Création de canaux sécurisés en cryptographie


En cryptographie, il existe deux façons de créer un canal sécurisé entre deux interlocuteurs :

Olvid utilise essentiellement la deuxième façon de faire dans sa version gratuite. Dans tous les cas, Olvid n’impose jamais de tiers de confiance.

1. S’appuyer sur un tiers de confiance

La première méthode permettant de créer un canal sécurisé est de s’appuyer sur un tiers de confiance. Cette méthode est très fréquemment utilisée :

  • Le protocole TLS, par exemple, repose essentiellement sur l’utilisation de certificats, délivrés par une autorité de certification, qui agit comme tiers de confiance.

  • Le standard de chiffrement d’emails S/MIME s’appuie lui aussi sur des certificats délivrés par des autorités de certification.

  • L’immense majorité des messageries instantanées sécurisées (chiffrées de bout-en-bout) utilisent cette architecture, en jouant elle-même le rôle de l’autorité de certification.

Cette architecture présente l’avantage de rendre la sécurité totalement « transparente » pour l’utilisateur final. En revanche, la sécurité est centralisée, assurée exclusivement par l’autorité de certification. Selon Wikipedia :

If the CA can be subverted, then the security of the entire system is lost, potentially subverting all the entities that trust the compromised CA.

Si l’autorité de certification peut être corrompue, alors la sécurité du système tout entier est perdue, entraînant potentiellement la corruption de toutes les entités qui font confiance à cette autorité corrompue.

C’est pour cette raison que les autorités de certification respectent de bonnes pratiques, comme la publication de Baseline Requirements, nécessaires pour être reconnues par les grands navigateurs comme Firefox ou Safari.

Le cas particulier des messageries instantanées sécurisées

À notre connaissance, aucune messagerie instantanée sécurisée (chiffrée de bout-en-bout) n’apporte de garantie similaire à celles imposées aux autorités de certification, alors qu’elles jouent le même rôle de tiers de confiance pour un nombre d’utilisateurs pouvant se chiffrer en milliards. En pratique, cela signifie que tous les utilisateurs d’une messagerie sont forcés (sans le savoir) de faire confiance à un annuaire centralisé, opéré par cette messagerie, qui joue le rôle de tiers de confiance.

Chez Olvid, nous pensons qu’imposer un unique tiers de confiance à près de trois milliards d’utilisateurs n’a strictement aucun sens et n’apporte qu’une illusion de sécurité.

Autrement dit, nous pensons que ces messageries n’apportent pas la sécurité qu’elles prétendent garantir.

« If you build a system where everything comes down to trusting the server, you might as well dispense with all the complexity and forget about end-to-end encryption ».

« Si vous construisez un système où tout se résume à faire confiance au serveur, autant se passer de toute complexité et oublier le chiffrement de bout en bout ».

Matthew Green, cryptography professor at Johns-Hopkins University, Wired

Ou 2. S’appuyer sur la confiance que les interlocuteurs se font entre eux

La seconde méthode permettant de créer un canal sécurisé est de s’appuyer sur la confiance que les interlocuteurs se font déjà entre eux ou, plus formellement, de s’appuyer sur un canal authentique préexistant entre les interlocuteurs. Les cas d’usage de cette méthode sont nombreux :

  • Le standard de chiffrement PGP, surtout utilisé dans le cadre de chiffrement de mails, mais parfois pour le chiffrement de fichiers, tombe dans cette catégorie. En effet, lorsque l’on utilise PGP pour chiffrer des emails, il faut au préalable avoir reçu la clé publique du destinataire (typiquement via un canal non-sûr), et avoir validé l’empreinte de cette clé. Cette dernière étape est cruciale et implique de confirmer, via un canal authentique (comme le téléphone) que l’empreinte de la clé publique reçue correspond bien à celle de la clé publique envoyée. Ceci, de façon à s’assurer que cette clé publique n’a pas été malicieusement modifiée pendant sa transmission sur le canal non-sûr. Cette validation est tristement célèbre, dans la mesure où elle est optionnelle (le chiffrement fonctionnera même si on ne fait pas cette validation) et fastidieuse (il faut s’échanger 32 caractères hexadécimaux). Il est fort probable qu’une part importante des utilisateurs ne se donnent pas cette peine. L’un des problèmes ici est l’utilisation importante qui est faite du canal authentique : 32 caractères à échanger, c’est beaucoup en pratique.

  • Certaines messageries instantanées sécurisées (chiffrées de bout-en-bout) permettent de valider « à la main » que les clés publiques distribuées par leur annuaire centralisé (voir plus haut) sont bien authentiques (autrement dit, qu’elles n’ont pas été malicieusement modifiées par l’annuaire). À l’instar de PGP, un nombre considérables de caractères doivent être échangés sur un canal authentique, typiquement 60 chiffres en base 10. Nous pensons que le nombre d’utilisateurs procédant à cette validation est marginal, tant l’opération est pénible.

L’une des méthodes d’entrée en contact d’Olvid fonctionne sur ce principe. Fort heureusement, nous avons pris soin de limiter l’utilisation du canal authentique à son strict minimum. En pratique, les utilisateurs n’ont besoin d’échanger que 2 × 4 = 8 chiffres sur le canal authentique. Cette validation est extrêmement rapide, raison pour laquelle cette dernière est un préalable obligatoire avant de pouvoir échanger le moindre message. Les protocoles cryptographiques d’Olvid apportent la preuve que la probabilité de réussite d’une attaque est de 1 sur 100 millions.

Olvid ne vous autorisera jamais à créer un canal sécurisé avec un autre utilisateur sans la garantie que c’est bien sa clé que vous avez reçue.