The Snowden Phone

The Snowden Phone

There’s a lot of debate around E2E (end-to-end) encryption just now, and in the rights of law enforcement to be able to detect threats. One of the best papers around which has analysed the implementation of security within mobile phones is [here]:

Within the paper, the authors outline the most popular end-to-end encryption messaging systems including Signal, WhatsApp, Wire, Viber, Riot and Telegram. In their conclusion, they find that they all have strengths and weaknesses with respect to security, privacy and usability.

The key recommendations for end-to-encryption messaging vendors are:

So let’s dip into Signal, and see how it manages to preserve privacy.

Signal is best in breed?

We increasingly see business people using the Signal App, as they don’t trust email to communicate their IP (Intellectual Property)/patents/etc. At its core, the Signal App uses the Signal Protocol. It uses Curve25519 to negotiate keys and then uses 256-bit AES keys for the core encryption. Along with this, it has forward secrecy, which means that a breach of any of the keys will not breach any of the other keys used in the past. It is expected that a major trust provider on the Internet will be breached for its private key in the next year or so, so having protection for all previous keys is a good thing.

As a further contribution, it uses the multicast encryption method to distribute messages over defined groups. The Signal Protocol has been so successful that it is now integrated into WhatsApp and Facebook Messenger for end-to-end encryption, but these do not use it by default, and only the Signal App gives end-to-end encryption by default.

Each party has a long-term public/private key pair, and this is used to provide the identity key for the entities and then uses Curve25519 to negotiate the keys. The keys are then chained by making them dependent on previous message exchanges, which provides a ratcheting mechanism. This makes it almost impossible to guess the key requires for the session.

Signal servers

The Signal servers are operated by Open Whisper Systems. These servers create a large-scale trust network where they discover contacts from users already registered and pass on their public keys. This overcomes many of the weaknesses of the PKI infrastructure, where only a few trusted entities are trusted in creating public keys. But what happens when a major trust provider, such as Verisign, is hacked? This would breach large parts of the Internet. Within Signal, we create a large-scale trust network, based on real users and their contacts. The voice and video calls are also peer-to-peer communications between trusted users but will be routed through their servers if one of the users is not registered, which will thus hide the source IP address.

The Signal servers store user phone numbers and public keys, and checks the contacts that the user has by taking a SHA-256 hash of registered users, and when a match is found, it sends these back to the client. After this, the server removes the hashed values gathered.

While WhatsApp stores metadata on its servers, Signal does not store any metadata contained within messages. In fact the only thing that Signal stores about the user is the last time they connected to the server, and this information is only defined for a specific date (and not the time accessed).

But while WhatsApp has billions of users (and growing every day), Signal has a much smaller base, but it’s growing as companies see it as a great way to secure internal communications, and also with trusted external entities. It must be remembered too that WhatsApp is owned by Facebook, and everyone knows the basic business model of Facebook.

Signal

With the rise in the threat of insiders and in the loss of long-term keys, Signal 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 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):		tkUbaj1VwEIwi0kYRlWbl+0Don8WSgKOfbvij6+RT3c=
->Identity key (Private key):		hIHdPPYfiF5eEoqXhAIOq1H5qy2VIJToadn1azjk96Q=
Ratchet key (Public key):		7P3yOKPcAX5rVnQkQCmmGfQdo0mi4GL33Yy7DpFMbU0=
-> Ratchet key (Private key):		QYHS9FrJQ59VRDVqdwsDDVEbaaPp3myA+vUl3MTdC2Y=
Handshake Public key:			a/xifzSbU5wSwF8CFh+xP2ybY7jG/gKoY7dW0DTOHhA=
->Handshake Private key:		lSvv3TRFq7xuHxeTjQDqXQc2+UOALDDNJmRXnoDCUBA=

Encrypted message1 a->b:  2cuNbhbPkpcIck3j+9m76bUIr4X2cJdZSOARpGTzKPV3cs1NUrytT+CiNkgXVtJ2KEOzChxOeqLYoBjP11WW/UsSnkhFUkFH2So2iEXutBDHzlYExvQ9MCVkRkH6FaCnvpyPFvW5B6R+YUIok5CuZr0G9hI1Zqgcb0CRnZh0Nm4otP3f3A==

Encrypted message2 a->b:  efj2axgAmcBuyjkDzKARlaNzu5MzWqqqd0T9OZH/hW5Oy5JCQH1PN3/fYHu3lwU3N1gthhnGzHtJhlmq06pzXRcTJrhN5xlvsxAl+1K6t08QnD8Ev8myq1Ou719YySagwYRPBvZVo36GmFvN+qM05//weZtTFeL1fR2FZ1FMyjRR2+WiYjFzuE1AOw==

Encrypted message3 b->a:  H1gex6vZi0KTPywWK9XzVKmGiP2515XgYrM1Gx+kwq6JY8cQSLIKSHOjexqJhOR8MoGQs9IVX3aKbZkPRcKknsczl/jAdTav9ooFUe5c0XmJFWQEqwRkPgdpxFdbNmbMm7CwBne/6pyb7OfHEmzLUY+MYNLpF3dDwN6SOJFQTjzYe5eVaflBTrJn55TD

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 on 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

Email is finished! It cannot be trusted, and the future is increasingly looking bright for Signal, but not so for governments, who will struggle to justify why we shouldn’t use it. Within a GDPR world, businesses need to look towards Signal as the correct way to pass sensitive information.

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.

PS: But … What’s App was acquired by Facebook, and what’s to stop Facebook from breaking the secure protocol? And what’s to stop someone from acquiring Signal?