Secure Infrastructure for Trusted Hardware

July 3, 2025

It is useful for servers to handle sensitive data in a way that keeps secrets hidden even from its operators. Secure hardware (also known as secure enclaves or trusted execution environments) which physically isolates sensitive data and computation to prevent unauthorised access is a common way to do this.

This post dives into one battle-tested approach towards secure hardware infrastructure in the cloud. It introduces StageX, a fully bootstrapped, reproducible, and auditable build toolchain that thwarts supply-chain attacks. It also describes QuorumOS, an execution layer for in-enclave applications that ensures that no single actor can compromise private keys. Readers will appreciate the importance of secure build processes and multi-party key generation, and be empowered to apply this stack to strengthen their own secure hardware infrastructure.

Note: this post refers to secure enclaves hosted in servers, such as Amazon Nitro, not those built into hardware wallets and mobile devices.

Stopping supply-chain attacks

Secure hardware must run uncompromised code. The challenge is that modern software depends on a large number of third-party packages. If an attacker compromises just one dependency, they can execute harmful code. Such supply-chain attacks are intensifying. In a recent incident, the user interface of a popular multi-signature wallet was infected as a result of a developer’s machine being compromised. The attackers specifically targeted a large centralised exchange and modified a transaction payload to steal more than $1.4 billion worth of funds.

Secure enclaves are just as vulnerable to such attacks, even if they run code in trusted hardware. Compromised code, especially that which handles private keys, can enable theft. The only way to defend against these attacks is to fully secure the software build processes and audit every single line of code that handles sensitive data or processes. Implementing such defenses, however, is far from trivial.

First of all, the amount of code in third-party dependencies is vast and complex. In some cases, one can either replace these packages either with much simpler ones, or clone their bare-minimum features for one’s project. This can shrink the attack surface of the final product and reduce the scope of audits.

Secondly, code authenticity and exact reproducibility must go hand in hand to guarantee code integrity. Teams must ensure that only the code they wish to compile and deploy is used, and nothing else. One way to do this is to make sure that multiple developers can independently verify and compile cryptographically hashed and signed code into the exact same binary.

Finally, teams must lock down the compiler. As Ken Thompson argued in Reflections on Trusting Trust (1984), benign code can compile into a malicious binary if the compiler is compromised. This leads to a recursive problem: even if one is sure that a compiler’s own code is benign, how can one know if the compiler that compiles it is malicious or not? One way to solve this problem is to bootstrap the entire compiler toolchain from fully open-source code and zero third-party binaries. The process starts from basic tools built with basic assembly, to a simple C compiler, to a full build toolchain capable of compiling Rust or other modern languages. This is difficult but necessary.

Removing single points of failure

Teams that custody private keys within secure enclaves must also prevent single points of failure, such as theft from within or key loss. No single employee should have access to any user’s private key, and it must always be possible to securely recover keys from loss.

One such incident occurred in 2018, when the founder of a large Canadian exchange either passed away or disappeared, causing $200 million of funds to be stuck, all because only he held its private keys. Another exchange saw six-digit losses when a single rogue employee stole their private keys via a USB drive. As crypto transactions are irreversible, companies must prevent such issues before they happen.

Recall that secure hardware is suitable for scenarios in which users trust operators, and can physically isolate computation and data from other parts of the system. To avoid any single party from stealing private keys, teams can set up a workflow where multiple trusted members contribute shares of a private key such that it stays within the secret enclave. Key isolation can therefore be achieved via Shamir’s secret-sharing scheme and strongly enforced operational security processes to prevent collusion among team members. This minimises the risk that a small number of team members can steal funds. Furthermore, key-shares can be backed up to prevent catastrophic key loss even if hardware fails.

Introducing StageX and QuorumOS

As described above, setting up secure infrastructure to prevent supply chain attacks and mitigate single points of failure is difficult. Fortunately, one such software stack is already open-source and available: StageX and QuorumOS. The wallet infrastructure company Turnkey (a Bain Capital Crypto portfolio company) already uses these tools to secure more than $100B in assets.

StageX provides fully auditable, bootstrapped, and reproducible build toolchains for software projects which demand high levels of code authenticity and integrity — exactly what is needed for software that runs in secure enclaves. It starts from an extremely small and auditable assembler (hex0) that compiles hexadecimal text files into binary executables. hex0 compiles more complex compilers (such as hex1 and hex2), progressively producing all that is needed to compile a functioning build toolchain, while solving the recursive problem of untrusted compilers.

All code that runs in an enclave still needs to be audited. This is unavoidable, but StageX streamlines and simplifies this process. Since it produces deterministic builds, and compiled binaries are hashed and signed, auditors can keep track of code, and system administrators can be assured that what they run is authentic.

QuorumOS is a system designed to ensure that secure hardware executes exactly the programs that it is given, and that these programs can access private keys that no individual team member can reconstruct alone. Before executing trusted programs (known as pivot binaries), QuorumOS requires a threshold of signers (e.g. 5 out of 7 team members) contribute cryptographic key shares. When it receives enough shares, it securely reconstructs a secret quorum key within the enclave. This quorum key can then be used for cryptographic operations, such as hierarchically generating more private keys, signing transactions, or encrypting and decrypting data. Since a threshold of signers is needed, no single team member can steal private keys, and key-shares can be backed up to prevent catastrophic loss.

StageX and QuorumOS work hand in hand to establish trust and security. When deployed with strong operational security practices, the former makes it feasible to thwart supply chain attacks, while the latter prevents fund theft or key loss due to single points of failure.

What about zero-knowledge proofs, etc?

Informed readers may wonder if zero-knowledge proofs are relevant to this discussion about trusted hardware. Others may wonder about other programmable cryptography techniques like fully homomorphic encryption. I argue that these techniques are fundamentally incommensurable with trusted hardware, ¹ although much industry discourse lumps them together and leads to much confusion.² Nevertheless, the overlap between programmable cryptography and trusted hardware is worth discussing a a future post.

Conclusion

Teams that run secure hardware must treat security as their highest duty. This research note highlights what truly matters for trust and security with secure hardware: software infrastructure and human processes. Teams should think of enclaves as only part of broader systems that must defend against software supply chain attacks and remove single points of failure. Without these protections, even trusted hardware is insecure. Fortunately, battle-tested infrastructure like StageX and QuorumOS demonstrate that it is possible to get this right. Users who put their trust in such teams deserve no less.

Credits

Many thanks to Arnaud Brousseau, Aayush Gupta, and Kobi Gurkan for their invaluable feedback and comments on this post.

Footnotes