dim*_*ike 11 linux encryption sd-card initrd
我正在尝试复制保护一些工作,这是一个可引导的 SD 卡,用于在 ARM 设备(Raspberry Pi)上引导 Linux 内核。我正在使用这种方法:
所以在引导加载程序加载内核和 initrd 后,内核解密 initrd 并执行其 init 脚本,这将生成密码并挂载根文件系统。
我的问题是:打破这个设置(解密根文件系统并使其从任何 SD 卡启动)有多容易?最薄弱的部分是什么?反编译内核并找到那些自定义加密函数有多容易?
编辑:这里有一些更正,这样你就不会在明显的事情上浪费时间:
破坏此设置(解密根文件系统并使其从任何 SD 卡启动)有多容易?
“破坏”您的设置的难易程度取决于您用于对文件系统本身进行签名/加密的任何方法中的熵位数(因为这决定了可用于暴力破解的独特组合的总数密码)。
最薄弱的部分是什么?
毫无疑问,使用预定义的 CID 作为密码,以及使用自定义伪随机数生成函数。
SD 卡的 CID应该只是只读的,但在当今时代,发现不合规的闪存设备并不少见。 有些人甚至展示了用某些 SD 卡覆盖CID的能力。这将使暴力破解密码变得更容易,尤其是在克隆您的 SD 卡后只是模拟SD 卡时(这是您可能需要考虑的其他事情)。
最后,使用任何类型的伪随机数生成器都已经存在一些内在缺陷,正是因为它不是随机的——它被称为伪随机是有原因的。最好使用预制的加密引导加载程序(如TrueCrypt或 LUKS,它们都适用于 Raspberry Pi)并避免进行任何手动内核修改。
反编译内核并找到那些自定义加密函数有多容易?
反编译任何东西都非常困难。相反,已编译应用程序的反汇编通常是微不足道的,并且有许多工具可用于协助将逆向工程汇编回另一种高级语言。如果攻击者甚至可以访问已编译的内核,分析伪随机数生成器之类的东西可能是微不足道的,除非故意混淆代码。
TL,DR:在加密和安全性方面不要重新发明轮子,坚持使用久经考验的方法。有几个全盘加密选项已经可用,并且已经证明可以在 Raspberry Pi 上正常工作。我会避免使用 SD 卡的 CID 作为一种“密码”——即使它不能改变,也有办法欺骗这个值。
复制保护已作为CPRM包含在 SD 卡规范中。
归档时间: |
|
查看次数: |
8928 次 |
最近记录: |