GPG - les concepts en clair et pédagogiquement

Posté par  . Édité par Benoît Sibaud. Modéré par baud123. Licence CC By‑SA.
51
18
avr.
2011
Sécurité

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

  • # une image vaut plein de mots

    Posté par  (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 : end to end asymetric crypto

    toile de confiance : web of trust

    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  (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  (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  . É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  . É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  (site Web personnel) . Évalué à 3.

        ton schéma il est quand même atrocement compliqué.

        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  . Évalué à 10.

      Votre image est un message chiffré, c'est bien ça ?

    • [^] # Re: une image vaut plein de mots

      Posté par  (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  (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  (site Web personnel) . Évalué à 1.

          la signature étant une application particulière du chiffrement

          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 :

          • La primitive est utilisée de façons différentes dans les deux fonctions : on produit une signature en utilisant sa clé privée, alors qu'on chiffre avec la clé publique du destinataire du message, le padding est différent...
          • Les services rendus sont différents : confidentialité dans le cas du chiffrement, authenticité et intégrité dans le cas de la signature.

          Le standard PCSK#1 décrit comment on peut utiliser RSA pour chiffrer ou signer.

          • [^] # Re: une image vaut plein de mots

            Posté par  (site Web personnel) . Évalué à 2.

            la signature étant une application particulière du chiffrement

            Dans le cas général, non.

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

  • # Autre site

    Posté par  . É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  (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  . Évalué à 1.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # HTTPS réputé théoriquement fiable depuis peu?

    Posté par  . Évalué à 2.

    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.

    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  . Évalué à 2.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: HTTPS réputé théoriquement fiable depuis peu?

        Posté par  . É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...

      • [^] # Re: HTTPS réputé théoriquement fiable depuis peu?

        Posté par  . É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  . Évalué à 8.

          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.

          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  . Évalué à 3.

          Tout dépend de ce que tu as a perdre si jamais on te vole ces informations.

          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  (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  . É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  . É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  . Évalué à 1.

    b) [...] 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.

    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 :

    --show-session-key

    Display the session key used for one message. See --override-session-key for the counterpart of this option.

    We think that Key Escrow is a Bad Thing; however the user should have the freedom to decide whether to go to prison or to reveal the content of one specific message without compromising all messages ever encrypted for one secret key. DON'T USE IT UNLESS YOU ARE REALLY FORCED TO DO SO.

    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  . Évalué à 0.

      Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: symétrique(message)

      Posté par  . Évalué à 2.

      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 ?

      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  . É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).

  • # C'est clair !

    Posté par  (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 à ceux qui les ont postés. Nous n’en sommes pas responsables.