RIOT文档二

可信平台架构——设备标识符组合引擎的硬件需求

1. Scope and Audience

本规范描述了通过Device Secret和首次出现的可变代码的散列所派生出来的identity value的硬件要求和整体流程。该规范将此派生值称为复合设备标识符CDI(Compound Device Identifier)。这个
复合设备标识符的组成收到硬件状态或配置和第一代可变代码的影响。

CDI的一个可能的应用是attest一个嵌入式设备是否可信。

文档的潜在读者是不可访问TPM的可编程组件的程序设计师。

2. Normative references(规范性引用文件)

(略)

3. Terms and definitions(名词解释)

  1. CDI

    复合设备标识符是一组数据,用于标识用于生成该数据的系统上运行的软件。

  1. digest

    hash值

  2. device

    一种整合了可编程组件与其他可选的可编程组件和外围设备平台。

  1. DICE

    Device Identifier Composition Engine: 创建CDI的不可变引擎

  2. measurement

    代码或者数据的安全哈希

  3. UDS

    只有制造商和DICE知道的Unique Device Secret,并且被DICE用于生成CDI。

4. Symbols and Abbreviated Terms(符号和缩写术语)

(略)

5. Introduction

CDI通过UDS和运行在平台上的第一代可变代码计算得到,并且涉及到了硬件状态信息和影响第一代可变代码的执行的配置信息。CDI被DICE计算出来。DICE在系统reset之后、移交控制权给可变代码之前,对UDS有着排他的访问权限。UDS由制造商以任何与该规范相一致的方式提供。如Figure 1中,举例说明CDI的计算的一般流程。UDS或者被测组件的任何改动都会导致CDI结果的改变。

UDS和可变代码的度量必须以一种加密的方式混合在一起,用CDI和代码度量来恢复UDS是不可行的。这可以通过使用一个安全的哈希算法来实现这两个值的连接。另外,这两个值可以在HMAC中使用,并使用UDS作为HMAC键。 HMAC将为UDS提供更高级别的保护,而不是简单的散列。结合这些值的具体方法是制造商的选择,因为它不影响互操作性。

方式(1):如果是哈希函数就把UDS和measurement连接起来进行哈希

方式(2):如果使用HMAC就用UDS作为key对measurement进行HMAC

HMAC操作需要花费更多的时间,但是依据 NIST SP800-57 中的描述,方式(2)可以提供二倍于方式(1)的保护级别。

在需要的地方,设备需要负责保护对CDI的访问(读、写和修改)。通过可变代码对CDI进行保护是不可行的。如何实现CDI的保护,超出了本规范的范围。

6. Requirements

6.1 Unique Device Secret properties(UDS的属性)

UDS的值 必须 是不相关的,并且在统计上是唯一的。

任何其他实体都 严禁 将UDS用作身份值。**

设备 必须 具有至少与设备认证过程中使用的安全强度相同的UDS。认证过程报告了设备的软件状态和身份。

当认证过程由不受设备制造商控制的软件决定时,UDS的大小 至少应该 是256位。

建议256位是因为SHA1已经被弃用,长的UDS意味着更长的实现寿命。

UDS 不应该 被重新写(rewritable)。

注:UDS改变意味着设备的身份改变,这意味着认证失败和先前的数据无法访问。

6.2 Device Identifier Composition Engine properties(DICE的属性)

在设备上实现的DICE 应该 是不可变的。

在设备的制造过程结束时,DICE就将不可变。

DICE 必须 具有对UDS具有排他的读取权限。

这意味着,实现DICE的可编程组件的封装通常会排除使用、读取和观察除DICE之外的实体的使用。

通常情况下,当一个硬件事件(例如重设)导致DICE开始执行时,对包含UDS的存储位置的访问将被启用。然后,读取存储位置的访问权限将被一个软件命令禁用。其他的实现也是可以的。

如果设备有调试端口或者调试模式的话:

  • 调试端口或调试模式只应在重置时启用,或者由在DICE执行后,由软件显式启用。

  • 当启用调试端口或调试模式时,任何试图读取UDS(包括DICE)的尝试都将被拒绝,或者产生与UDS无关的值。

任何常数值,比如所有的0,都是一个不相关的值。

6.3 Compound Device Identifier properties

CDI的规范需求超出了本文档的范围。

该设备可能需要专用的硬件来保护访问(读、写和修改)到CDI。

如果硬件无法保护CDI,那么由制造商提供的可变代码将减少CDI暴露给未授权实体的机会。通过对授权的可变代码进行度量而泄漏CDI的设备可能容易受到重放攻击和模拟的攻击。

鼓励设备制造商使用最佳实践(例如:iso/iec 27034)来防止CDI的泄漏。可能采取的措施包括:

1. 避免设计、编码和逻辑上的错误
2. 使用后立刻从RAM、寄存器、cache中擦除CDI

一个被可变代码泄漏的CDI应该以更新制造商的可变代码的方式淘汰。这将导致DICE产生一个新的CDI并且移除了泄漏的原因。

6.4 DICE Operation

当设备被重新设置时,在设备上的任何可变代码执行之前,DICE都不会受到干扰或改变。

在执行可变代码之前,DICE应该将UDS与第一代可变代码的measurement结合起来,这样就不能从CDI中推导出UDS,即使测量是已知的。

DICE将使用至少与UDS相同的加密强度的单向函数来创建CDI。

根据NIST的sp800-57,第1部分;在HMAC中使用散列算法提供的安全性和在摘要中的比特数一样多,但是在散列中使用的算法只提供了大约一半的比特。使用UDS作为HMAC密钥将使安全强度与UDS一样强大。

在执行可变代码之前,对UDS的访问将被禁用,直到下一次设备reset。

禁用功能可以通过很多方式实现,例如,通过将UDS存放在一次只读存储器中,通过显式的软件指令,通过硬件识别指令指针是否DICE指示的范围内 仅允许访问的UDS范围,通过在安全协处理器上只运行DICE并且只允许访问该安全协处理器访问DICE。或者其他可能的实现可是可以的。

在执行可变代码之前,DICE应该安全地删除任何可以用来确定UDS的值。

只要可变代码需要独占访问权,就可以将CDI写到一个位置,在这个位置上,可变的可变代码具有独占访问权。

可变代码可以使用和删除CDI和任何可以用来确定CDI的值。当可变代码使用CDI时,它需要保证阻止对CDI的访问和避免该值的泄露。

访问包括读、写、修改。

可变代码使用CDI的具体细节不在本文档中予以说明

DICE应使得设备在可变代码的范围内执行可变的代码,这些代码在被测的可变代码的范围内。

本站总访问量