If you've been to a threat modeling workshop, you'll remember being asked to identify something valuable—an heirloom jewelry set, say—and then being asked how to protect it. _Hide it in the basement_, someone will propose. Another: _Set a booby trap!_ A third: _No, that's illegal_. It will go on this way until the workshop organizer says _we need a framework for thinking about how to protect the jewels_. They'll introduce an "attacker model": the model against which your jewel protection setup is secure. Closing your front door is secure against people who respect doors. Locking your door and setting your alarm is secure against garden variety thieves, but not against a professional who's been surveilling your home.<br> <br> Attacker models make it possible to reason beyond the security of your hypothetical jewel box—and, if you're in web3, towards more realistic valuables like private keys. Since keys are your most precious crypto possession, it's worth thinking through the attackers capable of compromising them. This post does that thinking while giving you a glimpse into the threat modeling we did when we designed <a href="https://cubist.dev" target="_blank">CubeSigner</a>.<br> <br> There is a reason we didn't take the YOLO approach (signing in the browser) or the marketing-driven approach (MPC).<br> <br> ## The goal: keep keys safe<br> <br> A good key manager makes sure that you can use your keys and that attackers can't. Things like performance and flexibility are <a href="/blog/mpc-does-have-a-single-point-of-failure" target="_blank">important</a>—performance problems become security problems when, for example, traders are forced to use hot wallets because more secure wallets are too slow (yes, we've seen this in the wild!). But that's not the focus of this blog post. Here, we ask: _What kind of attacker could extract private keys from a given key management setup?_<br> <br> <br> ## The question: under which attacker model is a key manager secure?<br> <br> Now that we've defined our goal, we can think about realistic attacker models against which different key managers are secure. Let's warm up by analyzing a clearly broken approach: give everyone and everything a copy of your key. You're running a DeFi firm? Every automated trading workflow gets a copy of the keys. You're building a consumer wallet? Great, your users store their keys on their phone, their laptop, their other laptop, and iCloud. _Hmmm_, you think to yourself, _that sounds like a really terrible idea._ You're right! And you're right because the attacker model for give-everyone-the-keys _makes no sense_: copying keys and passing them out like candy is fine as long as every human being and every machine is perfectly correct and perfectly honest. It's an attacker model in a world with no attackers.<br> <br> But what about the approaches real, production key managers use today? Let's see when and if they make sense.<br> <br> ## Approach #1: YOLO. Sign in the browser.<br> <br> Signing in the browser is a relatively common strategy for wallet-as-a-service providers. First, the key manager stores keys offline—for example, in Hashicorp Vault or AWS Secrets Manager, or maybe split (or "sharded" or "secret shared") across multiple devices. Then, when a user requests a signature, the key manager retrieves or reconstructs the keys and pulls them into the browser. There, a piece of JavaScript uses the keys to sign whatever transactions the user requested.<br> <br> <br> How can an attacker defeat a browser-based key manager? There are (roughly) two options: (1) break into Vault/Secrets Manager/shard storage or (2) steal keys from the browser wallet. You need to believe that a realistic attacker can't accomplish either goal in order to believe that the key manager is secure—and one goal is much easier than the other. While targeting Vault is <a href="https://www.cvedetails.com/vulnerability-list/vendor_id-16814/product_id-70468/Hashicorp-Vault.html" target="_blank">possible</a>, attackers have better access to weaker prey online. In the browser, keys are handled by JavaScript, which every browser vendor (and JavaScript engine engineer) will tell you will result in you leaking your secrets. But JavaScript aside, you need to consider <a href="https://www.coindesk.com/business/2023/10/17/fantom-foundation-wallets-drained-657k-stolen/" target="_blank">browser</a> <a href="https://www.coinbase.com/blog/responding-to-firefox-0-days-in-the-wild" target="_blank">bugs</a> and <a href="https://cointelegraph.com/news/google-ads-delivered-malware-drains-nft-influencer-s-entire-crypto-wallet" target="_blank">malicious ads</a> and <a href="https://www.coindesk.com/business/2023/10/30/lastpass-hack-victims-lose-44m-in-a-single-day/" target="_blank">compromised extensions</a> and <a href="https://cointelegraph.com/news/ethereum-vitalik-buterin-x-hackers-drain" target="_blank">malicious links</a> and <a href="https://docs.ethers.org/v5/concepts/security/" target="_blank">side channel attacks</a> and <a href="https://cointelegraph.com/learn/what-is-a-phishing-attack-in-crypto-and-how-to-prevent-it" target="_blank">social engineering attacks</a> and more—no matter how the key is stored or sharded.<br> <br> The fossil record is littered with carcasses lost to the tarpit of web crypto. Learn more in our <a href="/blog/why-you-should-never-handle-private-keys-in-the-browser" target="_blank">blog post/depressing natural history exhibit</a>.<br> <br> ## Approach #2: Drink the kool-aid. Sign with MPC.<br> <br> MPC (short for multi-party computation) is a powerful cryptographic tool that allows mutually distrusting parties to jointly compute over data while keeping that data private. To put it in key management terms: different parties (e.g., a user's phone and a remote server) get pieces of a private key, and then sign using a protocol that ideally (1) doesn't reveal the key shares and (2) doesn't explicitly reconstruct the key in memory.<br> <br> And again we ask ourselves, _against what sort of attacker is the MPC-based key manager secure?_ At first glance, a persistent and sophisticated one: the attacker has to compromise _multiple_ parties in order to reconstruct the private key, since the MPC signing protocol never materializes the key in memory. Theoretically, adding more parties makes the attacker's job harder. In practice, though, most MPC-based key managers deploy _exactly_ the same software for each party—and they often deploy that software on the same cloud infrastructure from the same administrative account. As a result, if one party falls, they all do: compromising _every_ party is just a matter of executing the same remote attack two or three or four times—as in the <a href="https://cointelegraph.com/news/the-aftermath-of-axie-infinity-s-650m-ronin-bridge-hack" target="_blank">$650M Ronin bridge hack</a>—and then reconstructing the key from the stolen shards.<br> <br> But the attacker may not even have to compromise the parties if it manages to steal the key while the protocol executes. A correct multi-party signing protocol will never reconstruct or leak the key, but an incorrect one sure can—and, since MPC-based signing protocols are brutally complex for most relevant signature schemes, there's a long and evolving history of broken protocol descriptions. Even if the protocol itself is correct, the (also brutally complex) protocol implementation <a href="https://www.coindesk.com/tech/2023/08/09/fireblocks-discloses-zero-day-vulnerabilities-impacting-leading-mpc-wallets/" target="_blank">may</a> <a href="https://www.verichains.io/tsshock/" target="_blank">not</a> <a href="https://www.coinbase.com/blog/the-subtleties-of-error-handling-flaws-in-mpc" target="_blank">be</a>. Recently, for example, an implementation bug allowed an attacker who simply observed network traffic to completely reconstruct the private key.<br> <br> ## Approach #3: Simple and boring. Sign in secure hardware.<br> <br> Another approach to key management is to store keys and sign transactions entirely in secure hardware. The term "secure hardware" is a broad one: mobile phones, credit cards, Ledgers, cloud servers, hardware security modules (HSMs), and other devices include hardware that stores and processes secrets while promising that those secrets can't be extracted or copied. In other words, secure hardware turns secrets like signing keys into physical objects.<br> <br> In order to believe that a hardware-backed key manager is secure, you have to believe that an attacker cannot physically steal the underlying hardware or violate its guarantees. Whether that belief is realistic depends on the hardware. Intel's SGX, for example, has been <a href="https://cubist.dev/blog/intel-sgx-is-broken-again-what-the-downfall-attack-means-for-secure-hardware" target="_blank">broken continuously since its invention</a>, but many other kinds of secure hardware have strong security track records—and you already use and trust them every day.<br> <br> Virtually all banks use <a href="https://cpl.thalesgroup.com/faq/hardware-security-modules/what-payment-hardware-security-module-hsm" target="_blank">payment HSMs</a> for everything from <a href="https://www.usenix.org/system/files/sec21fall-gaddam.pdf" target="_blank">PIN processing</a> to issuing credit card numbers, and the Public Key Infrastructure that secures the internet (and thus all e-commerce) roots its trust in HSMs. This is because <a href="https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-641.pdf" target="_blank">essentially all known key extraction attacks</a> on HSMs require physical access to the HSM itself and access to an advanced laboratory. As a result, stealing keys requires breaking into a bank or data center and then breaking into a lab that has an electron microscope (instead of, say, sitting in the comfort of your own basement, watching network traffic or waiting for someone to click the link in a phishing email).<br> <br> <br> ## Why CubeSigner uses secure hardware<br> <br> We considered both MPC (which we've <a href="https://eprint.iacr.org/2023/060" target="_blank">worked</a> <a href="https://cseweb.ucsd.edu/~dstefan/pubs/mitchell:2012:information.pdf" target="_blank">on</a> academically) and secure hardware when we were designing CubeSigner. (We've also worked on many JavaScript and browser attacks and defenses—which is why we did not consider using JavaScript to implement serious cryptography in the browser.) Ultimately, we chose hardware[^1]—combined with physical isolation for side-channel resistance—because it's secure _in theory and in practice_ against realistic attackers. While we ❤️ MPC as academics, its practical guarantees don't measure up to its theoretical promise—and likely won't for a long time. Proving an MPC protocol or implementation correct, for example, is still an open research question. In contrast, we're working towards correctness proofs for our enclave-bound key management code today.<br> <br> <br> _For a less snarky and more technical rundown of key management tradeoffs, check<br> out our CEO Riad's <a href="https://www.youtube.com/watch?v=zyImxswXiVI" target="_blank">talk at the DeFi Security Summit 2023</a>._<br> <pre> <br> <br> </pre> [^1]: After considering many options, we went with <a href="https://cubist.dev/blog/intel-sgx-is-broken-again-what-the-downfall-attack-means-for-secure-hardware" target="_blank">HSMs and AWS’s Nitro enclaves</a>.<br> <br>