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

---

11 数字钥匙共享[WCC1/WCC2]

11.1 编码

根据第11.2节中描述的通信信道上交换的所有消息都符合ASN.1 DER编码规则，并使用隐式标记规则，除非另有规定，并且证书符合X.509格式，如文件[3]。
TLV字段应按照本规范中的说明进行组织。除非另有规定，否则不同的字段组织将被视为无效。嵌套级别由标记列中标记值的缩进表示。

11.2 共享原理

11.2.1 定义

11.2.1.1 共享密码

如果得到车辆制造商的支持，共享密码会提供给车主，车主会通过专用渠道提供给好友。然后，好友将其输入到车辆UI中以激活钥匙。车辆制造商验证是否输入了正确的共享密码。本规范把第11.2.1.3节和第17.8.19节中定义的共享密码作为一个激活选项。因此，本规范[32]先前版本中定义的共享密码被认为是过时的。车辆制造商决定是否实施此选项。

11.2.1.2 设备PIN

如果车辆制造商不需要共享密码，则可以在共享工作流程中由车主设备设置。车主通过专用通道向好友提供设备PIN，该通道与用于传送共享邀请的通道不同。然后，好友将其输入到他们的设备UI中，以继续共享工作流程。设备制造商验证好友是否输入了正确的设备PIN。设备制造商决定是否实施此选项。

11.2.1.3 激活选项

激活选项可由车辆制造商定义，以激活车辆中的好友钥匙。然后，好友可以选择任何支持的激活选项，可以包含共享密码作为一个选项。车辆OEM决定是否实施此选项。

11.2.1.4 批准共享方法

这些是由车辆制造商批准的设备制造商完全控制的设备制造商专有共享通道。可以评估和维护安全级别。当车辆制造商批准为安全时，共享机制不需要为使用该方法共享的钥匙使用激活选项。车辆制造商应能够为批准的共享方法定义激活方法策略。

11.2.1.5 共享方法组标识符

由制造商定义的标识符，用于实现专有共享方法。车辆制造商使用此标识符来定义参考共享方法的激活选项策略。

11.2.2 原理

数字密钥系统基于使用非对称密码学的签名验证。只有是在使用与车辆中注册的公钥相对应的私钥签署的请求时，车辆才会解锁车门或启动发动机。
如第6节所述，在车主设备和车辆配对后，车主便拥有私钥，其对应的公钥存储在车辆中。
为了允许好友访问车辆，车主使用他/她的私钥对好友的公钥进行签名。车主在好友的公钥上签名后，车辆将接受好友作为新的车辆用户，并存储好友的公钥。
数字钥匙共享包括车主向好友设备发送邀请URL，以及钥匙创建、钥匙签名和数据导入请求的状态交互活动。当使用安全共享通道（如设备制造商控制的专有消息传递通道）时，邀请和状态共享消息都可以通过该通道发送。不需要对目标设备进行额外的其他验证（如激活选项和设备PIN）。这些安全共享方法在本规范中被命名为批准共享方法，这意味着它们由车辆制造商批准使用，无需额外的激活选项。共享方法审批流程不在本规范的范围内。批准的共享方法列表可以在车辆制造商和设备制造商之间预先商定，可以使用钥匙跟踪和事件通知发送。
不同设备品牌的设备之间的数字钥匙共享（称为跨平台共享）由如下组成：

1. 通过车主经常与朋友使用的消息通道发送邀请。这提供了一个很好的保险，即邀请是被预定的人收到的。[38]定义了交换状态共享消息的通道。
   A. 如果车辆制造商要求，应使用一个或多个车辆制造商定义的激活选项，如共享密码和更多选项（例如，在首次使用好友钥匙时存在遥控钥匙）。车辆制造商在发送给车主设备的trackKey响应或eventNotification中提供这些信息。第17.8.19节列出了可用的激活选项。给定车辆的激活选项列表在车主和好友设备进行钥匙跟踪通信期间传输。此外，车主设备在钥匙共享期间向好友设备提供激活选项的列表。激活选项应显示在车主和好友设备UI中。好友可以从激活选项列表中选择并使用一个选项。
    如果共享密码是支持的激活选项之一，则车主设备应在设备UI中提供密码输入以及必要的使用指南。如果车辆软件更新添加或更改激活选项，则可以使用事件通知更新车主设备。
2. 如果车辆制造商决定不支持额外的激活选项，车主设备应向希望在其共享中添加额外验证的车主建议使用设备PIN（以及未来可能的其他“无声”验证方法）。设备制造商专有共享方法的策略由车主设备制造商定义。
   在某些情况下（例如，当车辆制造商修改了批准共享方法列表时），车主设备应使用批准共享方式发送共享方式证明，以确认车主设备使用了更新的批准的共享方法列表。
   车辆制造商更改共享策略的条件（即，从列表中添加或删除批准的共享方法）不在本规范的范围内。
   车辆制造商应使用事件通知“SHARING_policy_CHANGED”或其他设备制造商专有方法通知设备制造商激活策略的更改。

11.3 通信通道

实现跨平台共享的设备和车辆所使用的设备与代理服务器之间的标准化通信通道应使用[38]中定义的状态工作流方法。
参考的共享通道具有以下属性：
 开放标准，适用于所有符合数字密钥条件的设备和服务器
 共享邀请可以通过任何消息或聊天频道发送
 设备直接连接到代理服务器
此外，设备只能使用共享邀请中的加密密钥发送加密的共享数据。
车主设备和来自同一制造商的好友设备之间的通信通道是特定实施的，不在本规范的范围内，但如果打算在没有车辆制造商定义的其他激活选项的情况下激活钥匙，则应在表11-10中列为经批准的共享方法。图11-1显示了车主设备和好友设备之间的详细钥匙共享流程。该流程遵循[38]中定义的“状态工作流”。
注意：在图11-1中，全箭头表示同步请求，虚线箭头表示对同步请求的响应，开放箭头表示异步消息。
Figure 11-1: Detail of Key Sharing Flow Between Owner and Friend Device After Channel is Established

图11-1没有显示所有步骤或参数，例如完整的有效数据编码或设备制造商服务器。其目的是在原则上澄清流程并指出相关要素。
车主和好友设备之间的交互通过状态工作流程方法描述，该方法使用[38]中定义的以下HTTP访问方法。在设备上运行的应用程序可以调用代理服务器上的以下API（请参见第11.3.4.1节至第11.3.4.6节）：
 CreateMailbox
 UpdateMailbox
 DeleteMailbox
 ReadDisplayInformationFromMailbox
 ReadSecureContentFromMailbox
 Relinquish Mailbox
如本节所述，安全元件不参与生成用于共享通道的密钥数据。
第11.8节介绍了钥匙共享流程和数据。

11.3.1 通知

推送通知功能应由代理服务器实现。
[38]中所述的通知令牌应由每个设备制造商使用。
如果未使用通知令牌，则设备应针对代理服务器数据执行轮询策略。即使使用了推送通知，设备也可能实现（备份）轮询策略。
轮询策略应遵循以下建议：
 发送邀请后，车主设备应每10秒轮询一次签名请求（Signing Request）（或根据表11-3接收的其他消息），持续时间为3分钟，此后应每30秒轮询一次达10分钟，此后每3分钟轮询一次达1小时，此后每小时轮询一次，直到邮箱过期或删除。
 在接受邀请并将签名请求(signing request)上传到邮箱后，好友设备应在1分钟的持续时间内每5秒轮询一次导入请求(Import Request)（或根据表11-3接收的其他消息），此后应在接下来的10分钟内每30秒轮询一个，之后应在下一小时内每3分钟轮询一个，此后每小时一次，直到邮箱过期或删除为止。

11.3.2 跨平台共享邀请

车主设备生成密钥，并使用该密钥加密CreateMailbox API的相关数据，如[38]中所述。
车主设备通过调用CreateMailbox API启动共享会话，如第11.3.4.1节所述。该调用以URL的形式返回共享邀请。然后通过任何通信渠道（如WhatsApp等）将URL发送给好友。URL格式如[38]所述。框架层应将密钥作为片段附加到URL中。
代理服务器可以由任何CCC成员来实现。所有CCC批准的代理服务器URL应在[35]中列出。批准流程在单独的文件中定义，并由CCC控制。所有车主设备只能使用经批准的代理服务器URL。好友设备只能接受包含经批准的代理服务器URL的邀请。好友设备应在CCC程序管理文件[PMD]中规定的合理时间范围内支持所有CCC批准的代理服务器URL。

11.3.3 通用API参数定义

version参数应按照[38]中的说明进行设置。
mailboxIdentifier应按照[38]中的说明使用。
如果代理服务器不是由车主设备制造商托管的，则应使用deviceAttestation来验证车组设备。在其他情况下，设备制造商可能会使用专有方法来验证设备。好友设备不需要提供deviceAttestation。
deviceClaim应由车主和好友设备提供和设置，如[38]所述。
有效数据负载按照[38]中所述进行加密。对于数字汽车钥匙，有效数据负载应包含作为带有钥匙格式和符合[38]内容的JSON结构中提供的信息。
对于数字汽车钥匙，格式标识符为digitalwallet.carkey.ccc。内容数据结构如表11-1所示。
Table 11-1：content in JSON Format

在[35]中定义。
车主设备可以添加来自同一设备制造商的好友设备能够使用的专有数据（例如，“apple”），例如，以改善用户体验。如果好友设备来自其他设备制造商，则好友设备应忽略专有数据。车主设备应可以添加多个＜Device OEM＞字段，如果需要，每个字段用于不同的设备制造商。
请注意，所有平台的好友设备都可以“看到”所有字段。
genericSharingData定义为以下JSON结构：
Table 11-2：JSON formatted genericSharingData data structure

sharingData包含表11-3中定义的密钥共享数据元素，具体取决于共享状态。
sharingDataType 在Table 11-3中定义。
sharingId由车主设备在第一条消息中定义，以独立于mailboxIdentifier明确地标识共享会话。每个车主设备和每个会话的值应是唯一的。车主和好友设备应在同一共享会话的所有消息中使用相同的值。如果车主发出多个邀请（例如，用于好友手机和好友手表），则SharingId的值对于每个好友设备应是唯一的。
friendKeyId应由好友设备在key signing request中发送（格式如第2.4节中定义的“digital key identifier”）。
authType指示需要以下哪个其他验证。如果未使用任何方法，则该字段应不存在。此处列出了其他验证方法：
 如果以下两种情况均成立，指示使用VehicleActivation：
 在trackKey响应（见第17.8.5节）或eventNotification（见第178.9节）中，通过uiBundle向车主设备提供了至少一个激活选项
 使用了未经批准的共享方法
 只有在以下两个条件都成立的情况下，指示使用DevicePIN：
 无VehicleActivation要求
 车主选择使用device PIN进行密钥共享
将来可以添加其他好友验证选项，这些选项不在当前激活选项(activationOptions)列表中。
activationOptions由车辆制造商在trackKey响应或事件通知中提供。这些选项是特定于车辆并由车辆实现的，并且可以包括共享密码和/或通过共享密码激活钥匙的替代方式。车主和好友设备应在UI中进行提示。如果该字段不存在，则车辆制造商不需要进行额外的验证。在车辆制造商没有提供激活选项的情况下，车主或设备制造商仍然可以要求其他不涉及车辆制造商的验证方法，如authType中所述。
pinLength的值应介于4和8之间（包括4和8），由车主设备选择。车主设备应根据[38]中的建议，选择PIN长度和允许在好友设备UI中尝试输入设备PIN的次数的适当组合。
Table 11-3：sharingDataType enum Definition

共享类型sharingOwnerCancel和sharingFriendCancel应用于一些错误条件场景，替代共享流程的下一条消息，应包含一条错误消息（见表11-9）和适当的错误代码。
共享类型sharingPinReEntryRequest向好友指示输入的设备PIN错误。在TLV格式的字段sharingData中包含剩余的尝试次数。共享类型sharingPinReEntryValue包含具有新好友设备PIN的密钥签名请求。
CreateMailbox Message中提供的信息清单如下例子所示。
Listing 11-1：Sample Provisioning Information in JSON Format

11.3.4 API 参数用法

以下章节描述了[38]中与数字密钥跨平台共享相关的API参数的使用。

11.3.4.1 CreateMailbox API 参数

有效数据包含format和context字段（参见[38]）。context包含表11-1中描述的genericSharingData和可选的设备制造商特定共享数据。sharingDataType枚举（表11-3）应设置为1（sharingKeyCreationRequest），以指示sharingData的内容是表11-5中定义的钥匙创建请求。
displayInformation由车主设备决定。格式如[38]所述。
notificationToken由所有者设备在创建邮箱时提供，在邮箱的生存期内有效。当代理服务器从好友设备接收到钥匙签名请求(Key Signing Request)、共享拒绝(sharing rejection)或随后重试设备PIN（在钥匙签名请求的上下文中）时，车主设备应该使用它来接收来自代理服务器的通知。如果未使用通知，则车主设备应执行第11.3.1节“通知”小节中所述的定期轮询。
mailboxConfiguration应设置如下：
 accessRights = “RWD”
 expiration =
urlLink的格式如[37]所述。
所有CCC代理服务器应将isPushNotificationSupported设置为“true”，即服务器应支持它们。设备可能会选择不使用它们，尽管强烈建议使用它们。

11.3.4.2 UpdateMailbox API参数

有效数据包含format和content。content包含genericSharingData和设备制造商特定的共享数据，如Table 11-1所示。
来自于好友设备的sharingData包含如下信息：
 如Table 11-6所示的钥匙署名请求（Key Signing Request），或
 一个sharingFriendCancel错误信息
来自于车主设备的sharingData包含如下信息之一：
 如Table 11-6中的Import Request，或
 一个sharingOwnerCancel错误信息，或
 Device PIN输入请求信息
当代理服务器从车主接收到数据时，应由要被通知的好友设备提供notificationToken。参数由好友设备定义。如果未使用通知，则好友设备应根据第11.3.1节“通知”小节执行定期轮询。

11.3.4.3 DeleteMailbox API参数

好友设备应在成功接收到Import Request后删除邮箱。
如果车主收到好友的共享取消（例如好友拒绝邀请），则车主设备应删除邮箱。
如果好友收到车主的共享取消（例如车主没有签署好友钥匙），则好友设备应删除邮箱。
如果车主希望在钥匙签名后取消共享，除了删除邮箱外，还应使用远程终止请求(Remote Termination Request)，如图13-4[REV_140]所示。如果好友钥匙尚未注册，车辆制造商应将好友钥匙ID添加到拒绝列表中并拒绝钥匙跟踪（使用子状态代码50112）。

11.3.4.4 ReadDisplayInformationFromMailbox API参数

如果需要，在创建邮箱期间发布的displayInformation可以再次读取。

11.3.4.5 ReadSecureContentFromMailbox API参数

有效数据包含根据各个部分中的描述在创建或更新邮箱期间上载的有效数据。
在创建邮箱期间发布的displayInformation将被读取用于在好友设备上显示钥匙最终的显示位置的占位符。
邮箱的expiration表示邮箱的最长生存期（如果以前未删除）。

11.3.4.6 RelinquishMailbox API参数

可以调用此API，以允许接收共享邀请但无法处理数字钥匙的设备（例如平板电脑）释放邮箱链接，并让另一个设备连接到[38]中描述的邮箱。这允许另一个收件人获得邮箱，并使用适当的设备执行共享流程。

11.3.5 安全性注意事项

[38]中的安全性注意事项是通用的。如何在数字钥匙的中应用它们的一些注意事项：
 槽标识符确保钥匙创建请求(key creation request)可以导致基于该请求仅创建和接受一个钥匙。
 如果未使用批准的共享方法，则共享应受到第其他方法的保护，如果车辆支持，该方法可以是第11.2.1.3节及更高版本中描述的车辆制造商定义的方法（即激活选项），也可以是第11.3.6节中描述的设备制造商定义的其他方法（例如设备PIN）。
 共享应要求显式用户身份验证（如第9.1节RKE所述）。显式用户身份验证是用户意图和用户身份验证的结合。

11.3.6 Device PIN

11.3.6.1 概念

所有设备都应支持在车主设备上生成并在好友设备上输入的Device PIN。如果没有使用其他车辆制造商定义的激活选项，或者共享密码不是激活选项的一部分，则车主可以在共享工作流程中使用Device PIN作为激活选项。设备UI应指导用户通过另外的通道传输Device PIN，并防止用户无意中再次使用用于传达共享邀请的同一信道。然后，好友在好友设备UI中键入PIN以继续共享工作流程。车主设备然后验证是否在好友设备UI中输入了正确的PIN。
车主设备策略确定共享方法是否需要Device PIN。车主设备策略由车主设备制造商确定，这不是本标准范围之内。为确保良好的用户体验，建议不要同时激活需要用户界面交互的多个激活选项。例如，共享密码（由车辆制造商控制）和Device PIN（由设备制造商控制）请参阅标题为“原则”的第11.2节，了解车辆制造商定义的激活选项和设备PIN策略。

11.3.6.2 基本流程

车主设备生成相关的Device PIN（O_PIN）。它将Device PIN输入尝试次数设置为设备制造商定义的值，参考第11.3.3节中所述的pinLength。
车主然后通过其他通道将O_PIN发送给好友。该步骤应以设备UI为指导，以确保在符合11.3.6.1中的限制的情况下传输Device PIN。车主设备将尝试次数减少一。
车主设备通过钥匙创建请求(key creation request)中Tag 9F17h发送初始尝试次数。该Tag的存在表示车主已请求将Device PIN输入到好友设备。
Table 11-4：Key Configuration

Table 11-5：Key Creation Request

如果存在Tag D8h，则应使用共享密码，并且不应存在Tag 9F17h和9F18h。如果Tag D8h不存在，则如果需要Device PIN，则Tag 9F17h和9F18h应以数字形式向好友设备指示Device PIN长度。
如果Tag 7F60h不存在，则默认好友共享配置为：
 DAh: 00h
 DBh: present
 DCh: not present
 D8h: not present

Figure 11-2：Device PIN Flow

为了获得更集中的视图，Figure 11-2没有显示设备制造商服务器。
好友从其他通道获取O_PIN值或通过语音电话获得该值。
该值现在命名为F_PIN。好友将F_ PIN输入到好友设备UI中，好友设备将F_PIN加入钥匙署名请求(key signing request)中发送给车主设备。
Table 11-6：Key Signing Request

车主设备将接收到的F_PIN与O_PIN值进行比较。如果两个值相等，则车主设备对好友钥匙进行签名并发送导入请求(import request)。
如果Device PIN值不同，则车主设备向好友发送sharingPinReEntryRequest消息（如表11-7所示）。sharingData结构如表11-2所示。
Table 11-7：Device PIN Entry Request

好友设备允许好友再次输入F_PIN，并通过向车主发送sharingPinReEntryValue消息（如表11-6所示）将输入发送回，内容与表11-6中的钥匙签名请求相同，但sharingDataType表示这是一次重复的Device PIN输入尝试。
车主再次将F_PIN与O_PIN进行比较，如果相等则签名；如果不同，则允许对好友设备进行新的尝试，直到提供了正确的F_PIN或者剩余尝试次数为0。
如果剩余尝试次数为0，则车主发送取消消息（Table 11-3，sharingOwnerCancel），指示在定义的尝试次数后没有接收到有效的Device PIN。
如果好友设备在签名请求(key signing request)中没有发送Tag 5F3Fh（F_PIN），则好友设备不支持Device PIN功能。这种情况下的车主设备策略由设备制造商定义。选项可以是拒绝和该设备共享，或者建议车主在没有Device PIN的情况下共享，提供一些安全提示。