Як забезпечити автентичність електронних документів?

А. В. Лукацький
Науково-інженерне підприємство "Информзащита"

Введення

Останні кілька років ознаменувалися поступовою заміною паперової технології обробки інформації її електронним аналогом. З часом можна очікувати повного витіснення паперового документообігу електронним. Проте уявлення традиційних паперових документів у вигляді електронних послідовностей, що складаються з нулів і одиниць, знеособлює останні. Захисних атрибутів паперових документів: підписів, печаток і штампів, водяних знаків, спеціальної фактури паперової поверхні і т.д., – у електронного подання документів немає. Але електронні документи потрібно захищати не менш ретельно, ніж паперові. Тому виникає задача розробки такого механізму електронного захисту, який би зміг замінити підпис і друк на паперових документах. Тобто необхідно розробити механізм цифрового підпису (digital signature), яка представляє собою додаткову інформацію, приписувану до захищуваних даними. Цифровий підпис залежить від змісту підписуваного документа і якогось секретного елемента (ключа), яким володіє тільки особа, яка бере участь у захищеному обміні. Що повинен забезпечувати такий механізм?

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

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

Правові аспекти

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

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

Можна помітити, що і Цивільний Кодекс і Закон "Про інформацію, інформатизації і захисту інформації" лише підтверджують можливість застосування ЕЦП, але ніяким чином не регламентують випадки та порядок її використання. Ці завдання покладаються на додаткові правові акти. Проте, ніяких підзаконних актів, крім наробила багато шуму Указу Президента № 334 від 3 квітня 1995 року, до цих пір не розроблено. У Державній Думі давно чекають розгляду Закони "Про електронний документ" і "Про електронний цифровий підпис". Але розглянути їх планується не раніше кінця поточного року. А якщо врахувати майбутні вибори, то можна з упевненістю сказати, що про дані законопроекти заговорять не раніше 2000 року. Тому необхідно помітити, що для забезпечення юридичної значимості цифрового підпису необхідно, щоб в договорі про обмін електронними документами між сторонами була обов'язково розписана процедура "порядку узгодження розбіжностей". Без цієї процедури суд має право не приймати як доказ документи, підписані електронним цифровим підписом (Лист Вищого Арбітражного Суду РФ від 19 серпня 1994 р. № С1-7/ОП-587).

В Указі Президента від 3 квітня, у п.2 йдеться про те, що використовувати в інформаційно-телекомунікаційних системах засоби ЕЦП, які не мають сертифіката Федерального агентства урядового зв'язку та інформації (ФАПСИ), заборонено. Однак найбільше протиріччя викликає пункт 4, в якому забороняється діяльність неліцензованих ФАПСИ юридичних і фізичних осіб, пов'язаних з розробкою, реалізацією, виробництвом та експлуатацією шифрувальних засобів (в т.ч. і систем цифрового підпису). Тобто відповідно до цього пункту заборонено використовувати системи цифрового підпису навіть у домашніх умовах. Проте стаття 6 Закону "Про інформацію, інформатизації і захисту інформації" говорить про те, що власник інформаційного ресурсу має право сам встановлювати правила захисту своєї інформації.

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

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

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

Перші варіанти цифрового підпису були реалізовані за допомогою симетричних криптосистем, у якій абоненти, які беруть участь в обміні повідомленнями, використовують один і теж секретний ключ для проставляння та перевірки підписи під документом. В якості алгоритму криптографічного перетворення може використовуватися будь-яка з симетричних криптосистем, що володіє спеціальними режимами функціонування (наприклад, DES, ГОСТ 28147-89 і т.п.).

Процедура підпису документів за допомогою симетричної криптосистеми може виглядати наступним чином:

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

Для усунення зазначеного недоліку була запропонована схема з довіреною арбітром. У даній схемі крім Алекса і Юстаса існує арбітр – радистка Кет. Вона може обмінюватися повідомленнями і з Алексом, і з Юстасом, і володіє секретними ключами обох – kА і KЮ. Процедура підписання документів в даній схемі виглядає таким чином:

Наскільки ефективна ця схема? Розглянемо її з урахуванням вищевказаних вимог, що пред'являються до цифрового підпису.

По-перше, Кет і Юстас знають, що повідомлення прийшло саме від Алекса. Впевненість Кет заснована на тому, що секретний ключ kА мають тільки Алекс і Кет. Підтвердження Кет служить доказом Юстасу. По-друге, тільки Алекс знає ключ kА (і Кет, як довірений арбітр). Кет може отримати зашифроване повідомлення на ключі kА тільки від Алекса. Якщо Мюллер намагається послати повідомлення від імені Алекса, то Кет відразу виявить це на 2-му кроці. По-третє, якщо Юстас намагається використовувати цифровий підпис, отриману від Кет, і приєднати її до іншого повідомленням, видаючи його за повідомлення від Алекса, це виявляється. Арбітр може зажадати від Юстаса це повідомлення й потім порівнює його з повідомленням, зашифрованому на ключі kА. Відразу виявляється факт невідповідності між двома повідомленнями. Якби Юстас спробував модифіковані прислане повідомлення, то Кет аналогічним способом виявила б підробку. По-четверте, навіть якщо Алекс заперечує факт посилки підписаного повідомлення, підтвердження від Кет говорить про зворотне.

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

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

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

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

Пошуки методів, що усувають зазначені вище недоліки, велися за кількома напрямками. Найбільш вражаючих результатів домоглися криптографи-математики Уітфілд Діффі (W. Diffie) і Мартін Хеллман (M. Hellman), а також Ральф Меркль (Ralph Merkle), які в кінці 70-х років опублікували результати своїх досліджень. У своїх роботах автори показали, що існує можливість побудови криптосистем, не вимагають передачі особистого ключа між абонентами, які беруть участь в обміні захищається. У таких криптосистемах немає необхідності і в арбітра. Суть розробленого підходу полягає в тому, що в обміні захищеними документами кожен абонент використовує пару взаємопов'язаних ключів – відкритий і секретний. Відправник підписуваного документа передає одержувачу відкритий ключ. Він може це зробити будь-яким несекретних способом або помістити ключ в загальнодоступний довідник. За допомогою відкритого ключа одержувач перевіряє справжність одержуваної інформації. Секретний ключ, за допомогою якого підписувалася інформація, зберігається в таємниці від усіх.

Можна помітити, що в даній схемі абоненти використовують різні ключі, що не дозволяє шахраювати жодної зі сторін. Докладний аналіз цифрового підпису на основі криптосистем з відкритими ключами показує, що вона повністю задовольняє вимогам, що пред'являються до неї та вказаним на початку статті. На даний момент широкого відомі цифрові підписи, побудовані за алгоритмами RSA, Ель-Гамаля, Шнорр, Рабіна та математичного апарату еліптичних кривих.

Хеш-функція

Як показує практика, алгоритми з відкритим ключем дуже неефективні з-за низької швидкості обробки великого об'єму даних. Для зменшення часу на генерацію та перевірку підпису, а також для скорочення її розміру застосовується спеціальний механізм, званий хеш-функцією (hash function), який є відображенням підписується повідомлення в рядок фіксованої довжини, багато меншою розміру самого повідомлення. Замість підпису самого документа підписується хеш-функція цього документа. Аналогічним чином перевіряється підпис не самого документа, а його хеш-функції.

Зберігання ключів

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

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

Розподіл ключів

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

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

Стандарти

У Росії в 1994 році були прийняті стандарти ГОСТ Р 34.10-94 "Криптографічний захист інформації. Процедури вироблення і перевірки електронного цифрового підпису на базі асиметричного криптографічного алгоритму" і ГОСТ Р 34.11-94 "Криптографічний захист інформації. Функція хешування". Чим можуть допомогти користувачу дані стандарти? По-перше, вони повинні гарантувати крипостійкість, тобто надійність реалізованих по них алгоритмів. По-друге, застосування стандартів має забезпечити сумісність продуктів різних виробників. Проте є і проблеми при використанні прийнятих стандартів.

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

Як вже зазначалося, використання стандарту має гарантувати, що документи, підписані за допомогою ГОСТ Р 34.10-94, теоретично не можуть бути підроблені за прийнятний для зловмисника час. Однак на практиці справа не завжди йде таким чином. Пов'язано це з тим, що стандарт описує алгоритм математичною мовою, в той час як користувачі стикаються вже з його реалізацією. А при реалізації можуть бути допущені різні помилки, які зводять нанівець всі достоїнства алгоритму. Крім того, ефективне застосування систем ЕЦП залежить від їх правильної експлуатації. Наприклад, зберігання секретних ключів для генерації цифрового підпису на доступному всім жорсткому диску дозволяє зловмисникові одержати до них доступ і надалі підробляти документи, підписані на цих ключах.

Тому далеко не завжди зазначені системи забезпечують необхідний рівень захищеності.

Вимоги користувачів

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

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

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

Оскільки при придбанні системи цифрового підпису, як правило, у замовника вже склалася інформаційна інфраструктура, то дуже часто на перше місце виходить питання про інтеграцію купується системи в прийняту технологію обробки інформації. Наприклад, якщо в якості засобу відправки електронної пошти використовується Microsoft Outlook, то необхідно, щоб система ЕЦП могла бути вбудована в цю поштову програму. Таку можливість пропонують багато зарубіжних і деякі російські системи ЕЦП, наприклад, PGP (Pretty Good Privacy), яка також може бути вбудована в поштову програму Eudora, нарівні з Microsoft Outlook, широко поширену в Росії. Якщо система ЕЦП не підтримує використовуване у замовника програмне забезпечення (наприклад, тому що вона розроблена самим замовником), то постачальник повинен поставляти інтерфейс (API) для вбудовування можливостей роботи з цифровим підписом в систему замовника. Таку можливість пропонують багато російські виробники (наприклад, МО ПНІЕІ, ЛАН КРИПТО, НИП "Информзащита"). Причому бажано, щоб даний інтерфейс існував для різних операційних систем і платформ (Windows NT, Windows 9x, MS DOS, HP UX, AIX і т.д.).

Необхідно звернути увагу на запропоновані механізми або заходи захисту від несанкціонованого доступу до системи електронного цифрового підпису. Повинні бути передбачені дії, що виконуються у разі компрометації ключів одного з користувачів (наприклад, занесення їх в "чорні списки" і розсилка всім користувачам системи). Крім того, повинна контролюватися цілісність як системи ЕЦП в цілому, так і її компонентів (Наприклад, журналів реєстрації дій). У документації на деякі російські системи ЕЦП є рекомендації щодо застосування систем захисту інформації від несанкціонованого доступу. Дані системи, в Зокрема, дозволяють обмежити коло осіб, які мають право запуску системи цифрового підпису. Однією з таких систем є сертифікована в Гостехкомиссии Росії система Secret Net, розроблена Науково-інженерним підприємством "Информзащита".

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

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

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

Атаки на цифровий підпис

Користувачеві системи електронного цифрового підпису необхідно знати, яким чином зловмисник може здійснити атаку на ЕЦП. У документації на багато систем цифрового підпису дуже часто згадується число операцій, які треба здійснити для перебору всіх можливих ключів. Однак це лише один з можливих варіантів реалізації атак. Кваліфікований зловмисник далеко не завжди використовує такий "Грубий" перебір (brute force search) всіх можливих ключів. Розглянемо докладніше деякі з типів атак.

Атаки на алгоритми

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

Крім того, іноді в російських журналах або телеконференціях в мережі Internet і FIDOnet можна прочитати повідомлення про оптимізацію існуючих стандартів (наприклад, ГОСТ 28147-89 або DES), які нібито не знижують надійності самих стандартів, а швидкість роботи при цьому зростає на один-два порядки. До таких повідомленнями треба ставитися з певним ступенем скептицизму. Вигоди від застосування "оптимізованих" алгоритмів сумнівні, а от імовірність фальсифікації документів, підписаних з їх допомогою, збільшується.

Атаки на криптосистему

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

Для алгоритмів, заснованих на відкритих ключах, наприклад, RSA або Ель-Гамаля, існує ряд математичних проблем, які не завжди враховуються при побудові криптосистеми. До таких моментів можна віднести вибір початкових значень, на основі яких створюються ключі. Є певні числа, які дозволяють дуже швидко вирахувати секретний ключ ЕЦП. У той же час правильний вибір початкових значень дозволяє гарантувати неможливість "лобової" атаки протягом кількох сотень років при сучасному розвитку обчислювальної техніки.

Атаки на реалізацію

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

Як приклад атаки на реалізації систем ЕЦП можна назвати випадок, описаний в середині 90-х років у вітчизняній пресі і пов'язаний з установлюваної "закладкою" в широко поширену програму PGP.

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

Атаки на користувачів

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

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

Висновок

Описані в цій статті аспекти показують, що вибір системи електронного цифрового підпису – непросте завдання, вирішення якої необхідно приділити серйозну увагу. Не існує готових рецептів. Правильний вибір – це не просто перегляд рекламних буклетів, отриманих на виставці, або ознайомлення з Web-сервером постачальника системи ЕЦП. Це кропіткий процес, в якому повинно враховуватися безліч факторів. Це і необхідність інтеграції в прийняту технологію обробки інформації, і необхідність наявності сертифіката ФАПСИ, і алгоритм розподілу ключів, і т.д.

Зробіть правильний вибір – і Ваша інформація буде надійно захищена від підробки.

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

1. Bruce Schneier. Applied Cryptography, Second edition. John Wiley & Sons, 1996

2. Брюс Шнайер. Слабкі місця криптографічних систем. "Відкриті системи", № 1, 1999.

3. Ю. Мельников. Електронний цифровий підпис: чи завжди вона справжня? Банківські технології, № 5, 1995.

Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*