Politique RGS basée sur un profil de signature cryptographique

cryptographique

Ce premier exemple de politique de correspondance est basé sur un profil particulier de signature cryptographique. Comme cela a été abordé dans l'état de l'art, le processus de génération d'une signature électronique met en œuvre deux principaux mécanismes cryptographiques :

- le hachage des données à sécuriser produisant un condensat - le chiffrement du condensat avec la clé privée du signataire

La signature cryptographique est accompagnée d'un profil de dimensionnement cryptographique qui consiste à décrire le type d'algorithme de hachage, l'algorithme de signature... En général, afin de garantir une interopérabilité avec le plus grand nombre de clients, le profil intègre des algorithmes toujours en vigueur mais relativement faibles. Dans l'exemple présent, nous baserons la politique de correspondance sur le RGS49_{. Le RGS [5] a pour objectif}

de définir les règles applicables aux échanges entre les usagers et les autorités administratives et entre les autorités administratives. Ce référentiel fixe, selon le niveau de sécurité requis, les règles que doivent respecter certaines fonctions contribuant à la sécurité des informations, parmi lesquelles la signature électronique, l'authentification, la confidentialité ou encore l'horodatage. Le RGS est publié par l'ANSSI 50.

49 _{Le Référentiel général de sécurité (RGS) est créé par l’article 9 de l’ordonnance n° 2005-1516 du 8 décembre 2005 relative aux}

échanges électroniques entre les usagers et les autorités administratives et entre les autorités administratives. Ses conditions d’élaboration, d’approbation, de modification et de publication sont fixées par le décret n° 2010-112 du 2 février 2010 pris pour l’application des articles 9, 10 et 12 de l’ordonnance citée relatif à la sécurité des informations échangées par voie électronique.

111

L'application du RGS dans un système de messagerie électronique permettrait de respecter les exigences liées aux mécanismes cryptographiques. Il serait ainsi possible, d'imposer des algorithmes particuliers pour les mécanismes de signature et/ou de chiffrement. Le RGS, dans son annexe B1 [151], recommande entre autres, l'utilisation de l'algorithme de hachage SHA- 256[152]. Il devient intéressant de décrire dans une politique de correspondance, certaines exigences du RGS. L'exemple proposé dans ce chapitre décrit une politique comportant le type de signature et l'algorithme de hachage à utiliser. Cet exemple ne reprend pas toutes les exigences du RGS. Cependant, la description d'une politique intégrant d'autres exigences du RGS est possible.

Figure 41 : périmètre d'application de la politique de correspondance du RGS

Dans cet exemple, la politique de correspondance décrit des règles qui ne s'appliquent que sur le message. Deux évènements sont concernés par l'application de la politique de correspondance du RGS. Le périmètre est illustré dans la Figure 41. Pour l'évènement de création du message, la politique comporte une partie transformation qui décrit l'algorithme cryptographique à mettre en œuvre lors de la génération de la signature. Pour l'évènement d'affichage du message, la politique comporte une partie verification décrivant l'algorithme cryptographique imposé. Cette politique est appliquée dans les composants aMUA (MUA émetteur) et rMUA (MUA destinataire), ceci revient à appliquer une politique de correspondance de bout en bout.

La politique de correspondance du RGS peut être exprimée de la manière suivante. Soit la correspondance composée de deux politiques de correspondance évènementielles pour les évènements creation et display.

= { , }

Une description des politiques évènementielles est réalisée en XML. La première description proposée ici comporte les règles à appliquer lors de l'évènement de création du message exécuté dans le aMUA.

1 <CORRESPONDENCE_POLICY name="RGS" version = "1.0" domain="example.org"> 2 <EVENT eventId="CREATION">

3 <POLICY_TARGET policyTargetId ="MESSAGE">

Creation InitTransfer FinalTransfer Submission Retrieving Display Delivery Evènements appliquant la politique du RGS

112

4 < POLICY_TYPE policyType="TRANSFORMATION"> 5 <RULE ruleId ="g1">

6 <ACTION> addCryptographicSignature 7 <PARAMETERS>

8 <PARAMETER name="description" > add a cryptographic signature </PARAMETER> 9 <PARAMETER name="mechanism" > SMIME </PARAMETER>

10 <PARAMETER name="digestAlgorithm" > SHA-256 </PARAMETER> 11 </PARAMETERS> 12 </ACTION> 13 </RULE> 14 <POLICY_TYPE> 15 < POLICY_TARGET > </EVENT> </CORRESPONDENCE_POLICY>

Cette politique peut être interprétée de la manière suivante :

- la ligne 1 comporte la référence de politique de correspondance, à savoir la composition de

name, version et domain.

- la ligne 2 comporte l'évènement concerné (CREATION)

- la ligne 3 comporte la cible sur laquelle la politique sera appliquée, à savoir le message. - la ligne 4 comporte le nom du type de politique, à savoir TRANSFORMATION. - la ligne 5 comporte l'identifiant de la règle.

- la ligne 6 comporte l'opération à exécuter (ajout d'une signature cryptographique). - la ligne 8 comporte une description de l'opération.

- la ligne 9 comporte le nom du protocole de signature électronique à utiliser. - la ligne 10 comporte l'algorithme de hachage à utiliser.

L'exécution de cette politique va permettre d'ajouter une signature cryptographique basée sur un profil particulier.

La description proposée ci-dessous correspond aux opérations à exécuter lors de l'évènement d'affichage du message réalisé dans le rMUA.

1 <CORRESPONDENCE_POLICY name="RGS" version = "1.0" domain="example.org"> 2 <EVENT eventId="DISPLAY">

3 <POLICY_TARGET policyTargetId ="MESSAGE"> 4 < POLICY_TYPE policyType="VERIFICATION"> 5 <RULE ruleId ="v1">

6 <ACTION> checkCryptographicSignature 7 <PARAMETERS>

8 <PARAMETER name="description" > check a cryptographic signature </PARAMETER> 9 <PARAMETER name="mechanism" > SMIME </PARAMETER>

10 <PARAMETER name="digestAlgorithm" > SHA-256 </PARAMETER> 11 </PARAMETERS> 12 </ACTION> 13 </RULE> 14 <POLICY_TYPE> 15 < POLICY_TARGET > </EVENT> </CORRESPONDENCE_POLICY>

Cette politique peut être interprétée de la manière suivante :

- la ligne 1 comporte la référence de politique de correspondance, à savoir la composition de

name, version et domain.

113

- la ligne 3 comporte la cible sur laquelle la politique sera appliquée, à savoir le message. - la ligne 4 comporte le nom du type de politique, à savoir VERIFICATION.

- la ligne 5 comporte l'identifiant de la règle.

- la ligne 6 comporte l'opération à exécuter (vérification d'une signature cryptographique). - la ligne 8 comporte une description de l'opération.

- la ligne 9 comporte le nom du standard de signature électronique utilisé. - la ligne 10 comporte l'algorithme de hachage utilisé.

L'application de cette politique va permettre de vérifier qu'une signature est valide et qu'elle respecte un profil particulier de signature cryptographique.

La politique évènementielle DISPLAY revient à vérifier ce qui a été appliqué dans la politique évènementielle CREATION. L'utilisation de ces deux politiques de correspondance permet aux utilisateurs de s'assurer que les messages échangés appliquent la politique de correspondance du RGS.