赞
踩
secure boot目的
secure boot方案对系统软件采用签名认证的方式,在设备出厂前对设备操作系统的Image文件进行签名认证,并将公钥的Hash值写入芯片的一次性可编程模块。由于不同文件计算得到的Hash值不同,采用secure boot方案的设备每次启动时都会先校验系统的Hash值,即和芯片内的Hash值进行比较,然后对签名images的一级一级校验,实现从设备芯片到系统软件的链式校验过程,很好地避免设备出厂后没有得到客户签名认证的非授权操作,保护设备中原有的操作系统和软件版本。这里的设备包括手机,平板,盒子等。
签名的原理
数字签名是通过一些密码算法对数据进行签名,以保护源数据的做法。典型的数字签名方案包括以下三个算法:
上图是数据的数字签名和验证过程。Secure boot方案中的数字签名由SHA和RSA算法组成,并直接采用PUK替代CA。我们在PC端实现对Images的签名,并在手机端实现Images的验证,images文件的变化会导致解密过程的失败,从而很好地避免非授权操作。
rockchip方案介绍:
rockchip提供的secureboot方案分两种:soft和efuse两种,具体区别如下:soft是不烧efuse,安全级别低(可以更换FLASH来禁用secureboot),部分客户为了过google认证又不想太麻烦,就用soft。efuse是会把key的hash烧录到ap的efuse里面,安全级别高,需要通过换AP和FLASH来禁用secureboot,下面我们重点介绍efuse的方案:
secure boot soc 全貌[如上图]
efuse layout[如上图]
secure boot流程[如上图]
PC侧加密过程:
使用rockchip提供的签名工具(SecureBootTool_v1.83_foruser)对打包的update.img进行签名步骤及原理如下
1.工具首先会产生一对密钥对即:public key和privete key
2.使用sha256计算镜像代码的hash,并使用私钥对代码进行RSA2048签名
3.使用sha256计算出public key的hash
4.将镜像代码+2中签名+public key进行打包形成新的镜像
5.3种的hash会烧写到OTP(One Time Programable)里面(使用工具:Efuse_Tool_V1.36)
Mobile侧解密过程:
1.首先从新的镜像中获取public key计算hash值
2.从OTP中读取预烧写的hash值进行对比,如果相同则继续否则boot 失败
3.从新的镜像中获取签名,然后使用RSA2048计算hash
4.使用SHA256计算镜像code段的hash值,3和4的结果对比,相同则继续,否则失败
mobile侧:分为三个阶段romcode—>miniloader、miniloader—>uboot 、uboot—>kernel,对于我们可见的其实目前只有uboot—>kernel这个阶段,我们也将重点介绍这个阶段的实现过程
romcode-→miniloader
1.从一级bootloader里面获取public key,并计算hash值
2.读取OTP(efuse)中的hash值,与1中对比,如果相同则继续,否则失败
3.使用sha256计算一级loader code的hash值
4.获取一级loader的签名信息,并使用RSA2048计算其hash值
5.3和4中结果进行对比,如果相同则本级boot成功,否则失败
miniloader-→uboot
1.从一级bootloader里面获取public key,并计算hash值
2.读取OTP(efuse)中的hash值,与1中对比,如果相同则继续,否则失败
3.使用sha256计算一级uboot的hash值
4.获取uboot的签名信息,并使用RSA2048计算其hash值
5.3和4中结果进行对比,如果相同则本级boot成功,否则失败
uboot-→kernel
1.从一级bootloader里面获取public key,并计算hash值
2.读取OTP(efuse)中的hash值,与1中对比,如果相同则继续,否则失败
3.使用sha256计算一级boot的hash值
4.获取boot的签名信息,并使用RSA2048计算其hash值
5.3和4中结果进行对比,如果相同则本级boot成功,否则失败
uboot中最早涉及secureboot是从board_late_init开始的
其中主要做的事情是检测是否enable了secureboot,判断的依据是:读取和一级loader约定好的地址上是否有公钥存在,如果有则使能了secureboot,否则没有使能
在后面涉及到secureboot就是在cmd_bootrk.c中从存储中获取镜像的时候rk_load_image_from_storage中调用了SecureBootImageCheck
这个函数主要就是实现了上述uboot引导kernel的流程图中的功能,详细如下:
我们看到SecureBootImageCheck中进来两个参数:一个是boot_img_hdr,另一个是unlock,前者是boot.img的头信息,后者是bootloader是否解锁的标志,如果解锁了就不会去做secureboot的校验了,我们看一下这个函数的实现:
其中securemode参数是在前面进行securebootcheck函数中配置的,如果在ram中读到了miniloader的public key,则SecureMode = SBOOT_MODE_RK,否则默认为SBOOT_MODE_NS,最终会调用到SecureRKModeVerifyBootImage函数中:
1.首先校验boot.img magic信息和签名标签是否相同,不同则返回失败
2.计算boot.img中code的size
3.初始化加密计算引擎
4.使用rsa算法通过签名和公钥计算hash值
5.使用sha算法计算code的hash
6.对比hdr中的hash和code的hash是否一致,是继续,否则失败
7.对比签名解算的hash和code的hash,正确则继续,否则失败
至此签名的secureboot流程结束。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。