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

U2F (англ. Universal 2nd Factor) — открытый, бездрайверный протокол для двухфакторной аутентификации, основанный на вызов-ответной аутентификации, позволяющий интернет-пользователям использовать U2F устройство как второй фактор для аутентификации на большом количестве онлайн-сервисов.

Предпосылки и история создания

События, связанные с массовыми взломами аккаунтов ^{[п 1] [п 2] [п 3]}, подтверждают необходимость защиты данных, находящихся на онлайн-сервисах. Часто учётные записи пользователей защищены слабыми паролями ^{[п 4]}, пользователями используется одинаковый пароль в разных учетных записях, что способствует массовым взломам.^{[п 5]} Поэтому строгая аутентификация становится все более важным требованием. Большинство решений, обеспечивающих строгую аутентификацию дороже и сложнее в использовании (особенно с мобильными устройствами). В то же время, например, второй фактор в виде OTP уязвим для относительно общих атак, таких как фишинг ^{[п 6]}, смарт-карты требуют специализированного оборудования и/или установки драйверов перед использованием. В идеале база для безопасной аутентификации должна соответствовать таким требованиям, как: использование строгой аутентификации, соблюдение конфиденциальности пользователя, удобство использования и взаимодействие между различными устройствами, с помощью которых производится аутентификация. Для решения этих вопросов образовался FIDO Alliance, некоммерческая организация, сформированная в июле 2012 года^[1].

Спецификации протокола U2F v1.0 были опубликованы FIDO Alliance 9 декабря 2014 года^{[п 7]}.

30 июня 2015 года были выпущены две новые версии протокола, поддерживающие Bluetooth и NFC, как транспортные протоколы для U2F ^{[п 8]}. Таким образом стала возможна аутентификация посредством протокола U2F с помощью мобильных устройств, используя технологию NFC.

В конце 2015 года началась работа над усовершенствованными спецификациями, называемыми FIDO 2.0^{[п 9]}.

7 декабря 2016 года были объявлены обновленные спецификации протокола U2F v1.1^{[п 10]}.

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

FIDO U2F протокол основан на криптосистеме с открытым ключом^[2].

Регистрация пользователя

Схема регистрации на веб-сервисе

Во время регистрации проверяющая сторона (веб-сервис, целевой ресурс) отправляет некоторые данные для подписи устройством (то есть генерирует вызов) браузеру. Браузер добавляет к данным 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 и ГПСЧ генерирует новую пару^{[п 11]}.

• Счетчик. Предполагает собой дополнительную защиту U2F устройства от клонирования. Тем не менее защита таким способом может не сработать, например, если после клонирования, оригинальное U2F устройство какое-то время не использовалось для аутентификации. Для какой пары ключей и на какое значение во время аутентификации увеличивается его значение спецификациями не описано. Тем не менее, если в устройстве используется единый глобальный счетчик с предсказуемой суммой прироста, это создает утечку конфиденциальности^[10].

• Дескриптор ключа. U2F устройство может не хранить все закрытые ключи внутри устройства, а, например, каждый закрытый ключ может быть зашифрованной частью дескриптора ключа^[11]. В этом случае должен использоваться алгоритм шифрования, лучшим образом обеспечивающий безопасность при имеющемся аппаратном обеспечении.

Поддержка браузерами

U2F поддерживается Google Chrome, начиная с 38 версии, Opera — начиная с 40 версии^{[п 12]}. Mozilla добавила поддержку U2F в Firefox, которая может быть включена только путём добавления специального дополнения^{[п 13]}. Для браузера Google Chrome на Android OS была осуществлена поддержка U2F протокола посредством использования приложения Google Authenticator и U2F устройства с поддержкой NFC^{[п 14]}.

Источники

1. Malte Kahrs, Dr. Kim Nguyen. Future Ecosystems for Secure Authentication and Identification // ISSE 2015. — Springer Vieweg, 2015. — P. 12—21. — 315 p. — ISBN 978-3-658-10934-9. — ISBN 978-3-658-10933-2. — doi:10.1007/978-3-658-10934-9_2.
2. U2F v1.1 Specifications. Universal 2nd Factor (U2F) Overview (англ.). Дата обращения: 23 декабря 2016. Архивировано 24 декабря 2016 года.
3. U2F v1.1 Specifications. FIDO Technical Glossary (англ.). Дата обращения: 25 декабря 2016. Архивировано 25 декабря 2016 года.
4. U2F v1.1 Specifications. FIDO AppID and Facet Specification (англ.). Дата обращения: 23 декабря 2016. Архивировано 24 декабря 2016 года.
5. U2F v1.1 Specifications. FIDO U2F Raw Message Formats (англ.). Дата обращения: 31 декабря 2016. Архивировано 1 января 2017 года.
6. FIPS PUB 186-4. Digital Signature Standard (DSS) (англ.). Дата обращения: 31 декабря 2016. Архивировано 27 декабря 2016 года.
7. FIPS PUB 180-4. Secure Hash Standard (SHS) (англ.). Дата обращения: 31 декабря 2016. Архивировано из оригинала 26 ноября 2016 года.
8. D. Balfanz, R. Hamilton. Transport Layer Security (TLS) Channel IDs (англ.). Дата обращения: 2 января 2017. Архивировано 3 января 2017 года.
9. Nikolaos Karapanos, Srdjan Capkun. On the Effective Prevention of TLS Man-in-the-Middle Attacks in Web Applications (англ.). Дата обращения: 2 января 2017. Архивировано 3 января 2017 года.
10. Juan Lang, Alexei Czeskis, Dirk Balfanz, Marius Schilder, and Sampath Srinivas. Security Keys: Practical Cryptographic Second Factors for the Modern Web (англ.). Дата обращения: 2 января 2017. Архивировано 6 января 2017 года.
11. U2F v1.1 Specifications. FIDO U2F Implementation Considerations (англ.). Дата обращения: 1 января 2017. Архивировано 1 января 2017 года.

Примечания

1. James Fallows. Hacked! (англ.) // The Atlantic. — 2011. — November.
2. Mat Honan. How Apple and Amazon Security Flaws Led to My Epic Hacking (англ.) // Wired. — 2012. — 8 June.
3. Charles Arthur. Naked celebrity hack: security experts focus on iCloud backup theory (англ.) // The Guardian. — 2014. — 1 September.
4. Joseph Bonneau. 2012 IEEE Symposium on Security and Privacy. The science of guessing: analyzing an anonymized corpus of 70 million passwords (англ.).
5. К чему приведет взлом вашей почты (рус.) // Профиль : журнал. — Москва: ИДР-Формат, 2014. — Сентябрь (вып. 34[875]). — ISSN 1726-0639. Архивировано 13 января 2017 года.
6. John Scott-Railton, Katie Kleemola. London Calling: Two-Factor Authentication Phishing From Iran (англ.) // The Citizen Lab. — 2015. — 27 August.
7. FIDO 1.0 Specifications are Published and Final Preparing for Broad Industry Adoption of Strong Authentication in 2015 (англ.).
8. Sean Michael Kerner. FIDO Alliance Extends Two-Factor Security Standards to Bluetooth, NFC (англ.) // eWeek. — 2015. — 1 July.
9. Submission Request to W3C: FIDO 2.0 Platform Specifications 1.0 (англ.).
10. FIDO Alliance Announces Updated Authentication Specification Roadmap to Meet Growing Demand for Simpler, Stronger Authentication (англ.). Дата обращения: 11 января 2017. Архивировано 16 января 2017 года.
11. Key generation  (неопр.).
12. WHICH BROWSERS SUPPORT U2F?  (неопр.) Дата обращения: 11 января 2017. Архивировано из оригинала 18 августа 2017 года.
13. Add-ons  (неопр.). Дата обращения: 11 января 2017. Архивировано из оригинала 24 декабря 2016 года.
14. A new version of Authenticator for Android  (неопр.).