RIOT文档三

Device Identity with DICE and RIoT: Keys and Certificates

Abstract

该规范描述了基于TLS协议和X.509客户端证书的加密设备标识和认证方案。协议和证书格式可以由任何类型的安全处理器实现，但是尤其适用于适合于DICE+RIoT的安全架构。没有基于硬件的安全性的设备也可以在软件中实现协议，尽管这样将导致对最终的身份和认证较低的保证。

1. Contents

（略）

2. Terms and Definitions

Alias Key, Credential, and Certificate
Alias Key是由设备创建的非对称密钥对，每个新固件版本都要创建新的Alias Key(也可以更频繁的创建)。Alias Key的公钥通过设备的设备DeviceID Key进行认证，以形成Alias Key Certificate。Key和Certificate一起构成了Credential。

Attestation
认证是一个设备的安全配置的加密报告。在这个规范中，认证信息被编码为一个名为固件ID(FWID：Firmware ID)的加密散列值。

DeviceID Key, Credential, and Certificate
设备标识(DeviceID)是一种非对称密钥对，它作为设备的长期标识符。该规范假定DeviceID永远不变。如果供应商提供了一种机制来更改DeviceID，不管是使用远程使用加密协议，还是在重新制造，那么该规范中的协议将把它识别为不同的设备。

如果DeviceID密钥对是使用DICE+RIoT机制创建的，那么DeviceID将与设备硬件身份和RIoT Core组件联系起来。RIoT Core被认为是不变的，因此DeviceID不会改变。
DeviceID公钥可以通过设备厂商认证或自认证以形成DeviceID证书。

Device Identity Composition Engine (DICE)
DICE，是一个硬件/固件的能力，它能生成一个密码学上的唯一值，用于在设备上启动的最低层的软件。
兼容DICE的平台支持RIoT风格的安全架构。

Composite Identity
Composite Identity是一种数据结构，它编码了设备的硬件标识(DeviceID)和正在运行的固件(FWID)。

Compound Device Identity (CDI)

CDI是一个特殊的值，它是一个设备和它启动的RIoT Core的加密标识(例如散列)的惟一值。

Firmware ID (FWID)
The Firmware Identity (FWID)是Firmware Security Descriptor (FSD)的哈希值。

Firmware Security Descriptor (FSD)
固件安全描述符是一个供应商定义的机器可读数据结构，它描述了第1层代码的标识(可能还有其他与安全相关的数据)。RIoT使用FSD来验证它加载的第1层代码。

FSD可能包括：

1. Layer1固件镜像
2. 加密的标明被授权的Layer1的固件的清单文件
3. 在安全启动实现的环境中，已签名固件的固件版本号
4. 设备的关键的安全配置

这个文档既没有定义什么状态是安全的，也没有定义它在FSD中是如何表示的。但是，FSD应该是机器可读的，并且应该有一个规范化的表示，可以被散列以形成FWID。

对于DICE和RIoT体系结构中，以及本文档的上下文中，RIoT CORE被认为是不变的。因此，FSD不包括防暴核心层的标识。(未来的规范可能允许对防暴核心层进行安全更新。)

Layer
许多计算机系统以分阶段的方式启动，每一层都进行身份验证，并加载下一层，提供越来越复杂的运行时服务。
在这个规范中，第0层是由处理器启动的第一个代码。在DICE+RIoT系统中，Layer0也被称为RIoT Core，并提供基本的安全服务。简单的设备把所有功能打包进Layer1。更复杂的设备可能包含更多的层。

Name-Encoded DeviceID
Name-Encoded DeviceID是一个可选的字符串，哈希编码了DeviceID public key，并且出现在X509证书中的Issuer Name或者Subject Name字段中。

RIoT
一种针对计算设备提供基础信任服务的安全架构。

RIoT Core
RIoT指的是被处理器用于measure出CDI的那部分代码。反过来，RIoT Core使用CDI来创建DeviceID和其他密钥。虽然该文档主要关注设备的identity，但完整的RIoT实现也可以提供静态数据保护、安全固件更新和其他服务特性。RIoT Core的实现一般都是有设备供应商自行实现。

本文档中假设RIoT Core不会改变。

Security Processor

对密钥和有关操作进行保护的特定处理器。

3. Overview

以下部分提供了该规范中定义的协议和证书格式的概述。本节中的协议可以通过软件或硬件安全处理器实现。后面的部分将描述如何在基于RIoT的系统中创建密钥和证书。

3.1 Protocal Overview

设备通过传输级安全性(TLS)会话与客户端证书进行身份验证，并建立安全的通信。该规范定义了X509客户端证书配置文件和证书链接规则，允许设备对自己及其安全配置进行身份验证(eg：他们正在运行的固件)。

所有符合标准的设备都被配置或者可以生成一个称为DeviceID的非对称密钥对。该规范假设DeviceID的生命周期与设备的生命周期相同。供应商可能允许DeviceID改变(例如在重新制造或使用其他加密协议时)，但是依赖于此规范中的协议的各方将会将其识别为另外的设备。

设备还生成了第二个密钥家族，称为Alias Key。与不可更改的DeviceID creditial相比，Alias Key及其凭证的创建更频繁(例如，当设备固件更新或所有者更改时)。

Alias Key和可选的DeviceID key用x509格式证书进行认证。DeviceID Key的主要功能是验证Alias Key。生成的Alias kay证书中的字段还可以指定固件ID(例如补丁级别或设备固件的散列)来支持认证（attestation）。

DeviceID公钥本身可以由厂商认证，如果没有供应商认证或要求，它们可能是自我认证的，也可能是未经认证的。在前一种情况下，DeviceID作为从属CA，而在后一种情况下，DeviceID是根CA。设备可以支持多个选项来服务不同的依赖方。参见图1。

在TLS会话中，设备使用当前的Alias key及其证书作为客户端证书进行身份验证。根据认证场景，设备还可以在TLS握手期间发送厂商认证的DeviceID证书链或自我认证的DeviceID证书。如果TLS握手成功，服务器可以从DeviceID证书和来自Alias Key的固件ID中确定DeviceID的公钥部分。

设备还应该验证服务器TLS证书，本文不详述。

3.2 DeviceID and FWID Encodings

该规范定义了一个包含DeviceID(即硬件标识)和FWID(即软件标识)的Conposite Identity数据结构。Conposite Identity包含在Alias Key证书的Alternative Subject Name字段中。

3.3 TLS Handshake and Certificate Validation

实现此规范的设备通过TLS来认证他们的身份(它们的DeviceID)和它们的安全关键配置(它们的FWID)。希望对客户端进行身份验证的服务器必须请求客户端证书。符合标准的设备将会作出回应:

1. 生产商CA的证书链
2. 以DeviceID作为根的证书链
3. (bare)Alias证书

在TLS握手期间，服务器还应该提供服务器证书。如果服务器证书链无效或不可信，则设备可以终止连接。

但是具体定义了依赖方使用的策略来验证和授权设备超出了本文档范围。然而，以下的考虑可能是相关的:

1. All Certificate Chain Processing

   应实现RFC5280标准，例如：

   - 证书应该在有效期内被签名
   - 等等
   

   DeviceID证书中的DeviceID应该与Alias证书中的CI中的DeviceID一致。

2. Non-Vendor-Certified DeviceIDs

   没有生产商签名的证书应该自签名，且DeviceID可识别。

3. Vendor-Certified DeviceIDs

   有生产商签名，DeviceID证书应该回溯回CA

4. Bare Alias Certificates

   Alias证书签名必须是被CDI中的DeviceID签名得到的。

如果检查上述条件均满足，则可以从Alias证书的Subject Alternative Nave字段中提取出DeviceID和FWID。

3.4 Attestation

在该规范的上下文中，认证是通过其固件ID对设备的安全配置进行加密报告。FWID被定义为机器可读的数据结构的散列，称为固件安全描述符，它捕获了供应商认为相关的所有安全关键信息。

在最简单的情况下，固件安全描述符只是设备上的第1层固件。在这种情况下，FWID将是可更新固件映像的散列。更复杂的固件安全描述符包括识别授权固件、用于认证固件的数字证书的版本号、以及平台配置注册式的安全日志。

3.5 Bugs and Patching

再次说明，本文档中规定，DeviceID在设备的生命周期中不可变，Alias则会比较频繁的更新。

实现此规范的设备应该为DeviceID的私钥提供最高级别的保护。理想情况下，这将涉及到DICE—+RIOT机制或其他基于硬件的保护。如果DeivceID私钥被公开或用于发出恶意证书(未来的规范可能会处理这种能力)，该规范没有提供任何方法来进行挽救。

在零日特权升级错误或未知固件漏洞的情况下，没有任何现有的认证计划能够提供关于当前设备安全配置的权威报告。这是因为，如果固件是可开发的，就无法知道实际运行的代码是什么。然而，该规范中描述的认证方法可以证明该设备运行的是最新的固件版本(而不是旧的或未知的软件)。这意味着认证(至少)对旧固件的更新是有用的，因为旧的固件将被测试，并且永远不能模拟更新的固件。

3.6 Example DICE+RIoT Software Architecture

本节描述了一个利用DICE和RIoT机制实现的密钥和证书的生成过程。

DICE基于处理器和ROM，它可以为删层软件提供一个称为(CDI)的秘密，它依赖于硬件设备，以及引导层的身份。RIoT是使用CDI作为设备标识、存储保护和其他安全功能的一族技术。

图2说明了这么一个架构：一个启用了DICE的处理器运行一个名为RIoT Core的第一个引导程序，它来启动称为Layer 1的剩余设备固件。处理器中的DICE功能创建CDI，并将其传递给RIoT Core。CDI通常是一个32字节的值，它通过各个设备自己的UDS和RIoT Core的measurement生成的加密单向函数。RIoT Core使用CDI来派生额外的密钥和秘密，然后从RAM和寄存器中删除CDI。该规范假定RIoT Core永远不会改变，因此CDI在设备的生命周期中保持不变。

包含第1层的代码和安全关键配置数据的标识由它的FWID表示。防暴核心层负责确保第1层与由FWID表示的固件安全描述符(FDS)兼容。

除了Alias Key证书生成之外，RIoT还可以为DeviceID公钥生成自签署的DeviceID证书和自签名证书签名请求(CSR)。

下面的部分描述了RIoT生成符合该规范的密钥和证书的一种方式。

3.7 RIoT Core Operations

每次引导RIoT Core都要干下面的活：

1. 计算FWID

   通过直接的measurement（镜像的哈希）和间接地measurement（通过FSD生成的证书或是清单）生成FWID。如果FSD失效或是遗失，后续过程应该立刻abort并且cleanup。

2. 创建DeviceID

   RIoT Core使用CDI一个非对称的DeviceID密钥对。在该规范中，假定RIoT Core是不更改的，因此在每次启动时都创建了相同的DeviceID。公钥将会传递给Layer1，私钥在4、5步继续使用。

3. 创建Alias Key

   以CDI和FWID进行确定性生成。然后整个密钥对将会传递给Layer1，公钥部分在第4步还会用到。

4. 生成Alias Cert

   RIoT为Alias Key生成了一个证书，其中在Subject Alternative Name这个字段中写入了CI。然后通过DeviceID签名证书，然后把证书发给Layer1。

5. 生成DeviceID自签名证书（可选）

   通过DeviceID签名DeviceID的证书

6. 生成CSR

   为DeviceID公钥生成CSR，并用DeviceID私钥签署。

7. Cleanup
   清除RAM和寄存器，使得清除CDI和DeviceID。

3.8 Layer1 Behavior

RIoT Core给Layer 1提供了如下数据：

1. DevID Pub和DevID Cert
2. Alias Key Pair
3. Alias Cert by DeviceID
4. FSD(可能是显式的，也可能是其他方式）

Layer1也可以加载其他模块，并假定他们通过FSD被授权。最终Layer1可以以TLS为工具，通过来自RIoT Core的密钥和证书来认证自己。

Layer1应该确保：

1. 它只使用在这次引导中发布的Alias密钥。也就是说，Layer1的固件不应该使用之前发布的版本的Alias证书。
2. Alias Key的私钥不能暴露给外部和不受信任的实体。
3. Alias Key的私钥不能暴露给更早版本的固件。

如果满足了这些条件，使用本规范中描述的协议的各方可以对设备及其当前的安全配置进行验证。

3.9 Extending to Multiple Layers

协议和RIoT实现都直接扩展到多层引导，以及在同一主机上运行的多个程序的身份验证。

对于一个运行单片机设备固件的RIoT Core层，RIoT Core为固件生成了一个TLS会话中使用的Alias Key证书和密钥对。

如果实现了更多的层，则中间层将执行与RIoT Core类似的功能。每个额外的层将为后续层创建一个新的Alias Key，以及编码了后续层的FWID的Alias Key证书。在后续层发布的Alias Key证书是与本层自己的Alias Key(而不是DeviceId Key)签署的。换句话说，额外的层可以看成额外的CA。

这个方案可以一直扩展到应用程序层，每个应用程序都有一个惟一的Alias Key和对它进行编码的证书。

在这些情况下，依赖方可以遍历别名证书链，以建立顶层的标识和构成顶层可信计算基础的所有低层的标识。

（后续略）