Sécurité des Mobiles

Sécurité des Mobiles Pr Pascal Urien Télécom ParisTech Pascal Urien - Télécom ParisTech 1

Rappels des concepts de base sur la sécurité des systèmes d exploitation Pascal Urien - Télécom ParisTech 2

La sécurité est une construction (design) 2 lignes de remparts 1 bastion *La ville de Carcasonne Pascal Urien - Télécom ParisTech 3

Applications Distribuées & Sécurité Une application distribuée est un ensemble d entités logicielles, logiquement autonomes, qui produisent, consomment et échangent des informations OUTi = PROG(INi) ) Lorsque les composants logiciels des applications sont logés dans un même système informatique, ce dernier constitue de fait leur média de communication (parfois dénommé gluware). Le bus système permet le transfert des informations stockées en mémoire, les modules logiciels sont réalisés par des processus gérés par le système d exploitation. La sécurité est uniquement dépendante des caractéristiques du système d exploitation, par exemple en terme de gestion des droits utilisateurs, ou d isolement des processus. IN1 PROG1 OUT1 IN2 PROG2 GLUEWARE OUT2 Pascal Urien - Télécom ParisTech 4

Notion de GlueWare Sonde d écoute CPU MEM P2 Bus Système MEM P1 PONT de BUS Prog1 Data1 OS Firewall Système Prog2 Data2 DISQUE Bus IO Notion de SANDBOX CARTE RESEAU Pascal Urien - Télécom ParisTech 5

Isolation: Notion de SandBox Un SANDBOX est un environnement logiciel qui contrôle les accès d une application aux ressources d un système informatique géré par un système d exploitation Pascal Urien - Télécom ParisTech 6

Buffer Overflow En 1988, un étudiant du MIT, Robert Tappan Morris, réalisa la première mise en œuvre offensive sur internet des techniques buffers overflow, nommée Morris worm. Le buffer overflow consiste à modifier malicieusement la mémoire d un programme, typiquement lors de l écriture d une information localisée dans un paramètre d appel du programme, ou lors de l écriture de données reçues via le réseau (c est-à-dire à l aide des bibliothèques de sockets). Les effets espérés par les buffer overflow dans la pile d exécution sont répartis en trois classes principales La modification d une variable mémoire, proche de la zone mémoire occupée par le buffer. La modification de l adresse de retour du programme localisée dans la pile, le but étant l exécution d un code malveillant localisé dans un paramètre d appel ou dans une information reçue via le réseau. La modification d un pointeur de fonction afin d exécuter un code préalablement injecté. Pascal Urien - Télécom ParisTech 7

Le vers BLASTER (2003) Pascal Urien - Télécom ParisTech 8

Architecture d un mobile 2G "classique" http://www.nokia-tuning.net Pascal Urien - Télécom ParisTech 9

Android Nexus S, 2011 NFC ROM APPLICATIONS TELEPHONY Blue Tooth WiFi GPS NFC CTL CA ME RA ACCE LERO METER COM PASS FRAMEWORK /java/android/ JINI FLASH 1+15 Go RAM 512 Mo SCREEN MIC HP CO DEC USB LIBRAIRIES NFC RIL DALVIK Application Processor (1GHz) + GPU CPU core, "Hummingbird" LINUX KERNEL /dev/nfc /dev/baseband NFC CTL BASE BAND Baseband Processor Radio Layer Interface (RIL) SIM Front End Module (FEM) Pascal Urien - Télécom ParisTech 10

Trinité, Paul Kocher & ALL (2004) Extensibilité Sécurité Complexité Connectivité Pascal Urien - Télécom ParisTech 11

Plateformes Sécurisées, Bill Gates, RSA Security Conference, 2006 Network Firewall Processes Firewall User User s Right Secure Device Carte à puce Pascal Urien - Télécom ParisTech 12

La stratégie Microsoft Bill Gates RSA Security Conference 2007 IPSEC Le mot de passe est LE problème de sécurité Microsoft propose l usage généralisé de certificats Trustworthy Computing Des composants qui résistent aux attaques TPM Cartes à puce Identité Pascal Urien - Télécom ParisTech 13

Contrôle d intégrité Certaines attaques intrusives sont liées à la possibilité de modifier le code d un programme soit avant son exécution (modification du fichier exécutable) soit au cours de son exécution (point d arrêts en mode debug, modification de certaines zones mémoire, pose de bretelles.). L analyse d un code lors de son exécution révèle la clé associée à un algorithme cryptographique. Cependant des techniques d embrouillage de code (obfuscation) peuvent rendre ces attaques plus difficiles. Le groupe Trusted Computing Group (TCG) a défini une architecture sécurisée pour les ordinateurs personnels basés sur un module hardware sécurisé le TPM (Trusted Platform Module). Dans ce modèle l intégrité du système (bibliothèques essentielles du système d exploitation, ) est mesurée (integrity measurement) par une empreinte (SHA-1, 160 bits) stockée dans une puce de silicium résistante aux attaques (tamper resistant). L accès à ce dispositif est contrôlé par des secrets partagés symétriques. Le TPM s appuie sur un arbre de clés RSA, dont l accès à chaque nœud est protégé par une clé symétrique. Pascal Urien - Télécom ParisTech 14

Le TPM L intégration du TPM dans le système d exploitation windows s applique aux trois points suivants, Le Secure Boot. Le premier programme amorce est stocké dans le TPM. Le boot est une succession de programme Pi tels que Po est contenu dans le TPM, chaque Pi est associé à une empreinte Hi enregistrée dans le TPM, le programme Pi-1 charge Pi et vérifie son empreinte Hi. -Le chiffrement du contenu du disque dur (bitlocker TM ) à l aide d une clé maître (VEK, Volume Encryption Key) stockée dans le TPM. Le contrôle de l intégrité des PCs au moment de leur connexion réseau (NAP, Network Access Protection). Amorçage sécurisé Outils d administration Fournisseur de stockage de clés Services de base du TPM Driver du TPM TPM Application tierce TSS* Pascal Urien - Télécom ParisTech 15

Trusted Execution Environment (TEE) Le TEE est un environnement d exécution de confiance pour les mobiles. Pascal Urien - Télécom ParisTech 16

TrustZone Le concept de TrustZone propose la virtualisation d un processeur permettant la création de deux espaces de traitement de l information le "Normal Word" et le "Secure World". Chacun de ces modes de fonctionnement possède un banc de registres séparé et des mécanismes d interruption différents. Cependant le CPU et les mémoires internes (ROM, SRAM) sont communs aux deux mondes. Une troisième entité, le Monitor gère les changements de contexte entre le "Normal Word" et le "Secure World" à l aide d instructions spécifiques (Secure Monitor Call, SMC); elle se comporte de fait comme un hyperviseur qui réalise grâce à la technique de virtualisation, une isolation des espaces dits normaux ou sécurisés. Les tailles mémoire internes (In-SoC) sont de l ordre de 10 Ko pour la ROM et 128 Ko pour la SRAM. Pascal Urien - Télécom ParisTech 17

TrustZone D un point de vue physique, et contrairement aux Secure Elements, le processeur n implémente pas de contremesures matérielles. Les mémoires externes (Off-Soc), non volatiles (ROM, FLASH) ou volatiles (DRAM ) sont partagées par les deux mondes. Une entité MMU (Memory Management Unit) réalise les partitions nécessaires à leur virtualisation; des protections cryptographiques (chiffrement et intégrité) sont nécessaires pour la sécurité des informations stockées par le "Secure World". Le MMU assure également les partitions mémoires internes au SoC. Le concept TrustZone introduit la notion d entrée/sortie (IO) sécurisée. Un clavier sécurisé est géré par un pilote (driver) exécuté dans un SW. Un affichage sécurisé dispose deux mémoires d affichage (FrameBuffer) distinctes, et donc implique la disponibilité d un contrôleur particulier. Un pilote NFC exécuté en mode SW assure le traitement sécurisé de transaction de paiement. Pascal Urien - Télécom ParisTech 18

TrustZone Pascal Urien - Télécom ParisTech 19

Printed Circuit Board Secure Element et TEE Real Time Clock GlobalPlatform Device Technology TEE System Architecture Version 1.0, 2011 Pascal Urien - Télécom ParisTech 20

Attaque par canaux cachés Side Channel Attacks Pascal Urien - Télécom ParisTech 21

S. Ravi et al, 2004 Attaques adressant les systèmes embarqués Pascal Urien - Télécom ParisTech 22

RSA & Morse Samuel F a b modulus m Pascal Urien - Télécom ParisTech 23

Attaque d un exponentiator C(forme chiffrée) = M d modulo m d = d 0.2 0 + d 1.2 1 + d 2.2 2 + d 3. 2 3 + d 4.2 4 +...+ d i.2 i +...+ d p-1.2 p-1, ou di a pour valeur 0 ou 1. La forme chiffrée s exprime sous forme d un produit de p termes mi, C = m 0. m 1 m 2 m i m p-1 modulo m, avec mi= 1, si ei=0. mi= M 2^i modulo m, si ei=1 X i = M 2^i, X i+1 = Xi 2 En constate que, dans cette implémentation de l algorithme RSA (dite exponentiation), chaque bit (di) de la clé implique un temps calcul différent selon que sa valeur soit 0 (multiplication triviale par 1) ou 1 (multiplication par M 2^i ). En fonction des différences de temps calculs observées on déduit la valeur de di (0 ou 1). Pascal Urien - Télécom ParisTech 24

Android Pascal Urien - Télécom ParisTech 25

Android: Historique Android est un système d exploitation crée par la société Android Inc. rachetée en 2005 par GOOGLE. Dernière Nom de Date de Version Caractéristiques révision code sortie 1.0 1.0 fin 2007 version non éditée 1.1 1.1 Petit Four11 22-oct-08 1ère version incluse dans le premier téléphone. 1.5 mai-10 Cupcake11 30-avr-09 1.6 mai-10 Donut11 15-sept-09 2.0 2.1, mai 2010 Eclair11 26-oct-09 2.2.x 2.2.3, 2011 Froyo11 20-mai-10 vitesse améliorée etinterface graphique 2.3.x 2.3.7, 2012 Gingerbrea dernière version dédiée uniquement aux 06-déc-10 smartphones. Cette version est parfois utilisée d1112 sur de petites tablettes. 3.x.x 3.2, 2012 Honeycomb Réservé aux tablettes tactiles et aux téléviseurs 22-févr-11 13 connectés 4.0.x 4.0.4, 2012 Ice Cream Sandwich11 1516 19-oct-11 Cette nouvelle version, fortement inspirée d'honeycomb,changements 4.1.x 4.1.2, 2012 Jelly Bean17 09-juil-12 Il ajoute un système de notification améliorée, Google Chrome comme navigateur, la reconnaissance vocale 4.2.x Nouvelle interface de l'appareil photo prise en 4.2.2, février 2013 Jelly Bean 13-nov-12 compte d'un système multi-compte uniquement sur tablette 4.3.x 4.3.0, mai 2013 Jelly Bean 15-mai-13 Ajout du projet RoadRunner améliorant l'autonomie de batterie Marché 2011 2012 Android 48.7% 68.4% Apple ios 19.0% 19.4% Others 32.3% 12.2% Total 100.0% 100.0% Pascal Urien - Télécom ParisTech 26

Architecture du système Android Un système d exploitation Android comporte les éléments suivants Un noyau Linux Un ensemble de libraires, et la DALVIK Virtual Machine Un framework JAVA utilisant JINI Un ensemble d applications Pascal Urien - Télécom ParisTech 27

Architecture du Nexus S NFC ROM APPLICATIONS TELEPHONY Blue Tooth WiFi GPS NFC CTL CA ME RA ACCE LERO METER COM PASS FRAMEWORK /java/android/ JINI FLASH 1+15 Go RAM 512 Mo SCREEN MIC HP CO DEC USB LIBRAIRIES NFC RIL DALVIK Application Processor (1GHz) + GPU CPU core, "Hummingbird" LINUX KERNEL /dev/nfc /dev/baseband NFC CTL BASE BAND Baseband Processor Radio Layer Interface (RIL) SIM Front End Module (FEM) Pascal Urien - Télécom ParisTech 28

Android: Architecture Logicielle Pascal Urien - Télécom ParisTech 29

RIL 1/3 Radio Interface Layer http://www.kandroid.org/online-pdk/guide/telephony.html Pascal Urien - Télécom ParisTech 30

RIL 2/3 Pascal Urien - Télécom ParisTech 31

RIL 3/3 Pascal Urien - Télécom ParisTech 32

MIC, HP Broadband Wi-Fi chip SIM, CAMERA PN544(NFC) Pascal Urien - Télécom ParisTech 33 http://www.ifixit.com/teardown/nexus-s-teardown/4365/1

Application Android Une application Android comporte au plus quatre composants : l activité (Activity) le service (Service) le fournisseur de contenu (Content Provider) le gestionnaire de broadcast (Broadcast Receiver) Les composants peuvent être déclarés publics ou privés. http://developer.android.com/guide/components/fundamentals.html Pascal Urien - Télécom ParisTech 34

Application Android Le système d'exploitation Android est un système Linux multiutilisateurs Chaque application est associée à un compte utilisateur (user) diffèrent Par défaut, le système attribue à chaque application un User-ID unique et non connu de l'application. Les autorisations d accès aux fichiers sont basées sur le USER-ID. Par défaut, chaque application s'exécute dans son propre processus Linux. Android démarre le processus lorsque un composant d une application doit être exécuté. Il arrête le processus lorsque l application n est plus utilisée ou lorsque le système a besoin de mémoire pour d autres applications. Chaque processus possède sa propre machine virtuelle (VM), est en conséquence exécuté dans un environnement isolé des autres applications. Le système Android met en œuvre le principe du moindre privilège. Chaque application accède par défaut uniquement aux composants nécessaire à son exécution. Pascal Urien - Télécom ParisTech 35

Activity Une activité représente un écran unique avec une interface utilisateur. Par exemple, une application de messagerie peut avoir une activité qui affiche une liste de nouveaux e- mails, une autre activité pour composer un courriel et une autre activité pour la lecture des emails. Bien que les activités travaillent ensemble pour former une expérience utilisateur cohérente dans l'application de messagerie électronique, chacune est indépendante des autres. Pascal Urien - Télécom ParisTech 36

Service Un service est un composant qui s'exécute en arrière-plan. Un service ne gère pas une interface utilisateur. Par exemple, un service peut jouer de la musique en arrière-plan, ou il peut extraire des données via le réseau sans intervention de l'utilisateur. Un autre composant, comme une activité, peut démarrer le service et interagir avec ce dernier. Pascal Urien - Télécom ParisTech 37

Content Provider Un Content Provider gère un ensemble d information partagées, lié à l application. Les données peuvent être stockées dans le système de fichiers, une base de données SQLite, sur le web, ou tout autre endroit de stockage persistant auquel peut accéder l application. Grâce au Content Provider, d autres applications peuvent lire ou modifier les données (si cette opération est autorisée). Par exemple, le système Android fournit un Content Provider qui gère les contacts de l'utilisateur. Par conséquent, une application munie des autorisations nécessaires peut accéder a ce Content Provider. Pascal Urien - Télécom ParisTech 38

Broadcast Receiver Un Broadcast Receiver est un composant qui interagit avec les messages broadcast du système Les broadcast système par exemple, une indication d extinction de l'écran, une alerte de batterie faible, ou la capture d une photo. Les applications peuvent également produire des messages de broadcast, notifiant par exemple la disponibilité de données. Un Broadcast Receiver ne gère pas d interface utilisateur, mais peut cependant afficher une barre de statut. Typiquement un Broadcast Receiver démarre un service pour assurer le traitement d un évènement. Pascal Urien - Télécom ParisTech 39

Format APK Pour une Application Android Pascal Urien - Télécom ParisTech 40

Android: Intent Les composants activités, services, et broadcast receivers, sont activés par un message asynchrone dénommé Intent. Les messages Intent sont échangées via une architecture logicielle nommée Inter-Process- Communication (IPC) Pascal Urien - Télécom ParisTech 41

Interaction entre composants Accès via des url content://<authorité>/<table>/ Pascal Urien - Télécom ParisTech 42

Construction du Noyau Linux Le noyau est construit à l aide d un outil nommé GIT On peut trouver un exemple d archive à https://github.com/cyanogenmod/samsungkernel-crespo L image du noyau se nomme zimage Exemple de commandes: http://devjlanza.wordpress.com/2011/09/02/android-nexus-s-custom-kernel/ $ cd ~/mydroid $ git clone git://android.git.kernel.org/kernel/samsung.git $ cd samsung $ export ARCH=arm $ export CROSS_COMPILE=<path_to_mydroid>/prebuilt/linux-x86/toolchain/arm- eabi-4.4.3/bin/arm-eabi- $ export CCOMPILER=<path_to_mydroid>/prebuilt/linux-x86/toolchain/arm-eabi- 4.4.0/bin/arm-eabi- $ make ARCH=arm clean $ make ARCH=arm herring_defconfig $ make ARCH=arm menuconfig Pascal Urien - Télécom ParisTech 43 $ make -j2 ARCH=arm samsung\arch\arm\boot\zimage

Construction du build Android (ROM) L image (ROM) est construite à l aide de l outil REPO http://source.android.com/source/index.html Exemple $ mkdir ~/bin $ PATH=~/bin:$PATH $ curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo $ chmod a+x ~/bin/repo $ mkdir WORKING_DIRECTORY $ cd WORKING_DIRECTORY $ repo init -u https://android.googlesource.com/platform/manifest -b android-4.0.1_r1 $ repo sync $ source build/envsetup.sh lunch crespo $ make -j4 Le noyau (zimage) se trouve en \device\samsung\crespo\kernel Trois images sont générées dans out/target/product/crespo : boot.img, recovery.img, system.img Diverses applications sont générées dans out/host/linux-x86/bin adb, emulator, fastboot, mkbootimg Pascal Urien - Télécom ParisTech 44

Binaires Propriétaires pour le Nexus S Hardware Component Orientation sensor WiFi, Bluetooth, GPS Graphics NFC GSM Company AKM Broadcom Imagination NXP Samsung Pascal Urien - Télécom ParisTech 45

boot.img & recovery.img Le mobile android comporte plusieurs devices, dont on obtient la structure (via adb shell) à l aide de la commande #cat /proc/mtd dev: size erasesize name mtd0: 00040000 00020000 "misc" mtd1: 00500000 00020000 "recovery" mtd2: 00280000 00020000 "boot" mtd3: 04380000 00020000 "system" mtd4: 04380000 00020000 "cache" mtd5: 04ac0000 00020000 "userdata Les partitions recovery et boot sont localisées en /dev/mtd/mtd1 et /dev/mtd/mtd2 Une copie de mtd1 est stockée en /system/recovery.img. A chaque coupure d alimentation le contenu de /system/recovery.img est transféré dans /dev/mtd/mtd1 ramdisk La format de boot.img et recovery.img comporte En préfixe de 2 Ko (header) Une image noyau compressé (gzip kernel) Un ramdisk, l image d un petit système de gestion de fichiers Un suffixe optionnel En particulier le fichier default.prop contient la ligne ro.secure=1 qui permet à ADB d être root ou pas Référence http://androiddls.com/wiki/index.php?title=howto:_unpack%2c_edit %2C_and_Re-Pack_Boot_Images Pascal Urien - Télécom ParisTech 46

Détails des partitions /boot C'est la partition de boot. Elle comporte le noyau Android et le ramdisk. Sa présence est nécessaire au démarrage du système Android. En cas de destruction de la partition recovery, une nouvelle ROM (incluant une partition boot) doit être installée avant la mise hors tension du système. /system Cette partition contient l'os Android, c est-à-dire les blocs logiciels autres que le noyau et le ramdisk. La destruction de cette partition implique un démarrage en mode recovery, pour l installation d une nouvelle ROM. /recovery C est une partition de boot alternative, qui assure le démarrage du système à des fins de maintenance ou de mise à jour. /data Cette partition contient des données utilisateur, telles que contacts, sms, paramètres, et applications Android installées. Son contenu est effacé lors d une opération de retour à la configuration usine associée à une ROM (factory reset). /cache Cette partition stocke des données fréquemment consultées (cache de navigateur WEB). Sa destruction n a pas d impact sur le bon fonctionnement du système. /misc Cette partition contient divers paramètres de configuration sous forme d indications activé/désactivé, relativement au réseau, au contexte USB ou des options matérielles. Sa destruction ou l altération de son contenu entraine des disfonctionnements du terminal Android Pascal Urien - Télécom ParisTech 47

Le format update.zip Un fichier update.zip comporte les éléments suivants Une image d un système de fichiers Un répertoire \META-INF\com\google\android qui stocke un ficher updater-script copy_dir, format, delete, delete_recursive, set_perm, set_perm_recursive, show_progress, symilink Une signature java -jar signapk.jar certificate.pem key.pk8 myupdate.zip update.zip java -classpath testsign.jar testsign update.zip update-signed.zip Références http://fokke.org/site/content/howto-createandroid-updatezip-package http://www.londatiga.net/it/how-to-createandroid-update-zip-package/ http://www.synfulgeek.com/main/index.php/ar ticles/76-scratchpad-documenting-edifycommands-for-android-updater-scritps-basedoff-of-kernel-source-code META-INF/ +- MANIFEST.MF +- CERT.SF +- CERT.RSA +- com/ +- google/ +- android/ +- update-script +- update-binary +- updater-script system/ +- etc/ +- sysctl.conf +- security/ +- cacerts.bks Pascal Urien - Télécom ParisTech 48

Android: Boot Pascal Urien - Télécom ParisTech 49

Android: Boot 1/2 Step 1 : Power On and System Startup Lors de la mise sous tension le système exécute un code de démarrage, puis il charge en RAM et démarre la procédure Bootloader Step 2 : Bootloader Bootloader est un petit programme exécuté avant le chargement du système d'exploitation Android; il est dédié à une carte mère particulière. Le fabricant du terminal peut utiliser un bootloader du marché tel que redboot, uboot, qi bootloader, ou une version propriétaire. Ce logiciel n est pas un élément d Android, il permet aux opérateurs de brider certaines fonctionnalités du système. L éxécution de Bootloader est réalisée en deux étapes, la détection de la mémoire RAM et le chargement de logiciels, puis la configuration de divers paramètres (réseau, mémoires, ). Le code du Bootloader Android est stocké en <AndroidSource>\bootable\bootloader\legacy\usbloaderlegacy; il contient deux fichiers importants: 1. init.s - Initializes stacks, zeros the BSS segments, call _main() in main.c 2. main.c - Initializes hardware (clocks, board, keypad, console), creates Linux tags Step 3: Kernel Le noyau Android démarre d une manière similaire aux versions de Linux pour les PCs. A la fin de la phase d initialisation du système, il recherche le fichier init et démarre le premier processus. Step 4: init process Init est le premier processus (root processus), il réalise le montage des répertoires tels que /sys, /dev, /proc et éxécute le script init.rc script Le code source du processus init est à : <android source>/system/core/init Le fichier init.rc se trouve en: <android source>/system/core/rootdir/init.rc Le fichier readme.txt est localisé en: <android source>/system/core/init/readme.txt Pascal Urien - Télécom ParisTech 50

Android Boot: 2/2 Step 5: Zygote and Dalvik Zygote est un processus dédié à la gestion de machine virtuelle DALVIK, qui pré-charge et initialise les bibliothèques de classe. Zygote loading process 1. Load ZygoteInit class, Source Code :<Android Source> /frameworks/base/core/java/com/android/internal/os/zygoteinit.java 2. registerzygotesocket() - Registers a server socket for zygote command connections 3. preloadclasses() - preloaded-classes is simple text file contains list of classes that need to be preloaded, you can find preloaded-classes file at <Android Source>/frameworks/base 4. preloadresources() - preloadreaources means native themes and layouts, everything that include android.r file will be load using this method. A cette étape une animation apparait sur l écran du terminal. Step 6: System Service or Services L entité runtime demande à Zygote de démarrer les serveurs du système (system servers). Le code de ces serveurs est écrit en langage natif ou en langage java. Ces serveurs réalisent tous les services du système Les codes sources se trouvent dans las classe ZygoteInit et la méthode startsystemserver Step 7 : Boot Completed Le boot du système s achève lorsque tous les services sont chargés en mémoire et sont activés Pascal Urien - Télécom ParisTech 51

Rooting & Recovery Rooting La procédure de "rooting" d un système Android dépend du terminal qui l héberge et met à profit des bugs logiciels de sécurité. Le code binaire de la procédure su est copié dans un répertoire tel que /system/xbin/su, et muni des permissions nécessaires à l aide de la commande chmod. De nombreux documents disponibles sur Internet décrivent les opérations nécessaires au "rooting" d un terminal Android. Custom Recovery Lorsque le bootloader Android est en mode déverrouillé (unlocked) il est possible d installer une partition recovery non standard (Custom Revovery). ClockWorkMod Recovery est par exemple fréquemment utilisé pour le "rooting " des systèmes Android. La partition recovery n est pas détruite lors de l installation d une nouvelle ROM. https://sites.google.com/site/tomsgt123/adb-fastboot/understanding-android Pascal Urien - Télécom ParisTech 52

Le mode fastboot Lors de la mise en tension du mobile un combinaison de touches (ex. power_on volume_up) permet de passer en mode fastboot La commande adb reboot bootloader provoque également le passage en fastboot Par défaut le bootloader est verrouillé (locked). Pour verrouiller / déverrouiller le bootloader fastboot oem unlock fastboot oem lock Pour flasher un mobile fastboot flashall w (en mode fasboot) Pascal Urien - Télécom ParisTech 53

L utilitaire Fastboot C:\vaio\android\platform-tools>fastboot usage: fastboot [ <option> ] <command> commands: update <filename> flashall flash <partition> [ <filename> ] erase <partition> getvar <variable> boot <kernel> [ <ramdisk> ] flash:raw boot <kernel> [ <ramdisk> ] devices continue reboot reboot-bootloader help reflash device from update.zip flash boot + recovery + system write a file to a flash partition erase a flash partition display a bootloader variable download and boot kernel create bootimage and flash it list all connected devices continue with autoboot reboot device normally reboot device into bootloader show this help message options: -w erase userdata and cache -s <serial number> specify device serial number -p <product> specify product name -c <cmdline> override kernel commandline -i <vendor id> specify a custom USB vendor id -b <base_addr> specify a custom kernel base address -n <page size> specify the nand page size. default: 2048 Pascal Urien - Télécom ParisTech 54

ADB : Android Debug Bridge device commands: adb push <local> <remote> - copy file/dir to device adb pull <remote> [<local>] - copy file/dir from device adb sync [ <directory> ] - copy host->device only if changed (-l means list but don't copy) (see 'adb help all') adb shell - run remote shell interactively adb shell <command> - run remote shell command adb emu <command> - run emulator console command adb logcat [ <filter-spec> ] - View device log adb forward <local> <remote> - forward socket connections forward specs are one of: tcp:<port> localabstract:<unix domain socket name> localreserved:<unix domain socket name> localfilesystem:<unix domain socket name> dev:<character device name> jdwp:<process pid> (remote only) adb jdwp - list PIDs of processes hosting a JDWP transport adb install [-l] [-r] [-s] <file> - push this package file to the device and install it ('-l' means forward-lock the app) ('-r' means reinstall the app, keeping its data) ('-s' means install on SD card instead of internal storage) adb uninstall [-k] <package> - remove this app package from the device ('-k' means keep the data and cache directories) adb bugreport - return all information from the device that should be included in a bug report. Pascal Urien - Télécom ParisTech 55

adb backup [-f <file>] [-apk -noapk] [-shared -noshared] [-all] [-system -nosystem] [<packages...>] - write an archive of the device's data to <file>. If no -f option is supplied then the data is written to "backup.ab" in the current directory. (-apk -noapk enable/disable backup of the.apks themselves in the archive; the default is noapk.) (-shared -noshared enable/disable backup of the device's shared storage / SD card contents; the default is noshared.) (-all means to back up all installed applications) (-system -nosystem toggles whether -all automatically includes system applications; the default is to include system apps) (<packages...> is the list of applications to be backed up. If the -all or -shared flags are passed, then the package list is optional. Applications explicitly given on the command line will be included even if -nosystem would ordinarily cause them to be omitted.) adb restore <file> adb help adb version - restore device contents from the <file> backup archive - show this help message - show version num scripting: adb wait-for-device - block until device is online adb start-server - ensure that there is a server running adb kill-server - kill the server if it is running adb get-state - prints: offline bootloader device adb get-serialno - prints: <serial-number> adb status-window - continuously print device status for a specified device adb remount - remounts the /system partition on the device read-write adb reboot [bootloader recovery] - reboots the device, optionally into the bootloader or recovery adb reboot-bootloader program - reboots the device into the bootloader adb root - restarts the adbd daemon with root permissions adb usb - restarts the adbd daemon listening on USB adb tcpip <port> - restarts the adbd daemon listening on TCP on the specified port Pascal Urien - Télécom ParisTech 56

Android: Sécurité La sécurité android repose sur trois piliers Les Sandboxes Unix, associées aux processus Les permissions La signature des applications Understanding security on Android Enhance application security with sandboxes, application signing, and permissions C. Enrique Ortiz, Developer and author, About Mobility Weblog Tutorial: Building Secure Android Applications http://siis.cse.psu.edu/slides/android-sec-tutorial.pdf Pascal Urien - Télécom ParisTech 57

Application et User-Id Pour le noyau Linux associé à Android, une application possède un user-id, un id de groupe et un id de groupe secondaire. Chaque application possède des droits d accès en lecture, écriture et exécution. C est une politique de contrôle d accès discrétionnaire (DAC). Le système Unix possède un compte root dont user-id est 0, et qui possède tous les droits. Chaque Application possède sa propre instance de Dalvik Virtual Machine (DVM) Deux applications signées par une même clé privée peuvent partager un Sandbox identique. David Ehringer, The_Dalvik_Virtual_Machine.pdf Pascal Urien - Télécom ParisTech 58

Sandbox et Application User-id Pascal Urien - Télécom ParisTech 59

Partage de processus Pascal Urien - Télécom ParisTech 60

Permissions et Filtrage des Intents Le fichier Manifest.xml définit la structure d une application, c est-à-dire la liste de ses composants Il contient également les demandes de permission d accès aux ressources du mobile Il décrit également les Intents traitées par l application C est le gestionnaire de la politique de sécurité de l application Pascal Urien - Télécom ParisTech 61

Signature des Applications Chaque application (.apk) doit être signée Sous Eclipse on utilise les outils Keytool pour la génération de clés RSA dans un keystore Jarsigner pour la signature d une application Un certificat peut être auto-signé Pascal Urien - Télécom ParisTech 62

Business Model des applications Android Le modèle des applications Android "gratuites" est la collecte d information destinée à la diffusion de publicités ciblées. La collecte d information et son exportation implique l autorisation par l utilisateur d un certain nombre de permissions. Cependant des techniques de collecte dites "Zéro Permission" sont possibles. Pascal Urien - Télécom ParisTech 63

Exemple d attaque 1 Code PIN de verrouillage sous Android 2.3 Pascal Urien - Télécom ParisTech 64

Le Code PIN de Verrouillage de Terminal Code PIN : 1234 Vérifications : Pascal Urien - Télécom ParisTech 65

Le hash du code PIN est stocké dans le fichier /data/system/password.key public byte[] passwordtohash(string password) { if (password == null) { return null; } String algo = null; byte[] hashed = null; try { byte[] saltedpassword = (password + getsalt()).getbytes(); byte[] sha1 = MessageDigest.getInstance(algo = "SHA-1").digest(saltedPassword); byte[] md5 = MessageDigest.getInstance(algo = "MD5").digest(saltedPassword); hashed = (tohex(sha1) + tohex(md5)).getbytes(); } catch (NoSuchAlgorithmException e) { Log.w(TAG, "Failed to encode string because of missing algorithm: " + algo); } return hashed; } https://github.com/android/platform_frameworks_base/blob/master/core/java/com/android/i nternal/widget/lockpatternutils.java Pascal Urien - Télécom ParisTech 66

Le paramètre salt private String getsalt() { long salt = getlong(lock_password_salt_key, 0); if (salt == 0) { try { salt = SecureRandom.getInstance("SHA1PRNG").nextLong(); setlong(lock_password_salt_key, salt); Log.v(TAG, "Initialized lock password salt"); } catch (NoSuchAlgorithmException e) { // Throw an exception rather than storing a password we'll never be able to recover throw new IllegalStateException("Couldn't get SecureRandom number", e); } } return Long.toHexString(salt); } le salt reste constant et ne change qu avec une nouvelle installation Le salt est socké dans le fichier /data/data/com.android.provider.settings/database/settings.db Par la suite l attaque force brute est triviale Pascal Urien - Télécom ParisTech 67

Exemple d attaque 2 Escalade de privilèges "Privilege Escalation Attacks on Android" Lucas Davi, Alexandra Dmitrienko, Ahmad-Reza Sadeghi, Marcel Winandy Pascal Urien - Télécom ParisTech 68

Escalade de privilèges Les privilèges d un composant d une application sont contrôlés par le processus associé (au runtime) Les privilèges du composant appelant un composant publique ne sont pas contrôlés par le processus de l appelé. L escalade de privilège exploite ce défaut Pascal Urien - Télécom ParisTech 69

Partage de processus Deux applications partagent le même processus, si elles utilisent le même utilisateur Linux (défini à l installation et précisé dans l AndroidManifest avec shareduser = ) le même nom du processus (également définissable dans l AndroidManifest avec dans la partie «application» android :process = ) Le même certificat Ces possibilités sont offertes aux développeurs qui souhaitent réaliser des plugins ou des extensions d une application Le partage de processus et l escalade des privilèges permettent par exemple à une Application sans permission d envoyer des SMS via une Application autorisée. Pascal Urien - Télécom ParisTech 70

Exemple d attaque 3 Zero Permission Android Application Pascal Urien - Télécom ParisTech 71

Attaques Zéro Permission La liste des applications et fichiers stockés dans la sdcard peut être collectée sans permission dans le répertoire /sdcard/. Android ne gère pas de politique de sécurité pour les données stockées sur une sdcard externe Le fichier /data/system/packages.list contient la liste des applications installées, et peut être lu sans permission La lecture de certain fichiers utilisés par les applications était possible en 2012 Sans la permission PHONE_STATE il est impossible d obtenir les paramètres IMEI ou IMSI Cependant il est possible de récupérer les identifiants de l opérateur et du fournisseur SIM. Sans la permission INTERNET il est possible de lancer un browser via l INTENT URI_ACTION_VIEW, et de transférer de l information via les paramètres de l URI. Paul Brodeur "Zero-permission android applications" (2012) http://www.leviathansecurity.com/blog/zero-permission-android-applications/ Zero Permission Android Applications -Attacks and Defenses Vee]asha Moonsamy, Lym Batten, 2012 Pascal Urien - Télécom ParisTech 72

Sécurité du GSM Pascal Urien - Télécom ParisTech 73

Architecture Base Station (BTS) Base Station Controler (BSC) MSC+VLR RTC HLR+AuC

Principes Mécanisme de type provisionning Vecteurs d authentification (triplet du GSM) RAND (64 bits), SRES (32 bits), Kc (64 bits, dont 10 à zéro) Algorithmes Clé Ki de 128 bits A3Ki(RAND), calcul de la signature SRES A8Ki(RAND), calcul de Kc A3/A8 est en fait un algorithme unique, le COMP-128 COMP128-1, craqué en 1998, 219 vecteurs COMP128-2, version améliorée de COMP128-2 COMP 128-3, basé sur AES A5(Kc), chiffrement de paquets données (voix) Mode bloc de 112 bits A5/1, version forte, craquée en 99 A5/2, version faible, craquée en 99 A5/3, nouvelle version Pascal Urien - Télécom ParisTech 75

Carte SIM Mobile Station de Base VLR HLR/AuC LAI, TMSI Requête d Identité IMSI Requête d Authentification RAND Triplet (RAND, SRES, Kc) Kc= A8(Ki, RAND) SRES = A3(Ki, RAND) Acquittement Basculement en mode chiffré A5(Kc, TMSI) SRES = SRES? A5 Acquittement A5 Pascal Urien - Télécom ParisTech 76

Contrôle d accès du GSM 1/2 La norme GSM 03.20 décrit de manière concise les principes de mise en œuvre des éléments de sécurité dans un environnent GSM.Une cellule ou un ensemble de cellules sont identifiées par une étiquette LAI (Location Area Identity). Un abonné dispose d un couple de valeurs LAI-TMSI stocké dans son module SIM. Le mobile transmet au VLR les indications LAI et TMSI ; ce dernier tente de retrouver l IMSI identifiant de manière univoque un abonné. En cas d échec de cette opération, il délivre au mobile une requête d identification qui récupère en clair l IMSI mémorisé dans la carte SIM. A ce stade le VLR connaît l IMSI de l abonné. Il transmet au HLR (qui est généralement regroupé avec le bloc AuC) une demande d authentification. Si le compte utilisateur est valide dans la base de donnée de l opérateur, l AuC produit une suite de valeurs connue sous l appellation «triplet du GSM», trois nombres notés RAND, SRES et Kc. Pascal Urien - Télécom ParisTech 77

Contrôle d accès GSM 2/2 RAND est un nombre aléatoire de 16 octets, SRES (Signed RESponse, mot à mot réponse signée) est calculé par l algorithme A3 associé à la clé Ki, soit SRES= A3(Ki, RAND). Kc est la clé utilisée pour le chiffrement des communications, elle est déduite de l algorithme A8 associée à la clé Ki, soit Kc = A8(Ki, RAND). Ce mécanisme est une caractéristique originale du GSM ; en effet le VLR obtient de la part du HLR un ou plusieurs triplets d authentification. Le VLR transmet au mobile un défi RAND. La carte SIM exécute alors la fonction A3 dont le résultat ( SRES =A3(Ki, RAND) ) est renvoyé au HLR qui vérifie alors l égalité entre SRES et SRES. Le VLR choisit un nouveau TMSI, réalise son chiffrement avec l algorithme A5 muni de la clé Kc, puis transmet ce paramètre au mobile qui effectue l opération de déchiffrement. C est la station de base dont dépend le mobile, qui décide du basculement en mode chiffré (basé sur l algorithme A5 muni de la clé Kc) des communications. Pascal Urien - Télécom ParisTech 78

Eléments d identifications Mobile Equipment (ME) IMEI, International Mobile Equipment Identity Subscriber Identity Module (SIM) Ki Subscriber Authentication Key RUN_GSM_ALGO IMSI International Mobile Subscriber Identity DF_GSM/EF_IMSI TMSI Temporary Mobile Subscriber Identity PIN Personal Identity Number protecting a SIM LAI location area identity DF_GSM/EF_LOCI Pascal Urien - Télécom ParisTech 79

Sécurité de l UMTS Pascal Urien - Télécom ParisTech 80

Architecture Pascal Urien - Télécom ParisTech 81

Authentification UMTS - Principes Mutuelle Authentification Authentication and Key Agreement (AKA) Cipher key (CK) and Integrity key (IK) USIM VLR HLR send IMSI RAND(i) AUTN(i) Generate RES(i) Generate authentication vector V(1..n) Compare RES(i) and XRES(i) Pascal Urien - Télécom ParisTech 82

Authentification UMTS - MILENAGE RAND, 128 bits SQN: 48 bits AMF: 16 bits 128 bits + Ou Exclusif ri= 64,0,32,64,96 (rotation gauche) ci= 0,1,2,4,8 OP: clé OPérateur (128 bits) Ek: AES + clé 128bits Pascal Urien - Télécom ParisTech 83

Authentification UMTS Authentication Vector Generate SQN Generate RAND AMF (16 bits) SQN (48 bits) RAND (128 bits) K f1 f2 f3 f4 f5 MAC XRES CK IK AK AUTN := SQN AK AMF MAC AV := Pascal RAND Urien XRES - Télécom CK ParisTech IK AUTN 84

Authentification UMTS - USIM RAND AUTN f5 SQN AK AMF MAC AK K SQN f1 f2 f3 f4 XMAC RES CK IK Verify MAC = XMAC Verify that SQN is in the correct range Pascal Urien - Télécom ParisTech 85

LTE Pascal Urien - Télécom ParisTech 86

Pascal Urien - Télécom ParisTech 87

https://www.troopers.de/wp-content/uploads/2011/10/tr12_telcosecday_schneider_lte.pdf Pascal Urien - Télécom ParisTech 88

LTE: Hiérarchie des clés Pascal Urien - Télécom ParisTech 89

Pascal Urien - Télécom ParisTech 90

Carte à Puce & Secure Elements Pascal Urien - Télécom ParisTech 91

Quelques dates 1974, Brevet de R.Moreno 1977, Brevet de M.Ugon 1987, Première norme ISO 7816 1988, Spécification de la carte SIM 1995, Attaque DPA Paul Kocher 1996, Première norme EMV 1997, Brevet Java Card, US 6,308,317 JCOP (IBM JC/OP), 1998 1999, Global Platform (GP) 2002, dotnet smart card, Hiveminded EEPROM R O M RAM CPU 1988, the 21 (BO ) chip Siemens (SIM) chip, 1997 Pascal Urien - Télécom ParisTech 92

Exemple de Système d Exploitation Pascal Urien - Télécom ParisTech 93

Le Paiement Sécurisé *British Museum Pascal Urien - Télécom ParisTech 94

Le modèle EMV : EuroCard, MasterCard, Visa $$$$$ EMV cards Cryptograms Generation Financial Institution (Bank) Cards Issuer Financial Transaction Authorization Cryptograms Verification HSM Pascal Urien - Télécom ParisTech 95

Exemple: ARQC >> 80AE8000 1D 00 00 00 00 00 00, the transaction amount 00 00 00 00 00 00, the cash back 00 00, the national code of the payment terminal 80 00 00 00 00, the terminal verification result 00 00, the transaction currency code 01 01 01, the transaction date 00, the type of transaction 12 34 56 78, a four bytes random value << 77 1E 9F 27 01 80, Cryptogram Information Data 9F 36 02 00 18, Application Transaction Counter (ATC) 9F 26 08 80 29 D3 A0 BB 2A 5E 60, Application Cryptogram 9F 10 07 06 7B 0A 03 A4 A0 00, Issuer Application data Pascal Urien - Télécom ParisTech 96

La carte SIM From the report of SIMEG#1 in January 1988 "A SIM is the physically secured module which contains the IMSI, an authentication algorithm, the authentication key and other (security related) information and functions. The basic function of the SIM is to authenticate the subscriber identity in order to prevent misuse of the MS (Mobile Station) and the network." Siemens CHIP, 1997 Pascal Urien - Télécom ParisTech 97

La carte SIM L information est organisée en répertoires et fichiers Quelques données IMSI Deux répertoires téléphoniques Un fichier SMS Quelques procédures RUN_GSM_ALGORITHM, calcule l algorithme A3/A8 MF 3F00 DF 7F20 EF 6F20 Kc EF 6F07 IMSI RAND SRES A3 Ki A8 Kc // Run_Gsm_Algorithm(RAND) RAND >> A0 88 00 00 10 01 23 45 67 89 AB CD EF 01 23 45 67 89 AB CD EF << 9F 0C >> A0 C0 00 00 0C << FE 67 7C 9D B8 DD F1 B1 DE 27 18 00 90 00 SRES KC Pascal Urien - Télécom ParisTech 98

La carte USIM Le module UICC stocke au moins une application USIM Le fichier EF_DIR contient la liste des applications USIM Au moins deux applications peuvent être activées simultanément (notion de canaux logiques L index de l application est indiqué dans les deux derniers bits de l octet CLA L algorithme d authentification AKA est réalisé par la commande AUTHENTICATE (INS=88) command Exemple >> 00 88 00 00 20 RAND AUTN << DB 28 SRES CK IK 9000 AUTN:= SQN AK AMF XMAC HLR USIM Pascal Urien - Télécom ParisTech 99

Card Manager Smartcard Administration: GP Issuer Security Domain Other Security Domain Other Application KMC-ID (6B) CSN (Chip Serial Number, 4B) KMC (DES Master Key for Personalization Session Keys) K DEK K ENC K MAC Select ISD ISD Mutual Authentication Global Platform API The VISA Model* Runtime Environment Issuer Application *EMV Card Personalization Specification Version 1.1 July 2007 SKU ENC SKU MAC SKU DEK Secure Channel Application Management downloading - deletion Pascal Urien - Télécom ParisTech 100

Near Field Communication Pascal Urien - Télécom ParisTech 101

Petite Histoire du NFC 1994, Mifare 1K En 2011 les chips Mifare représentent 70% du marché du transport. 2001, ISO 14443 Standards (13,56 Mhz) Type A (Mifare) Type B Type F (Felica) 2004, NFC Forum Mifare (NXP), ISO14443A, ISO14443B, Felica (Sony) Trois modes fonctionnels Reader/Writer, Card Emulation, Peer to Peer Les contrôleurs NFC réalisent le protocole NFC Pascal Urien - Télécom ParisTech 102

De l lso 7816 à ISO 14443 L idée de base du Wi-Fi était la définition d un réseau Ethernet sans fil. L idée de base de l ISO 14443 design était la définition de cartes à puce (ISO 7816) sans contact. Contrairement à la norme IEEE 802.11 aucune sécurité n est définie pour les protocoles radio ISO14443 V= 2 π f c S µ o H ISO 14443 Contactless Mode ISO 7816 Contact Mode H = 5 A/m fc= 13,56 Mhz S= 40 10-4 V= 2,2V Pascal Urien - Télécom ParisTech 103

Définition d un Secure Element. Un Secure Element (SE) est un microcontrôleur sécurisé muni d interfaces électriques et de communication, telles que ISO7816, SPI or I 2 C. OS JAVACARD JCOP GP (Global Platform) ROM 160 KB EEPROM 72 KB RAM 4KB Crypto-processor 3xDES, AES, RSA, ECC Certification CC EAL5+ Security Certificates EMVCo EXAMPLE: NXP PN532 Pascal Urien - Télécom ParisTech 104

NFC et Secure Elements Certain contrôleurs NFC embarquent un Secure Element. Dans ce cas le mode "card emulation" peut être géré par le Secure Element C est le modèle Android 2.3 www.chipworks.com Reader/writer ISO 14443 A-B, MIFARE, FeliCa, NFC Forum tags, ISO 15693 Card Emulation ISO 14443 A-B-B, MIFARE, FeliCa RF, SWP RAM 5Ko, ROM 128 Ko, EEPROM 52 Ko Pascal Urien - Télécom ParisTech 105

La carte SIM se transforme en device NFC: le Contactless Front-end (CLF) The ETSI TS 102 613 Standard A simplified HDLC protocol: SHDLC A physical Link: Single Wire Protocol (SWP) Pascal Urien - Télécom ParisTech 106

NFC Reader/Writer & Card Emulation OTA(Over The Air) Administration SMS, GSM 3.48 NFC CONTROLER SECURE ELEMENT NFC CONTROLER Secure Element Administration SOFTWARE Reader/Writer Card Emulation Host Card Emulation Android 4.4 Pascal Urien - Télécom ParisTech 107

NFC P2P Mode Android NDEF Push Protocol Specification Version 1, 2011-02-22 The NDEF Push Protocol (NPP) is a simple protocol built on top of LLCP which is designed to push an NDEF message from one device to another. Initiator Target Pascal Urien - Télécom ParisTech 108

SD Card with NFC Controller EEPROM 72 Ko http://www.tyfone.com/ http://www.devicefidelity.com/ Pascal Urien - Télécom ParisTech 109

The In2Pay Administration Model* * http://www.devifi.com/assets/whitepaper.pdf Pascal Urien - Télécom ParisTech 110

Apercu des standards NFC Pascal Urien - Télécom ParisTech 111

Résumé des Standards NFC NDEF ISO 14443-2A ISO 14443-3A 14443-2B 14443-3B ISO 14443-2A ISO 14443-3A FELICA SNEP LLCP Passive Mode Active Mode NFCIP-1 ISO 14443-4 NFCIP-1 NFCIP-1 *ISO/IEC_18092 standard and NFCIP-1 standards are similar DEP: Data Exchange Protocol (Supports Read/Write Operations for Tags) Pascal Urien - Télécom ParisTech 112

NFC Radio ISO 14443 106 kbps 212 kbps 424 kbps 848 kbps Standard ISO 14443-2A NFC-A ISO 14443-2B NFC-B PCD to ICCC Reader to Card ASK 100% Modified Miller ASK 10%, NRZ-L PICC to PCD Card to Reader Subcarrier fc/16 OOK Manchester Subcarrier fc/16 BPSK, NRZ-L NFCIP-1 Passive Mode NFCIP-1 Active Mode Bit Rate Initiator Target 106 kbps ASK 100% Modified Miller 212-424 kbps ASK 8-30% OOK Manchester Bit Rate Initiator Target 106 kbps ASK 100% Modified Miller 212-424 kbps ASK 8-30 % OOK Manchester Subcarrier fc/16 OOK Manchester ASK 8-30% OOK Manchester ASK 100%, Modified Miller ASK 8-30%, OOK Manchester Pascal Urien - Télécom ParisTech 113

ISO 14443-3A State Machine REQA: Request Command for Type A ATQA: Answer To Request of Type A SAK: Select AcKnowledge UID: Unique IDentifier UID: 4,7,10 octets About Anti-collision Several devices may be detected at the same time. For example the PN532 NFC controller can work simultaneously with two ISO14443 devices. ISO 14443-4 MIFARE Pascal Urien - Télécom ParisTech 114

ISO 14443-3B State Machine AFI: Application Family Identifier (4 bytes). A card preselection criteria by application type. REQB: Request of Type B ATQB: Answer To Request of Type B ATA: Answer To ATTRIB ISO 14443-4 Pascal Urien - Télécom ParisTech 115

ISO 14443-4 Frames (T=CL) ISO 14443-4 frames transport ISO 7816-4 APDUs ISO 7816-4 APDU Pascal Urien - Télécom ParisTech 116

ISO 14443-4 TYPE A ONLY! RATS: Request for Answer To Select ATS: Answer To Select RATS/ATS is a mean to switch from MIFARE to ISO-14443A (Dual Interfaces Devices) Pascal Urien - Télécom ParisTech 117

NFCIP-1 Initiator State Machine Passive Mode Active Mode SDD Single Device Detection NFCID3: Random ID for transport protocol activation ATR_REQ: Attribute Request ATR_RES: Attribute Response LLCP Activation The Data Exchange Protocol (DEP) works with - DEP_REQ (Data Exchange Protocol Request ), and - DEP_RES (Data Exchange Protocol Response) The NFC-DEP MAC component SHALL use the three octet sequence 46h 66h 6Dh as the NFC Forum LLCP magic number. This magic number is encoded into the ATR_REQ / ATR_RES General Bytes fields Pascal Urien - Télécom ParisTech 118

LLCP: a Bridge to LAN Technologies NCPIP-1 Pascal Urien - Télécom ParisTech 119

1=Record Start 1=Record End 1=First Chunk 1= Payload Length 1= ID Length Structure of TYPE Field 1= Well Known NDEF: NFC Data Exchange Format NDEF Record Example: (NFC Text Record Type Definition) Identifier describing the TYPE of the payload URI reference (RFC 3986) D1: 1 1 0 1 0 001 01: Type Length 0A: Payload Length 54: Type= T, Text 02: ID= UTF8 65 6E: EN 53 61 6D 70 6C 65 20: "Sample " A summary of record TYPE may be found in NFC Tags A technical introduction, applications and products Rev. 1.3-1 December 2011 White paper, NXP Semiconductors. Pascal Urien - Télécom ParisTech 120

NFC TAGs NDEF Format for passive TAG Type 1 Based on ISO 14443-A Innovision Topaz, Broadcom BCM20203 Type 2 Similar to Type1 Based on ISO 144413-A Compatible with NXP MIFARE Ultralight. Type 3 Similar to Type1 Based on the Japanese Industrial Standard (JIS) X 6319-4. Compatible with Sony Felica Type 4 Similar to Type1 Based on ISO 14443-A Compatible with standard ISO 14433-4 Smartcards NXP-specific type tag Mifare Classic LLCP NDEF services SNEP: Simple NDEF Exchange Protocol SNEP Requests and SNEP Responses LLC service access point address 4 Service Name urn:nfc:sn:snep Pascal Urien - Télécom ParisTech 121

Exemple de tag, Type2 Tag Mifare Mifare Ultralight NDEF AID Mifare Classic Type2 Tag Size 48 bytes Mifare Application Directory, MAD Mifare tags are read by Android Mobiles Pascal Urien - Télécom ParisTech 122

Block0 UID MIFARE Sector 0 Manufacturer Data Block3 Block4 KEYA ACCESS Sector 1 KEYB Block7 KEYA ACCESS KEYB Pascal Urien - Télécom ParisTech 123

Mifare UltraLight Page 0 Page 1 Page 2 Page 3 Page 4 Check Byte UID Internal Byte LOCK bits OTP Page 15 OTP: One-Time Programmable (1=set) LOCK bits L BL L7 L6 L5 L4 L15 L14 L13 L12 L11 L10 L9 L8 OTP 15-10 BL BL 9-4 OTP Pascal Urien - Télécom ParisTech 124

NFC et Smartphones Pascal Urien - Télécom ParisTech 125

NFC et Smartphones Nokia Card Emulation and SWP NOKIA 6131 Android 2.3 (Gingerbread), Android 4.0 Reader/Writer and P2P Nexus S (v2.3), Galaxy Nexus (v4.0), Galaxy S2(v2.3) NXP NFC Controller PN65N RIM JDE 7.0.0 (October 2011) Reader/Writter and Card Emulation JSR 177 (SIM Access) Blackberry Bold 9900, 9930 INSIDE SecureRead NFC Controller IPHONE External NFC Reader Rumors for the NFC support NXP PN65N Pascal Urien - Télécom ParisTech 126

2011, Open Mobile API Pascal Urien - Télécom ParisTech 127

HID NFC White Paper: Services SIM centric Trusted Service Manager - Payment - Access Control - Transport Pascal Urien - Télécom ParisTech 128

La plateforme NFC Google Reader/Writer Card Emulation Peer to Peer Android Beams NFC Tags - EMV Magnetic Stripe Profile - Cloud Storage SNEP Pascal Urien - Télécom ParisTech 129

NFC Initiator SNEP, Android 4.x ATR_REQ, NFC-MAGIC VERSION WKS LTO ATR_RES, NFC-MAGIC VERSION WKS LTO LLCP-SYMM [0000] LLCP-SYMM [0000] LLCP-SYMM [0000] CONNECT [1120], DSAP=4, SSAP=32 CC [818402020078], DSAP=32, SSAP=4, MUI Information, SNEP PUT [132000 10020000000F D1010B5402656E 6B657976616C7565] DSAP=4, SSAP=32, NS=0, NR=0, SNEP HEADER, NDEF RECORD, keyvalue RR(1) [834401], SSAP=4, DSAP=32 Information, SNEP Success [830401 108100000000], SSAP=4, DSAP=32, NS=0, NR=1 RR(1) [13600], DSAP=4, SSAP=32 DISCONNECT [1160] DSAP=4, SSAP=32 DM [C400], DSAP=16, SSAP=32 LLCP-SYMM [0000] NFC Target Pascal Urien - Télécom ParisTech 130

Apple Patent, US 2011 0269423 A1 L application USIM est chargée dans le Secure Element du contrôleur NFC Pascal Urien - Télécom ParisTech 131

US Patent US 2014 0019367, Apple Pascal Urien - Télécom ParisTech 132

Au Sujet des Paiements NFC Certain paiements NFC sont basés sur la spécification MasterCard PayPass Deux modes sont définis Mag Stripe, un CVC3 de quatre digits (Card Verification Value) is calculé à partir d un algorithme 3xDES de divers paramètres (PAN, ATC counter, ) Contactless EMV Le Secure Element réalise les calculs cryptographiques et exécute l application EMV. * MasterCard PayPass, M/Chip, Acquirer Implementation Requirements, v.1-a4 6/06 Pascal Urien - Télécom ParisTech 133

Details du profile EMV Mag. Stripe* SELECT 2PAY.SYS.DDF01 SELECT MasterCard Google Prepaid Card GET PROCESSING OPTIONS READ first record PAN 16 digits BCD 64b 4 digits ATC PAN PAN (16d) Expiry Date (4d) KeyA Service Code (3d) xor C PAD Left 64b ENCRYPT A (Zero bit) 128b Right 64b B COMPUTE Cryptographic Checksum G=A23FB35FC89AE3A9 23358939AFBFCAEA 2335893905152040 CVC3=233 D KeyA KeyB KeyA ENCRYPT DECRYPT ENCRYPT E F G *Visa Contactless Payment Specification Version 2.0.2 July 2006 Pascal Urien - Télécom ParisTech 134

Google Acquirer Le Google Wallet 2 Card Not Present transaction (CNP) Customer s Issuer Bank Google Issuer Customer s Cards Card Network Acquirer Bank Google Virtual prepaid card Pascal Urien - Télécom ParisTech 135 MasterCard