How Do Ratchets Protect Your Data?

How Do Ratchets Protect Your Data?

Imagine if there was a company, and there was a staff common room, and it had a box with the keys to all the rooms in the building. Wouldn’t you worry that someone with some privilege would be able to get into all the rooms in the building, and then you wouldn’t be able to tell who had been in any of the rooms? Won’t you also worry that someone came in, and took a copy of a key, and could still get access to the rooms, and give it to others that they knew. Also, wouldn’t you worry that someone was able to get a master set of keys that all the other keys were derived from? Well, that’s what happens in many companies, where the electronic keys — encryption keys — are not protected properly.

Venafi recently surveyed over 500 CIOs outlines that one of the greatest holes in security in their organisations is related to encryption keys and digital certificates. They reported that around half of network attacks come in through SSL/TLS, and this figure is only likely to increase, with Dell estimating that 99% of all traffic on the Internet will be within the next five years. Thus firewalls will increasingly struggle to pick-up threats from traffic.

In summary, Venafi found that almost 90% thought that their company was against attack, as they cannot inspect the traffic, and around the same number said that they had suffered from an attack using encryption to hide the attack.

For Venafi, a significant finding is that 86% of CIOs think that stealing encryption keys and digital certifications will be a significant threat to their organisations, and 79% feel that innovation is being held back because of the trust issues with encryption keys.

We have generally built up security defences using network detection devices such as firewalls and IDSs, but these devices will not be able to detect malicious traffic, as they cannot inspect the traffic, and cannot spot malicious activity from stolen encryption keys. Some organisations change the passwords on their systems when a privileged user leaves the company, but very few would change all their encryption keys and digital certificates.

The cost of cryptography

Ponemon recently undertook some research into failures in control and trust, and surveyed over 2,400 companies from the Global 2000 in Australia, France, Germany, the UK and the US, and found that attacks on trust could lead to every organization losing up to:

$400 million

They identified that one of the major weaknesses in enterprise security is often the lack of management over encryption keys and certificates. This they report is down to them:

• Not knowing the number of keys and certificates they have. In fact, the majority (51%) don’t know how many are in use.
• Not knowing if they have strong enough hashing algorithms.
• Not knowing if their encryption is compliant with organisational policy.

This is alarming, especially as there is a move to Cloud-based systems, where a large-scale data breach can be caused by a single loss of an encryption key. Overall Ponemon found that Global 2000 companies had an average of 17,807 keys and certificates issued. They also reported that trust-based attacks would be hard to detect and would attack critical and that an attack on SSH services would allow other organisations to take direct control of their data and their Cloud-based processes.

Also, Ponemon found that 18% — nearly one-in-five — of companies survey thought that they expected to fall prey to a legacy cryptography attack over the next two years. And what about fixing easy problems? For they found that the expected cost of an easily preventable key management failure was $125 million. The easy win would be for them to establish control over their trust infrastructure, with 59% of the sample organisations saying that a refresh of key and certificate management would allow them to significantly reduce their security risks.

Things are not good on compromised Certificate Authorities (CAs) too, and where certificate impersonation is likely to expose each company to a cost of $73 million over two years.

So what is the cost of the trust attack? Ponemon reported on

• Incident response.
• Loss of productivity.
• Revenue cost.
• Brand and reputational damage.

In terms of the detail of breaches in the past 24 months, the reported levels were:

• 7% for man-in-the-middle (CA compromise).
• 3% for SSH key theft.
• 5% for server key theft.
• 18% for weak cryptography threat.

A figure of nearly one-in-five with a weak cryptography breach is fairly shocking!

Signal

With the rise in the threat of insiders and in the loss of long-term keys, Signal — developed by Open Whisper Systems — is increasingly seen as the tool of choice for many companies. With we get end-to-end encryption, and where there is no opportunity for a breach of a long-term key to comprise any of the previously encrypted communications.

The showcase their citizen-first approach with the tagline of:

Signal is made for you. As an Open Source project supported by grants and donations, Signal can put users first. There are no ads, no affiliate marketers, no creepy tracking. Just open technology for a fast, simple, and secure messaging experience. The way it should be.

Within Signal we see the implementation of a double ratchet system which is able to generate a new encryption key for every message, and where a breach of any of the keys does not promise the previously used ones.

An important concept in defending against a breach of the trust infrastructure is to implement key exchange methods (FS). With this a comprise of the long-term keys will not compromise any previous session keys. For example, if we send the public key of the server to the client, and then the client sends back a session key for the connection which is encrypted with the public key of the server, then the server will then decrypt this and determine the session. A leakage of the public key of the server would cause all the sessions which used this specific public key to be compromised. FS thus aims to overcome this by making sure that all the sessions keys could not be compromised, even though the long-term key was compromised. The problem with using the RSA method to pass keys is that a breach of the long keys would breach the keys previously used for secure communications.

Another important concept is where is key is ephemeral. With some key exchange methods, the same key will be generated if the same parameters are used on either side. This can cause problems as an intruder could guess the key, or even where the key was static and never changed. With ephemeral methods a different key is used for each connection, and, again, the leakage of any long-term would not cause all the associated session keys to be breached. The problem with the core Diffie-Hellman method is that the keys are not ephemeral, so we should avoid it in generating keys.

Double ratchet

Signal, though, builds forward secrecy into their systems with a double ratchet method, and where each key will not lead to a breach of the previous ones. The double ratchet concept was created by Trevor Perrin and Moxie Marlinspike. In hashing, this is implemented by taking a secret (“A”), and then adding a value of zero to it and then hashing this. The next hash is then our secret with a one added to it, and so on. A breach of one of the hashed values will not reveal the original secret, and it will not be possible to guess the next key.

Within the double ratchet method, we have an on-going renewal system and where the session keys are only ever short-lived. For this it uses the Elliptic Curve Diffie-Hellman (ECDH) key exchange method and a hashing method for deriving the keys — this gives it a “double” ratchet.

The two parties exchange encrypted messages based on a shared secret key. They create a new set of keys for every Double Ratchet message. Earlier keys cannot be calculated from the ones that follow. They also send Diffie-Hellman public values with their messages, and and the results of the Diffie-Hellman calculations are then mixed together into the derived keys. The protocol is useful for making sure that a hack on one set of keys does not lead to a hack on the rest of the keys. In will create two names (a and b), and then a will encrypt two and b will encrypt one message for a:

Name 1: Bob
Name 2: Alice

Bob  keys are:
Identity key (Public key):  VF3+Y8kuse3QdEfS5AQZMraGLqtGeZiQO4dUXlsChhw=
->Identity key (Private key):  0Tmru7NX865LG6YoJrB1g61R5LjRh75+O1bKEpnomF0=
Ratchet key (Public key):  KggeAtAR6G37t3//b5fFDfX3l82SRHhQi+lFCFnDEiE=
-> Ratchet key (Private key):  YMxWVOqxDTaU2nesi5Gc/jRLHtTER3aeu4l5X2HhY/Y=
Handshake Public key:   x5WM8YOwVePq3k6BJU1KJi+GJQNBMqK8MhIODVUsYkE=
->Handshake Private key:  so7vNSD1kWDPE+piEDtCBMH1lV6e04JLCTT8MTcY5X4=

Encrypted message1 a->b:  ZnVF/mvdDdfH0ypKKDbJzc/HjjVQp71w9RFSlyOdZmtWgOjjQqd+hP3MAacCV8z+j2J3v/J4UJYJI7COyjPjBzNzs5WkfJE1NMKj3qLUgRSmva8EimxhVSQ0LasS5wBEutFNGD8ETX3E8+exNyWGfxIsrxcgTMFGx2LRP4qdtZdACqdHRQ==

Encrypted message2 a->b:  5owlbrkh1rVvLXvCs91iDJT2lKOwAaXKQkTjpaeRqPc0rAsf4yEyRIBs+5Ib/bwz0cd0fvzVKbv1E6VAwVLWAWSMZdgXj8TGOEJM8FRnVNHDrO8E4x1dTE3BahB1JIuKOlHrNDW4OVPnL+2MCPuqOV1pJOvn9fmGPn0qguOX7WHUoektwwqxUXRonA==

Encrypted message3 b->a:  EBs0vllv1UQkUFKrCfL/KMdYv4T9oS65vKBNr1RKBmi/At20MSrfFNTUOCz3JJwVnM0JrYwDS5KNzNNKd/rXlDCsFIG/uwMYt5NJVs8L8y2o/UAEONowDsJRlCLCNpLZ3oOpnUdCNPGXXkGYcYfzCgsVR5MPKeGFjA1/dTrHOe3DmySaP+Xl0ftwgMe8

b decrypt:  The quick
b decrypt:  brown fox jumps
a decrypt:  over the lazy dog

A mechanical ratchet only moves forward for one step at a time. In cryptography, a ratchet method allows for future states to be calculated but only if you know an original seed value. It is not possible to calculate previous states from the current state. Typically this is done with a one-way-function such as a hash with a seed value and a salt.

For if we wanted to generate four ratchet values based a master key of “AlicePassword” (and using an HMAC hash, and were Alice will with an interactive hash of 0, 1, 2 and 3):

H0(AlicePassword)≡HMAC(AlicePassword,0x00)
H1(AlicePassword)≡HMAC(AlicePassword,0x01)
H2(AlicePassword)≡HMAC(AlicePassword,0x02)
H3(AlicePassword)≡HMAC(AlicePassword,0x03)

Each key is thus derived from the original seed. By observing H0(AlicePassword), it would not be possible to determine the next in the sequence (H1(AlicePassword)). As she sends messages, she creates an iterative hash for each one.

With the double racket method, Bob and Alice use their own outbound session — which is a ratchet and elliptic curve — to encrypt messages.

The ratchet can only go forwards (and not backwards) and derives a unique key for each message. Ed25519 elliptic curve signatures are then used to prove authenticity. The value of the ratchet and the Ed25519 public key are shared with the other parties in the conversation.

Initially, Alice and Bob each create three Elliptic Curve key pairs (Identity, Ratchet and Handshaking):

The keys will then be derived from these. If you want to see it in action, try here.

Conclusions

A basic message here … make sure you are using forward secrecy and that your key exchange methods are ephemeral … no excuses for large organisations. Methods such as Signal are increasingly replacing many of the communications systems which were based on secure email. The concept of secure email is really something that has never happened, and where we often just secure the transmission of the and have little in the way of security and authentication on the email client.

$400 million and a loss of customer trust, or a quick update on your key exchange methods? You choose …

So, here is MLS (Messaging Layer Security):