Key management
Blog posts
go back

You're likely not securing your staking keys properly

And it's (usually) not your fault

April 19, 2023
written by
Fraser Brown
Co-Founder & CTO
Riad Wabhy
Co-Founder & CEO
Deian Stefan
Co-Founder & Chief Scientist
Key management
Blog posts
You probably keep the serious keys—the keys that control 4 or 64 or 164 ETH—in cold storage. That's good security practice. You _know_ not to keep valuable secrets in memory, where an attacker can easily steal them.<br> <br> ### Why you should secure your validator keys<br> <br> But this best practice falls apart during "staking," participating in a blockchain's proof-of-stake protocol. On Ethereum, for example, staking validators sign attestations about every six minutes; pulling keys in and out of ledgers, 24/7, at couple-minute increments is a job that no one wants. Unfortunately, validator keys' availability requirements are at odds with their security requirements: if an attacker compromises a validator key, they can use it to sign messages that violate the rules of the consensus protocol. Such violations result in "slashing"—a forced exit from the network with a penalty of one ETH _and (often) up_ (the penalty calculation accounts for <a href="" target="_blank">many factors</a>). To take advantage of slashing, an attacker might, for example, steal validator keys and hold them ransom or use them to topple a rival staking service. <br> <br> ### Why the status quo is not working<br> <br> So how do stakers protect their validator keys today? Some configure their local validator client (e.g., <a href="" target="_blank">Lighthouse</a> or <a href="" target="_blank">Prysm</a>) to use encrypted keys stored in a password-protected "keystore" file. That might be OK, except that by default the password is also stored in a file, usually in a neighboring subdirectory. And, of course, the validator still holds unencrypted keys in memory when it's running (which, if all goes well, is all the time).<br> <br> Many security-conscious stakers rely on remote signing software like <a href="" target="_blank">Web3Signer</a>, which manages keys and signs transactions. To use Web3Signer, you can—but shouldn't!—give it access to your raw, unencrypted keys. Configuring the signer with access to keys stored in HashiCorp Vault, Azure Key Vault, or Amazon Secrets Manager seems safer: these services protect keys using Hardware Security Modules (HSMs), special-purpose, tamper-proof hardware built to securely store secrets. The catch—and as we'll find out in future posts, not the only catch—is that this configuration only protects keys when they're not being used! [^hsm] To produce validator signatures, Web3Signer must retrieve the key—which once again exposes raw, unencrypted secret keys to attackers. <br> <br> ### How you should secure your keys<br> <br> To defend against real attacks, you need to store keys and sign transactions using secure hardware. That way, your keys never leave a cryptographically secured, tamper-proof environment even when they're being used. At Cubist, we've been actually building such a system—turning years of academic research on systems security, verification, and cryptography into key-management practice. Our next few blog posts will walk you through how our key management system works (spoiler: it's more than just secure hardware!). But you don't have to wait to start using it, learn more at <br> <br> [^hsm] <small>HSMs are typically certified to meet very high standards of security like FIPS-140. This is great because it means that HSMs are very carefully designed and vetted—but unfortunately it also means that they generally support only a limited range of cryptographic algorithms. We don’t know of any commercially available HSMs that support the BLS signature scheme used by Ethereum validators.</small><br> <br>

Read more

Cubist & EigenLabs anti-slasher collaboration

Cubist is excited to announce a new partnership: we are working with EigenLabs to build anti-slashers that will help honest operators avoid getting slashed on EigenLayer.

September 19, 2023

Hardware-backed signing for MetaMask developers

Our Snap lets Snap- or dapp-developers use CubeSigner, our hardware-backed key management system, to safely sign transactions on behalf of their MetaMask users.

September 12, 2023

Intel SGX is broken (again)

Last week, security researcher Daniel Moghimi publicly announced the new Downfall attack that can steal private keys from Intel SGX hardware. In this post, we review the SGX architecture and discuss its underlying security problems. Then, we describe the process we used for evaluating which secure hardware to use in our key manager.

August 15, 2023