GnuPG Faut-il signer ou chiffrer ses mails

Suite au billet « GnuPG Renouveler sa clé de chiffrement » j’ai reçu un courriel me posant cette question :

Intéressant, mais je ne comprends rien à tout ça. Est-ce que tu peux nous expliquer à quoi ça sert, ça, et pourquoi tu le fais ? (:-)

Sachant de qui vient ce message, je soupçonne qu’il connaît déjà les réponses. Cela dit, c’est une belle opportunité d’y répondre de manière plus accessible et humaine, en évitant le jargon technique. Quoi que… je serais tout de même obliger d’employer quelques termes techniques. Désolé!

Il est vrai qu’à une époque, je communiquais en chiffré avec certaines personnes, notamment des participants aux Cafés Vie Privée. Aujourd’hui, j’ai perdu contact avec la plupart d’entre eux, et il est désormais assez rare que j’aie des échanges chiffrés. Alors…

À quoi ça sert ?:

Le chiffrement des mails consiste à rendre le contenu d’un message illisible pour toute personne autre que le destinataire légitime. Cela protège la confidentialité des informations échangées.
La signature électronique garantit l’authenticité et l’intégrité d’un message. Elle permet au destinataire de vérifier que le mail provient bien de l’expéditeur annoncé.

Pourquoi tu le fais ?:

Garder la possibilité d’envoyer des messages chiffrés et de déchiffrer ceux reçus, garder la possibilité de signer mes messages et de vérifier la signature de ceux reçus.

Que se passe-t-il lorsque vous envoyez un mail

Lorsque vous envoyez un mail, il passe par plusieurs serveurs avant d’atteindre le destinataire. Si aucune mesure de sécurité n’est mise en place, le contenu du message peut être facilement lu par quiconque a accès aux serveurs ou aux réseaux par lesquels il transite.

Le protocole principal pour envoyer des mails, SMTP (Simple Mail Transfer Protocol), a été initialement conçu sans chiffrement. Aujourd’hui la plupart des serveurs de messagerie utilisent TLS (Transport Layer Security) pour sécuriser les connexions SMTP. TLS protège le transport des messages entre les serveurs en chiffrant le canal de communication mais TLS ne garantit pas un chiffrement de bout en bout. Une fois le message reçu par le serveur du destinataire, il peut être stocké en clair.

Alors, faut-il signer, chiffrer ses mails ?

Dans l’absolu, la réponse à la question plus haut est oui ! Mais la réalité est plus complexe.

D’où vient la complexité ?
L’aspect technique et l’aspect humain.

  • Les méthodes de chiffrement des mails, comme GPG (Gnu Privacy Guard), PGP (Pretty Good Privacy) et S/MIME (Secure/Multipurpose Internet Mail Extensions), nécessitent une certaine compréhension technique et ne sont pas intuitives pour les utilisateurs non avertis.
  • PGP ou GPG (car ils sont compatibles) et S/MIME sont les deux principaux standards, mais ils ne sont pas interopérables, créant des barrières entre utilisateurs de différents protocoles.
  • Chaque utilisateur doit générer une paire de clés (une publique et une privée) et échanger des clés publiques avec ses correspondants.
  • Les outils de chiffrement intégrés aux clients de messagerie (lorsqu’ils existent) restent souvent peu intuitifs même si avec l’évolution cela tend vers la simplification, ça peut sembler complexe.
  • Certains services ou applications de messagerie, surtout en ligne (Gmail, Outlook, etc.), ne supportent pas nativement le chiffrement PGP ou S/MIME, ou le font de manière limitée.
  • Certains fournisseurs de messagerie (Gmail, Outlook, etc.) sont souvent réticents à mettre en place un chiffrement de bout en bout par défaut, en raison de la perte de contrôle sur les contenus des mails. Certains fournisseurs de messagerie analysent le contenu des mails pour des raisons de ciblage publicitaire, et le chiffrement de bout en bout serait incompatible avec ce modèle économique.
  • Si un utilisateur perd sa clé privée (par exemple, après une panne d’ordinateur sans sauvegarde), il ne pourra plus déchiffrer les mails reçus avec cette clé.
  • Une personne qui souhaite utiliser le chiffrement, doit s’assurer que ses correspondants l’utilisent également.

La liste n’est pas exhaustive mais c’est déjà beaucoup de freins.

Faudrait-il communiquer uniquement de façon chiffrée ?

Pas forcément. Tout comme on peut envoyer des cartes postales sans enveloppe, certains courriels ne nécessitent pas un haut niveau de confidentialité. Par exemple, si j’écris pour annoncer que j’apporterai un cake aux olives pour le 25e anniversaire de Root66, le chiffrement n’est pas forcément indispensable. La question de la confidentialité dépend donc de l’importance du contenu.
Par contre, si je communique avec des administrations, des banques, des assurances, des services médicaux, des avocats… Là, la confidentialité devient cruciale. Pourtant, cette option n’est que très rarement proposée, voire pas du tout, même pour ceux qui seraient en mesure de l’utiliser.

Ne leur jetons pas la pierre ! Cela est lié à la complicité actuelle à gérer des trousseaux de clés.

On le voit, ce n’est pas simple de communiquer en courriels chiffrés.

Il existe des messageries instantanées où le chiffrement de bout en bout est très simplifié comme Signal, Matrix via Element, pour ne citer qu’eux. Attention, Telegram ne chiffre pas de bout en bout par défaut, contrairement à ce que laisse entendre les médias.

Dans un monde idéal

Dans un monde idéal il faudrait combiner des améliorations techniques, des évolutions dans les usages et une interface conviviale.

Dans l’idéal et pour faire simple :

  • Standardisation mondiale des systèmes de messagerie intégrant nativement des protocoles de chiffrement comme OpenPGP/GnuPG ou S/MIME, sans configuration supplémentaire.
  • Interopérabilité totale quel que soit le client ou le fournisseur, les clés publiques et privées doivent pouvoir être échangées et utilisées facilement, sans problèmes de compatibilité.
  • Création simplifiée : Les clés de chiffrement seraient générées automatiquement lors de la création d’une adresse e-mail, sans intervention de l’utilisateur.
  • Distribution transparente des clés publiques avec publication dans un annuaire, ou échangées automatiquement lorsque deux personnes communiquent pour la première fois.
  • Renouvellement et révocation des clés expirées ou compromises seraient automatiquement renouvelées ou révoquées sans effort de l’utilisateur.
  • Partage d’accès temporaire : Si un utilisateur perd son accès à ses clés privées, un mécanisme sécurisé de récupération ou d’accès temporaire serait intégré.
  • Les outils et protocoles utilisés pour le chiffrement doivent être open source, audités régulièrement et vérifiés.

Voilà donc déjà quelques points, tant qu’ils ne sont pas mis en place, rendent encore le chiffrement des courriels complexe pour la plupart des utilisateurs.

Pour conclure

J’ai une paire de clés que je renouvelle de temps en temps, cela me permet en cas de besoin de pouvoir échanger par courriels chiffrés. Le fait de signer mes messages écrits en clair permet aux destinataires équipés des outils nécessaires de vérifier l’authenticité de l’expéditeur – en l’occurrence, moi.

Ne vous est-il jamais arrivé de recevoir un courriel d’une connaissance prétendant s’être fait voler son argent au Burkina Faso (ou ailleurs), vous demandant de l’aider par un envoie d’argent pour rentrer (alors même que cette personne n’a jamais quitté la France) ? Ce type d’arnaque, parmi bien d’autres, est malheureusement courant.

La signature numérique et sa vérification permettent de prévenir ce genre d’escroquerie, sauf si l’escroc a également réussi à voler la clé privée de votre connaissance et à découvrir sa phrase secrète. Un tel scénario, bien qu’éventuellement possible, reste toutefois très improbable.

Vous pouvez vous lâcher sur les commentaires.

Le billet « Faut-il signer, chiffrer ses mails » est apparu en premier sur le blog de Sima78.

GnuPG Renouveler sa clé de chiffrement

Il était temps que je renouvelle ma clé de chiffrement, en effet je n’avais pas mis de date d’expiration et par procrastination dont je suis un spécialiste je reculais la date de cette tâche de jour en jour pour ne pas dire d’année en année. Ce week-end je m’y suis collé et c’est l’occasion de créer un billet pour blog.

Trouvant les interfaces graphiques limitées dans les options, j’ai utilisé la ligne commande bien plus riche.

Faut-il communiquer qu’en mode chiffré ou pas… ce sera le sujet d’un autre article !

Avant tout, qu’est-ce que GnuPG ?

GnuPG (GNU Privacy Guard) est un logiciel libre qui permet de chiffrer et de signer des données et des communications, rendant vos échanges privés et authentiques. Il utilise le chiffrement asymétrique : chaque utilisateur possède une clé publique (à partager pour recevoir des messages chiffrés) et une clé privée (à garder secrète pour déchiffrer les messages reçus et signer ses propres messages).

Bref :

  • Protéger vos emails et fichiers pour qu’ils ne soient lisibles que par le destinataire choisi.
  • Vérifier l’authenticité des messages ou fichiers reçus, confirmant qu’ils proviennent bien de la personne qui les a signés.

C’est un outil pour la confidentialité et la sécurité des communications numériques.

Avertissement

Il ne s’agit pas de copier/coller bêtement les lignes de commande mais d’essayer de les comprendre et de vous les approprier.
Comme modifier « mon@mail.fr » par votre mail… Et mettre votre propre ID

Pour comprendre comment est faite une clé GnuPG

pub   rsa4096/0x2C07D84901065A3D 2024-11-10 [SC]
      Empreinte de la clef = 32B2 C27E 1C7D 3D68 8FA1  D49F 2C07 D849 0106 5A3D
uid                              sima78 (clés perso 01) <mon@mail.fr>
sub   rsa4096/0x373FEA503684F9B2 2024-11-10 [E]

pub : est la clé publique, l’ID est entre le « / » et avant 2024, utilisée pour chiffrer ou vérifier des signatures.
Empreinte de la clé : est l’empreinte complète qui permet de faire des vérifications.
uid : Identité de l’utilisateur associée à la clé publique (nom, email).
sub : Clé secondaire, souvent utilisée pour des rôles spécifiques comme le chiffrement.

Renouvellement de la clé GnuPG

Je commence par lister les clés

gpg –list-key

Là je constate que j’ai une grande quantité de clés publiques expirées.
Faire le ménage et commencer par identifier les clés publiques expirées

Faire le ménage, supprimer les clés expirées est tout à fait optionnel. Vous pouvez le faire après, ou ne pas le faire.

La procédure de renouvellement commence vraiment à « Révoquer l’ancienne clé ».

gpg --list-keys --with-colons | awk -F: '/^pub:e:/ {print $5}'

Permets de lister les clés expirées
Pour les supprimer deux possibilités

Dans mes penses-bêtes j’ai un script et une ligne de commande. Je vous mets les deux mais j’ai utilisé la ligne de commande plus bas, je n’ai pas retesté mon script.
Mon script avec une structure conditionnelle « if, then, fi » et une boucle « for do done« 

#!/bin/bash
# Script de suppression des clés publiques GPG expirées
# Vérifier si la commande gpg est disponible
if ! command -v gpg &> /dev/null; then
    echo "Erreur : gpg n'est pas installé." >&2
    exit 1
fi

# Parcourir en boucle chaque clé GPG expirée et la supprimer
for key in $(gpg --list-keys --with-colons | awk -F: '/^pub:e:/ {print $5}'); do
    echo "Suppression d'une clé expirée: $key"
    gpg --batch --yes --delete-keys "$key" || {
        echo "Échec de la suppression de la clé: $key" >&2
    }
done

echo "La suppression des clés expirées est terminée."
exit 0

Ou en une ligne, ce que j’ai utilisé

gpg --list-keys --with-colons | awk -F: '/^pub:e:/ {print $5}' | xargs -I {} gpg --batch --yes --delete-keys {}
  • gpg –list-keys –with-colons : Liste toutes les clés
  • awk -F: ‘/^pub:e:/ {print $5}’ : Filtre les clés publiques expirées (pub:e) et extrait leur ID.
  • xargs -I {} gpg –batch –yes –delete-keys {} : Utilise xargs pour passer chaque ID de clé expirée à gpg –delete-keys, supprimant ainsi les clés sans confirmation.

Cette commande supprime toutes les clés publiques expirées de manière automatique.

Mettre à jour les clés de votre trousseau

Pour synchroniser toutes les clés dans votre trousseau avec le serveur de clés et obtenir les dernières informations (comme les révocations), utilisez :

gpg –refresh-keys

Cela vérifie chaque clé de votre trousseau et télécharge les mises à jour disponibles, y compris les certificats de révocation, de tous les serveurs de clés configurés.

Révoquer l’ancienne clé

sima78@jilipolla:~$ gpg --output revocation_certificat.asc --gen-revoke mon@mail.fr
gpg: 'mon@mail.fr' matches multiple secret keys:
gpg:   sec  rsa4096/0x2A5F500DD27DD6FB 2017-02-22 sima78 <mon@mail.fr>
gpg:   sec  dsa3072/0x038072C036D4F9CD 2015-09-21 Sima78 <mon@mail.fr>

Ah, j’ai deux ID dont une est déjà expirée, c’est dont la première que je dois choisir.

sima78@jilipolla:~$ gpg --output revocation_certificat.asc --gen-revoke 0x2A5F500DD27DD6FB

sec  rsa4096/0x2A5F500DD27DD6FB 2017-02-22 sima78 <mon@mail.fr>

Faut-il créer un certificat de révocation pour cette clef ? (o/N) o
choisissez la cause de la révocation :
  0 = Aucune cause indiquée
  1 = La clef a été compromise
  2 = La clef a été remplacée
  3 = La clef n'est plus utilisée
  Q = Annuler
(Vous devriez sûrement sélectionner 1 ici)
Quelle est votre décision ? 0

Entrez une description facultative, en terminant par une ligne vide :
> ancienne
>

Cause de révocation : Aucune cause indiquée
ancienne
Est-ce d'accord ? (o/N) o
sortie forcée avec armure ASCII.
Certificat de révocation créé.

Veuillez le déplacer sur un support que vous pouvez cacher ; toute personne
accédant à ce certificat peut l'utiliser pour rendre votre clef inutilisable.
Imprimer ce certificat et le stocker ailleurs est une bonne idée, au cas où le
support devienne illisible. Attention tout de même : le système d'impression
utilisé pourrait stocker ces données et les rendre accessibles à d'autres.

Importer le certificat de révocation

sima78@jilipolla:~$ gpg --import revocation_certificat.asc
gpg: clef 0x2A5F500DD27DD6FB : « sima78 <mon@mail.fr> » certificat de révocation importé
gpg: Quantité totale traitée : 1
gpg:    nouvelles révocations de clef : 1
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: profondeur : 0  valables :   1  signées :   0
     confiance : 0 i., 0 n.d., 0 j., 0 m., 0 t., 1 u.

Envoyer sur le serveur de clés la révocation

sima78@jilipolla:~$ gpg --send-keys --keyserver keys.openpgp.org 0x2A5F500DD27DD6FB
gpg: envoi de la clef 0x2A5F500DD27DD6FB à hkp://keys.openpgp.org

Générer la nouvelle clé

sima78@jilipolla:~$ gpg --full-generate-key
gpg (GnuPG) 2.4.4; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Sélectionnez le type de clef désiré :
   (1) RSA and RSA
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (9) ECC (sign and encrypt) *default*
  (10) ECC (signature seule)
  (14) Existing key from card
Quel est votre choix ? 1

les clefs RSA peuvent faire une taille comprise entre 1024 et 4096 bits.
Quelle taille de clef désirez-vous ? (3072) 4096
La taille demandée est 4096 bits

Veuillez indiquer le temps pendant lequel cette clef devrait être valable.
         0 = la clef n'expire pas
      <n>  = la clef expire dans n jours
      <n>w = la clef expire dans n semaines
      <n>m = la clef expire dans n mois
      <n>y = la clef expire dans n ans
Pendant combien de temps la clef est-elle valable ? (0) 0
La clef n'expire pas du tout
Est-ce correct ? (o/N) o

GnuPG doit construire une identité pour identifier la clef.
Nom réel : sima78
Adresse électronique :  mon@mail.fr
Commentaire : clés perso 01
Vous utilisez le jeu de caractères « utf-8 ».
Vous avez sélectionné cette identité :
    « sima78 (clés perso 01) <smon@mail.fr > »
Changer le (N)om, le (C)ommentaire, l'(A)dresse électronique
ou (O)ui/(Q)uitter ? O

De nombreux octets aléatoires doivent être générés. Vous devriez faire
autre chose (taper au clavier, déplacer la souris, utiliser les disques)
pendant la génération de nombres premiers ; cela donne au générateur de
nombres aléatoires une meilleure chance d'obtenir suffisamment d'entropie.
De nombreux octets aléatoires doivent être générés. Vous devriez faire
autre chose (taper au clavier, déplacer la souris, utiliser les disques)
pendant la génération de nombres premiers ; cela donne au générateur de
nombres aléatoires une meilleure chance d'obtenir suffisamment d'entropie.

gpg: répertoire « /home/sima78/.gnupg/openpgp-revocs.d » créé
gpg: revocation certificate stored as '/home/sima78/.gnupg/openpgp-revocs.d/32B2C27E1C7D3D688FA1D49F2C07D84901065A3D.rev'
les clefs publique et secrète ont été créées et signées.

pub   rsa4096/0x2C07D84901065A3D 2024-11-10 [SC]
      Empreinte de la clef = 32B2 C27E 1C7D 3D68 8FA1  D49F 2C07 D849 0106 5A3D
uid                              sima78 (clés perso 01) <mon@mail.fr>
sub   rsa4096/0x373FEA503684F9B2 2024-11-10 [E]

On vérifie la liste des clés et note l’ID de la nouvelle clé
Une fois la nouvelle clé créée, listez vos clés pour noter l’ID de votre nouvelle clé :

gpg –list-keys

Exporter votre nouvelle clé publique

Exportez votre nouvelle clé publique pour la partager avec vos contacts :

sima78@jilipolla:~$ gpg --export --armor 0x2C07D84901065A3D > 2024-gnupg-sima78.asc

Publier la nouvelle clé publique sur un serveur de clés

Cela permet à vos contacts de retrouver votre nouvelle clé via un serveur de clés public, comme keys.openpgp.org. Il en existe plusieurs mais ils se synchronisent ente-eux

sima78@jilipolla:~$ gpg --send-keys --keyserver keys.openpgp.org 0x2C07D84901065A3D
gpg: envoi de la clef 0x2C07D84901065A3D à hkp://keys.openpgp.org

Il ne reste plus qu’à configurer les clients mail pour utiliser la nouvelle clé
Chaque client mail a des procédures spécifiques pour sélectionner une nouvelle clé GnuPG. Je ne vais donc pas détailler ici.

Récapitulatif des commandes que j’ai utilisées.

  • gpg –list-key
  • gpg –list-keys –with-colons | awk -F: ‘/^pub:e:/ {print $5}’
  • gpg –list-keys –with-colons | awk -F: ‘/^pub:e:/ {print $5}’ | xargs -I {} gpg –batch –yes –delete-keys {}
  • gpg –refresh-keys
  • gpg –output revocation_certificat.asc –gen-revoke mon@mail.fr
  • gpg –output revocation_certificat.asc –gen-revoke 0x2A5F500DD27DD6FB
  • gpg –full-generate-key
  • gpg –export –armor 0x2C07D84901065A3D > 2024-gnupg-sima78.asc
  • gpg –send-keys –keyserver keys.openpgp.org 0x2C07D84901065A3D

Les commandes 2, 3 et 4 sont optionnelles, j’avais juste besoin de faire du ménage.

Précisions, réflexion :
Il est fortement conseillé de créer un certificat de révocation de votre nouvelle clé que vous garderez précieusement dans vos sauvegardes. En effet, si pour une raison quelconque vous perdez votre paire de clés ou que votre clé est corrompue vous pourrez l’exporter pour révoquer votre clé et en recréer une nouvelle.
En écrivant cet article j’ai regardé ce que faisaient d’autres blogueurs, beaucoup commencent par générer la nouvelle clé et termine par la révocation de l’ancienne clé, c’est aussi une logique qui se tient.

Il existe de plus en plus de fournisseurs de messageries qui proposent la possibilité de chiffrement assymétrique de vos mails et signatures de façon simplifiée.

Pour aller plus loin
Gnu Privacy Guard (GnuPG) Mini Howto (Français)
Le manuel de GNU Privacy Guard (Français)

Vous pouvez vous lâcher dans les commentaires.

Le billet « GnuPG Renouveler sa clé de chiffrement » est apparu en premier sur le blog de Sima78.

Tuto – Chiffrement GnuPG et messagerie Protonmail

Tuto – Chiffrement GnuPG et messagerie Protonmail

Je n’ai pas de messagerie Protonmail par contre j’utilise GnuPG pour signer et chiffrer mes mails et pièces jointes.

J’avais un souci pour récupérer les clés publiques de mes correspondants sous Protonmail. Je mets donc ici les problèmes rencontrés et leurs résolutions.

Si cela peut servir à d’autres, cela me servira de toute façon de pense-bête.

Problème de récupération des clés GnuPG publiques Protonmail.

adressemail@protonmail.com est une adresse fictive pour ne pas mettre ici l’adresse réellement recherché, c’est pour l’exemple hein !

Lorsque j’essaie de récupérer une clé publique GnuPG Protonmail j’ai le message d’erreur suivant :
Quelle que soit la commande :

gpg --search-keys adressemail@protonmail.com

ou :

gpg2 –recv-keys adressemail@protonmail.com

J’ai le message d’erreur suivant :

gpg: WARNING: Tor is not running

gpg: error searching keyserver: Connexion refusée

gpg: échec de recherche au sein du serveur de clefs : Connexion refusée

On voit déjà que j’ai un souci de connexion lié à la configuration de mon GnuPG

Je commence donc par corriger cela :
Dans /home/user/.gnupg/dirmngr.conf j’ai commenté la ligne « use-tor » et toujours dans

###+++--- GPGConf ---+++###

# use-tor

Dans /home/user/.gnupg/gpg.conf j’ai modifié (dans la partie « keyserver ») le serveur par défaut et commenté l’ancien :
Remplacé « keyserver hkp://keys.gnupg.net » par « keyserver hkps://keys.openpgp.org »

#-----------------------------

# keyserver

#-----------------------------

# This is the server that --recv-keys, --send-keys, and --search-keys will

# communicate with to receive keys from, send keys to, and search for keys on

# keyserver hkp://keys.gnupg.net

keyserver hkps://keys.openpgp.org/

Deuxième tentative de récupération de la clé publique.

gpg --search-keys adressemail@protonmail.com

Et toujours rien, il ne trouve pas la clé ?…
Je vais sur les serveurs de clés en ligne rien de plus…

Je me renseigne et on me dit que les clés publiques Protonmail ne sont pas sur les serveurs publics habituels mais voir les renseignements sur :
https://blog.prokop.dev/posts/gpg-retrieve-public-key-proton-mail/ (Merci Syst)

Dernière tentative après avoir les informations sur le lien ci-dessus :

Et tout fonctionne à nouveau correctement :

gpg --keyserver hkps://api.protonmail.ch --search-key adressemail@protonmail.com

gpg: data source: https://api.protonmail.ch:443

(1)    systd@protonmail.com <adressemail@protonmail.com>

      2048 bit RSA key 0x2AB4A510999264D7, créé : 2017-07-25

Keys 1-1 of 1 for "adressemail@protonmail.com".  Entrez le ou les nombres, (S)uivant, ou (Q)uitter > 1

gpg: clef 0x2AB4A510999264D7 : clef publique « adressemail@protonmail.com <adressemail@protonmail.com> » importée

gpg: Quantité totale traitée : 1

gpg:               importées : 1

Ensuite je n’ai plus qu’à signer la clé et lui donner un niveau de confiance.
Terminé !

PS : le numéro de la clé est faux aussi, c’est pour l’exemple.

Le billet Tuto – Chiffrement GnuPG et messagerie Protonmail est apparu en premier sur le blog de Sima78.

Humeur – Sentiment de solitude avec GnuPG

René Magritte sima78, janv. 2018
René Magritte sima78

Humeur – Sentiment de solitude avec GnuPG

Je n’envisageais pas écrire un billet sur le sujet. Faire un Tuto sur GnuPG ? Certains en ont fait d’excellents et je ne vois pas ce que je peux y ajouter.

C’est un billet de ChezIceman « Tuto – Le mail sécurisé c’est pas si facile, sauf si… » qui m’a décidé de parler de mon expérience.

J’utilise GnuPG depuis déjà un certain temps.

J’ai plusieurs PC, tous sous linux, j’utilise sur tous GNOME Evolution (bah oui, j’aime bien) comme messagerie sauf sur l’un sur lequel j’utilise Thunderbird, car le pc a moins de ressource et Thunderbird est moins lourd qu’évolution… Me semble-t-il.

Je n’ai aucune expérience sur ordiphone puisque je ne communique pas par mail depuis mon ordiphone, je n’ai donc aucune expérience sur le chiffrement depuis ces appareils. J’ai bien une messagerie configurée dessus, mais elle est dédiée uniquement à recevoir mes log « Logwatch » et « Fail2ban » de mon serveur. Je n’envoie pas de message depuis cette messagerie.

J’ai bien une messagerie sur mon ordiphone professionnel, mais pas chiffrée et uniquement pro… Enfin, j’avais… depuis qu’il est cassé il y a 4 mois ils me l’ont remplacé par un téléphone à clapet, manque de budget, du temporaire paraît-il, entre-temps ils ont payé un ordiphone tout neuf (plus de 400 €) pour qu’une partie de mes équipes vérifient les Pass Sanitaires du public… Mais bon, ça c’est une autre histoire.

Bref, j’utilise GnuPG !

Il y a toujours un début à tout.
Je ne saurais pas dire depuis quand, mais assez tôt, lorsque j’ai découvert GnuPG (début des années 2000), je me suis documenté, créé mes clés, etc.

Wouaa Sima, mais alors tu communiques en chiffré depuis longtemps ! Hola, on se calme.[1]

Au tout début, j’étais donc seul à détenir une paire de clés, personne d’autre dans mon entourage, ce qui ne sert strictement à rien, car il faut au moins être deux pour communiquer en chiffré. Mais le sujet m’intéressait, j’apprenais et signais mes messages même si je savais que personne de l’autre côté pouvais vérifier ma signature… Ça ne servait donc à rien sauf pour ma culture personnelle.

Quand il y a un début, c’est qu’il y a une suite.
Puis j’ai rencontré (On Line) trois blogueurs qui utilisaient GnuPG avec qui j’ai communiqué en chiffré. Enfin, je pouvais tester mes connaissances, mettre en pratique la théorie acquise et j’en étais heureux, je pense que la joie était partagée, il y avait si peu de personnes qui utilisaient GnuPG.

Le hasard de la vie fait que l’on sait perdu de « vue », en fait ils ont arrêté de bloguer et nous n’avons plus communiqué. Puis il y a eu les « Café Vie Privée » (qui ne fonctionnent plus vraiment), j’ai participé à certains, j’en ai organisé dans les Yvelines avec d’autres libristes et dans ce contexte j’ai rencontré d’autres personnes qui communiquaient en chiffré, et des personnes qui s’y intéressaient. Ce qui me fait un peu sourire aujourd’hui, c’est que j’ai connu des personnes avec des discours défendant de façon abrupte la nécessité d’échanger en chiffré, faisant presque culpabiliser ceux qui ne le faisaient pas… Et qui aujourd’hui sont retournés à leurs messageries (FAI) sans chiffrement…
Toujours est-il qu’il a eu une période où j’ai échangé un peu plus en chiffré.

Puis c’est retombé comme un soufflé mal cuit.
Il faut dire qu’utiliser GnuPG, n’est pas si simple, cela demande une certaine rigueur (la rigueur n’est pas ma qualité première), tenir à jour ses clés, les synchroniser, être vigoureux pour le réseau de confiance, etc. Il faut reconnaître que c’est un peu une usine à gaz et je me suis retrouvé un peu seul, je n’ai que de rares personnes dans mon entourage utilisant le chiffrement pour communiquer. Sentiment de solitude !

Démocratisation et retour timide du chiffrement.
Alors bien sûr il y a la médiatisation, mais je pense que la sensibilisation est plutôt liée à l’actualité et aux nouvelles formes de communiquer de façon plus sécurisée : SMS via Silence, réseau Signal, Element, Telegram et autres. Et ce sont, AMHA, ceux qui communiquent via ces applications qui s’intéressent à la messagerie chiffrée, ce qui en fait une continuité et il y a des propositions « grand public » comme Prontomail et autres sauf que la grande majorité de ceux qui l’utilisent n’ont pas une réelle connaissance de ce qu’est une clé privée et clé publique et utilisent donc Prontomail de la façon la plus basique.

Dernièrement j’ai un collègue qui me dit : moi aussi Sima je communique en crypté (hou, ça fait mal aux oreilles), j’utilise Prontomail. Bah non, tu ne communiques pas en chiffré, en tout cas pas avec moi. Il ne faut pas oublier que Protonmail, comme d’autres, est une messagerie qui PERMET de communiquer de façon chiffrée, en cela j’ai vraiment apprécié le tutoriel d’Iceman « Tuto – Le mail sécurisé c’est pas si facile, sauf si… » que je conseille aux utilisateurs de Protonmail.

On va peut-être finir par savoir communiquer par mails chiffrés.

Deux excellents tutoriels GnuPG

Gnu Privacy Guard (GnuPG) Mini Howto (Français)

et l’excellent « Bien démarrer avec GnuPG« 

Précision de dernière minute: alors que le billet était déjà écrit et programmé pour sa publication j’ai souhaité tester l’application OpenPGP-Applet sous ubuntu20.04 pour gérer mes clés depuis une interface graphique. Une application qui par le passé ne m’a jamais convaincu par son fonctionnement hasardeux. Je l’installe, la lance et rien ne se passe, rien ne s’affiche… Pourtant avec un « ps aux » je vois que le processus est lancé, mais rien! Bon, je retourne à mes lignes de commande, mais le chiffrement conviviale pour l’utilisateur lambda n’est pas pour demain.

PS : avertissement pour ceux qui utilisent GnuPG sous Evolution, les pièces jointes ne sont pas chiffrées, il faut préalablement les chiffrer avant envoi.

Note(s)

  1. ^ Oui, ceux qui me lisent, les rares, savent qu’il m’arrive souvent de faire les questions réponses, en plus d’être dyslexique, je dois avoir une pointe de schizophrénie non diagnostiquée, je me sens moins seul devant l’écran 🙂

Crypsetup – Chiffrer la partition var

chiffrer partition varDéplacer la partition var dans une partition chiffrée

ATTENTION! La partition « var/ » est solicitée très tôt au boot, la déplacer sans précaution sur une partition chiffrée, c’est vous assurer d’un plantage au démarrage… Sauvegardez et suivez les instructions sans sauter d’étape.

Ce billet est dans la catégorie « Serveur », mais on peut appliquer cette méthode à tout pc sous linux.

Partons d’un principe que vous ayez déjà une partition chiffrée nommée « d5 » sur laquelle vous souhaitez déplacer le dossier « var » et tout ce qui s’y trouve… Étape par étape…

Pour en savoir plus sur le chiffrement de données allez faire un tour du côté de chez Hoper que je remercie!
Chiffrement-Theorie
Chiffrement-Pratique

Donc c’est fait! Vous avez une partition chiffrée prête à accueillir votre dossier « /var/ »

Déplacer /var dans une partition chiffrée en 6 étapes

1 Créer un fichier « crypttab » dans /etc/
Mettre le nom de la partition chiffrée, le « /dev/XXX » Correspondant « none » et la méthode de chiffrement. Ici, nous prenons l’exemple qu’il s’agit du /dev/sda5… Recherchez votre « dev/ » avec la commande « sudo fdisk -l »:

# vi /etc/crypttab

Et mettre

d5   /dev/sda5    none     cipher=aes-xts-plain64,size=512

2 Rechercher UUID de la partition avec la commande « blkid »

# blkid
/dev/sda1: UUID="53ca7412-1ff7-105d-13fd-b15ab0d5" TYPE="ext4"
/dev/sda5: UUID="24fda933-44f3-30da-1947-3c4508af77ae" TYPE="swap"
/dev/mapper/d5: UUID="f254212d-9492-fab0-9220-4f5dad3c940a" TYPE="ext4"

Il s’agit de la 3ème ligne

3 Ouvrir le fichier « fstab » et rajouter à la fin:

UUID="f254212d-9492-fab0-9220-4f5dad3c940a" /var    ext4    defaults    0    0

Vérifier avec la commande df -h, vous devriez voir la ligne suivante dans la liste

# df -h
(…)
/dev/mapper/d5   650G    1,4G  382G   1% /var

Moi j’ai:
/dev/mapper/d5_unformatted   650G    1,4G  382G   1% /var
Mais ça marche très bien !

4 Vérifier les processus en cours

# ps -eaf | less

D’autres préférerons « more »

# ps -eaf | more

    Arrêter les bases de données et apaches… dans mon cas:

# /etc/init.d/mysql stop
# /etc/init.d/apache2 stop
# /etc/init.d/postgresql stop

Puis revérifier:

# ps -eaf | less

5 Copier le contenu de /var dans /d5

# cp -a /var/* /d5/

    renommer le dossier /var pour pouvoir « faire marche arrière » en cas de problème.

# mv /var /var.old

6 C’est fini, on redémarre.
Seule contrainte, il faudra mettre un clavier et un écran sur le serveur qui demandera un mot de passe au moment de monter /var, donc à chaque reboot.

# reboot

LVM et cryptsetup partitioner et chiffrer un disque dur

lvm crypsetupJ’ai mis ce billet dans la catégorie serveur, mais en réalité cela s’applique à n’importe quel PC

Vous venez d’installer un disque supplémentaire sur votre pc.

Vous souhaitez le partitionner avec LVM (logical volume management ou gestion par volumes logiques) puis chiffrer les partitions avec Cryptsetup.

Prenons ici un disque dur de 1To et que l’on souhaite faire deux partitions qu’on nommera « donnees » et « save »

Vérifier les disques montés, et éviter de se tromper de disque. 🙂
Deux commandes utiles
sudo fdisk -l
sudo df -h

Avant tout, connaître sur quel « dev » se trouve le nouveau disque.

sudo fdisk -l
(...)
Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 têtes, 63 secteurs/piste, 121601 cylindres, total 1953525168 secteurs
(...)
Le disque /dev/sdb ne contient pas une table de partitions valable
(...)

On commence par créer notre volume physique

sudo pvcreate /dev/sdb
  Physical volume "/dev/sdb" successfully created

Puis on crée le groupe de volume

sudo vgcreate mvg /dev/sdb
  Volume group "mvg" successfully created

Maintenant on crée les volumes logiques (nos nouvelles partitions) :

sudo lvcreate -n donnees -L 700g mvg
  Logical volume "donnees" created
sudo lvcreate -n save -L 300g mvg
  Volume group "mvg" has insufficient free space (59267 extents): 76800 required.

Houps ! lors de la création du 2ème volume, il n’y a pas assez de place…
Solution et explication:
Il se trouve qu’il ne reste pas 300 Go de disponible mais, comme il l’indique seulement 59267 « extends ».
La taille d’un extend dépend des paramétrages utilisés lors de la création de la configuration LVM.
Par défaut, il fait des extends de 4 Mo.
Il indique donc très justement que pour créer un volume de 300 Go, il te faudrait 59267 « bouts » de 4 Mo.
  Volume group « mvg » has insufficient free space (59267 extents): 76800
Pour utiliser tout l’espace restant, le plus simple est de lui indiquer une taille en extend, dans ce cas :

sudo lvcreate -n save -l 59267 mvg 

Notez bien que ce n’est plus -L (taille) mais -l (extend), le petit l permet d’indiquer une taille directement en nombre d’extend, et pas en Mo/Go/To etc. »

Là le disque dur sous LVM est opérationnel…. Le chiffrage est un plus…

Maintenant je souhaite chiffrer les 2 partions créées, puis les monter respectivement dans « /mnt/donnees » et « /mnt/save »
Dans l’ordre: on se rend sur le répertoire /mnt, puis on crée les 2 répertoires (donnees et save).

cd /mnt
sudo mkdir donnees
sudo mkdir save

On chiffre les partitions avec cryptsetup, on y mets un type de fichier (là ext4) puis on les montes.

sudo cryptsetup -y --cipher=aes-xts-plain64 -s 512 create don /dev/mvg/donnees
sudo mkfs -t ext4 /dev/mapper/don
sudo mount /dev/mapper/don /mnt/donnees
sudo cryptsetup -y --cipher=aes-xts-plain64 -s 512 create sav /dev/mvg/save
sudo mkfs -t ext4 /dev/mapper/sav
sudo mount /dev/mapper/sav /mnt/save

Et voilà, c’est fini !

Pour « démonter » les volumes.

sudo umount /mnt/donnees
sudo cryptsetup remove don
sudo umount /mnt/save
sudo cryptsetup remove sav

Pour y accéder par la suite, à chaque démarrage il faudra taper les commandes suivantes:

sudo cryptsetup --cipher=aes-xts-plain64 -s 512 create don /dev/mvg/donnees
sudo mount /dev/mapper/don /mnt/donnees
sudo cryptsetup --cipher=aes-xts-plain64 -s 512 create sav /dev/mvg/save
sudo mount /dev/mapper/sav /mnt/save

Pour aller plus loin:
4 billets sur LVM et 2 sur le chiffrage sur le site Hoper sur l’onglet « Partage de connaissances »