whatsapp e2e demystified - dinosec · 2 2017© dinosecurity s.l. allrightsreserved. todos los...

2017 © Dino Security S.L.

All rights reserved. Todos los derechos reservados.www.dinosec.com

WhatsApp End To End Encryption

Demystified

w w w . d i n o s e c . c o m@ d i n o s e c

Raúl SilesFounder & Senior Security Analyst

[email protected]

March 4, 2017



Outline

• Secure / Private messaging and WhatsApp

• Crypto introduction and properties

• Signal protocol

– X3DH and Prekeys

– Double Ratchet

• Backdoor, vulnerability, bug or feature?

• Conclusions

• References



Secure Messaging & Private Communications

https://www.eff.org/secure-messaging-scorecard



Alice & Bob



WhatsApp Evolution



WhatsApp E2E Encryption

• WhatsApp E2E encryption is based on the Signal protocol

• The app uses Noise Pipes (transport) to

communicate with WhatsApp servers

• WhatsApp servers can know messages exist

(even if content is unknown)

– To, From, When, etc.

• Registration process (SMS), contacts, etc.

• Verify the other party key

– View contact info - Encryption: Security code

https://www.whatsapp.com/security/



Signal Protocol

• Previously named Axolotl protocol

• WhatsApp: End-to-End (E2E) encryption

– Since March 31, 2016

• Other apps: TextSecure (Android), Signal (iOS/

Android), Facebook Messenger, Google Allo…

– Variants of Signal protocol (Double Ratchet): Wire (Proteus), Matrix (Olm), Pond, Conversations, ChatSecure, Cryptocat: OMEMO (XMPP)…

• Limit the damage of a compromise

• Minimize trust in the messaging infrastructure (servers)

Main features/protocols: X3DH, prekeys & Double Ratchet



Who Is Behind This Protocol?

• Moxie Marlinspike and Trevor Perrin

• Open Whisper Systems (OWS)

https://whispersystems.org



Crypto Introduction



Diffie-Hellman (DH)

• Or how to exchange a shared secret key (in a secure

way) over an insecure channel

• Discrete logarithm (or elliptic curve discrete logarithm)

• "#%&'( = *

• # = log∝ *%&'(

– (is a prime >≈ 1.024 bits

• Non-authenticated

– Vulnerable to MitM attacks

"Diffie-Hellman" (THOTH - Píldora 38): http://www.criptored.upm.es/thoth/

http://www.criptored.upm.es/thoth/material/texto/pildora038.pdf



Diffie-Hellman (DH) Exchange

Alice p, " Bob

0 1

"0%&'2 = 3"1%&'2 = 4

56%&'2 = "1 0%&'278%&'2 = "0 1%&'2

"10%&'2 = S = "01%&'2

Agreement: (mod p) p is a prime number

" is a primitive root mod p

SECRETS

Shared Secret



DH Nomenclature

• DH (Diffie-Hellman)

• DHE (DH Ephemeral)

• ECDHE (Elliptic Curve DHE)

– Key agreement protocol to exchange a shared secret key (in a secure way) over an insecure channel using key pairs (public &

secret/private)

– Both parties have a pair of (elliptic curve) keys

• Public and secret/private keys

– Reference ECDH functions: X25519 & X448

Long-term keys (static) vs. Ephemeral keys (temporary)



Elliptic Curve Diffie-Hellman (ECDH)

• Curve25519 function (Daniel J. Bernstein, 2005)

– Curve25519 (elliptic curve) or X25519 (DH exchange function)

– 32-byte public & secret/private keys and 32-byte shared secret

– Shared secret can be used to authenticate (hash of the shared

secret) & encrypt messages

– Very high speed function offering ≈128 bits of security

– 9(;<=), where p is the prime number 2255 − 19 and E is the

elliptic curve y2 = x3 + 486662x2 + x (using the base point x=9)

– Validate public keys off-line

• Vulnerable to MitM attacks



Elliptic Curve Diffie-Hellman (ECDH) Exchange

Alice 9 Bob

0 1

?@ABC25519 0, 9 = 3?@ABC25519(1, 9) = 4

?@ABC25519 0, 4 ?@ABC25519(1, 3)

?@ABC25519 0, ?@ABC25519(1, 9) = S = ?@ABC25519 1, ?@ABC25519(0, 9)

Agreement: (base point)9 is a public value

SECRET/PRIVATE KEYS

Shared Secret (32-byte)

PUBLIC KEYS



Crypto Properties



Crypto Properties

• (Perfect) Forward Secrecy (PFS)

• Plausible deniability or plausibly deniable encryption

• Break-in recovery or future secrecy

Provided by the Signal protocol



(Perfect) Forward Secrecy (PFS)

• "Property of secure communication protocols in which compromise of long-term keys does not compromise past session keys."

– "Encrypted communications and sessions recorded in the past cannot be retrieved and decrypted should long-term secret keys or passwords be

compromised in the future."

• (Perfect) Forward secrecy or security (PFS)

• Provided by SCIMP (Silent Circle Instant Messaging Protocol)

– Usage of ephemeral (temporary per-message) keys & KDF

• "Pre-Compromise Security"

https://en.wikipedia.org/wiki/Forward_secrecy

PAST FUTUREPRESENT

BREAK



Plausible Deniability or Cryptographic Deniability

• Parties can convincingly deny that a message is encrypted,

that it (or its associated plaintext) even exists or that it is

able to decrypt it

– A party can be absolutely sure a message was sent by the other

party (it was not forged by an adversary), but…

– A party can not prove to anyone else that a given message was

written by the other party

• Provided by OTR (Off-The-Record) vs. GPG/PGP

– Keys derived from (ephemeral) shared secrets & renewed

https://whispersystems.org/blog/simplifying-otr-deniability/

(digital signatures)



Break-in Recovery or Future Secrecy

• "Property of secure communication protocols in which compromise of current keys does not compromise future session keys."

– Current key material can not be used to calculate the key material for future subsequent messages (DH exchanges)

– Self-healing (Axolotls)

• Provided by OTR (Off-The-Record)

• Post-Compromise Security (PCS)

– https://eprint.iacr.org/2016/221

https://whispersystems.org/blog/advanced-ratcheting/

PAST FUTUREPRESENT

BREAK



X3DH



X3DH

• X3DH or "Extended Triple Diffie-Hellman"

• Key agreement protocol

– Parties mutually authenticate each other based on public keys

– Provides forward secrecy and cryptographic deniability

• Establishing long-term encrypted sessions between users

– Establish a shared session key or secret key (SK)

– Asynchronous sessions, when a party (Bob) can be offline but

has previously published / cached some info to a server

– The other party (Alice) wants to send an encrypted message to

Bob, and also share a secret key for future communications



Pre-generated or Pre-loaded Keys (Prekeys)

• Forward secrecy in asynchronous messaging scenarios

– Asynchronous messaging uses long-live sessions

– Initial key exchange for the first message

• Initialization of messaging sessions without the presence of the remote party (asynchronous communication)

– A key exchange is required to send a message

– A key exchange requires messages from both parties

• Sender has to wait for the recipient to respond… blocked!

– Pre-generate keys and submit (pre-load) them to the

messaging server: One-time prekeys (OPK)https://whispersystems.org/blog/asynchronous-security/



X3DH Pre-Requisites

• Stateful protocol: First message creates the session state

– Bob's "prekey bundle" can be considered as the 1st message

• Once the session has been established, the session key

must be renewed (forward secrecy) using a ratchet

• Key directory (e.g. WhatsApp servers)

• X3DH must define three parameters:

– Curve: X25519 (or Curve25519)

– Hash: SHA256 ("HmacSHA256")

– Info: string value identifying the app using X3DH ("WhisperText")



X3DH Phases

1. User registration and key publication

– Bob publishes his identity key and prekeys to a server

2. X3DH key exchange and initial message submission

– Alice fetches a “prekey bundle” for Bob from the server, and

uses it to calculate the shared session key or secret key, and

sends an initial message to Bob

3. Initial message reception

– Bob receives and processes Alice’s initial message, and uses it

to calculate the same shared session key or secret key



Identity Keys (IK)

Identity key (long term)

Key directory

Public key Private key

This is a X3DH

message from

DinoSec J



TOFU: Trust On First Use

The initial key exchange to establish the encrypted session is vulnerable to MitM



Identity Keys (IK)

• Identity Keys (IK) provide authentication (if properly verified)

– TOFU: Trust On First Use

• Identity Keys (IK) do not provide forward secrecy



One-Time Prekeys (OPK)


This is a X3DH

message from

DinoSec J

Next one-time prekey

(prekey ID)Bob can delete the associated

one-time (use) prekey pair

immediately upon receiving

and decrypting the message

(forward secrecy)

Key directory


One-time prekeys

(200)…




Server should delete the one-time (use) prekey immediately

upon providing it to a user

(forward secrecy)



One-Time Prekeys (OPK)



• One-time prekeys (OPK) provide strong forward secrecy

• Bob (+ server) might run out of one-time prekeys (OPK)

• The server can lie and provide a fake one-time prekey

(OPK) that does not belong to Bob (Bob cannot decrypt it)



Signed Prekey (SPK) + Signature


This is a X3DH

message from

DinoSec J


(prekey ID)

Key directory


One-time prekeys

(200)…




Signed prekey

(mid term)

(30 days)


Signature

Signature

Signature

X3DHexchange






• One-time prekeys (OPK) provide strong forward secrecy

• Bob (+ server) might run out of one-time prekeys (OPK)

• The server can lie and provide a fake one-time prekey

(OPK) that does not belong to Bob (Bob cannot decrypt it)

• Signed prekeys (SPK) using Bob's identity private key (IK),

change on a time basics, and avoid getting fake prekeys




• Prekey (SPK) signed with Identity Key (IK)

– SPK public key signed with IK private key

• XEdDSA signatures (with Curve25519)

– XEd25519

– 512 bits or 64 bytes (based on SHA-512)

• Signature = XEdDSA(IKB, Encode(SPKB))– Byte sequence: XedDSA signature of SPKB with IKB private key

• Encode(PK): Encoding function to encode an X25519 public key PK into a byte

sequence. It consists of some single-byte constant to represent the type of curve

(0x05), followed by little-endian encoding of the u-coordinate as specified in RFC 7748.



Signature



X3DH: Prekey Bundle



(prekey ID)

Key directory


One-time prekeys

(200)

(short term)

…




Signed prekey

(mid term)

(30 days)


Signature

SignatureSignature

Public key Private keyIdentity key (long term)

Ephemeral key (EK)


Prekeybundle

IK

Sig.

SPK

OPK



X3DH Key Agreement

Signature



Prekey bundle

Goal: Establish an (authenticated) shared session key or secret key (SK)

Forward secrecy

SKShared Secret

Key (32-byte)

To authenticate Alice (by Bob) To authenticate Bob (by Alice)

Partial forward secrecy + auth

(Perfect) forward secrecy

Shared Secret

Mutual authenticationForward secrecy

(Optional: X4DH)



X3DH Key Agreement: Details

• Alice verifies Bob's SPK using IK & signature

– XEdDSA

• Alice calculates the shared secret key (SK):

SK = HKDF(DH1 || DH2 || DH3 || DH4) =HKDF(ECDH1(IKA, SPKB) || ECDH2(EKA, IKB) || ECDH3(EKA, SPKB) || ECDH4(EKA, OPKBn))

• Once SK is obtained, the private key for EKA

and the four DH outputs are deleted by Alice

Signature

Shared Secret



Signature



Shared Secret Key (SK)

• SK = HKDF(DH1 || DH2 || DH3 || DH4) • HKDF = HMAC-based Key Derivation Function (for SK)

– Output: 32 bytes (SK)

– Input:

• Input key material:

–F || DH1 || DH2 || DH3 || DH4 (32 + '128' bytes)

–F is a byte sequence containing 32 0xFF bytes (X25519)

• Salt: A byte sequence containing 32 zeros (0x00 bytes)

• Info: The "info" parameter defined for X3DH ("WhisperText")



Initial Message Post-X3DH

• Alice must include her identity details in all messages

("initial message") addressed to Bob (until he replies), so

that he can build the associated encrypted session (X3DH)

– Identity Key (IKA)

– Ephemeral Key (EKA)

– OPK prekey ID, identifying the OPK used from Bob

– Initial ciphertext using AEAD (Authenticated Encryption with

Associated Data)

Ciphertext with

Associated Data (AD)

using AEAD

Initial Message



Initial Message Ciphertext

• Initial ciphertext using AEAD (Authenticated Encryption

with Associated Data)

– Content = AD (Associated Data)

• Byte sequence with the identity of both users

AD = Encode(IKA) || Encode(IKB) – Key = SK (or the output of some HKDF based on SK)

– This ciphertext is the first message within some post-X3DH

protocol (e.g. Double Ratchet) & Alice's X3DH initial message

Ciphertext with


using AEAD

Initial Message



Initial Message Post-X3DH

Signature



Prekey bundle

SKShared Secret

Key (32-byte)

Shared Secret

Ciphertext with


using AEAD

Initial Message

OPK prekey ID






Receiving the Initial Message

• Bob calculates the shared secret key (SK)

• Bob deletes the four DH outputs once SK is obtained

• Bob constructs the AD (Associated Data), as previously

– AD = Encode(IKA) || Encode(IKB) • Bob tries to decrypt the initial ciphertext using SK and AD

• Bob deletes the one-time prekey (OPK) used

Shared Secret

X3DH protocol completed!! J



X3DH: Questions?

• Parties may compare their identity public keys IKA and IKB through some authenticated channel

– Public key fingerprints, or QR code

• Forward secrecy

– Server never hands out the same prekey (OTP) twice

– Client should never accept the same prekey (OTP) twice

– Bob might run out of one-time prekeys (OPK)

• Bob must prepopulate his set of prekeys in the key directory (server) periodically, or the

server must request a new set when it is running out

• If OPK is not used, it is exposed to replay attacks (same message again)

• If OPK is not used, the same secret could be derived in different runs if the initial

message is replayed



X3DH: Questions?

• If the signature of the pre-signed key is omitted, a

malicious server could provide Alice a fake "prekey

bundle" and calculate SK simply by compromising IKB



Double Ratchet



Double Ratchet "en español"



Double Ratchet: Overview

• The Double Ratchet algorithm is used by two parties

(Alice & Bob) to exchange (send and receive) encrypted

messages based on a shared secret key (SK)• The shared secret key (SK) is obtained via an initial key

exchange using a key agreement protocol (e.g. X3DH)

• The Double Ratchet manages the ongoing renewal and

maintenance of short-lived session keys

• Combines a DH ratchet with a hash ratchet (Double Ratchet)

• Previously named Axolotl ratchet



Double Ratchet: Simplified Version

• Without using the Double Ratchet J

This is an encrypted

message from

DinoSec J

Shared SecretShared Secret



Ratchets

• DH ratchet

– Key renewal throughout a session using Diffie-Hellman

– Future secrecy

– Provided by OTR (Off-The-Record)

• https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html

• Symmetric (or KDF or hash or immediate) ratchet

– Key renewal using a Key Derivation Function (KDF) or hash

– Optimal forward secrecy

– Provided by SCIMP (Silent Circle Instant Messaging Protocol)

• https://cdn.netzpolitik.org/wp-upload/SCIMP-paper.pdf

One-way functions



The Best of Both Worlds: Double Ratchet

• OTR (synchronous protocol) provides plausible deniability (keys derived from ephemeral shared secrets and renewed), partial forward secrecy (ephemeral

keys) and future secrecy (Diffie-Hellman)

– OTR is complex (DSA signatures) and discloses old MAC keys

• SCIMP (synchronous protocol) provides excellent forward secrecy (ephemeral

keys and KDF)

– Keys for lost or out-of-order messages must remain around or block ratchet from progressing

• Signal (asynchronous protocol): Double Ratchet

PAST FUTUREPRESENT

PAST FUTUREPRESENT

BREAK

PAST FUTUREPRESENT

BREAK

BREAK



Double Ratchet Crypto Properties

• Both parties derive new keys for every Double Ratchet

message

– Earlier keys cannot be calculated from later ones (forward

secrecy)

• Both parties also send DH public values attached

to their messages

– DH calculations are mixed into the derived keys so that later

keys cannot be calculated from earlier ones (future secrecy)

• Protection to earlier or later encrypted messages in case

of a compromise of a party’s keys

This is a Signal

protocol message from

DinoSec J



KDF & KDF Chains

• Key Derivation Function (KDF) – Crypto function

(e.g. HMAC, HKDF, hash or one-way function)

– KDF key (32-byte) or salt (secret & random)

– Input data (32-byte)

– "info" parameter (HKDF)

– Output data (random, if KDF key unknown)

• PRF: Pseudo Random Function

• KDF chain

– Output: Output key + (next) KDF key

• 64-byte (32-byte + 32-byte)

1 step



KDF Chain Properties

• Resilience: Output keys appear random (if KDF key is

unknown)

– Even if Input is known or controlled by an adversary

• Forward secrecy: Past Output keys appear random if KDF key is learned at some point in time (in the future)

• Break-in recovery: Future Output keys appear random if

KDF key is learned at some point in time (now)

– Provided that future inputs have added sufficient entropy

– Future secrecy



KDF Chains & KDF Keys

Alice: RK CK CK

Bob: RK CK CK

Three chains/user

RK: Rook Key

CK: Chain Key(s)

- Send

- Receive



How Do The Three Ratchets Work?

• Symmetric-key ratchet

• DH ratchet

• Signal protocol

• Double Ratchet

• X3DH

– Prekeys

• Double Ratchet

– Symmetric ratchet

– DH ratchet



Symmetric-key Ratchet

• Every message sent or received is encrypted with a unique Message Key (MK)– MK can be deleted after encrypting/decrypting

the message … or ...

– MK can be stored for out-of-order messages

• Not blocking the ratchet from progressing

• Message keys are output keys from the sending and receiving KDF chains

• KDF keys for these chains are the

Chain Keys (CK)

• Input is constant (no future secrecy)…

1 step



Symetric-key Ratchet: Chain Keys "Weakness"

• If an attacker steals one party’s

sending and receiving Chain Keys

(CK), the attacker can compute all

future Message Keys (MK) and

decrypt all future messages

• Double Ratchet combines the

symmetric-key ratchet with a DH

ratchet to update Chain Keys (CK)

based on DH outputs



DH Ratchet: Introduction

• When Alice and Bob exchange messages, they also

exchange new DH public keys

• DH output secrets become the inputs to the root chain (RK)

• The output keys from the root chain become new KDF keys

for the sending and receiving chains (CK)

DH



Symmetric-key Ratchet in Context (1/2)

• The sending and receiving chains (CK) advance as each

message is exchanged (sent and received) and new DH

public keys are exchanged too

• Their output keys are used to encrypt and decrypt

messages

– E.g. A1



Symmetric-key Ratchet in Context (2/2)



DH Ratchet

• Each party generates a DH key pair (public & private keys)

– Current ratchet key pair

• Every message begins with a header

– It contains the sender’s current ratchet public key

• When the remote party receives a new ratchet public key…

– A DH ratchet step is performed

– It replaces the local party’s current

ratchet key pair with a new key pair1 step

This is a Signal


DinoSec J

NEW



DH Ratchet: Roles

• Parties take turns replacing ratchet key pairs

– "Ping Pong" advertising and generating new keys

– DH calculations between ratchet key pairs will generate a new

DH output

• Bob is the sender or initiator & Alice is the recipient

This is a Signal


DinoSec J

Alice

Bob

1 step

NEW

NEW



Bob sends a message to Alice

NEW

NEW

1 step

This is a Signal


DinoSec J



Alice replies to Bob's message

NEW

1 step

1 step

This is a Signal


DinoSec J



Bob Replies to Alice

This is a Signal


DinoSec J

1 step

NEW

1 step



This is a Signal


DinoSec J

1 step

NEW

1 step



DH Outputs ≈ (Used To Derive) Chain Keys (CK)

DH outputs are (used to derive) the sending and receiving chains



Further DH Ratchet Steps

Parties take turns introducing new sending chains keys ("ping pong")

This is a Signal


DinoSec J

1 step

1 step



DH Ratchet within the Double Ratchet

• Previous model was a simplification…

• The Chain Keys (CK) are not directly obtained from the

DH outputs, but from the Root Chain

• The DH outputs are used as the KDF inputs of the Root

Chain

• The KDF outputs of the Root Chain are used as the

sending and receiving Chain Keys (CK)



DH Ratchet + Root Chain within the Double Ratchet

This is a Signal


DinoSec J

1 step

1 step

1 step

1 step

NEW

Root Chain

Shared Secret X3DH



Root Chain: Questions?

• Using a Root Chain provides resilience (KDF) and future

secrecy (DH ratchet key renewal)

• This model allows every party to create and use a new

DH ephemeral key (2nd DH ratchet step) immediately

without first advertising it and waiting for ACK (like OTR)

– This new DH key will be used with the next message sent

• The fact that the Root Key (RK) is mixed in the derivation

of the ephemeral keys (KDF), allows to chain back the

trust in the ephemerals to the initial handshake (X3DH)



Root Chain: Questions?

Shared Secret X3DH



Sending and Receiving Chains: Questions?

• Message Keys (MK) are derived from Chain Keys (CK),

rather than hash iterating them directly (like SCIMP)

• Using Sending and Receiving Chains solve the "delayed

message problem"

– If a message is delayed (or out-of-order), its keys (MK) can be immediately derived and cached without holding back (or

blocking) the Chain Key (CK) from ratcheting forward

– The cached message keys (MK) are not used to derive any

subsequent message keys (MK), maintaining forward secrecy



Sending and Receiving Chains: Questions?



X3DH + Double Ratchet Integration

• (Assumption) Alice begins sending messages first(Bob doesn’t send messages until he has received one

of Alice’s messages)

– Alice starts the X3DH protocol and

retrieves Bob's "prekey bundle" from server (including the SPKB)

– Alice constructs or derives the shared secret key (SK)

• Alice's X3DH initial message is

prepended to the first (Alice's)

Double Ratchet message

– Until she receives Bob's responseDouble Ratchet initialization




• SK is the initial RK

– (Both) Alice (and Bob) initialize(s) her Root

Chain

• Bob's SPKB becomes Bob's initial

ratchet public key

– Assume Bob's "prekey bundle" is like the

first message from Bob to Alice for Double

Ratchet

– Already received by Alice (X3DH)

– Alice initializes her Sending Chain, after

one DH ratchet step, and is ready to send

the 1st message (A1)

• The AD (Associated Data) from X3DH

is the same AD for Double Ratchet

1 step



First Double Ratchet Message (+ X3DH)

• Alice includes her current (just created) public DH ratchet key on her first Double Ratchet message

– So that Bob can initialize his Receiving Chain and his (next) Sending Chain (using the Root Chain too)

• Together with her X3DH initial message

– So that Bob can construct the shared secret key (SK), and initialize his Root Chain

Ciphertext with


using AEAD

Initial Message

OPK prekey ID

This is a Signal


DinoSec J

Initial Message

Shared Secret




• Alice is waiting to receive Bob'sreponse (B1), including his new

public DH ratchet key…

• To be able to run another DH

ratchet step in order to initialize

her Receiving Chain

– Required to process the response

submitted by Bob (B1)1 step

1 step



Double Ratchet in Action

We are only looking at Alice's Double Ratchet side (not Bob's)!



Double Ratchet in Action (1/4)

• Alice initializes her Double Ratchet protocol (after X3DH)

• Alice sends her first message (A1)

1 step

1 step




• Alice receives a response from Bob (B1)

1 step

1 step




• Alice sends her second message (A2)

and, before receiving

it, Bob sends her

second message too

(B2)

– Using Bob's "old"

public DH ratchet key

• Then, Alice sends

messages A3 and A4




• Bob sends messages B3 and B4

– Using Bob's "new" public DH ratchet key

• Then, Alice sends message A5

– Using Alice's "new" public DH ratchet key too

1 step

1 step



Double Ratchet in Full Action

Looking at both Alice's and Bob's Double Ratchets J



Lost or Out-of-Order Messages (1/2)

• Double Ratchet includes in each message header

– The message’s number in the Sending Chain (N = 0,1,2,…)

– The length (number of message keys) in the previous Sending Chain (PN)

• Recipient can advance to the relevant message key

– Storing skipped message keys (for later) from the Receiving Chain

• When a new message is received…

– If a DH ratchet step is triggered:

• Number of skipped messages = Received PN - length of the current Receiving Chain

• N is the number of skipped messages in the new (current) Receiving Chain

– If a DH ratchet step is not triggered:

• Number of skipped messages = Received N - length of the current Receiving Chain



Lost or Out-of-Order Messages (2/2)

• Alice receives B1 and then B4 (B2 & B3 are skipped)

– B4 triggers a DH ratchet step

• B4 message header

– N = 1

– PN = 2 (length)

• How many messages were skipped?

– DH ratchet step triggered:

– N = 1 (message number in the

new/current Receiving Chain:

0, 1 …)

– Skipped = 2 (PN) – 0 (current

Receiving Chain length) = 2

1 step N=1,PN=2,

PN=2

(0,1…)N=1



Double Ratchet Message Header & Contents

• Each Double Ratchet message header includes…

– Sender current public DH ratchet key

– Message’s number in the Sending Chain (N = 0,1,2,…)

– The length of the previous Sending Chain (PN)

• Each Double Ratchet message is encrypted using…

– AEAD (Authenticated Encryption with Associated Data)

• Message plaintext + message key (MK) + AEAD nonce (various options)

• Associated Data (AD) used for authentication (not encrypted)

– AD = Byte sequence ('ad') plus message header

This is a Signal


DinoSec J

PN=2, N=1



Double Ratchet Key Material Renewal

• As soon as a new common secret is established, a new symmetric sending ratchet gets initialized (to be able to start sending messages)

• Parties renew session key material continuously…

• In interaction with the remote party using a DH ratchet

– If possible: Every time a new message (with a new public DH ratchet key) is received

– When messages are exchanged between both parties (two-way message)

• Independently by using a symmetric (or hash) ratchet

• With every received message a party advances one step of the receiving symmetric ratchet

– And advances the DH ratchet whenever a new DH value from the remote party arrives

• With every sent message a party advances one step of the sending

symmetric ratchet

– And (tries) to provide the remote party with a new public DH key value



Double Ratchet Crypto Algorithms (1/3)

• DH ratchet: X25519 (32-byte shared secret)

– DH key pairs: Curve25519 (public & private 32-byte keys)

• Symmetric (or hash) ratchets:

– Root Chain ratchet:

• KDF = HKDF with SHA-256

– Key/salt=RK (32-byte)

– In=DH output (32-byte)

– Info="WhisperRatchet"

– Output=RK+CK (32+32, 64-byte)

1 step




• Symmetric (or hash) ratchets:

– Send and Receive Chain ratchets:

• Next CK: HMAC with SHA-256 (no KDF)

– HMAC(CK, "0x02") (32-byte)

• Next MK: KDF = HKDF with SHA-256

– Key/salt=["0x00"] (32-byte)

– In=HMAC(CK, "0x01") (32-byte)

– Info="WhisperMessageKeys"

– Output=eK+aK+IV (80-byte) (named "MK")

» eK = Encryption key (for AES) (32-byte)

» aK = Authentication key (for MAC) (32-byte)

» IV = Initialization vector (for AES) (16-byte)

Symmetric ratchet:Simplified version

1 step

MK

1 step CK




• Message encryption/decryption (symmetric):

– AES/CBC + PKCS#7 padding (or AES/CTR no padding)

• ciphertext = AES/CBC(eK, IV, plaintext)

– message = header(public DH ratchet key + N + PN) + ciphertext

• MAC (authentication): HMAC with SHA-256 (32-byte)

– HMAC(aK, AD + "protocol version (0x03) + message") (32-byte)

• (AEAD) Associated Data (AD) = IKA + IKB

– MAC (first 8 bytes of SHA-256)

• Final message = protocol version (0x03) + message + MAC



Double Ratchet: Questions?

• How is the first message from Bob protected?

– He needs to receive Alice's first message to construct the

shared secret key (SK)… or invert roles J

• What if Alice or Bob send various messages in a row

without receiving a message from the other party?

– Their DH ratchet won't step forward, and they will keep using

their current public DH ratchet key

– Their symmetric ratchet for the Sending Chain will step forward

with each message sent



Backdoor, Vulnerability, Bug or Feature?



Authenticating Public Keys…

• E2E encryption can go unnoticed by users (transparent)

• DH & ECDH are vulnerable to MitM attacks

• Validate public keys off-line

– Requires the users' intervention

– Verify key's fingerprints & bind them to users

• WhatsApp "Verify security code" screen

– Compare a 60-digit number or scan a QR code

• 60 digits (12x5)

https://whispersystems.org/blog/safety-number-updates/



The WhatsApp Encryption Backdoor Vulnerability

Jan 13, 2017: Apr 2016 (9 m) - Tobias Boelter



WhatsApp Retransmission Vulnerability

• Alice sends a message to Bob, but he is offline

– Message is not delivered (�) vs. (��)

– Messages, voice calls and file transfers

• If Bob's key changes before coming back online…

– He replaces his mobile phone and/or reinstalls the app

• Alice (WhatsApp app) will automatically retransmit the pending messages re-encrypting them with the new key

– New Bob's key or someone else key (MitM, "malicious" server, etc.)

• Afterwards (too late), Alice might get a notification about the

change in Bob's key

– If she enabled "Show security notifications"



WhatsApp vs. Signal Retransmissions

• WhatsApp

– Security code change notifications: "non-blocking"

• No settings option to change this behavior (opt-in to blocking behavior)

– "Show security notifications" disabled by default

• Signal

– Security code change notifications: "blocking"

• Require the user to manually verify the new key before continuing

– "Safety Numbers Approval" (when they change)

– Advisory mode (non-blocking) will be enabled by default for new installs of Signal L

– Safety numbers change notifications enabled by default

Security tradeoffs



WhatsApp vs. Signal Retransmissions



Desirable Software Properties

• Optimal approach?

– Security vs. Usability vs. "Customizability"

• Open source software

• Reproducible builds

• Software complexity?

• Provide users with multiple security options

• Defaults (opt-in vs. opt-out)

https://whispersystems.org/blog/reproducible-android/https://github.com/WhisperSystems/Signal-Android/wiki/Reproducible-Builds



Conclusions



Spanish Collection of Proverbs

"No dejes para

mañana lo que

puedas cifrar hoy…"

("doble carraquear")



References



References (1/3)

• "WhatsApp Encryption Overview". WhatsApp. Apr 2016.

https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf. https://www.whatsapp.com/security/

• "End-to-end encryption". WhatsApp Blog. Jan & Brian. April 5, 2016.

https://blog.whatsapp.com/10000618/end-to-end-encryption?l=en

• Curve25519. Daniel J. Bernstein. Feb 2006 (Nov 2005). https://cr.yp.to/ecdh.html. https://cr.yp.to/ecdh/curve25519-20060209.pdf. https://www.ietf.org/rfc/rfc7748.txt

• "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)". IETF. RFC 5869. H. Krawczyk

and P. Eronen. May 2010. http://www.ietf.org/rfc/rfc5869.txt

• "The XEdDSA and VXEdDSA Signature Schemes". OWS. Revision 1, 2016-10-20. Trevor Perrin(editor). Oct 2016. https://whispersystems.org/docs/specifications/xeddsa/ (xeddsa.pdf)

• "The X3DH (or "Extended Triple Diffie-Hellman") Key Agreement Protocol". OWS. Revision 1, 2016-

11-04. Moxie Marlinspike, Trevor Perrin (editor). Nov 2016. https://whispersystems.org/docs/specifications/x3dh/ (x3dh.pdf)

• "The Double Ratchet Algorithm". OWS. Revision 1, 2016-11-20. Moxie Marlinspike, Trevor Perrin

(editor). Nov 2016. https://whispersystems.org/docs/specifications/doubleratchet/ (doubleratchet.pdf)



References (2/3)

• "A Formal Security Analysis of the Signal Messaging Protocol". Cryptology ePrint Archive: Report2016/1013. Katriel Cohn-Gordon et.al. Oct 2016. URL: https://eprint.iacr.org/2016/1013 & URL:

https://eprint.iacr.org/2016/1013.pdf

• "How Secure is TextSecure?". Cryptology ePrint Archive: Report 2014/904. Tilman Frosch et.al.

Oct 2014. URL: https://eprint.iacr.org/2014/904.pdf

• "Simplifying OTR deniability". Moxie Marlinspike. Jul 2013.

https://whispersystems.org/blog/simplifying-otr-deniability/

• "Forward Secrecy for Asynchronous Messages". Moxie Marlinspike. Aug 2013.

https://whispersystems.org/blog/asynchronous-security/

• "Advanced cryptographic ratcheting". Moxie Marlinspike. Nov 2013. https://whispersystems.org/blog/advanced-ratcheting/

• "NorthSec 2015 - Trevor Perrin - TextSecure Protocol: Present and Future". Trevor Perrin. Jun 2015.

https://www.youtube.com/watch?v=7WnwSovjYMs

• "Man-in-the-middle attack on TextSecure". David Wind. Nov 2015. https://www.youtube.com/watch?v=bSap-VI4oh8

• "The Noise Protocol Framework" (revisión 31). Trevor Perrin. Oct 2016.

http://noiseprotocol.org/noise.html. https://noiseprotocol.org/docs/noise_stanford_seminar_2016.pdf



References (3/3)

• "WhatsApp backdoor vulnerability allows snooping on encrypted messages". The Guardian. Jan 13, 2017. https://www.theguardian.com/technology/2017/jan/13/whatsapp-backdoor-allows-snooping-on-

encrypted-messages

• "Should I be worried about the WhatsApp encryption backdoor vulnerability?". The Guardian. Jan 13,

2017. https://www.theguardian.com/technology/2017/jan/13/whatsapp-encryption-backdoor-snooping-signal

• "There is no WhatsApp 'backdoor'". OWS. Jan 13, 2017. https://whispersystems.org/blog/there-is-no-

whatsapp-backdoor/

• "In Response to Guardian’s Irresponsible Reporting on WhatsApp: A Plea for Responsible and

Contextualized Reporting on User Security". http://technosociology.org/?page_id=1687

• "WhatsApp Retransmission Vulnerability". Tobias Boelter. Apr 16, 2016.

https://tobi.rocks/2016/04/whats-app-retransmission-vulnerability/– https://tobi.rocks/pdf/whatsappslides.pdf

– https://www.youtube.com/watch?v=we-pJE5JjAs

– "WhatsApp vulnerability: Bug or Backdoor?". https://tobi.rocks/2017/01/whatsapp-vulnerability-bug-or-backdoor/

– "What is Facebook going to do? A suggestion.". https://tobi.rocks/2017/01/what-is-facebook-going-to-do-a-suggestion/

– "A response to the denials from moxie and WhatsApp". https://tobi.rocks/2017/01/there-is-a-whatsapp-backdoor/

– "Feelings". https://tobi.rocks/2017/01/feelings/

w w w. d i n o s e c . c o m@ d i n o s e c

R a ú l S i l e sr a u l @ d i n o s e c . c o m



Questions?

w w w. d i n o s e c . c o m@ d i n o s e c

whatsapp e2e demystified - dinosec · 2 2017© dinosecurity s.l. allrightsreserved. todos los...

Documents