Virtualization simulation system construction method for testing commercial password software

Abstract

The invention discloses a method for constructing a virtualization simulation system for testing commercial password software. The method comprises the following steps: S1, a function decoupling and abstraction stage; s2, a container mirroring and software construction stage; s3, a service arrangement and configuration stage; s4, a virtual environment starting and running stage; and S5, a virtual environment destroying stage. According to the method, the construction cost and the deployment complexity of the commercial password application security evaluation test environment can be greatly reduced, and the resource utilization rate and the environment consistency are improved.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and more specifically to a method for constructing a virtualized simulation system for testing commercial cryptographic software. Background Technology

[0002] Currently, conducting standardized security assessments of commercial cryptographic applications requires building a complete testing environment that conforms to the relevant standards of the State Cryptography Administration. This environment typically includes the following core hardware devices: Application server: The server that deploys the business system under test. When password operations are required, it completes the corresponding password operations by calling the API (Application Programming Interface) provided by the hardware server's cryptographic machine.

[0003] Server cryptographic machine: A dedicated hardware security device that provides high-performance cryptographic operations, such as SM2 / SM3 / SM4 / SM9 national cryptographic algorithms, and offers services including key generation, storage, and dedicated encryption / decryption operations. It is used to ensure the confidentiality, integrity, authenticity, and non-repudiation of data.

[0004] Smart cryptographic key: A hardware cryptographic device using a USB interface to implement security functions such as user authentication, multi-factor authentication, digital signature, and offline key protection.

[0005] like Figure 1 As shown, the working principle of the existing technical solution is as follows: The application under test is deployed on an application server. When the application under test reaches a stage requiring password protection, such as user login, encrypted data transmission, or encrypted data storage, the application server will call the API service interface provided by the server's cryptographic machine via the network or locally, sending the raw data to the dedicated server cryptographic machine. After performing encryption, decryption, signing, and verification operations, the server cryptographic machine returns the calculation results to the application server. The smart password key is usually inserted directly into the server or client computer by the administrator or user for authentication. The entire environment relies on physical hardware devices, and the devices communicate with each other through physical network interfaces or USB interfaces.

[0006] While existing solutions based entirely on hardware can meet the requirements for high security and high computing power, they have the following shortcomings in cryptographic evaluation practice, especially in cryptographic evaluation of small and medium-sized systems and during the R&D testing phase. The root cause of these shortcomings is directly related to the physical properties of the hardware devices: (1) High deployment complexity and long cycle: Because it relies on physical hardware, the data center environment must be adapted first. This includes reserving rack space, configuring redundant power supplies, and controlling temperature and humidity within reasonable ranges before hardware wiring and driver debugging can proceed. Furthermore, different manufacturers' hardware cryptographic devices and UKeys (USB Keys, smart cryptographic keys) have interface compatibility issues. For example, some manufacturers use proprietary communication protocols, requiring custom-developed adapter plugins, resulting in a long deployment cycle for a single environment. This is because the physical form of the hardware devices limits deployment flexibility, and the industry lacks a unified hardware integration and adaptation standard, requiring compatibility testing for each device individually. (2) Huge cost investment and heavy maintenance burden: Hardware-based cryptographic servers are generally expensive, requiring the use of three types of physical servers, security gateways, and data center infrastructure such as UPS (Uninterruptible Power Supply) and fire suppression systems. This causes the deployment cost of small-scale cryptographic systems to rise exponentially. Furthermore, there are long-term costs associated with hardware depreciation, data center maintenance requiring dedicated personnel, and equipment inspections. This situation arises because hardware cryptographic products rely on dedicated encryption chips and precision manufacturing processes, leading to high research and development and production costs. (3) Low resource utilization and poor reusability: In some low-computing-power scenarios, the demand is often intermittent invocation of server cryptographic machines. The computing power utilization of hardware cryptographic machines is low, easily leading to idle resources. Furthermore, a single hardware device can only physically connect to a limited number of servers, resulting in low resource scheduling efficiency. This phenomenon is caused by the physical exclusivity of the hardware devices, which prevents dynamic resource allocation and makes it difficult to achieve sharing and reuse across multiple scenarios.

[0007] Therefore, there is an urgent need in this field for a new construction scheme for a security assessment and testing environment for commercial cryptographic applications that can overcome the above-mentioned defects. Summary of the Invention

[0008] The technical problem to be solved by the present invention is to provide a method for constructing a virtualized simulation system for testing commercial cryptographic software, which can significantly reduce the cost and deployment complexity of constructing a security assessment and testing environment for commercial cryptographic applications, and improve resource utilization and environment consistency.

[0009] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows.

[0010] A method for constructing a virtualized simulation system for testing commercial cryptographic software includes the following steps: S1. Functional Decoupling and Abstraction Phase: Decouple the hardware device functions on which the commercial cryptography application security assessment and testing environment depends; abstract the decoupled functions into independent service modules. S2. Container Image and Software Building Phase: Write image build files for service modules that need to be containerized and build corresponding container images; build corresponding executable programs for service modules that need to run independently to simulate the corresponding hardware device entities; and version-mark each container image and executable program to ensure the consistency and traceability of the environment. S3. Service Orchestration and Configuration Phase: Write container orchestration configuration files to define the dependencies and network topology between the container images obtained in step S2 on the preset container engine and orchestrator; and define the access relationship between the executable program and the containerized environment to form a complete and functionally equivalent virtualization test environment. S4. Virtual Environment Startup and Operation Phase: Based on container orchestration configuration files, the involved containers are started with a single click by executing unified orchestration commands to run the virtualized test environment. S5. Virtual Environment Destruction Phase: Based on the container orchestration configuration file, a unified destruction command is executed to stop all containers with one click to destroy the virtualized test environment and release host hardware resources.

[0011] Preferably, the hardware devices in step S1 include a server cryptographic machine, a smart cryptographic key, and an application server, and the service modules include a cryptographic operation module, an identity authentication module, and a business processing module. Step S1 specifically includes: analyzing the cryptographic operation function of the server cryptographic machine, decoupling and abstracting it into a pure software-implemented cryptographic operation module; analyzing the identity authentication function of the smart cryptographic key, decoupling and abstracting it into a pure software-implemented identity authentication module; analyzing the business processing function of the application server, decoupling and abstracting it into a pure software-implemented business processing module; and further, step S1 also includes defining interface specifications between the modules to ensure loose coupling and standardized interaction between modules.

[0012] Preferably, step S2 specifically includes: Build a virtual server cryptographic machine container image for the cryptographic operation module: Based on the NodeJS base image, it integrates functional implementation interfaces that support, but are not limited to, SM2, SM3, and SM4 national cryptographic algorithms, exposes standard cryptographic service API interfaces, and manages keys through a defined key configuration file; Build a virtual smart key client executable program for the identity authentication module: Use NodeJS's SEA technology to generate a cross-platform executable application that simulates the certificate storage, signature verification and signing functions of the smart key in software form, and allows users to view the stored digital certificates. Build a virtual application server container image for the business processing module: Configure the password service call endpoint based on the business system's operating environment; use the JSON Web Token mechanism for identity authentication; optimize the final size of the virtual application server container image using a multi-layer container building mechanism; use Prisma ORM technology to define a data model for the business system under test, and set fields for confidentiality and integrity verification in this data model; Build an Nginx reverse proxy container image: Configure reverse proxy and SSL protocol technologies, and flexibly configure cipher suites and server digital certificates in the SSL protocol to simulate the security requirements of various commercial cryptographic application security assessment test environments; Build a database management system container image: integrate data storage functionality and support custom database usernames and passwords.

[0013] Preferably, the key configuration file uses a .key.json file for key management; the .key.json file contains a UUID for uniquely identifying the key, a type field for indicating the algorithm type, an algorithm field for specifying the specific algorithm, and the actual key value key or public-private key pair privateKey and publicKey represented in hexadecimal form.

[0014] Preferably, the virtualization test environment in step S3 includes the following containers and executable programs: a virtual server cryptographic machine container, a virtual application server container, a virtual smart key client executable program, an Nginx reverse proxy container, and a database management system container; the virtual server cryptographic machine container, virtual application server container, Nginx reverse proxy container, and database management system container are uniformly managed by the container engine and orchestrator; step S3 specifically includes: Configure a service discovery mechanism: ensure that containers can access each other by service name; Configure the network endpoint information required for the virtual smart key client executable to access the containerized environment; Configure resource limits and health check policies: Define storage volume mappings to enable persistent data, shared data, and injection of application configuration files into containers.

[0015] Preferably, step S4 specifically includes: When a user executes the command `docker compose up -d`, the container engine starts the containers involved according to the container orchestration configuration file. Once a container starts, it automatically forms an internal network, and each container discovers each other through the container's internal virtual network service. External users access the ports exposed by the Nginx reverse proxy container through a common browser; Once the virtualized testing environment is running, it responds to business requests initiated by external users through a browser and executes a simulated testing process for the security of commercial cryptographic applications.

[0016] Preferably, the simulation test process includes, but is not limited to, at least one of the following: A. Identity authentication process based on digital signature: The user manually starts the virtual smart key client executable program and initiates a login request to the virtual application server container via the Nginx reverse proxy container. The virtual application server container requests a challenge random number from the virtual server cryptographic machine container. The virtual server cryptographic machine container generates a challenge random number and forwards it to the virtual smart key client executable program through the virtual application server container and the Nginx reverse proxy container. The user signs the challenge random number using the virtual smart key provided by the virtual smart key client executable program and returns the signature value to the Nginx reverse proxy container. The Nginx reverse proxy container forwards the signature value to the virtual application server container. After receiving the signature value, the virtual application server container initiates a signature verification request to the virtual server cryptographic machine container. At the same time, the virtual application server container interacts with the database management system container to verify the user's credentials. After successful signature verification and credential verification, identity authentication is completed. B. Data encryption and storage process: The user submits plaintext data to be protected through a browser; the request is forwarded to the virtual application server container via the Nginx reverse proxy container; the virtual application server container forwards the encrypted request to the virtual server cryptographic machine container; the virtual server cryptographic machine container encrypts the plaintext, generates a ciphertext value, and simultaneously calculates its integrity check value, and then returns both; the virtual application server container stores the received ciphertext value and check value into the database management system container. C. Data decryption and query process: The user requests to view the stored encrypted value through a browser; the request is forwarded to the virtual application server container via the Nginx reverse proxy container; the virtual application server container retrieves the corresponding ciphertext value from the database management system container; then, it sends a decryption request to the virtual server cryptographic machine container; the virtual server cryptographic machine container uses the corresponding key to decrypt the ciphertext value, recovers the plaintext value, and returns it; the virtual application server container returns the decrypted plaintext value to the user's browser via the Nginx reverse proxy container.

[0017] Preferably, step S5 specifically involves: the user executing the `docker compose down` command to stop all containers with one click; the orchestrator automatically stops and removes all containers and related resources to release host hardware resources; it also supports immediately starting a new test environment or retaining the image for subsequent reuse.

[0018] Due to the adoption of the above technical solutions, the technical progress achieved by this invention is as follows.

[0019] This invention achieves technical effects such as "cost reduction, efficiency improvement, reuse, and scalability" through software and virtualization technologies, as detailed below: (1) Cost optimization effect: There is no need to purchase expensive hardware cryptographic equipment, eliminating the cost of purchasing physical cryptographic machines, dedicated servers, smart cryptographic keys, etc. At the same time, there is no need to bear the costs of data center operation and maintenance and hardware depreciation, which greatly reduces hardware costs. In addition, cryptographic software environments can be rented on demand through the cloud platform, further lowering the threshold for use by small and medium-sized enterprises. (2) Deployment efficiency improvement effect: Hardware-based cryptographic environments can take weeks or even longer to deploy, while virtualized cryptographic software environments can be deployed and used on the same day with a complete configuration file, significantly improving deployment efficiency. Furthermore, they support multiple environment rebuilds and tests daily, meeting iterative cryptographic assessment needs (such as rapid compliance verification after software version updates). The deployment process requires no professional hardware maintenance personnel; developers can complete it independently using scripts. Through container images and orchestration scripts, the cryptographic software environment can be started and copied in seconds, making it particularly suitable for agile development, automated testing, and educational demonstrations.

[0020] (3) Resource reuse effect: A single host server can support multiple independent cryptographic evaluation test environments, improving the utilization of physical hardware resources. Furthermore, Docker images ensure environment consistency: container images guarantee that the environment (including algorithm library version and system configuration) is completely consistent every time it starts, effectively avoiding deviations in test results caused by environmental differences and improving the accuracy and reproducibility of the cryptographic software environment.

[0021] (4) Enhance flexibility and scalability: Deployers can easily build test environments with different algorithms and configurations by modifying image build files or container orchestration configuration files, creating different commercial cryptographic software simulation environments. This facilitates compatibility and security comparison testing, greatly enhancing flexibility and scalability. Attached Figure Description

[0022] Figure 1A diagram of the hardware equipment for a security assessment and testing environment for existing commercial cryptographic applications; Figure 2 This is a flowchart of the method of the present invention; Figure 3 This is a flowchart illustrating the identity authentication process based on digital signatures in this invention. Figure 4 This is a flowchart illustrating the data encryption and storage process of the present invention. Figure 5 This is a flowchart of the data decryption query process of the present invention. Detailed Implementation

[0023] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0024] A method for constructing a virtualization simulation system for testing commercial cryptographic software employs Docker container virtualization technology. It implements the functions of devices such as server cryptographic machines and application servers in software form, encapsulating them into independent Docker images. Through container orchestration technology, it manages and runs these images uniformly, thereby simulating a complete and functionally equivalent hardware and software cryptographic evaluation environment (a commercial cryptographic application security assessment and testing environment). Figure 2 As shown, it includes the following steps: S1. Functional Decoupling and Abstraction Phase: Decouple the hardware functions on which the commercial cryptography application security assessment and testing environment depends; abstract the decoupled functions into independent service modules.

[0025] In this step, the hardware devices include a server cryptographic machine, a smart cryptographic key, and an application server, while the service modules include a cryptographic calculation module, an identity authentication module, and a business processing module.

[0026] This step specifically includes: Analyze the cryptographic operation function of the server's cryptographic machine, decouple and abstract it into a pure software-implemented cryptographic operation module; analyze the identity authentication function of the smart cryptographic key, decouple and abstract it into a pure software-implemented identity authentication module; analyze the business processing function of the application server, decouple and abstract it into a pure software-implemented business processing module. Define interface specifications between modules to ensure loose coupling and standardized interaction between modules.

[0027] S2. Container Image and Software Building Phase: Write image build files (Dockerfiles) for service modules that need to be containerized and build corresponding container images. Build corresponding executable programs for service modules that need to run independently to simulate the corresponding hardware devices. Version tag each container image and executable program to ensure environment consistency and traceability.

[0028] Specifically, writing a Dockerfile and building the corresponding Docker image includes: A virtual server cryptographic machine container image is built for the cryptographic operation module: Based on a NodeJS base image, it adopts the standard NodeJS API interface, integrates the functional implementation interface of Chinese cryptographic algorithms (SM2, SM3, SM4, etc.), exposes standard cryptographic service API interfaces, and has strong extensibility. Key management is performed through a defined key configuration file, which can be easily extended to more international algorithm implementations. Specifically, the key configuration file uses a .key.json file for key management. The .key.json file includes uuid, type, algorithm, key or privateKey and publicKey. The specific key value is not directly provided to the outside world; instead, a uuid value is provided for unique identification of the key. The type field indicates the algorithm type to confirm the types of algorithms supported by the key, such as message authentication code, symmetric, and asymmetric algorithms. The algorithm field specifies the specific algorithm, such as SM3, SM4, SM2, etc. The key refers to the actual key value, represented in hexadecimal form. privateKey and publicKey refer to the public and private key pairs, represented in hexadecimal form.

[0029] Build a virtual application server container image for the business processing module: Configure the password service call endpoint based on the business system's operating environment; use JWT (JSON Web Token) mechanism for identity authentication; optimize the final size of the virtual application server container image using Docker's multi-layer build mechanism; use Prisma ORM technology to define a data model for the business system under test, and set database fields such as password, content, and checksum in the data model as fields for confidentiality and integrity verification.

[0030] Build an Nginx reverse proxy container image: Configure reverse proxy and SSL protocol technologies, and flexibly configure cipher suites and server digital certificates in the SSL protocol to simulate the security requirements of various commercial cryptographic application security assessment and testing environments.

[0031] Build a database management system container image: integrate data storage functions and support custom database usernames and passwords, specifically for PostgreSQL databases.

[0032] Write the source code and build the corresponding executable program, including: A virtual smart key client executable program is built for the identity authentication module: This program simulates the certificate storage and signature verification functions of a smart key in software. Specifically, using NodeJS's SEA (Single executable applications) technology, a cross-platform executable application is generated that can run on Windows and macOS operating systems. This application can view stored digital certificates, perform signature verification using national cryptographic algorithms, and facilitate program distribution and use.

[0033] S3. Service Orchestration Configuration Phase: Write the container orchestration configuration file (Docker Compose configuration file). On the preset container engine and orchestrator, define the dependencies and network topology between the container images obtained in step S2; and define the access relationship between the executable program and the containerized environment to form a complete and functionally equivalent virtualization test environment.

[0034] The virtualization testing environment includes the following containers and executables: a virtual server cryptographic machine container, a virtual application server container, a virtual smart key client executable, an Nginx reverse proxy container, and a database management system container. These containers are managed uniformly by the container engine and orchestrator. Together, they constitute the virtualization simulation system. Specifically: Virtual server cryptographic machine container: This container runs a software cryptographic middleware that simulates the core API interfaces of a real server cryptographic machine, such as encryption / decryption and signature verification interfaces, by implementing corresponding national cryptographic algorithms. It receives cryptographic service requests from the virtual application server container, executes the software algorithm calculations, and returns the results.

[0035] Virtual Application Server Container: This container is used to deploy the business system under test. Internally, it is configured to direct cryptographic computation requests to the network address and port of the virtual server cryptographic machine container, rather than the traditional hardware IP address.

[0036] Virtual Smart Key Client Executable: This software runs a simulated smart key, providing functions such as certificate storage and signature verification. It simulates one or more virtual USB keys, and the certificate and key files stored internally are mounted to the client as encrypted volumes for its use.

[0037] Nginx Reverse Proxy Container: This container runs an Nginx server, serving as the unified entry point for the entire application system. It receives HTTP / HTTPS requests from external users and load balances these requests to backend virtual application server containers according to configured rules. This container is used to simulate a common web front-end proxy architecture in a production environment to test end-to-end authentication mechanisms, communication confidentiality, and communication integrity password requirements.

[0038] Database Management System Container: This container runs a PostgreSQL database to store application data from the business system under test. The virtual application system encrypts and stores sensitive fields in the database to test the confidentiality and integrity protection mechanisms of data storage.

[0039] Container engine and orchestrator: As the underlying core, it is responsible for creating, running, and managing all the containers mentioned above. Tools such as Docker Compose can be used for orchestration, defining dependencies, health status, network connectivity, and other related configurations between containers.

[0040] This architecture fully simulates the entire chain of commercial cryptographic applications, from network access, business processing, identity authentication, cryptographic services to data storage, providing a comprehensive virtualized commercial cryptographic software simulation environment.

[0041] This step specifically includes: Configure a service discovery mechanism: Ensure that containers can access each other through service names. For example, the virtual application server container connects to the virtual server cryptography machine container through the service name virtual-hsm, and connects to the database management system container through the service name postgres-db. Configure the network endpoint information required for the virtual smart key client executable to access the containerized environment; Configure resource limits and health check policies: Define storage volume mappings to enable persistent data, shared data, and injection of application configuration files into containers.

[0042] S4. Virtual Environment Startup and Operation Phase: Based on the container orchestration configuration file, the involved containers are started with one click by executing unified orchestration commands to run the virtualized test environment.

[0043] This step specifically includes: When a user executes the command `docker compose up -d`, the container engine starts the containers involved according to the container orchestration configuration file.

[0044] Once a container starts, it automatically forms an internal network, and containers discover each other through Docker's internal virtual network service.

[0045] External users access the ports exposed by the Nginx reverse proxy container through a common browser. These ports can be customized by the container orchestration configuration file, such as port 443, port 80, etc.

[0046] Once the virtualized testing environment is running, it responds to business requests initiated by external users through a browser and executes a simulated testing process for the security of commercial cryptographic applications.

[0047] The following diagrams illustrate three typical business processes: (1) Identity authentication process based on digital signature (e.g.) Figure 3 (as shown) The user manually launches the virtual smart key client executable and initiates a login request to the virtual application server container via the Nginx reverse proxy container. The virtual application server container requests a challenge random number from the virtual server cryptographic machine container. The virtual server cryptographic machine container generates a challenge random number and forwards it to the virtual smart key client executable via both the virtual application server container and the Nginx reverse proxy container. The user signs the challenge random number using the virtual smart key provided by the virtual smart key client executable and returns the signature value to the Nginx reverse proxy container. The Nginx reverse proxy container forwards the signature value to the virtual application server container. Upon receiving the signature value, the virtual application server container initiates a signature verification request to the virtual server cryptographic machine container. Simultaneously, the virtual application server container interacts with the database management system container to verify user credentials (such as username and password). After successful signature verification and credential verification, identity authentication is completed, and the user is allowed access. This process simulates and tests an identity authentication process based on digital signatures.

[0048] (2) Data encryption and storage process (e.g.) Figure 4 (as shown) The user submits plaintext data to be protected through a browser. The request is forwarded to the virtual application server container via the Nginx reverse proxy container. The virtual application server container forwards the encrypted request (containing the plaintext) to the virtual server cryptographic machine container. The virtual server cryptographic machine container encrypts the plaintext using a specified national cryptographic algorithm (such as SM4), generates a ciphertext value, and simultaneously calculates its integrity checksum, then returns both. The virtual application server container stores the received ciphertext value and checksum into the database management system container. This process simulates and tests the confidentiality and integrity protection mechanisms in the data storage stage.

[0049] (3) Data decryption and query process (e.g.) Figure 5 (as shown) A user requests to view a stored encrypted value through a browser. The request is forwarded to the Virtual Application Server (VAS) container via the Nginx reverse proxy container. The VAS container retrieves the corresponding ciphertext value from the database management system container. Then, it sends a decryption request to the VAS cryptographic machine container. The VAS cryptographic machine container decrypts the ciphertext value using the corresponding key, recovers the plaintext value, and returns it. The VAS container then returns the decrypted plaintext value to the user's browser via the Nginx reverse proxy container. This process simulates and tests the authorized user's compliant access to and decryption capabilities for encrypted stored data.

[0050] The simulation test process includes, but is not limited to, the above business processes. The results of cryptographic operations and database operations are ultimately returned along the original path and fed back to the external user through the Nginx reverse proxy container, completing a complete request-response process. This enables the simulation and testing of key points for security assessment of commercial cryptographic applications.

[0051] S5. Virtual Environment Destruction Phase: Based on the container orchestration configuration file, a unified destruction command is executed to stop all containers with one click to destroy the virtualized test environment and release host hardware resources.

[0052] To destroy a virtual environment, users can execute the Docker command (docker compose down) to stop all containers with one click. The orchestrator will automatically stop and remove all containers and related resources to free up host hardware resources such as CPU, memory, and storage space. It also supports immediately starting a new test environment or keeping the image for later reuse.

[0053] The innovative aspects of this invention are as follows: (1) The password function is separated into an independent software module: This invention does not simply simulate hardware cryptographic devices in software, but rather decouples and abstracts their core functions. The cryptographic computation services provided by the hardware cryptographic machine, the identity authentication and key storage services provided by the smart cryptographic key, and the business processing functions of the application server are decoupled from their specific physical form and extracted into standardized service modules in pure software form. Subsequently, using Docker container technology, these service modules are packaged into independent, portable virtual cryptographic device images; or the source code is written and packaged into independent executable programs.

[0054] (2) Containerized one-click deployment test environment: This invention utilizes container orchestration tools such as Docker Compose to abstract the complex topological relationships and dependencies between previously discrete physical devices requiring manual networking, application servers, server cryptographic machines, database servers, etc., into a declarative configuration file. This file defines the service discovery, network interconnection, and startup order of all virtual components, realizing the transformation from device stacking to service collection. It achieves one-click deployment and rapid replication, eliminating the need to concern oneself with complex underlying installation and configuration details. With just one command, the system automatically completes the setup and initialization of the entire heterogeneous environment, significantly shortening deployment time. The entire environment can be easily copied, version-managed, and distributed through an image repository, achieving out-of-the-box usability.

[0055] (3) Efficient reuse of hardware resources: This invention enables refined management and isolation of hardware resources, allowing a single physical server to run multiple independent and complete security evaluation environments simultaneously, greatly improving the utilization rate of hardware resources.

[0056] (4) Environmental consistency assurance: This invention solidifies all components of the cryptographic evaluation environment, including the version of the national cryptographic algorithm library, configuration files, the application under test, and its dependencies, into an immutable Docker image. This image serves as the sole authentic source for environment construction, ensuring that the exact same binary content is used wherever the environment is deployed and run. This eliminates the environment drift problem, and the immutability of the image ensures the reproducibility of evaluation results. Furthermore, any changes to the virtual environment require building a new image version, making all environment changes traceable and auditable. Versioned image management also simplifies rollback, upgrade, and troubleshooting processes.

Claims

1. A method for constructing a virtualized simulation system for testing commercial cryptographic software, characterized in that: Includes the following steps: S1. Functional Decoupling and Abstraction Phase: Decouple the hardware device functions on which the commercial cryptography application security assessment and testing environment depends; abstract the decoupled functions into independent service modules. S2. Container Image and Software Building Phase: Write image build files for service modules that need to be containerized and build corresponding container images; build corresponding executable programs for service modules that need to run independently to simulate the corresponding hardware device entities; and version-mark each container image and executable program to ensure the consistency and traceability of the environment. S3. Service Orchestration and Configuration Phase: Write container orchestration configuration files to define the dependencies and network topology between the container images obtained in step S2 on the preset container engine and orchestrator; and define the access relationship between the executable program and the containerized environment to form a complete and functionally equivalent virtualization test environment. S4. Virtual Environment Startup and Operation Phase: Based on container orchestration configuration files, the involved containers are started with a single click by executing unified orchestration commands to run the virtualized test environment. S5. Virtual Environment Destruction Phase: Based on the container orchestration configuration file, a unified destruction command is executed to stop all containers with one click to destroy the virtualized test environment and release host hardware resources.

2. The method for constructing a virtualization simulation system for testing commercial cryptographic software according to claim 1, characterized in that: The hardware devices in step S1 include a server cryptographic machine, a smart cryptographic key, and an application server. The service modules include a cryptographic operation module, an identity authentication module, and a business processing module. Step S1 specifically includes: analyzing the cryptographic operation function of the server cryptographic machine, decoupling and abstracting it into a pure software-implemented cryptographic operation module; analyzing the identity authentication function of the smart cryptographic key, decoupling and abstracting it into a pure software-implemented identity authentication module; analyzing the business processing function of the application server, decoupling and abstracting it into a pure software-implemented business processing module; step S1 also includes defining the interface specifications between the modules to ensure loose coupling and standardized interaction between the modules.

3. The method for constructing a virtualization simulation system for testing commercial cryptographic software according to claim 2, characterized in that: Step S2 specifically includes: Build a virtual server cryptographic machine container image for the cryptographic operation module: Based on the NodeJS base image, it integrates functional implementation interfaces that support, but are not limited to, SM2, SM3, and SM4 national cryptographic algorithms, exposes standard cryptographic service API interfaces, and manages keys through a defined key configuration file; Build a virtual smart key client executable program for the identity authentication module: Use NodeJS's SEA technology to generate a cross-platform executable application that simulates the certificate storage, signature verification and signing functions of the smart key in software form, and allows users to view the stored digital certificates. Build a virtual application server container image for the business processing module: Configure the password service call endpoint based on the business system's operating environment; use the JSON Web Token mechanism for identity authentication; optimize the final size of the virtual application server container image using a multi-layer container building mechanism; use Prisma ORM technology to define a data model for the business system under test, and set fields for confidentiality and integrity verification in this data model; Build an Nginx reverse proxy container image: Configure reverse proxy and SSL protocol technologies, and flexibly configure cipher suites and server digital certificates in the SSL protocol to simulate the security requirements of various commercial cryptographic application security assessment test environments; Build a database management system container image: integrate data storage functionality and support custom database usernames and passwords.

4. The method for constructing a virtualization simulation system for testing commercial cryptographic software according to claim 3, characterized in that: The key configuration file uses a .key.json file for key management; the .key.json file contains a UUID for uniquely identifying the key, a type field for indicating the algorithm type, an algorithm field for specifying the specific algorithm, and the actual key value key or public-private key pair privateKey and publicKey represented in hexadecimal form.

5. The method for constructing a virtualization simulation system for testing commercial cryptographic software according to claim 3, characterized in that: The virtualization test environment in step S3 includes the following containers and executable programs: a virtual server cryptographic machine container, a virtual application server container, a virtual smart key client executable program, an Nginx reverse proxy container, and a database management system container; the virtual server cryptographic machine container, virtual application server container, Nginx reverse proxy container, and database management system container are uniformly managed by the container engine and orchestrator; step S3 specifically includes: Configure a service discovery mechanism: ensure that containers can access each other by service name; Configure the network endpoint information required for the virtual smart key client executable to access the containerized environment; Configure resource limits and health check policies: Define storage volume mappings to enable persistent data, shared data, and injection of application configuration files into containers.

6. The method for constructing a virtualization simulation system for testing commercial cryptographic software according to claim 5, characterized in that: Step S4 specifically includes: When a user executes the command `docker compose up -d`, the container engine starts the containers involved according to the container orchestration configuration file. Once a container starts, it automatically forms an internal network, and each container discovers each other through the container's internal virtual network service. External users access the ports exposed by the Nginx reverse proxy container through a common browser; Once the virtualized test environment is running, it responds to business requests initiated by external users through a browser and executes a simulated test process for the security of commercial cryptographic applications.

7. A method for constructing a virtualization simulation system for testing commercial cryptographic software according to claim 6, characterized in that: The simulation test process includes, but is not limited to, at least one of the following: A. Identity authentication process based on digital signature: The user manually starts the virtual smart key client executable program and initiates a login request to the virtual application server container via the Nginx reverse proxy container. The virtual application server container requests a challenge random number from the virtual server cryptographic machine container. The virtual server cryptographic machine container generates a challenge random number and forwards it to the virtual smart key client executable program through the virtual application server container and the Nginx reverse proxy container. The user signs the challenge random number using the virtual smart key provided by the virtual smart key client executable program and returns the signature value to the Nginx reverse proxy container. The Nginx reverse proxy container forwards the signature value to the virtual application server container. After receiving the signature value, the virtual application server container sends a signature verification request to the virtual server cryptographic machine container; at the same time, the virtual application server container interacts with the database management system container to verify the user credentials; after successful signature verification and credential verification, identity authentication is completed. B. Data encryption and storage process: Users submit plaintext data to be protected through their browsers; the request is forwarded to the virtual application server container via the Nginx reverse proxy container. The virtual application server container forwards the encryption request to the virtual server cryptographic machine container; the virtual server cryptographic machine container encrypts the plaintext, generates a ciphertext value, and simultaneously calculates its integrity check value, and then returns both; the virtual application server container stores the received ciphertext value and check value into the database management system container. C. Data decryption and query process: The user requests to view the stored encrypted value through a browser; the request is forwarded to the virtual application server container via the Nginx reverse proxy container; the virtual application server container retrieves the corresponding ciphertext value from the database management system container; then, it sends a decryption request to the virtual server cryptographic machine container; the virtual server cryptographic machine container uses the corresponding key to decrypt the ciphertext value, recovers the plaintext value, and returns it; the virtual application server container returns the decrypted plaintext value to the user's browser via the Nginx reverse proxy container.

8. A method for constructing a virtualization simulation system for testing commercial cryptographic software according to claim 5, characterized in that: Step S5 specifically involves the user executing the `docker compose down` command to stop all containers with one click. The orchestrator automatically stops and removes all containers and related resources to free up host hardware resources. It also supports immediately starting a new test environment or retaining the image for later reuse.

Images