Когда вы используете полное шифрование диска LUKS, как бы вы защитились от злых служанок ?
Злая атака горничной - это когда кто-то получает физический доступ к вашему компьютеру во время вашего отсутствия и скомпрометирует незашифрованный / загрузочный раздел, чтобы перехватить ваш пароль FDE при следующем запуске компьютера
Одно из решений состоит в том, чтобы оставить раздел / boot на USB-накопителе, который всегда с вами (горничная не может добраться до него), но какую файловую систему следует использовать на нем, и как настроить систему для изящной обработки удаления USB-накопителя (и, следовательно, самого раздела / boot)?
Я использую CentOS, но общие, дистро-агностические ответы, конечно, приветствуются. Благодарю.
Другой подход к этой конкретной проблеме заключается в использовании доверенного платформенного модуля для хранения ключа шифрования, но защита действительно полагается на пользователя, чтобы сделать его эффективным. Элементарным решением на основе RHEL7 является tpm-luks ( https://github.com/GeisingerBTI/tpm-luks ).
Это работает при загрузке, каждый шаг процесса загрузки измеряет следующий и сохраняет это измерение в PCR на TPM. Как только процесс загрузки завершен, tpm-luks проверяет состояние PCR с помощью «заведомо исправной» конфигурации. Если в конфигурации «заведомо исправный» TPM откроет ключ LUKS, и tpm-luks передаст эти данные, чтобы разблокировать корневой раздел LUKS.
Поскольку все важное измеряется с помощью криптографического хэша, злая служанка, по сути, не может заменить GRUB / kernel / ramdisk, чтобы нечестно собирать парольную фразу FDE. В качестве дополнительного бонуса вам не нужна фраза FDE! Теоретически вы можете полностью удалить понятную человеку парольную фразу и полностью положиться на tpm-luks, но если вы пойдете по этому пути, вероятно, будет хорошей идеей сохранить заголовок LUKS и сохранить его в качестве резервной копии.
Как я уже упоминал, это требует некоторого усердия на пользователя. Если вы оставили компьютер без присмотра, и вам предложили ввести фразу-пароль, возможно, это плохая идея, чтобы ввести его, пока вы не проведете некоторые расследования. В этот момент вы должны загрузиться в среде live CD и посмотреть, есть ли ошибка в tpm-luks или
/boot
раздел действительно был изменен. Вы по-прежнему оставляете/boot
раздел незашифрованным, но если что-то важное изменяется, основной диск никогда не расшифровывается.источник