Our money must go digital

 

Imagine the following scenario for the future: a company runs out of certain material, which is only available from a supplier abroad. At the latest 24 hours later, supplies of the material must arrive, otherwise the production will be stopped. This issue is detected by a computer system. It orders new goods completely autonomously from the supplier's system, where they are immediately sent on their way, also completely automatically. Customs declaration, transport organisation, etc. – all of this is taken care of without human intervention. At customs, a computer scans the goods, concludes that everything is in order using specified parameters and requests the customs duties from the ordering computer system. The computer system would execute the payment immediately – but it can't, at least not at the moment. Finally, a person must authorise the payment and, usually, it takes at least one banking day for the customs to register the receipt of the funds.

This example illustrates the limitations of our current payment system: relatively long waiting times, complicated authorisation procedures and a lack of delivery-versus-payment functionalities. While this may have been acceptable in the past, it poses serious problems for the future. Because the future belongs – among other things – to the Internet of Things (IoT). By 2025, an estimated 75 billion devices will be linked via networks.  The potential for new business models is huge, from automatic customs clearance without human intervention, or rental charges for agricultural machinery billed according to the actual payload, to the self-ordering refrigerator.

However, many of these business models will be hard to realise if the current limits of payment systems remain. Digital currencies can lay the foundation for automation and overcome these limitations. The European Central Bank (ECB) is considering the introduction of a public digital euro – a digital form of central bank money that is to promote financial inclusion and be available to the citizens as a digital and secure means of payment. Still, even if this were to be decided in 2021, according to the assessment by the ECB's director Fabio Panetta as well such a currency would hardly be a reality until 2026 , especially since it is not yet known whether the digital euro will have the characteristics necessary for IoT business models. Given the growth of the IoT, this will be too late and too uncertain.

The solution to this dilemma lies with private initiatives. It is already possible to connect the SEPA system with an application based on distributed ledger technology (DLT) via a technical bridge solution. This method can be used, for example, to implement pay-per-use solutions: payments are triggered via the SEPA system and programmable payments can be mapped on a DLT. However, this so-called trigger solution does not eliminate the limitations of SEPA because a human authorisation is still needed. The machine or IoT device cannot bill itself. The system break in payment processing can be avoided if a digital means of payment is issued and processed directly on a DLT, instead of using conventional payments. 

A DLT-based digital currency does not necessarily have to be issued by a central bank. Banks or financial institutions can also create solutions for so-called programmable payments. One example are euro-based stablecoins – digital tokens backed by a specific monetary value. At present, there is still no regulatory basis for euro stablecoins and they have a high counterparty risk. However, with the planned EU directive "Markets in Crypto-assets" (MiCA) this is likely to change and stablecoins will become tokenized e-money. An alternative is tokenized scriptural money that financial institutions could issue. Unlike the stablecoin, it would have the advantage of not having to be 100 percent covered. Nevertheless, according to the current rules, such a currency would not be multi-bank capable and would thus entail very significant restrictions.

In whichever form this happens, the digital currency will become reality. This is the only way for the German industry to fully benefit from the potential of the IoT. Even more far-reaching automation in goods logistics or increasingly popular asset-as-a-service models are hardly conceivable in the long term without fully autonomous payments in real time. Details on the use cases and further details on the design of digital currencies can be found in the joint white paper "The future of payments: programmable payments in the IoT sector", which was written by PPI together with the partners Cash on Ledger, Digital Euro Association and Frankfurt School Blockchain Center. For a free download click here.

Authors: Anja Kamping, Philipp Schröder


EBICS key: how long is the key to success?

On 21 April 2021, an EBICS manufacturer workshop of the German Banking Industry Committee (DK) took place. In terms of content, the core adjustments to EBICS coming with version 3.0.1 were presented. However, much more interesting for me are the cryptographic adjustments presented at the same time, which will become mandatory for EBICS customer systems in November 2021. EBICS uses 3 RSA key pairs for communication: one pair for authorisation signatures, one pair for authentication of the EBICS fragment, and one pair for encryption/decryption of messages.

For EBICS V2.5, this adjustment means that authorisation signatures (A keys) must have at least a 2048-bit key length. For authentication (X keys) and encryption (E keys), a compromise of at least 1984 bits was decided. The reason for this is probably that Seccos smartcards with keys of this length still exist in the market. The so-called DS key of these Seccos cards has a 2048-bit key length and is located in the special area of the card chip protected by an alternative PIN. 

In addition, it was again confirmed to all participants that with the use of EBICS 3.0.1, all keys used for authentication (X00x), encryption (E00x) and authorisation signature (A00x) may no longer be shorter than 2048 bits.

For the customer product manufacturers, this means that a key extension process must start in the foreseeable future so that all customers can easily and simply switch to the new EBICS 3.0.1 version as of November. If this does not happen, a switch to EBICS 3.0.1 is not possible with the existing – too short – keys.

Customer products that do not offer key changes fall behind here; their users then have to generate new, longer keys in a time-consuming and complicated process, then have their access reset at the financial institution and then resubmit the keys and the INI letter to their financial institution. After that, it is a matter of waiting until the EBICS access is activated again.

EBICS customer products which offer their customers a key change still have to deal with the challenge that with EBICS 3.0.1, only X509 certificates may be used in EBICS communication. The customer products use completely new internal processes for this. The implementation must therefore be well planned and will generally not be easy. However, TRAVIC-EBICS-Kernel by PPI AG helps by providing the necessary functions for an easy switchover. It would be advisable to change from the previous key format (RDH2) to the PKCS#12 format (p12 file) for key files in the course of this.

A challenge arises for smartcards, because they often do not have the necessary key lengths and may have to be replaced, if this is possible at all. 


In conclusion: 

It is time to address the users of EBICS who use short keys so that they can update their keys in good time before the switch to EBICS 3.0.1 or before November 2021, generate their new keys and ideally submit them to their financial institution signed with the previous keys. Users who do not want to communicate with the key requirements applicable from November 2021 would face a fatal dysfunctionality of the EBICS access.

Author: Michael Schunk