CN115966038A - 一种数字钥匙开通方法、设备及系统 - Google Patents

Abstract

本申请提供了一种数字钥匙开通方法、设备及系统。该系统中包括第一设备、第二设备和服务器，在第一设备、第二设备和服务器之间已预先配置第一业务协议，该方法可以实现在第一业务协议的数字钥匙系统下，基于第一设备、第二设备和服务器之间的信任关系，通过服务器远程下发第二业务协议下数字钥匙开通所需的数据，利用第一业务协议下定义的机制完成第一设备和第二设备间在第二业务协议下的数字钥匙的开通，实现了在第一业务协议下的数字钥匙系统下增加对第二业务协议下的数字钥匙系统的支持，从而使得在可以不实现第二业务协议下的配对协议的情况下实现第二业务协议下数字钥匙开通所需的数据交互，减少了开发工作量和PKI体系成本，提升了用户体验。

Description

一种数字钥匙开通方法、设备及系统

技术领域

本申请涉及计算机技术领域，尤其涉及一种数字钥匙开通方法、设备及系统。

背景技术

随着车辆网联化的加速普及，数字车钥匙(或“数字钥匙”)产品应运而生，通过终端(如手机、可穿戴设备等)实现车辆解闭锁、启动发动机等功能，并利用智能网联车辆的无线通信模块实现数字车钥匙生命周期远程管理以及钥匙的分享等功能。目前，数字钥匙解决方案采用的标准一般是车联联盟(car connectivity consortium，CCC)标准和智慧车联产业生态联盟(intelligent car connectivity industry ecosystem alliance，ICCE)标准。但由于CCC标准和ICCE标准的设计思路不同，这使得CCC标准下的数字钥匙系统和ICCE标准下的数字钥匙系统难以兼容，进而导致在车辆中已配置了其中一个标准的数字钥匙系统下，需要额外开发另一个标准下的数字钥匙系统才能做到对两套数字钥匙系统的支持。

发明内容

本申请提供了一种数字钥匙开通方法、设备、系统、计算机存储可读存储介质及计算机程序产品，能够实现在已经开发了一种业务协议下的数字钥匙系统中，利用该数字钥匙系统的已有的功能来激活另一种业务协议下的数字钥匙系统，减少了开发工作量和PKI体系成本，提升了用户体验。

第一方面，本申请提供了一种数字钥匙开通方法，应用于第一设备，其中，第一设备、第二设备和服务器之间已预先配置第一业务协议，第一设备在第一业务协议下可开通第一数字钥匙，方法包括：向服务器发送目标请求，目标请求用于请求申请开通第二业务协议下的第二数字钥匙；利用第一业务协议定义的第一通信机制获取服务器发送的目标数据，目标数据用于构建第二数字钥匙的第一数据结构；响应于获取到的目标数据，生成第二数字钥匙的公钥和私钥，并至少基于目标数据构建第二数字钥匙的第一数据结构，以及向第一数据结构中至少写入目标数据；利用第一业务协议定义的第二通信机制向第二设备发送第一消息，第一消息中包括第二数字钥匙的公钥，第一消息用于指示第二设备存储第二数字钥匙的公钥。

这样，在第一设备、第二设备和服务器之间已预先配置第一业务协议时，基于第一设备、第二设备和服务器之间的信任关系，通过服务器远程下发第二业务协议下数字钥匙开通所需的数据，利用第一业务协议下定义的机制完成第一设备和第二设备间在第二业务协议下的数字钥匙的开通，实现了在已经开发了一种业务协议下的数字钥匙系统中，利用该数字钥匙系统的已有的功能来激活另一种业务协议下的数字钥匙系统，减少了开发工作量和PKI体系成本，提升了用户体验。

在一种可能的实现方式中，向第一数据结构中至少写入目标数据中的部分数据之前，方法还包括：利用第一业务协议定义的第一通信机制向服务器发送目标备案请求，目标备案请求用于请求对第二数字钥匙的公钥进行备案；获取服务器发送的目标备案证明，目标备案证明用于证明服务器已完成对第二数字钥匙的公钥的备案。这样，使得服务器可以对第二数字钥匙的公钥进行备案。

在一种可能的实现方式中，第一消息中还包括目标备案证明。这样，使得第二设备在获取到第一消息后对该目标备案证明进行校验，以确保第一消息中包含的第二数字钥匙的公钥来自于合法的设备，进而提升数字钥匙开通的安全性。

在一种可能的实现方式中，目标数据包括以下一项或多项：第二设备的标识，第二设备的公钥，箱位标识，授权公钥组，钥匙能力数据，私有邮箱大小，或，机密邮箱大小。

在一种可能的实现方式中，第一数据结构包括以下一项或多项：第二设备标识，第一设备内部对第二数字钥匙定义的标识，数字钥匙标识，箱位标识，实例CA标识，钥匙能力数据，第二数字钥匙的公钥，第二设备的公钥，授权公钥组，私有邮箱，或，机密邮箱。

在一种可能的实现方式中，第一设备内部对第二数字钥匙定义的标识，数字钥匙标识，箱位标识，实例CA标识和第二数字钥匙的公钥均由第一设备提供。

在一种可能的实现方式中，第二设备标识，箱位标识，钥匙能力数据，第二设备的公钥和授权公钥组均由目标数据得到，私有邮箱和机密邮箱由第一设备基于目标数据创建。

在一种可能的实现方式中，第一设备和第二设备中均配置有与第一数字钥匙匹配的数字钥匙系统，和与第二数字钥匙匹配的数字钥匙系统。

在一种可能的实现方式中，第一业务协议为ICCE标准协议，第二业务协议为CCC标准协议。

在一种可能的实现方式中，第一通信机制为基于设备间的密钥加密/解密数据以提供安全保障的通信机制；第二通信机制为基于第一数字钥匙的密钥和鉴权协议以提供安全保障的通信机制。

第二方面，本申请提供了一种数字钥匙开通方法，应用于服务器，其中，服务器、第一设备和第二设备之间已预先配置第一业务协议，第一设备在第一业务协议下可开通第一数字钥匙，方法包括：获取第一设备发送的目标请求，目标请求用于请求申请开通第二业务协议下的第二数字钥匙；响应于目标请求，获取目标数据，并利用第一业务协议定义的第一通信机制向第一设备发送目标数据，目标数据用于构建第二数字钥匙的第一数据结构。

在一种可能的实现方式中，方法还包括：利用第一业务协议定义的第一通信机制获取第一设备发送目标备案请求，目标备案请求用于请求对第二数字钥匙的公钥进行备案；响应于目标备案请求，对第二数字钥匙的公钥进行备案，生成目标备案证明，目标备案证明用于证明服务器已完成对第二数字钥匙的公钥的备案；利用第一业务协议定义的第一通信机制向第一设备发送目标备案证明。

在一种可能的实现方式中，目标数据包括以下一项或多项：第二设备的标识，第二设备的公钥，箱位标识，授权公钥组，钥匙能力数据，私有邮箱大小，或，机密邮箱大小。

在一种可能的实现方式中，第一数据结构包括以下一项或多项：第二设备标识，第一设备内部对第二数字钥匙定义的标识，数字钥匙标识，箱位标识，实例CA标识，钥匙能力数据，第二数字钥匙的公钥，第二设备的公钥，授权公钥组，私有邮箱，或，机密邮箱。

在一种可能的实现方式中，第一设备和第二设备中均配置有与第一数字钥匙匹配的数字钥匙系统，和与第二数字钥匙匹配的数字钥匙系统。在一种可能的实现方式中，第一业务协议为ICCE标准协议，第二业务协议为CCC标准协议。

在一种可能的实现方式中，第一通信机制为基于设备间的密钥加密/解密数据以提供安全保障的通信机制。

第三方面，本申请提供了一种数字钥匙开通系统，包括第一设备、第二设备和服务器，第一设备、第二设备和服务器之间已预先配置第一业务协议，第一设备在第一业务协议下可开通第一数字钥匙，其中，第一设备用于执行第一方面中的方法，服务器用于执行第二方面中的方法，第二设备用于响应于第一设备发送的第一消息，存储第二数字钥匙的公钥。

第四方面，本申请提供了一种设备，其特征在于，包括：

至少一个存储器，用于存储程序；

至少一个处理器，用于执行存储器存储的程序，当存储器存储的程序被执行时，处理器用于执行如第一方面或第二方面中的方法。

第五方面，本申请提供一种计算机可读存储介质，其上存储有用于实现第一方面或第二方面中的方法的计算机程序(也可称为指令或代码)。

例如，该计算机程序被计算机执行时，使得该计算机可以执行第一方面或第二方面中的方法。

第六方面，本申请提供一种芯片，包括处理器。处理器用于读取并执行存储器中存储的计算机程序，以执行第一方面或第二方面中的方法。

可选地，芯片还包括存储器，存储器与处理器通过电路或电线连接。

第七方面，本申请提供一种计算机程序产品，计算机程序产品包括计算机程序(也可称为指令或代码)，计算机程序被计算机执行时使得计算机实现第一方面或第二方面中的方法。

可以理解的是，上述第二方面至第七方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

图1是本申请实施例提供的一种ICCE标准下的数字钥匙开通过程的示意图；

图2是本申请实施例提供的一种CCC标准下的数字钥匙配对过程的示意图；

图3是本申请实施例提供的一种符合CCC标准要求的数字钥匙结构的示意图；

图4a是本申请实施例提供的一种应用场景示意图；

图4b是本申请实施例提供的一种数字钥匙颁发的系统架构的示意图；

图5是本申请实施例提供的一种终端的结构示意图；

图6是本申请实施例提供的一种服务器的结构示意图；

图7是本申请实施例提供的一种数字钥匙配对方法的流程示意图；

图8是本申请实施例提供的另一种数字钥匙配对方法的流程示意图；

图9是本申请实施例提供的一种数字钥匙分享方法的流程示意图；

图10是本申请实施例提供的一种数字钥匙中认证数据包的示意图；

图11是本申请实施例提供的另一种数字钥匙中认证数据包的示意图；

图12是本申请实施例提供的一种数字钥匙开头方法的流程示意图；

图13是本申请实施例提供的一种芯片的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本文中术语“和/或”，是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。本文中符号“/”表示关联对象是或者的关系，例如A/B表示A或者B。

本文中的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一响应消息和第二响应消息等是用于区别不同的响应消息，而不是用于描述响应消息的特定顺序。

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或者两个以上，例如，多个处理单元是指两个或者两个以上的处理单元等；多个元件是指两个或者两个以上的元件等。

为便于理解本申请提供的技术方案，首先对ICCE标准的设计思路和CCC标准的设计思路进行介绍。

(1)ICCE标准的设计思路

ICCE标准的设计思路主要是：基于业界成熟的服务器管理下发密钥的架构，实现数字钥匙的在线下发。其中，ICCE标准下的数字钥匙系统目前采用的是对称密钥体系。

示例性的，图1示出了一种ICCE标准下的数字钥匙开通过程。如图1所示，ICCE标准下的数字钥匙配对过程包括以下步骤：

S101、终端向服务器发送数字钥匙开通请求。

具体地，车辆的所有者(以下简称“车主”)可以在终端上登录与数字钥匙相关的应用，并可以在该应用上选择申请数字钥匙。当车主选择申请数字钥匙后，终端即向服务器发送数字钥匙开通请求。其中，该数字钥匙开通请求中可以携带有用于验证车主身份的信息和该车主所拥有的车辆的身份标识。

在一个例子中，用于验证车主身份的信息可以包括车主的身份标识或终端的身份标识中的一项或多项。其中，可以根据车主的身份标识和车辆的身份标识确定车主是否具备数字钥匙业务的开通权限，例如，当车主的车型支持数字钥匙功能，并且车主签约了厂商提供的数字钥匙功能服务后，该车主即具备数字钥匙业务的开通权限。可以根据终端的身份标识确定该终端是否具备数字钥匙业务的开通资质；例如，可以预先设定具备数字钥匙业务开通资质的终端的白名单，当该终端的身份标识属于该白名单中时，则该终端具备数字钥匙业务开通资质。由此，以提升数字钥匙开通的安全性。

S102、服务器响应于数字钥匙开通请求，对车主身份、请求权限等校验，并在校验通过后，生成一把数字钥匙。其中，数字钥匙包括业务密钥及相关数据(如操作权限、有效期等)。

具体地，服务器获取到数字钥匙开通请求后，其可以对车主的身份进行校验，以及检测车主是否有权限开通相关车辆的数字钥匙功能，例如，检测车主是否签约数字钥匙功能服务等。示例性的，服务器在确定数字钥匙开通请求中携带的车主和车辆的信息与存储的车主和该车主所拥有的车辆的信息一致时，则校验车主身份通过。之后，服务器在检测出车主具备数字钥匙开通权限后，可以为该车主的设备(即终端)生成一把数字钥匙，其中，数字钥匙使用的业务密钥可以但不限于是对称密钥。

示例性的，在校验车主的身份时可以但不限于通过短信验证码、邮箱验证码、电子身份证、人脸识别等方式进行校验。

在一个例子中，服务器在生成数字钥匙中所包含的业务密钥时，还可以生成与该业务密钥相关的数据信息，比如：该业务密钥的使用权限(如是否允许解闭锁，激活发动机，解闭后备箱，解闭车窗等)、有效期等。

S103、服务器向终端发送其生成的数字钥匙。

具体地，服务器在生成数字钥匙后，其可以将该数字钥匙发送至终端。此外，服务器也可以将与该数字钥匙相关的数据信息发送至终端。之后，终端获取到数字钥匙后，其可以存储该数字钥匙。至此，终端即获取到数字钥匙。

S104、终端或者服务器向车辆提供数字钥匙。

具体地，终端获取到数字钥匙后，可以和车辆交互，并进行认证。其中，在认证过程中可以使车辆根据预置的主密钥来派生出该终端对应的业务密钥以及该次通信所需的会话密钥。此外，服务器生成数字钥匙后，可以将该数字钥匙发送至车辆，这样车辆即可以获取到与终端匹配的数字钥匙中所包含的业务密钥。此外，终端或者服务器也可以将与该数字钥匙中所包含的业务密钥相关的数据信息发送至车辆。

至此即完成车辆与终端之间数字钥匙的开通过程。之后，车主使用该终端即可以对该车辆进行控制。

在一个例子中，当车辆是通过与终端交互获取到与终端匹配的业务密钥时，图1中所示的流程中，在执行S103完毕后，即可以理解为已完成数字钥匙的下发；之后，车辆与终端可以直接进行交互，以获取到与终端匹配的数字钥匙中所包含的业务密钥。当车辆是通过与服务器交互获取到与终端匹配的业务密钥时，图1中所示的流程中，在执行S104完毕后，即可以理解为已完成数字钥匙的下发。

(2)CCC标准的设计思路

CCC标准的设计思路主要是：基于公钥基础设施(public key infrastructure，PKI)体系和非对称密钥机制完成终端和车辆之间的离线(即：不依赖服务器)互信，即终端和车辆之间基于PKI建立互信关系，并安全交换并保存对方公钥和相关钥匙数据。

示例性的，图2示出了一种CCC标准下的数字钥匙配对过程。如图2所示，CCC标准下的数字钥匙配对过程包括以下步骤：

S201、终端与车辆建立连接。

具体地，终端和车辆之间可以通过蓝牙(bluetooth)或近场通信(near fieldcommunication，NFC)等无线通信技术建立连接。示例性的，车主可以携带实体钥匙和终端进入到车辆中，然后再控制终端与车辆建立连接并发起配对。

S202、车辆向终端发送车辆的证书链和生成数字钥匙所需的密钥创建数据。

具体地，在车辆与终端建立连接后，车辆可以向终端发送车辆的证书链和生成数字钥匙所需的密钥创建数据。

示例性的，密钥创建数据可以包括车辆的标识(vehicle identifier)、车辆的公钥(vehicle public key)、箱位标识(slot identifier)、授权公钥组(authorized publickeys)、钥匙能力数据(key options)、私有邮箱大小(private mailbox size)、机密邮箱大小(confidential mailbox size)、协议版本号(protocol version)、车辆的公钥证书中的一项或多项。

在一个例子中，箱位标识可以标识一把数字钥匙及与该数字钥匙相关的机密数据。其中，车辆可以依靠箱位标识的值来唯一标识一把数字钥匙及与该数字钥匙相关的机密数据。

授权公钥组可以包括至少一个车厂认可的认证中心的公钥。

钥匙能力数据可以指示钥匙可以支持的认证类型，和/或，使用条件等。

私有邮箱可以存储车辆的一些数据。在一个例子中，车辆和手机均可以读取私有邮箱中的数据。

机密邮箱可以存储车辆的一些机密数据。在一个例子中，车辆可以读取机密邮箱中的数据。

车辆的公钥证书可以理解为车辆的公钥的数字证书。其中，数字证书实际是由电子签证机关(certificate authority，CA)签发的对公钥的认证。数字证书的内容可以包括：电子签证机关的签名、证书所有者的身份信息、公钥、私钥和有效期等等。当前，证书的格式和验证方法普遍遵循X.509国际标准。

在一个例子中，车辆的证书链中包括服务器的证书、车辆的证书和车辆内生成的车辆的公钥证书。

S203、终端对密钥创建数据进行校验，以及在校验通过时，生成数字钥匙的公私钥对和符合CCC标准要求的数字钥匙结构。

具体地，终端可以基于车辆的证书链对密钥创建数据进行校验。例如：校验车辆的公钥证书是否合法等，其中，当确定车辆的公钥证书是由可信任的厂商颁发时，即可以确定校验通过。可以理解的是，车辆与车辆的厂商之间是信任关系，终端的厂商和终端之间是信任关系，那么当车辆的厂商和终端的厂商之间预先建立信任关系后，车辆和终端之间即间接建立起信任关系，这时终端在获取到车辆发送的车辆的公钥证书后，当确定该车辆的公钥证书是由车辆的厂商进行认证的后，即可以确定该数字证书是合法的，进而可确定该车辆是车辆的厂商认可的一部合法车辆。

终端在校验密钥创建数据通过后，可以生成数字钥匙的公私钥对。示例性的，可以是RSA公私钥对。

此外，终端在校验密钥创建数据通过后，也可以基于密钥创建数据生成符合CCC标准要求的数字钥匙结构。

在一个例子中，如图3所示，符合CCC标准要求的数字钥匙结构可以包括：车辆标识(vehicle identifier)、节点标识(endpoint identifier)、数字钥匙标识(digital keyidentifier)、箱位标识(slot identifier)、实例证书标识(instance CA identifier)、钥匙能力数据(key options)、终端公钥(device public key)、车辆公钥(vehicle publickey)、授权公钥组(authorized public keys)、私有邮箱(private mailbox)、机密邮箱(confidential mailbox)。

示例性的，节点标识(endpoint identifier)、数字钥匙标识(digital keyidentifier)、和终端公钥(device public key)可以由终端提供。实例证书标识(instanceCA identifier)可以由终端提供。车辆标识(vehicle identifier)、箱位标识(slotidentifier)、钥匙能力数据(key options)、车辆公钥(vehicle public key)、授权公钥组(authorized public keys)可以从车辆提供的密钥创建数据中获得。私有邮箱(privatemailbox)和机密邮箱(confidential mailbox)可以基于车辆提供的密钥创建数据中所包含的私有邮箱大小和机密邮箱大小进行创建。

示例性的，节点标识可以是终端内部对数字钥匙定义的标识。数字钥匙标识可以是终端在生成公私钥对后对生成的公钥的摘要进行计算生成的数值。

S204、终端为数字钥匙的公私钥对中的公钥生成数字钥匙的公钥证书。

具体地，终端在生成数字钥匙的公私钥对后，可以使用预置的instance CA私钥对数字钥匙的公私钥对中的公钥和其它相关信息进行签名，进而生成该数字钥匙的公钥证书。其中，终端的数字钥匙的公钥证书可以理解的为该终端上与车辆进行配对的数字钥匙的数字证书，通常符合X.509格式。

S205、终端向车辆发送至少包含数字钥匙的公钥证书的证书链。

具体地，终端在生成数字钥匙的公钥证书之后，可以向车辆发送至少包含数字钥匙的公钥证书的证书链，以便车辆可以获取到终端生成的数字钥匙的公钥。示例性的，至少包含其生成的数字钥匙的公钥的证书链中可以包括服务器的证书、终端的证书(instanceCA证书)和终端生成的数字钥匙的公钥证书。

S206、车辆对数字钥匙的公钥证书进行校验，以及在校验通过后存储公钥证书中包含的数字钥匙的公钥。

具体地，车辆可以基于终端的证书链对终端的数字钥匙的公钥证书进行校验，当校验出该终端的数字钥匙公钥证书是由合法的终端签发时，即校验通过。可以理解的是，车辆与车辆的厂商(比如：服务器)之间是信任关系，终端的厂商和终端之间是信任关系，那么当车辆的厂商和终端的厂商之间预先建立信任关系后，车辆和终端之间即间接建立起信任关系，这时车辆在获取到终端发送的数字钥匙的公钥证书后，当确定该公钥证书是由终端生成并签发后，即可以确定该公钥证书是合法的。

进一步地，在校验通过后，车辆即可以存储该公钥证书中所包含的数字钥匙的公钥，即存储终端的数字钥匙的公钥。

S207、车辆向终端发送密钥配置数据。

具体地，车辆在存储数字钥匙的公钥后，可以向终端发送密钥配置数据。

在一个例子中，密钥配置数据可以包括：用于证明车辆已认证并存储数字钥匙的公钥的证明(opaque attestation)、防盗器令牌(owner immobilizer token)、箱位标识位图(slot identifier bitmap)、箱位标识(slot identifier)、厂商私有数据结构(vehicleOEM proprietary data structure)、分享钥匙的防盗令牌和请求向服务器备案的密钥备案请求中的一项或多项。

S208、终端和/或车辆向服务器发送密钥备案请求，密钥备案请求中包括数字钥匙的公钥及证书链、车辆与终端间的配对证明。

具体地，终端在获取到车辆发送的密钥配置数据后，可以向服务器发送密钥备案请求，以向服务器进行备案。其中，密钥备案请求中可以包括终端的数字钥匙的公钥及证书链，数据保护公钥，车辆与终端间的配对证明等。其中，车辆与终端间的配对证明可以由车辆自身生成，并由车辆发送给终端，该证明可以表征两者之间的配对关系。在一个例子中，数据保护公钥可以由终端提供，该数据保护公钥可以为用于服务器下发数据时加密数据的公钥，通过该公钥对服务器向终端发送的通信数据进行加密，以提升数据安全。

此外，车辆在存储终端的数字钥匙的公钥后，也可以向服务器发送密钥备案请求，以向服务器进行备案。

S209、服务器对数字钥匙的公钥和终端与车辆的配对关系进行备案(keytracking)，生成备案证明。

具体地，服务器获取到密钥备案请求后，可以对终端的数字钥匙的公钥和终端与车辆的配对关系进行备案，例如通过存储终端的数字钥匙的公钥和终端与车辆的配对关系，同时，对终端的数字钥匙的公钥进行签名的方式生成备案证明，由此，证明已对终端和车辆的该组配对进行过备案。其中，该备案证明主要是用于证明服务器已完成备案。示例性的，备案证明中可以包括密钥追踪签名(key tracking signature)。

S210、服务器向终端和/或车辆发送备案证明。

具体地，服务器对终端的数字钥匙的公钥和终端与车辆的配对关系进行备案后，可以向终端和/或车辆发送备案证明。

在一个例子中，当终端获取到服务器发送的备案证明后，终端也可以将该备案证明通过CCC标准定义的终端和车辆的通信协议发送至车辆。

S211、车辆从终端或服务器获取到备案证明后，向终端发送分享配置数据。

具体地，车辆获取到备案证明，可以按照预设的校验规则对该备案证明进行校验，并在校验通过后，可以向终端发送分享配置数据，比如用于分享的防盗器令牌(immobilizer tokens for sharing)等。

S212、车辆激活钥匙的所有权限。

具体的，在车辆与终端完成配对后，车辆可以激活数字钥匙的所有权限。至此，即完成车辆与终端之间数字钥匙的配对过程，之后，车主使用该终端即可以对该车辆进行控制。可以理解的是，由于车辆和终端之间已完成对对方的公钥的认证和保存，因此两者之间在后续使用阶段可以建立信任关系，这样终端即可以对车辆进行控制，例如解闭锁车门和激活发动机等。

以上即是对ICCE标准和CCC标准的相关介绍。由上述的相关介绍可知，ICCE标准中的数字钥匙开通是基于服务器远程实现的，车辆基于预置的根密钥或从服务器获取的钥匙来验证终端，用户可以随时随地远程验证身份并事先获取好钥匙，再去和车辆交互，体验较好，也有助于设计各种租赁，快递进车等商用模式下的体验。CCC标准是通过车主所使用的终端与车主所使用的车辆进行配对方式得到数字钥匙；其中，在配对过程中，因为车主的终端和车辆此前未进行过通信，无法建立互相信任的关系，因此车主必须携带实体钥匙去车辆内证明车主身份和/或钥匙开通权限才能发起配对；此外，由于非对称密钥对需要安全交换，对于两个未进行过通信的设备间只有依赖PKI公钥基础设施构建的证书体系和用户触发进入配对模式来保证配对过程的安全，以保证车辆与拥有钥匙开通权限的设备正确配对。

下面对本申请提供的技术方案进行介绍。

需要说明的是，本申请提供的技术方案主要是：在车辆中已经采用了ICCE标准的数字钥匙系统时，使得该车辆可以利用ICCE标准定义的机制在实施ICCE标准的终端和车辆间完成CCC标准下的数字钥匙的开通，实现了在ICCE标准的数字钥匙系统下增加对CCC标准的数字钥匙系统的支持，从而使得在可以不实现或执行CCC配对协议的情况下实现CCC体系下数字钥匙配对所需的数据交互。

示例性的，图4a示出了一种应用场景。如图4a所示，终端100和服务器300之间可以通过网络进行通信，车辆200和服务器300之间也可以通过网络进行通信。该网络可以为有线网络(Wired network)或无线网络(wireless network)等网络连接。例如，该网络可以为局域网(local area networks，LAN)，也可以为广域网(wide area networks，WAN)(例如互联网)。终端100和车辆200之间可以通过无线通信技术进行通信。该无线通信技术可以包括：蓝牙(bluetooth)技术、近场通信NFC技术或者超宽带(ultra wide band，UWB)技术等。示例性的，服务器300可以为车辆厂商的服务器。

其中，服务器300可以为终端100和车辆200颁发ICCE标准下的数字钥匙。该服务器300也可以向终端100提供在CCC标准下生成数字钥匙所需的车辆的数据，比如：车辆的标识、车辆的公钥、车辆的公钥证书，以及钥匙配置数据，如邮箱大小(mailbox size)，钥匙能力数据(key options)等。终端100可以基于服务器300提供的数据生成CCC标准下的终端100的数字钥匙的公私钥对，并向服务器300发送密钥备案请求。在服务器300完成密钥备案后，终端100可以将其生成的数字钥匙的公钥(和/或数字钥匙的公钥证书的证书链)和服务器300发送的备案证明发送至车辆200。这样车辆200即获取到CCC标准下的数字钥匙系统中所需的数据，进而可以激活其针对终端100的数字钥匙的权限，达到与该终端100完成CCC标准下配对完成的状态。之后，终端100即可以对车辆200进行控制。

示例性的，图4b示出了一种数字钥匙颁发的系统架构。如图4b所示，在该系统架构中包括图4a中所示的终端100、车辆200和服务器300。其中，终端100中包括安全单元110，安全单元110中包括ICCE车钥匙应用(applet)111和CCC车钥匙应用112。ICCE车钥匙应用111为与ICCE标准相关的车钥匙应用，在该应用中至少可以安全接收、存储和使用ICCE标准下的数字钥匙；CCC车钥匙应用112为与CCC标准相关的车钥匙应用，在该应用中至少可以持有CCC标准下的数字钥匙。安全单元110可以对ICCE车钥匙应用(applet)111和CCC车钥匙应用112分别进行实例化。在一个例子中，ICCE车钥匙应用111可以具备用于指示车辆200进行CCC标准下数字钥匙系统的激活功能。在一个例子中，在终端100上还可以设置有用于申请数字钥匙的应用程序，通过该应用程序至少可以申请开通数字钥匙。

车辆200中包括ICCE数字钥匙系统210、密钥管理模块220和CCC数字钥匙系统230。ICCE数字钥匙系统210中包括鉴权模块211和密钥存储模块212，CCC数字钥匙系统230中包括鉴权模块231和密钥存储模块232。

ICCE数字钥匙系统210可以管理ICCE标准下的数字钥匙。在一个例子中，车辆200和终端100都已经实现了ICCE标准，并且完成了数字钥匙的下发。鉴权模块211可以检测车辆200获取到的终端100(即持有ICCE数字钥匙的车主设备，也可以理解为受信任的设备)或服务器300(即拥有对车辆的管理权的服务器)发送的与CCC标准下数字钥匙相关的数据是否是采用ICCE标准下的通讯机制和/或安全机制发送至车辆200，以及在检测到车辆200接收到的数据是采用ICCE标准下的通讯机制和/或安全机制发送至车辆200后，将接收到的数据发送至密钥管理模块220。此外，鉴权模块211还可以基于ICCE标准中定义的终端和车辆之间的密钥鉴权协议检测车辆200获取到的来自终端100的控制指令是否合法等等。在一个例子中，密钥存储模块212可以存储ICCE标准下的数字钥匙，和/或与ICCE标准下的数字钥匙相关的数据。

密钥管理模块220可以具有对CCC数字钥匙系统230的配置功能，其可以对CCC标准下的数字钥匙进行配置和初始化等。在一个例子中，在ICCE数字钥匙系统210中鉴权模块211向密钥管理模块220发送与CCC标准下数字钥匙相关的数据后，密钥管理模块220可以对其获取到的数据进行鉴权，并在确定数据来自合法、受信任且拥有钥匙开通相应权限的设备和服务器后，将该数据发送至CCC数字钥匙系统230中的密钥存储模块232中。

CCC数字钥匙系统230可以管理CCC标准下的数字钥匙。在一个例子中，鉴权模块231可以检测车辆200获取到的来自终端100的基于CCC标准的控制指令是否合法等等。在一个例子中，密钥存储模块232可以存储CCC标准下的数字钥匙，和/或与CCC标准下的数字钥匙相关的数据。

服务器300中可以但不限于包括数据处理模块310。该数据处理模块310可以具备CCC标准下的数字密钥的配置功能，其可以为终端100提供生成CCC标准下的数字钥匙所需的至少部分数据，以及对数字钥匙的公钥进行备案，并生成备案证明等。

可以理解的是，本申请中，在车辆和终端已采用ICCE标准的情况下，终端可以复用ICCE标准体系下的信任关系和安全机制，从服务器处安全获取到在CCC标准下生成数字钥匙所需的车辆的数据，从而可以生成CCC标准下的数字钥匙，并确保车辆可以基于ICCE体系的信任机制确保终端发送的CCC数字钥匙公钥等来自合法且具备钥匙开通权限的车主设备(持有ICCE体系下的车主钥匙)，由此实现了在ICCE标准的数字钥匙系统下增加对CCC标准的数字钥匙系统的支持，从而使得在可以不实现或执行CCC配对协议的情况下实现CCC体系下数字钥匙配对所需的数据交互，减少了开发工作量和PKI体系成本，提升了用户体验。

示例性的，图5示出了本申请实施例提供的一种终端100的硬件结构示意图。如图5所示，该终端100可以包括处理器110，存储器120和通信模块130。

其中，处理器110可以是通用处理器或者专用处理器。例如，处理器110可以包括中央处理器(central processing unit，CPU)和/或基带处理器。其中，基带处理器可以用于处理通信数据，CPU可以用于实现相应的控制和处理功能，执行软件程序，处理软件程序的数据。

示例性地，处理器110可以包括一个或多个处理单元。例如，处理器110可以包括应用处理器(application processor，AP)、调制解调器(modem)、图形处理器(graphicsprocessing unit，GPU)、图像信号处理器(image signal processor，ISP)、控制器、视频编解码器、数字信号处理器(digital signal processor，DSP)、基带处理器、和/或神经网络处理器(neural-network processing unit，NPU)等中的一项或多项。在一些实施例中，终端100可以包括一个或多个处理器110。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。示例性的，处理器110可以生成CCC标准下的数字钥匙的公私钥对，生成数字钥匙的公钥证书等。

存储器120可以存储有程序，程序可被处理器110运行。存储器120还可以存储有数据。处理器110可以读取存储器120中存储的数据。存储器120和处理器110可以单独设置。可选地，存储器120也可以集成在处理器110中。示例性的，存储器120中可以存储有与数字钥匙相关的数据等等。

通信模块130可以包括移动通信模块和无线通信模块中的至少一种。其中，当通信模块130包括移动通信模块时，通信模块130可以提供应用在电子设备上的包括2G/3G/4G/5G等无线通信的解决方案。比如，全球移动通讯系统(global system for mobilecommunications，GSM)、通用分组无线服务(general packet radio service，GPRS)、码分多址接入(code divisionmultiple access，CDMA)、宽带码分多址(wideband codedivision multiple access，WCDMA)，时分码分多址(time-division code divisionmultiple access，TD-SCDMA)、长期演进(long term evolution，LTE)、新空口(new radio，NR)等。

通信模块130可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(lownoise amplifier，LNA)等。通信模块130可以通过至少一根天线接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调器进行解调。通信模块130还可以对经调制解调器调制后的信号放大，经天线转为电磁波辐射出去。在一些示例中，通信模块130的至少部分功能模块可以被设置于处理器110中。在一些示例中，通信模块130的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。当通信模块130包括无线通信模块时，通信模块130可以提供应用在终端100上的包括无线局域网(wireless local areanetworks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequencymodulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。通信模块130可以是集成至少一个通信处理模块的一个或多个器件。通信模块130经由天线接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。通信模块130还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线转为电磁波辐射出去。示例性的，通信模块130可以接收服务器300发送的数据，或者向服务器300发送数据，或者向车辆200发送数据，或者接收车辆200发送的数据等等。

可以理解的是，本申请实施例示意的结构并不构成对终端100的具体限定。在本申请另一些实施例中，终端100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。在一些实施例中，车辆200的硬件结构可以具有与终端100的硬件结构相同，也可以具有比终端100更多或更少的部件，此处不做限定。

示例性地，图6示出了本申请实施例提供的一种服务器300的硬件结构示意图。如图6所示，该服务器300可以包括：处理器310，网络接口320，及存储器330。

其中，处理器310可以是通用处理器或者专用处理器。例如，处理器210可以包括中央处理器(central processing unit，CPU)和/或基带处理器。其中，基带处理器可以用于处理通信数据，CPU可以用于实现相应的控制和处理功能，执行软件程序，处理软件程序的数据。示例性的，处理器210可以获取到生成数字钥匙结构所需的车辆的数据，对终端生成的数字钥匙的公钥进行备案等等。

网络接口320可选地可以包括标准的有线接口，无线接口(如Wi-Fi，移动通信接口等)，受处理器310的控制用于收发数据，例如，从网络上接收终端100中通信模块130发送的数据，或者，向终端100发送数据，或者，向车辆200发送数据等。

存储器330可以存储有程序，程序可被处理器310运行。存储器330还可以存储有数据(比如，车辆的标识、车辆的公钥、车辆的公钥证书等等)。处理器310可以读取存储器330中存储的数据。存储器330和处理器310可以单独设置。可选地，存储器330也可以集成在处理器310中。

可以理解的是，本申请实施例示意的结构并不构成对服务器300的具体限定。在本申请另一些实施例中，服务器300可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

下面基于上文所描述的内容并结合图7，对本申请提供的技术方案进行详细说明。示例性地，图7示出了本申请实施例提供的一种数字钥匙配对方法的流程示意图。如图7所示，该方法可以包括以下步骤：

S701、终端与服务器建立连接。

具体地，终端和服务器之间可以通过网络建立连接。示例性的，车主可以在终端上登录与数字钥匙相关的应用。当车主成功登录与数字钥匙相关的应用后，终端与服务器之间即建立连接。其中，车主的登录的账号可以与车辆具有关联关系。

在一个例子中，终端与服务器建立连接后，两者之间可以建立安全数据通道，以保证数据通信过程中的安全性。示例性的，两者可以复用ICCE标准下的钥匙下发/更新流程中的安全机制、服务接口、软件开发工具包(software development kit，SDK)等进行数据交互。

S702、终端向服务器发送第一请求，第一请求用于申请开通CCC标准下的数字钥匙。

具体地，终端在获取到车主下发的数字钥匙申请指令后，可以向服务器发送用于申请开通CCC标准下的数字钥匙的第一请求。示例性的，终端可以复用ICCE标准下的钥匙下发/更新流程中的通信机制将该第一请求发送至服务器。示例性的，第一请求中可以包括用于加密数据的加密公钥，该加密公钥可以用于对终端与服务器间的通信数据进行加密。

在一个例子中，终端可以在车主申请ICCE标准下的数字钥匙时向服务器发送该第一请求，例如，当车主在终端上的ICCE车钥匙应用中申请开通数字钥匙时，终端可以发送该第一请求。此外，终端也可以在车主已申请开通完ICCE标准下的数字钥匙之后，并又申请开通CCC标准下的数字钥匙时向服务器发送该第一请求。具体可根据实际情况而定，此处不做限定。

S703、服务器响应于第一请求，获取第一数据，第一数据用于生成数字钥匙结构。

具体地，在服务器获取到第一请求后，服务器可以响应该第一请求，获取第一数据，第一数据用于生成数字钥匙结构。

在一个例子中，第一数据可以包括车辆的标识(vehicle identifier)、车辆的公钥(vehicle public key)、箱位标识(slot identifier)、授权公钥组(authorized publickeys)、钥匙能力数据(key options)、私有邮箱大小(private mailbox size)、机密邮箱大小(confidential mailbox size)中的一项或多项。

在一个例子中，第一数据可以由车辆所属的厂商预先配置在服务器中，这样服务器可以直接读取到该第一数据。

在一个例子中，服务器也可以由车辆处获取到第一数据。此时，服务器可以向车辆发送数据获取请求。车辆接收到数据获取请求后，可以将第一数据发送至服务器，这样服务器即获取到第一数据。

在一个例子中，服务器获取到第一请求后，可以对车主的身份进行校验，当校验通过后，再获取第一数据，由此以提升安全性。示例性的，服务器在确定第一请求中携带的车主和车辆的信息与其存储的车主和该车主所拥有的车辆的信息一致时，则校验通过。

可选地，服务器在对车主的身份校验通过后，还可以生成第一凭证，该第一凭证可以用于指示车辆存储终端的数字钥匙的公钥。其中，在后续终端与车辆交互时，车辆在获取到该第一凭证后才存储终端的数字钥匙的公钥，由此使车辆确认该公钥来源的可靠性，增加一层防护，提高数据安全性。

S704、服务器向终端发送第一数据。

具体地，服务器在获取到第一数据后，可以将第一数据发送至终端。示例性的，服务器在发送第一数据时可以复用ICCE标准下的钥匙下发/更新流程中的安全通信机制将该第一数据发送至终端。示例性的，第一数据可以使用第一请求中的加密公钥进行保护。

S705、终端生成数字钥匙的公私钥对，以及基于第一数据生成符合CCC标准要求的数字钥匙结构。

具体地，终端获取到第一数据后，可以生成数字钥匙的公私钥对，以及基于第一数据生成符合CCC标准要求的数字钥匙结构。

在一个例子中，如图3所示，符合CCC标准要求的数字钥匙结构可以包括：车辆标识(vehicle identifier)、节点标识(endpoint identifier)、数字钥匙标识(digital keyidentifier)、箱位标识(slot identifier)、applet实例CA标识(instance CAidentifier)、钥匙能力数据(key options)、终端上生成的数字钥匙的公钥(devicepublic key)、车辆公钥(vehicle public key)、授权公钥组(authorized public keys)、私有邮箱(private mailbox)、机密邮箱(confidential mailbox)。

示例性的，节点标识(endpoint identifier)、数字钥匙标识(digital keyidentifier)、和终端公钥(device public key)可以由终端生成。applet实例CA标识(instance CA identifier)可以由终端提供。车辆标识(vehicle identifier)、箱位标识(slot identifier)、钥匙能力数据(key options)、车辆公钥(vehicle public key)、授权公钥组(authorized public keys)可以由服务器提供。对于私有邮箱(private mailbox)和机密邮箱(confidential mailbox)，终端可以基于服务器提供的私有邮箱大小和机密邮箱大小生成。

S706、终端向数字钥匙结构中写入数据。

具体地，终端在生成数字钥匙结构后，可以在该数字钥匙结构中写入数据。

示例性的，对于私有邮箱和机密邮箱中所包含的车辆的数据，终端可以从服务器中获得。其中，对于私有邮箱和机密邮箱中所包含的车辆的数据，可以预先存储在服务器中。此外，服务器也可以通过与车辆进行通信，以获取到私有邮箱和机密邮箱中所包含的车辆的数据。

在一个例子中，终端完成在其自身的安全单元(secure element，SE)(比如图4b中所示的安全单元110)内的CCC applet的实例化，并按第一数据生成数字钥匙结构，以及生成数字钥匙的公私钥对，并将第一数据写入数字钥匙结构，即可以进入到CCC标准下终端侧配对完成的状态。

在一个例子中，终端完成在其自身的安全单元(secure element，SE)(比如图4b中所示的安全单元110)内的CCC applet的实例化，并由安全单元110解密第一数据，在CCCapplet111生成数字钥匙结构，以及生成数字钥匙的公私钥对，并将第一数据写入数字钥匙结构，即可以进入到CCC标准下终端侧配对完成的状态。

S707、终端向车辆发送至少包含数字钥匙的公钥的数据。

具体地，终端在向数字钥匙结构中写入数据后，可以向车辆发送至少包含数字钥匙的公钥的数据，比如：数字钥匙的公钥、数字钥匙的公钥证书、数字钥匙的证书链等等。

在一个例子中，在基于ICCE协议的实现中，终端在通过ICCE标准下的车钥匙应用(applet)(比如：图4b中的ICCE车钥匙应用111)与车辆交互时，当终端检测到存在CCC标准下的数字钥匙的激活数据，或者其它指示信息指示需要激活CCC标准下的数字钥匙时，终端可以在交易过程中的ICCE指令中通过特殊的指示位指示当前交互需要进行CCC协议和数字钥匙的激活，比如，通过指令的P1P2值，或是其他自定义标签来标记。

此外，终端可以生成符合CCC标准的数字钥匙(digital key，DK)证书(即数字钥匙的公钥证书)或证书链，并将其保存在ICCE协议的厂商自定义字段，如9F05Cardinfo1，或是其他厂商自定义的字段或二进制文件中。由此以将DK证书或证书链发送至车辆，进而实现向车辆发送至少包含数字钥匙的公钥的数据。

S708、车辆存储终端的数字钥匙的公钥。

具体地，车辆获取到终端发送的至少包含数字钥匙的公钥的数据后，可以存储该数字钥匙的公钥。至此，即完成在CCC标准下车辆与终端之间数字钥匙的配对，之后，终端和车辆之间即可以使用CCC标准下的数字钥匙系统进行通信。

在一个例子中，车辆与终端间可以先进行鉴权，当两者完成鉴权后，车辆即可以信任该终端，并从该终端处获取到终端发送的至少包含数字钥匙的公钥的数据，比如：数字钥匙的公钥和其他必要数据(如钥匙昵称等)等。

在一个例子中，车辆在通过其内的ICCE数字钥匙系统中的鉴权模块(比如：图4b中的鉴权模块211)使用ICCE标准下的密钥完成对终端的鉴权，并获取指令中携带的公钥和其它必要数据；之后，车辆可以进行校验数据完整性以及其它额外的验证，如验证第一凭证等，以确保这些数据来自持有数字钥匙的车主设备，并在验证通过后，车辆可以将这些数据配置给CCC数字钥匙系统，以激活CCC标准下的数字钥匙。

在一个例子中，在图7中，终端、服务器、车辆之间可以完全遵照ICCE标准执行，在进行通信时，可以基于ICCE标准定义的通信机制和安全机制进行通信。其中，安全机制可以包括业务校验、用户身份校验、信任关系校验、数据下发等机制。可以理解的是，图7中终端与服务器之间采用的是ICCE标准中定义的终端和服务器之间的通信机制、业务校验机制、用户身份校验机制和安全数据下发机制，终端与车辆之间采用的是ICCE标准中定义的终端和车辆之间的通信机制和数字钥匙及相关数据的校验等信任关系校验机制，车辆与服务器之间亦采用的是ICCE标准中定义的通信机制和安全机制。

可以理解的是，图7中，在ICCE标准的数字钥匙系统下，基于车辆、终端和服务器之间的信任关系，通过服务器远程下发CCC标准下数字钥匙配对所需的数据，利用ICCE标准定义的机制使得在实施ICCE标准的终端和车辆间完成CCC标准下的数字钥匙的开通，实现了在ICCE标准的数字钥匙系统下增加对CCC标准的数字钥匙系统的支持，从而使得在可以不实现或执行CCC配对协议的情况下实现CCC体系下数字钥匙配对所需的数据交互，减少了开发工作量和PKI体系成本，提升了用户体验。

示例性地，图8示出了本申请实施例提供的另一种数字钥匙配对方法的流程示意图。如图8所示，该方法可以包括以下步骤：

S801、终端与服务器建立连接。

具体地，终端和服务器之间可以通过网络建立连接。详见上文图7中S701中的描述，此处不再赘述。

S802、终端向服务器发送第一请求，第一请求用于申请开通CCC标准下的数字钥匙。

具体地，终端在获取到车主下发的数字钥匙申请指令后，可以向服务器发送用于申请开通CCC标准下的数字钥匙的第一请求。

S803、服务器响应于第一请求，获取第一数据，第一数据用于生成数字钥匙结构。

具体地，在服务器获取到第一请求后，服务器可以响应于该第一请求，获取第一数据，第一数据用于生成数字钥匙结构。详见上文图7中S702中的描述，此处不再赘述。

S804、服务器向终端发送第一数据。

具体地，服务器在获取到第一数据后，可以将第一数据发送至终端。

S805、终端生成数字钥匙的公私钥对，以及基于第一数据生成符合CCC标准要求的数字钥匙结构。

具体地，终端获取到第一数据后，可以生成数字钥匙的公私钥对，以及基于第一数据生成符合CCC标准要求的数字钥匙结构。详见上文图7中S705中的描述，此处不再赘述。在一个例子中，终端获取到第一数据后，可以激活CCC体系的终端侧证书链的中间证书，并生成满足CCC体系的DK证书并准备备案请求(key tracking request)。

S806、终端向服务器发送第一备案请求，第一备案请求中包括数字钥匙的公钥，第一备案请求用于请求对数字钥匙的公钥进行备案。

具体地，终端在生成数字钥匙的公私钥对和数字钥匙结构后，可以向服务器发送第一备案请求，第一备案请求中包括终端的数字钥匙的公钥，第一备案请求用于请求对终端的数字钥匙的公钥进行备案。

在一个例子中，第一备案请求可以包含终端与车辆间的配对证明，该配对证明可以是终端由ICCE体系中的信任根为其生成的数字钥匙的公钥提供担保(比如使用SCP03安全通道协议向服务器安全上传该公钥)，或是使用预置的设备身份密钥为该公钥签名，或是使用数字钥匙私钥对该公钥进行自签名。由于服务器在生成第一数据时，服务器已经获知到终端与车辆间的配对关系，所以在这里，该配对证明可以是用于确定备案请求里的数字钥匙的公钥是基于第一数据生成的，并来自下发第一数据的终端。

示例性的，终端可以通过ICCE标准下的终端与服务器之间的通信机制，向服务器发送第一备案请求，以向服务器证明第一备案请求中请求备案的公钥和/或终端与车辆间的配对证明来自终端，而非其他设备。

S807、服务器对终端的数字钥匙的公钥进行备案，生成第一备案证明。

具体地，服务器获取到第一备案请求后，可以对终端的数字钥匙的公钥进行备案，生成第一备案证明，该第一备案证明主要是用于证明服务器已对终端的数字钥匙的公钥完成备案。示例性的，服务器可以通过存储终端的数字钥匙的公钥，并通过对终端的数字钥匙的公钥或终端公钥和车辆的配对关系进行签名的方式生成第一备案证明。示例性的，第一备案证明中可以包括密钥追踪签名(key tracking signature)。

在一个例子中，当第一备案请求包含终端与车辆间的配对证明时，服务器也可以存储该配对证明，以对该配对证明进行备案。

S808、服务器向终端发送第一备案证明。

具体地，服务器对终端的数字钥匙的公钥进行备案后，可以向终端发送第一备案证明。此外，服务器也可以向终端发送一些其他必要数据，如用于分享的immo token，或者，在S804中未下发的其他数据等。

S809、终端响应于获取到的第一备案证明，向数字钥匙结构中写入数据。

具体地，终端在获取到第一备案证明后，可以响应于获取到的第一备案证明，在其生成的数字钥匙结构中写入数据。其中，终端在写入数据时，可以分阶段写入，即获取到一部分数据就写入一部分，也可以一次性写入，即获取到全部的数据后再写入。此时，终端即具有CCC标准下分享所需的所有数据，即数字钥匙结构。此时，终端则进入到配对完成的状态。

在一个例子中，终端所需写入的数据，可以由服务器一次性下发，也可以由服务器分阶段下发，具体可根据实际情况而定，此处不做限定。

示例性的，对于私有邮箱和机密邮箱中所包含的车辆的数据，终端可以从服务器中获得。其中，对于私有邮箱和机密邮箱中所包含的车辆的数据，可以预先存储在服务器中。此外，服务器也可以通过与车辆进行通信，以获取到私有邮箱和机密邮箱中所包含的车辆的数据。

S810、终端向车辆发送至少包含数字钥匙的公钥的数据和第一备案证明。

具体地，终端在向数字钥匙结构中写入数据后，可以向车辆发送至少包含数字钥匙的公钥的数据和第一备案证明。详见上文图7中S707中的描述，此处不再赘述。

S811、车辆对第一备案证明进行校验，并在校验通过后存储数字钥匙的公钥。

具体地，车辆获取到至少包含数字钥匙的公钥的数据和第一备案证明后，其可以按照预设的校验规则对该第一备案证明进行校验，当校验通过后，其即可以获知到其获取到的至少包含数字钥匙的公钥的数据来自合法的车主设备(即可信任的设备)，此时其可以存储该终端的数字钥匙的公钥。至此，即完成在CCC标准下车辆与终端之间数字钥匙的配对，之后，终端和车辆之间即可以使用CCC标准下的数字钥匙系统进行通信。详见上文图7中S708中的描述，此处不再赘述。

在一个例子中，在图8中，终端、服务器、车辆之间可以完全遵照ICCE标准执行，在进行通信时，可以基于ICCE标准定义的通信机制和安全机制进行通信。其中，安全机制可以包括业务校验、用户身份校验、信任关系校验、数据下发等机制。可以理解的是，图8中终端与服务器之间采用的是ICCE标准中定义的终端和服务器之间的通信机制、业务校验机制、用户身份校验机制和安全数据下发机制，终端与车辆之间采用的是ICCE标准中定义的终端和车辆之间的通信机制和数字钥匙及相关数据的校验等信任关系校验机制，车辆与服务器之间亦采用的是ICCE标准中定义的通信机制和安全机制。

可以理解的是，图8和图7的主要不同之处在于：图8中需要终端将生成的公钥发送到服务器进行备案，车辆通过服务器签发的备案证明来进一步再次确认该密钥来自合法的终端，由此以进一步提升安全性。

可以理解的是，图8中，在ICCE标准的数字钥匙系统下，基于车辆、终端和服务器之间的信任关系，通过服务器远程下发CCC标准下数字钥匙配对所需的数据，利用ICCE标准定义的机制使得在实施ICCE标准的终端和车辆间完成CCC标准下的数字钥匙的开通，实现了在ICCE标准的数字钥匙系统下增加对CCC标准的数字钥匙系统的支持，从而使得在可以不实现CCC配对协议的情况下实现CCC体系下数字钥匙配对所需的数据交互，减少了开发工作量和PKI体系成本，提升了用户体验。

以上即是对本申请提供的在ICCE标准的秘钥体系下进行CCC标准的数字钥匙配对过程的介绍。此外，在ICCE标准的秘钥体系下也可以进行CCC标准的数字钥匙分享。详见下文描述。

示例性的，图9示出了本申请实施例提供的一种数字钥匙分享方法的流程示意图。如图9所示，该方法可以包括以下步骤：

S901、服务器获取到车主下发的分享操作指令。

具体地，服务器可以与车主所使用的终端进行通信，这样当车主在其所使用的终端上发起分享操作后，服务器即可以获取到车主下发的分享操作指令。示例性的，该分享操作指令中可以包括待分享终端的身份标识，以及车主授予被分享终端的车辆相关操作权限，比如：数字钥匙的权限、有效期、分享口令信息等。

S902、服务器获取第一数据，第一数据用于生成数字钥匙结构。

具体地，在服务器获取到分享操作指令后，服务器可以获取第一数据，第一数据用于生成数字钥匙结构。详见上文图7中S702中的描述，此处不再赘述。

S903、服务器向待分享终端发送第一数据。

具体地，服务器在获取到第一数据后，可以将第一数据发送至待分享终端。示例性的，服务器在发送第一数据时可以复用ICCE标准下的钥匙下发/更新流程中的安全机制将该第一数据发送至待分享终端。

在一个例子中，待分享终端与服务器间可以先建立连接，之后，两者之间可以建立安全数据通道，以保证数据通信过程中的安全性。示例性的，两者可以复用ICCE标准下的钥匙下发/更新流程中的安全通信机制进行数据交互。示例性的，当两者建立连接后，在服务器获取到该终端发送的数字钥匙领取申请后，服务器可以基于其获取到的分享操作指令中包括的待分享终端的身份标识对与申请领取数字钥匙的待分享终端进行校验，当校验通过后，则向该待分享终端发送第一数据。此外，服务器也可以采用上文图1中所描述的校验车主身份的方式对待分享终端进行校验，详见上文描述，此处不再一一赘述。

在一个例子中，待分享终端与服务器间建立连接后，待分享终端可以向服务器发送用于申请开通CCC标准下数字钥匙的请求。其中，当服务器获取到待分享终端发送的请求时，服务器可以在获取第一数据，并向待分享终端发送第一数据。

S904、待分享终端生成数字钥匙的公私钥对，以及基于第一数据生成符合CCC标准要求的数字钥匙结构。

具体地，待分享终端获取到第一数据后，可以生成数字钥匙的公私钥对，以及基于第一数据生成符合CCC标准要求的数字钥匙结构。详见上文图7中S705中的描述，此处不再赘述。

S905、待分享终端向服务器发送第二备案请求，第二备案请求中包括待分享终端的数字钥匙的公钥，第二备案请求用于请求对待分享终端的数字钥匙的公钥进行备案。

具体地，待分享终端在生成数字钥匙的公私钥对和数字钥匙结构后，可以向服务器发送第二备案请求，第二备案请求中包括待分享终端的数字钥匙的公钥，第二备案请求用于请求对待分享终端的数字钥匙的公钥进行备案。

在一个例子中，第二备案请求可以包含待分享终端与车辆间的配对证明，该配对证明可以是待分享终端由ICCE体系中的信任根为其生成的数字钥匙的公钥提供担保(比如使用SCP03安全通道协议向服务器安全上传该公钥)，或是使用预置的设备身份密钥为该公钥签名，或是使用数字钥匙私钥对该公钥进行自签名。由于服务器在生成第一数据时，服务器已经获知到待分享终端与车辆间的配对关系，所以在这里，该配对证明可以是用于确定备案请求里的数字钥匙的公钥是基于第一数据生成的，并来自下发第一数据的待分享终端。

示例性的，待分享终端可以通过ICCE标准下的终端与服务器之间通信机制向服务器发送第二备案请求，以向服务器证明第二备案请求中请求备案的公钥来自该待分享终端，而非其他设备。例如，待分享终端可以使用ICCE标准中的SCP03安全通道协议向其所属的厂商服务器证明第二备案请求的来源合法，然后，待分享终端的厂商服务器再和业务服务器(即图9中所描述的服务器)进行通信，以将该第二备案请求发送至业务服务器。

示例性的，待分享终端也可以使用服务器的公钥对第二备案请求进行加密，并发送至服务器，以保证只有服务器使用私钥才能解密出第二备案请求，提升数据安全性。

S906、服务器对待分享终端的数字钥匙的公钥进行备案，生成第二备案证明。

具体地，服务器获取到第二备案请求后，可以对待分享终端的数字钥匙的公钥进行备案，生成第二备案证明，该第二备案证明主要是用于证明服务器已对待分享终端的数字钥匙的公钥完成备案。示例性的，服务器可以通过存储待分享终端的数字钥匙的公钥，并通过对待分享终端的数字钥匙的公钥进行签名的方式生成第二备案证明。示例性的，第二备案证明中可以包括密钥追踪签名(key tracking signature)。

在一个例子中，第二备案证明中还可以包括认证数据包(attestation package)，该认证数据包可以用于构建数字钥匙分享过程中数字钥匙的数据结构。示例性的，如图10所示，认证数据包的数据结构可以包括：待分享终端的数字钥匙的公钥(friend publickey)、配置数据(profile)、分享口令信息(sharing password information)、箱位标识(slot identifier)、有效期(validity start/end)、钥匙昵称(key friendly name)中的一项或多项。其中，配置数据(profile)中可以包括操控权限等数据。分享口令信息可以包含有关车主设备策略是否要求车辆在激活共享数字钥匙之前向好友请求共享密码的信息。

在一个例子中，如图11所示，认证数据包(attestation package)中还可以包括车主设备的签名(ownersignature)。此时，服务器可以向车主设备发送签名请求，在车主设备进行签名后，比如：使用CCC的RSA密钥进行数字签名操作，或使用ICCE协议密钥进行加密或消息认证码(message authentication code，MAC)操作，即可以得到车主设备签名后的认证证明。由此以表明此次分享是由车主设备授权的，进一步提升安全性。

S907、服务器向待分享终端发送第二备案证明。

具体地，服务器对待分享终端的公钥进行备案后，可以向待分享终端发送第二备案证明。

S908、待分享终端响应于获取到的第二备案证明，向数字钥匙结构中写入数据。

具体地，待分享终端在获取到第一备案证明后，可以在其生成的数字钥匙结构中写入数据。其中，待分享终端在写入数据时，可以分阶段写入，即获取到一部分数据就写入一部分，也可以一次性写入，即获取到全部的数据后再写入。此时，待分享终端即具有CCC标准下分享所需的所有数据，即数字钥匙结构。此时，待分享终端则进入到配对完成的状态。

在一个例子中，待分享终端所需写入的数据，可以由服务器一次性下发，也可以由服务器分阶段下发，具体可根据实际情况而定，此处不做限定。

示例性的，对于私有邮箱和机密邮箱中所包含的车辆的数据，待分享终端可以从服务器中获得。其中，对于私有邮箱和机密邮箱中所包含的车辆的数据，可以预先存储在服务器中。此外，服务器也可以通过与车辆进行通信，以获取到私有邮箱和机密邮箱中所包含的车辆的数据。

S909、待分享终端向车辆发送至少包含数字钥匙的公钥的数据和第二备案证明。

具体地，待分享终端在向数字钥匙结构中写入数据后，可以向车辆发送至少包含数字钥匙的公钥的数据和第二备案证明。

S910、车辆对第二备案证明进行校验，并在校验通过后存储待分享终端的数字钥匙的公钥。

具体地，车辆获取到至少包含数字钥匙的公钥的数据和第二备案证明后，其可以按照预设的校验规则对该第二备案证明进行校验，当校验通过后，其即可以获知到其获取到的至少包含数字钥匙的公钥的数据来自待分享终端(即可信任的设备)，此时其可以存储该数字钥匙的公钥。至此，即完成在CCC标准下数字钥匙分享，之后，待分享终端和车辆之间即可以使用CCC标准下的数字钥匙系统进行通信。

在一个例子中，在执行S904后，待分享终端可以直接执行S908，以及S908之后的步骤，即省略中间的备案过程，即省略S905至S907，且在执行S908之后的步骤时省略发送第二备案证明，具体可根据实际情况而定，此处不做限定。

在一个例子中，在图9中，待分享终端、服务器、车辆之间可以完全遵照ICCE标准执行，在进行通信时，可以基于ICCE标准定义的通信机制和安全机制进行通信。其中，安全机制可以包括业务校验、用户身份校验、信任关系校验、数据下发等机制。可以理解的是，图9中待分享终端与服务器之间采用的是ICCE标准中定义的待分享终端和服务器之间的通信机制、业务校验机制、用户身份校验机制和安全数据下发机制，待分享终端与车辆之间采用的是ICCE标准中定义的待分享终端和车辆之间的通信机制和数字钥匙及相关数据的校验等信任关系校验机制，车辆与服务器之间之间亦采用的是ICCE标准中定义的通信机制和安全机制。

可以理解的是，图9中，在ICCE标准的数字钥匙系统下，基于车辆、车主设备和服务器之间的信任关系，通过服务器远程下发CCC标准下数字钥匙分享所需的数据，从而无需车主设备和被分享设备间建立安全通信机制，即可以实现在ICCE标准的数字钥匙系统下完成CCC标准下的数字钥匙的分享，简化了分享流程，且实现了在ICCE标准的数字钥匙系统下增加对CCC标准的数字钥匙系统的支持，从而使得在不实现CCC分享协议的情况下实现CCC体系的分享所需的数据交互，减少了开发工作量和PKI体系成本，提升了用户体验。

接下来，基于上文所描述的内容，对本申请实施例提供的一种数字钥匙开通方法进行介绍。可以理解的是，该方法是上文所描述的内容的另一种表达方式，两者是相结合的。该方法是基于上文所描述的内容提出，该方法中的部分或全部内容可以参见上文中的相关描述。

请参阅图12，图12是本申请实施例提供的一种数字钥匙开通方法的流程示意图。该方法可以通过任何具有计算、处理能力的装置、设备、平台、设备集群来执行。

在图12中，第一设备、第二设备和服务器之间已预先配置第一业务协议，其中，第一设备在第一业务协议下可以申请开通第一数字钥匙。示例性的，图12中的第一设备可以为手机等终端，比如第一设备可以为图4a中所示的终端100，第二设备可以为车辆、安全门等设备，比如，第二设备可以为图4a中所示的车辆200。其中，第一设备可以通过数字钥匙对第二设备进行控制。在一个例子中，第一设备也可以为上文图9中所描述的待分享终端。示例性的，在图12中，第一业务协议可以为ICCE标准协议，第二业务协议可以为CCC标准协议。

如图12所示，该数字钥匙开通方法，可以包括以下步骤：

S1201、第一设备向服务器发送目标请求，目标请求用于请求申请开通第二业务协议下的第二数字钥匙。

具体地，第一设备在获取到用于下发的数字钥匙申请指令后，可以向服务器发送用于申请开通第二业务协议下的第二数字钥匙的目标请求。示例性的，目标请求可以为上文所描述的第一请求。

在一个例子中，第一设备可以复用第一业务协议下的钥匙下发/更新流程中的通信机制将该目标请求发送至服务器。

在一个例子中，目标请求可以是在用户利用第一设备申请第一业务协议下的第一数字钥匙时发送，也可以是在用户已申请第一数字钥匙，并又申请第二数字钥匙时生成。

S1202、服务器响应于目标请求，获取目标数据，并利用第一业务协议定义的第一通信机制向第一设备发送目标数据，目标数据用于构建第二数字钥匙的数据结构。

具体地，服务器获取到目标请求后，可以用于构建第二数字钥匙的数据结构的目标数据。示例性的，该目标数据可以预先配置在服务器中，也可以实时或预先从第二设备处获得。其中，当服务器获取到目标数据后，服务器可以利用第一业务协议定义的第一通信机制向第一设备发送该目标数据。示例性的，目标数据可以为上文所描述的第一数据。示例性的，第一通信机制是指第一业务协议下定义的第一设备和服务器之间的通信机制。比如：设备间通过密钥加密/解密数据来提供安全保障的通信机制。

在一个例子中，目标数据可以包括以下一项或多项：第二设备的标识，第二设备的公钥，箱位标识，授权公钥组，钥匙能力数据，私有邮箱大小，或，机密邮箱大小。

S1203、第一设备响应于获取到的目标数据，生成第二数字钥匙的公钥和私钥，并至少基于目标数据构建第一数据结构，以及向第一数据结构中至少写入目标数据中的部分数据。

具体地，第一设备获取到目标数据后，可以生成第二数字钥匙的公钥和私钥，并至少基于目标数据构建出第一数据结构，以及向第一数据结构中至少写入目标数据中的部分数据。至此第一设备即进入到在第二业务协议下第一设备侧配对完成的状态。

在一个例子中，第一数据结构可以为上文图3中所描述的符合CCC标准要求的数字钥匙结构。

示例性的，第一数据结构包括以下一项或多项：第二设备标识，第一设备内部对第二数字钥匙定义的标识，数字钥匙标识，箱位标识，实例CA标识，钥匙能力数据，第二数字钥匙的公钥，第二设备的公钥，授权公钥组，私有邮箱，或，机密邮箱。其中，第一设备内部对第二数字钥匙定义的标识可以理解为上文图3中所描述的节点标识。

在第一数据结构中，第一设备内部对第二数字钥匙定义的标识，数字钥匙标识，箱位标识，实例CA标识和第二数字钥匙的公钥可以均由第一设备提供。第二设备标识，箱位标识，钥匙能力数据，第二设备的公钥和授权公钥组可以均由目标数据得到。私有邮箱和机密邮箱可以由第一设备基于目标数据创建。

在一个例子中，第一设备在向第一数据结构中至少写入目标数据中的部分数据之前，第一设备可以利用第一业务协议定义的第一通信机制向服务器发送目标备案请求，其中，该目标备案请求用于请求对第二数字钥匙的公钥进行备案。服务器在获取到该目标备案请求后，可以对第二数字钥匙的公钥进行备案，生成目标备案证明，其中，目标备案证明用于证明服务器已完成对第二数字钥匙的公钥的备案。接着，服务器可以利用第一业务协议定义的第一通信机制向第一设备发送该目标备案证明。最后，第一设备即可以获取到服务器发送的目标备案证明。示例性的，目标备案证明可以为上文图8中所描述的第一备案证明，也可以为上文图9中所描述的第二备案证明。

S1204、第一设备利用第一业务协议定义的第二通信机制向第二设备发送第一消息，第一消息中包括第二数字钥匙的公钥，第一消息用于指示第二设备存储第二数字钥匙的公钥。

具体地，第一设备在向第一数据结构写入数据后，此时第一设备已完成在其自身一侧完成数字钥匙配对的状态，此时，第一设备可以利用第一业务协议定义的第二通信机制向第二设备发送第一消息，第一消息中包括第二数字钥匙的公钥，第一消息用于指示第二设备存储第二数字钥匙的公钥。示例性的，第二通信机制是指第一业务协议下定义的是第一设备和第二设备之间的通信机制。比如：设备间基于数字钥匙的密钥和鉴权协议来提供安全保障的通信机制。

在一个例子中，当第一设备获取到服务器发送的目标备案证明后，第一设备还可以在第一消息中添加目标备案证明。这样，第二设备即可以通过服务器签发的备案证明来进一步再次确认该第二数字钥匙的公钥来自合法的设备，由此以进一步提升安全性。

S1205、第二设备响应于第一消息，存储第二数字钥匙的公钥。

具体地，第二设备获取到第一消息后，可以存储第二数字钥匙的公钥。至此，即完成第一设备和第二设备在第二业务协议下的第二数字钥匙的开通，之后，第一设备和第二设备之间即可以使用该第二数字钥匙系统进行通信，且第一设备可以利用该第二数字钥匙对第二设备进行控制。

在一个例子中，当第一消息中包括目标备案证明时，第二设备可以按照预设的校验规则对该目标备案证明进行校验，当校验通过后，其即可以获知到其获取到的第二数字钥匙的公钥来自合法的设备，此时其可以存储第二数字钥匙的公钥。

在一个例子中，第一设备和第二设备中均配置有与第一数字钥匙匹配的数字钥匙系统，和与第二数字钥匙匹配的数字钥匙系统。换言之，第一设备和第二设备中均配置有两套数字钥匙系统，不同的数字钥匙系统可以支持不同的业务协议。

由此，实现在第一业务协议的数字钥匙系统下，基于第一设备、第二设备和服务器之间的信任关系，通过服务器远程下发第二业务协议下数字钥匙开通所需的数据，利用第一业务协议下定义的机制使得在实施第二业务协议下的第一设备和第二设备间完成第二业务协议下的数字钥匙的开通，实现了在第一业务协议下的数字钥匙系统下增加对第二业务协议下的数字钥匙系统的支持，从而使得在可以不实现或执行第二业务协议下的配对协议的情况下实现第二业务协议下数字钥匙开通所需的数据交互，减少了开发工作量和PKI体系成本，提升了用户体验。

可以理解的是，本申请的任意实施例中的各个步骤的执行顺序在不矛盾的前提下，可根据实际情况进行调整，调整后的技术方案也在本申请的范围之内。此外，本申请的任意实施例中的各个步骤也可以选择性执行，此处不做限定。

基于上述实施例中的方法，本申请实施例还提供了一种芯片。请参阅图13，图13为本申请实施例提供的一种芯片的结构示意图。如图13所示，芯片1300包括一个或多个处理器1301以及接口电路1302。可选的，芯片1300还可以包含总线1303。其中：

处理器1301可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器1301中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器1301可以是通用处理器、数字通信器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。接口电路1302可以用于数据、指令或者信息的发送或者接收，处理器1301可以利用接口电路1302接收的数据、指令或者其它信息，进行加工，可以将加工完成信息通过接口电路1302发送出去。

可选的，芯片还包括存储器，存储器可以包括只读存储器和随机存取存储器，并向处理器提供操作指令和数据。存储器的一部分还可以包括非易失性随机存取存储器(NVRAM)。可选的，存储器存储了可执行软件模块或者数据结构，处理器可以通过调用存储器存储的操作指令(该操作指令可存储在操作系统中)，执行相应的操作。

可选的，接口电路1302可用于输出处理器1301的执行结果。

需要说明的，处理器1301、接口电路1302各自对应的功能既可以通过硬件设计实现，也可以通过软件设计来实现，还可以通过软硬件结合的方式来实现，这里不作限制。

应理解，上述方法实施例的各步骤可以通过处理器中的硬件形式的逻辑电路或者软件形式的指令完成。其中，该芯片可应用于上述图4a中的终端100、车辆200或服务器300中，以实现本申请实施例中提供的方法。

可以理解的是，本申请的实施例中的处理器可以是中央处理单元(centralprocessing unit，CPU)，还可以是其他通用处理器、数字信号处理器(digital signalprocessor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现场可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、晶体管逻辑器件，硬件部件或者其任意组合。通用处理器可以是微处理器，也可以是任何常规的处理器。

本申请的实施例中的方法步骤可以通过硬件的方式来实现，也可以由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成，软件模块可以被存放于随机存取存储器(random access memory，RAM)、闪存、只读存储器(read-only memory，ROM)、可编程只读存储器(programmable rom，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)、寄存器、硬盘、移动硬盘、CD-ROM或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者通过所述计算机可读存储介质进行传输。所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。

可以理解的是，在本申请的实施例中涉及的各种数字编号仅为描述方便进行的区分，并不用来限制本申请的实施例的范围。

Claims (21)

1.一种数字钥匙开通方法，其特征在于，应用于第一设备，其中，所述第一设备、第二设备和服务器之间已预先配置第一业务协议，所述第一设备在所述第一业务协议下可开通第一数字钥匙，所述方法包括：

向所述服务器发送目标请求，所述目标请求用于请求申请开通第二业务协议下的第二数字钥匙；

利用所述第一业务协议定义的第一通信机制获取所述服务器发送的目标数据，所述目标数据用于构建所述第二数字钥匙的第一数据结构；

响应于获取到的所述目标数据，生成所述第二数字钥匙的公钥和私钥，并至少基于所述目标数据构建所述第二数字钥匙的第一数据结构，以及向所述第一数据结构中至少写入所述目标数据中的部分数据；

利用所述第一业务协议定义的第二通信机制向所述第二设备发送第一消息，所述第一消息中包括所述第二数字钥匙的公钥，所述第一消息用于指示所述第二设备存储所述第二数字钥匙的公钥。

2.根据权利要求1所述的方法，其特征在于，所述向所述第一数据结构中至少写入所述目标数据中的部分数据之前，所述方法还包括：

利用所述第一业务协议定义的第一通信机制向所述服务器发送目标备案请求，所述目标备案请求用于请求对所述第二数字钥匙的公钥进行备案；

获取所述服务器发送的所述目标备案证明，所述目标备案证明用于证明所述服务器已完成对所述第二数字钥匙的公钥的备案。

3.根据权利要求2所述的方法，其特征在于，所述第一消息中还包括所述目标备案证明。

4.根据权利要求1-3任一所述的方法，其特征在于，所述目标数据包括以下一项或多项：

所述第二设备的标识，所述第二设备的公钥，箱位标识，授权公钥组，钥匙能力数据，私有邮箱大小，或，机密邮箱大小。

5.根据权利要求1-4任一所述的方法，其特征在于，所述第一数据结构包括以下一项或多项：

所述第二设备标识，所述第一设备内部对所述第二数字钥匙定义的标识，数字钥匙标识，箱位标识，实例CA标识，钥匙能力数据，所述第二数字钥匙的公钥，所述第二设备的公钥，授权公钥组，私有邮箱，或，机密邮箱。

6.根据权利要求5所述的方法，其特征在于，所述第一设备内部对所述第二数字钥匙定义的标识，数字钥匙标识，箱位标识，实例CA标识和所述第二数字钥匙的公钥均由所述第一设备提供。

7.根据权利要求5或6所述的方法，其特征在于，所述第二设备标识，箱位标识，钥匙能力数据，所述第二设备的公钥和授权公钥组均由所述目标数据得到，所述私有邮箱和所述机密邮箱由所述第一设备基于所述目标数据创建。

8.根据权利要求1-7任一所述的方法，其特征在于，所述第一设备和所述第二设备中均配置有与所述第一数字钥匙匹配的数字钥匙系统，和与所述第二数字钥匙匹配的数字钥匙系统。

9.根据权利要求1-8任一所述的方法，其特征在于，所述第一业务协议为ICCE标准协议，所述第二业务协议为CCC标准协议。

10.根据权利要求1-9任一所述的方法，其特征在于，所述第一通信机制为基于设备间的密钥加密/解密数据以提供安全保障的通信机制；

所述第二通信机制为基于第一数字钥匙的密钥和鉴权协议以提供安全保障的通信机制。

11.一种数字钥匙开通方法，其特征在于，应用于服务器，其中，所述服务器、第一设备和第二设备之间已预先配置第一业务协议，所述第一设备在所述第一业务协议下可开通第一数字钥匙，所述方法包括：

获取所述第一设备发送的目标请求，所述目标请求用于请求申请开通第二业务协议下的第二数字钥匙；

响应于所述目标请求，获取目标数据，并利用所述第一业务协议定义的第一通信机制向所述第一设备发送所述目标数据，所述目标数据用于构建所述第二数字钥匙的第一数据结构。

12.根据权利要求11所述的方法，其特征在于，所述方法还包括：

利用所述第一业务协议定义的第一通信机制获取所述第一设备发送目标备案请求，所述目标备案请求用于请求对所述第二数字钥匙的公钥进行备案；

响应于所述目标备案请求，对所述第二数字钥匙的公钥进行备案，生成目标备案证明，所述目标备案证明用于证明所述服务器已完成对所述第二数字钥匙的公钥的备案；

利用第一业务协议定义的第一通信机制向所述第一设备发送所述目标备案证明。

13.根据权利要求11或12所述的方法，其特征在于，所述目标数据包括以下一项或多项：

所述第二设备的标识，所述第二设备的公钥，箱位标识，授权公钥组，钥匙能力数据，私有邮箱大小，或，机密邮箱大小。

14.根据权利要求11-13任一所述的方法，其特征在于，所述第一数据结构包括以下一项或多项：

所述第二设备标识，所述第一设备内部对所述第二数字钥匙定义的标识，数字钥匙标识，箱位标识，实例CA标识，钥匙能力数据，所述第二数字钥匙的公钥，所述第二设备的公钥，授权公钥组，私有邮箱，或，机密邮箱。

15.根据权利要求11-14任一所述的方法，其特征在于，所述第一设备和所述第二设备中均配置有与所述第一数字钥匙匹配的数字钥匙系统，和与所述第二数字钥匙匹配的数字钥匙系统。

16.根据权利要求11-15任一所述的方法，其特征在于，所述第一业务协议为ICCE标准协议，所述第二业务协议为CCC标准协议。

17.根据权利要求11-16任一所述的方法，其特征在于，所述第一通信机制为基于设备间的密钥加密/解密数据以提供安全保障的通信机制。

18.一种数字钥匙开通系统，其特征在于，包括第一设备、第二设备和服务器，所述第一设备、所述第二设备和所述服务器之间已预先配置第一业务协议，所述第一设备在所述第一业务协议下可开通第一数字钥匙，其中，所述第一设备用于执行权利要求1-10任一所述的方法，所述服务器用于执行如权利要求11-17任一所述的方法，所述第二设备用于响应于所述第一设备发送的第一消息，存储所述第二数字钥匙的公钥。

19.一种设备，其特征在于，包括：

至少一个存储器，用于存储程序；

至少一个处理器，用于执行所述存储器存储的程序，当所述存储器存储的程序被执行时，所述处理器用于执行如权利要求1-10任一所述的方法，或者，执行如权利要求11-17任一所述的方法。

20.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，当所述计算机程序在电子设备上运行时，使得所述电子设备执行如权利要求1-10任一所述的方法，或者，执行如权利要求11-17任一所述的方法。

21.一种计算机程序产品，其特征在于，当所述计算机程序产品在电子设备上运行时，使得所述电子设备执行如权利要求1-10任一所述的方法，或者，执行如权利要求11-17任一所述的方法。

Images