Fido u2f

Содержание:

FIDO U2F?—?Универсальная Двухфакторная Аутентификация. Введение +14

12.07.16 01:26

•
herrjemand
•
#305508
•
Хабрахабр

•
Из песочницы

•

6500

Информационная безопасность

Ни для кого не секрет, что сегодня существует большая проблема с безопасностью в интернете. Пользователи используют легкие пароли и переиспользуют их на других ресурсах. Парольные менеджеры все еще в новинку для обычного пользователя, и вашу бабушку вы вряд ли заставите использовать случайные одноразовые пароли с высокой энтропией. Жизнь тлен и боль…

На заре веб2.0 мы стали понимать, что паролей недостаточно и изобрели двухфакторную аутентификацию или 2FA.

Что из себя представляют 2FA решения сегодня?

SMS — одноразовые пароли отправленные с помощью SMS.
OTP(TOTP/HOTP) — одноразовые пароли, сгенерированные на основе мастер ключей. Примеры: Google Authenticator, Yubikey, банковские OTP токены.
Криптографические Токены — аппаратные средства для многофакторной аутентификации пользователей. Примеры: RSA SecureID, Рутокен.

При большом выборе решений, у пользователей до сих пор уводят аккаунты. Так почему существующие технологии не решили проблему?

Причин много:

Фишинг — практически все перечисленные решения уязвимы к MITM (человек посередине) атакам, и соответственно фишингу. Что остановит пользователя, который уже ввел свой логин и пароль, от введения одноразового пароля?
Безопасность — в данном случае я буду говорить именно про SMS. SMS на данный момент самое популярное решение 2FA на рынке. Истории о перевыпуске сим карты случались не только в России, но и в США, ЮАР, Великобритании и других странах. Почти все провайдеры предоставляют возможность восстановления сим-карт, и методы социальной инженерии еще никто не отменял.
Стоимость — если вы швейцарский банк, и ваш клиент хранит семизначные суммы иностранной валюты, то RSA токены это мизерная цена для обеспечения безопасности аккаунтов ваших клиентов. А если вы Twitter или Facebook, то выдавать недешевые токены каждому пользователю просто невозможно. SMS тоже стоит денег, и если вы держите любительский аниме форум о дискуссиях про то как пропатчить KDE под FreeBSD, то вы вряд ли сможете позволить себе SMS.
Совместимость — никто не любит возиться с драйверами, и это одна из причин того, что RSA и Рутокен все еще не завоевали мир.
Удобство использования — вводить одноразовые пароли это морока. Разблокируй экран, открой сообщения, прочитай код, ошибись, сожги телефон и компьютер — это стандартный алгоритм взаимодействия пользователя и двухфакторной аутентификации.

Этот список можно еще долго продолжать, но я думаю что мысль донесена. Сегодняшние решения не в состоянии надежно защитить пользователя, сложны в применении, дороги и не универсальны.

HyperFIDO U2F Security Key

Brand: HyperFIDO

Firmware: Feitian(?)

Chip: ?

Connection: USB-A

Features: U2F

Price: $9.98

Review Author: AGL

This HyperFIDO device is plastic so avoids the electrical issues of the KEY-ID and HyperFIDO Mini, above. It also avoids having an LED that can blind small children.

However, at least on the one that I received, the plastic USB part is only just small enough to fit into a USB socket. It takes a fair bit of force to insert and remove it. Also the end cap looks like it should be symmetrical and so able to go on either way around, but it doesn’t quite work when upside down.

Once inserted, pressing the button doesn’t take too much force, but it’s enough to make the device bend worryingly in the socket. It doesn’t actually appear to be a problem, but it adds a touch of anxiety to each use. Overall, it’s cheap and you’ll know it.

Additional comments from Brad Hill:

There is funny stuff going on with how the several of these I have present their attestation. Every time the device is registered, they generate a unique device name as part of the certificate. This has the upside of not presenting a cross-domain tracking identifier, but it tells me that the attestation private key is in the device somewhere. (or it may be generating a new random attestation key and cert every time, I don’t recall) Anyway, they seem fine for consumer use — I’ve used one I leave installed in my monitor’s USB hub on a daily basis for almost a year now. But I wouldn’t recommend these if you care about checking attestations.

Additional comments from Harald Wagener:

The housing plastics are so soft that putting them on a keyring broke the hole left for that purpose. Even the small threaded loop that is shipped with the key will saw through the housing body over time.

Шаг шесть с половиной — Защита от перебора

В ситуации, когда пользователь находится вдали от своего устройства, вредоносное программное обеспечение может попытаться атаковать устройство методом полного перебора или другими видами атак. Для защиты от этого U2F стандарт требует чтобы все имплементации, в железе и ПО, активировались пользователем. Пользователь обязан подтвердить свое решение на двухфакторную аутентификацию. Этим действием может быть простое нажатие на кнопку, ввод пин-кода, снятие отпечатка пальца или другое.

Сервисы с множественными точками входа

Возьмем для примера Gmail.

В Gmail можно войти как с веб интерфейса, так и с мобильного. Как можно произвести авторизацию пользователя с андроид приложения, если AppID нашего приложения и AppID сервиса будут различаться?

Для этого есть фасеты (facets).

Фасеты — это JSON файл со списком всех ID, которым разрешается производить аутентификацию для выбранного сервиса. Для примера, вот фасеты Google:

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

Фасеты должны быть в том же доменном пространстве что и AppID. Например, если наше AppID это https://example.com/facets.json, то https://security.example.com пройдет проверку, а https://security.example.net нет.

Для мобильных приложений фасеты имеют URI схему вида “OS:TYPE:ID”. Для андроида вычисляется SHA-1 сертификата подписи apk. Для IOS это bundle ID.

Фасеты обязаны раздаваться по HTTPS!

На данный момент готовы спецификации для USB, NFC и Bluetooth LE.

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

Chrome поддерживает U2F из коробки с начала 2015. U2F поддержка в Firefox в данный момент в активной разработке. Microsoft анонсировала поддержку U2F как для Windows 10 так и для Edge как часть FIDO2.0 стека, и она уже доступна в Insider Build.

Кто использует?

Google, Github, WordPress, Dropbox, Evernote. Правительство Великобритании недавно ввело поддержку U2F для своих государственных сайтов, что немало доставляет.

Что нужно учесть при переходе на U2F?

HTTPS ОБЯЗАТЕЛЕН — мало того, что если вы не предоставляете HTTPS своим пользователям, то вас не заботит их безопасность, и U2F вам будет мало интересен. Firefox, Chrome, и Edge требуют HTTPS соединения для использования U2F API.
Попробуйте TLS SessionID.
U2F это второй фактор. Не будьте как банки. Не используйте 2FA как основной фактор.

Подводим итоги

U2F это хорошо продуманная, сильная, открытая и стандартизированная технология. Она была успешно протестирована Google на своих сотрудниках, кои используют U2F на данный момент в качестве основного метода двухфакторной аутентификации.

U2F всего лишь протокол, что влечет за собой создание огромного рынка решений на основе его. От крипто-ключей с безопасным элементом, JavaCard имплементаций, до мобильных приложений и биометрически-защищенных U2F устройств, U2F дает свободу вашей фантазии втом, где его можно применить.

Примечания

https://fidoalliance.org/specifications/download/
https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-appid-and-facets-ps-20141009.html
https://developers.yubico.com/U2F/

Google Advanced Protection:

For Android Users:

Yubikey NEO + a second Yubikey NEO or a Yubikey 4C or 4C Nano if you want a USB-C device.

NFC has superior usability to BLE for mobile uses, doesn’t need a battery and thus the devices can be more robust. The TOTP features also available on the NEO or 4-series Yubikeys are a great addition, but you should have two devices that can do this, and save each seed to both in case one fails.

Unfortunately, you can’t yet use an NFC-only device like the Fidesmo card because Google still only supports registering a new device over USB. The Feitian MultiPass works, but I don’t recommend it because the NFC antenna is so bad.

For iOS Users:

Yubico U2F Security Key + VASCO DigiPass SecureClick

On iOS, you have to use BLE with the Google Smart Lock app to login. The only device I’ve found that works with this is the VASCO DigiPass SecureClick. The Feitian MultiPass should work in theory, and I’ve heard from people that got it to work, but I’ve tried to pair my MultiPass to three different iOS devices with no success.

As a backup, the Yubico U2F only device is ideal.

Особенности [ править | править код ]

Криптографические примитивы

Для операций подписи используется алгоритм ECDSA над кривой P-256, для операций хеширования — SHA-256 , которые широко доступны на встраиваемых платформах и достаточно надежны

Предотвращение атаки посредника

Когда > и позволяет серверу обнаружить атаку, если есть два раздельных канала TLS. Эта концепция была внедрена в спецификации протокола U2F, но тем не менее в данном подходе были обнаружены проблемы и предложены пути решения

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

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

Генерация регистрационно-зависимой пары закрытый/открытый ключ. Например, каждый Yubikey имеет свой мастер-ключ, который в связке с HMAC и ГПСЧ генерирует новую пару .

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

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

Goal: Strong Authentication and Privacy for the Web

The U2F eco-system is designed to provide strong authentication
for users on the web while preserving the user’s privacy. The
user carries a ‘U2F device’ as a second factor.

When the user registers the U2F device at an account at a
particular origin (such as http://www.company.com) the device creates
a new key pair usable only at that origin and gives the origin
the public key to associate with the account. When the user
authenticates (i.e., logs in) to the origin, in addition to
username and password, the origin (in this case,
http://www.company.com) can check whether the user has the U2F device
by verifying a signature created by the device.

The user is able to use the same device across multiple sites on
the web — it thus serves as the user’s physical web keychain
with multiple (virtual) keys to various sites provisioned from
one physical device. Using the open U2F standard, any origin
will be able to use any browser (or OS) which has U2F support
to talk to any U2F compliant device presented by the user to
enable strong authentication.

The U2F device registration and authentication operations are
exposed through Javascript APIs built into the browser and, in
following phases, native APIs in mobile OSes.

The U2F device can be embodied in various form factors, such as
stand alone USB devices, stand alone Near Field Communication
(NFC) device, stand alone BlueTooth LE devices, built-on-board
the user’s client machine/mobile device as pure software or
utilizing secured crypto capabilities. It is strongly
preferable to have hardware backed security, but it is not a
requirement. However, as we shall see the protocol provides an
attestation mechanism which allows the accepting online service
or website to identify the class of device and either accept it
or not depending on the particular site’s policy.

The specs for U2F are in two layers. The upper layer specifies
the cryptographic core of the protocol. The lower layer
specifies how the user’s client will communicate U2F
cryptographic requests to the U2F device over a particular
transport protocol (e.g., USB, NFC, BlueTooth LE, built-in on a
particular OS, etc).

The current spec set from the U2F group specifies the upper
layer (which is unchanged regardless of transport) and the
lower layer for the USB transport. Later phases of the protocol
spec will specify transports for U2F over NFC, BlueTooth and
when built-in (i.e, where the U2F capability is built into the
device and accessed locally via the OS).

As one of the founders of the U2F working group in FIDO, Google
is working to build U2F support into the Chrome browser and
will offer U2F as a 2nd factor option on Google accounts to
help the start-up of the open ecosystem.

Как я стал нодой

О Фидонете я знал давно. Ещё в далеком 2003 году, получив в своё распоряжение модем на 14400, первым делом я попытался подключиться к Сети Друзей. Но… Не сложилось. Потом появилось подключение к интернету, подписка в режиме read-only через NNTP, но мысль не только читать, но и писать всё равно осталась где-то в подсознании…

Год 2010. Пойнт.

И вот на дворе 2010 год. А если точнее — апрель-месяц. Появляется статья История одного пойнта, что выводит писательскую мысль из коматоза и отправляет на поиски пойнтового адреса у Сергея (2:5020/2140). И вот оно — первое сообщение и первый нетмейл!
Я сразу понял, что радость только начинается…

Verifying That a U2F Device Is ‘genuine’

The U2F device protocol is open. However, for effective
security, a U2F device has to be built to certain standards —
for example, if the Key Handle contains private keys encrypted
with some manufacturer specific method, this has to be
certified as well implemented, ideally by some ‘certification
body’ such as FIDO. In addition, the actual cryptographic
engine (secure element) should ideally have some strong
security properties.

With these considerations in mind, a relying party needs to able
to identify the type of device it is speaking to in a strong way
so that it can check against a database to see if that device
type has the certification characteristics that particular
relying party cares about. So, for example, a financial
services site may choose to only accept hardware-backed U2F
devices, while some other site may allow U2F devices
implemented in software.

Every U2F device device has a shared ‘Attestation’ key pair
which is present on it — this key is shared across a large
number of U2F device units made by the same vendor (this is to
prevent individual identifiability of the U2F device). Every
public key output by the U2F device during the registration
step is signed with the attestation private key.

The intention is that the public keys of all the ‘Attestation’
key pairs used by each vendor will be available in the public
domain — this could be implemented by certificates chaining to
a root public key or literally as a list. We will work within
FIDO to decide the details on how certified vendors can publish
their attestation public keys.

When such an infrastructure is available, a particular relying
party — say, a bank — might choose to accept only U2F devices
from certain vendors which have the appropriate published
certifications. To enforce this policy, it can verify that the
public key from a U2F device presented by the user is from a
vendor it trusts.

In practice, for high quality U2F devices we expect that the
attestation key would be burnt into the on-board secure element
— the actual key to be burnt in would be provided by the
vendor to the secure element manufacturer for every batch of
chips, say about 100,000 units.

Note that the attestation key’s presence only guarantees who the
vendor is for a well built U2F device — it is one part of the
story, albeit a very crucial part. As to whether the U2F device
is indeed secure, that guarantee comes from certifications where
third parties inspect the implementation by the vendor. In
summary, attestation is a strong identifier of the
certifications.

In this context, it’s worth noting that a U2F device which
stores keys on board rather than exporting them in the Key
Handle are, in principle, most secure, since it is not
vulnerable to any potential vendor specific vulnerabilities in
the design of the encryption of the data in the Key Handle.
However, a good design with an encrypted Key Handle will be
well above the bar in security while also being cheaper.

At this time, the encryption used to embed private keys in the
Key Handle are technically not part of the specified protocol.
However, strong best practice guidelines are specified in the
sample client side javacard applet available in U2F working
group materials. It may be appropriate to include a review of
particular implementations as part of a U2F certification
within FIDO.

Note that it is still possible for a vendor to build a U2F
compliant device which is not certified and whose attestation
keys are not published in a ‘certification database’. A relying
party could still choose to accept such devices — but it will do
so with the full knowledge that that particular device type is
not in the certification database.

Архитектура

Основные компоненты типового решения с поддержкой U2F-аутентификации на базе токена
JaCarta U2F представлены ниже:

Web-сервер – сервер, к ресурсам которого обращаются пользователи. На
одном Web-сервере может быть установлено несколько Web-приложений. В качестве
Web-сервера выступает, как правило, одно из доступных на рынке решений данного
класса (например, Microsoft IIS, Apache, nginx и др.).
Web-приложение – приложение (Web-сервис), реализующее конкретную
прикладную логику. Например, Web-портал, личный кабинет клиента банка и т.п.
U2F-сервер – приложение, реализующее серверную часть протокола U2F и
обеспечивающее хранение информации, полученной в процессе регистрации и
аутентификации. В качестве U2F-сервера может выступать либо готовое решение,
созданное сторонними производителями, либо продукт собственной разработки.
Web-приложение при получении запросов на регистрацию и аутентификацию
пользователей обращается к U2F-серверу для проверки и сохранения полученных от
пользователя данных.
U2F-клиент – приложение, посредством которого пользователь
взаимодействует с Web-сервисом (например, Web-браузер или мобильное приложение).
U2F-клиент реализует клиентскую часть протокола U2F, взаимодействует с
Web-сервером и U2F-токеном:
- взаимодействие с Web-сервером осуществляется по протоколу HTTPS;
- взаимодействие с U2F-токеном осуществляется по протоколу USB HID.
Токен JaCarta U2F – устройство, используемое в качестве второго фактора
аутентификации при доступе к Web-ресурсам и реализующее интерфейс USB HID.

Работа протокола [ править | править код ]

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

Во время регистрации проверяющая сторона (веб-сервис, целевой ресурс) отправляет некоторые данные для подписи устройством (то есть генерирует вызов) браузеру. Браузер добавляет к данным URI, с которого был произведен запрос на подпись и >

Аутентификация пользователя

Во время аутентификации проверяющая сторона отправляет некоторые данные (то есть генерирует вызов) и дескриптор ключа для подписи браузеру. Браузер добавляет к этому URI, с которого был произведен запрос на подпись и >

Небраузерные приложения

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

для веб-приложений определен в RFC 6454;
для Android приложений — это URI android: apk-key-hash: ;
для IOS приложений — это URI ios: bundle-id: .

Например, для приложения Example список разрешенных facet IDs может выглядеть следующим образом:

Status of This Document

This section describes the status of this document at the time of its publication.
Other documents may supersede this document. A list of current FIDO Alliance publications and the
latest revision of this technical report can be found in the FIDO Alliance specifications index at
https://www.fidoalliance.org/specifications/.

This document was published by the FIDO Alliance as a Implementation Draft.

This document is intended to become a FIDO Alliance Proposed Standard.

If you wish to make comments regarding this document, please
Contact Us.

All comments are welcome.

IMPLEMENTATION DRAFT

This Implementation Draft Specification has been prapared by FIDO Alliance, Inc. Permission is
hereby granted to use the Specification solely for the purpose of implementing the Specification. No rights
are granted to prepare derivative works of this Specification. Entities seeking permission to reproduce
portions of this Specification for other uses must contact the FIDO Alliance to determine whether an
appropriate license for such use is available.

Implementation of certain elements of this Specification may require licenses under third party intellectual
property rights, including without limitation, patent rights. The FIDO Alliance, Inc. and its Members
and any other contributors to the Specification are not, and shall not be held, responsible in any manner
for identifying or failing to identify any or all such third party intellectual property rights.

OpenID, SAML, and OAuth

FIDO protocols (both UAF and U2F) complement Federated Identity
Management (FIM) frameworks, such as OpenID and SAML, as well
as web authorization protocols, such as OAuth. FIM Relying
Parties can leverage an initial authentication event at an
identity provider (IdP). However, OpenID and SAML do not define
specific mechanisms for direct user authentication at the IdP.

When an IdP is integrated with a FIDO-enabled authentication
service, it can subsequently leverage the attributes of the
strong authentication with its Relying Parties. The following
diagram illustrates this relationship. FIDO-based
authentication (1) would logically occur first, and the FIM
protocols would then leverage that authentication event into
single sign-on events between the identity provider and its
federated Relying Parties (2).

Итоговые мысли

В общем ребята. Информации мало. Кое-что удалось найти, и кажется что.. в итоге можно предположить что это за приложения.

В общем смотрите:

Предположительно что F />
FIDO UAF ASM относится напрямую к аутентификации, возможно это какой-то модуль или плагин.
Отключить эти два приложения можно, но если вы знаете как — сделайте перед этим что-то вроде бэкапа Андроида.
Я не советую сразу бежать и удалять приложение. Сперва его попробуйте отключить. Не получается? Тогда заморозьте. И если уж вообще никак — то удаляйте, но делайте это на свой страх и риск. Для отключения, заморозки и удаления я советую использовать Titanium Backup.
В интернете пишут что приложения можно отключить также при помощи Package Disabler.

Ссылки по теме, если хотите углубиться в это все дело, более детальнее разобраться.. у меня уже просто нет сил, но если у вас есть желание, то пожалуйста:

На этом все господа. Надеюсь мне удалось оказать информационную помощь А теперь прощайте