L’anonymat pour tous

English: Tor Logo
English: Tor Logo (Photo credit: Wikipedia)

Les derniers révélations sur la surveillance des réseaux d’informations et de télécommunications nous amène à nous interroger sur la nécessité de s’en protéger. Derrière le bien fondé de nous protéger contre le mal qui en veut à la nation, ou toute autre bonne intention dont l’enfer est pavé, on veut nous surveiller. Ainsi dès que monsieur tout le monde va sur un site internet, ses habitudes sont répertoriées, les sites visités peuvent être retrouvés, et son identité informatique peut être découverte et donc son identité réelle aussi.

On voit bien que cela est dangereux pour des opposants politiques sous des régimes contraignants mais on ne réalise pas que cela l’est aussi dans nos “démocraties”. Rappelons que le partie au pouvoir voulait enlever le mot race de la constitution et par ce fait voulait supprimer un mot donc une idée de la circulation. Les idées devraient être libre de circuler: si elles sont ineptes, les individus ne vont pas les véhiculer, mais les interdire d’exister c’est tout simplement le début de la dictature. Nous devons donc nous méfier des autorités pour préserver notre liberté tant que la liberté d’expression et d’information ne sera pas devenu un droit inaliénable. C’est pour cela que l’anonymat n’est pas seulement une affaire d’opposants ou d’activistes résidents sous des régime oppressants: nous sommes également sous des régimes qui seront jugés oppressant par leurs successeurs !

Actuellement les contournements techniques existent car les mathématiques fonctionnent toujours, si bien que même les organisations de surveillance ne peuvent pas casser la cryptographie lourde et voient d’un mauvaise œil leur diffusion au grand public. Dans une époque pas si lointaine se promener dans la rue avec une disquette contenant des données cryptées était illégal ! Divulguer et démocratiser l’usage de la cryptographie forte est donc un devoir pour tous ceux qui place leur liberté au dessus de toute valeur.

Si la cryptographie permet d’obtenir la confidentialité et l’authenticité par le chiffrement et la signature, les mécanismes d’internet n’ont pas pour but de garantir l’anonymat. C’est pourquoi lorsque l’anonymat est requis il faut utiliser des artifices de routage (basés sur la cryptographie): le plus accessible est aujourd’hui la distribution Tails.

Tails permet d’exécuter un système entièrement configuré pour son intégration dans The Onion Router (TOR). Les accès réseaux passent par TOR ce qui rend l’utilisateur anonyme pour la destination: un site web ne saura pas qui vous êtes sur le réseau. Cela est valable pour tous les autres ressources: si vous faite utiliser le client de messagerie ou ouvrez une connexion  le serveur de messagerie et le serveur SSH ne saura pas où vous êtes sur le réseau.  En réalité la nature de TOR fait que le destinataire croira que vous êtes sur une adresse IP correspondant à l’un des nœud TOR présents dans le monde. Tails permet donc sans configuration d’accéder à l’anonymat en ligne et de plus ne laisse pas de trace sur la machine ce qui renforce la sécurité de l’utilisateur en rendant impossible une analyse après une saisie de la machine par exemple…

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:

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.

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.

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…)