Размещено на http://www.allbest.ru/

Вступ

В рамках роботи європейських інститутів стосовно застосування електронного підпису потребують звернення до проблем, що стосуються окремих підписів, але дуже часто документи вимагають, щоб більше ніж один підпис давав цьому документові юридичну чинність або зробив угоду дійсною [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. Такий запит припускає генерацію ключової пари, тому при реальній експлуатації набирають сили обмеження Ліцензійної угоди.

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

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

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 Асиметричні алгоритми шифрування

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

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

Таким чином, ми рятуємося від необхідності вирішувати складну задачу обміну секретними ключами.

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