CN116566594A - 一种设备控制方法、设备和分布式数字钥匙*** - Google Patents

一种设备控制方法、设备和分布式数字钥匙*** Download PDF

Info

Publication number
CN116566594A
CN116566594A CN202210114846.2A CN202210114846A CN116566594A CN 116566594 A CN116566594 A CN 116566594A CN 202210114846 A CN202210114846 A CN 202210114846A CN 116566594 A CN116566594 A CN 116566594A
Authority
CN
China
Prior art keywords
information
key
application
related information
key related
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210114846.2A
Other languages
English (en)
Inventor
李涛
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN202210114846.2A priority Critical patent/CN116566594A/zh
Priority to PCT/CN2022/139977 priority patent/WO2023142773A1/zh
Publication of CN116566594A publication Critical patent/CN116566594A/zh
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00—Individual registration on entry or exit
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00—Individual registration on entry or exit
    • G07C9/00174—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
    • G07C9/00896—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys specially adapted for particular uses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Lock And Its Accessories (AREA)

Abstract

本申请实施例提供一种设备控制方法、设备和分布式数字钥匙***，涉及通信技术领域。该方法应用于第一设备和第二设备，第一设备中存储有第一秘钥相关信息中的脱敏信息；第二设备的安全元件内存储有第一秘钥相关信息中的敏感信息和第二秘钥相关信息。该方法包括：第一设备向第二设备发送脱敏信息；第二设备将脱敏信息和敏感信息合并为第一秘钥相关信息；第二设备根据第一秘钥相关信息和第二秘钥相关信息进行第一设备和第二设备的相互认证；第二设备根据认证结果执行预设指令。本申请实施例提供的技术方案能够提高对终端设备的兼容性和安全性。

Description

一种设备控制方法、设备和分布式数字钥匙***
技术领域
本申请涉及通信技术领域，尤其涉及一种设备控制方法、设备和分布式数字钥匙***。
背景技术
数字钥匙(digital key，DK)是内置在手机等终端设备中的“虚拟钥匙”，随着计算机技术的发展，数字钥匙在汽车、智能门锁等领域的应用越来越广泛。以在汽车领域的应用为例，通过数字钥匙，用户不仅可以便捷地控制车门上锁、解锁、启动车机，还可以便捷地进行驾驶认可、转移汽车使用权等。
为了保障数字钥匙服务的安全，防止其他应用对数字钥匙进行恶意解析攻击，在目前的数字钥匙***中，数字钥匙通常需要存储在终端设备和目标设备(例如车机)各自的安全单元(Secure Element，SE)中，且安全单元通常至少需要达到评估保证等级4+(theevaluation assurance level 4+，EAL4+)的安全级别。但是，目前不少终端设备未配置满足要求的SE，或者，虽然配置了满足要求的SE但数字钥匙服务商没有权限使用该SE，这就导致基于该类终端设备无法使用满足安全级别的数字钥匙解锁和启动目标设备。换而言之，目前的数字钥匙***或因为无SE存储和保护钥匙信息导致安全性差，或因为SE权限设置和访问模式封闭导致兼容性差。
发明内容
本申请提供一种设备控制方法、设备和分布式数字钥匙***，用于提高数字钥匙***对终端设备的兼容性和安全性。
为达到上述目的，本申请采用如下技术方案：
第一方面，本申请实施例提供一种设备控制方法，应用于第一设备和第二设备，第一设备中存储有第一秘钥相关信息中的脱敏信息；第二设备的安全元件内存储有第一秘钥相关信息中的敏感信息和第二秘钥相关信息。该方法包括：第一设备向第二设备发送该脱敏信息；第二设备将该脱敏信息和该敏感信息合并为第一秘钥相关信息；第二设备根据第一秘钥相关信息和第二秘钥相关信息进行第一设备和第二设备的相互认证；第二设备根据认证结果执行预设指令。
其中，第一设备可以是终端设备(例如手机、智能手表等)，第二设备可以是终端设备控制的目标设备(例如车机、智能门锁等)。
在本实施例提供的方法中，终端设备的第一秘钥相关信息被分为脱敏信息和敏感信息两部分，且脱敏信息存储在终端设备中，敏感信息被存储在目标设备的安全元件中。由于该方法无需使用终端设备的安全元件，因此，能够兼容不具备安全元件或者在控制目标设备时无权使用安全元件的终端设备，即对终端设备具有更好的兼容性。另外，由于第一秘钥相关信息的敏感信息存储在目标设备的安全元件内，因此，该方法也能保证信息的安全性。
在一些实施例中，第二设备的安全元件内设置有第二数字钥匙应用和服务器应用，服务器应用内存储有该敏感信息，第二数字钥匙应用内存储有第二秘钥相关信息；第二设备根据第一秘钥相关信息和第二秘钥相关信息进行第一设备和第二设备的相互认证，以及，第二设备根据认证结果执行预设指令，包括：
服务器应用向第二数字钥匙应用发送第一秘钥相关信息中的卡片认证信息，卡片认证信息为第一秘钥相关信息的全部或者部分信息。
第二数字钥匙应用根据卡片认证信息和第二秘钥相关信息生成验证请求密文，以及，向服务器应用发送验证请求密文。
服务器应用根据验证请求密文认证第二设备；以及，在对第二设备认证通过之后，向第二数字钥匙应用发送应答密文。
第二数字钥匙应用根据应答密文认证第一设备；以及，在对第一设备认证通过之后，控制第二设备执行预设指令。
在本实施例中，第二设备的服务器应用作为终端设备的角色，第二数字钥匙应用作为目标设备的角色，使用第一秘钥相关信息和第二秘钥相关信息进行终端设备和目标设备的相互认证，使得认证过程避免了敏感信息在终端设备和目标设备之间的传输，能够保证认证过程的安全性。
在一些实施例中，该方法还包括：第二设备更新第一秘钥相关信息，并向第一设备发送更新后的第一秘钥相关信息中的脱敏信息。
在一些实施例中，在第一设备向第二设备发送该脱敏信息之前，该方法还包括：第一设备向第二设备发送第一设备的第一身份校验信息；第二设备根据第一身份校验信息校验第一设备的身份是否合法；以及，若第一设备的身份合法，第二设备向第一设备发送第二设备的第二身份校验信息；第一设备根据第二身份校验信息校验第二设备的身份是否合法。
在一些实施例中，在第一设备向第二设备发送该脱敏信息之前，该方法还包括：第一设备通过第一服务器向第二服务器发送注册信息；第二服务器根据注册信息生成第一秘钥相关信息，并向第一设备发送第一秘钥相关信息中的该脱敏信息，向第二设备发送第一秘钥相关信息中的该敏感信息。
在一些实施例中，第一设备向第二设备发送该脱敏信息，包括：第一设备在检测到第一预设条件之后，向第二设备发送该脱敏信息。其中，第一预设条件为，第一设备与第二设备的距离在预设范围内；或者，第一设备获取到第二用户操作，第二用户操作用于控制第二设备执行预设指令。
在一些实施例中，在第一设备和第二设备之间采用低功耗蓝牙BLE技术通信的情况下，第一设备和第二设备基于超文本传输安全协议HTTPS交互信息。
在一些实施例中，第一秘钥相关信息存储在第一数字钥匙应用内；第一数字钥匙应用为软件安装包中携带的应用程序，或者，应用平台的嵌套的小程序，或者网页应用程序。这一便捷的用户选项得益于第一数字钥匙应用不再依赖第一设备封闭的安全元件。
在一些实施例中，该敏感信息和第二秘钥相关信息位于第二设备的安全元件内，且位于安全元件内防火墙的两侧。
第二方面，本申请实施例提供一种设备控制方法，应用于第一设备，第一设备中存储有第一秘钥相关信息中的脱敏信息；第一秘钥相关信息中的敏感信息和第二秘钥相关信息存储于第二设备的安全元件内。该方法包括：向第二设备发送该脱敏信息。其中，该脱敏信息用于与第二设备中的敏感信息合并，获得第一秘钥相关信息；第一秘钥相关信息和第二秘钥相关信息用于由第二设备进行第一设备和第二设备的相互认证，以及，根据认证结果控制第二设备执行预设指令。
在一些实施例中，向第二设备发送该脱敏信息，包括：与第二设备相互校验对方的身份是否合法；若第一设备和第二设备的身份均合法，则向第二设备发送该脱敏信息。
在一些实施例中，向第二设备发送脱敏信息，包括：在检测到第一预设条件之后，向第二设备发送脱敏信息。其中，第一预设条件为，第一设备与第二设备的距离在预设范围内；或者，第一设备获取到第二用户操作，第二用户操作用于控制第二设备执行预设指令。
在一些实施例中，在向第二设备发送脱敏信息之前，该方法还包括：通过第一服务器向第二服务器发送注册信息；通过第一服务器接收第二服务器发送的该脱敏信息，该脱敏信息对应的第一秘钥相关信息是由第二服务器根据注册信息生成的；存储脱敏信息。
在一些实施例中，在第一设备和第二设备之间采用低功耗蓝牙BLE技术通信的情况下，第一设备和第二设备基于超文本传输安全协议HTTPS交互信息。
在一些实施例中，第一秘钥相关信息存储在第一数字钥匙应用内；第一数字钥匙应用为软件安装包中携带的应用程序，或者，应用平台的嵌套的小程序，或者网页应用程序。
第三方面，本申请实施例提供一种设备控制方法，应用于第二设备，第二设备的安全元件内存储有第一秘钥相关信息中的敏感信息和第二秘钥相关信息；第一秘钥相关信息中的脱敏信息存储在第一设备内。
该方法包括：接收第一设备发送的该脱敏信息；将该脱敏信息和该敏感信息合并为第一秘钥相关信息；根据第一秘钥相关信息和第二秘钥相关信息进行第一设备和第二设备的相互认证；根据认证结果控制第二设备执行预设指令。
在一些实施例中，第二设备的安全元件内设置有第二数字钥匙应用和服务器应用，服务器应用内存储有该敏感信息，第二数字钥匙应用内存储有第二秘钥相关信息；根据第一秘钥相关信息和第二秘钥相关信息进行第一设备和第二设备的相互认证，以及，根据认证结果控制第二设备执行预设指令，包括：
服务器应用向第二数字钥匙应用发送第一秘钥相关信息中的卡片认证信息，卡片认证信息为第一秘钥相关信息的全部或者部分信息。
第二数字钥匙应用根据卡片认证信息和第二秘钥相关信息生成验证请求密文，以及，向服务器应用发送验证请求密文。
服务器应用根据验证请求密文认证第二设备；以及，在对第二设备认证通过之后，向第二DK应用发送应答密文。
第二数字钥匙应用根据应答密文认证第一设备；以及，在对第一设备认证通过之后，控制第二设备执行预设指令。
在一些实施例中，该方法还包括：更新第一秘钥相关信息，并向第一设备发送更新后的第一秘钥相关信息中的脱敏信息。
在一些实施例中，在接收第一设备发送的该脱敏信息之前，该方法还包括：与第一设备相互校验对方的身份是否合法；在确定第一设备和第二设备的身份均合法之后，接收第一设备发送的该脱敏信息。
在一些实施例中，该敏感信息和第二秘钥相关信息位于第二设备的安全元件内，且位于安全元件内防火墙的两侧。
第四方面，本申请实施例提供一种分布式数字钥匙***，包括第一设备和第二设备，第一设备中存储有第一秘钥相关信息中的脱敏信息；第二设备的安全元件内存储有第一秘钥相关信息中的敏感信息和第二秘钥相关信息；第一设备和第二设备相互配合，实现上述第一方面示出的设备控制方法。
第五方面，本申请实施例提供一种第一设备，第一设备中存储有第一秘钥相关信息中的脱敏信息；第一秘钥相关信息中的敏感信息存储于第二设备的安全元件内，第一设备被配置为执行上述第二方面示出的设备控制方法。
第六方面，本申请实施例提供一种第二设备，第二设备的安全元件内存储有第一秘钥相关信息中的敏感信息和第二秘钥相关信息，第二设备被配置为执行如上述第三方面示出的设备控制方法。
第七方面，本申请实施例提供一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现如上述第二方面示出的设备控制方法。
第八方面，本申请实施例提供一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现如上述第三方面示出的设备控制方法。
第九方面，本申请实施例提供一种计算机程序产品，当该计算机程序产品在第一设备上运行时，使得该第一设备实现如第二方面示出的方法。
第十方面，本申请实施例提供一种计算机程序产品，当该计算机程序产品在第二设备上运行时，使得该第二设备实现如第三方面示出的方法。
可以理解的是，上述第二方面至第十方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。
附图说明
图1是本申请的一个实施例提供的数字钥匙***的示意性架构图；
图2是本申请另一个实施例提供的数字钥匙***的示意性架构图；
图3是本申请实施例提供的数字钥匙服务注册与开通过程的示意性流程图；
图4是本申请实施例提供的终端设备侧数字钥匙服务的开通界面示意图；
图5是本申请实施例提供的目标设备侧数字钥匙服务的开通界面示意图；
图6是本申请的一个实施例提供的目标设备解锁的示意性流程图；
图7是本申请另一个实施例提供的目标设备开锁的示意性流程图。
具体实施方式
下面结合附图对本申请实施例提供的技术方案进行说明。
应理解，在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。
在本实施例中，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。
数字钥匙(digital key，DK)是内置在手机等终端设备中的“虚拟钥匙”，随着计算机技术的发展，数字钥匙在汽车、智能门锁等领域的应用越来越广泛。以在汽车领域的应用为例，通过数字钥匙，用户不仅可以智能解闭车锁、远程启动车机、远程开关车机空调，还可以便捷地进行驾驶认可、通过分享数字钥匙转移汽车使用权等操作，给用户带来了更好的车机控制体验。
图1是本申请的一个实施例提供的数字钥匙***的示意性架构图。参见图1所示，该数字钥匙***包括终端设备(也可以称作第一设备)、终端设备服务器(也可以称作第一服务器)、目标设备服务器(也可以称作第二服务器)和目标设备(也可以称作第二设备)。下面分别对其进行说明。
(1)终端设备
在本申请的各个实施例中，终端设备可以是手机(mobile phone)、平板电脑(Pad)、可穿戴设备(如智能手表)、带无线收发功能的电脑、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、超级移动个人计算机(ultra-mobile personalcomputer，UMPC)、上网本、个人数字助理(personal digital assistant，PDA)等。本申请实施例对终端设备的类型不做具体限定。
在本实施例中，终端设备中设置有第一DK应用、第一SE和第一通信单元。
其中，在图1所示的***中，第一DK应用通常是安卓软件安装包(andriodPackage，APK)中携带的应用程序。第一DK应用在接收到用户的数字钥匙服务开通指令之后，可以与终端设备服务器进行交互，获得终端设备侧用于控制目标设备(例如解锁目标设备)的秘钥相关信息(本实施例称之为第一秘钥相关信息)。在本实施例中，第一DK应用包括相互配合的第一部分和第二部分，其中，第一部分部署在终端设备的存储器内，主要用于配置和维护第一DK应用。第二部分部署在第一SE中，用于存储第一秘钥相关信息，与目标设备(如车机)做鉴权认证。
第一SE用于存储终端设备内的关键数据，第一SE通常以芯片的形式存在于终端设备的内部，其通过加密/解密逻辑电路防止其他应用对SE内数据的恶意解析攻击，保护数据安全。需要说明的是，有使用权限的应用程序才能在第一SE内存储关键数据。以第一DK应用为例，若第一DK应用具有使用第一SE的权限，第一DK应用才可以将第一秘钥相关信息存储在第一SE中。
第一通信单元可以向应用(例如第一DK应用)提供在终端设备上的无线通信解决方案。该第一通信单元可以是射频(radio frequency，RF)单元，也可以是其他无线通信单元。终端设备通过该第一通信单元可以与终端设备服务器和目标设备通信。
(2)终端设备服务器
终端设备服务器能够向终端设备提供数字钥匙服务注册与开通服务，并且能够与目标设备服务器在建立可信链路之后，进行数据分享、信息交互等操作。
由于第一秘钥相关信息中与终端设备侧的相关信息(例如用户账号和密码信息、Token等)由终端设备服务器维护，而与目标设备相关的信息(例如卡片秘钥(CardSecret)、卡片用于认证阶段的扩展字段(CardAuthRFU)等)由目标设备服务器维护，终端设备与目标设备服务器进行交互时，需要终端设备服务器做请求和应答的中转。也就是说，终端设备服务器是终端设备和目标设备服务器进行信息交互的桥梁。具体地，终端设备服务器负责数字钥匙生命周期(例如注册、开通、更新、注销、同步和使用等)管理。因此，终端设备服务器也能够将终端设备侧的相关信息同步给目标设备服务器。
(3)目标设备
目标设备中设置有第二DK应用、第二SE和第二通信单元。
在本实施例中，第二DK应用包括相互配合的第一部分和第二部分，其中，第一部分部署在目标设备的存储器内，主要用于配置和维护第二DK应用。第二部分部署在第二SE中，用于存储目标设备的秘钥相关信息(本实施例称之为第二秘钥相关信息)，与终端设备(如手机)做鉴权认证，以及控制目标设备执行预设指令(例如控制车机解锁、启动引擎等)。
第二DK应用能够与目标设备服务器进行交互，接收目标设备服务器的指令、通知或者信息，并执行对应的操作。例如，目标设备应用可以根据目标设备服务器的通知，结合用户操作开通目标设备侧的数字钥匙服务，获得第二秘钥相关信息。
第二SE用于存储目标设备内的关键数据(例如第二秘钥相关信息)，其通常以芯片的形式存在于目标设备的内部，通过加密/解密逻辑电路防止其他应用对SE内数据的恶意解析攻击，保护数据安全。
第二通信单元可以向应用(例如第二DK应用)提供在目标设备上的无线通信解决方案。该第二通信单元可以是射频单元，也可以是其他无线通信单元。目标设备通过第二通信单元可以与目标设备服务器和终端设备通信。
(4)目标设备服务器
目标设备服务器能够向目标设备提供数字钥匙服务注册与开通服务，并能够与终端设备服务器在建立可信链路之后，进行数据分享、信息交互等操作。
在终端设备和目标设备均开通数字钥匙服务之后，若用户携带终端设备靠近目标设备，或者终端设备接收到用户对目标设备的控制操作之后，终端设备和目标设备通过第一秘钥相关信息和第二秘钥相关信息相互校验，并在校验成功之后控制目标设备执行预设指令(例如控制目标设备解锁)。以目标设备是车机为例，目标设备解锁之后，用户即可打开车门，或者启动车机引擎。
为了保障数字钥匙的安全，在上述本实施例提供的数字钥匙***中，第一SE和第二SE的均至少需达到EAL4+的安全级别。但是，目前有一些终端设备(例如一些中低端的手机、平板电脑、可穿戴设备等)是未配置满足要求的SE的；另外，有一些终端设备虽然配置了满足需求的SE，但由于权限问题，第一DK应用无法使用终端设备的SE，这就导致这些终端设备无法与目标设备等组成上述数字钥匙***，从而无法解锁目标设备或者无法安全解锁目标设备。也就是说，目前的数字钥匙***对终端设备的兼容性较差，且安全性较差。
为此，本申请实施例还提供一种分布式数字钥匙***，该数字钥匙***对各类终端设备具有更强的兼容性，并且能够保证数字钥匙的安全性。
图2是本申请另一个实施例提供的数字钥匙***的示意性架构图。参见图2所示，该***包括：终端设备(也可以称作第一设备)、终端设备服务器(也可以称作第一服务器)、目标设备(也可以称作第二设备)和目标设备服务器(也可以称作第二服务器)。下面分别对其进行说明。
(1)终端设备
在本实施例中，终端设备中设置有第一DK应用和第一通信单元。
在图2所示的***中，第一DK应用可以是APK中携带的应用程序。特别地，第一DK应用还可以是统一资源定位符(Uniform Resource Locator，URL)网页中运行的程序，或者一些应用平台(如微信、支付宝)中嵌套的小程序(Applet)，这一便捷的用户选项得益于第一DK应用不再依赖封闭的SE硬件，而是基于分布式的***设计思想。本实施例对第一DK应用的具体形式不进行限制。
第一DK应用中通常存储有应用信息和应用状态信息。其中，应用信息包括应用程序的版本、发行服务商、签名证书、注册和登录阶段涉及到的账户和密码、生物识别信息等。应用状态信息包括token信息的有效期等。此外，当第一DK应用根据用户指令开通数字钥匙服务之后，第一DK应用中还存储有第一秘钥相关信息中的脱敏信息。
在一个示例中，第一秘钥相关信息中的脱敏信息包括如表1所示的全部或者部分信息，此外还可以包括其他一些未示出的相关信息，本实施例对此不进行限制。
需要说明的是，终端设备通过数字钥匙服务控制目标设备时，终端设备相当于卡片(Card)，目标设备相当于读卡器(Reader)。因此，终端设备侧的秘钥相关信息(即第一秘钥相关信息)也可以称作卡片秘钥相关信息，目标设备侧的秘钥相关信息(即第二秘钥相关信息)也可以称作读卡器秘钥相关信息。
表1第一秘钥相关信息中的脱敏信息
在表1中，终端设备***包括终端设备和终端设备服务器，目标设备***包括目标设备和目标设备服务器。
其中，token信息是结合用户账号、密码和其它相关信息按照hash(哈希)或者密钥相关的哈希运算(hash-based message authentication code，HMAC)等计算规则生成的。终端设备登录终端设备服务器时，在访问请求中携带token信息即可进行身份认证，而无需携带账户和密码，避免了账户和密码在每次登录时都在空中传播，能够防止其他程序恶意攻击。token信息包括access token和refresh token，访问报文中通常携带的是accesstoken，但是每个token都有时效器(即有效期)，所以在access token失效后，终端设备服务器会向终端设备报错，以通知access token无效，此外还会向终端设备下发refreshtoken。基于此，第一DK应用会自动携带refresh token再次向终端设备服务器发起访问请求，在保持用户无感的同时，避免了再次获取账户和密码，以及账户和密码和在空中传输的过程。
应理解，对于一个目标设备，可能有多个终端设备均能够对目标设备进行解锁，因此，每一个终端设备均对应一个第一秘钥相关信息，且各个第一秘钥相关信息不相同。由于脱敏信息和敏感信息为第一秘钥相关信息中的一部分，因此，各个终端设备的脱敏信息各不相同，各个终端设备的敏感信息也各不相同。
第一通信单元可以向应用(例如第一DK应用)提供在终端设备上的无线通信解决方案。该第一通信单元可以是射频单元，也可以是其他通信单元。示例性的，该无线通信解决方案可以包括近距离无线通信技术(near field communication，NFC)、超宽带(ultrawide band，UWB)、蓝牙(bluetooth，BT)、低功耗蓝牙(bluetooth low energy，BLE)、调频(frequency modulation，FM)、红外技术(infrared，IR)、无线局域网(wireless localarea networks，WLAN)、蜂窝网络(cellular network，CN)等，本实施例对此不进行限制。
(2)终端设备服务器
终端设备服务器能够向终端设备提供数字钥匙服务注册与开通服务，并能够与目标设备服务器在建立可信链路之后，进行数据分享、信息交互等操作。具体参见前文描述，本实施例在此不再赘述。
(3)目标设备
参见图2所示，目标设备中设置有第二DK应用、SE和第二通信单元。
在本实施例中，第二DK应用包括相互配合的第一部分和第二部分，其中，第一部分部署在目标设备的存储器内，主要用于配置和维护第二DK应用，例如，根据目标设备服务器的通知，结合用户操作开通目标设备侧的数字钥匙服务，获得第一秘钥相关信息中的敏感信息，以及第二秘钥相关信息。第二部分部署在第二SE中，用于存储第二秘钥相关信息，与终端设备(如手机)做鉴权认证，以及控制目标设备执行预设指令(例如控制车机解锁、启动引擎等)。
在一些实施例中，该第一秘钥相关信息中的敏感信息为表2所示的部分或者全部信息，此外还可以包括其他一些未示出的相关信息，本实施例对此不进行限制。
表2第一秘钥相关信息中的敏感信息
在本实施例中，发卡阶段可以理解为，终端设备利用第一DK应用开通数字钥匙服务的阶段。认证阶段可以理解为终端设备在控制目标设备执行预设操作(例如解锁)时的身份认证阶段。
需要说明的是，第一秘钥相关信息中的脱敏信息和敏感信息可以包括一些相同的内容。例如以表1所示的脱敏信息和表2所示的敏感信息为例，脱敏信息和敏感信息中包括的相同内容可以是：卡片SE唯一标识(CardSEID)、卡片唯一标识(CardID)等。
在一些实施例中，该第二秘钥相关信息为表3所示的部分或者全部信息，此外还可以包括其他一些未示出的相关信息，本实施例对此不进行限制。应理解，一个目标设备通常仅有一组第二秘钥相关信息。
表3第二秘钥相关信息
在目标设备侧开通数字钥匙服务之后，目标设备的SE中包括防火墙、第二DK应用的第二部分和服务器应用。
其中，SE内的防火墙能够物理隔离位于防火墙两侧的应用，例如服务器应用和第二DK应用的第二部分，避免其相互之间任意访问对方的数据。但是在本实施例中，基于一些特定的协议或者规定(例如JAVA卡端操作***(JAVA CARD OS)或多操作***(MULTI OS)平台等的规定)，服务器应用和第二DK应用的第二部分可以穿过防火墙相互进行一些特定的访问(例如在相互认证过程中进行相互访问)。需要说明的是，本实施例对防火墙的类型不进行具体的限制。
第二DK应用的第二部分位于SE内的防火墙的一侧，用于作为读卡器(Reader)主动向终端设备的第一DK应用发起命令或者请求，并且第二DK应用的第二部分中存储有第二秘钥相关信息。服务器应用位于SE内的防火墙的另一侧，服务器应用包括Web服务器应用和DK服务器应用。DK服务器应用中存储有第一秘钥相关信息中的敏感信息。Web服务器应用为SE中的公共基础设施，在本实施例中，Web服务器应用可以作为服务器应答来自第一DK应用的请求，和主动推送相关状态信息，并承担着第一DK应用访问是否合理合法的风险控制任务。在一些实施例中，Web服务器应用可以采用通用的超文本传输安全协议(hyper texttransfer protocol secure，HTTPS)来进行证书互认证等。
在本实施例中，SE通常以芯片的形式存在，其能够通过加密/解密逻辑电路防止其他应用对SE数据的恶意解析攻击，保护数据安全。在一个示例中，该SE可以是嵌入式安全元件(embedded secure element，eSE)，eSE固定在终端设备的主板上，不能从主板上移除，因此也称作内置SE。在本实施例中，SE和NFC单元、BLE等元件连接，它使用NFC单元或者BLE等元件作为通向目标设备外部的网关。
第二通信单元可以向应用(例如第二DK应用、Web服务器应用、DK服务器应用等)提供在目标设备上的无线通信解决方案。目标设备通过第二通信单元可以与目标设备服务器和终端设备通信。该第二通信单元可以是射频单元，也可以是其他无线通信单元。示例性的，该无线通信解决方案可以包括NFC、UWB、BT、BLE、FM、IR、WLAN、CN等。
在终端设备和目标设备均开通数字钥匙服务之后，若用户携带终端设备靠近目标设备，或者终端设备接收到用户对目标设备的控制操作之后，终端设备可以通过NFC、BLE等无线短距通信技术，或者WLAN、CN等远距离通信技术，将第一秘钥相关信息中的脱敏信息发送给目标设备的服务器应用。终端设备将第一秘钥相关信息中的脱敏信息发送给目标设备的服务器应用。服务器应用将该脱敏信息与本地存储的敏感信息相结合，形成第一秘钥相关信息。随后，服务器应用代替第一DK应用作为卡片(Card)的角色，第二DK应用的第二部分作为读卡器(Reader)的角色，通过第一秘钥相关信息和第二秘钥相关信息相互认证。若认证成功，则第二DK应用的第二部分控制目标设备执行预设指令。以目标设备是车机为例，在终端设备和车机认证成功之后，第二DK应用的第二部分可以控制车机解锁。在车机解锁之后，用户即可打开车门，或者启动车机引擎。
综上所述，在本申请实施例提供的数字钥匙***中，第一秘钥相关信息被分为脱敏信息和敏感信息两部分，且脱敏信息存储在终端设备的第一DK应用中，敏感信息被存储在目标设备的服务器应用中。由于该数字钥匙***在提供数字钥匙服务器时无需使用终端设备的SE，因此，该数字钥匙***能够兼容不具备SE或者第一DK应用无权使用SE的终端设备，即对终端设备具有更好的兼容性。另外，由于第一秘钥相关信息的敏感信息存储在目标设备的SE内，因此，该***也能保证数字钥匙***的安全性。
下面基于图2所示的数字钥匙***，对终端设备侧和目标设备侧数字钥匙服务的注册与开通过程进行示例性说明。
图3是本申请实施例提供的数字钥匙服务注册与开通过程的示意性流程图。参见图3所示，该流程包括如下步骤S301～S316。
S301，终端设备接收第一用户操作。
终端设备在开通与注册数字钥匙服务时，首先需要下载并安装第一DK应用的APK或者调用第一DK应用的小程序或网页程序。随后，终端设备登陆第一DK应用，并获取第一用户操作，该第一用户操作用于指示终端设备开通数字钥匙服务。
以终端设备开通车机的数字钥匙为例，第一DK应用在登录成功之后可以根据用户指令显示数字钥匙开通界面，该界面中包括用于控制开通数字钥匙服务的第一控件。以图4所示的数字钥匙开通界面为例，第一控件为“创建数字钥匙”控件。终端设备在检测到用户对第一控件的操作之后，认为接收到了第一用户操作。
S302，在接收到第一用户操作之后，终端设备向终端设备服务器发送数字钥匙开通请求。
终端设备在接收到第一用户操作之后，需要通过第一DK应用执行如下操作(1)～(3)，本实施例对执行(1)和(2)的先后顺序不进行限制。
(1)第一DK应用获取用户基本信息和目标设备基本信息。以开通车机的数字钥匙为例，用户基本信息包括车主姓名、车主证件号码(例如身份证号码)、电话号码、邮箱等，目标设备基本信息包括车机型号、车机标识二维码、车机识别码(vehicle identificationnumber，VIN)等。示例性的，该用户基本信息和目标设备基本信息可以是在开通数字钥匙服务的过程中，用户在终端设备上输入的，也可以是终端设备通过终端设备服务器从目标设备服务器获取到的，本实施例对其不进行具体限制。
(2)第一DK应用生成如下内容：卡片业务公私钥对A1(简称公私钥对A1)、卡片自签名业务证书A1(简称业务证书A1)、卡片身份公私钥对B1(简称公私钥对B1)和卡片自签名身份证书B1(简称身份证书B1)。
卡片业务公私钥对A1，用于终端设备或者终端设备服务器加密/解密与业务相关的数据。
卡片自签名业务证书A1，用于校验证书合法性和恢复卡片业务公钥。
卡片身份公私钥对B1，用于终端设备或者终端设备服务器加密/解密与身份相关的数据。
卡片自签名身份证书B1，用于校验终端设备的身份和恢复卡片身份公钥。
可选的，在终端设备侧，公私钥对和证书的生成与存储可以是在专门的密钥存储中进行的，例如安卓密钥存储(Androidkeystore)。
(3)第一DK应用向终端设备服务器发送数字钥匙开通请求。
可选的，第一DK应用可以基于HTTPS向终端设备服务器发送数字钥匙开通请求。该数字钥匙开通请求中携带公私钥对A1中的公钥、公私钥对B1中的公钥、卡片自签名业务证书A1、卡片自签名身份证书B1、用户基本信息、目标设备基本信息等信息。
S303，终端设备服务器根据数字钥匙开通请求向终端设备发送第一响应消息。
终端设备服务器在接收到数字钥匙开通请求之后，先验证其中携带的卡片自签名身份证书B1，并在验证通过之后在该卡片自签名身份证书B1中添加核验标识，生成终端设备***认证证书B1_1(简称卡片身份认证证书B1_1，或认证证书B1_1)。该卡片身份认证证书B1_1用于表示该终端设备的身份经过了终端设备服务器的身份认证。随后，终端设备服务器向终端设备的第一DK应用发送第一响应消息，该第一响应消息中包括该卡片身份认证证书B1_1。该第一响应消息用于表示终端设备服务器已接收并处理数字钥匙开通请求，并且终端设备的身份经过了终端设备服务器的认证。
S304，终端设备服务器根据数字钥匙开通请求向目标设备服务器发送注册信息。
在本实施例中，注册信息包括卡片身份认证证书B1_1、Token、用户基本信息和目标设备基本信息等。其中，认证证书B1_1可参见S303的相关描述。Token是用户注册或首次登陆阶段，终端设备服务器根据用户的账号和密码等信息产生的，用于后续鉴权本次会话合理合法的字段。用户基本信息和目标设备基本信息可参见S302的相关描述。
S305，目标设备服务器根据注册信息确定第一秘钥相关信息。
目标设备服务器在接收到注册信息之后，需要根据三部分信息中的部分或者全部确定第一秘钥相关信息。其中，第一部分信息为目标设备服务器本地生成的信息，第二部分信息为目标设备服务器从终端设备服务器接收到的信息，第三部分信息为目标设备服务器从本地的秘钥池中调用的静态信息。下面对其进行具体的说明。
(1)第一部分信息
目标设备服务器在接收到注册信息之后需要在本地生成第一部分信息，第一部分信息包括但不限于：卡片业务公私钥对A2(简称公私钥对A2)、卡片业务证书A2(简称业务证书A2)、读卡器身份公私钥对B2(简称公私钥对B2)、读卡器身份证书B2(简称身份证书B2)、卡片身份认证证书B1_2、随机盐值A、随机盐值B、卡片计数器(CardATC)、卡片交易认证随机数(CardRnd)等。本实施例对第一部分信息的具体内容，以及生成第一部分信息中各个信息的先后顺序不进行限制。
卡片业务公私钥对A2，用于目标设备服务器加密/解密与业务相关的数据。
卡片业务证书A2，用于验证业务证书合法性和恢复卡片业务公钥A2。
读卡器身份公私钥对B2，用于目标设备或者目标设备服务器加密/解密与身份相关的数据。
读卡器身份证书B2，用于校验目标设备的身份和恢复读卡器身份公钥。
卡片身份认证证书B1_2，是目标设备服务器在对卡片身份认证证书B1_1校验通过之后，从卡片身份认证证书B1_1恢复卡片身份公钥后签名生成。可以理解，身份认证证书B1_2是卡片自签名身份证书B1经过终端设备服务器和目标设备服务器的双重认证之后得到的，其代表了终端设备的身份得到了终端设备服务器和目标设备服务器的双重认可。
随机盐值A和随机盐值B，用于对脱敏数据进行加密/解密。
卡片计数器(CardATC)，每进行一次认证之后数值增加N，N≥1且为整数。
卡片交易认证随机数(CardRnd)，用于在终端设备和目标设备认证的过程中参与加密/解密。
(2)第二部分信息
第二部分信息为目标设备服务器从终端设备服务器接收到的信息，其中包括：卡片身份认证证书B1_1、Token、用户基本信息、目标设备基本信息等。各个信息的具体内容请参见前文描述，本实施例在此不再赘述。
(3)第三部分信息
第三部分信息为目标设备服务器根据终端设备的Token、卡片唯一标识(CardID)等参数从秘钥池中调用的静态信息。应理解，目标设备服务器可能同时服务于多个目标设备，且针对每一个目标设备，终端设备中可能都存储有用于开通车钥匙服务的信息(即该第三部分信息)。因此，目标设备服务器需要根据Token、卡片唯一标识(CardID)等参数从秘钥池中调用对应的第三部分信息。
示例性的，在本实施例中，该第三部分信息包括以下内容中的至少一种：
卡片SE唯一标识(CardSEID)，用于唯一标识终端设备的SE。
卡片唯一标识(CardID)，用于唯一标识终端设备。
卡片用于认证阶段的扩展字段(CardAuthRFU)，包括一些附加认证信息，例如手机号码、所属地等。
卡片秘钥(CardSecret)，用于认证过程中的加密/解密。
可选的，卡片私有信息(CardPrivate Info)，可以包括一些用户的相关信息。
目标设备服务根据第一部分信息、第二部分信息和第三部分信息中的部分或者全部信息，生成第一秘钥相关信息。示例性的，该第一秘钥相关信息可以如表1和表2合并后的部分或者全部信息，此外还可以包括其他一些未示出的相关信息，本实施例对此不进行限制。
S306，目标设备服务器将第一秘钥相关信息中的脱敏信息发送给终端设备服务器。
在一个示例中，该第一秘钥相关信息中的脱敏信息可以为表3所示的部分或者全部信息，此外还可以包括其他一些未示出的相关信息，本实施例对此不进行限制。目标设备服务器在向终端设备服务器发送脱敏信息时，需要对脱敏信息进行加密。
当目标设备服务器通过加密的方式向终端设备服务器发送该脱敏信息时，在一个示例中，目标设备服务器可以依次对脱敏信息进行第一次加密和第二次加密。在第一次加密过程中，目标设备服务器使用卡片业务公私钥对A2中的公钥加密脱敏数据。在第二次加密过程中，目标设备服务器首先根据预设的查找版本、批次和索引信息，从秘钥池中查找到主个人化保护秘钥mkey；随后，使用Token作为分散因子从主个人化保护秘钥mkey中分散出分散个人化保护秘钥skey；最后，使用skey对脱敏信息进行加密。
需要说明的是，主个人化保护秘钥mkey和分散个人化保护秘钥skey都是用来加密/解密第一秘钥相关信息的，其中，mkey为根秘钥，skey为子秘钥。
S307，终端设备服务器对第一秘钥相关信息中的脱敏数据加密之后，将其发送给终端设备。
终端设备服务器在向终端设备发送脱敏信息时，需要对脱敏信息进行加密。示例性的，在脱敏信息已经过两次加密的基础上(具体见S306的相关描述)，终端设备服务器可以使用卡片自签名业务证书A1对脱敏信息进行第三次加密，并将经过三次加密的脱敏数据发送给终端设备。
S308，终端设备存储第一秘钥相关信息中的脱敏信息。
在一些实施例中，终端设备可以将第一秘钥相关信息中的脱敏信息存储在第一DK应用的轻型数据库(SQlite)中，其存储路径可以为“/data/data/<package name>/database/.db”。
由于一个终端设备能够针对多个目标设备开启数字钥匙服务，因此，一个终端设备可能对应多个第一秘钥相关信息。可以理解，一个终端设备可能对应多个第一秘钥相关信息中的脱敏信息。因此，终端在存储第一秘钥相关信息中的脱敏信息时，需要建立脱敏信息与读卡器唯一标识(Reader ID)、读卡器类别(Reader Type)的映射关系，以便后续在控制目标设备时调用。
S309，终端设备通过终端设备服务器向目标设备服务器发送第一开通成功通知。
该第一开通成功通知用于指示终端设备侧的数字钥匙服务已开通成功。
通过上述步骤S301～S309，在终端设备从目标设备服务器获取并存储脱敏数据之后，终端设备侧的数字钥匙服务开通成功。
下面对目标设备开通数字钥匙服务的过程进行具体的说明。在一些实施例中，目标设备服务器在接收到终端设备发送的第一开通成功通知之后(即在S309之后)，指示车机开通数字钥匙服务。在另一些实施例中，目标设备服务器在获取到第一秘钥相关信息之后(即在S305之后)，指示车机开通数字钥匙服务。该过程具体包括如下S310～S316。
S310，目标设备根据用户指令在SE内的防火墙的一侧安装第二DK应用的第二部分。
在本实施例中，目标设备和终端设备需要登录相同的账号(例如华为账号、手机号码、邮箱地址等)以共享数据。由于目标设备服务器中已经生成了第一秘钥相关信息(可参见S305)，因此，目标设备在登录与终端设备相同的账号之后，目标设备即可从目标设备服务器获取到前文示出的第一秘钥相关信息，并指示第二DK应用中预设的第一部分提示并引导用户开通目标设备侧的数字钥匙服务(可参见图5所示)。
目标设备在接收到用户输入的数字钥匙开通指令之后，目标设备打开与目标设备服务器传输数据的安全通道，通过该安全通道安装辅助安全域(supplementary securitydomain，SSD)，并通过该安全通道在SSD中下载并安装第二DK应用的第二部分。目标设备在将第二DK应用的第二部分安装成功之后向目标设备服务器发送第二响应消息，以向目标设备服务器通知第二DK应用的第二部分已安装成功。
S311，目标设备服务器向目标设备发送主数字钥匙和第二秘钥相关信息。
在本实施例中，目标设备服务器针对每一个目标设备均在秘钥池中预设有对应的第二秘钥相关信息。基于此，示例性的，目标设备服务器在检测到第二DK应用的第二部分安装成功之后，首先，目标设备服务器根据读卡器标识(ReaderID)从秘钥池中获取到第二秘钥相关信息。随后，目标设备服务器根据预设的查找版本、批次和索引信息，从秘钥池中查找到主数字钥匙mkey1～mkey3。最后，目标设备服务器并将主数字钥匙mkey1～mkey3和第二秘钥相关信息加密后通过安全通路后发送给目标设备。
在一个示例中，该第二秘钥相关信息可以为表2所示的部分或者全部信息，此外还可以包括其他一些未示出的相关信息，本实施例对此不进行限制。
此外，在mkey1～mkey3中，mkey1为目标设备鉴权终端设备时用到的认证密钥，mkey2为目标设备本地更新数据时用到的加密密钥，mkey3为目标设备本地更新数据时用到的认证密钥。
S312，目标设备将主数字钥匙和第二秘钥相关信息存储在第二DK应用内。
具体地，目标设备接收并解密第二秘钥相关信息和主数字钥匙mkey1～mkey3之后，将第二秘钥相关信息和主数字钥匙mkey1～mkey3存储在第二DK应用的第二部分内。
S313，目标设备在SE内的防火墙的另一侧安装服务器应用。
服务器应用包括DK服务器应用和Web服务器应用。在本实施例中，目标设备可以通过安全通道下载并安装DK服务器应用。此外，Web服务器应用是SE内的公共基础设备，其可以是目标设备在出厂时预装，也可以是在出厂之后，根据用户指令安装和更新的。
S314，目标设备服务器向目标设备发送第一秘钥相关信息中的敏感信息和第一信息。
在本实施例中，该第一秘钥相关信息中的敏感信息可以为表2所示的部分或者全部信息，此外还可以包括其他一些未示出的相关信息，本实施例对此不进行限制。
在本实施例中，第一信息包括卡片业务公私钥对A2、卡片业务证书A2、读卡器身份公私钥对B2、读卡器身份证书B2、卡片计数器(CardATC)、卡片交易认证随机数(CardRnd)、随机盐值A、随机盐值B、Token、分散个人化保护秘钥skey、分散数字钥匙skey1～skey3等信息。其中，基于前文描述可知，卡片业务公私钥对A2、卡片业务证书A2、读卡器身份公私钥对B2、读卡器身份证书B2、加密因子A、交易因子B是目标设备服务器中已有的信息。而分散个人化保护秘钥skey、分散数字钥匙skey1～skey3等信息需要由目标设备服务器确定。
示例性的，目标设备服务器可以根据预设的查找版本、批次和索引信息，从秘钥池中确定主个人化保护秘钥mkey和主数字钥匙mkey1～mkey3，使用Token作为分散因子即可从主个人化保护秘钥mkey中分散出分散个人化保护秘钥skey，使用Token作为分散因子即可从主数字钥匙mkey1～mkey3中分散出分散数字钥匙skey1～skey3。
目标设备服务器在向目标设备发送第一秘钥相关信息中的敏感信息时，需要对该敏感信息进行加密，并通过安全通道发送。
最后，目标设备服务器向目标设备发送第一秘钥相关信息中的脱敏信息和第一信息。
S315，目标设备将第一秘钥相关信息中的敏感信息以及第一信息存储在服务器应用中。
具体地，目标设备可以将第一秘钥相关信息中的敏感信息以及第一信息存储在DK服务器应用和或Web服务器应用中。
S316，目标设备向目标设备服务器发送第二开通成功通知。
该第二开通成功通知用于指示目标设备侧的数字钥匙服务已开通成功。
综上所述，通过上述步骤S310～S316，目标设备从目标设备服务器下载并安装第二DK应用的第二部分、在第二DK应用的第二部分内写入第二秘钥相关信息，以及从目标设备服务器下载并安装DK服务器应用、在DK服务器应用内写入第一秘钥相关信息中的敏感信息和第一信息之后，目标设备侧的数字钥匙服务开通成功。
在终端设备和目标设备均开通数字钥匙服务之后，终端设备便可以通过NFC、BLE、UWB、WLAN或者NC等通信技术与目标设备通信，从而控制目标设备执行预设指令，例如控制车机解锁。下面结合NFC、BLE对其进行示例性说明。
(一)基于NFC通信技术解锁目标设备
图6是本申请的一个实施例提供的目标设备解锁的示意性流程图，涉及终端设备和目标设备之间通过NFC技术通信以控制目标设备的过程。该流程具体包括如下步骤S600～S618。
S600，终端设备的第一通信单元和目标设备的第二通信单元之间建立底层无线连接。
在一些实施例中，终端设备的第一通信单元和目标设备的第二通信单元之间可以通过国际标准化组织(international organization for standardization，ISO)定制的ISO14443协议，即非接触式IC卡标准(Contactless card standards)协议建立底层的无线连接。本实施例对其具体过程不进行赘述。
S601，在满足第一预设条件后，第二通信单元向第二DK应用发送信息获取命令，该信息获取命令用于获取目标设备的第二身份校验信息。
在一些实施例中，第二通信单元在检测到满足第一预设条件(比如检测到终端设备与目标设备的距离在预设范围)后，发送信息获取命令给第二DK应用，以通知第二DK应用发送第二身份校验信息给第二通信单元。
在本实施例中，第一预设条件为终端设备与目标设备的距离在预设范围内。或者，终端设备获取到第二用户操作，该第二用户操作用于控制目标设备执行预设指令，例如开锁、解锁、打开车机空调等。
在一些实施例中，该信息获取命令也可以称作是获取处理数据(get processdata，GPD)命令，或者GPD组装命令。该信息获取命令用于获取目标设备的第二身份校验信息，该目标设备的第二身份校验信息可以是第二秘钥相关信息中的部分内容，例如可以是读卡器类型(ReaderType)、目标设备标识(ReaderID)、读卡器身份证书(ReaderCertificate)等。
S602，第二DK应用向第二通信单元发送目标设备的第二身份校验信息。
第二身份校验信息是第二DK应用中预设的参数，当第二DK应用接收到信息获取命令之后，向第二通信单元发送第二身份校验信息。
S603，第二通信单元向第一DK应用发送目标设备的第二身份校验信息。
具体地，第二通信单元可以通过第一通信单元向第一DK应用发送目标设备的第二身份校验信息。
S604，第一DK应用根据目标设备的第二身份校验信息，校验目标设备的身份是否合法。
在一些实施例中，由于终端设备可能开通了多个数字钥匙服务，因此，终端设备需要根据读卡器类型(ReaderType)、读卡器标识(ReaderID)等信息从终端设备中检索调用进行证书身份校验的秘钥和后续发送的脱敏信息。第一DK应用可以使用该秘钥校验读卡器身份证书((ReaderCertificate))是否合法。若读卡器身份证书(ReaderCertificate)不合法，则目标设备开锁失败。若读卡器身份证书(ReaderCertificate)合法，则认为目标设备的身份合法，并继续执行后续步骤。
S605，若目标设备的身份合法，则第一DK应用向第二DK应用发送终端设备的第一身份校验信息和第一秘钥相关信息中的脱敏信息。
示例性的，第一秘钥相关信息中的脱敏信息可以如表1中的部分或者全部所示，此外还可以包括一次其他为示出的信息，本实施例对此不进行限制。
示例性的，终端设备的第一身份校验信息可以包括卡片身份认证证书B1_2(CardCertificateB1_2)、Token、生物识别信息和卡片唯一标识(CardID)等参数。其中，生物识别信息包括用户的指纹信息、人脸信息、声纹信息、虹膜信息等。
第一DK应用向第二DK应用发送终端设备的第一身份校验信息和第一秘钥相关信息中的脱敏信息时，需要对其进行加密，本实施例对此不进行限制。
当第一DK应用采用加密的方式向终端设备发送脱敏信息，可选的，第一DK应用在向第二DK应用发送脱敏信息之前，可以协商出一个会话秘钥，并使用该会话秘钥对脱敏信息进行加密。示例性的，首先，第一DK应用根据卡片自签名身份证书B1(CardCertificateB1)，使用秘钥协商算法协商出第一会话秘钥，该第一会话秘钥用于加密第一DK应用中存储的脱敏信息。随后，由于第一DK应用中存储的脱敏信息依次经过了卡片业务公私钥对A2中的公钥A2、skey和卡片自签名业务证书A1三次加密，因此，第一DK应用需要先去除脱敏数据最外层的加密秘钥(即解除第三次加密)，再使用第一会话秘钥加密脱敏数据。可以理解，第一DK应用在使用第一会话秘钥加密脱敏信息之后，脱敏信息仍然有三层加密密钥。
可选的，在本实施例中，秘钥协商算法可以是迪菲-赫尔曼(Diffie-Hellman)秘钥协商算法、椭圆曲线DH(elliptic curves DH，ECDH)秘钥协商算法、临时DH秘钥协商算法(DH ephemeral，DHE)、临时椭圆曲线DH(ECDH ephemeral，ECDHE)中的任一种。
S606，第二DK应用透过SE内的防火墙向服务器应用发送第一秘钥相关信息中的脱敏信息和终端设备的第一身份校验信息。
在一些实施例中，第二DK应用在满足JAVA CARD OS或MULTI OS规定的访问规则下透过SE内的防火墙，向服务器应用发送第一秘钥相关信息中的脱敏信息和终端设备的第一身份校验信息。
S607，服务器应用根据终端设备的第一身份校验信息校验终端设备的身份是否合法。
例如，服务器应用可以根据卡片身份认证证书(CardCertificateB1_2)校验终端设备的身份是否合法；和/或，根据第一身份校验信息中的生物识别信息对应的hash值校验用户是否为车主；和/或，根据时间戳信息(Timestamp)、访问频次和信息的有效期/失效期校验数字钥匙服务是否过期。若用户不是车主，或者终端设备的身份证书校验失败，或者数字钥匙服务过期，则认为终端设备的身份不合法。
在一些实施例中，若服务器应用频繁接收到终端设备的数字钥匙信息，则认为本次开锁为一次风险事故，因此，服务器应用也可以确定终端设备的第一身份校验信息不合法，并确定开锁失败。
服务器应用在确定终端设备的身份合法之后，可以通过第二DK应用向第一DK应用发送第三响应消息，该第三响应消息用于向第一DK应用通知终端设备的身份校验已通过。示例性的，该第三响应消息可以是一个应用协议数据单元(application protocol DataUnit，APDU)授权信息，简称AUTH APDU。
需要说明的是，在目标设备的SE内，由于第二DK应用的第二部分和服务器应用之间设置有防火墙，因此，服务器应用需要在满足JAVA CARD OS或MULTIOS等规定的访问规则下穿过防火墙，通过第二DK应用向第一DK应用发送该第三响应消息。
此外，终端设备的第一DK应用在接收到第三响应信息之后，需要向依次通过第一通信单元、第二通信单元、第二DK应用向服务器应用发送第二信息。示例性的，该第二信息包括：第一DK应用接收第三响应消息的时间戳、第一DK应用生成卡片业务随机数(CardNonce)、第一DK应用本地取预存的Token和卡片唯一标识(CardID)等。
在本实施例中，服务器应用在向第一DK应用发送第三响应消息之后，可以通过第二信息从第一DK应用处获得卡片业务随机数(CardNonce)。在后续过程中(可参见S609)，服务器应用使用本地生成的卡片交易认证随机数(CardRnd)和从第一DK应用获得的随机数(CardNonce)，按照异或运算或其它算法规则新生成的随机数，该新生成的随机数用于终端设备和设备的相互认证，能够保证认证的可靠性。
第一DK应用在向服务器应用发送第二信息时可以对第二信息加密，也可以不对第二信息加密，本实施例对此不进行限制。
S608，若终端设备的身份合法，则服务器应用将本地存储的敏感信息与接收到的脱敏信息进行合并为第一秘钥相关信息。
由于目标设备在开通数字钥匙服务的过程中，本地已存储有敏感信息(可参见S315)，因此，服务器应用在对脱敏信息解密之后，即可将脱敏信息与本次存储的敏感信息进行结合，获得第一秘钥相关信息。
在一些实施例中，若终端设备的身份合法，服务器应用可以在向终端设备发送第三响应信息，并接收到第一DK应用返回的第二信息之后，将本地存储的敏感信息与接收到的脱敏信息合并，获得第一秘钥相关信息。
在另一些实施例中，若终端设备的身份合法，服务器应用也可以在向终端设备发送第三响应信息，并接收到第一DK应用返回的第二信息之前，将本地存储的敏感信息与接收到的脱敏信息合并，获得第一秘钥相关信息。
由于服务器应用接收到的脱敏信息是加密信息，则服务器应用将脱敏信息解密之后，才能将其与敏感信息合并，获得第一秘钥相关信息。
在一个示例中，若服务器应用接收到的脱敏信息依次经过卡片业务公私钥对A2中的公钥A2、分散个人化保护秘钥skey和第一会话秘钥依次分别进行了三次加密，那么服务器应用需要依次使用第一会话秘钥、分散个人化保护秘钥skey和卡片业务公私钥对A2中的公钥A2对脱敏数据依次进行解密。
具体地，首先，服务器应用使用与终端设备相同的秘钥协商算法协商出第一会话秘钥，并使用该第一会话秘钥对脱敏信息进行第一次解密。其次，服务器应用根据Token查找分散个人化保护秘钥skey，并使用skey对脱敏信息进行第二次解密。最后，服务器应用根据Token查找卡片业务公私钥对A2，并使用卡片业务公私钥对A2对脱敏信息进行第三次解密，获得脱敏信息的明文。
需要说明的是，在目标设备开通数字钥匙应用的过程中，个人化保护秘钥skey和卡片业务公私钥对A2已存储至服务器应用内(可参见S315)。因此，在上述解密过程中，服务器应用根据Token直接在本地查找即可。
由于多个不同的终端设备均可以针对同一个目标设备开通数字钥匙服务，那么，可以理解的是，该目标设备中可能会存储有多组不同的对应终端设备的敏感信息。基于此，服务器应用在对脱敏信息解密之后，需要先根据Token，和/或，卡片/读卡器唯一标识(ReaderID、ReaderType、CardID、CardSEID)从本地检索和获取对应的敏感信息，才能将脱敏信息和敏感信息组合，获得第一秘钥相关信息。应该理解存储于设备终端的脱敏信息不是唯一的，可以对应多个目标设备；相似的，目标设备中服务器应用存储的敏感信息不是唯一的，可以对应多个终端设备。所以在第一秘钥相关信息合并组合时需要正确搜索和配对。
基于上述S601～S608，目标设备侧的应用服务器获得完整的第一秘钥相关信息。也就是说，在S608之后，在目标设备SE内的防火墙的两侧，服务器应用中存储有第一秘钥相关信息，第二DK应用的第二部分存储有第二秘钥相关信息。基于此，服务器应用就可以代替终端设备的角色，第二DK应用就可以替代目标设备的角色，通过服务器应用和第二DK应用的交互对终端设备和目标设备进行相互认证。下面结合S609～S618对其进行具体说明。
S609，服务器应用将第一秘钥相关信息中的卡片认证信息发送给第二DK应用。
在一个示例中，服务器应用可以通过如下操作向第二DK应用发送卡片认证信息：
首先，服务器应用根据第一秘钥相关信息确定卡片认证信息。在一个示例中，卡片认证信息可以包括第一秘钥相关信息中的全部或者部分信息。例如，卡片认证信息可以包括新的卡片交易认证随机数(CardRnd_new)、卡片计数器(CardATC)等。其中，该新的卡片交易认证随机数(CardRnd_new)是服务器应用使用本地生成的卡片交易认证随机数(CardRnd)和终端设备的第一DK应用发送的随机数(CardNonce)按照异或运算或其它算法规则新生成的随机数。
其次，服务器应用根据Token或者读卡器类型(Reader Type)从本地检索出数字钥匙秘钥skey1～skey3，并使用Token对skey1～skey3进行分散，获得第二会话秘钥。
最后，服务器应用使用第二会话秘钥加密卡片认证信息形成加密字段，并将加密后的卡片认证信息发送给第二DK应用。应理解，该加密字段中携带卡片认证信息。
S610，第二DK应用根据卡片认证信息和第二秘钥相关信息生成验证请求密文。
由于第二DK应用接收到的卡片认证信息是在服务器应用中经过第二会话秘钥加密的，因此，第二DK应用在根据卡片认证信息和第二秘钥相关信息生成验证请求密文之前，首先需要生成相同的第二会话秘钥，并使用第二会话秘钥对卡片认证信息进行解密。
在一个示例中，第二DK应用可以通过如下操作(1)～(3)生成第二会话秘钥。
(1)第二DK应用根据卡片SE唯一标识(CardSEID)查找出对应第二秘钥相关信息，并从第二秘钥相关信息中确定出根秘钥(RootSecret)。
(2)第二DK应用根据卡片认证信息中携带的卡片SE唯一标识(CardSEID)等和用于认证阶段的扩展字段(CardAuthRFU)，从根秘钥(RootSecret)中分散出卡片秘钥(CardSecret)。该卡片秘钥(Card Secret)与第一秘钥相关信息中的卡片秘钥(Card Secret)相同。
(3)第二DK应用根据子秘钥Card Secret产生第二会话秘钥。
第二DK应用在生成第二会话秘钥之后，使用第二会话秘钥解密接收到的加密的卡片认证信息，得到明文的卡片认证信息，例如，卡片交易认证随机数(CardRnd)、卡片计数器(CardATC)等。
最后，第二DK应用根据加密算法(例如AES128_CBC算法)，使用第二会话秘钥加密卡片计数器(Card ATC)和卡片随机数(CardRnd)等信息，生成验证请求密文。该验证请求密文用于请求认证终端设备。
可选的，服务器应用还可以将读卡器随机数(ReaderRnd)添加在卡片认证信息中发送给第二DK应用。第二DK应用对加密字段进行解密即可获得该读卡器随机数(ReaderRnd)。若第一认证信息中携带的读卡器随机数(ReaderRnd)与第二DK应用中存储的读卡器随机数(ReaderRnd)相同，那么，第二DK应用执行生成验证请求密文的操作。若第一认证信息中携带的读卡器随机数(ReaderRnd)与第二DK应用中存储的读卡器随机数(ReaderRnd)不相同，那么第二DK应用对终端设备的校验失败，终端设备对目标设备的控制也失败，目标设备不再执行后续控制流程。
S611，第二DK应用透过SE内的防火墙向服务器应用发送验证请求密文。
在一些实施例中，第二DK应用在满足JAVA CARD OS或MULTIOS规定的访问规则下透过SE内的防火墙向DK服务器应用发送验证请求密文。
S612，服务器应用根据验证请求密文认证目标设备。
服务器应用在接收到验证请求密文之后，根据验证请求密文认证目标设备。
在一个示例中，服务器应用可以使用前期确定的第二会话秘钥对验证请求密文进行解密，获得验证请求明文，该验证请求明文中包括会话初始向量(Session IV)、卡片计数器(Card ATC)、用于认证阶段的扩展字段(ReaderAuthRFU)和卡片随机数(CardRnd)等信息。
若验证请求明文中的卡片随机数(CardRnd)和服务器应用本地的卡片随机数(CardRnd)相同，那么服务器应用认为目标设备认证通过。若验证请求明文中的卡片随机数(CardRnd)和服务器应用本地的卡片随机数(CardRnd)不同，那么，服务器应用认为目标设备认证失败，本次终端设备对目标设备的控制结束。
S613，若目标设备认证通过，则服务器应用透过SE内的防火墙向第二DK应用发送应答密文。
服务器应用在对目标设备认证通过之后，需要根据第二DK应用生成验证请求密文的加密算法，再生成一个应答密文，并给卡片计数器(CardATC)加N。该应答密文用于第二DK应用对终端设备进行认证。
在一个示例中，服务器应用可以根据加密算法(例如AES128_CBC算法)，使用第二会话秘钥加密会话初始向量(Session IV)，以及加密通过算法(例如SHA256算法)预先加密的卡片用于认证阶段的扩展字段(CardAuthRFU)、读卡器用于认证阶段的扩展字段(ReaderAuthRFU)、读卡器随机数(ReaderRnd)等信息，产生应答密文。可以理解，在一个示例中，CardAuthRFU、ReaderAuthRFU和ReaderRnd经过了SHA256算法和AES128_CBC算法两次加密。
S614，第二DK应用根据应答密文认证终端设备。
在一个示例中，由于SHA256算法是不可逆的，这就导致第二DK应用无法解密接收到的应答密文(可称作应答密文1)，因此，第二DK应用在接收到应答密文之后，可以采用与服务器应用相同的方法生成本地的应答密文(应答密文2)，并比较应答密文1和应答密文2是否相同。若应答密文1和应答密文2相同，则说明终端设备认证通过。若应答密文1和应答密文2不相同，则说明终端设备认证失败，终端设备对目标设备的控制失败。
S615，若终端设备认证通过，则第二DK应用向第一DK应用发送更新后的第一秘钥相关信息中脱敏信息(简称更新后的脱敏信息)。
在第二DK应用和服务器应用通过交互，完成终端设备和目标设备的相互认证之后，在第一秘钥相关信息的脱敏信息中，卡片交易认证随机数(CardRnd)、卡片交易认证计数器(CardATC)等参数都会更新。因此，第二DK应用需要向第一DK应用发送更新后的脱敏信息。
在一个示例中，第二DK应用在确定更新后的脱敏信息之后，控制服务器应用执行如下操作：首先，服务器应用根据秘钥协商算法协商出第三会话秘钥，并根据Token查找分散个人化保护秘钥skey和卡片业务公私钥对A2。随后，服务器应用使用卡片业务公私钥对A2中的公钥对更新后的脱敏数据进行第一次加密，使用分散个人化保护秘钥skey对脱敏数据进行第二次加密，使用第三会话秘钥对脱敏数据进行第三次加密。最后，服务器应用将经过三次加密后的脱敏信息发送给第二DK应用。第二DK应用透过SE内的防火墙向DK服务器应用发送更新后的脱敏信息。
可选的，该秘钥协商算法可以是DH、ECDH、DHE或者ECDHE中的任一种，本实施例对此不进行限制。
S616，第一DK应用存储更新后的脱敏信息。
第一DK应用对更新后的脱敏信息进行解密之后，存储更新后的脱敏信息。
在一些实施例中，第一DK应用在接收到更新后的脱敏信息之后，首先根据与S614中相同的秘钥协商算法协商出第三会话秘钥，并根据第三会话秘钥解除更新后的脱敏信息的第三层加密秘钥。随后，第一DK应用使用Androidkeystore的秘钥给更新后的脱敏信息重新进行第三层加密。最后，第一DK应用存储更新后的脱敏信息。在一些实施例中，终端设备可以将更新后的脱敏信息存储在轻型数据库(SQlite)中，其存储路径可以为“/data/data/<package name>/database/.db”。
S617，第一DK应用向第二DK应用发送第四响应消息，该第四响应消息用于指示更新后的脱敏信息以存储完成。
S618，第二DK应用控制目标设备执行预设指令。
需要说明的是，在本实施例中，在S614之后，可先执行S615～S617再执行S618(即先更新脱敏信息，再控制目标设备执行预设指令)，也可以先执行S618再执行S615～S617(即先控制目标设备执行预设指令，再更新脱敏信息)，本实施例对此不进行限制。
以目标设备是车机为例，目标设备解锁之后，目标设备即可根据用户操作打开车门或者启动车机引擎。
(二)基于BLE通信技术解锁目标设备
图7是本申请另一个实施例提供的目标设备开锁的示意性流程图，涉及终端设备和目标设备之间通过BLE技术通信以解锁目标设备的过程。在图7中，终端设备包括第一DK应用和第一通信单元，目标设备包括第二通信单元和SE，SE包括第二DK应用和服务器应用。该流程具体包括如下步骤S700～S716。
S700，第一通信单元和第二通信单元建立BLE连接，并建立终端设备和目标设备的个人局域网(personal area network，PAN)。
第一通信单元和第二通信单元建立BLE连接之后，可以通过BLE通用属性规范(BLEgeneric attribute profile，BLE GATT)协议建立终端设备和目标设备的基于HTTPS的PAN。基于此，下述第一DK应用在向目标设备发送消息时，皆使用HTTPS协议承载消息内容。这将使得第一DK应用可以直接访问目标设备中服务器应用，不需要第二DK应用的中转。
S701，在满足第一预设条件后，第一DK应用向服务器应用发送终端设备的第一身份校验信息。
在本实施例中，第一预设条件为终端设备与目标设备的距离在预设范围内。或者，终端设备获取到第二用户操作，该第二用户操作用于控制目标设备执行预设指令，例如开锁、解锁、打开车机空调等。
示例性的，终端设备的第一身份校验信息可以包括卡片身份认证证书B1_2(CardCertificateB1_2)、Token、生物识别信息和卡片唯一标识(CardID)等参数。其中，生物识别信息包括用户的指纹信息、人脸信息、声纹信息、虹膜信息等。
S702，服务器应用根据第一身份校验信息，校验终端设备的身份是否合法。S702可参见S607所示，本实施例在此不再赘述。
S703，若终端设备的身份合法，则服务器应用向第一DK应用发送目标设备的第二身份校验信息。
示例性的，第二身份校验信息包括可以是读卡器类型(ReaderType)、读卡器标识(ReaderID)、读卡器身份证书(ReaderCertificate)。
S704，第一DK应用根据目标设备的第二身份校验信息，校验目标设备的身份是否合法。
在本实施例中，S704的具体内容可参见S604所示，本实施例在此不再赘述。
可选的，第一DK应用在确定目标设备的身份合法之后，向目标设备的第二DK应用发送校验成功通知。
需要说明的是，本实施例对校验终端设备和目标设备身份的先后顺序不进行限制。例如，如S701～S704所示，先校验终端设备的身份，再校验目标设备的身份。或者，也可以先校验目标设备的身份，再校验终端设备的身份。
值得说明的是，若先校验目标设备的身份，在目标设备的身份校验通过之后，终端设备就可以将第一秘钥相关信息中的脱敏信息和终端设备的身份校验信息一起发送给目标设备，可以减少终端设备和目标设备之间的交互流程。
经过上述S701～S704，终端设备和目标设备即可相互校验对方的身份是否合法。若双方的身份均合法，则继续执行后续步骤。
S705，若目标设备的身份合法，则第一DK应用向服务器应用发送第一秘钥相关信息中的脱敏信息。
在一个示例中，若目标设备的身份合法，第二DK应用在接收到第一DK应用发送的校验成功通知之后，向服务器应用发送GPD报文，GPD报文中携带读卡器类型(ReaderType)、读卡器标识(ReaderID)、读卡器用于生成会话秘钥的扩展字段(ReaderSessionRFU)、读卡器随机数(ReaderRnd)等信息。服务器应用按照HTTPS协议将GPD报文打包，再将其发送至第一DK应用。
第一DK应用根据读卡器类型(ReaderType)、读卡器标识(ReaderID)等信息从第一DK应用内调取对应的脱敏信息。此外，第一DK应用需要使用预设的秘钥协商算法，根据读卡器用于生成会话秘钥的扩展字段(ReaderSessionRFU)、读卡器随机数(ReaderRnd)等信息协商出第四会话秘钥。该预设的秘钥协商算法可以是DH、ECDH、DHE或者ECDHE中的任一种。
基于前文描述可知，脱敏信息是依次经过了卡片业务公钥A2、分散个人化保护秘钥skey和卡片自签名业务证书A1三次加密，因此，第一DK应用需要先使用卡片自签名业务证书A1去使用第一会话秘钥去除脱敏数据最外层的加密秘钥，即解除第三次加密，再使用第四会话秘钥加密脱敏数据。可以理解，第一DK应用在使用第四会话秘钥加密脱敏信息之后，脱敏信息仍然有三层加密密钥。最后，第一DK应用向服务器应用发送脱敏信息。
S706，服务器应用将本地存储的敏感信息与接收到的脱敏信息进行合并，获得第一秘钥相关信息。
S707，服务器应用将第一秘钥相关信息中的卡片认证信息发送给第二DK应用。
S708，第二DK应用根据卡片认证信息和第二秘钥相关信息生成验证请求密文。
S709，第二DK应用透过SE内的防火墙向服务器应用发送验证请求密文。
S710，服务器应用根据验证请求密文认证目标设备。
S711，若目标设备认证通过，则服务器应用透过SE内的防火墙向第二DK应用发送应答密文。
S712，第二DK应用根据应答密文认证终端设备。
S713，若终端设备认证通过，则第二DK应用向第一DK应用发送更新后的脱敏信息。
S714，第一DK应用存储更新后的脱敏信息。
S715，第一DK应用向第二DK应用发送第四响应消息，该第四响应消息用于指示更新后的脱敏信息以存储完成。
S716，第二DK应用控制目标设备解锁。目标设备解锁之后，目标设备即可根据用户操作打开车门或者启动车机引擎。
在本实施例中，步骤S706～S716的具体实施过程，请参见S608～S618中记载的相关内容，本实施例在此不再赘述。另外，与S608～S618不同的是，在S706～S716中，终端设备和目标设备之间是通过HTTPS协议通信的。
基于上述描述可知，通过本申请实施例提供的设备控制方法，终端设备在解锁目标设备时，将终端设备存储的第一密钥相关信息中的脱敏信息发送给目标设备，由目标设备将脱敏信息与本地的敏感信息结合后获得完整的第一密钥相关信息，并根据第一密钥相关信息和第二密钥相关信息对终端设备和目标设备进行鉴权，从而控制目标设备。由此可见，在终端设备不使用SE存储和保护钥匙信息的情况下，基于该类终端设备的数字钥匙仍然可以安全控制目标设备(例如解锁和启动目标设备)。
应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
基于上述各个实施例提供的设备控制方法，本申请实施例还提供如下内容。
本申请实施例提供一种终端设备，终端设备中存储有第一秘钥相关信息中的脱敏信息；第一秘钥相关信息中的敏感信息存储于目标设备内，终端设备被配置为执行上述各个实施例中终端设备所执行的设备控制方法。
本申请实施例提供一种目标设备，目标设备中存储有第一秘钥相关信息中的敏感信息和第二秘钥相关信息，目标设备被配置为执行上述各个实施例中目标设备所执行的设备控制方法。
本申请实施例提供一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现如上述各个实施例中终端设备所执行的设备控制方法。
本申请实施例提供一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现如上述各个实施例中目标设备所执行的设备控制方法。
本申请实施例提供一种计算机程序产品，当该计算机程序产品在终端设备上运行时，使得该终端设备实现上述如各个实施例中终端设备所执行的设备控制方法。
本申请实施例提供一种计算机程序产品，当该计算机程序产品在目标设备上运行时，使得该目标设备实现上述如各个实施例中目标设备所执行的设备控制方法。
应理解，本申请实施例中提及的处理器可以是中央处理单元(centralprocessing unit，CPU)，还可以是其他通用处理器、数字信号处理器(digital signalprocessor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
还应理解，本申请实施例中提及的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double datarate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。
在本申请所提供的实施例中，各个框架或模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个框架或模块可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。
另外，在本申请各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的***、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。
以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (24)

1.一种设备控制方法，其特征在于，应用于第一设备和第二设备，所述第一设备中存储有第一秘钥相关信息中的脱敏信息；所述第二设备的安全元件内存储有所述第一秘钥相关信息中的敏感信息和第二秘钥相关信息；所述方法包括：
所述第一设备向所述第二设备发送所述脱敏信息；
所述第二设备将所述脱敏信息和所述敏感信息合并为所述第一秘钥相关信息；
所述第二设备根据所述第一秘钥相关信息和所述第二秘钥相关信息进行所述第一设备和所述第二设备的相互认证；
所述第二设备根据认证结果执行预设指令。
2.根据权利要求1所述的方法，其特征在于，所述第二设备的安全元件内设置有第二数字钥匙应用和服务器应用，所述服务器应用内存储有所述敏感信息，所述第二数字钥匙应用内存储有所述第二秘钥相关信息；所述第二设备根据所述第一秘钥相关信息和所述第二秘钥相关信息进行所述第一设备和所述第二设备的相互认证，以及，所述第二设备根据认证结果执行预设指令，包括：
所述服务器应用向所述第二数字钥匙应用发送所述第一秘钥相关信息中的卡片认证信息，所述卡片认证信息为所述第一秘钥相关信息的全部或者部分信息；
所述第二数字钥匙应用根据所述卡片认证信息和所述第二秘钥相关信息生成验证请求密文，以及，向所述服务器应用发送所述验证请求密文；
所述服务器应用根据所述验证请求密文认证所述第二设备；以及，在对所述第二设备认证通过之后，向所述第二数字钥匙应用发送应答密文；
所述第二数字钥匙应用根据所述应答密文认证所述第一设备；以及，在对所述第一设备认证通过之后，控制所述第二设备执行所述预设指令。
3.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：
所述第二设备更新所述第一秘钥相关信息，并向所述第一设备发送更新后的所述第一秘钥相关信息中的脱敏信息。
4.根据权利要求1～3任一项所述的方法，其特征在于，在所述第一设备向所述第二设备发送所述脱敏信息之前，所述方法还包括：
所述第一设备向所述第二设备发送所述第一设备的第一身份校验信息；
所述第二设备根据所述第一身份校验信息校验所述第一设备的身份是否合法；以及，若所述第一设备的身份合法，则向所述第一设备发送所述第二设备的第二身份校验信息；
所述第一设备根据所述第二身份校验信息校验所述第二设备的身份是否合法。
5.根据权利要求1～4任一项所述的方法，其特征在于，在所述第一设备向所述第二设备发送所述脱敏信息之前，所述方法还包括：
所述第一设备通过第一服务器向第二服务器发送注册信息；
所述第二服务器根据所述注册信息生成所述第一秘钥相关信息，并通过所述第一服务器向所述第一设备发送所述第一秘钥相关信息中的所述脱敏信息，向所述第二设备发送所述第一秘钥相关信息中的所述敏感信息。
6.根据权利要求1～5任一项所述的方法，其特征在于，所述第一设备向所述第二设备发送所述脱敏信息，包括：
所述第一设备在检测到第一预设条件之后，向所述第二设备发送所述脱敏信息；
其中，所述第一预设条件为，
所述第一设备与所述第二设备的距离在预设范围内；或者，
所述第一设备获取到第二用户操作，所述第二用户操作用于控制所述第二设备执行所述预设指令。
7.根据权利要求1～6任一项所述的方法，其特征在于，在所述第一设备和所述第二设备之间采用低功耗蓝牙BLE技术通信的情况下，所述第一设备和所述第二设备基于超文本传输安全协议HTTPS交互信息。
8.根据权利要求1～7任一项所述的方法，其特征在于，所述第一秘钥相关信息存储在第一数字钥匙应用内；所述第一数字钥匙应用为软件安装包中携带的应用程序，或者，应用平台的嵌套的小程序，或者网页应用程序。
9.根据权利要求1～8任一项所述的方法，其特征在于，所述敏感信息和所述第二秘钥相关信息位于所述第二设备的安全元件内，且位于所述安全元件内防火墙的两侧。
10.一种设备控制方法，应用于第一设备，其特征在于，所述第一设备中存储有第一秘钥相关信息中的脱敏信息；所述第一秘钥相关信息中的敏感信息和第二秘钥相关信息存储于第二设备的安全元件内，所述方法包括：
向所述第二设备发送所述脱敏信息；
其中，所述脱敏信息用于与所述第二设备中的所述敏感信息合并，获得所述第一秘钥相关信息；所述第一秘钥相关信息和所述第二秘钥相关信息用于由所述第二设备进行所述第一设备和所述第二设备的相互认证，以及，根据认证结果执行预设指令。
11.根据权利要求10所述的方法，其特征在于，向所述第二设备发送所述脱敏信息，包括：
与所述第二设备相互校验对方的身份是否合法；
若所述第一设备和所述第二设备的身份均合法，则向所述第二设备发送所述脱敏信息。
12.根据权利要求10或11所述的方法，其特征在于，所述向所述第二设备发送所述脱敏信息，包括：
在检测到第一预设条件之后，向所述第二设备发送所述脱敏信息；
其中，所述第一预设条件为，
所述第一设备与所述第二设备的距离在预设范围内；或者，
所述第一设备获取到第二用户操作，所述第二用户操作用于控制所述第二设备执行所述预设指令。
13.根据权利要求10～12任一项所述的方法，其特征在于，在向所述第二设备发送所述脱敏信息之前，所述方法还包括：
通过第一服务器向第二服务器发送注册信息；
通过所述第一服务器接收所述第二服务器发送的所述脱敏信息，所述脱敏信息对应的所述第一秘钥相关信息是由所述第二服务器根据所述注册信息生成的；
存储所述脱敏信息。
14.根据权利要求10～13任一项所述的方法，其特征在于，在所述第一设备和所述第二设备之间采用低功耗蓝牙BLE技术通信的情况下，所述第一设备和所述第二设备基于超文本传输安全协议HTTPS交互信息。
15.根据权利要求10～14任一项所述的方法，其特征在于，所述第一秘钥相关信息存储在第一数字钥匙应用内；所述第一数字钥匙应用为软件安装包中携带的应用程序，或者，应用平台的嵌套的小程序，或者网页应用程序。
16.一种设备控制方法，其特征在于，应用于第二设备，所述第二设备的安全元件内存储有第一秘钥相关信息中的敏感信息和第二秘钥相关信息；所述第一秘钥相关信息中的脱敏信息存储在第一设备内，所述方法包括：
接收所述第一设备发送的所述脱敏信息；
将所述脱敏信息和所述敏感信息合并为所述第一秘钥相关信息；
根据所述第一秘钥相关信息和所述第二秘钥相关信息进行所述第一设备和所述第二设备的相互认证；
根据认证结果执行预设指令。
17.根据权利要求16所述的方法，其特征在于，所述第二设备的安全元件内设置有第二数字钥匙应用和服务器应用，所述服务器应用内存储有所述敏感信息，所述第二数字钥匙应用内存储有所述第二秘钥相关信息；所述根据所述第一秘钥相关信息和所述第二秘钥相关信息进行所述第一设备和所述第二设备的相互认证，以及，根据认证结果执行预设指令，包括：
所述服务器应用向所述第二数字钥匙应用发送所述第一秘钥相关信息中的卡片认证信息，所述卡片认证信息为所述第一秘钥相关信息的全部或者部分信息；
所述第二数字钥匙应用根据所述卡片认证信息和所述第二秘钥相关信息生成验证请求密文，以及，向所述服务器应用发送所述验证请求密文；
所述服务器应用根据所述验证请求密文认证所述第二设备；以及，在对所述第二设备认证通过之后，向所述第二数字钥匙应用发送应答密文；
所述第二数字钥匙应用根据所述应答密文认证所述第一设备；以及，在对所述第一设备认证通过之后，控制所述第二设备执行所述预设指令。
18.根据权利要求16或17所述的方法，其特征在于，所述方法还包括：
更新所述第一秘钥相关信息，并向所述第一设备发送更新后的所述第一秘钥相关信息中的脱敏信息。
19.根据权利要求16～18任一项所述的方法，其特征在于，在所述接收所述第一设备发送的所述脱敏信息之前，所述方法还包括：
与所述第一设备相互校验对方的身份是否合法；
在确定所述第一设备和所述第二设备的身份均合法之后，接收所述第一设备发送的所述脱敏信息。
20.根据权利要求16～19任一项所述的方法，其特征在于，所述敏感信息和所述第二秘钥相关信息位于所述第二设备的安全元件内，且位于所述安全元件内防火墙的两侧。
21.一种分布式数字钥匙***，其特征在于，包括第一设备和第二设备，所述第一设备中存储有第一秘钥相关信息中的脱敏信息；所述第二设备的安全元件内存储有所述第一秘钥相关信息中的敏感信息和第二秘钥相关信息；所述第一设备和所述第二设备相互配合，实现上述权利要求1～9任一项所述的设备控制方法。
22.一种第一设备，其特征在于，所述第一设备中存储有第一秘钥相关信息中的脱敏信息；所述第一秘钥相关信息中的敏感信息存储于第二设备的安全元件内，所述第一设备被配置为执行如权利要求10～15任一项所述的设备控制方法。
23.一种第二设备，其特征在于，所述第二设备的安全元件内存储有所述第一秘钥相关信息中的敏感信息和第二秘钥相关信息，所述第二设备被配置为执行如权利要求16～20任一项所述的设备控制方法。
24.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现如权利要求10～15任一项所述的方法，或者如权利要求16～20任一项所述的设备控制方法。
CN202210114846.2A 2022-01-30 2022-01-30 一种设备控制方法、设备和分布式数字钥匙*** Pending CN116566594A (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202210114846.2A CN116566594A (zh) 2022-01-30 2022-01-30 一种设备控制方法、设备和分布式数字钥匙***
PCT/CN2022/139977 WO2023142773A1 (zh) 2022-01-30 2022-12-19 一种设备控制方法、设备和分布式数字钥匙***

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210114846.2A CN116566594A (zh) 2022-01-30 2022-01-30 一种设备控制方法、设备和分布式数字钥匙***

Publications (1)

Publication Number Publication Date
CN116566594A true CN116566594A (zh) 2023-08-08

Family

ID=87470367

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210114846.2A Pending CN116566594A (zh) 2022-01-30 2022-01-30 一种设备控制方法、设备和分布式数字钥匙***

Country Status (2)

Country Link
CN (1) CN116566594A (zh)
WO (1) WO2023142773A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116723508B (zh) * 2023-08-04 2023-11-14 小米汽车科技有限公司 车钥匙创建方法、装置、存储介质及***
CN117113311B (zh) * 2023-10-18 2024-03-01 紫光同芯微电子有限公司 用于终端设备身份验证的方法及装置、终端设备

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102511778B1 (ko) * 2018-03-05 2023-03-21 삼성전자주식회사 전자 디바이스 및 전자 디바이스의 디지털 키 프로비저닝 수행 방법
KR102626319B1 (ko) * 2018-05-23 2024-01-17 삼성전자주식회사 디지털 키를 저장하기 위한 방법 및 전자 디바이스
KR102545375B1 (ko) * 2018-09-14 2023-06-20 삼성전자 주식회사 액세서리를 이용하여 인증을 수행하는 전자 장치 및 전자 장치의 동작 방법
CN109558748B (zh) * 2018-11-23 2020-11-03 泰康保险集团股份有限公司 数据处理方法、装置、电子设备及存储介质
CN111835689B (zh) * 2019-04-22 2021-06-15 华为技术有限公司 数字钥匙的身份认证方法、终端设备及介质
CN110855616B (zh) * 2019-10-14 2021-11-23 中国第一汽车股份有限公司 一种数字钥匙生成***
CN111935672B (zh) * 2020-07-21 2022-10-25 捷德(中国)科技有限公司 信息读取方法、装置、***及存储介质

Also Published As

Publication number Publication date
WO2023142773A1 (zh) 2023-08-03

Similar Documents

Publication Publication Date Title
US8064598B2 (en) Apparatus, method and computer program product providing enforcement of operator lock
US10959092B2 (en) Method and system for pairing wireless mobile device with IoT device
RU2518924C2 (ru) Беспроводное устройство, способ запроса пользовательского клиента управления доступом и способ выполнения клиента управления доступом
EP2630816B1 (en) Authentication of access terminal identities in roaming networks
JP5031994B2 (ja) 権限委譲システムおよび制御装置および権限委譲方法
WO2023142773A1 (zh) 一种设备控制方法、设备和分布式数字钥匙***
US7844834B2 (en) Method and system for protecting data, related communication network and computer program product
EP3023899A1 (en) Proximity authentication system
EP1873668A1 (en) Integration of device integrity attestation into user authentication
US20050188219A1 (en) Method and a system for communication between a terminal and at least one communication equipment
TW200531493A (en) Method for authenticating applications
CN112396735B (zh) 网联汽车数字钥匙安全认证方法及装置
WO2002101981A1 (en) Method and arrangement for encrypting data transfer at an interface in mobile equipment in radio network, and mobile equipment in radio network
WO2022017314A1 (en) Information reading method, apparatus, system and storage medium
KR101716067B1 (ko) 제3자 포탈을 이용한 단말과 원격 서버 사이의 상호 인증을 위한 방법
EP3376421A1 (en) Method for authenticating a user and corresponding device, first and second servers and system
CN108352982B (zh) 通信装置、通信方法及记录介质
EP1728136A1 (en) Method and system for the cipher key controlled exploitation of data resources, related network and computer program products
CN109413648B (zh) 访问控制方法、终端、智能卡、后台服务器及存储介质
GB2526619A (en) Service provisioning
EP3732843A1 (en) Systems and methods for providing authentication and/or authorization
Kasper et al. Rights management with NFC smartphones and electronic ID cards: A proof of concept for modern car sharing
AU2019279983A1 (en) Secure access to encrypted data of a user terminal
EP3933627B1 (en) Authentication method
KR20170117682A (ko) 전자 기기 인증 방법 및 시스템

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination