A method and system for terminal capability hierarchical negotiation

Abstract

The present application relates to the field of communication technology and information security, in particular to a terminal capability layered negotiation method and system, aiming to solve the problems that the prior art cannot distinguish the upper limit of terminal hardware capability and the current actual available capability, the authentication and negotiation algorithm binding declaration, and lacks compliance version strategy pre-filtering. The present application constructs a three-layer model of hardware capability, current capability (including independent authentication and negotiation capability set), and compliance version, and the terminal filters the effective capability set according to the three-layer model and reports it to the server, and the server determines the algorithm combination mode based on the strategy. The implementation can finely describe the terminal capability, support independent evolution of authentication and negotiation capability, integrate compliance strategy filtering, and provide clear guidance when negotiation fails, and is suitable for various communication scenarios such as payment terminal remote key injection.

Description

Technical Field

[0001] This invention relates to the fields of communication technology and information security, specifically to a method and system for capability layering negotiation between a terminal and a server. It is particularly suitable for algorithm capability negotiation between a terminal and a key distribution host (KDH) in a remote key injection (RKI) scenario for payment terminals. It can also be widely applied to various communication systems that require fine description of terminal capabilities and implementation of policy-driven selection (such as TLS protocol extensions, IoT device authentication, etc.). Background Technology

[0002] In client-server communication systems, terminals typically need to declare their supported capabilities (such as encryption algorithms, protocol versions, and functionalities) to the server so that the server can select a combination of algorithms supported by both parties based on its security policy. For example, in a remote key injection (RKI) scenario for a payment terminal, the POS terminal needs to declare its supported authentication and key negotiation algorithms to the key distribution host (KDH), which then determines the algorithm suite for the current session.

[0003] In existing technologies, typical terminal capability negotiation schemes include: The PaxRhino solution from Baifu uses a single `supported_versions` parameter to select the entire algorithm suite (such as the RSA suite or ECC suite). The authentication algorithm and key negotiation algorithm are selected in tandem, preventing independent evolution. This solution only declares a version number, failing to distinguish between the terminal's hardware capability limits and its current usable capabilities.

[0004] The capability negotiation scheme in the TLS protocol involves the client declaring a list of supported cipher suites in the ClientHello message. Each suite specifies the authentication, key exchange, and encryption algorithms, and these suites are also bound together. Furthermore, the TLS protocol does not define a mechanism for pre-filtering capabilities on the endpoint based on local compliance policies.

[0005] General HTTP negotiation schemes typically declare capabilities using only version numbers or simple identifiers, lacking layered descriptions. Servers cannot determine fine-grained states such as "hardware not supported" or "certificate missing" of the terminal.

[0006] In client-server communication systems, terminals typically need to declare their supported capabilities (such as encryption algorithms, protocol versions, and functionalities) to the server so that the server can select a combination of algorithms supported by both parties based on its security policy. For example, in a remote key injection (RKI) scenario for a payment terminal, the POS terminal needs to declare its supported authentication and key negotiation algorithms to the key distribution host (KDH), which then determines the algorithm suite for the current session.

[0007] The existing technology has the following shortcomings: 1. Coarse-grained capability description: Existing solutions typically only declare a version number or a list of packages, failing to distinguish between the upper limit of the terminal's hardware capabilities and its currently available capabilities. For example, the terminal hardware may support post-quantum algorithms, but cannot use them due to the lack of the corresponding certificate. Existing solutions cannot express this difference, making it difficult for the server to determine whether the terminal's "hardware does not support it" or "certificate is missing," thus hindering the development of accurate migration strategies (such as prompting for device replacement or simply requiring a certificate upgrade).

[0008] 2. Coupling of Authentication and Negotiation Capabilities: The authentication algorithm and key negotiation algorithm are bound together in the same suite. This means that if a terminal wants to upgrade its key negotiation algorithm (e.g., by adding post-quantum key encapsulation), it must also possess the corresponding authentication credentials (e.g., post-quantum certificates), limiting the system's flexible evolution. This problem is particularly prominent in compliant environments where certificates are not replaceable (e.g., PCI secure room requirements).

[0009] 3. Lack of compliance version awareness: The terminal cannot declare the version of the security compliance standard it complies with (such as the PCI PTS version), and the server cannot filter the capability set according to the compliance policy, which may result in the selection of non-compliant algorithm combinations and cause compliance risks.

[0010] 4. Lack of terminal-side policy pre-filtering: The capability set reported by the terminal is often all the capabilities supported by the hardware. Without local policy filtering, it may contain algorithms that are not allowed to be used in the current compliant version, which increases the complexity of server decision-making and also exposes the details of the terminal's local policies.

[0011] 5. Inadequate negotiation failure handling mechanism: When a common algorithm cannot be negotiated, the existing solution usually only returns an error code, lacking clear instructions on the direction of terminal upgrade (whether hardware upgrade or certificate replacement is required).

[0012] Therefore, there is an urgent need for a capability negotiation method that can describe terminal capabilities in layers, support independent declarations of authentication and negotiation capabilities, integrate compliance policy filtering, and provide clear guidance on negotiation failures. Summary of the Invention

[0013] This invention provides a method and system for terminal capability layer negotiation, aiming to solve the technical problems of existing technologies that cannot distinguish between the upper limit of a terminal's hardware capabilities and its current actual available capabilities, the binding declaration of authentication algorithms and key negotiation algorithms, and the lack of pre-filtering of terminal-side policies based on compliant versions.

[0014] In a first aspect, the present invention provides a method for terminal capability layer negotiation, applied to a terminal, comprising: Obtain hardware capability information, current capability information, and compliance version identifier representing the terminal's three-layer capabilities. The current capability information includes an authentication capability set and a key negotiation capability set declared independently. The authentication capability set indicates the authentication algorithm for which the terminal currently holds authentication credentials, and the key negotiation capability set indicates the key negotiation algorithm that the terminal can currently execute without relying on authentication credentials. Based on the compliance version identifier, the embedded firmware policy table is queried, and the current capability information is filtered by policy to filter out invalid capability sets and obtain valid capability sets. Send a session initialization request to the server. The session initialization request includes the valid capability set and the compliance version identifier, but does not include the invalid capability set. Receive a session initialization response returned by the server, the session initialization response containing an algorithm combination mode determined by the server based on the effective capability set and the compliance version identifier.

[0015] Furthermore, the hardware capability information, current capability information, and compliance version identifier constitute a three-layer capability model: The first layer is hardware capability information, which indicates all algorithm capabilities supported by the terminal hardware and firmware. It represents the upper limit of capabilities, does not participate in algorithm negotiation and decision-making, and is used by the server to identify the migration readiness status of the terminal. The second layer is the current capability information, which reflects the actual capabilities available to the terminal in the current state and participates in algorithm negotiation and decision-making. The third layer is the compliance version identifier, which indicates the version of the security compliance standard that the terminal follows, and is used by the server to query the corresponding policy constraints.

[0016] Furthermore, the authentication capability set is equal to the intersection of the hardware authentication capability subset and the authentication algorithm set corresponding to the certificate held by the terminal; the key negotiation capability set is a subset of the hardware negotiation capability subset and is only constrained by hardware capabilities.

[0017] Furthermore, the effective capability set is the intersection of the current capability information and the set of allowed algorithms corresponding to the compliant version identifier in the firmware policy table.

[0018] Secondly, the present invention provides a method for terminal capability layered negotiation, applied to a server, comprising: The terminal receives a session initialization request, which includes a valid capability set and a compliance version identifier. The valid capability set is obtained by the terminal querying the embedded firmware policy table based on the compliance version identifier and filtering the current capability information according to the policy. The current capability information includes independently declared authentication capability set and key negotiation capability set. Based on the compliance version identifier, query the algorithm policy table to obtain the set of allowed authentication algorithms, the set of allowed key negotiation algorithms, and the preferred algorithm; The feasible authentication set is calculated as the intersection of the authentication capability set and the allowed authentication algorithm set; the feasible negotiation set is calculated as the intersection of the key negotiation capability set and the allowed key negotiation algorithm set. Valid combinations are selected from the cross-combinations of the feasible authentication set and the feasible negotiation set, and the algorithm combination mode is determined. Return a session initialization response to the terminal, the response containing the algorithm combination mode.

[0019] Furthermore, the combination corresponding to the preference algorithm is selected first; when the combination corresponding to the preference algorithm is not feasible, the combination with the highest security strength is selected.

[0020] Furthermore, when the feasible authentication set or the feasible negotiation set is empty, a negotiation failure response is returned to the terminal, the response containing an error code and minimum capability requirement information.

[0021] Thirdly, the present invention provides a terminal capability hierarchical negotiation system, including a terminal and a server; The terminal is used to: obtain hardware capability information, current capability information, and compliance version identifier representing the terminal's three-layer capabilities; query the embedded firmware policy table according to the compliance version identifier, perform policy filtering on the current capability information to obtain a valid capability set; and send a session initialization request containing the valid capability set and the compliance version identifier to the server. The server is configured to: receive the session initialization request, query the algorithm policy table according to the compliance version identifier, determine the algorithm combination mode from the set of valid capabilities, and return a session initialization response containing the algorithm combination mode to the terminal.

[0022] Furthermore, the hardware capability information, current capability information, and compliance version identifier constitute a three-layer capability model: The first layer is hardware capability information, which indicates all algorithm capabilities supported by the terminal hardware and firmware. It represents the upper limit of capabilities, does not participate in algorithm negotiation and decision-making, and is used by the server to identify the migration readiness status of the terminal. The second layer is the current capability information, which reflects the actual capabilities available to the terminal in the current state and participates in algorithm negotiation and decision-making. The third layer is the compliance version identifier, which indicates the version of the security compliance standard that the terminal follows, and is used by the server to query the corresponding policy constraints.

[0023] Furthermore, the server is also configured to: return a negotiation failure response containing minimum capability requirement information when the algorithm combination mode cannot be determined; the terminal is also configured to: determine whether equipment replacement or hardware upgrade is required based on the negotiation failure response and its own hardware capability information.

[0024] The present invention provides a technical solution that has at least the following technical effects: (1) In the current capability information, the authentication capability set and the key negotiation capability set are declared independently: the authentication capability set is constrained by authentication credentials (certificate / private key) and reflects the algorithm that the terminal can use to prove its identity; the key negotiation capability set is only constrained by hardware capabilities and does not depend on authentication credentials, reflecting the algorithm that the terminal can use to negotiate keys. This independent declaration realizes horizontal layering in the capability dimension (authentication capability vs. negotiation capability), laying the foundation for subsequent independent evolution. The terminal queries the embedded firmware policy table according to the compliance version identifier, filters the current capability information, and obtains the effective capability set. This process is essentially mapping the current capability (second layer) to the compliance constraints (third layer) and outputting the effective capability set that meets the compliance requirements (reporting layer). This mapping reflects the interaction and constraint relationship between different capability layers and is one of the core operations of "layered negotiation". The terminal only reports the filtered effective capability set and compliance version identifier. The server queries its own algorithm policy table based on this information to determine the algorithm combination mode. The terminal provides layered capability information, and the server matches and selects based on the policy, finally reaching an algorithm combination recognized by both parties. This process realizes cross-layer negotiation between the terminal and the server.

[0025] (2) Refined capability layer description: Through a three-layer model of hardware capabilities, current capabilities, and compliant versions, the server can accurately distinguish between the two states of "hardware supported but unusable due to missing certificate" and "hardware not supported". For example, if the server sees that the hardware capability includes ML-DSA but the current certification capability does not, it can determine that the terminal has PQC hardware but needs to be replaced to obtain a certificate, thereby formulating the correct migration strategy.

[0026] (3) Independent evolution of authentication and negotiation capabilities: The authentication capability set is constrained by the certificate (usually unchanged), while the key negotiation capability set is only constrained by the hardware (can be upgraded independently). This allows the terminal to upgrade the key negotiation algorithm without changing the certificate (e.g., by adding post-quantum key encapsulation), providing a capability negotiation basis for transitional schemes such as Hybrid 2. This is fundamentally different from the existing technology where authentication and negotiation are bound together.

[0027] (4) Terminal-side policy pre-filtering: The terminal pre-filters the capabilities according to the local firmware policy table to ensure that the reported capability set meets the compliant version requirements, reduce the server decision-making burden, and protect the privacy of the terminal's local policies (without reporting the complete firmware policy table).

[0028] (5) Server-side policy-driven decision-making: The server maintains an algorithm policy table according to the compliant version, supports the selection of preferred algorithms and security strength levels, and can achieve fine-grained policy control (e.g., forcing different algorithm combinations to be used for terminals with different PCI versions).

[0029] (6) Clear handling of negotiation failure: When negotiation fails, the server returns the minimum capability requirement, and the terminal can determine whether the equipment needs to be replaced or the hardware needs to be upgraded, providing quantitative guidance for operation and maintenance and reducing the cost of manual troubleshooting.

[0030] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0031] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0032] Figure 1 This is a structural block diagram of the terminal capability hierarchical negotiation system of the present invention; Figure 2 This is a flowchart of the terminal capability layered negotiation method of the present invention; Figure 3 This is a schematic diagram of the three-layer capability model structure of the present invention; Figure 4 This is a flowchart of the server strategy decision-making process of the present invention; Figure 5 This is a table showing the capabilities of the present invention under different terminal states. Detailed Implementation

[0033] The technical solution in this application embodiment has the following general idea: a three-layer capability model is constructed, consisting of hardware capability information, current capability information (including independently declared authentication capability set and key negotiation capability set), and compliance version identifier. The terminal queries the local firmware policy table according to the compliance version to pre-filter the current capabilities to obtain the effective capability set and reports it. The server then decides the optimal algorithm combination mode from the effective capability set according to its algorithm policy table, thereby realizing the fine-grained layered description of terminal capabilities, decoupling of authentication and negotiation capabilities, compliance-driven policy pre-filtering, and policy-based negotiation on the server side.

[0034] Before introducing specific embodiments, the system framework of the present invention will be introduced first. The system includes a terminal and a server.

[0035] like Figure 1 As shown, the terminal includes: Hardware capability reading module: Interacts with the security element or cryptographic module to read the list of supported authentication algorithms and key negotiation algorithms.

[0036] Certificate Management Module: Manages certificates stored on the terminal. Private keys are stored internally by the security element or cryptographic module and cannot be exported. Provides an interface to query the set of authentication algorithms corresponding to the currently held certificate.

[0037] Compliant version storage module: The compliant version identifier (such as "PTS_7.0") that the storage terminal follows is pre-installed with the firmware and its integrity is guaranteed by the firmware signing mechanism. It cannot be modified by the application layer.

[0038] Firmware policy table storage module: Stores local policy tables, mapping the allowed set of authentication algorithms and key negotiation algorithms according to compliant versions. The policy table is pre-installed with the firmware, its integrity is guaranteed by the firmware signing mechanism, and it is updated together during firmware upgrades.

[0039] Effective capability calculation module: Receives current capability information and compliance version identifier, queries firmware policy table, and calculates effective capability set (intersection).

[0040] Request sending module: Constructs a session initialization request, which includes a valid capability set, optional hardware capability information, and compliance version identifier, and sends it to the server.

[0041] Response processing module: Receives the session initialization response returned by the server, extracts the selected algorithm combination pattern, and provides it for use by subsequent communication modules.

[0042] The servers include: Request receiving module: Receives the terminal's session initialization request, and parses out the reported valid capability set, hardware capability information (if any), and compliance version identifier.

[0043] Policy table maintenance module: Maintains policy tables according to compliant versions, including the set of allowed authentication algorithms, the set of allowed key negotiation algorithms, preferred algorithms, security strength levels, etc. Policy tables can be dynamically configured by the administrator.

[0044] Decision-making module: Performs feasibility calculations and combination selections. Includes: Feasibility set calculation submodule: calculates the feasible authentication set and the feasible negotiation set.

[0045] Combination Filtering Submodule: Filters valid combinations based on combination validity rules (such as certain authentication algorithms cannot be paired with certain negotiation algorithms).

[0046] Optimal Selection Submodule: Selects the optimal combination based on preference algorithm or security strength.

[0047] Response sending module: Constructs a session initialization response, which includes the selected algorithm combination mode (or negotiation failure information), and returns it to the terminal.

[0048] like Figure 2As shown in the figure, this embodiment describes the capability layering negotiation process between the terminal and the server, including: S11: When the terminal is powered on or a connection is established, read hardware capability information (obtain the list of supported algorithms from the security chip or firmware configuration).

[0049] S12: The terminal checks the locally stored certificate / private key and calculates the authentication capability set; it extracts the key negotiation capability set from the hardware capabilities (usually taking all supported and available algorithms) to form the current capability information.

[0050] S13: The terminal reads the compliance version identifier (such as the PCI PTS version number, which is stored in the secure area) from the local storage.

[0051] S14: The terminal queries the embedded firmware policy table and obtains the set of allowed authentication algorithms and the set of allowed key negotiation algorithms based on the compliance version identifier. It then filters the current capability information to obtain the valid capability set.

[0052] S15: The terminal constructs a session initialization request (e.g., Command 46 in the RKI protocol), the message body of which contains: effective_authentication_set (set of effective authentication capabilities) effective_key_agreement_set (effective key agreement set) hardware_capabilities (optional, used for migration planning) compliance_version (compliance version identifier).

[0053] S16: The terminal sends a session initialization request to the server.

[0054] S21: The server receives the session initialization request and extracts the reported capability information.

[0055] S22: The server queries its algorithm policy table based on the compliance version identifier to obtain the set of allowed authentication algorithms, the set of allowed key negotiation algorithms, and the preferred algorithm for that version.

[0056] S23: The server calculates the feasible authentication set and the feasible negotiation set: Feasible authentication set = Reported authentication capability set ∩ Policy-permitted authentication set; Feasible negotiation set = Reported key negotiation capability set ∩ Policy-permitted negotiation set.

[0057] If neither is empty, then select valid combinations from the Cartesian product (e.g., exclude some unsafe combinations), and then select the optimal combination according to the preference algorithm or the safety strength.

[0058] S24: The server returns a session initialization response, which includes the selected choose_authentication and choose_key_agreement, as well as the session ID, etc.

[0059] S3: The terminal and the server use the selected algorithm combination for subsequent communication (such as two-way authentication, key injection, etc.). Example 1

[0060] This embodiment provides a method for terminal capability hierarchical negotiation, applied to terminals, such as... Figure 1 As shown, it includes: The process involves acquiring hardware capability information, current capability information, and compliance version identifier representing the terminal's three-layer capabilities. The current capability information includes independently declared authentication capability sets and key negotiation capability sets. The authentication capability set indicates the authentication algorithm for which the terminal currently holds authentication credentials, and the key negotiation capability set indicates the key negotiation algorithm currently executable by the terminal, independent of authentication credentials. This step, by acquiring capability information in a layered manner, allows the server to accurately distinguish the terminal's hardware support limits and current actual available capabilities, providing a precise basis for subsequent algorithm negotiation and migration planning. This enables independent evolution of authentication and negotiation capabilities, avoiding upgrade limitations caused by algorithm binding in traditional solutions. For example, the terminal can upgrade its key negotiation algorithm without changing its certificate.

[0061] The embedded firmware policy table is queried based on the compliance version identifier, and the current capability information is filtered by policy to remove invalid capability sets and obtain valid capability sets. This step reduces the decision-making burden of the server by filtering out algorithms that do not meet the requirements of the current compliance version in advance, while avoiding the exposure of complete local policy details on the terminal.

[0062] Send a session initialization request to the server. The session initialization request includes the valid capability set and the compliance version identifier, but does not include the invalid capability set. Receive a session initialization response returned by the server, the session initialization response containing an algorithm combination mode determined by the server based on the effective capability set and the compliance version identifier.

[0063] This embodiment systematically implements layered description and negotiation of terminal capabilities through features such as three-layer information acquisition, independent declaration of authentication / negotiation capabilities, policy filtering based on compliant versions, and reporting negotiation. Specifically, the independent declaration of authentication capability sets and key negotiation capability sets achieves horizontal layering along the capability dimension (authentication capability vs. negotiation capability), laying the foundation for subsequent independent evolution. The terminal queries the embedded firmware policy table based on the compliant version identifier to filter the current capability information and obtain the effective capability set. This process essentially maps the current capabilities to compliance constraints, outputting a valid capability set that meets compliance requirements (reporting layer). This mapping reflects the interaction and constraint relationships between different capability layers and is one of the core operations of "layered negotiation." The terminal only reports the filtered valid capability set and the compliant version identifier. The server queries its own policy table based on this information to determine the algorithm combination mode. This process realizes cross-layer negotiation between the terminal and the server: the terminal provides layered capability information, the server matches and selects based on policies, and finally reaches an algorithm combination agreed upon by both parties.

[0064] Furthermore, such as Figure 3 As shown, the hardware capability information, current capability information, and compliance version identifier constitute a three-layer capability model: The first layer is hardware capability information, which indicates all algorithm capabilities supported by the terminal hardware and firmware. It represents the upper limit of capabilities, does not participate in algorithm negotiation and decision-making, and is used by the server to identify the migration readiness status of the terminal. The second layer is the current capability information, which reflects the actual capabilities available to the terminal in the current state and participates in algorithm negotiation and decision-making. The third layer is the compliance version identifier, which indicates the version of the security compliance standard that the terminal follows, and is used by the server to query the corresponding policy constraints.

[0065] The authentication capability set is equal to the intersection of the hardware authentication capability subset and the authentication algorithm set corresponding to the certificate held by the terminal; the key negotiation capability set is a subset of the hardware negotiation capability subset and is only subject to hardware capability constraints.

[0066] The effective capability set is the intersection of the current capability information and the set of allowed algorithms corresponding to the compliant version identifier in the firmware policy table.

[0067] These three layers of information are independent and clearly defined, describing the three dimensions of "hardware upper limit", "actual availability" and "compliance constraints" respectively, forming a vertical hierarchical structure of capabilities.

[0068] like Figure 5 As shown, different terminals have different capabilities. Taking a PTS v7.0 certified POS terminal as an example, its hardware supports the following algorithms: Authentication algorithms: RSA-PSS, ECDSA, ML-DSA Key negotiation algorithms: RSA-OAEP, ECDH, ECDH+ML-KEM, ML-KEM This terminal was only injected with an ECC certificate (corresponding to the ECDSA authentication algorithm) at the factory, and not with an RSA certificate or an ML-DSA certificate. The terminal firmware policy table specifies that PTS v7.0 allows the use of ECDSA and ML-DSA as authentication algorithms, and ECDH, ECDH+ML-KEM, and ML-KEM as key negotiation algorithms. Therefore, the three-layer capability model is: First layer: Hardware capability information (read from hardware / firmware) text hardware_capabilities = { authentication: [RSA-PSS, ECDSA, ML-DSA], key_agreement: [RSA-OAEP, ECDH, ECDH+ML-KEM, ML-KEM] } Second layer: Current capability information (calculated based on certificate holdings) Authentication capability set = {hardware authentication capability} ∩ {algorithm corresponding to the certificate} = [ECDSA] (because only ECC certificate is available; RSA-PSS and ML-DSA do not have certificates); The key negotiation capability set is a subset of {hardware negotiation capabilities}, typically including all of them (but excluding algorithms requiring specific certificates). text current_capabilities = { authentication: [ECDSA], key_agreement: [RSA-OAEP, ECDH, ECDH+ML-KEM, ML-KEM] }

[0069] Third layer: Compliance version identifier text compliance_version = "PTS_7.0" Policy filtering: The terminal queries the firmware policy table. PTS_7.0 allows authentication algorithms [ECDSA, ML-DSA] and key negotiation algorithms [ECDH, ECDH+ML-KEM, ML-KEM]. Calculate the effective capability set (intersection): text effective_capabilities = { authentication: [ECDSA], / / ML-DSA is not in the current capability set key_agreement: [ECDH, ECDH+ML-KEM, ML-KEM] / / Keep all }

[0070] The terminal reports this set of valid capabilities. Upon receiving it, the server knows that the terminal can perform ECDSA authentication and supports ECDH, hybrid quantum, and pure quantum key negotiation. Simultaneously, if the server also receives hardware capability information (optionally reported), it can detect that the terminal hardware supports ML-DSA but currently lacks authentication capabilities, thus determining that the terminal is in a "hardware ready but certificate missing" state, providing a basis for subsequent migration planning. Example 2

[0071] Based on the same inventive concept, this invention provides a method for terminal capability layered negotiation, applied to servers, such as... Figure 1 As shown, it includes: The system receives a session initialization request from the receiving terminal. The request includes a valid capability set and a compliance version identifier. The valid capability set is obtained by the terminal querying the embedded firmware policy table based on the compliance version identifier and filtering the current capability information according to the policy. The current capability information includes independently declared authentication capability sets and key negotiation capability sets. By receiving the capability information reported by the receiving terminal in layers, the system provides a basis for making accurate algorithm combination decisions based on compliance policies, ensuring that the algorithm selection meets both security requirements and the actual capabilities of the terminal.

[0072] The algorithm policy table is queried based on the compliance version identifier to obtain the set of allowed authentication algorithms, the set of allowed key negotiation algorithms, and the preferred algorithm; thereby ensuring that the algorithm selection strictly follows the security standards of the current compliance version, while the preferred algorithm configuration supports differentiated security policies, balancing security and flexibility.

[0073] The feasible authentication set is calculated as the intersection of the authentication capability set and the allowed authentication algorithm set, and the feasible negotiation set is calculated as the intersection of the key negotiation capability set and the allowed key negotiation algorithm set.

[0074] Valid combinations are selected from the intersection of the feasible authentication set and the feasible negotiation set, and the algorithm combination mode is determined. By selecting the optimal algorithm combination, communication security is ensured while negotiation efficiency and compatibility are improved as much as possible, avoiding negotiation failures due to algorithm mismatch.

[0075] Return a session initialization response to the terminal, the response containing the algorithm combination mode.

[0076] Furthermore, the combination corresponding to the preference algorithm is preferentially selected; when the combination corresponding to the preference algorithm is not feasible, the combination with the highest security strength is selected. When the feasible authentication set or the feasible negotiation set is empty, a negotiation failure response is returned to the terminal, the response containing an error code and minimum capability requirement information.

[0077] Reference Figure 4 As shown, Figure 4 Describe the server's policy decision-making process in detail, and provide output examples under different inputs.

[0078] The strategic decision-making process is as follows: (1) Query strategy table: allowed_authentication=["ECDSA", "ML-DSA"], allowedkey_agreement=["ECDH+ML-KEM", "ML-KEM"], preferred="ECDH+ML-KEM"; (2) Calculate the feasible set: feasible_auth = ["ECDSA"] ∩ ["ECDSA", "ML-DSA"] = ["ECDSA"]; feasible_ka = ["ECDH", "ECDH+ML-KEM", "ML-KEM"] ∩ ["ECDH+ML-KEM", "ML-KEM"] = ["ECDH+ML-KEM", "ML-KEM"]; (3) Valid combination: According to the combination validity rules, the certified ECDSA can be combined with the negotiated ECDH+ML-KEM, and the valid combination is (ECDSA, ECDH+ML-KEM); (4) Optimal combination selection: The combination ECDH+ML-KEM is feasible and should be selected directly; (5) Decision results: chosen_authentication="1"(ECDSA), chosen_key_agreement="2"(ECDH+ML-KEM).

[0079] Example A: Normal negotiation Terminal reports: authentication=[ECDSA], key_agreement=[ECDH, ECDH+ML-KEM,ML-KEM], compliance_version="PTS_7.0"; Server policy (PTS_7.0): allowed_auth=[ECDSA, ML-DSA], allowed_ka=[ECDH+ML-KEM, ML-KEM], preferred="ECDH+ML-KEM"; Calculation: feasible_auth=[ECDSA], feasible_ka=[ECDH+ML-KEM, ML-KEM]; Effective combinations: (ECDSA, ECDH+ML-KEM) and (ECDSA, ML-KEM); Preference matching: (ECDSA, ECDH+ML-KEM) → Selected; Response: chosen_auth=ECDSA, chosen_ka=ECDH+ML-KEM.

[0080] Example B: Preference algorithm is not feasible Terminal reports: authentication=[ML-DSA], key_agreement=[ML-KEM], compliance_version="PTS_7.0"; Server policy: allowed_auth=[ECDSA, ML-DSA], allowed_ka=[ECDH+ML-KEM, ML-KEM], preferred="ECDH+ML-KEM"; Calculation: feasible_auth=[ML-DSA], feasible_ka=[ML-KEM]; Effective combinations: (ML-DSA, ML-KEM); The preference (ECDH+ML-KEM) is not feasible. Select the combination with the highest safety strength (ML-KEM strength ≥ ECDH+ML-KEM) → Select (ML-DSA, ML-KEM).

[0081] Example C: Negotiation failed Terminal reports: authentication=[ECDSA], key_agreement=[ECDH], compliance_version="PTS_7.0"; Server policy: allowed_auth=[ML-DSA], allowed_ka=[ML-KEM] (assuming the policy mandates PQC); Calculate: feasible_auth=[], feasible_ka=[]; Return negotiation failure response: json { "error_code": "CAPABILITY_MISMATCH", "minimum_required": { "authentication": ["ML-DSA"], "key_agreement": ["ML-KEM"] } } Upon receiving the certificate, the terminal checks its own hardware capabilities: if the hardware supports ML-DSA and ML-KEM but the current authentication capability set does not include ML-DSA, it determines that the device needs to be replaced to obtain the ML-DSA certificate; if the hardware does not support it, it determines that the device needs to be replaced.

[0082] The derivation of capabilities under the non-replaceable certificate constraint illustrates how this invention adapts to the compliance requirements of the non-replaceable PCI safe room certificate and demonstrates the advantages of independent declaration: According to PCI PIN Annex A2 Level 3, endpoint certificates are not replaceable once issued in a secure room. Therefore, even if a deployed endpoint's hardware supports the post-quantum signature algorithm (ML-DSA), it cannot obtain the corresponding certificate and cannot perform PQC authentication.

[0083] In the three-layer capability model of this invention: The hardware capability information still includes ML-DSA, which allows the server to identify the terminal's "hardware ready, but certificate missing" status. The server can then use this information to plan a batch device replacement strategy.

[0084] The current capability set does not include ML-DSA because the terminal does not hold the corresponding certificate.

[0085] The key negotiation capability set is independent of authentication credentials, so it can still include post-quantum key negotiation algorithms such as ML-KEM.

[0086] This enables flexible evolution: terminals can obtain HNDL protection by using hybrid key negotiation (ECDH+ML-KEM) or pure post-quantum key negotiation (ML-KEM) without changing certificates (authentication capabilities remain unchanged). This is the foundation of the Hybrid 2 transition solution. Servers can choose a hybrid mode based on the reported authentication capability set (without ML-DSA) and key negotiation capability set (with ML-KEM), satisfying post-quantum security requirements while remaining compatible with the existing certificate system.

[0087] Since the method described in Embodiment 2 of the present invention operates on a different subject than the method in Embodiment 1 of the present invention, but the information they interact with is the same, detailed information not described in Embodiment 2 of the present invention can be referred to in Embodiment 1, and the combination of the two can constitute a complete negotiation process, as can be seen in Embodiment 3.

[0088] Example 2 is the server-side implementation of Example 1. Both achieve complete capability negotiation between the terminal and the server through the same layered capability model and negotiation process. Example 3

[0089] Based on the same inventive concept, this invention provides a terminal capability hierarchical negotiation system, such as... Figure 1 As shown, it includes terminals and servers; The terminal is used to: obtain hardware capability information, current capability information, and compliance version identifier representing the terminal's three-layer capabilities; query the embedded firmware policy table according to the compliance version identifier, perform policy filtering on the current capability information to obtain a valid capability set; and send a session initialization request containing the valid capability set and the compliance version identifier to the server. The server is configured to: receive the session initialization request, query the algorithm policy table according to the compliance version identifier, determine the algorithm combination mode from the set of valid capabilities, and return a session initialization response containing the algorithm combination mode to the terminal.

[0090] Furthermore, such as Figure 2 As shown, the hardware capability information, current capability information, and compliance version identifier constitute a three-layer capability model: The first layer is hardware capability information, which indicates all algorithm capabilities supported by the terminal hardware and firmware. It represents the upper limit of capabilities, does not participate in algorithm negotiation and decision-making, and is used by the server to identify the migration readiness status of the terminal. The second layer is the current capability information, which reflects the actual capabilities available to the terminal in the current state and participates in algorithm negotiation and decision-making. The third layer is the compliance version identifier, which indicates the version of the security compliance standard that the terminal follows, and is used by the server to query the corresponding policy constraints.

[0091] Furthermore, the server is also configured to: return a negotiation failure response containing minimum capability requirement information when the algorithm combination mode cannot be determined; the terminal is also configured to: determine whether equipment replacement or hardware upgrade is required based on the negotiation failure response and its own hardware capability information.

[0092] Example 3 is a system-level integration of the terminal method in Example 1 and the server method in Example 2, realizing a complete capability layer negotiation process through the interaction between the terminal and the server.

[0093] While specific embodiments of the present invention have been described above, those skilled in the art should understand that the specific embodiments described are merely illustrative and not intended to limit the scope of the present invention. Equivalent modifications and variations made by those skilled in the art in accordance with the spirit of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A method for terminal capability hierarchical negotiation, applied to a terminal, the method comprising: include: Obtain hardware capability information, current capability information, and compliance version identifier representing the terminal's three-layer capabilities. The current capability information includes an authentication capability set and a key negotiation capability set declared independently. The authentication capability set indicates the authentication algorithm for which the terminal currently holds authentication credentials, and the key negotiation capability set indicates the key negotiation algorithm that the terminal can currently execute without relying on authentication credentials. Based on the compliance version identifier, the embedded firmware policy table is queried, and the current capability information is filtered by policy to filter out invalid capability sets and obtain valid capability sets. Send a session initialization request to the server. The session initialization request includes the valid capability set and the compliance version identifier, but does not include the invalid capability set. Receive a session initialization response returned by the server, the session initialization response containing an algorithm combination mode determined by the server based on the effective capability set and the compliance version identifier.

2. The method of claim 1, wherein: The hardware capability information, current capability information, and compliance version identifier constitute a three-layer capability model: The first layer is hardware capability information, which indicates all algorithm capabilities supported by the terminal hardware and firmware. It represents the upper limit of capabilities, does not participate in algorithm negotiation and decision-making, and is used by the server to identify the migration readiness status of the terminal. The second layer is the current capability information, which reflects the actual capabilities available to the terminal in the current state and participates in algorithm negotiation and decision-making. The third layer is the compliance version identifier, which indicates the version of the security compliance standard that the terminal follows, and is used by the server to query the corresponding policy constraints.

3. The method of claim 1, wherein: The authentication capability set is equal to the intersection of the hardware authentication capability subset and the authentication algorithm set corresponding to the certificate held by the terminal; The key negotiation capability set is a subset of the hardware negotiation capability subset and is only subject to hardware capability constraints.

4. The method of claim 3, wherein: The effective capability set is the intersection of the current capability information and the set of allowed algorithms corresponding to the compliant version identifier in the firmware policy table.

5. A terminal capability hierarchical negotiation method, applied to a server, characterized in that, include: The terminal receives a session initialization request, which includes a valid capability set and a compliance version identifier. The valid capability set is obtained by the terminal querying the embedded firmware policy table based on the compliance version identifier and filtering the current capability information according to the policy. The current capability information includes independently declared authentication capability set and key negotiation capability set. Based on the compliance version identifier, query the algorithm policy table to obtain the set of allowed authentication algorithms, the set of allowed key negotiation algorithms, and the preferred algorithm; The feasible authentication set is calculated as the intersection of the authentication capability set and the allowed authentication algorithm set; the feasible negotiation set is calculated as the intersection of the key negotiation capability set and the allowed key negotiation algorithm set. Valid combinations are selected from the cross-combinations of the feasible authentication set and the feasible negotiation set, and the algorithm combination mode is determined. Return a session initialization response to the terminal, the response containing the algorithm combination mode.

6. The method according to claim 5, characterized in that, The method for determining the algorithm combination includes: prioritizing the combination corresponding to the preference algorithm; and when the combination corresponding to the preference algorithm is not feasible, selecting the combination with the highest security strength.

7. The method according to claim 5, characterized in that, When the feasible authentication set or the feasible negotiation set is empty, a negotiation failure response is returned to the terminal, the response containing an error code and minimum capability requirement information.

8. A terminal capability hierarchical negotiation system, characterized in that, Includes terminals and servers; The terminal is used to: obtain hardware capability information, current capability information, and compliance version identifier representing the terminal's three-layer capabilities; query the embedded firmware policy table according to the compliance version identifier, perform policy filtering on the current capability information to obtain a valid capability set; and send a session initialization request containing the valid capability set and the compliance version identifier to the server. The server is configured to: receive the session initialization request, query the algorithm policy table according to the compliance version identifier, determine the algorithm combination mode from the set of valid capabilities, and return a session initialization response containing the algorithm combination mode to the terminal.

9. The system according to claim 8, characterized in that, The hardware capability information, current capability information, and compliance version identifier constitute a three-layer capability model: The first layer is hardware capability information, which indicates all algorithm capabilities supported by the terminal hardware and firmware. It represents the upper limit of capabilities, does not participate in algorithm negotiation and decision-making, and is used by the server to identify the migration readiness status of the terminal. The second layer is the current capability information, which reflects the actual capabilities available to the terminal in the current state and participates in algorithm negotiation and decision-making. The third layer is the compliance version identifier, which indicates the version of the security compliance standard that the terminal follows, and is used by the server to query the corresponding policy constraints.

10. The system according to claim 8, characterized in that, The server is also configured to: return a negotiation failure response containing minimum capability requirement information when the algorithm combination mode cannot be determined; the terminal is also configured to: determine whether equipment replacement or hardware upgrade is required based on the negotiation failure response and its own hardware capability information.

Images