10. 新鲜度
10. 新鲜度
验证者或依赖方可能需要了解证据或认证结果产生的时间点(即"时期")。这对于判断所包含的声明是否可以被认为是新鲜的至关重要,这意味着它们仍然反映了证明者的最新状态,并且任何认证结果都是使用最新的证据、背书和参考值评估策略生成的。
本节提供了许多细节。但是,它不定义任何协议格式,所示的交互是抽象的。本节旨在帮助创建协议和解决方案的人员了解确保新鲜度的可用选项。在协议中提供新鲜度的方式是一个架构决策。新鲜度的提供会影响协议中所需的往返次数;因此,必须在设计早期做出决定。不同的决策将对最终的互操作性产生重大影响,这就是为什么本节要详细说明,以便新鲜度的选择在交互协议之间兼容,如图 9 所示。
新鲜度是根据证据或认证结果的评估策略来评估的,该策略将估计的时期与该策略本地定义的"过期"阈值进行比较。然而,总是存在竞态条件的可能性,即证明者的状态和评估策略可能在证据或认证结果生成后立即改变。目标只是将它们的时效性缩小到验证者(对于证据)或依赖方(对于认证结果)愿意接受的程度。对新鲜度要求的一些灵活性是启用证据和认证结果的缓存和重用的关键组成部分,这在它们的计算使用大量资源预算的情况下尤其有价值(例如,受限设备中的能量)。
有三种常见的方法来确定证据或认证结果的时期。
10.1. 使用同步时钟的显式计时
第一种方法是依赖同步且可信的时钟,并在证据或认证结果的声明中包含签名的时间戳(参见 [RATS-TUDA])。时间戳也可以基于每个声明添加,以区分证据或认证结果的生成时间与特定声明生成的时间。时钟的可信性通常可以通过背书建立,并且通常需要关于签名者时间同步机制的额外声明。
然而,在某些用例中可能无法获得可信的时钟。例如,在当今的许多 TEE 中,时钟仅在 TEE 外部可用;因此,TEE 无法信任它。
10.2. 使用随机数的隐式计时
第二种方法将计时的责任完全放在验证者(对于证据)或依赖方(对于认证结果)身上。例如,当证明者没有可信的时钟或时间同步受到损害时,这种方法可能是合适的。在这种方法中,评估实体发送一个不可预测的随机数,然后随机数被签名并与证据或认证结果中的声明一起包含。在检查发送和接收的随机数相同后,评估实体知道声明是在随机数生成后签名的。这允许将"粗略"的时期与证据或认证结果关联。在这种情况下,时期被称为粗略的,因为:
-
时期适用于整个声明集,而不是更细粒度的关联,以及
-
声明创建时间和声明收集时间之间的时间是无法区分的。
10.3. 使用时期标识符的隐式计时
第三种方法依赖于由某个"时期 ID 分发者"定期向证据或认证结果的发送者和接收者发送时期标识符(ID)。
时期 ID 与随机数不同,因为它们可以被多次使用,甚至可以同时被多个实体使用。时期 ID 与时间戳不同,因为它们不必传达关于时间点的信息,即它们不一定是单调递增的整数。
与随机数方法一样,这允许在不需要可信时钟或时间同步的情况下关联"粗略"的时期,以便生成或评估证据或认证结果的新鲜度。只有时期 ID 分发者需要访问时钟,以便它可以定期发送新的时期 ID。
最新的时期 ID 包含在生成的证据或认证结果中,评估实体可以将接收到的证据或认证结果中的时期 ID 与从时期 ID 分发者接收到的最新时期 ID 进行比较,以确定它是否在当前时期内。实际的解决方案还需要考虑转换到新时期时的竞态条件,例如通过使用由时期 ID 分发者签名的计数器作为时期 ID,通过在消息和/或检查中包含当前和先前的时期 ID,通过在时期 ID 不匹配的情况下要求重试,或者通过缓冲可能与接收者尚未获得的时期 ID 相关联的传入消息。
更一般地,为了防止评估实体产生假阴性(例如,即使证据不是陈旧的也被丢弃),评估实体应保持由最近接收的时期 ID 组成的"时期窗口"。这种时期窗口的深度与第一个接收时期 ID 和最后一个接收时期 ID 之间的最大网络传播延迟成正比,与时期持续时间成反比。评估实体应将接收到的证据或认证结果中携带的时期 ID 与其时期窗口中的时期 ID 进行比较,以找到合适的匹配。
虽然随机数方法通常需要评估实体为生成的每个随机数保持状态,但时期 ID 方法将保持的状态最小化为独立于预期从中接收证据或认证结果的证明者或验证者的数量,只要所有这些都使用相同的时期 ID 分发者。
10.4. 讨论
隐式和显式计时可以组合成混合机制。例如,如果证明环境中存在时钟并被认为是可信的(防篡改的)但未同步,则可以使用基于随机数的交换来确定相关对等方之间的(相对)时间偏移,然后进行任意数量的基于时间戳的交换。
重要的是要注意,声明中的实际值可能在声明被签名之前很久就已经生成。如果是这样,签名者有责任确保这些值在签名时仍然是新鲜的。例如,在启动时生成的值可能已保存到安全存储中,直到与远程验证者建立网络连接并获得随机数。
附录 A 中提供了更详细的讨论和示例。
有关时期 ID 安全性的讨论,请参见第 12.3 节。