Подробности в этой теме:
https://forum.rutoken.ru/topic/3254

В контексте атак по каналам ПЭМИ подписание со смарткарты выглядит более безопасной операцией чем дешифрование, но как результат подписи/проверки подписи использовать для открытия LUKS слота ?  - я не знаю :(

Может быть, Rutoken 3000 + ФКН2 чем-то лучше для защиты от атак по каналам ПЭМИ?
Но можно ли установить КриптоПро v5 в initrd/initramfs - его текстово консольную часть - самый необходимый минимум?

Более подробно вопросы по Rutoken 3000 для открытия LUKS2 слотов обозначены в теме:
https://forum.rutoken.ru/post/14860/#p14860

С другой стороны не думаю, что если устройство работает по HID, то оно не может переключаться и в другие режимы работы, в которых бы оно имело доступ и к DMA через какие-нибудь недокументированные режимы работы контроллера USB, специально заложенные в них заранее как раз для такого случая.

Могу согласиться, что описанная в этой ветке защита может предотвратить утечку данных при СЛУЧАЙНОЙ утере носителя владельцем.

Если же мы пытаемся защититься от целеноправленного несанкционированного доступа к данным при наличии  у атакующих физического доступа к компьютеру, то они могут установить троян в BIOS и/или прошивку HDD.

У SATA контроллера (как и USB контроллера) есть доступ ко всей RAM через DMA? Он может вычитывать любые области памяти в т.ч., где хранятся ключи в слотах LUKS? Может ли закрытая прошивка диска посылать какие-нибудь недокументированные команды котроллеру на чтение областей RAM для поиска ключей LUKS?

На разных сайтах пишут разное относительно опасности USB и SATA в плане утечек через DMA, не уверен чему верить.

Мне кажется, что на безопасной рабочей станции не должно быть внешних проприетарных устройств, подключенных по шинам, контроллеры которых видно по lspci, должна быть open source прошивка матплаты типа Libreboot вместо BIOS и загрузчики, защищенные от прошивок носителей, либо  шифрованием либо использованием очень старых флэшек или старых SD карт и старых ридеров.
Наверно можно попытаться найти open source Ethernet контроллер и подключать остальные устройства (диски, USB и т.п.) на другом компьютере, который предоставляет доступ к этим устройствам по Ethernet (iSCSI, iFC, USBIP и т.п.).

Может быть, кого-то бы даже заинтересовала платформа Talos2:
https://www.raptorcs.com/content/TL2WK2/intro.html
Якобы на маплате нет закрытых блобов, но ктож проверит.

У Вас какая-то очень странная модель угроз. Никакой CCID драйвер не даст DMA (не говоря уже о том, что надо будет написать специальную прошивку для токена), он вообще для смарт-карт не имеет смысла. А если Вы считаете, что можете на компьютер устанавливать любые вредоносные драйверы (полный доступ с root правами), то ключи шифрования можно даже не искать, а просто почитать диск.
В большинстве случаев в которых применяется LUKS защищаются не от администратора с полным доступом, а защищаются от утери устройства или от несанкционированного доступа.

Рады, что Вам удалось решить свою задачу, хоть и с помощью Yubikey.
На самом деле аутентификация с помощью Yubikey не является двухфакторной. Здесь есть только один фактор -владения ключем. Любой, у кого есть ключ, сможет осуществить вход. В токенах для этого и есть дополнительный фактор - знания PIN кода, который и защищает от подобного сценария.

Реализовать аутентификацию в LUKS с помощью Рутокен S безопасно невозможно, так как он не является криптографическим токеном. Такой сценарий действительно можно реализовать с помощью Рутокен ЭЦП, а настройку сделать проще. Но пока Вы первый, кто обратился с таким сценарием. Как только этот сценарий станет распространенным, мы сделаем более удобные средства для настройки.

Чтобы добавить что-то в initrd в Debian используется initramfs-tools (смотрите https://manpages.debian.org/stretch/ini … .8.en.html)

Скорее всего в initrd не упакован /usr/bin/pkcs11-tool...

Спасибо за подсказки :-)

Да, скорее всего, так оно и есть, вопрос, как бы его туда добавить тогда? Или это надо на форуме Debian спрашивать?

Оказывается, что в основной консоли (скрипт открывает дополнительную) также пишутся ошибки:

Что касается основных дополнений (не по части initrd) - это все найдено в сети и позаимствовано. Мне бы пока добиться для начала, чтобы на этапе загрузки ключ вообще прочитался из ruToken-а, потом, конечно, разберусь с остальным тщательно.

P.S. У shred есть ключ -u. ☺
А почему после чтения ключа не размонтируется /crypto/ram?
И вообще, pkcs11-tool пишет (т.е. должен, судя по коду) в stdout, если не указан output-file.

Попробуем у себя воспроизвести.

Итак, текущий вариант: для универсальности рассматриваем компьютер с Debian 9.4 Stretch, где СЗИ от НСД не установлена, есть под рукой ruToken ECP и ruToken S (в пределах территориального органа их очень много, желание повысить защищенность информации), SSD разбит на тома 1) /boot и 2) CryptLVM, в последнем в свою очередь тома swap, /, /tmp и /home. Дополнительно, хотя для поставленной цели это неважно, реализована двухфакторная аутентификация пользователя по инструкции отсюда — https://dev.rutoken.ru/pages/viewpage.a … Id=3440665 с имеющимся сертификатом.

В реализации работы с LUKS для простоты и отдельных своих соображений опять-таки первоначально пробую реализовать вариант с ruToken ECP, обращаться к librtpkcs11ecp.so, но не к pkcs15, а также заведомо не прибегаю к ассиметричному шифрованию.

Мои действия:
1) создаю симметричный ключ шифрования, который в случае чего можно будет использовать просто, как пароль, записываю его в ruToken ECP и в один из слотов LUKS:

LUKS_KEY=`openssl rand -base64 99` && echo "$LUKS_KEY" >> ~/LVM_LUKS.tmp
dd if=~/LVM_LUKS.tmp of=~/LVM_LUKS.key bs=1 skip=0 count=64
shred ~/LVM_LUKS.tmp
rm ~/LVM_LUKS.tmp
sudo cryptsetup luksAddKey /dev/sda2 ~/LVM_LUKS.key
pkcs11-tool --module /usr/lib/librtpkcs11ecp.so --login --write-object ~/LVM_LUKS.key --type data --label LVM_LUKS.key --application-label cryptsetup --private
shred ~/LVM_LUKS.key
rm ~/LVM_LUKS.key

2) создаю папку /crypto, а в ней файл «luks_unlock.sh» с атрибутами 0755 (при этом рабочий файл luks_unlock.sh делаю без комментариев и пустых строк):

#!/bin/bash -i
PATH=$PATH:/usr/bin

# Use RAM-disk for temporary storage
# Unlike tmpfs, ramfs does not use swap, making it
# somewhat more suitable for keeping data off persistent storage.
RAMDISK="/crypto/ram"
mkdir -p $RAMDISK
mount -t ramfs -o size=1m ramfs $RAMDISK
chmod -R u=rwx,g=,o= $RAMDISK

# Plaintext written to RAM at this location
DESTINATION=$RAMDISK/luks_output

# Ensure PCSC daemon is running
pcscd -d

echo "Decrypting LUKS volume with card from $CRYPTTAB_KEY (also $1)" >> /tmp/luks_status

# Run pkcs15-crypt on a different terminal
openvt -fsw -c 2 -- pkcs11-tool --module /usr/lib/librtpkcs11ecp.so --login --read-object --type data --label LVM_LUKS.key --output-file $DESTINATION 2> /tmp/luks_errors

# This is used to unlock the disk
cat $DESTINATION

# Overwrite and remove copy on ramdisk
shred $DESTINATION
rm $DESTINATION

3) файл /etc/crypttab привожу к виду:

# <target> <device> <key file> <options> 
sda2_crypt UUID=56fe86c5-a589-4b52-a296-03c1eac5c54f none luks,keyscript=/crypto/unlock.sh 
# sda2_crypt UUID=56fe86c5-a589-4b52-a296-03c1eac5c54f none luks

4) выполняю команды ниже и перезагружаюсь

update-initramfs -u
update-grub

На этапе загрузки получаю ошибку: «openvt: can't execute pkcs11-tool no such file or directory»

Как это все исправить и довести до рабочего состояния? По возможности я хочу избежать работы с pkcs15 и асимметричного шифрования.

Enter password for volume.cnt:

И не понятно, кто виноват. То ли файл разрушен, то ли что-то с ключом не так.
По truecrypt --list-token-keyfiles --token-lib=/usr/lib/opensc-pkcs11.so ключ как бы есть, но вот цел ли он, вопрос.