Apple et Google font la promotion de leur technologie de certification de matériel.
Au nom de la sécurité, les deux gros fournisseurs d’OS mobiles sont en train de verrouiller un marché où ils seraient les seuls acteurs mondiaux à décider qui a le droit d’utiliser tel ou tel matériel.
Le principe
Le but de ces technologies est d’interdire aux gens d’utiliser du matériel et du logiciel non approuvé par Google et Apple.
Faussement présenté comme une fonctionnalité de sécurité, les banques et les gouvernements les adoptent avec enthousiasme, car cela leur permet d’imposer l’usage de logiciels privateurs à leurs clients/citoyens, quitte à sacrifier la souveraineté.
Les technologies
API Play Integrity de Google
Cette API Android permet à une application de vérifier :
- qu’elle n’a pas été modifiée par l’utilisateur ;
- que l’utilisateur a bien payé pour l’utiliser ;
- que l’exécution n’a pas lieu sur un émulateur ;
- que le matériel sur lequel elle s’exécute est certifié par Google.
Quelques fournisseurs d’Android proposent des alternatives à ce service :
- Unified Attestation, créé par Volla ;
- Android hardware attestation, présenté par Graphene OS comme une alternative à Google’s Play Integrity API plus ouverte.
API App Attest d'Apple
https://developer.apple.com/documentation/devicecheck/preparing-to-use-the-app-attest-service
Privacy Pass
Ce protocole a pour but d’authentifier un utilisateur anonyme. Cela peut sembler contradictoire, mais il s’agit de remplacer les solutions pour stopper les vils bots (captcha, anubis…).
Concrètement l’utilisateur doit obtenir un jeton avant d’accéder à un service.
Malheureusement de vils humains d’Apple et Cloudflare ont trouvé opportun d’implémenter ce système en rendant obligatoire l’usage d’un matériel certifié.
reCAPTCHA
Cette solution de Google impose aussi l’usage des services Google pour vérifier un mobile pour pouvoir accéder à certains services, notamment des sites web.
La certification de matériel du point de vue des utilisateurs
Pour le consommateur, la certification du matériel (appliqué aux ordiphones) revient à :
- limiter son choix de matériel neuf ;
- limiter son choix de matériel d’occasion ;
- accélérer l’obsolescence du matériel possédé.
Bref il faudra plus régulièrement « tout racheter ».
(Source: sketch des Guignols sur les "iAiles-dans-les-dos", une révolution de Steeve Jobs qui innove au paradis, 2011)
Pour le citoyen, c’est :
- l’usage obligatoire de logiciels privateurs ;
- une inscription forcé et donc l’acceptation des contrats de société “agressives” sur la vie privée et les données personnelles.
Pour les États et l’Union Européenne, c’est un nouvel abandon de souveraineté.
Certifier du matériel, c’est privateur. Certifier des gens c’est pire.
Si vous avez un diplôme d’ingénieur, un permis de chasse, un passe sanitaire ou un tatouage mafieux, vous savez que les organisations adorent certifier les personnes, par exemple pour être bien certaine de recruter un bon tireur pour une mission spéciale en pleine pandémie.
Toutefois si vous êtes un braconnier antivax de l’école 42, vous pouvez aussi télétravailler du côté obscur, par exemple comme développeur Android.
Enfin jusqu’ici, car Google demandera bientôt que tout développeur d’applications Android s’inscrive avec des obligations comme fournir une pièce d’identité officielle et lister tous ses identifiants d’applications actuels et futurs…
Une campagne est en cours pour défendre le droit des braconniers antivax de l’école 42gens normaux de continuer à développer librement sur Android : https://keepandroidopen.org/fr/
# On connait la technique !
Posté par Pierre Jarillon (site web personnel) . Évalué à 8 (+7/-2). Dernière modification le 19 juin 2026 à 19:11.
On a déjà vu ça ! Microsoft et les DRM, la société des droits d'auteur… Albanel qui croyait défendre cette mafia en a été la risée. Tous ceux qui ont voulu construire un monopole sur des textes réglementaires se sont cassé la figure. Pourvu que ça dure !
[^] # Re: On connait la technique !
Posté par Maclag . Évalué à 10 (+12/-1).
Sauf que là ce n'est pas sur des textes réglementaires, c'est à travers des limitations technologiques.
Tout ça me rappelle un peu le discours de Peter Thiel qui disait que la population n'accepterait jamais ses idées, mais il pourrait les imposer par la technologie. Si on avait proposé une règle qui impose l'usage d'Android par Google ou iOS, elle aurait été démontée au parlement (sous un gouv modéré, on s'entend, pas une majorité RN…).
Mais là c'est plus insidieux: c'est vendu aux banques etc. comme le nec plus ultra de la sécurisation, et ça marche: les banques embarquent, les gouvernements embarquent, et on peut s'attendre à ce que, si rien n'est fait, ça se répande.
Il faut alerter les pouvoirs publics pour qu'ils régulent sur le sujet, le plus tôt sera le mieux, on connaît tous les effets du "fait accompli" et du "statut quo", les plus anciens se souviennent encore de la lutte contre la vente liée de Windows sur les machines.
[^] # Re: On connait la technique !
Posté par Pol' uX (site web personnel) . Évalué à 5 (+5/-2).
Ne pas avoir de spyphone Apple ou Google est la première des démarches à adopter.
Adhérer à l'April, ça vous tente ?
[^] # Re: On connait la technique !
Posté par devnewton 🍺 (site web personnel) . Évalué à 10 (+7/-0).
Sauf que les entreprises et les administrations ont une stratégie "app first / app only" 😷.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: On connait la technique !
Posté par samantha64 . Évalué à -2 (+3/-5).
Et alors ?
C'est pas ton ordi mobile c'est celui de l'entreprise, tu le laisse au taf comme tout le monde devrais le faire.
Pour ton numéro privée soit une ligne fixe soit une brique nokia classique.
Tes 1 million de fois moins emmerder avec ça.
Au pire tu fais comme moi, ta un rectangle noir juste pour prendre des photos, car on ne peut pas nier sa praticité pour ça.
[^] # Re: On connait la technique !
Posté par tkr (Mastodon) . Évalué à 1 (+0/-1).
tout pareil ici, pas de tel perso compatible applis au taff ou ailleurs ; pour rien au monde je reviendrai aux "applis"
[^] # Re: On connait la technique !
Posté par tkr (Mastodon) . Évalué à 1 (+0/-1). Dernière modification le 03 juillet 2026 à 14:58.
j'ai une vie pratique incompatible avec les app-only, je changerai pour aucune d'entre elles, jamais.
[^] # Re: On connait la technique !
Posté par Voltairine . Évalué à 10 (+10/-0).
Oui mais seule une infime minorité de personnes déjà convaincues le font ou le feront.
Pour le grand public ces enjeux sont incompréhensibles et globalement il s'en fout complètement.
D'où la nécessité de faire du lobbying sur ce sujet.
Et merci pour cette dépêche informative, claire et concise. Cela change des logorrhées générées par IA sur d’obscurs logiciel créés de la même manière…
[^] # Re: On connait la technique !
Posté par samantha64 . Évalué à -6 (+0/-6).
En effet.
C'est pas qu'ils sen foutent, c'est qu'ils en sont inconscient due a leur illettrisme.
Seules les personnes aillent un QI et, ou conscience plus développer font du préventif sur le sujet.
Hormis c'est gens, seules les gens qui furent impacter négativement en ont conscience.
[^] # Re: On connait la technique !
Posté par C. OB (site web personnel) . Évalué à 5 (+5/-1).
Rien de simple dans cette démarche en 2026:
Comme le dit devnewton: Les administrations, les banques, les services ont tous de plus en plus une stratégie "app-first, app-only". Quelques exemples: Flora Bank (banque de cdiscont), Electra & allego (charge de voiture), Lidl (app obligatoire pour charger également), l'identité numérique par La poste, l'app la plus déficiente du monde mais le seul moyen pour créer une auto-entreprise à ce jour…)
Si on veux l'équivalent du 3310, bah déjà il faut de la 3G/4G vu que la 2 s’éteint.
Il y a quelques modèles , assez confidentiels (On en trouve chez HMD , dans la gamme "Senior" et "Classique" donc certains ressemblent à des 3310), mais toujours privateurs.
Rare sont les modèles vendu directement sous linux avec une couche graphique utilisable. Et ils ne sont pas à portée de ma bourse.
Comme le dit Voltairine, nous, on saurait le faire. Et on le ferait même pour nos proches.
Mais ceux à convaincre ce sont tous les autres, qui vont dans leur boutique orange quand au bout de 2 ans leur smartphone est cassé et que le vendeur sera fort content de lui vendre un énième Android++ "sécurisé".
Je ne peux m'empêcher de me dire qu'avec Trump , il nous reste un peu moins de 5 ans de n'importe quoi pour qu'il force Google à bloquer des services pour les européens sur fond de différent commercial ou géopolitique: Blocage des mises à jour ou des services tel que Play Integrity comme décrit ici .
Il n'y a que ça qui ferait que les banques, tellement obnubilés des gros vilains rooteurs de téléphone, s’aperçoive qu'elles se sont soumise au bon vouloir d'un acteur privé et hostile.
Par "Sécurité".
(Sans l'accès au playstore , bon courage pour pousser une mise à jour chez leurs clients qui retire cette dépendance, d'ailleurs).
Les OS alternatifs basés sur AOSP sont parfois bien mais pas ideaux non plus (disclaimer : Je suis sous /e/OS , par conviction, mais sans utiliser toute la couche Murena qui reste assez fortement poussée, sans doute car c'est ce qui rapporte des sous. Comme quoi…)
Je rêve d'un smartphone en RISC-V vraiment libre depuis le matériel jusqu'à l'OS, dont le modem cellulaire est physiquement désactivable , comme les camera/micro & le gps.
On y est pas, ne serait-ce qu'en terme de conso d'énergie, mais j'espère le voir avant ma mort (si j'avais le temps & les sous je tenterais de le faire…)
[^] # Re: On connait la technique !
Posté par Astaoth . Évalué à 5 (+5/-2). Dernière modification le 20 juin 2026 à 21:24.
C'est mon moment de briller en société en posant un lien vers le Commodore Callback pour une petite dose de rétro futurisme ! C'est un feature phone a clapet, sous SailfishOS et sa couche Android pour avoir les applis de communications modernes dessus. Le principe de ce téléphone est d'avoir quelque chose pour communiquer (signal, whatsapp, etc) mais sans réseau social. Il sera toujours possible de sideload des applis android ou d'en proposer pour le commodore store.
Je me permets de poser aussi sans honte mon petit lien de parainnage pour s'inscrire à la newsletter qui annoncera la précommande (à la fin du mois), qui donnera une réduction supplémentaire de 50$ à la commande à celleux qui l'utilisent, et pour moi avoir des coques gratuites :3
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: On connait la technique !
Posté par samantha64 . Évalué à 2 (+2/-0).
La FSF a lancer https://librephone.fsf.org/
[^] # Re: On connait la technique !
Posté par samantha64 . Évalué à 1 (+1/-0).
Perso je suis revenue au bon vieux nokia.
Quoi que il ont ""moderniser"" le 3310 avec la capacité de se connecter sur des réseaux 4/5g.
Au final je garde juste mon rectangle noir pour prendre des photos/video et lire des pdf si je dois passer du temps loin de mon pc.
[^] # Re: On connait la technique !
Posté par tkr (Mastodon) . Évalué à 2 (+0/-0).
+1
obligation d'installer l'appli? je dégaine mon "3310" anti-applis : soit ça se fera sans applis, soit avec une appli sur un appareil appartenant à la personne demandeuse (donc pas moi), soit ça se fera sans moi.
Je met l'interlocuteur systématiquement devant le fait accompli : on a plus le droit de dire "non", c'est donc l'appareili qui ne pourra dire autre chose que "non, définitivement".
[^] # Re: On connait la technique !
Posté par karteum59 (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 05 juillet 2026 à 04:58.
C'est de plus en plus difficile
On se dirige vers un monde où il est obligatoire d'avoir un smartphone verrouillé (et que pour respecter sa vie privée il faut l'éteindre le plus souvent possible et ne l'utiliser que pour ces applis indispensables, et avoir un autre tel à côté). En tout cas les solutions de contounement comme Zygisk, Play integrity fix, etc. semblent de plus en plus difficiles à mettre en oeuvre.
[^] # Re: On connait la technique !
Posté par Pol' uX (site web personnel) . Évalué à 6 (+4/-0).
Oui. D'où l'urgence de résister. Est-ce que la solution viendra plus vite si tout le monde dit « c'est impossible de faire sans » et joue le jeu du verrouillage ?
Adhérer à l'April, ça vous tente ?
[^] # Re: On connait la technique !
Posté par Nicolas Boulay (site web personnel) . Évalué à 8 (+5/-0).
Le gvt ne s'est pas rendu compte qu'il sont fort pour creer de la norme et mauvais pour les logiciels ?
Leurs normes pourraient reposer sur des principes d'interoperabilité.
"La première sécurité est la liberté"
# Message à google.
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 6 (+3/-0).
Le site keepandroidopen invite à laisser un petit message à Google sur le sujet. Comme j'ai eu un peu de mal à me décider quoi écrire, et si ça peut en inspirer d'autre à répondre au propre sondage de Google, voici ce que j'ai écrit :
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
# Unified Attestation est techniquement merdique
Posté par xryl669 . Évalué à 9 (+8/-0).
Pour quelqu'un qui a étudié un minimum comment fonctionne Play Integrity (voir ci dessous pour une micro résumé), l'alternative proposée par Volla, UnifiedAttestation est techniquement foirée. Déjà que Play Integrity repose sur des principes très limites, UA lui, est carrément out.
Toute la sécurité de UA est que leur "Unified Backend" qui tourne sur un téléphone open source (et est en open source) ne soit pas compromis. Or, si tu as un téléphone rooté, rien n'interdit à ce que tu:
1. Remplace le UB par un proxy qui capture les tokens/challenge
2. Génère un token auto signé (avec un certificat installé sur la machine),
3. Simule l'app server et renvoi le token en MITMisant le serveur, tout en fournissant à l'App Server d'origine un faux token et un faux certificat pour capturer et modifier le service (et donc, de fait, capturer les identifiants bancaires et autres informations croustillantes, sans que l'application n'y voit que du feu)
Pour le PI de Google, le principe (et les failles) sont les mêmes, sauf que:
1. La génération du token et la certification du téléphone sont réalisés sans une machine virtuelle métamorphique (c'est à dire que la machine virtuelle est généré dynamiquement par Google, est envoyée via les Play Service qui tournent en root). Le code de vérification est donc spécifique à cette machine virtuelle (dont les instructions, l'obfuscation, les mappings, etc… changent en permanence).
2. Le App Server est géré par Google, et le retour du token passe par la même VM (donc impossible de MITM au passage)
Donc la "force" de Google, c'est d'avoir fait un code qui génère des machines virtuelles à la volée et leur code associé. Ce n'est pas le PI, ce n'est pas l'attestation HW, c'est de la sécurité par l'obscurité.
Le principe, c'est que lorsqu'un hacker casse/rev eng la VM du PI (ce qui demande une charge de travail conséquente), Google regénère une nouvelle VM (sans effort) et tout est à jeter et refaire. C'est un travail de Sisyphe, pas franchement de la sécurité.
Il faut bien comprendre que le jour où la VM est décodée, plus rien n'empêchera un développeur d'écrire une fausse VM qui réponde comme celle de Google mais avec de fausses données et donc permettant le MITM. Et à la vitesse où les LLM de code et de pentest se développent, ce jour est bientôt venu, un modèle de language dont la tâche est de casser la VM de PI va pouvoir le faire en quelques jours (heures?) et ce sera la fin de la sécurité du PI.
Quelles alternatives alors?
C'est simple, c'est comme pour les DRM, il est impossible de fournir une solution technique fonctionnelle de protection logicielle. La seule solution c'est mathématiquement via du chiffrement avec un secret que seul l'utilisateur connaît. On ne peut pas faire confiance à l'utilisateur (et surtout pas son smartphone). Si une donnée doit être validée, c'est pas un canal annexe, extérieur au système de l'utilisateur (par exemple, la validité d'une pièce d'identité doit être signée avec un certificat de l'État, et validée non pas sur le smartphone de l'utilisateur, mais sur celui du représentant de l'ordre). La probabilité que les 2 appareils soient compromis est faible, mais pas nulle. Un virement à l'origine de l'utilisateur doit être considéré comme douteux et validé par une action explicite de l'utilisateur impossible à falsifier (qui doit donc être externe au CPU du système et dont les certificats de signature sont privés et calculés hors du système), etc…
[^] # Re: Unified Attestation est techniquement merdique
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 5 (+3/-0).
Je pense qu'il y a une petite faute de frappe, là, et ça fait un peu vriller à la lecture :)
[^] # Re: Unified Attestation est techniquement merdique
Posté par xryl669 . Évalué à 3 (+2/-0).
Exact. Désolé, mais je peux plus éditer le post.
[^] # Re: Unified Attestation est techniquement merdique
Posté par samantha64 . Évalué à 0 (+1/-1). Dernière modification le 28 juin 2026 à 16:22.
Bref on en revient toujours a ce que disais Ken Thompson dans "Reflections on Trusting Trust".
Et encore faut faire confiance a google et que leur infra soit eux même sécuriser (mdr), mais ça c'est juste la confiance du coter technique, ensuite il y a la confiance du coter légale/national et la je ne comprend pas pourquoi personne n'intervient pas car google est clairement l'un des divers bras droit de la contre intelligence des US.
La FSF la donne depuis des années; Pas de logiciels ou matériels privateur.
Et la raison de ça ce serait pas du a l'illettrisme numérique généraliser ?
Illettrisme numérique qui n'est pas du tout causer par les Gafam.
Comme dit précédemment, logiciel/matériel privateur.
Certe, mais tout comme transporter de l'argent liquide les probabilités d’être voler sont eux aussi non nulle.
Ça n'existe pas mais une grille de nombre ferais l'affaire.
https://linuxfr.org/users/elessar/journaux/les-banques-et-l-authentification-a-deux-facteurs
[^] # Re: Unified Attestation est techniquement merdique
Posté par Stephane21 . Évalué à 0 (+1/-1). Dernière modification le 03 juillet 2026 à 18:53.
Des 3 solutions en lice :
- Google Play Integrity API est un abus de position dominante, car Google certifie les téléphones Android (AOSP + services Google) et cela exclue les téléphones AOSP.
- UnifiedAttestation est la pire des 3 solutions, car elle semble techniquement bidon, et dans le meilleur des cas, si ses failles architecturales étaient comblées, on se retrouverait au mieux dans la même situation qu'avec Google Play Integrity API, le monopole serait juste dans les mains d'une autre entité privée.
- Je ne sais pas si Android Hardware Attestation est souhaitable, mais c'est ce qui me semble le mieux a l'heure actuelle.
Android Hardware Attestation repose sur l'utilisation du "secured element", un système qui me semble très raisonnablement sécurisé, et qui ne nécessite pas de validation de la part de Google.
Android Hardware Attestation, en plus de renvoyer la signature de l'OS pourrait dans l’idéal :
- Attester que le "secured boot" est en place.
- Attester que l'OS est a jour (Android 17.0) et pas plusieurs mois/années en retard, ni uniquement les patchs mensuels de backport.
Les applis bancaires auraient alors a disposition un vrai indicateur de sécurité informatique, au lieu de cet indicateur de sécurité factice (Google Play Integrity API certifie actuellement des téléphones non mis a jour depuis plusieurs années, avec des 100aines de failles 0day, style Xiaomi). Un autre problème étant que 90% des téléphones Android tournent avec un OS passoire qui ne sera jamais mis a jour.
[^] # Re: Unified Attestation est techniquement merdique
Posté par fearan . Évalué à 4 (+2/-1).
Mais c'est quoi cette putain de manie. nombre de téléphone ne sont plus mis à jour quelques années (2 / 3) après mise sur le marché. La seule manière de l'avoir à jour est de déverrouiller le boot loader, et peu de solution permettent de le reverrouiller.
A coté de cela on peut utiliser un pc Windows XP, sans faire sourciller la banque.
J'aimerai bien conserver mon téléphone plus de 10 ans, et si possible sans avoir l'OS google avec ses appli imposées qui enflent à chaque mise à jour
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Unified Attestation est techniquement merdique
Posté par Stephane21 . Évalué à -1 (+0/-1). Dernière modification le 06 juillet 2026 à 08:23.
Il s'agit de la manie de nombreuses banques actuellement, et si elle trouvent un moyen de vérifier qu'un OS est sécurisé, moi je préférerais que cela se fasse sans l'abus de position dominante "Google Play API" ni "UnifiedAttestation".
La situation est bien pire que celle que vous décrivez, hors téléphones Apple, Google, GrapheneOS et peut être certains Samsung haut de gamme, je n'ai jamais vu un seul téléphone portable à jour au moment de sa sortie. Tous les autres téléphones ne sont pas à jour au niveau de soit Android, soit le noyau Linux, soit les drivers, soit les firmwares… Si le bootloader de votre téléphone est déverrouillé, alors beaucoup de gens considéreront qu'il n'est pas sécurisé (a moins que votre code PIN fasse plus de ~15 caractères, dans ce cas là, pas de brute-force possible). Vous sous-entendez que LineageOS permet de garder son téléphone a jour, à ma connaissance ce n'est pas le cas, aucun téléphone LineageOS n'est à jour, LineageOS a constamment plusieurs mois de retard et ne permet pas de reverrouiller le bootloader. LineageOS se concentre principalement sur la couche Android. Il faut aussi savoir que les patchs mensuels Android n'incluent pas toutes les mises a jour de sécurité.
[^] # Re: Unified Attestation est techniquement merdique
Posté par xryl669 . Évalué à 3 (+2/-0).
La mise à jour pour être number one, c'est du vent. Une mise à jour n'a, techniquement, de sens que si elle corrige quelque chose qui est cassé. On nous a bassiné (inculqué?) avec cette fausse idée qu'il faut systématiquement que tous nos logiciels soient à jour, tout le temps, téléchargeant des Go de versions qui corrigent la couleur de fond d'un bouton ou le rayon en pixel de l'arrondi d'un rectangle.
J'ai un téléphone qui est en Android 8 (oui oui) et qui fonctionne toujours comme au premier jour. Pourquoi?
Simplement parce que je ne l'ai jamais mis à jour après avoir flashé la ROM qui me convenait. Pas de version X.Y.Z.trucmuche qui ajoute surtout 2Mo de binaire supplémentaire et qui rame comme un galérien.
Alors, on va me répondre, la sécurité toussa. Le téléphone est rooté, bootloader unlocké, il passe le PI (forcément). Mais je n'ai aucune application Google dessus à part le playstore (impossible de l'enlever ce parasite). Je n'ai pas 150'000 applications et les seules que j'ai installé sont open sources et suffisamment absconses pour que ce ne soit pas intéressant pour un hacker à chercher et trouver une faille. Aucune application ne peut devenir "root" sans passer par un popup système.
J'ai un autre téléphone plus récent, en Android 16, qui ne passe pas le PI, car il est MicroG (et totalement Google free). Au final, c'est une plaie à utiliser au quotidien car les applis "sécuritaires" comme celle des banques, de l'État ne fonctionne pas dessus (mais elles tournent très bien sur un téléphone qui a 10 ans, sans mise à jour depuis). Donc la "protection" qu'apporte AHA ou PI c'est n'est que du vent, du pipeau dans les montagnes. C'est comme celui qui annonce "je fais du E2E crypté sur le Web" et qui distribue le code de cryptographie lui même.
[^] # Re: Unified Attestation est techniquement merdique
Posté par fearan . Évalué à 5 (+2/-0).
Non il permet de le garder plus à jour que le système de base qui est abandonné rapidement après commercialisation, et pourtant l'OS+ application plus à jour est considéré comme non sécurisé alors que celui qui n'a reçu aucune mise à jour de sécurité depuis 5 ans, lui est réputé l'être.
Les banques se cachent derrière 'la sécurité' pour se déresponsabiliser, et au final forcer un achat à leur client.
Les dernières mises à jour officielle de mon téléphone doivent dater de mi-2022 (juin), la dernière mise à jour de sécurité de mon téléphone date de novembre 2025.
Donc j'ai pas forcément le top coté mis à jour, mais c'est quand même largement plus à jour que le système de base.
L'autre problème c'est que même du temps où j'utilisais la ROM de base, le téléphone devenait de plus en plus lent, et avait de moins en moins d'espace sur la partition principale, et l'impossibilité d'installer des appli sur la carte SD rendait ce détail encore plus problématique.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Unified Attestation est techniquement merdique
Posté par fasthm . Évalué à 2 (+0/-0).
La solution est donc d'avoir un téléphone libéré qui fait tourner une vm winxp pour accéder à la banque !
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
[^] # Re: Unified Attestation est techniquement merdique
Posté par pasBill pasGates . Évalué à 1 (+0/-0).
Ai le serveur a un time out de 30s, le LLM qui doit faire tout le reverse engineering et analyse de la VM puis les modifications aura bien du mal.
[^] # Re: Unified Attestation est techniquement merdique
Posté par xryl669 . Évalué à 1 (+0/-0).
Le LLM est utilisé en offline, pour reproduire le code source de la VM à partir du binaire. Le timeout en live, OSEF vu qu'après ce sera le code généré par le LLM qui simulera DroidGuard (et donc qui répondra en mentant au serveur).
On verra, pour l'instant, j'ai vu 2 personnes différentes qui ont fait du rev. eng de ces VM et chacune d'entre elle a laissé tombé pour générer un équivalent, à cause de l’asymétrie de création de code vs le temps de rev. eng.
Avec un LLM, si on tombe sur du "jour" de rev. eng au lieu d'un mois pour un humain, alors c'est game over pour Google. Google ne peut simplement pas redistribuer des milliards de DroidGuard tous les jours.
[^] # Re: Unified Attestation est techniquement merdique
Posté par pasBill pasGates . Évalué à 1 (+0/-0).
Je ne vois pas ce qui empêche Google d'envoyer une VM générée dynamiquement à chaque fois ce qui rend l'analyse offline impossible
[^] # Re: Unified Attestation est techniquement merdique
Posté par xryl669 . Évalué à 1 (+0/-0).
Les protocoles. Quelque soit la VM générée, au final, elle va:
1. Vérifier que ton téléphone est non modifié (check du bootloader, des applis présentes pour détecter des traces d'outils de rootage, etc…)
2. S'assurer du patch de sécurité de ton téléphone
3. Récupérer un token (ou le générer, je ne me souviens plus)
4. Consulter ton TEE pour lui faire signer le token avec le résultat de l'audit (la fameuse Keybox).
5. Envoyer ce token signé à un server PI maintenu par Google (qui va faire des stats sur les envois pour s'assurer que c'est genuine… trop de demande par heure et c'est le ban assuré, car c'est le comportement de ceux qui bidouille pour passer PI, ils font plein de tests jusqu'à ce que ça passe)
6. Le serveur envoie alors le token signé ou un dérivé à un serveur de ton fournisseur d'application, qui digère tout ça et prévient l'application que c'est bon, c'est "valide"
Si tu fais une application qui "agit comme" DroidGuard et contacte le serveur PI (avec des données menteuses), Google peut faire toutes les VM qu'il veut, il ne pourra pas distinguer la substitution. Changer le protocole pour chaque VM "générée" sur le serveur PI qui est utilisé en prod par des milliards de device est très peu probable.
[^] # Re: Unified Attestation est techniquement merdique
Posté par pasBill pasGates . Évalué à 1 (+0/-0). Dernière modification le 09 juillet 2026 à 12:06.
Sauf que la VM , vu qu'elle est générée automatiquement, peut contenir par exemple un secret bien enfoui qui sera aussi passé lors de l'envoi de la réponse (avec un timestamp et signature pour faire joli et éviter le replay) et à moins de faire le reverse engineering de la VM à vitesse supersonique tu ne l'auras pas et le serveur saura que la réponse n'a pas été généré par la VM.
En générant une VM à chaque fois, cela élimine l'analyse offline, et donne en gros 30s pour faire l'analyse de la VM
[^] # Re: Unified Attestation est techniquement merdique
Posté par fearan . Évalué à 3 (+0/-0).
J'ai du mal à suivre comment fonctionne la sécurité avec PI,
l'application réclame un token qui est utilisé pour ensuite utilisé vis à vis du serveur de la banque (ou autre) pour valider les transactions ?
Ou c'est l'appli qui demande 'juste' au système si c'est bon, et dans ce cas il 'suffirait' de modifier l'application pour que l'appel au PI soit remplacé par l'appel a Pl (Play Lazy) qui laisserait tout passer ?
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Unified Attestation est techniquement merdique
Posté par xryl669 . Évalué à 3 (+2/-0). Dernière modification le 08 juillet 2026 à 10:58.
Regarde mon post juste au dessus.
Pour faire très simple, le principe de validation se fait avec 4 entités:
1. Ton device, l'appli qui nécessite la certif PI (A)
2. Un serveur lié à l'appli qui fait la demande de certification (B)
3. Un serveur qui communique via internet avec B, géré par Google (C)
4. DroidGuard (sur ton téléphone) qui dialogue avec (C) et (A) : (D)
La séquence:
1. Lors d'une certif PI, ton appli (A) demande au PlayService de valider ton système. Celui télécharge une VM et la lance via (D).
2. La VM est "obfuscated", mais grosso modo, c'est un spyware qui va scruter ton téléphone en mode root/système pour y détecter toute modification non googlesque.
3. Ton appli (A) va communiquer avec (B) qui va lui donner un token opaque qu'elle va passer à (D)
4. DroidGuard va signer ce token avec la clé publique de Google en y ajoutant toutes les infos issues du spyware (pas très RGPD tout ça, mais passons) et l'envoyer à (C).
5. Le serveur de ton appli (B) va communiquer avec (C) pour lui soumettre le token à vérifier
6. Le serveur PI (C) va s'assurer que le token fourni par (D) est bien signé (donc validation HW validée) et correspond à celui fourni par (B). Il va dire à (B) "Ok c'est bon".
7. (B) va renvoyer un "Go go go" à ton appli (A) pour qu'elle continue de t'afficher des pubs, sinon, c'est la page rouge "erreur VTFF"
Donc toute cette architecture a plusieurs failles:
1. Tu peux MITM le serveur (B) de ton appli. Mais s'il est pas trop débile, tant qu'il n'a pas vu la demande de certif PI, il peut te jeter. Par contre, une fois la demande PI faite, si tu maintiens la session en vie via un MITM, tu peux continuer ad vitam æternam à utiliser l'appli, même sur un autre téléphone. C'est une des fonctions de MicroG d'ailleurs: d'utiliser un téléphone ancien qui passe PI comme proxy DroidGuard.
2. Tu peux pas MITM le serveur (C) car c'est sur internet
3. Tu peux truander DroidGuard avec ton propre "DroidDeguard" qui répond comme l'original mais fait ce qu'il veut. C'est le maillon faible de la chaîne, d'où la technique de sécurité par l'obscurité ici, avec les VM polymorphe de Google. Une fois une VM décodée pour comprendre le protocole utilisé pour dialoguer avec (C), c'est game over. Le protocole a peu de chance de changer, vu le nombre de device en circulation et la lenteur pour certain de se mettre à jour. Si un LLM peut rev. eng. le protocole en un jour, de toute façon, c'est impossible pour Google de mettre à jour ses serveurs prod à cette vitesse.
4. Tu peux hacker l'application (A) pour qu'elle ne fasse pas la demande PI. Mais comme la logique/sécurité du système est très probablement dans (B), tu n'iras pas loin de toute façon, si (B) voit des requêtes sur quelque chose qui est censé arriver après la certif PI, il va te jeter.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.