Secure Electronic Transaction (SET)

- це стандартизований протокол для проведення операцій по кредитній/банківській карті через небезпечні мережі (наприклад інтренет).

SET це не сама платіжна система, це набір правил і протоколів безпеки (цифрових сертифікатів, криптографічних технологій) для автентифікації здійснюваних транзакцій. Це дозволяє користувачам безпечно використовувати кредитно/банківські картки в відкритій мережі. Однак, SET так і не став популярним протоколом. VISA тепер продвигає XML-протоколи 3-D Secure.

Більш детальний огляд даного протоколу можна знайти у стандарті RFC 3538

Важливим нововведенням в протокол є включений подвійний підпис . Мета подвійного підпису така ж , як стандартного електронного підпису : гарантувати автентифікацію і цілісність даних. Він пов'язує два повідомлення, які призначені для двох різних одержувачів . У цьому випадку , клієнт хоче послати інформацію про замовлення ( OI ) до купця і платіжну інформацію ( PI) в банк. Продавцеві не потрібно знати номер кредитної картки клієнта , і банку не потрібно знати деталі замовлення клієнта. Посилання необхідне , щоб користувач зміг довести , що платіж призначено для цього замовлення.Дайджесту повідомлення (MD ) з OI і PI незалежно генерується замовником. Подвійний підпис зашифрованого MD (з закритим ключем клієнта) каскадного МД ПІ і ОІ. Подвійний підпис передається продавцеві і банку . Протокол організовує для торговця , щоб побачити MD ПІ , не бачачи PI себе , а банк бачить MD з OI , але не О.І. себе . Подвійний підпис можна перевірити за допомогою МД О.І. або ІП . Він не вимагає OI або PI . Його МД не розкривають зміст OI або ІП , і , таким чином конфіденційність зберігається.

Отже SET — це відкритий стандарт який має підтримку з боку таких фірм, як:

● IBM● Microsoft● Visa, MasterCard● GTE● VerySign, RSA

Розрахункова система у SET

SET угода 1-Клієнт відкриває картковий рахунок -Mastercard, Visa..-клієнт отримує угоду ,підписану банком;-продавець, який обирає певну марку карти мусить мати 2 сертифікати-один для підпису, один для обміну ключа;-клієнт передає замовлення на продукт або послугу продавцеві ;-продавець надсилає копію сертифіката для підтвердження.

SET угода 2-клієнт надсилає замовлення і платіжне повідомлення продавцеві;-продавець вимагає підтвердження платежу до відправлення замовлення;-продавець оформляє замовлення клієнту;-продавець надає товари або послуги клієнтові;-продавець вимагає оплати товарів або послуг.

Переваги SET● Технології які використовуються

- як механізм шифрування використовуються симетричні або відкриті ключі

- використання цифрових сертифікатів

- подвійний підпис● Перевірка достовірності

- цифрові сертифікати● Цілісність

- використання симетричного шифрування

- шифрування з використанням відкритих ключів

Характеристики протокола SET

• Протокол SЕТ є стійким протоколом

• Протокол SET є єдиним (відомим) відкритим стійким протоколом в електронній комерції

• Протокол SET є галузевим стандартом в області пластикових карт

Архітектура системи

Реалізація транзакцій в протоколі SET

• Замовлення на запит / Відповідь• Запит на авторизацію / Відповідь• Шлюз запиту сертифіката / Відповідь• Пакетний запит адміністрації / Відповідь• Інформаційний запит / Відповідь• Запит авторизації / Відповідь• Визначення запиту / Відповідь• Запит на отримання кредита/ Відповідь• Відновлення кредитування/ Відповідь

У протоколі SET використовуються чотири типи пар асиметричних ключів, що відрізняються один від одного за своїм призначенням:

• ключ для підпису (Digital Signature Key, використовується для ідентифікації власника ключа);

• ключ для шифрування даних (Key Encipherment / Data Encipherment Key, чи інакше KeyExchange Key, ключ, використовуваний для шифрування даних в процесі проведення транзакції;

• ключ для підписування сертифікатів (Certificate Signature Key);

• ключ для підписування списків відкликаних сертифікатів CRL (CRL Signature Key).

Формат сертифіката відкритого ключа у протоколі SET задовольняє стандарту Х.509 v.3 .Сертифікат містить такі дані:• версію протоколу Х.509 ( завжди встановлюється значення, рівне 3);• Serial Number - серійний номер сертифіката - унікальний цілочисельний номер сертифіката , присвоюється центром сертифікації , що видав сертифікат;• Algorithm Identifier - ідентифікатор алгоритму електронного цифрового підписи , використовуваного центром сертифікації для підписування сертифіката ;• Issuer Name - ім'я центру сертифікації , генеруючого сертифікат;• термін початку дії сертифіката;• термін закінчення дії сертифіката;• Subject Name - ім'я власника сертифіката;• ідентифікатор алгоритму , в якому буде використовуватися сертифікується ключ;• значення відкритого ключа який сертифікується;• рівень власника сертифіката в протоколі SET , тип сертифіката (сертифікат власника карти , сертифікат торгової точки тощо ) ;• цифровий підпис сертифіката , зроблену з використанням Certificate Signing Key центру сертифікації .

Справжність SET-сертифікатів визначається за допомогою ієрархічного ланцюга перевірок.

Порівнюються наступні поля:• поля Issuer Name у сертифікаті нижнього рівня і Subject Name у сертифікаті більш високого рівня ;• поля Certlssuer і CertSerialNumber з Х.509 Extensions сертифіката нижнього рівня відповідно з полями Issuer Name і Serial Number у сертифікаті більш високого рівня. При позитивному результаті порівняння в сертифікаті нижнього рівня перевіряється термін дії сертифіката;• термін дії ключа , зазначеного в сертифікаті ;• рівень власника сертифіката в ієрархії системи центру сертифікації ;• відповідність типу сертифіката його вмісту.У сертифікаті вищого рівня перевіряється :• термін дії сертифіката;• термін дії ключа , зазначеного в сертифікаті ;• рівень власника сертифіката в ієрархії системи центру сертифікації ;• відповідність типу сертифіката його вмісту ;• використання за призначенням ключа , зазначеного в сертифікаті , і деякі інші поля.

Наведемо тепер процедуру отримання сертифіката відкритого ключа власником карти більш детально , ілюструючи , яким чином здійснюється вирішення основних завдань захищеного обміну інформацією - аутентифікації джерела інформації та забезпечення цілісності і конфіденційності переданої в процесі сертифікації інформації.1 . Власник карти генерує запит 2 . ССА обробляє отримане від власника карти повідомлення CardCInitReq , виробляючи такі перевірки :3 . Після цього ССА генерує відповідь ( в термінології SET - CInitCardRes ), що з підписуваних за допомогою ССА Private Signature Key даних. 4 . Власник карти ( точніше , звичайно , його програмне забезпечення) , отримавши повідомлення CardCInitRes , перевіряє сертифікати ССА Key- Exchange Key і ССА Signature Key , а також цифровий підпис ССА . 5 . Далі власник карти передає на адресу ССА запит на отримання реєстраційної форми (у термінології SET - RegFormReq ) . 6 . ССА , отримавши повідомлення RegFormReq , за допомогою свого Private Key - Exchange Key розшифровує номер карти і значення ключа Кр , і далі за допомогою ключа Кр , дешифрує RegForinReqData .7 . За номером картки та мови власника карти ССА , визначає відповідну реєстраційну форму для власника карти , підписує цю форму разом з іншими даними (включаючи Chall - EE2 ) своїм ключем Private Signature Key і відправляє її власнику картки.8 . Власник карти знову перевіряє сертифікат ключа Private Signature Key і цифровий підпис ССА 9 . ССА , отримавши повідомлення CertReq , за допомогою ССА Private Signature Key розшифровує значення Kp , далі розшифровує реєстраційну форму і ключ Kz , перевіряє цифровий підпис власника картки. 10 . Власник карти за допомогою раніше запомненного значення ключа K розшифровує отримане повідомлення CertRes , перевіряє сертифікат свого відкритого ключа і формує значення секрету S , яке в подальшому використовується власником картки при проведенні транзакції , про що буде розказано далі .

Таким чином , процедура отримання сертифіката відкритого ключа складається з трьох етапів.1 . Перший етап характеризується отриманням власником карти відсутніх списків CRL і аутентифікацією ССА (використовується стандартна процедура « рукостискання» , коли власник картки повідомляє ССА деякий випадкове число , а ССА повертає підписані ним дані, що містять це випадкове число ) .2 . На другому етапі в захищеній з допомогою отриманого відкритого ключа ССА сесії власник карти запитує в ССА реєстраційну форму , повідомляючи ССА номер своєї карти. ССА залежно від номера картки надає власнику картки реєстраційну форму.Нарешті , на третьому етапі клієнт заповнює реєстраційну форму , включаючи в неї свій відкритий ключ , і направляє , її власнику картки. Натомість клієнт отримує від ССА сертифікат відкритого ключа та деякий секрет , використовуваний для маскування номера картки в сертифікаті , а також для подальшої аутентифікації власника карти його банком- емітентом.

Сертифікат може бути відкликаний за однією з наступних причин:• відповідний сертифікатом секретний ключ став відомий зловмиснику;• сертифікат належить суб'єкту системи центру сертифікації SET, по яким-небудь обставинам припинив своє функціонування;• змінилися облікові дані сертифіката.

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

Тип злочину SET вирішує проблему? SSL вирішує проблему?

Злочинні транзакції по “правильним” картам

Так Ні

Зловживання магазинів Так Ні

Фіктивні магазини Ні Ні

Фіктивниі банки Так Ні

Компрометація данних Так Так

Дякую за увагу