View
214
Download
0
Category
Preview:
Citation preview
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
raul@dinosec.com
March 4, 2017
22017 © 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
32017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Secure Messaging & Private Communications
https://www.eff.org/secure-messaging-scorecard
42017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Alice & Bob
52017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
WhatsApp Evolution
62017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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/
72017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
82017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Who Is Behind This Protocol?
• Moxie Marlinspike and Trevor Perrin
• Open Whisper Systems (OWS)
https://whispersystems.org
2017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Crypto Introduction
102017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
112017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
122017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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)
132017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
142017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
2017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Crypto Properties
162017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Crypto Properties
• (Perfect) Forward Secrecy (PFS)
• Plausible deniability or plausibly deniable encryption
• Break-in recovery or future secrecy
Provided by the Signal protocol
172017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
(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
182017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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)
192017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
212017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
222017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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/
232017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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")
242017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
252017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Identity Keys (IK)
Identity key (long term)
Key directory
Public key Private key
This is a X3DH
message from
DinoSec J
262017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
TOFU: Trust On First Use
The initial key exchange to establish the encrypted session is vulnerable to MitM
272017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Identity Keys (IK)
• Identity Keys (IK) provide authentication (if properly verified)
– TOFU: Trust On First Use
• Identity Keys (IK) do not provide forward secrecy
282017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
One-Time Prekeys (OPK)
Identity key (long term)
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
Public key Private key
One-time prekeys
(200)…
Public key Private key
Public key Private key
Public key Private key
Server should delete the one-time (use) prekey immediately
upon providing it to a user
(forward secrecy)
292017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
One-Time Prekeys (OPK)
• 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)
302017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Signed Prekey (SPK) + Signature
Identity key (long term)
This is a X3DH
message from
DinoSec J
Next one-time prekey
(prekey ID)
Key directory
Public key Private key
One-time prekeys
(200)…
Public key Private key
Public key Private key
Public key Private key
Signed prekey
(mid term)
(30 days)
Public key Private key
Signature
Signature
Signature
X3DHexchange
312017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Signed Prekey (SPK) + Signature
• 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)
• Signed prekeys (SPK) using Bob's identity private key (IK),
change on a time basics, and avoid getting fake prekeys
322017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Signed Prekey (SPK) + Signature
• 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.
Public key Private key
Public key Private key
Signature
332017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
X3DH: Prekey Bundle
Identity key (long term)
Next one-time prekey
(prekey ID)
Key directory
Public key Private key
One-time prekeys
(200)
(short term)
…
Public key Private key
Public key Private key
Public key Private key
Signed prekey
(mid term)
(30 days)
Public key Private key
Signature
SignatureSignature
Public key Private keyIdentity key (long term)
Ephemeral key (EK)
Public key Private key
Prekeybundle
IK
Sig.
SPK
OPK
342017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
X3DH Key Agreement
Signature
Public key Private key
Public key Private key
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)
352017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
Public key Private key
Public key Private key
Signature
362017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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")
372017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
382017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
Associated Data (AD)
using AEAD
Initial Message
392017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Initial Message Post-X3DH
Signature
Public key Private key
Public key Private key
Prekey bundle
SKShared Secret
Key (32-byte)
Shared Secret
Ciphertext with
Associated Data (AD)
using AEAD
Initial Message
OPK prekey ID
Public key Private key
Public key Private key
Public key Private key
402017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
412017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
422017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
2017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Double Ratchet
442017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Double Ratchet "en español"
452017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
462017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Double Ratchet: Simplified Version
• Without using the Double Ratchet J
This is an encrypted
message from
DinoSec J
Shared SecretShared Secret
472017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
482017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
492017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
502017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
512017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
522017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
KDF Chains & KDF Keys
Alice: RK CK CK
Bob: RK CK CK
Three chains/user
RK: Rook Key
CK: Chain Key(s)
- Send
- Receive
532017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
How Do The Three Ratchets Work?
• Symmetric-key ratchet
• DH ratchet
• Signal protocol
• Double Ratchet
• X3DH
– Prekeys
• Double Ratchet
– Symmetric ratchet
– DH ratchet
542017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
552017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
562017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
572017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
582017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Symmetric-key Ratchet in Context (2/2)
592017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
protocol message from
DinoSec J
NEW
602017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
protocol message from
DinoSec J
Alice
Bob
1 step
NEW
NEW
612017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Bob sends a message to Alice
NEW
NEW
1 step
This is a Signal
protocol message from
DinoSec J
622017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Alice replies to Bob's message
NEW
1 step
1 step
This is a Signal
protocol message from
DinoSec J
632017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Bob Replies to Alice
This is a Signal
protocol message from
DinoSec J
1 step
NEW
1 step
642017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
This is a Signal
protocol message from
DinoSec J
1 step
NEW
1 step
652017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
DH Outputs ≈ (Used To Derive) Chain Keys (CK)
DH outputs are (used to derive) the sending and receiving chains
662017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Further DH Ratchet Steps
Parties take turns introducing new sending chains keys ("ping pong")
This is a Signal
protocol message from
DinoSec J
1 step
1 step
672017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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)
682017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
DH Ratchet + Root Chain within the Double Ratchet
This is a Signal
protocol message from
DinoSec J
1 step
1 step
1 step
1 step
NEW
Root Chain
Shared Secret X3DH
692017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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)
702017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Root Chain: Questions?
Shared Secret X3DH
712017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
722017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Sending and Receiving Chains: Questions?
732017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
742017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
X3DH + Double Ratchet Integration
• 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
752017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
Associated Data (AD)
using AEAD
Initial Message
OPK prekey ID
This is a Signal
protocol message from
DinoSec J
Initial Message
Shared Secret
762017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
X3DH + Double Ratchet Integration
• 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
772017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Double Ratchet in Action
We are only looking at Alice's Double Ratchet side (not Bob's)!
782017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Double Ratchet in Action (1/4)
• Alice initializes her Double Ratchet protocol (after X3DH)
• Alice sends her first message (A1)
1 step
1 step
792017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Double Ratchet in Action (2/4)
• Alice receives a response from Bob (B1)
1 step
1 step
802017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Double Ratchet in Action (3/4)
• 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
812017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Double Ratchet in Action (4/4)
• 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
822017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Double Ratchet in Full Action
Looking at both Alice's and Bob's Double Ratchets J
832017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
842017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
852017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
protocol message from
DinoSec J
PN=2, N=1
862017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
872017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
882017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Double Ratchet Crypto Algorithms (2/3)
• 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
892017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Double Ratchet Crypto Algorithms (3/3)
• 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
902017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
2017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Backdoor, Vulnerability, Bug or Feature?
922017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Backdoor, Vulnerability, Bug or Feature?
932017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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/
942017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
The WhatsApp Encryption Backdoor Vulnerability
Jan 13, 2017: Apr 2016 (9 m) - Tobias Boelter
952017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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"
962017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
WhatsApp vs. Signal Retransmissions
– 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
972017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
WhatsApp vs. Signal Retransmissions
982017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
2017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Conclusions
1002017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
Spanish Collection of Proverbs
"No dejes para
mañana lo que
puedas cifrar hoy…"
("doble carraquear")
1012017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
References
1022017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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)
1032017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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
1042017 © Dino Security S.L.
All rights reserved. Todos los derechos reservados.www.dinosec.com
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/
Recommended