Google Drive
Gist
Clipboard
This whitepaper describes protocols used by Status to achieve Perfect Forward Secrecy for 1:1 chat participants. It builds on the X3DH and Double Ratchet specifications from Open Whisper Systems, with some adaptations to operate in a decentralized environment.
Perfect Forward Secrecy is a feature of specific key-agreement protocols which provide assurances that your session keys will not be compromised even if the private keys of the participants are compromised. Specifically, past messages cannot be decrypted by a third-party who manages to get a hold of a private key.
Secret channel describes a communication channel where Double Ratchet algorithm is in use.
Confidentiality
The adversary should not be able to learn what data is being exchanged between two Status clients.
Authenticity
The adversary should not be able to cause either endpoint of a Status 1:1 chat to accept data from any third party as though it came from the other endpoint.
Forward Secrecy
The adversary should not be able to learn what data was exchanged between two Status clients if, at some later time, the adversary compromises one or both of the endpoint devices.
Types used in this specification are defined using Protobuf. Protocol buffers are a language-neutral, platform-neutral, extensible mechanism for serializing structured data.
Whisper (see PoC spec) serves as the transport layer for the Status chat protocol. Whisper is a hybrid P2P/DHT communication protocol which delivers messages probabilistically. It is designed to provide configurable levels of darkness and plausible deniability at the expense of high-latency and relatively high bandwidth.
Generating a user account in Status involves 3 steps:
Once two accounts have been generated (Alice and Bob), Alice can send a contact request with an introductory message to Bob.
There are two possible scenarios, which dictate the presence or absence of a prekey bundle:
Bob receives a contact request, informing him of:
If Bob's prekey bundle was not available to Alice, Perfect Forward Secrecy hasn't yet been established. In any case, there are no implicit guarantees that Alice is whom she claims to be, and Bob should perform some form of external verification (e.g., using an Identicon).
If Bob accepts the contact request, a secure channel is created (if it wasn't already), and a visual indicator is displayed to signify that PFS has been established. Bob and Alice can then start exchanging messages, making use of the Double Ratchet algorithm as explained in more detail in section 2.4.2.
If Bob denies the request, Alice is not able to send messages and the only action available is resending the contact request.
If Alice later recovers her account, the Double Ratchet state information will not be available, so she is no longer able to decrypt any messages received from existing contacts.
If an incoming message (on the same Whisper topic) fails to decrypt, a message is shown to Alice asking whether she wants to re-establish a secure channel with Bob, repeating the procedure in the previous section. TODO: @cammellos for more detail, if any
TODO
All messaging in Status is subject to end-to-end encryption to provide users with a strong degree of privacy and security.
End-to-end encryption (E2EE) takes place between two clients. The main cryptographic protocol is a Status implementation of the Double Ratchet protocol, which is in turn derived from the Off-the-Record protocol, using a different ratchet. The message payload is subsequently encrypted by the transport protocol - Whisper (see section 1.4) -, using symmetric key encryption.
Furthermore, Status uses the concept of prekeys (through the use of X3DH) to allow the protocol to operate in an asynchronous environment. It is not necessary for two parties to be online at the same time to initiate an encrypted conversation.
Status uses the following cryptographic primitives:
Whisper
X3DH
Double Ratchet
Key derivation is done using HKDF.
Every client initially generates some key material which is stored locally:
Prekey bundles are exchanged through QR codes, contact codes, 1:1 or public chat messages. We will be updating this document with information about bundle exchange through ENS and Swarm as work progresses and technologies become more usable.
X3DH works by having client apps create and make available a bundle of prekeys (the X3DH bundle) that can later be requested by other interlocutors when they wish to start a conversation with a given user.
In the X3DH specification, a shared server is typically used to store bundles and allow other users to download them upon request. Given Status' goal of decentralization, Status chat clients cannot rely on the same type of infrastructure and must achieve the same result using other means. By growing order of convenience and security, the considered approaches are:
Since bundles stored in QR codes or ENS records cannot be updated to delete already used keys, the approach taken is to make publicly available an initial generic bundle without one-time prekeys, and subsequently provide a second user-specific X3DH prekey bundle.
There are two phases in the initial negotiation of a 1:1 chat:
The initial key exchange flow is described in section 3 of the X3DH protocol, with some additional context:
Bob's prekey bundle is retrieved by Alice, however it is not specific to Alice. It contains:
(protobuf)
message Bundle {
bytes identity = 1;
bytes signed_pre_key = 2;
bytes signature = 3;
}
identity: Identity key \(IK_B\)signed_pre_key: Signed prekey \(SPK_B\)signature: Prekey signature Sig(\(IK_B\), Encode(\(SPK_B\)))COMMENT: https://github.com/status-im/status-go/blob/features%2Fx3dh/services/shhext/chat/encryption.proto#L15 looks like signed_pre_key is a map here, and it talks about installation id. – Oskar
Having established the initial shared secret SK through X3DH, we can use it to seed a Double Ratchet exchange between Alice and Bob.
Please refer to the Double Ratchet spec for more details.
The initial message sent by Alice to Bob is sent as a top-level ProtocolMessage (protobuf) containing a DirectMessageProtocol (protobuf):
message ProtocolMessage {
Bundle bundle = 1;
oneof message_type {
DirectMessageProtocol direct_message = 101;
bytes public_message = 102;
}
}
bundle: optional bundle is exchanged with each message;direct_message: encrypted one-to-one chat message; orpublic_message: unencrypted public chat message.message DirectMessageProtocol {
X3DHHeader X3DH_header = 1;
DRHeader DR_header = 2;
DHHeader DH_header = 101;
bytes payload = 3;
}
X3DH_header: the X3DHHeader field in DirectMessageProtocol contains:
(protobuf)
message X3DHHeader {
bytes key = 1;
bytes id = 4;
}
key: Alice's ephemeral key \(EK_A\);id: Identifier stating which of Bob's prekeys Alice used, in this case Bob's bundle signed prekey.Alice's identity key \(IK_A\) is sent at the transport layer level (Whisper);
DR_header: Double ratchet header (protobuf). Used when Bob's public bundle is available:
message DRHeader {
bytes key = 1;
uint32 n = 2;
uint32 pn = 3;
bytes id = 4;
}
key: Alice's current ratchet public key (as mentioned in DR spec section 2.2);n: number of the message in the sending chain;pn: length of the previous sending chain;id: Bob's bundle ID.DH_header: Diffie-Helman header (used when Bob's bundle is not available):
(protobuf)
message DHHeader {
bytes key = 1;
}
key: Alice's compressed ephemeral public key.payload:
The same considerations apply as in section 4 of the X3DH spec and section 6 of the Double Ratchet spec, with some additions detailed below.
TODO: Add any additional context here not covered in the X3DH and DR specs, e.g.:
TODO
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe