S/MIME, PGP et Seald - Une comparaison des plus objectives (FR)

lun. 22 octobre 2018 Dan Lousqui

Share on: Twitter - Facebook - Google+

(NDLR: Malgré le titre aguicheur, je tiens à signaler (full disclosure) que je fais parti de l'équipe Seald, ma vision est donc objective de par ma subjectivité (oups)).

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.

Les solutions les plus classiques sont PGP (pour les experts techniques et les particuliers) et S/MIME (en entreprise, pour les employés qui savent que la solution existe). 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.

Chiffrer un email, comment faire ?

(Cette partie est une vulgarisation de la cryptographie, je prends volontairement certains raccourcis, libre à vous d'en discuter en commentaire :-) )

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é" 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.

Les trois protocoles (PGP, S/MIME 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.

1. 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.

2. 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, PGP, S/MIME 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à, PGP et S/MIME 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 a 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 a 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é 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. (A 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. 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. A 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:

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

Le seul compromis étant de devoir stocker ses clés publiques ainsi qu'une partie du secret de déchiffrement des messages sur les serveurs Seald, bien que cela n'ai aucun impact sur la sécurité.

D'autres avantages non abordés sont également présents avec la solution Seald, tels que :

• Possibilité d'envoyer d'un message chiffré pour quelqu'un n'ayant pas la solution;
• Possibilité d'ouvrir ses messages sans installer Seald sur son PC, grâce à l'application mobile Seald ;
• Possibilité de manager et contrôler une équipe;
• Et plein d'autres choses !

Mais cela me donne la possibilité d'écrire d'autres articles dans un futur plus ou moins proche ;-)

Comments