Protecting a Hot Wallet Service

Acash wallet is where you keep your valuable cash. If you lose it, you lose your money. So you keep it physically secure at all times and don’t give it to anyone else.

___________________________________________________________

A digital wallet is used to store valuable digital currency. A digital wallet needs a key to open it, but if you lose the key someone else might be able to open it without you knowing, so losing the key effectively means you have lost the wallet and the money it holds.
While you can open a cash wallet with your hands, to use a digital wallet you need a computer. The digital wallet might just be some data, and the software to handle it, stored on your computer – this is called a hot wallet, because it is ready to go at any moment. Alternatively, the wallet might be a separate device you attach to a computer when you need to use it – this is called a cold wallet, because you have to plug it in and start it up from cold to use it.
Unfortunately, while you are in control of your hands, you are not necessarily the only one with control of your computer. If an attacker has control of your computer, they are in a good position to 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 the means of delivering malware to your computer. Cold wallets are harder, because the attacker must coordinate their attack with your use of the device. For this reason, crypto currency providers and financial regulators recommend, or even mandate, the use of a cold wallet for storing large amounts of currency. Hot wallets are loaded with modest amounts for instant use and are topped up from the cold wallet when required. This is like having a cash wallet that is topped up from a cash machine when it is running low.
Cold wallets must be used carefully, and their keys must be well protected, but this is difficult, and their use can be time consuming and error prone.
A digital wallet service, which takes responsibility for the security of the wallets of many customers, could improve security, but such a service will always be online and so is “hot”, which is contra to common advice and regulation. This paper considers the problem in detail, comparing the security of cold wallets against a hot wallet service. It shows that, with proper protection in the service, it is possible to provide a hot wallet service that offers protection equivalent to using offline cold wallet devices.

• Cold Wallets

A person who needs to authorise digital financial transactions from time to time must hold a cryptographic private key. This key represents their digital identity and must be kept private – not divulged to anyone else, as doing so would allow others to impersonate them.
The cryptographic mechanism employed means the user can authorise transactions using their private key without divulging it. Devices are available that hold the private key and authorise transactions if a password is presented. These are specially designed to ensure the private key cannot be extracted from the device, even with unfettered physical access, and transactions can only be authorised if the password is known.
When a user first obtains a device, it contains no private key. When it is initialised, it generates a private key that it stores. It also produces a public key that is revealed, which can be used by anyone to prove that a transaction was authorised by the device.
If the user makes occasional transactions, the device that holds their private key can be kept offline except for when they need to make a transaction. To make a transaction, the user needs to provide their password and a unique identity for the transaction. The device then returns a digital signature value for the transaction. The password could be entered through a keypad on the device, but the transaction identity is too long to be entered this way and the signature is too long to be copied from a screen on the device. This means the device must be taken online (plugged into a computer) while the transaction is being authorised.
While the user holding the device can be sure that no transaction is authorised unless they provide their password, a weakness in all this is that they get no indication of what they are authorising. They are viewing details of the transaction using their computer, and in theory the unique identity of this is what they are authorising, but the computer’s software could instead provide the identity of some other transaction and the user would be unaware of this at the time. In addition, if the password is entered into the device via the computer, it is possible for the software to authorise several transactions without the user knowing while the device is plugged in.
However, attacks like this would require a degree of sophistication and as soon as one user detects a discrepancy in their transaction record it is likely that an investigation would reveal the attack and it would be stopped. So, to be an effective attack, it would have to be targeted at a single high-worth user or coordinated over many users. A coordinated attack must be delivered to large numbers of users and remain hidden before striking simultaneously against any device that is online, which makes it difficult to do.
The main security advantage of having a separate device to hold the private key used to authorise transactions is that it cannot be used when not connected to a computer. It requires the physical intervention of the user before it can be used. This forces an attack to focus on the time it is connected, and while this is quite feasible as the computer presents a large attack surface, it is much harder to attack large numbers of users because the attack must be coordinated to avoid discovery before the attack is complete.
The need to connect a device each time it is to be used is an inconvenience and is not suitable if transactions are made frequently. If the private key could be managed by a service provider and the security measures taken to protect it were equivalent, this would allow transactions to be signed more easily, allowing transactions that had not previously warranted this level of protection to be signed.
On a related note, in cases where the digital identity needs to be linked to the user’s real physical identity, the device must produce a request for its private key to be certified. This request is passed to a central authority which confirms the user’s real identity and issues a certificate that declares the user is in possession of the private key. All this is done without revealing the private key. Subsequently, anyone with a copy of the certificate can confirm that a transaction has been signed by the device that the user registered. It is important that the registration process confirms the user’s identity, because if a user can register their device in someone else’s name, they will be able to authorise transactions in that person’s name. The device needs to be online while engaging in the registration process, as the data involved is too long to copy by hand.

• Protecting the Key

A device held by a user to protect their private key is not shared, but a service provider needs to hold the private keys for many users. This requires a special form of device (a Hardware Security Module – HSM) that can be trusted to protect many keys. The shared device is housed in a server room and must always be connected to the service provider’s network. When a transaction needs to be authorised, the client must first authenticate to the shared device. The device then selects the client’s private key and uses it to sign the transaction.
Just like a private device, the shared device is trusted to not divulge the private keys, but it is also trusted to pick the correct private key when asked to sign a transaction. A password is typically used to authenticate the client, and so a password management mechanism must also be supported, and this too needs to be trusted to not divulge clients’ passwords or to allow them to be modified by other clients. Passwords must be transferred between client and server securely, which involves using cryptographic mechanisms to create a secure channel.
All this functionality increases the complexity, and so lowers the trust, in the shared device. It is also difficult to make such a device meet large scale requirements. So, in practice the implementation is split. An application server handles the authentication of clients, and the special shared device just handles the private keys and the cryptographic operations needed to authorise a transaction.
This means the private keys are well protected against disclosure, but there is much less assurance that the keys will only be used appropriately. It becomes the responsibility of the application server to authenticate clients and match their requests to the correct private key in the shared device. A stronger solution would be to have the HSM challenge the user to use their password to authenticate directly, but this adds complexity which increases the attack surface of the HSM.
Where the clients hold their own private keys in their own devices, a large-scale attack requires considerable skill and careful coordination, and cannot exploit the keys in devices that are not connected. However, with the keys held centrally in a shared device that is always online, a large-scale attack is much simpler – it need only take control of the application server to have the freedom to use any private key.
A managed key service has a large attack surface, as it requires a complex application server to control access to the hardware device that holds all the private keys and is always online. The only way to ensure it provides protection equivalent to a personal key device is to make the attack surface inaccessible, without preventing it from handling legitimate transactions.

• Protecting the Key Service

Placing a security gateway computer in front of the application hides the application server’s attack surface. The attacker instead sees the attack surface of the security gateway. This ought to be smaller, but the attacker may still be able to take control of the security gateway and disable it, allowing them to subsequently fully target the application server’s attack surface.
Thus, the risk is reduced but not eliminated, so such a solution is not equivalent to have an offline device. The problem here is that one software stack (that of the application server) is replaced by another (that of the security gateway), and a software stack is always sufficiently complex for there to be flaws and weaknesses that can be exploited.
However, a security gateway need not be a computer. Forcepoint’s High Speed Verifier (HSV) is a hardware logic device that is designed to connect highly critical systems to untrustworthy networks without presenting any software attack surface to an attacker.
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 – other messages are discarded. The verification of the message data is implemented in hardware logic not software. Also, the protocol used to pass the messages through the verifier is handled by the hardware logic, so the verifier component has no software attack surface.
Unfortunately, the data formats and protocols in common use are complex and need software to handle them. Only by keeping the formats and protocols simple it is possible to handle them in logic. So, the HSV uses software to convert between the complex data formats and protocols needed by applications and the simple data formats and protocols supported by the logic. Although complex, the conversion software is not security critical – if an attacker takes control of it, all they can do is pass messages that are allowed anyway.
By fronting the application server with a security gateway that uses hardware logic to verify the messages that are exchanged with a client, the software attack surface is eliminated. This is the same as disconnecting the application server from the client network, except that it is still possible to exchange the messages needed by the application.

• Conclusion

Cold wallets are disconnected when not in use, and they cannot be misused by an attacker in this state. But as soon as they are connected to a computer, so they can be used legitimately, they can be used inappropriately by an attack that has control of that computer. To attack the wallets of many users in this way, without discovery, is difficult because those wallets will only be brought online over a protracted period.
Hot wallets are convenient, and essential for high-volume trading, but a hot wallet is always open to attack from the computer it is stored in or connected to, so it is ill advised to store highly valuable assets in them. As all wallets are online, they can all be attacked in parallel, making it easy to coordinate a widespread attack.
To benefit from the convenience of a hot wallet, while having the security benefits of a cold wallet, the application for managing the wallets can be moved into a protected service. The service is protected so that it cannot be attacked from the outside, in the same way as an offline cold wallet, but it can still exchange messages with clients to perform transactions.
This kind of protection cannot be provided by software, since that software might itself be flawed and vulnerable to attack, but hardware logic can be used instead. This verifies message exchanges are following the designated protocol and that the message contents are valid and safe. Hardware logic faces any attacker, and as a result the application presents them with no attack surface – much like a disconnected cold wallet.
Forcepoint’s High Speed Verifier is a hardware logic appliance that has been designed to allow information to be exchanged between systems that cannot be connected because the risk of cyber attack is too great. It provides a scalable solution to the problem of protecting a hot wallet service to the same degree as a cold wallet.