基于标识密码的双向认证的安全启动协议

冯云龙，张宏科，刘林海

(中国电子科技集团公司 第54研究所，石家庄 050081)

0 引言

由于在设备生命周期的早期阶段，防火墙和反病毒软件等传统对策尚未启用[1]，设备在启动过程中遭到的攻击很难被检测到，导致系统安全受到影响。近年来，随着密码学的发展，安全启动(Secure Boot)方案较好地解决了这一问题。它可以防止恶意软件和其他恶意操作对启动过程进行攻击[2]，强制每个引导阶段对后续阶段进行身份验证，只有经过授权实体签名的固件才能被加载，从而在整个引导过程中建立信任链，保证系统的安全。在此过程中，设备通常需要借助efuse、BootROM等相关硬件作为信任根(RoT，root-of-trust)来引导信任链[3]。可见，硬件对系统的安全性非常重要。

然而，日益复杂的全球化硬件供应链正在威胁着核心硬件的可信度。安全引导中的RoT不可避免地受到了供应链的攻击[4]。具体来说，现在许多原始设备制造商将其硬件或固件开发外包给第三方供应商，而没有对其安全状况进行全面检查[5]，在这种情况下，设备可能会在多次中转中被拦截并被植入破坏组件[6]。上述情况表明，系统启动时硬件必须真实可信。例如，攻击者可以拦截客户的嵌入式设备并用恶意的处理器替换原处理器，或者植入一个额外的芯片破坏处理器间的通信，这些攻击被称为中间人攻击。这些攻击可能会导致恶意映像的加载，从而在启动阶段就控制了系统。上述情况表明，系统启动时硬件必须真实可信。

随着科学技术的发展，很多研究人员对硬件在保护系统安全方面做了深入研究。Jiang等人[7]提出了一种基于ARM TrustZone技术的安全引导方案，在传统Secure boot的基础上，借助开源OP-TEE和ARM硬件的支持，该方案在ZC702上实现了同时运行OP-TEE可信操作系统和Linux系统，敏感操作在OP-TEE中执行，结果通过驱动接口返回给Liunx，较好地保护了用户的信息安全。Kumar等人[8]提出了一种后量子安全引导(PQSB)方法，该方案完全由硬件实现，虽然其安全性高，速度快，但是不便于部署在已有设备上。Ehret等人[9]设计了一个以安全为重点的低功耗SoC架构，具有硬件信任根，用于边缘设备。该体系结构被命名为最优资源分配的可重构边缘计算。Pocklassery等人[10]基于物理不可克隆技术提出了一种针对FPGA的自认证安全引导方法。上述这些方案都默认了设备本身的真实可信，仅实现了设备对用户身份的单向认证，忽略了设备本身也可能成为攻击者的事实。

此外，传统secure boot方案存在如下问题：首先，认证方式都是基于证书的公钥基础设施(PKI，public key infrastructure)体制，在设备增多时，证书的管理会变得复杂。其次，采用的链式信任链过长，导致信任值损失较多。而基于标识的密码体系(IBC，identity-based encryption)是一种密码学体制，旨在解决传统PKI中的密钥分发与管理问题。在传统的PKI中，用户需要通过证书颁发机构来获取公钥证书。而在IBC中，用户可以直接使用自己的身份信息作为公钥，无需经过第三方机构的证书颁发。考虑到上述优点，提出了一种基于IBC体制的Secure boot方案，简称为IBCEB方案。以Xilinx的Zynq7000 系列SoC为例介绍传统Secure boot流程并进行分析，详细介绍IBCEB方案并对其进行安全性分析，介绍双向认证在ZC706评估板上的实现过程，总结并展望未来工作。IBCEB方案实现了在启动过程中的无证书双向认证，并且优化了信任链的传递，降低了信任传递的损失。

1 传统Secure boot

Xilinx推出的Zynq-7000 系列SoC，已广泛应用于各行各业。ZYNQ-7000系列所支持的Secure boot非常具有代表意义。本节将以Zynq系列为例介绍并分析传统Secure boot的过程。

1.1 安全启动镜像

启动镜像文件又称为BOOT.BIN文件，是Zynq启动的必备文件。它由FSBL、bit流、U-boot、Linux内核和BootROM组成。

BootROM程序由Xilinx编写，出厂后无法更改。BootROM程序为设备启动后第一段执行的代码，其主要作用有根据输入信号初始化CPU、初始化基本系统功能和判断启动方式等。在其执行完毕后会将CPU控制权移交给FSBL。另外，如果启用Secure boot，那么BootROM还会负责完成对FSBL的验签以及解密工作。

FSBL作为一段Secure boot中的核心程序，它的作用有进一步初始化PS、使用bit流文件对PL侧编程、装载裸机程序或者U-boot、执行用户定义的代码，并移交CPU控制权。如果启用了Secure boot功能，FSBL还会对接下来的程序进行RSA的验签认证以及AES解密工作。

在实际操作时，BOOT.BIN由Xilinx提供的BootGen工具生成。BootGen可以整合从FSBL到APP的所有代码，并且支持选择每一块区域是否需加密或者验签。在整合的过程中，会先添加一段引导头信息，每一段程序都会变为相应的分区(Partition)，每个分区的数据都可被AES加密、RSA签名，以确保镜像无法被随意读取，并且如果启用RSA认证，那么在每个分区后会追加数字证书，以确保分区数据的可信性。BOOT.BIN的结构如图1所示。

图1 BOOT.BIN格式

RSA认证模式为传统的PKI体系。在该体系下，会建设一个证书权威中心CA(Certificate Authority)。传统Secure Boot中关于认证涉及4种秘钥：主公钥PPK、主私钥PSK、次公钥SPK、次私钥SSK。其中PPK和PSK作为CA用于发放数字证书的秘钥对。RSA秘钥的详细信息如表1所示。

表1 认证相关秘钥

每一个Partition后的证书含有RSA认证的参数Modulus(n)、PPK、SPK、PSK对SPK的签名值和SSK对Partition内容的签名值。

1.2 Secure Boot流程

传统Secure Boot方案一般分为3个阶段：准备阶段、认证阶段和解密阶段。在启动过程中，需要每一分区对下一分区进行认证和解密。为了存储信任根，需要使用到eFuse(Electronic Fuse)。它是一次性可编程存储器，在向其烧写内容后用户层面是无法读取的。在Zynq平台上，PS侧和PL侧均有一个eFuse。PS侧的eFuse用于验证CA是否合法。PL侧的eFuse存放AES加密的秘钥，用于给每个分区解密。为了简化说明将PS侧的eFuse称为eFuse1，PL侧的eFuse称为eFuse2。下面介绍各阶段完成的工作，其中，Secure boot中各符号含义如表2所示。

表2 Secure boot中各符号含义

传统Secure boot流程如图2所示。

图2 传统Secure boot流程

准备阶段：用户需要生成AES密钥和RSA密钥(SPK，SSK)，并向指定CA注册数字证书，即可获取SPSK(SPK)。然后向eFuse1中烧写CA的公钥的哈希值H(PPK)，最后为了实现AES的加密，需要向eFuse2中烧写AES密钥。准备完毕后按照上一节的启动镜像格式生成BOOT.BIN文件。

认证阶段：1)为了确定当前分区中的签名是否来自合法的CA，设备将比较计算式(1)，如果一致则说明该镜像来自可信的CA授权的用户；2)为了确认用户的身份是否真实，设备将读取分区中的SPK值和证书，计算式(2)进行比较。如果相等则说明用户身份也真实。

H(PPK)=eFuse1

(1)

VPPK(SPSK(H(SPK)))=H(SPK)

(2)

解密阶段：3)解密之前需要计算式(3)，确保分区的完整性，以防止恶意镜像对AES引擎的攻击。4)读取eFuse2中的AES密钥，然后将该分区送入AES引擎解密，即计算式(4)。之后将CPU控制权移交给下一分区。随后下一分区重复上述步骤，直到最后一块分区完成，设备的信任链构建成功，则视为安全启动成功。

VSPK(SSSK(H(EAES(p))))=H(EAES(p))

(3)

p=DeFuse2(EAES(p))

(4)

1.3 传统Secure boot方案分析

传统Secure boot的认证方案中采用的PKI技术综合使用了数字摘要技术、数字签名等密码技术以及一套完整的证书管理机制来提供安全服务[11]。系统建设有公信力的认证中心(CA，certification authority)鉴定用户身份，然后为用户签发数字证书。数字证书安全地将用户身份和用户密钥绑定在一起。用户在业务系统中先交换证书，然后使用公私钥完成用户的身份认证、访问控制和信息安全传递等操作。它的特点是简单易懂，但是其中存在着证书管理复杂，链式信任链信任值损失多，需要消耗的计算资源高等缺点，可能并不适合部署在计算资源紧缺的嵌入式设备上。

传统Secure Boot的安全模型是建立在使用者是攻击者，设备是被攻击者的基础上，只实现了设备对用户的认证。如今，芯片供应链在设计、制造和分销等方面都已全球化[12]。PCB设计人员仅在内部设计和生产一小部分组件，而依赖于合同制造商、分销商和EDA工具等各种可能含有恶意的第三方组件，从而使伪设备攻击供应链。这种情况下设备成为攻击者，仅仅实现单向认证是不安全的。

2 IBCEB方案

IBCEB方案采用了基于标识密码体制的SM9算法，可以直接使用身份信息进行密码运算，签名私钥则通过可信第三方密钥生成中心(KGC，key generation center)生成。此外，为了检测到设备是否被篡改以及实现用户与设备的双向身份认证，需要使用物理不可克隆函数(PUF，physical unclable function)技术[13-15]。PUF会根据生产电路板时微小的差异产生唯一设备ID。此ID结合 SM9即可实现用户和设备的双向认证。

2.1 方案模型

本方案系统模型如图3所示。

图3 系统模型

涉及4个实体和3个阶段。下面对这4个实体、3个阶段以及相关安全假设做简要介绍。其中，IBCEB中的符号如表3所示。

表3 IBCEB中的符号

KGC：秘钥生成中心，方案中的核心机构，负责用户和设备的签名私钥生成和私钥分发。假设KGC完全可信，其私钥ks永远不会泄露。

User：IoT设备的所有者和使用者。用户ID可以是其手机号、邮箱等序列。User会保存向KGC申请的用户签名私钥dsAU，以及向KGC申请的IoT设备的签名私钥dsAI。假设用户存放的dsAUdsAI是安全的不会泄露。

IoT设备：指用户使用的产品，在某一台设备到达用户手中后，用户会通过PUF技术为设备生成唯一的序列号IoTid，并发送给KGC注册得到dsAI签名私钥。随后用户会向其eFuse1中烧写H(Ppub-s||Uid)。假设eFuse中数据除了设备本身，无法被他人读取。

BOOT.BIN：IoT设备的启动镜像文件，该文件由用户使用各个分区文件经过AES加密和SM9签名后生成。BOOT.BIN在生成并存入IoT设备之后，就代表着用户的身份，与设备进行认证。

2.2 方案设计

IBCEB方案主要包括系统初始化、启动镜像生成和设备启动3个步骤。其中涉及椭圆曲线参数、签名私钥生成、签名算法和验签算法，以上均按照SM9国家标准进行选取和实现。

2.2.1 初始化阶段

1)KGC按国标SM9选取参数，并生成(ks，Ppub-s)；

2)用户对IoT设备运行PUF模块，得到IoTid；

3)用户与KGC建立安全的连接；

4)用户将自身Uid和设备IoTID发送给KGC；

5)KGC分别为Uid和IoTid生成dsAU和dsAI，并发送给用户；

6)用户生成加密密钥KAES；

7)用户在eFuse1中烧写H(Ppub-s||Uid)，eFuse2中烧写AESkey。

2.2.2 镜像生成阶段

1)User准备好正常启动所需的FSBL、U-boot、Kernel、APP等相关文件。

2)对于以上每一个partition执行如下操作：

(1)对partition使用AES加密得到EAES(p)；

(2)使用dsAU对EAES(p)进行签名得到SdsAU(EAES(p))；

(3)使用dsAI对Ppub-s进行签名得到SdsAI(Ppub-s)；

(4)最后得到加密后的partition结构如图4所示。

图4 加密后partition结构

3)添加相关控制信息后，将上述合并至一个文件BOOT.BIN中。

2.2.3 启动阶段

1)BootRom阶段执行如下操作：

(1)读取Partition1，即FSBL分区。

(2)读取分区中Ppub-s，Uid，并计算验证H(Ppub-s||Uid)是否等于efuse1中的值，相等则继续，不相等则终止启动。

(3)调用PUF模块获得IoTid，并使用IoTid计算VIoTid(SdsAI(Ppub-s))若验签通过则继续，不通过则终止启动。

(4)使用分区中提供的Uid计算VUid(SdsAU(EAES(p)))，若验证通过则继续启动，不通过则终止启动。

(5)使用eFuse2中的KAES解密当前Partition。

(6)转移CPU控制权给FSBL。

2)FSBL阶段：

(1)读取Partition2，即bitstream。

(2)重复1)中(2)～(6)。

(3)读取partition3，即U-boot和kernel。

(4)重复1)中(2)～(6)。

(5)转移CPU控制权给Linux Kernel。

3 安全性分析

IBCEB方案实现了用户和设备的双向认证，能够抵御伪造设备攻击。IBCEB方案的信任链采用了星型和链型相结合的方式。

3.1 信任链模型

Demper-Shafer理论适用于分析信任链的传递过程，其中的信任衰减法则定义如下：A对B的信任值称为T(A，B)，B对C的信任值称为T(B，C)，A经过B对C的信任值称为TB(A，C)，则有：

TB(A，C)≤min(T(A，B)，T(B，C) )

(5)

通过公式(5)可知，链式模型在信任传递过程中，信任传递次数多，导致了信任值损失多，此外链中任意节点出现问题都会摧毁整条信任链，而星型信任链没有多级信任传递，信任值损失小[16-18]。IBCEB方案采用了链式与星型信任链结合的方式，缩短了信任的传递路程，减少了信任值损失。信任链模型如图5所示。

图5 信任链模型

3.2 安全性分析

假设敌手试图在BootROM执行期间读取芯片内部的信息。Secure boot是从BootROM开始执行，如果BootROM检测到启用Secure boot，那么就会禁用PS和PL的debug端口。因此想要通过JTAG接口在启动阶段访问内部寄存器或内存数据是不可能的[19-21]。

假设敌手试图读取在外部存储器中的FSBL和操作系统镜像。镜像文件是先经过AES加密[22-24]，后经SM9签名的。AES秘钥由用户自己生成并烧写到PL的eFuse中，efuse中的秘钥是安全的，因为eFuse不提供读取接口，因此敌手无法在没有AES秘钥的情况下解密镜像数据。

假设敌手试图修改镜像文件，试图使用恶意代码对AES解密引擎进行攻击。这种攻击在本方案下是无效的。因为所有的partition都经过了dsAU的签名，且BootROM在解密前会先使用Uid进行验签，验签不通过则无法进入AES解密阶段。由于dsAU是KGC由用户标识Uid生成，在验签通过的同时还可实现设备对用户身份的认证。

假设敌手使用恶意设备替换原设备来试图窃取用户信息。这种伪造设备攻击在本方案下也是无效的。因为IBCEB不仅使用dsAU对partition进行签名，还用dsAI对Ppubs进行签名。在启动过程中，由用户代码读取设备IoTid并对Ppub-s进行验签，以实现用户和设备的双向认证。伪造设备计算得到的标识IoTid必定与原设备不同，这就保证了伪造设备是无法通过认证的。

4 实验分析

为了验证基于标识密码的双向认证的安全启动协议方案的可行性，选择在Xilinx ZC706测试评估板上进行实验分析。ZC706搭载的芯片为XC7Z045，属于Zynq7000系列。

4.1 实验过程

SM9标识加密算法是基于标识的非对称加密算法，256 bit的SM9算法加密强度等同于2 048 bit密钥的RSA加密算法，并且运算速度优于RSA。因此，基于标识密码的双向认证的安全启动协议方案中认证算法选择了国标SM9算法，IBC体系的SM9算法在2020年纳入国家标准(GB/T 38635.2-2020)。SM9国标中选取了高效率的配对友好曲线，并且选择了运算速度快的R-ate双线性对运算，以减少Miller循环次数，提高计算效率。

SM9算法需要在有限域上进行双线性对的计算，由于其计算过程复杂，完全重新实现并不现实。因此在实际实现中，选择了由北京大学开发并维护的开源国密算法库GmSSL。GmSSL中实现了对所有国密算法、标准和安全通信协议的全面功能覆盖。其中，在SM9算法的实现上，GmSSL实现了定义在上椭圆曲线的各种运算和各类数据转换，以及双线性对的计算，并且在其中加入了常见的优化方法。

传统Secure boot的RSA认证是在FSBL阶段调用RSA库形式实现，因此为了方便对比性能差异，需要将FSBL中的RSA认证代码删除，添加基于GmSSL实现的SM9验签部分的代码。并在FSBL初始化完成之后，加载bit流之前，即在Fsbl Hook Before Bit stream Dload()的hook函数中实现。根据启动介质的不同，对后续分区实现相应的验签操作。

实际上由于FSBL是由Bootrom搬运至OCM执行，而OCM的大小仅有256 kB，其中还有64 kB地址不连续，因此，需要精简GmSSL库，只保留验签所需代码，且选择Release模式编译FSBL，但在精简至最少代码时仍然无法通过编译，此时还需要修改lscript.ld文件，将.heap段映射至ps7_ram_1_S_AXI_BASEADDR中，最终才能实现将SM9移植到FSBL中。

在实现了基于SM9的认证功能后，还需考虑对镜像文件的加密。由于zynq本身硬件支持的解密效率高达100 MB/s，因此仍选择沿用Zynq7000自身硬件支持的AES算法。最后在实际生成镜像文件时，使用BootGen工具，对镜像进行加密以及整合操作。生成启动镜像如图6所示。

图6 生成启动镜像

在启动镜像生成完毕后，用户需使用SM9算法对BOOT.BIN中各分区添加分区的签名信息和Ppub-s的签名信息。对BOOT.BIN签名过程如图7所示。

图7 对BOOT.BIN签名过程

eFuse的烧写需要使用Xilinx提供的eFuse驱动。在计算好H(Ppub-s||Uid)后，将值写入驱动的配置文件中。在编译完成后，选择JTAG引导模式，使用XSCT命令行对eFuse进行烧写。基于AES密钥的存储有两种方式，一种为存储至eFuse中，虽然eFuse中更加安全，不会泄露密钥，但是之后都无法更改；另一种可以选择存放在BBRAM中，BBRAM是由电池供电的一块RAM，在开发板断电后其中的数据不会消失，并且密钥可以多次修改。为了方便测试选择了BBRAM形式存储AES密钥，BBRAM在开发板断电后数据不会消失且密钥可以修改。烧写AES密钥如图8所示。

图8 烧写AES密钥

4.2 实验结果与分析

嵌入式设备的启动所需的时间一般主要由3部分组成：BootROM将FSBL从存储介质搬运至OCM的时间t1，FSBL将后续U-boot、Kernel从存储介质搬运至DDR时间t2，以及U-Boot、Kernel程序自身的初始化时间t3。

对于t1，由于BootROM的不可修改性和不可访问性，导致无法测量t1的准确数值，但是一般而言由于FSBL的大小仅为100 kB，相比于bit流、U-Boot、kernel一般20 MB的大小，t1可以忽略不计；对于t3，在选择常用版本的Linux，U-Boot的情况下，测量得到U-Boot启动耗时1 287 ms，Linux内核启动耗时4 065 ms。这里并不包括搬运时间，而是指搬运至DDR后各自的执行时间，此时间和存储介质的传输速度无关，即在不更换CPU和DDR的情况下可以看作固定值；对于t2，在启用Secure boot时，FSBL在搬运之前会先读取分区信息进行RSA认证，通过后再将数据通过PCAP总线传送至AES解密引擎解密，最后再送入DDR。FSBL的代码可以添加用户自定义的部分，因此可以便捷地实现对上述功能计时。综上所述，t1无法测量且占比很小，t3为固定值，所以t2是系统启动时间中有意义的统计因素。

此次实验采用了常见的含有Bit流、U-boot、Linux 的23 M的镜像从SD卡来启动设备，设备成功启动如图9所示。

图9 设备成功启动

由此测得t2值为12.39 s。由于从SD卡启动会涉及文件的读写，双线性对的运算复杂，且OCM仅有256 kB，因此面对较大的bit流、Linux内核文件时，会导致效率的下降。虽然IBCEB方案牺牲了部分效率，但是IBCEB方案实现了设备与用户的双向认证，保证了系统的安全。

在安全性方面，为了测试IBCEB能否抵御篡改镜像攻击，首先选择在ZC706评估板上选择常用的U-Boot、Linux版本实现了正常启动。然后通过更换APP中的内容来模拟对系统镜像的篡改攻击。在启动时，FSBL计算验签的结果不通过，启动终止。启动验证失败测试结果如图10所示。

图10 启动验证失败

5 结束语

文章提出了基于标识密码的双向认证的安全启动协议的方案，简称IBCEB方案。文章对该方案进行了详细的理论分析，同时，在ZC706评估板上进行了相关实验分析。实验结果显示，实现了用户和设备之间无证书的双向认证协议，提高了系统的安全性。此外，还对传统信任链模型进行了优化，采用了星型和链式相结合的信任链，降低了信任传递的损失。此方案适用于公共安防、智慧家居等诸多领域，使用前景广阔。尽管IBCEB方案存在优势，但也存在一些不足。首先，一旦KGC主密钥被泄露，则任何一个用户的私钥都可以被计算出来，就会严重威胁到系统的安全。其次，虽然理论上SM9的性能优于RSA，但是SM9国标中的参数以及验签算法对于嵌入式设备来说执行流程复杂，带来了效率的损失。因此接下来将进一步研究由用户与KGC共同决定签名私钥的隐式证书密码体制，以及在Secure Boot应用中，如何轻量化SM9认证协议。