Everyone's talking about the sanctity of the MRENCLAVE and MRSIGNER measurements as if they're immutable proof of your enclave's integrity. That's the theory. In practice, I've seen more drift in these values during what should be routine, identical deployments than I care to count. The tooling for actually tracking this is either buried in verbose SDK output or requires you to trust another opaque cloud provider dashboard.

I built a CLI tool to cut through that. It's called `enclave-diff`. It doesn't manage your deployments; it just tells you if the TCB you *think* you're running matches the one you're *actually* running. The core problem it solves is that a single-bit change in your enclave's code, dependencies, or even build environment can—and will—alter your measurement. If you're not checking this at every deploy, your entire remote attestation chain is built on sand.

Here's how you use it. You point it at two signed enclave packages (or at the measurement registers extracted by your attestation service), and it gives you a structured diff of the components that contributed to the measurement.

```bash
# Basic usage: compare two local .signed.so files
enclave-diff compare
--old ./release/v1.2.1/enclave.signed.so
--new ./release/v1.2.2/enclave.signed.so
--output markdown

# Or, compare against a canonical measurement from your manifest
enclave-diff verify
--enclave ./new_deploy.signed.so
--expected-mr-enclave 0xabc123...
```

The output breaks down the potential sources of change:
* **MRENCLAVE Delta:** Flags if the core identity hash differs.
* **MRSIGNER Delta:** Flags if the sealing authority changed.
* **Build Report:** Parses the SIGSTRUCT and shows you:
* `isvprodid`, `isvsvn` changes
* `attributes` bitfield changes (e.g., debug mode toggled)
* A list of linked dependencies and their hashes from the `.sgx.dynsym` section, highlighting any that changed between builds.

Why is this necessary? Because "secure by default" toolchains will still give you a new measurement if your CI runner gets a library update. If you're sealing data inside the enclave, a mismatched measurement means you can't unseal. That's an outage. This tool is meant to be run in your pipeline *before* you cut over traffic.

It's written in Rust, of course. The current limitations are:
* Only supports Intel SGX format directly (`.signed.so`, `.dll`). For other platforms (SEV, etc.), you need to feed it the raw measurement values.
* It doesn't explain *why* a dependency hash changed, only that it did. That's your job to trace back through the build cache.

The repo is over at [REDACTED]. It's early, but the parsing logic for the SGX structures is solid. I'm looking for feedback on what other data sources it should ingest—maybe direct integration with Azure's attestation service logs or AWS Nitro PCR outputs.

The takeaway: If you're not actively diffing your enclave measurements between deploys, you're not doing operational security; you're just hoping. And hope is not a strategy.

-- Dave