SEPAmail : utilisation des protocoles de l'internet SMTP, SMIME, HTTP, REST, SOAP, IP, DNS...

Le protocole SEPAmail peut se définir comme un ensemble de règles permettant de mettre en oeuvre une messagerie entre un expéditeur et un destinataire (appelés les utilisateurs de SEPAmail) via des relais (appelés adhérents du réseau privé SEPAmail).

Ces relais  sont des fournisseurs d'accès au réseau SEPAmail pour le compte de leurs clients.
Le rôle de ces relais est :

• de relayer les messages de leur client sur le réseau SEPAmail
• d'authentifier leurs clients quand ils émettent ou reçoivent un message SEPAmail
• d'accuser réception des messages au nom de leur client destinataire

Pour réaliser ces fonctions en se servant d'un réseau de transport public comme internet, le protocole SEPAmail met en œuvre trois couches d'abstraction :

• une enveloppe SEPAmail, qui, dans l'état de l'art du moment, est une enveloppe SMTP/S-MIME
• une missive SEPAmail qui, pour le moment, est un flux xml contenant un entête et un corps
• un message SEPAmail qui, pour le moment, est un flux xml dérivé d'un gabarit de message générique à entête et corps.

Cette double encapsulation au sein d'une messagerie à relais permet de sécuriser la messagerie et de faire transiter des messages sur le réseau public internet d'un expéditeur à un destinataire avec un bon niveau de confiance, de confidentialité, d'intégrité.

Il existe deux façons de faire transiter les enveloppes SEPAmail:

• le mode canonique qui est pour le moment un échange SMTP dans l'état de l'art
• le mode flash, voulu par les premiers adhérents qui est, pour le moment, un échange web-services de serveur à serveur à l'aide du protocole SOAP sur HTTP(S) ou REST sur HTTP(S)

On peut donc schématiser l'utilisation des couches protocolaires par le schéma suivant:

Les couches utilisées par le protocole SEPAmail

Nous retrouvons dans la colonne de gauche les couches du modèle TCP/IP, puis les couches du protocole SEPAmail et enfin les protocoles standards utilisés:

• S-MIME au sein de SMTP pour la couche enveloppe
• un échange SMTP pour l'échange SEPAMail en mode canonique (le plus naturel et le moins couteux)
• un échange SOAP sur HTTP pour l'échange SEPAmail en mode flash tel qu'implémenté pour l'expérimentation (le plus couteux et pas très naturel sauf à implémenter SEPAmail au sein d'une prise SOAP plus générale)
• un échange REST sur HTTP pour l'échange SEPAmail en mode flash et sobre (rapide, moins couteux que SOAP, naturel car SEPAmail permet d'échanger une ressource enveloppe SEPAmail)
• TCP comme couche transport quand il est mis en oeuvre sur le réseau à bas coût internet
• IP et DNS pour la couche réseau

A la lecture de ce schéma, nous voyons que SEPAmail est un protocole en couches utilisant des standards du web. SEPAmail écrit que cette utilisation doit être réalisée dans l'état de l'art, ce qui, signifie, par exemple :

• pour la couche HTTP, l'utilisation de la version 1.1 pour les possibilités de négociation de contenu et de connexion persistante,
• pour la couche S-MIME, l'utilisation de sha256 au minimum à la place de sha1 selon les recommandations récentes.

Les règles de l'état de l'art pour les protocoles utilisés par SEPAmail sont, si besoin, précisées dans des règles opérationnelles issus des travaux des adhérents SEPAmail et partagés entre eux.
Ces règles opérationnelles précisent également les restrictions de l'utilisation de certains protocoles en expliquant dans la mesure du possible les raisons afin qu'une règle ne soit pas appliquée indéfiniment si la raison a disparu.

Le standard SEPAmail n'explique donc, ni l'état de l'art des couches utilisées, ni l'utilisation de ces couches.

Prenons un exemple pour bien comprendre ce que cela peut signifier pour celui qui implémente SEPAmail au sein d'un logiciel.

Supposons que l'adhérent de l'expéditeur d'un message envoie une enveloppe SEPAmail en mode canonique avec un algorithme cryptographique non supporté par le système récepteur de l'adhérent du destinataire, alors, il est normal que ce système récepteur réponde un code de type 476 ou 576 (Cryptographic algorithm not supported) sur la couche SMTP, conformément à la RFC 3463.

Si maintenant cette même enveloppe est conforme du point de vue SMIME avec un algorithme supporté par S-MIME et l'agent smtp (MTA) mais que l'enveloppe SEPAmail utilise un algorithme non permis par le protocole SEPAmail, une bonne façon de répondre est de répondre sur la couche SEPAmail, c'est à dire d'envoyer une missive d'acquittement avec un statut NAK et un code retour 573 (Unsupported algorithm or security function ), conformément au fonctionnement proposé par la SMIRK MIS 1202.


Le principe général est ainsi, comme le veut l'usage avec les protocoles internet, de répondre sur la bonne couche des erreurs de la couche et de ne répondre sur la couche SEPAmail que pour ce qui concerne le protocole SEPAmail.

Il est important de noter que le transport d'une enveloppe SEPAmail doit s'imaginer en premier lieu par le mode canonique, c'est à dire via le protocole d'échange SMTP, puisque c'est le mode naturel de la messagerie SEPAmail.
Le mode flash doit être implémenté de façon cohérente au mode canonique, que ce soit via SOAP ou REST, sujet qui fera peut-être l'objet d'un billet.

Le dispositif SEPAmail au cœur d'une architecture de messagerie

Le dispositif SEPAmail au cœur d'une architecture de messagerie

L'architecture schématisée ci-dessus s'articule autour du mode canonique :

• un composant recevant et envoyant les courriels (MTA)
• un composant chiffrant et déchiffrant, relié à un composant d'authentification et une infrastructure à clé publique (PKI)
• un composant SMART mettant en œuvre le protocole SEPAmail autour de la missive (décrit dans le document SMIRK MIS1101, remplacé par SMIRK MIS1202 fin juillet 2012)

La liaison avec le système d'information se fait par le SMART.
La liaison avec le reste du monde via des équipements de protection, type pare-feu.

Le mode flash est sobre et ne s'occupe que d'interfacer entre le reste du monde et le composant MTA une chaîne de type web-service.

Charge à la chaîne canonique de savoir traiter en priorité les flux reçu ou émis en mode flash.

Des liaisons facultatives sont à prévoir entre le SMART et :

• un module d'horodatage externe et certifié si besoin
• un module de contrôle de type juridique si besoin

 

L'information échangée de composants à composants

Dans cette architecture, l'information échangée est, tout au long de la chaîne :

• une enveloppe SEPAmail, c'est à dire une enveloppe SMTP
• SMIME entre le composant crypto et le reste du monde (composant MTA compris)
• SMTP déchiffrée entre le composant crypto et le SMART
• Et entre le SI et le SMART :
• une missive SEPAmail, c'est à dire un flux xml au standard missive de SEPAmail.

L'enveloppe SEPAmail et la missive SEPAmail sont des blocs d'information dotés d'un entête.
On peut donc passer les arguments au sein de ces entêtes.

Le bloc d'information est ainsi porteur de toute l'information utile et il n'y a pas d'API compliqué à prévoir entre ces composants autres que la spécification des entêtes et leur utilisation au sein du Système d'information cible des spécifications d'intégration de SEPAmail.

Quelques éléments de sécurité

Le composant SMART et le composant CRYPTO sont certainement à protéger au sein d'un segment de réseau spécifique à SEPAmail.

Cette organisation ne remet pas en questions les règles de sécurité autour du composant MTA, notamment son emplacement et le filtrage associé au flux SMTP.
Si un responsable de la sécurité du système d'information cible désire associer des règles spécifiques au flux SEPAmail, il pourra le réaliser sans souci sur l'adresse de courriel qui est spécifique :

• nom de domaine sepamail.eu, 
• sous-domaine pouvant être authentifié en DKIM et soumis à des règles SPF, 
• adresses de courriel définies et spécifiques à SEPAmail

Le mode flash est associé au mode canonique et la sécurité spécifique du transactionnel à temps court peut ainsi reposer sur quelques règles communes.

Des anti-virus peuvent être habilement utilisés à plusieurs endroits et notamment sur le flux chiffré avec le reste du flux SMTP en entrée de SI puis après (et avant) le déchiffrement.

Le cœur du système d'information n'est exposé qu'à un flux xml filtré, authentifié (signature), intègre (signature), valide (schéma xml) et vérifié (anti-virus).

L'exploitation du dispositif

Le dispositif décrit peut être exploité de la façon habituelle pour l'entreprise, charge à l'intégrateur de la solution d'ajouter les prises (ou sondes) entre les nouveaux composants et le composant d'exploitation pour alerte d'une défaillance opérationnelle.

Les fonctions du composant SMART

Que fait donc le SMART dans cette configuration ?

Il implémente les fonctions non encore réalisées autour de la missive :

• gestion du flux de travaux (workflow) en émission de missive nominale, incluant :
• l'attente de l'acquittement
• le renvoi éventuel de la missive
• l'escalade si la missive n'est pas acquittée dans les temps prévus
• gestion de l'acquittement en réception de missive nominale
• directement si c'est possible
• en délégation de l'application métier cible du message sinon
• dépôt des missives en direction des applications métiers
• récupération des missives provenant des applications métiers
• pilotage des commandes autour de la missive

Ceci est décrit plus spécifiquement ici dans le document SMIRK MIS1101 remplacé par SMIRK MIS1202 fin juillet 2012.

Pourquoi SEPAmail utilise le protocole S/MIME ?

SEPAmail utilise pour l'échange d'information

• la cryptographie à clé publique pour l'authentification, la confidentialité et le contrôle d'intégrité
• le protocole SMTP et ses extensions pour la structuration d'une enveloppe et son contenu
• S-MIME pour l'encapsulation des éléments cryptographiques au sein de l'enveloppe SMTP, en tant que contenu MIME sécurisé

Les principaux intérêts de ces protocoles sont :

• leur utilisation répandue (standard)
• leur évolutivité (à chaque fois qu'une anomalie ou une faille est détecté)
• la séparation en couche à fonction unique

Ils sont tous les trois préconisés par l'adminitration française dans le référentiel général d'interopérabilité (RGI).

S-MIME permet de fixer un cadre cryptographique désynchronisé sans envoi de challenge au préalable, ce qui simplifie beaucoup la compréhension du cadre de l'échange et permet un échange par relais, ce qui n'est pas possible avec d'autres protocoles "dits" connectés ou temps réel.

S-MIME est largement utilisé et largement attaqué. Il évolue rapidement et, pour le moment, permet des niveaux de sécurité très importants, largement supérieurs à ceux nécessaires dans le cas du dispositif SEPAmail.
S-MIME permet de nombreuses possibilités concernant la façon de stocker, de chiffrer ou d'authentifier l'information. Certaines des combinaisons sont assez exotiques et ne sont pas prises en charge par les clients de messagerie.
Cependant, la plupart des formes classiques S-MIME, notamment le chiffrement d'un contenu préalablement signé, sont prises en charge par défaut dans les clients de messagerie usuels.

Il est donc possible, grâce au choix de ces standards, de générer, transporter et lire des informations SEPAmail nativement avec les infrastructures existantes de messagerie électronique.