NdM.: cette dépêche a été réécrite en avril 2021 suite à la suppression du compte de son auteur principal.
Le logiciel libre GPG (« Gnu Privacy Guard ») permet la transmission de messages électroniques signés et chiffrés, garantissant ainsi leurs authenticité, intégrité et confidentialité (Wikipédia). Il permet donc de sécuriser un contenu numérique lorsqu'il est stocké ou échangé.
Détaillons les éléments de la sécurisation des communications numériques :
- le contrôle d'intégrité : vérification de l'absence d'altération du contenu (conforme à l'original) ;
- l'authentification : s'assurer de l'identité de l'auteur ;
- le chiffrement : le message est illisible pour des yeux indiscrets.
GPG est la version libre (au sens de logiciel libre) du logiciel PGP (« Pretty Good Privacy »).
Un outil de base : le chiffrement asymétrique
Le chiffrement asymétrique 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.
Le nom asymétrique vient du fait qu'il ne s'agit pas d'une unique clé secrète qui aurait été définie lors d'une rencontre physique entre l'émetteur et le destinataire, mais une paire de clés. Il y a donc une clé privée et une clé publique, associées. La paire est créée par chaque utilisateur qui veut communiquer un contenu numérique. La clé privée doit rester secrète et la clé publique peut être librement communiquée.
Chiffrement asymétrique : avec quelle clé chiffre-t-on ?
a) Un contenu peut être chiffré par une clé privée. Il peut alors être déchiffré par la clé publique associée (qui est potentiellement accessible à tous). Ainsi on vérifie que c'est le détenteur de la clé privée qui a chiffré le contenu. Ce principe permet l'authentification. Le fait qu'un algorithme de chiffrement asymétrique soit consommateur de ressource machine qu'un algorithme de chiffrement symétrique conduit à ne l'utiliser que sur une empreinte du contenu. Ce cas permet donc au destinataire d'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 (tout le monde peut utiliser la clé publique pour chiffrer et seul le détenteur de la clé privée pourra déchiffrer). Ce principe mert d'échanger un contenu chiffré : l'émetteur chiffre avec la clé publique du destinataire, le destinataire déchiffre avec sa clé privée, et réciproquement. Pour des raisons de consommation de ressources, le contenu est chiffré avec un algorithme de chiffrement symétrique (comme AES par exemple) et la clé de chiffrement symétrique est transmise via l'algorithme de chiffrement asymétrique, avec la clé publique du destinataire. Ce cas permet donc à l'émetteur de chiffrer un contenu à destination du destinataire.
La confiance, ou comment faire le lien entre une clé publique librement accessible et l'identité du détenteur de la clé privée correspondante
Dans les deux cas précédents, il faut s'assurer que la clé publique utilisée est bien celle du correspondant souhaité. Il faut soit que les deux interlocuteurs se sont déjà rencontrés physiquement et aient échangé leurs clés publiques, soit qu'ils se fassent indirectement confiance (via un ou plusieurs intermédiaires à travers chaine de confiance).
Voir le lien sur les « Key signing party ».
Le contrôle d'intégrité
Le contrôle d'intégrité repose sur l'« empreinte » du contenu (une version réduite de ce contenu). Le destinataire va pourquoi calculer lui aussi de son côté l'empreinte et comparer. Le processus est fiable si et seulement si :
- l'algorithme de génération de l'empreinte est solide, donc qu'il y a peu de chances d'avoir une même empreinte, une collision ;
- le destinataire a l'assurance que l'empreinte reçue n'a pas été altérée pendant la communication.
L'authentification
Pour réaliser l'authentification, une empreinte du contenu est produite et chiffrée avec la clé privée de l'émetteur. Authentification et 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).
Note : un auteur (ou un collectif d'auteurs) peut produire et diffuser des contenus « authentifiés » en restant dans l'anonymat, en utilisant toujours la même clé privée. Les destinataires n'auront qu'une seule assurance : c'est toujours le même auteur ou collectif.
Aller plus loin
- Page GPG de Wikipédia (418 clics)
- La cryptographie asymétrique (216 clics)
- Sécuriser ses conversations avec OpenPGP (231 clics)
- Installation et configuration de GPG pour Ubuntu (149 clics)
- GPA : l'interface graphique de GPG (103 clics)
- Key Signing Party (83 clics)
- La Key Signing Party des RMLL 2010 (48 clics)
- Authentification sur Internet avec GpgAuth (140 clics)
- GpgAuth : à quoi ça sert et comment ça marche ? (155 clics)
- GPG Howto (journal LinuxFr) (172 clics)
- Protocoles d'authentification sur Wikipédia (53 clics)
# une image vaut plein de mots
Posté par Krunch (site web personnel) . Évalué à 9.
Je trouve qu'en général, l'utilisation de schémas aide à comprendre les concepts cryptographiques et comment ils sont assemblés pour former un cryptosystème. J'avais fait un truc sur le sujet il y a longtemps et c'est grandement améliorable mais si ça peut aider des gens :
chiffrement asymétrique de bout en bout :
toile de confiance :
La présentation complète est à http://docu.fsugar.be/openpgp/openpgp.html
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: une image vaut plein de mots
Posté par erdnaxeli (site web personnel) . Évalué à 10.
Heu … personnellement je ne comprends rien à ton image mais la dépêche m'a parue assez claire.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: une image vaut plein de mots
Posté par Krunch (site web personnel) . Évalué à 3.
Bon ben faut croire que ça marche pas pour tout le monde :) Enfin sinon lors d'une présentation interactive ça aide pas mal je trouve.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: une image vaut plein de mots
Posté par Martin Peres (site web personnel) . Évalué à 3.
ça marche plutôt pas mal pour moi, mais je suis déjà bien familier avec la crypto (a)symétrique, le chiffrement et la signature donc ...
[^] # Re: une image vaut plein de mots
Posté par Ellendhel (site web personnel) . Évalué à 5.
L'idée est effectivement de faire une présentation interactive pour que les choses soient plus claires. Découvrir et lire le schéma en un seul bloc peut être assez difficile pour beaucoup de personnes, alors qu'en ayant des blocs qui apparaissent au fil de l'explication est généralement plus apprécié.
En tout cas, c'est le genre de retour que j'ai eu lors de mes présentation d'introduction à la cryptographie.
publicité subliminale : http://www.ellendhel.net/article.php?ref=2009+12+30-0
[^] # Re: une image vaut plein de mots
Posté par Christophe Turbout . Évalué à 1.
bah je le trouve plutôt clair moi son schéma ...
il montre bien les utilisations des clés privées et des clés publiques ainsi
que le processus de contrôle d'intégrité des personnes et du message.
[^] # Re: une image vaut plein de mots
Posté par grondilu . Évalué à 5.
Pardon mais si en général, une image aide à comprendre les concepts, alors j'suis désolé mais là ça doit être l'exception qui confirme la règle, parce que ton schéma il est quand même atrocement compliqué.
[^] # Re: une image vaut plein de mots
Posté par Krunch (site web personnel) . Évalué à 3.
Ah ben pourtant c'est déjà pas mal simplifié :)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: une image vaut plein de mots
Posté par BFG . Évalué à 10.
Votre image est un message chiffré, c'est bien ça ?
[^] # Re: une image vaut plein de mots
Posté par jcs (site web personnel) . Évalué à 1.
Malheureusement je crains que ton schéma ne fasse pas la différence entre signature et chiffrement.
[^] # Re: une image vaut plein de mots
Posté par Krunch (site web personnel) . Évalué à 2.
Ben la signature étant une application particulière du chiffrement, si. Mais effectivement sans les explications en live c'est pas forcément évident.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: une image vaut plein de mots
Posté par jcs (site web personnel) . Évalué à 1.
Dans le cas général, non. À la limite dans le cas particulier de RSA et encore avec beaucoup de réserves. RSA est d'abord est une primitive cryptographique. Il existe des fonctions "signature RSA" et "chiffrement RSA" qui utilisent la même primitive mais :
Le standard PCSK#1 décrit comment on peut utiliser RSA pour chiffrer ou signer.
[^] # Re: une image vaut plein de mots
Posté par Krunch (site web personnel) . Évalué à 2.
Si.
Ce que je veux dire c'est qu'un algo de chiffrement asymétrique est un algo de signature potentiel et vice-versa (et c'est pas juste pour RSA). Évidemment il faut déjà avoir compris en quoi les concepts de confidentialité et d'authentification sont différents avant de regarder le schéma (qui, à la base, fait partie d'une présentation disponible dans le même répertoire).
Cela dit, il est vrai que les détails d'implémentation de l'algorithme de signature sont généralement différents de l'algo de chiffrement sur lequel il est basé et qu'on utilise même souvent des algos complétements différents pour l'un et l'autre mais l'idée était d'introduire les primitives cryptographiques et comment elles sont combinées, pas de discuter des algos spécifiques (et puis le schéma est déjà assez compliqué comme ça mais le .dia est dans le même répertoire donc tu peux toujours modifier si tu veux).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Très intéressant, merci.
Posté par madhatter (site web personnel) . Évalué à 4.
Merci pour cet exposé très intéressant sur GPG. Je souhaitais depuis quelques m'y pencher d'un peu plus près pour en comprendre le fonctionnement étant donné que mine de rien, je l'utilise tout les jours via les dépôts Debian.
Merci encore ;).
There is no spoon...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Très intéressant, merci.
Posté par madhatter (site web personnel) . Évalué à 2.
Ben encore merci alors :D
There is no spoon...
# Autre site
Posté par anakin . Évalué à 3.
Il y aussi ce site http://www.securite-informatique.gouv.fr/autoformations/signature_elec/co/mod01_chap01.html qui est pas mal je trouve, avec des animations bien faites et claires pour expliquer aux débutants les principes de base.
[^] # Re: Autre site
Posté par Bruce Le Nain (site web personnel) . Évalué à 4.
Dommage qu'on n'y parle pas de GPG, et qu'il y soit dit que les clefs ne sont fournies que par des organismes de confiance. Sinon, très bien fait, en effet :)
# Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: La question de la limite des algorithmes
Posté par Shuba . Évalué à 4.
Moui, enfin tant que le contraire n'a pas été prouvé, ie qu'on n'a pas d'algo rapide pour résoudre ces problèmes, ça marche.
[^] # Re: La question de la limite des algorithmes
Posté par 태 (site web personnel) . Évalué à 3.
La crainte, c'est que quelqu'un ait (ou fasse) la preuve et ne la communique pas.
[^] # Re: La question de la limite des algorithmes
Posté par djano . Évalué à 1.
Oui m'enfin pour le moment on n'a pas trouvé mieux!
[^] # Re: La question de la limite des algorithmes
Posté par khivapia . Évalué à 3.
C'est surtout ça qui détermine la sécurité d'un certain nombre de schémas: l'AES n'a été déclaré sûr que parce qu'un nombre élevé de cryptologues (éminents ?) se sont penchés dessus sans rien trouver.
C'est la même chose pour la compétition SHA-3 qui est en cours.
[^] # Re: La question de la limite des algorithmes - démoinssez-moi !!
Posté par kursus_hc . Évalué à 1.
Il faudrait demander à Geohot.
[^] # Re: La question de la limite des algorithmes - démoinssez-moi !!
Posté par khivapia . Évalué à 4.
Dans le cas de la PS3, ce ne sont pas les algorithmes de cryptologie qui sont en cause, mais leur implémentation; qui utilisait un générateur de nombre aléatoires foireux.
Il est connu depuis longtemps que pour nombre de protocoles de signature, le fait de connaître avec certitude ne serait-ce qu'une dizaine de bits d'un aléa de 160 censé être inconnu permet de retrouver la clef privée...
[^] # Re: La question de la limite des algorithmes - démoinssez-moi !!
Posté par neerd . Évalué à 1.
Forcément à piquer du code Debian ...
-->[]
[^] # Re: La question de la limite des algorithmes
Posté par Gniarf . Évalué à 4.
s/hacker/poudre verte//
[^] # Re: La question de la limite des algorithmes
Posté par Krunch (site web personnel) . Évalué à 2.
La formulation est peut-être maladroite mais c'est pas de la poudre verte. Des implémentations de cryptosystèmes quantiques ont bel et bien été cassées alors que le modèle théorique est prouvé sûr. Après je sais pas si on peut parler d'approche « hacker » mais pour autant que je sache, la plupart des trucs qui sont publiés à ce sujet viennent de http://www.iet.ntnu.no/groups/optics/qcr/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# HTTPS réputé théoriquement fiable depuis peu?
Posté par djano . Évalué à 2.
Je suis surpris par cette phrase. D’où tiens tu cela?
Je pensais qu'en cryptographie, tout est fiable jusqu’à ce que l'on prouve le contraire. Il me semble avoir vu qu'on arrive a avoir des idées sur la fiabilité d'un algorithme, mais qu'on ne peut pas prouver sa fiabilité.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: HTTPS réputé théoriquement fiable depuis peu?
Posté par mortimer . Évalué à 1.
Le ssl ne se base pas que sur un seul algo de chiffrement. Libre à l'administrateur d'un serveur web (quand il en a la possibilité) de limiter les algos de calcul de condensat et de chiffrement à ceux qui sont réputés fiables. Par exemple, avec apache httpd et mod_ssl, ça se fait avec la directive SSLCipherSuite (http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslciphersuite ).
Après, il faut aussi bien choisir son autorité de certification, et éviter celles qui utilisent encore md5, par exemple...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: HTTPS réputé théoriquement fiable depuis peu?
Posté par Étienne . Évalué à 5.
Le certificat de linuxfr n'est pas auto-signé, il est signé par CAcert. Le problème est que le certificat de CAcert n'est pas livré avec les navigateurs.
[^] # Re: HTTPS réputé théoriquement fiable depuis peu?
Posté par djano . Évalué à 5.
Et Mozilla ne veut pas l'ajouter car ils reprochent a CAcert de ne pas être encore assez "surs". Il y a un bug dans leur bugzilla. Peut être dans le futur?
En même temps, même les autorités réputées sures se font cracker et Mozilla commence a vouloir faire le ménage. (Bon sang je ne retrouve plus les liens!)
[^] # Re: HTTPS réputé théoriquement fiable depuis peu?
Posté par jcs (site web personnel) . Évalué à 2.
En voilà déjà un, sur la mise à jour de la Mozilla CA Certificate Policy :
http://groups.google.com/group/mozilla.dev.security.policy/browse_frm/thread/426b771c7236fe27/6edabc01f8611862?tvc=1#6edabc01f8611862
[^] # Re: HTTPS réputé théoriquement fiable depuis peu?
Posté par djano . Évalué à 1.
En fait, j'ai simplement lu trop vite. Toutes mes confuses.
Si je me rappelle bien, SHA-1 est déconseillé car il est possible de générer un hash SHA-1 identique a un autre hash avec une probabilité accessible a des grands moyens computationnels. En pratique est ce que cela rend le surf en HTTPs moins sur? Oui, mais est ce que cela me dérange que quelqu'un intercepte mes communications sur linuxfr.org at applique une grosse masse de calcul pour arriver a me leurrer? non.
Comme d'habitude en sécurité, il y a un compromis entre ta sécurité et la convivialité d'utilisation. Tout dépend de ce que tu as a perdre si jamais on te vole ces informations.
Par exemple, de nombreux projets utilisaient jusqu’à récemment des signatures md5 pour les tarballs, parce que ce l'on veut juste vérifier que le paquet est intègre. On ne cherche pas a assurer une sécurité absolue.
[^] # Re: HTTPS réputé théoriquement fiable depuis peu?
Posté par claudex . Évalué à 8.
Il y a aussi le principe qui dit qu'un système est aussi sécurisé que sa partie la plus faible. C'est-à-dire que si tu construit un coffre-fort, il y a beaucoup plus de chance qu'on te vole la clef qu'on perce la paroi du coffre. Et pour les tarball, la plupart du temps, le lien est à côté de la somme MD5 (ou dans le même répertoire quand il n'y a pas de page web), si quelqu'un arrive à changer le lien ou le fichier, il n'y a aucune raison qu'il n'arrive pas à changer la somme MD5 avec celle de son nouveau fichier.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: HTTPS réputé théoriquement fiable depuis peu?
Posté par Édouard Siha . Évalué à 3.
On le voit souvent formulé de la façon suivante : une bonne protection est une protection qui tiendra pour la durée de vie de la donnée à protéger.
Pour un numéro de carte bancaire par exemple, c'est quelques années.
[^] # Re: HTTPS réputé théoriquement fiable depuis peu?
Posté par jcs (site web personnel) . Évalué à 5.
Toutes les attaques ne se valent pas, toutes ne sont pas applicables à tous les "mode opératoires". Par exemple pour MD5 je peux te sortir une collision en une dizaine de seconde sur mon PC, par contre trouver un autre fichier qui a une empreinte données, c'est beaucoup plus difficile. Si en plus je veux pirater un repository debian et que ce fichier doit être un tarball valide, là c'est carrément mission impossible.
Dans le même esprit, la spécification TLS utilise MD5 et SHA-1 ensemble, mais pour le moment il n'a pas été montré que les attaques sur ces deux algorithmes ont un impact sur la sécurité de TLS. Des attaques type Comodo (sur les PKI) sont à mon avis bien plus facile à monter et donc plus probables.
[^] # Re: HTTPS réputé théoriquement fiable depuis peu?
Posté par mortimer . Évalué à 2.
Il a été démontré en 2008 (http://www.win.tue.nl/hashclash/rogue-ca/) qu'avec relativement peu de moyens (200 playstations, un quadcore), on pouvait générer deux certificats avec le même hash md5 en à peu près une journée.
Dans la démo en question, ils ont fait signer par une AC reconnue un certificat anodin, puis associé cette signature à un autre certificat (ayant le même hash md5) pouvant être utilisé comme autorité intermédiaire. Ce qui signifie au final qu'ils ont pu émettre et signer des certificats reconnus par les navigateurs.
Pour moi, il est clair que md5 et sha-1 ne sont plus fiables.
[^] # Re: HTTPS réputé théoriquement fiable depuis peu?
Posté par hirymnak . Évalué à 1.
Bonjour,
Je suis utilisateur d'OpenPGP (standard de GPG) depuis quelques années, et j'ai effectivement entendu que des fonctions de hashage comme MD5 ou SHA-1 ne devaient plus être utilisées.
Effectivement, tomber sur une page HTTPS utilisant SHA-1 comme algo de signature du certificat fait prendre le risque que le contenu ne soit pas authentifié, le chiffrement des données transitant n'étant pas mis en question.
Je me pose dans ce cas une question à propos d'OpenPGP :
Alors qu'il est possible avec GPG de signer des contenus avec SHA-2 (ex : SHA-256, SHA-512), lors des Signing Parties, chacun a la possibilité d'étendre le réseau de confiance en signant la clef publique de son voisin. En fait il ne signe pas la clef publique, mais son empreinte SHA-1 !
Le réseau de confiance, et toute la fiabilité des clefs reçues sur serveur de clefs, n'en est-il donc pas altéré ?
Cordialement
# symétrique(message)
Posté par BFG . Évalué à 1.
Est-ce uniquement pour des questions de vitesse/légèreté, comme pour le point a) au dessus ?
D'autre part, dans le manuel de GPG, on lit :
Je ne suis pas sûr de comprendre cette option. Est-ce que cela sert à voir la clef temporaire utilisée pour le chiffrement symétrique ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: symétrique(message)
Posté par oinkoink_daotter . Évalué à 2.
Je ne suis pas utilisateur de GPG, mais oui, ça a l'air d'afficher la clef de session utilisée pour un message.
[^] # Re: symétrique(message)
Posté par Emmanuel C . Évalué à 4.
Pour répondre à la première question, j'avais lu que la fiabilité des chiffrements asymétriques était d'autant plus élevée que les contenus à chiffrer étaient petits. En gros, si on chiffre trop de données avec un algo asymétrique, on "risque" de pouvoir retrouver le message et/ou la clé privée (ou une histoire du même genre).
Les méthodes symétriques n'ont pas ce défaut : elles fonctionnent très bien, très vite, très rapidement sur de grandes quantités de données. Leur seul inconvénient est que le secret doit être partagé. C'est un inconvénient de taille...
L'idée est donc de prendre une clé de session arbitraire qui sera placée dans le message, mais chiffrée avec un algo asymétrique, puis de chiffrer le reste des données avec uniquement cette clé de session. On utilise les bonnes propriétés des deux techniques, et en plus, la clé change à chaque fois, ce qui neutralisera pas mal d'attaque basées sur la répétition d'un motif habituel (Ceci dit, il y a d'autres techniques pour éviter cette répétition).
[^] # Re: symétrique(message)
Posté par Krunch (site web personnel) . Évalué à 5.
Les algorithmes de chiffrement asymétriques sont généralement plus « fragiles » par nature dans le sens où il est assez facile d'introduire des failles en les utilisants de manière inappropriées. Pour RSA par exemple, la page wikipédia liste quelques problèmes qui sont contournés si on ne chiffre que des messages « aléatoires » (les clés de sessions) : http://en.wikipedia.org/wiki/RSA#Attacks_against_plain_RSA
Cela dit, il est aussi assez facile de mal utiliser les algos de chiffrement symétriques. Voir par exemple ECB : http://en.wikipedia.org/wiki/Cipher_block_chaining#Electronic_codebook_.28ECB.29
La vraie solution est bien entendue de ne pas écrire de code qui fasse de la crypto à ce niveau à moins d'être un expert dans le domaine (et encore). À ce sujet, j'aime bien cet article : http://chargen.matasano.com/chargen/2009/7/22/if-youre-typing-the-letters-a-e-s-into-your-code-youre-doing.html
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# C'est clair !
Posté par davux (site web personnel) . Évalué à 4.
Haha, un article sur le chiffrement qui s'appelle "les concepts en clair", elle est bonne. :)
C'est vrai que GPG sans ça c'est un peu cryptique.
Merci pour l'article en tout cas.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.