With EBICS communication, various security features and regulations are specified that must be adhered to by customers and financial institutions alike. The financial institutions must always ensure that the current specifications are available and supported in their EBICS bank server. EBICS customers themselves and each individual EBICS users are, however, also responsible for ensuring the use of customer software that is continuously up to date and that meets the current EBICS security standards. It is therefore paramount both due to functional adjustments and for security reasons to frequently update the software of the EBICS client systems.
Once an existing EBICS client software has been brought up to date via updates, however, it does not mean that the EBICS software in question automatically starts to communicate with the financial institution using the most recent EBICS version and the latest security procedure. Depending on the previously used EBICS version and client functionality, this requires an update of the various application keys for encryption (E002), authentication (X002) and authorisation (A004, A005 or A006) and of the new EBICS version to be used, followed by an exchange of this data with the EBICS bank servers. It may also be necessary to update the Internet encryption (TLS) to a more recent and secure version by means of a renewed certificate exchange. Such updates usually require a proactive approach and manual adjustments by the EBICS user.
Why are these updates important?
EBICS communication via the Internet has its own specifications for security procedures. The EBICS society continuously updates and adapts them to current security requirements by means of new EBICS versions. One example are key lengths. Older EBICS versions still permit key lengths of 1024 bits for encryption (E002), authentication (X002) and authorisation (A004, A005 or A006). That length no longer meets the current security requirements as too short key lengths are considered unsafe. Newer EBICS versions only permit keys with a minimum length of 2048 bits. Another example is evident in the procedures and versions of the TLS encryption that are in use. To be able to follow security recommendations such as the ones by the BSI in Germany more flexibly, the EBICS society has created a separate annex of the EBICS 3.0 specification called Transport Layer Security, which contains the respective guidelines. As the EBICS 2.5 specification could not be adapted retroactively, the DK (Deutsche Kreditwirtschaft) has additionally issued its own recommendation document in 2019 titled Empfehlungen zu EBICS-Sicherheitsverfahren und Schlüssellängen (recommendations on EBICS security procedures and key-lengths). It contains information on the security procedures to be used in EBICS communication. See also www.ebics.de and www.ebics.org.
To allow EBICS users a smooth transition to newer EBICS versions and security standards, most financial institutions still offer their customers the older procedures in parallel with the new ones. Unfortunately, it has become clear that in many cases this leads to customers not taking the opportunity to update their EBICS communication. Many keep using older systems and procedures. This, in turn, makes it hard for the financial institutions to discontinue those old procedures.
In the end, every participant in EBICS communication expects a secure data exchange to be ensured. Nobody wants to sustain losses. Which means that everyone should take care to contribute their part. Of course, EBICS security is not the only thing financial institutions need to keep an eye on. Ultimately, all parties involved must take all possible security measures in their infrastructure and software solutions to prevent misuse and losses.
So why wait any longer? Let's do this.
Author: Michael Lembcke
Once an existing EBICS client software has been brought up to date via updates, however, it does not mean that the EBICS software in question automatically starts to communicate with the financial institution using the most recent EBICS version and the latest security procedure. Depending on the previously used EBICS version and client functionality, this requires an update of the various application keys for encryption (E002), authentication (X002) and authorisation (A004, A005 or A006) and of the new EBICS version to be used, followed by an exchange of this data with the EBICS bank servers. It may also be necessary to update the Internet encryption (TLS) to a more recent and secure version by means of a renewed certificate exchange. Such updates usually require a proactive approach and manual adjustments by the EBICS user.
Why are these updates important?
EBICS communication via the Internet has its own specifications for security procedures. The EBICS society continuously updates and adapts them to current security requirements by means of new EBICS versions. One example are key lengths. Older EBICS versions still permit key lengths of 1024 bits for encryption (E002), authentication (X002) and authorisation (A004, A005 or A006). That length no longer meets the current security requirements as too short key lengths are considered unsafe. Newer EBICS versions only permit keys with a minimum length of 2048 bits. Another example is evident in the procedures and versions of the TLS encryption that are in use. To be able to follow security recommendations such as the ones by the BSI in Germany more flexibly, the EBICS society has created a separate annex of the EBICS 3.0 specification called Transport Layer Security, which contains the respective guidelines. As the EBICS 2.5 specification could not be adapted retroactively, the DK (Deutsche Kreditwirtschaft) has additionally issued its own recommendation document in 2019 titled Empfehlungen zu EBICS-Sicherheitsverfahren und Schlüssellängen (recommendations on EBICS security procedures and key-lengths). It contains information on the security procedures to be used in EBICS communication. See also www.ebics.de and www.ebics.org.
To allow EBICS users a smooth transition to newer EBICS versions and security standards, most financial institutions still offer their customers the older procedures in parallel with the new ones. Unfortunately, it has become clear that in many cases this leads to customers not taking the opportunity to update their EBICS communication. Many keep using older systems and procedures. This, in turn, makes it hard for the financial institutions to discontinue those old procedures.
In the end, every participant in EBICS communication expects a secure data exchange to be ensured. Nobody wants to sustain losses. Which means that everyone should take care to contribute their part. Of course, EBICS security is not the only thing financial institutions need to keep an eye on. Ultimately, all parties involved must take all possible security measures in their infrastructure and software solutions to prevent misuse and losses.
So why wait any longer? Let's do this.
Author: Michael Lembcke