A remote key injection method, system, pos

Abstract

This invention provides a remote key injection method, system, and POS machine. The method includes: sending a connection request to a key distribution host, the connection request including device capability information and / or key requirement information; receiving response information sent by the key distribution host, the response information including a first ciphertext obtained by encrypting a working key based on a first transmission key, or a second ciphertext obtained by encrypting the working key based on a second transmission key, or a third ciphertext obtained by encrypting the working key based on a first transmission key and a second transmission key; and decrypting the ciphertext to obtain the working key. This scheme is compatible with devices supporting TR34, devices supporting ECKA, and devices supporting mixed mode. The server can automatically select the most efficient or most secure protocol for interaction based on the algorithm capabilities reported by the device, greatly improving the efficiency, security, and flexibility of key distribution.

Description

Technical Field

[0001] This invention relates to the field of remote key injection technology, and more particularly to a remote key injection method, system, and POS machine. Background Technology

[0002] Remote key injection (RKI) is the core step in the security initialization of payment terminals. The mainstream technical routes are mainly divided into RSA key transmission system based on public key infrastructure (PKI) (represented by the TR34 standard) and key negotiation system based on elliptic curve (ECC) (represented by ECDH / ECKA).

[0003] The RSA key transfer system, based on the TR34 specification, utilizes RSA asymmetric encryption and digital signature technology. The process includes identity authentication and certificate exchange, encrypting the transmission key Kn using the RSA public key, and decrypting the working key using Kn. Its advantages include high security and compliance with the PCI standard, but RSA computation is computationally intensive. The key negotiation system, based on the ECC elliptic curve principle, involves the key distribution host and key receiving device each generating temporary public-private key pairs. After exchanging public keys, they calculate the same transmission key TK locally using the ECDH principle. Its advantages include fast computation speed, low bandwidth consumption, and suitability for generating high-strength keys (such as AES256), but the process is not fully compatible with traditional bank card organization specifications (such as TR34).

[0004] Existing Key Distribution Hosts (KDHs) typically support only one fixed key exchange protocol. For example, they may enforce either the TR34 specification based on RSA certificates or ECDH / ECKA negotiation based on ECC. With the diversification of point-of-sale (POS) terminals, devices from the same batch or different vendors may have varying hardware capabilities (some only support RSA hardware acceleration, while others support ECC). A single-protocol server cannot efficiently serve a heterogeneous group of devices simultaneously, resulting in either older devices being unable to connect or newer devices being forced to use inefficient older protocols. Therefore, a remote key injection method is needed that can dynamically identify and match protocols based on the capabilities of the terminal devices, and even support concurrent use of mixed protocols. Summary of the Invention

[0005] The purpose of this invention is to provide a remote key injection method, system, and POS machine that is compatible with devices that support TR34 (RSA), ECKA (ECC), and mixed mode. The server can automatically select the most efficient or secure protocol for interaction based on the algorithm capabilities reported by the device, which greatly improves the efficiency, security, and flexibility of key distribution.

[0006] The technical solution provided by this invention is as follows: In a first aspect, this application provides a remote key injection method, applied to a key receiving device, comprising: A connection request is sent to the key distribution host. The connection request includes device capability information and / or key requirement information. The device capability is that it only supports the first key transmission protocol, or only supports the second key transmission protocol, or supports both the first key transmission protocol and the second key transmission protocol. The key requirement is a first key requirement corresponding to the first key transmission protocol, or a second key requirement corresponding to the second key transmission protocol, or a synchronization requirement between the first key and the second key. The system receives a response message from the key distribution host, the response message including ciphertext obtained by encrypting the working key generated by the key distribution host based on the transmission key; the ciphertext is either a first ciphertext obtained by encrypting the working key with a first transmission key generated based on a first encryption process of the first key transmission protocol, or a second ciphertext obtained by encrypting the working key with a second transmission key generated based on a second encryption process of the second key transmission protocol, or a third ciphertext obtained by encrypting the working key with both the first and second transmission keys. The ciphertext is decrypted to obtain the working key.

[0007] In some embodiments, when the device capability is to simultaneously support both the first key transmission protocol and the second key transmission protocol, it further includes: A first temporary key pair is generated based on the elliptic curve algorithm. The first temporary key pair includes a first ECC temporary public key and a first ECC temporary private key. The first ECC temporary public key is digitally signed using the RSA private key of the key receiving device to obtain the first RSA digital signature. When sending a connection request to the key distribution host, the connection request also includes the first ECC temporary public key and the first RSA digital signature.

[0008] In some implementations, the response information further includes a second ECC temporary public key and a second RSA digital signature. The second ECC temporary public key and the second RSA digital signature are obtained based on the response of the key distribution host when it receives the connection request. When the key distribution host receives the connection request, it verifies the first RSA digital signature based on the RSA public key of the key receiving device, and generates a second temporary key pair after successful verification. The second temporary key pair includes the second ECC temporary public key and the second ECC temporary private key. The second temporary public key is then digitally signed using the RSA private key of the key distribution host to obtain the second RSA digital signature.

[0009] In some implementations, the first transmission key is generated by the key distribution host after performing two-way authentication with the key receiving device through an RSA certificate, and is encrypted using the RSA public key of the key distribution host; The second transmission key is a shared key obtained by the key distribution host through negotiation and calculation of the second ECC temporary private key and the first ECC temporary public key; When the device is capable of simultaneously supporting the first key transmission protocol and the second key transmission protocol, and the key requirement is a synchronization requirement for the first key and the second key, the first transmission key is used as the first key component, and the second transmission key is used as the second key component. The third ciphertext is obtained by encrypting the working key with a first synthesized transmission key, which is obtained by the key distribution host synthesizing the first key component and the second key component using a synthesis function.

[0010] In some implementations, the second transmission key may also be signed and authenticated using the RSA certificate during the negotiation and calculation process of the second ECC temporary private key and the first ECC temporary public key.

[0011] In some implementations, upon receiving the response information sent by the key distribution host, the method further includes: The identity is authenticated with the distribution host using the RSA certificate, and the second RSA digital signature is verified using the RSA public key of the key distribution host. After successful verification, a third transmission key is calculated based on the RSA public key of the key distribution host, and a fourth transmission key is calculated based on the first ECC temporary private key and the second ECC temporary public key. The second synthetic transmission key is calculated based on the third transmission key and the fourth transmission key; The working key is obtained by decrypting the third ciphertext using the second synthesized transmission key.

[0012] In some implementations, the working key is obtained by encapsulating the first service key and the second service key issued by the key distribution host according to the first key requirement and the second key requirement in the same data structure, so that the first synthesized transmission key encrypts the first service key and the second service key as a whole.

[0013] Secondly, this application provides a remote key injection method applied to a key distribution host, comprising: The device receives a connection request sent by a key receiving device. The connection request includes the device capability information and / or key requirement information of the key receiving device. The device capability is that it only supports the first key transmission protocol, or only supports the second key transmission protocol, or supports both the first key transmission protocol and the second key transmission protocol. The key requirement is a first key requirement corresponding to the first key transmission protocol, or a second key requirement corresponding to the second key transmission protocol, or a synchronization requirement between the first key and the second key. The key receiving device sends a response message, which includes ciphertext obtained by encrypting the generated working key based on the transmission key; the ciphertext is either a first ciphertext obtained by encrypting the working key with a first transmission key generated based on a first encryption process of the first key transmission protocol, or a second ciphertext obtained by encrypting the working key with a second transmission key generated based on a second encryption process of the second key transmission protocol, or a third ciphertext obtained by encrypting the working key with both the first and second transmission keys, so that the key receiving device can decrypt the ciphertext to obtain the working key.

[0014] Thirdly, this application provides a remote key injection system, comprising: A key receiving device is configured to send a connection request to a key distribution host. The connection request includes device capability information and / or key requirement information of the key receiving device. The device capability is that it only supports a first key transmission protocol, or only supports a second key transmission protocol, or supports both the first key transmission protocol and the second key transmission protocol. The key requirement is a first key requirement corresponding to the first key transmission protocol, or a second key requirement corresponding to the second key transmission protocol, or a synchronization requirement between the first key and the second key. A key distribution host is configured to receive the connection request and send response information to the key receiving device. The response information includes ciphertext obtained by encrypting a working key generated by the key distribution host based on a transmission key. The ciphertext is either a first ciphertext obtained by encrypting the working key with a first transmission key generated based on a first encryption process of the first key transmission protocol, or a second ciphertext obtained by encrypting the working key with a second transmission key generated based on a second encryption process of the second key transmission protocol, or a third ciphertext obtained by encrypting the working key with both the first and second transmission keys. The key receiving device can decrypt the ciphertext to obtain the working key.

[0015] Fourthly, this application provides a POS machine that uses the remote key injection method described in the first aspect to obtain a working key.

[0016] The remote key injection method, system, and POS machine provided by this invention can simultaneously support devices that support TR34 (RSA), devices that support ECKA (ECC), and devices that support mixed mode. The server can select the most efficient or most secure protocol for interaction based on the device capability information or key requirement information reported by the device, which greatly improves the efficiency, security, and flexibility of key distribution. Attached Figure Description

[0017] The preferred embodiments will now be described in a clear and easy-to-understand manner, with reference to the accompanying drawings, to further explain the above-mentioned characteristics, technical features, advantages, and implementation methods of this solution.

[0018] Figure 1 This is a schematic diagram of the overall process of one embodiment of the present invention; Figure 2 This is a schematic diagram of the overall process of another embodiment of the present invention. Detailed Implementation

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the specific implementation methods of the present invention will be described below with reference to the accompanying drawings. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings and other implementation methods can be obtained based on these drawings without any creative effort.

[0020] To keep the drawings concise, only the parts relevant to the invention are shown schematically in each figure, and they do not represent the actual structure of the product. Furthermore, for ease of understanding, in some figures, only one of components with the same structure or function is shown schematically, or only one is labeled. In this document, "one" can mean not only "only one" but also "more than one".

[0021] Before detailing the technical solution of this application, the proprietary technical terms in this field are explained: Remote Key Injection (RKI) refers to the process of securely distributing and loading encryption keys into payment terminal devices remotely over a network. It can also be called remote key loading or online key distribution.

[0022] A Key Distribution Host (KDH) is a server-side component in an RKI system responsible for generating, encrypting, and distributing keys. It is typically connected to a Hardware Encryption Machine (HSM). It can also be referred to as a key injection server, KMS backend, or server-side component.

[0023] A key receiving device (KRD) refers to the target terminal that receives the key, typically a security device such as a POS machine or keypad. Examples include POS terminals, payment terminals, and acceptance terminals.

[0024] Public Key Infrastructure (PKI) refers to a universal security infrastructure that uses public key concepts and technologies to implement and provide security services. It forms the basis of the TR34 process. It can also be called a digital certificate system or a CA system.

[0025] The TR34 specification (Technical Report 34, TR34) is a remote key distribution standard protocol based on asymmetric key hierarchy (RSA) published by the PCI SSC (Payment Card Industry Security Standards Committee). It can also be referred to as PCIPIN Security TR-34.

[0026] Elliptic Curve Cryptography (ECC) is a public-key encryption algorithm based on elliptic curve mathematics. Compared to RSA, it requires a shorter key length while maintaining the same level of security. It can also be called an elliptic curve algorithm.

[0027] Elliptic Curve Key Agreement (ECKA) is a variant of the ECC algorithm used by two communicating parties to negotiate a shared key over an insecure channel. It can also be referred to as EC-DH or a key negotiation mechanism.

[0028] A transport key (TK / Kn) is a key temporarily generated during the RKI process, used solely to protect the subsequent transmission of the working key. It can also be called a process key, a key encryption key (KEK), or a session key.

[0029] The working key (WK) is the key actually used to encrypt sensitive data (such as magnet link information and PIN) in business transactions; it is the final payload of the RKI. It can also be called the business key, data key, PIN key, or DEK.

[0030] Remote key injection (RKI) is the core step in the security initialization of payment terminals. The mainstream technical routes are mainly divided into RSA key transmission system based on public key infrastructure (PKI) (represented by the TR34 standard) and key negotiation system based on elliptic curve (ECC) (represented by ECDH / ECKA).

[0031] The RSA key transfer system, based on the TR34 specification, utilizes RSA asymmetric encryption and digital signature technology. The process includes identity authentication and certificate exchange, encrypting the transmission key Kn using the RSA public key, and decrypting the working key using Kn. It is typically used to distribute AES128 or TDES keys. Its advantages include high security and compliance with the PCI standard, but RSA computation is computationally intensive. The key negotiation system, based on the ECC elliptic curve principle, involves the key distribution host and key receiving device each generating temporary public-private key pairs. After exchanging public keys, they calculate the same transmission key TK locally using the ECDH principle. Its advantages include fast computation speed, low bandwidth consumption, and suitability for generating high-strength keys (such as AES256), but the process is not fully compatible with traditional bank card organization specifications (such as TR34).

[0032] Existing Key Distribution Hosts (KDHs) typically support only one fixed key exchange protocol. For example, they may enforce either the TR34 specification based on RSA certificates or ECDH / ECKA negotiation based on ECC. With the diversification of point-of-sale (POS) terminals, devices from the same batch or different manufacturers may have varying hardware capabilities (some only support RSA hardware acceleration, while others support ECC). A single-protocol server cannot efficiently serve a heterogeneous group of devices simultaneously, resulting in either older devices being unable to connect or newer devices being forced to use inefficient older protocols. Furthermore, existing solutions typically negotiate only one type of transport key in a single session (e.g., generating only one transport key for encrypting the AES128 working key). However, in modern financial scenarios, terminals may require both traditional magnetic stripe card encryption keys (typically short, such as AES128 or TDES) and high-strength peer-to-peer (P2PE) encryption keys (such as AES256). Existing technologies struggle to simultaneously distribute keys of multiple strengths in a single interaction by leveraging the advantages of different asymmetric algorithms (e.g., using RSA for authentication and ECC for temporary key negotiation). Therefore, a remote key injection method is needed that can dynamically identify and match protocols based on the capabilities of terminal devices, and even support concurrent hybrid protocols.

[0033] This solution breaks the "island effect" of traditional key injection protocols, transforming from "static and singular" to "dynamic and adaptive." The server no longer rigidly requires devices to adhere to a single specification, but instead adaptively switches based on device capabilities (seamless switching between RSA and ECC). Furthermore, it achieves "dual-track concurrent injection," creatively combining the advantages of TR34 (mature and compliant) and ECKA (efficient and high-strength). On the same device, it can obtain both AES128 keys conforming to older specifications and future-proof AES256 keys, solving the pain point of traditional single protocols being unable to simultaneously ensure compatibility and high security. The following is a detailed description of this solution with reference to the accompanying diagrams: In one embodiment, refer to the appendix to the specification. Figure 1 This application provides a remote key injection method, applied to a key receiving device, comprising: S100. Send a connection request to the key distribution host. The connection request includes device capability information and / or key requirement information. The device capability is that it only supports the first key transmission protocol, or only supports the second key transmission protocol, or supports both the first key transmission protocol and the second key transmission protocol. The key requirement is the first key requirement corresponding to the first key transmission protocol, or the second key requirement corresponding to the second key transmission protocol, or the first key and second key synchronization requirement.

[0034] In one example, the first key transmission protocol is TR34, and the second key transmission protocol is ECKA. Taking a POS machine as the key receiving device as an example, when performing remote key injection, the POS machine initiates a connection request to the KDH (Key Distribution Host), and the request message contains a device capability field.

[0035] For example, the field {"Alg_Support": ["RSA_2048","ECC_P256"],"Protocol_Support": ["TR34","ECKA_Variant"],"Key_Need":["PIN_KEY_AES128","DATA_KEY_AES256"]} explicitly tells the server that the key receiving device supports both TR34 and ECC, and requires two keys of different strengths. Other examples may include key receiving devices supporting only the TR34 protocol or only the ECKA protocol. When the key receiving device supports both TR34 and ECC, different key requirements are possible, such as requiring only one type of key (i.e., single-key requirement) or two keys of different strengths (i.e., dual-key requirement), broadening the scope and application scenarios of this application.

[0036] S200. Receive response information sent by the key distribution host. The response information includes ciphertext obtained by encrypting the working key generated by the key distribution host based on the transmission key. The ciphertext is either a first ciphertext obtained by encrypting the working key with the first transmission key generated by the first encryption process of the first key transmission protocol, or a second ciphertext obtained by encrypting the working key with the second transmission key generated by the second encryption process of the second key transmission protocol, or a third ciphertext obtained by encrypting the working key with the first transmission key and the second transmission key.

[0037] After the key receiving device sends a connection request to the key distribution host (or server), the key distribution host receives the request, and the policy decision module can match according to preset rules: Case A (TR34 only): If the device only supports RSA, or requests a traditional bank key, KDH decides to execute the standard TR34 procedure, generate a first transmission key based on the first encryption procedure of the first key transmission protocol, encrypt the issued working key to obtain the first ciphertext, and send it to the key receiving device.

[0038] Case B (ECKA only): If the device only supports ECC and prioritizes speed, KDH decides to execute the ECKA process, generates a second transmission key based on the second encryption process of the second key transmission protocol, encrypts the issued working key to obtain the second ciphertext, and sends it to the key receiving device.

[0039] Case C (Hybrid): If the device supports dual-mode and the request includes both high and low strength key requirements, KDH decides to execute the "hybrid injection strategy", encrypting the working key based on the first and second transmission keys to obtain the third ciphertext, and sending it to the key receiving device.

[0040] When the device is capable of simultaneously supporting the first key transmission protocol and the second key transmission protocol, and the key requirement is the synchronization of the first key and the second key, the key distribution host can execute the first encryption process and the second encryption process in parallel or serial manner.

[0041] S300: Decrypt the ciphertext to obtain the working key.

[0042] After receiving the ciphertext sent by the key distribution host, the key receiving device can obtain the working key by decrypting the ciphertext, thus achieving secure transmission of the working key.

[0043] This solution is compatible with devices that support TR34 (RSA), ECKA (ECC), and mixed-mode devices. The server can automatically select the most efficient, secure, or user-required protocol for interaction based on the algorithm capabilities reported by the device, greatly improving the efficiency, security, and flexibility of key distribution.

[0044] Furthermore, existing KDH solutions are typically isolated (either running TR34 or ECKA services). This proposed KDH solution introduces a new "Protocol Arbiter," which sits after the network access layer and before the Hardware Encryptor (HSM) calls. On the hardware side, as long as the HSM supports both RSA and ECC instruction sets, no hardware replacement is required; however, a new HSM interface needs to be called to support the packaging of "mixed key blocks."

[0045] Since the KDH in this application can support multiple modes, usage rules can be set for ease of management. For example, during power-on initialization (low frequency, high security requirements), even if dual-mode support is set, the mixed mode is forced to be used; when updating the PIN key quickly (high frequency, low latency requirements), even if dual-mode support is supported, the pure ECKA mode (using ECC public and private keys) is preferred; if it is an older device, it will fall back to TR34 mode, or an even older ECDH mode (using RSA public and private keys).

[0046] When the device only supports the first key transmission protocol or only supports the second key transmission protocol, or when the key requirement is a first key requirement corresponding to the first key transmission protocol or a second key requirement corresponding to the second key transmission protocol, KDH performs working key encryption based on the first encryption process of the first key transmission protocol or the second encryption process of the second key transmission protocol. This encryption process can adopt the same encryption process as existing technologies, and will not be described in detail in this application. The focus of this application is the "hybrid injection strategy" of KDH when the device supports dual-mode and the key request includes both high and low strength key requirements.

[0047] In one embodiment, based on the foregoing embodiments, when the device capability is to simultaneously support both the first key transmission protocol and the second key transmission protocol, it further includes: A first temporary key pair is generated based on the elliptic curve algorithm. The first temporary key pair includes a first ECC temporary public key and a first ECC temporary private key. The first ECC temporary public key is digitally signed using the RSA private key of the key receiving device to obtain a first RSA digital signature. When sending a connection request to the key distribution host, the connection request also includes the first ECC temporary public key, the first RSA digital signature, and the target key ID.

[0048] Specifically, the key receiving device (e.g., KRD, POS machine, etc.) first generates a temporary elliptic curve key pair within its local security domain, containing a private key (krd_priv) and a public key (krd_pub). The device digitally signs the generated ECC temporary public key (krd_pub) using a pre-configured RSA private key (i.e., the device's identity private key). This step establishes a cryptographic binding between the ECC negotiation parameters and the device's legitimate identity. The device then sends a connection request to the key distribution host, carrying a "backpack" payload: {ECC temporary public key (i.e., the first ECC temporary public key) + RSA digital signature (the first RSA digital signature) + target key ID}.

[0049] Preferably, the response information also includes a second ECC temporary public key and a second RSA digital signature; the second ECC temporary public key and the second RSA digital signature are obtained based on the response of the key distribution host when it receives the connection request. When the key distribution host receives the connection request, it verifies the first RSA digital signature based on the RSA public key of the key receiving device, and generates a second temporary key pair after successful verification. The second temporary key pair includes a second ECC temporary public key and a second ECC temporary private key. Then, the key distribution host digitally signs the second ECC temporary public key using its RSA private key to obtain the second RSA digital signature.

[0050] After receiving the request, the server first verifies the digital signature using the RSA public key of the key receiving device to ensure that the ECC public key does indeed come from a legitimate terminal device. At the same time, before generating the ciphertext, a second RSA digital signature is also generated, which is digitally signed by the RSA private key of the key distribution host. This is so that the key receiving device can identify the key distribution host after receiving the ciphertext, further improving the security of key interaction.

[0051] Preferably, the first transmission key is generated by the key distribution host after performing two-way authentication with the key receiving device through an RSA authentication certificate, and is encrypted using the key distribution host's RSA public key; the second transmission key is a shared key obtained by the key distribution host through negotiation and calculation of the second ECC temporary private key and the first ECC temporary public key.

[0052] Specifically, the first encryption process based on the first key transmission protocol is as follows: establish a TR34 channel based on the RSA protocol; perform two-way authentication (exchange certificates) using RSA public and private keys; generate and encrypt the transmission key TK_TR34 using the RSA public key through KDH to protect the subsequent AES128 key.

[0053] The second encryption process based on the second key transmission protocol is as follows: It is recommended to use an ECKA channel based on the ECC protocol; use the ECC public and private keys (which may be temporarily generated ephemeral keys) to negotiate the key. Both parties calculate the shared transmission key TK_ECKA according to the ECDH variant algorithm (ECKA) and the public keys exchanged by both parties, so as to protect the subsequent AES256 key.

[0054] When the device is capable of simultaneously supporting both the first and second key transmission protocols, and the key requirement is synchronization of the first and second keys, the first transmission key is used as the first key component, and the second transmission key is used as the second key component. The third ciphertext is obtained by encrypting the working key with the first synthesized transmission key, which is obtained by the key distribution host synthesizing the first and second key components using a synthesis function. In this case, the working key is obtained by encapsulating the first and second business keys issued by the key distribution host according to the first and second key requirements into the same data structure, so that the first synthesized transmission key can encrypt the first and second business keys as a whole.

[0055] In the packaging process of hybrid key injection, the server does not generate two independent ciphertext packets. This application introduces the concept of a "Composite Transport Key": the server uses the first key component (Krsa) negotiated via the TR34 protocol and the second key component (Kecc) negotiated via the ECKA protocol to generate a unique composite transport key through a key derivation function (e.g., Kfinal=HKDF(Krsa⊕Kecc)). Subsequently, the server encapsulates business keys of different strengths (e.g., AES-128 PIN keys and AES-256 data keys) in the same data structure (Key Block) and uses the composite transport key for overall encryption (AES-GCM mode). This packaging method ensures the "atomicity" of key injection. The terminal can only synthesize the correct decryption key if it successfully completes both RSA authentication and ECC key negotiation simultaneously. If any protocol branch is attacked or fails, the entire key packet cannot be decrypted. This completely solves the risk of a "semi-secure state" (e.g., only the low-strength key is updated while the high-strength key update fails) that may occur in the prior art.

[0056] The KDH server does not directly use a single protocol's transport key for encryption; instead, it performs a key fusion operation. The server obtains a first transport key (TK_TR34) negotiated through the TR34 procedure and a second transport key (TK_ECKA) negotiated through the ECKA procedure. The server then uses a key derivation function (KDF) or an XOR operation to generate a unique composite transport key (Final_TK), as shown in the following formula: Final_TK = KDF( TK_TR34 ⊕ TK_ECKA, Salt ); At this point, Final_TK simultaneously contains both RSA authentication attributes and ECC high-strength attributes.

[0057] In addition, the server packages all working keys to be issued (such as the first business key WorkingKey_A and the second business key WorkingKey_B) into a unified key payload. This payload is then encrypted using AES-GCM using the aforementioned Final_TK to generate a unique encrypted block. KDH then sends this single encrypted block to the key receiving device.

[0058] In addition, to prevent man-in-the-middle attacks, the second transmission key can also be signed and authenticated by an RSA certificate during the negotiation and calculation process of the second ECC ephemeral private key and the first ECC ephemeral public key. That is, during the hybrid injection process, the ECC ephemeral public key (ephemeral key) generated by the terminal must be digitally signed by the terminal's RSA identity private key (TR34 certificate private key) as part of the "payload to be signed" to achieve linkage between protocols and to achieve secure ECDH negotiation without increasing the cost of additional ECC certificate chain management.

[0059] In existing technologies, ECDH negotiation is typically unauthenticated (vulnerable to man-in-the-middle attacks) or requires establishing a complex ECC certificate chain. This solution innovatively utilizes the device's existing RSA identity key to sign the ECC temporary parameters. This retains the efficiency and forward security of ECC while leveraging the mature RSA PKI system for identity endorsement, achieving the best of both worlds. Furthermore, compared to traditional TR34 which requires multiple interactions (requesting a certificate -> returning a certificate -> sending an encrypted key), this process directly carries the public key when sending the connection request, achieving "request-based negotiation." The entire process is completed in a single HTTP request, significantly reducing the failure rate of POS machines in weak network environments.

[0060] In one embodiment, based on the foregoing embodiments, upon receiving the response information sent by the key distribution host, the method further includes: The identity is authenticated with the distribution host using an RSA certificate, and the second RSA digital signature is verified using the RSA public key of the key distribution host. After successful verification, the third transmission key is calculated using the RSA public key of the key distribution host, and the fourth transmission key is calculated using the first ECC temporary private key and the second ECC temporary public key. The second combined transmission key is calculated using the third and fourth transmission keys. The working key is obtained by decrypting the third ciphertext using the second combined transmission key.

[0061] When both the key receiving device and the key distribution host are correct connection devices and the key transmission is secure, the third transmission key should be exactly the same as the first transmission key, the fourth transmission key should be exactly the same as the second transmission key, and the second combined transmission key should be exactly the same as the first combined transmission key. Only in this way can it be guaranteed that the working key obtained by decrypting the ciphertext is the correct key; otherwise, it indicates that there is a security problem with this key transmission.

[0062] Specifically, upon receiving the response, the device first verifies the server's RSA signature to confirm a successful connection to a legitimate KDH server. Using its local ECC private key and the server's ECC public key, the device performs ECDH computation to obtain the same shared secret. It then uses the same derivation algorithm to generate a transport key, resulting in a synthesized transport key. Finally, by decrypting the ciphertext using the synthesized transport key, the target working key is obtained.

[0063] Additionally, the device can calculate the decrypted key checksum (KCV) to verify key integrity. Once verification is successful, the key is securely stored in a hardware-secured area. Finally, the device sends an "injection complete" confirmation message to the server, ending the process.

[0064] In one embodiment, refer to the appendix to the specification. Figure 2 This application provides a remote key injection method, applied to a key distribution host, comprising: S110. Receive a connection request sent by a key receiving device. The connection request includes device capability information and / or key requirement information of the key receiving device. The device capability is that it only supports the first key transmission protocol, or only supports the second key transmission protocol, or supports both the first key transmission protocol and the second key transmission protocol. The key requirement is the first key requirement corresponding to the first key transmission protocol, or the second key requirement corresponding to the second key transmission protocol, or the first key and second key synchronization requirement. S210. Send response information to the key receiving device. The response information includes ciphertext obtained by encrypting the working key generated based on the transmission key. The ciphertext is either a first ciphertext obtained by encrypting the working key with the first transmission key generated based on the first encryption process of the first key transmission protocol, or a second ciphertext obtained by encrypting the working key with the second transmission key generated based on the second encryption process of the second key transmission protocol, or a third ciphertext obtained by encrypting the working key with the first transmission key and the second transmission key, so that the key receiving device can decrypt the ciphertext to obtain the working key.

[0065] This embodiment describes the entire remote key injection process from the perspective of the key distribution host. Its technical concept is the same as that of the aforementioned embodiment, and will not be repeated here.

[0066] In one embodiment, this application provides a remote key injection system, comprising: A key receiving device is used to send a connection request to a key distribution host. The connection request includes the device capability information and / or key requirement information of the key receiving device. The device capability is that it only supports the first key transmission protocol, or only supports the second key transmission protocol, or supports both the first key transmission protocol and the second key transmission protocol. The key requirement is the first key requirement corresponding to the first key transmission protocol, or the second key requirement corresponding to the second key transmission protocol, or the first key and second key synchronization requirement. A key distribution host is used to receive connection requests and send response information to a key receiving device. The response information includes ciphertext obtained by encrypting the working key generated by the key distribution host based on the transmission key. The ciphertext is either a first ciphertext obtained by encrypting the working key with the first transmission key generated based on the first encryption process of the first key transmission protocol, or a second ciphertext obtained by encrypting the working key with the second transmission key generated based on the second encryption process of the second key transmission protocol, or a third ciphertext obtained by encrypting the working key with the first transmission key and the second transmission key. The key receiving device can decrypt the ciphertext to obtain the working key.

[0067] This embodiment describes the entire remote key injection process from a system perspective. Its technical concept is the same as that of the aforementioned embodiment, and will not be repeated here.

[0068] In one embodiment, this application provides a POS machine that uses the remote key injection method described in the foregoing embodiments to obtain a working key.

[0069] It should be noted that the above embodiments can be freely combined as needed. The above description is only a preferred embodiment of the present invention. It should be pointed out that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A remote key injection method, applied to a key receiving device, characterized in that, include: Send a connection request to the key distribution host, the connection request including device capability information and / or key requirement information; The device capability is to support only the first key transmission protocol, or only the second key transmission protocol, or both the first key transmission protocol and the second key transmission protocol; the key requirement is a first key requirement corresponding to the first key transmission protocol, or a second key requirement corresponding to the second key transmission protocol, or a synchronization requirement between the first key and the second key. Receive response information sent by the key distribution host, the response information including ciphertext obtained by encrypting the working key generated by the key distribution host based on the transmission key; The ciphertext is either a first ciphertext obtained by encrypting the working key with a first transmission key generated based on a first encryption process of the first key transmission protocol, or a second ciphertext obtained by encrypting the working key with a second transmission key generated based on a second encryption process of the second key transmission protocol, or a third ciphertext obtained by encrypting the working key with the first transmission key and the second transmission key. The working key is obtained by decrypting the ciphertext.

2. The remote key injection method according to claim 1, characterized in that, When the device capability is to simultaneously support both the first key transmission protocol and the second key transmission protocol, it further includes: A first temporary key pair is generated based on the elliptic curve algorithm. The first temporary key pair includes a first ECC temporary public key and a first ECC temporary private key. The first ECC temporary public key is digitally signed using the RSA private key of the key receiving device to obtain the first RSA digital signature. When sending a connection request to the key distribution host, the connection request also includes the first ECC temporary public key and the first RSA digital signature.

3. The remote key injection method according to claim 2, characterized in that, The response information also includes a second ECC temporary public key and a second RSA digital signature. The second ECC temporary public key and the second RSA digital signature are obtained based on the response of the key distribution host when it receives the connection request. When the key distribution host receives the connection request, it verifies the first RSA digital signature based on the RSA public key of the key receiving device, and generates a second temporary key pair after successful verification. The second temporary key pair includes the second ECC temporary public key and the second ECC temporary private key. Then, the second ECC temporary public key is digitally signed using the RSA private key of the key distribution host to obtain the second RSA digital signature.

4. The remote key injection method according to claim 3, characterized in that, The first transmission key is generated by the key distribution host after performing two-way authentication with the key receiving device through an RSA certificate, and is encrypted using the RSA public key of the key distribution host; The second transmission key is a shared key obtained by the key distribution host through negotiation and calculation of the second ECC temporary private key and the first ECC temporary public key; When the device is capable of simultaneously supporting the first key transmission protocol and the second key transmission protocol, and the key requirement is a synchronization requirement for the first key and the second key, the first transmission key is used as the first key component, and the second transmission key is used as the second key component. The third ciphertext is obtained by encrypting the working key with a first synthesized transmission key, which is obtained by the key distribution host synthesizing the first key component and the second key component using a synthesis function.

5. The remote key injection method according to claim 4, characterized in that, The second transmission key can also be signed and authenticated using the RSA certificate during the negotiation and calculation process of the second ECC temporary private key and the first ECC temporary public key.

6. The remote key injection method according to claim 5, characterized in that, Upon receiving the response information sent by the key distribution host, the method further includes: The identity is authenticated with the distribution host using the RSA certificate, and the second RSA digital signature is verified using the RSA public key of the key distribution host. After successful verification, a third transmission key is calculated based on the RSA public key of the key distribution host, and a fourth transmission key is calculated based on the first ECC temporary private key and the second ECC temporary public key. The second synthetic transmission key is calculated based on the third transmission key and the fourth transmission key; The working key is obtained by decrypting the third ciphertext using the second synthesized transmission key.

7. The remote key injection method according to any one of claims 4-6, characterized in that, The working key is obtained by encapsulating the first business key and the second business key issued by the key distribution host according to the first key requirement and the second key requirement in the same data structure, so that the first synthesized transmission key can encrypt the first business key and the second business key as a whole.

8. A remote key injection method, applied to a key distribution host, characterized in that, include: Receive a connection request sent by a key receiving device, the connection request including device capability information and / or key requirement information of the key receiving device; The device capability is to support only the first key transmission protocol, or only the second key transmission protocol, or both the first key transmission protocol and the second key transmission protocol; the key requirement is a first key requirement corresponding to the first key transmission protocol, or a second key requirement corresponding to the second key transmission protocol, or a synchronization requirement between the first key and the second key. Send response information to the key receiving device, the response information including ciphertext of the generated working key encrypted based on the transmission key; The ciphertext is either a first ciphertext obtained by encrypting the working key with a first transmission key generated based on a first encryption process of the first key transmission protocol, or a second ciphertext obtained by encrypting the working key with a second transmission key generated based on a second encryption process of the second key transmission protocol, or a third ciphertext obtained by encrypting the working key with the first transmission key and the second transmission key, so that the key receiving device can decrypt the ciphertext to obtain the working key.

9. A remote key injection system, characterized in that, include: A key receiving device is used to send a connection request to a key distribution host, the connection request including device capability information and / or key requirement information of the key receiving device; The device capability is to support only the first key transmission protocol, or only the second key transmission protocol, or both the first key transmission protocol and the second key transmission protocol; the key requirement is a first key requirement corresponding to the first key transmission protocol, or a second key requirement corresponding to the second key transmission protocol, or a synchronization requirement between the first key and the second key. A key distribution host is configured to receive the connection request and send response information to the key receiving device, the response information including ciphertext obtained by encrypting the working key generated by the key distribution host based on the transmission key; The ciphertext is either a first ciphertext obtained by encrypting the working key with a first transmission key generated based on a first encryption process of the first key transmission protocol, or a second ciphertext obtained by encrypting the working key with a second transmission key generated based on a second encryption process of the second key transmission protocol, or a third ciphertext obtained by encrypting the working key with the first transmission key and the second transmission key. The key receiving device can decrypt the ciphertext to obtain the working key.

10. A POS machine, characterized in that, The working key is obtained by using the remote key injection method according to any one of claims 1-7.

Images