SecurityInsider
Le blog des experts sécurité Wavestone

Les nouveautés sécurité d’Android 6 Marshmallow



La nouvelle mouture de la plateforme mobile Android, nommée “Marshmallow” et correspondant à la version 6 et l’API Level 23, a été rendue publique par le projet Android Open Source Project (AOSP) le 5 octobre 2015.
Au-delà des nouveautés graphiques ou ergonomiques, quelques importantes améliorations en matière de sécurité ont été apportées.

Une gestion granulaire des permissions autorisées par application

Cette amélioration est un grand pas en avant dans le modèle de sécurité d’Android qui jusqu’à Android Lollipop, suivait le principe du “tout ou rien” en matière de permissions : un utilisateur devait accepter toutes les permissions exigées par une application, ou simplement choisir de ne pas l’installer. De nombreux abus des usages liés à ces permissions ont eu lieu, impliquant des comportements frauduleux tel que l’envoi de SMS surtaxés.
Il est ainsi désormais possible, après installation, de révoquer des permissions qui seraient jugées abusives : une application de type “réveil” n’a dans l’absolu pas besoin d’accéder à Internet, la liste des contacts ou la carte SD…
En plus d’améliorer la sécurité intrinsèque des fonctions des applications, cette amélioration permet également un meilleur contrôle de la privacité des données en empêchant par exemple une application d’accéder aux informations de géolocalisation.
Il est à noter que cette fonctionnalité de gestion granulaire des permissions, appelée “App Ops”, avait été introduite puis rapidement retirée de la version 4.3 [1] [2].
Dans l’exemple ci-dessous, une application de test [3] initie automatiquement un appel (fictivement malveillant) lors de son démarrage :

Le message inter-applicatif (Intent) traduisant le passage d’un appel téléphonique est effectivement transmis de l’application SampleApplication vers le module téléphonique d’Android :


Cette permission va par suite être révoquée. L’effet est visible dans les traces d’exécution, où ce même message inter-applicatif va cette fois-ci être refusé, retournant que l’application ne dispose pas de cette permission :






Le secure boot et le chiffrement intégral de disque par défaut obligatoires

Autre mesure phare, les constructeurs vont devoir activer le secure boot et le chiffrement intégral de disque par défaut pour les terminaux disposant d’une puce cryptographique matérielle suffisamment performante pour pouvoir être certifié comme étant “Android Compatible”, selon les règles énoncées au sein de “l’Android Compatibility Definition Document” [4] [5].
Cette certification est un pré-requis au niveau des constructeurs pour avoir le droit d’installer, contre rétribution, les services Google (Google Mobile Services) sur leurs terminaux. Pour information une puce est actuellement jugée suffisamment performante si elle permet le chiffrement AES avec un débit d’au moins 50 Mo/s.

Des nouvelles méthodes d’authentification utilisateur 

À l’image de TouchID pour iOS, une API d’authentification biométrique par empreinte digitale a été introduite [6] et va ainsi permettre aux applications de pouvoir mettre en œuvre une authentification forte, en couplant par exemple cette reconnaissance biométrique à une authentification par mot de passe.
Toujours sur le volet authentification, la fonctionnalité ConfirmCredential [7] a été introduite et permet à une application de valider l’authentification d’un utilisateur en se basant sur la référence temporelle de la dernière authentification réussie d’un utilisateur : de manière similaire à une “période de grâce”, une application peut autoriser l’accès si la dernière authentification réussie de l’utilisateur a eu lieu il y a X secondes, lui évitant ainsi de re-saisir ses authentifiants.
Inutile donc de préciser que cette fonction pourrait engendrer des défauts de contrôle d’accès et qu’elle est ainsi à utiliser avec parcimonie.

De multiples ajouts de capacités pour la gestion de flotte [8]:

  • L’intégration de la gestion granulaire des permissions par application, ainsi que la définition d’un comportement par défaut face aux nouvelles permissions demandées à l’exécution par les applications, par exemple suite à une mise à jour : toujours demander à l’utilisateur, toujours autoriser par défaut ou toujours refuser par défaut. Dans ces deux derniers cas les permissions ne sont pas modifiables par l’utilisateur via l’interface graphique [9] ;
  • L’ajout de restriction d’utilisation, en rendant possible l’interdiction d’accès à la liste des contacts entreprise depuis des terminaux Bluetooth ou encore le démarrage en mode sans échec du terminal [10] ;
  • Le renforcement des limitations visuelles pour les terminaux déployés en mode “kiosque” (Corporate-Owned, Single-Use) via la possibilité de désactiver la barre de notification et d’empêcher le terminal de se mettre en veille ;
  •  L’installation et la désinstallation silencieuse d’applications sur un terminal par le gestionnaire de flotte ;
  • L’accès silencieux à un certificat, sans interaction utilisateur, par une application entreprise [11] ;
  • L’installation de certificats et d’autorité de certification par une application entreprise ;
  • La mise à jour automatique du terminal [12].


Les principaux éditeurs de solution de gestion de flotte annoncent avoir pris en compte toutes ces fonctions.


En conclusion, ces améliorations s’inscrivent dans la volonté du projet AOSP et de Google de vouloir faire d’Android un système mobile offrant un niveau de sécurité intrinsèquement élevé, via l’intégration de fonctionnalités de sécurité issues de la solution de containerisation Samsung KNOX [13] ; ainsi qu’une plateforme mature pour un usage en entreprise avec la solution de gestion Android for Work [14].


Sources :


Thomas Debize


Aucun commentaire:

Enregistrer un commentaire