Communauté SEPAmail : SMOC

SMOC, c'est quoi ?

SMOC est l'acronyme de SepaMail Output Cryptographic, ce qui pourrait signifier Sortie chiffrée d'un SEPAmail.

C'est un composant open source en licence GPLv3 développé par Bishan Kumar Madhoo, société idSoft, selon une spécification réalisée par moi pour le compte du cabinet deciBI.

Qu'est-ce que cela fait ?

SMOC est un composant :

• qui prend en entrée une missive SEPAmail et un fichier de configuration
• qui génère une enveloppe SEPAmail, l'envoie en mode canonique (SMTP) et se synchronise avec une répertoire d'un compte imap corresponsdant au compte de l'expéditeur

C'est une librairie java que l'on peut inclure dans un projet java ou utiliser en ligne de commande.

Où peut-on le trouver ?

SMOC a été publié sur la plateforme de code google, sous le nom de code sepamail-smoc.
La page du projet se trouve ici
Le code source du projet est ici.

A-t-on le droit de l'utiliser ?

Le logiciel a été développé en langage java sous une licence d'utilisation open source (GPLv3).
Il utilise des composants et des bibliothèques qui sont toutes sous une licence open source.

Tout le monde peut donc utiliser tout ou partie de SMOC sous les conditions des licences d'utilisation, notamment en respectant le droit des auteurs.

Ce composant fait-il partie du standard de SEPAmail ?

Le standard n'a pas vocation à inclure des implémentations logicielles.
Donc ce composant ne fait pas partie du standard.

Existent-t-ils d'autres composants comme SMOC ?

Oui.

• SMURF est un composant permettant de publiposter des missives SEPAmail depuis un système d'information d'entreprise.
• SMIC est un composant de conversion croisée entre les deux formats missive (xml) et pdf (guide du créancier).
• SMAC est un composant croisé entre le mode canonique et les modes flash
• SMACK est un composant d'acquittement automatique de missive nominale
• SMETH est une extension du client de messagerie thunderbird pour recevoir et envoyer des SEPAmail RUBIS. SMETH est utile pour concevoir de nouvelles applications, tester des applications existantes et, d'une manière générale, comme visionneuse d'un SEPAmail sur un environnement local

SEPAmail: onze principes

Voici quelques principes qui, à mon sens, fondent l'approche SEPAmail et structurent le standard:

• SEPAmail est une messagerie au minimum 4 coins, 2 utilisateurs, 2 adhérents, couverts par au moins trois contrats
• SEPAmail permet des échanges de dialogues structurés formalisés au sein d'applications, qui, lorsqu'elles sont éditées par la norme, ont une portée globale (à tous les adhérents)
  
• SEPAmail met en œuvre un procédé d’accusé de réception systématique (l'acquittement) qui est garanti par les adhérents. Cet accusé de réception induit l'authentification des adhérents et l'intégrité des messages échangés
  
• SEPAmail permet de garantir l'authentification des personnes physiques liés à un identifiant (le qxban). Le transcodage entre un IBAN et un QXBAN est toujours assuré par l'adhérent émetteur du QXBAN. L'IBAN est ainsi protégé dans le dialogue entre les utilisateurs, même lorsque un message articule un paiement
• SEPAmail permet, par la vertu du modèle 4 coins et de la chaîne contractuelle, à un adhérent de proposer à son client, l'utilisateur SEPAmail, des services autour du flux quand ce flux est vu par l’adhérent : enrichissement du flux, vérification, articulation d'un paiement (le rôle des établissements de paiement est un plus pour l'utilisateur)
  
• SEPAmail garantit à l'utilisateur que l'adhérent doit respecter des règles et qu'il y a un juge arbitre de ces règles quand le protocole ne permet pas d'exclure intrinsèquement les tricheurs. Le juge arbitre est la Banque de France quand on parle de la loi française et c'est le scheme quand on parle de la charte des adhérents SEPAmail.
• tous les messages constitutifs d'une application sont autoporteurs de l'information pour qu'une partie du dialogue permette de réaliser l'action suivante
• SEPAmail ne présume pas le canal d'échange de l'information entre un adhérent et son client, l'utilisateur et notamment le moyen de l'authentification de l'utilisateur par l'adhérent
  
• l'extension de norme à la relation "pair à pair" doit être possible
• le modèle 4 coins peut devenir un modèle 5,6 coins ou plus mais pas un modèle 2 ou 3 coins dans le cadre communautaire, car c'est lui qui garantit beaucoup des principes ci-dessus et ces modèles qui rendent la confiance à l'utilisateur (les avocats, les médecins, les notaires) et oblige à un juge arbitre clair protégeant les utilisateurs
• sepamail doit pouvoir fonctionner nativement en mode canonique avec les infrastructures et les protocoles de messageries électroniques standards

SEPAmail et mon client de messagerie

Puis-je recevoir un contenu SEPAmail dans mon client de messagerie habituel ?

A priori, l'idée est assez naturelle.

Mon client de messagerie (Mail User Agent ou MUA) sait :

• récupérer et transmettre un courriel à son facteur usuel (Mail Transfert Agent ou MTA)
• chiffrer/déchiffrer un contenu au format S/MIME
• afficher un courriel
• stocker, classer, indexer un contenu SMTP dans un format unitaire ou globalisé

Bref, il sait lire, écrire, stocker, récupérer et transmettre pour envoi une enveloppe SEPAmail.

Que lui manque-t-il alors pour qu'il devienne mon client SEPAmail (Interface Homme Machine IHM) ?

Pas grand chose à vrai dire...

Il faut juste que je puisse :

• ne voir que l'information utile dans la missive (format xml) et le message (format xml)
• voir cette information sous une forme lisible
• être aidé dans la mise en œuvre du protocole SEPAmail, et notamment pour l'acquittement automatique et obligatoire

Comment faire cela simplement ?

Je peux par exemple imaginer installer une extension qui puisse mettre en œuvre les fonction suivantes autour de la missive :

• affichage à l'utilisateur humain de l'entête de la missive pour les champs importants :
• horodatage
• expéditeur
• destinataire
• priorité
• type de missive
• affichage à l'utilisateur humain du contenu de la missive selon son type
• possibilité d'acquitter la missive nominale de façon manuelle (voire automatique) avec un code d'acquittement validant au moins la bonne distribution

Je peux aussi imaginer qu'il y ait une extension pour chaque application SEPAmail (RUBIS, GEMME, JADE, ...) qui me fournisse les fonctions suivantes :

• affichage à l'utilisateur humain du contenu du message selon son type, sous une forme à trouver, à défaut une table de type formulaire
• affichage des binaires contenus dans le messages sous forme de pièces jointes classiques après vérification antivirale locale
• possibilité de mettre en œuvre le message suivant s'il existe au sein de la séquence liée à l'application SEPAmail en reprenant les informations du message précédent

En extension de norme, je peux me servir de mon adresse de courriel classique avec mon relais d'acheminement (ma banque ou l'adhérent SEPAmail qui me fournit le service SEPAmail) et il me faudra alors associer à cette adresse de courriel un biclé certifié et insérer les certificats de mon relais d'acheminement.

Quelques petits schémas pour illustrer

exemple d'architecture autour d'un MUA

Voici ce que pourrait être l'architecture applicative autour de mon client de messagerie habituel :

• trois acteurs :
• l'adhérent SEPAmail qui fournit le service, par exemple ma banque
• l'utilisateur SEPAmail qui utilise le service, par exemple, moi, client de ma banque ayant souscrit le service SEPAmail RUBIS
• mon fournisseur d'accès internet qui m'a également fourni une adresse de courriel et les services de son MTA
• cinq composants :
• la plate-forme de l'adhérent, que je ne connais pas et accessible via par des adresses de courriels fournies par l'adhérent
• le MTA de mon FAI, que j'utilise sans vraiment le savoir en ayant configuré au démarrage mon client de messagerie (configurations smtp et imap/pop)
• le parefeu de mon réseau (ma Box) ou mon système d'exploitation, configuré le plus souvent nativement pour permettre le passage de courriel
• mon client de messagerie (MUA) préféré et utilisé qui va accueillir des extensions SEPAmail pour être compatible avec ce service
• un anti-virus que mon MUA sait appeler si nécessaire, notamment quand une extension SEPAmail extrait une pièce jointe et me l'expose à l'ouverture ou l'exécution
• trois zones :
• le SI de l'adhérent SEPAmail, inconnu pour moi
• internet, également peu connu de moi
• mon réseau domestique ou de travail, symbolisé sur le schéma par le carré en pointillé autour de mon MUA

Voici ce que pourrait être l'architecture applicative au sein de mon client de messagerie :

• un composant de cryptographie pour permettre la gestion des certificats avec le coffre-fort de mon système d'exploitation ainsi que la mécanique cryptographique autour du chiffrement et de la signature
• un composant permettant la vérification d'une authentification sous un protocole type SAPPhire
• une extension commune autour de la missive
• des extensions pour chacune des applications SEPAmail que j'ai contractées.

  

  composants du client de messagerie

   

Que reste-t-il donc à faire pour que cela fonctionne ?

Il faut simplement que des éditeurs développent des extensions pour les clients de messagerie usuels (Outlook, Thunderbird, Mail)...

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.

Vocabulaire SEPAmail : mode d'échange canonique versus flash

Le standard SEPAmail définit la structuration de l'information échangée, une organisation pour l'adressage, les séquences d'envoi/réception.
Concernant l'échange à proprement parler de l'information, la documentation cite de deux modes : le mode canonique et le mode flash.

Le mode d'échange canonique

L'adjectif canonique doit être compris dans son utilisation usuelle en mathématiques comme en informatique, c'est à dire standard ou encore naturel et instinctif.
SEPAmail est une messagerie sur internet, le mode d'échange canonique est donc celui de la messagerie électronique, c'est à dire le mécanisme d'échange proposé par le protocole SMTP.

Ce protocole met en œuvre le transfert direct de serveur à serveur et le relais si besoin. Il repose sur des protocoles tiers tels que le DNS, IP, TCP, ainsi qu'un mécanisme d'extensions du protocole qui permet notamment l'implémentation de priorité.
Enfin, il définit une liste de commandes pour permettre de dialoguer entre deux serveurs et, si besoin, différer la remise effective du message.
Cette souplesse protocolaire permet d'éviter de perdre des messages si l'un des composants automates de la messagerie n'est pas joignable.

En théorie, un message peut être distribué à son destinataire plusieurs jours après l'émission par son expéditeur. En pratique, la messagerie électronique est souvent très rapide; nous sommes habitués depuis des années à recevoir nos messages électroniques dans un temps très court (souvent plus rapide que les SMS) et c'est même cette particularité qui a fait le succès et la généralisation de la messagerie électronique.

Pour être efficientes dans la mise en œuvre du protocole SMTP, la plupart des applications dédiées à l'échange des messages (applications dites MTA comme Mail Tranfert Agent) ont mis en place un mécanisme efficace de files d'attente et c'est ce mécanisme qui permet une bonne articulation entre des applications différentes avec des contraintes souvent divergentes.

SEPAmail repose nativement sur le protocole SMTP pour la structuration de l'information (enveloppe SEPAmail = enveloppe SMTP).
SEPAmail repose aussi nativement sur le protocole SMTP pour l'échange de cette information.
Ainsi, une enveloppe SEPAmail peut transiter par les systèmes de messagerie électronique sans aucune modification de ces systèmes.
Avec le mode d'échange canonique, SEPAmail est totalement compatible avec la messagerie électronique existante.

Le mode d'échange flash

Le mode d'échange canonique ne garantit pas un temps très court pour l'échange des données.
SEPAmail définit donc, lorsqu'il est important d'échanger rapidement une enveloppe SEPAmail, un mode d'échange flash.

Celui-ci repose sur un mécanisme de services web avec une garantie de réponse courte dite flash, de l'ordre de quelques secondes, comme en monétique.

C'est ce mode d'échange qui est en cours d'expérimentation dans l'esprit  qui peut le plus peut le moins. Cette expérimentation permet de bien s'assurer des délais raisonnables bout à bout que l'on peut garantir selon la charge et l'organisation des systèmes d'information bancaires ainsi que les coûts maximums de l'infrastructure flash.

Quelques réflexions sur le mode d'échange batch

La monétique et les systèmes informatiques bancaires en général sont assez friands de traitements par lots (batch processing) à des temps programmés à l'avance (vacations) et donc non à la demande comme les traitements transactionnels sur requêtes d'un client. Certains acteurs bancaires adhérents de SEPAmail mettent en œuvre de tels traitements au sein de leur système d'information.

Ce mode d'échange n'est pas souhaité entre les adhérents pour plusieurs raisons :

• il va à l'encontre de la logique message unitaire de SEPAmail
• il induit une gestion centralisée et pilotée de la charge alors que SEPAmail privilégie une gestion répartie pair à pair de l'échange.
• il repose sur un mode non transactionnel alors que SEPAmail utilise le réseau IP, transactionnel par nature

Le web service sur internet et l'illusion du temps réel

Le temps réel est à la mode dans le monde internet et le service web semble être l'objet de toutes les attentions actuelles pour mettre en œuvre du temps réel.

Cependant, derrière ce terme se cache des contradictions qui sont rarement mises en avant.

Un système temps réel est généralement défini par sa capacité à délivrer un résultat dans un temps fini et garanti, ce qui oblige toute la chaîne des procédés utilisés à être en temps réel.

Or, le réseau IP repose aujourd'hui :

• sur des machines dont les système d'exploitation ne sont pas des systèmes temps réel
• sur des protocoles qui ne peuvent garantir le résultat et encore moins en temps fini

Le réseau IP repose sur le paradigme du best of qui est peu compatible avec le temps réel.

On devrait donc parler de temps court au lieu de temps réel. On peut parler aussi de temps synchrone entre deux automates, dans la transaction entre le serveur et le client.

Le mode flash SEPAmail est un mode synchrone alors que le mode canonique est un mode asynchrone.

Le service web (web services) peut être vu comme une généralisation du service de page web à l'internaute.
Les protocole de la famille tcp/ip (dont http) ont permis dans un premier temps à des automates de servir de l'information sous forme de pages html à des êtres humains organisés.

Très vite, des automates programmables doués d'ubiquité se sont substitués aux internautes pour transformer, traiter l'information et la restituer autrement (opérés de façon exceptionnelles par exemple par google, yahoo, kelkoo). Les services webs sont apparus pour permettre la communication et l'échange de données entre applications et systèmes hétérogènes dans des environnements distribués.

Les services webs présentent des particularités souvent oubliées et qu'il convient de bien appréhender dans le cadre de SEPAmail. Ils sont généralement en mode client/serveur avec une structure de coût essentiellement déportée sur le serveur. Ils sont plutôt gros consommateurs de ressources par rapport à d'autres implémentations. Ils sont souvent concurrentiels sur le réseau IP des transactions hommes/machines et l'articulation avec les échanges homme/machine est rarement facile à mettre en place.

L'engouement pour les architecture reposant sur des appels de procédures à distances (RPC ou Remote Procedure Call) a permis de régler quelques problématiques liés au secret de fabrication, au coûts d'intégration ou encore aux contraintes de distribution des services.

C'est dans ce contexte que SEPAmail a conçu un mode flash de cette messagerie sécurisée qui, devrait, à terme, n'être utilisé que pour les messages à forte valeur ajoutée pour les clients finaux.