Don't let TEEs break your MPC

What it is

Trail of Bits' analysis of running threshold-signature MPC inside TEEs (Intel TDX, AMD SEV-SNP, AWS Nitro Enclaves). The summary already covers the central rollback attack and the pitfall catalog. What it omits are several concrete, actionable specifics an engineer can check against their own deployment.

What to do

Beyond "bind attestation to party identity" and "use multiple vendors," the post states these that the summary does not:

• Override Intel's attestation grace period. Intel's vendor verification tools accept known-vulnerable firmware versions for one full year after public disclosure. The post recommends implementing your own security version number (SVN) validation on top of the defaults to enforce stricter deadlines — otherwise a compromised-but-patched-window firmware passes remote attestation cleanly.
• **Terminate peer-to-peer channels inside the enclaves.** Establish TLS (or equivalent) with endpoints inside the secure enclaves themselves, not on the host, so the untrusted host cannot observe or tamper with protocol messages in transit.
• Write constant-time crypto even inside the TEE. The host controls scheduling and can measure timing; constant-time implementations are still required for all secret-processing operations.
• Never pull code at runtime (e.g., curl-ing tools into the enclave). Anything fetched after measurement is unmeasured; an attacker controlling that source gets attested-but-unverified code execution. This is the same class as the WhatsApp LD_PRELOAD bypass.
• Trim and measure the image. Redundant kernel drivers, permissive kernel config flags, stray ACPI entries, unnecessary systemd services/timers, and weak entropy sources all sit inside the trust boundary — remove, harden, then measure what remains.

The freshness through-line

The post frames three separate attacks as the same failure — authenticated encryption gives confidentiality and integrity but not freshness:

• filesystem rollback replaying a deleted pre-signature file (nonce reuse → key-share leak);
• DDRop: a sub-$200 DDR5 interposer that silently drops memory writes so the CPU rereads stale-but-validly-decrypting data, breaking integrity on Intel TDX, Scalable SGX, and AMD SEV-SNP;
• LUKS2 header malleability serving stale/null-cipher volume state.

Memory encryption without freshness fails the same way stale disk state does. If you defend against one, check the other two.

Caveats

The post's own limits: multi-vendor deployment is "challenging in practice" due to operational complexity, and it recommends it only for high-security applications. The overall verdict is that TEE+MPC is worthwhile only as defense-in-depth over a sound protocol — never as a substitute for one.