L’utilisation de javamail crypto doit permettre au développeur de ne pas trop rentrer dans la technique de la norme S/MIME. En effet avec des points d’entrée clairs comme crypter, signer, décrypter et vérifier on fait rapidement confiance. A tord.
Il y a pourtant des signes qui ne trompent pas comme la date de dernière mise à jour du projet: juin 2006, et les quelques TODO dans le code. On se raccroche néanmoins à un espoir devant la peur du code à écrire sans l’aide de cette bibliothèque. De plus, quand il s’agit de crypter, signer et décrypter, Javamail Crypto donne satisfaction. Le seul point inquiétant est la vérification de la signature S/MIME qui nécessite de faire une petite gymnastique pour fournir à l’API la clé publique pour vérifier la signature…
En regardant le post Réception de mail crypté S/MIME, on voit qu’une fois le certificat publique obtenu, il suffit de la passer à la classe utilitaire en même temps que le mail dont on veut vérifier la signature. La confiance est là et on oublie de tester ce qui se passe quand on signe avec un certificat différent de celui utilisé pour la vérification. La réponse est rien.
Quelle fut ma déception quand un mail signé par un tiers fut validé par javamail crypto combien même je lui passe un certificat différents comme référence! En investiguant la méthode appelée et grace à l’open source, la crédulité dont on a pu faire prouve tire en nous un le gloussement d’un rire nerveux. La clé passée en paramètre n’est jamais utilisée !!!!
En fait javamail se contente de vérifier que la signature correspond bien au contenu signé. Cette vérification de la non altération du message est cependant insuffisante quand il s’agit de données sensible. Sans aller jusqu’à s’assurer de la non répudiation en vérifiant les listes de révocation, on s’attend à ce que Javamail crypto s’assure au moins que la signature provient bien d’un émetteur donné. Sinon à quoi ça sert de passer la clé publique ?
Finalement il vaut mieux s’adresser à Dieu qu’à ses saints. En utilisant directement Bouncycastle dont javamail crypto est une abstraction, on s’en sort. Avec plus de code mais il faut bien ça. Le lecteur trouvera e lui même le détail de la solution en se référant à la classe org.bouncycastle.mail.smime.examples.ValidateSignedMail présente dans les sources.
Tags: BouncyCastle Javamail-crypto
bonjour,
je débute avec JavaMail. Si j’ai bien compris votre article, vous voudriez que JavaMail contrôle que l’utilisateur ait bien acheté un certificat qui lui permet de crypter son courriel ?
Pas exactement. Javamail est l’API java pour envoyer et recevoir des mail. Elle ne gère pas la norme S/MIME (cryptage et signature). javamail–crypto est une librairie qui simplifie l’usage de l’API de cryptographie Java (JCA, JCE) pour faire des mail cryptés/signés.
Quand vous recevez un mail signé, votre expéditeur dit 2 choses. Il dit qui il est et il dit qu’il authentifie le contenu du mail. Autrement dit la signature cryptographique garantie que c’est bien l’expéditeur qui a signé le mail et que personne n’a modifié le message entre-temps. C’est la garantie de non altération et de non répudiation.
J’aurais voulu que javamail-crypto permette de verifier la signature dans ses 2 aspects. Or il se contente de vérifier que la signature porte bien sur le message i.e. le mail n’a pas été modifié. Peu importe qui est le signataire. Comme dans la méthode de verification on passe le certificat (celui de l’expéditeur légitime) j’aurais voulu que toute tentative de m’envoyer un mail avec une signature quelconque échoue sauf dans le cas de l’expéditeur légitime. Malheureusement javamail-crypto ignore le paramètre qu’on lui passe donc n’importe qui peut m’envoyer un mail et javamail-crypto ne garantie que la non altération.
Salut,
Je ne sais pas si tu es dans les parages mais j’éprouve un peu de mal avec Bouncycastle s’agissant d’appliquer l’exemple ValidateSignedMail. En fait je tente de déchiffrer un mail et ensuite de vérifier sa signature en validant toute la chaîne de certificats via un fichier JKS où sont les autorités racines et intermédiaires concernées.
Mon gros problème est qu’après déchiffrement je récupère un MimeBodyPart en faisant ceci :
MimeBodyPart res = SMIMEUtil.toMimeBodyPart(recipient.getContent(jceKeyTransEnvelopRec));
L’exemple utilise une classe SignedMailValidator qui s’instancie avec en paramètre un MimeMessage. Hors malgré avoir essayé beaucoup de choses pour mettre les briques entre elles, je n’arrive pas à fournir ce MimeMessage signé (signature encapsulée ou détachée) juste après le déchiffrement. Aurais-tu des indications à conseiller ?
Merci de ton attention,
@+