A container identity trusted key management method based on a universal computing architecture

Abstract

A container identity trusted key management method based on a universal computing architecture, specifically comprising the following steps: step 1, generating a KDC management container and a client container on the basis of a basic container image; step 2, operating in the KDC container constructed in step 1, constructing a domain and configuring the KDC container and starting a secure channel; step 3, generating relevant asymmetric public keys and private keys in the KDC container, and applying for a certificate based on the private key; step 4, signing the certificate by using TPM hardware to generate a signature file, and transmitting the signature file to the client container; step 5, verifying the signature by using an upper layer protocol by the client container; step 6, parsing the received certificate by the client container, and encrypting and negotiating a session key, and transmitting the generated encrypted file back to the KDC container; step 7, decrypting the session key by the KDC container with the private key; and step 8, transmitting relevant content by using the session key.

Description

Technical Field

[0001] This invention belongs to the field of cloud computing technology keys, specifically relating to a container identity trusted key management method based on a generic computing architecture. Background Technology

[0002] Cloud computing is an internet-based computing model that provides computing resources, storage space, and application services over a network. Based on virtualization technology, cloud computing divides physical computing resources (such as servers, storage, and networks) into multiple virtual resources. This allows multiple users to share the same set of physical resources, improving hardware utilization and resource flexibility. Cloud computing provides highly reliable and secure measures, including data backup, disaster recovery, and secure access control.

[0003] Generic computing architecture is a novel distributed cloud computing architecture based on Docker, improving upon traditional cloud computing. This architecture, centered on containers, achieves fine-grained application partitioning and loosely coupled service architecture. Compared to traditional cloud computing architectures, generic computing architecture replaces multi-process collaboration with multi-container collaboration. This architecture effectively decouples the relationships between containers with different functions, providing a more granular application partitioning. Simultaneously, it ensures data security, emphasizing inherent security.

[0004] Docker containers are a technology developed by Google using the Go programming language and leveraging Linux kernel cgroups and namespaces for process encapsulation and isolation. This technology significantly simplifies creation and maintenance, making Docker more lightweight and faster than virtual machine technology. Docker offers several key advantages: first, it utilizes system resources more efficiently; second, it has faster startup times; third, it provides a consistent runtime environment and is easier to maintain and scale; and finally, it supports continuous delivery and deployment and is easy to migrate.

[0005] A Trusted Platform Module (TPM) is a hardware security module integrated as a chip into a computer motherboard or other device, designed to provide security and data protection for computer systems. It supports robust encryption algorithms and key management functions, capable of generating, storing, and managing symmetric and asymmetric keys. This allows the TPM to encrypt and decrypt data stored in the computer system, ensuring data confidentiality. In addition to encryption, the TPM provides digital signature and authentication functions to verify the authenticity and integrity of software. The TPM can generate and verify digital signatures to ensure that the software has not been tampered with or replaced by malware. This function is crucial for preventing the execution of malware and ensuring system security. By using the TPM's digital signature and authentication functions, the execution of malware and the injection of malicious code can be effectively prevented, thus ensuring system integrity. This hardware-level security protection makes the TPM more reliable than software-level security, preventing unauthorized access and data leakage.

[0006] Kerberos is a network authentication protocol used for secure authentication and authorization management in computer networks. Kerberos uses symmetric-key cryptography for authentication, known as ticket exchange. It uses a pre-shared key to encrypt and decrypt tickets, ensuring the security of the authentication process. After a user logs in, the Kerberos server generates an encrypted ticket for them to access other network services. Kerberos employs a centralized identity management model. It uses a trusted third-party authentication server, called the Key Distribution Center (KDC), to issue tickets and verify user identities. The KDC consists of two parts: a Ticket Granting Ticket (TGS) server and an Authentication Server (AS) server, specifically used to authenticate client identities and issue Ticket Grant Tickets (TGTs) for accessing the TGS. This centralized management simplifies the complexity of identity management and provides a trusted entity to handle the authentication process.

[0007] In a robust computing architecture, a user's business is broken down into multiple independent, finely categorized services, each executed by a separate container. Therefore, to fulfill the user's business requirements, multiple containers responsible for different functions need to work collaboratively. Trusted interaction between containers becomes essential, typically achieved through session keys; however, Docker itself does not provide this type of security authentication. Container interactions can be frequent or infrequent. If authentication is achieved during the initial interaction, it becomes difficult for a container to verify the security of other containers when they frequently access it, given that the container can only confirm the security of the initial interaction. Furthermore, when significant time intervals exist, ensuring that containers confirm the other's identity from the previous interaction is challenging. The root of these difficulties lies in the low security level of the Docker container's execution environment, making it vulnerable to file theft attacks during transmission, as there is no trusted security guarantee for files during transfer. Therefore, a method is needed to protect and securely encrypt container identity and container key interactions. Summary of the Invention

[0008] To address the issues of identity leakage and key communication difficulties arising from key negotiation between Docker containers in a generic computing architecture due to the lack of trusted hardware encryption during the negotiation process, this invention provides a container identity trusted key management method based on a generic computing architecture. This method solves the problem of difficulty in trusted identity authentication between containers during initial interaction within a business application, particularly in insecure environments, and provides security guarantees for key certificate transmission. Furthermore, it utilizes Kerberos technology to design a third-party identity verification management container. By distributing identity authentication and related credentials, the method ensures trusted authentication of containers and recognizes their identity as a trusted container within the generic computing architecture for a specified period, further enhancing the reliability of containers and the security of data within the generic computing architecture.

[0009] To achieve the above objectives, the present invention adopts the following technical solution:

[0010] A container identity trusted key management method based on a generic computing architecture includes at least one KDC container responsible for account generation, key distribution, and certificate signing, and at least one storage host for storing the data of the KDC container. The KDC container requires at least two client containers to complete ticket interaction for Kerberos services. Both client containers can perform account entry, identity authentication, service request, and interaction authentication operations with the KDC container. The KDC container that monitors the client container accounts plays a supervisory role over the client containers that make interaction requests using Kerberos technology in the entire generic computing. The client container accounts are entered into the database of the KDC container, and the storage host stores the data of the KDC container.

[0011] Specifically, the following steps are included:

[0012] Step 1: Based on the base container image, define the domain image responsible for authentication and Kerberos domain construction. This includes installing tools to establish the entire Kerberos domain and related trusted hardware TPM calls and secure transport channels, generating the KDC container responsible for authentication and domain construction, and generating client containers that need to run in the Kerberos domain.

[0013] Step 2: Perform operations in the KDC container built in Step 1, install the tools required by Kerberos technology, build a Kerberos technology domain, set your own IP address as the administrator of the entire domain during the construction process, and start the secure channel service.

[0014] Step 3: Generate the relevant asymmetric public and private keys in the KDC container, and apply for a certificate based on the private key. The KDC container performs a self-signing operation to generate a certificate application request .csr file, and then uses the .csr file to use the operation commands of the upper-layer protocol OpenSSL to generate a .crt certificate file.

[0015] Step 4: Use TPM hardware to sign the .crt certificate file and generate a signature file. Then, use a regular file transfer framework to transfer the signature file and the .crt certificate file to the client container that needs to exchange keys.

[0016] Step 5: The client container uses the upper-layer protocol to verify the signature file and the .crt certificate file;

[0017] Step 6: After verifying the certificate, the client container uses the parsed public key to encrypt the agreed session key and then transmits the generated encrypted file back to the KDC container.

[0018] Step 7: After receiving the encrypted file generated in step 6, the KDC container uses the private key generated in step 3 to decrypt the encrypted file encrypted with the public key, and obtains the session key K agreed upon by the client container.

[0019] Step 8: After obtaining the session key K, the client container transmits its username and password to the KDC container. The session key generated by the client container for subsequent communication will also be stored in the KDC container for convenient Kerberos service operations. The KDC container stores the transmitted client container username and password in its database, creates the corresponding account for the client container in the Kerberos domain, grants permissions, and confirms that the client container has joined the Kerberos domain. This concludes the key interaction operation based on trusted TPM hardware.

[0020] Furthermore, in step 4, the KDC container can perform trusted encryption based on TPM on the transmitted .crt certificate file, and perform trusted signing operation on the .crt certificate file based on hardware encryption. If the attacker cannot obtain the key for encryption based on the physical machine, they cannot crack the encrypted file during the transmission process, ensuring that the recipient can obtain a secure file.

[0021] Furthermore, the specific implementation of step 5 is as follows:

[0022] After the client container obtains the transmitted signature file and .crt certificate file through the lightweight transport framework, it needs to call the corresponding upper-layer protocol OpenSSL interface to verify the signature file and the transmitted .crt certificate file based on TPM trusted hardware. If the .crt certificate file has been tampered with, the verification will fail, and the client container can choose to re-initiate the request, asking the KDC container to provide the corresponding .crt certificate file and signature file again. If the .crt certificate file has not been tampered with, it will be displayed as a successful signature verification in the client container, and the client container and the KDC container have completed a TPM trusted hardware-based encrypted certificate transmission.

[0023] Furthermore, the specific implementation of step 6 is as follows:

[0024] After the certificate is verified to be correct, the client container parses the received .crt certificate file and obtains the public key of the KDC container in the .crt certificate file. The client container sets a session key for this session, assuming it is K. K is used as the agreed session key to encrypt the communication between the KDC container and the client container. The client container uses the parsed public key to encrypt the agreed session key and then transmits the generated encrypted file back to the KDC container.

[0025] Compared with the prior art, the beneficial effects of the present invention are:

[0026] This invention discloses a container identity trusted key management method based on a generic computing architecture. It is an improvement and optimization for key negotiation and interaction in the new cloud computing architecture of generic computing. It enables hardware-protected key transmission security in generic computing architectures. Using a management container to authenticate and manage containers in the cluster helps operators manage container identities, solving the potential identity leakage problem caused by inconsistent authentication and decentralized identity management in large clusters. Key signing based on trusted hardware further guarantees the trustworthiness and authority of the management container. The management container can perform operations such as deleting accounts from untrusted containers. These operations are encrypted by the TPM service before being transmitted to other containers, ensuring that other containers will not respond to requests from that container in the future, thus increasing the security of container interactions.

[0027] The main technical problem addressed is that, compared to traditional cloud computing, where Kerberos technology is used for account entry in management containers, ensuring the security of the entire transmission process is crucial to prevent account theft. Attackers can exploit this vulnerability in various ways, such as attacking the secure channel to prevent users from using it, attacking the transmitted file itself to deliver a different file, or sending files at high frequency to make it impossible for users to confirm which file they initially intended to receive. Using TPM encryption, which encrypts the data multiple times, increases the difficulty of cracking the encryption, making it impossible for attackers to replicate the same signature file. Users only need to check for the signature upon receiving a file. Furthermore, TPM encryption, being hardware-based, allows container interactions to establish trusted communication even in risky environments. After obtaining the interaction key, trusted transmission over a secure channel can be performed using the agreed-upon account password, thus solving the secure channel transmission problem from a hardware perspective. Attached Figure Description

[0028] Figure 1 This is an implementation flowchart of a container identity trusted key management method based on a generic computing architecture according to the present invention.

[0029] Figure 2 This is an implementation architecture diagram of a generic computing architecture that utilizes Kerberos technology to complete identity authentication. Detailed Implementation

[0030] The following detailed description, in conjunction with the accompanying drawings and specific implementation methods, provides a further explanation of the container trusted key management method based on a generic computing architecture according to the present invention.

[0031] A container identity trusted key management method based on a generic computing architecture includes at least one KDC container responsible for account generation, key distribution, and certificate signing, and at least one storage host for storing the data of the KDC container. The KDC container requires at least two client containers to complete ticket interaction for Kerberos services. Both client containers can perform account entry, identity authentication, service request, and interaction authentication operations with the KDC container. The KDC container that monitors the client container accounts plays a supervisory role over the client containers that make interaction requests using Kerberos technology in the entire generic computing. The client container accounts are entered into the database of the KDC container, and the storage host stores the data of the KDC container.

[0032] like Figure 1 As shown, a container identity trusted key management method based on a generic computing architecture specifically includes the following steps:

[0033] Step 1: Based on the base container image, define the domain image responsible for authentication and Kerberos domain construction. This includes installing tools to establish the entire Kerberos domain and related trusted hardware TPM calls and secure transport channels, generating the KDC container responsible for authentication and domain construction, and generating client containers that need to run in the Kerberos domain.

[0034] Step 2: Perform operations in the KDC container built in Step 1, install the tools required by Kerberos technology, build a Kerberos technology domain, set your own IP address as the administrator of the entire domain during the construction process, and start the secure channel service.

[0035] Step 3: Generate the relevant asymmetric public and private keys in the KDC container, and apply for a certificate based on the private key. The KDC container performs a self-signing operation to generate a certificate application request .csr file, and then uses the .csr file to use the operation commands of the upper-layer protocol OpenSSL to generate a .crt certificate file.

[0036] Step 4: Use TPM hardware to sign the .crt certificate file and generate a signature file. Then, use a standard file transfer framework to transmit the signature file and the .crt certificate file to the client container that needs to exchange keys. The specific steps are as follows:

[0037] The KDC container can perform trusted encryption based on TPM on the transmitted .crt certificate file. It performs trusted signing operation on the .crt certificate file based on hardware encryption. Attackers cannot obtain the encryption key based on the physical machine and therefore cannot crack the encrypted file during the transmission process, ensuring that the recipient can obtain a secure file.

[0038] Step 5: After the client container obtains the transmitted signature file and .crt certificate file through the lightweight transport framework, it needs to call the corresponding upper-layer protocol OpenSSL interface to verify the signature file and the transmitted .crt certificate file based on TPM trusted hardware. If the .crt certificate file has been tampered with, the verification will fail, and the client container can choose to re-initiate the request, asking the KDC container to provide the corresponding .crt certificate file and signature file again. If the .crt certificate file has not been tampered with, it will be displayed as a successful signature verification in the client container. The client container and the KDC container have completed a TPM trusted hardware-based encrypted certificate transmission.

[0039] Step 6: After verifying the certificate, the client container uses the parsed public key to encrypt the agreed session key, and then transmits the generated encrypted file back to the KDC container. The specific steps are as follows:

[0040] After the certificate is verified to be correct, the client container parses the received .crt certificate file and obtains the public key of the KDC container in the .crt certificate file. The client container sets a session key for this session, assuming it is K. K is used as the agreed session key to encrypt the communication between the KDC container and the client container. The client container uses the parsed public key to encrypt the agreed session key and transmits the generated encrypted file back to the KDC container.

[0041] Step 7: After receiving the encrypted file generated in step 6, the KDC container uses the private key generated in step 3 to decrypt the encrypted file encrypted with the public key, and obtains the session key K agreed upon by the client container.

[0042] Step 8: After obtaining the session key K, the client container transmits its username and password to the KDC container. The session key generated by the client container for subsequent communication will also be stored in the KDC container for convenient Kerberos service operations. The KDC container stores the transmitted client container username and password in its database, creates the corresponding account for the client container in the Kerberos domain, grants permissions, and confirms that the client container has joined the Kerberos domain. This concludes the key interaction operation based on trusted TPM hardware.

[0043] This invention proposes to provide secure encryption services for file transfer during key negotiation by using trusted host hardware (TPM). This approach mainly solves the problems of identity leakage and key theft caused by potential attackers exploiting file attacks on the transmission key during transmission, which are common in traditional container interactions that rely solely on upper-layer protocols and transmission channels for data interaction and communication. It also addresses the data interaction problems between containers in generalized computing, which require collaboration among multiple containers. Furthermore, it addresses the management issues of modifying or deleting the identity of a container when it is attacked or contains malicious code, rendering the container identity untrustworthy.

[0044] The container identity trusted key management method based on the generic computing architecture combines host TPM hardware to encrypt and sign transmitted files. It uses the Kerberos protocol for key storage and identity verification within the KDC container. This solves the key leakage and identity verification problems caused by potential attacks on transmitted files during traditional key negotiation. By utilizing secure channels and trusted hardware, it enhances communication security between containers under the generic computing architecture, ensuring that all key transmissions are handled through trusted hardware. This guarantees that after encrypting transmitted files using TPM trusted hardware, containers under the generic computing architecture can provide hardware-based trusted transmission, thus ensuring that files are not tampered with during the session.

[0045] like Figure 2 The diagram illustrates an architecture within a Kerberos domain based on a generalized computing architecture, where a KDC container authenticates a client container and facilitates the client container's access to the server for ticket issuance. In the initial service request, the client container requests service from the Authentication Server (AS) portion of the KDC container. This request is sent in plaintext, containing the client container's username, IP address, and timestamp. Upon receiving the request, the AS quickly searches its database for an account with that IP address and username. If found, it encrypts a file called a TGT using the key stored in the KDC container for that username. This file includes the current timestamp, the client container's and the Ticket Granting Server (TGS)'s session key (Client-TGS_Session Key, CT_SK), and the TGT's expiration time. This is one part of the file. The other part is encrypted by the KDC container using its own key; this part is used by the KDC container for verification. The TGT file is then sent back to the client container. Once the client container obtains the TGT file, it can decrypt the first part of the TGT file using its own key, namely the timestamp, the client container, and the TGS session key CT_SK. The other part remains unchanged as it cannot be decrypted.

[0046] During the second communication, the client container has obtained the CT_SK key required for the TGS session. Using this key, it encrypts the client container's username, IP address, and timestamp, then writes the IP address of the server container it wants to access in plaintext. It also transmits the TGT portion, which could not be deciphered in the first communication, to the TGS. In this step, because the client container can decipher the timestamp provided by the AS, if the timestamp is too far removed from the current communication time, the client container can consider the TGT document issued by the AS untrustworthy and request a new one. The client container can then re-request the plaintext version. After obtaining the encrypted file, TGS first analyzes the plaintext portion. TGS first analyzes the server container in the plaintext. If the server container IP requested in the plaintext is currently being accessed by other client containers and cannot provide service, the communication ends because the server container cannot provide service. If the server container can provide service, TGS uses the CT_SK session key to parse the file, and then uses its own key to decrypt the TGT portion that the client container could not decrypt in the first communication. The encrypted usernames in the two portions are compared. If they are the same username, TGS considers the containers interacting in the first and second communications to be the same client container, ensuring that the identity has not been stolen. Since the server container has already stored its key in the KDC container during the TPM encryption key exchange between the server container and the KDC container, the KDC container can use the server container's key to encrypt a ticket (SeverTicket, ST) for the client container. This ST includes the client container's name, IP address, the IP address accessing the server container, the ST's validity period, a timestamp, and the client-server session key (CS_SK). At this point, the KDC container also needs to use the session key CT_SK from the first communication to encrypt CS_SK, timestamp, and ST validity period, and then send the file to the client container.

[0047] In the third communication, the client container receives the file from the KDC container. It uses the CT_SK from the first communication to parse the second part of the file transmitted in the second communication. At this point, the client container obtains the CS_SK, timestamp, and ST validity period. After verifying that the ST validity period and timestamp meet the communication requirements, the client container uses the parsed CS_SK session key to encrypt the client container's username, IP address, timestamp, and ST validity period, and transmits this along with the ST file received in the second communication to the server container. Upon receiving this ticket, the server container uses its own key to decrypt the portion of the ST encrypted with its key, obtaining the session key CS_SK. It then uses CS_SK to decrypt the file sent by the client container. The two parts of the file are compared. If the username and IP address parsed from both parts match, the server container considers the client container requesting authentication from the KDC container and the client container requesting service access from the server container to be the same user. The authentication is complete. At this point, the client container and the server container complete trusted authentication in the Kerberos domain and begin relevant service interactions.

[0048] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A container identity trusted key management method based on a generic computing architecture, characterized in that, It includes at least one KDC container responsible for account generation, key distribution, and certificate signing, and at least one storage host for storing the data of the KDC container. The KDC container requires at least two client containers to complete the ticket interaction for Kerberos services. Both client containers can perform account entry, identity authentication, service request, and interactive authentication operations with the KDC container. The KDC container that monitors the client container accounts plays a supervisory role over the client containers that make interactive requests using Kerberos technology for the entire general-purpose computing. The client container accounts are entered into the database of the KDC container, and the storage host stores the data of the KDC container. Specifically, the following steps are included: Step 1: Based on the base container image, define the domain image responsible for authentication and Kerberos domain construction. This includes installing tools to establish the entire Kerberos domain and related trusted hardware TPM calls and secure transport channels, generating the KDC container responsible for authentication and domain construction, and generating client containers that need to run in the Kerberos domain. Step 2: Perform operations in the KDC container built in Step 1, install the tools required by Kerberos technology, build a Kerberos technology domain, set your own IP address as the administrator of the entire domain during the construction process, and start the secure channel service. Step 3: Generate the relevant asymmetric public and private keys in the KDC container, and apply for a certificate based on the private key. The KDC container performs a self-signing operation to generate a certificate application request .csr file, and then uses the .csr file to use the operation commands of the upper-layer protocol OpenSSL to generate a .crt certificate file. Step 4: Use TPM hardware to sign the .crt certificate file and generate a signature file. Then, use a regular file transfer framework to transfer the signature file and the .crt certificate file to the client container that needs to exchange keys. Step 5: The client container uses the upper-layer protocol to verify the signature file and the .crt certificate file; Step 6: After verifying the certificate, the client container uses the parsed public key to encrypt the agreed session key and then transmits the generated encrypted file back to the KDC container. Step 7: After receiving the encrypted file generated in step 6, the KDC container uses the private key generated in step 3 to decrypt the encrypted file encrypted with the public key, and obtains the session key K agreed upon by the client container. Step 8: After obtaining the session key K, the client container transmits its username and password to the KDC container. The session key generated by the client container for subsequent communication will also be stored in the KDC container for convenient Kerberos service operations. The KDC container stores the transmitted client container username and password in its database, creates the corresponding account for the client container in the Kerberos domain, grants permissions, and confirms that the client container has joined the Kerberos domain. This concludes the key interaction operation based on trusted TPM hardware.

2. The container identity trusted key management method based on a generic computing architecture according to claim 1, characterized in that, In step 4, the KDC container can perform trusted encryption based on TPM on the transmitted .crt certificate file. It performs trusted signing operation on the .crt certificate file based on hardware encryption. If the attacker cannot obtain the key for encryption based on the physical machine, they cannot crack the encrypted file during the transmission process, ensuring that the recipient can obtain a secure file.

3. The container identity trusted key management method based on a generic computing architecture according to claim 1, characterized in that, The specific steps of step 5 are as follows: After the client container obtains the transmitted signature file and .crt certificate file through the lightweight transport framework, it needs to call the corresponding upper-layer protocol OpenSSL interface to verify the signature file and the transmitted .crt certificate file based on TPM trusted hardware. If the .crt certificate file has been tampered with, the verification will fail. The client container can choose to re-initiate the request and ask the KDC container to provide the corresponding .crt certificate file and signature file again. If the .crt certificate file has not been tampered with, and the signature verification is shown as correct in the client container, the client container and the KDC container have completed a cryptographic certificate transfer based on TPM trusted hardware.

4. The container identity trusted key management method based on a generic computing architecture according to claim 1, characterized in that, The specific steps of step 6 are as follows: After the certificate is verified to be correct, the client container parses the received .crt certificate file and obtains the public key of the KDC container in the .crt certificate file. The client container sets a session key for this session, assuming it is K. K is used as the agreed session key to encrypt the communication between the KDC container and the client container. The client container uses the parsed public key to encrypt the agreed session key and then transmits the generated encrypted file back to the KDC container.

Images