KDH binding verification method and device

Abstract

The application discloses a KDH binding verification method and device, and relates to the technical field of information security. The technical defects that the traditional certificate verification scheme does not explicitly distinguish between the CA certificate binding and the entity identity issuing constraint are solved. The method comprises the following steps: a terminal acquires an intermediate CA certificate of a KDH, binds the intermediate CA certificate as a legal KDH issuing CA after verifying the legality of the intermediate CA certificate by using a preset root certificate, and forms an issuer constraint with an unchangeable life cycle; in subsequent communication, the terminal only accepts entity certificates issued by the binding CA, and realizes KDH identity authentication by verifying the issuer field matching and the digital signature validity of the entity certificate. The application solidifies the binding relationship of the terminal-intermediate CA certificate, shrinks the trust boundary from the general CA certificate chain to a specific issuer constraint, effectively prevents illegal KDH entity impersonation attacks, and is especially suitable for payment terminals and other scenarios with extremely high requirements for identity authentication security.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and in particular to a method and apparatus for binding and verifying a key distribution host (KDH) in a remote key injection (RKI) scenario for payment terminals, especially applicable to payment terminal devices that comply with PCI PTS and PCIPIN Security requirements. Background Technology

[0002] In the payment industry, POS terminals need to securely obtain encryption keys (such as MK / SK MK, DUKPT IPEK, etc.) from a Key Distribution Host (KDH). This process is called Remote Key Injection (RKI). During RKI, the terminal must establish secure communication with a legitimate KDH to prevent being hijacked to a malicious KDH and thus causing key leakage.

[0003] In existing technologies, terminals typically verify the identity of the peer by checking the certificate chain provided by the KDH. Typical practices include: The terminal is pre-installed with an OEM root certificate (root certificate) to verify the legitimacy of the KDH certificate chain; The terminal verifies whether the KDH certificate was issued by a trusted CA, whether it is within its validity period, and whether it has been revoked.

[0004] However, the existing solutions have the following shortcomings: 1) Lack of distinction between CA certificate binding and entity identity issuance constraints: In existing related technologies, devices typically verify the identity of the communication peer by verifying the certificate chain. However, traditional solutions often fail to clearly distinguish between "CA certificate binding" and "entity identity issuance constraints," leading devices to potentially only verify the existence of the CA during the binding phase (e.g., checking whether the CA certificate was issued by the root certificate and whether it is valid), without strictly limiting subsequent communication to KDH entities with a specific issuance relationship. In other words, as long as the CA certificate is valid, the terminal accepts any KDH certificate issued by that CA, failing to limit trust to a specific issuing CA.

[0005] 2) Unable to prevent cross-CA spoofing attacks: Attackers can use certificates issued by other legitimate CAs (such as different intermediate CAs under an industry public root CA) to spoof KDH, and the terminal cannot distinguish them, creating a security vulnerability. For example, if an attacker obtains another intermediate CA certificate issued by the same root CA, they can use that CA to issue a fake entity certificate. Since the certificate chain is also legitimate, the terminal will mistakenly accept it.

[0006] 3) Certificate replacement constraints are not reflected: According to the PCI PIN Annex A2 Level 3 security room requirements, terminal certificates cannot be replaced during the device's lifecycle. Similarly, the terminal's trust anchor to the KDH should also be subject to strict access protection, meaning it should not be tampered with by the application layer or external interfaces, and can only be updated through sensitive service functions that require authentication only. However, existing technologies do not provide a method for persistently binding the KDH's issuing CA to the terminal while ensuring access protection.

[0007] 4) Not applicable to compliance migration scenarios: During the PQC migration process, the terminal may need to rely on a specific KDH CA for a long time. Existing solutions cannot guarantee the persistence of this binding relationship and the protection against unauthorized modifications.

[0008] Therefore, there is an urgent need for a KDH binding verification method that can strongly bind the KDH issuing CA to the terminal, and the binding relationship cannot be tampered with by the application layer and external interfaces, and can only be updated or reset through certified sensitive service functions. Summary of the Invention

[0009] This invention provides a KDH binding verification method and apparatus, aiming to solve the following technical problems: how to limit the terminal's trust in a KDH to only trusting KDH entities issued by a specific issuing CA, rather than any legitimate CA-issued KDH; how to establish a persistent binding relationship between the terminal and the KDH issuing CA while meeting PCI compliance constraints, and how to ensure that the binding relationship is not directly accessible to the application layer and external interfaces, but can only be updated or reset through certified sensitive service functions; how to prevent attackers from using certificates issued by different CAs to launch KDH spoofing attacks; and how to clearly distinguish between "CA certificate legitimacy verification" and "issuer constraint binding," overcoming the ambiguous practice in the prior art of "verifying the existence of the CA as binding."

[0010] In a first aspect, the present invention provides a KDH binding verification method applied to a terminal, comprising the following steps: S1. Obtain the intermediate CA certificate for KDH; S2. Verify the legality of the digital signature and certificate chain of the intermediate CA certificate using the root certificate pre-installed on the terminal; S3. After successful verification, the intermediate CA certificate is bound to a valid KDH issuing CA, forming an issuer constraint, that is, only entity certificates issued by this intermediate CA certificate are accepted. S4. Obtain the entity certificate of KDH during subsequent communication; S5. Verify whether the entity certificate was issued by the bound intermediate CA certificate; S6. If yes, then accept the KDH access; otherwise, reject the KDH access.

[0011] Furthermore, the issuer constraint cannot be modified at the application layer or external interfaces, and can only be updated or reset through certified sensitive service functions, and access to the sensitive functions requires authentication.

[0012] Furthermore, in step S5, verifying whether the entity certificate was issued by the bound intermediate CA certificate specifically includes: Check if the issuer field of the entity certificate matches the subject of the intermediate CA certificate; Verify the digital signature of the entity certificate using the public key of the intermediate CA certificate.

[0013] Furthermore, S5 also includes: When any content verification fails, the terminal logs the security event and terminates the session.

[0014] Furthermore, the binding of the intermediate CA certificate to a legitimate KDH issuing CA specifically refers to: storing the binding relationship between the terminal and the intermediate CA certificate in a secure storage area, which is not directly accessible to the application layer or external interfaces; establishing an unchangeable issuer constraint through the binding relationship, so that only entity certificates issued by the intermediate CA certificate are subsequently accepted.

[0015] Furthermore, the root certificate is pre-installed when the terminal leaves the factory.

[0016] Secondly, the present invention provides a KDH binding verification device, comprising: The first certificate acquisition module is used to acquire the intermediate CA certificate of KDH; The first verification module uses the root certificate pre-installed on the terminal to verify the legality of the digital signature and certificate chain of the intermediate CA certificate; The issuer constraint module is used to bind the intermediate CA certificate to a valid KDH issuing CA after the first verification module passes the verification, thus forming an issuer constraint, that is, only entity certificates issued by this intermediate CA certificate are accepted. The second certificate acquisition module is used to obtain the entity certificate of KDH during subsequent communication with KDH; The second verification module is used to verify whether the entity certificate is issued by the bound intermediate CA certificate; The session control module is used to determine whether to accept the KDH and continue communication based on the verification results of the first verification module and the second verification module. If the verification fails, the session is terminated.

[0017] Furthermore, the issuer constraint module is a secure storage area, which cannot be directly accessed by the application layer or external interfaces; the issuer constraint cannot be modified through the application layer or external interfaces, but can only be updated or reset through certified sensitive service functions, and access to the sensitive service functions requires secure message authentication.

[0018] Furthermore, the content verified by the second verification module includes: Check if the issuer field of the entity certificate matches the subject of the intermediate CA certificate; Verify the digital signature of the entity certificate using the public key of the intermediate CA certificate.

[0019] The present invention has the following technical effects: (1) Strong binding relationship: The terminal's trust in KDH is precisely limited to "only trusting KDHs issued by a specific intermediate CA certificate", rather than KDHs issued by any legitimate CA, which significantly improves the ability to resist spoofing attacks.

[0020] (2) Complies with PCI compliance requirements: The binding relationship is stored in a secure storage area and cannot be directly accessed by the application layer or external interfaces. It can only be updated or reset through certified sensitive service functions, which complies with the PCI security requirement that sensitive functions must be certified before they can be accessed. At the same time, it avoids the security risks caused by unauthorized modification of the trust anchor.

[0021] (3) Prevent cross-CA attacks: Even if an attacker obtains a KDH certificate issued by another legitimate CA, it will not be able to pass the terminal's verification because the terminal only accepts certificates issued by the bound intermediate CA certificate.

[0022] (4) Achieve simplicity and efficiency: No need to modify the PKI infrastructure, only need to add a binding operation and subsequent issuer verification on the terminal side, with minimal changes to the existing RKI protocol.

[0023] (5) Applicable to long-term deployment: In long-term scenarios such as PQC migration, the relationship between the terminal and the KDH-issued CA is protected by access, ensuring that the trust anchor is not tampered with without authorization during deployment. When it is necessary to replace the KDH CA, it can be updated through certified sensitive service functions.

[0024] 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

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

[0026] Figure 1 This is a flowchart of the KDH binding verification method of the present invention; Figure 2 This is a timing diagram of the interaction between KDH binding verification and the RKI protocol in this invention. Figure 3 This is a structural block diagram of the KDH binding verification device of the present invention. Detailed Implementation

[0027] Existing technologies fail to address the following technical issues: When verifying a KDH certificate chain, the terminal only checks the existence of the CA (i.e., whether the CA certificate was issued by the root certificate and whether it is within its validity period), but cannot strictly limit subsequent communication to come from a KDH entity with a specific issuing relationship. This allows attackers to impersonate KDHs by using certificates issued by other legitimate CAs (including different intermediate CAs under the same root certificate), and the terminal cannot distinguish between them.

[0028] In response to this, the technical solution in this application embodiment is as follows: Addressing the problem in existing technologies where the terminal only verifies the existence of the certificate chain but cannot restrict the KDH to be issued by a specific issuer, this application clearly distinguishes between the two stages of "CA certificate legitimacy verification" and "issuer constraint binding." After verifying the legitimacy of the intermediate CA certificate, it binds it as the terminal's sole issuer constraint. This binding relationship is stored in a secure storage area and cannot be directly accessed by the application layer or external interfaces. It can only be updated or reset through certified sensitive service functions. This ensures that the terminal subsequently only accepts KDH entity certificates issued by this intermediate CA, thereby precisely narrowing the trust from "any legitimate CA" to "the sole issuer," fundamentally preventing cross-CA spoofing attacks and meeting the long-term security requirement of protected trust anchors in a PCI compliant environment.

[0029] The embodiments of this application have the following characteristics: It clearly distinguishes between "CA certificate legitimacy verification" and "issuer constraint binding" in terms of concepts, overcoming the fundamental defect of conflating the two in existing technologies; By narrowing the trust anchor from "any legitimate CA" to "the uniquely bound issuing CA," even if an attacker holds other legitimate intermediate CA certificates issued by the same root CA, they will be unable to pass verification; The binding relationship protects access to the application layer and external interfaces, and the mechanism of allowing only certified sensitive service functions to be updated or reset complies with PCI's security requirements that sensitive services must be certified before access, providing the payment industry with a technical solution that meets regulatory requirements. Example

[0030] like Figure 1 As shown, this embodiment provides a KDH binding verification method applied to a terminal, including the following steps: S1. Obtain the KDH intermediate CA certificate During the initial communication or initialization process with KDH, the terminal obtains the intermediate CA certificate of KDH.

[0031] S2. Verify the legality of the intermediate CA certificate's digital signature and certificate chain using the root certificate pre-installed on the terminal. The terminal uses a pre-installed root certificate (i.e., the OEM root certificate) to verify the digital signature of the intermediate CA certificate and check the integrity and validity of the certificate chain. The root certificate is pre-installed on the terminal at the factory.

[0032] S3. After successful verification, bind the intermediate CA certificate to a valid KDH-issued CA to form an issuer constraint. This issuer constraint restricts the terminal to accepting only entity certificates issued by this intermediate CA certificate. The binding essentially establishes an "issuer constraint relationship"—the terminal stores this intermediate CA certificate in a secure storage area as the sole KDH issuance trust anchor. This trust anchor cannot be directly accessed by the application layer or external interfaces; it can only be updated or reset through certified sensitive service functions.

[0033] S4. Obtain the KDH entity certificate during subsequent communication with KDH. Each time a subsequent RKI session is established, the terminal receives the entity certificate (i.e., the entity certificate) provided by KDH.

[0034] S5. Verify whether the entity certificate was issued by the bound intermediate CA certificate. Specifically, this includes: checking whether the issuer field of the entity certificate matches the subject of the intermediate CA certificate; and verifying the digital signature of the entity certificate using the public key of the intermediate CA certificate. If any verification fails, the terminal logs the security event and terminates the session.

[0035] S6. If yes, then accept the KDH access; otherwise, reject the KDH access. The terminal accepts the KDH only if the entity certificate is issued by the bound intermediate CA certificate; otherwise, it rejects it.

[0036] This embodiment effectively prevents unauthorized KDH devices from accessing the terminal through certificate chain verification and issuer constraint mechanisms, avoiding the risks of unauthorized access and data leakage, and improving communication security. After the initial binding, subsequent communication only needs to verify whether the entity certificate was issued by the bound intermediate CA, eliminating the need for repeated full certificate chain verification, significantly improving communication establishment efficiency and simplifying the verification process. When verification fails, the terminal automatically records the security event and terminates the session, promptly blocking potential attacks and improving the overall stability and anti-attack capability of the system, thereby enhancing system reliability. The pre-configured root certificate and bound intermediate CA model reduces the complexity of certificate management, facilitates unified updates and maintenance, and lowers long-term operation and maintenance costs.

[0037] Furthermore, the issuer constraint cannot be modified at the application layer or through external interfaces; it can only be updated or reset through authenticated sensitive service functions, which require authentication for access. Specifically, the binding relationship between the terminal and the intermediate CA certificate is stored in a secure storage area, which is not directly accessible to the application layer or external interfaces. This binding relationship establishes an issuer constraint, ensuring that only entity certificates issued by this intermediate CA certificate are accepted subsequently.

[0038] This invention explicitly proposes the core legal and technical concept of "issuer constraint," and clearly distinguishes "CA certificate legitimacy verification" from "issuer constraint binding" as two operations with different legal meanings and technical implementations, which goes beyond the conventional certificate chain verification logic. In the RKI scenario, a two-level verification architecture is constructed. By fixing the issuing CA of the KDH, the terminal's trust anchor for the KDH is moved down from the root certificate level and fixed at the intermediate CA level. This design breaks through the existing conventional thinking of "strengthening certificate chain verification or introducing additional certificates."

[0039] The establishment of the issuer constraint occurs during the device initialization phase and is decoupled from the RKI protocol process. Specifically, during the device initialization phase: the terminal obtains the KDH intermediate CA certificate (intermediate CA certificate) through an authenticated sensitive service function, or writes the intermediate CA certificate to the local configuration interface in a controlled physical environment. Before writing, the local configuration interface determines whether the intermediate CA certificate already exists in the secure storage area; if it does, the writing is rejected. After verifying the legitimacy of the intermediate CA certificate using a preset root certificate, the terminal stores the intermediate CA certificate in the secure storage area as the issuer constraint. This binding relationship cannot be directly accessed by the application layer or external interfaces; it can only be updated or reset through the authenticated sensitive service function.

[0040] like Figure 2 As shown, the complete interaction process in the RKI protocol, and the KDH binding verification interaction sequence in this embodiment of the invention, are as follows: The terminal sends a session initialization request (Command 46) to the KDH, which may include terminal capability information.

[0041] KDH returns a session initialization response, along with H_CERT.

[0042] The terminal verifies whether H_CERT was issued by the bound intermediate CA certificate (checking whether the issuer field matches the subject of the intermediate CA certificate, and verifying the digital signature using the public key of the intermediate CA certificate).

[0043] After successful verification, the terminal and KDH continue with subsequent steps such as two-way authentication and key injection.

[0044] If verification fails, the terminal returns an error code (e.g., "KDH binding verification failed") and terminates the session.

[0045] Through the above process, the terminal ensures that it only communicates with KDHs authorized by a specific issuing CA, effectively preventing KDH spoofing attacks.

[0046] Examples illustrating the differences between existing methods and the implementation method of this invention: The typical approach in existing solutions is as follows: the terminal uses the OEM root certificate to verify the signature of the intermediate CA certificate. If the signature passes verification, the intermediate CA certificate is considered trustworthy, and the terminal then verifies that the entity certificate was issued by that intermediate CA certificate. However, in actual deployments, terminals often accept any legitimate intermediate CA certificate during the initial communication and store it as a "trusted CA." Subsequent checks only verify whether the entity certificate was issued by this stored CA. This stored CA is not bound to a specific issuing relationship—if an attacker can provide another intermediate CA certificate also issued by the OEM root certificate (e.g., a legitimate CA certificate obtained through other channels), the terminal will also accept and bind it, leading to the subsequent acceptance of counterfeit entity certificates issued by the original intermediate CA certificate.

[0047] The improved method of this invention: This invention strictly distinguishes between "CA certificate validity verification" and "issuer constraint binding". After verifying the validity of the intermediate CA certificate, the terminal not only stores the certificate but also uses it as the sole issuer constraint. This constraint is stored in a secure storage area and cannot be directly accessed by the application layer or external interfaces. It can only be updated or reset through authentication-only sensitive service functions. Any subsequent KDH must provide an entity certificate issued by this specific intermediate CA certificate. Even if an attacker can provide another valid intermediate CA certificate (also issued by the OEM root certificate), it will not be accepted because the terminal is already bound to the unique issuing CA. This design precisely narrows trust from the "CA set" to the "single issuer," achieving a protected binding relationship.

[0048] Attack scenario verification: If an attacker sets up a fake KDH and holds a certificate issued by another legitimate CA (an intermediate CA certificate not authorized by the OEM, but also issued by the OEM root certificate).

[0049] Existing technical methods: The terminal only verifies the existence of the certificate chain and may accept the fake KDH.

[0050] An improved method in this embodiment of the invention: The terminal is already bound to a specific intermediate CA certificate. The issuer of the entity certificate provided by the fake KDH is not the bound intermediate CA certificate, so the verification fails and the terminal refuses to connect. Example

[0051] Based on the same inventive concept, this application also provides an apparatus corresponding to the method in Embodiment 1, as detailed in Embodiment 2.

[0052] like Figure 3 As shown, this embodiment provides a KDH binding verification device applied to a terminal, including: The first certificate acquisition module is responsible for acquiring the intermediate CA certificate of KDH. During the device initialization phase, this module acquires certificate data through certified sensitive service functions, or receives and writes certificate data through a local configuration interface in a controlled physical environment. Before writing, the local configuration interface determines whether an intermediate CA certificate already exists in the secure storage area. If it does, the writing is rejected.

[0053] The first verification module uses the terminal's pre-installed root certificate (OEM_ROOT_CERT) to verify the digital signature of the intermediate CA certificate and the legality of the certificate chain; this module has an embedded certificate chain verification engine that supports the X.509 standard certificate format.

[0054] Issuer constraint module: After the first verification module passes the verification, the intermediate CA certificate is bound to a valid KDH issuing CA to form an issuer constraint, that is, only entity certificates issued by this intermediate CA certificate are accepted.

[0055] The second certificate acquisition module is used to obtain the entity certificate of KDH during subsequent communication with KDH.

[0056] The second verification module is used to verify whether the entity certificate was issued by the bound intermediate CA certificate.

[0057] Session control module: Used to determine whether to accept the KDH and continue communication based on the verification results of the first verification module and the second verification module. If the verification fails, the session is terminated.

[0058] In practice, the secure storage area of ​​the issuer constraint module is located in the terminal's secure chip or secure element, and direct access from the application layer and external interfaces is restricted through hardware access control mechanisms. Updates and resets of issuer constraints require authenticated sensitive service functions before execution. During initial deployment, intermediate CA certificates can be written via a local configuration interface in a controlled physical environment. Before writing, it is determined whether the intermediate CA certificate already exists in the secure storage area; if it does, the write operation is rejected. This design ensures access protection for issuer constraints while supporting authorized controlled updates or resets, complying with PCI sensitive service security compliance requirements.

[0059] The second verification module verifies the following: whether the issuer field of the entity certificate matches the subject of the intermediate CA certificate; and verify the digital signature of the entity certificate using the public key of the intermediate CA certificate.

[0060] Since the apparatus described in Embodiment 2 of the present invention is an apparatus used to implement the method of Embodiment 1 of the present invention, those skilled in the art can understand the specific structure and variations of the apparatus based on the method described in Embodiment 1 of the present invention, and therefore will not be described again here. All apparatuses used in the method of Embodiment 1 of the present invention fall within the scope of protection of the present invention.

[0061] 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 KDH binding verification method, applied to a terminal, characterized in that: Includes the following steps: S1. Obtain the intermediate CA certificate for KDH; S2. Verify the legality of the digital signature and certificate chain of the intermediate CA certificate using the root certificate pre-installed on the terminal; S3. After successful verification, the intermediate CA certificate is bound to a valid KDH issuing CA, forming an issuer constraint, that is, only entity certificates issued by this intermediate CA certificate are accepted. S4. Obtain the entity certificate of KDH during subsequent communication; S5. Verify whether the entity certificate was issued by the bound intermediate CA certificate; S6. If yes, then accept the KDH access; otherwise, reject the KDH access.

2. The method according to claim 1, characterized in that: The issuer constraint cannot be modified at the application layer or external interfaces, and can only be updated or reset through certified sensitive service functions, which require authentication for access.

3. The method according to claim 1, characterized in that: In step S5, verifying whether the entity certificate was issued by the bound intermediate CA certificate specifically includes: Check if the issuer field of the entity certificate matches the subject of the intermediate CA certificate; Verify the digital signature of the entity certificate using the public key of the intermediate CA certificate.

4. The method according to claim 3, characterized in that: The S5 also includes: When any content verification fails, the terminal logs the security event and terminates the session.

5. The method according to claim 1, characterized in that: The binding of the intermediate CA certificate to a valid KDH issuing CA specifically means storing the binding relationship between the terminal and the intermediate CA certificate in a secure storage area, which is not directly accessible to the application layer or external interfaces. The binding relationship establishes an immutable issuer constraint, ensuring that only entity certificates issued by this intermediate CA certificate are accepted subsequently.

6. The method according to claim 1, characterized in that: The root certificate is pre-installed on the terminal at the factory.

7. A KDH binding verification device, characterized in that: include: The first certificate acquisition module is used to acquire the intermediate CA certificate of KDH; The first verification module uses the root certificate pre-installed on the terminal to verify the legality of the digital signature and certificate chain of the intermediate CA certificate; The issuer constraint module is used to bind the intermediate CA certificate to a valid KDH issuing CA after the first verification module passes the verification, thus forming an issuer constraint, that is, only entity certificates issued by this intermediate CA certificate are accepted. The second certificate acquisition module is used to obtain the entity certificate of KDH during subsequent communication with KDH; The second verification module is used to verify whether the entity certificate is issued by the bound intermediate CA certificate; The session control module is used to determine whether to accept the KDH and continue communication based on the verification results of the first verification module and the second verification module. If the verification fails, the session is terminated.

8. The apparatus according to claim 7, characterized in that: The issuer constraint module is a secure storage area that cannot be directly accessed by the application layer or external interfaces. The issuer constraints cannot be modified through the application layer or external interfaces, but can only be updated or reset through authenticated sensitive service functions, and access to the sensitive functions requires authentication.

9. The apparatus according to claim 7, characterized in that: The second verification module verifies the following: Check if the issuer field of the entity certificate matches the subject of the intermediate CA certificate; Verify the digital signature of the entity certificate using the public key of the intermediate CA certificate.

Images