Cryptographic Message Syntax

CMS (Cryptographic Message Syntax), définie dans le RFC 5652 [78], est une syntaxe d'encapsulation pour la protection de données. Avec CMS, un objet contenant des données peut être encapsulé dans un autre, afin d'appliquer sur ce dernier des mécanismes cryptographique. CMS est transport-agnostique [75]. De la même manière que PKCS#7, sur lequel elle est basée, CMS n'avait pas pour objectif initial d'être dédiée à la sécurisation des messages. Avec CMS, il est par exemple possible de sécuriser un fichier sur un disque dur. CMS supporte les mécanismes de signature électronique et de chiffrement. L'objet CMS est généré en utilisant ASN.128 _{et l'encodage BER}29_{. CMS ne vérifie pas si les données à sécuriser sont au}

format binaire. Le protocole S/MIME applique un encodage et un formatage MIME, afin de permettre le transport d'un objet CMS. CMS spécifie également les conventions d''usage de différents algorithmes cryptographiques [79].

CMS propose la protection d'un contenu qui est identifié par le type de contenu ContentInfo. Ce type de contenu peut encapsuler d'autres contenus. Un type de contenu ContentInfo est identifié par un oid (object identifier). CMS défini six types de contenu qui peuvent être encapsulés :

 data,  digested-data,  encrypted-data,  authenticated-data,  signed-data,  enveloped-data,

Le type de contenu data est utilisé pour faire référence à des données au format ASCII, comme un fichier texte par exemple.

Le type de contenu digested-data consiste en un contenu libre et un condensé du contenu. Ce type de contenu est principalement utilisé pour garantir l'intégrité

Le type de contenu encrypted-data consiste en un contenu libre chiffré. Ce type de contenu n'est associé à aucun destinataire et ne dispose pas de clés de chiffrement de contenu (contrairement au type de contenu enveloped-data). Ce type de contenu est utilisé pour chiffrer un contenu pour un stockage local avec par exemple une clé de déchiffrement dérivée d'un mot de passe.

28 _{Abstract Syntax Notation 1 est une syntaxe et une notation qui décrit les règles et les structures pour représenter, encoder,}

transmettre et décoder des données. ASN.1 est un standard joint ITU-T, ISO et IEC. ASN.1 est défini dans les standards X.680, X.681, X.682 et X.683 de l'ITU-T.

29 _{Le codage BER (Basic Encoding Rules) est un des formats d'encodage définie par le standard ASN.1. BER est défini dans le}

59

Le type de contenu authenticated-data consiste en un contenu libre, un code d'authentification de message (MAC - message authentication code) et des clés d'authentification chiffrées pour un ou plusieurs destinataires. Ce principe permet de protéger en intégrité, tout type de contenu pour un nombre arbitraire de destinataires.

Les deux principaux types de contenu utilisés dans les systèmes de messagerie sécurisée sont

signedData et envelopedData. Dans la suite de ce document, nous décrirons ces deux types en

détail.

Le type signedData permet de transporter n'importe quel type de contenu et une à plusieurs valeurs de signature. Plusieurs signataires peuvent signer en parallèle le contenu. Cependant, l'application typique d'un type signedData est une seule signature numérique d'un signataire qui s'applique sur le contenu. Le principe est basé sur le mécanisme de signature numérique décrit précédemment. Cependant, CMS a quelques particularités. Il autorise l'ajout d'attributs spécifiques (jeton d'horodatage, contre signature...) qui seront associés avec la signature et protégés de la même manière que le message.

Un objet de type signedData transporte différentes informations (cf. Figure 12) :

 la version de la syntaxe (version),

 une collection d'identifiants d'algorithmes de hachage (digestAlgorithms) utilisés par tous les signataires,

 le contenu signé (encapContentInfo),

 une collection de certificats (certificates) permettant de vérifier le chemin de certification de tous les signataires,

 une collection de listes de révocation (crls) permettant de vérifier que tous les certificats présents sont valides,

 une collection SignerInfos qui contient les informations pour chaque signataire.

Figure 12 : Description de la structure SignedData de l'objet CMS

Le type de contenu signedData est décrit en ASN.1 dans le RFC 5652 [78]. SignerInfos est une collection de SignerInfo. Il y a autant d'objets SignerInfo que de signataires. Un objet de type

SignerInfo transporte différentes informations (cf. Figure 13) :

 la version de la syntaxe (version),

 l'identifiant du certificat du signataire (signerID) nécessaire pour la vérification de la signature par le destinataire,

 l'identifiant de l'algorithme de hachage (digestAlgorithm) utilisé,  une collection d'attributs qui seront signés (signedAttrs),

 l'identifiant de l'algorithme de signature (signatureAlgorithm) utilisée,

 la signature qui correspond au résultat du processus de génération de la signature et dépend de l'algorithme employé (signature),

DigestAlgorithms SignedData

Version DigestAlgorithms_{DigestAlgorithms}

DigestAlgorithms DigestAlgorithmsCertificates ContentInfo

DigestAlgorithms

60

 une collection d'attributs qui ne seront pas signés (unsignedAttrs).

Figure 13 : Description de la structure SignerInfo de l'objet CMS

Les collections signedAttrs et unsignedAttrs permettent de transporter des attributs avec la signature. La structure d'un message S/MIME comportant un objet CMS de type SignedData est illustrée dans la Figure 14.

Figure 14 : structure d'un message S/MIME avec un type de contenu SignedData

Le type envelopedData consiste en un contenu chiffré et un ensemble de clés de chiffrement, elles même chiffrées en fonction du nombre de destinataires du message. Ce type permet le support du chiffrement d'un contenu d'un émetteur vers plusieurs destinataires. N'importe quel type de contenu peut être chiffré. Un objet de type envelopedData comporte différentes informations (cf. Figure 15):

 la version de la syntaxe (version),

 des informations concernant l'émetteur (originatorInfo) comme des certificats,  une collection d'informations (recipientInfos)pour chaque destinataire,

 le contenu chiffré (encryptedContentInfo),

 une collection d'attributs (unprotectedAttrs) qui ne seront pas sécurisés mais seront transportés avec l'objet CMS.

Figure 15 : Description de la structure envelopedData de l'objet CMS

La structure d'un message S/MIME comportant un objet CMS de type EnvelopedData est illustrée dans la Figure 16.

SignerInfo version signer ID DigestAlgorithms DigestAlgorithmssignedAttrs digestAlgorithm signatureAlgorithm DigestAlgorithms DigestAlgorithmsunsignedAttrs signature Unsigned message Header Body Signed message Header Body Signature SignedData CMS object EnvelopedData

version originatorInfo encryptedContentInfo

DigestAlgorithms DigestAlgorithmsrecipientInfos

DigestAlgorithms DigestAlgorithms unprotectedAttrs

61

Figure 16 : Structure d'un message S/MIME avec un type de contenu EnvelopedData