Mails sécurisés S/MIME avec Thunderbird sous TAILS Linux

Crystal Thunderbird icon
Image via Wikipedia

TAILS est une distribution offrant l’anonymat sur internet tout en ne laissant pas de trace sur la machine hôte (et le cas échéant sur la clé USB qui héberge l’OS). Pour la plupart des usages tels que la navigation internet, le webmail, l’édition de documents etc…l’usage du répertoire temporaire, dont la taille dépend de la quantité de RAM disponible, est amplement suffisant.
Mais il y a des cas qui nécessitent d’une part de persister les changements comme par exemple le paramétrage d’une boîte mail et d’autre part l’usage de fonctionnalités non couvertes par les applications de la distribution comme par exemple l’usage de S/MIME pour la signature et le cryptage de mails. C’est ainsi que TAILS 2011.04 propose Claw Mails dans une version qui n’inclut pas le chiffrement S/MIME mais uniquement GnuPG. Le module S/MIME disponible sur le site de Claw Mail indique qu’il nécessite une version plus récente du client mail. La solution que nous proposons est l’usage de Thunderbird avec persistance des paramètres de mail.

Prerequis

Nous supposons que la clé USB contenant TAILS est constituée de 2 partitions. La première contient l’ISO de TAILS proprement dite et la seconde est une partition cryptée.

Installation de Thunderbird

Télécharger l’archive de thunderbird sur le site officiel puis décompresser le répertoire thunderbird dans la partition crypté. Si nous supposons que la partition crypté est monté sous /media/data, alors on peut décompresser notre client mail dans /media/data/Programmes/thunderbird.

L’astuce pour que la paramétrage des comptes mails ainsi que le contenu des mails soit persisté de façon sécurisé sur la partition cryptée consiste à faire un lien symbolique de /home/amnesia/.thunderbird vers /media/data/.thunderbird. Le script ci-après permet de lancer thunderbird en créant au préalable répertoire et lien symbolique si nécessaire. Créons le fichier /media/data/Programmes/mail.sh avec le contenu suivant:

#!/bin/bash
# fichier /media/data/Programmes/mail.sh
USB_MOUNT_POINT=/media/data
PROGRAM_LOC=$USB_MOUNT_POINT/Programmes
PROGRAM_DIR=$PROGRAM_LOC/thunderbird
if [ ! -e $USB_MOUNT_POINT/.thunderbird ]; then
  mkdir $USB_MOUNT_POINT/.thunderbird
fi
if [ ! -e ~/.thunderbird ]; then
 sudo ln -s $USB_MOUNT_POINT/.thunderbird ~/.thunderbird
fi
$PROGRAM_DIR/thunderbird

 

Réception de mail crypté S/MIME avec Javamail-crypto

Crypto stub
Image via Wikipedia

Dans le billet précédent je montrais comment envoyer un mail S/MIME, ce billet traite de l’opération inverse. Comment réceptionner un mail crypté et signé en S/MIME ?

L’idée est de reprendre la méthode de lecture du certificat publique du signataire pour vérifier la signature du mail mais il faut auparavant décrypter le mail reçu. En effet l’expéditeur signe le message puis le crypte donc on doit décrypter puis vérifier la signature une fois que le mail est devenu lisible.
Voici le pseudo-code

MimeMessage m = retrieveMessageFromMailBox();
m = decryptMessage(m);
checkSignature(m);

La lecture du message dans la boite mail ne pose pas de grande difficulté mais le résultat est un mail avec comme content-type la valeur application/pkcs7-mime. Malheureusement le code utilitaire SMIMEEncryptionUtils de javamail-crypto (qui décrypte un message contient un oubli qui l’empêche de gérer les mails cryptés contenant des PJ comme c’est le cas dans un mail signé. En effet le résultat du décryptage doit être un mail avec le content-type valant multipart/signed ou application/pkcs7-mime ou bien application/x-pkcs7-mime, sinon le mail n’est pas détecté comme un mail signé. Or le méthode qui décrypter decryptMessage.decryptMessage()oublie malheureusement d’invoquer saveChange()sur le message. Aussi le le content-type n’est pas mis à jour. So do it yourself !

Ensuite il suffit d’appeler la méthode utilitaire de vérification de signature SMIMEEncryptionUtils.checkSignature() pour finir la partie réception d’un S/MIME. Il est a noté que le mail signé par SMIMEEncryptionUtils.signeMessage() est de type multipart/signed ce qui signifie que le mail est constitué de 2 partie :

  1. le contenu message original avant signature
  2. la signature portant sur le message original précédent

Il faut en tenir compte pour extraire les informations du message original. C’est-à-dire que le contenu du mail décrypté que l’on obtient par MimeMessage.getContent() pourra être itéré mais on ne s’intéressera qu’à sa première partie. Cette première partie obtenue par Multipart.getBodyPart() sera soit considéré comme  le contenu du corps du message original avant signature si son content-type est text/plain mais si le message original avait déjà des pièces-jointes le content-type sera multipart/mixed et il faudra alors itérer sur la première partie. La forme du message original dépend du client mail utilisé pour créer le message original avant signature et cryptage.

Encrytage de mail avec JavaMail-Crypto et BouncyCastle

Icon from Nuvola icon theme for KDE 3.x.
Image via Wikipedia

Javamail-crypto est une API peu récente puisque le jar est estampillé juin 2006. Cepedant l’usage de cette API simplifie grandemant la vie du programmeur puisque pourvu que le message en clair, la session mail, ainsi que la clé soient fournis, il suffit de faire

EncryptionUtils smimeUtils = null;
String type = EncryptionManager.SMIME;
smimeUtils = EncryptionManager.getEncryptionUtils(type);
smimeSignedMsg = smimeUtils.encryptMessage(session, mmessage,
smimeKey);

Lorsque l’on doit envoyer un mail crypté à la norme S/MIME, on utilise la clé publique du destinataire. On ne peut pas utiliser Javamail-crypto et Bouncycastle comme on le ferait dans le cas de la signature comme dans l’exemple suivant:

char[] smimePw = new String("mot de passe")
.toCharArray();
EncryptionKeyManager smimeKeyMgr = smimeUtils.createKeyManager();
InputStream privKeyIS = null:
smimeKeyMgr.loadPrivateKeystore(privKeyIS, smimePw);
smimeKey = smimeKeyMgr.getPrivateKey("cle privee signature",
smimePw);

En effet bien que l’on puisse charger les clé publiques, l’API s’attend à lire en entrée un fichier PKCS12. Or ce fichier doit aussi contenir la clé privée ce que le destinataire du mail ne va jamais nous fournir. Il se bornera à nous fournir un certificat contenant sa clé publique.

Heureusement que l’API de cryptage prend une clé java.security.Key , il nous suffit de créer un tel objet. Pour cela il ne suffit par de créer un objet implémentant l’interface Key car le code de SMIMEEncryptionUtils.encryptMessage() fait un transtypage:

BouncySMIMEEncryptionKey bKey = (BouncySMIMEEncryptionKey) key;

Nous devons donc créer de toute pièce une instance de BouncySMIMEEncryptionKey.Cela est assez facile car en regardant le code on voit qu’il nous suffit, pour encryptage de mail, de fixer le certificat dans un objet BouncySMIMEEncryptionKey.

Voici le code complet pour lire la clé publique dans un fichier PEM et encrypter un mail:

EncryptionUtils smimeUtils = null;
BouncySMIMEEncryptionKey smimeKey = null;
String type = EncryptionManager.SMIME;
smimeUtils = EncryptionManager.getEncryptionUtils(type);
PEMReader reader = new PEMReader(new InputStreamReader(inputStremoOnThePEM));
X509CertificateObject cert = (X509CertificateObject) reader.readObject();
smimeKey = new BouncySMIMEEncryptionKey();
smimeKey.setCertificate(cert);
MimeMessage smimeSignedMsg = smimeUtils.encryptMessage(session, mmessage,smimeKey);

Sécuriser ses courriels en S/MIME avec Gnome Evolution

Category:WikiProject Cryptography participants
Image via Wikipedia

On entend par sécurisation de courriel le fait de garantir l’intégrité et la confidentialité du contenu. L’intégrité du contenu est assurée quand le message reçu est authentique c’est-à-dire qu’il est bien celui que l’expéditeur a envoyé. La confidentialité est assurée quand seul le destinataire peut lire le contenu du message.

La sécurisation des mails se fait par signature du contenu puis cryptage de l’ensemble (contenu original + signature). La signature et le cryptage se font avec un algorithme cryptographique dont la sécurité est basée sur le secret de la clé et la difficulté à deviner la clé. L’algorithme que nous allons utiliser est RSA qui utilise en fait une paire de 2 clés liées entre elles, l’une privée et l’autre publique. La difficulté à deviner la clé publique se base sur l’impossibilité (à ce jour) de trouver un algorithme indépendant de la taille de la clé privée pour calculer le logarithme discret. En réalité il n’y a pas d’algorithme de calcul du logarithme discret si bien qu’il faut tester toutes les solutions (clés privées hypotètiques) et voir si ça marche. A l’heure d’aujourd’hui une clé RSA de 2048 bits est jugées sûre. En effet cela correspond à un ensemble de plus de 3*10^500 clés hypothètiques.

La norme S/MIME spécifie comment former le mail pour y inclure la signature electronique et comment encapsuler la forme cryptée dans un mail (qui n’est qu’un texte). S/MIME indique également comment utiliser les certificats x509. X509 est une norme pour authentifier des clés publiques. Le certificat garantit donc qu’une clé publique donnée correspond bien à une clé privée appartenant à une personne donnée. Cette garantie est donnée par la caution d’une autorité dite de confiance qui se charge contre rémunération de vérifier l’authenticité de la clé publique.

Pour générer la paire de clés RSA on utilise openssl disponible sous toutes les distributions linux. A ce jour Ubuntu 10.10 propose la version 0.9.8o. Ce n’est pas la version la plus à jour que l’ont peut trouver sur www.openssl.org.

~$ openssl version
OpenSSL 0.9.8o 01 Jun 2010

Pour information le N900 dispose aussi d’openssl en version 0.9.8n
~ $ openssl version
OpenSSL 0.9.8n 24 Mar 2010

Commençons par générer une clé privée RSA en entrant la commande suivante dans un terminal:


Cela va créer le fichier privkey.pem contenant une clé RSA cryptée en triple DES avec le mot de passe renseigné.

Attention: le mot de passe demandé permet de crypter la clé afin de la protéger si un intrus accède au fichier. NE PAS OUBLIER CE MOT DE PASSE.

Changez les droits d’accès à la clé privée pour être le seul à pouvoir y accéder. Remplacer le user et le groupe par votre user.

sudo chmod 400 privkey.pem
sudo chown thierry:thierry privkey.pem

Nous disposons à ce stade d’une clé privée RSA avec laquelle nous pouvons signer des mail pour authentifier nos envois et décrypter des mails pour s’assurer que personne n’espionne les mails que l’on reçoit.

Pour ce faire il nous faut générer la clé publique associée à notre clé privée. La clé publique est stockée dans un certificat x509 qui devrait être signé par une authorité de confiance qui atteste que c’est bien notre clé publique RSA. Cependant Pour pouvons faire un certificat signé avec notre propre clé privée. Dans un terminal rentrons la commande suivante:

sudo openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095

Cela va créer un certificat x509 valide pendant 3 ans, contenant des informations pour nous identifier (pays, ville, organisagtion, nom, email) ainsi que la clé publique RSA. Ce certificat prétend que la personne identifiée possède la clé privée associée à la clé publique presente dans le certificat. Comme ce certificat est signé par nous même, la preuve de l’identité n’est pas garantie puisque l’on peut faire un certificat au nom d’une autre personne. Par contre on a la garantie cryhptographique que celui qui a fait le certificat possède la clé privée associée à la clé publique à cause de la signature RSA du certificat. Cette garantie est suffisante dans un cadre privé et nous pouvons toujours publier le certificat sur un site web à notre nom afin de lui donner un cachet officiel.

Le fichier cacert.pem est public mais ne doit pas être altéré sinon au mieux le certificat sera faux à cause de sa signature RSA devenue non valide et au pire non authentique dans la cas d’un certificat remplacé par un autre dont on ne possède pas la clé privé (dans ce cas on est victime d’usurpation d’identité).

Modifions les droits du fichier de certificat pour le rendre accessible à tous en lecture seule. Remplacez le user par votre user.

sudo chown thierry:thierry cacert.perm
sudo chmod 444 cacert.pem

Ce certificat doit être importé dans Evolution en temps que certificat d’autorité de sorte les mails signés avec notre clé privée soit considéré valide d’une part parce que la signature correspond au message et d’autre par parce que le certificat est signé par une autorité de certification reconnu dans Evolution. La manipulation suivante doit être faite chez tous les destinataires de nos mail signé.

Utilisons la commande suivante pour nous envoyé un mail signé. Rentrer le mot de passe de la clé privée puis le contenu du mail puis finir par CTRL-D
thierry@jesus:~/crypto$ sudo openssl smime -sign -signer cacert.pem -inkey privkey.pem -text -from xxxxx@xxxxx.xxx -to xxxxx@xxxxx.xxx -subject "Signed message" | sendmail xxxxxx@xxxxxxx.xxx
Enter pass phrase for privkey.pem:
ce message est trés important
thierry@jesus:~/crypto$

En ouvrant le mail dans Evolution on doit voir le contenu du mail mais une alerte nous prévient que la signature n’est pas valide.

En effet bien que la signature soit correcte car le certificat est envoyé dans le mail et Evolution constate que la signature correspond bien au contenu,  le certificat n’est pas authentifié. Cliquez sur l’icône  et une fenêtre indique que le certificat n’est pas sûr:

Pour y remédier il faut ajouter le certificat dans la liste des certificat de confiance (Certificate Authority). Pour cela dans Evolution aller dans le menu Edition > Préférences > Certficats > Autorités pour importer le fichier cacert.pem. Cette manipulation doit être faite chez tous les destinataires de nos mails signé (si on avait fait signé notre certificat par une autorité reconnue cela n’aurait pas été nécessaire mais payant).

Attention: un certificat est public et aucun mot de passe n’est demandé mais le coffre fort contenu les certificats de Gnome Evolution est protégé par mot de passe. Si un message suivant apparait Enter the password for `NSS User Private Key and Certificate Services` il s’agit d’un autre mot de passe que celui de notre clé privée.

Cocher toutes les cases pour simplement dire que nous faisons confiance à ce certificat pour tout même si seule la case courrier électronique est nécessaire.

En revenant sur le mail on s’aperçoit que maintenant Evolution nous indique que la signature est correcte et valide.

Pour que nos destinataires vérifient notre signature il faut leur fournir notre certificat et qu’ils l’importent comme autorité de confiance.

Notre clé RSA nous a permi de signer un mail et maintenant nous allons tester la réception de mail crypté. Pour cela on va s’envoyé un mail crypté avec notre clé publique contenue dans le certificat (accessible à tous ceux qui veulent crypter un message à notre intention)

Nous reprenons la commande précédente (signature de message) et y ajoutons le cryptage. Le mot de passe de la clé privée est demandé à cause de la partie signature (optionnelle dans cette exemple) mais remarquons que la partie cryptage ne fait intervenir que le certificat public. Terminez par CTRL-D.

thierry@jesus:~/crypto$ sudo openssl smime -sign -signer cacert.pem -inkey privkey.pem -text | sudo openssl smime -encrypt -from xxxxx@xxxxx.xxx -to xxxxx@xxxxxxx.xxx -subject "Signed and encrypted message" cacert.pem | sendmail xxxxxxx@xxxxxxx.xxx
Enter pass phrase for privkey.pem:
Attention ce message est crypté à destination de Thierry Bressure. Le contenu est signé par Thierry Bressure.

Le message réceptionné par Gnome Evolution est bien crypté comme le montre la capture suivante :

C’est ce qui ce passe quand une personne qui n’a pas la clé de décryptage ouvre le mail.

Pour que nous puissions ouvrir le mail crypté à notre intention, nous devons ajouter notre certificat privé dans Evolution. Le certificat privé est la concaténation du certificat public (cacert.pem) et de la clé privée, le tout dans un format spécial dit PKCS12 (.p12).

Pour créer le fichier pkcs12 rentrer dans un terminal:

thierry@jesus:~/crypto$ sudo openssl pkcs12 -export -in cacert.pem -out cacert.p12 -inkey privkey.pem -name "Thierry Bressure"

Le mot de passe de la clé privée est demandé pour décrypter la clé privée et un second mot de passe est demandé pour protéger la clé privée dans le fichier pkcs12.

Ce certificat ne doit pas être divulgué. Modifions les droit sur ce fichier cacert.p12 en faisant

sudo chown thierry:thierry cacert.p12
chmod 400 cacert.p12

Nous allons maintenant importer ce certificat privé dans Evolution. Dans Edition > Préférences> Certificats > Vos certificats cliquer sur importer.

Le mot de passe du coffre fort des certificats de Gnome est requis ainsi que le mot de passe du fichier pkcs12.

En retournant sur le mail on s’aperçoit que Evolution arrive maintenant à le décrypter grâce à notre certificat privé.

A ce stade nous avons montré que nos destinataires sont capable de vérifier notre signature et que nous somme capable de décrypter les mails qui nous sont destinés. Pour signer nos mails et crypter nos mails avec Evolution il suffit de choisir notre certificat privé dans Edition> Préférences > Compte de messageries > “sélectionner un compte” > Sécurité > Secure MIME à la fois pour la signature et le cryptage.

Attention pour crypter un message pour un destinataire il faut au préalable avoir reçu un mail signé (contenant son certificat public) de la part de cette personne.

Sécuriser ses courriels en S/MIME avec Gnome Evolution

Category:WikiProject Cryptography participants
Image via Wikipedia

On entend par sécurisation de courriel le fait de garantir l’intégrité et la confidentialité du contenu. L’intégrité du contenu est assurée quand le message reçu est authentique c’est-à-dire qu’il est bien celui que l’expéditeur a envoyé. La confidentialité est assurée quand seul le destinataire peut lire le contenu du message.

La sécurisation des mails se fait par signature du contenu puis cryptage de l’ensemble (contenu original + signature). La signature et le cryptage se font avec un algorithme cryptographique dont la sécurité est basée sur le secret de la clé et la difficulté à deviner la clé. L’algorithme que nous allons utiliser est RSA qui utilise en fait une paire de 2 clés liées entre elles, l’une privée et l’autre publique. La difficulté à deviner la clé publique se base sur l’impossibilité (à ce jour) de trouver un algorithme indépendant de la taille de la clé privée pour calculer le logarithme discret. En réalité il n’y a pas d’algorithme de calcul du logarithme discret si bien qu’il faut tester toutes les solutions (clés privées hypotètiques) et voir si ça marche. A l’heure d’aujourd’hui une clé RSA de 2048 bits est jugées sûre. En effet cela correspond à un ensemble de plus de 3*10^500 clés hypothètiques.

La norme S/MIME spécifie comment former le mail pour y inclure la signature electronique et comment encapsuler la forme cryptée dans un mail (qui n’est qu’un texte). S/MIME indique également comment utiliser les certificats x509. X509 est une norme pour authentifier des clés publiques. Le certificat garantit donc qu’une clé publique donnée correspond bien à une clé privée appartenant à une personne donnée. Cette garantie est donnée par la caution d’une autorité dite de confiance qui se charge contre rémunération de vérifier l’authenticité de la clé publique.

Pour générer la paire de clés RSA on utilise openssl disponible sous toutes les distributions linux. A ce jour Ubuntu 10.10 propose la version 0.9.8o. Ce n’est pas la version la plus à jour que l’ont peut trouver sur www.openssl.org.

~$ openssl version
OpenSSL 0.9.8o 01 Jun 2010

Pour information le N900 dispose aussi d’openssl en version 0.9.8n
~ $ openssl version
OpenSSL 0.9.8n 24 Mar 2010

Commençons par générer une clé privée RSA en entrant la commande suivante dans un terminal:

sudo  openssl genrsa -des3 -out privkey.pem 2048

Cela va créer le fichier privkey.pem contenant une clé RSA cryptée en triple DES avec le mot de passe renseigné.

Attention: le mot de passe demandé permet de crypter la clé afin de la protéger si un intrus accède au fichier. NE PAS OUBLIER CE MOT DE PASSE.

Changez les droits d’accès à la clé privée pour être le seul à pouvoir y accéder. Remplacer le user et le groupe par votre user.

sudo chmod 400 privkey.pem
sudo chown thierry:thierry privkey.pem

Nous disposons à ce stade d’une clé privée RSA avec laquelle nous pouvons signer des mail pour authentifier nos envois et décrypter des mails pour s’assurer que personne n’espionne les mails que l’on reçoit.

Pour ce faire il nous faut générer la clé publique associée à notre clé privée. La clé publique est stockée dans un certificat x509 qui devrait être signé par une authorité de confiance qui atteste que c’est bien notre clé publique RSA. Cependant Pour pouvons faire un certificat signé avec notre propre clé privée. Dans un terminal rentrons la commande suivante:

sudo openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095

Cela va créer un certificat x509 valide pendant 3 ans, contenant des informations pour nous identifier (pays, ville, organisagtion, nom, email) ainsi que la clé publique RSA. Ce certificat prétend que la personne identifiée possède la clé privée associée à la clé publique presente dans le certificat. Comme ce certificat est signé par nous même, la preuve de l’identité n’est pas garantie puisque l’on peut faire un certificat au nom d’une autre personne. Par contre on a la garantie cryhptographique que celui qui a fait le certificat possède la clé privée associée à la clé publique à cause de la signature RSA du certificat. Cette garantie est suffisante dans un cadre privé et nous pouvons toujours publier le certificat sur un site web à notre nom afin de lui donner un cachet officiel.

Le fichier cacert.pem est public mais ne doit pas être altéré sinon au mieux le certificat sera faux à cause de sa signature RSA devenue non valide et au pire non authentique dans la cas d’un certificat remplacé par un autre dont on ne possède pas la clé privé (dans ce cas on est victime d’usurpation d’identité).

Modifions les droits du fichier de certificat pour le rendre accessible à tous en lecture seule. Remplacez le user par votre user.

sudo chown thierry:thierry cacert.perm
sudo chmod 444 cacert.pem

Ce certificat doit être importé dans Evolution en temps que certificat d’autorité de sorte les mails signés avec notre clé privée soit considéré valide d’une part parce que la signature correspond au message et d’autre par parce que le certificat est signé par une autorité de certification reconnu dans Evolution. La manipulation suivante doit être faite chez tous les destinataires de nos mail signé.

Utilisons la commande suivante pour nous envoyé un mail signé. Rentrer le mot de passe de la clé privée puis le contenu du mail puis finir par CTRL-D
thierry@jesus:~/crypto$ sudo openssl smime -sign -signer cacert.pem -inkey privkey.pem -text -from xxxxx@xxxxx.xxx -to xxxxx@xxxxx.xxx -subject "Signed message" | sendmail xxxxxx@xxxxxxx.xxx
Enter pass phrase for privkey.pem:
ce message est trés important
thierry@jesus:~/crypto$

En ouvrant le mail dans Evolution on doit voir le contenu du mail mais une alerte nous prévient que la signature n’est pas valide.

En effet bien que la signature soit correcte car le certificat est envoyé dans le mail et Evolution constate que la signature correspond bien au contenu,  le certificat n’est pas authentifié. Cliquez sur l’icône  et une fenêtre indique que le certificat n’est pas sûr:

Pour y remédier il faut ajouter le certificat dans la liste des certificat de confiance (Certificate Authority). Pour cela dans Evolution aller dans le menu Edition > Préférences > Certficats > Autorités pour importer le fichier cacert.pem. Cette manipulation doit être faite chez tous les destinataires de nos mails signé (si on avait fait signé notre certificat par une autorité reconnue cela n’aurait pas été nécessaire mais payant).

Attention: un certificat est public et aucun mot de passe n’est demandé mais le coffre fort contenu les certificats de Gnome Evolution est protégé par mot de passe. Si un message suivant apparait Enter the password for `NSS User Private Key and Certificate Services` il s’agit d’un autre mot de passe que celui de notre clé privée.

Cocher toutes les cases pour simplement dire que nous faisons confiance à ce certificat pour tout même si seule la case courrier électronique est nécessaire.

En revenant sur le mail on s’aperçoit que maintenant Evolution nous indique que la signature est correcte et valide.

Pour que nos destinataires vérifient notre signature il faut leur fournir notre certificat et qu’ils l’importent comme autorité de confiance.

Notre clé RSA nous a permi de signer un mail et maintenant nous allons tester la réception de mail crypté. Pour cela on va s’envoyé un mail crypté avec notre clé publique contenue dans le certificat (accessible à tous ceux qui veulent crypter un message à notre intention)

Nous reprenons la commande précédente (signature de message) et y ajoutons le cryptage. Le mot de passe de la clé privée est demandé à cause de la partie signature (optionnelle dans cette exemple) mais remarquons que la partie cryptage ne fait intervenir que le certificat public. Terminez par CTRL-D.

thierry@jesus:~/crypto$ sudo openssl smime -sign -signer cacert.pem -inkey privkey.pem -text | sudo openssl smime -encrypt -from xxxxx@xxxxx.xxx -to xxxxx@xxxxxxx.xxx -subject "Signed and encrypted message" cacert.pem | sendmail xxxxxxx@xxxxxxx.xxx
Enter pass phrase for privkey.pem:
Attention ce message est crypté à destination de Thierry Bressure. Le contenu est signé par Thierry Bressure.

Le message réceptionné par Gnome Evolution est bien crypté comme le montre la capture suivante :

C’est ce qui ce passe quand une personne qui n’a pas la clé de décryptage ouvre le mail.

Pour que nous puissions ouvrir le mail crypté à notre intention, nous devons ajouter notre certificat privé dans Evolution. Le certificat privé est la concaténation du certificat public (cacert.pem) et de la clé privée, le tout dans un format spécial dit PKCS12 (.p12).

Pour créer le fichier pkcs12 rentrer dans un terminal:

thierry@jesus:~/crypto$ sudo openssl pkcs12 -export -in cacert.pem -out cacert.p12 -inkey privkey.pem -name "Thierry Bressure"

Le mot de passe de la clé privée est demandé pour décrypter la clé privée et un second mot de passe est demandé pour protéger la clé privée dans le fichier pkcs12.

Ce certificat ne doit pas être divulgué. Modifions les droit sur ce fichier cacert.p12 en faisant

sudo chown thierry:thierry cacert.p12
chmod 400 cacert.p12

Nous allons maintenant importer ce certificat privé dans Evolution. Dans Edition > Préférences> Certificats > Vos certificats cliquer sur importer.

Le mot de passe du coffre fort des certificats de Gnome est requis ainsi que le mot de passe du fichier pkcs12.

En retournant sur le mail on s’aperçoit que Evolution arrive maintenant à le décrypter grâce à notre certificat privé.

A ce stade nous avons montré que nos destinataires sont capable de vérifier notre signature et que nous somme capable de décrypter les mails qui nous sont destinés. Pour signer nos mails et crypter nos mails avec Evolution il suffit de choisir notre certificat privé dans Edition> Préférences > Compte de messageries > “sélectionner un compte” > Sécurité > Secure MIME à la fois pour la signature et le cryptage.

Attention pour crypter un message pour un destinataire il faut au préalable avoir reçu un mail signé (contenant son certificat public) de la part de cette personne.

Envoi de mail sécurisé en Java

Category:WikiProject Cryptography participants

Nous sommes dans le cadre du standard S/MIME avec 2 clés: une pour la signature et l’autre pour le cryptage.

Principe général

L’expéditeur veut être sûr que son message ne sera pas modifié pendant le transfert (internet n’est pas sûr…) Et que seul le destinataire pourra lire le message.

On recherche donc l’authenticité et la confidentialité.

  1. Signature : l’expéditeur signe le message avec sa clé privée.
  2. Cryptage : après avoir signé le message, l’expéditeur le crypte avec la clé publique du destinataire.

Outils

Java SE contient désormais les extension cryptographique mais l’API optionnelle JavaMail ne prend pas en charge la sécurité. Le programmeur doit donc transformer le message en clair en le passant en “multipart” pour y insérer la signature puis crypter les différentes parties et gérer les entêtes du mail pour indiquer au destinataire qu’il s’agit d’un mail crypté et signé.

JavaMail

La version courante 1.4.3 permet d’envoyer un mail en se connectant à un serveur SMTP. Nous utilisons en également les capacités de JavaMail à gérer les pièces jointes ainsi que les entêtes du mail.

Javamail-crypto

Cette librairie permet d’ajouter à JavaMail la prise en charge du S/MIME. JavaMail-Crypto s’appuie sur 2 founisseurs d’implémentation: BouncyCastle pour SMIME et Cryptix pour PGP. Seul le premier sera utilisé dans notre cas.

OpenSSL

OpenSSL est une librairie et des outils pour créer des clés et certificats cryptographique et les manipuler dans un contexte pratique (chriffrage…). Disponible sur tous les Unix il est également utilisable avec Cygwin (pour ceux qui sont du côté obscure…)