Sécurité logicielle des smartphones

Un utilisateur de smartphone subit différentes menaces lorsqu'il utilise son téléphone. Ces menaces peuvent soit nuire au bon fonctionnement du smartphone, soit transmettre ou modifier les données de l'utilisateur. Pour ces raisons, les applications qui y sont déployées doivent avoir des garanties de confidentialité et d'intégrité quant aux informations qu'elles manipulent. De plus, certains logiciels pouvant être eux-mêmes malveillants, leurs fonctionnalités et leurs activités doivent être limitées (consultation de la position GPS, du carnet d'adresse, transmission de données sur le réseau, envoi de SMS facturés, etc.).

Il y a trois cibles privilégiées par les attaquants[1]:

• les données, les smartphones sont des appareils de gestion de données, par conséquent ils peuvent contenir des données sensibles comme des numéros de cartes de crédit, des informations d'authentification, des informations privées, des journaux d'activité (calendrier, journaux d'appel) ;
• l'identité, les smartphones sont très personnalisables, l'appareil ou son contenu sont associés à une personne spécifique. Par exemple, tout appareil mobile qui peut transmettre de l'information est lié au propriétaire du contrat de téléphonie mobile, un attaquant peut vouloir voler l'identité du propriétaire d'un smartphone pour commettre d'autres délits ;
• la disponibilité, en attaquant un smartphone on peut limiter l'accès de celui-ci au propriétaire, voire l'en priver et le rendre hors service.

À l'origine de ces attaques on retrouve les mêmes acteurs que dans l'informatique non mobile[1] :

• les professionnels que ce soit des commerciaux ou bien des militaires visent les trois cibles précédemment citées. Ils peuvent voler les données sensibles du grand public, pratiquer l'espionnage industriel ou bien utiliser l'identité des personnes attaquées pour réaliser d'autres attaques ;
• les escrocs qui veulent acquérir des revenus par l'intermédiaire de l'identité ou des données qu'ils ont volées. Les escrocs se contentent d'attaquer un maximum de personnes pour augmenter de manière quantitative leur potentiel profit ;
• les pirates qui s'attaquent spécifiquement à la disponibilité. Leur but est de développer des virus et autre vers pour causer uniquement des dommages à l'appareil. Dans certains cas, les pirates ont de l'intérêt à voler des données sur des appareils.

Quand un smartphone est infecté par une personne malveillante, l'attaquant peut opérer plusieurs types d'action sur le smartphone :

• L'attaquant peut manipuler le smartphone comme une machine zombie, c'est-à-dire une machine avec laquelle l'attaquant peut communiquer et envoyer des commandes qui lui serviront à envoyer des messages indésirables (des spams) au travers de sms ou de mails[2] ;
• L'attaquant peut facilement forcer le smartphone à passer des coups de téléphone. Par exemple en utilisant l'Interface de programmation PhoneMakerCall de Microsoft, qui récupère des numéros de téléphone de n'importe quelle source comme les pages jaunes, pour ensuite les appeler[2]. Mais il peut aussi utiliser cette méthode pour appeler des services payants, ce qui provoque un coût pour le propriétaire du smartphone. Elle est également très dangereuse car le smartphone pourrait appeler des services d'urgence et ainsi nuire à leur bon fonctionnement[2] ;
• Un smartphone compromis peut enregistrer les conversations de l'utilisateur avec d'autres personnes et les transmettre[2]. Ceci provoque des problèmes de confidentialité pour les utilisateurs et de sécurité pour les industries ;
• Un utilisateur malveillant peut également voler l'identité d'un utilisateur, usurper son identité (copie de la carte SIM, du téléphone, etc.) et ainsi se faire passer pour lui. Ceci pose des problèmes de sécurité dans des pays où les smartphones permettent de faire des commandes, de consulter ses comptes ou encore servir de carte d'identité[2] ;
• Il peut diminuer l'autonomie du smartphone en déchargeant la batterie[3], par exemple en lançant une application qui va faire fonctionner en permanence le processeur du smartphone, ce qui demande beaucoup d'énergie. Un facteur qui distingue les appareils informatiques mobiles à partir d'ordinateurs de bureau est leurs performances limitées. Ce sont Frank Stajano et Ross Anderson qui ont décrit pour la première fois cette forme d'attaque, la qualifiant d'attaque de « l'épuisement de la batterie » ou de « la torture de la privation de sommeil »[4] ;
• Il peut empêcher le fonctionnement et/ou le démarrage du smartphone en le rendant inutilisable[5]. Il peut soit supprimer les données de démarrage et ainsi rendre le téléphone vide de tous système, soit modifier ces mêmes fichiers pour le rendre inutilisable (exemple : un script qui se lance au démarrage et force le smartphone à redémarrer) ou encore lancer au démarrage une application qui viderait la batterie[4];
• Il peut supprimer les données personnelles (photos, musiques, vidéos, etc.) ou professionnelles (contacts) de l'utilisateur[5].

Certaines attaques proviennent de failles dans le gestionnaire des SMS et des MMS.

Certains modèles de mobiles ont des problèmes dans la gestion des messages SMS binaires. Il est possible en envoyant un message mal-formé de bloquer ou de forcer le téléphone à redémarrer, menant à des attaques par dénis de service. Lorsqu'un utilisateur du modèle SIEMENS S5 recevait un SMS contenant un caractère chinois, cela menait à un déni de service[6]. La norme impose que la taille maximale d'une adresse mail soit de 32 caractères, certaines implémentations de téléphone Nokia ont montré qu'ils ne vérifiaient pas cette norme, par conséquent si un utilisateur entre une adresse mail supérieure à 32 caractères cela mène au dysfonctionnement complet du gestionnaire de messagerie qui est mis hors-service. Cette attaque est nommée "curse of silence". Une étude sur la sécurité de l'infrastructure SMS a révélé que les messages SMS envoyés depuis Internet peuvent être utilisés pour provoquer un déni de service distribué (DDoS) contre les infrastructures de télécommunications mobiles d'une grande ville. L'attaque exploite les retards dans la livraison des messages pour surcharger le réseau.

Un téléphone malintentionné envoie un MMS à d'autres téléphones avec une pièce jointe. Cette pièce jointe est infectée par un virus. À la réception du MMS, l'utilisateur a le choix ou non d'ouvrir cette pièce jointe. S'il l'ouvre, il est infecté et le virus envoie un MMS avec une pièce jointe infectée à tous les contacts de son répertoire. Le virus CommWarrior[5] utilise le carnet d'adresses et envoie des messages MMS incluant un fichier infecté aux destinataires. Exemple réel : un utilisateur a installé le logiciel qu'il a reçu comme message MMS ; ensuite le virus a commencé à envoyer des messages aux destinataires récupérés à partir du carnet d'adresse.

Attaques sur les réseaux GSM

L'attaquant peut chercher à briser le chiffrement du réseau mobile. Le chiffrement des réseaux GSM fait partie de la famille des algorithmes A5. Du fait de la politique de sécurité par l'obscurité il n'a pas été permis de tester publiquement la solidité de ces algorithmes. Il y avait principalement deux variantes de l'algorithme qui étaient déployées : A5/1 et A5/2 (chiffrement par flot), ce dernier étant une version plus faible de chiffrement pour les pays ayant des restrictions légales sur l'utilisation des schémas cryptographiques. Depuis que l'algorithme de chiffrement a été rendu public, il a été prouvé qu'il était possible de casser ces algorithmes de chiffrement en environ 6 heures[7]. En juillet 2007, le 3GPP a décidé de prohiber l'utilisation de A5/2.

D'autres algorithmes publics plus résistants ont été introduits : le A5/3 et le A5/4 (chiffrement par blocs) autrement appelés UEA1 ou KASUMI[8] publiés par l'ETSI. Si le réseau ne supporte pas A5/1 ni d'autres algorithmes A5 supportés par le téléphone mobile, le réseau peut à tout moment forcer l'utilisation de A5/0, qui veut dire que la communication n'est pas chiffrée. Même si le téléphone est capable de communications radio 3G ou 4G qui possèdent des algorithmes bien plus résistants que ceux du 2G GSM, le réseau peut limiter la communication radio au 2G (GSM) et forcer l'utilisation de A5/0 (non chiffré) [9]. Ceci permet l'attaque par IMSI catcher. Une fois l'algorithme cassé, l'attaquant peut intercepter en clair toutes les communications effectuées par le smartphone victime.

Attaques sur les réseaux Wi-Fi

Point d'accès jumeaux

L'attaquant peut chercher à écouter les communications Wi-Fi pour en tirer des informations (identifiant, mot de passe). Ce type d'attaque n'est pas propre aux smartphones mais ceux-ci sont très vulnérables à ces attaques car très souvent le Wi-Fi est le seul moyen de communication qu'ils possèdent pour accéder à Internet. La sécurité des réseaux sans fil (WLAN) est un sujet sensible. Au départ les réseaux sans fils étaient sécurisés par des clés WEP : ses faiblesses sont une clé de chiffrement courte qui est la même pour tous les clients connectés. De plus, plusieurs réductions dans l'espace de recherche des clés ont été trouvées par des cryptologues.

Maintenant les réseaux sans fil sont protégés par le protocole de sécurité WPA. WPA est basé sur le "Temporal Key Integrity Protocol (TKIP)" qui a été conçu pour permettre la migration de WEP à WPA sur le matériel déjà déployé. La principale amélioration en matière de sécurité concerne les clés de chiffrement dynamique. Pour les petits réseaux, la clé WPA est une "clé pré-partagée" qui est basée sur une clé partagée. Le chiffrement peut être vulnérable si la longueur de la clé partagée est courte. Avec des possibilités limitées de saisie, par exemple seulement via le clavier numérique, les utilisateurs de téléphones mobiles ont tendance à définir des clés de chiffrement courtes qui ne contiennent que des nombres. Cela augmente la probabilité qu'un attaquant réussisse une attaque par force brute. Le successeur de WPA se nomme WPA2 ; il est supposé être suffisamment sûr pour résister à une attaque par force brute. Comme pour les réseaux GSM, si l'attaquant arrive à casser la clé d'identification, il lui sera possible d'attaquer le téléphone mais aussi tout le réseau sur lequel il se trouve.

Beaucoup de smartphones se souviennent des réseaux Wi-Fi auxquels ils ont déjà été connectés, ce mécanisme permet d'éviter à l'utilisateur de s’identifier à chaque connexion. Cependant un attaquant pourrait créer un point d'accès Wi-Fi jumeau avec les mêmes paramètres et caractéristiques que le vrai réseau[10], en utilisant le fait que certains smartphones mémorisent les réseaux, ils pourraient confondre les deux réseaux et se connecter au réseau de l'attaquant qui pourra intercepter des données si celui-ci ne transmet pas ses données de manière chiffrée.

Lasco est un ver qui infecte d'abord l'appareil distant à l'aide du fichier au format SIS (en)[11]. Un fichier au format SIS (Software Installation Script) est un fichier script qui peut être exécuté par le système sans interaction avec l'utilisateur. Le smartphone croit donc recevoir le fichier d'une source sûre et le télécharge[5].

Principe des attaques sur le Bluetooth

Les problèmes de sécurité des appareils mobiles liés au Bluetooth ont été étudiés et ont montré de multiples problèmes sur différents téléphones. Une vulnérabilité simple à exploiter : les services non enregistrés ne nécessitent aucune authentification, l'application vulnérable possède un port série virtuel utilisé pour contrôler le téléphone. Un attaquant n'avait besoin que de se connecter au port pour prendre le contrôle total de l'appareil[12]. Un autre exemple, un téléphone doit être à portée et son bluetooth en mode découverte. On envoie un fichier par Bluetooth. Si le receveur accepte, un virus est transmis. Par exemple : Cabir [5] est un ver qui se propage via la connexion Bluetooth. Le ver recherche les téléphones à proximité, avec le Bluetooth en mode découverte et s'envoie vers le périphérique cible. La transmission doit être acceptée par le destinataire ; l'utilisateur doit accepter le fichier entrant et installer le programme. C'est seulement après l'installation que le ver infecte l'appareil.

Le juice jacking est un type de cyberattaque visant un téléphone intelligent, une tablette ou un autre périphérique informatique utilisant un port de rechargement (pour recharger sa batterie) qui sert également de port de transfert de données, par exemple un port USB.

Le juice jacking peut prendre deux formes :

• l'installation d'un logiciel malveillant sur le périphérique ;
• ou le vol de données du périphérique.

Le navigateur Web mobile est un vecteur d'attaque émergent pour les appareils mobiles. Tout comme les navigateurs Web d'ordinateurs personnels, les navigateurs Web mobiles sont issus de moteurs de liaison HTTP et de rendu du HTML, tels que WebKit ou Gecko.

Le déverrouillage de l'iPhone avec le firmware 1.1.1 (jailbreak[13]) a été entièrement basé sur les vulnérabilités du navigateur Web. Par conséquent, l'exploitation de cette vulnérabilité décrit ici l'importance du navigateur Web comme vecteur d'attaque pour un appareil mobile. Il y avait une vulnérabilité basée sur le dépassement de tampon de la pile dans une bibliothèque utilisée par le navigateur Web (libtiff).

Une vulnérabilité dans le navigateur web d'Android a été découverte en octobre 2008. Comme la vulnérabilité iPhone ci-dessus, elle était due à un module de bibliothèque obsolète et vulnérable. Une différence importante à la vulnérabilité iPhone a été l'architecture d'Android, système de sandboxing qui limitait les effets de cette vulnérabilité pour le processus de navigateur Web.

Les smartphones sont aussi victimes des piratages classiques liés au Web : hameçonnage, sites Web malveillants, la grande différence est que les smartphones ne disposent pas encore d'antivirus performant.^{[réf. nécessaire]}

Parfois, il est possible d'échapper aux fonctions de sécurité en modifiant le système d'exploitation lui-même. Comme exemples du monde réel, cette section couvre la manipulation du firmware et des certificats de signature malveillants. Ces attaques sont difficiles.

À la fin de l'année 2004, des vulnérabilités dans l'exécution de machines virtuelles de certains appareils ont été présentées. Il était possible de contourner le vérificateur de bytecode et d'accéder aux méthodes du système d'exploitation natif sous-jacent. Les résultats de ces recherches n'ont pas été publiés dans le détail. La sécurité du firmware Symbian de Nokia Platform Security Architecture (PSA) repose sur un fichier de configuration central SWIPolicy. Par exemple il était possible en 2008 de manipuler un firmware Nokia [14] avant que celui ne soit installé, en effet dans certaines versions téléchargeables de celui-ci, ce fichier était humainement lisible, il était donc possible de le modifier et de modifier l’image du firmware, ceci a été résolu par une mise à jour de Nokia. En théorie les smartphones ont un avantage sur les disques durs car les fichiers de l’OS sont dans la mémoire morte, et ne peuvent donc être modifiés par un malware. Cependant dans certains OS il était possible de contourner cela : dans l’OS Symbian il était possible d’écraser un fichier par un fichier du même nom [14]. Sur l’OS Windows, il était possible de changer un pointeur de configuration général vers un fichier modifiable.

Quand une application est installée, la signature de cette application est vérifiée par une série de certificats. On peut créer une signature valide sans utiliser de certificat valide [15] et l’ajouter à la liste. Dans l’OS Symbian tous les certificats se trouvent dans le répertoire : c:\resource\swicertstore\dat. Avec les modifications du firmware expliquées plus haut il est très facile d’insérer un certificat valide.

Typiquement l'attaque d'un smartphone réalisée par un malware se déroule en trois phases : l'infection d'un hôte, l'accomplissement de sa fonction et la propagation de celui-ci dans le système. Un malware utilisera souvent les ressources offertes par le smartphone infecté. Il utilisera les périphériques de sortie comme le bluetooth ou l'infrarouge mais il pourra aussi utiliser le carnet d'adresse ou l'adresse mail de la personne pour infecter les connaissances de l'utilisateur. Il abusera l'utilisateur en exploitant la confiance qu'il accordera aux données envoyées par une connaissance.

L'infection correspond au moyen qu'utilise le malware pour s'introduire dans le smartphone, il peut soit utiliser une des failles précédemment présentées soit abuser de la crédulité de l'utilisateur. On classe les infections en quatre classes selon leurs degrés d'interaction avec l'utilisateur[18] :

la permission explicite

l'interaction la plus bénigne est de demander à l'utilisateur si elle est autorisée à infecter l'appareil, en indiquant clairement son comportement potentiel de malveillance. C'est le comportement typique d'une preuve de concept des logiciels malveillants.

la permission implicite

cette infection est basée sur le fait que l'utilisateur a l'habitude des procédures d'installation. La plupart des chevaux de Troie tente de séduire l'utilisateur pour qu'il installe un logiciel attractif (jeux, applications utiles etc.) mais qui s'avère contenir un malware.

l'interaction commune

cette infection est liée à un comportement commun, par exemple l'ouverture d'un MMS ou d'un mail.

aucune interaction

cette dernière classe d'infection est la plus dangereuse. En effet un ver capable d'infecter un smartphone et qui pourrait infecter d'autres smartphones sans aucune interaction serait catastrophique. Heureusement pour l'instant il n'y en a jamais eu.

Une fois que le malware aura infecté un téléphone il cherchera aussi à accomplir son but qui se divise en trois grandes classes, en dommages monétaires, endommager les données et/ou l'appareil, et des dommages cachés [19]:

dommage monétaire

après avoir volé des données de l'utilisateur, l'attaquant peut les revendre à ce même utilisateur, ou bien les vendre à une tierce-partie.

endommager

le malware peut endommager partiellement l'appareil.

dommage caché

les deux types de dommages précédemment cités sont détectables, mais le malware peut aussi laisser une porte dérobée pour une future attaque ou encore réaliser des écoutes téléphoniques.

Une fois que le malware a infecté un smartphone, il a toujours pour but de se propager d'une manière ou d'une autre[20] :

• il peut se propager à travers les appareils proches de lui en utilisant le Wi-Fi, le bluetooth et l'infrarouge ;
• il peut se propager aussi en utilisant les réseaux distants comme les appels téléphoniques ou SMS ou encore les emails.

Voici différents logiciels malveillants qui existent dans le monde des smartphones avec un petit descriptif de chacun d'entre eux.

• CommWarrior, découvert le 7 mars 2005, est le premier ver qui peut infecter plusieurs appareils à partir de MMS[5]. Il en envoie sous la forme d'un fichier archive COMMWARRIOR.ZIP qui contient un fichier COMMWARRIOR.SIS. Quand ce fichier est exécuté, Coomwarrior tente de se connecter aux périphériques Bluetooth ou infra-rouges présents dans le périmètre du téléphone infecté sous un nom aléatoire. Il tente ensuite de s'envoyer par message MMS aux contacts présents dans le smartphone avec différents entêtes de message pour que les personnes, qui reçoivent ces MMS, les ouvrent sans plus de vérification.
• Phage est le premier virus sur Palm OS qui fut découvert[5]. Il est transféré sur le Palm depuis un PC par la synchronisation. Il contamine toutes les applications qui se trouvent dans le smartphone et y inclut son propre code pour pouvoir fonctionner sans que l'utilisateur et le système ne le détectent. Tout ce que le système détectera sont ses applications habituelles qui fonctionnent.
• RedBrowser est un cheval de Troie qui est fondé sur java[5]. Le cheval de Troie se fait passer pour un programme « RedBrowser » qui permet à l'utilisateur de visiter des sites WAP sans connexion WAP. Lors de la demande d'installation de l'application, l'utilisateur voit sur son téléphone que l'application a besoin d'une autorisation pour envoyer des messages. De ce fait, si l'utilisateur valide, RedBrowser peut envoyer des sms à des centres d'appels payants. Ce programme utilise la connexion du smartphone aux réseaux sociaux (Facebook, Twitter, etc.) pour obtenir les coordonnées des contacts de l'utilisateur (à condition d'avoir les autorisations nécessaires) et leur envoyer des messages.
• WinCE.PmCryptic.A est un logiciel malveillant sur Windows Mobile qui a pour but de faire gagner de l'argent à leurs auteurs. Il utilise l'infestation des cartes mémoires qui sont insérées dans le smartphone pour se propager plus efficacement[21].
• CardTrap est un virus qui est disponible sur différents types de smartphone qui a pour objectif de désactiver le système et les applications tierces. Il fonctionne en remplaçant le fichier qui est utilisé au démarrage du smartphone et celui de chaque application nécessaire à leur démarrage pour empêcher leurs exécutions[22]. Il existe différentes variantes de ce virus dont Cardtrap.A pour les appareils du type SymbOS. Il infecte également la carte mémoire avec les logiciels malveillants capables d'infecter Windows.
• CMPC fait partie des logiciels malveillants émergents qui peuvent utiliser la proximité des dispositifs de propager, ce qui est difficilement détectable. CPMC utilise la communauté sociale pour fonctionner. Il intègre des composants qui s'adaptent au cours du temps, en traitant avec des logiciels malveillants trouvés lors de sa propagation[23]. Ainsi au cours du temps CMPC fait évoluer ces composants en les remplaçant par des logiciels malveillants rencontrés.

• FlexiSpy est une application qui peut être considérée comme un cheval de Troie basée sur Symbian. Le programme envoie toutes les informations reçues et envoyées par le smartphone à un serveur FlexiSpy. Il a été créé à l'origine pour protéger les enfants et espionner les conjoints adultères[5]. C'est pour cette deuxième partie (espionnage) qu'il peut être considéré comme un cheval de Troie.

Voici un graphique qui représente les effets et actions des logiciels malveillants pour les smartphones (en 2009)[17] :

Effets des logiciels malveillants.

D'après le graphique, 50 logiciels malveillants n'ont pas de comportement négatif[17] si ce n'est leur faculté d'expansion.

Il existe une multitude de malwares. C'est en partie lié à la multitude de systèmes présents sur les smartphones. Cependant une volonté chez les attaquants de rendre leurs malwares multiplateformes, on peut trouver des malwares qui s'attaquent spécifiquement à un OS mais qui se propageront vers différents systèmes.

Tout d'abord pour se propager et pour agir les malwares peuvent utiliser les environnements d'exécution comme la machine virtuelle JAVA ou l’environnement Dotnet. Ils peuvent aussi utiliser des librairies présentes dans beaucoup de systèmes d'exploitation[24]. D'autres malwares disposent de plusieurs fichiers exécutables pour pouvoir s'exécuter dans plusieurs environnements et ils les répandent durant le processus de propagation. En pratique, ce type de malwares a besoin d'une connexion entre les deux systèmes d'exploitation pour l'utiliser comme un vecteur d'attaque. Cette connexion peut être une carte mémoire passée d'un appareil à un autre, un logiciel de synchronisation avec un PC ou un logiciel de transmission.

La première couche de sécurité au sein d'un smartphone se situe au niveau du système d'exploitation porté par celui-ci. Au-delà des rôles habituels d'un système d'exploitation (gérer les ressources, ordonnancer les processus), sur un smartphone, il doit également mettre en place la mécanique permettant d'introduire différentes applications et données sans pour autant introduire de risque.

Une idée centrale retrouvée au sein des systèmes d'exploitation mobiles est l'idée de sandbox. Les smartphones étant actuellement prévus pour accueillir de nombreuses applications, ils doivent mettre en place des mécanismes pour que ces installations ne représentent pas de danger ni pour eux-mêmes, ni pour les autres applications, ni pour les données (du système, des autres applications ou de l'utilisateur). Si une application malveillante parvient à atteindre un terminal, il faut que la surface d'attaque que le système offre soit la plus petite possible. Le sandboxing développe cette idée de compartimenter les différents processus, les empêchant d’interagir et donc de se nuire. En fonction des systèmes, le sandboxing ne se traduira pas de la même façon. Là où iOS mettra l'accent à limiter l'accès à son API pour les applications issues de son App Store, Android basera son sandboxing sur son héritage de Linux.

Les points suivants mettent en valeur des mécanismes mis en place dans les systèmes d'exploitation, notamment Android.

Détecteurs de rootkits

Tout comme sur un ordinateur, l'intrusion d'un rootkit dans le système est un grand danger ; de la même façon que sur un ordinateur, il est important de prévenir ce genre d'intrusions, et d'être capable de les détecter autant que possible. En effet, on peut craindre, de la part de ce genre de programme malveillant, un contournement partiel ou complet des sécurités présentes sur le terminal infecté, pouvant octroyer jusqu'aux droits d'administrateur à l'utilisateur malveillant. Si ceci arrive, rien ne l'empêche alors d'étudier les sécurités qu'il a contourné, de déployer les applicatifs qu'il souhaite, ou encore de diffuser une méthode d'intrusion d'un rootkit à un plus large public[25]^,[26]. On peut citer, comme mécanisme de défense, la chain of trust présente dans iOS. Ce mécanisme repose sur la signature des différentes applications nécessaires au démarrage du système d'exploitation, ainsi que d'un certificat signé par Apple. Dans le cas où des vérifications de signatures ne sont pas concluantes, alors le terminal détecte une anomalie et interrompt la séquence de démarrage[27].

Isolation des processus

Android, de par héritage, utilise les mécanismes d'isolations des utilisateurs de Linux entre les applications. Chaque application se retrouve associée à un utilisateur ainsi qu'à un couple (UID, GID). Cette façon de faire met en œuvre un sandboxing : les applications peuvent être malveillantes, elles ne pourront pas sortir du cadre qui leur est réservé par leurs identifiants, et donc aller interférer avec le bon fonctionnement du système. Par exemple, il est impossible à un processus d'aller mettre fin au processus d'un autre utilisateur ; une application ne pourra donc aller terminer l'exécution d'une autre[25]^,[28]^,[29]^,[30]^,[31].

Droits sur les fichiers

Dans l'héritage de Linux, on retrouve également les mécanismes de permissions. Ceux-ci participent au sandboxing : tout processus ne peut éditer les fichiers qu'il souhaite. Il ne sera donc pas envisageable d'aller librement corrompre les fichiers servant au bon fonctionnement d'une autre application, voire du système. De plus, on trouve dans Android l'idée de verrouillage des permissions de la mémoire. Il n'est pas possible de modifier les droits de fichiers posés sur la carte SD du téléphone, et par conséquent il est impossible d'y installer des applications[32]^,[33]^,[34].

Unité de gestion de la mémoire

De la même façon que sur un ordinateur, une unité de gestion de la mémoire permet d'empêcher une escalade de privilège. En effet, si un processus parvenait à atteindre la zone de mémoire réservée à d'autres processus, il pourrait écrire dans la mémoire d'un processus ayant des droits supérieurs aux siens, des droits root dans le pire des cas, et effectuer des actions qui sont au-delà de ses droits d'action sur le système. Il suffirait d'insérer des appels de fonctions non autorisées par les privilèges de l'application malveillante[35].

Développement au travers d'environnements d'exécution (runtime)

Le développement est, notamment sur Android, effectué en langage de haut-niveau, lesquels effectuent des contrôles sur ce qui est fait par le programme exécuté. On peut par exemple citer les machines virtuelles Java qui contrôlent en permanence les actions des fils d'exécution qu'elles gèrent, surveillent les ressources, les attribuent, et empêchent les actions malveillantes que pourraient tenter des applications. On peut citer les buffer overflow[36] qui sont empêchés par ces contrôles[37]^,[35].

Au-dessus des sécurités du système d'exploitation, on peut ensuite trouver une couche logicielle de sécurité. Cette couche est composée de différentes briques visant à renforcer différents points : empêcher les logiciels malveillants, les intrusions, ou encore l'identification d'un utilisateur en tant qu'humain et son authentification. On y trouvera des briques logicielles qui sont notamment héritées de l'expérience de sécurité acquise avec les ordinateurs ; néanmoins, ces briques subissent, sur des smartphones, des contraintes plus fortes (voir les limitations).

MSM (Mobile Security Management)

Avec l’émergence des différents usages de technologies sans fil et mobiles( BYOD, MDM, enterprise mobility,...) dans l'environnement professionnel, la tendance grandissante du Mobile Security Management (MSM) propose une méthode globale de traitement des risques sécuritaires liés à la mobilité. Cette nouvelle génération d'outil est communément appelée m-UTM (Mobile Unified Threat Management). Elle découle de facto de la complexité des architectures mises en œuvre en matière de mobilité. Que ce soit au niveau de la couche système et du noyau, au niveau des données ou des couches de communication, le Mobile Security Management, à l'aide de composants tels que les modules de chiffrements, les moteurs VPN, ou les routines de politiques permet la prise en charge complète des risques liés à la sécurité mobile. Il établit une prise en charge logique du cycle logique des terminaux mobile^[pas clair] : enrôlement (intégration au système d'information), exploitation, répudiation et adresse la confidentialité, l'intégrité et l'authentification.

Antivirus et pare-feu

Un antivirus peut être déployé sur un téléphone pour vérifier que celui-ci n'est pas infecté par une menace connue, notamment par des détections de signatures de logiciels malveillant parmi les fichiers exécutables que l'antivirus trouve sur le terminal. Un pare-feu, quant à lui, peut veiller sur le trafic existant sur le réseau et s'assurer qu'aucune application malveillante ne cherche à communiquer au travers de celui-ci. Il peut tout autant vérifier qu'une application installée ne cherche pas à établir de communication suspecte, qu'il peut empêcher une tentative d'intrusion[38]^,[25]^,[39]^,[40]^,[26].

Notifications visuelles

Afin que l'utilisateur prenne conscience d'éventuelles actions anormales, telles qu'un appel qu'il n'a pas demandé, on peut lier certaines fonctions à un effet visuel impossible à contourner. Par exemple, dès lors qu'un appel est déclenché, le numéro appelé doit systématiquement être affiché. Ainsi, si un appel est déclenché par une application malveillante, l'utilisateur pourra le constater, et prendre les mesures nécessaires.

Test de Turing

Dans la même idée que précédemment, il est important de confirmer certaines actions par une action de l'utilisateur. Le test de Turing vise à faire la distinction entre un utilisateur humain et un utilisateur virtuel ; il se présente souvent sous la forme d'un captcha. Il est théoriquement impossible à un programme de résoudre un tel test, et donc des actions peuvent être conditionnées par l'approbation ou le refus de la part de l'utilisateur, quand le test lui est proposé[41].

Identification biométrique

Une autre méthode consiste à utiliser la biométrie[42]. Un des avantages à utiliser une sécurité biométrique est que les utilisateurs peuvent éviter de se souvenir d'un mot de passe ou de toute autre combinaison secrète pour s'authentifier et empêcher les utilisateurs malveillants d'accéder à leur terminal. Seul l'utilisateur principal peut accéder au smartphone. La biométrie est une technique d'identification d'une personne au moyen de sa morphologie (par une reconnaissance de l’œil ou du visage, par exemple) ou bien de son comportement (sa signature ou sa façon d'écrire par exemple).

Lorsqu'une application passe les différentes barrières de sécurité, tant au niveau du matériel du smartphone que des vigilances successives des responsables des kiosques d'applications et des utilisateurs, elle peut mettre en œuvre les actions pour lesquelles elle a été conçue. Dès lors que lesdites actions se déclenchent, l'activité de l'application malveillante peut être détectée si l'on surveille les différentes ressources utilisables du téléphone. Suivant les buts des applicatifs, les conséquences de l'infection ne seront pas toujours les mêmes ; on peut d'ailleurs noter que toutes les applications malveillantes ne visent pas à nuire aux terminaux sur lesquels elles se sont déployées. Les points suivants décrivent différents éléments à observer sur le téléphone pour détecter une activité suspecte[43]^,[44].

Batterie

Certaines applications malveillantes visent à épuiser les ressources énergétiques du téléphone. Surveiller la consommation d'énergie du téléphone peut donc être un moyen de les détecter. Même si vider la batterie n'est pas nécessairement leur but, l'utilisation des ressources énergétiques du smartphone sera impactée , surtout si ces applications malveillantes sont fortement actives sur les réseaux sans fil[25].

Consommation de mémoire

La consommation de mémoire est inhérente à toute activité de la part d'un applicatif. Néanmoins, si l'on constate qu'une part importante de la mémoire est utilisée par une application, celle-ci peut sembler suspecte.

Trafic réseau

Sur un smartphone, nombre d'applications installables sont vouées à établir des connexions sur le réseau ; il en va souvent de leur fonctionnement normal. Néanmoins, une application utilisant fortement le réseau peut être suspectée de tenter de communiquer un grand nombre d'informations, ou de diffuser des données à de nombreux autres terminaux. Ce constat ne permet qu'une suspicion car des applications comme le streaming peuvent consommer beaucoup des ressources en termes de communications sur le réseau.

Services

On peut surveiller l'activité des différents services d'un smartphone. Lors de certaines actions, certains services n'ont pas à connaître d'activité et si l'on en détecte, l'application en étant à l'origine est suspecte. On peut par exemple citer l'activation du service d'envoi de SMS quand on est en train de filmer : cette activation n'a pas lieu d'être, et une application peut tenter d'envoyer des SMS pendant que son activité est masquée[45].

Les différents points de surveillance cités ci-avant ne représentent que des indications et non pas des mesures permettant d'affirmer avec certitude de la légitimité de l'activité d'une application. Néanmoins, ces critères peuvent aider à cibler des recherches, surtout dans le cas où plusieurs critères se croisent, mettant en évidence une application comme ayant des utilisations suspectes des ressources.

Le trafic des informations échangées par les protocoles propres aux téléphones est un élément qui peut être surveillé. On peut placer des sécurités au sein des points de trafic des informations afin de pratiquer des détections ou des filtres de comportements anormaux. Comme l'usage des protocoles mobiles est beaucoup plus cadré que l'utilisation d'internet, les flux de données peuvent être tout à fait prévus (tel que le protocole suivi pour l'envoi d'un SMS par exemple) ; ceci permet de détecter facilement des anomalies au sein des réseaux mobiles.

Filtres anti-spam

Comme pour les e-mails, on peut constater des campagnes de spam par l'intermédiaire des moyens de communications d'un portable (SMS, MMS). Il est donc possible de détecter et amoindrir ce genre de tentative par des filtres déployés sur les infrastructures relayant ces messages.

Chiffrement des données stockées ou télé communiquées

Dans la mesure où il est toujours possible que des données échangées puissent être interceptées, les communications, ou même le stockage d'information, peuvent s'appuyer sur la cryptographie afin de prévenir qu'une entité malveillante puisse utiliser d'éventuelles données obtenues lors de communications. Ceci pose néanmoins le problème de l'échange de clé par canal sécurisé pour les algorithmes de chiffrement en nécessitant un.

Surveillance du réseau télécom

Les réseaux d'échanges pour les SMS et les MMS ont des comportements complètement prédictibles ; leur usage n'est pas aussi libre que ceux des protocoles tels que TCP ou UDP. Cette liberté empêche de prédire l'usage qui sera fait des protocoles courants du web ; on peut générer un trafic faible et intermittent en consultant de simples pages, ou bien générer un trafic intense et continu en utilisant du streaming. Les échanges de messages via les téléphones sont des communications ayant un cadre et un modèle précis et l'utilisateur d'un téléphone n'a pas, dans un cas normal, la liberté d'intervenir dans les détails de ces communications. Or donc, si une anomalie dans les flux d'échanges de données apparaît au sein des réseaux mobiles, il y a une potentielle menace qui peut être rapidement détectée.

Dans la chaîne de construction et de diffusion des terminaux, il est de la responsabilité des constructeurs de veiller à ce que leurs machines soient diffusées dans un état de base n'apportant aucune faille. Les utilisateurs ne sont majoritairement pas experts et nombre d'entre eux ne sont pas au fait de l'existence de failles de sécurité ; la configuration diffusée par les constructeurs sera donc la configuration conservée par nombre d'utilisateurs. Ci-dessous sont listées plusieurs points auxquels les constructeurs doivent veiller.

Retirer le mode débug

Les téléphones sont utilisés dans un mode de développement, durant celui-ci, et ce mode doit être désactivé avant la commercialisation. Ce mode permet l'accès à différentes fonctionnalités, non prévues pour une utilisation habituelle. De par la vitesse de développement et de production, des inattentions surviennent et certains appareils sont commercialisés en mode de débug. Ce genre de déploiement mène à des gammes de téléphones sensibles à des failles exploitant cet oubli[46]^,[47].

Paramétrages par défaut corrects

Quand un smartphone est commercialisé, son paramétrage doit être correct, et ne pas laisser place à des vides de sécurité. La configuration par défaut n'est pas toujours modifiée, et un bon paramétrage initial est essentiel pour les utilisateurs. On trouve par exemple des configurations de bases permettant des attaques de déni de service[25]^,[48].

Examen des applications publiées

Accompagnant l'avènement des smartphones, des kiosques d'applications sont apparus. Un utilisateur se retrouve donc face à un choix immense d'applications. Ceci est encore plus vrai pour les entités se chargeant de déployer ces kiosques, car elles ont pour tâche d'examiner le contenu qui leur est soumis, à différents points de vue (informatique, moral). Cet examen informatique doit être particulièrement précautionneux, car si une faille n'est pas détectée, l'application peut se répandre en quelques jours de façon très rapide, et contaminer un grand nombre de terminaux[25].

Détecter les applications demandant des droits suspects

Lors de l'installation d'applications, il est bon de mettre en garde l'utilisateur contre des ensembles de permissions qui, groupées, semblent potentiellement suspectes ou dangereuses. C'est ce que cherchent à détecter des outils tels que le framework Kirin, sur Android, interdisant certains ensembles de permissions[41].

Procédure de révocation

Avec les kiosques d'application est apparue une fonctionnalité introduite au sein des terminaux : une procédure de révocation. Initiée par Android, cette procédure consiste à une désinstallation distante et globale d'une application, sur tous les terminaux la possédant. Ceci fait que la diffusion d'une application malveillante ayant réussi à échapper aux contrôles peut être immédiatement stoppée quand la menace est révélée[49]^,[50].

Éviter de trop personnaliser et brider les systèmes

Des fabricants sont tentés de mettre des surcouches sur les systèmes d'exploitation existants, dans le double but d'offrir des options personnalisées et de brider ou rendre payantes certaines fonctionnalités. Ceci a pour conséquence, d'une part d'introduire de nouveaux bogues car les surcouches sont rarement aussi stables et fiables que les systèmes originaux, d'autre part d'inciter les utilisateurs à modifier les systèmes pour contourner les restrictions, ce qui peut introduire de nouvelles vulnérabilités.

Améliorer les processus de mises à jour

De nouvelles versions des différentes composantes logicielles d'un smartphone, notamment les systèmes d'exploitation, sont régulièrement publiées. Celles-ci corrigent de nombreuses failles au fil du temps. Néanmoins, les constructeurs mettent souvent un temps considérable pour déployer ces mises à jour pour leurs terminaux, et ne le font parfois pas. Ainsi, des failles persistent alors qu'elles pourraient être corrigées ; et dans le cas où elles ne le sont pas, puisqu'elles sont connues, elles sont très facilement exploitables[41].

De nombreux comportements mal intentionnés sont permis par l'inattention de l'utilisateur. Depuis l'absence de verrouillage par mot de passe du terminal jusqu'au contrôle précis des permissions accordées aux applications, l'utilisateur a une grande part de responsabilité dans le cycle de sécurité : ne pas être le vecteur d'intrusion. Cette précaution est d'autant plus importante dans le cas où l'utilisateur est l'employé d'une entreprise et qu'il stocke, à ce titre, des données professionnelles au sein de son terminal. Ci-dessous sont détaillées quelques précautions que peut prendre un utilisateur afin de veiller correctement à son smartphone.

Être sceptique

Un utilisateur ne doit pas croire tout ce qui peut lui être présenté car certaines informations peuvent être des tentatives d'hameçonnage ou vouées à diffuser une application malveillante. Il est donc conseillé de vérifier la réputation des applicatifs que l'on souhaite acquérir avant d'effectivement les installer sur son terminal[51].

Droit d'installation d'une application sur smartphone.

Permissions données aux applications

La distribution massive d'applications s'est accompagnée de la mise en place de mécanismes de permissions au sein des différents systèmes d'exploitation. Il est nécessaire d'éclaircir ces différents systèmes aux utilisateurs, car ils diffèrent d'un système à l'autre, et ne sont pas toujours triviaux ; de plus, il est rarement possible de modifier un ensemble de permission demandé par une application si celui-ci est trop large. Mais ce dernier point est un source de risques, car un utilisateur peut accorder des droits à une application, bien au-delà des droits dont elle a besoin. Par exemple, une application de prise de note n'a a priori pas besoin d'un accès au service de géolocalisation. L'utilisateur doit donc veiller aux privilèges requis par une application lors de son installation et ne pas accepter l'installation si les droits demandés sont incohérents[52]^,[48]^,[53].

Être précautionneux

La protection du terminal d'un utilisateur passe par de simples gestes et précautions tels que verrouiller son smartphone quand celui-ci n'est plus utilisé, protéger le déverrouillage par un mot de passe, ne pas laisser son terminal sans surveillance, ne pas faire confiance aux applications, ne pas stocker de données sensibles ou uniques, ou encore chiffrer les données sensibles qu'on ne peut séparer de l'appareil[54]^,[55].

Veiller aux données

Les smartphones possèdent une mémoire non négligeable et permettent de transporter plusieurs gigaoctets de données. L'utilisateur doit être prudent quant à la nature des données qu'il transporte et si celles-ci doivent être protégées. Il n'est généralement pas dramatique de laisser une chanson être copiée, mais le vol d'un fichier contenant des informations bancaires ou des données professionnelles est plus dangereux. L'utilisateur doit donc avoir la prudence d'éviter le transport de données sensibles non chiffrées sur un smartphone, lequel peut être perdu ou volé. De plus, quand un utilisateur se sépare d'un terminal, il doit veiller à retirer toutes ses données personnelles avant de le transmettre[54]^,[48].

Veiller aux services de communication

Quand un terminal n'en a pas l'usage, l'utilisateur ne doit pas laisser les communications sans fil (Wi-Fi et Bluetooth) actives ; dans le cas où celles-ci souffrent d'un mauvais réglage, ces canaux de communications peuvent fournir une entrée à une personne ayant des intentions malveillantes.

Ces précautions sont des mesures permettant de ne pas laisser de solution de facilité à l'intrusion de personnes ou d'applications malveillantes au sein d'un smartphone ; si les utilisateurs sont prudents, de nombreuses attaques peuvent être déjouées, tout particulièrement l'hameçonnage et les applications ne cherchant qu'à obtenir des droits sur un terminal.

Les mécanismes de sécurités cités dans cet article sont pour une bonne part hérités de la connaissance et de l'expérience acquise avec la sécurité des ordinateurs. Les briques composant les deux types d'appareils sont proches, et l'on trouve des mesures communes, telles que les antivirus et les pare-feu. Néanmoins, la mise en place de ces solutions n'est pas toujours possible ou tout au moins est fortement contrainte dans le cadre d'un terminal mobile. La raison en est la différence de ressources techniques que proposent les deux types d'appareil ; quand bien même la puissance des smartphones est de plus en plus importante, ceux-ci souffrent d'autres limitations que leur puissance de calcul.

• Système mono-tâche : certains systèmes d'exploitation, tout au moins dans des versions passées mais toujours couramment utilisées, sont mono-tâche. Seule la tâche au premier plan est exécutée. Il paraît délicat d'introduire des applications telles que des antivirus et des pare-feu sur de tels systèmes, car ceux-ci ne pourraient pas effectuer leur surveillance pendant que l'utilisateur est en train d'utiliser le terminal, c'est-à-dire quand il y aurait le plus besoin de ladite surveillance.
• Autonomie énergétique : un critère capital quant à l'utilisation d'un smartphone est son autonomie énergétique. Il est important de ne pas ajouter une surcharge trop importante de consommation de ressources par les mécanismes de sécurité, sans quoi l'autonomie des terminaux s'en trouverait affectée de façon importante, nuisant à la bonne utilisation du smartphone.
• Réseau : directement liée à l'autonomie de l'appareil, l'utilisation du réseau ne doit pas être trop importante. C'est en effet une des ressources les plus coûteuses, d'un point de vue de la consommation d'énergie ; néanmoins, les calculs les plus lourds peuvent nécessiter d'être délocalisés sur des serveurs en vue de préserver la batterie. Cette balance peut rendre délicate l'implémentation de certains mécanismes, gourmands en calcul[56].

De plus, il est à noter qu'à tous les niveaux, il est courant de constater que des mises à jour existent, peuvent être développées, ou déployées, mais que ceci n'est pas toujours fait. On peut par exemple citer un utilisateur qui ne sait pas qu'il existe une version plus récente du système d'exploitation compatible avec son smartphone, ou encore des failles connues mais non corrigées avant de longues périodes dans certains cycles de développement, lesquelles périodes permettent d'exploiter les failles mises à jour[47].

• (en) Matt Bishop, Introduction to Computer Security, Addison Wesley Professional, 2004, 784 p.

• (en) Ken Dunham, Saeed Abu-Nimeh et Michael Becher, Mobile Malware Attack and Defense, Syngress Media, 2008, 401 p. (lire en ligne)

• (en) Chuanxiong Guo, Helen Wang et Wenwu Zhu, « Smartphone attacks and defenses », ACM SIGCOMM HotNets, Association for Computing Machinery, Inc.,,‎ novembre 2004 (lire en ligne)

• (en) Mulliner Collin Richard, « Security of Smart Phones », citeseerx, Association for Computing Machinery, Inc.,,‎ 2006 (lire en ligne)

• (en) Audun Jøsang, Laurent Miralabé et Léonard Dallot, « It's not a bug, it's a feature: 25 years of mobile network insecurity », European Conference on Cyber Warfare and Security (ECCWS 2015),‎ 2015 (lire en ligne)

• (en) Volker Roth, Wolfgang Polak et Eleanor Rieffel, « Simple and Effective Defense Against Evil Twin Access Points », ACM SIGCOMM HotNets,‎ 2008 (ISBN 978-1-59593-814-5, DOI 10.1145/1352533.1352569, lire en ligne)

• (en) Michael Becher, « Security of Smartphones at the Dawn of their Ubiquitousness », Document,‎ 2009 (lire en ligne)

• (en) Vaibhav Ranchhoddas Pandya, « Iphone Security Analysis », Document,‎ 2008 (lire en ligne)

• (en) Sampo Töyssy et Marko Helenius, « About malicious software in smartphones », Journal in Computer Virology, Springer Paris,, vol. 2, n^o 2,‎ 2006, p. 109-119 (ISSN 1772-9890, lire en ligne)

• (en) Timo Gendrullis, « A real-world attack breaking A5/1 within hours », citeseerx,‎ novembre 2008, p. 266--282 (lire en ligne)

• (en) Aubrey-Derrick Schmidt, Hans-Gunther Schmidt, Leonid Batyuk, Jan Hendrik Clausen, Seyit Ahmet Camtepe et Sahin Albayrak, « Smartphone Malware Evolution Revisited: Android Next Target? », 4th International Conference on Malicious and Unwanted Software (MALWARE),, 2009 4th International Conference on,‎ avril 2009 (ISBN 978-1-4244-5786-1, lire en ligne)

• (en) Feng Yang, Xuehai Zhou, Gangyong Jia et Qiyuan Zhang, « A Non-cooperative Game Approach for Intrusion Detection in Smartphone Systems », 8th Annual Communication Networks and Services Research Conference,‎ mai 2010 (ISBN 978-1-4244-6248-3, lire en ligne)

• (en) Michael Becher, Felix C. Freiling, Johannes Hoffmann,, Thorsten Holz,, Sebastian Uellenbeck,, et Christopher Wolf,, « Mobile Security Catching Up? Revealing the Nuts and Bolts of the Security of Mobile Devices », Security and Privacy (SP), 2011 IEEE Symposium on,‎ mai 2011 (ISBN 978-1-4577-0147-4, ISSN 1081-6011, DOI 10.1109/SP.2011.29, lire en ligne)

• (en) Sung-Min Lee, Sang-bum Suh, Bokdeuk Jeong et Sangdok Mo, « A Multi-Layer Mandatory Access Control Mechanism for Mobile Devices Based on Virtualization », Consumer Communications and Networking Conference, 2008. CCNC 2008. 5th IEEE,‎ janvier 2008 (ISSN 0197-2618, lire en ligne)

• (en) Xudong Ni, Zhimin Yang, Xiaole Bai, Adam C. Champion et Dong Xuan, « DiffUser: Differentiated User Access Control on Smartphones », Mobile Adhoc and Sensor Systems, 2009. MASS '09. IEEE 6th International Conference on,‎ octobre 2009 (ISBN 978-1-4244-5113-5, lire en ligne)

• (en) David Dagon, Tom Martin et Thad Starder, « Mobile Phones asComputing Devices:The Viruses are Coming! », IEEE Pervasive Computing, vol. 3, no. 4,‎ octobre-décembre 2004 (ISSN 1536-1268, lire en ligne)

• Cigref, « Sécurisation de la mobilité », cigref,‎ octobre 2010 (lire en ligne)

• (en) James W. Mickens et Brian D. Noble, « Modeling epidemic spreading in mobile environments », WiSe '05 Proceedings of the 4th ACM workshop on Wireless security, Association for Computing Machinery, Inc.,,‎ 2005, p. 77-86 (DOI 10.1145/1080793.1080806, lire en ligne)

• (en) Feng Li, Yinying Yang et Jie Wu, « CPMC: An Efficient Proximity Malware Coping Scheme in Smartphone-based Mobile Networks », INFOCOM, 2010 Proceedings IEEE,‎ mars 2010 (ISSN 0743-166X, lire en ligne)

• (en) Wei Hoo Chong, « iDENTM Smartphone Embedded Software Testing », Information Technology, 2007. ITNG '07. Fourth International Conference,‎ novembre 2007 (ISBN 0-7695-2776-0, lire en ligne)

• (en) Bryan Dixon et Shivakant Mishra, « On Rootkit and Malware Detection in Smartphones », Dependable Systems and Networks Workshops (DSN-W), 2010 International Conference,‎ juin - juillet 2010 (ISBN 978-1-4244-7728-9, lire en ligne)

• (en) Machigar Ongtang, Stephen McLaughlin, William Enck et Patrick Mcdaniel, « Semantically Rich Application-Centric Security in Android », Computer Security Applications Conference, 2009. ACSAC '09. Annual,‎ décembre 2009 (ISSN 1063-9527, lire en ligne)

• (en) Aubrey-Derrick Schmidt, Rainer Bye Bye, Hans-Gunther Schmidt, Jan Clausen, Osman Kiraz, Kamer A. Yüksel, Seyit A. Camtepe et Sahin Albayrak, « Static Analysis of Executables for Collaborative Malware Detection on Android », Communications, 2009. ICC '09. IEEE International Conference,‎ 2009 (ISSN 1938-1883, lire en ligne)

• Romain Raboin, « La sécurité des smartphones », SSTIC09,‎ décembre 2009 (lire en ligne)

• Nicolas Ruff, « Sécurité du système Android », SSTIC11,‎ 2011 (lire en ligne)

• (en) Rubathas Thirumathyam et Mohammad O. Derawi, « Biometric Template Data Protection in Mobile Device Environment Using XML-database », 2010 2nd International Workshop on Security and Communication Networks (IWSCN), 2010,‎ 2010 (ISBN 978-1-4244-6938-3, lire en ligne)

• (en) Giles Hogben et Marnix Dekker, « Smartphones: Information security risks, opportunities and recommendations for users », Document,‎ 2010 (lire en ligne)

• (en) Aubrey-Derrick Schmidt, Hans-Gunthe Schmidt, Jan Clausen, Kamer Ali Yüksel, Osman Kiraz, Ahmet Camtepe et Sahin Albayrak, « Enhancing Security of Linux-based Android Devices », in Proceedings of 15th International Linux Kongress,‎ octobre 2008 (lire en ligne)

• Asaf Shabtai, Yuval Fledel, Uri Kanonov, Yuval Elovici et Shlomi Dolev, « Google Android: A State-of-the-Art Review of Security Mechanisms », CoRR,‎ 2009 (lire en ligne)

• (en) Cedric Halbronn et Jean Sigwald, « iPhone security model & vulnerabilities », HITB SecConf 2010,‎ 2010 (lire en ligne)

• Siemens, « Siemens M Series SMS DoS Vulnerability », sur securityfocus.com

• ESTI, « 3GPP™ Confidentiality and Integrity Algorithms UEA1 & UIA1 » [archive du 12 mai 2012], sur etsi.org (consulté le 21 avril 2012)

• Portail de la sécurité de l’information
• Portail de la sécurité informatique
• Portail des télécommunications