Protection des messages par SMIME

Publié le 23 février 2015 par JoMendes

Comme vous le savez déjà, les opérations cryptographiques sont standardisées afin de permettre une certaine interopérabilité, comme déjà évoquées par exemple ici-même.

Dans le cas particulier des messages électroniques, il y avait au commencement le mail sans aucun mécanisme de protection de l’information, alors l’IETF réunit un groupe d’ingénieur et il en ressortit le mail à confidentialité renforcée (PEM). Et l’IETF vit que cela était bon alors il poursuivit son effort et inventa : le PKCS7 avant d’engendrer la « syntaxe des messages cryptographiques » ou CMS.

Cette syntaxe est utilisée pour signer numériquement, résumer, authentifier ou chiffrer des messages arbitraires. Elle est dérivée de PKCS#7 version 1.5. En particulier, le CMS est utilisé pour la signature et le chiffrement de message électronique de type MIME. Le MIME ainsi étendu pour supporter les messages cryptographiques devient le S/MIME pour Secure MIME.

Notons ici que S/MIME se base sur PKCS7 et donc sur des certificats X.509, cette méthode est bien différente de la protection de message via une clé PGP.

Également, et il faut que cela soit bien pris en compte : les opérations SMIME ne protégent que le corps du mail (et les pièces jointes associées). L’entête du message (et en particulier son sujet) n’est jamais chiffrée ou contrôlée en intégrité

Chiffrement :

Le chiffrement d’un message est réalisé de la façon suivante:   le message est d’abord chiffré par un algorithme symétrique : 3DES par défaut dans beaucoup de client mail (parfois dénommé MUA : Mail User Agent) en témoigne l’extrait du code de ThunderBird ci-dessous

/* Make triple-DES the strong cipher. */
strong_mapi = smime_mapi_by_cipher (SMIME_DES_EDE3_168);

Cela n’est pas incorrect en soi puisque les RFC sur le CMS exigeaient à l’origine que le DES-EDE3 soit supporté et elles n’ont pas évoluées depuis quelque temps (la dernière que nous avons trouvée date de 2009). L’usage du Triple DES est simplement dépassé en terme de sécurité. Même si le problème de la gestion des nouveaux algorithmes n’est pas nouveau pour Thunderbird, en témoigne ce « bug » ouvert depuis 2003.

Cependant restons de bonne foi, le texte des RFC est passé d’un très péremptoir « CMS implementations must include Triple-DES in CBC mode. » courant 1999 à un plus souple  « The Content encryptionAlgorithmIdentifier type identifies a content-encryption algorithm.  Examples include Triple-DES and RC2. » dix ans plus tard

Précisons également que si vous avez un certificat avec une clé ECDSA, supposition est alors faite que votre client mail supporte AES-128-CBC. Et cet algorithme sera choisi par défaut pour chiffrer vos messages, conformément à la RFC 5753.

Une fois le message chiffré, il faut transmettre la clé à chacun des destinataires, en la chiffrant avec leur clé publique respective : le résultat de chaque chiffrement est regroupé en tête de message avec le RecipientInfo : généralement à base du couple {Numéro de série,DN de l’émetteur} du certificat.

L’enchainement peut s’illustrer alors de la sorte :

Schema_Chiffrement_SMIMEAinsi les différents blocs s’agencent de la sorte :

SMIME_EnveloppedLorsque vous recevez un message chiffré, votre client mail recherche dans votre magasin de certificat personnel, puis parse le mail chiffré pour y retrouver un couple {DN de l’émetteur du certificat, Numéro de série du certificat} d’un certificat dont vous possédez la clé privée afin de déchiffrer le message.

Dans le cas où aucun certificat n’est pas trouvé, votre client mail se fendra d’un petit message du style :

pasdecert

Message sous MS OutLook 2010

L’usage du Triple-DES n’est pas une fatalité en soit. En effet grâce aux SMIMECapabilities un MUA est en mesure d’annoncer les algorithmes de chiffrement symétrique qu’il supporte et souhaite voir utiliser dans les prochains messages. Il y a deux bémols à cela :

Le premier point (noir) est que l’expression de ces desiderata se fait à l’aide de l’attribut SMIMECapabilities. Et cet attribut n’est présent que dans les signatures électroniques. Autrement dit pour envoyer un mail chiffré décemment il faut d’abord envoyer un message signé. Voilà un usage assez insoupçonné de la signature de mail.

Reste à savoir comment l’utilisateur peut hiérarchiser, lui-même ces préférences : Thunderbird ne permet pas (encore) de le faire, mais Outlook intégre cette gestion directement dans son interface.

Ci dessous, un exemple de SMIMECapabilities en ASN.1 demandant en priorité l’usage du chiffrement en AES-128 et du condensat SHA384.

     SEQUENCE {
       OBJECT IDENTIFIER
         sMIMECapabilities (1 2 840 113549 1 9 15)
       SET {
         SEQUENCE {
           SEQUENCE {
             OBJECT IDENTIFIER
               aes128-CBC (2 16 840 1 101 3 4 1 2)
             }
           SEQUENCE {
             OBJECT IDENTIFIER
               aes256-CBC (2 16 840 1 101 3 4 1 42)
             }
           SEQUENCE {
             OBJECT IDENTIFIER
               aes192-CBC (2 16 840 1 101 3 4 1 22)
             }
           SEQUENCE {
             OBJECT IDENTIFIER
               des-EDE3-CBC (1 2 840 113549 3 7)
             }
           SEQUENCE {
             OBJECT IDENTIFIER rc2CBC (1 2 840 113549 3 2)
             INTEGER 128
             }
           SEQUENCE {
             OBJECT IDENTIFIER rc2CBC (1 2 840 113549 3 2)
             INTEGER 64
             }
           SEQUENCE {
             OBJECT IDENTIFIER
               sha-384 (2 16 840 1 101 3 4 2 2)
             }
           SEQUENCE {
             OBJECT IDENTIFIER
               sha-512 (2 16 840 1 101 3 4 2 3)
             }
           SEQUENCE {
             OBJECT IDENTIFIER
               sha-256 (2 16 840 1 101 3 4 2 1)
             }
           SEQUENCE {
             OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
             }
           }
         }
       }

Deuxièmement, la prise en compte de ces « souhaits » reste à la discrétion du MUA d’en face. Ce point n’est pas à négliger. Prenons ici encore l’exemple de Thunderbird.

Nous avons effectué les tests suivants entre un Thunderbird 31.4.0 sous Ubuntu 14.04 LTS et un Outlook 2013 sous windows 7 SP1.

De Thunderbird vers OutLook, message chiffré 1,               Algo : DES_EDE3_CBC
De OutLook        vers Thunderbird, message chiffré 2,        Algo : DES_EDE3_CBC
De Thunderbird vers OutLook, réponse chiffré 2,                Algo : DES_EDE3_CBC
De OutLook        vers Thunderbird, réponse chiffré 1,        Algo : DES_EDE3_CBC

Jusque là tout va bien : Pas de message signé donc pas de SMIMECapabilities donc on garde le Triple-DES.

De TB vers OL, message signé 1,      Algo : RSA/SHA1,
De OL vers TB, réponse en chiffré,  Algo : AES256_CBC
De TB vers OL, réponse en chiffré,  Algo : DES_EDE3_CBC

Ici on voit qu’OutLook, en réponse à un message signé reçu, chiffre en AES256_CBC (chiffre demandé par Thunderbird).

De OL vers TB, message signé 2,      Algo : RSA/SHA384
De TB vers OL, réponse en chiffré,  Algo : DES_EDE3_CBC,
De OL vers TB, réponse en chiffré,  Algo : DES_EDE3_CBC
De TB vers OL, réponse en  signé/chiffré,  Algo : RSA/SHA1-DES_EDE3_CBC
De OL vers TB, réponse en chiffré,  Algo : AES256_CBC
De TB vers OL, réponse en chiffré,  Algo : DES_EDE3_CBC

Là, on se rend compte que Thunderbird ne tient pas compte de demandes d’OutLook et continue d’utiliser systématiquement le Triple-DES.

Enfin, précisons bien que les SMIMECapabilities ne sont pris en compte que dans la réponse à un mail signé. Autrement dit, elles ne sont pas persistantes dans l’environnement de messagerie (ie si vous écrivez un nouveau mail au même destinataire, le 3DES redevient le défaut.).

Voilà donc une bonne raison de signer tous ses messages.

Signature :

Alors que Windows vient de sortir une préversion de son nouvel OS pour téléphone mobile, nous allons en autre illustrer grâce à Windows Phone 7 la différence entre une signature « enveloppée » et « attachée ». En effet, en fonction du type de signature, le comportement de votre « bon » vieux WP7 varie. La preuve en image ci-dessous.

signed_messagesAfin de comprendre le pourquoi du comment, il nous faut revenir aux fondamentaux. La signature permet de garantir l’intégrité et l’authenticité d’un message.

Généralement, la signature d’un message prend en compte deux paramètres :

– Le hash du corps du message
– La date de la signature

Cet ensemble de donnée est alors « chiffré » avec la clé privée du signataire et regroupé avec tout plein d’autres informations dont l’identité du signataire (toujours le couple {DN de l’émetteur du certificat, Numéro de série du certificat}). Cependant, a contrario du message chiffré qui remplace totalement le message en clair, la signature doit être rajoutée à ce dernier.

SMIME_sign

Il y a là deux alternatives (qui en autre expliquent le comportement du Windows Phone 7).

  • Dans le cas d’une signature dite « attachée », la structure représentant la signature est une simple pièce jointe au sens MIME contenant toutes les informations relatives à la signature et à sa vérification. Ainsi en ignorant cette pièce jointe, le message peut être lu sans analyseur syntaxique particulier, d’où le comportement du Windows Phone 7. Il est d’ailleurs intéressant de voir que si vous ajoutez une pièce jointe à une message signée, celle-ci n’apparait pas dans le MUA du téléphone.
Date: Mon, 16 Feb 2015 05:13:05 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
Subject: Test sign
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070002090205030408030000"

This is a cryptographically signed message in MIME format.

--------------ms070002090205030408030000
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le Corps de mon message signé

--------------ms070002090205030408030000
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDUDCC
[...]
Aj80Hugwc2r3kgV9tU2vvatpwR+nOSJ6J5Vb7wgAAAAAAAA=
--------------ms070002090205030408030000--
  • A contrario, dans le cas d’une signature dite « enveloppée », la structure représentant la signature englobe complétement le message à signer à la façon d’une enveloppe pour les messages chiffrés. Pour pouvoir lire le message, le MUA doit savoir interpréter un message SMIME.
Mon, 23 Feb 2015 14:26:16 +0100
Subject: =?iso-8859-1?Q?Test_sign=E9?=
Date: Mon, 23 Feb 2015 13:26:15 +0000
Content-Type: application/pkcs7-mime; smime-type=signed-data;
	name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Transfer-Encoding: base64
MIME-Version: 1.0

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgIFADCABgkqhkiG9w0BBwGggCSABIIE
[...]
59WobSmRJurFXAAAAAAAAA==

Quid des messages à la fois chiffrés et signés

Il est possible de combiner le chiffrement et la signature. Dans ce cas, la question de savoir comment sont traités ces 2 opérations se pose. Il y a priori 3 scenario possibles :

  •  Le message est d’abord chiffré puis le résultat est signé : Chiffré Signé
  • Le message est d’abord signé puis le résultat est chiffré : Signé Chiffré
  • Le message est chiffré puis le message est signé : la signature du clair est alors ajoutée au message chiffré.

De ces 3 alternatives, seules les 2 premières sont intéressantes et peuvent avoir des applications intéressantes.

– Le chiffré signé peut être utile à la façon des protections IPSec en ESPv2 : l’intégrité du message est d’abord vérifiée avant de tenter tout déchiffrement (afin d’éviter tout gaspillage de CPU). Dans un cas, plus spécifique aux courriers électroniques, nous pouvons assez facilement imaginer le cas d’une passerelle ne voulant remettre que des messages de confiance à ces utilisateurs finaux : la vérification doit donc avoir lieu avant le déchiffrement.

– Le signé chiffré présente lui l’avantage d’avoir une protection de l’intégrité au plus proche de la source. En effet, avant de falsifier une signature, l’attaquant doit casser le chiffrement. Et si on compare au cas précédent, il est moins probable (au sens mathématiques du terme) de forger la signature d’un message en clair que celle d’un message chiffré où l’on peut jouer sur les vecteurs d’initialisation et clé de chiffrement.

Une réflexion assez complète sur ce débat peut être trouvée  ici.

Une alternative pour ne pas avoir à se poser la question est donc de faire ce qu’on appelle du « Triple Wrap » : En résumé, on signe le message en claire puis on chiffre le message signé et on resigne le tout avec éventuellement un autre signataire que le premier utilisé.

Malheureusement en pratique, seul le signé-chiffré est implémenté dans les clients de messagerie gérant le SMIME (à l’exception du défunt Milimail).

Moralité de l’histoire : Pour une meilleur sécurité du chiffrement, signons nos messages !

A propos JoMendes

Amateur de mathématiques et d'hexadécimal. Je m'intéresse de près ou de loin suivant mon niveau à tous les sujets de sécurité de l'information.
Cet article, publié dans Cryptographie Symétrique, Outils, est tagué , , . Ajoutez ce permalien à vos favoris.

3 commentaires pour Protection des messages par SMIME

  1. Ping : Outils, services, sites à (re)découvrir 2015 S09 | La Mare du Gof

  2. Ping : Certificat pour authentifier ou chiffrer | Cryptobourrin

  3. Ping : Compression et chiffrement | Cryptobourrin

Laisser un commentaire