<index> / <android> / tee
[ en | fr ]
┌───────────────────────┐
│                       │
│                       │
│                       │
│                       │
│                       │
│                       │
│                       │
│                       │
│                       │
│                       │
│                       │
│                       │
│                       │
│                       │
│                       │
└───────────────────────┘
Walkthroug Android TEE
~ lululufr
CONTENTS
  0  the tee — definition
  1  the issue & enclaves — why it exists
  2  arm trustzone — two worlds
  3  tee vs ree — the split
  4  the smc — the doorway
  5  the ns-bit — the badge
  6  the chain of trust — verified boot
  7  trusted os — a real kernel
  8  tee vs secure element — complementary
  9  case study: netflix — drm in practice

──[ 0. The TEE ]──

The TEE (Trusted Execution Environment) is a secure area inside the main 
processor that:
    - Runs its own OS (a "secure OS")
    - Is fully isolated from the "normal" Android system (the REE, or Rich
      Execution Environment)
    - Is only reachable by trusted applications, or by trusted drivers

──[ 1. The Issue & Enclaves ]──

The TEE was born from one question: how do you protect data in an inherently 
hostile environment? The answer was a new building block: the **enclave**.
    ENCLAVE: a secure area inside your device that isolates sensitive
    data. A protected environment where only authorized code can touch
    the data, with protection against outside observation.

    Only a process running inside an enclave can read the data stored
    in that same enclave.

Enclaves are everywhere now:
    Windows   VBS  (Virtualization-Based Security)
    Intel     SGX  (Software Guard Extensions)
    Mac       SEP  (Secure Enclave Processor)
    Android   TEE  (via ARM TrustZone)

──[ 2. ARM TrustZone ]──

On ARM chips, which run the vast majority of phones, the relevant tech is called 
TrustZone. Idea: split the processor in two parallel worlds. An enclave mechanism baked
into the silicon, and that's where our TEE lives.
graph TB
    A[TrustZone Technology]
    A --> B[Normal World - REE]
    A --> C[Secure World - TEE]

    B --> D[Android OS]
    B --> E[Applications]
    B --> F[Games]

    C --> G[Keymaster]
    C --> H[Gatekeeper]
    C --> I[DRM Services]
──[ 3. TEE vs REE ]──

So we get two worlds living side by side:
    Normal World (REE) — Rich Execution Environment
        - Android OS
        - Apps (Instagram, TikTok, ...)
        - Games

    Secure World (TEE) — Trusted Execution Environment
        - Signed code only
        - Cryptographic key management
        - Biometrics (face / fingerprint)
        - DRM (content protection)
ARM TrustZone / Trusty overview
The EL0 / EL1 / EL3 zones in the diagram map cleanly to a more familiar Linux 
idea: protection rings.
ARM exception levels (EL0 / EL1 / EL3)
──[ 4. The SMC ]──

Key takeaway from that diagram: every instruction that wants to reach the TEE 
has to go through one specific doorway, the SMC (Secure Monitor Call). A typical request for a crypto key looks like:
sequenceDiagram
    participant A as Android App
    participant K as Android Kernel
    participant S as Secure Monitor
    participant T as TEE

    A->>K: I need a crypto key
    K->>S: SMC (Secure Monitor Call)
    Note over S: NS-bit verification
    S->>T: Switch to Secure World
    T->>T: Secure processing
    T->>S: Encrypted result
    S->>K: Return to Normal World
    K->>A: Here is your key (encrypted)
──[ 5. The NS-bit ]──

The NS-bit (Non-Secure bit) is the security badge stamped on every operation the 
processor does. It's the fundamental mechanism that keeps the two worlds
logically separate. When the processor runs an op, the NS-bit propagates through the whole system:
    - On the system bus: every transaction (AXI/ACE) carries this bit.
      When the CPU reads an address, the request includes the NS-bit
      telling the system which world it came from.
    - In memory controllers: they read the NS-bit to decide if access is
      allowed. A memory region can be configured to accept only NS=0
      accesses (Secure World only).

    NS-bit:
        NS = 0  ->  "Secure World"  (TEE)
        NS = 1  ->  "Normal World"  (REE)

The current world is governed by the NS bit of the SCR (Secure Configuration 
Register) — a special register only reachable from Monitor mode (EL3).
    TL;DR:
        NS = 0  ->  "I'm in the Secure World"  (TEE)
        NS = 1  ->  "I'm in the Normal World"  (REE)

    Lives in SCR.NS (Secure Configuration Register).

──[ 6. The Chain of Trust ]──

Android uses Verified Boot: at each step of boot, a signature validates the next 
stage. A cascade of identity checks.
flowchart TD
    A[ROM Boot] --> B{Signature OK?}
    B -->|yes| C[Bootloader]
    B -->|no| X[Degraded mode]
    C --> D{Signature OK?}
    D -->|yes| E[Android Kernel]
    D -->|no| X
    E --> F{Signature OK?}
    F -->|yes| G[TEE Kernel OK]
    F -->|no| X
Rule: a component is only "trusted" once the previous one has
    authenticated it.

──[ 7. Trusted OS ]──

The TEE isn't just a chunk of protected memory — it's a real OS running in 
parallel with Android. Each vendor ships its own:
    Google     Trusty (TOS)
    Qualcomm   QSEE
    Samsung    TEEGRIS
    ...

This Trusty kernel can load Trusted Applications like:
    Keymaster    cryptographic key management
    Gatekeeper   PIN / pattern / password verification
    DRM          protected-content handling

──[ 8. TEE vs Secure Element ]──

Worth telling the Secure Element and the TEE apart. They're complementary, not 
the same thing:
    Secure Element (SE)
        - Dedicated hardware: a physically isolated microcontroller
        - Tiny resources: a few KB of RAM/ROM
        - Use: key storage, ...
        + Total physical isolation
        - Very limited power/size

    TEE
        - Logical isolation: separated by the NS-bit
        - Shared resources: access to the main CPU/GPU
        - Use: heavy crypto, biometrics, HD video
        + High compute power
        - Shares the physical hardware

──[ 9. Case Study: Netflix ]──

Concrete example: Netflix.

Secure video decoding

When you watch an HD/4K movie on Netflix, the video is decoded directly inside 
the TEE. Why?
    - Stop the video stream from being copied
    - Respect copyright
    - Comply with studio licensing

If the app finds your phone has no working TEE, quality gets capped — you won't 
get past ~480p.
    How the key stays safe: each Netflix title has its own AES key
    provided by Widevine. That key:
        - sits in the TEE and never leaves it
        - decrypts content inside the TEE
        - feeds the decrypted stream out through a verified driver

Revisiting our earlier diagram with this flow:
sequenceDiagram
    participant N as Netflix App
    participant A as Android
    participant T as TEE
    participant W as Widevine CDM
    participant S as Netflix Server

    N->>S: Request a movie
    S->>N: Encrypted content + license
    N->>A: Decrypt this for me
    A->>T: SMC to Widevine
    T->>W: Load license
    W->>W: Verify rights
    W->>W: Decrypt content
    W->>T: Decrypted video stream
    T-->>A: Secure channel to GPU
    A->>N: Video output
──[ EOF ]──