TEE Anchor: Introducing a Mechanism to Preemptively Block Physical Attacks on TEEs

TEE (Trusted Execution Environment) is one of the core technologies that Acompany leverages in both its research and its products. Recently, physical attacks against current TEEs have emerged as a realistic threat. In this article, we introduce "TEE Anchor," a newly developed mechanism that can be used to counter these physical attacks on TEEs indirectly but effectively.

The Threat of Physical Attacks on TEEs

In 2025, physical attacks against TEEs known as TEE.fail [1] and Battering RAM [2] were announced. These attacks attach an attack device called an interposer to the DRAM section of the machine (computer) running the TEE, and then either read the traffic flowing over the DRAM bus or, by grounding, tamper with (alias) the physical location in memory being operated on, thereby extracting the secret information that the TEE protects.

Each of these attack papers goes beyond merely stealing secrets: they also extract the key generally known as the Attestation Key. This key is a secret held uniquely by the hardware and is indispensable for producing the TEE's identity certificate (Attestation Report), which allows the correctness of the TEE to be verified remotely. As a result, the possibility has emerged that an attacker who is not a TEE at all could forge an Attestation Report, shaking the very foundation of trust in TEEs.

Since a text-only explanation can be hard to follow, let us look at photographs of the actual attacks and attack devices.

As you can see, the attacker physically accesses the target machine, attaches the attack device, and literally carries out a "physical attack." Note that "physical attack" here does not include things like smashing the machine with a sledgehammer. If pulverizing it with a hammer is the quickest form of "physical availability attack," then these attacks might be called "physical confidentiality and integrity attacks."

Until these attacks appeared, physical attacks of this kind were recognized as an issue but left unaddressed as unrealistic. However, the attack setup can now be built for USD 1,000 in the case of TEE.fail and a mere USD 50 in the case of Battering RAM, which puts it well within reach of any reasonably motivated enthusiast.

The root cause of these physical attacks on current TEEs lies in the fact that TEE memory encryption uses deterministic encryption schemes such as AES-XTS and AES-XEX. These schemes use the physical address as the tweak, which conversely means that if the same plaintext is placed at the same physical address, the resulting ciphertext will always be the same as long as the encryption key is unchanged. Both TEE.fail and Battering RAM exploit the fact that this ciphertext can be reproduced simply by matching the physical address.

In addition, although it has not been confirmed as of July 2026, at least in publicly available information, a stronger physical attacker could carry out the following steps:

1. Read and back up a specific memory page at some point in time $t$
2. Wait until the point in time $t’$ at which the target processing takes place
3. Once time $t’$ arrives, write the backed-up memory page back to the same location

This constitutes a physical memory rollback attack. For example, if a program is implemented such that secret information resides in memory at time $t$, is then wiped and replaced with public information, and is transmitted externally at time $t’$, it is clear that this attack becomes a fatal threat.

What did protect against these physical confidentiality and integrity attacks was the legacy Intel SGX, now discontinued, that was built into client machines (such as Core-series CPU machines). This legacy SGX had the CPU hardware manage a counter value that was incremented on every write, with its integrity maintained by a Merkle tree also managed by the CPU hardware. By using this counter value as the tweak during memory encryption, it prevented these physical attacks.

The price the legacy SGX paid for this, however, was a severe degradation in performance. As a result, maintaining a practical speed as a TEE imposed extremely tight memory size constraints: at most 512 MB per TEE, and typically 128 MB (of which only 96 MB was actually usable by the user).

Current SGX has greatly relaxed this size limit, but in exchange the strong hardware-based countermeasures found in the legacy SGX have been lost. Likewise, the encryption schemes assumed by other major TEEs such as Intel TDX, AMD SEV-SNP, and Arm CCA are equally insufficient as countermeasures against physical attacks.

As this situation makes clear, countering physical attacks while maintaining performance requires the following two things:

• Reviving non-deterministic encryption of the kind the legacy SGX had.
• In light of the large-scale workloads that TEEs are now expected to handle, avoiding the memory size constraints of the legacy SGX while also keeping processing speed high.

From the standpoint of current TEE and hardware technology this is close to magic, so there is no chance of building it and releasing it to the world any time soon. Moreover, even if it were released, one would need a CPU equipped with a compatible memory encryption engine, which generally requires hardware-level replacement. And existing machines that cannot be replaced would remain exposed to the threat of physical attacks.

Weaknesses of TEE Physical Attacks

TEE physical attacks look quite threatening from what we have seen so far, but they also have two major weaknesses that cannot be ignored.

First, the physical attack itself is by no means easy. The papers give the impression that the setup can be built and applied casually, but it is clear that the electronics work and the reverse engineering required to establish attack patterns demand considerable dedication. Beyond building the interposer, the attack process also combines various known advanced attack techniques (e.g., SEV-Step and Controlled-Channel Attacks). It further requires a detailed understanding of the target, cryptography included, so it is not an easy attack open to just anyone. Broadly the same argument applies to the many TEE attacks proposed to date.

Second, and importantly, the attack simply cannot be carried out without physical access to the machine. As reflected in the CVSS scoring criteria, where attacks requiring physical access are assigned the lowest score coefficient, the bar here is far higher than for attacks that can be mounted remotely.

Let us give a more intuitive example. If someone were to force their way into a data center guarded by armed security personnel and attempt something like TEE.fail, the attacker would likely be "physically handled" right at the gate and that would be the end of it. What is more, the location of a data center is often kept secret in the first place, and if it cannot be identified there is no way to attack it.

Conversely, a "stray machine" such as one an individual keeps at home can be manipulated at that person's sole discretion, which makes it a "dangerous" machine from the perspective of physical attacks. The experiments by the papers' authors are the prime example of mounting physical attacks on machines they themselves own.

The official TEE.fail site itself pokes fun at this, captioning the data center attack photo shown above with "Are You Crazy?! Who Will Let You Into a Datacenter With This Thing!"

A New Security Requirement: "Proof of Affiliation"

In short, given that we cannot address the root cause in hardware today, one of the most effective ways to counter physical attacks is to prove that "the machine is managed by a trustworthy organization (one with tight security)" — in other words, that "the machine belongs to a trustworthy organization."

The foremost example of a trustworthy organization is a cloud vendor that manages machines in a heavily guarded data center. This is somewhat ironic, given that one of the main motivations for TEEs in the first place is protection from privileged entities on the host side (of course, current TEEs can still protect against a "cloud vendor mounting privileged software-based attacks").

At the same time, depending on the circumstances there can well be organizations that the parties involved agree to regard as trustworthy — for example, a particular financial institution or organization, a particular defense or military organization, or a particular (consensus-approved) Web3 community. Given that the requirement to treat an arbitrary organization as trustworthy can arise depending on the situation, being locked in to a specific cloud vendor is insufficient.

The problem, however, is that few existing technologies can provide such proof of affiliation. Conventional RA (Remote Attestation) can check the security level and behavioral definitions of a TEE machine and TEE instance and confirm that they match expectations, but — with the exception of AMD SEV-SNP — it cannot confirm which organization manages the machine.

With SEV-SNP, using the VLEK (Versioned Loaded Endorsement Key) — generated from a secret shared between AMD and the cloud vendor — as the AK allows a verifier to be confident, by verifying its signature, that the Attester (the TEE machine under verification) belongs to that cloud vendor. However, the specification states that the VLEK is not intended to be made available to parties other than cloud vendors [3], and it is limited to SEV-SNP, so it lacks both deployability by arbitrary organizations and cross-TEE applicability.

At the same time, with attacks this sensational in the news, various communities have hardly stayed quiet, and a number of proposals for proof of affiliation have appeared in the wake of these physical attacks (details below). However, none of them satisfies all of the following requirements for proof of affiliation; each sacrifices one or more of security, performance, and flexibility:

• It offers cross-TEE applicability, so that proof of affiliation can be applied to every current TEE.
• It keeps the performance overhead of applying proof of affiliation to a minimum.
• It requires no additional trust in components that TEEs normally place outside the trust boundary, such as the TPM.
• Conventional RA can still be performed (verified) by the Verifier or the remote user (Relying Party; RP) themselves, without excessive delegation of trust that would make even the execution of RA dependent on a specific organization.
• Proof of affiliation can be deployed by any organization.

All five of these requirements are indispensable if any organization is to easily provide affiliation assurance for its machines — across all TEEs and with security maximized — as a countermeasure to physical attacks.

TEE Anchor: Satisfying All Five Requirements

TEE Anchor, which we have newly developed, satisfies all five of the requirements above while providing assurance of organizational affiliation as a countermeasure to physical attacks. The core idea is to have the organization's root CA certify (sign and issue a certificate for) the CPU identifier (Chip ID) of the TEE machine, thereby guaranteeing its affiliation through the organization's own PKI.

In today's mainstream TEEs, the Chip ID can be extracted either from the TEE's Attestation Report (AR) or from the TEE vendor-issued certificate that authenticates it (hereafter we refer to these collectively as RA evidence). For each TEE, the following values, for example, can be used as the Chip ID:

• Intel SGX/TDX: PPID (Platform Provisioning ID). Extractable from the PCK Cert (the TEE vendor-issued certificate)
• AMD SEV-SNP: CHIP_ID. Extractable from the Attestation Report
• Arm CCA: cca-platform-instance-id. Extractable from the Attestation Report (Platform Token)

TEE Anchor has two main functions — provisioning and verification — and these form its core. It also provides a function for initializing the organizational CA needed for provisioning, as well as a function for revoking the certificate issued to a particular machine. All of these are offered as a CLI tool that can be easily invoked by running the tee-anchor command on the CLI (or as a subprocess). It is about as easy to use as virtee's snpguest, and another benefit is that it does not require the effort of deeply embedding it into your code the way SGX/TDX RA does.

Another strength is that verification only requires invoking the command after conventional RA verification has been performed, so affiliation assurance can be verified non-invasively, without breaking existing RA implementations.

Provisioning Phase

Provisioning in TEE Anchor is the procedure by which the organization managing a machine issues a certificate for the Chip ID of the managed TEE machine, anchored in the organization's root CA. Building on this, in the verification phase described later, the Verifier checks the signature on the issued and distributed certificate and compares the Chip ID embedded in that certificate with the Chip ID contained in the AR or TEE vendor certificate actually supplied by the Attester. If they match, the Verifier can be confident that the Attester machine genuinely belongs to that organization.

To perform provisioning, you first initialize the organizational CA with a TEE Anchor subcommand (including publishing the root CA certificate to Verifiers), and then obtain the RA evidence on the TEE machine the organization intends to manage. You then verify the signature on the RA evidence to confirm, as a precaution, that it is genuinely certified with the TEE vendor's root CA as the trust anchor.

Once confirmed, the next step is to extract the Chip ID from the RA evidence. An X.509 certificate embedding that Chip ID in an X.509 extension is then issued using the organization's root CA private key. This produces a two-level certificate chain consisting of the organizational leaf certificate containing the Chip ID and the organizational root CA certificate that authenticates it. The Attestation Key (AK) public key that authenticates the AR of that TEE is used as the To Be Signed key of the organizational leaf certificate, but since it plays no particular role in TEE Anchor, this is nothing more than a placeholder measure.

The organization then distributes this organizational certificate chain to Verifiers. Various distribution methods are conceivable, but this falls outside TEE Anchor's responsibilities, so TEE Anchor does not provide a distribution mechanism. Using this organizational certificate chain, a Verifier can confirm whether the machine under verification genuinely belongs to a trustworthy organization.

Extraction of the RA evidence is the one step outside TEE Anchor's scope and must be handled by each user, but the TEE Anchor GitHub repository provides sample extraction programs — simple ones — for each TEE. Everything from there through creating the organizational certificate chain can be done easily by running TEE Anchor subcommands.

As a precondition, this provisioning, the initialization of the organizational CA itself, and the revocation process described next must all be carried out by the organization in a physically secure state. Since guaranteeing that third parties cannot mount physical attacks (e.g., through tight security) is the fundamental premise of a trustworthy organization in TEE Anchor, this condition is automatically satisfied as long as a trustworthy organization performs these steps.

Revocation

For example, when an organization disposes of a machine it managed, the machine leaves that organization's control at that point, so the organizational certificate for it must be invalidated. Also, if the AK is compromised by means other than a physical attack, the conventional approach is to report the incident and have the TEE vendor revoke it; but because there is lead time for both the report and the vendor's response, having the organization revoke it directly can well be faster acting.

To prepare for such scenarios, TEE Anchor also provides a function for revoking issued organizational leaf certificates. Using a TEE Anchor subcommand, the organization can take the certificate to be revoked as input, add it to a revocation database (a simple text format in the current implementation), and generate a Certificate Revocation List (CRL) based on that database.

The verifying side can optionally take this CRL as input, in which case an additional revocation check is performed.

Verification Phase

In the verification phase, the verifier first performs conventional RA against the Attester and confirms, as usual, that the TEE meets the Verifier's expected requirements. If the signature on the AR is wrong, the TEE vendor certificate has been revoked, the measurements do not match expectations, and so on, there is no need to bother verifying the proof of affiliation, and the process can simply end there.

Once conventional RA verification succeeds, the verifier then additionally runs the TEE Anchor verification subcommand. For SEV-SNP this simply means calling tee-anchor after running snpguest; for TDX it means calling it as a subprocess from the program after verifying the Quote (AR) via the DCAP API. As noted above, it can be carried out non-invasively with respect to existing RA implementations.

TEE Anchor verification begins by extracting the Chip ID from the RA evidence. Since conventional RA should already have been performed, it should already be established that the RA evidence carries the TEE vendor's endorsement; nevertheless, as a precaution, the current implementation has TEE Anchor verify once more that a signature anchored in the TEE vendor is present.

Next, using the organizational root CA certificate received in advance, it verifies the organizational certificate chain received from the organization and confirms that the organizational leaf certificate was genuinely issued by that organization. It then extracts the Chip ID from the organizational leaf certificate and checks it against the one extracted from the RA evidence. If they match, the Verifier can be confident that the Attester genuinely belongs to that organization, so it treats the Attester as trustworthy and proceeds with the subsequent processing it wishes to perform with the TEE. If they do not match, affiliation with a trustworthy organization cannot be confirmed, so it refuses any further interaction and terminates.

As mentioned earlier, if a CRL is passed to this verification as an optional input, a check against the revocation list is also performed, making it possible to detect revoked certificates.

TEE Anchor verification, performed after conventional RA, is likewise easy to carry out by simply running a TEE Anchor subcommand.

Performance

Turning to the performance evaluation of the TEE Anchor described so far, verification completes in less time than conventional RA takes to run (snpguest certs + snpguest attestation should be used for SEV-SNP), so the overhead can be considered acceptable. Furthermore, conventional RA in practice also involves obtaining and transferring the RA evidence along with various other processing, including remote communication; once those parts of conventional RA, which fall outside the measurements in Figure 5, are taken into account, TEE Anchor's overhead is all the more negligible.

All the other subcommands, including the verification subcommand, also complete within 10 ms, so we can conclude that the implementation is quite lightweight overall.

Comparison with Related Approaches

TEE Anchor is thus a very simple mechanism that nonetheless covers the essential points. Next, we examine how it differs from various existing approaches (we will not revisit AMD SEV-SNP's VLEK, which was already discussed above).

Below is an arbitrary scorecard comparing the related approaches with TEE Anchor.

Intel POE

Intel POE (Platform Ownership Endorsements) [4] issues an Endorsement for a Chip ID called the PIID (not the PPID) in Intel SGX/TDX, and verifies it in addition to conventional RA. Since Endorsements can also be issued by parties other than Intel, its basic structure is of the same kind as TEE Anchor in that it allows deployment by arbitrary organizations and leverages a Chip ID-equivalent concept.

POE's biggest drawback, however, is that using it is said to require integration into DCAP, the complex RA infrastructure for Intel SGX/TDX. The official statement [4] explicitly says that its verification is planned to be implemented as one of DCAP's Quote verification libraries, which — as can be seen from Humane-RAFW-DCAP, which the author implemented and provides — presumably means it is carried out by calling the somewhat idiosyncratic DCAP API. Moreover, by its very nature it is completely locked in to SGX/TDX, so application to other TEEs is impossible.

Another major drawback of POE is that it is intended only for use with Intel SGX/TDX — in other words, it lacks cross-TEE applicability. Indeed, the repository [4] released at the same time as DCAP version 1.27 shows that it is provided strictly as part of DCAP for SGX/TDX, and direct use with other TEEs such as SEV-SNP is impossible. Likewise, the draft [10] proposing integration into CoRIM — the format used in RATS (RFC 9334), which standardizes RA, for enumerating reference measurements (expected measurements) — also reads as assuming application to Intel SGX/TDX only, showing that cross-TEE applicability is not taken into account.

In terms of freedom to deploy proof of affiliation it is superior to VLEK, but with respect to being locked in to a specific vendor and lacking cross-TEE applicability, it carries the same constraint as VLEK.

By contrast, TEE Anchor can be applied across all major current TEEs, which clearly differentiates it from POE.

DCEA and Dstack

DCEA (Data Center Execution Assurance) [5] is a proposal that authenticates the host-side vTPM using the TEE's AR and, in some cases, a host-side physical TPM Quote, and then issues a certificate for the EK — the parent key of that vTPM's AK — so that affiliation with the cloud vendor can genuinely be verified.

Dstack proposes something simpler: after confirming that the SGX/TDX PPID (Chip ID) belongs to the cloud vendor, it authenticates that machine's TPM AK with the TEE's AR and issues a TPM EK certificate so that its affiliation can be verified [6].

In other words, since the EK of the (v)TPM on the machine signifies affiliation with the organization (cloud), proof of affiliation should be achievable by these methods.

These are certainly viable options, but from the standpoint of proving affiliation they are undeniably somewhat excessive. First, because they depend on the TPM, they risk introducing additional TPM-specific attack vectors [7] that require no physical access. It would be putting the cart before the horse if the very mechanism meant to prevent physical attacks on TEEs were overturned by an attack on the TPM that requires no physical access at all.

The DCEA paper also reports experimental results showing that Quote generation alone takes about 550 ms with a physical TPM and about 300 ms with a vTPM. It is plain to see that this is very heavy compared with TEE Anchor, where each operation takes less than 10 ms.

Therefore, compared with these TPM-based approaches, TEE Anchor has the advantage in both security and performance.

Proof of Cloud Alliance

Proof of Cloud Alliance [8] is a framework in which multiple independent organizations verify the correspondence between a Chip ID and a verified physical location and register it in a signed, centralized, append-only registry that they jointly manage; it shares with TEE Anchor the use of Chip IDs. In essence, it is a scheme in which a Web3-style consensus-based collective controls Chip ID-based operations, and the operations around them, in a kind of majority-vote fashion.

However, registering a machine requires verification through heavy additional measures such as physical attendance by existing members, zk-TLS proofs, tamper-detecting RFID beacons, or the aforementioned DCEA. Adding an entry to the registry also requires a majority vote of existing members, and the Chip ID whitelist and revocation list must be fetched from a centralized database jointly managed by multiple organizations. This is a significant barrier for an organization that wants to deploy flexibly for its own operations.

TEE Anchor, by contrast, has each organization issue certificates with its own CA, so the organization can independently decide which machines it trusts. It also requires no participation in a centralized registry, no agreement among multiple organizations, and no costly verification procedures. In short, the design philosophies of the two — particularly around provisioning — differ substantially.

Whereas Proof of Cloud Alliance is oriented toward a shared registry among many mutually distrustful participants, TEE Anchor allows any single organization to introduce affiliation assurance on its own and in a lightweight manner; the two may look similar but their target use cases are quite different. Both can be differentiated in terms of application domain and operational cost, and if flexibility and lightness are the priorities, TEE Anchor is the better fit.

SPIFFE/SPIRE

SPIFFE/SPIRE is a framework that issues attestation-based identifiers called SVIDs to workloads, and Pontes et al. extended it to SEV-SNP CVMs [9]. In this scheme, a SPIRE server operated by the organization performs the TEE's RA, issues an SVID, and passes it to the end Verifier; the end Verifier checks the SVID, but it is not designed to perform conventional RA itself. By design, it looks only at the SVID it receives. Incidentally, this was not originally proposed as a countermeasure to physical attacks, but its properties make it repurposable for that to a fair degree.

Like Microsoft Azure Attestation (MAA), this is a model in which even the execution of conventional RA is entrusted to and dependent on the organization. That is not inherently bad, since the organization is trusted by premise; but if the premise is to trust the organization only for physical management and affiliation assurance, one can view additionally trusting it with the execution of conventional RA as somewhat excessive.

TEE Anchor, on the other hand, has the Verifier perform conventional RA itself, keeping trust in the organization to a minimum — physically secure management of machines, provisioning, and the like. This too is not a matter of superiority but of a division of roles arising from different trust models: whether trust is centralized or left to each Verifier.

Conclusion

In this article we introduced TEE Anchor, which provides assurance that a TEE machine belongs to a trustworthy organization as a countermeasure to physical attacks, while balancing security, performance, and flexibility.

The implementation is available in the following GitHub repository.

GitHub - acompany-develop/tee-anchor: Ensures geographical security and prevents physical attacks by verifying the organisation to which the TEE machine belongs

Ensures geographical security and prevents physical attacks by verifying the organisation to which the TEE machine belongs - acompany-develop/tee-anchor

GitHub

We hope that TEE Anchor will go on to be used as one effective countermeasure against physical attacks on TEEs.

References

[1] J. Chuang, A. Seto, N. Berrios, S. van Schaik, C. Garman, and D. Genkin, “TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition”, in Proc. 47th IEEE Symp. on Security and Privacy (S&P), 2026. https://tee.fail

[2] J. De Meulemeester, D. Oswald, I. Verbauwhede, and J. Van Bulck, “Battering RAM: Low-Cost Interposer Attacks on Confidential Computing via Dynamic Memory Aliasing”, in Proc. 47th IEEE Symp. on Security and Privacy (S&P), May 2026. https://batteringram.eu/

[3] AMD, “SEV Secure Nested Paging Firmware ABI Specification”, Revision 1.58. https://www.amd.com/content/dam/amd/en/documents/developer/56860.pdf

[4] Intel, “Platform Ownership Endorsements for Confidential Computing.”, accessed 2026/8/17. https://github.com/intel/confidential-computing.tee.dcap.poe/tree/main

[5] F. Rezabek, M. Mahhouk, A. Miller, Q. Kilbourn, G. Carle, and J. Passerat-Palmbach, “Proof of Cloud: Data Center Execution Assurance for Confidential VMs”, arXiv preprint arXiv:2510.12469, 2025.

[6] Dstack-TEE, “TEE: TPM-Based Approach to Code and Location Verification #626”, accessed 2026/6/25. https://github.com/Dstack-TEE/dstack/discussions/626

[7] D. Moghimi, B. Sunar, T. Eisenbarth, and N. Heninger, “TPM-FAIL: TPM meets Timing and Lattice Attacks”, in Proc. 29th USENIX Security Symposium (USENIX Security 20), pp. 2057–2073, 2020.

[8] Proof of Cloud Alliance, “Proof of Cloud”, accessed 2026/6/25. https://proofofcloud.org

[9] D. Pontes, F. Silva, E. Falc˜ao, and A. Brito, “Attesting AMD SEV-SNP Virtual Machines with SPIRE”, in Proc. 12th Latin-American Symp. on Dependable and Secure Computing (LADC ’23), pp. 1–10, 2023. https://doi.org/10.1145/3615366.3615419

[10] Mateusz Bronk et al., “A CoRIM Profile for Intel Platform Ownership Endorsements (POE)”, accessed 2026/8/17. https://datatracker.ietf.org/doc/draft-bzb-rats-intel-poe-endorsements/