An external device authentication method and apparatus, an electronic device, and a storage medium

Abstract

The application discloses an external device authentication method and device, electronic equipment and storage medium, the method comprises the following steps: obtaining the authentication request sent by the external device to the target end; the authentication request is attached with a device type, a device certificate and a signature; a preset rule is matched in a preset rule template according to the device type; based on the preset rule, the hardware accelerator is used to verify and check the device certificate and the signature; when the verification and checking result is successful, a session key is generated and distributed to the external device; wherein, the session key is used to establish an encrypted channel between the external device and the target end. The embodiment of the application combines the hardware accelerator with the flexible rule matching mechanism, not only improves the authentication and verification efficiency, but also enhances the security and scalability of the system, provides an efficient, reliable and secure communication solution for the Internet of Things and network communication field, and can be widely applied to the technical field of data processing.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to an external device authentication method, apparatus, electronic device, and storage medium. Background Technology

[0002] In the modern Internet of Things (IoT) and network communication fields, secure communication between devices is crucial. With the increasing demand for connectivity between external devices (such as diagnostic tools, upgrade devices, and smart terminals) and target devices (such as vehicle terminals), ensuring the security and reliability of communication has become one of the core challenges in technological development. Traditional authentication and encryption mechanisms often rely on software implementations, which, while meeting basic security requirements, become performance and efficiency bottlenecks when handling large-scale device connections and high-concurrency requests.

[0003] Existing technologies have many shortcomings in terms of device authentication rule adaptability, authentication efficiency, anomaly handling, and key management. For example, rule design relies on fixed configurations, updates are lagging and it is difficult to adapt to new device types; signature verification and certificate chain verification mainly rely on software processing, which is inefficient, especially in high-concurrency scenarios; the anomaly handling mechanism is simplistic and lacks support for device feature recording and analysis; the session key generation method is simple and lacks optimization and effective rotation and destruction mechanisms, resulting in significant security risks. Summary of the Invention

[0004] The main objective of this invention is to provide an external device authentication method, apparatus, electronic device, and storage medium to solve at least one problem in the prior art. This invention can securely achieve external device authentication.

[0005] To achieve the above objectives, one aspect of the present invention provides an external device authentication method, the method comprising:

[0006] Obtain the authentication request sent by the external device to the target device; the authentication request includes the device type, device certificate, and signature;

[0007] Preset rules are obtained by matching the device type with preset rule templates;

[0008] Based on pre-defined rules, a hardware accelerator is used to verify and validate device certificates and signatures;

[0009] If the verification result is successful, a session key is generated and distributed to the external device; the session key is used to establish an encrypted channel between the external device and the target.

[0010] In some embodiments, matching preset rules from a preset rule template based on the device type includes the following steps:

[0011] Determine the authentication rule requirements for external devices based on device type mapping;

[0012] The authentication rules require certificate verification requirements, signature algorithm support, and pre-defined special rules. The pre-defined special rules include one or more combinations of mandatory certificate verification rules, signature verification rules, dynamic key generation rules, and key rotation mechanisms.

[0013] Pre-defined rules are loaded from the rule template based on device type and authentication rule requirements;

[0014] If the device type is not found in the rule template, or if any rule requirement in the authentication rule is not matched or supported in the rule template, the preset rule loading is determined to have failed.

[0015] In some embodiments, the method further includes the following steps:

[0016] If no preset rule is found in the rule template based on the device type, a rule matching failure event is triggered.

[0017] In response to a rule matching failure event, an update request is sent to the OTA service so that the OTA service updates the rule template in response to the update request.

[0018] In some embodiments, based on preset rules, a hardware accelerator is used to verify and validate the device certificate and signature, including the following steps:

[0019] The certificate chain is traced back from the device certificate to the root certificate, and the integrity of the intermediate certificates is verified step by step to check whether they are issued by a trusted certificate authority. The certificate chain includes the device certificate, the root certificate, and at least one intermediate certificate.

[0020] The signatures corresponding to each certificate in the certificate chain are verified using hardware accelerators in parallelization.

[0021] Check whether the certificates in the certificate chain contain the extended fields required by the trust policy.

[0022] In some embodiments, generating a session key and distributing it to an external device includes the following steps:

[0023] A unique session key is randomly generated at the target end using a preset key algorithm. The session key is then encrypted using the public key of an external device to obtain an encryption key.

[0024] The encryption key is transmitted from the target end to the external device, so that the external device can decrypt the encryption key based on the private key corresponding to the public key to obtain the session key;

[0025] The encrypted channel is established through a handshake process using a preset communication protocol during the transmission of the encryption key.

[0026] In some embodiments, the verification includes certificate verification and signature verification. When the verification fails, the method further includes the following steps:

[0027] When the certificate verification result is a verification failure, the certificate verification failure information is recorded, and a warning and a prompt to update the certificate are sent to the external device.

[0028] When the signature verification result is a verification failure, access to external devices is restricted and the characteristic information of the external devices is recorded;

[0029] If the verification fails after a preset number of attempts, a preset alarm is triggered and a preset enhanced verification process is initiated.

[0030] In some embodiments, the method further includes at least one of the following steps:

[0031] The authentication process of external devices is logged based on a preset log format;

[0032] The session key is destroyed and rotated based on preset conditions.

[0033] To achieve the above objectives, another aspect of the present invention provides an external device authentication apparatus, the apparatus comprising:

[0034] The first module is used to obtain the authentication request sent by the external device to the target end; the authentication request includes the device type, device certificate and signature;

[0035] The second module is used to match preset rules from preset rule templates based on the device type;

[0036] The third module is used to verify and validate device certificates and signatures using a hardware accelerator based on preset rules.

[0037] The fourth module is used to generate a session key and distribute it to an external device when the verification result is successful; the session key is used to establish an encrypted channel between the external device and the target.

[0038] In some embodiments, the apparatus further includes:

[0039] The fifth module is used to trigger a rule matching failure event when no preset rule is found in the rule template based on the device type.

[0040] The sixth module is used to send an update request to the OTA service in response to a rule matching failure event, so that the OTA service updates the rule template in response to the update request.

[0041] In some embodiments, the verification includes certificate verification and signature verification, and the apparatus further includes:

[0042] The seventh module is used to record the certificate verification failure information and send warnings and certificate update prompts to external devices when the certificate verification result is a failure.

[0043] The eighth module is used to restrict access to external devices and record the characteristic information of external devices when the signature verification result is a verification failure.

[0044] The ninth module is used to trigger a preset alarm and start a preset enhanced verification process when the verification result fails after a preset number of verification attempts.

[0045] In some embodiments, the device further includes at least one of the following:

[0046] The tenth module is used to log the authentication process of external devices based on a preset log format;

[0047] The eleventh module is used to destroy and rotate session keys based on preset conditions.

[0048] To achieve the above objectives, another aspect of the present invention provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0049] To achieve the above objectives, another aspect of the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0050] This invention provides an external device authentication method, apparatus, electronic device, and storage medium. The scheme involves acquiring an authentication request sent by an external device to a target device; the authentication request includes device type, device certificate, and signature; matching the device type against a preset rule template to obtain pre-defined rules; verifying the device certificate and signature using a hardware accelerator based on the pre-defined rules; and generating a session key and distributing it to the external device when the verification is successful. The session key is used to establish an encrypted channel between the external device and the target device. This invention offers the following advantages:

[0051] 1. Flexible rule matching mechanism: Based on device type, the system matches pre-defined rules from preset rule templates, enabling it to flexibly respond to authentication requirements of different types of devices. This rule matching mechanism not only improves the system's scalability but also allows for dynamic adjustment of authentication strategies according to actual needs, enhancing the system's adaptability.

[0052] 2. Efficient Authentication and Verification: By introducing a hardware accelerator to verify device certificates and signatures, the efficiency of the authentication process is significantly improved. The hardware accelerator can process multiple verification tasks in parallel, reducing software implementation latency. Especially in high-concurrency scenarios, it can effectively reduce system response time and improve overall performance.

[0053] 3. Enhanced Security: The authentication process is secured by using hardware accelerators for certificate and signature verification. Hardware accelerators are resistant to common software attacks (such as side-channel attacks) and provide higher computational reliability, thereby enhancing the overall security of the system.

[0054] 4. Dynamic generation and distribution of session keys: After successful verification, the system can dynamically generate session keys and distribute them to external devices. This mechanism ensures that the communication channel between the external device and the target is encrypted, effectively preventing data leakage and man-in-the-middle attacks, and further enhancing communication security.

[0055] In summary, the embodiments of the present invention, by combining hardware accelerators with flexible rule matching mechanisms, not only improve the efficiency of authentication and verification, but also enhance the security and scalability of the system, providing an efficient and reliable secure communication solution for the Internet of Things and network communication fields. Attached Figure Description

[0056] Figure 1 This is a flowchart of the external device authentication method provided in an embodiment of the present invention;

[0057] Figure 2 This is a general flowchart of the external device authentication method provided in the embodiments of the present invention;

[0058] Figure 3 This is a flowchart of rule matching and rule verification provided in an embodiment of the present invention;

[0059] Figure 4 This is a schematic diagram illustrating the composition of the certificate provided in an embodiment of the present invention;

[0060] Figure 5 This is a schematic diagram of the certificate chain structure provided in an embodiment of the present invention;

[0061] Figure 6 This is a schematic diagram of the certificate verification and signature verification process provided in an embodiment of the present invention;

[0062] Figure 7 This is a schematic diagram of the external device authentication device provided in an embodiment of the present invention;

[0063] Figure 8 This is a schematic diagram of the hardware structure of the electronic device provided in an embodiment of the present invention. Detailed Implementation

[0064] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the embodiments of this invention; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this invention as detailed in the appended claims.

[0065] It is understood that the terms "first," "second," etc., used in this invention may be used to describe various concepts, but unless specifically stated otherwise, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of embodiments of this invention, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words "if" or "when" as used herein may be interpreted as "when," "in response to determination," or "in the event of a determination."

[0066] The terms “at least one,” “multiple,” “each,” “any,” etc., used in this invention, “at least one” includes one, two, or more than two; “multiple” includes two or more than two; “each” refers to each of the corresponding multiple; and “any” refers to any one of the multiple.

[0067] Unless otherwise defined, all technical and scientific terms used in this invention have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used in this invention is for descriptive purposes only and is not intended to limit the invention.

[0068] The external device authentication method provided in this invention relates to the field of data processing technology. This method can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or in-vehicle terminal, but is not limited thereto. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application implementing the external device authentication method, but is not limited to the above forms.

[0069] This invention can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This invention can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This invention can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0070] Figure 1 This is an optional flowchart of the external device authentication method provided in this embodiment of the invention. Figure 1 The method may include, but is not limited to, steps S100 to S400.

[0071] S100: Obtain the authentication request sent by the external device to the target device;

[0072] The authentication request includes the device type, device certificate, and signature.

[0073] For example, in some implementations, an external device sends an authentication request to the vehicle, along with a device certificate and signature.

[0074] S200: Match the preset rules in the preset rule template according to the device type;

[0075] It should be noted that in some embodiments, step S200 may include the following steps: determining the authentication rule requirements of the external device based on the device type mapping; wherein, the authentication rule requirements include certificate verification requirements, signature algorithm support, and preset special rules; the preset special rules include one or more combinations of mandatory certificate verification rules, signature verification rules, dynamic key generation rules, and key rotation mechanisms; loading preset rules into the rule template based on the device type and authentication rule requirements; wherein, if the device type is not found in the rule template, or if any rule requirement in the authentication rule requirements does not match or is not supported in the rule template, it is determined that the loading of the preset rules has failed.

[0076] For example, in some specific implementations, pre-defined rules can be loaded according to the device type, and the validity of external device certificates can be verified based on a pre-defined trusted certificate chain. Specifically, in some specific application scenarios, embodiments of the present invention provide configurable rule templates, allowing administrators to quickly generate authentication rules based on the characteristics of new device types.

[0077] Configurable rule templates include the following elements: device type (e.g., diagnostic tools, smartphones, OTA devices), certificate verification requirements (certificate chain verification depth, CA trust list), and signature algorithm support (supported signature algorithm types, such as RSA, ECC).

[0078] Specific authentication rules can also be defined for different types of external devices:

[0079] 1. Configure mandatory certificate verification rules for vehicle diagnostic tools to ensure the absolute trustworthiness of the device's identity;

[0080] 2. For smartphone applications, configure signature verification rules and improve authentication efficiency through hardware accelerators;

[0081] 3. Configure dynamic key generation rules for OTA upgrade devices and record the entire operation log;

[0082] In addition, for devices with long-term connections, a key rotation mechanism can be added to ensure communication security.

[0083] In some embodiments, the method may further include the following steps: when no preset rule is matched in the rule template according to the device type, a rule matching failure event is triggered; in response to the rule matching failure event, an update request is sent to the OTA service so that the OTA service updates the rule template in response to the update request.

[0084] For example, in some specific implementations, if the rules do not match, the latest OTA rules are automatically retrieved and updated. Specifically, OTA rule updates can be implemented as follows:

[0085] When the device is performing rule matching, if it finds that a suitable rule cannot be matched or the matching result does not meet expectations, the system will trigger a rule matching failure event (this event can be an exception capture, a specific log record, or a special event object used to notify the system of subsequent processing procedures).

[0086] Sending an update request: In the event handler for a rule matching failure, the system sends an update request to the OTA service. This request can be an HTTP request, a message queue message, or a WebSocket message, depending on the OTA service's interface type and communication protocol.

[0087] Receiving a new rule template: After sending an update request, the device needs to wait for a response from the OTA service. The OTA service will return the latest rule template as the response content to the device. After receiving the new rule template, the device stores it in its local rule file, replacing the old rule template.

[0088] Perform rule matching again: Use the newly loaded rule data to re-match the device with the rules. If the match is successful, the device continues subsequent operations according to the new rules; if the match still fails, detailed log information can be recorded for troubleshooting and further processing.

[0089] S300 uses a hardware accelerator to verify and validate device certificates and signatures based on preset rules.

[0090] It should be noted that in some embodiments, step S300 may include the following steps: tracing back from the device certificate to the root certificate, verifying step by step whether intermediate certificates are issued by a trusted certificate authority to detect the integrity of the certificate chain; wherein, the certificate chain includes the device certificate, the root certificate, and at least one intermediate certificate; using a hardware accelerator to parallelize the verification of the signature corresponding to each certificate in the certificate chain; and checking whether the certificates in the certificate chain contain the extended fields required by the trust policy.

[0091] For example, in some specific implementations, hardware accelerators can be used to quickly complete signature verification and certificate chain verification. For instance, dedicated hardware acceleration modules for RSA / ECC can be used to accelerate certificate verification and signature verification. Hardware acceleration support is provided for the commonly used SHA-256 hash algorithm. Simultaneously, certificate chain processing is parallelized to shorten verification time. Specifically, the device certificate can be traced back to the root certificate, verifying step-by-step whether intermediate certificates were issued by a trusted Certificate Authority (CA); verifying the validity of each level of certificate, including signature verification, certificate expiration, and revocation. Furthermore, hardware acceleration modules (such as RSA / ECC accelerators) are used to parallelize (decompose the authentication process into multiple independent tasks, such as step-by-step verification of the certificate chain, signature verification, hash calculation, etc. These tasks are relatively independent and can be executed in parallel) each signature in the certificate chain to ensure that the certificate has not been tampered with. Furthermore, it can be checked whether the certificate contains extension fields (such as device purpose and permission scope) required by the trust policy.

[0092] S400: If the verification result is successful, generate a session key and distribute it to external devices;

[0093] The session key is used to establish an encrypted channel between the external device and the target.

[0094] It should be noted that in some embodiments, generating a session key and distributing it to an external device may include the following steps: randomly generating a unique session key at the target end using a preset key algorithm, encrypting the session key using the public key of the external device to obtain an encryption key; transmitting the encryption key from the target end to the external device so that the external device can decrypt the encryption key based on the private key corresponding to the public key to obtain the session key; wherein, the encryption channel is established through a handshake process using a preset communication protocol during the transmission of the encryption key.

[0095] For example, in some specific implementations, a unique session key can be generated based on device characteristics, and the key can be securely distributed to an external device to establish an encrypted channel. Specifically, the session key generation and distribution can be implemented as follows: The algorithm for generating the session key can use the RSA algorithm. A random session key is generated at the vehicle end, encrypted using the public key of the external device, and then the encrypted key is sent to the external device. The external device decrypts the key using its private key, thus both parties obtain the same session key. During the process of sending the encrypted key to the external device, the TLS / SSL protocol is used, and an encrypted channel is established through a handshake process.

[0096] In some embodiments, the verification includes certificate verification and signature verification. When the verification result fails, the method may further include the following steps: when the certificate verification result fails, record the certificate verification failure information and send a warning and a certificate update prompt to the external device; when the signature verification result fails, restrict the access of the external device and record the characteristic information of the external device; when the verification result fails a preset number of times, trigger a preset alarm and start a preset enhanced verification process.

[0097] For example, in some implementations, successful authentication allows the device to access the vehicle network. Authentication failure logs detailed information and triggers a dynamic response (such as restricting device access or triggering an alarm). The dynamic response mechanism includes:

[0098] When certificate verification fails, trigger a device warning and prompt for certificate update; record detailed logs: record detailed information about the certificate verification failure, including device ID, certificate error type, time, etc.

[0099] When a signature verification error occurs, device access is restricted and device characteristics are recorded for subsequent analysis: Record device characteristics: Record device characteristic information, such as device ID, IP address, user agent, etc., for subsequent analysis.

[0100] When multiple authentication failures are detected, a high-priority alarm is triggered, and an enhanced verification process is initiated.

[0101] In some embodiments, the method may further include at least one of the following steps: logging the authentication process of the external device based on a preset log format; destroying and rotating the session key based on preset conditions.

[0102] For example, in some specific implementations, the authentication process and device behavior can be recorded in real time, while session keys are destroyed and rotated to ensure key security. In some specific application scenarios, this can be achieved as follows:

[0103] 1. Log format:

[0104] Operating entity: The entity (person or equipment) that records the operation.

[0105] Time: Records the time of the operation.

[0106] Purpose: To record the purpose of the operation.

[0107] Result: Record the result of the operation.

[0108] Detailed information: Records detailed information about certificate verification failures, including device ID, certificate error type, time, etc.

[0109] Storage location: Stored in the log file on the local server.

[0110] 2. Key Destruction:

[0111] Destruction conditions: Keys that are no longer in use should be deleted immediately, including backups and archives. This includes, but is not limited to, the following situations: key expires, key is suspected of being leaked, the key's intended use no longer exists, or security vulnerabilities are found in the encryption algorithm used by the key or the key management process.

[0112] Regular checks: Regularly check the usage of keys to ensure that keys that are no longer in use are destroyed in a timely manner.

[0113] 3. Key rotation:

[0114] Rotation conditions: Keys are rotated immediately when they reach the end of their lifespan or when they are considered to be potentially compromised or cracked.

[0115] Regular rotation: Keys are rotated periodically (e.g., every 30 days or every 90 days) to ensure key security.

[0116] To explain in detail the principle of the technical solution of the present invention, the overall process of the present invention will be described below with reference to some specific embodiments. It is easy to understand that the following is an explanation of the technical principle of the present invention and should not be regarded as a limitation of the present invention.

[0117] First, it's important to note that external device authentication in intelligent vehicle-to-everything (V2X) systems is typically handled using fixed rules. These rules are pre-configured during system development to match the type of external device and complete the relevant authentication operations. The authentication process mainly includes steps such as device type matching, certificate chain verification, and signature verification. After a device submits an authentication request, the system progressively verifies the validity of the certificate chain based on the device's certificate and signature information, ensuring the integrity of the certificate from the device certificate to the root certificate, while also verifying the legality and validity of the signature. Session key generation usually relies on a unified algorithm. After generating a key based on the device identifier, it is distributed to the device through a secure channel to establish an encrypted communication connection. The logging function involved in the authentication process can store key information about device authentication, such as the submission time of the device certificate and the authentication result, providing basic data support for subsequent auditing and analysis.

[0118] However, existing technologies have shortcomings in terms of device authentication rule adaptability, authentication efficiency, anomaly handling, and key management. To address these shortcomings, this invention provides a method for authenticating external devices in intelligent connected vehicles, aiming to solve the problem of counterfeit devices accessing vehicle networks. By optimizing the authentication process and log management, the legitimacy of external device access and the security of the vehicle network are ensured. This method does not require modification of the vehicle's original communication protocol; it achieves comprehensive authentication of external devices solely through HSM dynamic key generation and a rapid certificate verification mechanism. Simultaneously, detailed log recording and analysis effectively enhance the system's protection capabilities. Figure 2 As shown, the method of this embodiment of the invention can be implemented as follows:

[0119] S1. External device connection request:

[0120] The device sends an authentication request to the vehicle, along with the device certificate and signature.

[0121] S2, Dynamic Rule Matching:

[0122] The HSM module (authentication module) loads pre-defined rules based on the device type and verifies the validity of external device certificates against a pre-defined trusted certificate chain. If the rules do not match, it automatically retrieves the latest OTA rules and updates them.

[0123] It provides configurable rule templates, allowing administrators to quickly generate authentication rules based on the characteristics of new device types.

[0124] Configurable rule templates include the following elements: device type (e.g., diagnostic tools, smartphones, OTA devices), certificate verification requirements (certificate chain verification depth, CA trust list), and signature algorithm support (supported signature algorithm types, such as RSA, ECC).

[0125] Specific authentication rules can also be defined for different types of external devices:

[0126] 1. Configure mandatory certificate verification rules for vehicle diagnostic tools to ensure the absolute trustworthiness of the device's identity;

[0127] 2. For smartphone applications, configure signature verification rules and improve authentication efficiency through hardware accelerators;

[0128] 3. Configure dynamic key generation rules for OTA upgrade devices and record the entire operation log;

[0129] Furthermore, for devices with long-term connections, a key rotation mechanism can be added to ensure communication security. For example, using a JSON file:

[0130]

[0131]

[0132] Specifically, it determines whether a rule matches, providing a matching verification example, such as... Figure 3 As shown, after reading the rule template, the system verifies each device type and pre-defined authentication rule requirement (including checking certificate chain verification depth, checking the CA trust list, checking signature algorithm support, and detecting other rules, which correspond to the aforementioned specific authentication rules). When all authentication rule requirements are met, device authentication can be performed based on the loaded authentication rules.

[0133] In some specific application scenarios, the OTA rule updates are implemented as follows:

[0134] When the device is performing rule matching, if it finds that a suitable rule cannot be matched or the matching result does not meet expectations, the system will trigger a rule matching failure event (this event can be an exception capture, a specific log record, or a special event object used to notify the system of subsequent processing procedures).

[0135] Sending an update request: In the event handler for a rule matching failure, the system sends an update request to the OTA service. This request can be an HTTP request, a message queue message, or a WebSocket message, depending on the OTA service's interface type and communication protocol.

[0136] Receiving a new rule template: After sending an update request, the device needs to wait for a response from the OTA service. The OTA service will return the latest rule template as the response content to the device. After receiving the new rule template, the device stores it in its local rule file, replacing the old rule template.

[0137] Perform rule matching again: Use the newly loaded rule data to re-match the device with the rules. If the match is successful, the device continues subsequent operations according to the new rules; if the match still fails, detailed log information can be recorded for troubleshooting and further processing.

[0138] S3. Certificate Verification and Signature Verification:

[0139] Hardware accelerators are used to quickly complete signature verification and certificate chain verification. For example, dedicated hardware acceleration modules for RSA / ECC can be used to speed up certificate verification and signature verification. Hardware acceleration support is provided for the commonly used SHA-256 hash algorithm. Simultaneously, certificate chain processing is parallelized to reduce verification time. Figure 4 and Figure 5 As shown, the components of a certificate and the structure of the certificate chain are presented in sequence. Figure 6 As shown, the specific process can be implemented as follows:

[0140] S31. The authentication module receives the certificate submitted by the device.

[0141] S32. Check the integrity of the certificate chain:

[0142] The process traces from the device certificate back to the root certificate, verifying at each level whether intermediate certificates were issued by a trusted Certificate Authority (CA). The CA system is a tree structure, with each CA having one or more child CAs, and the top-level CA called the root CA. Certificate issuers of other CAs besides the root CA are their next-level CAs. This hierarchical relationship forms a trust chain.

[0143] Verify the validity of each level of certificate, including signature verification, certificate expiration, and revocation.

[0144] S33. Parallelize the authentication process using hardware acceleration modules (such as RSA / ECC accelerators) (decompose the authentication process into multiple independent tasks, such as step-by-step verification of the certificate chain, signature verification, hash calculation, etc. These tasks are relatively independent of each other and can be executed in parallel) to verify each signature in the certificate chain, ensuring that the certificate has not been tampered with.

[0145] Specific operations:

[0146] 1. Break down the certificates at each level in the certificate chain into independent tasks.

[0147] 2. Each task is executed in parallel by a hardware acceleration module, which performs signature verification and hash calculation.

[0148] Example as follows:

[0149] CASPER is an asymmetric cryptography accelerator provided by NXP Semiconductors that supports multiple operating modes, including 64-bit multiplication, 64-bit addition, 64-bit subtraction, and 64-bit XOR. Using this accelerator, two or four RAMs can be accessed in parallel, allowing for simultaneous access to 64-bit or 128-bit data, thus enabling parallel processing tasks.

[0150] S34. Check whether the certificate contains the extension fields (such as device purpose and permission scope) required by the trust policy.

[0151] S4. Session Key Generation and Distribution: Generate a unique session key based on device characteristics, securely distribute the key to external devices, and establish an encrypted channel. Specifically, this can be achieved as follows:

[0152] The session key can be generated using the RSA algorithm. The client (corresponding to the vehicle) generates a random session key, encrypts it using the server's (corresponding to the external device) public key, and then sends the encrypted key to the server. The server decrypts it using its private key, thus ensuring both parties have the same session key.

[0153] During the process of sending the encrypted key to the server, the TLS / SSL protocol is used to establish an encrypted channel through a handshake process:

[0154] Before sending the key, the sender first sends a connection request. The server returns an SSL / TLS certificate containing the server's public key, the Certificate Authority's (CA) signature, and other information. The server then checks the certificate's validity, verifying that it was issued by a trusted CA and that the public key in the certificate matches the expected value. If the certificate is invalid, the server terminates the connection; if valid, the server generates a symmetric encryption key, encrypts this key with its public key, and sends it to the server. Only the server can decrypt this key using its private key. Once the server successfully decrypts and obtains the symmetric key, both the sender and server can use it to encrypt and decrypt data. All subsequent communication uses this key to protect confidentiality and integrity, ensuring secure data transmission.

[0155] S5. Authentication Result Processing: Upon successful authentication, the device is allowed to access the vehicle network. If authentication fails, a detailed log is recorded, and a dynamic response is executed (such as restricting device access or triggering an alarm). Specifically, this can be achieved as follows:

[0156] Dynamic response mechanisms include:

[0157] When certificate verification fails, trigger a device warning and prompt for certificate update; record detailed logs: record detailed information about the certificate verification failure, including device ID, certificate error type, time, etc.

[0158] When a signature verification error occurs, device access is restricted and device characteristics are recorded for subsequent analysis: Record device characteristics: Record device characteristic information, such as device ID, IP address, user agent, etc., for subsequent analysis.

[0159] When multiple authentication failures are detected, a high-priority alarm is triggered, and an enhanced verification process is initiated.

[0160] S6. Log Recording and Key Management: Records the authentication process and device behavior in real time, while simultaneously destroying and rotating session keys to ensure key security. Specifically, this can be achieved as follows:

[0161] 1. Log format:

[0162] Operating entity: The entity (person or equipment) that records the operation.

[0163] Time: Records the time of the operation.

[0164] Purpose: To record the purpose of the operation.

[0165] Result: Record the result of the operation.

[0166] Detailed information: Records detailed information about certificate verification failures, including device ID, certificate error type, time, etc.

[0167] Storage location: Stored in the log file on the local server.

[0168] 2. Key Destruction:

[0169] Destruction conditions: Keys that are no longer in use should be deleted immediately, including backups and archives. This includes, but is not limited to, the following situations: key expires, key is suspected of being leaked, the key's intended use no longer exists, or security vulnerabilities are found in the encryption algorithm used by the key or the key management process.

[0170] Regular checks: Regularly check the usage of keys to ensure that keys that are no longer in use are destroyed in a timely manner.

[0171] 3. Key rotation:

[0172] Rotation conditions: Keys are rotated immediately when they reach the end of their lifespan or when they are considered to be potentially compromised or cracked.

[0173] Regular rotation: Keys are rotated periodically (e.g., every 30 days or every 90 days) to ensure key security.

[0174] In summary, this invention significantly improves rule adaptability by introducing a dynamic rule adaptation and real-time update mechanism and providing configurable rule templates to support rapid rule generation and real-time OTA updates based on device type. Simultaneously, it employs hardware acceleration optimization technology, utilizing RSA / ECC hardware acceleration modules and parallelized certificate chain processing to substantially improve the efficiency of signature verification and certificate verification, meeting the needs of high-concurrency scenarios. Furthermore, this invention designs a multi-level dynamic response mechanism to flexibly trigger warnings, restrict access, or enhance the verification process based on authentication anomalies, recording detailed characteristics for subsequent analysis. Regarding key management, this invention enhances communication security by dynamically generating session keys and implementing an efficient rotation and destruction mechanism, thereby constructing a more secure, efficient, and flexible vehicle network authentication system.

[0175] Compared with the prior art, the improved technical features and effects of the present invention are as follows:

[0176] 1. Dynamic rule loading and update mechanism:

[0177] HSM Pre-built Rules and OTA Updates: Authentication rules are automatically loaded based on device type. If there is a mismatch, online fetching and updating are supported to flexibly adapt to new device types.

[0178] Configurable templates: Provides templates for quickly generating authentication rules, supports differentiated authentication requirements, and adapts to multi-device scenarios.

[0179] 2. Introduce hardware acceleration to optimize authentication efficiency:

[0180] Hardware acceleration module: Significantly improves the efficiency of signature verification and certificate chain verification by utilizing RSA / ECC accelerators, with optimizations specifically for commonly used hash algorithms such as SHA-256.

[0181] Parallel processing of certificate chains: By changing the linear verification mode and introducing parallel computing, the verification time of long certificate chains is reduced, and the system operating efficiency is significantly improved.

[0182] 3. Deepin Certificate Verification and Dynamic Response Mechanism:

[0183] Deep certificate verification: Covers signature verification, validity period check, revocation status verification, and extended field check, improving authentication reliability.

[0184] Dynamic response mechanism:

[0185] Certificate verification failed: A warning is triggered and a prompt to update the certificate is displayed.

[0186] Signature verification error: Restrict device access and record characteristics for subsequent analysis.

[0187] Multiple failures detection: Trigger a high-priority alarm and initiate an enhanced verification process.

[0188] 4. Session key generation and management:

[0189] Unique session keys are dynamically generated based on device characteristics, and the security and efficiency of key management are improved through secure distribution, rotation, and destruction mechanisms.

[0190] like Figure 7 As shown, this embodiment of the invention also provides an external device authentication device 900, which may include:

[0191] The first module 901 is used to obtain the authentication request sent by the external device to the target end; the authentication request includes the device type, device certificate and signature;

[0192] The second module 902 is used to match preset rules from preset rule templates based on the device type;

[0193] The third module 903 is used to verify and validate device certificates and signatures using a hardware accelerator based on preset rules;

[0194] The fourth module 904 is used to generate a session key and distribute it to an external device when the verification result is successful; the session key is used to establish an encrypted channel between the external device and the target.

[0195] In some embodiments, the apparatus may further include:

[0196] The fifth module is used to trigger a rule matching failure event when no preset rule is found in the rule template based on the device type.

[0197] The sixth module is used to send an update request to the OTA service in response to a rule matching failure event, so that the OTA service updates the rule template in response to the update request.

[0198] In some embodiments, the verification includes certificate verification and signature verification, and the apparatus may further include:

[0199] The seventh module is used to record the certificate verification failure information and send warnings and certificate update prompts to external devices when the certificate verification result is a failure.

[0200] The eighth module is used to restrict access to external devices and record the characteristic information of external devices when the signature verification result is a verification failure.

[0201] The ninth module is used to trigger a preset alarm and start a preset enhanced verification process when the verification result fails after a preset number of verification attempts.

[0202] In some embodiments, the apparatus may further include at least one of the following:

[0203] The tenth module is used to log the authentication process of external devices based on a preset log format;

[0204] The eleventh module is used to destroy and rotate session keys based on preset conditions.

[0205] The content of the method embodiments of the present invention is applicable to the device embodiments. The specific functions implemented by the device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above methods.

[0206] This invention also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned external device authentication method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0207] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0208] Please see Figure 8 , Figure 8 The hardware structure of an electronic device 1000 according to another embodiment is illustrated. The electronic device 1000 includes:

[0209] The processor 1001 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present invention.

[0210] The memory 1002 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 1002 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1002 and is called and executed by the processor 1001 to execute the external device authentication method of the embodiments of this invention.

[0211] Input / output interface 1003 is used to implement information input and output;

[0212] The communication interface 1004 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0213] Bus 1005 transmits information between various components of the device (e.g., processor 1001, memory 1002, input / output interface 1003, and communication interface 1004);

[0214] The processor 1001, memory 1002, input / output interface 1003 and communication interface 1004 are connected to each other within the device via bus 1005.

[0215] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned external device authentication method.

[0216] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0217] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0218] The external device authentication method, external device authentication apparatus, electronic device, and storage medium provided in this invention obtain an authentication request sent by an external device to a target device. The authentication request includes a device type, device certificate, and signature. Preset rules are obtained by matching the device type against a preset rule template. Based on the preset rules, a hardware accelerator is used to verify the device certificate and signature. If the verification is successful, a session key is generated and distributed to the external device. The session key is used to establish an encrypted channel between the external device and the target device. This invention offers the following advantages:

[0219] 1. Flexible rule matching mechanism: Based on device type, the system matches pre-defined rules from preset rule templates, enabling it to flexibly respond to authentication requirements of different types of devices. This rule matching mechanism not only improves the system's scalability but also allows for dynamic adjustment of authentication strategies according to actual needs, enhancing the system's adaptability.

[0220] 2. Efficient Authentication and Verification: By introducing a hardware accelerator to verify device certificates and signatures, the efficiency of the authentication process is significantly improved. The hardware accelerator can process multiple verification tasks in parallel, reducing software implementation latency. Especially in high-concurrency scenarios, it can effectively reduce system response time and improve overall performance.

[0221] 3. Enhanced Security: The authentication process is secured by using hardware accelerators for certificate and signature verification. Hardware accelerators are resistant to common software attacks (such as side-channel attacks) and provide higher computational reliability, thereby enhancing the overall security of the system.

[0222] 4. Dynamic generation and distribution of session keys: After successful verification, the system can dynamically generate session keys and distribute them to external devices. This mechanism ensures that the communication channel between the external device and the target is encrypted, effectively preventing data leakage and man-in-the-middle attacks, and further enhancing communication security.

[0223] In summary, the embodiments of the present invention, by combining hardware accelerators with flexible rule matching mechanisms, not only improve the efficiency of authentication and verification, but also enhance the security and scalability of the system, providing an efficient and reliable secure communication solution for the Internet of Things and network communication fields.

[0224] The embodiments described in this invention are for the purpose of more clearly illustrating the technical solutions of the embodiments of this invention, and do not constitute a limitation on the technical solutions provided by the embodiments of this invention. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this invention are also applicable to similar technical problems.

[0225] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of the present invention, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0226] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the embodiments of the present invention, depending on actual needs.

[0227] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0228] The terms "first," "second," "third," "fourth," etc. (if present) in the specification 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 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.

[0229] It should be understood that in this invention, "at least one (item)" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0230] In the embodiments provided by this invention, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between systems or units may be electrical, mechanical, or other forms.

[0231] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments of the present invention, depending on actual needs.

[0232] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0233] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0234] The preferred embodiments of the present invention have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present invention. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and spirit of the present invention should be within the scope of the claims of the present invention.

Claims

1. An external device authentication method, characterized in that, The method includes the following steps: Obtain the authentication request sent by the external device to the target device; the authentication request includes the device type, device certificate, and signature; Preset rules are obtained by matching the device type with preset rule templates; The step of matching a preset rule from a preset rule template based on the device type includes the following steps: The authentication rule requirements for the external device are determined based on the device type mapping. The authentication rules require certificate verification requirements, signature algorithm support, and pre-defined special rules; the pre-defined special rules include one or more combinations of mandatory certificate verification rules, signature verification rules, dynamic key generation rules, and key rotation mechanisms. The preset rules are loaded from the rule template based on the device type and the authentication rule requirements; If the device type is not found in the rule template, or if any of the authentication rule requirements are not matched or supported in the rule template, the preset rule loading is determined to have failed. Based on the preset rules, a hardware accelerator is used to verify the device certificate and the signature; If the verification result is successful, a session key is generated and distributed to the external device; wherein, the session key is used to establish an encrypted channel between the external device and the target.

2. The external device authentication method according to claim 1, characterized in that, The method further includes the following steps: When no preset rule is matched in the rule template according to the device type, a rule matching failure event is triggered. In response to the rule matching failure event, an update request is sent to the OTA service so that the OTA service updates the rule template in response to the update request.

3. The external device authentication method according to claim 1, characterized in that, The verification and validation of the device certificate and the signature using a hardware accelerator based on the preset rules includes the following steps: The integrity of the certificate chain is checked by tracing back from the device certificate to the root certificate and verifying whether the intermediate certificates are issued by a trusted certificate authority. The certificate chain includes the device certificate, the root certificate, and at least one of the intermediate certificates. The signature corresponding to each certificate in the certificate chain is verified using the hardware accelerator in parallelization. Check whether the certificates in the certificate chain contain the extended fields required by the trust policy.

4. The external device authentication method according to claim 1, characterized in that, The process of generating a session key and distributing it to the external device includes the following steps: A unique session key is randomly generated at the target end using a preset key algorithm. The session key is then encrypted using the public key of the external device to obtain an encryption key. The encryption key is transmitted from the target end to the external device, so that the external device can decrypt the encryption key based on the private key corresponding to the public key to obtain the session key; The encryption channel is established through a handshake process using a preset communication protocol during the transmission of the encryption key.

5. The external device authentication method according to claim 1, characterized in that, The verification includes certificate verification and signature verification. When the verification fails, the method further includes the following steps: If the certificate verification fails, record the failure information and send a warning and a certificate update prompt to the external device. If the signature verification result is a verification failure, access to the external device is restricted and the characteristic information of the external device is recorded; If the verification fails a preset number of times, a preset alarm is triggered and a preset enhanced verification process is started.

6. The external device authentication method according to claim 1, characterized in that, The method further includes at least one of the following steps: The authentication process of the external device is logged based on a preset log format; The session key is destroyed and rotated based on preset conditions.

7. An external device authentication device, characterized in that, The device includes: The first module is used to obtain the authentication request sent by the external device to the target terminal; the authentication request includes the device type, device certificate and signature; The second module is used to match preset rules from a preset rule template based on the device type; The step of matching a preset rule from a preset rule template based on the device type includes the following steps: The authentication rule requirements for the external device are determined based on the device type mapping. The authentication rules require certificate verification requirements, signature algorithm support, and pre-defined special rules; the pre-defined special rules include one or more combinations of mandatory certificate verification rules, signature verification rules, dynamic key generation rules, and key rotation mechanisms. The preset rules are loaded from the rule template based on the device type and the authentication rule requirements; If the device type is not found in the rule template, or if any of the authentication rule requirements are not matched or supported in the rule template, the preset rule loading is determined to have failed. The third module is used to verify the device certificate and the signature using a hardware accelerator based on the preset rules. The fourth module is used to generate a session key and distribute it to the external device when the verification result is successful; wherein the session key is used to establish an encrypted channel between the external device and the target end.

8. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 6.

Images