jeudi 28 juin 2012

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.

jeudi 21 juin 2012

Application SEPAmail : RUBIS

RUBIS permet pour un utilisateur de SEPAmail d'envoyer une demande de règlement à un autre utilisateur SEPAmail.
Ces utilisateurs sont appelés demandeur et interlocuteur payeur.
RUBIS permet aussi au payeur de répondre "oui", "non", "oui mais", voire de ne rien répondre.

Qu'est-ce qu'une demande de règlement ?

Assez simplement, on peut résumer la demande de règlement à :
  • une requête
  • pour être payé
  • de la part de quelqu'un
  • une somme d'argent définie
  • dans une devise précise
  • à une date définie
Il y a un message iso 20022 pour réaliser ce genre de demande, le pain.013.
Il permet de préciser et de typer ce que sont les dates, les devises, le moyen de paiement demandé.

Comment évite-t-on les demandes non sollicitées ?

Cela est un vrai problème et cela dépend du contexte et du demandeur.
SEPAmail prévient et prévoit ces cas.

Supposons que le demandeur est un créancier de particuliers. Il s'inscrit dans l'annuaire RUBIS, diffusé entre les adhérents.
Dans ce cas, le particulier peut choisir d'autoriser ou non le créancier à lui envoyer des demandes de règlement au travers de SEPAmail. Il utilise pour cela un message spécifique de SEPAmail ActivationEnroll.

Selon les adhérents, les règles utilisées pour ne pas importuner leur client avec des messages sans autorisation préalable seront différentes. Certains ont prévu d'avertir qu'il y a une demande de règlement de la part d'un nouveau créancier enregistré dans l'annuaire. D'autres ont prévu de ne pas distribuer le message. Enfin, certains préfèrent implémenter un système de opt-in opt-out extensible à toute paire d'interlocuteurs.
Supposons que le demandeur soit un particulier qui fasse des demandes non sollicitées, alors, comme il authentifié, il pourra être bloqué par sa banque sur déclaration d'abus.

Les principes sont assez simples :
  • pour s'échanger un premier message, il faut demander d'abord à l'autre et être deux d'accord pour l'échange. Il y a donc une phase préalable d'inscription ou de connexion (enroll).
  • il n'est pas nécessaire de demander avant chaque échange car, après acceptation initiale, les deux interlocuteurs sont considérés comme d'accord ou connectés, tant que l'un des deux ne demande pas l'arrêt.
  • pour ne plus recevoir de message de l'autre partie, il faut l'expliciter par un message de déconnexion (enroll)

Ainsi, on est bien sur un fonctionnement optin/optout classique, sachant qu'il y authentification de toutes les parties et entente entre les adhérents pour ne pas relayer les messages SEPAmail non sollicités de part et d'autre.

Est-on obligé de répondre à une demande de règlement ?

L'interlocuteur payeur n'est pas obligé de répondre au demandeur.
Sa seule obligation est la suivante:
  • s'il a répondu OUI
  • puis qu'il ne peut ou ne veut honorer le règlement,
  • il ne peut empêcher l'adhérent SEPAmail dont il le client de diffuser l'information du non règlement (notamment en arguant du secret bancaire ou de son contrat)

Si on répond oui à une demande de règlement, que se passe-t-il ?

Si on répond OUI à une demande de règlement, alors, selon le contrat passé entre l'adhérent et son client, l'adhérent peut enclencher un paiement, comme un virement, un paiement par carte ou tout autre dispositif contractuel.
Mais il n'est pas obligé de le faire.
Dans l'absolu, RUBIS peut déboucher sur un paiement par chèque de la part de l'utilisateur.

mercredi 20 juin 2012

Le logo SEPAmail

Le logotype SEPAmail a été inventé par:
  • Cyril Vignet, l'inventeur du concept SEPAmail
  • Gaelle YOLLANT, graphiste créatrice

On le voit sur cet espace : http://sepamail.eu/.

Il comporte plusieurs parties :
  • une enveloppe (couleur taupe) en train d'être insérée dans une boîte
  • 12 étoiles (couleur jaune) disposées en ellipse autour de l'enveloppe
  • la mention SEPA en majuscule (couleur rouge)
  • suivi de la mention mail en minuscule (couleur taupe)

Interprétation

L'enveloppe symbolise le courrier, cœur de métier de SEPAmail.
Les étoiles représentent la vocation européenne de SEPAmail.
La disposition des étoiles autour de la messagerie rappelle ces logos internet des navigateurs.
L'ensemble "étoiles et enveloppe" constitue la partie graphique reprise dans les icônes, notamment l’icône favorite pour les navigateurs.

SEPA étant un acronyme, il est normal de le conserver en majuscule.
SEPAmail traitant de messages autour du paiement, il est logique de mettre en valeur le SEPA qui devient le quotidien européen du paiement.
Conformément à la nétiquette, la mention au mail (le nom anglais du courriel électronique mais aussi du courrier physique) reste en minuscule puisqu'il s'agit d'un mot commun.

On trouve ci-dessous les couleurs primaires et secondaires de SEPAmail proposées par Gaëlle YOLLANT. Les couleurs sont acidulées/pastels afin de suggérer la sérénité qu'apporte la solution SEPAmail à ses utilisateurs.

Couleurs primaires :
  • rvb(177,17,22) ou #b11116, rouge
  • rvb(141,125,116) ou #8d7d74, gris
  • rvb(88,29,116) ou #581d74, violet
  • rvb(211,203,197) ou #d3cbc5, taupe
  • rvb(244,121,32) ou #f47920, orange
  • rvb(189,207,65) ou #bdcf41, vert
Couleurs secondaires :
  • rvb(230,225,222) ou #e6e1de
  • rvb(0,178,203) ou #00b2cb
  • rvb(167,120,174) ou #a778ae
  • rvb(176,0,108) ou #b0006c


Le logotype est déposé, ainsi que la marque (référence inpi).

lundi 18 juin 2012

SEPAmail est une messagerie orientée paiement

Le dispositif SEPAmail est orienté paiement documentaire.
Il permet à deux entités économiques :
  • de s'échanger des documents autour du paiement (devis, facture, demande de règlement, avis de virement, avis de remboursement...)
  • de demander explicitement ou implicitement à sa banque d'enclencher automatiquement un paiement (virement, paiement carte, prélèvement si mandat) 
Nous retrouvons cette orientation avec la plupart des applications SEPAmail : RUBIS, JADE, GEMME, DIAMOND, IOLITE.
Cependant, SEPAmail permet aussi de n'échanger que du document, comme avec JASPE ou AGATE.
Dans ce cas, la banque apporte comme valeur ajoutée son articulation de confiance et son plan d'adressage européen.

Il est donc possible qu'une entité non bancaire devienne adhérent SEPAmail.
Pour cela, il faudrait que l'entité dispose  :
  • de canaux avec ses clients permettant une authentification du niveau minimal demandé par SEPAmail
  • d'un BIC pour pouvoir correspondre avec les autres adhérents SEPAmail
  • d'une infrastructure lui permettant de se connecter au réseau d'adhérents SEPAmail
L'entité pourrait alors opérer facilement des applications non orientées paiement.

Foire aux question n°1

Voici quelques unes des questions qui reviennent souvent dans un premier billet sur ce sujet.

Est-ce SEPAmail est un nouveau moyen de paiement?

Je n'envisage pas SEPAmail comme un nouveau moyen de paiement, mais comme une organisation qui permet peut-être à de nouveaux moyens de paiement d'exister.
Par organisation, j'entends :
  • rédaction d'un standard, 
  • animation d'une communauté,
  • création d'un canal de messagerie au sein de l'espace de confiance entre les banques
SEPAmail permet de s'échanger de l'information autour (avant et après) le paiement.
Par exemple:
  • j'envoie des factures (IOLITE) puis une demande de règlement en fin de mois (RUBIS),
  • j'envoie un avis de remboursement (JADE) qui enclenche directement un virement,
  • j'envoie un contrat à signer (JASPE) puis les demandes de règlements (RUBIS)
  • je vérifie les identifiants bancaires de mon client (DIAMOND) puis lui envoie une demande d'autorisation de mandat de prélèvement (GEMME) et des notifications de prélèvement (GEMME)
SEPAmail traite donc plus particulièrement de dématérialisation et d'automatisation autour du paiement documentaire.

Est-ce le service RUBIS initie forcément un virement?

Non.

L'application SEPAmail RUBIS permet d'envoyer une demande de règlement à sa contrepartie qui peut l'accepter, le refuser ou ne rien faire. Selon le service contracté par la contrepartie avec sa banque, l'acceptation peut enclencher un paiement par virement, par carte ou autre.

En quoi ma banque est-elle en capacité de sécuriser mes messages?

Le réseau inter-bancaire présente des avantages :
  • il s'est doté depuis longtemps d'un espace de confiance entre la plupart des banques dans le monde entier
  • il possède un plan d'adressage européen (de fait mondial) des entités économiques ayant un compte, à savoir le couple IBAN@BIC
  • voir les flux d'information autour des paiements permet d'offrir le service d'automatisation de l'enclenchement du paiement ainsi que des services de vérification, validation des coordonnées de la contrepartie
  • le réseau interbancaire est en mesure de proposer un alias de l'IBAN qui ne puisse pas passer en compensation et donc permettre de doter les entités économiques d'un numéro de compte pour la seule transmission d'information. Dans SEPAmail, l'alias de l'IBAN est le QXBAN
SEPAmail propose même avec l'application AGATE de pouvoir échanger des flux qui ne seront pas regardé par les banques. Elles ne feront alors fonction que de relais d'acheminement sécurisé.

Pourquoi un adressage lié à mes coordonnées bancaires?

L'adressage pour s'envoyer des messages SEPAmail est lié à un IBAN et un BIC, c'est à dire un identifiant de compte et un identifiant de banque.
C'est assez pratique et assez universel.
SEPAmail propose un alias de l'IBAN, le QXBAN afin d'éviter de passer son IBAN à tout le monde. Le QXBAN ne peut pas passer en compensation dans les circuits autres que SEPAmail (il faudra garantir cette propriété dans le temps, car il y aura toujours à un moment une envie d'utiliser cet identifiant pour une autre portée que le réseau SEPAmail).
Le QXBAN est généré selon un algorithme qui garantit :
  • que le BIC est contenu dans le QXBAN
  • que l'on ne peut pas déduire l'IBAN du QXBAN
Enfin, le modèle 4 coins utilisé dans tous les cas par SEPAmail garantit que la conversion QXBAN->IBAN est toujours réalisée par la banque émettant l'IBAN et le QXBAN.

vendredi 15 juin 2012

SEPAmail est une messagerie articulée

Les banques disposent de réels atouts pour participer à une messagerie

Les  entités économiques ont des canaux avec leurs banques permettant l'échange d'information avec un excellent degré de confiance.
Entre elles, les banques disposent également de possibilités d'échange d'information avec un excellent degré de confiance.

Si deux entités économiques ne disposent pas d'un canal de confiance entre elles, alors le dispositif SEPAmail permet de le faire en articulant les canaux existants de confiance. La messagerie profite ainsi des bienfaits du modèle 4 coins, que nous avons déjà évoqué.

L'articulation autour d'un relais d'acheminement


Les banques jouent un rôle de relais d'acheminement de messagerie, une véritable articulation permettant des fonctions difficiles à réunir par les entités économiques elles-même.
En effet, ces articulations permettent :
  • de joindre des espaces de confiance
  • de joindre des canaux de messagerie de nature différente, permettant le multi-canal
  • de faire transiter une information dans un espace contractuel permanent
  • de voir les flux transiter et d'apporter de la valeur ajoutée sur ces flux (sécurité, vérification, validation, structuration, enrichissement, stockage, réponse sous mandat)

mercredi 13 juin 2012

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.

mardi 12 juin 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.

vendredi 8 juin 2012

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 : la missive nominale

La missive


Une missive SEPAmail est un contenant regroupant un message et des propriétés d'adressage et de priorité au sein du réseau des utilisateurs SEPAmail, comme précisé dans un précédent billet.
Cette couche intermédiaire entre l'enveloppe et le message permet de rendre confidentielles ces propriétés et de ne conserver sur l'enveloppe que les seules informations nécessaire au bon acheminement sur le réseau IP de l'ensemble {enveloppe>missive>message}

La missive nominale

Une missive est dite nominale lorsqu'elle transporte un message émis par un utilisateur SEPAmail destiné à un autre utilisateur SEPAmail (ou lui-même).

Le cœur de métier du dispositif SEPAmail est donc de transporter ces missives nominales.

Pourquoi distinguer des missives nominales ?

Si on veut garantir la bonne distribution d'un message, il faut que le destinataire puisse accuser de façon certaine la bonne réception et sa capacité à traiter le message.
Il faut donc un mécanisme pour distinguer le message initial et l'accusé de réception afin d'appliquer les bonnes règles (priorité, émission, réception, contrôle).

Comment cela fonctionne ?

La missive est structurée en xml, ce qui permet:
  • en exploitation une validation rapide et simple
  • une évolution plus facile et la possibilité de gérer plusieurs versions
La missive est orientée adressage et routage dans le réseau (privé) SEPAmail.
Elle est exclusivement dédiée à ces fonctions.

Le type nominal de la missive signifie qu'elle contient un message à relayer.

Les autres missives

Il y a dans la norme d'autres types de missives:
  • la missive d'acquittement, permettant l'acquittement des missives nominales
  • la missive de service, permettant d'encapsuler un dialogue client/serveur dans l'espace de confiance de l'adhérent avec son utilisateur
  • la missive d'interfaçage (SMAPI), permettant d'encapsuler des accesseurs/constructeurs API avec un SMart ou un SMile

mercredi 6 juin 2012

Vocabulaire SEPAmail : SMART et SMILE

SMART

SMART est l'acronyme de SepaMail Acknowledgment, Routing and Transfer.

Il s'agit du nom de code d'un composant que chaque adhérent SEPAmail met en œuvre au sein de son système d'information afin de pouvoir échanger des messages/missives/enveloppes SEPAmail selon le protocole SEPAmail.

Ce composant s'occupe de l'acheminement (transmission en émission et réception) des messages SEPAmail au sein de missives nominales ainsi que du bon acquittement de ces missives nominales.

le SMART dans le réseau des adhérents SEPAmail
La documentation propose ce schéma d'architecture (licence creatives commons)

C'est lui qui met en œuvre (ou délègue) les fonctions suivantes du protocole entre les adhérents :
  • vérifications en réception  ecosystem, adresse, signature, adressage, intégrité, xml, typage du contenu...
  • authentification du pair
  • déchiffrement, chiffrement
  • acquittement des missives nominales
  • renvoi des missives si non acquittement dans les temps impartis et escalade si nécessaire
  • transmission des messages au SI
  • génération des missives
  • génération/émission des enveloppes (délégation conseillée)
  • envoi/réception sur le réseau IP (délégation conseillée à un MTA)
  • horodatage (délégation conseillée)
  • journalisation (délégation conseillée)
Il existe actuellement une implémentation logicielle de SMART, utilisé pour l'expérimentation, éditée par la société StreamMind. Le logiciel s'appelle SEPAplug®; il embarque d'autres fonctions que celles du SMART et il est utilisé dans un contexte plus large au sein du système d'information pour la plupart des adhérents de l'expérimentation.

On peut imaginer que d'autres implémentations de SMART vont voir le jour, soit développées directement par les directions d'études des adhérents, soit par des éditeurs externes.

Une implémentation (de référence ?) pourrait également être développée autour de serveurs d'échange de courriel (Mail Transfert Agent) du marché comme MS Exchange ou VMWare Zimbra.

SMILE

SMILE est un acronyme à trouver.
Je relate dans ce billet sur le SMIRK l'idée de baptiser des composants fonctionnels de cette manière mais je ne connais pas encore la signification de cet acronyme et il n'y a rien dans la documentation sur ce sujet à ce jour.
On peut imaginer le I d'Interface et le E d'Enterprise... reste le L ?

L'idée était de réserver le sourire pour les clients des adhérents SEPAmail, les gros utilisateurs.

SMILE est un composant similaire au SMART dans ces fonctions mais il est orienté extension de la norme dans l'espace entre l'adhérent et son client, l'utilisateur final SEPAmail qui a souscrit un service utilisant SEPAmail.

SMILE diffère dans son implémentation du SMART pour la partie authentification du pair car l'authentification d'un utilisateur dépend de l'adhérent et du canal avec son client.
SEPAmail propose une simplification partagée utilisant elle-même le dispositif de messagerie SEPAmail autour du sujet de l'authentification: SAPPhire.
SAPPhire fera l'objet d'un prochain billet.
Il existe actuellement une implémentation logicielle de SMILE, utilisé pour l'expérimentation. Il s'agit également du logiciel SEPAplug®.

Pour aller plus loin

lundi 4 juin 2012

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:

vendredi 1 juin 2012

SEPAmail est une messagerie structurée

La messagerie électronique a changé la façon de communiquer dans l'entreprise.
D'aucuns lui voient un avenir sombre car il y aurait "trop de messages, trop de messages illisibles, trop de messages moches" (marc herbert).


Le dispositif SEPAmail diffère d'une messagerie classique par la structuration imposée:
  • structuration du contenu du message (le signifiant), qui doit se conformer à un schéma prédéfini (schémas XML)
  • structuration du type de message, qui doit appartenir à une liste prédéfinie
  • structuration de la séquence de messages, qui est définie au travers de règles métier (directives d'implémentation)
  • structuration de la partition des messages en écosystèmes
  • structuration de la séquence d'échange des missives avec son mécanisme d'acquittement (accusé de réception SEPAmail)

SEPAmail profite donc des qualités de la messagerie électronique (rapidité, simplicité, coût, ergonomie, usage répandu) tout en structurant les échanges pour y ajouter des possibilités d'automatisation, de dématérialisation, de sécurité.

On peut voir SEPAmail comme une messagerie structurée authentifiant tous les acteurs (relais et utilisateurs) autour d'un signifiant métier fondé sur l'iso 20022.