In the [first post of this series](https://cubist.dev/blog/staking-keys-status-quo) we went over the basics of what you need to do to secure your staking keys: (1) use a remote signing tool and (2) ensure that the remote signer both _stores_ and _signs_ in secure hardware---otherwise an attacker can just exfiltrate your keys from memory. But as we hinted in the post, this is not enough.<br> <br> ## The attacker model<br> <br> To understand what else we need, let's first look at the attacker model of a typical <a href="https://ethereum.org/en/developers/docs/nodes-and-clients/node-architecture/" target="_blank">proof-of-stake validator setup</a> with remote signing. At a high level, there are three moving pieces: the validator or consensus client (used to participate in consensus protocol), the execution client (used to execute smart contracts), and the remote signing service (used to sign requests for the validation client).<br> <br> <br> <br> The validator and execution clients are complex pieces of software that are exposed to untrusted network traffic and execute untrusted code, respectively. So, using a remote signer is good for security not only because it allows you to keep your keys in hardware, but also because it introduces a boundary between the complex attacker-facing code and the security critical code that handles keys. And, if we turn this boundary into a _secure isolation boundary_, we can even safeguard keys from completely compromised clients.<br> <br> ## Isolation<br> <br> Unfortunately, trying to get isolation by running an off-the-shelf remote signing tool like Web3Signer in a separate process won't cut it. An attacker that compromises a client (or any other service running on the same machine) could just read the memory of the signer process (e.g., by reading `/proc/{pid}/mem`).<br> <br> Enforcing isolation by running a remote signer in a separate VM or enclave also won't do. This is because existing tools don't consider the code that _interfaces_ with them to be untrusted: they'll (almost always) sign whatever you ask them to sign with any key at any time. The one exception to the sign-anything approach is slashing protections, but even then, existing tools assume that requests are coming from a trusted client. Retrofitting an existing tool to treat everything as untrusted is a whack-a-mole game of trying to insert the right security checks into the right parts of the codebase.<br> <br> ## Least privilege + compartmentalization<br> <br> Even if we win the game of whack-a-mole, this only solves part of the problem. Existing signers do _a lot_: they're essentially large, monolithic web apps. The code handling keys run in the same process as the code handling untrusted HTTP requests, the code parsing the untrusted JSON objects coming from other validators, the code communicating with a database that stores the anti-slashing data, the log4j code managing logs, etc. To safeguard your keys (and, e.g., sign in hardware), you would have to break this system into multiple compartments, each running with least privilege. The signing code that uses secret keys should not be able to talk to the network or filesystem, and your logging library should _definitely_ not be in your trusted computing base.<br> <br> An alternative approach---and the one we've taken---is to design the system to be least-privileged and compartmentalized from the start. Ground up, security-centric design is much easier to get right: it's far simpler to reason about what code *should* be allowed to do than to reason about what code *should not* be allowed to do. It's the same reason we all prefer allow-lists over deny-lists.<br> <br>