[发明专利]一种基于TrustZone的安全和可信混合系统启动方法

权利要求书

1.一种基于TrustZone的安全和可信混合系统启动方法，其特征在于：所述方法依次包括以下步骤：

(1)安全启动：

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

(2)可信启动：

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

在步骤(1)中，安全环境是指基于TrustZone技术的安全运行环境，利用一些具有防篡改能力的设备存储用于验证的可信根，在离线阶段对安全环境程序进行签名，最后在启动后对签名进行验证；

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

在步骤(1)中，安全启动具体实现如下：

安全环境的安全启动技术基于签名机制，分为签名和验证签名两个过程，

1)离线阶段；

为实现安全启动，在离线阶段分别度量安全环境的Flash Bootloader和OP-TEE OS，并对度量结果签名，采用SHA256算法计算Flash Bootloader的哈希值作为Flash Bootloader的度量结果，用Flash Bootloader的私钥对该度量结果签名，其公钥的哈希值保存于eFuse，Flash Bootloader的公钥附在Flash Bootloader后面，Flash Bootloader的签名附在Flash Bootloader的公钥后面，将Flash Bootloader及其公钥和签名作为一个整体存储于物联网设备的闪存，同理，计算OP-TEE OS的哈希值作为OP-TEE OS的度量结果，用OP-TEOS的私钥对该度量结果签名，其公钥的哈希值保存于Flash Bootloader，OP-TEE OS的公钥附在OP-TEE OS后面，OP-TEE OS的签名附在OP-TEE OS的公钥后面，将OP-TEE OS及其公钥和签名作为一个整体存储于物联网设备的闪存；

2)安全启动阶段；

设备上电后，基于签名验证机制安全启动安全环境的ROM Bootloader、FlashBootloader和OP-TEE OS，ROM中的ROM Bootloader为安全启动的信任基点，负责验证FlashBootloader的完整性，验证通过后，启动并将执行权限交给Flash Bootloader，FlashBootloader验证OP-TEE OS的完整性，验证通过后，启动并将执行权限交给OP-TEE OS，至此，完成安全环境程序的安全启动，其中任意一个阶段的完整性验证失败，都将导致系统终止启动；现设P₀为ROM Bootloader，P₁为Flash Bootloader，P₂为OP-TEE OS，当程序P_i-1要启动程序P_i，在程序P_i被加载到内存后，程序P_i-1对程序P_i的完整性验证的执行步骤如下：

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

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

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

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

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

在步骤(2)中，可信启动具体实现如下：可信启动分为离线准备和可信启动两个阶段，

1)离线阶段

可信启动的哈希链设计：

在离线阶段设计哈希链，哈希链的初始值设置为V＝0，依次由哈希链的当前值V和下一个文件I进行哈希计算，获得新的哈希值；普通环境包括Linux OS和应用程序；由于应用程序都在cpio-Initrd压缩文件中，因此度量cpio-Initrd的完整性即度量应用程序的完整性，在离线阶段，将哈希链初始值设置为V＝0后，依次读取Linux OS的二进制文件I₁和cpio-Initrd压缩文件I₂，即可获得普通环境可信启动的哈希链终值V＝H(H(0||I₁)||I₂)，并将该值安全地保存于认证服务器，作为普通环境可信启动阶段完整性验证的参考值；

远程证明密钥存储方案：

将普通环境可信启动阶段获得的哈希链终值V用对称密钥加密后发送至认证服务器，以验证可信启动阶段的完整性；

利用CAAM模块构造的Blob数据结构，共包含三个部分：被加密的Blob Key、被加密的远程证明密钥和远程证明密钥的消息认证码MAC(Message Authentication Code)；利用CAAM模块构建Blob的具体步骤如下：

步骤1：CAAM模块利用内部的随机数生成器生成一个256位的Blob Key；

步骤2：CAAM模块采用AES-CCM加密算法，用Blob Key加密远程证明密钥，同时生成一个消息认证码MAC用于验证远程证明密钥的完整性；

步骤3：CAAM模块利用Master Key在内部生成一个Blob Key Encryption Key，用BKEK加密Blob Key，生成被加密的Blob Key；

步骤4：由被加密的Blob Key、被加密的远程证明密钥和消息认证码MAC构成Blob，存储于设备的闪存；

2)可信启动阶段：

OP-TEE OS启动后，将其作为可信启动的信任基点，实现普通环境程序的可信启动；首先基于哈希链启动Linux OS和cpio-Initrd中的应用程序，然后在系统启动后向认证服务器证明普通环境可信启动阶段的完整性；

基于哈希链的可信启动：

OP-TEE OS将可信启动的哈希链初始值设置为V＝0，具体执行步骤如下：

步骤1：OP-TEE OS读取Linux OS的二进制文件I₁；

步骤2：OP-TEE OS更新保存于安全环境安全内存的哈希值V，更新为V←Hash(V||I₁)；

步骤3：OP-TEE OS读取cpio-Initrd压缩文件I₂；

步骤4：OP-TEE OS更新保存于安全环境安全内存的哈希值V，更新为V←Hash(V||I₂)；

步骤5：OP-TEE OS启动Linux OS；

远程证明：

远程证明的具体步骤如下：

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

步骤2：示证模块利用CAAM模块解封装Blob获得远程证明密钥K，并用K加密远程证明信息；为实现Blob的解封装，首先CAAM模块在内部利用Master Key生成Blob Key EncryptionKey；然后CAAM模块用Blob Key Encryption Key解密Blob中被加密的Blob Key，获得BlobKey；最后CAAM模块用Blob Key解密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验证失败，则表明普通环境程序的完整性被破坏。