Accueil > Actualités > Normes & sécurités > EBICS 3.0, Protocole de communication sécurisé

EBICS 3.0, Protocole de communication sécurisé

EBICS est un protocole standard interbancaire sur Internet au niveau européen, permettant de répondre aux exigences d’ouverture du marché et l’utilisation des nouveaux moyens de paiement européens, SEPA.

Pour garantir l’identité du donneur d’ordre, EBICS TS utilise les mécanismes de sécurité de signature électronique sur trois dimensions :

  • Scellement électronique de tous les fichiers échangés
  • Sécurisation du transfert
  • Identification certaine de l’émetteur

Des formations sont assurées par Cedricom pour vous permettre une bonne compréhension de ce protocole.

Le protocole EBICS 3.0

Un peu d’histoire...

Utilisé depuis 2010 en remplacement des protocoles ETEBAC 3 et 5, le protocole EBICS est devenu le standard de communication entre les entreprises et leurs Banques :

  • La version 2.4.2 est actuellement en vigueur en France
  • Désormais, l’Allemagne, la Suisse et la France ont officiellement choisi l’EBICS
  • Le Portugal a également adopté la version française de l’EBICS, sans toutefois se joindre à l’organisme EBICS

La « société EBICS » a fait évoluer les spécifications en version 3.0, avec pour objectifs annoncés :

  • L’harmonisation des versions Allemande, Française et Suisse
  • Et par voie de conséquence son expansion au reste de l’Europe
  • La mise en application de cette nouvelle version est planifiée pour le 27 novembre 2018
  • A noter que les Banques doivent maintenir une compatibilité avec la version 2.4.2, pour une durée indéterminée à ce jour

« Avec la version 3.0, la vision d’un protocole européen EBICS entièrement harmonisé devient réalité et va encore plus loin dans l’européanisation d’EBICS »

Concept du Business Transaction Format : le BTF

Le BTF est le concept d’EBICS 3.0 qui permet de décrire les caractéristiques d’une requête EBICS ainsi que son contenu.
Le concept est un mix entre les normes françaises et allemandes :

  • Française : par l’utilisation d’un orderType par sens (FUL pour l’upload / FDL pour le download) et un fileformat pour identifier le contenu des données transférées
  • Allemande : par l’utilisation d’un type de message (orderType) par type de fichier transféré



Point de vue fonctionnel

Définition des fichiers transférés

Pour rappel en EBICS 2.4 :

  • En Allemagne les transferts sont décrits à travers la notion d’« OrderType ». Chaque « OrderType » définit un sens de transfert et le format du fichier transféré.
    Plusieurs dizaines d’« OrderType » sont ainsi définis
  • En France, pour le transfert de fichiers, il n’existe que deux « OrderTypes » : le FUL (pour l’upload) et FDL (pour le download),
    complétés par des « Files Formats » décrivant le type de fichier. Chaque établissement bancaire étant libre dans le nommage des « Files Format »

Comme l’implémentation Française, la version EBICS 3.0 utilise deux « OrderTypes » (BTD pour le download et BTU pour l’upload) pour définir le sens de transfert.
La description du transfert est complétée par une description de fichier sous la forme de BTF (Business Transaction Format).
Outre une description précise et normalisée du type de fichier transféré, l’usage du BTF permet :

  • De préciser les traitements souhaités (service, option)
  • De spécifier de manière bilatérale des formats spécifiques non normalisés (scope)
  • De transférer un ensemble de fichiers dans un seul transfert (container)

Les conteneurs XML et SVC, déjà utilisés en Allemagne, permettent le transfert de plusieurs fichiers d’ordre XML au sein d’une structure XML.
Le conteneur ZIP, également utilisé en Allemagne pour les messages CAMT, permet le transfert de plusieurs fichiers dans une archive ZIP.
Le nom des fichiers contenus dans l’archive est déterminé par le standard EBICS.

Enrôlement

La version 3.0 permet désormais à un utilisateur disposant d’un certificat de signature X509, délivré par une autorité de confiance ( AC ) reconnue par l’établissement financier, d’enrôler ses trois certificats (identification, cryptage, signature) avec une seule commande (H3K), et cela sans émettre de lettre d’initialisation.

Compte rendu protocolaires

Un nouveau type de message EBICS (HAC) facilite la récupération de l’ensemble des comptes rendus de transferts associés à un PartnerId.
Les comptes rendus sont au format PSR (ISO-20022 pain.002).

Informations clients et utilisateurs

Les commandes HKD et HTD permettent de retrouver les informations des contrats EBICS pour le client ou pour un utilisateur.
En EBICS 2.4.2, dans les réponses aux commandes HKD et HTD, les transferts autorisés sont décrits uniquement par les « OrderTypes »
rendant l’utilisation de ces commandes peu pertinente pour le marché Français.
Dans la version 3.0, la description des transferts utilise les BTF et l’exploitation de ces commandes devient possible.

Signature disjointe

La signature disjointe reste facultative en France.

Point de vue technique

Schéma XSD

Les messages EBICS restent fidèles au format XML, mais le schéma XSD applicable passe de la version H003 à la version H005.

Méthode de signature

L’usage de la signature A006, basée sur la méthode EMSA-PSS recommandée par l’ANSSI, devient possible en France en complément de la version A005 basée sur la méthode EMSA-PKCS1-v1_5.

Certificats X509

Pour la gestion des bi-clés cryptographiques, l’utilisation des certificats X509 est obligatoire.
Cet usage était déjà établi en France et le gabarit des certificats reste inchangé, la migration des utilisateurs EBICS 2.4.2 Français vers la nouvelle version en sera facilitée.

Les nouveaux messages portés par EBICS 3.0

Messages de transactions

BTU : Initialisation d’envoi de fichier
L’ancien message FUL est remplacé par un nouveau message nommé BTU (Business Transaction Upload).

Messages Information Abonnement

HKD (download bank parameter) : Récupération des droits pour tous les utilisateurs d’abonnement
De par l’introduction du concept de BTF, le HKD est désormais utilisable en France :
Il permet à un abonné de récupérer les informations « contractuelle » hébergées par la banque concernant son entreprise ainsi que tous les utilisateurs associés.
La réponse de la banque contient :

  • une liste des comptes du client (Account Info)
  • les BTF et le niveau de signature attendu
  • les droits associés à chaque utilisateur

Permet potentiellement d’initialiser automatiquement le contexte de l’abonné dans son logiciel client (comptes, types de fichiers, signatures, ...)
HTD (download subscriber’s customer and subscriber information)
Identique au HKD, toutefois, l’abonné ne reçoit pas d’informations sur les autres utilisateurs de la société.

Messages de gestion des clefs

H3K
Introduit en version 2.5, ce message émet les clés publiques :

  • du certificat de signature vers le serveur,
  • du certificat d’authentification,
  • du certificat de chiffrement

Ce message permet de procéder à un enrôlement automatiquement, dans la mesure où le certificat de signature est émis par une autorité de confiance reconnue par la banque.
H3K a été introduit pour envoyer les trois certificats en une seule fois.
Grace à ce message, il n’est plus nécessaire d’envoyer les lettres d’initialisations à sa banque.
En contrepartie, ce message exige que le certificat de signature ait été émis par une autorité de confiance acceptée par le serveur
et que les informations identifiants le certificat de façon unique aient été précédemment associées à l’utilisateur.
Une fois le message traité, le profil de l’utilisateur passe automatiquement à l’état ‘READY’.
SPR : révocation des certificats clients
Ce message (SPR) permet à un utilisateur de prévenir la banque que ses certificats ne sont plus valides.
Pour cela, il envoie simplement la signature d’un fichier ne contenant qu’un caractère vide dans le message d’initialisation.
L’envoi du fichier n’est pas réalisé car sans intérêt.

Messages administratifs

HAA (download retrievable order types) : Récupère les types de fichiers reconnus sur la plateforme
L’introduction des BTF permet désormais d’utiliser pleinement en France ce message qui permet de récupérer auprès du serveur la liste des BTF pour lesquels des relevés sont disponibles.
Permet de limiter le nombre de requêtes vers le serveur, et d’automatiser la récupération des relevés uniquement lorsqu’ils sont disponibles.
HPD (download bank parameter) : Récupération des paramètres de la banque
HEV (download supported EBICS versions) : Récupération des version EBICS supportées
Pour information, il est parfaitement possible d’indiquer que le serveur supporte plusieurs versions de la norme EBICS en parallèle via l’utilisation de plusieurs nœuds ‘VersionNumber’.
Ce message permet de récupérer auprès de la banque les versions de la norme EBICS supporté par le serveur.
Ce message pouvant être envoyé avant les échanges de certificats, il ne contient aucune signature et donnée chiffrée.

Messages d’acquittement

HAC
Introduit en version 2.5, ce message récupère toutes les informations relatives à l’état des traitements des messages BTU et BTD par le serveur,
pour l’abonné courant. Lors du téléchargement de HAC.
Permet une éventuellement actualisation automatique des statuts des transferts dans le logiciel client.

Banques et Fintech : Testez vos serveurs EBICS 3.0 !

CEDRICOM propose aux Banques et Fintech un outil de test pour qualifier les serveurs EBICS 3.0.
Toutes les Banques et établissements de paiements (PSP) doivent mettre à disposition cette nouvelle version 3.0 du protocole EBICS sur leurs serveurs de communication, en parallèle de la version 2.4.
L’adoption de la nouvelle spécification EBICS 3.0, qui entre en vigueur dès le 27 Novembre 2018,
doit permettre l’interopérabilité totale des solutions des divers pays et lever un des freins au déploiement paneuropéen du protocole.
Un outil dédié aux tests des serveurs EBICS 3.0 :
Notre outil de tests EBICS 3.0 est orienté sur les tests unitaires de messages et il permet de valider les données protocolaires échangées.
Les profils (connexion, partner, BTF, …) sont sauvegardés et peuvent être réutilisés d’un test à l’autre.
Il est également possible de mixer ces données entre profils et ainsi créer des cas de figure atypiques que le serveur doit pouvoir analyser et rejeter le cas échéant.
Que ce soit pour valider la conformité des serveurs, leur comportement aux limites, vérifier leur niveau de compatibilité ou leur étendue fonctionnelle,
notre outil de tests est la solution idéale pour les phases de validation, qualification, recette et mise en production des plateformes EBICS 3.0.

Contactez-nous pour plus d’information via : commercial cedricom.com

De la technique

Encore de la technique...