Think twice before implementing encryption
Security attributes are often summed in three, sometimes four, basic properties that we may need to implement on our assets:
- Confidentiality, the loss of which, is disclosure,
- Integrity, the loss of which is corruption,
- Availability, the loss of which is denial of service.
The fourth property is traceability, which is of no interest to us in this paper.
It is interesting that when talking about computer security, many people will think about confidentiality first. “What happens if my files get stolen?” “Google has all my e-mail!”
Disclosure may or may not be bad. Typically, disclosure of technical secrets or business information can result in the loss of a competitive advantage. Disclosure of personal data can result in breach of regulations under the GDPR, and various side effects such as personal embarrassment, as in the case of France’s former minister Benjamin Griveaux, whose political career came to a stop after the leak of a sex tape. It can also have catastrophic effects in terms of branding and litigation from those whose data leaked, as in the case of the Ashley Madison hack. And most of the time, it has very little effect besides temporary bad publicity, as in the Facebook Cambridge Analytica affair, which seems to have produced little more than a Netflix documentary on the topic.
But confidentiality is really only one part of the equation. Losing integrity means your systems may start working against you. When Avast failed to protect CCleaner’s integrity, all of the application’s users became targets for the malware embedded in the corrupt file.
Losing integrity often means your systems also lose their availability: they become unable to perform their function: this happened to car manufacturers, aircraft part manufacturers, and probably others as well, resulting in weeks of downtime and sometimes disruption of the supply chain upwards and downwards. It turns out that availability is often the most important property of systems.
What few people seem to realise is that confidentiality is really the opposite of availability. The more confidential a file is, the less available it is, almost by definition. Open source projects that publish their source code to hundreds of Git repositories over the Internet gain the resistance of redundancy. When Linus Torvalds’ hard disk failed, he lost next to no work. Meanwhile, to keep data confidential will require having the fewest possible copies, which increases the risk of loss. Or it will require that we encrypt the data, but then how do we keep a copy of the key just in case? How do we ensure that the key remains available to those who will need it through time? What happens when the only guy who knows the passwords dies and leaves millions of users locked out of their account with no way to retrieve their money?
Using encryption also often means that the availability of your data becomes dependent on the availability of the encryption infrastructure. If the encryption is based on certificates and you validate the certificate, as you should, then access to the data is conditional to the availability of the revocation server. If you use smart cards, you will need to have them at hand. And probably, you will need to keep them physically secure, which again reduces the availability of your data: now instead of just double-clicking on a file, you need to retrieve a physical key, get up, walk to the safe, open it, retrieve the card, … by the time you come back from coffee, you no longer know what you wanted to open.
This is also a problem when documenting large industrial projects. Typically over decades, everyone who worked on it will have left the company. Yet access to the data is still required. Every so often, you will run into a ZIP file that was dutifully protected with a password, with no-one on the project able to tell you what it is.
A good way to envisage the trade-off is to wonder what is worse: having all your files published for all to see, or losing them forever?