EBICS-Security – Quand est-il temps de mettre à jour votre système client ?

EBICS spécifie différentes fonctions et règlementations de sécurité qui doivent être respectées par les clients et les institutions financières. Ces dernières doivent toujours veiller à ce que les spécifications les plus à jour soient mises en œuvre et supportées par leurs serveurs bancaires EBICS. Cependant, les clients EBICS et chaque utilisateur ont aussi la responsabilité d’utiliser à tout instant des logiciels client répondant aux standards de sécurité EBICS en vigueur. Il est donc primordial, tant en raison des adaptations fonctionnelles que pour des raisons de sécurité, de mettre à jour fréquemment les logiciels client EBICS.

Toutefois, la mise à jour d’un logiciel client EBICS existant ne signifie pas que ce logiciel EBICS sera automatiquement capable de communiquer avec l’institution financière en utilisant la version EBICS et les procédures de sécurité les plus récentes. En fonction de la version EBICS et des fonctionnalités client utilisées précédemment, il est nécessaire de mettre à jour les différentes clés d’application pour le chiffrement (E002), l’authentification (X002) et les signatures (A004, A005 ou A006) ainsi que la version d’EBICS à utiliser, suivie d’un échange de ces données avec les serveurs bancaires EBICS. Il peut aussi être nécessaire de mettre à jour le cryptage Internet (TLS) vers une version plus récente et plus sécurisée en échangeant des certificats renouvelés. De telles mises à jour requièrent en règle générale une intervention proactive et des ajustements manuels de la part de l’utilisateur EBICS.

Pourquoi ces mises à jour sont-elles importantes ?

La communication EBICS via Internet possède ses propres spécifications en termes de procédures de sécurité. La société EBICS les met à jour et les adapte régulièrement aux exigences de sécurité en vigueur au moyen de nouvelles versions d’EBICS. Un exemple est la longueur des clés. Les anciennes versions d’EBICS permettent encore d’utiliser des clés de longueur 1 024 bits pour le chiffrement (E002), l’authentification (X002) et les signatures (A004, A005 ou A006). Mais cette longueur ne répond plus aux exigences de sécurité actuelles, car les clés trop courtes sont considérées comme peu sécurisées. Les versions plus récentes d’EBICS n’acceptent que des clés d’une longueur minimale de 2 048 bits. Un autre exemple est mis en évidence avec les procédures et les versions du cryptage TLS. Afin de répondre plus aisément aux recommandations de sécurité, par exemple à celles de BSI en Allemagne, la société EBICS a créé une annexe distincte des spécifications EBICS 3.0, appelée Transport Layer Security qui comporte les directives y afférentes. Comme les spécifications de la version 2.5 d’EBICS ne pouvaient pas être adaptée rétroactivement, la DK (Die Deutsche Kreditwirtschaft) a en outre publié en 2019 son propre document de recommandations intitulé Recommandations concernant les protocoles de sécurité EBICS et la longueur des clés (disponible en allemand et en anglais). Il contient des informations sur les procédures de sécurité à utiliser pour EBICS. Voir aussi www.ebics.de et www.ebics.org.

Afin de permettre aux utilisateurs d’EBICS une transition en douceur vers les nouvelles versions d’EBICS et les nouveaux standards de sécurité, la plupart des institutions financières proposent toujours à leurs clients les versions plus anciennes, en parallèle avec les nouvelles. Malheureusement, il est devenu évident que dans de nombreux cas cela conduit à ce que les clients ne saisissent pas l’occasion de mettre à jour leur communication EBICS. Nombreux sont ceux qui continuent à utiliser les anciens systèmes et procédures. Il est donc plus difficile pour les institutions financières de mettre fin à ces anciennes procédures.

En fin de compte, chaque acteur de la communication EBICS s’attend à ce qu’un échange de données sécurisé soit assuré. Personne ne veut subir de dommages. Ce qui signifie que chacun doit apporter sa contribution. Bien entendu la sécurité d’EBICS n’est pas la seule chose que les institutions financières et les entreprises doivent garder à l’esprit. Après tout, toutes les parties impliquées doivent prendre toutes les mesures de sécurité possibles dans leurs infrastructures et dans leurs solutions logicielles afin de prévenir les abus et les pertes.

Alors, pourquoi attendre ? Allons-y.

Auteur: Michael Lembcke

Open banking : EBICS versus API

L'Open banking est l'une des tendances de fond que de nombreuses institutions financières risquent de manquer. Puisque presqu’aucune interface DSP2 ne semble être prête pour le marché, les autorités de surveillance bancaire ont accordé une période de transition allant jusqu'à décembre 2020. Mais le problème est autre : de nombreuses institutions ne ressentent que peu d'envie d'investir beaucoup d'argent pour faciliter la vie des fournisseurs d’interfaces d'Open banking – d'autant plus que les protocoles établis comme FinTS et EBICS offrent beaucoup plus de possibilités que « l'APIsation » du secteur bancaire.

Les deux protocoles, FinTS et EBICS, couvrent déjà presque tous les domaines des opérations bancaires : des paiements aux opérations de crédit en passant par les transactions de titres. Au total, plus de 200 processus sont disponibles qui décrivent de façon contraignante tant les interfaces métier que la communication technique entre les partenaires participants. Dès les années 90 HBCI et FinTS ont été les pionniers en matière de standards ouverts dans la communication avec les institutions financières. Il y a plus de dix ans qu'EBICS a été introduit par la Deutsche Kreditwirtschaft (DK) ou par son prédécesseur comme standard contraignant pour les échanges avec les entreprises. L'Open banking est donc une réalité en Allemagne depuis de nombreuses années.

Aucune interface DSP2 uniforme en vue


Aussi bonne que soit l'idée de l'Open banking, les évolutions auxquelles pousse la DSP 2 laisse perplexes beaucoup d'institutions financières, même celles qui veulent avancer. D'un côté, la DSP2 est supposée servir de base à une norme européenne d'Open banking. De l’autre, le législateur a délibérément laissé ouverte la question de savoir comment la communication doit avoir lieu et comment elle peut être sécurisée. En conséquence, les fournisseurs d'API pour l'Open banking exhortent les banques à implémenter leurs solutions et à adopter leurs propres interprétations de l'Open banking, juste pour ne pas être marginalisées. En plus, différentes initiatives dans divers pays développent des protocoles pour les aspects technique/métier des applications, ce qui conduit à un nombre incontrôlé des types d’API. Les concepts transnationaux par contre sont encore loin d'être en vue.

Tout cela pourrait devenir un puits sans fonds pour les institutions, s'il n'y a pas bientôt une spécification uniforme de la DSP2 que chaque banque puisse suivre. Tant que cela n'arrivera pas, de nombreuses visions de l'Open banking resteront des vœux pieux. Après tout, selon la loi, l'ouverture doit être gratuite et exempte de discrimination. Gagner de l’argent avec elle est réservé à d’autres acteurs. Alors, quelle devrait être la motivation d’une banque à continuer d’ajouter des nouvelles API gratuitement, juste pour que les prestataires tiers puissent plus facilement augmenter leurs parts de marché ? Cela rétrograderait les institutions elles-mêmes au rang de simples fournisseurs de services. Il est beaucoup plus raisonnable de s’en remettre à des standards établis de longue date.
EBICS : Open banking pour entreprise

L'un de ces standards est EBICS. Il est largement répandu : outre l'Allemagne, EBICS est aussi populaire en France. Il existe un accord de coopération entre la Deutsche Kreditwirtschaft et son équivalent français, le CFONB. Ces deux plus grands marchés des paiements de la zone euro utilisent EBICS pour les entreprises et les opérations interbancaires. La Suisse (SIX) est également fan d’EBICS, et l’Autriche (STUZZA) envisage d’y participer. Au lieu de se perdre dans le maquis des API, il vaut mieux se demander comment EBICS peut évoluer pour être conforme à la DSP2. Et la réponse est : avec une signature à distance (voir figure 1). Un portail EBICS moderne peut générer la signature et l'envoyer au serveur bancaire EBICS en utilisant des données entrantes comme le code d'un PhotoTAN ou d'un QR TAN au moyen de dispositifs matériels.
Figure 1 : Comment les signatures à distance EBICS étoffent EBICS pour en faire une solution d'Open banking conforme à la DSP2
EBICS offre de nombreux avantages aux entreprises. Celles qui disposent d'un client EBICS peuvent effectuer des opérations bancaires multiples et également utiliser la signature électronique distribuée (VEU). De cette façon, les modèles de rôles et de droits peuvent être réalisés (signatures T, A, B et E), pour déterminer par exemple, si les ordres de paiement sont remis par des personnes autorisées ou si la personne concernée dispose des autorisations appropriées pour valider ces ordres de paiement. Tout comme pour FinTS, ce qui suit s'applique également à EBICS : l'infrastructure nécessaire pour mettre en œuvre l'Open banking existe déjà. Rien que pour cette raison il est compréhensible que de nombreuses institutions aient du mal à investir pour le moment. Rien ne garantit qu'elles choisiront le bon fournisseur d'API ou que les législateurs n'adopteront pas de nouvelles règlementations rendant obsolètes les investissements déjà réalisés.

Auteur : Michael Schunk