У цілому система обміну при використанні асиметричного шифрування виглядає в такий спосіб. Для кожного з N абонентів, що ведуть обмін, обрана своя пара ключів: "відкритий" E_j і "закритий" D_j, де j - номер абонента. Усі відкриті ключі відомі всім користувачам мережі, кожен закритий ключ, навпаки, зберігається тільки в того абонента, якому він належить. Якщо абонент, скажемо під номером 7, збирається передати інформацію абонентові під номером 9, він шифрує дані ключем шифрування E₉ і відправляє її абонентові 9. Незважаючи на те, що всі користувачі мережі знають ключ E₉ і, можливо, мають доступ до каналу, по якому йде зашифроване послання, вони не можуть прочитати вихідний текст, тому що процедура шифрування необоротна по відкритому ключі. І тільки абонент №9, одержавши послання, робить над ним перетворення за допомогою відомого тільки йому ключа D₉ і відновлює текст послання. Помітьте, що якщо повідомлення потрібно відправити в протилежному напрямку (від абонента 9 до абонента 7), те потрібно буде використовувати вже іншу пару ключів (для шифрування ключ E₇, а для розшифрування - ключ D₇).

Як ми бачимо, по-перше, в асиметричних системах кількість існуючих ключів зв'язано з кількістю абонентів лінійно (у системі з N користувачів використовуються 2*N ключів), а не квадратично, як у симетричних системах. По-друге, при порушенні конфіденційності k-ої робочої станції зловмисник довідається тільки ключ D_k: це дозволяє йому читати всі повідомлення, що приходять абонентові 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 і обчислює

y₁ = g^k mod p і

y₂ = m y^k,

де означає побітове додавання по модулі 2. Потім Борис посилає (y₁,y₂) Олександру.

Олександр, одержавши зашифроване повідомлення, відновлює його:

m = (y₁^a mod p) y₂.

Алгоритм цифрового підпису 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-формат даних про цілісність повідомлення, його автентифікації і користувальницької автентифікації.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При реалізації специфікації "Цифровий підпис 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.

Кореневий елемент 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, у якому зашифрований елемент GetSpecial Discounted Booking For Partners з Лістінгу 1 отриманий простою заміною елементом Encrypted Data.

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

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

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

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

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-запит GetSpecial Discounted Booking For Partners, що неодноразово приводився в цій статті. Однак цього разу заголовок запиту передає інформацію про цифровий підпис відповідно до розглянутої специфікації.

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

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

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

3. Елемент wsse: Binary Security Token містить маркер доступу (security token). Маркер доступу подібний пропускові, видаваному службою безпеки, або посвідченню особи, яких необхідно пред'явити при вході в область обмеженого доступу. Нижче описані основні типи маркерів доступу.

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

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

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

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

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

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

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

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

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

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

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

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

Висновок

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Размещено на Allbest.ru