Dans les messagers avec cryptage de bout en bout (E2E), l'utilisateur est responsable de ses clés. Lorsqu'il les perd, il est obligé de réinitialiser son compte.

La réinitialisation d'un compte est dangereuse. Vous effacez les clés publiques et dans toutes les conversations devenez un inconnu cryptographique. Vous devez restaurer votre identité, et dans presque tous les cas, cela signifie une réunion personnelle et une comparaison des «numéros de sécurité» avec chacun des contacts. À quelle fréquence passez-vous vraiment un tel test, qui est la seule protection contre MiTM?

Même si vous êtes sérieux au sujet des numéros de sécurité, vous ne voyez de nombreux partenaires de chat qu'une fois par an lors d'une conférence, donc vous êtes coincé.

Mais cela arrive rarement, non?

À quelle fréquence une réinitialisation se produit-elle? Réponse: dans la plupart des applications de chat E2E tout le temps.

Dans ces messageries instantanées, vous abandonnez la cryptographie et commencez simplement à faire confiance au serveur: (1) chaque fois que vous passez à un nouveau téléphone; (2) chaque fois qu'un interlocuteur passe à un nouveau téléphone; (3) lors de la réinitialisation aux paramètres d'usine du téléphone; (4) lorsqu'un interlocuteur effectue une réinitialisation aux paramètres d'usine; (5) chaque fois que vous désinstallez et réinstallez l'application, ou (6) lorsqu'une personne à qui vous parlez la désinstalle et la réinstalle. Si vous avez des dizaines de contacts, une réinitialisation aura lieu tous les quelques jours.

La réinitialisation se produit si régulièrement que ces applications prétendent que ce n'est pas un problème:

Il semble que nous ayons une mise à niveau de sécurité! (Mais pas vraiment)

Est-ce vraiment TOFU?

En cryptographie, le terme TOFU ("confiance à la première utilisation") décrit un jeu de hasard lorsque deux parties s'expriment pour la première fois. Au lieu de se rencontrer en personne, le médiateur est responsable de chaque côté ... puis, après que les parties se sont présentées, chaque partie surveille attentivement les clés pour s'assurer que rien n'a changé. Si la clé a changé, chaque côté donne une alarme.

Si la clé de l'hôte distant change dans SSH dans une telle situation, elle ne "fonctionnera pas", mais deviendra complètement belliqueuse:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is 00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff Please contact your system administrator. Add correct host key in /Users/rmueller/.ssh/known_hosts to get rid of this message. Offending RSA key in /Users/rmueller/.ssh/known_hosts:12 RSA host key for 8.8.8.8 has changed and you have requested strict checking. Host key verification failed.

Voici le comportement correct. Et rappelez-vous: ce n'est pas TOFU s'il vous permet de continuer à travailler avec un petit avertissement. Vous devriez voir un crâne géant avec des os croisés .

Bien sûr, ces messagers instantanés diront que tout va bien, car l'utilisateur est prévenu. S'il le souhaite, il peut vérifier les numéros de sécurité. C'est pourquoi nous ne sommes pas d'accord:

La vérification n'est pas effectuée car elle se produit trop souvent.
Vérifiez suce.
Même une brève enquête auprès de nos amis soucieux de la sécurité a montré que personne ne s'inquiète de ce test.
Il s'agit donc simplement de faire confiance au serveur et aux SMS (enfin, bien!) Encore et encore .
Enfin, ces applications ne devraient pas fonctionner de cette façon. Surtout lors du changement d'appareils. Un cas normal typique peut être traité sans à-coups et en toute sécurité, et plus la situation est rare, plus elle devrait être pire. Dans une minute, montrez la solution Keybase.

Arrêtez de l'appeler TOFU

Il y a une attaque très efficace. Supposons qu'Eve veuille s'introduire dans la conversation existante d'Alice et Bob et se tenir entre eux. Alice et Bob sont en contact depuis de nombreuses années, ayant depuis longtemps passé TOFU.

Eve fait juste penser à Alice que Bob a acheté un nouveau téléphone:

Bob (Eve): Hé, hé!

Alice: Yo, Bob! Il semble que vous ayez de nouveaux numéros de sécurité.

Bob (Eve): Oui, j'ai acheté l'iPhone XS, un bon téléphone, très content. Échangeons les numéros de sécurité sur le RWC 2020. Hé, avez-vous votre adresse Caroline actuelle? Je veux la surprendre pendant que je suis à San Francisco.

Alice: Je ne peux pas comparer, Android 4 life! Oui, Cosy Street 555.

Par conséquent, il est peu probable que la plupart des messagers chiffrés obtiennent la conformité TOFU. Cela ressemble plus à TADA - faites confiance après avoir ajouté des appareils. Il s'agit d'un problème réel et non fictif, car il crée la possibilité d'une implémentation malveillante dans une conversation préexistante. Dans le vrai TOFU, au moment où quelqu'un s'intéresse à votre conversation, il ne pourra pas l'infiltrer. Avec TADA, c'est possible.

Dans les discussions de groupe, la situation est encore pire. Plus il y a de personnes dans le chat, plus souvent le compte sera réinstallé. Dans une entreprise de seulement 20 personnes, cela se produira environ toutes les deux semaines, selon notre estimation. Et chaque personne dans l'entreprise doit rencontrer cette personne. Personnellement. Sinon, le chat entier est compromis par une taupe ou un pirate.

Solution

Existe-t-il une bonne solution qui n'implique pas la confiance dans les serveurs de clés privées? Nous pensons qu'il existe: un support réel pour plusieurs appareils. Cela signifie que vous gérez une chaîne d'appareils qui représentent votre identité. Lorsque vous recevez un nouvel appareil (téléphone, ordinateur portable, ordinateur de bureau, iPad, etc.), il génère sa propre paire de clés et votre ancien appareil le signe. Si vous perdez l'appareil, «supprimez-le» de l'un des autres. Techniquement, une telle suppression est un rappel, et dans ce cas, il existe également une sorte d'inversion de clé qui se produit automatiquement.

Par conséquent, vous n'avez pas besoin de faire confiance au serveur ou de vous rencontrer en personne lorsque l'interlocuteur ou le collègue reçoit un nouvel appareil . De même, vous n'avez pas besoin de faire confiance au serveur ou de vous rencontrer en personne lorsqu'il supprime l'appareil, s'il n'était pas le dernier. La seule fois où vous devez voir un avertissement, c'est lorsque quelqu'un perd vraiment l'accès à tous ses paramètres. Et dans ce cas, vous verrez un avertissement sérieux, comme il se doit:

Particulièrement laid au maximum

Par conséquent, beaucoup moins de comptes sont réinitialisés et réinstallés. Historiquement, sur Keybase, le nombre total de modules complémentaires et d'avis sur les appareils est dix fois le nombre de décharges de compte (vous n'avez pas besoin de nous croire sur parole, c'est accessible au public dans notre arborescence Merkle). Contrairement à d'autres messageries instantanées, nous pouvons afficher un avertissement vraiment terrifiant lorsque vous parlez à quelqu'un qui a récemment réinstallé les clés.

La gestion des appareils est une opération d'ingénierie complexe que nous avons raffinée à plusieurs reprises. Le périphérique existant signe les clés publiques du nouveau périphérique et chiffre toutes les données secrètes importantes pour la clé publique du nouveau périphérique. Cette opération doit être effectuée rapidement (en une seconde), car nous parlons de la plage d'attention de l'utilisateur. Par conséquent, Keybase utilise une hiérarchie de clés, de sorte que lors du transfert de 32 octets de données secrètes à partir d'un ancien appareil, le nouvel appareil peut voir toutes les données cryptographiques à longue durée de vie (voir la FAQ ci-dessous pour plus de détails). Cela peut sembler un peu surprenant, mais c'est exactement le but de la cryptographie . Il ne résout pas vos problèmes de gestion des secrets, il rend simplement le système plus évolutif.

L'image complète de la sécurité

Nous pouvons maintenant formuler quatre propriétés de sécurité de base pour l'application Keybase:

les clés secrètes durables ne quittent jamais les appareils sur lesquels elles sont créées
la prise en charge complète de plusieurs appareils minimise les baisses de compte
la révocation d'une clé ne peut pas être retardée ou annulée de manière malveillante
secret direct à l'aide de messages horaires éphémères

Les deux premiers semblent compréhensibles. Un troisième devient important dans une conception où le rappel de l'appareil est attendu et considéré comme normal. Le système doit vérifier que les serveurs malveillants ne peuvent pas retarder les examens des appareils, dont nous avons parlé plus tôt .

Consultez notre article sur la messagerie éphémère pour plus d'informations sur la quatrième fonctionnalité de sécurité.

Beaucoup de nouvelle cryptographie, tout est-il correctement implémenté?

Keybase n'a jamais implémenté les fonctions de sécurité de base auparavant et ne l'a même jamais décrit dans des articles scientifiques. Nous avons dû inventer nous-mêmes des protocoles cryptographiques. Heureusement, il existe de nombreux algorithmes de chiffrement standardisés et largement utilisés pour toutes les situations. Tout notre code client est ouvert . Théoriquement, n'importe qui peut trouver des erreurs de conception ou d'implémentation. Mais nous voulions démontrer la structure interne et avons engagé le meilleur cabinet d'audit de sécurité pour une analyse complète.

Aujourd'hui, nous présentons le rapport du Groupe NCC et sommes extrêmement encouragés par les résultats. Keybase a dépensé plus de 100 000 $ en audit et le groupe NCC a embauché des experts de haut niveau en sécurité et en cryptographie. Ils ont trouvé deux erreurs importantes dans notre implémentation, et nous les avons rapidement corrigées. Ces bogues ne pouvaient apparaître que si nos serveurs avaient agi avec malveillance. Nous pouvons vous assurer qu'ils n'agiront pas ainsi, mais vous n'avez aucune raison de nous croire. Voilà la chose!

Nous croyons que l'équipe de la CCN a fait un excellent travail. Respect du temps passé à comprendre pleinement notre architecture et notre implémentation. Ils ont trouvé des erreurs subtiles qui ont attiré l'attention de nos développeurs, bien que nous ayons récemment observé cette partie de la base de code à plusieurs reprises. Nous vous recommandons de consulter le rapport ici ou de consulter notre FAQ.

FAQ

Comment osez-vous attaquer un produit XYZ?

Nous avons déjà supprimé les références à des produits spécifiques de l'article.

Quoi d'autre?

Nous sommes fiers que Keybase ne nécessite pas de numéros de téléphone et puisse vérifier cryptographiquement les identifiants Twitter, HackerNews, Reddit et Github si vous connaissez quelqu'un.

Et ... très bientôt ... il y aura un soutien pour Mastodon.

Qu'en est-il des attaques par redirection de téléphone?

De nombreuses applications sont susceptibles de rediriger les attaques. Eve entre dans un kiosque dans un centre commercial et convainc Bob, l'opérateur mobile, de transmettre le numéro de téléphone de Bob à son appareil. Ou elle convainc le représentant par téléphone. Désormais, Eve peut s'authentifier sur les serveurs de messagerie, affirmant qu'elle est Bob. Le résultat ressemble à notre exemple d'Alice, Bob et Eve est plus élevé, mais Eve n'a pas besoin de pénétrer dans les serveurs. Certaines applications offrent un «blocage d'enregistrement» pour se protéger contre cette attaque, mais par défaut, elles sont ennuyeuses.

J'ai entendu que Keybase envoie des clés privées au serveur?

Au début (2014 et début 2015), Keybase fonctionnait comme une application Web PGP, et l'utilisateur pouvait choisir la fonction pour stocker ses clés PGP privées sur nos serveurs, chiffrées avec des mots de passe (que Keybase ne connaissait pas).

En septembre 2015, nous avons présenté le nouveau modèle Keybase. Les clés PGP ne sont jamais utilisées (et jamais utilisées) dans le chat ou le système de fichiers Keybase.

Comment les anciens chats apparaissent-ils instantanément sur les nouveaux téléphones?

Dans certaines autres applications, les nouveaux appareils ne voient pas les anciens messages, car la synchronisation des anciens messages via le serveur est contraire au secret direct. L'application Keybase vous permet de désigner certains messages - ou des conversations entières - comme «éphémères». Ils sont détruits après un certain temps et sont cryptés deux fois: une fois à l'aide de clés de cryptage de conversation de longue durée, et l'autre à l'aide de clés éphémères changeant fréquemment. Ainsi, les messages éphémères fournissent un secret direct et ne peuvent pas être synchronisés entre les téléphones.

Les messages non éphémères restent jusqu'à ce que l'utilisateur les supprime explicitement et que E2E se synchronise avec les nouveaux appareils de style Slack, uniquement avec cryptage! Par conséquent, lorsque vous ajoutez quelqu'un à une équipe ou ajoutez un nouvel appareil pour vous-même, les messages sont débloqués.

Plus d'informations sur la synchronisation dans le paragraphe suivant.

Parlez-nous des PUK!

Il y a deux ans, nous avons introduit les clés pour les utilisateurs (PUK) . La moitié publique du PUK est annoncée dans la chaîne publique des utilisateurs. La moitié secrète est cryptée pour la clé publique de chaque appareil. Lorsqu'Alice prépare un nouvel appareil, son ancien appareil connaît la moitié secrète de son PUK et la clé publique du nouvel appareil. Il crypte la moitié secrète du PUK pour la clé publique du nouveau périphérique, et le nouveau périphérique télécharge ce texte chiffré via le serveur. Le nouvel appareil déchiffre le PUK et peut accéder immédiatement à tous les messages de discussion de longue durée.

Chaque fois qu'Alice rappelle un appareil, elle change son PUK, de sorte que tous ses appareils, à l'exception du dernier rappelé, reçoivent un nouveau PUK.

Ce schéma de synchronisation est fondamentalement différent du premier système Keybase PGP. Ici, toutes les clés impliquées ont 32 octets de véritable entropie; elles ne cassent pas avec la force brute en cas de piratage de serveur. Certes, si le Curve25519 ou le PRNG de Go est cassé, alors tout se casse. Mais la synchronisation PUK ne fait aucune autre hypothèse cryptographique importante.

Qu'en est-il des discussions en grand groupe?

Les groupes tL; dr ont leurs propres chaînes de signatures auditées pour changer les rôles, ajouter et supprimer des membres.

Les chercheurs en sécurité ont écrit sur les attaques d'utilisateurs fantômes sur les chats de groupe. Si les clients des utilisateurs ne sont pas en mesure de vérifier cryptographiquement l'appartenance à un groupe, les serveurs malveillants peuvent intégrer des logiciels espions et des taupes dans les discussions de groupe. Keybase dispose d'un système très fiable sous la forme d'une fonction spéciale de groupes , dont nous parlerons à l'avenir.

Pouvez-vous parler de NCC-KB2018-001?

Nous pensons que ce bogue est la découverte la plus importante de l'audit NCC. Keybase utilise activement des structures de données immuables pour se protéger contre l'ambiguïté du serveur de l'ajout uniquement. Dans le cas d'un bug, un serveur honnête peut commencer à se dérober: "Je vous ai dit A plus tôt, mais un bug s'est produit, je voulais dire B". Mais nos clients ont une politique commune de ne pas laisser au serveur une telle flexibilité: ils ont des exceptions codées en dur en cas de bugs.

Récemment, nous avons également introduit Sigchain V2 : ce système résout les problèmes d'évolutivité que nous n'avions pas correctement prédits dans la première version. Désormais, les clients sont plus économiques avec les données cryptographiques qu'ils extraient du serveur, ne recevant qu'une seule signature de la queue de la chaîne de signature, plutôt que la signature de chaque lien intermédiaire. Ainsi, les clients ont perdu l'occasion de rechercher par cycles un hachage de signature spécifique, mais nous avons déjà utilisé ces hachages pour rechercher de mauvais maillons de chaîne dans cette liste d'exceptions codées en dur. Nous nous préparions pour la sortie de Sigchain V2, oubliant ce détail enfoui sous plusieurs couches d'abstractions, le système a donc simplement fait confiance au champ à partir de la réponse du serveur.

Une fois que le NCC a découvert cette erreur, le correctif a été assez simple: rechercher des exceptions codées en dur avec un hachage de maillon de chaîne plutôt qu'avec un hachage de signature de maillon de chaîne. Le client peut toujours calculer directement ces hachages.

Nous pouvons également attribuer cette erreur à la complexité supplémentaire requise pour prendre en charge simultanément Sigchain V1 et Sigchain V2. Les clients modernes écrivent des liens Sigchain V2, mais tous les clients doivent prendre en charge les liens v1 hérités pour une durée illimitée. Rappelez-vous que les clients signent des liens avec leurs clés privées pour chaque appareil. Nous ne pouvons pas coordonner tous les clients remplaçant les données historiques dans un délai raisonnable, car ces clients peuvent simplement être hors ligne.

Pouvez-vous parler de NCC-KB2018-004?

Comme en 001 (voir ci-dessus), nous avons été déçus par une certaine combinaison de prise en charge simultanée de solutions obsolètes et d'optimisation, ce qui semblait important à mesure que nous gagnions en expérience avec le système.

Dans Sigchain V2, nous réduisons la taille des chaînes en octets afin de réduire la bande passante nécessaire pour rechercher des utilisateurs. Cette économie est particulièrement importante sur les téléphones portables. Ainsi, nous encodons les maillons de chaîne avec MessagePack , pas JSON , ce qui donne de bonnes économies. À leur tour, les clients signent et vérifient les signatures sur ces chaînes. Les chercheurs de NCC ont trouvé des moyens délicats de créer des «signatures» qui ressemblent à JSON et MessagePack en même temps, conduisant à un conflit. Nous avons involontairement introduit cette ambiguïté de décodage lors de l'optimisation lorsque nous avons basculé les analyseurs JSON de l'analyseur Go standard vers un analyseur plus efficace. Cet analyseur rapide a silencieusement ignoré un tas d'ordures avant de trouver le JSON réel, qui comprenait cette fonctionnalité d'attaque polyglotte. L'erreur est corrigée par une vérification d'entrée supplémentaire .

Dans Sigchain V2, nous avons également accepté la suggestion d' Adam Langley que les signataires précèdent leurs packages avec des signatures par le préfixe de la ligne de contexte et l'octet \0 afin que les vérificateurs ne soient pas confondus par les intentions du signataire. Du côté de la vérification de cette idée de préfixe de contexte, il y avait des erreurs qui pouvaient conduire à d'autres attaques polyglottes. Nous avons rapidement corrigé cette faille avec une liste blanche .

Après avoir corrigé les deux bogues, le serveur rejette les charges malveillantes de l'attaque polyglotte, de sorte que l'exploitation de ces vulnérabilités n'est possible qu'avec l'aide d'un serveur compromis.

Où est la documentation?

https://keybase.io/docs

Au cours des prochains mois, nous consacrerons plus de temps à l'élaboration de la documentation.

Vous pouvez en dire plus sur cette déclaration de NCC: «Cependant, un attaquant peut refuser de mettre à jour sigchain ou de ramener la sigchain d'un utilisateur à un état précédent en tronquant les maillons suivants de la chaîne»

Keybase fait un usage intensif de structures de données publiques immuables qui ne font que s'ajouter, ce qui force l'infrastructure du serveur à capturer une véritable représentation des identifiants des utilisateurs. Nous pouvons garantir le rappel des appareils et la suppression des membres du groupe de manière à ce qu'un serveur compromis ne puisse pas revenir en arrière. Si le serveur décide d'afficher une vue incohérente, cette déviation fait partie du dossier public immuable. Les clients Keybase ou un auditeur tiers peuvent détecter une incompatibilité à tout moment après l'attaque. Nous pensons que ces garanties dépassent de loin les garanties des produits concurrents et sont presque optimales, compte tenu des limites pratiques des téléphones mobiles et des clients disposant d'une puissance de calcul limitée.

Autrement dit, Keybase ne peut pas inventer les signatures de quelqu'un d'autre. Comme tout serveur, il peut contenir des données. Mais notre arbre Merkle transparent est conçu pour les stocker pendant une très courte période de temps, et il est toujours découvrable.

Comment Keybase gère-t-il les réinitialisations de compte?

Lorsque les utilisateurs de Keybase perdent réellement tous leurs appareils (au lieu d'en ajouter de nouveaux ou d'en perdre quelques-uns), ils doivent réinitialiser. Après la réinitialisation du compte, l'utilisateur est fondamentalement nouveau, mais il a le même nom d'utilisateur. Il ne peut pas signer l '«instruction de réinitialisation» car il a perdu toutes ses clés. Donc, à la place, le serveur Keybase valide l'instruction non effaçable dans l'arborescence Merkle, ce qui signifie réinitialiser. Les clients imposent l'impossibilité d'annuler ces instructions. Dans un prochain article, des mécanismes spécifiques seront décrits en détail.

Cet utilisateur devra rajouter des vérifications d'identité (Twitter, Github, peu importe) avec les nouvelles clés.

Un serveur peut-il simplement échanger la feuille d'arbre Merkle de quelqu'un pour annoncer un jeu de clés complètement différent?

Les auteurs de la NCC envisagent un serveur Keybase hostile qui change complètement la feuille d'arbre Merkle, remplaçant le vrai jeu de clés de Bob par un tout nouveau jeu de faux. Un serveur attaquant a deux options. Tout d'abord, il peut bifurquer l'état du monde en plaçant Bob dans une fourchette, et ceux qu'il veut tromper dans une autre. Deuxièmement, il peut "tricher" en publiant une version de l'arbre Merkle avec le jeu correct de clés Bob et d'autres versions avec un faux jeu. Les utilisateurs qui interagissent régulièrement avec Bob découvriront cette attaque, car ils vérifieront que les versions précédemment téléchargées de l'historique de Bob sont des préfixes valides des nouvelles versions téléchargées depuis le serveur. Les validateurs tiers qui analysent toutes les mises à jour de Keybase remarqueront également cette attaque. Si vous écrivez un validateur Keybase tiers que nous aimons, nous pouvons offrir une récompense importante. Reportez-vous à max sur Keybase. Sinon, nous espérons planifier prochainement la création d'un validateur autonome.

Pouvez-vous croire ce que j'ai lu jusqu'au bout?

Lire ou simplement faire défiler vers le bas?

Keybase et vrai TOFU