A method and system for secure injection of a POS terminal operating key and a storage medium

Abstract

The application discloses a POS terminal working key security injection method, system and storage medium. The method comprises the following steps: after a key loading device and a POS terminal establish a physical connection, performing bidirectional certificate authentication, exchanging certificates and verifying identities, exchanging random numbers, time stamps and generating a MAC containing the random number of the opposite party to bind the session; after authentication, both sides generate a temporary key pair respectively, exchange public keys and calculate a shared secret value based on an elliptic curve algorithm to derive a temporary session key; the device encapsulates the working key into a standard key block using the key and transmits the standard key block to the terminal; the terminal verifies the integrity of the key block, decrypts and extracts the working key, and stores the working key after verifying the correctness. Through bidirectional authentication and MAC binding, illegal access and replay attacks are prevented, the temporary key negotiation realizes plug and play without pre-shared key and forward security, standard encapsulation and threefold verification ensure key integrity and compliance, the working key can be safely injected for the first time, and single session leakage does not affect others.

Description

Technical Field

[0001] This invention belongs to the field of payment terminal security technology, and in particular relates to a secure injection method, system and storage medium for a POS terminal working key. Background Technology

[0002] As the core acceptance device for financial transactions, the secure injection of working keys into POS terminals is a crucial step in ensuring transaction security. Traditional key injection methods typically rely on dedicated hardware terminals and pre-shared keys, requiring POS terminals to be transported back to a key management center or technicians to bring pre-configured key equipment to the site for injection, resulting in high costs for hardware maintenance, updates, and technical support. In recent years, remote key injection solutions have emerged, enabling offline key distribution through network communication between the server and the POS terminal, alleviating the efficiency problem of offline injection to some extent. However, existing remote injection solutions generally use server-side-led RSA public key encryption or pre-configured basic derived keys (BDKs) to transmit working keys, essentially still relying on pre-shared keys or fixed key materials, failing to achieve plug-and-play functionality when the key loading device first connects to an unfamiliar POS terminal. Furthermore, existing solutions lack session-level key isolation mechanisms, as session keys are associated with long-term key materials; leakage of long-term keys will jeopardize all past and future sessions. In addition, audit logs are mostly stored at the host operating system level, posing a risk of tampering or forgery, and failing to meet the stringent requirements of financial security standards such as PCI PIN for operational traceability and non-repudiation. Summary of the Invention

[0003] (a) Purpose of the invention To overcome the above shortcomings, the present invention aims to provide a secure injection method, system and storage medium for POS terminal working keys, so as to solve the technical problems of existing POS key injection schemes relying on pre-shared keys or fixed key materials, which cannot achieve plug-and-play functionality for first-time connection of unfamiliar devices, and lacking session-level key isolation and tamper-proof audit traceability mechanisms.

[0004] (II) Technical Solution To achieve the above objectives, this application provides the following technical solution: A secure injection method for a POS terminal working key includes the following steps: Step 1: After the key loading device and the POS terminal establish a connection through a physical line, they perform two-way certificate authentication, exchange their respective device certificates and verify the legitimacy of each other's identities. During the authentication process, they exchange the first random number and the first timestamp, and use the signing private key to generate a message authentication code containing the other party's random number to bind the same session. Step 2: After successful authentication, the key loading device and the POS terminal generate temporary key pairs, exchange temporary public keys, calculate the shared secret value based on the elliptic curve key negotiation algorithm, and derive a temporary session key based on the shared secret value, random numbers from both parties, and timestamps. Step 3: The key loading device uses a temporary session key to encapsulate the working key to be injected into a standard key block, which is then transmitted to the POS terminal via a physical line; Step 4: After receiving the standard key block, the POS terminal uses the temporary session key to verify the integrity of the standard key block and decrypts it to extract the working key. After verifying the correctness of the working key, it stores it in the secure storage area.

[0005] A two-way certificate authentication mechanism ensures the authenticity and trustworthiness of the device identity between the key loading device and the POS terminal, preventing unauthorized device access. During authentication, the exchanged random numbers and timestamps, along with the message authentication code generated by the signature private key, bind both parties to the same session, preventing attackers from impersonating legitimate devices by recording and replaying legitimate communication data. After successful authentication, the method uses elliptic curve temporary key pairs for key negotiation. Each session independently generates a temporary key pair and derives a unique temporary session key, achieving secure channel establishment without pre-shared keys and ensuring no mathematical correlation between the temporary session key and the long-term key material for a single session. Based on this, the method uses the temporary session key to standardly encapsulate the working key before transmission. Before importing, the POS terminal sequentially verifies the integrity of the encapsulation block, the correctness of the working key, and the legitimacy of the key's purpose, ensuring the received key is complete and error-free and will not be misused in other security scenarios. These four steps work together to enable the POS terminal to securely inject the working key upon its first connection to the key loading device, and the leakage of a key in a single POS terminal session will not affect the security of injection operations on other terminals or in other batches.

[0006] In some embodiments, step one, the two-way certificate authentication specifically includes: The key loading device sends a first device certificate chain, a first random number, a first timestamp, and a first message authentication code generated by using a first signature private key to the first random number and the first timestamp to the POS terminal. The POS terminal verifies the integrity, validity period, and revocation status of the first device certificate chain, verifies whether the first device certificate is in the pre-configured whitelist, and verifies the first message authentication code; After successful verification, the POS terminal returns a second device certificate chain, a second random number, a second timestamp, and a second message authentication code generated by using the second signature private key to the second random number, the second timestamp, and the first random number to the key loading device. The key loading device verifies the second device certificate chain and the second message authentication code, and confirms that the second message authentication code contains a first random number.

[0007] This authentication process achieves two-way identity verification between the key loading device and the POS terminal. Verification of the device certificate chain ensures that the device certificate originates from a trusted root certificate authority and has not been revoked within its validity period. A pre-configured whitelist mechanism further restricts acceptance to key loading device certificates issued by specific authorities, effectively defending against attacks from unauthorized devices holding other legitimate certificates. The first message authentication code is generated by the key loading device's signing private key. Verifying this authentication code by the POS terminal confirms that the key loading device indeed holds the private key corresponding to the certificate, ensuring the authenticity of the message source and that the content has not been tampered with during transmission. The second message authentication code returned by the POS terminal contains the first random number sent by the key loading device. This binding mechanism allows the key loading device to confirm that the POS terminal's authentication response is for the current session and not a replay of a previously recorded session.

[0008] In some embodiments, in step two, the temporary key pair is destroyed by the hardware clearing circuit of its respective built-in security module after the shared secret value calculation is completed.

[0009] The temporary key pair is destroyed immediately by a hardware zeroing circuit after the shared secret value calculation is completed, ensuring that the temporary private key never leaves the trusted boundary of the security module and exists only for the short period required for the calculation. Even if an attacker subsequently obtains the device's long-term key material through physical or software means, they cannot deduce the temporary session key negotiated in historical sessions, thus ensuring that the security of each key injection operation is independent.

[0010] In some embodiments, in step two, the method for deriving the temporary session key is as follows: using a shared secret value, random numbers from both parties, timestamps from both parties, and a predetermined string as input parameters, and using the hash value of the concatenated temporary public keys from both parties as the salt value, a key derivation function is used to generate the temporary session key.

[0011] This derivation method uses the hash value of the concatenated temporary public keys of both parties as the salt, ensuring the uniqueness of the salt across different sessions. Combined with the shared secret value, random numbers from both parties, timestamps from both parties, and a predefined string, the derivation input ensures that the temporary session key derived for each session is globally unique. Even if the shared secret value of a session is leaked for some reason, an attacker cannot deduce the temporary session keys for other sessions because the random numbers, timestamps, and temporary public keys for each session are different and unpredictable.

[0012] In some embodiments, in step three, the standard key block is a key block conforming to the TR-31 standard. The key block includes a key block header, encrypted key data, and an authentication code. The key block header records the purpose identifier and algorithm identifier of the working key, and the authentication code is calculated and generated by the temporary session key pair with the key block header and encrypted key data.

[0013] The working key is encapsulated using a key block format conforming to the TR-31 standard, ensuring that it exists in a standardized and secure structure during transmission from the key loading device to the POS terminal. The purpose identifier and algorithm identifier recorded in the key block header give the working key self-describing capabilities. The POS terminal can determine the intended security scenario and algorithm for which the key is used based on the header information. The authentication code covers both the key block header and the encrypted key data. Any tampering with the key block header or the encrypted data will cause the authentication code verification to fail, resulting in the POS terminal recognizing and rejecting the authentication.

[0014] In some embodiments, step four, in which the POS terminal verifies the integrity of the standard key block, specifically includes: recalculating the authentication code using the temporary session key to the received key block header and encrypted key data, comparing it with the authentication code in the standard key block, and confirming the integrity if they match. Verifying the correctness of the working key includes: calculating the key check value of the decrypted working key and comparing it with the key check value carried in the standard key block; The POS terminal also parses the purpose identifier and algorithm identifier in the key block header. Only after confirming that the purpose and algorithm of the working key are consistent with expectations can storage be allowed.

[0015] The POS terminal employs a triple verification mechanism to ensure the security and reliability of the imported working key: authentication code verification confirms that the key block has not been tampered with since being issued by the key loading device; key checksum verification confirms that the decrypted and recovered working key matches the working key generated by the key loading device; and the parsing and verification of the purpose identifier and algorithm identifier prevent the working key from being imported into incorrect usage or algorithm scenarios. Storage is only permitted after all three verifications pass, effectively preventing the POS terminal from importing incorrect or unexpected working keys due to transmission errors, device malfunctions, or malicious attacks.

[0016] In some embodiments, in steps one to four, all cryptographic operations involving private key generation, shared secret value calculation, key encapsulation and decapsulation are completed within the security boundary of the security module, and the physical line only transmits the device certificate, temporary public key and encapsulated ciphertext data.

[0017] Sensitive cryptographic operations such as private key generation, shared secret value calculation, key encapsulation and decapsulation are all completed within the security boundaries of the security module. The private key, temporary private key, shared secret value, and working key plaintext never enter the host operating system's visible memory space at any time. The data transmitted over the physical line consists only of device certificates, temporary public keys, and encapsulated ciphertext data. Even if the physical line is intercepted or an attacker gains complete control of the host operating system, all that can be obtained is public information or ciphertext data; no plaintext key can be extracted.

[0018] In some embodiments, an audit log recording step is also included: The key loading device and the POS terminal each record audit logs in their respective secure storage areas. The audit logs include operation timestamps, operator identifiers, device identifiers, session parameters, key verification values ​​of the working key, and operation results. The audit logs are digitally signed by the device's unique private key for each security module, and the host operating system has no right to access or modify the audit logs.

[0019] Both the key loading device and the POS terminal record audit logs in their respective secure storage areas, which are then signed by a security module. This ensures that all critical information from each key injection operation is immutably preserved, preventing malicious software or unauthorized operations at the host operating system level from deleting or falsifying log records. Complete records of fields such as operation timestamp, operator identifier, device identifier, session parameters, working key verification value, and operation result allow auditors to trace the operator, time, involved devices, and final injection result of each key injection operation, meeting the requirements of financial security standards such as PCI PIN for dual-person control and operation traceability.

[0020] Another aspect of this application provides a system for a key loading device to securely inject a working key into a POS terminal, comprising: The key loading device has a built-in first security module for generating working keys, initiating two-way certificate authentication, performing temporary key negotiation, and encapsulating working keys into standard key blocks. The POS terminal has a built-in second security module for performing two-way certificate authentication, performing temporary key negotiation, receiving and decrypting standard key blocks to extract and store working keys; The physical line is used to connect the key loading device and the POS terminal to transmit device certificates, temporary public keys and standard key blocks; The system executes any of the methods mentioned above.

[0021] Both the key loading device and the POS terminal have built-in independent security modules, ensuring that sensitive operations such as key generation, certificate authentication, key negotiation, and key encapsulation and decapsulation are completed within their respective security modules. The plaintext working key remains encapsulated and protected throughout transmission. The key loading device acts as the key generation source and negotiation initiator, while the POS terminal acts as the key receiver. Connected directly via a physical line and employing the aforementioned method, they form a complete on-site secure injection system for POS terminal working keys. This system enables plug-and-play functionality for initial connection of unfamiliar POS terminals without the need for a pre-shared key.

[0022] In another aspect, this application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the methods described above.

[0023] When the computer program stored on the storage medium is executed by the processor, it can control the key loading device and the POS terminal to cooperate in completing the entire process of two-way certificate authentication, temporary key negotiation, working key encapsulation and transmission, and import verification. This enables general computing devices to execute the above-mentioned POS terminal working key security injection method after installing the storage medium, which facilitates the system upgrade and function expansion of existing devices. Attached Figure Description

[0024] Figure 1 This is a flowchart of the secure injection method for the POS terminal working key of the present invention. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments and the accompanying drawings. It should be understood that these descriptions are merely exemplary and not intended to limit the scope of the invention. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concept of the invention.

[0026] The present invention provides a secure injection method for a POS terminal working key. The core of this method lies in the cooperation of four links: two-way certificate authentication, temporary key negotiation, standard key block encapsulation, and security boundary isolation, to achieve plug-and-play functionality for the first connection between the key loading device and an unfamiliar POS terminal without a pre-shared key.

[0027] This method is executed collaboratively by a key loading device and a POS terminal. The key loading device has a built-in first security module, and the POS terminal has a built-in second security module. The two devices are physically connected via a USB cable, RS-232 serial cable, or Ethernet direct connection cable. Preferably, the physical line uses shielded cable no longer than two meters to reduce the risk of physical layer signal eavesdropping or interference. As an alternative, fiber optic cable can be used in scenarios with complex electromagnetic environments. All sensitive cryptographic operations involving private key generation, shared secret value calculation, key encapsulation, and decapsulation are completed within the security boundaries of their respective security modules. The security modules are specifically hardware security modules that comply with PCI HSM or FIPS 140-2 Level 3 and above. The host operating system can only access device certificates, temporary public keys, and encapsulated ciphertext data, but cannot access any private keys, temporary private keys, shared secret values, or plaintext working keys. This security module also has a physical tamper-proof protection mesh, which triggers the automatic destruction of internal sensitive data once a physical intrusion attempt is detected.

[0028] The first embodiment of the method will be described in detail below with reference to steps one through four.

[0029] In step one, after the key loading device and the POS terminal establish a connection via a physical line, two-way certificate authentication is performed. Specifically, the key loading device first sends a first device certificate chain, a first random number, and a first timestamp to the POS terminal, and simultaneously uses a first signing private key to generate a first message authentication code from the first random number and the first timestamp. After receiving the above information, the POS terminal performs triple verification on the first device certificate chain: verifying the integrity of the certificate chain, i.e., whether the hierarchical signature chain from the root certificate authority through intermediate certificate authorities to the terminal entity certificate is complete and valid; verifying whether the certificate is valid and whether it has been revoked, which can be achieved through online certificate status protocol queries or comparison with certificate revocation lists; and verifying whether the first device certificate is on the whitelist pre-configured by the Key Infrastructure (KIF), i.e., only key loading device certificates issued by specific KIF authorities are accepted, and even if an attacker holds a certificate issued by another legitimate certificate authority, it cannot pass the whitelist check. In addition, the POS terminal also verifies the first message authentication code to confirm that the key loading device does indeed hold the signing private key corresponding to the first device certificate and that the message content has not been tampered with during transmission. Upon successful verification, the POS terminal immediately records the operation audit log of this authentication success event in its local secure storage area. Subsequently, the POS terminal returns a second device certificate chain, a second random number, and a second timestamp to the key loading device, and uses the second signing private key to generate a second message authentication code using the second random number, the second timestamp, and the first random number. Upon receiving this information, the key loading device verifies the integrity and validity of the second device certificate chain, verifies the second message authentication code, and confirms that the second message authentication code indeed contains the first random number it sent in step one. This two-way authentication process ensures that both parties connected on the physical line are genuine devices holding valid certificates and corresponding private keys. Because the second message authentication code returned by the POS terminal is bound to the first random number sent by the key loading device, the key loading device can confirm that the POS terminal's authentication response is for the current session and not a replay of a historically recorded session.

[0030] Preferably, the verification of the first and second timestamps uses an acceptable time window of plus or minus five minutes, and messages exceeding this window will be discarded directly; as an alternative, in network environments with high clock synchronization accuracy, a strict time window of plus or minus one minute can also be used.

[0031] In step two, after successful authentication, the key loading device and the POS terminal each generate a temporary key pair. Specifically, the first security module of the key loading device generates a first temporary key pair, containing a first temporary private key and a first temporary public key; the second security module of the POS terminal generates a second temporary key pair, containing a second temporary private key and a second temporary public key. After exchanging their respective temporary public keys, both parties calculate a shared secret value based on the elliptic curve key negotiation algorithm. Specifically, the first security module calculates the shared secret value using its own first temporary private key and the received second temporary public key, and the second security module calculates the shared secret value using its own second temporary private key and the received first temporary public key; both yield the same mathematically. Based on this, both parties use the shared secret value, their respective random numbers, their respective timestamps, and a predetermined string as input parameters, and the hash value of the concatenated temporary public keys as the salt, to generate a temporary session key using a key derivation function. Preferably, the elliptic curve key negotiation algorithm uses the X25519 curve, which is a Montgomery curve and has constant-time implementation characteristics, effectively resisting side-channel attacks. As an alternative, the P-256 curve can also be used in environments requiring NIST standard compliance. Preferably, the key derivation function uses the HKDF-SHA256 algorithm; as an alternative, a key derivation function based on the Chinese national cryptographic algorithm SM3 can also be used. Based on this, the first security module immediately destroys the first temporary private key via a hardware zeroing circuit after calculating the shared secret value, and the second security module immediately destroys the second temporary private key via a hardware zeroing circuit after calculating the shared secret value. This hardware zeroing circuit ensures that the temporary private key cannot be recovered through cold-start attacks or other memory residue analysis methods by writing all-zero data to the memory unit storing the temporary private key and performing multiple overwrite operations.

[0032] In step three, the key loading device uses the temporary session key derived in step two to encapsulate the working key to be injected into a standard key block. Specifically, this standard key block conforms to the TR-31 standard, a key block standard format specifically using Version D and employing the AES-256 algorithm for key encapsulation. This key block contains three components: a key block header, encrypted key data, and an authentication code. The key block header records the purpose identifier and algorithm identifier of the working key—the purpose identifier specifically includes types such as PIN encryption, PIN decryption, MAC generation, and data encryption; the algorithm identifier includes algorithm types such as AES, TDES, and ECC—giving the key block self-describing capabilities. The encrypted key data includes the ciphertext of the working key encrypted with the temporary session key, the key checksum of the working key, and padding data in PKCS#7 format. The authentication code is generated by calculating AES-CMAC from the concatenated value of the key block header and encrypted key data using the temporary session key; this authentication code covers both the header and the ciphertext data. After encapsulation, the key loading device transmits the key block header, encrypted key data, and authentication code to the POS terminal via a physical line. Upon completion of the transmission, the key loading device immediately destroys the temporary session key and the first temporary private key to ensure that no temporary key materials remain in the device.

[0033] In step four, after receiving the standard key block, the POS terminal performs a triple verification to ensure the security and reliability of the imported working key. The first verification is integrity verification: the POS terminal uses the temporary session key it holds from step two to recalculate the authentication code on the received key block header and encrypted key data. It then compares the recalculated authentication code with the authentication code carried in the standard key block. If they match, it confirms that the key block has not been tampered with during transmission. The second verification is key correctness verification: after decrypting the encrypted key data using the temporary session key to extract the plaintext working key, the POS terminal calculates the key checksum of the working key. Specifically, it calculates the CMAC value of the working key and takes the first six bytes as the key checksum. This calculated key checksum is compared with the key checksum carried in the standard key block. If they match, it confirms that the decrypted and recovered working key is completely consistent with the working key generated by the key loading device. The third verification step is to verify the legality of the purpose: The POS terminal parses the purpose identifier and algorithm identifier recorded in the key block header to confirm that the intended purpose and algorithm of the working key are consistent with the key type that the POS terminal currently needs to import. For example, if the POS terminal currently needs to import a PIN encryption key but the purpose identifier recorded in the key block header is a data encryption key, the POS terminal will refuse to import the key. After all three verifications pass, the POS terminal stores the working key in a designated key slot in the secure storage area. Preferably, this secure storage area is a non-volatile random access memory with physical protection inside the security module. Even if the POS terminal is powered off, the working key is still securely stored and cannot be read by the host operating system. As an alternative, the secure storage area can also be a one-time programmable memory or secure flash memory inside the security module.

[0034] It is worth noting that throughout the entire process from steps one to four, all cryptographic operations involving private key generation, shared secret value calculation, key encapsulation, and decapsulation are completed within the security boundaries of the security module. Specifically, the signing private key of the key loading device, the signing private key of the POS terminal, the temporary private keys of both parties, the ECDH shared secret value, and the plaintext of the working key do not enter the host operating system's memory space at any point in the entire process. The data that the host operating system can access is limited to the device certificate, the temporary public key, and the encapsulated ciphertext block. This means that even if the physical line is intercepted or the attacker completely controls the host operating system, all that can be obtained is public information or ciphertext data, and no plaintext key can be extracted.

[0035] Building upon the key injection process described above, this method further includes an audit log recording step. Specifically, the first security module of the key loading device and the second security module of the POS terminal each record audit logs in their respective secure storage areas. Each audit log entry contains the following fields: operation start and end timestamps, operator identifier, key loading device serial number and certificate fingerprint, POS terminal serial number and certificate fingerprint, session parameters (including random numbers for both parties and temporary public keys for both parties), key verification value and purpose identifier and algorithm identifier of the working key, and the result of the key injection operation. After being written to the secure storage area, the audit log is digitally signed by the unique signing private key of each security module, ensuring the log's source is trustworthy and its content is tamper-proof. Because the audit logs are stored in the non-volatile secure storage area of ​​the security modules, the host operating system has no right to access or modify any log records. Preferably, the security modules also maintain an incrementing counter, which automatically increments each time an audit log is written. This counter value is also used as one of the inputs for log signing, further preventing the logs from being deleted or rearranged. In actual operation and maintenance, the key loading device and POS terminal can periodically send audit logs back to the KIF central audit system through a secure channel for reconciliation and anomaly detection, thereby meeting the stringent requirements of financial security standards such as PCI PIN for dual-person control and operation traceability.

[0036] Another aspect of the present invention provides a system for securely injecting a working key into a POS terminal using a key loading device. The system includes a key loading device, a POS terminal, and a physical line. The key loading device has a built-in first security module for generating a working key, initiating two-way certificate authentication, performing temporary key negotiation, and encapsulating the working key into a standard key block. The POS terminal has a built-in second security module for performing two-way certificate authentication, performing temporary key negotiation, receiving and decrypting the standard key block to extract and store the working key. The physical line connects the key loading device and the POS terminal for transmitting device certificates, temporary public keys, and the standard key block. The system executes all the process steps described in any of the above method embodiments. Through the deployment of this system, plug-and-play functionality can be achieved for the first connection of unfamiliar POS terminals without a pre-shared key. The same key loading device can serve multiple POS terminals sequentially, with each session independently negotiating a temporary session key. A key leak in one POS terminal will not affect the security of other terminals.

[0037] Another aspect of the present invention provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program controls a key loading device and a POS terminal to cooperate in completing all the process steps described in any of the above-described method embodiments, including: two-way certificate authentication, temporary key negotiation, working key encapsulation and transmission, and import verification. The storage medium may be in the form of a secure digital card, a read-only memory in an embedded security chip, or a secure storage device conforming to the Universal Serial Bus interface specification. Through this storage medium, a general-purpose computing device, after installing the storage medium, possesses the ability to execute the above-described POS terminal working key secure injection method, facilitating system upgrades and functional expansion of existing devices.

[0038] It should be understood that the specific embodiments described above are merely illustrative or explanatory of the principles of the invention and do not constitute a limitation thereof. Therefore, any modifications, equivalent substitutions, improvements, etc., made without departing from the spirit and scope of the invention should be included within the protection scope of the invention. Furthermore, the appended claims are intended to cover all variations and modifications falling within the scope and boundaries of the appended claims, or equivalent forms of such scope and boundaries.

Claims

1. A secure injection method for a POS terminal working key, characterized in that, Includes the following steps: Step 1: After the key loading device and the POS terminal establish a connection through a physical line, they perform two-way certificate authentication, exchange their respective device certificates and verify the legitimacy of each other's identities. During the authentication process, they exchange the first random number and the first timestamp, and use the signing private key to generate a message authentication code containing the other party's random number to bind the same session. Step 2: After successful authentication, the key loading device and the POS terminal generate temporary key pairs, exchange temporary public keys, calculate a shared secret value based on the elliptic curve key negotiation algorithm, and derive a temporary session key based on the shared secret value, random numbers from both parties, and timestamps. Step 3: The key loading device uses the temporary session key to encapsulate the working key to be injected into a standard key block, and transmits it to the POS terminal through the physical line; Step 4: After receiving the standard key block, the POS terminal uses the temporary session key to verify the integrity of the standard key block and decrypts and extracts the working key. After verifying the correctness of the working key, it stores it in the secure storage area. In step one, the two-way certificate authentication specifically includes: The key loading device sends a first device certificate chain, a first random number, a first timestamp, and a first message authentication code generated by using a first signature private key to the POS terminal; The POS terminal verifies the integrity, validity period, and revocation status of the first device certificate chain, verifies whether the first device certificate is in the pre-configured whitelist, and verifies the first message authentication code. After successful verification, the POS terminal returns to the key loading device a second device certificate chain, a second random number, a second timestamp, and a second message authentication code generated using the second signature private key on the second random number, the second timestamp, and the first random number; The key loading device verifies the second device certificate chain and the second message authentication code, and confirms that the second message authentication code contains the first random number.

2. The method according to claim 1, characterized in that, In step two, the temporary key pairs are destroyed by the hardware clearing circuit of their respective built-in security modules after the shared secret value is calculated.

3. The method according to claim 1, characterized in that, In step two, the method for deriving the temporary session key is as follows: using the shared secret value, random numbers from both parties, timestamps from both parties, and a predetermined string as input parameters, and using the hash value of the concatenated temporary public keys from both parties as the salt value, the temporary session key is generated using a key derivation function.

4. The method according to claim 1, characterized in that, In step three, the standard key block is a key block conforming to the TR-31 standard. The key block includes a key block header, encrypted key data, and an authentication code. The key block header records the purpose identifier and algorithm identifier of the working key. The authentication code is calculated and generated by the temporary session key using the key block header and the encrypted key data.

5. The method according to claim 4, characterized in that, In step four, the POS terminal verifies the integrity of the standard key block by: recalculating the authentication code using the temporary session key on the received key block header and encrypted key data, comparing it with the authentication code in the standard key block, and confirming the integrity if they match. The verification of the correctness of the working key includes: calculating the key verification value of the decrypted working key and comparing it with the key verification value carried in the standard key block; The POS terminal also parses the purpose identifier and algorithm identifier in the key block header, and only allows storage after confirming that the purpose and algorithm of the working key are consistent with expectations.

6. The method according to claim 2, characterized in that, In steps one through four, all cryptographic operations involving private key generation, shared secret value calculation, key encapsulation and decapsulation are completed within the security boundary of the security module. The physical line only transmits the device certificate, temporary public key, and encapsulated ciphertext data.

7. The method according to claim 2, characterized in that, It also includes the audit log recording steps: The key loading device and the POS terminal each record audit logs in their respective secure storage areas. The audit logs include operation timestamps, operator identifiers, device identifiers, session parameters, key verification values ​​of the working key, and operation results. The audit logs are digitally signed by the device's unique private key for each security module, and the host operating system has no right to access or modify the audit logs.

8. A system for securely injecting a working key into a POS terminal using a key loading device, for performing the method according to any one of claims 1-7, characterized in that, include: The key loading device has a built-in first security module for generating working keys, initiating two-way certificate authentication, performing temporary key negotiation, and encapsulating the working keys into standard key blocks. The POS terminal has a built-in second security module for performing two-way certificate authentication, performing temporary key negotiation, receiving and decrypting the standard key block to extract and store the working key; A physical line is used to connect the key loading device and the POS terminal to transmit device certificates, temporary public keys, and standard key blocks.

9. A computer-readable storage medium, characterized in that, The device contains a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 7.

Images