安全引导可用于保证系统的完整性,防止系统中重要镜像文件被破坏或替换。
一般情况下,安全引导需要保护
• 系统的BootLoader镜像文件、
• TEE镜像文件、
• Linux内核镜像文件、
• Recover镜像文件
• 以及在ARMv8中使用的ATF镜像文件。
将TEE镜像文件的加载操作加入安全引导功能中可阻止黑客通过替换TEE镜像文件的方式来窃取被TEE保护的重要资料。
当前使用ARM芯片的系统中大部分使能了安全引导功能,该功能对于用户的最直接感受就是,当用户非法刷入其他厂商的ROM后手机无法正常启动,这是因为非法刷机将导致系统中的重要镜像文件被替换,系统在启动过程中对镜像文件的电子验签失败,如果BootLoader验证失败,则系统在进入BootLoader阶段之前就会挂死。
(信任根这个词语此时有没有在你的脑子里包含)
安全引导的原理
安全引导功能的原理就是采用链式验签的方式启动系统,也就是在系统启动过程中,在加载下一个阶段的镜像之前都会对需要被加载的镜像文件进行电子验签,只有验签操作通过后,该镜像才能被加载到内存中,然后系统才会跳转到下一个阶段继续执行,整个验签链中的任何一环验签失败都会导致系统挂死,系统启动过程中的第一级验签操作是由ChipRom来完成的。
只要芯片一出厂,用户就无法修改固化在芯片中的这部分代码,因此无法通过修改第一级验签结果来关闭安全引导功能。
而且验签操作使用的RSA公钥或者哈希值将会被保存在OTP/efuse中,该区域中的数据一般只有ChipRom和TEE能够读取且无法被修改。RSA公钥或者哈希值将会在产品出厂之前被写入到OTP/efuse中,而且不同厂商使用的密钥会不一样。
本质上也就是说Rom拿来校验后级第一部分的内容所用到的密钥是来自OTP里面,而这种是在出厂就确认好了的,无法修改的。ChipRom和OTP的配合让这个安全启动的最开始具备了灵活性和安全性兼顾。
在谷歌的安全引导功能白皮书中提出了安全引导功能实现方案的设计建议。
谷歌建议将镜像文件的电子签名信息和验签使用的RSA公钥保存在电子证书中,系统在启动的过程中首先会验证电子证书的合法性,如果验证通过则需从电子证书中获取签名信息和RSA公钥,然后再利用它们对镜像文件进行验证。整个验证过程就是先验证证书,验证证书通过后再去验证镜像文件的合法性。
但是在实际实现过程中,大多数芯片厂商是将签名信息与需要被验签的镜像文件打包在一起,而RSA公钥则会被打包到执行验证操作的镜像文件中。
(但是动态TA的事情)
不同厂商可能会对镜像文件进行加密操作,使保存在设备中的镜像文件都是以密文的形式存在。
在启动过程中,首先会验证密文镜像文件的合法性然后再进行解密镜像文件的操作,这些都完成后才会将明文的镜像文件加载到内存中然后再执行跳转操作。
先验证,再解密,签名的是加密的文件哦。
-
ROM
+关注
关注
4文章
572浏览量
85768 -
镜像
+关注
关注
0文章
164浏览量
10715 -
系统
+关注
关注
1文章
1017浏览量
21339
发布评论请先 登录
相关推荐
评论