Пример, как можно использовать USB-брелок Yubikey в качестве смарткарты для хранения GPG-ключей и ключей для аутентификации на SSH-серверах.Использование с GPG.
Подключаем Yubikey к порту USB и проверяем, что он определился:
gpg --card-status
...
Version ..........: 2.1
Manufacturer .....: YubicoДля переноса GPG-ключа на брелок запускаем "gpg --edit-key идентификатор_ключа" и выполняем в редакторе команду "keytocard" (внимание, закрытый ключ будет не скопирован, а перенесён, т.е. удалён с локальной машины, поэтому нужно заранее позаботиться о создании резервной копии).
Убедимся, что ключ переместился:
gpg --card-status | grep key
URL of public key : [...]
Signature key ....: [...] XXXX YYYY
Encryption key....: [...] ZZZZ VVVV
Authentication key: [...] AAAA BBBB
General key info..: sub rsa4096/QQQQQQ <foobar@domain.tld>Для проверки создадим шифрованное сообщение и расшифруем его:
gpg --encrypt --output /tmp/message.txt.enc -r foobar@domain.tld /tmp/message.txt
gpg --decrypt /tmp/message.txt.enc
Настраиваем SSH-ключи.Удостоверимся, что ключ аутентификации перенесён на Yubikey ("Authentication key" в выводе "gpg --card-status") и выполним экспорт открытого ключа SSH из Yubikey:
gpg --export-ssh-key 0xAAAABBBB
Далее, скопируем экспортированный ключ на SSH-сервер и настроим gpg-agent для работы в роли агента SSH:echo 'enable-ssh-support' >> ~/.gnupg/gpg-agent.conf
Перезапустим агенты GPG/SSH:
killall gpg-agent
killall ssh-agent
gpg-agent --daemonПоменяем путь к сокету SSH_AUTH_SOCK на GPG. В ~/.bashrc:
export SSH_AGENT_PID=""
export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)Проверим, виден ли ключ SSH при подключении брелока:
ssh-add -l
4096 SHA256:XXXX cardno:0006064XXXX (RSA)
Всё в порядке, теперь при подключении к серверу SSH будет использовать ключ с брелока Yubikey.
URL: https://0day.work/using-a-yubikey-for-gpg-and-ssh/
Обсуждается: https://www.opennet.ru/tips/info/3048.shtml
Это те которые теперь closed-source code и дырявые?
In October 2017, security researchers found a vulnerability (known as ROCA) in the implementation of RSA keypair generation in a cryptographic library used by a large number of Infineon security chips. The vulnerability allows an attacker to reconstruct the private key by using the public key.[18][19] All YubiKey 4, YubiKey 4C, and YubiKey 4 nano within the revisions 4.2.6 to 4.3.4 are affected by this vulnerabilityЕсть что-то более открытое аналогичное?
Сделай своё на Arduino/AVR/STM32/RISC-V. Ну серьезно, в наше время можно купить платку с микроконтроллером и USB разъёмом, да сделать свой ультра-девайс.
угу, убердивайс, из которого все твои закрытые ключи и пароли вынимаются путем чтения его флэшки или и вовсе перехвата уже расшифрованных данных из памяти компьютера (спасибо интелу за meltdown и amd за spectre)единственный смысл подобных токенов исключительно в том, чтобы закрытые ключи никогда не покидали устройства, а внутри него хранились в принципиально нечитаемом виде
сделать подобное из китайских запчастей практически нереально, из некитайских...да кто ж тебе их продаст-то.
а обычный функционал убикея (с прикидыванием клавиатурой вместо токена) - это пожалуйста, это можно. Но совершенно бессмысленно.
STM32 можно залочить на "WriteOnly".
> STM32 можно залочить на "WriteOnly".У L1/L4/F0/... есть еще level2, там блокируется все что можно. И jtag, и встроенный бут, и вообще - записать что-то новое или прочитать можно будет только если фирмвара юзера (или юзеровский бут) на это согласна. И даже так option bytes менять нельзя, так что разлочить чип не сможет даже фирмвара уже. ST клянется что они не могут failure analisys на таких чипах. Даже если это и полуправда, проблем атакующему привалит. А самые очевидные дыры давно опробовали и заделали, потому что конкуренты не прочь спереть фирмварь, особенно китайцы. И защита камня от чтения это единственное что стопорит моменталное появление китайских клонов быстро, нагло и за треть цены.
> внутри него хранились в принципиально нечитаемом видеНу и кто мешает применить AES шифрование для своих ключей?
>> внутри него хранились в принципиально нечитаемом виде
> Ну и кто мешает применить AES шифрование для своих ключей?здравый смысл? Задача не в шифровании ("кто мешает" шифровать на диске без всяких ненужнотокенов), а в том, чтобы ключи _никогда_ не расшифровывались - кроме применений, когда они не покидают внутреннюю память дивайса. В случае gpg все шифрование придется выполнять внутри, на входе плейнтекст и парольная фраза, на выходе - уже шифрованный или подписанный или то и другое пакет.
Не знаю, не знаю, насколько тормозно это будет на stm и поместится ли в память вообще, особенно, если понадобятся block ciphers (обычно не нужен, но мало ли).В случае ssh попроще, там протокол устроен так, что все можно сделать почти правильно.
Но, "почему-то", никто пока не сделал хотя бы и для ssh-only. Удивительно, но факт.
> угу, убердивайс, из которого все твои закрытые ключи и пароли вынимаются путем
> чтения его флэшкиПрочитаешь мне STM32? А то гадские китайцы залочили прошивку на чтение, понимаешь. Можно стереть и свою влить, но так не интересно - ведь китайскую прошивку я при этом не получу. А писать самому 128 кил кода довольно напряжно. Нет, 10К зелени на взлом путем вскрытия чипа и дампа флеша электронным микроскопом я тебе не дам, извини. За 10 штук я таки сам перепишу это с ноля и лучше.
> или и вовсе перехвата уже расшифрованных данных из
> памяти компьютера (спасибо интелу за meltdown и amd за spectre)Так не надо там хранить ключ вечно. GPG должен быть в курсе таких вещей.
> сделать подобное из китайских запчастей практически нереально, из некитайских...да кто
> ж тебе их продаст-то.На любой микроконтроль защита от чтения ставится. Чтобы конкуренты прошивки не воровали.
> Нет, 10К зелени на взлом путем вскрытия чипа и дампа флеша электронным микроскопом я тебе не дам, извини. За 10 штук я таки сам перепишу это с ноля и лучше.Так и быть Анон, я дам тебе 10К зелени если ты напишешь её "с нуля". А будет лучше - сможешь и больше зелени поднять, не проблема. Оставь свой и-мэил тут.
В статье переносят свой ключ на юбикей, а не генерируют новый ключ юбикеем, уязвимость как то связана с этим, если да, то как?
Эта уязвимость лишь упрощает факторизацию простых ключей (512, 1024 и 2048), _созданных_ встроенным в YubiKey TPM-модулем. 3072 и 4096-битовые ключи даже при генерации уязвимым устройством считаются безопасными.Вот на русском статья про ROCA https://www.opennet.ru/opennews/art.shtml?num=47396
Trezor, например. Оно, конечно, в первую очередь биткоин-кошелёк, но и более приземлённые вещи может, в том числе и сабж.Есл- хочется попроще и подешевле - fsp-01
Я наваял такое: https://github.com/nuclearcat/cedarkey
Работает, но до ума не доводил, т.к. лично для меня достаточно существующего функционала, а остальным неинтересно, скорее всего по причине отсутствия blue pill.
> ЮбикейЮбать какие ключи!
А как-то можно этих штук купить и не загреметь на нары?
приезжаешь (по туристик визе) в Штаты. И заказываешь да хоть с амазона хоть на адрес в хостеле, хоть целое ведро.При отлете в родные щебеня - оставляешь на тумбочке, конечно. Ты ж купить спрашивал, а не "купить в Россию", да? ;-)
https://store.softline.ru/yubico/
Дорого.
Если, например, хочется входить в систему по ключу + хранить на нем же пару сертификатов для крипто про и випнета (все неизвелкаемое), то за тыщу рублей можно что-то найти? (кроссплатформенное, ествественно)
>то
> за тыщу рублей можно что-то найти? (кроссплатформенное, ествественно)Спаяй, будь ... самоделкиным ^W производителем!
https://www.fsij.org/gnuk/neug-on-stm32-nucleo-f103.html
<=https://fosdem.org/2018/schedule/event/hwenablement_gnuk_tok.../1900 йен это тыр или больше?...
Подскажите нубу. Чем это лучше смарткарт?
А есть и полный опенсорс для этой задачи: https://github.com/nuclearcat/cedarkey
Добрый день! Подскажите кто покупал Yubikey, для него необходим дополнительный софт покупать для записи или он в комплекте идет с лицензионным ключем? так же тут на сайте https://softlist.biz/catalog/product-yubikey-5-nfc/ написано что есть поддержка macOS и Linux, кто пробовал нормально работает, без лагов?