Android 11 Developer Preview: toutes les nouvelles fonctionnalités de confidentialité et de sécurité

En avance sur le calendrier, Google a publié aujourd'hui le premier aperçu du développeur de la prochaine version de l'OS Android: Android 11. Des images système sont disponibles pour les Pixel 2, Pixel 3, Pixel 3a, Pixel 4, mais si vous n'en possédez pas appareils, vous pouvez également essayer l'aperçu du développeur via l'émulateur Android Studio ou le système générique Image. Bien que Google conserve la plupart des nouvelles fonctionnalités intéressantes pour les utilisateurs et les développeurs pour une grande annonce à Google I/O 2020, la société a partagé une multitude de modifications disponibles dans le premier Developer Preview. Voici un résumé de toutes les nouvelles fonctionnalités liées à la confidentialité et à la sécurité annoncées par Google dans Android 11 Developer Preview 1.

Android 11 Developer Preview 1 – Nouvelles fonctionnalités de confidentialité

Accès avec autorisation unique

Android contrôle les types de données auxquelles les applications peuvent accéder via son système d'autorisation. Avant Android 6.0 Marshmallow, les applications demandaient des autorisations lors de l'installation. Les utilisateurs devaient donc décider s'ils acceptaient qu'une application dispose de certaines autorisations avant de l'installer. Android 6.0 Marshmallow a introduit des autorisations d'exécution pour un ensemble sélectionné d'autorisations sensibles, notamment l'accès à la localisation, l'accès au microphone et l'accès à la caméra. Les autorisations d'exécution ne peuvent être accordées qu'après l'installation, et l'application qui les demande doit inviter l'utilisateur via une boîte de dialogue fournie par le système à autoriser l'accès. Enfin, dans Android 10, Google a introduit une version spéciale de l'autorisation d'exécution qui permet à l'utilisateur d'accorder l'accès uniquement lorsque l'application est en cours d'utilisation; cependant, Google n'a introduit que l'option « pendant que l'application est en cours d'utilisation » pour l'autorisation de localisation.

Dans Android 11, Google offre aux utilisateurs un contrôle plus précis sur d’autres autorisations sensibles, notamment l’accès à la caméra et au microphone. La société a introduit une nouvelle fonctionnalité « autorisation unique » dans l'aperçu du développeur Android 11 qui permet à l'utilisateur d'accorder temporairement à une application l'accès à une autorisation tant que cette application est dans le premier plan. Une fois que l’utilisateur quitte l’application, celle-ci perd l’accès à cette autorisation et doit la demander à nouveau.

Modifications du stockage limité

Dans Android 10 bêta 2, Google a proposé un changement radical dans la manière dont les applications accèdent au stockage externe sur Android. (Le stockage externe, ici, est défini comme les données visibles par l'utilisateur et les autres applications situées dans /data/media.) Le Le changement, baptisé « Scoped Storage », visait à éliminer l'utilisation trop large du READ_EXTERNAL_STORAGE autorisation. Trop d'applications sur le Google Play Store demandaient et obtenaient l'accès à l'intégralité du stockage externe sur lequel les utilisateurs enregistraient leurs documents privés, photos, vidéos et autres fichiers. Avec Scoped Storage, les applications auraient, par défaut, uniquement la possibilité de voir leurs répertoires de données privées. Si une application détient l’autorisation READ_EXTERNAL_STORAGE sous l’application Scoped Storage, elle peut alors afficher certains fichiers multimédias accessibles via l’API MediaStore. Alternativement, l'application peut utiliser Storage Access Framework pour que l'utilisateur sélectionne manuellement les fichiers via le sélecteur de fichiers système. Enfin, les applications qui nécessitent un accès large au stockage externe, telles que les gestionnaires de fichiers, peuvent utiliser Storage Access Framework pour demander à l'utilisateur d'accorder à l'application l'accès au répertoire racine du stockage externe, accordant ainsi l'accès à tous ses sous-répertoires, aussi.

L'application du stockage limité devait prendre effet pour toutes les applications sous Android 10, mais après les retours et critiques des développeurs, Google assoupli les changements, ne les exigeant que pour les applications ciblant le niveau d'API 29 (Android 10). Après le 1er août 2020, toutes les nouvelles applications soumises au Google Play Store doivent cibler Android 10, et il en va de même pour toutes les mises à jour des applications existantes après le 1er novembre 2020. De plus, sous Android 11, les développeurs d'applications de gestion de fichiers doit soumettre un formulaire de déclaration à Google pour avoir un large accès au stockage externe; Une fois acceptées, les applications de gestion de fichiers auront une vue non filtrée de MediaStore mais n'auront pas accès aux répertoires d'applications externes.

De plus, Google a introduit d'autres modifications apportées au stockage étendu dans l'aperçu du développeur Android 11. Les applications peuvent choisir d'obtenir le chemin d'accès brut du fichier et d'effectuer des opérations de modification par lots pour les fichiers multimédias dans le MediaStore. L'interface DocumentsUI a été mise à jour pour être plus simple pour les utilisateurs. Ces changements ont été annoncés lors du Sommet des développeurs Android l'année dernière, et on nous promet des améliorations supplémentaires du stockage étendu dans les futures versions d'Android 11.

Android 11 Developer Preview 1 – Nouvelles fonctionnalités de sécurité

Prise en charge du permis de conduire mobile

Depuis le début de l'année dernière, Google travaille sur le API IdentityCredential et HAL dans AOSP. Cette fonctionnalité jette les bases du stockage sécurisé des documents d'identification sur votre appareil mobile, et en particulier des permis de conduire mobiles conformes à la norme ISO 18013-5. Google officiellement a annoncé cette fonctionnalité lors de Google I/O 2019, et maintenant il est enfin pris en charge dans Android 11 Developer Preview 1.

Google n'a pas eu grand-chose à dire sur cette fonctionnalité dans le communiqué de presse, mais comme la fonctionnalité est développée de manière ouverte, nous savons déjà une grande partie de ce qui est prévu. Lors de l'I/O 2019, Google a déclaré qu'il travaillait avec l'ISO pour normaliser la mise en œuvre des passeports électroniques; nous n'avons toujours pas la moindre idée du moment où les passeports électroniques seront disponibles, mais il existe déjà plusieurs États américains où les eDL sont mis en œuvre ou sont en phase d'essai. Google a également déclaré qu'il travaillait à fournir une bibliothèque Jetpack afin que les développeurs puissent créer des applications d'identité. Nous ne savons pas dans combien de temps les développeurs pourront tester cette fonctionnalité, car une prise en charge appropriée nécessite un matériel sécurisé sur l'appareil. Le Unité de traitement sécurisée sur le Qualcomm Snapdragon 865 prend en charge l'API IdentityCredential, bien qu'elle puisse ne pas prendre en charge le mode d'accès direct de l'API puisque le SPU est intégré au SoC; Le mode d'accès direct permettrait à l'utilisateur d'extraire une pièce d'identité électronique stockée même lorsqu'il n'y a pas assez de puissance pour démarrer Android. Pour plus d'informations sur cette API, je recommande lire notre couverture initiale où Shawn Willden, responsable de l'équipe de sécurité matérielle Android, a apporté sa contribution.

Nouveaux modules principaux du projet

L'un des changements les plus importants apportés à Android 10 pour les appareils nouvellement lancés a été l'introduction de Ligne principale du projet, qui malgré son nom, n'a rien à voir avec la prise en charge du noyau Linux principal sur Android. (Ce projet, soit dit en passant, s'appelle Generic Kernel Image et est toujours en cours de réalisation.) Au lieu de cela, le but du projet Mainline est de Google va reprendre le contrôle des composants clés du framework et des applications système aux OEM. Chaque module Mainline est encapsulé sous forme d'APK ou un Fichier APEX et peut être mis à jour par Google via le Play Store. L'utilisateur considère les mises à jour comme une « mise à jour du système Google Play » (GPSU) sur son appareil, et les mises à jour sont publiées à une cadence régulière comme un train (c.-à-d. ils sont téléchargés et installés en même temps).

Google impose l'inclusion de modules Mainline spécifiques, qui, au moment de Google I/O 2019, en comprenaient 13. Désormais, Google impose un total de 20 modules Mainline dans Android 11 Developer Preview 1.

*Remarque: au moment de la publication, Google ne nous a pas fourni la liste complète des modules Mainline actuellement requis. Nous mettrons à jour ce tableau une fois que nous aurons la liste complète.

Modifications biométriques rapides

Présentation d'Android 9 Pie l'API BiometricPrompt, une API unifiée pour le matériel d'authentification biométrique. L'API offre aux développeurs un moyen de défier l'utilisateur grâce à ses données biométriques enregistrées, qu'il s'agisse d'empreintes digitales, de visage ou d'iris. Avant BiometricPrompt, les développeurs devaient créer leur propre boîte de dialogue d'authentification et utiliser l'API FingerprintManager, qui prenait uniquement en charge l'authentification par empreinte digitale, pour défier l'utilisateur. Sur les smartphones Galaxy équipés de scanners d'iris, les développeurs ont dû utiliser le SDK de Samsung pour défier l'utilisateur. Avec BiometricPrompt, les développeurs peuvent défier l'utilisateur avec n'importe quelle méthode biométrique prise en charge, et le système fournit la boîte de dialogue à l'utilisateur. Ainsi, les développeurs n'ont plus à se soucier de la prise en charge spécifique d'un type particulier de matériel biométrique, et ils n'ont plus non plus à coder l'interface utilisateur pour la boîte de dialogue d'authentification. Le Matériel de reconnaissance faciale sécurisé du Pixel 4, par exemple, peut être utilisé pour l'authentification dans les applications qui utilisent BiometricPrompt.

Quoi de neuf pour BiometricPrompt dans Android 11 Developer Preview 1? Google a ajouté 3 nouveaux types d'authentificateurs: fort, faible et informations d'identification de l'appareil. Avant Android 11, les développeurs ne pouvaient interroger le matériel biométrique sécurisé de l'appareil (scanner d'empreintes digitales, scanner de reconnaissance faciale 3D ou scanner d'iris) qu'en utilisant BiometricPrompt. À partir d'Android 11 Developer Preview 1, les développeurs peuvent également interroger des méthodes biométriques jugées « faibles », telles que les solutions logicielles de reconnaissance faciale que l'on trouve sur de nombreux téléphones. Par exemple, Google précédemment mis sur liste noire plusieurs téléphones Samsung Galaxy pour renvoyer un authentificateur de reconnaissance faciale faible lors d'une tentative d'authentification basée sur la cryptographie. C'est maintenant au développeur de décider du niveau de granularité d'authentification biométrique dont son application a besoin.

Stockage et partage sécurisés des BLOB

Une nouvelle API appelée BlobstoreManager permettra aux applications de partager plus facilement et plus sûrement des blobs de données entre elles. Google cite les applications partageant des modèles d'apprentissage automatique comme cas d'utilisation idéal de la nouvelle API BlobstoreManager.

Renforcement de la plateforme

Dans le but de réduire la surface d'attaque d'Android, Google utilise Désinfectants LLVM pour identifier "les bugs d'utilisation abusive de la mémoire et les comportements non définis potentiellement dangereux". Google étend désormais leur utilisation des désinfectants basés sur un compilateur pour plusieurs composants critiques en matière de sécurité, notamment BoundSan, IntSan, CFI et Shadow-Call Stack. Pour détecter les problèmes de mémoire en production, Google active "marquage du pointeur de tas" pour toutes les applications ciblant Android 11 ou version ultérieure. Le marquage du pointeur de tas est pris en charge sur les appareils ARMv8 64 bits avec prise en charge par le noyau d'ARM Top-byte Ignore (TBI), une fonctionnalité dans laquelle "le Le matériel ignore l'octet de poids fort d'un pointeur lors de l'accès à la mémoire. » Google prévient les développeurs que ces améliorations renforcées pourraient "faire apparaître des plantages d'applications plus répétables/reproductibles", les développeurs devraient donc tester minutieusement leurs applications sur le nouveau développeur Android 11 Aperçu. Afin de rechercher et de corriger de nombreuses erreurs de mémoire dans le système, Google a utilisé un outil de détection d'erreurs de mémoire appelé AddressSanitizer assisté par matériel (HWASan). Google propose des images système prédéfinies compatibles HWASan sur le serveur de build AOSP au cas où vous souhaiteriez rechercher et corriger des erreurs de mémoire dans vos propres applications.

---

Google ne manquera pas d'annoncer des fonctionnalités supplémentaires pour protéger la confidentialité des utilisateurs et améliorer la sécurité, alors assurez-vous de garder un œil sur notre couverture Android 11 pour rester à jour.

Actualités Android 11 sur XDA