mardi 31 juillet 2012

SEPAmail et mon client de messagerie

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


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

Mon client de messagerie (Mail User Agent ou MUA) sait :
  • récupérer et transmettre un courriel à son facteur usuel (Mail Transfert Agent ou MTA)
  • chiffrer/déchiffrer un contenu au format S/MIME
  • afficher un courriel
  • stocker, classer, indexer un contenu SMTP dans un format unitaire ou globalisé
Bref, il sait lire, écrire, stocker, récupérer et transmettre pour envoi une enveloppe SEPAmail.

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


Pas grand chose à vrai dire...

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

Comment faire cela simplement ?

Je peux par exemple imaginer installer une extension qui puisse mettre en œuvre les fonction suivantes autour de la missive :
  • affichage à l'utilisateur humain de l'entête de la missive pour les champs importants :
    • horodatage
    • expéditeur
    • destinataire
    • priorité
    • type de missive
  • affichage à l'utilisateur humain du contenu de la missive selon son type
  • possibilité d'acquitter la missive nominale de façon manuelle (voire automatique) avec un code d'acquittement validant au moins la bonne distribution
Je peux aussi imaginer qu'il y ait une extension pour chaque application SEPAmail (RUBIS, GEMME, JADE, ...) qui me fournisse les fonctions suivantes :
  • affichage à l'utilisateur humain du contenu du message selon son type, sous une forme à trouver, à défaut une table de type formulaire
  • affichage des binaires contenus dans le messages sous forme de pièces jointes classiques après vérification antivirale locale
  • possibilité de mettre en œuvre le message suivant s'il existe au sein de la séquence liée à l'application SEPAmail en reprenant les informations du message précédent
En extension de norme, je peux me servir de mon adresse de courriel classique avec mon relais d'acheminement (ma banque ou l'adhérent SEPAmail qui me fournit le service SEPAmail) et il me faudra alors associer à cette adresse de courriel un biclé certifié et insérer les certificats de mon relais d'acheminement.

Quelques petits schémas pour illustrer

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

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

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

lundi 30 juillet 2012

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.

mardi 24 juillet 2012

Vocabulaire SEPAmail : l'ICQX

A partir de la version 1206, SEPAmail utilise un nouvel identifiant dénommé ICQX, pour "Identifiant Créancier QX" -- rappelons que QX est le pseudo-code pays identifiant le Scheme SEPAmail, utilisé notamment dans les QXBAN.

Voici quelques éléments répondant aux principales questions se rapportant à cet identifiant.

1. Qui peut disposer d'un ICQX ?

Toute personne morale. Toutefois, cet identifiant n'a réellement de sens que si cette personne morale intervient comme créancier dans l'une des applications de SEPAmail.
Bien que l'ICQX soit inspiré de l'ICS (Identifiant Créancier SEPA), il ne lui est aucunement relié. Il n'est d'ailleurs pas nécessaire d'avoir un ICS pour demander un ICQX, ni inversement.

2. Que contient un ICQX ?

Techniquement, c'est un identifiant de 35 caractères alphanumériques, contenant une référence au pays d'appartenance (légale) du créancier. Sémantiquement, il ne contient rien d'autre. Toutefois, en son rôle d'identifiant (cf. l'intéressant point de vue de Michel Volle à ce sujet dans un autre article), il permet d'accéder à toutes les informations significatives pour un créancier personne morale : identification de la personne morale, éléments bancaires ....

3. Comment obtenir un ICQX ?

Seul le Scheme, ou sa déclinaison locale, le QXOO, peut attribuer un ICQX. Toutefois, le créancier souhaitant en obtenir un doit obligatoirement passer par sa banque -- ou l'une de ses banques, qui jouera le rôle d'intermédiaire avec le Scheme ou le QXOO. Pour obtenir un ICQX, l'entreprise doit fournir des éléments d'identification légaux (RCS, adresse du siège ...), dont la banque a la responsabilité de vérifier l'exactitude (authentification), et qui constituent une ICQXCard.
La création de l'ICQX entraîne l'inscription du créancier dans le référentiel ICQX@SCHEME de SEPAmail, à partir duquel le Scheme fournira, à leur demande, les informations nécessaires aux membres du réseau.

4. J'ai un ICQX -- et maintenant ?

Maintenant, cet ICQX sert d'identifiant unique dans l'ensemble du système SEPAmail. Il est sûr, puisqu'il ne correspond à rien en-dehors de SEPAmail. Il est fiable, puisque votre banque a validé votre identité. Il vous permet donc de transmettre, grâce à un seul identifiant, une "carte d'identité" complète. Vous pouvez maintenant vous abonner aux services proposés par SEPAmail (inscription RUBIS, GEMME émission ...) en fournissant simplement cet ICQX. Pour chaque service, vous disposerez d'une ServiceCard, strictement interne à SEPAmail, qui servira à vous mettre en relation avec les autres utilisateurs de ce service.

5. J'ai plusieurs banques. Dois-je avoir plusieurs ICQX ? Puis-je en avoir plusieurs ?

Non. L'ICQX est unique, et vous devez donc choisir la banque par le biais de laquelle vous le demandez. Si vous changez de banque, vous devrez demander une mise à jour à la nouvelle banque.
En revanche, lorsque vous vous inscrivez à un nouveau service, vous pouvez choisir le QXBAN associé, qui peut donc ne pas correspondre à la même banque.

6. Mon ICQX est-il éternel ? Puis-je le supprimer ?

L'ICQX a une durée de validité, prévue contractuellement entre votre banque et vous. A l'issue de cette durée, il devra être prorogé, ce qui implique notamment une nouvelle vérification des éléments d'identité.
Il n'est pas possible de supprimer un ICQX. En revanche, vous pouvez désactiver tous les services associés, ce qui, dans la pratique, reviendra au même.

7. Mon ICQX va-t-il être revendu à d'autres sociétés ?

Non, l'ICQX sert uniquement de façon interne à SEPAmail, et n'a pas vocation à être fourni ou vendu à qui que ce soit.

vendredi 20 juillet 2012

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

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


L'architecture schématisée ci-dessus s'articule autour du mode canonique :
  • un composant recevant et envoyant les courriels (MTA)
  • un composant chiffrant et déchiffrant, relié à un composant d'authentification et une infrastructure à clé publique (PKI)
  • un composant SMART mettant en œuvre le protocole SEPAmail autour de la missive (décrit dans le document SMIRK MIS1101, remplacé par SMIRK MIS1202 fin juillet 2012)
La liaison avec le système d'information se fait par le SMART.
La liaison avec le reste du monde via des équipements de protection, type pare-feu.

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

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

Des liaisons facultatives sont à prévoir entre le SMART et :
  • un module d'horodatage externe et certifié si besoin
  • un module de contrôle de type juridique si besoin

 

L'information échangée de composants à composants

Dans cette architecture, l'information échangée est, tout au long de la chaîne :
  • une enveloppe SEPAmail, c'est à dire une enveloppe SMTP
    • SMIME entre le composant crypto et le reste du monde (composant MTA compris)
    • SMTP déchiffrée entre le composant crypto et le SMART
  • Et entre le SI et le SMART :
    • une missive SEPAmail, c'est à dire un flux xml au standard missive de SEPAmail.
L'enveloppe SEPAmail et la missive SEPAmail sont des blocs d'information dotés d'un entête.
On peut donc passer les arguments au sein de ces entêtes.

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

Quelques éléments de sécurité

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

Cette organisation ne remet pas en questions les règles de sécurité autour du composant MTA, notamment son emplacement et le filtrage associé au flux SMTP.
Si un responsable de la sécurité du système d'information cible désire associer des règles spécifiques au flux SEPAmail, il pourra le réaliser sans souci sur l'adresse de courriel qui est spécifique :
  • nom de domaine sepamail.eu, 
  • sous-domaine pouvant être authentifié en DKIM et soumis à des règles SPF, 
  • adresses de courriel définies et spécifiques à SEPAmail
Le mode flash est associé au mode canonique et la sécurité spécifique du transactionnel à temps court peut ainsi reposer sur quelques règles communes.

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

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

L'exploitation du dispositif

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

Les fonctions du composant SMART

Que fait donc le SMART dans cette configuration ?

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

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

mardi 10 juillet 2012

Vocabulaire SEPAmail : le QXBAN

Le qxBAN est l'identifiant de l'utilisateur SEPAmail.
Cet identifiant répond à la norme des IBANs (iso 13616) avec un code pays "QX", code pays que l'iso 3166-2 a assigné pour des usages privés.

Sa génération est décrite dans la documentation de SEPAmail. Elle est réalisée par l'adhérent SEPAmail pour le compte de son client. C'est l'adhérent qui conserve le transcodage QXBAN<->IBAN.

Le standard SEPAmail propose donc nativement de protéger l'IBAN ou les autres identifiants bancaires (PAN) en généralisant l'utilisation d'un alias qui n'est pas utilisable directement dans les circuits monétiques.
un exemple de RIS2D
image issue de la documentation
sous licence CC-BY-SA

Le qxBAN est repris dans une forme graphique, un code barre 2D de type datamatrix qui s'appelle le RIS2D (Relevé d'Identité SEPAmail 2D).

Ce RIS2D évolue pour se conformer à la norme 2D-DOC, une norme d'authentification statique des documents.

Les avantages du qxBAN

Le qxBAN présente les avantages suivants :
  • le qxBAN peut être échangé entre tous les acteurs sans risque de fraude monétique puisque le transcodage qxBAN/iBAN est toujours réalisé par le producteur du qxBAN avec une source authentifiée pour son propre usage de l'iBAN
  • il n'est pas possible de déduire un iBAN depuis un qxBAN, par construction aléatoire du qxBAN
  • le BIC est inclus dans le qxBAN, le qxBAN est donc autoporteur de toute l'information de routage.
  • le qxBAN est un identifiant international, puisqu'il n'inclut pas le pays dans sa définition
  • le qxBAN peut être lié à plusieurs comptes bancaires, voire à aucun compte si l'adhérent n'est pas une banque

Les ambiguïtés autour du qxBAN

Le qxBAN est une notion importante de SEPAmail car il permet la protection de l'IBAN qui s'expose de plus en plus avec la généralisation de SEPA.
Cependant, le qxBAN ne lève pas les ambiguïtés suivantes :
  • il ne faut pas confondre l'identifiant de l'utilisateur SEPAmail au sein du réseau SEPAmail avec la personne physique (authentifiée par les adhérents SEPAmail comme l'utilisateur SEPAmail)
    • pourra-t-il y avoir plusieurs personnes physiques ayant le droit d'utiliser un même qxBAN ?
    • pourra-t-il y avoir un qxban sans compte IBAN ou sans carte PAN associés ?
  • il ne faut surtout pas que le qxBAN, qui sera largement diffusé, soit utilisable dans un réseau de paiement tel quel ou en compensation. C'est son principe qui serait remis en question. Or, la tentation est forte pour certains qui ne veulent pas du modèle 4 coins
  • le qxBAN n'est pas un identifiant unique que l'on conserve quand on change d'adhérent SEPAmail
  • le qxBAN, dans sa forme actuelle, présente une limite d'utilisation par le nombre de qxBAN possibles par BIC. Il y a, pour chacun des BIC, 3,4x1029 possibilités pour le moment, ce qui laisse venir mais il ne faut pas que l'adhérent en profite pour générer autre chose que de l'aléatoire. Certains adhérents  ont déjà pensé générer le qxBAN par une fonction de hachage à sens unique de l'IBAN ou encore segmenter leur clientèle en réservant quelques caractères parmi ces 19 positions. Toutes ces idées vont à l'encontre du principe premier du QXBAN. C'est un identifiant ne portant aucun sens autre que le BIC.
Pour finir ce billet, citons Michel Volle qui dans son livre "de l'informatique" parle de l'identifiant en ces termes :
"Il importe [...] de définir correctement la population dont il s'agit d'identifier les individus: il ne faut pas confondre le client avec le service qui lui est rendu, avec le produit qui lui est fourni ni avec le contrat que l'on a passé avec lui. Il faut aussi construire des identifiants pérennes, qui resteront affectés à l'individu pendant tout son cycle de vie, et s'interdire de ré-utiliser un identifiant après la fin du cycle de vie. Mieux vaut enfin ne pas confondre le rôle des identifiants et le rôle des attributs: l'identifiant ne doit être porteur d'aucune information."
 Michel Volle, de l'informatique, chapitre 7, page 268.