Le chiffrement des emails est une problématique souvent abordée, il n’est plus nécessaire de se justifier, les emails ne sont pas sécurisés ! De plus, avec le nombre croissant de fuites de données et de mots de passe, il devient important de sécuriser ces échanges. Cependant, encore trop peu d’entreprises ont pris l’initiative d’implémenter des solutions répondant à cette problématique.

S/MIME et PGP sont les solutions les plus classiques pour recourir au chiffrement des données au niveau des emails. La solution Seald est (pour le moment) moins populaire. Nous n’aborderons pas le sujet des utilisations / expériences utilisateur des différentes implémentations des protocoles, le but de cet article étant principalement d’expliquer les différences des protocoles, en détaillant leurs fonctionnements, leurs avantages et leurs inconvénients.

S/MIME, PGP, Seald… Chiffrer un email, comment faire ?

(Cette partie est une vulgarisation de la cryptographie, je prends volontairement certains raccourcis).

En cryptographie, il y a principalement deux méthodes de chiffrement : le chiffrement symétrique et asymétrique. Pour faire simple :

  • avec le chiffrement symétrique, la même “clé de chiffrement” permet de chiffrer et de déchiffrer un message ;
  • avec le chiffrement asymétrique, une “clé publique” permet de chiffrer un message, une “clé privée” permet de le déchiffrer.

S/MIME, PGP et Seald utilisent la cryptographie symétrique pour protéger le message, et la cryptographie asymétrique pour protéger la “clé” (symétrique) de déchiffrement du message.

Chiffrer un message

De façon plus détaillée, le chiffrement d’un message d’Alice pour Bob fonctionne ainsi :

  • Alice possède un message en clair qu’elle souhaite envoyer à Bob (ClearMessage) ;
  • Alice va générer une clé symétrique (MessageKey) ;
  • Alice va chiffrer le message à l’aide de la clé symétrique (ProtectedMessage) ;
  • Alice va chiffrer la MessageKey avec la clé publique de Bob (EncryptedMessageKey).

Pour envoyer son message de façon sécurisée, Alice transmet le ProtectedMessage et l'EncryptedMessageKey à Bob. Précisons qu'on parle bien de chiffrer un email ou un document et non de "crypter" un fichier, le terme étant impropre.

Déchiffrer un message

De la même façon, le déchiffrement d’un message par Bob se fera ainsi :

  • Bob va déchiffrer l’EncryptedMessageKey à l'aide de sa clé privée (MessageKey) ;
  • Bob va déchiffrer le ProtectedMessage à l'aide de la MessageKey(ClearMessage).

Et… c’est tout ? Pourquoi tant de chichis ?

Et oui ! Sur ces aspects,S/MIME, PGP et Seald ne diffèrent pas, ça fonctionne bien, c’est sécurisé, et il n’y a pas grand-chose à améliorer (Non, cet article n’est pas sur la crypto post-quantique). Par contre, il y a deux éléments clés qui n’ont pas été abordés :

  • Comment Alice transmet l’EncryptedMessageKey et le ProtectedMessage à Bob ?
  • Comment Alice récupère la clé publique de Bob ?

C’est exactement sur ces sujets que PGP, S/MIME et Seald se différencient !

Transmission de l’EncryptedMessageKey et du ProtectedMessage

PGP et S/MIME

Sur ce sujet-là S/MIME et PGP ont fait le même choix, l’EncryptedMessageKey et le ProtectedMessage sont tous les deux envoyés sur le même support, c'est-à-dire l'email.

Cela à un avantage certain, tout est au même endroit, et il suffit uniquement d’avoir l’email protégé et la clé privée pour le déchiffrer. Cependant, cela apporte quelques désavantages :

  • Si la clé privée est compromise, le message est toujours déchiffrable (même si la clé est révoquée !) ;
  • Si le message doit être envoyé à 10 000 destinataires, il faut créer 10 000 EncryptedMessageKey, cela augmente considérablement la taille du message à envoyer ;
  • Si le destinataire à plusieurs appareils (deux ordinateurs, un smartphone, …), chaque appareil possède sa propre paire de clé publique/privée (il est très mauvais de faire transiter une clé privée d’un poste à un autre). Ainsi si un destinataire fait l’acquisition d’un nouvel équipement, la clé de ce dernier ne pourra pas déchiffrer d’anciens messages, car ceux-ci ne contiendront pas d’EncryptedMessageKey destinée au nouvel appareil.

Seald

Afin de répondre à ces problématiques, Seald a fait le choix de transmettre l’EncryptedMessageKey sur un autre canal : le serveur Seald.

Cela n’a aucun impact sur la sécurité du message, car sans la clé privée, l’EncryptedMessageKey ne sert à rien. Seald n'ayant à aucun moment la clé privée des utilisateurs, cela ne met pas en danger la MessageKey. Ainsi, pour récupérer l'EncryptedMessageKey, le destinataire devra faire une requête (authentifiée) vers les serveurs de Seald, cela engendre de nombreux avantages :

  • Il est possible de révoquer l’accès à un message, même après son envoi. Pour cela, il suffit de supprimer la (ou les) EncryptedMessageKey correspondant sur le serveur Seald, même après envoi du message ;
  • Il est possible d’ajouter des destinataires au message après son envoi. Pour cela, il suffit d’ajouter une (ou des) EncryptedMessageKey sur le serveur Seald ;
  • Si un destinataire fait l’acquisition d’un nouvel appareil, il est possible d’ajouter une EncryptedMessageKey permettant au nouvel appareil de lire les anciens messages ;
  • Il est possible de journaliser toutes les tentatives d’ouverture (succès ou échec) des messages, permettant (par exemple) l’intégration de nouvelles informations dans un SIEM.

Récupération de la clé publique

PGP

PGP est simpliste, mais pas efficace : pour récupérer la clé publique de quelqu’un, il faut que celui-ci vous la transmette. Cela peut se faire par email (mais du coup, cet échange ne sera pas sécurisé) ou par un serveur annuaire. Cette étape est un des talons d’Achile de PGP, ayant pour conséquence d’avoir créé la naissance de “cryptoparty”. Ce n’est clairement pas une solution pérenne dans la vie de tous les jours. (À noter que l’initiative de Keybase pour “lier” des identités numériques sur les réseaux sociaux à une clé PGP est la meilleure alternative à ce jour, selon moi).

S/MIME

S/MIME se base sur le format de certificats numériques X.509. En outre, la clé publique d’un utilisateur est encapsulée dans un certificat, c’est-à-dire qu’elle est signée par une “autorité de certification” à laquelle l’utilisateur doit avoir confiance. C’est le même fonctionnement que pour le protocole TLS (utilisé par HTTPS). Cela permet d’avoir une certaine garantie que la clé publique utilisée pour chiffrer un message est bien la bonne, et qu’aucun intermédiaire malveillant n’a usurpé l’identité de quiconque lors de l’échange de clés. Néanmoins, la récupération initiale de la clé d’un destinataire peut être pénible, mais reste sécurisée.

Seald

Dans le cas de PGP et S/MIME, un problème réside dans le fait qu’il est compliqué de récupérer une clé publique et d’être tenu à jour des “changements” dans les jeux de clés des utilisateurs. Certes, des protocoles existent pour détecter une révocation de clé, mais cela reste rare. Le scénario le plus fréquent étant la perte d’une ancienne clé, pour en créer une nouvelle.

Seald héberge l’ensemble des clés publiques de ses utilisateurs sur ses serveurs sécurisés. Une identité Seald est associée à plusieurs clés publiques (généralement une par équipement). Chaque clé publique est horodatée, et doit être signée par une clé déjà présente sur un compte (cela est régi par ce que l’on appelle la SigChain, un autre article pourra être dédié à l’explication de ce mécanisme). Ainsi il est impossible, à quelqu’un d’autre que l’utilisateur, d’ajouter arbitrairement une nouvelle clé à un compte. À partir de l’email de quelqu’un, il est possible de récupérer son identité Seald ainsi que la liste de ses clés publiques.

Ce mécanisme ne nécessite aucun échange avec le destinataire, les clés publiques peuvent donc être récupérées de façon complètement automatique et transparente. De plus, l’opération peut être réalisée à chaque chiffrement de message, permettant de mettre ces données en cache afin de détecter tous mouvements de clés d’un utilisateur.

Conclusion

Sans trop de surprise, vous vous êtes sans doute rendu compte que j’ai mis Seald en avant face à ses concurrents. En effet, de nombreux avantages sont présents dans Seald qui offre la possibilité de :

  • révoquer des messages post-envoi ;
  • journaliser les accès aux messages ;
  • lire des messages sur plusieurs équipements, sans copier de clés privées ;
  • échanger et mettre à jour les clés de ses contacts automatiquement.

Better Seald than sorry.

Découvrez Seald !