Cloud computing platform authentication security local area virtual network construction method

Abstract

According to the cloud computing platform authentication security local area virtual network construction method, the local area virtual network is constructed based on a trusted authentication platform and a message secret key code algorithm for security vulnerabilities of the cloud platform local area virtual network, and firstly, the trusted computing technology is applied to identity verification between cloud platform virtual network devices; and secondly, the identity authentication scheme of the credible authentication platform is introduced into the key negotiation process, so that the key negotiation is established on the basis that the platform identity is confirmed to be credible, and the security and reliability of the key negotiation process are ensured. A key negotiation process is established in a message key code address learning stage, so that the OVS can use a message key code identity verification scheme to verify the identity of the VM when communicating with the VM for the first time; and thirdly, an identity verification scheme realized by utilizing a message secret key code algorithm enables the OVS to verify the identity of the sending end VM of each received data frame, so that the real-time verification of the VM identity is realized, the cloud platform local virtual network reaches a higher security level, and the efficiency is higher.

Description

Technical Field

[0001] The present application relates to a method for constructing a secure local area virtual network for a cloud platform, and more particularly to a method for constructing a secure local area virtual network for a cloud computing platform authentication, and belongs to the technical field of cloud platform local area network construction. Background Art

[0002] At present, virtual networks based on virtualization technology are developing very rapidly and have become an important part of cloud platforms and data centers. Cloud platforms are the carriers for cloud computing. They are a collection of various resources including computing, storage and networks. Cloud platforms use virtualization technology to reuse physical devices, greatly improving the utilization rate of devices. At the same time, resources are provided to the outside world as services, reducing the user's investment costs.

[0003] With the continuous development of cloud computing, the concept of Network as a Service (NaaS) has gradually matured, and virtual networks, as a key technology for realizing NaaS, have also been widely used. Compared with traditional networks, virtual network technology has unique advantages in building complex network environments and saving resources. In addition, network function virtualization and software-defined networks based on virtual network technology also have subversive and innovative significance for traditional network models.

[0004] At present, the most widely used scenarios for virtual networks are cloud platforms and data centers. In mainstream cloud platforms, the virtual network technology used to isolate tenant networks is to divide virtual local area networks. However, there are inevitable security issues in dividing local virtual networks in cloud platforms. Compared with traditional networks, virtual networks cannot use hardware devices to improve their security. Secondly, because they are in a virtual environment, such as message key code addresses and IP addresses, as well as various virtual network devices and tenant identities, are easy to forge. As a result, the virtual network environment in the cloud platform is subject to malicious attacks, which in turn affects the entire cloud platform. Therefore, in order to ensure the security of the virtual network in the cloud platform and ensure the normal operation of the entire cloud platform, it is necessary to take measures to make up for the security vulnerabilities caused by dividing local virtual networks in the cloud platform.

[0005] Although academia and the business community have conducted extensive research on virtual networks and their security issues in cloud platforms, there is almost no research on the local virtual network partitioning technology that isolates tenant networks in cloud platforms. It is urgent to study the security vulnerabilities in the local virtual network partitioning technology in cloud platforms and design solutions to fill these vulnerabilities.

[0006] The problems that need to be solved in the construction of cloud platform secure local virtual network in the prior art and the key technical difficulties of this application include: (1) The existing virtual network cannot use hardware devices to improve its security. Since it is in a virtual environment, the message key code address and IP address as well as various virtual network devices and tenant identities can be easily forged, causing the virtual network environment in the cloud platform to be attacked maliciously, thereby affecting the entire cloud platform. There is a lack of measures to make up for the security loopholes caused by dividing the local virtual network in the cloud platform. The security of the virtual network in the cloud platform cannot be guaranteed, and thus the normal operation of the entire cloud platform cannot be ensured. There is almost no research in the existing technology on the local virtual network division technology for isolating tenant networks in the cloud platform. It is urgent to take the security loopholes existing in the local virtual network division technology in the cloud platform as the research object and design solutions to make up for this loophole.

[0007] (2) The existing technology of dividing local virtual networks in cloud platforms has inevitable security problems, but there is no solution to make up for the security loopholes in the local virtual network division technology in the cloud platform. There is a lack of key negotiation based on a trusted authentication platform and identity authentication based on a message key code algorithm. The key negotiation process cannot be established on the basis of platform identity authentication using a trusted authentication platform, and cannot be used for identity authentication of both parties in the key negotiation process in the subsequent communication process. The local virtual network environment is easily attacked by disguised malicious virtual machines. It is impossible to prevent malicious virtual machines from attacking the local virtual network environment. The cloud platform has great security risks by isolating tenant networks by dividing local virtual networks. The security level of the virtual network in the cloud platform is low, which is also easy to reduce the service efficiency of the cloud platform.

[0008] (3) There is no logic in the local virtual network to determine whether the identity of the access end is legitimate, that is, the identity of the access end is not verified, and the security loopholes existing in the local virtual network division in the cloud platform cannot be made up. In the local virtual network environment divided by the cloud platform, there is a lack of an identity authentication mechanism. When the virtual host accesses the local virtual network, it is impossible to authenticate the identity based on the data packets it sends and process all the messages it sends. In the process of virtual host communication in the local virtual network, there is a lack of identity authentication for each message, and it is impossible to determine whether the identity of the communication host in the local virtual network is credible at all times. Most of the verification mechanisms added to the local virtual network by the existing technology seriously affect its communication efficiency. The key negotiation method of the existing technology cannot meet the identity authentication requirements. In addition, the two parties in the key negotiation are not ordinary users, but virtual hosts in the cloud platform. The key negotiation process cannot be established on the basis of realizing the identity authentication of the negotiation parties on the platform with a trusted authentication platform. There is a lack of an efficient key storage method and search method to shorten the key search time. The long-term use of the same key brings the risk of key leakage. Summary of the invention

[0009] In order to make up for the security loopholes in the local virtual network division technology in the cloud platform, this application establishes a local virtual network construction based on a virtual trusted platform module and a message key code algorithm. The key negotiation based on the trusted authentication platform aims to establish the key negotiation process on the basis of platform identity authentication using a trusted authentication platform, while the identity authentication based on the message key code algorithm is used for the identity authentication of both parties in the key negotiation in the subsequent communication process to prevent the local virtual network environment from being attacked by disguised malicious virtual machines. After testing, it is shown that this solution can indeed prevent attacks launched by malicious virtual machines on the local virtual network environment, and make up for the security risks brought about by the cloud platform isolating tenant networks by dividing local virtual networks. The local virtual network construction solution based on the trusted authentication platform and the message key code algorithm combines the advantages of the trusted authentication platform platform identity authentication mechanism and the high efficiency of the message key code algorithm, improving the security level of the virtual network in the cloud platform without reducing the service efficiency of the cloud platform.

[0010] In order to achieve the above technical effects, the technical solutions adopted in this application are as follows: The method for constructing a local virtual network with authentication security on a cloud computing platform is based on a virtual trusted platform module and a message secret key algorithm to construct a local virtual network structure, which includes two parts: key negotiation based on a trusted authentication platform establishes the key negotiation process on the basis of platform identity authentication implemented by a trusted authentication platform, and identity authentication based on a message secret key algorithm is used for identity authentication of both parties in the key negotiation in the subsequent communication process, so as to prevent the local virtual network environment from being attacked by disguised malicious virtual machines; A. Key negotiation based on a trusted authentication platform: Establish a platform identity authentication mechanism based on a trusted authentication platform to determine the identity of the VM. The identity authentication based on the message key code algorithm must be completed before the first communication between the VM and OVS begins. The key negotiation and the identity authentication mechanism based on the trusted authentication platform are designed to be implemented in the message key code address learning phase of the VM. Specifically, it includes reconstructing the format of the data packet used in the key negotiation process, the processing logic of the data packet exchange, and the algorithm used for the key exchange. B. Authentication based on message key algorithm: It is based on secure key negotiation. When key negotiation is completed, a message key calculation module and an authentication module are constructed. The message key calculation module includes a data frame processing method, a specific message key algorithm, and a method for attaching a message key value to a data frame. The authentication module includes a method for OVS to process data frames with message key values ​​attached, as well as a method for receiving and discarding data frames. It is extended to all virtual network devices in the cloud platform to improve the security of virtual networks in the cloud platform. C uses the OpenStack cloud platform to build a corresponding secure local area virtual network, and adds a key negotiation module, a message key code calculation module and an identity authentication module to the secure local area virtual network to implement the local area virtual network solution, thereby making up for the security vulnerabilities caused by dividing the local area virtual network in the cloud platform, resisting the attack of malicious VMs in the local area virtual network, and improving the security of the network in the cloud platform.

[0011] Preferably, the local area virtual network construction method: based on the key negotiation of the trusted authentication platform, the key negotiation is completed at the data link layer using the ARP protocol, and the key negotiation process is established on the basis of realizing the identity authentication of the negotiation parties through the trusted authentication platform; In addition, a database is built to save keys, and the keys are encrypted and stored using a trusted authentication platform. When OVS verifies the identity of the VM, a key retrieval process is set up to find the key in the database based on the characteristic information of the VM. An efficient key storage and search method is established to shorten the key search time. The shared key between the VM and OVS is set to be updated regularly to further improve the confidentiality of the key to prevent the risk of key leakage caused by long-term use of the same key. This application makes up for the security vulnerabilities caused by dividing local virtual networks in the cloud platform by constructing a local virtual network based on a trusted authentication platform and a message key code algorithm. The application includes two parts: one is key negotiation based on a trusted authentication platform, including identity authentication, policy negotiation, key generation and key management; the other is identity authentication based on a message key code algorithm.

[0012] Preferably, the overall architecture of key agreement based on the trusted authentication platform is: (1) Use a trusted authentication platform to authenticate the identities of both parties in key negotiation; (2) If authentication succeeds, the two parties enter the policy negotiation phase and exchange cryptographic algorithms and hash functions supported by both parties. If authentication fails, the two parties stop and report an error. (3) The two parties in negotiation exchange the relevant parameters for generating keys and each generates a shared key. After the key is generated, it is encrypted and stored using a trusted authentication platform.

[0013] Preferably, the detailed scheme of key negotiation based on the trusted authentication platform: the key negotiation based on the trusted authentication platform requires that the negotiation process is implemented with the underlying protocol and is completed before the first communication between the negotiating parties, the key negotiation is completed in the data link layer, and a key negotiation data packet is established based on the ARP message to complete the key negotiation process; The key negotiation is completed before the upper layer communication officially starts, and is implemented by the underlying protocol. The key negotiation process is set after the first address learning of the virtual host is completed, that is, when the VM receives the ARP reply packet returned from OVS, the key negotiation process based on the trusted authentication platform begins. The key negotiation scheme based on the trusted authentication platform includes four steps, namely, platform identity authentication based on the trusted authentication platform, policy negotiation, key generation, and key query and update; (1) Platform identity authentication based on a trusted authentication platform The unforgeable trusted authentication platform module is used as the identity of the VM. It has a one-to-one correspondence with the VM. The inherent identity authentication mechanism of the trusted authentication platform implements identity authentication from the perspective of the platform itself, which fully meets the authentication requirements between the VM and OVS in the cloud platform. Use AIK to prove the platform's identity to other users: First, the client generates an AIK certificate with the AIK key and EK certificate at the trusted third-party privacy PCA, and binds the relationship between AIK and EK. At this time, AIK is equivalent to binding with the platform identity. Then the client sends the data signed by the AIK certificate and AIK private key to the verification end. The verification end uses the PCA public key to decrypt the AIK public key and verify the client's signature to confirm the client's identity. The identity authentication based on the trusted authentication platform is to use the virtual TPM to authenticate the platform identity. The virtualization solution is to virtualize a physical TPM into multiple trusted authentication platforms and assign them to each virtual machine, so that the virtual machine uses the trusted authentication platform just like the physical host uses TPM. The TPM chip is virtualized into multiple trusted authentication platforms, and these trusted authentication platforms are managed by the trusted authentication platform Managent. The trusted authentication platform uses the physical TPM resources in a time-sharing manner. When the VM uses the trusted authentication platform to authenticate with OVS, the trusted authentication platform first uses TPM to apply for an AK certificate for the VM. Then, the VM sends the AIK certificate and AIK signature message to the OVS. OVS uses the PCA public key to decrypt the AIK certificate to obtain the AIK public key, and uses this public key to verify the signature message and confirm the identity of the VM. (2) Strategy Negotiation The two negotiating parties determine the consistent encryption algorithm and hash function, which is completed by exchanging two data packets. The first data packet is used by the VM to send information such as the encryption algorithms and hash functions it supports to OVS, and the second data packet is used by OVS to inform the VM of the selected encryption algorithm and hash function. The policy data is loaded into the KNBV data part of the key negotiation data packet; The policy data used for negotiation is encapsulated in the KNBV data part of the key negotiation. When the OVS receives the policy negotiation data packet, it determines that the data packet is used for policy negotiation through the protocol type field in the KNBV header, and then uses the policy information in the KNBV data part to determine the encryption algorithm and hash function. After that, OVS returns a policy response message to the VM. When the VM receives the response packet, it selects the same encryption algorithm and hash function as the OVS. At this point, the policy negotiation process is completed; (3) Key generation The negotiating parties first exchange the parameters for generating the key, and then each uses the relevant algorithm that has been negotiated in advance to generate the key. The key is never transmitted in the public channel from beginning to end, and even if the parameters for generating the key are intercepted by a third party, the key cannot be imitated. The key exchange process is as follows: ① Let p be a large prime number, a be an integer, a be a primitive root of p, satisfying a mod p, a^2 mod p, ..., a^(p-1) mod p are all different integers, and make a and p public; ②VM selects a random number R1 and calculates Y1=a^R1 mod p; ③OVS selects a random number R2 and calculates Y2=a^R2 mod p; ④VM saves R1 and sends Y1 to OVS; OVS saves R2 and sends Y2 to VM; ⑤VM calculates the key: K=Y2^R1 mod p; ⑥OVS calculates the key: K=Y1^R2 mod p; In the specific parameter exchange process, VM first loads Y1 and other related information into the KNBV data part, and then sends the data packet to OVS. OVS takes out parameter Y1 and generates key K, then loads its own parameter Y2 and other related information into the KNBV data part and sends it to VM. VM takes out parameter Y2 and generates key K. So far, the VM and OVS have generated the same key. (4) Query and update of key When the key is only stored on the local server, the hash value of the OVSID, local virtual network ID, message key address, and IP address information is used as the storage keyword. In the distributed cloud platform, when the key is stored on a separate server, the server ID needs to be added to the storage keyword. When searching for the key in the database, the hash value of the data packet and the OVS information to which the client belongs is used as the search keyword to achieve fast search in the database. In addition, the storage and use of keys are designed to enhance security from two aspects: first, the keys agreed upon by both parties are encrypted using the trusted authentication platform before being stored, and the shared key is bound to the storage key inside the trusted authentication platform, which greatly improves security; second, the shared key between OVS and VM is set to be updated regularly to avoid the long-term use of the same key in identity authentication, which may cause the key to be cracked by a third party.

[0014] Preferably, the overall architecture of identity authentication based on the message key code algorithm is: The specific work of the message key code calculation module and the identity authentication module is: Message key code: VM uses the pre-agreed shared key K and the message key code algorithm to calculate Mac=MAC k (m), append the message key code value to the original data frame to form a new data frame, and then send it to OVS; Authentication module: After OVS receives the data frame sent from the VM, it calculates Vrfy k (m, MAC k (m)) = 1, verify the VM identity, the specific steps of the identity authentication module are as follows: Step 1: OVS uses the pre-agreed shared key and message key algorithm to process the data frame sent from the VM according to the VM's message key operation method to obtain a new message key value; Step 2: OVS compares the new message key code value with the message key code value received from the VM. If they are the same, it indicates that the identity authentication is successful. The data frame is received, the message key code value in the frame is removed, and it is transmitted as a normal data frame. If they are different, it indicates that the identity authentication fails and the message data frame is discarded.

[0015] Preferably, a detailed identity authentication scheme based on a message key code algorithm is as follows: when the data frame is received by OVS, the identity authentication module on the OVS side removes the attached message key code value to obtain the original data frame, and then performs message key code calculation on the original data frame according to the processing mode of the VM to obtain a new message key code value, and determines whether the data frame is sent by the original trusted VM by comparing the two message key code values, and further determines whether the identity of the VM is tampered with; When the data message begins to be encapsulated at the br-tun bridge of the computing node, if it is found that the frame length exceeds the maximum frame length limit of the link layer, the message needs to be fragmented, and the message key value is removed before fragmentation. The length of the message key value is taken into account during fragmentation, and then the message key value is recalculated for each fragment and then attached to the end of the reserved data field. The data frame encapsulated by the GRE protocol and attached with the message key value can be transparently transmitted on ordinary network devices; The data frames with message key code values ​​attached in the cloud platform are compatible with ordinary physical devices and are transparently transmitted between different network devices. When the data frames with message key code values ​​attached arrive at the network node, the br-tun bridge of the node first performs identity authentication. If the authentication passes, the message key code value is recalculated before continuing to be transmitted. If the authentication fails, it is discarded. The keys used for identity authentication between different nodes can be determined through the ordinary key negotiation protocol.

[0016] When the network node verifies the identity of the computing node, it recalculates the message key code value and sends the data frame to the br-int bridge of the node for identity authentication. If the verification is successful, it means that the br-int bridge of the network node determines that the identity of the br-tun bridge is credible, thereby determining that the identity of the VM of the computing node is credible. The trust in this process is passed level by level, and each level ensures that the identity of the previous level is credible. The final level can also determine that the identity of the first level is credible. That is, at this time, the br-int bridge of the network node can determine that the identity of the VM of the computing node is credible.

[0017] Preferably, a secure local virtual network architecture is built: the secure local virtual network of the solution built using the OpenStack cloud platform adopts the OpenStake three-node deployment mode, and virtual machines are created for multiple tenants on the computing nodes. Each virtual machine is configured with a dedicated trusted authentication platform, and then these virtual machines are connected to the same or multiple OVSs, and local virtual networks are divided on the OVS to isolate virtual machines of different tenants. Finally, the computing nodes and network nodes are connected using the br-tun bridge, and a DHCP server and a virtual router are configured on the network nodes to dynamically allocate IP addresses to virtual machines on the computing nodes and communicate across local virtual networks; A key negotiation and message key calculation module is added to the VM of the secure local area virtual network, so that the virtual machine can start the key negotiation process immediately after receiving the ARP reply packet from the OVS end. In the subsequent communication process with other virtual machines, each Ethernet frame sent outward can calculate the message key value in the message key calculation module. On the OVS end, an identity authentication module is added so that after receiving the Ethernet frame sent by the VM, the OVS end first verifies the identity of the VM. If the verification is successful, the VM's data frame is received. If the verification fails, the VM's data frame is discarded.

[0018] Preferably, the key negotiation of the secure local virtual network: platform identity authentication, policy negotiation and key generation process is completed by exchanging 7 data packets. After the VM receives the ARP response packet from OVS, the key negotiation module in the VM protocol stack starts working, and the process is as follows: The first packet: VM sends an AK certificate request packet to PCA; Data packet 2: PCA returns the AIK certificate to VM; The third data packet: VM sends the AIK certificate and signature to OVS, which then authenticates the VM through the platform. The fourth data packet: After the platform identity authentication is passed, the VM sends a policy negotiation data packet to OVS. The data packet contains the encryption algorithm and hash function supported by the VM side. The fifth packet: After OVS selects the encryption algorithm and hash function, it notifies the VM; The sixth data packet: VM sends the key parameters generated by itself to OVS; Data packet 7: OVS sends the key parameters generated by itself to VM; The specific work involved in the exchange of the above 7 data packets includes the assembly and sending of request frames, the reception and processing of response frames, writing data frame filling, sending and receiving processing codes in the Hook function, and performing corresponding processing according to the frame type when filling the KNBV header and KNBV data part in the data frame.

[0019] Preferably, the identity authentication of the secure local area virtual network: adopts a message key code algorithm composed of other encryption primitives, and adopts HmacSHA1 as a specific implementation algorithm for identity authentication based on the message key code algorithm, and the steps are as follows: Step 1: Process the key K, fill it with 0 or perform a hash operation with H; Step 2: XOR the K' obtained in step 1 with the iPad; Step 3: Perform a cascade operation on the data stream M and the string S1 obtained in step 2; Step 4: Use the hash function H to apply to the string obtained in the previous step; Step 5: XOR the K obtained in step 1 with opad; Step 6: Perform cascade operation on the results obtained in step 4 and step 5; Step 7: Apply the hash function H to the result of step 6 to obtain the message key code H; Where H represents the hash function, K represents the key, m represents the message to be sent, K' represents the key that is padded or processed by the hash function. When the key length is less than the hash block, it needs to be padded with 0. When the key length exceeds the hash block, it needs to be hashed by the hash function first. || represents the cascade operation, ⊕ represents the XOR operation, and opad and ipad represent two strings from the outside and inside respectively. The message key code calculation module is added to the network protocol stack on the VM side, and the identity authentication based on the message key code algorithm is implemented in the secure local area virtual network. The Hook function is used to modify the source code of processing data packets in OVS on the OVS side to add the identity authentication module.

[0020] Preferably, add an authentication module: 1) VM side: The message key calculation module written by the Hook function is mounted at POST_ROUTING. Data packets sent from the VM user space will be intercepted by the message key calculation module before being sent to the network card for forwarding. After being processed by the HMACSHA1 algorithm, they are sent to the network card to wait for sending. The specific processing process of the message key calculation module is that after intercepting the skb, the Hook function performs message key calculation on the data part pointed to by the pointer and the two consecutive data areas stored in the head. The message digest message key value obtained by the HMACSHA1 algorithm has 20 bytes, and then this message key value is attached to the data part and forwarded synchronously; 2) OVS side: Authentication is implemented by modifying the datapath code for processing data packets. The data packet is obtained in the netdev_port_receive function and represented by the structure skb. The verification code is added to the beginning of this function. The same message key code operation is performed on the two consecutive data areas of the header and data part of the skb to obtain the message key code of the OVS side, and then compared with the message key code carried in the message. If the two message key codes are the same, it means that the identity of the message sender is the trusted VM when OVS was created. The message sent by it is received and handed over to OVS for further processing. If they are different, it means that the message may be sent by a malicious VM and the data frame is discarded.

[0021] Compared with the prior art, the innovations and advantages of this application are: (1) In order to make up for the security loopholes in the local virtual network division technology in the cloud platform, this application establishes a local virtual network construction based on a virtual trusted platform module and a message key code algorithm. The key negotiation based on the trusted authentication platform aims to establish the key negotiation process on the basis of realizing platform identity authentication with a trusted authentication platform, while the identity authentication based on the message key code algorithm is used for the identity authentication of both parties in the key negotiation in the subsequent communication process to prevent the local virtual network environment from being attacked by disguised malicious virtual machines. After testing, it is shown that this scheme can indeed prevent malicious virtual machines from launching attacks on the local virtual network environment, and make up for the security risks brought about by the cloud platform isolating tenant networks by dividing local virtual networks. The local virtual network construction scheme based on the trusted authentication platform and the message key code algorithm combines the advantages of the trusted authentication platform platform identity authentication mechanism and the high efficiency of the message key code algorithm, thereby improving the security level of the virtual network in the cloud platform without reducing the service efficiency of the cloud platform.

[0022] (2) The identity authentication based on the message key code algorithm of this application is established on the basis of secure key negotiation. The platform identity authentication mechanism of the trusted authentication platform is used to determine the identity of the VM end. The key negotiation and the identity authentication mechanism based on the trusted authentication platform are designed to be implemented in the message key code address learning stage of the VM end. The format of the data packet used in the key negotiation process, the processing logic of the data packet exchange, and the algorithm used for the key exchange are redesigned. At the same time, two modules are designed to complete this function, namely the message key code calculation module and the identity authentication module. The message key code calculation module includes the processing method of the data frame, the specific message key code algorithm and the method of attaching the message key code value to the data frame, while the identity authentication module includes the method of OVS processing the data frame with the message key code value attached and the processing method of receiving and discarding the data frame. In order to increase the practicality of the identity authentication scheme based on the message key code algorithm, it is also designed to be extended to all virtual network devices in the cloud platform. Through analysis, it is proved that after the scheme is extended to the entire cloud platform, it can indeed improve the security of the virtual network in the cloud platform, and it is better than the traditional identity authentication scheme in terms of efficiency. Finally, the corresponding secure local virtual network was built using the OpenStack cloud platform, and the key negotiation module, message key code calculation module and identity authentication module for implementing the local virtual network solution were added to the secure local virtual network. Through specific experimental tests, it was verified that the local virtual network solution can indeed make up for the security vulnerabilities caused by dividing the local virtual network in the cloud platform, and it was also verified that the local virtual network solution can resist the attack of malicious VMs in the local virtual network and improve the security and stability of the network in the cloud platform.

[0023] (3) This application is based on the local virtual network technology used to isolate tenant networks in the cloud platform. By analyzing the implementation principle of this technology, its security vulnerabilities are discovered. A solution for building a local virtual network based on a trusted authentication platform and a message key code algorithm is designed to address this vulnerability. The outstanding contributions and innovations of this application also lie in: first, applying trusted computing technology to the identity authentication between virtual network devices on the cloud platform; second, introducing the identity authentication scheme of the trusted authentication platform into the key negotiation process, so that the key negotiation is established on the basis that the platform identity has been confirmed to be trusted, ensuring the security and reliability of the key negotiation process. At the same time, the key negotiation process is established in the message key code address learning stage, so that OVS can use the message key code identity authentication scheme to verify the identity of the VM when it communicates with the VM for the first time; third, the identity authentication scheme implemented by the message key code algorithm enables OVS to verify the identity of the sending VM for each received data frame, realizing real-time verification of the VM identity, achieving a higher security level, and higher efficiency, and greatly improving the feasibility and security of the local virtual network of the cloud platform. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 It is the overall design diagram of the local area virtual network solution of this application.

[0025] Figure 2 This is a diagram of the request packet format sent by the VM to OVS during the authentication phase.

[0026] Figure 3 This is a diagram of the request packet format sent by the VM to OVS during the policy negotiation phase.

[0027] Figure 4 This is a diagram of the request packet format sent by VM to OVS during the key generation phase.

[0028] Figure 5 It is a schematic diagram of the correspondence between keywords and keys.

[0029] Figure 6 Diagram of an authentication scheme based on a message-key algorithm.

[0030] Figure 7 This is a diagram of the data frame format of the message key code value.

[0031] Figure 8 It is a data frame format diagram encapsulated by the VXLAN protocol and attached with a message key code value.

[0032] Fig. 9 This is a diagram showing the implementation effect of identity authentication based on the message key code algorithm in the cloud platform.

[0033] Fig.10 is a flowchart of the key negotiation packet exchange.

[0034] Fig.11 This is a schematic diagram of the processing of data packet skb in the kernel.

[0035] Fig.12 This is a schematic diagram of the processing of data packet skb during the verification process. DETAILED DESCRIPTION

[0036] The following, in conjunction with the accompanying drawings, further describes the technical solution of the method for constructing a cloud computing platform authentication security local virtual network provided by the present application, so that technical personnel in the field can better understand the present application and implement it.

[0037] At present, the most widely used scenarios for virtual networks are cloud platforms and data centers. In mainstream cloud platforms, the virtual network technology used to isolate tenant networks is to divide virtual local area networks. However, dividing local virtual networks in cloud platforms has inevitable security issues, that is, attackers can disguise themselves as legitimate members of the local virtual network by forging their own identities, and then launch attacks on the local virtual network environment. For example, in the OpenStack cloud platform, the virtual machine controlled by the attacker can replace the original legitimate members of the local virtual network by forging message key code addresses and IP addresses, or occupying the ports of legitimate local virtual network members, and then launch attacks as legitimate members.

[0038] In order to make up for the security loopholes in the local virtual network division technology in the cloud platform, this application has designed a corresponding solution - building a local virtual network structure based on a virtual trusted platform module and a message key code algorithm. The solution consists of two parts, namely key negotiation based on a trusted authentication platform and identity authentication based on a message key code algorithm. The key negotiation based on a trusted authentication platform aims to establish the key negotiation process on the basis of platform identity authentication using a trusted authentication platform, while the identity authentication based on a message key code algorithm is used for the identity authentication of both parties in the key negotiation during subsequent communications, preventing the local virtual network environment from being attacked by disguised malicious virtual machines. In order to verify the effectiveness of this solution, this application has designed and implemented a corresponding secure local virtual network. After testing, it has been shown that this solution can indeed prevent malicious virtual machines from launching attacks on the local virtual network environment, and make up for the security risks brought about by the cloud platform isolating tenant networks by dividing local virtual networks.

[0039] The local virtual network construction solution based on the trusted authentication platform and the message key code algorithm designed in this application combines the advantages of the trusted authentication platform identity authentication mechanism and the high efficiency of the message key code algorithm to improve the security level of the virtual network in the cloud platform without reducing the service efficiency of the cloud platform.

[0040] 1. Local Area Virtual Network Construction Method 1. Target analysis There is no logic in the local virtual network to determine whether the identity of the access end is legitimate, that is, the identity of the access end is not verified. If this verification process already exists in the local virtual network, the local virtual network can deny access to hosts that fail identity authentication, and all messages sent by them will be discarded, and their attacks will not succeed. In order to make up for the security vulnerabilities in the local virtual network division in the cloud platform, an identity authentication mechanism is added to the local virtual network environment divided by the cloud platform. This mechanism meets the following requirements: (1) When a virtual host accesses a local area virtual network, its identity is authenticated based on the data packets it sends. If the authentication succeeds, its legal identity is recognized and it is allowed to become a member of the local area virtual network. If the authentication fails, the virtual host is denied membership in the local area virtual network and all messages it sends are discarded.

[0041] (2) During the communication process between virtual hosts within the local virtual network, each message is authenticated to determine whether the identity of the communicating host in the local virtual network is trustworthy. If the verification fails, the virtual host that sent the message is found through the address information in the message and is removed from the local virtual network.

[0042] (3) Adding this verification mechanism to the local area virtual network will not affect its communication efficiency too much.

[0043] 2. Scheme design If the traditional key negotiation method is used, the second requirement in the above requirement cannot be met, because the traditional key negotiation scheme is established at the application layer, and the communication connection has been established at this time. In addition, the two parties in the key negotiation are not ordinary users, but virtual hosts in the cloud platform. In order to achieve the above key negotiation goals, this application designs a new key negotiation scheme - key negotiation based on a trusted authentication platform, which uses the ARP protocol to complete key negotiation at the data link layer, and establishes the key negotiation process on the basis of using a trusted authentication platform to realize the platform identity authentication of the two negotiating parties.

[0044] In addition, a database is built to save keys, and the keys are encrypted and stored using a trusted authentication platform. When OVS verifies the identity of the VM, a key retrieval process is set up to search for keys in the database based on the characteristic information of the VM. If a large number of keys are stored in the database, the ordinary search method will be very time-consuming. In order to improve the search efficiency, this application establishes an efficient key storage method and search method to shorten the key search time, and sets regular updates to the shared key between the VM and OVS to further improve the confidentiality of the key to prevent the risk of key leakage caused by long-term use of the same key.

[0045] This application makes up for the security loopholes caused by the division of local virtual networks in the cloud platform. It builds a local virtual network based on a trusted authentication platform and a message key code algorithm, which includes two parts: (1) Key negotiation based on a trusted authentication platform, including identity authentication, policy negotiation, key generation, and key management; (2) Authentication based on message key algorithm. The overall design diagram of the local area virtual network solution is as follows: Figure 1 shown.

[0046] 2. Key Agreement Based on Trusted Authentication Platform 1. Overall architecture of the key agreement scheme (1) Use a trusted authentication platform to authenticate the identities of both parties in key negotiation; (2) If authentication succeeds, the two parties enter the policy negotiation phase and exchange cryptographic algorithms and hash functions supported by both parties. If authentication fails, the two parties stop and report an error. (3) The two parties in negotiation exchange the relevant parameters for generating keys and each generates a shared key. After the key is generated, it is encrypted and stored using a trusted authentication platform.

[0047] 2. Detailed scheme for key negotiation Key negotiation based on a trusted authentication platform requires that the negotiation process be implemented with an underlying protocol and completed before the first communication between the two negotiating parties. The key negotiation is completed in the data link layer, and a key negotiation data packet is established based on the ARP message to complete the key negotiation process.

[0048] Key negotiation is completed before the upper-layer communication officially begins and is implemented by the underlying protocol. The key negotiation process is set after the first address learning of the virtual host is completed, that is, when the VM receives the ARP reply packet returned from OVS, the key negotiation process based on the trusted authentication platform begins. The key negotiation scheme based on the trusted authentication platform includes four steps, namely platform identity authentication based on the trusted authentication platform, policy negotiation, key generation, and key query and update.

[0049] (1) Platform identity authentication based on a trusted authentication platform The unforgeable trusted authentication platform module is used as the identity of the VM. It has a one-to-one correspondence with the VM. The inherent authentication mechanism of the trusted authentication platform implements identity authentication from the perspective of the platform itself, which fully meets the authentication requirements between VM and OVS in the cloud platform.

[0050] Use AIK to prove the platform's identity to other users: First, the client generates an AIK certificate with the AIK key and EK certificate at a trusted third-party privacy CA (PCA), and binds the relationship between AIK and EK. At this time, AIK is equivalent to binding with the platform identity. Then the client sends the data signed by the AIK certificate and the AIK private key to the verification end. The verification end uses the PCA public key to decrypt the AIK public key and verify the client's signature to confirm the client's identity. Identity authentication based on a trusted authentication platform is to use a virtual TPM to authenticate the platform. The virtualization solution is to virtualize a physical TPM into multiple trusted authentication platforms and assign them to each virtual machine, so that the virtual machine uses the trusted authentication platform just like a physical host uses TPM. The TPM chip is virtualized into multiple trusted authentication platforms, and these trusted authentication platforms are managed by the trusted authentication platform Managent. The trusted authentication platform uses physical TPM resources in a time-sharing manner. When the VM uses the trusted authentication platform to authenticate with OVS, the trusted authentication platform first uses TPM to apply for an AK certificate for the VM. Then, the VM sends the AIK certificate and the AIK signature message to the OVS. OVS uses the PCA public key to decrypt the AIK certificate to obtain the AIK public key, and uses this public key to verify the signature message and confirm the identity of the VM.

[0051] The identity authentication based on the trusted authentication platform is completed by exchanging three data packets. The first data packet is used to request the AIK certificate from PCA, the second data packet is used to receive the AIK certificate sent by PCA, and the third data packet is used to send the AIK certificate and AIK signature message to OVS. The KNBV data part is used to carry relevant information for identity authentication at this stage, including EK certificate, AIK certificate and AIK signature. The format of the request packet sent by VM to OVS during the identity authentication stage is as follows: Figure 2 shown.

[0052] (2) Strategy Negotiation The negotiation parties determine the consistent encryption algorithm and hash function, which is completed by exchanging two data packets. The first data packet is used by the VM to send information such as the encryption algorithms and hash functions it supports to OVS, and the second data packet is used by OVS to inform the VM of the selected encryption algorithm and hash function. The policy data is loaded into the KNBV data part of the key negotiation data packet. The format of the request packet sent by the VM to OVS during the policy negotiation phase is as follows: Figure 3 shown.

[0053] The policy data used for negotiation is encapsulated in the KNBV data part of the key negotiation. When the OVS receives the policy negotiation data packet, it determines that the data packet is used for policy negotiation through the protocol type field in the KNBV header, and then uses the policy information in the KNBV data part to determine the encryption algorithm and hash function. After that, OVS returns a policy response message to the VM. When the VM receives the response packet, it selects the same encryption algorithm and hash function as the OVS. At this point, the policy negotiation process is completed.

[0054] (3) Key generation The negotiating parties first exchange the parameters for generating the key, and then each uses the relevant algorithm that has been negotiated in advance to generate the key. The key is never transmitted in the public channel from beginning to end, and even if the parameters for generating the key are intercepted by a third party, the key cannot be imitated. The key exchange process is as follows: ① Let p be a large prime number, a be an integer, a be a primitive root of p, satisfying a mod p, a^2 mod p, ..., a^(p-1) mod p are all different integers, and make a and p public; ②VM selects a random number R1 and calculates Y1=a^R1 mod p; ③OVS selects a random number R2 and calculates Y2=a^R2 mod p; ④VM saves R1 and sends Y1 to OVS; OVS saves R2 and sends Y2 to VM; ⑤VM calculates the key: K=Y2^R1 mod p; ⑥OVS calculates the key: K=Y1^R2 mod p; In the specific parameter exchange process, VM first loads Y1 and other related information into the KNBV data part, and then sends the data packet to OVS. OVS takes out parameter Y1 to generate key K, and then loads its own parameter Y2 and other related information into the KNBV data part and sends it to VM. VM takes out parameter Y2 to generate key K. So far, the VM and OVS have generated the same key. The format of the request packet sent by VM to OVS during the key generation phase is as follows: Figure 4 shown.

[0055] (4) Query and update of key When the key is only stored on the local server, the hash value of the OVSID, local virtual network ID, message key code address, and IP address information is used as the storage keyword. In the distributed cloud platform, when the key is stored on a separate server, the server ID needs to be added to the storage keyword. When searching for the key in the database, the hash value of the data packet and the OVS information to which the client belongs is used as the search keyword to achieve fast search in the database.

[0056] The advantages of this storage and search method are: first, there is no need to store a large amount of local virtual network ID, message key code address, IP address and other information, which saves storage space, and saves search time because there is no need to compare multiple keywords. Secondly, if the key is stored directly in the database, the comparison process will take too much time because the key is too long. To search for the key by keyword, you only need to compare the keyword. The keyword is shorter than the key, so the search time is also shorter.

[0057] The specific storage-retrieval process is that when negotiating the key, OVS will bind the key negotiated with the VM to the VM's message key code address, IP address, and local virtual network ID, and then add this information to the OVSID for hash calculation. The obtained hash value is stored in the database as a storage keyword and synchronized with the key. When OVS executes the message key code algorithm to verify the identity of the VM, OVS first queries the information in the data packet to obtain the message key code address, IP address, and local virtual network ID corresponding to the VM, and then synchronizes the OVSID where the VM is located with this information for hash calculation to obtain the retrieval keyword, and uses this keyword to search the database for the key corresponding to the VM. The correspondence between keywords and keys is shown in the following figure. Figure 5 shown.

[0058] In addition, the storage and use of keys are designed to enhance security from two aspects: first, the keys agreed upon by both parties are encrypted using the trusted authentication platform before being stored, and the shared key is bound to the storage key inside the trusted authentication platform, which greatly improves security; second, the shared key between OVS and VM is set to be updated regularly to avoid the long-term use of the same key in identity authentication, which may cause the key to be cracked by a third party.

[0059] 3. Authentication based on message key algorithm 1. Overall architecture of identity authentication scheme The authentication process is completed by two modules, namely the message key code calculation module and the authentication module. The message key code calculation module calculates the message verification code on the VM side, and the authentication module completes the authentication process on the OVS side. The authentication scheme based on the message key code algorithm is shown in the figure below. Figure 6 shown.

[0060] The specific work of the message key code calculation module and the identity authentication module is: Message key code: VM uses the pre-agreed shared key K and the message key code algorithm to calculate Mac=MAC k (m), append the message key code value to the original data frame to form a new data frame, and then send it to OVS; Authentication module: After OVS receives the data frame sent from the VM, it calculates Vrfy k (m, MAC k (m)) = 1, verify the VM identity, the specific steps of the identity authentication module are as follows: Step 1: OVS uses the pre-agreed shared key and message key algorithm to process the data frame sent from the VM according to the VM's message key operation method to obtain a new message key value; Step 2: OVS compares the new message key code value with the message key code value received from the VM. If they are the same, it indicates that the identity authentication is successful. The data frame is received, the message key code value in the frame is removed, and it is transmitted as a normal data frame. If they are different, it indicates that the identity authentication fails and the message data frame is discarded.

[0061] 2. Detailed Identity Verification Scheme In the VM, each outgoing data frame needs to be calculated for the message key code, and the message key code value is attached to the data field in the data frame. The format of the data frame with the message key code value attached is as follows: Figure 7 shown.

[0062] When the data frame is received by OVS, the identity authentication module on the OVS side removes the attached message key value to obtain the original data frame, and then calculates the message key value of the original data frame according to the processing method of the VM to obtain a new message key value. By comparing the two message key values, it is determined whether the data frame is sent by the original trusted VM, and then whether the identity of the VM has been tampered with; To implement identity authentication between VM and OVS on the computing node, it is necessary to modify the code of VM and OVS, and use GRE or VXLAN to encapsulate the data frame with the message key code value. The encapsulation method is to add a GRE header to the data frame of one protocol, encapsulate it into the payload of another network layer protocol, and then send it to other nodes to achieve transparent transmission through ordinary physical network equipment.

[0063] When the data message begins to be encapsulated at the br-tun bridge of the computing node, if it is found that the length of the frame exceeds the maximum frame length limit of the link layer, the message needs to be fragmented, and the message key code value is removed before fragmentation. The length of the message key code value is taken into account during fragmentation, and then the message key code value is recalculated for each fragment and attached to the end of the reserved data field. The data frame encapsulated by the GRE protocol and attached with the message key code value can be transparently transmitted on ordinary network devices.

[0064] When OpenStack uses VXLAN mode for networking, the data frame with the message key code value is encapsulated into the UDP segment of the transport layer protocol. The format of the data frame with the message key code value encapsulated by the VXLAN protocol is as follows: Figure 8 As shown: At this time, the VXLAN header, L2 layer data frame and message key code value are treated as ordinary data transmission. When the frame length of the encapsulated data frame exceeds the maximum frame length limit of the link layer, it is also fragmented, and the data part in the L2 layer data frame is segmented. The message key code of the segmented data is recalculated and the message key code value is attached. Then, the original L2 layer data frame header and VXLAN header are added and handed over to the VXLAN protocol for encapsulation.

[0065] The data frames with message key code values ​​attached in the cloud platform are compatible with ordinary physical devices and are transparently transmitted between different network devices. When the data frames with message key code values ​​attached arrive at the network node, the br-tun bridge of the node first performs identity authentication. If the authentication passes, the message key code value is recalculated before continuing to be transmitted. If the authentication fails, it is discarded. The keys used for identity authentication between different nodes can be determined through the ordinary key negotiation protocol.

[0066] When the network node verifies the identity of the computing node, it recalculates the message key code value and sends the data frame to the br-int bridge of the node for identity authentication. If the verification is successful, it means that the br-int bridge of the network node determines that the identity of the br-tun bridge is credible, thereby determining that the identity of the VM of the computing node is credible. The trust in this process is passed level by level, and each level ensures that the identity of the previous level is credible. The final level can also determine that the identity of the first level is credible. That is, at this time, the br-int bridge of the network node can determine that the identity of the VM of the computing node is credible.

[0067] The above scheme of extending the identity authentication based on the message secret key algorithm to the entire cloud platform can make the virtual network in the cloud platform have the following three advantages: First, it can enable the communication subjects with the added identity authentication module to mutually verify each other's identity. Second, the identity authentication based on the message secret key algorithm can also verify the integrity of the message, so that the virtual network device can identify whether the message has been tampered with. Third, the method of recalculating the message secret key value when the data packet flows in different virtual network devices can make the key negotiation only need to be carried out in the directly connected devices, reducing the complexity of key negotiation and reducing the data communication caused by negotiating the key.

[0068] In a large cloud platform, there are a large number of VMs and virtual network devices. One OVS may be connected to many VMs, and one more OVS is connected to a virtual router. When performing identity authentication, if each virtual network device verifies the identity of the sender of each received data frame separately, the amount of calculation will be very large and the efficiency will be greatly reduced. Therefore, in this case, this application proposes to upgrade the message key code algorithm in the identity authentication scheme based on the message key code algorithm to a more efficient aggregate message key code algorithm: When multiple users send messages and message key values ​​to the recipient, these multiple message key values ​​are aggregated into a new message key value, and then you only need to verify this new message key value to verify the identities of all users. In the cloud platform application scenario, when many VMs connected under OVS communicate with each other, OVS aggregates the message key values ​​in the data packets with the same local virtual network ID to obtain a unique message key value, and then verifies this unique message key value. If the verification is successful, it means that the identities of multiple VMs are credible, and the data packets they send are allowed to continue to be transmitted. If the verification fails, separate troubleshooting is performed.

[0069] The authentication scheme based on the message key algorithm has the following advantages: (1) Data packets sent by VMs in the same local virtual network at the same time are verified simultaneously, avoiding the time overhead caused by sequential verification. (2) If cross-host communication is required, the aggregation of message key values ​​can occur on the br-tun bridge connecting the nodes, so that all data frames transmitted on the link do not have to carry message key values, which can reduce the occupation of bandwidth resources.

[0070] The implementation effect of identity authentication based on message key code algorithm in cloud platform is shown in the figure below: Fig. 9 As shown in the figure. In the message key code algorithm, the method of achieving aggregation is an efficient XOR operation. Therefore, using the message key code algorithm to aggregate all message key code values ​​and then verifying is much faster than directly verifying each message key code value. Therefore, when the identity authentication scheme based on the message key code algorithm is extended to the cloud platform, the message key code algorithm can be used instead of the message key code to improve the efficiency of identity authentication.

[0071] 4. Solution Security Analysis Use the message key code algorithm to implement identity authentication from VM to OVS: For each message sent from VM to OVS, verify its integrity and whether it is sent by the original trusted VM, and then verify whether the identity of the VM sending the message has been tampered with. If an attacker forges a data frame as a legitimate user, the data frame will fail to be verified on the OVS side. OVS can discard such data frames to protect the local virtual network environment from external attacks. In addition, the attacker's host is found based on information such as the message key code address and removed from the local virtual network.

[0072] The reason why identity authentication can be achieved through the message key code algorithm and thus prevent attacks is that there is a shared key between the VM and OVS. The reliability of identity authentication is completely based on the security of key negotiation. After the administrator creates the VM, the key negotiation between the VM and OVS needs to be completed during the first address learning phase of the VM. This process is implemented based on the key negotiation scheme of the trusted authentication platform, and the specific shared key generation uses a large prime number as the key generation source, which improves the security level of the key. In addition, the key will only be generated by each negotiating party and will not be transmitted on a public channel, so it can be prevented from being stolen. In order to prevent man-in-the-middle attacks, the platform identity authentication mechanism of the trusted authentication platform is used to ensure that key negotiation is carried out on the basis that both parties have authenticated the trustworthiness of the platform.

[0073] After the key negotiation is completed, in the communication between VM and OVS, for each message sent from the VM, when passing through OVS, the identity of the VM will be verified to determine whether the VM is the original trusted VM. Regarding the security vulnerabilities of the two LAN division methods, when the LAN is divided based on ports, the attacker sends a message to OVS by accessing the idle LAN port configured with the LAN ID. Since the attacker and OVS do not share the key, the authentication will definitely fail when OVS performs authentication. This message will be discarded and the attacker may also be removed from the LAN. The attacker's attempt to attack the LAN through this security vulnerability will not succeed. In the case of dividing the LAN based on the message key code address or IP address, when the attacker tries to replace the original VM by forging the message key code address and IP address, since the key negotiation process has not been carried out, the attacker's message sent to OVS will also fail to be verified, so the attacker's attack on the LAN in this way will not succeed. In addition, to prevent key leakage caused by using the same key multiple times during communication, the key shared by VM and OVS is updated regularly, which further improves the security of the solution.

[0074] 5. Build a secure local area virtual network architecture In order to verify whether the LAN solution is feasible, the secure LAN virtual network of the solution built on the OpenStack cloud platform adopts the OpenStake three-node deployment mode, and creates virtual machines for multiple tenants on the computing nodes. Each virtual machine is configured with a dedicated trusted authentication platform, and then these virtual machines are connected to the same or multiple OVSs. The LAN virtual network is divided on the OVS to isolate the virtual machines of different tenants. Finally, the computing node and the network node are connected using the br-tun bridge, and the DHCP server and virtual router are configured on the network node to dynamically allocate IP addresses to the virtual machines on the computing nodes and communicate across the LAN virtual network.

[0075] A key negotiation and message key calculation module is added to the VM of the secure local area virtual network, so that the virtual machine can start the key negotiation process immediately after receiving the ARP reply packet from the OVS end. In the subsequent communication process with other virtual machines, each Ethernet frame sent outward can calculate the message key value in the message key calculation module. On the OVS end, an identity authentication module is added so that after receiving the Ethernet frame sent by the VM, the OVS end first verifies the identity of the VM. If the verification is successful, the VM's data frame is received. If the verification fails, the VM's data frame is discarded.

[0076] 6. Secure LAN Technology Route The key negotiation module and message key code calculation module on the VM side both work in the network protocol stack and are written using the Hook function of the Netfilter framework, implementing key negotiation and identity authentication.

[0077] 1. Key Negotiation The platform identity authentication, policy negotiation and key generation process is completed by exchanging 7 packets. The packet exchange process is as follows: Fig.10 As shown in the figure, after the VM receives the ARP response packet from OVS, the key negotiation module in the VM protocol stack starts working, and the process is as follows: The first packet: VM sends an AK certificate request packet to PCA; Data packet 2: PCA returns the AIK certificate to VM; The third data packet: VM sends the AIK certificate and signature to OVS, which then authenticates the VM through the platform. The fourth data packet: After the platform identity authentication is passed, the VM sends a policy negotiation data packet to OVS. The data packet contains the encryption algorithm and hash function supported by the VM side. The fifth packet: After OVS selects the encryption algorithm and hash function, it notifies the VM; The sixth data packet: VM sends the key parameters generated by itself to OVS; Data packet 7: OVS sends the key parameters generated by itself to VM; The specific work involved in the exchange of the above 7 data packets includes the assembly and sending of request frames, the reception and processing of response frames, writing data frame filling, sending and receiving processing codes in the Hook function, and performing corresponding processing according to the frame type when filling the KNBV header and KNBV data part in the data frame.

[0078] (II) Identity verification The message key code algorithm composed of other encryption primitives is adopted, and HmacSHA1 is used as the specific implementation algorithm of the identity authentication based on the message key code algorithm. The steps are as follows: Step 1: Process the key K, fill it with 0 or perform a hash operation with H; Step 2: XOR the K' obtained in step 1 with the iPad; Step 3: Perform a cascade operation on the data stream M and the string S1 obtained in step 2; Step 4: Use the hash function H to apply to the string obtained in the previous step; Step 5: XOR the K obtained in step 1 with opad; Step 6: Perform cascade operation on the results obtained in step 4 and step 5; Step 7: Apply the hash function H to the result of step 6 to obtain the message key code H; Where H represents the hash function, K represents the key, m represents the message to be sent, K' represents the key that is padded or processed by the hash function. When the key length is less than the hash block, it needs to be padded with 0. When the key length exceeds the hash block, it needs to be hashed by the hash function first. || represents the cascade operation, ⊕ represents the XOR operation, and opad and ipad represent two strings from the outside and inside respectively. The message key code calculation module is added to the network protocol stack on the VM side, and the identity authentication based on the message key code algorithm is implemented in the secure local area virtual network. The Hook function is used to modify the source code of processing data packets in OVS on the OVS side to add the identity authentication module.

[0079] 1. VM side The message key calculation module written by the Hook function is mounted at POST_ROUTING. The data packets sent from the VM user space will be intercepted by the message key calculation module before being sent to the network card for forwarding. After being processed by the HMACSHA1 algorithm, they are sent to the network card to wait for sending. The specific processing process of the message key calculation module is that after intercepting the skb, the Hook function performs message key operations on the data part pointed to by the pointer and the two consecutive data areas stored in the head. The message digest message key value obtained by the HMACSHA1 algorithm has 20 bytes, and then this message key value is attached to the back of the data part and forwarded synchronously. The processing of the data packet skb in the kernel is as follows Fig.11 shown.

[0080] 2. OVS Authentication is implemented by modifying the datapath code that processes data packets. The data packet is obtained in the netdev_port_receive function and represented by the structure skb. The verification code is added to the beginning of this function. The same message key code operation is performed on the two continuous data areas of the header and data part of the skb to obtain the message key code on the OVS side, and then compared with the message key code carried in the message. If the two message key codes are the same, it means that the identity of the message sender is the trusted VM when OVS created it. The message sent by it is received and handed over to OVS for further processing. If they are different, it means that the message may be sent by a malicious VM and the data frame is discarded. The processing of the data packet skb during the verification process is as follows: Fig.12 shown.

[0081] 7. System Testing and Analysis 1. Feasibility test The feasibility test is to test whether the authentication based on the message key algorithm can identify the identity of the malicious VM. First, use the same key to test, then change the VM end key to identify the malicious VM, and then test again. The specific operation method is: load the message key calculation module into VM1 and VM2, load the authentication module into OVS, then ping VM2 from VM1, and use the wireshark capture tool on the nuc host to capture the data packets of the virtual terminals tap0 and tap1 connecting VM1 and VM2 on OVS, and finally use the dmesg command to print out the result information of the kernel authentication.

[0082] (1) VM1 and OVS have the same key VM1 and OVS have the same key, which means VM1 is a trusted virtual machine that has negotiated a key with OVS. The message key code value in the data frame sent by VM1 is the same as the message key code value recalculated in OVS, so OVS outputs the match success message, indicating that VM1 and OVS have successfully authenticated their identities, and VM1 is a virtual machine that OVS has confirmed to be safe.

[0083] (2) The keys of VM1 and OVS are different In this experiment, the fact that VMI and OVS do not have the same secret key indicates that VM1's identity is forged. In reality, if VMI is indeed a malicious virtual machine, it will definitely not have the same secret key as OVS, because the malicious VM1 will not go through the key negotiation process with OVS. The message key code value calculated by VM1 is different from the message key code value calculated by OVS for the same data frame, so OVS outputs the matchfailed message, indicating that VM1's identity authentication failed. VM1 may be a malicious virtual machine, and the data frames it sends are discarded.

[0084] Through the above experiments, it can be proved that the authentication scheme based on the message key code algorithm can indeed identify the identity of the VM and block the attack frames sent by the malicious VM outside the local virtual network environment. Therefore, the authentication scheme based on the message key code algorithm can be used to make up for the security loopholes in the local virtual network division method in the cloud platform and improve the security of the cloud platform network.

[0085] (II) Efficiency test In order to verify whether the message key code algorithm has a significant impact on the processing efficiency of data frames during the identity authentication process, we tested the time consumption of the identity authentication module and the message key code calculation module respectively.

[0086] A large number of tests have been conducted on the authentication module on the OVS side. The time spent on performing authentication on the OVS side is extremely short, generally only a dozen microseconds. Therefore, the efficiency of the authentication module can meet the needs of normal applications.

[0087] On the VM side, the message key code calculation module was also tested. When the key length used was also 128 bits, tap0 to tap4 represented the virtual network cards of 5 VMs. When the number of VMs increased, the time consumed by the message key code calculation module did not increase sharply and was still only a dozen microseconds.

[0088] 3. Results Analysis Through the above feasibility experiments, we can draw the following conclusions: when the VM and OVS have securely negotiated the key, the OVS loaded with the authentication module can identify malicious VMs that have not been key negotiated. Therefore, the authentication scheme based on the message key code algorithm is effective in filling the security loopholes in the local virtual network division method in the cloud platform. Malicious VMs can no longer disguise themselves as normal users by forging their own identities or occupying legitimate VM ports.

[0089] In addition, it can be seen from the above experiment that as long as the keys of both parties of the authentication are different, the authentication will definitely fail, and OVS will discard the message that failed the authentication. Therefore, this can also prove that this application can resist the attack of malicious VM. For example, when a malicious VM launches an attack on the local virtual network environment, since it does not negotiate the key with OVS, it will definitely fail in the authentication link, and the message it sends will be discarded, and its attack behavior will not succeed.

[0090] In order to determine whether the authentication scheme based on the message key code algorithm can be applied to large cloud platforms, its efficiency was also tested. The conclusion is that whether it is the message key code calculation module on the VM side or the authentication module on the OVS side, the time consumption caused by different message key code algorithms is very small. Therefore, the authentication scheme based on the message key code algorithm will not affect the transmission efficiency of the data frame, nor will it cause a decrease in the quality of network services. Therefore, it is feasible and effective to apply the authentication scheme based on the message key code algorithm to large cloud platforms.

Claims

1. A method for constructing a secure local virtual network for a cloud computing platform, characterized in that: The local virtual network is constructed based on the virtual trusted platform module and the message key code algorithm, which includes two parts: the key negotiation based on the trusted authentication platform establishes the key negotiation process on the basis of platform identity authentication implemented by the trusted authentication platform, and the identity authentication based on the message key code algorithm is used for the identity authentication of the two parties in the key negotiation in the subsequent communication process, preventing the local virtual network environment from being attacked by disguised malicious virtual machines; The method for building a secure local virtual network for cloud computing platform authentication is divided into the following three steps: A. Key negotiation based on a trusted authentication platform: Establish a platform identity authentication mechanism based on a trusted authentication platform to determine the identity of the VM. The identity authentication based on the message key code algorithm must be completed before the first communication between the VM and OVS begins. The key negotiation and the identity authentication mechanism based on the trusted authentication platform are designed to be implemented in the message key code address learning phase of the VM. Specifically, it includes reconstructing the format of the data packet used in the key negotiation process, the processing logic of the data packet exchange, and the algorithm used for the key exchange. B. Authentication based on message key algorithm: It is based on secure key negotiation. When key negotiation is completed, a message key calculation module and an authentication module are constructed. The message key calculation module includes a data frame processing method, a specific message key algorithm, and a method for attaching a message key value to a data frame. The authentication module includes a method for OVS to process data frames with message key values ​​attached, as well as a method for receiving and discarding data frames. It is extended to all virtual network devices in the cloud platform to improve the security of virtual networks in the cloud platform. C uses the OpenStack cloud platform to build a corresponding secure local area virtual network, and adds a key negotiation module, a message key code calculation module and an identity authentication module to the secure local area virtual network to implement the local area virtual network solution, thereby making up for the security vulnerabilities caused by dividing the local area virtual network in the cloud platform, resisting the attack of malicious VMs in the local area virtual network, and improving the security of the network in the cloud platform.

2. According to the cloud computing platform authentication security local virtual network construction method of claim 1, it is characterized in that: Method for constructing a local virtual network: key negotiation based on a trusted authentication platform, using the ARP protocol to complete key negotiation at the data link layer, and the key negotiation process is based on the identity authentication of the two negotiating parties using a trusted authentication platform; In addition, a database is built to save keys, and the keys are encrypted and stored using a trusted authentication platform. When OVS verifies the identity of the VM, a key retrieval process is set up to find the key in the database based on the characteristic information of the VM. An efficient key storage and search method is established to shorten the key search time. The shared key between the VM and OVS is set to be updated regularly to further improve the confidentiality of the key to prevent the risk of key leakage caused by long-term use of the same key. The construction of a local area virtual network based on a trusted authentication platform and a message key code algorithm includes two parts: one is key negotiation based on a trusted authentication platform, including identity authentication, policy negotiation, key generation and key management; the other is identity authentication based on a message key code algorithm.

3. The method for constructing a cloud computing platform authentication secure local virtual network according to claim 1, characterized in that: The overall architecture of key negotiation based on the trusted authentication platform: (1) Use a trusted authentication platform to authenticate the identities of both parties in key negotiation; (2) If authentication succeeds, the two parties enter the policy negotiation phase and exchange cryptographic algorithms and hash functions supported by both parties. If authentication fails, the two parties stop and report an error. (3) The two parties in negotiation exchange the relevant parameters for generating keys and each generates a shared key. After the key is generated, it is encrypted and stored using a trusted authentication platform.

4. The method for constructing a cloud computing platform authentication secure local virtual network according to claim 1, characterized in that: Detailed scheme of key negotiation based on trusted authentication platform: Key negotiation based on trusted authentication platform requires that the negotiation process be implemented with the underlying protocol and completed before the first communication between the two negotiating parties. Key negotiation is completed in the data link layer, and a key negotiation data packet is established based on the ARP message to complete the key negotiation process. The key negotiation is completed before the upper layer communication officially starts, and is implemented by the underlying protocol. The key negotiation process is set after the first address learning of the virtual host is completed, that is, when the VM receives the ARP reply packet returned from OVS, the key negotiation process based on the trusted authentication platform begins. The key negotiation scheme based on the trusted authentication platform includes four steps, namely, platform identity authentication based on the trusted authentication platform, policy negotiation, key generation, and key query and update; (1) Platform identity authentication based on a trusted authentication platform The unforgeable trusted authentication platform module is used as the identity of the VM. It has a one-to-one correspondence with the VM. The inherent identity authentication mechanism of the trusted authentication platform implements identity authentication from the perspective of the platform itself, which fully meets the authentication requirements between the VM and OVS in the cloud platform. Use AIK to prove the platform's identity to other users: First, the client generates an AIK certificate with the AIK key and EK certificate at the trusted third-party privacy PCA, and binds the relationship between AIK and EK. At this time, AIK is equivalent to binding with the platform identity. Then the client sends the data signed by the AIK certificate and AIK private key to the verification end. The verification end uses the PCA public key to decrypt the AIK public key and verify the client's signature to confirm the client's identity. The identity authentication based on the trusted authentication platform is to use the virtual TPM to authenticate the platform identity. The virtualization solution is to virtualize a physical TPM into multiple trusted authentication platforms and assign them to each virtual machine, so that the virtual machine uses the trusted authentication platform just like the physical host uses TPM. The TPM chip is virtualized into multiple trusted authentication platforms, and these trusted authentication platforms are managed by the trusted authentication platform Managent. The trusted authentication platform uses the physical TPM resources in a time-sharing manner. When the VM uses the trusted authentication platform to authenticate with OVS, the trusted authentication platform first uses TPM to apply for an AK certificate for the VM. Then, the VM sends the AIK certificate and AIK signature message to the OVS. OVS uses the PCA public key to decrypt the AIK certificate to obtain the AIK public key, and uses this public key to verify the signature message and confirm the identity of the VM. (2) Strategy Negotiation The two negotiating parties determine the consistent encryption algorithm and hash function, which is completed by exchanging two data packets. The first data packet is used by the VM to send information such as the encryption algorithms and hash functions it supports to OVS, and the second data packet is used by OVS to inform the VM of the selected encryption algorithm and hash function. The policy data is loaded into the KNBV data part of the key negotiation data packet; The policy data used for negotiation is encapsulated in the KNBV data part of the key negotiation. When the OVS receives the policy negotiation data packet, it determines that the data packet is used for policy negotiation through the protocol type field in the KNBV header, and then uses the policy information in the KNBV data part to determine the encryption algorithm and hash function. After that, OVS returns a policy response message to the VM. When the VM receives the response packet, it selects the same encryption algorithm and hash function as the OVS. At this point, the policy negotiation process is completed; (3) Key generation The negotiating parties first exchange the parameters for generating the key, and then each uses the relevant algorithm that has been negotiated in advance to generate the key. The key is never transmitted in the public channel from beginning to end, and even if the parameters for generating the key are intercepted by a third party, the key cannot be imitated. The key exchange process is as follows: ① Let p be a large prime number, a be an integer, a be a primitive root of p, satisfying a mod p, a^2 mod p, ..., a^(p-1) mod p are all different integers, and make a and p public; ②VM selects a random number R1 and calculates Y1=a^R1 mod p; ③OVS selects a random number R2 and calculates Y2=a^R2 mod p; ④VM saves R1 and sends Y1 to OVS; OVS saves R2 and sends Y2 to VM; ⑤VM calculates the key: K=Y2^R1 mod p; ⑥OVS calculates the key: K=Y1^R2 mod p; In the specific parameter exchange process, VM first loads Y1 and other related information into the KNBV data part, and then sends the data packet to OVS. OVS takes out parameter Y1 and generates key K, then loads its own parameter Y2 and other related information into the KNBV data part and sends it to VM. VM takes out parameter Y2 and generates key K. So far, the VM and OVS have generated the same key. (4) Query and update of key When the key is only stored on the local server, the hash value of the OVSID, local virtual network ID, message key address, and IP address information is used as the storage keyword. In the distributed cloud platform, when the key is stored on a separate server, the server ID needs to be added to the storage keyword. When searching for the key in the database, the hash value of the data packet and the OVS information to which the client belongs is used as the search keyword to achieve fast search in the database. In addition, the storage and use of keys are designed to enhance security from two aspects: first, the keys agreed upon by both parties are encrypted using the trusted authentication platform before being stored, and the shared keys are bound to the storage keys inside the trusted authentication platform, which greatly improves security; Second, set up regular updates of the shared key between OVS and VM to avoid long-term use of the same key in authentication, which may cause the key to be cracked by a third party.

5. The method for constructing a cloud computing platform authentication secure local virtual network according to claim 1, characterized in that: The overall architecture of message key-based authentication: The specific work of the message key code calculation module and the identity authentication module is: Message key code: VM uses the pre-agreed shared key K and the message key code algorithm to calculate Mac=MAC k (m), append the message key code value to the original data frame to form a new data frame, and then send it to OVS; Authentication module: After OVS receives the data frame sent from the VM, it calculates Vrfy k (m, MAC k (m)) = 1, verify the VM identity, the specific steps of the identity authentication module are as follows: Step 1: OVS uses the pre-agreed shared key and message key algorithm to process the data frame sent from the VM according to the VM's message key operation method to obtain a new message key value; Step 2: OVS compares the new message key code value with the message key code value received from the VM. If they are the same, it indicates that the identity authentication is successful. The data frame is received, the message key code value in the frame is removed, and it is transmitted as a normal data frame. If they are different, it indicates that the identity authentication fails and the message data frame is discarded.

6. The method for constructing a cloud computing platform authentication secure local virtual network according to claim 1, characterized in that: Detailed scheme of identity authentication based on message key algorithm: When the data frame is received by OVS, the identity authentication module on the OVS side removes the attached message key value to obtain the original data frame, and then calculates the message key value of the original data frame according to the processing method of the VM to obtain a new message key value. By comparing the two message key values, it is determined whether the data frame is sent by the original trusted VM, and then whether the identity of the VM has been tampered with; When the data message begins to be encapsulated at the br-tun bridge of the computing node, if it is found that the frame length exceeds the maximum frame length limit of the link layer, the message needs to be fragmented, and the message key value is removed before fragmentation. The length of the message key value is taken into account during fragmentation, and then the message key value is recalculated for each fragment and then attached to the end of the reserved data field. The data frame encapsulated by the GRE protocol and attached with the message key value can be transparently transmitted on ordinary network devices; The data frames with message key values ​​attached in the cloud platform are compatible with common physical devices and are transparently transmitted between different network devices. When the data frames with message key values ​​attached arrive at the network node, the br-tun bridge of the node first performs identity authentication. If the authentication is successful, the message key value is recalculated before continuing to be transmitted. If the authentication fails, it is discarded. The keys used for identity authentication between different nodes can be determined through the common key negotiation protocol. When the network node verifies the identity of the computing node, it recalculates the message key code value and sends the data frame to the br-int bridge of the node for identity authentication. If the verification is successful, it means that the br-int bridge of the network node determines that the identity of the br-tun bridge is credible, thereby determining that the identity of the VM of the computing node is credible. The trust in this process is passed level by level, and each level ensures that the identity of the previous level is credible. The final level can also determine that the identity of the first level is credible. That is, at this time, the br-int bridge of the network node can determine that the identity of the VM of the computing node is credible.

7. The method for constructing a cloud computing platform authentication secure local virtual network according to claim 1, characterized in that: Build a secure LAN virtual network architecture: The secure LAN virtual network of the solution built using the OpenStack cloud platform adopts the OpenStake three-node deployment mode, and creates virtual machines for multiple tenants on the computing nodes. Each virtual machine is configured with a dedicated trusted authentication platform, and then these virtual machines are connected to the same or multiple OVSs. The LAN virtual networks are divided on the OVS to isolate the virtual machines of different tenants. Finally, the computing nodes and network nodes are connected using the br-tun bridge, and the DHCP server and virtual router are configured on the network nodes to dynamically allocate IP addresses to the virtual machines on the computing nodes and communicate across the LAN virtual networks. A key negotiation and message key calculation module is added to the VM of the secure local area virtual network, so that the virtual machine can start the key negotiation process immediately after receiving the ARP reply packet from the OVS end. In the subsequent communication process with other virtual machines, each Ethernet frame sent outward can calculate the message key value in the message key calculation module. On the OVS end, an identity authentication module is added so that after receiving the Ethernet frame sent by the VM, the OVS end first verifies the identity of the VM. If the verification is successful, the VM's data frame is received. If the verification fails, the VM's data frame is discarded.

8. The method for constructing a cloud computing platform authentication secure local virtual network according to claim 1, characterized in that: Key negotiation of secure local virtual network: The platform authentication, policy negotiation and key generation process is completed by exchanging 7 data packets. After the VM receives the ARP reply packet from OVS, the key negotiation module in the VM protocol stack starts working. The process is as follows: The first packet: VM sends an AK certificate request packet to PCA; Data packet 2: PCA returns the AIK certificate to VM; The third data packet: VM sends the AIK certificate and signature to OVS, which then authenticates the VM through the platform. The fourth data packet: After the platform identity authentication is passed, the VM sends a policy negotiation data packet to OVS. The data packet contains the encryption algorithm and hash function supported by the VM side. The fifth packet: After OVS selects the encryption algorithm and hash function, it notifies the VM; The sixth data packet: VM sends the key parameters generated by itself to OVS; Data packet 7: OVS sends the key parameters generated by itself to VM; The specific work involved in the exchange of the above 7 data packets includes the assembly and sending of request frames, the reception and processing of response frames, writing data frame filling, sending and receiving processing codes in the Hook function, and performing corresponding processing according to the frame type when filling the KNBV header and KNBV data part in the data frame.

9. The method for constructing a cloud computing platform authentication secure local virtual network according to claim 1, characterized in that: Authentication of secure local area virtual network: adopt the message key code algorithm composed of other encryption primitives, and use HmacSHA1 as the specific implementation algorithm of the authentication based on the message key code algorithm. The steps are as follows: Step 1: Process the key K, fill it with 0 or perform a hash operation with H; Step 2: XOR the K' obtained in step 1 with the iPad; Step 3: Perform a cascade operation on the data stream M and the string S1 obtained in step 2; Step 4: Use the hash function H to apply to the string obtained in the previous step; Step 5: XOR the K obtained in step 1 with opad; Step 6: Perform cascade operation on the results obtained in step 4 and step 5; Step 7: Apply the hash function H to the result of step 6 to obtain the message key code H; Where H represents the hash function, K represents the key, m represents the message to be sent, K' represents the key that is padded or processed by the hash function. When the key length is less than the hash block, it needs to be padded with 0. When the key length exceeds the hash block, it needs to be hashed by the hash function first. || represents the cascade operation, ⊕ represents the XOR operation, and opad and ipad represent two strings from the outside and inside respectively. The message key code calculation module is added to the network protocol stack on the VM side, and the identity authentication based on the message key code algorithm is implemented in the secure local area virtual network. The Hook function is used to modify the source code of processing data packets in OVS on the OVS side to add the identity authentication module.

10. The method for constructing a cloud computing platform authentication secure local virtual network according to claim 9, characterized in that: Add the authentication module: 1) VM side: The message key calculation module written by the Hook function is mounted at POST_ROUTING. Data packets sent from the VM user space will be intercepted by the message key calculation module before being sent to the network card for forwarding. After being processed by the HMACSHA1 algorithm, they are sent to the network card to wait for sending. The specific processing process of the message key calculation module is that after intercepting the skb, the Hook function performs message key calculation on the data part pointed to by the pointer and the two consecutive data areas stored in the head. The message digest message key value obtained by the HMACSHA1 algorithm has 20 bytes, and then this message key value is attached to the data part and forwarded synchronously; 2) OVS side: Authentication is implemented by modifying the datapath code for processing data packets. The data packet is obtained in the netdev_port_receive function and represented by the structure skb. The verification code is added to the beginning of this function. The same message key code operation is performed on the two consecutive data areas of the header and data part of the skb to obtain the message key code of the OVS side, and then compared with the message key code carried in the message. If the two message key codes are the same, it means that the identity of the message sender is the trusted VM when OVS was created. The message sent by it is received and handed over to OVS for further processing. If they are different, it means that the message may be sent by a malicious VM and the data frame is discarded.

Images