Terminal key injection method and system based on temporary certificate, and storage medium

Abstract

The invention discloses a terminal key injection method and system based on a temporary certificate and a storage medium, and belongs to the field of electronic payment and information security. According to the method, a bidirectional identity authentication and chain verification mechanism based on a temporary certificate is introduced, and an identity verification system based on a digital certificate is directly established, so that the defects that a traditional scheme only depends on random number anti-replay, so that identity verification cannot be performed, and the traditional scheme is easily attacked by a man-in-the-middle are overcome, bidirectional credible authentication of a key injection requester and a receiver is realized, and the authentication efficiency is improved. And the legality of the operation main body is ensured from the source. Meanwhile, the temporary certificate is bound with the unique identity information of the terminal, and authorization is carried out after verification, so that effective binding of the injection authority and the terminal identity is realized, the defects of fuzzy authority management and control and easy occurrence of an unauthorized operation in a traditional scheme are overcome, and accurate management and control of the authority are achieved. In addition, the digital signature and temporary public key encryption technology is utilized, and tamper-proof and confidentiality guarantee is provided for the secret key data in the transmission process.

Description

Technical Field

[0001] This application relates to the fields of electronic payment and information security technology, and in particular to a terminal key injection method, system and storage medium based on temporary certificates. Background Technology

[0002] In the deployment and use of key-sensitive devices such as payment terminals and financial terminals, the security and legitimacy of key injection are core requirements. Existing terminal key injection schemes have the following core technical defects:

[0003] (1) Lack of identity verification and anti-tampering mechanism for key injection: Traditional schemes rely on random numbers to prevent replay of injection requests. However, random numbers can only ensure the uniqueness of the request, but cannot verify the legitimate identity of the injection initiator, nor can they guarantee the data integrity during key transmission. This can easily lead to security risks such as key hijacking and tampering.

[0004] (2) Lack of effective control over key injection permissions: There is a lack of permission restriction mechanism that is bound to the terminal identity. Any device with an injection channel can initiate a key injection request, which poses a security risk of illegal injection of malicious keys and unauthorized operation.

[0005] Therefore, there is an urgent need for a terminal key injection scheme with identity authentication capabilities to address the shortcomings of existing technologies from the perspectives of security and access control. Summary of the Invention

[0006] The embodiments of this disclosure provide a terminal key injection method, system, and storage medium based on temporary certificates, which at least solves the technical problems of insecure injection process and weak access control caused by the lack of identity certificate-based verification mechanism and data anti-tampering protection in traditional key injection schemes in the prior art, as well as the failure to effectively bind key injection permissions to terminal identity.

[0007] According to one aspect of the present disclosure, a terminal key injection method based on temporary certificates is provided, applied between a key distribution host configured with digital certificates and a sales terminal. The method includes: the sales terminal responding to a key injection request sent by the key distribution host, generating a pair of temporary asymmetric keys, using its own first digital certificate to issue a temporary digital certificate containing a temporary public key for the current session, and sending the first digital certificate and the temporary digital certificate to the key distribution host; the key distribution host verifying the authenticity and legality of the first digital certificate and the temporary digital certificate step by step according to the pre-set first digital certificate, generating a terminal master key after successful verification, and using the temporary public key to encrypt the terminal master key or to encrypt the terminal. The session key of the master key is encrypted to form the first ciphertext. The key distribution host uses its own private key to sign data containing at least the first ciphertext, and sends the first ciphertext, the signature data, and the key distribution host's own second digital certificate to the sales terminal. The sales terminal verifies the validity of the second digital certificate and the signature data based on the pre-set second digital certificate. After successful verification, it uses the temporary private key corresponding to the temporary public key to decrypt the first ciphertext, obtain the terminal master key, and store it. The key distribution host uses its own terminal master key to encapsulate the working key to be injected into a key block and sends it to the sales terminal. The sales terminal uses the stored terminal master key to decrypt and verify the key block, obtain the working key, and store it.

[0008] According to another aspect of the present disclosure, a storage medium is also provided, the storage medium including a stored program, wherein, when the program is executed, a processor performs any of the methods described above.

[0009] According to another aspect of the embodiments of this disclosure, a terminal key injection system based on temporary certificates is also provided, including a key distribution host configured with digital certificates and a sales terminal. The key distribution host and the sales terminal are configured such that: in response to a key injection request sent by the key distribution host, the sales terminal generates a pair of temporary asymmetric keys, uses its own first digital certificate to issue a temporary digital certificate containing a temporary public key for the current session, and sends the first digital certificate and the temporary digital certificate to the key distribution host; the key distribution host verifies the authenticity and legality of the first digital certificate and the temporary digital certificate level by level based on the preset first digital certificate, generates a terminal master key after successful verification, and uses the temporary public key to access the terminal master key or... The session key used to encrypt the terminal master key is encrypted to form the first ciphertext. The key distribution host uses its own private key to sign the data containing at least the first ciphertext, and sends the first ciphertext, the signature data, and the key distribution host's own second digital certificate to the sales terminal. The sales terminal verifies the validity of the second digital certificate and the signature data based on the pre-set second digital certificate. After successful verification, it uses the temporary private key corresponding to the temporary public key to decrypt the first ciphertext, obtain the terminal master key, and store it. The key distribution host uses its own terminal master key to encapsulate the working key to be injected into a key block and sends it to the sales terminal. The sales terminal uses the stored terminal master key to decrypt and verify the key block, obtain the working key, and store it.

[0010] The beneficial effects of this application include:

[0011] (1) Significantly enhanced security protection layers: This application takes temporary certificate authentication as the core security boundary. Compared with the traditional scheme that relies on random numbers, it adds identity verification based on digital certificate chain and data integrity protection capabilities based on digital signature. By constructing a step-by-step verification chain of "Root Certificate Authority (Root CA) → Terminal Certificate Authority (Terminal CA) → Temporary Certificate", it realizes strong authentication of the injection requester's identity and anti-tampering verification of instructions, which greatly reduces the security risks of key hijacking, tampering and illegal injection during transmission.

[0012] (2) Improved injection efficiency and resource utilization: This application simplifies the redundant verification process in traditional schemes that is highly dependent on the specific operating environment, focusing on core identity authentication links such as efficient and standard certificate verification and signature verification. The fast verification mechanism based on the trusted certificate chain can filter out illegal or unauthorized injection requests in real time, reducing the amount of invalid communication data, certificate transmission and unnecessary verification operations, reducing the overall resource consumption of the system, thereby improving the response speed and processing efficiency of the legitimate key injection process.

[0013] (3) Precise Access Control: Temporary digital certificates are deeply bound to the digital certificate and unique serial number of the point of sale (POS) terminal itself upon issuance. The verification process of the temporary certificate by the key distribution host (KDH) is also the process of confirming the legitimate identity of the terminal. This ensures that the scope of key injection permissions automatically and accurately matches the verified terminal identity, thereby preventing unauthorized injection operations beyond permissions or across devices and achieving automated and precise control from identity to permissions. Attached Figure Description

[0014] The accompanying drawings, which are included to provide a further understanding of this disclosure and form part of this application, illustrate exemplary embodiments of this disclosure and are used to explain this disclosure, but do not constitute an undue limitation of this disclosure. In the drawings:

[0015] Figure 1 This is a flowchart of the terminal key injection method based on temporary certificates according to Embodiment 1 of this application;

[0016] Figure 2 This is a flowchart of one of the digital certificate issuance processes according to Embodiment 1 of this application;

[0017] Figure 3 This is a flowchart of another digital certificate issuance process according to Embodiment 1 of this application. Detailed Implementation

[0018] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this disclosure.

[0019] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0020] Terminology Explanation:

[0021] POS: Short for Point of Sale, which is a point of sale terminal;

[0022] KLD: Key loading device, a key downloading device used for local key injection, commonly known as the mother POS;

[0023] RKMS: Remote key management system, a remote key management system used for remote key injection;

[0024] KDH: Key Distribution Host, is a general term that includes KLD and RKMS;

[0025] CSR: Certificate Signing Request, used to request a certificate from a CA;

[0026] SN: The unique serial number of the POS terminal;

[0027] TMK: Terminal master key under the MK / SK key system;

[0028] IPEK: The initial key under the DUKPT key representation;

[0029] CA: Certificate Authority, which provides identity authentication services and is responsible for issuing and managing digital certificates;

[0030] Certificate: A digital certificate is issued by a Certificate Authority (CA) and signed using the CA's private key. It is used to verify the authenticity of the certificate holder.

[0031] Example 1

[0032] According to a first aspect of this embodiment, a terminal key injection method based on a temporary certificate is provided, which is applied between a key distribution host configured with a digital certificate and a sales terminal. Figure 1 A flowchart illustrating the method is shown below. (Refer to...) Figure 1 As shown, the method includes:

[0033] S1: In response to the key injection request sent by the key distribution host, the sales terminal generates a pair of temporary asymmetric keys, uses its own first digital certificate to issue a temporary digital certificate containing the temporary public key for this session, and sends the first digital certificate and the temporary digital certificate to the key distribution host;

[0034] S2: The key distribution host verifies the authenticity and legality of the first digital certificate and the temporary digital certificate step by step based on the pre-set first digital certificate. After the verification is passed, it generates the terminal master key and uses the temporary public key to encrypt the terminal master key or the session key used to encrypt the terminal master key to form the first ciphertext.

[0035] S3: The key distribution host uses its own private key to sign data containing at least the first ciphertext, and sends the first ciphertext, the signed data and the key distribution host's own second digital certificate to the sales terminal.

[0036] S4: The sales terminal verifies the validity of the second digital certificate and signature data based on the pre-installed second digital certificate. After the verification is successful, it uses the temporary private key corresponding to the temporary public key to decrypt the first ciphertext, obtain the terminal master key, and store it.

[0037] S5: The key distribution host uses its own terminal master key to encapsulate the working key to be injected into a key block and distribute it to the sales terminal.

[0038] S6: The sales terminal uses the stored terminal master key to decrypt and verify the key block, obtain the working key, and store it.

[0039] In this embodiment, the key distribution host is pre-configured with a corresponding second digital certificate, which is used to prove its identity as a legitimate key manager. For example, this second digital certificate may be issued by a financial institution's private certificate authority (CA) or a trusted third-party key management CA. The sales terminal is pre-configured with its own first digital certificate, which is used to uniquely identify its identity as a legitimate payment terminal. For example, this first digital certificate may be issued by the terminal manufacturer, payment service provider, or the same trusted CA system, and the certificate typically contains information such as the terminal's unique serial number. Furthermore, both the key distribution host and the sales terminal are pre-configured with corresponding root digital certificates (such as industry root CA certificates or system private root certificates) to verify the legitimacy of each other's certificate signature chains. Thus, an initial trust anchor based on Public Key Infrastructure (PKI) is established, laying the foundation for subsequent certificate-based two-way authentication and secure communication.

[0040] Therefore, during the key injection trigger phase, when a newly deployed sales terminal (such as a new model POS machine) needs to be injected with a working key (such as a PIN encryption key) for financial transactions, or when the key of an existing terminal needs to be updated periodically, the key distribution host (such as a bank's back-end system or key management center) will initiate a key injection request to the sales terminal. At this time, the sales terminal responds to the key injection request sent by the key distribution host, generates a pair of temporary asymmetric keys, uses its own first digital certificate to issue a temporary digital certificate containing a temporary public key for this session, and sends the first digital certificate and the temporary digital certificate to the key distribution host (corresponding to step S1). Specifically, the key injection request can be sent via a local connection (such as USB, serial port, etc.) or remote network communication. After receiving the request, the sales terminal immediately generates a pair of temporary asymmetric keys (including a temporary public key and its corresponding temporary private key) locally, used only for this communication session. Subsequently, the sales terminal uses its own long-term stored first digital certificate, used to identify its legitimate identity, to issue a brand new, short-term valid temporary digital certificate for this session, which contains the temporary public key generated this time. Finally, the sales terminal sends its long-term identity credential (first digital certificate) and the temporary identity credential for this session (temporary digital certificate) to the key distribution host. This completes the cryptographic mapping and declaration from the terminal's long-term identity to the temporary identity for this session, laying the foundation for subsequent two-way authentication.

[0041] Then, the key distribution host verifies the authenticity and legality of the first digital certificate and the temporary digital certificate level by level based on the pre-set first digital certificate. After successful verification, it generates a terminal master key and encrypts the terminal master key or the session key used to encrypt the terminal master key using the temporary public key to form the first ciphertext (corresponding to step S2). Specifically, in the identity authentication and key preparation stage, after receiving the certificate from the sales terminal, the key distribution host initiates a strict verification process, including: the key distribution host uses its pre-set first digital certificate (e.g., the root CA certificate of the payment system) to verify the received first digital certificate, confirming that its signature chain is traceable to the trusted root and that the certificate has not expired or been revoked. Based on this successful verification, the key distribution host then uses the verified first digital certificate to verify the signature of the temporary digital certificate, ensuring that the certificate was indeed issued by the sales terminal and checking the short validity period of the temporary certificate. If both levels of verification pass, the legality of the sales terminal's identity and the timeliness of the request are confirmed. Immediately afterwards, the key distribution host generates a brand new terminal master key (TMK) as the top-level key shared with the target terminal. To ensure the secure transmission of TMK, the key distribution host uses a temporary public key extracted from a verified temporary digital certificate to encrypt either the TMK itself or an intermediate session key used to encrypt the TMK, generating the first ciphertext. This ensures both strong authentication and the confidentiality of core key materials during transmission.

[0042] Subsequently, the key distribution host uses its own private key to sign the data containing at least the first ciphertext, and sends the first ciphertext, the signed data, and the key distribution host's own second digital certificate to the sales terminal (corresponding to step S3). Specifically, in the secure transmission and source verification stage, the key distribution host needs to securely send the encrypted TMK to the sales terminal and prove the legitimate source of the instruction, including: the key distribution host using the private key corresponding to its own second digital certificate to digitally sign the data containing the first ciphertext and necessary associated information (such as terminal identifier and session number). Then, the key distribution host packages the first ciphertext, the generated digital signature, and the second digital certificate used to verify its identity, and sends it to the sales terminal. Thus, not only is the encrypted key transmitted, but also a basis for verifying the integrity of the instruction and the identity of the sender is provided.

[0043] Further, the sales terminal verifies the validity of the second digital certificate and signature data based on the pre-installed second digital certificate. After successful verification, it decrypts the first ciphertext using the temporary private key corresponding to the temporary public key, obtains the terminal master key, and stores it (corresponding to step S4). Specifically, in the terminal verification and key acquisition stage, after receiving the data packet from the key distribution host, the sales terminal first performs authentication of the sender, including: the sales terminal uses its pre-installed second digital certificate to verify the authenticity of the received second digital certificate. After successful verification, it uses the public key of the second digital certificate to verify the validity of the digital signature, ensuring that the data has not been tampered with during transmission and that it indeed comes from a legitimate key distribution host. After confirming the trustworthiness of the instruction source, the sales terminal uses the temporary private key it generated and securely saved at the beginning of the session to decrypt the first ciphertext, finally obtaining the terminal master key (TMK) and storing it in a secure storage area. Thus, after verifying the legitimacy of the instruction source, the sales terminal securely obtains the top-level key (i.e., the terminal master key) shared with the key distribution host.

[0044] Next, the key distribution host uses its own terminal master key to encapsulate the working key to be injected into a key block and distribute it to the sales terminal (corresponding to step S5). Specifically, during the working key injection phase, both parties have established a trust relationship based on a shared TMK. The key distribution host uses its TMK to encrypt and protect the integrity of the actual working key to be injected (such as the key used to encrypt bank card magnetic stripe data) according to an industry standard format (such as TR-31), encapsulating it into a protected key block. Then, this key block is distributed to the sales terminal. Thus, secure distribution of business keys is achieved under secure top-level key protection.

[0045] Finally, the sales terminal uses the stored terminal master key to decrypt and verify the key block, obtain the working key, and store it (corresponding to step S6). Specifically, during the working key activation phase, the sales terminal uses the securely stored TMK to decrypt the received key block, verify its integrity (e.g., verify the key verification value KCV), and after successful verification, injects the obtained working key into the terminal's hardware security module or secure storage area for subsequent business transactions. This completes a closed loop from identity authentication to secure key transmission and finally successful injection of the business key. The entire process, based on digital certificates and temporary certificates, achieves two-way identity authentication between the key distribution host and the sales terminal, ensuring the legitimacy of the key injection operation entity from the source.

[0046] As described in the background section, existing terminal key injection schemes have the following core technical defects: (1) Lack of identity verification and anti-tampering mechanisms for key injection: Traditional schemes rely on random numbers to prevent replay of injection requests, but random numbers can only ensure the uniqueness of the request, cannot verify the legitimate identity of the injection initiator, and cannot guarantee the data integrity during key transmission, which can easily lead to security risks of key hijacking and tampering. (2) Lack of effective control over key injection permissions: There is a lack of permission restriction mechanism bound to the terminal identity, and any device with an injection channel can initiate a key injection request, which poses security risks of illegal injection of malicious keys and unauthorized operation.

[0047] In view of this, the terminal key injection scheme based on temporary certificates proposed in this application overcomes the problem of lacking an identity certificate verification mechanism. The sales terminal uses its long-term identity certificate (first digital certificate) to issue short-term valid temporary digital certificates, constructing a cryptographic binding of "device long-term identity → session temporary identity." The key distribution host then verifies the identity legitimacy based on the certificate through a strict certificate chain. To simultaneously provide tamper-proof protection and establish a secure channel, the verified temporary certificate public key is used to encrypt key materials, and digital signatures are used to ensure the integrity of transmitted data. Finally, to achieve effective binding of permissions and identity, the entire injection process is executed within the context of the terminal identity verified by the certificate, ensuring accurate matching of key injection permissions. The entire process deeply integrates identity authentication, permission verification, data encryption, and integrity protection.

[0048] Therefore, this application directly establishes a digital certificate-based identity verification system by introducing a two-way identity authentication and chain verification mechanism based on temporary certificates. This overcomes the shortcomings of traditional schemes that rely solely on random numbers for replay protection and are vulnerable to man-in-the-middle attacks, achieving two-way trusted authentication between the key injection requester and receiver, thus ensuring the legitimacy of the operating entity from the source. Simultaneously, by binding the temporary certificate to the terminal's unique identity information and authorizing after verification, effective binding of injection permissions to the terminal's identity is achieved, overcoming the shortcomings of traditional schemes such as vague permission control and susceptibility to unauthorized operations, thus achieving precise permission control. Furthermore, digital signatures and temporary public key encryption technology provide tamper-proof and confidentiality guarantees for key data during transmission. In summary, this application systematically solves the technical problems of insecure injection processes and weak permission control in existing key injection schemes due to the lack of identity certificate-based verification mechanisms and data tamper-proof protection, as well as the failure to effectively bind key injection permissions to the terminal's identity.

[0049] Optionally, the digital certificates configured in the key distribution host and the sales terminal are obtained through the following certificate issuance process: The root certificate authority uses its own root private key to sign the public keys of the first sub-certificate authority and the second sub-certificate authority respectively, generating a first sub-certificate authority digital certificate and a second sub-certificate authority digital certificate. The first sub-certificate authority digital certificate is stored in the first sub-certificate authority, and the second sub-certificate authority digital certificate is stored in the second sub-certificate authority. The first sub-certificate authority uses its first sub-certificate authority private key corresponding to the first sub-certificate authority digital certificate to sign the public key of the key distribution host, generating a second digital certificate. The second digital certificate and the first sub-certificate authority digital certificate are stored together in the key distribution host. The second sub-certificate authority uses its second sub-certificate authority private key corresponding to the second sub-certificate authority digital certificate to sign the public key of the sales terminal, generating a first digital certificate. The first digital certificate and the second sub-certificate authority digital certificate are stored together in the sales terminal.

[0050] In this embodiment of the invention, a specific digital certificate issuance system is provided as the infrastructure for implementing the key injection method based on temporary certificates. This system adopts a hierarchical certificate authority (CA) structure to achieve separation of permissions and scalable management, making it particularly suitable for application scenarios requiring centralized and standardized identity management for a large number of terminals and devices, such as large payment networks or financial terminal management platforms.

[0051] like Figure 2 As shown, firstly, the root certificate authority (Root CA) at the top of the trust chain issues digital certificates to its two specialized sub-certificate authorities. Specifically, the first sub-certificate authority (such as the KDH CA responsible for managing all key distribution hosts) and the second sub-certificate authority (such as the POS CA responsible for managing all point-of-sale (POS) terminals) each generate their own asymmetric key pairs and submit their public keys to the root certificate authority. The root certificate authority uses its strictly offline-stored root private key to sign the public keys and identity information (such as organization name, purpose, etc.) of both sub-certificate authorities, generating the first and second sub-certificate authority digital certificates respectively. Thus, the root certificate authority securely delegates its trusted authority to these two sub-certificate authorities, and the first and second sub-certificate authority digital certificates become their legitimate credentials for future certificate issuance operations. These two sub-certificate authority certificates are securely distributed and stored in the systems of the first and second sub-certificate authorities, respectively.

[0052] After obtaining legitimate identity, the first sub-certificate authority begins fulfilling its responsibilities by issuing identity certificates to key distribution hosts under its jurisdiction. Specifically, when a new key distribution host (such as a bank's new key management system) needs to connect, it generates its own key pair and submits its public key and host identification information to the first sub-certificate authority. The first sub-certificate authority uses its first sub-institution private key, corresponding to its first sub-institution digital certificate, to sign the key distribution host's public key and other information, generating a second digital certificate (i.e., a KDH certificate) for that key distribution host. To ensure that the key distribution host can verify the legitimacy of its certificate in subsequent communications, the first sub-certificate authority provides not only the issued second digital certificate but also its own first sub-institution digital certificate upon delivery. The key distribution host securely stores both certificates together. Thus, the key distribution host obtains a digital identity endorsed by a trusted sub-institution and accompanied by a complete chain of proof (host certificate → sub-institution certificate).

[0053] Furthermore, the second sub-certificate authority is responsible for issuing identity certificates for the sales terminals. Specifically, for each sales terminal to be deployed (such as a POS machine), after generating its own key pair, it submits its public key and unique serial number, among other identity information, to the second sub-certificate authority. The second sub-certificate authority uses its own sub-sub-certificate's private key, corresponding to its sub-sub-certificate, to sign the sales terminal's public key and other information, generating the terminal's first digital certificate (i.e., the POS certificate). Similarly, when delivering the certificate, the second sub-certificate authority provides its own sub-sub-certificate to the sales terminal. The sales terminal securely stores the obtained first and sub-sub-certificate digital certificates in its hardware security module. Thus, each sales terminal obtains a unique, legitimate digital identity endorsed by its dedicated sub-sub-certificate and accompanied by a chain of proof (terminal certificate → sub-sub-certificate).

[0054] Thus, through the multi-level certificate issuance system constructed by the above steps, the key distribution host and the sales terminal each obtain digital certificates issued by different management sub-organizations, all ultimately traceable to the same trusted root certificate authority. This multi-level certificate issuance system not only achieves isolation of issuance responsibility and enhances the flexibility and security of system management, but also lays a solid foundation of trust for two-way identity authentication. When the key distribution host and the sales terminal present their respective certificates during the key injection process, the other party can use the pre-installed root certificate to verify the legitimacy and trustworthiness of the other party's identity by verifying the complete trust chain of "terminal / host certificate → sub-organization certificate → root certificate".

[0055] Optionally, the digital certificates configured in the key distribution host and the sales terminal are obtained through the following certificate issuance process: the root certificate authority uses its own root private key to sign the public key of the key distribution host to generate a second digital certificate, and stores the second digital certificate in the key distribution host; the root certificate authority uses its own root private key to sign the public key of the sales terminal to generate a first digital certificate, and stores the first digital certificate in the sales terminal.

[0056] In this embodiment of the invention, a simpler digital certificate issuance scheme is provided as an optional infrastructure for implementing the temporary certificate-based key injection method. This digital certificate issuance scheme adopts a flat trust model in which a single root certificate authority (Root CA) directly issues certificates to terminal devices. It is particularly suitable for application scenarios with relatively limited system size, centralized management structure, or high requirements for deployment agility, such as payment terminal systems for small and medium-sized merchants, and dedicated device management within closed networks.

[0057] Therefore, as Figure 3 As shown, the root certificate authority (DCA), acting as the sole anchor of trust for the entire system, directly creates identity credentials for the key distribution host. Specifically, after generating its own asymmetric key pair, the key distribution host submits its public key along with host identification information (such as host ID, affiliated authority, etc.) to the DCA. The DCA uses its securely protected root private key to digitally sign the key distribution host's public key and identity information, generating a second digital certificate (i.e., a KDH certificate) for the key distribution host. The issuer of this second digital certificate is directly the DCA. The generated second digital certificate is securely distributed and stored within the key distribution host. Thus, the key distribution host obtains a digital identity directly endorsed by the highest trusted authority, without the need for an intermediate CA certificate.

[0058] Simultaneously, the root certificate authority (DCA) directly creates identity credentials for each point-of-sale (POS) terminal. Specifically, after generating its own key pair, each POS terminal (such as a POS machine) submits its public key and unique serial number, along with other critical identity information, to the DCA. The DCA then uses its root private key to sign the POS terminal's public key and identity information, generating the terminal's first digital certificate (i.e., the POS certificate). This first digital certificate is also issued by the DCA. The generated first digital certificate is securely injected and stored in the secure storage area of ​​the corresponding POS terminal. Thus, each POS terminal obtains a digital certificate directly issued by the DCA and uniquely bound to its hardware identity.

[0059] Thus, through the direct issuance system constructed using the above steps, both the key distribution host and the sales terminal obtain digital certificates directly issued by the same trusted root certificate authority. This flattened trust model simplifies the certificate chain. When verifying the identity of another party, the device only needs to use the same pre-installed root certificate to directly verify whether the signature of the other party's certificate was generated by that root private key, without needing to handle multi-level certificate chains. This reduces the complexity of the device's certificate verification logic and decreases the certificate management steps, facilitating rapid deployment and maintenance. It provides an equally robust but more concise trust foundation for two-way identity authentication, enabling efficient and reliable initiation of certificate-based secure key injection processes in applicable scenarios.

[0060] Optionally, the operation of issuing a temporary digital certificate containing a temporary public key for this session using its own first digital certificate includes: the sales terminal generating a temporary asymmetric key pair for this session, including a temporary public key and a corresponding temporary private key; the sales terminal constructing a structured temporary certificate data body, which includes at least: a temporary public key, a unique serial number of the sales terminal, issuer subject information extracted from the first digital certificate, and a preset validity period; the sales terminal using the private key corresponding to the first digital certificate to digitally sign the temporary certificate data body and generate a digital signature value; and the sales terminal combining the temporary certificate data body and the digital signature value to form a complete temporary digital certificate, and storing the temporary digital certificate and the temporary private key locally.

[0061] In this embodiment of the invention, the specific operation of the sales terminal generating a temporary digital certificate during the key injection session is the core of constructing the independent security context for this session. Its core lies in utilizing the terminal's own long-term identity certificate to create a short-term, verifiable, and identity-bound temporary credential for a one-time session. This mechanism is particularly suitable for dynamic interaction scenarios with strict requirements for session security and identity verification. The detailed process is as follows:

[0062] Upon receiving the injection request from the key distribution host, the sales terminal first generates a temporary asymmetric key pair for this independent communication session. Specifically, within its secure operating environment (such as within a security chip), the sales terminal invokes a cryptographic random number generator to produce a temporary private key used only for this session, and calculates the corresponding temporary public key using standard algorithms such as elliptic curve cryptography or RSA. This key pair is discarded after the session ends, ensuring the temporary nature and forward security of the keys. This establishes a unique encryption and signature foundation for this session.

[0063] After obtaining the temporary key pair, the sales terminal begins to construct the temporary certificate data body to be signed. Specifically, this data body is a structured data set that contains at least the following core fields: (1) the temporary public key for this session, used for subsequent encrypted transmission; (2) the sales terminal's unique serial number, which is an identity identifier read from the terminal hardware or secure storage and consistent with the subject information of the terminal's long-term identity certificate (first digital certificate), used to cryptographically bind the temporary certificate to a specific physical device; (3) the issuer subject information extracted from the first digital certificate, which directly declares that the issuer of this temporary certificate is the sales terminal itself, ensuring the traceability of the source of responsibility; (4) a preset short-term validity period (e.g., from the time of generation to within the next 5 minutes), which strictly limits the validity window of the temporary certificate to prevent the certificate from being replayed or abused for a long time. These fields together form a complete certificate statement containing identity, key, and validity period. Thus, a prototype of a temporary credential with a self-expiration mechanism that is clearly associated with a specific terminal identity and this session is constructed.

[0064] After the certificate data body is constructed, the sales terminal uses its long-term identity credential (i.e., the private key corresponding to the pre-installed first digital certificate) to digitally sign the data body. Specifically, the sales terminal uses its long-term private key to perform a hash operation on the constructed structured data body and then signs it, generating a digital signature value. This signing act is cryptographically equivalent to using the terminal's long-term identity to endorse the temporary certificate, and any verifier can use the public key in the terminal's publicly disclosed first digital certificate to verify this signature. Thus, an authoritative binding and authenticity proof is achieved between the terminal's non-repudiable long-term identity and the temporary identity for this session.

[0065] Finally, the sales terminal combines and encapsulates the constructed temporary certificate data body and the generated digital signature value according to a standard certificate encoding format (such as X.509 format) to form a complete temporary digital certificate that can be processed by standard verification logic. Simultaneously, the sales terminal associates the temporary private key corresponding to this certificate with the temporary digital certificate in a local secure storage area (such as a hardware security module), ensuring that it is only used to decrypt data sent to this session. Thus, the sales terminal completes the entire process of generating and storing the security credentials for this session (including the certificate with the temporary public key and the temporary private key) locally, ready to send the temporary certificate to initiate subsequent authentication processes at any time.

[0066] Thus, through the above steps, the sales terminal dynamically generates a short-term, session-specific temporary digital certificate. This temporary digital certificate not only provides the secure encryption public key for this session but also, by mandating the inclusion of the sales terminal's unique serial number and digitally signing it with the sales terminal's long-term private key, establishes a strong, unforgeable association with the specific terminal's identity at the cryptographic level. This provides a crucial technical prerequisite for the subsequent key distribution host to perform strict, certificate-chain-based two-way authentication, constituting the core mechanism for the entire solution to achieve precise control over identity and permissions.

[0067] Optionally, the key distribution host verifies the authenticity and legitimacy of the first digital certificate and temporary digital certificates step by step based on the pre-set first digital certificate. This includes: the key distribution host using the public key of the pre-set first digital certificate to decrypt and verify the digital signature of the first digital certificate, while verifying whether the complete issuance path of the first digital certificate can be traced back to the first digital certificate, and simultaneously checking whether the version, serial number, validity period, and key usage of the first digital certificate conform to the predefined policy; after the first digital certificate is verified, the key distribution host extracts the corresponding subject identification information from specific fields of the first digital certificate; the key distribution host parses the encoded structure of the temporary digital certificate and obtains the declared issuer subject information, temporary public key, and corresponding... from the specified fields. The temporary digital certificate is used to verify the consistency of the issuer's subject information. The issuer's subject information declared in the temporary digital certificate is matched field-by-field with the subject identifier information extracted from the verified first digital certificate. After the issuer's consistency verification is successful, the key distribution host uses the public key of the verified first digital certificate to perform a signature verification operation on the digital signature of the temporary digital certificate. This verifies whether the digital signature was generated by the private key corresponding to the first digital certificate and verifies the integrity of the temporary digital certificate, thus verifying the authenticity of the digital signature and the integrity of the data. After the digital signature verification is successful, the key distribution host determines, based on the current timestamp, whether the valid time interval declared in the temporary digital certificate includes the current time and confirms whether the length of the valid time interval meets the preset short-lived requirement.

[0068] In this embodiment of the invention, the rigorous, step-by-step verification of the digital certificate submitted by the sales terminal by the key distribution host is the core step in achieving two-way trusted authentication. Its purpose is to use cryptographic means to sequentially confirm the legitimacy of the sales terminal's long-term identity, the authenticity of the temporary certificate's source, the integrity of the data, and the freshness of the session, thereby constructing a secure foundation for a key injection session. This mechanism is particularly suitable for financial security scenarios where the authenticity of the identities of both communicating parties and the reliability of instructions are extremely important.

[0069] Therefore, upon receiving the first digital certificate (i.e., the long-term POS certificate) from the point of sale (POS), the key distribution host first initiates verification of its long-term identity. Specifically, the key distribution host uses the public key from its pre-installed first digital certificate (i.e., the trusted root CA certificate verifying the POS certificate chain) to decrypt and verify the digital signature of the first digital certificate. This process verifies whether the certificate was issued by a legitimate authority within the trusted root CA system. Simultaneously, the key distribution host checks the complete issuance path of the first digital certificate to ensure it is traceable back to the pre-installed first digital certificate, and concurrently checks the certificate's version number, serial number, validity period, and key usage extension fields to ensure it conforms to the system's predefined policies (e.g., the certificate must be valid, and the key usage must include a digital signature). Thus, at the certificate level, the long-term legitimate identity and current validity of the POS entity are confirmed.

[0070] After the initial digital certificate is verified, the key distribution host extracts its Subject Distinguished Name. Subsequently, the key distribution host parses the encoded structure of the temporary digital certificate (e.g., ASN.1 DER encoding) and extracts three key pieces of information from its specified fields: the declared issuer subject information, the temporary public key for this session, and the validity period of the certificate claim. The core verification involves the key distribution host performing a precise, field-by-field comparison between the declared issuer subject information in the temporary certificate and the Subject Distinguished Name extracted from the verified initial digital certificate. This confirms that the temporary digital certificate logically claims to have been issued by the currently verified specific sales terminal, completing a closed-loop consistency verification from the verified terminal identity to the source of the temporary certificate claim.

[0071] After the issuer's consistency verification passes, the key distribution host uses the public key from the verified first digital certificate to perform a signature verification operation on the digital signature of the temporary digital certificate. Specifically, the key distribution host recalculates the hash value of the temporary certificate's data body and uses the public key of the first digital certificate to decrypt the signature value for comparison. This operation verifies that the digital signature of the temporary certificate was indeed generated by the private key corresponding to the first digital certificate (i.e., the long-term private key of the sales terminal), and that the data body of the temporary certificate was not tampered with during transmission. Thus, at the cryptographic level, the authenticity and data integrity of the temporary certificate are confirmed, meaning that the temporary certificate was indeed issued by the claimed legitimate sales terminal and its content is complete.

[0072] Finally, the key distribution host performs mandatory verification of the temporary certificate's core security attribute (i.e., validity). Specifically, the key distribution host obtains the current precise system timestamp and determines whether this time falls within the valid time interval declared by the temporary digital certificate. Simultaneously, the key distribution host confirms whether the total length of this valid time interval (e.g., end time minus start time) meets the system's preset short-lived requirement (e.g., no more than 5 minutes). This step ensures that the temporary certificate is not an old certificate issued in the past, nor a certificate with an excessively wide time window, effectively defending against certificate replay attacks. Thus, it injects freshness into this key injection session, ensuring the session's real-time nature and security.

[0073] Through the step-by-step, multi-dimensional verification chain constructed by the above steps, the key distribution host not only verifies the static legitimacy of the sales terminal but also dynamically and rigorously confirms the authenticity, integrity, and real-time nature of the temporary credential for this session. This elevates traditional one-way or weak authentication to a robust, interconnected authentication system based on cryptographic evidence, laying a solid foundation of trust for the subsequent encrypted transmission of key materials. This directly reflects the improved overall security level of this solution.

[0074] Optionally, the key distribution host generates the terminal master key through the following steps: The key distribution host obtains the unique serial number of the sales terminal and performs standardized encoding processing on the unique serial number to obtain the first data block; The key distribution host obtains the current precise timestamp and extracts the numerical bits of the current precise timestamp with a preset precision to obtain the second data block; The key distribution host generates a random number as the third data block; The key distribution host uses a preset fixed salt value bound to the identity of the key distribution host as the fourth data block; The key distribution host concatenates the first, second, third, and fourth data blocks in a preset order to form combined seed data; The key distribution host inputs the combined seed data into a cryptographic hash function for one-way hash calculation to obtain an intermediate digest value; The key distribution host uses the intermediate digest value as input key material, inputs it into the first key derivation function and specifies the derived key length as the target length of the terminal master key, performs key derivation calculation, and finally outputs the terminal master key.

[0075] In this embodiment of the invention, the specific process by which the key distribution host generates the Terminal Master Key (TMK) is a crucial step in building session security. It aims to dynamically generate a high-strength, unique key that is strongly associated with a specific terminal and session, based on multi-source entropy materials and standard cryptographic algorithms. This mechanism is particularly suitable for financial key management systems that have strict requirements for the unpredictability, uniqueness, and anti-derivation properties of keys.

[0076] Therefore, the key distribution host first collects and preprocesses entropy source materials for key generation from different dimensions. Specifically, the key distribution host performs the following steps: (1) Obtain and process the terminal identifier, that is, obtain its unique serial number from the target sales terminal information of this key injection request, and perform standardized encoding processing on the serial number (such as converting it into a byte array of uniform length, or performing normalized string encoding) to obtain the first data block. This ensures the strong binding of the key to a specific terminal device. (2) Obtain and process the time factor, that is, obtain the current precise timestamp (such as UTC time, accurate to milliseconds), and extract the numerical bits of the preset precision (for example, extract the numerical value representing "year, month, day, hour, minute, second", ignoring the millisecond part) to obtain the second data block. This injects a time factor into the key, ensuring that the keys generated at different times are different. (3) Generate a random factor, that is, under the protection of a secure random number generator, generate a cryptographically secure random number as the third data block. This provides the core of the unpredictability of the key. (4) Introduce a system-specific factor, that is, call a preset fixed salt value bound to the identity of the key distribution host as the fourth data block. This fixed salt value is typically associated with a host certificate or system identifier and is used to bind the generated key to a specific key management system, preventing cross-system key deduction attacks. This completes the preparation and formatting of entropy source material from four independent dimensions: device, time, randomness, and system.

[0077] Subsequently, the key distribution host concatenates the four data blocks (the first to the fourth data blocks) in a preset, predetermined order to form a complete combined seed data. This order is part of the algorithm, and for example, but not limited to, concatenation in the order of "fourth data block (fixed salt value) → first data block (terminal serial number) → second data block (timestamp) → third data block (random number)" to ensure the reproducibility of the generation process.

[0078] Next, the key distribution host inputs the combined seed data into a cryptographic hash function (such as SHA-256) for one-way hash calculation. The purpose of this step is to: (1) obfuscate and compress, that is, to convert multiple input data of different lengths and formats into a fixed-length intermediate digest value without statistical characteristics; (2) disrupt the input structure, that is, to ensure that the final key does not directly expose any information of the original input data, and even if some input entropy values ​​are weak, the overall strength can be improved after hashing; (3) provide a uniform input for subsequent key derivation. Thus, a high-strength, uniformly distributed intermediate value is generated as an ideal starting point for key derivation.

[0079] Finally, the key distribution host uses the intermediate digest value obtained in the previous step as input key material and feeds it into a first key derivation function. This key derivation function is a standard algorithm specifically designed to generate strong cryptographic keys from non-uniform or short entropy sources, such as HKDF (HMAC-based Key Derivation Function). The key distribution host specifies the required key length to be derived as the length of the target terminal master key (e.g., 128 bits or 256 bits) and performs the key derivation calculation. This function iteratively expands the input material through a pseudo-random function (usually HMAC) over multiple rounds, ultimately outputting a terminal master key of the specified length and high cryptographic strength. Thus, a complete process driven by multi-source entropy, processed through a standardized cryptographic procedure, and ultimately generating a high-quality session master key is completed.

[0080] Through the above steps, the terminal master key (TMK) generated by the key distribution host possesses the following key security attributes: uniqueness (due to the combination of the terminal's unique serial number, precise timestamp, and random number); unpredictability (due to the inclusion of cryptographic random numbers processed by hashing and KDF); and strong context association (due to binding to a specific terminal, the current session time, and a specific key management system). Therefore, this scheme abandons simple key storage and retrieval in its terminal master key generation process, adopting a dynamic generation mode that significantly improves the security of the key injection process. It is an effective design to combat key leakage and deduction attacks, providing top-level key protection for the secure distribution of working keys.

[0081] Optionally, the key distribution host encrypts the session key used to encrypt the terminal master key using a temporary public key to form the first ciphertext through the following steps: the key distribution host obtains the current time's timestamp from the system clock as a time factor; the key distribution host generates a cryptographically secure random number as a random factor; the key distribution host concatenates the time factor and the random factor to form session key seed data; the key distribution host inputs the session key seed data into a second key derivation function to derive a session key of a specified length; the key distribution host uses the session key to encrypt the terminal master key using a symmetric encryption algorithm to generate terminal master key ciphertext; and uses the temporary public key to encrypt the session key using an asymmetric encryption algorithm to generate session key ciphertext; the key distribution host combines the session key ciphertext and the terminal master key ciphertext according to a preset encapsulation format to form the first ciphertext.

[0082] In this embodiment of the invention, the key distribution host utilizes a verified temporary public key to construct a secure hybrid encryption structure to protect the transmission of the Terminal Master Key (TMK) to the sales terminal. This is the core of implementing efficient and highly secure key distribution, and its design adopts best practices in cryptography: using the secure key distribution capabilities of asymmetric encryption to protect a high-strength session key, and then using the efficient symmetric encryption capabilities of this session key to protect the actual master key data, thereby achieving an optimal balance between security and performance. This mechanism is a classic and effective solution to address the challenge of secure transmission of key materials in untrusted channels.

[0083] Therefore, to ensure that the encryption key used in each session is unique and unpredictable, the key distribution host first generates a session key specifically for this encrypted transmission. Specifically, the key distribution host obtains a high-precision timestamp of the current moment from the system clock as a time factor and generates a random factor using a cryptographically secure random number generator. These two factors are concatenated to form the session key seed data. This seed data is then input into a second key derivation function (e.g., another HKDF instance different from the one used to generate the TMK) to derive a session key of a specified length (e.g., 128 bits or 256 bits). This step, by combining time (ensuring uniqueness) with cryptographic randomness (ensuring unpredictability) and strengthening it with a standardized key derivation function, generates a high-quality temporary symmetric key.

[0084] After obtaining the session key, the key distribution host performs the core double encryption operation: (1) Symmetric encryption protection of TMK, that is, the key distribution host uses the session key generated in the previous step to encrypt the previously generated terminal master key (TMK) through an efficient symmetric encryption algorithm (such as AES-GCM mode). This operation generates terminal master key ciphertext, which, while TMK is protected by the session key, also provides data integrity and authenticity verification through GCM mode. (2) Asymmetric encryption protection of the session key, that is, to ensure that the session key itself can be securely transmitted to the sales terminal, the key distribution host uses the temporary public key extracted from the verified temporary digital certificate to encrypt the session key through an asymmetric encryption algorithm (such as RSA-OAEP or an elliptic curve-based encryption scheme). This operation generates session key ciphertext, which can only be decrypted by the sales terminal holding the corresponding temporary private key. Thus, two ciphertext layers are constructed: the inner layer is TMK protected by the session key, and the outer layer is the session key protected by the terminal temporary public key.

[0085] Finally, the key distribution host combines the generated session key ciphertext with the terminal master key ciphertext according to a preset, standardized encapsulation format. For example, the format can be simply defined as the sequential concatenation of the two ciphertexts, or it can use a more structured TLV (Type-Length-Value) encoding. The encapsulation result is the first ciphertext. This formatted combination ensures that the receiver (sales terminal) can clearly parse the two parts and process them in the correct order (i.e., first decrypt the outer layer to obtain the session key, then use the session key to decrypt the ciphertext to obtain the TMK).

[0086] Through the encrypted transmission mechanism constructed using the steps described above, the key distribution host achieves secure encapsulation of the terminal master key. This encrypted transmission mechanism provides multiple security safeguards: First, in the final transmitted ciphertext, both the terminal master key and its protection key (session key) exist in ciphertext form, eliminating the risk of plaintext transmission. Second, a hybrid encryption architecture is employed, utilizing asymmetric encryption to ensure the reliable distribution of the session key and leveraging symmetric encryption to achieve efficient and strong protection of the terminal master key. Furthermore, the generation of the session key incorporates a time factor and cryptographic random numbers, ensuring the key's timeliness and uniqueness, achieving a one-time pad security level. In terms of efficiency, this encrypted transmission mechanism restricts the computationally expensive asymmetric encryption operation to short-length session keys, while employing high-performance symmetric encryption for the data subject (terminal master key), thereby optimizing overall computational and communication efficiency while ensuring security. This design provides direct and reliable technical support for building a secure communication channel and achieving secure and efficient key transmission for the entire scheme.

[0087] Furthermore, it should be specifically noted that the specific cryptographic algorithms used in the embodiments of this invention to encrypt the terminal master key or its protection key using a temporary public key can be implemented in various ways that conform to industry standards. The selection and substitution of these specific algorithms do not affect the implementation of the core solution of this invention and should be covered within the scope of protection of this patent. Specifically, the encryption method includes, but is not limited to, the following optional implementations:

[0088] (1) Traditional asymmetric encryption: The traditional RSA algorithm can be used directly to encrypt the terminal master key (TMK) or session key using a temporary public key.

[0089] (2) RSA-based hybrid encryption and standard encapsulation: An enhanced RSA encapsulation method can be adopted. In this method, a temporary AES-128 key is first generated as the session key; then, the AES-128 key is encrypted and encapsulated using the RSA-OAEP padding scheme (specifying the MGF1 mask generation function and SHA-256 hash algorithm) and the temporary public key; finally, the protected terminal master key (TMK) is organized according to the standard key block format such as TR-31, and encrypted using the aforementioned AES-128 key as the protection key for the key block.

[0090] (3) Key negotiation and enhanced encryption based on elliptic curve cryptography (ECC): To support stronger key strength, elliptic curve cryptography can be used. In this approach, the key distribution host and the sales terminal can use the ECDH (Elliptic Curve Diffie-Hellman) key negotiation protocol (e.g., following the X9.63 standard) to derive a shared AES-256 key using their respective local private keys and the other party's remote public key (i.e., temporary public key) (using hash algorithms such as SHA-256). This AES-256 key will be used as a session key or directly as a protection key in the TR-31 standard key block format to encrypt the terminal master key (TMK).

[0091] The changes and selections of the above encryption methods are all equivalent replacements or optimizations of the specific technical means to achieve the same inventive concept of "protecting key key materials with temporary public keys". They do not deviate from the authentication and secure transmission framework based on temporary certificates proposed in this invention, and therefore all fall within the scope of protection of this patent.

[0092] Furthermore, in this application, the first key derivation function (used to derive the terminal master key from the combined seed data) and the second key derivation function (used to derive the session key from the session key seed data) both refer to key derivation function modules conforming to cryptographic standards. The core difference between the two lies in the different uses of the input materials and the output key, rather than the necessity of using different algorithms. In practical implementation, they can (but are not required to) be two independent instances of the same key derivation algorithm (e.g., HKDF), serving the generation of the terminal master key and the session key respectively. This design ensures key independence at each stage while maintaining flexibility in system implementation.

[0093] In summary, this application has the following beneficial effects:

[0094] (1) Significantly enhanced security protection layers: This application takes temporary certificate authentication as the core security boundary. Compared with the traditional scheme that relies on random numbers, it adds identity verification based on digital certificate chain and data integrity protection capabilities based on digital signature. By constructing a step-by-step verification chain of "Root Certificate Authority (Root CA) → Terminal Certificate Authority (Terminal CA) → Temporary Certificate", it realizes strong authentication of the injection requester's identity and anti-tampering verification of instructions, which greatly reduces the security risks of key hijacking, tampering and illegal injection during transmission.

[0095] (2) Improved injection efficiency and resource utilization: This application simplifies the redundant verification process in traditional schemes that is highly dependent on the specific operating environment, focusing on core identity authentication links such as efficient and standard certificate verification and signature verification. The fast verification mechanism based on the trusted certificate chain can filter out illegal or unauthorized injection requests in real time, reducing the amount of invalid communication data, certificate transmission and unnecessary verification operations, reducing the overall resource consumption of the system, thereby improving the response speed and processing efficiency of the legitimate key injection process.

[0096] (3) Precise Access Control: Temporary digital certificates are deeply bound to the digital certificate and unique serial number of the point of sale (POS) terminal itself upon issuance. The verification process of the temporary certificate by the key distribution host (KDH) is also the process of confirming the legitimate identity of the terminal. This ensures that the scope of key injection permissions automatically and accurately matches the verified terminal identity, thereby preventing unauthorized injection operations beyond permissions or across devices and achieving automated and precise control from identity to permissions.

[0097] In addition, refer to Figure 1 As shown, according to a second aspect of this embodiment, a storage medium is provided. The storage medium includes a stored program, wherein, when the program is executed, a processor performs any of the methods described above.

[0098] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0099] Example 2

[0100] This embodiment provides a terminal key injection system based on temporary certificates, including a key distribution host configured with digital certificates and a sales terminal. The key distribution host and sales terminal are configured as follows: In response to a key injection request sent by the key distribution host, the sales terminal generates a pair of temporary asymmetric keys, uses its own first digital certificate to issue a temporary digital certificate containing a temporary public key for the current session, and sends the first digital certificate and the temporary digital certificate to the key distribution host; the key distribution host verifies the authenticity and legality of the first digital certificate and the temporary digital certificate level by level based on the pre-set first digital certificate, generates a terminal master key after successful verification, and uses the temporary public key to encrypt the terminal master key or to encrypt the terminal. The session key of the master key is encrypted to form the first ciphertext. The key distribution host uses its own private key to sign data containing at least the first ciphertext, and sends the first ciphertext, the signature data, and the key distribution host's own second digital certificate to the sales terminal. The sales terminal verifies the validity of the second digital certificate and the signature data based on the pre-set second digital certificate. After successful verification, it uses the temporary private key corresponding to the temporary public key to decrypt the first ciphertext, obtain the terminal master key, and store it. The key distribution host uses its own terminal master key to encapsulate the working key to be injected into a key block and sends it to the sales terminal. The sales terminal uses the stored terminal master key to decrypt and verify the key block, obtain the working key, and store it.

[0101] Optionally, the digital certificates configured in the key distribution host and the sales terminal are obtained through the following certificate issuance process: The root certificate authority uses its own root private key to sign the public keys of the first sub-certificate authority and the second sub-certificate authority respectively, generating a first sub-certificate authority digital certificate and a second sub-certificate authority digital certificate. The first sub-certificate authority digital certificate is stored in the first sub-certificate authority, and the second sub-certificate authority digital certificate is stored in the second sub-certificate authority. The first sub-certificate authority uses its first sub-certificate authority private key corresponding to the first sub-certificate authority digital certificate to sign the public key of the key distribution host, generating a second digital certificate. The second digital certificate and the first sub-certificate authority digital certificate are stored together in the key distribution host. The second sub-certificate authority uses its second sub-certificate authority private key corresponding to the second sub-certificate authority digital certificate to sign the public key of the sales terminal, generating a first digital certificate. The first digital certificate and the second sub-certificate authority digital certificate are stored together in the sales terminal.

[0102] It should be noted that the terminal key injection system based on temporary certificates provided in this embodiment can implement all the functions and steps in the above method embodiments, solve the same technical problems, and achieve the same technical effects. The similarities will not be repeated here.

[0103] Therefore, according to this embodiment, by introducing a two-way identity authentication and chain verification mechanism based on temporary certificates, a digital certificate-based identity verification system is directly established. This overcomes the shortcomings of traditional schemes that rely solely on random numbers for replay protection but cannot verify identity and are vulnerable to man-in-the-middle attacks. It achieves two-way trusted authentication between the key injection requester and the receiver, ensuring the legitimacy of the operating entity from the source. Simultaneously, by binding the temporary certificate to the terminal's unique identity information and authorizing after verification, effective binding of injection permissions to the terminal's identity is achieved. This overcomes the shortcomings of traditional schemes, such as vague permission control and susceptibility to unauthorized operations, achieving precise permission control. Furthermore, digital signatures and temporary public key encryption technology provide tamper-proof and confidentiality guarantees for key data during transmission. In summary, this application systematically solves the technical problems of insecure injection processes and weak permission control in existing key injection schemes due to the lack of identity certificate-based verification mechanisms and data tamper-proof protection, as well as the failure to effectively bind key injection permissions to the terminal's identity.

[0104] The above description is only a preferred embodiment of the present invention. It should be noted 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 terminal key injection method based on temporary certificates, characterized in that, The method, applied between a key distribution host configured with a digital certificate and a point-of-sale terminal, includes: In response to the key injection request sent by the key distribution host, the sales terminal generates a pair of temporary asymmetric keys, uses its own first digital certificate to issue a temporary digital certificate containing the temporary public key for this session, and sends the first digital certificate and the temporary digital certificate to the key distribution host. The key distribution host verifies the authenticity and legality of the first digital certificate and the temporary digital certificate step by step based on the pre-set first digital certificate. After the verification is passed, it generates the terminal master key and uses the temporary public key to encrypt the terminal master key or the session key used to encrypt the terminal master key to form the first ciphertext. The key distribution host uses its own private key to sign data containing at least the first ciphertext, and sends the first ciphertext, the signed data, and the key distribution host's own second digital certificate to the sales terminal. The sales terminal verifies the validity of the second digital certificate and signature data based on the pre-installed second digital certificate. After successful verification, it decrypts the first ciphertext using the temporary private key corresponding to the temporary public key, obtains the terminal master key, and stores it. The key distribution host uses its own terminal master key to encapsulate the working key to be injected into a key block and distribute it to the sales terminal; The sales terminal uses the stored terminal master key to decrypt and verify the key block, obtain the working key, and store it.

2. The method according to claim 1, characterized in that, The digital certificates configured in the key distribution host and point-of-sale terminal are obtained through the following certificate issuance process: The root certificate authority uses its own root private key to sign the public keys of the first sub-certificate authority and the second sub-certificate authority respectively, generating digital certificates for the first and second sub-certificate authorities. The first sub-certificate authority digital certificate is stored in the first sub-certificate authority, and the second sub-certificate authority digital certificate is stored in the second sub-certificate authority. The first sub-certificate authority uses the private key of the first sub-certificate corresponding to the first sub-certificate digital certificate to sign the public key of the key distribution host, generate a second digital certificate, and store the second digital certificate and the first sub-certificate digital certificate together in the key distribution host; The second sub-certificate authority uses the private key of the second sub-certificate corresponding to the digital certificate of the second sub-certificate to sign the public key of the sales terminal, generate the first digital certificate, and store the first digital certificate and the digital certificate of the second sub-certificate together in the sales terminal.

3. The method according to claim 1, characterized in that, The digital certificates configured in the key distribution host and point-of-sale terminal are obtained through the following certificate issuance process: The root certificate authority uses its own root private key to sign the public key of the key distribution host, generating a second digital certificate, and then stores the second digital certificate on the key distribution host. The root certificate authority uses its own root private key to sign the public key of the sales terminal, generating the first digital certificate, and then stores the first digital certificate on the sales terminal.

4. The method according to claim 1, characterized in that, The operation of issuing a temporary digital certificate containing a temporary public key for this session using one's own primary digital certificate includes: The point of sale generates a temporary asymmetric key pair for this session, including a temporary public key and a corresponding temporary private key; The sales terminal constructs a structured temporary certificate data body, which includes at least: a temporary public key, a unique serial number of the sales terminal, issuer subject information extracted from the first digital certificate, and a preset validity period. The point of sale uses the private key corresponding to the first digital certificate to digitally sign the temporary certificate data body and generate a digital signature value. The sales terminal combines the temporary certificate data body with the digital signature value to form a complete temporary digital certificate, and stores the temporary digital certificate and temporary private key locally.

5. The method according to claim 4, characterized in that, The key distribution host verifies the authenticity and legitimacy of the first digital certificate and temporary digital certificates step by step based on the pre-installed first digital certificate, including: The key distribution host uses the public key of the pre-installed first digital certificate to decrypt and verify the digital signature of the first digital certificate. At the same time, it verifies whether the complete issuance path of the first digital certificate can be traced back to the first digital certificate, and simultaneously checks whether the version, serial number, validity period and key usage of the first digital certificate comply with the predefined policy. After the first digital certificate is verified, the key distribution host extracts the corresponding subject identification information from a specific field of the first digital certificate; The key distribution host parses the encoded structure of the temporary digital certificate, retrieves the issued subject information, temporary public key and corresponding validity period declared in the specified fields, and matches the issued subject information declared in the temporary digital certificate with the subject identifier information extracted from the verified first digital certificate field by field to verify the consistency of the issuer. After the issuer's consistency verification is passed, the key distribution host uses the public key of the verified first digital certificate to perform a signature verification operation on the digital signature of the temporary digital certificate. This verifies whether the digital signature was generated by the private key corresponding to the first digital certificate and verifies the integrity of the temporary digital certificate, thereby verifying the authenticity of the digital signature and the integrity of the data. After the digital signature verification is successful, the key distribution host determines whether the valid time interval declared in the temporary digital certificate includes the current time based on the current timestamp, and confirms whether the length of the valid time interval meets the preset short-lived requirement.

6. The method according to claim 1, characterized in that, The key distribution host generates the terminal master key through the following steps: The key distribution host obtains the unique serial number of the sales terminal and performs standardized encoding on the unique serial number to obtain the first data block; The key distribution host obtains the current precise timestamp and extracts the numerical bits of the current precise timestamp with a preset precision to obtain the second data block; The key distribution host generates a random number as the third data block; The key distribution host uses a pre-set fixed salt value, which is bound to the key distribution host's identity, as the fourth data block; The key distribution host concatenates the first data block, the second data block, the third data block, and the fourth data block in a preset order to form combined seed data; The key distribution host inputs the combined seed data into a cryptographic hash function to perform one-way hash calculation and obtain the intermediate digest value; The key distribution host takes the intermediate digest value as the input key material, inputs it into the first key derivation function, and specifies the derived key length as the target length of the terminal master key. It then performs key derivation calculations and finally outputs the terminal master key.

7. The method according to claim 6, characterized in that, The key distribution host encrypts the session key, which is used to encrypt the terminal master key, using the temporary public key to form the first ciphertext through the following steps: The key distribution host obtains the current time's timestamp from the system clock and uses it as a time factor; The key distribution host generates a cryptographically secure random number as a random factor; The key distribution host concatenates the time factor and the random factor to form the session key seed data; The key distribution host inputs the session key seed data into the second key derivation function to derive a session key of a specified length; The key distribution host uses the session key to encrypt the terminal master key using a symmetric encryption algorithm, generating the terminal master key ciphertext. And using a temporary public key, the session key is encrypted using an asymmetric encryption algorithm to generate the session key ciphertext; The key distribution host combines the session key ciphertext and the terminal master key ciphertext according to a preset encapsulation format to form the first ciphertext.

8. A storage medium, characterized in that, The storage medium includes a stored program, wherein, when the program is executed, the method described in any one of claims 1 to 7 is performed by a processor.

9. A terminal key injection system based on temporary certificates, characterized in that, This includes a key distribution host and a point-of-sale terminal configured with digital certificates, and the key distribution host and point-of-sale terminal are configured as follows: In response to the key injection request sent by the key distribution host, the sales terminal generates a pair of temporary asymmetric keys, uses its own first digital certificate to issue a temporary digital certificate containing the temporary public key for this session, and sends the first digital certificate and the temporary digital certificate to the key distribution host. The key distribution host verifies the authenticity and legality of the first digital certificate and the temporary digital certificate step by step based on the pre-set first digital certificate. After the verification is passed, it generates the terminal master key and uses the temporary public key to encrypt the terminal master key or the session key used to encrypt the terminal master key to form the first ciphertext. The key distribution host uses its own private key to sign data containing at least the first ciphertext, and sends the first ciphertext, the signed data, and the key distribution host's own second digital certificate to the sales terminal. The sales terminal verifies the validity of the second digital certificate and signature data based on the pre-installed second digital certificate. After successful verification, it decrypts the first ciphertext using the temporary private key corresponding to the temporary public key, obtains the terminal master key, and stores it. The key distribution host uses its own terminal master key to encapsulate the working key to be injected into a key block and distribute it to the sales terminal; The sales terminal uses the stored terminal master key to decrypt and verify the key block, obtain the working key, and store it.

10. The system according to claim 9, characterized in that, The digital certificates configured in the key distribution host and point-of-sale terminal are obtained through the following certificate issuance process: The root certificate authority uses its own root private key to sign the public keys of the first sub-certificate authority and the second sub-certificate authority respectively, generating digital certificates for the first and second sub-certificate authorities. The first sub-certificate authority digital certificate is stored in the first sub-certificate authority, and the second sub-certificate authority digital certificate is stored in the second sub-certificate authority. The first sub-certificate authority uses the private key of the first sub-certificate corresponding to the first sub-certificate digital certificate to sign the public key of the key distribution host, generate a second digital certificate, and store the second digital certificate and the first sub-certificate digital certificate together in the key distribution host; The second sub-certificate authority uses the private key of the second sub-certificate corresponding to the digital certificate of the second sub-certificate to sign the public key of the sales terminal, generate the first digital certificate, and store the first digital certificate and the digital certificate of the second sub-certificate together in the sales terminal.

Images