Trois jours après son lancement, l’application européenne de vérification d’âge accumule les failles de sécurité. Un chercheur a tout contourné en éditant un fichier texte.
C’est un poisson d’avril cette application !
3 « J'aime »
Un piège assez classique. On présente une proposition technique douteuse. Ensuite on corrige l’aspect technique et tout va bien on peut lancer le projet. Entre temps personne n’aura parlé du fond
4 « J'aime »
Je ne suis pas convaincu que ce soit corrigeable. Même s’ils corrigent le « fichier de config » en le chiffrant de façon à interdire sa modification, un tel chiffrage ne peut pas être fermé (il y a forcément la clé de déchiffrement dans le logiciel ou quelque part). Il faudrait pouvoir stocker la clé dans le TEE de l’appareil (l’enclave sécurisée), mais pas tous les téléphones Android ont un TEE (ou un TEE fonctionnel). Bref, toute tentative de chiffrement est vouée à l’échec d’une manière ou d’une autre, à part si l’authentification est faite à distance, par un serveur non corruptible, ce qui casserait, de fait, la notion de « non connaissance » de ton activité. En gros, c’est mort techniquement et il n’y a pas de solution technique viable qui permette de le faire correctement.
3 « J'aime »
Il y a un ‹ s › en trop dans ton affirmation.
4 « J'aime »
A la lecture de votre article on peut se demander quel est le degré de professionnalisme avec lesquels les développeurs ont travaillé a la réponse a un appel d’offre de cette importance !
Si l’on veut garder un peu d’optimisme, ont dira que le caractère open source du code a démontré son efficacité et permettra collectivement améliorer cette bouse … A moin qu’il soit plus pertinent de repartir d’une page blanche 
2 « J'aime »
Après lecture du code, il semble que ce n’est pas si mal en fait, je pense. L’interface « finale » (c’est à dire l’UI qu’il y a sur Android et iOS) est pourrie, comme souvent, mais heureusement, ça n’a pas été fait en Flutter ou ReactNative, mais en natif pour chaque plateforme, ce qui est plus facile à lire, AMHA.
Les erreurs de stockage des infos d’accès (PIN + Biométrie) sont finalement corrigeable je pense (contrairement à ce que j’affirmais plus haut).
Le PIN entré devrait être utilisé après déduction par PBKDF comme clé de chiffrage maître des certificats créés dans la BDD SQLite qu’ils utilisent (au lieu qu’il soit indépendant comme actuellement). Le fichier devrait avoir des slots de « tests » (chaque test de pin erroné détruit un slot et contacte le KeyStore d’Android pour modifier le fingerprint du fichier en cours). Lorsque les 3 slots sont brûlés, le fichier est détruit, il faudra tout réimporter.
Pour éviter une attaque à « froid », il faut que le fingerprint du fichier soit stoqué dans le KeyStore d’Android (possibilité d’écriture et de vérification avec une clé privé dans le KeyStore mais pas de lecture de la clé privée pour forger une autre signature)
Si un petit malin copie le fichier avant un test (backup) et le restore après un test de PIN erroné, le fingerprint est vérifié avec le KeyStore d’Android et il ne passera plus, vu que le fingerprint mis en secret est celui du 2eme slot, pas du premier. Du coup, écrasement du fichier de donnée, tout est détruit, game over.
Évidemment, un test système peut être contourné sous un débuggeur qui arrêterait l’application juste après le test du PIN et avant le « grillage » du slot, mais cela reste une technique très compliquée à mettre en œuvre pour un gain très hypothétique.
Si le PIN est bon, les slots manquant de tests PIN sont recréés, et c’est reparti.
Cette solution reste locale, offline mais sécurisée. Il est donc possible de faire ce que le système prétend pouvoir faire.
1 « J'aime »
Comment ça « tous les téléphones n’ont pas un TEE fonctionnel » ?
J’ai jamais vu de device sans TEE hein, même pour les sombres trucs chinois ça marche
En fait c’est pas compliqué le device refuse de boot sans tee donc…
Quand des ânes choisissent des amateurs pour faire le boulot. Ce serait pas un problème récurrent en France et en Europe aujourd’hui?
1 « J'aime »
Je pense que l’article se veut un peu « spectaculaire ». La gestion du code PIN et de l’empreinte digitale n’est pas top, mais en soi, le protocole de vérification d’identité n’y est pas lié. Là, il s’agit d’une implémentation spécifique de ce protocole dans une application. En effet, le protocole n’est justement pas fait pour servir de « justificatif d’identité » permanent ; c’est seulement pour des vérifications ponctuelles (genre quand tu crées un compte en ligne) et ensuite, aucune donnée ne doit rester sur l’appareil (scan de passeport/carte d’identité). Et oui, si quelqu’un a accès à ton compte ou ton appareil une fois la vérification effectuée, il sera catégorisé comme majeur alors que l’utilisateur peut être mineur, mais c’est aussi aux gens de faire attention à qui ils confient leur appareil ou leur compte.
Bon, là, l’implémentation sur l’application n’est pas folle, c’est vrai. Mais ne pas confondre, implementation et protocol. Les limitations du protocole s’expliquent aussi par le fait qu’il permet de prouver la majorité sans avoir à fournir ou donner accès aux données d’identité aux développeurs d’applications. Je pense que c’est une bonne chose, car si chaque application se retrouvait avec une copie de nos données pour vérifier notre identité, je trouverais ça pas acceptable non plus.
1 « J'aime »
Déjà, tous les téléphones avec un Android 9 ou précédent n’ont pas de TEE. Ensuite pour les téléphones ultérieurs à Android 9, tu peux avoir un TEE (hardware) ou pas. Si tu n’as pas de TEE, le fabricant peut implémenter StrongBox, qui, dixit Google:
Les appareils compatibles équipés d’Android 9 (niveau d’API 28) ou d’une version ultérieure peuvent disposer de StrongBox Keymaster, une implémentation du HAL Keymaster ou Keymint qui se trouve dans un composant sécurisé de type module matériel de sécurité. Bien que les modules matériels de sécurité puissent faire référence à de nombreuses implémentations différentes de stockage de clés sans qu’un compromis du noyau Linux ne les révèle, comme le TEE, StrongBox fait explicitement référence à des appareils tels que des composants sécurisés intégrés (eSE) ou des unités de traitement sécurisé (iSE) sur SoC […] Si le processus de l’application est compromis, le pirate informatique peut utiliser les clés de l’application, mais ne pourra pas en extraire le matériel (par exemple, pour l’utiliser en dehors de l’appareil Android).
Ou tu peux implémenter un TEE en faisant tourner un autre noyau via Trustee en amont de Linux (le kernel devient l’un des 2 processus de ce noyau) en utilisant la TrustZone des processeurs ARM.
Ça c’est pour la théorie. Dans la pratique, je n’ai jamais rencontré d’implémentation de Trustee. On peut désactiver le TEE très facilement étant root (il y a un module Magisk pour cela) ce qui fait croire à Android qu’il n’y a pas de TEE hardware et qui l’oblige donc à utiliser une solution à base de « fake StrongBox » (qui tourne sur un pseudo « container » et donc visible par le noyau et du root).
Un refus de boot, c’est parce que le bootloader est fermé. Un device avec un bootloader fermé de toute façon est une plaie pour l’humanité. C’est un spyphone où tu ne peux pas savoir ce que fait ton téléphone (il peut tout à fait faire tourner Linux/Android dans un container/VM/VE et espionner tout ce que tu fais et tu ne peux pas le savoir). Si tu as un bootloader ouvert, tu peux installer un noyau Linux qui a, ou pas, un driver TEE réel ou un fake qui simule le TEE en effectuant les opérations en soft, et il bootera sans le moindre soucis (c’est ce que j’ai sur mon téléphone). Évidemment, lors de l’installation d’une telle ROM, tu perds la ROM d’origine, vu que tu n’as plus accès aux clés pour décrypter la ROM d’origine, mais par définition, c’est ce que tu veux non?
Quelle belle bande d’amateurs - clowns de première classe … et on doit leur faire confiance ?!