Використання електронного цифрового підпису у електронному документообігу

Вступ

В рамках роботи європейських інститутів стосовно застосування електронного підпису потребують звернення до проблем, що стосуються окремих підписів, але дуже часто документи вимагають, щоб більше ніж один підпис давав цьому документові юридичну чинність або зробив угоду дійсною [1]. Вони можуть бути рівнозначними, незалежними підписами, типу таких, як підписи покупця і продавця в контракті, або вкладеними, в яких другий підпис ставиться поверх первинного підпису, прикладами яких є підпис свідка, або підпис начальника, який затверджує підпис підлеглого. Дотепер, політика підпису була визначена тільки для перевірки окремого електронного підпису.

Однак, оскільки все більше технологій паперового документообігу переміщається в електронне середовище, зростає ділова потреба розширити цю політику з метою підтримки багаторазових підписів. Ця потреба спричинена повільним просуванням застосування більш складних ділових угод, котрі вимагають запевняння не однієї людини, а декількох, або виникають більш строгі вимоги щодо форматів цифрового підпису. Ці вимоги стосуються, наприклад, фінансових трансакцій споживачів або кредитних угод зі структурованими умовами щодо "оплати/постачання". Для того, щоб прискорити застосування подвійного підпису, необхідно якнайшвидше створити підстави для надання юридичної сили такому підпису.

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

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

Правила використання підпису повинні взяти до уваги інтерфейс між людиною і комп'ютерною системою. Тільки людина може приймати рішення застосувати підпис чи ні. Це вірно, навіть коли підпис ґрунтується від імені організації або юридичної особи. Людина може керувати створенням підпису за допомогою прикладного інтерфейсу.

Розділ 1. Основи електронного юридично значимого документообігу в процесі створення цифрового підпису

1.1 Використання схеми відкритих криптографічних ключів

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

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

Поширення відкритих ключів між учасниками електронного документообігу може здійснюватися по двох технологіях: корпоративно і відкрито.

Корпоративна технологія припускає наявність незалежного учасника електронного документообігу, що виконує роль Адміністрації системи ЕЦП і забезпечуючого формування довідників відкритих ключів учасників системи, їхнього розсилання і відновлення для кожного її учасника. Корпоративна технологія керування ключами характерна для організації корпоративних комп'ютерних мереж.

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

При відправленні документа, користувач "пристиковує" до нього свій цифровий паспорт і підписує його своєю ЕЦП. При одержанні документа перевіряється дійсність і незмінність цифрового паспорта, шляхом перевірки під ним ЕЦП сертифікаційного центра, витягається з нього відкритий ключ відправника і на основі його перевіряється ЕЦП відправника під отриманим документом.

Відкрита схема не вимагає формування і відновлення довідників відкритих ключів, тому що відкритий ключ відправника попадає до одержувача разом з електронним документом. Відкрита схема поширення ключів характерна для відкритих мереж, хоча також може успішно використовуватися й у корпоративних комп'ютерних мережах. Відкрита схема вимагає наявності Сертифікаційного центра (СЦ) і центрів видачі цифрових паспортів.

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

.1.1 Основні функції Адміністрації системи ЕЦП у корпоративних мережах

Основними функціями Адміністрації системи ЕЦП є:

1.  Висновок договорів на обслуговування в системі електронного документообігу, юридична експертиза договірної документації;

2.      Опис параметрів користувачів у системі електронного документообігу;

3.  Здійснення ключового керування в системі;

4.      Здійснення заходів щодо забезпечення безпечної експлуатації системи;

.        Забезпечення технічної і технологічної експертизи при виникненні конфліктних ситуацій між учасниками електронного документообігу, організація процедури узгодження розбіжностей;

.        Ліцензійний супровід експлуатації криптографічних засобів;

.1.2 Основні функції Центра видачі цифрових паспортів і СЦ у відкритих мережах

Центр видачі цифрових паспортів:

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

2.      Автоматизоване введення даних для формування цифрового паспорта;

.        Відправлення ЦП по корпоративній мережі в СЦ для його запевняння

.        електронним цифровим підписом СЦ;

.        Видача завіреного цифрового паспорта кінцевому користувачеві;

.        Облік і архівне збереження виданих цифрових паспортів.

Центр сертифікації:

.    Виконує функції запевняння своїм електронним цифровим підписом і реєстрацію цифрових паспортів, одержуваних від центрів їхньої видачі;

2.      Здійснює керування цифровими паспортами;

.        Реалізує запити кінцевих користувачів на перевірку дійсності (перевірка дійсності ЦП, терміну його дії, відсутності в списку відкликаних ЦП);

.        Поширює інформацію про відкликані цифрові паспорти.

1.1.3 Використання електронного цифрового підпису в інформаційних технологіяхтехнології стали в даний час одними з найбільше широко використовуваними в мережі Інтернет механізмом обміну і надання інформації. Однак, як і в більшості рішень, що одержали поширення в Інтернет, питання безпеки при виробленні концепції і реалізації використовуваних у Web-протоколів або форматів (у першу чергу HTTP (Hyper Text Transfer Protocol) враховані не були, що привело до появи додаткових надбудов до протоколів транспортного рівня, що дозволяють вирішити задачі забезпечення безпеки. Універсальний протокол, що є де-факто стандартом для Web-технологій був розроблений компанією Netscape Communications, Inc. і одержав назву SSL (Secure Sockets Layer). Протокол HTTPS (HTTP Secure - http поверх SSL) підтримується більшістю найбільш розповсюджених броузерів, у тому числі Netscape і Microsoft Explorer, і багатьма Web-серверами. Однак це не дозволяє забезпечити захист переданої інформації для таких часто використовуваних протоколів, як POP3, SMTP, telnet, так і довільних прикладних протоколів заснованих на стеці TCP/IP. Додатково, і для роботи з завіреними електронним цифровим підписом документами було розроблено програмне забезпечення, що дає можливість за допомогою протоколу SSL забезпечити строгий захист інформації при використанні описаних вище протоколів, а також підтримувати роботу з інформацією у форматі CMS/PKCS#7. Для забезпечення специфічних функцій Абонентського Пункту Завідуючого Центру, додатково використовуються й інші формати представлення даних про які буде повідомлено нижче.

Це устаткування не накладає обмежень на використовуване клієнтське програмне забезпечення і дозволяє вирішити наступні задачі:

·  Забезпечувати приховання переданої інформації;

·              Забезпечувати цілісність цієї інформації, тобто захист від модифікації;

·              Здійснювати автентифікацію серверів, тобто доказ того, що сервера є саме тими, за кого вони себе видають;

·              Здійснювати автентифікацію клієнтів при доступі до сервера;

·              Забезпечувати функції Абонентського Пункту Завідуючого Центру.

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

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

·  Зашифроване за допомогою відкритого ключа повідомлення може бути розшифровано тільки за допомогою відповідного закритого ключа;

·              ЕЦП, створена за допомогою закритого ключа, може бути перевірена на відповідність за допомогою відкритого ключа.

У протоколі SSL/TLS використовується асиметричний алгоритм для вироблення загальних сесійних ключів, призначених для шифрування каналу між сервером і клієнтом, причому для кожної сесії використовується новий ключ. Конкретний алгоритм і ключ визначаються в процесі встановлення з'єднання.

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

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

Цифровий сертифікат - це документ, що видає ЗЦ кожному з взаємодіючих об'єктів, дійсність яких він раніше засвідчив. Сертифікат містить інформацію про об'єкт (як, наприклад, назва організації, ім'я (сервера або людини)), його відкритий ключ і саме головне ЕЦП самого ЗЦ, передбачається, що всі учасники обміну безумовно довіряють ЗЦ. Сертифікати можуть служити як для забезпечення безпеки Web-повідомлень, так і для захисту поштових повідомлень і підпису програмного забезпечення. Існують три види цифрових сертифікатів, використовуваних у SSL/TLS: сертифікат сервера (Site Certificate), персональний сертифікат (Personal Certificate) і сертифікат ЗЦ (CA Certificate)

Сертифікат сервера дозволяє упевнитися в дійсності сервера - абстрактного ресурсу.

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

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

.2 Робота Завідуючого Центру сертифікатів та ключів підпису

"Завідуючий Центр сертифікатів та ключів підпису" є ключовим компонентом для різного типу прикладних захищених систем корпоративного рівня (захищений документообіг, Інтернет-банкінг, білінгові системи, електронна комерція, Інтернет процесінг і т.п.), що використовує технології інфраструктури з відкритими ключами (PKI).

Центр корпоративної інформації, засвідчує, системи виконані як довірені (може поставлятися з вихідними кодами) сервіс на Unix системах (FreeBSD, Linux) і забезпечує:

.    Реєстрацію й обслуговування запитів користувачів на створення цифрового сертифіката. Створення за заявою користувача секретного і відкритого ключів. Спосіб доставки інформації про власника сертифіката і формат запиту визначається регламентом експлуатації конкретного ЗЦ.

2.      Створення цифрового сертифіката користувача і його запевняння на секретному ключі ЗЦ. Сертифікати, що випускаються, можуть бути використані як персональні, сертифікати ресурсу, або кореневі сертифікати підлеглих ЗЦ. Створені цифрові сертифікати можуть брати участь в організації захищеного з'єднання по протоколі Transport Layer Security (TLS) із криптографічними алгоритмами (хеш функція, шифрування і вироблення імітовставки).

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

У КП реалізовано:

Алгоритми ЕЦП:

§ RSA (PKCS#1, RFC 2437)

§   DSA (FIPS 186-1)

Хеш функції:

§ MD5 (RFC 1321)

§   SHA-1 (FIPS 181, RFC 3174)

Алгоритм узгодження ключів

§ Diffie-Hellman (X9.42, RFC 2631)

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

ЗЦ надає можливість здійснювати роздільний випуск електронних сертифікатів для ЕЦП і асиметричного шифрування, використовуваного S/MIME (RFC 2633). Електронні сертифікати відповідають міжнародним рекомендаціям X.509 v.3 (RFC 2459, RFC 3039) і можуть видаватися у форматах PKCS#12, DER або PEM.

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

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

Взаємодія з адміністративним ресурсом відбувається по захищеному з'єднанню по протоколі TLS v1.0 (можлива підтримка протоколу SSLv3).

Для довірених систем <#"872474.files/image001.gif">

Рис. 1.1 Структурна схема ЗЦ

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

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

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

За допомогою інфраструктури відкритих ключів вирішуються наступні задачі:

·  Забезпечення приховання переданої інформації.

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

·  Забезпечення автентифікації ресурсу, тобто доказ того, що ресурс є саме тим, за кого він себе видає.

·              Забезпечення автентифікації користувачів при доступі до ресурсу.

Узявши за основу ці корисні властивості, реалізовані в системі <#"872474.files/image002.gif">

Рис. 1.2 Система захищеного електронного документообігу

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

1.5 Запит на створення сертифіката з локальною генерацією ключової пари

Такий вид запиту призначений для створення сертифіката з локальної генерації ключів і формування запиту у форматі PKCS#10. Такий запит припускає генерацію ключової пари, тому при реальній експлуатації набирають сили обмеження Ліцензійної угоди.

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

Якщо у формі майстра запитів був зведений додатковий прапор "Зробити перевидання існуючого сертифіката" (сертифікат повинний мати статус - Особисті сертифікати), то дані будуть включені в запит зі складу обраного сертифіката. Такий режим корисний для систем, у яких регламентом допускається перевидання власних сертифікатів самостійно самим користувачем, минаючи службу Адміністраторів взаємодії з користувачами.

1.  необхідно вказати яким сертифікатом ЗЦ буде завірений сертифікат, для якого готується запит (від якого кореня буде видаватися даний сертифікат);

2.      необхідно вказати для яких задач буде використані створюваний сертифікат і визначити (додаткова функція "Редагувати") області і порядок застосування сертифіката, для яких його використання буде вважатися дійсним;

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

.        вказується інформація (загального і додаткова) про власника цифрового сертифіката;

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

Запис про запит виду PKCS#10 не повинна віддалятися з бази "Запити в ЗЦ" доки, не буде отримана відповідь зі служб ЗЦ і на клієнтському робочому місці не буде згрупована (процедура автоматична або в ON-LINE). Персональний сертифікат (секретний ключ, що не залишав робочого місця і відповідний йому, завірений сертифікат з відкритим ключем).

Теоретично можлива така ситуація, при якій запит на створення сертифіката саме для даного відкритого ключа може бути відхилений. Таке поводження ЗЦ порозумівається тим, що ЗЦ при створенні сертифіката забезпечує "унікальність відкритих ключів". Самі ключі були створені локально (ЗЦ не керує даною процедурою) на робочому місці користувача і малоймовірно, але теоретично можливо, що два користувачі незалежно друг від друга створили однакові відкриті ключі - така ситуація для PKI систем є неприпустимою. У цьому випадку користувач повинний зробити повторне формування PKCS#10 запиту і передачу його службам ЗЦ з наступним формуванням сертифіката відкритого ключа на ЗЦ.

Якщо формування запиту здійснюється користувачем самостійно, то на цьому етапі формування запиту закінчується. Користувачеві необхідно (не зводячи прапор відправлення запиту в ЗЦ) зробити Експорт запиту з бази запитів і на транспортному носії доставити в служби ЗЦ.

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

З цього моменту можна користуватися знову створеним сертифікатом. Використання PKCS#10 запиту не є безпечним (мається на увазі не безпека ключової інформації, а істинність введеної інформації про суб'єкта) для ON-LINE режиму - користувачі самостійно заповнюють інформаційну частину сертифіката без контролю Адміністратора взаємодії з користувачами. Порозумівається це тим, що сам PKCS#10 має ЕЦП на ключі який тільки що був локально створений і про нього "нічого не знають" служби ЗЦ, інформацію, що знаходиться усередині запиту і підписану на "раніше невідомому для ЗЦ" ключі неможливо змінити - порушиться цілісність запиту, тому те, що було введено при заповненні форм майстри запиту, є винятковою відповідальністю користувача (і формально може суперечити політиці безпеки PKI системи в цілому), що є потенційною погрозою для всієї PKI системи. Дата дії сертифіката, отриманого на такий запит, проставляється автоматично й обчислюється як поточна дата плюс один рік. Для прийняття хоч яких те заходів для забезпечення істинності й адресності переданого в режимі ON-LINE запиту використовується захищений транспортний протокол TLS з авторизацією по персональному сертифікаті в момент утворення з'єднання, однак CMC запис, утворений з PKCS#10 запиту в базі "історій" сертифікатів на ЗЦ не буде (і технічно не може) мати ЕЦП адміністратора, що відповідальний за інформацію представлену в запиті, що може викликати значні труднощі при розборі можливих конфліктних ситуацій зв'язаних саме з цим сертифікатом у службі Арбітражу ЗЦ.

Більш безпечної є режим ON-LINE перевидання власного сертифіката, при якому інформаційна частина витягається з уже перевіреного Службою адміністраторів ЗЦ сертифіката, а сама CMC запис має ЕЦП раніше виданого діючого сертифіката користувача.

.6 Запит на створення сертифіката з генерацією ключової пари в ЗЦ

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

Форми, пропоновані до заповнення Адміністратором ЗЦ по представленню інформації кінцевого користувача майже аналогічні з формами запиту PKCS#10. Користувачем заповнюється запропонований ланцюжок форм, деякі полючи в аркушах ланцюжка є недоступними для даного виду запиту.

Якщо у формі майстра запитів був зведений додатковий прапор "Зробити перевидання існуючого сертифіката" (сертифікат повинний мати статус - Особисті сертифікати), то дані будуть включені в запит зі складу обраного сертифіката. Такий режим корисний для систем, у яких регламентом допускається перевидання власних сертифікатів самостійно самим користувачем минаючи службу Адміністраторів взаємодії з користувачами.

1.  необхідно вказати яким кореневим сертифікатом ЗЦ буде завірений сертифікат, для якого готується запит (від якого кореня буде видаватися даний сертифікат);

2.      необхідно вказати сертифікат з бази "Особисті сертифікати", ключ якого буде брати участь у виробленні ЕЦП на CMC запиті, тобто сертифікат Адміністратора;

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

.        Адміністратор може керувати періодом дії створюваного сертифіката. Але в будь-якому випадку період дії сертифіката не може перевищувати дати припинення дії кореневого сертифіката ЗЦ, від якого видається користувальний сертифікат.

На цьому кроці Адміністратор може визначити мітки мандатної політики розмежування доступу, їхній рівень. Види доступу і максимальний рівень доступу визначені в кореневому сертифікаті, від якого видається користувальний сертифікат.

Адміністратор може створювати сертифікати інших адміністраторів із указівкою спеціальних мандатних міток. Автоматично відслідковується ланцюжок підпорядкування значень міток, не можна створити мітку, зі значенням перевищуючому або рівним значенню мітки в кореневому сертифікаті видавця або мітки із сертифіката Адміністратора, що підписує поточний CMC запит. Молодші розряди Ідентифікатора політики розмежування доступу можуть вводиться в додатковому вікні через роздільник "+". У системі зареєстровані два молодших розряди:

1.  Сертифікати адміністратора з даною міткою можуть бути використані тільки для запевняння сертифікатів.

2.      Сертифікати адміністратора з даною міткою можуть бути використані тільки для керування статусом користувальних сертифікатів.

Якщо кореневий сертифікат видавця не має у своєму складі мандатної мітки, то при спробі "Редагувати" на екрані буде отримане відповідне попередження.

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

6.      Указати пароль, що буде брати участь у шифруванні (розшифрування) секретного ключа створеного засобами ЗЦ зі складу в наслідку отриманого сертифіката. При введенні пароля автоматично перевіряється мінімально припустима довжина (6 символів) і відповідність пароля, що повторно вводиться. Адміністратор повинний забезпечити умови, при яких власноручно введений користувачем пароль залишився б винятково секретом користувача. Адміністратор повинний ознайомити користувача з матеріалами дійсного керівництва. Технологія захисту введеного пароля при транспортуванні запиту/відповіді по каналах зв'язку і між компонентами ЗЦ до КП) зі складу ЗЦ заснована на асиметричному шифруванні введеного пароля користувача на відкритому ключі КП ( що використовується винятково для цих цілей).

.        Вказується інформація (загального і додаткова) про власника цифрового сертифіката.

.        Адміністраторові надається можливість увести додаткову технологічну інформацію, що не буде включена до складу сертифіката, але буде утримуватися в CMC запису, що входить у "історію" даного сертифіката. Основне призначення цієї форми - введення атрибутів документів підтверджуючу персональну інформацію про суб'єкта або прив'язки суб'єкта до формальних вимог реальної PKI системи, у якій планується використовувати сертифікати.

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

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

Завершення процедури формування запиту приводить до розміщення запиту в базі "Запити в ЗЦ" поза залежністю зведений прапор доставки в ЗЦ чи ні.

При мережній доставці запиту в ЗЦ, якщо по яким або причинах запит не зміг бути оброблений у режимі ON-LINE, те користувач одержує про даний факт повідомлення, і наступні дії відбуваються вручну (функція "Одержати відповідь" у базі "Запити в ЗЦ").

Якщо процедура відправлення запиту, його обробки і доставці на АП пройшла, то після візуалізації змісту завіреного сертифіката, користувач установлює його в локальне сховище в базу "Особисті сертифікати", попутно буде запитаний пароль, що брав участь у захисті секретного ключа при транспортування по каналах і між компонентами ЗЦ. З цього моменту можна користуватися знову створеним сертифікатом.

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

Користувач, одержавши відчужуваний носій зі своїм персональним сертифікатом на своєму робочому місці в базу "Особисті сертифікати". І по виконанні процедури Імпорту встановленим сертифікатом користуватися для вироблення власної ЕЦП на електронних документах і проходження процедур автентификації при організації захищених з'єднань.

Для одержання твердої копії сертифіката на паперовому носії варто скористатися функцією "Сертифікати" з форми "Відповідь ЗЦ".

.7 Перевірка дійсності ЕЦП на реальний момент часу

Перевірка дійсності ЕЦП на реальний момент часу реалізований на основі рекомендацій RFC 3029 по роботі зі спеціалізованим сервісом "Електронного нотаріуса". Основна форма пропонує висновок відсортованих запитів (або запитів у зв'язуванні з DVC квитанціями) по фільтру - ім'я сервера DVCS. З операцій над записами доступні:

Новий запит:

·  Ініціює майстер DVC заявок на перевірку ЭЦП;

·              Відкрити відзначену заявку або квитанцію;

·              Видалити запит цілком (у зв'язуванні з квитанцією) або тільки квитанцію;

·              Експортувати DVC заявку або квитанцію.

.8 COM - технологія

Абревіатура COM - це Component Object Model - компонентна об'єктна модель. Суттю використання даної технології є те, що програми будуються з компонентів, що складаються з об'єктів, і доступ до зареєстрованих об'єктів Криптографічного Центра (КЦ) на обробку завірених документів стає доступний як з HTML форм, так і з інших програм установлених на комп'ютері користувача.

·              ЕЦП HTML форми <#"872474.files/image003.gif">

: простий дільник числа (p-1), що задовольняє умові:

Параметри p, q, g публікуються для всіх учасників обміну ЕД з ЕЦП.

Секретний ключ x випадково вибирається з діапазону [1,q] і тримається в секреті.

Відкритий ключ обчислюється:

Також при описі даної схеми будуть використовуватися наступні позначення і додаткові параметри: m - вхідне повідомлення користувача для схеми з ЕЦП; k - випадкове число, що задовольняє умові 0<k<q, що зберігається в секреті і міняється від одного підпису до іншої; H - хеш-функція, h - хеш-код повідомлення.

Процес генерації ЕЦП складається з декількох етапів:

. Обчислюється хеш-код повідомлення m

. З діапазону [1,q] випадковим образом вибирається значення k і обчислюється

. Обчислюється , де  задовольняє умові

Значення r, s є ЕЦП повідомлення m і передаються разом з ним по каналах зв'язку.

.9.2 Перевірка ЕЦП

Нехай прийняте повідомлення m1 і його підпис s1, r1.

Перевірка ЕЦП відбувається в такий спосіб:

-        перевіряється виконань умов 0<r1<q, 0<s1<q, і якщо хоча б одне з них порушено, підпис відкидається.

-        Обчислюються значення:

-        перевіряється рівність v = r1

Якщо остання рівність виконується, то підпис приймається. У даному стандарті специфікується також процедура генерації основних параметрів системи і проводиться доказ того, що якщо v=r1, то m1=m, r1=r, s1=s.

.10 Стандарт на процедури ЕЦП ГОСТ Р 34.10-94

Вітчизняним стандартом на процедури вироблення і перевірки ЕЦП є ГОСТ Р 34.10-94. Схема ЕЦП, запропонована в даному стандарті, багато в чому нагадує підпис у DSA.

Цифровий підпис являє собою два великих цілих простих числа. Загальнодоступні параметри схеми ЕЦП (p, q, a) повинні задовольняти наступним умовам:

 або

: простий дільник числа (p-1), що задовольняє

умові

Секретний ключ x випадково вибирається з діапазону [1,q] і тримається в секреті.

Відкритий ключ обчислюється: .

2.10.1 Генерація ЕЦП

Процес генерації ЕЦП складається з декількох етапів:

1.Обчислюється хеш-код повідомлення m

(хеш-функція, використовувана в даному стандарті відповідно до ГОСТ Р 34.10-94), якщо , те  привласнюється значення 0…02551

. З діапазону [1,q] випадковим образом вибирається значення k

. Обчислюється , ; якщо r1=0, варто повернутися до попереднього етапу і виробити інше значення k.

. Обчислюється ; якщо s=0, те необхідно виробити інше значення k.

Значення r1, s1 є ЕЦП повідомлення m і передаються разом з ним по каналах зв'язку.

.10.2 Перевірка ЕЦП

Перевірка ЕЦП відбувається в такий спосіб:

         перевіряється виконань умов 0<r<q, 0<s<q, і якщо хоча б одне з них порушено, підпис відкидається.

-        Обчислюється хеш-код даного повідомлення ; Якщо , те бітове представлення : 0…02551...

         Обчислюється значення .

         Обчислюється значення .

         Обчислюється значення .

         перевіряється рівність .

Якщо остання рівність виконується, то підпис приймається.

.11 Цифрові підписи, засновані на симетричних кріптосистемах

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

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

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

Розділ 3. Забезпечення цілісності даних і автентифікації користувачів за допомогою підписів xml у системах документообігу

.1 Можливості цифрового підпису у форматі XML

Специфікація підпису XML - "Цифровий підпис XML" (XMLDS) - яка була розроблена спільними зусиллями організації W3C і IETF, має статус Рекомендації W3C. Цей документ [7] визначає правила обробки і синтаксис, призначені для упакування в XML-формат даних про цілісність повідомлення, його автентифікації і користувальницької автентифікації.

У нашому випадку розглядається (як приклад) взаємодія між туроператором і його партнерами (готелями). Припустимо, що туроператор хоче викликати метод GetSpecial Discounted Booking For Partners Web-сервісу свого партнера. Цей метод надає послугу інтерактивного резервування місць в отеленні за спеціальною ціною (зі знижкою). Причому побачити цю знижку можуть тільки бізнес партнери, а не споживачі.

Викликаючи метод SOAP - Simple Object Access Protocol GetSpecial Discounted Booking For Partners, туроператор включає в нього інформацію про цілісність повідомлення і користувальницької автентифікації. При одержанні цього виклику брандмауерові XML організації буде потрібно переглянути SOAP-повідомлення, щоб повірити, що:

·  повідомлення не було змінено, поки воно передавалося в Web-сервіс організації (цілісність повідомлення);

·              запитуюча сторона є бізнес партнером (користувальницька автентифікація).

Якщо виконані ці дві умови, брандмауер XML дозволяє запитуючій стороні перейти до SOAP-сервера і робить наступні дії:

1.  Туроператор направляє в Web-сервіс організації SOAP-запит про виклик методу. Цей запит включає всю інформацію, що відноситься до забезпечення безпеки (користувальницька автентифікація і користувальницька автентифікація).

2.      Web-сервіс організації захищений брандмауером XML, що приймає всі запити, що направляються в цей SOAP-сервер. брандмауер XML перевіряє, чи ідентично отримане повідомлення тому, що запитуюча сторона збиралася відправити.

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

.        Якщо запитуюча сторона є бізнес партнером, брандмауер XML дозволяє запитуючій стороні перейти до SOAP-сервера.

Лістінг 1 - це простий SOAP-запит, що передає в Web-сервіс організації виклик методу GetSpecial Discounted Booking For Partners. У цьому SOAP-запиті відсутні які-небудь дані про цілісність повідомлення або користувальницької автентифікації. Лістінг 1 - це початкова крапка демонстрації застосування специфікації "Цифровий підпис XML".

SOAP у даному випадку використовується як приклад XML-формату, щоб продемонструвати "Цифровий підпис XML", що не є специфічною для SOAP. Тому її можна застосовувати, щоб уставляти підписи і профілі повідомлення в будь-який екземпляр XML: SOAP або який-небудь інший.

У наступному прикладі теги цифрового підпису XML будуть вставлені в заголовок SOAP. Цифровий підпис - це гнучка технологія, він допускає включення таких тегів у будь-яке місце XML-файлу. Насправді існують три типи підписів XML: замкнена в конверт (enveloping), що укладається в конверт (enveloped) і окрема (detached). Якщо підпис XML обертає даному, підлягаючому підписанню, говорять, що це підпис, що укладає в конверт. Якщо ж даному, підлягаючому підписанню, обертають цей підпис (наприклад, підпис XML стає елементом даних XML, що підписуються), то цей підпис називається укладається в конверт. Нарешті, якщо підпис і даному, підлягаючому підписанню, зберігаються роздільно - елемент, що підписується, і елемент підпису є елементами одного рівня - такий підпис прийнято вважати відособленої. У прикладі, що у цій статті ілюструє застосування специфікації "Цифровий підпис XML", використовуються відособлені підписи.

.2 Формування цифрового підпису XML

Перший крок - це створення елемента Signature. Згодом цей елемент буде обертати всі інші елементи цифрового підпису XML. У Лістінгу 2 точно таке ж тіло як і у Лістінгу 1, єдина відмінність між ними полягає в тім, що Лістінг 2 містить оголошення простору імен цифрового підпису XML (http://www.w3.org/2000/09/xmldsig#) і заголовок SOAP. Цей заголовок SOAP обертає елемент Signature.

Елемент Signature у Лістінгу 2 містить три дочірніх елементи: SignedInfo, SignatureValue і KeyInfo.

Цей елемент є єдиним елементом, що обертає, для інших тегів цифрового підпису XML. У наступних кроках: 2, 3 і 4 - ми створимо дочірні вузли для цих трьох нащадків Signature (SignedInfo, SignatureValue і KeyInfo).

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

Алгоритми канонізації призначені для генерації двійкових потоків для логічно еквівалентних даних XML. Щоб бути упевненим, що логічно еквівалентні XML-документи створюють той самий дайджест (і однаковий підпис), необхідно канонізувати ресурс XML до створення дайджесту потоку даних.

Елемент Canonicalization Method у Лістінгу 3 містить атрибут Algorithm, значенням якого є рядок URI (http://www.w3.org/2001/10/xml-exc-c14n#). Цей рядок URI вказує алгоритм, описаний специфікацією W3C - "Виняткова канонізація XML" (Exclusive XML Canonicalization). Подробиці канонізації XML виходять за рамки цієї статті. Детальна інформація про канонізації може бути знайдена в статтях, посилання на які приведені в розділі Ресурси.

На даному етапі просто створюється елемент Canonicalization Method - а алгоритм канонізації поки не використовується. Він буде застосовується до елемента SignedInfo після того, як будуть сформовані всі його нащадки.

Наступний нащадок елемента SignedInfo - це елемент Signature Method, атрибут Algorithm якого вказує алгоритм, використовуваний для створення криптографічного підпису.

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

1.  Указівка даних, що підлягають підписанню. Для цього використовується атрибут URI елемента Reference. Дані, що підписуються, можуть бути як усередині XML-документа, так і поза нього. Якщо дані і підпис знаходяться в тому самому XML-документі, для їхньої указівки використовується ідентифікатор фрагмента у виді значення атрибута URI елемента Reference. Так, у Лістінгу 3 значення атрибута URI указує на елемент GetSpecial Discounted Booking For Partners. Якщо ж дані є зовнішніми стосовно файлу з цифровим підписом XML, посилатися на них необхідно за допомогою URI як значення атрибута URI елемента Reference.

Цифровий підпис XML дозволяє виконувати ряд операцій над даними перш, ніж профілювати і підписувати них. Наприклад, до того, як підписувати дані, їх можна канонізувати, або до їхнього профілювання до них можна застосувати які-небудь перетворення XSL. Так, якщо дані про ціни представлені в табличній формі, їх можна перетворити, одержавши звичайний рахунок-фактуру. Для цього можна скористатися перетворенням XSL як шаблоном цього рахунка. Це означає, що буде підписуватися весь рахунок, а не тільки неопрацьовані дані, включені у файл із цифровим підписом XML.

Елемент Transforms містить інформацію про те, які операції виконуються на даних до їхнього підписання. В елемента Transforms у Лістінгу 3 мається один дочірній елемент Transform. Таких елементів може бути будь-яка кількість.

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

У тому випадку якщо елемент Transforms містить більш одного елемента Transform, необхідно враховувати їхній порядок проходження. Перетворення виконуються в тім порядку, у якому вони з'являються в елементі Transforms. Усі вони виробляються до профілювання даних. Отже, вихідні дані останнього елемента Transform є вхідними даними для алгоритму профілю повідомлення.

2.  Алгоритм, використовуваний для створення дайджесту. Специфікація "Цифровий підпис XML" рекомендує використовувати алгоритм профілю SHA-1. Ця інформація знаходиться в елементі DigestMethod, нащадку елемента Reference - у значенні його атрибута Algorithm (http://www.w3.org/2000/09/xmldsig#sha1).

3.      Значення дайджесту. Елемент DigestValue у Лістінгу 3 містить дійсне значення дайджесту, отримане застосуванням алгоритму дайджесту до канонічної форми елемента GetSpecial Discounted Booking For Partners. Необхідно відзначити, що бінарні дані в неопрацьованому виді (такі як потік, створений алгоритмами дайджесту повідомлення, підписи і шифрування) не можуть бути загорнені в розмітку XML - це може ускладнити розбір XML. Перш ніж обертати них у розмітку XML, такі дані представляються в кодуванні base-64. У результаті, зашифровані дані не містять бітів, що могли б конфліктувати із правилами обробки XML.

Після того, як SignedInfo і його дочірні елементи сформовані, необхідно провести канонізацію всього елемента SignedInfo по алгоритму, зазначеному в елементі Canonicalization Method. Після цього варто одержати значення дайджесту й обернути це значення в елемент Signature Value, як показано в Лістінгу 4. Під час підписання канонічна форма елемента SignedInfo використовується в якості даному, підлягаючому підписанню. У неї входять усі дочірні елементи елемента SignedInfo.

Необхідно відзначити, що структура SignedInfo містить посилання на підпис даних (атрибут URI елемента Reference), значення дайджесту й ім'я методу підпису, а також інші біти інформації. Отже, підписання структури SignedInfo фактично означає підписання дайджесту даних разом із самим посиланням на ці дані.

У Лістінгу 2 в елемента Signature є ще один дочірній елемент по імені KeyInfo. Четвертий крок - створення його нащадків. У Лістінгу 5 елемент KeyInfo містить дочірній елемент KeyName. Цей елемент KeyName є ідентифікатором ключа, що використовується для перевірки підпису. KeyName - це просто "заповнювач" для ідентифікаторів ключа. Специфікація "Цифровий підпис XML" не визначає механізм, що співвідносить ідентифікатор з дійсною парою ключів, використовуваних для підписання. Проектування механізму ідентифікації ключа - задача додатків, що реалізують "Цифровий підпис XML". Наприклад, ідентифікатор ключа в Лістінгу 5 (MyKeyIdentifier) може ідентифікувати загальний секретний ключ (симетричний ключ), яким вже обмінювалися туроператор і готель.

Крім того, елемент KeyInfo - необов'язковий: його можна як включати, так і не включати в підпис. Цей елемент є необов'язковим, тому що під час підписання, можливо, може не знадобитися включати інформацію про ключ у файл із цифровим підписом XML. Елемент KeyInfo може також використовуватися при шифруванні XML, про що буде розказано в наступному розділі.

Ці чотири кроки - проста демонстрація застосування специфікації "Цифровий підпис XML". Лістінг 5 - повне SOAP-повідомлення, що у своєму заголовку несе дані про цілісність повідомлення і користувальницької автентифікації.

Розглянемо, як обробляється заголовок повідомлення, представленого в Лістінге 5, на стороні Web-сервісу організації.

.2.1 Перевірка цифрового підпису XML

Процедура перевірки проста і логічно може бути виведена з методики формування цифрового підпису XML, розглянутої вище. Вона розпадається на три етапи.

По-перше, необхідно канонізувати елемент SignedInfo. Нагадаємо, що елемент Canonicalization Method встановлює алгоритм канонізації. Тому варто скористатися цією канонічною формою елемента SignedInfo для частини процесу, що залишилася, перевірки.

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

1.  Дані, по яких побудований дайджест. Випливає, що атрибут Reference елемента, щоб одержати ці дані.

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

.        Алгоритм дайджесту. Ця інформація знаходиться в значенні атрибута Algorithm елемента Digest Method. Необхідно застосувати цей дайджест повідомлення і перевірити, чи не відрізняється значення дайджесту від тієї, що утримується в елементі DigestValue.

Якщо перевірка дайджесту приводить до негативного результату, то процес перевірки закінчується і вважається незадовільним.

Якщо з'ясовується, що з величиною профілю усі в порядку, настає черга третього етапу - перевірки підпису. Для перевірки підпису необхідний ключ сторони, що підписала, (відкритий або загальний секретний). Інформацію про ключ можна одержати з елемента KeyInfo, якщо він присутній (або якщо додаткові уже відомий така інформація). Як тільки ключ, використовуваний при перевірці підпису, відомий, потрібно прочитати метод підпису, що застосовувався при створенні цього підпису. Атрибут Algorithm елемента Signature Method містить цю інформацію. Після чого варто скористатися канонічною формою елемента Signed Info і ключем, щоб підтвердити величину підпису.

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

·  Можна перевірити, що отримане SOAP-повідомлення було дійсно відправлене відомим відправником.

·              Можна перевірити, що отримані дані не були змінені, поки вони передавалися, і що вони не відрізняються від тих, що відправник збирався відправити.

Таким чином, стосуючись нашого приклада, можна бути упевненим, що запит про резервування за спеціальною ціною зі знижкою був уставлений дійсно партнером, і що ці дані не були змінені, поки вони передавалися. Проте, можливо ситуація, коли дані, передані по Інтернет, можуть бути переглянуті хакерами. Розглянемо, як ця проблема може бути вирішена за допомогою специфікації "Шифрування XML".

.3 Шифрування XML

Специфікація шифрування XML задовольняє вимогам конфіденційності XML-повідомлень. Ця специфікація дозволяє реалізувати наступну функціональність:

·  шифрування цілого XML-файлу;

·              шифрування будь-якого окремого елемента XML-файлу;

·              шифрування тільки змісту XML-файлу;

·              шифрування даних, відмінних від XML (наприклад, малюнка JPG);

·              шифрування вже зашифрованого елемента ("супершифрування").

.4 Шифрування цілого XML-файлу

Давайте почнемо із шифрування цілого XML-файлу. Лістінг 6 - це приклад такого зашифрованого файлу [3]. При цьому вихідний XML-документ не показаний, оскільки він не потрібний, тому що шифрування XML-файлу своїм результатом має таку ж XML-структуру - за винятком зашифрованої величини, укладеної в елементі CipherValue.

Кореневий елемент EncryptedData несе зашифровані дані разом з такою необхідною інформацією, як алгоритм, використовуваний для шифрування. Цей елемент містить оголошення простору імен шифрування XML (http://www.w3.org/2001/04/xmlenc#) і атрибут MimeType, значення якого дорівнює text/xml. По цьому атрибуті одержувач цього зашифрованого XML-файлу може зрозуміти, що XML-файл був зашифрований, щоб створити структуру EncryptedData.

Перший нащадок кореневого елемента - елемент EncryptionMethod. Цей елемент містить атрибут Algorithm, що визначає алгоритм, використаний при шифруванні. Його значення дорівнює http://www.w3.org/2001/04/xmlenc#3des-cbc, що визначає алгоритм потрійний DES (Data Encryption Standard, Стандарт шифрування даних).

Елемент ds:KeyInfo той же самий, що і той, котрий використовувався при застосуванні специфікації "Цифровий підпис XML". Необхідно відзначити, що цей елемент був запозичений із простору імен цифрового підпису XML.

Елемент EncryptedData містить ще один дочірній елемент - CipherData, у якого у свою чергу мається дочірній елемент CipherValue. Цей елемент CipherValue несе зашифрований зміст (зашифровану версію XML-документа). Таким чином, результатом шифрування XML-файлу є зміст елемента CipherValue.

.5 Шифрування окремого елемента

Як було сказано вище, структура EncryptedData несе зашифровані дані разом з необхідною інформацією. В основі шифрування одиночного елемента XML-файлу лежить аналогічний підхід. Розглянемо Лістінг 7, у якому зашифрований елемент GetSpecial Discounted Booking For Partners з Лістінгу 1 отриманий простою заміною елементом Encrypted Data.

Порівняємо елемент Encrypted Data з Лістінгу 6 з елементом Encrypted Data з Лістінгу 7. Неважко бачити, що мається одне розходження: замість атрибута Mime Type Лістінгу 6 у Лістінге 7 з'явився атрибут Type. Значення цього атрибута дорівнює http:///www.w3.org/2001/04/xmlenc#Element, що означає, що зашифровано XML-елемент.

Таким чином, при шифруванні елемента XML-файлу варто використовувати ідентифікатор http:///www.w3.org/2001/04/xmlenc#Element як значення атрибута Type. У цьому випадку одержувач зашифрованого XML-файлу буде знати, що зашифровані дані повинні інтерпретуватися як XML-елемент у розшифрованій простій текстовій формі.

.5.1 Шифрування змісту елемента

Розглянемо Лістінг 8, у якому зашифровано тільки зміст елемента GetSpecial Discounted Booking For Partners - для цього цей зміст був замінений структурою EncryptedData. Цей прийом схожий на шифрування елемента (див. Лістінг 7). Відмінність полягає в тому, що цього разу значення атрибута Type тега Encrypted Data дорівнює http://www.w3.org/2001/04/xmlenc#Content. Це значення говорить про те, що зашифровані дані повинні інтерпретуватися як зміст елемента.

.6 Обробка шифрування XML

Розглянемо, як брандмауер XML працює з поняттями шифрування. Брандмауер одержує Лістінг 7 або 8 (SOAP-повідомлення з зашифрованими елементами або змістом) і, перш ніж переслати SOAP-серверові розшифрований запит SOAP-повідомлення, перетворить їхній зміст у дешифровану форму.

Одержувач зашифрованого XML-файлу (наприклад, у нашому випадку брандмауер XML організації) розшифровує цей XML-файл, виконуючи наступну послідовність дій:

1.  Витягає зашифрований зміст елемента CypherValue;

2.      Зчитує значення атрибута алгоритму елемента EncryptionMethod;

.        Зчитує значення атрибута Type елемента EncryptedData;

.        Одержує інформацію про ключ з елемента ds:KeyInfo;

.        Використовує отриману інформацію для створення простого текстового (розшифрованого) файлу.

.7 Введення в безпеку Web-сервісів

Виникає питання, яким образом брандмауер XML використовує підписи і шифрування XML для захисту SOAP-серверів? Адже незважаючи на те, що можливості цих двох технологій були продемонстровані на численних прикладах, необхідно з'ясувати, як застосовувати ці дві специфікації при використанні брандмауера XML для захисту SOAP-серверів, особливо якщо врахувати жодна з них не є специфічною для SOAP. Спробуємо зрозуміти, чому вся інформація, що стосується підписи, була поміщена в заголовок SOAP, а не в тіло SOAP [3].

Специфікація консорціуму OASIS "Безпека Web-сервісів" докладно визначає, як застосовувати технології підпису і шифрування XML при обміні SOAP-повідомленнями. Цей стандарт одержує елементи низького рівня з розглянутих вище специфікацій ("Цифровий підпис XML" і "Шифрування XML") і задає високорівневий синтаксис для обгортання в SOAP-повідомленнях інформації про безпеку.

Специфікація "Безпека Web-сервісів" описує механізм безпечного обміну SOAP-повідомленнями. Вона забезпечує наступну функціональність:

1.  Цілісність повідомлення.

2.      Користувальницьку автентифікацію.

.        Конфіденційність.

Розглянемо Лістінг 9 - це SOAP-повідомлення, що несе інформацію про безпеку відповідно до синтаксису специфікації "Безпека Web-сервісів". Лістінг 9 - цей той же самий SOAP-запит GetSpecial Discounted Booking For Partners, що неодноразово приводився в цій статті. Однак цього разу заголовок запиту передає інформацію про цифровий підпис відповідно до розглянутої специфікації.

Щоб краще зрозуміти синтаксис специфікації "Безпека Web-сервісів", розглянемо Лістінг 9:

1.  Елемент SOAP:Envelope містить оголошення просторів імен для SOAP, "Безпека Web-сервісів" і "Цифрового підпису XML".

2.      В елемента SOAP:Header мається тільки один дочірній елемент (wsse:Security), що є обгорткою для всієї інформації про безпеку. В елемента wsse:Security два дочірніх елементи: wsse: Binary Security Token і ds:Signature.

Найбільш популярний і широко використовуваний маркер доступу - це пари логін-пароль, як та, що застосовується при перевірці електронної пошти.

Пари логін-пароль - це маркер доступу, призначений для людини. Існують маркери доступу, що мають бінарну форму (і, отже, можуть бути нечитабельні). Такі маркери називаються бінарними маркерами доступу. Наприклад, сертифікат X509 (дуже популярний формат цифрових сертифікатів, розроблений Міжнародним союзом електрозв'язку - сектора телекомунікацій (International Telecommunications Union - Telecommunications sector, ITU-T)) - це бінарний маркер доступу.

Атрибут ValueType елемента wsse: Binary Security Token містить інформацію про те, який тип бінарного маркера доступу загорнуть в елемент wsse: Binary Security Token. У Лістінгу 9 значення цього атрибута дорівнює wsse:X509v3, що означає сертифікат X509.

Атрибут Encoding Type елемента wsse: Binary Security Token показує, яка кодування в бінарного маркера доступу. Як уже відзначалося вище, бінарні дані не можуть бути загорнені у формат XML. Отже, вони повинні бути перетворені в даний формат (як правило, вони представляються в кодуванні base-64). Сертифікат X509 обернуть в елемент wsse: Binary Security Token як зміст цього елемента.

4.  Елемент ds:Signature точно такий же як і той, що був розглянутий раніше в розділі про підпис XML. Необхідно звернути увагу на наступні два моменти:

·  Значення атрибута URI (#myDiscount Request Body) елемента Reference є ідентифікатором фрагмента, що вказує на елемент SOAP: Body. Це означає, що елемент SOAP:Body - це той елемент, що вже був підписаний і обернуть у теги цифрового підпису XML.

·              В елемента ds:KeyInfo мається елемент wsse: Security Token Reference, що містить посилання на маркери доступу. У нашому випадку в нього є дочірній елемент wsse: Reference, атрибут URI якого вказує на елемент wsse: Binary Security Token, розглянутий у пункті 3 цього розділу. Це означає, що відкритий ключ у сертифікаті X509 (те, що обертає елемент wsse: Binary Security Token) використовується для перевірки підпису.

Розглянутий приклад дуже простий, він знайомить з підписаними повідомленнями захищених Web-сервісів.

Стандарт цифрового підпису XML-Signature Syntax and Processing розроблений W3C. Визначає синтаксис представлення цифрових підписів декількох видів і правила їхньої обробки, а також сервіси, що забезпечують цілісність даних (у тому числі документів XML, що утримуються в переданому повідомленні або де-небудь поза ним), установлення дійсності повідомлення і достовірності обличчя, що підписало повідомлення. Передбачаються можливості ідентифікації колекцій ресурсів, алгоритмів, ключів захисту інформації.

Прийняття Партнерством стандарту на оформлення електронно-цифрового підпису (ЕЦП) на XML-документи дозволить усім членам Партнерства обмінюватися підписаними електронними документами, захищеними ЕЦП і одноманітно формувати і перевіряти ЕЦП при різного роду електронних обмінах.

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

цифровий підпис криптографічний ключ

Висновок

Електронна комерція, що заявляється зараз, в Інтернеті насправді не відповідає потрібним вимогам. Реалізований тільки перший елемент - вітрина або ще простіше - дошка оголошень, на якій потенційний покупець може ознайомитися з асортиментом пропонованих до реалізації товарів і послуг.

Повномасштабний бізнес в електронному виді не реалізується по різних причинах.

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

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

·  відсутність методології побудови відкритих систем електронного бізнесу, у яких рівнозахищені всі учасники угод;

·              відсутність механізмів комплексної експертизи технологій електронного документообігу;

·              відсутність стандартів страхування ризиків електронної комерції, обумовлених некоректним застосуванням засобів електронного цифрового підпису.

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

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

• щоб керувати багаторазовим підписом;

• щоб видаватися у визнаному форматі, і при умовах, при яких вони приймають, і/або забезпечують електронні підписи.

Ця майбутня задача повинна "XML-орієнтуватися" і роз’яснити, що центри роботи з електронними підписами і їхнього керування і просто не зв'язані з діловими протоколами.

В існуючому документі, не була зроблена спроба проектування детальних технічних правил, що стосуються політики підпису. Очевидно, що могли бути кілька різних підходів, кожен заснований на деякому керівництві, і мати відношення до стандартів. Це забезпечило б ілюстрацію того, як принципи, описані в існуючій роботі, можуть бути застосовані, і забезпечити інструмент для того, щоб керувати XML підписами принаймні в одній діловій системі.

Список літератури

1. Touch Memory - новый электронный идентификатор /Монитор./ - 1992. - N 6. - с.26-30.

2. Безопасность персонального компьютера / Пер. с англ.; Худ. обл. М.В. Драко. - Мн.: ООО «Попурри», 1997. - 480 с.

3. Б. Шнаер. Прикладная криптография. Протоколы, алгоритмы, исходные тексты на языке Си. - М.: Издательство ТРИУМФ, 2002 - 816 с.: 816 с.

4. В.В. Шураков. Обеспечение сохранности информации в системах обработки данных (по данным зарубежной печати): Учебное пособие для вузов. - М.: Финансы и статистика, - 1985. - 224 с.

5. Д. Гроувер, Р. Сатер, Дж. Фипс и др. Защита программного обеспечения. // Пер. с англ. // Под редакцией Д. Гроувера - М.: Мир, - 1992. - 285 с.

6. Жельников В. Криптография от папируса до компьютера. - М.: ABF, 1996. - 336с.

7. Конев И.Р., Беляев А.В., Информационная безопасность предприятия. - СПб.: БХВ-Петербург, 2003. - 752 с.

8. Мельников В.В. Безопасность информации в автоматизированных системах. - М.: Финансы и статистика, 2003. - 368 с.

9. Микросхемы интегральные серии КР1531. - Санкт-Петербург: Издательство РНИИ "Электростандарт", - 1993. - 140 c.

10.О.Н. Лебедев. Применение микросхем памяти в электронных устройствах: Справ. пособие. - М.: Радио и связь, - 1994. - 216 c.

11.Петраков А.В. Основы практической защиты информации. - М.: Радио и связь, 1999. - 368 с.

12.Семейство БИС для шифровки цифровой информации. - Электроника, - 1977. - т. 50. - N 18. - с. 4-5.

13.Хорошко В.А., Чекатков А.А. Методы и средства защиты информации / Под ред. Ю.С. Ковтанюка - К.: Издательство Юниор, 2003. - 504 с.

14.Цифровые и аналоговые интегральные микросхемы: Справочник /С.В. Якубовский, Л.И. Ниссельсон, В.И. Кулешова и др;/ Под редакцией С.В. Якубовского. - М.: Радио и связь, - 1989. - 496 c.

15.Щеглов А.Ю. Защита компьютерной информации от несанкционированного доступа. - СПб.: Наука и техника, 2004. - 384 с.: ил.

16.Электронные ключи американской фирмы SOFTWARE SECURITY / Защита информации "Конфидент"/. - 1994. - N 1. - с.76-83.

17.Ю.В. Романцев, П.А. Тимофеев, В.Ф. Шаньгин. Защита информации в компьютерных системах и сетях / Под ред. В.Ф. Шаньгина/. - М.: Радио и связь, 1999. - 328 с.