Making wiring money secure is a big challenge. We are all grateful, that we no longer need to go to the bank institute for wiring money to another bank account. It is also great that we do not need to use these TAN lists anymore, when we were asked to cross out number by number after each bank transaction.
But what are still the challenges with electronic bank transactions?
Integrity of the transaction data
The banking user uses a web interface to tell the bank, how much money he wishes to send to another account. A malware in the user’s browser, can change this data. Originially the user wanted to send €100 to the account 1234567890, but when he clicked the button “send”, the malware changed the transaction data to €10000 and to the account 666.666.XX. The bank receives the 10000 Euros for the evil account. It has no chance to know, that originally the user wanted to send 100 Euros to his friend. Also the user does not immediately know what happened.
The money might be gone.
TAN lists and OTP tokens
Several years ago TAN lists were used. Some banks are using OTP tokens, to identify the user, during a transaction. But the TAN lists and the OTP tokens can not ensure the integrity of the transaction data. The OTP token can be used to verify that it is really the true user, who is in the possession of the token and who triggered the transaction. But still a man in the middle can intercept a valid transaction and change the amount and account! Still neither the bank nor the user know, that something happened in between.
This is due to the problem, that there is no cryptographic link between the transaction data and the OTP.
OCRA: Linking transation and TAN
The OATH Challenge Response Algorithm (OCRA) can provide this missing link. OCRA is specified in RFC 6287.
Just like HOTP and TOTP – which you might know from the Google Authenticator – the OCRA algorithm is defined by the Initiative for Open Authentication. Basically OCRA is some kind of enhanced HOTP algorithm.
The HOTP algorithm takes only one parameter, the “counter”, which is increased continously by each key press. In conjunction with the secret key a 6 or 8 digit one time password is calculated. The secret key represents the possession factor. Thus the one time password depends on the secret key and the parameter “counter”. In case you like buzz words like HMAC and SHA, take a look at RFC4226).
To cut a long story short, OCRA simply enhances the “counter” and allows many more input parameters for roughly the same algorithm. I.e. you can also put the account number and the amount into the OCRA algorithm. This will result in a one time password, which depends on the secret key and the complete transaction data. If you or an attacker would put other transaction data (input parameters) into the algorithm, this would result in another OTP value.
How can this be used for online banking?
The bank initially hands over the secret key to the user. The key can be contained in a hardware device or in a smartphone app. The bank knows each secret key of each user.
The user enters his transaction data on the banking website. The user also transfers the transaction data to his device (which contains the secret key). This transfer could be done manually or in any automatic manner using QR codes, network or bluetooth.
On the device the user verifies the correctness of the transaction data. Only then he continues by generating the TAN on the device. He now can add this TAN in the banking website. The transaction data and the TAN is sent to the bank.
As mentioned earlier the TAN cryptographically depends on the transaction data. The bank can use the user’s secret key to also calculate the TAN for the given transaction data. If the bank gets the same TAN, the bank knows, that the user really was willing to perform this transaction and that the transaction data were not modified by an attacker. Otherwise the modified transaction data would result in a different TAN.
In this scenario each and every transaction which is issued by a bank customer is cryptographically secure. So it is more important to protect the secret key in the device than the online banking account itself, since there can be no transaction without the secret key.
privacyIDEA, OCRA and DisplayTAN
privacyIDEA supports OCRA (the TiQR token) for quite a while. In the upcoming version 2.20 the OCRA mechanism was enhanced, so that it can be used with many different devices, especially with the DisplayTAN-card.
Banks do not need to program the key management for their web application on their own to support OCRA. They can easily use one single REST API call with privacyIDEA to add strong transaction security with privacyIDEA.
The DisplayTAN cards are attractive for customers, since they can be integrated in the banking card itself. This way the customer can have on card for all tasks.
