GrapheneOS : présentation en détails de l'OS et du projet

GrapheneOS est un système d'exploitation mobile basé sur le code source d'Android (AOSP), compatible avec son écosystème d'applications, et visant à renforcer la sécurité et la vie privée. Revenons ensemble sur l'état de cet OS open-source alternatif en 2021 !

GrapheneOS : présentation en détails de l'OS et du projet

Une nébuleuse de connaissances

En août dernier, j'avais mentionné pour la première fois GrapheneOS sur ce blog. Cela faisait déjà quelques mois que j'utilisais GrapheneOS en OS mobile principal, et il y a quelques temps cela fait un an désormais que je l'utilise au quotidien. Le temps passe si vite !

À la découverte de GrapheneOS
GrapheneOS est un système d’exploitation (OS) focalisé sur la sécurité et la vie privée, compatible avec l’écosystème d’applications Android dont il est dérivé.

Et depuis ce premier article, GrapheneOS a également évolué : naturellement avec le passage à Android 11 qui a été réalisé en quelques semaines à peine, et le support de nouveaux appareils.

J'ai aussi pu constater des retours très positifs, l'arrivée de nouveaux utilisateurs, et de membres réguliers d'une communauté qui ne cesse de grandir et se rassemble autour d'un objectif : proposer une sécurité pragmatique loin des dogmes de la sécurité théâtrale.

Evidence-based security
En écho à la “broscience” (usuellement de la désinformation scientifique par des personnes non-compétentes), je souhaite m’adresser dans cette série d’articles à des mythes persistants de la sécurité informatique, qui n’ont jamais été corrects, ou bien obsolètes.

Je mentirais si je disais que ce blog n'a pas été inspiré par mes nombreuses conversations, directement avec des développeurs de GrapheneOS ou avec d'autres chercheurs en sécurité. J'ai longtemps été un passionné de sécurité informatique, mais je dois dire que j'ai énormément appris en l'espace d'une année, et ce blog est une façon de partager à mon tour ce savoir de façon (je l'espère) plutôt accessible mais toujours technique et sourcé.

Dans ce présent article, je propose un mélange de plusieurs points :

  • Explication de l'intérêt de GrapheneOS
  • Les renforcements de GrapheneOS
  • Les fonctionnalités de GrapheneOS
  • Usage d'Android sans Google Play Services
  • Mon retour d'expérience après un an
  • L'avenir du projet et conclusions

Sur certains aspects, cet article sera une réécriture modernisée du précédent. La présence de redite est donc attendue.

GrapheneOS : son intérêt

GrapheneOS est donc une distribution d'AOSP (Android Open Source Project). Il convient dans un premier temps de faire l'état des lieux de cette fondation sur laquelle GrapheneOS tente de se construire.

La fondation : AOSP (Android Open Source Project)

Nous avons récemment analysé et étudié de surface le modèle de sécurité d'AOSP et sa place dans l'écosystème mobile :

Le modèle de sécurité mobile : Android, iOS, “Linux phones”
Petite incursion dans le monde de la sécurité mobile. Qu’en est-il de son modèle de sécurité ? Quels sont les moyens mis en oeuvre par ses acteurs principaux ?

Cet article vous aidera à comprendre qu'AOSP possède un modèle de sécurité minutieusement pensé, non-exhaustivement à titre de rappel :

  • Chaque application dispose d'une sandbox (au sein d'un profil)
  • Chaque profil a ses propres clés de chiffrement (FBE)
  • Il y a une vérification d'intégrité au démarrage (verified boot)
  • Les privilèges sont toujours restreints (principe du moindre privilège)
  • Utilisation encouragée des éléments sécurisés (StrongBox, Weaver)
Aparté sur Google Titan M
Petite incursion dans le monde de la sécurité hardware et des enclaves sécurisées, avec la vedette Titan M, la puce de sécurité pensée par Google.

AOSP est lui-même une distribution de Linux, dont nous avons parcouru quelques défauts techniques en matière de sécurité :

Linux et la sécurité, tel un désert et un oasis ?
On entend souvent que Linux est un OS plus sécurisé que les autres. Mais qu’est-ce que ça veut dire, et est-ce vrai ? Posons-nous un court instant pour vérifier la véracité de cette association en l’an 2021...

Pour parvenir à son modèle de sandboxing robuste, AOSP emploie des règles strictes SELinux qui visent à réduire drastiquement la surface d'attaque exposée par Linux aux applications.

AOSP mène un travail de fond depuis plusieurs années sur le champ de la sécurité de Linux visant à limiter les interactions dangereuses entre le kernel et l'userpsace, et à corriger ne serait-ce qu'en partie ses défauts liés à la gestion de la mémoire.

Buffer overflow & consort : tout ce que vous devez savoir
De nombreuses vulnérabilités dans les systèmes informatiques sont liées à des erreurs de gestion de la mémoire, permises entre autres par l’utilisation de langages de bas-niveau répandus tels que le C et le C++. En 2019, elles constituaient pour Microsoft environ 70% des vulnérabilités traitées.

Depuis 2018, Google préconise de compiler Linux avec Control-Flow Integrity. Avec la version 5.13 de Linux qui pointe le bout de son nez, l'utilisation de CFI devrait être d'autant plus accessible.

En conclusion, AOSP moderne propose un modèle de sécurité robuste, qui n'est pourtant respecté que par la propre distribution de Google sur ses smartphones Google Pixel. Les autres constructeurs ont tendance à modifier le système et affaiblir ce modèle, de même que les distributions alternatives communément appelées ROMs customs.

GrapheneOS se veut être rigoureux dans sa manière d'utiliser AOSP. GrapheneOS est donc conservatif du modèle de sécurité de ce dernier, et ne vise qu'à le renforcer tout en proposant un OS très fonctionnel et respectueux de la vie privée.

Les Google Play Services

Une question légitime revient souvent :

GrapheneOS est-il donc degoogled ?

AOSP ne contient pas (ou très peu) de code lié aux services Google. Ceux-ci sont proposés dans un code propriétaire sous le nom de Google Play Services. GrapheneOS ne les contient pas, et ne vise pas à fournir une implémentation alternative (microG n'étant pas une bonne idée).

GrapheneOS est de facto épuré des services Google, et n'a pas besoin de chercher à se déclarer degoogled. Les Play Services ajoutent une surface d'attaque en plus d'être invasifs, donc c'est un aspect positif de cela.

Puis-je utiliser microG quand même ?

Ce n'est pas supporté car l'OS doit explicitement autoriser du signature spoofing. Ce n'est pas suggéré non plus pour les raisons évoquées ci-dessus, microG étant une implémentation très imparfaite. Concrètement, vous devrez vous passer complètement des Play Services.

Est-ce si difficile de vivre sans, et quelles sont les conséquences ?

Nous le verrons un peu plus bas avec mon retour personnel. De plus, ce problème d'accessibilité est en passe d'être résolu avec la future possibilité d'installer directement les Play Services de façon non-privilégiée.

GrapheneOS et Play services : comment ça marche ?
GrapheneOS a récemment développé une méthode de compatibilité avec les Google Play services, permettant d’accroître sa compatibilité avec les applications Android. Regardons en détails le fonctionnement de cette méthode alternative.
Et c'est chose faite en ce mois d'août 2021 !

Les appareils supportés (en 2021)

GrapheneOS ne supporte à l'heure actuelle que les smartphones Google Pixel. C'est parfois un sujet d'incompréhension que j'ai déjà traité dans mes articles, mais il n'est pas une mauvaise chose de revenir une nouvelle fois dessus. En somme, les Google Pixel :

Ces critères non-exhaustifs sont importants afin de respecter le modèle de sécurité pensé par Google pour AOSP. GrapheneOS choisit donc de supporter les Google Pixel mais ce n'est nullement définitif : si un autre appareil venait à supporter l'ensemble de ces critères, il pourrait être supporté également à condition d'avoir le support derrière.

N'est-ce pas ironique d'acheter un smartphone Google pour ne pas utiliser leurs services ?

Certains y perçoivent une forme d'ironie : acheter un smartphone Google pour finalement ne pas utiliser les services Google.

Qu'est-ce que cela change si c'était Samsung ou Xiaomi ? Strictement rien, ces critères sont choisis objectivement. L'idée à long terme est bien entendu pour GrapheneOS de travailler directement avec des constructeurs pour proposer des appareils alternatifs remplissant ces critères.

Pour qui, au final ?

Je le répète souvent : il convient à chacun d'évaluer son modèle de menace. Mais il se trouve que GrapheneOS conviendrait à de nombreuses personnes : des personnes travaillant dans des environnements sensibles aux enthousiastes de la sécurité informatique, en passant par des simples personnes qui souhaitent un système épuré, fonctionnel et sûr.

Selon moi, GrapheneOS conviendrait à un très large panel de profils aux modèles de menace différents. La seule contre-indication me venant à l'esprit est l'utilisation d'applications qui ont une dépendance forte sur les Play Services (quelques réseaux sociaux et applications bancaires).

GrapheneOS vise cependant à être simple d'utilisation, sécurisé out-of-the-box et propose même quelques ajouts à AOSP pour être plus agréable à utiliser. C'est donc un OS pleinement fonctionnel qui cherche à proposer un compromis qui n'existe nul part ailleurs. Avec Android, vous êtes bien plus libres en choix d'applications qu'avec iOS par exemple.

Les mesures de renforcement

Nous avons vu que GrapheneOS est conservatif du modèle de sécurité d'AOSP, au contraire de distributions alternatives d'Android (OEMs et ROMs customs). Partant de cette fondation déjà robuste, qu'est-ce que GrapheneOS apporte concrètement ? Quelles sont ses mesures de renforcement ?

Globalement, GrapheneOS est un OS minimal mettant l'accent sur la protection contre les vulnérabilités liées à la mémoire, donc encore une fois je suggère la lecture de cet article très important :

Buffer overflow & consort : tout ce que vous devez savoir
De nombreuses vulnérabilités dans les systèmes informatiques sont liées à des erreurs de gestion de la mémoire, permises entre autres par l’utilisation de langages de bas-niveau répandus tels que le C et le C++. En 2019, elles constituaient pour Microsoft environ 70% des vulnérabilités traitées.

Avertissement: cette partie sera relativement technique. N'ayez pas peur si vous ne comprenez pas tout.

Renforcement de Linux

GrapheneOS utilise linux-hardened, une série de patchs qui visent à renforcer la sécurité de Linux :

Quelques bricoles pour renforcer Linux : ASLR, lockdown, PTI (Spectre/Meltdown)...
Linux a lui aussi droit à son confinement ! Nous allons voir quelques paramètres non-exhaustifs pour renforcer sa sécurité.

Parmi les mesures de renforcement, on peut noter que le support des modules dynamiques est désactivé, et un nombre minimal de modules est conservé permettant de réduire la surface d'attaque. Certaines fonctionnalités sont restreintes telles que perf et ptrace.

ASLR (Address Space Layout Randomization) est également renforcé : l'entropie est augmentée de 24 à 33 bits. C'est une des mesures visant à renforcer la protection contre les vulnérabilités liées à la mémoire.

D'autres protections sont mises en place telles que des mitigations contre les use-after-free via des mécanismes de zeroing. Toutes les allocations de la stack du kernel sont initialisées par zéro, prévenant de certaines vulnérabilités.

Renforcement de l'allocateur de mémoire

L'allocateur de mémoire est entre autres responsable de l'allocation dynamique de la mémoire dans le tas (heap) qui fournit par exemple les standards d'allocation en C (malloc et free, etc.). Nous avons mentionné son importance pour contrer des vulnérabilités liées à la mémoire (heap overflow, use-after-free, double free) dans un article précédent.

Jusqu'à Android 11, Android utilisait jemalloc. Depuis Android 11, c'est scudo qui est utilisé pour tous les appareils disposant de la mémoire nécessaire, et propose des mitigations supplémentaires.

GrapheneOS choisit d'utiliser son projet maison, hardened_malloc :

GrapheneOS/hardened_malloc
Hardened allocator designed for modern systems. It has integration into Android's Bionic libc and can be used externally with musl and glibc as a dynamic library for use on other Linux-based pl...

Hardened Malloc est sans aucun doute le seul allocateur qui met la sécurité autant en avant. Il est basé sur la conception de l'allocateur d'OpenBSD et renforce substantiellement tous les aspects des allocateurs classiques.

Hardened Malloc n'est pas seulement un outil de mitigation mais aussi un outil qui permet de reporter des problèmes aux développeurs. Si une application s'avère ne pas fonctionner correctement à cause de Hardened Malloc, c'est que ce dernier vous a protégé d'un bug de mémoire dans l'application en question, qu'il faut reporter au développeur avec les logs.

Renforcement des lancements de processus

Pour lancer des applications, Android utilise le modèle Zygote. L'avantage de Zygote est entre autres d'accélérer le temps de démarrage à froid des applications, et ceci passe par le biais de la création d'un modèle de données qui est créé au démarrage d'Android et réutilisé à chaque fois qu'une application est lancée pour l'ensemble des profils (avec fork()).

Sci-Hub | From Zygote to Morula: Fortifying Weakened ASLR on Android
En embryologie, la cellule zygote est le nom donné à l'oeuf fécondé qui, au terme de sa division cellulaire, produira la morula (stade précoce de l'embryon qui ressemble à une mûre).

De façon très succincte, le modèle Zygote résulte dans des applications qui partageront des données telles que l'adressage de mémoire, ce qui par nature affaiblit des mitigations probabilistes telles que ASLR ou les canaries. Une étude de 2014 analyse et explique les défauts (et avantages) de Zygote, en montrant des exemples d'attaques potentielles. Ce problème est commun à de nombreux OS, dont iOS (Dyld Shared Cache).

GrapheneOS choisit d'utiliser execv() pour créer des nouveaux processus quand des applications sont lancées : chaque application disposera ainsi de ses propres données initiales, la randomisation ayant lieu à nouveau au lieu d'être "copiée" du modèle prédéfini au démarrage. ASLR n'est donc plus seulement déterminé au démarrage du système, mais au démarrage de chaque application, ce qui rend des exploits plus difficiles.

Ce changement a peu de répercussions négatives excepté notamment sur le démarrage à froid d'une application (~100ms supplémentaires en moyenne). Il est à noter que GrapheneOS prévoit d'optimiser la chose en adoptant un modèle très similaire au modèle "Morula" du papier cité précédemment.

D'expérience, il a été constaté que ce changement ne se remarque réellement que sur des appareils qui ont un CPU peu puissant et un disque lent (mémoire eMMC au lieu de UFS), comme le Pixel 3a.

La balance bénéfices/coût est largement en faveur de cette mesure qui renforce la sécurité : il est peu probable que vous remarquiez les dégradations de performances sur des appareils modernes. De plus, elle n'affecte aucunement la performance de l'application elle-même.

Autres renforcements

Cette liste est non-exhaustive, veuillez consulter :

GrapheneOS features overview
Overview of GrapheneOS features differentiating it from the Android Open Source Project (AOSP).

Ces renforcements ne sont pas forcément visibles par l'utilisateur final mais protègent contre plusieurs familles de vulnérabilités.

Les fonctionnalités de sécurité et de vie privée

GrapheneOS implémente également des fonctionnalités supplémentaires par rapport à AOSP. Ces changements sont quant à eux appréciables directement par l'utilisateur final et sont importants dans l'écosystème sécurisé et minimaliste que GrapheneOS tente de bâtir.

Vanadium

Vanadium est le navigateur par défaut de GrapheneOS, basé sur Chromium ; il s'occupe également de servir la WebView qui est utilisée par les applications pour servir du contenu web. C'est donc une composante cruciale et il est recommandé de ne pas utiliser un autre navigateur.

GrapheneOS/Vanadium
Privacy and security enhanced releases of Chromium for GrapheneOS. Vanadium provides the WebView and standard user-facing browser on GrapheneOS. It depends on hardening in other GrapheneOS reposito...

Vanadium est renforcé par rapport à une distribution standard de Chromium sur mobile et force l'isolation stricte par site peu importe la mémoire disponible de l'appareil, ce qui garantit une sandbox optimale. Vanadium choisit également des paramètres renforcés de compilation tels qu'un CFI granulaire basé sur le type, la Stack Smashing Protection, une initialisation de toutes les variables, etc.

Vanadium est également configuré pour une vie privée basée sur le principe du blend in. En d'autres termes, Vanadium ne doit pas ou peu se démarquer des autres utilisateurs de Chrome sur Google Pixel. Il partage également quelques mesures d'anti-fingerprinting avec Bromite. Par exemple, l'API de Chromium Battery Status ne donne pas d'informations non-nécessaires.

Depuis une mise à jour ayant eu lieu en Juin 2021, Vanadium permet d'être utilisé en mode JIT-less. Le JIT (just-in-time compiler) est depuis plusieurs années un standard répandu dans les navigateurs qui permet une amélioration significative des performances en compilant du code JavaScript au lieu de l'interpréter à la volée.

Le JIT est une surface d'attaque souvent visée et exploitée.
Juste à temps ! Mais à quel prix ? Le JIT et ses problèmes...
Vous arrivez juste à temps ! Parlons de la compilation JIT pour just-in-time, ou dynamique : une stratégie d’exécution de code très répandue dans nos navigateurs Web mais qui n’est pas sans défauts pour la sécurité.

Cependant le JIT constitue une violation à W^X : on ne devrait pas écrire dans un espace mémoire ensuite exécuté. Il y a donc des implications en matière de sécurité, et bien que le JIT améliore les performances, c'est au prix de la sécurité également. Il convient à vous d'essayer de voir si vous pouvez vous passer du JIT grâce à un bouton prévu à cet effet dans Vanadium.

PDF Viewer

Le format PDF est commun, mais représente pourtant un vecteur d'attaque pour les interpréteurs. GrapheneOS choisit d'inclure une application sécurisée et simple qui permet de consulter des PDF, renforcée grâce à la sandbox fournie par la WebView de Vanadium.

GrapheneOS/PdfViewer
Simple Android PDF viewer based on pdf.js and content providers. The app doesn't require any permissions. The PDF stream is fed into the sandboxed WebView without giving it access to content or...

Cette application ne demande d'ailleurs aucune permission. Le code du rendu des PDFs est écrit dans un langage memory-safe. Quand bien même un attaquant réussirait à compromettre le rendu, il serait contenu dans la sandbox de Vanadium sans aucun accès extérieur.

La permission "capteurs" (sensors)

Par rapport à Android, GrapheneOS ajoute une permission supplémentaire relative à l'utilisation des capteurs qui sont aujourd'hui très nombreux : gyroscope, accéléromètre, magnétomètre, baromètre, etc.

Cette permission n'existe pas vraiment de base pour les applications (ce qui est dommage). Ce que fait donc habilement cette permission, c'est de fournir des données nulles (zéro) au lieu des données réelles mesurées.

Ok, très bien... mais pourquoi au juste ?

Il existe des considérations en matière de vie privée : l'utilisation de ces capteurs peut être détournée non seulement à des fins de collecte de données non-souhaitées concernant votre activité, mais de manière bien plus vicieuse également. Voici quelques études à ce sujet :

Par défaut, et pour des raisons de compatibilité, cette permission sera toujours activée. Mais quand vous faites face à une application qui n'est pas forcément de confiance et qui n'a pas besoin de cette permission, n'hésitez donc pas à la désactiver.

La permission "réseau" (network)

De la même façon, cette permission n'existe pas normalement sur Android, ou plus précisément ne propose pas de paramètre accessible et visuel. GrapheneOS utilise ici la permission INTERNET qui existe déjà pour les applications, l'améliore et en fait une permission utilisable directement par l'utilisateur final.

Cette permission réseau peut couper l'accès à tout type de réseau pour une application, y compris localhost (prévenant ainsi des fuites entre plusieurs profils).

Google Camera : j'aime l'utiliser, mais on n'est jamais trop sûr…

Cette approche est bien plus robuste qu'une autre telle que NetGuard. Il faut néanmoins garder à l'esprit que cette permission ne peut pas empêcher une application de communiquer avec une autre par une API au sein d'un même profil (avec consentement mutuel). Une solution est d'utiliser plusieurs profils si nécessaire. Cette permission n'exempt donc pas de faire attention aux autres.

PIN scrambling

L'authentification biométrique est utile car elle permet de protéger son moyen d'authentification principal des shoulder surfing attacks : un terme compliqué pour simplement désigner le fait qu'on puisse vous observer en train de taper votre PIN...

J'ai testé : une horreur quand on est bourré !

Le PIN scrambling permet un affichage de saisie de PIN aléatoire, ce qui pourrait en théorie protéger contre quelques formes de shoulder surfing (restriction d'angles, empreintes sur l'écran, vibrations). Je ne pense pas que ce soit indispensable, mais c'est sympathique. Bien sûr, c'est à activer soi-même, ce n'est pas activé par défaut.

Indicateurs de caméra/microphone

Lorsqu'iOS 14 nous a présenté ces indicateurs, nous voulions tout de suite la même chose pour Android. Google n'a pas tardé, en réalité, puisqu'il l'a ajouté tardivement dans les sources d'Android 11 : GrapheneOS se contente de les activer par défaut.

En réalité, ce n'est pas un ajout si important que cela. AOSP moderne est déjà très restrictif de base quant à l'utilisation de la caméra : il n'est pas possible de l'utiliser facilement par une application en arrière-plan.

Vie privée sur les points d'accès réseau

GrapheneOS garantit une vie privée de haut niveau quant à l'utilisation de réseaux Wi-Fi, en particulier sur les Google Pixel. D'abord parce que les Google Pixel disposent d'une implémentation particulièrement robuste de la randomisation d'adresses MAC.

Sur l'OS stock des Pixel, le comportement par défaut est d'utiliser une adresse MAC randomisée unique par réseau. Dans GrapheneOS, il y a un autre choix utilisé par défaut : une adresse MAC randomisée sera générée à chaque connexion. En parallèle, le client DHCP est configuré pour n'envoyer aucune information identifiable.

Du fait de l'isolation de la baseband grâce à la configuration stricte de l'IOMMU au sein du SoC Qualcomm, il est possible d'utiliser son smartphone en Wi-Fi only. Il suffit pour cela d'activer le mode avion, puis d'activer le Wi-Fi ensuite. Cela permet d'empêcher la triangulation par nature du réseau mobile : pas vraiment besoin d'un killswitch.

GrapheneOS propose d'ailleurs un mode LTE-only. En théorie, il permet d'éviter certaines formes d'interceptions et l'utilisation de réseaux peu sécurisés comme la 2G. Cependant, VoLTE sera nécessaire pour passer les appels, et en France on pêche dessus (comme toujours).

Auditor : vérification continue de l'intégrité

GrapheneOS embarque une fonctionnalité d'attestation : Auditor. Auditor a été développé principalement pour GrapheneOS mais est aussi compatible avec d'autres appareils/distributions compatibles.

Vérificaton à distance sur attestation.app

Auditor permet de vérifier l'intégrité du système d'une façon qui ne peut être contournée ou modifiée par l'OS, car Auditor communique directement avec les enclaves sécurisées que sont par exemple TEE (Trusted Execution Environment sur les SoC ARM) ou HSM (Hardware Security Module = éléments sécurisés comme Titan M).

La vérification peut se faire localement, ou bien à distance avec le service attestation.app proposé : ces informations seront envoyées régulièrement (toutes les 4 heures), et une alerte par mail sera envoyée en cas de changement suspect de l'intégrité du système.

Il est conseillé de faire l'appareillage dès que possible car ce dernier repose sur le principe du trust on first use. La première vérification n'est donc pas vraiment significative, mais les vérifications subséquentes le seront.

Seamless updater : mises à jour transparentes

La garantie de mises à jour rapides et régulières est indispensable au modèle de sécurité. GrapheneOS emploie son propre service qui est simple et peu intrusif, et qui recherche automatiquement des mises à jour toutes les 4 heures en arrière-plan. Ces mises à jour sont évidemment incrémentales et automatiques : on ne télécharge que ce qui est nécessaire.

Une interruption ne pose pas de problème : la mise à jour reprend dès que la connectivité est disponible.

De même, une interruption pendant l'installation ne pose pas de problème particulier puisque la mise à jour se fait sur une seconde installation de GrapheneOS qui deviendra active seulement après la fin de la mise à jour. Après le redémarrage, si la nouvelle version n'arrive pas à démarrer, il y a un mécanisme de rollback vers la version précédente.

Il va sans dire que GrapheneOS lui-même adopte les mises à jour upstream très rapidement : dès la parution du bulletin mensuel pour les mises à jour de sécurité, et quelques semaines tout au plus pour les versions majeures (la transition vers Android 11 fut assez rapide). Certains fix sont même adoptés en amont avant leur distribution sur l'OS stock.

Autres mesures et fonctionnalités

  • Vérification de connectivité avec un serveur maison plutôt que Google
  • Les nouveaux périphériques USB ne sont pas autorisés avant unlock
  • Intégration de Seedvault : backups chiffrés compatible Nextcloud
  • Utilisation d'un serveur HTTPS pour synchroniser pour l'horloge
  • Compilation AOT au lieu de JIT pour les applications
  • Redémarrage automatique quand le smartphone n'est plus utilisé (*)
  • Désactivation automatique du Bluetooth après un timeout

* Cette fonctionnalité est utile dans le cas où votre smartphone est égaré (après un timeout) afin de s'assurer que le chiffrement est en état de repos, limitant ainsi des tentatives de cold boot pour récupérer les clés.

De manière générale, GrapheneOS ne souhaite ajouter que le strict nécessaire. C'est un choix de ne pas inclure des applications par défaut car celles-ci peuvent être recommandées un jour puis devenir obsolètes le lendemain, avec des implications.

L'ensemble des serveurs nécessaires au fonctionnement de GrapheneOS est hébergé sur des machines virtuelles et dédiées louées chez OVH sans tierces parties (pas de CDNs, pas de miroirs, etc.). Des standards de sécurité robustes sont mis en place (configuration TLS, DNSSEC/DANE, OCSP, CAA, etc.). Toute l'infrastructure est transparente et documentée.

Toutes les connexions par défaut de l'OS sont aussi documentées.

Installer GrapheneOS

Vous devez posséder un appareil compatible, au temps d'écriture de cet article (visiteurs du futur, consultez le site officiel) :

  • Pixel 5
  • Pixel 4a & 4a 5G
  • Pixel 4 & 4 XL
  • Pixel 3a & 3a XL
  • Pixel 3 & 3 XL

Ensuite, je me contente de vous renvoyer à la page officielle :

GrapheneOS installation
Installation instructions for GrapheneOS, a security and privacy focused mobile OS with Android app compatibility.

Vous avez deux possibilités à ce jour :

  • Utiliser l'installateur WebUSB (conseillé pour tout le monde)
  • Procéder à l'installation en CLI (uniquement si contre-indication)

L'installateur WebUSB ne fonctionne que sur des navigateurs Chromium-based, Firefox n'implémentant pas cette fonctionnalité. C'est une façon d'installer accessible, simple, sûre et rapide.

Les instructions sont détaillées et maintenues à jour sur le site officiel. Ne suivez pas de guide tiers (et encore moins de vidéos sur YouTube). En cas de problème lié à l'installation ou autre, n'hésitez pas à rejoindre le channel Matrix (#grapheneos:grapheneos.org).

Utiliser Android sans Google

A l'usage, GrapheneOS s'utilise la majorité du temps comme une autre distribution d'Android sans Google Play Services.

Moi du futur : notez que depuis la possibilité d'installer les Play services, la situation a évolué. Il y a une bien plus grande liberté d'utilisation.

Les applications : démystification

Comme vous pouvez le voir ci-dessus, j'utilise Spotify. J'utilise également d'autres applications telles que Discord. Bien sûr, j'utilise autant d'alternatives pensées sans Play Services, mais parfois on n'a pas le choix.

Quoiqu'il en soit, peu d'applications ne fonctionneront pas du fait de l'absence de Google Play Services, même si cela reste une portion non-négligeable et qu'il faut en tenir compte. Il faudra parfois réévaluer un besoin, trouver une alternative ou encore faire des concessions.

Les applications qui ne fonctionnent pas ont une dépendance forte avec les Play Services pour une raison (SafetyNet) ou pour une autre. Ces applications sont par exemple Instagram, Snapchat, qu'on ne regrettera pas vraiment. En revanche, certaines applications bancaires refusent catégoriquement de fonctionner sans Play Services, c'est le cas de Crédit Mutuel.

Ensuite, certaines applications fonctionneront partiellement car elles ont une dépendance partielle. Par exemple, si elles dépendant sur l'API Google Maps, cette fonctionnalité sera logiquement cassée. Donc si une application est affichée "dépendante", il n'est pas improbable qu'elle fonctionne bien pour votre utilisation (consultez ici un tableau communautaire).

Il est à noter que GrapheneOS travaille actuellement sur une implémentation minimale (stub) et sans privilèges qui fera croire à des applications que les Play Services sont présents mais que les serveurs sont down. Cette mesure viserait à rendre certaines applications compatibles.

Une révolution pour (très) bientôt...

Mise à jour apportée en Juillet 2021.

Finalement, il sera bientôt possible d'installer les Play Services sur GrapheneOS de façon sûre : les Play Services ne seront pas privilégiés dans le système et pourront être installées au cas par cas dans un profil utilisateur. Vous pourrez ainsi avoir un profil principal sans Google, mais un autre profil avec les Play Services pour vos applications qui en ont besoin. Et contrairement à microG, tout sera pleinement implémenté (à terme).

Cela devrait être une petite révolution pour GrapheneOS : l'absence de Play Services était un problème d'accessibilité majeur. Maintenant, vous aurez le choix de les utiliser ou non, et si vous décidez de les utiliser, ils seront contenus dans la sandbox de l'OS telles une application classique qui peut être installée ou non dans un profil utilisateur.

Vous pouvez en savoir plus en lisant ces annonces sur Twitter :

Je vous tiendrai au courant par le biais d'un nouvel article, probablement (août 2021 : c'est fait !). Vous pouvez toujours suivre l'évolution du projet en détails par vous-même en suivant le compte Twitter officiel de GrapheneOS. Cette fonctionnalité (au stade d'expérimentation actuellement) est également documentée sur le site.

Les notifications push

Les Google Play Services implémentent un système de push (FCM/GCM) qui permet aux développeurs d'implémenter cette fonctionnalité simplement, tout en étant efficiente en termes de consommation sur le smartphone. L'absence de Play Services implique l'absence de cette fonctionnalité.

En conséquence, de nombreuses applications ne pourront plus proposer de notifications push  - mais pas toutes. En effet, certaines d'entre elles telles que Signal implémentent un fallback sur un websocket qui servira la même fonction. Outre Signal, FairEmail, WhatsApp et même Facebook (sans commentaire) le font.

GrapheneOS Frequently Asked Questions
Answers to frequently asked questions about GrapheneOS.

Les applications concernées demanderont une exception d'optimisation de la batterie (cette optimisation empêche concrètement une application d'avoir un service en arrière-plan). N'hésitez pas à communiquer aux développeurs que cette possibilité existe, et qu'elle peut être relativement triviale à implémenter pour ne plus dépendre d'un service propriétaire.

Les marchés d'application

Pour une expérience Android sans Play Services, je conseille ces deux marchés d'applications :

  • Aurora Store : un front-end soigné pour le Play Store. Oui, vous avez bien lu : vous pouvez accéder, installer, et mettre à jour des applications réservées normalement au Play Store.
  • F-Droid : le marché d'applications FOSS (free & open-source softwares) qu'on ne présente plus. Il a eu quelques problèmes par le passé (notamment avec les formats de signature qui restaient en v1), mais on l'aime quand même.
Conseil pour Aurora Store : révoquez sa permission stockage et désactivez Downloads > Use external storage, pour n'utiliser que son stockage interne et isolé des autres applications. Cela empêche certaines attaques.

Certaines applications telles que Signal peuvent être récupérées directement sur le site web de leur développeur. Certains développeurs maintiennent leur propre dépôt compatible avec F-Droid, comme Bitwarden ou NewPipe.

Android 12 facilitera l'usage de ces marchés alternatifs. Par ailleurs, GrapheneOS projette de créer son propre marché qui abritera les mises à jour de certaines composantes du système, et proposera aussi quelques builds d'applications tierces.

Souvenez-vous à titre informatif et pratique : AOSP a un modèle de sécurité robuste pour ses applications. Chaque application est signée, donc ne peut être mise à jour que par une .apk avec une signature correspondante. Enfin, AOSP empêche les downgrades : il n'est pas possible de revenir à des versions antérieures sans réinstaller complètement.

Les alternatives aux services classiques

On ne va pas se mentir, entre nous, Google Maps c'est bien pratique. En soi, l'application fonctionne sans Play Services avec quelques fonctionnalités en moins. Une solution encore moins invasive est d'installer la PWA (Progressive Web App). Personnellement, je l'utilise en complément de Magic Earth, une application qui utilise OpenStreetMap. Transportr est également très pratique pour consulter les horaires de transports.

Quant à Google Drive et les autres services de synchronisation pratiques, j'utilise simplement Nextcloud avec DAVx⁵ et je conseille également Syncthing et EteSync. Vous pourriez également considérer un serveur Jellyfin au lieu de souscrire à des abonnements chez Netflix et consort. Et au passage, un serveur Miniflux peut être plus qu'utile avec les divers clients Fever disponibles sur Android.

En plus de ce que j'ai déjà mentionné, pour des besoins "standards" :

Ce sont mes recommandations personnelles, et non celles du projet GrapheneOS. J'ai mes propres besoins, je fournis ces exemples à simple but informatif. Généralement, j'apprécie les applications simples et modernes.

VPN et blocage de publicités

Tout d'abord, ces articles sont les bienvenus dans ce contexte :

Empreinte numérique : une question d’entropie
Non, je ne vais pas faire un cours sur l’équation de Boltzmann. Mais on va parler de votre empreinte numérique et ce qui fait le caractère unique de votre personne sur Internet.

Gardez en tête que le filtrage par blacklisting peut vous rendre plus unique.

Les VPNs et leur mésusage
Les VPN sont aujourd’hui des outils bien connus du grand public. Leur intérêt est toutefois questionnable, et leur usage est souvent loin d’être optimal.

Un VPN est un outil fantastique s'il est bien compris et utilisé. L'article explique bien qu'il est fortement conseillé d'utiliser le DNS fourni par son prestataire VPN pour ne pas se démarquer des autres utilisateurs. Si vous utilisez un VPN, et que vous souhaitez bloquer les publicités et trackers pour un confort supplémentaire, choisissez un prestataire qui propose cette option.

Si vous n'utilisez pas un VPN, dans ce cas vous pouvez utiliser la fonctionnalité Private DNS d'Android qui en d'autres termes signifie DNS-over-TLS. Vous pouvez par exemple utiliser dns.adguard.com ou NextDNS pour un blocage plus ou moins granulaire. Notez que cette fonction prend prévalence sur les DNS d'un VPN, donc faites très attention si vous l'utilisez avec ce dernier : ne vous rendez pas plus unique que nécessaire.

Si vous souhaitez bloquer les publicités seulement dans le navigateur, Bromite est une option. Vanadium reste la première recommandation, mais Bromite est reconnu comme the next best thing (que je conseille à tous ceux qui n'utilisent pas GrapheneOS d'ailleurs). Concernant YouTube, nous avions parlé de NewPipe.

Google Camera

C'est effectivement dommage d'utiliser un Google Pixel sans pouvoir profiter pleinement de son appareil photo numérique. Google Camera reste une application propriétaire qu'il vaut mieux ne pas utiliser si possible : utilisez l'application AOSP par défaut ou encore OpenCamera.

Cependant, Google Camera ne demande pas encore de dépendances fortes sur les Play Services, et fonctionne encore à l'heure actuelle sur GrapheneOS grâce à Gcam Services Provider : cette application simule la présence des Play Services (mais n'implémente rien : stub) seulement pour Google Camera afin qu'elle puisse fonctionner. Je conseille également de désactiver les permissions réseau de Google Camera.

Mise à jour : depuis la possibilité offerte par les sandboxed Play services, cette dernière devient la façon recommandée d'utiliser Google Camera. Il n'est pas nécessaire d'installer entièrement les Play services pour que cette application fonctionne, en effet seul GSF suffit et fait exactement la même chose que l'implémentation non-officielle citée ci-dessus.

Les user profiles

C'est une fonctionnalité propre à AOSP mais qui n'est pas activée chez de nombreuses distributions. GrapheneOS non seulement veille à l'activer mais encourage son utilisation pour des fins de compartimentalisation.

Quelle est la différence avec Shelter/Island ?

Shelter (ou apparenté) gère des work profiles qui sont différents et n'offrent pas du tout une isolation comparable. Les work profiles sont une fonctionnalité de confort plutôt que de sécurité/vie privée.

Les user profiles quant à eux sont pensés pour être isolés entre eux :

  • Chaque profil a des clés de chiffrement différents. Quand un profil secondaire est déconnecté, les clés sont éjectées de la mémoire.
  • Grâce au fonctionnement de Titan M et de l'API Weaver, la mémoire d'un profil est complètement inutilisable après sa suppression.
  • Les applications ne peuvent pas communiquer entre différents profils quand leur permission réseau est révoquée (IPC).

Il y a cependant quelques spécificités à prendre en compte :

  • Ce n'est pas visible par défaut, mais une application est installée pour tous les profils. Un profil ne peut pas installer une même application avec une version antérieure ou une signature différente.
  • La connectivité à un VPN est déterminée par le profil actif. Pour limiter les fuites, il faut configurer le même VPN sur tous les profils.

Les user profiles constituent donc un outil puissant permettant de compartimentaliser l'usage de son smartphone. Gardez en tête également que toutes les applications sont sandboxées même au sein du même profil, sous réserve de bien gérer les permissions octroyées.

L'autonomie

En théorie, l'autonomie devrait être meilleure car l'OS n'embarque pas de bloatwares et services Google. De plus, la compilation à l'avance des applications (au lieu du JIT) permet un fonctionnement plus économe.

Mais ce gain peut être compensé négativement par :

  • L'utilisation du GPS pour la localisation. Sur l'OS stock, les Play Services peuvent être utilisés pour géolocaliser, ce qui est un poil plus économe.
  • Les applications qui doivent compenser l'absence de serveurs Google pour les notifications push, en ouvrant un websocket comme Signal.

En pratique, j'ai une très bonne autonomie et je peux utiliser mon smartphone plusieurs jours sans charger avec mon utilisation (légère).

Quelques conseils

  • Installez le moins d'applications possibles, juste le nécessaire
  • Installez les mises à jour (OS + apps) dès que possible
  • N'octroyez que les permissions nécessaires à une application
  • N'octroyez pas les services d'accessibilité sauf si indispensable
  • Compartimentalisez avec des profils utilisateurs
  • Veillez à ce que les option de développeurs soient inactivées
  • Redémarrez régulièrement pour profiter de verified boot

Avec tout cela, je vous souhaite une excellente expérience ! GrapheneOS est sûr out-of-the-box, donc vous n'avez pas grand chose à configurer, et vous devriez même éviter de changer un paramètre dont vous n'êtes pas sûr des répercussions.

Un an avec GrapheneOS

Mon avis sur l'utilisation de GrapheneOS ne change pas par rapport au précédent article : j'en suis pleinement satisfait. Je n'utilise pas un smartphone pour beaucoup de choses en réalité, mais GrapheneOS n'en demeure pas moins un OS très fonctionnel.

Les premières semaines, je me demandais comment j'allais vivre sans les notifications Discord (que je dois utiliser pour certains cercles d'amis). Finalement, j'ai appris à vivre sans et cela a même un aspect positif : je suis bien plus tranquille. Je ne peux être dérangé que par Signal, sur lequel j'ai pu retrouver l'ensemble de mes contacts après les avoir sensibilisé.

Du coup, je n'utilise même plus le réseau mobile chez moi : je le coupe avec le mode avion pour utiliser mon Pixel en mode Wi-Fi only. Je ne l'active que quand c'est nécessaire. J'utilise également très peu de services tiers, et ce que j'estime possible à héberger moi-même, je l'héberge.

Enfin, je ne sais pas vraiment quoi vous dire d'autre, c'est devenu tellement naturel pour moi d'utiliser Android sans Play Services. Malheureusement, ma banque est le seul obstacle à ce rêve, donc j'utilise un iPad en complément pour certaines tâches du genre. Avec un peu de chance, votre banque ne vous emmerdera pas autant (et sinon, j'emmerde les banques).

Si vous avez des questions particulières, j'y répondrai avec plaisir.

Conclusion

GrapheneOS n'est pas seulement un OS, aussi intéressant soit-il pour moi : mais une nébuleuse de projets et de connaissances liées à la sécurité et la vie privée. J'ai appris énormément depuis que je connais le projet, et aujourd'hui à mon tour je partage ce que j'ai appris, que ce soit sur ce blog ou sur les channels du projet. Je fais évidemment mes propres recherches, et j'aspire à devenir un contributeur encore plus investi.

Nous avons constaté au cours de ces derniers articles que la sécurité moderne repose sur le modèle Zero Trust, avec une défense en profondeur ; d'où l'importance d'un modèle de sécurité élaboré et robuste, comme AOSP, et d'autant plus renforcé par GrapheneOS, qui est à ce jour selon moi l'un des OS qui offre tout simplement le meilleur compromis sécurité/fonctionnalité.

Mais GrapheneOS est également tourné vers l'avenir, et ne dépend pas forcément d'AOSP ou encore des Google Pixel. Par exemple, il est prévu à terme que le projet développe ses propres appareils sécurisés en partenariat avec des constructeurs. Il est également prévu de s'intéresser aux microkernels tout en conservant une couche de compatibilité Linux. Autre exemple à plus court terme, gVisor est considéré pour renforcer la sandbox des applications, quand il sera jugé suffisamment utilisable.

Initialement développé par le chercheur en sécurité Daniel Micay, GrapheneOS dispose désormais des moyens nécessaires pour rémunérer ses développeurs. Je suis donc aujourd'hui très confiant quant à l'avenir du projet qui a connu des heures sombres, mais est désormais sur la bonne voie.

En espérant, comme toujours, que cet article aura su aiguiller votre curiosité envers ce projet et ses principes.

Ressources