Protecting a Hot Wallet Service – A digital wallet is where valuable digital currency is kept. A key is required to open a digital wallet, but if you lose the key, someone else may be able to open it without your knowledge, so losing the key effectively means you have lost the wallet and the money it contains.
A cash wallet can be opened with your hands, but a digital wallet requires the use of a computer. The digital wallet could simply be data and the software to manage it stored on your computer – this is known as a hot wallet because it is ready to use at any time. [Protecting a Hot Wallet Service]
Alternatively, the wallet could be a separate device that you connect to a computer when you need to use it – this is known as a cold wallet because you must plug it in and start it up from cold to use it.
Unfortunately, while you have control over your hands, you do not always have control over your computer. If an attacker has access to your computer, they can steal the key to your wallet, and if the wallet is on the computer or attached to it, the attacker has access to your money.
Hot wallets are relatively easy prey for an attacker with malware delivery capabilities. Cold wallets are more difficult to compromise because the attacker must coordinate their attack with your use of the device. As a result, crypto currency providers and financial regulators strongly advise, if not require, the use of a cold wallet for storing large amounts of currency.
Hot wallets are pre-loaded with small amounts for immediate use and are replenished from the cold wallet as needed. This is analogous to having a cash wallet that is topped up from a cash machine when it runs out of money. [Protecting a Hot Wallet Service]
Cold wallets must be used with caution, and their keys must be kept safe; however, this is difficult, and their use can be time consuming and error prone.
A digital wallet service that is responsible for the security of many customers’ wallets could improve security, but such a service is always online and thus “hot,” which is contrary to common advice and regulation. This paper examines the issue in depth, contrasting the security of cold wallets versus a hot wallet service. It demonstrates that, with proper service protection, it is possible to provide a hot wallet service that provides protection equivalent to using offline cold wallet devices.
Cold Wallets [Protecting a Hot Wallet Service]
A cryptographic private key is required for anyone who needs to authorise digital financial transactions on a regular basis. This key represents their digital identity and must be kept private; revealing it to others would allow others to impersonate them.
Because of the cryptographic mechanism used, the user can authorise transactions using their private key without disclosing it. There are devices available that store the private key and authorise transactions when a password is entered. These are specially designed to prevent the private key from being extracted from the device, even with unrestricted physical access, and transactions can be authorised only if the password is known.
When a user first acquires a device, it does not contain a private key. When it is first activated, it generates and stores a private key. It also generates a public key that is revealed, which can be used by anyone to prove that the device authorised a transaction. [Protecting a Hot Wallet Service]
If the user only makes occasional transactions, the device containing their private key can be kept offline except when a transaction is required. To complete a transaction, the user must enter their password as well as a unique transaction identity. The device then returns the transaction’s digital signature value.
The password could be entered using the device’s keypad, but the transaction identity is too long to enter this way, and the signature is too long to copy from the device’s screen. This means that the device must be connected to the internet (plugged into a computer) while the transaction is authorised.
While the user holding the device can be confident that no transaction will be authorised unless they enter their password, a flaw in the system is that they receive no indication of what they are authorising.
They are viewing transaction details on their computer, and in theory they are authorising the transaction’s unique identity, but the computer’s software could instead provide the identity of another transaction, and the user would be unaware of this at the time. [Protecting a Hot Wallet Service]
Furthermore, if the password is entered into the device via the computer, the software may be able to authorise several transactions without the user’s knowledge while the device is plugged in.
However, such attacks would necessitate a certain level of sophistication, and as soon as one user notices a discrepancy in their transaction record, an investigation will likely reveal the attack and it will be stopped.
As a result, for an attack to be effective, it must be directed at a single high-value user or coordinated across many users. A coordinated attack must be delivered to a large number of users while remaining hidden before striking simultaneously against any online device, which is difficult to accomplish.
The primary security benefit of using a separate device to store the private key used to authorise transactions is that it cannot be used when not connected to a computer. It requires the user’s physical intervention before it can be used. [Protecting a Hot Wallet Service]
This forces an attack to focus on the time it is connected, and while this is quite feasible given the computer’s large attack surface, attacking large numbers of users is much more difficult because the attack must be coordinated to avoid detection before the attack is complete.
The requirement to connect a device each time it is to be used is inconvenient and not suitable for frequent transactions. If a service provider could manage the private key and the security measures used to protect it were equivalent, transactions could be signed more easily, allowing transactions that did not previously warrant this level of protection to be signed.
In addition, if the digital identity must be linked to the user’s real physical identity, the device must generate a request for its private key to be certified. This request is forwarded to a central authority, which confirms the user’s true identity and issues a certificate certifying the user’s possession of the private key.
All of this is accomplished without revealing the private key. Anyone who has a copy of the certificate can then confirm that a transaction was signed by the device that the user registered. It is critical that the registration process confirms the user’s identity, because if a user registers their device in the name of another person, they will be able to authorise transactions in that person’s name. Because the data involved is too long to copy by hand, the device must be online during the registration process. [Protecting a Hot Wallet Service]
Protecting the Key
A device used to protect a user’s private key is not shared, but a service provider must hold private keys for many users. This necessitates the use of a specialised device (a Hardware Security Module – HSM) that can be trusted to safeguard a large number of keys. The shared device is housed in a server room and must always be connected to the network of the service provider. To authorise a transaction, the client must first authenticate to the shared device. The device then chooses the client’s private key and signs the transaction with it.
The shared device, like a private device, is trusted not to reveal the private keys, but it is also trusted to select the correct private key when asked to sign a transaction. Because a password is typically used to authenticate the client, a password management mechanism must also be supported, and it must also be trusted not to reveal clients’ passwords or allow them to be modified by other clients. Passwords must be securely transferred between client and server, which requires the use of cryptographic mechanisms to establish a secure channel. [Protecting a Hot Wallet Service]
All of this functionality increases the complexity of the shared device, lowering trust. It is also difficult to create a device that can meet large-scale requirements. As a result, in practise, the implementation is divided. An application server handles client authentication, while the special shared device handles only the private keys and cryptographic operations required to authorise a transaction.
This means that while the private keys are well protected against disclosure, there is much less assurance that they will be used appropriately. It is the application server’s responsibility to authenticate clients and match their requests to the correct private key in the shared device. A more robust solution would be to have the HSM directly challenge the user to use their password to authenticate, but this adds complexity and increases the HSM’s attack surface.
Where clients keep their own private keys in their own devices, a large-scale attack requires considerable skill and careful coordination, and cannot exploit keys in unconnected devices. A large-scale attack, on the other hand, is much simpler when the keys are held centrally in a shared device that is always online – it only needs to take control of the application server to have the freedom to use any private key. [Protecting a Hot Wallet Service]
A managed key service has a large attack surface because it necessitates the use of a complex application server to control access to the hardware device that stores all private keys and is always online. The only way to ensure it provides equivalent protection to a personal key device is to make the attack surface inaccessible while still allowing it to handle legitimate transactions.
Protecting the Key Service
Placing a security gateway computer in front of the application hides the attack surface of the application server. Instead, the attacker sees the security gateway’s attack surface. Although this should be smaller, the attacker may still be able to take control of the security gateway and disable it, allowing them to fully target the application server’s attack surface.
As a result, the risk is reduced but not eliminated, and such a solution does not equate to having an offline device. The issue here is that one software stack (that of the application server) is being replaced by another (that of the security gateway), and a software stack is always sufficiently complex for flaws and weaknesses to exist. [Protecting a Hot Wallet Service]
A security gateway, on the other hand, does not have to be a computer. The High Speed Verifier (HSV) from Forcepoint is a hardware logic device designed to connect highly critical systems to untrustworthy networks without exposing an attacker to any software attack surface.
The verifier allows messages to pass in both directions between the two networks, but only messages that exactly match a tightly specified data format are allowed through; all other messages are rejected. The message data is validated using hardware logic rather than software. Furthermore, the hardware logic handles the protocol used to pass messages through the verifier, so the verifier component has no software attack surface.
Unfortunately, the data formats and protocols currently in use are complex and require software to handle. Only by keeping formats and protocols simple can they be handled logically. As a result, the HSV employs software to translate between the complex data formats and protocols required by applications and the simple data formats and protocols supported by logic. Despite its complexity, the conversion software is not security critical; if an attacker gains control of it, all they can do is send messages that are permitted in any case. [Protecting a Hot Wallet Service]
The software attack surface is reduced by fronting the application server with a security gateway that uses hardware logic to verify messages exchanged with a client. This is the same as disconnecting the application server from the client network, except that the application can still exchange messages.
Conclusion
When cold wallets are not in use, they are disconnected and cannot be used by an attacker. However, as soon as they are connected to a computer, they can be used inappropriately by an attack that has control of that computer. It is difficult to attack the wallets of many users in this manner without being discovered because those wallets will only be brought online over a long period of time.
Hot wallets are convenient and necessary for high-volume trading, but they are always vulnerable to attack from the computer in which they are stored or connected, so it is not advisable to store highly valuable assets in them. Because all wallets are online, they can all be attacked at the same time, making it simple to coordinate a large-scale attack. [Protecting a Hot Wallet Service]
To enjoy the convenience of a hot wallet while maintaining the security of a cold wallet, the wallet management application can be moved into a protected service. In the same way that an offline cold wallet cannot be attacked from the outside, the service can still exchange messages with clients to perform transactions.
This level of security cannot be provided by software because the software may be flawed and vulnerable to attack, but hardware logic can be used instead. This ensures that message exchanges adhere to the specified protocol and that the message contents are valid and secure. Because hardware logic is exposed to any attacker, the application provides no attack surface – similar to a disconnected cold wallet.
The High Speed Verifier from Forcepoint is a hardware logic appliance designed to allow information to be exchanged between systems that cannot be connected due to the risk of cyber attack. It offers a scalable solution to the problem of protecting a hot wallet service in the same way that a cold wallet is protected. [Protecting a Hot Wallet Service]
