Method for digital currency intra-chain and cross-chain off-chain swaps based on trusted hardware

A method for digital currency intra-chain and cross-chain off-chain swaps based on trusted hardware, comprising:

• step (1) randomly generating, by a trusted hardware system of an initiator, a public-private key pair
• (
• p
• ⁢
• k
• A
• TEE
• ,
• s
• ⁢
• k
• A
• TEE
• )
• ,
• generating a signature σA for a public key
• p
• ⁢
• k
• A
• TEE
• by using a signature private key of the trusted hardware system of the initiator, and sending the public key
• p
• ⁢
• k
• A
• TEE
• and the signature σA to a software system of the initiator;
• step (2) calculating, by the software system of the initiator, a digital currency address addr through the public key
• p
• ⁢
• k
• A
• TEE
• ,
• and depositing a digital currency into the digital currency address through a blockchain;
• sending, by the software system of the initiator, the public key
• pk
• A
• TEE
• ,
• a type of the digital currency, an initiator rescue address addrA preset by the initiator and an earliest rescue time tA expected by the initiator to the trusted hardware system of the initiator, requesting the hardware system of the initiator to generate a rescue object for
• (
• pk
• A
• TEE
• ,
• sk
• A
• TEE
• )
• ,
• and returning, by the trusted hardware system of the initiator, the generated rescue object and a signature σtA;
• step (3) randomly generating, by a trusted hardware system of a responder, a public-private key pair
• (
• pk
• B
• TEE
• ,
• sk
• B
• TEE
• )
• ,
• generating a signature op for a public key
• pk
• B
• TEE
• by using a signature private key of the trusted hardware system of the responder, and returning the public key
• pk
• B
• TEE
• and the signature σB to the software system of the responder;
• step (4) calculating, by the software system of the responder, a digital currency address addr′ through the public key
• pk
• B
• TEE
• ,
• and depositing a digital currency into the digital currency address through a blockchain;
• sending, by the software system of the responder, the public key
• pk
• B
• TEE
• ,
• a type of the digital currency, an responder rescue address addrB preset by the responder, and an earliest rescue time tB expected by the responder to the trusted hardware system of the responder, requesting the rusted hardware system of the responder to generate a rescue object for
• (
• pk
• B
• TEE
• ,
• sk
• B
• TEE
• )
• and returning, by the trusted hardware system of the responder, the generated rescue object and a signature σtB;
• step (5) sending, by the software system of the initiator, the digital currency address addr and the earliest rescue time tA expected by the initiator to the software system of the responder, and verifying, by the software system of the responder, whether there is a corresponding digital currency at addr and confirming whether to accept the earliest rescue time tA expected by the initiator;
• when the responder does not accept the earliest rescue time t expected by the initiator, terminating a transaction, otherwise, determining whether tB−t is greater than two fixed time intervals, when tB−tA being not greater than the two fixed time intervals, terminating the transaction, and when tB−tA being greater than the two fixed time intervals, and sending, by the software system of the responder, a trusted hardware signature public key of the responder and a trusted hardware encryption public key of the responder to the software system of the initiator;
• step (6) sending, by the software system of the responder, the digital currency address addr′ and the earliest rescue time tB expected by the responder to the software system of the initiator, and verifying, by the software system of the initiator, whether there is a corresponding digital currency at addr′ and confirming whether to accept the earliest rescue time tB expected by the responder;
• when the initiator does not accept the earliest rescue time tB expected by the responder, terminating a transaction, otherwise, determining whether tB−tA is greater than two fixed time intervals, when tB−tA being not greater than the two fixed time intervals, terminating the transaction, and when tB−tA being greater than the two fixed time intervals, and sending, by the software system of the initiator, a trusted hardware signature public key of the initiator and a trusted hardware encryption public of the initiator to the software system of the responder;
• step (7) sending, by the software system of the initiator, the public key
• pk
• A
• TEE
• ,
• the trusted hardware encryption public key of the responder, and a rescue address addrA′ preset by the initiator located in a same blockchain system as the digital currency address addr′ to the trusted hardware system of the initiator, and requesting the trusted, hardware system of the initiator to transfer
• (
• pk
• A
• TEE
• ,
• sk
• A
• TEE
• )
• ;
• and performing, by the trusted hardware system of the initiator, asymmetric encryption on
• sk
• A
• TEE
• ,
• by using , to generate a ciphertext CA, deleting
• (
• pk
• A
• TEE
• ,
• sk
• A
• TEE
• )
• from a confidential storage space, and signing CA and addrA′, respectively, by using the trusted hardware signature private key to generate signatures σCA and σaddrA′, and sending CA, σCA′ and σaddrA′ to the software system of the initiator;
• step (8) sending, by the software system of the initiator, the public key
• pk
• A
• TEE
• ,
• the signature σA, the ciphertext CA, the signature σCA, the earliest rescue time tA expected by the initiator, the signature σCA, the rescue address addrA′ of the initiator and the signature σaddrA′ to the software system of the responder;
• step (9) sending, by the software system of the responder, the public key
• pk
• A
• TEE
• ,
• the signature σA, the ciphertext CA, the signature σCA, the earliest rescue time tA expected by the initiator, the signature σtA, the rescue address addrA′ of the initiator, the signature σaddrA′, the trusted hardware signature public key of the initiator, the trusted hardware encryption public key of the initiator, the public key
• pk
• B
• TEE
• ,
• the earliest rescue time tB expected by the responder, the signature σtB, and a rescue address addrB′ preset by the responder located in a same blockchain system as the digital currency address addr to the trusted hardware of the responder, using, by the trusted hardware system, to verify whether σA is a signature for
• pk
• A
• TEE
• by the trusted hardware system of the initiator using , whether σCA is a signature for CA by the trusted hardware system of the initiator using , whether σtA is a signature for tA by the trusted hardware system of the initiator using , whether σaddrA′ is a signature for addrA′ by the trusted hardware system of the initiator using , and using to verify whether σtB is signature for tB by the trusted hardware system of the responder using , when verifying being passed, verifying whether tB−tA is greater than two fixed time intervals, and when verifying being further passed, performing, by , asymmetric decryption on CA to obtain
• sk
• A
• TEE
• ,
• storing
• (
• pk
• A
• TEE
• ,
• sk
• A
• TEE
• )
• into the confidential storage space of the trusted hardware system of the responder, setting the public-private key pair to a locked state, and deleting
• (
• pk
• B
• TEE
• ,
• sk
• B
• TEE
• )
• from the confidential storage space;
• performing, by the trusted hardware system of the responder, asymmetric encryption on
• sk
• B
• TEE
• by using , to generate a ciphertext CB, and sign CB by using the trusted hardware signature private key to generate a signature σCB;
• and generating, by the trusted hardware of the responder, a special rescue object for
• (
• pk
• A
• TEE
• ,
• sk
• A
• TEE
• )
• ,
• with an expected rescue time being a time t′A that is earlier than tA by at least a fixed time interval, with a rescue address being addrB′, with a payload being the data of a blockchain transaction txR′ of immediately transferring from addr′ to addrA′ that meets a digital currency type, and returning, by the trusted hardware system of the responder, CB, σCB and the special rescue object to the software system of the responder;
• step (10) sending, by the software system of the responder, the public key
• pk
• B
• TEE
• ,
• the signature σB, the ciphertext CB, the signature σCB, the earliest rescue time tB expected by the responder and the signature σtB to the software system of the initiator;
• step (11) sending, by the software system of the initiator, the public key
• pk
• B
• TEE
• ,
• the signature σB, the ciphertext CB, the signature σCB, the earliest rescue time tB expected by the responder and the signature σtB, the trusted hardware signature public key of the responder, the earliest rescue time tA expected by the initiator and the signature σtA to the trusted hardware system of the initiator, using, by the trusted hardware system of the initiator, to verify whether σB is a signature for
• pk
• B
• TEE
• by the trusted hardware system of the responder using , whether σCB is a signature for CB by the trusted hardware system of the responder using , and whether σtB is a signature for tB by the trusted hardware system of the responder using , and using to verify whether σtA is a signature for tA by the trusted hardware system of the initiator using , when verifying being passed, verifying whether tB−tA is greater than two fixed time intervals, and when verifying being further passed, performing, by , asymmetric decryption on CB to obtain
• sk
• B
• TEE
• ,
• storing
• (
• pk
• B
• TEE
• ,
• sk
• B
• TEE
• )
• into the confidential storage space of the trusted hardware system of the initiator, signing, by ,
• pk
• B
• TEE
• to generate a signature σB′, performing, by , asymmetric encryption on a completion symbol to generate a ciphertext C′A, signing, by , C′A to generate a signature σC′A, and returning σB′, C′A, and σC′A to the software system of the initiator;
• step (12) sending, by the software system of the initiator, the ciphertext C′A and the signature σC′A to the software system of the responder;
• and
• step (13) sending, by the software system of the responder, the ciphertext C′A, the signature σC′A and the trusted hardware signature public key of the initiator to the trusted hardware system of the responder, using, by the trusted hardware system of the responder, to verify whether σC′A is a signature for C′A by the trusted hardware system of the initiator using , when the verifying being passed, performing, by , asymmetric decryption on C′A, and when the ciphertext C′A being decrypted to obtain the completion symbol, removing the locked state of
• (
• pk
• A
• TEE
• ,
• sk
• A
• TEE
• )
• ,
• signing, by ,
• pk
• A
• TEE
• to generate a signature σA′, and returning σA′ to the software system of the responder, so as to avoid on-chain swap and improve efficiency of intra-chain and cross-chain swap in digital currency.