Systems Design‎ > ‎

How to Achieve Clear Text Security

Everybody knows it: to make a system secure, we just need to encrypt it. Full stop. It is true for banks, social media, cell phones and even IoT. There are lots of researchers spending their lives designing new algorithms and it's only a matter of time to find these algorithms implemented in hardware blocks or available as netlists for next-generation, FPGA-enabled processors. The Germans knew about it during World-War II - that's what Enigma was about.

Well, maybe you're right. If you ask me, maybe not and here is why.

Secure Systems Requirements

By now, we all should know that security is about 4 basic concepts: authenticity, confidentiality, integrity and availability. There are several standards and guidelines to choose from, like COBIT, ITIL, ISO 27001, etc. It all boils down to documentation procedures and methodologies. But is it enough? If it were so easy, why would we receive every year articles titled "Hall of Shame" with the worst intrusions? Let's take a step back and see what the requirements are.

Not all systems are alike and not all information is equally sensitive: you won't treat an icon on a marketing page like a credit card number. Similarly, data at rest in a database will require stronger encryption than a transactional server with periodic key updates. In the end, data is secure as long as it cannot be decoded before it becomes obsolete. So there are several questions to ask before we start:

  • How critical is my system?
  • How much time will my attackers have to decode the data?
  • Will the data still be valid by the time they crack it?
  • If obsolete data can be decoded, can it be used to crack other valid data?
  • How sensitive are individual fields?

Security vs. Complexity

It should be clear by now that a system is never completely secure, and if it happens to be, it won't be forever: even if Moore's law has been said to be dying for 20 years, computing power is becoming higher and cheaper every year. During World-War II, Enigma had an equivalent complexity of 76 bits, which was seen as unbreakable by its creators but history showed that, even by then, it did not pass the test. Nowadays, 128-bit WEP algorithms are easily cracked by free software and 256-bit is considered a minimum for a relatively safe operation. But for how long? Complexity is a time bomb waiting to burst in our hands.

Encryption is nothing more than obfuscation: data look random at first sight, until you get the key to make sense out of it. Hackers are waiting in the dark and look patiently at your data flow. They are just looking for certain conditions to start analyzing your secrets:
  • Have access to a minimum quantity of data to look for patterns
  • Detect a predictable pattern which will indicate when the key is cracked
In short, the most verbose systems are potentially the most vulnerable. A consequence is that encrypting EVERYTHING also increases vulnerability for the sensitive parts, if they do not have their own protection.

Predictable patterns are a potential leak in your strategy. Let's assume you store VISA card numbers in your database: the attacker will look for a pattern "45" at the beginning of the number when trying to crack the number. Then we will convert it to binary-coded-decimal to hide the content... but your pattern still exists, with a leading 0x45. Fair enough, let's make it binary! Good guess but you still have about 12 null bits at the top, which will call the attacker's attention. Then fill these with a random pattern before encryption. You can still extract your number relatively easily and you will keep at bay the smaller players.

When dealing with authentication, HMAC is a nice alternative. Instead of sending the password encrypted in some form, you create a challenge based on strong encryption and a decimal conversion, leading to 6 digits. It is a clever way to send a response based on the result without leaking the secret: any bit error in the whole hash will generate a completely wrong number. It is usually based on strong encryption and cannot be cracked without a huge number of samples. Your best guess is a 1-in-a-million blind guess. Just beware that the current botnets can organize an orchestrated attack where each node tries a different code at the same time and you're in for the headlines - and there are more than enough vulnerable Internet-facing webcams to do the job. I'm not talking about a potential risk: just read the news to see what the hackers are currently able to do.

The Clear-Text Security Paradigm

Let's face it: you will never reach any level of security if you don't encrypt your data. Nevertheless, once your key was cracked, your traffic is as clear as water. So if your strategy is based on a single encryption scheme, your security is only a matter of time. At that point, your best guess is to say "Good boy! You made it and got a candy. Now let's move to round 2."

The Clear-Text Security paradigm is not about transmitting everything unencrypted: it is about using strong encryption for the most sensitive information and giving away (or using weaker encryption for) the less critical data. By doing so, you will call the attention of the hacker (strong encryption does not go unnoticed) but reduce the available samples for decoding. This way your hacker will have more entertainment and you will reduce your exposure.

Another layer of security would be to use a variable key dependent of the data: it will reduce your costs on genuine nodes (you know how the key is formed) while randomizing the key from the hacker's perspective. He may eventually crack one packet but will have to start again with the next.

The Achilles' Heel

There are 2 aspects that require particular attention.

  1. If you plan on using strong encryption (let's say for instance 256-bit keys) your encrypted data fields must be at least of the same size. This is where protocols like Sigfox can be questioned with regard to security.
  2. Secure systems often use key synchronization schemes, using a single key for the initial negotiation. These resynchronization schemes are often used for intrusions on the weakest link. The authenticity of the client must therefore be checked before the working key is sent.

Some guidelines

To conclude, here are a few rules to keep in mind to keep your system afloat:

  1. Transmit encrypted data only when necessary (if you need to send packets permanently, make sure they do not include sensitive data and use a different encryption)
  2. Use multiple encryption schemes to isolate the most sensitive information
  3. Ideally, use row-dependent encryption keys in databases to reduce the risk of massive intrusions
  4. Avoid predictable patterns in your raw encrypted data to confuse your attackers