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 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é à 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.