Is “Privacy by design” feasible?

Yes, of course it is!

It is not however simple to design information systems with privacy in mind as a top priority. Consider this example as illustration.

A security research on the vulnerability in Intel CPU architecture that allows side-channel attack that could breach cryptographic keys was published on BlackHat 2018 conference. The vulnerability is named TLBleed and media already buzzed about it in June 2018 speculating that Intel might not provide the fix and wouldn’t even publish the vulnerability with a proper CVE. Well is this really a vulnerability in Intel Architecture?

Processing architectures are designed for optimal performance, power consumption, and physical characteristics. Software systems that operate on top of processing architectures (applications as well as operating systems), leverage those optimization functionalities to gain competitive advantage. However, software developers that integrate cryptographic functions into their applications to protect integrity and confidentiality of data have to do it with “privacy by design” as a priority. Particularly if they want to claim that their solution is EU GDPR compliant.

Unfortunately, the problem is not only about protecting privacy but it’s a systemic problem for security by design and affects every kind of software from cryptocurrency wallets over cloud computing middleware to embedded systems (these days called the Internet of Things, IoT).

Practically, to mitigate TLBleed vulnerability developers have to apply methods to avoid execution of cryptographic primitives within high-performance processing services. On Intel architecture they could use Intel Integrated Performance Primitives Cryptography. Here is also one very useful presentation with examples on how to avoid side-channel attacks on cryptography by secure coding.

For more information on secure cryptographic design you may also read my previous post on Heartbleed and ShellShock.