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="https://eth2book.info/bellatrix/part2/incentives/slashing/" 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="https://lighthouse-book.sigmaprime.io/intro.html" target="_blank">Lighthouse</a> or <a href="https://github.com/prysmaticlabs/prysm" 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="https://docs.web3signer.consensys.net/" 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 https://cubist.dev/keys. <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>