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...
# Unified Attestation est techniquement merdique
Posté par xryl669 . En réponse à la dépêche La certification du matériel appliquée aux ordiphones: la sécurité comme prétexte pour constituer un oligopole ?. É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...