Securing bank transactions with privacyIDEA

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

The transaction data could be changed before they reach the bank.

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.

Just ask us!


About Enterprise File Encryption

This article was first published at owncloud.

Your Data is at risk. And thus is your personal life and your company’s values.
You avoid hackers, trade espionage and rogue governments getting your data by using your own cloud storage like ownCloud. Your data under your control.

But depending on where your storage is located some risks still remain. The connection to your ownCloud installation in the hosted datacenter is TLS protected. All data are encrypted on their transport to the datacenter. But within the datacenter your data is plain text.
You are using ownClouds integrated encryption? You even have the full disk encrypted using LUKS or similar methods? This is fine but only protects you from certain attacks like stealing the sole hard disk.
But if the attacker gains access to the very location where the actual encryption takes place, the encryption is useless, since this location also contains the encryption key! Thus, if the attacker has access to the datacenter or – more probably – is a rogue or bribed employee of the datacenter the attacker can get physical access to your encryption key and finally to your data.

This is why client side encrpytion is such a good idea. With client side encryption the data is encrypted on your own client. The key material is only available on your client, not on the ownCloud server. The data is sent already encrypted to the server. Not only is the transport layer encrypted using TLS but the payload itself within the TLS can not be read anymore.
The ownCloud server and the storage never sees any clear text data and never has access to the encryption key.
The tool cryptomator which was introduced in this[link] previous blog post works this way.


But enterprise scenarios come with a longer requirements list than tools like the slick cryptomater can cover.
Even smaller companies have to comply with the requirements of the enteprrises if they are supplier for the bigger ones.
I have run several projects where supplying companies were confronted with the requirements for encrpytion and two factor authentication since they delivered to bigger enterprises, that simple defined those requirements. Let us take a look at the requirements when you run a company or bigger organization.

File Encryption

In such scenarios when encrypting data it is important to encrypt files. In contrast to full disk encryption and encrypted containers encrypted files can be moved around without breaking the encryption. Even the encrypting file system does not provide this sticky encryption. If the user moves the file to another disk or a USB stick, the file would not be encrypted anymore, since with full disc encryption and container encryption the encryption is bound to the storage and not to the data.
The data should not be decrypted when the file is moved. This is why we require to encrypt the files and keep them encrypted when moving the file to another locatoin.

Client Side Encryption

As mentioned in the beginning the files should be encrypted and decrypted on the client. This way only encrypted data is transferred via the network. The user can also move the files as in the previous requirement but most important the encryption gets independent from the storage location.
The administrator can access the file but can not read the data in the file. This way all backup mechanisms still work, but the data is persistently protected.


When working with data in a company users are usually working on projects with other colleages.
Thus several users need access to the encrypted data. The project leader or data owner might need to add other users to the group and grant them access to the encrypted data or withdraw this access again.

It is important to note, that usually not *the* administrator gives access to the data. Complying to the concept of duty of separation, the administrator may be responsible for providing the storage and taking care of the backup, but he might not be allowed, to read the data and probalby will not be allowed to decide who is allowed to read the data.

This leads us to the requirement for a bit more sophisticated key management.

Key Management

If files are encrypted with passwords then a password based key derivation function (PBKDF) is used to generate the encryption key. A badly implemented encryption would use this key to encrypt the file. This would result in the problem, that – if you change the password – the complete file needs to be decrypted with the old password and re-encrypted with the new password. This might be fine for one small file but totally fails with a complete directory, a harddisk or a huge storage.

When you look at encryption a multi-step encryption has proven to be sensible. Even in the case of a PGP encrypted Email, the email is for many reasons not encrypted with the public key of the recipient directly but with a symmetric data encryption key (DEK), which is unique to this email.
Only this DEK is encrypted with the public key of the recipient. This is called Key Encryption Key (KEK).

The other great thing when using a DEK and KEK is, that several users can have access to the same data with different passwords – or different KEKs. This way a user who has access to the data can also be allowed to grant access on the data to a new user. The software can access the DEK with the KEK of the old user and encrypt the DEK of the file with the KEK of the new user.

This way, each file has a list of KEK-encrypted DEKs attached to it. Thus an enterprise encryption software needs to allow adding users with their key encryption key to files.
Users need to have different roles like adding users to access groups or only being allowed to access the data.

(Of course you can not effectively avoid the user breach: The user who has been granted access to the data can go rogue and print the data, take a photograph or copy. If you want to tackle with this threat you need to think about implementing data leakage prevenion.)

So what the heck with the KEK?

You might use the latest and greatest symmetric unbreakable encryption algorithms for actually encrypting the data. But these are of no use, if the access to this encryption – usually the password – is week. An attacker would always target the KEK (a.k.a. Passwords) and not the DEK (The encryption itself).

Thus, another important requirement is not only to encrypt the data but also to protect the access to this encryption. A good way to do this is not to use a password based access but to use public key cryptography.
As mentioned with the PGP example, the KEK is the public key of the user. The DEK is encrypted with the public key.
The user has to provide his private key to decrypt the DEK to access the data.

Perfectly the private key is located on a smartcard, so that the private key can not (easily) be copied or stolen.
If the private key was initially created on the smartcard, you can in addition be sure that the private key was not stolen or copied.

Data Read Escalation

As we required earlier the administrator usually can not read the data and can not add users to the group of data users, who can read the encrypted data.
But in certain cases – when all users have lost their smartcard, forgotten their passwords, have quit the job – the company needs to be able to access the encrypted data without one of the originial users available.

In this case the encryption solution needs to provide a process with preferably 4 eyes principle to regain access.
4 eyes principle is important to increase the trust and allow full deniability for all participants.

Technicaly the key management can to this by adding a system-KEK or recovery-KEK to all files.

Hardware Security Modules

Besides using smartcards for the user’s KEKs, the support for hardware security modules can be a good idea. The HSM can be used to protect the system-KEK or recovery-KEK or to sign configuration data. Otherwise a user with the right to only read encrypted data could escalate his rights to “assign-new-users to the encryption group” by flipping some bytes in the database.


We already said, that reencrypting the data is a bad idea and should be avoided. Nevertheless it can be necessary. E.g. if the symmetric encryption algorithm used to encrypt the files is know to have weeknesses. This is especially important if you need to upgrade the encrpytion algorithm.
In a worst case scenario the system- or backup-key could be compromized, then this keys need to be changed.
The solution should provide the possibility to reencrypt the data.

Possible Solutions

There is a quite nice long list of commercial products, which cover those requirements. Some are better and more convenient in smartcard support, some in group management and some in automation.
It is always a good idea, to identify your own needs and evaluate the right solution.
Most of the tools are products of companies located in Germany and thus comply to the (still) stirct data protection laws.

Why is there no open source?

Nevertheless there is no open source tool, which is capable of covering the requirements and competing with the commercial tools available. This might be due to the scratch-your-own-itch concept of open source development. Individuals start open source projects, which will provide a solution to their own problem. A perfect example is the tool cryptomator. It does a great job in file encryption and covers a lot of requirements but totally lacks the key management and because of this will only work for a single user, but not for project groups in a company.
Another reason might be, that the customers for such an enterprise file encryption tool in 95% of the cases runs Windows on their clients and may thus be used to install and use closed source software – so why should the software vendor bother about an open source busines model?

With the growing pressure of undemocratic survailance requests even by the German government the threat through backdoors and unpublished zero days increases dramatically. In a sensitive area like data encryption, where data obviously is to be protected from preying eyes, open source solutions can help to regain the trust in such software.
So I urge all open source companies with data storage centric products to think about enhancing their portfolio with an open source project for a trustyworthy, modern, enterprise ready file encryption solution. In my opinion this is not only a gap in the market but would also be a great help for a mature and democratic society.


ownCloud Two Factor Authentication

ownCloud and privacyIDEA

privacyIDEA-800pxWith ownCloud 9.1 a new authentication framework for two factor authentication provider was introduced.

We implemented the privacyIDEA ownCloud App which connects ownCloud with privacyIDEA. This way you are able to use many different kinds of authentication devices like smartphones, key fob tokens, Smartdisplayer cards, Yubikeys for your users to authenticate at ownCloud. In addition users can use the very same centrally managed token to authenticate at other services like your VPN, Windows Desktop or SSH.


Use any authentication device with ownCloud.

This is a big improvement for your enterprise environment in contrast to only managing second factors within ownCloud.

ownCloud developers have done a great job on providing this 2FA API. Nevertheless while implementing the first external provider (the privacyIDEA ownCloud App) we realized some shortcomings of the API.

Working togeather with ownCloud to improve the Two Factor integration

I was able to work closely togeather with the ownCloud security specialist and the developers to discuss ideas and a strategy for improvements. Thanks a lot for this open mind and the time! We all (ownCloud and NetKnights) are eager to further improve the security and possible integration scenarios of ownCloud.

More information to the user

One idea was to improve the communication with an authentication backend like privacyIDEA. The current implementation only allowed to show “Authentication failed!” in case of an error. But using an external authentication system it sometimes can proove useful to display more information to the user, since authenticating with two factors is a more complex and error prone process. Also on the user side. Furthermore, displaying more information can be necessary when it comes to scenarios like challenge response.

Anyway, this resulted in an improvement of the 2FA API and a pull request to the ownCloud github repository which is planned to be contained in the next ownCloud release 9.2. This way the privacyIDEA ownCloud App can display additional information like “privacyIDEA Server down”, “Internal privacyIDEA Error”, “Wrong OTP value”… Thus the user could fix his problem (by using the correct token or flipping the token upside down…) instead of calling the helpdesk and causing additional costs.

Emails and SMS

Another topic, that was discussed, is the support for external challenge response like SMS, Email or TiQR tokens. While this is still work in progress the discussion showed, that great and sensible solutions and integrations can be achieved when combining ownCloud with privacyIDEA.

Go Secure

Secure your own data, your ownCloud with 2nd factor authentication under your control!

Get the privacyIDEA ownCloud App.


Lasting Two Factor Authentication with privacyIDEA

You may have read about the NIST, lately. NIST is updating its Digital Authentication Guideline.


NIST is the National Institute of Standards and Technologies. It is part of the Department of Commerce of the United States and works on standards which are met by several governmental institutions and and also companies. It is a physical laboratory and also deals with topics like earth quakes and fire protection. But also with standards in information technology. E.g., NIST played it’s role in defining the encryption protocols DES and AES.

Digital Authentication Guideline

Die Verwendung von SMS für Authentifizierung wird von NIST als veraltet eingestuft.

Die Verwendung von SMS für Authentifizierung wird von NIST als überholt eingestuft.

NIST now released a draft of its Digital Authentication Guideline. This guideline describes how to evaluate risks in authentication processes and also gives dedicated countermeasures and advices. Two factor authentication plays an important role.

The interesting and new part is, that the draft SP800-63B explicitly points out the risks of Out-Of-Band authentication using SMS (text messages). In section the usage of SMS is event denoted as deprecated!

OOB using SMS is deprecated, and may no longer be allowed in future releases of this guidance.

No authentication technology lasts forever

We do not want to start bashing SMS. But we should be very well aware, that no authentication technology is built for eternity or will withstand hackers forever. Technologies and processes we are using today may work very well – today. But tomorrow things may have changed and these technologies and processes may be easily bypassed by hackers.

The common conclusion should be: The used authentication technology or authentication process must be replacable. We should not rely on a product, that only implements one authentication process – in this case SMS. Because the effort if changing to another authentication process would mean changing the complete software. The complete backend. The vendor. Get a complete new solution.

Ever-lasting authentication with privacyIDEA

Due to this NetKnights relies on privacyIDEA. privacyIDEA is an authentication system, that supports a broad variety of tokens, authentication devices and thus authentication technologies and processes. Of course privacyIDEA supports one time passwords via SMS and Email. But it also supports one time passwords by smartphone apps, challenge response mechanisms, many different kind of OTP hardware devices, Yubikeys and also X.509 certificates and SSH keys.

A company which uses privacyIDEA has no problem with the NIST guideline. They can just enroll new token types for their users and smoothly change SMS tokens to smartphone apps, hardware tokens or Yubikeys. No software needs to be evaluated and replaced. No vendor needs to be contacted and no processes need to be changed.

This way privacyIDEA helps to reduce administrative costs and also reduces the TCO. NetKnights provides different level of service level agreemets for privacyIDEA. We also help with the integration of privacyIDEA into the company network and deliver the appropriate tokens.

Just ask us.



privacyIDEA applies for Open Source Business Award


The German Open Source Business Award (also called OSBAR) is awarded by the  Open Source Business Alliance. The Open Source Business Alliance in a German association of companies providing and working with Open Source solutions with about 200 members. The OSBAR is looking for innovative open source projects and ideas which provide a crucial benefit to companies and institutions of the public sector.


We believe that the open source project privacyIDEA covers these requirements. Compared to ordinary or classical OTP systems, privacyIDEA implements a lot of new ideas and thus allows for elegant solutions in your network.

This is why NetKnights applied with the project privacyIDEA for the Open Source Business Award. You may read the German application. privacyIDEA_OSBAR_2016


Two Factor Authentication with Event Handler Framework

privacyIDEA will provide an Event Handler Framework in the upcoming release 2.12.

Policies for Two Factor Authentication

Using policies you can already configure privacyIDEA in a very detailed and sophisticated manner. The administrator can define the behaviour of privacyIDEA. This way you can run privacyIDEA in many differenz scenarios and find a solution for all requirements. Policies change the authentication and authorization behaviour. The administrator can define security levels or perform an easy migration.


With the Event-Handler you get completely new possibilities. While policies change the behaviour of privacyIDEA, the Event-Handler does not change this, but starts completely new actions depending on events without changing the behaviour define by the policies.


event-handler-enThe screenshot above shows an event definition for the event “token_init”. This is the event of initializing or enrolling a token. In addition to the way the token is initialized, now the action “sendmail” is triggered. The logic is implemented in the handlermodule “UserNotification”. The interesting thing is, that such an action can be bound to any arbitrary event.


More Event-Handler-Module

The first event-handler module to be shipped is the module “UserNotification”. More modules are about to follow. A moduel “Enrollment” could trigger and action to enroll a certain token type for a user — as an reaction to any kind of event!

This way you get unimagined possibilities to design new, creative configurations and workflows. Once more privacyIDEA proves, that it is a modern, innovative and trend-setting authentication system.

Please sign up to our newsletter to always be up to date.


Migrating a proprietary OTP / two factor solution

Easy migration of an existing OTP system to privacyIDEA

Often customers decide to switch their existing, proprietary OTP / two factor authentication system. They do it for several reasons. The existing system is to old and they get no useful updates anymore. Often the existing system is not flexible enough. The tokens, which run with this system, do not comply with the todays requirements. Companies merge and each company comes with its own proprietary authentication system. Sometimes the existing system is simply to expensive. And sometimes the customer prefers to use a transparent open source solution due to the increasing problems in trust and survailance.

These are reasons, why customers decide to use privacyIDEA.

Today privacyIDEA provides several possibilities to perform such a smooth migration. E.g. the RADIUS token. But starting with privacyIDEA version 2.11 there will be an even simpler migration scenario. privacyIDEA 2.11 will be released on March, 18th. If you want to stay tuned, please subscribe to our newsletter.

Centrally defined RADIUS servers

With privacyIDEA 2.11 you get the possibility to centrally define RADIUS servers. This is similar to the possibility to define SMTP servers centrally, which was introduced in privacyIDEA 2.10.

Centrally defined RADIUS server "RSA SecurID"

Centrally defined RADIUS server “RSA SecurID”

These RADIUS server definitions now can be used within RADIUS tokens or policies!

Up to privacyIDEA 2.10 each user had to get his own RADIUS token. Such a RADIUS token points to the RADIUS server of the obsolete OTP system. As long as the user has no real OTP token within privacyIDEA, the user will be authenticated against the obsolete OTP system.

One policy for all users

Starting with version 2.11 you now can define a privacyIDEA policy based on this centrally defined RADIUS server.


The centrally defined RADIUS server “RSA SecurID” is used in the passthru-policy.

To do this, the existing passthru-policy was enhanced. The passthru policy fires, if a user has no token assigned within privacyIDEA. With the passthru-policy the authentication request is forwarded to the LDAP or AD or — new in version 2.11 — to a centrally defined RADIUS server.

This means, that you only need to define one single policy to start a smooth migration from your old OTP system to privacyIDEA. You can then enroll new tokens to the users within privacyIDEA step by step without a hurry or without doing a hard switch!


The scenario described in this post works flawlessly with all systems, that use a RADIUS server. Including systems like Kobil, RSA SecurID, SafeNet, Vasco (in alphabetical order).

Just ask us!

The problem with the Google Authenticator


A good mobile network coverage, cheap smartphones and the trend “bring your own device” led to a paradigm shift in two factor authentication. A few years ago two factor authentication was a topic for large companies and those with a high need for security. But now two factor authentication is handy and cost efficient.

And finally we all learned that we should do something about our data security.

I very much like that everybody is thinking about increasing their security, but when talking of smartphone apps, email or SMS, we also have to be aware of the limits, that come with these convenient solutions. In certain cases the so called two factor authentication again boils down to one factor.

The Google Authenticator

The Google Authenticator was one of the first apps, that provided the OTP functionality with a piece of software on your smartphone. The Google Authenitcator supports HOTP and TOTP algorithms. Possible other apps are FreeOTP (TOTP) or HDE OTP (TOTP).

Using your smartphone as an authentication device can indeed make sense. An important aspect of the factor “possession” is, that the user takes care of this factor and does not leave it on the desk or plugged into the computer when going for lunch or leaving the room otherwise.

The Seed (1)

The OTP algorithms HOTP and TOTP are based on a symmetric secret key which is also called seed. Using the algorithm, the seed and a moving factor the OTP value is calculated. This means that the seed needs to be protected. We doubt that you can protect the seed in the smartphone on a high security level. The smartphone is a powerful computer with old, not up-to-date software and usually a bad virus protection.

The Seed (2)

But the even much simpler misuse is during the enrollment process. The initialization of the smartphone app.


With the Google Authenticator this happens with a QRCode. The QRCode contains the seed in clear text. The above code has the contents:


The value O6LVCAVTS2IJ25NKXKOOGCNTJIOFNUXA is the secret key in the so called “base32” notation. This might look complicated to an untrained, human being eye. But the computer takes this as clear text for real.

As this is a timebased OTP token (TOTP), each device that scans this code will create the same OTP value. The value will change, but it will be the same value. On each device. Always.

A Self-experiment

Do you have two smartphones at hand? Install the Google Authenticator on both smartphones or HDE OTP or FreeOTP. The only prerequisite is that the smartphones have the exact time.

Experiment 1

Scan the QRCode with smartphone A and scan the QRCode with smartphone B.

Start the Google Authenticator and watch that both smartphons will show the same one time password. The same one time password two times? This is wired. Something is wrong with the naming here.

Experiment 2

This experiment gets even worse. Delete the token from smartphone B. Print out this blog article or at least the QRCode. Put it into the drawer for about a week.

After this week open the drawer, take the sheet of paper an scan the printed QRCode with the smartphone B. Smartphone B will show the same QRCode as smartphone A immediately.

The problem in your company

Due to the nature of the TOTP algorithm and the rollout procedure of the Google Authenticator you can create identical copies of those tokens. Even after a week or a year.

If – as a company – you want to avoid that users give their passwords to their colleagues you are in a mess. You must not rely blindly on the two factor authentication. The same QRCode can be scanned by all colleagues and thus each colleague can login as his pal without any hassle – since he has a copy of his second factor. And again you – as a company – can not reliably identify which employee logged in, when you see a certain user account. The idea of the second factor is void.

A possible solution

The problem is in the rollout process where the secret key is provided in clear text. A better rollout concept like the one of the TiQR-Token can help. In this case the smartphone creates the secret key. The scanned QRCode just contains a registration link, to which the secret key is sent by the smartphone. But this rollout process requires a slightly more complicated running infrastructure. The smartphone needs to be online, the registration link has to have a certificate trusted by the smartphone.

Especially the ease of the rollout of the Google Authentication probably lead to its success. So you see you need to plan and think things through when implementing a two factor solution in your network. A weaker security is only acceptable if you are aware of its side effects and consequence and you can accept the remaining risk.