<index> / <android> / tee
[ en | fr ]
┌───────────────────────┐
│                       │
│                       │
│                       │
│                       │
│                       │
│                       │
│                       │
│                       │
│                       │
│                       │
│                       │
│                       │
│                       │
│                       │
│                       │
└───────────────────────┘
Au cœur du TEE Android
~ lululufr
SOMMAIRE
  0  le tee — définition
  1  le problème & enclaves — pourquoi ça existe
  2  arm trustzone — deux mondes
  3  tee vs ree — la séparation
  4  le smc — la porte d'entrée
  5  le ns-bit — le badge
  6  la chaîne de confiance — verified boot
  7  trusted os — un vrai kernel
  8  tee vs secure element — complémentaires
  9  étude de cas : netflix — drm en pratique

──[ 0. Le TEE ]──

Le TEE (Trusted Execution Environment) est une zone sécurisée à l'intérieur du 
processeur principal qui :
    - Fait tourner son propre OS (un "secure OS")
    - Est totalement isolée du système Android "normal" (le REE, ou Rich
      Execution Environment)
    - N'est joignable que par des applications de confiance, ou des
      drivers de confiance

──[ 1. Le Problème & Enclaves ]──

Le TEE est né d'une seule question : comment protéger des données dans un 
environnement intrinsèquement hostile ? La réponse : une nouvelle brique, l'**enclave**.
    ENCLAVE : zone sécurisée dans ton appareil qui isole des données
    sensibles. Environnement protégé où seul du code autorisé peut
    toucher les données, avec une protection contre l'observation
    extérieure.

    Seul un processus qui tourne dans l'enclave peut lire ses données.

Les enclaves sont partout maintenant :
    Windows   VBS  (Virtualization-Based Security)
    Intel     SGX  (Software Guard Extensions)
    Mac       SEP  (Secure Enclave Processor)
    Android   TEE  (via ARM TrustZone)

──[ 2. ARM TrustZone ]──

Sur les puces ARM, qui équipent la grande majorité des smartphones, la techno 
qui nous intéresse s'appelle TrustZone. L'idée : scinder le processeur en deux mondes parallèles. Un mécanisme d'enclave
gravé dans le silicium, et c'est là que vit notre TEE.
graph TB
    A[Technologie TrustZone]
    A --> B[Monde Normal - REE]
    A --> C[Monde Sécurisé - TEE]

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

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

Deux mondes côte à côte :
    Monde Normal (REE) — Rich Execution Environment
        - OS Android
        - Apps (Instagram, TikTok, ...)
        - Jeux

    Monde Sécurisé (TEE) — Trusted Execution Environment
        - Code signé uniquement
        - Gestion des clés cryptographiques
        - Biométrie (visage / empreinte)
        - DRM (protection des contenus)
Vue d'ensemble ARM TrustZone / Trusty
Les zones EL0 / EL1 / EL3 du schéma collent à une notion plus familière côté 
Linux : les anneaux de protection.
Niveaux d'exception ARM (EL0 / EL1 / EL3)
──[ 4. Le SMC ]──

À retenir du schéma : toute instruction qui veut atteindre le TEE doit passer 
par une porte précise, le SMC (Secure Monitor Call). Une demande typique de clé crypto, ça donne :
sequenceDiagram
    participant A as App Android
    participant K as Kernel Android
    participant S as Secure Monitor
    participant T as TEE

    A->>K: J'ai besoin d'une clé crypto
    K->>S: SMC (Secure Monitor Call)
    Note over S: Vérification du NS-bit
    S->>T: Bascule vers le Monde Sécurisé
    T->>T: Traitement sécurisé
    T->>S: Résultat chiffré
    S->>K: Retour au Monde Normal
    K->>A: Voici votre clé (chiffrée)
──[ 5. Le NS-bit ]──

Le NS-bit (Non-Secure bit), c'est le badge de sécurité tamponné sur chaque 
opération du processeur. Le mécanisme fondamental qui maintient les deux mondes
logiquement séparés. Quand le processeur exécute une op, le NS-bit se propage dans tout le système :
    - Sur le bus système : chaque transaction (AXI/ACE) porte ce bit.
      Quand le CPU lit une adresse, la requête contient le NS-bit qui
      indique d'où elle vient.
    - Dans les contrôleurs mémoire : ils lisent le NS-bit pour décider
      si l'accès passe. Une région mémoire peut être configurée pour
      n'accepter que les accès NS=0 (Monde Sécurisé uniquement).

    NS-bit :
        NS = 0  ->  "Monde Sécurisé"  (TEE)
        NS = 1  ->  "Monde Normal"    (REE)

Le monde courant est gouverné par le bit NS du SCR (Secure Configuration 
Register), un registre spécial accessible uniquement depuis le mode Monitor
(EL3).
    TL;DR :
        NS = 0  ->  "Je suis dans le Monde Sécurisé"  (TEE)
        NS = 1  ->  "Je suis dans le Monde Normal"    (REE)

    Vit dans SCR.NS (Secure Configuration Register).

──[ 6. La Chaîne de Confiance ]──

Android utilise le Verified Boot : à chaque étape du boot, une signature valide 
la suivante. Une cascade de contrôles d'identité.
flowchart TD
    A[Boot ROM] --> B{Signature OK ?}
    B -->|oui| C[Bootloader]
    B -->|non| X[Mode dégradé]
    C --> D{Signature OK ?}
    D -->|oui| E[Kernel Android]
    D -->|non| X
    E --> F{Signature OK ?}
    F -->|oui| G[Kernel TEE OK]
    F -->|non| X
Règle : un composant n'est "de confiance" qu'une fois que le
    précédent l'a authentifié.

──[ 7. Trusted OS ]──

Le TEE n'est pas juste un bloc de mémoire protégée — c'est un vrai OS qui tourne 
en parallèle d'Android. Chaque constructeur ship le sien :
    Google     Trusty (TOS)
    Qualcomm   QSEE
    Samsung    TEEGRIS
    ...

Ce kernel Trusty charge des Trusted Applications comme :
    Keymaster    gestion des clés crypto
    Gatekeeper   vérif du PIN / schéma / mot de passe
    DRM          gestion des contenus protégés

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

Bon à savoir : Secure Element et TEE, c'est pas la même chose. Complémentaires, 
mais distincts :
    Secure Element (SE)
        - Hardware dédié : un microcontrôleur physiquement isolé
        - Ressources minimes : quelques Ko de RAM/ROM
        - Usage : stockage de clés, ...
        + Isolation physique totale
        - Puissance/taille très limitées

    TEE
        - Isolation logique : séparation par le NS-bit
        - Ressources partagées : accès au CPU/GPU principal
        - Usage : crypto lourde, biométrie, vidéo HD
        + Grosse puissance de calcul
        - Partage le hardware physique

──[ 9. Étude de Cas : Netflix ]──

Exemple concret : Netflix.

Décodage vidéo sécurisé

Quand tu regardes un film HD/4K sur Netflix, la vidéo est décodée direct dans le 
TEE. Pourquoi ?
    - Empêcher la copie du flux vidéo
    - Respecter le copyright
    - Coller aux exigences de licence des studios

Si l'app détecte que ton téléphone n'a pas de TEE fonctionnel, la qualité est 
plafonnée — tu ne dépasseras pas les ~480p.
    Comment la clé reste safe : chaque titre Netflix a sa propre clé AES
    fournie par Widevine. Cette clé :
        - vit dans le TEE et n'en sort jamais
        - déchiffre le contenu dans le TEE
        - fait sortir le flux déchiffré via un driver vérifié

Avec ce flux, le schéma précédent devient :
sequenceDiagram
    participant N as App Netflix
    participant A as Android
    participant T as TEE
    participant W as Widevine CDM
    participant S as Serveur Netflix

    N->>S: Demande un film
    S->>N: Contenu chiffré + licence
    N->>A: Déchiffre-moi ça
    A->>T: SMC vers Widevine
    T->>W: Charge la licence
    W->>W: Vérifie les droits
    W->>W: Déchiffre le contenu
    W->>T: Flux vidéo déchiffré
    T-->>A: Canal sécurisé vers le GPU
    A->>N: Sortie vidéo
──[ EOF ]──