Method, device and medium for implementing secure socket communication in operating system kernel

Abstract

This application discloses a method, apparatus, and medium for implementing secure socket communication within the operating system kernel, belonging to the field of computer systems and network communication technology. This method registers a new secure socket type at the socket layer of the operating system kernel and associates it with a customized set of operation functions. Applications only need to create sockets of this type and inject cryptographic parameters through standard system calls to establish a connection, thereby obtaining transparent, end-to-end automatic encrypted communication capabilities. During transmission, data is encrypted in kernel mode by calling the native crypto subsystem API through a rewritten send function and an authentication tag is attached. During reception, the rewritten receive function automatically performs decryption and integrity verification. This scheme avoids reliance on large external security libraries, improves security and performance, and decentralizes encryption / decryption, resource management, and other processes to the kernel mode, providing upper-layer applications with easy-to-use, lightweight, high-performance, and highly secure kernel-level transparent secure communication.

Description

Technical Field

[0001] This invention belongs to the field of computer systems and network communication technology, and particularly relates to a method, apparatus and medium for implementing secure socket communication in the operating system kernel. Background Technology

[0002] Network communication security is a core requirement in the field of information technology. In the Internet environment, in order to protect the confidentiality and integrity of transmitted data, it is usually necessary to provide encryption protection for communication links between computers.

[0003] Currently, existing technologies for establishing secure links for mainstream, network-secure communications primarily focus on application-layer implementation. These solutions typically utilize existing security protocol stacks and cryptographic libraries to achieve encrypted communication. A widely adopted existing technology is the OpenSSL library and its implemented SSL / TLS protocol. In this approach, the applications of both communicating parties, by calling application programming interfaces such as OpenSSL, establish a regular socket connection and then initiate additional security processes such as handshake negotiation and key exchange. Ultimately, at the application-layer data level, they achieve functions such as encryption, decryption, and authentication of plaintext data, forming a secure logical channel. This technical architecture, as an industry-standard solution, has been integrated into browsers, servers, and various web application software.

[0004] However, this existing technology, primarily implemented at the application layer, has significant drawbacks and limitations. First, it introduces complex dependencies. Libraries like OpenSSL are large, containing functionality far exceeding simple secure communication needs, and rely on numerous other runtime libraries and system components, increasing system complexity. Second, it introduces additional security risks. Due to the sheer size of its codebase and the widespread use of its applications, OpenSSL has historically experienced several serious security vulnerabilities, directly threatening thousands of upper-layer applications that depend on it. Third, it presents high costs and challenges in integration, deployment, and maintenance. Version updates, maintenance of dependent libraries, and compilation adaptations for different operating systems all burden developers and administrators. Finally, in certain specific computing environments or resource-constrained scenarios, such as embedded systems or customized kernel environments, integrating such complex application-layer security libraries may be impractical or prohibitively costly.

[0005] In summary, although existing application-layer secure communication technologies are mature and widely used, their complex dependencies, potential vulnerability risks, and high integration and maintenance costs make finding a more lightweight, secure, and easier-to-integrate and maintain secure communication solution a pressing technical problem. Especially given that operating systems already have built-in high-performance, high-security cryptographic algorithms, building an automated, transparent secure socket communication mechanism at the kernel level can effectively circumvent these shortcomings and provide a new technical path for scenarios requiring simplification, high performance, and high security. Summary of the Invention

[0006] To overcome the problems of complex dependencies, numerous security risks, and high integration and maintenance costs in existing application-layer secure communication technologies, this invention provides a method, apparatus, and medium for implementing secure socket communication in the operating system kernel, achieving the following core objectives: 1) providing a lightweight secure communication solution without introducing complex external dependencies; 2) placing encryption and decryption operations in kernel mode, utilizing high-performance kernel algorithms and isolation mechanisms to improve system security and performance; 3) providing transparent operations to upper-layer applications, minimizing application development complexity.

[0007] A first aspect of the present invention provides a method for implementing secure socket communication in an operating system kernel. This method, based on the operating system kernel, specifically includes the following steps: S1: Register a new secure socket type in the socket layer of the operating system kernel, the secure socket type being associated with a customized set of socket layer operation functions; S2: In response to the application's socket creation request, generate a socket instance belonging to the secure socket type and bind it to the customized socket layer operation function set; S3: Receive the cryptographic parameters injected by the application through the socket instance, store the cryptographic parameters in the kernel memory structure associated with the socket, and complete the encryption context initialization; S4: When the application calls the sending interface to send data, the sending function in the customized operation function set is triggered. The sending function intercepts the user-mode plaintext data, calls the kernel cryptographic algorithm service, uses the stored cryptographic parameters to encrypt and protect the integrity of the plaintext data, generates ciphertext data containing authentication tags, and then sends the ciphertext data to the other end through the underlying network protocol stack. S5: When the socket instance receives ciphertext data sent by the peer, it triggers the receive function in the custom operation function set. The function calls the kernel cryptographic algorithm service to decrypt and verify the integrity of the ciphertext data using the stored cryptographic parameters. After the verification is successful, the plaintext data is returned to the application.

[0008] Specifically, in step S3, the application injects cryptographic parameters through the setsockopt system call. The parameter setting function in the custom operation function set intercepts the cryptographic parameters of the call, verifies the validity of the parameters, and stores them in the kernel memory structure.

[0009] Furthermore, the cryptographic parameters include at least a key for a symmetric encryption algorithm, an initialization vector, and additional authentication data, wherein the symmetric encryption algorithm is an algorithm that supports an authentication encryption mode.

[0010] Furthermore, the symmetric encryption algorithm is the AES algorithm in GCM mode, and the authentication tag length is 128 bits.

[0011] Specifically, step S4 includes: S401: Allocate a kernel buffer in kernel mode that is larger than the original length for the user-space plaintext data to be sent, in order to hold the authentication tag generated by encryption; S402: Copy user-mode plaintext data to kernel-mode buffer; S403: Calls the authentication and encryption API provided by the kernel crypto subsystem, i.e., the cryptographic algorithm service, to encrypt and authenticate the data in the kernel-mode buffer, generating ciphertext data containing authentication tags; S404: Calls the send function of the kernel standard network protocol to transmit encrypted data containing the authentication tag to the other end through the standard network send interface.

[0012] Specifically, step S5 includes: S501: Calls the receive function of the kernel standard network protocol stack to receive encrypted data packets containing authentication tags from the peer from the network buffer; S502: Allocate a buffer in kernel mode to hold the received ciphertext data, and call the authentication and decryption API provided by the kernel crypto subsystem to decrypt and verify the integrity of the ciphertext data; S503: If the verification passes, the decrypted plaintext data is copied from the kernel-mode buffer back to the buffer provided by the user-mode application; if the verification fails, an error message is returned and the data packet is discarded.

[0013] Specifically, after step S5 of the method for implementing secure socket communication in the operating system kernel, step S6 is further included: when the application closes the socket instance, a release function in the custom operation function set is triggered, which securely clears the cryptographic parameters stored in the kernel memory and releases the encryption algorithm instance and related kernel resources.

[0014] A second aspect of the present invention provides an apparatus for implementing secure socket communication in an operating system kernel, employing a modular design that allows for dynamic loading and unloading from the operating system kernel, comprising: The socket type registration module is used to register new secure socket types in the kernel and associate them with a set of customized socket layer operation functions; The parameter management module is used to receive and store application-injected cryptographic parameters and initialize the encryption context through the overridden setsockopt function; The automatic encryption module is used to intercept user-mode plaintext data through a rewritten send function, call the kernel cryptographic algorithm service to complete encryption and integrity protection, and send the ciphertext data into the network protocol stack. The automatic decryption module is used to obtain the ciphertext data from the other end through the rewritten receiving function, call the kernel cryptographic algorithm service to complete the decryption and integrity verification, and return the legitimate plaintext data to the application. The resource cleanup module is used to clear sensitive cryptographic parameters and release kernel encryption resources when the socket is closed.

[0015] Furthermore, this application also proposes that both the automatic encryption module and the automatic decryption module call the native crypto subsystem API of the operating system kernel to achieve hardware acceleration support for encryption and decryption operations.

[0016] In a third aspect, this application also proposes a computer-readable storage medium having a computer program / instructions stored thereon, which, when executed by a processor, implements the above-described method for implementing secure socket communication in an operating system kernel.

[0017] Compared with the prior art, the present invention has the following advantages: 1. High transparency and ease of use: Application developers do not need to understand the complex details of cryptographic protocols. They only need to specify a new type (such as SOCK_GCM_UDP) when creating a socket and pass in the pre-shared key parameter through the standard interface setsockopt to obtain full-link automatic encryption and decryption communication capabilities.

[0018] 2. High performance and low overhead: Encryption and decryption calculations are performed directly using highly optimized cryptographic algorithm libraries natively provided by the operating system kernel (such as the crypto subsystem of the Linux kernel), avoiding the overhead of frequent data copying and context switching between user mode and kernel mode.

[0019] 3. Lightweight and High Security: The solution is implemented as a compact kernel module, which greatly reduces system complexity, does not rely on a large external security library, and reduces the attack surface; at the same time, the kernel-mode key and algorithm context are isolated from the user process space, making it more difficult for attackers to directly detect or tamper with compared to the user-mode implementation.

[0020] 4. Excellent compatibility and scalability: Implemented without modifying the core logic of the kernel's standard network protocol stack, it has no intrusion on existing UDP / TCP applications. It is easily extensible to support different cryptographic algorithms (such as SM4, AES-GCM, AES-CCM, etc.), requiring only adaptation of the encryption / decryption engine's adaptation layer.

[0021] 5. Reduced operation and maintenance costs: As the reliance on core network security functions has shifted from complex application libraries to a stable and relatively fixed operating system kernel, the difficulty and cost of system integration, deployment and long-term operation and maintenance are greatly reduced.

[0022] The method, apparatus, and computer-readable storage medium provided by this invention enable encryption and decryption operations to be handled directly at the socket layer by registering secure socket types and binding custom function sets at the kernel layer. This avoids dependencies on application-layer libraries, offering advantages such as reduced reliance on external libraries, simplified system architecture, improved communication security, and lower maintenance and deployment costs. It effectively addresses the complexity, security, and performance issues arising from the implementation of application-layer security components in existing technologies, providing a new and reliable solution for scenarios requiring lightweight, highly secure network communication.

[0023] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures pointed out in the description, claims and drawings. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 This is a flowchart illustrating a method, apparatus, and medium for implementing secure socket communication in an operating system kernel according to an embodiment of the present invention. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0027] Example 1: In this embodiment, please refer to Figure 1 This paper provides a method for implementing secure socket communication in an operating system kernel, the method comprising the following steps: Step S1: Register a new secure socket type in the socket layer of the operating system kernel. The secure socket type is associated with a customized set of socket layer operation functions. Step S2: Respond to the application's socket creation request, generate a socket instance of the secure socket type, and bind it to a custom set of socket layer operation functions; Step S3: Receive the cryptographic parameters injected by the application through the socket instance, store the cryptographic parameters in the kernel memory structure associated with the socket, and complete the encryption context initialization; Step S4: When the application calls the send interface to send data, the send function in the custom operation function set is triggered. The send function intercepts the user-mode plaintext data, calls the kernel cryptographic algorithm service, uses the stored cryptographic parameters to encrypt and protect the integrity of the plaintext data, generates ciphertext data containing authentication tags, and then sends the ciphertext data to the other end through the underlying network protocol stack. Step S5: When the socket instance receives ciphertext data sent by the peer, it triggers the receive function in the custom operation function set. The function calls the kernel cryptographic algorithm service to decrypt and verify the integrity of the ciphertext data using the stored cryptographic parameters. After successful verification, the plaintext data is returned to the application.

[0028] For ease of understanding, the following explains some key terms in this embodiment: The operating system kernel is the core component of a computer operating system, responsible for managing system resources, scheduling processes, and providing hardware abstraction. It runs in privileged mode, having direct access to system hardware to ensure system stability and security.

[0029] The socket layer is a key software layer in the operating system kernel that implements network communication abstraction. It provides a programming interface for applications, enabling them to interact with the underlying network protocol stack in a unified way to send and receive data.

[0030] A secure socket type is a socket class registered in the socket layer of the operating system kernel. This type is designed to provide built-in secure communication functions; its behavior and operations are defined and managed through a specific set of associated socket layer operation functions, thereby achieving transparent data encryption / decryption and integrity protection.

[0031] The new secure socket type does not refer to a completely new network protocol parallel to TCP or UDP. Instead, it's a new "family" or "protocol type" registered within the existing socket framework, bound to a set of kernel functions that implement secure communication logic. Its core purpose is to provide upper-layer applications with a communication mechanism that allows for end-to-end automatic encryption, decryption, and integrity verification without integrating complex external security libraries or modifying application-layer code. Applications simply create sockets by specifying this new type, injecting the necessary cryptographic parameters through standard interfaces, just like creating ordinary sockets. Subsequent data encryption / decryption, authentication, and other security operations are all handled automatically and transparently by the kernel.

[0032] A custom socket layer operation function set is a set of functions designed for a specific socket type (such as a secure socket type). These functions rewrite or extend standard socket operations, such as sending, receiving, and setting parameters, to implement specific security processing logic at the kernel level, such as intercepting data and invoking cryptographic services.

[0033] A socket instance is a communication endpoint object created by an application at runtime. When an application requests the creation of a secure socket, an instance of the secure socket type is generated and automatically bound to the specific socket layer operation function set mentioned above, enabling it to have secure communication capabilities.

[0034] Cryptographic parameters are the input data necessary for executing cryptographic algorithms, such as encryption keys and initialization vectors. The security of these parameters directly affects the confidentiality and integrity of communication. In this embodiment, these parameters are securely stored in the kernel memory structure associated with the socket.

[0035] Kernel cryptographic algorithm services are a set of cryptographic algorithm implementation interfaces provided by the operating system kernel. These services are typically optimized to perform cryptographic operations such as encryption, decryption, hashing, and authentication using the processor instruction set or dedicated hardware accelerators, providing secure computation support for kernel modules.

[0036] An authentication tag is a piece of additional data generated during the execution of the authentication encryption algorithm. This tag is transmitted along with the ciphertext data. The receiver verifies the authentication tag to confirm whether the ciphertext data has been tampered with during transmission, thereby ensuring the integrity and authenticity of the data.

[0037] This embodiment provides a method for implementing secure socket communication in the operating system kernel: First, a new secure socket type is registered in the socket layer of the operating system kernel, and this secure socket type is associated with a specific set of socket layer operation functions. Specifically, a socket family identifier can be defined in the kernel, for example, by modifying relevant data structures in the kernel network subsystem to add support for that family. Then, a set of socket operation functions is implemented for this defined socket family or type. This set contains function pointers for handling operations such as socket creation, data sending, data receiving, parameter setting, and resource release. These function pointers are configured to point to the secure processing logic implemented in this embodiment. For example, the socket type and its set of operation functions can be dynamically registered with the kernel when the kernel module is loaded.

[0038] Secondly, in response to the application's socket creation request, a socket instance belonging to the aforementioned secure socket type is generated and bound to the specific set of socket layer operation functions. When an application requests to create a socket via a system call (e.g., 'socket()'), the operating system kernel recognizes that the request is for a registered secure socket type. The kernel then calls the creation function from the aforementioned specific set of operation functions. This creation function allocates kernel resources, such as data structures like 'struct socket' and 'struct sock', and points the internal operation function pointers of the newly generated socket instance to the aforementioned specific set of socket layer operation functions, thereby ensuring that the socket instance can automatically execute secure logic in subsequent operations.

[0039] Furthermore, the cryptographic parameters injected by the application are received through the aforementioned socket instance and stored in the kernel memory structure associated with the socket, thus completing the encryption context initialization. After creating a secure socket instance, the application needs to provide the kernel with cryptographic parameters for encryption and decryption operations. This can be achieved through system call interfaces; for example, the application can call a system call designed for secure sockets to pass parameters such as the key and initialization vector from user space to kernel space. In the kernel, the parameter setting function in the aforementioned specific operation function set receives these parameters and securely copies them to the kernel memory area associated with the current socket instance. This kernel memory area can be a field in the socket data structure or a dynamically allocated buffer. After the parameters are stored, the kernel initializes the encryption context based on these parameters, preparing for subsequent data encryption and decryption operations.

[0040] Furthermore, when the application calls the send interface to send data, it triggers the send function in the aforementioned specific operation function set. This send function intercepts the user-space plaintext data, calls the kernel cryptographic algorithm service, and uses the stored cryptographic parameters to encrypt and protect the integrity of the plaintext data, generating ciphertext data containing an authentication tag. The ciphertext data is then sent to the peer via the underlying network protocol stack. Specifically, when the application performs a send operation (e.g., 'send()' or 'write()') on a secure socket instance, the call is redirected to the send function in the aforementioned specific operation function set. This send function first retrieves the plaintext data from the user-space buffer and copies it to the kernel-space buffer. Subsequently, the function calls the cryptographic algorithm service provided by the operating system kernel, such as a symmetric encryption algorithm implementation, to encrypt the plaintext data using the cryptographic parameters stored in step S3, and generates an authentication tag for integrity protection. The encrypted ciphertext data, along with the authentication tag, is encapsulated and sent to the peer via the underlying network protocol stack (e.g., the TCP / IP protocol stack).

[0041] Finally, when the aforementioned socket instance receives ciphertext data sent by the peer, it triggers the receive function in the aforementioned specific operation function set. This function calls the kernel cryptographic algorithm service to decrypt and verify the integrity of the ciphertext data using the stored cryptographic parameters. After successful verification, the plaintext data is returned to the application. When the underlying network protocol stack receives an inbound data packet for this secure socket instance, the data packet is passed to the receive function in the aforementioned specific operation function set. This receive function first retrieves the ciphertext data and authentication tag from the network buffer. Then, it calls the cryptographic algorithm service provided by the operating system kernel to decrypt the ciphertext data using the cryptographic parameters stored in step S3, and simultaneously verifies the integrity of the authentication tag. If the verification result shows that the data has not been tampered with and its source is legitimate, the decrypted plaintext data is copied to the user-space buffer provided by the application. If the verification fails, the data packet is considered invalid and discarded, and an error indication can be returned to the application.

[0042] This embodiment effectively solves the problems of dependency, vulnerability risks, and integration and maintenance costs faced by traditional application-layer secure communication solutions by implementing a secure socket communication mechanism in the operating system kernel. By sinking data encryption / decryption and integrity protection functions to the kernel socket layer, applications do not need to integrate third-party cryptographic libraries, thereby simplifying the system architecture and reducing dependence on external components. In addition, by utilizing the kernel's native cryptographic algorithm services, the execution efficiency and reliability of secure operations are improved, and the data copying overhead between user space and kernel space is reduced. This transparent kernel-level secure communication mechanism provides a lightweight, efficient, and easily integrated solution for resource-constrained computing environments or those with high security and performance requirements.

[0043] In some of the embodiments described above in this application, cryptographic parameters injected by the application are proposed to complete the initialization of the encryption context. However, in its implementation, the parameter injection mechanism lacks standardization and security guarantees. The application may directly inject invalid or malicious parameters, which may lead to encryption operation failure, waste of system resources, or increased risk of security vulnerabilities.

[0044] In response, this application further proposes that in step S3, the application injects cryptographic parameters through the setsockopt system call, the parameter setting function in the customized operation function set intercepts the call, and stores the parameters in the kernel memory structure after validating their validity.

[0045] Specifically, the application injects cryptographic parameters through the 'setsockopt' system call. The 'setsockopt' system call is a standard interface provided by the operating system, allowing applications to configure various socket options at runtime. By utilizing this standard interface to inject cryptographic parameters, this application avoids designing and implementing a completely new, non-standard parameter passing mechanism for secure socket communication, thereby reducing the development and integration difficulty of the application and ensuring the compatibility and stability of parameter passing.

[0046] Furthermore, the parameter setting function in the customized operation function set intercepts the cryptographic parameters of the call. Specifically, in the operating system kernel, each socket type is associated with a set of operation functions to handle various behaviors of that type of socket, such as creation, binding, sending, receiving, and setting options. When an application calls 'setsockopt' on a secure socket instance, the kernel will find and execute the corresponding function in its associated customized operation function set based on the socket type. This application achieves the interception of the 'setsockopt' system call by providing a dedicated parameter setting function in the customized operation function set, thereby enabling fine-grained management and control of cryptographic parameters injected by the application in kernel mode. When registering a new secure socket type, in the 'struct proto_ops' or similar protocol operation structure, the function pointer of the 'setsockopt' operation is pointed to a custom kernel function, which is responsible for handling the option settings specific to secure sockets. Alternatively, a hook function can be registered at a lower level of the network protocol stack to intercept and process calls of specific socket types after the 'setsockopt' system call enters the kernel, but before the standard processing flow.

[0047] Furthermore, the aforementioned parameter validity verification refers to performing a series of checks on the cryptographic parameters injected by the application to ensure that these parameters meet the expected format, length, range, and security requirements. This step is crucial to preventing invalid or malicious parameters from entering the kernel, causing security vulnerabilities, or system instability. Verification can include format and length checks, i.e., checking whether the lengths of parameters such as the key, initialization vector (IV), and additional authentication data (AAD) match the requirements of the selected encryption algorithm (e.g., AES-GCM). For example, the key length for AES-GCM is typically 128 bits, 192 bits, or 256 bits, and the IV length is typically 96 bits. In addition, validity and security checks can be performed, i.e., verifying whether the parameter values ​​are within a reasonable range, for example, avoiding the use of weak keys or known vulnerable parameter combinations. Simultaneously, it checks whether the memory address provided by user space is valid and readable, preventing the kernel from accessing illegal memory regions.

[0048] Furthermore, after the verification is passed, the cryptographic parameters are stored in the kernel memory structure. The cryptographic parameters that have passed the validity verification need to be securely stored in the kernel space and associated with the corresponding secure socket instance so that subsequent encryption and decryption operations can access these parameters quickly and reliably.

[0049] By utilizing the standard system call 'setsockopt' as an interface for injecting cryptographic parameters into applications, a standardized and easily integrated parameter passing mechanism is provided for secure sockets. The parameter setting function in the customized operation function set intercepts this call in kernel space and performs strict validity checks on the injected parameters, effectively preventing invalid or malicious parameters from entering the kernel, thus significantly improving the security and reliability of the encryption context initialization. After successful verification, the cryptographic parameters are securely stored in the kernel memory structure associated with the socket instance, ensuring the isolation and protection of sensitive data in kernel space and providing a stable, efficient, and secure context environment for subsequent encryption and decryption operations. This mechanism, closely integrated with the registration and instance creation of secure socket types (steps S1 and S2), together constructs a complete, secure, and transparent kernel-level secure communication framework from parameter injection to encryption context initialization, effectively solving the problem of the lack of standardization and security guarantees in parameter injection mechanisms, and reducing security risks and system instability caused by parameter errors.

[0050] In some of the schemes mentioned above in this application, cryptographic parameters are proposed to initialize the encryption context. However, in the implementation process, incomplete or insecure parameters may lead to insufficient encryption strength or failure to effectively guarantee data integrity and authentication. For example, the lack of key elements such as initialization vectors or additional authentication data will weaken the randomness and anti-replay attack capability of encryption, or the algorithm may not support authentication mode, thus failing to simultaneously achieve data confidentiality and anti-tampering protection.

[0051] In this regard, this application further proposes that the cryptographic parameters include at least a key for a symmetric encryption algorithm, an initialization vector, and additional authentication data. The symmetric encryption algorithm is an algorithm that supports an authenticated encryption mode. The key for the symmetric encryption algorithm is the core component of the algorithm, and its security directly determines the confidentiality of the encrypted data. It is used to encrypt plaintext data and decrypt ciphertext data. This key can be a secret value pre-negotiated and shared through a secure channel. For example, before establishing a secure communication session, the communicating parties generate and share this key through out-of-band methods or a key exchange protocol based on Public Key Infrastructure (PKI) (such as the Diffie-Hellman key exchange protocol). Alternatively, this key can also be derived from a master key or session seed through a key derivation function (KDF) to ensure that each communication session uses an independent key.

[0052] Furthermore, the initialization vector (IV) is a non-secret random or pseudo-random number used in the encryption process. Its main function is to increase the randomness of the encryption. Even if the same plaintext is encrypted multiple times using the same key, different ciphertexts will be generated each time because a different initialization vector is used, thus effectively resisting replay attacks and pattern leakage attacks. The initialization vector can be a sufficiently long value that is randomly generated during each encryption operation and transmitted to the receiver along with the ciphertext. Alternatively, in some authenticated encryption modes, the initialization vector can also be generated using an incrementing counter value to ensure that it is unique in each encryption operation.

[0053] Furthermore, Attached Authentication Data (AAD) is an important component of the authentication encryption mode. It allows authentication of unencrypted data that requires integrity protection. This data typically includes protocol headers, session identifiers, timestamps, etc., which remain in plaintext during transmission, but their integrity is protected by the authentication encryption algorithm.

[0054] Furthermore, the symmetric encryption algorithm, specifically Authenticated Encryption with Associated Data (AEAD), is an advanced encryption technology that simultaneously provides data confidentiality (preventing eavesdropping), integrity (preventing tampering), and authentication (verifying data origin and non-forgery) within a single algorithmic operation. This mode avoids potential security vulnerabilities associated with traditional "encryption after authentication" or "authentication after encryption" methods, simplifying the design of security protocols.

[0055] Through the above technical solutions, this application can effectively solve the problems of insufficient encryption strength and inability to effectively guarantee data integrity and authentication when implementing secure socket communication in the operating system kernel.

[0056] In some embodiments described above in this application, symmetric encryption algorithms are proposed to support authentication encryption modes. However, in their implementation, indefinite algorithm selection may lead to security risks or low performance efficiency. For example, not specifying the specific algorithm and tag length may introduce potential vulnerabilities or excessive resource consumption. Therefore, this application further proposes the symmetric encryption algorithm, specifically the AES algorithm in GCM mode, with the authentication tag length being 128 bits.

[0057] Specifically, AES (Advanced Encryption Standard) is a widely adopted symmetric block cipher algorithm, renowned for its high security, efficiency, and international standardization. Its block length is 128 bits, and it supports key lengths of 128, 192, or 256 bits. GCM (Galois / Counter Mode) is an authentication encryption mode that provides data confidentiality while also offering data integrity and authentication. GCM combines the parallel processing capabilities of CTR (Counter Mode) with the authentication capabilities of GMAC (Galois Message Authentication Code), enabling high-performance encryption and decryption operations on modern processors. The choice of AES in GCM mode is based on AES's extensive hardware acceleration support and GCM's efficiency and security in providing authentication encryption. Besides GCM, authentication encryption modes include CCM (Counter with CBC-MAC) and EAX (Encrypt-then-Authenticate-then-Translate), but GCM typically offers a better balance between performance and security, especially in hardware environments that support parallel processing. Furthermore, the authentication tag is part of the output of the authentication encryption algorithm and is used to verify the integrity and authenticity of the ciphertext data. The receiver recalculates the authentication tag and compares it with the received tag to determine whether the data has been tampered with or forged. The length of the authentication tag directly affects its resistance to forgery attacks. Shorter tags may be easier for attackers to guess or forge, thus reducing security; while excessively long tags increase data transmission overhead. Setting the authentication tag length to 128 bits is based on cryptographic security practices and performance considerations. At the same time, a 128-bit tag length is also a standard and efficient choice in most network protocols and hardware implementations, avoiding security risks caused by tags that are too short or additional performance burdens caused by tags that are too long.

[0058] The above technical solution explicitly specifies the AES algorithm in GCM mode as the symmetric encryption algorithm and sets the authentication tag length to 128 bits, thereby solving the problem that indefinite algorithm selection may lead to security risks or low performance efficiency. The AES algorithm in GCM mode provides strong data confidentiality and integrity protection. Combined with the 128-bit authentication tag, it ensures a high degree of data security during transmission and effectively resists tampering and forgery attacks.

[0059] In some embodiments described above in this application, a step of encrypting and protecting the integrity of the transmitted data is further proposed, specifically step S4 includes: First, in kernel mode, a kernel buffer larger than the original length is allocated for the plaintext user-space data to be sent, in order to hold the authentication tag generated by encryption.

[0060] This measure aims to reserve sufficient memory for subsequent encryption operations, particularly to accommodate the authentication tag attached by the authentication encryption algorithm when generating ciphertext. For example, memory allocation functions provided by the operating system kernel, such as 'kmalloc' or 'vmalloc', can be used to dynamically calculate and allocate the required memory based on the actual length of the plaintext data to be sent plus the expected authentication tag length. Alternatively, the system can maintain a pre-allocated kernel buffer pool, selecting appropriate buffers based on data size and expanding or reallocating them as needed to optimize memory management efficiency.

[0061] Next, the user-space plaintext data is copied to the kernel-space buffer.

[0062] This operation ensures that sensitive plaintext data is isolated from insecure user space to a protected kernel-mode environment before encryption. Specifically, user-mode data provided by the application can be precisely copied to a previously allocated kernel-mode buffer by calling kernel-provided secure copy functions such as 'copy_from_user'. In some high-performance scenarios, zero-copy techniques can also be considered, allowing the kernel to directly access user-mode memory without actually copying the data, through memory mapping or other methods, but access permissions and security isolation must be ensured.

[0063] Next, the authentication and encryption API provided by the kernel crypto subsystem, i.e. the cryptographic algorithm service, is called to encrypt and authenticate the data in the kernel-mode buffer, generating ciphertext data containing authentication tags.

[0064] This step is central to ensuring data confidentiality and integrity. For example, in the Linux kernel, authentication and encryption interfaces such as 'crypto_aead_encrypt' can be called, passing in stored cryptographic parameters (such as keys, initialization vectors, etc.) and plaintext data from the kernel-mode buffer. The kernel's crypto subsystem then handles the encryption and generation of authentication tags. This subsystem typically leverages hardware acceleration to significantly improve encryption and decryption performance.

[0065] Finally, the kernel's standard network protocol send function is called to transmit the encrypted data containing the authentication tag to the other end through the standard network send interface.

[0066] This step ensures that the encrypted data can be seamlessly integrated into the existing network communication architecture. Specifically, functions such as 'sock_sendmsg' provided by the kernel network protocol stack or the lower-level 'dev_queue_xmit' can be used to submit the encrypted data packet containing the authentication tag to the network interface for transmission. This approach avoids modifications to the underlying network protocol stack, guaranteeing compatibility with existing network infrastructure and transmission efficiency.

[0067] Through the above technical solution, this application effectively solves the problem of efficiently and securely handling data encryption during transmission.

[0068] In some of the embodiments described above in this application, a further step is proposed: the receiving function decrypts and verifies the integrity of the encrypted data. Specifically, step S5 further includes: S501: Calls the receive function of the kernel standard network protocol stack to receive encrypted data packets containing authentication tags from the peer from the network buffer; S502: Allocate a buffer in kernel mode to hold the received ciphertext data, and call the authentication and decryption API provided by the kernel crypto subsystem to decrypt and verify the integrity of the ciphertext data; S503: If the verification passes, the decrypted plaintext data is copied from the kernel-mode buffer back to the buffer provided by the user-mode application; if the verification fails, an error message is returned and the data packet is discarded.

[0069] Specifically, in step S501, the receive function of the kernel's standard network protocol stack is called to receive encrypted data packets containing authentication tags from the peer from the network buffer. This step aims to utilize the low-level network functions built into the operating system kernel to efficiently and reliably acquire data transmitted over the network. Specifically, this receive function can be a function in the Linux kernel such as 'sock_recvmsg' or 'tcp_recvmsg' used for socket data reception; these functions are responsible for reading data from the receive queue or network buffer associated with the socket. Alternatively, in other operating system environments, it can be a receive routine that interacts directly with the network interface card (NIC) driver, passing the data packets received by the hardware to the kernel network protocol stack, thereby ensuring that the data packets are captured as soon as they enter kernel space.

[0070] In step S502, a buffer is allocated in kernel mode to hold the received ciphertext data. The authentication and decryption API provided by the kernel's crypto subsystem is then called to decrypt and verify the integrity of the ciphertext data. The core of this step is to ensure that the ciphertext data is processed in a secure and controlled kernel environment and to utilize the cryptographic services provided by the kernel for efficient and secure decryption and verification. When allocating the buffer in kernel mode, a dynamic memory allocation mechanism can be used to flexibly allocate memory space based on the actual size of the received data packet; alternatively, a fixed-size kernel buffer pool can be pre-allocated, and available buffers can be obtained from it through memory management mechanisms to optimize memory usage efficiency. When calling the authentication and decryption API, the native crypto subsystem API of the operating system kernel can be utilized, such as the Linux kernel's 'crypto_aead_decrypt' function. This function encapsulates the decryption and integrity verification logic of authentication encryption modes (such as GCM), thereby achieving hardware acceleration support for encryption and decryption operations and improving processing efficiency and security.

[0071] In step S503, if the verification passes, the decrypted plaintext data is copied from the kernel-mode buffer back to the buffer provided by the user-mode application; if the verification fails, an error message is returned and the data packet is discarded. This step establishes a strict data integrity control and error handling mechanism, ensuring that only verified legitimate plaintext data can be passed to the application and promptly notifying the application to handle abnormal situations. When decryption and integrity verification are successful, a memory copy function provided by the kernel, such as the Linux kernel's 'copy_to_user', is used to securely copy the plaintext data from the kernel-mode buffer to the buffer specified by the user-mode application, avoiding the risk of user-mode programs directly accessing kernel memory. If the verification fails, an error message is returned to the application through a socket error code or specific socket options, and the encrypted data packet is immediately released or discarded, preventing invalid or malicious data from entering the application, thereby effectively preventing potential security threats and data corruption.

[0072] Through the above technical solution, this application achieves refined control and security assurance of encrypted data processing at the receiving end.

[0073] In some of the solutions described above in this application, a method for implementing secure socket communication in the operating system kernel is proposed to protect the confidentiality and integrity of data transmission. However, in this process, when the application closes the socket instance, the cryptographic parameters stored in the kernel memory may not be cleared in time, resulting in the retention of sensitive information such as keys, which increases the risk of security leakage. At the same time, the encryption algorithm instance and related kernel resources are not released, which may cause memory leaks and waste of system resources.

[0074] To this end, this application further proposes a step S6: when the application closes the socket instance, a release function in the custom operation function set is triggered. This function securely clears the cryptographic parameters stored in kernel memory and releases the encryption algorithm instance and related kernel resources. Specifically, when the application terminates its association with the secure socket instance by calling system calls such as 'close()' or 'shutdown()', the operating system kernel will capture this event. The kernel can identify that the socket instance belongs to a pre-registered secure socket type, thereby initiating the subsequent resource release process. Another implementation is to register a custom resource release callback function to the kernel's socket lifecycle management framework when registering the secure socket type. When the reference count of the socket instance drops to zero, or its lifecycle ends, the callback function will be automatically called, ensuring that cleanup operations are performed promptly when the socket is no longer in use.

[0075] Through the above technical solution, this application implements a method for secure socket communication in the operating system kernel, which can promptly and securely clean up related resources when the application closes the socket instance. Specifically, when the application closes the socket instance, the system triggers a release function in a customized set of operation functions. This release function first securely clears the cryptographic parameters stored in kernel memory, such as keys and initialization vectors. By erasing sensitive data and releasing memory, it effectively prevents this critical information from remaining in memory after the socket is closed, thereby significantly reducing the risk of sensitive information leakage and enhancing system security. Simultaneously, the release function also releases the encryption algorithm instance and related kernel resources, such as the encryption context and memory pool, avoiding memory leaks and system resource waste caused by untimely resource reclamation. This mechanism improves the lifecycle management of secure socket communication, ensuring the effective utilization of system resources and long-term operational stability. Compared with solutions that only provide encrypted communication but lack a comprehensive resource cleanup mechanism, this application further improves the overall security of secure socket communication and the efficiency of system resource management by implementing automated secure cleanup at the kernel level. Example 2: In this embodiment, this application proposes a device for implementing secure socket communication within the operating system kernel. The core innovation of this embodiment lies in moving the secure communication mechanism down from the application layer to the operating system kernel layer. Specifically, this is achieved by integrating a socket type registration module, a parameter management module, an automatic encryption module, an automatic decryption module, and a resource cleanup module. This avoids complex dependencies on application-layer libraries, reduces potential security vulnerabilities, and simplifies the integration and maintenance process. The device includes: The socket type registration module is used to register new secure socket types in the kernel and associate them with a set of customized socket layer operation functions; The parameter management module is used to receive and store application-injected cryptographic parameters and initialize the encryption context through the overridden setsockopt function; The automatic encryption module is used to intercept user-mode plaintext data through a rewritten send function, call the kernel cryptographic algorithm service to complete encryption and integrity protection, and send the ciphertext data into the network protocol stack. The automatic decryption module is used to obtain the ciphertext data from the other end through the rewritten receiving function, call the kernel cryptographic algorithm service to complete the decryption and integrity verification, and return the legitimate plaintext data to the application. The resource cleanup module is used to clear sensitive cryptographic parameters and release kernel encryption resources when the socket is closed.

[0076] Specifically, the socket type registration module registers new secure socket types in the kernel, enabling the operating system to recognize and handle such sockets, thereby bypassing application-layer library dependencies and achieving lightweight communication mechanisms; the parameter management module securely receives and stores cryptographic parameters through the rewritten setsockopt function, ensuring that parameter processing does not depend on external libraries and reducing vulnerability risks; the automatic encryption module intercepts user-space plaintext data when sending data and uses kernel cryptographic algorithm services for encryption and integrity protection, avoiding complex calls to application-layer libraries and reducing integration costs; the automatic decryption module decrypts and verifies received data, ensuring that data is securely returned to the application without application-layer intervention, reducing the operational burden; and the resource cleanup module clears sensitive parameters and releases resources when the socket is closed, preventing information leakage, improving overall security, and optimizing kernel efficiency.

[0077] Through the above technical solutions, this application effectively solves the problems of complex dependencies, potential vulnerability risks, and high integration and maintenance costs associated with application-layer secure communication schemes. Since the secure communication function is implemented directly in the kernel, applications do not need to integrate third-party cryptographic libraries, simplifying the system architecture. The use of native kernel cryptographic services improves the execution efficiency and reliability of secure operations and reduces the data copying overhead between user space and kernel space. This transparent kernel-level secure communication mechanism provides a lightweight, efficient, and easily integrated solution for resource-constrained computing environments or those with high security and performance requirements.

[0078] Example 3: In this embodiment, a computer-readable storage medium is provided, on which a computer program / instruction is stored, which, when executed by a processor, implements a method for implementing secure socket communication in an operating system kernel.

[0079] Through the above technical solution, this application encapsulates the method of implementing secure socket communication in the operating system kernel into a computer program / instruction on a computer-readable storage medium, which is then executed by a processor, effectively solving the problems of complex deployment, poor consistency, and difficult maintenance.

[0080] Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for implementing secure socket communication in an operating system kernel, characterized in that, Includes the following steps: S1: Register a new secure socket type in the socket layer of the operating system kernel, the secure socket type being associated with a customized set of socket layer operation functions; S2: In response to the application's socket creation request, generate a socket instance belonging to the secure socket type and bind it to the customized socket layer operation function set; S3: Receive the cryptographic parameters injected by the application through the socket instance, store the cryptographic parameters in the kernel memory structure associated with the socket, and complete the encryption context initialization; S4: When the application calls the sending interface to send data, the sending function in the customized operation function set is triggered. The sending function intercepts the user-mode plaintext data, calls the kernel cryptographic algorithm service, uses the stored cryptographic parameters to encrypt and protect the integrity of the plaintext data, generates ciphertext data containing authentication tags, and then sends the ciphertext data to the other end through the underlying network protocol stack. S5: When the socket instance receives ciphertext data sent by the peer, it triggers the receive function in the custom operation function set. The function calls the kernel cryptographic algorithm service to decrypt and verify the integrity of the ciphertext data using the stored cryptographic parameters. After the verification is successful, the plaintext data is returned to the application.

2. The method for implementing secure socket communication in an operating system kernel as described in claim 1, characterized in that, In step S3, the application injects cryptographic parameters through the setsockopt system call. The parameter setting function in the custom operation function set intercepts the cryptographic parameters of the call, verifies the validity of the parameters, and stores them in the kernel memory structure.

3. The method for implementing secure socket communication in an operating system kernel as described in claim 2, characterized in that, The cryptographic parameters include at least the key of the symmetric encryption algorithm, the initialization vector, and additional authentication data, wherein the symmetric encryption algorithm is an algorithm that supports authentication encryption mode.

4. The method for implementing secure socket communication in an operating system kernel as described in claim 3, characterized in that, The symmetric encryption algorithm is the AES algorithm in GCM mode, and the authentication tag is 128 bits long.

5. The method for implementing secure socket communication in an operating system kernel as described in claim 1, characterized in that, Step S4 specifically includes: S401: Allocate a kernel buffer in kernel mode that is larger than the original length for the user-space plaintext data to be sent, in order to hold the authentication tag generated by encryption; S402: Copy the user-mode plaintext data to the kernel-mode buffer; S403: Calls the authentication and encryption API provided by the kernel crypto subsystem, i.e., the cryptographic algorithm service, to encrypt and authenticate the data in the kernel-mode buffer, generating ciphertext data containing authentication tags; S404: Calls the send function of the kernel standard network protocol to transmit encrypted data containing the authentication tag to the other end through the standard network send interface.

6. The method for implementing secure socket communication in an operating system kernel as described in claim 1, characterized in that, Step S5 specifically includes: S501: Calls the receive function of the kernel standard network protocol stack to receive encrypted data packets containing authentication tags from the peer from the network buffer; S502: Allocate a buffer in kernel mode to hold the received ciphertext data, and call the authentication and decryption API provided by the kernel crypto subsystem to decrypt and verify the integrity of the ciphertext data; S503: If the verification passes, the decrypted plaintext data is copied from the kernel-mode buffer back to the buffer provided by the user-mode application; if the verification fails, an error message is returned and the data packet is discarded.

7. A method for implementing secure socket communication in an operating system kernel as described in claim 1, characterized in that, It also includes step S6: when the application closes the socket instance, it triggers the release function in the custom operation function set, which securely clears the cryptographic parameters stored in the kernel memory and releases the encryption algorithm instance and related kernel resources.

8. An apparatus for implementing secure socket communication in an operating system kernel, characterized in that, include: The socket type registration module is used to register new secure socket types in the kernel and associate them with a set of customized socket layer operation functions; The parameter management module is used to receive and store application-injected cryptographic parameters and initialize the encryption context through the overridden setsockopt function; The automatic encryption module is used to intercept user-mode plaintext data through a rewritten send function, call the kernel cryptographic algorithm service to complete encryption and integrity protection, and send the ciphertext data into the network protocol stack. The automatic decryption module is used to obtain the ciphertext data from the other end through the rewritten receiving function, call the kernel cryptographic algorithm service to complete the decryption and integrity verification, and return the legitimate plaintext data to the application. The resource cleanup module is used to clear sensitive cryptographic parameters and release kernel encryption resources when the socket is closed.

9. The apparatus for implementing secure socket communication in an operating system kernel as described in claim 8, characterized in that, Both the automatic encryption module and the automatic decryption module call the native crypto subsystem API of the operating system kernel to achieve hardware acceleration support for encryption and decryption operations.

10. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement a method for implementing secure socket communication in an operating system kernel as described in any one of claims 1 to 7.

Images