A communication method and communication device based on a trusted execution environment

Abstract

The application discloses a communication method and communication equipment based on a trusted execution environment, and belongs to the field of communication technology. The method is applied to a communication equipment, a main execution environment and a trusted execution environment are run on the communication equipment, an application layer component and a protocol stack component are arranged in the main execution environment, and a security application component is arranged in the trusted execution environment. The method comprises the following steps: the application layer component sends a connection request to the protocol stack component; the protocol stack component obtains handshake information of a target equipment and sends the handshake information to the security application component; the security application component performs security decision on the handshake information to obtain a decision result and sends the decision result to the protocol stack component. Therefore, the embodiment of the application migrates the security decision process of the handshake information from the main execution environment to the trusted execution environment, overcomes the problem that an attacker can implement a downgrade attack or bypass a certificate verification mechanism to connect to a malicious device by tampering with handshake logic, and improves communication security.

Description

Technical Field

[0001] This application belongs to the fields of intelligent vehicle technology, connected vehicle technology, and communication technology, and specifically relates to a communication method and communication device based on a trusted execution environment. Background Technology

[0002] With the rapid development of intelligent connected vehicle technology, communication devices need to frequently interact with cloud servers or other communication devices and maintain secure communication. Taking in-vehicle communication devices as an example, they need to establish secure communication channels with cloud servers and in-vehicle electronic control units (ECUs). Typical scenarios include: Over-the-Air (OTA) upgrades, remote diagnostics, remote control, Vehicle-to-Everything (V2X) communication, in-vehicle electronic control unit (ECU) communication, and user data synchronization.

[0003] The aforementioned scenarios impose stringent security requirements on the communication process, such as ensuring firmware integrity, data confidentiality, valid authentication, and protection against replay attacks. Transport Layer Security (TLS), as a core technology for ensuring the security of these communications, is widely used in existing technologies.

[0004] However, in existing technical solutions, the TLS protocol stack runs entirely within a general-purpose operating system environment. In this implementation, security decisions during the TLS handshake process, such as certificate verification and security parameter negotiation, are entirely controlled by the ordinary operating system. This allows attackers to potentially carry out downgrade attacks by tampering with the handshake logic or bypass certificate verification mechanisms, leading to communication devices connecting to malicious devices and compromising communication security. Summary of the Invention

[0005] The purpose of this application is to provide a communication method and communication device based on a trusted execution environment, which can solve the technical problem in the prior art where attackers may carry out downgrade attacks by tampering with the handshake logic or bypassing the certificate verification mechanism, thereby causing the communication device to connect to a malicious device, making it impossible to effectively guarantee communication security.

[0006] To solve the above-mentioned technical problems, this application is implemented as follows: In a first aspect, embodiments of this application provide a communication method based on a trusted execution environment, applied to a communication device. The communication device runs a main execution environment and a trusted execution environment, which are physically isolated from the main execution environment at the hardware layer. The main execution environment includes application layer components and a protocol stack component, while the trusted execution environment includes a security application component. The method includes: The application layer component sends a connection request to the protocol stack component, wherein the connection request is used to request the establishment of a connection with the target device; The protocol stack component obtains the handshake information of the target device; The protocol stack component sends the handshake information to the security application component; The security application component performs a security ruling on the handshake information and obtains the ruling result. The security application component sends the ruling result to the protocol stack component.

[0007] Therefore, in this embodiment of the application, the communication device can run a main execution environment and a trusted execution environment. The main execution environment is equipped with an application layer component and a protocol stack component, while the trusted execution environment is equipped with a secure application component. In this way, the application layer component can send a connection request to the protocol stack component to request to establish a connection with the target device, thereby enabling the protocol stack component to obtain the handshake information of the target device. The obtained handshake information is then sent to the secure application component, which performs a security ruling on the handshake information and returns the ruling result to the protocol stack component.

[0008] In this embodiment, the trusted execution environment (TEE) is physically isolated from the main execution environment at the hardware layer, possessing an independent secure computing area that effectively resists malicious attacks. In this application, the secure decision-making process for handshake information is migrated from the main execution environment to the TEE, where the secure application component independently completes the security decision. The protocol stack component in the main execution environment is only responsible for forwarding the handshake information and has no right to modify the decision result. This overcomes the problem of attackers carrying out downgrade attacks by tampering with the handshake logic or bypassing certificate verification mechanisms to connect to malicious devices, thereby improving communication security.

[0009] Secondly, embodiments of this application provide a communication device on which a main execution environment and a trusted execution environment run, the trusted execution environment and the main execution environment being physically isolated at the hardware layer; the main execution environment is provided with application layer components and protocol stack components, and the trusted execution environment is provided with security application components; The application layer component is used to: send a connection request to the protocol stack component, wherein the connection request is used to request to establish a connection with the target device; The protocol stack component is used to: obtain the handshake information of the target device and send the handshake information to the security application component; The security application component is used to: perform security adjudication on the handshake information, obtain the adjudication result, and send the adjudication result to the protocol stack component.

[0010] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0011] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect. Attached Figure Description

[0012] To more clearly illustrate the technical solutions of the application embodiments, the drawings used in the description of the application embodiments will be briefly introduced below. Obviously, the 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.

[0013] Figure 1 This is a flowchart illustrating a communication method based on a trusted execution environment provided in an embodiment of this application; Figure 2 This is a schematic diagram of the system architecture to which the communication method based on a trusted execution environment is applicable in the embodiments of this application; Figure 3 This is a flowchart illustrating the handshake establishment phase in a specific implementation provided in this application. Figure 4 This is a flowchart illustrating the secure data transmission stage in a specific embodiment provided in this application. Figure 5 This is a flowchart illustrating the session secure destruction phase in a specific implementation provided in this application's embodiments; Figure 6 This is a structural block diagram of the communication device provided in the embodiments of this application; Figure 7 A structural block diagram of the electronic device provided in the application embodiment. Detailed Implementation

[0014] In the application embodiments, the term "and / or" describes the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The character " / " generally indicates that the preceding and following associated objects have an "or" relationship.

[0015] In the embodiments of this application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0016] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0017] In a first aspect, embodiments of this application provide a communication method based on a trusted execution environment, applied to a communication device, wherein a main execution environment and a trusted execution environment (TEE) run on the communication device, and the trusted execution environment and the main execution environment are physically isolated at the hardware layer; the main execution environment is provided with application layer components and protocol stack components, and the trusted execution environment is provided with security application components.

[0018] Optionally, the main execution environment also includes a client library component; the protocol stack component calls the security application component through the client library component. The client library component encapsulates the calling interface of the trusted execution environment, so that each time the protocol stack component calls the trusted execution environment, it can do so through the client library component.

[0019] In some embodiments, the primary execution environment can be a rich execution environment, such as a general execution environment running a general-purpose operating system, which is feature-rich but has relatively low security.

[0020] In some embodiments, the Trusted Execution Environment (TEE) refers to a secure isolation area inside the processor chip, which runs in isolation from ordinary operating systems (such as REE) and has hardware-level security protection capabilities. The TEE can be implemented by a TrustZone architecture or an Intel SGX architecture.

[0021] It should be noted that secure applications running within a trusted execution environment are called Trusted Applications (TAs), which can be responsible for performing sensitive operations such as key management and encryption / decryption.

[0022] In some embodiments, the Trusted Execution Environment Operating System (TEE OS) can be the operating system of the Qualcomm Secure Execution Environment (QSEE), the Open Portable Trusted Execution Environment Operating System (OP-TEE), or a Trusty OS.

[0023] In some embodiments, the communication device may be an in-vehicle device, a terminal device, or an ECU.

[0024] like Figure 1 As shown, the communication method based on the trusted execution environment may include the following steps 101 to 105: Step 101: The application layer component sends a connection request to the protocol stack component.

[0025] The connection request is used to request the establishment of a connection with the target device. In some embodiments, the target device can be a server, an in-vehicle device, or an ECU. It should be noted that when both the communication device and the target device are in-vehicle devices, they are different in-vehicle devices; when both the communication device and the target device are ECUs, they can be different ECUs within the same in-vehicle device.

[0026] Optionally, when any application installed on the communication device needs to establish a connection with the target device, the application layer component may send a connection request to the protocol stack component.

[0027] Step 102: The protocol stack component obtains the handshake information of the target device.

[0028] In some embodiments, the handshake information of the target device includes: the protocol version supported by the target device, the cipher suites supported by the target device, the certificate chain of the target device, and the parameters (e.g., curve parameters) of the cryptographic algorithms supported by the target device.

[0029] For example, the cryptographic algorithms described herein may be any of the following: Advanced Encryption Standard - Galois / Counter Mode (AES-GCM) algorithm, State Cryptography Algorithm 4 - Galois / Counter Mode (SM4-GCM), Elliptic Curve Digital Signature Algorithm (ECDSA), Edwards Curve Digital Signature Algorithm (EdDSA), or Elliptic Curve Public Key Cryptography Algorithm (SM2).

[0030] Optionally, the protocol stack component obtains the handshake information of the target device, including: The protocol stack component sends a list of protocol versions supported by the protocol stack component and a list of cipher suites supported by the protocol stack component to the target device; The protocol stack component receives the protocol versions and cipher suites supported by the target device, wherein the protocol versions supported by the target device are at least one of the protocol version lists, and the cipher suites supported by the target device are at least one of the cipher suite lists. The protocol stack component receives the certificate chain of the target device and parameters of the cryptographic algorithms supported by the target device.

[0031] Step 103: The protocol stack component sends the handshake information to the security application component.

[0032] In some embodiments, after the protocol stack component obtains the handshake information, it can package it and send it to the security application component at once, so that the security application component can make a security ruling on the handshake information.

[0033] Step 104: The security application component performs a security ruling on the handshake information and obtains the ruling result.

[0034] Optionally, if a client library component is also provided in the main execution environment, the protocol stack component calls the security application component through the client library component to perform security adjudication on the handshake information.

[0035] Optionally, the security application component performs a security ruling on the handshake information, including: The security application component determines whether the protocol version supported by the target device is in the allowed list, wherein the allowed list includes at least one predetermined protocol version; wherein, if the protocol version supported by the target device is in the allowed list, the protocol version supported by the target device passes the security ruling; otherwise, the protocol version supported by the target device fails the security ruling. The security application component determines whether the algorithm associated with the cipher suite supported by the target device belongs to a predetermined security algorithm; wherein, if the algorithm associated with the cipher suite supported by the target device belongs to a predetermined security algorithm, the cipher suite supported by the target device passes the security ruling; otherwise, the cipher suite supported by the target device fails the security ruling. The security application component verifies the validity period, domain name, and root CA certificate of the target device's certificate chain; wherein, if the validity period, domain name, and root CA certificate all pass the verification, the target device's certificate chain passes the security ruling; otherwise, the target device's certificate chain fails the security ruling. The security application component determines whether the parameters of the cryptographic algorithm supported by the target device belong to the parameters of a predetermined cryptographic algorithm; wherein, if the parameters of the cryptographic algorithm supported by the target device belong to the parameters of a predetermined cryptographic algorithm, the parameters of the cryptographic algorithm supported by the target device pass the security decision; otherwise, the parameters of the cryptographic algorithm supported by the target device fail the security decision.

[0036] It should be noted that the handshake information passes security arbitration if all the contents included in the handshake information pass the security arbitration; otherwise, the handshake information fails the security arbitration.

[0037] In some embodiments, the security application component can calculate the hash value of the root CA certificate in the certificate chain of the target device and determine whether the hash value exists in a pre-stored hash value list. If the hash value exists in the pre-stored hash value list, the root CA certificate is verified; otherwise, the root CA certificate is not verified.

[0038] By storing the hash value of the trusted root CA certificate instead of the complete certificate within the trusted execution environment, storage space is saved while hardware-level protection of the root CA trust anchor is achieved.

[0039] Optionally, the trusted execution environment is further provided with a secure storage component; the list of hash values ​​mentioned above is stored in the secure storage component.

[0040] Step 105: The security application component sends the ruling result to the protocol stack component.

[0041] The security application component sends the arbitration result to the protocol stack component, causing the protocol stack component to perform key derivation based on the arbitration result or send a connection failure message to the application layer component.

[0042] As can be seen from steps 101 to 105 above, in this embodiment of the application, the communication device can run a main execution environment and a trusted execution environment. The main execution environment is equipped with an application layer component and a protocol stack component, and the trusted execution environment is equipped with a secure application component. In this way, the application layer component can send a connection request to the protocol stack component to request to establish a connection with the target device, thereby enabling the protocol stack component to obtain the handshake information of the target device, and then send the obtained handshake information to the secure application component. The secure application component then performs a security ruling on the handshake information and returns the ruling result to the protocol stack component.

[0043] In this embodiment, the trusted execution environment (TEE) is physically isolated from the main execution environment at the hardware layer, possessing an independent secure computing area that effectively resists malicious attacks. In this application, the secure decision-making process for handshake information is migrated from the main execution environment to the TEE, where the secure application component independently completes the security decision. The protocol stack component in the main execution environment is only responsible for forwarding the handshake information and has no right to modify the decision result. This overcomes the problem of attackers carrying out downgrade attacks by tampering with the handshake logic or bypassing certificate verification mechanisms to connect to malicious devices, thereby improving communication security.

[0044] In addition, by decoupling the security adjudication function from the protocol stack components and deploying it in a trusted execution environment, the updates and maintenance of security policies do not require modification of the protocol stack component code, reducing system coupling and facilitating independent upgrades and management of security functions.

[0045] Furthermore, the security application components in the Trusted Execution Environment (TEE) perform security adjudication, ensuring that every connection request undergoes rigorous security verification. Only the handshake information that passes the adjudication can continue the subsequent communication establishment process, thereby guaranteeing a secure connection between the communication device and the legitimate target device.

[0046] Optionally, the method further includes the following steps A-1 and / or A-2: Step A-1: ​​If the arbitration result indicates that the handshake information has passed the security arbitration, the protocol stack component calls the security application component to perform key derivation to obtain the first session key; Step A-2: If the arbitration result indicates that the handshake information has not passed the security arbitration, the protocol stack component sends a connection failure indication message to the application layer component.

[0047] The first session key is used to: encrypt data or information sent by the communication device to the target device, and decrypt data or information from the target device.

[0048] As can be seen, in some embodiments, after transferring the security decision-making power of the handshake from the main execution environment to the trusted execution environment, a strong binding between the adjudication and key derivation can be achieved, thereby avoiding bypassing the security adjudication process to perform key derivation, and thus improving communication security.

[0049] Furthermore, if the handshake message fails to pass the arbitration, key derivation will not be performed, thus avoiding the waste of computing resources and preventing the generation of any key material on insecure connections. This completely eliminates the insecure communication mode of "connect first, worry later".

[0050] Optionally, before the protocol stack component calls the security application component to perform key derivation, the method further includes the following steps B-1 to B-2: Step B-1: After receiving the connection request, the protocol stack component calls the security application component to generate the first random number for the client; In some embodiments, after receiving a connection request, the protocol stack component can send a session initialization request to the security application component, enabling the security application component to generate a first random number for the client and return the first random number to the protocol stack component. Furthermore, the security application component can also assign a session identifier (ID) and return the session ID to the protocol stack component, so that subsequent interactions are associated with this session ID.

[0051] Step B-2: The protocol stack component obtains the second random number of the target device and the first public key of the target device; In some embodiments, the target device can generate a second random number and a first public key and a first private key of the target device, thereby storing the first public key and the first private key, and returning the first public key and the second random number to the protocol stack component. The first public key and the first private key constitute a key pair.

[0052] Optionally, in step A-1 above, the protocol stack component calls the security application component to perform key derivation to obtain the first session key, including the following steps A-1.1 to A-1.4: A-1.1: The protocol stack component sends the second random number and the first public key to the security application component; it should be noted that, after the protocol stack component obtains the second random number and the first public key through step B-2, it can send the second random number and the first public key to the security application component so that the security application component can use the first public key and the second random number to perform the key derivation process.

[0053] A-1.2: The security application component generates a second public key and a second private key for the client, and stores the second public key and the second private key; wherein, the second public key and the second private key constitute a key pair; in addition, the second private key is stored in a trusted execution environment and is never output.

[0054] A-1.3: The security application component generates a first shared key based on the second private key and the first public key, generates a first master key based on the first shared key, the second random number and the first random number, derives a first session key based on the first master key, and stores the first session key.

[0055] In some embodiments, the security application component may execute an elliptic curve algorithm based on a second private key and a first public key to obtain a first shared key; wherein the first shared key is stored in a trusted execution environment.

[0056] In some embodiments, the security application component can obtain the first master key according to the first formula, wherein the first formula is: master_secret_1=PRF(premaster_secret_1,"master_secret", client_random+server_random), where master_secret_1 represents the first master key, premaster_secret_1 represents the first shared key, client_random represents the first random number, server_random represents the second random number, PRF represents a pseudo-random function, and "master_secret" represents a fixed string.

[0057] In some embodiments, the security application component can obtain a first key block key_block_1 according to a second formula, and then derive a first session key from the first key block; wherein, the second formula is: key_block_1=PRF(master_secret_1,"key expansion",server_random+client_random); "key expansion" represents a fixed string; In addition, the first session key includes: The key used by the security application component to encrypt or by the target device to decrypt; client_write_key; The key used by the target device's encryption or security application components to decrypt the data, server_write_key; Client-side initialization vector client_write_IV; Target device orientation initialization vector server_write_IV.

[0058] As can be seen, two different sets of keys are used here to protect the two communication directions respectively: the communication device to the target device direction uses client_write_key+client_write_IV; the target device to the communication device direction uses server_write_key+server_write_IV.

[0059] It should be noted that if the same key is used in both directions, the same plaintext will produce the same ciphertext (exposing duplicate content), and an attacker can "reflect" the ciphertext from one side to impersonate the other side's message. Using different keys in both directions completely isolates this risk.

[0060] Furthermore, even with the same key and plaintext, different initialization vectors will produce different ciphertexts. For example, in Advanced Encryption Standard - Galois / Counter Mode (AES-GCM), the complete numeric one-time use value (nonce) consists of a fixed initialization vector (4 bytes) plus an incrementing sequence number for each message (8 bytes), ensuring that the encryption result of each message is different.

[0061] A-1.4: The security application component sends the key handle associated with the first session key to the protocol stack component. The key handle represents a reference identifier that does not expose the plaintext of the key. The handle allows a request to the TEE to perform cryptographic operations, but does not allow direct access to the key itself.

[0062] As can be seen from the above, in this embodiment of the application, on the communication device side, the key derivation process can be executed in a trusted execution environment, and the derived key can be stored in the trusted execution environment, thereby further ensuring the security of the key.

[0063] Optionally, if a secure storage component is also provided in the trusted execution environment, the first session key, the first shared key, the first master key, and the first key block can be stored in the secure storage component.

[0064] Optionally, after the security application component generates the first random number, the method further includes the following steps C-1 to C-2: Step C-1: The security application component sends the first random number to the protocol stack component; Step C-2: The protocol stack component sends the first random number to the target device; As can be seen from steps C-1 to C-2, in some embodiments, after the security application component generates the first random number, it can send the first random number to the protocol stack component, so that the protocol stack component sends the first random number to the target device, thereby enabling the target device to use the first random number for key derivation; After the security application component generates the client's second public key and second private key, the method further includes the following steps C-3 to C-4: Step C-3: The security application component sends the second public key to the protocol stack component; Step C-4: The protocol stack component sends the second public key to the target device, so that the target device generates a second shared key based on the second public key and the first private key of the target device, generates a second master key based on the second shared key, the second random number and the first random number, and derives a second session key based on the second master key; The second session key is used to: encrypt data or information sent by the target device to the communication device, and to decrypt data or information from the communication device.

[0065] As can be seen from steps C-3 to C-4, in some embodiments, after the security application component generates the second public key, it can send the second public key to the protocol stack component, so that the protocol stack component can send the second public key to the target device, thereby enabling the target device to use the second public key for key derivation.

[0066] In some embodiments, the target device may perform an elliptic curve algorithm based on the second public key and the first private key to obtain a second shared key.

[0067] In some embodiments, the target device can obtain the second master key according to the third formula, where the third formula is: master_secret_2=PRF(premaster_secret_2,"master_secret", client_random+server_random), where master_secret_2 represents the second master key, premaster_secret_2 represents the second shared key, client_random represents the first random number, server_random represents the second random number, PRF represents the pseudo-random function, and "master_secret" represents a fixed string.

[0068] In some embodiments, the target device can obtain the second key block key_block_2 according to the fourth formula, and then derive the second session key from the second key block; wherein, the fourth formula is: key_block_2=PRF(master_secret_2,"key expansion",server_random+client_random)"key expansion" represents a fixed string; In addition, the second session key includes: The key used by the security application component to encrypt or by the target device to decrypt; client_write_key; The key used by the target device's encryption or security application components to decrypt the data, server_write_key; Client-side initialization vector client_write_IV; Target device orientation initialization vector server_write_IV.

[0069] Therefore, it can be seen that the security application component and the target device can calculate the same first session key and second session key using the method described above.

[0070] Optionally, the method further includes the following steps D-1 to D-3: Step D-1: The protocol stack component sends the client certificate to the target device; Optionally, before step D-1, the method further includes: the target device sending a first request to the protocol stack component, wherein the first request is used to request the client certificate; in this way, after receiving the first request, the protocol stack component can return the client certificate to the target device.

[0071] Step D-2: The protocol stack component calls the security application component to generate a digital signature based on the client's second private key; Step D-3: The protocol stack component sends the digital signature to the target device, so that the target device verifies the digital signature based on the client's second public key in the client certificate.

[0072] The digital signature is generated based on the client's second private key. After the target device receives the client certificate and the digital signature, it can verify the digital signature using the second public key in the client certificate. It is understood that if the digital signature passes verification, it indicates that the client's second private key is stored in the trusted execution environment.

[0073] In some embodiments, after receiving the client certificate, the target device can also verify the authenticity of the client certificate, that is, verify the certificate chain of the client certificate level by level from the bottom up; for example, if the certificate chain of the client certificate is as follows: [Client Device Certificate] → Issuer → [Intermediate CA Certificate] → Issuer → [Root CA Certificate] The verification process is as follows: (1) Retrieve the "Issuer" field of the client device certificate → Find the intermediate CA certificate; (2) Verify the digital signature of the client certificate using the public key of the intermediate CA certificate; (3) Extract the "Issuer" field of the intermediate CA certificate → find the root CA certificate; (4) Verify the digital signature of the intermediate CA certificate using the public key of the root CA certificate; (5) Verify whether the root CA certificate is in the "trusted root CA list" of the target device; In addition, you can check: certificate validity period, revocation status information (such as Certificate Revocation List (CRL) / Online Certificate Status Protocol (OCSP)), and usage constraints (such as whether the Key Usage extension field in the digital certificate supports scenarios where the public key is used for client authentication).

[0074] Optionally, in step D-2 above, the protocol stack component calls the security application component to generate a digital signature based on the client's second private key, including the following steps D-2.1 to D-2.3: Step D-2.1: The protocol stack component calculates the hash value of the handshake message, wherein the handshake message includes the handshake message between the protocol stack component and the target device; for example, the handshake message may include all handshake messages exchanged between the protocol stack component and the target device; It should be noted that the reason for calculating the hash value of the handshake message between the protocol stack component and the target device in step D-2.1, instead of calculating the hash value of fixed content, is as follows: It can prevent replay attacks: that is, the handshake messages are different each time (client_random / server_random are different each time), and the digital signature is also different each time; Context binding is possible: digital signatures can be bound to a specific handshake. Man-in-the-middle tampering with any handshake message will cause hash inconsistencies, resulting in signature verification failure.

[0075] Step D-2.2: The protocol stack component sends the hash value to the security application component; Step D-2.3: The security application component signs the hash value according to the second private key to obtain the digital signature, and sends the digital signature to the protocol stack component.

[0076] Therefore, after the security application component generates a digital signature, it can return the digital signature to the protocol stack component without returning the second private key. In this way, the second private key is always protected in the trusted execution environment. Even if the main execution environment is compromised, the attacker cannot steal or clone the second private key.

[0077] It should be noted that, when the protocol stack component calls the security application component to generate a digital signature based on the client's second private key through steps D-2.1 to D-2.3 above, after the target device receives the digital signature, it can calculate the hash value of the handshake message, extract the second public key from the client certificate, and use the second public key to decrypt the digital signature to obtain a hash value. Then, it compares whether the hash value obtained from the decryption is the same as the hash value calculated by the target device. If they are the same, the digital signature passes the verification; otherwise, the digital signature fails the verification.

[0078] It should also be noted that by verifying the authenticity of the client certificate, it can be proven that the certificate is a genuine certificate issued by a trusted CA. By verifying the digital signature mentioned above, it can be proven that the "sender" does indeed hold the private key of this certificate. Thus, the final conclusion can be reached: this client is the legitimate device claimed by the certificate.

[0079] Optionally, the method further includes the following steps E-1 to E-3: Step E-1: The protocol stack component calls the security application component to verify whether the first session key and the second session key are the same; Step E-2: If the first session key and the second session key are the same, the protocol stack component sends a connection success indication message to the application layer component; and / or, Step E-3: If the first session key is different from the second session key, the protocol stack component sends a connection failure indication message to the application layer component.

[0080] As can be seen, in some embodiments, after deriving the first session key and the second session key, it is possible to further verify whether the first session key and the second session key are the same, so as to ensure that data transmission can be performed using the first session key and the second session key in the future.

[0081] Optionally, in step E-1 above, the protocol stack component calls the security application component to verify whether the first session key and the second session key are the same, including the following steps E-1.1 to E-1.4: Step E-1.1: The protocol stack component calls the security application component to generate the first handshake end information based on the first session key associated with the key handle; In some embodiments, in step E-1.1, the protocol stack component calls the security application component to generate first handshake end information based on the first session key associated with the key handle, including: The protocol stack component sends the client's tag information and key handle to the security application component; The security application component generates first verification data based on the first master key, the client's tag information, and the hash value of the handshake message, wherein the handshake message includes the handshake message between the protocol stack component and the target device; The security application component encrypts the first verification data according to the first session key associated with the key handle to obtain the first handshake end information, and sends the first handshake end information to the protocol stack component.

[0082] The security application component can input the first master key, the client's tag information, and the hash value of the handshake message into a pseudo-random function to obtain the first verification data.

[0083] Step E-1.2: The protocol stack component sends the first handshake end information to the target device, so that the target device verifies the first handshake end information according to the second session key; In some embodiments, in step E-1.2, the target device verifies the first handshake end information based on the second session key, including: The target device decrypts the first handshake end information using the second session key to obtain second verification data. Based on the second master key, the client's tag information, and the hash value of the handshake message, it generates third verification data and compares whether the third verification data is consistent with the second verification data. If the third verification data is consistent with the second verification data, the first handshake end information passes verification; otherwise, the first handshake end information fails verification.

[0084] The target device can input the second master key, the client's tag information, and the hash value of the handshake message into a pseudo-random function to obtain the third verification data.

[0085] Step E-1.3: The protocol stack component receives second handshake end information from the target device, wherein the second handshake end information is generated based on the second session key; In some embodiments, in step E-1.3, the target device generates second handshake end information based on the second session key, including: The target device generates fourth verification data based on the second master key, the target device's tag information, and the hash value of the handshake message, wherein the handshake message includes the handshake message between the protocol stack component and the target device; The target device encrypts the fourth verification data according to the second session key to obtain the second handshake end information.

[0086] The target device can input the second master key, the target device's tag information, and the hash value of the handshake message into a pseudo-random function to obtain the fourth verification data.

[0087] Step E-1.4: The protocol stack component calls the security application component to verify the second handshake end information based on the first session key associated with the key handle; In some embodiments, in step E-1.4, the protocol stack component calls the security application component to verify the second handshake end information based on the first session key associated with the key handle, including: The protocol stack component sends the second handshake end information and the key handle to the security application component; The security application component decrypts the second handshake end information based on the first session key associated with the key handle to obtain the fifth verification data. Based on the first master key, the tag information of the target device, and the hash value of the handshake message, it generates the sixth verification data and compares the fifth verification data with the sixth verification data to obtain the verification result of the second handshake end information. If the fifth verification data and the sixth verification data are consistent, the second handshake end information passes the verification; otherwise, the second handshake end information fails the verification. The security application component sends the verification result of the second handshake end information to the protocol stack component.

[0088] The security application component can input the first master key, the target device's tag information, and the hash value of the handshake message into a pseudo-random function to obtain the sixth verification data.

[0089] Furthermore, if both the first handshake end information and the second handshake end information are verified, the first session key is the same as the second session key; otherwise, the first session key is different from the second session key.

[0090] As can be seen from steps E-1.1 to E-1.4 above, by using the first session key to encrypt the first handshake end information through the security application component, and then using the second session key to decrypt the first handshake end information through the target device, the target device can verify whether the second session key and the first session key are the same; by using the second session key to encrypt the second handshake end information through the target device, and then using the first session key to decrypt the second handshake end information through the security application component, the security application component can verify whether the second session key and the first session key are the same, so as to ensure that data transmission can be performed using the first session key and the second session key in the future.

[0091] Optionally, the method further includes the following steps F-1 to F-6: Step F-1: The application layer component sends application data to the protocol stack component; The application data is used to request data from the target device; for example, the application data includes a Scalable Service-Oriented Middleware over IP (SOME / IP) request based on Internet Protocol; wherein, the SOME / IP request is a function call message initiated by the client to the server to trigger remote operation or obtain data.

[0092] Step F-2: The protocol stack component calls the security application component to encrypt the application data according to the first session key associated with the key handle, to obtain the first ciphertext information; In some embodiments, the protocol stack component may send the application data and the key handle to the security application component, so that the security application component encrypts the application data according to the first session key associated with the key handle to obtain first ciphertext information, and then returns the first ciphertext information to the protocol stack component.

[0093] It should be noted that the first session key used for data transmission between the communication device and the target device is stored in the Trusted Execution Environment. Therefore, the application data needs to be encrypted by calling the security application component in the Trusted Execution Environment before it is transmitted to the target device.

[0094] Step F-3: The protocol stack component sends the first ciphertext information to the target device, so that the target device decrypts the first ciphertext information according to the second session key, generates reply data according to the decrypted data, and encrypts the reply data according to the second session key to obtain the second ciphertext information; Step F-4: The protocol stack component receives the second ciphertext information from the target device; Step F-5: The protocol stack component calls the security application component to decrypt the second ciphertext information according to the first session key associated with the key handle, and obtains the reply data; The protocol stack component can send a key handle and second ciphertext information to the security application component, so that the security application component can use the first session key associated with the key handle to decrypt the second ciphertext information and obtain the reply data.

[0095] Step F-6: The protocol stack component sends the response data to the application layer component.

[0096] Wherein, the first session key is a key derived from the security application component for data transmission between the communication device and the target device, and the second session key is a key derived from the target device for data transmission between the communication device and the target device; therefore, if the first session key and the second session key are the same, data transmission between the communication device and the target device can proceed normally. Thus, in step F-3, the second session key can be used to decrypt the first ciphertext information; and in step F-5, the first session key can be used to decrypt the second ciphertext information.

[0097] Furthermore, if the application data contained in the first encrypted information is used to request data, then the reply data refers to the response data generated based on the application data.

[0098] As can be seen from steps F-1 to F-6 above, after deriving the first session key and the second session key, the first session key and the second session key can be used to realize secure data transmission between the communication device and the target device.

[0099] Optionally, the method further includes the following steps G-1 to G-5: Step G-1: The application layer component sends a connection closure request to the protocol stack component; Step G-2: The protocol stack component sends a session destruction request to the security application component; Step G-3: The security application component clears the stored first session key and the association between the first session key and the key handle; Step G-4: The security application component sends a session destruction confirmation to the protocol stack component; Step G-5: The protocol stack component sends a connection closure notification to the target device.

[0100] As can be seen from steps G-1 to G-5 above, when it is necessary to close the connection between the communication device and the target device, the application layer component can send a connection closure request to the protocol stack component, so that the protocol stack component sends a session destruction request to the security application component. In this way, the security application component can clear its stored first session key and the association between the first session key and the key handle. Thus, the key handle associated with the first session key will become invalid. Then, the security application component can notify the protocol stack component that the session has been destroyed, and the protocol stack component can notify the target device that the connection has been closed.

[0101] In this case, the connection closure request and session destruction request can both carry the session ID, so that the security application component can clearly delete the session key of which session and its association with the key handle.

[0102] In addition, in some embodiments, the first session key can be securely erased in step G-3 by first overwriting the memory area with all zeros or random numbers to ensure that no first session key remains.

[0103] It should be noted that cold start attacks can occur in certain scenarios, where attackers can read residual data in memory after the session ends, recover historical keys, and decrypt the captured communication content. However, in this embodiment, the key of the session can be destroyed after the session ends (i.e., after the data transmission between the communication device and the target device is completed), thereby preventing the aforementioned cold start attack.

[0104] In some embodiments, if the first shared key, the first master key, and the first key block described above are also stored in the trusted execution environment, the security application component will also clear the stored first shared key, the first master key, and the first key block after receiving the session destruction request.

[0105] To facilitate understanding of the communication method based on a trusted execution environment in the embodiments of this application, the specific implementation of the method is described below.

[0106] Using the communication device as an in-vehicle device, the system architecture applicable to the communication method based on a trusted execution environment in this application embodiment can be as follows: Figure 2 As shown in Table 1, the target device can be an ECU or a cloud server. In addition, the system on a chip (SoC) of the vehicle device is divided into two secure and isolated execution environments.

[0107] Table 1

[0108] The REE includes the following components: Application layer components: run OTA clients, remote diagnostic services, remote control services, advanced driver assistance systems (ADAS) and other in-vehicle safety applications, and are responsible for business logic processing; Protocol stack components: Based on the standard TLS protocol stack, it retains the protocol state machine and message encapsulation functions, but redirects cryptographic operations to the TEE. The protocol stack components include the OpenSSL component and the engine component. The OpenSSL component is used to implement the TLS protocol. The engine component is an Open Secure Sockets Layer (OpenSSL) ENGINE plugin, used to intercept cryptographic operations and redirect them to the TEE. In this way, through the engine component, the in-vehicle service middleware (such as the SOME / IP protocol stack) can trigger calls to the TEE without modification. In the case of using the TLS protocol, this engine component can also be called the TLS Trusted Application (TA) engine component. It should be noted that OpenSSL can be replaced by embedded transport layer security library (mbedTLS), wolf secure socket layer library (wolfSSL), etc., and connect to TEE through the corresponding callback mechanism; Client Library Component: The TEE client library running in REE is responsible for encapsulating the TEE call interface and communicating with the security application components in the TEE; when using the TLS protocol, this client library component can be called the TLS TA client library component. Network driver: Responsible for data transmission and reception on Ethernet or 4G / 5G networks.

[0109] In addition, the TEE includes the following components: Security application components: used for key management, encryption / decryption engines, certificate verification, handshake adjudication, signature services, etc.; when using the TLS protocol, security application components can also be called TLS security TA components. Secure Storage component: As a secure storage area for the TEE, it is used to store device private keys, session keys, root CA hashes, etc.

[0110] It should be noted that, in Figure 2In the diagram, dashed arrows indicate calls that cross the REE / TEE security boundary. This boundary is enforced by hardware (such as ARM TrustZone), preventing the REE from directly accessing TEE memory and ensuring the security of keys and sensitive operations.

[0111] It should be noted that, Figure 2 The architecture shown is applicable to any of the following scenarios: in-vehicle SOME / IP secure communication, OTA upgrades, remote diagnostics, remote control, and V2X communication. Specifically, in the in-vehicle SOME / IP secure communication scenario, the above protocol stack components may also include the vsomeip 3.x component; the vsomeip 3.x component is used to implement the AUTOSAR standard SOME / IP protocol stack. It can be understood that the vsomeip 3.x component is a component specific to the in-vehicle SOME / IP secure communication scenario, meaning it is an open-source implementation framework based on the SOME / IP protocol, specifically designed for in-vehicle communication, and belongs to the application-layer service-oriented communication middleware.

[0112] For example, in an in-vehicle SOME / IP secure communication scenario, the data flow can be described as follows: (1) Downlink call chain: Application layer component → vsomeip 3.x component → OpenSSL component → Engine component → Client library component → Security application component; (2) Password operation flow: When the OpenSSL component needs to perform encryption / signing operations, the engine component intercepts the request and sends it to the TEE through the client library component; (3) Network data flow: The OpenSSL component sends the encrypted data to the target device through the network driver.

[0113] The following is a detailed introduction. Figure 2 The specific process of the communication method based on the trusted execution environment under the illustrated architecture is as follows: I. Handshake establishment phase, such as Figure 3 As shown, the specific steps include steps 1 to 27 as follows: Step 1: The application layer component sends a connection request to the protocol stack component to request secure communication with the target device; wherein, when any application installed on the vehicle device needs to communicate securely with the target device, the application layer component can send the above connection request to the protocol stack component. Step 2: The protocol stack component sends a session initialization request to the security application component; Step 3: The security application component assigns a session ID and generates the client's first random number, client_random, and then returns the session ID and client_random to the protocol stack component. Assigning a session ID means creating a "file number" for this secure connection, and all subsequent operations are associated with this session ID. In addition, the first random number can be generated by a hardware random number generator, and the first random number can be, for example, a 32-byte random number. It's important to note that `client_random` directly participates in subsequent key derivation. If generated within the REE (Remote Elementary Environment), malware could manipulate the random number generator to make it predictable, thus making the key predictable and ultimately enabling decryption of communications. However, when generated within the TEE (Trusted Elementary Environment), the quality of `client_random` is guaranteed by hardware, and the REE cannot interfere. Step 4: The protocol stack component sends a ClientHello message to the target device. The ClientHello message carries a list of protocol versions supported by the protocol stack component, a list of cipher suites, and client_random. Step 5: The target device replies to the protocol stack component with a server greeting (ServerHello) message. The ServerHello message carries the protocol version selected by the target device in the version list, the cipher suite selected in the cipher suite list, and the second random number server_random generated by the target device. Step 6: The target device sends a certificate message to the protocol stack component. The certificate message carries the target device's certificate chain. For example, the target device's certificate chain is: [Target Device Certificate] → [Intermediate CA Certificate] → [Root CA Certificate]. This certificate chain is transmitted in plaintext. Step 7: The target device sends a ServerKeyExchange message to the protocol stack component. This message carries parameters for the cryptographic algorithms supported by the target device, such as the key exchange parameters for the Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) algorithm. These parameters may include a first public key and curve parameters. It should be noted that the first public key is the public key in a temporarily generated key pair on the target device, while the first private key in this key pair is stored on the target device. Furthermore, the ECDHE key exchange parameters are transmitted in plaintext. Step 8: The target device sends a Certificate Request message to the protocol stack component, that is, the target device requests the client to present a certificate to prove its identity; Step 9: The target device sends a ServerHelloDone message to the protocol stack component; the ServerHelloDone message indicates that the target device has completed sending the handshake message. It should be noted that the information carried in the handshake messages in steps 5 to 7 is all in plaintext and can be completely decided in one go; Step 10: The protocol stack component packages the received handshake information and sends it to the security application component in one go; wherein, the handshake information includes: the protocol version selected by the target device, the cipher suite selected by the target device, the certificate chain of the target device, and the parameters of the cryptographic algorithms supported by the target device; Step 11: The security application component performs a security ruling on the handshake information and returns the ruling result to the protocol stack component; it should be noted that the specific process of performing a security ruling on the handshake information here can be found in the previous text, and will not be repeated here; The ruling can include the following three types: Allow: This means that all items in the handshake message have passed the check and the handshake continues, i.e., proceed to step 12. Denied (DENY): This indicates a serious security issue, connection failed, proceed to step 14; WARN: There is a risk, but it is acceptable (e.g., the certificate is about to expire). Whether to proceed to step 12 or step 14 is up to the policy. Step 12: The protocol stack component sends the target device's first public key and server_random to the security application component; Step 13: The security application component uses the first public key and server_random to perform key derivation to obtain the first session key, and then returns the client's second public key and the key handle associated with the first session key to the protocol stack component; The key derivation process here is described in detail below: The security application component generates a pair of temporary ECDHE keys for the client: {second private key, second public key}; wherein, the second private key is kept in the TEE and is never output; The security application component uses the second private key and the first public key to perform an elliptic curve Diffie-Hellman (ECDH) operation to obtain the first shared key premaster_secret_1; where premaster_secret_1 is stored in the TEE; The security application component calculates the first master key master_secret_1 according to the formula master_secret_1=PRF(premaster_secret_1,"mastersecret",client_random+server_random); where PRF represents a pseudo-random function and "master_secret" represents a fixed string. The security application component calculates the first key block key_block_1 according to the formula key_block_1=PRF(master_secret_1,"key expansion",server_random+client_random), and then extracts the first session key from key_block_1; "key expansion" represents a fixed string; The first session key includes: client_write_key (16 bytes) used for encryption by the security application component or decryption by the target device, server_write_key (16 bytes) used for encryption by the target device or decryption by the security application component, client_write_IV (4 bytes) and target device initialization vector server_write_IV (4 bytes). It should be noted that the aforementioned first session key, first shared key, first master key, and first key block can be stored in a secure storage component; Step 14: The protocol stack component sends a connection failure indication message to the application layer component; Step 15: The protocol stack component sends a Certificate message to the target device, which carries the client certificate; Once the target device receives the client certificate, it can verify the authenticity of the client certificate, that is, verify the certificate chain of the client certificate level by level from the bottom up. It should be noted that a specific example of verifying the authenticity of the client can be found in the previous text, and will not be repeated here. Step 16: The protocol stack component sends a ClientKeyExchange message to the target device, which carries the second public key; After receiving the second public key, the target device can perform key derivation to obtain the second session key; the specific process of the target device performing key derivation is as follows: The target device uses the second public key and the first private key to perform an elliptic curve Diffie-Hellman (ECDH) operation to obtain the second shared key premaster_secret_2; The target device calculates the second master key master_secret_2 according to the formula master_secret_2=PRF(premaster_secret_2,"mastersecret",client_random+server_random); where PRF represents a pseudo-random function and "master_secret" represents a fixed string. The target device calculates the second key block key_block_2 according to the formula key_block_2=PRF(master_secret_2,"key expansion",server_random+client_random), and then intercepts the second session key from key_block_2; The second session key includes: client_write_key (16 bytes) used for encryption by the security application component or decryption by the target device, server_write_key (16 bytes) used for encryption by the target device or decryption by the security application component, client_write_IV (4 bytes) and target device initialization vector server_write_IV (4 bytes). It should be noted that the first shared key and the second shared key mentioned above are the same, the first master key and the second master key are the same, the first key block and the second key block are the same, and the first session key and the second session key are the same. Step 17: The protocol stack component calculates the hash value of the handshake message and sends the hash value of the handshake message to the security application component, wherein the handshake message includes the messages from steps 4 to 9 and steps 15 to 16 described above. Step 18: The security application component uses the second private key to sign the hash value of the handshake message, obtains a digital signature, and returns the digital signature to the protocol stack component; Step 19: The protocol stack component sends a CertificateVerify message to the target device, which carries the digital signature; After receiving the digital signature, the target device can use the second public key in the client certificate received in step 15 to verify the digital signature; if the digital signature passes the verification, it means that the client has the second private key claimed in the client certificate. Step 20: The protocol stack component sends a ChangeCipherSpec message to the target device to notify the target device that all subsequent messages it sends will use the negotiated session key (i.e., the first session key). Step 21: The protocol stack component sends the client tag information (client finished) and key handle to the security application component; Step 22: The security application component calculates the first verification data verify_data_1 according to the formula verify_data_1=PRF(master_secret_1,"clientfinished", Hash(all handshake messages)), and encrypts verify_data_1 using the client_write_key associated with the key handle to obtain the first handshake end information, and returns the first handshake end information to the protocol stack component; where Hash(all handshake messages) represents the hash value of the handshake messages between the protocol stack component and the target device; Step 23: The protocol stack component sends the first handshake end information to the target device; After receiving the first handshake end information, the target device decrypts the first handshake end information using client_write_key to obtain the second verification data verify_data_2; according to the formula verify_data_3=PRF(master_secret_2,"client finished",Hash(all handshake messages)), the third verification data verify_data_3 is calculated; verify_data_2 and verify_data_3 are compared to see if they are consistent. If they are consistent, the first handshake end information passes verification; otherwise, the first handshake end information fails verification. Understandably, if the first handshake end information is verified, the subsequent step 24 is executed; if the first handshake end information is not verified, the target device can send an indication that the first handshake end information has not been verified to the protocol stack component, so that the protocol stack component can send a connection failure indication to the application layer component.

[0114] Step 24: The target device sends a ChangeCipherSpec message to the protocol stack component to notify the protocol stack component (client) that all subsequent messages it sends will use the negotiated session key (i.e., the second session key). Step 25: The target device calculates the fourth verification data verify_data_4 according to the formula verify_data_4=PRF(master_secret_2,"serverfinished", Hash(all handshake messages)), encrypts verify_data_4 using server_write_key, obtains the second handshake end information, and returns the second handshake end information to the protocol stack component; where server finished represents the tag information of the target device; Step 26: The protocol stack component sends the second handshake end information and key handle to the security application component; Step 27: The security application component uses the server_write_key associated with the key handle to decrypt the second handshake end information to obtain the fifth verification data verify_data_5; according to the formula verify_data_6=PRF(master_secret_1,"server finished",Hash(all handshake messages)), it calculates the sixth verification data verify_data_6; it compares verify_data_5 and verify_data_6 to obtain the verification result, and returns the verification result to the protocol stack component. If verify_data_5 and verify_data_6 are consistent, the second handshake end information passes verification; otherwise, the second handshake end information fails verification. If the second handshake end information passes verification, an encrypted channel is established between the vehicle-mounted device and the target device; if the second handshake end information fails verification, the protocol stack component can send a connection failure indication to the application layer component. At this point, the handshake phase is complete.

[0115] In addition, once the encrypted channel is successfully established between the vehicle-mounted device and the target device, the subsequent secure data transmission phase can begin.

[0116] II. Secure data transmission phase, such as Figure 4 As shown, the specific steps include steps 28 to 35 as follows: Step 28: The application layer component sends application data to the protocol stack component; for example, the application data includes a SOME / IP request; Step 29: The protocol stack component sends the application data and key handle to the security application component; Step 30: The security application component uses the client_write_key associated with the key handle and encrypts the application data using the Authenticated Encryption with Associated Data (AEAD) algorithm, thereby returning the first ciphertext information (i.e., ciphertext + authentication tag (ensuring ciphertext integrity and authenticity)) to the protocol stack component: Step 31: The protocol stack component encapsulates the first ciphertext information into a TLS Record format and sends it to the target device; Step 32: The target device uses client_write_key to decrypt the ciphertext in the first ciphertext information and verifies the authentication tag. If the authentication is successful, it generates reply data based on the decrypted application data, and then encrypts the reply data using server_write_key to obtain the second ciphertext information (i.e., ciphertext + authentication tag), and returns the second ciphertext information to the protocol stack component. Step 33: The protocol stack component sends the second ciphertext information and key handle to the security application component; Step 34: The security application component uses the server_write_key associated with the key handle to decrypt the ciphertext in the second ciphertext information and verify the authentication tag. If the authentication is successful, it returns the decrypted response data to the protocol stack component. Step 35: The protocol stack component sends reply data to the application layer component.

[0117] It should be noted that during the above process, the protocol stack component calls the security application component every time it sends or receives data to ensure that the session key is never exposed to the REE. Even if the REE is compromised, the attacker can only obtain the key handle and cannot encrypt or decrypt it on their own.

[0118] III. Session security destruction phase, such as Figure 5 The above includes the following steps 36-39: Step 36: The application layer component sends a connection closure request to the protocol stack component; Step 37: The protocol stack component sends a session destruction request to the security application component; Among them, after receiving the session destruction request, the security application component securely erases the stored first session key, the association between the first session key and the key handle, the first master key, the first shared key, and the first key block; Step 38: The security application component sends a session destruction confirmation to the protocol stack component; Step 39: The protocol stack component sends a connection closure notification to the target device.

[0119] It should be noted that erasing the relevant information of the aforementioned keys during the session destruction phase can prevent attackers from recovering historical keys by reading residual data in memory after the session ends, thereby preventing them from decrypting the captured communication content.

[0120] It should be noted that all the messages sent by the protocol stack component to the security application component can be implemented through the client library component. That is, the client library component can forward messages between the protocol stack component and the security application component. To more clearly illustrate the interaction flow between the protocol stack component, the security application component, and the target device, Figures 3-5 The client library components are not shown in either document.

[0121] also, Figures 3-5 Each step only briefly illustrates the important messages or information related to that step.

[0122] It should also be noted that the order of the steps in the communication method based on the Trusted Execution Environment (TEE) described in this article can be adjusted according to the actual application scenario, and the methods described in the text can be adjusted accordingly. For example, in TLS 1.2: Certificate and ServerKeyExchange are in plaintext → TEE can see all the information at once before key derivation; in TLS 1.3: Certificate is encrypted → TEE needs to derive the key before it can obtain the certificate.

[0123] Furthermore, existing automotive TLS implementations suffer from significant drawbacks in terms of security, cost, and performance. These are detailed below: 1. For pure software TLS solutions: In traditional solutions, the TLS protocol stack runs entirely within a general-purpose operating system (such as Linux / Android), which presents the following security risks: (1) Risk of session key exposure: In traditional schemes, TLS session keys are generated, stored and used in the memory of ordinary operating systems. Attackers can obtain the plaintext of the key through memory dumps, debugging interfaces or system vulnerabilities. Once the key is leaked, all historical and future communication data can be decrypted.

[0124] (2) The handshake process can be tampered with: that is, the security decisions of the TLS handshake (certificate verification, parameter negotiation) are completely controlled by the ordinary operating system. Attackers can tamper with the handshake logic, carry out downgrade attacks or bypass certificate verification, and connect to malicious servers.

[0125] (3) Device identity private key is easy to clone: ​​In the mTLS two-way authentication scenario, the identity private key of the vehicle or ECU is usually stored in the ordinary file system. Attackers can copy the private key to clone the vehicle identity and impersonate a legitimate vehicle to access the cloud.

[0126] 2. For traditional hardware security module (HSM) solutions: Traditional solutions rely on HSM chips to provide key protection capabilities, but have the following limitations: (1) High hardware cost: that is, an additional independent HSM chip needs to be purchased; (2) Occupies printed circuit board (PCB) space: that is, additional chip placement space is required; (3) Large communication delay: It is necessary to communicate through buses such as Serial Peripheral Interface (SPI) / Inter-Integrated Circuit (I2C); (4) High integration complexity: that is, it requires dedicated drivers and interface adaptation.

[0127] 3. For the Public-Key Cryptography Standards #11 (PKCS #11) interface: Some in-vehicle platforms offer trusted applications compliant with the PKCS#11 standard, but this standard interface has the following fundamental limitations, making it unsuitable for TLS security enhancement scenarios: (1) Mismatch in design positioning: PKCS#11 is a general cryptographic hardware abstraction interface, designed to provide atomic cryptographic operations (such as signing, encryption, and decryption), rather than being optimized for the TLS protocol; that is, in the existing technology, the PKCS#11 interface must be called once for each atomic cryptographic operation, so implementing TLS using PKCS#11 requires a large number of interface call combinations.

[0128] (2) Security decision-making power remains in the normal execution environment: that is, PKCS#11 trusted applications only passively perform cryptographic operations and cannot actively verify the security of TLS handshake information. Security decisions such as TLS version selection, cipher suite negotiation, and certificate verification are still controlled by the normal operating system, and attackers can tamper with these decision-making logics.

[0129] (3) Lack of TLS-specific security features: That is, the PKCS#11 standard does not include the features required for the following TLS security enhancements: TLS handshake information security adjudication mechanism; Root CA certificate hash whitelist verification; Full lifecycle protection of TLS session keys; Optimize the batch encryption / decryption interface.

[0130] In summary, the security risks shown in Table 3 exist in all the application scenarios shown in Table 2: Table 2

[0131] Table 3

[0132] The communication method based on a trusted execution environment described in the embodiments of this application can achieve the following breakthroughs: (1) Transfer of security decision-making power: This means transferring the security decision-making power of TLS communication from the ordinary execution environment to the trusted execution environment. The trusted execution environment has the ability to actively reject insecure connections, rather than passively performing cryptographic operations.

[0133] (2) TLS-specific trusted application design: that is, designing trusted applications optimized for the TLS protocol, providing a composite command interface, which can complete key exchange and derivation, handshake information verification and adjudication, etc. with a single call, greatly reducing the overhead of switching execution environments.

[0134] (3) Session key lifecycle isolation: The entire process of session key generation, derivation, use and destruction is completed within a trusted execution environment. Ordinary execution environments only hold the key handle and cannot obtain the plaintext of the key.

[0135] (4) The root CA hash whitelist mechanism is adopted: that is, the hash value of the trusted root CA certificate is stored in the trusted execution environment instead of the complete certificate, which saves storage space and realizes hardware-level protection of the root CA trust anchor point.

[0136] (5) Transparent integration of vehicle middleware: that is, through the standard encryption engine interface (i.e. the engine component mentioned above), the vehicle service middleware (such as the SOME / IP protocol stack) can use the communication method based on the trusted execution environment provided in the embodiments of this application without modification.

[0137] In summary, the key differences between the communication method based on a trusted execution environment in this application and the prior art can be described as follows: 1. Security adjudication mechanism led by TEE: "Security adjudication first, key derivation later"; as shown in Table 4: Table 4

[0138] 2. Root CA hash whitelist mechanism: This mechanism uses the hash value of the root CA certificate instead of the full certificate for storage, achieving efficient and secure trust anchor verification; details are shown in Table 5. Table 5

[0139] 3. TLS semantic-level compound commands, that is, elevating the TEE interface from the "cryptographic primitive level" to the "TLS protocol semantic level", allowing multiple operations to be completed in a single call; as shown in Table 6: Table 6

[0140] It should be noted that the 7 calls to TEE (i.e., 7 calls to the security application component) in this application refer to the following steps: Step 2 (allocating session ID and first random number), Step 10 (performing security adjudication), Step 12 (deriving key), Step 17 (generating digital signature), Step 21 (encrypting to obtain first handshake end information), Step 26 (decrypting second handshake end information), and Step 37 (securely destroying session).

[0141] In summary, the communication method based on the trusted execution environment in this application is compared with traditional solutions as shown in Table 7.

[0142] Table 7

[0143] As can be seen, the communication method based on the trusted execution environment in this application embodiment can achieve the beneficial effects shown in Table 8 and meet the compliance requirements shown in Table 9.

[0144] Table 8

[0145] Table 9

[0146] Among them, ISO / SAE 21434: represents the engineering standard for road vehicle cybersecurity; UN R155: Represents the United Nations regulations on vehicle cybersecurity; GDPR stands for General Data Protection Regulation.

[0147] It should also be noted that the communication method based on a trusted execution environment in this application is not only applicable to the automotive field, but can also be widely applied to other embedded systems and IoT scenarios that require secure communication.

[0148] Secondly, the application embodiments also provide a communication device, such as... Figure 6 As shown, the communication device 600 runs a main execution environment and a trusted execution environment, which are physically isolated from the main execution environment at the hardware layer; the main execution environment is equipped with an application layer component 601 and a protocol stack component 602, and the trusted execution environment is equipped with a security application component 603. The application layer component 601 is used to: send a connection request to the protocol stack component, wherein the connection request is used to request to establish a connection with the target device; The protocol stack component 602 is used to: obtain the handshake information of the target device and send the handshake information to the security application component 603; The security application component 603 is used to: perform security adjudication on the handshake information, obtain an adjudication result, and send the adjudication result to the protocol stack component.

[0149] Optionally, the main execution environment also includes a client library component; the protocol stack component 602 calls the security application component 603 through the client library component.

[0150] Optionally, the protocol stack component 602 is further configured to: if the arbitration result indicates that the handshake information has passed the security arbitration, call the security application component 603 to perform key derivation to obtain a first session key; and / or, if the arbitration result indicates that the handshake information has not passed the security arbitration, the protocol stack component 602 sends a connection failure indication message to the application layer component 601; wherein the first session key is used to: encrypt data or information sent by the communication device to the target device, and decrypt data or information from the target device.

[0151] Optionally, before the protocol stack component 602 calls the security application component 603 to perform key derivation, the protocol stack component 602 is further configured to: Upon receiving the connection request, the security application component 603 is invoked to generate a first random number for the client; Obtain the second random number of the target device and the first public key of the target device; The protocol stack component 602 calls the security application component 603 to perform key derivation to obtain the first session key, including: The protocol stack component 602 sends the second random number and the first public key to the security application component 603, so that the security application component 603 generates the client's second public key and second private key, stores the second public key and the second private key, generates a first shared key based on the second private key and the first public key, generates a first master key based on the first shared key, the second random number and the first random number, derives a first session key based on the first master key, and stores the first session key; wherein, the second public key and the second private key constitute a key pair; The protocol stack component 602 receives the key handle associated with the first session key from the security application component 603.

[0152] Optionally, the trusted execution environment is further provided with a secure storage component; the first shared key, the first master key, and the first session key are stored in the secure storage component.

[0153] Optionally, after the security application component 603 generates the first random number: the security application component 603 is further configured to: send the first random number to the protocol stack component; the protocol stack component 602 is further configured to: send the first random number to the target device; After the security application component 603 generates the client's second public key and second private key: the security application component 603 is further configured to: send the second public key to the protocol stack component; the protocol stack component 602 is further configured to send the second public key to the target device, so that the target device generates a second shared key based on the second public key and the target device's first private key, generates a second master key based on the second shared key, the second random number and the first random number, and derives a second session key based on the second master key; The second session key is used to: encrypt data or information sent by the target device to the communication device, and to decrypt data or information from the communication device.

[0154] Optionally, the protocol stack component 602 is further configured to: Send the client certificate to the target device; The security application component 603 is invoked to generate a digital signature based on the client's second private key; The digital signature is sent to the target device so that the target device can verify the digital signature based on the client's second public key in the client certificate.

[0155] Optionally, the protocol stack component 602 calls the security application component 603 to generate a digital signature based on the client's second private key, including: The protocol stack component 602 calculates the hash value of the handshake message, wherein the handshake message includes the handshake message between the protocol stack component and the target device; The protocol stack component 602 sends the hash value to the security application component 603, so that the security application component 603 signs the hash value according to the second private key to obtain the digital signature; The protocol stack component 602 receives the digital signature from the security application component 603.

[0156] Optionally, the protocol stack component 602 is further configured to: call the security application component 603 to verify whether the first session key and the second session key are the same; The protocol stack component 602 is further configured to: send a connection success indication to the application layer component 601 when the first session key is the same as the second session key; and / or, send a connection failure indication to the application layer component 601 when the first session key is different from the second session key.

[0157] Optionally, the protocol stack component 602 calls the security application component 603 to verify whether the first session key and the second session key are the same, including: The protocol stack component 602 calls the security application component 603 to generate first handshake end information based on the first session key associated with the key handle; The protocol stack component 602 sends the first handshake end information to the target device, so that the target device can verify the first handshake end information according to the second session key; The protocol stack component 602 receives second handshake end information from the target device, wherein the second handshake end information is generated based on the second session key; The protocol stack component 602 calls the security application component 603 to verify the second handshake end information based on the first session key associated with the key handle; Specifically, if both the first handshake end information and the second handshake end information are verified, the first session key is the same as the second session key; otherwise, the first session key is different from the second session key.

[0158] Optionally, the application layer component 601 is further configured to: send application data to the protocol stack component 602; The protocol stack component 602 is also used for: The security application component 603 is invoked to encrypt the application data according to the first session key associated with the key handle, thereby obtaining the first ciphertext information; The first ciphertext information is sent to the target device so that the target device decrypts the first ciphertext information according to the second session key, generates reply data according to the decrypted data, and encrypts the reply data according to the second session key to obtain the second ciphertext information. Receive the second encrypted information from the target device; The security application component 603 is invoked to decrypt the second ciphertext information based on the first session key associated with the key handle, thereby obtaining the reply data; The response data is sent to the application layer component 601.

[0159] Optionally, the application layer component 601 is further configured to: send a connection closure request to the protocol stack component 602; The protocol stack component 602 is also used to: send a session destruction request to the security application component 603; The security application component 603 is further configured to: clear the stored first session key and the association between the first session key and the key handle; and send a session destruction confirmation to the protocol stack component 602. The protocol stack component 602 is also used to send a connection closure notification to the target device.

[0160] Optionally, if the handshake information includes the certificate chain of the target device, and the certificate chain includes a root certification authority (CA) certificate, the security application component 603 performs a security ruling on the handshake information, including: the security application component 603 calculates the hash value of the root CA certificate of the target device; if the hash value of the root CA certificate of the target device is included in a pre-stored hash value list, the security application component 603 determines that the root CA certificate of the target device passes the security ruling.

[0161] It should be noted that the division of modules or components in the embodiments of this application is illustrative and only represents a logical functional division. In actual implementation, there may be other division methods. Furthermore, the functional modules or components in the various embodiments of this application can be integrated into one module or component, or each module or component can exist physically separately, or two or more modules or components can be integrated into one module or component. The integrated modules or components described above can be implemented in hardware or as software functional modules.

[0162] If the integrated module or component is implemented as a software functional module and sold or used as an independent product, it can be stored in a processor-readable storage medium. Based on this understanding, the technical solution of this application, 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 several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0163] It should be noted that the communication device provided in the application embodiment can implement all the method steps implemented in the above method embodiment and can achieve the same technical effect. Therefore, the parts that are the same as those in the method embodiment and the beneficial effects will not be described in detail here.

[0164] Embodiments of the present invention also provide an electronic device, such as... Figure 7 As shown, the electronic device includes a memory 720, a transceiver 710, and a processor 700; Memory 720 is used to store computer programs; Transceiver 710 is used to receive and send data under the control of processor 700; The processor 700 is used to read the computer program in the memory 720 and execute the communication method based on the trusted execution environment described in the first aspect above.

[0165] Among them, Figure 7 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits together, represented by one or more processors (processor 700) and memory (memory 720). The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface. The transceiver 710 can be multiple elements, including transmitters and receivers, providing a unit for communicating with various other devices over transmission media, including wireless channels, wired channels, optical fibers, etc. The processor 700 is responsible for managing the bus architecture and general processing, and the memory 720 can store data used by the processor 700 during operation.

[0166] The processor 700 can be a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a complex programmable logic device (CPLD). The processor 700 can also adopt a multi-core architecture.

[0167] Embodiments of the present invention also provide a processor-readable storage medium storing a computer program for causing the processor to execute the communication method based on a trusted execution environment described above.

[0168] The processor-readable storage medium can be any available medium or data storage device that the processor can access, including but not limited to magnetic memory (e.g., floppy disk, hard disk, magnetic tape, magneto-optical disk (MO)), optical memory (e.g., CD, DVD, BD, HVD), and semiconductor memory (e.g., ROM, EPROM, EEPROM, non-volatile memory (NAND FLASH), solid-state drive (SSD)).

[0169] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0170] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-executable instructions. These computer-executable instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0171] These processor-executable instructions may also be stored in a processor-readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the processor-readable memory produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0172] These processors can execute instructions that can also be loaded onto a computer or other programmable data processing device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0173] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A communication method based on a trusted execution environment, characterized by, It is applied to communication equipment, on which a main execution environment and a trusted execution environment run, and the trusted execution environment and the main execution environment are physically isolated at the hardware layer; The main execution environment includes application layer components and protocol stack components, and the trusted execution environment includes security application components; the method includes: The application layer component sends a connection request to the protocol stack component, wherein the connection request is used to request the establishment of a connection with the target device; The protocol stack component obtains the handshake information of the target device; The protocol stack component sends the handshake information to the security application component; The security application component performs a security ruling on the handshake information and obtains the ruling result. The security application component sends the ruling result to the protocol stack component.

2. The method of claim 1, wherein, The method further includes: If the arbitration result indicates that the handshake information has passed the security arbitration, the protocol stack component calls the security application component to perform key derivation to obtain the first session key; and / or, If the arbitration result indicates that the handshake information has failed the security arbitration, the protocol stack component sends a connection failure indication message to the application layer component; The first session key is used to: encrypt data or information sent by the communication device to the target device, and decrypt data or information from the target device.

3. The method of claim 2, wherein, Before the protocol stack component calls the security application component to perform key derivation, the method further includes: After receiving the connection request, the protocol stack component calls the security application component to generate the first random number for the client; The protocol stack component obtains the second random number of the target device and the first public key of the target device; The protocol stack component calls the security application component to perform key derivation and obtain the first session key, including: The protocol stack component sends the second random number and the first public key to the security application component; The security application component generates a second public key and a second private key for the client, and stores the second public key and the second private key; wherein the second public key and the second private key constitute a key pair; The security application component generates a first shared key based on the second private key and the first public key, generates a first master key based on the first shared key, the second random number and the first random number, derives a first session key based on the first master key, and stores the first session key; The security application component sends the key handle associated with the first session key to the protocol stack component.

4. The method of claim 3, wherein, After the security application component generates the first random number, the method further includes: The security application component sends the first random number to the protocol stack component; The protocol stack component sends the first random number to the target device; After the security application component generates the client's second public key and second private key, the method further includes: The security application component sends the second public key to the protocol stack component; The protocol stack component sends the second public key to the target device, so that the target device generates a second shared key based on the second public key and the first private key of the target device, generates a second master key based on the second shared key, the second random number and the first random number, and derives a second session key based on the second master key; The second session key is used to: encrypt data or information sent by the target device to the communication device, and decrypt data or information from the communication device.

5. The method according to any one of claims 3 to 4, characterized in that, The method further includes: The protocol stack component sends the client certificate to the target device; The protocol stack component calls the security application component to generate a digital signature based on the second private key; The protocol stack component sends the digital signature to the target device, so that the target device verifies the digital signature based on the second public key in the client certificate.

6. The method of claim 5, wherein, The protocol stack component calls the security application component to generate a digital signature based on the client's second private key, including: The protocol stack component calculates the hash value of the handshake message, wherein the handshake message includes the handshake message between the protocol stack component and the target device; The protocol stack component sends the hash value to the security application component; The security application component signs the hash value using the second private key to obtain the digital signature, and then sends the digital signature to the protocol stack component.

7. The method of claim 4, wherein, The method further includes: The protocol stack component calls the security application component to verify whether the first session key and the second session key are the same; If the first session key and the second session key are the same, the protocol stack component sends a connection success indication message to the application layer component; and / or, If the first session key is different from the second session key, the protocol stack component sends a connection failure indication message to the application layer component.

8. The method of claim 7, wherein, The protocol stack component calls the security application component to verify whether the first session key and the second session key are the same, including: The protocol stack component calls the security application component to generate first handshake end information based on the first session key associated with the key handle; The protocol stack component sends the first handshake end information to the target device, so that the target device can verify the first handshake end information according to the second session key; The protocol stack component receives second handshake end information from the target device, wherein the second handshake end information is generated based on the second session key; The protocol stack component calls the security application component to verify the second handshake end information based on the first session key associated with the key handle; Specifically, if both the first handshake end information and the second handshake end information are verified, the first session key is the same as the second session key; otherwise, the first session key is different from the second session key.

9. The method of claim 4, 7 or 8, wherein, The method further includes: The application layer component sends application data to the protocol stack component; The protocol stack component calls the security application component to encrypt the application data according to the first session key associated with the key handle, and obtains the first ciphertext information; The protocol stack component sends the first ciphertext information to the target device, so that the target device decrypts the first ciphertext information according to the second session key, generates reply data according to the decrypted data, and encrypts the reply data according to the second session key to obtain the second ciphertext information; The protocol stack component receives the second encrypted information from the target device; The protocol stack component calls the security application component to decrypt the second ciphertext information based on the first session key associated with the key handle, and obtains the reply data; The protocol stack component sends the response data to the application layer component.

10. The method of claim 4, 7 or 8, wherein, The method further includes: The application layer component sends a connection closure request to the protocol stack component; The protocol stack component sends a session destruction request to the security application component; The security application component clears the stored first session key and the association between the first session key and the key handle; The security application component sends a session destruction confirmation to the protocol stack component; The protocol stack component sends a connection closure notification to the target device.

11. The method according to any one of claims 1 to 4, characterized in that, When the handshake information includes the target device's certificate chain, and the certificate chain includes a root certification authority (CA) certificate, the security application component performs a security ruling on the handshake information, including: The security application component calculates the hash value of the root CA certificate of the target device; If the target device's root CA certificate hash is included in a pre-stored list of hash values, the security application component determines that the target device's root CA certificate has passed a security ruling.

12. A communication device, characterized in that, The communication device runs a main execution environment and a trusted execution environment, which are physically isolated from the main execution environment at the hardware layer. The main execution environment is equipped with application layer components and protocol stack components, while the trusted execution environment is equipped with security application components. The application layer component is used to: send a connection request to the protocol stack component, wherein the connection request is used to request to establish a connection with the target device; The protocol stack component is used to: obtain the handshake information of the target device and send the handshake information to the security application component; The security application component is used to: perform security adjudication on the handshake information, obtain the adjudication result, and send the adjudication result to the protocol stack component.

Images