Le TEE, nouvelle ligne de défense dans les mobiles

Transcription

1 Le TEE, nouvelle ligne de défense dans les mobiles SSTIC 2013 Hervé Sibert

2 Disclaimer Copyright ST-Ericsson All rights reserved. The contents of this document are subject to change without prior notice. ST-Ericsson makes no representation or warranty of any nature whatsoever (neither expressed nor implied) with respect to the matters addressed in this document, including but not limited to warranties of merchantability or fitness for a particular purpose, interpretability or interoperability or, against infringement of third party intellectual property rights, and in no event shall ST-Ericsson be liable to any party for any direct, indirect, incidental and or consequential damages and or loss whatsoever (including but not limited to monetary losses or loss of data), that might arise from the use of this document or the information in it. ST-Ericsson and the ST-Ericsson logo are trademarks of the ST-Ericsson group of companies or used under a license from STMicroelectronics NV or TelefonaktiebolagetLM Ericsson. All other names are the property of their respective owners. For more information on ST-Ericsson, visit 2 (32)

3 Plateforme mobile >>>>> Quasi-téléphone matériel : PCB avec SoC, BB, NVM, DDR, ports, écran tactile système : OS Linux, Android 3 (32)

4 Késako TEE?

5 Changement de paradigme Peu déployé, restreint au mobile [1990, 2007] Framework applicatif propriétaire Apps JVM (J2ME) Couche d adaptation RTOS propriétaire Plusieurs fournisseurs, portage spécifique Native apps [2007,?] Linux Apps Dalvik Android framework Fonctions sensibles??? HW de sécurité (secrets, crypto ) Fonctions sensibles Pas de standards HW de sécurité (secrets, crypto ) Chaque fabricant de SoC a le sien, pas ou peu de suivi Ouvert ou ouvrable 5 (32)

6 TEE = Trusted Execution Environment REE TEE Native apps Apps Dalvik Framework Android Linux Séquencement des fonctions sensibles Fonctions sensibles HW de sécurité (secrets, crypto ) Les fonctionnalités sensibles sont déportées dans le TEE, mais leur gestion demeure extérieure au TEE. 6 (32)

7 Le TEE, ses fonctionnalités Dédié à la gestion des fonctions sensibles et du code dont l exécution dans l OS normal exposerait la sécurité aux attaques Contrôle du boot sécurisé Fonctions de sécurité Stockage sécurisé IHM sécurisée (écran tactile, affichage) Canaux sécurisés avec SIM, Secure Element Fonctions d isolation Isolation du code et des données (propres et applicatives) vs OS normal Protection des clés sur lesquelles reposent les fonctions de sécurité Isolation entre les différentes applications du TEE (code et données) 7 (32)

8 Le TEE GlobalPlatform est une alliance d industriels du domaine de la carte à puce et du paiement, centrée sur le Secure Element, rassemblant fabricants de carte à puce, de SoCs, professionnels du paiement, opérateurs, OEMs, vendeurs de solutions de sécurité, labos GlobalPlatform a commencé à définir un TEE standard il y a ~5 ans Volonté de contrôler une migration potentielle de la sécurité vers le SoC Standardisation des interfaces TEE Internal API : développement de Trusted Applications dans le TEE TEE Client API : communication avec les TAs depuis l OS Encourager le développement logiciel dans le TEE Simplifier la migration d un TEE à l autre pour les fabricants Programme de certification pour l apport de garanties de sécurité Programme de conformité pour assurer l interopérabilité des GP TEEs 8 (32)

9 Bases matérielles pour un TEE DDR emmc DDR emmc DDR emmc SoC SoC SoC esram Crypto HW esram Crypto HW CPU esram Crypto HW CPU CPU ROM OTP Périphs ROM OTP Périphs CPU Sécu ROM OTP Périphs Processeur virtuel (ex. ARM TrustZone) Processeur on-soc Copro de sécurité Processeur externe 9 (32)

10 Késako TrustZone?

11 ARM TrustZone en bref Monde Normal Monde Securisé Périphériques Périphériques ICN Fire wall ICN DDR esram erom CPU Interruptions, Caches, MMU DDR esram erom CPU Interruptions, Caches, MMU 11 (32)

12 ARM TrustZone en bref Les composants clés supportent état normal et état sécurisé ICN TZ-compatible Périphériques T Z T Z T Z T Z T Z DDR esram erom TZ CPU Interruptions, Caches, MMU 12 (32)

13 Les fondamentaux de TrustZone Le bit NS: 0=Secure, 1=Non-Secure Propagé sur le bus interne, il matérialise la sécurité des accès processeurs Isolation au sein du CPU Nouveaux modes: secure privileged/user Le mode moniteur, invoqué via l instruction Secure Monitor Call ou une interruption sécurisée, héberge le code qui sauve/restaure les registres du mode lors de l entrée/la sortie SECURE MODES USER PRIVILEGED TEE apps TEE core Secure HW MONITOR MODE Monitor NORMAL MODES OS User OS Kernel Shared/nonsecure HW USER PRIVILEGED Chaque mode a ses tables MMU Les pages peuvent être taguées secure/non-secure Le bit NS propagé lors d un accès CPU à la mémoire est à 0 si le processeur est en mode secure et si l adresse cible est taguée secure TZIC: chaque interruption (IRQ/FIQ) peut être secure/non-secure Chaque ligne de cache est taguée suivant l accès qui l a mise en cache 13 (32)

14 Mais encore? Isolation hors du CPU La MMU autorise les accès suivant les descripteurs Les descripteurs MMU du monde normal peuvent permettre l accès à une page taguée secure du côté sécurisé, en l absence d autres protections Protection matérielle des accès hors du CPU Extensions Registres internes du SoC l accessibilité suivant la valeur du bit NS est définie lors de la conception TrustZone Memory Wrapper devant une mémoire, n autorise que les accès avec NS=0 jusqu à une frontière définie dans un registre (contrôlé par le monde sécurisé) TrustZone Protection Controller devant les (contrôleurs de) périphériques, permet de filtrer les accès suivant la valeur du bit NS Des DMAs compatibles TZ permettent d effectuer des transactions pour le compte du mode secure Du matériel spécifique permet des filtrages plus fins que S/NS 14 (32)

15 TrustZone dans la poche Tous les CPU ARMs depuis ARM1176 En particulier tous les Cortex Ax Mais encore faut-il que le SoC permette un usage cohérent de TrustZone Le CPU démarre en mode secure Si TrustZone n est pas utilisé, pas de raison d en sortir Si le bit NS n est pas utilisé au niveau des mémoires/périphériques, pas d utilisation intéressante possible Dans la pratique Les SoCs de la plupart des smartphones récents sont pensés pour un usage cohérent de TrustZone mais les garanties de sécurité sont presque inexistantes. Bonne protection contre un rootkit TZ 15 (32)

16 Une recette de TEE

17 Premier ingrédient: un secure boot Racine de confiance matérielle OTP contenant au moins une clé publique, une clé symétrique unique, un identifiant public unique Protection des accès au mode secure par test de chip et debug (JTAG) ROM boot Initialisation limitée de la plateforme, en mode secure Chargement en RAM on-chip, vérification et exécution du SW boot, depuis USB, UART, emmc SW boot Initialisation complète de la plateforme (contrôleur DDR, power mgmt ) Contrôle du mode de boot (provisioning/production/ ) Initialisation du TEE Passage du CPU en mode normal pour le boot Android 17 (32)

18 Chaîne de confiance du boot AP HW esram pub DDR SW boot Région DDR Modem FW Modem Modem Boot semblable à celui de l AP OTP Root PK HW crypto Boot ROM 1 esram sec Initial SW boot TEE keys 2 TEE core App keys Canal sécurisé TEE-modem ST-Ericsson TEE contrôlant boot, debug, contrôle d accès mémoire, ressources de sécurité. OS loader OS 5 7 Trusted Apps Région DDR sécurisé Charge, valide avec un service TEE, initialise et exécute 6 Un service TEE charge le SW boot du modem en DDR, règle le firewall, démarre le modem 7 Les threads de l OS déclenchent le chargement dynamique des TAs, exécutées comme des extensions des threads Binaires signés avec les clés Root, TEE, App 18 (32)

19 Second ingrédient: un TEE OS TEE Native OS Applications USER PRIVILEGED Wrapper API GlobalPlatform TEE Client API TEE Driver Monitor TEE Core GlobalPlatform TEE Internal API TEE Libs Admin Agent Kernel Trusted Apps TrustZone HW resources crypto, timers, watchdog, fuses, secure storage, modem control USER (Secure DDR) PRIVILEGED (Secure esram) 19 (32)

20 disponible ST-Ericsson TEE Decision de concevoir le TEE ST-Ericsson fondée sur : - L utilisation du TEE comme coeur de la sécurité plateforme commune ST-Ericsson, - Le besoin des clients de garder le contrôle sur la sécurité, excluant une solution commerciale TEE v1 Déployé sur NovaThor U8500, support de la TEE Client API En déploiement, conforme aux spécifications TEE v1.0 TEE v2 Standards Premier standard TEE (pas de spécifications) Contribution aux spécifications, aux tests de conformité, à la définition de la certification Device Committee Spécifications TEE + conformité + certification (32)

21 coopératif Gestion de nombreuses fonctions critiques du système en collaboration avec l OS Multi-coeurs Caches Power state Resets Contrôle de configuration du système de sécurité Debug et tests Power, clock Mémoires Filtres sur le bus 21 (32)

22 joli (?) Small is beautiful Les Trusted Applications sont réduites au maximum Limitation de la surface d attaque dans le monde sécurisé L orchestration reste du ressort de l OS Le TEE hérite du scheduling de l OS Le besoin en mémoire est réduit Le Paging-on-demand permet de conserver une exécution on-chip du mode secure privileged Chargement dynamique des Trusted Applications Les binaires des TAs sont stockées dans un répertoire spécifique Le driver TEE fournit le binaire TA demandé lorsqu un client ouvre une session avec cette TA 22 (32)

23 utilisable Build Basé sur la toolchain Android (gcc, make) Toolchain unique pour Android et le TEE Outils de signature intégrés dans la toolchain Gestion de conf avec git, revue de code avec gerrit Debug printf, qui repasse la sortie au driver TEE, JTAG et RAM dump, si le debug du mode secure est activé Développement de TAs Trusted Applications SDK extrait du git TEE Interface client côté Linux : GlobalPlatform TEE Client API v1.0c, interface interne pour les TAs : GlobalPlatform TEE Internal API v (32)

24 Troisième ingrédient : des applications OS TEE Blocs security-aware Flux Protection de contenus Navigateurr Player video HD Applications entreprise SIMlock, IMEI TA de paiement Contrôle des flux video Crypto, clés, OTP Modem HW Video Affichage Paiement/ Services bancaires Applications natives de l OS TAs HDMI Ecran tactile Protection du SIMlock/IMEI TEE driver TEE Core Interfaces externes Monde normal Monde sécurisé Secure Element, SIM Plateforme HW (ex. CPU ARM avec TrustZone) NFC Réseau 24 (32)

25 Exemples d applications Protection de contenus OS L OS orchestrela fonctionnalité mais ne peut déroberou corrompredes données sensibles Affichage Multimedia Input TEE Modem 25 (32)

26 Exemples d applications Entrée sécurisée de code PIN Services bancaires OS L OS orchestrela fonctionnalité mais ne peut déroberou corrompredes données sensibles Affichage $$$ Multimedia Input **** TEE Modem 26 (32)

27 Exemples d applications Gestion de device Subsidy Lock - SIMlock OS L OS orchestrela fonctionnalité mais ne peut déroberou corrompredes données sensibles Affichage Multimedia Input TEE Modem 27 (32)

28 Et la sécurité?

29 Dans le TEE ST-Ericsson Vérification du code Le noyau du TEE estchargé et vérifiépar le secure boot, on-chip Les TAs sont signées et leur signature est vérifiée au chargement Isolation Le noyau du TEE estexécutéon-chip, en mode Secure privileged Les TAs tournent en DDR en mode Secure user La MMU Secure (descripteursen ROM et RAM on-chip protégée par HW) permet d isolerles TAs du noyauet les TAs entre elles Stockage sécurisé Les données des TAs sont protégées cryptographiquement et stockées dansun FS Linux NVM dédiéetee (RPMB de l emmc) pour la protection contrele rollback Autres protections NX pour les user TAs et le noyau(partiellement), todo : ASLR 29 (32)

30 Cible de sécurité Un intermédiaire entre OS ouvert et Secure Element Pas (ou peu) de résistance aux attaques matérielles Beaucoup plus intégréau SoC qu un SE plus de fonctionnalités, plus de ressources, mais aussi plus d interactions et de surface d attaque Attaques sur TrustZone Par canaux cachés(timing ) Autres? (bugs HW / absence de séparation physique) Attaquessur TEE Dan Rosenberg, GlobalPlatform TEE Internal API = C Une ciblede choix Next generation mobile rootkits, Thomas Roth, Black Hat EU (32)

31 Profil de Protection TEE TEE complet GP TEE HW Objectif = prévention contre les attaques reproductibles aisément Modèle d attaque = attaque SW/HW pour déterminer une vulnérabilité exploitable par logiciel uniquement, puis attaque logicielle Niveau d assurance EAL2+ (potentiel d attaque augmenté) REE (OS) GP TEE Client API Frontière avec l OS = interface(s) de communication TA TA TA GP TEE Internal API TEE Cible de l évaluation = plateforme TEE Frontière avec les TAs = GP TEE Internal API Agent de communication REE communication Initialisation : le processus d initialisation du TEE, bienque non standardisé, doit répondre aux exigences de sécurité Agent de comm. TEE Base HW du TEE Plateforme matérielle Base HW certifiée = HW utilisé pour protéger et fournir les services TEE GP 31 (32)

32 ON PEUT JOUER AVEC? Stay tuned!