La sécurité de MIDP

MISC n° 045 | septembre 2009 | Eric Vétillard
Creative Commons
  • Actuellement 0 sur 5 étoiles
0
Merci d'avoir participé !
Vous avez déjà noté cette page, vous ne pouvez la noter qu'une fois !
Votre note a été changée, merci de votre participation !
Sur les téléphones mobiles, le modèle de sécurité de Java est modifié pour tenir compte des spécificités des applications mobiles. Ce modèle présente des caractéristiques intéressantes, mais il pose des problèmes importants aux utilisateurs et aux développeurs.

1. La sécurité sur les mobiles

MIDP (Mobile Information Device Profile) est le dialecte de Java le plus répandu sur les téléphones mobiles. C'est une version limitée du langage, et surtout de l'API, qui est disponible des mobiles les plus simples jusqu'aux plus complexes. Un mobile n'est pas un PC, et la problématique de sécurité y est aussi extrêmement différente. Avant d’entrer dans les détails du modèle de sécurité de MIDP, commençons par mettre en évidence certaines de ces différences.

- L'opérateur. L'opérateur mobile est impliqué dans la gestion du téléphone mobile. Il subventionne son achat, il y appose souvent sa marque et il en contrôle au moins partiellement le contenu. Son rôle dépasse donc de très loin le rôle d'un FAI dans la gestion d'un PC. Avec l'iPhone, Apple a légèrement modifié le modèle, en prenant à son compte certaines des prérogatives de l'opérateur, mais sans grand impact sur l'utilisateur.

- Un système peu ouvert. La grande majorité des mobiles ont un système fermé, dans lequel il est impossible de charger des programmes natifs. Cela complique les possibilités d'attaques, car l'injection de code malicieux est rendu nettement plus complexe.

- Une fragmentation importante. Il existe un grand nombre de systèmes d'exploitation pour téléphones mobiles, avec des taux de pénétration relativement faibles pour chacun. Le système S40 de Nokia, équipant leurs téléphones de moyenne gamme, est le plus répandu, et il est présent sur 19% des téléphones. Cette fragmentation rend difficile la propagation de virus et autres contenus malicieux, qui ne fonctionnent souvent que sur un type précis de téléphone.

Ces trois caractéristiques suffisent à expliquer pourquoi la sécurité des mobiles est un problème spécifique. Intéressons-nous maintenant aux biens accessibles depuis un mobile qui peuvent présenter un intérêt pour un attaquant:

- L'accès au réseau. Un téléphone mobile permet de téléphoner et d'échanger des SMS, même surtaxés, même à l'étranger, et cette capacité peut être utilisée par un attaquant En sortant légèrement du champ de la sécurité, une application qui utilise le réseau de manière inconsidérée en condition de roaming, même sans intention de nuire, peut rapidement coûter très cher à l'abonné.

- Les informations personnelles. Ce terme générique couvre des informations très diverses, incluant en particulier un répertoire de contacts, un historique des communications, et sur certains appareils, une possibilité de localiser le mobile ou d'enregistrer les sons ambiants. On trouve aussi de plus en plus souvent sur les mobiles des informations professionnelles, parfois sensibles, et souvent mal protégées.

- Des contenus protégés. On trouve encore sur des téléphones mobiles des contenus protégés, allant des sonneries à la musique et aux émissions de télévision. Ces contenus sont souvent protégés par des mécanismes spécifiques.

Cette liste est relativement courte, ce qui est plutôt une bonne nouvelle, dans la mesure où ces biens ne sont pas très faciles à abuser. Même s’il est simple d'envoyer un SMS surtaxé depuis un téléphone mobile, collecter l'argent ainsi récolté est difficile, car ces numéros surtaxés sont gérés par les mêmes opérateurs mobiles, qui rechigneront à payer les sommes réclamées alors que leurs abonnés se plaignent d'abus. De par leur connectivité limitée, les téléphones mobiles ne font pas non plus de bons « zombies » à intégrer dans un botnet.

Par ailleurs, les informations personnelles et professionnelles sont plutôt intéressantes pour des attaques ciblées sur une personne ou un groupe de personnes. En dehors de la récolte d'informations sur des tiers (les contacts), ces informations sont difficiles à exploiter de manière systématique. Par exemple, il est facile de récolter les numéros de mobiles de tous les contacts d'une victime, mais chaque envoi faisant l'objet d'une confirmation ///à compléter///

Quant aux contenus protégés, ils sont généralement disponibles par ailleurs sur Internet. L'intérêt des opérateurs et des ayant-droits est donc souvent de s'assurer que l'abonné n'a accès qu'au contenu dûment payé, plus que d'en éviter la copie.

Bien entendu, ceci est un état de l'art mi-2009. Les technologies mobiles évoluent rapidement, et les téléphones mobiles sont de plus en plus de vrais ordinateurs. De même, la valeur des biens disponibles sur les mobiles pourrait augmenter rapidement, avec l'apparition de smartphones toujours plus puissants, et avec le déploiement de technologies comme NFC.

2. Le modèle de sécurité de MIDP2

Le modèle de sécurité de MIDP2 est défini dans la spécification elle-même et complété par une annexe spécifique, destinée aux implémentations sur téléphones mobiles GSM et 3G. De plus, le modèle est enrichi par les différentes extensions définies pour MIDP au sein du Java Community Process (JCP). Ce modèle est assez classique et nous allons simplement insister ici sur ses spécificités.

2.1 Les principes de base

Les applications MIDP sont distribuées dans des MIDlet suites, qui contiennent une ou plusieurs applications (midlets). Une MIDlet suite est considérée comme trusted quand elle a été signée, et que l'appareil de destination contient les clés nécessaires pour en vérifier la signature. Dans les autres cas, et en particulier quand l'application n'est pas signée, la MIDlet suite est considérée comme untrusted.

Dans ce dernier cas, les applications n'ont accès par défaut qu'à un ensemble limité de fonctions, comprenant principalement les API de gestion de l'affichage, de stockage persistent local, et l'utilisation de sons pré-enregistrés. De plus, après consultation de l'utilisateur, ces applications ont accès au réseau, exclusivement avec les protocoles HTTP et HTTPS. L'objectif de cet ensemble de fonctions limité est de faciliter le développement de jeux simples, qui peuvent être déployés sans contraintes.

Pour accéder aux autres fonctions du téléphone, les applications doivent être signées. Par exemple, une signature est requise pour utiliser des SMS au sein d'une application. On retrouve alors un système de gestion d'autorisations à base de permissions qui est relativement classique. Les éléments de base de ce système sont :

- Les permissions, qui sont ici des identifiants définis par une API ou une fonction, et utilisés pour interdire son utilisation sans autorisation. Ce sont des permissions nommées très simples. Par exemple, la permission javax.microedition.io.HttpConnection permet d'accéder au réseau par le protocole HTTP.

- Les domaines de protection, qui sont associés à un signataire, et qui définissent chacun un ensemble de permissions accordées de manière automatique (Allowed), ainsi qu'un ensemble de permissions accordées en fonction du choix de l'utilisateur (User). Dans ce dernier cas, les domaines de protection peuvent raffiner le type d'interaction requis avec l'utilisateur, avec trois choix possibles. Dans le mode blanket, l'utilisateur n'est interrogé qu'une fois pour la vie de l'application (typiquement, à la première opération nécessitant la permission). Dans le mode session, l'utilisateur doit confirmer son autorisation à chaque fois que l'application est lancée. Enfin, dans le mode oneshot, l'utilisateur doit confirmer son autorisation chaque fois que l'autorisation est requise.

Ensuite, les permissions disponibles varient selon les appareils. Bien entendu, un appareil ne supporte que les permissions correspondant à ses fonctionnalités. De plus, la configuration d'un appareil inclut également un ensemble de domaines de protection.

Enfin, chaque MIDlet suite doit lister explicitement dans son manifest les permissions dont ses applications ont besoin pour fonctionner. Ces permissions sont partagées en deux catégories. Les permissions qui sont critiques pour le fonctionnement de l'application sont listées dans l'attribut MIDlet-Permissions ; celles qui sont optionnelles ou non critiques (utilisées dans des fonctions non indispensables de l'application) sont listées dans l'attribut MIDlet-Permissions-Opt. Les applications sont également signées, ce qui permet d'associer chaque application à un domaine de protection.

Avec ces informations, complétées pendant l'exécution par les réponses de l'utilisateur, le système est capable d'autoriser ou non une opération demandée par une application. Cette décision est prise en deux temps, lors de l'installation de l'application, et pendant son exécution, quand une opération nécessite qu'une permission spécifique soit accordée.

Pendant l'installation, l'application est rejetée uniquement si elle requiert une permission critique qui n'est pas supportée ou qui n'est pas incluse dans le domaine de permission de l'application. Dans les autres cas, l'application est installée (même si une des permissions non critiques n'est pas supportée).

Pendant l'exécution, quand une méthode nécessitant une permission s'exécute, le système doit tout d'abord vérifier que la permission fait partie des permissions demandées par l'application. Ensuite, la permission est accordée si elle est Allowed dans le domaine de protection ou si elle est User dans le domaine de protection et que l'utilisateur l'a explicitement accordée. Si nécessaire, le système déclenche une interaction avec l'utilisateur, dont la fréquence dépend du type d'interaction requis. Enfin, si la permission ne peut pas être accordée, la méthode qui a déclenché la demande de permission doit déclencher une SecurityException.

Du point de vue du développeur, les contraintes posées à ce niveau sont assez simples, et peuvent être résumées en quelques règles :

- Toujours être prêt à recevoir une exception. Quand une permission est requise par une application, il est toujours conseillé de prendre en compte le déclenchement d'une SecurityException. Cela permet d'éviter à un utilisateur distrait qui a fait le mauvais choix dans un dialogue de voir l'application se terminer abruptement.

- Faire très attention avec les permissions optionnelles. Ces permissions ne sont pas gérées de manière standard. En particulier, il est possible de démarrer une application demandant une permission optionnelle qui n'est pas supportée sur le mobile. Toute tentative d'utiliser la fonction associée déclenchera une exception. De plus, les permissions optionnelles sont toujours difficiles à gérer.

- Ne pas demander de permissions dont on ne se sert pas. Cette dernière remarque paraît évidente, mais il est assez simple au cours d'un développement de laisser « traîner » une permission devenue inutile. Cela peut mener à un rejet de l'application.

Toutefois, la plupart des applications MIDP sont destinées à des téléphones mobiles, et il faut donc prendre en compte la politique de sécurité spécifique qui a été développée pour les téléphones GSM et 3G.

2.2 La politique de sécurité pour GSM et 3G

Le modèle de sécurité est raffiné dans la spécification par une annexe non normative destinée aux téléphones mobiles, qui a été très largement adoptée par les opérateurs.

La politique commence par mieux définir les domaines de protection. Chaque domaine de protection associe un certificat X.509 destiné à vérifier la signature de l'application et une politique de sécurité. Les domaines de protection sont groupés en quelques catégories.

Les domaines fabricant et opérateur sont des domaines privilégiés destinés respectivement aux applications signées par le fabricant et l'opérateur. Dans ces deux domaines, la politique de sécurité associée contient une liste de permissions Allowed, incluant généralement toutes les permissions disponibles.

Les domaines des tiers identifiés servent à associer chaque certificat « tiers » disponible à une liste de permissions. La politique de sécurité associée contient une liste de permissions User, souvent assez large, mais qui nécessiteront une validation par l'utilisateur avant d'être effectivement attribuée.

Le domaine des tiers non identifiés regroupe les applications non signées, qui n'ont accès qu'à un sous-ensemble limité de fonctions (suffisantes pour bien des applications). La politique de sécurité associée contient une liste de permissions User, généralement plus restrictive que pour les tiers identifiés.

Les différences entre ces catégories sont significatives. D'un côté, les applications associées à un domaine de protection opérateur ou fabricant se voient attribuer toutes les permissions possibles, sans aucune interaction avec l'utilisateur au niveau du système. A l'opposé, les applications des tiers, identifiés ou non, sont systématiquement soumises à des validations par les utilisateurs.

Les conséquences sur le développement sont importantes, avec des avantages et des inconvénients des deux côtés. Les applications du domaine opérateur n'auront pas à gérer des interruptions intempestives par des messages système. Par contre, il leur est fortement déconseillé d'inclure des confirmations similaires, au sein même de l'application (d'autant plus que l'opérateur signataire verra sa responsabilité engagée en cas de problème avec l'application). Les applications des domaines tiers devront gérer des interruptions parfois intempestives, mais elles n'auront par contre pas à inclure de code spécifique dans l'application pour gérer ces permissions.

Prenons un exemple simple, avec une application qui doit envoyer un SMS, incluant par exemple le code suivant :

MessageConnection conn =

    (MessageConnection) Connector.open("sms://+33131313131");

TextMessage msg =

    (TextMessage) conn.newMessage(MessageConnection.TEXT_MESSAGE);

msg.setAddress("sms://88888" );

msg.setPayloadText("Bonjour MISC" );

conn.send(msg);

Pour exécuter ce code, il faut posséder la permission javax.wireless.messaging.sms.send, qui est souvent une des plus restrictives. Dans une application d'un domaine tiers, une confirmation est requise à chaque utilisation, à l'exécution de la méthode MessageConnection.send(). Ce comportement est d'ailleurs assez atypique, dans la mesure où les vérifications sont souvent faites à l'ouverture d'une connexion, lors de l'exécution de Connector.open(). Ici, il vaut mieux attendre l'envoi, dans la mesure où l'adresse de destination peut être changée, comme cela est fait ici (en passant à un SMS surtaxé). L'utilisateur aura donc l'occasion de se rendre compte qu'un SMS surtaxé est sur le point d'être envoyé, car le message de confirmation doit contenir l'adresse d'envoi.

A l'inverse, sur une application d'un domaine opérateur, aucune confirmation n'est demandée à l'utilisateur. La politique de sécurité stipule que l'application doit avertir l'utilisateur des coûts, mais il n'y a ici aucune obligation. Ce système permet une flexibilité accrue ; il est par exemple possible d'avertir l'utilisateur du coût exact de l'envoi du SMS pour son opérateur (qui a signé l'application), mais il faut alors faire confiance à l'application pour présenter ces informations. Le modèle sous-jacent est celui d'un contrat entre le développeur de l'application et l'opérateur téléphonique qui l'a signée, afin d'établir une répartition précise des responsabilités.

Pour faciliter la tâche du développeur d'applications « tierces », la politique de sécurité MIDP définit assez précisément la manière dont les interactions avec l'utilisateur sont organisées. En particulier, il définit des groupes de permissions (Appel téléphonique, accès réseau, messagerie, démarrage automatique, connectivité locale, enregistrement multimédia, lecture de données utilisateur, écriture de données utilisateur, localisation...).

Certains groupes de permissions (accès réseau de bas niveau (socket), messagerie limitée (cell broadcast), accès à la carte SIM) ne sont pas toujours disponibles aux applications tierces, et encore moins aux applications non signées.

Ces groupes permettent de simplifier et de standardiser les interactions avec l'utilisateur. Pour le développeur, ils permettent de rendre prévisibles les interactions avec l'utilisateur. La politique de sécurité définit également la manière dont l'utilisateur peut modifier le comportement par défaut de la plate-forme Java dans un domaine de protection donné. Cela permet en particulier de diminuer le nombre d'interactions requises pour des applications qui utilisent de nombreuses permissions.

Enfin, cette politique de sécurité définit comment la carte SIM doit être utilisée pour vérifier des signatures d'applications, ainsi que des procédures à appliquer en cas de changement de SIM et en cas de roaming, afin de continuer à garantir la validité des signatures des applications opérateur.

3. Quelques problèmes dans le modèle

3.1 Un modèle complexe et difficile à comprendre

Ce modèle de sécurité est intéressant sur le papier, mais il pèche en pratique par sa complexité. Dans certains cas, ce modèle de sécurité peut donner une fausse impression de sécurité aux utilisateurs. Prenons comme exemple les avertissements concernant l'envoi de SMS. Si vous utilisez une application qui n'est pas signée, ou une application qui a été signée par un tiers de confiance, vous avez la garantie de devoir confirmer tout envoi de SMS. En revanche, si l'application a été signée par le fabricant du téléphone ou par l'opérateur mobile, il n'y aura aucune confirmation. Du point de vue de l'utilisateur, la seule différence entre ces deux applications est le nom du signataire, qui n'est affiché qu'une fois, lors de l'installation initiale de l'application.

Un autre problème est lié à l'aspect interactif des requêtes de permissions. Du coup, les permissions sont demandées les unes après les autres, avec potentiellement des écarts importants. On peut donc imaginer un jeu qui demande à son lancement la permission d'accéder à Internet (pour récupérer un niveau), et qui demande à la fin de la partie la permission d'accéder aux contacts (juste après avoir proposé d'envoyer votre score à un ami). Un attaquant augmente ainsi considérablement ses chances d'obtenir deux réponses positives

3.2 Un bac à sable dans le Sahara

L'environnement d'exécution Java est généralement posé sur un système d'exploitation. Ce système peut être très simple dans le cas d'appareils bas de gamme ou ce peut être un système complet pour un téléphone haut de gamme. Dans les deux cas, les risques sont assez différents, même s’ils peuvent parfois se recouper.

Dans un téléphone haut de gamme, le système d'exploitation peut être ouvert. Dans ce cas, les programmes Java et leurs données persistantes sont stockées dans le système de fichiers du téléphone, qui n'est peut-être pas bien protégé lui-même. Dès lors, un attaquant a accès au code et aux données de l'application, permettant au moins de pratiquer un reverse engineering de l'application, et donc d'en identifier les vulnérabilités essentielles. Ces systèmes d'exploitation sont souvent assez simples, et possèdent de nombreuses failles, rendues dangereuses par le fait que la mise à jour régulière des systèmes d'exploitation est une pratique peu répandue sur les mobiles.

Dans un téléphone bas de gamme, des attaques de bas niveau restent possibles, car un tel téléphone embarque peu de mesures de sécurité de bas niveau. Si la mémoire n'est pas chiffrée, un attaquant peut en obtenir une image. Si son intégrité n'est pas vérifiée, il est même possible de modifier une application ou ses données, voire l'environnement d'exécution Java (par exemple pour inhiber la vérification des signatures d'applications).

En pratique, la plupart des attaques sur Java ont été commises par le biais du système sous-jacent, le plus souvent en abusant du système de fichiers de Symbian. Dans le cas de systèmes mal sécurisés, le bac à sable de Java est simplement submergé par les problèmes de son environnement.

On arrive donc à la situation assez classique que les appareils les plus simples sont aussi les plus difficiles à attaquer ; sur des appareils fermés, MIDP est un moyen intéressant d'ouvrir le téléphone en contrôlant les risques associés. Il n'existe apparemment aujourd'hui aucun virus bâti uniquement sur MIDP.

3.3 Certification et fragmentation

Nous avons vu que le modèle de sécurité de MIDP2 repose sur la signature des applications. Une signature est apposée sur une application en conclusion d'un processus de certification, comme le processus « Java Verified », défini par Sun et par un consortium composé des principaux fabricants et opérateurs soutenant MIDP (http://www.javaverified.com/).

Un des problèmes notoires auxquels les développeurs doivent faire face en MIDP est la fragmentation. Les différentes téléphones incluant MIDP2 ont sélectionné des configurations différentes, utilisent des écrans de tailles différentes, sont basés sur des versions différentes de l'environnement... La portabilité des applications n'est donc souvent que relative, dans la mesure où les applications doivent être adaptées aux divers modèles de téléphones. Souvent, afin de limiter la taille de leurs applications, les développeurs fournissent des applications « localisées » à chaque pays. Pour une application diffusée sur 50 modèles différents dans 20 pays, nous obtenons ici 1000 binaires différents, qui devront tous être signés.

Dans un tel scénario, si l'apposition d'une signature implique un processus de certification, même rapide, les coûts deviennent rapidement exorbitants, en raison du volume de binaires à traiter (100.000€ pour une application simple). La fragmentation a été une source de problèmes pour le programme de signature Java Verified depuis sa création, et le consortium UTI qui le gère a pris des initiatives spécifiques pour réduire la fragmentation. Ce sujet fait en effet l'objet d'un guide de développement spécifique, destiné à faciliter le portage des applications ; de plus, le consortium a pris l'initiative de développer une bibliothèque open source de tests d'interopérabilité des mobiles (JATAF, pour Aava Application Terminal Alignment Framework). Ces initiatives datent de 2009, et il faudra un peu de temps pour évaluer leur impact.

3.4 Une signature, ça garantit quoi ?

Le fait de reposer sur une signature électronique des applications peut également donner une fausse impression de sécurité sur les applications. Le programme Symbian Signed, en charge de la certification des applications Symbian, a plusieurs fois signé des applications malveillantes, y compris très récemment, en juillet 2009. Cet incident a généré beaucoup de réactions sur Internet [SIGN].

Avec les outils disponibles aujourd'hui, il est quasiment impossible d'empêcher la signature occasionnelle d'un programme Symbian malveillant. Cela arrive moins souvent aux programmes MIDP, et la raison principale est que les API Java ne permettent souvent pas d'accéder au système sous-jacent de manière pratique pour réaliser des attaques facilement exploitables. Mais, dans le principe, le risque est le même : si une action malveillante est possible en MIDP, elle peut être signée.

En pratique, la signature permet principalement d'authentifier l'auteur de l'application. Si c'est une société connue, le niveau de confiance augmente, principalement car la responsabilité de la société est engagée. Mais, dans le cas de sociétés inconnues, la signature n'apporte pas grand-chose en termes de confiance.

De manière intéressante, la spécification MIDP 2.1 permet de vérifier qu'une signature n'a pas été révoquée avant de lancer une application, ce qui permettrait d'éliminer des applications malveillantes, même après leur déploiement. Cependant, la spécification utilise le mot « SHOULD » pour cette fonction, qui n'est apparemment pas souvent supportée en pratique.

4. Evolution et alternatives

4.1 MIDP 3.0

La version 3.0 de MIDP est actuellement en Proposed Final Draft, dernière étape avant le vote final. Le modèle change peu du point de vue des utilisateurs (les interactions sont quasiment les mêmes), mais les changements sont significatifs pour les développeurs.

Le principal changement est l'adoption du modèle de Java Se, avec plusieurs types de permission au niveau Java. Cela permet de définir des permissions beaucoup plus précises. Par exemple, on peut définir la permission suivante :

MIDlet-Permission-1: javax.microedition.io.HttpProtocolPermission "http://www.vetilles.com/pub/*:*"

Cette permission permet de restreindre l'accès à un site ou même à une partie d'un site. Cela permet de vérifier facilement qu'une application n'utilise une certaine permission que d'une manière restreinte, ce qui peut faciliter le travail des évaluateurs.

Un autre changement important se situe au niveau de la communication entre applications. MIDP 3.0 définit de nouveaux mécanismes de communication, ainsi qu'un moyen de ne partager une ressource qu'avec des applications d'un vendeur donné, signées par un certificat donné ou d'un domaine donné.

Les évolutions sont donc assez mineures, et elles ne remettent pas en cause le modèle existant, où l'utilisateur peut être consulté au cours de l'exécution du programme.

4.2 Alternatives

Nous avons ici insisté sur les faiblesses du système de sécurité de MIDP2. Il convient toutefois de rappeler que ce système est relativement ancien, et qu'il offre un compromis entre sécurité et flexibilité qui n'a pas d'équivalent sur PC.

Dans le monde mobile, d'autres approches sont possibles, et nous en considérons deux à titre de comparaison.

- iPhone. La sécurité des applications iPhone est très différente de celle proposée par MIDP2. Tout d'abord, les applications sont natives, ce qui augmente leur potentiel de nuisance. Ensuite, l'utilisateur final n'est pas du tout impliqué, puisque les interactions sont très rares ; l'exception notable consiste à faire confirmer par l'utilisateur le fait qu'une application n'utilise pas de données de localisation. Par ailleurs, Apple certifie les applications, mais le processus est opaque. Apple contrôle également la distribution des applications, avec la possibilité de les révoquer. Opacité et contrôle : on a peut-être du mal à apprécier, mais la méthode est efficace. Plus d'un milliard de téléchargements plus tard, on attend encore le premier scandale lié à une application malicieuse sur iPhone.

- Android. Les applications Android utilisent une machine virtuelle, dont les principes de base sont inspirés de Java (avec en particulier la vérification du bytecode à l'installation). Ensuite, l'application doit demander des permissions que l'utilisateur doit approuver d'un bloc lors de l'installation de l'application. Pendant l'exécution, plus d'interaction (mais l'utilisateur peut accéder à la liste des permissions de chaque application). En dehors de ça, Google semble avoir un processus de distribution plutôt transparent, mais Google conserve malgré tout la mainmise sur la distribution. Nous manquons cependant de recul pour savoir dans quelle mesure ils vont utiliser ce pouvoir de contrôle.

Conclusion

Le modèle de sécurité de MIDP est le plus ancien encore en vigueur aujourd'hui. Il souffre d'une certaine incohérence, en particulier entre les applications des opérateurs et les applications tierces. Toutefois, ce n'est sans doute pas la sécurité qui a empêché la diffusion des applications, mais plutôt la fragmentation des implémentations et les modes de distribution des applications.

Ma préférence personnelle va au compromis choisi par Android, car il permet à l'utilisateur averti de prendre une décision en connaissance de cause avant d'installer l'application, sans pour autant gêner l'utilisateur de base, qui ignore de toute manière tout avertissement de sécurité.

Enfin, tous ces modèles de sécurité se concentrent sur la protection de l'utilisateur contre des applications malveillantes, mais ils ne donnent aucune directive concernant la protection des biens de ces applications. Le principal danger des applications mobiles ne vient donc probablement pas aujourd'hui des dégâts qu'elles peuvent provoquer, mais du manque de protection des biens de plus en plus sensibles qu'elles renferment.

A propos de l'auteur

Eric Vétillard est venu tardivement à la sécurité, en développant des machines virtuelles Java sur des cartes à puce. Il s'intéresse particulièrement à la sécurité du code mobile et aux manières de certifier du code. Il est responsable technique du Java Card Forum, et directeur technique de Trusted Labs. Retrouvez-le sur son blog à http://javacard.vetilles.com.

Références

[MIDP 2.1] JSR-118 Expert Group, Mobile Information Device Profile Specification, Release 2,1, disponible à http://www.jcp.org/en/jsr/summary?id=118.

[MIDP 3.0] JSR-271 Expert Group, Mobile Information Device Profile Specification, Release 3.0, disponible à http://www.jcp.org/en/jsr/detail?id=271.

[SIGN] VÉTILLARD (Éric), « Should we sign malware ? », juillet 2009, disponible à http://javacard.vetilles.com/2009/07/22/should-we-sign-malware/.