SECURITE POUR LES TELEPHONES PORTABLES

Résumé Le problème de la sécurité des téléphones portables connaît 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 riche

Institut de la Francophonie pour l Informatique

Ecole Nationale Supérieure des Télécommunications

RAPPORT DE STAGE DE FIN D ETUDES

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é

Table des matières

Remerciements 2

Table des matières 3

Résumé 5

Abstract 6

Liste des figures 7

Chapitre 1: Introduction 8

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

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

Résumé

Le problème de la sécurité des téléphones portables connaît 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

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

Liste des figures

Figure 1 Les exigences de sécurité pour un smartphone 10

Figure 2 Les exigences communes de sécurité de systèmes embarqués 11

Figure 3 Les attaques sur les systèmes embarqués 15

Figure 4 L'architecture logicielle du téléphone portable 18

Figure 5 La communication par GSM 22

Figure 6 L'architecture de l'OS Symbian v8.0 24

Figure 7 Le constructeur de deux phases (droit) dans le Symbian et le constructeur standard (gauche) 28

Figure 8 Exemple de code source Java et le code d octet correspondant 47

Figure 9 Quelques expressions de types utilisées par le vérificateur et leur relation de sous-type 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

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é connaît 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

1

SMS: Short Message Service

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 2 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 3 Le chapitre 4 concentre sur l'OS Symbian et le développement des applications dans cet environnement Le chapitre 5 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 6

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

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 Sécurité de contenu, gestion des droits numériques

Fournisseur de service des applications

Communications sécurisées Non-répudiation

Fournisseur de service Fabricant de téléphone

Accès sécurisé au réseau Utilisation frauduleuse de service

Fournisseur de logiciel et de

matériel

Protection des propriétés intellectuelles

Figure 1 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

2

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

être la protection des contenus multimédias fournis au téléphone, et le fabricant de téléphone pourrait en plus s'intéresser au secret du logiciel de propriété industrielle qui réside dans le téléphone Pour chacun de ces cas, l'ensemble des entités non sûres (potentiellement malveillantes) peut également changer Par exemple, dans la perspective

du fournisseur de contenu, l'utilisateur du téléphone peut être une entité non sûre

La Figure 2 cite les exigences de sécurité pour les systèmes embarqués, qui sont décrits comme suit :

Figure 2 Les exigences communes de sécurité de systèmes embarqués

Identification de l'utilisateur indique le processus d'authentifier les utilisateurs avant

de leur permettre d'utiliser le système

Accès sécurisé au réseau fournit une connexion de réseau ou un accès de service

seulement si le dispositif est autorisé

Communications sécurisées se composent d'authentification de communication entres

les égaux, d'assurance de confidentialité et d'intégrité des données communiquées, d'empêchement de répudiation d'une transaction, et de protection de l'identité des

entités communiqués

Stockage sécurisé garantit la confidentialité et l'intégrité des informations sensibles

stockées dans le système

Contenu sécurisé impose les restrictions d'utilisation du contenu numérique stocké ou

consulté par le système

Disponibilité s'assure que le système peut exécuter sa fonction attendue et servir les

utilisateurs légitimes à tout moment, sans être interrompu par des attaques de déni de

service

Plusieurs primitives fonctionnelles de sécurité ont été proposées dans le contexte de la sécurité du système informatique Ceux-ci incluent divers algorithmes cryptographiques utilisés pour chiffrer et déchiffrer les données, et pour vérifier l'intégrité des données En général, les algorithmes cryptographiques peuvent être classifiés en trois classes :

chiffrements symétriques (l expéditeur et le récepteur emploie la même clé secrète pour chiffrer et déchiffrer des données), chiffrements asymétriques (également appelés

algorithmes à clés publiques, emploient une clé secrète privée pour le déchiffrage, et une

clé publique relative non-secrète pour le chiffrage ou la vérification), et les algorithmes de hachage (fournissent des « signatures » pour des messages et la vérification d intégrité)

Les solutions de sécurité pour répondre aux exigences de sécurité se fondent typiquement sur les primitives cryptographiques mentionnés ci-dessus, ou sur les mécanismes de sécurité qui emploient une combinaison de ces primitives d'une façon spécifique (par exemple, des protocoles de sécurité) Des technologies et des mécanismes de sécurité ont été conçus autour de ces algorithmes cryptographiques afin de fournir des services de sécurité spécifiques Par exemple :

Les protocoles de sécurité fournissent des manières d'assurer les canaux de

transmission pour le système embarqué IPSec et SSL sont des exemples populaires des protocoles de sécurité, largement utilisés pour les réseaux privés virtuels (VPNs) et les transactions web

Les certificats numériques fournissent des manières d'associer l'identité à une entité,

et les technologies biométriques comme la reconnaissance d'empreinte digitale et la reconnaissance de voix aident à l'authentification d'utilisateur final Les signatures numériques, qui fonctionnent comme équivalents électroniques des signatures manuscrites, peuvent être utilisées pour authentifier la source de données et également pour vérifier son identité

Les protocoles de gestion des droits numériques, tels que OpenIPMP, MPEG, ISMA,

et MOSES, fournissent les cadres sécurisés pour protéger le contenu d'application contre l'utilisation non autorisée

Le stockage sécurisé et l'exécution sécurisée exigent que l'architecture du système

soit adaptée pour des considérations de sécurité Les exemples simples incluent l'usage

du matériel pour surveiller des transactions de bus et de bloquer des accès illégaux aux secteurs protégés dans la mémoire [12], l'authentification du progiciel qui s'exécute sur

le système, l'isolement d'application pour préserver l'intimité et l'intégrité du code et les données associées à une application ou à un processus donnée [32], les techniques matériels/logiciels pour préserver l'intimité et l'intégrité des données dans toute la hiérarchie de mémoire [43], l'exécution du code chiffré [30], etc

2.2 Défis de conception d un système embarqué sécurisé

Dans le monde des systèmes embarqués, les concepteurs d'un système embarqué doivent supporter de diverses solutions de sécurité afin de traiter un ou plusieurs des exigences de sécurité décrites ci-dessus Ces exigences présentent des empêchements dans le processus

de conception, qui sont brièvement décrits ci-dessous :

Brèches de traitement : Dans les systèmes avec les ressources modestes de traitement

et de mémoire, les demandes élevées de calculs pour les services de sécurité exigent normalement des changements dans la technologie (par exemple, couper le processus

de code d octet Java en deux phases) ou l utilisation des composants dédiés

Flexibilité : Un système embarqué est souvent conçu pour répondre aux exigences

d'exécution des multiples et diverses protocoles de sécurité et standards pour supporter : des objectifs de sécurité, l'interopérabilité dans différents environnements, le traitement

de sécurité dans différentes couches de réseau (par exemple, un PDA permettant le réseau local sans fil pour la connexion au réseau privé virtuel et supportant la navigation sécurisé de web doit exécuter WEP, IPSec et SSL) En outre, avec des protocoles de sécurité constamment visée par des hackers, il n'est pas étonnant qu'ils continuent à se produire de nouvelles attaques Il est souhaitable de permettre à l'architecture de sécurité d'être assez flexible (programmable) pour adapter facilement aux changements Cependant, la flexibilité peut également causer des difficultés envers

la sécurité

Tamper-résistance : Les attaques des logiciels malveillants tels que des virus et des

chevaux de Troie sont les menaces les plus communes à n'importe quel système embarqué qui est capable d'exécuter des applications téléchargées Puisque ces attaques peuvent compromettre la sécurité de tous points de vue (l intégrité, des données

personnelles, la disponibilité), il est nécessaire de développer et déployer de diverses

contre-mesures matériels/logiciels contre ces attaques

Brèches d'assurance : Il est bien connu qu'il est beaucoup plus difficile de construire

des systèmes véritablement plus fiables que ceux qui fonctionnent simplement dans la plupart du temps Les systèmes sûrs doivent pouvoir manipuler des situations qui peuvent se produire par hasard et ils relèvent un plus grand défi : ils doivent continuer à fonctionner sûrement en dépit des attaques réalisées par des adversaires intelligents qui cherchent intentionnellement des modes de défaillances indésirables Lors que les systèmes deviennent plus complexes, il y a inévitablement des modes de défaillance qui

doivent être adressés

Notons que les deux autres facteurs, le cỏt et la batterie, influent également sur l efficacité des mesures de sécurité d un système embarqué

2.3 Attaques sur le système embarqué

Il est important de définir au début quelles capacités de sécurité sont exigées, comme par exemple les attaques qui doivent être empêchées Une issue orthogonale est le niveau exigé

de l'assurance, c'est-à-dire la probabilité que ces buts ont été atteints La Figure 3 cite les diverses catégories des techniques utilisées pour attaquer un dispositif Au niveau supérieur, les attaques peuvent être classifiées dans deux larges catégories : attaques

physiques et side-channel, et attaques logiques

Les attaques physiques et side-channel [2][29][39][28] se réfèrent aux attaques qui

exploitent l'implémentation du système et/ou identifient les propriétés de l'implémentation

Des attaques physiques et side-channel sont généralement classifiées en des attaques invasives et non-invasives Les attaques invasives ont pour but d'obtenir l'accès au

dispositif pour observer, manipuler, et interférer dans les systèmes internes Puisque les attaques invasives exigent typiquement une infrastructure relativement chère, elles sont

assez difficiles à déployer Les exemples des attaques invasives incluent micro-probing et rétro-ingénierie (reverse engineering) de la conception Il y a beaucoup de formes

d'attaques non invasives telles que des attaques de synchronisation, des techniques d'induction de faute, des attaques basées sur l'analyse électromagnétique et l analyse de consommation

Micro-probing Rétro-ingénierie

Temps de calcul Analyse de consommation SPA DPA Electromagnétique Analyse

SEMA DEMA Injection de faute

Virus Chevaux de Troie

Faiblesses de crypto et de protocole

Figure 3 Les attaques sur les systèmes embarqués

Les attaques logiques sont faciles à déployer contre les capacités d'exécuter les applications téléchargées, et exploitent des faiblesses ou des bogues dans l'architecture globale (matériel/logiciel) aussi bien que des problèmes dans la conception de l'algorithme cryptographique ou du protocole de sécurité Dans la pratique, les attaquants utilisent souvent une combinaison des plusieurs techniques pour atteindre leurs objectifs Par exemple, pour un smartphone, du point de vue de l'attaquant, les objectifs visés sont :

de rendre inutilisable le téléphone portable;

de modifier le comportement du téléphone;

d'accéder aux données sensibles;

d'émettre des appels voix ou données à l'insu de l'utilisateur;

d'outrepasser les politiques de gestion des droits numérique

Dans le cadre de ce rapport, nous concentrons sur la menace la plus importante, les attaques logicielles

2.3.1 Attaques logicielles

Les attaques logicielles représentent une menace importante pour les systèmes embarqués qui sont capables de télécharger et d'exécuter des applications Par rapport aux attaques

physiques et side-channel, les attaques logicielles exigent typiquement une infrastructure

qui est facilement disponible Ces attaques sont implémentées par des agents malveillants

comme les virus, les vers, les chevaux de Troie, etc., et ils peuvent exploiter des failles dans l'OS ou le logiciel d'application, obtenir l'accès aux systèmes internes, et perturber ses fonctions normales à fin de manipuler des données ou des processus sensibles (attaques d'intégrité), relever des informations personnelles, et/ou dénier l'accès aux ressources de système (attaques de disponibilité),

Des agents malveillants effectuent des attaques logiciels par l'exploitation des faiblesses dans l'architectures du système final sont étudiés dans [9][45][37][4][20] Ils se présentent typiquement en raison des imperfections dans le logiciel, qui peuvent être nommés comme vulnérabilités [9]

Le problème de débordement de mémoire (buffer overflow) est un trou commun dans les

systèmes d'exploitation et les logiciels d'application, qui peut être exploité dans les attaques logicielles [7] Le problème peut avoir lieu à cause de la vérification réduite des limites des

tampons Les effets de débordement de mémoire peuvent réécrire (overwriting) la mémoire

de la pile, les tas, et les pointeurs de fonction L'attaquant peut utiliser le débordement de mémoire pour réécrire les adresses du programme stocké tout près, ceci lui permet de transférer le contrôle au code malveillant, qui, une fois exécuté, peut avoir des effets indésirables

de l'unité centrale: mémoire vive (RAM5) et mémoire flash avec des volumes supérieurs au méga-octet, parfois un peu de mémoire morte (ROM6 et OTP7) pour des services dédiés à

la sécurité De plus, des processeurs dédiés multimédia peuvent également être présents afin de compenser le manque de puissance de certains processeurs Finalement, les interfaces écran, clavier, connecteurs (série, IrDA, BlueTooth), haut-parleur, micro, etc., habillent le tout Ainsi, l'architecture matérielle est comparable à ce que l'on connaît dans le monde PC, avec bien souvent les mêmes fabricants sauf une différence importante, la configuration matérielle d'un téléphone portable n'est pas modifiable par l'utilisateur

18

Figure 4 L'architecture logicielle du téléphone portable

Au niveau du logiciel, l'architecture est plus variable suivant les fabricants de téléphones portables L'ensemble des applications du téléphone s'exécute au-dessus de l'OS, (Figure 4)

à l'exception de l'application GSM8 et des protocoles associés qui reposent généralement sur une implémentation propriétaires pour des raisons de performance L'OS fournit l'interface de programmation (API par la suite) qui tient compte de l'intégration de téléphone de n'importe quelle tiers application tiers et donc ces types d'OS sont dits

« ouverts » De plus, les applications peuvent profiter des capacités de communication de données de téléphone Toutes les applications typiques d'Internet telles que des browseurs, des clients d'email, et des messagers instantanés fonctionnent au-dessus du service des données du téléphone La tendance actuelle va vers des téléphones portables à base d'OS ouverts, tels que Embedded Linux [14], Symbian [46] et WindowsCE [35], la mise à jour

de l'OS étant par ailleurs possible dans certains cas

8

GSM: Global System for Mobile Communications

Contrairement à la SIM9, notons que les informations/applications ne sont pas propriété exclusive de l'opérateur Plus précisément, nous pouvons classifier les informations/applications liées aux services de l'opérateur (par exemple, l'application GSM), celles liées à des services additionnels relevant de différents fournisseurs de services (par exemple l'accès à un portail, e-commerce), ou celles de l'utilisateur (par exemple, un agenda électronique)

Les mécanismes de sécurité doivent prendre en compte les exigences de chaque acteur (voir section 4.3) Actuellement l'opérateur se positionne en tant que fournisseur de service vis-à-vis de l'utilisateur A ce titre, il est à même d'assurer que le niveau de sécurité est conforme à l'attente de l'utilisateur En particulier, dans le contexte d'un commerce électronique, l'opérateur garantit à l'utilisateur la confidentialité, l'authenticité et la validité

de la transaction

3.2 SIM

La SIM est venu un long chemin depuis sa conception dans 1988 comme un module d'authentification avec une quantité limitée de mémoire Dans chaque téléphone portable, cette petite carte à puce est la seule partie de l'opérateur qui reste avec le client Dans ses premiers jours, la SIM a contenu l'identité d'abonné individuelle, l'algorithme d'authentification et les clés, ainsi que d'autres fonctions de sécurité telles que la PIN10, qui

a été présentée la première fois en 1991 La SIM a permis ensuite aux opérateurs de gérer

la facturation et d'autres informations sur leurs clients, et d'authentifier l'utilisateur pour l'accès au réseau

L'architecture SIM se compose généralement d'un microprocesseur CISC11 8 bits cadencé à 4,77 MHz, mais de plus en plus, d'un processeur RISC 32 bits à 30 ou voire 100 MHz La SIM intègre également de la mémoire sous forme de ROM qui accueille essentiellement l'OS, d'EEPROM12 qui sert à stocker les applications et les données persistantes, et de RAM Il est important de noter que la SIM intègre aussi un cryptoprocesseur dédié aux fonctions cryptographiques

La SIM peut être considérée comme un ordinateur à seul processeur qui se compose de l'OS, de système de fichiers et des applications Les OS propriétaires sont généralement développés pour un unique service (au minimum, les fonctionnalités décrites dans la spécification GSM 11.11 [15]) Avec les OS « ouvert » tels que JavaCard, le téléchargement de nouvelles applications, et dans certains cas, la mise à jour de l'OS est possible Aujourd'hui, la tendance est à l'uniformisation des OS autour de JavaCard

Une caractéristique fondamentale de la SIM est que son ensemble d'informations et d'applications contenues appartient à l'opérateur, non à l'utilisateur Nous pouvons donc s'appuyer sur des mécanismes de sécurité fortement centralisés pour garantir un haut niveau

de sécurité

3.3 Interfaces entre le téléphone portable et la SIM

L'Institut européen des normes de télécommunication (ETSI) définit dans la spécification GSM 11.11 [15] les caractéristiques physiques (connecteurs), électroniques (protocole de transmission) et logique (commandes) de l'interconnexion du téléphone portable et de la SIM Au niveau applicatif, la spécification GSM 11.14 ou SIMToolKit de l'ETSI [16] définit une plate-forme pour le développement de fonctionnalités implémentées dans la majorité des téléphones portables, une partie du code s'exécutant dans le téléphone, l'autre

au sein de la SIM Parmi ces fonctionnalités, nous pouvons signaler la possibilité donnée à

la SIM d'être « proactif », c'est-à-dire d'initialiser des actions sur le téléphone sous forme

de scripts ou d'appliquettes (applets) JavaCard (affichage de texte, appel d'un numéro,

établir une connexion GPRS13 data, etc.) Ces applications SIM réalisent au besoin des services de sécurité en s'appuyant sur des clés et algorithmes de la SIM

La spécification WIM14 [53] du OMA forum [38], anciennement WAP forum, définit, pour

sa part, une application au sein de la SIM avec une API dédiée à la sécurité dans les protocoles WAP La SIM peut ainsi être utilisée pour stocker des certificats et des clés de type RSA, réaliser les opérations de signature et d'authentification pour les services de sécurité de la couche transport (protocoles WTLS et TLS) Elle fournit également des

La spécification JSR17 177 [27] étend cette approche aux fonctions de sécurité de la SIM Plus précisément, la spécification JSR 177 définit un ensemble d'APIs pour accéder par RMI aux fonctions de sécurité implémentées dans la SIM qui est alors vue comme un outil

de sécurité J2ME

En résumé, l'ensemble de ces spécifications concourt au développement d'application dont bien souvent la partie principale s'exécute dans le téléphone portable, les services de sécurité étant exécutés dans la SIM Nous pensons que cette fonctionnalité n'est, à l'heure actuelle, pas assez exploitée, alors qu'elle devrait être le principe de base de tout mécanisme de sécurité présent dans le téléphone portable

3.4 Communication par GSM

La fonction initiale des téléphones portables est évidement l'émission et la réception de voix et de données En termes de sécurité, l'émission et la réception d'appels posent les problèmes d'accès au réseau de téléphone portable, de sécurité des communications, et pour l'opérateur, d'imputation des communications (lorsqu'il ne s'agit pas de communications prépayées)

Une session de communication par GSM passe par trois phases : l'authentification, la génération de clés de session et le chiffrement de données échangés Au niveau de l'accès

au réseau, l'authentification est basée sur la SIM et est réalisée de la manière suivante

Chaque SIM contient une clé secrète K f , le « réseau » retrouvant K f à l'aide d'une clé mère

K m et des données d'identification de la SIM (ex.: numéro de série, etc.) Le « réseau »

envoie un challenge RAND (un nombre aléatoire de 128 bits) A la réception de RAND, la SIM calcule la réponse SRES sur 32 bits obtenue en appliquant un algorithme cryptographique appelé A 3 (implémenté dans la SIM) au challenge RAND, avec la clé secrète K f Le réseau vérifie que la réponse SRES envoyée par la SIM correspond bien au

challenge précédemment envoyé; l'authentification de la SIM est valide si tel est le cas, sinon l'authentification a échoué

Figure 5 La communication par GSM

La sécurité des communications est obtenue en chiffrant les échanges entre le téléphone

portable et le réseau Ce chiffrement nécessite la génération d'une clé de session K s de 64 bits Cette clé obtenue par la deuxième phase (génération de clés) en appliquant un

algorithme appelé A 8 (implémenté dans la SIM) au challenge précédant RAND, avec une clé K f Une fois la clé de session générée par la SIM, elle est fournie au téléphone portable qui va chiffrer les communications (troisième phase) à l'aide de l'algorithme

cryptographique A 5

Le schéma global est résumé sur la Figure 5 Nous voyons que la sécurité de l'authentification et de la génération de la clé de session repose exclusivement sur le secret

de la clé K f Notons que la clé K f est stockée dans la SIM et n'est jamais communiquée au

téléphone (en particulier, les algorithmes A 3 et A 8 sont exécutés dans la SIM) Ceci est rendu possible dans la mesure ó la SIM est propriété exclusive de l opérateur : l'opérateur

peut s'assurer que toute application contenue dans la SIM préserve la sécurité de K f

En reposant sur la clé de session K s, le chiffrement des communications est à la charge du téléphone pour des raisons de performance La sécurité des communications revient à

protéger le secret de la clé K s Si le téléphone est compromis, un attaquant peut avoir accès

à cette clé et déchiffrer l'ensemble des communications Au niveau des contraintes de performance, ce risque est inévitable Les développeurs doivent prendre en compte ce risque lors du développement des applications, et, en particulier, contrơler l'utilisation des fonctionnalités sensibles afin d'empêcher un attaquant d'y accéder

En pratique, les algorithmes A 3 et A 8 sont généralement combinés En particulier, l'ETSI a proposé les algorithmes (secrets) COMP 128 (cassé en avril 1998), COMP 128-2, et plus récemment, COMP 128-3 pour réaliser l'authentification et la génération de la clé de session [10] Notons que les opérateurs n'utilisent pas l'un de ces algorithmes, mais une version propriétaire

Concernant l'algorithme de chiffrement A 5 , il est public Les version A 5 /2 (chiffrement faible) et A 5 /1 ont fait l'objet d'attaques respectivement en aỏt et en décembre 1999 En revanche, il n'existe pas, à notre connaissance, d'attaque sur la version A 5 /3 de l'algorithme

Intéressons-nous maintenant brièvement à l'imputation des communications Le schéma adopté par les opérateurs repose sur le fait que la SIM est attribuée à un utilisateur donné Toute communication est alors imputée à l'utilisateur porteur de la SIM authentifiée, ce dernier étant supposé s'être identifié via le code PIN Notons cependant qu'il est donné à l'utilisateur le moyen de désactiver la vérification du PIN Si l'utilisateur choisit cette option, en cas de vol, toute communication sera imputée sur son abonnement, et ce malgré l'absence d'authentification du porteur de la SIM

Chapitre 4: Système d exploitation Symbian

L'OS Symbian a été précédemment connu comme EPOC Le système d'exploitation EPOC

a été au commencement développé par Psion pour leurs propres dispositifs de PDA Cependant, Symbian a été fondé pour prendre soin du développement ultérieur d'EPOC Symbian est possédé par Ericsson, Motorola, Nokia, Panasonic et Psion Récemment le nom du système d'exploitation a été changé en OS Symbian

Figure 6 L'architecture de l'OS Symbian v8.0

L'OS Symbian est basé sur une architecture de micro noyau multitâche Les services de système tels que la téléphonie, le middleware de réseau et les moteurs d'application fonctionnent dans leurs propres processus L'OS a été conçu dans l'esprit des dispositifs mobiles, en utilisant des techniques avancées d'orientée objet, menant à une architecture flexible basée sur les composants

4.1 Sécurité au niveau de l OS

4.1.1 Contrôle d'accès

Le contrôle d'accès est implémenté par la demande d'un mot de passe avant d'accorder l'accès au dispositif Ceci assure la confidentialité et l'intégrité à un certain niveau, parce qu'aucune donnée ne peut être lues (confidentialité) ou être écrites (intégrité), sans identifier l'utilisateur et autoriser l'accès au dispositif Cependant, c'est seulement une approche limitée parce qu'après l'identification, l'utilisateur peut accéder à toutes les

données sur le dispositif Et plus important, toutes les applications lancées par l'utilisateur peuvent accéder à toutes les données

4.1.2 Cryptographie et chiffrement

Dans l'OS Symbian, le chiffrement et le déchiffrement des fichiers ne sont pas une partie

du système d'exploitation par défaut Cependant, il y a un module de cryptographie disponible pour des développeurs d'application pour permettre l'implémentation facile des capacités cryptographiques dans leur logiciel Le module de cryptographie de l'OS Symbian se compose des chiffrements symétriques et asymétriques aussi bien que les fonctions de hachage et le générateur de nombre aléatoire [40] Néanmoins, tous les produits ne sont pas délivrés avec le support cryptographique à l'exception de ceux pour les

partenaires du programme « Symbian Platinum Partner »

4.1.3 Système de fichiers

Il y a différents systèmes de fichiers utilisés dans des dispositifs Symbian Par exemple, les fichiers stockés dans la mémoire flash interne et ceux stockés sur la carte de mémoire

démontable Une entité appelée File Server est construite sur eux Elle fournit une interface

uniforme pour accéder à tous les fichiers, et aussi le contrôle de tout l'accès au fichier Néanmoins, il n'y a aucune gestion de permission basée sur l'application initialisant la demande d'accès de fichier dans le serveur de fichiers

Normalement, sur un dispositif cible, le Z: représente la ROM et le C: est une partie de l'espace mémoire disponible de RAM L'OS Symbian est installé dans la ROM, des programmes et les fichiers de tiers sont typiquement installés sur le C:

Les smartphones peuvent embarquer des machines plus « complètes », c'est-à-dire mettant

à disposition du développeur une API bien plus riche A ce sujet, il faut préciser que si l'API de base a été standardisée, de nombreuses extensions ont été proposées par les constructeurs pour supporter des fonctions exotiques telles que clapets, vibreurs, molettes,

et autres Ceci explique pourquoi les applications (et en particulier les jeux) Java les plus élaborées sont spécifiques à une famille de téléphones donnée, malgré l'apparente universalité de ce langage

Les quatre niveaux d'API Java potentiellement disponibles sur les téléphones sont à l'heure actuelle :

CLDC (Connection Limited Devices) v1.0 et v1.1 : la base minimale des API

disponibles

MIDP (Mobile Information Device Profile) v1.0 et v2.0 : une nouvelle base minimale

d'API, sur-ensemble du précédent Ce standard est aujourd'hui largement implémenté dans les téléphones du commerce et on trouve peu d'équipements compatibles CLDC uniquement Les applications compatibles MIDP sont appelées « MIDlets »

JSR (Java Specification Requests) : des extensions d'API normalisées ou en cours de

normalisation Par exemple : JSR 82 (Java API for BlueTooth), JSR 135 (Mobile Media API - MMAPI), etc

Des API spécifiques : dans ce domaine tout est permis

En général, la programmation en Java dans Symbian est comme dans les autres OSs, sauf les cas particuliers suivants [50]:

18

KVM: Kilobyte Virtual Machine

sans support pour les types de données en point flottant (float et double)

sans support pour le Java Native Interface (JNI)

sans support pour le chargeur de classes (class loader) défini par l'utilisateur

sans réflexion

sans support pour les groupes de processus léger (thread groups) et les processus légers démons (daemon threads)

sans support pour le mécanisme de finalization des instances de classe

sans référence fiable (weak reference)

limitations de traitement des exceptions

4.2.2 C++

L'OS Symbian est écrit en C++, il est donc justement normal de développer des applications également en C++ Ceci fournit au développeurs la flexibilité Cependant, cette flexibilité amène avec lui la complexité et dans certain cas, il peut être plus approprié

de développer une application en Java, qui est aussi bien supportée sur d'autres dispositifs utilisant l'OS Symbian

Le développement des applications écrites en C++ demande un environnement de

développement standard (de type gcc, Visual Studio, MetroWerks Code Warrior, Borland C++ Builder X ou autre) et le SDK19 Symbian qui est disponible gratuitement sur son site [48]

Les deux principaux constructeurs utilisant l'OS Symbian fournissent également des versions « adaptées » du SDK, qui gèrent les spécificités de leurs téléphones En effet, le système Symbian est fortement « modulable », chaque sous-système pouvant être réécrit [47] Parmi les SDK « adaptés » disponible actuellement, on trouve UIQ pour Sony Ericsson P800/900, Motorola A920 et les Nokia 60, 80 et 90

A cause des ressources limitées des dispositifs mobiles, les développeurs doivent utiliser quelques particularités qui ne sont pas communes avec les autres systèmes :

19

SDK: Software Development Kit

Figure 7 Le constructeur de deux phases (droit) dans le Symbian et le constructeur

standard (gauche)

4.3 Sécurité des applications du téléphone portable

Comme mentionné dans la section 2.1, les exigences de sécurité changent selon les perspectives que nous considérons Intéressons-nous dans un premier temps aux OS propriétaires fermés, c'est-à-dire ne supportant pas le téléchargement d'applications Du point de vue d'un fournisseur de services, cela signifie soit que son service s'appuie exclusivement sur des services présents par défaut dans les téléphones portables, soit qu'il négocie un accord pour inclure le code nécessaire dans les téléphones portables

Dans le premier cas, le constructeur du téléphone portable pourrait (à la demande de l'opérateur) s'assurer, éventuellement via une évaluation au sens Critères Communs

(Common Criteria20), que les services présents dans le téléphone portable ne puissent être détournés à des fins malveillantes Dans le second cas, l'accord devrait exiger l'évaluation

20

Les Critères Communs (Common Criteria) est une norme internationale qui définit des concepts et des

principes généraux pour l évaluation de sécurité et représente le modèle général d évaluation Il représente des bases pour exprimer des objectifs de sécurité, pour choisir et définir des exigences de sécurité, et pour écrire des spécifications de haut niveau pour les produits et les systèmes Ce standard se trouve sur le site http://www.commoncriteria.org

du code avant installation, afin de vérifier qu'il ne contient ni porte dérobée (backdoor), ni

bogue résiduel Dans les deux cas, le fournisseur de services ne serait pas en mesure d'introduire un programme malveillant dans le téléphone portable

Du point de vue de l'utilisateur, les OS propriétaires fermés rendent impossible le téléchargement de nouvelles applications En d'autres termes, il n'est pas possible, pour l'utilisateur, de télécharger un programme malveillant en vue d'attaque le téléphone portable et/ou les services

Au contraire des OS fermés, les OS (propriétaires) ouverts supportent au minimum le téléchargement de services ou de contenu via des applications écrites en Java, mais aussi le téléchargement d'application (généralement, en C++) exécutées par l'OS, et dans certains cas, la mise à jour de l'OS lui-même Dans ce contexte, le risque est grand de voir l'utilisateur installer, volontairement ou non, une application malveillante Pour faire face à

ce problème, les constructeurs de téléphones portables proposent des solutions complémentaires dont les objectifs sont de garantir la sécurité tout au long du cycle de vie des applications Nous présentons les solutions actuellement déployées dans les différentes phases d'une application (le développement, le téléchargement, l'installation, l'exécution et l'exploitation), ainsi que leur limites

4.3.1 Développement

Les problèmes de sécurité rencontrés dans la phase de développement sont les mêmes que ceux rencontrés dans le monde PC Les applications sont généralement écrites en Java ou C++ (voir section 4.2) en s'appuyant en grande partie sur les APIs standards, mais les développeurs utilisent aussi des APIs propriétaires afin d'optimiser le code, ou d'accéder à des fonctions spécifiques Des telles pratiques augmentent les risques liés à la présence de failles de sécurité, ces APIs « contournant » les mécanismes de sécurité de l'OS De plus, l'existence de bogues résiduels ou de portes dérobées peut être exploités pour attaquer le téléphone portable

Cependant, il existe une différence fondamentale dans le cadre des téléphones portables, à savoir que le code des applications est globalement moins important, rendant ainsi plus efficaces les techniques d'audit de code, ou encore possible l'évaluation, au sens Critères Communs

Nous ne nous étendrons pas davantage sur cet aspect, considérant que les mécanismes de sécurité mis en place dans les phases suivantes ont pour objectifs de précisément de se protéger contre cela et au point de vue des attaquants, ils utilisent toutes les failles de sécurité pour atteindre leurs objectifs

4.3.2 Téléchargement

La phase de téléchargement correspond au chargement d'une application dans le téléphone portable à partir d'un serveur Notons que le téléchargement peut être à l'initiative de l'opérateur (par exemple, pour une mise à jour logicielle), du fournisseur de services (par exemple, lors de l'accès à un portail), ou bien de l'utilisateur (par exemple, le chargement

de nouveaux jeux payants pour la N-Gage) Les applications peuvent également être chargées à partir d'un poste de travail ou d'un autre téléphone portable et dans ce cas, le problème revient à assurer la sécurité dans la phase de l'installation (voir section suivante)

Dans cette phase, les problèmes de sécurité se posent au niveau de l'accès au service et du transfert de l'application Concernant l'accès au service, les mécanismes à mettre en place sont cơté serveur (contrơle d'accès par mot de passe, gestion des abonnements, etc.) et ne rentrent pas dans le carde de ce rapport Au niveau transfert, il s'agit de garantir la confidentialité et/ou l'intégrité des échanges, afin d'empêcher un attaquant d'accéder au code et aux données de l'application, ou de modifier ce code et d'y introduire une faille

A l'image de ce qui fait sur Internet, l'utilisation de TLS/SSL pour sécuriser le niveau transfert nous semble une bonne solution Ainsi, le WAP Forum a spécifié WTLS [54] qui n'est autre que l'implémentation de TLS dans WAP Bien que généralement implémentée dans les téléphones portables, signalons cependant qu'une telle solution n'est pas souvent utilisée Et lorsque c'est le cas, il est rare que l'ensemble des problèmes y afférant soit pris

en compte En particulier, la certification des clés publiques (pour empêcher une attaque de

type man in the middle) n'est généralement pas mise en oeuvre, ou mal, ne tenant pas

compte du fait que la notion de certification est encore moins compréhensible/intuitive pour un utilisateur mobile que pour un utilisateur PC Dans la mesure ó la possibilité de désactiver la sécurité au niveau transport est souvent donnée à l'utilisateur, l'absence de compréhension risque fort de se traduire par le choix de cette option

En résumé, les solutions pour sécuriser le niveau transport, bien qu'existantes, ne sont généralement pas ou mal mises en oeuvre Les opérateurs préfèrent considérer que la sécurité au niveau transport est assurée par la sécurité « physique » du coeur de réseau, oubliant que ce dernier est de plus en plus souvent connecté à Internet

4.3.3 Installation

Une fois l'application téléchargée, et avant son installation, il s'agit de vérifier qu'elle est saine, en particulier, qu'elle ne contient pas de virus et autres programmes malveillants Ceci peut être réalisé soit par des antivirus, soit par des techniques de certification de code

La première n'est, à l'heure actuelle, que rarement utilisée, mais le tapage qu'a alimenté le ver Cabir [3] nous laisse à penser que les distributeurs d'antivirus vont rapidement se lancer

dans la course F-Secure a récemment proposé Mobile Anti-virus pour les séries 60 de

Nokia [18] qui recherche automatiquement tous les fichiers lorsqu'ils sont enregistrés,

copiés, téléchargées, synchronisés ou modifiés Le Symantec Client Security [44] pour le

Nokia 9500 Communicator et Nokia 9300 est une protection par des technologies d'antivirus et de pare-feu intégrés

Notons que les antivirus s'appuient sur la « signature virale » propre à chaque virus pour les détecter Il s'agit de la méthode de « recherche de signature », la plus ancienne méthode utilisée par les antivirus Cette méthode n'est fiable que si l'antivirus possède une base virale à jour, c'est-à-dire comportant les signatures de tous les virus connus Toutefois cette méthode ne permet pas la détection des virus n'ayant pas encore été répertoriés par les éditeurs d'antivirus De plus, les programmeurs de virus les ont désormais dotés de capacités de camouflage, de manière à rendre leur signature difficile à détecter, voire indétectable; il s'agit de "virus polymorphes"

Certains antivirus utilisent un contrôleur d'intégrité pour vérifier si les fichiers ont été modifiés Ainsi le contrôleur d'intégrité construit une base de données contenant des informations sur les fichiers exécutables du système (date de modification, taille, et éventuellement une somme de contrôle) Ainsi, lorsqu'un fichier exécutable change de caractéristiques, l'antivirus prévient l'utilisateur

Le problème revient à s'assurer la sécurité des fichiers de définition de virus (signature virale) dans le premier cas et de base de données dans le deuxième cas D'autre part, il faut s'assurer également que l'antivirus n'est pas infecté par un virus dans tous deux cas et la mise à jour automatique, sécurisée des signatures virales dans la méthode de recherche de signature

L'utilisation d'antivirus est une protection passive, nous pouvons détecter les virus seulement lorsque nous avons le fichier de définition de virus D'autre part, cette approche

ne fonctionne correctement que si nous avons déjà une séparation forte entre un domaine

de confiance ó faire tourner l'antivirus et un domaine « non sécurisé » ó exécuter les applications à surveiller

Une limite importante, que personne n'a été en mesure de contourner jusqu'à présent, est la phase d'installation de l'application « hostile » Sur le Nokia N-Gage par exemple, l'exécution directe d'un « APP » est interdite « pour raison de sécurité » On peut légitimement se demander si le filtrage est effectué sur l'extension ou sur le contenu

Intéressons-nous plus particulièrement à la certification de code Le principe fondamental est de signer numériquement le code afin de s'assurer de son authenticité Actuellement,

deux approches se distinguent : Symbian Signed [49] et MIDP [36]

Suivant l'approche Symbian Signed, toute application téléchargée doit être signée De manière générale, l'installation d'un « SIS » (package d'installation) nécessite au moins deux confirmations de l'utilisateur, sauf si celle-ci a été signé par une autorité reconnue par

le téléphone (par exemple, sur le Sony Ericsson P900, les autorités pré-installées sont :

Baltimore, Entrust, GTE CyberTrust, GlobalSign, RSA Data, Thawte, Verisign et évidement Sony Ericsson et Symbian) Dans le cas de l'absence de signature valide,

l'utilisateur est prévenu, et la possibilité de continuer l'installation de l'application lui est

donnée (message « Unable to verify Continue anyway? » pour Cabir), et ainsi,

d'outrepasser le mécanisme de sécurité En faisant précéder le téléchargement par un

« faux » SMS prévenant de la mise à jour nécessaire du système, il est fort à parier que bon nombre d'utilisateurs continueront l'installation malgré le message de mise en garde

Une fois installées, aucune distinction n'est fait entre les applications signées et les autres :

il en résulte que tout programme malveillant ainsi installé a accès exactement aux mêmes fonctionnalités qu'une application légitime Nous pensons donc que la solution retenue par Symbian Signed n'est pas satisfaisante

Intéressons-nous maintenant à la solution MIDP pour environnement Java J2ME Le principe de base est le même que précédemment, à savoir la signature numérique du code (c'est-à-dire des fichiers jar) à base de l'infrastructure à clé publique Pourtant, la signature associe à ce principe la notion de domaine de sécurité : un domaine de sécurité définit un niveau de certification qui est identifié par une ou plusieurs clés de certification

Tout code signé avec une clé de certification K c est associé au domaine de sécurité identifié

par K c Tout code non signé (ou avec une signature invalide) est associé à un domaine

spécifique (Untrusted Domain) Il est ainsi possible de distinguer les applications présentes

dans le téléphone portable: celles signées par l'opérateur, celles signées par un fournisseur

de service connu, ou encore celles non signées ou avec une signature invalide

Signalons enfin, mais nous n'étudierons pas ce problème dans ce rapport, qu'une attention particulière doit être apportée aux applications soumises à droits pour lesquelles il ne suffit pas de vérifier que l'application est saine, mais il faut également vérifier que l'utilisateur a acquis les droits l'autorisant à y accéder et sécuriser son installation

4.3.4 Exécution

Lorsqu'une application est installée, elle est « exécutable » A ce niveau, il peut sembler inutile de mettre en place des mécanismes de sécurité, dans la mesure ó, pour être installée, l'application a dû être jugée saine Néanmoins, une application saine ne veut pas dire qu'elle ne contient pas de portes dérobées ou de bogues résiduels En outre, le pire ennemi de la sécurité est l'utilisateur à qui on donne encore une fois la possibilité d'outrepasser les mécanismes de sécurité, par exemple en lui demandant de confirmer une

action jugée non sûre (message « Unable to verify Continue anyway? » pour Cabir)

L'API Symbian est extrêmement riche D'autre part, les applications Symbian sont compilées directement en code assembleur ARM, et ont des accès illimités à la plate-forme Une application native Symbian peut virtuellement effectuer n'importe quelle opération sur

le téléphone, à cause de l'absence de modèle de sécurité (pas de notion d'utilisateur, de liste

de contrôle d'accès aux fichiers, etc.)

De plus, une grande partie de l'API se trouve dans des librairies et non dans le noyau, ce qui permet de contourner plus facilement les éventuels mécanismes de sécurité Par exemple, pour envoyer un SMS, et en supposant qu'une confirmation utilisateur soit imposée par l'API, il suffirait d'appeler directement la fonction interne d'envoi de SMS plutôt que de passer par l'API standard pour contourner cette sécurité

Il est donc préférable de mettre en place des mécanismes de sécurité afin de contrôler les actions des applications lors de l'exécution De manière générale, les mécanismes de sécurité à l'exécution dépendent fortement des mécanismes utilisés lors de l'installation

Ainsi, comme nous avons signalé précédemment, la solution Symbian Signed ne permet pas

de distinguer les applications signées de celles non signées Il n'est donc pas possible de contrôler à l'exécution les actions des applications non signées, qui peuvent ainsi accéder aux mêmes fonctionnalités que les applications non signées

Par contre, la notion de domaine de sécurité proposée dans MIDP est utile pour mettre en oeuvre des solutions de contrôle à l'exécution Dans la machine virtuelle Java, les principes

de base consistent d'une part à vérifier que l'exécution est conforme au langage utilisé, et d'autre part, à contrôler l'accès aux ressources et aux données Le premier point est couvert, dans le cas de MIDP, par l'utilisation obligatoire d'un vérificateur de code d octet21

(bytecode) Pour le second point, à chaque domaine de sécurité est associé un ensemble de

droits d'accès, ou privilèges, portant sur les données et les ressources du téléphone portable Pour une application donnée, son domaine de sécurité définit donc l'ensemble des ressources et des données auxquelles elle est autorisée à accéder En particulier, en définissant des droits très restreints pour les applications non signées ou à signature invalide, il est possible de les confiner dans un espace ne leur permettant pas d'accéder aux informations et services sensibles

Bien entendu, lorsqu'ils sont mise en oeuvre, ces mécanismes de sécurité doivent être exempts de failles de sécurité Cela signifie qu'ils doivent faire l'objet d'un audit poussé, ou

21

Voir l'annexe pour une introduction détaillée sur le problème de vérification de code d octet Java

d'une évaluation au sens Critères Communs En particulier, la machine virtuelle Java doit être vérifié en vue d'éliminer les éventuels bogues de programmation A ce niveau, il faut signaler que les risques liés à l'exécution d'un MIDlet « hostile » sont limités par la pauvreté de l'API CLDC/MIDP Il existe des erreurs d'implémentation dans le modèle de sécurité de Java (risque accru compte tenu des compromis imposés par la faible mémoire et

la faible puissance de calcul des téléphones portables), par exemple, l'attaque sur le Siemens S55 [41] permettant d'envoyer un SMS avant l'affichage de la fenêtre de

confirmation De plus, lors de la récente conférence Hack in the Box en Malaisie [23], des

failles de sécurité dans J2ME ont été mises à jour, failles qu'un attaquant peut exploiter pour installer un programme malveillant

A l'heure actuelle, il existe peu d'attaques publiées démontrant des failles dans les MIDlet Java, mais il est probable que de nombreux chercheurs travaillent sur le sujet

4.3.5 Exploitation

Certaines applications fournissent des services de sécurité que d'autres applications utilisent, à l'image d'applications fournissant l'API JSR 177, ou bien WMLScript et ECMAScript pour WAP [53] Ces applications deviennent donc aussi sensibles que le code natif, et requièrent donc le même niveau d'exigence en termes de sécurité Concrètement, dans le cadre de MIDP, cela signifie que ces applications seront associées au même domaine de sécurité que le domaine du code natif

La sécurité des applications du téléphone portable est moins bien gérée Ceci est expliqué par plusieurs raisons : la disparité dans les architectures matérielles, la disparité des architectures d'OS et particulièrement des services de sécurité disponible dans chaque OS,

la diversité des standards L'absence d'attaques à grande échelle n'incite pas les acteurs à prendre les mesures nécessaires Malheureusement, encore une fois, il faudra attendre une telle attaque pour qu'enfin la sécurité soit vue comme un argument commercial, et donc prise en compte

La solution la plus simple est d'empêcher l'exécution d applications malicieuses sur le téléphone portable D'ailleurs, c'est ce que font la plupart des opérateurs : sur une téléphone portable standard, nous pouvons installer que des applications Java qui sont très bien contrôlées (par le modèle de bac à sable de KVM)

Dans le cas d un vrai smartphone, la seule solution est de sécuriser une partie du système et

de s'assurer que le monde non sécurisé ne peut pas agir sur le monde sécurisé C'est assez difficile et aucun téléphone actuel n'utilise cette approche En particulier, il faut s'assurer que les applications sécurisées peuvent acquérir un contrôle exclusif sur l'écran, le clavier

et les autres interfaces quand elles doivent interagir avec l'utilisateur

En d autres termes, les contre-mesures doivent régler les accès des divers composants logiciels (système d'exploitation, code téléchargé, etc.) à différentes parties des systèmes (registre, régions de mémoire, co-processeurs de sécurité, etc.) pendant différentes étapes

de l'exécution (processus de démarrage, exécution normale, mode d'interruption, etc.) par une combinaison des changements de matériel et de logiciel Puisque les contre-mesures efficaces doivent permettre au système de fournir des garanties au sujet de la sécurité immédiatement après le commencement d'opération du système, la plupart des mesures

définissent des notions de la confiance ou des frontières de confiance (également nommés des périmètres de sécurité) à travers des diverses ressources de matériel et de logiciel Ceci

permet au système de détecter des infractions à des frontières de confiance (telles que des accès illégaux aux régions de mémoire) et d'imposer des mécanismes de rétablissement (tels que la mise à 0 des registres du processeur et des régions de mémoire) Ainsi, une frontière de confiance fournit une base naturelle et commode pour le système pour prendre des décisions judicieuses ou de compromis au sujet de sécurité

Pour atteindre ce but, il est obligatoire d utiliser l approche en couche en partant du

matériel : c est l approche nommée l informatique de confiance (Trusted Computing Base

ou TCB) C est en fait un principe récursif, si la couche n-1 est sécurisée et si la couche n-1

a plus de pouvoir que la couche n, alors la couche n-1 peut sécuriser la couche n Ainsi, on

sécurise l unité central, puis le BIOS, puis la mémoire vive, puis la mémoire morte, puis le noyau de l'OS et puis certaines applications de l'OS Cette approche se base sur deux suppositions suivantes :

Supposition 1 : l'utilisation des composants de matériel additionnels augmentent la sécurité considérablement Si on stocke un secret, tel qu'une clé, sur un périphérique

de stockage, il y a alors de bonnes chances que quelqu'un d'autre puisse le lire Plusieurs outils sont disponibles pour détecter les empreintes de clé sur le stockage

ou en RAM La meilleure manière pour éviter d'exposer la clé à tels l'attaque est de stocker la clé dans un endroit séparé, auquel aucun logiciel malveillant ne peut accéder Ceci ne résout pas le problème que la clé doit être transférée à la mémoire vive (RAM) pour être traitée par l'unité centrale La solution est d'avoir un processeur séparé à l'endroit ó la clé est stockée La clé sera traitée là, et il ne la laissera jamais C'est sécurisé Ce genre de stockage et d'unité de traitement dédié est implémenté en tant que carte intelligente, si un composant de matériel

démontable est exigé, ou comme un module de plate-forme sécurisée (Trusted

le système d'exploitation lui-même ou une application, respecte cet attribut, le mécanisme de contrôle d'accès est sécurisé Si autre logiciel ou système d'exploitation est utilisé pour accéder aux données, alors le mécanisme de contrôle d'accès n'assure plus la protection Les améliorations de la programmation système

de contrôle d'accès n'améliore pas le niveau de la sécurité : il y a un besoin de changer la technologie La solution à cette tâche de sécurité est le chiffrement Le chiffrement peut être considéré comme le niveau ultime de la protection de données

Le chiffrage ne protège pas contre détruire le contenu en effaçant un fichier C'est toujours à la portée du contrôle d'accès Nous avons vu que le contenu est bien protégé contre la lecture, car il est chiffré Ce que nous devons protéger avec le niveau ultime de la sécurité sont les clés utilisées pour le chiffrement et le

déchiffrement Ici nous renvoyons à la supposition 1, et nous pouvons alors

conclure : des clés de chiffrement doivent être stockées et traitées dans le matériel dédié tel que les cartes intelligentes ou le TPM

5.1 Renforcer la sécurité des téléphones portables

A partir de la SIM, en basant sur le principe de l informatique de confiance, nous proposons une approche pour améliorer la sécurité des téléphones portables De notre point

de vue, le renforcement de la sécurité des téléphones portables passe par la prise en compte des trois aspects qui sont expliqués dans les trois sous-sections ci-dessous Nous discutons également les solutions et la tendance actuelles qui peuvent être appliquées pour chaque aspect proposé

fondamentaux de tous les services de sécurité D autre part, la supposition 1 notée en

dessus montre que il faut préserver ces secrets et les traiter dans un endroit séparé

L utilisation des composants dédiés passe par deux points suivants :

la carte SIM (ou autre carte) pour tous les services d'authentification, de signature et

de gestion de clés

les composants du téléphone portable pour les opérations de cryptographie nécessitant de la performance (chiffrement symétrique par cryptoprocesseurs), pour

le stockage des données sensibles et volumineuse, ainsi que pour la protection du

code natif (en particulier, le chargeur de démarrage (boot loader) doit être sécurisé

par utilisation de mémoire morte)

L'usage d'un module de co-processeur sécurisé séparé, qui est dédié au traitement de toutes les informations sensibles dans le système est trouvé dans [55][24][25] Chaque information qui est envoyée du co-processeur sécurisé est chiffrée

Beaucoup d'architectures des systèmes embarqués se fondent sur l'identification et la maintenance des zones choisies de son sous-système de mémoire (volatile ou non-volatile, hors puce ou sur puce) en tant que des endroits de stockage sécurisé L'isolement physique est souvent utilisé pour limiter l'accès des zones de mémoire sécurisée aux composants de confiance du système Quand ce n'est pas possible, un mécanisme de protection de

mémoire adopté dans beaucoup de SOCs (System On Chip) embarqués comporte

l'utilisation de matériel surveillant le bus, qui peut distinguer l'accès légal et illégal à ces endroits Par exemple, la solution de sécurité de CrypoCell de Discretix [12] comporte BusWatcher, qui exécute cette fonction L'assurance de l'intimité et de l'intégrité dans la hiérarchie de mémoire est le centre de [43], qui utilise une gestion sécurisée de contexte de matériel, de nouvelles instructions, et des unités de hachages et de chiffrage dans le

processeur Le travail dans [32] décrit un modèle d'exécution dans la mémoire (eXecutable Only Memory} - XOM), et des techniques architecturales pour le mettre en oeuvre, en