Un outil de base : le chiffrement asymétrique
GPG utilise un chiffrement asymétrique (on parle d'algorithme de chiffrement asymétrique). Cela lui permet de réaliser les fonctions d'authentification et de chiffrement : l'authentification nécessite d'utiliser le chiffrement, même si le but n'est pas de brouiller le contenu numérique lui-même.
Ce chiffrement utilisé est dit asymétrique car il n'y a pas une unique clé secrète (partagée lors d'une rencontre réelle entre l'émetteur et le destinataire) permettant de chiffrer et déchiffrer un contenu, mais une paire de clés -- une clé privée et une clé publique, les deux étant associées, -- créée par chaque utilisateur qui communique un contenu numérique. La clé privée a vocation a rester secrète (c'est un enjeu important) et la clé publique a vocation à être librement communiquée.
Le principe du chiffrement asymétrique en action : avec quelle clé chiffre-t-on un contenu ?
a) Un contenu peut être chiffré par une clé privée. Il peut alors être déchiffré par la clé publique associée. Ce déchiffrement peut être réalisé par quiconque : la clé publique a vocation a être accessible à tous. Cela donne l'assurance que c'est bien le détenteur de la clé privée qui a chiffré le contenu. C'est en exploitant ce principe que l'authentification peut être réalisée. Dans la pratique, du fait que l'algorithme de chiffrement asymétrique est plus gourmand en ressource machine qu'un algorithme de chiffrement symétrique, ce n'est généralement pas le contenu à transmettre qui est chiffré par la clé privée mais une "empreinte" de ce contenu (voir plus bas, les paragraphes sur le contrôle d'intégrité et l'authentification). Ici, « l'utilisateur » destinataire veut authentifier l'émetteur d'un contenu numérique.
b) Un contenu peut être chiffré par une clé publique. Il peut alors être déchiffré par la clé privée associée. N'importe qui peut chiffrer un contenu avec ma clé publique et seul moi, détenteur de la clé privée (restée secrète), pourrai le déchiffrer. C'est en exploitant ce principe que deux interlocuteurs peuvent échanger un contenu chiffré : A chiffre avec la clé publique de B, B déchiffre avec sa clé privée, et réciproquement. Dans la pratique, pour être précis dans le détail, comme exposé au cas a), GPG ne chiffre pas tout le contenu : ici, GPG chiffre le contenu avec un algorithme de chiffrement symétrique (comme 3DES, AES, ...) puis chiffre la clé de chiffrement symétrique utilisée grâce à l'algorithme de chiffrement asymétrique, avec la clé publique du destinataire. Ici, « l'utilisateur » émetteur veut chiffrer un contenu à destination d'une autre personne.
La question de la confiance... dans l'association entre une clé publique librement accessible et l'identité du détenteur de la clé privée correspondante
Dans les deux cas a) et b) précités, l'utilisateur doit obtenir l'assurance que la clé publique qu'il utilise -- pour déchiffrer dans le cas a) et pour chiffrer dans le cas b) -- est bien celle de son correspondant. Pour ce faire, soit les deux interlocuteurs se sont déjà rencontrés physiquement et ont échangé leurs clés publiques (ils ont scellé une relation de confiance), soit ils se font indirectement confiance (par le biais d'un intermédiaire ou de multiples intermédiaires qui constituent une chaine de confiance).
Je vous renvoie à la notion de « Key signing party » (notamment dans les rencontres d'adeptes de logiciels libres) où des personnes échangent ainsi leur clé publique GPG deux à deux (avec un contrôle minimal de l'identité, typiquement la carte d'identité).
Le principe de base du contrôle d'intégrité et ses limites
La fonction de contrôle d'intégrité est assurée notamment par un algorithme générant une « empreinte » d'un contenu numérique, ou encore, une « image » réduite en taille de ce contenu. À la réception d'un contenu et de son empreinte, un destinataire peut s'assurer que le contenu est conforme à l'original de la façon suivante : il génère lui-même l'empreinte de ce contenu avec le même algorithme que l'émetteur et compare cette empreinte avec l'empreinte qu'il a reçue.
Le processus décrit dans ce paragraphe est fiable si et seulement si :
- l'algorithme de génération de l'empreinte est solide, c'est-à-dire si deux contenus distincts ont une très faible probabilité d'avoir une empreinte identique. C'est une vraie question car on découvre parfois des faiblesses dans les algorithmes utilisés. SHA512 est réputé solide, alors que MD5 ou SHA1 présentent des faiblesses. La NSA (National Security Agency, l'Agence de Sécurité américaine) est derrière la plupart de ces algorithmes et ils disposent de bon chercheurs. Cependant, le code source étant libre, il est largement audité par des experts indépendants ;
- le destinataire a l'assurance que l'empreinte qu'il a reçue n'a pas été falsifiée pendant la communication.
Supposons que les deux interlocuteurs puissent échanger l'empreinte d'un contenu lors d'une rencontre réelle, ils ont alors l'assurance de partager une empreinte identique. À ce compte-là, autant échanger directement le contenu lui-même. Si la rencontre réelle n'est pas d'actualité et que l'échange a lieu par un réseau informatique, on peut imaginer que le contenu soit falsifié ainsi que l'empreinte (par un intermédiaire sur le réseau (on parle d'attaque du type « man in the middle » ou « l'homme au milieu » en français)). Si la falsification est bien faite, à la réception, la comparaison entre l'empreinte régénérée et l'empreinte reçue sera valide et le contenu à contrôler sera considéré abusivement comme intègre.
Ainsi, même si l'algorithme de génération de l'empreinte est solide, ce processus utilisé seul n'est pas suffisant. Pour avoir l'assurance que l'empreinte reçue n'a pas été falsifiée, un bon moyen est de chiffrer la communication. La falsification "correcte" de l'empreinte pendant la communication nécessitera alors de casser le chiffrement (on parle de décryptage) et de chiffrer correctement le contenu falsifié.
En accédant à un contenu chiffré par le protocole HTTPS ('S' pour Sécurisé), on obtient un premier niveau de garantie, mais l'algorithme de chiffrement utilisé par HTTPS est réputé théoriquement faible depuis peu.
L'authentification (par signature cryptographique)
Un autre moyen très favorable est d'utiliser le chiffrement asymétrique de GPG sur l'empreinte. C'est en réalité exactement ce que fait le logiciel GPG pour réaliser l'authentification : GPG produit une empreinte du contenu (par un algorithme au choix de l'utilisateur) et chiffre cette empreinte avec la clé privée de l'émetteur. Ainsi, l'authentification et le contrôle d'intégrité sont réalisés dans un même processus. On parle de signature cryptographique ou d'empreinte signée numériquement (chiffrée par une clé privée).
Pour maximiser la sécurité, il est possible pour un collectif d'auteurs de produire autant de signatures cryptographiques qu'il y a d'auteurs (chacun utilisant sa propre clé privée), ce seront autant de fichiers de signatures.
Ceci dit, pour finir, il est très intéressant de noter qu'un auteur (ou un collectif d'auteurs) peut produire et diffuser des contenus « authentifiés » en restant dans l'anonymat. Il conviendra alors de générer une signature cryptographique avec la même clé privée à chaque fois. Les destinataires auront une seule assurance : l'auteur (ou le collectif) est bien le même à chaque fois.
