A middleware communication encryption method

Abstract

This invention relates to a middleware communication encryption method. The client starts, reads relevant data from a configuration file, and performs signature verification on the configuration file. The server reads the certificate and application private key path from the configuration file, configures the configuration file signature data, and performs signature verification on the configuration file. Encrypted session parameters are generated for the service instance, storing the encryption level and encryption algorithm. When the application requests the service instance, the middleware client constructs an encrypted session connection request and an authentication request message. The middleware server begins listening for encrypted session connection requests from middleware clients. The client sends the constructed encrypted session connection request to the server. Upon receiving the encrypted session connection request from the middleware client, the server performs integrity verification. Asymmetric encryption technology is used to extract the public key from the requester's digital certificate to encrypt the symmetric key, constructing a response message. This provides service instance-level encryption, achieving an optimal trade-off between security and performance.

Description

Technical Field

[0001] This invention belongs to the field of middleware communication encryption technology, and particularly relates to a middleware communication encryption method. Background Technology

[0002] In the automotive industry, middleware communication frameworks based on Ethernet communication protection are rare. Although there are mature communication encryption technologies in the IT field, directly porting these solutions to automotive communication presents technical challenges in terms of performance or functionality, failing to meet the needs of automotive business scenarios. Widely used encryption technologies in the IT field include IPSec and TLS. IPSec suffers from limited granularity because it is imperceptible to applications; TLS does not support multicast communication, while multicast can improve communication efficiency in some middleware such as SOME / IP, and TLS requires a fairly complex authentication handshake process. Currently, the commonly used encryption frameworks in the IT field are IPSec and TLS. IPSec can achieve data confidentiality, data integrity, data authentication, and anti-replay functions; however, IPSec operates on top of low-level protocols and cannot provide applications with service-level encryption granularity.

[0003] Therefore, how to solve the problem that existing communication encryption technologies may not meet the performance or functional requirements of automotive business scenarios when directly transplanted to automotive communication, and how to improve the security of the communication process and achieve the best balance between security and performance, is a technical problem that urgently needs to be solved. Summary of the Invention

[0004] The purpose of this invention is to provide a middleware communication encryption method to solve the problem that existing communication encryption technologies, when directly applied to automotive communication, do not meet the performance or functional requirements of automotive business scenarios, thereby improving the security of the communication process and achieving the best balance between security and performance.

[0005] To solve the above-mentioned technical problems, the present invention adopts the following technical solution:

[0006] A middleware communication encryption method includes the following steps:

[0007] S1: The middleware client starts, reads the certificate, application private key path and configuration file signature data from the configuration file, performs signature verification on the configuration file, and loads the certificate and application private key after the signature verification is successful.

[0008] The middleware server starts, reads the certificate and application private key paths from the configuration file, configures the configuration file signing data, performs signature verification on the configuration file, and loads the certificate and application private key after the signature verification is successful.

[0009] S2: The application requests a service instance, obtains the configuration information of the service instance from the service rule matrix in the application certificate, the application provides the service instance, obtains the configuration information of the service instance from the service rule matrix in the certificate, generates encrypted session parameters for the service instance, stores the encryption level and encryption algorithm, and generates a random symmetric key for encrypting business messages of the service instance.

[0010] S3: The middleware client constructs an encrypted session connection request, generates a new random number N, associates each request with the corresponding response, and constructs an authentication request message. The middleware server starts listening for encrypted session connection requests from the middleware client.

[0011] S4: The middleware client sends the constructed encrypted session connection request to the middleware server and waits to receive the connection response. After receiving the encrypted session connection request from the middleware client, the middleware server performs an integrity check and determines whether the integrity check passes. If it does, proceed to step S5; otherwise, the session handshake will terminate immediately and refuse to provide services.

[0012] S5: Use asymmetric encryption technology to extract the public key from the requester's digital certificate to encrypt the symmetric key, construct a response message, digitally sign the response message using the provider's private key, and send the response message back to the middleware client.

[0013] S6: The middleware client verifies the validity of the session connection response message. If the verification is successful, it extracts the symmetric encryption key and algorithm of the service instance. Subsequent business communication messages with the middleware server will be encrypted using the symmetric key.

[0014] Preferably, the certificate read from the configuration file in step S1 includes the root certificate and the application certificate. The certificate loaded after the signature verification is passed also includes the root certificate and the application certificate. The signature data includes the signature algorithm, the signature certificate, and the configuration file signature value.

[0015] Preferably, the configuration information in step S2 includes roles and encryption levels, wherein roles include three types: requester, provider, and requester / provider, and encryption levels include three levels: NoSec, Authentication, and Confidentiality.

[0016] Preferably, the three encryption levels provided in step S2, including NoSec, Authentication, and Confidentiality, are progressively increasing levels. NoSec does not encrypt the message and is fully compatible with the original SOME / IP message; Authentication provides data authentication and integrity, detecting whether the message has been modified while flowing through the network. In addition, the Authentication security level also provides replay protection, that is, it identifies and discards duplicate data packets to prevent attackers from capturing valid messages, retransmitting them, and triggering the same operation multiple times; Confidentiality provides authentication, authorization, integrity, and confidentiality, as well as replay protection, including all the security attributes introduced by the authentication level, supplemented by encryption, to prevent potential attackers from stealing the content of messages transmitted over the network, that is, to provide data confidentiality.

[0017] Preferably, the response message in step S5 includes a random number copied from the request, the provider's certificate, a symmetric encryption key, the security level selected by the provider, and an identifier uniquely assigned to each requester.

[0018] Preferably, the response message includes the following information: version number, asymmetric encryption algorithm type, message digest algorithm type, padding field, random number, fingerprint of the digital certificate applied by the middleware server, security level of the session, symmetric encryption algorithm type of the session, unique identifier assigned to each requester, length and key value of the encrypted symmetric key, signature length and signature value of the response message, wherein the version number is 1 byte long, the asymmetric encryption algorithm type is 1 byte long, the message digest algorithm type is 1 byte long, the padding field is 1 byte long with an additional 4 bytes for padding, the random number is 32 bytes long, the fingerprint of the digital certificate applied by the middleware server is 32 bytes long, the security level of the session is 1 byte long, the symmetric encryption algorithm type of the session is 1 byte long, and the unique identifier assigned to each requester is 2 bytes long.

[0019] Preferably, concurrently with step S3, a security session for the service instance is first established. The specific process for establishing a security session for the service instance is as follows:

[0020] Perform mutual authentication between the middleware client and the middleware server: determine the role associated with the application, which is either a provider or a requester. The provider digitally signs its handshake response with its private key, and the requester verifies the signature to verify whether the current security level of the service instance is acceptable.

[0021] Handshake: The provider and requester share session parameters, including the symmetric key, symmetric algorithm, and pairing ID transmitted in encrypted form. After the handshake, the service instance's message communication uses the symmetric key from the parameters exchanged during the handshake to encrypt messages.

[0022] The beneficial effects of this invention include:

[0023] The middleware communication encryption method provided by this invention involves the following steps: The client starts by reading relevant data from a configuration file and performing signature verification on the configuration file. The server starts by reading the certificate and application private key path from the configuration file, configuring the configuration file signature data, and performing signature verification on the configuration file. The application requests a service instance, provides the service instance, generates encrypted session parameters for the service instance, and stores the encryption level and encryption algorithm. The middleware client constructs an encrypted session connection request and an authentication request message. The middleware server begins listening for encrypted session connection requests from the middleware client. The client sends the constructed encrypted session connection request to the server. Upon receiving the encrypted session connection request from the middleware client, the server performs integrity verification. Asymmetric encryption technology is used to extract the public key from the requester's digital certificate to encrypt the symmetric key, and a response message is constructed.

[0024] First, by retrieving the configuration information of the service instance from the service rule matrix in the certificate, encrypted session parameters are generated for the service instance, storing the encryption level and encryption algorithm, and generating a random symmetric key for encrypting business messages for the service instance. Messages with the encryption level set to NoSec are not encrypted, ensuring full compatibility with original SOME / IP messages. Authentication provides data authentication and integrity, while Confidentiality provides three progressively increasing security levels: authentication, authorization, integrity, confidentiality, and replay protection. This combination of simple, high-level rules replaces the low-level strategies of traditional communication networks, achieving the optimal trade-off between security and performance.

[0025] Secondly, mutual authentication is performed between the middleware client and the middleware server: the role associated with the application is determined, namely, providing or requesting. The provider digitally signs its handshake response with its own private key, and the requester verifies the signature to verify whether the current security level of the service instance is acceptable. This ensures that each application only accesses service instances that conform to the authorization policy declared in its corresponding digital certificate. The requester is implicitly authenticated because it needs its own private key to decrypt the symmetric key used for subsequent runtime protection. That is, the provider encrypts the symmetric key with the public key in the requester's certificate, which effectively improves the security of the communication process. Attached Figure Description

[0026] Figure 1This is a flowchart illustrating the middleware communication encryption method of the present invention.

[0027] Figure 2 This is a schematic diagram of the main flow timing in the middleware communication encryption process of the present invention.

[0028] Figure 3 This is a schematic diagram illustrating the format of the encrypted message according to the present invention.

[0029] Figure 4 This is a schematic diagram of the encryption middleware module of the present invention. Detailed Implementation

[0030] The following is in conjunction with the appendix Figures 1-4 The present invention will be further described in detail below:

[0031] Example 1

[0032] See appendix Figure 1 and Figure 2 As shown, a middleware communication encryption method includes the following steps:

[0033] S1: The middleware client starts, reads the certificate, application private key path and configuration file signature data from the configuration file, performs signature verification on the configuration file, and loads the certificate and application private key after the signature verification is successful.

[0034] The middleware server starts, reads the certificate and application private key paths from the configuration file, configures the configuration file signature data, performs signature verification on the configuration file, and loads the certificate and application private key after the signature verification is successful.

[0035] By verifying the authenticity and integrity of the signature before loading the certificate and application private key, the middleware client and server can promptly detect the risk of information tampering, thus initially ensuring the security of the communication process.

[0036] S2: The application requests a service instance, retrieves the service instance's configuration information from the service rule matrix in the application certificate, and then provides the service instance. It generates encrypted session parameters for the service instance, stores progressively increasing multi-level encryption levels and algorithms, and generates a random symmetric key for encrypting business messages for that service instance. Messages with the encryption level set to NoSec are not encrypted, ensuring full compatibility with original SOME / IP messages. Authentication provides data authentication and integrity, while Confidentiality provides three progressively increasing security levels: authentication, authorization, integrity, confidentiality, and replay protection. This combination of simple, high-level rules replaces the low-level strategies of traditional communication networks, achieving an optimal balance between security and performance.

[0037] S3: The middleware client constructs an encrypted session connection request, generates a new random number N, associates each request with the corresponding response, and constructs an authentication request message. The middleware server then begins listening for encrypted session connection requests from the middleware client.

[0038] S4: The middleware client sends the constructed encrypted session connection request to the middleware server and waits to receive the connection response. Upon receiving the encrypted session connection request from the middleware client, the middleware server performs an integrity check and determines whether the integrity check passes. If yes, proceed to step S5; otherwise, the session handshake terminates immediately, and service is refused. This integrity check process ensures data integrity during communication, thereby guaranteeing data security, effectively detecting unexpected changes to data during transmission or storage, ensuring data accuracy and consistency, reducing the probability of data retransmission, and improving data transmission efficiency.

[0039] S5: Use asymmetric encryption technology to extract the public key from the requester's digital certificate to encrypt the symmetric key, construct a response message, digitally sign the response message using the provider's private key, and send the response message back to the middleware client.

[0040] S6: The middleware client verifies the validity of the session connection response message. If the verification is successful, it extracts the symmetric encryption key and algorithm of the service instance. Subsequent business communication messages with the middleware server will be encrypted using the symmetric key.

[0041] Example 2

[0042] Building upon Example 1, the certificate read from the configuration file in step S1 includes a root certificate and an application certificate. The certificate loaded after signature verification also includes a root certificate and an application certificate. The signature data includes a signature algorithm, a signature certificate, and the configuration file signature value. The root certificate is used to issue application certificates, and the application certificate is used to verify the application's identity, ensuring that only legitimate users can access protected resources. Through the use of secure communication protocols, when the application certificate communicates with the server, secure data transmission is ensured, preventing data theft or tampering during transmission. This effectively protects user privacy and security, allowing users to confidently conduct online transactions or other sensitive operations. The root certificate and application certificate together form the foundation of network security, responsible for issuing and managing application certificates, verifying the identity of websites and users, and ensuring secure data transmission, respectively. These mechanisms collectively maintain trust and security in the network environment, enabling users to conduct secure communication and data exchange on the Internet.

[0043] The configuration information in step S2 includes roles and encryption levels. Roles include three types: requester, provider, and requester / provider. Encryption levels include three levels: NoSec, Authentication, and Confidentiality. The three encryption levels provided in step S2—NoSec, Authentication, and Confidentiality—are progressively increasing in level. NoSec does not encrypt the message and is fully compatible with the original SOME / IP message. Authentication provides data authentication and integrity, detecting whether the message has been modified while flowing through the network. Furthermore, the Authentication security level provides replay protection, identifying and discarding duplicate data packets to prevent attackers from capturing valid messages, retransmitting them, and triggering the same operation multiple times. Confidentiality provides authentication, authorization, integrity, and confidentiality, as well as replay protection, including all the security attributes introduced by the authentication level, supplemented by encryption, to prevent potential attackers from stealing the content of messages transmitted over the network, i.e., providing data confidentiality.

[0044] Example 3

[0045] Based on Embodiment 1 or Embodiment 2, the response message in step S5 includes a random number copied from the request, the provider's certificate, a symmetric encryption key, the security level selected by the provider, and a unique identifier assigned to each requester. The response message includes the following information: version number, asymmetric encryption algorithm type, message digest algorithm type, padding field, random number, fingerprint of the middleware server's digital certificate, session security level, session's symmetric encryption algorithm type, a unique identifier assigned to each requester, the length and key value of the encrypted symmetric key, and the signature length and signature value of the response message. The version number is 1 byte long, the asymmetric encryption algorithm type is 1 byte long, the message digest algorithm type is 1 byte long, the padding field is 1 byte long (with an additional 4 bytes for padding), the random number is 32 bytes long, the fingerprint of the middleware server's digital certificate is 32 bytes long, the session security level is 1 byte long, the session's symmetric encryption algorithm type is 1 byte long, and the unique identifier assigned to each requester is 2 bytes long.

[0046] See Figure 3 and Figure 4As shown, the encrypted message format includes SOME / IP Header, SOME / IP Payload, Support Data, and MAC. The module diagram of the encryption middleware includes Application adapter, Service discovery, Routing, Message, Endpoint, Configuration, Security, Crypto, and logging.

[0047] Simultaneously with step S3, a secure session for the service instance is first established. The specific process for establishing a secure session for the service instance is as follows: Mutual authentication is performed between the middleware client and the middleware server: the role associated with the application is determined, namely, providing or requesting. The provider digitally signs its handshake response with its private key, and the requester verifies the signature to determine whether the current security level of the service instance is acceptable. Handshake: The provider and the requester share session parameters, including a symmetric key, symmetric algorithm, and pairing ID transmitted in encrypted form. After the handshake, message communication of the service instance uses the symmetric key from the parameters exchanged during the handshake to encrypt messages.

[0048] The middleware communication encryption method provided by this invention offers service instance-level encryption protection and multiple levels of encryption protection for each service instance. Specifically, NoSec does not encrypt messages, ensuring full compatibility with original SOME / IP messages; Authentication provides data authentication and integrity, detecting whether messages are modified while flowing through the network; furthermore, the Authentication security level provides replay protection, identifying and discarding duplicate data packets to prevent attackers from capturing valid messages, retransmitting them, and triggering the same operation multiple times; Confidentiality provides authentication, authorization, integrity, confidentiality, and replay protection, including all security attributes introduced by the authentication level, supplemented by encryption, to prevent potential attackers from stealing the content of messages transmitted over the network, thus providing data confidentiality. The framework supports configuring multiple encryption algorithms to balance security and performance, supports multicast message encryption in the SOME / IP protocol, and allows for efficient broadcasting of messages. Through three progressively increasing security levels, combined with simple high-level rules, it replaces the low-level strategies of traditional communication networks to achieve the optimal trade-off between security and performance.

[0049] In summary, the middleware communication encryption method provided by this invention involves the following steps: The client starts by reading relevant data from a configuration file and verifying the file's signature. The server starts by reading the certificate and application private key path from the configuration file, configuring the configuration file's signature data, and verifying the file's signature. The application requests a service instance, provides the service instance, generates encrypted session parameters for the service instance, and stores the encryption level and encryption algorithm. The middleware client constructs an encrypted session connection request and an authentication request message. The middleware server begins listening for encrypted session connection requests from the middleware client. The client sends the constructed encrypted session connection request to the server. Upon receiving the encrypted session connection request from the middleware client, the server performs an integrity verification. Finally, it uses asymmetric encryption technology to extract the public key from the requester's digital certificate to encrypt the symmetric key and construct a response message.

[0050] The above process retrieves the configuration information of the service instance from the service rule matrix in the certificate, generates encrypted session parameters for the service instance, stores the encryption level and encryption algorithm, and generates a random symmetric key for encrypting business messages for the service instance. Messages with the encryption level set to NoSec are not encrypted, ensuring full compatibility with original SOME / IP messages. Authentication provides data authentication and integrity, while Confidentiality provides three progressively increasing security levels: authentication, authorization, integrity, confidentiality, and replay protection. This combination of simple, high-level rules replaces the low-level strategies of traditional communication networks, achieving an optimal balance between security and performance. By performing mutual authentication between the middleware client and middleware server: determining the role associated with the application, namely either providing or requesting, the provider digitally signs its handshake response with its own private key, and the requester verifies the signature to check whether the current security level of the service instance is acceptable. This ensures that each application only accesses service instances that conform to the authorization policy declared in its corresponding digital certificate. The requester is implicitly authenticated because it needs its own private key to decrypt the symmetric key used for subsequent runtime protection. That is, the provider encrypts the symmetric key with the public key in the requester's certificate, effectively improving the security of the communication process.

Claims

1. A middleware communication encryption method, characterized in that, Includes the following steps: S1: The middleware client starts, reads the certificate, application private key path and configuration file signature data from the configuration file, performs signature verification on the configuration file, and loads the certificate and application private key after the signature verification is successful. The certificate read from the configuration file includes the root certificate and the application certificate. The middleware server starts, reads the certificate and application private key paths from the configuration file, configures the configuration file signing data, performs signature verification on the configuration file, and loads the certificate and application private key after the signature verification is successful. S2: The application requests a service instance, obtains the configuration information of the service instance from the service rule matrix in the application certificate, the application provides the service instance, obtains the configuration information of the service instance from the service rule matrix in the application certificate, generates encrypted session parameters for the service instance, stores the security level and encryption algorithm, and generates a random symmetric key for encrypting business messages of the service instance. S3: The middleware client constructs an encrypted session connection request, generates a new random number N to associate each request with the corresponding response, and constructs an authentication request message. The middleware server starts listening for encrypted session connection requests from the middleware client. S4: The middleware client sends the constructed encrypted session connection request to the middleware server and waits to receive the connection response. After receiving the encrypted session connection request from the middleware client, the middleware server performs an integrity check and determines whether the integrity check passes. If it does, proceed to step S5; otherwise, the session handshake will terminate immediately and refuse to provide services. S5: Use asymmetric encryption technology to extract the public key from the requester's digital certificate to encrypt a random symmetric key, construct a response message, digitally sign the response message using the provider's private key, and send the response message back to the middleware client. S6: The middleware client verifies the validity of the session connection response message. If the verification is successful, it extracts the random symmetric key and algorithm of the service instance. Subsequent business communication messages with the middleware server will be encrypted using the random symmetric key.

2. The middleware communication encryption method according to claim 1, characterized in that, The certificates loaded after the signature verification in step S1 include the root certificate and the application certificate. The signature data includes the signature algorithm, the signature certificate, and the signature value of the configuration file.

3. The middleware communication encryption method according to claim 1, characterized in that, The configuration information in step S2 includes roles and security levels, where roles include three types: requester, provider, and requester / provider.

4. The middleware communication encryption method according to claim 3, characterized in that, The three security levels provided in step S2 are NoSec (unencrypted security), Authentication (authentication), and Confidentiality (confidentiality), which are progressively higher levels.

5. The middleware communication encryption method according to claim 4, characterized in that, NoSec does not encrypt messages and is fully compatible with original SOME / IP messages; Authentication provides data authentication and integrity, detecting whether messages are modified as they flow through the network. In addition, the Authentication security level also provides replay protection, that is, it identifies and discards duplicate data packets to prevent attackers from capturing valid messages, retransmitting them, and triggering the same operation multiple times; Confidentiality provides authentication, authorization, integrity, and confidentiality, as well as replay protection, including all the security attributes introduced by the authentication level, supplemented by encryption, to prevent potential attackers from stealing the content of messages transmitted over the network, that is, to provide data confidentiality.

6. The middleware communication encryption method according to claim 1, characterized in that, The response message in step S5 includes a random number copied from the request, the provider's digital certificate, a random symmetric key, the security level selected by the provider, and an identifier uniquely assigned to each requester.

7. The middleware communication encryption method according to claim 1, characterized in that, The response message includes the following information: version number, asymmetric encryption algorithm type, message digest algorithm type, padding field, random number, fingerprint of middleware server application certificate, security level of session, symmetric encryption algorithm type of session, unique identifier assigned to each requester, length and key value of encrypted random symmetric key, signature length and signature value of response message, wherein the version number is 1 byte long, the asymmetric encryption algorithm type is 1 byte long, the message digest algorithm type is 1 byte long, the padding field is 1 byte long with an additional 4 bytes for padding, the random number is 32 bytes long, the fingerprint of middleware server application certificate is 32 bytes long, the security level of session is 1 byte long, the symmetric encryption algorithm type of session is 1 byte long, and the unique identifier assigned to each requester is 2 bytes long.

8. The middleware communication encryption method according to claim 1, characterized in that, Simultaneously with step S3, a security session for the service instance is first established. The specific process for establishing a security session for the service instance is as follows: S31: Perform mutual authentication between the middleware client and the middleware server; S32: The middleware client and the middleware server perform a handshake.

9. A middleware communication encryption method according to claim 8, characterized in that, The specific process of performing mutual authentication between the middleware client and the middleware server is as follows: Determine the role associated with the application, namely, the provider or the requester; The provider digitally signs its handshake response using its own private key; The requester verifies the signature to determine if the current security level of the service instance is acceptable.

10. A middleware communication encryption method according to claim 8, characterized in that, The specific process of the handshake between the middleware client and the middleware server is as follows: the provider and the requester share session parameters, including a random symmetric key, symmetric algorithm, and pairing ID transmitted in encrypted form. After the handshake, the message communication of the service instance uses the random symmetric key in the parameters exchanged during the handshake to encrypt the message.

Images