Service-oriented vehicle diagnosis secure communication method and device, vehicle and storage medium

Abstract

The application discloses a service-oriented vehicle-mounted diagnosis safe communication method and device, a vehicle and a storage medium. The method comprises the following steps: receiving an identity authentication request sent by a diagnosis client, performing identity verification on the diagnosis client based on the identity authentication request; generating an authentication code and returning the authentication code to the diagnosis client in the case that the identity verification is passed; receiving a token application request carrying the authentication code sent by the diagnosis client, and performing verification on the authentication code; generating and signing an access token in the case that the authentication code verification is passed, and issuing the access token to the diagnosis client, so that the diagnosis client initiates diagnosis resource access to the diagnosis server based on the access token. The technical scheme can improve the communication security of the service-oriented vehicle-mounted diagnosis.

Description

Technical Field

[0001] This invention relates to the fields of vehicle diagnostics and vehicle network security technology, and in particular to a service-oriented vehicle diagnostic secure communication method, device, vehicle, and storage medium. Background Technology

[0002] With the development of intelligent connected vehicles, more and more cars are using high-performance computing (HPC) platforms and centralized electronic and electrical architectures. Traditional diagnostic protocols, such as Unified Diagnostic Services (UDS), are proving inadequate when handling complex software data and dynamic diagnostic scenarios. For example, they struggle to efficiently access complex software data and flexibly adapt to dynamic diagnostic scenarios. Service-Oriented Vehicle Diagnostics (SOVD) is a service-oriented diagnostic standard that abstracts diagnostic functions and data into independent service resources, using entities and resource sets for association and management. It also provides a standardized interface that allows clients to access these resources via standard HTTP methods, thereby enabling corresponding diagnostic functions. The SOVD standard supports remote diagnostics, local diagnostics, and on-board diagnostics.

[0003] With the introduction of remote access interfaces, many security issues arise, such as client identity forgery, server identity forgery, and attacks on the security of communication data (confidentiality, integrity, replay, etc.). Therefore, ensuring the communication security of service-oriented vehicle diagnostics is a pressing technical problem that needs to be solved. Summary of the Invention

[0004] This invention provides a service-oriented vehicle diagnostic secure communication method, device, vehicle, and storage medium to ensure the communication security of service-oriented vehicle diagnostics.

[0005] According to one aspect of the present invention, a service-oriented on-board diagnostic safety communication method is provided, comprising: Receive an authentication request sent by the diagnostic client, and perform identity verification on the diagnostic client based on the authentication request; If the identity verification is successful, an authentication code is generated and returned to the diagnostic client. Receive a token request request carrying the authentication code sent by the diagnostic client, and perform verification on the authentication code; If the authentication code is verified, an access token is generated and signed, and the access token is issued to the diagnostic client so that the diagnostic client can initiate access to diagnostic resources from the diagnostic server based on the access token.

[0006] According to another aspect of the present invention, a service-oriented on-board diagnostic safety communication device is provided, comprising: The identity authentication module is used to receive identity authentication requests sent by the diagnostic client and perform identity verification on the diagnostic client based on the identity authentication requests; The authentication code generation module is used to generate an authentication code when the identity verification is successful, and return the authentication code to the diagnostic client; The authentication code verification module is used to receive a token request request carrying the authentication code sent by the diagnostic client and to verify the authentication code. The access token processing module is used to generate and sign an access token when the authentication code verification is successful, and issue the access token to the diagnostic client so that the diagnostic client can initiate access to diagnostic resources to the diagnostic server based on the access token.

[0007] According to another aspect of the present invention, a vehicle is provided, the vehicle comprising: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, which is then executed by the at least one processor to enable the at least one processor to execute the service-oriented vehicle diagnostic safety communication method according to any embodiment of the present invention.

[0008] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the service-oriented vehicle diagnostic safety communication method according to any embodiment of the present invention.

[0009] The technical solution of this invention includes: receiving an authentication request sent by a diagnostic client; performing identity verification on the diagnostic client based on the authentication request; generating an authentication code if the identity verification is successful, and returning the authentication code to the diagnostic client; receiving a token request carrying the authentication code sent by the diagnostic client, and performing verification on the authentication code; generating and signing an access token if the authentication code verification is successful, and issuing the access token to the diagnostic client, so that the diagnostic client can initiate access to diagnostic resources from the diagnostic server based on the access token. This technical solution, through identity verification and authentication code verification, can prevent identity forgery; based on the signing and verification of the access token, the legitimacy of access to diagnostic resources can be ensured, preventing data tampering and replay attacks, thereby guaranteeing the security of service-oriented vehicle diagnostics.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A flowchart illustrating a service-oriented on-board diagnostic security communication method provided in an embodiment of the present invention; Figure 2 A flowchart illustrating another service-oriented vehicle diagnostic security communication method provided in an embodiment of the present invention; Figure 3 A system architecture diagram of SOVD secure communication provided for the implementation of this invention; Figure 4 A flowchart of a preferred service-oriented vehicle diagnostic security communication method is provided in this embodiment of the invention; Figure 5 This is a schematic diagram of the structure of a service-oriented vehicle diagnostic safety communication device provided in an embodiment of the present invention; Figure 6 A schematic diagram of the vehicle structure for implementing the service-oriented on-board diagnostic secure communication method of this invention. Detailed Implementation

[0013] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0014] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0015] Figure 1 This is a flowchart illustrating a service-oriented vehicle diagnostic secure communication method according to an embodiment of the present invention. This embodiment is applicable to situations requiring secure communication between a diagnostic client and a diagnostic server. The method can be executed by a service-oriented vehicle diagnostic secure communication device, which can be implemented in hardware and / or software and can be configured in a vehicle. Figure 1 As shown, the method specifically includes the following steps: S110. Receive an authentication request sent by the diagnostic client, and perform identity verification on the diagnostic client based on the authentication request.

[0016] In this context, the diagnostic client refers to a remote or local client that needs to access in-vehicle diagnostic services; it can also be a client within the vehicle, such as a diagnostic application on the vehicle's infotainment system. An authentication request can be understood as a request sent by the diagnostic client to the authorized server to request an authentication code.

[0017] Specifically, the authorization server can be in a listening state. Upon receiving an authentication request from the diagnostic client, it can verify the client's legitimacy based on the information carried in the authentication request. If the authentication fails, it indicates that the diagnostic client's identity may be forged, and the server will refuse to send an authentication code to the diagnostic client.

[0018] In some possible implementations, the authentication request carries the diagnostic client's identity certificate; the step of performing identity verification on the diagnostic client based on the authentication request includes: obtaining the identity certificate based on the authentication request, and verifying the signature, integrity, and legality of the identity certificate using a preset root certificate.

[0019] In this context, the identity certificate refers to an electronic credential pre-issued by the key management module to uniquely identify the legitimate device identity of the diagnostic client. The default root certificate can be understood as a trust root certificate pre-configured within the authorized server.

[0020] It should also be noted that, in order to effectively resist replay attacks and improve authentication security, in this embodiment of the invention, the authorization server can generate random challenge data before identity authentication and send the challenge data to the diagnostic client.

[0021] Furthermore, the diagnostic client can include its identity certificate and challenge data in the authentication request and send the request to the authorization server. The authorization server can retrieve the diagnostic client's identity certificate from the authentication request and then use its locally preset root certificate to verify the integrity of the diagnostic client's signature, the validity of its content, and the consistency of the challenge data. For example, it can verify whether the received challenge data matches the previously issued challenge data. If all verifications are successful, the diagnostic client's identity verification is considered successful.

[0022] Since the challenge data is a one-time random sequence of data generated in real time by the authorization server, meaning the challenge data is valid only once, the authorization server can ensure the uniqueness of a single session interaction by verifying the consistency of the challenge data, effectively resisting replay attacks and improving authentication security.

[0023] S120. If the identity verification is successful, generate an authentication code and return the authentication code to the diagnostic client.

[0024] In this embodiment of the invention, if the identity verification described in the foregoing steps is successful, the authorization server can generate a temporary authentication code and return the authentication code to the diagnostic client. Only when the diagnostic client holds the authentication code can it apply to the authorization server for an access token to access diagnostic resources.

[0025] S130: Receive a token request request carrying the authentication code sent by the diagnostic client, and perform verification on the authentication code.

[0026] The token request is used to request a formal and valid credential from the authorized server, that is, to request an access token.

[0027] Specifically, the authorization server can receive a token request sent by the diagnostic client. The token request carries the authentication code returned to the diagnostic client in the aforementioned steps. The authorization server can verify the authentication code and determine whether to issue an access token to the diagnostic client based on the verification result. Only after obtaining the access token can the diagnostic client access the diagnostic resources.

[0028] S140. If the authentication code verification is successful, generate and sign an access token, and issue the access token to the diagnostic client so that the diagnostic client can initiate access to diagnostic resources to the diagnostic server based on the access token.

[0029] The access token refers to the official and legitimate credential used to access diagnostic services. Signature processing can involve encrypting and encapsulating the token information to ensure it cannot be tampered with.

[0030] Specifically, after the authentication code verification is successful, the authorization server can generate a corresponding access token, sign the access token, and then send the signed access token to the diagnostic client. In this way, after receiving the access token, the diagnostic client can use it to initiate corresponding diagnostic resource access to the diagnostic server.

[0031] In some possible implementations, generating and signing the access token upon successful verification of the authentication code includes: generating a plaintext payload of the access token; signing the plaintext payload of the access token using a private key within a trusted execution environment; and combining the signature with the plaintext payload of the access token to obtain the access token.

[0032] In this context, the plaintext payload of the access token refers to the raw token information that has not undergone signature processing. Specifically, after the authentication code is verified, the authorization server can construct the plaintext payload of the access token, then call the key management module through the API to sign the plaintext payload of the access token using the private key, and then combine the signature result with the plaintext payload of the access token to obtain the complete access token.

[0033] It should also be noted that multiple operating systems are usually virtualized simultaneously in the same HPC, such as Linux, Android, and QNX systems. The service-oriented vehicle diagnostic server (SOVD server) will also be distributed across these systems. Ensuring the secure use of passwords across multiple systems will also present a challenge.

[0034] To address the aforementioned technical issues, in some possible implementations, the trusted execution environment stores key materials, and the signing operation is performed within the trusted execution environment based on the private key in the key materials, which can ensure the secure use of cryptography.

[0035] Specifically, the signing operation for the plaintext payload of the access token can be completed within a trusted execution environment. The trusted execution environment has pre-stored key materials, and the signing process can directly call the private key in the key materials to execute the signing process without exposing the key information to the outside.

[0036] In some embodiments, the key materials include an asymmetric key pair and a digital certificate; the asymmetric key pair is used to perform signature and verification operations on the access token, and the private key in the asymmetric key pair participates in the computation only within the trusted execution environment.

[0037] It should be noted that the key materials include two types of security credentials: asymmetric key pairs and digital certificates. Asymmetric key pairs are used to complete the signing and verification operations of access tokens. The private key in the asymmetric key pair only participates in the computation within the trusted execution environment, which can avoid the exposure and leakage of the private key and improve the overall communication security level.

[0038] In vehicle systems, if the key is stored in a normal operating environment and the signature operation is performed in a conventional operating system, the key is easily stolen and the signature process is hijacked, which cannot guarantee the overall security of the access token generation process. The technical solution of the present invention can avoid the above problems.

[0039] In some possible implementations, the diagnostic server is deployed on at least two operating systems in the in-vehicle high-performance computing platform; when the authorized server and the diagnostic server are located on the same operating system, the authorized server and the diagnostic server interact through inter-process communication. When the authorization server and the diagnostic server are located on different operating systems, the authorization server and the diagnostic server interact through remote procedure calls.

[0040] The operating system can include, but is not limited to, Linux, Android, and QNX systems. Inter-process communication (IPC) refers to the data exchange method between different programs within the same system. Remote procedure call (RPC) refers to the function call and data transfer method between cross-systems.

[0041] Specifically, the diagnostic server can be deployed on multiple operating systems of the vehicle platform. When the authorized server and the diagnostic server are on the same operating system, they can interact using inter-process communication. When the authorized server and the diagnostic server are on different operating systems, they can interact using remote procedure calls.

[0042] The technical solution of this invention includes: receiving an authentication request sent by a diagnostic client; performing identity verification on the diagnostic client based on the authentication request; generating an authentication code if the identity verification is successful, and returning the authentication code to the diagnostic client; receiving a token request carrying the authentication code sent by the diagnostic client, and performing verification on the authentication code; generating and signing an access token if the authentication code verification is successful, and issuing the access token to the diagnostic client, so that the diagnostic client can initiate access to diagnostic resources from the diagnostic server based on the access token. This technical solution, through identity verification and authentication code verification, can prevent identity forgery; based on the signing and verification of the access token, the legitimacy of access to diagnostic resources can be ensured, preventing data tampering and replay attacks, thereby improving the security of service-oriented vehicle diagnostics.

[0043] Figure 2 This is a flowchart of another service-oriented vehicle diagnostic security communication method provided by an embodiment of the present invention. Based on the above embodiments, this embodiment further optimizes the generation and verification of access tokens. For specific implementation details, please refer to the technical solution of this embodiment. Technical terms that are the same as or corresponding to those in the above embodiments will not be repeated here. Figure 2 As shown, the method specifically includes the following steps: S210. Receive an authentication request sent by the diagnostic client, and perform identity verification on the diagnostic client based on the authentication request.

[0044] S220. If the identity verification is successful, generate an authentication code and return the authentication code to the diagnostic client.

[0045] S230: Receive a token request request carrying the authentication code sent by the diagnostic client, and perform verification on the authentication code.

[0046] S240. If the authentication code verification is successful, generate and sign an access token, and issue the access token to the diagnostic client.

[0047] In existing technologies, access tokens typically contain only simple identifiers or basic session information, which cannot control access permissions for diagnostic purposes.

[0048] In this embodiment of the invention, the access token includes at least one of the following: token type, signature algorithm, issuer information, validity period, client identity identifier, and diagnostic resource access permission information.

[0049] The token type can be a classification that identifies the token's purpose and access level. The signature algorithm can be understood as the cryptographic calculation method used to perform the token signing. The validity period refers to the timeframe within which the token is legally usable. The client identity identifier is used to distinguish different access subjects. Diagnostic resource access permission information is used to limit the scope of diagnostic resources that the client can access.

[0050] By adding multiple attribute information to the token, comprehensive verification basis can be provided for the diagnostic server, and access control of diagnostic resources can be implemented, effectively solving the technical problem that existing technologies cannot control access permissions to diagnostic resources.

[0051] In a preferred implementation, the token format is JWT. The token's security is ensured through a signature, and the token also records the permissions held by the client. The server uses this field to determine whether the current client has permission to access a specific resource, thus achieving access control. The token format is as follows: JSON Web Token {"typ":"JWT", "alg":"RSA2048S256"} {"iss":"XXX", "exp":1300819380, "identity info" "permission" "...."} { "signature" } type: Indicates the token type alg: represents the signature algorithm iss: Represents information about the token issuer. Exp: token validity period Identity information: Client's identity identifier Permission: Client permissions Signature: The token's signature S250, The diagnostic client initiates access to diagnostic resources to the diagnostic server based on the access token.

[0052] Specifically, the diagnostic client can initiate a specific diagnostic resource access request to the diagnostic server. The diagnostic resource access request may include an access token and diagnostic operation instructions to be executed.

[0053] S260. Receive the signature verification public key acquisition request sent by the diagnostic server.

[0054] The signature verification public key acquisition request can be understood as the diagnostic server requesting the authorization server to apply for the signature verification public key, which can be used to verify the legitimacy of the access token.

[0055] Understandably, when the diagnostic server receives a diagnostic resource access request from the diagnostic client, it needs to verify the access token in the request before allowing the client to access the diagnostic resources.

[0056] To verify the access token, a signature verification public key retrieval request needs to be sent to the diagnostic server to obtain the corresponding signature verification public key. At this time, the authorization server can receive the public key retrieval request sent by the diagnostic server.

[0057] S270. Issue a verification public key corresponding to the access token to the diagnostic server, so that the diagnostic server can perform a validity check on the access token based on the verification public key; if the verification is successful, allow the diagnostic client to perform diagnostic operations.

[0058] Specifically, the authorization server can distribute the signature verification public key to the diagnostic server, enabling the diagnostic server to verify access tokens. Furthermore, the diagnostic server performs a validity check on the access token based on the signature verification public key, and allows the diagnostic client to perform diagnostic operations if the verification passes.

[0059] In some possible implementations, the diagnostic server performs a validity check on the access token based on the signature verification public key, including: performing a signature check on the access token based on the signature verification public key, performing an expiration check on the access token, and performing an access token permission matching check. Signature verification refers to using a signature verification public key to verify the validity of the token signature. Validity verification checks whether the token is within the permitted time frame. Permission matching verification can be understood as verifying whether the token's permissions match the requested resource.

[0060] Specifically, the diagnostic server can use the obtained signature verification public key to sign and verify the token. After successful signature verification, it further verifies whether the token is within its validity period and whether the token's permissions match the requested resource. Once all the above verifications are successful, the diagnostic client can be allowed to perform the corresponding diagnostic operations.

[0061] In a preferred embodiment, Figure 3 A system architecture diagram of SOVD secure communication provided for the implementation of this invention is shown below. Figure 3 As shown, there are multiple operating systems OS1, OS2, and OS3 in HPC. Each operating system may contain one or more Service-Oriented Vehicle Diagnostics Clients (SOVD Clients) and SOVD Servers. Communication between them is forwarded by the Service-Oriented Vehicle Diagnostics Gateway (SOVD Gateway).

[0062] 1. The In-vehicle Authorization Server (IAS) is responsible for authenticating the service-oriented vehicle diagnostics client (SOVD Client) and issuing access tokens. It also provides credentials for the SOVD Server to verify the tokens. All domains access the trusted execution environment (TEX) through the Authorization Server.

[0063] 2. The SOVD security module is inherited as a dynamic library and is responsible for verifying the token and the Transport Layer Security (TLS) certificate.

[0064] 3. The Key Management Module is responsible for managing keys and certificates. All operations related to the private key are performed by this module, including the signing operation in the TLS handshake process. This module is located within the Trusted Execution Environment (TEE) to ensure that the private key does not leave the TEE. This environment includes, but is not limited to, the Trusted Execution Environment (TEE), the Hardware Security Module (HSM), and the Secure Element (SE).

[0065] 4. HTTP communication between SOVD Client and each server within HPC uses TLS for bidirectional security protection.

[0066] 5. Within the same operating system, the SOVD Server and Authorization Server communicate using IPC, including but not limited to shared memory and service-oriented Ethernet middleware protocols (Scalable service-oriented middleware over IP, SOME / IP). Between different operating systems, the SOVD Server and Authorization Server communicate using RPC, including but not limited to SOME / IP and Data Distribution Service (DDS).

[0067] like Figure 4 As shown in the flowchart, this embodiment of the invention provides a preferred service-oriented vehicle diagnostic security communication method. After the TLS connection between the SOVD client and the SOVD Server is established, the SOVD security communication process is as follows: 1. The SOVD client uses the identity certificate and challenge data to send an authentication and verification code request to the Authorization Server.

[0068] 2. The Authorization Server uses the root certificate of the identity certificate to verify the signature of the SOVD client's identity certificate. After successful verification, an authentication code is generated.

[0069] 3. The Authorization Server returns the authentication code to the SOVD client.

[0070] 4. The SOVD client uses the authentication code and challenge data to send a token request to the Authorization Server.

[0071] 5. The Authorization Server uses challenge data to verify the authentication code. If it passes, it generates a token. The token has a signature, which is performed in a trusted execution environment.

[0072] 6. The Authorization Server returns a token to the SOVD client.

[0073] 7. The SOVD client uses the token to send a diagnostic request to the SOVD server.

[0074] 8. The SOVD server queries the Authorization Server for the token verification public key.

[0075] 9. The Authorization Server returns the signature verification public key to the SOVD server.

[0076] 10. The SOVD server uses the public key to verify the token signature and performs other validity checks. If the verification passes, it performs relevant diagnostic operations.

[0077] 11. The SOVD server returns the operation results to the SOVD client, completing the entire process.

[0078] Note: Before this process, the relevant certificates need to be installed into the trusted execution environment, and the SOVD client needs to complete the registration of the identity certificate.

[0079] This invention provides security protection for SOVD communication: it encrypts communication data between the client and the server using the TLS protocol, and the TLS-related private key is only used within a secure execution environment, ensuring key security; it ensures the legitimacy of the access device through a client authentication mechanism; it implements secure verification and permission control of client access requests by introducing an access token; and it provides security support for cryptographic operations of the overall solution based on a trusted execution environment and a key management module, comprehensively improving the security and reliability of SOVD diagnostic interaction.

[0080] Figure 5 This is a schematic diagram of a service-oriented vehicle diagnostic safety communication device provided in an embodiment of the present invention. Figure 5 As shown, the device includes: The identity authentication module 510 is used to receive an identity authentication request sent by the diagnostic client and perform identity verification on the diagnostic client based on the identity authentication request; The authentication code generation module 520 is used to generate an authentication code when the identity verification is successful, and return the authentication code to the diagnostic client. The authentication code verification module 530 is used to receive a token application request carrying the authentication code sent by the diagnostic client and to perform verification on the authentication code; The access token processing module 540 is used to generate and sign an access token when the authentication code verification is successful, and issue the access token to the diagnostic client so that the diagnostic client can initiate access to diagnostic resources to the diagnostic server based on the access token.

[0081] The technical solution of this invention includes: receiving an authentication request sent by a diagnostic client; performing identity verification on the diagnostic client based on the authentication request; generating an authentication code if the identity verification is successful, and returning the authentication code to the diagnostic client; receiving a token request carrying the authentication code sent by the diagnostic client, and performing verification on the authentication code; generating and signing an access token if the authentication code verification is successful, and issuing the access token to the diagnostic client, so that the diagnostic client can initiate access to diagnostic resources from the diagnostic server based on the access token. This technical solution, through identity verification and authentication code verification, can prevent identity forgery; based on the signing and verification of the access token, the legitimacy of access to diagnostic resources can be ensured, preventing data tampering and replay attacks, thereby improving the security of service-oriented vehicle diagnostics.

[0082] In some possible implementations, the identity authentication module 510 includes: The certificate acquisition submodule is used to obtain the identity certificate of the diagnostic client based on the identity authentication request; The certificate verification submodule is used to verify the signature, integrity, and legality of the identity certificate using a preset root certificate.

[0083] In some possible implementations, the access token processing module 540 includes: The payload generation submodule is used to generate the plaintext payload of the access token; The signature execution submodule is used to sign the plaintext payload of the access token using a private key within the trusted execution environment; The token combination submodule is used to combine the signature with the plaintext payload of the access token to obtain the access token.

[0084] In some possible implementations, the trusted execution environment stores key material, and the signing operation is performed within the trusted execution environment based on the private key in the key material.

[0085] In some possible implementations, the key material includes asymmetric key pairs and digital certificates; The asymmetric key pair is used to perform the signing and verification operations of the access token, and the private key in the asymmetric key pair only participates in the operation within the trusted execution environment.

[0086] Among the possible implementations are: The public key interaction module is used to receive the signature verification public key acquisition request sent by the diagnostic server, and to issue the signature verification public key corresponding to the access token to the diagnostic server, so that the diagnostic server performs a legality verification on the access token based on the signature verification public key; if the verification is successful, the diagnostic client is allowed to perform diagnostic operations.

[0087] In some possible implementations, the access token includes at least one of the following: token type, signature algorithm, issuer information, validity period, client identity identifier, and diagnostic resource access permission information.

[0088] In some possible implementations, the public key exchange module is also used to cooperate with the diagnostic server to perform a validity check, the validity check including: Based on the signature verification public key, the access token is subjected to signature verification, validity period verification, and permission matching verification.

[0089] In some possible implementations, the diagnostic server is deployed on at least two operating systems within an in-vehicle high-performance computing platform; When the authorization server and the diagnostic server are located on the same operating system, the authorization server and the diagnostic server interact through inter-process communication. When the authorization server and the diagnostic server are located on different operating systems, the authorization server and the diagnostic server interact through remote procedure calls.

[0090] The service-oriented vehicle diagnostic safety communication device provided in the embodiments of the present invention can execute the service-oriented vehicle diagnostic safety communication method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of executing the method.

[0091] Figure 6 This is a schematic diagram of a vehicle for implementing the service-oriented on-board diagnostic secure communication method according to embodiments of the present invention. The vehicle is intended to represent various forms of digital computers, such as laptops, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframes, and other suitable computers. The vehicle can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0092] like Figure 6As shown, vehicle 60 includes at least one processor 61 and a memory, such as read-only memory (ROM) 62 and random access memory (RAM) 63, communicatively connected to the at least one processor 61. The memory stores computer programs executable by the at least one processor. The processor 61 can perform various appropriate actions and processes based on the computer program stored in ROM 62 or loaded into RAM 63 from storage unit 68. RAM 63 can also store various programs and data required for the operation of vehicle 60. The processor 61, ROM 62, and RAM 63 are interconnected via bus 64. Input / output (I / O) interface 65 is also connected to bus 64.

[0093] Multiple components in vehicle 60 are connected to I / O interface 65, including: input unit 66, such as keyboard, mouse, etc.; output unit 67, such as various types of displays, speakers, etc.; storage unit 68, such as disk, optical disk, etc.; and communication unit 69, such as network card, modem, wireless transceiver, etc. Communication unit 69 allows vehicle 60 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0094] Processor 61 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 61 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 61 performs the various methods and processes described above, such as service-oriented in-vehicle diagnostic safety communication methods.

[0095] In some embodiments, the service-oriented on-board diagnostic secure communication method can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 68. In some embodiments, part or all of the computer program can be loaded and / or installed on vehicle 60 via ROM 62 and / or communication unit 69. When the computer program is loaded into RAM 63 and executed by processor 61, one or more steps of the service-oriented on-board diagnostic secure communication method described above can be performed. Alternatively, in other embodiments, processor 61 can be configured to perform the service-oriented on-board diagnostic secure communication method by any other suitable means (e.g., by means of firmware).

[0096] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include: implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0097] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0098] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0099] To provide interaction with the user, the systems and technologies described herein can be implemented in a vehicle having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the vehicle. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0100] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0101] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0102] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0103] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A service-oriented on-board diagnostic safety communication method, characterized in that, include: Receive an authentication request sent by the diagnostic client, and perform identity verification on the diagnostic client based on the authentication request; If the identity verification is successful, an authentication code is generated and returned to the diagnostic client. Receive a token request request carrying the authentication code sent by the diagnostic client, and perform verification on the authentication code; If the authentication code is verified, an access token is generated and signed, and the access token is issued to the diagnostic client so that the diagnostic client can initiate access to diagnostic resources from the diagnostic server based on the access token.

2. The method according to claim 1, characterized in that, The authentication request carries the identity certificate of the diagnostic client; The step of performing identity verification on the diagnostic client based on the identity authentication request includes: The identity certificate is obtained based on the identity authentication request, and the signature, integrity and legality of the identity certificate are verified using a preset root certificate.

3. The method according to claim 1, characterized in that, The process of generating and signing an access token upon successful verification of the authentication code includes: Generate a plaintext payload for the access token, and sign the plaintext payload for the access token using a private key within the trusted execution environment; The access token is obtained by combining the signature with the plaintext payload of the access token.

4. The method according to claim 3, characterized in that, The trusted execution environment stores key materials, and the signing operation is performed within the trusted execution environment based on the private key in the key materials.

5. The method according to claim 4, characterized in that, The key materials include asymmetric key pairs and digital certificates; The asymmetric key pair is used to perform the signing and verification operations of the access token, and the private key in the asymmetric key pair only participates in the operation within the trusted execution environment.

6. The method according to claim 1, characterized in that, Also includes: Receive the signature verification public key acquisition request sent by the diagnostic server; The diagnostic server issues a public key for signature verification corresponding to the access token, so that the diagnostic server can perform a legality verification on the access token based on the public key for signature verification. If the verification passes, the diagnostic client is allowed to perform diagnostic operations.

7. The method according to claim 6, characterized in that, The access token includes at least one of the following: token type, signature algorithm, issuer information, validity period, client identity identifier, and diagnostic resource access permission information.

8. The method according to claim 7, characterized in that, The diagnostic server performs a validity check on the access token based on the signature verification public key, including: Based on the signature verification public key, the access token is subjected to signature verification, validity period verification, and permission matching verification.

9. The method according to claim 1, characterized in that, The diagnostic server is deployed on at least two operating systems of the in-vehicle high-performance computing platform; When the authorization server and the diagnostic server are located on the same operating system, the authorization server and the diagnostic server interact through inter-process communication. When the authorization server and the diagnostic server are located on different operating systems, the authorization server and the diagnostic server interact through remote procedure calls.

10. A service-oriented on-board diagnostic safety communication device, characterized in that, include: The identity authentication module is used to receive identity authentication requests sent by the diagnostic client and perform identity verification on the diagnostic client based on the identity authentication requests; The authentication code generation module is used to generate an authentication code when the identity verification is successful, and return the authentication code to the diagnostic client; The authentication code verification module is used to receive a token request request carrying the authentication code sent by the diagnostic client and to verify the authentication code. The access token processing module is used to generate and sign an access token when the authentication code verification is successful, and issue the access token to the diagnostic client so that the diagnostic client can initiate access to diagnostic resources to the diagnostic server based on the access token.

11. A vehicle, characterized in that, The vehicles include: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, which is then executed by the at least one processor to enable the at least one processor to perform the service-oriented vehicle diagnostic safety communication method according to any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the service-oriented vehicle diagnostic safety communication method according to any one of claims 1-9.

Images