diff --git a/x6.md b/x6.md index fec7b77..60b5cd6 100644 --- a/x6.md +++ b/x6.md @@ -3,15 +3,13 @@ sip: x6 title: Initial Conversational Security Specification status: Draft type: Standard -author: Andrea Piana , Pedro Pombeiro +author: Andrea Piana , Pedro Pombeiro , Corey Petty , Oskar Thorén created: 2018-12-05 updated: 2019-04-22 --- **TODO: Specify conversational security and guarantees** -See https://notes.status.im/sDKuBAiPSH6iB9cFmEKLyg?both# for things that we want to capture here. - *NOTE: Starting point: PFS whitepaper.* Status Perfect Forward Secrecy Whitepaper @@ -340,4 +338,194 @@ Expired session should not be used for new messages and should be deleted after ## 4.3 Stale devices -When a bundle is received from $IK$ a timer is initiated on any `installation-id` belonging to $IK$ not included in the bundle. If after 7 days no bundles are received from these devices they are marked as `stale` and no message will be sent to them. \ No newline at end of file +When a bundle is received from $IK$ a timer is initiated on any `installation-id` belonging to $IK$ not included in the bundle. If after 7 days no bundles are received from these devices they are marked as `stale` and no message will be sent to them. + + +## Raw SoK evaluation import + +TODO: Write this in a more active voice + +## Conversational Security +TODO: description here + +### --- Security and Privacy Features +#### Confidentiality (YES) +> Only the intended recipients are able to read a message. Specifically, the message must not be readable by a server operator that is not a conversation participant + +- Yes. +- There's a layer of encryption at Whisper as well as above with Double Ratchet +- Relay nodes and Mailservers can only read a topic of a Whisper message, and nothing within the payload. + +#### Integrity (YES) +> No honest party will accept a message that has been modified in transit. + +- Yes. +- Assuming a user validates (TODO: Check this assumption) every message they are able to decrypt and validates its signature from the sender, then it is not able to be altered in transit. + * [igorm] i'm really not sure about it, Whisper provides a signature, but I'm not sure we check it anywhere (simple grepping didn't give anything) + +#### Authentication (YES) +> Each participant in the conversation receives proof of possession of a known long-term secret from all other participants that they believe to be participating in the conversation. In addition, each participant is able to verify that a message was sent from the claimed source + +- 1:1 --- one-to-one messages are encrypted with the recipient's public key, and digitally signed by the sender's. In order to provide Perfect Forward Secrecy, we build on the X3DH and Double Ratchet specifications from Open Whisper Systems, with some adaptations to operate in a decentralized environment. +- group --- group chat is pairwise +- public --- A user subscribes to a public channel topic and the decryption key is derived from the topic name + +**TODO:** Need to verify that this is actually the case +**TODO:** Fill in explicit details here + +#### Participant Consistency (YES?) +> At any point when a message is accepted by an honest party, all honest parties are guaranteed to have the same view of the participant list + +- **TODO:** Need details here + +#### Destination Validation (YES?) +> When a message is accepted by an honest party, they can verify that they were included in the set of intended recipients for the message. + +- Users are aware of the topic that a message was sent to, and that they have the ability to decrypt it. +- + +#### Forward Secrecy (PARTIAL) +> Compromising all key material does not enable decryption of previously encrypted data + +- After first back and forth between two contacts with PFS enabled, yes. + +#### Backward Secrecy (YES) +> Compromising all key material does not enable decryption of succeeding encrypted data + +- PFS requires both backward and forwards secrecy +[Andrea: This is not true, (Perfect) Forward Secrecy does not imply backward secrecy (which is also called post-compromise security, as signal calls it, or future secrecy, it's not well defined). Technically this is a NO , double ratchet offers good Backward secrecy, but not perfect. Effectively if all the key material is compromised, any future message received will be also compromised (due to the hash ratchet), until a DH ratchet step is completed (i.e. the compromised party generate a new random key and ratchet)] + +#### Anonymity Preserving (PARTIAL) +> Any anonymity features provided by the underlying transport privacy architecture are not undermined (e.g., if the transport privacy system provides anonymity, the conversation security level does not deanonymize users by linking key identifiers). + +- by default, yes +- ENS Naming system attaches an identifier to a given public key + +#### Speaker Consistency (PARTIAL) +> All participants agree on the sequence of messages sent by each participant. A protocol might perform consistency checks on blocks of messages during the protocol, or after every message is sent. + +- We use Lamport timestamps for ordering of events. +- In addition to this, we use local timestamps to attempt a more intuitive ordering. [Andrea: currently this was introduced as a regression during performance optimization and might result in out-of-order messages if sent across day boundaries, so I consider it a bug and not part of the specs (it does not make the order more intuitive, quite the opposite as it might result in causally related messages being out-of-order, but helps dividing the messages in days)] +- Fundamentally, there's no single source of truth, nor consensus process for global ordering [Andrea: Global ordering does not need a consensus process i.e. if you order messages alphabetically, and you break ties consistenly, you have global ordering, as all the participants will see the same ordering (as opposed to say order by the time the message was received locally), of course is not useful, you want to have causal + global to be meaningful] + +TODO: Understand how this is different from Global Transcript +[Andrea: This is basically Global transcript for a single participants, we offer global transcript] + +#### Causality Preserving (PARTIAL) +> Implementations can avoid displaying a message before messages that causally precede it + +- Not yet, but in pipeline (data sync layer) + +[Andrea: Messages are already causally ordered, we don't display messages that are causally related out-of-order, that's already granted by lamport timestamps] + +TODO: Verify if this can be done already by looking at Lamport clock difference + +#### Global Transcript (PARTIAL) +> All participants see all messages in the same order + +- See directly above + +[Andrea: messages are globally (total) ordered, so all participants see the same ordering] + +#### Message Unlinkability (NO) +> If a judge is convinced that a participant authored one message in the conversation, this does not provide evidence that they authored other messages + +- Currently, the Status software signs every messages sent with the user's public key, thus making it no able to give unlinkability. +- This is not necessary though, and could be built in to have an option to not sign. +- Side note: moot account allows for this but is a function of the anonymity set that uses it. The more people that use this account the stronger the unlinkability. + +#### Message Repudiation (NO) +> Given a conversation transcript and all cryptographic keys, there is no evidence that a given message was authored by any particular user + +- All messages are digitally signed by their sender. +- The underlying transport, Whisper, does allow for unsigned messages, but we don't use it. + +#### Participant Repudiation (NO) +> Given a conversation transcript and all cryptographic key material for all but one accused (honest) participant, there is no evidence that the honest participant was in a conversation with any of the other participants. + +### --- Group related features +#### Computational Equality (YES) +> All chat participants share an equal computational load + +- One a message is sent, all participanats in a group chat perform the same steps to retrieve and decrypt it. +- If proof of work is actually used at the Whisper layer (basically turned off in Status) then the sender would have to do additional computational work to send messages. + +#### Trust Equality (PARTIAL) +> No participant is more trusted or takes on more responsibility than any other + +- 1:1 chats and public chats are equal +- group chats have admins (on purpose) +- Private Group chats have Administrators and Members. Upon construction, the creator is made an admin. These groups have the following priveledges: + - Admins: + - Add group members + - Promote group members to admin + - Change group name + - Members: + - Accept invitation to group + - Leave group + - Non-Members: + - Invited by admins show up as "invited" in group; this leaks contacat information + - Invited people don't opt-in to being invited + +TODO: Group chat dynamics should have a documented state diagram +TODO: create issues for identity leak of invited members as well as current members of a group showing up who have not accepted yet [Andrea: that's an interesting point, didn't think of that. Currently we have this behaviour for 2 reasons, backward compatibility with previous releases, which had no concept of joining, and also because we rely on other peers to propagate group info, so we don't have a single-message point of failure (the invitation), the first can be addressed easilly, the second is trickier, without giving up the propagation mechanism (if we choose to give this up, then it's trivial)] + +#### Subgroup Messaging (NO) +> Messages can be sent to a subset of participants without forming a new conversation + +- This would require a new topic and either a new public chat or a new group chat +[Andrea: This is a YES, as messages are pairwise encrypted, and client-side fanout, so anyone could potentially send a message only to a subset of the group] + +#### Contractible Membership (PARTIAL) +> After the conversation begins, participants can leave without restarting the protocol + +- For 1:1, there is no way to ignore or block a user from sending you a message. This is currently in the pipeline. +- For public chats, Yes. A member simply stops subscribing to a specific topic and will no longer receive messages. +- For group chats: this assumes pairwise encryption OR key is renegotiated +- This only currently works on the identity level, and not the device level. A ghost device will have access to anything other devices have. +[Andrea: For group chats, that's possible as using pairwise encryption, also with group chats (which use device-to-device encryption), ghost devices is a bit more complicated, in general, they don't have access to the messages you send, i.e. If I send a message from device A1 to the group chat and there is a ghost device A2, it will not be able to decrypt the content, but will see that a message has been sent (as only paired devices are kept in sync, and those are explicitly approved by the user). Messages that you receive are different, so a ghost device (A2) will potentially be able to decrypt the message, but A1 can detect the ghost device (in most cases, it's complicated :), the pfs docs describe multi-device support), for one-to-one ghost devices are undetectable] + +#### Expandable Membership (PARTIAL) +> After the conversation begins, participants can join without restarting the protocol. + +- 1:1: no, only 1:1 +- private group: yes, since it is pair-wise, each person in the group just creates a pair with the new member +- public: yes, as members of a public chat are only subscribing to a topic and receiving anyone sending messages to it. + +### --- Usability and Adoption + +#### Out-of-Order Resilient (PARTIAL) +> If a message is delayed in transit, but eventually arrives, its contents are accessible upon arrival + +- Due to asynchronous forward secrecy and no additional services, private keys might be rotated + +[Andrea: That's correct, in some cases if the message is delayed for too long, or really out-of-order, the specific message key might have been deleted, as we only keep the last 3000 message keys] +[Igor: TTL of a whisper message can expire, so any node-in-transit will drop it. Also, I believe we ignore messages with skewed timestamps] + +#### Dropped Message Resilient (PARTIAL) +> Messages can be decrypted without receipt of all previous messages. This is desirable for asynchronous and unreliable network services + +- Public chats: yes, users are able to decrypt any message received at any time. +- 1-to-1/group chat also, this is a YES in my opinion + +#### Asynchronous (PARTIAL) +> Messages can be sent securely to disconnected recipients and received upon their next connection + +- The semantics around message reliability are currently poor + * [Igor: messages are stored on mailservers for way longer than TTL (30 days), but that requires Status infrastructure] +- There's a TTL in Whisper and mailserver can deliver messages after the fact + +TODO: this requires more detail + +#### Multi-Device Support (YES) +> A user can participate in the conversation using multiple devices at once. Each device must be able to send and receive messages. Ideally, all devices have identical views of the conversation. The devices might use a synchronized long-term key or distinct keys. + +- Yes +- There is currently work being done to improve the syncing process between a user's devices. + +#### No Additional Service (NO) +> The protocol does not require any infrastructure other than the protocol participants. Specifically, the protocol must not require additional servers for relaying messages or storing any kind of key material. + +- The protocol requires whisper relay servers and mailservers currently. +- The larger the number of whisper relay servers, the better the transport security but there might be potential scaling problems. +- Mailservers act to provide asyncronicity so users can retreive messages after coming back from an offline period. \ No newline at end of file