SEPAmail, c'est de l'internet, pas du paiement

Je suis étonné de lire ici ou là que SEPAmail est un moyen de paiement.

Certes, l'application RUBIS de SEPAmail, appelée aussi "règlement via SEPAmail" permet d'articuler une demande de règlement et un paiement, le plus souvent par virement.
RUBIS est donc une application idéale pour rendre possible le paiement de proximité à la main de celui qui doit payer.Mais ce n'est pas un paiement a proprement dit, c'est un échange d'information avant le paiement, rendant possible le paiement électronique de proximité à la main du payeur.


C'est bien cette application qui pourrait être utilisée et mise en avant par l'état pour le paiement de la TVA, du "reste à charge" dans le cadre du tiers payant, ou encore du remplacement du TIP... au lieu de nous emmener vers le tout prélèvement pour tous (entreprises, particuliers, institutions).

Le prélèvement apparaît la bonne solution à la plupart des grosses administrations et grosses entreprises mais il induit un désengagement supplémentaire du payeur, absolument non nécessaire et, à mon sens contre-productif pour la confiance entre les parties.

Regardons de plus près le besoin d'une entreprise par rapport à la TVA, la saisie comptable, la transmission de facture...

Ce besoin repose dans le fond sur de l'échange d'information authentifié avant un paiement, pour éviter la fraude ou le flou qui permet les délais de paiement à rallonge par le payeur.
Il semble à l'évidence utile de dématérialiser et d'automatiser cet échange d'information.

Le problème, c'est que c'est du mode "message" dont on a besoin, pas du mode "action".
L'extranet est donc une mauvaise solution, comme l'articulation du paiement par celui qui veut être payé et qui est assez gros pour l'imposer.

Il faut s'adapter à celui qui prépare, déclare et paie, et donc travaille pour la collecte de l'état. Il faut s'adapter à l'humain (un échange de message structuré) et non à l'action automatique à la main du plus gros, qui produit nécessairement à terme un absurde non contrôlé.

C'est dans cette optique qu'un besoin de messagerie sécurisée en amont des paiement (mobilité bancaire, articulation d'un paiement, transmission d'un mandat, vérification d'identité bancaire, transmission de facture, justificatif d'un versement) a été décelé en 2008 puis mise en oeuvre dans le cadre d'un réseau de banques dès 2012.

Un réseau de banques, c'est la garantie :

• d'un réseau quart de confiance, comme celui des médecins, des avocats, des notaires, le socle véritable de tout réseau de confiance,
• de la confidentialité liée au secret bancaire,
• d'une capacité à repérer les déviances de l'automatisation par le double contrôle comptable, le contrôle réglementaire, les lois anti-blanchiement et financement d'activités illégales.
• de prix au plus juste, par la mise en concurrence possible
• d'une articulation facile avec le monde des paiements, sans préjuger du moyen de paiement utilisé

En conclusion

SEPAmail est une bonne idée qui devrait être un peu plus regardée par tous ceux qui ne confondent pas modernisation de l'état avec "prélèvement de tous" et "extranets centralisés pour tous"...

Foire aux questions n°3

Voici les questions qui me sont posées fréquemment ces temps-ci sur SEPAmail.
Si vous avez vous-même des questions, n'hésitez pas à me contacter par la zone commentaire de ce billet ou via les réseaux sociaux viadeo ou linkedIn.

SEPAmail pour tous, c'est pour quand ?

En ce moment, le protocole SEPAmail est bien mis en oeuvre entre des particuliers, des entreprises et des professionnels dans au moins 3 des 5 banques ayant adhéré au réseau.
Par exemple, j'ai payé une facture d'un opérateur de télécom avec l'application de SEPAmail RUBIS et je rembourse l'un de mes clients quand il paie au restaurant.
Cependant, mon épouse, mes enfants et mes parents n'utilisent pas encore SEPAmail, et notamment RUBIS. Pourquoi ?
Parce que le lancement est prévu courant 2014... vers mars pour les premiers prêts, avant l'été pour les autres.
Donc, une fois le SEPA dernière nous (février 2014), SEPAmail devrait être accessible au plus grand nombre, notamment sur le sol français.

SEPAmail est un réseau de messagerie privée ou publique ?

SEPAmail est un réseau de messagerie privée, utilisable par les clients des adhérents de SEPAmail qui deviennent ainsi des fournisseurs d'accès à SEPAmail et ses applications.
SEPAmail permet de faire transiter de façon sécurisée l'information sur un réseau public comme internet, entre tous les points d'articulation de la messagerie.
Voilà pourquoi la réponse à cette question peut être ambiguë pour certains qui ne se sont pas plongés dans le standard, qui lui, est ouvert et public.

C'est quoi le règlement (via) SEPAmail ?

Le règlement (via) SEPAmail, c'est le nom générique de l'application de SEPAmail dont le nom de code entre ses concepteurs est RUBIS.

J'ai déjà écrit que SEPAmail n'était pas un nouveau moyen de paiement.
C'est une messagerie qui permet entre autres de s'envoyer entre deux entités économiques (particulier, entreprise, professionnel, institution, administration, association.... ) une demande de règlement et d'y répondre par une acceptation ou un refus, voire de ne pas y répondre.
La demande et la réponse passe par la messagerie SEPAmail. Elles sont complètement dématérialisées, automatisées, articulées.
Quand la réponse est positive, une initiation de paiement peut être articulée en même temps, ce qui est le comportement par défaut adopté par les adhérents. La réponse positive vaut donc initiation de paiement donc un règlement "dit" SEPAmail.
La plupart des banques mettant en œuvre RUBIS ont articulé un virement, ce qui permet au passage de répondre à la demande de virement de proximité.

L'application DIAMOND est-elle bien 4-coins ?

L'application de SEPAmail DIAMOND permet à un gros remettant d'ordre (prélèvement ou virement) de vérifier un identifiant bancaire avant la remise.
Par exemple, un opérateur d'énergie va vérifier avant d'envoyer un remboursement l'IBAN de son client en correspondance avec le nom et le prénom. Le score rendu avec DIAMOND par la banque de son client permet à cet opérateur de prendre une décision de virement automatique (par exemple via JADE) ou de matérialisation d'une lettre chèque.

Si le client remboursé (ou prélevé) n'est pas au courant qu'il y a des demandes de vérification de son identifiant bancaire, l'application n'est pas vraiment 4 coins.
Si le client est au courant à chaque demande, il peut ne plus se fier à cette information récurrente, voire considérer cette information comme une pollution.
Par contre, si ce client peut décider de son niveau d'information et agir en cas de suspicion d'abus de demande de de vérification, alors, nous somme bien dans un modèle 4 coins vertueux.
C'est ce troisième cas qu'est en train de finaliser le scheme SEPAmail.

 

Pourquoi il n'y a plus de billets chaque semaine sur ce blog depuis quelques mois ?

La question m'est souvent posée ;-)

Il y a plusieurs réponses à cela.

Tout d'abord, SEPAmail n'est pas généralisé et les banques ne communiquent pas beaucoup en ces temps d'urgence SEPA.

Ensuite, je suis sollicité sur plein de sujets par plusieurs acteurs mettant en oeuvre SEPAmail mais je suis plutôt sous Non Disclosure Agreement avec eux... donc, en ce moment, je ne partage pas avec tous mes bonnes idées, car je ne sais pas toujours si elles ne sont pas un peu issues de mes travaux confidentiels.

Enfin, je préfère attendre d'avoir du contenu intéressant pour vous et moi, plutôt que de vous abreuver de contenu en retard ou trop en avance sur le temps SEPAmail.

N'hésitez pas à me contacter ou à participer au blog si vous avez des idées.

Dans les tuyaux, il y a à venir :

• un billet sur la SMIRK JADE qui est en voie de diffusion
• un billet sur la gestion des dates dans RUBIS et notamment des précisions sur la "date souhaitée de paiement" et la "date d'expiration" de tout message
• une série de billets sur des produits dans le même champ fonctionnel : MyBank, StarMail, Zoomit...
• un billet sur la gestion de la volumétrie

Bonne lecture...

En marge de SEPAmail : 2DDoc

Au fil du projet SEPAmail, il y a des idées (portées par des hommes) qui sont simples et réalisables... moins brillantes peut-être que les dogmes de quelques experts mais elles m'ont séduit car je crois en leur potentiel de métamorphose du sujet qu'elle traite.

Je continue cette série par le standard récent 2DDoc, inventé par la société AriadNext et porté par Cyril Murié de l'Agence Nationale des Titres Sécurisés (ANTS).

Les concepteurs de ce standard le présente ainsi : "Le standard à codes barres bidimensionnel 2D-Doc consiste en la sécurisation de données dans un code à barres signé électroniquement par la clé privée correspondant à une clé publique placée dans un certificat du type cachet serveur."

Premier constat : la fraude documentaire est facile à réaliser.
Un cas d'usage consiste à retoucher à l'aide d'une application la numérisation d'un document utilisé à des fins officielles afin de changer un élément important de ce document : une adresse, un nom, une date... tout en conservant un aspect "authentique" au document sans que cela soit facile à démontrer.


Deuxième constat : la numérisation ne veut pas dire dématérialisation et encore moins automatisation.


Beaucoup d'entreprises numérisent les documents qu'elles manipulent afin de les stocker, les reproduire, les sauvegarder plus facilement.
En sus de la numérisation, il est souvent configuré une reconnaissance de caractères afin de permettre des choix sur reconnaissance d'étiquettes  identifiants, références, etc...
Cependant, numériser et la reconnaissance de caractères ne signifie pas qu'il est plus facile d'automatiser des procédés. La notion d'encodage sous forme de code barre permet une lecture plus fiable et souvent plus facile.
Pour automatiser les procédés à la réception d'un document matérialisés ou numérisés, la présence de code barre permet une meilleure réussite et moins de cas à traiter avec un agent humain.

Troisième constat : pour dématérialiser de façon efficace une chaîne complète de traitement, il faut pouvoir articuler un tronçon matérialisé.
Quand on pense dématérialisation, on doit aussi penser à rester interopérable avec des agents qui ne disposent pas de la possibilité de lire ou écrire un support dématérialisé.
Ceci est connu des éditeurs de billets électroniques. Il faut pouvoir aussi imprimer ce billet dans certains cas.

Fort de ces trois constats, la société AriadNext a proposé d'encoder dans un code à barre 2D les informations utiles du document pour un automate, comme le nom, le montant, la date, l'adresse etc..., signées cryptographiquement par l'éditeur du document qui, par cette signature, authentifie ces informations.
Ce code à barre devient ainsi un sceau d'information photocopiable, imprimable, infalsifiable, lisible par un automate avec un fort taux de réussite.

Le principal inconvénient du code barre 2D est le peu d'information que l'on peut encoder.
l'ANTS a donc standardisé cette information sur le principe :

• d'un entête de type nomenclature à tiroir
• d'un corps de message de type liste de paires clés/valeurs en normalisant les clés, le type des valeurs.
• d'une signature des informations

sans y stocker le certificat qu'il faut donc récupérer par soi-même pour vérifier le code-barre.

Les informations 2DDOC sont compatibles avec les types de l'iso 20022 et les relevés d'identité bancaire et les relevés d'identité SEPAmail (RIS) sont des documents reconnus par le standard.

Ainsi, le RIS peut être encodé comme un 2DDOC : il s'appelle alors un RIS2D.

Voici mon RIS2D 2DDoc de test avec lequel vous pouvez essayer de m'envoyer un message SEPAmail.

Quels sont les avantages ?

Ils sont nombreux :

• la fraude par retouche infographique est difficile
• l'échange d'identifiant authentifié est automatisable et plutôt ergonomique avec un smartphone
• le standard propose une structuration des documents et des informations sensibles
• la vérification peut-être déshumanisée, ce qui peut augmenter la sécurité pour les agents
• la photocopie de l'identifiant authentifiable est possible

L'authentification documentaire est un premier pas vers la vulgarisation de l'authentification et la distinction essentielle entre l'authentification d'une personne, d'un document, à distance, en présence.

Quels sont les inconvénients ?

L'un des plus gros inconvénients, selon moi, tient dans un des avantages.
A ne plus pouvoir frauder par la retouche graphique, la fraude interne aux producteurs privés et publics de justificatifs va devenir visible.

Est-ce qu'un opérateur d'énergie ou de téléphonie va vraiment vouloir faire plus qu'authentifier un document et un montant et devenir responsable, sous son sceau et son organisation, de l'authentification d'une personne, d'une domiciliation, d'une date de naissance ?

On peut reprocher aussi au standard de ne pas expliciter suffisamment les limites d'utilisation d'une clé privée, notamment l'usure de la clé utilisée par rapport à l'usage.

Pour ceux qui liront la spécification technique, ils verront qu'il n'est pas possible de donner autre chose qu'une date limite d'utilisation, ce qui n'est pas très international. La norme possède également une limite intrinsèque liée au nombre maximum de jours depuis le 1er janvier 2000, à savoir 65535 jours donc elle ne sera plus valable en 2180 !

Enfin, par manque de place, il n'a pas été prévu de pouvoir insérer une clé publique liée à l'identifiant, ce qui aurait résolu nombre de difficultés cryptographiques d'inscription, notamment pour les relevés d'identité bancaire.

Pour aller plus loin

• le site 2D-doc
• le descriptif du processus
• la spécification technique
• l'application de lecture 2D-doc pour Android
• la page 2D-doc sur le site de l'ANTS

SEPAmail au coeur d'une solution pour remplacer les espaces clients "non markettés"

Il y a de nombreux espaces clients virtuels

De nombreux espaces clients virtuels se sont mis en place au fil des années, la plupart sur les modèles des boutiques eCommerce et marketés selon les mêmes principes.

Ainsi, aujourd'hui, chacun d'entre nous peut :

• voir ses remboursements de sécurité sociale sur son espace dédié de la CPAM, RAM, MSA etc...
• déclarer et consulter ses impôts
• récupérer ses remboursements de mutuelle
• déclarer ses emplois à domicile
• consulter ses déclarations CAF
• etc...

De même, les entreprises ont un espace de consultation et de déclaration pour :

• le RSI URSSAF
• le RSI RAM
• les impots
• les caisses de retraites
• les organismes de formation
• etc...

Tous ces espaces sont opérés et édités à grands frais par les institutions avec des critères de sécurités pas forcément homogènes, une authentification dédiée, des alertes par courriel avec des informations non anonymes.

Le papier a été remplacé par des documents numériques dans autant d'espaces que d'éditeurs de documents, avec une logique de stockage assuré et financé par l'éditeur au lieu et place du destinataire.

Le principe sous-jacent peut s'énoncer ainsi :
"Nous, les éditeurs de papier, nous avons intérêt à dématérialiser pour notamment faire des économies. Nous sommes prêts à financer des espaces de stockage pour nos destinataires car cela nous coutera moins cher, même si, avec ce service, nous changeons totalement les usages, la structure de coûts et les responsabilités autour du stockage, de la preuve et de la sécurité."

Ce principe n'est pas très efficace car il change fondamentalement les règles de confiance entre les expéditeurs et les destinataires de ces documents; alors même que cette confiance repose depuis des siècles sur le pair à pair et le rebond de l'authentification.

La confiance est primordiale.

Or, la confiance est primordiale dans les relations entre les entités économiques et il est important de ne pas déresponsabiliser l'utilisateur et le bénéficiaire des services collectifs.

Avec SEPAmail, l'approche de la dématérialisation et de l'automatisation est différente.
SEPAmail sécurise l'échange d'informations sans changer la nature et l'enjeu des stockages existants ou à venir.

Ainsi, un particulier peut choisir de matérialiser tous les documents qui lui arrivent ou les stocker de façon sécurisée ou non, dans en endroit unique ou non, il reste responsable et maître du stockage des documents.

Il ne dépend pas de nombreux éditeurs et de chacune des implémentations en terme de lecture de document, d'espaces de stockage et de sécurité de ses informations.

Le destinataire doit rester maitre à bord de son système d'information.

L'utilisateur reste le maitre à bord, quelque soit l'expéditeur du document.
Ainsi, l'utilisateur peut s'organiser de façon durable et personnalisée, comme autrefois pour son organisation de courriers.
 
Qu'en est-il des espaces clients des nombreux fournisseurs de services, espaces largement marketés ?



Les usages du web et la création de compte deviennent la norme... au risque de perdre toute confiance avec son client.

J'ai lu récemment un billet sur la promotion des commandes en ligne sans création de compte client... grand bonheur de l'acheteur soucieux de ne pas être une cible marketting ou publicitaire de plus.

Les stratégies sont difficiles pour ces utilisateurs, car ce sont plutôt les usages du web commercial qui s'imposent même dans la vie physique et pour la plupart des actes de la vie réelle... Aujourd'hui, on vous demande souvent de créer, de temps en temps à votre insu, un compte client pour pouvoir vous atteindre, vous segmenter...

Là encore, SEPAmail permet facilement le paiement sans création de compte avec les applications RUBIS et GEMME, tout simplement car SEPAmail met en avant un adressage mondial des entités économiques protégé par le réseau des banques des utilisateurs.

Avec des coûts annoncés très faibles et un spam difficile sans se griller définitivement sur le réseau, SEPAmail est sûrement un moyen efficace de communiquer avec son client en toute confiance et authentification avec un ré-équilibrage de la relation par la possibilité pour chaque client de décider de ce qu'il reçoit, et de qui il le reçoit.

L'important pour la confiance numérique de demain, c'est de pouvoir informer et vendre le meilleur produit pour son client... en toute responsabilité et toute transparence.

Pour aller plus loin

Je suis intéressé par vos remarques sur ce sujet et les développements d'usages que permet la notion de messagerie sécurisée, comme SEPAmail.

Communauté SEPAmail : DenyAll

Nous continuons notre tour des entreprises de la communauté SEPAmail avec DenyAll.

Jacques Sebag, directeur général et Renaud Bidou, directeur technique, se sont très tôt intéressés au standard SEPAmail et ont apporté durant l'année 2012 une contribution importante au groupe sécurité.

Stéphane de Saint Albin, directeur marketing, répond à nos questions.

Quand a été créé DenyAll, dans quel contexte ?

DenyAll est un éditeur français de logiciel, leader sur le marché de la sécurité applicative. Spin-off de la Société Générale, fondée en 2001, la société fut l’un des pionniers du Web Application Firewall au niveau mondial. Afin de sécuriser ses applications bancaires, la Société Générale avait en effet mis au point l’un des premiers reverse proxy filtrant, une technologie qui n’existait pas encore sous forme commerciale à la fin des années 90. DenyAll n’a cessé d’innover depuis pour répondre aux défis liés à la sécurisation et à l’accélération des applications et services Web de ses clients.

Combien de collaborateurs, quels profils, quelles fonctions ?

DenyAll emploie une quarantaine de personnes, dont plus de la moitié sont des ingénieurs logiciels, qui innovent pour lutter contre les attaques connues et inconnues. Les ingénieurs avant-vente sont des experts en sécurité réseau et applicative. La direction est composée de vétérans de l’industrie du logiciels et d’experts en sécurité :

• Jacques Sebag, Directeur Général, a plus de 25 années d'expérience en France, en Europe et aux Etats-Unis. Il a contribué au développement d’Oracle, Remedy, Veritas, Symantec et Ever Team.
• Renaud Bidou, Directeur Technique, est un expert de la sécurité reconnu. Il a fondé la société Intexxia, premier SOC français en 2000, et travaillé pendant 5 ans chez Radware.
• Stéphane de Saint Albin, Directeur Marketing, a exercé diverses fonctions au sein d’éditeurs comme Microsoft, 4D, Symantec et Neowave, en France, en Europe et aux Etats-Unis.

Quels sont les principaux produits ou services développés et vendus ?

L’offre de DenyAll s’articule autour des thèmes Protect, Detect et Manage :

• Protect : les produits historiques de DenyAll sont des pare-feux pour applications et services Web. rWeb, sProxy et rXML s’appuient sur une technologie reverse proxy éprouvée et une architecture modulaire qui permet à la société d’ajouter régulièrement de nouveaux modules de sécurité, comme ce fut le cas pour Sepamail.
• Detect : suite à l’acquisition de la société VulnIT en juillet 2012, DenyAll propose une gamme de scanneurs conçus pour aider auditeurs et équipes en charge de la sécurité informatique à gérer les vulnérabilités de leur infrastructure et de leurs applications, y compris en mode SaaS/Cloud, pour tester les défenses depuis l’extérieur.
• Manage : la console de management (DAMC) permet de réduire le TCO, de centraliser l’allocation des tâches entre administrateurs en charge de la sécurité, de l’infrastructure informatique et des applications.

Quel est le profil de vos clients, quelles sont vos références ?

DenyAll a vendu initialement aux grandes institutions financières Françaises. La société s’est développée sur d’autres secteurs verticaux en Europe, aidant les entreprises leaders des secteurs de l’énergie, des transports, des télécoms, de la défense, des médias, de la distribution, des services et du secteur public à protéger leurs applications Web. Aujourd’hui, DenyAll compte plus de 300 clients actifs, dont un tiers sont membres du CAC40. Une part grandissante des nouveaux clients de DenyAll sont des entreprises de tailles moyennes en Europe, Afrique du Nord, au Moyen-Orient et en Asie.

Quelles sont vos spécificités ?

DenyAll est un expert de la sécurité applicative. Avec plus de 10 ans d'expérience dans la sécurisation et l’accélération des applications Web, XML et FTP, DenyAll répond aux besoins de la plupart des organisations, grands comptes comme PME. Les pare-feux applicatifs de DenyAll protègent plus de 30 000 sites transactionnels, frontaux web, applications à base de Web Services (SOA) et outils de collaboration, en environnement traditionnel comme dans le Cloud. Les innovations DenyAll incluent la Scoring List, l’analyse comportementale, l’architecture Multi-DMZ et son mode Pooling, le module Client Shield qui contrôle l’exécution sécurisée du navigateur, des nouveaux moteurs de sécurité pour les langages modernes tels que JSON, le Mode Transparent Sécurisé, pour un déploiement facilité sans compromis de sécurité et le virtual patching, fruit de l’intégration entre les produits Protect et Detect.

Quel est votre lien à SEPAmail ?

Nous fournissons des solutions de sécurité des couches de transport. Concrètement, cela signifie que nous sécurisons les flux HTTP ainsi que les données XML utilisés pour échanger les missives. En effet les protocoles utilisés sont connus pour servir de vecteur d’attaque des couches applicatives. De telles attaques pourraient compromettre l’intégrité des données, interférer sur les processus de traitement, altérer les transactions, voire permettre un accès illégitime aux terminaux des administrateurs ou des utilisateurs du service.

Ainsi nous vérifions qu’aucune attaque n’est insérée dans les données en comparant les flux avec différentes bases de signatures. Nous nous assurons également que les formats de données sont conformes aux spécifications afin de prévenir d’erreurs de traitement volontaires ou non. Enfin les fichiers sont extraits et transmis à un anti-virus afin d’identifier toute menace de cette nature avant leur traitement.

Quel est votre implication dans la communauté SEPAmail ? Quelle évolution pour la suite ?

A l’issue de la première expérimentation, nous avons remis une étude de la sécurité des couches de transport au groupe de travail sécurité. Cette étude avait pour but de mettre en avant les failles techniques et structurelles que nous avons identifiées lors des tests. Cela a permis de renforcer la sécurité de certains composants de la chaine applicative, tels que les modèles de données par exemple, et de définir les contours fonctionnels des besoins de sécurisation de la couche de transport.

Dans l’avenir nous continuons à travailler avec certains membres de la communauté pour la mise en production de nos solutions de sécurité. Nous restons également disponible pour assister le groupe de travail sécurité dans ses travaux touchant à nos domaines d’expertise.

SAPPhire

SAPPhire n'est pas une application SEPAmail malgré son nom de pierre précieuse.
SAPPhire est une proposition fonctionnelle simplifiée autour de l'authentification.
SAPPhire dépasse donc largement le projet SEPAmail même si :

• SAPPhire utilise dans son échange d'information des messages SEPAmail,
• SEPAmail peut utiliser SAPPhire (plutôt en extension de norme) pour permettre l'authentification à distance d'un utilisateur sur une interface, par exemple depuis son smartphone.

SAPPhire concrètement, ce sont des niveaux pour simplifier la compréhension

SAPPhire propose trois niveaux différents :

• SAPPhire 1 est une authentification simple à un facteur SAPPhire
• SAPPhire 2 est une authentification forte à deux facteurs SAPPhire
• SAPPhire 3 permet les conditions de la signature numérique présumée fiable

Ainsi :

• SAPPhire 1 permet la consultation de messages
• SAPPhire 2 permet des actions qui engage le client (par exemple un virement ou l'envoi d'un courriel)
• SAPPhire 3 permet de signer un document

Les facteurs SAPPhire ne sont pas nombreux  mais pourront dans le futur augmenter en nombre :

• un certificat logiciel installé sur l'environnement local de confiance protégé par un PIN
• un certificat matériel en présence de l'environnement local de confiance
• un certificat matériel protégé par un PIN

Bref, l'idée derrière SAPPhire, c'est qu'au delà de la complexité portée par la cryptographie et l'authentification, une ergonomie utilisateur est possible tout en respectant l'état de l'art, les directives nationales et européennes.
Il devient possible, en adoptant SAPPhire massivement, de dire le niveau SAPPhire de chacune des fonctions demandées par un service métier.
L'infrastructure, la sécurité et, plus généralement, les services informatiques des entités économiques pourraient alors proposer le support des niveaux SAPPhire plutôt que de devoir inventer à chaque nouveau projet le cadre d'intervention de l'authentification.

La petite histoire

Voici la petite histoire, celle qui explique la confusion pour certains autour de SAPPhire.
SAPPhire a été décrit au début comme l'application SEPAmail permettant d'échanger des éléments de sécurité, notamment des clés publiques.
L'eco-système secure a été inventé et associé à SAPPhire puisqu'il contient les messages d'échange d’éléments de sécurité.

Le premier démonstrateur

Dans le cadre de SEPAmail, un premier démonstrateur smartphone a été mis en œuvre par le groupe BPCE et les sociétés AriadNext et StreamMind démontrant qu'un utilisateur de smartphone pouvait s'authentifier à un service bancaire sans à avoir à passer par l'agence et sans forcément devoir recevoir un certificat matériel personnalisé.
Ce démonstrateur repose sur une application Android téléchargeable depuis son dépôt certifié. L'application :

1. s'installe
2. génère un biclé logiciel,
3. génère un code PIN protégeant l'accès et le stockage de ce certificat
4. envoie la clé publique à un serveur bancaire à l'aide d'un message SEPAmail sur le réseau IP (non sécurisé)
5. cette clé n'est activée que lorsque l'utilisateur demande cette action sur un DAB/GAB avec une authentification forte grace à sa carte de retrait ou sa carte bancaire et elle ne l'est que pour le téléphone enregistré
6. le biclé peut alors être utilisé dans le cadre d'une authentification à distance

SAPPhire 1 était ainsi né et une idée assez originale et élégante est venu de la rencontre entre les différents métiers de la banque (juridique, flux, authentification, moyens de paiement : utiliser le DAB et son authentification pour valider, par rebond et sur un autre canal, le niveau d'authentification de la carte bancaire.

Le deuxième démonstrateur

Les possibilités de trouver sur le marché des jetons cryptographiques matériels se connectant facilement à un smartphone et peu cher ont donné l'idée du deuxième démonstrateur, réalisé par le groupe BPCE et la société AriadNext : connecter l'application déjà développée avec un certificat matériel pour augmenter le niveau de sécurité et permettre deux nouveaux niveaux : SAPPhire 2 et SAPPhire 3.
Le démonstrateur a été réalisé avec des cartes NFC dont une de paiement et à démontré l'ergonomie possible pour l'utilisateur final des niveaux SAPPhire.
Les trois premières étapes du démonstrateur précédent ont donc été adaptées à un biclé matériel.

SAPPhire : quel avenir ?

SAPPhire est une simplification réelle d'un domaine devenu trop technique et trop complexe pour être réellement utilisé correctement par les éditeurs, les développeurs et les concepteurs de solutions logicielles utilisant largement de l'authentification à distance.
Si SAPPhire est compris et adopté comme un standard fonctionnel de spécification de l'authentification, alors les discussions vont aussi devenir plus simples autour de tous les standards utilisant l'authentification.
Gageons qu'un des géants du web ou une communauté amenée à s'imposer internationalement comme SEPAmail comprendra et utilisera SAPPhire.

La cryptographie, un sujet complexe

« Authentifier, c'est vérifier l'authenticité de l'identité présentée. »

Présentée ainsi, l'authentification peut paraître simple.
Cependant :

• que signifie vérifier ?
• de quelle identité parle-t-on ?
• Que veut bien vouloir dire « présenter » une identité ?

La cryptographie est un procédé mathématique qui permet de s'affranchir de mettre en présence l'authentifiant et l'authentifié. Elle ne permet pas de simplifier les autres aspects de l'authentification, même si elle résout d'autres problèmes de façon assez élégante, comme la confidentialité ou l'anonymisation.
Autour du projet SEPAmail, nous avons rencontré des experts « authentification », « cryptographie », « sécurité », ce qui m'a permis de me rendre compte que :

• le sujet est complexe,
• le sens du vocable fondamental n'est pas toujours partagé,
• il manque un modèle d'authentification partagé,
• les couches permettant la simplification locale ne sont pas toujours valorisées
• il y a réellement un besoin de simplicité pour l'utilisateur

Je détaille tout cela dans ce billet un peu long (pour une fois).

Les mots valise

Le sujet comprend beaucoup de mots valises qui sont structurants.
J'en précise certains en donnant quelques uns des sens différents utilisés et les confusions possibles.

Identification

« L'identification, c'est vérifier qu'un identifiant est présent dans une liste. » 

Par exemple, on identifie la chaîne de caractères que lit un lecteur de badge comme appartenant à la liste des identifiants de badges autorisés à passer un portique. Il peut être également identifié comme appartenant à une liste d'identifiants de badges non autorisés à passer le portique.
Ici, la chaîne de caractères est l'identifiant du badge.
Le badge est considéré comme non identifié si son identifiant n'appartient à aucune des listes.
Par extension, nombreux sont ceux qui induisent l'identifiant comme l'identité d'une personne physique. Ils considèrent alors l'identification, non pas comme la vérification que l’identité de la personne ramené à des identifiants (nom, prénom, visage, empreinte digitale, adresse) appartient à une liste d'identifiants connus, mais comme la vérification que la personne est bien celle associés aux identifiants présentés.
Cette approximation usuelle amène deux remarques :

• un identifiant n'est pas une identité
• identifier dans le sens télévisuel de la série policière est plutôt de l'authentification d'identité de personnes physiques dans une société les recensant en ayant associé un identifiant unique.

Authentification

« L'authentification, c'est vérifier l'authenticité. »

Ceci n'est pas simple et repose généralement sur le croisement de plusieurs critères.
Par exemple, l'authenticité d'un billet de banque repose sur de nombreux procédés de fabrication secrets ou connus mais difficiles à reproduire.
Par extension encore, la plupart parle d'authentification de personnes physiques à l'aide de procédé cryptographique alors même que l'authentification concerne une chaîne de caractères appelée « clé privée » au sein d'un système applicatif et/ou matériel déverrouillé par la personne physique en question.
Deux questions intéressantes sont :

1. que veut-on authentifier ?
2. Pourquoi veut-on authentifier ?

En y répondant, on simplifie généralement le problème.
L'authentification d'une personne vis-à-vis d'un système d'information est délicate à réaliser de façon directe. En effet, du point de vue de la machine, seul un procédé de nature cryptographique s'avère sûr, tandis que la personne, quant à elle, ne peut directement employer un tel mécanisme.
Les procédés d'authentification directe d'une personne se caractérisent tous par la possibilité de rejeu.
Pour bien distinguer les procédés d'authentification directe d'une personne, nous qualifions ces procédés de déverrouillage.
La robustesse est la capacité d'un mécanisme d'authentification à résister à une méthode de contournement ou de falsification.
Actuellement, il n'existe pas de mécanisme d'authentification que l'on ne peut pas contourner ou falsifier. Par contre, il en existe avec une robustesse très élevée. On distingue souvent trois niveaux de robustesse : standard, renforcé et élevé.

Sécurité

« La sécurité, c'est, entre autres, l'absence ou la limitation des risques dans un domaine précis. »

Dès que l'on parle de sécurité, il y a de gros écarts de compréhension, notamment :

• entre ceux qui croient au système ultime et ceux qui croient qu'un tel système n'existent pas,
• entre ceux qui « font la preuve » et ceux qui « s'engagent » en s'assurant contre le risque.

De plus, pour rendre plus compréhensible la notion de sécurité d'un système, beaucoup utilisent la notion de niveaux.
Or, sur ces sujets, on trouve de nombreux qualificatifs pour de nombreux concepts, par exemple :

• des niveaux d'authentification (simple, forte)
• des niveaux de robustesse cryptographique (standard, renforcé, élevé) [Référentiel Général de Sécurité]
• deux niveaux européens de signature électronique (simple et avancée) [Directive 1999/93/CE article 2]
• plusieurs niveaux français de signature électronique (simple, présumée fiable, avancée) [Memento sur la signature électronique de l'agence nationale de sécurité des système d'information ANSSI]
• différents niveaux de sécurité d'un système informatique (logique, physique, réseau, utilisateurs)
• deux états d'insécurité (passif et actif)
• des certificats électroniques (qualifiés ou « dits » conformes en attente de qualification)
• des autorités de certifications (racines, intermédiaires, qualifiées)
• différentes instances édictant différentes normes de sécurité dans le domaine du traitement de l'information, des systèmes d'information, des données de paiements (EPC, RGS, PCI DSS).

Nous voyons bien qu'un même adjectif peut être utilisé dans un sens différent, ce qui augmente les possibilités de confusion et d'incompréhension, même auprès d'un public averti.

Cryptographie

« La cryptographie est une des disciplines de la cryptologie s'attachant à protéger des messages. »

D'un abord mathématique et rigoureux, cette science a été vulgarisée par l'utilisation en sécurité informatique et en droit.
Cette vulgarisation conduit à de nombreuses confusions.

 

Une confusion possible : Décrypter et déchiffrer

Notons les définitions suivantes :

• chiffrer : transformer à l'aide d'une clé de chiffrement un message en clair (dit texte clair) en un message incompréhensible (dit texte chiffré) pour celui qui ne dispose pas de la clé de déchiffrement (en anglais encryption)
• déchiffrer :  retrouver le message clair correspondant à un message chiffré avec la clé de déchiffrement
• décrypter : retrouver le message clair correspondant à un message chiffré sans posséder la clé de déchiffrement (terme que ne possèdent pas les anglophones, qui eux « cassent » des codes secrets)

Le mot « crypter » n'a pas raison d'être ; il n'existe donc pas et il est absent du dictionnaire de l'académie française.

Déchiffrer et décrypter ne signifient pas du tout la même chose en langue française alors que les traductions anglicistes les confondent allègrement.

Une confusion possible : le procédé de cryptographie asymétrique utilise largement le procédé de cryptographie symétrique

Il y a plusieurs procédés de cryptographie dont deux permettent de nombreuses fonctionnalités :

• le système de chiffrement symétrique, quand il utilise la même clé pour chiffrer et déchiffrer.
• le système de chiffrement asymétrique, quand il utilise des clés différentes : une paire composée d'une clé publique, servant au chiffrement, et d'une clé privée, servant à déchiffrer (Le point fondamental soutenant cette décomposition publique/privée est l'impossibilité calculatoire de déduire la clé privée de la clé publique)

L'utilisation d'un système symétrique ou asymétrique dépend des tâches à accomplir. La cryptographie asymétrique présente deux intérêts majeurs : elle supprime le problème de transmission sécurisée de la clé, et elle permet la signature électronique.
Elle ne remplace cependant pas les systèmes symétriques car les temps de calcul sont nettement plus longs. La plupart du temps, le système asymétrique sera utilisé pour échanger une clé de session (courte) qui servira ensuite de clé partagée pour un échange symétrique plus rapide.
Les deux procédés ne s'opposent donc pas ; ils se complètent. 

Une confusion possible : le procédé de cryptographie asymétrique est accessible aux automates de calcul et non directement aux humains

D'aucuns parlent d'authentification de personne au moyen de procédé de cryptographie asymétriques alors même que ce type de procédé n'est pas accessibles directement à l'être humain non outillé d'un calculateur.
L'humain déverrouille un environnement local de confiance à l'aide d'un mécanisme de rejeu (une combinaison plus ou moins compliquée de plusieurs facteurs entre ce qu'il possède, qu'il sait, qu'il est...) laissant alors la charge à cet environnement local de confiance automatisé de s'authentifier à l'aide d'un procédé de cryptographique asymétrique sans rejeu.

Une confusion possible : déverrouillage local et authentification à distance

Seule l'utilisation de protocoles cryptographiques d'authentification permet de garantir à deux machines qu'elles communiquent bien l'une avec l'autre et non avec une machine usurpatrice.
Pour authentifier une personne, on utilise des mécanismes de déverrouillage (mot de passe, biométrie, support personnel) dont l'esprit est qu'ils doivent demeurer locaux.
L'utilisation d'un déverrouillage dans une procédure à distance ne constitue pas véritablement une authentification car dans le monde numérique, le rejeu est rendu très facile par les possibilités de copie numérique.
Le périmètre dans lequel le mécanisme de déverrouillage est employé doit être bien identifié car c'est un environnement qui doit être local et de confiance.

Non répudiation

« La non-répudiation est l’impossibilité de nier la participation au traitement d’une information. »

La non-répudiation de quoi ?

Selon le contexte, la non répudiation ne se limite pas au seul auteur d'un processus ou d'une action.
Par exemple, pour l'échange de messages, on peut considérer de façon distincte :

• la répudiation par l'émetteur du message ("je nie avoir envoyé le message")
• la répudiation par le destinataire ("je nie avoir reçu le message")
• la répudiation sur le contenu du message de l'un ou de l'autre (« je nie avoir envoyé le contenu de ce message » ou « je nie avoir reçu le contenu de ce message »)
• la répudiation sur les données liées au temps, l'horodatage de l'un ou de l'autre(« je nie avoir envoyé à cette date et cette heure le message », « je nie avoir reçu ce message à cette date et heure »)

Le contexte juridique de la non-répudiation

La non-répudiation est souvent associée au contexte juridique du « renversement de la charge de la preuve » dans le cadre de la signature électronique, preuve préconstituée.
Le coût économique de cette charge de la preuve étant dans certaines situations non négligeable, cette caractéristique de « non répudiation » peut devenir un sujet clé.
Pour éviter de se poser cette question, il est possible d'insérer dans le contrat initial entre une banque et son client l'obligation de preuve pour celui qui dénonce une signature.
Ainsi, le cadre de la répudiation devient contractuel.

Le contexte technique de la non-répudiation

Les systèmes de cryptographie asymétriques consacrent la notion de certificat et d'autorité de certification avec un usage garanti de non répudiation dans le cadre de la norme X.509 et sa spécialisation pour les application internet.
Attention, là encore, on utilise deux expressions voisines anglaises, souvent confondues et associées toutes les deux à la non-répudiation. Nous détaillons pour une bonne compréhension ces deux expressions et l'usage technique.

• « key usage extensions », ou extension du protocole sur l'usage de la clé est un champ renseignant sur l'utilisation qui doit être faite de la clé. Si ce champ est défini comme critique, alors la clé ne doit être utilisée que pour l'usage spécifié. Si le champ n'est pas positionné à critique, alors le champ Key usage est là à titre indicatif.
• « extended key usage extension », ou extension du protocole sur l'usage étendu de la clé, permet de définir de façon plus étendue les usages, notamment par une fonction globale attendue de la clé, comme la protection des courriels ou l'authentification d'un serveur. Voici quelques uns des usages étendus possibles, pour bien comprendre. 

En guise de conclusion

Il me semble qu'au vu de :

• la complexité du sujet,
• du manque de compréhension partagée parmi les différents experts,
• du vocabulaire ambigu ou mal traduit largement utilisé, surtout du côté des adjectifs de la graduation,
• de l'évolution des technologies avec les capacités de calcul des processeurs et des failles découvertes,

Il est temps de partager un référentiel simple et compréhensible pour l'utilisateur qui soit orienté sur les grandes fonctions qu'apporte la cryptographie en sécurité.

C'est l'objet de SAPPhire, un standard de simplification pour l'authentification sécurisé orienté utilisateur.
SAPPhire a été développé pour SEPAmail mais dépasse largement le cadre de SEPAmail.
J'en développerai peut-être dans un prochain billet en quoi SAPPhire répond à ces différentes problématiques.

SEPAmail et l'automatisation

SEPAmail permet, de par son organisation, la dématérialisation et l'automatisation de flux d'information entre des entités économiques.

L'automatisation est un des principaux intérêts de SEPAmail.

Pour autant, il est illusoire que SEPAmail soit automatisé à 100%, ne serait-ce que pour son exploitation.

Il y aura toujours des cas où le contrôle humain sera nécessaire.

L'idée est de limiter drastiquement ces cas.
C'est rendu possible par :

• la séparation fonctionnelle du dispositif de messagerie (j'échange de l'information de façon sécurisée) avec les applications (le contenu transporté)
• l'utilisation de protocoles ayant apporté la preuve de leur capacité à traiter de gros flux
• l'utilisation du réseau internet organisé et dimensionné pour ce type d'échange
• la structuration des dialogues qui ne permettent que des échanges définis dans le cadre d'un automate fini
• la structuration du contenu de chacun des messages, partagée et évolutive (schémas xml publiés)

Cependant, il y a des cas où l'intervention humaine est nécessaire :

• le contrôle d'un envoi sur demande d'un client
• une escalade non prévue pour un acquittement non réalisé
• la gestion d'une erreur non automatisée car prévue mais improbable
• un contrôle anti-fraude
• la reprise après une interruption de service

Il est important pour chacun des adhérents de bien prévoir ces cas de traitements manuels et de ne pas les considérer comme anormaux.
Il faut donc savoir désynchroniser certaines opérations et les aiguiller vers une interface homme-machine pour traitement humain.

Pour prendre un parallèle significatif, les messageries électroniques sont aujourd'hui largement automatisées.
Cependant, il faut intervenir manuellement de temps à autres sur un message bloqué ou prétendument perdu.

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.

Le modèle 4 coins

Le dispositif SEPAmail repose sur un modèle mettant en jeu quatre acteurs :

• un utilisateur A, client du fournisseur de services SEPAmail FSA
• FSA, adhérent du réseau SEPAmail
• FSB, adhérent du réseau SEPAmail
• un utilisateur B, client du fournisseur de services SEPAmail FSB

les acteurs et les espaces de confiance

FSA et FSB sont liés au réseau SEPAmail par un contrat d'adhésion.
Ce contrat d'adhésion comprend notamment l'acceptation d'une charte d'adhérent.
Cette charte fixe les règles communes que chaque adhérent s'engage à respecter.
Elle est publiée, publique et connue de tous, utilisateurs compris.

En 2012, FSA et FSB sont des banques tenues au secret bancaire.
Si des entités non bancaires demandaient leur adhésion, il faudrait préciser quel serait le cadre du secret minimal entre cette entité et son client.

A et FSA d'un côté, et B et FSB d'un autre côté, sont liés deux à deux par un contrat de service autour de SEPAmail.
Ce contrat précise les conditions d'utilisation du service, notamment les termes de la protection des données, du mandat de transmission de l'information, les bonnes règles à respecter pour chacun des acteurs afin de garantir la sécurité proposée dans le cadre de la messagerie SEPAmail.
Chaque fournisseur de service possède avec son client des espaces de confiance dans lesquels les parties sont mutuellement authentifiées et grâce auxquels l'échange d'information peut se faire en toute sécurité.

Les vertus du modèle 4 coins

Le modèle 4 coins SEPAmail présente les avantages suivants:

• les acteurs sont tous sous contrat commercial pair à pair
• c'est le réseau d'adhérents avec des règles partagées et contrôlées lors de chaque échange qui fait office de tiers de confiance et non une seule entité
• la confiance vient d'espaces de confiance pré-existants mis bout à bout, il n'y a pas de nouvel espace à créer mais une chaîne de confiance à articuler
• il permet des canaux de communication différents entre chacune des parties
• il permet à chaque fournisseur de service de proposer des services à valeurs ajoutées différents pour son client
• il permet d'inscrire l'échange d'information sécurisée dans une vision flux (articulation, structuration partagée, enrichissement par les relais) et non pas seulement comme des transferts de blocs authentifiés entre pairs.

Quand la sécurité est en jeu, le modèle 4 coins apporte les preuves de son efficacité.

On peut citer, par exemple, l'organisation de l'arbitrage des conflits en justice.
Les parties confient leur défense à des avocats différents.
Ils sont soumis à des règles communes de secret, de communication, de devoir de représentation des intérêts de leur client, un engagement à servir la justice.
Dans la plupart des cas, il y a un juge-arbitre désintéressé représentant les règles sociales et l'avocat est un relais pour la défense.
Il connaît les règles et apporte une forte valeur ajoutée dans la relation, notamment car il a la capacité à discuter sous secret avec l'avocat de l'autre partie.

On retrouve aussi des cas de figure similaires avec

• les notaires et l'ordre des notaires,
• les médecins et l'ordre des médecins.

On peut prendre un exemple de modèle 3 coins ayant montré ses limites : le cas de la distribution postale recommandée avec accusé de réception.
Le transporteur fait office de tiers certifiant unique.
La plupart du temps, les véritables règles de cette certification ne sont pas connues du public et il n'y a pas de contrat(s) entre les parties.
Le transporteur est le juge-arbitre en cas de litige.

Mais SEPAmail est-il toujours 4 coins ?

Cas où deux clients partagent le même fournisseur de service

Si A et B ont le même fournisseur de service, alors le modèle 4 coins semble devenir un modèle 3 coins car il n'y a que trois acteurs.
Qu'est-ce qui garantit que A et B ne perdent pas les vertus du modèle 4 coins ?
L'adhérent s'est engagé à mettre en œuvre le standard SEPAmail. Or le standard ne fait aucune différence sur ce sujet.
Dans tous les cas, l'échange d'information doit mettre en œuvre :

• le dispositif de messagerie sécurisée avec l'authentification, l'acquittement, l'horodatage, la journalisation
• la couverture des garanties à l'utilisateur selon le niveau de service souscrit

La conséquence, c'est que le fournisseur de service assume donc les rôles des deux relais d'acheminement.
Il doit donc nécessairement s'envoyer à lui-même une enveloppe SEPAmail contenant une signature de la missive, comme pour les autres cas.

Cas d'un client s'envoyant un message à lui-même

Supposons ce cas possible avec une application SEPAmail.
Dans le cas où un client utilisateur d'un fournisseur de service désire s'envoyer à lui même un message SEPAmail, alors, le modèle 4 coins est mis en œuvre de la même façon, même si il ne met en jeu que deux acteurs.
On considère successivement les 4 coins : l'expéditeur, le relais de l'expéditeur, le relais du destinataire et le destinataire.
Les trois échanges sur les trois espaces de confiance sont mis en œuvre en respectant scrupuleusement les règles du standard SEPAmail.

SEPAmail met donc toujours en jeu un modèle avec au moins 4 coins

Dans les cas où seuls deux ou trois acteurs interagissent dans le dispositif SEPAmail, il y a toujours au moins 4 coins, les 4 rôles toujours mis en action:

• l'expéditeur
• le relais de l'expéditeur
• le relais du destinataire
• le destinataire 

Vocabulaire SEPAmail : l'acquittement

Qu'est-ce que l'acquittement dans SEPAmail ?

L'acquittement SEPAmail permet de mettre en place une chaîne d'accusés de réception pair à pair depuis l'expéditeur du message jusqu'au destinataire du message en passant par les relais d'acheminement (les adhérents SEPAmail).

L'accusé de réception SEPAmail est réalisé sous la forme d'une missive de type acquittement, en réponse à une missive nominale qui contient l'information initiale à transmettre.

Cet accusé possède les propriétés suivantes :

• rien ne distingue une enveloppe SEPAmail contenant une missive d'acquittement
• l'acquittement est désynchronisé de la réception, avec une garantie d'acquittement selon la priorité de l'envoi
• l'acquittement est garanti grâce à un engagement des parties, ainsi qu'un mécanisme de renvoi et d'escalade
• l'acquittement est horodaté pour la partie réception du message initial et pour son envoi
• l'acquittement garantit la vérification des signatures, la vérification de l'intégrité du message initial

Certains parlent de cet acquittement comme un acquittement technique, ce qui amène de la confusion car cela induit que c'est un accusé de type infrastructure et automate, comme ceux des protocoles réseau, ce qui n'est pas du tout le cas.

Cet acquittement est fondamental dans le protocole SEPAmail car c'est lui qui va permettre à chacun des adhérents de proposer du service à son client, notamment des services juridiques, d'huissier, de qualité, de relance automatique etc...
Cet acquittement est un acquittement non technique, automate dans la plupart des cas, et enfin fonctionnel pour le métier de messagerie électronique. Il est partagé par toutes les applications SEPAmail et fait partie des composants de sécurité de la messagerie SEPAmail.

Les comparaisons avec l'accusé de réception postal.

Le mécanisme de recommandé avec accusé/réception souffre de défauts connus :

• il faut noter le numéro de lettre recommandée sur le courrier ce qui confond la couche message et la couche enveloppe
• n'importe qui peut envoyer un recommandé au nom de quelqu'un d'autre car il n'y a pas vérification de l'identité à l'envoi
• si le recommandé n'est pas accepté, il faut envoyer une lettre simple en même temps pour garantir que le destinataire a bien reçu le courrier
• le facteur, en remettant le courrier, attend une signature pour générer l'accusé de réception, ce qui provoque une attente due à une synchronisation nécessaire pour garantir l'accusé réception et souvent une délégation de signature au service courrier
• le transporteur est en même temps relais d'acheminement pour les deux parties, sans contrat commercial clairement établi entre les parties et le transporteur

L'acquittement SEPAmail a été pensé pour dépasser tous ces défauts.
Nous y reviendrons peut-être dans un prochain billet.

Pour aller plus loin

On trouvera sur la documentation de SEPAmail:

• les règles protocolaires sur l'acquittement.
• les règles protocolaires sur le renvoi de missive nominale.

SEPAmail est une messagerie sécurisée

SEPAmail est une messagerie sécurisée, notamment car :

• elle permet d'authentifier tous les acteurs
• elle assure la confidentialité et l'intégrité des messages
• elle n'expose sur le réseau internet que des renseignements génériques, notamment elle permet la confidentialité de l'expéditeur et du destinataire du message
• elle renforce le mécanisme de l'accusé de réception

Précisons ces points.

Les acteurs du dispositif SEPAmail sont des adhérents au réseau (principalement des banques) et des utilisateurs (des clients ou des agents des adhérents).
Les utilisateurs sont tous identifiés par un identifiant SEPAmail, le QXBAN.
Ce QXBAN fera l'objet d'un billet ultérieur pour en expliquer  l'intérêt et le principe.
Les utilisateurs sont toujours authentifiés par l'adhérent. Le niveau d'authentification dépend du service et du besoin fonctionnel.
Au passage, notons que SEPAmail a permis de spécifier SAPPhire, standard simple pour l'authentification dans un cadre générique.
Les adhérents SEPAmail sont identifiés par un identifiant bancaire, le BIC.
Les adhérents SEPAmail sont mutuellement authentifiées.

La messagerie utilise entre chaque partie (émetteur, récepteur, relais) des protocoles standards de cryptographie permettant nativement des fonctions de confidentialité, intégrité et authentification.

Ne sont exposés sur le réseau IP entre deux adhérents SEPAmail que des adresses de courriel du type [ecosystem]@[BIC].sepamail.eu et une priorité, comme décrit dans la documentation.

Enfin, un protocole d'acquittement des envois complète l'organisation de la messagerie. Cet acquittement n'est pas technique. Entres autres, il ne dépend pas des infrastructures. Il fait partie de la couche métier de la messagerie. Il est désynchronisé de l'envoi, complété par un procédé de renvoi et d'escalade en cas de non retour, au cœur d'une organisation de type automate fini.