Secure Electronic Transaction (SET)

1. Secure Electronic Transaction (SET)

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

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

5. Отже SET — це відкритий стандарт який має підтримку з боку таких фірм, як: IBM Microsoft Visa, MasterCard GTE VerySign, RSA

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

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

8. Переваги SET Технологіїяківикористовуються - як механізмшифруваннявикористовуютьсясиметричніабовідкритіключі - використанняцифровихсертифікатів - подвійнийпідпис Перевіркадостовірності - цифровісертифікати Цілісність - використаннясиметричногошифрування - шифрування з використаннямвідкритихключів

9. Характеристики протокола SET • Протокол SЕТ є стійким протоколом • Протокол SET є єдиним (відомим) відкритимстійким протоколом в електроннійкомерції • Протокол SET є галузевим стандартом в областіпластикових карт

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

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

12. У протоколі SET використовуються чотири типи пар асиметричних ключів, що відрізняються один від одного за своїм призначенням: • ключ для підпису (Digital Signature Key, використовується для ідентифікації власника ключа); • ключ для шифрування даних (Key Encipherment / Data Encipherment Key, чи інакше KeyExchange Key, ключ, використовуваний для шифрування даних в процесі проведення транзакції; • ключ для підписування сертифікатів (Certificate Signature Key); • ключ для підписування списків відкликаних сертифікатів CRL (CRL Signature Key).

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

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

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

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

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

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