Портал освітньо-інформаційних послуг «Студентська консультація»

  
Телефон +3 8(066) 185-39-18
Телефон +3 8(093) 202-63-01
 (066) 185-39-18
Вконтакте Студентська консультація
 portalstudcon@gmail.com

<script>

  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){

  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),

  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)

  })(window,document,'script','//www.google-analytics.com/analytics.js','ga');

 

  ga('create', 'UA-53007750-1', 'auto');

  ga('send', 'pageview');

 

</script>

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

Тип роботи: 
Дипломна робота
К-сть сторінок: 
66
Мова: 
Українська
Оцінка: 
ВСТУП
 
В рамках роботи європейських інститутів стосовно застосування електронного підпису потребують звернення до проблем, що стосуються окремих підписів, але дуже часто документи вимагають, щоб більше ніж один підпис давав цьому документові юридичну чинність або зробив угоду дійсною [1]. Вони можуть бути рівнозначними, незалежними підписами, типу таких, як підписи покупця і продавця в контракті, або вкладеними, в яких  другий  підпис ставиться поверх первинного підпису, прикладами яких є підпис свідка, або підпис начальника, який затверджує підпис підлеглого. Дотепер, політика підпису була визначена тільки для перевірки окремого електронного підпису. Однак, оскільки все більше  технологій  паперового документообігу переміщається в електронне  середовище,  зростає ділова потреба розширити цю політику з метою підтримки багаторазових підписів. Ця потреба спричинена повільним просуванням застосування  більш складних ділових угод, котрі вимагають запевняння не однієї людини, а декількох, або  виникають більш строгі вимоги щодо форматів цифрового підпису. Ці вимоги стосуються, наприклад, фінансових трансакцій споживачів або кредитних угод зі структурованими умовами щодо "оплати/постачання". Для того, щоб прискорити застосування подвійного підпису, необхідно якнайшвидше  створити підстави  для надання юридичної сили такому  підпису.
Є нагальна потреба перемістити всі особливості рукописного підпису у електронний світ, і розвивати еквівалентну довіру електронним підписам, особливо де вони вказують юридично обов'язкове зобов'язання. Однак, є багато характеристик підписів які поки що не покриваються існуючим законодавством, що викликає необхідність створення подальших нормативних документів щодо застосування електронних підписів.
Широка інтерпретація політики підпису може бути корисним інструментом для того, щоб визначити засіб для створення і перевірки всіх типових якостей рукописного підпису. Політика підпису може включати засоби  відтворення формальностей підписання, а саме: хто може підписатися, кількість підписів, що повинно бути підписано і при яких обставинах. Визначаючи область застосування, до якого політика підпису застосовується, можливо відтворити частину контекстної інформації, що є доречною для застосування підпису, як у паперовому світі. Оскільки ці фактори змінюються відповідно до обставин, у яких підпис повинен використовуватися, з цього випливає, що не можливо визначити всі сценарії. Дипломна робота аналізує деякі з факторів, що можуть бути зібрані, щоб організовувати політику підпису, що є доречною діловою специфічною потребою.
Правила використання підпису повинні взяти до уваги інтерфейс між людиною і комп'ютерною системою. Тільки людина може приймати рішення застосувати підпис чи ні. Це вірно, навіть коли підпис ґрунтується від імені організації або юридичної особи. Людина може керувати створенням підпису за допомогою прикладного інтерфейсу.
 
РОЗДІЛ 1. ОСНОВИ ЕЛЕКТРОННОГО ЮРИДИЧНО ЗНАЧИМОГО ДОКУМЕНТООБІГУ В ПРОЦЕСІ СТВОРЕННЯ ЦИФРОВОГО ПІДПИСУ
 
1.1 Використання схеми відкритих криптографічних ключів
 
Побудова систем електронного документообігу вимагає використання криптографічних засобів захисту інформації і використання апарата електронного цифрового підпису (ЕЦП). Апарат ЕЦП забезпечує можливість встановлення однозначної автентифікації (авторства) відправника електронного документа і забезпечення контролю незмінності документа після його підписання.
Для реалізації апарата ЕЦП використовуються асиметричні криптографічні ключі. Для кожного користувача системи, що приймають участь у повноформатному електронному документообігу, повинні існувати секретний ключ ЕЦП і зв'язаний з ним по криптографічних алгоритмах відкритий ключ ЕЦП. Секретний ключ ЕЦП забезпечує користувачеві можливість установки унікальної особистої ЕЦП під документами, що він може відправляти по комп'ютерній мережі. Відкритий ключ забезпечує можливість перевірки дійсності ЕЦП і авторства відправника. У такий спосіб кожен користувач електронного документообігу повинний мати особистий секретний ключ ЕЦП і усі відкриті ключі інших користувачів, що можуть відправляти електронні документи на його адресу.
Поширення відкритих ключів між учасниками електронного документообігу може здійснюватися по двох технологіях: корпоративно і відкрито.
Корпоративна технологія припускає наявність незалежного учасника електронного документообігу, що виконує роль Адміністрації системи ЕЦП і забезпечуючого формування довідників відкритих ключів учасників системи, їхнього розсилання і відновлення для кожного її учасника. Корпоративна технологія керування ключами характерна для організації корпоративних комп'ютерних мереж.
Відкрита технологія криптографічних ключів заснована на використанні цифрових сертифікатів (цифрових паспортів). Передбачається, що кожен учасник електронного документообігу має особистий цифровий паспорт, що включає ідентифікатори користувача і відкритий ключ цього користувача. Цифровий паспорт підписаний ЕЦП Сертифікаційного центра (незалежного довірчого органа, що здійснює запевняння і супровід цифрових паспортів), що забезпечує можливість контролю його дійсності і незмінності. Відкритий ключ сертифікаційного центра загальнодоступний і відомий всім учасникам системи.
При відправленні документа, користувач "пристиковує" до нього свій цифровий паспорт і підписує його своєю ЕЦП. При одержанні документа перевіряється дійсність і незмінність цифрового паспорта, шляхом перевірки під ним ЕЦП сертифікаційного центра, витягається з нього відкритий ключ відправника і на основі його перевіряється ЕЦП відправника під отриманим документом.
Відкрита схема не вимагає формування і відновлення довідників відкритих ключів, тому що відкритий ключ відправника попадає до одержувача разом з електронним документом. Відкрита схема поширення ключів характерна для відкритих мереж, хоча також може успішно використовуватися й у корпоративних комп'ютерних мережах. Відкрита схема вимагає наявності Сертифікаційного центра (СЦ) і центрів видачі цифрових паспортів.
Відкрита схема поширення відкритих криптографічних ключів є більш перспективною. Це обумовлюється тим, що, у перших, забезпечується більш просте керування ключами і не потрібно підтримувати довідники відкритих ключів, обсяг яких, у загальному випадку, пропорційний кількості учасників системи електронного документообігу, і в других, при введенні національних стандартів на види цифрових паспортів, протоколи безпечної передачі інформації і програмних криптографічних засобів (чому учить закордонний досвід), кінцевий користувач, що має один цифровий паспорт і один секретний ключ ЕЦП може брати участь у різних системах електронного документообігу. Наприклад таких, як податкова інспекція, пенсійний фонд, здійснення комунальних платежів, використання електронних магазинів і т.д.
 
1.1.1 Основні функції Адміністрації системи ЕЦП у корпоративних мережах 
Основними функціями Адміністрації системи ЕЦП є:
1.Висновок договорів на обслуговування в системі електронного документообігу, юридична експертиза договірної документації;
2.Опис параметрів користувачів у системі електронного документообігу;
3.Здійснення ключового керування в системі;
4.Здійснення заходів щодо забезпечення безпечної експлуатації системи;
5.Забезпечення технічної і технологічної експертизи при виникненні конфліктних ситуацій між учасниками електронного документообігу, організація процедури узгодження розбіжностей;
6.Ліцензійний супровід експлуатації криптографічних засобів;
 
1.1.2 Основні функції Центра видачі цифрових паспортів і СЦ у відкритих мережах
Центр видачі цифрових паспортів:
1.Перевірка дійсності реєстраційних документів юридичних осіб, що заявили про бажання одержати цифровий паспорт;
2.Автоматизоване введення даних для формування цифрового паспорта;
3.Відправлення ЦП по корпоративній мережі в СЦ для його запевняння 
4.електронним цифровим підписом СЦ;
5.Видача завіреного цифрового паспорта кінцевому користувачеві;
6.Облік і архівне збереження виданих цифрових паспортів.
Центр сертифікації:
1.Виконує функції запевняння своїм електронним цифровим підписом і реєстрацію цифрових паспортів, одержуваних від центрів їхньої видачі;
2.Здійснює керування цифровими паспортами;
3.Реалізує запити кінцевих користувачів на перевірку дійсності (перевірка дійсності ЦП, терміну його дії, відсутності в списку відкликаних ЦП);
4.Поширює інформацію про відкликані цифрові паспорти.
 
1.1.3 Використання електронного цифрового підпису в інформаційних технологіях
Web-технології стали в даний час одними з найбільше широко використовуваними в мережі Інтернет механізмом обміну і надання інформації. Однак, як і в більшості рішень, що одержали поширення в Інтернет, питання безпеки при виробленні концепції і реалізації використовуваних у 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) 
Сертифікат сервера дозволяє упевнитися в дійсності сервера - абстрактного ресурсу. 
Персональний сертифікат служить для ідентифікації клієнтів на ресурсі. За допомогою персональних сертифікатів можна забезпечити набагато більш високий рівень безпеки при розмежуванні доступу на сервер, чим за допомогою інших механізмів. 
СА сертифікат. Сертифікат ЗЦ служить для перевірки дійсності самого ЗЦ. З його допомогою підписуються сертифікат сервера і персональний сертифікат. Він повинний зберігатися на сервері і на клієнтській машині, для того щоб сервер і клієнтський додаток могли перевірити дійсність підписаних їм ЗЦ сертифікатів.
 
1.2 Робота Засвідчуючого Центру сертифікатів та ключів підпису
 
"Засвідчуючий Центр сертифікатів та ключів підпису" є ключовим компонентом для різного типу прикладних захищених систем корпоративного рівня (захищений документообіг, Інтернет-банкінг, білінгові системи, електронна комерція, Інтернет процесінг і.т.п.), що використовує технології інфраструктури з відкритими ключами (PKI). 
Центр корпоративної інформації, засвідчує, системи виконані як довірені (може поставлятися з вихідними кодами) сервіс на Unix системах (FreeBSD, Linux) і забезпечує: 
1.Реєстрацію й обслуговування запитів користувачів на створення цифрового сертифіката. Створення за заявою користувача секретного і відкритого ключів. Спосіб доставки інформації про власника сертифіката і формат запиту визначається регламентом експлуатації конкретного ЗЦ.
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). 
Для довірених систем у яких потрібно використовувати сертифіковані операційні системи, існує спеціальний варіант постачання ЗЦ побудований на захищеній інтегрованій системі (на основі ALT Linux) обробки конфіденційної інформації.
5.Технічну підтримку при проведенні розбору конфліктних ситуацій. ЗЦ забезпечує ведення завіреної "історії життя" сертифіката. Будь-яка подія, будь те централізоване ухвалення рішення про випуск сертифіката або зміна статусу уже випущеного сертифіката, оформляється у виді спеціального запису (у форматі CMC (RFC 2797)) у "історії" сертифіката і має ЕЦП ініціатора ухвалення рішення. Взаємозалежні CMC запису визначають усю "історію життя" сертифіката. Даний підхід дозволяє, аргументовано вирішувати задачі арбітражу і використовувати ЗЦ у системах, де ухвалення рішення вимагає проведення спеціальних організаційно технічних заходів групи офіцерів безпеки. 
6.Додатково ЗЦ забезпечує: 
•Підтвердження дійсності електронного цифрового підпису на електронному документі у відношенні виданих ЗЦ сертифікатів. 
•Формування "штампа часу" на електронному документі. 
•Надання публічного сервісу - "Служби часу ЗЦ". 
 
1.3 Структурна схема ЗЦ
 
ЗЦ є програмно - апаратним комплексом, що виконує функції формування сертифіката ключа підпису. Ключі можуть створюватися як зовні на відповідному програмному забезпеченні користувача, так і засобами ЗЦ. Носієм інформації про випущений сертифікат виступає відчужуваний носій (Floppy Disk, або інший носій, використання якого визначається специфікою автоматизованої системи). 
ЗЦ спроектований і повинний експлуатуватися, як довірена, замкнута, автоматизована система, що модифікується не. Під замкнутістю розуміється неможливість впливу на склад і компоненти системи іншим способом, крім як визначеним регламентом образом. Під немодифікованістю розуміється відсутність у системі засобів розробки прямо або побічно впливають на функціональну однозначність виконуваних процедур. 
ЗЦ побудований по модульному принципі і містить у своєму складі наступні компоненти (підсистеми): 
 
Рис. 1.1 Структурна схема ЗЦ
 
Підсистеми ЗЦ виконані з захистом від НСД. Контроль за незмінністю програмного середовища здійснює спеціалізований сервіс, що конфігурується при інсталяції ЗЦ і веде робочі журнали контролю цілісності ПО, доступ до яких має обслуговуючий персонал ЗЦ. 
 
1.4 Приклади побудови систем заснованих на інфраструктурі відкритих ключів
 
Однією з технологій, що дозволяє вирішити більшість проблем зв’язаних з безпекою в комп’ютерних мережах, є інфраструктура відкритих ключів. 
За допомогою інфраструктури відкритих ключів вирішуються наступні задачі: 
Забезпечення приховання переданої інформації. 
Забезпечення цілісності цієї інформації, тобто захист від модифікації. Існують технічні рішення, що дозволяють розміщати на серверах ресурсу завірену інформацію, має електронний цифровий підпис, перевірка якого (у тому числі й у ON-LINE) дозволяє підтвердити цілісність і авторство розміщеної інформації. 
Забезпечення автентифікації ресурсу, тобто доказ того, що ресурс є саме тим, за кого він себе видає. 
Забезпечення автентифікації користувачів при доступі до ресурсу. 
Узявши за основу ці корисні властивості, реалізовані в системі, можна побудувати систему захищеного електронного документообігу, у якій поняття документообігу багато ширше чим простий рух наказів або листів усередині організації. 
 
Рис. 1.2 Система захищеного електронного документообігу
 
Запропонована схема дозволяє вирішити IT задачі організацій фактично будь-якого профілю, а використання типових стандартних рішень роблять розробки прозорими для розуміння й аналізу.
 
1.5 PKCS#10. Запит на створення сертифіката з локальною генерацією ключової пари
 
Такий вид запиту призначений для створення сертифіката з локальної генерації ключів і формування запиту у форматі PKCS#10. Такий запит припускає генерацію ключової пари, тому при реальній експлуатації набирають сили обмеження Ліцензійної угоди. 
Далі користувачем заповнюється запропонований ланцюжок форм, деякі полючи в аркушах ланцюжка є недоступними для даного виду запиту. 
Якщо у формі майстра запитів був зведений додатковий прапор "Зробити перевидання існуючого сертифіката" (сертифікат повинний мати статус - Особисті сертифікати), то дані будуть включені в запит зі складу обраного сертифіката. Такий режим корисний для систем, у яких регламентом допускається перевидання власних сертифікатів самостійно самим користувачем, минаючи службу Адміністраторів взаємодії з користувачами. 
1.необхідно вказати яким сертифікатом ЗЦ буде завірений сертифікат, для якого готується запит (від якого кореня буде видаватися даний сертифікат);
2.необхідно вказати для яких задач буде використані створюваний сертифікат і визначити (додаткова функція "Редагувати") області і порядок застосування сертифіката, для яких його використання буде вважатися дійсним; 
3.визначити для якого криптографічного алгоритму буде локально створена ключова пара з наступним розміщенням цієї інформації в запиті. Як уже раніше відзначалося, ПО має модульну структуру підтримуваних алгоритмів і користувач у праві вибрати кожної на свій розсуд; 
4.вказується інформація (загального і додаткова) про власника цифрового сертифіката;
5.на цьому етапі відбувається генерація ключової інформації - операція ресурсномісткої і тривала за часом із усієї введеної інформації підготовляється запит і користувачеві дається можливість перевірити введені дані і при необхідності, повернувши по кроках назад, змінити помилково введену інформацію. 
Запис про запит виду PKCS#10 не повинна віддалятися з бази "Запити в ЗЦ" доки, не буде отримана відповідь зі служб ЗЦ і на клієнтському робочому місці не буде згрупована (процедура автоматична або в ON-LINE). Персональний сертифікат (секретний ключ, що не залишав робочого місця і відповідний йому, завірений сертифікат з відкритим ключем). 
Теоретично можлива така ситуація, при якій запит на створення сертифіката саме для даного відкритого ключа може бути відхилений. Таке поводження ЗЦ порозумівається тим, що ЗЦ при створенні сертифіката забезпечує "унікальність відкритих ключів". Самі ключі були створені локально (ЗЦ не керує даною процедурою) на робочому місці користувача і малоймовірно, але теоретично можливо, що два користувачі незалежно друг від друга створили однакові відкриті ключі - така ситуація для PKI систем є неприпустимою. У цьому випадку користувач повинний зробити повторне формування PKCS#10 запиту і передачу його службам ЗЦ з наступним формуванням сертифіката відкритого ключа на ЗЦ. 
Якщо формування запиту здійснюється користувачем самостійно, то на цьому етапі формування запиту закінчується. Користувачеві необхідно (не зводячи прапор відправлення запиту в ЗЦ) зробити Експорт запиту з бази запитів і на транспортному носії доставити в служби ЗЦ.
Якщо процедура відправлення запиту, його обробки і доставці на АП пройшла, то після візуалізації змісту завіреного сертифіката, користувач установлює його в локальне сховище. Автоматично відбувається прив'язка з раніше локально створеною ключовою інформацією й у результаті сертифікат розміщається в базі "Особисті сертифікати" 
З цього моменту можна користуватися знову створеним сертифікатом. Використання PKCS#10 запиту не є безпечним (мається на увазі не безпека ключової інформації, а істинність введеної інформації про суб'єкта) для ON-LINE режиму - користувачі самостійно заповнюють інформаційну частину сертифіката без контролю Адміністратора взаємодії з користувачами. Порозумівається це тим, що сам PKCS#10 має ЕЦП на ключі який тільки що був локально створений і про нього "нічого не знають" служби ЗЦ, інформацію, що знаходиться усередині запиту і підписану на "раніше невідомому для ЗЦ" ключі неможливо змінити - порушиться цілісність запиту, тому те, що було введено при заповненні форм майстри запиту, є винятковою відповідальністю користувача (і формально може суперечити політиці безпеки PKI системи в цілому), що є потенційною погрозою для всієї PKI системи. Дата дії сертифіката, отриманого на такий запит, проставляється автоматично й обчислюється як поточна дата плюс один рік. Для прийняття хоч яких те заходів для забезпечення істинності й адресності переданого в режимі ON-LINE запиту використовується захищений транспортний протокол TLS з авторизацією по персональному сертифікаті в момент утворення з'єднання, однак CMC запис, утворений з PKCS#10 запиту в базі "історій" сертифікатів на ЗЦ не буде (і технічно не може) мати ЕЦП адміністратора, що відповідальний за інформацію представлену в запиті, що може викликати значні труднощі при розборі можливих конфліктних ситуацій зв'язаних саме з цим сертифікатом у службі Арбітражу ЗЦ. 
Більш безпечної є режим ON-LINE перевидання власного сертифіката, при якому інформаційна частина витягається з уже перевіреного Службою адміністраторів ЗЦ сертифіката, а сама CMC запис має ЕЦП раніше виданого діючого сертифіката користувача.
 
1.6 Запит на створення сертифіката з генерацією ключової пари в ЗЦ
 
На відміну від запиту у форматі PKCS#10 даний вид запиту позбавлений описаних вище недоліків, більш того він дозволяє описати вимогу на створення ключової інформації засобами (сертифікованими) ЗЦ. 
Форми, пропоновані до заповнення Адміністратором ЗЦ по представленню інформації кінцевого користувача майже аналогічні з формами запиту PKCS#10. Користувачем заповнюється запропонований ланцюжок форм, деякі полючи в аркушах ланцюжка є недоступними для даного виду запиту. 
Якщо у формі майстра запитів був зведений додатковий прапор "Зробити перевидання існуючого сертифіката" (сертифікат повинний мати статус - Особисті сертифікати), то дані будуть включені в запит зі складу обраного сертифіката. Такий режим корисний для систем, у яких регламентом допускається перевидання власних сертифікатів самостійно самим користувачем минаючи службу Адміністраторів взаємодії з користувачами. 
1.необхідно вказати яким кореневим сертифікатом ЗЦ буде завірений сертифікат, для якого готується запит (від якого кореня буде видаватися даний сертифікат);
2.необхідно вказати сертифікат з бази "Особисті сертифікати", ключ якого буде брати участь у виробленні ЕЦП на CMC запиті, тобто сертифікат Адміністратора;
3.необхідно вказати для яких задач буде використані створюваний сертифікат і визначити області і порядок застосування сертифіката, для яких його використання буде вважатися дійсним;
4.Адміністратор може керувати періодом дії створюваного сертифіката. Але в будь-якому випадку період дії сертифіката не може перевищувати дати припинення дії кореневого сертифіката ЗЦ, від якого видається користувальний сертифікат. 
На цьому кроці Адміністратор може визначити мітки мандатної політики розмежування доступу, їхній рівень. Види доступу і максимальний рівень доступу визначені в кореневому сертифікаті, від якого видається користувальний сертифікат. 
Адміністратор може створювати сертифікати інших адміністраторів із указівкою спеціальних мандатних міток. Автоматично відслідковується ланцюжок підпорядкування значень міток, не можна створити мітку, зі значенням перевищуючому або рівним значенню мітки в кореневому сертифікаті видавця або мітки із сертифіката Адміністратора, що підписує поточний CMC запит. Молодші розряди Ідентифікатора політики розмежування доступу можуть вводиться в додатковому вікні через роздільник "+". У системі зареєстровані два молодших розряди: 
1.Сертифікати адміністратора з даною міткою можуть бути використані тільки для запевняння сертифікатів. 
2.Сертифікати адміністратора з даною міткою можуть бути використані тільки для керування статусом користувальних сертифікатів. 
Якщо кореневий сертифікат видавця не має у своєму складі мандатної мітки, то при спробі "Редагувати" на екрані буде отримане відповідне попередження. 
5.визначити для якого криптографічного алгоритму буде локально створена ключова пара з наступним розміщенням цієї інформації в запиті. У цьому режимі неактивними є форми на вибір локального токену, у якому буде відбуватися генерація, оскільки генерація ключового матеріалу відбувається засобами ЗЦ, а не Абонентського Пункту. 
6.Указати пароль, що буде брати участь у шифруванні (розшифрування) секретного ключа створеного засобами ЗЦ зі складу в наслідку отриманого сертифіката. При введенні пароля автоматично перевіряється мінімально припустима довжина (6 символів) і відповідність пароля, що повторно вводиться. Адміністратор повинний забезпечити умови, при яких власноручно введений користувачем пароль залишився б винятково секретом користувача. Адміністратор повинний ознайомити користувача з матеріалами дійсного керівництва. Технологія захисту введеного пароля при транспортуванні запиту/відповіді по каналах зв'язку і між компонентами ЗЦ до КП) зі складу ЗЦ заснована на асиметричному шифруванні введеного пароля користувача на відкритому ключі КП ( що використовується винятково для цих цілей). 
7.Вказується інформація (загального і додаткова) про власника цифрового сертифіката. 
8.Адміністраторові надається можливість увести додаткову технологічну інформацію, що не буде включена до складу сертифіката, але буде утримуватися в CMC запису, що входить у "історію" даного сертифіката. Основне призначення цієї форми - введення атрибутів документів підтверджуючу персональну інформацію про суб'єкта або прив'язки суб'єкта до формальних вимог реальної PKI системи, у якій планується використовувати сертифікати. 
Формат коментарів може бути визначений зовнішнім шаблоном, наприклад паспортними даними, якщо політика безпеки системи допускає збереження такого роду інформації. 
9.з усієї введеної інформації підготовляється запит і користувачеві дається можливість перевірити введені дані і при необхідності, повернувши по кроках назад, змінити помилково введену інформацію. 
Завершення процедури формування запиту приводить до розміщення запиту в базі "Запити в ЗЦ" поза залежністю зведений прапор доставки в ЗЦ чи ні. 
При мережній доставці запиту в ЗЦ, якщо по яким або причинах запит не зміг бути оброблений у режимі ON-LINE, те користувач одержує про даний факт повідомлення, і наступні дії відбуваються вручну (функція "Одержати відповідь" у базі "Запити в ЗЦ"). 
Якщо процедура відправлення запиту, його обробки і доставці на АП пройшла, то після візуалізації змісту завіреного сертифіката, користувач установлює його в локальне сховище в базу "Особисті сертифікати", попутно буде запитаний пароль, що брав участь у захисті секретного ключа при транспортування по каналах і між компонентами ЗЦ. З цього моменту можна користуватися знову створеним сертифікатом. 
Якщо планується зберегти сертифікат разом із ключами на зовнішньому носії або USB токену, наприклад, для передачі його від Адміністратора користувачеві, варто використовувати функцію. У представленому вікні вибирається транспортний пристрій і відбувається експорт сертифіката. 
Користувач, одержавши відчужуваний носій зі своїм персональним сертифікатом на своєму робочому місці в базу "Особисті сертифікати". І по виконанні процедури Імпорту встановленим сертифікатом користуватися для вироблення власної ЕЦП на електронних документах і проходження процедур автентификації при організації захищених з'єднань. 
Для одержання твердої копії сертифіката на паперовому носії  варто скористатися функцією "Сертифікати" з форми "Відповідь ЗЦ".
 
1.7 Перевірка дійсності ЕЦП на реальний момент часу
 
Перевірка дійсності ЕЦП на реальний момент часу реалізований на основі рекомендацій RFC 3029 по роботі зі спеціалізованим сервісом "Електронного нотаріуса". Основна форма пропонує висновок відсортованих запитів (або запитів у зв'язуванні з DVC квитанціями) по фільтру - ім'я сервера DVCS. З операцій над записами доступні: 
Новий запит:
Ініціює майстер DVC заявок на перевірку ЭЦП;
Одержати відповідь із сервера на відзначену заявку;
Відкрити відзначену заявку або квитанцію;
Видалити запит цілком (у зв'язуванні з квитанцією) або тільки квитанцію;
Експортувати DVC заявку або квитанцію. 
 
1.8 COM – технологія
 
  COM - це Component Object Model - компонентна об'єктна модель. Суттю використання даної технології є те, що програми будуються з компонентів, що складаються з об'єктів, і доступ до зареєстрованих об'єктів Криптографічного Центра (КЦ) на обробку завірених документів стає доступний як з HTML форм, так і з інших програм установлених на комп'ютері користувача. 
ЕЦП HTML форми;
інтеграція с пакетом Microsoft Office.
 
1.9 ЕЦП HTML форми
 
Використання COM об'єктів зі складу ПО для виконання процедур вироблення і перевірки електронного цифрового підпису над інформацією з HTML форм дозволяє ефективним образом вирішити багато задач з областей, що базуються на Web-технологіях, таких як, вилучене керування електронними платежами (системи типу "Банк-Клієнт") і будь-яких інших, де необхідно авторизований запит із завіреними даними на обслуговування, наприклад системи електронної торгівлі, різні системи керування об'єктами, платного інформаційного забезпечення, різні платіжні і т.п. Дана технологія приносить у такого роду системи цілий ряд нових властивостей: 
Стругаючи взаємна автентифікація користувача і ресурсу на основі цифрового сертифіката. 
Проведення в ON-LINE вироблення і перевірки ЕЦП над блоком інформації. 
Конфіденційність, авторство, цілісність і невідмовність завіреної інформації транспортується по відкритих мережах (Інтернет). 
Як ілюстрацію, на використанні COM побудований інтерфейс інформаційної підтримки розбору конфліктних ситуацій у Центрі Арбітражу ЗЦ. 
Якщо існує технологічна необхідність робити відправлення підписаного документа по захищеному протоколі, варто описати в настроюваннях ПО даний сервер (XXX) у списку захищених ресурсів. 
У приведеному прикладі відпрацьовують COM об'єкти зі складу ПО роблячи вироблення ЕЦП над змістом і розміщенням CMS документа утримуючого і дані і саму ЕЦП у схованому полі, якому можна переправити на Web-сервер. При виробленні ЕЦП, ПО дозволяє локально зберегти підготовлений до відправлення на сервер CMS документ, що забезпечує інформаційну підтримку користувача при розборі можливих конфліктів у системі. На стороні сервера може бути зроблена перевірка локально підготовленого CMS документа і реалізований функціонал прикладної автоматизованої системи того або іншого призначення.
Отже основними функціями сертифікаційних центрів є забезпечення користувачів сертифікатами що дозволяють забезпечити як конфіденційність своїх даних так і підтвердити їхню цілісність при передачі інформаційними каналами зв'язку. В даний час швидкий розвиток інформаційних технологій вимагає забезпечення усе більше людей сертифікатами, саме тому зростає кількість устаткування, програмного забезпечення що дозволяє одержати їх. Також розвиваються і кількість протоколів тому протоколи різних видів будуть у подальшому розвиватися, знаходячи своїх нових користувачів, у той час як інші протоколи будуть заповнювати білі плями в секторі протоколів безпечної передачі даних в Інтранет-мережах, залишені попередніми учасниками.
 
РОЗДІЛ 2. ВИКОРИСТАННЯ ЕЛЕКТРОННОГО ЦИФРОВОГО ПІДПИСУ У ЕЛЕКТРОННОМУ ДОКУМЕНТООБІГУ
 
2.1 Електронний цифровий підпис у електронному документообігу
 
Відомо, що вміст будь-якого документа (файлу) представлено в комп'ютері як послідовність байтів і тому може бути однозначно описано визначеним (дуже довгим) числом або послідовністю декількох більш коротких чисел. Щоб «покоротшати» цю послідовність, не втративши її унікальності, застосовують спеціальні математичні алгоритми, такі як контрольна сума (control total) або хеш-функція (hash function). Якщо кожен байт файлу помножити на його номер (позицію) у файлі й отримані результати підсумовувати, то вийде більш коротке, у порівнянні з довжиною файлу, число. Зміна будь-якого байта у вихідному файлі змінює підсумкове число. На практиці використовуються більш складні алгоритми, що виключають можливість уведення такої комбінації перекручувань, при якій підсумкове число залишилося б незмінним. Хеш-функція визначається як унікальне число, отримане з вихідного файлу шляхом його «обрахування» за допомогою складного, але відомого (відкритого) алгоритму. Один з цих алгоритмів закріплений у ГОСТ Р 34.11-94 «Інформаційна технологія. Криптографічний захист інформації. Функція хешування».
Тепер розглянемо, як виходить електронний підпис. Тут потрібне невеликий відступ. З древніх часів відомий криптографічний метод, пізніше названий шифруванням за допомогою симетричного ключа, при використанні якого для зашифровування і розшифровування служить той самий ключ (шифр, спосіб). Головною проблемою симетричного шифрування є конфіденційність передачі ключа від відправника до одержувача. Розкриття ключа в процесі передачі рівносильною розкриттю документа і наданню зловмисникові можливості його підробити.
У 70-х рр. був винайдений алгоритм асиметричного шифрування. Суть його полягає в тому, що зашифровується документ одним ключем, а розшифровується іншим, причому по першому з них практично неможливо обчислити другий, і навпаки. Тому якщо відправник зашифрує документ секретним ключем, а публічний, або відкритий, ключ надасть адресатам, то вони зможуть розшифрувати документ, зашифрований відправником, і тільки ім. Ніхто інший, не володіючи секретним ключем відправника, не зможе так зашифрувати документ, щоб він розшифровувався парним до секретного відкритим ключем.
Відправник, обчисливши хеш-функцію документа, зашифровує її значення своїм секретним ключем і передає результат разом з текстом документа. Одержувач по тім же алгоритмі обчислює хеш-функцію документа, потім за допомогою наданого йому відправником відкритого ключа розшифровує передане значення хеш-функції і порівнює обчислене і розшифроване значення. Якщо одержувач зміг розшифрувати значення хеш-функції, використовуючи відкритий ключ відправника, то зашифрував це значення саме відправник. Чужий або перекручений ключ нічого не розшифрує. Якщо обчислене і розшифроване значення хеш-функції збігаються, то документ не був змінений. Будь-яке перекручування (навмисного або ненавмисне) документа в процесі передачі дасть нове значення хеш-функції, що обчислюється одержувачем,, і програма перевірки підпису повідомить, що підпис під документом невірний.
Таким чином, на відміну від власноручного підпису, ЕЦП нерозривно зв'язана не з визначеною особою, а з документом і секретним ключем. Якщо дискетою з вашим секретним ключем заволодіє хтось іншої, то він, природно, зможе ставити підпису за вас. Однак вашу ЕЦП не можна перенести з одного документа на який-небудь інший, її неможливо скопіювати, підробити — під кожним документом вона унікальна. Процедури збереження, використання, відновлення і знищення ключів досить докладно розписані в різних методичних рекомендаціях до систем ЕЦП.
 
2.2 Шифрування асиметричними ключами
 
Розглянемо шифрування інформації асиметричними ключами. Якщо поміняти ключі місцями, іншими словами, секретним зробити ключ розшифровування, а відкритим (публічним) - ключ зашифровування, то відправник може зашифрувати лист відкритим ключем одержувача, і тоді прочитати лист зуміє лише той, у кого мається парний секретний ключ, тобто тільки сам одержувач. Велика перевага асиметричної схеми шифрування в тім і полягає, що відпадає необхідність у конфіденційній передачі ключів. Відкритий ключ можна зробити доступним на Web-сайті, передати по електронній пошті і т.п., не побоюючись негативних наслідків доступу до нього третіх осіб.
Для зручності шифрування і використання ЕЦП у корпоративних системах з великим числом абонентів застосовуються довідники відкритих ключів. Кожен ключ має тіло і номер, однаковий для секретної і відкритої частин ключа й унікальний для кожного абонента. Номер передається у відкритому виді в заголовку зашифрованого документа або в заголовку ЕЦП. Одержувач по цьому номері з відповідного довідника вибирає сам ключ, що підставляється в процедуру розшифровування або перевірки підпису. Виконується така вибірка, як правило, за допомогою спеціальних програм, і вся процедура займає частки секунди.
 
2.3 Керування ключовою системою
 
Важливу роль у системі електронного документообігу грає адміністрація системи. Вона забезпечує контроль за дотриманням абонентами єдиних правил роботи, бере участь у розборі конфліктних ситуацій, керує ключовою системою і, що дуже важливо, підтримує у всіх абонентів довідники відкритих ключів в актуальному стані. Довідники міняються регулярно: при будь-якій зміні списку учасників, при заміні яких-небудь ключів. Необхідність заміни ключів виникає, скажемо, у випадку їхньої компрометації - під цим розуміють ряд подій, при яких ключова інформація стає недоступної або виникає підозра про несанкціонований доступ. До таких подій відносяться втрата ключових дискет; утрата дискет з наступним виявленням; ушкодження дискет; звільнення співробітника, що мав доступ до ключової інформації; порушення правил збереження і знищення (після закінчення терміну дії) секретних ключів і ін.
При виникненні подібної події учасник системи зобов'язаний негайно повідомити адміністрацію системи (або її підрозділ - центр керування ключовою системою) про факт компрометації. У свою чергу, адміністрація повинна блокувати відкритий ключ учасника в довіднику і сповістити об цьому інших учасників (обновити в них довідники). Фіксація моменту повідомлення адміністрації про компрометацію ключів дуже важлива. Дійсними вважаються тільки ті документи учасника, що були отримані до цього моменту. Даний факт враховується при розборі конфліктних ситуацій: насамперед проводиться перевірка, чи був ключ відправника діючої на момент одержання документа адресатом.
У тому випадку, коли в корпоративній системі документообігу передбачений обмін електронними документами лише між центром (банком, брокерською фірмою, холдингом) і його клієнтами, клієнтам досить знати тільки один відкритий ключ ЕЦП цього центра, останній же використовує довідник відкритих ключів усіх клієнтів. Якщо ж у системі передбачена можливість обміну електронними документами між абонентами прямо, то довідники з переліками відкритих ключів повинні бути у всіх учасників і обновлятися одночасно.
 
2.4 Створення пакету документів
 
Організація системи електронного документообігу не зводиться до установки програмного забезпечення. Значно більш складним і трудомістким процесом (принаймні, на початковому етапі) є підготовка документів, що докладно описує всі процедури функціонування системи, а також навчання співробітників, що будуть забезпечувати її роботу. Спрощує ситуацію те, що зразки подібних документів вже існують і можна замовити розробку всього пакета компанії, що має досвід успішного застосування ЕЦП. Ідеально, якщо ці документи пройшли «перевірку боєм», тобто на їхній основі розглядався конфлікт у суді. Адміністрацію системи можна організувати на базі сторонньої фірми, що розташовує відповідними службами, кваліфікованими співробітниками, необхідними комплектами договорів, визначеним досвідом обслуговування таких систем. Ризик розкриття конфіденційної інформації при цьому відсутній, оскільки секретними ключами учасників адміністрація не володіє - вона оперує тільки довідниками відкритих ключів. Важливо, щоб генерація ключів (включаючи секретні) проводилася уповноваженими співробітниками учасників (нехай і на території ліцензованої адміністрації.
 
2.5 Проблеми поширення сертифікатів відкритих ключів
 
Рішенням проблеми поширення сертифікатів відкритих ключів серед усіх зацікавлених у цьому осіб є участь в електронному документообігу треті, незалежної, сторони, що здійснює реєстрацію і наступне поширення відкритих ключів учасників електронного документообігу. Такою третьою стороною є ЗЦ відкритих ключів.
Для здійснення своїх функцій ЗЦ веде спеціальний реєстр, у якому утримується інформація про всіх зареєстрованих у ЗЦ відкритих ключах. При звертанні будь-якої особи з метою посвідчення відкритого ключа якого-небудь електронного цифрового підпису ЗЦ видає Сертифікат, у якому утримується інформація про самий відкритий ключ, про власника даної ЕЦП, інформація про період, протягом якого діє ЕЦП, інформація про накладений власником даної ЕЦП обмеженнях на область її застосування.
Послуги ЗЦ, надані за допомогою Інтернету, здійснюються автоматизованими комп'ютерними системами, тому доступ до таких послуг надається всі 24 години на добу без яких-небудь перерв або вихідних. При цьому послуги по посвідченню відкритих ключів ЕЦП надаються центрами будь-якому бажаючий і на безоплатній основі. Заробляють на своє існування центри за рахунок зборів із власників ЕЦП за здійснення процедур реєстрації відкритих ключів, а також надання інших платних послуг.
Як уже раніше вказувалося, електронний Сертифікат виробляється автоматизованою системою ЗЦ при надходженні відповідного запиту. Для того, щоб виключити можливість підробки, електронний Сертифікат завіряється електронним цифровим підписом ЗЦ. Перевірка електронного цифрового підпису ЗЦ здійснюється за допомогою відповідного відкритого ключа. Відкритий ключ електронного цифрового підпису ЗЦ повинний бути загальновідомим, з цією метою він повинний періодично публікуватися у відповідних друкованих виданнях, а також утримуватися на інформаційному сайті самого ЗЦ. Відкритий ключ електронного цифрового підпису ЗЦ повинний також вказуватися у виданої відповідним державним органом ЗЦ ліцензії.
ЗЦ несуть відповідальність за збитки, понесені користувачем відкритого ключа в результаті довіри до представленого в Сертифікаті інформації, у випадку, якщо вона не відповідає дійсності. Тому надання саме достовірної інформації є основою діяльності ЗЦ.
Таким чином, розроблені процедури діяльності ЗЦ повною мірою забезпечують вимоги щодо безпеки проведення ідентифікації учасників електронного документообігу. Здійснення процедур реєстрації, поширення й ідентифікації відкритих ключів не самими учасниками електронного документообігу, а незалежною третьою стороною, що діє привселюдно, по суті справи, рятує учасників електронного документообігу від тієї рутинної роботи, що зв'язана зі здійсненням даних процедур. До того ж здійснення даних процедур ЗЦ переводить правовідносини, зв'язані з поширенням відкритих ключів, з приватно-правової площини в публічну.
 
2.6 Асиметричні алгоритми шифрування
 
Розвиток основних типів криптографічних протоколів (ключовий обмін, (ЕЦП), автентификація й ін) було б неможливо без створення відкритих ключів і побудованих на їхній основі асиметричних протоколів шифрування.
Основна ідея асиметричних криптоалгоритмів полягає в тому, що для шифрування повідомлення використовується один ключ, а при розшифровані - іншій. Крім того, процедура шифрування обрана так, що вона необоротна навіть по відомому ключі шифрування - це друга необхідна умова асиметричної криптографії. Тобто, знаючи ключ шифрування і зашифрований текст, неможливо відновити вихідне повідомлення - прочитати його можна тільки за допомогою другого ключа - ключа розшифрування. А раз так, то ключ шифрування для відправлення листів якій-небудь особі можна взагалі не ховати - знаючи його все рівно неможливо прочитати зашифроване повідомлення. Тому, ключ шифрування називають в асиметричних системах "відкритим ключем", а от ключ розшифрування одержувачеві повідомлень необхідно тримати в секреті - він називається "закритим ключем".
Таким чином,  ми рятуємося від необхідності вирішувати складну задачу обміну секретними ключами.
Напрошується питання: "Чому, знаючи відкритий ключ, не можна обчислити закритий ключ?" - це третя необхідна умова асиметричної криптографії - алгоритми шифрування і розшифрування створюються так, щоб знаючи відкритий ключ, неможливо обчислити закритий ключ. 
У цілому система обміну при використанні асиметричного шифрування виглядає в такий спосіб. Для кожного з N абонентів, що ведуть обмін, обрана своя пара ключів: "відкритий" Ej і "закритий" Dj, де j - номер абонента. Усі відкриті ключі відомі всім користувачам мережі, кожен закритий ключ, навпаки, зберігається тільки в того абонента, якому він належить. Якщо абонент, скажемо під номером 7, збирається передати інформацію абонентові під номером 9, він шифрує дані ключем шифрування E9 і відправляє її абонентові 9. Незважаючи на те, що всі користувачі мережі знають ключ E9 і, можливо, мають доступ до каналу, по якому йде зашифроване послання, вони не можуть прочитати вихідний текст, тому що процедура шифрування необоротна по відкритому ключі. І тільки абонент №9, одержавши послання, робить над ним перетворення за допомогою відомого тільки йому ключа D9 і відновлює текст послання. Помітьте, що якщо повідомлення потрібно відправити в протилежному напрямку (від абонента 9 до абонента 7), те потрібно буде використовувати вже іншу пару ключів (для шифрування ключ E7, а для розшифрування - ключ D7). 
Як ми бачимо, по-перше, в асиметричних системах кількість існуючих ключів зв'язано з кількістю абонентів лінійно (у системі з N користувачів використовуються 2*N ключів), а не квадратично, як у симетричних системах. По-друге, при порушенні конфіденційності k-ої робочої станції зловмисник довідається тільки ключ Dk: це дозволяє йому читати всі повідомлення, що приходять абонентові k, але не дозволяє видавати себе за нього при відправленні листів. 
 
2.7 Стандарт асиметричного шифрування RSA
 
Найпоширенішим алгоритмом асиметричного шифрування є алгоритм RSA. Він був запропонований трьома дослідниками-математиками Рональдом Ривестом (R.Rivest) , Ади Шамиром (A.Shamir) і Леонардом Адльманом (L.Adleman) у 1977-78 роках. Розроблювачам даного алгоритму удалося ефективно втілити ідею однобічних функцій із секретом. Стійкість RSA базується на складності факторизації великих цілих чисел. У 1993 році метод RSA був обнародуваний і прийнятий як стандарт (PKCS #1: RSA Encryption standart). RSA можна застосовувати як для шифрування/розшифрування, так і для генерації/перевірки електронно-цифрового підпису.
 
2.8 Криптосистема Ель-Гамаля
 
Дана система є альтернативою RSA і при рівному значенні ключа забезпечує ту ж криптостійкість.
На відміну від RSA метод Ель-Гамаля заснований на проблемі дискретного логарифма. Цим він схожий на алгоритм Діфі-Хелмана. Якщо підносити число до степеня в кінцевому полі досить легко, то відновити аргумент за значенням (тобто знайти логарифм) досить важко.
Основу системи складають параметри p і g - числа, перше з яких - простої, а друге - ціле.
Олександр генерує секретний ключ а й обчислює відкритий ключ y = gа mod p. Якщо Борис хоче послати Олександру повідомлення m, то він вибирає випадкове число k, менше p і обчислює
y1 = gk mod p   і
y2 = m  yk,
де  означає побітове додавання по модулі 2. Потім Борис посилає (y1,y2) Олександру.
Олександр, одержавши зашифроване повідомлення, відновлює його:
m = (y1a mod p)  y2.
Алгоритм цифрового підпису DSA, розроблений NIST (National Institute of Standard and Technology) і є частиною стандарту DSS частково спирається на розглянутий метод.
 
2.9 Алгоритм DSA
 
У 1991 р. у США був опублікований проект федерального стандарту цифрового підпису - DSS (Digital Signature Standard, [DSS91], що описує систему цифрового підпису DSA (Digital Signature Algorithm). Одним з основних критеріїв при створенні проекту була його патентна чистота.
Пропонований алгоритм DSA, має, як і RSA, теоретико-числовий характер, і заснований на криптографічній системі Ель-Гамаля у варіанті Шнора. Його надійність заснована на практичній нерозв'язності визначеної частки випадку задачі обчислення дискретного логарифма. Сучасні методи рішення цієї задачі мають приблизно ту ж ефективність, що і методи рішення задачі факторизації; у зв'язку з цим пропонується використовувати ключі довжиною від 512 до 1024 біт з тими ж характеристиками надійності, що й у системі RSA. Довжина підпису в системі DSA менше, ніж у RSA, і складає 320 біт.
З моменту опублікування проект одержав багато критичних відкликань, багато хто з яких були враховані при його доробці. Одним з головних аргументів проти DSA є те, що, на відміну від загальної задачі обчислення дискретного логарифма, її окремий випадок, використаний у даній схемі, мало вивчений і, можливо, має істотно меншу складність розкриття. Крім того, стандарт не специфікує спосіб одержання псевдовипадкових чисел, використовуваних при формуванні цифрового підпису, і не вказує на те, що цей елемент алгоритму є одним із самих критичних по криптографічній стійкості.
Функції DSA обмежені тільки цифровим підписом, система принципово не призначена для шифрування даних. По швидкодії система DSA порівнянна з RSA при формуванні підпису, але істотно (у 10-40 разів) уступає їй при перевірці підпису.
Разом із проектом DSS опублікований проект стандарту SHS (Secure Hash Standard), що описує односпрямовану хеш-функцію SHA (Secure Hash Algorithm), рекомендовану для використання разом з DSA. Хеш-функція SHA є модифікацією алгоритму MD4, добре відомого в криптографічній літературі.
 
2.9.1 Генерація ЕЦП
При генерації ЕЦП використовуються параметри трьох груп:
-загальні параметри
-секретний ключ
-відкритий ключ
Загальні параметри необхідні для функціонування системи в цілому. Секретний ключ використовується для формування ЕЦП, а відкритий - для перевірки ЕЦП. Загальними параметрами системи є прості цілі числа p, q, g, що задовольняють наступним умовам:
 q: простий дільник числа (p-1), що задовольняє умові:
 g: так називаний генератор, що задовольняє рівності:
Параметри p, q, g публікуються для всіх учасників обміну ЕД з ЕЦП.
Секретний ключ x випадково вибирається з діапазону [1,q] і тримається в секреті.
Відкритий ключ обчислюється:  
Також при описі даної схеми будуть використовуватися наступні позначення і додаткові параметри: m - вхідне повідомлення користувача для схеми з ЕЦП; k -  випадкове число, що задовольняє умові 0<k<q, що зберігається в секреті і міняється від одного підпису до іншої; H - хеш-функція, h - хеш-код повідомлення.
Процес генерації ЕЦП складається з декількох етапів:
1. Обчислюється хеш-код повідомлення m  
2. З діапазону [1,q] випадковим образом  вибирається значення k і обчислюється  
3. Обчислюється  , де   задовольняє умові
 
Значення r, s є ЕЦП повідомлення m  і передаються разом з ним по каналах зв'язку.
 
2.9.2 Перевірка ЕЦП
Нехай прийняте повідомлення m1 і його підпис s1, r1.
Перевірка ЕЦП відбувається в такий спосіб:
-перевіряється виконань умов 0<r1<q, 0<s1<q, і якщо хоча б одне з них порушено, підпис відкидається.
-Обчислюються значення:
-перевіряється рівність v = r1
Якщо остання рівність виконується, то підпис приймається. У даному стандарті специфікується також процедура генерації основних параметрів системи і проводиться доказ того, що якщо v=r1, то m1=m, r1=r, s1=s.
 
2.10 Стандарт на процедури ЕЦП ГОСТ Р 34.10-94
 
Вітчизняним стандартом на процедури вироблення і перевірки ЕЦП є ГОСТ Р 34.10-94. Схема ЕЦП, запропонована в даному стандарті, багато в чому нагадує підпис у DSA.
Цифровий підпис являє собою два великих цілих простих  числа. Загальнодоступні параметри схеми ЕЦП (p, q, a) повинні задовольняти наступним умовам:
   або  
q: простий дільник числа (p-1), що задовольняє
умові  
 
Секретний ключ x випадково вибирається з діапазону [1,q] і тримається в секреті.
Відкритий ключ обчислюється:  .
 
2.10.1 Генерація ЕЦП
 
Процес генерації ЕЦП складається з декількох етапів:
1.Обчислюється хеш-код повідомлення m  
(хеш-функція, використовувана в даному стандарті відповідно до ГОСТ Р 34.10-94), якщо  , те   привласнюється значення 0…02551
2. З діапазону [1,q] випадковим образом вибирається значення k
3. Обчислюється  ,  ; якщо r1=0, варто повернутися до попереднього етапу і виробити інше значення k.
4. Обчислюється  ; якщо s=0, те необхідно виробити інше значення k.
Значення r1, s1 є ЕЦП повідомлення m  і передаються разом з ним по каналах зв'язку.
 
2.10.2 Перевірка ЕЦП
 
Перевірка ЕЦП відбувається в такий спосіб:
-перевіряється виконань умов 0<r<q, 0<s<q, і якщо хоча б одне з них порушено, підпис відкидається.
-Обчислюється хеш-код даного повідомлення  ; Якщо  , те бітове представлення  : 0…02551...
-Обчислюється значення  .
-Обчислюється значення  .
-Обчислюється значення  .
-перевіряється рівність  .
Якщо остання рівність виконується, то підпис приймається.
 
2.11 Цифрові підписи, засновані на симетричних кріптосистемах
 
Існує ще один метод криптографії - так називана симетрична криптографія. При симетричній криптографії для шифрування і дешифрування використовується той самий ключ. У цьому випадку цей секретний ключ - симетричний ключ - є загальним для двох учасників обміну повідомленнями. З погляду обчислень симетрична криптографія вимагає менше витрат у порівнянні з асиметричної. Саме тому асиметрична криптографія звичайно застосовується тільки для передачі загальної конфіденційної інформації. Як що тільки обмінюються повідомленнями сторони її одержують, вони можуть перейти до 
Договірні відносини, побудовані за принципом сукупності парних договорів "Центр системи - вилучений учасник", що передбачають взаємну сертифікацію відкритих ключів, забезпечують захист сторін від різних ризиків.
Якщо в системі для захисту інформації застосовується електронний цифровий підпис, то за допомогою закріплення за учасниками індивідуальної ключової інформації забезпечується юридична чинність електронних документів. Усе це можливо при дотриманні ряду додаткових умов, до яких відносяться: висновок коректних договорів, задовільні формати документів і ін.
 
РОЗДІЛ 3 ЗАБЕЗПЕЧЕННЯ ЦІЛІСНОСТІ ДАНИХ І  АВТЕНТИФІКАЦІЇ КОРИСТУВАЧІВ ЗА ДОПОМОГОЮ ПІДПИСІВ XML У СИСТЕМАХ ДОКУМЕНТООБІГУ
 
3.1 Можливості цифрового підпису у форматі XML
 
Специфікація підпису XML - "Цифровий підпис XML" (XMLDS) - яка була розроблена спільними зусиллями організації W3C і IETF, має статус Рекомендації W3C. Цей документ [7] визначає правила обробки і синтаксис, призначені для упакування в XML-формат даних про цілісність повідомлення, його автентифікації і користувальницької автентифікації.
У нашому випадку розглядається (як приклад) взаємодія між туроператором і його партнерами (готелями). Припустимо, що туроператор хоче викликати метод GetSpecialDiscountedBookingForPartners Web-сервісу свого партнера. Цей метод надає послугу інтерактивного резервування місць в отеленні за спеціальною ціною (зі знижкою). Причому побачити цю знижку можуть тільки бізнес партнери, а не споживачі.
Викликаючи метод SOAP - Simple Object Access Protocol GetSpecialDiscountedBookingForPartners, туроператор включає в нього інформацію про цілісність повідомлення і користувальницької автентифікації. При одержанні цього виклику брандмауерові XML організації буде потрібно переглянути SOAP-повідомлення, щоб повірити, що:
повідомлення не було змінено, поки воно передавалося в Web-сервіс організації (цілісність повідомлення);
запитуюча сторона є бізнес партнером (користувальницька автентифікація). 
Якщо виконані ці дві умови, брандмауер XML дозволяє запитуючій стороні перейти до SOAP-сервера і робить наступні дії:
1.Туроператор направляє в Web-сервіс організації SOAP-запит про виклик методу. Цей запит включає всю інформацію, що відноситься до забезпечення безпеки (користувальницька автентифікація і користувальницька автентифікація). 
2.Web-сервіс організації захищений брандмауером XML, що приймає всі запити, що направляються в цей SOAP-сервер. брандмауер XML перевіряє, чи ідентично отримане повідомлення тому, що запитуюча сторона збиралася відправити. 
3.Якщо цілісність повідомлення не порушена, брандмауер XML зчитує ідентифікаційну інформацію запитуючої сторони з цього SOAP-запиту і перевіряє, чи є цей користувач бізнес партнером. 
4.Якщо запитуюча сторона є бізнес партнером, брандмауер XML дозволяє запитуючій стороні перейти до SOAP-сервера. 
Лістінг 1 - це простий SOAP-запит, що передає в Web-сервіс організації виклик методу GetSpecialDiscountedBookingForPartners. У цьому SOAP-запиті відсутні які-небудь дані про цілісність повідомлення або користувальницької автентифікації. Лістінг 1 - це початкова крапка демонстрації застосування специфікації "Цифровий підпис XML".
 
Лістінг 1
<?xml version=”1.0”?>
 <SOAP-ENV:Envelope
    xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”>
    <SOAP-ENV:Body>
        <s:GetSpecialDiscountedBookingForPartners
         xmlns:s=“http://www.MyHotel.com/partnerservice/”>
              <!--Parameters passed with the method call-->
         </s:GetSpecialDiscountedBookingForPartners>
    </SOAP-ENV:Body>
 </SOAP-ENV:Envelope>
 
SOAP у даному випадку використовується як приклад XML-формату, щоб продемонструвати "Цифровий підпис XML", що не є специфічною для SOAP. Тому її можна застосовувати, щоб уставляти підписи і профілі повідомлення в будь-який екземпляр XML: SOAP або який-небудь інший.
У наступному прикладі теги цифрового підпису XML будуть вставлені в заголовок SOAP. Цифровий підпис - це гнучка технологія, він допускає включення таких тегів у будь-яке місце XML-файлу. Насправді існують три типи підписів XML: замкнена в конверт (enveloping), що укладається в конверт (enveloped) і окрема (detached). Якщо підпис XML обертає даному, підлягаючому підписанню, говорять, що це підпис, що укладає в конверт. Якщо ж даному, підлягаючому підписанню, обертають цей підпис (наприклад, підпис XML стає елементом даних XML, що підписуються), то цей підпис називається укладається в конверт. Нарешті, якщо підпис і даному, підлягаючому підписанню, зберігаються роздільно - елемент, що підписується, і елемент підпису є елементами одного рівня - такий підпис прийнято вважати відособленої. У прикладі, що у цій статті ілюструє застосування специфікації "Цифровий підпис XML", використовуються відособлені підписи.
 
3.2 Формування цифрового підпису XML: 
 
Перший крок - це створення елемента Signature. Згодом цей елемент буде обертати всі інші елементи цифрового підпису XML. У Лістінгу 2 точно таке ж тіло як і у Лістінгу 1, єдина відмінність між ними полягає в тім, що Лістінг 2 містить оголошення простору імен цифрового підпису XML (http://www.w3.org/2000/09/xmldsig#) і заголовок SOAP. Цей заголовок SOAP обертає елемент Signature.
 
Лістінг 2
<?xml version=”1.0”?>
 <SOAP-ENV:Envelope
    <SOAP-ENV:Header>
        <ds:Signature>
             <ds:SignedInfo>
             </ds:SignedInfo>
             <ds:SignatureValue>
             </ds:SignatureValue>
             <ds:KeyInfo>
             </ds:KeyInfo>
        </ds:Signature>
    </SOAP-ENV:Header>
    <SOAP-ENV:Body>
        <s:GetSpecialDiscountedBookingForPartners
          xmlns:s=“http://www.MyHotel.com/partnerservice/”>
              <!--Parameters passed with the method call-->
         </s:GetSpecialDiscountedBookingForPartners>
    </SOAP-ENV:Body>
 </SOAP-ENV:Envelope>
 
Елемент Signature у Лістінгу 2 містить три дочірніх елементи: SignedInfo, SignatureValue і KeyInfo. 
Цей елемент є єдиним елементом, що обертає, для інших тегів цифрового підпису XML. У наступних кроках: 2, 3 і 4 - ми створимо дочірні вузли для цих трьох нащадків Signature (SignedInfo, SignatureValue і KeyInfo).
Другий крок - створення дочірніх вузлів елемента SignedInfo. Лістінг 3 - результат включення дочірніх вузлів SignedInfo у Лістінг 2. Закінчена структура елемента SignedInfo - докладна ілюстрація того, як створюється підпис XML - елемент SignedInfo має трохи нащадків, кожний з яких містить трохи біт інформації, призначення якої буде розкрито нижче.
 
Лістінг 3
<?xml version=”1.0”?>
<SOAP-ENV:Envelope
    <SOAP-ENV:Header>
        <ds:Signature>
             <ds:SignedInfo>
                  <ds:CanonicalizationMethod
                      Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                  <ds:SignatureMethod
                      Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
                  <ds:Reference URI="#GetSpecialDiscountedBookingForPartners">
                      <ds:Transforms>
                          <ds:Transform
                              Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                      </ds:Transforms>
                      <ds:DigestMethod
                          Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                      <ds:DigestValue>
                          BIUddkjKKo2...
                      </ds:DigestValue>
                  </ds:Reference>
             </ds:SignedInfo>
             <ds:SignatureValue>
             </ds:SignatureValue>
             <ds:KeyInfo>
             </ds:KeyInfo>
        </ds:Signature>
    </SOAP-ENV:Header>
    <SOAP-ENV:Body>
        <s:GetSpecialDiscountedBookingForPartners
           xmlns:s=“http://www.MyHotel.com/partnerservice/
            ID="GetSpecialDiscountedBookingForPartners">
              <!--Parameters passed with the method call-->
         </s:GetSpecialDiscountedBookingForPartners>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>
 
CanonicalizationMethod - це обов'язковий елемент, що ідентифікує алгоритм канонізації, застосовуваної до елемента SignedInfo до створення підпису.
Алгоритми канонізації надзвичайно важливі під час ідписання XML, оскільки алгоритми дайджестів повідомлень інтерпретують XML як потік двійкових даних. Два різних потоки можуть представляти той самий ресурс. Наприклад, якщо змінити послідовність атрибутів в елементі XML, що результативний XML-файл є логічною еквівалентною версією вихідного XML-файлу. Однак, ці два логічно еквівалентних файли будуть містять різні потоки даних і створюють різні дайджести.
Алгоритми канонізації призначені для генерації двійкових потоків для логічно еквівалентних даних XML. Щоб бути упевненим, що логічно еквівалентні XML-документи створюють той самий дайджест (і однаковий підпис), необхідно канонізувати ресурс XML до створення дайджесту потоку даних. 
Елемент CanonicalizationMethod у Лістінгу 3 містить атрибут Algorithm, значенням якого є рядок URI (http://www.w3.org/2001/10/xml-exc-c14n#). Цей рядок URI вказує алгоритм, описаний специфікацією W3C - "Виняткова канонізація XML" (Exclusive XML Canonicalization). Подробиці канонізації XML виходять за рамки цієї статті. Детальна інформація про канонізації може бути знайдена в статтях, посилання на які приведені в розділі Ресурси.
На даному етапі просто створюється елемент CanonicalizationMethod - а алгоритм канонізації поки не використовується. Він буде застосовується до елемента SignedInfo після того, як будуть сформовані всі його нащадки. 
Наступний нащадок елемента SignedInfo - це елемент SignatureMethod, атрибут Algorithm якого вказує алгоритм, використовуваний для створення криптографічного підпису.
Третій нащадок елемента SignedInfo - елемент Reference. В елемента SignedInfo повинний бути хоча б один елемент Reference. Цей елемент використовується для збереження інформації, що включає:
1.Указівка даних, що підлягають підписанню. Для цього використовується атрибут URI елемента Reference.  Дані, що підписуються, можуть бути як усередині XML-документа, так і поза нього. Якщо дані і підпис знаходяться в тому самому XML-документі, для їхньої указівки використовується ідентифікатор фрагмента у виді значення атрибута URI елемента Reference. Так, у Лістінгу 3 значення атрибута URI указує на елемент GetSpecialDiscountedBookingForPartners. Якщо ж дані є зовнішніми стосовно файлу з цифровим підписом 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 містить дійсне значення дайджесту, отримане застосуванням алгоритму дайджесту до канонічної форми елемента GetSpecialDiscountedBookingForPartners. Необхідно відзначити, що бінарні дані в неопрацьованому виді (такі як потік, створений алгоритмами дайджесту повідомлення, підписи і шифрування) не можуть бути загорнені в розмітку XML - це може ускладнити розбір XML. Перш ніж обертати них у розмітку XML, такі дані представляються в кодуванні base-64. У результаті, зашифровані дані не містять бітів, що могли б конфліктувати із правилами обробки XML. 
Після того, як SignedInfo і його дочірні елементи сформовані, необхідно провести канонізацію всього елемента SignedInfo по алгоритму, зазначеному в елементі CanonicalizationMethod. Після цього варто одержати значення дайджесту й обернути це значення в елемент SignatureValue, як показано в Лістінгу 4. Під час підписання канонічна форма елемента SignedInfo використовується в якості даному, підлягаючому підписанню. У неї входять усі дочірні елементи елемента SignedInfo.
 
Лістінг 4
<?xml version=”1.0”?>
<SOAP-ENV:Envelope
    <SOAP-ENV:Header>
        <ds:Signature>
             <ds:SignedInfo>
                  <ds:CanonicalizationMethod
                      Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                  <ds:SignatureMethod
                      Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
                  <ds:Reference URI="#GetSpecialDiscountedBookingForPartners">
                      <ds:Transforms>
                          <ds:Transform
                              Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                      </ds:Transforms>
                      <ds:DigestMethod
                          Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                      <ds:DigestValue>
                          BIUddkjKKo2...
                      </ds:DigestValue>
                  </ds:Reference>
             </ds:SignedInfo>
             <ds:SignatureValue>
                 halHJghyf765....
             </ds:SignatureValue>
             <ds:KeyInfo>
             </ds:KeyInfo>
        </ds:Signature>
    </SOAP-ENV:Header>
    <SOAP-ENV:Body>
        <s:GetSpecialDiscountedBookingForPartners
           xmlns:s=“http://www.MyHotel.com/partnerservice/
            ID="GetSpecialDiscountedBookingForPartners">
              <!--Parameters passed with the method call-->
         </s:GetSpecialDiscountedBookingForPartners>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>
 
Необхідно відзначити, що структура SignedInfo містить посилання на підпис даних (атрибут URI елемента Reference), значення дайджесту й ім'я методу підпису, а також інші біти інформації. Отже, підписання структури SignedInfo фактично означає підписання дайджесту даних разом із самим посиланням на ці дані.
У Лістінгу 2 в елемента Signature є ще один дочірній елемент по імені KeyInfo. Четвертий крок - створення його нащадків. У Лістінгу 5 елемент KeyInfo містить дочірній елемент KeyName. Цей елемент KeyName є ідентифікатором ключа, що використовується для перевірки підпису. KeyName - це просто "заповнювач" для ідентифікаторів ключа. Специфікація "Цифровий підпис XML" не визначає механізм, що співвідносить ідентифікатор з дійсною парою ключів, використовуваних для підписання. Проектування механізму ідентифікації ключа - задача додатків, що реалізують "Цифровий підпис XML". Наприклад, ідентифікатор ключа в Лістінгу 5 (MyKeyIdentifier) може ідентифікувати загальний секретний ключ (симетричний ключ), яким вже обмінювалися туроператор і готель.
Лістінг 5
<?xml version=”1.0”?>
<SOAP-ENV:Envelope
    <SOAP-ENV:Header>
        <ds:Signature>
             <ds:SignedInfo>
                  <ds:CanonicalizationMethod
                      Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                  <ds:SignatureMethod
                      Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
                  <ds:Reference URI="#GetSpecialDiscountedBookingForPartners">
                      <ds:Transforms>
                          <ds:Transform
                              Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                      </ds:Transforms>
                      <ds:DigestMethod
                          Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                      <ds:DigestValue>
                          BIUddkjKKo2...
                      </ds:DigestValue>
                  </ds:Reference>
             </ds:SignedInfo>
             <ds:SignatureValue>
                 halHJghyf765....
             </ds:SignatureValue>
             <ds:KeyInfo>
                 <ds:KeyName>MyKeyIdentifier</ds:KeyName>
             </ds:KeyInfo>
        </ds:Signature>
    </SOAP-ENV:Header>
    <SOAP-ENV:Body>
        <s:GetSpecialDiscountedBookingForPartners
           xmlns:s=“http://www.MyHotel.com/partnerservice/
            ID="GetSpecialDiscountedBookingForPartners">
             <!--Parameters passed with the method call-->
         </s:GetSpecialDiscountedBookingForPartners>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>
 
Крім того, елемент KeyInfo - необов'язковий: його можна як включати, так і не включати в підпис. Цей елемент є необов'язковим, тому що під час підписання, можливо, може не знадобитися включати інформацію про ключ у файл із цифровим підписом XML. Елемент KeyInfo може також використовуватися при шифруванні XML, про що буде розказано в наступному розділі.
Ці чотири кроки - проста демонстрація застосування специфікації "Цифровий підпис XML". Лістінг 5 - повне SOAP-повідомлення, що у своєму заголовку несе дані про цілісність повідомлення і користувальницької автентифікації.
Розглянемо, як обробляється заголовок повідомлення, представленого в Лістінге 5, на стороні Web-сервісу організації.
 
3.2.1 Перевірка цифрового підпису XML
Процедура перевірки проста і логічно може бути виведена з методики формування цифрового підпису XML, розглянутої вище. Вона розпадається на три етапи.
По-перше, необхідно канонізувати елемент SignedInfo. Нагадаємо, що елемент CanonicalizationMethod встановлює алгоритм канонізації. Тому варто скористатися цією канонічною формою елемента SignedInfo для частини процесу, що залишилася, перевірки.
По-друге, необхідно проконтролювати цілісність повідомлення, перевіривши дайджест, що знаходиться в елементі Reference, сформованому раніше, на кроці 2. При перевірці дайджесту потрібно мати інформацію, що включає:
1.Дані, по яких побудований дайджест. Випливає, що розіменовувати атрибут Reference елемента, щоб одержати ці дані. 
2.Будь-які трансформації, що можуть застосовуватися до цих даних до запуску алгоритму профілю. В елементі Transforms утримується ця інформація. Перш ніж одержувати дайджест даних, необхідно застосувати до них ті ж трансформації. 
3.Алгоритм дайджесту. Ця інформація знаходиться в значенні атрибута Algorithm елемента DigestMethod. Необхідно застосувати цей дайджест повідомлення і перевірити, чи не відрізняється значення дайджесту від тієї, що утримується в елементі DigestValue. 
Якщо перевірка дайджесту приводить до негативного результату, то процес перевірки закінчується і вважається незадовільним.
Якщо з'ясовується, що з величиною профілю усі в порядку, настає черга третього етапу - перевірки підпису. Для перевірки підпису необхідний ключ сторони, що підписала, (відкритий або загальний секретний). Інформацію про ключ можна одержати з елемента KeyInfo, якщо він присутній (або якщо додаткові уже відомий така інформація). Як тільки ключ, використовуваний при перевірці підпису, відомий, потрібно прочитати метод підпису, що застосовувався при створенні цього підпису. Атрибут Algorithm елемента SignatureMethod містить цю інформацію. Після чого варто скористатися канонічною формою елемента SignedInfo і ключем, щоб підтвердити величину підпису. 
При реалізації специфікації "Цифровий підпис XML" можна створювати заголовки SOAP для генерації підписаних SOAP-повідомлень. Брандмауер XML, що знаходиться на стороні одержувача, обробляє цей заголовок SOAP, щоб перевірити підпису перш ніж переслати запит на SOAP-сервер. Задача забезпечення безпеки може бути досягнуті в такий спосіб:
Можна перевірити, що отримане SOAP-повідомлення було дійсно відправлене відомим відправником. 
Можна перевірити, що отримані дані не були змінені, поки вони передавалися, і що вони не відрізняються від тих, що відправник збирався відправити. 
Таким чином, стосуючись нашого приклада, можна бути упевненим, що запит про резервування за спеціальною ціною зі знижкою був уставлений дійсно партнером, і що ці дані не були змінені, поки вони передавалися. Проте, можливо ситуація, коли дані, передані по Інтернет, можуть бути переглянуті хакерами. Розглянемо, як ця проблема може бути вирішена за допомогою специфікації "Шифрування XML".
 
3.3 Шифрування XML
 
Специфікація шифрування XML задовольняє вимогам конфіденційності XML-повідомлень. Ця специфікація дозволяє реалізувати наступну функціональність:
•шифрування цілого XML-файлу; 
•шифрування будь-якого окремого елемента XML-файлу; 
•шифрування тільки змісту XML-файлу; 
•шифрування даних, відмінних від XML (наприклад, малюнка JPG); 
•шифрування вже зашифрованого елемента ("супершифрування"). 
 
 
3.4 Шифрування цілого XML-файлу
 
Давайте почнемо із шифрування цілого XML-файлу. Лістінг 6 - це приклад такого зашифрованого файлу [3]. При цьому вихідний XML-документ не показаний, оскільки він не потрібний, тому що шифрування XML-файлу своїм результатом має таку ж XML-структуру - за винятком зашифрованої величини, укладеної в елементі CipherValue.
 
Лістінг 6
<?xml version='1.0'?>
 <EncryptedData
    MimeType="text/xml">
    <EncryptionMethod
    <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:KeyName>MyKeyIdentifier</ds:KeyName>
    </ds:KeyInfo>
    <CipherData>
      <CipherValue>B457V645B45........</CipherValue>
    </CipherData>
 </EncryptedData>
 
Кореневий елемент 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.
 
3.5 Шифрування окремого елемента
 
Як було сказано вище, структура EncryptedData несе зашифровані дані разом з необхідною інформацією. В основі шифрування одиночного елемента XML-файлу лежить аналогічний підхід. Розглянемо Лістінг 7, у якому зашифрований елемент GetSpecialDiscountedBookingForPartners з Лістінгу 1 отриманий простою заміною елементом EncryptedData.
 
Лістінг 7
<?xml version=”1.0”?>
 <SOAP-ENV:Envelope
    xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”>
    <SOAP-ENV:Body>
        <xenc:EncryptedData
             xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
             Type="http://www.w3.org/2001/04/xmlenc#Element">
             <xenc:EncryptionMethod
                 Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
             <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                 <ds:KeyName>MyKeyIdentifier</ds:KeyName>
             </ds:KeyInfo>
             <xenc:CipherData>
                   <xenc:CipherValue>B457V645B45........</xenc:CipherValue>
             </xenc:CipherData>
        </xenc:EncryptedData>
    </SOAP-ENV:Body>
 </SOAP-ENV:Envelope>
 
Порівняємо елемент EncryptedData з Лістінгу 6 з елементом EncryptedData з Лістінгу 7. Неважко бачити, що мається одне розходження: замість атрибута MimeType Лістінгу 6 у Лістінге 7 з'явився атрибут Type. Значення цього атрибута дорівнює http:///www.w3.org/2001/04/xmlenc#Element, що означає, що зашифровано XML-елемент.
Таким чином, при шифруванні елемента XML-файлу варто використовувати ідентифікатор http:///www.w3.org/2001/04/xmlenc#Element як значення атрибута Type. У цьому випадку одержувач зашифрованого XML-файлу буде знати, що зашифровані дані повинні інтерпретуватися як XML-елемент у розшифрованій простій текстовій формі.
 
3.5.1 Шифрування змісту елемента
 
Розглянемо Лістінг 8, у якому зашифровано тільки зміст елемента GetSpecialDiscountedBookingForPartners - для цього цей зміст був замінений структурою EncryptedData. Цей прийом схожий на шифрування елемента (див. Лістінг 7). Відмінність полягає в тому, що цього разу значення атрибута Type тега EncryptedData дорівнює http://www.w3.org/2001/04/xmlenc#Content. Це значення говорить про те, що зашифровані дані повинні інтерпретуватися як зміст елемента.
 
Лістінг 8
<?xml version=”1.0”?>
 <SOAP-ENV:Envelope
    xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”>
    <SOAP-ENV:Body>
        <s:GetSpecialDiscountedBookingForPartners
           xmlns:s=“http://www.MyHotel.com/partnerservice/
            ID="GetSpecialDiscountedBookingForPartners">
            <xenc:EncryptedData
                 xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
                 Type="http://www.w3.org/2001/04/xmlenc#Content">
                 <xenc:EncryptionMethod
                     Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
                 <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                     <ds:KeyName>MyKeyIdentifier</ds:KeyName>
                 </ds:KeyInfo>
                 <xenc:CipherData>
                       <xenc:CipherValue>B457V645B45........</xenc:CipherValue>
                </xenc:CipherData>
            </xenc:EncryptedData>
         </s:GetSpecialDiscountedBookingForPartners>
    </SOAP-ENV:Body>
 </SOAP-ENV:Envelope>
 
3.6 Обробка шифрування XML
 
Розглянемо, як брандмауер XML працює з поняттями шифрування. Брандмауер одержує Лістінг 7 або 8 (SOAP-повідомлення з зашифрованими елементами або змістом) і, перш ніж переслати SOAP-серверові розшифрований запит SOAP-повідомлення, перетворить їхній зміст у дешифровану форму.
Одержувач зашифрованого XML-файлу (наприклад, у нашому випадку брандмауер XML організації) розшифровує цей XML-файл, виконуючи наступну послідовність дій:
1.Витягає зашифрований зміст елемента CypherValue;
2.Зчитує значення атрибута алгоритму елемента EncryptionMethod;
3.Зчитує значення атрибута Type елемента EncryptedData;
4.Одержує інформацію про ключ з елемента ds:KeyInfo;
5.Використовує отриману інформацію для створення простого текстового (розшифрованого) файлу. 
 
3.7 Введення в безпеку Web-сервісів
 
Виникає питання, яким образом брандмауер XML використовує підписи і шифрування XML для захисту SOAP-серверів? Адже незважаючи на те, що можливості цих двох технологій були продемонстровані на численних прикладах, необхідно з'ясувати, як застосовувати ці дві специфікації при використанні брандмауера XML для захисту SOAP-серверів, особливо якщо врахувати жодна з них не є специфічною для SOAP. Спробуємо зрозуміти, чому вся інформація, що стосується підписи, була поміщена в заголовок SOAP, а не в тіло SOAP [3].
Специфікація консорціуму OASIS "Безпека Web-сервісів" докладно визначає, як застосовувати технології підпису і шифрування XML при обміні SOAP-повідомленнями. Цей стандарт одержує елементи низького рівня з розглянутих вище специфікацій ("Цифровий підпис XML" і "Шифрування XML") і задає високорівневий синтаксис для обгортання в SOAP-повідомленнях інформації про безпеку.
Специфікація "Безпека Web-сервісів" описує механізм безпечного обміну SOAP-повідомленнями. Вона забезпечує наступну функціональність:
1.Цілісність повідомлення. 
2.Користувальницьку автентифікацію. 
3.Конфіденційність. 
Розглянемо Лістінг 9 - це SOAP-повідомлення, що несе інформацію про безпеку відповідно до синтаксису специфікації "Безпека Web-сервісів". Лістінг 9 - цей той же самий SOAP-запит GetSpecialDiscountedBookingForPartners, що неодноразово приводився в цій статті. Однак цього разу заголовок запиту передає інформацію про цифровий підпис відповідно до розглянутої специфікації.
 
Лістінг 9
<?xml version="1.0" encoding="utf-8"?>
<SOAP:Envelope
    <SOAP:Header>
        <wsse:Security>
            <wsse:BinarySecurityToken
                ValueType="wsse:X509v3"
                EncodingType="wsse:Base64Binary"
                wsu:Id="MyTourOperatorCertificate">
                   LKSAJDFLKASJDlkjlkj243kj;lkjLKJ...
            </wsse:BinarySecurityToken>
            <ds:Signature>
                <ds:SignedInfo>
                    <ds:CanonicalizationMethod 
                        Algorithm="http://www.w3.org/2001/10/xml -exc-c14n# "/>
                    <ds:SignatureMethod
                        Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
                    <ds:Reference URI="#myDiscountRequestBody">
                        <ds:Transforms>
                            <ds:Transform
                                Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                        </ds:Transforms>
                        <ds:DigestMethod
                            Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                        <ds:DigestValue>BSDFHJYK21f...</ds:DigestValue>
                    </ds:Reference>
                </ds:SignedInfo>
                <ds:SignatureValue>
                    GKLKAJFLASKJ52kjKJKLJ345KKKJ...
                </ds:SignatureValue>
                <ds:KeyInfo>
                    <wsse:SecurityTokenReference>
                        <wsse:Reference URI="#MyTourOperatorCertificate"/>
                    </wsse:SecurityTokenReference>
                </ds:KeyInfo>
            </ds:Signature>
        </wsse:Security>
    </SOAP:Header>
    <SOAP-ENV:Body>
        <s:GetSpecialDiscountedBookingForPartners
            xmlns:s=“http://www.MyHotel.com/partnerservice/
            ID="myDiscountRequestBody">
                 <!--Parameters passed with the method call-->
         </s:GetSpecialDiscountedBookingForPartners>
    </SOAP-ENV:Body>
 </SOAP-ENV:Envelope>
 
Щоб краще зрозуміти синтаксис специфікації "Безпека Web-сервісів", розглянемо Лістінг 9:
1.Елемент SOAP:Envelope містить оголошення просторів імен для SOAP, "Безпека Web-сервісів" і "Цифрового підпису XML". 
2.В елемента SOAP:Header мається тільки один дочірній елемент (wsse:Security), що є обгорткою для всієї інформації про безпеку. В елемента wsse:Security два дочірніх елементи: wsse:BinarySecurityToken і ds:Signature. 
3.Елемент wsse:BinarySecurityToken містить маркер доступу (security token). Маркер доступу подібний пропускові, видаваному службою безпеки, або посвідченню особи, яких необхідно пред'явити при вході в область обмеженого доступу. Нижче описані основні типи маркерів доступу.
Найбільш популярний і широко використовуваний маркер доступу - це пари логін-пароль, як та, що застосовується при перевірці електронної пошти.
Пари логін-пароль - це маркер доступу, призначений для людини. Існують маркери доступу, що мають бінарну форму (і, отже, можуть бути нечитабельні). Такі маркери називаються бінарними маркерами доступу. Наприклад, сертифікат X509 (дуже популярний формат цифрових сертифікатів, розроблений Міжнародним союзом електрозв'язку - сектора телекомунікацій (International Telecommunications Union - Telecommunications sector, ITU-T)) - це бінарний маркер доступу.
Атрибут ValueType елемента wsse:BinarySecurityToken містить інформацію про те, який тип бінарного маркера доступу загорнуть в елемент wsse:BinarySecurityToken. У Лістінгу 9 значення цього атрибута дорівнює wsse:X509v3, що означає сертифікат X509.
Атрибут EncodingType елемента wsse:BinarySecurityToken показує, яка кодування в бінарного маркера доступу. Як уже відзначалося вище, бінарні дані не можуть бути загорнені у формат XML. Отже, вони повинні бути перетворені в даний формат (як правило, вони представляються в кодуванні base-64). Сертифікат X509 обернуть в елемент wsse:BinarySecurityToken як зміст цього елемента. 
4.Елемент ds:Signature точно такий же як і той, що був розглянутий раніше в розділі про підпис XML. Необхідно звернути увагу на наступні два моменти: 
•Значення атрибута URI (#myDiscountRequestBody) елемента Reference є ідентифікатором фрагмента, що вказує на елемент SOAP:Body. Це означає, що елемент SOAP:Body - це той елемент, що вже був підписаний і обернуть у теги цифрового підпису XML. 
•В елемента ds:KeyInfo мається елемент wsse:SecurityTokenReference, що містить посилання на маркери доступу. У нашому випадку в нього є дочірній елемент wsse:Reference, атрибут URI якого вказує на елемент wsse:BinarySecurityToken, розглянутий у пункті 3 цього розділу. Це означає, що відкритий ключ у сертифікаті X509 (те, що обертає елемент wsse:BinarySecurityToken) використовується для перевірки підпису. 
Розглянутий приклад дуже простий, він знайомить з підписаними повідомленнями захищених 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 с.
Фото Капча