(2020-10-06 18:47:33 отредактировано sanyo)

Рандомизировать канал USB при подтверждении владения токеном для LUKS

Добрый день,

В контексте http://forum.rutoken.ru/topic/1624/page/2/
для использования Rutoken для защиты/генерации ключа для авторизации LUKS слота.

Я нуб в криптографии, даже не могу понять заранее возможно ли следующее:

Защитить USB канал от/при передачи открытого (например, расшифрованного) ключа для разблокировки диска с LUKS криптографией.

Я бы хотел, чтобы расшифрованный ключ для разблокировки LUKS слота кратковременно хранился только в оперативке и процессоре, но не передавался по USB и SATA/IDE и т.п. шинам компьютера для предотвращения утечки по побочным каналам типа ПЭМИ.

О такой атаке упоминается даже на странице Veracrypt:
https://www.veracrypt.fr/en/Physical%20Security.html

Furthermore, even if the attacker cannot physically access the computer hardware directly, he or she may be able to breach the physical security of the computer by remotely intercepting and analyzing emanations from the computer hardware (including the monitor and cables). For example, intercepted emanations from the cable connecting the keyboard with the computer can reveal passwords you type. It is beyond the scope of this document to list all of the kinds of such attacks (sometimes called TEMPEST attacks) and all known ways to prevent them (such as shielding or radio jamming). It is your responsibility to prevent such attacks. If you do not, VeraCrypt may become unable to secure data on the computer.

(2020-10-05 15:17:44 отредактировано sanyo)

Re: Рандомизировать канал USB при подтверждении владения токеном для LUKS

Хотя похоже при атаке типа ПЭМИ на 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

(2020-10-06 18:54:22 отредактировано sanyo)

Re: Рандомизировать канал USB при подтверждении владения токеном для LUKS

А вот интересно, может быть, Rutoken 3000 в связке с протоколом КриптоПро5 ФКН2 мог бы использоваться как раз для защиты данных USB канала в случае утечек ПЭМИ?

И тогда можно было бы спокойно шифровать ключи или пароли, используемые для открытия криптоконтейнера?

Можно ли КриптоПро5 хотя бы только с утилитами командной строки уместить в initrd/initramfs, чтобы открывать шифрованный системный диск на старте сразу же после загрузки ядра?

Когда у вас планируется появление Rutoken 3000 с кнопкой Touch и сертификатом ФСБ?

Re: Рандомизировать канал USB при подтверждении владения токеном для LUKS

sanyo, добрый день!

https://github.com/darkskiez/u2f-luks работает так:
1) В качестве ключа/секрета берется открытый ключ полученный с u2f-токена на запрос регистрации. Его токен выдает наружу.
2) При расшифровании, по подписываемому сообщению и его эл. подписи восстанавливается открытый ключ.

Используя КриптоПро CSP вы можете зашифровать lukcs-пароль на ключевой паре (на своем открытом ключе в виде CMS), которая будет храниться на Рутокен ЭЦП 2.0 3000.
Выработанный симметричный ключ будет безопасно передан по защищенному USB каналу в ОЗУ компьютера для расшифрования luks-пароля криптопровайдером.
Скорее всего это возможно сделать с помощью утилиты cryptcp из состава криптопровайдера. Как ее использовать для этих целей вам лучше подскажут в компании КриптоПро: info@cryptopro.ru

>Когда у вас планируется появление Rutoken 3000 с кнопкой Touch и сертификатом ФСБ?
В ближайшее время выход такого продукта не планируется.