CN110730159B - 一种基于TrustZone的安全和可信混合系统启动方法 - Google Patents

一种基于TrustZone的安全和可信混合系统启动方法 Download PDF

Info

Publication number
CN110730159B
CN110730159B CN201910828486.0A CN201910828486A CN110730159B CN 110730159 B CN110730159 B CN 110730159B CN 201910828486 A CN201910828486 A CN 201910828486A CN 110730159 B CN110730159 B CN 110730159B
Authority
CN
China
Prior art keywords
key
environment
trusted
module
starting
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201910828486.0A
Other languages
English (en)
Other versions
CN110730159A (zh
Inventor
凌振
邵鑫慧
吴文甲
杨明
付新文
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Southeast University
Original Assignee
Southeast University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Southeast University filed Critical Southeast University
Priority to CN201910828486.0A priority Critical patent/CN110730159B/zh
Publication of CN110730159A publication Critical patent/CN110730159A/zh
Application granted granted Critical
Publication of CN110730159B publication Critical patent/CN110730159B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0631—Substitution permutation network [SPN], i.e. cipher composed of a number of stages or rounds each involving linear and nonlinear transformations, e.g. AES algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Storage Device Security (AREA)

Abstract

本发明公开一种基于TrustZone的安全和可信混合启动方法,首先采用安全启动技术启动安全操作系统，安全操作系统启动后即可利用TrustZone技术的内存隔离机制为可信启动的度量结果提供安全内存，随后采用可信启动技术启动功能复杂、易受攻击的通用操作系统。从而防御对系统启动阶段的篡改攻击，能够有效保证系统的完整性和可用性。

Description

一种基于TrustZone的安全和可信混合系统启动方法
技术领域
本发明属于物联网智能终端安全领域，具体涉及物联网智能终端在系统启动阶段的完整性验证方法。
背景技术
物联网在不同行业的广泛普及，促进了万物互联新时代的到来，智能家居、智能医疗、智能机器人等数以百万计的新设备接入网络。系统启动是物联网设备生命周期关键点之一，许多攻击者试图在设备断电后攻击设备，例如替换或篡改闪存中的操作系统/ 固件。如果系统启动时，直接从闪存读取操作系统/固件而不做任何验证，则可能启动一个被篡改的系统。
目前主要的针对启动阶段的完整性验证技术有安全启动技术以及可信启动技术。安全启动技术在检测到程序被篡改后会终止启动，在物联网设备的应用场景中，不符合可用性、完整性、机密性三个经典安全标准中的可用性标准。可信启动更符合物联网设备的可用性需求，但可信启动依赖可信根保证度量结果的可靠性。由于TPM(Trusted PlatformModule)和MTM(Mobile Trusted Module)等安全硬件在物联网设备中没有得到广泛部署，通过外接这些安全硬件实现可信启动，不但降低了物联网设备的灵活性，也增加物联网设备的成本。
得益于TrustZone技术安全操作系统和普通操作系统是隔离的，利用安全启动技术启动安全操作系统，安全操作系统启动后即可利用TrustZone的内存隔离机制为可信启动的度量结果提供安全内存，随后采用可信启动技术启动功能复杂、易受攻击的通用操作系统，从而完成对启动阶段的完整性验证。
发明内容
本发明的目的在于解决现有技术中存在的不足，通过结合安全启动技术以及可信启动技术，提供一种系统启动阶段完整性验证的技术，防御对系统启动时的篡改攻击，保证系统启动的完整性。
为了实现上述目的，本发明的技术方案如下：本发明在支持TrustZone的物联网智能终端上，设计安全和可信混合启动技术，实现系统启动阶段的完整性验证。一种基于TrustZone的安全和可信混合系统启动方法，所述方法依次包括以下步骤：
(1)安全启动：
利用TrustZone技术提供安全环境和普通环境，以一个可信根作为系统启动的信任基点，利用安全启动技术对安全环境程序的启动进行验证；
(2)可信启动：
安全环境启动完成后，将其作为可信启动的信任基点，利用可信启动技术实现普通环境程序的可信启动。
作为本发明的一种改进，在步骤(1)中，安全环境是指基于TrustZone技术的安全运行环境，如OP-TEE。利用一些具有防篡改能力的设备存储用于验证的可信根，在离线阶段对安全环境程序进行签名，最后在启动后对签名进行验证。
作为本发明的一种改进，在步骤(2)中，普通环境包括Linux操作系统以及应用程序，在离线阶段，度量普通环境程序的哈希值，将哈希值以及远程证明密钥安全的存储在远程认证设备；此外，远程证明密钥也需要安全的存储在物联网设备中。普通环境启动后，物联网设备将启动时生成的哈希值加密发送至远程认证设备，远程认证设备最终完成普通环境程序的完整性验证。
基于TrustZone的软件隔离机制，本发明部署安全环境和普通环境的软件资源如下：安全环境包括Bootloader和安全操作系统，其中Bootloader分为两级，第一级Bootloader内置于SoC上的ROM，本发明将其称为ROM Bootloader，第二级Bootloader 保存于Flash，本发明将其称为Flash Bootloader。同时，本发明选用OP-TEE OS作为安全环境的安全操作系统。在普通环境，本发明选用Linux OS作为通用操作系统，选用 Tmpfs和cpio-Initrd作为文件系统。其中，Tmpfs是一种基于内存的文件系统； cpio-Initrd是一个CPIO格式的压缩文件，里面包含文件系统的文件和目录。 cpio-Initrd保存于物联网设备的闪存，在系统启动阶段由Flash Bootloader将其加载至内存，Linux OS启动时在创建内存文件系统Tmpfs后会侦测出cpio-Initrd是一个CPIO 格式的压缩文件，继而将cpio-Initrd解压提取到Tmpfs形成系统的文件系统。
设备供电后，首先采用安全启动技术启动安全环境的ROM Bootloader、FlashBootloader和OP-TEE OS。OP-TEE OS启动，即证明安全环境的代码未被篡改。基于TrustZone的内存隔离机制，安全环境为可信启动的度量结果提供安全内存，随后采用可信启动技术启动普通环境的Linux OS和文件系统中的应用程序，并在系统启动后向认证服务器证明普通环境可信启动阶段的完整性。
与现有技术相比，本发明利用对安全和可信启动技术的结合，增加了安全启动的可用性，保障了可信启动的可靠性，能够有效抵御系统启动阶段的篡改攻击，保证了系统启动阶段的完整性和系统的可用性、安全性。
附图说明
图1为本发明中的流程设计方案；
图2为本发明中的安全启动设计方案；
图3为本发明中的可信启动设计方案；
图4为CAAM Blob结构；
图5为本发明中的可信启动远程证明过程。
具体实施方式
下面对本发明技术方案进行详细说明，但是本发明的保护范围不局限于所述实施例。
如图1所示，本发明的一种安全和可信混合启动方法，依次包括以下步骤：
(1)安全启动；
在系统开发完成时，在物联网设备中的一些防篡改硬件中存储安全环境用于验证签名的公钥，攻击者很难通过物理攻击来篡改其中的内容，以此确保公钥的可靠性。之后对安全环境程序进行度量并对结果用私钥进行签名。设备上电后，将签名的结果用存储在防篡改硬件中的公钥进行验证，如果验证成功，则表明安全环境没有被篡改。
(2)可信启动；
安全环境启动后，采用可信启动技术启动普通环境。在系统开发完成时，计算获得普通环境程序的哈希值并将其存储与远程认证设备，作为验证普通环境可信启动阶段完整性的参考值。为了保证通信时数据的安全，需要在物联网设备以及远程认证设备上安全的存储一个远程证明密钥，用于数据的加密。普通环境启动后，将度量结果的哈希值以及从认证设备那取得的随机数进行加密发送给认证服务器进行验证，如果哈希值以及随机数都验证通过，则表明普通环境可信启动阶段的完整性验证通过；如果随机数验证失败，则表明受到重放攻击；如果哈希值验证失败，则表明普通环境程序的完整性被破坏。
应用实施例1：
本实施中的安全和可信混合启动技术：包括以下步骤：
一、安全环境的安全启动：
安全环境的安全启动技术基于签名机制，因此分为签名和验证签名两个过程，具体如图2所示。图中的上半部分为的签名过程，在离线阶段完成，且只执行一次；图中的下半部分为验证签名过程，在每次系统启动时执行。
1)离线阶段；
为实现安全启动，在离线阶段分别度量安全环境的Flash Bootloader和OP-TEEOS，并对度量结果签名。执行过程如图2的上半部分所示，采用SHA256算法计算FlashBootloader的哈希值作为Flash Bootloader的度量结果，用Flash Bootloader的私钥对该度量结果签名，其公钥的哈希值保存于eFuse。Flash Bootloader的公钥附在FlashBootloader后面，Flash Bootloader的签名附在Flash Bootloader的公钥后面，将FlashBootloader及其公钥和签名作为一个整体存储于物联网设备的闪存。同理，计算OP-TEE OS的哈希值作为OP-TEE OS的度量结果，用OP-TE OS的私钥对该度量结果签名，其公钥的哈希值保存于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为安全启动的信任基点，负责验证Flash Bootloader的完整性，验证通过后，启动并将执行权限交给Flash Bootloader。Flash Bootloader验证OP-TEE OS的完整性，验证通过后，启动并将执行权限交给OP-TEEOS，至此，完成安全环境程序的安全启动。其中任意一个阶段的完整性验证失败，都将导致系统终止启动。现设P0为ROM Bootloader，P1为Flash Bootloader，P2为OP-TEE OS，当程序Pi-1要启动程序Pi，在程序Pi被加载到内存后，程序Pi-1对程序Pi的完整性验证的执行步骤如下：
步骤1：Pi-1分别从内存中读取Pi、Pi的公钥和Pi的签名。
步骤2：Pi-1计算公钥的哈希值，将计算结果与存储在Pi-1中的公钥哈希比对。特殊的，当Pi为安全环境的Flash Bootloader时，需将计算结果与存储在eFuse的公钥哈希比对。如果匹配，执行步骤3；否则，终止启动。
步骤3：Pi-1用公钥解密签名，获得度量结果m。
步骤4：Pi-1重新计算Pi的哈希值，获得度量结果m′。将m′与步骤3获得的m比对，如果匹配，执行Pi；否则，终止启动。
如果OP-TEE OS启动，则证明安全环境的代码未被篡改，即安全环境可信，且TrustZone的隔离机制保证普通环境的程序没有权限访问安全环境的资源，因此安全环境可为可信启动提供安全内存，并将安全环境的OP-TEE OS作为可信启动的信任基点。
二、普通环境的可信启动方法；
OP-TEE OS启动后，为同时满足物联网设备的可用性和安全性需求，采用可信启动技术启动普通环境的程序。可信启动技术分为离线准备和可信启动两个阶段，具体如图3所示。图中的上半部分为离线阶段，在系统开发时完成，且只执行一次，计算获得的哈希链终值V保存于认证服务器，作为验证普通环境可信启动阶段完整性的参考值。图中在下半部分为可信启动阶段，在每次系统启动时执行。由于可信启动要通过远程证明的方式证明可信启动阶段的完整性，因此还需在物联网设备上安全地存储一个远程证明密钥。
1)离线阶段
1.可信启动的哈希链设计
为实现普通环境程序的可信启动，需在离线阶段设计如图3上半部分所示的哈希链。哈希链的初始值设置为V＝0，依次由哈希链的当前值V和下一个文件I进行哈希计算，获得新的哈希值。普通环境包括Linux OS和应用程序。由于应用程序都在cpio-Initrd 压缩文件中，因此度量cpio-Initrd的完整性即度量应用程序的完整性。在离线阶段，将哈希链初始值设置为V＝0后，依次读取Linux OS的二进制文件I1和cpio-Initrd压缩文件I2，即可获得普通环境可信启动的哈希链终值V＝H(H(0||I1)||I2)，并将该值安全地保存于认证服务器，作为普通环境可信启动阶段完整性验证的参考值。
2.远程证明密钥存储方案
本发明设计将普通环境可信启动阶段获得的哈希链终值V用对称密钥加密后发送至认证服务器，以验证可信启动阶段的完整性。因此在离线阶段，需分别在认证服务器和物联网设备存储一个远程证明密钥。
如果物联网设备支持安全存储或相关功能，则可以把远程证明密钥存储在安全存储，如果物联网设备不支持，则可以采用其他方案保证远程证明密钥的安全性，本发明基于i.MX6q的CAAM(Cryptographic Acceleration And Assurance Module)模块实现在设备的闪存中安全地存储一个远程证明密钥。
CAAM模块为一个加速硬件加密的模块，其内部包含一个随机数生成器，用该随机数生成器可以在CAAM模块内部生成Blob Key，同时CAAM模块由SNVS(Secure Non-VolatileStorage)为其提供一个256位的非易失性Master Key。CAAM模块的Blob机制可以保证远程证明密钥的机密性和完整性。
本发明利用CAAM模块构造的Blob数据结构如图4所示，共包含三个部分：被加密的Blob Key、被加密的远程证明密钥和远程证明密钥的消息认证码MAC(MessageAuthentication Code)。由于Blob中需要提供机密性和完整性保护的远程证明密钥已经被加密，因此Blob可以安全的存放于设备的闪存。在离线开发阶段，本发明利用CAAM 模块构建Blob的具体步骤如下：
步骤1：CAAM模块利用内部的随机数生成器生成一个256位的Blob Key。
步骤2：CAAM模块采用AES-CCM加密算法，用Blob Key加密远程证明密钥，同时生成一个消息认证码MAC用于验证远程证明密钥的完整性。
步骤3：CAAM模块利用Master Key在内部生成一个Blob Key Encryption Key，即图4中的BKEK，用BKEK加密Blob Key，生成被加密的Blob Key。
步骤4：由被加密的Blob Key、被加密的远程证明密钥和消息认证码MAC构成Blob，存储于设备的闪存。
默认情况下，安全环境和普通环境的程序都可以利用CAAM模块解封装Blob获取其中的远程证明密钥，为防御普通环境中的攻击程序从Blob中获取远程证明密钥，本发明利用i.MX6q的CSU(Central Security Unit)单元设置CAAM模块的访问权限，保证只有安全环境的程序可以访问CAAM模块，即保证只有安全环境的程序可以解封装Blob获得远程证明密钥。
CSU是在总线主控(Bus Master)和总线从控(Bus Slaves)之间设置访问控制策略的硬件单元，允许将外设划分为四个不同的安全模式，分别对应于普通环境的用户模式、普通环境的特权模式、安全环境的用户模式和安全环境的特权模式，每个安全模式又可以分别设置外设的读权限(RD)和写权限(WR)。CSU单元通过CSL(Configure Slave Level) 寄存器设置外设的访问权限，CSL寄存器的值和访问权限的对应关系如表1所示。
表1：外设访问权限表
Figure BDA0002189878780000061
从表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-TEE OS启动过程中设置第17 个CSL寄存器的16-24位，即CSL16[24:16]，从而实现CAAM模块的访问权限控制。
2)可信启动阶段
OP-TEE OS启动后，将其作为可信启动的信任基点，实现普通环境程序的可信启动。可信启动过程如图3的下半部分所示，首先基于哈希链启动Linux OS和cpio-Initrd 中的应用程序，然后在系统启动后向认证服务器证明普通环境可信启动阶段的完整性。
3.基于哈希链的可信启动
为实现普通环境程序的可信启动，OP-TEE OS依次度量Linux OS和cpio-Initrd的完整性。OP-TEE OS将可信启动的哈希链初始值设置为V＝0，具体执行步骤如下：
步骤1：OP-TEE OS读取Linux OS的二进制文件I1。
步骤2：OP-TEE OS更新保存于安全环境安全内存的哈希值V，更新为V←Hash(V||I1)。
步骤3：OP-TEE OS读取cpio-Initrd压缩文件I2。
步骤4：OP-TEE OS更新保存于安全环境安全内存的哈希值V，更新为V←Hash(V||I2)。
步骤5：OP-TEE OS启动Linux OS。
4.远程证明
Linux OS启动后，为实现如图5所示的远程证明，本发明在安全环境设计示证模块，该模块利用CAAM模块解封装Blob获得远程证明密钥，并用该密钥对远程证明的信息加密；在普通环境设计数据转发模块，用于验证模块和示证模块之间的数据转发；在认证服务器上设计验证模块，用于验证普通环境可信启动阶段的完整性。远程证明的具体步骤如下：
步骤1：可信物联网设备向验证模块请求Nonce。普通环境的数据转发模块与验证模块建立SSL加密连接，向验证模块请求一个Nonce，该值每次由验证模块随机生成以对抗重放攻击。普通环境的数据转发模块将接收到的Nonce通过共享内存的方式传送给安全环境的示证模块，示证模块将Nonce拷贝到安全环境的内存。
步骤2：示证模块利用CAAM模块解封装Blob获得远程证明密钥K，并用K加密远程证明信息。为实现Blob的解封装，首先CAAM模块在内部利用Master Key生成Blob KeyEncryption Key；然后CAAM模块用Blob Key Encryption Key解密Blob中被加密的BlobKey，获得Blob Key；最后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验证失败，则表明普通环境程序的完整性被破坏。
通过上述实施例可以看出，本发明混合了安全和可信启动技术，利用安全启动技术启动安全操作系统，在安全操作系统下利用可信启动技术启动普通环境的操作系统，有效抵御了系统在启动阶段被篡改的可能性，保证了系统启动阶段的完整性。

Claims (1)

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，至此，完成安全环境程序的安全启动，其中任意一个阶段的完整性验证失败，都将导致系统终止启动；现设P0为ROM Bootloader，P1为Flash Bootloader，P2为OP-TEE OS，当程序Pi-1要启动程序Pi，在程序Pi被加载到内存后，程序Pi-1对程序Pi的完整性验证的执行步骤如下：
步骤1：Pi-1分别从内存中读取Pi、Pi的公钥和Pi的签名；
步骤2：Pi-1计算公钥的哈希值，将计算结果与存储在Pi-1中的公钥哈希比对，特殊的，当Pi为安全环境的Flash Bootloader时，需将计算结果与存储在eFuse的公钥哈希比对，如果匹配，执行步骤3；否则，终止启动；
步骤3：Pi-1用公钥解密签名，获得度量结果m；
步骤4：Pi-1重新计算Pi的哈希值，获得度量结果m′，将m′与步骤3获得的m比对，如果匹配，执行Pi；否则，终止启动；
如果OP-TEE OS启动，则证明安全环境的代码未被篡改，即安全环境可信，且TrustZone的隔离机制保证普通环境的程序没有权限访问安全环境的资源，因此安全环境可为可信启动提供安全内存，并将安全环境的OP-TEE OS作为可信启动的信任基点；
在步骤(2)中，可信启动具体实现如下：可信启动分为离线准备和可信启动两个阶段，
1)离线阶段
可信启动的哈希链设计：
在离线阶段设计哈希链，哈希链的初始值设置为V＝0，依次由哈希链的当前值V和下一个文件I进行哈希计算，获得新的哈希值；普通环境包括Linux OS和应用程序；由于应用程序都在cpio-Initrd压缩文件中，因此度量cpio-Initrd的完整性即度量应用程序的完整性，在离线阶段，将哈希链初始值设置为V＝0后，依次读取Linux OS的二进制文件I1和cpio-Initrd压缩文件I2，即可获得普通环境可信启动的哈希链终值V＝H(H(0||I1)||I2)，并将该值安全地保存于认证服务器，作为普通环境可信启动阶段完整性验证的参考值；
远程证明密钥存储方案：
将普通环境可信启动阶段获得的哈希链终值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的二进制文件I1；
步骤2：OP-TEE OS更新保存于安全环境安全内存的哈希值V，更新为V←Hash(V||I1)；
步骤3：OP-TEE OS读取cpio-Initrd压缩文件I2；
步骤4：OP-TEE OS更新保存于安全环境安全内存的哈希值V，更新为V←Hash(V||I2)；
步骤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验证失败，则表明普通环境程序的完整性被破坏。
CN201910828486.0A 2019-09-03 2019-09-03 一种基于TrustZone的安全和可信混合系统启动方法 Active CN110730159B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910828486.0A CN110730159B (zh) 2019-09-03 2019-09-03 一种基于TrustZone的安全和可信混合系统启动方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910828486.0A CN110730159B (zh) 2019-09-03 2019-09-03 一种基于TrustZone的安全和可信混合系统启动方法

Publications (2)

Publication Number Publication Date
CN110730159A CN110730159A (zh) 2020-01-24
CN110730159B true CN110730159B (zh) 2022-01-25

Family

ID=69218870

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910828486.0A Active CN110730159B (zh) 2019-09-03 2019-09-03 一种基于TrustZone的安全和可信混合系统启动方法

Country Status (1)

Country Link
CN (1) CN110730159B (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110635904B (zh) * 2019-09-16 2020-07-31 绍兴文理学院 一种软件定义物联网节点远程证明方法及系统
CN111353150B (zh) * 2020-02-25 2022-06-07 苏州浪潮智能科技有限公司 一种可信启动方法、装置、电子设备及可读存储介质
US11921904B1 (en) * 2020-04-08 2024-03-05 Marvell Asia Pte Ltd System and methods for firmware security mechanism
CN113626818B (zh) * 2020-05-08 2023-10-20 华为技术有限公司 计算机系统、服务处理方法、可读存储介质及芯片
CN114491565B (zh) * 2022-03-31 2022-07-05 飞腾信息技术有限公司 固件安全启动方法、装置、计算设备和可读存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107908977A (zh) * 2017-09-28 2018-04-13 中国船舶重工集团公司第七0九研究所 基于TrustZone的智能移动终端信任链安全传递方法及系统

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8375221B1 (en) * 2011-07-29 2013-02-12 Microsoft Corporation Firmware-based trusted platform module for arm processor architectures and trustzone security extensions
CN103514414A (zh) * 2012-06-26 2014-01-15 上海盛轩网络科技有限公司 一种基于ARM TrustZone的加密方法及加密系统

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107908977A (zh) * 2017-09-28 2018-04-13 中国船舶重工集团公司第七0九研究所 基于TrustZone的智能移动终端信任链安全传递方法及系统

Also Published As

Publication number Publication date
CN110730159A (zh) 2020-01-24

Similar Documents

Publication Publication Date Title
CN110730159B (zh) 一种基于TrustZone的安全和可信混合系统启动方法
CN109313690B (zh) 自包含的加密引导策略验证
US10885197B2 (en) Merging multiple compute nodes with trusted platform modules utilizing authentication protocol with active trusted platform module provisioning
JP5703391B2 (ja) 耐タンパー性ブート処理のためのシステム及び方法
US7986786B2 (en) Methods and systems for utilizing cryptographic functions of a cryptographic co-processor
US8019994B2 (en) Authentication of a request to alter at least one of a BIOS and a setting associated with the BIOS
CN104160403B (zh) 使用单个可信平台模块测量平台部件
JP4638912B2 (ja) ディストリビューションｃｄを使用した、署名されたグループにおけるダイレクトプルーフの秘密鍵を装置に伝達する方法
US20110246778A1 (en) Providing security mechanisms for virtual machine images
CN111264044B (zh) 芯片、生成私钥的方法和可信证明的方法
KR20170095163A (ko) 하드웨어 디바이스 및 그 인증 방법
US11082214B2 (en) Key generation apparatus and key update method
CN110688660B (zh) 一种终端安全启动的方法及装置、存储介质
TW201516733A (zh) 用以核對ｕｅｆｉ認證變量變化之系統及方法
WO2006002282A1 (en) Systems and methods for performing secure communications between an authorized computing platform and a hardware component
JP2011522469A (ja) 保護されたソフトウエアイメージを有する集積回路及びそのための方法
US10282549B2 (en) Modifying service operating system of baseboard management controller
JP2018117185A (ja) 情報処理装置、情報処理方法
JP2017011491A (ja) 認証システム
Nyström et al. UEFI NETWORKING AND PRE-OS SECURITY.
US20220182248A1 (en) Secure startup method, controller, and control system
CN116566613A (zh) 使用平台密钥保护与安全处理器的通信
US20230351056A1 (en) Sram physically unclonable function (puf) memory for generating keys based on device owner
Plappert et al. Evaluating the applicability of hardware trust anchors for automotive applications
US20220209946A1 (en) Key revocation for edge devices

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant