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.

Und mal wieder ging ein Beitrag durch die Presse, dass weitere Schlupflöcher für eine klassische Erklärung von verschränkten Photonpaaren in der Wiener Hofburg gestopft wurden.

Doch was hat es mit der Quantenkryptographie eigentlich auf sich? Und dabei bietet die Schweizer Firma ID Quantique dazu schon seit Jahren Produkte an!

Zentralbild Prof. Dr. phil Werner Kar. Heisenberg, Physiker, geboren 5.12.1901 in Würzburg, Professor für theoretische Physik, Direktor des Max-Planck-Instituts für Physik in Göttingen, Nobelpreis für Physik 1932 (Aufnahme 1933) 39049-33

Werner Heisenberg, Vater der Quantenmechanik (1933) [Bundesarchiv, Bild183-R57262 / CC-BY-SA 3.0]

Management Abstract

„Quantenkryptographie“ ist ein irreführender Name, da hier nicht wirklich die Verschlüsselung selber Thema ist. D.h. mit Quantenkryptographie kann man keine Email und vor allem keine Festplatte verschlüsseln. Der Prozess, der weithin mit „Quantenkryptigraphie“ bezeichnet wird, dient lediglich dazu, zwischen zwei Kommunikationspartnern, „sicher“ einen Schlüssel auszutauschen, um diesen Schlüssel dann zu verwenden, um den eigentlichen Nachrichtentext mit klassischen Algorithmen zu verschlüsseln. „Sicher“ heißt dabei auch nicht, dass ein Angreifer nicht mithören kann, sondern, dass die Kommunikationspartner wissen, ob ein Angreifer mitgehört hat oder nicht und daher wissen, ob der ausgehandelte Schlüssel vertrauenswürdig ist.

Quantenkryptographie löst also das Problem des Man-In-The-Middle-Angriffs beim Schlüsselaustausch.

Quantenkryptographie Hintergründe


Erwin Schrödinger (1933) brachte uns die Katze

Disclaimer: Dieser Beitrag beansprucht nicht für sich wissenschaftlich korrekte Detailausführung, sondern ein grobes Verständnis für die Zusammenhänge zu vermitteln.

Die Quantenkryptographie arbeitet in der Welt der Quantenmechanik. Dies sind Effekte auf atomarer Ebene. Da wir – anders als die Newtonsche Mechanik – die Quantenmechanik in unserem Alltag nicht beobachten, haben wir hierzu keine persönlichen Erfahrungswerte. Uns fehlt Intuition. So wirkt sie auf uns merkwürdige, bisweilen unlogisch und ist schwer begreifbar.

In der Quantenmechanik gilt, dass der Zustand eines Objekts durch die Messung verändert bzw. erst bestimmt wird. Für die dicke meines Haares klingt das merkwürdig. Doch für die Quantenmechanik ist ein Haar immer noch die makroskopische Welt. Unheimlich dick. Und daher greift die Quantenmechanik erst bei ganz winzigen Größen. Bpsw. bei einem winzigen Lichtteilchen.

Erwin Schrödinger gab dazu das Gedankenexperiment mit der Katze in dem Kasten ab, bei dem die Katze erst tot oder lebendig ist, wenn wir den Deckel aufmachen. D.h. die Messung legt erst den Zustand fest, in dem sich die Katze befindet.

Messung von Lichtquanten

Die Messung von Lichtquanten haben einen angenehmen Vorteil, weil es hierzu eine gute Parallele in unserer makroskopischen Welt gibt – nämlich die Polarisation des Lichtes als elektromagnetische Welle. Dies ist vielleicht eingängiger, als den Lebenszustand einer Katze zu messen.

Wenn vor unpolarisiertes Licht mit verschiedenen Schwingungsebenen ein linearer Polarisationsfilter gehalten wird, erhält man danach linear polarisiertes Licht.


Mit Hilfe eines Polarisationsfilters kann die Schwingungsebene des Lichtes auf eine einzige Ebene festgelegt werden.

Wenn man nun vor das linear polarisierte Licht wiederum einen um 90 Grad gedrehten Polarisationsfilter hält, so wird das Licht ausgelöscht.


Ein Polarisationsfilter kann makroskopisches, polarisiertes Licht auslöschen.

Auf Lichtquantenebene ist der sogenannte Spin polarisiert. Auch dieser Spin ist messbar – vergleichsweise der Schwingungsebene. Wir unterscheiden hier vertikalen und Diagonalen Spin.


Die Messung von Lichtquanten mit polarisiertem Spin kann zu nicht vorhersagbaren Ergebnissen führen.

Um den Spin eines polarisierten Lichtquantes zu bestimmen, muss er gemessen werden. Doch dabei läuft man Gefahr – genau wie bei dem obigen Beispiel – das Lichtquant zu „vernichten“ oder in einen neuen Polarisationszustand zu zwingen. Man kann mit Sicherheit nicht sagen, wie das Lichtquant vorher tatsächlich gewesen ist. Es gilt:

  • Wird vor ein Lichtquant mit „vertikal“ polarisierten Spin ein vertikaler Filter gehalten, so kommt das Lichtquant immer durch. Wie nehmen das als binäre 1.
  • Wird vor ein Lichtquant mit „horizontal“ polarisierten Spin ein vertikaler Filter gehalten, so kommt das Lichtquant niemals durch. Wir nehmen das als binäre 0.
  • Wird aber vor ein Lichtquant mit „diagonal“ polarisierten Spin ein vertikaler Filter gehalten, so kommt das Lichtquant entweder durch als vertikal polarisiertes Lichtquant (binäre 1) oder nicht (binäre 0). D.h. man misst eine 1 oder eine 0 und weiß aber nicht, dass man auch das andere hätte messen könne. Das nebenstehende Bild veranschaulicht dies. In dem Bild zeigt eine 0,5, dass man entweder 1 oder 0 gemessen haben kann.


Quantenkryptographie Beispiel

In diesem Beispiel polarisiert Alice Lichtquanten aus einer unpolarisierten Lichtquelle wie einer LED. D.h. sie erzeugt einen Strom aus polarisierten Lichtquanten. Sie selber wendet die Filter an und kennt somit die Filteranordnung und die Polarisierung. Diesen Strom sendet sie an Bob.


Ein ungestörter Schlüsseltausch zwischen Alice und Bob.

Bob muss sich selber frei überlegen, welche Filter er pro Lichtquant anwendet.

Alice teilt ihm mit, welche seiner Wahl richtig war. Nämlich der erste, der fünfte und der siebte Filter.

So nehmen Alice und Bob die erste, fünfte und siebte Stelle und erhalten beide den gleichen 3 bit langen Verschlüsselungskey.

Sie können sicher sein, dass nur sie beide diesen Verschlüsselungskey kennen.

Man in the middle

Nun hört Eve diese Kommunikation ab. Doch schon die Bezeichnung ist falsch. In der Quantenkryptographie kann man nicht einem vorbeiziehendem Strom zuhören. Um ihn zu sehen (oder zu hören) muss er gemessen und wieder neu ausgesendet werden. Und genau hier entsteht das Problem, weil Eve mit den Messungen die Polarisationszustände der Lichtquanten verändern wird.


Der Schlüsseltausch wird von Eve gestört. Der Schlüssel wird durch Eve ungewollt verändert.

Auch Eve muss sich für eine Filteranordnung entscheiden mit der sie misst. Und genau hier entsteht das Problem.

Das fünfte Bit wurde von Alice vertikal polarisiert gesendet. Eve hat sich für einen diagonalen Filter entschieden. D.h. Eve kann eine 0 (\) messen – es kann aber auch sein, dass sie eine 1 (/) gemessen hat. Dies ist nicht ihre Entscheidung, sondern quantenmechanischer Zufall. In diesem Universum hat Eve nun eine 1 (/) gemessen, weswegen sie nun auch eine 1 (/) weitersendet. Da Bob das fünfte Bit mit einem diagonalen Filter miss, kann auch bei Bob eine 0 oder 1 gemessen werden.

Dadurch dass Eve messend und somit verändert in den Strom der Lichtquanten eingreift, schüttelt sie die Informationen durcheinander. In diesem Beispiel des 3-Bit-Schlüssels hat sie mit 75% Wahrscheinlichkeit den Schlüssel zerstört.

Alice wird mit ihrem originalen Schlüssel 101 etwas verschlüsseln was Bob mit dem Schlüssel 100 nicht entschlüsseln kann. Somit merken sie, dass die Verbindung abgehört wurde. Das Datenleck muss gefunden werden und der Schlüsseltausch kann neu beginnen.