Talk like an Egyptian: a brief history of data encryption
While financial institutions have been using encryption technologies for years, the implementation is through “security silos” that seek to protect the most important data. In today’s world of high connectivity and strong regulation, however, all information must be seen as important.
The Information Commissioner’s Office (ICO) states that a key principle of General Data Protection Regulation (GDPR) is that personal data is processed securely by means of “appropriate technical and organisational measures” – this is the “security principle”. They add that Article 32 of GDPR includes encryption as an example of an appropriate technical measure, depending on the nature and risks of the data processing activities.
The problem is that encryption comes in many different forms, and many organisations simply implement full disk encryption so they can tick the encryption box. In reality, this “tick-box compliance” does nothing to protect data on active systems, whether at rest, in transit or in use. That means it is not just all of the data that should be protected, but it is all of the data, all of the time.
Encryption history
Data encryption goes back millennia. The ancient Egyptians, Greeks, Spartans and Romans all used some form of message concealment, in peace time as well as during wars. The Egyptians used Disordered Hieroglyphics, the Greeks –Steganography, the Spartans – Scytale, and the Romans – the Caesar Cipher.
While these basic methods laid the foundations for modern cryptography, things have moved on considerably. What has evolved are two fundamental approaches based on complicated mathematics: “symmetric” and “asymmetric” cryptography.
Simple symmetrics
The Caesar Cipher is an example of symmetric cryptography. It is designed to ensure that the plain text of a message is replaced by cipher-text which appears to be gibberish. The sender first encrypts the message with an “algorithm” and a “key”, then delivers the encrypted message. The recipient reverses the processes, using the same key and algorithm to decrypt.
A simple algorithm could be “to shift the alphabet”, using a key which would be “the specific number of places to shift”. So, a key of three means that the letter A would be shifted by three, and therefore replaced with D, and so on. The person receiving the message uses the same key to reverse the process, using the same algorithm.
There’s a challenge with symmetric cryptography
All modern forms of symmetric cryptography are based on this principle. However, there is a significant problem with its security. Clearly, the sender needs to be sure that only the recipient can read the original message by decrypting the ciphertext. The challenge is in securely delivering the key to the recipient. If someone intercepts the delivery of the key, and they know the algorithm used, they can easily decrypt the text.
This is where asymmetric cryptography comes in
To overcome this problem researchers came up with asymmetric, or “public key” cryptography, using some complicated mathematics to create two tightly connected keys for each person. One key is a “public key” and the other is a “private key”. For example, if Bob encrypts a message using Alice’s public key, she – and only she – can decrypt it using her own private key, hence the asymmetry of the process. Alice can safely give everyone her public key, knowing that only she can decrypt messages that are encrypted for her because she keeps her private key secret.
Asymmetric cryptography also has a challenge
How does Bob know that Alice’s public key really is what it claims to be? If a malicious individual, let’s call her Villanelle, manages to send her own public key to Bob, pretending that it is Alice’s public key, then Villanelle will be able to decrypt Bob’s messages to Alice. Villanelle can then re-encrypt each message using Alice’s real public key and send them on to her, so no-one notices the interception and the breach goes undiscovered.
We need an infrastructure
Rather than relying on individuals to send their public keys to each other – an error-prone, easily manipulated and frankly unusable approach – there needs to be an overarching authority that is trusted by the whole community. In the real world we have a global infrastructure in the form of governments that issue passports to their citizens. The passport acts as a trusted identity for each travelling individual. These concepts of “trust” and “identity” are introduced with Public Key Infrastructure (PKI), where digital certificates are used in place of passports.
Enter PKI
In a community that needs to share encrypted messages and data, all members “trust” a “Certificate Authority” which issues everyone with their own identity in the form of “digital certificates”. The certificate contains the user’s public key. This approach means that Bob can be sure that Alice’s public key is genuine because it is certified by their common Certificate Authority. The infrastructure overcomes the asymmetric cryptography challenge because everyone in the community trusts the Authority.
So why don’t we just throw symmetric encryption away?
Public key encryption can be slow. But symmetric encryption is fast – even more so nowadays since modern CPUs have dedicated instructions for the purpose. So, a combination of both is used, playing to the strengths of each. Symmetric cryptography is therefore used to encrypt files and messages – each with its own unique key. Then asymmetric encryption is used to secure this key. And we can be sure that only the intended individual can decrypt the data because their digital certificate from PKI assures their identity.
Isn’t this all too difficult?
You could be forgiven that with all this evolution and the plethora of encryption products on the market, we had it cracked. But is not as simple as that. Many encryption products rely on individuals to choose which information should be encrypted. Or at best they use data classification tools that automate some of the decisions, with IT specialists defining the decision-making rules.
But to deliver comprehensive data protection, firstly we have to recognise that even the most innocuous-looking information could help the “bad guys”, for example, to build a set of personal profiles which can be used for fraud. Therefore, all information must be encrypted a ll of the time, and in all locations. All data – 100% – must therefore be protected at rest, in transit and in use. And particularly with the exponential growth in remote working forced on us by COVID-19, we need to be sure that information is useless if it falls into the wrong hands – whether by accident, through insider theft or by malware attack
Modern PKI encryption techniques
To be useable, 100% encryption needs to be fast and completely invisible to the user – removing the human element entirely. The only way to do this is through transparent encryption which operates at the file system level. This way there is no disruption to the way people and applications work. If you want to edit a spreadsheet – you just open it as usual. All the process of finding keys, decrypting and encrypting has to happen behind the scenes. This approach means that there are no user decisions to make – the data will always be strongly protected, and users don’t have to decide what to encrypt and which information is less important.
And since real life isn’t simple, this type of approach means that data encryption can be applied to all processes and systems – new and legacy. With PKI encryption implemented in this way we can finally move away from security silos to comprehensive protection without any gaps.
The Romans, Greeks and Egyptians showed us the way, and if we had thought more about protecting the data and less about simply trying to prevent access to it with firewalls, user controls and other “castle and moat” techniques, modern information security may have taken a different route. But the fact is that we now have the knowledge, the technology, and the processing power to deliver on the promise of using encryption to protect 100% of the data 100% of the time.
Interesting, I wonder what the statistics are on your first point there