ChainPro Security and TEEs

When we set out to build ChainPro, we needed industrial grade security for the strategies we want to run for users. We need whales to trust us with 7 figure TWAPs. We need funds to trust us with their centralized exchange (CEX) API keys as our infrastructure automates funding rate arbitrage for them. The best technology that makes all of this possible are Trusted Execution Environments, TEEs for short.

TEEs are private, confidential computing environments. Under the hood we rely on Turnkey for private key management. On top of them we built an execution engine using TEEs (specifically AMD SEV-SNP on Azure Confidential Compute) so that users can securely automate trading strategies. Two important properties of our infrastructure are:

1. Only the user and TEE have access to the user's private keys and CEX API keys, ensuring  nobody else can access them.
2. Automations can only run inside the TEE and must be pre-approved by the user.

With those two properties, our execution engine is a secure extension of your computer.

What follows is a technical deep-dive into our architecture, AMD SEV-SNP, and attack surfaces. Non-technical readers can leave beforehand knowing the following: ChainPro provides the same security properties as popular wallets like Phantom and Metamask but is much more powerful. In the future we will add higher security options as well for users that need security comparable to hardware wallets and multisigs.

Technical Architecture

Chainpro’s architecture has been designed for performance and security. Users can authenticate through three options: email, email with a passkey, or a crypto wallet. A time-bound session key securely stored in the browser or mobile app, similar to how Hyperliquid and dYdX store API wallets in user’s browser Our approach additionally adds the restriction that these keys are time-bound and stored in IndexedDB rather than Local Storage. This reduces the surface area for a hack, compared to our peers.

When creating an order (e.g., limit, TWAP, scale) via our TEE-based execution engine, the user generates a task key to sign transactions. This key is encrypted with the TEE’s public key, ensuring only the TEE can access it. The user signs the order and submits it to ChainPro’s API, which monitors it for execution (e.g., tracking price feeds for limit orders). Once ready, the API sends the order to the TEE, which decrypts, validates, and executes the transaction.

Centralized Exchange API keys follow the same process. They are encrypted with the TEE’s public key, ensuring that neither our team nor any external party can access them.

By design, the TEE-based execution engine only executes pre-approved transactions, validated via a user’s cryptographic signature. Our engine has been rigorously audited by the elite team at Spearbit Cantina. Looking ahead, we plan to open-source the TEE code and support remote attestations, allowing anyone to verify the integrity of the code running in our TEEs.

TEEs in Detail: AMD SEV-SNP

For our Trusted Execution Environment we use AMD Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP). SEV-SNP relies on two trusted components: the Secure Processor and Virtual Machines (VMs). Other system components, such as the hypervisor or operating system, are not assumed to be trusted, which ensures that data and code remain confidential and tamper-proof, even if the underlying host system is compromised.

VMs host applications like our execution engine. All VM memory is encrypted using a unique encryption key provided by the Secure Processor. The Secure Processor performs the heavy lifting, not only securing per-VM encryption keys but also managing:

• Attestation Reports: Produces attestation reports signed with a unique public-private key pair created during chip manufacturing. These reports verify the integrity of the VM and its workload.
• Integrity Validation: Ensures VM launches are legitimate, detecting any unauthorized modifications or tampering.
• Hardware Integrity Checks: Continuously monitors for physical tampering with the chip.
• Secure Boot: Enforces a secure boot process, ensuring only trusted firmware runs on the Secure Processor.
• Access Control: Detects and prevents access control violations, maintaining strict isolation of trusted components.

Encryption and decryption operations within the execution engine add only microseconds of latency. Execution latency is on the order of milliseconds so running the execution engine within a TEE significantly improves security without meaningfully impacting performance.

Build and Runtime Integrity

Build and runtime integrity for all wallets (e.g. ChainPro, Phantom, Gnosis Safe, etc.) is critical for safeguarding user funds. For all wallets, if a malicious developer is able to push changes to a user’s devices, the user’s funds are at risk.

The execution engine deployment process is multiple steps and requires approval from multiple team members, ensuring no single individual can initiate a deployment unilaterally. At the beginning of the build process, the execution engine’s code is compiled, signed and manually verified by multiple team members. During runtime, Microsoft Azure Attestation automatically verifies the source code hasn’t been altered and that it is running on AMD SEV-SNP hardware. If any discrepancies are detected, the execution engine will fail to run.

Attack Surfaces and Mitigations

While our architecture is designed with robust security measures, no system is entirely immune to threats. Below, we outline potential vulnerabilities, their implications, and the mitigations we employ.

Physical and Side-Channel Attacks:

• Risk: Attackers with physical or low-level access to machines at Azure Data Centers could attempt physical attacks (e.g., tampering with hardware) or side-channel attacks (e.g., analyzing power consumption or cache timing) to extract sensitive data from the TEE.
• Mitigation: Azure Data Centers employ stringent physical security, including armed guards, surveillance, and access controls. AMD SEV-SNP’s Secure Processor includes hardware integrity checks to detect tampering as well as mitigations for side-channel attacks.

Deployment of Malicious Code:

• Risk: Deploying bad code to the TEE, whether intentional (e.g. by a malicious developer) or accidental, could compromise the execution engine in production, potentially enabling unauthorized access to user funds. This risk is universal across wallet deployments, including MetaMask, Phantom, and hardware wallets.
• Mitigation: Our deployment process requires approvals from multiple team members. Code is signed and verified via Microsoft Azure Attestation during build and runtime, ensuring only trusted code runs. Regular audits, including by Spearbit Cantina, further reduce this risk.

Transaction Replay:

• Risk: Transaction replay attacks, where a valid transaction is maliciously re-executed, could lead to unintended financial losses. Enforcing replay protection within the TEE is challenging, as it requires maintaining a trusted state.
• Mitigation: We implement multiple checks and precautions outside the TEE, such as nonce validation and transaction uniqueness checks, to prevent replays. Furthermore, permissions are updated post-order completion, blocking task keys from requesting signatures again. We have never experienced a replay issue yet in the future we plan to maintain a trusted state to prevent them altogether.

Malicious Software on User Devices:

• Risk: Malicious software, such as malignant Chrome extensions, phishing links, or social engineering scams, could compromise a user’s device and expose their ChainPro account. This vulnerability is universal across all wallets, including Phantom, MetaMask, Gnosis Safes, and hardware wallets.
• Mitigation: Unfortunately, there is no direct defense against compromised user devices, as this lies outside our control. We educate users on best practices, such as avoiding suspicious links and using secure environments. Our time-bound API keys and IndexedDB storage reduce the attack window, but user diligence remains critical.

Bugs in Microsoft Azure or AMD SEV-SNP:

• Risk: A bug in Azure’s infrastructure or AMD SEV-SNP could undermine the TEE’s security guarantees, potentially exposing sensitive data within our execution engine.
• Mitigation: Both Azure and AMD SEV-SNP are well-audited, with extensive testing and industry adoption. We continuously monitor for vulnerabilities and apply patches promptly.