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 ?
Un peu d'histoire
Le modèle de sécurité mobile est apparu bien plus tard que le modèle de sécurité desktop, duquel il se distingue par ses bases modernes, moins permissives et plus soucieuses de la sécurité.
C'est en quelque sorte logique, tantôt le modèle de sécurité mobile doit répondre à des contraintes fortes : l'appareil mobile est ainsi devenu notre troisième main et second cerveau, il nous accompagne lors de nos déplacements ; c'est un condensé de technologie qui en fait un outil formidable mais aussi une cible de choix.
Ce modèle de sécurité se traduit notamment par un système de permissions robuste, une chaîne de confiance, des mitigations modernes, et moins de "permissivité générale" ; ce paradigme moins permissif qualifié de "user-safe". La question se pose toujours : jusqu'à quel degré un OS doit mettre à disposition les outils pour le modifier en profondeur, sachant que cela peut nuire au modèle de sécurité qui a été pensé au départ ?
Android : un OS aux grandes qualités et aux grands défauts
Android est un système open-source (AOSP) développé par Google, qui implémente une politique stricte SELinux, un modèle de sandboxing efficace, et d'autres mitigations telles que le verified boot et le CFI. Android utilise Linux comme son noyau, mais son userspace diffère radicalement de ce que vous trouverez sur des distributions GNU/Linux.
Android reste en soi une distribution de Linux au même titre que les autres, mais cette fois-ci avec un modèle de sécurité élaboré sur des bases modernes. L'ensemble des applications sont signées et contenues dans une sandbox avec des accès restreints par un modèle de permissions qui s'affine au fil des versions.
Je propose aux plus intéressés de lire ce passage en revue de l'ensemble du modèle de sécurité d'Android moderne par des ingénieurs de Google.
Trusted-on-boot
L'implémentation de la vérification d'intégrité au démarrage est Android Verified Boot sur Android, que j'appelle simplement parfois verified boot.
Pourquoi est-ce que verified boot est si important ?
Cela fait plusieurs articles que je le mentionne : verified boot est un pilier fondamental de tout modèle de sécurité moderne. Il permet d'assurer l'intégrité et l'authenticité du système et de la chaîne de démarrage. Ceci à condition que le bootloader demeure verrouillé.
verified boot protège entre autres de toute forme de tentative d'altération que ce soit par un attaquant physique ou non :
- Les attaques evil maid, autrement dit par possession physique.
- La persistance de malwares, de rootkits.
- Les attaques par rollback, qui consistent à retourner sur des versions antérieures du système pour exploiter une faille.
Android et iOS possèdent une implémentation de ce modèle du trusted-on-boot. Si votre appareil dispose d'une forme de verified boot, je vous invite à le redémarrer régulièrement : dans l'éventualité où un attaquant (physique ou à distance) a compromis votre système et gagne en privilèges, verified boot permet de parer à cette attaque et d'éviter des catastrophes.
Protected until first auth
Le principe trusted-on-boot est accompagné du protected until first auth. Android moderne n'utilise plus le chiffrement intégral de disque (FDE), mais le chiffrement par profil (FBE pour file-based) ; oui, Android moderne fonctionne par profils même si votre distribution d'Android n'a pas forcément activé le multi-profils et c'est bien dommage car cette isolation est nettement supérieure à un simple workspace proposé et géré par Shelter.
Une fois le processus d'authentification complété (de façon moderne avec un élément sécurisé), les clés du profil sont dans la mémoire.
Dès lors, on dit que les données sortent de leur état de repos (at rest). Elles sont toujours chiffrées sur le disque, mais elles sont dans un état plus exposé naturellement (les clés sont chargées en mémoire) pour pouvoir être utilisées.
Même quand votre smartphone est verrouillé, en état AFU (after first unlock), vous êtes théoriquement vulnérables à une cold boot attack (qui consiste à geler instantanément la mémoire et profiter de sa rémanence).
Dans un monde idéal (donc pas le nôtre), les applications pourraient au cas par cas pallier ce problème en utilisant le hardware keystore avec setUnlockedDeviceRequired(true) en parallèle d'un respawn de leur processus une fois en IDLE. Certaines applications le font, mais c'est loin d'être le cas de toutes.
Plus exactement cet état AFU concerne un profil sur Android moderne. Sur un iPhone, il n'y a pas de profil donc c'est pour tout le système.
Ce n'est pas réaliste suivant votre modèle de menace, bien sûr, mais gardez ça à l'esprit. En guise de bonne pratique, il vaut mieux se déconnecter du profil (Android 11 éjecte les clés du profil en question de la mémoire) voire éteindre son smartphone quand il n'est pas à être utilisé. C'est d'ailleurs une fonctionnalité récemment implémentée dans GrapheneOS.
La distribution, sa grande faiblesse
Android étant un système ouvert, c'est le candidat de choix pour être accueilli par l'écrasante majorité des smartphones qui fonctionnent actuellement.
Malheureusement, cette forme de qualité est aussi sa grande faiblesse :
- Les constructeurs (OEMs) modifient assez intensivement Android en y intégrant leurs surcouches, des services tiers, qui ne font que contribuer à agrandir la surface d'attaque et introduire des bugs.
- Ces OEMs vont même jusqu'à réduire la sécurité globale : Asus par exemple rend la politique SELinux plus permissive, et beaucoup de smartphones n'implémentent pas verified boot correctement.
- La fragmentation dont souffre énormément Android. Ce n'est pas faute de vouloir aborder le problème en rendant le système modulaire, mais le problème est là, il persiste... De plus les mises à jour d'Android sont une chose, mais les OEMs doivent aussi contribuer pour les mises à jour spécifiques à leur hardware/firmware (est-ce que le constructeur saura prendre la peine de fournir les patchs ?).
Pour résumer :
- Les constructeurs tiers affaiblissent considérablement le modèle de sécurité pensé par Google pour Android.
- La majorité des personnes se balade avec un nid à RCEs (remote code execution) dans leur poche, exploitable par le script kiddie du coin.
Exemple avec OnePlus, historiquement très négligent de la sécurité au profit des "performances" :
OnePlus have been repeatedly discovered to have a broken and vulnerable implementations of verified boot. There are reports of people setting up devices with alternative operating systems using verified boot, but there are also reports of devices as new as the OnePlus 7 Pro having a broken implementation (see comments from 19:42), which provides no visual indication of verification (or not) of the OS, yet will not decrypt user data if the OS is modified.
- Android Privacy and Security - and-priv-sec@hub.libranet.de
Aparté sur les Google Play Services
Android est souvent associé aux Play Services, qui permettent aux services Google de... fonctionner. Les Play Services sont propriétaires, c'est-à-dire que leur code n'est pas ouvert. Ce sont les Play Services qui sont également responsables de toute la télémétrie liée à Google.
Exception faite à certains constructeurs chinois qui remplacent les Play Services par une crèmerie similaire, aucun smartphone Android n'est livré sans, car les Play Services sont perçus comme une plus-value indispensable à l'utilisateur final.
En revanche, les Play Services ajoutent entre autres de la surface d'attaque et vous conditionne à l'utilisation des services Google, ce qui donne une mauvaise image globale à l'écosystème Android qui pourtant ne démérite pas dans de nombreux domaines.
Qu'en est-il de microG ? Est-ce que c'est "sûr" d'utilisation ?
microG est une implémentation open-source des Play Services, souvent utilisée sur des ROMs alternatives pour bénéficier des notifications push gérées par les serveurs Google, par exemple.
Cependant il reste préférable de ne pas utiliser microG si possible :
- microG ne permet pas de gérer la télémétrie Google aussi finement que les Play Services le peuvent (pas d'option pour gérer l'Ads ID)
- microG nécessite une ROM qui supporte du signature spoofing, ce qui peut être très dangereux.
- microG ne supporte pas le certificate pinning utilisé dans la sécurité de l'écosystème Google Play.
Tout comme les Play Services, microG ajoute également une surface d'attaque privilégiée au sein du système.
Google Pixel : Android done right
Il semblerait que seul Google est capable de distribuer Android de façon correcte sur ses propres smartphones.
Outre les Play Services qui sont bien sûr présents, il y a peu de modifications à AOSP et toutes les sécurités sont bien implémentées, jusqu'au hardware-même des Google Pixel qui est pensé pour tirer profit des dernières API disponibles sur Android (exemple avec StrongBox).
Les Pixel ont également un suivi convenable dans le temps et avec transparence : 3 ans en moyenne de mises à jour majeures avec patchs de sécurité livrés chaque début de mois, le tout avec une très grande rapidité. C'est le haut du panier par rapport aux autres constructeurs, mais personnellement je pense que Google pourrait encore mieux faire : quid du rôle de Qualcomm ? Les prochains smartphones avec SoC Qualcomm pourraient donc bénéficier de 4 ans de mises à jour, ce qui est déjà mieux.
Le processeur de bande de base (baseband) est responsable entre autres de toutes les fonctions radios et dispose de sa propre RAM et firmware. Le Wi-Fi et Bluetooth furent historiquement compartimentalisés sur un autre SoC dédié, mais sont intégrés sur les SoC modernes Qualcomm par exemple. L'isolation sur des puces séparées est bien plus complexe qu'elle ne paraît et à la discrétion de l'OS et les drivers ; en pratique, chaotique. Désormais cette isolation hardware est garantie par un IOMMU strict.
Les Pixel sont également les seuls appareils Android que je connaisse qui bénéficient d'un kernel (Linux donc) compilé via clang avec la mitigation Control Flow Integrity.
Je continue à faire l'éloge des Pixel mais cette fois-ci pour une raison qui devrait vous plaire : il est possible de reverrouiller le bootloader avec un OS custom et des clés Android Verified Boot custom.
Le bootloader ne doit être déverrouillé temporairement que pour l'installation d'un firmware custom, mais doit être verrouillé par la suite pour profiter du verified boot, un pilier du modèle de sécurité d'Android moderne.
En somme, vous avez la liberté d'installer une ROM alternative sans compromettre le modèle de sécurité pour autant…
Le verrouillage du bootloader est contrôlé par la paramètre "OEM unlocking" dans les options pour développeurs d'Android. Ce paramètre gère un byte, stocké sur les Google Pixel au niveau de l'élément sécurisé. La vraie protection contre le déverrouillage du bootloader vient cependant du fait que l'état de ce dernier constitue une entrée pour la dérivation de la clé de chiffrement de la partition des données des utilisateurs. Déverrouiller le bootloader reviendrait donc à supprimer tout le contenu du smartphone, rendant vos données inutilisables.
Le danger du root et des ROMs customs
Pour vous débarrasser d'une surcouche ou des Play Services (ou autres modifications invasives du système), vous serez tentés de passer par diverses solutions. Ce sont des initiatives louables mais qui nuisent complètement au modèle de sécurité d'Android.
Le root est à éviter car il brise complètement le modèle de sécurité mobile en introduisant une surface d'attaque majeure : Android se fonde sur le principe du moindre privilège et n'emploie pas lui-même des privilèges non-restreints.
Comme son nom l'indique (les habitués aux systèmes Unix-like comprennent vite), le root donne l'accès total à l'ensemble du système. Si vous introduisez une porte d'une telle ampleur, what could go wrong?
Les ROMs customs telles que LineageOS (successeur spirituel du défunt CyanogenMod) sont étonnamment très négligentes du modèle de sécurité :
- Elles nécessitent par exemple de démarrer avec le bootloader déverrouillé (ce qui empêche verified boot de fonctionner).
- De plus les patchs de sécurité ne sont que partiellement implémentés pour de nombreux appareils, ce qui est assez trompeur. Vous avez idéalement les dernières mises à jour Android, mais pas les mises à jour pour votre hardware/firmware.
- Enfin, de nombreux appareils "supportés" par LineageOS dépendent de builds userdebug qui exposent une surface d'attaque supplémentaire (en exposant par exemple root via
adb).
Ces critiques s'appliquent aussi à /e/OS qui est une distribution de LineageOS aménagée pour proposer ses services alternatifs et une plus grande facilité d'utilisation d'Android "ungoogled" (bien que je ne trouve pas AOSP pur rebutant à utiliser).
Les ROMs customs se contentent souvent de "fonctionner" à tout prix plutôt que d'être conservatrices du modèle de sécurité. Je comprends leur intérêt et les utilisateurs qui s'en contentent "à défaut de mieux", et je salue les développeurs qui dépensent temps et argent ; mais ces précisions sont à connaître dans le cadre de l'établissement d'un modèle de menace.
iOS : chez Apple, la prison dorée
iOS est également un système moderne et sûr, implémentant des mitigations similaires à Android, et un modèle de sandboxing particulièrement robuste. Évidemment, iOS n'est pas open-source, mais il l'est partiellement. Je ne vais pas m'attarder particulièrement sur iOS qui partage beaucoup de points communs avec Android de nos jours, mais plutôt m'attarder sur ses forces.
Un OS user-safe a ses avantages
Cette "prison dorée" est un avantage majeur pour la sécurité de l'utilisateur final. Le système (du hardware au software) n'execute que théoriquement du code signé et de confiance :
- En vous forçant à passer par l'App Store (il est possible d'utiliser des stores alternatifs sans jailbreak, mais c'est bien plus compliqué que sur Android), vous avez une source de confiance unique.
- Cette fonctionnalité est tirée à profit jusque dans le silicone des SoC Apple, par exemple avec Page Protection Layer (PPL), une mitigation garante de l'intégrité du système présente sur les SoC A12 et ultérieurs.
Il va de soi que vous rompez la chaîne de confiance établie par le modèle de sécurité pensé par Apple si vous vous amusez à jailbreak (littéralement s'échapper de la prison, mais à quel prix ?). Les jailbreak sont d'ailleurs très rarement persistants, en conséquence de ces mitigations.
La chaîne de confiance
Apple gère quasiment intégralement le hardware jusqu'au software, et leurs intégrations sont sans égales.
C'est très bénéfique dans certaines situations :
- L'iPhone 5S reçoit encore des mises à jour de sécurité alors que ce smartphone est sorti en 2013 !
- Apple a été un pionnier dans la sécurité hardware mobile avec son implémentation de la Secure Enclave Processor (depuis l'iPhone 5S)
- Contrairement à Android, très peu de fragmentation. Quand la dernière version d'iOS est la version majoritaire, ce n'est pas le cas pour Android, loin de là.
La chaîne de confiance est plus exactement un principe en sécurité informatique qui permet de valider l'authenticité et l'intégrité de chaque composante hardware et/ou software par un mécanisme cryptographique. C'est un principe totalement appliqué à la séquence de démarrage des iDevices.
Cette chaîne de confiance existe bien sûr, mais dans une moindre mesure forcément, chez Android avec Qualcomm.
En lieu et place des Play Services, les services Apple
Il y a également débat sur la supposée meilleure confidentialité des services Apple comparée aux services Google. Mais je vais être clair : n'ayez confiance dans un service "dans le cloud" seulement si celui-ci est chiffré de bout-en-bout, autrement c'est un compromis à faire qui dépend de votre modèle de menace.
Bien qu'Apple le documente plutôt bien, peu de services très utilisés sont réellement protégés par du chiffrement de bout-en-bout. L'intéressé expliquera que cette problématique est liée à "l'expérience utilisateur" : si vous oubliez une passphrase, vous perdez toutes vos photos dans un monde hypothétique où Apple Photos était un service chiffré de bout-en-bout.
Avis personnel, cette défense est un peu maigre : pourquoi ne pas laisser l'utilisateur final décider du compromis qui lui convient le mieux ? Les services Apple ont cet avantage de délester un maximum les serveurs du traitement de l'information au profit d'un traitement local, donc ce fonctionnement hybride pourrait fonctionner potentiellement.
Petite mention à iCloud Backup qui, si activé, garde une copie sur les serveurs Apple de votre historique iMessage... le tout avec la clé qui permet de déchiffrer ce backup. Apple a tenté par le passé d'y remédier, mais on se doute bien que ça bloque à un endroit.
Sachez d'ailleurs qu'il est possible d'utiliser iOS avec un Apple ID anonyme, et en désactivant totalement iCloud. Beaucoup de fausses informations circulent encore à ce sujet, et si certaines d'entre elles s'avèrent encore vraies, iOS n'est peut-être plus la prison qu'il était il y a quelques années.
GNU/Linux phones : Linux est là, mais le modèle de sécurité ?
Linux est un abus de langage pour dire en réalité GNU/Linux. Techniquement, Android est une distribution de Linux. ChromeOS aussi ! Il n'est pas nécessaire d'avoir les outils GNU pour être une distribution Linux.
Je ne vais pas m'éterniser sur ces tentatives (telles que le PinePhone, ou Librem). Un grand nombre de leurs défauts sont hérités des problèmes liés au modèle de sécurité desktop de GNU/Linux, abordés dans cet article :
PureOS est en réalité basé sur Debian (avec quelques bricoles), que je considère inadapté sur des plateformes autres que des serveurs. Il n'y a donc pas de réel modèle de sécurité, encore moins lié au mobile, et toujours pas de solution de sandboxing convenable.
Non, flanquer "Linux" et open-source/libre/whatever sur une fiche de produit ne fait pas de celui-ci subitement un produit sûr et élaboré. Ici, c'est même plutôt le contraire... on peut citer de manière non-exhaustive :
- Manque d'une forme de verified boot
- Pas de gestion cryptographique hardware aussi poussée
- Pas de mise à jour possible de firmwares même obsolètes (linux-libre)
- Mauvaise isolation du modem (stack USB Linux vs IOMMU)
- Toutes les problématiques de l'article lié à l'insécurité de l'écosystème Linux sur desktop s'appliquent aussi ici.
Concernant Linux-libre, voici une citation appréciée dans ce contexte :
Owning the proprietary software industry by forcing yourself to run insecure code - Matthew Garrett
En effet, l'usage de Linux-libre, une version modifiée de Linux qui empêche l'utilisation de firmwares et microcodes non-libres, signifie qu'il est inconcevable d'obtenir des mises à jour régulières. Tout ça pour quelle raison finalement ? Car ces "Linux phones" ne sont absolument pas 100% libres, le SoC (et pas que) étant toujours strictement propriétaire (cf. plus bas, même RISC-V ne serait pas une garantie).
Les kill switchs représentent une fonctionnalité davantage marketing que pertinente, même si elle a des bénéfices (mineurs et niches). La plupart du temps, un attaquant peut simplement attendre pour exfiltrer des données.
Pour la plupart des modèles de menace, un système de permissions robuste comme sur Android et iOS modernes suffisent. De plus, l'isolation fournie par l'IOMMU peut être tirée à profit sur un Google Pixel par exemple, où il est possible d'utiliser le Wi-Fi en désactivant les fonctions radio (équivalent au mode avion mais avec Wi-Fi).
Les plus soucieux pourront toujours préparer le décapeur thermique...
Je suis conscient de l'existence d'autres alternatives telles que Sailfish OS, ou encore Ubuntu Touch : est-ce vraiment nécessaire de se répéter ? Méfiez-vous du "marketing du libre", en particulier sur des work-in-progress.
GrapheneOS : sécurité renforcée sur les fondations d'Android
Je ne présente plus GrapheneOS, l'OS qui se donne pour mission de pousser le modèle de sécurité mobile jusqu'à ses retranchements.
Wonderfall
Compatible avec l'écosystème des applications Android, il se base sur les dernières avancées présentes dans AOSP et ne fonctionne à l'heure actuelle que sur les Google Pixel pour les raisons citées plus haut dans cet article.
GrapheneOS capitalise sur la modernité d'AOSP et sa sécurité out-of-the-box, et le renforce avec :
- Un allocateur de mémoire renforcé : hardened-malloc.
- Un renforcement du kernel : linux-hardened.
- Des politiques SELinux encore plus strictes.
- Un début d'écosystème bâti autour de la sécurité de Chromium et de son sandboxing : Vanadium, PDF Viewer.
- Des options pratiques telles que le PIN scrambling.
- Un service d'attestation hardware-backed.
- Des mises à jour automatiques, transparentes et rapides : dès que le bulletin de sécurité est publié, il y a un délai de quelques jours maximum.
- Et bien plus encore...
GrapheneOS n'est peut-être pas pour tout le monde, surtout du fait de l'absence des Play Services. Mais si vous êtes prêts à faire ce léger compromis, il sera difficile de faire un retour en arrière tant vous apprendrez énormément dans cette aventure.
Vous disposerez d'un modèle de sécurité robuste ainsi que d'une vie privée de première partie sans égale (aucune communication avec des tiers sur un profil par défaut). Les applications bénéficient bien entendu d'une sandbox au sein d'un même profil, mais vous pouvez couper toute possibilité de communication avec l'utilisation de plusieurs profils qui ont chacun des clés de chiffrement différents, comme expliqué ci-dessus.
Par rapport à AOSP, GrapheneOS pousse le modèle de permissions encore plus loin en proposant une permission "réseau" qui permet de couper la communication d'une application à n'importe quel réseau (local et Internet). Cependant, il faut garder en tête que des applications peuvent toujours communiquer entre elles par des API pour tenter d'exfiltrer des données, donc cette feature a ses limites.
Perspective globale et avenir
Nous avons passé en brève revue le modèle de sécurité mobile et ses différents acteurs. Vous avez pu constater que ce modèle est intrinsèquement plus moderne que son versant desktop, et applique à la lettre des concepts-clés de la sécurité informatique moderne tels que PoLP (Principle of Least Privilege) et ZTS (Zero Trust Security).
Les langages memory-safe
L'adoption de langages "memory-safe" est également de la partie, que ce soit dans l'écosystème proposé sur Android ("Java", Kotlin) ou iOS (Swift) et jusque dans les composantes intégrées au système.
Au passage, je suis tombé la semaine dernière sur un article très intéressant qui fait écho à cette problématique :
Examples would be the buffer overflow problem that has long afflicted software written in system languages like C, used for the Linux kernel. Switch language? "We know we have a whole new set of programming languages now, like Rust and Go and Swift, that operate in completely new ways," he says. "By using these languages you've engineered away entire classes of memory safety bugs."
- Dan Lorenc, Google Security Team Lead. Chez TheRegister
Bien que des mitigations ont été pensées rien qu'au niveau des compilateurs, la stack SSP proposée par GCC par exemple ne suffit pas à protéger contre toutes les attaques d'overflow. Les langages memory-safe sont l'avenir, mais il faut être réaliste : on ne réécrit pas des masses de code dans un tout nouveau langage, du moins pas avant des années, et avec le recul nécessaire.
Petit ajout du 7 avril 2021 : Google vient d'annoncer sur son blog de sécurité le support officiel de Rust comme langage de programmation système pour AOSP, et vante ses qualités de langage memory-safe.
Les microkernels
Les microkernels sont également l'avenir : ils sont bien plus légers que les noyaux monolithiques, ceci en délestant de nombreuses fonctionnalités et services à l'userspace (avec bien sûr une compartimentalisation et isolation adéquate) et contribuant ainsi à réduire drastiquement la surface d'attaque.
C'est ce que Google développe déjà activement avec le projet Fuchsia, perçu comme le successeur d'Android, qui n'utilisera plus Linux mais Zircon, un microkernel. GrapheneOS considère également le passage au microkernel (avec une couche de compatibilité Linux) comme un projet de long-terme.
Il y a donc de grandes marges de progrès et le modèle de sécurité mobile ne cesse d'évoluer. Nous en avons cependant une perspective très optimiste avec les acteurs actuels, qui, bien qu'ils sont critiquables pour leurs services, possèdent des ingénieurs de talent qui façonnent la sécurité de demain. Google est un contributeur important dans la sécurité de Linux, par exemple.
Quand le desktop s'inspire du mobile
On peut également constater que le modèle de sécurité desktop cherche à s'inspirer du mobile, notamment sur Windows 10 avec les applications UWP qui proposent un standard de sandboxing robuste sur desktop (mais allez-y pour convaincre d'utiliser W10 en S-mode...), ou encore les laptops Secured Core qui signifient l'intérêt pour un modèle de sécurité hardware et firmware.
On peut également penser à macOS qui a aussi son modèle de sandboxing, et une implémentation de verified boot sur les Mac Intel+T2 et plus récemment M1, qui apporte d'ailleurs de nombreuses nouveautés liées à la sécurité :
Du côté de "l'écosystème GNU/Linux", j'espère voir un jour un sursaut dans cette problématique du modèle de sécurité. Le libre, par définition, ne peut pas vraiment être contrôlé par de grands acteurs donc la communauté du libre toute entière doit soutenir cette mouvance pour rendre son écosystème plus sûr et moderne. C'est un des objectifs de ma série d'articles...
Je reviendrai sur le modèle de sécurité desktop dans un prochain article.
x86, ARM... RISC-V : quid du hardware ?
La sécurité de nos CPU a été remise au goût du jour notamment par Spectre et Meltdown qui affectaient principalement x86 (mais aussi ARM).
Tandis que x86 est historiquement le jeu d'instructions utilisé sur desktop, ARM est celui utilisé sur mobile, et commence à faire son incursion sur desktop (le Mac M1 en est l'exemple le plus récent). Je simplifie ici volontairement, ce sont en réalité des grandes familles, vous m'avez compris.
x86 est une plateforme vieillissante, fermée, subissant son âge et sa complexité de sur-ingénierie (voyez un peu ce que donne Intel ME) à côté d'un ARM bien plus simple et logiquement perçu comme de facto plus sûr. Ce sont des discussions assez hypothétiques mais bien compréhensibles.
Au passage, je vous suggère de lire à propos des futures extensions memory tagging d'ARM qui verront le jour avec les SoC armv9 :
Wonderfall
ARM demeure une plateforme fermée, donc la question d'un hardware plus ouvert est légitime. RISC-V est un jeu d'instruction libre et prometteur, par exemple. Je n'aime pas apporter des mauvaises nouvelles, mais tout ne sera pas si rose comme l'explique très justement ce thread Twitter. RISC-V est un pas vers l'ouverture du hardware, mais pas une révolution pour autant. Plus qu'une spécification ouverte, il faut des implémentations plus ouvertes !
Conclusion & références
Je commence déjà à divaguer tant il y a de choses à dire et tant le sujet est passionnant. Je pense qu'il vaut mieux s'en arrêter là et peut-être, à l'avenir, développer des points particuliers voire des points occultés par oubli de ma part. N'hésitez pas à me faire part si vous avez la volonté d'approfondir un sujet en particulier : je suis loin d'être un expert sur tous les sujets mais je serais ravi de travailler en profondeur sur des thématiques particulières.
J'espère que cet article aura été utile à certaines personnes que ce soit pour le partage de connaissances, ou le choix d'un appareil sûr selon les standards actuels en 2021. Mon avis personnel pour le choix d'un smartphone, par ordre :
- GrapheneOS sur Pixel est l'idéal (sécurité et vie privée ++)
- Sinon, un iPhone récent (A12+, à jour, no jailbreak)
- Ou bien un Pixel récent (3+, à jour, stock)
De plus, je ferais un maximum de tâches sur cet appareil plutôt que sur mon desktop. J'éviterais par exemple de synchroniser Signal / WhatsApp / whatever sur desktop. Un iPad avec clavier est concevable pour faire un maximum de tâches dans le cadre d'un bon modèle de sécurité.
La vie privée de première partie offerte par un iPhone et un Google Pixel "stock" peut être perçue comme inférieure, mais elle l'est relativement moins par rapport à d'autres modèles d'autres constructeurs. Ces appareils peuvent être configurés pour utiliser un compte anonyme et limiter la télémétrie, même si ce n'est pas idéal si les GAFAM font l'objet principal de votre modèle de menace. En revanche, ces appareils offrent une bonne vie privée de tierce partie à condition de respecter des règles d'usage.
Ici, je m'intéresse à la sécurité pure en occultant les considérations économiques. Bien que les Pixel de la gamme "a" ainsi que les iPhone SE et les iPad entrée de gamme sont relativement abordables, je comprends le problème de l'accessibilité.
La sécurité ne doit pas être un "problème de riche".
Vous pouvez creuser le sujet davantage à ces adresses :
- Android | Madaidan's Insecurities (madaidans-insecurities.github.io)
- Linux Phones | Madaidan's Insecurities (madaidans-insecurities.github.io)
- GrapheneOS
- Apple Platform Security
- Secure an Android Device | Android Open Source Project
- OS Security: iOS vs GrapheneOS vs stock Android : GrapheneOS (reddit.com)
- Android Privacy and Security - and-priv-sec@hub.libranet.de
J'ai également ajouté plusieurs liens au fil de cet article, n'hésitez pas à les consulter.