Processus de chiffrement et de déchiffrement

La caractéristique des processus de chiffrement et de déchiffrement de la technologie SHF est qu'ils ne sont pas réalisés par le MUA. Ceci est principalement dû à une limitation IMAP. Le standard IMAP ne permet pas la modification des messages stockés dans les boites aux lettres. Afin de fournir les services de chiffrement et de déchiffrement, nous avons choisi de développer un nouveau composant basé sur la spécification Domain Security [159]. Le composant qui réalise ces processus est appelé Domain Confidentiality Authority (DCA).

La Figure 60 illustre les composants d'architecture et une transmission d'un message qui est signé et chiffré. L'architecture est composée de deux entités ADMD. Les concepts d'ADMD sont décrits dans le chapitre relatif à l'état de l'art. Le MUA émetteur (Sender MUA) exécute le processus de génération de signature et transmet le message signé (S). Le DCA de l'ADMD A reçoit le message S et le chiffre (E). Le DCA de l'ADMD B reçoit le message E, le déchiffre (S) et le transmet au MUA destinataire (Recipient MUA) qui procède à la vérification de la signature.

Figure 60 : Architecture basée sur la technologie SHF

Les processus de chiffrement et de déchiffrement ne peuvent être exécutés que dans le cas où le contenu à chiffrer correspond à un objet signature S/MIME et si la structure SecureHeaderFields est encapsulée dans les attributs signés de la signature. Ces processus utilisent les champs statuts présents dans HeaderFieldStatus. Les trois valeurs de statut sont duplicated, deleted and modified. Le principal intérêt des statuts est qu'il est possible de décrire un comportement particulier par champ d'entête. Header Body signed message unsigned message Body Signature Header 1 2 S ADMD A E Sender MUA DCA S ADMD B DCA Recipient MUA

137 Lors du processus de chiffrement :

 si le statut est duplicated, le champ ne subit aucune transformation.  si le statut est deleted, le DCA retire le champ du message.

 si le statut est modified, le DCA remplace la valeur du champ par une nouvelle valeur. Lors du processus de déchiffrement :

 si le statut est duplicated, le champ ne subit aucune transformation.

 si le statut est deleted, le DCA réécrit le champ (nom et valeur) dans le message à partir du champ présent dans la structure SecureHeaderFields.

 si le statut est modified, le DCA réécrit la valeur du champ présente dans HeaderFieldValue de la structure SecureHeaderFields.

Le processus de chiffrement S/MIME intégrant la technologie SHF est illustré dans la Figure 61. En fonction des statuts, les champs d'entête du message peuvent être protégés (1) et le message est chiffré (2). Avec cette technologie, il est possible de transférer un message à travers un système non sécurisé. Cependant, les mécanismes de chiffrement et de déchiffrement sont optionnels et la technologie SHF peut se limiter à l'application des mécanismes de signature.

Figure 61 : Processus de chiffrement S/MIME avec la technologie SHF

Une mise en œuvre de la technologie SHF a été réalisé dans le client Trustedbird. Ces travaux ont fait l'objet d'une publication [157], fournie en annexe II. Actuellement, une soumission54 auprès de l'IETF, est en cours. Un accord de publication du document avec un statut expérimental a été transmis par l'IETF.

8.7

Découverte et récupération des politiques de

correspondance

Les agents en charge de l'application des politiques de correspondance doivent disposer de celles-ci. Dans le cas contraire, des mécanismes de découverte et de récupération des politiques sont nécessaires. Afin d'être diffusables, les politiques doivent, dans un premier temps, être publiées au sein d'une zone de stockage. Ensuite, il faut mettre en œuvre un mécanisme qui 54 _{https://datatracker.ietf.org/doc/draft-cailleux-secure-headers/} Signature Body signed message Body Signature Header encrypted message Header 1 2

138

permet la découverte des politiques de correspondance pour un domaine donné. Ceci peut être réalisé à partir de services plus ou moins propriétaires. Le service de nom du domaine (au sens DNS) offre un mécanisme d'enregistrement de service et propose une solution de découverte de service décrits dans le RFC 2782 [160]. Nous nous baserons dessus pour récupérer le nom du serveur en charge du stockage des politiques de correspondance.

L'enregistrement de service, également appelé enregistrement SRV, est un type de donnée du DNS qui permet d'indiquer la localisation d'un service. L'objectif est de définir un enregistrement SRV pour le service de diffusion de politiques de correspondance. Celui-ci pourrait prendre la forme suivante :

_correspondence._tcp.example.com. 86400 IN SRV 0 33 9020 server1.example.com. Cet exemple d'enregistrement est composé de :

 _correspondence : nom du service

 _tcp : nom du protocole de transport  example.com. : nom du domaine

 86400 : TTL (Time To Live)  IN : classe, à savoir Internet  SRV : type d'enregistrement DNS

 0 : priorité du serveur cible. Plus elle est faible, plus le serveur pourra être sollicité

 33 : poids relatif pour les enregistrements de même priorité  9020 : port TCP sur lequel le service est disponible

 server1.example.com. : nom du serveur cible qui fournit le service

Figure 62 : Mécanismes de découverte et de récupération de politiques de correspondance

La Figure 62 décrit le scénario de découverte et de récupération des politiques de correspondance. L'enregistrement SRV est publié dans le système DNS par une personne autorisée (1). La politique est publiée dans le serveur de politiques de correspondance par une personne autorisée (2). L'agent du système de messagerie envoie une requête de découverte de service à destination du serveur DNS (3). Le serveur DNS renvoie le nom du serveur de politiques de correspondance. L'agent contacte le serveur pour récupérer la politique (4). Il

Policy server agent Policy publication DNS server 2 Policies 3 4 Policies 1 SRV record publication

139

pourrait récupérer une politique particulière ou bien l'ensemble des politiques. Il est important de noter qu'il n'y a pas de mécanismes permettant de sécuriser ces échanges (contrôle d'accès, sécurisation des politiques...) définis à ce jour. Ces aspects devraient faire l'objet de futurs travaux.