Method for realizing openstack virtual machine noVNC secure communication based on national secret

Abstract

The invention discloses a method for realizing openstack virtual machine noVNC secure communication based on national secret, and relates to the technical field of cloud computing, and the method comprises the steps: firstly introducing adaptive SM2 and SM4 algorithms for a VNCrypt part of a VNC protocol, and deeply transforming a QEMU source code to process national secret encrypted data; a certificate, a public key, a private key and a private key are generated by using SM2 and stored in a PEM format and are managed, controlled and distributed by OpenStack-Barbican; when a user creates a virtual machine, the OpenStack enables the QEMU to load a state secret certificate, and the secret key starts encryption verification; a console url is obtained, and Nova generates token binding key information with an abstract by using SM3; and the proxy end and the two ends negotiate an encryption mode, a VeNCrypt link is established according to the terminal type of the server, then an SM4 is used for encrypting a challenge password, and the server end decrypts and verifies to complete a closed loop. According to the method and the system, the virtual machine noVNC can guarantee the information security in some scenes with relatively high data security requirements.

Description

Technical Field

[0001] The present invention relates to the technical field of cloud computing, in particular to a method for realizing noVNC secure communication of an openstack virtual machine based on national encryption. Background Art

[0002] In today's digital age, remote desktop access technology plays a key role. Among them, VNC (Virtual Network Computer) has attracted much attention as a widely used remote desktop protocol. It relies on RFB (Remote Frame Buffer Protocol, used for remote display, allowing a client application to remotely access and control a graphical user interface on a server) to build a communication mechanism, and finely defines the transmission process of screen updates, mouse and keyboard events, and control commands, thereby realizing the user's demand for remote access across the network and precise control of another computer desktop environment.

[0003] As a VNC client based on HTML5, noVNC stands out. It has opened up a convenient channel for users in the field of cloud computing, especially in the OpenStack environment, so that users can easily access and flexibly operate virtual machines remotely with the help of a Web browser. In the typical application scenario of OpenStack, the QEMU VNC server is closely bound to the virtual machine startup process and starts with the virtual machine; at the same time, users can use the dedicated interface provided by nova to successfully obtain a special URL containing key information. This URL is not only bound to the host and port details corresponding to the virtual machine VNC server, but also associated with the token used for identity verification. When the client (usually a browser) tries to access the URL, it will first connect to the proxy (nova-novncproxy). During this process, the proxy uses the sha256 algorithm by default to strictly verify the token, and then establishes a TLS channel based on the default RSA algorithm (in some cases, it will also directly establish a TCP connection) to open the socket connection with the server. Once the connection is successful, the server will accurately transmit the real-time display information in the virtual machine's video memory to the client through the proxy at a fixed frequency of every 30ms to ensure the timeliness and smoothness of the remote desktop display.

[0004] However, an in-depth review of the current OpenStack noVNC usage scenarios reveals many potential risks, especially in terms of data security and privacy protection. As the network environment becomes increasingly complex, especially in public networks or untrusted network environments full of unknown risks, noVNC's existing communication architecture has exposed obvious shortcomings. On the one hand, the traditional sha256 algorithm is used for token verification and the default RSA algorithm is used to build communication channels. In the face of high-intensity network attacks, its encryption strength is slightly insufficient, making it difficult to ensure confidentiality during data transmission, and it is very likely that sensitive information in transmission will be intercepted and cracked; on the other hand, in the data storage link, the existing technical means also lack sufficient protection mechanisms and cannot effectively guarantee the integrity of the data, and the risk of data tampering remains high.

[0005] What is particularly critical is that in cloud computing application scenarios such as finance, government, and military, which have extremely high data security requirements, these defects may lead to catastrophic consequences. These fields carry a large amount of critical information. Once the data is leaked or maliciously tampered with, it will not only cause significant economic losses, but may also endanger national security. In addition, over-reliance on traditional foreign encryption algorithms means that my country will be subject to the control of others in the field of information security, and its ability to independently control technology will be greatly reduced.

[0006] To sum up, in the noVNC usage scenario based on the OpenStack cloud environment, it is urgently necessary to introduce a new secure communication method based on the national secret algorithm to reshape the data security line of defense, fill the huge loopholes in the existing technology, and ensure that national information security is firmly protected in the cloud computing era. Summary of the invention

[0007] In view of the needs and shortcomings of current technological development, the present invention provides a method for realizing secure communication of openstack virtual machine noVNC based on national encryption, to realize encryption and identity authentication of openstack virtual machine noVNC access channel through domestic cryptographic suite SM2-SM3-SM4, to realize virtual machine noVNC in certain scenarios with high data security requirements, to ensure information security and to realize secure communication.

[0008] The present invention provides a method for realizing noVNC secure communication of openstack virtual machines based on national encryption, and the technical solution adopted to solve the above technical problems is as follows:

[0009] A method for implementing noVNC secure communication of an openstack virtual machine based on national encryption, comprising the following steps:

[0010] S1. For the VNC protocol VeNCrypt security type and the interaction between QEMU and VNC, introduce and adapt the national encryption SM2 and SM4 algorithms;

[0011] S2. Use the national encryption SM2 to generate certificates, public keys and private keys. The private key is saved in PEM format and distributed by OpenStack-Barbican.

[0012] S3. When the user creates a virtual machine, OpenStack calls QEMU to start and load the national encryption certificate and key, and turns on VNC verification and VeNCrypt encryption;

[0013] S4. When the user obtains the virtual machine console URL, Nova uses the national encryption SM3 algorithm to generate a token with summary information and binds the key information;

[0014] S5. The proxy negotiates the VNC security type with the server and client to ensure the consistency of supporting VeNCrypt encryption mode;

[0015] S6. The proxy nova-novncproxy loads the national secret certificate and private key according to the VeNCrypt subtype of the server to establish a VeNCrypt link with the server.

[0016] S7. After the VNC link is established, the agent uses the national encryption SM4 algorithm to encrypt the server challenge and transmit the user password;

[0017] S8. The server uses the national secret SM4 algorithm to decrypt and verify the encrypted information of the agent to complete the user identity authentication closed loop.

[0018] Optionally, the specific implementation process of step S1 includes:

[0019] Conduct an in-depth analysis of the security type of VeNCrypt in the VNC protocol, locate the relevant code modules involved in encryption algorithm calling, key management and security type identification, introduce the national encryption SM2 and SM4 algorithm libraries, and modify the VeNCrypt security type code logic to support calling the national encryption SM2 algorithm for digital certificate generation and key exchange, and using the national encryption SM4 algorithm for data encryption operations;

[0020] Go deep into the QEMU source code and modify the process code for establishing VNC connection and sending and receiving data so that it can recognize and correctly process data encrypted based on the national encryption algorithm.

[0021] Further optionally, the specific implementation process of step S2 includes:

[0022] Use the key generation mechanism of the national secret SM2 algorithm, based on the mathematical principle of elliptic curves, to generate a public key and private key pair, fill in the certificate content according to the X509 digital certificate standard format, and clearly mark the SM2 logo in the public key algorithm, public key parameters, and signature algorithm fields, generate a standard X509 digital certificate, and convert the private key into PEM format for storage;

[0023] With the help of OpenStack-Barbican, a key management service, the generated certificates, public keys and private keys are included in its management and control system, realizing a centralized and secure distribution process, ensuring that each component can accurately obtain the required key materials when communicating.

[0024] Further optionally, the specific implementation process of step S3 includes:

[0025] Add code logic to the libvirt driver section of the OpenStack-Nova source code;

[0026] When the user issues an instruction to create a virtual machine, the added code logic will read the pre-configured national encryption certificate and private key file path and load them into the memory; at the same time, it will pass parameters to QEMU to enable VNC verification and VeNCrypt encryption to ensure that the virtual machine has a security protection mechanism during the startup process.

[0027] Further optionally, the specific implementation process of step S4 includes:

[0028] In the process code of Nova component generating console url, the national secret SM3 algorithm library is introduced, and the function that originally uses SHA-256 to calculate the token digest is replaced with the national secret SM3 algorithm. The token digest is calculated by the national secret SM3 algorithm, and the calculation result is bound to the host and port information of the virtual machine VNC server and stored in a preset data structure for subsequent verification.

[0029] Further optionally, the specific implementation process of step S5 includes:

[0030] Modify the relevant code of the nova-novncproxy module in the OpenStack-Nova source code;

[0031] When the agent establishes a connection with the server, it receives the VeNCrypt type information fed back by the server, then starts the interaction process with the client, sends a query command to the client, and waits for the client's response; according to the feedback information from the server and client, it adjusts the subsequent communication strategy to ensure that the agent, server, and client reach an agreement on the VNC security type, especially to ensure consistent support for the VeNCrypt encryption mode.

[0032] Further optionally, the specific implementation process of step S6 includes:

[0033] After confirming that the VeNCrypt subtype on the server is X509VNC, nova-novncproxy reads the certificate and private key path generated by the national encryption SM2 algorithm from the configuration file, loads these key materials, and then initiates a connection request using the VeNCrypt protocol. During the connection process, it exchanges and verifies certificates with the server, and establishes an encrypted link by verifying the authenticity and validity of both parties' certificates.

[0034] Further optionally, the specific implementation process of step S7 includes:

[0035] In the nova-novncproxy source code, modify the code logic part that processes the server-side challenge (usually located in the function related to data reception and processing); when receiving the challenge from the server, capture the password information entered by the user in the browser, call the national encryption SM4 algorithm library, use the user password as the encryption key, encrypt the challenge, package the encrypted result with password-related information (such as the password hash value or other identification information), and send it to the server.

[0036] Further optionally, the specific implementation process of step S8 includes:

[0037] In the QEMU / VNC related source code, the national secret SM4 algorithm decryption module is embedded for the encrypted information receiving agent process;

[0038] When receiving the data sent by the agent, the embedded SM4 algorithm decryption module is called, and the extracted password information is used as the decryption key to decrypt the encrypted challenge;

[0039] After decryption is completed, the decrypted result is compared with the original challenge value. If the two are consistent, it means that the user identity authentication is passed and the normal data transmission channel is opened, otherwise the connection is disconnected.

[0040] The method of realizing noVNC secure communication of openstack virtual machine based on national encryption of the present invention has the following beneficial effects compared with the prior art:

[0041] 1. The present invention implements encryption and identity authentication of the openstack virtual machine noVNC access channel through the domestic cryptographic suite SM2-SM3-SM4, and implements the virtual machine noVNC in certain scenarios with high data security requirements, ensures information security, and realizes secure communication;

[0042] 2. The present invention enables the X509VNC security type of VeNCrypt, encrypts the VNC access channel, prevents the access channel from being hijacked, and ensures the security of data transmission; at the same time, the user is required to enter a password for VNC identity authentication, which can effectively isolate illegal access and increase the security of noVNC; based on the national secret SM2 algorithm, a digital certificate, a public key, and a secret key are generated to implement VNC access channel encryption based on the X509VNC type, which ensures security strength while also improving the efficiency of encryption and decryption;

[0043] 3. The present invention is a transformation based on existing cloud computing infrastructures such as OpenStack and QEMU. By modifying the source code (such as OpenStack-Nova source code, QEMU / VNC related source code) to achieve the adaptation of the national encryption algorithm and the addition of security functions, it can be well integrated with the existing cloud computing environment. This means that when enterprises or institutions adopt this solution, there is no need to replace the existing infrastructure on a large scale, which reduces the upgrade cost and can effectively improve the security of remote access to virtual machines in their cloud computing environment;

[0044] 4. Use OpenStack-Barbican to manage and distribute certificates and keys, and incorporate key materials into a centralized management and control system. This approach can achieve full life cycle management of keys, including standardized operations in the generation, storage, distribution, and destruction stages, thereby improving the security and efficiency of key management and reducing security risks caused by poor key management. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Attached Figure 1 It is a flow chart of the method of embodiment 1 of the present invention. DETAILED DESCRIPTION

[0046] In order to make the technical solution, the technical problem solved and the technical effect of the present invention more clearly understood, the technical solution of the present invention is clearly and completely described below in conjunction with specific embodiments.

[0047] Embodiment 1:

[0048] Combined with Figure 1This embodiment proposes a method for implementing noVNC secure communication of an openstack virtual machine based on national encryption, which includes the following steps:

[0049] S1. For the VNC protocol VeNCrypt security type and the interaction between QEMU and VNC, the national encryption SM2 and SM4 algorithms are introduced and adapted. The specific implementation process includes:

[0050] Conduct in-depth analysis of the security type of VeNCrypt in the VNC protocol, and locate the relevant code modules involved in encryption algorithm calls, key management, and security type identification (such as in the core code files of the VNC protocol implementation);

[0051] Introduce the national secret SM2 and SM4 algorithm libraries, and modify the VeNCrypt security type code logic to support calling the national secret SM2 algorithm for digital certificate generation and key exchange, and using the national secret SM4 algorithm for data encryption operations;

[0052] We went deep into the QEMU source code and modified the process code for establishing a connection with VNC and sending and receiving data so that it can recognize and correctly process data encrypted based on the national encryption algorithm, ensuring that the interaction between QEMU and VNC can adapt to the requirements of the national encryption algorithm.

[0053] S2. Use the national encryption SM2 to generate certificates, public keys and private keys. The private key is saved in PEM format and distributed by OpenStack-Barbican. The specific implementation process includes:

[0054] Use the key generation mechanism of the national secret SM2 algorithm, based on the mathematical principle of elliptic curves, to generate a public key and private key pair, fill in the certificate content according to the X509 digital certificate standard format, such as the certificate subject, validity period, issuer and other information, and clearly mark the SM2 logo in the public key algorithm, public key parameters, and signature algorithm fields, generate a standard X509 digital certificate, and convert the private key into PEM format for storage;

[0055] With the help of OpenStack-Barbican, a key management service, the generated certificates, public keys and private keys are included in its management and control system; through the Barbican API interface, centralized storage and secure distribution of certificates and keys are achieved, ensuring that each component can accurately obtain the required key materials during communication.

[0056] S3. When a user creates a virtual machine, OpenStack calls QEMU to start and load the national encryption certificate and key, and turns on VNC verification and VeNCrypt encryption. The specific implementation process includes:

[0057] Add code logic to the libvirt driver section of the OpenStack-Nova source code;

[0058] When the user issues an instruction to create a virtual machine, the added code logic will read the pre-configured national encryption certificate and private key file path and load them into the memory; at the same time, it will pass parameters to QEMU to enable VNC verification and VeNCrypt encryption to ensure that the virtual machine has a security protection mechanism during the startup process.

[0059] S4. When the user obtains the virtual machine console URL, Nova uses the national encryption SM3 algorithm to generate a token with summary information and binds key information. The specific implementation process includes:

[0060] In the process code of Nova component generating console url (specifically in the function module responsible for generating console url in Nova), introduce the national secret SM3 algorithm library, replace the function that originally uses SHA-256 to calculate the token summary with the national secret SM3 algorithm, calculate the token summary through the national secret SM3 algorithm, and bind the calculation result with the host and port information of the virtual machine VNC server, and store it in a preset data structure (such as a dictionary or database table) for subsequent verification.

[0061] S5. The proxy negotiates the VNC security type with the server and client to ensure the consistency of supporting VeNCrypt encryption mode. The specific implementation process includes:

[0062] Modify the relevant codes of the nova-novncproxy module in the OpenStack-Nova source code (mainly functions related to connection establishment and interaction);

[0063] When the agent establishes a connection with the server, it receives the VeNCrypt type information fed back by the server, then starts the interaction process with the client, sends a query command to the client, and waits for the client's response; according to the feedback information from the server and client, it adjusts the subsequent communication strategy to ensure that the agent, server, and client reach an agreement on the VNC security type, especially to ensure consistent support for the VeNCrypt encryption mode.

[0064] S6. The proxy nova-novncproxy loads the national secret certificate and private key to establish a VeNCrypt link with the server based on the VeNCrypt subtype of the server. The specific implementation process includes:

[0065] After confirming that the VeNCrypt subtype on the server is X509VNC, nova-novncproxy reads the certificate and private key path generated by the national encryption SM2 algorithm from the configuration file, loads these key materials, and then initiates a connection request using the VeNCrypt protocol. During the connection process, it exchanges and verifies certificates with the server, and establishes an encrypted link by verifying the authenticity and validity of both parties' certificates.

[0066] S7. After the VNC link is established, the agent uses the national encryption SM4 algorithm to encrypt the server challenge and transmit the user password. The specific implementation process includes:

[0067] In the nova-novncproxy source code, modify the code logic part that processes the server-side challenge (usually located in the function related to data reception and processing); when receiving the challenge from the server, capture the password information entered by the user in the browser, call the national encryption SM4 algorithm library, use the user password as the encryption key, encrypt the challenge, package the encrypted result with password-related information (such as the password hash value or other identification information), and send it to the server.

[0068] S8. The server uses the national secret SM4 algorithm to decrypt and verify the encrypted information of the proxy end to complete the user identity authentication closed loop. The specific implementation process includes:

[0069] In the QEMU / VNC related source code, the national secret SM4 algorithm decryption module is embedded for the encrypted information receiving agent process;

[0070] When receiving the data sent by the agent, the embedded SM4 algorithm decryption module is called, and the extracted password information is used as the decryption key to decrypt the encrypted challenge;

[0071] After decryption is completed, the decrypted result is compared with the original challenge value. If the two are consistent, it means that the user identity authentication is passed and the normal data transmission channel is opened, otherwise the connection is disconnected.

[0072] In summary, the method of realizing secure communication of openstack virtual machine noVNC based on national encryption of the present invention is adopted, and the encryption and identity authentication of the openstack virtual machine noVNC access channel are realized through the domestic cryptographic suite SM2-SM3-SM4, so that the virtual machine noVNC can be used in some scenarios with high data security requirements, thereby ensuring information security and realizing secure communication.

[0073] The above specific examples are used to explain the principles and implementation methods of the present invention in detail. These examples are only used to help understand the core technical content of the present invention. Based on the above specific embodiments of the present invention, any improvements and modifications made by technicians in this technical field without departing from the principles of the present invention should fall within the scope of patent protection of the present invention.

Claims

1. A method for implementing noVNC secure communication of openstack virtual machines based on national encryption, characterized in that: The steps include: S1. For the VNC protocol VeNCrypt security type and the interaction between QEMU and VNC, introduce and adapt the national encryption SM2 and SM4 algorithms; S2. Use the national encryption SM2 to generate certificates, public keys and private keys. The private key is saved in PEM format and distributed by OpenStack-Barbican. S3. When the user creates a virtual machine, OpenStack calls QEMU to start and load the national encryption certificate and key, and turns on VNC verification and VeNCrypt encryption; S4. When the user obtains the virtual machine console URL, Nova uses the national encryption SM3 algorithm to generate a token with summary information and binds the key information; S5. The proxy negotiates the VNC security type with the server and client to ensure the consistency of supporting VeNCrypt encryption mode; S6. The proxy nova-novncproxy loads the national secret certificate and private key according to the VeNCrypt subtype of the server to establish a VeNCrypt link with the server. S7. After the VNC link is established, the agent uses the national encryption SM4 algorithm to encrypt the server challenge and transmit the user password; S8. The server uses the national secret SM4 algorithm to decrypt and verify the encrypted information of the agent to complete the user identity authentication closed loop.

2. According to claim 1, a method for realizing openstack virtual machine noVNC secure communication based on national encryption, characterized in that: The specific implementation process of step S1 includes: Conduct an in-depth analysis of the security type of VeNCrypt in the VNC protocol, locate the relevant code modules involved in encryption algorithm calling, key management and security type identification, introduce the national encryption SM2 and SM4 algorithm libraries, and modify the VeNCrypt security type code logic to support calling the national encryption SM2 algorithm for digital certificate generation and key exchange, and using the national encryption SM4 algorithm for data encryption operations; Go deep into the QEMU source code and modify the process code for establishing VNC connection and sending and receiving data so that it can recognize and correctly process data encrypted based on the national encryption algorithm.

3. According to claim 2, a method for realizing openstack virtual machine noVNC secure communication based on national encryption is characterized in that: The specific implementation process of step S2 includes: Use the key generation mechanism of the national secret SM2 algorithm, based on the mathematical principle of elliptic curves, to generate a public key and private key pair, fill in the certificate content according to the X509 digital certificate standard format, and clearly mark the SM2 logo in the public key algorithm, public key parameters, and signature algorithm fields, generate a standard X509 digital certificate, and convert the private key into PEM format for storage; With the help of OpenStack-Barbican, a key management service, the generated certificates, public keys and private keys are included in its management and control system, realizing a centralized and secure distribution process, ensuring that each component can accurately obtain the required key materials when communicating.

4. According to claim 3, a method for realizing openstack virtual machine noVNC secure communication based on national encryption is characterized in that: The specific implementation process of step S3 includes: Add code logic to the libvirt driver section of the OpenStack-Nova source code; When the user issues an instruction to create a virtual machine, the added code logic will read the pre-configured national encryption certificate and private key file path and load them into the memory; at the same time, it will pass parameters to QEMU to enable VNC verification and VeNCrypt encryption to ensure that the virtual machine has a security protection mechanism during the startup process.

5. According to claim 4, a method for realizing openstack virtual machine noVNC secure communication based on national encryption is characterized in that: The specific implementation process of step S4 includes: In the process code of Nova component generating console url, the national secret SM3 algorithm library is introduced, and the function that originally uses SHA-256 to calculate the token digest is replaced with the national secret SM3 algorithm. The token digest is calculated by the national secret SM3 algorithm, and the calculation result is bound to the host and port information of the virtual machine VNC server and stored in a preset data structure for subsequent verification.

6. A method for realizing openstack virtual machine noVNC secure communication based on national encryption according to claim 5, characterized in that: The specific implementation process of step S5 includes: Modify the relevant code of the nova-novncproxy module in the OpenStack-Nova source code; When the proxy establishes a connection with the server, it receives the VeNCrypt type information fed back by the server, then starts the interaction process with the client, sends a query command to the client, and waits for the client's response; based on the feedback information from the server and client, it adjusts the subsequent communication strategy to ensure that the proxy, server, and client reach an agreement on the VNC security type.

7. A method for realizing openstack virtual machine noVNC secure communication based on national encryption according to claim 6, characterized in that: The specific implementation process of step S6 includes: After confirming that the VeNCrypt subtype on the server is X509VNC, nova-novncproxy reads the certificate and private key path generated by the national encryption SM2 algorithm from the configuration file, loads these key materials, and then initiates a connection request using the VeNCrypt protocol. During the connection process, it exchanges and verifies certificates with the server, and establishes an encrypted link by verifying the authenticity and validity of both parties' certificates.

8. According to claim 7, a method for realizing openstack virtual machine noVNC secure communication based on national encryption is characterized in that: The specific implementation process of step S7 includes: In the nova-novncproxy source code, modify the code logic for processing server-side challenges; When receiving the challenge from the server, capture the password information entered by the user in the browser, call the national encryption SM4 algorithm library, use the user password as the encryption key, encrypt the challenge, package the encrypted result with the password-related information, and send it to the server.

9. A method for realizing openstack virtual machine noVNC secure communication based on national encryption according to claim 8, characterized in that: The specific implementation process of step S8 includes: In the QEMU / VNC related source code, the national secret SM4 algorithm decryption module is embedded for the encrypted information receiving agent process; When receiving the data sent by the agent, the embedded SM4 algorithm decryption module is called, and the extracted password information is used as the decryption key to decrypt the encrypted challenge; After decryption is completed, the decrypted result is compared with the original challenge value. If the two are consistent, it means that the user identity authentication is passed and the normal data transmission channel is opened, otherwise the connection is disconnected.

Images