secure boot目的
secure boot方案对系统软件采用签名认证的方式，在设备出厂前对设备操作系统的Image文件进行签名认证，并将公钥的Hash值写入芯片的一次性可编程模块。由于不同文件计算得到的Hash值不同，采用secure boot方案的设备每次启动时都会先校验系统的Hash值，即和芯片内的Hash值进行比较，然后对签名images的一级一级校验，实现从设备芯片到系统软件的链式校验过程，很好地避免设备出厂后没有得到客户签名认证的非授权操作，保护设备中原有的操作系统和软件版本。这里的设备包括手机，平板，盒子等。

签名的原理
数字签名是通过一些密码算法对数据进行签名，以保护源数据的做法。典型的数字签名方案包括以下三个算法：

1. 密钥生成算法，用来输出公钥和私钥。
2. 签名算法，用私钥对给定数据进行加密来生成签名。
   3.签名验证算法，用公钥对加密过的消息进行解密验证。

上图是数据的数字签名和验证过程。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流程结束。