Le premier contact que les nouveaux clients ont avec EBICS est généralement le processus d’initialisation. C’est d’une certaine façon dommage, car leur expérience EBICS commence par la partie probablement la plus compliquée et la moins intuitive. Et lorsque ces nouveaux clients auront enfin réussi à se débrouiller avec leur propre technologie réseau, les proxies, les pare-feux et le TLS, à transférer correctement les données du formulaire des paramètres bancaires dans l’application, qui, espérons-le, les a guidés de manière aussi simple et intuitive que possible à travers l’envoi des deux messages d’initialisation, ils seront alors surpris de découvrir qu’ils ne sont en aucun cas enfin prêts à utiliser EBICS. Au lieu de cela, ils doivent d’abord imprimer une lettre INI de plusieurs pages, la signer et l’envoyer à leur institution financière. Et attendre. Attendre que la lettre leur parvienne et qu’un employé de l’institution financière ait entré les 192 chiffres hexadécimaux des valeurs de hachage des trois clés EBICS dans l’ordinateur bancaire. Vraisemblablement toujours conformément au principe du double contrôle.
Si cela est fait - et il n’y a, en règle générale, aucune indication si ce procédé est terminé, ni quand il l’est - les nouveaux clients peuvent enfin commencer à utiliser l’EBICS. Ou presque. Avant cela, ils doivent d’abord avoir récupéré les clés bancaires et confirmé leurs valeurs de hachage qui, espérons-le, seront soigneusement comparées avec celles du formulaire des paramètres bancaires.
Après le traumatisme de l’initialisation première, le reste ressemble pratiquement à une promenade de santé. Dans de nombreuses applications, les clés propres au client peuvent être renouvelées par un simple clic. Les nouvelles clés bancaires peuvent désormais être signées avec les anciennes et acceptées automatiquement. Le véritable inconvénient consiste dans l’obligation - pour toute raison - de se réinitialiser complètement.
En France, la situation est (légèrement) meilleure
Les clients français d’EBICS qui lisent ce blog se demandent peut-être de quoi je parle. Le réseau et le TLS ne sont pas plus faciles à gérer en France qu’ailleurs et les informations du formulaire des paramètres bancaires doivent être saisies, mais au moins l’échange des clés EBICS est aussi simple que possible grâce aux certificats basés sur les AC : Le participant envoie ses clés sous forme de certificats que l’institution financière peut valider et libérer directement sur la base de la signature de l’Autorité de certification émettrice. Le client EBICS peut donc récupérer immédiatement les clés bancaires sous forme de certificats. Et si ces certificats ont également été émis par une AC et que le client fait confiance à cette AC, plus rien ne s’oppose au lancement d’une communication EBICS.
Cette apparente facilité est bien sûr quelque peu illusoire, car les certificats ne tombent pas du ciel. Le processus de certification n’est pas vraiment plus simple que l’initialisation EBICS car, là aussi, il faut que la personne et son identité numérique concordent en toute sécurité. L’avantage est que le processus n’est pas considéré comme faisant partie d’EBICS et il n’est donc pas imputé au protocole. Bien sûr, un certificat peut être utilisé à de nombreuses fins - l’initialisation EBICS, en revanche, n’est toujours valable que pour ce participant dans cette institution financière.
Je ne développerai pas non plus le fait que les certificats entraînent également d’autres problèmes tels que les coûts réguliers de renouvellement, le problème de s’accorder sur une liste d’AC fiables aussi globalement que possible et des scénarios d’échec s’il n’y a qu’un seul fournisseur généralement reconnu pour la vérification en ligne des certificats.
Cela reste donc difficile, mais nous pensons que la situation ne doit pas rester ainsi. Lors d’une séance de brainstorming, nous avons trouvé deux idées que nous aimerions présenter ici - au risque qu’elles se révèlent complètement déconnectées en pratique.
Option 1 : Face-à-face
Notre première idée est que le futur utilisateur d’EBICS prenne rendez-vous avec son conseiller bancaire afin que ce dernier active l’initialisation EBICS. Pendant que le conseiller saisit les données nécessaires telles que le nom et l’adresse, l’identifiant du client et du participant dans le système, au moment opportun, l’utilisateur saisit un mot de passe unique choisi librement – à saisir comme d’habitude deux fois afin d’exclure les fautes de frappe. L’utilisateur doit bien entendu se souvenir du mot de passe jusqu’à ce qu’il se connecte à son client EBICS, puis le saisir à nouveau lors de la configuration de l’accès bancaire. En utilisant le mot de passe, une clé symétrique est alors générée avec laquelle le message d’initialisation - qui contient les trois clés EBICS - est chiffré. Comme l’ordinateur de la banque connaît le mot de passe, il peut générer la même clé symétrique et la communication est protégée contre les écoutes, les manipulations et même les attaques de type « man-in-the-middle ». Par conséquent, le serveur peut renvoyer les clés bancaires directement dans la réponse. Le mot de passe d’initialisation n’est plus nécessaire (et ne doit pas être réutilisé pour des réinitialisations ultérieures).
Le résultat : un seul message EBICS après lequel l’utilisateur est complètement initialisé et prêt pour EBICS. Du côté de l’institution financière, les étapes manuelles après la configuration sont éliminées, le client ne doit pas envoyer de lettre et - surtout - ne doit pas attendre !
Deux problèmes potentiels viennent à l’esprit :
- Un attaquant, qui connaît suffisamment bien l’institution financière et le participant, pourrait deviner l’identifiant du client et du participant ainsi que le mot de passe que le client a imaginé et se connecter lui-même avant le participant légitime. Un PIN, par exemple, qui est généré lors de la création du participant et qui lui est donné, ainsi qu’un verrou après n tentatives infructueuses peuvent protéger contre ce risque.
- Les erreurs que le serveur signale lorsque quelqu’un devine de façon hasardeuse la clé pourraient permettre des attaques oracle. Là encore, il devrait être utile que le participant soit complètement bloqué après n tentatives infructueuses.
Ce problème pourrait alors être résolu.
Option 2 : Numérisation totale
L’option 1 reste encore trop proche de la situation actuelle : le client reçoit une feuille de papier sur laquelle les données sont indiquées, ensuite il saisit les données dans son application. Mais quel est l’intérêt ? Pourquoi ne pas donner au client ces données sous forme numérique ? Par exemple stockées dans une clé USB que le conseiller peut utiliser directement et remettre au client, qui peut la conserver par la suite, bien entendu avec l’empreinte publicitaire de l’institution financière. Sur la clé USB se trouverait alors un fichier contenant tout ce qui est nécessaire à la configuration :
- L’URL
- Les identifiants
- Une clé symétrique, avec laquelle on sécurise la communication initiale, comme dans l’option 1
Ici, bien sûr, il n’est pas nécessaire de tenir compte de ce dont une personne peut se souvenir ou doit taper, la clé peut être aussi longue que souhaité. Le risque d’une attaque consistant à deviner la clé est ainsi éliminé. Le plus grand danger reste que le client perde la clé USB en rentrant chez lui. Une protection du fichier par mot de passe peut aider dans ce cas.
En revanche, en arrivant chez lui avec la clé USB, il importe le fichier dans son application EBICS. Celui-ci reconnaît le format et peut ainsi établir immédiatement et de manière autonome l’accès bancaire complet - comme décrit dans l’option 1.
Que faire si mon système ne dispose pas d’un port USB ? Il s’agit par exemple d’un smartphone sur lequel je veux m’inscrire pour une application de signature. Dans ce cas, la solution de la clé USB n’est effectivement pas adaptée, mais il est possible d’utiliser les codes QR. Il suffit donc de lui fournir les données de cette manière. Ce peut être également la politique de l’entreprise qu’aucune clé USB ne soit utilisée, même si elle provient d’une source aussi fiable qu’une institution financière. On pourrait bien sûr penser à simplement envoyer le fichier par courriel. Et donc se demander immédiatement après l’intérêt de recourir à une clé USB. La réponse est probablement qu’il n’y en a pas, si (a) le fichier est sécurisé cryptographiquement avec un mot de passe suffisamment sûr et (b) le mot de passe n’est pas dans le même courrier, mais est transmis d’une autre manière sécurisée. Cela devrait être possible.
Atteindre l’objectif
L’initialisation peut être simplifiée. Mais pour que cette simplification soit utile, il ne suffit pas qu’une seule institution financière la mette en œuvre ou - plus absurde encore - un seul système client (fabricant). Ce n’est que si un tel changement est partie intégrante de la spécification EBICS qu’il pourra faciliter la vie des clients et des institutions financières. Dans ce cas la situation sera considérablement facilitée : pour le client, la configuration d’un accès bancaire n’est plus une difficulté et les institutions financières n’ont plus à taper des valeurs de hachage. Dans certains centres d’appel, des employés ne font que cela.
Si l’initialisation est aussi simplifiée, le fait qu’elle doive être effectuée individuellement pour chaque participant EBICS ne pose peut-être plus de problème. Mais là aussi, nous avons réfléchi à des moyens de simplification que j’aimerais présenter dans un prochain article de ce blog.
Auteur : Curd Reinert
