Les réponses que j'ai obtenues ont été bonnes, mais je voulais fournir un peu plus de détails, en expliquant précisément pourquoi le système existe, ce qui devrait expliquer un peu plus ce à quoi il sert.

Clause de non-responsabilité: Bien que je travaille maintenant pour Google, je ne savais rien de ce projet au moment où cette réponse a été rédigée. Tout ce qui est rapporté ici a été recueilli auprès de sources publiques. Ce message est mes propres opinions, observations et commentaires, et ne représente pas les opinions, les points de vue ou les intentions de Google.

Bien qu'il soit intéressant de souligner que j'utilise Ceci et le bricoler depuis un certain temps maintenant, et en tant que personne ayant beaucoup travaillé avec l'ingénierie sociale et les prises de contrôle de compte, je suis démesurément impressionné par ce qui a été accompli ici.

Pourquoi quelque chose de nouveau était nécessaire

Pensez à ceci: Google a déployé l'authentification à deux facteurs il y a longtemps. C'est une entreprise qui se soucie profondément de la sécurité, et la leur a été de premier ordre. Et alors qu'ils utilisaient déjà la meilleure technologie disponible, la sécurité supplémentaire offerte par U2F par rapport aux deux facteurs traditionnels est si importante que l'entreprise en a valu le temps et l'argent pour concevoir, développer, déployer et prendre en charge un système de remplacement qu'ils ne vendent même pas eux-mêmes. Oui, c'est une démarche très socialement consciente de leur part de s'engager dans cette voie, mais ce n'est pas seulement une question de communauté. Google l'a également fait parce qu'eux-mêmes ont besoin de la sécurité qu'offre à eux seuls U2F. Beaucoup de gens font confiance à Google pour leurs informations les plus précieuses, et certains dans des environnements politiques dangereux font même confiance à Google pour leur vie . Google a besoin de la sécurité pour pouvoir garantir cette confiance.

Il s'agit de hameçonnage. Le phishing est un gros problème. C'est extrêmement courant et super efficace . Pour les attaques contre des cibles durcies, le phishing et les attaques similaires sont vraiment le meilleur pari d'un attaquant, et ils le savent. Et plus important encore:

Notre protection contre le phishing est risible. Nous avons une authentification à deux facteurs, mais les implémentations offrent peu de défense. Les systèmes courants tels que SecurID, Google Authenticator, les boucles de messagerie, de téléphone et de SMS - tous ces systèmes n'offrent aucune protection du tout contre les attaques de phishing au moment de l'utilisation. Un mot de passe à usage unique est toujours un mot de passe, et il peut être divulgué à un attaquant.

Et ce n'est pas seulement théorique. Nous avons vu ces attaques effectivement menées. Les attaquants capturent en fait les réponses de second facteur envoyées aux sites de phishing et les lisent immédiatement sur la vraie page de connexion. Cela se produit actuellement.

Alors disons que vous êtes Google. Vous avez déployé les meilleures protections disponibles et vous constatez qu'elles ne sont pas suffisantes. Que faire? Personne d'autre ne résout ce problème pour vous; vous devez le comprendre.

La solution est simple; L'adoption est le vrai problème

La création d'une solution de second facteur qui ne peut pas être hameçonnée est étonnamment simple. Tout ce que vous avez à faire est d'impliquer le navigateur. Dans le cas de U2F, l'appareil crée une paire de clés publique / privée pour chaque site et grave l'identité du site dans le "Key Handle" que le site est censé utiliser pour demander l'authentification. Ensuite, cette identité de site est vérifiée par le navigateur chaque fois avant toute tentative d'authentification. L'identité du site peut même être liée à une clé publique TLS spécifique. Et comme il s'agit d'un protocole défi-réponse, la relecture n'est pas possible non plus. Et si le serveur perd accidentellement votre "Key Handle" lors d'une violation de base de données, cela n'affecte toujours pas votre sécurité ou ne révèle pas votre identité. L'utilisation de cet appareil élimine efficacement le phishing comme possibilité , ce qui est un gros problème pour une organisation sensible à la sécurité.

Ni la crypto ni son application ne sont nouvelles. Les deux sont bien compris et fiables. La technologie n'a jamais été la difficulté, la difficulté est l'adoption. Mais Google est l'un des rares acteurs en mesure de surmonter les obstacles qui retiennent généralement des solutions comme celle-ci. Puisque Google fabrique le navigateur le plus populaire, ils peuvent s'assurer qu'il est compatible par défaut. Puisqu'ils créent le système d'exploitation mobile le plus populaire, ils peuvent s'assurer qu'il fonctionne également. Et comme ils exécutent le service de messagerie le plus populaire, ils peuvent s'assurer que cette technologie a un cas d'utilisation pertinent.

Plus ouvert que nécessaire

Bien sûr, Google aurait pu tirer parti de cette position pour se donnent un avantage concurrentiel sur le marché, mais ils ne l'ont pas fait. Et c'est plutôt cool. Tout le monde a besoin de ce niveau de protection , y compris Yahoo et Microsoft avec leurs offres de messagerie concurrentes. Ce qui est cool, c'est qu'il a été conçu pour que même les concurrents puissent le s'approprier en toute sécurité. Rien dans la technologie n'est lié à Google - même le matériel est totalement indépendant de l'utilisation.

Le système a été conçu en supposant que vous ne l'utiliseriez pas uniquement pour Google. Une caractéristique clé du protocole est qu'à aucun moment le jeton ne s'identifie lui-même . En fait, les spécifications indiquent que cette conception a été choisie pour empêcher la possibilité de créer un "supercookie" qui pourrait être utilisé pour vous suivre entre des services de connivence.

Vous pouvez donc obtenir un jeton unique et utilisez-le en toute sécurité non seulement sur Gmail, mais également sur tout autre service prenant en charge U2F. Cela vous donne beaucoup plus de raisons de mettre de l'argent pour un. Et depuis que Yubico a publié des implémentations de référence du logiciel serveur en PHP, Java et Python, la mise en place de l'authentification sur votre propre serveur est en toute sécurité à la portée des petits magasins.

U2F est capable d'utiliser un canal chiffré à l'aide de la cryptographie à clé publique pour s'assurer que SEUL le bon serveur peut obtenir le jeton unique. Cela signifie que le brancher sur un site de phishing signifie que rien ne se passe - ils ne peuvent pas accéder à votre compte. Au lieu de cela, ils doivent s'appuyer sur des attaques techniques telles que XSS et des logiciels malveillants locaux.

Il est censé pouvoir cacher le fait que vous utilisez le même appareil pour plusieurs services, de sorte que quelqu'un qui contrôle à la fois le site A et le site B ne peut pas voir que vous avez utilisé le même appareil sur tous les deux. Il est censé être sécurisé.

Cela semble être la meilleure option disponible actuellement, principalement en raison du processus de normalisation en cours et de son large soutien et de son élan.

À partir de la spécification FIDO

Lors de l'inscription à un service en ligne, la machine cliente de l'utilisateur crée une nouvelle paire de clés. Il conserve la clé privée et enregistre la clé publique auprès du service en ligne. L'authentification est effectuée par le périphérique client prouvant la possession de la clé privée du service en signant un défi. Les clés privées du client ne peuvent être utilisées qu'après avoir été déverrouillées localement sur l'appareil par l'utilisateur. Le déverrouillage local est accompli par une action conviviale et sécurisée, comme glisser un doigt, saisir un code PIN, parler dans un microphone, insérer un appareil à second facteur ou appuyer sur un bouton.

Je n'ai pas encore complètement exploré les spécifications. Mais:

1. En quoi U2F est-il fondamentalement différent d'OTP?
   U2F n'utilise pas d'OTP. Il s'agit en réalité de l'authentification du site et de l'utilisation d'une clé privée comme facteur.

2. Comment U2F affecte-t-il la faisabilité des attaques de phishing par rapport aux systèmes OTP?
   Les systèmes OTP limités dans le temps font un excellent travail de lutte hameçonnage (vol d'informations d'identification) parce qu'ils sont difficiles à voler. U2F est vraiment destiné à combattre les attaques MiTM.

3. Dans quelle mesure les attaques non interactives contre U2F (par exemple par force brute, etc.)?
   Les attaques par force brute ne le seraient pas vraiment le chemin à parcourir. Vous voudriez voler les clés - du serveur ou du client. La manière dont il gère les logiciels malveillants, etc. est essentielle. La mise en œuvre sera très importante.

4. Puis-je utiliser en toute sécurité un seul jeton U2F avec plusieurs services indépendants?
   Bien sûr - c'est pourquoi public / privé les clés valent mieux que les secrets partagés.

5. Comment U2F se compare-t-il aux autres offres commerciales? Existe-t-il de meilleures solutions?
   Je ne peux parler que de la nôtre, qui est à la fois dans nos versions commerciales et open-source. La principale différence est que nous stockons un hachage du certificat ssl du site ciblé dans le serveur d'authentification et livrons avec un OTP chiffré par la clé privée du serveur d'authentification. Avant que l'utilisateur n'obtienne l'OTP, le jeton logiciel récupère le certificat du site cible via la connexion de l'utilisateur, le hache et compare les deux. S'ils correspondent, l'OTP est présenté, copié dans le presse-papiers et le navigateur est lancé dans l'url. Si ce n'est pas le cas, une erreur est donnée.

   Aucune modification du serveur ou du navigateur n'est donc nécessaire. Les clés sont stockées sur un serveur distinct du serveur Web. L'OTP fait partie du processus (bien qu'il puisse être supprimé / masqué). C'est open-source. D'autre part, U2F a un élan, bien qu'il s'agisse d'un consortium «pay-to-play». U2F est disponible sur certaines offres matérielles «sécurisées». Les nôtres peuvent être implémentés sur eux (par exemple, un lecteur crypto-USB). YMMV.

   Pour plus d'informations sur l'authentification mutuelle de WiKID, cliquez ici: https://www.wikidsystems.com/learn-more/technology/mutual_authentication et un guide ici: http://www.howtoforge.com/prevent_phishing_with_mutual_authentication.

Je viens de lire certaines des spécifications parce que je voulais savoir si l'appareil stockait les clés (privées) réelles. Je peux essayer de répondre à certaines des questions.

Les OTP sont simplement des jetons à usage unique, tandis que U2F est basé sur la cryptographie à clé publique; plus précisément, la clé Yubico Fido U2F semble utiliser la cryptographie à courbe elliptique.

U2F devrait aider à se protéger contre les attaques de phishing puisque vous devez confirmer la transaction par une intervention manuelle, c'est-à-dire en appuyant sur le bouton. Voler les clés nécessiterait de voler l'appareil lui-même, ce qui pourrait être plus difficile que les broches OTP, selon l'endroit où les gens les stockent. Bien sûr, les deux approches sont encore quelque peu vulnérables aux attaques MitM; si un attaquant peut d'une manière ou d'une autre s'interposer entre vous et le service, interférer dans une session en cours, il n'y a pas grand-chose à faire. Le trafic doit être chiffré, le point final vérifié et personne ne doit avoir un accès complet à votre ordinateur; les choses évidentes.

Je suppose que la faisabilité de casser des clés U2F dépendrait de la force des algorithmes de clé publique implémentés sur la clé matérielle spécifique. La clé Yubico semble utiliser ECDSA sur la courbe elliptique P-256 NIST. Jugez vous-même si le nombre de bits (et la source de la courbe) sont suffisamment sécurisés et fiables ...

Le document de synthèse de FIDO mentionne des "appareils U2F peu coûteux" qui ne stockent pas les clés privées mais stockez-les cryptées (enveloppées) dans le "Key Handle", qui est l'identifiant qui relie les clés privées et publiques et est envoyé aux services distants. Donc, si je comprends bien, le service distant obtient à la fois les clés publiques (telles quelles) et privées (cryptées dans le descripteur de clé), de sorte que la sécurité est vraiment conforme à la sécurité de l'algorithme utilisé sur le périphérique matériel; le site distant a vos clés privées! D'une certaine manière, c'est l'inverse du stockage de la session d'un utilisateur cryptée dans un cookie - ici, le site distant conserve les clés, où la partie clé privée est cryptée et ne peut en théorie être décryptée que par le périphérique matériel. Fait intéressant, cet appareil Yubico lui-même semble être un tel appareil, c'est-à-dire que les clés quittent l'appareil au lieu d'y être contenues.

Je comprends les motivations économiques et de facilité d'utilisation - stocker beaucoup de clés les paires sur les puces de ce type d'appareils seraient plus chères - mais je ne suis pas sûr d'aimer cette approche.

Donc, pour revenir à votre question sur l'utilisation des jetons avec plusieurs services indépendants: l'appareil peut générer autant de paires qu'il le souhaite puisque les paires de clés sont enregistrées sur le service lui-même. Lorsque vous vous connectez, l'appareil déballe la clé privée et vérifie la signature. Le message contient l'origine, donc la clé ne devrait fonctionner que pour ce service spécifique.

Pour des raisons de haute sécurité, il serait préférable d'utiliser un appareil qui stocke les clés privées (ou les génère) de la manière dont elles ne peut pas être récupéré du tout et ne quittez jamais l'appareil. Je ne sais rien du côté électronique de ces appareils, mais je suppose qu'il faudrait qu'un attaquant assez sophistiqué vole puis craque le matériel physique pour obtenir les clés, en supposant que l'appareil utilise les mêmes puces que celles utilisées sur les cartes à puce modernes , sims et autres formes de cryptographie matérielle.

Sources:

• Présentation générale: "7. Autoriser les appareils U2F peu coûteux"

• Considérations d'implémentation: "Les jetons U2F peuvent ne pas stocker le matériel de clé privée, et peuvent plutôt exporter une clé privée encapsulée dans le cadre du descripteur de clé."

• Vérifiez également le document FIDO "format de message brut".

Un jeton U2F implémente un algorithme de réponse au défi utilisant la cryptographie à clé publique. Il fournit deux fonctions: enregistrer une nouvelle origine et calculer la réponse à un défi.

Ainsi, il n'implémente pas la génération de One Time Password (OTP).

Enregistrement d'une nouvelle origine

(Une chaîne d'origine identifie le système distant, par exemple le nom d'hôte du serveur distant.)

Lors de l'enregistrement d'une nouvelle origine, le jeton prend la chaîne d'origine en entrée et renvoie

• une clé publique (KA) nouvellement générée,
• un certificat d'attestation (c'est-à-dire la clé publique d'attestation et une signature sur KA en utilisant la clé privée d'attestation) ,
• un handle de clé (H), et
• une signature (sur l'origine, KA et H)

en utilisant le nouvellement créé Clé privée. La paire de clés d'attestation est partagée entre un groupe de périphériques produits par le même fournisseur et généralement signée par une autorité de certification bien connue. Le descripteur de clé est une chaîne qui identifie KA. Tous ces éléments sont envoyés à l'origine.

Signature du défi

Lors de la signature d'un défi (c'est-à-dire en générant la réponse), le jeton prend la chaîne d'origine, les données de défi (contenant les informations de session) , et un descripteur de clé en entrée.

• Si l'origine ne correspond pas à l'origine au moment de la génération du descripteur de clé, une erreur est renvoyée.
• Si le descripteur de clé est inconnu , une erreur est renvoyée.
• Sinon, la signature sur les données de défi et la valeur d'un compteur de transaction interne sont calculées (à l'aide de la clé privée référencée par le descripteur de clé) et sont renvoyées ainsi que la valeur du compteur.

Implémentations de jetons possibles

1. Une implémentation de jeton U2F valide a un tableau associatif inscriptible potentiellement important où les poignées de clé sont mappées aux clés privées et aux informations d'origine. Ce tableau ne doit pas quitter ce jeton et doit donc être protégé contre sa lecture.

   La spécification U2F ne permet pas la réutilisation de clés privées pour différentes origines; donc, un grand tableau est nécessaire.

2. Alternativement, une implémentation de jeton U2F sans aucune mémoire en lecture-écriture est également possible: au lieu de stocker le privé key et l'origine à l'intérieur du token, le token les crypte symétriquement avec une clé interne (K0). Le résultat est ensuite simplement renvoyé comme poignée de clé. Dans une conception matérielle saine, K0 ne peut pas quitter le jeton. En d'autres termes, la clé privée et la chaîne d'origine sont stockées en externe, elles sont distribuées aux origines car elles sont utilisées comme descripteurs de clé - ce qui est bien tant que le chiffrement ne peut pas être rompu.

Fondamentalement, la plupart des jetons U2F disponibles implémentent la deuxième méthode, et sont donc relativement peu coûteux à produire (à partir d'environ 5 € chez Amazon: recherchez 'FIDO U2F'). Le Yubikey U2F est un exemple d'une telle implémentation.

Les attaques

Dans des circonstances normales, les attaques par force brute devraient être irréalisables. Une telle attaque serait d'essayer de forcer brutalement la clé privée spécifique à l'origine lorsque vous connaissez la clé publique.

• En supposant qu'un jeton U2F bon marché est utilisé, on pourrait également essayer de forcer brutalement le key (K0) lorsque vous connaissez la poignée de clé spécifique à l'origine. Cela n'est possible que si le fournisseur de jetons a commis une erreur de conception. Par exemple, lorsque le fournisseur expédie chaque jeton avec la même clé interne et que la clé fuit d'une manière ou d'une autre.
• Ou, dans le cas où la clé interne K0 est: différente pour chaque jeton mais K0 ne peut pas être réinitialisée par l'utilisateur final, est conservé par le fournisseur et (volontairement ou involontairement) partagé avec une autre partie - alors cette partie a moins d'efforts pour forcer brutalement une poignée de clé (qui provient d'un jeton produit par ce fournisseur).
• Un autre risque serait une faible implémentation d'algorithme de chiffrement symétrique utilisé à l'intérieur du jeton, facilitant ainsi le forçage brutal des données chiffrées dans le descripteur de clé H.

Certains scénarios de phishing et d'intermédiaire sont rejetés car le jeton U2F vérifie l'origine et les données spécifiques à la session sont utilisées comme défi.

Je pense qu'il est très mauvais que l'utilisateur du jeton ne voie pas quelle action il / elle accepte réellement en appuyant sur le bouton de son jeton. Sinon, un utilisateur avec un système d'exploitation infecté sur le PC public non approuvé peut involontairement laisser un programme malveillant accéder à son propre compte bancaire au lieu de se connecter à Facebook.

Cependant, le protocole U2F contient des informations sur l'action en cours (URI, AppID et ID de canal TLS en option). Je pense qu'avant de commencer à utiliser ces appareils, il est logique d'attendre l'apparition des jetons U2F avec un petit écran LCD qui affichera ces informations (au moins AppID) et permettra ensuite de ne pas être d'accord si cela s'avère être pas quoi vous attendez.