签名引导映像的整个想法是防止用自定义或恶意的东西替换引导映像。然而,整个过程似乎依赖于一个单一的失败点:图像签名的验证。引导加载程序需要验证签名映像是否已由私钥签名,私钥要求存储公钥.在某个地方。
也许它是存储在一个非易失性存储器芯片(例如。罗姆芯片)。也许它被存储在内置存储设备中的一个超级秘密区。(还有其他选择吗?)
ROM芯片(真正的只读)不是唯一的方法--除非焊接一个新的芯片--以确保启动过程不能改变?如果是这样的话,为什么移动设备不关心使用这些芯片来保持对引导映像的强大控制呢?是技术上的原因,还是更多的成本/效益的原因?
假设设备制造商希望保持一定的灵活性,以便在发现bug时更改引导过程,那么他们如何(尝试)保护这个读/写引导代码和/或一组公钥?
发布于 2011-12-21 01:20:38
对于可信引导 (或经过身份验证的引导或安全引导,或者您想要调用它),您需要一个受完整性保护的信任根。它不需要是一个“超级秘密”部门,它需要一个“超级屏蔽”部门。罗姆符合要求。
实际上,设备制造商喜欢将尽可能少的代码放在ROM中,因为他们不想在设备发布前几个月停止更新代码。因此,代码通常只会初始化几个核心设备(例如,将MMU放入形状),从存储介质加载前几个扇区,根据存储在ROM中的公钥验证它们的加密签名,并将执行转移到该代码。如果签名不匹配,ROM代码可能允许用户上传另一个引导映像(通常是通过USB)。
第一个非ROM引导代码通常比ROM代码要复杂得多:它通常需要知道如何管理内存、访问各种存储设备、可能是读取文件系统、至少有一个基本的用户界面等等。因此,在实践中,所有的代码错误,以及(或者在引导链的后面)都是iPhones被越狱的方式。一些制造商,如苹果,确实非常关注引导映像的控制,但这并不意味着他们成功地面对了一个坚定的社区。
此外,即使已签名的引导映像保持不变,操作系统本身也过于复杂,无法承受很长时间的攻击。对整个操作系统进行签名是不实际的,因为除了最基本的移动电话和PDA之外,所有用户都希望能够安装自己的应用程序(而且OSes往往有根洞)。操作系统通常可以做它想做的事情,但如果它天真地覆盖引导映像,设备就不会启动。如果您想运行不同的操作系统,您可能可以使用原始操作系统作为启动真正操作系统的跳转点。
速度是另一个因素:验证100 GB引导加载程序的真实性只是现代智能手机上的一个亮点,但验证多GB操作系统的真实性或完整性太慢了。增量验证还会降低磁盘读取的速度,并且需要目前无法广泛使用的文件系统支持。
https://security.stackexchange.com/questions/9940
复制相似问题