5.4. Цифрові підписи

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

• після обчислення дайджеста до повідомлення не вносилися зміни (цілісність повідомлення);

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

5.5. Сертифікати

У найзагальнішому вигляді цифрові сертифікати - це структура даних, яка містить дві інформаційні частини:

• ідентифікацію (наприклад, ім'я, контактна адреса і ін.) власника сертифікату (індивідуума або організації); і відкритий ключ власника сертифікату.

• відкритий ключ власника сертифікату.

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

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

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

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

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

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

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

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

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

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

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

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

Лістинг 1 - це простій SOAP-запит, який передає в Web-сервіс готелю виклик методу GetSpecialDiscountedBookingForPartners. У цьому SOAP-запиті відсутні які-небудь дані про цілісність повідомлення або призначеної для користувача аутентифікації. Лістинг 1 - це початкова точка демонстрації застосування специфікації “Цифровий підпис XML”.

Лістинг 1

<?xml version=”1.0”?>

<SOAP-ENV:Envelope

xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”>

<SOAP-ENV:Body>

<s:GetSpecialDiscountedBookingForPartners

xmlns:s=“http://www.MyHotel.com/partnerservice/”>

<!--Parameters passed with the method call--> </s:GetSpecialDiscountedBookingForPartners>

</SOAP-ENV:Body>

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

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