pith. machine review for the scientific record. sign in

arxiv: 2605.13676 · v1 · submitted 2026-05-13 · 💻 cs.CR

Recognition: unknown

EBCC: Enclave-Backed Confidential Containers via OCI-Compatible Runtime Integration

Di Lu , Qingwen Zhang , Yujia Liu , Xuewen Dong , Yulong Shen , Zhiquan Liu , Jianfeng Ma
Authors on Pith no claims yet

Pith reviewed 2026-05-14 18:01 UTC · model grok-4.3

classification 💻 cs.CR
keywords confidential containerstrusted execution environmentsOCI runtimeenclave integrationcontainer lifecycleKeystone TEE
0
0 comments X

The pith

EBCC lets TEE-backed confidential containers follow the standard OCI lifecycle without enlarging the protected TCB.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper introduces EBCC to treat REE-side anchors and TEE-side confidential stages as one composite container. It preserves ordinary OCI operations for deployment, monitoring, and control while routing TEE-specific work through a backend adapter. Persistent per-instance state and per-stage artifacts handle requests, responses, logging, and evidence without moving extra code into the protected environment. Implementation on Keystone plus cross-TEE mapping to SGX, TDX, and OP-TEE shows the approach works for enclave, VM, and embedded styles. Overhead appears mainly in host-side mediation steps while the protected TCB size stays essentially unchanged.

Core claim

EBCC treats the REE-side anchor and TEE-side confidential stages as a single containerized confidential-computing composite, preserves standard OCI lifecycle operations, and keeps TEE-specific execution behind a backend adapter. It also maintains persistent per-instance state and per-stage artifacts for request handling, response generation, logging, and evidence binding.

What carries the argument

The OCI-compatible runtime architecture that uses a backend adapter to mediate lifecycle operations between host and TEE while preserving per-instance state and artifacts.

If this is right

  • Standard OCI commands and tools become usable for TEE-backed workloads.
  • The protected-side TCB remains materially the same size.
  • The same stage abstraction maps to enclave-style, VM-style, and embedded-style TEEs.
  • Added latency comes from lifecycle mediation, validation, EID allocation, dispatch, and artifact persistence.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Existing container orchestration systems could schedule confidential workloads with little or no TEE-specific plugin work.
  • Developers could move sensitive code into TEE stages using familiar container images and commands.
  • Security reviews would concentrate on the adapter as the main new mediation surface.

Load-bearing premise

The backend adapter and lifecycle mediation preserve isolation and do not introduce new attack surfaces or require extra assumptions beyond standard TEE guarantees.

What would settle it

A concrete attack that exploits the host-side mediation layer to breach TEE confidentiality or integrity, or a measurement showing material growth in the protected-side TCB.

Figures

Figures reproduced from arXiv: 2605.13676 by Di Lu, Jianfeng Ma, Qingwen Zhang, Xuewen Dong, Yujia Liu, Yulong Shen, Zhiquan Liu.

Figure 1
Figure 1. Figure 1: Platform-independent architecture of EBCC. EBCC preserves the [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Internal responsibilities of the C4 OCI runtime. The runtime maps [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Keystone-based implementation of EBCC. The [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figure 5
Figure 5. Figure 5: End-to-end completion latency under light and heavy workloads. [PITH_FULL_IMAGE:figures/full_fig_p011_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Concurrent execution behavior under increasing concurrency levels. [PITH_FULL_IMAGE:figures/full_fig_p012_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Workload evaluation on SGX. The upper panel shows the light task, [PITH_FULL_IMAGE:figures/full_fig_p015_7.png] view at source ↗
Figure 9
Figure 9. Figure 9: Workload evaluation on OP-TEE. The upper panel shows the light [PITH_FULL_IMAGE:figures/full_fig_p015_9.png] view at source ↗
read the original abstract

Container runtimes provide a stable operational interface for deploying, monitoring, and controlling modern workloads, while trusted execution environments (TEEs) provide hardware-enforced isolation for sensitive computation. Existing confidential-container systems often rely on VM-backed deployment stacks or TEE-specific execution substrates, which can separate confidential execution from the conventional OCI runtime lifecycle. This paper presents EBCC (Enclave-Backed Confidential Containers), an OCI-compatible runtime architecture for managing composite confidential-computing workloads. EBCC treats the REE-side anchor and TEE-side confidential stages as a single containerized confidential-computing composite, preserves standard OCI lifecycle operations, and keeps TEE-specific execution behind a backend adapter. It also maintains persistent per-instance state and per-stage artifacts for request handling, response generation, logging, and evidence binding. We implement EBCC on a Keystone backend and evaluate its correctness, performance, footprint, and concurrent execution behavior. The results show that EBCC introduces additional latency over native Keystone execution, mainly due to lifecycle mediation, request validation, EID allocation, backend dispatch, and artifact persistence, while keeping the added footprint concentrated on host-side management state. Cross-TEE case studies on SGX, TDX, and OP-TEE show that the same lifecycle and stage abstraction can be mapped to enclave-style, VM-style, and embedded-style TEEs. These results indicate that EBCC can make TEE-backed execution manageable through an OCI-style lifecycle without materially enlarging the protected-side TCB.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 1 minor

Summary. The paper presents EBCC, an OCI-compatible runtime architecture that integrates TEE-backed confidential containers by treating REE-side anchors and TEE-side stages as a single composite workload. It preserves standard OCI lifecycle operations via a backend adapter, maintains persistent per-instance state and artifacts for request handling and evidence binding, and is implemented on a Keystone backend. Evaluations are described for correctness, performance, footprint, and concurrent execution, with cross-TEE mappings to SGX, TDX, and OP-TEE; the central claim is that this approach enables manageable TEE-backed execution through an OCI-style lifecycle without materially enlarging the protected-side TCB.

Significance. If the TCB claim is substantiated with measurements, EBCC would offer a concrete bridge between conventional container runtimes and hardware-isolated execution, reducing the need for VM-centric or TEE-specific deployment stacks. The Keystone implementation and cross-TEE case studies provide a practical demonstration of the architecture's portability across enclave, VM, and embedded TEE styles, which strengthens the contribution if accompanied by explicit TCB breakdowns and reproducible evaluation data.

major comments (2)
  1. Abstract: The claim that 'added footprint is host-side only' and that EBCC does not 'materially enlarge the protected-side TCB' is load-bearing for the central contribution yet is asserted without any code-size measurements, interface enumeration, or breakdown showing which functions (lifecycle mediation, EID allocation, artifact persistence, response generation, evidence binding) execute inside the enclave versus the adapter shim.
  2. Abstract (evaluation description): Results on latency, footprint, and concurrent behavior are referenced but no methodology, metrics, baselines, error bars, or comparison to native Keystone execution are supplied, preventing verification of the performance overhead or the TCB assertion.
minor comments (1)
  1. Abstract: The description of 'composite confidential-computing workloads' and 'per-stage artifacts' would benefit from an explicit diagram or table distinguishing REE-side versus TEE-side components to clarify the isolation boundary.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback on the abstract and evaluation claims. We address each point below and will revise the manuscript to provide the requested substantiation while preserving the core architecture description.

read point-by-point responses

  1. Referee: Abstract: The claim that 'added footprint is host-side only' and that EBCC does not 'materially enlarge the protected-side TCB' is load-bearing for the central contribution yet is asserted without any code-size measurements, interface enumeration, or breakdown showing which functions (lifecycle mediation, EID allocation, artifact persistence, response generation, evidence binding) execute inside the enclave versus the adapter shim.

    Authors: We agree the abstract assertion requires explicit support. The manuscript architecture (Section 3) places all new mediation, EID allocation, artifact persistence, and evidence binding logic in the host-side adapter shim, with the enclave executing only the original workload binary unchanged. In revision we will add a concise interface enumeration and code-size table (adapter vs. protected runtime) to the abstract and a dedicated TCB breakdown subsection, confirming no protected-side enlargement beyond the Keystone baseline. revision: yes

  2. Referee: Abstract (evaluation description): Results on latency, footprint, and concurrent behavior are referenced but no methodology, metrics, baselines, error bars, or comparison to native Keystone execution are supplied, preventing verification of the performance overhead or the TCB assertion.

    Authors: The full evaluation (Section 5) uses native Keystone execution as the direct baseline, reports average latency overhead for each lifecycle stage, host-only memory footprint deltas, and concurrent throughput with standard deviation from 10 runs. To address the abstract, we will insert a one-sentence methodology summary and key quantitative results (e.g., latency overhead range, host footprint increase) while keeping the abstract concise. revision: yes

Circularity Check

0 steps flagged

No circularity; design claims are architectural assertions without self-referential reduction

full rationale

The paper presents an OCI-compatible runtime architecture for TEE-backed containers, implemented on Keystone with cross-TEE mappings. No equations, fitted parameters, predictions, or derivations appear. The central claim that added footprint remains host-side only is stated as a direct consequence of the described separation between REE anchor and TEE stages, without reducing to a self-definition, self-citation chain, or renamed input. The architecture is treated as an independent design choice whose TCB properties follow from the explicit component boundaries given in the text.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 1 invented entities

The design rests on standard TEE isolation properties and OCI runtime stability; no free parameters are fitted to data and no new physical entities are postulated.

axioms (2)
  • domain assumption Trusted execution environments provide hardware-enforced isolation for confidential stages
    Invoked when stating that TEE-specific execution stays behind the adapter without enlarging protected TCB.
  • domain assumption OCI runtime lifecycle operations are stable and sufficient for composite workload management
    Used to claim that standard start/stop/monitor commands can be preserved for the REE-TEE composite.
invented entities (1)
  • EBCC composite confidential container no independent evidence
    purpose: Single unit that combines REE anchor and TEE confidential stages under one OCI lifecycle
    New architectural construct introduced to bridge conventional runtimes and TEEs.

pith-pipeline@v0.9.0 · 5582 in / 1277 out tokens · 42523 ms · 2026-05-14T18:01:49.441092+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

63 extracted references · 7 canonical work pages · 2 internal anchors

  1. [1]

    Crossing shifted moats: Replacing old bridges with new tunnels to confidential containers,

    E. Valdez, S. Ahmed, Z. Gu, C. de Dinechin, P. Cheng, and H. Jamjoom, “Crossing shifted moats: Replacing old bridges with new tunnels to confidential containers,” inProceedings of the ACM SIGSAC Conference on Computer and Communications Security (CCS), 2024. JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2021 18

    2024

  2. [2]

    Serverless confidential containers: Challenges and experiences,

    C. Segarra, T. Feldman-Fitzthum, and D. Buono, “Serverless confidential containers: Challenges and experiences,” in2nd Workshop on SErverless Systems, Applications and MEthodologies (SESAME), co-located with EuroSys, 2024

    2024

  3. [3]

    Scone: Secure linux containers with intel sgx,

    S. Arnautov, B. Trach, F. Gregor, T. Knauth, A. Martin, C. Priebe, J. Lind, D. Muthukumaran, D. O’Keeffe, M. Stillwell, D. Goltzsche, D. Eyers, R. Kapitza, P. Pietzuch, and C. Fetzer, “Scone: Secure linux containers with intel sgx,” in12th USENIX Symposium on Operating Systems Design and Implementation (OSDI), 2016, pp. 689–703

    2016

  4. [4]

    Occlum: Secure and efficient multitasking inside a single enclave of intel sgx,

    Y . Shen, H. Tian, Y . Chen, K. Chen, R. Wang, Y . Xu, Y . Xia, and S. Yan, “Occlum: Secure and efficient multitasking inside a single enclave of intel sgx,” inProceedings of the Twenty-Fifth International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), 2020, pp. 955–970

    2020

  5. [5]

    Graphene-sgx: A practical library os for unmodified applications on sgx,

    C.-C. Tsai, D. E. Porter, and M. Vij, “Graphene-sgx: A practical library os for unmodified applications on sgx,” in2017 USENIX Annual Technical Conference (USENIX ATC), 2017

    2017

  6. [6]

    Privacy-preserving container attestation,

    L. Ferro, E. Bravi, S. Sisinni, and A. Lioy, “Privacy-preserving container attestation,”Journal of Network and Systems Management, vol. 34, no. 1, p. 5, 2026

    2026

  7. [7]

    Confidential kubernetes deployment models: Architecture, security, and performance trade-offs,

    E. Falc ˜ao, F. Silva, C. Pamplona, A. Melo, A. S. M. Asadujjaman, and A. Brito, “Confidential kubernetes deployment models: Architecture, security, and performance trade-offs,”Applied Sciences, vol. 15, no. 18, p. 10160, 2025

    2025

  8. [8]

    Confidential containers self-assessment (cncf tag security),

    “Confidential containers self-assessment (cncf tag security),” 2024, accessed 2026-04. [Online]. Available: https://tag-security.cncf.io/community/assessments/projects/ confidential-containers/self-assessment/

    2024

  9. [9]

    Confidential containers: Attestation agent (github),

    “Confidential containers: Attestation agent (github),” 2024, accessed 2026-04. [Online]. Available: https://github.com/confidential-containers/ attestation-agent

    2024

  10. [10]

    Confidential containers trustee (kbs/kms) (github),

    “Confidential containers trustee (kbs/kms) (github),” 2024, accessed 2026-04. [Online]. Available: https://github.com/confidential-containers/ trustee

    2024

  11. [11]

    Confidential containers: Attestation service (consolidated into trustee),

    “Confidential containers: Attestation service (consolidated into trustee),” 2023, accessed 2026-04. [Online]. Available: https://github.com/ confidential-containers/attestation-service

    2023

  12. [12]

    Confidential containers: Attestation with trustee,

    “Confidential containers: Attestation with trustee,” 2025, accessed 2026-04. [Online]. Available: https://confidentialcontainers.org/docs/ attestation/

    2025

  13. [13]

    Trusted container exten- sions (tcx) for container-based confidential computing,

    F. Brasser, I. Roy, S. Shinde, and F. Schuster, “Trusted container exten- sions (tcx) for container-based confidential computing,”arXiv preprint arXiv:2205.05747, 2022

    work page arXiv 2022

  14. [14]

    Rcontainer: A secure container architecture through extending arm cca hardware primitives,

    Q. Zhou, W. Cao, X. Jia, P. Liu, S. Zhang, J. Chen, S. Xu, and Z. Song, “Rcontainer: A secure container architecture through extending arm cca hardware primitives,” inNetwork and Distributed System Security Symposium (NDSS), 2025

    2025

  15. [15]

    Arca: A lightweight confidential container architecture for cloud-native environments,

    D. Lu, M. Sun, Q. Zhang, Y . Liu, J. Zhang, X. Dong, Y . Shen, and J. Ma, “Arca: A lightweight confidential container architecture for cloud-native environments,”arXiv preprint arXiv:2601.01214, 2026

    work page arXiv 2026

  16. [16]

    Characterizing Trust Boundary Vulnerabilities in TEE Containers: An Empirical Study

    W. Liu, H. Chen, S. Huai, Z. Xu, W. Wang, Z. Li, and Z. Liu, “Characterizing trust boundary vulnerabilities in tee containers,”arXiv preprint arXiv:2508.20962, 2025

    work page internal anchor Pith review Pith/arXiv arXiv 2025

  17. [17]

    What you trust is insecure: Demystifying how developers (mis)use trusted execution environments in practice,

    Y . Niu, J. Shi, R. Han, Y . Liu, C. Ma, Y . Lyu, and D. Lo, “What you trust is insecure: Demystifying how developers (mis)use trusted execution environments in practice,” inIEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), 2026, accepted; preprint: arXiv:2512.17363

    work page arXiv 2026

  18. [18]

    Sok: A systematic review of tee usage for devel- oping confidential applications,

    A. Paju and others, “Sok: A systematic review of tee usage for devel- oping confidential applications,” inProceedings of the ACM Workshop on Cloud Computing Security Workshop (CCSW), 2023

    2023

  19. [19]

    Gramine-tdx: A lightweight os kernel for confidential vms,

    D. Kuvaiskii, D. Stavrakakis, K. Qin, C. Xing, P. Bhatotia, and M. Vij, “Gramine-tdx: A lightweight os kernel for confidential vms,” inProceed- ings of the ACM SIGSAC Conference on Computer and Communications Security (CCS), 2024, pp. 4598–4612

    2024

  20. [20]

    Analyzing the performance impact of hpc workloads with gramine and sgx on 3rd generation xeon scalable processors,

    S. Miwa and S. Matsuo, “Analyzing the performance impact of hpc workloads with gramine and sgx on 3rd generation xeon scalable processors,” inSC’23 Workshops: 2nd International Workshop on Cyber Security in High Performance Computing (S-HPC), 2023

    2023

  21. [21]

    Acctee: A webassembly-based two-way sandbox for trusted resource accounting,

    D. Goltzsche, M. Nieke, T. Knauth, and R. Kapitza, “Acctee: A webassembly-based two-way sandbox for trusted resource accounting,” inProceedings of the 20th International Middleware Conference (Mid- dleware), 2019, pp. 123–135

    2019

  22. [22]

    A practical intel sgx setting for linux containers in the cloud,

    D. J. Tian, J. I. Choi, G. Hernandez, P. Traynor, and K. R. B. Butler, “A practical intel sgx setting for linux containers in the cloud,” inACM Conference on Data and Application Security and Privacy (CODASPY), 2019

    2019

  23. [23]

    Twine: An embedded trusted runtime for webassembly,

    J. M ´en´etrey, D. Spini, O. de Riedmatten, P. Felber, and V . Schiavoni, “Twine: An embedded trusted runtime for webassembly,”arXiv preprint arXiv:2103.15860, 2021

    work page arXiv 2021

  24. [24]

    Chancel: Efficient multi-client isolation under adversarial programs,

    A. Ahmad, T. Kim, B. Lee, D. Lee, Y . Kim, I. Shin, and T. Kim, “Chancel: Efficient multi-client isolation under adversarial programs,” inUSENIX Security Symposium, 2021

    2021

  25. [25]

    Reusable enclaves for confidential serverless computing,

    S. Zhao and others, “Reusable enclaves for confidential serverless computing,” in32nd USENIX Security Symposium (USENIX Security), 2023

    2023

  26. [26]

    Intel tdx demystified: A top-down approach,

    P.-C. Cheng, W. Ozga, E. Valdez, S. Ahmed, Z. Gu, H. Jamjoom, H. Franke, and J. Bottomley, “Intel tdx demystified: A top-down approach,”ACM Computing Surveys, 2024

    2024

  27. [27]

    Documentation for intel trust domain exten- sions (intel tdx),

    “Documentation for intel trust domain exten- sions (intel tdx),” 2023, accessed 2026-04. [Online]. Available: https://www.intel.com/content/www/us/en/developer/tools/ trust-domain-extensions/documentation.html

    2023

  28. [28]

    Confidential vms explained: An empirical analysis of amd sev-snp and intel tdx,

    M. Misono, D. Stavrakakis, N. Santos, and P. Bhatotia, “Confidential vms explained: An empirical analysis of amd sev-snp and intel tdx,” Proceedings of the ACM on Measurement and Analysis of Computing Systems, vol. 8, no. 3, pp. 36:1–36:42, 2024

    2024

  29. [29]

    An ex- perimental evaluation of tee technology: Benchmarking transparent approaches based on sgx, sev, and tdx,

    L. Coppolino, S. D’Antonio, G. Mazzeo, and L. Romano, “An ex- perimental evaluation of tee technology: Benchmarking transparent approaches based on sgx, sev, and tdx,”Computers & Security, vol. 154, no. 6, p. 104457, 2025

    2025

  30. [30]

    Enabling realms with the arm confidential compute architecture,

    “Enabling realms with the arm confidential compute architecture,” USENIX ;login:, 2023

    2023

  31. [31]

    Cage: Complementing arm cca with gpu extensions,

    C. Wang, F. Zhang, Y . Deng, K. Leach, J. Cao, Z. Ning, S. Yan, and Z. He, “Cage: Complementing arm cca with gpu extensions,” inNetwork and Distributed System Security Symposium (NDSS), 2024, pp. 1–16

    2024

  32. [32]

    A verified confidential computing as a service framework,

    H. Chen, W. Liu, S. Huai, W. Wang, Z. Xu, and Z. Li, “A verified confidential computing as a service framework,” in32nd USENIX Security Symposium (USENIX Security), 2023

    2023

  33. [33]

    Heckler: Breaking confidential vms with malicious interrupts,

    B. Schl ¨uter, S. Sridhara, M. Kuhne, A. Bertschi, and S. Shinde, “Heckler: Breaking confidential vms with malicious interrupts,” in33rd USENIX Security Symposium (USENIX Security), 2024

    2024

  34. [34]

    Wesee: Using malicious #vc interrupts to break amd sev-snp,

    B. Schl ¨uter, S. Sridhara, A. Bertschi, and S. Shinde, “Wesee: Using malicious #vc interrupts to break amd sev-snp,” inIEEE Symposium on Security and Privacy (S&P), 2024

    2024

  35. [35]

    00seven – re-enabling virtual machine forensics: Introspecting confidential vms using privileged in-vm agents,

    F. Schwarz and C. Rossow, “00seven – re-enabling virtual machine forensics: Introspecting confidential vms using privileged in-vm agents,” in33rd USENIX Security Symposium (USENIX Security), 2024

    2024

  36. [36]

    Cachewarp: Software-based fault injection using mi- croarchitectural effects on confidential VMs,

    R. Zhang, M. Li, X. Chen, Q. Chen, S. Zhang, W. Xu, K. Chen, and H. Wang, “Cachewarp: Software-based fault injection using mi- croarchitectural effects on confidential VMs,” in33rd USENIX Security Symposium (USENIX Security), 2024

    2024

  37. [37]

    Breaking constant-time cryptography on amd sev via the ciphertext side channel,

    M. Li, Y . Zhu, X. Tian, R. Zhang, S. Hu, and H. Wang, “Breaking constant-time cryptography on amd sev via the ciphertext side channel,” in30th USENIX Security Symposium (USENIX Security), 2021

    2021

  38. [38]

    Rmpocalypse: How a catch-22 breaks amd sev-snp,

    Y . Cui, R. Zhang, M. Li, K. Chen, and H. Wang, “Rmpocalypse: How a catch-22 breaks amd sev-snp,” inProceedings of the ACM SIGSAC Conference on Computer and Communications Security (CCS), 2025

    2025

  39. [39]

    Heracles: Chosen plaintext attack on amd sev-snp,

    B. Schl ¨uter, S. Sridhara, A. Bertschi, and S. Shinde, “Heracles: Chosen plaintext attack on amd sev-snp,” inProceedings of the ACM SIGSAC Conference on Computer and Communications Security (CCS), 2025

    2025

  40. [40]

    Counterseveil- lance: Performance-counter attacks on amd sev-snp,

    S. Gast, H. Weissteiner, R. L. Schr ¨oder, and D. Gruss, “Counterseveil- lance: Performance-counter attacks on amd sev-snp,” inNetwork and Distributed System Security Symposium (NDSS), 2025

    2025

  41. [41]

    Tdxdown: Single-stepping and instruction counting attacks against intel tdx,

    L. Wilke, F. Sieck, and T. Eisenbarth, “Tdxdown: Single-stepping and instruction counting attacks against intel tdx,” inProceedings of the ACM SIGSAC Conference on Computer and Communications Security (CCS), 2024

    2024

  42. [42]

    Tdxploit: Novel techniques for single-stepping and cache attacks on intel tdx,

    F. Rauscher, L. Wilke, H. Weissteiner, T. Eisenbarth, and D. Gruss, “Tdxploit: Novel techniques for single-stepping and cache attacks on intel tdx,” in34th USENIX Security Symposium (USENIX Security), 2025

    2025

  43. [43]

    Sev-step: A single-stepping framework for amd-sev,

    L. Wilke, J. Wichelmann, A. Rabich, and T. Eisenbarth, “Sev-step: A single-stepping framework for amd-sev,”IACR Transactions on Crypto- graphic Hardware and Embedded Systems (TCHES), vol. 2024, no. 1, pp. 180–206, 2024

    2024

  44. [44]

    Exploring side-channels in intel trust domain extensions,

    U. Mandal and others, “Exploring side-channels in intel trust domain extensions,” IACR ePrint 2025/079, 2025. [Online]. Available: https://eprint.iacr.org/2025/079.pdf

    2025

  45. [45]

    Pandora: Prin- cipled symbolic validation of intel sgx enclaves,

    F. Alder, F. Kison, J. G ¨otzfried, S. Schinzel, and T. Holz, “Pandora: Prin- cipled symbolic validation of intel sgx enclaves,” inIEEE Symposium on Security and Privacy (S&P), 2024. JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2021 19

    2024

  46. [46]

    Aex-notify: Thwarting precise single-stepping attacks through hardware-software co-design,

    S. Constable and others, “Aex-notify: Thwarting precise single-stepping attacks through hardware-software co-design,” in32nd USENIX Security Symposium (USENIX Security), 2023

    2023

  47. [47]

    Aex-nstep: Probabilistic interrupt counting attacks on intel sgx,

    N. Dutly, F. Groschupp, I. Puddu, K. Kostiainen, and S. Capkun, “Aex-nstep: Probabilistic interrupt counting attacks on intel sgx,”arXiv preprint arXiv:2510.14675, 2025

    work page arXiv 2025

  48. [48]

    Sigy: Breaking intel sgx enclaves with malicious exceptions & signals,

    S. Sridhara, A. Bertschi, B. Schl ¨uter, and S. Shinde, “Sigy: Breaking intel sgx enclaves with malicious exceptions & signals,” inACM Asia Conference on Computer and Communications Security (AsiaCCS), 2025

    2025

  49. [49]

    Remote attestation procedures (rats) architecture (ietf draft),

    “Remote attestation procedures (rats) architecture (ietf draft),” 2022. [Online]. Available: https://datatracker.ietf.org/doc/ draft-ietf-rats-architecture/22/

    2022

  50. [50]

    Rfc 9334: Remote attestation procedures (rats) architecture,

    “Rfc 9334: Remote attestation procedures (rats) architecture,” 2025. [Online]. Available: https://datatracker.ietf.org/doc/rfc9334/

    2025

  51. [51]

    Rfc 9711: The entity attestation token (eat),

    L. Lundblade and H. Birkholz, “Rfc 9711: The entity attestation token (eat),” 2025

    2025

  52. [52]

    Rfc 9782: Entity attestation token (eat) media types,

    ——, “Rfc 9782: Entity attestation token (eat) media types,” 2025

    2025

  53. [53]

    Rfc 9783: Arm’s platform security archi- tecture (psa) attestation token,

    H. Birkholz and T. Fossati, “Rfc 9783: Arm’s platform security archi- tecture (psa) attestation token,” 2025

    2025

  54. [54]

    Standard-based remote attestation: The veraison project,

    L. Ferro and A. Lioy, “Standard-based remote attestation: The veraison project,” inITASEC: Italian Conference on Cybersecurity, ser. CEUR Workshop Proceedings, vol. 3731, 2024. [Online]. Available: https://ceur-ws.org/V ol-3731/paper28.pdf

    2024

  55. [55]

    Provably secure communication protocols for remote attestation,

    J. Wilson, M. Asplund, and F. Boeira, “Provably secure communication protocols for remote attestation,” inProceedings of the 19th Interna- tional Conference on Availability, Reliability and Security (ARES), 2024

    2024

  56. [56]

    Prove: Provable remote attestation for public verifiability,

    E. Dushku, M. Rabbani, J. Vliegen, and A. Braeken, “Prove: Provable remote attestation for public verifiability,”Journal of Information Secu- rity and Applications, vol. 75, p. 103448, 2023

    2023

  57. [57]

    Universal remote attestation for cloud and edge platforms,

    B. Raja, D. F ´abrega, G. Perez, and A. Estevez, “Universal remote attestation for cloud and edge platforms,” inProceedings of the ACM Workshop on Cloud Computing Security Workshop (CCSW), 2023

    2023

  58. [58]

    Remote attestation with constrained disclosure,

    M. Eckel, D. R. George, B. Grohmann, and C. Krauß, “Remote attestation with constrained disclosure,” inAnnual Computer Security Applications Conference (ACSAC), 2023

    2023

  59. [59]

    Towards continuous integrity attestation and its challenges in practice: A case study of keylime,

    M. Ruffin, C. Wang, G. Almasi, A. Adebayo, H. Franke, and G. Wang, “Towards continuous integrity attestation and its challenges in practice: A case study of keylime,” inIEEE/IFIP International Conference on Dependable Systems and Networks (DSN), 2025

    2025

  60. [60]

    Bridging remote attestation and secure software updates in embedded systems,

    A. B. Usman and others, “Bridging remote attestation and secure software updates in embedded systems,”International Journal of In- formation Security, 2026

    2026

  61. [61]

    Enabling integrity measurement for secure applications in confidential computing scenarios,

    J. Catalano and others, “Enabling integrity measurement for secure applications in confidential computing scenarios,”Journal of Network and Systems Management, 2026

    2026

  62. [62]

    TrustMee: Self-Verifying Remote Attestation Evidence

    B. Schl ¨uter, S. Sridhara, A. Bertschi, and S. Shinde, “Trustmee: Self- verifying remote attestation evidence,”arXiv preprint arXiv:2602.13148, 2026. Di Lu(Member, IEEE) received the B.S., M.S., and Ph.D. degrees in computer science and technology from Xidian University, China, in 2006, 2009, and

    work page internal anchor Pith review Pith/arXiv arXiv 2026

  63. [63]

    His research interests include trusted com- puting, confidential computing, system and network security

    Now he is a full Professor in the School of Computer Science and Technology at Xidian Uni- versity. His research interests include trusted com- puting, confidential computing, system and network security. Qingwen Zhangreceived the BS degree from Xi- dian University, China, in 2024. She is currently pursuing an MS degree in the School of Computer Science a...

    2024