A method for implementing transparent communication protection on a trusted execution environment

Abstract

The application discloses a kind of in trusted execution environment realizes transparent communication protection method, by inserting security protocol layer in the libOS kernel network module of TEE, for the application running in TEE provides transparent communication protection.Developer does not need to write communication protection module in source code.Communication protection range covers the network TCP communication that data flows from one TEE protection domain to another TEE protection domain is not protected by TEE, and protection type includes data confidentiality protection, data integrity protection and identity authentication protection.Specifically includes: key exchange, symmetric encryption and decryption, message verification protocol, and overload socket class and related system call of libOS, so that application is automatically encrypted and decrypted when sending and receiving data.Lightweight high-performance block ring buffer is introduced for fast reassembly and decryption and encryption data, located in TEE protection domain, to ensure data security and efficient processing.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of trusted computing, trusted execution environment, library operating system and network communication protection, and particularly relates to a method for realizing transparent communication protection on a trusted execution environment. BACKGROUND

[0002] Currently, the trusted execution environment technology (Trusted Execution Environment, TEE) has been widely applied on remote machines to protect the confidentiality and integrity of user data and programs. Especially in the cloud platform scenario, if a user wants to rent cloud computing resources to run his own distributed system (such as federated learning), while worrying that his secrets (such as business data and training models) will be stolen by other tenants or cloud platform hosts, he can use Intel Software Guard Extensions (Intel SGX) to protect his system. This is the core idea of the SGX threat model: the user can not trust the host operating system (HostOS). However, the biggest cost of this high security guarantee is to change the traditional programming model.

[0003] In order to enable applications in traditional environment to run directly in SGX environment without redeveloping the application using SGX SDK, the library operating system (libOS) is the most commonly used means at present. The principle of libOS is to implant the operating system as a link library into the executable file of the application, and replace the original system call (syscall) with libOS-syscall rewritten using libOS, so as to achieve the effect of intercepting the syscall of the application. libOS-syscall is accessed to the service of HostOS after SGX exit (SGXexit). The biggest problem of the proxy mechanism of libOS at present is that it cannot guarantee the security of the data flowing out of the protection domain, and the user needs to ensure the security by programming. In terms of network communication, although there are many traditional solutions that can provide communication protection without modifying the application source code (such as proxy and gateway), these solutions usually assume that local communication is secure, thereby allowing the use of third-party processes to encrypt network traffic. In the TEE environment, inter-process communication itself needs to be protected, and the data of the application is exposed to a huge data leakage risk in the process of flowing from the protection domain where the application is located to the third-party process used for network traffic encryption. The current libOS does not embed a network security protocol to ensure the security of network communication, but relies on the user to use an encryption library in the application source code to ensure the security of communication. This causes great inconvenience to the application of SGX. First, the use of encryption library requires certain network security background knowledge, which increases the programming threshold of the developer; second, the porting work requires a lot of work; finally, the network communication behavior of some applications is not managed by the application itself, but depends on other runtime libraries, which usually do not have writable source code. At present, in the field of trusted computing, there is an urgent need for a communication protection solution that does not require modification of the application source code and can ensure that the data is encrypted before flowing out of the protection domain, in other words, a transparent communication protection solution on TEE is needed. SUMMARY

[0004] In view of the above problems that the communication protection in the existing trusted execution environment still needs to be solved by the developer programming, the purpose of the present application is to provide a method for realizing transparent communication protection on a trusted execution environment, which meets the security specification of SGX, that is, requires the communication data of the application to be encrypted before flowing out of the protection domain, provides a communication protection solution without the need for application source code, reduces the threshold of TEE use, and only introduces very small communication encryption overhead, which is suitable for distributed trusted execution environment application scenarios.

[0005] To achieve the above application purpose, the embodiment provides a method for realizing transparent communication protection on a trusted execution environment, comprising the following steps:

[0006] A transparent security protocol layer is inserted in the network module of the libOS kernel of the TEE, and the transparent security protocol layer includes a key exchange handshake protocol, an encryption and decryption protocol, a message verification protocol, and a block ring buffer;

[0007] The inserted transparent security protocol layer provides transparent communication protection for a user application program running in the TEE, including: the user application program implements identity authentication protection based on the key exchange handshake protocol; when the user application program sends request data using TCP, the request data is intercepted and encrypted and integrity verified in the block ring buffer based on the encryption and decryption protocol and the message verification protocol before being sent out of the TEE protection domain; when the user application program receives data using TCP, the received data from outside the TEE protection domain is intercepted, and the received data is decrypted in the block ring buffer based on the encryption and decryption protocol and the message verification protocol before being delivered to the user application program, so as to implement data confidentiality protection and data integrity protection.

[0008] In the method, the transparency in the transparent security protocol layer and the transparent communication protection means that the source code of the user application program does not need to be modified, that is, the application developer does not need to write a communication protection module in the source code of the application program, and the transparent communication protection range based on the transparent communication protection process can be explicitly determined as network TCP communication that is not protected by the TEE between the time when data flows out of one TEE protection domain and the time when the data flows into another TEE protection domain.

[0009] When the transparent security protocol layer is inserted in the network module of the libOS kernel of the TEE, the socket class of the libOS kernel is increased and modified, and is re-encapsulated into a new class ssocket, where the new class ssocket is expressed as:

[0010] class ssocket : public socket {

[0011] private:

[0012] class cipher _sig_cipher;

[0013] class cipher _sym_cipher;

[0014] class cipher _mac_cipher;

[0015] class blockring _blockring;

[0016] public:

[0017] int read();

[0018] int write();

[0019] ssocket accept();

[0020] int connect();

[0021] };

[0022] Wherein, public socket indicates the public socket class, the class ssocket indicates the ssocket class, which is added and modified in the public public socket, has the private member variable private and the public member variable public, wherein the private member variable private includes the class cipher_sig_cipher, the class cipher_sym_cipher, the class cipher_mac_cipher and the class blockring_blockring, is used for identity signature authentication, encrypts and decrypts communication data, _integrity check for communication message, buffer communication data and data format conversion respectively, the public member variable public implements the overload implementation of the core system call system call and syscall, specifically includes int read(), int write(), ssocket accept(), int connect(), respectively indicates read operation, write operation, receiving operation and connection operation.

[0023] Based on the added class ssocket, the ssocket API is provided to the user application upward to replace the implementation of the original syscall method, the communication data requested by the application through syscall is re-encapsulated through ssocket on the application layer, including:

[0024] The definition of linux read: ssize_t read (int fd, void *buf, size_t count);

[0025] Modify its implementation: if the linux file corresponding to fd (file descriptor) belongs to ssocket object, call recvfrom (fd, buf, count, 0, NULL, NULL) to realize read function;

[0026] The definition of linux read: ssize_t recv (int sockfd, void buf[.len], size_tlen, int flags);

[0027] Modify its implementation: if the linux file corresponding to fd (file descriptor) belongs to ssocket object, call recvfrom(sockfd, buf, len, flags, NULL, NULL) to realize recv function;

[0028] Linux definition of read: ssize_t recvfrom(int sockfd, void buf[restrict.len], size_t len, int flags, struct sockaddr *_Nullable restrict src_addr,socklen_t *_Nullable restrict addrlen);

[0029] Modify its implementation: if the linux file corresponding to fd (file descriptor) belongs to ssocket object, encapsulate buf as struct msghdr msg, and then call recvmsg(sockfd, &msg, flags) to realize the function of recvfrom;

[0030] Linux definition of write: ssize_t write(int fd, const void buf[.count],size_t count);

[0031] Modify its implementation: if the linux file corresponding to fd (file descriptor) belongs to ssocket object, call sendto(fd, buf, count, 0, NULL, 0) to realize the function of write;

[0032] Linux definition of write: ssize_t send(int sockfd, const void buf[.len],size_t len, int flags);

[0033] Modify its implementation: if the linux file corresponding to fd (file descriptor) belongs to ssocket object, call sendto(sockfd, buf, len, flags, NULL, 0) to realize the function of send;

[0034] Linux definition of sendto: ssize_t sendto(int sockfd, const void buf[.len], size_t len, int flags, const struct sockaddr *dest_addr, socklen_t addrlen);

[0035] Modify its implementation: if the fd (file descriptor) corresponding to the linux file belongs to the ssocket object, then encapsulate the buf as struct msghdr msg, and call sendmsg(sockfd, &msg, flags) to realize the function of sendto.

[0036] For sendmsg and recvmsg system calls, state recognition is inserted in their implementation, and handshake messages based on the key exchange handshake protocol are passed when necessary, and for the HANDSHAKED state, i.e., the key exchange is completed, the message is symmetrically encrypted and decrypted.

[0037] In the method of the application, the transparent security protocol layer is a complete application layer protocol, which does not change the network (transmission layer, network layer, data link layer, physical layer) message metadata below the application layer, such as IP and port. The network socket interface of the host operating system (HostOeperating System, HostOS) is called downward to access the network, and the libOS is not required to have a network protocol stack implementation. The transparent security protocol layer replaces the linux socket module with ssocket, and provides an API interface consistent with the linux socket module to the user application program upward, maintains the transparency to the application, and does not need to modify the network interface of the application.

[0038] In the method of the application, when the user application program is protected based on the key exchange handshake protocol, the state machine is used to keep the transparency to the user application program, and the key exchange based on the key exchange handshake protocol is completed to realize the identity authentication, wherein the state machine includes states and state transition formulas.

[0039] The states include an initial state NEW, a handshake failure termination state BARE, a handshake completion termination state HANDSHAKED, a request handshake state CHELLOSEND, a waiting handshake state WAITCHELLO, and a handshake reply state RECVCHELLO.

[0040] The state transition formulas include:

[0041] (1) NEW 无身份密钥→ BARE. Indicates that when no identity key is available, the handshake fails and the state is converted to BARE.

[0042] (2) NEW 调用[connect|write|read] → CHELLO sent successfully → CHELLOSEND → SHELLO received successfully → HANDSHAKED. This means that when the NEW state intercepts the connect, write, or read system call, it will send a CHELLO message. If the message is sent successfully, it will transition to the CHELLOSEND state. Then it will try to receive the SHELLO message. If it is successful, the handshake is successful and it will transition to the HANDSHAKED state.

[0043] (3) NEW 调用accept →Receive CHELLO successfully →RECVCHELLO

[0044] →SHELLO sent successfully→HANDSHAKED

[0045] → Sending SHELLO failed → WAITCHELLO. This means that when the NEW state intercepts the accept system call, it will try to receive the CHELLO message. If it is received successfully, it will change to the RECVCHELLO state; then it will try to send the SHELLO message. If it is successful, the handshake is successful and it will change to the HANDSHAKED state; if it fails, it will change to the WAITCHELLO state;

[0046] (4) CHELLOSEND 调用[write|read] → Receive SHELLO successfully → HANDSHAKED. This means that when the CHELLOSEND state intercepts the write or read system call, it will try to receive the SHELLO message. If it is received successfully, it will change to the HANDSHAKED state;

[0047] (5) WAITCHELLO 调用[write|read] → Receive CHELLO successfully → RECVCHELLO → Send SHELLO successfully → HANDSHAKED, which means that when the WAITCHELLO state intercepts the write and read system calls, it will try to receive the CHELLO message. If it is received successfully, it will change to the RECVCHELLO state; then try to send the SHELLO message. If it is successful, the handshake is successful and it will change to the HANDSHAKED state;

[0048] (6) RECVCHELLO 调用[write|read]→ SHELLO success → HANDSHAKED. It means that the state of RECVCHELLO will try to send SHELLO packet when it intercepts the write, read system call, and if it succeeds, it will change to the state of HANDSHAKED.

[0049] Where CHELLO is the handshake initiation packet sent by the communication connection initiator C to the communication connection receiver S, SHELLO is the handshake response packet sent by the receiver S to the initiator C, and call means the syscall generated by the upper layer application. The arrow → indicates the next process, and the call in the state machine conversion formula means that the security protocol layer in libOS intercepts the syscall of the upper layer application. The state machine works in the connect, accept, write, read, send, recv, sendto, recvfrom, sendmsg, and recvmsg syscalls. The initiator C of the communication connection is regarded as the handshake initiator, and the receiver S of the communication connection is regarded as the handshake responder. The handshake initiator sends the handshake initiation packet CHELLO to the handshake responder, and the handshake responder receives the handshake initiation packet CHELLO and feeds back the handshake response packet SHELLO to the handshake initiator.

[0050] The initial state of all ssocket objects when created is NEW. Once the ssocket object calls connect, it will send CHELLO and try to wait for SHELLO. If no reply is received immediately, it will also try to receive SHELLO before the subsequent read / write request (read / write, etc.). Before this, all application communication data will be cached locally and will not be sent to the network in the protection domain, because the key negotiation has not been completed. Similarly, once the ssocket object calls accept, it will try to wait for CHELLO from the handshake initiator, and return SHELLO after receiving CHELLO. After the key negotiation is completed, the state of the ssocket object will end in HANDSHAKED, and the subsequent communication will use the negotiated key for encryption and decryption. If there is no identity key available, the identity signature check cannot be passed, and the state of the ssocket object will remain in BARE, and an exception warning will be thrown.

[0051] The key exchange handshake protocol based on the state machine is as follows:

[0052] C → S :DHpara, DHPKC, PKC, Sig{Hash{DHpara, DHPKC, PKC}, KC};

[0053] S → C : DHPKS, PKS, Sig{Hash{DHPKS, PKS}, KS};

[0054] Where C → S means the initiator C sends a message to the responder S, and the colon behind is the message composition. DHpara is the public parameter of key agreement, DHPKC is the key agreement public key of the initiator, DHPKS is the key agreement public key of the responder. PKC is the identity public key of the initiator, PKS is the identity public key of the responder. K C is the identity private key corresponding to PKC, K S is the identity private key corresponding to PKS. Sig{x, y} means signing x using the key y. Hash{...} means hashing all the contents in the braces to produce a fixed-length digest. After two message transmissions, also known as two handshakes, the communication parties can calculate the session key DHsession according to DHpara and DHPKC. The integrity of the handshake message is protected by the signature. For the identity public key PK, the communication parties need to maintain an additional white list PKSet. The identity of the connection is verified by the signature, and the identity signature verification needs to complete two steps:

[0055] Step 1: Check if the public key of the communication party is in the white list: PK ∈ PKSet t , if successful, continue step 2; otherwise, fail;

[0056] Step 2: veri(PK, Sig): use the cryptographic algorithm to verify whether the public key PK can verify the signature Sig.

[0057] Based on the above key exchange handshake protocol, the message encapsulation information includes: handshake initiation message CHELLO: {word length | key agreement suite | negotiation public key | identity public key | identity signature}; handshake response message SHELLO: {word length | negotiation public key | identity public key | identity signature}; communication message: {encryption {word length | communication data} | message verification code}. The identity signature in the message is provided by the signature algorithm, and has the following cryptographic relationship:

[0058] ;

[0059] Wherein, owf is a one way function, which operates a fixed-length identity signature signature through a random number rand, an identity key key and a text digest digest which is equal in length to key, cpf is a collision-resistant pseudo-random function, which maps an indefinite-length communication payload to a fixed-length text digest digest. Signature verification will check the relationship among signature, digest and public key, and specifically includes:

[0060] For public parameters , a random number k known only by the signing party, the signature calculation is:

[0061] Signature verification:

[0062] As can be seen, the signature guarantees the integrity of the message handshake information and provides the identity information of the signer. The key agreement is achieved through the exchange of CHELLO and SHELLO twice, that is, for public parameters p, g , initiator private key a , responder private key b :

[0063] Handshake initiator:

[0064] Handshake responder:

[0065] In the method of the application, the encryption and decryption protocol for message confidentiality protection is:

[0066] C / S → S / C: enc{msg}, which indicates that the initiator C (or the responder S) sends the encrypted message enc{msg} of the original message msg to the responder S (or the initiator C);

[0067] ​​​​​​​​​​​​​​S / C : msg ← dec{enc{msg}} means that the responder S (or the initiator C) receives the encrypted message enc{msg} and uses the decryption algorithm dec to extract the original message msg.

[0068] In the method of the present application, the message check protocol used for message integrity protection is as follows, taking MAC verification as an example:

[0069] mm[0] ← CPF(block[0], ctr[0]) means that the initiator C performs collision avoidance hash calculation (hereinafter referred to as CPF) on the first message block block[0] using the initial counter ctr[0] to generate the first message check code mm[0].

[0070] C → S : enc{block[0]}, mac{n ← rand, mm[0]} means that the initiator C sends the encrypted first message block enc{block[0]} to the responder S; and a message check message containing a random number n, which informs the responder that the responder will receive a message check code after receiving n regular messages, and the initial message check code mm[0].

[0071] mm[i] ← CPF(mm[i − 1] ⊕ block[i], ctr[i])

[0072] C → S : enc{block[i]} means that the initiator C performs CPF calculation on the next n messages block[i] using the i-th iteration of ctr as the counter and the exclusive OR value of the message check code mm[i-1] of the previous iteration and the current message block block[i] as the text. The ctr counter is incremented by iteration after each CPF calculation. The initiator sends the message block block[i] to the responder S after performing the CPF calculation iteration on the message check code for the next n message blocks block[i].

[0073] C → S : enc{block[n]}, mac{n'← rand, mm[n]} means that after n iterations of calculation and message block sending, the initiator C sends a message check message to the responder S, which contains a random number n', indicating the number of message blocks to be received before the next message check; and a message check code mm[n] after n iterations.

[0074] mm[n] = mac.payload, which means that the responder S compares the mm[n] calculated by itself after receiving the message check packet with the message check code delivered by the sender C in the payload of the message check packet. If they are consistent, the integrity check passes; otherwise, it fails.

[0075] The calculation of the message check code value has the following properties:

[0076] ∀i ∈ [0, n], CPF(block[0], block[1],... block[n]) = CPF(CPF(block[0],... block[i]), CPF(block[i + 1],... block[n])), which means that for any number i between 0 and n (inclusive), the message check code generated by performing the CPF operation on all message blocks from 0 to n is equal to the message check code generated by performing the CPF operation on the message blocks from 0 to i and the message check code generated by performing the CPF operation on the message blocks from i + 1 to n, and then performing the CPF operation again.

[0077] For the responder, even if a single message is truncated and thus needs to be received multiple times to complete message reconstruction, the calculation result of the message check will not change, and the responder only needs to chain process each encrypted message:

[0078] mm[n] ← CPF(mm[n − 1] ← CPF(...CPF(mm[0] ⊕ block[1], ctr[1])...) ⊕ block[n], ctr[n]), which means that the message check code mm[n] can be obtained by performing the CPF operation on the XOR value of the message check code mm[n-1] generated by the previous iteration and the nth message block block[n] and the counter ctr[n] of the nth iteration. And mm[n-1] can be obtained by performing the CPF operation on mm[n-2], block[n-1], and ctr[n-1], and so on.

[0079] After processing n encrypted messages according to this process, the integrity protection check is completed by comparing the MAC value delivered by the communication partner at the end of the message with the MAC value calculated by oneself.

[0080] The method adds a lightweight high-performance block ring to the libOS without a network protocol stack to complete the rapid reorganization and decryption of encrypted block data. The block ring is completely located in the TEE protection domain, ensuring that data decryption occurs in the TEE protection domain and is not sniffed by malicious programs. The block ring includes a physically continuous and logically connected ring-type buffer queue, a block-based cache, a message length header, a decryption suite, and a verification suite.

[0081] When receiving encrypted data in blocks (encrypted blocks), the ring-type buffer queue is added at the tail in byte units, the queue tail pointer is increased by the corresponding length of the data (unit: byte), and the message length header is recorded, to realize data buffering; when decrypting the buffered data, the buffered data is popped out of the head of the buffer ring in block units, the queue head pointer is increased by the corresponding length of the data (unit: byte), and the message length header is recorded, and the popped out buffered data is decrypted and integrity verified through the decryption suite and the verification suite.

[0082] The block ring also has a static memory space, and the runtime reading and writing only change the queue pointer and rewrite the buffer data, without realloc, which is highly efficient. The new ssocket is added to maintain consistency with the original socket behavior. When the user application performs a read syscall, the block ring tries to read as much data as possible from the socket to the receive buffer and decrypt as much data as possible to deliver to the upper layer application. When the tail of the block ring cannot form a complete buffer block, and the application requires the data length to be an integer multiple of the buffer block length, the block ring will split the buffer block, and the data that is not taken will be cached to the block cache, waiting for the next read.

[0083] When the read / recv / recvfrom / recvmsg syscall is triggered in the re-encapsulation, for their common parameters, the file descriptor sockfd, the user receive area des_buf, the receive flag flag, and the maximum length of the user receive area max_len, the block ring executes the following process:

[0084] Step 1: Determine whether the block ring is empty: if If the buffer and the cache are empty at the same time, return true; otherwise, return false:

[0085] return cache.empty() && buffer.empty();

[0086] Step 2: Set the receive flag rflag to flag if step 1 returns true, or to the or of flag and MSG_DONTWAIT if step 1 returns false:

[0087] if (block_ring.empty()) {

[0088] rflag = flag;

[0089] } else {

[0090] rflag = flag | MSG_DONTWAIT;

[0091] }

[0092] Step 3: Perform the system call recv(sockfd, buffer, buffer.size(), rflag);

[0093] Step 4: Check the amount of data that the block ring can decrypt, avail, which is the sum of the cache size, cache.size(), and the amount of data that can be decrypted in the receive buffer, buffer.size(), in units of BLOCK_LEN:

[0094] avail = cache.size() + buffer.size() / BLOCK_LEN * BLOCK_LEN;

[0095] Step 5: Calculate the amount of data that should be delivered to the syscall, ret_len, which is the minimum of the maximum length of the user receive buffer, max_len, and the amount of data that can be decrypted, avail:

[0096] ret_len = min(max_len, avail);

[0097] Step 6: Check if the remaining length of the message maintained in buffer, msg_len, is 0. If it is, update the message length, msg_len, to the result of decrypting the next block in buffer using the decryption suite, cypher:

[0098] if (msg_len == 0) {

[0099] msg_len = cypher.decrypt(buffer, BLOCK_LEN);

[0100] }

[0101] Step 7: Calculate the length of data decrypted from the buffer next time, dec len, which is equal to the difference between ret len and the length of the block buffer, rounded down to the nearest integer multiple of BLOCK LEN. Use the decryption suite cypher to decrypt the data of length dec len in the buffer to obtain the decrypted information dec data:

[0102] dec len = (ret len - cache.size()) / BLOCK LEN*BLOCK LEN;

[0103] dec data = cypher.decrypt(buffer, dec len);

[0104] Step 8: Update the message length msg len to the existing length minus the length of the data decrypted from the buffer this time, dec len:

[0105] msg len = msg len - dec len;

[0106] Step 9: Update the message verification suite state:

[0107] macer.update(buffer, dec len), indicating that the message verification suite macer performs CPF calculation on the data of length dec len in the buffer to iteratively update;

[0108] Step 10: Copy the decrypted data to the user receiving area, and the function of copy(des, src, len) is to copy the data of length len in src to des:

[0109] copy(des_buf, cache, cache.size());

[0110] copy(des_buf + cache.size(), dec_data, dec_len);

[0111] Step 11: Copy the remaining data in dec_data to the buffer block:

[0112] copy(cache, dec_data + dec_len, dec_data.size() - dec_len);

[0113] Step 12: Check if the next message block is the message check code: if msg_len is not equal to 0, it means that the next message block is not the message check code, and the process ends; otherwise, continue to step 13 to check the message.

[0114] Step 13: Check the tail message check code: if the check value of the message check suite is equal to the decrypted value of the next message block in buffer, return true for successful check; otherwise, return false for failure:

[0115] if (macer.get_mac() == cypher.decrypt(buffer, BLOCK_LEN)) {

[0116] return true;

[0117] } else {

[0118] return false;

[0119] }

[0120] In the method of the application, the block ring buffer is rewritten to keep consistent with the original socket behavior, and the select, poll, and epoll syscall related to the read and write signals of the network protocol stack are rewritten;

[0121] The block ring buffer is equivalent to moving part of the network protocol stack from the untrusted HostOS to the trusted TEE protection domain. When the select, poll, and epoll of the HostOS return no readable signal, the block ring buffer is additionally checked for readability, i.e.

[0122] The return value ssocket_ret of the member method select, poll, and epoll of the ssocket is false only when the return value socket_ret of the member method select, poll, and epoll of the socket is false, and the block ring is empty. Otherwise, it returns true:

[0123] if (socket_ret==false&&block_ring.empty()) {

[0124] return false;

[0125] } else {

[0126] return true;

[0127] }。

[0128] Compared with the prior art, the present application has the beneficial effects at least including:

[0129] (1) The present application no longer needs the developer to call a third-party encryption library to complete communication protection when programming for SGX. The developer can directly deploy the existing program in the SGX environment through the libOS, and pass the trusted public key whitelist through the ioctl command, so as to obtain the transparent communication protection capability provided by the present application, which is beneficial to improve the development and deployment efficiency of the application in the trusted execution environment.

[0130] (2) The present application supports separated identity authentication, that is, the identity verification process can not be strongly coupled with the establishment of a secure communication connection. Especially in the trusted execution environment, remote authentication is usually necessary, and the separated identity authentication design can complete remote authentication outside the application program source code, and the identity mounting of the secure communication connection is completed by maintaining the trusted public key whitelist through the ioctl command.

[0131] (3) The present application is simple and feasible, and does not need the libOS to have a network protocol stack module. The block ring provides a simple alternative to the network protocol stack, which can be regarded as a partial mirror of the external HostOS network protocol stack.

[0132] (4) The present application has high reliability. The present application only inserts the encryption and decryption and integrity verification modules required for communication protection in the libOS, and the complex network service is still provided by the external HostOS. At the same time, it is ensured that all socket network communication data has completed encryption before being delivered to the HostOS. BRIEF DESCRIPTION OF DRAWINGS

[0133] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiment or prior art description. Obviously, the drawings in the following description only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained without creative labor on the basis of these drawings.

[0134] Figure 1 The flow chart of the method for implementing transparent communication protection in the trusted execution environment provided for the embodiment;

[0135] Figure 2 The software architecture schematic diagram of the transparent security protocol working in the libOS kernel provided for the embodiment;

[0136] Figure 3 The state machine working flow schematic diagram of the transparent security protocol working in the libOS kernel provided for the embodiment;

[0137] Figure 4The software architecture schematic diagram of the lightweight high-performance block ring buffer provided for the embodiment. DETAILED DESCRIPTION

[0138] In order to make the objects, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and do not limit the protection scope of the present application.

[0139] The present application provides a method for implementing transparent communication protection on a trusted execution environment (TEE), which can be applied to network communication protection tasks, including data confidentiality protection, data integrity protection and identity protection. Through a lightweight block ring buffer, the performance of format conversion between encryption blocks and stream data is improved; and through a state machine-based transparent key exchange handshake protocol, the problem that existing technical solutions are difficult to implement transparent communication protection in a trusted execution environment scenario is solved. Moreover, the process of transparent communication data encryption and decryption meets the threat model of the trusted execution environment, effectively protecting the confidential data plaintext from leaving the protection domain (data is encrypted before flowing out).

[0140] The method for implementing transparent communication protection on a trusted execution environment provided by the present application can be used in a federated learning task, where communication occurs between various training nodes of the federated learning, and the data input by each node when calling socket communication is training data with privacy information, and the communication data between nodes outside the corresponding protection domain is encrypted. It can also be used in a Web server task, where a user client uses the transparent security protocol of the present application to establish a secure connection with a Web server running in a TEE, and communication occurs between the Web server and the user client, and the user privacy is protected by the security protocol. It can also be used in a distributed database task, where communication occurs between distributed database nodes, and the corresponding communication data is encrypted database forms.

[0141] Taking federated learning as an example, the training program is written using pytorch, and the communication is managed by pytorch gloo backend, and the gloo communication parameters remain default (gloo does not encrypt and authenticate the communication by default). Before running the training program, the user calls an initialization program to pass a set of trusted public keys to the libOS kernel through an API. During the running of the training program, the communication connection of gloo is intercepted by the transparent security protocol, the state machine algorithm is used to complete the key exchange and identity authentication, and the communication data is encrypted and decrypted and MAC checked, thereby realizing the identity protection, confidentiality protection and integrity protection described in the present application.

[0142] As shown in Figure 1 The use of the method for implementing transparent communication protection on a trusted execution environment provided by the embodiment includes the following steps:

[0143] Step 1, modify the libOS code according to the application, which can pull the modified libOS code from the corresponding open source library of the application or modify the official libOS code using a patch.

[0144] In the embodiment, the modification of libOS includes: re-encapsulation of the socket module, using ssocket type objects instead of socket type objects, ssocket type restructures the syscall implementation of socket type, including: connect, accept, read, write, send, recv, etc. The state machine-based key negotiation algorithm process is inserted in these syscalls, and the process of calling the block ring buffer for symmetric encryption and decryption of communication data and MAC verification.

[0145] In the embodiment, the modification of libOS includes: a new ioctl operation code (opcode) type, when ioctl identifies that the file descriptor (fd) corresponds to the ssocket object, it will identify the opcode, call the corresponding processing method (handler), and add the public key passed in the parameters of ioctl to the trusted public key set protected in the libOS kernel. The purpose of this step is to inform the libOS kernel which communication parties can be trusted, and to refuse any identity outside the trusted public key set to prevent man-in-the-middle attacks. At the same time, the signature verification of the trusted public key on the key negotiation message also provides integrity protection for key negotiation, preventing third parties from tampering with connection requests.

[0146] In the initialization process, the corresponding open source library of the application provides a reference implementation for identity public key delivery for this embodiment. Users can modify it to meet their identity management needs in distributed applications, such as modifying the input file address of the trusted public key or passing the trusted public key through an environment variable.

[0147] Step 2, use libOS build and run user application.

[0148] In the embodiment, this step is no different from the standard libOS usage method, and the user can refer to the usage guide on the libOS official website. After installing libOS and its running dependencies, compile and run the user's application on the TEE.

[0149] Step 3, use the API of the application to pass the trusted public key set.

[0150] In the embodiment, in order to enable the libOS kernel to be aware of the concept of connected identity and provide identity protection capabilities, the present invention provides a user API to inform libOS which identity public keys can be trusted. Users can manage identity whitelists through the API. When the user uses the API to add a trusted public key to the trusted public key set of the libOS kernel, the corresponding identity will be accepted by the security protocol; when the user uses the API to provide their own identity private key to libOS, the security protocol will be activated, and the signature of the identity private key to the handshake message will be attached to the handshake message of the key negotiation:

[0151] ;

[0152] ;

[0153] ;

[0154] ；

[0155] ;

[0156] Among them, k is a random number known only to the signer, which ensures that no third party can solve the signer's private key by using the simultaneous equations of historical data ( ):

[0157]

[0158] Step 4: Communication protection begins to take effect on the application. From this step onwards, no user intervention is required, i.e. transparent communication protection.

[0159] In the embodiment, libOS will intercept the syscall of the application, wherein the socket module corresponding to the network communication is replaced by the ssocket module corresponding to the present invention. That is, when the application attempts to make a network communication service request through the socket interface, the syscall will be intercepted by ssocket, thereby achieving the purpose of transparent communication protection.

[0160] like Figure 2The figure shows the software architecture of the transparent security protocol. After the user uses the API to pass the identity private key and trusted public key set to the libOS kernel, libOS will start ssocket to protect the communication. At the beginning of the connection, a key negotiation handshake will be performed according to the state transition formula of the state machine to generate a session key and complete the identity verification. When the application subsequently uses syscalls such as read, write, send, and recv to read and write to the ssocket, that is, when the corresponding connected ssocket is used for network communication, the ssocket will use the underlying block ring buffer to perform symmetrical encryption and decryption on the network communication data to protect data confidentiality, perform MAC verification, and ensure data integrity.

[0161] Step 5: Receive a connection request.

[0162] In the embodiment, the communication connection is divided into an initiator and a responder. The key negotiation handshake messages sent and received by both parties in the handshake protocol are inconsistent. Ssocket will identify whether the syscall corresponding to the connection request is connect or accept to divide the initiator and responder of the connection, and initialize the status of both to NEW.

[0163] The subsequent communication connection initiator and responder will follow Figure 3 The state machine shown in the figure transitions between states, ultimately completing the handshake or rejecting the connection. During the handshake process (i.e., the state transition), if a write operation to the ssocket triggers a timeout on the sending or receiving of the handshake message, it indicates that the other party is not ready. At this time, the data written to the ssocket by the original syscall cannot be encrypted and will be cached in the protection domain until the handshake is completed and sent. Correspondingly, read operations on the ssocket triggered during the handshake process will not write to the user receive area and will return 0 to indicate that no data was received.

[0164] Step 6: Symmetric encryption and decryption of communication and integrity verification.

[0165] In this embodiment, when an application invokes a syscall to write to the file descriptor (fd) corresponding to an ssocket, triggering the security protocol, the security protocol encrypts the corresponding user data in the syscall using a symmetric encryption algorithm within the protection domain. The encrypted data is then sent using the host OS's network services, using the session key generated during the key negotiation handshake. A message integrity check (MAC) is appended to the end of the encrypted data packet.

[0166] In the embodiment, when the application calls syscall to read the file descriptor (fd) corresponding to the ssocket and triggers the security protocol, such as Figure 4As shown, the security protocol pulls data from the network protocol stack of the host OS to the tail of the block ring buffer, and decrypts as much data as possible from the head to the application data receiving area. Since the block ring is entirely within the protection domain, data decryption can be performed without exposing the data in plaintext. At the same time, when the block ring processes the end of a message, it identifies the MAC attached to the tail and compares the MAC calculated by itself with the MAC, and if they are the same, the message integrity check is passed, otherwise it indicates that the communication data has been tampered with by a third party. And end the connection to prevent data leakage.

[0167] The present application needs to be embedded in the standard libOS kernel in actual use. The security protocol part of the present application claims intellectual property protection for the design of the handshake protocol process, the state machine, and the structure of the block ring buffer. For specific cryptographic algorithms in the security protocol, the present embodiment only illustrates examples for ease of understanding, and does not claim intellectual property protection. For the signature of the handshake message, both DSA algorithm and RSA algorithm can be used; for symmetric encryption and decryption, both AES algorithm and DES algorithm can be used; for message integrity check MAC, both SHA algorithm and MD5 algorithm can be used.

[0168] The specific embodiments described above have detailed the technical solutions and beneficial effects of the present application. It should be understood that the above description is only the most preferred embodiment of the present application, and is not intended to limit the present application. Any modifications, supplements, and equivalent replacements made within the principle range of the present application should be included in the protection scope of the present application.

Claims

1. A method for implementing transparent communication protection in a trusted execution environment, characterized in that: The following steps are involved: Insert a transparent security protocol layer into the network module of the TEE's libOS kernel. The transparent security protocol layer includes a key exchange handshake protocol, an encryption and decryption protocol, a message authentication protocol, and a block ring buffer. The inserted transparent security protocol layer provides transparent communication protection for user applications running in the TEE, including: user applications implement identity authentication protection based on the key exchange handshake protocol; When a user application uses TCP to send request data, the request data is intercepted and encrypted and integrity-verified in the block ring buffer based on the encryption and decryption protocol and the message authentication protocol before being sent out of the TEE protection domain. When a user application uses TCP to receive data, the received data from outside the TEE protection domain is intercepted and decrypted in the block ring buffer based on the encryption and decryption protocol and the message authentication protocol before being delivered to the user application to achieve data confidentiality protection and data integrity protection.

2. The method for implementing transparent communication protection in a trusted execution environment according to claim 1, characterized in that: When inserting the transparent security protocol layer into the network module of the libOS kernel of the TEE, the libOS kernel socket class is added and modified and then repackaged into a new class ssocket. The new class ssocket is represented as follows: class ssocket : public socket { private: class cipher _sig_cipher; class cipher _sym_cipher; class cipher _mac_cipher; class blockring _blockring; public: int read(); int write(); ssocket accept(); int connect(); }; Among them, public socket represents the public socket class, class ssocket represents the ssocket class, which is newly added and modified in the public socket, and has private member variables private and public member variables public. Among them, the private member variables private include class cipher _sig_cipher, class cipher _sym_cipher, class cipher _mac_cipher, and class blockring _blockring, which are respectively used for identity signature authentication, encryption and decryption of communication data, integrity verification of communication messages, caching of communication data and data format conversion. The public member variables public implement the overloading of core system calls system call and syscall, specifically including int read(), int write(), ssocket accept(), and int connect(), which respectively represent read operations, write operations, receive operations, and connection operations.

3. The method for implementing transparent communication protection in a trusted execution environment according to claim 1, wherein: The transparent security protocol layer is a complete application layer protocol. It does not change the network message metadata below the application layer. It calls the network socket interface of the host operating system to access the network. It does not require libOS to have a network protocol stack implementation. It provides the user application with a new ssocket API interface that is consistent with the host operating system socket, maintains transparency to the application, and does not require the application to modify the network interface.

4. The method for implementing transparent communication protection in a trusted execution environment according to claim 1, wherein: When a user application implements identity authentication protection based on the key exchange handshake protocol, a state machine is used to complete the key exchange based on the key exchange handshake protocol to implement identity authentication while maintaining transparency to the user application. The state machine includes states and state transition formulas. The states include the initial state NEW, the handshake failure termination state BARE, the handshake completion termination state HANDSHAKED, the handshake request state CHELLOSEND, the handshake waiting state WAITCHELLO, and the handshake reply state RECVCHELLO. The state transition formula includes: (1) NEW 无身份密钥 → BARE, which means that when no identity key is available, the handshake fails and the state changes to BARE; (2) NEW 调用[connect|write|read] → CHELLO sent successfully → CHELLOSEND → SHELLO received successfully → HANDSHAKED, indicating that the NEW state will send a CHELLO message when the connect, write, or read system call is intercepted. If the message is sent successfully, the state will be transformed into the CHELLOSEND state; then the state will try to receive the SHELLO message. If successful, the handshake is successful and the state will be transformed into the HANDSHAKED state; (3) NEW 调用accept →Receive CHELLO successfully →RECVCHELLO →Send SHELLO successfully→HANDSHAKED → Sending SHELLO fails → WAITCHELLO, which means that when the NEW state intercepts the accept system call, it will try to receive the CHELLO message. If it is received successfully, it will change to the RECVCHELLO state; then try to send the SHELLO message. If it is successful, the handshake is successful and it will change to the HANDSHAKED state; if it fails, it will change to the WAITCHELLO state; (4) CHELLOSEND 调用[write|read] → Receive SHELLO successfully → HANDSHAKED, which means that when the CHELLOSEND state intercepts the write or read system call, it will try to receive the SHELLO message. If it is received successfully, it will change to the HANDSHAKED state; (5) WAITCHELLO 调用[write|read] → Receive CHELLO successfully → RECVCHELLO → Send SHELLO successfully → HANDSHAKED, which means that when the WAITCHELLO state intercepts the write and read system calls, it will try to receive the CHELLO message. If it is received successfully, it will change to the RECVCHELLO state; then try to send the SHELLO message. If it is successful, the handshake is successful and it will change to the HANDSHAKED state; (6) RECVCHELLO 调用[write|read] →Send SHELLO successfully→HANDSHAKED, indicating that when the RECVCHELLO state intercepts the write or read system call, it will try to send a SHELLO message. If it is sent successfully, it will be converted to the HANDSHAKED state; Among them, CHELLO is the handshake initiation message sent by the communication connection initiator C to the communication connection receiver S, SHELLO is the handshake response message sent by the receiver S to the initiator C, and call refers to the syscall generated by calling the upper-layer application.

5. The method for implementing transparent communication protection in a trusted execution environment according to claim 4, characterized in that: The key exchange handshake protocol implemented based on the state machine includes: Handshake initiation message CHELLO: {word length | key negotiation suite | negotiated public key | identity public key | identity signature}; Handshake response message SHELLO: {word length | negotiated public key | identity public key | identity signature} Communication message: {encryption {word length | communication data} | integrity check code}.

6. The method for implementing transparent communication protection in a trusted execution environment according to claim 1, wherein: The block ring buffer includes a ring buffer queue whose physical addresses are continuous and logically connected end to end, a buffer block in units of blocks, a message length header, a decryption suite, and a verification suite; When receiving encrypted data in blocks, bytes are used as the basic unit to add data to the tail of the circular buffer queue. The tail pointer of the queue increases by the length of the queued data and is recorded in the message length header to achieve data buffering. When decrypting buffered data, the buffered data is popped out of the buffer ring queue head with the buffer block as the basic unit. The queue head pointer increases by the corresponding length of the dequeued data and records it in the message length header. The popped buffered data is decrypted and integrity verified through the decryption suite and verification suite.

7. The method for implementing transparent communication protection in a trusted execution environment according to claim 6, characterized in that: The block ring buffer also has static memory space. Reading and writing at runtime only changes the queue pointer and rewrites the buffer data, and no realloc occurs.

8. The method for implementing transparent communication protection in a trusted execution environment according to claim 6, characterized in that: Also includes: To maintain consistency with the original socket class behavior, the newly added ssocket class attempts to read as much data as possible from the socket class when the user application performs a readsyscall, and decrypts as much data as possible and delivers it to the upper-layer application. When the tail of the block ring buffer cannot form a complete buffer block, and the application requires the data length to be a non-integer multiple of the buffer block length, the block ring buffer will split the buffer block, and the unread data will be cached and wait for the next read.

9. The method for implementing transparent communication protection in a trusted execution environment according to claim 6, wherein: In order to keep the block ring buffer consistent with the original socket-like behavior, the select, poll, and epoll syscalls related to the network protocol stack read and write signals are rewritten; The block ring buffer is equivalent to moving part of the network protocol stack from the untrusted HostOS to the trusted TEE protection domain. When the HostOS select, poll, and epoll return no readable signals, an additional check is performed to see if the block ring buffer is readable, namely: For the return value ssocket_ret of the member methods select, poll, and epoll of ssocket and the return value socket_ret of the member methods select, poll, and epoll of socket, whether block_ring can read br_in: ssocket_ret = socket_ret | br_in.

Images