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


2

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é.


3

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


4
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


5

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.


6

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.


7

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


8

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.


9
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,
), 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.


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 chaîne
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 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.


11
ê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.


12
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.


13
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



14
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 coû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.


15

Attaques physiques et side-channel
Invasives
Non-invasives
Temps de calcul

Attaques logiques
Attaques logicielles
Faiblesses

Analyse de
consommation
SPA
Micro-probing
Rétro-ingénierie

DPA
Electromagnétique

Virus

Chevaux de Troie

Faiblesses de
crypto et de
protocole

Analyse
SEMA
DEMA
Injection de faute
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



16
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.


17

Chapitre 3: Téléphones portables
3.1 Architecture
L'architecture matérielle du téléphone portable repose généralement sur un processeur de
type RISC3 de la famille ARM4 dont la capacité de traitement varie de quelques dizaines de

MHz à plus de 100 MHz, la puissance du système étant intimement liée aux services
proposés: Vidéo, Audio, Jeux, animation 2D/3D. On trouvera différentes mémoires autour
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.

3

RISC: Reduced Instruction Set Computer.
ARM: Advanced RISC Machine.
5
RAM: Random Access Memory.
6
ROM: Read Only Memory.
7
OTP: One Time Programmable.
4


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.


19
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.

9

SIM: Subscriber Identity Module.
PIN: Personal Identification Number.
11
CISC: Complex Instruction Set Computer.
12
EEPROM: Electrically Erasable Programmable Read-Only Memory.
10


20
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

13
14

GPRS: General Packet Radio Service.
WIM: WAP Identity Module.


21
services de sécurité applicative type WMLscript et ECMAscript permettant entre autres
d'utiliser une signature dans la carte depuis une page WAP.

Comme nous l'avons signalé précédemment, les SIM sont de plus en plus souvent de type
JavaCard. Dans le monde Java, une appliquette fait appel à une méthode d'une autre
Appliquette par RMI15. Au niveau des JavaCard, nous retrouvons un mécanisme équivalent
(JCRMI16) pour accéder à une Appliquette de la carte par simple appel de méthode,

simplifiant encore l'interconnexion des applications du téléphone avec celles de la SIM.
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.

15

RMI: Remote Method Invocation.
JCRMI: JavaCard Remote Method Invocation.
17
JSR: Java Specification Requests.
16



22
Chaque SIM contient une clé secrète Kf, le « réseau » retrouvant Kf à l'aide d'une clé mère
Km 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é A3 (implémenté dans la SIM) au challenge RAND, avec la clé
secrète Kf. 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 Ks de 64
bits. Cette clé obtenue par la deuxième phase (génération de clés) en appliquant un
algorithme appelé A8 (implémenté dans la SIM) au challenge précédant RAND, avec une
clé Kf. 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 A5.


23
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é Kf. Notons que la clé Kf est stockée dans la SIM et n'est jamais communiquée au
téléphone (en particulier, les algorithmes A3 et A8 sont exécutés dans la SIM). Ceci est
rendu possible dans la mesure où 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 Kf.
En reposant sur la clé de session Ks, 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é Ks. 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 A3 et A8 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 A5, il est public. Les version A5/2 (chiffrement
faible) et A5/1 ont fait l'objet d'attaques respectivement en août et en décembre 1999. En
revanche, il n'existe pas, à notre connaissance, d'attaque sur la version A5/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.


24

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


25
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:.

4.1.4 Gestion de mémoire
L'OS Symbian souligne l'importance de la gestion sophistiquée de mémoire sur des
dispositifs avec des ressources restreintes. Le noyau du système d'exploitation fonctionne
en mode privilégié - l'espace d'adressage est protégé et donc un bogue d'une application ne
peut pas réécrire la pile ou le tas du noyau - et il est responsable d'attribuer la mémoire aux
applications fonctionnant dans le mode d'utilisateur non privilégié [17]. Chaque
programme peut accéder seulement à la mémoire assignée pour lui par le noyau. En
d'autres termes, des programmes sont protégés contre l'un l'autre en termes d'accès
mémoire. En outre, l'OS Symbian a les directives de programmation strictes au sujet de