在启动时自动解锁 LUKS

LUKS 是 Linux 上通用的磁盘加密方式。只有持有密码或密钥文件,才能解锁 LUKS 卷。其作用和 Windows 中的 BitLocker 类似,但是不使用封闭、且并不安全的 TPM。

注意:本文所述的操作,将会导致您的加密卷实质无效,并可能造成信息安全的重大损失。请在慎重思考,并明白自己正在做什么之后,再进行操作。

本文所述的操作,本质上是将密钥文件放在可以直接被公开读取的存储设备上。若该设备是可移动、贴身携带、且便于销毁的,那么其实不失为一种方便的解锁方法。然而本文着重将的是,将密钥防止在固定磁盘上,即可被直接读取的 /boot 分区。因此,在执行完本文的操作后,您的加密卷本质上和未加密的卷没有任何区别,也就是 加密了等于没加

或许有读者会奇怪,笔者为何要做这种脱裤子放屁的事情呢?试想这样一个场景:如果您将服务器托管在由他人控制的物理机房,或租用虚拟服务器,那么倘若未开启加密,那么对方可以随意扫描你的磁盘。由于机房托管的服务器众多,往往会采用程序自动化扫描的方式。尽管其本身的动机可能是无害的,如防止病毒入侵或攻击,但在隐私上对用户形成了损害。因此,使用加密磁盘,便大大提高了自动化扫描的成本,从而在一定程度上保护隐私安全。

值得注意的是,无论您是否开启加密,或执行本文的操作,只要您将服务器托管于他人的控制之下,那么您的磁盘加密本质上是无效的。实现您通过 VNC 输入 LUKS 密码的场景:由于 VNC 服务器受到对方控制,对方可以记录您的 LUKS 密钥从而查看您的数据。此外,对方还可以对您的服务器进行内存 dump、网络监控等行为。

因此,本文旨在解决以下问题:

  • 大大提高自动化扫描的成本:多数自动扫描程序无法应对 LUKS 加密的卷
  • 无法防止您的服务器托管商对您的服务器进行人工审查

以下为正文。本文假定 vda2 为加密的卷,vda1 为挂载到 /boot 的卷。实际使用中,请根据实际情况修改。

首先,创建一个密钥文件:

1
dd if=/dev/urandom of=/boot/keyfile bs=1024 count=4

然后,设置对应的权限:

1
chmod 000 /boot/keyfile

第三步,将该密钥文件设置为 LUSK 的解密密钥:

1
cryptsetup luksAddKey /dev/vda2 /boot/keyfile

第四步,修改 /etc/crypttab 文件:

1
vda2_crypt UUID=不要改 /dev/vda1:/keyfile luks,keyscript=/lib/cryptsetup/scripts/passdev

完成后,更新 initramfs:

1
update-initramfs -u