A device control method, device, and distributed digital key system

Abstract

This application provides a device control method, device, and distributed digital key system, relating to the field of communication technology. The method is applied to a first device and a second device. The first device stores de-identified information from first key-related information; the second device's secure element stores sensitive information from the first key-related information and second key-related information. The method includes: the first device sending de-identified information to the second device; the second device merging the de-identified information and sensitive information into first key-related information; the second device performing mutual authentication between the first and second devices based on the first and second key-related information; and the second device executing a preset instruction based on the authentication result. The technical solution provided by this application can improve the compatibility and security of terminal devices.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a device control method, device, and distributed digital key system. Background Technology

[0002] A digital key (DK) is a "virtual key" built into mobile phones and other terminal devices. With the development of computer technology, digital keys are being used more and more widely in the fields of automobiles and smart locks. Taking the automotive field as an example, through digital keys, users can not only conveniently control the locking and unlocking of car doors and start the vehicle, but also conveniently perform driving authorization and transfer of vehicle use rights.

[0003] To ensure the security of digital key services and prevent malicious attacks from other applications, current digital key systems typically require digital keys to be stored in secure elements (SEs) on both the terminal device and the target device (e.g., in-vehicle infotainment system). These SEs generally need to meet at least an Evaluation Assurance Level 4+ (EAL4+) security level. However, many terminal devices currently lack compliant SEs, or even if they are, the digital key service provider lacks the necessary permissions to use them. This prevents these terminal devices from unlocking and starting the target device using a secure digital key. In other words, current digital key systems suffer from poor security either due to the lack of an SE for storing and protecting key information, or due to closed SE permission settings and access modes leading to poor compatibility. Summary of the Invention

[0004] This application provides a device control method, device, and distributed digital key system to improve the compatibility and security of the digital key system with terminal devices.

[0005] To achieve the above objectives, this application adopts the following technical solution:

[0006] In a first aspect, embodiments of this application provide a device control method applied to a first device and a second device. The first device stores de-identified information from first key-related information; the second device's secure element stores sensitive information from the first key-related information and second key-related information. The method includes: the first device sending the de-identified information to the second device; the second device merging the de-identified information and the sensitive information into first key-related information; the second device performing mutual authentication between the first device and the second device based on the first key-related information and the second key-related information; and the second device executing a preset instruction based on the authentication result.

[0007] The first device can be a terminal device (such as a mobile phone, smartwatch, etc.), and the second device can be a target device controlled by the terminal device (such as a vehicle system, smart door lock, etc.).

[0008] In the method provided in this embodiment, the first key-related information of the terminal device is divided into two parts: de-identified information and sensitive information. The de-identified information is stored in the terminal device, and the sensitive information is stored in the secure element of the target device. Since this method does not require the use of the secure element of the terminal device, it is compatible with terminal devices that do not have a secure element or are not authorized to use a secure element when controlling the target device, thus offering better compatibility with terminal devices. Furthermore, because the sensitive information related to the first key is stored within the secure element of the target device, this method also ensures information security.

[0009] In some embodiments, the security element of the second device includes a second digital key application and a server application. The server application stores the sensitive information, and the second digital key application stores second key-related information. The second device performs mutual authentication between the first device and the second device based on the first key-related information and the second key-related information. Furthermore, the second device executes preset instructions based on the authentication result, including:

[0010] The server application sends the card authentication information from the first key information to the second digital key application. The card authentication information is all or part of the information related to the first key.

[0011] The second digital key application generates a verification request ciphertext based on the card authentication information and the second key information, and sends the verification request ciphertext to the server application.

[0012] The server application authenticates the second device based on the encrypted verification request; and after successfully authenticating the second device, it sends an encrypted response to the second digital key application.

[0013] The second digital key application authenticates the first device based on the encrypted response; and, after the first device is successfully authenticated, controls the second device to execute preset instructions.

[0014] In this embodiment, the server application of the second device acts as the terminal device, and the second digital key application acts as the target device. The terminal device and the target device use the information related to the first key and the information related to the second key to perform mutual authentication. This avoids the transmission of sensitive information between the terminal device and the target device during the authentication process, thus ensuring the security of the authentication process.

[0015] In some embodiments, the method further includes: the second device updating the first key-related information and sending the de-identified information in the updated first key-related information to the first device.

[0016] In some embodiments, before the first device sends the de-identified information to the second device, the method further includes: the first device sending first identity verification information of the first device to the second device; the second device verifying whether the identity of the first device is legitimate based on the first identity verification information; and if the identity of the first device is legitimate, the second device sending second identity verification information of the second device to the first device; and the first device verifying whether the identity of the second device is legitimate based on the second identity verification information.

[0017] In some embodiments, before the first device sends the de-identified information to the second device, the method further includes: the first device sending registration information to the second server through the first server; the second server generating first key-related information based on the registration information, and sending the de-identified information in the first key-related information to the first device, and sending the sensitive information in the first key-related information to the second device.

[0018] In some embodiments, the first device sending the de-identified information to the second device includes: the first device sending the de-identified information to the second device after detecting a first preset condition. The first preset condition is that the distance between the first device and the second device is within a preset range; or, the first device receives a second user operation, which is used to control the second device to execute a preset instruction.

[0019] In some embodiments, when Bluetooth Low Energy (BLE) technology is used to communicate between the first device and the second device, the first device and the second device exchange information based on the Hypertext Transfer Security Protocol (HTTPS).

[0020] In some embodiments, information related to the first key is stored within a first digital key application; the first digital key application is an application included in a software installation package, or a nested applet on an application platform, or a web application. This convenient user option benefits from the fact that the first digital key application no longer relies on the closed security elements of the first device.

[0021] In some embodiments, the sensitive information and the second key-related information are located within the secure element of the second device, and on both sides of the firewall within the secure element.

[0022] Secondly, embodiments of this application provide a device control method applied to a first device, wherein the first device stores de-identified information from first key-related information; sensitive information from the first key-related information and second key-related information are stored in a secure element of the second device. The method includes: sending the de-identified information to the second device. The de-identified information is used to merge with the sensitive information in the second device to obtain first key-related information; the first key-related information and the second key-related information are used by the second device to perform mutual authentication between the first device and the second device; and, based on the authentication result, controlling the second device to execute preset instructions.

[0023] In some embodiments, sending the de-identified information to the second device includes: mutually verifying the identity of the other party with the second device; if the identities of both the first device and the second device are valid, then sending the de-identified information to the second device.

[0024] In some embodiments, sending de-identified information to the second device includes: sending de-identified information to the second device after detecting a first preset condition. The first preset condition is that the distance between the first device and the second device is within a preset range; or, the first device receives a second user operation, the second user operation being used to control the second device to execute a preset instruction.

[0025] In some embodiments, before sending the de-identified information to the second device, the method further includes: sending registration information to the second server through the first server; receiving the de-identified information sent by the second server through the first server, wherein the first key-related information corresponding to the de-identified information is generated by the second server based on the registration information; and storing the de-identified information.

[0026] In some embodiments, when Bluetooth Low Energy (BLE) technology is used to communicate between the first device and the second device, the first device and the second device exchange information based on the Hypertext Transfer Security Protocol (HTTPS).

[0027] In some embodiments, the information related to the first key is stored within the first digital key application; the first digital key application is an application carried in a software installation package, or a nested applet of an application platform, or a web application.

[0028] Thirdly, embodiments of this application provide a device control method applied to a second device, wherein the security element of the second device stores sensitive information from the first key-related information and the second key-related information; and the desensitized information from the first key-related information is stored in the first device.

[0029] The method includes: receiving the de-identified information sent by the first device; merging the de-identified information and the sensitive information into a first key-related information; performing mutual authentication between the first device and the second device based on the first key-related information and the second key-related information; and controlling the second device to execute a preset instruction based on the authentication result.

[0030] In some embodiments, the security element of the second device includes a second digital key application and a server application. The server application stores the sensitive information, and the second digital key application stores second key-related information. The second device performs mutual authentication with the first device based on the first key-related information and the second key-related information, and controls the second device to execute preset instructions based on the authentication result, including:

[0031] The server application sends the card authentication information from the first key information to the second digital key application. The card authentication information is all or part of the information related to the first key.

[0032] The second digital key application generates a verification request ciphertext based on the card authentication information and the second key information, and sends the verification request ciphertext to the server application.

[0033] The server application authenticates the second device based on the encrypted verification request; and after successfully authenticating the second device, it sends an encrypted response to the second DK application.

[0034] The second digital key application authenticates the first device based on the encrypted response; and, after the first device is successfully authenticated, controls the second device to execute preset instructions.

[0035] In some embodiments, the method further includes: updating the first key-related information and sending the de-identified information in the updated first key-related information to the first device.

[0036] In some embodiments, before receiving the de-identified information sent by the first device, the method further includes: mutually verifying the identity of the other party with the first device; and after determining that the identities of both the first device and the second device are legitimate, receiving the de-identified information sent by the first device.

[0037] In some embodiments, the sensitive information and the second key-related information are located within the secure element of the second device, and on both sides of the firewall within the secure element.

[0038] Fourthly, embodiments of this application provide a distributed digital key system, including a first device and a second device. The first device stores de-identified information from first key-related information; the security element of the second device stores sensitive information from first key-related information and second key-related information; the first device and the second device cooperate with each other to implement the device control method shown in the first aspect above.

[0039] Fifthly, embodiments of this application provide a first device, which stores desensitized information from first key-related information; sensitive information from the first key-related information is stored in a secure element of a second device, and the first device is configured to execute the device control method shown in the second aspect above.

[0040] In a sixth aspect, embodiments of this application provide a second device, the second device having a security element storing sensitive information from a first key-related information and second key-related information, the second device being configured to execute the device control method shown in the third aspect above.

[0041] In a seventh aspect, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the device control method shown in the second aspect above.

[0042] Eighthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the device control method shown in the third aspect above.

[0043] Ninthly, embodiments of this application provide a computer program product that, when run on a first device, causes the first device to implement the method shown in the second aspect.

[0044] In a tenth aspect, embodiments of this application provide a computer program product that, when run on a second device, causes the second device to implement the method shown in the third aspect.

[0045] It is understood that the beneficial effects of aspects two through ten above can be found in the relevant descriptions in aspect one above, and will not be repeated here. Attached Figure Description

[0046] Figure 1 This is a schematic architecture diagram of a digital key system provided in one embodiment of this application;

[0047] Figure 2 This is a schematic architecture diagram of a digital key system provided in another embodiment of this application;

[0048] Figure 3 This is a schematic flowchart illustrating the registration and activation process of the digital key service provided in this application embodiment;

[0049] Figure 4 This is a schematic diagram of the activation interface for the digital key service on the terminal device side provided in the embodiments of this application;

[0050] Figure 5 This is a schematic diagram of the activation interface for the target device-side digital key service provided in an embodiment of this application;

[0051] Figure 6 This is a schematic flowchart illustrating the unlocking of a target device provided in one embodiment of this application;

[0052] Figure 7 This is a schematic flowchart illustrating the unlocking of a target device provided in another embodiment of this application. Detailed Implementation

[0053] The technical solutions provided in the embodiments of this application will be described below with reference to the accompanying drawings.

[0054] It should be understood that in the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in this document is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone.

[0055] In this embodiment, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.

[0056] A digital key (DK) is a "virtual key" built into mobile phones and other terminal devices. With the development of computer technology, digital keys are being used more and more widely in the fields of automobiles and smart locks. Taking the automotive field as an example, through digital keys, users can not only intelligently unlock and lock car doors, remotely start the car's infotainment system, and remotely turn the car's air conditioning on and off, but also conveniently perform operations such as driver authorization and transferring car usage rights by sharing digital keys, bringing users a better car control experience.

[0057] Figure 1 This is a schematic architecture diagram of a digital key system provided in one embodiment of this application. See also... Figure 1 As shown, the digital key system includes a terminal device (also referred to as the first device), a terminal device server (also referred to as the first server), a target device server (also referred to as the second server), and a target device (also referred to as the second device). These will be described in detail below.

[0058] (1) Terminal equipment

[0059] In various embodiments of this application, the terminal device may be a mobile phone, tablet computer, wearable device (such as a smartwatch), computer with wireless transceiver capabilities, augmented reality (AR) / virtual reality (VR) device, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), etc. This application does not specifically limit the type of terminal device.

[0060] In this embodiment, the terminal device is provided with a first DK application, a first SE, and a first communication unit.

[0061] Among them, Figure 1 In the system shown, the first DK application is typically an application included in an Android software installation package (APK). After receiving the user's digital key service activation command, the first DK application can interact with the terminal device server to obtain key-related information (referred to as first key-related information in this embodiment) used by the terminal device to control the target device (e.g., unlock the target device). In this embodiment, the first DK application includes a first part and a second part that cooperate with each other. The first part is deployed in the terminal device's memory and is mainly used for configuring and maintaining the first DK application. The second part is deployed in the first SE and is used to store the first key-related information and perform authentication with the target device (such as an in-vehicle system).

[0062] The first SE (Secure Entity) is used to store critical data within the terminal device. It typically exists internally as a chip and uses encryption / decryption logic to prevent malicious attacks from other applications, thus protecting data security. It's important to note that only applications with the necessary permissions can store critical data within the first SE. For example, with the first DK (Data Access Key) application, only if the first DK application has permission to use the first SE can it store the first key's related information within it.

[0063] The first communication unit can provide an application (such as a first DK application) with a wireless communication solution on the terminal device. This first communication unit can be a radio frequency (RF) unit or other wireless communication unit. The terminal device can communicate with the terminal device server and the target device through this first communication unit.

[0064] (2) Terminal equipment server

[0065] The terminal device server can provide digital key service registration and activation services to terminal devices, and can also perform data sharing and information exchange with the target device server after establishing a trusted link.

[0066] Because the terminal device server maintains information related to the digital key (such as user account and password information, token, etc.), while the target device server maintains information related to the target device (such as card secret, extended fields used for authentication, etc.), the terminal device server acts as an intermediary for requests and responses when the terminal device and the target device server interact. In other words, the terminal device server is the bridge for information exchange between the two. Specifically, the terminal device server is responsible for managing the digital key's lifecycle (such as registration, activation, update, deregistration, synchronization, and use). Therefore, the terminal device server can also synchronize relevant information from the terminal device to the target device server.

[0067] (3) Target equipment

[0068] The target device is equipped with a second DK application, a second SE, and a second communication unit.

[0069] In this embodiment, the second DK application includes a first part and a second part that cooperate with each other. The first part is deployed in the memory of the target device and is mainly used for configuring and maintaining the second DK application. The second part is deployed in the second SE and is used to store the key-related information of the target device (referred to as the second key-related information in this embodiment), to perform authentication with terminal devices (such as mobile phones), and to control the target device to execute preset instructions (such as controlling the vehicle system to unlock, start the engine, etc.).

[0070] The second DK application can interact with the target device server, receive instructions, notifications, or information from the target device server, and execute corresponding operations. For example, the target device application can activate the digital key service on the target device side based on the notification from the target device server and the user's operation, and obtain information related to the second key.

[0071] The second SE is used to store critical data within the target device (such as information related to the second key). It typically exists inside the target device in the form of a chip and uses encryption / decryption logic circuits to prevent other applications from maliciously parsing and attacking the data within the SE, thus protecting data security.

[0072] The second communication unit can provide an application (such as a second DK application) with a wireless communication solution on the target device. This second communication unit can be a radio frequency unit or other wireless communication unit. The target device can communicate with the target device server and terminal devices through the second communication unit.

[0073] (4) Target device server

[0074] The target device server can provide digital key service registration and activation services to the target device, and can perform data sharing and information exchange with the terminal device server after establishing a trusted link.

[0075] After both the terminal device and the target device have activated the digital key service, if a user approaches the target device with the terminal device, or if the terminal device receives a control operation from the user on the target device, the terminal device and the target device verify each other using information related to the first key and the second key. Upon successful verification, the terminal device controls the target device to execute preset commands (such as unlocking the target device). Taking a vehicle infotainment system as an example, after the target device is unlocked, the user can open the car door or start the vehicle's engine.

[0076] To ensure the security of the digital key, in the digital key system provided in this embodiment, both the first SE and the second SE must reach at least the EAL4+ security level. However, some terminal devices (such as some low-end mobile phones, tablets, wearable devices, etc.) are not configured with SEs that meet the requirements; in addition, some terminal devices, although configured with SEs that meet the requirements, cannot use the SEs of the terminal devices due to permission issues. This results in these terminal devices being unable to form the aforementioned digital key system with the target device, thus failing to unlock the target device or failing to securely unlock the target device. In other words, the current digital key system has poor compatibility with terminal devices and poor security.

[0077] Therefore, this application also provides a distributed digital key system, which has stronger compatibility with various terminal devices and can ensure the security of digital keys.

[0078] Figure 2 This is a schematic architecture diagram of a digital key system provided in another embodiment of this application. See also... Figure 2 As shown, the system includes: a terminal device (also referred to as the first device), a terminal device server (also referred to as the first server), a target device (also referred to as the second device), and a target device server (also referred to as the second server). These will be described in detail below.

[0079] (1) Terminal equipment

[0080] In this embodiment, the terminal device is equipped with a first DK application and a first communication unit.

[0081] exist Figure 2 In the system shown, the first DK application can be an application carried within an APK. Specifically, the first DK application can also be a program running on a Uniform Resource Locator (URL) webpage, or an applet embedded in some application platforms (such as WeChat and Alipay). This convenient user option benefits from the fact that the first DK application no longer relies on closed SE hardware, but is based on a distributed system design. This embodiment does not limit the specific form of the first DK application.

[0082] The first DK application typically stores application information and application status information. Application information includes the application version, distribution provider, signing certificate, account and password information involved in registration and login, and biometric information. Application status information includes the expiration date of the token. Furthermore, after the first DK application activates the digital key service according to user instructions, it also stores anonymized information from the first key-related data.

[0083] In one example, the de-identified information in the first key-related information includes all or part of the information shown in Table 1, and may also include other related information not shown. This embodiment does not limit this.

[0084] It should be noted that when a terminal device controls a target device through a digital key service, the terminal device is equivalent to a card, and the target device is equivalent to a card reader. Therefore, the key-related information on the terminal device side (i.e., the first key-related information) can also be called card key-related information, and the key-related information on the target device side (i.e., the second key-related information) can also be called card reader key-related information.

[0085] Table 1. De-identification information related to the first key.

[0086]

[0087] In Table 1, the terminal device system includes the terminal device and the terminal device server, and the target device system includes the target device and the target device server.

[0088] The token information is generated by combining the user's account, password, and other relevant information according to calculation rules such as hashing or hash-based message authentication code (HMAC) related to the key. When a terminal device logs into the terminal device server, it can authenticate by including the token information in the access request, without having to carry the account and password. This avoids the account and password being transmitted over the air with each login and prevents malicious attacks from other programs. The token information includes an access token and a refresh token. The access message usually carries the access token, but each token has an expiration time. Therefore, after the access token expires, the terminal device server will report an error to the terminal device to notify it that the access token is invalid. In addition, it will also issue a refresh token to the terminal device. Based on this, the first DK application will automatically carry the refresh token to re-initiate the access request to the terminal device server, keeping the user unnoticed and avoiding the need to obtain the account and password again, as well as the process of transmitting the account and password over the air.

[0089] It should be understood that for a target device, multiple terminal devices may be able to unlock it. Therefore, each terminal device corresponds to a first key-related information, and the first key-related information is different for each device. Since de-identified information and sensitive information are part of the first key-related information, the de-identified information and sensitive information of each terminal device are different.

[0090] The first communication unit can provide an application (e.g., a first DK application) with a wireless communication solution on a terminal device. This first communication unit can be a radio frequency unit or other communication units. For example, the wireless communication solution may include near-field communication (NFC), ultra-wideband (UWB), Bluetooth (BT), Bluetooth Low Energy (BLE), frequency modulation (FM), infrared (IR), wireless local area networks (WLAN), cellular networks (CN), etc., and this embodiment does not limit this to any particular type.

[0091] (2) Terminal equipment server

[0092] The terminal device server can provide digital key service registration and activation services to terminal devices, and can perform data sharing and information exchange with the target device server after establishing a trusted link. See the preceding description for details; this embodiment will not repeat them here.

[0093] (3) Target equipment

[0094] See Figure 2 As shown, the target device is equipped with a second DK application, an SE, and a second communication unit.

[0095] In this embodiment, the second DK application includes a first part and a second part that cooperate with each other. The first part is deployed in the memory of the target device and is mainly used for configuring and maintaining the second DK application. For example, based on the notification from the target device server and combined with the user's operation, it activates the digital key service on the target device side, obtains sensitive information from the first key-related information, and second key-related information. The second part is deployed in the second SE and is used to store the second key-related information, perform authentication with terminal devices (such as mobile phones), and control the target device to execute preset instructions (such as controlling the vehicle system to unlock, start the engine, etc.).

[0096] In some embodiments, the sensitive information in the first key-related information includes some or all of the information shown in Table 2, and may also include other related information not shown. This embodiment does not limit this.

[0097] Sensitive information related to the first key in Table 2

[0098]

[0099] In this embodiment, the card issuance stage can be understood as the stage in which the terminal device activates the digital key service using the first DK application. The authentication stage can be understood as the identity authentication stage when the terminal device controls the target device to perform a preset operation (such as unlocking).

[0100] It should be noted that the de-identified information and sensitive information in the first key-related information may include some of the same content. For example, taking the de-identified information shown in Table 1 and the sensitive information shown in Table 2 as examples, the same content included in the de-identified information and sensitive information may be: Card SE ID, Card ID, etc.

[0101] In some embodiments, the second key-related information may be some or all of the information shown in Table 3, and may also include other related information not shown. This embodiment does not impose any limitations on this. It should be understood that a target device typically has only one set of second key-related information.

[0102] Table 3. Information related to the second key

[0103]

[0104] After the digital key service is enabled on the target device side, the SE of the target device includes a firewall, the second part of the second DK application, and a server application.

[0105] The firewall within the SE can physically isolate applications located on either side of the firewall, such as server applications and the second part of the second DK application, preventing them from arbitrarily accessing each other's data. However, in this embodiment, based on certain protocols or regulations (such as those of JAVA CARD OS or MULTI OS platforms), the server application and the second part of the second DK application can bypass the firewall to perform certain specific accesses (e.g., access during mutual authentication). It should be noted that this embodiment does not impose specific restrictions on the type of firewall.

[0106] The second part of the second DK application is located on one side of the firewall within the SE. It acts as a reader to actively initiate commands or requests to the first DK application on the terminal device, and this second part stores information related to the second key. The server application is located on the other side of the firewall within the SE. The server application includes a web server application and a DK server application. The DK server application stores sensitive information from the first key's related information. The web server application is public infrastructure within the SE. In this embodiment, the web server application can act as a server to respond to requests from the first DK application, actively push relevant status information, and undertake the risk control task of ensuring the legitimacy of the first DK application's access. In some embodiments, the web server application can use the common Hypertext Transfer Protocol Secure (HTTPS) for certificate mutual authentication, etc.

[0107] In this embodiment, the SE typically exists in the form of a chip, which can prevent malicious parsing attacks on SE data by other applications through encryption / decryption logic circuits, thus protecting data security. In one example, the SE can be an embedded secure element (eSE), which is fixed on the motherboard of the terminal device and cannot be removed from the motherboard; therefore, it is also called a built-in SE. In this embodiment, the SE is connected to components such as NFC units and BLE, and it uses NFC units or BLE components as gateways to the outside of the target device.

[0108] The second communication unit can provide a wireless communication solution on the target device to applications (such as a second DK application, a web server application, a DK server application, etc.). The target device can communicate with the target device server and terminal devices through the second communication unit. This second communication unit can be a radio frequency unit or other wireless communication units. For example, the wireless communication solution may include NFC, UWB, BT, BLE, FM, IR, WLAN, CN, etc.

[0109] After both the terminal device and the target device have activated the digital key service, if the user brings the terminal device close to the target device, or if the terminal device receives a control operation from the user on the target device, the terminal device can send the de-identified information from the first key-related information to the target device's server application via short-range wireless communication technologies such as NFC and BLE, or long-range communication technologies such as WLAN and CN. The server application combines this de-identified information with locally stored sensitive information to form the first key-related information. Subsequently, the server application acts as the card, replacing the first DK application, and the second part of the second DK application acts as the reader, mutually authenticating using the first and second key-related information. If authentication is successful, the second part of the second DK application controls the target device to execute preset commands. Taking a car infotainment system as an example, after successful authentication between the terminal device and the car infotainment system, the second part of the second DK application can control the car infotainment system to unlock. After the car infotainment system unlocks, the user can open the car door or start the car engine.

[0110] In summary, in the digital key system provided in this application embodiment, the first key-related information is divided into two parts: de-identified information and sensitive information. The de-identified information is stored in the first DK application of the terminal device, while the sensitive information is stored in the server application of the target device. Since this digital key system does not require the use of the terminal device's SE when providing the digital key server, it is compatible with terminal devices that do not have an SE or whose first DK application is not authorized to use an SE, thus offering better compatibility with terminal devices. Furthermore, because the sensitive information related to the first key is stored in the target device's SE, this system also ensures the security of the digital key system.

[0111] The following is based on Figure 2 The digital key system shown provides an exemplary illustration of the registration and activation process for digital key services on both the terminal device and target device sides.

[0112] Figure 3 This is a schematic flowchart illustrating the registration and activation process of the digital key service provided in this application embodiment. See also... Figure 3As shown, the process includes the following steps S301 to S316.

[0113] S301, the terminal device receives the first user's operation.

[0114] When activating and registering the digital key service, the terminal device first needs to download and install the First DK application's APK or call the First DK application's mini-program or web application. Then, the terminal device logs into the First DK application and obtains the first user action, which instructs the terminal device to activate the digital key service.

[0115] Taking the activation of the vehicle's digital key via a terminal device as an example, after successful login, the first DK application can display the digital key activation interface according to user instructions. This interface includes a first control for controlling the activation of the digital key service. Figure 4 Taking the digital key activation interface shown as an example, the first control is the "Create Digital Key" control. After detecting the user's operation on the first control, the terminal device considers it to have received the first user operation.

[0116] S302, after receiving the first user operation, the terminal device sends a digital key activation request to the terminal device server.

[0117] After receiving the first user operation, the terminal device needs to perform the following operations (1) to (3) through the first DK application. In this embodiment, the order of execution of (1) and (2) is not restricted.

[0118] (1) The first DK application obtains basic user information and basic target device information. Taking the digital key for activating the vehicle system as an example, the basic user information includes the vehicle owner's name, vehicle owner's identification number (e.g., ID card number), phone number, email address, etc., and the basic target device information includes the vehicle system model, vehicle system identification QR code, vehicle identification number (VIN), etc. For example, the basic user information and basic target device information can be entered by the user on the terminal device during the activation of the digital key service, or they can be obtained by the terminal device from the target device server through the terminal device server. This embodiment does not impose specific restrictions on them.

[0119] (2) The first DK application generates the following content: card business public and private key pair A1 (hereinafter referred to as public and private key pair A1), card self-signed business certificate A1 (hereinafter referred to as business certificate A1), card identity public and private key pair B1 (hereinafter referred to as public and private key pair B1) and card self-signed identity certificate B1 (hereinafter referred to as identity certificate B1).

[0120] The public / private key pair A1 for card services is used by the terminal device or the terminal device server to encrypt / decrypt business-related data.

[0121] Card self-signed business certificate A1 is used to verify the validity of the certificate and recover the public key of the card business.

[0122] Card identity public / private key pair B1 is used by the terminal device or terminal device server to encrypt / decrypt identity-related data.

[0123] Card self-signed identity certificate B1 is used to verify the identity of the terminal device and recover the card identity public key.

[0124] Optionally, on the terminal device side, the generation and storage of public and private key pairs and certificates can be performed in a dedicated key store, such as Android keystore.

[0125] (3) The first DK application sends a digital key activation request to the terminal device server.

[0126] Optionally, the first DK application can send a digital key activation request to the terminal device server via HTTPS. This digital key activation request carries information such as the public key in public-private key pair A1, the public key in public-private key pair B1, card self-signed business certificate A1, card self-signed identity certificate B1, user basic information, and target device basic information.

[0127] S303, the terminal device server sends a first response message to the terminal device based on the digital key activation request.

[0128] After receiving a digital key activation request, the terminal device server first verifies the self-signed card identity certificate B1 carried within the request. Upon successful verification, a verification identifier is added to the self-signed card identity certificate B1, generating a terminal device system authentication certificate B1_1 (referred to as card identity authentication certificate B1_1, or authentication certificate B1_1). This card identity authentication certificate B1_1 indicates that the terminal device's identity has been authenticated by the terminal device server. Subsequently, the terminal device server sends a first response message to the terminal device's first DK application. This first response message includes the card identity authentication certificate B1_1. This first response message indicates that the terminal device server has received and processed the digital key activation request, and that the terminal device's identity has been authenticated by the terminal device server.

[0129] S304, The terminal device server sends registration information to the target device server based on the digital key activation request.

[0130] In this embodiment, the registration information includes card identity authentication certificate B1_1, a token, user basic information, and target device basic information. The authentication certificate B1_1 can be found in the relevant description in S303. The token is generated by the terminal device server based on the user's account and password during the user registration or initial login phase, and is used to authenticate the legitimacy of this session. The user basic information and target device basic information can be found in the relevant description in S302.

[0131] S305, the target device server determines the first key information based on the registration information.

[0132] After receiving the registration information, the target device server needs to determine the first key information based on some or all of the three parts of information. The first part is information generated locally by the target device server; the second part is information received by the target device server from the terminal device server; and the third part is static information retrieved by the target device server from its local key pool. These will be explained in detail below.

[0133] (1) First part of the information

[0134] After receiving the registration information, the target device server needs to generate the first part of information locally. This first part of information includes, but is not limited to: card service public / private key pair A2 (hereinafter referred to as public / private key pair A2), card service certificate A2 (hereinafter referred to as service certificate A2), reader identity public / private key pair B2 (hereinafter referred to as public / private key pair B2), reader identity certificate B2 (hereinafter referred to as identity certificate B2), card identity authentication certificate B1_2, random salt value A, random salt value B, card counter (CardATC), and card transaction authentication random number (CardRnd), etc. This embodiment does not restrict the specific content of the first part of information or the order in which the various pieces of information in the first part of information are generated.

[0135] The card business public / private key pair A2 is used by the target device server to encrypt / decrypt business-related data.

[0136] Card business certificate A2 is used to verify the legitimacy of the business certificate and to recover the card business public key A2.

[0137] The reader's identity public / private key pair B2 is used by the target device or the target device server to encrypt / decrypt identity-related data.

[0138] The card reader identity certificate B2 is used to verify the identity of the target device and recover the card reader's identity public key.

[0139] Card authentication certificate B1_2 is generated by the target device server after successfully verifying card authentication certificate B1_1, by retrieving the card's public key from card authentication certificate B1_1 and then signing it. In other words, authentication certificate B1_2 is obtained after the self-signed card authentication certificate B1 has undergone dual authentication by both the terminal device server and the target device server, representing that the terminal device's identity has been dually recognized by both servers.

[0140] Random salt values ​​A and B are used to encrypt / decrypt anonymized data.

[0141] The card counter (CardATC) increments by N after each authentication, where N ≥ 1 and is an integer.

[0142] The Card Transaction Authentication Random Number (CardRnd) is used in the encryption / decryption process during the authentication between the terminal device and the target device.

[0143] (2) Second part of the information

[0144] The second part of the information consists of what the target device server receives from the terminal device server, including: card authentication certificate B1_1, token, user basic information, target device basic information, etc. Please refer to the preceding description for the specific content of each piece of information; this embodiment will not repeat it here.

[0145] (3) Third part of the information

[0146] The third part of the information consists of static information retrieved by the target device server from the key pool based on parameters such as the terminal device's Token and CardID. It should be understood that the target device server may serve multiple target devices simultaneously, and for each target device, the terminal device may store information used to activate the car key service (i.e., this third part of the information). Therefore, the target device server needs to retrieve the corresponding third part of the information from the key pool based on parameters such as the Token and CardID.

[0147] For example, in this embodiment, the third part of the information includes at least one of the following:

[0148] Card SEID is a unique identifier used to uniquely identify the SE of a terminal device.

[0149] Card ID is used to uniquely identify terminal devices.

[0150] The card uses extended fields (CardAuthRFU) for the authentication phase, which include additional authentication information such as mobile phone number and location.

[0151] The Card Secret is used for encryption / decryption during the authentication process.

[0152] Optionally, CardPrivate Info may include some user-related information.

[0153] The target device service generates first key-related information based on some or all of the information in the first part, the second part, and the third part. For example, this first key-related information may be some or all of the information combined from Tables 1 and 2, and may also include other related information not shown; this embodiment does not impose any limitations on this.

[0154] S306, the target device server sends the de-identified information from the first key-related information to the terminal device server.

[0155] In one example, the de-identified information in the first key-related information may be part or all of the information shown in Table 3, and may also include other related information not shown; this embodiment does not impose any limitations on this. When the target device server sends the de-identified information to the terminal device server, it needs to encrypt the de-identified information.

[0156] When the target device server sends the de-identified information to the terminal device server in an encrypted manner, in one example, the target device server can perform a first encryption and a second encryption on the de-identified information sequentially. During the first encryption, the target device server uses the card service public and private keys to encrypt the de-identified data using the public key in A2. During the second encryption, the target device server first retrieves the master personalized protection key `mkey` from the key pool based on preset version, batch, and index information; then, it uses a token as a distribution factor to distribute the distributed personalized protection key `skey` from the master personalized protection key `mkey`; finally, it uses `skey` to encrypt the de-identified information.

[0157] It should be noted that both the master personal protection key mkey and the distributed personal protection key skey are used to encrypt / decrypt information related to the first key. Among them, mkey is the root key and skey is the child key.

[0158] S307, the terminal device server encrypts the de-identified data in the first key information and sends it to the terminal device.

[0159] When sending de-identified information to the terminal device, the terminal device server needs to encrypt the de-identified information. For example, after the de-identified information has already been encrypted twice (see the relevant description in S306), the terminal device server can use the card self-signed business certificate A1 to encrypt the de-identified information a third time, and then send the de-identified data with three encryptions to the terminal device.

[0160] S308, The terminal device stores the de-identified information in the first key-related information.

[0161] In some embodiments, the terminal device may store the de-identified information in the first key-related information in a lightweight database (SQLite) of the first DK application, and the storage path may be " / data / data / ".<package name> / database / .db".

[0162] Since a single terminal device can enable digital key services for multiple target devices, it may correspond to multiple sets of primary key-related information. This means that a single terminal device may correspond to de-identified information within multiple sets of primary key-related information. Therefore, when storing the de-identified information within the primary key-related information, the terminal needs to establish a mapping relationship between the de-identified information and the reader's unique identifier (Reader ID) and reader type for subsequent retrieval when controlling target devices.

[0163] S309, the terminal device sends the first activation success notification to the target device server through the terminal device server.

[0164] The first activation success notification indicates that the digital key service on the terminal device side has been successfully activated.

[0165] After the terminal device obtains and stores the de-identified data from the target device server through the above steps S301 to S309, the digital key service on the terminal device side is successfully activated.

[0166] The process of activating the digital key service on the target device is described in detail below. In some embodiments, after receiving the first activation success notification sent by the terminal device (i.e., after S309), the target device server instructs the vehicle system to activate the digital key service. In other embodiments, after obtaining the first key-related information (i.e., after S305), the target device server instructs the vehicle system to activate the digital key service. This process specifically includes the following S310 to S316.

[0167] S310, the target device installs the second part of the second DK application on one side of the firewall within the SE according to user instructions.

[0168] In this embodiment, the target device and the terminal device need to log in with the same account (e.g., Huawei account, mobile phone number, email address, etc.) to share data. Since the target device server has already generated the first key-related information (see S305), after logging in with the same account as the terminal device, the target device can obtain the first key-related information shown above from the target device server and instruct the second DK application to pre-set the first part of the prompt and guide the user to activate the digital key service on the target device side (see S305). Figure 5 (As shown).

[0169] After receiving the digital key activation command from the user, the target device opens a secure channel for data transmission with the target device server. Through this secure channel, it installs a supplementary security domain (SSD) and downloads and installs the second part of the second DK application onto the SSD. After successfully installing the second part of the second DK application, the target device sends a second response message to the target device server to notify it that the second part of the second DK application has been successfully installed.

[0170] S311, the target device server sends information related to the master digital key and the second key to the target device.

[0171] In this embodiment, the target device server pre-stores corresponding second key information in the key pool for each target device. Based on this, for example, after detecting the successful installation of the second part of the second DK application, the target device server first retrieves the second key information from the key pool based on the reader ID. Then, based on pre-defined version, batch, and index information, the target device server retrieves the master digital keys mkey1 to mkey3 from the key pool. Finally, the target device server encrypts the master digital keys mkey1 to mkey3 and the second key information and sends them to the target device through a secure channel.

[0172] In one example, the information related to the second key may be part or all of the information shown in Table 2, and may also include other information not shown. This embodiment does not impose any restrictions on this.

[0173] In addition, among mkey1 to mkey3, mkey1 is the authentication key used by the target device to authenticate the terminal device, mkey2 is the encryption key used by the target device to update data locally, and mkey3 is the authentication key used by the target device to update data locally.

[0174] S312, the target device stores information related to the master digital key and the second key within the second DK application.

[0175] Specifically, after the target device receives and decrypts the second key information and the master digital keys mkey1 to mkey3, it stores the second key information and the master digital keys mkey1 to mkey3 in the second part of the second DK application.

[0176] S313, the target device installs a server application on the other side of the firewall within the SE.

[0177] The server applications include DK server applications and Web server applications. In this embodiment, the target device can download and install the DK server application through a secure channel. Furthermore, the Web server application is a common infrastructure within the SE; it can be pre-installed on the target device at the factory, or it can be installed and updated after the device leaves the factory according to user instructions.

[0178] S314, The target device server sends sensitive information and first information from the first key-related information to the target device.

[0179] In this embodiment, the sensitive information in the first key-related information may be some or all of the information shown in Table 2, and may also include other related information not shown. This embodiment does not impose any restrictions on this.

[0180] In this embodiment, the first information includes card service public / private key pair A2, card service certificate A2, reader identity public / private key pair B2, reader identity certificate B2, card counter (CardATC), card transaction authentication random number (CardRnd), random salt value A, random salt value B, token, decentralized personalization protection key skey, and decentralized digital keys skey1 to skey3. As described above, the card service public / private key pair A2, card service certificate A2, reader identity public / private key pair B2, reader identity certificate B2, encryption factor A, and transaction factor B are information already present in the target device server. However, the decentralized personalization protection key skey and decentralized digital keys skey1 to skey3 need to be determined by the target device server.

[0181] For example, the target device server can determine the master personalized protection key mkey and master digital keys mkey1 to mkey3 from the key pool based on the preset search version, batch and index information. Using a token as a distribution factor, the distributed personalized protection key skey can be distributed from the master personalized protection key mkey, and the distributed digital keys skey1 to skey3 can be distributed from the master digital keys mkey1 to mkey3.

[0182] When the target device server sends sensitive information from the first key-related information to the target device, it needs to encrypt the sensitive information and send it through a secure channel.

[0183] Finally, the target device server sends the de-identified information and the first information from the first key-related information to the target device.

[0184] S315, the target device stores the sensitive information in the first key-related information and the first information in the server application.

[0185] Specifically, the target device can store sensitive information from the first key-related information, as well as the first information, in a DK server application and / or a web server application.

[0186] S316, the target device sends a second successful activation notification to the target device server.

[0187] The second activation success notification is used to indicate that the digital key service on the target device has been successfully activated.

[0188] In summary, through the above steps S310 to S316, after the target device downloads and installs the second part of the second DK application from the target device server, writes the second key-related information into the second part of the second DK application, and downloads and installs the DK server application from the target device server, and writes the sensitive information and first information from the first key-related information into the DK server application, the digital key service on the target device side is successfully activated.

[0189] After both the terminal device and the target device have activated the digital key service, the terminal device can communicate with the target device via communication technologies such as NFC, BLE, UWB, WLAN, or NC, thereby controlling the target device to execute preset commands, such as controlling the vehicle's infotainment system to unlock. The following section provides an example using NFC and BLE.

[0190] (i) Unlocking target devices based on NFC communication technology

[0191] Figure 6 This is a schematic flowchart illustrating the unlocking of a target device according to an embodiment of this application, involving a process of communication between a terminal device and a target device via NFC technology to control the target device. The process specifically includes the following steps S600 to S618.

[0192] S600 establishes a low-level wireless connection between the first communication unit of the terminal device and the second communication unit of the target device.

[0193] In some embodiments, the first communication unit of the terminal device and the second communication unit of the target device can establish an underlying wireless connection through the ISO14443 protocol, a protocol customized by the International Organization for Standardization (ISO), also known as the contactless card standards protocol. The specific process will not be elaborated upon in this embodiment.

[0194] S601, after the first preset condition is met, the second communication unit sends an information acquisition command to the second DK application. The information acquisition command is used to acquire the second identity verification information of the target device.

[0195] In some embodiments, after detecting that the first preset condition is met (e.g., detecting that the distance between the terminal device and the target device is within a preset range), the second communication unit sends an information acquisition command to the second DK application to notify the second DK application to send second identity verification information to the second communication unit.

[0196] In this embodiment, the first preset condition is that the distance between the terminal device and the target device is within a preset range. Alternatively, the terminal device receives a second user operation, which is used to control the target device to execute preset instructions, such as unlocking, turning on the vehicle's air conditioning, etc.

[0197] In some embodiments, this information retrieval command may also be referred to as a get processdata (GPD) command or a GPD assembly command. This information retrieval command is used to obtain the second identity verification information of the target device. This second identity verification information may be a portion of the second key-related information, such as reader type (ReaderType), target device identifier (ReaderID), reader certificate (ReaderCertificate), etc.

[0198] S602, the second DK application sends the second identity verification information of the target device to the second communication unit.

[0199] The second identity verification information is a preset parameter in the second DK application. When the second DK application receives the information acquisition command, it sends the second identity verification information to the second communication unit.

[0200] S603, the second communication unit sends the second identity verification information of the target device to the first DK application.

[0201] Specifically, the second communication unit can send the second identity verification information of the target device to the first DK application through the first communication unit.

[0202] S604, the first DK application verifies the legitimacy of the target device's identity based on the target device's second identity verification information.

[0203] In some embodiments, since the terminal device may have activated multiple digital key services, it needs to retrieve the key for certificate verification and the subsequently sent de-identified information from its own memory based on information such as the reader type (ReaderType) and reader ID (ReaderID). The first DK application can use this key to verify the validity of the reader's identity certificate ((ReaderCertificate)). If the reader's identity certificate (ReaderCertificate) is invalid, the target device will fail to unlock. If the reader's identity certificate (ReaderCertificate) is valid, the target device is considered to be legitimate, and subsequent steps will continue.

[0204] S605, if the target device's identity is legitimate, the first DK application sends the terminal device's first identity verification information and the de-identified information from the first key-related information to the second DK application.

[0205] For example, the de-identified information in the first key-related information may be part or all of the information shown in Table 1, and may also include other information not shown. This embodiment does not limit this.

[0206] For example, the first identity verification information of the terminal device may include parameters such as CardCertificateB1_2, Token, biometric information, and CardID. Among them, biometric information includes the user's fingerprint information, facial information, voiceprint information, iris information, etc.

[0207] When the first DK application sends the de-identified information in the first identity verification information and the first key-related information of the terminal device to the second DK application, it needs to be encrypted. This embodiment does not impose any restrictions on this.

[0208] When the first DK application sends de-identified information to the terminal device using encryption, optionally, before sending the de-identified information to the second DK application, the first DK application can negotiate a session key and use this session key to encrypt the de-identified information. For example, firstly, the first DK application, based on the card self-signed identity certificate B1 (CardCertificateB1), negotiates a first session key using a key negotiation algorithm. This first session key is used to encrypt the de-identified information stored in the first DK application. Subsequently, since the de-identified information stored in the first DK application is encrypted three times sequentially using the public key A2, skey, and the card self-signed business certificate A1 in the card business public-private key pair A2, the first DK application needs to remove the outermost encryption key of the de-identified data (i.e., decrypt the third encryption) before using the first session key to encrypt the de-identified data. It can be understood that after the first DK application encrypts the de-identified information using the first session key, the de-identified information still has three layers of encryption keys.

[0209] Optionally, in this embodiment, the key negotiation algorithm can be any one of the following: Diffie-Hellman key negotiation algorithm, elliptic curve DH (ECDH) key negotiation algorithm, ephemeral DH (DHE) key negotiation algorithm, and ephemeral ephemeral DH (ECDHHE).

[0210] S606, the second DK application sends the de-identified information from the first key-related information and the first identity verification information of the terminal device to the server application through the firewall in the SE.

[0211] In some embodiments, the second DK application, under the access rules specified by JAVA CARD OS or MULTI OS, sends the de-identified information in the first key-related information and the first identity verification information of the terminal device through the firewall in the SE to the server application.

[0212] S607, the server application verifies the legitimacy of the terminal device's identity based on the terminal device's first identity verification information.

[0213] For example, the server application can verify the legitimacy of the terminal device's identity based on the CardCertificateB1_2; and / or, verify whether the user is the vehicle owner based on the hash value corresponding to the biometric information in the first identity verification information; and / or, verify whether the digital key service has expired based on the timestamp information, access frequency, and the information's validity / expiration period. If the user is not the vehicle owner, or the terminal device's identity certificate verification fails, or the digital key service has expired, then the terminal device's identity is considered illegitimate.

[0214] In some embodiments, if the server application frequently receives digital key information from the terminal device, it considers the unlocking to be a risk incident. Therefore, the server application can also determine that the terminal device's first identity verification information is invalid and that the unlocking has failed.

[0215] After verifying the legitimacy of the terminal device, the server application can send a third response message to the first DK application through the second DK application. This third response message notifies the first DK application that the terminal device's identity verification has been successful. For example, this third response message can be an Application Protocol Data Unit (APDU) authorization message, abbreviated as AUTH APDU.

[0216] It should be noted that within the SE of the target device, since a firewall is set up between the second part of the second DK application and the server application, the server application needs to pass through the firewall and send the third response message to the first DK application through the second DK application while meeting the access rules specified by JAVA CARD OS or MULTIOS.

[0217] Furthermore, after receiving the third response information, the first DK application of the terminal device needs to send second information to the server application sequentially through the first communication unit, the second communication unit, and the second DK application. For example, this second information includes: a timestamp of the first DK application receiving the third response message, a card service random number (CardNonce) generated by the first DK application, and a pre-stored token and card unique identifier (CardID) retrieved locally by the first DK application.

[0218] In this embodiment, after sending the third response message to the first DK application, the server application can obtain the card transaction random number (CardNonce) from the first DK application through the second information. In subsequent processes (see S609), the server application uses the locally generated card transaction authentication random number (CardRnd) and the random number (CardNonce) obtained from the first DK application to generate a new random number according to the XOR operation or other algorithm rules. This newly generated random number is used for mutual authentication between terminal devices, which can ensure the reliability of authentication.

[0219] When the first DK application sends the second information to the server application, it may or may not encrypt the second information; this embodiment does not impose any restrictions on this.

[0220] S608, if the terminal device is legitimate, the server application will merge the locally stored sensitive information with the received de-identified information into the first key-related information.

[0221] Since the target device has already stored sensitive information locally during the digital key service activation process (see S315), the server application can combine the desensitized information with the currently stored sensitive information after decrypting the desensitized information to obtain the first key-related information.

[0222] In some embodiments, if the terminal device is legitimate, the server application can, after sending a third response message to the terminal device and receiving the second message returned by the first DK application, merge the locally stored sensitive information with the received de-identified information to obtain the first key-related information.

[0223] In other embodiments, if the terminal device is legitimate, the server application may also merge the locally stored sensitive information with the received de-identified information to obtain the first key-related information before sending the third response information to the terminal device and receiving the second information returned by the first DK application.

[0224] Since the de-identified information received by the server application is encrypted, the server application must decrypt the de-identified information before it can merge it with the sensitive information to obtain the first key information.

[0225] In one example, if the de-identified information received by the server application is encrypted three times in sequence using the public key A2 in A2 of the card business public and private key pair, the decentralized personalization protection key skey, and the first session key, then the server application needs to decrypt the de-identified data in sequence using the first session key, the decentralized personalization protection key skey, and the public key A2 in A2 of the card business public and private key pair.

[0226] Specifically, first, the server application negotiates a first session key using the same key negotiation algorithm as the terminal device, and uses this first session key to decrypt the anonymized information for the first time. Second, the server application looks up the decentralized personalization protection key skey based on the token, and uses skey to decrypt the anonymized information for the second time. Finally, the server application looks up the card business public / private key pair A2 based on the token, and uses the card business public / private key pair A2 to decrypt the anonymized information for the third time, obtaining the plaintext of the anonymized information.

[0227] It should be noted that during the activation of the digital key application on the target device, the personalized protection key skey and the public / private key pair A2 for card services are already stored in the server application (see S315). Therefore, during the decryption process described above, the server application can directly look up the token locally.

[0228] Since multiple different terminal devices can activate the digital key service for the same target device, it's understandable that the target device might store multiple sets of sensitive information corresponding to different terminal devices. Therefore, after decrypting the anonymized information, the server application needs to retrieve and obtain the corresponding sensitive information locally based on the token and / or the unique identifier of the card / reader (ReaderID, ReaderType, CardID, CardSEID) before combining the anonymized and sensitive information to obtain the first key information. It should be understood that the anonymized information stored on the device terminal is not unique and can correspond to multiple target devices; similarly, the sensitive information stored by the server application on the target device is not unique and can correspond to multiple terminal devices. Therefore, correct searching and matching are necessary when merging and combining the first key information.

[0229] Based on S601 to S608 above, the application server on the target device side obtains complete information related to the first key. That is, after S608, on both sides of the firewall within the target device's SE, the server application stores information related to the first key, and the second part of the second DK application stores information related to the second key. Based on this, the server application can replace the role of the terminal device, and the second DK application can replace the role of the target device, performing mutual authentication between the terminal device and the target device through the interaction between the server application and the second DK application. The following section provides a detailed explanation in conjunction with S609 to S618.

[0230] S609, the server application sends the card authentication information from the first key information to the second DK application.

[0231] In one example, the server application can send card authentication information to the second DK application as follows:

[0232] First, the server application determines the card authentication information based on the first key information. In one example, the card authentication information may include all or part of the information from the first key. For example, the card authentication information may include a new card transaction authentication random number (CardRnd_new), a card counter (CardATC), etc. The new card transaction authentication random number (CardRnd_new) is a random number newly generated by the server application using a locally generated card transaction authentication random number (CardRnd) and a random number (CardNonce) sent by the terminal device's first DK application, according to an XOR operation or other algorithm rules.

[0233] Secondly, the server application retrieves the digital key keys skey1 to skey3 from the local machine based on the Token or Reader Type, and distributes skey1 to skey3 using the Token to obtain the second session key.

[0234] Finally, the server application uses the second session key to encrypt the card authentication information into an encrypted field, and sends the encrypted card authentication information to the second DK application. It should be understood that this encrypted field carries the card authentication information.

[0235] S610, the second DK application generates a verification request ciphertext based on the card authentication information and the second key information.

[0236] Since the card authentication information received by the second DK application is encrypted with the second session key in the server application, the second DK application first needs to generate the same second session key and use the second session key to decrypt the card authentication information before generating the verification request ciphertext based on the card authentication information and the second key information.

[0237] In one example, the second DK application can generate the second session key by performing the following operations (1) to (3).

[0238] (1) The second DK application finds the relevant information of the second key based on the unique identifier of the card SE (CardSEID), and determines the root key (RootSecret) from the relevant information of the second key.

[0239] (2) The second DK application extracts the card secret from the root secret based on the unique card SE identifier (CardSEID) carried in the card authentication information and the extended field (CardAuthRFU) used in the authentication phase. This card secret is the same as the card secret in the information related to the first secret.

[0240] (3) The second DK application generates a second session key based on the subkey Card Secret.

[0241] After generating the second session key, the second DK application uses the second session key to decrypt the received encrypted card authentication information to obtain the plaintext card authentication information, such as the card transaction authentication random number (CardRnd) and the card counter (CardATC).

[0242] Finally, the second DK application uses the second session key to encrypt information such as the card counter (Card ATC) and card random number (CardRnd) according to an encryption algorithm (e.g., AES128_CBC algorithm) to generate a verification request ciphertext. This verification request ciphertext is used to request authentication from the terminal device.

[0243] Optionally, the server application can also add the reader random number (ReaderRnd) to the card authentication information and send it to the second DK application. The second DK application can obtain the reader random number (ReaderRnd) by decrypting the encrypted field. If the reader random number (ReaderRnd) carried in the first authentication information is the same as the reader random number (ReaderRnd) stored in the second DK application, then the second DK application performs the operation of generating the ciphertext of the verification request. If the reader random number (ReaderRnd) carried in the first authentication information is different from the reader random number (ReaderRnd) stored in the second DK application, then the second DK application's verification of the terminal device fails, the terminal device's control of the target device also fails, and the target device no longer executes the subsequent control process.

[0244] S611, the second DK application sends an encrypted authentication request to the server application through the firewall within the SE.

[0245] In some embodiments, the second DK application sends an encrypted authentication request to the DK server application through the firewall within the SE, provided that the access rules specified by JAVA CARD OS or MULTIOS are met.

[0246] S612, the server application authenticates the target device based on the encrypted verification request.

[0247] After receiving the encrypted verification request, the server application authenticates the target device based on the encrypted verification request.

[0248] In one example, the server application can use a pre-determined second session key to decrypt the ciphertext of the verification request and obtain the plaintext verification request, which includes information such as the Session Initiation Vector (SESIV), Card Counter (Card ATC), extended fields for the authentication phase (ReaderAuthRFU), and Card Random Number (CardRnd).

[0249] If the card random number (CardRnd) in the verification request plaintext is the same as the card random number (CardRnd) on the server application's local machine, then the server application considers the target device authentication successful. If the card random number (CardRnd) in the verification request plaintext is different from the card random number (CardRnd) on the server application's local machine, then the server application considers the target device authentication failed, and the terminal device's control over the target device ends.

[0250] S613 If the target device is successfully authenticated, the server application sends a response ciphertext to the second DK application through the firewall within the SE.

[0251] After successfully authenticating the target device, the server application needs to generate a response ciphertext based on the encryption algorithm used by the second DK application to generate the verification request ciphertext, and then increment the card counter (CardATC) by N. This response ciphertext is used by the second DK application to authenticate the terminal device.

[0252] In one example, the server application can use a second session key to encrypt the Session Initialization Vector (Session IV) based on an encryption algorithm (e.g., AES128_CBC), as well as information such as the card's extended fields for the authentication phase (CardAuthRFU), the reader's extended fields for the authentication phase (ReaderAuthRFU), and the reader's random number (ReaderRnd), all pre-encrypted using an algorithm (e.g., SHA256), to generate the ciphertext for the response. It can be understood that in one example, CardAuthRFU, ReaderAuthRFU, and ReaderRnd are encrypted twice using both the SHA256 and AES128_CBC algorithms.

[0253] S614, the second DK application authenticates terminal devices based on the encrypted response.

[0254] In one example, because the SHA256 algorithm is irreversible, the second DK application cannot decrypt the received ciphertext of the response (referred to as ciphertext 1). Therefore, after receiving the ciphertext of the response, the second DK application can generate its own ciphertext of the response (ciphertext 2) using the same method as the server application, and compare ciphertext 1 and ciphertext 2. If ciphertext 1 and ciphertext 2 are the same, it means the terminal device authentication is successful. If ciphertext 1 and ciphertext 2 are different, it means the terminal device authentication has failed, and the terminal device has failed to control the target device.

[0255] S615, if the terminal device authentication is successful, the second DK application sends the updated de-identified information (hereinafter referred to as the updated de-identified information) in the first DK application to the first DK application.

[0256] After the second DK application and the server application complete mutual authentication between the terminal device and the target device through interaction, parameters such as the card transaction authentication random number (CardRnd) and the card transaction authentication counter (CardATC) in the anonymized information related to the first key will be updated. Therefore, the second DK application needs to send the updated anonymized information to the first DK application.

[0257] In one example, after determining the updated de-identified information, the second DK application controls the server application to perform the following operations: First, the server application negotiates a third session key using a key negotiation algorithm and looks up the decentralized personalization protection key skey and the card business public / private key pair A2 based on the token. Then, the server application uses the public key from the card business public / private key pair A2 to perform a first encryption of the updated de-identified data, uses the decentralized personalization protection key skey to perform a second encryption, and uses the third session key to perform a third encryption. Finally, the server application sends the de-identified information, encrypted three times, to the second DK application. The second DK application then sends the updated de-identified information to the DK server application through the firewall within the SE.

[0258] Optionally, the key negotiation algorithm can be any one of DH, ECDH, DHE, or ECDHE, and this embodiment does not impose any restrictions on it.

[0259] S616, the first DK application stores the updated de-identified information.

[0260] The first DK application decrypts the updated de-identified information and then stores it.

[0261] In some embodiments, after receiving the updated de-identified information, the first DK application first negotiates a third session key using the same key negotiation algorithm as in S614, and then uses the third session key to decrypt the third layer encryption key of the updated de-identified information. Subsequently, the first DK application re-encrypts the updated de-identified information using the Android keystore key. Finally, the first DK application stores the updated de-identified information. In some embodiments, the terminal device can store the updated de-identified information in a lightweight database (SQLite), with the storage path being " / data / data / ".<package name> / database / .db".

[0262] S617, the first DK application sends a fourth response message to the second DK application, which indicates that the updated de-identified information has been stored.

[0263] S618, the second DK application controls the target device to execute preset instructions.

[0264] It should be noted that in this embodiment, after S614, S615 to S617 can be executed first and then S618 can be executed (i.e., update the desensitization information first and then control the target device to execute the preset instruction), or S618 can be executed first and then S615 to S617 can be executed (i.e., control the target device to execute the preset instruction first and then update the desensitization information). This embodiment does not impose any restrictions on this.

[0265] Taking the target device as an example, once the target device is unlocked, it can open the car door or start the car engine according to the user's operation.

[0266] (II) Unlocking the target device based on BLE communication technology

[0267] Figure 7 This is a schematic flowchart illustrating the unlocking of a target device according to another embodiment of this application, involving the process of unlocking the target device through communication between a terminal device and a target device via BLE technology. Figure 7 In this process, the terminal device includes a first DK application and a first communication unit, and the target device includes a second communication unit and an SE, wherein the SE includes a second DK application and a server application. The process specifically includes the following steps S700–S716.

[0268] In S700, the first communication unit and the second communication unit establish a BLE connection and establish a personal area network (PAN) between the terminal device and the target device.

[0269] After the first and second communication units establish a BLE connection, an HTTPS-based PAN can be established between the terminal device and the target device using the BLE generic attribute profile (BLE GATT) protocol. Therefore, the first DK application described below uses the HTTPS protocol to carry message content when sending messages to the target device. This allows the first DK application to directly access the server application on the target device without the need for a second DK application as an intermediary.

[0270] S701, after the first preset condition is met, the first DK application sends the first identity verification information of the terminal device to the server application.

[0271] In this embodiment, the first preset condition is that the distance between the terminal device and the target device is within a preset range. Alternatively, the terminal device receives a second user operation, which is used to control the target device to execute preset instructions, such as unlocking, turning on the vehicle's air conditioning, etc.

[0272] For example, the first identity verification information of the terminal device may include parameters such as CardCertificateB1_2, Token, biometric information, and CardID. Among them, biometric information includes the user's fingerprint information, facial information, voiceprint information, iris information, etc.

[0273] In S702, the server application verifies the legitimacy of the terminal device's identity based on the first identity verification information. S702 is similar to S607, and will not be repeated here.

[0274] S703, if the terminal device's identity is valid, the server application sends the target device's second identity verification information to the first DK application.

[0275] For example, the second identity verification information may include reader type (ReaderType), reader ID (ReaderID), and reader identity certificate (ReaderCertificate).

[0276] S704, the first DK application verifies the legitimacy of the target device's identity based on the target device's second identity verification information.

[0277] In this embodiment, the specific content of S704 can be found in S604, and will not be repeated here.

[0278] Optionally, after verifying the legitimacy of the target device, the first DK application sends a verification success notification to the second DK application on the target device.

[0279] It should be noted that this embodiment does not restrict the order in which the identities of the terminal device and the target device are verified. For example, as shown in S701 to S704, the identity of the terminal device is verified first, and then the identity of the target device is verified. Alternatively, the identity of the target device can be verified first, and then the identity of the terminal device can be verified.

[0280] It is worth noting that if the identity of the target device is verified first, the terminal device can send the de-identified information in the first key information and the terminal device's identity verification information together to the target device after the target device's identity verification is successful, which can reduce the interaction process between the terminal device and the target device.

[0281] After steps S701 to S704, the terminal device and the target device can verify each other's identity. If both identities are valid, the subsequent steps will continue.

[0282] S705, if the target device is legitimate, the first DK application sends the de-identified information from the first key-related information to the server application.

[0283] In one example, if the target device is legitimate, after receiving the successful verification notification from the first DK application, the second DK application sends a GPD message to the server application. The GPD message carries information such as the reader type (ReaderType), reader ID (ReaderID), the extended field used by the reader to generate the session key (ReaderSessionRFU), and the reader's random number (ReaderRnd). The server application packages the GPD message according to the HTTPS protocol and then sends it to the first DK application.

[0284] The first DK application retrieves the corresponding de-identified information from within itself based on information such as the reader type (ReaderType) and reader identifier (ReaderID). Furthermore, the first DK application needs to use a preset key negotiation algorithm to negotiate a fourth session key based on information such as the extended field used by the reader to generate the session key (ReaderSessionRFU) and the reader random number (ReaderRnd). This preset key negotiation algorithm can be any one of DH, ECDH, DHE, or ECDHE.

[0285] As described above, the de-identified information is encrypted three times sequentially using the card business public key A2, the decentralized personalization protection key skey, and the card self-signed business certificate A1. Therefore, the first DK application needs to first use the card self-signed business certificate A1 to remove the outermost encryption key of the de-identified data using the first session key, i.e., decrypt the third encryption, and then use the fourth session key to encrypt the de-identified data. It can be understood that after the first DK application encrypts the de-identified information using the fourth session key, the de-identified information still has three layers of encryption keys. Finally, the first DK application sends the de-identified information to the server application.

[0286] S706, the server application merges the locally stored sensitive information with the received de-identified information to obtain the first key-related information.

[0287] S707, the server application sends the card authentication information from the first key information to the second DK application.

[0288] S708, the second DK application generates a verification request ciphertext based on the card authentication information and the second key information.

[0289] S709, the second DK application sends an encrypted authentication request to the server application through the firewall within the SE.

[0290] S710: The server application authenticates the target device based on the encrypted verification request.

[0291] If the target device is successfully authenticated, the server application sends a response ciphertext to the second DK application through the firewall within the SE.

[0292] S712, the second DK application authenticates terminal devices based on the encrypted response.

[0293] S713, if the terminal device authentication is successful, the second DK application sends the updated de-identified information to the first DK application.

[0294] S714, the first DK application stores updated de-identified information.

[0295] S715, the first DK application sends a fourth response message to the second DK application, which indicates that the updated de-identified information has been stored.

[0296] S716, the second DK application controls the unlocking of the target device. After the target device is unlocked, it can open the car door or start the vehicle engine according to user operation.

[0297] In this embodiment, the specific implementation process of steps S706 to S716 can be found in the relevant content described in S608 to S618, and will not be repeated here. Furthermore, unlike S608 to S618, in S706 to S716, the terminal device and the target device communicate via the HTTPS protocol.

[0298] As described above, the device control method provided in this application allows the terminal device to send de-identified information from the first key-related information stored in the terminal device to the target device when unlocking the target device. The target device then combines the de-identified information with its local sensitive information to obtain the complete first key-related information. Based on the first key-related information and the second key-related information, the terminal device and the target device are authenticated, thereby controlling the target device. Therefore, even without using a SE to store and protect key information, the digital key based on this type of terminal device can still securely control the target device (e.g., unlock and start the target device).

[0299] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0300] Based on the device control methods provided in the above embodiments, this application also provides the following content.

[0301] This application provides a terminal device that stores de-identified information from first key-related information; sensitive information from the first key-related information is stored in a target device, and the terminal device is configured to execute the device control method executed by the terminal device in the above embodiments.

[0302] This application provides a target device that stores sensitive information from a first key-related information and second key-related information. The target device is configured to execute the device control method performed by the target device in the above embodiments.

[0303] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the device control method performed by the terminal device as described in the various embodiments above.

[0304] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the device control method performed by the target device as described in the above embodiments.

[0305] This application provides a computer program product that, when run on a terminal device, enables the terminal device to implement the device control methods executed by the terminal device as described in the various embodiments.

[0306] This application provides a computer program product that, when run on a target device, enables the target device to implement the device control method performed by the target device as described in the various embodiments.

[0307] It should be understood that the processor mentioned in the embodiments of this application can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0308] It should also be understood that the memory mentioned in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0309] In the embodiments provided in this application, the division of each framework or module is only a logical functional division. In actual implementation, there may be other division methods. For example, multiple frameworks or modules may be combined or integrated into another system, or some features may be ignored or not executed.

[0310] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0311] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0312] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0313] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A device control method characterized by, The method is applied to a first device and a second device, the first device stores desensitization information in first secret key related information, a second digital key application and a server application are arranged in a secure element of the second device, the server application stores sensitive information in the first secret key related information, and the second digital key application stores second secret key related information; the method comprises the following steps: The first device sends the desensitization information to the second device; In the second device: The server application combines the desensitization information and the sensitive information into the first secret key related information; The server application sends card authentication information in the first secret key related information to the second digital key application, the card authentication information being all or part of the first secret key related information; The second digital key application generates verification request ciphertext according to the card authentication information and the second secret key related information, and sends the verification request ciphertext to the server application; The server application authenticates the second device according to the verification request ciphertext, and sends response ciphertext to the second digital key application after the second device is authenticated; The second digital key application authenticates the first device according to the response ciphertext, and controls the second device to execute a preset instruction after the first device is authenticated.

2. The method of claim 1, wherein, The method further comprises the following steps: The second device updates the first secret key related information, and sends desensitization information in the updated first secret key related information to the first device.

3. The method of claim 1, wherein, Before the first device sends the desensitization information to the second device, the method further comprises the following steps: The first device sends first identity verification information of the first device to the second device; The second device verifies whether the identity of the first device is legal according to the first identity verification information, and sends second identity verification information of the second device to the first device if the identity of the first device is legal; The first device verifies whether the identity of the second device is legal according to the second identity verification information.

4. The method according to any one of claims 1 to 3, characterized in that, Before the first device sends the desensitization information to the second device, the method further comprises the following steps: The first device sends registration information to a second server through a first server; The second server generates the first secret key related information according to the registration information, and sends the desensitization information in the first secret key related information to the first device through the first server, and sends the sensitive information in the first secret key related information to the second device.

5. The method according to any one of claims 1 to 3, characterized in that, The first device sends the desensitization information to the second device, comprising the following steps: The first device sends the desensitization information to the second device after detecting a first preset condition; The first preset condition is that, The distance between the first device and the second device is within a preset range; or The first device obtains a second user operation for controlling the second device to execute the preset instruction.

6. The method according to any one of claims 1 to 3, characterized in that, In a case that the first device and the second device communicate by using Bluetooth Low Energy (BLE) technology, the first device and the second device interact information based on Hyper Text Transfer Protocol Secure (HTTPS).

7. The method of any one of claims 1-3, wherein, The first key-related information is stored in a first digital key application; the first digital key application is an application program carried in a software installation package, or a nested applet of an application platform, or a web application program.

8. The method of any one of claims 1-3, wherein, The sensitive information and the second key-related information are located in a secure element of the second device and on both sides of a firewall in the secure element.

9. A device control method characterized by, The second device is applied, and a second digital key application and a server application are arranged in a secure element of the second device; the server application stores sensitive information in the first key-related information, and the second digital key application stores second key-related information; Desensitized information in the first key-related information is stored in the first device, and the method comprises: The server application receives the desensitized information sent by the first device; The server application combines the desensitized information and the sensitive information into the first key-related information; The server application sends card authentication information in the first key-related information to the second digital key application; the card authentication information is all or part of the first key-related information; The second digital key application generates verification request ciphertext according to the card authentication information and the second key-related information, and sends the verification request ciphertext to the server application; The server application authenticates the second device according to the verification request ciphertext; and after the second device is authenticated, sends response ciphertext to the second DK application; The second digital key application authenticates the first device according to the response ciphertext; and after the first device is authenticated, controls the second device to execute a preset instruction.

10. The method of claim 9, wherein, The method further comprises: The second digital key application updates the first key-related information, and sends desensitized information in the updated first key-related information to the first device.

11. The method according to claim 9 or 10, characterized in that, Before the server application receives the desensitized information sent by the first device, the method further comprises: The server application and the first device verify each other's identity; After determining that the identities of the first device and the second device are both legal, the server application receives the desensitized information sent by the first device.

12. The method of claim 9 or 10, wherein, The sensitive information and the second key-related information are located in a secure element of the second device and on both sides of a firewall in the secure element.

13. A distributed digital key system, characterized by The first device and the second device are included, the first device stores desensitization information in the first secret key related information; the second device is provided with a second digital key application and a server application in the security element, the server application stores sensitive information in the first secret key related information, and the second digital key application stores second secret key related information; the first device and the second device cooperate with each other to realize the device control method in any one of claims 1-8.

14. A second device, comprising: The security element of the second device stores sensitive information in the first secret key related information and second secret key related information, and the second device is configured to execute the device control method in any one of claims 9-12.

15. A computer readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is executed by the processor to realize the method in any one of claims 9-12.

Images