一种基于TrustZone的安全和可信混合系统启动方法与流程

本发明属于物联网智能终端安全领域，具体涉及物联网智能终端在系统启动阶段的完整性验证方法。

背景技术：

物联网在不同行业的广泛普及，促进了万物互联新时代的到来，智能家居、智能医疗、智能机器人等数以百万计的新设备接入网络。系统启动是物联网设备生命周期关键点之一，许多攻击者试图在设备断电后攻击设备，例如替换或篡改闪存中的操作系统/固件。如果系统启动时，直接从闪存读取操作系统/固件而不做任何验证，则可能启动一个被篡改的系统。

目前主要的针对启动阶段的完整性验证技术有安全启动技术以及可信启动技术。安全启动技术在检测到程序被篡改后会终止启动，在物联网设备的应用场景中，不符合可用性、完整性、机密性三个经典安全标准中的可用性标准。可信启动更符合物联网设备的可用性需求，但可信启动依赖可信根保证度量结果的可靠性。由于tpm(trustedplatformmodule)和mtm(mobiletrustedmodule)等安全硬件在物联网设备中没有得到广泛部署，通过外接这些安全硬件实现可信启动，不但降低了物联网设备的灵活性，也增加物联网设备的成本。

得益于trustzone技术安全操作系统和普通操作系统是隔离的，利用安全启动技术启动安全操作系统，安全操作系统启动后即可利用trustzone的内存隔离机制为可信启动的度量结果提供安全内存，随后采用可信启动技术启动功能复杂、易受攻击的通用操作系统，从而完成对启动阶段的完整性验证。

技术实现要素：

本发明的目的在于解决现有技术中存在的不足，通过结合安全启动技术以及可信启动技术，提供一种系统启动阶段完整性验证的技术，防御对系统启动时的篡改攻击，保证系统启动的完整性。

为了实现上述目的，本发明的技术方案如下：本发明在支持trustzone的物联网智能终端上，设计安全和可信混合启动技术，实现系统启动阶段的完整性验证。一种基于trustzone的安全和可信混合系统启动方法，所述方法依次包括以下步骤：

(1)安全启动：

利用trustzone技术提供安全环境和普通环境，以一个可信根作为系统启动的信任基点，利用安全启动技术对安全环境程序的启动进行验证；

(2)可信启动：

安全环境启动完成后，将其作为可信启动的信任基点，利用可信启动技术实现普通环境程序的可信启动。

作为本发明的一种改进，在步骤(1)中，安全环境是指基于trustzone技术的安全运行环境，如op-tee。利用一些具有防篡改能力的设备存储用于验证的可信根，在离线阶段对安全环境程序进行签名，最后在启动后对签名进行验证。

作为本发明的一种改进，在步骤(2)中，普通环境包括linux操作系统以及应用程序，在离线阶段，度量普通环境程序的哈希值，将哈希值以及远程证明密钥安全的存储在远程认证设备；此外，远程证明密钥也需要安全的存储在物联网设备中。普通环境启动后，物联网设备将启动时生成的哈希值加密发送至远程认证设备，远程认证设备最终完成普通环境程序的完整性验证

基于trustzone的软件隔离机制，本发明部署安全环境和普通环境的软件资源如下：安全环境包括bootloader和安全操作系统，其中bootloader分为两级，第一级bootloader内置于soc上的rom，本发明将其称为rombootloader，第二级bootloader保存于flash，本发明将其称为flashbootloader。同时，本发明选用op-teeos作为安全环境的安全操作系统。在普通环境，本发明选用linuxos作为通用操作系统，选用tmpfs和cpio-initrd作为文件系统。其中，tmpfs是一种基于内存的文件系统；cpio-initrd是一个cpio格式的压缩文件，里面包含文件系统的文件和目录。cpio-initrd保存于物联网设备的闪存，在系统启动阶段由flashbootloader将其加载至内存，linuxos启动时在创建内存文件系统tmpfs后会侦测出cpio-initrd是一个cpio格式的压缩文件，继而将cpio-initrd解压提取到tmpfs形成系统的文件系统。

设备供电后，首先采用安全启动技术启动安全环境的rombootloader、flashbootloader和op-teeos。op-teeos启动，即证明安全环境的代码未被篡改。基于trustzone的内存隔离机制，安全环境为可信启动的度量结果提供安全内存，随后采用可信启动技术启动普通环境的linuxos和文件系统中的应用程序，并在系统启动后向认证服务器证明普通环境可信启动阶段的完整性。

与现有技术相比，本发明利用对安全和可信启动技术的结合，增加了安全启动的可用性，保障了可信启动的可靠性，能够有效抵御系统启动阶段的篡改攻击，保证了系统启动阶段的完整性和系统的可用性、安全性。

附图说明

图1为本发明中的流程设计方案；

图2为本发明中的安全启动设计方案；

图3为本发明中的可信启动设计方案；

图4为caamblob结构；

图5为本发明中的可信启动远程证明过程。

具体实施方式

下面对本发明技术方案进行详细说明，但是本发明的保护范围不局限于所述实施例。

如图1所示，本发明的一种安全和可信混合启动方法，依次包括以下步骤：

(1)安全启动；

在系统开发完成时，在物联网设备中的一些防篡改硬件中存储安全环境用于验证签名的公钥，攻击者很难通过物理攻击来篡改其中的内容，以此确保公钥的可靠性。之后对安全环境程序进行度量并对结果用私钥进行签名。设备上电后，将签名的结果用存储在防篡改硬件中的公钥进行验证，如果验证成功，则表明安全环境没有被篡改。

(2)可信启动；

安全环境启动后，采用可信启动技术启动普通环境。在系统开发完成时，计算获得普通环境程序的哈希值并将其存储与远程认证设备，作为验证普通环境可信启动阶段完整性的参考值。为了保证通信时数据的安全，需要在物联网设备以及远程认证设备上安全的存储一个远程证明密钥，用于数据的加密。普通环境启动后，将度量结果的哈希值以及从认证设备那取得的随机数进行加密发送给认证服务器进行验证，如果哈希值以及随机数都验证通过，则表明普通环境可信启动阶段的完整性验证通过；如果随机数验证失败，则表明受到重放攻击；如果哈希值验证失败，则表明普通环境程序的完整性被破坏。

应用实施例1：

本实施中的安全和可信混合启动技术：包括以下步骤：

一、安全环境的安全启动：

安全环境的安全启动技术基于签名机制，因此分为签名和验证签名两个过程，具体如图2所示。图中的上半部分为的签名过程，在离线阶段完成，且只执行一次；图中的下半部分为验证签名过程，在每次系统启动时执行。

1)离线阶段；

为实现安全启动，在离线阶段分别度量安全环境的flashbootloader和op-teeos，并对度量结果签名。执行过程如图2的上半部分所示，采用sha256算法计算flashbootloader的哈希值作为flashbootloader的度量结果，用flashbootloader的私钥对该度量结果签名，其公钥的哈希值保存于efuse。flashbootloader的公钥附在flashbootloader后面，flashbootloader的签名附在flashbootloader的公钥后面，将flashbootloader及其公钥和签名作为一个整体存储于物联网设备的闪存。同理，计算op-teeos的哈希值作为op-teeos的度量结果，用op-teos的私钥对该度量结果签名，其公钥的哈希值保存于flashbootloader。op-teeos的公钥附在op-teeos后面，op-teeos的签名附在op-teeos的公钥后面，将op-teeos及其公钥和签名作为一个整体存储于物联网设备的闪存。

2)安全启动阶段；

设备上电后，基于签名验证机制安全启动安全环境的rombootloader、flashbootloader和op-teeos。rom中的rombootloader为安全启动的信任基点，负责验证flashbootloader的完整性，验证通过后，启动并将执行权限交给flashbootloader。flashbootloader验证op-teeos的完整性，验证通过后，启动并将执行权限交给op-teeos，至此，完成安全环境程序的安全启动。其中任意一个阶段的完整性验证失败，都将导致系统终止启动。现设p0为rombootloader，p1为flashbootloader，p2为op-teeos，当程序pi-1要启动程序pi，在程序pi被加载到内存后，程序pi-1对程序pi的完整性验证的执行步骤如下：

步骤1：pi-1分别从内存中读取pi、pi的公钥和pi的签名。

步骤2：pi-1计算公钥的哈希值，将计算结果与存储在pi-1中的公钥哈希比对。特殊的，当pi为安全环境的flashbootloader时，需将计算结果与存储在efuse的公钥哈希比对。如果匹配，执行步骤3；否则，终止启动。

步骤3：pi-1用公钥解密签名，获得度量结果m。

步骤4：pi-1重新计算pi的哈希值，获得度量结果m′。将m′与步骤3获得的m比对，如果匹配，执行pi；否则，终止启动。

如果op-teeos启动，则证明安全环境的代码未被篡改，即安全环境可信，且trustzone的隔离机制保证普通环境的程序没有权限访问安全环境的资源，因此安全环境可为可信启动提供安全内存，并将安全环境的op-teeos作为可信启动的信任基点。

二、普通环境的可信启动方法；

op-teeos启动后，为同时满足物联网设备的可用性和安全性需求，采用可信启动技术启动普通环境的程序。可信启动技术分为离线准备和可信启动两个阶段，具体如图3所示。图中的上半部分为离线阶段，在系统开发时完成，且只执行一次，计算获得的哈希链终值v保存于认证服务器，作为验证普通环境可信启动阶段完整性的参考值。图中在下半部分为可信启动阶段，在每次系统启动时执行。由于可信启动要通过远程证明的方式证明可信启动阶段的完整性，因此还需在物联网设备上安全地存储一个远程证明密钥。

1)离线阶段

1.可信启动的哈希链设计

为实现普通环境程序的可信启动，需在离线阶段设计如图3上半部分所示的哈希链。哈希链的初始值设置为v＝0，依次由哈希链的当前值v和下一个文件i进行哈希计算，获得新的哈希值。普通环境包括linuxos和应用程序。由于应用程序都在cpio-initrd压缩文件中，因此度量cpio-initrd的完整性即度量应用程序的完整性。在离线阶段，将哈希链初始值设置为v＝0后，依次读取linuxos的二进制文件i1和cpio-initrd压缩文件i2，即可获得普通环境可信启动的哈希链终值v＝h(h(0||i1)||i2)，并将该值安全地保存于认证服务器，作为普通环境可信启动阶段完整性验证的参考值。

2.远程证明密钥存储方案

本发明设计将普通环境可信启动阶段获得的哈希链终值v用对称密钥加密后发送至认证服务器，以验证可信启动阶段的完整性。因此在离线阶段，需分别在认证服务器和物联网设备存储一个远程证明密钥。

如果物联网设备支持安全存储或相关功能，则可以把远程证明密钥存储在安全存储，如果物联网设备不支持，则可以采用其他方案保证远程证明密钥的安全性，本发明基于i.mx6q的caam(cryptographicaccelerationandassurancemodule)模块实现在设备的闪存中安全地存储一个远程证明密钥。

caam模块为一个加速硬件加密的模块，其内部包含一个随机数生成器，用该随机数生成器可以在caam模块内部生成blobkey，同时caam模块由snvs(securenon-volatilestorage)为其提供一个256位的非易失性masterkey。caam模块的blob机制可以保证远程证明密钥的机密性和完整性。

本发明利用caam模块构造的blob数据结构如图4所示，共包含三个部分：被加密的blobkey、被加密的远程证明密钥和远程证明密钥的消息认证码mac(messageauthenticationcode)。由于blob中需要提供机密性和完整性保护的远程证明密钥已经被加密，因此blob可以安全的存放于设备的闪存。在离线开发阶段，本发明利用caam模块构建blob的具体步骤如下：

步骤1：caam模块利用内部的随机数生成器生成一个256位的blobkey。

步骤2：caam模块采用aes-ccm加密算法，用blobkey加密远程证明密钥，同时生成一个消息认证码mac用于验证远程证明密钥的完整性。

步骤3：caam模块利用masterkey在内部生成一个blobkeyencryptionkey，即图4中的bkek，用bkek加密blobkey，生成被加密的blobkey。

步骤4：由被加密的blobkey、被加密的远程证明密钥和消息认证码mac构成blob，存储于设备的闪存。

默认情况下，安全环境和普通环境的程序都可以利用caam模块解封装blob获取其中的远程证明密钥，为防御普通环境中的攻击程序从blob中获取远程证明密钥，本发明利用i.mx6q的csu(centralsecurityunit)单元设置caam模块的访问权限，保证只有安全环境的程序可以访问caam模块，即保证只有安全环境的程序可以解封装blob获得远程证明密钥。

csu是在总线主控(busmaster)和总线从控(busslaves)之间设置访问控制策略的硬件单元，允许将外设划分为四个不同的安全模式，分别对应于普通环境的用户模式、普通环境的特权模式、安全环境的用户模式和安全环境的特权模式，每个安全模式又可以分别设置外设的读权限(rd)和写权限(wr)。csu单元通过csl(configureslavelevel)寄存器设置外设的访问权限，csl寄存器的值和访问权限的对应关系如表1所示。

表1：外设访问权限表

从表1可知，控制一个外设的访问权限需要8位，每个外设还需一个lock位，即控制一个外设占用9位。每个csl寄存器为32位，csu在设计时分别用csl寄存器的0-8位和16-24位各控制一个外设，即一个csl寄存器可以控制2个外设。csu总共有40个csl寄存器，即可以控制80个外设的访问权限。其中，第17个csl寄存器的16-23位(csl16[23:16])控制caam模块的访问权限。本发明要求安全环境的程序有caam模块的访问权限，但普通环境没有caam模块的访问权限，因此将寄存器csl16[23:16]的值设置为00110011b，并将csl16[24](即caam的lock位)置为1，一旦lock位被置为1后，任何程序都不能更改caam的访问权限。本发明在op-teeos启动过程中设置第17个csl寄存器的16-24位，即csl16[24:16]，从而实现caam模块的访问权限控制。

2)可信启动阶段

op-teeos启动后，将其作为可信启动的信任基点，实现普通环境程序的可信启动。可信启动过程如图3的下半部分所示，首先基于哈希链启动linuxos和cpio-initrd中的应用程序，然后在系统启动后向认证服务器证明普通环境可信启动阶段的完整性。

3.基于哈希链的可信启动

为实现普通环境程序的可信启动，op-teeos依次度量linuxos和cpio-initrd的完整性。op-teeos将可信启动的哈希链初始值设置为v＝0，具体执行步骤如下：

步骤1：op-teeos读取linuxos的二进制文件i1。

步骤2：op-teeos更新保存于安全环境安全内存的哈希值v，更新为v←hash(v||i1)。

步骤3：op-teeos读取cpio-initrd压缩文件i2。

步骤4：op-teeos更新保存于安全环境安全内存的哈希值v，更新为v←hash(v||i2)。

步骤5：op-teeos启动linuxos。

4.远程证明

linuxos启动后，为实现如图5所示的远程证明，本发明在安全环境设计示证模块，该模块利用caam模块解封装blob获得远程证明密钥，并用该密钥对远程证明的信息加密；在普通环境设计数据转发模块，用于验证模块和示证模块之间的数据转发；在认证服务器上设计验证模块，用于验证普通环境可信启动阶段的完整性。远程证明的具体步骤如下：

步骤1：可信物联网设备向验证模块请求nonce。普通环境的数据转发模块与验证模块建立ssl加密连接，向验证模块请求一个nonce，该值每次由验证模块随机生成以对抗重放攻击。普通环境的数据转发模块将接收到的nonce通过共享内存的方式传送给安全环境的示证模块，示证模块将nonce拷贝到安全环境的内存。

步骤2：示证模块利用caam模块解封装blob获得远程证明密钥k，并用k加密远程证明信息。为实现blob的解封装，首先caam模块在内部利用masterkey生成blobkeyencryptionkey；然后caam模块用blobkeyencryptionkey解密blob中被加密的blobkey，获得blobkey；最后caam模块用blobkey解密blob中被加密的远程证明密钥k，并用blob中的mac验证k的完整性。示证模块将获得的远程证明密钥k保存于安全环境的安全内存，trustzone的内存隔离机制保证普通环境的程序无法获得该密钥。同时，示证模块用远程证明密钥k对哈希链终值v和nonce加密，得到密文e，e＝aes-128-cbc(nonce||v,k)。

步骤3：可信物联网设备将密文e发送给验证模块。示证模块将密文e通过共享内存的方式传送给普通环境的数据转发模块，由普通环境的数据转发模块将密文e通过ssl加密连接发送给验证模块。

步骤4：验证模块验证密文e。验证模块分别读取已保存的哈希链终值v′、nonce′和远程证明密钥k′，并用k′解密密文e，获得哈希链终值v和nonce，依次比v′和v、nonce^′和nonce。如果哈希链终值v和nonce都验证通过，则表明普通环境可信启动阶段的完整性验证通过；如果nonce验证失败，则表明受到重放攻击；如果哈希链终值v验证失败，则表明普通环境程序的完整性被破坏。

通过上述实施例可以看出，本发明混合了安全和可信启动技术，利用安全启动技术启动安全操作系统，在安全操作系统下利用可信启动技术启动普通环境的操作系统，有效抵御了系统在启动阶段被篡改的可能性，保证了系统启动阶段的完整性。