Secure Boot是指为安全应用而建立的可信平台启动流程，它以不可变的序列启动系统，使用信任链机制和RSA加密认证的方法，来验证启动序列中涉及到的软件的来源的真实性，因此可防止任何未经授权或恶意修改的软件在设备上运行。
Secure Boot的使能是通过一组硬件熔丝（fuses）来实现的，对于要执行的代码，它必须由被硬件熔丝标识过的可信实体签名（signed）后，才能在使能了Secure Boot的设备上运行。
主要作用：
- 信任链和加密认证机制，保证镜像的完整且可信任
- 软件版本防回滚机制，避免可信任的老旧版本的bug
- 可关闭的JTAG调试接口，杜绝恶意获取信息
- 禁用读写接口，从硬件层面断绝泄密可能性
设计思路
设备的启动包括多个阶段，每个阶段的镜像执行了特定的功能，并且每个镜像由先前的镜像来验证。例如，APPSPBL→SBL→ARM®TrustZone，APPSPBL验证SBL，SBL验证TZ，再由TZ验证其他子系统镜像：
1. 上电后芯片内安全的ROM Soc Bootloader（APPSPBL）先启动，然后校验并启动主芯片的Flash Device Bootloader（SBL或XBL）；
2. 接下来Flash Device Bootloader（SBL或XBL）加载并校验安全系统的OS，通过后由安全系统（TrustZone OS）加载并校验Normal World Bootloader（Little Kernel），确保普通世界主系统启动前是安全的（高通平台中TZ OS还加载校验了RPM）；
3. Normal World Bootloader（Little Kernel）加载Normal World OS（Kernel），并对该Signed Kernel进行SHA256签名校验，通过后将执行权转移；
从上电复位开始的整个启动过程中，下一级的安全基于上一级的验证，最终依赖于芯片内置的OTP（一次性编程器件）和安全硬件，逐级的验证构成了整个系统的信任链。信任链中的某一个环节被破坏，都会导致整个系统不安全。
系统启动过程中安全可信的根源是APPSPBL，因为它是被固化在芯片ROM中的只读固件，无法被修改。在执行启动流程中的下一个镜像前，首先加载并鉴权该镜像以确保其包含的是已授权软件。如，只有在APPSPBL成功鉴权SBL后，控制权才能转移给SBL。得到控制权的SBL因已被鉴权所以是可信的，因此可由它来鉴权下一个待执行的镜像，并由它们通过其实现的功能进一步建立设备的安全运行环境。
镜像的签名和校验流程
Secure boot机制是基于RSA算法的，即私钥加密公钥解密。公钥是通过对芯片的熔丝寄存器进行编程写入；私钥用于对编译好的二进制文件的Hash值进行签名，最后再将已签名的二进制文件烧录到芯片中。
验证流程如下图所示，当芯片每次上电时，固化在芯片ROM的APPSPBL被加载，并检测熔丝寄存器的Secure Boot使能位。
若检测结果为已使能，则APPSPBL会从芯片的熔丝寄存器中取出OEM的公钥Hash；然后以它为信任根开始对SBL1镜像的证书链进行解密操作，得到用于解密代码签名的最终公钥Public verification Key；再使用该最终公钥解密代码签名，得到Original Signed digest。其次，APPSPBL也会重新计算待加载的SBL1镜像的Hash值，得到Flash digest，并将两者进行对比。当两者一致时则校验通过，执行权可从APPSPBL转移到SBL；否则终止启动流程。
证书链及其格式
总的来说，Secure Boot是使用链式机制来验证某个镜像的真实性的：
- 以熔丝区的OEM公钥Hash为信任根，逐步验证证书链，得到用于解密代码签名的公钥；
- 使用代码签名的公钥来解密镜像的代码签名，得到编译时对镜像计算的Hash值；
- 在DDR中加载镜像后计算其Hash值，将其与步骤2得到的原Hash值对比，以此验证镜像来源的真实性；
以上流程要求被验证的镜像如APPSBL的证书链是被正确构建的，只有当证书链、镜像代码签名均无误，验证才会得到正确的结果，我们才可以说该镜像的来源是可靠真实的。关于证书链的格式描述如下。
如图2-2所示，这是签名镜像中的三证书链结构。签名镜像包括源码、代码签名和证书链，而Secure Boot的验证是基于证书链验证和代码签名的校验进行的。
由图可知，三证书链中包含三张证书，每张证书中又包含了自身的签名和下一张证书的公钥。一张证书的签名由前一张证书的私钥生成，前一张证书的公钥用于验证这一张证书的签名，以此类推共进行两次证书验证，最后证书用其公钥解密签名镜像的代码签名。注意，Root CA的证书签名是由存储在QFPROM的OEM公钥Hash来验证，QFPROM这个区域就是所说的熔丝区，一旦写入数据即不能更改，以此来保证安全。
生成的三个证书都遵循ITU-T X.509 v3规格；三个签名Signature(I)、Signature(A)、Signature(D)均是通过RSASSA-PKCS#1 v1.5 SHA-256计算得来；Root CA的Signature(R)是对其本身进行SHA256计算得来的OEM公钥Hash值。它们之间的关系如下：
- 使能Secure Boot功能时将OEM公钥Hash值写入到熔丝区，其与Signature(R)是一致的；
- Root CA通过Private Key(R)生成Signature(I)，放在Attestation CA中；
- Attestation CA通过Private Key(I)生成Signature(A)，放在Attestation Certificate中；
- Attestation Certificate通过Private Key(A)生成Signature(D)，放在签名镜像中。
版本回退保护 Rollback Prevention
版本回退保护，用于限制被烧录到芯片的镜像版本，使其不能低于Rollback prevention寄存器中指定的版本。即使是已签名的认证Image，当其签名版本低于最低要求版本时，系统同样会终止其启动。
如：我们默认的初始版本都是0，后续发现该0版本存在风险BUG能被别人利用或破解，此时我们可更新一个版本并命名为1，然后将熔丝寄存器中的回退标志位置为1。升级到版本1后，若后续想重新刷回版本0，系统会阻止这种已排除在外的签名版本，只有当签名版本高于系统回退标志的版本号才能认为是合法有效的。
禁止JTAG调试
使能Secure Boot时，可以选择熔断QFPROM_RAW_OEM_CONFIG_ROW0_MSB eFuse寄存器与Debug相关的位，以防止外部通过JTAG端口访问设备的处理器。这确保系统启动时的Secure Boot序列不能被绕过。
验证是否熔丝签名
测试device是否已使能Secure Boot的方法主要分为两类。
- 第一类是在模块运行时读取熔丝寄存器进行查询；
- 第二类是通过下载镜像的结果来直观地体现使能的情况；
读取寄存器
通过adb shell使用devmem程序读取QFPROM_RAW_OEM_SEC_BOOT_ROW0_LSB寄存器，地址0x000A01D0：devmem 0xA01D0
1）若读出的值为0x00000000，则该模块未被熔丝：
2）若读出的值为0x00303030则该模块已被熔丝：
QPST 下载非签名版本
已使能Secure Boot的模块无法下载非签名的版本。
对于已使能Secure Boot的模块，使用QPST software download工具下载非签名版本。
- 打开QPST工具，选择非签名版本的contents.xml文件后点击Start按键
- 此时QPST会进入无响应状态，时间持续约1分钟后提示下载失败
QFIL 下载非签名版本
对于已使能Secure Boot的模块，使用QFIL工具下载非签名版本。
- 打开QFIL工具，选择非签名版本的xml文件后点击Download按键
- 此时QFIL会进入无响应状态，时间持续约3分钟后提示下载失败
错误提示：
ERROR: function: sahara_rx_data:276 Unable to read packet header. Only read 0 bytes.
ERROR: function: sahara_main:982 Sahara protocol error
ERROR: function: main:320 Uploading Image using Sahara protocol failed
Download Fail:Sahara Fail:QSaharaServer Fail:Process fail
这是因为已使能Secure Boot的模块无法下载非签名的版本，对待下载镜像的校验失败了。
注意事项
对于已使能Secure Boot的模块，单独下载非签名镜像如appsboot.mbn会导致模块无法开机；
此时模块只能进入紧急下载模式并重新下载签名版本镜像才能正常运行。