A design method of a POS machine remote key filling protocol based on TR34 specification

Abstract

The application relates to the technical field of POS machine key filling, in particular to a design method of a POS machine remote key filling protocol based on TR34 specification, in which bidirectional identity authentication is realized between a terminal device and a server through PKI technology, asymmetric encryption and signature technology are used to negotiate a transmission key Kn, and a session key Kn is used to realize subsequent key transmission protection. A complete RKI process is divided into three stages of Init, KeyTransport and KeyLoading. In the Init stage, the generation process of the first RT KRD of the Bind stage and the first step of the KeyTransport stage in the standard TR34 protocol specification is integrated; in the KeyTransport stage, a core transmission key is negotiated by KDH and KRD and is used for key issuing in the subsequent KeyLoading stage; in the KeyLoading stage, the KDH encrypts the key to be issued subsequently by using the negotiated transmission key Kn, the KRD decrypts the key ciphertext issued by the KDH by using the same transmission key Kn and installs the key, and the whole RKI process is completed. The application optimizes the protocol process on the basis of the TR34 protocol, improves the execution efficiency of the RKI, and reduces the number of certificates in the system.

Description

Technical Field

[0001] This invention relates to the field of POS machine key filling technology, specifically a design method for a POS machine remote key filling protocol based on the TR34 specification. Background Technology

[0002] According to Kirkhoff's principle, the security of a cryptographic system must never rely on the cryptographic algorithm; security depends on the secrecy of the key. In the POS industry, the core issue of financial transaction security is how to ensure the security of the transaction key throughout its entire lifecycle. Traditional key installation methods for POS products typically require the use of a dedicated KLD (Key Loader Device) in a secure environment (KIF) at the factory or repair center for centralized local key injection (Direct Key Injection, DKI). This manual operation is complex, requires a secure environment, and is costly. Therefore, more and more customers are turning to the more convenient and equally secure remote key injection method (Remote Key Injection, RKI). This involves deploying the POS directly to the end merchant's environment and remotely connecting to a key server (RKMS) via the network to inject and update financial transaction keys.

[0003] It has the advantages of high production efficiency and convenient maintenance. However, since remote key filling using the RKI method requires key transmission over an open network, a robust security protocol needs to be designed.

[0004] Remote key filling protocols distribute keys between POS terminals and server backends, involving a wide range of applications. Currently, major domestic banks and equipment manufacturers have launched their own RKI solutions, and the market lacks a standardized and unified protocol implementation. Internationally, the American National Standards Institute (ANSI) has developed a mature TR34 protocol specification for remote key filling, which details the protocol implementation for distributing symmetric keys using asymmetric technology, and provides recommended format specifications for key filling messages (KT) to achieve secure symmetric key exchange.

[0005] The TR34 standard protocol has not yet been widely adopted in the domestic POS industry, mainly due to the following two shortcomings in its standard specifications:

[0006] Its core transmission key, used for distributing subsequent keys, is generated by the server and encrypted with the POS terminal certificate public key. After being distributed, the POS terminal needs to use the corresponding private key to decrypt it. In asymmetric algorithms such as RSA, the computational cost of private key operations is several times that of public key operations. The terminal's efficiency in using asymmetric private key decryption to install symmetric keys is low.

[0007] According to the testing specifications of the Commercial Cryptography Testing Center of the State Cryptography Administration of my country, systems performing two-way authentication and key distribution on open networks require a dual-certificate mechanism. This means that a signature certificate for identity authentication and an encryption certificate for key encryption must be two different certificates. This necessitates that each POS terminal using the TR34 standard must have at least two device certificates (one for signing messages and one for encrypting and decrypting the temporary transmission key KE). This significantly increases the maintenance costs for the CA (Certificate Authority) issuance system of POS terminal manufacturers, requiring the injection of two device certificates into each device during manufacturing and maintenance.

[0008] To address the two shortcomings mentioned above, this invention optimizes the protocol process based on the TR34 protocol, thereby resolving the two deficiencies, improving the execution efficiency of RKI, and reducing the number of certificates in the system. Summary of the Invention

[0009] To address the aforementioned issues, this invention provides a design method for a POS machine remote key filling protocol based on the TR34 specification.

[0010] To achieve the above-mentioned technical objectives, the technical solution adopted by this invention is as follows:

[0011] A design method for a POS machine remote key filling protocol based on the TR34 specification is presented. In the RKI, the terminal device (KRD) and the server (KDH) achieve two-way authentication through PKI technology, negotiate and generate a transmission key Kn using asymmetric encryption and signature technology, and use a session key Kn to protect the subsequent key transmission.

[0012] Furthermore, the RKI process is divided into three stages: Init, KeyTransport, and KeyLoading.

[0013] Init phase: The first step (RT) of the Bind phase and KeyTransport phase in the standard TR34 protocol specification. KRD The generation process is integrated;

[0014] KeyTransport phase: KDH and KRD negotiate the core transport key, which is used for key distribution in the subsequent KeyLoading phase;

[0015] KeyLoading stage: KDH uses the negotiated transport key Kn to encrypt the key to be issued later, and KRD uses the same transport key Kn to decrypt the ciphertext of the key issued by KDH and install it, completing the entire RKI process.

[0016] Furthermore, the Init phase integrates the Bind phase and the first step of the KeyTransport phase in the standard TR34 protocol specification, namely the generation of the RTKRD. The specific steps are as follows:

[0017] S101: KRD initiates an RKI request

[0018] KRD generates a random number R. KRD RT is generated after signing with the KRD certificate private key. KRD Together with KRD certificate CT KRD Pack them together and send them to KDH;

[0019] S102: KDH receives RKI verification request

[0020] KDH verification CT KRD Certificate, and use CT KRD Certificate Verification RT KRD Signature confirms the legitimacy of the terminal;

[0021] S103: KDH stores KRD certificates

[0022] KDH saves the KRD certificate locally for verification of the KT during the subsequent KeyTransport phase. KRD sign;

[0023] S104: KDH generates RKI request and response

[0024] KDH generates a random number R. KDH Using KDH signing certificate CT KDH_Auth RT is generated after signing with the private key. KDH Together with KDH signing certificate CT KDH_Auth and KDH encryption certificate CT KDH_Enc Pack them together and send them to KRD;

[0025] S105: KRD verifies KDH_Auth, KDH_Enc certificates and RT KDH sign

[0026] KRD verifies the validity of the KDH_Auth and KDH_Enc certificates and uses CT. KDH_Auth Certificate Verification RT KDH sign;

[0027] S106: KRD saves R KDH KDH_Auth and KDH_Enc certificates

[0028] KRD saves R KDHStore the KDH_Auth and KDH_Enc certificates locally for use in generating the KT during the subsequent KeyTransport phase. KRD Message.

[0029] Furthermore, in the KeyTransport phase: KDH and KRD negotiate a core transport key, which is used for key distribution in the subsequent KeyLoading phase; the specific steps are as follows:

[0030] S201: KRD generates the transmission key Kn for this key distribution;

[0031] S202: KRD generates a temporary encryption key K E ;

[0032] S203: KRD generates ciphertext key packet

[0033] KRD constructs a key packet containing version, terminal ID, key packet header, and transmission key Kn, and uses K... E Encrypt it to generate a ciphertext key packet BE;

[0034] S204: KRD uses the KDH key to encrypt the temporary encryption key K E

[0035] KRD uses the KDH encryption certificate CT saved during the Init phase. KDH_Enc Public key encryption K E ;

[0036] S205: KRD constructs the final key filling protocol message KT KRD

[0037] KRD constructs KT according to the CMS encrypted envelope format specification defined in PKCS#7. KRD ;

[0038] S206: KDH parsing and verification of KT KRD And install Kn

[0039] KDH receives KT KRD Then, following the PKCS#7 specification format, its content was parsed and compared with R. KDH The value is verified using the public key certificate of the KRD stored in the S103 phase of the Init process, and the EncryptedKey is decrypted using the private key corresponding to the KDH encryption certificate to obtain the K value. E Then use K E Decrypt BE to obtain the final transmission key Kn.

[0040] Furthermore, in S203, BE = E KE (Version||ID KRD_CRED||Kn||KBH).

[0041] Furthermore, in S205, KT KRD =R KDH ||KBH||EncryptedKey||BE||S KRD (R KDH ||KBH||EncryptedKey||BE)||CRL CA_KRD .

[0042] Furthermore, in S204, KRD uses the KDH encryption certificate CTKDH_Enc public key stored in the Init phase to encrypt KE; EncryptedKey = E KDH (K E ).

[0043] Based on the above, the present invention also provides a computer-readable storage medium storing at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, at least one program, code set, or instruction set is loaded and executed by a processor to implement the above-described method for implementing the POS remote key filling protocol based on the TR34 specification.

[0044] The novel RKI protocol proposed in this invention, based on the standard TR34 specification, has the core design idea of ​​adjusting the RKI key filling protocol process. Instead, the KRD terminal generates Kn and encrypts it using the server's public key certificate, returning the key. The server is then responsible for decrypting and restoring the key using the KDH private key. This has the following beneficial effects:

[0045] 1) The performance burden of asymmetric private key operations is shifted from the POS terminal to the cloud with stronger computing power. The POS terminal only needs to handle relatively simple public key operations, reducing the terminal's computing cost. As a result, a lower-cost chip solution can be selected to implement the RKI function.

[0046] 2) After the protocol process is adjusted, the terminal only needs to have one terminal signing certificate built in, which reduces the size of the certificate in the whole system and effectively reduces the maintenance cost of POS terminal certificate. Attached Figure Description

[0047] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0048] Figure 1 This is a schematic diagram of the process of the present invention;

[0049] Figure 2 This is a block diagram of the RKI system in this invention;

[0050] Figure 3 This is a schematic diagram of the TR34 standard protocol flow. Detailed Implementation

[0051] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to represent selected embodiments of the invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0052] The existing standard TR34 specification defines KRD (Key Receiving Device) as the terminal receiving the injected key, and KDH (Key Distribution Host) as the server distributing the key. During the Bind process phase before key loading, both exchange and verify each other's public key certificates and store them locally. In the KeyTransport phase, KDH uses the KRD's public key to encrypt and distribute the transmission key Kn. In the KeyLoading phase, KDH and KRD use the transmission key Kn to perform encrypted key distribution. The complete protocol flow is attached. Figure 3 As shown in Table 1 below, the detailed implementation steps of the core KeyTransport phase are as follows:

[0053] Table 1

[0054]

[0055]

[0056] A1: KRD generates terminal random numbers

[0057] KRD generates a random number R. KRD And after signing with the KRD certificate, a token for this RKI process is generated: RT KRD Send it to KDH.

[0058] B1: KDH receiver terminal random number

[0059] KDH receives RT KRD Verify its signature and obtain the terminal random number R. KRD And save it locally.

[0060] B2: Generate the transmission key to be distributed.

[0061] KDH generates a symmetric algorithm type transmission key Kn.

[0062] B3: Generate a temporary encryption key

[0063] KDH generates a temporary symmetric encryption key K. E .

[0064] B4: Generate ciphertext key packet

[0065] KDH constructs a key packet containing version, terminal ID, key packet header, and transport key Kn, and uses Kn... E Encrypt it to generate a ciphertext key packet BE, the structure of which is as follows:

[0066] BE=EKE(Version||IDKDH_CRED||Kn||KBH)

[0067] B5: Encrypt temporary encryption key

[0068] KDH uses the public key of the KRD certificate stored in the Bind phase to encrypt K E :

[0069] EncryptedKey::=E KRD (K E )

[0070] B6: Construct the final key filling protocol message KT KDH

[0071] KDH assembles KT according to the CMS encrypted envelope format specification defined in PKCS#7. KDH Its structure is as follows:

[0072] KT KDH =R KRD ||KBH||EncryptedKey||BE||S KDH (R KRD ||KBH||EncryptedKey||

[0073] BE)||CRL CA_KDH

[0074] A2: KRD parsing and verification of KT KDH And install Kn

[0075] KRD receives KT KDH Then, following the PKCS#7 specification format, its content was parsed and compared with R. KRD The value is verified using the KDH public key certificate, and the EncryptedKey is decrypted using the private key corresponding to the KRD certificate to obtain the K value. E Then use KE to decrypt BE to obtain the final transmission key Kn.

[0076] After completing the above steps, during the KeyLoading phase, KRD and KDH use Kn to encrypt and distribute subsequent working keys.

[0077] The aforementioned standard TR34 protocol has several drawbacks, including low efficiency in decrypting and installing symmetric keys using asymmetric private keys on terminals, and the requirement that each POS terminal using the standard TR34 protocol must have at least two device certificates.

[0078] To address this, this invention provides a design method for a POS machine remote key loading protocol based on the TR34 specification. In the RKI, the terminal device (KRD) and the server (KDH) achieve two-way authentication via PKI technology, negotiate and generate a transmission key Kn using asymmetric encryption and signature technology, and use a session key Kn to protect subsequent key transmission. The RKI process consists of three stages: Init, KeyTransport, and KeyLoading.

[0079] Init phase: The first step (RT) of the Bind phase and KeyTransport phase in the standard TR34 protocol specification. KRD The generation process is integrated; the specific steps are as follows:

[0080] S101: KRD initiates an RKI request

[0081] KRD generates a random number R. KRD RT is generated after signing with the KRD certificate private key. KRD Together with KRD certificate CT KRD Pack them together and send them to KDH;

[0082] S102: KDH receives RKI verification request

[0083] KDH verification CT KRD Certificate, and use CT KRD Certificate Verification RT KRD Signature confirms the legitimacy of the terminal;

[0084] S103: KDH stores KRD certificates

[0085] KDH saves the KRD certificate locally for verification of the KT during the subsequent KeyTransport phase. KRD sign;

[0086] S104: KDH generates RKI request and response

[0087] KDH generates a random number R. KDH Using KDH signing certificate CT KDH_Auth RT is generated after signing with the private key. KDH Together with KDH signing certificate CT KDH_Auth and KDH encryption certificate CT KDH_Enc Pack them together and send them to KRD;

[0088] S105: KRD verifies KDH_Auth, KDH_Enc certificates and RT KDH sign

[0089] KRD verifies the validity of the KDH_Auth and KDH_Enc certificates and uses CT. KDH_Auth Certificate Verification RT KDH sign;

[0090] S106: KRD saves R KDH KDH_Auth and KDH_Enc certificates

[0091] KRD saves R KDH Store the KDH_Auth and KDH_Enc certificates locally for use in generating the KT during the subsequent KeyTransport phase. KRD Message.

[0092] KeyTransport phase: KDH and KRD negotiate the core transport key, which is used for key distribution in the subsequent KeyLoading phase; the specific steps are as follows:

[0093] S201: KRD generates the transmission key Kn for this key distribution;

[0094] S202: KRD generates a temporary encryption key K E

[0095] S203: KRD generates ciphertext key packet

[0096] KRD constructs a key packet containing version, terminal ID, key packet header, and transmission key Kn, and uses K... E Encrypt it to generate a ciphertext key packet BE;

[0097] BE = E KE (Version||ID KRD_CRED ||Kn||KBH)

[0098] S204: KRD uses the KDH key to encrypt the temporary encryption key K E

[0099] KRD uses the KDH encryption certificate CT saved during the Init phase. KDH_Enc Public key encryption K E ;

[0100] EncryptedKey=E KDH (K E )

[0101] S205: KRD constructs the final key filling protocol message KT KRD

[0102] KRD constructs KT according to the CMS encrypted envelope format specification defined in PKCS#7. KRD KT KRD =R KDH ||KBH||EncryptedKey||BE||S KRD (R KDH ||KBH||EncryptedKey||BE)||CRL CA_KRD

[0103] S206: KDH parsing and verification of KT KRD And install Kn

[0104] KDH receives KT KRD Then, following the PKCS#7 specification format, its content was parsed and compared with R. KDH The value is verified using the public key certificate of the KRD stored in the S103 phase of the Init process, and the EncryptedKey is decrypted using the private key corresponding to the KDH encryption certificate to obtain the K value. E Then use K E Decrypt BE to obtain the final transmission key Kn.

[0105] KeyLoading stage: KDH uses the negotiated transport key Kn to encrypt the key to be issued later, and KRD uses the same transport key Kn to decrypt the ciphertext of the key issued by KDH and install it, completing the entire RKI process.

[0106] Example 1

[0107] The logic block diagram of the RKI system in this embodiment is attached. Figure 2As shown: The terminal device (KRD) and the server (KDH) achieve two-way authentication via PKI technology. Asymmetric encryption and signature techniques are used to negotiate and generate a transmission key Kn, and a session key Kn is used to protect subsequent key transmissions. The optimized RKI protocol flow is attached. Figure 1 As shown, the complete RKL process consists of three stages: Init, KeyTransport, and KeyLoading.

[0108] Init phase: The first step (RT) of the Bind phase and KeyTransport phase in the standard TR34 protocol specification. KRD The generation process is integrated, and the specific steps are as follows (as shown in Table 2 below):

[0109] Table 2

[0110]

[0111]

[0112] A1: KRD initiates an RKI request

[0113] KRD generates a random number R. KRD RT is generated after signing with the KRD certificate private key. KRD Together with KRD certificate CT KRD Package them together and send them to KDH.

[0114] B1: KDH receives RKI verification request

[0115] KDH verification CT KRD Certificate, and use CT KRD Certificate Verification RT KRD Signature confirms the legitimacy of the terminal.

[0116] B2: KDH stores KRD certificates

[0117] KDH saves the KRD certificate locally for verification of the KT during the subsequent KeyTransport phase. KRD sign.

[0118] B3: KDH generates RKI request and response

[0119] KDH generates a random number R. KDH Using KDH signing certificate CT KDH_Auth RT is generated after signing with the private key. KDH Together with KDH signing certificate CT KDH_Auth and KDH encryption certificate CT KDH_Enc Package them together and send them to KRD.

[0120] A2: KRD verifies the KDH_Auth and KDH_Enc certificates, and verifies the RT. KDH sign

[0121] KRD verifies the validity of the KDH_Auth and KDH_Enc certificates and uses CT. KDH_Auth Certificate Verification RT KDH sign;

[0122] A3: KRD saves R KDH KDH_Auth and KDH_Enc certificates

[0123] KRD saves R KDH Store the KDH_Auth and KDH_Enc certificates locally for use in generating the KT during the subsequent KeyTransport phase. KRD Message.

[0124] In this specific solution, the KRD terminal only needs to integrate one KRD signing certificate CT. KRD That's all.

[0125] KeyTransport phase: KDH and KRD negotiate the core transport key, which is used for key distribution in the subsequent KeyLoading phase. The specific steps are as follows (as shown in Table 3 below):

[0126] Table 3

[0127]

[0128]

[0129] A1: Generate the transmission key Kn used for key distribution;

[0130] A2: Generate a temporary encryption key K E ;

[0131] A3: Generate ciphertext key packet

[0132] KRD constructs a key packet containing version, terminal ID, key packet header, and transmission key Kn, and uses K... E Encrypt it to generate a ciphertext key packet BE;

[0133] BE = E KE (Version||ID KRD_CRED ||Kn||KBH)

[0134] A4: Encrypt the temporary encryption key K using the KDH key. E

[0135] KRD uses the KDH encryption certificate CT saved during the Init phase.KDH_Enc Public key encryption K E ;

[0136] EncryptedKey=E KDH (K E )

[0137] A5: Construct the final key filling protocol message KT KRD

[0138] KRD constructs KT according to the CMS encrypted envelope format specification defined in PKCS#7. KRD KT KRD =R KDH ||KBH||EncryptedKey||BE||S KRD (R KDH ||KBH||EncryptedKey||BE)||CRL CA_KRD

[0139] B1: KDH parsing and verification of KT KRD And install Kn

[0140] KDH receives KT KRD Then, following the PKCS#7 specification format, its content was parsed and compared with R. KDH The value is used to verify the signature using the public key certificate of the KRD saved in step B2 of the int phase, and the EncryptedKey is decrypted using the private key corresponding to the KDH encryption certificate to obtain the K value. E Then use K E Decrypt BE to obtain the final transmission key Kn.

[0141] KeyLoading Phase: KDH uses the negotiated transport key Kn to encrypt the key to be issued later. KRD uses the same transport key Kn to decrypt the ciphertext of the key issued by KDH and install it, completing the entire RKI process.

[0142] This invention integrates the Bind and KeyTransport phases in the original TR34 standard through a complete RKI protocol process design, reducing the number of interactions between the two parties and improving the execution efficiency of RKI.

[0143] Furthermore, this invention redesigns the Kn generation scheme in the KeyTransport stage of the standard TR34 specification, changing it to generate Kn by KRD and encrypt it with the encryption certificate of KDH and return it. It still uses the PKCS#7 format specified in the standard TR34 specification to organize KT messages, ensuring the security and compliance of messages and supporting the smooth upgrade of existing systems.

[0144] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0145] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0146] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the invention by those skilled in the art. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the invention should be included within the scope of protection of the invention.

Claims

1. A design method for a POS machine remote key filling protocol based on the TR34 specification, characterized in that, In RKI, the terminal device POS and the server achieve two-way identity authentication through PKI technology, negotiate and generate a transmission key Kn using asymmetric encryption and signature technology, and use a session key Kn to protect subsequent key transmission. The RKI process is divided into three stages: Init, KeyTransport, and KeyLoading. Init phase: The first step (RT) of the Bind phase and KeyTransport phase in the standard TR34 protocol specification. KRD The generation process is integrated; KeyTransport phase: The KDH server and KRD negotiate the core transmission key, which is used for key distribution in the subsequent KeyLoading phase; the KRD is the terminal device POS machine. KeyLoading stage: KDH uses the negotiated transport key Kn to encrypt the key to be issued later, and KRD uses the same transport key Kn to decrypt the ciphertext of the key issued by KDH and install it, completing the entire RKI process; The Init phase integrates the Bind phase and the first step of the KeyTransport phase in the standard TR34 protocol specification, namely the generation of the RTKRD. The specific steps are as follows: S101: KRD initiates an RKI request KRD generates a random number R. KRD RT is generated after signing with the KRD certificate private key. KRD Together with KRD certificate CT KRD Pack them together and send them to KDH; S102: KDH receives RKI verification request KDH verification CT KRD Certificate, and use CT KRD Certificate Verification RT KRD Signature confirms the legitimacy of the terminal; S103: KDH stores KRD certificates KDH saves the KRD certificate locally for verification of the KT during the subsequent KeyTransport phase. KRD sign; S104: KDH generates RKI request and response KDH generates a random number R. KDH Using KDH signing certificate CT KDH_Auth RT is generated after signing with the private key. KDH Together with KDH signing certificate CT KDH_Auth and KDH encryption certificate CT KDH_Enc Pack them together and send them to KRD; S105: KRD CT verification KDH_Auth CT scan KDH_Enc Certificates and RT KDH sign KRD verification CT KDH_Auth and CT KDH_Enc Certificate validity, and use CT KDH_Auth Certificate Verification RT KDH sign; S106: KRD saves R KDH CT scan KDH_Auth and CT KDH_Enc Certificate KRD saves R KDH CT scan KDH_Auth and CT KDH_Enc The certificate is stored locally and used to generate the KT during the subsequent KeyTransport stage. KRD Message; KeyTransport phase: KDH and KRD negotiate the core transport key, which is used for key distribution in the subsequent KeyLoading phase; the specific steps are as follows: S201: KRD generates the transmission key Kn for this key distribution; S202: KRD generates a temporary encryption key K E ; S203: KRD generates ciphertext key packet KRD constructs a key packet containing version, terminal ID, key packet header, and transmission key Kn, and uses K... E Encrypt it to generate a ciphertext key packet BE; S204: KRD uses the KDH key to encrypt the temporary encryption key K E Get EncryptedKey KRD uses the KDH encryption certificate CT saved during the Init phase. KDH_Enc Public key encryption K E ; S205: KRD constructs the final key filling protocol message KT KRD KRD constructs KT according to the CMS encrypted envelope format specification defined in PKCS#7. KRD ; S206: KDH parsing and verification of KT KRD And install Kn KDH receives KT KRD Then, following the PKCS#7 specification format, its content was parsed and compared with R. KDH The value is verified using the public key certificate of the KRD stored in the S103 phase of the Init process, and the EncryptedKey is decrypted using the private key corresponding to the KDH encryption certificate to obtain the K value. E Then use K E Decrypt BE to obtain the final transmission key Kn.

2. The design method of a POS machine remote key filling protocol based on the TR34 specification according to claim 1, characterized in that, In S203, BE = EKE(Version||ID KRD_CRED ||Kn|| KBH).

3. The design method of a POS machine remote key filling protocol based on the TR34 specification according to claim 1, characterized in that, KT in S205 KRD = R KDH || KBH || EncryptedKey || BE || S KRD (R KDH || KBH ||EncryptedKey|| BE) || CRL CA_KRD .

4. The design method of a POS machine remote key filling protocol based on the TR34 specification according to claim 1, characterized in that, In S204, KRD uses the KDH encryption certificate CT saved during the Init phase. KDH_Enc Public key encryption KE; EncryptedKey = E KDH (K E ).

5. A computer-readable storage medium, characterized in that: The storage medium stores at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, at least one program, code set, or instruction set is loaded and executed by a processor to implement the design method of the POS machine remote key filling protocol based on the TR34 specification as described in any one of claims 1 to 4.

Images