Quelle est la sécurité des jetons FIDO U2F

Question

Google et Yubico viennent d'annoncer la disponibilité de jetons de sécurité cryptographiques suivant la spécification FIDO U2F. Est-ce juste une autre option 2FA, ou est-ce bien meilleur que des solutions telles que SecureID et TOTP?

Plus précisément:

En quoi U2F est-il fondamentalement différent de l'OTP?
Comment U2F affecte-t-il la faisabilité des attaques de phishing par rapport aux systèmes OTP?
Dans quelle mesure les attaques non interactives contre U2F sont-elles réalisables (par exemple, force brute, etc.)?
Puis-je utiliser en toute sécurité un seul jeton U2F avec plusieurs services indépendants?
Comment U2F se compare-t-il aux autres offres commerciales? Existe-t-il de meilleures solutions?

tylerl · Accepted Answer

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

Avis de non-responsabilité: Bien que je travaille maintenant pour Google, je ne savais rien de ce projet au moment où la réponse a été écrite. 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 vues ou les intentions de Google.

Bien qu'il vaille la peine de souligner que je l'utilise et le bricole depuis un certain temps maintenant, et en tant que personne qui a 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-y: Google a déployé l'authentification à deux facteurs il y a longtemps. Il s'agit d'une entreprise qui se soucie profondément de la sécurité, et la leur est de premier ordre. Et alors qu'ils utilisaient déjà la meilleure technologie disponible, la sécurité supplémentaire qu'U2F offre au-dessus du facteur 2 traditionnel est si importante qu'elle valait le temps de l'entreprise et de l'argent pour concevoir, développer, déployer et soutenir un système de remplacement qu'ils ne vendent même pas eux-mêmes. Oui, c'est un geste très socialement conscient de leur part de s'engager dans cette voie, mais il ne s'agit pas seulement de la communauté. Google l'a également fait car ils ont eux-mêmes besoin de la sécurité qu'offre U2F. Beaucoup de gens font confiance à Google avec leurs informations les plus précieuses, et certains dans des environnements politiques dangereux font même confiance à Google avec leur vies. Google a besoin de la sécurité pour pouvoir respecter cette confiance.

Cela revient au phishing. Le phishing est un gros problème. C'est extrêmement courant et super efficace. Pour les attaques contre des cibles endurcies, le phishing et les attaques similaires sont vraiment le meilleur pari d'un attaquant, et ils le savent. Et plus important:

Notre protection contre le phishing est risible. Nous avons une authentification à deux facteurs, mais les implémentations offrent peu de défense. Systèmes courants tels que SecurID, Google Authenticator, e-mail, téléphone et SMS - tous ces systèmes offrent aucune protection du tout contre le temps- utiliser des attaques de phishing. Un mot de passe à usage unique est toujours un mot de passe et peut être divulgué à un attaquant.

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

Alors dites que vous êtes Google. Vous avez déployé les meilleures protections disponibles et vous pouvez voir 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

Créer 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, le périphérique 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 fuit accidentellement votre "clé" dans une violation de base de données, cela n'affecte toujours pas votre sécurité ou révèle votre identité. L'utilisation de cet appareil élimine efficacement le phishing comme une possibilité , ce qui est très important 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. Étant donné que Google crée le navigateur le plus populaire, ils peuvent s'assurer qu'il est compatible par défaut. Puisqu'ils fabriquent 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 donner 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 de manière à ce que même les concurrents puissent se l'approprier en toute sécurité. Rien dans la technologie n'est lié à Google - même le matériel est complètement indépendant de l'utilisation.

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

Vous pouvez donc obtenir un seul jeton et l'utiliser 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 de côté. Et depuis Yubico publié les implémentations de référence du logiciel serveur en PHP, Java et Python, obtenir l'authentification et l'exécuter sur votre propre serveur est en toute sécurité à la portée même des petites boutiques.

Natanael · Answer

U2F est capable d'utiliser un canal crypté à l'aide de la cryptographie à clé publique pour garantir que SEULEMENT le bon serveur peut obtenir le jeton unique. Cela signifie que le brancher lorsque 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 comme XSS et les logiciels malveillants locaux.

Il est censé pouvoir masquer 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 les deux. Il est censé être sécurisé.

Il semble que ce soit la meilleure option actuellement disponible, principalement en raison du processus de normalisation en cours et de son large soutien et de son élan.

De la spécification FIDO

Lors de l'inscription à un service en ligne, l'appareil client 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 l'appareil 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 telle que glisser un doigt, saisir un code PIN, parler dans un microphone, insérer un appareil à deux facteurs ou appuyer sur un bouton.

nowen · Answer

Je n'ai pas encore complètement exploré la spécification. Mais:

En quoi U2F est-il fondamentalement différent de l'OTP?
U2F n'utilise pas d'OTP. Il s'agit vraiment de l'authentification du site et de l'utilisation de la possession d'une clé privée comme facteur.
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 contre le phishing (vol d'informations d'identification) car ils sont difficiles à voler. U2F est vraiment destiné à combattre les attaques MiTM.
Quelle est la faisabilité des attaques non interactives contre U2F (par exemple, force brute, etc.)?
Les attaques par force brute ne seraient pas vraiment la voie à suivre. Vous voudriez voler les clés - soit du serveur, soit du client. La façon dont il gère les logiciels malveillants, etc. est essentielle. La mise en œuvre sera très importante.
Puis-je utiliser en toute sécurité un seul jeton U2F avec plusieurs services indépendants?
Bien sûr - c'est pourquoi les clés publiques/privées valent mieux que les secrets partagés.
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 cible dans le serveur d'authentification et le 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. S'ils ne le font pas, une erreur est donnée.

Il n'y a donc pas de modification du serveur ou du navigateur 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'un autre côté, U2F a une dynamique, 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.

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

wvh · Answer

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.

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 vous aider à vous protéger contre les attaques de phishing, car 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 de terminaison vérifié et personne ne doit avoir un accès complet à votre ordinateur; les trucs évidents.

Je suppose que la faisabilité de casser les clés U2F dépendrait de la force des algorithmes de clé publique mis en œuvre sur la clé matérielle spécifique. La clé Yubico semble utiliser l'ECDSA sur la courbe elliptique P-256 NIST. Jugez-en si le nombre de bits (et la source de la courbe) sont suffisamment sûrs et fiables ...

Le document de présentation de FIDO mentionne des "appareils U2F peu coûteux" qui ne stockent pas les clés privées réelles mais les stockent cryptées (encapsulées) dans le "Key Handle", qui est l'identifiant qui relie les clés privées et publiques ensemble et est envoyé à services à distance. Donc, si je le comprends bien, le service distant obtient à la fois les clés publiques (en l'état) et privées (cryptées dans le gestionnaire de clés), de sorte que la sécurité tient vraiment ou tombe avec 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é dans un cookie - ici, le site distant conserve les clés, où la partie clé privée est cryptée et en théorie ne peut ê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 la facilité d'utilisation - stocker beaucoup de paires de clés sur les puces dans ce type d'appareils serait plus cher - mais je ne suis pas sûr que j'aime 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 car 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 sécurité élevée, il serait préférable d'utiliser un appareil qui stocke les clés privées (ou les génère) de manière à ce qu'elles ne puissent pas être récupérées du tout et ne quittez jamais l'appareil. Je ne sais rien du côté électonique de ces appareils, mais je suppose qu'il faudrait un attaquant assez sophistiqué pour voler puis casser 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 chiffrement matériel.

Sources:

Présentation générale: "7. Autoriser les appareils U2F bon marché"

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

Consultez également le document FIDO "format de message brut", auquel SE ne me permet pas de créer un lien car je ne suis pas encore jugé digne.

maxschlepzig · Answer

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

Ainsi, il n'implémente pas la génération 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 nouvellement générée (KA),
un certificat d'attestation (c'est-à-dire la clé publique d'attestation et une signature sur KA utilisant la clé privée d'attestation),
une poignée de clé (H), et
une signature (sur l'Origine, KA et H)

en utilisant la clé privée nouvellement créé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és par une autorité de certification bien connue. Le descripteur de clé est une chaîne qui identifie KA. Tous ces articles sont envoyés à l'origine.

Signer le défi

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

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 transactions internes est calculée (en utilisant la clé privée référencée par le handle de clé) et est renvoyée ainsi que la valeur du compteur.

Implémentations de jetons possibles

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 € sur Amazon: recherchez 'FIDO U2F'). Le Yubikey U2F est un exemple d'une telle implémentation.

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é soit utilisé, on pourrait également essayer de forcer brutalement la clé interne (K0) lorsque vous connaissez le descripteur de clé spécifique à l'origine. Cela n'est possible que si le fournisseur de jetons a fait 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ée par le fournisseur et (volontairement ou involontairement) partagée avec une autre partie - alors cette partie a moins effort pour forcer brutalement une poignée de clé (qui provenait d'un jeton produit par ce fournisseur).
Un autre risque serait une faible implémentation d'un algorithme de chiffrement symétrique utilisé à l'intérieur du jeton, ce qui faciliterait le forçage brut des données chiffrées dans le gestionnaire de clés H.

Certains scénarios phishing et man-in-the-middle sont vaincus car le jeton U2F vérifie l'origine et les données spécifiques à la session sont utilisées comme défi.

Ivan from Russia · Answer

Je pense qu'il est très mauvais que l'utilisateur du token ne voit pas quelle action il/elle accepte réellement en appuyant sur le bouton de son token. Sinon, un utilisateur avec un système d'exploitation infecté sur le PC public non fiable peut involontairement laisser un programme malveillant dans 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 facultatif). Je pense qu'avant de commencer à utiliser ces appareils, il est logique d'attendre l'apparition de jetons U2F avec un petit écran LCD qui affichera ces informations (au moins AppID) et ensuite permettre de une action en désaccord si elle ne correspond pas à ce que vous attendez.