An operating system security authentication and key management method based on post-quantum signature

Abstract

The application discloses a kind of based on post-quantum signature operating system security authentication and key management method, belong to operating system security and quantum security technical field, including the following steps, establish the three-layer security architecture model based on hardware trust root-post-quantum signature chain-mixed key management;Operating system security authentication is carried out based on three-layer security architecture model;After security authentication passes, the whole life cycle management of post-quantum key is executed to generate key, and in the process, the way of hardware isolation and encryption protection is used to ensure that key is not leaked, traceable and controllable;Post-quantum signature and the post-quantum key obtained in the above step are deployed to the operating system and terminal equipment that have passed security authentication, the application uses the above method, realizes operating system full-scene anti-quantum security authentication, guarantees the safety of the whole life cycle of key, realizes the smooth compatibility with existing traditional cryptographic system, reduces migration cost, improves the overall security level of operating system.

Description

Technical Field

[0001] This invention relates to the fields of operating system security and quantum security technology, and in particular to an operating system security authentication and key management method based on post-quantum signatures. Background Technology

[0002] With the rapid development of quantum computing technology, traditional cryptographic algorithms (such as RSA and ECC) face a major security threat from being cracked by quantum computers. Shor's algorithm can solve the problems of large number factorization and discrete logarithm in polynomial time. Once large-scale quantum computers are put into use, the security authentication system and key management mechanism of existing operating systems will be completely ineffective, leading to serious security incidents such as device intrusion, data theft, and system tampering.

[0003] Current operating system security authentication primarily relies on traditional cryptographic signature technology, covering scenarios such as device startup, user login, module loading, and network communication. Key management is also mainly designed for traditional keys, resulting in the following core defects: First, it lacks quantum resistance; existing authentication systems cannot withstand quantum computing attacks, and long-term stored keys and certificates are at risk of being cracked prematurely. Second, the authentication chain is incomplete; some scenarios (such as lightweight terminal firmware authentication) do not achieve end-to-end trust, leaving vulnerabilities for malicious code injection. Third, key management has shortcomings; private key storage often uses software encryption, making it susceptible to theft, and key rotation and revocation mechanisms are inflexible and cannot adapt to the needs of quantum security scenarios. Fourth, it suffers from poor compatibility; existing post-quantum security solutions are mostly deployed using a single algorithm, which is incompatible with existing traditional cryptographic systems, leading to high migration costs, deployment difficulties, and a lack of smooth transition. Summary of the Invention

[0004] The purpose of this invention is to provide a method for operating system security authentication and key management based on post-quantum signatures. By deeply integrating post-quantum signature technology with hardware root of trust and hybrid key management, it achieves quantum-resistant security authentication of the operating system in all scenarios, ensures the security of the key throughout its entire life cycle, and achieves smooth compatibility with existing traditional cryptographic systems, reducing migration costs and improving the overall security level of the operating system.

[0005] To achieve the above objectives, this invention provides a method for operating system security authentication and key management based on post-quantum signatures, comprising the following steps: S1. Establish a three-layer security architecture model based on hardware root of trust, post-quantum signature chain, and hybrid key management; S2. Operating system security authentication based on a three-layer security architecture model; S3. After security authentication is passed, the entire lifecycle management of the quantum key is performed to generate a key, and hardware isolation and encryption protection are used in the process to ensure that the key is not leaked, is traceable and controllable. S4. Deploy the post-quantum signature and the post-quantum key obtained in S3 to the operating system of the terminal device that has been securely authenticated in S2, and complete the system security authentication and key management process.

[0006] Preferably, the hardware root of trust in S1 adopts one of HSM, TEE and security chip. The post-quantum signature chain is selected from CRYSTALS-Dilithium algorithm, Falcon algorithm and SPHINCS+ algorithm according to the use case and operating system. The post-quantum signature chain forms a trusted signature chain of root public key-secondary public key-tertiary public key. The hybrid key management adopts a hybrid key management system that supports the parallel management of post-quantum keys and traditional keys.

[0007] Preferably, the process of S2 is as follows: S21. Perform terminal device startup authentication, and start the terminal device after authentication is completed; S22. After the terminal device starts up, it performs user authentication. S23. After user authentication is completed, kernel module and firmware authentication are performed. After S24 and S23 are completed, network communication authentication is performed.

[0008] Preferably, the process of S21 is as follows: S211. After the hardware trust root in the three-layer security architecture model starts, it calls the preset post-quantum root public key to verify the post-quantum signature of the operating system bootloader. If the verification is successful, proceed to S212; otherwise, terminate the device boot process and output "Bootloader signature verification failed". S212. Start the Bootloader and call the post-quantum public key stored in the Bootloader to verify the post-quantum signature of the operating system kernel image. If the verification is successful, proceed to S213; otherwise, terminate the device boot process and output "Kernel image signature verification failed". S213. Start the kernel and call the kernel's pre-set post-quantum public key to verify the post-quantum signatures of the system driver and kernel module. If the verification is successful, the terminal device will start successfully; otherwise, output "verification failed" and terminate the device startup.

[0009] Preferably, the process of S22 is as follows: S221. After the terminal device starts up, it performs a user login operation and signs the challenge information sent by the operating system using its own post-quantum private key to generate a post-quantum signature result. S222. After receiving the signature result, the operating system calls the corresponding post-quantum public key certificate to verify the signature. If the verification is successful, the user is allowed to log in or the process is executed. If the verification fails, the operation is rejected and an exception log is recorded. S223. After successful verification, the post-quantum private key is stored in a hardware root of trust for isolation and protection to prevent private key theft and replay attacks, thus completing user authentication.

[0010] Preferably, the process in S23 is as follows: After S231 and S22 are completed, all kernel modules and firmware to be loaded are pre-signed using the post-quantum signature algorithm to obtain signature information. The signature information includes the version number, hash value and permission attributes of the kernel module and firmware. S232. The post-quantum root CA calls its own stored post-quantum private key to sign the post-quantum certificate of the module / firmware issuer, thus completing the legality endorsement of the issuer's certificate. Afterwards, the module / firmware issuer calls its own private key corresponding to the post-quantum certificate signed by the root CA to sign the post-quantum signature information of the specific kernel module / firmware, thus obtaining the post-quantum root-module / firmware issuer-specific module / firmware module / firmware certificate chain. S233. The operating system kernel first verifies the validity of the certificate chain. After verification, it verifies the post-quantum signature and hash value of the module / firmware to complete the loading of the module / firmware.

[0011] Preferably, the process of S24 is as follows: S241. During network communication authentication, both communicating parties deploy a hybrid certificate that combines traditional signatures and post-quantum signatures. When the server and client perform a communication handshake, both traditional signatures and post-quantum signatures are generated simultaneously. S242. During the handshake phase, the server and client verify each other's identity using a post-quantum signature algorithm, and simultaneously negotiate the session key using the post-quantum key exchange algorithm Kyber. S243. A secure communication link is established when both the traditional signature and the post-quantum signature of both parties are verified, the session key negotiation is completed, and the encryption verification is successful. Otherwise, the communication is terminated and a message indicating that the communication verification failed is output.

[0012] Preferably, the process of S3 is as follows: S31. A TRNG true random number generator is used in conjunction with an HSM hardware security module to generate a quantum public-private key pair, while simultaneously generating a traditional public-private key pair. S32. Store both the post-quantum private key and the traditional core private key in the hardware root of trust to prevent the private key from being written in plaintext. At the same time, incorporate the post-quantum public key and the hybrid certificate into the PKI certificate system to complete the registration, review and release of the certificate. S33. The public key certificate is transmitted in encrypted form using the TLS 1.3 protocol and the Kyber algorithm. At the same time, the public key certificate is pre-installed in the hardware root of trust for the terminal device to ensure that the distribution process is not stolen or tampered with. S34. Rotate the root key and secondary key according to the prescribed time using a hierarchical rotation strategy, and update the session key after each communication. S35. Include post-quantum certificates and hybrid certificates in the CRL certificate revocation list, and immediately trigger revocation operations when private key is leaked, device is deregistered, or certificate expires; S36. A master key fragmentation threshold management mechanism is adopted to split the master key into multiple fragments and distribute them to different authorized entities. When the master key needs to be recovered, multi-factor authentication is performed and a specified number of key fragments are collected.

[0013] Preferably, the process of S4 is as follows: S41. Upgrade the operating system kernel and bootloader to ensure that the operating system supports post-quantum signature verification operations, and adapt the hardware devices to ensure that they support the generation, storage and computation of post-quantum keys. S42. The system's hybrid mode is initiated by dual signatures of traditional signature and post-quantum signature, and dual encryption modes of traditional key and post-quantum key. When the dual verification is successful, the authentication and encryption operations take effect. S43. Circularly update the operating system and terminal devices, gradually phase out traditional signature algorithms and traditional keys, and gradually update the operating system to a post-quantum signature algorithm and post-quantum key method; After S44, the operating system, and terminal devices are updated, a security audit system is deployed. The security audit system records all post-quantum signature and verification operations, as well as key generation, storage, distribution, rotation, and revocation operations, and authentication failure and key abnormality events in real time, and retains audit logs for traceability.

[0014] Therefore, the operating system security authentication and key management method based on post-quantum signatures using the above structure has the following advantages: 1. Strong resistance to quantum attacks: It adopts the NIST-standardized post-quantum signature algorithm to build a full-scenario post-quantum secure authentication system, which can effectively resist quantum computing attacks such as Shor's algorithm, ensure the long-term security of operating system authentication and keys, and solve the quantum security risks of traditional cryptographic systems; 2. Complete authentication chain: Covering four core authentication scenarios: device startup, user / process identity, kernel module / firmware, and network communication, it builds a trusted authentication chain from hardware to application, eliminating security vulnerabilities such as malicious code injection, identity forgery, and module tampering; 3. Secure and reliable key management: The core private key is stored in hardware isolation. Combined with mechanisms such as hierarchical key rotation, threshold key recovery, and real-time certificate revocation, the key is securely managed throughout its entire lifecycle to prevent leakage, loss, or misuse. 4. Good compatibility and low migration cost: It adopts a hybrid dual-signature and dual-encryption mode that combines traditional and post-quantum technologies, eliminating the need to completely replace the existing system. This allows for a smooth transition, reducing deployment costs and migration risks for enterprises and institutions, and is compatible with different types of operating systems and terminal devices. 5. High scalability: Supports flexible switching between multiple post-quantum signature algorithms such as CRYSTALS-Dilithium, Falcon and SPHINCS+, while also being compatible with domestic post-quantum algorithms. The algorithm selection and deployment scheme can be flexibly adjusted according to NIST algorithm updates and actual application scenario requirements. 6. Reasonable performance optimization: For high-concurrency signature verification scenarios, batch verification algorithms are used to optimize performance, combined with hardware acceleration technology to reduce the performance overhead of post-quantum signature verification, ensuring that the normal operation of the operating system is not affected.

[0015] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0016] Figure 1 This is an overall flowchart of an operating system security authentication and key management method based on post-quantum signatures according to the present invention; Figure 2 This is a flowchart illustrating the operating system security authentication process of the present invention, which is based on a post-quantum signature-based operating system security authentication and key management method. Figure 3 This figure shows the research results of an operating system security authentication and key management method based on post-quantum signatures according to the present invention. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0018] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0019] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0020] The following detailed description of some embodiments of the present invention is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0021] Example 1 like Figures 1-3 As shown, it includes the following steps: S1. Establish a three-layer security architecture model based on hardware root of trust, post-quantum signature chain, and hybrid key management; The hardware root of trust is pre-configured with a post-quantum signature root public key. The post-quantum signature chain is constructed using the NIST-standardized post-quantum signature algorithm. Hybrid key management enables collaborative management of traditional keys and post-quantum keys.

[0022] The hardware root of trust adopts one of HSM, TEE and security chip. The post-quantum signature chain is selected from CRYSTALS-Dilithium algorithm, Falcon algorithm and SPHINCS+ algorithm according to the use case and operating system. The post-quantum signature chain forms a trusted signature chain of root public key-secondary public key-third public key. Hybrid key management adopts a hybrid key management system that supports the parallel management of post-quantum keys and traditional keys.

[0023] S2. Based on a three-layer security architecture model, the operating system performs security authentication, and uses post-quantum signature verification to realize identity and integrity verification. S21. Perform terminal device startup authentication, and start the terminal device after authentication is completed; S211. After the hardware trust root in the three-layer security architecture model starts, it calls the preset post-quantum root public key to verify the post-quantum signature of the operating system bootloader. If the verification is successful, proceed to S212; otherwise, terminate the device boot process and output "Bootloader signature verification failed" to prevent malicious code from being injected into the system. S212. Start the Bootloader and call the post-quantum public key stored in the Bootloader to verify the post-quantum signature of the operating system kernel image. If the verification is successful, proceed to S213. Otherwise, terminate the device boot process and output "kernel image verification failed" to prevent malicious code from being injected into the system. S213. Start the kernel and call the kernel's pre-set post-quantum public key to verify the post-quantum signatures of the system driver and kernel module. If the verification is successful, the terminal device will start successfully; otherwise, output "verification failed" and terminate the device startup to prevent malicious code from being injected into the system.

[0024] S22. After the terminal device starts up, it performs user authentication. The operating system pre-installs post-quantum public key certificates for users and processes. During the transition period, a hybrid certificate combining traditional public key certificates and post-quantum public key certificates is used. The hybrid certificate is incorporated into the post-quantum root CA system to ensure the anti-quantum forgery capability of communication identity authentication.

[0025] S221. After the terminal device starts up, it performs a user login operation and signs the challenge information sent by the operating system using its own post-quantum private key to generate a post-quantum signature result. S222. After receiving the signature result, the operating system calls the corresponding post-quantum public key certificate to verify the signature. If the verification is successful, the user is allowed to log in or the process is executed. If the verification fails, the operation is rejected and an exception log is recorded. S223. After successful verification, the post-quantum private key is stored in a hardware root of trust for isolation and protection to prevent private key theft and replay attacks, thus completing user authentication.

[0026] S23. After user authentication is completed, kernel module and firmware authentication are performed. For high-concurrency signature verification scenarios, a batch verification algorithm is adopted to optimize performance.

[0027] After S231 and S22 are completed, all kernel modules and firmware to be loaded are pre-signed using the post-quantum signature algorithm to obtain signature information. The signature information includes the version number, hash value and permission attributes of the kernel module and firmware. S232. The post-quantum root CA calls its own stored post-quantum private key to sign the post-quantum certificate of the module / firmware issuer, thus completing the legality endorsement of the issuer's certificate. Afterwards, the module / firmware issuer calls its own private key corresponding to the post-quantum certificate signed by the root CA to sign the post-quantum signature information of the specific kernel module / firmware, thus obtaining the post-quantum root-module / firmware issuer-specific module / firmware module / firmware certificate chain. S233. The operating system kernel first verifies the validity of the certificate chain. After verification, it verifies the post-quantum signature and hash value of the module / firmware to complete the loading of the module / firmware.

[0028] After S24 and S23 are completed, network communication authentication is performed.

[0029] S241. During network communication authentication, both communicating parties deploy a hybrid certificate that combines traditional signatures and post-quantum signatures. When the server and client perform a communication handshake, both traditional signatures and post-quantum signatures are generated simultaneously. S242. During the handshake phase, the server and client verify each other's identity using a post-quantum signature algorithm, and simultaneously negotiate the session key using the post-quantum key exchange algorithm Kyber. S243. A secure communication link is established when both the traditional signature and the post-quantum signature of both parties are verified, the session key negotiation is completed, and the encryption verification is successful. Otherwise, the communication is terminated and a message indicating that the communication verification failed is output.

[0030] S3. After security authentication is passed, the entire lifecycle management of the quantum key is performed to generate a key, and hardware isolation and encryption protection are used in the process to ensure that the key is not leaked, is traceable and controllable. S31. A TRNG true random number generator is used in conjunction with an HSM hardware security module to generate a quantum public-private key pair, while simultaneously generating a traditional public-private key pair. S32. Store both the post-quantum private key and the traditional core private key in the hardware root of trust to prevent the private key from being written in plaintext. At the same time, incorporate the post-quantum public key and the hybrid certificate into the PKI certificate system to complete the registration, review and release of the certificate. S33. The public key certificate is transmitted in encrypted form using the TLS 1.3 protocol and the Kyber algorithm. At the same time, the public key certificate is pre-installed in the hardware root of trust for the terminal device to ensure that the distribution process is not stolen or tampered with. S34. Rotate the root key and secondary key according to the prescribed time using a hierarchical rotation strategy, and update the session key after each communication. S35. Include post-quantum certificates and hybrid certificates in the CRL certificate revocation list, and immediately trigger revocation operations when private key is leaked, device is deregistered, or certificate expires; S36. A master key fragmentation threshold management mechanism is adopted to split the master key into multiple fragments and distribute them to different authorized entities. When the master key needs to be recovered, multi-factor authentication is performed and a specified number of key fragments are collected.

[0031] S4. Deploy the post-quantum signature and the post-quantum key obtained in S3 to the operating system of the terminal device that has been securely authenticated in S2, and complete the system security authentication and key management process.

[0032] S41. Upgrade the operating system kernel and bootloader to ensure that the operating system supports post-quantum signature verification operations, and adapt the hardware devices to ensure that they support the generation, storage and computation of post-quantum keys. S42. The system's hybrid mode is initiated by dual signatures of traditional signature and post-quantum signature, and dual encryption modes of traditional key and post-quantum key. When the dual verification is successful, the authentication and encryption operations take effect. S43. Circularly update the operating system and terminal devices, gradually phase out traditional signature algorithms and traditional keys, and gradually update the operating system to a post-quantum signature algorithm and post-quantum key method; After S44, the operating system, and terminal devices are updated, a security audit system is deployed. The security audit system records all post-quantum signature and verification operations, as well as key generation, storage, distribution, rotation, and revocation operations, and authentication failure and key abnormality events in real time, and retains audit logs for traceability.

[0033] To verify the practicality, ease of use, and security of the method proposed in this application, 10 pilot units of different types were selected, including 5 enterprise server scenarios, 3 IoT embedded scenarios, and 2 government terminal scenarios. After deploying the method of this invention, a satisfaction survey was conducted for 3 months. The survey subjects included system administrators, technical maintenance personnel, and security auditors. A total of 120 questionnaires were distributed, and 117 valid questionnaires were returned, with an effective response rate of 97.5%. The specific survey results mainly covered six dimensions: security, compatibility, ease of use, performance, scalability, and overall satisfaction, as shown in Table 1. Security: resistance to quantum attacks, key storage security, and authentication link reliability; Compatibility: The degree of compatibility with existing operating systems and hardware devices (HSM / security chip), and the smoothness of the transition; Ease of use: Convenience of authentication operations, complexity of key management (generation / rotation / revocation) operations, and difficulty of operation and maintenance; Performance characteristics: Signature / verification speed, system startup latency, and adaptability to high-concurrency scenarios; Scalability: ease of algorithm switching and adaptability to different scenarios (server / embedded); Overall satisfaction: A comprehensive evaluation of the practical effectiveness and safety value of the method of this invention.

[0034] Table 1 Survey Results

[0035] Example 2 Using a general-purpose server operating system as the application scenario, CRYSTALS-Dilithium is adopted as the mainstream post-quantum signature algorithm, Falcon algorithm is used as a lightweight backup algorithm, and SPHINCS+ algorithm is used as the root CA certificate signature algorithm to achieve quantum-resistant authentication and key management in all scenarios. The specific implementation steps are as follows: Step 1: Construct a three-tier security architecture model; Deploy a hardware root of trust: Use the HSM hardware security module as the hardware root of trust. The SPHINCS+ root public key and Dilithium root public key are pre-installed in the HSM. The HSM is equipped with anti-tampering and anti-side channel attack functions to prevent the root public key from being tampered with or stolen. Constructing a post-quantum signature chain: A system-level signature chain is constructed based on the Dilithium algorithm. The root public key is stored in the HSM, the second-level public key is used for signing the Bootloader, kernel, and driver modules, and the third-level public key is used for signing users, processes, and applications, forming a trusted signature chain of "root public key → second-level public key → third-level public key". Establish a hybrid key management system: Deploy a hybrid key management system to support the parallel management of Dilithium post-quantum keys and RSA traditional keys, realize integrated control of key generation, storage, distribution, rotation and revocation, and link KMS and HSM to ensure the secure storage of core keys.

[0036] Step 2: Execute full-scenario security authentication: 2.1 Device Startup Authentication: After the server is powered on, the HSM hardware root of trust is started first. It calls the preset Dilithium root public key to verify the Dilithium signature of the operating system bootloader. The verification content includes the hash value and version number of the bootloader to ensure that the bootloader has not been tampered with. After successful signature verification, the Bootloader starts and uses its stored Dilithium Level 2 public key to verify the Dilithium signature of the Linux kernel image. If the signature verification is successful, the kernel starts; if the signature verification fails, the boot process is terminated immediately, and an alarm message is sent to the administrator. After the kernel starts, it calls the pre-configured Dilithium Level 3 public key to perform batch verification of the Dilithium signatures of system drivers and kernel modules. The batch verification uses a batch verification algorithm to reduce verification latency. If the verification passes, the module is loaded; if the verification fails, loading is refused, and an exception log is recorded.

[0037] 2.2 User / Process Authentication: The operating system comes pre-installed with hybrid certificates for administrators, ordinary users, and core processes. The hybrid certificate is a combination of a Dilithium post-quantum certificate and a traditional RSA certificate. The certificate is stored on a PKI certificate server and is issued by SPHINCS and a root CA. When an administrator logs in, the operating system sends a random challenge message to the administrator terminal through the Trusted Execution Environment (TEE). The administrator terminal signs the challenge message using its own Dilithium private key to generate a Dilithium signature result. After receiving the signature result, the operating system calls the administrator's hybrid certificate in the PKI server and verifies both the RSA signature and the Dilithium signature. If both signatures pass the verification, login is allowed; otherwise, login is denied. If the verification fails three times in a row, the account is locked. When the core process is executed, the process signs its identity information using its own stored Dilithium private key. The private key is stored in the HSM. The operating system calls the hybrid certificate corresponding to the process to perform double signature verification. If the verification is successful, the process is allowed to execute; otherwise, the process is terminated and anomalies are investigated.

[0038] 2.3 Kernel Module and Firmware Authentication: All kernel modules and server firmware to be loaded are pre-signed using the Dilithium algorithm. The signature information includes the module / firmware version number, hash value, and permission attributes. The signature private key is stored in the HSM and can be accessed by the administrator with authorization. Establish a module / firmware certificate chain: SPHINCS + root CA sign the module issuer's Dilithium certificate, and the issuer certificate signs the Dilithium signature information of the specific module / firmware, forming a trusted certificate chain of "root CA → issuer → module / firmware". When the operating system loads a module / firmware, it first verifies the validity of the certificate chain, and then verifies the Dilithium signature and hash value of the module / firmware to ensure that the module / firmware is from a legitimate source and has not been tampered with. If the verification passes, the module / firmware is loaded; otherwise, the loading is refused and an alarm is issued.

[0039] 2.4 Network Communication Authentication: When the server communicates with the client, it uses the TLS 1.3 protocol combined with post-quantum technology, and both parties deploy Dilithium+RSA hybrid certificates; During the communication handshake phase, the server and client simultaneously generate RSA signatures and Dilithium signatures and send them to each other. At the same time, they use the Kyber post-quantum key exchange algorithm to negotiate the session key. After receiving the signature, both parties verify each other's RSA signature and Dilithium signature. Once both signatures are verified, the session key negotiation is completed, and the encryption verification is successful, a secure communication link is established, and the transmitted data is encrypted using the session key. During communication, the session key is updated periodically to ensure communication security. If a signature verification failure or key abnormality is detected, the communication link is terminated immediately and a communication abnormality log is recorded.

[0040] Step 3: Key lifecycle management: 3.1 Key Generation: A TRNG true random number generator combined with an HSM is used to generate Dilithium post-quantum public-private key pairs and RSA traditional public-private key pairs. The key length of the post-quantum public-private key pairs is Dilithium 2, which balances security and performance. The key length of the traditional public-private key pairs is 2048 bits. The entire generation process is encrypted. After generation, the private key is directly stored in the HSM, and the public key is sent to the PKI certificate server for certificate registration. 3.2 Key Storage: Dilithium private keys and RSA core private keys are stored in HSM, and plaintext transmission is prohibited. HSM is configured with access control, and only authorized administrators can use the private keys to perform signing operations. User private keys are stored in USB key shields or TEE, process private keys are stored in HSM, and public keys and hybrid certificates are stored in PKI certificate servers, which support real-time querying. 3.3 Key Distribution: The PKI certificate server uses the TLS 1.3 protocol combined with the Kyber algorithm to encrypt and distribute the hybrid certificates of users / processes to the corresponding terminal devices and processes; for fixed servers, the core public key is pre-placed in the HSM to avoid security risks during the distribution process. 3.4 Key Rotation: A tiered rotation strategy is adopted. The SPHINCS+ root key is rotated every 2 years, the Dilithium level 2 key is rotated every 4 months, the Dilithium level 3 key is rotated every 2 months, and the session key is updated for each communication session. Key rotation is automatically triggered by KMS. A dual-key parallel mechanism is used during the rotation process to ensure the normal operation of the system. The old key is revoked immediately after the rotation is completed. 3.5 Key Revocation: When a user leaves the company, the device is deregistered, the private key is leaked, or the certificate expires, the administrator triggers the key revocation operation through KMS, adds the corresponding hybrid certificate to the CRL certificate revocation list, and pushes the certificate revocation information to the entire system through the OCSP protocol to ensure that the revoked certificate can no longer be used for authentication. 3.6 Key Recovery: The master key in the HSM is split into 5 fragments and distributed to 3 authorized administrators. When the master key is lost or needs to be recovered, all 3 administrators must provide key fragments simultaneously and pass multi-factor authentication in order to recover the master key, thus preventing single point of leakage or loss of the master key.

[0041] Step 4: Deployment of a smooth transition mechanism: 4.1 Environment Adaptation: Upgrade the Linux kernel to a version that supports Dilithium signature verification, upgrade the bootloader to support post-quantum signature verification, and update the HSM firmware to support key operations for the three post-quantum algorithms: Dilithium, Falcon, and SPHINCS+. 4.2 Hybrid Mode Enabled: Enable dual-signature and dual-encryption mode. All authentication operations require dual-signature verification using both RSA traditional signature and Dilithium post-quantum signature. All key encryption requires dual encryption using both traditional key and post-quantum key to ensure compatibility with existing un-upgraded terminal devices. 4.3 Full Switchover: Newly deployed servers will use the Dilithium post-quantum signature algorithm and post-quantum key by default, and will no longer deploy the RSA traditional key; for existing old servers, the RSA traditional signature and traditional key will be gradually disabled through system upgrades and firmware updates to complete the full switchover to the post-quantum security system. 4.4 Audit and Monitoring: Deploy a security audit system to record all Dilithium signing / verification operations, key generation / storage / distribution / rotation / revocation operations, as well as authentication failures, key anomalies, and other events in real time. Support real-time detection and analysis of quantum attack behavior. Audit logs are retained for more than one year for security tracing and incident investigation.

[0042] After completion, deploy security enhancement measures for the system: Side-channel protection: Employs HSM hardware acceleration for Dilithium signature verification and key computation, enables HSM's side-channel protection function to prevent side-channel attacks such as timing attacks and power consumption attacks; encrypts and protects private key computation in TEE to avoid leakage of sensitive information during the computation process. Private key status management: Dilithium private keys are marked with status to prevent the reuse of private keys. After each use of a private key for signing, the private key status record is updated. If the reuse of a private key is detected, the private key is locked and an alarm is triggered immediately. Emergency Response: A pre-configured emergency key revocation mechanism allows administrators to quickly trigger the emergency revocation of all relevant keys via KMS in the event of a quantum attack or private key leak; a quantum attack emergency response process is established, clearly defining emergency handling steps and division of responsibilities to minimize security risks.

[0043] Example 3 Taking IoT embedded operating systems (such as RT-Thread and FreeRTOS) as the application scenario, and considering the resource-constrained nature of embedded devices, the above method is adapted and optimized. The specific implementation steps are as follows: 1. Architecture Adaptation: It adopts a three-layer architecture of "security chip + post-quantum signature chain + lightweight hybrid key management". The security chip is a low-cost, low-power embedded security chip with a pre-installed Falcon post-quantum root public key. 2. Algorithm selection: The mainstream scenario adopts the Falcon post-quantum signature algorithm, the root CA certificate signature adopts the SPHINCS+ algorithm, and the transition period adopts the Falcon+ECC hybrid signature mode to reduce performance overhead and storage usage; 3. Authentication process optimization: Device startup authentication is simplified to a two-level signature verification process of "security chip → Bootloader → kernel", reducing signature verification steps and performance overhead; user / process identity authentication adopts a lightweight signature verification method, simplifying the length of challenge information and shortening signature / verification time; 4. Key Management Adaptation: Key generation uses a lightweight TRNG true random number generator, and the keys are stored in an embedded security chip to avoid consuming too much device storage resources; key rotation adopts a manual trigger mode, with the root key rotating every 3 years and the secondary key rotating every 6 months. 5. Smooth transition: Embedded devices gradually enable the Falcon+ECC hybrid signature mode through firmware updates. After all devices have completed the firmware update, they are switched to the pure Falcon quantum signature mode, reducing migration costs.

[0044] The method in this embodiment can adapt to the resource-constrained characteristics of embedded devices while ensuring the quantum security of the embedded operating system, ensuring the normal operation of the device, and achieving a compatible transition with existing Internet of Things systems.

[0045] Therefore, this invention adopts a post-quantum signature-based operating system security authentication and key management method. By deeply integrating post-quantum signature technology with hardware root of trust and hybrid key management, it achieves quantum-resistant security authentication of the operating system in all scenarios, ensures the security of the key throughout its entire life cycle, and achieves smooth compatibility with existing traditional cryptographic systems, reducing migration costs and improving the overall security level of the operating system.

[0046] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the technical solutions of the present invention, and these modifications or equivalent substitutions cannot cause the modified technical solutions to deviate from the spirit and scope of the technical solutions of the present invention.

Claims

1. A method for operating system security authentication and key management based on post-quantum signatures, characterized in that, Includes the following steps: S1. Establish a three-layer security architecture model based on hardware root of trust, post-quantum signature chain, and hybrid key management; S2. Operating system security authentication based on a three-layer security architecture model; S3. After security authentication is passed, the entire lifecycle management of the quantum key is performed to generate a key, and hardware isolation and encryption protection are used in the process to ensure that the key is not leaked, is traceable and controllable. S4. Deploy the post-quantum signature and the post-quantum key obtained in S3 to the operating system of the terminal device that has been securely authenticated in S2, and complete the system security authentication and key management process.

2. The operating system security authentication and key management method based on post-quantum signatures according to claim 1, characterized in that: The hardware root of trust in S1 uses one of HSM, TEE, and security chip. The post-quantum signature chain is selected from CRYSTALS-Dilithium algorithm, Falcon algorithm, and SPHINCS+ algorithm according to the use case and operating system. The post-quantum signature chain forms a trusted signature chain of root public key-secondary public key-tertiary public key. Hybrid key management adopts a hybrid key management system that supports parallel management of post-quantum keys and traditional keys.

3. The operating system security authentication and key management method based on post-quantum signatures according to claim 2, characterized in that, The process of S2 is as follows: S21. Perform terminal device startup authentication, and start the terminal device after authentication is completed; S22. After the terminal device starts up, it performs user authentication. S23. After user authentication is completed, kernel module and firmware authentication are performed. After S24 and S23 are completed, network communication authentication is performed.

4. The operating system security authentication and key management method based on post-quantum signatures according to claim 3, characterized in that, The process of S21 is as follows: S211. After the hardware trust root in the three-layer security architecture model starts, it calls the preset post-quantum root public key to verify the post-quantum signature of the operating system bootloader. If the verification is successful, proceed to S212; otherwise, terminate the device boot process and output "Bootloader signature verification failed". S212. Start the Bootloader and call the post-quantum public key stored in the Bootloader to verify the post-quantum signature of the operating system kernel image. If the verification is successful, proceed to S213; otherwise, terminate the device boot process and output "Kernel image signature verification failed". S213. Start the kernel and call the kernel's pre-set post-quantum public key to verify the post-quantum signatures of the system driver and kernel module. If the verification is successful, the terminal device will start successfully; otherwise, output "verification failed" and terminate the device startup.

5. The operating system security authentication and key management method based on post-quantum signatures according to claim 4, characterized in that, The process of S22 is as follows: S221. After the terminal device starts up, it performs a user login operation and signs the challenge information sent by the operating system using its own post-quantum private key to generate a post-quantum signature result. S222. After receiving the signature result, the operating system calls the corresponding post-quantum public key certificate to verify the signature. If the verification is successful, the user is allowed to log in or the process is executed. If the verification fails, the operation is rejected and an exception log is recorded. S223. After successful verification, the post-quantum private key is stored in a hardware root of trust for isolation and protection to prevent private key theft and replay attacks, thus completing user authentication.

6. The operating system security authentication and key management method based on post-quantum signatures according to claim 5, characterized in that, The process of S23 is as follows: After S231 and S22 are completed, all kernel modules and firmware to be loaded are pre-signed using the post-quantum signature algorithm to obtain signature information. The signature information includes the version number, hash value and permission attributes of the kernel module and firmware. S232. The post-quantum root CA calls its own stored post-quantum private key to sign the post-quantum certificate of the module / firmware issuer, thus completing the legality endorsement of the issuer's certificate. Afterwards, the module / firmware issuer calls its own private key corresponding to the post-quantum certificate signed by the root CA to sign the post-quantum signature information of the specific kernel module / firmware, thus obtaining the post-quantum root-module / firmware issuer-specific module / firmware module / firmware certificate chain. S233. The operating system kernel first verifies the validity of the certificate chain. After verification, it verifies the post-quantum signature and hash value of the module / firmware to complete the loading of the module / firmware.

7. The operating system security authentication and key management method based on post-quantum signatures according to claim 6, characterized in that, The process of S24 is as follows: S241. During network communication authentication, both communicating parties deploy a hybrid certificate that combines traditional signatures and post-quantum signatures. When the server and client perform a communication handshake, both traditional signatures and post-quantum signatures are generated simultaneously. S242. During the handshake phase, the server and client verify each other's identity using a post-quantum signature algorithm, and simultaneously negotiate the session key using the post-quantum key exchange algorithm Kyber. S243. A secure communication link is established when both the traditional signature and the post-quantum signature of both parties are verified, the session key negotiation is completed, and the encryption verification is successful. Otherwise, the communication is terminated and a message indicating that the communication verification failed is output.

8. The operating system security authentication and key management method based on post-quantum signatures according to claim 7, characterized in that, The process of S3 is as follows: S31. A TRNG true random number generator is used in conjunction with an HSM hardware security module to generate a quantum public-private key pair, while simultaneously generating a traditional public-private key pair. S32. Store both the post-quantum private key and the traditional core private key in the hardware root of trust to prevent the private key from being written in plaintext. At the same time, incorporate the post-quantum public key and the hybrid certificate into the PKI certificate system to complete the registration, review and release of the certificate. S33. The public key certificate is transmitted in encrypted form using the TLS 1.3 protocol and the Kyber algorithm. At the same time, the public key certificate is pre-installed in the hardware root of trust for the terminal device to ensure that the distribution process is not stolen or tampered with. S34. Rotate the root key and secondary key according to the prescribed time using a hierarchical rotation strategy, and update the session key after each communication. S35. Include post-quantum certificates and hybrid certificates in the CRL certificate revocation list, and immediately trigger revocation operations when private key is leaked, device is deregistered, or certificate expires; S36. A master key fragmentation threshold management mechanism is adopted to split the master key into multiple fragments and distribute them to different authorized entities. When the master key needs to be recovered, multi-factor authentication is performed and a specified number of key fragments are collected.

9. A method for operating system security authentication and key management based on post-quantum signatures according to claim 8, characterized in that, The process of S4 is as follows: S41. Upgrade the operating system kernel and bootloader to ensure that the operating system supports post-quantum signature verification operations, and adapt the hardware devices to ensure that they support the generation, storage and computation of post-quantum keys. S42. The system's hybrid mode is initiated by dual signatures of traditional signature and post-quantum signature, and dual encryption modes of traditional key and post-quantum key. When the dual verification is successful, the authentication and encryption operations take effect. S43. Circularly update the operating system and terminal devices, gradually phase out traditional signature algorithms and traditional keys, and gradually update the operating system to a post-quantum signature algorithm and post-quantum key method; After S44, the operating system, and terminal devices are updated, a security audit system is deployed. The security audit system records all post-quantum signature and verification operations, as well as key generation, storage, distribution, rotation, and revocation operations, and authentication failure and key abnormality events in real time, and retains audit logs for traceability.

Images