---
# System prepended metadata

title: TEE development for confidential computing

---

2026.01.13

Here is my opinionated argument about at the moment, TEE is possibily only available option for confidential computing to be used in production(have good user experience/performance).

## First what is TEE



## why TEE considered broke so far

- some famous attacks are [Battering RAM](https://batteringram.eu/) and [Wiretap](https://wiretap.fail/) and overall attacks listed in [TEE fail](https://tee.fail/)(and the response from [intel](https://www.intel.com/content/www/us/en/security-center/announcement/intel-security-announcement-2025-10-28-001.html)). These are low-cost hardware attack, so hard security perspective, it considered broke.
- ARM/Intel have [Deterministic encryption](https://en.wikipedia.org/wiki/Deterministic_encryption), which produces the same ciphertext each time the same plaintext is encrypted with a given key. The encryption is suboptimal for protecting data flowing between a CPU and a memory chip, as attacker could observe and perform [replay attack](https://en.wikipedia.org/wiki/Replay_attack). 
    - Also it's design tradeoff cus deterministic encryption is performant then probabilistic encryption.
- more of a issue is, the attacks could be defended by chip manufactor's patch, but derived from general responses from ARM/Intel, it looks less likely. 

## however still it's viable option for confidential computing

### confidential computing 
focuses on protecting data while it’s actively being processed. Not encryption at rest (for stored data) or encryption in transit (for data being transferred over the network).

- existing confidential ai inference product (e.g [confer](https://confer.to/blog/2026/01/private-inference/), [tinfoil](https://tinfoil.sh/), [apple's private cloud compute](https://security.apple.com/blog/private-cloud-compute/). ) using TEE +  llm. 
- existing confidential computing product (e.g [signal](https://signal.org/blog/private-contact-discovery/), [whatsapp](https://ai.meta.com/static-resource/private-processing-technical-whitepaper)) using TEE.
- ORAM(e.g [signal](https://signal.org/blog/building-faster-oram)) but still bit expensive
- FHE for general LLM inference is too slow to be used as product for now. 
- iO for arbitrary computing is not practical for now.
- tldr it's consider broke yes, but still better than nothing, especially theres no other usable approaches. 

## what tools can be used

- Chip based TEE
    - [ARM trustzone](https://www.arm.com/technologies/trustzone-for-cortex-a)
    - [Intel SGX](https://en.wikipedia.org/wiki/Software_Guard_Extensions)
    - [Apple secure enclave](https://support.apple.com/guide/security/secure-enclave-sec59b0b31ff/web)
- CPU-based(VM-based) TEE
    - [Intel TDX](https://github.com/canonical/tdx)
    - [AMD SEV](https://www.amd.com/en/developer/sev.html)
    - [AWS nitro enclave](https://docs.aws.amazon.com/enclaves/latest/user/nitro-enclave.html)
        - [example](https://github.com/aws-samples/aws-nitro-enclaves-bidding-service):  Flow is, each user's encrypted secret input posted on S3 bucket, and the encrypted data accessed from parent instance(public) and delivered to enclave. Enclave perform confidential compute and foward back to partent instance. Parent instance decrypt via KMS and upload on S3.   
        - Enclave is fully isolated virtual environment which only able to communicate via vsock with parent instance
- Wrapper
    - [dstack](https://github.com/Dstack-TEE/dstack)
    - [gramineproject](https://gramineproject.io/)
e only. They have no persistent storage, no interactive access, and no external networking.
    - [GCP](https://docs.cloud.google.com/confidential-computing/confidential-vm/docs/confidential-vm-overview)
- GPU
    - [NVIDIA Confidential Computing](https://www.nvidia.com/en-us/data-center/solutions/confidential-computing/)

## notion of TEE

- confidentiality
- verifiability

## General questions on TEE development on prod
- What tool to choose? on device chip based TEE more secure but harder to manage vs VM based TEE easiler to develope but requires additional trust on vendor. What spectrum of decision can be made?
- Does enclave spawn per every usercase? what are the security concern on spawn enclave for longer term for multiple cases? To be specific, in this NDA example, could it be used for multiple deals with multiple people or necessarily need to be spawn/removed per each deal? 

### think out of box 

https://lumo.proton.me/about

<!-- ## consider

### userflow

- generate key 
- enter app 
- TEE provides hardware levels of security. 
    - each hardware manufactor have own ver 

## resources

- https://arstechnica.com/security/2025/09/intel-and-amd-trusted-enclaves-the-backbone-of-network-security-fall-to-physical-attacks/ 
- https://news.ycombinator.com/item?id=43996555 -->