Універсальна двофакторна автентифікація

U2F (англ. Universal 2nd Factor - відкритий, бездрайверний протокол для двофакторної автентифікації, заснований на виклик-відповідь автентифікації, що дозволяє інтернет-користувачам використовувати U2F пристроєм як другим чинником для автентифікації на великій кількості онлайн-служб.

Передумови та історія створення

[ред. | ред. код]

Події, пов'язані з масовими зломами облікових записів, підтверджують необхідність захисту даних, що знаходяться на онлайн-службах. Часто облікові записи користувачів захищені слабкими паролями, користувачами використовується однаковий пароль в різних облікових записах, що сприяє масовим зломам. Тому сувора автентифікація стає все більш важливою вимогою. Більшість рішень, що забезпечують сувору автентифікацію дорожчою і складнішою у використанні (особливо з мобільними пристроями). Водночас, наприклад, другий чинник у вигляді OTP вразливий для відносно загальних атак, таких як фішинг, смарткарти вимагають спеціалізованого обладнання та/або установки драйверів перед використанням. В ідеалі база для безпечної автентифікації повинна відповідати таким вимогам, як: використання суворої автентифікації, дотримання конфіденційності користувача, зручність використання і взаємодія між різними пристроями, за допомогою яких проводиться автентифікація. Для розв'язання цих питань утворився FIDO Alliance[en], некомерційна організація, сформована в липні 2012 року[1].

30 червня 2015 року було випущено дві нові версії протоколу, що підтримують Bluetooth і NFC, як транспортні протоколи для U2F. Таким чином стала можлива автентифікація за допомогою протоколу U2F за допомогою мобільних пристроїв, використовуючи технологію NFC.

7 грудня 2016 року було оголошено оновлені специфікації протоколу U2F v1.1[п 1].

Робота протоколу

[ред. | ред. код]

Реєстрація користувача

[ред. | ред. код]
Схема реєстрації на вебсервісі

Під час реєстрації перевірна сторона (вебсервіс, цільовий ресурс) відправляє деякі дані для підпису пристроєм (тобто генерує виклик) браузеру. Браузер додає до даних URI, з якого був зроблений запит на підпис та ID каналу TLS і відправляє їх на U2F пристрій. Для успішної реєстрації, користувач повинен підтвердити свою згоду, пройшовши «тест на присутність користувача» (наприклад, натиснувши кнопку, що знаходиться безпосередньо на U2F пристрої), після чого U2F пристрій всередині себе генерує реєстраційно-залежну (тобто унікальну для даного пристрою, вебсервісу і призначеного для користувача облікового запису) пару відкритий/закритий ключ і відповідний цій парі дескриптор ключа (key handle (наприклад, випадкове число)), далі повертає відкритий ключ, дескриптор ключа, атестаційний сертифікат пристрої (сервер (необов'язково) перевіряє справжність пристрою. Наприклад, банківський сайт, можливо, зажадає наявності U2F пристрої певних постачальників) і підпис виклику браузеру. Браузер відправляє ці дані назад на цільовий ресурс, де відбувається верифікація підпису виклику, запам'ятовується відкритий ключ і дескриптор ключа, що асоціюються з даними призначеним для користувача обліковим записом[2].

Автентифікація користувача

[ред. | ред. код]
Схема автентифікації на вебсервісі

Під час автентифікації перевіряє сторона відправляє деякі дані (тобто генерує виклик) і дескриптор ключа для підпису браузера. Браузер додає до цього URI, з якого був зроблений запит на підпис та ID каналу TLS і відправляє на U2F пристрій. Перш ніж підписати, U2F пристрій повинен «побачити» пройдений «тест на присутність користувача». Використовуючи дескриптор ключа, пристрій вибере відповідний йому закритий ключ для підпису, і якщо пристрій не "визнає" дескриптор або пов'язаний з закритим ключем URI, то запит на підпис відхиляється. Якщо все пройшло успішно, то проводиться підпис даних клієнта. Для запобігання клонування пристрою, всередині нього знаходиться лічильник, який за будь-якої автентифікації збільшує своє значення. Його значення так само підписується і відправляється перевірній стороні[2].

Небраузерні застосунки

[ред. | ред. код]

Вебзастосунок за допомогою браузера контактує з U2F пристроєм за допомогою JavaScript API[2]. Мобільний додаток так само має «спілкуватися» з пристроєм за допомогою API, при побудові якого використовується поняття web origin (вище згаданий URI для вебзастосунків). Для можливості роботи з різними API було вирішено використовувати фасети (facets). Фасет - це виконання програми, яке контактує з перевірною стороною[3]. Наприклад, застосунок Example може мати реалізацію під Android, IOS або вебзастосунок. Усе це фасети застосунку Example.

Facet ID - це ідентифікатор (URI), який призначається виконання програми для конкретної платформи [4] :

  • для вебзастосунків визначено у RFC 6454 ;
  • для Android додатків - це URI android: apk-key-hash: <hash-ofapk-signing-cert>;
  • для IOS додатків - це URI ios: bundle-id: <ios-bundle-id-of-app>.

AppID - це URL, який вказує на JSON файл, який містить список дозволених facet IDs. AppID є частиною переданих даних при реєстрації та автентифікації, тому для успішного їх проходження потрібно, щоб facet ID був дозволений в списку, що містить facet IDs, пов'язаному з цим AppID[2][4].

Наприклад, для застосунку Example список дозволених facet IDs може виглядати наступним чином:

{
"trustedFacets": [{
  "version": { "major": 1, "minor" : 0 },
  "ids": [
   "https://accounts.example.com",
   "https://myaccount.example.com",
   "https://security.example.com",
   "android:apk-key-hash:FD18FA800DD00C0D9D7724328B6...",
   "android:apk-key-hash:Rj6gA3QDA2ddyQyi21JXly6gw9...",
   "ios:bundle-id:com.example.SecurityKey.dogfood"
  ]
 }]
}

Особливості

[ред. | ред. код]

Криптографічні примітиви

[ред. | ред. код]

Для операцій підписування використовується алгоритм ECDSA над кривою P-256, для операцій хешування- SHA-256[5], які широко доступні на вбудованих платформах і досить надійні[6][7].

Запобігання атаки посередника

[ред. | ред. код]

Коли ID каналу TLS додається до даних клієнта під час роботи протоколу, сервер може виявити потенційну атаку посередника. Концепція ID каналу TLS представлена в документі IETF [8] і дозволяє серверу виявити атаку, якщо є два роздільних канали TLS. Ця концепція була впроваджена в специфікації протоколу U2F, але проте в цьому підході були виявлені проблеми та запропоновані шляхи вирішення[9].

Нестандартизовані рішення

[ред. | ред. код]

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

  • Утворення реєстраційно-залежної пари закритий/відкритий ключ. Наприклад, кожен Yubikey має свій майстер-ключ, який у зв'язці з HMAC і ГПСЧ утворює нову пару[10].
  • Лічильник. Передбачає собою додатковий захист U2F пристрою від клонування. Проте захист таким способом може не спрацювати, наприклад, якщо після клонування, оригінальний U2F пристрій якийсь час не використовувався для автентифікації. Для якої пари ключів і на яке значення під час автентифікації збільшується його значення специфікаціями не описано. Проте, якщо в пристрої використовується єдиний глобальний лічильник з передбачуваною сумою приросту, це створює витік конфіденційності [11]
  • Дескриптор ключа. U2F пристрій може не зберігати всі закриті ключі всередині пристрою, а, наприклад, кожен закритий ключ може бути зашифрованою частиною дескриптора ключа[12]. У цьому випадку повинен використовуватися алгоритм шифрування, найкращим чином забезпечує безпеку при наявному апаратному забезпеченні.

Джерела

[ред. | ред. код]
  1. ↑ Malte Kahrs, Dr. Kim Nguyen. Future Ecosystems for Secure Authentication and Identification // ISSE 2015. — Springer Vieweg, 2015. — P. 12—21. — ISBN 978-3-658-10934-9. — DOI:10.1007/978-3-658-10934-9_2.
  2. ↑ а б в г U2F v1.1 Specifications (PDF) (англ.). {{cite web}}: Проігноровано невідомий параметр |accessyear= (можливо, |access-date=?) (довідка)
  3. ↑ U2F v1.1 Specifications (PDF) (англ.). {{cite web}}: Проігноровано невідомий параметр |accessyear= (можливо, |access-date=?) (довідка)
  4. ↑ а б U2F v1.1 Specifications (PDF) (англ.). {{cite web}}: Проігноровано невідомий параметр |accessyear= (можливо, |access-date=?) (довідка)
  5. ↑ U2F v1.1 Specifications (PDF) (англ.). {{cite web}}: Проігноровано невідомий параметр |accessyear= (можливо, |access-date=?) (довідка)
  6. ↑ FIPS PUB 186-4 (PDF) (англ.). {{cite web}}: Проігноровано невідомий параметр |accessyear= (можливо, |access-date=?) (довідка)
  7. ↑ FIPS PUB 180-4 (PDF) (англ.). Архів оригіналу (PDF) за 26 листопада 2016. Процитовано 31 грудня 2016. {{cite web}}: Проігноровано невідомий параметр |accessyear= (можливо, |access-date=?) (довідка)
  8. ↑ D. Balfanz, R. Hamilton. Transport Layer Security (TLS) Channel IDs (англ.).
  9. ↑ Nikolaos Karapanos, Srdjan Capkun. On the Effective Prevention of TLS Man-in-the-Middle Attacks in Web Applications (PDF) (англ.).
  10. ↑ Key generation.
  11. ↑ Juan Lang, Alexei Czeskis, Dirk Balfanz, Marius Schilder, and Sampath Srinivas. Security Keys: Practical Cryptographic Second Factors for the Modern Web (PDF) (англ.).
  12. ↑ U2F v1.1 Specifications (PDF) (англ.). {{cite web}}: Проігноровано невідомий параметр |accessyear= (можливо, |access-date=?) (довідка)

Примітки

[ред. | ред. код]
  1. ↑ FIDO Alliance Announces Updated Authentication Specification Roadmap to Meet Growing Demand for Simpler, Stronger Authentication (англ.). Архів оригіналу за 16 січня 2017. Процитовано 25 березня 2021. [Архівовано 2017-01-16 у Wayback Machine.]