Протокол виконує обчислення загального секрету, грунтуючись тільки на головних ключах, що дозволяє не виробляти передачі відкритих ключів під час виконання протоколу. Секретний ключ обчислюється з використанням наступної функції:

.

Протокол 3. Повний протокол узгодження ключів

????? ???????? ? ?????? ?????????? ?????????? ??????. ???????? ???????? ??????????? ? ???? ??? ???????? ?????? ??

, і двох пар сеансових ключів , .

У цьому протоколі виконується дві передачі сеансових відкритих ключів. З використанням сеансових і довготривалих відкритих та особистих ключів, що формуються загальні секретні значення та . Обчислення секретного ключа здійснюється за формулою

.

Підписування електронних документів різних форм

Підпис в HTML-формі

Така задача виникає при встановленні засобів ЕЦП в системах коли користувач працює в системі через Web-браузер (MS IE). У таких системах надходять наступним чином: створюється приховане hidden-поле у формі. Коли користувач натискає кнопку типу "підписати і відправити", відповідний скрипт обробника (наприклад, на VBScript) формує строкову змінну, в яку методом конкатенації записують важливу інформацію з ідентифікації документа і вміст текстових полів, які ввів користувач. Далі сформована стрічка підписується. Найчастіше використовуються методи об'єктів CAPICOM.dll, не відділений підпис. Підписана строкою змінна і є електронний документ. Підписаний документ (підписаний рядок) записується в hidden-полі і методом POST передається на сервер. Серверний додаток перевіряє підпис у змінної, отриманої з hidden-поля, і в залежності від результатів перевірки ЕЦП і змістовної частини електронного документа здійснює його подальшу обробку. Важливим моментом є збереження підписаного документа на сервер. Для цього, як правило, створюють таблицю в базі даних системи з двома полями: поле ключа і строкове поле з підписаним електронним документом.

Підпис в базі даних

Досить часто зустрічається нефайлова форма подання електронного документа, а електронний документ - як сукупність записів в таблицях бази даних. Для підписання такого документа значення полів записів в таблицях бази даних наводяться в рядковий тип, і за допомогою конкатенації формується строкою змінна, відображає істотну змістовну і ідентифікаційну частину документа. Саме цей рядок тепер вважається оригіналом електронного документа і підписується. Підписаний рядок зберігається у відповідній таблиці бази даних системи з двома полями: поле ключа документа і строкове поле, що містить підписаний електронний документ.

Підпис документів у форматі XML

Якщо документ представлений у форматі XML, то є кілька підходів до формування його підписів: формування ЕЦП XML-документів XMLdsig для Windows (MSXML5, MSXML6) з використанням Microsoft Office InfoPath 2003 - нової складової системи Microsoft Office; підпис XML-документа як звичайного файлу. Іноді для підпису в XML-документі в тезі документа створюють окремий атрибут, в який заноситься ЕЦП від символьного рядка змінної довжини, що містить значення атрибутів тега документа. Такий досить цікавий підхід до підпису XML-документа також зустрічається, і він є цілком легітимним.

Підпис файлів у форматі PDF

Для формування і перевірки ЕЦП і забезпечення юридичної значимості електронних документів, які формуються в форматі PDF, компанія "крипто-ПРО" розробила спеціальний продукт, званий «КріптоПро PDF». Він є модулем створення та перевірки ЕЦП і призначений для формування та перевірки ЕЦП в програмax Adobe Reader, Adobe Acrobat версії 7 і вище. «КріптоПро PDF» розроблений з використанням програмного інтерфейсу Adobe Systems Inc. і завірений електронним цифровим підписом компанії Adobe Systems.

Це дозволяє використовувати сертифіковані засоби криптографічного захисту інформації "КріптоПро CSP "в продуктах Adobe Acrobat, Adobe Reader та Adobe LiveCycle ES. Важливе зауваження: "крипто-Про CSP" для перевірки ЕЦП не вимагає активації ліцензії, тобто працює безкоштовно. Досить просто встановити цей продукт і перевіряти підпис з використанням Adobe Reader.

Підпис багатофайлових документів

Іноді документ може являти собою досить велику сукупність файлів. Наприклад, відомості про первинні документах для здійснення операцій в реєстрі власників інвестиційних паїв пайового фонду, отриманих від керуючої компанії. У цьому випадку можна формувати для кожного документа свою ЕЦП, а можна від цього відмовитися. Якщо з яких-небудь причин формування ЕЦП для кожного файлу документа неможливо, то створюють ще один файл текстового формату, в який записують ідентифікаційні дані документа і значення хеш-функцій для кожного файлу документа. Саме цей файл (картка документа) і підписують. Але в даному разі в системі повинен бути передбачений інструмент для користувача, що дозволяє розрахувати значення хеш-функцій для кожного файлу та порівняння обчислених значень з даними картки документа.

Цифрові сертифікати

При використанні асиметричних методів шифрування (і, зокрема, електронного цифрового підпису) необхідно мати гарантію автентичності пари (ім'я користувача, відкритий ключ користувача). Для вирішення цього завдання в специфікаціях X.509 вводяться поняття цифрового сертифікату та засвідчувального центру.

Засвідчувальний центр - це компонент глобальної служби каталогів, відповідальний за керування криптографічними ключами користувачів. Відкриті ключі та інша інформація про користувачів зберігається засвідчують центрами у вигляді цифрових сертифікатів, що мають наступну структуру:

· порядковий номер сертифіката;

· ідентифікатор алгоритму електронного підпису;

· ім'я центра, що засвідчує;

· термін придатності;

· ім'я власника сертифіката (ім'я користувача, якому належить сертифікат);

· відкриті ключі власника сертифіката (ключів може бути декілька);

· ідентифікатори алгоритмів, асоційованих з відкритими ключами власника сертифіката;

· електронний підпис, згенерований з використанням секретного ключа центра, що засвідчує (підписується результат хешування всієї інформації, що зберігається в сертифікаті).

Цифрові сертифікати володіють наступними властивостями:

· будь-який користувач, який знає відкритий ключ засвідчувального центру, може дізнатися відкриті ключі інших клієнтів центру і перевірити цілісність сертифіката;

· ніхто, крім центра, що засвідчує, не може модифікувати інформацію про користувача без порушення цілісності сертифікату.

У специфікаціях X.509 не описується конкретна процедура генерації криптографічних ключів та управління ними, однак даються деякі загальні рекомендації. Зокрема, обговорюється, що пари ключів можуть породжуватися кожним із наступних способів:

· ключі може генерувати сам користувач. У такому випадку секретний ключ не потрапляє в руки третіх осіб, проте потрібно вирішувати задачу безпечного зв'язку з документом з центром;

· ключі генерує довірену особу. У такому випадку доводиться вирішувати завдання безпечної доставки секретного ключа власнику та надання довірених даних для створення сертифіката;

· ключі генеруються підтверджуючий центр. У такому випадку залишається тільки завдання безпечної передачі ключів власнику.