EBICS - Guide de mise en uvre en France (Implementation Guidelines)

Version 1.2 Mise en cohrence avec la version 2.4.1 des spcifications

AVIS AU LECTEUR

La documentation relative au protocole EBICS, conue dans sa version initiale par le ZKA (quivalent allemand du CFONB) a t rdige en allemand puis traduite en anglais. Sa version 2.4 constitue la premire version commune Franco-Allemande. Une mise jour V2.4.1 a t publie en septembre 2009. Nanmoins la mise en uvre dEBICS en France doit tre adapte au contexte national (migration des ETEBAC, instruments de paiements nationaux,.). Le CFONB a labor ce guide dimplmentation dEBICS en France, pour les raisons suivantes : 1. afin dassurer le remplacement progressif des protocoles ETEBAC 3 (phase 1) puis 5 (phase 2), il convenait de prendre en compte, pour donner le maximum de souplesse cette migration, les habitudes dutilisation des entreprises franaises en matire de transfert de fichiers, 2. pour le remplacement dETEBAC 3, des adaptations taient ncessaires par rapport aux fonctionnalits offertes par le protocole en matire de scurit de transport, 3. la liste des commandes figurant dans le protocole comprend bien videmment les commandes utilises dans les contextes allemands et franais. Ce guide identifie avec prcision le sous-ensemble recommand pour les commandes utilises en France, 4. le protocole EBICS est en particulier destin lacheminement dinstructions de paiements europens (SEPA) mais aussi nationaux (VO, LCR,..) ainsi que des restitutions clientles (extraits de comptes,..). La description de leur paramtrage tait ncessaire. Il peut galement tre employ pour dautres usages bancaires.

Nota : Afin de faciliter leur actualisation et le chargement par les diteurs, les listes de donnes suivantes ne figurent pas en annexe de ce document mais sont disponibles en tant que documents distincts sur le site du CFONB : www.cfonb.org dans la mme rubrique que ce guide dimplmentation (Documentation : Migration ETEBAC vers EBICS et SWIFTNet): Annexe A2 dans son intgralit : FileFormat/Request Type Nommage des fichiers Annexe A3.1 :Liste des messages derreurs lis aux certificats

EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 1 sur 27

TABLEAU DEVOLUTIONS
Version VO 1.0 VF 1.1 Date 12/2/2009 Mai 2009 Chapitre Tous Type1 C Description des volutions Cration du document La dnomination Signature Bancaire est remplac par Ordre dExcution . La dnomination Fichier Mtier est replace par Remise dOrdre . Insertion des rponses aux questions reues de la FAQ Prcisions sur linitialisation des paramtres scuritaires et le calcul la signature du A006 Test : prcision sur le format du paramtre TEST Echanges de flux : restructuration du chapitre Modalits dutilisation du poste client : mise en conformit avec le contrat type Afin de faciliter la mise jour, ces documents sont extraits des IG et publis sur le site du CFONB. Mise en cohrence avec la version 2.4.1 des spcifications Complmentarit des phases Codage ASCII / EBCDIC Le PSR est mis disposition et non pas envoy Remarque : Calcul de la signature : Prcisions suite aux rponses donnes des questions Cas des prestataires de services Nommage des fichiers : ajout du PSR de niveau protocolaire (type pain.002.001.02.ack) Format du Payment Status Report

Tous 2.1.1.1 et 2.1.1.2 2.1.4 2.2 3 Annexe 2 VF 1.2 9/2009 Tous 1.1 1.2.5 Tous 2.1.2.2 2.1.4 A2 A.5

C C C C C M

C A C C C A A/M

E : Erreur ; M : modification ; C : Clarification ; S : suppression ; A : Ajout/Extension

EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 2 sur 27

Sommaire du guide de mise en uvre

1. INTRODUCTION ......................................................................................................................4

1.1. 1.2.

Objet et primtre du guide................................................................................................ 4 Rgles communautaires dimplmentation ........................................................................ 6 1.2.1. Multi-bancarit des postes clients : ......................................................................... 6 1.2.2. Les modalits dimplmentation : ........................................................................... 6 1.2.3. Scurisation des changes : ..................................................................................... 6 1.2.4. Les caractres spcifiques : ..................................................................................... 6 1.2.5. Codage ASCII / EBCDIC : ..................................................................................... 7

2.

IMPLEMENTATION .................................................................................................................8

Initialisation........................................................................................................................ 8 2.1.1. Schma gnral de linitialisation des paramtres scuritaires ............................... 8 2.1.2. Initialisation des paramtres scuritaires................................................................. 9 2.1.3. Initialisation des identifiants ................................................................................. 11 2.1.4. Prestataires de services.......................................................................................... 11 2.1.5. Tests ...................................................................................................................... 12 2.2. Echanges de flux .............................................................................................................. 13 2.2.1. Paramtrages lis aux flux..................................................................................... 13 2.2.2. Traitement des remises dordres ........................................................................... 13 2.2.2.1. Liste des contrles en pr-validation..................................................................... 13 2.2.2.2. Contrles de scurit des fichiers de remise dordres ........................................... 13 2.2.2.3. Information client sur la rception du fichier de remise dordres ......................... 14 2.2.3. Rcupration des fichiers clients : la commande Download (FDL) ..................... 15
3. 4. MODALITES DUTILISATION DU POSTE CLIENT..............................................................16 ANNEXES ..............................................................................................................................17

2.1.

A.1 Order Type ............................................................................................................................ 17 A.2 FileFormat/Request Type Nommage des fichiers .............................................................. 18 A.3 Certificats .............................................................................................................................. 18 A.3.1 Messages derreurs lies aux certificats ..................................................................... 18 A.3.2 Gabarit certificats porteurs EBICS ............................................................................. 18 A.3.3 Gabarit certificats serveurs EBICS............................................................................. 20 A.4 Format imprimable du certificat............................................................................................ 21 A.5 Format du Payment Status Report......................................................................................... 24 A.6 Exemple de calcul de Hash ................................................................................................... 26 A7 - Glossaire............................................................................................................................... 27

EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 3 sur 27

1. INTRODUCTION
1.1. Objet et primtre du guide
Ce guide dimplmentation est destin aux dveloppeurs des postes clients et des serveurs EBICS. Il ne sagit pas dun manuel utilisateur destin aux clients. Il a pour but principal de prciser les modalits et paramtres dimplmentation. Il est de la responsabilit des fournisseurs de logiciel de prvoir un manuel utilisateur. Ce manuel utilisateur devra contenir notamment la liste des codes retours EBICS ainsi que les codes retours spcifiques au logiciel avec pour chacun un libell explicite. Ce guide dimplmentation est un complment de la documentation EBICS : Les spcifications gnrales Version 2.4.1 (en Allemand ou traduites en anglais) Le guide dimplmentation Version 1.7 (en Allemand ou traduit en anglais). La lecture de cette documentation est un pralable ncessaire la bonne comprhension de ce prsent guide. Ce guide sappuie sur la version 2.4.1 codifie H003 dans les messages - dEBICS commune la France et lAllemagne et qui sera implmente dans les deux pays partir de lautomne 2009. En cible, lutilisation du protocole EBICS, sera identique en France et en Allemagne. Cependant compte-tenu de lexistant des deux pays, les modalits dimplmentation de cette version pourront tre lgrement diffrentes dun pays lautre. De plus, lutilisation de certaines fonctionnalits optionnelles tant du domaine concurrentiel, il est de la responsabilit de lutilisateur de sassurer du niveau de service offert par ses tablissements bancaires et de paramtrer en fonction le logiciel. Le primtre de ce guide CFONB est limit aux changes de flux entre postes clients localiss en France et serveurs de banques localises en France. Le choix de lextension aux changes transfrontaliers du poste client et/ou du serveur est du ressort des diteurs de logiciels ou des banques2. Ce guide est plus particulirement destin dcrire les paramtrages des postes clients mais il donne galement des recommandations pour le paramtrage des serveurs bancaires. Limplmentation devra respecter les prconisations et rglementations existantes, notamment celles relatives aux services bancaires et/ou financiers sur Internet (SBFI) (voir site : www.ssi.gouv.fr/site_documents/pp/ppcr0401.pdf). La mise en place en France du protocole EBICS est prvue en trois phases : Phase 1 : Le remplacement dETEBAC 3, Phase 2 : Le remplacement dETEBAC 5, Phase 3 : Lutilisation de la signature disjointe au travers du protocole EBICS. Les phases correspondent aux dates de disponibilit des solutions EBICS. Les solutions ne se remplacent pas mais sajoutent. Il y aura donc simultanment, dabord des clients en phase 1 (signature disjointe) puis en phase 1 et 2 (signature jointe) puis dans les 3 phases. En aucun cas une nouvelle phase ne vient se substituer une phase prcdente Cette version du guide dcrit exclusivement les modalits dimplmentation dans le cadre de la phase 1 (remplacement dETEBAC 3).
2

Le terme banque utilis dans ce document doit tre entendu comme Prestataire de Services de paiement (PSP) au sens de la directive 2007/064/CE sur les services de paiements du 17 novembre 2007, transpose dans lordonnance 2009-866 du 15 juillet 2009.

EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 4 sur 27

Utilisation dEBICS dans le cadre du remplacement ETEBAC 3 Dans ce cas prcis, mme si le protocole EBICS permet lacheminement dune signature de lordre de faon disjointe, ce principe ne sera pas abord dans ce guide pour la phase 1 (remplacement ETEBAC 3). La confirmation de lordre sera transmise de faon disjointe par le canal habituel ou prconis par la banque (Ex : portail internet de ltablissement bancaire) en privilgiant les moyens de communication lectronique.

EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 5 sur 27

1.2. Rgles communautaires dimplmentation

1.2.1. Multi-bancarit des postes clients : Chaque poste client doit pouvoir se connecter divers serveurs bancaires respectant les prconisations de ce guide. Il devra tre possible de rajouter ou de supprimer une connexion bancaire sur un poste install.

1.2.2. Les modalits dimplmentation :

Elles peuvent tre de deux natures : Soit lies aux recommandations interbancaires franaises, Soit lies loffre de service dun ou plusieurs tablissements bancaires. Les recommandations interbancaires franaises concernent principalement : Les commandes utilises (Order type voir annexe A1) Le nommage des fichiers (FileFormat/Request Type voir annexe A2) Pour limiter la liste des commandes, il ny a pas autant de commandes que de types de fichiers (contrairement limplmentation en Allemagne), mais le type de fichier est une valeur de lun des paramtres (File format/request type) de la commande. Les offres de services bancaires peuvent porter sur : Les contrles complmentaires effectuer par le protocole sur les donnes bancaires (ex : contrle du montant ou du compte), Les niveaux spcifiques de scurit, Les types de fichiers propritaires, Les flux dinformations propritaires, Les choix bancaires de rendre obligatoire ou dinterdire un paramtrage optionnel La profondeur de lhistorique des fichiers mis disposition sur le serveur Les modalits de rcupration de ces fichiers par le client. Les modalits spcifiques lies des offres bancaires ne sont pas couvertes par ce guide. Afin de pouvoir paramtrer linstallation, chaque banque doit fournir au pralable son client les informations dcrivant son abonnement.

1.2.3. Scurisation des changes :

Le prsent guide ne couvre que la phase 1 et donc uniquement la signature des donnes transportes appel scellement. Il ne couvre pas lordre dexcution (quil soit joint ou disjoint du fichier de remise dordres ou des donnes transportes). Nota : lordre dexcution peut galement tre appel signature bancaire ou personnelle. Par consquent, les fonctionnalits de VEU (voir spcifications EBICS 11.2.3 et 12.3) correspondants lordre dexcution lectronique disjoint ne seront pas abordes dans ce guide dcrivant la phase 1 (remplacement dETEBAC3) dans le cadre dchanges de flux avec des serveurs de banques franaises tels que dfinis par le CFONB. Le paramtre correspondant cette notion est la classe de signature des utilisateurs codifie T (Transport), par dfaut, pour tous les types de formats changs en France pour la phase 1 (remplacement ETEBAC3).

1.2.4. Les caractres spcifiques :

Les caractres autoriss sont dfinis par le schma XSD ; les caractres spcifiques utiliss au niveau de lchange protocolaire en France ou en Allemagne (par exemple , , , , , , , ) sont exclus par le schma XSD. Dans les fichiers, les caractres utiliser sont ceux dfinis dans les standards.

EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 6 sur 27

1.2.5. Codage ASCII / EBCDIC :

Il est recommand que les fichiers changs soient en ASCII. Si la banque le propose, pour lenvoi de fichiers en EBCDIC, lindication EBCDIC doit figurer dans les balises FULOrderParams sur le modle suivant :

<FULOrderParams> <Parameter> <Name>EBCDIC</Name> <Value>TRUE</Value> </Parameter> <FileFormat CountryCode="FR">pain.xxx.cfonb160.dct</FileFormat>

</FULOrderParams>

EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 7 sur 27

2. IMPLEMENTATION 2.1. Initialisation

2.1.1. Schma gnral de linitialisation des paramtres scuritaires

Entreprise

Contrat

Enregistrement du contrat Client. Production des Identifiants Client : HostId, UserId, PartnerId. Enregistrement des Identifiants Client et URL Banque. Production des cls Client, impression et envoi par courrier Initialisation EBICS Envoi des 3 certificats : Authentification, Chiffrement et Signature par commandes INI/HIA

Saisie des cls Client, enregistrement sur le Host Banque

Tlchargement des Certificats Banques par commande HPB Enregistrement des Certificats Banque dans la base Banques du poste Client. Tests, Dbut des remises Client.

EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 8 sur 27

2.1.2. Initialisation des paramtres scuritaires

2.1.2.1. Les certificats Les changes de flux avec les serveurs des banques franaises dfinis par le CFONB sont bass sur lutilisation de certificats lectroniques X509 permettant la garantie de lintgrit en phase 1 et lordre dexcution en phase 2. Les caractristiques dtailles de ces certificats (gabarit) sont dcrites en annexe A3. La sparation des usages (Authentification, Chiffrement et Signature (scellement en phase 1, bancaire en phase 2)) est obligatoire, ce seront donc 3 cls (une pour chacun des usages) qui seront utilises par le poste client (et par le serveur de la banque). De plus, les changes sont assurs au travers dune connexion Http/s (couche TLS) base sur lutilisation dun certificat serveur qui devra tre rcupr et accept par le poste client pralablement tout change protocolaire. Les spcifications EBICS v2.4 prvoient que la signature protocolaire peut tre de classe Transport T , Bancaire unique E ou Bancaire Multiple A&B, respectivement 1re et 2nd signature . La prsente version du Guide dImplmentation, concernant la phase 1, naborde que la classe de signature de transport T . La phase 2 implmentera les autres classes de signature. La version EBICS v2.4 supporte les versions de la signature lectronique codifies A004, A005 ou A006. Mais la version A004 de la signature ne sera pas utilise en France car elle nest pas compatible avec lutilisation des certificats, donc seules les versions A005 et A006 seront utilises en France. La version A005 de la signature est prconise car compatible dans les 2 phases de la migration ETEBAC Lutilisation de la signature A006 nest pas recommande pour des problmes de disponibilit actuelle des supports hardware ncessaires pour la phase 2. En version A005 et A006 (chiffrement E002), cest lalgorithme de chiffrement AES qui est retenu. 2.1.2.2. Remarque : Calcul de la signature Les caractres systmes tels que (CR, LF and Ctrl-Z) ne sont pas inclus dans le calcul du hash dans les versions A005 et A006. Avec A006, il y a un double calcul de hash3, la signature nest pas calcule sur le message luimme ; donc explicitement Si(Hash(M)) ; mais sur le hash du message ; donc explicitement Si(Hash(Hash(M)). La signature sapplique sur le tag SignedInfo pass la canonisation C14N puis la canonisation est hache. Il faut hasher le certificat pralablement encod au format DER - sans les caractres (CR, LF CTRL-Z) Les 2 paddings suivants peuvent tre utiliss : . ANSIX923 The ANSIX923 padding string consists of a sequence of bytes filled with zeros before the length. . ISO10126 The ISO10126 padding string consists of random data before the length. La dtection du mode de padding se fait en constatant le type de padding : des zros ou des donnes alatoires. Il convient dutiliser PKCS1 V1.5 pour chiffrer la cl de chiffrement La canonisation doit ajouter les valeurs par dfaut. Dans un document XML, seuls les namespaces utiliss dans le document XML doivent tre indiqus. Les autres namespaces ne doivent pas tre indiqus. Le lien pour la canonisation est :
http://www.ebics-zka.de/english/document/pdf/Anhang%201%20des%20IG%20_%20Beispiel%20Kanonisierung%20Hashwerte.zip

LXML/DSIG distingue entre documents XML avec ou sans commentaires. Dans EBICS : the algorithm for cononicalizaltion is defined via http://www.w3.org/2006/12/xml-c14n11. This is the algorithm, where the XML-comments are erased. The identifier for the algorithm which doen not erase the comments would be http://www.w3.org/2006/12/xml-c14n11#WithComments

Voir lexplication des motifs dans la FAQ 9/10/2009 Page 9 sur 27

EBICS IG CFONB VF 1.2 .doc

2.1.2.3. Initialisation des certificats clients et envoi des cls publiques au serveur banque Il est ncessaire pour le serveur banque de disposer des trois cls publiques du poste client, une par usage (authentification, chiffrement et scellement en phase1). Chaque cl publique est stocke dans un certificat gnr (auto-sign) sur le poste client ou import. Chacun des 3 certificats correspondant aux trois types de cls est transmis au serveur dans un fichier dinitialisation via le protocole EBICS, selon le schma XSD dEBICS v2.4. Une procdure de validation est ncessaire pour la banque pour contrler lauthentification de lmetteur de chacun de ces 3 certificats. En phase 1, lutilisation dun certificat auto-sign ne permet pas ce contrle par la chane de certification. Lauthentification doit donc tre assure par un second mcanisme externe au fichier dinitialisation gnr sur le poste client. Ceci est ralis par lenvoi la banque, en parallle de celui du certificat via EBICS, dun document de confirmation par un autre canal (impression et envoi dun pdf par courrier, fax, tlchargement ). Le choix du canal est hors primtre de ce guide mais doit tre prcis dans le contrat client entreprise/banque. En France, lenvoi de trois documents : un document par certificats, est obligatoire. Cette authentification peut tre faite par signature manuelle du client sur la version imprime du fichier dinitialisation (voir annexe A4 format imprimable du certificat). Ce document comprend le certificat intgrable4, ainsi que les informations didentification de lutilisateur (user ID, partner ID, et ventuellement UserName) et du sceau (hash) du certificat dans un format imprimable en vue du rapprochement. Dans la banque, la validation du certificat seffectue par le rapprochement de ces donnes. Limplementation de cette procdure papier est obligatoire. Optionnellement si la banque offre le service, ce fichier de confirmation du certificat, peut tre transmis par un autre canal lectronique et scuris quEBICS, car il est conu pour pouvoir tre intgr automatiquement sur le serveur de la banque.

Le contrle de lauthentification par mail simple nest pas garanti, lenvoi par mail simple de ce fichier nest pas recommand. Lutilisation dun certificat dlivr par une AC permet le contrle de la chane de certification grce une automatisation complte du rapprochement. Cest cette mthode dauthentification qui sera utilise dans la phase 2. Le renouvellement des certificats du poste client est possible par la commande PUB (dcrit au chapitre 10 des Spcifications EBICS 2.4.1). 2.1.2.4. Rcupration sur le poste client des cls publiques des certificats de la banque Les gabarits de certificats prconiss en cible sont en 2048 bits (pour la longueur de cl RSA) et RSA2048-SHA2 (pour lalgorithme de signature), il parat donc souhaitable de dmarrer le lancement EBICS en France avec ces caractristiques de certificat. Actuellement les AC rfrences ne sont pas compatibles avec cette cible (notamment le SHA2 nest pas encore implment). Il semble donc prfrable dutiliser provisoirement pour les serveurs des certificats auto-signs ou issus dAC privatives (en RSA 2048 bits et RSA2048-SHA2 pour lalgorithme de signature) et de migrer ensuite vers des certificats mis par des AC (bancaires ou non bancaires) habilites ayant ces caractristiques. Les postes clients devront tlcharger les cls publiques du serveur mises disposition par la banque, par la commande protocolaire HPB (download public bank key) puis les contrler (voir spcifications EBICS 2.4 chapitre 4.4.2.1). Il nest pas ncessaire dautomatiser la commande HPB lors de chaque change. En revanche, il est fortement conseiller de la dclencher en cas

Au format DER

EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 10 sur 27

de rception dune anomalie concernant les certificats du poste serveur (notamment lors du renouvellement des certificats). Dans la commande HPB, la banque doit envoyer les certificats X509 en plus des cls publiques. Comme pour les cls publiques des postes clients, ce contrle pourra tre fait par lenvoi (en parallle de celui via EBICS) dun document de confirmation par un autre canal (ce document peut tre le format imprimable du certificat voir annexe A4). Le poste client devra tre en mesure de permettre une procdure simple de rapprochement entre les cls publiques transmises via EBICS et celles reues partir dun autre canal. 2.1.2.5. Messages derreurs lis aux certificats Toute erreur sur certificat est signale par un message. La liste des messages derreurs lis aux certificats figure sur le site du CFONB : www.cfonb.org

2.1.3. Initialisation des identifiants

Chaque banque doit communiquer ses clients abonns les informations suivantes ncessaires au paramtrage du poste client. Le HostID (Identifiant la banque) : il est recommand aux banques dutiliser un code BIC sur 11 positions (BIC 8 complt avec XXX ventuellement). Le UserID, (Nom de lutilisateur ou du service) : la syntaxe est libre, dans le respect du format spcifi [a-zA-Z0-9,=]{1,35} Le PartnerID (Numro de contrat/abonnement) : la syntaxe est libre, dans le respect du format spcifi [a-zA-Z0-9,=]{1,35} } Les deux derniers identifiants seront communiqus par la banque lors de la signature du contrat. Il est recommand de ne pas renseigner le SystemID. Nota : Partner ID = Abonnement pour une Socit User ID = Utilisateur dans cet abonnement. En migration Etebac 3, l'utilisateur physique n'a pas d'existence dans EBICS. Il y a toujours au moins un utilisateur UserID dans un abonnement. Les certificats sont attachs l'utilisateur. Dans la majorit des cas, un client (socit) n'aura qu'un utilisateur. Nanmoins, certaines entreprises plus complexes peuvent faire le choix d'avoir plusieurs utilisateurs dans le cadre d'un abonnement, par exemple un user ID pour un dpartement Compta, et un autre user ID pour un autre dpartement (achats par exemple).

2.1.4. Prestataires de services

Ce type de socit gnre des fichiers (par exemple : paye,..) pour de multiples clients et doit les transmettre aux banques de ces clients. En ETEBAC 3, actuellement le client signe un contrat dchange avec sa banque, mais il peut dlguer, de manire transparente pour celle-ci, les changes un prestataire. Il en sera de mme avec EBICS. De ce fait, un prestataire qui a plusieurs clients, recevra un PartnerID/UserID de chacun de ses clients. Il devra sinitialiser avec chaque banque pour chaque client.

EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 11 sur 27

2.1.5. Tests
Un change de fichiers de tests est ncessaire avant tout change de fichiers rels. De ce fait, chaque serveur doit tre en mesure de recevoir des flux de tests et de production. Lobligation sera faite contractuellement au client dtre en mesure deffectuer des tests et donc celui-ci devra disposer dun logiciel apte les faire. De plus il doit tre possible dtre en mode test avec une banque et en mode oprationnel avec une autre. La recommandation suivante a pour objet de prciser les conditions de ces tests. Le poste client doit disposer dun paramtrage permettant de basculer du mode Test au mode Production. Son utilisation ne peut tre qu linitiative du client en accord avec sa banque. Compte tenu des risques de confusion entre flux de tests et flux oprationnels, il nest pas souhaitable que cette distinction rsulte dune intervention manuelle au niveau serveur. En France, il est recommand dutiliser un paramtre complmentaire aux commandes FUL ou FDL pour distinguer le flux de Test ou de Production. La prsence du paramtre appel TEST et sa valeur True signifiera que le flux est en test. Labsence du paramtre quivaudra un flux de Production. Lindication test doit figurer dans les balises FULOrderParams sur le modle suivant :

<FULOrderParams> <Parameter> <Name>TEST</Name> <Value>TRUE</Value> </Parameter> <FileFormat CountryCode="FR">pain.xxx.cfonb160.dct</FileFormat> </FULOrderParams>

EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 12 sur 27

2.2. Echanges de flux

Toute transaction EBICS est compose au minimum de deux messages, lun dinitialisation et lautre de transfert (en upload ou en download). Deux Order Type spcifiques seront utiliss pour les changes de flux : FUL et FDL, qui sont les commandes dchanges de fichiers. FUL (Upload) pour lenvoi dun fichier de remise dordres par le client vers sa banque FDL (Download) pour la rcupration par le client dun fichier de donnes (par exemple : relev de comptes) mis disposition par sa banque

2.2.1. Paramtrages lis aux flux

Dans la phase 1 (remplacement ETEBAC 3), seule la valeur T (transport) est prconise dans le rfrentiel du serveur pour la classe de signature. Dans ce cas le contrle de la signature de transport est obligatoire par le serveur (voir paragraphes suivants). Le poste client doit prciser dans le message, par la valeur D du premier champ de lOrderAttributes que le flux est en classe de signature transport ). Rappel : Pour les autres commandes, la valeur du premier champ de lOrderAttribute sera conforme aux spcifications EBICS 2 .4 (voir tableau page 280 du document des spcifications dtailles).

2.2.2. Traitement des remises dordres 2.2.2.1. Liste des contrles en pr-validation
En Upload, dans le premier message, celui dinitialisation, un certain nombre de contrles dits de pr-validations sont prvus : Contrle des certificats (3 cls publiques) sur la base des informations transmises par le poste client lors de linitialisation, Contrle de montants (limites), Contrle de comptes
Parmi ces contrles, celui portant sur les certificats est fortement recommand pour les serveurs en France. Les contrles de montants et de comptes sont optionnels pour les serveurs EBICS en France et laisss au libre choix de chaque tablissement bancaire. Sil ne permet pas ces contrles, le serveur rpond par la ngative au poste client.

2.2.2.2. Contrles de scurit des fichiers de remise dordres

Le premier message, celui dinitialisation, contient le hash du fichier de remise dordres calcul par le poste client ainsi que le fichier comportant la (ou les) signature(s). A cette tape, le fichier de remise dordres nest pas encore transfr, donc le hash ne peut pas tre calcul sur le serveur. Or ce contrle en synchrone nassure pas toute garantie pour la non rpudiation du fichier de remise dordres puisquelle se fonde sur un hash communiqu par le client. Cette non rpudiation impacte la phase 2 mais il parat ncessaire den dcrire en dtail le fonctionnement pour identifier tout risque. Le protocole EBICS garantit lintgrit au cours de lchange par la signature lectronique didentification/authentification de lutilisateur metteur du message.

La signature est deux niveaux. : Tous les fichiers changs sont signs lectroniquement. Le rsultat de cette signature est stock dans une structure communique dans le message dinitialisation, avec le hash du
EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 13 sur 27

fichier calcul sur le poste client. La classe de cette signature est bancaire (ordre dexcution) ou transport selon le profil dclar de lutilisateur dans le rfrentiel du serveur. Chaque message EBICS est authentifi avec la cl dauthentification de lutilisateur metteur du message. La signature utilise un mcanisme de signature XMLDsig. La liste complte des champs du message entrant dans le calcul de cette signature se trouve dans les spcifications. On peut rappeler que les donnes signes sont gnralement sensibles, par exemple le hash, le fichier comportant les signatures.

Le contrle de signature des fichiers changs sappuie sur le hash transmis par lutilisateur et celui calcul par la banque destinataire. Ce dernier seffectue sur le fichier reu par paquets de 1Mo, le calcul pourrait donc commencer, en mode synchrone, avant la fin de la rception du dernier paquet, ou en mode asynchrone aprs avoir termin la communication avec lutilisateur. Cest au serveur de choisir son mode de fonctionnement : asynchrone ou synchrone. Le choix est laiss libre pour limplmentation. En synchrone, il est possible de dcompresser, dchiffrer et contrler la signature du fichier avant denvoyer la trame de rponse au client distant, cest dire avant la fin de la transaction EBICS. En effet la dernire trame envoye par le client EBICS contient le dernier segment de donne repr par la balise <SegmentNumber lastSegment= true >. Le serveur a donc lopportunit de faire la vrification de la signature et de renvoyer, le cas chant, une erreur (EBICS_SIGNATURE_VERIFICATION_FAILED) dans la trame de rponse la rception de ce dernier segment. En asynchrone, lorsque la transaction EBICS se termine, le fichier reu na pas t dcompress, dchiffr et contrl intgre par sa (ou ses) signature(s). Or, les erreurs ventuelles dtectes sur le fichier chang, doivent tre mise disposition du client EBICS par PSR ou PTK, dcrits au paragraphe suivant.

2.2.2.3. Information client sur la rception du fichier de remise dordres

Pour les traitements en mode asynchrone, le client doit tre inform par le serveur de la bonne rception ou non du fichier. En phase 1 (remplacement ETEBAC 3) les acquittements ngatifs doivent obligatoirement tre transmis au client. La mise disposition des acquittements positifs est recommande et dpend de loffre de service bancaire. Le poste client doit tre en mesure de rcuprer les deux types dacquittement. En Allemagne, cette fonctionnalit est ralise, ce jour, par lutilisation du Kunden Protokoll (OrderType PTK) dcrit au chapitre 10 des Spcifications EBICS 2.4 En France, la cible est lutilisation du PSR qui est rcupr par la commande FDL (Download) ou tout autre canal. Lutilisation du PTK peut rester une implmentation temporaire condition de tenir compte de la longueur maximum des identifiants limite 8 caractres par rapport au PSR qui admet des longueurs didentifiants sur 35 caractres. Utilisation du Payment Status Report : Le Payment Status Report (Format ISO 20022 XML pain.002.001.02, disponible sur le site ISO www.iso20022.org) doit tre fait au niveau fichier. De ce fait, les items de niveau 3.0 et au del ne seront pas valoriss, seuls les items de niveau GroupHeader et OriginalGroupInformationAndStatus seront renseigns (voir annexe A5 Format du Payment Status report) A dfaut, la mise disposition ou lenvoi dun Payment Status Report peut seffectuer par un autre canal (mail, portail internet) en utilisant une feuille de style afin de le rendre lisible. En annexe 5 Format du Payment Status Report figure la description des donnes permettant de rapprocher un PSR avec la remise dordres correspondante.

EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 14 sur 27

La gnration dun Payment Status Report est obligatoire pour tout chec de transaction. Il nest pas obligatoire de crer un PSR par fichier transmis en chec, mais dans le cas dun envoi multiple, le serveur peut effectuer, la fin de cet envoi une concatnation technique de plusieurs fichiers XML de compte rendu (prsence de plusieurs header XML dans le mme fichier) dans un seul PSR. Dans ce cas, le PSR ne pourra pas tre dpars directement par le poste client. Il devra auparavant tre dcoup en fichiers XML unitaires avant de parser chaque compte rendu. Le PSR ne porte que sur la commande FUL (UPLOAD) et ne doit pas tre gnr pour les autres commandes (INI, HIA ,..).

2.2.3. Rcupration des fichiers clients : la commande Download (FDL)

Lutilisation de la commande de Download (FDL) sans paramtrage de date permet de rcuprer lensemble des fichiers disponibles (non encore rcuprs). Sur cette commande, le serveur met disposition tous les fichiers en stock, ceux de mme type sont concatns avant dtre compresss et chiffrs pour lchange, ne formant plus ainsi quun seul fichier. Aprs envoi, les fichiers sont systmatiquement archivs sur le serveur. Ils peuvent alors tre nouveau rcuprs en utilisant la commande de download (FDL) avec un paramtre correspondant une date ou un intervalle de dates en fonction de loffre de service bancaire. Lintervalle de dates possible dpend de la profondeur darchivage mis en place sur le serveur. Chaque tablissement bancaire peut fixer une dure dhistorisation pour chaque type de fichier et doit le faire figurer dans le contrat dabonnement. La remise disposition de fichiers au-del de la priode dhistorique en ligne nest pas du domaine protocolaire. Remarques : Certaines banques peuvent proposer une offre de services spcifique de mise disposition dinformation (frquence de relevs,). La mthode dcrite pour nommer les fichiers permet de couvrir les besoins relatifs ces services spcifiques. Les banques pourront utiliser des extensions propritaires dans le nom du fichier utilis dans le FileFormat. Ce type de paramtrage spcifique un tablissement doit tre indiqu dans les annexes du contrat dabonnement. La commande FDL ne comporte quun seul FILE FORMAT. Donc seuls des fichiers de mme type seront concatner. Le client EBICS devra grer ce type de cas. Sur la commande FDL, si lintervalle de date nest pas renseign, tous les relevs non reus sont transmis, ce qui en France inclut le PSR et le PTK. Cette gestion est implmenter par banque.

EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 15 sur 27

3. MODALITES DUTILISATION DU POSTE CLIENT

La mise en uvre de la connexion dun poste client avec une banque requiert au pralable la signature dun contrat entre le client et cette banque. Ce contrat doit comporter un document indiquant les donnes spcifiques cet abonnement. Il y a donc un contrat signer et une initialisation raliser pour chaque banque. Il est du ressort des diteurs de logiciels de mettre disposition les moyens ncessaires aux clients pour scuriser laccs au poste client et aux donnes sensibles. Le client devra disposer des outils permettant de scuriser sa connexion Internet (firewall, antivirus,..) et les tenir jour. Chaque poste client et chaque serveur doivent avoir des Log permettant de faire le suivi des changes (horodatage, montant, .). Il doit tre possible de rechercher la log de bout en bout de chaque transaction et de pouvoir la transmettre la banque (mail,..). Il est recommand que les interfaces homme-machine et les ditions soient en Franais.

EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 16 sur 27

4. ANNEXES
A.1 Order Type
Les spcifications 2.4 dEBICS sappliquent en France et en Allemagne mais les commandes (OrderType) couples un format de fichier spcifique ne seront pas utilises en France. Pour cette fonctionnalit, en France on utilise lOrdertype FUL associ au Fileformat spcifique. Les commandes du protocole sont classes en deux catgories : Les system orders lies la gestion du rfrentiel EBICS ou au protocole lui-mme Les bank-technical orders lies un format La liste des commandes supportes par les serveurs franais est un sous-ensemble des commandes EBICS et sont plutt considres comme des system orders, lexception des commandes FUL et FDL , qui sont les seules commandes dupload et de download de fichiers autorises en France. La liste ci-dessous constitue la liste exhaustive des OrderTypes ncessaires en France. Limplmentation de la commande HTD (Download subscribers customer and subscriber Data) est recommande. En dehors de cette liste, les autres commandes sont optionnelles. Un serveur qui reoit une commande quil ne peut pas traiter doit rpondre le code retour prvu : EBICS_UNSUPPORTED_ORDER_TYPE Identification HCA HCS HIA Nom Send amendment of the subscriber key for identification and authentication and encryption Transmission of the subscriber key for ES, identification and authentication and encryption Transmission of the subscriber key for identification and authentication and encryption within the framework of subscriber initialisation Transfer the public bank key (download) Download bank parameters Send password initialisation Download supported EBICS versions Send public key for signature verification Customers public key for the ES (see Appendix Chapter 15) Transmission of an ES file with a signature for a dummy file that only contains a space Upload de fichiers dont le type est en paramtre Download de fichiers dont le type est en paramtre Format

HPB HPD INI HEV PUB

Customers public key for the ES

SPR

Suspension of access authorisation

FUL FDL PTK

File Upload File Download Kunden Protokoll

EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 17 sur 27

A.2 FileFormat/Request Type Nommage des fichiers

Avertissement : le contenu de cette annexe dnomme EBICS SWIFNet - Nommage Fichiers est consulter sur le site du CFONB : www.cfonb.org dans la rubrique Documentation : Migration ETEBAC vers EBICS et SWIFTNet

A.3 Certificats
A.3.1 Messages derreurs lies aux certificats Avertissement : le contenu de cette partie est consulter sur le site du CFONB : www.cfonb.org dans la rubrique Documentation : Migration ETEBAC vers EBICS et SWIFTNet A.3.2 Gabarit certificats porteurs EBICS
Un certificat porteur pour EBICS peut tre auto-sign ou import sur le poste client sil est dlivr par une AC prive. Trois usages sont dfinis pour EBICS et trois certificats sont requis.

Certificat ddi la signature

Champ X509 version serialNumber Signature Algorithm issuer validity Valeur =2 nombre alatoire sur 35 octets max si auto sign RSA-SHA2 (256) =subject dure de validit : 5 ans5 Obligatoire oui oui oui oui oui

subject (objet ou DN)

Lattribut utilis est le commonname

oui

subjectPublicKeyInfo extensions : AuthorityKeyIdentifier SubjectKeyIdentifier KeyUsage ExtendedKeyUsage CRLDistributionPoints

cl RSA de longueur 2048 bits rsaEncryption =SubjectKeyIdentifier de lAC ou du prsent certificat NonRepudiation

oui

oui oui oui non non

EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 18 sur 27

certificat ddi lauthentification

Champ X509 version serialNumber Signature Algorithm issuer validity Valeur =2 nombre alatoire sur 35 octets max si auto sign RSA-SHA2 (256) =subject dure de validit : 5 ans 5 Lattribut utilis est le commonname Obligatoire oui oui oui oui oui

subject (objet ou DN)

oui

subjectPublicKeyInfo extensions : AuthorityKeyIdentifier SubjectKeyIdentifier KeyUsage ExtendedKeyUsage CRLDistributionPoints

cl RSA de longueur 2048 bits - rsaEncryption =SubjectKeyIdentifier de lAC ou du prsent certificat DigitalSignature

oui oui oui oui non non

certificat ddi au chiffrement

Champ X509 version serialNumber Signature Algorithm issuer validity Valeur =2 nombre alatoire sur 35 octets max si auto sign RSA-SHA2 (256) =subject dure de validit : 5 ans 5 Obligatoire oui oui oui oui oui

subject (objet ou DN)

Lattribut utilis est le commonname

oui

subjectPublicKeyInfo extensions : AuthorityKeyIdentifier SubjectKeyIdentifier KeyUsage ExtendedKeyUsage CRLDistributionPoints

cl RSA de longueur 2048 bits - rsaEncryption =SubjectKeyIdentifier de lAC ou du prsent certificat keyEncipherment ou keyAgreement

oui oui oui oui non

Cette dure de validit est valable uniquement pour les certificats autosigns. Dans le cas de certificats dAC la dure de validit sera celle de la politique de certification correspondante au certificat.

EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 19 sur 27

A.3.3 Gabarit certificats serveurs EBICS Il est ncessaire de disposer dun certificat par usage, soit dans la version actuelle 2.4 : 2 certificats par serveur banque (authentification et chiffrement). Les deux certificats serveurs sont assimils des certificats SSL TLS et donc doivent avoir la fois le KeyUsage de DigitalSignature et de KeyEncipherment. Le certificat de signature nest pas prvu dans la version EBICS 2.4 qui couvre le remplacement de ETEBAC 3 et ETEBAC 5.

Certificat serveur ddi lauthentification

Champ X509 Version serialNumber Signature Algorithm issuer validity subject (objet ou DN) subjectPublicKeyInfo extensions : AuthorityKeyIdentifier KeyUsage CertificatePolicies CRLDistributionPoints FreshestCRL ExtendedKeyUsage Valeur =2 RSA-SHA2 (256) dure de validit : 5 ans6 Lattribut utilis est le commonname cl RSA de longueur 2048 bits rsaEncryption Oblig. oui oui oui oui oui oui oui oui oui oui oui non non

DigitalSignature ;keyEncipherment

certificat serveur ddi au chiffrement

Champ X509 Version serialNumber Signature Algorithm issuer validity subject (objet ou DN) subjectPublicKeyInfo extensions : AuthorityKeyIdentifier KeyUsage CertificatePolicies CRLDistributionPoints FreshestCRL ExtendedKeyUsage Valeur =2 RSA-SHA2 (256) dure de validit : 5 ans6 Lattribut utilis est le commonname cl RSA de longueur 2048 bits rsaEncryption Oblig. oui oui oui oui oui oui oui oui oui oui oui non non

DigitalSignature ;keyEncipherment

Cette dure de validit est valable uniquement pour les certificats autosigns. Dans le cas de certificats dAC la dure de validit sera celle de la politique de certification correspondante au certificat.

EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 20 sur 27

A.4 Format imprimable du certificat

En France, lenvoi de trois documents : un document par certificats, est obligatoire. Chaque certificat est imprim au format PEM. Le hash imprim est celui du certificat construit selon la norme X509 avec lalgorithme SHA2 (256). Limpression du hash est en hexadcimal et en majuscules. Les lettres suivantes ne sont donnes qu titre dexemple de prsentation. Pour trouver un exemple de calcul de hash se reporter lannexe 6.

Lettre dinitialisation du certificat de signature de transport

Date : Time : Host Id : Banque : User-ID : Partner-ID : Version : TT.MM.JJJJ HH:MM:SS BIC11 de la banque nom de la banque Xxxxxxxx Yyyyyyyy Signature A005

Certificat de signature lectronique

-----BEGIN CERTIFICATE----MIICcjCCAdugAwIBAgIBDzANBgkqhkiG9w0BAQQFADA6MQswCQYDVQQGEwJGUjEY MBYGA1UECxMPYmFucXVlcG9wdWxhaOdrLaNGZtYDVQQDEwggdHVyYm9zYTAeFw0w ODA5MTAxMzI0MzZaFw0xODA5MDgxMzI0MzZaMDQxCzAJBgNVBAYTAmZyMRgwFgYD VQQLEw9iYW5xdWVwb3B1bGFpcmUxCzAJBgNVBAMTAmpmMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQCkscideEsfU0+UPqM13kPUQVBFYB4xOcHCYqzr6PPgl7Co GwsjK5o4CKUm/7qWS0BdnqNOdrLaNGZ4kCXlXDg1SemWMlOgPtWl9T3XAiyyr88L Ei+9sisIUA/JE/3leQWuk0gJXohtxKUwR/fbsWrQjqLspxNK09Urbqz8hwehPQID AQABo4GNMIGKMA4GA1UdDwEB/wQEAwIE8DA4BgNVHR8EMTAvMC2gK6AphidodHRw Oi8vODYuNjQuMTAuMTM4LytDU0NPQ0ErL2FzYV9jYS5jcmwwHwYDVR0jBBgwFoAU zM7nNDE4VQkAUz33C9ztXhG9P3gwHQYDVR0OBBYEFNd6cAJ8L04eB7TiCzpcumIn gFSsMA0GCSqGSIb3DQEBBAUAA4GBAEm2OLlVyMIzf7Bk7ZUNBCQacvUEdl2o58Pg py+CMN+K1OdrLaNGZ77TIVKbydqwI2t7hIpuC81c8D3O9r3LiYSDrgxMFhxeUKLD sIo1dusXjV8nHm5V2zu4hOdrLaNGZix3bEEEFH+cpzOp5y/ogwHWVpz6h3r36Lgo Vl1S6JU6 -----END CERTIFICATE-----

Hash du certificat de signature (SHA-256): B8 3C B0 19 66 C9 9C 6E 2C A5 BA 6A 2B 56 01 92 35 2A B4 91 53 E9 0B BA 34 C1 5E B5 9F 4A 64 F7

Date :

Signature :

EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 21 sur 27

Lettre dinitialisation du certificat dauthentification

Date : Time : Host Id : Banque : User-ID : Partner-ID : Version : TT.MM.JJJJ HH :MM :SS BIC11 de la banque nom de la banque Xxxxxxxx Yyyyyyyy Authentification X002

Certificat dauthentification Type : X002

-----BEGIN CERTIFICATE----MIICcjCCAdugAwIBAgIBDzANBgkqhkiG9w0BAQQFADA6MQswCQYDVQQGEwJGUjEY zM7nNDE4VQkAUz33C9ztXhG9P3gwHQYDVR0OBBYEFNd6cAJ8L04eB7TiCzpcumIn MBYGA1UECxMPYmFucXVlcG9wdWxhaOdrLaNGZtYDVQQDEwggdHVyYm9zYTAeFw0w ODA5MTAxMzI0MzZaFw0xODA5MDgxMzI0MzZaMDQxCzAJBgNVBAYTAmZyMRgwFgYD VQQLEw9iYW5xdWVwb3B1bGFpcmUxCzAJBgNVBAMTAmpmMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQCkscideEsfU0+UPqM13kPUQVBFYB4xOcHCYqzr6PPgl7Co GwsjK5o4CKUm/7qWS0BdnqNOdrLaNGZ4kCXlXDg1SemWMlOgPtWl9T3XAiyyr88L Ei+9sisIUA/JE/3leQWuk0gJXohtxKUwR/fbsWrQjqLspxNK09Urbqz8hwehPQID AQABo4GNMIGKMA4GA1UdDwEB/wQEAwIE8DA4BgNVHR8EMTAvMC2gK6AphidodHRw Oi8vODYuNjQuMTAuMTM4LytDU0NPQ0ErL2FzYV9jYS5jcmwwHwYDVR0jBBgwFoAU gFSsMA0GCSqGSIb3DQEBBAUAA4GBAEm2OLlVyMIzf7Bk7ZUNBCQacvUEdl2o58Pg py+CMN+K1OdrLaNGZ77TIVKbydqwI2t7hIpuC81c8D3O9r3LiYSDrgxMFhxeUKLD sIo1dusXjV8nHm5V2zu4hOdrLaNGZix3bEEEFH+cpzOp5y/ogwHWVpz6h3r36Lgo Vl1S6JU6 -----END CERTIFICATE-----

Hash du certificat dauthentification (SHA-256) : 2C A5 BA 6A 2B 56 01 92 35 2A B4 91 53 E9 0B BA B8 3C B0 19 66 C9 9C 6E 34 C1 5E B5 9F 4A 64 F7

Date :

Signature :

EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 22 sur 27

Lettre dinitialisation du certificat de chiffrement

Date : Time : Host Id : Banque : User-ID : Partner-ID : Version : TT.MM.JJJJ HH:MM:SS BIC11 de la banque nom de la banque Xxxxxxxx Yyyyyyyy Chiffrement E002

Certificat de chiffrement Type : E002

-----BEGIN CERTIFICATE----MIICcjCCAdugAwIBAgIBDzANBgkqhkiG9w0BAQQFADA6MQswCQYDVQQGEwJGUjEY zM7nNDE4VQkAUz33C9ztXhG9P3gwHQYDVR0OBBYEFNd6cAJ8L04eB7TiCzpcumIn MBYGA1UECxMPYmFucXVlcG9wdWxhaOdrLaNGZtYDVQQDEwggdHVyYm9zYTAeFw0w ODA5MTAxMzI0MzZaFw0xODA5MDgxMzI0MzZaMDQxCzAJBgNVBAYTAmZyMRgwFgYD VQQLEw9iYW5xdWVwb3B1bGFpcmUxCzAJBgNVBAMTAmpmMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQCkscideEsfU0+UPqM13kPUQVBFYB4xOcHCYqzr6PPgl7Co GwsjK5o4CKUm/7qWS0BdnqNOdrLaNGZ4kCXlXDg1SemWMlOgPtWl9T3XAiyyr88L Ei+9sisIUA/JE/3leQWuk0gJXohtxKUwR/fbsWrQjqLspxNK09Urbqz8hwehPQID AQABo4GNMIGKMA4GA1UdDwEB/wQEAwIE8DA4BgNVHR8EMTAvMC2gK6AphidodHRw Oi8vODYuNjQuMTAuMTM4LytDU0NPQ0ErL2FzYV9jYS5jcmwwHwYDVR0jBBgwFoAU gFSsMA0GCSqGSIb3DQEBBAUAA4GBAEm2OLlVyMIzf7Bk7ZUNBCQacvUEdl2o58Pg py+CMN+K1OdrLaNGZ77TIVKbydqwI2t7hIpuC81c8D3O9r3LiYSDrgxMFhxeUKLD sIo1dusXjV8nHm5V2zu4hOdrLaNGZix3bEEEFH+cpzOp5y/ogwHWVpz6h3r36Lgo Vl1S6JU6 -----END CERTIFICATE-----

Hash du certificat de chiffrement (SHA-256) : 2C A5 BA 6A 2B 56 01 92 35 2A B4 91 53 E9 0B BA B8 3C B0 19 66 C9 9C 6E 34 C1 5E B5 9F 4A 64 F7

Date :

Signature :

EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 23 sur 27

A.5 Format du Payment Status Report

Cette annexe est base sur la version 2 du Payment Status Report (pain.002.001.02). Dans la suite du document, les rfrences des messages items du PSR sont reprises pour indiquer leur valorisation possible :

1.1 MessageIdentification Rfrence du message : Numro alatoire unique identifiant le PSR gnr automatiquement par le serveur 1.2 CrationDateTime - Date de cration : date et heure de cration du message 1.3 InitiatingParty Emetteur du message : BIC de la banque qui met le message (HostID) Les autres champs ne sont pas valoriser.

EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 24 sur 27

2.1 OriginalMessageIdentification Rfrence du message dorigine : A valoriser par lOrderID. 7 2.3 OriginalMessageNameIdentification Nom du message dorigine : A valoriser par FileFormat 2.8 GroupStatus Code Statut : A valoriser par RJCT en cas danomalie ou par RCVD si le fichier est correct 2.09 StatusReasonInformation / 2.12 Code Code anomalie : A valoriser par NARR , uniquement en cas danomalie (ie : si GroupStatus = RJCT ) 2.14 AdditionalStatusReasonInformation dtail de lanomalie : A valoriser par le code erreur EBICS (en anglais). La liste des codes se trouve dans le document EBICS_Annex1_ReturnCodes14-09-2009nA.pdf qui accompagne les spcifications EBICS 2.4.1 Cette donnes doit tre renseigne uniquement en cas danomalie (GroupStatus = RJCT )

Les autres champs ne sont pas valoriser. Nota : Le PSR de niveau protocolaire sera transmis par le message : pain.002.001.02.ack (cf. annexe 2 Nommage des fichiers version 1.2)

La gestion sur le poste client de lOrderID qui doit tre unique par utilisateur/fileformat et qui sert au rapprochement lors de la signature disjointe (VEU) doit tre prcise. Cest la seule donne permettant le rapprochement sur le poste client avec le PSR. Ce point est important pour le rapprochement automatique, inexistant sur les versions allemandes, qui peut ne pas tre requis en phase 1. EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 25 sur 27

A.6 Exemple de calcul de Hash Le hash peut tre control par la commande openssl suivante : openssl x509 -sha256 -fingerprint -in cert.pem results into this output: SHA256 Fingerprint = A6:16:4F:86:65:AF:84:D5:84:AB:70:51:19:37:2F:4D:61:36:AE:69:C2:6A:F6:AF:31:79:CD:01:37:3 C:D4:81

cert.pem

ExempleSignatureTra nsport.doc

EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 26 sur 27

A7 - Glossaire
Sigle Dfinition

AC API Authentification Banque CFONB Certificat Certificat auto-sign Chiffrement DER EBICS ETEBAC Fichier dordres Remise dordres Fileformat Hash, empreinte sceau Sceau du certificat IP

Autorit de Certification Application Programing Interface (interface de programmation) Procdure permettant de vrifier lidentit dune entit (personne ou systme)

Prestataire de Services de paiement (PSP) au sens de la directive 2007/064/CE sur les services de paiements du 17 novembre 2007, transpose dans lordonnance 2009-866 du 15 juillet 2009.
Comit Franais dOrganisation et de Normalisation Bancaires Standard permettant de stocker une cl publique Certificat gnr par lmetteur du message Processus de transformation des donnes laide dun algorithme cryptographique Standard de prsentation de certificat (Distinguished Encoding Rules) Electronic Banking Internet Communication Standard Echanges Tlmatiques Entre Banques et Clients Fichier contenant les instructions bancaires Gnralement pour la France il sagit de la nature de la transaction bancaire dans les commandes FUL et FDL Valeur numrique associe un message pour sassurer de son intgrit

Internet Protocol Nature de la transaction EBICS incluant pour lAllemagne la nature Order Type : des transactions bancaires Ordre dexcution Voir signature de lordre Privacy Enhanced Mail. Le format PEM est du DER encod en PEM base64 auquel sont ajoutes des en-ttes en ASCII. Il peut contenir des cls prives, des cls publiques et des certificats X509. Request Type : Nature de la demande dinformation Scellement Fonction mathmatique permettant dobtenir le sceau Signature permettant de sassurer de lorigine et de lintgrit des Signature de transport donnes dun message. Elle na pas de valeur personnelle Signature de lordre La signature de lordre est galement appele ordre dexcution ou /Ordre dexcution signature personnelle lectronique. Elle permet dauthentifier /Confirmation personnellement lmetteur dun message Les instructions et la signature de lordre ne sont pas transmises dans le mme flux mais de faon asynchrone. Signature disjointe : Elles peuvent tre transmises par le mme canal ou par canal diffrent ainsi quau mme moment ou dcales dans le temps. Society for Worldwide Interbank Financial Transaction SWIFT Transport Layer Security TLS Verteilte Elektronische Unterschrift (Signature Electronique Disjointe) VEU : Protocole de communication par commutation de paquets, X25 commercialis par France Telecom, utilis par les protocoles ETEBAC Zentraler KreditAusschuss ZKA

EBICS IG CFONB VF 1.2 .doc

9/10/2009

Page 27 sur 27