Parmi les nombreux ajouts d’iOS 16, Automatic Verification devrait être nettement appréciée des internautes. Elle permet d’authentifier automatiquement une personne lors de la présence de certains CAPTCHA, comme la reconnaissance de certains éléments ou une action à effectuer.
MacRumors rapporte qu’Apple a travaillé avec Fastly et Cloudflare pour développer cette authentification automatique. Le mécanisme sera disponible dans iOS 16 et macOS Ventura et sa présence sera détectée par les mesures de sécurité des deux entreprises. Les CAPTCHA ne seront alors pas affichés.
En plus du temps gagné lors de l’inscription à un service par exemple, la technique peut permettre de finaliser une manipulation si Fastly et Cloudflare sont en panne, les CAPTCHA ne s’affichant plus.
Le mécanisme est local, dérivé des Private Access Tokens et fonctionne avec l’Apple ID. Le système part du principe qu’il existe suffisamment de preuves d’activité humaine pour ne pas avoir à faire de manipulation supplémentaire. Le site consulté ne reçoit qu’un signal de confirmation, le système n’envoyant pas d’autres informations.
D'autres prestataires de services pourraient annoncer le support de cette authentification automatique.
Commentaires (12)
#1
Donc les machines qui filtrent les humains trouvent qu’il y a des machines suffisamment en symbiose avec un humain? :p
#2
Quelqu’un peut m’expliquer le principe ?
Le principe du captcha est que le serveur ne fait pas confiance au client pour procéder à la vérification. Si le client dit “oui je suis un mac et je jure sur l’honneur qu’il y a bien un utilisateur”, qu’est-ce qui empêche un robot d’envoyer le même type de message ?
Au mieux, il y aura une clé privée dans chaque Mac. Mais alors cette clé privée est dans l’image d’iOS 16 et peut être extraite. Pas nécessairement par madame Michu, mais une société dont le business est de créer des faux comptes a des ressources à y consacrer.
#3
Vu autrement : Apple a décidé de ne plus aider à entraîner les IA des concurrents.
#4
Tu as des explications sur le blog de CloudFlare par exemple : https://blog.cloudflare.com/eliminating-captchas-on-iphones-and-macs-using-new-standard/
Mais en gros, au lieu de CF ou un autre système tiers qui passe par son algo (en utilisant par exemple une Captcha) pour valider la nature de la requête; là c’est Apple qui vient avec son propre algo inclus dans ses devices pour certifier la même chose.
A première vue c’est basé sur une interaction physique avec l’utilisateur (déverrouillage + mouvements); histoire de compliquer la tâche aux “phone farms” existantes.
Mais j’imagine que ceux-ci vont trouver des moyens de contournement, et Apple devra améliorer son algo, et ils trouveront des moyens de contournement, et…
#4.1
Ok merci c’est un peu plus clair, mais le lien entre le “client” et le “attester” me semble quand-même le maillon faible (moins faible que dans mon idée initiale où c’était “origin” qui validait, mais quand-même)…
#5
Au final c’est plus contre les DDoS que contre les captchas, les deux partenaires étant des CDN… On peut imaginer qu’une mécanique surveillera que le nombre de demandes simultanées n’est pas à anormal au sein de l’OS. En contrepartie de cette garantie, il y a un passe droit qui permet d’échapper à un Captcha
#5.1
De ce que j’ai compris, Cloudflare ne fait pas confiance au terminal (dit “client”, mac ou iBidule). Il fait confiance à un site Apple (le “attester”). Si Cloudflare suspecte (p. ex. à cause d’un nombre anormal de requêtes) que l’attester Apple n’est pas capable de correctement détecter les fraudes, Cloudflare retire sa confiance à Apple et les passe-droits cessent…
Je suspecte que cette confiance ne pourra marcher que sur des configurations propriétaires. Je vois mal comment un Linux que tout le monde peut hacker pourrait contenir du code qui “prouve” que l’utilisateur a déplacé la souris…
#6
Les clefs privées peuvent être stockées dans des enclaves sécurisées et ne sont alors pas extractibles (comme avec une carte à puce) : tu donnes le message à déchiffrer à l’enclave, le code PIN (ou tu poses ton doigt, tu montres ta frimousse, etc.) et l’enclave te le ressort en clair, sans donner la clef privée à l’OS.
Sinon, de ce que j’ai compris, et en très gros :
Depuis ton Mac/iPhone enregistré via ton compte [email protected], tu visites sur un site web NextInpact (au hasard) qui intègre un captcha fourni par CloufFlare. CloudFlare voit (via l’UserAgent) que tu as Safari, et contacte Apple pour savoir si tu es un humain avec un identifiant unique (mais sans lui dire que tu regardes NextInpact). Apple vérifie si [email protected] est bien un compte normal (au besoin en te demandant de poser ton doigt) et répond que c’est bon à CloudFlare.
CloudFlare n’a aucun moyen de connaître tes infos personnelles (qui ne sont pas fournies par Apple), Apple n’a aucun moyen de connaître les sites que tu visites (non fournis par CloudFlare), Google perd un moyen gratuit d’entraîner ses IA et d’enrichir sa base de connaissance des internautes.
Apple y gagne car Google y perd.
#6.1
Merci. J’avais effectivement fini par comprendre cela.
Mais on est bien d’accord : ceci n’est pas transposable de manière simple à autre chose qu’un écosystème fermé. Les choses qui me viennent :
La clé est stockée dans l’enclave sécurisée. Soit. Mais comment y arrive-t-elle ? À un moment ou un autre il faudra bien l’y mettre si elle n’y est pas déjà. Si elle passe par Internet, il est possible de l’intercepter (sauf si elle est chiffrée, mais alors le problème se repose pour la clé de chiffrement de la clé, récursivement). Donc il faut qu’une clé de base soit dans l’enclave dès la fabrication.
Comment le “attester” peut-il être sûr qu’il y a bien un utilisateur humain devant le terminal ? Pour cela, il doit faire confiance au terminal. Ceci n’est possible que sur un système fermé. Un système ouvert peut spoofer les activités de l’humain. C’est le principe fondateur : si un attaquant a un accès physique à la machine, tu ne peux plus lui faire confiance.
Pour être plus clair : “Apple vérifie si […] au besoin en te demandant de poser ton doigt” : comment Apple peut-il vérifier que tu as bien posé ton doigt ? Sur un système ouvert je peux remplacer le lecteur d’empreinte par un truc qui va répondre juste ce qu’il faut (rappel : un lecteur d’empreinte n’envoie pas la photo de l’empreinte à Apple, juste un nombre suffisant de signes distinctifs pour pouvoir l’authentifier sans pouvoir la reproduire)
Par ailleurs, demander aux utilisateurs de lire leure empreinte pour valider un truc aussi trivial que poster un commentaire sur NxI me semble bizarre.
Bref, je salue l’initiative, mais ce n’est pas - jusqu’à ce qu’on me montre le contraire - généralisable à un Linux qui fait tourner Firefox sur une machine custom-built.
#7
Les clefs sont généralement générées par l’enclave sécurisée elle-même, et ça peut être fait à tout moment.
Et pour la lecture d’empreinte, rien n’est envoyé à Apple. Lors de la première capture, un certain nombre de points sont conservés dans l’enclave sécurisée, et lors des vérifications, on vérifie seulement s’ils sont présents.
Ensuite, sur du Linux, il y a toujours une amélioration car la preuve peut être donnée par captcha habituel, mais avec mémorisation par CF et Apple (même si ça ne sera pas Apple en l’occurrence) : tu auras donc moins de captcha à remplir.
Bien sûr, Apple se préoccupe d’abord de son écosystème. Charge aux autres de s’occuper des leurs.
#8
J’entends bien tous tes arguments. Mais le diable est dans les détails…
Oui, mais comment Apple sait-il que la clé a bien été générée par l’enclave sécurisée et pas par un rPi dans un coin ? Ne me dis pas que la clé est authentifiée un certificat numérique, parce qu’alors je te demanderai où est la clé qui a authentifié la clé
À un moment, il a bien fallu qu’une clé soit stockée dans l’enclave et communiquée à Apple de manière sécurisée (ie … en usine).
Une clé générée par madame Michu, ça sert à protéger le terminal de madame Michu, et éventuellement des équipements qui sont sous la responsabilité exclusive de madame Michu (par exemple quand elle uploade sa clé publique sur GitHub pour sécuriser ses git push). Si tu veux protéger le serveur, c’est le serveur qui doit générer la clé. On peut le tourner dans tous les sens, on ne peut pas changer les lois de la physique, Jim ; tu ne peux pas avoir une porte et adapter ta serrure pour accepter une nouvelle clé chaque fois qu’un inconnu t’en envoie une.
Oui, je sais comment fonctionne un lecteur d’empreinte. Mais donc on fait confiance au terminal pour avoir effectivement vérifié les points de concordance…
En pratique une attestation ne pourra pas être réutilisée pendant des heures sans être renouvelée, sinon je mets une ferme de bots et un gus qui passe une fois par jour pour cliquer sur les photos de chats sur chaque machine. Comme un utilisateur lambda se retrouve avec au pire du pire 1 ou 2 CAPTCHA à remplir chaque jour, rarement plus, le gain risque d’être marginal…
Et encore une fois, le protocole ne marche que parce qu’il y a aussi la vérification que l’application en avant-plan est bien celle qu’on veut autoriser… Et ça, ben sur un Linux tu oublies.
Je répète, je suis bien heureux pour les possesseurs de matériel Apple (après tout, j’ai un iPhone…), mais ça ne me semble pas généralisable. Ca marche exclusivement parce que CF a confiance en Apple, et Apple a confiance en l’inviolabilité de ses terminaux. Aucun autre constructeur (à part peut-être Blackberry et autres constructeurs de téléphones pro ultra-sécurisés) ne peut en dire autant.
#9
Ce qui est intéressant dans les questions sur la “généralisation” possible du système, c’est qu’elle n’est posée que du point de vue du client (iDevice ici), alors qu’en fait c’est avant tout un problème côté serveur.
A la base c’est les clients des CDN que sont Fastly et CF qui demandent à protéger leur contenu contre les DDoS et une des stratégies employées est de balancer une Captcha.
Pour éviter les faux négatifs, deux sociétés privées ont mis en place un partenariat technique avec une troisième société privée… pour simplifier les choses pour les clients des trois sociétés.
Le soucis des Captcha ne se pose que pour les services qui souhaitent se protéger en passant par un CDN qui met ça en place comme stratégie.
Pour les services qui ne se protègent pas ou se protègent différemment, le problème des Captchas n’existe pas.
Ça devient forcément complexe de vouloir standardiser et ouvrir un protocole qui en réalité ne vise à résoudre que des problèmes créés par des entreprises privées pour leurs clients.
Pour tenter une comparaison du monde réel… imaginons que tous les jours des vendeurs et autres témoins de Jéhovah viennent sonner chez moi pour tenter de me vendre leur soupe.
Pour m’en prémunir, j’ai installé sur ma sonnette un système de chat automatique qui demande à la personne souhaitant appuyer sur celle-ci, de répondre à une question à laquelle seuls les gens que je souhaite recevoir peuvent répondre, via un clavier. En cas de mauvaise réponse, la personne est arrosée. En cas de bonne réponse, ma sonnette s’active et je suis prévenu de la présence d’une personne “de qualité”.
Ça marche du tonnerre contre les relous, par contre j’ai déjà des amis qui ont fait une faute d’orthographe dans la réponse et se sont trouvés trempés. Et puis ça emmerde mon pote qui passe tous les jours me déposer les pommes récoltées dans la journée.
Pour simplifier les choses, j’ai installé un système sans-contact, il suffit de passer un appareil capable à proximité d’un capteur et ça active immédiatement la sonnette. Sauf que pour faire ça j’ai utilisé un protocole maison, qui nécessite l’achat d’un “badge” spécial pour la personne qui souhaite en profiter et bien entendu je compte sur les personnes intéressées pour l’acquérir elles-même; car j’estime que pouvoir venir chez moi est un immense privilège. Non mais.