个人工具
登录
查看“UbuntuHelp:FeistyLUKSTwoFormFactor”的源代码 - Ubuntu中文
UbuntuHelp
讨论
查看源代码
历史
搜索
导航
首页
最近更改
随机页面
页面分类
帮助
编辑
编辑指南
沙盒
新闻动态
字词处理
工具
链入页面
相关更改
特殊页面
页面信息
查看“UbuntuHelp:FeistyLUKSTwoFormFactor”的源代码
来自Ubuntu中文
←
UbuntuHelp:FeistyLUKSTwoFormFactor
跳转至:
导航
,
搜索
因为以下原因,你没有权限编辑本页:
您所请求的操作仅限于该用户组的用户使用:
用户
您可以查看与复制此页面的源代码。
=== Possible Solutions === 1. Boot volume on the same usb flash drive with the keys. This would require some changes to scripts and such.. (Perhaps the 'strongest' protection to the problem. The 'keys' are more likely to stay in your possession. A hash checksum of the boot kernel and image presented before cryptkey mounting. (Weak - adulterated initramfs image could report original numbers - fake out) It still might be advisable to checksum the /boot after /root mounted. Maybe an unnspecified script to report on the checksum and compare to the previous startup values. Brake booting if different for confirmation of changes. (thinking that the unidentified script would be outside of the initramfs ability to affect...) Encrypted /boot with GRUB able to prompt for passphrases to unlock the LUKS partitions. (Weak? - Now we have to trust GRUB hasn't been attacked. It is integral and bound to the hardrive partitions.) Could GRUB be loaded on a USB device? 2. Don't backup the random keys. Or back them up encrypted somewhere else. (But, backup keys could compromise plausible deniability if discovery of such media/medium exists.) 3. Use 'random' when you can afford the painfull time penalty for encryption. 4. Place the random system keys on individual encrypted USB devices thereby spreading the risks. However, the caveat being increased administration.
返回至
UbuntuHelp:FeistyLUKSTwoFormFactor
。