End-to-end encrypted remote call architecture

Abstract

The invention discloses an end-to-end encrypted remote call architecture, which comprises a server, a server encryption and decryption module, first trusted hardware, a client, a client encryption and decryption module and second trusted hardware, after the server side receives an encrypted data message sent by the client side, a server side encryption and decryption module decrypts the data by using a session key token stored by first trusted hardware, and after decryption, the server side restores the original data and executes corresponding service logic processing according to specific requirements called by the RPC; after the processing is completed, the server encryption and decryption module encrypts the response data by using a session key token stored by the first trusted hardware, and then sends an encrypted response message back to the client; and after receiving the encrypted response message, the client decrypts the data by using a session key token stored by the second trusted hardware to obtain response data of the server, and the client performs subsequent operation according to the corresponding response data and executes a corresponding service process.

Description

Technical Field

[0001] The present application belongs to the field of distributed computing and trusted computing technology, and in particular, relates to an end-to-end encrypted remote call architecture. Background Art

[0002] In today's digital age, Remote Procedure Call (RPC) is widely used in various application scenarios, such as distributed systems, cloud computing, and the Internet of Things. However, traditional remote procedure call methods often face security risks during data transmission, and data may be stolen, tampered with, or monitored by a third party. Although some encryption technologies are currently applied to remote procedure calls, there are still problems such as insufficient flexibility in encryption methods, insufficient encryption thoroughness, complex key management, and complex certificate verification processes, which cannot meet the growing stringent requirements for data security and privacy protection.

[0003] The current mainstream solution is to encrypt RPC communication based on SSL / TLS. First, generate and configure the TLS / SSL certificate and private key on the server, enable TLS / SSL encryption and enter the port listening state. You can use tools such as OpenSSL to generate a self-signed certificate, or use a certificate authority (CA) to obtain a signed certificate; then, configure the server certificate on the RPC client and enable TLS / SSL encryption, and then you can initiate an encrypted RPC call.

[0004] Although the above-mentioned SSL / TLS-based RPC communication provides security, it also has some disadvantages. At the beginning of RPC communication, a connection needs to be established, namely the SSL / TLS handshake, which is a complicated process; certificates and keys need to be managed, which increases the complexity and maintenance cost of the system; due to the encryption of data content, debugging and troubleshooting may become more difficult; if the certificate is not managed properly, it may lead to man-in-the-middle attacks, and attackers can forge certificates; if the certificate expires or is revoked, the communication will be interrupted, affecting the system availability. Summary of the invention

[0005] The purpose of this application is to overcome the problems of the prior art and to disclose an end-to-end encrypted remote call architecture. The architecture of this application solves the problem of data security in the existing remote call process and ensures the confidentiality, integrity and authenticity of data during transmission and processing.

[0006] The purpose of this application is achieved through the following technical solutions:

[0007] An end-to-end encrypted remote call architecture, the end-to-end encrypted remote call architecture comprising: a server, a server encryption and decryption module, a first trusted hardware, a client, a client encryption and decryption module and a second trusted hardware;

[0008] After the server receives the encrypted data message sent by the client, the server encryption and decryption module uses the session key token stored in the first trusted hardware to decrypt the data. After decryption, the server restores the original data and performs corresponding business logic processing according to the specific requirements of the RPC call;

[0009] After the processing is completed, the server encryption and decryption module uses the session key token stored in the first trusted hardware to encrypt the response data, and then sends the encrypted response message back to the client;

[0010] After receiving the encrypted response message, the client uses the session key token stored in the second trusted hardware to decrypt the data and obtain the response data from the server. The client then performs subsequent operations based on the corresponding response data and executes the corresponding business process.

[0011] According to a preferred embodiment, the server is also provided with a micro trusted center, and each trusted hardware is initialized by inserting into the micro trusted center. After initialization, each trusted hardware stores a pair of public and private keys and certificates, and registers its corresponding certificate in the micro trusted center.

[0012] According to a preferred embodiment, the process of generating a communication key in the RPC communication system includes:

[0013] The micro trusted center binds the first trusted hardware, uses the first trusted hardware to generate a random number as the session key token in the RPC communication system, uses the public key of the first trusted hardware to encrypt the session key to obtain etoken and stores it in the secure storage space of the first trusted hardware.

[0014] According to a preferred embodiment, the distribution process of the communication key in the RPC communication system includes:

[0015] When distributing keys, the etoken stored in the first trusted hardware bound to the micro trusted center is decrypted to obtain the session key token, and the session key token is encrypted with the public key of the second trusted hardware of the user to be distributed and then imported into the second trusted hardware of the user to be distributed;

[0016] The user device can be directly inserted into the second trusted hardware to securely access the RPC communication system.

[0017] According to a preferred embodiment, when the client makes a remote procedure call, it first determines the RPC parameters that need to be encrypted, and then passes the string of the corresponding parameters to the bound second trusted hardware, and symmetrically encrypts the corresponding parameter string using the session key token inside the second trusted hardware;

[0018] After receiving the RPC call request, the server sends the specified encrypted field to the first trusted hardware for decryption, and splices the decrypted field with the original field into a complete RPC call, thereby executing the corresponding RPC call request.

[0019] According to a preferred embodiment, after the execution of the call request is completed, the execution result is encrypted by the first trusted hardware and returned to the client;

[0020] After the client receives the RPC call reply, it uses the second trusted hardware to decrypt and obtain the execution result.

[0021] According to a preferred embodiment, each trusted hardware is a USB Key.

[0022] According to a preferred embodiment, the client and the server are respectively bound one by one with their corresponding trusted hardware.

[0023] According to a preferred embodiment, the TCP / IP protocol is used to transmit data packets between the client and the server.

[0024] The aforementioned main scheme of the present application and its further options can be freely combined to form multiple schemes, all of which are schemes that can be adopted and claimed for protection in the present application. After understanding the scheme of the present application, those skilled in the art can understand that there are multiple combinations based on the prior art and common knowledge, all of which are technical schemes to be protected by the present application, and they are not exhaustively listed here.

[0025] Beneficial effects of this application:

[0026] 1. High data confidentiality

[0027] Using end-to-end encryption, key parameters of the data are always encrypted during the entire transmission and processing process. Only the two communicating parties can decrypt and view the data content, which greatly reduces the risk of data being stolen and spied on by third parties, and effectively protects users' privacy and sensitive information.

[0028] 2. Reliable data integrity

[0029] During the data encryption process, data verification information, such as hash values, can be generated and transmitted together with the encrypted data. After decryption, the server can verify the integrity of the data by comparing the verification information, ensuring that the data has not been tampered with during transmission, thereby ensuring the reliability and accuracy of the data.

[0030] 3. Simplified key management

[0031] Key management and encryption and decryption based on trusted hardware are simpler and safer. The client only needs to call the interface of the trusted hardware to complete the encryption and decryption process; key initialization and update operations can be directly operated on the trusted hardware through the Micro Trust Center device or updated online through encrypted RPC. It not only reduces the risk of key leakage, but also takes into account flexibility and improves the efficiency of key management.

[0032] 4. Prevent man-in-the-middle attacks

[0033] Use trusted hardware to bind to the RPC client / server, encrypt key parameters during transmission, add verification information to the data content, and other means to comprehensively prevent man-in-the-middle attacks.

[0034] 5. Wide applicability

[0035] This application is applicable to various remote procedure call scenarios and application fields, such as remote calls between distributed nodes in supercomputing centers, communications between distributed systems within enterprises, and data interactions between IoT devices. It can provide strong data security protection and has high versatility and practicality. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 This is a schematic diagram of the structure of the end-to-end encrypted remote call architecture of this application;

[0037] Figure 2 This is the remote procedure call sequence diagram of this application;

[0038] Figure 3 It is a hardware logic connection diagram of this application. DETAILED DESCRIPTION

[0039] The following describes the embodiments of the present application through specific examples, and those skilled in the art can easily understand other advantages and effects of the present application from the contents disclosed in this specification. The present application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present application. It should be noted that the following embodiments and features in the embodiments can be combined with each other without conflict.

[0040] It should be noted that similar reference numerals and letters denote similar items in the following drawings, and therefore, once an item is defined in one drawing, further definition and explanation thereof is not required in subsequent drawings.

[0041] In the description of the present application, it should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc. indicate positions or positional relationships based on the positions or positional relationships shown in the accompanying drawings, or the positions or positional relationships in which the product of the application is usually placed when in use. They are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific position, be constructed and operated in a specific position, and therefore cannot be understood as a limitation on the present application. In addition, the terms "first", "second", "third", etc. are only used to distinguish the description, and cannot be understood as indicating or implying relative importance.

[0042] In the description of this application, it should also be noted that, unless otherwise clearly specified and limited, the terms "set", "install", "connect", and "connect" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or it can be indirectly connected through an intermediate medium, or it can be the internal communication of two elements. For ordinary technicians in this field, the specific meanings of the above terms in this application can be understood according to specific circumstances.

[0043] In addition, the present application would like to point out that, in the present application, unless the specific structure, connection relationship, positional relationship, power source relationship, etc. are specifically written out, the structure, connection relationship, positional relationship, power source relationship, etc. involved in the present application are all known by those skilled in the art on the basis of the prior art without creative work.

[0044] refer to Figure 1 and Figure 2 As shown, the present application discloses an end-to-end encrypted remote call architecture, the end-to-end encrypted remote call architecture comprising: a server, a server encryption and decryption module, a first trusted hardware, a client, a client encryption and decryption module and a second trusted hardware;

[0045] After the server receives the encrypted data message sent by the client, the server encryption and decryption module uses the session key token stored in the first trusted hardware to decrypt the data. After decryption, the server restores the original data and performs corresponding business logic processing according to the specific requirements of the RPC call;

[0046] After the processing is completed, the server encryption and decryption module uses the session key token stored in the first trusted hardware to encrypt the response data, and then sends the encrypted response message back to the client;

[0047] After receiving the encrypted response message, the client uses the session key token stored in the second trusted hardware to decrypt the data and obtain the response data from the server. The client then performs subsequent operations based on the corresponding response data and executes the corresponding business process.

[0048] In this application, the server / client adds an encryption and decryption module layer between the traditional RPC call service layer and the business layer, and calls the encryption and decryption interface of USBKey through the encryption and decryption module layer to realize the encryption and decryption of data content.

[0049] In this application, TCP / IP protocol is used between the client and the server to transmit data packets with encrypted key parameters. During the transmission process, some mechanisms of the network protocol itself, such as data packet checksum and retransmission, can ensure the reliable transmission of data, and the key parameter part of the data content always exists in ciphertext to ensure data security.

[0050] Trusted hardware generally refers to a secure cryptographic device that supports commonly used domestic and foreign cryptographic algorithms and national secret algorithms, has secure storage space, and supports secure storage and use of public and private keys and certificates. Common trusted hardware includes smart password keys (USBKey), trusted encryption modules (TPM / TCM), etc. In this application, USBKey is used to encrypt and store the session key of the RPC call, and different USBKeys are made for different RPC clients / servers to save the encrypted session key, ensuring that the trusted RPC client / server device is bound to the USBKey hardware one-to-one. By using trusted hardware to bind to the RPC client / server, encrypting key parameters during the transmission process, and adding verification information to the data content, man-in-the-middle attacks are comprehensively prevented.

[0051] This application encrypts RPC parameters at the application layer based on trusted hardware, rather than using SSL / TLS encryption at the RPC service layer, to improve the flexibility of encryption operations.

[0052] Preferably, the server is provided with a micro trusted center, and each trusted hardware is initialized by inserting into the micro trusted center. After initialization, each trusted hardware stores a pair of public and private keys and certificates, and registers its corresponding certificate in the micro trusted center.

[0053] The process of generating the communication key in the RPC communication system includes:

[0054] The micro trusted center binds the first trusted hardware, uses the first trusted hardware to generate a random number as the session key token in the RPC communication system, uses the public key of the first trusted hardware to encrypt the session key to obtain etoken and stores it in the secure storage space of the first trusted hardware.

[0055] The distribution process of communication keys in the RPC communication system includes:

[0056] When distributing keys, the etoken stored in the first trusted hardware bound to the Micro Trust Center is decrypted to obtain the session key token, and the session key token is encrypted with the public key of the second trusted hardware of the user to be distributed and then imported into the second trusted hardware of the user to be distributed; the user device is directly inserted into the second trusted hardware to securely access the RPC communication system. Therefore, the key is stored in the trusted hardware USBKey in the form of an encrypted etoken during storage and transmission, and is used in the internal encrypted container of the trusted hardware USBKey to ensure that the key will not be exposed in plain text.

[0057] Furthermore, the tokens required for client RPC communication are uniformly initialized and distributed at the Micro Trust Center, ensuring the security of data transmission; the token is encrypted into etoken and stored inside the second trusted hardware USBKey, and external devices cannot read the token, ensuring the security of data storage; the etoken is decrypted and used in the isolated container inside the second trusted hardware USBKey, and the plain text cannot be read by external devices, ensuring the security of data use.

[0058] In addition, when the client is in normal use, the etoken in the second trusted hardware USBKey of the client can be updated online. The update is performed through RPC calls, and the key parameters are encrypted to ensure that the token cannot be obtained by a third party.

[0059] Preferably, when the client makes a remote procedure call, it first determines the RPC parameters that need to be encrypted, then passes the corresponding parameter string to the bound second trusted hardware USBKey, and uses the session key token inside the second trusted hardware to symmetrically encrypt the corresponding parameter string. Thus, the entire encryption process is executed in the secure container inside the second trusted hardware USBKey, avoiding the risk of token leakage.

[0060] After receiving the RPC call request, the server sends the specified encrypted field to the first trusted hardware for decryption, and splices the decrypted field with the original field into a complete RPC call, thereby executing the corresponding RPC call request. After the server call request is executed, the execution result is encrypted using the first trusted hardware and returned to the client; after the client receives the RPC call reply, it uses the second trusted hardware to decrypt and obtain the real execution result.

[0061] This application uses trusted hardware to store keys, and uses the Micro Trust Center (trusted management device) to manage, distribute, update, delete, etc. keys, simplifying the handshake process of the connection. In addition, the application layer is responsible for whether to encrypt and the range of encryption parameters, which is more flexible and customizable, and easier to debug. At the same time, the trusted hardware is bound to the client and server of the RPC call one by one to avoid man-in-the-middle attacks.

[0062] Example 1

[0063] refer to Figure 3 As shown in the figure, a hardware application form of the present application is shown. Different from the traditional RPC call encrypted by SSL / TLS, the cloud platform based on the TIPU trusted infrastructure unit, the TIPU card and the physical server host are physically connected through a PCIE bridge, and the TIPU itself has an independent operating system.

[0064] Therefore, in the TIPU-USBKey solution, the trusted hardware USBKey is connected through the USB interface as a TIPU board peripheral, and the TIPU operating system completes the encryption and decryption work by calling the driver interface of the trusted hardware USBKey to access the hardware. In the TIPU-USBKey solution, the trusted hardware USBKey supports commonly used encryption algorithms at home and abroad, especially the national secret algorithm. It imports the public and private key pairs bound to the user during initialization, provides the function of executing encryption and decryption algorithms in the hardware device, and provides a certain amount of secure storage space. Neither the TIPU device nor the user device can access the session key (token), ensuring the security of the session key.

[0065] Before the first use of the trusted hardware USBKey, you need to create the user's corresponding public and private keys and certificates in the certificate center, and insert them into the Micro Trust Center device when using them. Then the Micro Trust Center calls the relevant interfaces of UBSKey to generate session keys, encrypt session keys, save session keys, delete session keys, etc.

[0066] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present application should be included in the protection scope of the present application.

Claims

1. An end-to-end encrypted remote call architecture, characterized in that: The end-to-end encrypted remote call architecture includes: a server, a server encryption and decryption module, a first trusted hardware, a client, a client encryption and decryption module, and a second trusted hardware; After the server receives the encrypted data message sent by the client, the server encryption and decryption module uses the session key token stored in the first trusted hardware to decrypt the data. After decryption, the server restores the original data and performs corresponding business logic processing according to the specific requirements of the RPC call; After the processing is completed, the server encryption and decryption module uses the session key token stored in the first trusted hardware to encrypt the response data, and then sends the encrypted response message back to the client; After receiving the encrypted response message, the client uses the session key token stored in the second trusted hardware to decrypt the data and obtain the response data from the server. The client then performs subsequent operations based on the corresponding response data and executes the corresponding business process.

2. The end-to-end encrypted remote call architecture as claimed in claim 1, characterized in that: The server is also provided with a micro-trusted center, and each trusted hardware is initialized by inserting into the micro-trusted center. After initialization, each trusted hardware stores a pair of public and private keys and certificates, and registers its corresponding certificate in the micro-trusted center.

3. The end-to-end encrypted remote call architecture as claimed in claim 2, characterized in that: The process of generating the communication key in the RPC communication system includes: The micro trusted center binds the first trusted hardware, uses the first trusted hardware to generate a random number as the session key token in the RPC communication system, uses the public key of the first trusted hardware to encrypt the session key to obtain etoken and stores it in the secure storage space of the first trusted hardware.

4. The end-to-end encrypted remote call architecture as claimed in claim 3, characterized in that: The distribution process of communication keys in the RPC communication system includes: When distributing keys, the etoken stored in the first trusted hardware bound to the micro trusted center is decrypted to obtain the session key token, and the session key token is encrypted with the public key of the second trusted hardware of the user to be distributed and then imported into the second trusted hardware of the user to be distributed; The user device can be directly inserted into the second trusted hardware to securely access the RPC communication system.

5. The end-to-end encrypted remote call architecture as claimed in claim 1, characterized in that: When the client makes a remote procedure call, it first determines the RPC parameters that need to be encrypted, then passes the corresponding parameter string to the bound second trusted hardware, and uses the session key token inside the second trusted hardware to symmetrically encrypt the corresponding parameter string; After receiving the RPC call request, the server sends the specified encrypted field to the first trusted hardware for decryption, and splices the decrypted field with the original field into a complete RPC call, thereby executing the corresponding RPC call request.

6. The end-to-end encrypted remote call architecture as claimed in claim 5, characterized in that: After the server calls the request, it encrypts the execution result using the first trusted hardware and returns it to the client. After the client receives the RPC call reply, it uses the second trusted hardware to decrypt and obtain the execution result.

7. The end-to-end encrypted remote call architecture as claimed in claim 1, characterized in that: Each trusted hardware is a USBKey.

8. The end-to-end encrypted remote call architecture as claimed in claim 1, characterized in that: The client and the server are respectively bound to their corresponding trusted hardware one by one.

9. The end-to-end encrypted remote call architecture as claimed in claim 1, characterized in that: The TCP / IP protocol is used to transmit data packets between the client and the server.

Images