A digital key opening method, device and system

Abstract

The application provides a digital key opening method, device and system. The system comprises a first device, a second device and a server, a first service protocol is preconfigured between the first device, the second device and the server, the method can realize, based on a trust relationship between the first device, the second device and the server, remote issuance of data required for opening a digital key under a second service protocol by the server under a digital key system of the first service protocol, and opening of the digital key under the second service protocol between the first device and the second device by using a mechanism defined under the first service protocol, thereby realizing support for the digital key system under the second service protocol in the digital key system under the first service protocol, so that the data interaction required for opening the digital key under the second service protocol can be realized without implementing a pairing protocol under the second service protocol, development workload and PKI system cost are reduced, and user experience is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computers, and in particular to a digital key opening method, device and system. BACKGROUND

[0002] With the accelerated popularization of vehicle networking, digital vehicle key (or "digital key") products have emerged, which realize vehicle unlocking and locking, engine starting and other functions through terminals (such as mobile phones, wearable devices, etc.), and realize digital vehicle key life cycle remote management and key sharing through the wireless communication module of intelligent networked vehicles. At present, the standards used by digital key solutions are generally the car connectivity consortium (CCC) standard and the intelligent car connectivity industry ecosystem alliance (ICCE) standard. However, due to the different design ideas of the CCC standard and the ICCE standard, the digital key system under the CCC standard and the digital key system under the ICCE standard are difficult to be compatible, which leads to the need to develop an additional digital key system under another standard in order to support two sets of digital key systems in a vehicle that has already configured a digital key system under one of the standards. SUMMARY

[0003] The present application provides a digital key opening method, device, system, computer storage readable storage medium and computer program product, which can realize activating a digital key system under another business protocol by using the existing functions of the digital key system under a business protocol that has been developed, reducing the development workload and PKI system cost, and improving the user experience.

[0004] In a first aspect, the present application provides a digital key opening method applied to a first device, wherein a first business protocol has been pre-configured between the first device, a second device and a server, the first device can open a first digital key under the first business protocol, and the method comprises: sending a target request to the server, the target request being used to request to apply for opening a second digital key under a second business protocol; obtaining target data sent by the server by using a first communication mechanism defined by the first business protocol, the target data being used to construct a first data structure of the second digital key; in response to the obtained target data, generating a public key and a private key of the second digital key, and constructing the first data structure of the second digital key based on at least the target data, and writing at least the target data into the first data structure; sending a first message to the second device by using a second communication mechanism defined by the first business protocol, the first message comprising the public key of the second digital key, and the first message being used to instruct the second device to store the public key of the second digital key.

[0005] In this way, when the first service protocol, the second service protocol and the server have been pre-configured between the first device, the second device and the server, based on the trust relationship between the first device, the second device and the server, the data required for opening the digital key under the second service protocol is remotely issued by the server, and the opening of the digital key between the first device and the second device under the second service protocol is completed by using the mechanism defined under the first service protocol, so that the digital key system under one service protocol is activated by using the existing function of the digital key system under another service protocol, the development workload and the PKI system cost are reduced, and the user experience is improved.

[0006] In a possible implementation, before at least part of the data in the target data is written into the first data structure, the method further includes: sending a target record request to the server by using the first communication mechanism defined by the first service protocol, the target record request being used to request to record the public key of the second digital key; and obtaining a target record proof sent by the server, the target record proof being used to prove that the server has completed the record of the public key of the second digital key. In this way, the server can record the public key of the second digital key.

[0007] In a possible implementation, the first message further includes the target record proof. In this way, the second device verifies the target record proof after obtaining the first message, to ensure that the public key of the second digital key included in the first message comes from a legal device, and thus the security of the opening of the digital key is improved.

[0008] In a possible implementation, the target data includes one or more of the following: an identifier of the second device, a public key of the second device, a box identifier, an authorized public key group, key capability data, a private mailbox size, or a confidential mailbox size.

[0009] In a possible implementation, the first data structure includes one or more of the following: the second device identifier, an identifier of the second digital key defined by the first device, a digital key identifier, a box identifier, an instance CA identifier, key capability data, a public key of the second digital key, a public key of the second device, an authorized public key group, a private mailbox, or a confidential mailbox.

[0010] In a possible implementation, the identifier of the second digital key defined by the first device, the digital key identifier, the box identifier, the instance CA identifier and the public key of the second digital key are all provided by the first device.

[0011] In a possible implementation, the second device identifier, the box identifier, the key capability data, the public key of the second device and the authorized public key group are all obtained from the target data, and the private mailbox and the confidential mailbox are created by the first device based on the target data.

[0012] In a possible implementation, the first device and the second device are each configured with a digital key system matching the first digital key and a digital key system matching the second digital key.

[0013] In a possible implementation, the first service protocol is an ICCE standard protocol, and the second service protocol is a CCC standard protocol.

[0014] In a possible implementation, the first communication mechanism is a communication mechanism based on key encryption / decryption between devices to provide security assurance; and the second communication mechanism is a communication mechanism based on the key of the first digital key and an authentication protocol to provide security assurance.

[0015] In a second aspect, the present application provides a method for opening a digital key, applied to a server, wherein the server, a first device and a second device are pre-configured with a first service protocol, the first device can open a first digital key under the first service protocol, and the method comprises: obtaining a target request sent by the first device, the target request being used to request to apply for opening a second digital key under a second service protocol; in response to the target request, obtaining target data, and sending the target data to the first device by using a first communication mechanism defined by the first service protocol, the target data being used to construct a first data structure of the second digital key.

[0016] In a possible implementation, the method further comprises: obtaining a target record request sent by the first device by using the first communication mechanism defined by the first service protocol, the target record request being used to request to record a public key of the second digital key; in response to the target record request, recording the public key of the second digital key, generating a target record proof, the target record proof being used to prove that the server has completed the recording of the public key of the second digital key; and sending the target record proof to the first device by using the first communication mechanism defined by the first service protocol.

[0017] In a possible implementation, the target data comprises one or more of the following: an identifier of the second device, a public key of the second device, a box identifier, an authorized public key group, key capability data, a private mailbox size, or a confidential mailbox size.

[0018] In a possible implementation, the first data structure comprises one or more of the following: the second device identifier, an identifier defined by the first device internally for the second digital key, a digital key identifier, a box identifier, an instance CA identifier, key capability data, a public key of the second digital key, a public key of the second device, an authorized public key group, a private mailbox, or a confidential mailbox.

[0019] In a possible implementation, the first device and the second device are each configured with a digital key system matching the first digital key and a digital key system matching the second digital key. In a possible implementation, the first service protocol is an ICCE standard protocol, and the second service protocol is a CCC standard protocol.

[0020] In a possible implementation, the first communication mechanism is a communication mechanism based on encryption / decryption of data between devices by using a key to provide security assurance.

[0021] In a third aspect, the present application provides a digital key opening system, comprising a first device, a second device, and a server, the first device, the second device, and the server are pre-configured with a first service protocol, and the first device can open a first digital key under the first service protocol, wherein the first device is configured to execute the method in the first aspect, the server is configured to execute the method in the second aspect, and the second device is configured to store a public key of a second digital key in response to a first message sent by the first device.

[0022] In a fourth aspect, the present application provides a device, characterized in that comprising:

[0023] at least one memory configured to store a program;

[0024] at least one processor configured to execute the program stored in the memory, and when the program stored in the memory is executed, the processor is configured to execute the method in the first aspect or the second aspect.

[0025] In a fifth aspect, the present application provides a computer readable storage medium, which stores a computer program (also referred to as instructions or codes) for implementing the method in the first aspect or the second aspect.

[0026] For example, when the computer program is executed by a computer, the computer can execute the method in the first aspect or the second aspect.

[0027] In a sixth aspect, the present application provides a chip comprising a processor. The processor is configured to read and execute a computer program stored in a memory to execute the method in the first aspect or the second aspect.

[0028] Optionally, the chip further comprises the memory, and the memory is connected to the processor through a circuit or a wire.

[0029] In a seventh aspect, the present application provides a computer program product, which comprises a computer program (also referred to as instructions or codes). When the computer program is executed by a computer, the computer program makes the computer implement the method in the first aspect or the second aspect.

[0030] It can be understood that the beneficial effects of the above-mentioned second aspect to the seventh aspect can be referred to the related description in the above-mentioned first aspect, which will not be repeated here. BRIEF DESCRIPTION OF DRAWINGS

[0031] Figure 1 is a schematic diagram of a digital key opening process under the ICCE standard provided by an embodiment of the present application;

[0032] Figure 2 is a schematic diagram of a digital key pairing process under the CCC standard provided by an embodiment of the present application;

[0033] Figure 3 is a schematic diagram of a digital key structure meeting the requirements of the CCC standard provided by an embodiment of the present application;

[0034] Figure 4a is a schematic diagram of an application scenario provided by an embodiment of the present application;

[0035] Figure 4b is a schematic diagram of a system architecture for issuing a digital key provided by an embodiment of the present application;

[0036] Figure 5 is a schematic diagram of the structure of a terminal provided by an embodiment of the present application;

[0037] Figure 6 is a schematic diagram of the structure of a server provided by an embodiment of the present application;

[0038] Figure 7 is a flowchart of a digital key pairing method provided by an embodiment of the present application;

[0039] Figure 8 is a flowchart of another digital key pairing method provided by an embodiment of the present application;

[0040] Figure 9 is a flowchart of a digital key sharing method provided by an embodiment of the present application;

[0041] Figure 10 is a schematic diagram of an authentication data packet in a digital key provided by an embodiment of the present application;

[0042] Figure 11 is a schematic diagram of another authentication data packet in a digital key provided by an embodiment of the present application;

[0043] Figure 12 is a flowchart of a digital key opening method provided by an embodiment of the present application;

[0044] Figure 13 is a schematic diagram of the structure of a chip provided by an embodiment of the present application. DETAILED DESCRIPTION

[0045] In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some but not all of the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative work fall within the protection scope of the present application.

[0046] The term “and / or” used in this document is a description of an association relationship of associated objects, which means that there can be three relationships, for example, A and / or B can mean that A exists alone, A and B exist together, and B exists alone. The symbol “ / ” in this document means an or relationship of associated objects, for example, A / B means A or B.

[0047] The terms “first” and “second” and the like in the description and claims of this document are used to distinguish different objects, and are not used to describe a specific order of the objects. For example, the first response message and the second response message are used to distinguish different response messages, and are not used to describe a specific order of the response messages.

[0048] In the embodiments of the present application, the words “exemplary” or “for example” are used to mean serving as an example, instance, or illustration. Any embodiment or design presented as “exemplary” or “for example” in the embodiments of the present application should not be interpreted as being more preferred or advantageous than other embodiments or design solutions. Rather, the use of “exemplary” or “for example” is intended to present concepts in a concrete manner.

[0049] In the description of the embodiments of the present application, unless otherwise specified, “a plurality of” means two or more, for example, a plurality of processing units means two or more processing units, and the like; a plurality of elements means two or more elements, and the like.

[0050] In order to facilitate understanding of the technical solutions provided in the present application, first, the design ideas of the ICCE standard and the design ideas of the CCC standard are introduced.

[0051] (1) Design ideas of the ICCE standard

[0052] The design ideas of the ICCE standard are mainly: based on the mature server management key distribution architecture in the industry, to realize the online distribution of the digital key. The digital key system under the ICCE standard currently adopts a symmetric key system.

[0053] Exemplarily, Figure 1 An ICCE standard digital key opening process is shown. As shown inFigure 1 As shown, the digital key pairing process under the ICCE standard includes the following steps:

[0054] S101, the terminal sends a digital key opening request to the server.

[0055] Specifically, the owner of the vehicle (hereinafter referred to as "the vehicle owner") can log in to the application related to the digital key on the terminal, and can select to apply for the digital key on the application. When the vehicle owner selects to apply for the digital key, the terminal sends a digital key opening request to the server. The digital key opening request can carry information for verifying the identity of the vehicle owner and the identity of the vehicle owned by the vehicle owner.

[0056] In one example, the information for verifying the identity of the vehicle owner can include one or more of the identity of the vehicle owner or the identity of the terminal. The identity of the vehicle owner and the identity of the vehicle can be used to determine whether the vehicle owner has the opening permission of the digital key service, for example, when the vehicle owner's vehicle model supports the digital key function and the vehicle owner subscribes to the digital key function service provided by the manufacturer, the vehicle owner has the opening permission of the digital key service. The identity of the terminal can be used to determine whether the terminal has the opening qualification of the digital key service; for example, a white list of terminals with digital key service opening qualification can be pre-set, and when the identity of the terminal belongs to the white list, the terminal has the digital key service opening qualification. Thus, the security of the digital key opening is improved.

[0057] S102, the server responds to the digital key opening request, verifies the identity of the vehicle owner, the request permission, etc., and generates a digital key after the verification is passed. The digital key includes a service key and related data (such as operation permission, validity period, etc.).

[0058] Specifically, after the server obtains the digital key opening request, it can verify the identity of the vehicle owner and detect whether the vehicle owner has the permission to open the digital key function of the related vehicle, for example, detect whether the vehicle owner subscribes to the digital key function service, etc. For example, the server determines that the information of the vehicle owner and the vehicle carried in the digital key opening request is consistent with the stored information of the vehicle owner and the vehicle owned by the vehicle owner, and then verifies that the identity of the vehicle owner is passed. After detecting that the vehicle owner has the permission to open the digital key, the server can generate a digital key for the device (i.e. the terminal) of the vehicle owner, wherein the service key used by the digital key can be but not limited to a symmetric key.

[0059] For example, the identity of the vehicle owner can be verified by but not limited to the following methods: SMS verification code, email verification code, electronic identity card, face recognition, etc.

[0060] In one example, the server can also generate data information related to the service key contained in the digital key when generating the service key, such as the usage permission of the service key (e.g. whether to allow unlocking, activating the engine, unlocking the trunk, unlocking the window, etc.), the validity period, etc.

[0061] S103, the server sends the digital key generated by it to the terminal.

[0062] Specifically, after generating the digital key, the server can send the digital key to the terminal. In addition, the server can also send the data information related to the digital key to the terminal. After the terminal obtains the digital key, it can store the digital key. At this point, the terminal obtains the digital key.

[0063] S104, the terminal or the server provides the digital key to the vehicle.

[0064] Specifically, after the terminal obtains the digital key, it can interact with the vehicle and perform authentication. In the authentication process, the vehicle can derive the service key corresponding to the terminal and the session key required for this communication according to the preset master key. In addition, after the server generates the digital key, it can send the digital key to the vehicle, so that the vehicle can obtain the service key contained in the digital key matched with the terminal. In addition, the terminal or the server can also send the data information related to the service key contained in the digital key to the vehicle.

[0065] At this point, the unlocking process of the digital key between the vehicle and the terminal is completed. After that, the vehicle owner can use the terminal to control the vehicle.

[0066] In one example, when the vehicle obtains the service key matched with the terminal by interacting with the terminal, Figure 1 In the process shown in FIG. 1, after S103 is executed, it can be understood that the digital key has been issued; then, the vehicle and the terminal can directly interact to obtain the service key contained in the digital key matched with the terminal. When the vehicle obtains the service key matched with the terminal by interacting with the server, Figure 1 In the process shown in FIG. 1, after S104 is executed, it can be understood that the digital key has been issued.

[0067] (2) Design idea of CCC standard

[0068] The design idea of the CCC standard is mainly: based on the public key infrastructure (PKI) system and the asymmetric key mechanism to complete the offline (i.e., not dependent on the server) mutual trust between the terminal and the vehicle, that is, the terminal and the vehicle establish a mutual trust relationship based on PKI, and securely exchange and save the public key and related key data of the other party.

[0069] Exemplarily, Figure 2 A digital key pairing process under the CCC standard is shown. As shown in Figure 2 The digital key pairing process under the CCC standard includes the following steps:

[0070] S201, the terminal establishes a connection with the vehicle.

[0071] Specifically, the terminal and the vehicle can establish a connection through wireless communication technologies such as bluetooth or near field communication (NFC). Exemplarily, the vehicle owner can carry the physical key and the terminal into the vehicle, and then control the terminal to establish a connection with the vehicle and initiate pairing.

[0072] S202, the vehicle sends the certificate chain of the vehicle and the key creation data required for generating the digital key to the terminal.

[0073] Specifically, after the vehicle establishes a connection with the terminal, the vehicle can send the certificate chain of the vehicle and the key creation data required for generating the digital key to the terminal.

[0074] Exemplarily, the key creation data can include one or more of the vehicle identifier, the vehicle public key, the slot identifier, the authorized public keys, the key options, the private mailbox size, the confidential mailbox size, the protocol version, and the vehicle public key certificate of the vehicle.

[0075] In one example, the slot identifier can identify a digital key and confidential data related to the digital key. Wherein, the vehicle can rely on the value of the slot identifier to uniquely identify a digital key and confidential data related to the digital key.

[0076] The authorized public key group can include the public key of at least one authentication center recognized by the vehicle factory.

[0077] The key capability data can indicate authentication types that the key can support, and / or, usage conditions, etc.

[0078] The private mailbox can store some data of the vehicle. In one example, both the vehicle and the mobile phone can read the data in the private mailbox.

[0079] The confidential mailbox can store some confidential data of the vehicle. In one example, the vehicle can read the data in the confidential mailbox.

[0080] The public key certificate of the vehicle can be understood as a digital certificate of the public key of the vehicle. The digital certificate is actually an authentication of the public key issued by a certificate authority (CA). The content of the digital certificate can include the signature of the certificate authority, the identity information of the certificate owner, the public key, the private key, and the validity period, etc. At present, the format and verification method of the certificate generally follow the X.509 international standard.

[0081] In one example, the certificate chain of the vehicle includes the certificate of the server, the certificate of the vehicle, and the public key certificate of the vehicle generated in the vehicle.

[0082] S203, the terminal checks the key creation data, and when the check passes, generates a public-private key pair of the digital key and a digital key structure meeting the CCC standard requirements.

[0083] Specifically, the terminal can check the key creation data based on the certificate chain of the vehicle. For example, check whether the public key certificate of the vehicle is legal, etc., wherein when it is determined that the public key certificate of the vehicle is issued by a trusted manufacturer, it can be determined that the check passes. It can be understood that the relationship between the vehicle and the manufacturer of the vehicle is a trusted relationship, the relationship between the manufacturer of the terminal and the terminal is a trusted relationship, and then when the trusted relationship is established between the manufacturer of the vehicle and the manufacturer of the terminal in advance, the trusted relationship is indirectly established between the vehicle and the terminal. At this time, after the terminal obtains the public key certificate of the vehicle sent by the vehicle, when it is determined that the public key certificate of the vehicle is authenticated by the manufacturer of the vehicle, it can be determined that the digital certificate is legal, and then it can be determined that the vehicle is a legal vehicle approved by the manufacturer of the vehicle.

[0084] After the terminal checks that the key creation data passes, the terminal can generate a public-private key pair of the digital key. For example, it can be an RSA public-private key pair.

[0085] In addition, after the terminal checks that the key creation data passes, the terminal can also generate a digital key structure meeting the CCC standard requirements based on the key creation data.

[0086] In one example, as shown in FIG. 2, the terminal can generate a digital key structure meeting the CCC standard requirements based on the key creation data. Figure 3As shown, the digital key structure that meets the CCC standard requirements can include: a vehicle identifier, an endpoint identifier, a digital key identifier, a slot identifier, an instance CA identifier, key options, a device public key, a vehicle public key, authorized public keys, a private mailbox, and a confidential mailbox.

[0087] For example, the endpoint identifier, the digital key identifier, and the device public key can be provided by the terminal. The instance CA identifier can be provided by the terminal. The vehicle identifier, the slot identifier, the key options, the vehicle public key, and the authorized public keys can be obtained from the key creation data provided by the vehicle. The private mailbox and the confidential mailbox can be created based on the private mailbox size and the confidential mailbox size contained in the key creation data provided by the vehicle.

[0088] For example, the endpoint identifier can be an identifier defined by the terminal for the digital key. The digital key identifier can be a value generated by the terminal by calculating a digest of the generated public key after generating a public-private key pair.

[0089] S204, the terminal generates a public key certificate for the public key of the public-private key pair of the digital key.

[0090] Specifically, after generating the public-private key pair of the digital key, the terminal can use a preset instance CA private key to sign the public key of the public-private key pair of the digital key and other related information, thereby generating the public key certificate of the digital key. The public key certificate of the digital key of the terminal can be understood as a digital certificate of the digital key matched with the vehicle on the terminal, which is usually in the X.509 format.

[0091] S205, the terminal sends a certificate chain containing at least the public key certificate of the digital key to the vehicle.

[0092] Specifically, after generating the public key certificate of the digital key, the terminal can send the certificate chain containing at least the public key certificate of the digital key to the vehicle, so that the vehicle can obtain the public key of the digital key generated by the terminal. For example, the certificate chain containing at least the public key of the digital key generated by the terminal can include the certificate of the server, the certificate of the terminal (instanceCA certificate), and the public key certificate of the digital key generated by the terminal.

[0093] S206, the vehicle verifies the public key certificate of the digital key, and stores the public key of the digital key contained in the public key certificate after verification.

[0094] Specifically, the vehicle can verify the public key certificate of the digital key of the terminal based on the certificate chain of the terminal, and when it is verified that the public key certificate of the digital key of the terminal is issued by a legitimate terminal, the verification is passed. It can be understood that the vehicle and the manufacturer of the vehicle (such as the server) are in a trusted relationship, the manufacturer of the terminal and the terminal are in a trusted relationship, and when the vehicle and the manufacturer of the terminal establish a trusted relationship in advance, the vehicle and the terminal indirectly establish a trusted relationship, and when the vehicle obtains the public key certificate of the digital key sent by the terminal, it is determined that the public key certificate is generated and issued by the terminal, and it is determined that the public key certificate is legal.

[0095] Further, after the verification is passed, the vehicle can store the public key of the digital key contained in the public key certificate, that is, store the public key of the digital key of the terminal.

[0096] S207, the vehicle sends key configuration data to the terminal.

[0097] Specifically, after storing the public key of the digital key, the vehicle can send key configuration data to the terminal.

[0098] In one example, the key configuration data can include one or more of an opaque attestation for proving that the vehicle has authenticated and stored the public key of the digital key, an owner immobilizer token, a slot identifier bitmap, a slot identifier, a vehicle OEM proprietary data structure, an owner immobilizer token for sharing the key, and a key registration request for requesting registration with the server.

[0099] S208, the terminal and / or the vehicle sends a key registration request to the server, wherein the key registration request comprises the public key and the certificate chain of the digital key, and the pairing proof between the vehicle and the terminal.

[0100] Specifically, after obtaining the key configuration data sent by the vehicle, the terminal can send a key registration request to the server for registration. The key registration request can include the public key and the certificate chain of the digital key of the terminal, the data protection public key, and the pairing proof between the vehicle and the terminal. The pairing proof between the vehicle and the terminal can be generated by the vehicle itself and sent to the terminal. The proof can represent the pairing relationship between the two. In one example, the data protection public key can be provided by the terminal. The data protection public key can be a public key used for encrypting data when the server issues data. The communication data sent by the server to the terminal is encrypted by the public key to improve data security.

[0101] In addition, after storing the public key of the digital key of the terminal, the vehicle can also send a key registration request to the server for registration.

[0102] S209, the server registers the public key of the digital key and the pairing relationship between the terminal and the vehicle (key tracking), and generates a registration proof.

[0103] Specifically, after obtaining the key registration request, the server can register the public key of the digital key of the terminal and the pairing relationship between the terminal and the vehicle, for example, by storing the public key of the digital key of the terminal and the pairing relationship between the terminal and the vehicle, and generating a registration proof by signing the public key of the digital key of the terminal. In this way, it is proved that the terminal and the vehicle have been registered. The registration proof is mainly used to prove that the server has completed the registration. For example, the registration proof can include a key tracking signature.

[0104] S210, the server sends the registration proof to the terminal and / or the vehicle.

[0105] Specifically, after registering the public key of the digital key of the terminal and the pairing relationship between the terminal and the vehicle, the server can send the registration proof to the terminal and / or the vehicle.

[0106] In one example, after the terminal obtains the registration proof sent by the server, the terminal can also send the registration proof to the vehicle through the communication protocol between the terminal and the vehicle defined by the CCC standard.

[0107] S211, after the vehicle obtains the registration proof from the terminal or the server, the vehicle sends sharing configuration data to the terminal.

[0108] Specifically, the vehicle obtains the recordation certificate, can verify the recordation certificate according to a preset verification rule, and after verification, can send sharing configuration data, such as immobilizer tokens for sharing, to the terminal.

[0109] S212, the vehicle activates all permissions of the key.

[0110] Specifically, after the vehicle and the terminal complete pairing, the vehicle can activate all permissions of the digital key. At this point, the pairing process of the digital key between the vehicle and the terminal is completed, and thereafter, the vehicle owner can control the vehicle using the terminal. It can be understood that, since the vehicle and the terminal have completed authentication and saving of the public key of the other party, a trusted relationship can be established between the two in the subsequent use stage, so that the terminal can control the vehicle, such as unlocking the vehicle door and activating the engine.

[0111] The above is a related introduction to the ICCE standard and the CCC standard. As can be known from the above related introduction, the digital key opening in the ICCE standard is realized remotely based on a server, the vehicle verifies the terminal based on a preset root key or a key obtained from the server, the user can remotely verify the identity at any time and any place and obtain the key in advance, and then interacts with the vehicle, which is a good experience and is also helpful for designing various commercial modes such as leasing and express delivery into the vehicle. The CCC standard obtains the digital key by pairing the terminal used by the vehicle owner with the vehicle used by the vehicle owner. In the pairing process, since the terminal of the vehicle owner and the vehicle have not communicated before, a mutually trusted relationship cannot be established, so the vehicle owner must carry the physical key to prove the identity of the vehicle owner and / or the key opening permission to initiate pairing. In addition, since the asymmetric key pair needs to be exchanged securely, only the certificate system constructed by relying on the PKI public key infrastructure and the user triggering the pairing mode can ensure the security of the pairing process to ensure that the vehicle is correctly paired with the device that has the key opening permission.

[0112] The technical solutions provided in the present application will be introduced below.

[0113] It should be noted that the technical solutions provided in the present application are mainly as follows: when the digital key system of the ICCE standard has been adopted in the vehicle, the vehicle can complete the opening of the digital key under the CCC standard between the terminal and the vehicle that implements the ICCE standard by using the mechanism defined in the ICCE standard, and the support for the digital key system of the CCC standard under the digital key system of the ICCE standard is realized, so that the data interaction required for the digital key pairing under the CCC system can be realized without implementing or executing the CCC pairing protocol.

[0114] Exemplarily, Figure 4a An application scenario is shown. As Figure 4a indicated, the terminal 100 and the server 300 can communicate through a network, and the vehicle 200 and the server 300 can also communicate through the network. The network can be a wired network or a wireless network, etc. For example, the network can be a local area network (LAN), and can also be a wide area network (WAN) (such as the Internet). The terminal 100 and the vehicle 200 can communicate through wireless communication technology. The wireless communication technology can include bluetooth technology, near field communication (NFC) technology, or ultra wide band (UWB) technology, etc. Exemplarily, the server 300 can be a server of a vehicle manufacturer.

[0115] The server 300 can issue a digital key under the ICCE standard for the terminal 100 and the vehicle 200. The server 300 can also provide the terminal 100 with data of the vehicle required for generating a digital key under the CCC standard, such as an identifier of the vehicle, a public key of the vehicle, a public key certificate of the vehicle, and key configuration data such as a mailbox size, key options, etc. The terminal 100 can generate a public-private key pair of the digital key of the terminal 100 under the CCC standard based on the data provided by the server 300, and send a key registration request to the server 300. After the server 300 completes the key registration, the terminal 100 can send the public key of the digital key (and / or a certificate chain of the public key certificate of the digital key) generated by it and the registration proof sent by the server 300 to the vehicle 200. In this way, the vehicle 200 obtains the data required in the digital key system under the CCC standard, and can then activate the permission of the digital key of the terminal 100, reaching a state of completing pairing under the CCC standard with the terminal 100. After that, the terminal 100 can control the vehicle 200.

[0116] Exemplarily, Figure 4b A system architecture of digital key issuance is shown. As Figure 4b indicated, the system architecture includes Figure 4aThe terminal 100, the vehicle 200 and the server 300 shown in the figure. Among them, the terminal 100 comprises a security unit 110, the security unit 110 comprises an ICCE car key application (applet) 111 and a CCC car key application 112. The ICCE car key application 111 is a car key application related to the ICCE standard, in which application at least the digital key under the ICCE standard can be securely received, stored and used; the CCC car key application 112 is a car key application related to the CCC standard, in which application at least the digital key under the CCC standard can be held. The security unit 110 can instantiate the ICCE car key application (applet) 111 and the CCC car key application 112 respectively. In one example, the ICCE car key application 111 can have a function of instructing the vehicle 200 to activate the digital key system under the CCC standard. In one example, an application program for applying for a digital key can also be provided on the terminal 100, through which at least the digital key can be applied for.

[0117] The vehicle 200 comprises an ICCE digital key system 210, a key management module 220 and a CCC digital key system 230. The ICCE digital key system 210 comprises an authentication module 211 and a key storage module 212, and the CCC digital key system 230 comprises an authentication module 231 and a key storage module 232.

[0118] The ICCE digital key system 210 can manage the digital key under the ICCE standard. In one example, the vehicle 200 and the terminal 100 have both implemented the ICCE standard, and the digital key has been issued. The authentication module 211 can detect whether the data related to the digital key under the CCC standard sent by the terminal 100 (i.e. the owner device holding the ICCE digital key, which can also be understood as a trusted device) or the server 300 (i.e. the server having the management right of the vehicle) obtained by the vehicle 200 is sent to the vehicle 200 by using the communication mechanism and / or security mechanism under the ICCE standard, and after detecting that the data received by the vehicle 200 is sent to the vehicle 200 by using the communication mechanism and / or security mechanism under the ICCE standard, the received data is sent to the key management module 220. In addition, the authentication module 211 can also detect whether the control instruction from the terminal 100 obtained by the vehicle 200 is legal based on the key authentication protocol between the terminal and the vehicle defined in the ICCE standard, etc. In one example, the key storage module 212 can store the digital key under the ICCE standard and / or the data related to the digital key under the ICCE standard.

[0119] The key management module 220 can have a configuration function for the CCC digital key system 230, which can configure and initialize the digital key under the CCC standard, etc. In one example, after the authentication module 211 in the ICCE digital key system 210 sends the data related to the digital key under the CCC standard to the key management module 220, the key management module 220 can authenticate the data obtained by it, and after determining that the data comes from a legal, trusted and key-authorized device and server, the data is sent to the key storage module 232 in the CCC digital key system 230.

[0120] The CCC digital key system 230 can manage the digital key under the CCC standard. In one example, the authentication module 231 can detect whether the control instruction based on the CCC standard obtained by the vehicle 200 from the terminal 100 is legal, etc. In one example, the key storage module 232 can store the digital key under the CCC standard and / or data related to the digital key under the CCC standard.

[0121] The server 300 can include but is not limited to a data processing module 310. The data processing module 310 can have a configuration function for the digital key under the CCC standard, which can provide the terminal 100 with at least part of the data required to generate the digital key under the CCC standard, and record the public key of the digital key, and generate a record certificate, etc.

[0122] It can be understood that in this application, in the case where the vehicle and the terminal have adopted the ICCE standard, the terminal can reuse the trust relationship and security mechanism under the ICCE standard system to securely obtain the data of the vehicle required to generate the digital key under the CCC standard from the server, so as to generate the digital key under the CCC standard, and ensure that the vehicle can ensure that the CCC digital key public key sent by the terminal comes from a legal and key-authorized owner device (holding the owner key under the ICCE system) based on the trust mechanism of the ICCE system, thereby realizing the support for the digital key system under the CCC standard in the digital key system under the ICCE standard, so as to realize the data interaction required for the digital key pairing under the CCC system without implementing or executing the CCC pairing protocol, reduce the development workload and PKI system cost, and improve the user experience.

[0123] An exemplary, Figure 5 A hardware structure schematic diagram of a terminal 100 provided by an embodiment of the present application is shown. As Figure 5 shown, the terminal 100 can include a processor 110, a memory 120 and a communication module 130.

[0124] The processor 110 can be a general-purpose processor or a special-purpose processor. For example, the processor 110 can include a central processing unit (CPU) and / or a baseband processor. The baseband processor can be configured to process communication data, and the CPU can be configured to implement corresponding control and processing functions, execute software programs, and process data of the software programs.

[0125] For example, the processor 110 can include one or more processing units. For example, the processor 110 can include one or more of an application processor (AP), a modem, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. In some embodiments, the terminal 100 can include one or more processors 110. Different processing units can be independent devices or can be integrated in one or more processors. For example, the processor 110 can generate a public-private key pair of a digital key under the CCC standard, generate a public key certificate of the digital key, and the like.

[0126] The memory 120 can store programs that can be executed by the processor 110. The memory 120 can also store data. The processor 110 can read the data stored in the memory 120. The memory 120 and the processor 110 can be separately provided. Alternatively, the memory 120 can also be integrated in the processor 110. For example, the memory 120 can store data related to the digital key and the like.

[0127] The communication module 130 can include at least one of a mobile communication module and a wireless communication module. Among them, when the communication module 130 includes a mobile communication module, the communication module 130 can provide a solution including wireless communication of 2G / 3G / 4G / 5G or the like applied to an electronic device. For example, global system for mobile communications (GSM), general packet radio service (GPRS), code division multiple access (CDMA), wideband code division multiple access (WCDMA), time-division code division multiple access (TD-SCDMA), long term evolution (LTE), new radio (NR), etc.

[0128] The communication module 130 can include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The communication module 130 can receive electromagnetic waves through at least one antenna, and perform filtering, amplification, etc. on the received electromagnetic waves, and transmit the processed electromagnetic waves to the modem for demodulation. The communication module 130 can also amplify signals modulated by the modem, and convert the signals into electromagnetic waves for radiation through the antenna. In some examples, at least part of the functional modules of the communication module 130 can be arranged in the processor 110. In some examples, at least part of the functional modules of the communication module 130 and at least part of the modules of the processor 110 can be arranged in the same device. When the communication module 130 includes a wireless communication module, the communication module 130 can provide a wireless communication solution applied to the terminal 100, including wireless local area networks (WLAN) (such as a wireless fidelity (Wi-Fi) network), Bluetooth (BT), a global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR) technology, etc. The communication module 130 can be one or more devices that integrate at least one communication processing module. The communication module 130 receives electromagnetic waves through an antenna, performs frequency modulation and filtering on the electromagnetic wave signals, and transmits the processed signals to the processor 110. The communication module 130 can also receive signals to be transmitted from the processor 110, perform frequency modulation and amplification on the signals, and convert the signals into electromagnetic waves for radiation through an antenna. For example, the communication module 130 can receive data transmitted by the server 300, or transmit data to the server 300, or transmit data to the vehicle 200, or receive data transmitted by the vehicle 200, etc.

[0129] It can be understood that the structure illustrated in the embodiments of the present application does not constitute a specific limitation on the terminal 100. In other embodiments of the present application, the terminal 100 can include more or fewer components than those illustrated, or combine certain components, or split certain components, or different component arrangements. The illustrated components can be implemented in hardware, software, or a combination of software and hardware. In some embodiments, the hardware structure of the vehicle 200 can have the same hardware structure as the terminal 100, or more or fewer components than the terminal 100, which is not limited herein.

[0130] For example, Figure 6A hardware structure schematic diagram of a server 300 provided by an embodiment of the present application is shown. As shown in the figure, the server 300 can include a processor 310, a network interface 320, and a memory 330. Figure 6

[0131] The processor 310 can be a general-purpose processor or a special-purpose processor. For example, the processor 210 can include a central processing unit (CPU) and / or a baseband processor. The baseband processor can be used to process communication data, and the CPU can be used to implement corresponding control and processing functions, execute software programs, and process data of the software programs. For example, the processor 210 can obtain data of a vehicle required for generating a digital key structure, record a public key of a digital key generated by a terminal, and the like.

[0132] The network interface 320 can optionally include a standard wired interface, a wireless interface (such as Wi-Fi, a mobile communication interface, and the like), and be controlled by the processor 310 to receive and transmit data, for example, receive data transmitted by the communication module 130 in the terminal 100 from a network, or transmit data to the terminal 100, or transmit data to the vehicle 200, and the like.

[0133] The memory 330 can store programs that can be run by the processor 310. The memory 330 can also store data (such as an identifier of a vehicle, a public key of a vehicle, a public key certificate of a vehicle, and the like). The processor 310 can read the data stored in the memory 330. The memory 330 and the processor 310 can be separately arranged. Alternatively, the memory 330 can also be integrated in the processor 310.

[0134] It can be understood that the structure shown in the embodiments of the present application does not constitute a specific limitation on the server 300. In other embodiments of the present application, the server 300 can include more or fewer components than shown in the figure, or combine certain components, or split certain components, or different arrangement of components. The components shown in the figure can be implemented in hardware, software, or a combination of software and hardware.

[0135] The above-described content will be described below in combination with Figure 7 The technical solutions provided by the present application will be described in detail. For example, Figure 7 A flowchart of a digital key pairing method provided by an embodiment of the present application is shown. As shown in the figure, the method can include the following steps: Figure 7

[0136] S701, the terminal establishes a connection with the server.

[0137] ​​Specifically, a connection can be established between the terminal and the server through a network. Illustratively, the vehicle owner can log in to an application related to the digital key on the terminal. When the vehicle owner successfully logs in to the application related to the digital key, a connection is established between the terminal and the server. The account of the vehicle owner logged in can have an association with the vehicle.

[0138] In one example, after the terminal establishes a connection with the server, a secure data channel can be established between the two to ensure the security of the data communication process. Illustratively, the two can reuse the security mechanism, service interface, software development kit (SDK), etc. in the key issuance / update process under the ICCE standard for data interaction.

[0139] S702, the terminal sends a first request to the server, and the first request is used to apply for opening the digital key under the CCC standard.

[0140] Specifically, after the terminal obtains the digital key application instruction issued by the vehicle owner, the terminal can send a first request to the server for applying for opening the digital key under the CCC standard. Illustratively, the terminal can reuse the communication mechanism in the key issuance / update process under the ICCE standard to send the first request to the server. Illustratively, the first request can include an encryption public key used for encrypting data, which can be used to encrypt the communication data between the terminal and the server.

[0141] In one example, the terminal can send the first request to the server when the vehicle owner applies for the digital key under the ICCE standard, for example, when the vehicle owner applies for opening the digital key in the ICCE car key application on the terminal, the terminal can send the first request. In addition, the terminal can also send the first request to the server when the vehicle owner has applied for opening the digital key under the ICCE standard and applies for opening the digital key under the CCC standard. The specific application can be determined according to the actual situation, which is not limited here.

[0142] S703, the server acquires first data in response to the first request, and the first data is used to generate a digital key structure.

[0143] Specifically, after the server acquires the first request, the server can acquire first data in response to the first request, and the first data is used to generate a digital key structure.

[0144] In one example, the first data can include one or more of a vehicle identifier, a vehicle public key, a slot identifier, authorized public keys, key options, a private mailbox size, and a confidential mailbox size.

[0145] In one example, the first data can be pre-configured in the server by a manufacturer of the vehicle, so that the server can directly read the first data.

[0146] In one example, the server can also obtain the first data from the vehicle. At this time, the server can send a data obtaining request to the vehicle. After receiving the data obtaining request, the vehicle can send the first data to the server, so that the server obtains the first data.

[0147] In one example, after the server obtains the first request, the identity of the vehicle owner can be verified, and the first data can be obtained after the verification is passed, thereby improving security. For example, the server determines that the information of the vehicle owner and the vehicle carried in the first request is consistent with the information of the vehicle owner and the vehicle owned by the vehicle owner stored by the server, and the verification is passed.

[0148] Optionally, after the identity of the vehicle owner is verified, the server can also generate a first credential, which can be used to indicate the public key of the digital key of the terminal stored by the vehicle. Wherein, when the terminal interacts with the vehicle subsequently, the vehicle stores the public key of the digital key of the terminal only after obtaining the first credential, thereby making the vehicle confirm the reliability of the source of the public key, adding a layer of protection, and improving data security.

[0149] S704, the server sends the first data to the terminal.

[0150] Specifically, after obtaining the first data, the server can send the first data to the terminal. For example, the server can use the security communication mechanism in the key issuance / update process under the ICCE standard to send the first data to the terminal when sending the first data. For example, the first data can be protected using the encryption public key in the first request.

[0151] S705, the terminal generates a public-private key pair of the digital key, and generates a digital key structure meeting the requirements of the CCC standard based on the first data.

[0152] Specifically, after the terminal obtains the first data, the terminal can generate a public-private key pair of the digital key, and generate a digital key structure meeting the CCC standard requirements based on the first data.

[0153] In one example, as shown in FIG. 7, the digital key structure meeting the CCC standard requirements can include: a vehicle identifier, an endpoint identifier, a digital key identifier, a slot identifier, an instance CA identifier, key options, a device public key, a vehicle public key, authorized public keys, a private mailbox, and a confidential mailbox. Figure 3

[0154] Specifically, the node identifier (endpoint identifier), the digital key identifier (digital key identifier), and the terminal public key (device public key) can be generated by the terminal. The applet instance CA identifier (instance CA identifier) can be provided by the terminal. The vehicle identifier (vehicle identifier), the slot identifier (slot identifier), the key options (key options), the vehicle public key (vehicle public key), and the authorized public key group (authorized public keys) can be provided by the server. For the private mailbox (private mailbox) and the confidential mailbox (confidential mailbox), the terminal can generate based on the private mailbox size and the confidential mailbox size provided by the server.

[0155] S706, the terminal writes data into the digital key structure.

[0156] Specifically, after the terminal generates the digital key structure, the terminal can write data into the digital key structure.

[0157] ​Exemplarily, the terminal can obtain the data of the vehicle contained in the private mailbox and the confidential mailbox from the server. Among them, the data of the vehicle contained in the private mailbox and the confidential mailbox can be pre-stored in the server. In addition, the server can also obtain the data of the vehicle contained in the private mailbox and the confidential mailbox by communicating with the vehicle.

[0158] In one example, the terminal completes instantiation of the CCC applet in its own secure element (SE) (such as the secure element 110 shown in FIG. 11), and generates a digital key structure according to the first data, and generates a public-private key pair of the digital key, and writes the first data into the digital key structure, that is, can enter the state of terminal-side pairing completion under the CCC standard. Figure 4b

[0159] In one example, the terminal completes instantiation of the CCC applet in its own secure element (SE) (such as the secure element 110 shown in FIG. 11), and generates a digital key structure according to the first data, and generates a public-private key pair of the digital key, and writes the first data into the digital key structure, that is, can enter the state of terminal-side pairing completion under the CCC standard. Figure 4b

[0160] S707, the terminal sends data containing at least the public key of the digital key to the vehicle.

[0161] Specifically, after the terminal writes data into the digital key structure, the terminal can send data containing at least the public key of the digital key to the vehicle, such as: the public key of the digital key, the public key certificate of the digital key, the certificate chain of the digital key, etc.

[0162] In one example, in the implementation based on the ICCE protocol, when the terminal interacts with the vehicle through the vehicle key applet (such as the ICCE vehicle key applet 111 shown in FIG. 11) under the ICCE standard, when the terminal detects that there is activation data of the digital key under the CCC standard, or other indication information indicates that the digital key under the CCC standard needs to be activated, the terminal can indicate that the current interaction needs to perform CCC protocol and activation of the digital key through a special indication bit in the ICCE instruction in the transaction process, such as through the P1P2 value of the instruction, or other custom labels. Figure 4b

[0163] ​​​In addition, the terminal can generate a digital key (DK) certificate (i.e., a public key certificate of the digital key) or a certificate chain conforming to the CCC standard, and save it in a vendor-defined field of the ICCE protocol, such as 9F05Cardinfo1, or other vendor-defined fields or binary files. In this way, the DK certificate or certificate chain is sent to the vehicle, and data containing at least the public key of the digital key is sent to the vehicle.

[0164] S708, the vehicle stores the public key of the digital key of the terminal.

[0165] Specifically, after the vehicle obtains the data containing at least the public key of the digital key sent by the terminal, the vehicle can store the public key of the digital key. At this point, the pairing of the digital key between the vehicle and the terminal under the CCC standard is completed, and the terminal and the vehicle can then communicate using the digital key system under the CCC standard.

[0166] In one example, the vehicle and the terminal can first perform authentication, and after the authentication is completed, the vehicle can trust the terminal and obtain the data containing at least the public key of the digital key sent by the terminal, such as the public key of the digital key and other necessary data (such as key nickname, etc.).

[0167] In one example, the vehicle uses the key under the ICCE standard to complete the authentication of the terminal through the authentication module in the ICCE digital key system in the vehicle (such as the authentication module 211 in the Figure 4b vehicle can perform data integrity verification and other additional verification, such as verifying the first credential, to ensure that the data comes from the owner device holding the digital key, and after the verification is passed, the vehicle can configure the data to the CCC digital key system to activate the digital key under the CCC standard.

[0168] In one example, in the Figure 7 terminal, server, and vehicle can fully comply with the ICCE standard, and when communicating, they can communicate based on the communication mechanism and security mechanism defined in the ICCE standard. The security mechanism can include business verification, user identity verification, trust relationship verification, data delivery, etc. It can be understood that Figure 7 In the terminal and server, the communication mechanism, business verification mechanism, user identity verification mechanism, and secure data delivery mechanism defined in the ICCE standard are used, the communication mechanism and digital key and related data verification trust relationship verification mechanism between the terminal and the vehicle are used, and the communication mechanism and security mechanism defined in the ICCE standard are also used between the vehicle and the server.

[0169] It can be understood that, Figure 7 In the ICCE standard digital key system, based on the trust relationship among the vehicle, the terminal and the server, the data required for the digital key pairing under the CCC standard is remotely issued by the server, and the mechanism defined in the ICCE standard is used to complete the opening of the digital key under the CCC standard between the terminal and the vehicle implementing the ICCE standard, so as to realize the support for the CCC standard digital key system under the ICCE standard, so that the data interaction required for the digital key pairing under the CCC system can be realized without implementing or executing the CCC pairing protocol, the development workload and the PKI system cost are reduced, and the user experience is improved.

[0170] Exemplarily, Figure 8 A flowchart of another digital key pairing method provided by the embodiment of the application is shown. As Figure 8 shown, the method can include the following steps:

[0171] S801, the terminal establishes a connection with the server.

[0172] Specifically, the terminal and the server can establish a connection through a network. For details, see the description in S701 in the above Figure 7 , which will not be repeated here.

[0173] S802, the terminal sends a first request to the server, and the first request is used to apply for opening the digital key under the CCC standard.

[0174] Specifically, after obtaining the digital key application instruction issued by the vehicle owner, the terminal can send a first request for applying for opening the digital key under the CCC standard to the server.

[0175] S803, the server acquires first data in response to the first request, and the first data is used to generate a digital key structure.

[0176] Specifically, after the server acquires the first request, the server can acquire first data in response to the first request, and the first data is used to generate a digital key structure. For details, see the description in S702 in the above Figure 7 , which will not be repeated here.

[0177] S804, the server sends the first data to the terminal.

[0178] Specifically, after acquiring the first data, the server can send the first data to the terminal.

[0179] S805, the terminal generates a public-private key pair of the digital key, and generates a digital key structure meeting the requirements of the CCC standard based on the first data.

[0180] Specifically, after obtaining the first data, the terminal can generate a public / private key pair for the digital key, and generate a digital key structure that conforms to the CCC standard based on the first data. See above for details. Figure 7 The description in S705 will not be repeated here. In one example, after the terminal obtains the first data, it can activate the intermediate certificate of the terminal-side certificate chain of the CCC system, generate a DK certificate that meets the CCC system requirements, and prepare a filing request (key tracking request).

[0181] S806. The terminal sends a first filing request to the server. The first filing request includes the public key of the digital key. The first filing request is used to request the filing of the public key of the digital key.

[0182] Specifically, after generating the public and private key pair and digital key structure of the digital key, the terminal can send a first filing request to the server. The first filing request includes the public key of the terminal's digital key and is used to request the filing of the public key of the terminal's digital key.

[0183] In one example, the first registration request may include proof of pairing between the terminal and the vehicle. This proof could be that the terminal guarantees the public key of the digital key it generates using a root of trust in the ICCE system (e.g., by securely uploading the public key to the server using the SCP03 secure channel protocol), or it could sign the public key using a pre-configured device identity key, or it could self-sign the public key using the digital key's private key. Since the server already knows the pairing relationship between the terminal and the vehicle when generating the first data, this proof of pairing can be used to determine that the public key of the digital key in the registration request was generated based on the first data and originated from the terminal that issued the first data.

[0184] For example, the terminal can send a first filing request to the server through the communication mechanism between the terminal and the server under the ICCE standard, in order to prove to the server that the public key requested for filing in the first filing request and / or the pairing proof between the terminal and the vehicle comes from the terminal and not from other devices.

[0185] S807. The server registers the public key of the terminal's digital key and generates the first registration certificate.

[0186] Specifically, after obtaining the first record request, the server can record the public key of the digital key of the terminal, and generate a first record certificate. The first record certificate is mainly used to prove that the server has completed the record of the public key of the digital key of the terminal. For example, the server can generate the first record certificate by storing the public key of the digital key of the terminal and signing the public key of the digital key of the terminal or the pairing relationship between the terminal and the vehicle. For example, the first record certificate can include a key tracking signature.

[0187] In one example, when the first record request includes a pairing certificate between the terminal and the vehicle, the server can also store the pairing certificate to record the pairing certificate.

[0188] S808, the server sends the first record certificate to the terminal.

[0189] Specifically, after recording the public key of the digital key of the terminal, the server can send the first record certificate to the terminal. In addition, the server can also send some other necessary data to the terminal, such as an immo token for sharing, or other data not issued in S804, etc.

[0190] S809, the terminal writes data in the digital key structure in response to the obtained first record certificate.

[0191] Specifically, after obtaining the first record certificate, the terminal can write data in the digital key structure generated by the terminal in response to the obtained first record certificate. When writing data, the terminal can write in stages, that is, write a part after obtaining a part of data, or write all at once, that is, write after obtaining all the data. At this time, the terminal has all the data required for sharing under the CCC standard, that is, the digital key structure. At this time, the terminal enters the pairing completion state.

[0192] In one example, the data required to be written by the terminal can be issued by the server at one time, or can be issued by the server in stages, which can be determined according to actual conditions, and is not limited here.

[0193] For example, the terminal can obtain the data of the vehicle contained in the private mailbox and the confidential mailbox from the server. The data of the vehicle contained in the private mailbox and the confidential mailbox can be pre-stored in the server. In addition, the server can also obtain the data of the vehicle contained in the private mailbox and the confidential mailbox by communicating with the vehicle.

[0194] S810, the terminal sends data at least including the public key of the digital key and the first record certificate to the vehicle.

[0195] Specifically, after the terminal writes data into the digital key structure, it can send data containing at least the public key of the digital key and the first record proof to the vehicle. For details, see the description in S707 above. Figure 7 The description in S707 above is not repeated here.

[0196] S811, the vehicle verifies the first record proof, and stores the public key of the digital key after verification.

[0197] Specifically, after the vehicle obtains data containing at least the public key of the digital key and the first record proof, it can verify the first record proof according to the preset verification rule. When the verification is passed, it can be known that the data containing at least the public key of the digital key obtained by the vehicle comes from a legitimate owner device (i.e. a trusted device), and at this time, the vehicle can store the public key of the digital key of the terminal. At this point, the pairing of the digital key between the vehicle and the terminal under the CCC standard is completed, and then the terminal and the vehicle can communicate using the digital key system under the CCC standard. For details, see the description in S708 above. Figure 7 The description in S708 above is not repeated here.

[0198] In one example, in Figure 8 , the terminal, the server, and the vehicle can fully comply with the ICCE standard, and when communicating, they can communicate based on the communication mechanism and the security mechanism defined in the ICCE standard. Among them, the security mechanism can include business verification, user identity verification, trust relationship verification, data delivery, etc. It can be understood that Figure 8 The communication mechanism, business verification mechanism, user identity verification mechanism, and secure data delivery mechanism between the terminal and the server in

[0199] It can be understood that Figure 8 and Figure 7 The main difference is: Figure 8 In , the terminal needs to send the generated public key to the server for record, and the vehicle further confirms that the key comes from a legitimate terminal through the record proof issued by the server, thereby further improving security.

[0200] It can be understood that Figure 8In the ICCE standard digital key system, based on the trust relationship among the vehicle, the terminal and the server, the data required for the CCC standard digital key pairing is remotely issued by the server, and the mechanism defined in the ICCE standard is used to complete the opening of the CCC standard digital key between the terminal and the vehicle implementing the ICCE standard, so as to realize the support of the CCC standard digital key system in the ICCE standard digital key system, so that the data interaction required for the CCC system digital key pairing can be realized without implementing the CCC pairing protocol, the development workload and the PKI system cost are reduced, and the user experience is improved.

[0201] The above is the introduction of the CCC standard digital key pairing process in the ICCE standard key system provided by the present application. In addition, the CCC standard digital key sharing can also be performed in the ICCE standard key system. See the description below.

[0202] Exemplarily, Figure 9 A flowchart of a digital key sharing method provided by an embodiment of the present application is shown. As Figure 9 shown, the method can include the following steps:

[0203] S901, the server acquires the sharing operation instruction issued by the vehicle owner.

[0204] Specifically, the server can communicate with the terminal used by the vehicle owner, so that when the vehicle owner initiates the sharing operation on the terminal used by him, the server can acquire the sharing operation instruction issued by the vehicle owner. Exemplarily, the sharing operation instruction can include the identity of the terminal to be shared, and the vehicle operation permission granted by the vehicle owner to the shared terminal, such as: digital key permission, validity period, sharing password information, etc.

[0205] S902, the server acquires first data, and the first data is used to generate a digital key structure.

[0206] Specifically, after the server acquires the sharing operation instruction, the server can acquire the first data, and the first data is used to generate a digital key structure. See the description in S702 in the above Figure 7 , which will not be repeated here.

[0207] S903, the server sends the first data to the terminal to be shared.

[0208] Specifically, after acquiring the first data, the server can send the first data to the terminal to be shared. Exemplarily, the server can reuse the security mechanism in the key issuance / update process in the ICCE standard to send the first data to the terminal to be shared when sending the first data.

[0209] In one example, the to-be-shared terminal and the server can first establish a connection, and then a secure data channel can be established between the two to ensure the security of the data communication process. For example, the two can reuse the security communication mechanism in the key issuance / update process under the ICCE standard for data interaction. For example, after the two establish a connection, after the server obtains the digital key application for taking of the to-be-shared terminal, the server can verify the to-be-shared terminal based on the identity of the to-be-shared terminal included in the sharing operation instruction obtained by the server, and when the verification is passed, the server sends the first data to the to-be-shared terminal. In addition, the server can also verify the to-be-shared terminal in the manner of verifying the identity of the vehicle owner described in the above Figure 1 , which is described in detail above and will not be repeated here.

[0210] In one example, after the to-be-shared terminal and the server establish a connection, the to-be-shared terminal can send a request to the server for applying for opening a digital key under the CCC standard. When the server obtains the request sent by the to-be-shared terminal, the server can obtain the first data and send the first data to the to-be-shared terminal.

[0211] S904, the to-be-shared terminal generates a public-private key pair of the digital key, and generates a digital key structure meeting the requirements of the CCC standard based on the first data.

[0212] Specifically, after the to-be-shared terminal obtains the first data, the to-be-shared terminal can generate a public-private key pair of the digital key, and generate a digital key structure meeting the requirements of the CCC standard based on the first data. For details, see the description of S705 in the above Figure 7 , which will not be repeated here.

[0213] S905, the to-be-shared terminal sends a second record request to the server, the second record request including the public key of the digital key of the to-be-shared terminal, and the second record request being used to request to record the public key of the digital key of the to-be-shared terminal.

[0214] Specifically, after the to-be-shared terminal generates a public-private key pair of the digital key and a digital key structure, the to-be-shared terminal can send a second record request to the server, the second record request including the public key of the digital key of the to-be-shared terminal, and the second record request being used to request to record the public key of the digital key of the to-be-shared terminal.

[0215] In one example, the second registration request can include a pairing proof between the sharing terminal and the vehicle. The pairing proof can be a public key of a digital key generated by a root of trust in the ICCE system for the sharing terminal (such as securely uploading the public key to the server using the SCP03 secure channel protocol), or signed by a pre-installed device identity key, or self-signed by the private key of the digital key. Since the server has learned the pairing relationship between the sharing terminal and the vehicle when generating the first data, here, the pairing proof can be used to determine that the public key of the digital key in the registration request is generated based on the first data and comes from the sharing terminal that issued the first data.

[0216] For example, the sharing terminal can use the SCP03 secure channel protocol in the ICCE standard to prove to the server that the source of the second registration request is legitimate, and then the server of the sharing terminal communicates with the business server (i.e., the server described in the Figure 9 For example, the sharing terminal can use the SCP03 secure channel protocol in the ICCE standard to prove to the server that the source of the second registration request is legitimate, and then the server of the sharing terminal communicates with the business server (i.e., the server described in the

[0217] For example, the sharing terminal can use the SCP03 secure channel protocol in the ICCE standard to prove to the server that the source of the second registration request is legitimate, and then the server of the sharing terminal communicates with the business server (i.e., the server described in the

[0218] S906, the server registers the public key of the digital key of the sharing terminal and generates a second registration proof.

[0219] Specifically, after obtaining the second registration request, the server can register the public key of the digital key of the sharing terminal and generate a second registration proof. The second registration proof is mainly used to prove that the server has completed the registration of the public key of the digital key of the sharing terminal. For example, the server can generate the second registration proof by storing the public key of the digital key of the sharing terminal and signing the public key of the digital key of the sharing terminal. For example, the second registration proof can include a key tracking signature.

[0220] In one example, the second registration proof can also include an attestation package, which can be used to construct the data structure of the digital key in the digital key sharing process. For example, as shown in Figure 10As shown, the data structure of the authentication data packet can include one or more of the public key of the digital key of the terminal to be shared (friend public key), profile, sharing password information, slot identifier, validity start / end, key friendly name. Among them, the profile can include data such as operation permission. The sharing password information can include information about whether the vehicle owner device policy requires the vehicle to request a sharing password from the friend before activating the shared digital key.

[0221] In one example, as shown in Figure 11 The authentication data packet (attestation package) can also include the signature of the vehicle owner device (owner signature). At this time, the server can send a signature request to the vehicle owner device, and after the vehicle owner device signs, such as using the RSA key of the CCC for digital signature operation, or using the ICCE protocol key for encryption or message authentication code (MAC) operation, the vehicle owner device signature can be obtained. The authentication certificate after signing indicates that this sharing is authorized by the vehicle owner device, further improving security.

[0222] S907, the server sends a second record certificate to the terminal to be shared.

[0223] Specifically, after the server records the public key of the terminal to be shared, the server can send a second record certificate to the terminal to be shared.

[0224] S908, the terminal to be shared writes data into the digital key structure in response to the obtained second record certificate.

[0225] Specifically, after the terminal to be shared obtains the first record certificate, it can write data into the digital key structure it generates. Among them, the terminal to be shared can write data in stages, that is, write a part of data after obtaining a part of data, or write all data at a time, that is, write after obtaining all data. At this time, the terminal to be shared has all the data required for sharing under the CCC standard, that is, the digital key structure. At this time, the terminal to be shared enters the state of completed pairing.

[0226] In one example, the data required to be written by the terminal to be shared can be issued by the server at a time, or can be issued by the server in stages, which can be determined according to actual conditions, which is not limited here.

[0227] Exemplarily, the data of the vehicle contained in the private mailbox and the confidential mailbox can be obtained by the sharing terminal from the server. Wherein, the data of the vehicle contained in the private mailbox and the confidential mailbox can be pre-stored in the server. In addition, the server can also obtain the data of the vehicle contained in the private mailbox and the confidential mailbox by communicating with the vehicle.

[0228] S909, the sharing terminal sends the data containing at least the public key of the digital key and the second record proof to the vehicle.

[0229] Specifically, after writing the data into the digital key structure, the sharing terminal can send the data containing at least the public key of the digital key and the second record proof to the vehicle.

[0230] S910, the vehicle verifies the second record proof, and stores the public key of the digital key of the sharing terminal after verification.

[0231] Specifically, after obtaining the data containing at least the public key of the digital key and the second record proof, the vehicle can verify the second record proof according to the preset verification rule. When the verification is passed, it can be known that the data containing at least the public key of the digital key obtained by the vehicle comes from the sharing terminal (i.e. trusted device), at this time, it can store the public key of the digital key. At this time, the sharing of the digital key under the CCC standard is completed, and then the sharing terminal and the vehicle can use the digital key system under the CCC standard to communicate.

[0232] In one example, after performing S904, the sharing terminal can directly perform S908 and the steps after S908, i.e. omit the intermediate record process, i.e. omit S905 to S907, and omit sending the second record proof when performing the steps after S908. The specific implementation can be determined according to actual conditions, which is not limited here.

[0233] In one example, after performing S904, the sharing terminal can directly perform S908 and the steps after S908, i.e. omit the intermediate record process, i.e. omit S905 to S907, and omit sending the second record proof when performing the steps after S908. The specific implementation can be determined according to actual conditions, which is not limited here. Figure 9 In one example, the sharing terminal, the server and the vehicle can completely comply with the ICCE standard, and can communicate based on the communication mechanism and the security mechanism defined by the ICCE standard when communicating. Wherein, the security mechanism can include business verification, user identity verification, trust relationship verification, data delivery and the like. It can be understood that, Figure 9The communication mechanism between the sharing terminal and the server, the service verification mechanism, the user identity verification mechanism, and the security data delivery mechanism defined in the ICCE standard are adopted between the sharing terminal and the server, the communication mechanism between the sharing terminal and the vehicle, and the trust relationship verification mechanism such as the verification of the digital key and related data defined in the ICCE standard are adopted between the sharing terminal and the vehicle, and the communication mechanism and the security mechanism defined in the ICCE standard are also adopted between the vehicle and the server.

[0234] It can be understood that, Figure 9 In the ICCE standard digital key system, based on the trust relationship among the vehicle, the owner device, and the server, the data required for sharing the digital key in the CCC standard is remotely delivered by the server, so that the secure communication mechanism between the owner device and the shared device is not required, that is, the sharing of the digital key in the CCC standard can be completed in the ICCE standard digital key system, the sharing process is simplified, and the support for the digital key system in the CCC standard is added in the ICCE standard digital key system, so that the data interaction required for sharing the CCC system without implementing the CCC sharing protocol is realized, the development workload and the PKI system cost are reduced, and the user experience is improved.

[0235] Next, based on the content described above, a digital key opening method provided by an embodiment of the present application is introduced. It can be understood that the method is another expression of the content described above, and the two are combined. The method is based on the content described above, and part or all of the content in the method can be referred to the related description in the above.

[0236] Please refer to Figure 12 , Figure 12 is a flowchart of a digital key opening method provided by an embodiment of the present application. The method can be executed by any device, equipment, platform, or device cluster with computing and processing capabilities.

[0237] In Figure 12 , the first device, the second device, and the server are pre-configured with a first service protocol, wherein the first device can apply for opening a first digital key under the first service protocol. Exemplarily, Figure 12 The first device in the above can be a terminal such as a mobile phone, for example, the first device can be Figure 4a the terminal 100 shown in FIG. 1, the second device can be a vehicle, a security door, or the like, for example, the second device can be Figure 4a the vehicle 200 shown in FIG. 2. The first device can control the second device through a digital key. In one example, the first device can also be a sharing terminal described in the above Figure 9 Exemplarily, in the aboveFigure 12 In some embodiments, the first service protocol can be an ICCE standard protocol, and the second service protocol can be a CCC standard protocol.

[0238] As shown in Figure 12 The digital key opening method can include the following steps:

[0239] S1201, the first device sends a target request to the server, and the target request is used to request to apply for opening a second digital key under a second service protocol.

[0240] Specifically, after obtaining the digital key application instruction for distribution, the first device can send a target request to the server for applying for opening a second digital key under a second service protocol. For example, the target request can be the first request described above.

[0241] In one example, the first device can reuse the communication mechanism in the key distribution / update process under the first service protocol to send the target request to the server.

[0242] In one example, the target request can be sent when the user applies for a first digital key under the first service protocol using the first device, or can be generated when the user has applied for a first digital key and applies for a second digital key.

[0243] S1202, the server responds to the target request, obtains target data, and sends the target data to the first device using a first communication mechanism defined by the first service protocol, and the target data is used to construct the data structure of the second digital key.

[0244] Specifically, after obtaining the target request, the server can obtain the target data used to construct the data structure of the second digital key. For example, the target data can be pre-configured in the server, or can be obtained from the second device in real time or in advance. When the server obtains the target data, the server can send the target data to the first device using a first communication mechanism defined by the first service protocol. For example, the target data can be the first data described above. For example, the first communication mechanism refers to the communication mechanism between the first device and the server defined by the first service protocol. For example: the communication mechanism between devices through key encryption / decryption data to provide security protection.

[0245] In one example, the target data can include one or more of the following: an identifier of the second device, a public key of the second device, a box position identifier, an authorized public key group, key capability data, a private mailbox size, or a confidential mailbox size.

[0246] S1203, the first device generates a public key and a private key of the second digital key in response to the target data, constructs a first data structure based on at least the target data, and writes at least part of the target data into the first data structure.

[0247] Specifically, after obtaining the target data, the first device can generate a public key and a private key of the second digital key, construct a first data structure based on at least the target data, and write at least part of the target data into the first data structure. At this point, the first device enters a state of completing pairing on the first device side under the second service protocol.

[0248] In one example, the first data structure can be a digital key structure conforming to the CCC standard requirement as described above. Figure 3

[0249] For example, the first data structure includes one or more of the following: a second device identifier, a first device internal identifier of the second digital key, a digital key identifier, a box identifier, an instance CA identifier, key capability data, a public key of the second digital key, a public key of the second device, an authorized public key group, a private mailbox, or a confidential mailbox. The first device internal identifier of the second digital key can be understood as the node identifier described above. Figure 3

[0250] In the first data structure, the first device internal identifier of the second digital key, the digital key identifier, the box identifier, the instance CA identifier, and the public key of the second digital key can all be provided by the first device. The second device identifier, the box identifier, the key capability data, the public key of the second device, and the authorized public key group can all be obtained from the target data. The private mailbox and the confidential mailbox can be created by the first device based on the target data.

[0251] In one example, before writing at least part of the target data into the first data structure, the first device can send a target registration request to the server using the first communication mechanism defined by the first service protocol, where the target registration request is used to request registration of the public key of the second digital key. After obtaining the target registration request, the server can register the public key of the second digital key and generate a target registration certificate, where the target registration certificate is used to prove that the server has completed the registration of the public key of the second digital key. Then, the server can send the target registration certificate to the first device using the first communication mechanism defined by the first service protocol. Finally, the first device can obtain the target registration certificate sent by the server. For example, the target registration certificate can be the first registration certificate described above, or the second registration certificate described above. Figure 8 Figure 9 ​​​​

[0252] S1204, the first device sends a first message to the second device by using a second communication mechanism defined by the first service protocol, the first message includes the public key of the second digital key, and the first message is used to instruct the second device to store the public key of the second digital key.

[0253] Specifically, after the first device writes data into the first data structure, the first device has completed the state of completing the digital key pairing on its own side, at this time, the first device can send a first message to the second device by using a second communication mechanism defined by the first service protocol, the first message includes the public key of the second digital key, and the first message is used to instruct the second device to store the public key of the second digital key. For example, the second communication mechanism refers to the communication mechanism between the first device and the second device defined by the first service protocol. For example, the communication mechanism between the devices provides security protection based on the digital key, the key and the authentication protocol.

[0254] In one example, after the first device obtains the target record certificate sent by the server, the first device can also add the target record certificate in the first message. In this way, the second device can further confirm that the public key of the second digital key comes from a legal device through the record certificate issued by the server, thereby further improving the security.

[0255] S1205, the second device stores the public key of the second digital key in response to the first message.

[0256] Specifically, after the second device obtains the first message, the second device can store the public key of the second digital key. At this time, the opening of the second digital key between the first device and the second device under the second service protocol is completed, and then the first device and the second device can use the second digital key system to communicate, and the first device can control the second device by using the second digital key.

[0257] In one example, when the first message includes the target record certificate, the second device can verify the target record certificate according to a preset verification rule, and when the verification is passed, the second device can know that the public key of the second digital key obtained by the second device comes from a legal device, and at this time, the second device can store the public key of the second digital key.

[0258] In one example, the first device and the second device are each configured with a digital key system matched with the first digital key and a digital key system matched with the second digital key. In other words, the first device and the second device are each configured with two sets of digital key systems, and different digital key systems can support different service protocols.

[0259] Therefore, the digital key system under the first service protocol is realized, based on the trust relationship among the first device, the second device and the server, the data required for opening the digital key under the second service protocol is remotely issued by the server, the opening of the digital key under the second service protocol is completed between the first device and the second device under the second service protocol by using the mechanism defined under the first service protocol, the support for the digital key system under the second service protocol is added in the digital key system under the first service protocol, and therefore, the data interaction required for opening the digital key under the second service protocol is realized without implementing or executing the pairing protocol under the second service protocol, the development workload and the PKI system cost are reduced, and the user experience is improved.

[0260] It can be understood that the execution sequence of each step in any embodiment of the present application can be adjusted according to actual conditions without contradiction, and the adjusted technical solution is also within the scope of the present application. In addition, each step in any embodiment of the present application can also be selectively executed, which is not limited here.

[0261] Based on the method in the above embodiment, the present embodiment further provides a chip. Please refer to Figure 13 , Figure 13 FIG. 1 is a structural schematic diagram of a chip provided by the present embodiment. As shown in Figure 13 , the chip 1300 includes one or more processors 1301 and interface circuits 1302. Optionally, the chip 1300 can also include a bus 1303. Wherein:

[0262] The processor 1301 can be an integrated circuit chip with a processing capability of signals. In the implementation process, each step of the above method can be completed by integrated logic circuits of hardware in the processor 1301 or instructions in the form of software. The above processor 1301 can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. Each method and step disclosed in the present embodiment can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor. The interface circuit 1302 can be used for sending or receiving data, instructions or information. The processor 1301 can process the data, instructions or other information received by the interface circuit 1302, and can send the processed information through the interface circuit 1302.

[0263] Optionally, the chip further includes a memory, which can include a read-only memory and a random access memory, and provides the processor with operation instructions and data. A part of the memory can further include a non-volatile random access memory (NVRAM). Optionally, the memory stores executable software modules or data structures, and the processor can execute corresponding operations by calling operation instructions stored in the memory (which can be stored in an operating system).

[0264] Optionally, the interface circuit 1302 can be used to output the execution result of the processor 1301.

[0265] It should be noted that the functions of the processor 1301 and the interface circuit 1302 respectively can be realized by hardware design, software design, or a combination of hardware and software, which is not limited here.

[0266] It should be understood that each step of the above method embodiments can be completed by a logic circuit in the form of hardware in the processor or instructions in the form of software. The chip can be applied to the terminal 100, the vehicle 200 or the server 300 in the above Figure 4a , to realize the method provided in the embodiments of the present application.

[0267] It can be understood that the processor in the embodiments of the present application can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. The general-purpose processor can be a microprocessor or any conventional processor.

[0268] The method steps in the embodiments of the present application can be implemented by hardware, or by a combination of software and hardware executed by a processor. The software instructions can be composed of a corresponding software module, which can be stored in a random access memory (RAM), a flash memory, a read-only memory (ROM), a programmable read-only memory (PROM), an erasable PROM (EPROM), an electrically EPROM (EEPROM), a register, a hard disk, a mobile hard disk, a CD-ROM, or any other form of storage medium well known in the art. An exemplary storage medium is coupled to a processor, so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an ASIC.

[0269] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware, or any combination thereof. When implemented by software, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted by the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center by wire (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. integrated with one or more available media. The available media can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid state disk (SSD)), etc.

[0270] It can be understood that the various numerical numbers involved in the embodiments of the present application are only for the convenience of differentiation, and do not limit the scope of the embodiments of the present application.

Claims

1. A digital key opening method characterized by, The method is applied to a first device, wherein a first service protocol has been pre-configured between the first device, a second device and a server, and the first device can open a first digital key under the first service protocol, and the method comprises the following steps: sending a target request to the server, the target request being used for requesting to apply for opening a second digital key under a second service protocol; obtaining target data sent by the server by using a first communication mechanism defined by the first service protocol, the target data being used for constructing a first data structure of the second digital key; in response to the obtained target data, generating a public key and a private key of the second digital key, constructing a first data structure of the second digital key based on at least the target data, and writing at least part of data in the target data into the first data structure; sending a first message to the second device by using a second communication mechanism defined by the first service protocol, the first message comprising the public key of the second digital key, and the first message being used for instructing the second device to store the public key of the second digital key.

2. The method of claim 1, wherein, Before the step of writing at least part of data in the target data into the first data structure, the method further comprises the following steps: sending a target record request to the server by using the first communication mechanism defined by the first service protocol, the target record request being used for requesting to record the public key of the second digital key; obtaining a target record proof sent by the server, the target record proof being used for proving that the server has completed the recording of the public key of the second digital key.

3. The method of claim 2, wherein, The first message further comprises the target record proof.

4. The method according to any of claims 1 to 3, characterized in that, The target data comprises one or more of the following: an identifier of the second device, a public key of the second device, a box identifier, an authorized public key group, key capability data, a private mailbox size, or a confidential mailbox size.

5. The method according to any one of claims 1 to 3, characterized in that, The first data structure comprises one or more of the following: the second device identifier, an identifier defined by the first device for the second digital key, a digital key identifier, a box identifier, an instance CA identifier, key capability data, the public key of the second digital key, the public key of the second device, an authorized public key group, a private mailbox, or a confidential mailbox.

6. The method of claim 5, wherein, The identifier defined by the first device for the second digital key, the digital key identifier, the box identifier, the instance CA identifier and the public key of the second digital key are all provided by the first device.

7. The method of claim 5, wherein, The second device identifier, the box identifier, the key capability data, the public key of the second device and the authorized public key group are all obtained from the target data, and the private mailbox and the confidential mailbox are created by the first device based on the target data.

8. The method of any one of claims 1-3, wherein, Both the first device and the second device are configured with a digital key system matched with the first digital key and a digital key system matched with the second digital key.

9. The method according to any one of claims 1 to 3, characterized in that, The first service protocol is an ICCE standard protocol, and the second service protocol is a CCC standard protocol.

10. The method of any one of claims 1-3, wherein, The first communication mechanism is a communication mechanism based on key encryption / decryption between devices to provide security protection. The second communication mechanism is a first digital key based key and authentication protocol to provide a secure communication mechanism.

11. A digital key opening method characterized by, The server, the first device and the second device have pre-configured a first service protocol, and the first device can open a first digital key under the first service protocol. Obtain a target request sent by the first device, the target request being used to request to apply for opening a second digital key under a second service protocol; In response to the target request, obtain target data, and send the target data to the first device by using a first communication mechanism defined by the first service protocol, the target data being used to construct a first data structure of the second digital key.

12. The method of claim 11, wherein, The method further comprises: Obtain a target record request sent by the first device by using the first communication mechanism defined by the first service protocol, the target record request being used to request to record a public key of the second digital key; In response to the target record request, record the public key of the second digital key, and generate a target record certificate, the target record certificate being used to prove that the server has completed the record of the public key of the second digital key; Send the target record certificate to the first device by using the first communication mechanism defined by the first service protocol.

13. The method of claim 11, wherein, The target data comprises one or more of the following: An identifier of the second device, a public key of the second device, a box identifier, an authorized public key group, key capability data, a private mailbox size, or a confidential mailbox size.

14. The method according to any of claims 11-13, characterized by, The first data structure comprises one or more of the following: The second device identifier, an identifier defined by the first device for the second digital key, a digital key identifier, a box identifier, an instance CA identifier, key capability data, a public key of the second digital key, a public key of the second device, an authorized public key group, a private mailbox, or a confidential mailbox.

15. The method of any of claims 11-13, wherein, The first device and the second device are each configured with a digital key system matched with the first digital key and a digital key system matched with the second digital key.

16. The method of any one of claims 11-13, wherein, The first service protocol is an ICCE standard protocol, and the second service protocol is a CCC standard protocol.

17. The method of any of claims 11-13, wherein, The first communication mechanism is a communication mechanism based on key encryption / decryption of devices to provide security protection.

18. A digital key opening system, characterized by, The first device, the second device and the server have pre-configured a first service protocol, and the first device can open a first digital key under the first service protocol, wherein the first device is configured to perform the method of any one of claims 1-10, the server is configured to perform the method of any one of claims 11-17, and the second device is configured to store a public key of the second digital key in response to a first message sent by the first device.

19. An apparatus, comprising: The server comprises: At least one memory for storing a program; at least one processor configured to perform a program stored in the memory, and when the program stored in the memory is executed, the processor is configured to perform the method of any one of claims 1-10, or perform the method of any one of claims 11-17. 20.A computer readable storage medium, storing a computer program, and when the computer program is run on an electronic device, the computer program causes the electronic device to perform the method of any one of claims 1-10, or perform the method of any one of claims 11-17.

21. A computer program product, characterised in that, The computer program product, when run on an electronic device, causes the electronic device to perform the method of any one of claims 1-10, or perform the method of any one of claims 11-17.

Images