Whatsapp E2E Encryption Roo

Raúl Siles Founder & Senior Security Analyst [email protected] www.dinosec.com @ dinosec March 4, 2017 WhatsApp End To End Encryption Demystified

2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com Outline • Secure / Private messaging and WhatsApp • Crypto introduction and properties • Signal protocol – X3DH and Prekeys – Double Ratchet • Backdoor, vulnerability, bug or feature? • Conclusions • References

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

2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 5 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/

• 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

• Moxie Marlinspike and Trevor Perrin • Open Whisper Systems (OWS)

https://whispersystems.org

• 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

Alice p, " Bob Agreement: (mod p) p is a prime number " is a primitive root mod p 0 SECRETS 1 "0 %&' 2 = 3 "1 %&' 2 = 4

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

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

Shared Secret

• 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)

• 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 255 – 9(;<=), where p is the prime number 2 − 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

Alice 9 Bob Agreement: (base point) 9 is a public value

0 SECRET/PRIVATE KEYS 1 ?@ABC25519 0, 9 = 3 PUBLIC ?@ABC25519(1, 9) = 4 KEYS

?@ABC25519 0, 4 ?@ABC25519(1, 3) ?@ABC25519 0, ?@ABC25519(1, 9) = S = ?@ABC25519 1, ?@ABC25519(0, 9) Shared Secret (32-byte)

• (Perfect) Forward Secrecy (PFS) • Plausible deniability or plausibly deniable encryption • Break-in recovery or future secrecy

Provided by the Signal protocol

2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 16 (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" BREAK

PAST PRESENT FUTURE

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

• 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 (digital signatures) • Provided by OTR (Off-The-Record) vs. GPG/PGP – Keys derived from (ephemeral) shared secrets & renewed https://whispersystems.org/blog/simplifying-otr-deniability/

2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 18 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

BREAK

PAST PRESENT FUTURE

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

• 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

2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 21 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/

• 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")

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

Key directory

Identity key Public key Private key (long term)

This is a X3DH message from DinoSec J

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

• Identity Keys (IK) provide authentication (if properly verified) – TOFU: Trust On First Use • Identity Keys (IK) do not provide forward secrecy

Key directory

Identity key Public key Private key (long term)

Public key Private key One-time Public key Private key prekeys … Next one- (200) time prekey Public key Private key (prekey ID)

This is a X3DH Bob can delete the associated message from DinoSec J Server should delete the one- one-time (use) prekey pair time (use) prekey immediately immediately upon receiving upon providing it to a user and decrypting the message (forward secrecy) (forward secrecy)

• Identity Keys (IK) provide authentication (if properly verified) • Identity Keys (IK) do not provide forward secrecy • 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)

Key directory

Identity key Public key Private key (long term)

Signature Signature

Signature Signed Public key Private key prekey (mid term) (30 days) Public key Private key One-time Public key Private key prekeys … Next one- (200) X3DH time prekey Public key Private key exchange (prekey ID)

This is a X3DH message from DinoSec J

• Prekey (SPK) signed with Identity Key (IK) Public key Private key

– SPK public key signed with IK private key Signature

• XEdDSA signatures (with Curve25519) Public key Private key – 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.

Key directory

Identity key Identity key (long term) Public key Private key Public key Private key (long term)

Ephemeral Public key Private key Signature key (EK) Signed Public key Private key prekey (mid term) (30 days) IK

Sig. Signature Signature Public key Private key SPK One-time Public key Private key OPK prekeys … Next one- (200) Prekey time prekey Public key Private key (short term) bundle (prekey ID)

Mutual authentication Forward secrecy Public key Private key

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

Public key Private key Signature

Forward secrecy Partial forward secrecy + auth

(Perfect) forward secrecy SK (Optional: X4DH) Shared Secret Shared Secret Prekey bundle Key (32-byte) Goal: Establish an (authenticated) shared session key or secret key (SK)

• Alice verifies Bob's SPK using IK & signature Public key Private key

Signature – XEdDSA Signature

• Alice calculates the shared secret key (SK): Public key Private key Shared Secret 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

• 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")

2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 36 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)

Initial Message

Ciphertext with Associated Data (AD) using AEAD

• 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

Initial Message

Ciphertext with Associated Data (AD) using AEAD

Public key Private key Public key Private key

Signature

Public key Private key Public key Private key

Shared Secret SK Public key Private key

Shared Secret Prekey bundle Initial Message Key (32-byte)

Ciphertext with Associated Data (AD) using AEAD OPK prekey ID

• Bob calculates the shared secret key (SK) Shared Secret • 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

X3DH protocol completed!! J

• 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

• 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

• 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

• Without using the Double Ratchet J

Shared Secret Shared Secret

This is an encrypted message from DinoSec J

2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 46 Ratchets • DH ratchet – Key renewal throughout a session using Diffie-Hellman – Future secrecy One-way functions – 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

• 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

BREAK PAST PRESENT FUTURE • 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

PAST PRESENT BREAK FUTURE • Signal (asynchronous protocol): Double Ratchet BREAK PAST PRESENT FUTURE

• 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 This is a Signal protocol message from to their messages DinoSec J – 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

• 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) 1 step • PRF: Pseudo Random Function • KDF chain – Output: Output key + (next) KDF key • 64-byte (32-byte + 32-byte)

• 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

Alice: RK CK CK Three chains/user RK: Rook Key CK: Chain Key(s) Bob: RK CK CK - Send - Receive

• Symmetric-key ratchet • Double Ratchet • DH ratchet

• X3DH – Prekeys • Signal protocol • Double Ratchet – Symmetric ratchet – DH 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 1 step • KDF keys for these chains are the Chain Keys (CK) • Input is constant (no future secrecy)…

• 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

• 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)

• 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

• Each party generates a DH key pair (public & private keys) – Current ratchet key pair • Every message begins with a header

This is a Signal protocol message from – It contains the sender’s current ratchet public key DinoSec J • 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 pair 1 step

NEW

NEW This is a Signal protocol message from DinoSec J Bob

1 step

NEW Alice • 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

NEW This is a Signal protocol message from DinoSec J

1 step

NEW

1 step

This is a Signal protocol message from DinoSec J 1 step

NEW

1 step

This is a Signal protocol message from DinoSec J

1 step

NEW

This is a Signal protocol message from DinoSec J 1 step

NEW

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

1 step

This is a Signal protocol message from DinoSec J

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

• 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)

Root Chain

Shared Secret X3DH

1 step 1 step

This is a Signal protocol message from DinoSec J

1 step 1 step

NEW

• 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)

Shared Secret X3DH

• 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

• (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 Double Ratchet initialization – Until she receives Bob's response

• 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) 1 step – 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

2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 74 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) Initial Message • Together with her X3DH initial message – So that Bob can construct the shared secret key (SK),

and initialize his Root Chain Shared Secret

This is a Signal protocol message from DinoSec J

Initial Message

Ciphertext with Associated Data (AD) using AEAD OPK prekey ID

• Alice is waiting to receive Bob's reponse (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 1 step submitted by Bob (B1)

1 step

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

• Alice initializes her Double Ratchet protocol (after X3DH)

1 step • Alice sends her first message (A1)

1 step

• Alice receives a response from Bob (B1)

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

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

• 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

• Alice receives B1 and then B4 (B2 & B3 are skipped) PN=2 – B4 triggers a DH ratchet step • B4 message header – N = 1 – PN = 2 (length) • How many messages were skipped? – DH ratchet step triggered: 1 step N=1, – N = 1 (message number in the PN=2, new/current Receiving Chain: (0,1…) 0, 1 …) N=1 – Skipped = 2 (PN) – 0 (current Receiving Chain length) = 2

• 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

PN=2, N=1

This is a Signal protocol message from DinoSec J

• 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

• 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 1 step – Key/salt=RK (32-byte) – In=DH output (32-byte) – Info="WhisperRatchet" – Output=RK+CK (32+32, 64-byte)

Symmetric ratchet: • Symmetric (or hash) ratchets: Simplified version – Send and Receive Chain ratchets: • Next CK: HMAC with SHA-256 (no KDF) – HMAC(CK, "0x02") (32-byte) 1 step MK • Next MK: KDF = HKDF with SHA-256 1 step CK – 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)

• 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

• 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

• 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/

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

2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 94 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"

2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 95 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

• 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

("doble carraquear")

• "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)

• "A Formal Security Analysis of the Signal Messaging Protocol". Cryptology ePrint Archive: Report 2016/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

• "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/

Raúl Siles [email protected] Questions?

www.dinosec.com @dinosec