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

Схема реєстрації на вебсервісі

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