CMYK / .eps Facebook “f ” Logo CMYK / .

eps

Messenger Secret Conversations

Technical Whitepaper

Version 2.0
May 18, 2017
Version History:
2.0 — May 18, 2017
1.0 — Jul 8, 2016

©2017 Facebook, Inc. All rights reserved

 messenger secret conversations technical whitepaper 3

Contents

Introduction 4

Transport Protocol Overview 5

Abuse Reporting 11

Message Storage 13

Conclusion 15
 messenger secret conversations technical whitepaper 4

Introduction

In this document we provide a brief technical overview of Secret

Conversations — a specialized conversation mode within Face-
book Messenger. Secret Conversations provides end-to-end
encryption for messages using keys that are only available on users’
devices.
Secret Conversations is a distinct conversation mode inside
Facebook Messenger. Individual secret conversations are displayed
as separate threads in Messenger and share many UX elements with
regular Messenger conversations. However, Secret Conversa-
tions uses a different transport protocol, specialised on-device stor-
age and separate back-end infrastructure.
The Secret Conversations threat model considers the com-
promise of server and networking infrastructure used by Messenger
— Facebook’s included. Attempts to obtain message plaintext or fal-
sify messages by Facebook or network providers result in explicit
warnings to the user. We assume however that clients are working as
designed, e.g. that they are not infected with malware.
Secret Conversations relies upon the Signal Protocol. Messen-
ger uses Signal Protocol’s implementation as available in the open-
source libsignal-protocol-java and libsignal-protocol-c libraries for Android
and iOS respectively. Secret Conversations also incorporates
abuse-reporting features which are not present in other platforms
which use the Signal Protocol.
In this document we describe Secret Conversations, starting
with the transport protocol. We then cover abuse reporting and close
with how we handle on-device storage.
 DON'T TOUCH…
Follow
2k followers
BACKGROUNDS

apps.apple.com

Funny #lock #screen #wallpaper

Funny #wallpaper #iPhone nel 2022 | Sfondi
carini, Sfondi iphone, Sfondi twitter in... more
2022 |

More to explore

Brown skin girl love

S Samantha F.A Cute cat with text:

Why are yo looking …
my phone? Wallpaper

Visit Save
 messenger secret conversations technical whitepaper 5

Transport Protocol Overview

Secret Conversations is a device-to-device conversation mode.

Messages are only accessible from the devices which participate in a
conversation when the conversation occurs. This differs from regular
Messenger conversations which are stored server-side and are ac-
cessible from any device connected to the participating Facebook ac-
counts; including present and future devices and browser instances.
Instead, to use Secret Conversations users enable some subset
of devices, such as their mobile phone and a tablet, upon which only
their future secret conversations will be available.

Device Management

A user can enable or disable a device for Secret Conversations at

any point, and can disable other devices remotely from any currently
enabled device. Secret Conversations may also be enabled or
disabled automatically. When a user logs into a compatible version of
Messenger, the new device gets enabled for use with Secret Con-
versations. Facebook disables devices after they have been offline
for a period of at least 30 days. Upon enabling a new device existing
Secret Conversations messages and cryptographic keys are not
transferred to the new device.
Whenever the list of devices on which Secret Conversations is
enabled changes for an account, Messenger displays a warning that
this occurred. When a user’s own set of enabled devices changes, all
of their other devices enabled for Secret Conversations proac-
tively receive an update. People with pre-existing secret conversa-
tions with the user who changed their list of enabled devices receive
the same warning when they return to these pre-existing conversa-
tions.
Facebook bounces messages sent to an incorrect list of partici-
pants, and includes the correct device list within that bounce. Mes-
senger does not automatically resend bounced messages when new
devices are added to a secret conversation – an explicit resend action
from the user is required. Messenger, however, may automatically
 messenger secret conversations technical whitepaper 6

resend messages without user interaction in case of device removal,

as no device will receive the message that the sender has not been
notified about.

Keys

Each device manages various cryptographic keys. All keys are gener-
ated or derived on-device. Private keys are never sent to Facebook.

Public keys All public key operations use Curve25519. Each device
uses the following public-secret keypairs:

• The Identity Key keypair (IK pk , IKsk ). This is a long-term keypair

which is generated the first time Messenger runs.

• The Signed Pre-Key keypair (SPK pk , SPKsk ). This is a medium-term

keypair which is rotated periodically. It is signed by IKsk .

• The One-Time Pre-Key keypairs (OTPK pk , OTPKsk ). These keypairs

are generated in batches by clients. They facilitate asynchronous
conversation initiation.1 1
The client also generates a single
Last-Resort Pre-Key. This is used like
• The Ephemeral Key keypairs (EK pk , EKsk ). A new ephemeral keypair a One-Time Pre-Key, but is simply
provided when the server has no One-
is generated for each round of communication within a secret Time Pre-Keys available for a given
conversation and is subsequently discarded. device.

Pairwise Session keys When starting a pairwise cryptographic chan-

nel the participating devices derive symmetric session keys. These
are:

• The Root Key (RK) is a 256-bit key which is used to derive Chain
Keys in the Signal Protocol ratchets.

• Chain Keys (CK) are each 256-bit values which are used to derive
Message Keys.

• Message Keys (MK) are each 640-bit values which consist of 256 bits
for an AES-256 key, 256 bits for an HMAC·SHA256 key, and 128 bits
for an Initialization Vector (IV) for AES-CBC encryption.

Multicast Session keys In Secret Conversations involving more

than 2 devices each device uses session keys for sending messages.
These are:

• Sender Chain Keys (SCK) are 256-bit values used to derive Sender
Message Keys.
 messenger secret conversations technical whitepaper 7

• Sender Message Keys (SMK) are 384-bit values consisting of 256 bits
for an AES-256 key, and 128 bits for an Initialization Vector (IV) for
AES-CBC encryption.

• Sender Signing Keys (SSK) are key pairs used to sign multicast
messages.
When Messenger initialises Secret Conversations it generates
and then uploads to Facebook its permanent IK pk and the current
SPK pk . It generates a batch of one-time pre-key keypairs and uploads
their public parts to Facebook on demand.

Pairwise Channel Initiation

Each device in a secret conversation must have a pairwise channel

with each other device before it can send messages. Each pairwise
channel consists of two devices: one Initiator device and one Respon-
der device (I and R respectively). Let HKDF be a secure hash-based
key derivation function, and ECDH indicate the elliptic curve Diffie-
Hellman function applied to a secret and public key. To create a new
pairwise channel:

1. The Initiator obtains from Facebook IKRpk , SPKRpk and OTPKRpk for
an one-time pre-key keypair generated by the Responder device.

2. Facebook deletes OTPKRpk from the Responder’s list of available

one-time pre-keys, so long as it is not the last-resort.

3. The Initiator generates a fresh ephemeral keypair (EK Ipk , EKsk

I
).

4. The Initiator now computes the first root key RK as follows:

I
a = ECDH(IKsk , SPKRpk ), I
b = ECDH(EKsk , IKRpk )
I
c = ECDH(EKsk , SPKRpk ), I
d = ECDH(EKsk , OTPKRpk )
RK = HKDF( a||b||c||d)
Using the RK the Initiator can calculate the first CK and MK (as
described next) and use those to start sending messages.

5. The Initiator sends the first encrypted message to the Responder,

including the fresh EK Ipk it generated previously.

Upon receiving the first encrypted message the Responder:

1. Recomputes RK as above by performing the four ECDH operations

using the other part of the same keypairs available locally.

2. Recomputes the first CK and MK, and decrypts the message.

3. Deletes (OTPKRpk ,OTPKsk

R
) from its local storage.
 messenger secret conversations technical whitepaper 8

Pairwise Message Exchange

Each pairwise message is encrypted with AES·CBC and authenticated

using HMAC·SHA256. The unique MK is derived from the current CK
and RK. Their first value is:

CK = RK

MK = HKDF(CK)
In each message exchange, the sender generates a fresh ephemeral
keypair (EKsender
pk , EKsender
sk ) and includes the public part in the out-
going message. The recipient calculates the current MK value using
EKsender
pk and can decrypt the message. It too then generates a fresh
ephemeral keypair (EKreceiver
pk , EKreceiver
sk ) and derives new keys RK0 ,
0 0
CK and MK for use with the next response by updating the previous
symmetric key values as follows:

RK0 , CK0 = HKDF(ECDH(EKreceiver

sk , EKsender
pk ))

MK0 = HKDF(CK0 )
If a second message is sent before the opposing party responds, the
sender uses a new chain key CK00 = HKDF(CK) and a corresponding
MK00 = HKDF(CK00 ).
When a secret conversation contains just two devices, we use the
pairwise channel for transmitting messages directly. The Signal
Protocol’s implementation is open-source and available at https:
//github.com/whispersystems/libsignal-protocol-java/.

Multi-device Message Exchange

Secret conversations with more than two devices use the Signal Pro-
tocol’s Group Messaging protocol.
All messages have a Sender and at least two Receivers. Prior to
sending to a multi-device conversation Sender must have a pairwise
channel with every Receiver. Sender also generates a SCK and SSK,
and sends them along its pairwise channel to each Receiver.
Each multi-device message is encrypted with AES·CBC and signed
by the SSK. The unique SMK is derived from the SCK similarly to the
pairwise channel:

SMK = HKDF(SCK)

For subsequent messages the Sender ratchets the SCK using HKDF

SCK0 = HKDF(SCK)
 messenger secret conversations technical whitepaper 9

and uses each subsequent SCK0 key to derive SMK and SSK. This
approach provides forward secrecy, as earlier SCKs and SMKs cannot
be calculated from the current state.
When a new device is added to a secret conversation, each other
device will send the new device their latest SCK upon sending their
next message. When a device is removed however, each device will
generate a new SCK. This ensures that the necessary key material is
restricted to the devices within the thread.

Attachments
If a message includes attachments, such as images or videos, they
are encrypted and uploaded to Facebook. For each attachment, the
sender:

1. Generates a pseudorandom 256-bit AES key K and a 96-bit pseu-

dorandom Initialization Vector IV.

2. Encrypts the attachment using AES-GCM2 encryption using K 2

Messenger uses the AES-GCM imple-
and IV. The IV is placed into the header (Associated Data) of the mentation provided by OpenSSL. On
Android, Messenger employs Conceal.
GCM encryption. The IV and the GCM authentication tag are Conceal is open-source and available at
attached to the resulting ciphertext to form the encrypted file. https://facebook.github.io/conceal/

3. Computes a SHA256 hash H of the resulting encrypted file and

uploads the file to Facebook. The sender obtains a unique identi-
fier for future retrieval.

4. Encodes the unique identifier, K, H, attachment metadata, and an

optional thumbnail into a message. The message is encrypted and
sent to the recipient who downloads the content, verifies the hash
H, and decrypts the file using K.

Stickers

Stickers are images chosen from a set of collections hosted by Face-

book. Each sticker is referenced by a unique identifier. The sender
chooses a sticker to attach in a conversation from a set of sticker pre-
views available in the message composer. The sender then sends the
corresponding sticker identifier as an encrypted message to the re-
cipient. Unless the sticker file is available locally, both the sender and
the receiver submit the sticker identifier to Facebook and download
the corresponding sticker file. Facebook may infer the use of individ-
ual stickers when they are first used on a device but devices cache
sticker files and avoid repeat fetches if a sticker is later reused.
 messenger secret conversations technical whitepaper 10

Conversation Metadata
During a secret conversation, devices generate metadata such as de-
livery and read receipts to indicate successful message transmission
and display, respectively. Conversation metadata such as delivery
and read receipts do not contain message plaintext and are not end-
to-end encrypted.

Key Verification

For every secret conversation Messenger exposes in its interface the

identity keys (i.e. IK pk ) for every participating device. Users may
optionally verify these keys in order to ensure no man-in-the- mid-
dle attack is compromising their secret conversations. Messenger
displays the 256-bit IK pk values in hexadecimal format.
 messenger secret conversations technical whitepaper 11

Abuse Reporting

A participant in a secret conversation may voluntarily notify Face-

book of abusive content. Facebook uses such reports to identify users
who violate Facebook’s terms of service.
The ability to report abuse does not represent a relaxation of the
end-to-end encryption guarantees of Secret Conversations. Face-
book will never have access to plaintext messages unless one partici-
pant in a secret conversation voluntarily reports the conversation.
Secret Conversations includes a mechanism to perform
“franking” of messages sent through Facebook. This mechanism is
analogous to placing a cryptographic stamp on the message, without
learning the message content.

Franking

The franking mechanism must satisfy three main guarantees: au-

thenticity, confidentiality and third-party deniability. The authenticity
property ensures that if a user submits a report then the message
must have legitimately originated from the sender’s device. The con-
fidentiality property ensures that no outside party — including Face-
book — should learn the content of a message unless a participant
in a secret conversation voluntarily shares that information. Finally,
the third-party deniability property ensures that no party outside of
Facebook can cryptographically determine the validity of a report.

Franking tag Authenticity for messages in a secret conversation is

provided by the Franking tag TF . Senders must send the Franking
tag along with each encrypted message. To compute TF , the sender
first generates a 256-bit random nonce NF . NF is added to the unen-
crypted message being transmitted. Next, the entire data structure is
serialized into a string M, and TF is computed as:

TF = HMAC·SHA256(NF , M)

NF remains within the serialised, encrypted data sent to the recipient.

The sender destroys any other copies of NF after transmission. TF is
 messenger secret conversations technical whitepaper 12

transmitted to Facebook along with each encrypted message.

Franking messages When Facebook receives TF , it uses a Facebook

key KF to compute the Reporting tag RF over TF and conversation
context (e.g., sender and recipient identifiers, timestamp) as:

RF = HMAC·SHA256(KF , TF kcontext)

Both TF and RF are sent to the recipient along with the encrypted
message. The recipient decrypts the ciphertext, parses the resulting
plaintext to obtain NF , and verifies the structure of TF prior to dis-
playing the message. If TF is not verified then the recipient discards
the message without displaying it. The recipient stores the message
M, NF , TF , RF and context in its local storage.

Reporting abuse To report abuse, the recipient of a message submits

to Facebook the full serialized message plaintext, RF , NF , and context.
Upon receiving this message Facebook first recomputes TF and then
validates RF using the provided information as well as its internal
key KF .

Security and Privacy The authenticity properties of the franking

mechanism are based on reasonable assumptions about the collision-
resistance of the SHA256 hash function and the unforgeability of
HMAC·SHA256.

Authenticity In order to “forge” invalid content M0 , a user must

either ( a) produce a forged HMAC tag under Facebook’s key KF ,
or (b), identify a collision NF 0 , M0 , context0 such that the HMAC of
these values is equal to the HMAC of a different valid message M
sent through Facebook.

Confidentiality Similarly, under reasonable assumptions about

HMAC·SHA256, the resulting tag reveals no information about
the message to Facebook or to eavesdroppers.

Third-party deniability The guarantee holds under the assumption

that HMAC·SHA256 is a pseudorandom function and that KF is
never publicly revealed. Facebook rotates KF periodically.
 messenger secret conversations technical whitepaper 14

Video Attachments on iOS

As with other attachment types on iOS, video attachments are stored

on-device encrypted. To play videos however, Messenger’s video
player on iOS must access them via a URL. As memory cannot be
addressed by URL, this prevents videos from being playable directly
from an in-memory decrypt. Messenger decrypts videos and stores
them in a session-based least-recently-used filesystem cache when
they need to be viewed. This cache is cleared when a user logs out.
When a secret conversation is deleted, any associated decrypted
video attachments in the cache are deleted.
 messenger secret conversations technical whitepaper 15

Conclusion

Secret Conversations is a specialised conversation mode in Mes-

senger. Messages in Secret Conversations are encrypted end-to-
end between the sender and the recipient using the Signal Protocol
and its open-source implementations. Third parties — Facebook in-
cluded — do not have access to message plaintext and messages can
only be decrypted by their intended recipient. Users may inspect the
identity keys used for end-to-end encryption and verify the confiden-
tiality and authenticity of their communications. Decrypted messages
do not leave the devices that participate in the conversation. Users
retain the ability to report abusive content to Facebook.