Your Bitcoin Wallet May Be At Risk: Safenet HSM Key-Extraction Vulnerability

As a next generation Bitcoin exchange, ensuring the security of bitcoin on deposit is Gemini’s top priority. Perhaps more so than credit-cards, ACH or any other payment systems, Bitcoin is the one payment technology where possession of money can be boiled down to pure cryptographic capability: generating a signature with an ECDSA private key is money. If you lose control of that private key, you lose the ability to spend your funds, plain and simple.

With adoption of strong cryptography, direct attacks against cryptographic algorithms and protocols have become increasingly rare, although not extinct, as demonstrated by WEP, MD5, GSM encryption and the never-ending saga of TLS vulnerabilities. Far more common, however, are system failures caused by inadequate key management (i.e. when secrets are mishandled) that allow attackers to bypass the cryptography altogether. To that end, Hardware Security Modules (HSMs) have been promoted as best practice for implementing strict control over private keys. An HSM is a special-purpose, tamper-resistant device for managing cryptographic keys. They are not general-purpose computers meant for everyday use or extensibility; there is no Angry Birds app. In fact, there is no keyboard/mouse or an elaborate LCD display for interacting with the device. Instead they must be connected to a trusted client — an ordinary computer that instructs the HSM over a minimalist interface tailored for cryptography — in order to generate new keys, perform specific operations using those keys and destroy said keys when they are no longer needed or desired.

With respect to Bitcoin companies, many offline “cold” vaulting systems (including Gemini’s) utilize HSMs in an “M-of-N” multi-signature security design whereby HSM transaction signers are held in separate, air-gapped, secure physical storage locations. No one particular HSM can spend funds on its own. Instead, a quorum of several HSMs are required to sign and thereby validate a given transaction with their private keys, effectively making the quorum of HSMs the manifestation of funds on deposit (i.e., money held in custody).

Critical to this security design is that secret keys never leave the HSM itself; all operations take place within the secure execution environment of the HSM. For example, when decrypting a message, the ciphertext itself is sent to the device, where it is decrypted using the private keys held by (and inside of) the HSM and the decrypted message is returned back. This is distinct from a non-HSM device that actually reveals the private key to the attached trusted client to “borrow” for performing some operation. It is a fundamental design objective of HSMs to never reveal keys, not even to trusted clients when connected.

At Gemini, we have evaluated several different HSM models. One of the first vendors we reached out to was Safenet, recently acquired by the French conglomerate Gemalto. Safenet produces a family of HSMs, ranging from USB-attached compact Luna G5 to the network-connected SA7000, which is used by Amazon in its CloudHSM offering where AWS customers can lease access to a device. While evaluating the Luna G5, we discovered a vulnerability that allows the extraction of secret keys. As it turns out, the problem is not unique to the G5; it applies to the entire family, including the PCIe version, as well as the networked appliance featured in CloudHSM.

What makes this vulnerability somewhat unusual is that it is a consequence of following a standard too closely, as opposed to the more common problem of diverging from established practices. Safenet HSMs are closely based on the PKCS#11 specification. This is a de facto standard designed to promote interoperability between cryptographic hardware by providing a consistent software interface. Imagine how difficult it would be to write a cryptographic application — such as a Bitcoin wallet — to work with external hardware if each device required a different API for signing a Bitcoin transaction. Certainly, the differences between devices are apparent: some connect over USB while others are addressed over TCP/IP. Each device typically requires a different device driver much like different brands of printers do. But once your HSM is connected, PKCS11 seeks to provide a higher-level point where these differences can be abstracted behind a unified API, with a vendor-provided PKCS#11 module translating the software concepts into the appropriate commands for that brand of hardware.

PKCS #11 defines a series of “mechanisms” that a particular model of hardware can support. These include the usual suspects such as block ciphers (AES, 3DES, etc.) stream ciphers (RC4) keyed-MACs (HMAC, CBC-MAC), asymmetric encryption (RSA), key-agreement (Diffie-Hellman) and digital signatures (RSA again, ECDSA, etc.). PKCS #11, however, does not mandate that a particular mechanism be implemented by a given device, only a way to interrogate the device hardware to determine what is supported. Vendors can also define additional proprietary mechanisms as long as their identifiers do not conflict with the standard. It turns out that Safenet products implement a substantial amount of PKCS #11-defined mechanisms, and that is the problem. Not all of the ideas in PKCS #11 mechanisms are good. In particular, we found that several key derivation mechanisms create weak keys that can be brute-forced easily to recover the original key in a matter of seconds.

Successful exploit requires authenticated access to the HSM, which can be done by subverting the legitimate trusted client that was using the HSM. That may sound like a prohibitive requirement or even tautological — “if your trusted client is compromised, then your cryptographic keys are also compromised.” But HSMs are specifically designed to survive that threat model — the assumption goes that even if an adversary obtains temporary access to the secure physical storage location of the HSM, they can only perform limited operations with the stored key. They can not just ask the HSM to cough up a copy of its stored secrets. This type of vulnerability breaks that model: temporary access can be leveraged to fully exfiltrate both public and private keys and use them in the future, independent of the device.

As a matter of principle, we do not release weaponized exploits or proof-of-concept code that shows how to utilize a given bug. Instead we practice responsible disclosure by working closely with vendors to help them find a solution to fix vulnerabilities, and then publish our findings after a patch is available to the public. We reported the vulnerability to Safenet on January 30th, 2015. It was confirmed by the vendor on February 11th, 2015 and a security update for affected products has been released on July 9th, 2015. We plan to publish a follow-up post with additional technical details. For now it’s worth pointing out that the vulnerability affects all symmetric keys and some private-key types, including ECDSA keys used in Bitcoin. If you have been using Safenet HSMs for managing Bitcoin keys, your wallet may be at risk. Due to the nature of the vulnerability, it is not possible in all cases for customers to work-around the problem without applying the firmware update. In particular, having the HSM set to strict FIPS mode does not mitigate the risk. We encourage customers to upgrade to the latest version released by Safenet [Bulletin]. Users leasing an HSM via Amazon CloudHSM service should consult specific instructions provided by AWS.

You can find a more detailed description of this vulnerability here.

CVD ID: 2015–5464