It is the nature of things that new customers’ first contact with EBICS is usually the initialisation process. This is somewhat unfortunate, because it means that right at the beginning of their EBICS experience, they are confronted with what is probably the most complicated and least intuitive part. And once new customers have successfully struggled through their own network technology, proxies, firewalls and the TLS, have properly and obediently transferred the data from the BPD sheet into the application – which hopefully guided them as simply and intuitively as possible through sending the two initialisation messages – they will be surprised to find that they are by no means ready to finally use EBICS. Instead, they must first print out, sign and send a multi-page INI letter to their financial institution. And then they wait. They wait until the letter has arrived and a bank employee has entered the 192 hex digits of the hash values of the three EBICS keys into the bank server. Possibly even involving a four-eyes principle process.
Once that is dealt with – and there is usually no clue as to if and when exactly it happens – the new customers can at last use EBICS. Almost. Before that they must download the bank keys and confirm their hash values, which they compare hopefully carefully with those on the BPD sheet.
After this trauma of initial initialisation, the rest is almost a walk in the park. Own keys can be renewed in many applications at the push of a button. New bank keys can now be signed with the old ones and accepted automatically. Things only become really unpleasant if – for whatever reason – a complete reinitialisation becomes necessary.
France, you are (a little) better off
French EBICS customers who read this blog may wonder what I am going on about. Network and TLS may not be any easier to handle in France than elsewhere and the BPD sheet must also be typed out, but at least the actual EBICS key exchange is as simple as one could wish for thanks to CA-based certificates: EBICS users send their keys as certificates, which the financial institution can validate and release directly based on the signature of the issuing certificate authority. The EBICS client can thus download the bank keys as certificates immediately afterwards. And if these certificates were also issued by a CA and the client trusts this CA, then nothing stands in the way of starting an EBICS communication.
This apparent effortlessness is a little deceptive, of course, as the certificates do not just drop from the sky either. The certification process is not necessarily simpler than the EBICS initialisation, because in this case, too, a person and that person's digital identity have to be matched securely. The main advantage is that the process is not regarded as part of EBICS and is therefore not blamed on the protocol. And of course, a certificate can be used for many purposes – the EBICS initialisation, on the other hand, is only ever valid for exactly one EBICS user at exactly one financial institution.
I will only mention in passing the fact that certificates bring with them other problems, such as regular renewal costs, the problem of agreeing on a list of trustworthy CAs as globally as possible, and interesting failure scenarios if there is only one generally recognised provider for the online verification of certificates.
In other words, the process remains a struggle, but we believe that it need not stay that way. In a brainstorming session, we came up with two ideas that we want to present here – even at the risk that they may prove to be entirely lacking in practicality.
Option 1: face to face
Our first idea is based on the assumption that the future EBICS users will sit down with a bank advisor in order to have the advisor activate EBICS for them. While the bank advisor enters the necessary data such as name, address, customer and EBICS user ID into the system, at one point he or she passes the keyboard to the EBICS user, who enters a freely chosen one-time password – and repeats it, as usual, to rule out typos. The EBICS user must remember the password until logging in to the EBICS client and then enter it again when setting up the bank access. With the help of the password, a symmetrical key is generated and used to encrypt the initialisation message – which contains all three EBICS keys. Since the bank server knows the password, it can generate the same symmetric key and communication is protected against interception, manipulation and even man-in-the-middle attacks. Therefore, the server can also return the bank keys directly as part of the response. The initialisation password is no longer required (and must not be reused for later reinitialisations either).
The result: after a single EBICS message, the EBICS user is completely initialised and ready for EBICS. On the bank side, once the setup is complete, the manual steps are eliminated. The customer does not have to send a letter and – most importantly – does not have to wait!
Two possible problems come to mind with this scenario:
- An attacker who knows both the financial institution and the EBICS user well enough could guess the customer ID and EBICS user ID as well as the password that the customer has come up with and log in before the legitimate user does. The process can, for example, be protected by a PIN, which is generated and given to the EBICS user during setup, as well as by a lock after n failed attempts.
- The errors that the server reports back when someone wildly guesses the key could allow oracle attacks. This problem could also be helped if the EBICS user is completely locked after n failed attempts.
The issues could thus be solved.
Option 2: all digital
Option 1 is still a little bit stuck in the traditional way: the customer gets a piece of paper, the data from it must be typed into the application ... But why? Why not give the customer the data digitally instead? E.g. on a USB drive, on which the bank advisor directly stores the data before handing it over to the customer, who is then free to keep it – naturally with the bank's advertising imprint. The USB drive would then contain a file that includes everything needed for the setup:
- The URL
- The IDs
- A symmetric key, which is used to secure the initial communication in the same way as with option 1
Obviously, there is no need to take into account how much a person can remember or is willing to type; the key can be as long as desired. Attacks by means of guessing the key are no longer an issue. The biggest risk is still that the customer loses the USB drive on the way home. But again, a password protection of the file can help.
Once, however, the EBICS user makes it home safely with the drive, he or she imports the file into the EBICS application. The latter recognises the format and can thus immediately and autonomously set up the complete bank access – as described in option 1.
What if my system has no USB port? Then it may be a smartphone on which I want to register for a signature app, for example. In that case, it may not have much use for USB, but it can do a lot with QR codes. So the data can be provided this way. Or perhaps it is company policy that does not allow the use of USB drives, not even from such a trustworthy source as my financial institution. Then one could of course consider simply sending the file by e-mail. And once the thought has crossed one's mind, one wonders whether it needs a USB stick at all. And the answer is probably no, if (a) the file is cryptographically secured with a sufficiently good password and (b) the password is not included in the same e-mail, but is transmitted in a different, secure way. That should be manageable.
Achieving the goal
The initialisation can be simplified. But for this simplification to be of any use, it is not enough for just one financial institution to implement it or – even more absurdly – just one customer system (provider). Only if such a change becomes part of the EBICS specification can it make life easier for customers and financial institutions. But then, the improvement will be considerable: for the customer, setting up a bank access is no longer a nuisance, and the financial institutions can save themselves the hassle of typing in hash values. There are employees in call centres who in fact do nothing else.
If the initialisation is simplified this much, it is perhaps no longer a problem that it must be carried out individually for each EBICS user. Still, we have given thought to ways of simplification for that aspect, as well – which I will happy to share in a later blog post.
Author: Curd Reinert
