Какова криптографическая связь между ключом SSH и моим Yubikey?

Мне любопытно, какова криптографическая связь между сгенерированным закрытым (и открытым) ключом ssh, когда я использую свой Yubikey для добавления дополнительного уровня защиты.

Единственная универсальная вещь заключается в том, что закрытый ключ вам никогда не раскрывается. Этот файл «закрытого ключа» непригоден для использования до тех пор, пока его информация не будет загружена обратно в Yubikey, после чего Yubikey сможет создавать подписи по запросу.

То, как именно это реализовано, может варьироваться, поскольку не все «ключи безопасности» U2F являются Yubikeys, и даже Yubikeys не обязаны делать это одинаково; Для достижения этого результата можно использовать как минимум 3 различных механизма.

Пишет ли ssh-keygen что-нибудь в сам Юбикей?

При генерации *-skклавиш, краткий ответ: «технически это зависит, но на практике нет (если вы не используете , в этом случае да)».

Теоретически токен U2F действительно может хранить все эти пары ключей в памяти, как это делалось раньше со смарт-картами (сравните режим «PIV» Yubikey), но на практике токены достигают этого, вообще не имея никакой записываемой памяти.

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

(И всякий раз, когда вы запускаете ssh-keygen дляключ, в результатеФайл закрытого ключа содержит только открытый ключ и «дескриптор ключа», ту же информацию, что и веб-сайт. Единственное отличие состоит в том, что вы будете использовать одну и ту же пару ключей на всех хостах SSH вместо автоматического создания уникальных пар ключей для каждого сервера.)

Хитрость в том, что каждый токен Yubikey имеет записанный на фабрике ключей AES, и всякий раз, когда его просят сгенерировать новые учетные данные U2F, он шифрует новый закрытый ключ своим внутренним ключом AES и возвращает весь закрытый ключ как " ключевой дескриптор» на веб-сайт. Затем он просто полностью забывает ключ и ждет следующего запроса.

Для веб-сайта этот «дескриптор ключа» непрозрачен — он выглядит как очень большой идентификатор ключа и хранится в обычной таблице базы данных. Но во время входа в систему, когда веб-сайт отправляет «дескриптор ключа» обратно в токен, Yubikey может расшифровать его и снова восстановить тот же закрытый ключ, а когда закончите, снова выбросить его.

Я думаю, что это обычно называется «оберткой ключей», и это позволяет одному и тому же токену поддерживать буквально неограниченное количество пар ключей. Документально подтверждено , что Yubikeys используют этот метод, но так же работает и большинство других токенов U2F/FIDO. Тот же трюк используется и при генерации ключей на чипах TPM2.

(Есть еще один похожий подход, который, кажется, я читал об одном производителе, использующем свои токены U2F: детерминированная генерация ключей, когда в токене есть встроенное начальное число для генерации ключа, и используется что-то вродечтобы каждый раз генерировать один и тот же ключ для одного и того же веб-сайта с нуля.)

Короче говоря, создание ключа «ed25519-sk» с помощью Yubikey ничего не записывает во внутреннюю память — вся необходимая информация хранится в зашифрованном виде в файле вашего закрытого ключа и загружается обратно в Yubikey в ОЗУ.

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

Чтобы это работало, токены FIDO2 имеют постоянную память для определенного количества пар ключей (вместе с соответствующими именами пользователей и идентификаторами приложений), но она не используется по умолчанию — ключ сохраняется в токене только в том случае, если приложение специально запрашивает « удостоверение резидента. Для OpenSSH ssh-keygenопция приведет к тому, что пара ключей будет сохранена в самом токене с помощьюопция, позволяющая загрузить его обратно в файлы «id_whatever».

Обратите внимание, что U2F/FIDO полностью независимы от режимов эмуляции смарт-карт PIV и OpenPGP, которые можно найти в различных моделях Yubikey. В трех режимах используются разные инструменты и разные протоколы.

В режиме PIV пары ключей ECP256 могут быть сгенерированы на смарт-карте PIV с помощьюи доступ через ssh, и они записываются во внутреннюю память Yubikey — локальные файлы не сохраняются, модуль PKCS#11 извлекает все из Yubikey по мере необходимости. Карта PIV, которую эмулирует Yubikeys, имеет более строгую структуру, чем большинство смарт-карт; Я думаю, что он может содержать 3 пары ключей. Конечно, их можно удалить и создать заново в любой момент.

Аналогично в режиме OpenPGP можно генерировать пары ключей ECP256 на смарт-карте OpenPGP, и их можно использовать для SSH через– они тоже хранятся внутри Yubikey, хотя на этот раз сохраняется только частичная информация. Весь закрытый ключ хранится на карте, носохраняет метаданные PGP и «заглушку», напоминающую, что соответствующий закрытый ключ находится на карте. Карты OpenPGP могут содержать всего 3 пары ключей, но только одна из них может использоваться для SSH.