Terminal device and data processing method for terminal device

Abstract

To provide a terminal device and a data processing method of the terminal device.SOLUTION: In a data processing method of a terminal device including a communication apparatus, the communication apparatus detects (S91) whether a native system of the terminal device includes a component for adapting to a public protocol of a digital vehicle key, and if the native system lacks at least one component, performs (S92) communication based on the public protocol with a target communicator who is a participant of the public protocol.SELECTED DRAWING: Figure 9

Description

Technical Field

[0001] The present disclosure relates to the field of terminal technologies, and particularly to terminal devices and data processing methods for terminal devices.

Background Art

[0002] Terminal devices as vehicle keys have emerged as a popular technology in recent years, and this function is also called a digital vehicle key. Different from conventional physical vehicle keys, a digital vehicle key can integrate the functions of a vehicle key into a mobile terminal device to realize functions such as opening and closing a vehicle door and starting a vehicle. Currently, some vehicle manufacturers and mobile terminal manufacturers are jointly developing solutions for digital vehicle keys. However, these solutions have low applicability and high setting costs.

Summary of the Invention

[0003] To solve the problems existing in the related art, the present disclosure provides a terminal device and a data processing method for the terminal device.

[0004] According to a first aspect of an embodiment of the present disclosure, a terminal device including a communication device is provided, and the communication device detects whether a component for the native system of the terminal device to conform to a public protocol of a digital vehicle key is included, and when the native system lacks at least one of the components, is configured to perform communication based on the public protocol with a target communicator who is a participant in the public protocol.

[0005] The communication device optionally includes a digital key module that can communicate with a vehicle server and is configured to implement the functions of a vehicle manufacturer application as defined in the public protocol; a local application module that can communicate with a terminal device server and is configured to implement the functions of a terminal device manufacturer application as defined in the public protocol; a digital key framework module that is configured to implement the functions of a digital key framework as defined in the public protocol; and a key management module that is configured to implement the functions of a digital key program as defined in the public protocol.

[0006] Optionally, the communication device includes an encrypted white-box module configured to store digital vehicle key data.

[0007] Optionally, the local application module is configured to communicate with the terminal device server based on the terminal device service module in the vehicle server.

[0008] Selectively, the public protocol is a certificate authentication-based public protocol, the target communicator comprises a vehicle server and a terminal device server, and the terminal device is used to complete the authentication step of key sharing and obtain a shared digital vehicle key by communicating with the vehicle server via the digital key module and the terminal device server via the local application module in response to receiving a key sharing request.

[0009] The public protocol can be selected to be either the CCC protocol or the ICCOA protocol.

[0010] Optionally, the target communicator includes a vehicle, and the terminal device is used to establish a security channel by communicating with the vehicle based on the public protocol via the communication device, and to transmit target control commands to the vehicle via the security channel to control the vehicle and perform target operations.

[0011] A second embodiment of the embodiments of the present disclosure provides a data processing method for a terminal device applicable to the terminal device described in any one of the first embodiments, the method comprising: detecting whether the native system of the terminal device includes components for conforming to a public protocol for a digital vehicle key; and, if the native system is missing at least one of the components, communicating with a target communicator who is a participant in the public protocol, based on the public protocol.

[0012] Optionally, the public protocol is a certificate authentication-based public protocol, the target communicator comprises a vehicle server and a terminal device server, and the step of communicating with the target communicator based on the public protocol includes, in response to receiving a key sharing request, completing the key sharing authentication step and obtaining a shared digital vehicle key by communicating with the vehicle server via a digital key module in the communication device and communicating with the terminal device server via a local application module in the communication device.

[0013] Optionally, the target communicator comprises a vehicle, and the step of communicating with the target communicator based on the public protocol includes the steps of establishing a security channel by communicating with the vehicle based on the public protocol via the communication device, and transmitting a target control command to the vehicle via the security channel to control the vehicle and perform a target operation.

[0014] In the above proposed technology, a communication device is installed within the terminal device, and the communication device can detect whether the terminal device's native system includes components for conforming to the public protocol of a digital vehicle key. If the native system is missing at least one of the components, communication based on the public protocol is performed with a target communicator who is a participant in the public protocol. [Effects of the Invention]

[0015] In this way, the terminal device can communicate with the target communicator based on the public protocol via the communication device, and therefore can realize the function of a digital vehicle key based on the public protocol. This method allows the public protocol to be applied to various terminal devices, thus expanding the scope of application of the public protocol. At the same time, terminal devices that do not support the public protocol can also communicate based on the public protocol via the communication device, thereby realizing the digital vehicle key function. Therefore, it is not necessary to place components for realizing a digital vehicle key based on a private protocol within the terminal device, thereby reducing the setup cost of the digital vehicle key.

[0016] The above general explanation and the following detailed explanation are illustrative and explanatory, and do not limit this disclosure. [Brief explanation of the drawing]

[0017] The drawings here are incorporated into the specification and become part of this specification, illustrating embodiments conforming to this disclosure and illustrating the principles of this disclosure together with the specification. [Figure 1] This is an architectural diagram of a digital vehicle key system based on the ICCOA protocol, as shown in one exemplary embodiment. [Figure 2] This is a block diagram of a terminal device shown in one exemplary embodiment. [Figure 3] It is a block diagram of a communication device shown in an exemplary embodiment. [Figure 4] It is a block diagram of a communication device and an encrypted white box shown in an exemplary embodiment. [Figure 5] It is a flowchart for starting the operation of a digital vehicle key shown in an exemplary embodiment. [Figure 6] It is an architecture diagram of a digital vehicle key of ICCOA shown in an exemplary embodiment. [Figure 7] It is a flowchart of key sharing shown in an exemplary embodiment. [Figure 8] It is a flowchart of standard authentication between a mobile terminal and a vehicle shown in an exemplary embodiment. [Figure 9] It is a flowchart of a data processing method of a terminal device shown in an exemplary embodiment.

Embodiments for Carrying out the Invention

[0018] Here, exemplary embodiments will be described in detail, and the examples are shown in the drawings. In the following description, when it relates to the drawings, unless otherwise indicated, the same numerals in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments that conform to the present disclosure. Rather, they are merely examples of devices and methods that conform to some aspects of the present disclosure, which are described in detail in the appended claims.

[0019] Before describing the terminal device and the data processing method of the terminal device of the present disclosure, first, the application scenario of the present disclosure will be described.

[0020] Using a terminal device as a vehicle key is a popular technology that has emerged in recent years, and this function is also called a digital vehicle key. Different from the conventional physical vehicle key, the digital vehicle key can integrate the vehicle key function into a mobile terminal device, thereby realizing functions such as opening and closing the car door and starting the vehicle.

[0021] For example, in some scenarios, an automobile manufacturer can develop a digital vehicle key based on a private protocol. By encapsulating data related to the private protocol in an automobile manufacturer application, a terminal device installed with the automobile manufacturer application can interact with the vehicle and a vehicle server based on the private protocol, thereby realizing functions of the digital vehicle key such as vehicle control and key sharing. To realize the functions of the digital vehicle key, the automobile manufacturer application needs to be executed on the terminal device, for example, executed in the foreground, consuming a lot of resources of the terminal device, or it can also be suspended in the background.

[0022] Therefore, some automobile manufacturers and mobile terminal manufacturers have jointly developed a solution for the digital vehicle key, that is, a solution for the digital vehicle key based on a public protocol. Compared with the private protocol, the public protocol can realize the functions of the digital vehicle key based on the lowest layer of the operating system.

[0023] Here, we will explain using the public protocol "ICCOA" as an example, and refer to the architecture diagram of a digital vehicle key system based on the ICCOA protocol shown in Figure 1. In a solution for a vehicle digital key based on a public protocol, operations related to the digital vehicle key can be encapsulated as a Digital Key Framework (DKF). The Digital Key Framework can provide various APIs (Application Programming Interfaces) for higher-level applications to call, such as device pairing, key lifecycle management, key unlocking, key locking, sharing, and vehicle control. By configuring the Digital Key Framework at the system level, terminal devices can implement the functions of the digital vehicle key based on the lowest level of the operating system, which has the advantage of consuming fewer resources and providing a better user experience.

[0024] Furthermore, since the public protocol is developed jointly by automobile manufacturers and mobile device manufacturers, the types of terminal devices that can use it are limited. For example, if terminal manufacturer A and an automobile manufacturer jointly develop public protocol 1, terminal device A1 under terminal manufacturer A can support public protocol 1, but terminal device B1 under terminal manufacturer B will have difficulty supporting public protocol 1, which will affect the user experience. For example, in some scenarios, vehicle users may include the vehicle owner and their friends, but the vehicle owner uses terminal device A1 which supports public protocol 1, while their friends use terminal device B1 which does not support public protocol 1, so the vehicle owner cannot share the digital vehicle key with their friends.

[0025] Therefore, to ensure compatibility, automakers typically need to simultaneously develop solutions for digital vehicle keys based on both private and public protocols. Both solutions can be configured on terminal devices. However, this results in high development and implementation costs for digital vehicle key solutions.

[0026] Therefore, this disclosure provides a terminal device, which may be a mobile terminal device such as a mobile phone or tablet, or another type of terminal device that can be equipped with a digital key function.

[0027] Figure 2 is a block diagram of a terminal device shown in this disclosure, and referring to Figure 2, the terminal device comprises a communication device which detects whether the terminal device's native system includes components for conforming to the public protocol of a digital vehicle key, and is configured to communicate based on the public protocol with a target communicator who is a participant in the public protocol if the native system is missing at least one of the components.

[0028] Here, the native system of the terminal device may be the system installed at the time of shipment of the terminal device, and depending on the differences in the terminal device, the native system may take various forms, such as the iOS system, the Hong Kong system, or the Android system, and is not limited to these in this disclosure. In order to implement a digital vehicle key based on a public protocol, it is necessary to configure the corresponding components on the terminal device. These components may include security units, digital key frameworks, trusted execution environments, etc. For specific types, please refer to the description of the relevant digital vehicle key public protocol.

[0029] The communication device can detect whether the terminal device's native system includes components for conforming to the public protocol of the digital vehicle key. If the native system is missing one or more of the components, the communication device can communicate based on the public protocol with a target communicator who is a participant in the public protocol.

[0030] Here, the communication device can be represented in the form of software, hardware, or a combination of software and hardware. For example, in one possible embodiment, the communication device can be represented in the form of an SDK (Software Development Kit). The public protocol may be a public protocol based on a certificate system, such as the CCC (Car Connectivity Consortium) protocol or the ICCOA (Intelligent Car Connectivity Open Alliance) protocol. The public protocol may also be a public protocol based on cryptographic key authentication, such as the ICCE (Intelligent Car Connectivity Industry Ecosystem Alliance Digital Key System) protocol.

[0031] The communication device will be described below using the public protocol "ICCOA" as an example.

[0032] Figure 3 is a block diagram of the communication device shown in this disclosure. In one possible embodiment, the communication device may include a digital key module. The digital key module is capable of communicating with a vehicle server and is configured to implement the functions of a vehicle manufacturer application as defined in the public protocol.

[0033] The ICCOA protocol stipulates that vehicle manufacturer applications must provide users with a functional interface related to digital vehicle keys. Therefore, a digital key module can be obtained by encapsulating the relevant key management function methods. Here, the key management function methods can include key creation, key sharing, key deletion, RKE (Remote Keyless Entry), etc. The digital key module can be represented in the form of an SDK and can provide the interface for the above key management function methods.

[0034] Referring to Figure 3, in one possible embodiment, the communication device includes a local application module configured to implement the functions of a terminal device manufacturer application defined in the public protocol.

[0035] The local application module can communicate with the terminal device server. In some implementations, the local application module may be configured to communicate directly with the terminal device server. In some implementations, a terminal device service module may be configured on the vehicle server. Thus, the local application module is configured to communicate with the terminal device server based on the terminal device service module on the vehicle server.

[0036] The ICCOA protocol stipulates that terminal device manufacturer applications must provide users with functional interfaces related to digital vehicle keys and perform service processes such as activating, updating, sharing, and deactivating digital vehicle keys. Therefore, the aforementioned related functional methods can be encapsulated to obtain the local application module. The local application module can also be represented in the form of an SDK and provides interfaces for business functions such as activating, updating, sharing, and deactivating vehicle keys.

[0037] Referring to Figure 3, in one possible embodiment, the communication device includes a digital key framework module configured to implement the functions of the digital key framework defined in the public protocol.

[0038] For example, operations related to a digital vehicle key TA (Trusted Application) in the digital vehicle key lifecycle can be encapsulated, thereby obtaining the digital key framework module. The digital key framework module can provide vehicle key management services to the digital key module and local application module in the form of an API for calls, and these functions include, but are not limited to, device pairing, key lifecycle management, key unlocking, key locking, sharing, and vehicle control. The digital key framework module can further interact with a key management module, thereby facilitating the key management module to receive and respond to authentication messages sent from the vehicle in a timely manner.

[0039] Furthermore, the digital key framework module may be configured to perform Bluetooth® pairing with the vehicle and establish a Bluetooth connection, and the Bluetooth pairing and connection method may be a general-purpose method or a user-configured method. In interaction with the vehicle, the digital key framework module can perform parsing and encapsulation of Bluetooth authentication data packets.

[0040] Referring to Figure 3, in one possible embodiment, the communication device includes a key management module configured to implement the functions of a digital key program defined in the public protocol.

[0041] Here, the key management module may include a TA module, which can invoke the security capabilities provided by the security storage unit, thereby constructing and storing key data. Referring here to the block diagram of the communication device and encryption white box shown in Figure 4, unlike related technologies which store key data via a Secure Element (SE), in this disclosure, the TA module can store key data in the form of an encryption white box. In some implementations, the TA module can store key data using the security storage technology of the terminal device's native system. For example, in the Android system, key data can be stored using key-store (Android encryption key) technology.

[0042] Furthermore, in service processes such as pairing, unlocking, locking, sharing, and vehicle control of digital vehicle keys, the TA module can further encrypt, decrypt, and perform security controls on the data. In some implementation scenarios, the TA module can also be used to verify the user's identity.

[0043] In some implementation scenarios, the TA module may be configured to have a calling interface. The key management module may further include a CA (Client Application) module. The CA module can perform functions related to the TA by calling the interface of the TA module.

[0044] Furthermore, the communication device can be encapsulated within an application on the terminal, and is not limited to such encapsulations in this disclosure.

[0045] Based on the communication device, the terminal device can communicate with the target communicator based on the public protocol.

[0046] For example, in one possible embodiment, the public protocol is a certificate authentication-based public protocol, and the terminal device is used to communicate with the vehicle server, terminal device server and vehicle via the communication device to complete the digital vehicle key activation step and obtain the digital vehicle key.

[0047] Refer to the digital vehicle key activation flowchart shown in Figure 5 and the ICCOA digital vehicle key architecture diagram shown in Figure 6. In this disclosure, the digital vehicle key flow based on the communication device activation ICCOA protocol includes the following steps.

[0048] In steps 511 to 513, the user can initiate the key activation flow via the communication device of the terminal device. Here, the user can input pairing information. The pairing information can be generated by the vehicle server, and the digital key module in the communication device can obtain the pairing information from the vehicle server. The vehicle server can also send initial pairing parameters to the vehicle.

[0049] In step 52, the vehicle interacts with the terminal device's DKF module and performs bidirectional authentication based on the SPAKE2+ algorithm and terminal device to establish a SPAKE2+ security channel. If the vehicle is bound to the vehicle owner's terminal device, the key activation flow ends; if the vehicle is not bound to the vehicle owner's terminal device, the subsequent flow continues based on the SPAKE2+ security channel.

[0050] The vehicle (or terminal device) can further check whether the current state satisfies the conditions for key activation, and the conditions can be set according to the needs of application. In step 53, if the conditions for key activation are met, the vehicle transmits the vehicle public key certificate [F] to the terminal device, the vehicle public key certificate [F] includes the vehicle public key and the vehicle server CA signature.

[0051] In steps 541-543, the terminal device's key management module can verify the vehicle public key certificate [F] using the vehicle server CA certificate [C], where the vehicle server CA certificate [C] includes the vehicle server CA public key and a trusted CA signature. After successful verification, the terminal device can store the vehicle public key certificate [F]. For example, the terminal device can store the vehicle public key certificate in an encrypted white box. The terminal device can also generate a digital vehicle key public / private key pair [K], where the digital vehicle key public / private key pair [K] includes the digital vehicle key public key and the digital vehicle key private key. The terminal device can further sign the digital vehicle key public key via the key management module's certificate [H] to generate a digital vehicle key public key certificate [L]. Here, the key management module's certificate [H] includes the key management module's CA public key and the key management module's CA private key, and the digital vehicle key public key certificate [L] includes the digital vehicle key public key and the key management module's CA signature.

[0052] In step 55, the terminal device sequentially transmits the terminal device server CA certificate [D], the key management module certificate [J], and the digital vehicle key public key certificate [L] to the vehicle. Here, the terminal device server CA certificate [D] includes the terminal device server CA public key and the vehicle server CA signature. The key management module certificate [J] includes the key management module CA public key and the terminal device server CA signature.

[0053] In step 56, the vehicle sequentially verifies the certificate chain transmitted from the terminal device. Here, the vehicle can verify the terminal device server CA certificate [D] via the vehicle server CA certificate [G], where the vehicle server CA certificate [G] includes the vehicle server CA public key and a trusted CA signature. The vehicle can also verify the key management module certificate [J] via the terminal device server CA certificate [D], where the terminal device server CA certificate [D] includes the terminal device server CA public key and the vehicle server CA signature. The vehicle can verify the digital vehicle key public key certificate [L] via the key management module certificate [J].

[0054] If verification is successful, the vehicle can store the digital vehicle key public key and the corresponding digital vehicle key information. In this way, the terminal device verifies and stores the vehicle public key, and the vehicle verifies and stores the digital vehicle key public key, thereby completing the encryption key generation and verification steps in the vehicle owner's key pairing stage. At this point, pairing between the terminal device and the vehicle is successful.

[0055] In step 57, the vehicle instructs the terminal device of its transmission status and the pairing status of the vehicle's digital vehicle key.

[0056] In steps 581-583, the vehicle synchronizes the activation status of its digital vehicle key with the vehicle server, and the terminal device transmits the activation status of its digital vehicle key to the terminal device server. The terminal device server then synchronizes the activation status of its digital vehicle key with the vehicle server.

[0057] In step 59, the vehicle server sends a key activation message to notify the vehicle owner.

[0058] In step 510, the first standard authentication is performed between the terminal device and the vehicle, and a standard authentication security channel is established.

[0059] In step 511, if it is necessary to configure digital vehicle key service data, the vehicle sends a request to the terminal device to save the digital vehicle key service data.

[0060] By using the above proposed technology, it becomes possible to initiate the operation of a digital vehicle key based on the ICCOA protocol for terminal devices whose native systems do not support the ICCOA protocol, based on the communication device, thereby expanding the scope of application of the ICCOA protocol.

[0061] In one possible embodiment, the public protocol is a certificate-based public protocol, the target communicators include a vehicle server and a terminal device server, and the terminal device is used to complete the authentication step of key sharing and obtain a shared digital vehicle key by communicating with the vehicle server via the digital key module and with the terminal device server via the local application module in response to receiving a key sharing request. Of course, in some implementation scenarios, the terminal device may also be the initiator of key sharing (i.e., the vehicle owner's terminal device) and share the digital vehicle key with another terminal device.

[0062] The following illustrates the process of sharing a digital vehicle key.

[0063] Figure 7 is a flowchart of the key sharing process described in this disclosure. Referring to Figure 7, the key sharing flow includes the following steps:

[0064] In step 71, the user can set friend key sharing information, such as expiration date and permissions. If the native system of the vehicle owner's terminal device supports the ICCOA protocol, the user can set the friend key sharing information in the terminal device manufacturer application of the vehicle owner's terminal device, which may be, for example, a wallet application. If the native system of the vehicle owner's terminal device does not support the ICCOA protocol, the user can set the friend key sharing information via the communication device.

[0065] In step 72, the vehicle owner's terminal device signs the friend key sharing information using the vehicle owner's digital vehicle key secret key to generate a friend key sharing request.

[0066] In step 73, the vehicle owner's terminal device sends a friend key sharing request to the vehicle owner's terminal device server, and the vehicle owner's terminal device server forwards this sharing request to the vehicle server.

[0067] In step 74, the vehicle server receives the sharing request and verifies the signature of the sharing information using the vehicle owner's digital vehicle key public key.

[0068] In step 75, after successfully verifying the signature of the shared information, the vehicle server generates a shared link SessionID. Since the SessionID can be randomly generated by a random number generator, the risk of gradual increase in prediction is avoided.

[0069] In step 76, the vehicle server sends the shared link SessionID to the vehicle owner's terminal device server, and the vehicle owner's terminal device server forwards the shared link SessionID to the vehicle owner's terminal device.

[0070] In step 77, after the vehicle owner's terminal device receives the shared link SessionID, it generates a shared link containing the SessionID and shares it with its friends.

[0071] In step 78, a friend can open a shared link via a friend terminal device. If the native system of the friend terminal device supports the ICCOA protocol, the friend terminal device jumps to the terminal device manufacturer application and obtains friend key sharing information from the friend terminal device server based on the SessionID. Here, the friend terminal device server can obtain friend key sharing information from the vehicle server. If the native system of the friend terminal device does not support the ICCOA protocol, when the friend terminal device opens a shared link, it can obtain friend key sharing information from the friend terminal device server based on the SessionID using a digital key module.

[0072] In step 79, the vehicle server transmits the friend key sharing information to the friend terminal device server, and the friend terminal server transfers the friend key sharing information to the friend terminal device.

[0073] In step 710, the friend terminal device presents information related to friend key sharing and proceeds after confirmation by the user. If the current friend terminal device already has the corresponding vehicle key, it terminates the key sharing flow and presents the corresponding information.

[0074] In step 711, the friend terminal device generates a friend digital vehicle key public / private key pair.

[0075] In step 712, if the native system of the friend terminal device supports the ICCOA protocol, the friend terminal device can generate a friend digital vehicle key public key certificate by signing the already generated friend digital vehicle key public key based on a trusted execution environment CA. If the native system of the friend terminal device supports the ICCOA protocol, the friend terminal device can generate a friend digital vehicle key public key certificate by signing the already generated friend digital vehicle key public key based on a key management module in the communication device.

[0076] In step 713, the Friend terminal device can initiate a transmission request to the Friend terminal device server, and the transmitted contents include the Friend digital vehicle key public key certificate, the Friend terminal device TEE CA certificate (or the Key Management Module CA certificate if the Friend terminal device's native system does not support the ICCOA protocol, which is obtained by the Friend terminal server CA private key signing the Key Management Module CA public key), and the Friend terminal device server CA certificate. The Friend terminal device server forwards the transmitted contents to the vehicle server, which then forwards them to the vehicle owner's terminal device server. Subsequently, the vehicle owner's terminal device server further forwards the transmitted contents to the vehicle owner's terminal device.

[0077] In step 714, after receiving the above transmission content, the vehicle owner's terminal device can verify the friend terminal device server CA certificate using the vehicle server CA certificate stored in the vehicle owner's terminal device, then verify the friend terminal device TEE CA certificate using the friend terminal device server CA certificate, and finally verify the friend digital vehicle key public key certificate using the friend terminal device TEE CA certificate.

[0078] Alternatively, if the transmitted content includes the Friend Digital Vehicle Key Public Key Certificate, the Key Management Module CA Certificate, and the Friend Terminal Device Server CA Certificate, the vehicle owner's terminal device will first verify the Friend Terminal Device Server CA Certificate using the Vehicle Server CA Certificate, then verify the Key Management Module CA Certificate using the Friend Terminal Device Server CA Certificate, and finally verify the Friend Digital Vehicle Key Public Key Certificate using the Key Management Module CA Certificate.

[0079] In step 715, if the vehicle owner's terminal device confirms that it has successfully verified the certificate chain described above, it obtains the Friend Digital Vehicle Key Public Key. In this way, the vehicle owner's terminal device can use the vehicle owner's Digital Vehicle Key Private Key to sign the Friend Key Sharing Information and the Friend Digital Vehicle Key Public Key to generate Friend Key Authentication Information.

[0080] In step 716, the vehicle owner's terminal device sends a transmission request to the vehicle owner's terminal device server, and the transmission contents may include friend key authentication information and the vehicle's public key certificate. The vehicle owner's terminal device server forwards the transmission contents to the vehicle server, which then forwards the transmission contents to the friend terminal device server, which in turn forwards the transmission contents to the friend terminal device.

[0081] In step 717, the friend terminal device receives the friend key authentication information and the vehicle public key certificate, and then stores the friend key authentication information and the vehicle public key certificate. Here, the friend key authentication information is used for the first standard authentication of the friend key and the vehicle, and is deleted after the transaction is completed. In this manner, friend key activation is completed.

[0082] The friend terminal device can further synchronize the friend key state to the friend terminal device server, which then synchronizes it to the vehicle server, and the vehicle server further synchronizes the friend key state to the vehicle owner's terminal device server. Subsequently, the vehicle owner's terminal device server synchronizes it to the vehicle owner's terminal device.

[0083] In step 718, the vehicle server records and tracks changes in the friend key status and notifies the vehicle owner and friends in the form of a short message.

[0084] Using the above proposed technology, it is possible to execute the digital vehicle key sharing flow based on the communication device for terminal devices whose native systems do not support the ICCOA protocol, thereby expanding the scope of application of the ICCOA protocol.

[0085] In one possible embodiment, the target communicator includes a vehicle, and the terminal device is used to establish a security channel by communicating with the vehicle via the communication device based on the public protocol, and to transmit target control commands to the vehicle via the security channel to control the vehicle and perform target operations.

[0086] For example, after activating the digital vehicle key, the terminal device can use the digital vehicle key. When using the digital vehicle key, the terminal device can authenticate the vehicle based on the communication device.

[0087] Here, the authentication process may include standard authentication or rapid authentication. In standard authentication, the vehicle verifies the legitimacy of the mobile terminal's digital vehicle key using a pre-stored digital vehicle key public key. In rapid authentication, the vehicle verifies the legitimacy of the mobile terminal's digital vehicle key using a rapid authentication cryptographic key generated and stored in the previous standard authentication.

[0088] Figure 8 is a flowchart of the standard certification of mobile terminals and vehicles as shown in this disclosure. Referring to Figure 8, the standard certification process includes the following steps:

[0089] In step 81, the vehicle generates a temporary public / private key pair.

[0090] In step 82, the vehicle sends a public key exchange request to the mobile terminal, transmitting a temporary vehicle public key and a vehicle ID (Vehicle_ID). Refer to the ICCOA protocol for the rules for generating the vehicle ID.

[0091] In step 83, the mobile terminal generates a temporary public / private key pair for the digital vehicle key. For example, the mobile terminal can generate the temporary public / private key pair using a key management module.

[0092] In step 84, the mobile terminal sends a public key exchange request response to the vehicle, returning the temporary public key for the digital vehicle key and the digital vehicle key ID (KeyID). Refer to the ICCOA protocol for the rules for generating the digital vehicle key KeyID.

[0093] In step 85, the vehicle generates vehicle authentication information, which includes the digital vehicle key temporary public key, the vehicle temporary public key, and related information for the digital vehicle key ID. The vehicle can further sign the vehicle authentication information using the vehicle private key.

[0094] In step 86, the vehicle sends a standard authentication request to the mobile terminal and transmits the vehicle authentication information signature to the mobile terminal.

[0095] In step 87, the mobile terminal verifies the signature using the vehicle's public key, and the vehicle's public key certificate is sent to the mobile terminal via the key activation flow. In this way, the mobile terminal can verify the vehicle's signature using the vehicle's public key, thereby verifying the vehicle's identity and thus preventing a counterfeit vehicle from obtaining mobile terminal information.

[0096] In step 88, if the vehicle authentication information signature passes verification, the mobile terminal generates digital vehicle key authentication information, which may include the digital vehicle key temporary public key, the vehicle temporary public key, and vehicle ID-related information. The mobile terminal can then sign the digital vehicle key authentication information using the digital vehicle key private key.

[0097] In steps 891 and 892, the mobile terminal can generate a security channel encryption key and a fast authentication encryption key using the KDF algorithm based on the agreed symmetric encryption key, while the vehicle side generates a security channel encryption key and a fast authentication encryption key using the same encryption key agreement algorithm and KDF algorithm. Based on the same security channel encryption key, both establish a security channel.

[0098] In step 810, based on the established security channel, the mobile terminal sends a standard authentication request response to the vehicle and sends a digital vehicle key authentication information signature to the vehicle.

[0099] In step 811, the vehicle retrieves the corresponding digital vehicle key public key by querying the digital vehicle key ID transmitted from the mobile terminal within the vehicle. If the digital vehicle key public key is found, step 815 is executed. If the vehicle cannot find the digital vehicle key ID and the corresponding digital vehicle key public key, steps 812 to 814 are executed based on the established security channel, and the vehicle retrieves the friend key's digital vehicle key public key through steps 812 to 814.

[0100] In step 812, the vehicle-facing mobile terminal sends a digital vehicle key data request, which is used to obtain friend key authentication information.

[0101] In step 813, the mobile terminal sends a digital vehicle key data request response to the vehicle and returns friend key authentication information.

[0102] In step 814, the vehicle decrypts the friend key authentication information using the security channel encryption key, and then verifies the signature of the friend key authentication information using the vehicle owner's digital vehicle key public key. If the verification is successful, the friend digital vehicle key public key in the friend key authentication information is saved.

[0103] In step 815, the vehicle verifies the digital vehicle key authentication information signature transmitted from the mobile terminal using the digital vehicle key public key corresponding to the digital vehicle key ID. If the verification is successful, standard authentication is successful. After passing standard authentication, the vehicle and mobile terminal synchronously save the rapidly generated rapid authentication encryption key for subsequent rapid authentication. For example, the mobile terminal can save the rapid authentication encryption key in an encrypted white-box module.

[0104] In step 816, after successful authentication, the vehicle sends a status report to the mobile terminal, notifying the mobile terminal of the vehicle's authentication status. In some implementation scenarios, before sending the status report, the vehicle may perform read / write operations on the mobile terminal's service data based on the established security channel.

[0105] After standard authentication, the mobile terminal can transmit commands based on the established security channel, thereby controlling the vehicle.

[0106] In the above embodiments, key activation, key sharing, and key use were used as examples to illustrate how the mobile terminal of this disclosure performs public protocol communication. However, as those skilled in the art will see, the mobile terminal provided by this disclosure can perform various communications based on the communication device and further implement corresponding functions. These functions include, but are not limited to, key activation, key sharing, key use, and key deactivation.

[0107] Furthermore, while the ICCOA protocol was used as an example in the above embodiment to illustrate the embodiment of the mobile terminal provided by this disclosure, in other implementation scenarios, the public protocol may be the CCC protocol, the ICCE protocol, or the like.

[0108] For example, in the ICCE protocol, the digital key module in the communication device is configured to communicate with a vehicle server and to implement the functions of the vehicle manufacturer application defined in the public protocol. These functions may include providing a user interface for key management and inquiry, providing a dialogue channel between the key and the vehicle server, executing service flows such as activation, updating, sharing, and deactivation, pairing and connecting to vehicle Bluetooth / UWB (Ultra Wide Band) during the key activation stage, and sending commands to the key management module via an API provided by DKF. Therefore, the digital key module can be obtained by encapsulating the above functional methods. The digital key module can also be represented in the form of an SDK and provide an interface for the above functions.

[0109] The local application module of the communication device is capable of communicating with a terminal device server and is configured to implement the functions of the terminal device manufacturer application as defined in the public protocol. These functions may include providing a user interface for the digital vehicle key's related functions, interacting with the vehicle server, executing service flows such as activation, updating, sharing, and deactivation, and triggering state synchronization with the automobile manufacturer server after performing operations to complete key lifecycle state changes. Therefore, the local application module can be obtained by encapsulating the above-mentioned related functional methods. The local application module can also be represented in the form of an SDK and provide an interface for the above functions.

[0110] The digital key framework module of the communication device is configured to implement the functions of the digital key framework defined in the public protocol. These functions include device pairing, vehicle key distribution, and management. The digital key framework module can also interact with the digital vehicle key program to facilitate the timely reception and response of authentication messages transmitted from the vehicle by the key management module. The digital key framework module can further perform access control to the AP of the key management module and maintain access control rules.

[0111] The key management module is configured to implement the functions of the digital key program defined in the public protocol. For example, the key management module can provide security transaction functions based on the encryption white box. Furthermore, to satisfy the requests for multiple vehicle keys, the key management module can use a unified AID (application identifier) ​​and ensure that different manufacturer key data is separated, thereby avoiding malicious query requests.

[0112] Based on the communication device, the terminal device can communicate with the target communicator based on the ICCE protocol, and for the sake of brevity, a detailed explanation of the communication method is omitted in this disclosure. Similarly, the communication device may be used to implement the functions of the terminal device as defined in the CCC protocol, and the communication device is configured to establish communication based on the CCC protocol between the terminal device and the target communicator, and a detailed explanation is omitted in this disclosure.

[0113] Based on the same concept of invention, this disclosure further provides a data processing method for a terminal device applicable to the terminal device provided herein. Figure 9 is a flowchart of the data processing method for a terminal device shown herein, and referring to Figure 9, the method includes the following steps.

[0114] In step S91, it is detected whether the terminal device's native system includes components that conform to the public protocol for digital vehicle keys.

[0115] In step S92, if the native system is missing at least one component, it communicates with the target communicator based on the public protocol, and the target communicator is a participant in the public protocol.

[0116] For example, in one possible embodiment, the public protocol is a certificate authentication-based public protocol, the target communicators include a vehicle server and a terminal device server, and the step of communicating with the target communicators based on the public protocol includes the step of obtaining a digital vehicle key by completing the activation step of the digital vehicle key as defined in the public protocol by communicating with the vehicle server, terminal device server and vehicle via the communication device.

[0117] Referring to Figures 5 and 6, the flow for initiating the operation of the ICCOA protocol digital vehicle key based on the communication device includes the following steps:

[0118] In steps 511 to 513, the user can initiate the key activation flow via the communication device of the terminal device. Here, the user can input pairing information. The pairing information can be generated by the vehicle server, and the digital key module in the communication device can obtain the pairing information from the vehicle server. The vehicle server can also send initial pairing parameters to the vehicle.

[0119] In step 52, the vehicle interacts with the terminal device's DKF module and performs bidirectional authentication based on the SPAKE2+ algorithm and the terminal device, thereby establishing a SPAKE2+ security channel. If the vehicle is already bound to the vehicle owner's terminal device, the key activation flow is terminated; if the vehicle is not bound to the vehicle owner's terminal device, the subsequent flow continues based on the SPAKE2+ security channel.

[0120] The vehicle (or terminal device) can further check whether the current state satisfies the conditions for key activation, and the conditions can be set according to the needs of application. In step 53, if the key activation conditions are met, the vehicle transmits the vehicle public key certificate [F] to the terminal device, the vehicle public key certificate [F] includes the vehicle public key and the vehicle server CA signature.

[0121] In steps 541-543, the terminal device's key management module can verify the vehicle public key certificate [F] using the vehicle server CA certificate [C], where the vehicle server CA certificate [C] includes the vehicle server CA public key and a trusted CA signature. After successful verification, the terminal device can store the vehicle public key certificate [F]. For example, the terminal device can store the vehicle public key certificate in an encrypted white box. The terminal device can also generate a digital vehicle key public / private key pair [K], where the digital vehicle key public / private key pair [K] includes the digital vehicle key public key and the digital vehicle key private key. The terminal device can further generate a digital vehicle key public key certificate [L] by signing the digital vehicle key public key with the key management module's certificate [H]. Here, the key management module's certificate [H] includes the key management module's CA public key and the key management module's CA private key, and the digital vehicle key public key certificate [L] includes the digital vehicle key public key and the key management module's CA signature.

[0122] In step 55, the terminal device sequentially transmits the terminal device server CA certificate [D], the key management module certificate [J], and the digital vehicle key public key certificate [L] to the vehicle. Here, the terminal device server CA certificate [D] includes the terminal device server CA public key and the vehicle server CA signature. The key management module certificate [J] includes the key management module CA public key and the terminal device server CA signature.

[0123] In step 56, the vehicle sequentially verifies the certificate chain transmitted from the terminal device. Here, the vehicle can verify the terminal device server CA certificate [D] via the vehicle server CA certificate [G], where the vehicle server CA certificate [G] includes the vehicle server CA public key and a trusted CA signature. The vehicle can also verify the key management module certificate [J] via the terminal device server CA certificate [D], where the terminal device server CA certificate [D] includes the terminal device server CA public key and the vehicle server CA signature. The vehicle can verify the digital vehicle key public key certificate [L] via the key management module certificate [J].

[0124] If verification is successful, the vehicle can store the digital vehicle key public key and the corresponding digital vehicle key information. In this way, the terminal device verifies and stores the vehicle public key, and the vehicle verifies and stores the digital vehicle key public key, thereby completing the encryption key generation and verification steps in the vehicle owner's key pairing stage. At this point, pairing between the terminal device and the vehicle is successful.

[0125] In step 57, the vehicle instructs the terminal device of its transmission status and the pairing status of the vehicle's digital vehicle key.

[0126] In steps 581-583, the vehicle synchronizes the activation status of its digital vehicle key with the vehicle server, and the terminal device transmits the activation status of its digital vehicle key to the terminal device server. The terminal device server then synchronizes the activation status of its digital vehicle key with the vehicle server.

[0127] In step 59, the vehicle server sends a key activation message to notify the vehicle owner.

[0128] In step 510, the first standard authentication is performed between the terminal device and the vehicle, and a standard authentication security channel is established.

[0129] In step 511, if it is necessary to configure digital vehicle key service data, the vehicle sends a request to the terminal device to save the digital vehicle key service data.

[0130] By using the above proposed technology, it becomes possible to initiate the operation of a digital vehicle key based on the ICCOA protocol for terminal devices whose native systems do not support the ICCOA protocol, based on the communication device, thereby expanding the scope of application of the ICCOA protocol.

[0131] In one possible embodiment, the public protocol is a certificate authentication-based public protocol, and the target communicator includes a vehicle server and a terminal device server, and in response to receiving a key sharing request, the steps include completing the authentication step of key sharing and obtaining a shared digital vehicle key by communicating with the vehicle server via a digital key module in the communication device and communicating with the terminal device server via a local application module in the communication device.

[0132] Referring to Figure 7, the key sharing flow includes the following steps:

[0133] In step 71, the user can set friend key sharing information, such as expiration date and permissions. If the native system of the vehicle owner's terminal device supports the ICCOA protocol, the user can set the friend key sharing information in the terminal device manufacturer application of the vehicle owner's terminal device, which may be, for example, a wallet application. If the native system of the vehicle owner's terminal device does not support the ICCOA protocol, the user can set the friend key sharing information via the communication device.

[0134] In step 72, the vehicle owner's terminal device signs the friend key sharing information using the vehicle owner's digital vehicle key secret key to generate a friend key sharing request.

[0135] In step 73, the vehicle owner's terminal device sends a friend key sharing request to the vehicle owner's terminal device server, and the vehicle owner's terminal device server forwards this sharing request to the vehicle server.

[0136] In step 74, the vehicle server receives the sharing request and verifies the signature of the sharing information using the vehicle owner's digital vehicle key public key.

[0137] In step 75, after successfully verifying the signature of the shared information, the vehicle server generates a shared link SessionID. Since the SessionID can be generated by a random number generator, the risk of increasing prediction is avoided.

[0138] In step 76, the vehicle server sends the shared link SessionID to the vehicle owner's terminal device server, and the vehicle owner's terminal device server forwards the shared link SessionID to the vehicle owner's terminal device.

[0139] In step 77, after the vehicle owner's terminal device receives the shared link SessionID, it generates a shared link containing the SessionID and shares it with its friends.

[0140] In step 78, a friend can open a shared link via a friend terminal device. If the native system of the friend terminal device supports the ICCOA protocol, the friend terminal device jumps to the terminal device manufacturer application and obtains friend key sharing information from the friend terminal device server based on the SessionID. Here, the friend terminal device server can obtain friend key sharing information from the vehicle server. If the native system of the friend terminal device does not support the ICCOA protocol, when the friend terminal device opens a shared link, it can obtain friend key sharing information from the friend terminal device server based on the SessionID using a digital key module.

[0141] In step 79, the vehicle server transmits the friend key sharing information to the friend terminal device server, and the friend terminal server transfers the friend key sharing information to the friend terminal device.

[0142] In step 710, the friend terminal device presents information related to friend key sharing and proceeds after confirmation by the user. If the current friend terminal device already has the corresponding vehicle key, it terminates the key sharing flow and presents the corresponding information.

[0143] In step 711, the friend terminal device generates a friend digital vehicle key public / private key pair.

[0144] In step 712, if the native system of the friend terminal device supports the ICCOA protocol, the friend terminal device can generate a friend digital vehicle key public key certificate by signing the already generated friend digital vehicle key public key based on a trusted execution environment CA. If the native system of the friend terminal device supports the ICCOA protocol, the friend terminal device can generate a friend digital vehicle key public key certificate by signing the already generated friend digital vehicle key public key based on a key management module in the communication device.

[0145] In step 713, the Friend terminal device can initiate a transmission request to the Friend terminal device server, and the transmitted contents include the Friend digital vehicle key public key certificate, the Friend terminal device TEE CA certificate (or the Key Management Module CA certificate if the Friend terminal device's native system does not support the ICCOA protocol, which is obtained by the Friend terminal server CA private key signing the Key Management Module CA public key), and the Friend terminal device server CA certificate. The Friend terminal device server forwards the transmitted contents to the vehicle server, which then forwards them to the vehicle owner's terminal device server. Subsequently, the vehicle owner's terminal device server further forwards the transmitted contents to the vehicle owner's terminal device.

[0146] In step 714, after receiving the above transmission content, the vehicle owner's terminal device can verify the friend terminal device server CA certificate using the vehicle server CA certificate stored in the vehicle owner's terminal device, then verify the friend terminal device TEE CA certificate using the friend terminal device server CA certificate, and finally verify the friend digital vehicle key public key certificate using the friend terminal device TEE CA certificate.

[0147] Alternatively, if the transmitted content includes the Friend Digital Vehicle Key Public Key Certificate, the Key Management Module CA Certificate, and the Friend Terminal Device Server CA Certificate, the vehicle owner's terminal device will first verify the Friend Terminal Device Server CA Certificate using the Vehicle Server CA Certificate, then verify the Key Management Module CA Certificate using the Friend Terminal Device Server CA Certificate, and finally verify the Friend Digital Vehicle Key Public Key Certificate using the Key Management Module CA Certificate.

[0148] In step 715, if the vehicle owner's terminal device confirms that it has successfully verified the certificate chain described above, it obtains the Friend Digital Vehicle Key Public Key. In this way, the vehicle owner's terminal device can use the vehicle owner's Digital Vehicle Key Private Key to sign the Friend Key Sharing Information and the Friend Digital Vehicle Key Public Key to generate Friend Key Authentication Information.

[0149] In step 716, the vehicle owner's terminal device sends a transmission request to the vehicle owner's terminal device server, and the transmission contents may include friend key authentication information and the vehicle's public key certificate. The vehicle owner's terminal device server forwards the transmission contents to the vehicle server, which then forwards the transmission contents to the friend terminal device server, which in turn forwards the transmission contents to the friend terminal device.

[0150] In step 717, the friend terminal device receives the friend key authentication information and the vehicle public key certificate, and then stores the friend key authentication information and the vehicle public key certificate. Here, the friend key authentication information is used for the first standard authentication of the friend key and the vehicle, and is deleted after the transaction is completed. In this manner, friend key activation is completed.

[0151] The friend terminal device can further synchronize the friend key state to the friend terminal device server, which then synchronizes it to the vehicle server, and the vehicle server further synchronizes the friend key state to the vehicle owner's terminal device server. Subsequently, the vehicle owner's terminal device server synchronizes it to the vehicle owner's terminal device.

[0152] In step 718, the vehicle server records and tracks changes in the friend key status and notifies the vehicle owner and friends in the form of a short message.

[0153] Using the above proposed technology, it is possible to execute the digital vehicle key sharing flow based on the communication device for terminal devices whose native systems do not support the ICCOA protocol, thereby expanding the scope of application of the ICCOA protocol.

[0154] In one possible embodiment, the target communicator includes a vehicle, and the step of communicating with the target communicator based on the public protocol includes the steps of establishing a security channel by communicating with the vehicle based on the public protocol via the communication device, and transmitting a target control command to the vehicle via the security channel to control the vehicle and perform a target operation.

[0155] Figure 8 is a flowchart of the standard authentication of mobile terminals and vehicles as shown in this disclosure. Referring to Figure 8, the standard authentication flow may include the following steps:

[0156] In step 81, the vehicle generates a temporary public / private key pair.

[0157] In step 82, the vehicle sends a public key exchange request to the mobile terminal, transmitting a temporary vehicle public key and a vehicle ID (Vehicle_ID). Refer to the ICCOA protocol for the rules for generating the vehicle ID.

[0158] In step 83, the mobile terminal generates a temporary public / private key pair for the digital vehicle key. For example, the mobile terminal can generate the temporary public / private key pair using a key management module.

[0159] In step 84, the mobile terminal sends a public key exchange request response to the vehicle, returning the temporary public key for the digital vehicle key and the digital vehicle key ID (KeyID). Refer to the ICCOA protocol for the rules for generating the digital vehicle key KeyID.

[0160] In step 85, the vehicle generates vehicle authentication information, which includes the digital vehicle key temporary public key, the vehicle temporary public key, and related information for the digital vehicle key ID. The vehicle can further sign the vehicle authentication information using the vehicle private key.

[0161] In step 86, the vehicle sends a standard authentication request to the mobile terminal and transmits the vehicle authentication information signature to the mobile terminal.

[0162] In step 87, the mobile terminal verifies the signature using the vehicle's public key, and the vehicle's public key certificate is sent to the mobile terminal via the key activation flow. In this way, the mobile terminal can verify the vehicle's signature using the vehicle's public key, thereby verifying the vehicle's identity and thus preventing a counterfeit vehicle from obtaining mobile terminal information.

[0163] In step 88, if the vehicle authentication information signature passes verification, the mobile terminal generates digital vehicle key authentication information, which may include the digital vehicle key temporary public key, the vehicle temporary public key, and vehicle ID-related information. The mobile terminal can then sign the digital vehicle key authentication information using the digital vehicle key private key.

[0164] In steps 891 and 892, the mobile terminal can generate a security channel encryption key and a fast authentication encryption key using the KDF algorithm based on the agreed symmetric encryption key, and the vehicle side generates a security channel encryption key and a fast authentication encryption key using the same encryption key agreement algorithm and KDF algorithm. Based on the same security channel encryption key, both parties establish a security channel.

[0165] In step 810, based on the established security channel, the mobile terminal sends a standard authentication request response to the vehicle and sends a digital vehicle key authentication information signature to the vehicle.

[0166] In step 811, the vehicle retrieves the corresponding digital vehicle key public key by querying the digital vehicle key ID transmitted from the mobile terminal within the vehicle. If the digital vehicle key public key is found, step 815 is executed. If the vehicle cannot find the digital vehicle key ID and the corresponding digital vehicle key public key, steps 812 to 814 are executed based on the established security channel, and the vehicle retrieves the friend key's digital vehicle key public key through steps 812 to 814.

[0167] In step 812, the vehicle-facing mobile terminal sends a digital vehicle key data request, which is used to obtain friend key authentication information.

[0168] In step 813, the mobile terminal sends a digital vehicle key data request response to the vehicle and returns friend key authentication information.

[0169] In step 814, the vehicle decrypts the friend key authentication information using the security channel encryption key, and then verifies the signature of the friend key authentication information using the vehicle owner's digital vehicle key public key. If the verification is successful, the friend digital vehicle key public key in the friend key authentication information is saved.

[0170] In step 815, the vehicle verifies the digital vehicle key authentication information signature transmitted from the mobile terminal using the digital vehicle key public key corresponding to the digital vehicle key ID. If the verification is successful, standard authentication is successful. After passing standard authentication, the vehicle and mobile terminal synchronously save the rapidly generated rapid authentication encryption key for subsequent rapid authentication. For example, the mobile terminal can save the rapid authentication encryption key in an encrypted white-box module.

[0171] In step 816, after successful authentication, the vehicle sends a status report to the mobile terminal, notifying the mobile terminal of the vehicle's authentication status. In some implementation scenarios, before sending the status report, the vehicle may perform read / write operations on the mobile terminal's service data based on the established security channel.

[0172] After standard authentication, the mobile terminal can transmit commands based on the established security channel, thereby controlling the vehicle.

[0173] In the above proposed technology, a communication device is installed within the terminal device, and the communication device can detect whether the terminal device's native system includes components for conforming to the public protocol of a digital vehicle key. If the native system is missing at least one of the components, communication based on the public protocol is performed with a target communicator who is a participant in the public protocol.

[0174] In this way, the terminal device can communicate with the target communicator based on the public protocol via the communication device, and therefore can realize the function of a digital vehicle key based on the public protocol. This method allows the public protocol to be applied to various terminal devices, thus expanding the scope of application of the public protocol. At the same time, terminal devices that do not support the public protocol can also communicate based on the public protocol via the communication device, thereby realizing the digital vehicle key function. Therefore, it is not necessary to place components for realizing a digital vehicle key based on a private protocol within the terminal device, thereby reducing the setup cost of the digital vehicle key.

[0175] In another exemplary embodiment, a computer program product is further provided, the computer program product comprising a computer program executable by a programmable device, the computer program having a code portion for executing a data processing method of the terminal device when executed by the programmable device.

[0176] A person skilled in the art will readily conceive of other embodiments of the Disclosure after considering the Specification and putting the Disclosure into practice. This application seeks to cover all variations, uses, or adaptive changes of the Disclosure, which will follow the general principles of the Disclosure and include common or commonly used technical means in the Art not disclosed herein. The Specification and Examples are illustrative only, and the true scope and spirit of the Disclosure are indicated by the following Claims.

[0177] Please understand that this disclosure is not limited to the exact structure described above and shown in the drawings, and that various modifications and changes may be made as long as they do not deviate from its scope. The scope of this disclosure is limited only to the attached claims.

Claims

1. Equipped with communication devices, The communication device is configured to detect whether the terminal device's native system includes components for conforming to the public protocol of a digital vehicle key, and if the native system is missing at least one of the components, to communicate with a target communicator who is a participant in the public protocol, wherein the components include a security unit, a digital key framework, and a trusted execution environment, and the public protocol is the ICCOA protocol. The aforementioned communication device A digital key module that is capable of communicating with a vehicle server and is configured to implement the functions of a vehicle manufacturer application as defined in the public protocol, A local application module that is capable of communicating with a terminal device server and is configured to implement the functions of a terminal device manufacturer application as defined in the public protocol, A digital key framework module configured to implement the functions of the digital key framework defined in the aforementioned public protocol, A key management module configured to implement the functions of a digital key program defined in the aforementioned public protocol, Equipped with, The aforementioned public protocol is a public protocol based on certificate authentication, The aforementioned target communication provider includes a vehicle server and a terminal device server, The terminal device, in response to receiving a key sharing request, communicates with the vehicle server via the digital key module and with the terminal device server via the local application module to complete the authentication step of key sharing and obtain the shared digital vehicle key. The aforementioned terminal device is In response to the user initiating the key activation flow via a communication device, the digital key framework module establishes a security channel with the vehicle. Based on the aforementioned security channel, obtain the vehicle public key certificate, The key management module verifies the vehicle public key certificate using the vehicle server CA certificate, and after successful verification, stores the vehicle public key certificate. The aforementioned key management module generates a digital vehicle key public / private key pair, which includes a digital vehicle key public key and a digital vehicle key private key. The digital vehicle key public key certificate is generated by signing the digital vehicle key public key via the certificate of the key management module, and the certificate of the key management module includes a terminal device server CA signature. A terminal device configured to transmit the terminal device server CA certificate, the key management module certificate, and the digital vehicle key public key certificate to the vehicle so that the vehicle can sequentially verify the terminal device server CA certificate, the key management module certificate, and the digital vehicle key public key certificate, and to store the digital vehicle key public key if the verification is successful.

2. The terminal device according to claim 1, wherein the communication device comprises an encrypted white-box module configured to store digital vehicle key data.

3. The terminal device according to claim 1, wherein the local application module is configured to communicate with the terminal device server based on the terminal device service module in the vehicle server.

4. The aforementioned target communications person is equipped with a vehicle, The terminal device according to claim 1, which is used to establish a security channel by communicating with the vehicle based on the public protocol via the communication device, and to transmit target control commands to the vehicle via the security channel to control the vehicle and perform target operations.

5. Applicable to the terminal device described in any one of claims 1 to 4, The steps include: detecting whether the native system of the terminal device includes components for conforming to the public protocol of digital vehicle keys; If the native system is missing at least one of the components, the steps include: performing communication based on the public protocol with a target communicator who is a participant in the public protocol; The components include a security unit, a digital key framework, and a trusted execution environment, and the public protocol is the ICCOA protocol. The aforementioned public protocol is a public protocol based on certificate authentication, The aforementioned target communication provider includes a vehicle server and a terminal device server, The step of performing communication based on the public protocol with a target communicator who is a participant in the public protocol includes, in response to receiving a key sharing request, communicating with the vehicle server via a digital key module in the communication device and communicating with the terminal device server via a local application module in the communication device, thereby completing the key sharing authentication step and obtaining the shared digital vehicle key. In response to the user initiating the key activation flow via a communication device, the digital key framework module establishes a security channel with the vehicle. Based on the aforementioned security channel, obtain the vehicle public key certificate, The key management module verifies the vehicle public key certificate using the vehicle server CA certificate, and after successful verification, saves the vehicle public key certificate. The aforementioned key management module generates a digital vehicle key public / private key pair, which includes a digital vehicle key public key and a digital vehicle key private key. The digital vehicle key public key certificate is generated by signing the digital vehicle key public key via the certificate of the key management module, and the certificate of the key management module includes a terminal device server CA signature. A data processing method for a terminal device, comprising transmitting the terminal device server CA certificate, the key management module certificate, and the digital vehicle key public key certificate to the vehicle so that the vehicle sequentially verifies the terminal device server CA certificate, the key management module certificate, and the digital vehicle key public key certificate, and saving the digital vehicle key public key if the verification is successful.

6. The aforementioned target communications person is equipped with a vehicle, The step of communicating with the target communicator based on the aforementioned public protocol is: The steps include establishing a security channel by communicating with the vehicle based on the public protocol via the communication device, The steps include: transmitting a target control command to the vehicle via the security channel to control the vehicle and perform a target operation; The method according to claim 5, including the method described in claim 5.

Images