Хотя похоже при атаке типа ПЭМИ на USB канал Rutoken бессмысленно что-то шифровать, потому что незашифрованное значение будет всегда заведомо известно атакующим.
Вероятно при такой атаке имеет смысл использовать только функцию подписания Rutoken, но опять же как ее прикрутить к разблокировке диска?
Как сделать так, чтобы пароль или ключ для разблокировки шифрованного контейнера становился доступен скрипту только в том случае, если прошла верификация подписи сообщения, отправленного токену скриптом?
Т.е.
1) Генерим какое-то случайное сообщение.
2) Отправляем его на подпись токену.
3) Верифицируем возвращенную подпись сообщения открытым ключом.
4) Если верификация прошла успешно, значит токен аутентичный (хотя что мешает поменять открытый ключ при физическом доступе), далее хотелось бы как-то разблокировать шифрованный диск, но откуда взять пароль ? :)
Кстати, идея! Можно попытаться сделать свой сильно защищенный после обфускации выполняемый файл, внутри которого хранится зашифрованный пароль (который не передается по USB каналу), паблик ключ токена и логика для проверки аутентичности токена и подстановки ключа из этого файла, если предположить, что атакующие не смогут расковырять такой выполняемый файл, например если он обфусцирован Eazfuscator-ом и потом скомпилирован в native с помощью DotNet Core RT, но это зависит от квалификации атакующих.
Но они могут перехватить такой исполняемый файл по ПЭМИ шины диска и расковыривать его в комфортных условиях на своих компах под отладчиком :(
Хотя программу можно наверно разместить в чипах BIOS в качестве payload для Libreboot, но все же предварительно во время разработки и прошивки ее могут вытащить по каналам ПЭМИ.
Вообщем похоже со смарткартами ничего не получится?
А что в плане U2F токенов? У них вроде бы более мудреный протокол, там есть рандомность и постоянно увеличиваемый счетчик последовательности?
Есть такая малопопулярная программа:
https://github.com/darkskiez/u2f-luks
Я пока смутно представляю, как работает протокол FIDO и тем более данная программа, вообще имеет ли смысл пытаться изучить вариант FIDO или там все тоже самое, что и со смарткартами, но с небольшими отличиями в деталях реализации?
How does this work?
This uses some trickery in order to synthesis a static key from a U2F token because:
U2F keys are almost stateless holding only a counter
U2F keys can only sign requests with ecdsa
U2F signatures are only over partially supplied data include the counters
This tool uses the public key obtained during the register request as the LUKS privatekey, and derives the public key back from the authenticate requests using eliptic curve key recovery (http://github.com/darkskiez/eckr) on the signatures.
This tool encrypts the keyhandle optionally with the userpassphrase, and stores it in the u2f-luks.keys file. Only the correct keyhandle, passphrase and U2F token will yeild the correct key. We store a hash based on the correct key in the keyfile because the key recovery algorithm returns two candidate keys.
Most U2F tokens will blink if the correct matching password is entered.
Можете объяснить простыми словами, что там происходит, а то уж очень мудрено для меня написано ?
Как раз используется подпись, но ведь U2F собственно больше ничего и не умеет кроме подписи?
И вот еще один похожий проект, но уже для токенов FIDO2:
https://github.com/shimunn/fido2luks
