The handkerchief problem with encryption

[patrickboch]

When we speak to customers about security, we often hear the requirement for “more encryption”. Which makes sense, doesn’t it? After all, with todays’ encryption algorithms, anyone who is able to steal encrypted data cannot really do anything with them without asking a supercomputer - who then would be busy decrypting for the next 7 million years (only to come up with the answer “42”). Well, unfortunately it’s not that easy.

And when I’m saying encryption is not easy, I’m not even referring to the differences in asymmetric vs. symmetric encryption or the different types of encryption algorithms (we’ll get into details of those in future posts). I will not even go into the details of different layers where encryption is important. Rather, for the purposes of this article, I’d like to view the encryption from the perspective of the application.

Firstly, it's important to understand that – quite understandably – vendors like to promote their solution as having superior encryption. The reality is quite different, however. One reason for this is the standardization of encryption, a second reason can be found within the nature of todays’ application architecture and the third reason doesn’t even have to do anything with encryption or even technology, for that matter.

The first reason is quickly covered: any technology solution today does not exist in a vacuum. On the contrary, in a highly connected world, solutions need to be able to communicate, even when encrypted data is involved. Hence, most encryption is standardized and pressed into three letter acronyms such as TLS, SSL or AES.

Secondly, viewing encryption from an application perspective: It would obviously best if the application could process data even when it is encryption and only the decrypted values would be displayed in the User Interface (UI side encryption). Put differently: it would be great if the application knew that

PQPM7aCOxurcuhlI7Exdjw==

multiplied with

BrDwPV2s6Xri6jndOt4NYg==

equals

O0HrSmCSBNW6ugKA7N2ZMg==

You already see the problem? Any application knows that 6 x 7 = 42 – the same example I used above, but encrypted. However, in order to be able to perform this calculation, the application needs to know the key the plain text was encrypted with.

Side note: Theoretically this is even possible without the application knowing the key. The term for this is “homomorphic encryption”, but it’s light years away from being commercially viable.

In other words: the application – at some point – needs to decrypt the data, and doing so requires the encryption key. So far for the theory, now let’s see what this means in a typical solution architecture today.

The real question customers should ask is: Who do they want to protect against and "how do bad actors retrieve their precious data" or "who are these bad actors anyway?". Some examples:

• If you implement filesystem encryption and database volume encryption (often referred to “transparent data encryption”, or TDE), you are protecting against the administrator of the infrastructure (i.e. they will not be able to view the data in plain text). However, the database admin or the application admin will still be able to see the data.


• If you want to prevent the database admin to see data, you will need to implement application side encryption. This encrypts data within the database but is transparent to the application. In other words, depending on their access rights, application users might still be able to see the data.


• If you want to make absolutely sure that the application administrator also doesn’t view any data, you will have to resort to the UI-side encryption which I mentioned above – which, however, makes a processing of data impossible.

And now we’re finally getting to the heart of the matter.

Application Side encryption means that encrypted data is sent to the application and will stay encrypted until the application actually uses the data. If the data is used, the application will decrypt it, process it, and encrypt it again after use. This particular process – simplified – requires two things:

1. The database needs to support it


2. The application needs (a function) to support it.

Modern databases, such as SQL Server, Oracle Database or SAP HANA provide this support – and if you were to write a new application on top of either one of these databases, you can implement this support on the application side, too.

However, complex applications (MS dynamics, Oracle ERP and also SAP ERP) which have been around before databases supported that kind of encryption do not support application side encryption.

Is it possible to implement such a function in an “aged” application? It sure is – but it’s simply too much effort: these complex applications contain millions of lines of codes, with a similar number of dependencies within the code, so it would probably take years – even for corporations the size of Microsoft, Oracle or SAP – to implement full application side encryption.

Nevertheless, you sometimes hear the phrase “Microsoft (or Oracle) are able to provide this level of encryption”. And you might be surprised that I see this phrase as true, which brings us to the third reason, which is not technological but semantical in nature. For example: if you were asking me “can you hand me a Kleenex, please”, and I’d hand over a diaper – you’d be surprised, because “Kleenex” has become a synonym for a handkerchief. The company behind Kleenex, however, also produces diapers. The same scenario applies here: if (at least in an enterprise context) someone refers to “Oracle” they are referring to Oracle’s database product in most cases. On the other hand, when someone says “SAP” they are referring to the application – even worse, most of the times when someone mentions “HANA”, they are more often than not referring to the application “SAP S/4HANA” rather than the database.

If you compare apples with apples and oranges with oranges, however, you would need to compare the databases with each other and the business applications with each other. The result can be seen in the following table:

Encryption capabilities of selected vendors and solutions

As you can see, on close objection, there are almost no differences between the different products, at least when it comes to encryption.

The moral of the story is simple: Don’t ask for “more encryption”, but rather ask yourself first, who do you want to protect against. And if confronted with statements about encryption possibilities of specific solutions, make sure you don’t compare apples to oranges.

 In general, security needs to be approached holistically. Encryption can be a part of the solution, but it is no silver bullet. In many contexts, proper authorizations, logging and auditing are more effective and more appropriate.