This is the second in a series of posts exploring the various approaches to safeguarding crypto assets. In the first post we explained our method and looked at the most common attack vector – physical access. This post goes into the other, more sophisticated vectors that could be used to get unauthorized access to a private key and the asset it holds. We’ll also explore various systems that offer protection against failure of the storage medium.
We compared Multi-Signature, Multi-Party Computation, and Hardware Security Modules to find out which one would be the best at protecting crypto-currencies and assets while also meeting operational, business, and regulatory requirements. This is part II in our series of blogs.
The recent disclosure of Plundervolt showed that side-channel attacks are alive and well, even on supposedly secure enclaves. These software vulnerabilities allow attackers to use manipulation or observation of the physical properties of hardware to extract what should be securely stored data – and that includes private keys.
Multi-signature complicates these types of attacks in an obvious way - it would require hackers to successfully run their attacks on multiple machines of potentially different types, presumably placed in different locations. Having at least one of the authorization devices offline at a physically segregated location minimizes the risk to virtually zero, but it comes at the cost of scaling and transaction speed.
The same goes for secure multi-party computation (SMPC) solutions, though it has an additional advantage: the shared key material is regularly rotated at random, so a highly coordinated effort would be required for such an attack to succeed.
Obviously, Hardware Security Modules (HSMs) are built to prevent exactly such attacks, especially the Primus HSMs by Securosys. We partnered with HSR to research side-channel attacks. As a result of a multi-year effort, our HSMs now have the capacity to implement effective countermeasures against such attacks.
In the next post we will take a look at side-channel attacks, randomization weakness, and quantum-protection.
Even though the byte size required to generate cryptocurrency keys makes it statistically impossible to generate two identical keys, computers are notoriously unreliable at generating true entropy (randomness). An adequately dedicated attacker might be able to use this weakness in software randomness to successfully replicate a private key.
Other enterprise software solutions based on either multi-signature or multi-party computation can overcome this issue by integrating a more scalable source of entropy for the key generation. However, in order to prevent a man-in-the-middle attack, they do have to keep the integration channel between the source and the software that generates the key secure.
This, again, is an area where even the “simple” legacy HSMs stand out with their very design – it was, after all, their original purpose. As demanded by the best practice and certification requirements in the industry, which typically include multiple sources of hardware entropy that are securely integrated within the key generation part of the module, HSMs can even prevent attacks on the integration architecture.
Another potential danger to current cryptographic algorithms comes from the promise of quantum computing, with which it might soon be possible to calculate the private key from the public key.
The software of cryptocurrency wallets deals with this naturally by following the practice established with Bitcoin and the intention of its inventor(s): only an address, which is a (double-)hash of the public key related to the asset’s private key, is used. Since such software is typically present in all multi-signature and SMPC applications, they are naturally robust against this attack vector despite their persisting vulnerability to others.
Legacy HSMs protect against physical, side-channel, and randomization vulnerabilities. However, they do expose their operators to this type of attack. This is because they require the operator to retrieve a potentially quantum-vulnerable public key. This public key then allows the business application to generate and use an address associated with the asset key.
Securosys HSMs deal with this potential vulnerability by allowing the developers to export the address only after the first signature with the private key. This way, the public key of the keys created and retained in the HSMs aren’t exposed until the asset has been withdrawn, thus rendering the key worthless.
Losing access to one’s keys is just as catastrophic as them being stolen or compromised – it means that, for all intents and purposes, one loses the cryptocurrency balance.
Traditional multi-signature-based solutions introduce various methods of protection against the loss of key material. The Glacier Protocol and similar concepts recommend using a sufficiently low quorum-to-group ratio (e.g. 2/5) with geo-redundant paper wallets stored in physically protected locations. While this is arguably acceptable as protection against physical damage, it is again very difficult to scale and useful only for individual holders. Other approaches might include a more automated digital backup of the keys. However, all of these have one thing in common - they increase the risk of keys exposure linearly to the number of locations where copies of the same key or multiple multi-signature keys are stored.
Because multi-party computation splits a single key, it is adequate to simply back up the key material in case of the loss of a required quorum. This, however, again introduces an additional point of exposure of the key material, which has to be physically protected.
While top-of-the-shelf HSMs use data storage with much higher reliability standards than traditional servers or PCs, their potential failure still can’t be ruled out. They must be protected against by redundancy or regular backups but are also notorious for a very complicated redundancy setup that can’t be scaled. Securosys HSMs address this issue by introducing a seamless redundancy setup process. This includes highly secure physical initial pairing using master-slave model with up to 64 devices as well as real-time, end-to-end encrypted synchronization.
In the following posts, we’ll explore various methods of transaction authorization. We’ll also get into the business and regulatory considerations, as well as the trade-offs involved in these approaches, and their respective developer experience.
You can find more information on the safeguarding of crypto assets here.