EBICS IG CFONB V2 1.4 english version 24 02 2012
Contents
1. eeeeeeeeeeeeeeeeeeeeeeeeeeeeeneeeeeeeeeeeeees 19 2 2 3 File retrieving by the customer workstation the Download command FDL 21 3 USE OF THE CUSTOMER WORKSTATION uo0 ccceeeeeseccecccceeeeeeeeeeseeeeeeeeeeeeeeeeesensneeaees 22 Bh WAIN DA E EE O 23 Ja EL O a a B 2 AEE EE E EE E E EE 23 A2 FileFormat Request Type Files names eseesseeeseseeeseseesseserssresstssresresstesessreeseeseeseessressesereseeses 24 A3 Certificates eseis nr a a e E a A E E OE RE ESS 24 A3 1 Errors messages related to Certificates ccccccscsssseeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeees 24 A3 2 Structure of the certificates for EBICS customer workstations eeeseeee 24 A3 3 Structure of the certificates for EBICS bank servers ccccssseeseeeeeeeeeeeeeeeeeeeeeeees 29 A4 Pint CSPI CAS a ske 4 cis Stra a cae bas ea gens eonncuana e a aaaea e naa n n a tan tiss 31 A5 Payment Status Report Format sessi ein Ba SRS ge a Med ee 35 AG Example ot Hash Calet lation ssni iei i iaasa e Snia E EE i N Ea e cased 35 AT Glossar on a a a a a a e a a a Sie ie a 36 EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 3 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid 1 INTRODUCTION 1 1 Purpose and scope of the guide This implementation guide is intended for developers of EBICS customer workstations and bank servers This is not a user manual for customers Its main pur2. 19 37 2F 4D 61 36 AE 69 C2 6A F6 AF 31 79 CD 01 37 3C D4 81 XP cert pem m ExempleSignatureTra nsport doc EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 35 sur 37 02 2012 doc A7 Glossary English translation for information purposes only Only the French version is valid Name or Acronym Acronym Signification Definition CA Certificate Authority Certification Authority In cryptography a certificate authority or certification authority CA is an entity that issues digital certificates for using by other parties API Application Programming Interface An application programming interface API is a set of routines data structures object classes and or protocols provided by libraries and or operating system services in order to support the building of applications Authentication Authentication is the act of establishing or confirming someone as authentic This confirms that the identity registered is a trusted one Bank The term bank used in this document should be understood as a Payment Service Provider PSP under 2007 064 CE Payment Services Directive dated November 17th 2007 The French transposition is the Ordonnance 2009 866 dated July 15 th 2009 CFONB Comit Frangais d Organisation et de Normalisation Bancaires French Standard Organization dedicated to resolve technical problems on the banking area context In particular it normalizes
3. EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 29 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid Serveur Certificate for Encipherment Mandatory field X509 Value Y Yes N No version 2 for X509V3 Y serialNumber Y Signature Algorithm RSA SHA2 256 Y issuer Y validity Validity 5 years Y subject objet ou DN The attribute is commonname subjectPublicKeyInfo RSA KEY of 2048 bit length Y rsaEncryption extensions AuthorityKeyIdentifier Y KeyUsage DigitalSignature keyEncipherment Y CertificatePolicies Y CRLDistributionPoints E FreshestCRL N ExtendedKeyUsage This is valid only for self signed certificates The term of validity of CA certificates will depend on the Policy of the CA for this type of certificate EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 30 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid A4 Print Certificate In France sending of the 3 certificates one per usage is mandatory Each certificate is printed in PEM format The hash printed consists of the certificate built in the standard X509 with the algorithm SHA2 256 The hash is printed in hexadecimal and in uppercase The following letters are given as examples of presentation For an example of calculated hash refer to Annex 6 When the certi
4. EBICS TS example joint execution order and usage CA certificates Authentification Encryption and Signature cssccssseeeeeeeeeeeeeeeeseeeeeeeeeeeeeeeeeeeeeenees 11 2 1 2 Sec rity Set Up iiaeeeaino pi aatia asiria e ipada aineena airida 12 2 1 3 Electronic signature and ENncryption ccccsssssseeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeenees 16 2 1 4 Initi lization of DSa aeaaea eaaa aeaaeae aa aaae paraa ainaani aaee 17 2 1 5 Management of several users in a single SUDSCTIPTION cceeeeeeeeeeeeeeeees 17 2 1 6 Service Providers ciciccciisicsistescdicasiieiaiesascsisinsssasetasaneeciwucdiednvnaneetucctinutaveanvacnteuasen 17 EBICS T profile Service provider shall bear the management of authentication encryption and signing Certificates ssssnsnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn nenna 17 EBICS TS profile the signature certificate is under the responsibility of the customer and therefore under his exclusive permanent control The service provider must provide a secure environment to the customer which has to sign himself each file before their delivery to the Bank eeeeeeeeeeeseeeeseeeeeeeeeeeeeeeeeneeeeeaeeeeeeeseeseeeeeeeeeenees 18 Ps AY Same E Cee er 18 2 2 File transfers ennnen ainiai ened 19 2 2 1 Settings related to file transfers ccccceeseeeeseeeeeeeeeeeeeeeeseseneeeeeeeeeeeeeeseeeeeeees 19 2 2 2 Processing of the order remittances
5. an additional set up to FUL or FDL orders to distinguish the test files from the production files The presence of the set up called TEST and its value True means that it s a test file The absence of the set up means a production file The TEST indication must be included in the tag OrderParam in the following way lt FULOrderParams gt lt Parameter gt lt Name gt TEST lt Name gt lt Value gt TRUE lt Value gt lt Parameter gt lt FileFormat CountryCode FR gt pain xxx cfonb160 dct lt FileFormat gt lt FULOrderParams gt EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 18 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid 2 2 File transfers Any EBICS transaction is made at least of two messages one for initialization and another for the data transfer upload or download mode Two OrderTypes will be used for file transfers FUL and FDL Those commands are used gt FUL Upload for sending a remittance file by the customer to the bank gt FDL Download for the retrieval by the customer of a file generated by the bank customer reporting 2 2 1 Settings related to file transfers In EBICS T profile only the value T transport is recommended in the bank server repository for the class of signature In this case the check of the signature of transport is required by the server see below The customer workstation must specify in
6. commands EBICS TS can also be implemented with self generated certificates for authentification and encryption sent by another channel mail and a signature certificate issued by a CA IEN Certificate V rification in relation with the CA Downloading of the bank Certificates DN ValiditY Usage with by HPB command os f Matching with the Recording of the Bank certificates in p onac the database of the customer ka workstation gt oo Tests EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 11 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid 2 1 2 Security set up 2 1 2 1 Certificates File transfers with the French banks servers specified by the CFONB are based on the use of X509 certificates to guarantee the integrity in phase 1 and the execution order in phase 2 The details of these certificates templates are described in Appendix A3 The separation of uses Authentication Encryption and Signature sealing in EBICS T electronic signature in EBICS TS is mandatory so 3 keys will be used one for each use by the customer workstation and the bank server Both physical persons do not have common certificates for authentication encryption and digital signature each element of this triplet must be different It is recalled that certificates for authentication encryption and digital signa
7. exchanges between banks and between banks customers Certificate Digital certificate In cryptography a public key certificate also known as a digital certificate is an electronic document which uses a digital signature to bind together a public key with a registered identity If it isn t self signed the certificate can be used to verify that a public key belongs to an individual Certification chain trusted chain Chaine de certification Verification of the certification up to the root Aurthority Self signed Certificate made by server or workstation without certificate Certificate Authority In cryptography encryption is the process to transform information using an algorithm called cipher to make it unreadable to anyone except those Encryption possessing special knowledge usually referred to a key The result of the process is encrypted information in cryptography referred to a cipher text DER Distinguished Encoding ASCII text format allowing transmitting features of an Rules electronic certificate Electronic Banking EBICS is a new Standard Communication Protocol EBICS internet Communication between Banks and Customers over TCP IP and Standard Internet It provides you with a multi bankable a application Echanges T l matiques Current File Transfer Protocol used in France to ETEBAC Entre Banques et exchange between Banks and customers EBICS will Customers replace this protocol ove
8. in the contract concluded between the client and the Bank the signatory has the signature power alone or combined with a second signature The indicator ES quantity 1 or 2 sets the minimum number of signatories expected For ES quantity 1 orders received with 2 signatures are accepted This allows for example handling the case of a number of signatures depending on the amount of the order transmitted In the French implementation the final validation is not necessarily processed directly by the EBICS Protocol It is therefore necessary for the EBICS server to forward all these orders to the Bank business application where the verification of the number of signatures expected is controlled Note gt The contract describes for each FileFormat the number of required signatures simple signature ES quantity 1 one or two ES quantity 1 for example according to the amount two mandatory ES quantity 2 gt A rejection of the order by the lack or excess of signature may therefore occur downstream of the EBICS server after acceptance at the EBICS protocol level gt To prevent rejects the client workstation must control the number of expected signatures according to the contract prior to sending the file gt Inall cases more than 2 signatures are not accepted gt The EBICS protocol allows the use of 2 other signature classes A and B but this use is not adopted so far in France gt Any reception without s
9. needed to process execution orders electronically signed and transported with the orders to execute 4 the list of orders Order types in the protocol includes the orders used in the German and French contexts This guide identifies the precise sub set recommended for the orders used in France 5 EBICS protocol is to be used for the remittance of SEPA payments but also for domestic payments VO LCR and customer reporting account statements The description of the national settings was necessary EBICS protocol can also be used for other banking purposes Note To facilitate the updating and the loading by editors the following lists are not attached to this document but are available as separate documents on CFONB website www cfonb org with this Implementation Guide Documentation gt ETEBAC Migration to SWIFTNet and EBICS gt Annex A2 FileFormat Request Type file naming gt Annex A3 1 List of error messages related to certificates gt Annex A5 Payment Status Report format gt Annex A6 Example of Hash calculation EBICS IG CFONB V2 1 4 english version 24 02 2012 Page sur 37 02 2012 doc Amendment history English translation for information purposes only Only the French version is valid Version Date Chapter Type Description VO 1 1 24 4 2009 First English version In phase with French V1 1 VO 1 2 9 2009 All Consistency with the ve
10. number of expected signatures for the different UserID of this PartnerID 2 1 5 Management of several users in a single subscription This part describes the recommendation for the management of multiple users Userld at a same Subscriber Partnerld The MessagelD must be unique This identification is performed by the server by joining the transaction number Orderld with subscriber Partnerld and the type of order OrderType It is therefore essential to manage transaction numbers Orderld regardless of the user Userld When initializing the users userID of a subscriber PartnerID it is recommended for good management of the transaction numbers to assign slices of transaction numbers Orderld by users Userld For example the slice A000 to AZZZ for the first user B000 to BZZZ for the second user with a maximum of 26_users by subscription etc Reminder OrderlDtype 1 A Z A Z0 9 3 This precaution could avoid the risk of duplicate Orderld and its rejection by the EBICS Bank server 2 1 6 Service Providers Several service providers generate files e g payroll for multiple customers and send them to the banks of their customers In EBICS T profile the customer signs a contract with the bank but he may delegate the file transfer in a transparent or not manner to his provider Thus a service provider who has several customers receives a PartnerlD UserID from each of its customers It will have to ini
11. of maximum 20 Bytes y if self signed Signature Algorithm RSA SHA2 256 Y issuer subject Y validity Validity 5 years Y subject object or DN The attribute is commonname Y subjectPublicKeyInfo RSA KEY R e Y rsakncryption extensions 5s SubjectKeyIdentifier of the CA or KeyI AU ROFE YREVEGENET ETEF of the current certificate SubjectKeyIdentifier Y KeyUsage NonRepudiation Y ExtendedKeyUsage N CRLDistributionPoints N A N EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 24 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid Self Signed Certificate for Authentication EBICS T or TS A Mandatory Field X509 Value Y Yes N No version 2 Y Y serialNumber Random Number of maximum 35 octets if self signed Signature Algorithm RSA SHA2 256 Y issuer subject validity Validity 5 years Y i Y subject object or DN The attribute is commonname x LoS Y subjectPublicKeyInfo RSA key of 2048 bit length rsakncryption extensions R Pe SubjectKeyIdentifier of the CA or of Y AuthorityKeyIdentifier er aie ee a the current certificate SubjectKeyIdentifier Y KeyUsage DigitalSignature Y ExtendedKeyUsage N A N CRLDistributionPoints N A N Self Signed Certificate for Encryption EBICS T or TS Value Manda
12. the bank server of the correct or incorrect reception of the file and especially controls and rejects described in the preceding paragraph and which are primarily on the business file signature verification The rejection negative acknowledgments must mandatorily be transmitted to the customer workstation Sending positive acknowledgments is optional and depends on the bank s service offering The customer workstation must be able to retrieve both types of acknowledgments In Germany this functionality is currently performed using Kunden Protokoll OrderType PTK described in Chapter 10 of EBICS V2 4 2 Specifications For the implementation in France the target is the use of the PSR Payment Status Report retrieved using the FDL Download command or any other channel However the PTK can be used temporarily knowing that it has to be implemented on identifiers with a maximum length of 8 characters instead of the 35 characters of PSR identifiers Using the Payment Status Report The Payment Status Report ISO 20022 XML format pain 002 001 xx available at ISO www iso20022 org must be generated at file level Therefore items of the level 3 0 and beyond will not be filled in only GroupHeader level items or OriginalGroupInformationAndStatus will be filled in see Appendix A5 Format Payment Status Report Otherwise sending a Payment Status Report may be done by another channel mail Internet web portal by using a style sheet to ma
13. 6AphidodHRw Oi8vODYuNjQUMTAUMTM4LytDUONPQOErL2FzYV9jYSS5SjicmwwHwYDVROjBBgwFoAU ZM7nNDE4VQkAUz33C9ztxhG9P3gwHQYDVROOBBYEFNd6cAJ8L04eB7TiCzpcumIn gFSsMA0GCSqGS lb3DQEBBAUAA4GBAEm2OLIVyMIzf7Bk7ZUNBCQacvUEdl2058Pg py CMN K1 OdrLaNGZ77TIVKbydqwl2t7hlpuC81c8D309r3LiYSDrgxMFhxeUKLD slo1dusxXjV8nHm5V2zu4hOdrLaNGZix3bEEEFH cpzOp5y ogwHW Vpz6h3r36Lgo VI1S6JU6 Hash of the signature certificate SHA 256 B8 3C BO 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 V2 1 4 english version 24 02 2012 Page 32 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid Initialization Letter for the authentification certificate Date TT MM JJJJ Time HH MM SS Host Id BIC11 of the bank Bank name of the bank User ID XXXXXXXX Partner ID Yyyyyyyy Version Authentication X002 Authentification Certificate Type X002 If CA certificate Certificate issued to name surname or identifier Certificate issued by name the certification authority MIICcjCCAdugAwl BAgIBDZANBgkqhkiG9wOBAQQFADA6MQswCQYDVQQGEwWJGUjEY ZM7nNDE4VQkAUz33C9ztxhG9P3gwHQYDVROOBBYEFNd6cAJ8L04eB7TiCzpcumIn MBYGA1UECXxMPYmFucXVIcG9wdW xhaOdrLaNGZtYDVQQDEwggdHVyYm9zY TAeFwOw ODAS5MTAxMzl0OMzZaFwOxODASMDgxMzlOMzZaMDQxCzAJBgNVBAYTAmZyMRgwFgYD VQQLEw9iYW5xdW Vwb3B1bGFpcmUxCzAJBgNVBAMTAmpmMIGfMA0GCSqGS Ib3DQEB AQUAA4GNADCBiQKBgQCkscideEsfU0
14. An example of hash computation is described in annex 6 4 For historical reasons EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 16 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid 2 1 4 Initialization of IDs Each bank must inform its customers about the following information necessary to set up the customer workstation gt The HostID bank identification it is recommended that banks use a BIC with 11 characters possibly BIC 8 supplemented with XXX gt The UserID user or department name The syntax is free in accordance with the specified format a zA Z0 9 1 35 gt The PartnerlD contract subscription Number The syntax is free in accordance with the specified format a zA Z0 9 1 35 The last two identifiers will be provided by the bank when signing the contract It is recommended not to fill in the SystemID item There is always at least one user UserID per subscription The certificates are attached to the user Note Partner ID Subscription for a Company User ID User of this subscription In EBICS T profile in most cases a customer Company will have only one user However some companies may be more complex and may choice to have multiple users per subscription for example a user ID for the Accounting department and another user ID for another department eg Sourcing A given FileFormats RequestType will have the same
15. English translation for information purposes only Only the French version is valid EBICS Implementation Guide in France Version 2 1 4 This version is consistent with the V2 4 2 of the specifications NOTICE TO THE READER The documentation relating to the EBICS protocol designed in its original version by the ZKA German equivalent of CFONB was written in German and then translated into English Release 2 4 is the first joint French German release An update V2 4 1 has been published in September 2009 However the implementation of EBICS in France must be adapted to the national context ETEBAC 3 amp 5 migration national payment instruments The latest version of the specifications EBICS v2 4 2 published in February 2010 supplements or clarifies the version 2 4 1 for the implementation of the personal signature attached An exhaustive list of clarifications is available in the specifications this guide corresponds to version v2 4 2 The CFONB has developed this implementation guide to EBICS in France for the following reasons 1 the French practices in customer to bank files transfers had to be taken into account to ensure the smooth replacement of ETEBAC 3 phase 1 and 5 phase 2 protocols as well as the maximum flexibility in the migration 2 to replace ETEBAC3 adaptations were needed in relation to the securised functionalities offered by the transport protocol 3 to replace ETEBAC 5 adaptations were
16. UPqM13kKPUQVBFYB4xOcHCYqzr6PPgl7Co GwsjK504CKUm 7qWSOBdnqNOdrLaNGZ4kCxX XDg1SemWMIOgPtWI9T3XAiyyr88L Ei 9sisIUA JE 3leQWuk0gJXohtxKUwR fbsWrQjqLspxNKO9Urbqz8hwehPQID AQABo4GNMIGKMA4GA1 UdDWEB wQEAwlE8DA4BgNVHR8EMTAvMC2gk6AphidodHRw Oi8vODYuNjQUMTAUMTM4LytDUONPQOErL2FzYV9jYSS5SjicmwwHwYDVROjBBgwFoAU gFSsMA0GCSqGS lb3DQEBBAUAA4GBAEm2OLIVyMIzf7Bk7ZUNBCQacvUEdl2058Pg py CMN K1 OdrLaNGZ77TIVKbydqwl2t7hlpuC81c8D309r3LiYSDrgxMFhxeUKLD slo1dusxXjV8nHm5V2zu4hOdrLaNGZix3bEEEFH cpzOp5y ogwHW Vpz6h3r36Lgo VI1S6JU6 Hash of the authentification certificate SHA 256 2C A5 BA 6A 2B 56 01 92 35 2A B4 91 53 E9 0B BA B8 3C BO 19 66 C9 9C 6E 34 C1 5E B5 9F 4A 64 F7 Date Signature EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 33 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid Initialization Letter for the encryption certificate Date TT MM JJJJ Time HH MM SS Host Id BIC11 of the bank Bank name of the bank User ID XXXXXXXX Partner ID Yyyyyyyy Version Encryption E002 Encryption Certificate Type E002 If CA certificate Certificate issued to name surname or identifier Certificate issued by name the certification authority MIICcjCCAdugAwIBAgIBDzANBgkqhkiG9wW0OBAQQFADA6MQswCQYDVQQGEwJGUJEY ZM7nNDE4VQkAUz33C9ztxhG9P3gwHQYDVROOBBYEFNd6cAJ8L04eB7TiCzpcumIn MBYGA1UECxXMPYmFucXVIcG9wdW xhaOdrLaNGZtYDVQQDEwggdHVyYm9zY TAeFwOw ODAS5MTAxMzl0OM
17. ated July 15 2009 EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 4 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid 1 2 Common implementation rules 1 2 1 Interoperability between customer workstations and bank servers Each customer workstation must be able to connect to various bank servers which are in conformity with the recommendations of this guide It should be possible to add or remove a bank connection to an already installed workstation 1 2 2 The ways to implement EBICS in France They can be of two kinds either related to French interbank recommendations or related to the service offered by one or more banks gt The French interbank recommendations are related mainly to The Order types see Annex A1 The naming of files FileFormat Request type see Annex A2 The type of certificates Certificates see Annex A4 depending on the profile T or TS To limit the list of order types there are not as many order types as file types unlike in the German implementation but the file type is a value of one set up of the order FileFormat request type gt Specific Bank services may include Others controls to be carried out by the protocol on the banking data e g monitoring of the amount or account specific levels of security proprietary file types proprietary types of information the bank choice to make specific settings mandato
18. ccess if OCSP service Freshest CRL If DeltaCRL is used Authority Information Access CRLDistributionPoints If OCSP service EBICS IG CFONB V2 1 4 english version 24 02 2012 doc 02 2012 Mandatory Y Yes N No N but non critical if present N but non critical if present Y but non critical with DeltaCRL Y but non critical with OCSP Page 28 sur 37 English translation for information purposes only Only the French version is valid A3 3 Structure of the certificates for EBICS bank servers It is necessary to have a certificate for each usage ie in the current version 2 4 1 2 certificates per server bank authentication and encryption Both server certificates are treated as SSL TLS certificates and must therefore have both the KeyUsage of DigitalSignature and of KeyEncipherment The signature certificate is not provided in EBICS 2 4 1 for ETEBAC 3 and ETEBAC 5 migration Server Certificate for Authentication Mandatory field X509 Value Y Yes N No version 2 for X509V3 Y serialNumber Y Signature Algorithm RSA SHA2 256 Y issuer Y validity Validity 5 years k Y subject object or DN The attribute is commonname subjectPublicKeyInfo ROA KEY SR ee Y rsakncryption extensions AuthorityKeyIdentifier Y KeyUsage DigitalSignature KeyEncipherment Y CertificatePolicies Y CRLDistributionPoints E FreshestCRL N ExtendedKeyUsage N
19. f the order is also called execution order or personal electronic signature It authenticates personally the sender of a message Separate signature The instructions and signature of the order are not transmitted in same flow but in an asynchronous way They can be transmitted through the same or different channel at to the same moment or shifted time Society for Worldwide SWIFT Interbank Financial Transaction TLS Transport Layer Security f Verteilte Elektronische VEU Uinterconntt Separate Signature Process in EBICS Normalized packet switching network used in France ae Kan by ETEBAC German Standard Organization to normalize banking zentaier area context in Germany ZKA KreditAusschuss New name since 2011 DK Die Deutsche Kreditwirtschaft EBICS IG CFONB V2 1 4 english version 24 02 2012 doc 02 2012 Page 37 sur 37
20. ficate is issued by a certification authority to facilitate the reconciliation it is recommended to print the following certificate data on the initialization letter or in the contract for an automatic reconciliation process gt certificate issued to name surname ID subject field NC gt certificate issued by name the certification authority issuer field CN EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 31 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid Initialization Letter for the certificate with signature of transport Date TT MM JJJJ Time HH MM SS Host Id BIC11 of the bank Bank name of the bank User ID XXXXXXXX Partner ID Yyyyyyyy Version Signature A005 Signature certificate Type A005 If CA certificate Certificate issued to name surname or identifier Certificate issued by name the certification authority MIICcjCCAdugAwlBAgIBDZANBgkqhkiG9wOBAQQFADA6MQswCQYDVQQGEwWJGUjEY MBYGA1UECxMPYmFucXVIcG9wdW xhaOdrLaNGZtYDVQQDEwggdHVyYm9zY TAeFwOw ODASMTAxMzl0OMzZaFwOxODASMDgxMzlOMzZaMDQxCzAJBgNVBAYTAmZyMRgwFgYD VQQLEw9iYW5xdW Vwb3B1bGFpcmUxCzAJBgNVBAMTAmpmMIGfMA0GCSqGS b3DQEB AQUAA4GNADCBiQKBgQCkscideEsfU0 UPqM13kKPUQVBFYB4xOcHCYqzr6PPgl7Co GwsjK504CKUm 7qWSOBdnqNOdrLaNGZ4kCxX XDg1SemWMIOgPtWI9T3XAiyyr88L Ei 9sisIUA JE 3leQWuk0gJXohtxKUwR fbsWrQjqLspxNKO9Urbqz8hwehPQID AQABo4GNMIGKMA4GA1 UdDWEB wQEAwlE8DA4BgNVHR8EMTAvMC2gk
21. g either a date or a range of dates depending on the services provided by the bank The range of possible dates will depend on the archiving duration of the bank server Each bank may set a different archiving duration for each file type this information should be included in the subscription contract Making files available beyond their online period archiving duration is not in the protocol field Note Some banks may offer specific reporting services various reporting frequencies The method described for naming the files can cover the needs for these services Banks may use proprietary extensions in the file name used in the FileFormat This type of setting specific to an institution should be indicated in the annexes of the subscription contract The FDL command has only one FILE FORMAT parameter So only files with the same type could be concatenated EBICS customer workstation will have to handle this case The FDL command without date range allows the customer to get all available reports not yet retrieved EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 21 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid 3 USE OF THE CUSTOMER WORKSTATION Before the implementation of the connection between a customer workstation and a bank server a contract must be signed between the customer and the bank The contract must include a document indicating the specific data f
22. igitalSignature 1 ExtendedKeyUsage id kp clientAuth N but non critical if present N but non Be careful to critical character critical if present Subject Alternative may include mail address Be careful Name to critical character Issuer Alternative Name May be completed with CRLDistributionPoints AuthorityInformation access if OCSP service Y but non itical Freshest CRL If DeltaCRL is used ee with DeltaCRL Y but Authority l oe A If OCSP service critrical Information Access with OCSP EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 27 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid AC Authenticate Encipherment On hardware or software device Value Field X509 N A Not Applicable Z2 for X509V3 Single for AC Name max length 20 Bytes validity 3 years subject objet ou DN User Id including the CommonName subjectPublicKeyInfo RSA Bey with 2048 bits Key Length rsaEncryption AuthorityKeyIdentifier AC SubjectKeyIdentifier SubjectKeyIdentifier Keysage k ExtendedKeyUsage id Subject Alternative may include mail address Be careful Name to critical character A RSA SHA2 256 or SHA1 160 Al hm a iaaitaacai goear intermediary phase for 3 years a yEncipherment 1 kp emailProtection Issuer Alternative Be careful to critical character Name Possibly may be completed with AuthorityInformation a
23. ignature or with more than 2 signatures is rejected by the EBICS server Joint Signature without DS VEU mode EBICS profile TS Personal Signature 0 1 2 gt 2 Expected ES 1 One or two E class signatures are expected Any other combination with A B ou T Expected ES 1 A causes a reject Double signature required 2 E class Expected ES 2 signatures are expected Double signature required All other Pe combination with A B ou T causes a reject EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 7 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid gt Example with 1 personal signature expected In this case one signature is required for national Direct debits FileFormat ddd Contractually the definition for the file FileFormat ddd is ES quantity 1 However the file is not rejected by EBICS protocol if it contains 2 signatures but will be rejected by the back end Reject if transport type signature but not if double signature gt Example with 1 or 2 personal signatures expected In this case 1 signature is required for small amount credit transfers and 2 signatures for big amounts Contractually the association for the file FileFormat sct is ES quantity 1 All files received with 1 or 2 signatures are accepted by the EBICS server Big amounts credit transfers are rejected by the business app
24. ke it readable In Appendix A5 Format of the Payment Status Report are described the data needed to match a PSR with the corresponding remittance order Generation of a Payment Status Report is mandatory for any failed transaction It s not necessary to create a PSR for each remittance file in failure but in the case of multiple remittance files the server may at the end of the transmission create a technical concatenation of several XML files presence of several headers in the same XML file ina EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 20 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid single PSR In this case the PSR can not be deparsed directly by the customer workstation It should be previously cut in unitary XML files before parsing each one PSR only covers the FUL command UPLOAD and should not be generated for other commands INI HIA 2 2 3 File retrieving by the customer workstation the Download command FDL The Download order FDL without setting a date is used to retrieve all the files available not yet retrieved the bank server provides all the files in storage Those of the same type are concatenated before being zipped and encrypted for the transfer thus forming a single file After sending the files are automatically archived on the bank server Then they can be retrieved again using the Download order FDL with a set up includin
25. le with this target It therefore is autorised to use temporarily for server certificates either self signed certificates or private CA certificates in RSA 2048 bits and RSA2048 SHA2 for the signature algorithm and later to migrate towards certificates issued by CA bank and non bank providing these characteristics The customer workstation will have to download the public keys from the bank server using the HPB command download public bank key and then check them see EBICS V2 4 2 specifications Chapter 4 4 2 It is not necessary to automate the HPB command in every exchange However we strongly advise to send it upon receipt of an anomaly tending to the renewal of the bank certificate In HPB command the bank must send the X509 certificates with the public keys As for the public keys of the customer workstation this check may be made by sending in parallel of the EBICS exchange a confirmation document by another channel this document may be the Print of the certificate see Appendix A4 The customer workstation should be able to provide a simple procedure to match the public keys transmitted using EBICS and the ones received by another channel 2 1 2 5 Certificate revocation Certificates issued by a CA may be revoked Search for CRL Certificate Revocation List or control the status of the certificate in the OCSP Online Certificate Status Protocol must be done for each CA accepted by the Bank so only if the certificatio
26. lementation Guide Tis ANTRODUG TION nnen E a cose Ee 4 less P rpos and Scope OF the gude sisnei nis acire rien a aa EE ESEE a PEOTI EEE STES 4 1 2 Common implementation rules eeeseeeeeseeeseeeeesetsseserssressesersstesstserestessesstestesseeseeseessreseeseeesresst 5 1 2 1 Interoperability between customer workstations and bank servers 0 5 1 2 2 The ways to implement EBICS in France ccccccccccssseseeeeeeeeeeeeseeeeeeeeeeeeeeeeeeneees 5 1 2 3 Securing the file transfers eeceeeeeeeeeeeeeeeeeeeeeeeeeeeeeeseneeeeeeeeeeeeeseeeeeeeeeeeeeees 5 1 2 4 Implementation Of a CONTIACT cceeeeeeeeeeeeeeeeeneeeeeeeeeneeeneneneeeeeeeeeeeeeeeeeaeeeeeeeeeneees 6 1 2 6 Specific characters niai eeaeee eaea de oseane aae dene ddaa durai re eedi sainda uaa 9 1 2 7 ASCII EBCDIC Coding ssnnssssnnnnnnnennennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn nnmnnn 9 LEA e A EA 9 1 2 9 Line feed delimiter management CR LF CRLF Or NO issssssssssssssssssnnnnnnnnnnnnnnnnn 9 2 IMPLEMENTATION sc tipte pinea a ener alte eel e AEREA bet eth EREE EE RENT 10 rA O i o AE E E E Mees tives EEE E E 10 2 1 1 General schemata of the security SettingS cccecceesseeeeseeeeeeeeeeeeeeeeeeennees 10 2 1 1 1 EBICS T example execution order on a separate channel and usage of self signed certificates nasini nninnni nananana nananana annainn aana ainicisials ein aa einiaidiaisiaisis 10 2 1 1 2
27. lication if they have not 2 signatures Indicator optional double signature one E or two E E class signatures are expected gt Example with 2 personal signatures double signature mandatory In this case two signatures are required for the treasury credit transfers Fileformat ict Contractually the association for the file FileFormat ict is ES quantity 2 Personal Signature 2 2 Comment _ Double signature mandatory two E class Ge a BISA signatures are expected Expected ES 2 Vouble sig oe E art ca E ompbinatio EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 8 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid 1 2 6 Specific characters The authorized characters in the protocolar exchanges are defined by the XSD schema The specific characters used in France or Germany e g a B A are excluded from the protocol itself by the schema XSD In the files the characters used are those defined in the standards 1 2 7 ASCII EBCDIC Coding The exchange of files in ASCII coded characters is recommended If the bank proposes to send EBCDIC files the indication EBCDIC must appear in the tags FULOrderParams on the following model lt FULOrderParams gt lt Parameter gt lt Name gt EBCDIC lt Name gt lt Value gt TRUE lt Value gt lt Parameter gt lt FileFormat CountryCode FR gt pain xxx cf
28. n chain is registered and under the conditions of the CRL publication by the CA If the certificate is revoked regardless of the SPR command user using the server updates the user status to 8 Suspended by user SPR that no longer allows any file transfer All file transfers initiated by the user will have to code error 091004 EBICS_ INVALID _USER_STATE 2 1 2 6 Errors messages related to Certificates Any error about certificate management must be announced by a message Disclaimer The list of error messages related to Certificates is available on the CFONB website www cfonb org in the Documentation section ETEBAC Migration to SWIFTNet and EBICS EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 15 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid 2 1 3 Electronic signature and encryption 2 1 3 1 Main principles The EBICS V2 4 1 version supports the electronic signature coded A004 A005 or A006 But the A004 version of the signature will not be used in France because it is not compatible with the use of certificates so only versions A005 and A006 will be used in France Using signature A006 is not recommended for problems of current availability of hardware The A005 version of the signature is recommended in France The AES encryption algorithm is used 2 1 3 2 Remarks on signature computing e System characters such as CR LF and Ctrl Z have not to be i
29. nce and bank servers located in France The choice to extend it to cross border communications is the responsibility of software vendors or banks This guide is specifically designed to describe the set up of customer workstations but it also gives recommendations for configuring bank servers The implementation should respect the existing recommendations and regulations including those relating to banking and or financial services on Internet SBF1 refer to website www ssi gouv fr site_documents pp ppcr0401 pdf This guide describes the procedures for EBICS Protocol implementation gt asa successor of ETEBAC3 with a confirmation by an other channel than EBICS of the execution order Later in the document this terms will be described as EBICS profile T transport gt or asa successor of ETEBAC5 with the customer electronic signature of the execution order attached to the order Later in the document this mode will be described as EBICS profile TS transport and personal signature Note The EBICS protocol allows a disjointed signature of the orders via EBICS this function is not addressed in this version of the implementation guide but will be included in a later DS Distributed Signature profile The term bank used in this document should be understood as a Payment Service Provider PSP under 2007 064 CE Payment Services Directive dated November 17 2007 The French transposition is the Ordonnance 2009 866 d
30. ncluded in the hash computing in the versions A005 and A006 e With A006 there is a double computing of the hash signature is not computed on the message itself Si Hash M but on the hash of the message Si Hash Hash M e The signature is calculated on the Signedinfo tag after C14N cononicalization then the cononicalization is hashed e Hashing is calculated on the certificate previously encoded by DER without characters CR LF Ctrl Z e The 2 following paddings can be used ANSIX923 The ANSIX923 padding string consists of a sequence of bytes filled with zeros before the length 1 010126 The 1S010126 padding string consists of random data before the length The detection of the padding method of is done by finding the type of padding zeroes or random data e PKCS1 V1 5 should be used to encrypt the encryption key e The cononicalization must add the default values In an XML document only the namespaces used in the XML document should be indicated Other namespaces must not be shown The link for the canonization is http www ebics org index php id 38 e The XML DSIG distinguishes between XML documents with or without comments In EBICS The Algorithm for cononicalization is defined via http www w3 org 2006 12 xml cl4n11 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
31. ol commands are classified into two categories e The system orders related to the management of e The bank technical orders related to a format The list of commands supported by the French servers is a subset of commands and EBICS are considered as system orders except orders FUL and LDF which are the only commands and upload download file allowed in France The list below is the complete list of OrderType mandatory in France The other Ordertypes are optional The implementation of the HTD Ordertype Download subscriber s customer and subscriber Data is recommended A server receiving a command that it can t process must send the return code EBICSS_UNSUPPORTED_ORDER_TYPE Identification Name Format HCA Send amendment of the subscriber key for identification and authentication and encryption HCS Transmission of the subscriber key for ES identification and authentication and encryption HIA Transmission of the subscriber key for identification and authentication and encryption within the framework of subscriber initialisation HPB Transfer the public bank key download HPD Download bank parameters INI Send password initialisation Customer s public key for the ES HEV Download supported EBICSS versions PUB Send public key for signature verification Customer s public key for the ES see Appendix Chapter 15 SPR Suspension of access authorisation Transmission of an ES file with a signa
32. onb160 dct lt FileFormat gt lt FULOrderParams gt 1 2 8 Parser Fixed format files can contain multiple logical iterations order files provided that they are with an identical FileFormat In this case they can be placed one after the other and merged in a single physical file The variable format XML files follow the same mechanism only in exchange for the bank to customer a physical file can contain multiple logical messages merged without any tag Accordingly before any processing it is necessary to disassemble these messages to integrate them in a parser 1 2 9 Line feed delimiter management CR LF CRLF or no For customer to bank exchanges the bank server software must support files containing any line feed delimiter including no delimiter For bank to customer exchanges the workstation software must also process files containing any line feed delimiter including no delimiter EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 9 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid 2 IMPLEMENTATION 2 1 Set up 2 1 1 General schemata of the security settings 2 1 1 1 EBICS T example execution order on a separate channel and usage of self signed certificates penne eee Oe Contract N Contract o gt Capture of the customer contract Production of the Customers Identifiers Recording of the Customer Identifiers Hostld Use
33. or this subscription So there will be a contract and a set up for each bank It is the responsibility of software vendors to make available to customers the features needed to secure the access to the customer workstation and the sensitive data The customer must have the tools to secure the Internet connection firewall anti virus and keep them up to date When the customer workstation stores certificates in a database it will have to provide a level of security data encryption adequate and equivalent to that of the EE or Java Key Store Each customer workstation and each bank server keep a record of all transactions Log with time stamp amount It must be possible to retrieve the end to end log of each transaction and to transmit it to the bank mail It is recommended that the user interface and the prints are in French In order to provide any evidence in the case of a conflict the client must keep the signed files such as delivered to the Bank as well as all other necessary data EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 22 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid 4 ANNEXES A1 Order Type EBICS Specifications 2 4 1 apply in France and Germany but the controls OrderType coupled to a specific file format will not be used in France For this feature in France we use the OrderType FUL associated with specific FileFormat The protoc
34. ormat Following the procedures defined between the Bank and its client contractual client must be set gt EBICST In transport mode EBICS T profile client confirms its orders by another communication channel In this case the customer workstation is set up with user class signature T transport ES quantity 0 Separate Signature without DS VEU mode EBICS profile T Personal signatures 0 1 2et OrderAttributes DZHNN all signatures are taken as transport signatures regardless of class A B E ou T assigned to the user Awaited ES 0 REJ Reject This parameter gives the number of personal signature see EBICS specifications 2 4 2 EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 6 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid gt EBICS TS With EBICS TS signature attached to the execution order the user signs electronically the order file and sends jointly the order file and the execution orders via EBICS In this case the customer workstation is set up with user class signature E electronic signature The signature of this user has power to authorize the orders as written in the contract between the user and the bank through his signature made by a personal certificate issued to him by a CA and recognized by the Bank Depending on the number of Expected Signature related to the FileFormat and described
35. ot be calculated on the bank server Thus this synchronous control does not provide all guarantee for non repudiation of the remittance file since it is performed based on the hash sent by the customer workstation The EBICS protocol guarantees the integrity of each EBICS command by the electronic identification authentication signature of the user issuing the message The signature is used at two levels All remittance files are signed with an electronic signature The result of this signature is stored in a field in the Initialization message transmitted with the calculated hash of the file on the customer workstation The class of the signature is execution order personal signature or transport depending on the user profile set for the user in the bank server EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 19 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid e Each EBICS message is authenticated with the authentication key of the user sending the message The signature mechanism uses a XMLDsig signature The complete list of fields of the message included in the calculation of the signature can be found in the specifications It may be recalled that the signed data are generally sensitive such as the hash and the file containing the signatures The signature control of the remittance files is based on the matching between the hash sent by the customer workstation and tha
36. pose is to specify the methods of implementation and the settings It is the responsibility of software suppliers to provide a user manual This user manual will have to contain the list of EBICS return codes as well as the return codes specific to the application with an explicit narrative for each This implementation guide is a supplement to the EBICS documentation gt The general specifications Release 2 4 2 in German or translated into English and annexes OrderTypes et Return codes gt The Implementation Guide Release 1 7 in German http www ebics de index php id 93 or translated into English http Awww ebics org index php id 93 Reading this documentation is a prerequisite for a proper understanding of this guide This guide is based on EBICS release 2 4 2 common to France and Germany codified H003 in the messages which has been implemented in both countries from autumn 2009 The target is to use identically the EBICS protocol in France and Germany However considering the existing solutions in the two countries the mode of implementation of this release will be slightly different from one country to another In addition the use of some optional features being in the competition area it is the user responsibility to check the service level offered by its banking institutions and to parameterize the software accordingly The scope of this CFONB guide is limited to file transfers between customer workstations located in Fra
37. r TCP IP Data file Remittance file File containing order s remittance data FileFormat Typically for France it is the nature of the transaction in order FUL and FDL EBICS IG CFONB V2 1 4 english version 24 02 2012 doc 02 2012 Page 36 sur 37 English translation for information purposes only Only the French version is valid Name or Acronym Acronym Signification Definition Hash Seal Single numeric value representing data for integrity Seal of the control operation certificate The Internet Protocol IP is a protocol used for data IP laternat Protocol transmission across a packet switched internet network using the Internet Protocol Suite also referred to TCP IP Order Type Type of remittance or upload transaction In Germany it includes the nature of the transaction Execution order See order s signature PEM is a DER Format encoded in base64 with ASCII PEM Privacy Enhanced Mail headers See also DER It may contain private keys public keys and X509 certificates Request Type Type of the request included in the EBICS transaction Seal calculation Mathematical function allowing data integrity s control Transport signature Signature allowing to guarantee the origin and integrity of a message s data It is not a personal signature It does not have mandate value Personal signature Execution order Confirmation The signature o
38. r by file In EBICS TS each signatory shall have a personal signature certificate on physical device whose structure is consistent with that shown in Annex A3 This personal signature certificate is mandatory issued by a CA that is recognized by the Bank Data associated with the signatory are his first and last name the name of the CA used by signatory a data in the certificate ensuring the uniqueness of the certificate within a CA Depending on the s CA this data can be DN SAN or a serial number In EBICS T these signatories are attached to an EBICS user class T In EBICS TS these signatories are attached to an EBICS user class E Reminder each transport or signatory user Userld must hold 3 certificates signature encryption authentication for a signatory user Userld only the signature certificate must necessarily be issued by a CA in the subscription initialization phase INI and HIA orders 2 cases arise to validate the user Userld If the certificate is an auto generated certificate signature control of the mail sent to the Bank containing the hash of the certificate and signed by an authorized person in the company If the certificate is issued by a CA matching between the data mentioned in the contract and those issued from the certification chain 1 2 5 Integrity and signature of the file transfers The ES Quantity parameter is set up on the server based on the contract and on the FileF
39. rld and bank URL Partnerld Production of customer keys printing and sending another channel mail a NY Capture and recording of the Customer keys on EBICS Initialisation the bank server host Sending of the 3 certificates Authentification Encryption and Signature with by INI HIA commands Downloading of the bank Certifica with by HPB command Recording of the Bank certificates in the database of the customer workstation Tests _ First customer remittance of orders EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 10 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid 2 1 1 2 EBICS TS example joint execution order and usage CA certificates Authentification Encryption and Signature ete PEETELI gt TT Bank Capture of the customer contract Production of the Customers Identifiers HostId Userld Partnerld a NN Capture of the Recording of the Customer Identifiers stomer and bank URL certificate Loading of customer certificates parameters on the EBICS Initialisation bank server Most AC DN Ss walle ATN Sending of the 3 certificates Authentification Encryption and Signature with by INI HIA
40. rsion 2 4 1 of the specifications 1 1 C Complementarities of the migration phases 1 2 5 A ASCII EBCDIC Coding All C PSR is at disposal and not sent 2 1 2 2 C Remarks on signature computing 2 1 4 C Case _of the service providers A2 A File naming Addition of the protocol level of the PSR type pain 002 001 02 ack A 5 A M Format of the Payment Status Report VO 2 0 04 2010 Personal signature management All A M Replacement of the phase 1 amp 2 concept for designation of EBICS Profile T and EBICS profile TS 2 1 5 A Multi users management within the same customer A5 M Payment Status Report Format annex in a dedicated document VO 2 1 05 2010 All C Clarifications on V2 0 No rejection of remittance when ES quantity 1 with 1 2 5 M 2 signatures received Rejection when more than 2 signatures are received VO2 1 1 01 02 2011 A 3 2 M KeyUsage pg 25 26 27 VO2 1 2 21 06 2011 21 21 c These clarifications allow to respect the security rules SE for personal certificates VO2 1 3 13 10 2011 1 2 9 C Line feed delimiter management VO2 1 4 24 02 2012 128 c Add in the second paragraph only in exchange for the bank to customer l E Error M Modification C Clarification S suppression A Addition Extension EBICS IG CFONB V2 1 4 english version 24 02 2012 doc 02 2012 Page 2 sur 37 English translation for information purposes only Only the French version is valid Summary Imp
41. ry or optional the period of availability of the files on the server the procedures for retrieving those files by the customer The specific rules related to specific bank services are not covered by this guide In order to configure the installation each bank must provide in advance to his customer the information needed to describe its subscription 1 2 3 Securing the file transfers The EBICS Protocol provides security for the file transfers at two levels gt onthe network with the https protocol based on the bank server certificate gt At the level of the application protocol by using certificates dedicated to authentication confidentiality and integrity signature usages At the network level confidentiality of exchanges on the internet network is established through a https TLS Transport Layer Security layer connection This is based on using a server certificate at the Bank Information System IS This certificate previously checked and accepted by the client before any Exchange Protocol will allow a first level of Bank Server authentication by the Customer workstation After establishing the https channel all data EBICS orders client data and signatures will be carried in this TLS secure network At the application level the EBICS Protocol provides 1 mutual authentication of the Customer workstation and server using client and server certificates dedicated to this authentication service 2 Confidentiality in addition
42. s will be renewed following the indications of the CA s certification policy and SEND to the server with EBICS orders PUB and HCS described in Chapter 10 specification EBICS 2 4 2 o Signature certificate EBICS T for the sealing of the messages self signed or generated by a CA that is recognized by the Bank and on hardware or software media EBICS TS mandatorily generated by a CA recognized by the Bank and on hardware for personal signature The media type will be deducted from the value of the ID OID CA certificate policy The signing certificate will be either exclusively used for signature or be a multi purpose certificate only used for signing In all cases it will be different from authentication and encryption certificates EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 12 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid gt On the bank server Two certificates self signed or generated by a CA with a RSA SHA algorithm 256 and 2048 bit key length Self signed certificates will be valid for 5 years at most EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 13 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid 2 1 2 3 Initialization of customer certificates and sending of public keys to the bank server The bank server needs three public keys from the customer workstation one per usage authen
43. t calculated by the bank This one is done on the file received by packets of 1MB the calculation could begin in synchronous mode before the end of the reception of the last packet or in asynchronous mode after completing the communication with the customer workstation Each server can choose its mode of operation asynchronous or synchronous The choice is left open for implementation In synchronous mode it is possible to decompress decrypt and check the signature of the remittance file before sending the response frame to the customer workstation i e before the end of the EBICS transaction Indeed in the last frame sent by the EBICS customer workstation the last segment contains the data identified by the tag lt SegmentNumber lastSegment true gt The server has the opportunity to verify the signature and return if any an error EBICS_SIGNATURE_VERIFICATION_FAILED in the response frame to the receipt of the last segment In asynchronous mode when the EBICS transaction is completed the received remittance file has not yet been decompressed decrypted and its signature integrity has not been checked However any errors detected on the remittance file must be made available at all times for EBICS customer workstation by PSR or PTK as described in the following paragraph 2 2 2 3 Communication to the customer about the receipt of order remittance file When using the asynchronous mode the customer workstation must be informed by
44. te in a printable format necessary for the reconciliation In the bank the validation is done by matching these data Optionally if proposed by the bank this certificate confirmation file can be transmitted by another secured electronic channel different from EBICS as it is designed to be integrated automatically on the bank server As the safety of a simple mail not secured is not guaranteed sending this file by mail not secured is not recommended gt Using a certificate issued by a CA When using a certificate issued by a Certification Authority CA the control of the certification chain of the certificate is possible through a fully automated reconciliation following the internal rules of each bank In EBICS T the certificate is processed as a self generated certificate In EBICS TS if the signature certificate has been issued by a CA non reconised by the bank then the certificate is rejected in the initialization phase EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 14 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid 2 1 2 4 Retrieving the public key certificates of the bank by the customer The recommended targeted template of the certificates will be 2048 bits for the RSA key length and RSA2048 SHA2 for the signature algorithm The EBICS launch in France is done with these characteristics of the certificate Currently some CA s are not yet compatib
45. the message using the value D in the first field of OrderAttribute that the file transfer is using Transport as signature class In EBICS TS profile this field must contain the value O Reminder For other commands the value of the first field of OrderAttribute will conform to EBICS 2 4 2 specifications see table on page 275 of the detailed specifications 2 2 2 Processing of the order remittances Using the FUL command each signature class is in relation with a FileFormat 2 2 2 1 List of pre validation controls In Upload in the first message the initialization one various controls so called pre validation are planned e Certificates control 3 public keys based on the information sent by the customer workstation during the initialization stage e Amounts control limits e Accounts checking Among these the certificates control is highly recommended for bank servers in France Checking the amounts and accounts is optional for EBICS bank servers in France and each bank can decide to implement them or not If the bank server does not manage these controls it replies by a negative response to the customer workstation 2 2 2 2 Security checks of received remittance files The first message the initialization one contains the hash of the remittance file calculated by the customer workstation as well as the file with the digital signature s At this stage the remittance file is not yet uploaded so the hash cann
46. tialize with each bank for each customer EBICS T profile Service provider shall bear the management of authentication encryption and signing certificates EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 17 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid EBICS TS profile the signature certificate is under the responsibility of the customer and therefore under his exclusive permanent control The service provider must provide a secure environment to the customer which has to sign himself each file before their delivery to the Bank 2 1 7 Tests A test of the file transfer is necessary before any transfer of real files Therefore each server must be able to receive test and production files Contractually the customer will have to be able to test with a workstation software able to do so In addition it should be possible to be in test mode with a bank and in the operational mode with another one The following recommendation specifies the conditions of these tests The customer workstation must have a set up which allow switching from test mode to production mode Its use can only be made at the initiative of the customer in agreement with its bank In order to avoid potential confusion between operational and testing flows it is not desirable that this distinction results from a manual intervention at the bank server level In France it is recommended to use
47. tication encryption and sealing Each public key is stored in a certificate on hardware or software media dependinbg on their eligibility characteristics see 2 1 2 2 Each of the 3 certificates for the three types of usages is transmitted to the server in an initialization file using the EBICS protocol according to the XSD schema of EBICS V2 4 The reconciliation process will differ depending on the case Two cases are possible using a self signed certificate using a certificate issued by a CA gt Using a self signed certificate When using a self signed certificate this validation is not possible by the certification chain The authentication must be ensured by a second mechanism different from the initialization file generated by the customer workstation This is done by sending to the bank in parallel with the certificate via EBICS a confirmation by another channel printing and sending a pdf by mail fax download The way to send this confirmation is out of the scope of this guide but must be stated in the customer bank contract In France sending 3 documents one per certificate is mandatory This authentication can also be made by manual signature on the printed version of the initialization file see Annex A4 Print the certificate This document includes the certificate in DER format together with information identifying the user user ID partner ID and possibly UserName and the seal hash of the certifica
48. to that provided by https by data encryption using client and server certificates dedicated to this encryption service 3 EBICS Profile T for the integrity of data transmitted by the client to the Bank server the data are sealed by electronic signature by using a certificate dedicated for this feature The execution order is transmitted by another communications channel than EBICS EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 5 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid 4 EBICS Profile TS for integrity and non repudiation of the data transmitted by the client to the Bank server data are signed electronically using a certificate for this feature The electronically signed execution order attached with the data has execution order value 1 2 4 Implementation of a contract It is recommended in a contract to always define a Userld physical person or service for Transport This transport Userld has in principle all transport rights for all the files of the contract including all reporting files This transport Userld as its name implies has of course no signature rights on the orders transmitted All the users Userld allowed to personal signature Signatory must be named in the contract For each FileFormat are listed the rights of each signatory on this FileFormat simple signature dual signature dual optional signature possibly maximum amount by order o
49. tory Field X509 N A Not Applicable Y Yes N No version 2 Y Y serialNumber Random Number of maximum 35 octets if self signed Signature Algorithm RSA SHA2 256 Y Y issuer subject validity Validity 5 years Y Y subject object or DN The attribute is commonname subjectPublicKeyInfo RSA key Of 2048 Dit eng Y rsakncryption extensions AuthorityKeyIdentifier SubjectKk y d nerf r of the CA or of Y current certificate SubjectKeyIdentifier Y KeyUsage keyEncipherment or keyAgreement Y ExtendedKeyUsage N A N CRLDistributionPoints N A N This is valid only for self signed certificates The term of validity of CA certificates will depend on the Policy of the CA for this type of certificate EBICS IG CFONB V2 1 4 english version 24 02 2012 doc 02 2012 Page 25 sur 37 English translation for information purposes only Only the French version is valid CA certificate use Each bank determines the certificates compliant with the structure described below that it agrees for the personal signature AC Signature Certificate Mandatory on hardware device for TS profile 2 Value Mandatory Field X503 N A Not Applicable Y Yes N No 2 for X509V3 a Single by AC registered with max Signature Algorithm RSA SHA2 256 or SHA1 160 intermediary phase for 3 years subject objet ou DN User Id including the CommonName a a i RSA K ith 204 j K L h rsakncryption fetensions O OOSOCSOSC CSC S Authori
50. ture for a dummy file that only contains a space FUL File Upload Upload files whose type is in parameter FDL File Download Download files whose type is in parameter PTK Kunden Protokoll EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 23 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid A2 FileFormat Request Type Files names Disclaimer This annex named Annexe 2 EBICS SWIFNet Nommage Fichiers is available on the CFONB website www cfonb org in the Documentation section Migration ETEBAC vers EBICS et SWIFTNet A3 Certificates A3 1 Errors messages related to Certificates Disclaimer This annex named Annexe 3 Certificates error codes is available on the CFONB website www cfonb org in the Documentation section Migration ETEBAC vers EBICS et SWIFTNet A3 2 Structure of the certificates for EBICS customer workstations The certificate for EBICS customers can be self signed or imported on the customer workstation if it is issued by a private Certificate Authority CA Three usages are defined for EBICS and three certificates are required Self Signed Certificate Usage Self Signed Certificate for signature EBICS T only Value Mandatory Piera X302 N A Not Applicable Y Yes N No version 2 for X509V3 Y dita Nunber Random Number
51. ture must be different from each other for single userID Nota bene 1 in two different contracts physical person can have two different userID using the same triplet Nota bene 2 to the reconciliation it is underlined that the customer workstation must be able to print all initialization letters for each certificate of each userID 2 1 2 2 Characteristics of eligible Certificates When certificates are issued by a CA recognized the bank the algorithm used by the certification authority to sign these certificates is either RSA SHA 1 algorithm and this for a temporary and non renewable maximum period of 3 years and replaced by the RSA SHA2 256 target either directly with an algorithm RSA SHA2 256 all certificates issued by a CA 3 year target In all cases the EBICS messages are signed with a SHA2 algorithm The SHA1 algorithm is allowed only for the CA s signature Certificates may be placed on different media gt On the customer workstation o authentication certificate on hardware or software media self signed or generated by a CA that is recognized by the Bank o Encryption certificate on hardware or software media self signed or generated by a CA that is recognized by the Bank Self signed certificates must be renewed after a period of 5 years Except change due to a security alert they can be renewed at the end of this period either again by self signed certificates or CA certificates CA certificate
52. tyKeyIdentifier AC SubjectKeyIdentifier ContentCommitment 1 id kp emailProtection N N but non critical if present N but non Be careful to critical character critical if present xX Y Y Y Y Y X Y Y Y Subject Alternative may include mail address Be careful Name to critical character Issuer Alternative Name May be completed with CRLDistributionPoints AuthorityInformation access if OCSP service Y but non Freshest CRL If DeltaCRL is used critical with DeltaCRL Y but non If OCSP service critical with OCSP If the qualified certificate contents v if QCStatement OID pointing out the certificate is Susie fied qualified and the private key of the Cartificate certificate is stored within a SSCD Authority Information Access EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 26 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid AC Authenticate Certificate On hardware or software device 2 Value Mandatory Field X509 N A Not Applicable Y Yes N No 2_ for X509V3 Single for AC Name max length 20 Bytes i RSA SHA2 256 or SHA1 160 Al hm a iaaitaacai goear intermediary phase for 3 years validity 3 years subject objet ou DN User Id including the CommonName subjectPublicKeyInfo RSA Bey with 2048 bits Key Length rsaEncryption AuthorityKeyIdentifier AC SubjectKeylIdentifier SubjectKeyIdentifier KeyUsage D
53. zZaFwOxODASMDgxMzl0OMzZaMDQxCzAJBgNVBAYTAmZyMRgwFgYD VQQLEw9iYW5xdW Vwb3B1bGFpcmUxCzAJBgNVBAMTAmpmMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQCkscideEsfU0 UPqM1 3kKPUQVBFYB4xOcHCYqzr6PPgI7Co GwsjK504CKUm 7qWSOBdnqNOdrLaNGZ4kCx XDg1SemWMIOgPtWI9T3XAiyyr88L Ei 9sisIUA JE 3leQWuk0gJXohtxKUwR fbsW rQjqLspxNKO9Urbqz8hwehPQID AQABo4GNMIGKMA4GA1 UdDWEB wQEAwlE8DA4BgNVHR8EMTAvMC2gk6AphidodHRw Oi8vODYuNjQUMTAUMTM4LytDUONPQOErL2FzYV9jYSS5SjicmwwHwYDVROjBBgwFoAU gFSsMA0GCSqGS lb3DQEBBAUAA4GBAEm2OLIVyMIzf7Bk7ZUNBCQacvUEdl2058Pg py CMN K1 OdrLaNGZ77TIVKbydqwl2t7hlpuC81c8D309r3LiYSDrgxMFhxeUKLD slo1dusxXjV8nHm5V2zu4hOdrLaNGZix3bEEEFH cpzOp5y ogwHW Vpz6h3r36Lgo VI1S6JU6 Hash of the Encryption Certificate SHA 256 2C A5 BA 6A 2B 56 01 92 35 2A B4 91 53 E9 0B BA B8 3C BO 19 66 C9 9C 6E 34 C1 5E B5 9F 4A 64 F7 Date Signature EBICS IG CFONB V2 1 4 english version 24 02 2012 Page 34 sur 37 02 2012 doc English translation for information purposes only Only the French version is valid A5 Payment Status Report Format Disclaimer This annex named Annex 5 EBICS Payment Status Report is available on the CFONB website www cfonb org in the Documentation section Migration ETEBAC vers EBICS et SWIFTNet A6 Example of Hash calculation The hash can be checked using the openssl following command 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
Download Pdf Manuals
Related Search