(LUẬN VĂN THẠC SĨ) SECURITE POUR LES TELEPHONES PORTABLES

Institut de la Francophonie pour l Informatique Ecole Nationale Supérieure des Télécommunications RAPPORT DE STAGE DE FIN D ETUDES Sujet : SECURITE POUR LES TELEPHONES PORTABLES Etudiant : Pham Viet Tan Nguyen, IFI Responsable : Patrick Bellot, ENST Paris, janvier 2005 TIEU LUAN MOI download : skknchat@gmail.com Remerciements Je tiens remercier particulièrement Monsieur Patrick Bellot, Professeur du Département Informatique et Réseaux (INFRES), l Ecole Nationale Supérieure des Télécommunications (ENST), pour m avoir accueilli et m avoir bien encadré pendant toute la durée du stage J aimerais remercier sincèrement Monsieur Michel Riguidel, Responsable du Département Informatique et Réseaux, l Ecole Nationale Supérieure des Télécommunications (ENST), de ses conseils professionnels et de m a donné des meilleures conditions de travail au cours du stage J exprime également mes vifs remerciements Monsieur Charles Durand, Directeur de l Institut de la Francophonie pour l Informatique (IFI), d avoir préparé mon stage Finalement, je remercie aussi vivement toutes les personnes de l ENST et de l IFI, particulièrement les thésards et les stagiaires de l INFRES, qui m ont porté leur amitié TIEU LUAN MOI download : skknchat@gmail.com Table des matières Remerciements Table des matières Résumé Abstract Liste des figures Chapitre 1: Introduction Chapitre 2: Systèmes embarqués sécurisés : un défi 10 2.1 Exigences de sécurité 10 2.2 Défis de conception d un système embarqué sécurisé 13 2.3 Attaques sur le système embarqué 14 2.3.1 Attaques logicielles 15 Chapitre 3: Téléphones portables 17 3.1 Architecture 17 3.2 SIM 19 3.3 Interfaces entre le téléphone portable et la SIM 20 3.4 Communication par GSM 21 Chapitre 4: Système d exploitation Symbian 24 4.1 Sécurité au niveau de l OS 24 4.1.1 Contrôle d'accès 24 4.1.2 Cryptographie et chiffrement 25 4.1.3 Système de fichiers 25 4.1.4 Gestion de mémoire 25 4.2 Développement d applications 26 4.2.1 Java 26 4.2.2 C++ 27 4.3 Sécurité des applications du téléphone portable 28 4.3.1 Développement 29 4.3.2 Téléchargement 30 4.3.3 Installation 31 4.3.4 Exécution 33 4.3.5 Exploitation 35 Chapitre 5: Améliorer la sécurité des téléphones portables 36 5.1 Renforcer la sécurité des téléphones portables 38 5.1.1 Utilisation systématique des composants matériels dédiés sécurité 39 5.1.2 Sécurité du code 41 5.1.3 Gestion du niveau de sécurité des applications et services 42 5.2 Analyse 43 Chapitre 6: Conclusion 44 Annexe : Vérification de code d octet Java 45 A.1 Introduction 45 A.2 Vue d ensemble de la JVM et de vérification de code d octet 46 A.3 Approches et algorithmes 49 A.3.1 Analyse de flux de données 49 A.3.2 Vérification de l initialisation d objet 55 A.3.3 Problèmes des sous-programmes 58 A.3.4 Vérification de modèles 62 A.4 Vérification pour les dispositifs mobiles 67 TIEU LUAN MOI download : skknchat@gmail.com A.4.1 Vérification légère de code d octet 68 A.4.2 Vérification pour Java Smart Card 69 A.5 Conclusions 71 Références 72 TIEU LUAN MOI download : skknchat@gmail.com Résumé Le problème de la sécurité des téléphones portables connt un regain d intérêt depuis l année 2003 avec la généralisation des plates-formes Symbian OS et Windows CE : leur richesse et leurs failles dans le modèle de sécurité permettent aux attaquants de réaliser des opérations malveillantes comme le ver Cabir et récemment Skulls pour Symbian OS et le ver Dust pour Windows CE Ce travail a pour but de faire une étude profonde sur les problèmes de sécurité des téléphones portables, notamment ceux qui utilisent le système d'exploitation Symbian et le réseau GSM Nous nous concentrons sur les raisons pour lesquelles la sécurité des téléphones portables n'est pas actuellement garantie fin de proposer une approche globale de la sécurité Cette approche passe par la définition d une architecture de sécurité intégrant le téléphone, la SIM, les services de sécurité, et s appuyant sur la certification du code des applications natives ou sensibles Un autre intérêt du stage est la vérification de code d octet Java qui donne la possibilité de prévoir le comportement des programmes avant leur exécution réelle Le stage est réalisé dans le cadre du grand projet européen SEINIT auquel l ENST participe Mots clés : Sécurité des téléphones portables, Symbian, virus, attaques logicielles, informatique de confiance, vérification de code d octet TIEU LUAN MOI download : skknchat@gmail.com Abstract The security problem of mobile phones has taken a lot of interests from 2003 with the generalization of platforms Symbian OS and Windows CE: their richness and weakness in the security model allow attackers realize many malicious operations like the worms Cabir and recently Skulls in Symbian OS or Dust in Windows CE The purpose of this work is to make a survey on security problems of mobile phones, particularly which use the operating system Symbian and GSM network We concentrate on reasons for which the security of mobile phones is not currently guaranteed to propose a global approach of security This approach goes through the definition of a security architecture integrating the phone, the SIM, the services and base on code certification of native or sensible applications Another interest of this internship is the problem of Java bytecode verification which gives the possibility to predict programs behavior before their real execution This work is realized in the context of European project SEINIT, in which ENST is involved Keywords: mobile phone security, Symbian, virus, software attack, Trusted Computing Base, bytecode verification TIEU LUAN MOI download : skknchat@gmail.com Liste des figures Figure Les exigences de sécurité pour un smartphone 10 Figure Les exigences communes de sécurité de systèmes embarqués 11 Figure Les attaques sur les systèmes embarqués 15 Figure L'architecture logicielle du téléphone portable 18 Figure La communication par GSM 22 Figure L'architecture de l'OS Symbian v8.0 24 Figure Le constructeur de deux phases (droit) dans le Symbian et le constructeur standard (gauche) 28 Figure Exemple de code source Java et le code d octet correspondant 47 Figure Quelques expressions de types utilisées par le vérificateur et leur relation de soustype 50 Figure 10 Exemple de sous-programme et le code d'octet correspondant 58 Figure 11 Flux de contrôle dans l'approche de vérification de modèles 67 TIEU LUAN MOI download : skknchat@gmail.com Chapitre 1: Introduction Aujourd'hui, les dispositifs mobiles apparaissent sous différentes formes et caractéristiques Un dispositif mobile typique utilise un système d'exploitation qui permet l'installation de logiciels de producteurs tiers La plupart des produits ont aussi des logiciels préinstallés pour la gestion des informations personnelles telles que des applications de carnet d'adresses ou de calendrier Quelques dispositifs incluent des applications préinstallées comme des browsers, des applications de traitement de textes, des programmes de courrier électronique, etc Ces dispositifs sont connus généralement sous le nom d'assistant numérique personnel (PDA par la suite) Pour échanger des données avec les ordinateurs de bureau, les autres PDAs ou le réseau local, les PDA sont souvent incluent les mécanismes de communication (série, IrDA, BlueTooth, réseau local sans fil) En plus de la fonctionnalité standard de PDAs, le smartphone ajoute un téléphone portable intégré Cette intégration permet aux utilisateurs de porter un seul dispositif au lieu d'un portable et d'un PDA Le sujet de la sécurité des dispositifs mobiles, en général, ou des téléphones portables, spécifiquement, n'est pas nouveau, en 2000, le virus VBS/Timofonica [52] avait pour charge d'envoyer des SMS1 aux abonnés du service Movistar Ce virus se propageait toutefois exclusivement sur les ordinateurs personnels (PC par la suite) et n'avait pas d'impact sur les téléphones visés Depuis l'année 2003, le problème de la sécurité connt un regain d'intérêt avec la généralisation des plates-formes Symbian OS [46] et Windows CE [35], qui sont beaucoup plus performantes en termes de programmation que les anciens téléphones propriétaires La richesse de ces plates-formes et leurs failles dans le modèle de sécurité permettent aux attaquants de réaliser des attaques comme le ver Cabir [3] et récemment Skulls [42] pour Symbian OS et le ver Dust [13] pour Windows CE Ce rapport a pour but de faire une enquête sur les problèmes de sécurité des téléphones portables, notamment les smartphones qui utilisent le système d'exploitation (OS par la suite) Symbian et le réseau GSM Nous nous concentrons sur les raisons (les exigences de SMS: Short Message Service TIEU LUAN MOI download : skknchat@gmail.com sécurité et les solutions existantes) pour lesquelles la sécurité des téléphones portables n'est pas actuellement garantie fin de proposer une approche globale de la sécurité Ce stage avait été intitulé dans un premier temps « Analyse de code d octet Java » qui a pour but de faire des études sur la vérification de code d octet Java et d écrire ensuite un analyseur (vérificateur) Java pour Symbian Au cours de réalisation du stage, nous avons constaté que le but initial n est pas assez pour garantir la sécurité des téléphones portables (comme montré dans ce rapport), le sujet est devenu ensuite « Sécurité pour les téléphones portables » Ce travail est réalisé dans le cadre d un grand projet, SEINIT (Security Expert Initiative, http://www.seinit.org), entre les universités et les entreprises européens, auquel l ENST participe L objectif de SEINIT est d assurer un cadre de sécurité et de confiance, fonctionnant sur de multiples dispositifs et sur des réseaux hétérogènes Omniprésent, interopérable, ce cadre sera également centré autour de l utilisateur final En particulier, SEINIT définira des modèles de confiance et de sécurité innovants afin de répondre aux nouveaux enjeux de l environnement numérique ambiant Le reste de ce rapport se compose de cinq chapitres Le chapitre aborde les exigences de sécurité pour le système embarqué en général ainsi des défis de conception et les attaques sur le système embarqué Une anatomie de l'architecture des téléphones portables est donnée dans le chapitre Le chapitre concentre sur l'OS Symbian et le développement des applications dans cet environnement Le chapitre décrit les aspects pour le renforcement de la sécurité des téléphones portables Finalement, le rapport se termine par la dernière section avec de conclusion dans le chapitre Ce rapport se compose également d une annexe abordant la vérification de code d octet Java Nous décrivons des divers algorithmes et leurs problèmes principaux, par exemple dans l implémentation existante de Sun TIEU LUAN MOI download : skknchat@gmail.com 10 Chapitre 2: Systèmes embarqués sécurisés : un défi 2.1 Exigences de sécurité Les téléphones portables, spécifiquement ou les systèmes embarqués, en général, fournissent souvent les fonctions critiques qui pourraient être sabotées par des entités malveillantes Avant de discuter les exigences communes de sécurité des systèmes embarqués, il est important de noter qu'il y a beaucoup d'entités impliquées dans la chne de conception, de fabrication, et d'utilisation d'un système embarqué Les exigences de sécurité changent selon les perspectives que nous considérons Par exemple, considérons un smartphone2 qui est capable de communications de données, de multimédia, et de voix sans fils Les exigences de sécurité selon les points de vue des différents participants sont comme suit : Utilisateur final Intimité et l intégrité des données personnelles Appels et transactions frauduleux Perte/vol Exécution sécurisée des applications téléchargées Fournisseur de contenu Fournisseur de service des applications Fournisseur de service Fabricant de téléphone Fournisseur de logiciel et de matériel Sécurité de contenu, gestion des droits numériques Communications sécurisées Non-répudiation Accès sécurisé au réseau Utilisation frauduleuse de service Protection des propriétés intellectuelles Figure Les exigences de sécurité pour un smartphone Les soucis de l'utilisateur peuvent inclure la sécurité des données personnelles stockées et communiquées par le téléphone, pendant que l'inquiétude du fournisseur de contenu peut Le mot smartphone est utilisé dans ce rapport comme une combinaison d un téléphone portable traditionnel et d un assistant numérique personnel (PDA) Les smartphones diffèrent des téléphones portables normaux sur le point qu ils ont un système d exploitation et le stockage local, pour que l utilisateur ou les encarteurs puissent ajouter l information et les applications comme les PDAs TIEU LUAN MOI download : skknchat@gmail.com 64 détermination profite de l'information de typage telle que les types de retaddr(ra) pour déterminer avec certitude le point auquel une instruction ret se branche en cas de retour tôt partir des sous-programmes nichés Un autre avantage de la vérification polyvariante est qu'elle manipule le code qui est accessible partir des corps de sous-programme et de programme principal, tel que les traiteurs d'exception mentionnés dans la section A.3.3.2 : plutôt que de décider si de tels traiteurs d'exception font partie d'un sous-programme ou pas, l'analyse polyvariant les analyse simplement plusieurs fois, une fois dans le contour vide et une fois ou plusieurs fois dans des contours de sous-programme Un inconvénient de la vérification polyvariante est qu'elle est plus complexe que l'approche de Sun au niveau de calculs En particulier, si des sous-programmes sont nichées la profondeur N, et chaque sous-programme est appelé k fois, les instructions de la sousprogramme la plus intérieure sont analysées kN fois au lieu d'une fois dans l'algorithme de Sun Cependant, en pratique, la plus part des méthodes de Java a N 1, très peu a N = et N > est inconnue Donc, le coût extra de vérification polyvariante est entièrement acceptable dans la pratique Un autre inconvénient plus sérieux de cette approche est que la vérification polyvariante basée sur les contours peut ne pas accepter le code valide parce que la structure de sousprogramme qu'elle infère par la construction des contours peut être infinie Alternativement, la terminaison peut être assurée en exigeant que les contours ne contiennent jamais deux fois la même étiquette de sous-programme : un jsr contour contenant dans un est rejeté, selon les spécifications la de JVM qui déclare que les sous- programmes ne peuvent pas être récursives (C'est ce que le vérificateur de Java Card [A32] fait.) Mais dans ce cas, on finit par le rejet d'un morceau valide de code d octet de JVM, généré par la compilation d'un programme Java valide L'utilisation des contours données-indépendants pour diriger la vérification polyvariante peut causer trop ou même infiniment beaucoup de différents états qui doivent être stockés pour un point donné de programme, même si ces états sont exactement identiques On TIEU LUAN MOI download : skknchat@gmail.com 65 décrit maintenant une approche alternative la vérification polyvariante, n'employant pas des contours, qui évite ces problèmes A.3.4.2 Vérification de modèles des interprétations abstraites Les analyses de flux de données peuvent être vue comme la vérification de modèles (model checking) des interprétations abstraites [A28] Puisqu'une grande partie des vérifications de code d octet est évidemment une interprétation abstraite (d'une JVM défensive au niveau de type), il est normal de regarder les parties restantes dans une perspective de vérification de modèles Posegga et Vogt [A22] étaient les premiers dans cette approche Ils décrivent un algorithme qui prend le code d octet pour une méthode et produit une formule temporelle de logique qui est vérifiée si et seulement si le code d octet est sûr Ils emploient alors un vérificateur de modèle disponible immédiatement pour déterminer la validité de la formule Tandis que cette application emploie seulement une petite partie de la puissance et de la généralité de la logique temporelle et du vérificateur de modèle, l'approche semble intéressante pour établir des propriétés plus fines du code d octet qui dépassent les propriétés de base de sûreté de la vérification de code d octet Brisset [A2] et Coglio [A3], indépendamment, extraient l'essence de l'approche de vérification de modèles : l'idée d'explorer tous les états accessibles de l'interprète abstrait Ils considèrent la relation de transition obtenue en combinant la relation de transition de l'interprète abstrait au niveau de type avec la relation de « successeur » entre les instructions Cette relation est de la forme (p,S,R) (p',S',R'), signifiant que l'interprète abstrait, commencée au CP p avec le type de pile S et le type de registre R, peut abstraitement exécuter l'instruction p et arriver au CP p avec le type de pile S et enregistrer le type R Les transitions additionnelles (p,S,R) err sont proposées pour refléter les états (p,S,R) dans lesquels l'interprète abstrait est « obstrué » (ne peut pas faire une transition parce qu'un certain vérification échoué) (p,S,R) (p ,S ,R ) si instr(p) : (S,R) (S ,R ) et p est un successeur de p (p,S,R) err si instr(p) : (S,R) L'algorithme de vérification BC (Brisset-Coglio) explore simplement tous les états accessibles par des applications rộpộtộes de la relation ộtendue de transitions commenỗant TIEU LUAN MOI download : skknchat@gmail.com 66 par l'état initial = (0, ,(P0, ,Pn-1,T, ,T)) correspondant l'entrée de méthode En d'autre termes, on écrit C( ) = | pour la fermeture d'une étape d'un ensemble d'états , l'algorithme BC calcule par itération de point fixe l'ensemble le plus petit c contenant et fermé sous C Si err c, l'état d'erreur est accessible et le code d octet est rejeté Autrement, le code d octet passe la vérification Dans le dernier cas (err n'est pas accessible), l'exactitude de l'interprétation abstraite (comme prouvé dans [A23]) garantit que l'interprète concret et défensif de JVM n'échouera jamais une vérification de sûreté pendant l'exécution du code de méthode, par conséquent le code d octet est sûr Cet algorithme se termine toujours parce que le nombre d'états distincts est fini (quoique grand), puisqu'il y a un nombre fini de types distincts utilisés dans le programme, et que la taille de la pile est bornée, et que le nombre de registres est fixe Le problème avec des sous-programmes décrits dans la section A.3.3 dispart complètement dans cette approche Il suffit d'employer les transitions suivantes pour les instructions jsr et ret : (p,S,R) ( ,retaddr(p+3).S,R) si instr(p) = jsr (p,S,R) (q,S,R) si instr(p) = ret r et R(r) = retaddr(q) (p,S,R) err si instr(p) = ret r et R(r) retaddr(q) Un autre intérêt de cette approche est qu'il nous permet de reconsidérer certaines des décisions de conception expliquées dans les sections A.3.1.2, A.3.1.3 et A.3.2 En particulier, l'algorithme BC ne calcule jamais les bornes supérieures des types, mais vérifie simplement des relations de sous-types entre les types Ainsi, il peut être appliqué n'importe quelle relation de sous-type bien fondée, pas seulement les relations qui forment un semi-treillis En effet, il peut suivre des types d'interface et vérifier des instructions invokeinterface exactement, sans devoir traiter des ensembles de types ou de complétion de treillis De même, il est possible de vérifier le code où la taille de pile n'est pas la même sur tous les chemins menant une instruction Cette approche a été prouvée l exactitude l aide de Coq dans [A2] et aussi dans [A13] en utilisant Isabelle/HOL Pourtant, l'algorithme de vérification BC basé sur la vérification de modèles peut être impraticable : il fonctionne temps exponentiel en le nombre de TIEU LUAN MOI download : skknchat@gmail.com 67 branches de conditionnelle ou de N-chemins dans la méthode Considérons le joint de flux de données représenté sur la Figure 11, partie gauche Tandis que les algorithmes de flux de données vérifient les instructions suivant le point de joint seulement une fois dans la supposition r : C où C = bs(D,E) (bs est la borne supérieure), l'algorithme BC les vérifie deux fois, une fois dans la supposition r : D, une fois dans la supposition r : E Considérons maintenant le flux de contrôle montré dans la partie droite de la Figure 11 Il se compose de N constructions conditionnelles, chacune assigne un type différent aux registres r1 rN Les instructions après le dernier conditionnel doivent être vérifiées 2N fois sous 2N types différents du registre Figure 11 Flux de contrôle dans l'approche de vộrification de modốles Une faỗon pour amộliorer l'efficacitộ de l'algorithme BC est de réduire le nombre d'états qui doivent être explorés par l'application judicieuse d'étapes d'élargissement (widening steps) : quelques transitions (pc,S,R) (pc',S',R') peuvent être remplacées par (pc,S,R) (pc',S'',R'') où R'