CCC数字钥匙3.0标准解读(9)

---

7 标准交互

标准交互协议旨在提供以下属性：
 相互认证
 前向安全性
 追踪朔源
 完整性和保密性
车辆和设备之间的安全通道是通过在车辆和设备侧生成临时密钥对来启动的。使用密钥协商方法，双方派生共享密钥，用于生成共享对称密钥，共享密钥使用Diffie-Hellman和密钥派生函数生成。
在车辆侧生成的临时公钥使用车辆的私钥vehicle_SK进行签名。这导致了设备对车辆的认证。从设备的角度来看，这保证了MITM攻击不会泄露任何隐私敏感数据。该原理还允许设备将数据传输到车辆，而不存在任何被被动或主动窃听者泄露的可能性。
最后，设备使用建立的安全通道来加密设备的公钥标识符以及签名，签名是基于车辆的相关数据和一些额外的应用程序特殊数据计算产生的。车辆对设备签名的验证允许车辆对设备进行身份验证。
Figure 7-1：Standard Transaction Flow

8 快速交互

快速交互协议旨在提供以下属性：
 设备身份验证或相互身份验证
 完整性和保密性
 追踪朔源
设备基于之前在标准交互中共享密钥生成一个密码，这允许车辆对设备进行身份验证。可选地，通过先前在标准交互期间的共享密钥和临时密钥导出会话密钥来建立车辆和设备之间的安全通道。车辆通过建立安全通道实现了设备认证车辆。当端点创建期间定义的端点配置允许快速交互时，共享密钥应始终在标准交互中重新生成。参见第15.3.2.4节（见表15-13）。
Figure 8-1：Fast Transaction Flow

9 用户认证

设备应提供根据其用户身份验证（UA）策略强制执行用户身份验证的功能。设备应至少提供UA策略之一（[A]、[AL]、[E]、[T]）（见表9-2）。用户身份验证策略由设备上的用户设置。UA仅由设备强制执行。执行UA的条件由所选择的UA策略基于交互类型来确定（见表9-2）。
交互类型在AUTH0命令的P2参数中设置为特定的transaction_code值。
表9-1中规定了交互类型分配。
可以为每个数字钥匙单独启用或禁用用户身份验证。UA策略存储在需要用户身份验证的交互类型的列表中。对于每个新的数字钥匙，默认情况下，用户身份验证应设置为Off[O]（见表9-2）。
Table 9-1：AUTH0 Command Transaction Type Coding

车辆会话从在前一车辆会话结束或车辆锁定结束后或在车辆未使用的适当超时之后第一次使用数字钥匙开始。
表9-2显示了对交换类型的策略分配以及导致相关联的用户体验。
Table 9-2：User Authentication Policies

 X: 在设备上执行UA
 -: 不需要UA
车主不应该能够限制共享钥匙的UA设置选项。
注意：当为数字钥匙设置了用户身份验证时，该钥匙可能无法在电池电量不足模式下使用。

9.1 显式用户身份验证策略

为了提高安全性，在触发操作之前需要显式UA可能是有益的。显式UA应要求在实施显式UA之前记录RKE行动的意图。只有在显式UA已成功执行的情况下，才能执行相关的RKE操作。显式UA和操作之间的时间不得超过1分钟，除非设备被设置为仅数字钥匙功能可以被触发的状态。在离开仅数字密钥功能触发的状态后，应在执行另一项操作之前执行显式UA。

9.2 隐式用户身份验证策略

为了改善用户体验，设备允许单个成功的UA事件在短时间内（宽限期）授权几个数字密钥动作可能是有益的。这可以适用到用于设备解锁的UA。如果用户设备实现这样的宽限期，则该宽限期不应超过5分钟。如果设备支持，其他成功的UA事件应该会导致该宽限期计时器启动/重新启动。当UA失效时，例如当设备被锁定时，宽限期应立即到期。该隐式UA不应用于关键操作，例如端点授权、钥匙共享，或者当设备的UA策略明确禁止将隐式UA用于交互的类型或远程功能执行时。
用户应该能够启用或禁用此隐式UA的使用。用户还可以配置0分钟（禁用）和上面定义的最长时间之间的宽限期长度。

10 检查存在交互

检查存在交互协议旨在提供以下属性：
 车辆认证
 设备标识
 完整性和保密性
 追踪朔源
该机制类似于第7节中描述的标准交互机制，只是设备签名不发送到车辆，并且用户身份验证被禁用。目的是允许在不需要用户身份验证的情况下验证车辆附近的设备存在，同时防止跟踪。
Figure 10-1：Check Presence Transaction