UBS goes EBICS

Patrik Giger, Head Payment Connectivity Services, UBS Switzerland AG

Dans le cadre de l’enquête Cash Management 2015 organisée par Euromoney, UBS s’est vue décerner le prix de « Best Domestic Cash Manager Switzerland » pour la cinquième fois consécutive. Ce succès résulte d’une prise en considération depuis plusieurs années des besoins des clients et de la recherche  d’une qualité optimale des produits et des services proposés.

L’infrastructure pour la connexion directe avec les systèmes clients fait partie intégrante de cette offre de services. Depuis de nombreuses années, c’est une interface basée sur un échange propriétaire des données qui a fait ses preuves dans notre pays – une connexion directe largement plébiscitée par les clients. À l’international, ces derniers utilisent principalement une connexion via SWIFT for Corporates ou des solutions multibanques pour échanger des données de paiement et de reporting avec leurs institutions financières.

Les clients d’UBS sont d’ores et déjà en mesure d’exécuter leurs opérations financières mondiales en toute sécurité, y compris avec  les succursales internationales. L’objectif majeur des nouvelles infrastructures est de rendre les échanges avec les institutions financières encore plus sûrs, plus aisés et plus standardisés.


Harmonisation des opérations de paiement : une opportunité autant qu’un défi

Dans le cadre d’un projet commun dénommé «Harmonisation du trafic des paiements», les banques suisses ont entériné un accord prévoyant, d’ici 2020, la migration des opérations de paiement vers  la norme internationale ISO 20022 (pour plus de détails, voir http://www.paymentstandards.ch/fr/home.html).

Dans les quatre années à venir, les formats et traitements existants seront modifiés afin d’exploiter durablement les synergies entre prestataires de services de paiement, institutions financières et consommateurs tout au long de la chaîne de valeur. Ces synergies doivent donc devenir des atouts pour tous les acteurs impliqués. Or, le défi est non seulement de taille, mais le calendrier établi pour atteindre cet objectif se révèle très ambitieux. Ce sont les répercussions que ces changements auront sur les clients qui sont dès lors bien souvent sous-estimées. La modification des formats va ainsi sans doute également se traduire par une évolution des procédures au sein des entreprises clientes.

Les développeurs de logiciels en tant que pivots de l’harmonisation

Les départements informatiques des clients, ainsi que les consultants IT et les développeurs de logiciels, jouent un rôle fondamental dans la migration des opérations de paiement en Suisse. Plus de 90 % des clients d’UBS utilisent p. ex. un logiciel standard proposé par un prestataire bien implanté sur le marché pour permettre les échanges avec leurs banques. Et ces clients s’attendent bien entendu à ce que les ERP (Enterprise Ressource Planning) et autres TMS (Treasury Management Software) correspondants soient en mesure de gérer rapidement et avec fiabilité les nouveaux formats ISO. Pour simplifier le passage aux formats ISO 20022, UBS met à la disposition des développeurs une plateforme de test dédiée, qui permet de télétransmettre des fichiers tests, tant manuellement que par le biais d’un canal EBICS, en vue de leur validation. Outre des codes d’erreur standardisés, les rapports de test contiennent également des informations très détaillées sur les éventuelles anomalies et imperfections des messages. La plateforme propose par ailleurs aux développeurs un « readiness test », qui confirme leur aptitude (et celle de leurs clients) à gérer l’ISO 20022.

Remplacement d’une solution propriétaire éprouvée

UBS propose à ses clients le canal de communication EBICS depuis déjà 2013. Ce canal est utilisé par quelques clients dotés de logiciels financiers très spécifiques, mais la grande majorité favorise toujours la solution propriétaire. Cela s’explique notamment par la grande stabilité des opérations de paiement dans notre pays, où les changements sont demeurés très rares au cours des dernières décennies. Tant les clients que les développeurs locaux de logiciels n’avaient donc aucune raison de modifier leurs solutions existantes éprouvées. Et ceci s’appliquait également aux banques.

EBICS – un canal idéal pour ISO 20022

Alors pourquoi – en plus des formats – vouloir aussi changer les canaux de communication? Les analyses ont montré que l’intégration des nouveaux formats dans les anciens canaux (propriétaires) allait demander à peu près autant d’efforts de la part des clients, des développeurs de logiciels et des banques que d’instaurer le nouveau canal standardisé EBICS.

Les principaux prestataires financiers helvétiques proposent d’ores et déjà une connexion via EBICS, ou ils sont en passe de le faire.

L’avantage du standard EBICS est évident: les clients pourront profiter du fait que les «banques parlent la même langue». En Suisse, nous disposons en outre déjà de solutions éprouvées, puisqu’EBICS s’est imposé comme un standard de communication stable et fiable depuis son introduction en Allemagne il y a 10 ans. L’adhésion de la Suisse en tant que troisième pays membre de la société EBICS (avec l’Allemagne et la France) témoigne sans équivoque de la volonté des prestataires financiers helvétiques de faire de ce canal de communication non pas un produit secondaire, mais bien une solution d’importance stratégique.

Lutte autour des types d’ordres standardisés

S’agissant des types d’ordres, c’est l’approche allemande qui s’est imposée en Suisse (indication du contenu à l’aide du type d'ordre), par opposition au modèle français qui ne connaît que les types d'ordres «upload» et «download». La «recommandation suisse» prévoit une standardisation la plus étendue possible des types d’ordres, et la migration des opérations de paiement offre la possibilité d’aller encore plus loin. Le type d’ordre suisse «XE2» s’applique actuellement aux transferts nationaux ainsi qu’aux virements SEPA et internationaux. Or, UBS s’engage pour que les types d’ordres soient à l’avenir étendus pour maximiser l’effet de synergie d’ISO 20022 et d’EBICS. Dans les faits, on envisage donc d’utiliser des types d’ordres EBICS spécifiques pour les paiements en Suisse, à l’étranger et via SEPA. Cette proposition fait l’objet de discussions animées au sein des instances compétentes et UBS espère ainsi atteindre un degré de standardisation à synergie ajoutée.

UBS implémente EBICS – mondialement!

UBS a décidé de remplacer l’infrastructure de communication existante pour les opérations de paiements de masse en Suisse par une solution EBICS standardisée. À terme, la banque prévoit même d’utiliser EBICS en tant que protocole de communication pour ses clients dans les centres de comptabilité internationaux, en Asie et aux États-Unis. Point essentiel lors de cette migration, l’infrastructure doit être stable et standardisée. Grâce à l’étroite collaboration avec la société PPI, nous serons à l’avenir en mesure de recommander aux clients ne disposant pas de logiciels capables de gérer EBICS un plug-in, qui se chargera de la communication. En outre, nous offrirons la possibilité de se connecter au portail EBICS «UBS KeyPort Web» en tant qu’alternative lorsque les clients souhaitent télétransmettre manuellement leurs transactions sous forme de fichiers ou de télécharger leurs reportings par le biais d’un portail Internet.

L’offre EBICS d’UBS s’adresse en premier lieu aux clients qui ont besoin d’une connexion directe pour leurs systèmes ERP et TMS, puis à ceux qui recherchent un portail disposant de capacités «multi-booking-center» pour leurs paiements de masse. Pour traiter les transactions spécifiques et obtenir des informations supplémentaires, nos clients pourront continuer à utiliser notre e-banking UBS, une solution aussi moderne que polyvalente.

EBICS doit continuer à évoluer

UBS supportera tant la variante allemande (DK) du standard que la variante française. Il est cependant urgent d’harmoniser encore d’avantage le standard, car bien que seuls trois membres siègent au sein de la société EBICS, le nombre d’implémentations distinctes se révèle déjà très élevé. La société EBICS a d’ailleurs d’ores et déjà lancé un projet d’harmonisation supplémentaire sous le nom BTF (voir l’article de Sabine Wenzel, EBICS SCRL, dans ce blog http://www.ebicsblog.com/fr/harmonieusement-international-avec-ebics-btf/). Selon nous, cette harmonisation constitue une priorité majeure et nous sommes convaincus qu’EBICS va continuer à s’imposer en tant que standard de communication à l’échelle mondiale. UBS est en première ligne sur ce sujet et mise sur EBICS en Suisse, en Allemagne, en Europe, en Asie et aux États-Unis.

Patrik Giger

EBICS et TLS 1.2 – un regain de sécurité sans complexité accrue

Curd Reinert, Project Manager EBICS-Kernel, PPI AG

Quiconque jette un coup d'œil sur les spécifications actuelles d’EBICS pourra s’étonner de constater que la version prescrite pour le protocole de sécurisation des échanges sur Internet, Transport Layer Security (TLS), est toujours la version 1.0. A un certain moment, ce fut un choix judicieux: lorsque les spécifications EBICS ont été publiées, le protocole TLS 1.0 était la technologie la pus avancée. À l'époque, en effet, il avait surtout été jugé important de ne pas utiliser le protocole SSL. Ce choix avait d'ailleurs garanti une excellente protection par exemple contre la vulnérabilité logicielle POODLE, et ce, aussi bien pour les éditeurs que pour les exploitants: EBICS excluait l’utilisation du protocole SSL et les applications EBICS étaient protégées contre POODLE. Ceci étant dit, POODLE n'aurait eu de toute façon pratiquement aucune chance avec un client EBICS: Lors d'une telle attaque, l'agresseur contraint en effet le client à envoyer des milliers de requêtes au serveur HTTPS, pour, par exemple, obtenir le cookie de la session. Or, EBICS n'utilise aucun cookie de session et les logiciels clients ne sont pas des applications web avec lesquelles JavaScript peut être utilisé pour envoyer des milliers de requêtes. Mais essayez d’expliquer cela aux auditeurs!


Et il ne s'agissait là que de l'une des attaques malveillantes portant des noms amusants: HEARTBLEED, par exemple, mettait à profit une erreur dans l'implémentation TLS d'OpenSSL. Et sans oublier non plus la menace BEAST. Pourtant, comme dans le cas de la menace POODLE, EBICS est également protégé contre une attaque BEAST. Malgré tout la réputation du protocole TLS 1.0 est durablement compromise et tous les sites recommandent de passer au successeur, plus sûr, le protocole TLS 1.2.

Cela fut admis dans le cadre d’EBICS et des demandes de modification ont été planifiées afin de prendre charge TLS 1.2. Malheureusement, la sortie de cette nouvelle version prend du retard et les auditeurs nous demandent souvent : Pourquoi EBICS utilise-t-il encore le protocole TLS 1.0 ? Un argument du genre «parce ce que c'est ce qui est prescrit dans les spécifications » n'est certainement plus une raison valable si l'on tient compte du fait que le BSI (federal office for information security) conseille officiellement d'éviter cette version. C'est d'ailleurs la raison pour laquelle vous trouverez désormais sur le site officiel EBICS des recommandations en matière de sécurité qui conseillent d'utiliser la version TLS 1.2 – sans expliquer comment concilier cette recommandation et la spécification.

Nous avons testé 82 serveurs EBICS en Allemagne et en France : Seulement 52 serveurs ont pu communiquer avec nous en utilisant le protocole TLS 1.2. Si vous décidez donc aujourd'hui en tant que fabricant de produits clients de ne plus supporter TLS 1.0, vous ne pourrez plus vous connecter à environ un tiers des serveurs EBICS. Et la situation risque d'être encore pire pour les exploitants de serveurs qui communiquent avec des produits clients utilisant les différentes versions.




Quelles sont alors les possibilités? Proposer la version TLS 1.2 sans toutefois interdire la version TLS 1.0. Cette solution est possible aussi bien pour les clients que pour les serveurs; lors de la prise de contact - ou handshake - TLS, les deux parties se mettent d'accord sur la variante commune la plus sûre – du moins en théorie. Ceci a d'ailleurs effectivement fonctionné sur 28 des serveurs testés. Mais nous avons aussi trouvé deux serveurs qui interrompent systématiquement la communication dès lors que le client propose la version TLS 1.2. Ceci est particulièrement désagréable pour les fabricants de produits clients étant donné que les clients ne peuvent alors tout simplement pas proposer la version TLS 1.2 «au cas où». Et s'ils le font tout de même, ils prennent le risque de ne pas pouvoir communiquer avec quelques serveurs.

Nous avons naturellement informé les opérateurs de ces deux serveurs EBICS. Comme notre test ne couvrant pas tous les serveurs EBICS, nous recommandons aux exploitants de contrôler eux-mêmes le comportement de leur serveur EBICS.

Une question subsiste cependant: Quel serait le risque lié à un décryptage du protocole TLS dans EBICS ; quelles seraient les données visibles? Les données de l'ordre elles-mêmes sont cryptées une seconde fois et restent invisibles pour l'agresseur. Il reste donc uniquement le cadre XML dans lequel sont intégrées les données de l'ordre ou, comme on les nomme également depuis l'affaire Snowden : les métadonnées. Il s'agit là principalement du type d'ordre ou du format de fichier, de l'ID client et de l'ID participant. En d'autres termes, pas vraiment grand-chose. Cela suffira-t-il à calmer les esprits : c’est une autre histoire.

Curd Reinert