Sécurité des terminaux mobiles – Partie 1/2

La sécurité des mobiles et des communications est un enjeu à la fois pour la vie privée, la liberté, mais aussi pour la sécurité des personnes et des pays. Comment résistent les applications de messageries instantanées aux attaques sur les systèmes et/ou les réseaux ?

Une des principales préoccupations depuis les révélations de Snowden est le respect de la vie privée et des libertés et par conséquent la confidentialité des échanges. Les écoutes massives mises au jour ont effrayé de nombreux utilisateurs de téléphones mobiles. Pour les reconquérir, les fabricants et les éditeurs d’applications sécurisent de plus en plus les données stockées ainsi que celles échangées sur les réseaux.

Cette sécurité ne doit pas compromettre l’expérience utilisateur et donc la rapidité des échanges et la fluidité de traitement. Quelle sécurité est implémentée et à quel point est-elle fiable ?

1. Sécurité des systèmes

La première des protections réside dans le système lui-même, du firmware au système d’exploitation. Comment est garantie cette sécurité ? Comment la compromettre et quels sont les risques ?

1.1 Chaîne de confiance

Le code exécuté par le processeur du terminal est un des garants du fait que les opérations effectuées sont uniquement celles qui sont prévues par l’éditeur du système d’exploitation ou des applications s’exécutant. Afin de garantir que ce code est intègre, une chaîne de confiance est implémentée au démarrage des terminaux. Apple, par exemple, intègre un certificat dans la mémoire ROM (inaltérable) de ses processeurs. Exemple :

Ce certificat racine permet de vérifier l’intégralité de la chaîne de confiance pour tous les éléments de code signés avec des certificats eux-mêmes signés par celui-ci avant d’être exécutés. Ainsi Apple garantit que le code exécuté est le sien. La plupart des systèmes Android (Google, Samsung, LG, HTC…) ont également intégré une chaîne de confiance garantissant l’intégrité du code exécuté. Ces équipements peuvent néanmoins être facilement personnalisés, mais dès lors, un fusible de garantie anti-compromission est déclenché. Certaines applications sécurisées refusent alors de s’exécuter. C’est le cas par exemple de KNOX (Samsung).

Les mises à jour sont également signées et vérifiées afin qu’elles ne soient pas un vecteur de compromission. Enfin, iOS ou les dernières moutures du système Android (6.0.1 mise à jour postérieure à novembre 2016) empêchent les downgrade de système et par conséquent les attaques sur des vulnérabilités antérieures.

Enfin, les applications disponibles sur les magasins sont elles aussi signées, mais pas par l’éditeur du système d’exploitation. Les développeurs restent responsables des applications diffusées, et malgré les vérifications opérées par Google ou Apple, certaines sont malveillantes. Ce système garantit néanmoins que des applications très grand public comme Facebook, Twitter… ne sont pas compromises.

1.2 Vérification d’intégrité du système

Une fois le code vérifié, il est nécessaire de s’assurer que celui-ci n’est pas altéré au cours de l’exécution. Apple utilise plusieurs mesures de protection. La première, Kernel Patch Protection, vérifie périodiquement l’intégrité du kernel (certaines parties exécutées seulement) et empêche tout kernel modifié de s’exécuter. La deuxième est la signature et la vérification systématique des mises à jour qui empêchent un attaquant de modifier le système par ce biais.

Samsung a déployé un système similaire, TrustZone Integrity Measurement Architecture. Celui-ci réside dans la partie TrustZone, Trusted Execution Environment, permettant une exécution sécurisée au niveau matériel.

1.3 Chiffrement des données

Apple a chiffré son système jusqu’à la version 10 d’iOS. Ceci ralentissait la découverte de vulnérabilités en empêchant les chercheurs d’accéder au code. Le chiffrement garantissait également l’authenticité des données, celles-ci ne pouvant être déchiffrées que par un co-processeur cryptographique spécifique dans lequel la clé a été codée au niveau du silicium. Plusieurs contournements ont été trouvés permettant d’accéder au code déchiffré, en utilisant la fonction cryptographique sur un appareil compromis. Cependant, Apple a choisi de ne plus chiffrer complètement les mises à jour de son système d’exploitation, considérant sa chaîne de vérification suffisamment sûre.

La confidentialité des données utilisateur est également souvent assurée par le chiffrement. Sur les plateformes haut de gamme (Apple, Google ou Samsung), une clé spécifique à chaque appareil, combinée au mot de passe utilisateur permet de chiffrer les données. Pour attaquer le mot de passe, il est par conséquent nécessaire d’utiliser le terminal. Ceci implique un nombre d’essais illimités.

Cependant, sur bon nombre de plateformes Android, le chiffrement des données utilisateurs avec une clé dérivée du mot de passe n’est pas fait par défaut. Si Android Marshmallow impose le chiffrement par défaut, celui-ci est réalisé avec le mot de passe « default_password ». Le pin, pattern ou de mot de passe ne servant qu’à accéder à l’interface graphique. Samsung propose une option « Secure boot » permettant d’activer la fonctionnalité de chiffrement par dérivation du mot de passe.

Évidemment, sur les plateformes sécurisées, un accès système à l’insu de l’utilisateur permet d’accéder à l’ensemble des données lorsque le terminal est déverrouillé.

De même, certains mécanismes implémentés pour l’expérience utilisateur permettent de récupérer certaines données même si le terminal est verrouillé. C’est le cas des sauvegardes pour les iPhones par exemple si l’ordinateur sur lequel a été connecté le terminal est récupéré.

Enfin, beaucoup de données sont également sauvegardées dans le cloud. Il est alors uniquement nécessaire d’obtenir les identifiants de connexion afin d’y accéder. Ceci relève d’autres stratégies de pénétration.

1.4 Compromission

Malgré les mesures de protection décrites auparavant, des hackers ou des chercheurs ont réussi à compromettre les systèmes qui les implémentent.

Sur Apple, les jailbreaks permettent d’en contourner un certain nombre. La plupart des solutions publiques requièrent des actions explicites de la part de l’utilisateur, ce qui limite le risque de compromission de type Evil Maid.

Les applications sont exécutées dans des sandboxes, permettant d’isoler leurs données d’exécution et de stockage. Ainsi, une application ne peut en théorie pas agir sur les données d’une autre ou compromettre le système. Néanmoins certaines vulnérabilités ont permis de s’échapper de cette sandbox.

Certains éditeurs de solutions ont implémenté des attaques utilisant des remote exploits. Des traces de tels programmes ont par exemple été trouvées dans la fuite de données de Hacking Team en juillet 2015.

Une fois le système compromis, beaucoup d’attaques deviennent possibles, notamment l’exfiltration des données personnelles stockées sur l’appareil. Néanmoins, selon le niveau de compromission, les données exposées ne sont pas les mêmes. Un accès complet au système permet la modification d’applications ou leur remplacement ainsi que l’interception complète des flux réseaux. Dans ce cas, plus aucune donnée ne peut être considérée comme sûre, notamment les échanges sur les messageries dites sécurisées, comme expliqué ci-dessous.

2. Sécurité des communications de données

Les différentes messageries sécurisées dépendent à la fois de la sécurité du système sur lequel elles sont installées, mais également de la chaîne de confiance qu’elles implémentent. Nous allons voir que cette chaîne est souvent de bonne qualité, mais certaines applications sont plus paranoïaques que d’autres.

2.1 Chiffrement et authentification des communications

2.1.1 Public Key Infrastructure

L’infrastructure à clé publique est la base de la chaîne de confiance des communications sécurisées. Pour rappel, une telle infrastructure fonctionne de la manière suivante :

Fig 1 : Schéma simplifié d’une infrastructure à clé publique.

 

Une autorité racine émet un certificat qu’elle signe elle-même. Elle peut ensuite signer des certificats pour des entités subordonnées ou authentifier des données. La vérification s’effectue en vérifiant les signatures à chaque échelon. La sécurité repose par conséquent sur la confiance accordée à l’autorité racine et à la confidentialité de sa clé privée. En cas de fuite ou de vol, une autorité peut répudier les certificats qu’elle a signés, à condition que cette information puisse être diffusée et les certificats remplacés ou supprimés. Si c’est le certificat racine qui est compromis, alors c’est à l’utilisateur ou à l’éditeur qui l’embarque de le supprimer.

L’exemple le plus parlant d’une telle infrastructure est le magasin de certificats embarqué dans les navigateurs internet. Celui-ci contient les certificats des autorités racines qui permettent d’authentifier les sites web et sécuriser les échanges.

Cette infrastructure est appliquée de la même manière dans la sécurité mobile à la différence qu’elle s’étend à l’ensemble de la plateforme. En effet, chacune embarque également un magasin de certificats permettant l’authentification des échanges. L’authentification de code reste vérifiée par les seuls certificats des éditeurs de système d’exploitation.

Chaque application s’appuyant sur le protocole HTTPS et les communications standards fournies par les frameworks iOS ou Android utilise le magasin de certificat de la plateforme.

Un magasin de certificat est livré avec le système d’exploitation (exemple https://support.apple.com/en-us/HT204132). Cependant, des certificats peuvent également y être ajoutés. Certaines plateformes permettent également à l’utilisateur de ne plus faire confiance à un certificat livré par défaut.

2.1.2 Protocoles utilisés par les applications mobiles

Au-delà des protocoles de chiffrement spécifiques à chaque application, le transport est quasi-exclusivement assuré par HTTPS.

Les applications comme Facebook Messenger, Snapchat, WhatsApp ou Viber utilisent cette couche de transport. Elles utilisent le framework commun de la plateforme qui est régulièrement mis à jour. Les attaques par downgrade de connexion par imposture de serveur ne sont par conséquent plus possibles. Facebook lèvera par exemple une exception « Certificate Unknown » et Snapchat ne répondra qu’un « Close notify » sans détailler l’erreur.

Deux autres protocoles de communication sécurisés on fait leur apparition MTProto pour Telegram et Double Ratchet pour Signal. Ces deux protocoles utilisent des clés éphémères pour le chiffrement des messages et garantissent ainsi la Perfect Forward Secrecy. L’échange des clés est basé sur un échange Diffie-Hellman qui permet d’éliminer les attaques de l’homme du milieu.

Matthieu REGNERY
Institut de Recherche Criminelle de la Gendarmerie Nationale

La seconde partie de cet article sera publiée prochainement sur le blog, restez connectés 😉

Retrouvez cet article (et bien d’autres) dans MISC n°91, disponible sur la boutique et sur la plateforme de lecture en ligne Connect !