GnuPG Faut-il signer ou chiffrer ses mails

1 170 mots, temps de lecture 6 minutes.

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 ?:

Continuer la lecture de « GnuPG Faut-il signer ou chiffrer ses mails »

GnuPG Renouveler sa clé de chiffrement

1 654 mots, temps de lecture 9 minutes.

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 ?

Continuer la lecture de « GnuPG Renouveler sa clé de chiffrement »

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

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 la partition var

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.

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

J’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 »