Post-quantum federal learning system and dynamic migration method

Abstract

The invention provides a post-quantum federal learning system and a dynamic migration method, and relates to the technical field of network security. Dynamic switching between a basic cipher suite and a post quantum cipher suite is realized by introducing a dual-stack communication and cipher agility engine module, and continuous operation and business continuity of the system are ensured. The PQC performance optimizer overcomes the performance bottleneck of the PQC algorithm by reducing the calculation and communication overhead of the PQC algorithm in federated learning, so that the federated learning system can meet the real-time requirement. The hybrid encryption and hierarchical security aggregation module dynamically selects a security level according to a security policy, so that both security and efficiency are considered, and risks possibly existing in a single PQC algorithm are avoided. And the post-quantum security authentication and certification server verifies the integrity and authenticity of the hardware environment and the software environment of the client, a full-stack post-quantum trust chain is constructed, and the overall security of the system is improved.

Description

Technical Field

[0001] This application relates to the field of cybersecurity technology, and more specifically, to a post-quantum federated learning system and a dynamic migration method. Background Technology

[0002] With the rapid development of quantum computing technology, the public-key cryptography systems (such as RSA and ECC) upon which current federated learning systems rely face a serious threat of quantum attacks. To address this challenge, migrating to post-quantum cryptography (PQC) is an inevitable trend, but the actual migration process faces three major technical challenges: 1. Balancing performance and security is challenging: Compared to basic cryptography, the PQC algorithm incurs significantly higher computational and communication overhead. Directly replacing existing cryptographic algorithms in a system could prevent the federated learning system from meeting real-time requirements, thus impacting overall performance.

[0003] 2. Lack of a smooth transition mechanism during migration: Existing technical solutions often adopt a "one-size-fits-all" approach when migrating from basic cryptography to PQC, lacking necessary transition mechanisms. This makes it extremely difficult to achieve a smooth and seamless migration from basic cryptography to PQC while ensuring system continuity and business continuity.

[0004] 3. High risk of algorithm rigidity: PQC algorithms are still in the early stages of development and have not been verified in long-term real-world applications, so there may be undiscovered vulnerabilities. If the system deploys only a single PQC algorithm, once that algorithm is compromised or a defect is discovered, the entire system will face a huge risk of "putting all its eggs in one basket," lacking flexibility and resilience.

[0005] There is currently no effective technical solution to the above problems. Summary of the Invention

[0006] The purpose of this application is to provide a post-quantum federated learning system and a dynamic migration method, aiming to solve the technical problems of existing federated learning systems in the face of quantum computing threats, such as the lack of a smooth transition mechanism when migrating from basic cryptography to post-quantum cryptography, the high performance overhead of the PQC algorithm, and the security risks of a single PQC algorithm.

[0007] In the first aspect, this application provides a post-quantum federated learning system applied to an aggregation server in federated learning, including: a dual-stack communication and cryptographic agility engine module, a PQC performance optimizer, a hybrid encryption and hierarchical security aggregation module, and a post-quantum security authentication and proof server; Dual-stack communication and cryptographic agility engine module for dynamic switching between basic cipher suites and post-quantum cipher suites; The PQC performance optimizer is used to reduce the computational and communication overhead of the PQC algorithm in federated learning. The hybrid encryption and layered security aggregation module is used to dynamically select the security level according to the security policy; The post-quantum security authentication and verification server is used to verify the integrity and authenticity of the client's hardware and software environment.

[0008] This application provides a federated learning system capable of addressing the threat of quantum computing through this technical solution. By introducing dual-stack communication, PQC performance optimization, hybrid encryption and hierarchical security aggregation, and a post-quantum security authentication mechanism, it achieves a smooth transition from traditional cryptography to post-quantum cryptography, effectively solving the problems of difficult migration, high performance overhead, and high security risks in existing technologies, and providing comprehensive post-quantum security guarantees for federated learning.

[0009] Optionally, the dual-stack communication and cryptographic agility engine module includes: The policy manager is used to define, store, and distribute cipher suite priorities and migration policies that the system should use; A dual-stack communication protocol stack is used to support the parallel operation of basic cryptographic suites and post-quantum cryptographic suites; The dynamic negotiator, located in the local decision engine of each client, is used to select the highest priority post-quantum cryptographic suite from the list of suites it supports based on the migration strategy and its own capabilities, and initiate a connection request to the aggregation server. Based on the response from the aggregation server, it determines whether the connection is successful. If the connection is successful, it guides subsequent communication to use the selected post-quantum cryptographic suite. If the connection fails, it triggers a degradation process, guiding subsequent communication to fall back to the basic cryptographic suite allowed by the migration strategy.

[0010] This application achieves intelligent negotiation and dynamic switching of cipher suites between the client and the server through a policy manager, a dual-stack communication protocol stack, and a dynamic negotiator. This ensures that the system maintains backward compatibility during the backward migration to quantum cryptography and can gracefully downgrade according to the actual situation, avoiding business interruption caused by forced upgrades and improving the system's flexibility and availability.

[0011] Optionally, the migration strategy includes a migration timeline and client blacklists / whitelists. The policy manager is also used to force client upgrades based on the migration timeline and to specify allowed or prohibited suites for clients based on the client blacklists / whitelists.

[0012] This application introduces a migration timeline and client blacklists / whitelists, enabling the policy manager to control the migration process of cipher suites more finely. It can not only force clients to upgrade at specific points in time, but also specify allowed or prohibited suites for different clients, thereby achieving more flexible and secure migration management and further improving the system's controllability and security.

[0013] Optionally, the PQC performance optimizer includes: The batch signature verification module is used to perform batch verification of model update signatures from multiple clients. The session multiplexing module generates a session ticket after a complete handshake, encrypts and signs the session ticket using the aggregation server's PQC signature private key, and then sends it to the client. In subsequent training rounds within a preset period, the module receives session tickets provided by the client, verifies the validity of their PQC signatures, and recovers the shared key from the session ticket after successful verification to establish a secure connection. The client-side compute offloading module is used to delegate PQC compute tasks to a trusted agent device.

[0014] This application significantly reduces the computational and communication overhead of the PQC algorithm in federated learning through mechanisms such as batch signature verification, session reuse, and client computation offloading. It effectively solves the performance bottleneck problem of the PQC algorithm, improves the practicality and scalability of the system, and enables the federated learning system to meet real-time requirements while adopting post-quantum cryptography.

[0015] Optionally, the hybrid encryption and layered security aggregation module includes: The security policy manager is used to define security levels and dynamically select security levels based on security policies and distribute them to the corresponding clients. Security policies include data attributes, device capabilities, or compliance requirements. A multi-mode encryption library that supports selecting encryption methods based on security levels; A hybrid aggregator is used to process model updates at different security levels and fuse the aggregation results. Optionally, the security levels include at least: Level 1: Transmission encryption based on PQC KEM and symmetric encryption; Level 2: End-to-end encryption based on PQC homomorphic encryption or secure multi-party computation.

[0016] This application achieves dynamic selection of security levels based on data sensitivity, device capabilities, and compliance requirements through a security policy manager, a multi-mode encryption library, and a hybrid aggregator. It also supports the mixed use of multiple encryption methods, thereby ensuring data security while taking into account system efficiency, achieving a fine balance between security and efficiency.

[0017] Optionally, when the hybrid aggregator performs model updates at different security levels and merges the aggregation results, it specifically executes the following: Broadcast the security policy to all clients; Each client is triggered to generate, according to the security policy, a model update encrypted with PQC KEM and with a level 1 identifier, and a model update encrypted with PQC homomorphic and with a level 2 identifier. After receiving all updated models, based on the identifier, decrypt all model updates corresponding to level one and put them into the plaintext buffer, and put all model updates corresponding to level two into the homomorphic ciphertext buffer. The model updates of all plaintext buffers are averaged to obtain the first processing result; The model update of the homomorphic ciphertext buffer is encoded and transformed to obtain the second processing result; The first and second processing results are fused by homomorphic operations to obtain the final global model update.

[0018] Optionally, the post-quantum security authentication and proof server includes: A third-party certification authority used to verify client-side proof reports and issue PQC signed rulings; A client-side proof generator is used to generate a proof report containing the PQC public key and environment metrics, including the hash value of the currently loaded software environment metrics and the hardware environment identifier. The validator is used to initiate authentication challenges and control the client's participation in federated learning tasks based on the rulings of a third-party authentication authority.

[0019] Optionally, when the validator initiates an authentication challenge and controls the client's participation in the federated learning task based on the ruling of a third-party authentication authority, it specifically performs the following: The verifier receives a ruling from a third-party certification authority; The authenticity of the ruling is verified using the PQC public key from a third-party certified authority. If the verification passes and the client is confirmed to be trustworthy, the client's PQC public key is bound to its identity, and the client is allowed to participate in subsequent federated learning tasks. If verification fails, the client is rejected and blacklisted.

[0020] Secondly, this application also provides a dynamic transfer method applied to a post-quantum federated learning system as described in any of the preceding claims. The dynamic transfer method includes the following steps: S1. Establish a dual-stack communication connection between the client and the server to support dynamic negotiation between basic cryptographic suites and post-quantum cryptographic suites; S2. Control the switching and forced upgrade of cipher suites according to the migration timeline; S3. During the execution of federated learning tasks, batch signature verification, session reuse, and client computation offloading are employed to optimize PQC performance. S4. Dynamically select the security level and perform hybrid encryption and layered security aggregation processing based on data sensitivity, equipment capabilities, or compliance requirements; S5. Perform post-quantum security authentication on the client to ensure the integrity and authenticity of the client's hardware and software environment.

[0021] As shown above, the post-quantum federated learning system and dynamic migration method provided in this application achieve dynamic switching between basic and post-quantum cryptographic suites by introducing a dual-stack communication and cryptographic agility engine module. This avoids system interruptions or compatibility issues caused by traditional "one-size-fits-all" migration methods, ensuring continuous system operation and business continuity. The PQC performance optimizer overcomes the performance bottleneck of the PQC algorithm by reducing its computational and communication overhead in federated learning, enabling the federated learning system to meet real-time requirements. The hybrid encryption and layered security aggregation module dynamically selects the security level according to the security policy, balancing security and efficiency and avoiding the risks that may exist with a single PQC algorithm. The post-quantum security authentication and proof server verifies the integrity and authenticity of the client's hardware and software environments, constructing a full-stack post-quantum trust chain and improving the overall security of the system. In summary, the post-quantum federated learning system of this application provides a comprehensive, efficient, and secure solution that effectively addresses the challenges brought by quantum computing to federated learning, demonstrating significant technological advancements and practical value.

[0022] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing embodiments of this application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description and the accompanying drawings. Attached Figure Description

[0023] Figure 1 This is a flowchart of a dynamic migration method provided in an embodiment of this application. Detailed Implementation

[0024] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0025] It should be noted that similar reference numerals 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. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0026] In a first aspect, this application provides a post-quantum federated learning system applied to an aggregation server in federated learning, including: a dual-stack communication and cryptographic agility engine module, a PQC performance optimizer, a hybrid encryption and hierarchical security aggregation module, and a post-quantum security authentication and proof server; Dual-stack communication and cryptographic agility engine module for dynamic switching between basic cipher suites and post-quantum cipher suites; The PQC performance optimizer is used to reduce the computational and communication overhead of the PQC algorithm in federated learning. The hybrid encryption and layered security aggregation module is used to dynamically select the security level according to the security policy; The post-quantum security authentication and verification server is used to verify the integrity and authenticity of the client's hardware and software environment.

[0027] The "federated learning" mentioned in this application is a distributed machine learning paradigm that allows multiple participants to collaboratively train a model without sharing the original data. The "aggregation server" is responsible for coordinating the client training process and aggregating model updates. "Basic cryptographic suites" typically refer to widely used public-key cryptography algorithms, such as the TLS protocol based on elliptic curve cryptography (ECC) or RSA. "Post-quantum cryptographic suites (PQC)" refer to cryptographic algorithms resistant to post-quantum computer attacks, such as lattice-based Kyber (for key exchange) and Dilithium (for digital signatures). The implementation environment of this application mainly includes the federated learning aggregation server and multiple client devices, which may have different computing capabilities and security requirements.

[0028] The Dual-Stack Communication and Cryptographic Agility Engine module is used for dynamic switching between basic cipher suites and post-quantum cipher suites. As one implementation, this module can be configured to support two independent communication protocol stacks: a basic protocol stack and a PQC protocol stack. The basic protocol stack can implement a basic TLS protocol based on ECC, RSA, or SM2, for example, by modifying an open-source TLS library (such as OpenSSL). The PQC protocol stack can implement TLS handshakes based on PQC KEM (such as Kyber) and PQC digital signatures (such as Dilithium) (e.g., TLS 1.3 with PQC groups / signatures) or custom secure communication protocols. These two protocol stacks can work in parallel, sharing the underlying TCP / UDP transport layer. When a client initiates a connection request, this module can, based on a preset policy or the client's capabilities, prioritize attempting to establish a connection using the PQC protocol stack. If the PQC connection succeeds, subsequent communication will use the post-quantum cipher suite; if the PQC connection fails, it can fall back to the basic protocol stack and use the basic cipher suite to establish a connection.

[0029] The PQC performance optimizer is used to reduce the computational and communication overhead of the PQC algorithm in federated learning. For example, this optimizer can employ batch processing techniques to reduce the overhead of signature verification. In federated learning, the aggregation server needs to verify a large number of model update signatures submitted by clients. The traditional method is to verify them one by one, which is inefficient. Through batch signature verification, multiple signatures and their corresponding messages and public keys can be grouped, and then multiple independent signature verification equations can be merged into a single, more complex verification equation by introducing random linear coefficients. Thus, only one verification calculation of the composite equation is needed to determine whether the entire batch of signatures is valid. Another implementation method is to use a session reuse mechanism. After the client first participates in the task or the session expires, a complete, post-quantum TLS 1.3-style handshake is performed. The server generates a session ticket containing sufficient information (such as master key derivation information, cipher suite identifier, lifespan, etc.), encrypts and signs it using the server's PQC signing private key, and then sends it to the client. In subsequent training rounds, the client only needs to submit this session ticket in ClientHello. After the server verifies the validity and signature of the ticket, it can directly recover the shared key from the ticket without having to perform the expensive PQC KEM operation again.

[0030] The hybrid encryption and layered security aggregation module dynamically selects security levels based on security policies. This module can be configured with a security policy manager to define different security levels and dynamically select the appropriate security level and distribute it to the corresponding clients based on security policies such as data attributes, device capabilities, or compliance requirements. For example, Level 1 can be defined as transport encryption based on PQC KEM and symmetric encryption, while Level 2 can be defined as end-to-end encryption based on PQC homomorphic encryption or secure multi-party computation. When the security policy requires high data privacy protection, Level 2 can be selected; when performance requirements are high and data sensitivity is relatively low, Level 1 can be selected. This module may also include a multi-mode encryption library that supports selecting the appropriate encryption method based on the selected security level, and a hybrid aggregator to handle model updates for different security levels and fuse the aggregation results.

[0031] The post-quantum secure authentication and proof server is used to verify the integrity and authenticity of the client's hardware and software environments. This server may include a client proof generator to generate a proof report containing a PQC public key and environment metrics, where the environment metrics include the hash value of the currently loaded software environment metric and the hardware environment identifier. For example, when a client device is produced or deployed, its hardware security module (such as an HSM / TEE) generates a PQC signing key pair; the private key never leaves the secure hardware environment, while the public key is exported. The hash value of the expected "trusted state" of the client's software stack (operating system, federated learning client software, PQC algorithm library) is pre-computed and registered in the database of the authentication authority. When the client needs to participate in a federated learning task, the proof generator measures the state of the current operating environment, including the memory image hash of the federated learning client software, the hash of the linked PQC cryptographic library, and the hashes of other critical system components, and packages these measurements, a random number, and its own PQC identity public key into a proof report. This report is signed using the endorsement key of the client's hardware security module and then a second-signed using its PQC signing private key. The server may also include a validator for initiating authentication challenges and controlling client participation in federated learning tasks based on the rulings of a third-party authentication authority. The validator forwards a double-signed proof report to the third-party authentication authority, which verifies the hardware signature and software state, and returns the ruling statement to the validator after digitally signing it with its own PQC private key.

[0032] The post-quantum federated learning system in this application runs in a federated learning aggregation server, and its working principle is as follows: First, when a client attempts to connect to the aggregation server, the dual-stack communication and cryptographic agility engine module comes into play. This module, through a dynamic negotiator, prioritizes establishing a secure connection with the client based on post-quantum cryptography, according to preset cipher suite priorities and migration policies. If the negotiation is successful, subsequent communication will be encrypted and authenticated using post-quantum cryptography throughout. If the client does not support post-quantum cryptography or the PQC handshake fails, the system will trigger a degradation process, falling back to the basic cipher suite allowed by the policy to ensure business continuity. During this process, the policy manager can force the client to upgrade or restrict its connection based on the migration timeline or client blacklists / whitelists, thereby achieving a smooth and controlled cryptographic migration.

[0033] During federated learning tasks, the PQC performance optimizer intervenes to mitigate the performance overhead of the PQC algorithm. Specifically, when the aggregation server receives model updates and their PQC signatures from multiple clients, the batch signature verification module does not verify them one by one, but processes them in batches, verifying the validity of multiple signatures at once, significantly reducing computational resource consumption. Simultaneously, the session reuse module generates and issues a session ticket after the client completes its first full PQC handshake. In subsequent training rounds, the client only needs to submit this session ticket, and the server can quickly restore the secure session by verifying the PQC signature on the ticket, avoiding repeated execution of the expensive PQC key exchange process. Furthermore, for clients with limited computational power, the client computation offloading module allows them to delegate computational tasks such as PQC signatures to trusted proxy devices, thereby reducing the client's computational burden.

[0034] Meanwhile, the hybrid encryption and layered security aggregation module dynamically adjusts the security level of data encryption based on the specific needs and security policies of the federated learning task. The security policy manager selects an appropriate security level for different clients or data based on data sensitivity, device capabilities, or compliance requirements. For example, for highly sensitive data, the system selects level two, employing PQC homomorphic encryption or secure multi-party computation, ensuring that the aggregation server cannot obtain plaintext model updates from the client, achieving end-to-end data privacy protection. For scenarios with high performance requirements and relatively low data sensitivity, the system can choose level one, which is transmission encryption based on PQC KEM and symmetric encryption, protecting data security during transmission. The hybrid aggregator can process model updates from different security levels and merge them to ultimately generate a global model update.

[0035] Before the start of the entire federated learning task or at specific points in time, the post-quantum-secure authentication and proof server performs rigorous post-quantum-secure authentication on clients. The client proof generator produces a proof report containing its PQC public key and current hardware and software environment metrics, and double-signs the report using both the classic signature of the hardware security module and its own PQC signature. The verifier forwards this report to a third-party authentication authority, which verifies the report's authenticity and integrity, and signs the ruling using its PQC private key. Upon receiving the ruling, the verifier verifies its authenticity using the third-party authentication authority's PQC public key and decides whether to allow the client to participate in the federated learning task based on the ruling, thus ensuring that only trusted, tamper-proof clients can join the federated learning network.

[0036] In some implementations, the dual-stack communication and cryptographic agility engine module includes: The policy manager is used to define, store, and distribute cipher suite priorities and migration policies that the system should use; A dual-stack communication protocol stack is used to support the parallel operation of basic cryptographic suites and post-quantum cryptographic suites; The dynamic negotiator, located in the local decision engine of each client, is used to select the highest priority post-quantum cryptographic suite from the list of suites it supports based on the migration strategy and its own capabilities, and initiate a connection request to the aggregation server. Based on the response from the aggregation server, it determines whether the connection is successful. If the connection is successful, it guides subsequent communication to use the selected post-quantum cryptographic suite. If the connection fails, it triggers a degradation process, guiding subsequent communication to fall back to the basic cryptographic suite allowed by the migration strategy.

[0037] Specifically, a dual-stack communication protocol stack can be understood as including a PQC protocol stack and a base protocol stack. The PQC protocol stack aims to implement TLS handshakes (e.g., TLS 1.3 with PQC groups / signatures) based on PQC KEM (e.g., Kyber) and PQC digital signatures (e.g., Dilithium) or custom secure communication protocols. The base protocol stack is used to implement basic TLS protocols based on ECC, RSA, or SM2. In practical applications, a dual-stack communication protocol stack can be implemented by modifying open-source TLS libraries (e.g., OpenSSL, BoringSSL) or custom communication middleware to ensure that the two sets of logic can work in parallel and share the underlying TCP / UDP transport layer.

[0038] The dynamic negotiator operates on the client side, selecting the highest-priority post-quantum cipher suite from an ordered list based on a preset migration policy and the client's supported cipher suite capabilities. For example, this list could be [PQC:Kyber768+Dilithium5,PQC:Falcon-1024+Kyber1024,Classic:ECDH-secp521r1+ECDSA], where the list order represents the system's preferences. The migration policy can exist as a configuration file in JSON or a similar format, updated by the administrator, loaded at server startup, and dynamically updated at runtime through a secure management interface. This migration policy includes a migration timeline and client blacklists / whitelists. The migration timeline is a time-based or federated task round-based policy, such as setting "after_2025-12-01": "deny_classic" (i.e., denying basic suite connections after December 1, 2025). Client blacklists / whitelists specify allowed or prohibited suites for specific client versions.

[0039] This application's solution constructs a flexible and robust dynamic switching mechanism for cipher suites by introducing a policy manager, a dual-stack communication protocol stack, and a dynamic negotiator. The policy manager, as the core, centrally manages the priority and migration strategy of cipher suites, ensuring uniform and controllable behavior throughout the system during post-quantum migration. The dual-stack communication protocol stack provides underlying technical support, enabling the system to support the parallel operation of both classical and post-quantum cipher suites, avoiding the risks of a "one-size-fits-all" migration. The dynamic negotiator plays an intelligent decision-making role on the client side, proactively attempting to establish a post-quantum secure connection based on the policy issued by the policy manager and the client's own capabilities. When the PQC connection is successful, the system prioritizes the more secure post-quantum cipher suite; when the PQC connection fails or the client does not support PQC, the dynamic negotiator can trigger a degradation process, reverting to the allowed basic cipher suite, thus ensuring business continuity and backward compatibility. Furthermore, the policy manager can force client upgrades according to the migration timeline, ensuring the system can gradually phase out old and insecure cipher suites according to a preset schedule, achieving a smooth and forced migration.

[0040] In some preferred embodiments, the process of establishing a secure connection between the client and the server before the start of a federated learning task is as follows: First, in step 1: initialization and policy distribution phase, the aggregation server starts and loads the latest password policy. Then, the client initiates a connection request to the server, for example, by establishing a TCP connection.

[0041] Next, in step 2: the client initiates the PQC priority handshake phase. The client's dynamic negotiator selects the highest-priority post-quantum cryptographic suite from its supported suite list, such as TLS_KYBER768_RSA_WITH_AES_256_GCM_SHA384, and sends it as the preferred suite in the ClientHello message. This approach reflects the client's proactive attempt to use the most advanced PQC scheme, balancing backward compatibility and security priorities.

[0042] Subsequently, in step 3: server response and negotiation phase, after receiving ClientHello, the server queries its cipher suite policy manager.

[0043] If we enter Scenario A: Both parties support PQC (ideal path), and the server finds the client's proposed post-quantum cryptographic suite in its priority list and is permitted for use, then the server replies with ServerHello, confirming the use of the post-quantum cryptographic suite. Subsequent key exchange and authentication processes will all be completed using the PQC algorithm, thus establishing a secure post-quantum channel.

[0044] If scenario B occurs: the client does not support PQC or the PQC handshake fails (graceful degradation), for example, the client is an older version whose ClientHello only contains classic suites, or the handshake fails due to a mismatch in the supported post-quantum cryptographic suites. In this case, the server's negotiation engine will automatically trigger a degradation process, falling back to classic cryptographic suites allowed in the policy, such as TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384. The server regenerates a ServerHello response client using classic suites, thus establishing a classic secure channel, ensuring backward compatibility and business continuity. Simultaneously, the system will record this degradation event for auditing purposes.

[0045] Furthermore, in step 4: the policy-driven upgrade phase, after the downgraded connection is established, the server can decide whether to accept the connection based on the timeline in the policy manager. For example, if the policy stipulates "Classic suites are prohibited from today," but a client still uses the classic suites to connect, the server can immediately send a "policy reject" message and actively disconnect after completing the handshake, forcing the client to upgrade its software to support PQC. This is not only a negotiation mechanism but also a proactive migration management tool, allowing administrators to smoothly set and enforce migration deadlines.

[0046] Finally, in step 5: Connection Reuse and Future Upgrade Phase, once the connection is established, the session key will be cached for subsequent communication (session reuse), avoiding the expensive PQC handshake in each training round. When the client software is updated, it will automatically try a higher-priority post-quantum cryptographic suite on the next connection, thus achieving a seamless upgrade.

[0047] In some implementations, the migration policy includes a migration timeline and client blacklists / whitelists. The policy manager is also used to force client upgrades based on the migration timeline and to specify allowed or prohibited suites for clients based on the client blacklists / whitelists.

[0048] Upon receiving a connection request from a client, the policy manager assesses the situation based on a predefined migration timeline. For example, if the current time has passed the deadline set on the migration timeline, and the client still attempts to connect using basic cipher suites, the policy manager can force the client to upgrade its software to support post-quantum cipher suites. Even after a downgraded connection is established, the policy manager can decide whether to accept the connection based on the migration timeline, thus forcing the client to upgrade. Furthermore, the policy manager uses client blacklists and whitelists to specify which cipher suites are allowed or prohibited for each client. For example, for a specific client version, it can be explicitly stated that it can only use certain specific post-quantum cipher suites, or that it can be prohibited from using certain cipher suites known to have vulnerabilities, thereby achieving granular security management.

[0049] This application's solution refines the migration strategy into a migration timeline and client blacklists / whitelists, and empowers the policy manager to force clients to upgrade and specify allowed or prohibited suites based on these strategies, making the entire post-quantum migration process more controllable and flexible. When a client initiates a connection request, the dynamic negotiator makes an initial selection based on its own suite list and migration strategy. However, the final connection establishment and suite usage still require the final decision of the policy manager 100. By checking the migration timeline, the policy manager can ensure that the system gradually phases out basic cryptographic suites after preset time points, forcing clients to migrate to post-quantum cryptographic suites, thereby avoiding migration stagnation caused by incompatible client versions. Simultaneously, through client blacklists / whitelists, the policy manager can provide customized cryptographic suite usage rules based on the characteristics or security needs of different clients. For example, clients with weaker computing power can be allowed to use post-quantum cryptographic suites with lower performance overhead, while clients with high security requirements can be forced to use more secure post-quantum cryptographic suites, thus ensuring both security and system compatibility and availability.

[0050] In some implementations, the PQC performance optimizer includes: The batch signature verification module is used to perform batch verification of model update signatures from multiple clients. The session multiplexing module generates a session ticket after a complete handshake, encrypts and signs the session ticket using the aggregation server's PQC signature private key, and then sends it to the client. In subsequent training rounds within a preset period, the module receives session tickets provided by the client, verifies the validity of their PQC signatures, and recovers the shared key from the session ticket after successful verification to establish a secure connection. The client-side compute offloading module is used to delegate PQC compute tasks to a trusted agent device.

[0051] Specifically, the batch signature verification module is used to perform batch verification of model update signatures from multiple clients. In practice, not all PQC signature algorithms are suitable for batch verification. This system prioritizes signature schemes that mathematically support batch verification optimization, such as lattice-based Dilithium or hash-based SPHINCS+. For Dilithium, the verification process involves linear algebra operations, and multiple signature verifications can be optimized by combining multiple linear equations into a composite equation. This module implements a dedicated batch verification algorithm. After the aggregation server receives a batch (e.g., 100) of client model updates and their corresponding PQC signatures, this module does not immediately perform individual verifications. Instead, it groups these signatures, their corresponding messages (model update data), and public keys. For security reasons, an "all or nothing" batch verification technique is typically used, meaning either the entire batch passes or fails. The algorithm introduces random linear coefficients to merge multiple independent signature verification equations into a single, more complex verification equation. By performing the verification calculation of this composite equation only once, it can determine with a very high probability whether the entire batch of signatures is valid. For example, to verify the validity of {σ_i} for message {m_i} and public key {pk_i}, instead of checking that each Verify(pk_i,m_i,σ_i) == true, a random coefficient r_i is generated, and an aggregation equation is verified: Verify_Aggregate({pk_i},{m_i},{σ_i},{r_i}) == true. If batch verification fails, it means that at least one signature is invalid. In this case, a binary search strategy (such as splitting the batch in half and re-verifying) or a rollback to verifying each signature individually can be used to quickly locate and eliminate invalid malicious updates.

[0052] The session multiplexing module generates a session ticket after a complete handshake, encrypts and signs it using the aggregation server's PQC signing private key, and sends it to the client. In subsequent training rounds within a preset period, the module receives session tickets from the client, verifies the validity of their PQC signatures, and, upon successful verification, recovers the shared key from the session ticket to establish a secure connection. Specifically, a complete, post-quantum TLS 1.3 style handshake is performed after the client's first participation in a task or after the session expires. This handshake negotiates the master key MS using a PQC KEM (such as Kyber). The server generates a session ticket containing sufficient information (such as master key derivation information, cipher suite identifier, lifespan, etc.), encrypts and signs it using the server's PQC signing private key, and sends it to the client. In subsequent training rounds, the client only needs to submit this session ticket in the ClientHello. After the server verifies the validity and signature of the ticket, it can directly recover the shared key from the ticket without performing the costly PQC KEM operation again. This shared key is used to derive the symmetric encryption key for the current round of communication. The session ticket itself is encrypted and authenticated to prevent eavesdropping and tampering. The ticket has a strict lifespan (e.g., 12 hours), after which a full handshake is forced to be performed again to provide forward security. The server needs to securely manage the keys used to encrypt the tickets.

[0053] The client-side compute offloading module delegates PQC computation tasks to a trusted proxy device. In practice, this module introduces a trusted local proxy, such as a home gateway, edge server, or an intermediate device with a TEE (Trusted Execution Environment). A secure channel is pre-established between the weak client and the local proxy, which can use lightweight classic cryptography because the link is local. When the weak client needs to generate a signature for a model update, it does not compute it directly but sends the message digest to be signed to the local proxy. The local proxy (with stronger computational capabilities) performs the signing operation using a PQC private key pre-configured for the client. Crucially, the private key is securely stored in the proxy's TEE and is never exposed to the weak client in plaintext. The proxy returns the generated complete PQC signature to the weak client. The weak client then submits the model update and the received signature together to a remote aggregation server. This scheme relies on trust in the local proxy, which can be established through hardware (TEE), physical security (gateway deployed in a trusted location), or security protocols. The aggregation server does not need to be aware of this unloading process; it only verifies the validity of the final signature, and the verification process is transparent to the server.

[0054] Through the above technical solutions, the post-quantum federated learning system of this application has achieved significant technical results in PQC performance optimization. First, the batch signature verification mechanism greatly improves the efficiency of the aggregation server in processing client signatures, especially in large-scale federated learning scenarios, significantly shortening aggregation time and increasing system throughput. Second, the session reuse mechanism effectively reduces the redundant computation and communication overhead caused by PQC handshakes, enabling each round of training in federated learning to be conducted with lower latency and higher efficiency, thereby improving system real-time performance and user experience. Third, the client computation offloading mechanism solves the problem that resource-constrained clients cannot handle the complex computations of PQC, allowing more heterogeneous devices to participate in federated learning securely and efficiently, expanding the application scope of federated learning, while ensuring the security of PQC private keys through trusted proxy devices. These optimization measures work together to make the deployment of PQC algorithms in federated learning more practical and efficient, overcoming the inherent performance challenges of traditional PQC schemes and laying a solid foundation for the widespread application of post-quantum federated learning.

[0055] In some implementations, the hybrid encryption and layered security aggregation module includes: The security policy manager is used to define security levels and dynamically select security levels based on security policies and distribute them to the corresponding clients. Security policies include data attributes, device capabilities, or compliance requirements. A multi-mode encryption library that supports selecting encryption methods based on security levels; Hybrid aggregator is used to handle model updates at different security levels and merge the aggregation results.

[0056] Specifically, the security policy manager can be understood as the core decision-making unit in the system. Its main responsibility is to formulate, store, and distribute security policies for federated learning tasks. These security policies are the key basis for guiding the system in selecting security levels. Their content can cover data attributes, such as the sensitivity or classification level of the data; device capabilities, such as the computing power, storage resources, or whether the client device has a trusted execution environment; and compliance requirements, such as data privacy regulations specific to a particular industry or region. By comprehensively considering these factors, the security policy manager can dynamically assign an appropriate security level to each client or each round of federated learning tasks and distribute it to the corresponding client to ensure that security measures match actual needs.

[0057] The multi-mode encryption library is configured to support multiple encryption methods, flexibly selecting and applying appropriate encryption algorithms based on the security level determined by the security policy manager. For example, when the security level requirement is low, a transmission encryption method based on PQC KEM and symmetric encryption can be used; while when the security level requirement is high, and end-to-end data privacy protection is needed, more complex encryption technologies such as PQC homomorphic encryption or secure multi-party computation can be supported. This encryption library is designed to provide a scalable encryption framework to adapt to various post-quantum encryption algorithms and security requirements that may emerge in the future.

[0058] In practical applications, the hybrid aggregator is specifically used to process model updates from different security levels and ultimately fuse the aggregation results. During federated learning, clients may be assigned to different security levels, and their uploaded model updates may use different encryption methods. The hybrid aggregator is designed to identify these updates with different encryption modes and perform corresponding decryption or homomorphic operations based on their encryption type, ultimately effectively fusing these processed model updates to generate a global model update. Its purpose is to ensure that the aggregation process of federated learning can proceed smoothly even in scenarios with mixed security levels, and to guarantee the accuracy and security of the final aggregation result.

[0059] This application's solution addresses the challenge of flexibly handling diverse security needs and effectively aggregating model updates with different encryption modes in federated learning through the collaborative work of a security policy manager, a multi-mode encryption library, and a hybrid aggregator. Specifically, when a federated learning task starts, the security policy manager dynamically determines the most suitable security level for each participating client based on preset security policies, such as data sensitivity, client device capabilities, or compliance requirements. The security policy manager then distributes the selected security level information to the corresponding client. Upon receiving its assigned security level, the client uses the corresponding encryption methods supported by the multi-mode encryption library to encrypt its local model updates. For example, a client requiring high privacy protection might choose homomorphic encryption; while a client requiring only transmission encryption might choose a combination of PQC KEM and symmetric encryption. Once these model updates with different encryption modes are uploaded to the aggregation server, the hybrid aggregator identifies and processes these updates with different security level identifiers. For transmission-encrypted model updates, the hybrid aggregator performs decryption; for homomorphically encrypted model updates, it directly performs homomorphic aggregation in the ciphertext domain. Ultimately, the hybrid aggregator merges these model updates processed in different ways to obtain a unified global model update. This allows the system to flexibly adjust the security level according to actual needs while ensuring a smooth and efficient aggregation process.

[0060] In some implementations, the security levels include at least: Level 1: Transmission encryption based on PQC KEM and symmetric encryption; Level 2: End-to-end encryption based on PQC homomorphic encryption or secure multi-party computation.

[0061] Layer 1 aims to provide security during transmission. Specifically, the client and aggregation server negotiate a shared key using a post-quantum cryptography key encapsulation mechanism (PQC KEM), such as the Kyber algorithm. The client then uses a symmetric key derived from this shared key (e.g., AES-256-GCM) to encrypt and authenticate its local model update, generating ciphertext, which it then transmits to the aggregation server. Upon receiving the ciphertext, the aggregation server decrypts it using the same symmetric key derived from the shared key, obtaining the plaintext model update. This layer primarily protects the confidentiality and integrity of the model update during transmission, but the aggregation server has access to each client's plaintext model update before aggregation.

[0062] Furthermore, Layer 2 aims to provide end-to-end secure aggregation, ensuring that the aggregation server cannot obtain any plaintext model updates from clients during the aggregation process, and can only decrypt the final aggregation result. This layer can be implemented based on post-quantum homomorphic encryption (PQC-HE) or secure multi-party computation (SMPC) techniques. Taking PQC homomorphic encryption as an example, the aggregation server generates a pair of PQC homomorphic encryption keys (including a public key HE_pk and a private key HE_sk) and distributes the public key HE_pk to the clients that need Layer 2 protection. After receiving the public key HE_pk, the client directly uses the public key to homomorphically encrypt its local model update, generating homomorphic ciphertext, and sends this homomorphic ciphertext to the aggregation server. After receiving the homomorphic ciphertext from all clients, the aggregation server directly performs aggregation operations in the ciphertext state, such as homomorphic addition and homomorphic scalar multiplication. After aggregation is complete, the aggregation server uses its private key HE_sk to decrypt the aggregated homomorphic ciphertext, thereby obtaining the final global model update.

[0063] This application's solution defines and supports the two security levels mentioned above, enabling the hybrid encryption and layered security aggregation module to flexibly select appropriate security protection strengths for different federated learning tasks or clients based on actual security strategies. Level 1 ensures post-quantum security of data transmission through PQC KEM and symmetric encryption, suitable for scenarios with high security requirements during transmission but high tolerance for server-side data visibility. Level 2 achieves end-to-end encryption of client model updates through PQC homomorphic encryption or secure multi-party computation, ensuring that even the aggregation server cannot obtain plaintext data from individual clients, thus meeting the needs of application scenarios with extremely high data privacy requirements.

[0064] In some implementations, when the hybrid aggregator performs model updates at different security levels and merges the aggregation results, it specifically executes the following: Broadcast the security policy to all clients; Each client is triggered to generate, according to the security policy, a model update encrypted with PQC KEM and with a level 1 identifier, and a model update encrypted with PQC homomorphic and with a level 2 identifier. After receiving all updated models, based on the identifier, decrypt all model updates corresponding to level one and put them into the plaintext buffer, and put all model updates corresponding to level two into the homomorphic ciphertext buffer. The model updates of all plaintext buffers are averaged to obtain the first processing result; The model update of the homomorphic ciphertext buffer is encoded and transformed to obtain the second processing result; The first and second processing results are fused by homomorphic operations to obtain the final global model update.

[0065] Specifically, the security policy is broadcast to all clients to ensure that all clients participating in federated learning can access and comply with the latest security policy. This security policy can be defined, stored, and distributed by the security policy manager, and can include data attributes, device capabilities, or compliance requirements. Triggering each client to generate a model update encrypted with PQC KEM and bearing a Level 1 identifier, and a model update encrypted with PQC homomorphic encryption and bearing a Level 2 identifier, respectively, means that the client determines the appropriate security level based on the received security policy. If a client is designated as Level 1, its model update will be symmetrically encrypted using the shared key negotiated with PQC KEM and will bear a Level 1 identifier; if a client is designated as Level 2, its model update will be directly encrypted using the PQC homomorphic encryption public key and will bear a Level 2 identifier. Upon receiving all updated models, the aggregation server decrypts all model updates corresponding to Level 1 and places them in a plaintext buffer, while placing all model updates corresponding to Level 2 in a homomorphic ciphertext buffer. This means that after receiving model updates from the client, the aggregation server categorizes and processes them according to the level identifier attached to the model updates. For Level 1 model updates, the server uses a shared key to decrypt them, restoring them to plaintext form, and stores them in the plaintext buffer. For Level 2 model updates, since they have already undergone homomorphic encryption, the server does not need to decrypt them and directly stores them in the homomorphic ciphertext buffer. Averaging all model updates in the plaintext buffer yields the first processing result. This involves applying standard federated averaging or other aggregation algorithms to all model updates collected in the plaintext buffer to obtain a preliminary aggregation result. Encoding and transforming the model updates in the homomorphic ciphertext buffer yields the second processing result. This involves performing homomorphic aggregation operations, such as homomorphic addition and homomorphic scalar multiplication, on the model updates in the homomorphic ciphertext buffer to complete the aggregation in ciphertext, resulting in a homomorphically encrypted aggregation result. The final global model update is obtained by fusing the first and second processing results through homomorphic operations. This involves homomorphically encrypting the plaintext first processing result and then performing homomorphic addition and other operations with the homomorphically ciphertext second processing result. The result is a homomorphic ciphertext that integrates the data from the two security levels. This ciphertext can then be decrypted by the server using its private key to obtain the final global model.

[0066] This application's solution broadcasts the security policy to all clients, ensuring that clients adhere to a unified security standard when generating model updates. Furthermore, clients generate encrypted model updates with different levels of identifiers according to the policy, enabling the aggregation server to clearly distinguish and process heterogeneous data. Upon receiving a model update, the server decrypts it into plaintext or directly stores it as homomorphic ciphertext based on the identifier, placing it into the corresponding buffer. Subsequently, the model updates in the plaintext buffer undergo conventional averaging to obtain the first processing result, which fully utilizes the efficiency of transmission encryption. Simultaneously, the model updates in the homomorphic ciphertext buffer undergo homomorphic aggregation to obtain the second processing result, achieving a high level of privacy protection without revealing the original data. Finally, the first and second processing results are fused through homomorphic operations, allowing the aggregation results of two different security levels to be uniformly integrated while maintaining their respective security characteristics, thus overcoming the complexity and limitations of traditional methods in processing heterogeneous encrypted data fusion. This enables the system to dynamically adjust the security policy according to actual needs and data sensitivity, achieving a better balance between security and performance.

[0067] In some implementations, the post-quantum secure authentication and proof server includes: A third-party certification authority used to verify client-side proof reports and issue PQC signed rulings; A client-side proof generator is used to generate a proof report containing the PQC public key and environment metrics, including the hash value of the currently loaded software environment metrics and the hardware environment identifier. The validator is used to initiate authentication challenges and control the client's participation in federated learning tasks based on the rulings of a third-party authentication authority.

[0068] The third-party authentication authority is used to verify the client's proof report and issue PQC signature decisions. Specifically, after receiving the proof report forwarded by the validator from the aggregation server, the third-party authentication authority performs a verification operation. This verification operation includes verifying the hardware signature in the report using the hardware vendor's root certificate to confirm that the report indeed comes from a genuine, tamper-proof Trusted Execution Environment (TEE). Simultaneously, the third-party authentication authority compares the software metric hash value in the report with trusted benchmark values ​​pre-registered in its database to confirm that the software running on the client is a certified, tamper-proof version and contains the correct PQC algorithm library. After completing the verification, the third-party authentication authority generates a "verification passed" or "verification failed" decision statement, digitally signs the decision statement using its own PQC private key, and then returns it to the aggregation server.

[0069] The client-side proof generator generates a proof report containing the PQC public key and environment metrics, including the hash of the currently loaded software environment metric and the hardware environment identifier. Specifically, the client-side proof generator is triggered when the client receives a post-quantum authentication challenge from the validator on the aggregation server. It first measures the state of the current operating environment, such as the memory image hash of the federated learning client software, the hash of linked PQC cryptographic libraries (such as implementations of Kyber and Dilithium), and the hashes of other critical system components. Then, the client-side proof generator packages this measurement result, a random number received from the authentication challenge, and the client's own PQC identity public key into a proof report. This proof report is first signed using the endorsement key of the client's hardware security module—a classic digital signature, secure by the hardware manufacturer. To ensure the entire proof process is post-quantum, the client further signs the entire proof report (including the hardware signature) a second time using its PQC signing private key. Thus, the proof report will have two signatures: a classic signature from the hardware and a PQC signature from the client.

[0070] The validator initiates authentication challenges and controls client participation in federated learning tasks based on the rulings of a third-party authentication authority. Specifically, when a client initiates a connection request to the aggregation server, the validator does not immediately begin the federated learning process. Instead, it first sends a post-quantum authentication challenge to the client, which includes a random number to prevent replay attacks. Upon receiving the client's double-signed proof report, the validator extracts the client's PQC public key and the measurement value from the report, forwards the entire proof report to a trusted third-party authentication authority, and requests verification. Upon receiving the PQC-signed ruling statement from the third-party authentication authority, the validator uses the authority's PQC public key to verify the statement's authenticity. If the verification passes and the statement confirms the client's trustworthiness, the validator binds the client's PQC public key to its identity and allows the client to participate in subsequent federated learning tasks. Conversely, if the verification fails, the server rejects the client and blacklists it.

[0071] This application's solution, through the coordinated use of the aforementioned modules, constructs a full-stack post-quantum trust chain. Combining a Trusted Execution Environment (TEE) and PQC signatures, it builds a full-stack trusted verification mechanism from device hardware to software environment. This significantly enhances the security of the federated learning system, ensures the integrity and authenticity of the client's computing environment, and effectively fills the gap in post-quantum security of traditional authentication mechanisms. Specifically, by introducing a third-party authentication authority, independent and authoritative verification of the client's proof report is achieved, reducing the verification burden on the aggregation server and enhancing the credibility of the authentication results. The client proof generator generates a double-signed proof report containing the PQC public key and environment metrics, proving not only the client's identity but also providing evidence of the integrity of its operating environment, which possesses post-quantum properties. The verifier, as a key link in access control, can precisely control the client's participation permissions based on authoritative rulings, effectively preventing potential malicious or compromised clients from interfering with the federated learning process, greatly improving the robustness and security of the entire federated learning system.

[0072] In some implementations, when the validator initiates an authentication challenge and controls the client's participation in the federated learning task based on the ruling of a third-party authentication authority, it specifically performs the following: The verifier receives a ruling from a third-party certification authority; The authenticity of the ruling is verified using the PQC public key from a third-party certified authority. If the verification passes and the client is confirmed to be trustworthy, the client's PQC public key is bound to its identity, and the client is allowed to participate in subsequent federated learning tasks. If verification fails, the client is rejected and blacklisted.

[0073] Upon receiving a ruling from a third-party certification authority, the verifier first needs to verify the authenticity and completeness of the ruling. Specifically, the ruling is a statement digitally signed by the third-party certification authority using its PQC private key. Therefore, the verifier will verify the PQC signature of the ruling statement using the PQC public key of a pre-trusted third-party certification authority. This step aims to ensure that the ruling information has not been tampered with and truly originates from a trusted third-party certification authority.

[0074] Furthermore, after the validator verifies the authenticity of the ruling, it makes a final decision based on the content of the ruling statement. If the ruling statement explicitly indicates that the client is trustworthy—that is, the verification passes and the statement confirms the client's trustworthiness—the validator will bind the client's PQC public key to its identity, thereby establishing post-quantum identity trust for the client. Based on this, the client will be allowed to participate in subsequent federated learning tasks. Conversely, if the verification fails, or the ruling statement indicates that the client is untrustworthy, the client will be refused participation in the federated learning task and may be blacklisted to prevent it from attempting to connect or participate again.

[0075] This application's scheme achieves fine-grained control over client participation in federated learning tasks by delegating the complex verification of client proof reports to a professional third-party certification authority, with the verifier providing final confirmation of the PQC signature ruling returned by the third-party certification authority. Specifically, the verifier no longer needs to directly handle classical signatures of the client's hardware security modules or complex software environment metric comparisons, but instead relies on the professional judgment of the third-party certification authority. By verifying the authenticity of the ruling using the third-party certification authority's PQC public key, the reliability and post-quantum security of the decision-making basis are ensured. Once the ruling is confirmed as valid and the client is trustworthy, the client's PQC public key is bound to its identity, providing a post-quantum trust foundation for its subsequent secure communication and model updates. If the ruling indicates that the client is untrustworthy, its participation is immediately rejected, effectively preventing potentially malicious or compromised clients from entering the federated learning system, thereby maintaining the security and data integrity of the entire system.

[0076] Through the above technical solutions, this application significantly enhances the security and efficiency of the post-quantum federated learning system in terms of client admission control. First, by offloading the complex verification logic of client proofs from the aggregation server to a professional third-party certification authority, the computational burden on the aggregation server is reduced, and the professionalism and independence of the third-party certification authority are leveraged to improve the authority of the verification results. Second, by verifying the PQC signature decisions of the third-party certification authority through a verifier, post-quantum security of the decision-making process is ensured, effectively resisting the threat of quantum attacks to the authenticity of certification decisions. Furthermore, the explicit admission or rejection mechanism based on the decision results can quickly and accurately identify and isolate untrusted clients, thereby ensuring the smooth operation of federated learning tasks in a trusted environment and improving the overall security protection capability and operational efficiency of the system.

[0077] Secondly, please refer to Figure 1 This application also provides a dynamic transfer method applied to a post-quantum federated learning system as described in any of the preceding claims. The dynamic transfer method includes the following steps: S1. Establish a dual-stack communication connection between the client and the server to support dynamic negotiation between basic cryptographic suites and post-quantum cryptographic suites; S2. Control the switching and forced upgrade of cipher suites according to the migration timeline; S3. During the execution of federated learning tasks, batch signature verification, session reuse, and client computation offloading are employed to optimize PQC performance. S4. Dynamically select the security level and perform hybrid encryption and layered security aggregation processing based on data sensitivity, equipment capabilities, or compliance requirements; S5. Perform post-quantum security authentication on the client to ensure the integrity and authenticity of the client's hardware and software environment.

[0078] Specifically, the establishment of a dual-stack communication connection aims to allow clients and aggregation servers to simultaneously support and run both basic and post-quantum cryptographic suites on the same communication infrastructure. Dynamic negotiation refers to the client's dynamic negotiator selecting the highest-priority post-quantum cryptographic suite from its supported suite list and initiating a connection request to the aggregation server during the connection establishment process, based on a preset migration strategy and its own capabilities. The response from the aggregation server determines whether the connection is successful. If successful, subsequent communication uses the selected post-quantum cryptographic suite; if the connection fails, a degradation process is triggered, reverting subsequent communication to the basic cryptographic suite allowed by the migration strategy, ensuring successful connection establishment and business continuity.

[0079] The migration timeline can be understood as a pre-defined strategic time point or stage used to guide the migration of cipher suites from basic to post-quantum. The policy manager can define, store, and distribute the cipher suite priorities and migration policies that the system should use, where the migration policies include the migration timeline. The policy manager is also used to force client upgrades based on the migration timeline. For example, if the policy stipulates that basic suite connections will be rejected after a specific date, the server can immediately send a "policy rejection" message and actively disconnect after completing the handshake, forcing the client to upgrade its software to support PQC. In this way, the system can proactively control the switching of cipher suites and force clients to upgrade their software to support post-quantum cipher suites when specific migration timelines are reached, thereby driving the entire federated learning ecosystem to gradually evolve towards post-quantum security standards.

[0080] The security policy manager can dynamically evaluate and select the most suitable security level for each client or task based on data attributes, device capabilities, or compliance requirements in the federated learning task. Security levels include at least Level 1: transport encryption based on PQC KEM and symmetric encryption; and Level 2: end-to-end encryption based on PQC homomorphic encryption or secure multi-party computation. Hybrid encryption and layered security aggregation processing means the system can support and integrate model updates under different security levels. For example, it can trigger each client to generate model updates encrypted with PQC KEM and marked with a Level 1 identifier, and model updates encrypted with PQC homomorphic encryption and marked with a Level 2 identifier, respectively, according to the security policy. After receiving all updated models, based on the identifier, all model updates corresponding to Level 1 are decrypted and placed in the plaintext buffer, and all model updates corresponding to Level 2 are placed in the homomorphic ciphertext buffer. The model updates of all plaintext buffers are averaged to obtain the first processing result; the model updates of homomorphic ciphertext buffers are encoded and transformed to obtain the second processing result; the first and second processing results are fused through homomorphic operations to obtain the final global model update, so as to achieve a fine balance between security and efficiency.

[0081] Post-quantum security authentication refers to a rigorous authentication process that verifies the integrity and authenticity of a client's operating environment before the client participates in federated learning tasks. This involves the client's proof generator producing a proof report containing a PQC public key and environment metrics, including the hash value of the currently loaded software environment metric and the hardware environment identifier. This report is signed using the endorsement key of the client's hardware security module and then a second signature using the client's PQC signing private key. Subsequently, the aggregate server's verifier forwards this report to a third-party authentication authority for verification. Upon successful verification, the third-party authority digitally signs the ruling statement using its PQC private key and returns it to the aggregate server. The aggregate server's verifier, upon receiving the ruling from the third-party authority, uses the authority's PQC public key to verify its authenticity. If verification passes and the statement confirms the client's trustworthiness, the client's PQC public key is bound to its identity, allowing the client to participate in subsequent federated learning tasks; if verification fails, the client is rejected and blacklisted, thus constructing a full-stack post-quantum trust chain from hardware to software.

[0082] This application's dynamic migration method, by coordinating the five core steps mentioned above, effectively addresses the challenges of achieving a smooth transition, performance optimization, flexible security, and sustained trust in post-quantum federated learning systems. By establishing a dual-stack communication connection between the client and server and supporting dynamic negotiation, this method enables the system to flexibly choose between basic and post-quantum cryptographic suites, avoiding compatibility issues and business interruptions that may occur with traditional "one-size-fits-all" migration methods, and ensuring the smooth operation of the system during its evolution towards the post-quantum era. By controlling the switching and forced upgrades of cryptographic suites according to the migration timeline, this method provides the system with a policy-driven migration management mechanism, which can proactively drive clients to upgrade their cryptographic suites based on a preset schedule or specific events, effectively managing the progress and risks of migration. During the execution of federated learning tasks, by employing batch signature verification processing, session reuse processing, and client computation offloading processing, this method significantly optimizes the performance bottleneck of the PQC algorithm in federated learning, making the practical application of the PQC algorithm more feasible and efficient. Furthermore, by dynamically selecting security levels based on data sensitivity, device capabilities, or compliance requirements and performing hybrid encryption and layered security aggregation processing, this method achieves a fine-grained balance between security and efficiency. It can allocate different security protection strengths to different data or clients according to the differentiated needs of specific scenarios. Finally, by performing post-quantum security authentication on the client, this method constructs a full-stack post-quantum trust chain, ensuring the integrity and authenticity of the client devices and their software environments participating in federated learning, effectively resisting security threats from malicious clients or tampered environments.

[0083] Post-quantum security authentication refers to a rigorous authentication process that verifies the integrity and authenticity of a client's operating environment before the client participates in federated learning tasks. This involves the client's proof generator producing a proof report containing a PQC public key and environment metrics, including the hash value of the currently loaded software environment metric and the hardware environment identifier. This report is signed using the endorsement key of the client's hardware security module and then a second signature using the client's PQC signing private key. Subsequently, the aggregate server's verifier forwards this report to a third-party authentication authority for verification. Upon successful verification, the third-party authority digitally signs the ruling statement using its PQC private key and returns it to the aggregate server. The aggregate server's verifier, upon receiving the ruling from the third-party authority, uses the authority's PQC public key to verify its authenticity. If verification passes and the statement confirms the client's trustworthiness, the client's PQC public key is bound to its identity, allowing the client to participate in subsequent federated learning tasks; if verification fails, the client is rejected and blacklisted, thus constructing a full-stack post-quantum trust chain from hardware to software.

[0084] This application's dynamic migration method, by coordinating the five core steps mentioned above, effectively addresses the challenges of achieving a smooth transition, performance optimization, flexible security, and sustained trust in post-quantum federated learning systems. By establishing a dual-stack communication connection between the client and server and supporting dynamic negotiation, this method enables the system to flexibly choose between basic and post-quantum cryptographic suites, avoiding compatibility issues and business interruptions that may occur with traditional "one-size-fits-all" migration methods, and ensuring the smooth operation of the system during its evolution towards the post-quantum era. By controlling the switching and forced upgrades of cryptographic suites according to the migration timeline, this method provides the system with a policy-driven migration management mechanism, which can proactively drive clients to upgrade their cryptographic suites based on a preset schedule or specific events, effectively managing the progress and risks of migration. During the execution of federated learning tasks, by employing batch signature verification processing, session reuse processing, and client computation offloading processing, this method significantly optimizes the performance bottleneck of the PQC algorithm in federated learning, making the practical application of the PQC algorithm more feasible and efficient. Furthermore, by dynamically selecting security levels based on data sensitivity, device capabilities, or compliance requirements and performing hybrid encryption and layered security aggregation processing, this method achieves a fine-grained balance between security and efficiency. It can allocate different security protection strengths to different data or clients according to the differentiated needs of specific scenarios. Finally, by performing post-quantum security authentication on the client, this method constructs a full-stack post-quantum trust chain, ensuring the integrity and authenticity of the client devices and their software environments participating in federated learning, effectively resisting security threats from malicious clients or tampered environments.

[0085] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0086] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A post-quantum federated learning system, applied to an aggregation server of federated learning, characterized in that, Comprise: Dual-stack communication and cryptographic agility engine module, PQC performance optimizer, hybrid encryption and layered security aggregation module, and post-quantum secure authentication and attestation server; Dual-stack communication and cryptographic agility engine module, for dynamic switching between basic cryptographic suites and post-quantum cryptographic suites; PQC performance optimizer, for reducing the computational and communication overhead of PQC algorithms in federated learning; Hybrid encryption and layered security aggregation module, for dynamically selecting security levels according to security policies; Post-quantum secure authentication and attestation server, for verifying the integrity and authenticity of client hardware and software environments.

2. The post-quantum federated learning system of claim 1, wherein, The dual-stack communication and cryptographic agility engine module comprises: A policy manager for defining, storing and issuing cryptographic suite priority and migration policies to be used by the system; A dual-stack communication protocol stack for supporting the parallel running of basic cryptographic suites and post-quantum cryptographic suites; A dynamic negotiator located in the local decision engine of each client, for selecting the highest priority post-quantum cryptographic suite from the list of suites it supports according to the migration policy and its own capabilities, and initiating a connection request to the aggregation server, determining whether the connection is successful according to the response from the aggregation server, if the connection is successful, guiding the subsequent communication to use the selected post-quantum cryptographic suite, if the connection fails, triggering a downgrade process, guiding the subsequent communication to fall back to the basic cryptographic suite allowed by the migration policy.

3. The post-quantum federated learning system of claim 2, wherein: The migration policy includes a migration timeline and a client blacklist and whitelist, and the policy manager is further configured to force the client to upgrade according to the migration timeline, and to specify the allowed or prohibited suite for the client according to the client blacklist and whitelist.

4. The post-quantum federated learning system of claim 1, wherein, The PQC performance optimizer comprises: A batch signature verification module for batch verification of model update signatures of multiple clients; A session reuse module for generating a session ticket after a complete handshake, encrypting and signing the session ticket using the PQC signature private key of the aggregation server, and then sending it to the client, in the subsequent training rounds within the preset period, receiving the session ticket provided by the client, verifying the validity of the PQC signature, and recovering the shared key from the session ticket to establish a secure connection after verification; A client computation offloading module for delegating PQC computation tasks to a trusted proxy device.

5. The post-quantum federated learning system of claim 1, wherein, The hybrid encryption and layered security aggregation module comprises: A security policy manager for defining security levels and dynamically selecting security levels according to security policies and issuing them to corresponding clients, wherein the security policy includes data attributes, device capabilities or compliance requirements; A multi-mode encryption library that supports selecting encryption methods according to security levels; A hybrid aggregator for processing model updates of different security levels and implementing aggregation result fusion.

6. The post-quantum federated learning system of claim 5, wherein, The security levels at least include: Level one: transmission encryption based on PQC KEM and symmetric encryption; Level two: end-to-end encryption based on PQC homomorphic encryption or secure multi-party computation.

7. The post-quantum federated learning system of claim 6, wherein, When the hybrid aggregator is executing processing model updates of different security levels and implementing aggregation result fusion, it specifically executes: Broadcasting the security policy to all clients; Triggering each client to generate model updates encrypted by PQC KEM and attached with level one identification, and model updates encrypted by PQC homomorphic encryption and attached with level two identification according to the security policy respectively; Receiving all updated models, decrypting all model updates corresponding to level one and putting them into the plaintext buffer according to the identification, and putting all model updates corresponding to level two into the homomorphic ciphertext buffer; Performing average processing on all model updates in the plaintext buffer to obtain a first processing result; Performing encoding and conversion processing on the model updates in the homomorphic ciphertext buffer to obtain a second processing result; Fusing the first processing result and the second processing result through homomorphic operation to obtain the final global model update.

8. The post-quantum federated learning system of claim 1, wherein, The post-quantum secure authentication and proof server comprises: A third-party authentication authority for verifying client proof reports and issuing PQC signature decisions; A client proof generator for generating a proof report containing a PQC public key and an environment metric, the environment metric including a software environment metric hash value currently loaded and a hardware environment identifier; A verifier for initiating an authentication challenge and controlling the client to participate in a federated learning task according to the decision of the third-party authentication authority.

9. The post-quantum federated learning system of claim 8, wherein, When the verifier initiates an authentication challenge and controls the client to participate in a federated learning task according to the decision of the third-party authentication authority, it specifically performs: The verifier receives the decision of the third-party authentication authority; Use the PQC public key of the third-party authentication authority to verify the authenticity of the decision; If the verification is passed and it is declared that the client is trusted, bind the PQC public key of the client with its identity, and allow the client to participate in subsequent federated learning tasks; If the verification fails, the client is rejected and is listed in the blacklist.

10. A dynamic migration method, characterized by, The dynamic migration method is applied to the post-quantum federated learning system of any one of claims 1-9, and comprises the steps of: S1. Establishing a dual-stack communication connection between the client and the server, supporting dynamic negotiation of basic and post-quantum cryptographic suites; S2. According to the migration timeline, control the switching and forced upgrade of the cryptographic suite; S3. During the execution of the federated learning task, use batch signature verification processing, session reuse processing and client computation offloading processing to optimize PQC performance; S4. According to data sensitivity, device capability or compliance requirements, dynamically select the security level and perform hybrid encryption and layered security aggregation processing; S5. Post-quantum secure authentication of the client to ensure the integrity and authenticity of the client's hardware and software environments.

Images