Container technology-based password equipment security upgrading method and system

Abstract

The invention discloses a security upgrading method and system for password equipment based on a container technology, and relates to the technical field of information security. According to the method, the configuration file and the key file are separated from the container mirror image and stored in the persistent data volume, so that the risks of loss, damage and leakage of the configuration or the key caused by mirror image replacement in the upgrading process are thoroughly avoided, the security of the upgrading process is greatly improved, and due to the fact that the containers of the new version and the old version share the same persistent data, the security of the upgrading process is greatly improved. The rollback operation only needs to switch the running container instance without recovering or migrating data, and the whole process can be automatically executed and can be completed in seconds, so that the fault recovery time is remarkably shortened, the service continuity is ensured, the container technology ensures the consistency of new version software, the upgrading success rate and the software running stability are improved, and the upgrading efficiency is improved. And the upgrading process is standardized into mirror image pulling, container starting and health checking, and the container is switched if the upgrading process fails, so that automatic and batch deployment is easy.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and in particular to a method and system for security upgrade of cryptographic devices based on container technology. Background Technology

[0002] Container technology packages an application and all its dependencies (such as libraries, binaries, configurations, etc.) into a standardized, lightweight image and runs it in an isolated container, enabling applications to be built once and run anywhere. However, directly applying container technology to cryptographic device upgrade scenarios with extremely high requirements for security, stability, and recoverability faces new challenges, particularly in how to securely manage sensitive configurations and keys and implement a fast and reliable rollback mechanism. Cryptographic devices (such as cryptographic machines, key management systems, and encryption gateways) are core components for ensuring the security of information systems, and their software updates and upgrades are crucial for fixing security vulnerabilities and improving performance. Traditional cryptographic device upgrade methods typically involve directly replacing executable files or application patch packages on the device's operating system. This approach has the following significant problems: Configuration and key risks: New software versions may depend on specific library files or environment configurations. Direct replacement may lead to upgrade failure or abnormal operation due to environment incompatibility. The upgrade process may accidentally overwrite or damage the device's critical configuration files and key files, causing the device to malfunction or generate serious security risks.

[0003] Rollback is difficult: If the upgrade fails, rolling back to the old version usually requires manual operation or a complex recovery process, which is time-consuming, risky, and seriously affects business continuity. The upgrade environment may differ between different devices, making it difficult to guarantee the consistency of the software operating environment after the upgrade. To address the aforementioned technical shortcomings, a solution is proposed. Summary of the Invention

[0004] The purpose of this invention is to enable rapid, secure, and reliable upgrades to cryptographic device software, and to quickly and automatically roll back to a stable state in the event of an upgrade failure, while ensuring the security and isolation of configuration files and key files.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a security upgrade method for cryptographic devices based on container technology, comprising the following steps: Step 1: For the new version of the target cryptographic device software, build a container image. The container image contains the new version's executable file, runtime dependencies, and non-sensitive default configuration files, but does not contain the actual configuration files and key files related to the specific device instance. Step 2: On the host machine of the cryptographic device, configure an independent persistent storage volume for the cryptographic device instance. The persistent storage volume is used to store the instance's personalized configuration files and key materials, ensuring that the file lifecycle is decoupled from the container image, and implementing encrypted storage and fine-grained access control of the key files. Step 3: When upgrading a container, stop the first container instance running the old version of the software and switch the container. Create and start a new container instance based on the container image, and mount the persistent storage volume to the predetermined path in the new container instance so that the new version of the software can access the personalized configuration file and key materials, thereby achieving transparent access of the new version of the software to the actual device configuration and keys. Step 4: After the new container starts, perform status verification, including automatically executing preset health checks and functional verification processes, covering software startup status, critical service availability, configuration and key access correctness, and core encryption function integrity verification. Step 5: If the status verification step passes, the upgrade is confirmed to be complete; if it fails, an automatic rollback operation is triggered. The automatic rollback operation includes terminating the new container instance and restarting the new container instance with the persistent storage volume mounted.

[0006] Furthermore, building a container image specifically includes: Perform static code analysis on the new version of the cryptographic device software to identify and eliminate potential risks of sensitive data leakage; We use Alpine Linux and a lightweight base image of the Distroless type to build a minimal upgrade image, reducing image size and potential attack surface.

[0007] Furthermore, on the host machine of the cryptographic device, a separate persistent storage volume is configured for the cryptographic device instance, specifically including the following: The key files stored in the persistent data volume are encrypted using both file system encryption and application layer encryption. Set up Linux file permission-based access control for the data volume and its files to ensure that only authorized processes and users can access it; Regularly audit the access logs of data volumes to promptly detect and respond to abnormal access behavior.

[0008] Furthermore, container upgrades also include the following: Before starting a new container instance, an image security verification step is also included: the upgrade image is pulled from a trusted private image repository, and the digital signature of the image is verified using an asymmetric cryptographic algorithm to ensure the integrity and trustworthiness of the image's source.

[0009] Furthermore, the digital signature of the mirror image is verified using an asymmetric cryptographic algorithm, specifically the SM2 algorithm.

[0010] Further, the health check and functional verification process is as follows: a. Check the container runtime status to confirm that the container process is running continuously; b. Service port connectivity test; c. Access verification: Confirm that the new version of the software can successfully read the mounted configuration file and key file; d. Core cryptographic function self-check: Call the predefined cryptographic operation interface to verify that the algorithm function is normal; The conditions for triggering the automatic rollback mechanism are: the health check process does not return to a successful status within the preset timeout period, the password service process is detected to have exited abnormally, or the core function self-check fails, at least one of the following situations.

[0011] Furthermore, it also includes an audit log generation step: recording the entire lifecycle event logs for upgrades and rollbacks. The logs include at least the event timestamp, operation type, source / target image identifier, container identifier, health check results, and final status, for security auditing and fault tracing.

[0012] A security upgrade system for cryptographic devices based on container technology includes the following modules: The image building module builds a container image for a new version of the target cryptographic device software. The container image contains the new version of the executable file, runtime dependencies, and non-sensitive default configuration files, but does not contain the actual configuration files and key files related to the specific device instance. The data volume management module configures independent persistent storage volumes for cryptographic device instances on the host machine of the cryptographic device. The persistent storage volume is used to store the instance's personalized configuration files and key materials, ensuring that the file lifecycle is decoupled from the container image, and implementing encrypted storage and fine-grained access control of key files. The container switching module stops the first container instance running the old version of the software during container upgrade and switches the container. It creates and starts a new container instance based on the container image and mounts the persistent storage volume to a predetermined path within the new container instance, so that the new version of the software can access personalized configuration files and key materials, thus enabling the new version of the software to have transparent access to the actual device configuration and keys. The health check module performs status verification after the new container starts, including automatically executing preset health checks and functional verification processes, covering software startup status, critical service availability, configuration and key access correctness, and core encryption function integrity verification. The verification execution module confirms the upgrade is complete if the status verification step passes; otherwise, it triggers an automatic rollback operation, which includes terminating the new container instance and restarting the new container instance with the persistent storage volume mounted.

[0013] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are: This container-based method and system for secure upgrades of cryptographic devices completely avoids the risk of configuration or key loss, corruption, or leakage due to image replacement during the upgrade process by separating configuration files and key files from container images and storing them in persistent data volumes. This greatly enhances the security of the upgrade process. Since the old and new versions of containers share the same persistent data, the rollback operation only requires switching the running container instance, without the need to restore or migrate data. The entire process can be automated and completed within seconds, significantly shortening fault recovery time and ensuring business continuity. Container technology ensures that the new version of the software runs in a completely consistent and isolated environment, eliminating environment dependency issues and improving the upgrade success rate and software stability. The upgrade process is standardized as pulling the image, starting the container, performing a health check, and switching containers if it fails. The operation is simple, easy to automate, and can be deployed in batches. The upgrade image only contains the necessary executable files and dependencies, is small in size, and is easy to transmit over the network and deploy quickly. Attached Figure Description

[0014] Figure 1 A schematic diagram of the overall steps of the method of the present invention is shown; Figure 2 A schematic diagram of the overall system flow structure of the present invention is shown. Detailed Implementation

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

[0016] Example 1: like Figure 1 As shown, a method for security upgrade of cryptographic devices based on container technology is characterized by the following steps: Step 1: For the new version of the target cryptographic device software, build a container image. The container image contains the new version's executable file, runtime dependencies, and non-sensitive default configuration files, but does not contain the actual configuration files and key files related to the specific device instance. Step 2: On the host machine of the cryptographic device, configure an independent persistent storage volume for the cryptographic device instance. The persistent storage volume is used to store the instance's personalized configuration files and key materials, ensuring that the file lifecycle is decoupled from the container image, and implementing encrypted storage and fine-grained access control of the key files. Step 3: When upgrading a container, stop the first container instance running the old version of the software and switch the container. Create and start a new container instance based on the container image, and mount the persistent storage volume to the predetermined path in the new container instance so that the new version of the software can access the personalized configuration file and key materials, thereby achieving transparent access of the new version of the software to the actual device configuration and keys. Step 4: After the new container starts, perform status verification, including automatically executing preset health checks and functional verification processes, covering software startup status, critical service availability, configuration and key access correctness, and core encryption function integrity verification. Step 5: If the status verification step passes, the upgrade is confirmed to be complete; if it fails, an automatic rollback operation is triggered. The automatic rollback operation includes terminating the new container instance and restarting the new container instance with the persistent storage volume mounted.

[0017] Building a container image specifically includes: Perform static code analysis on the new version of the cryptographic device software to identify and eliminate potential risks of sensitive data leakage; We use Alpine Linux and a lightweight base image of the Distroless type to build a minimal upgrade image, reducing image size and potential attack surface.

[0018] On the host machine of the cryptographic device, configure a separate persistent storage volume for the cryptographic device instance, specifically including the following: The key files stored in the persistent data volume are encrypted using both file system encryption and application layer encryption. Set up Linux file permission-based access control for the data volume and its files to ensure that only authorized processes and users can access it; Regularly audit the access logs of data volumes to promptly detect and respond to abnormal access behavior.

[0019] When performing a container upgrade, the following are also included: Before starting a new container instance, an image security verification step is also included: the upgrade image is pulled from a trusted private image repository, and the digital signature of the image is verified using an asymmetric cryptographic algorithm to ensure the integrity and trustworthiness of the image's source.

[0020] The digital signature of the mirror image is verified using an asymmetric cryptographic algorithm, specifically the SM2 algorithm.

[0021] The health check and functional verification process is as follows: a. Check the container runtime status to confirm that the container process is running continuously; b. Service port connectivity test; c. Access verification: Confirm that the new version of the software can successfully read the mounted configuration file and key file; d. Core cryptographic function self-check: Call the predefined cryptographic operation interface to verify that the algorithm function is normal; The conditions for triggering the automatic rollback mechanism are: the health check process does not return to a successful status within the preset timeout period, the password service process is detected to have exited abnormally, or the core function self-check fails, at least one of the following situations.

[0022] It also includes an audit log generation step: recording the entire lifecycle event logs for upgrades and rollbacks. The logs include at least the event timestamp, operation type, source / target image identifier, container identifier, health check results, and final status, for security auditing and fault tracing.

[0023] A security upgrade system for cryptographic devices based on container technology includes the following modules: The image building module builds a container image for a new version of the target cryptographic device software. The container image contains the new version of the executable file, runtime dependencies, and non-sensitive default configuration files, but does not contain the actual configuration files and key files related to the specific device instance. The data volume management module configures independent persistent storage volumes for cryptographic device instances on the host machine of the cryptographic device. The persistent storage volume is used to store the instance's personalized configuration files and key materials, ensuring that the file lifecycle is decoupled from the container image, and implementing encrypted storage and fine-grained access control of key files. The container switching module stops the first container instance running the old version of the software during container upgrade and switches the container. It creates and starts a new container instance based on the container image and mounts the persistent storage volume to a predetermined path within the new container instance, so that the new version of the software can access personalized configuration files and key materials, thus enabling the new version of the software to have transparent access to the actual device configuration and keys. The health check module performs status verification after the new container starts, including automatically executing preset health checks and functional verification processes, covering software startup status, critical service availability, configuration and key access correctness, and core encryption function integrity verification. The verification execution module confirms the upgrade is complete if the status verification step passes; otherwise, it triggers an automatic rollback operation, which includes terminating the new container instance and restarting the new container instance with the persistent storage volume mounted.

[0024] This solution isolates and protects sensitive data. The core security design lies in completely separating configuration files and key files from the container image and storing them in a persistent data volume on the host machine. This fundamentally eliminates the risk of sensitive data being accidentally included, leaked, or accessed without authorization during the upgrade process, such as image building, pushing, pulling, or container startup. The upgrade image itself does not contain any sensitive information, and even if intercepted, it is impossible to directly obtain key data. Image integrity and source trustworthiness: Upgrade images must be distributed through a secure image repository and digitally signed before deployment. The domestic cryptographic algorithm SM2 must be used to ensure that the images have not been tampered with and that their source is trustworthy, preventing the deployment of malicious or tampered images.

[0025] Runtime environment isolation: Container technology provides a lightweight sandbox, where new versions of software run in an isolated environment, limiting the impact of potential vulnerabilities or attacks.

[0026] Access control and encryption: The data volume on the host machine has strict permissions and can perform file-level encryption on the key file. The container runs as a non-root user and follows the principle of least privilege.

[0027] Operation auditing: Detailed logs of upgrade, rollback, and image operations are recorded, supporting security auditing and fault tracing; A rollback operation is essentially a container instance switch, relying on the stability of persistent data volumes. The process is automated and can be completed within seconds, greatly reducing time to service interruption (MTTR), and the result is deterministic.

[0028] The container image encapsulates all dependencies, ensuring that the new version behaves consistently on any target host, eliminating upgrade failures caused by environmental differences, and improving success rate and stability; The process design is clearly defined as stopping the old process, starting the new process, checking, and confirming / rolling back. The status is clear, avoiding confusion in intermediate states. Automated script / platform execution reduces human intervention errors, and automated health checks ensure objective and timely verification.

[0029] Configuration and keys are independent of the container lifecycle, so critical data is fully preserved even if the container is rebuilt, providing a foundation for recovery.

[0030] This invention achieves a significant improvement in security and reliability in cryptographic device scenarios through an innovative architecture that features image-free sensitive data, persistent data volumes, and rapid container switching.

[0031] The size of the interval and threshold is set to facilitate comparison. The size of the threshold depends on the amount of sample data and the number of bases set by those skilled in the art for each set of sample data; as long as it does not affect the ratio between the parameter and the quantized value.

[0032] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation. In the two embodiments provided in this application, it should be understood that the disclosed methods and systems can be implemented in other ways; for example, the device embodiments described above are merely illustrative, and the division of modules is merely a logical functional division. In actual implementation, there may be other division methods, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed; another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, and the indirect coupling or communication connection of devices or modules can be electrical, mechanical or other forms. The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A method for security upgrade of cryptographic devices based on container technology, characterized in that, Includes the following steps: Step 1: For the new version of the target cryptographic device software, build a container image. The container image contains the new version's executable file, runtime dependencies, and non-sensitive default configuration files, but does not contain the actual configuration files and key files related to the specific device instance. Step 2: On the host machine of the cryptographic device, configure an independent persistent storage volume for the cryptographic device instance. The persistent storage volume is used to store the instance's personalized configuration files and key materials, ensuring that the file lifecycle is decoupled from the container image, and implementing encrypted storage and fine-grained access control of the key files. Step 3: When upgrading a container, stop the first container instance running the old version of the software and switch the container. Create and start a new container instance based on the container image, and mount the persistent storage volume to the predetermined path in the new container instance so that the new version of the software can access the personalized configuration file and key materials, thereby achieving transparent access of the new version of the software to the actual device configuration and keys. Step 4: After the new container starts, perform status verification, including automatically executing preset health checks and functional verification processes, covering software startup status, critical service availability, configuration and key access correctness, and core encryption function integrity verification. Step 5: If the status verification step passes, the upgrade is confirmed to be complete; if it fails, an automatic rollback operation is triggered. The automatic rollback operation includes terminating the new container instance and restarting the new container instance with the persistent storage volume mounted.

2. The security upgrade method for cryptographic devices based on container technology according to claim 1, characterized in that, Building a container image specifically includes: Perform static code analysis on the new version of the cryptographic device software to identify and eliminate potential risks of sensitive data leakage; We use Alpine Linux and Distroless lightweight base images to build a minimal upgrade image, reducing image size and potential attack surface.

3. The security upgrade method for cryptographic devices based on container technology according to claim 1, characterized in that, On the host machine of the cryptographic device, configure a separate persistent storage volume for the cryptographic device instance, specifically including the following: The key files stored in the persistent data volume are encrypted using both file system encryption and application layer encryption. Set up Linux file permission-based access control for the data volume and its files to ensure that only authorized processes and users can access it; Regularly audit the access logs of data volumes to promptly detect and respond to abnormal access behavior.

4. The security upgrade method for cryptographic devices based on container technology according to claim 1, characterized in that, The following are also included when performing a container upgrade: Before starting a new container instance, an image security verification step is also included: the upgrade image is pulled from a trusted private image repository, and the digital signature of the image is verified using an asymmetric cryptographic algorithm to ensure the integrity and trustworthiness of the image's source.

5. The security upgrade method for cryptographic devices based on container technology according to claim 4, characterized in that, The digital signature of the mirror image is verified using an asymmetric cryptographic algorithm, specifically the SM2 algorithm.

6. The security upgrade method for cryptographic devices based on container technology according to claim 1, characterized in that, The health check and functional verification process is as follows: a. Check the container runtime status to confirm that the container process is running continuously; b. Service port connectivity test; c. Access verification: Confirm that the new version of the software can successfully read the mounted configuration file and key file; d. Core cryptographic function self-check: Call the predefined cryptographic operation interface to verify that the algorithm function is normal; The conditions for triggering the automatic rollback mechanism are: the health check process does not return to a successful status within the preset timeout period, the password service process is detected to have exited abnormally, or the core function self-check fails.

7. The security upgrade method for cryptographic devices based on container technology according to claim 1, characterized in that, It also includes an audit log generation step: recording the entire lifecycle event logs for upgrades and rollbacks. The logs include at least the event timestamp, operation type, source / target image identifier, container identifier, health check results, and final status, for security auditing and fault tracing.

8. A security upgrade system for cryptographic devices based on container technology, used in the security upgrade method for cryptographic devices based on container technology as described in any one of claims 1-8, characterized in that, Includes the following modules: The image building module builds a container image for a new version of the target cryptographic device software. The container image contains the new version of the executable file, runtime dependencies, and non-sensitive default configuration files, but does not contain the actual configuration files and key files related to the specific device instance. The data volume management module configures an independent persistent storage volume for the cryptographic device instance on the host machine of the cryptographic device. The persistent storage volume is used to store the instance's personalized configuration files and key materials, ensuring that the file lifecycle is decoupled from the container image, and implementing encrypted storage and fine-grained access control of key files. The container switching module stops the first container instance running the old version of the software during container upgrade and switches the container. It creates and starts a new container instance based on the container image and mounts the persistent storage volume to a predetermined path within the new container instance, so that the new version of the software can access personalized configuration files and key materials, thus enabling the new version of the software to transparently access the actual device configuration and keys. The health check module performs status verification after the new container starts, including automatically executing preset health checks and functional verification processes, covering software startup status, critical service availability, configuration and key access correctness, and core encryption function integrity verification. The verification execution module confirms the upgrade is complete if the status verification step passes; otherwise, it triggers an automatic rollback operation, which includes terminating the new container instance and restarting the new container instance with the persistent storage volume mounted.

Images