La sécurité des données dans les applications mobiles

"En avril 2016, le FBI a fait appel à une entreprise spécialisée pour débloquer l’iPhone de Syed Farook, un des auteurs de l’attaque de San Bernardino aux Etats-Unis. Après plusieurs semaines de confrontation au cours de laquelle le FBI a tenté de convaincre Apple de déverrouiller ce téléphone, c’est finalement par une voie détournée que le FBI est parvenu à accéder aux données protégées."

Au-delà des différents débats et des polémiques sur la protection de la vie privée et sur la légalité d’une telle méthode, cet événement nous rappelle que les téléphones et tablettes, qui sont maintenant de plus en plus intégrés dans les solutions informatiques mises en place, deviennent un élément très sensible en termes de sécurité de l’information.

Les spécialistes sécurité s’activent à protéger les données de l’entreprise contre toute attaque externe et adaptent sans cesse les systèmes pour assurer une protection maximale des informations. D’un autre côté, en tant qu’employés de ces mêmes entreprises, nous réclamons un accès facilité à ces données en situation de mobilité, même dans des situations où la connexion n’est pas optimale. Les utilisateurs peuvent ainsi transporter des données sensibles dans leur poche, au risque de se faire subtiliser leur appareil par un tiers ou simplement de l’égarer. La protection des données sur les applications mobiles est donc un sujet important que nous proposons d’aborder ici sous un angle plus technique afin de vous montrer ce que vous pouvez faire pour leur sécurisation.

 

Les risques propres aux appareils mobiles

La tendance actuelle qui consiste à utiliser des appareils privés dans un cadre professionnel (Bring Your Own Device) complexifie encore cette problématique en permettant de faire fonctionner en même temps des applications professionnelles (avec les données de l’entreprise) et des applications à usage privé (comme des jeux) dont les sources ne sont pas forcément fiables et qui peuvent interagir avec les mobiles sans que cela soit forcément visible pour l’utilisateur.

Une application comme Facebook sur Android, par exemple, est avertie dès qu’un SMS est reçu et peut même en intercepter la gestion (le lire, stocker les informations et transmettre le SMS à une autre application). Ce point est critique car certains systèmes de e-banking utilisent une authentification forte à base de messages SMS et rien n’assure que ceux-ci ne sont pas interceptés par une application comme Facebook, voire même transférés et stockés dans une autre base de données. Ce qui est possible avec Facebook, l’est également pour une application malicieuse distribuée sous couvert de jeu gratuit, qui par l’intermédiaire de permissions acceptées rapidement, dispose d’accès à différentes informations de votre smartphone. A noter que la nouvelle version d’Android (version 6) permet une gestion des permissions à l’unité comme sur iOS mais rien n’obligera les applications à adhérer à ce nouveau mode d’autorisation (rétrocompatibilité oblige).

ELCARD: la solution d’authentification multi-facteurs sur smartphone

L’application mobile ELCARD fait partie de la solution d’authentification multi-facteurs élaborée par ELCA. Elle propose une authentification forte en utilisant un Smartphone au moment de la connexion. Cette application est utilisée par les collaborateurs ELCA et plusieurs des clients pour se connecter au VPN d’entreprise. Il est donc essentiel d’avoir une application garantissant une sécurité importante des données stockées sur l’appareil. Le point sensible dans cette application est la génération du code d’authentification qui est envoyé au serveur pour valider l’identité de l’utilisateur. Ce code est calculé à partir d’une grille de codage, et de plusieurs informations: un challenge envoyé par le serveur, l’identité de l’appareil et le pictogramme graphique effectué par l’utilisateur (principe de Password Based Encryption, où une clé de chiffrement est dérivée d’un mot de passe, qui dans ce cas ne sont stockés nulle part). Ce sont l’ensemble de ces informations qui permettent de générer le code d’authentification, dont l’exactitude ne peut être vérifiée que du côté serveur. La grille de codage, élément central de l’algorithme avec le pictogramme de l’utilisateur, est stockée sous forme d’un fichier propre à l’application sur iOS qui assure une bonne isolation des informations entre les applications. Sur Android, où les données sont moins isolées, cette grille de stockage est implémentée par du code natif offusqué, différent sur chaque appareil, qui est généré du côté serveur en fonction des identifiants de l’appareil lui-même et intégré dynamiquement au code de l’application. Ce processus est fait à l’initialisation d’une nouvelle grille de codage et rend inopérante la copie de l’application sur un autre appareil (le code natif intégré n’étant plus compatible avec l’identifiant de l’appareil). De plus ce système permet de limiter la portée d’une attaque utilisant la rétro-ingénierie (la décompilation du code de l’application) à un seul appareil.

 

La gestion des données sensibles dans le domaine de la santé

Comme les entreprises ne cessent de lancer des applications mobiles professionnelles dans le domaine de la santé, ELCA s’efforce de rester à la pointe en matière de sécurité des appareils mobiles, principalement dans les domaines suivants:

  • La sécurisation de la communication avec le back-end.
  • La sécurisation des solutions de stockage embarqué.

Le protocole d’autorisation utilisé pour les applications mobiles est OAuth 2.0, la meilleure solution à l’heure actuelle. Cependant, une étude publiée par Microsoft montre que près de 60 % des applications les plus populaires disponibles sur Google Play "mettent en œuvre des protocoles défectueux vulnérables aux attaques"(1). En effet, la spécification du protocole OAuth 2.0 elle-même, ou plus précisément son processus d’autorisation via un code, contient une faille de sécurité bien documentée qui concerne les applications mobiles (2). Par conséquent, ELCA recommande de prendre les précautions nécessaires lors de toute utilisation d’OAuth 2.0, comme cela a été décrit récemment dans un projet de l’IETF (3).

 

Même si, sur iOS, les données sont enregistrées dans des sandboxes et cryptées par défaut, il faut garder à l’esprit que le cryptage et la protection s’appuient sur la force du mot de passe de l’appareil (4). Pour les applications disponibles via les boutiques d’applications publiques, cela pose un défi particulier: les développeurs n’ont en effet aucun moyen d’imposer l’usage d’un mot de passe sur l’appareil – l’usage d’un mot de passe peut toutefois être rendu obligatoire lorsque l’application est intégrée dans un scénario d’entreprise à l’aide de solutions Mobile Device Management. Bien qu’il soit possible de mettre en œuvre des mécanismes de cryptage spécifiques aux applications – comme c’est le cas avec ELCARD –, on peut aussi décider dans certains cas, lorsque les données et les risques y afférents le justifient, de ne pas stocker les informations extrêmement sensibles sur les appareils et d’obliger les utilisateurs à les consulter en ligne, même si cela est moins pratique.

L’approche Microsoft

L’approche de la solution Enterprise Mobility Suite de Microsoft est différente car elle propose de protéger directement les documents contenant les informations et ne repose donc pas sur la partie applicative elle-même pour garantir cela. Cette fonctionnalité est fournie avec l’intégration de Azure Rights Management (Azure RMS) qui prend en charge l’authentification des utilisateurs et va chiffrer les documents (quel que soit leur type) pour restreindre leur accès.

Le système fonctionne de la manière suivante:

  • Au préalable, l’utilisateur doit disposer d’un compte auprès de Azure Active Directory, condition sine qua non pour utiliser le système Azure RMS.
  • Le document est sécurisé en étant chiffré et n’est donc pas affichable directement.
  • Lors de l’accès à un document sécurisé, une requête de demande d’accès est envoyée à Azure RMS.
  • Celui-ci, une fois l’utilisateur authentifié, génère une clef de déchiffrement elle-même chiffrée par une clef publique de l’utilisateur.
  • Sur le poste client, la clef de déchiffrement est déchiffrée en utilisant la clef privée de l’utilisateur.
  • Le contenu du document est affiché et les droits d’utilisation peuvent être pris en compte par l’application associée si celle-ci intègre la gestion des droits par Azure RMS.

Cette approche présente un avantage certain car elle permet de contrôler la diffusion du document lui-même après sa mise à disposition à l’utilisateur. Ainsi si le destinataire d’un document le transmet par email, celui-ci ne pourra être ouvert par le nouveau destinataire. Cette solution est disponible sur les plateformes mobile (iOS, Android et Windows), les OS de bureau (Windows, Mac OSX) et elle est directement intégré dans la suite Office 365 et d’autres outils comme Foxit PDF Reader.

A noter que le système utilise Azure Active Directory mais les documents eux-mêmes ne sont pas nécessairement disponibles dans le cloud, c’est donc juste l’authentification qui nécessite un compte dans le cloud de Microsoft.

En bref

La mise en place d’application mobile amène de nouveaux défis dont la sécurité des données est une des composantes importantes. De plus, l’utilisation, dans un cadre professionnel, des appareils mobiles personnels, où cohabitent applications professionnelles et de loisirs, oblige à prendre en compte la question de la sécurité des données des applications dès la phase de conception. Une analyse standard des menaces et des risques passe par un diagramme de flux de données et une classification des données selon leur sensibilité. Le but de cette analyse est d’évaluer le risque et de prendre ensuite des décisions quant à la conception de l’application en connaissance de cause. Il est donc essentiel de s’appuyer sur des partenaires expérimentés pour aider au développement et au déploiement réussis de votre application mobile.

 

  1. "OAuth Demystified for Mobile Application Developers", 23.05.2016 (http://research.microsoft.com/pubs/231728/OAuthDemystified.pdf)
  2. "Enhancing OAuth Security for Mobile Applications with PKCE", 23.05.2016 (https://openid.net/2015/05/26/enhancing-oauth-security-for-mobile-applic...)
  3. "Proof Key for Code Exchange by OAuth Public Clients", 23.05.2016 (https://tools.ietf.org/html/draft-ietf-oauth-spop-15)
  4. "A (not so) quick primer on iOS encryption", 23.05.2016 (http://www.darthnull.org/2014/10/06/ios-encryption)