According to the EBICS specification, data is always transferred
signed and encrypted. This applies to both directions of communication:
customer > bank and bank > customer. In Germany, there are
theoretically no limitations on the validity of the keys used for this.
In France, at least the validity of the certificates is limited. For
security reasons, it is absolutely necessary to renew the keys
regularly. For the customer side, EBICS already provides functions for
an automated key change for an EBICS user that has been initialised.
However, the automatic renewal of bank keys is more difficult in
practice. A “soft key change” is one solution.
The reason why banks do not like changing their EBICS keys
The EBICS customer system can download the public bank keys so that the file submission can be authenticated (identified by the bank) and encrypted with order type HPB at the bank. If the customer system is using invalid or out of date bank keys, it gets the negative return code EBICS_BANK_PUBKEY_UPDATE_REQUIRED in accordance with the EBICS specification.
This can cause the following problems:
The path to problem-free bank key changing
To be able to renew bank keys and certificates regularly without any problems, a “soft key change” should be enabled for starters. This means that not all customers have to update their bank keys from one day to the next.
A soft key change such as this is possible if the EBICS bank server is able to work in parallel with old and new bank key pairs. EBICS clients that detect a change and perform the update (in some cases automatically) use the new key, and the other clients continue to use the old one. In the latter case, the bank can contact the relevant customers.
All further measures must be implemented on the client and server sides by EBICS-CR EB-14-12. The CR has been decreed for the next EBICS specification and stipulates, among other things, that when bank keys are downloaded, the new bank keys are signed with the old bank authentication key (see www.ebics.org). Thus a manual release in the EBICS client is only required for the first bank key download. For every subsequent HPB order, the signature is checked and the bank keys are released automatically in the EBICS client if the check is successful.
With these functions, the renewal of the bank keys can be fully automated.
Michael Lembcke
The reason why banks do not like changing their EBICS keys
The EBICS customer system can download the public bank keys so that the file submission can be authenticated (identified by the bank) and encrypted with order type HPB at the bank. If the customer system is using invalid or out of date bank keys, it gets the negative return code EBICS_BANK_PUBKEY_UPDATE_REQUIRED in accordance with the EBICS specification.
This can cause the following problems:
- When the EBICS client receives the return code EBICS_BANK_PUBKEY_UPDATE_REQUIRED, it should download the current bank keys via HPB. This process is not always supported sufficiently by EBICS clients.
- After the bank keys are downloaded again, keys that are not CA- and certificate-based have to be released manually in the EBICS client by entering a hash value.
- The use of EBICS clients is often automated. The need to intercede manually when renewing the bank keys, e.g. to download the keys again or release them, is usually detected too late or not at all. Therefore, malfunctions are inevitable.
The path to problem-free bank key changing
To be able to renew bank keys and certificates regularly without any problems, a “soft key change” should be enabled for starters. This means that not all customers have to update their bank keys from one day to the next.
A soft key change such as this is possible if the EBICS bank server is able to work in parallel with old and new bank key pairs. EBICS clients that detect a change and perform the update (in some cases automatically) use the new key, and the other clients continue to use the old one. In the latter case, the bank can contact the relevant customers.
All further measures must be implemented on the client and server sides by EBICS-CR EB-14-12. The CR has been decreed for the next EBICS specification and stipulates, among other things, that when bank keys are downloaded, the new bank keys are signed with the old bank authentication key (see www.ebics.org). Thus a manual release in the EBICS client is only required for the first bank key download. For every subsequent HPB order, the signature is checked and the bank keys are released automatically in the EBICS client if the check is successful.
With these functions, the renewal of the bank keys can be fully automated.
Michael Lembcke