L’attestation matérielle comme auxiliaire monopolistique
(grapheneos.social)- Apple et Google étendent l’usage de l’attestation fondée sur le matériel, encouragent son adoption par davantage de services et renforcent à long terme une structure qui exclut le matériel et les OS non approuvés de la concurrence
- Les API Play Integrity de Google et App Attest d’Apple fonctionnent de manière similaire ; Play Integrity exige une attestation matérielle pour
strong integrityet évolue vers une exigence progressive similaire aussi pourdevice integrity - Privacy Pass d’Apple, le projet annulé Web Environment Integrity de Google et
reCAPTCHA Mobile Verificationtransposent ces exigences d’attestation sur le web, au point que l’accès à des services web pourrait être bloqué sans iPhone ou appareil Android certifié - L’API Play Integrity interdit GrapheneOS alors même qu’il est plus sûr que les systèmes autorisés, tout en autorisant des appareils sans correctifs de sécurité depuis 10 ans, ce qui met davantage en évidence un objectif de licence Google Mobile Services et d’exclusion de la concurrence qu’un motif de sécurité
- À mesure que les services publics et bancaires exigent davantage App Attest et Play Integrity, ils imposent de fait des appareils Apple ou des terminaux Android certifiés par Google, avec un impact possible aussi sur l’accès web depuis Windows, Linux de bureau ou FreeBSD
Des exigences d’attestation qui s’étendent au web
- Le Privacy Pass d’Apple transpose l’attestation matérielle sur le web afin d’aider à franchir les CAPTCHA depuis son propre matériel
- À l’époque, beaucoup jugeaient cela inoffensif, estimant que peu de sites bloqueraient les utilisateurs n’ayant pas de matériel Apple
- Apple et Google sont tous deux susceptibles d’étendre une attestation matérielle bien plus large au web
- Les banques et les services publics exigent de plus en plus l’usage d’applications mobiles, et peuvent y utiliser l’attestation pour imposer des appareils et OS approuvés par Apple ou Google
- Le Privacy Pass d’Apple, le projet annulé Web Environment Integrity de Google et reCAPTCHA Mobile Verification étendent cette dynamique au web
- La couverture actuelle de reCAPTCHA Mobile Verification ne traite pas correctement de son impact ni de sa portée
- Cette méthode impose, dans certains cas, de scanner un QR code avec un smartphone certifié pour réussir un reCAPTCHA, ce qui introduit des exigences d’attestation matérielle aussi pour Windows, Linux de bureau, OpenBSD, etc.
- Grâce à son contrôle sur reCAPTCHA, Google est en position de faire en sorte qu’un iPhone ou un appareil Android certifié soit nécessaire pour utiliser une immense partie du web
- Google définit les exigences de certification Android, qui incluent notamment l’obligation d’intégrer Google Chrome
- reCAPTCHA Mobile Verification fonctionne actuellement avec Google Play sandboxé sur GrapheneOS, mais existe afin de commencer aussi à l’utiliser sur des systèmes dépourvus d’attestation matérielle
- Si cette exigence est appliquée, les personnes ne disposant ni d’iPhone ni d’appareil Android pourraient être bloquées sans condition supplémentaire
Play Integrity et l’exclusion de GrapheneOS
- L’API Play Integrity de Google interdit l’usage de GrapheneOS alors même qu’il est bien plus sûr que n’importe quel système autorisé
- L’API Play Integrity interdit aussi d’autres alternatives, et le problème ne concerne pas seulement les OS fondés sur AOSP
- Même l’usage d’un OS mobile fondé sur FreeBSD ne permettrait pas d’éviter ce problème, mais seulement d’être encore plus exclu
- L’API Play Integrity autorise des appareils sans correctifs de sécurité depuis 10 ans
- Le niveau
device integritypeut être contourné par usurpation, mais Google peut assez bien le détecter et le bloquer si cela commence à être utilisé à grande échelle - Contourner le niveau
strong integrityexige des clés divulguées issues d’un TEE ou d’un SE - L’API Play Integrity n’est pas très sûre et n’est pas particulièrement difficile à contourner temporairement
- Il existe des frameworks pour usurper les vérifications logicielles, et il est aussi possible d’acheter des clés divulguées pour contourner l’attestation matérielle
- Cela dit, le contournement devient de plus en plus difficile et sa durée de validité de plus en plus courte
- Play Integrity n’apporte pas de fonction de sécurité utile, mais fonctionne très bien pour exclure la concurrence
- Les services qui exigent Apple App Attest ou Google Play Integrity contribuent surtout à préserver le duopole d’Apple et Google sur les appareils mobiles
- Play Integrity est plus important parce qu’AOSP est open source
- GrapheneOS peut être vérifié par attestation matérielle, et si Google l’interdit dans Play Integrity, c’est parce qu’il ne licence pas Google Mobile Services et ne se conforme pas à des règles anticoncurrentielles
- Ces règles ont déjà été jugées illégales, notamment en Corée du Sud
- Les services ne devraient pas interdire l’usage de matériel et de systèmes d’exploitation arbitraires
- Dès lors que Google autorise des appareils non corrigés depuis 10 ans tout en refusant des OS bien plus sûrs, l’argument de la sécurité est difficile à soutenir
- Il s’agit d’imposer un monopole via la licence GMS
Services publics, banques et rôle de la régulation
- Les gouvernements imposent de plus en plus l’usage d’Apple App Attest et de Google Play Integrity non seulement pour leurs propres services, mais aussi pour des services commerciaux
- L’UE mène cette dynamique en appliquant ces exigences aux paiements numériques, à la vérification d’identité, à la vérification de l’âge, etc.
- De nombreuses applications gouvernementales de l’UE intègrent déjà ces exigences
- Au lieu d’empêcher les graves pratiques anticoncurrentielles d’Apple et Google, les gouvernements participent directement à l’exclusion de la concurrence via leurs propres services
- Exiger des gens un appareil Apple ou un appareil Android certifié par Google relève non pas de la sécurité, mais de la restriction de la concurrence
- Le fait qu’un appareil iOS non modifié ou Android Google Mobile Services devienne nécessaire pour accéder à des services bancaires, à des services publics ou pour franchir certains reCAPTCHA n’est pas un problème propre à GrapheneOS
- Cela a les mêmes effets sur Windows, Linux de bureau, FreeBSD, etc.
- Ce n’est pas un problème propre aux Pixel, aux appareils Android ou aux systèmes d’exploitation fondés sur AOSP ; cela peut aussi affecter l’accès au web depuis un ordinateur de bureau
API d’attestation Android et Unified Attestation
- Android fournit un système standard d’attestation matérielle prenant en charge les systèmes d’exploitation alternatifs via des empreintes de clés de démarrage vérifié autorisées
- L’attestation matérielle d’Android s’appuie principalement sur la racine de confiance de Google et sur son service de provisionnement de clés à distance, mais l’API elle-même prend en charge des racines de confiance alternatives
- L’attestation matérielle Android ne devrait pas être utilisée pour exclure les utilisateurs qui n’emploient pas un matériel ou un OS donnés
- Cependant, le fait de pouvoir autoriser des racines de confiance et des OS arbitraires laisse aux services une marge pour accepter davantage de systèmes
- Si Google poursuivait réellement un objectif de sécurité, il pourrait autoriser GrapheneOS dans Play Integrity en utilisant ce même système
- Unified Attestation est un autre système anticoncurrentiel poussé par plusieurs entreprises européennes, qui finirait par exclure de manière similaire les utilisateurs de matériel et de logiciels arbitraires
- Unified Attestation n’est pas une solution et est bien pire que l’API d’attestation matérielle Android, pourtant beaucoup plus ouverte
- Unified Attestation de Volla est entièrement construite au-dessus de l’API d’attestation matérielle Android
- L’Unified Attestation de Volla existe afin que le contrôle de ce qui est autorisé revienne à une autorité centrale et aux services
2 commentaires
J’aime tellement Google que j’aimerais qu’il y en ait au moins cinq 🥰
Commentaires sur Hacker News
Le EU Digital Identity Wallet (EUDI) exige une attestation matérielle de Google ou d’Apple, ce qui revient de fait à lier toute l’identité numérique de l’UE au duopole américain
Cela revient à parler de souveraineté numérique tout en prenant ce genre de décision, comme si la protection des enfants passait avant la souveraineté
https://gitlab.opencode.de/bmi/eudi-wallet/wallet-developmen...
Je ne comprends pas pourquoi cette décision a été prise au départ
On voyait clairement que la réponse était pensée pour des utilisateurs ordinaires sans connaissances techniques
Beaucoup insistent sur l’importance de la souveraineté et de la sortie de la dépendance envers les États-Unis, alors je ne comprends pas pourquoi il n’y a pas davantage d’opposition ; j’en viens à me demander si ce n’est pas simplement de l’ignorance
C’est encore plus vrai pour les identifiants préservant la vie privée, d’où l’importance de l’attestation de l’appareil
Si l’on ne peut pas vérifier que le matériel empêche l’extraction des clés de l’utilisateur, on ne peut pas garantir que les clés d’identité sont bien verrouillées dans l’appareil
Le pire, c’est qu’au final des criminels motivés trouveront quand même un moyen d’extraire ces clés pour commettre des fraudes, et qu’au bout du compte cela détruit l’open source et l’informatique ouverte
La question de savoir qui devrait être obligé de présenter une pièce d’identité est autre chose ; et dans la plupart des situations purement en ligne, j’aurais tendance à répondre « non », mais le secteur financier dispose déjà depuis des décennies d’une solution éprouvée
Exiger du silicium et des logiciels approuvés n’est même pas le plus gros problème ici
Ils n’utilisent ni preuve à divulgation nulle de connaissance ni signature aveugle
Donc, à chaque fois qu’on s’authentifie avec l’appareil, on laisse un paquet de preuves qui peut servir à relier cette action à l’appareil
Ils font semblant de se soucier de la vie privée en ajoutant une architecture de contournement où un serveur intermédiaire récupère un identifiant à usage unique à partir d’un identifiant statique de l’appareil, mais comme on ne sait pas ce que font ces serveurs intermédiaires, il faut partir du principe qu’ils enregistrent tout
Ce n’est ainsi que pour la voie d’attestation distante, et la voie DRM ID est pire encore. Il n’y a pas de contournement significatif, donc tous les serveurs de licence peuvent accéder à l’identité statique gravée dans le silicium. Et inutile de parler de la voie du compte Google
Une proposition d’utiliser des signatures aveugles pour l’attestation distante a bien existé, mais elle n’est visiblement pas utilisée à l’heure actuelle : <https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation>
Il y a plusieurs raisons possibles. La raison évidente, c’est qu’ils veulent pouvoir violer la vie privée quand ils le souhaitent, ou qu’ils y sont obligés
Une autre raison, c’est que si l’on ne peut pas relier une attestation à un appareil donné, alors la seule mesure d’atténuation des abus qui reste vraiment, c’est la limitation de débit, et cela peut ne pas leur sembler suffisant. Un attaquant pourrait monter une ferme d’appareils et faire gagner de l’argent à chacun en fournissant une attestation distante à des acteurs malveillants
Je ne vois pas comment un service peut mettre en place une limitation de débit tout en restant anonyme
Si un service peut compter que deux requêtes viennent de la même entité, alors deux services peuvent aussi prétendre être le même service pour déterminer que deux requêtes viennent de la même entité et donc les corréler
Dire des choses comme « le problème, ce n’est pas l’attestation matérielle, c’est l’absence de preuves à divulgation nulle de connaissance », c’est normaliser un nouveau comportement
Il ne faut pas. Qu’on utilise des preuves à divulgation nulle de connaissance ou la dernière technique de sécurité pour faire de l’attestation matérielle, le problème, c’est l’attestation matérielle elle-même
Même chose pour la vérification d’âge. Le problème n’est pas qu’elle soit vulnérable aux fuites de données ; le problème en soi, c’est la vérification d’âge
J’étais à peu près certain depuis l’annonce de l’application que l’architecture serait de ce type
Je me souviens aussi avoir vu sur le forum Graphene une discussion disant que le DRM ID est non seulement conservé, mais reste aussi identique d’un profil à l’autre
Si oui, quel serait le levier, incitatif ou coercitif, qui pourrait pousser à son adoption ?
C’est un fil qui montre bien pourquoi cette technologie devient un problème pour tout ce qui se veut « ouvert »
L’argument consistant à dire « il suffit de créer notre propre web séparé » ne tient que jusqu’au moment où tous les services passent derrière un web qui exige de posséder un appareil mobile approuvé par Google ou par Apple
Google me bloque déjà complètement à ce niveau
Si je clique sur les carrés pour sélectionner les éléments demandés, ça boucle à l’infini, et si j’essaie la version audio, je suis totalement bloqué pour activité suspecte
Du coup, je roule seul ces temps-ci et je n’ai même pas renouvelé mon adhésion cette année
La dernière fois que j’ai vécu quelque chose de comparable, c’était quand Facebook est devenu l’unique moyen d’accéder à certains événements. À l’époque aussi, j’ai simplement accepté d’être exclu et j’ai consacré mon temps et mon argent à autre chose
Beaucoup d’entreprises ou de groupes sociaux étaient déjà accessibles uniquement derrière Facebook, WhatsApp et autres
Cela ressemble vraiment à une sorte de dystopie cyberpunk étrange : comme si l’on ne pouvait envoyer des lettres ou des colis qu’à des personnes abonnées au même service postal privé, ou conduire seulement sur des routes ayant une licence croisée avec la marque de sa voiture
Même s’il y avait effectivement une fonctionnalité de sécurité, le dommage collatéral consistant à faire des systèmes d’exploitation autres que ceux de Google ou Apple des citoyens de seconde zone resterait entier, et c’est bien là le problème central
Pour les banques ou les interactions avec l’État, ce ne serait probablement pas réaliste, mais pour beaucoup d’autres services, cela pourrait l’être
Cela dit, il faut toujours construire quelque chose, les coûts se répartissent sur moins de monde, et le fait qu’on n’ait pas à créer de technologie publicitaire, avec une complexité moindre, ne suffira probablement pas à compenser
Cela dit, c’est peut-être une sorte de problème de bons ingrédients. Le matériel sera plus difficile
Ça ressemble à une question idiote, mais je la pose sérieusement
En 1999, quand Intel a décidé d’intégrer dans ses CPU un numéro de série lisible par logiciel, il y a eu une opposition énorme, et l’entreprise a fini par faire marche arrière
Après cela, les autoritaristes qui poussaient la « sécurité » et l’informatique de confiance ont continué à promouvoir le TPM et les technologies associées, contribuant aussi à la montée des écosystèmes fermés sur mobile
L’exigence de TPM dans Windows 11 était une nouvelle étape vers cet objectif. J’ai été sidéré de voir à quel point on en a fait la promotion ici et ailleurs comme si c’était une bonne chose
Cela montre qu’il est très facile d’imposer n’importe quoi à une part importante des gens dès lors qu’on invoque la « sécurité ». J’espère que cette proportion diminue
La guerre contre l’informatique généraliste continue, et il faut continuer à se battre
Stallman avait raison, comme souvent. Il est temps de relire son « Right to Read ». Et si ça n’existe pas encore, un court-métrage créé par IA pourrait aussi être une bonne idée
« Ceux qui renoncent à la liberté au nom de la sécurité ne méritent ni l’une ni l’autre »
L’IA est un outil totalement centralisé et monopolistique
Comme on le voit dans ce fil, au lieu d’un élan, d’une colère ou d’une réponse auto-organisée face à ces problèmes, on n’a que du désespoir du type « personne ne s’en soucie » ou « on ne peut rien faire »
Abandonner est le moyen le plus sûr de perdre
Les commentaires ici semblent lire cela comme si l’attestation en elle-même était mauvaise, alors que l’argument réel semble plutôt être qu’il devrait exister une voie incluant explicitement des fournisseurs autres qu’Apple et Google
Le titre donne l’impression qu’Apple et Google sont mauvais et font cela pour verrouiller leur monopole, tandis que leur concurrent GrapheneOS lutterait pour les gens
Mais quand la dernière objection est qu’eux aussi auraient dû être inclus, et qu’ils disent avoir été refusés pour des raisons obscures par la Play Integrity API de Google, en affirmant que ces raisons sont malveillantes, cela laisse penser qu’eux aussi reconnaissent une valeur du point de vue de la sécurité
Pour des données d’identité importantes, une preuve de toute la chaîne de signature est vraiment nécessaire. C’est parce que c’est la seule façon d’éviter une situation où l’on peut fabriquer facilement de fausses identités avec l’IA
Les brevets et le droit d’auteur ont été les formes originelles du monopole
Tant qu’un logiciel n’est pas open source, il est monopolistique par définition
Je suis surpris qu’il n’y ait pas plus de HN fortunés pour soutenir GrapheneOS
Le diagramme de Venn entre les personnes aisées et les techniciens qui se soucient de ce problème doit quand même avoir un fort recouvrement, et Graphene, malgré ses défauts, fait beaucoup de travail de fond dans ce domaine
Notre civilisation a désespérément besoin d’un moyen de modifier la microélectronique moderne après fabrication, au minimum dans des ateliers de réparation bien équipés
C’était déjà nécessaire hier
À défaut, il faudrait interdire que les appareils informatiques vendus comme généralistes soient livrés avec un premier bootloader de quelque type que ce soit inscrit dans la mask ROM du CPU ou du SoC
Autrement dit, la première instruction exécutée par le CPU après une réinitialisation devrait provenir d’un support de stockage physiquement situé à l’extérieur du boîtier du CPU
Référence : https://pluralistic.net/2026/01/01/39c3/
Même un SoC relativement simple effectue énormément d’opérations dans une boot ROM non documentée pour aider au processus de réinitialisation avant d’atteindre le vecteur de reset architectural
Il y a aussi beaucoup de valeur à intégrer dans une boot ROM impossible à effacer accidentellement des routines DFU bas niveau
Le silicium du SoC pourrait être révisé de manière à enregistrer chaque instruction exécutée depuis la mise sous tension jusqu’à l’instruction de transfert vers le secure boot
En ajoutant des instructions auxiliaires pour l’interrogation d’état, la détection d’overflow, la génération de signature, etc., le système d’exploitation pourrait produire sa propre attestation tout en signalant implicitement toute altération pré-boot
Il suffirait d’interdire l’intégration de matériel de clé codé en dur dans le bootloader, ainsi que la vérification par cette clé du code qu’il charge
Il est stupéfiant qu’on laisse le duopole Google-Apple décider qui peut ou non accéder à des services qui n’ont pourtant aucun rapport direct avec eux
Imaginez qu’à cause de positions anti-Google vous soyez banni des services Google et que vous ne puissiez plus vous connecter à votre compte bancaire
Il faut vraiment démanteler Alphabet
Pour un sujet aussi grave, un véritable texte structuré et logique sur une seule page aurait été bien préférable à un fil difficile à lire comme celui-ci