A cash 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.
Protecting Crypto Assets
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.
2. 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.
3. 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 th
Leave a Reply