Pour l'utilisation de l'outil d'encryption/décryption gpg (obtenir des clés, signer des clés, partager des clés) voir FormationGPG.

Formation au système d'encryption et de signature OpenPgp. Ceci peut se faire dans le câdre d'une FormationSécuritéThéorique plus générale ou indépendamment.

L'utilisation d'OpenPGP permet l'échange d'information sensible, comme des mots de passe ou des informations personnelles sur des rendez-vous ou autre, de façon sécuritaire via courriel ou par fichiers partagés via un autre moyen.

Dans le câdre de cette formation on va principalement montrer comment utiliser le plugin enigmail de thunderbird.

Public cible

Tous travailleurs et travailleuses de Koumbit ou membres qui souhaitent se familiariser avec l'encryption et la signature sur internet.

Préparation suggérée

1. installation de thunderbird + enigmail (ou équivalent)
2. génération d'une clef (optionnel)

Plan de cours

La formation se fait en trois parties:

1. création d'une clef pour ceux qui n'en ont pas déjà une (~20mins)
2. présentation théorique et pratique - on comprend le principe (~1h - 1h30)

3. KeySigningParty - on signe les clefs! (~1h)

Première partie: Création de clef

Première démystification: distinction de OpenPgp, GPG, PGP, Enigmail

• PGP est un logiciel propriétaire de cryptographie.
• GPG (ou Gnu Privacy Guard) est un logiciel de cryptographie. C'est la version libre de PGP.
• Enigmail est un plugin à Thunderbird. Il intègre et simplifie l'utilisation de GPG directement dans Thunderbird qui est utilisé pour envoyer des mails, via des éléments de son interface.
• OpenPGP est un standard pour l'inter-communication des applications PGP.

On présente OpenPgp et surtout Thunderbird + Enigmail, en suivant un peu le plan dans la page GnuPrivacyGuard.

On demande à ceux qui non pas de clef d'installer les logiciels tout en les guidant.

création d'une clef par le wizard d'enigmail

Avant de créer les clefs, on va configurer GPG pour qu'il utilise des algorithmes plus fort pour l'encryption et la signature. Les détails de la configuration son tirés de la documentation de Riseup et y sont bien détaillés.

Ouvrir le fichier ~/.gnupg/gpg.conf dans un éditeur de texte et ajouter les lignes suivantes:

• keyserver hkps://hkps.pool.sks-keyservers.net
  keyserver-options ca-cert-file=/home/myuser/.gnupg/sks-keyservers.netCA.pem
  keyserver-options no-honor-keyserver-url
  # long keyids are more collision-resistant than short keyids (it's trivial to make a key with any desired short keyid)
  keyid-format 0xlong
  # when multiple digests are supported by all recipients, choose the strongest one:
  personal-digest-preferences SHA512 SHA384 SHA256 SHA224
  # preferences chosen for new keys should prioritize stronger algorithms:
  default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
  # You should always know at a glance which User IDs gpg thinks are legitimately bound to the keys in your keyring:
  verify-options show-uid-validity
  list-options show-uid-validity
  # when making an OpenPGP certification, use a stronger digest than the default SHA1:
  # when outputting certificates, view user IDs distinctly from keys:
  fixed-list-mode
  cert-digest-algo SHA512

Ensuite, il faut télécharger le fichier https://sks-keyservers.net/sks-keyservers.netCA.pem et le sauvegarder sous ~/.gnupg/.

Une fois la configuration terminée, on utilise le wizard d'Enigmail pour générer les clefs.

Quelques détails important pour la création:

• date d'expiration: généralement on vise de 2 à 3 ans
  • fait en sorte que dans le pire des cas (perdu clef privée ou mot de passe et perdu ou pas de certificat de révocation) les gens qui auraient signé notre clef publique se rendraient compte qu'il ne faut plus utiliser cette clef pour encrypter des messages.
  • force les gens à mettre à jour l'info sur les clefs publiques (réf. mise à jour du trousseau plus bas)
• suggestion pour la taille de clef présentment: 4096 bits

• choisir un bon mot de passe (voir GénérerUnMotDePasse)

• créer un certificat de révocation
  • quoi faire quand on perd sa clef (+ expiration)
  • ne pas double-clicker le certificat de révocation! il ne faut pas l'importer tout de suite.
  • imprimer et/ou backup
• désactiver l'option "Always trust people's key" dans les préférences d'envoi d'enigmail
• activer l'option "Toujours utiliser PGP/Mime" dans "Account settings"

  • 

Deuxième partie: formation

Dans cette partie on vise à définir et expliquer certains mots du jargon de l'encryption. Spécifiquement, on veut expliquer la différence entre l'encryption et la signature, puis on veut définir les deux modes d'encryption soit symétrique et asymétrique.

OpenPGP se situe dans l'encryption asymétrique.

encryption vs signature

En quelques points concis:

• encryption: message décodable seulement par le destinataire
  • on encode un message pour que celui-ci ne soit lisible que par le destinataire qui a en sa possession l'information nécessaire pour le décodage.
  • dans le câdre de l'encryption asymétrique, celà signifie qu'on encrypte à l'aide de la clef publique du destinataire et que seul la clef privée du destinataire peut décrypter le message.

    

• signature: checksum décodable par tout le monde mais qui ne peut être créé que par ma clef privée.
  • inverse d'encryption tel que défini plus haut: on encode le checksum à l'aide de la clef privée du signataire et la clef publique du signataire sert à décrypter le message.
  • deux étapes pour la création d'une signature: on calcule un checksum du contenu (fichier, contenu d'un e-mail), puis on encrypte ce checksum.
  • l'information à signer et la signature sont souvent transmises ensemble, mais ce n'est pas obligatoire (voir signatures de clefs publiques plus bas)
  • le checksum est décodable par tous et permet de valider le contenu de l'information
  • l'encryption (inversée pourrait-on dire) assure que le message doit bien provenir de la personne qui a la clef privée correspondante
  • pour coupler les deux points plus haut: une validation exacte grâce au checksum qui provient d'un message décrypté grâce à la clef publique du signataire constitue une signature, donc l'assurance que le détenteur de la clef privée atteste du contenu du message.

    

Donc pour résumer les points plus haut: l'encryption sert à cacher une information à tous sauf le destinataire, tandis qu'une signature sert à prouver que le détenteur d'une clef avait bien en sa possession le même contenu que l'on a reçu.

Une note importante: signature et encryption ne sont pas exclusifs. Par exemple, on peut en premier lieu signer notre message, puis encrypter le message et sa signature. Ce processus permet de créer un message lisible seulement par certaines personnes (encryption) et d'y joindre une assurance sur le contenu du message (validation via la signature).

encryption symétrique

L'encryption symétrique implique que source et destinataire dans une communication aient partagé un secret avant la communication.

Le secret permet d'encrypter et décrypter le message.

L'encryption symmétrique est quelque fois impratiquable. On aimerait pouvoir établir une connexion encryptée avec des gens ou des serveurs avec qui on n'a jamais eu de lien direct préalable. Par exemple, pour l'envoi de emails, il est difficile (voir impossible) d'échanger un secret avec chaque personne avant de communiquer.

encryption asymétrique

Au lieux d'impliquer un seul secret, l'encryption asymétrique implique deux parties:

• clef privée
• clef publique

La clef privée doit être gardée secrète! elle permet de décrypter un message qui nous est destiné.

La clef publique peut être publiée: elle permet d'encrypter un message destiné à une personne en particulier.

On utilise généralement un mot de passe sur la clef privée. Ça offre une protection de plus: pour décrypter un message, il faut non seulement avoir le fichier mais en plus avoir le mot de passe. Par conséquent, le mot de passe doit être bon pour rendre l'accès à la clef privée le plus difficile possible à d'autres personnes que vous.

Dans le cas d'OpenPGP, une troisième composante importante entre en jeu: le certificat de révocation. C'est la porte de sortie en cas d'urgence: c'est le moyen de prévenir les gens si jamais on n'est plus en contrôle de notre clef privée (perdue, volée, mot de passe oublié). Une fois importé, et peut-être publié sur les keyservers (voir web of trust), le certificat de révocation a pour effet de marquer la clef publique comme inutilisable. C'est donc un fichier important mais dangereux; il faut le conserver dans un lieu sûr.

envoyer un courriel crypté et signé au formateur

On commence par trouver la clef publique du formateur, peut-être sur les keyservers.

Il faut ensuite vérifier si on a déjà un lien (ou chemin) de confiance (réf. web of trust).

XXX: mot de passe ? (je me rappelle pas pourquoi c'était là)

web of trust

L'échange de clefs et de signatures d'une personne à l'autre c'est bien, mais qu'en est-il du problème mentionné plus haut? Qu'est-ce qui arrive lorsqu'on ne connaît pas directement la personne avec qui on veut communiquer?

C'est là qu'entre en jeu le web of trust. En tissant les liens entre notre propre clef et celle est autres, on a un outil pour établir une confiance objective avec quelqu'un qu'on ne connaît pas.

Comme les clefs publiques ont la propriété de pouvoir être partagées publiquement, il existe des serveurs spécialisés pour la publication et la recherche de celles-ci. On les appelle keyservers. Non seulement on peut envoyer le contenu de notre clef publique, mais les signatures sur notre clef peuvent également y être diffusées. C'est ainsi qu'on peut obtenir les liens entre les clefs pour procéder à notre vérification du lien de confiance.

Comme l'utilisation de keyservers rend publique les liens de confiance que vous avez envers différentes personnes, certaines personnes préfèrent ne pas publier leur clef sur ces serveurs. Il est tout de même possible d'envoyer les signatures directement aux gens concernés pour qu'elles soient importées dans leur trousseau privé. On parle alors de signature locale. Il est bon de demander lors d'une échange de signatures de clefs si l'autre personne préfère que sa clef privée ainsi que les signatures ne demeurent locales ou bien si elle est d'accord pour qu'on envoie la signature sur les keyservers.

Pendant l'échange de signatures de clefs, deux personnes vérifient en même temps l'identité d'une personne ainsi que son contrôle d'une adresse courriel, puis valide que la clef publique de l'autre correspond bien à la clef que cette personne détient en sa possession. On peut soit obtenir la clef publique via les keyservers, soit directement par transfert de l'autre personne.

En se remémorant la définition de signature plus haut, on peut définir de façon plus concrète à quoi correspond une signature de clef publique: c'est un checksum du contenu de la clef publique d'une personne, encrypté avec la clef privée de la personne qui fait la vérification. Donc après avoir validé en personne avec nos yeux, nos doigts et nos oreilles, on traduit cette validation physique en en validation digitale authentifiée.

vérification du "chemin de confiance" entre deux clefs

Lorsqu'on veut communiquer avec une personne qu'on ne connaît pas directement, il est bon de vérifier le "chemin de confiance" entre notre clef et la clef publique destinataire. Comme notre objectif est d'envoyer une information sensible à quelqu'un, on veut avoir une certaine mesure de confiance que cette personne est bien qui elle prétend être.

Ce lien de confiance devrait être basé sur la capacité des autres à signer des clefs correctement, et à ne pas forger l'identité des autres.

Le mot "chemin" s'applique au fait qu'on trace d'abord un graphe des liens (signatures) entre les clefs, puis qu'on suive ces liens.

Chaque personne a une définition bien à elle de la confiance qu'elle porte envers certaines personnes. Donc il faut suivre ses propres instincts. Dans l'intérêt de donner un exemple de règles qui assureraient un minimum de confiance marginale, on peut définir les règles suivantes:

• connaître personnellement la personne depuis déjà un certain temps (c'est bien d'avoir tout de même signé la clef de la personne à l'aide d'une vérification de la clef publique)
• avoir signé directement la clef d'une personne
• qu'une personne qu'on considère de confiance pour qui on a signé la clef ait signé la clef d'une autre personne. même si on considère une clef comme étant marginalement légitime, celà ne veut pas dire qu'on fait confiance aux signatures qu'elle aurait publiée.
• généralement, pour les liens indirects comme le point précédent, il est préférable d'avoir au moins deux chemins, donc deux personnes de confiance ont signé la clef de l'autre personne.
• la confiance va généralement en descendant dans un graphe hiérarchique comme ci-dessous. en langage humain, celà veut dire que je vais confiance en une clef que j'ai signée, puis si je porte une certaine confience en la capacité de cette personne à signer correctement, je peux faire confiance en les signatures que cette personne a faite, et ainsi de suite.

Pour les gens visuels des outils peuvent être utilisés, comme par exemple http://pgp.cs.uu.nl/

backups

Avec l'encryption asymétrique, si on perd notre clef privée, on perd l'habileté à décrypter les messages qui nous sont destinés ainsi que l'habileté à former une signature qui certifie qu'on serait l'origine du message. Dans ce cas, si on n'a pas de certificat de révocation, on n'a pas non plus l'habileté de prévenir nos éventuels correspondantEs que nous ne pouvons plus décrypter leurs messages.

Il est donc primordial de garder un bon backup de ces éléments.

La pratique la plus recommandée est de conserver une copie de ces éléments dans un format de stockage offline, et de s'assurer que ce stockage soit dans un endroit sûr (personne d'autre que soi peut accéder au contenu du backup)

Certaines personnes impriment leur certificat de révocation et le conservent dans un coffre-fort. Il faut alors se rappeler du code du coffre-fort.

C'est également possible de le stocker dans un disque/une clef usb encrypté(e) qui est conservé(e) débranché d'un ordinateur; il faut se rappeler du mot de passe d'encryption du médium.

C'est bien aussi de vérifier de temps à autres que notre backup est toujours lisible.

Lorsqu'on perd la clé privée

• Générer une nouvelle clé
• En espérant qu'on ait déjà généré un certificat de révocation et qu'on l'ait gardé dans un endroit sûr, importer le certificat de révocation dans son trousseau, puis le publier sur les keyservers.

Comme la perte de la clef privée signifie la perte de l'habileté à authentifier nos communications par signature, certaines personnes sont très rétissentes à commencer à utiliser une autre clef de la même personne tant qu'elle n'aura pas revérifié la clef en personne, surtout dans le cas où la personne a également perdu son certificat de révocation. Celà s'applique tout particulièrement dans les cas où un océan empêcherait le contact direct.

Donc c'est important de révoquer sa clef en cas de problème. On repart à 0 en terme de web of trust, mais les gens qui avaient signé notre clef perdue seront moins réticent de signer notre nouvelle clef.

autres opérations

Ici on enlève nos mitaines et on commence à utiliser l'encryption à des fins plus pratiques.

• encryption/signature de fichiers
  • encryption d'un fichier vers soi-même (cacher le contenu du fichier à tous sauf soi)
  • encryption d'un e-mail qu'on envoie à qqun d'autre
• décryption/vérification

  • exemple, downloader Tor bundle et vérifier le fichier downloadé contre la signature publiée sur le site web.

• mise à jour automatique du trousseau de clef / parcimonie

Deuxième partie: keysigning

La seconde partie est un KeySigningParty, qui dure environ 1h - 1h30, car on fait aussi un peu de formation sur comment signer les clefs.

And don't forget...

... never bring tequila to a keysigning party!

Outils présentés

• Thunderbird (ou icedove) + enigmail

• seahorse

• GPG

• Caff (de signing-party) et pius

Notes prises par les participants

How a KeySigningParty works:

1. Everyone adds their PGP keys to a common document
2. It is printed, distributed and then read aloud
3. Everyone confirms that each key that is read, is the key they see on the page
4. Each person also confirms that when their key is read, it is their actual key
5. Each person then checks everyone else's supporting documentation (driver's license, passport, etc.) or otherwise ensures that the people there do indeed match the names on the list

Autre documentation

• http://www.zytrax.com/tech/survival/encryption.html

• https://we.riseup.net/riseuplabs+paow/openpgp-best-practices

CategoryFormation CategoryFormationPublique