Start With the Threat Model

What you will learn

In this lesson, you will learn how to define:

• The protected asset
• The attacker
• The attacker's capabilities
• The trusted components
• The required security properties
• The attacks that are outside the system's scope
• The conditions under which the system should refuse to operate

Why the threat model comes first

A TEE is not a security goal.

It is a mechanism that may help achieve a security goal.

Saying that an application "uses a TEE" tells us very little unless we also know:

• What information is sensitive
• Who should not see it
• Who should not modify it
• What hardware is trusted
• What software is trusted
• Whether physical access is considered
• Whether availability matters
• Whether the result must be publicly verifiable

A system designed to protect an AI model from a cloud administrator has a different threat model from a mobile wallet designed to protect keys from a device thief.

A private auction has a different threat model from a confidential database.

Step 1: Identify the assets

An asset is anything the system needs to protect.

TEE assets may include:

• Private keys
• User data
• Source code
• Compiled application code
• AI model weights
• Private prompts
• Transaction intentions
• Trading strategies
• Authentication credentials
• Application state
• Attestation policies
• Reference measurements
• Audit records
• Recovery keys
• Intermediate computation values

Do not write "sensitive data" as one broad asset. Name the exact data.

`` Asset: User medical record Asset: AI model weights Asset: Session decryption key Asset: Accepted enclave measurement list Asset: Final medical risk score ``

The accepted measurement list is an asset because an attacker who changes it may cause the verifier to trust malicious code.

Step 2: Identify the security property

Each asset may need a different protection.

Ask whether the asset requires:

• Confidentiality
• Integrity
• Authenticity
• Freshness
• Availability
• Unlinkability
• Non-repudiation
• Auditability
• Deletion
• State continuity

| Asset | Required property | | ----- | ----- | | Medical record | Confidentiality and integrity | | Application measurement | Integrity and authenticity | | Attestation nonce | Freshness and unpredictability | | Model version | Integrity and rollback protection | | Service | Availability | | User identity | Privacy and unlinkability |

A TEE may support some of these properties, but not all of them.

Step 3: Identify the attackers

A TEE system may face several attackers.

Remote network attacker

This attacker may:

• Intercept traffic
• Modify traffic
• Replay requests
• Submit malformed inputs
• Exhaust resources
• Impersonate a client

Malicious user

This attacker may:

• Send specially crafted inputs
• Call the application repeatedly
• Study output differences
• Attempt to extract protected data
• Abuse valid application functions

Compromised host operating system

This attacker may:

• Control scheduling
• Control page tables
• Modify files
• Observe system calls
• Manipulate return values
• Stop the protected workload
• Observe timing
• Control network and storage access

Malicious hypervisor

This attacker may:

• Control virtual CPU scheduling
• Manipulate guest-visible devices
• Control memory allocation
• Observe VM exits
• Delay or interrupt execution
• Attempt memory remapping
• Restore old VM state

Cloud administrator

This attacker may:

• Control infrastructure configuration
• Move the workload
• Stop the machine
• Change network routes
• Roll out firmware
• Control some operational services

Supply-chain attacker

This attacker may compromise:

• Dependencies
• Build tools
• Compilers
• Container images
• Firmware
• Signing keys
• Deployment scripts

Physical attacker

This attacker may have access to:

• Memory modules
• Power supply
• Debug ports
• Processor package
• Peripheral buses
• Cooling systems
• Hardware replacement

Not every TEE protects against every physical attack.

Malicious application developer

This attacker may intentionally place data-exfiltration logic inside the trusted application. Attestation may prove that the malicious code is running exactly as measured.

Step 4: Give attackers specific capabilities

Avoid vague statements such as:

> The cloud is untrusted.

Write:

> The host administrator may read and modify host storage, control network routing, restart the VM, change scheduling, and provide malicious input through host interfaces. The administrator cannot directly read confidential VM private memory without breaking the assumed hardware guarantee.

A useful threat statement has three parts:

`` Actor + Capability + Target ``

Example:

`` A malicious hypervisor can restore an older encrypted database snapshot to cause the TEE application to operate on stale state. ``

Step 5: State what remains trusted

A TEE application may still trust:

• CPU hardware
• Processor microcode
• Firmware
• TEE runtime
• Guest operating system
• Trusted application
• Cryptographic libraries
• Attestation service
• Hardware vendor certificate chain
• Key Broker Service
• Build pipeline
• Software signing key
• Reference-value administrator

Do not say that the system is "trustless." A TEE changes the location and size of trust. It does not remove trust.

Step 6: State what is outside the threat model

A system cannot defend against every possible attacker.

Examples of exclusions may include:

• Destructive physical attacks
• Nation-state hardware implants
• Compromise of the processor manufacturer's root signing key
• Denial of service by the cloud provider
• A compromised user device
• Data leakage intentionally produced by approved application code

Exclusions should be visible. They should not be hidden in technical documentation.

Example: Confidential AI inference

A company wants to run a private AI inference service.

Assets

• User prompt
• Model weights
• Model configuration
• Output
• Session keys
• Approved workload measurement

Attackers

• Cloud administrator
• Other cloud tenants
• Remote network attacker
• Malicious user
• Compromised host
• Supply-chain attacker

Required guarantees

• Prompt confidentiality
• Model-weight confidentiality
• Model integrity
• Output integrity
• Fresh evidence
• Secure channel binding
• Controlled model updates

Remaining exposure

• Request timing
• Response timing
• Input size
• Output size
• Availability
• User account metadata
• Billing data

Developer exercise

Write a threat model for a TEE-backed password manager.

Include:

1. Five protected assets 2. Four attackers 3. Two availability attacks 4. Two rollback attacks 5. Three components that remain trusted 6. One attack that is explicitly outside scope

Common mistakes

Key takeaways

• Begin with assets and attackers, not hardware brands.
• Connect each asset to a required security property.
• Describe attacker capabilities precisely.
• List trusted components.
• State excluded attacks clearly.
• Record remaining risks after the TEE is added.

Check your understanding

1. Why is "the cloud is untrusted" an incomplete threat model? 2. Can an attested application still be malicious? 3. Why is an approved measurement list a protected asset? 4. What availability powers may remain with an untrusted host? 5. Why should out-of-scope attacks be written down?