嗨，我想了解与依赖 LUKS dm-crypt 的 GNU/Linux 主机相比，加密基于 Android 的手机是如何工作的。
这是我的理解： GNU/Linux 上的加密 LVM 是一个仅在初始安装时可用的选项，因此如果一开始没有完成，那么以后就没有机会在系统级别执行此操作。删除 FDE 需要在数据备份后完全重新格式化驱动器。使用 FDE 时确保安全的唯一方法是完全关闭设备，而不是将其置于 RAM 模式的挂起状态。在这种情况下，密码屏幕保护程序是无用的，因为内存转储可以检索密钥。休眠是可以的，因为默认情况下 SWAP 是加密的。如果我错了，请随时纠正我。
令我疑惑的是：Android 也依赖 LUKS 的情况下，如何对系统进行安装后加密？它只加密内部存储而不加密SD卡吗？如果手机大部分时间都处于开机状态，那么加密的意义何在，小偷不应该通过转储手机 RAM 并提取主密钥来绕过滑动屏幕加密吗？
TIA
VoldAndroid 在一个名为 (Volume Daemon)的模块中实现设备加密cryptfs这会调用实际加密设备的内核。当用户加密设备时，Vold 会重新启动设备并开始加密数据分区。在加密过程中，Vold 会禁用设备上非核心服务的所有内容。如果用户在加密过程开始时尚未设置密码，则 Android 要求用户创建密码，这是对实施的批评之一，因为解密过程与用户屏幕解锁密码相关联，这并不是超级复杂. 一旦设备被加密，根据 AOSP 页面上的文档，加密的主密钥将存储在数据分区的页脚中。据我所知，Android 的实现只加密数据分区，即用户和应用数据。一旦设备被加密，只要手机被锁定，用户就必须输入他们的密码。在他们可以访问他们的数据之前，内核会挂载一个从实际加密的块设备中读取的 tmpfs/data。您的屏幕解锁密码经过哈希处理并用于解密主密钥。这是关于加密实现的注释的描述。
加密页脚包含有关加密类型的详细信息，以及用于解密文件系统的主密钥的加密副本。主密钥是通过从 /dev/urandom 读取创建的 128 位数字。它使用 SSL 库中的 PBKDF2 函数创建的用户密码的哈希值进行加密。页脚还包含一个随机盐（也从 /dev/urandom 读取），用于将熵添加到来自 PBKDF2 的哈希中，并防止对密码的彩虹表攻击。此外，在加密页脚中设置标志 CRYPT_ENCRYPTION_IN_PROGRESS 以检测未能完成加密过程。有关加密页脚布局的详细信息，请参阅文件 cryptfs.h。加密页脚保留在分区的最后 16 KB 中，并且 /data 文件系统无法扩展到分区的该部分。
设备加密后，撤消它的唯一方法是擦除数据。我认为您在 AOSP 源中获得的默认实现不会加密 SD 卡，因为并非所有 android 设备都具有可移动卡，例如 Galaxy Nexus，但我猜设备制造商可以为此添加支持。有关 FDE 实现的 AOSP 文档可在此处获取，Android Notes on Encryption Implementation。与其他一些 AOSP 文档相比，它非常彻底。您可能有兴趣查看这篇博文，Android 手机上的冷启动加密密钥恢复，其中包含有关尝试使用 CyanogenMod7 进行密钥恢复的一些信息。
他的结论是：
如果手机自行重启，密钥是完全可恢复的。如果使用软重置键弦，它可能是可恢复的。如果通过power-pull重新启动它可能会部分恢复（这里的实验中可能存在错误。）如果手机自行关闭它似乎无法恢复。诸如直接重新启动到 fastboot 或在按住 fastboot 键时进行正常重新启动，或将其连接到 USB 等变量似乎无关紧要。
但他正在运行 CyanogenMod7，所以我不知道这是否普遍适用于设备上的库存 ROM 或直接从 AOSP 构建的 ROM，但也许有更多关于密钥恢复潜力的信息和研究。
希望这会有所帮助。