Apparatus and methods for remote controlled cold storage of digital assets using near field communication tags

Abstract

An air-gapped system enables the secure transfer and control of digital assets, such as those associated with crypto-currency. The system includes an Integration Server for receiving requests from an application interface, a Central Control Center for verifying the requests received and authorizing the requests using digital signatures, and multiple Distributed Data Centers, each including a cold Data Center Hardware Security Module (DC HSM). These DC HSMs securely store and manage cryptographic keys. Each Data Center also includes an offline Processing Unit coupling its DC HSM to a dedicated Remote Controlled Server. The Remote Controlled Server receives requests from the Integration Server and forwards them to the Processing Unit of a DC HSM using a Near-Field Communication (NFC) Interface between the two. Preferably, the NFC interface is physically shielded to resist side channel attacks.

Claims

1. A method of performing a transaction over a blockchain network, the method comprising: receiving instructions for executing a blockchain transaction; ensuring that the instructions are authorized; on the basis of the received instruction, generating a command to collect signatures for the blockchain transaction; transmitting the command using a secure air-gapped process to multiple Data Center Hardware Security Modules (DC HSMs), wherein each DC HSM contains a corresponding private key for signing the blockchain transaction; validating an authenticity of the received command at each of the multiple DC HSMs; securely signing the blockchain transaction inside each of the multiple DC HSMs using a signing technique and transferring signatures back using the secured air-gapped process; building a multi-signed transaction from collected DC HSM signatures; and transmitting the multi-signed transaction to a destination, wherein the secure air-gapped process uses near field communication (NFC) interfaces and NFC Radio Frequency Identification (RFID) tags, and wherein the NFC interfaces are physically shielded.

2. The method of claim 1, wherein the destination comprises a blockchain network.

3. The method of claim 1, wherein the NFC interfaces are physically shielded to resist side channel attacks.

4. The method of claim 2, further comprising ensuring that at least M of N DC HSMs sign the blockchain transaction before transmitting the multi-signed transactions to the blockchain network, where N=a total number of DC HSMs, and M≤N, for integers N and M.

5. The method of claim 4, wherein the signing technique comprises Elliptic Curve Digital Signature Algorithm (ECDSA), Edwards-Curve Digital Signature Algorithm (EdDSA), RSA, or any combination thereof.

6. A cold storage system for storing digital assets comprising: a. an integration server, including a processor and a memory, coupled to an external network; b. a central control center comprising a request handler and a command handling Hardware Security Module (HSM); and c. multiple distributed data centers each comprising: i. an associated Data Center (DC) HSM for managing cryptographic keys; ii. a processor coupled to the associated DC HSM; iii. a dedicated remote controlled server coupled to the integration server; and iv. a physically shielded near field communication (NFC) adapter pair having a Radio Frequency Identification (RFID) tag forming an air-gapped communication channel between the remote controlled server and the processor coupled to the associated DC HSM.

7. The cold storage system of claim 6, wherein each of the NFC adapter pairs comprises NFC devices and tags physically shielded to avoid side channel attacks, data skimming, or both.

8. The cold storage system of claim 7, wherein each of the NFC adapter pairs comprises NFC devices having both read/write capabilities comprising NFC tags between the NFC devices.

9. The cold storage system of claim 6, wherein the external network comprises the Internet or a virtual private network.

10. The cold storage system of claim 6, wherein the request handler is configured to receive raw instructions to execute blockchain transactions from the integration server and to send the raw instructions to the command handling HSM over the air-gapped channel.

11. The cold storage system of claim 10, wherein the raw instruction is authorized by the command handling HSM through a multiple factor authentication protocol.

12. The cold storage system of claim 6, wherein each of the multiple processors of the distributed data centers is configured to send and receive commands only from its associated NFC adapter pair.

13. The cold storage system of claim 6, wherein each of the multiple associated DC HSMs is configured to verify an authenticity of received commands using digital signatures and pre-installed certificates of the command handling HSM.

14. The cold storage system of claim 6, wherein each of the associated DC HSMs is configured for determining whether an associated one or more command execution constraints are met.

15. The cold storage system of claim 14, wherein the command execution constraints comprise velocity of requests, time bound expiry, or both.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) The following figures are used to illustrate embodiments of the invention. In the figures, the same label refers to the identical or a similar element.

(2) FIG. 1 is a high-level flow chart of a method of securely executing a blockchain transaction in accordance with one embodiment of the invention.

(3) FIG. 2 is a schematic diagram of a system in accordance with one embodiment of the invention.

(4) FIG. 3 shows a Data Center of FIG. 2, in accordance with one embodiment of the invention.

(5) FIGS. 4A and 4B together show a flowchart of a method of processing commands when a user requests either the creation of a wallet or the transferring/withdrawing of funds from a wallet, in accordance with one embodiment of the invention.

(6) FIG. 5 is a flowchart of a method of initializing an HSM and configuring Administrator and Operator Card groups, in accordance with one embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

(7) In accordance with the principles of the invention, an HSM is configured as a cold wallet for all transactions over a blockchain network, by securing private keys used for signing transactions. Preferably, the HSM is coupled to an Integration Server over a near-field communication (NFC) network, which effectively takes the HSM offline. Several definitions are useful for the discussion that follows.

(8) A cold wallet is a private key storage mechanism that is entirely offline.

(9) A hot wallet is a private key storage mechanism that is coupled to the Internet, that is, online.

(10) A Hardware Security Module (HSM) is a physical computing device that safeguards and manages cryptographic keys and provides secure execution of critical code. HSMs have built-in anti-tampering technology which wipes secrets in case of a physical breach. Generally, an HSM uses two sets of cards: Administrative Cards, which are used to enable administrative functions such as Key Recovery, and Operator Cards, which are used by operational staff to perform functions such as signing with cryptographic keys. The Administrator and Operator Card sets are not interchangeable, and access to one does not provide access to the other. To perform operations such as the signing of the transaction, multiple operator cards can be configured so that no single user can process requests on the HSM.

(11) A multi-signature wallet is a wallet in which control over multiple private keys is required to spend from that wallet. In other words, an address in the wallet has multiple private keys behind it. The idea with multi-signature wallets is that multiple people or entities can cooperatively control the funds in the wallet. The “M” of “N” multi-signatures (where M≤N, and M and N are both integers) can be implemented with “N” HSMs acting as controlling entities of which “M” signatures are required to process transactions.

(12) Near-Field Communication (NFC) is a de facto standard for a certain form of radio communication. NFC includes a set of communication protocols that enable two electronic devices to establish communication using NFC tags by bringing them within close proximity of each other. This is a fast and convenient method of data transfer.

(13) Radio Frequency Identification (RFID) is a short-distance electromagnetic method for transmitting small bits of data.

(14) An RFID-Shield is an RFID-blocking shield designed to help insulate a wallet from a very particular brand of electronic pickpocketing, called “RFID skimming.”

(15) While the discussion that follows describes digital currencies, it will be appreciated that other digital objects can be secured using the principles of the invention.

(16) FIG. 1 is a high-level diagram showing how keys, and thus assets, are protected in a blockchain network in accordance with the principles of the invention. The process starts in a step 1001. In a step 1010, a transaction is received from a user (e.g., a person or entity wishing to make a transaction) at an integration server. In a step 1020, the integration server forwards this transaction to a control center. Next in a step 1030, the control center validates the transaction by ensuring that it is authorized by the owner. In a step 1040, a command containing instructions to be executed on the HSMs is sent back to the integration server. In a step 1050, the integration server transfers the command to multiple data centers over a TCP/IP connection.

(17) At each data center, the command is transmitted to a corresponding DC HSM over an air-gapped communication channel using NFC protocol in a manner that ensures security. Preferably, the air-gapped communication channel is shielded, such that the NFC communication cannot be read by eavesdroppers or other malicious actors. In this way, even if the TCP/IP connection is compromised, a malicious actor cannot intercept any of the communications to the DC HSM. In effect, the DC HSM is offline, that is, a “cold wallet.” At worst, if a malicious attack is attempted, a user will receive a denial of service (DoS) message and the transaction will be terminated.

(18) In a step 1060, each of these DC HSMs verifies that the request is authorized by the control center. In some embodiments, each DC HSM tests for a corresponding constraint, such as for a control center signature or for non-stale commands, and ensures that the constraint is met before signing the transaction.

(19) In a step 1070, the transaction request is signed inside each DC HSM, and in a step 1080 the signature is transmitted back over the air-gapped communication channel to the integration server. In a step 1090 the integration server builds a signed transaction using these collected signatures and ultimately transmits the signed transaction to its intended recipients, such as by broadcasting the transaction over a blockchain network. In a step 1095, the process ends.

(20) FIG. 2 is a block diagram of a system 2000 in accordance with one embodiment invention, coupled to multiple blockchain networks 2010. The system 2000 includes a user interface 2015 coupled to an integration server 2020. The integration server 2020 is coupled to the multiple blockchain networks 2010, a Central Control Center 2030, and multiple Distributed Data Centers 2050.sub.1, 2050.sub.2, . . . , 2050.sub.N (i.e., 2050.sub.i=1 to N). The Central Control Center 2030 includes a Request Handler 2035 and a Command Handling HSM 2040 configured to receive signatures from N operators OP1-OPN, for integer N.

(21) Each of the Distributed Data Centers 2050.sub.i=1 to N is coupled to the Integration Server 2020. Each of the Distributed Data Centers 2050.sub.i=1 to N includes a Dedicated Remote Controlled Server 2060.sub.i coupled to the Integration Server 2020 and also coupled to a corresponding DC HSM.sub.i over a matched NFC pair 2085.sub.i (each, described in more detail below, having an air-gap) and a Processing Unit 2090.sub.i.

(22) In operation, an unsigned request is sent from the user interface 2015 to the Integration Server 2020, which forwards the unsigned request to the Request Handler 2035. The Request Handler 2035 sends the unsigned request to the Command Handling HSM 2040 for signatures from the Operators OP1-OPN. If a threshold M out of N operators sign the request, thereby validating it, a command is created and sent back to the Request Handler 2035. The Request Handler 2035 forwards the command to the Integration Server 2020, which then forwards the command to the Data Centers 2050.sub.i=1 to N for processing. As some examples, the processing can include commands to create a wallet, withdraw funds, etc.

(23) FIG. 3 is a more detailed block diagram of an exemplary Data Center 2050.sub.1 in accordance with one embodiment of the invention. As shown in FIG. 3, the Data Center 2050.sub.1 is coupled to the Integration Server 2020 through a Remote Controlled Server 2060.sub.1. The Remote Controlled Server 2060.sub.1 is coupled to a matched NFC adapter pair 2085.sub.1 that includes a first NFC 2080A.sub.1 coupled to the Remote Controlled Server 2060.sub.1 and to a second NFC 2080B.sub.1 over an air gap. Each of NFC 2080A.sub.1 and NFC 2080B.sub.1 has an NFC RFID tag 2089.sub.1, which provides read/write capabilities for securely communicating with each other. The NFC pair 2085.sub.1 is surrounded by an RF shield 2088.sub.1. The second NFC 2080B.sub.1 is coupled to a Processing Unit 2090.sub.1, which in turn is coupled to its corresponding DC HSM 2070.sub.1.

(24) Because the DC HSM 2070.sub.1 is coupled to the Integration Server 2020 and thus ultimately to the Multiple Blockchain Networks 2010 over an air gap and not an IP connection, the DC HSM 2070.sub.1 is referred to as a “cold” HSM.

(25) This unique type of communication between the Command Handling HSM 2040 and the DC HSMs 2070.sub.i=1 to N, through the Integration Server 2020, is carried out by specially signed message communication and over the NFC protocol. Therefore, even if an intruder were to seize the external system, access to the internal system is prevented. At most, a malicious attacker can only cause a DoS attack.

(26) FIG. 4 (FIG. 4A continued in FIG. 4B) shows the steps 4000 of a method of processing commands when a user requests that the system either generate a wallet or transfer/withdraw funds. In this example, the elements of FIG. 2 are used to tie the steps of the method with the components of a system in accordance with the embodiments. Referring to FIGS. 2 and 4, in a step 4005, a user makes a request from a device 2015 connected to the Internet. Next, in a step 4010, the integration server 2020 determines whether the user has been authenticated. If the user has been authenticated, the process continues to a step 4020; otherwise, the process continues to a step 4015, where the process is terminated based on a user authentication error.

(27) In the step 4020, the Integration Server 2020 creates an unsigned transaction for the Command Handling HSM 2040, with a raw blockchain transaction as payload. Next, the method continues to a step 4025, where the operators authorize the transaction, and continues to a step 4030, where it is determined whether M signatures have been collected from the operators. If M signatures have not been collected, the process loops back to the step 4025; otherwise, the process continues to a step 4035.

(28) In the step 4035 the Command Handling HSM 2040 signs the command using the Organization Private Key and transmits the signed command to the Integration Server 2020. In a step 4040, the Integration Server 2020 receives the signed command containing a raw blockchain transaction and transmits the signed command to each Processing Unit 2090.sub.i=1 to N at the Distributed Data Centers 2050.sub.i=1 to N. In a step 4045, each Processing Unit 2090.sub.i=1 to N determines whether the signature on the command is verified. If each Processing Unit 2090.sub.i=1 to N determines that the signature on the command is verified, the process continues to a step 4055; otherwise, the process continues to a step 4050. In the step 4050, the process is terminated based on an Unauthorized Command Error.

(29) In the step 4055, each Processing Unit 2090.sub.i=1 to N determines whether its associated command execution constraints have been met. If each Processing Unit 2090.sub.i=1 to N determines that the constraints have been met, the process continues to a step 4065; otherwise, the process continues to the step 4060. In the step 4060, the transaction is terminated based on a Command Constraint Error.

(30) In the step 4065, each Processing Unit 2090.sub.i=1 to N extracts the raw blockchain transaction from the command and transmits the raw blockchain transaction data to the corresponding DC HSM 2070.sub.i=1 to N. Next, in a step 4070, each DC HSM 2090.sub.i=1 to N signs the raw blockchain transaction data using the User's private key. Each DC HSM 2090.sub.i=1 to N then transmits the signed transaction data through its corresponding Processing Unit 2090.sub.i=1 to N to its NFC pair 2085.sub.i=1 to N to its Remote Controlled Server 2060.sub.i=1 to N and to the Integration Server 2020.

(31) Next, in a step 4075, the Integration Server 2020 determines whether at least M out of N DC HSMs have responded. If at least M out of N DC HSMs have responded, the process continues to a step 4080; otherwise, the process loops back to the step 4040. In the step 4080, the Integration Server 2020 determines whether a blockchain transaction was involved. If a blockchain transaction was involved, the process continues to a step 4085; otherwise, the process continues to a step 4090, where the user receives notification that the operation was successful. In the step 4085, the transaction is broadcast to the blockchain network, and the process continues to the step 4090.

(32) The process of initializing an HSM includes (1) erasing the HSM, (2) creating a new master key for the HSM, and (3) creating a new Administrator Card Set to protect this master key. This master key cannot be exported and remains stored inside the non-volatile memory of the HSM until the module is re-initialized.

(33) Typically, an HSM is initialized by selecting the item “Module initialization” from the main menu available on the HSM's front panel. Next, a default quorum for the Administrative Card Set (ACS) is selected. The quorum is the maximum number of administrative cards (K) required by default for an operation. Also, the total number of administrative cards (N) intended to be used must be specified in this step. Next a Blank card for the ACS is inserted. A prompt will appear to confirm that the user wants to use the card. If required, certain operations (such as recovery and replacement) can be disabled for the card.

(34) Next, an Operators Group is created for the HSM. To create the Operators Group, the HSM will authenticate the previously created administrators and will create a physically controllable smart card for each member of the new Operators Group. Each member of the Operators Group can be configured to have access to only certain operations. After this procedure is finished, the HSM is initialized.

(35) After initialization, whenever the key needs to be used, operators must present their cards to the HSM. The loading of a key can be used based on a predefined policy, such as, at least M operator cards must be authorized out of a total N operator cards. Once the key is loaded on the HSM's memory, it is possible to use it, for instance, to sign a transaction.

(36) FIG. 5 shows the steps 5000 of method to initialize an HSM and configure both Administrator and Operator Card groups required for further operation processing using the HSM, in accordance with one embodiment of the invention. As used herein, at least two card sets are used in performing operations in accordance with embodiments of the invention, an Administrator Card Set and an Operator Card Set. The two card sets allow holders of each set to perform specific functions. Each card set contains a set of keys that authorize specific actions. The Administrator Cards are not used in normal operation, but only in cases when the HSM is set up or restored, or when Operator Cards are recovered.

(37) Referring to FIG. 5, in a step 5005, a security officer activates initializing the HSM using a menu on the HSM's front panel. Next, in a step 5010, the security officer determines the total number of Administrator Cards to be configured, in this example, integer N. In a step 5015, the security officer enters the quorum for the Administrator Card Set needed to authorize a transaction, here integer K, where K≤N. Next, in a step 5020, a blank Administrator Card is inserted into the HSM, and in a step 5025 the Administrator Card is configured with authorizations. Next, in a step 5030, the HSM determines whether the N Administrator Cards have been configured. If all N Administrator Cards have been configured, the process continues to a step 5035; otherwise, the process loops back to the step 5020.

(38) In the step 5035, the HSM receives a command to create an Operator Card Set. Next, in a step 5040, the HSM determines whether this operation is authorized by K Administrator Cards. If the operation has been authorized by K Administrator Cards, the process continues to a step 5050; otherwise the process continues to a step 5045. In the step 5045, the process waits for K Administrator Cards to be inserted for the authorization to be performed and then loops back to the step 5040.

(39) In the step 5050, a blank Operator Card is inserted, and in the step 5055, the inserted Operator Card is configured with authorizations. Next, in a step 5060, the HSM determines whether all the Operator Cards have been configured. If all the Operator Cards have been configured, the process continues to a step 5065, where it is determined that the HSM Initialization is successful. If in the step 5060 it is determined that not all of the Operator Cards have been initialized, the process loops back to the step 5050.

(40) The Administrator Cards are not used in normal operation, but only in cases when the HSM is set up or restored, or when Operator Cards are recovered. The Operators Card Set is used by operational staff to perform functions such as signing with the generated cryptographic keys. Preferably, multiple operator cards are created, so that no single card has the authority to process the requests.

(41) It will be appreciated that the Administrator and Operator cards are not interchangeable, and access to one does not provide access to the other. Inside the HSM secure module area, the integrity and confidentiality of all other objects are guaranteed by encrypting everything with the private key embodied in the security world.

(42) In operation of one embodiment, an HSM is initialized, Administrator and Operator card sets are configured. For systems with N HSMs, at least K Administrator cards are configured and an Operator card set is configured. When a request for a transaction is received at an integration server, the command is transferred to a request handler. At least M operators must manually validate the transaction. Among other things, each operator performs different checks to determine the validity of the command. Alternatively, a transaction is validated automatically using a software agent. In other embodiments a command handling HSM then signs the command with the organization's private key. This signature establishes the authenticity and integrity of the request for the flow of commands down the pipeline, to protect downstream HSMs against possible intrusion. The command handler then transmits the request to the integration server in any suitable format, such as JavaScript Object Notation (JSON) or Extensible Markup Language (XML), to name only two such formats. The request handler then receives the signed command and transmits it to multiple distributed data centers.

(43) Each data center includes a dedicated remote controlled server coupled to the integration server, a shielded NFC pair coupling the remote controlled server to a processing unit, which in turn is coupled to a DC HSM. At each data center, the signed command is transferred using the NFC protocol to the offline processing unit. The signature is verified using the organization's public key stored in the DC HSM. An agent at the DC HSM performs and enforces checks on the behavior of command execution. For example, an agent on DC HSM.sub.1 may check that the command is not stale, such as being signed too long ago, and an agent on DC HSM.sub.2 may check that the command is not a duplicate. It will be appreciated that in some embodiments, a single agent can perform multiple checks.

(44) At each data center, after it has been determined that its associated one or more checks have been passed, the raw unsigned blockchain transaction is extracted from the signed command and passed to the corresponding DC HSM to be signed using the user's private key. Typically, the extraction is only needed for transfer requests by a user or for wallet generation requests on certain blockchains.

(45) Next, after M out of N of the multiple DC HSMs have responded with payloads containing signatures, the operation requested by the user is carried out and its response data is passed back to the integration server. If the request involves a blockchain transaction, the response data is broadcast to the network.

(46) While the examples above are directed to digital wallets, it will be appreciated that the principles of the invention can be used with other digital assets such as titles of ownership, medical records, and supply chains, to name only a few examples.

(47) It will be readily apparent to one skilled in the art that various other modifications may be made to the embodiments without departing from the spirit and scope of the invention as defined by the appended claims.