Latest revision as of 10:48, 23 June 2016

Abstract

In this document we present the first public draft of (n+1)sec - a secure multi-party communication protocol developed by eQualit.ie with support from the Open Technology Fund and Cryptocat. We include the design rationale, choice of security features, adversarial models, schematic and high level specification of sub-protocols. A subsequent document will present security proofs and implementation details.

The (n+1)sec project was inspired by Off-The-Record messaging protocol and subsequent efforts to explore a multiparty use-case for OTR in ^[GUVGC09]. (n+1)sec is currently developed for Cryptocat - a browser based XMPP chat platform and assumes its use-cases. Most importantly, (n+1)sec allows for secure multi-party key exchange and end-to-end encrypted communications without extensive computational requirements from the client. You can follow and contribute to the implementation of np1sec on our Github pages. Future protocol iterations will consider a variety of other real-world use cases and be platform independent. Please use the Discussion page to ask questions and leave comments.

In the following section we summarise relevant publications and describe their influence on this protocol. In Section III, we describe our approach and choice of security features. In Section IV, we review the security properties within this protocol. In Section V we give basic mathematical definition needed to model the chat session and security proofs for various security aspects of the protocol. Section VI provides formal definitions and references to the adversarial models for each property. In Section VII we describe various parts of the protocol and present choices for each sub protocol. In Section VIII, we present each of the (n+1)sec protocol steps at various stages in schematic and algorithmic format. We present our choice of primitives in Section IX. Finally, we define the work that remains to be done on this protocol and acknowledge the good people who have helped us get here.

Two-party Off The Record messaging (OTR) was introduced in ^[BGB04] as an alternative to PGP for secure casual Internet chat by providing necessary forward secrecy and deniable transcript features. The paper proposes the use of symmetric encryption and message authentication in OTR for confidentiality and integrity, and the Diffie-Hellman key exchange for authenticating the other party in the chat. Since publication in 2004, it has defined the standard for secure Internet chat attracting a lot of academic attention and security analysis. The OTR protocol is now at Version 3 and the libotr software libraries are continuously updated. Our research and literature review focused on the protocol presented in ^[BGB04] and the subsequent proposal for a multiparty use-case in ^[GUVGC09].

In ^[RGK05], researchers point out that OTR’s approach to authenticate renewed ephemeral session keys is provided by the property of confidentiality and is therefore dependent on the secrecy of the conversation. Hence, breaking the secrecy of the conversation (e.g. by leaking the session key) will lead to false authentication as well. They offer two authenticated deniable key exchange protocols, which also provide forward secrecy, as a replacement for OTR’s original key exchange. Furthermore, they argue that forgeability and malleability do not have any mathematical consequence in improving deniability if the parties have been authenticated by a deniable key exchange scheme. They argue that as these properties pose potential security threats, it is desirable to omit them from the protocol entirely.

An alternative appears in ^[BS07], using the Schnorr zero-knowledge proof and signature algorithm, to introduce a 4-round challenge-based authentication scheme that grants deniability to the two-round authenticated protocol described in ^[BVS05].

^[ACMP10] offers a more efficient protocol than ^[BS07] in the sense that ephemeral Diffie-Hellman elements are reusable to regenerate keys when some of the participants change. As such, it offers a one-round protocol to generate a key for a subgroup of the original conversation.

An unauthenticated exchange of the OTR version identifier can pose a threat to authenticity as shown in ^[BM]: the adversary can force clients to downgrade to an older, (potentially insecure) version of the protocol. They also note the Diffie-Hellman key exchange failure in delivering authentication in the presence of an active adversary. Furthermore, they show that the early publication of MAC keys for the purpose of forgeability can easily enable the active adversary to forge messages during the conversation (instead of the intended forgeability after the conversation has ended). Finally, they argue that in an environment where the adversary is controlling the whole network, she can effectively disarm the protocol of its forgeability property.

Various attempts have been made to construct an efficient multiparty (known as group) authenticated key exchange protocol. OTR authors proposed a generalisation of two-party OTR to a multiparty use-case in ^[GUVGC09]. However, they did not specify the cryptographic primitives, neither did they give a formal definition of the adversaries nor the proof of the algorithm’s security (reduction). Although a more robust key exchange is proposed, some primary performance analysis of the implementation of the key agreement protocol has been shown to be impractically slow, especially on mobile devices ^{[Gun13a][Git11]}.

^[LVH13] proposes GOTR as an alternative to ^[GUVGC09] with a goal of improving on some of its security properties. A notable change is the use of p2p private channels to send message digest so as to establish transcript consistency and implicit message origin authenticity between users. GOTR also strives to improve on repudiability by considering deniability against an 'online judge' as well as forgeability for the entire transcript by a single party (this is possible in ^[GUVGC09] as long as a deniable AKE is being used). The idea of online repudiabilty relies on the judge controlling up to N-2 parties while the two remaining "honest" parties are allowed to collude. This is slightly unusual for both repudiability and honesty. ^[LVH13] also proposes an involved contributory BD based key agreement scheme, which disregard room consistency and turns GOTR into a broadcast scheme (c.f. Appendix B).

Our approach for (n+1)sec design was based on the following requirements, in order of importance:

1. A protocol that is provably secure in a sufficiently strong adversarial model that addresses confidentiality, authenticity and forward secrecy
2. Applicable to the Cryptocat XMPP use-case
3. Providing some degree of deniability when it does not negatively impact usability or our security goals
4. Addressing security flaws in ^[BGB04] and ^[GUVGC09]

We designate the protocol suggested in ^[GUVGC09] as our starting point and apply various modifications to reach a desirable protocol satisfying the above stated goals.

A significant portion of our research suggested a better performing, more secure alternative to the key exchange protocol suggested in ^[GUVGC09]. Based on conclusions in ^[BM] and ^[RGK05], we are making the following design changes:

• Using a more secure deniable key exchange algorithm, instead of naive Diffie-Hellman

In designing (n+1)sec’s deniable authentication and key agreement protocol, we have followed ^[ACMP10] by choosing a provably secure authenticated key exchange method and replacing the signature-based authentication with a deniable one. We have chosen the protocol introduced in ^[ACMP10] instead of ^[BS07], due to its superior efficiency. We abstract out the method where parties communicate their secret for additional flexibility.

• Using a more practical algorithm, rather than the peer-to-peer signature key exchange

We have chosen the two round SKEME-based Triple Diffie-Hellman deniable key authentication instead of the Schnorr signature scheme suggested in ^[BS07] because it saves us two critical rounds for authentication (even though it offers a slightly weaker form of deniability). We have also modified the protocol to represent the chat condition where participants sequentially join and leave the chat.

• Omitting forgeability and malleability from the protocol and refraining from broadcasting the expired ephemeral authentication keys.

Following conclusions in ^[RGK05] we have dropped forgeability (mandatory publication of ephemeral signature/MAC keys) and malleability from our requirements since protocol deniability is based on a deniable key exchange. This significantly improves protocol efficiency, a primary focus for (n+1)sec. The deniability of the authentication scheme prevents users not present in a chat session from forging a part of the transcript, however it allows them to forge a whole session with false participants and a complete transcript.

Another major departure from the suggested protocol in ^[GUVGC09] is in-session transcript authentication, which happens every time a participant receives or sends a message. Transcript authentication (referred to as transcript consistency check from here on) is an optimistic approach based on the assumption that the chat server is mandated to provides a reliable and orderly message delivery, as it is in the case of XMPP protocol. We can ensure transcript consistency whenever the underlying transport layer guarantees the reliable delivery of the messages in the same order for all participants. If however, the underlying protocol does not guarantee reliability either in delivery or order, we report the discrepancy in user's transcript compared to their peers but we do not attempt to correct the transport protocol's action (we offer detection but not recovery).

We also equip (n+1)sec with heartbeat to ensure in-session forward secrecy, periodical consistency check and freshness.

We propose the possibility of using block-based, rather than stream-based, encryption for the symmetric encryption primitives.

Finally, other protocol design possibilities considered and the rationale for not pursuing them further is discussed in Appendix B: Other design possibilities

Following from the design rationales proposed in SectionIII, we give an informal description of the properties which (n+1)sec aims to secure in a multi-party chat session:

• Participant deniable authenticity based on their long term persistent identity: While a participant in a chat can be sure of another participant’s authenticity, they cannot prove their confidence to anybody else who has not actively participated in the chat session or who has not interacted with the authenticator prior to the session.
• Message origin authenticity against both outsider intrusion and the impersonation of existing participants by other malicious participants in the session. This means that the user can be assured of the authenticity of the sender of each original message even if other participants in the room try to impersonate the sender and send messages on their behalf.
• Confidentiality of the conversation so its content is not accessible or readable by an outsider.
• Forward secrecy of the conversation, so its content remains inaccessible in the event that the long term private key of a participant (which represents their long term identity) is compromised after session key establishment. In addition in-session forward secrecy means that compromise of the ephemeral keys of a participant, or the session key during chat session which is live for long time, would reveal only a fraction of the transcript.
• Room consistency, where all participants are confident that they have been participating in the same room; they are confident that everybody in the room believes that everybody else sees the same participant list as they do.
• Transcript consistency, where all participants are confident that they have been participating in the same conversation; as the conversation continues, they are confident that they have been seeing the same sequence of messages.

For each of these requirements, it is necessary to formalize the above mentioned properties against an adversarial model which addresses the requirements stated in Section III. The next section will introduce formal definitions covering these elements.

In modelling the chat session, in terms of the adversarial models and protocol specifications, the notation of ^[ACMP10] is followed. This notation is common to other publication on group key exchange such as ^[GBNM11], and is adherred to for consistency.

Definition V.1 Multi-party chat session: Let be the set of possible participants. A multi-party chat session is an ordered pair in which and is the unique session id. Without loss of generality we assume and we interchangeably refer to party by index i. Furthermore, it is assumed that party is presented and identified verifiably by a long-term persistence key pair .

Definition V.2 sub session After session S is established, A subset of participants might want to start a session in which parties in are excluded (for example when those parties leave the chatroom). In such a setting we say is a subsession of S. When there is no need to specify the subsession of choice, we use to refer to .

Definition V.3 An authenticated group key exchange (AGKE) is Algorithm which each honest party will execute in order to communicate (by means of sending, receiving or computing) a cryptographic secret - namely a key - among the other parties of a session. By (or when the underlying session is understood) we are referring to an instance of which the party executes to achieve the collective goal. Further more we define:

• Session id as seen by : Session id will be derived during the execution of the protocol. The session id is computed by (the instance of the protocol run by for session S) and is indicated by , or when there is no concern of confusion
• Participant list: is the list of participants which believes are participating in the chat session S. When there is no ambiguity in the underlying session, we simply use notation.
• 'key id is the serial number given to the P2P keys generated during the process of key exchange, is computed as .
• Ephemeral key list: is the list of ephemeral public key 's of all participants which believes they are using in the chat session S. When there is no ambiguity in the underlying session, we simply use notation instead. We use the notaion of to represent ordered concatenation of pairs as in . The order is assumed to be computable by all participants (lexicographically ordered using long term public key of participants, for example).
• Session key of as seen by : (or ) is the session key of session S as computed by . It represents the cryptographic secret computed by AGKE, it can be a set of secrets. The essential defining factor is that it should become common knowledge for the session participants at the end of AGKE execution. Similarly we define to represent the subsession key
• Accepted state: A party enters the accepted state if it has computed and has detected no errors in the protocol.
• Partnered instances: Two instances and are considered partnered if and only if both instances have accepted and .

• A correct AKGE algorithm is an AKGE which, when all instances of AKE algorithm are initiated with access to a network which correctly forwards all messages without modification, all participants ultimately are partnered and all compute equal ’s.

When underlying session are not considered we may omit the super script from all above notations.

Adversarial models are explained as a game, in which the adversary's possibilitiy of winning the game should be considered in terms of their ability to break the cryptographic primitives.

Accordingly to the requirements discussed in Section IV, it is necessary to examine the algorithm in terms of following threat cases:

1. Deniable Authenticated key exchange (including a forward secrecy adversary)
2. Message origin authenticity
3. Confidentiality
4. Transcript consistency

The following sections will define adversarial scenarios which represent the above threats.

Deniable Authenticated Key Exchange Adversary

Following the approach in [BoSt06] the model is divided into two adversaries: Authenticated Group Key Exchange and the Deniability Adversary.

As deniability is not our primary focus, we wil consider a weaker deniability adversarial model, which limits possible input similarly to the limitations considered by [GKR06]. This provision would disallow an input from the 'judge' and therefore saves an extra round of communication within the protocol.

Because he t(n+1)sec protocol runs a peer-to-peer key exchange and establishes parallel deniable authentication, we use the adversarial model from ^[ACMP10] for authenticated group key exchange. This ensures the security of both group and peer-to-peer keys independently. The protocol also takes advantage of "single round computation of a subgroup key". Meaning that when a participant leaves the session remaining participants can re-establish a (sub)session with only one round of communication. In this circumstance, the model must also consider an adversary's attack against the subgroup key.

We do not attempt to model resistance against internal key compromise impersonation (KCI) as defined ^[GBNM11].

Authenticated Key Exchange Adversary

Adversarial power

The following set of functions model the AKE adversarial threats. The adversary for the authenticated key exchange can mount an attack through a sequence of call to the functions, outlined below. The limitation on the order and condition of calling these functions is defined per adversary. We will re-use these definitions to demonstrate similar routes for other adversaries considered by the threat models in later sections.

• Execute(): asks all parties in the to run (a new) AGKE protocol and will receive the execution transcript, i.e. can eavesdrop.
• Send()/() sends a message m to the instance . We assume that m contains information to identify the sender . will receive the execution transcript. Specifically, by sending messages it forces to initiate .
• SKE(): asks to compute the subgroup key for the subsession. In response, will either send a message or compute the subgroup key depending on the state of . This can be invoked only once per input.
• RevealGK(): gives to if it has accepted (as defined in Definition III.3).
• RevealSK(): gives the to if it has been computed for subsession T.
• Corrupt(): gives its long term secret key to (but not the session key).

Adversary's challenges

The following set of functions model the adversary's challenges. These reveal either a random value or a key. The adversary's advantage in distinguishing the cases should be translatable into an attack against the GDH primitive for the protocol to be considered secure.

• TestGK(): To the ultimate goal of challenging the confidentially of , can run TestGK() against U. As a the result a random bit b is chosen, if then is given the session key, otherwise a random value from the same probability distribution is given to . Obviously, this can only be invoked once and only on accepted participants.
• TestSK(): To the ultimate goal of challenging the confidentially of , can run TestSK() against U. The result depends on a a random chosen bit b, if then is given the subsession key, otherwise a random value from the same probability distribution is given to .

Definition of Adversaries and their advantages

The following terminology is useful in simplifying the elimination of trivial adversarial threats.

Definition VI.1 Accepted is fresh if none of the following is true:

• RevealGK() for .
• Corrupt() invoked for any before any Send().

Definition VI.2 A pair of is fresh, if is accepted and if none of the following is true:

• RevealSK() for .
• Corrupt() invoked for any before any Send().

Definition VI.3 An AKE Adversary for the join key agreement is a probabilistic polynomial time algorithm (ppt) which can invoke all the functions given above with a condition that the TestGK is invoked at least once against a fresh instance which stays fresh until the end of the game. The game ends when outputs its guess for b. We say a key exchange protocol is secure if the following function is negligible:

Similarly we define the Adversary leaving the session:

Definition VI.4 An AKE Adversary for the leave key agreement is a ppt which can invoke all the functions given above with the condition that one of the invocations of TestSK is invoked against a fresh instance which stays fresh till the the end of the game. The game ends when outputs its guess for b for that invocation. We say a key exchange protocol is secure if the following function is negilgible:

Forward Secrecy Adversary

We do not define an independent forward secrecy adversary. Forward secrecy can be derived by resistance against the confidentiality adversary as well incorporating a forward secure key exchange as described in ^[GBN10]. The adversaries of Definition VI.3 and VI.4, are able to Corrupt users after the communication of DH secrets. Therefore they can trivially break an AKE without forward secrecy. In this sense, the resistance against forward secrecy adversary is included in AKE adversarial model.

Deniability Adversary

We use the deniability adversary of [BoSt06], however following the path of [GRK06], we limit the security input of the deniability adversary in order to prevent the adversary from receiving input from the judge.

'Definition VI.5 A Deniability Adversary with bound and security input is a ppt algorithm which can invoke Send and Reveal as desired and Corrupt as many as times. At the end, will output a transcript .

Definition VI.6 For each , we define a simulator , is a ppt algorithm which receives the same input as . It can invoke Corrupt times in addition to Send and Reveal but only against corrupted instances. It terminates by outputting a transcript .

Definition VI.7 A deniability judge with security input is a ppt algorithm which can invoke arbitrary number of deniability adversaries with security input . On each execution of a corresponding runs with the same input. At the end a confidential random bit b is generated, and either or is presented to based on whether or 0 respectively.

Definition VI.8 We call a Group AKE deniable with respect to input set , if the following advantage is negligible:

Similar to [GRK06], we claim that the AKE presented in this paper is deniable when is equal to the set of valid messages eavesdropped by during other sessions. This, in particular, excludes a transcript computed by such as a group element whose discrete logarithm is only known to (This means is given but is unaware of a).

Secure Multiparty Channel Adversary

The desirable way to define an adversary for a multiparty chat session is a secure channel model similar to the two-party secure channels described in ^[CaKr01] and ^[KPW13]. However, defining such a model is outside of our current scope. It is desirable to later improve the security of the protocol bu considering such a model at a later stage. At present, we use a per message model for confidentiality and origin authenticity.

Message Origin Authentication Adversary

As each participant executes a sign and encrypt function before sending their authenticated ephemeral signing key, the message origin adversary model is based on a typical adversary for a signature scheme such as the one presented in [PVY00].

Adversarial power

In addition to adversarial functions defined in section 1.1.1. we must define the following function to allow for the adversary using the chosen-message attack.

• MakeSend() causes the to sign and send a valid message m to instance . will receive the transcript including the signature.

Definition of Adversary

Definition VI.9: Message Origin Authentication Adversary is a polynomial time algorithm which has access to the Corrupt, Send, Reveal and MakeSend functions. The output of the algorithm should be a message m sent to instance . The scheme is secure against Message Origin Adversary if the probability in which believes that m has originated from an uncorrupted participant is negligible.

Message Confidentiality Adversary

The goal of adversary is to read, at least, part of the communications transcript during the session.

Adversary's challenges

The following set of functions model the confidentiality adversary's challenges. These reveal either a random value or an encrypted message. The adversary's advantage in distinguishing the cases should be translatable into an attack against the block cipher, AES in this case.

• TestM(): To the ultimate goal of challenging the indistinguishibility of , can execute TestM() against . As a result a random bit b is chosen, if then is given .

Definition of Adversaries and their advantages

Definition 1 A Confidentiality Adversary is a ppt which can invoke all the functions given in sections IV.1.1.1 and IV.1.1.3 with the condition that one of the invocations of TestM is invoked against an instance where all instances in session s are fresh and stay fresh till the end of the game. The game ends when outputs its guess for b for that invocation. We say that the protocol is secure if the following function is negligible:

Consistency Adversary

In (n+1)sec protocol, we attempt to ensure the consistency among participants all along the session incrementally, i.e. assuring consistency after receiving each message in a timely manner. However, we do not model the incremental aspect of consistency into the adversarial model, for the sake of simplicity.

Definition 1 Transcript Consistency Adversary is given the ability to invoke all functions in sections IV.1.1.1 and IV.1.1.3. We say the protocol is secure against Consensus Adversary if at least two uncorrupted accepted instances possess the transcripts chain and they believe they have the see Section VII.4.1.

To achieve the security properties listed in Section IV, we break the protocol into the following sub-protocols:

1. Deniable authenticated signature key and session key exchange, where participants deniably authenticate each other and agree on session key(s), while also exchanging ephemeral signing keys
2. Communication, where parties send authenticated confidential messages
3. Transcript consistency verification, where parties verify that all have received and seen an identical transcript in the same order, since the start of the chat session after receiving each messages.

Our choice of sub-protocols for (n+1)sec followed suggestions made in ^[BGB04] and ^[GUVGC09], except where there has been a practical or security-related reason to deviate from those recommendations.

In the following section we briefly describe our choice of the sub-protocols for each of the required tasks for a multi-party chat session.

VII.1 Design of Deniable Authenticated Signature Key Exchange

We have chosen our deniable signature key exchange protocol following the conclusions in ^[Gun13b] - by identifying a secure key exchange protocol that satisfies our needs. We then apply the triple Diffie-Hellman authenticated exchange to grant it properties of deniability [Ma13]. Subsequently, one can apply the same approach presented in ^[Gun13b] to communicate ephemeral signature keys during the key establishment process. However, for efficiency, we use the same ephemeral Diffie-Hellman private and public values used to deniably authenticate users and generate secret shares to produce ephemeral signatures.

For the choice of the base authenticated key exchange protocol, we suggest a variant based on ^[ACMP10]. The rationale for the choice is laid out as follows:

• The base design of the protocol in ^[ACMP10] is the same as the base for ^[BVS05] (recommended by ^[Gun13a]). However, the protocol presented in ^[ACMP10] is simpler.
• ^[ACMP10] offers a peer-to-peer key exchange with no extra rounds, if needed.
• ^[BVS05] and ^[ACMP10] are superior to the widely studied ^[BCPQ01] and its dynamic variation ^[BCP01] both in security and performance ( rounds).
• ^[BVS05] has been suggested by ^[Gun13b] for the reason described in ^[Gun13a]. We believe that the new deniable authentication approach, as it is similar to the SKEME protocol, satisfies the properties of deniability which ^[BVS05] considered crucial aside from the cooperating judge.
• Security analysis of ^[GBNM11] and ^[BCGNP08] has found that ^[BVS05] is provably secure against all attacks (including the insider attacks) that the papers consider.
• It is a two-round protocol and hence offers competitive efficiency considering the security property that it provides.
• ^[ACMP10] only needs one round of key re-agreement in the case of a participant leaving the chat, while ^[BVS05] enforces re-computation of Diffie-Hellman ephemeral keys and hence needs a minimum of two rounds plus overhead of re-authenticating the new ephemeral keys. This can significantly improve the efficiency of casual chat sessions where participants frequently enter and exit the chat.
• Although the Schnorr based algorithm suggested in ^[BVS05] satisfies a more comprehensible deniable model, triple Diffie-Hellman authenticated key exchange only needs two rounds of communication and can be done alongside the key agreement steps, while the Schnorr based algorithm of ^[BVS05] needs four rounds.
• Although key exchange algorithms based on the standard model are considered theoretically more secure than those based on the random oracle model, there has been no proposal for a 2-round protocol in the standard model that promises forward secrecy. Therefore, due to the importance of usability and efficiency in our approach, we opted to for a ROM based protocol such as described by ^[BVS05] and ^[ACMP10].

VII.1a Sharing a secret among the group

All AGKE descriptions take the necessary steps to share a common secret confidentially among the group members along side other operations such as authentication and insuring partnership. To insure forward secrecy these methods mostly rely upon a P2P Deffie-Hellman key exchange. Most AGKE descriptions rely on sharing an equation and solving a specific linear system described in IX.4.

We abstract this step as GroupEnc/GroupDec primitive, to allow for alternative designs which do not interact with the rest of the protocol and might offer other benefits. For example the "Naive peer-to-peer" primitive IX.4 trades simplicity and generalizability (to a broadcast scheme c.f. Section VII.2) for bandwidth consumption.

VII.3 Message Authentication

As message authentication needs to be resistant to malicious insiders, following the outline of ^[GUVGC09], (n+1)sec signs each message using a public key signature scheme. The messages are signed with the ephemeral key of the sender. The authenticity of the origin can be verified by the public ephemeral key of the party distributed during the key exchange period.

VII.4 Transcript Ordering and Consistency

Since each message sent by any one participant is signed by the ephemeral private key generated for that specific session, it is not possible for the internal or external adversary to forge a message on behalf of an uncorrupted participant.

However, if the adversary is controlling the network structure, denial or delay of service is always possible. The consistency of the transcript (i.e. all participants see the same transcript in the same order) relies on the means of transport guaranteeing reliable delivery, with a single order, to every participant. In other words, we are verifying the reception of the message by the intended recipients.

By assuring transcript consistency, we also preventing from sending different messages to , while they believe they are seeing the same conversation. In absence of transcript consistency, when a central server is managing the chatroom, this attack requires to conspire with server, which is permeable in (n+1)sec threat model in accordance with the definition of transcript consistency in ^[GUVGC09].

The protocol offered in this document examines the transcript for such consistency. In the case that the underlying transport fails to provide this level of consistency, clearly the consistency test will fail. In this sense, failure of consistency does not distinguish between malicious activities or the absence of a reliable transport.

(n+1)sec performs transcript authentication whenever a message is received. This is to guarantee consistency and protect the protocol against the transcript consistency attack. The procedure is similar to the procedure described in ^[GUVGC09], with two major differences:

• We require additionally that message order be preserved for the following reasons:

1. XMPP, as the main protocol considered for this design, delivers messages to all clients in the same order.
2. The (n+1)sec protocol detects if the adversary has manipulated the order of the messages rather than only dropping undesirable messages
3. It is simpler to authenticate an ordered transcript compared to an unordered transcript.

• We also require that each participant updates all other participants about their view of the session transcript every time they send a message, along with requiring heartbeat, this ensures that participants are aware whether or not they are all seeing the same transcript during the session.

There are some cases where XMPP can fail our reliability assumption. In such cases, our consistency checks will fail. More advanced end-to-end recovery techniques are able to rescue such a scenario. We do not specify such techniques currently, though later versions of the protocol may rectify this.

Definitions and assumptions

Transport assumption: We assume the central server reliably delivers messages to everyone, including the original sender, in the same order.

Definition Each message M (sent after session S has been established) has an implicit server-sequence-number seqnum(M), a receive-parent: parent(M) (or recv-parent) the seqnum of last message the sender has received before sending M and a sender-sequence-number own-seqnum(M). We interchangeable use m when refering to both a message and its seqnum.

Once a message M with seqnum m is received by instance from the server (including participants own messages sent), a may be calculated recursively as follows:

(we define TrascriptChain[0] = (sk^S_i, sid_i))

A new message M contains p the seqnum of recv-parent of m, and own-seqnum(M).

• We say instance has accepted message m if it has been received by , then decrypted-verified.

• We say instances and have reached mutual consistency for message m if both accepted message m and have calculated the same hash of and verified .

• We say session S has reached consistency on message m, if all instances , and have reached mutual consistency.

Server order

All clients see the same message order from the server. All messages are sent to all users. Aside from the presence messages (messages which indicate a user is joining or leaving a chatroom or if they have been inactive for a long time) sent by the server, messages are sent by users.

All messages in a room have a unique sequence number (0, 1, ...). We assume that the server is unaware of sequence numbers (e.g. XMPP MUC); clients must allocate them implicitly when receiving messages.

In this section we present the (n+1)sec protocol in algorithmic format. All user IDs should be considered the modulo number of participants in the room.

Deniable authentication is derived from the Triple Diffie-Hellman algorithm presented in ^[Sys14]. Joining the room is a variation of the two-round mBD+P protocol presented in ^[ACMP10] where the authentication step has been made deniable. Leaving the room is the one-round mBD+S from ^[ACMP10]. In both cases, we have added a key confirmation round (round 3) as recommended by ^[ChMa10] to provide mutual authentication as defined in ^[GBNM11].

VIII.1 Schematic view of the key exchange

The protocol computes a unified session key for all participants. This imposes, in particular, the necessity that all ' is identical for all participants.However, as consistent view is part of (n+1)sec security model, it does not impose extra limitation on the protocol. For more information please see Appendix B: Participatory vs individually independent computation of group keys.

For simplicity, group operation is written multiplicatively (even though it is actually an elliptic curve point operation traditionally represented by addition).

Whenever our design deviates from ^[ACMP10], it is marked in yellow. We have abstracted out the steps mentioned in ^[ACMP10] as an independent primitive in pink, however the resulting computation is identical with the one in ^[ACMP10] protocol:

Algorithm 1

Round	Step	Description	Pseudo-code	Type
1	1	Generate ephemeral DH private key		Computation
	2	Generate DH key for BD, Triple DH and Signature		Computation
	3	Broadcast User identity and the DH key		Broadcast
2	4	Compute Session Id		Receive
	5	Generate Triple Diffie-Hellman P2P keys		Computation
	6	Generate key confirmations		Computation
	7	Generate secret shares		Computation
	8	Encrypt shares		Computation
	9	Sign identity, shares		Computation
	10	Broadcast encrypted shares and confirmation	)	Broadcast
3	11	Check the validity of key confirmation		Receive
	12	Check signatures		Computation
	13	Check Session Ids		Computation
	14	Generate session key		Computation
3	15	Broadcast session confirmation		Broadcast
-	16	Check the validity of session confirmation		Receive
	17	Check signatures		Computation

Triple Diffie-Hellman authentication

(n+1)sec uses a varient of Triple Diffie-Hellman (TDH) protocol also employed in Textsecure protocol ^[Mo13] to carry out mutual deniable authentication as well as peer-to-peer secret key exchange. It can be seen as a variation of [SoKi00] key exchange, however, unlike SoKi00], as it does not multiply all three DH secrets and therefore is not suspticble to attacks mentioned in ^[BoMa10].

By using TDH secret both in p2p key as well as in key confirmation step, (n+1)sec both implicitly and explicitly authenticate the peers.

In Algorithm 1, TDH and the original group key exchange from ^[ACMP10] has been combined to provide a deniable authenticated group key exchange. Here, we single out TDH Algorithm 1.1 for better presentation of the protocol for the reader. Note, that the users run step 5 differently based on their order in the group. This measure ensures that the P2P key is computed the same between two parties, i.e, .

Algorithm 1.1 Triple Diffie-Hellman between and assuming i < j

Round	Step	Description	Pseudo-code	Type
1	1	Generate ephemeral DH private key		Computation
	2	Generate ephemeral DH public key		Computation
	3	Broadcast User identity and the DH key		Broadcast
2	4	Receive other party id and ephemeral DH public key		Receive
	5	Generate Triple Diffie-Hellman P2P keys		Computation
	6	Send key confirmation to other party		Broadcast
-	7	Receive and Check the validity of key confirmation		Receive

GroupEnc and GroupDec functions

For the high level design of the protocol we do not specify the primitives for GroupEnc and GroupDec used in steps 8 and 14 of Alogrithm 1 as a part of the protocol, as we do not specifies the Hash function and the block cipher. We explain their property here. We choose a candidate in section IX.4.

The GroupEnc and GroupDec functions are primitives which are called collectively by all instances involved in the session and are supposed to satisfies the following goal:

Definition: Let and for each , let be a secret shared between and only between and . The goal of group is that:

1. Each member of group to generate and share a secret among the member of group G using public channel .
2. remains unknown for any eavesdropping the channel .

To this end each member compute and broadcast on . Later on when receives all . It recovers all secrets by computing .

(n+1)sec key exchange vs original Flexible Group Key Exchange of ^[ACMP10]

Although in higher level view of (n+1)sec we generalized the process of key exchange using GroupEnc/GroupDec abstraction, at lower level our choice of primitive for this functions make the group key computation processes of (n+1)sec and the original key exchange algorithm the same. Hence, the steps marked pink in Algorithm 1, only differ in from ^[ACMP10] but not in result.

(n+1)run a deniable mutual authentication protocol along side with the key exchange protocol, this results in communicating extra key confirmation data along side of other data exchanged during the course of running the protocol. As we will show in the proof, these data has effect on the usual run of the algorithm.

The only step that (n+1)sec runs differently compare to the original algorithm (beside generating extra data), is computation of mutual secret, between and . In original, algorithm it is simply . In (n+1)sec, it is the triple DH secret . We will prove that this change does not compromise any of the protocol proprieties.

The main difference between the two key exchange algorithms is in the key used for signature. In original algorithm, parties use their long term private key to sign their contribution, while in (n+1)sec they use their ephemeral keys. However, because the ephemeral keys has been authenticated before used for verification, we prove that the authenticity of signatures in both algorithms are equivalent under CDH assumption.

VIII.2 Chatroom Setup

In almost any practical case, participants join the chat sequentially. It is assumed that multiple participants cannot join simultaneously. For the sake of efficiency one can adjust the implementation to have a threshold time to wait and thus start a chat with more participants. However, this makes the implementation significantly more complicated without any evident efficiency benefit.

Therefore, our assumption is that a secure chat is always set up when a participant starts the chat room. Additional participants would be added sequentially using Algorithm VIII.3, as they enter the chat. Algorithm 1 describes the chat room setup protocol.

Algorithm 2

Description	Pseudo-code	Type
Generate ephemeral DH private key of the room initiator		Computation
Generate DH key for BD, Triple DH and Signature		Computation
Set participant list		Computation

VIII.3 Join

Joining a chat involves two different procedures: the Join procedure, described in Algorithm 2, which runs on the new participant’s instance, and an Accept New Participant Procedure, described in Algorithm 3, which runs on the clients of participants that are already in the chat.

When a new participant joins the chat, current participants can still use their established authenticated ephemeral public key (to derive the and as their signature verification key). Confidentiality of is guarded against the new participant by Diffie-Hellman key shares hashed alongside the session id (which is dependent on the list of participants). The new participant cannot combine the old and new shares to recover . The fact that old participants do not need to compute new ephemeral keys (and re-verify their ephemeral identities) decreases the computational complexity of the protocol.

The new participant needs to authenticate everybody already in the room and hand them their ephemeral key. All the parties already in the room only need to authenticate the new participant and need to send to them their ephemeral DH key. These procedures are described in Algorithm 3 and 4. After initial authentication step, all parties follow the same procedure to initiate a new session following Algorithm 5.

Authentication Step for new Joining party

Algorithm 3

Description	Pseudo-code	Type
Generate ephemeral DH private key		Computation
Generate DH key for BD, Triple DH and Signature		Computation
Broadcast User identity and the DH key		Broadcast
Receive other users' id/key		Receive
Generate Triple Diffie-Hellman P2P keys		Computation
Generate key confirmations		Computation

After this step joining user will proceed to "initiate new session" by Algorithm 5.

Authentication Step for parties in the room

For other participants to a accept a new participant only, the authentication step is different. After current participants authenticate the new user, they proceed to update session.

Algorithm 4

Description	Pseudo-code	Type
broadcast all user's identities		Broadcast
Receive other users' id/key and update participant list		Receive
Generate Triple Diffie-Hellman P2P key for the new participant		Computation
Generate key confirmations		Computation

After this step users will proceed to "initiate new session" using Algorithm 5.

Initiate new session

Algorithm 5

Description	Pseudo-code	Type
Compute Session Id		Computation
Cancel any pending request for establishing a session with the same Id	AxeNewSessionRequestTimer	Computation
Generate secret shares		Computation
Encrypt shares		Computation
Sign identity, shares		Computation
Broadcast key shares and confirmation (if any)		Broadcast
Receive other user(s)' key shares and confirmation of unauthenticated users or Time out	Wait to Receive ( for unauthenticated or Timeout by(2BROADCAST_LATENCY+INTERACTION_GRACE_INTERVAL, Drop inactive users, queue a new session request)	Receive
Check the validity of key confirmation of unauthenticated users	for unauthenticated	Computation
Check signatures	for j in {1,...,n}	Computation
Check Session Ids		Computation
Generate session key		Computation
Broadcast session confirmation		Broadcast
Check the validity of session confirmation		Receive
Check signatures		Computation
Initiate the TranscriptChain		Computation
Initiate the last_sender_seq_num array		Computation
Initiate the own_seq_num to 0		Computation

Sending and receiving messages while joining is in progress

In situations where a prolonged joining process (due to connection problems or malicious activities) has an adverse effect on the user experience, it might be desirable to enable that joining users can communicate with the parties in the room, while maintaining minimum assurances of authenticity, confidentiality, forward secrecy, as well as consistency only among participants.

Consistency aspects of (n+1)sec, both for the room view (plist) and for the transcript, are reached through group agreement. However, there are times when group agreement may be hard or impossible to reach either due to latency in a single participant's connection or due to a single participant broadcasting incorrect confirmation data (such as wrong plist, sid, key share, etc).

We offer an extension to the (n+1)sec protocol to tackle this problem during the joining process. When a new participant joins the room, they send their DH key shares to the other participants. The other participants send their ephemeral key in return. They then send their key confirmation and key share. If this extension is to be considered, as soon as each user receives a key confirmation from another user, who is not currently part of the session, (n+1)sec displays a message highlighting the fact that although the user is not part of the session part of the conversation (from users' who confirmed the new user's identity) is being shared with them (through P2P encryption using the key derived from DH Key). The protocol, however, does not honour their input in the consistency check until a new session including the new user is set up. Each client can decide whether to disable this option.

The user remains in the list of those not part of the current session, but receives the session messages until a new session is set up. Similarly, when a user receives a message from a user who is not part of the session, (n+1)sec will decrypt the message and display it with a disclaimer that the user is not yet part of the session and that some participants may not receive the same message.

This is less secure model in which a room is a forwardly secure authenticated communication channel while a session is a subset of the room, which additionally offers a consistent view of the room and consistent messages among participants. The detail of the process is depicted in Secthoin VIII.5

VIII.4 Leave

Leaving a chatroom involves a message from a leaving party indicating its intention to leave which, as with all other messages, contains the hash of TranscriptChain and one procedure for those who are staying in the chatroom (Procedure Farewell) which is described in Table ''(n+1)sec''#Leave.

Farewell

Run by exiting user.

Algorithm 6

Description	Pseudo-code	Type
Send farewell message	Send("Leaving!")	Broadcast
Wait to receive hashes of TranscriptChain or Timeout	Wait to Receive() or Timeout by((2 BROADCAST_LATENCY)+INTERACTION_GRACE_INTERVAL)	Receive

Shrink

When the remaining participants receive the farewell message they need to reply with the Hash of TranscriptChain of the last message seen by the leaving user. They also need to re-run the one round key update algorithm. However, they only need a notice from the server that the user is leaving to initiate a subsession excluding the leaving user.

Additionally, failure to receive a heartbeat from a user will result in executing Algorithm ''(n+1)sec''#Shrink excluding users who did not update their key.

Algorithm 7

Description	Pseudo-code	Type
Send Hash of TranscriptChain of last message seen by leaving user	Send()	Broadcast
Remove leaving user's id/key and update participant list		Computation

Users will proceed to "initiate new session" steps.

VIII.5 Secure Send and Receive

After the session key is established, participants will use Algorithms 5 and 6 to communicate securely.

On Send, the protocol checks the status of the new ephemeral Diffie-Hellman and key share using messages it receives from participants. It (re)sends any missing pieces. It also informs other participants which part of the key share has been received by the participant. This information is needed in order to enforce in-session forward secrecy. The metadata flag indicates if the message being sent only contains meta data (e.g. heartbeat) or actual user communication.

On Receive, the protocol updates who has seen which pieces of the key shares. The protocol also generates a new group key if the new key shares have been received from all participants. Those who have not updated their key shares eventually time out via their heartbeat interval.

Send

Algorithm 8

Description	Pseudo-code	Type
prepend session id and sender id		Computation
Generate new DH Key or new secret share if needed and append		Computation
Increment own sequence number		Computation
Append the hash of the TranscriptChain, up to the parent of the message being sent	(m, , , )	Computation
Generate a random nonce and append to the message		Computation
Sign the message and append the signature		Computation
Encrypt		Computation
Broadcast the message		Broadcast
Reset Heartbeat timeout timer	ResetHeartbeatTimer()	Computation
Set ACK timeout timer if the message has user content	False then ResetHeartbeatTimer()	Computation

Receive

Algorithm 9

Description	Pseudo-code	Type
Decrypt message		Computation
Check signature		Computation
Compute message sequence number	ComputeSeqNum(m)	Computation
Verify session id and transcript consistency and sender sequence number, issue a warning in case of failure	and and	Computation
Update TranscriptChain if possible		Computation
Update sender sequence number record		Computation
Update sender's ephemeral key or share secret		Computation
If all users' share are received, generate session key		Computation
Update ack timeout timer	AxeAckTimeoutTimer	Computation
Update rekey timeout timer	ResetRekeyTimeOut()	Computation
If the message has content set up ACK timer	then	Computation
return m	If then return m	Computation

Out of Session Send and Receive

Due to nature of the key exchange algorithm, (n+1)sec support confidential P2P communication. This in particular enables the user to share the conversation with joining user(s) who confirmed their identity to the user but have not established a session yet. It is worth mentioning that every session keeps a list future sessions to transition to this is equivalent to the list of confirmed but yet to join users. If the extension discussed in section VIII.3 is enabled it will make use of this list to implement the following changes:

• When a user send a message Extended Send is invoked instead, it sends the message to the session using Send but also to the prospective participants, using P2P Send.
• When a message is received, Extended Receive is called which check if the user has the correct key to decrypt the message. If the message is encrypted by session key and user has the session key then it calls the normal receive. If the message is encrypted by a p2p key that the user share, it calls P2P Receive. Otherwise, it simply ignores the message.

Algorithm 9.1 Extended Send

Algorithm 9.2 Extended Receive

Algorithm 9.3 P2P Send

Description	Pseudo-code	Type
Prepend key id and sender id		Computation
Generate a random nonce and append to the message		Computation
Sign the message and append the signature		Computation
Encrypt		Computation
Broadcast the message		Broadcast

Algorithm 9.4 P2P Receive

Description	Pseudo-code	Type
Decrypt message		Computation
Check signature		Computation
return m	return m	Computation

VIII.6 Reaching Consistency

The protocol provisions two procedures to reach consistency in different cases: (a) reaching consistency for arbitrary messages during the course of a conversation, and (b) reaching consistency when an instance leaves. Case (b) may be viewed as a special instance of case (a) plus the additional premise that must reach consistency as soon as possible (because they want to leave), and that they don't care about reaching consistency for any subsequent messages that they might receive after their final "farewell" message.

Reaching consistency for arbitrary messages during the course of a conversation:

Algorithm 10

Description	Pseudo-code	Type
Receive m with parent p from		Computation
Compare hash of TranscriptChain_j[p] with own value of it, issue a warning if it fails.		Computation
Compute TranscriptChain^S_i[m]		Computation

Case (b): when an instance wants to part, they send a "farewell" message m which contains .

• Everyone should include in their re-key message
• When reaches mutual consistency for p may leave or otherwise (if received hashes and their owns are non-matching) shows a warning.
  • won't have a chance to reach consistency for the messages receives after p

VIII.7 In-session Forward Secrecy

To ensure forward secrecy in long living chat sessions, (n+1)sec provides a session key update throughout the session. Each message sent to the session by each participant contains meta data described in #VIII.5.1 (n+1)sec Message Structure. Prior to sending any message, (n+1)sec determines the content of meta data, and piggy backs to that message according to the following algorithm:

Algorithm 10.1 Compute meta data

Description	Pseudo-code	Type
Initiate meta data with current state of knowledge of new ephemeral keys and secret shares	for all j in {1,...n}	Computation
Include the new ephemeral key if participant has not receive it	If meta_data \leftarrow	Computation
If (all) participants have sent their ephemeral keys compute the shared secret	If for all j in {1,...n}, then	Computation
Return meta data	return meta_data	Computation

VIII.8 Heartbeat and Timeout

Heartbeat is an empty message which contains only meta data. The meta data consists of information used to compute a new key and the most updated hash of transcript chain.

The protocol sends a heart beat only if the user has not sent any messages for a specific period of time.

The heartbeat is necessary to ensure three properties:

- Periodic transcript consistency check. - In session forward secrecy. - Freshness

To achieve these goals three time out periods are defined when heart beat sending is required. Additionally, we define an interval to model the latency in the underlying transport. These should be defined to cover common cases (e.g. 95th-percentile):

• ACK_GRACE_INTERVAL: When a receives a non-empty message it needs to inform the group about the transcript update no later than ACK_GRACE_INTERVAL time. Therefore if f does not send a message ACK_GRACE_INTERVAL seconds after receiving a non empty message, will send a heartbeat.

• REKEY_GRACE_INTERVAL, to ensure in session forward secrecy, the protocol requires that each updates their DH ephemeral key as well as group key. After a session is established or it was rekeyed, each needs to send its new DH ephemeral key no later than REKEY_GRACE_INTERVAL. Therefore if has not sent any message by that

period of time, it issues an empty message. Similarly after receiving all ephemeral keys from all participants, needs to send its secret for computation of new key no later than REKEY_GRACE_INTERVAL.

• INTERACTION_GRACE_INTERVAL, to ensure establishment of a session in timely manner, when immediate contribution of participants is required (for example sending key confirmation, contribution to the session secret), this values indicate that how long an active participants should wait till it decide to drop the non-contributing inactive participants from the participant list.

• BROADCAST_LATENCY: Modelling the amount of time which a message takes to reach the server and broadcast to the other clients. It should be based on the transport considered.

Failure to heartbeat and inactivity timers

Whenever, a message m is received a timer of (2*BROADCAST_LATENCY)+ACK_GRACE_INTERVAL) period is set. If the for a is received from all participants, the timer is cancelled. Otherwise at the time out, the protocol issues a local UI warning and cancel the warning if/when such a hash is received and is consistence among participants.

When a new session key is computed as well as when receives new ephemeral DH values from all users, a timer of (2*BROADCAST_LATENCY)+REKEY_GRACE_INTERVAL period is set. It is cancelled when all user contributions are received (ephemeral keys or session key secrets). Otherwise, the excludes users who failed to contribute from the exclude those users from the plist and call initiate new session. This measure is taken to ensure that users do not block in-session forward secrecy due to loss of connection or being under attack.

Timing out during an interactive session

(n+1)sec by design assumes the participants are trusted in being commited to the goal fo creating a secure chatroom. In this sense, (n+1)sec provide little defens against party which trying to sabotage a room by mounting various denial of service approaches. However, there are situation where a party is genuinely affected (by external adversary) or by connection problem. Under such assumption, situations we expect that all other parties, reach a consensus, that a participant has connectivity problem and agree on leave them out of the room.

Timeout sub protocol is designed to deal with such a situation. When a new session is requested (for join, leave, etc) each participant wait for (2*BROADCAST_LATENCY)+INTERACTION_GRACE_INTERVAL, they omit non-participating participants from the plist, and wait for PLIST_UPDATE_GRACE_INTERVAL. so other participants also reach to the same conclusion and updates their plists, then they initiate a new session.

Drop inactive users, queue a new session request

Algorithm 10.XX

Description	Pseudo-code	Type
Drop inactive users		Computation
Recompute Session Id		Computation
Set up timer to request a new session	SetTimer(PLIST_UPDATE_GRACE_INTERVAL, initiate new session)	Computation

When a participant receives a request for initiating new session, it checks their most current view of participant list (the one with eliminated timed out users) and if it matched then they go ahead with initiating the session, otherwise decline halt the request.

VIII.9 (n+1)sec Message Dictionary

All (n+1)sec messages have the following format

   :o3np1sec:Base64EnocodedMessage

The Base64EncodedMessage is decoded to sub data fields. There is no delimiter, the fields can be split based on the data size. We use commas (',') only for the purposes of readability in this document. The data types are described as follows.

Bytes (DTByte):

   1 byte unsigned value

Shorts (DTSHort):

   2 byte unsigned value, big-endian

Length (DTLength):

   4 byte unsigned value, big-endian

HashBlock (DTHash):

   32 byte data

Opaque variable-length data (DTOpaque):

   4 byte unsigned len, big-endian
   len byte data

All messages have mandatory version and message type fields:

version (DTShort), message type (DTShort), type-specific part

"version" is equal to 0001.

"message type" is chosen from the following list:

   UNKNOWN                     =0x00, //Invalid
   JOIN_REQUEST                =0x0a, //Session establishement
   PARTICIPANTS_INFO           =0x0b,
   JOINER_AUTH                 =0x0c,
   GROUP_SHARE                 =0x0d,
   SESSION_CONFIRMATION        =0x0e, //In session messages
   IN_SESSION_MESSAGE          =0x10,
   P2P_MESSAGE                 =0x20,

many messages use "participant id" which is defined as follows:

   participant nickname, participant fingerprint (DTHash)

participant nickname is a string. Its size can be determined by the length of the participant id - 32. The participant finger print is a 32bit representation of an ed25519 public key.

"participant info" is defined as

   participant id, ephemeral public key (DTHash), authenticated (DTByte)

From the point of view of the sender of the message the participant is authenticated if "authenticated" is 1. Unauthenticated if it is 0.

The following sections will describe the type-specific part for each type of messagee information about the joiner.

Join Request

   participant_info

where the following fields from participant_info submessage:

   participant id, ephemeral publick key (DTHash)

are representing the joiner's information. the

   authenticated (DTByte)

is kept only for compatibility with participant_info sub message structure and has no information value. It should be 1 as it represents the state of authentication of the joiner to itself. However, its value will be ignored by the current participants.

Participant Info

   session id (DTHash), session view (DTOpaque), key_confirmation(DTOpaque), sender's share(DTHash)

"session view" consists of

   participant0_info (DTOpeque), participant1_info (DTOpeque), ..., partcipantn_info(DTOpeque)

where "participant0,...,participantn" are all participants in the session (represented by session id).

"key confirmation" consists of a hash of a triple dh token between the sender and the joining participant and the "participant id" of the joining user.

the sender's share is computed as described in the algorithm.

Joiner Auth

   session id (DTHash), key_confirmation (DTOpeque), signature

"key confirmation" consists of a hash of a triple dh token between the sender and the joining participant and the "participant id" of the joining user.

Group Share

   session id (DTHash), sender share (DTHash), signature (DTHash)
     

Session Confirmation

   session id (DTHash), session confirmation (DTHash), next session ephemeral key (DTHash)

"session confirmation" is a hash(Session key|sender nickname), the next session ephemeral key is the 32 byte public key that the user is going to use in the next session.

(n+1)sec in session Message Structure

Every (n+1)sec message sent after establishment of a session has the following format:

   :o3np1sec:Base64EnocodedMessage

The message has the following structure.

    sid (DTHash), Encrypted part of the message, Signature (DTHashx2)

Encrypted message can be decrypted by the session key

   sender_index (DTLength), own_sender_id (DTLength), parent_id (DTLength), hash of TranscriptChain of the message (DTHash), nonce (DTHash), message load

"session ID" and the "sender_index" are prepended in part to address concerns of [Da01].

"own_sender_id" is the sequential id assigned to each message by its sender, used for transcript consistency check.

"parent_id" is the global sequential id of the last message seen by the sender before sending the message.

The message also includes the "hash of TranscriptChain" of the parent of the message as "additional authenticated data".

Note that we send the entry in the chain indexed by rather than . This is because a hash may only be calculated once the subject is actually received back from the server (i.e. gets a sequence number). This differs from some other concepts of "message ID" that may be calculated locally.

"nonce" is a random 128 bit value, appended to prevent any possibility of replay or brute force attack.

"message load" is a multi-field message and has the following structure:

   sub_message_type(DTShort)
   sub_message(DTOpeque) [Optional]

current sub message types are:

   USER_MESSAGE: 0001
   follewed by the plain text typed by user and handled to (n+1)sec by the chat client(DTOpaque)
   LEAVE_MESSAGE 0002
   followed by nothing.

   If there is no message load, then the message is just an ack, acknowledging receipt of other messages.

(n+1)sec P2P Message Structure

Every p2p (n+1)sec message sent after exchange of the ephemeral public keys has the following format.

   :o3np1sec:Base64EnocodedMessage

The Base64EncodedMessage is decoded as:

   version (DTShort), sid (DTHash), Encrypted part of the message, Signature (DTHashx2)
   keyid, Encrypted part of the message, Signature

Encrypted message can be decrypted by the p2p key and has the following structure

Signed Message consists of following parts

   keyid, sender id, received id, nonce, User message, 

The "Key ID" and the "sender ID" are prepended in part to address concerns of ^[Da02]. The nonce is a random 128 bit value, appended to prevent any possibility of replay or brute force attack.

User message is the plain text typed by user and handled to (n+1)sec by the chat client.

VIII.10 (n+1)sec Session Management and Message Handling

(n+1)sec secure conversations are modeled as chat sessions with proven cryptographic properties. A chat session starts with participants run the key agreement protocol and then agree and confirm a shared key.

However, the process on how a joining and leaving participants trigger a new chat sessions and how participants need to respond to multiple simultanous joins and leaves requests and the process of establishing multiple chat sessions is managed by (n+1)sec Session Management protocol.

This protocol is work in progress to deal with unresponsive participants and those who denial their response to bar the establishment of a session. This section explains the rules - based on which - (n+1)sec currently governs the order when multiple participants try to join or leave a session simultaneously.

Every participant in a chat room has either the status of a "joiner" or a "confirmed participant" of a (confirmed) session exclusively. Based on the user status and the message received, a specific subprotocol needs to be run by the user which is explained in the following sections.

FSM message handling: The basic rule is that if the message has a session id of a session that the user is part of, then message handling is governed by the finite state machine table described below. Otherwise, the messages should be handled as follows, for users of joiner or confirmed participant status:

Joiner

In current (n+1)sec implementation, this state is implemented as:

   user_in_room_state == JOINING
   

• Messages without session id (including JOIN_REQUEST): The Joiner, user in "JOINIG" state will ignores all messages without session id.

• If the message has a session id which the joiner has not constructed a session - the joiner will react as follows based on the typ of the message:

• • Participant Info:
    • If the joiner is mentioned in the participant list, the joiner construct a session with that list. The session will be at the state of JOIN_REQUESTED.
    • If the joiner is not mentioned in the plist, the joiner ignores the message (Suggestion: Should the joiner begins a session by appending itself to the list?).

• • Session Confirmation: The joiner will mark all its sessions as DEAD and wait for the new participant list (*** should joiner send a new join request?).

If the message has session id corresponding to a session that the joiner already constructed (and is in process of joining, i.e. is not DEAD), then the session FSM will deal with the message, as stated above.

Confirmed Participant

This state is indicated as follows in the current implementation of (n+1)sec:

   user_in_room_state == CURRENT_USER

The confirmed participant is a member of a unique session in state of IN_SESSION. This session is indicated as active_session. All messages participants sends to the room is going to such session. The participant also keeps an indicator named as next_in_activation_line. Both indicators are pointing to the active_session at the point when the active_session moves to IN_SESSION state.

• If the received message has a session id and the participant has constructed a session corresponding to that message. Then the FSM treats the message.

• If the received message has a session id, but the confirmed participant does not have a session is not part of the session then the participant will ignore the message, unless the message is of PARTICIPANT_INFO.

• If the received message is of PARTICIPANT_INFO for which, the user doesn't have corresponding session then the FSM of next_in_activation_line session will treat the session. For the definition of next_in_activation_line.

• If the received message does not have a session id, then it is a JOIN_REQUEST (otherwise marked as invalid). The FSM of next_in_activation_line will treat the session.

Session transition

Each confirmed participant (user_in_room_state == CURRENT_USER) keeps to indicators:

• active_session

The active_session is the only session which is in IN_SESSION state. A session state moves to IN_SESSION when the user receives session confirmation from all participants. In that case the previously active session state will be DEAD.

When a new session get activated, all STALE sessions gets refreshed. That is, all sessions which were requested to be created (due to join or leave) during the creation of the newly active session, will be recreated according to the new participant list. Further more, the next_in_activation_line also points to the newly activated session.

• next_in_activation_line

next_in_activation_line is the session which receives requests for new session (join/leave). When new session is activated it also become next_in_activation_line. When a new priority session is constructed it takes the next_in_activation_line pointer. If there is no priority session, then the first session which gets it share key generated becomes the next in activtion.

When a user leaves while another user trys to join, the leave protocol will take priority and a new participant info message is sent to the joining user after all leaving users have left. In this case, the session with leaving participant removed becomes the next_in_activation_line and all live sessions (not DEAD) (beside the active_session) will be marked as stale.

When multiple users are joining, when the confirmed participant receives the first joiner auth, it will halt the protocol for other joining users. That's the session will become the next_in_activation_line, and all live sessions (beside the active_session will bemarked as stale.

When the next_in_activation_line session is confirmed and moves to IN_SESSION, the active_session moves to DEAD state. For each stale session, a new participant info list will be generated of the union of the participant in new active session and the participant in the stale session bar the users which left during in process of active_session establishment. The participants info message will be sent to the remaining joining users.

Joining user (user_in_room_state == JOINING) does not keep any indicator.

Finite State Table

The sesseion finte state machine react based on the following table. A joiner will start a new session with JOIN_REQUESTED after it sends its join request.

If a message is received when there is no handler it will be ignored.

Explaniantion of the handlers

• authenticate and send share called by the joiner, computes authentication token with each of the participants and the user share of the session key and send a JOINER_AUTH Message. Beside generating share it acts like authenticate and store share.

• authenticate and store share

 validate the authentication token and store the sent share. If everybody is authenticated and all shares are received, compute the session key and the session confirmation and send of SESSION_CONFIRMATION message. In that case, the session state will be changed to GROUP_KEY GENERATED. Otherwise stays unchanged.

If the received PARTICIPANTS_INFO message does not corresponds to the session, it create a new session for that list in stale state. In that case, the state of the receiving session stays unchanged.

• confirm and may move session

it validate the session confirmation. If all the participant is confirmed the state will change to IN_SESSION. joiner become confirmed participant. Otherwise it does not change the state of the session.

• init a session with new user

When a confirmed participant receive this message start a new session with the joiner added to it. The state of new session will be RE_SHARED. it does not change the state of the session.

• init a stale session with new user

It creates a new session with the joiner added to it. The state of new session will be STALE. it does not change the state of the session.

IX.1 Hash Function

SHA256 is being used as the hash function and the random oracle. SHA256 provides a sufficiently secure hash primitive for the level of security provided by (n+1)sec and is widely implemented.

IX.2 Message Origin Authentication

ED25519 has been chosen as the signature primitive due to its efficiency and more secure implementability over other elliptic-curve digital signature algorithms. ^[Be11]

IX.3 Message Encryption

We are using AES-256 in Galois/Counter Mode (GCM) with a shared group key for message encryption, we are following the suggestion by the original OTR protocol of using counter mode. However, unlike OTR, does not support per message forgeability (although the whole transcript is forgeable), it is not prohibitive to use the same key for encryption and authentication.

The added authentication, spares P@P send and receive routines from using digital signature.

With GCM mode, the authenticated encryption is generically secure by the result (and assumptions) of ^[Kr00].

IX.4 GroupEnc and GroupDec Functions

The GroupEnc and GroupDec functions defined in Section VIII.1, facilitate the collective generation of a secret(s) shared by the group. Here we mention two examples of such functions, and specify the functions for (n+1)sec' protocol:

• Naive peer-to-peer GroupEnc/Dec:

The simplest path to design such primitives is to encrypt using the p2p encryption secret between each pair of participants:

• Linear System based GroupEnc/Dec:

Another possibility is that each user generates k linear equations of l variables such if the system of equations has m independent equations then m < l. The remaining equations should be generated using the mutual secrets .

An example of such a system is used by [BuDe95]. In which as follows:

Each user U_i generate equations (k_{i,i-1}+k_{i,i+1}=a_i) so the system for n equation variable will be:

Failed to parse (unknown function '\matrix'): \matrix{ x_1 + x_2 = a_1 \\ x_2+x_3= a_2 \\ \vdots \\ x_n + x_{n-1} = a_n \\}

Then each participant adds the equation of to the system and solves the derived system of -equation -unknown to recover the secrets.

in such a system:

(n+1)sec uses the modification of the primitive suggested in ^[ACMP10] to guard the confidentiality of the p2p and the subgroup keys:

While the naive peer to peer primitive is easier to understand and analyse, the second system gives the flexibility for the implementor to decide the trade off between the amount of data (number of equations) vs. the redundancy in the system (if some equations are not delivered the user can still compute a subset of secrets).

This document is the first public draft of the (n+1)sec protocol. We are genuinely hoping to receive a lot of feedback and review on this work and have chosen the wiki format to support Discussion. Ongoing tasks for the team include mathematical proofs of resistance to the adversarial model presented herein as well as technical implementation details. This is currently scheduled for the end of December, 2014. The np1sec software library will be initially implemented in Cryptocat and (with your help) further developed to suit a variety of use-cases in the near future.

The eQualit.ie team would like to give special thanks and note to the effort and dedication offered by Trevor Perrin and Ximin Luo to this project. They have been actively involved throughout the year and the result would not have been the same without their contribution. The team would also like to express thanks to Joseph Bonneau for his constructive comment and critisim to improve the protocol and its presentation. George Kadianakis for helping with the security proof and pointing out flaws and attack; Arlo Breault for his work on implementation of the protocol in the np1sec software library; David Goulet for valuable advice as well as continued assistance and support offered to the project; Prof. Payman Mohassel for his help and advice on the security model and the proof; Prof. Jermey Clark, Prof. Matthew Green and Frederic Jacobs for their constructive participation in the design debates; Prof. Mark Manulis for suggesting the GKA. eQualit.ie expresses gratitude to Nadim Kobeissi, Cryptocat founder and developer who initiated the project and for sharing his experience and giving advice on secure browser based chat. Last but not least we would like to thank the Open Technology Fund for supporting the project.

Appendix A: Asynchronous communication and Forward Secrecy

The protocol is primarily targeted to synchronous cases, however, with some modification it can be used for asynchronous cases.

Provided that the participants are not concerned with authenticating the list of participants (it is OK if Eve impersonates Bob as long as she is unable to read Bob’s messages). Participants can communicate using their pairwise exchanged ephemeral Diffie-Hellman keys until all participants finish the second round of authentication.

As soon as a deniable handshake has been established among a set of participants any subset of them can communicate and authenticate their messages using the “session key” and their ephemeral signature key.

The protocol does not enforce explicitly a time limit on renewing the session key shares and can be used for an asynchronous high latency transport after the key establishment state.

The downside of using a session key for a long time is that a compromised session key will reveal all past communication during that session. This does not pose an imminent threat when the life span of a chat is short. However, in the context of asynchronous high latency transport, it is a more serious concern.

The protocol requires the participants to pre-emptively update their ephemeral signature/shares and propagate them as part of the messages they are already sending. Subsequently, they also update their key share with their neighbours as soon as the neighbours also propagate their new ephemeral signature keys.

As the assumption of having a continuous heartbeat might not be realistic in various asynchronous cases, implementations can assume specific deadlines for dropping users who did not communicate their new keys or shares.

Appendix B: Other design possibilities

During the process of designing (n+1)sec we have considered and debated other design possibilities which we will describe in this section along side our arguments in favour of the choices made.

Group Key Scheme vs Broadcast Scheme

We say a group key scheme (as defined in Section V) is correct if all accepted instances of end up with the same participant lists and compute the same session id.

By contrast, a broadcast scheme refers to a scheme in which each participant is broadcasting a message to a set of participants of their choice from a set of potential participants. Each participant will have its own different which is able to broadcast as well. See GOTR by ^[LVH13] For an example of such scheme where each participant chooses there own circle of audiances.

Therefore, in the context of a chat room, broadcasting scheme participants do not have the same view of the room and consequently we cannot compute a unified session id based on the list of the participants (as opposed to the group key scheme). In a group key scheme, it is the name of the chat room plus a set of ephemeral keys and the set of ephemeral public keys which uniquely identifies the session. There are advantages and disadvantages to each of these schemes, which we enumerate here:

1. Chat room simulation: A group scheme simulates a normal chat room in the absence of an authentication adversary, where the participants all have the same view of who is in the chat room when they start talking. This is not the case in a broadcasting scheme as participants keep different participant lists. This is in conflict with the security assumptions of the authentication properties from the original proposal for (n+1)sec.
2. Consistency: In a group key exchange, the consistency of the participant list (and session id) is provided by the group key exchange protocol. In such a protocol, extra measures need to be taken only to assure the transcript's consistency, i.e. verification of the consistency of delivery and order of messages exchanged between participants. In a broadcast scheme, a new notion needs to be defined and enforced so that a minimum consistency of a conversation can be simulated. For example, as broadcasting to a subset of potential participants is allowed, the notion needs to deal with a situation in which A receives the DH public key of B but wants to send a message to the "room" before it receives the DH key of C.
3. Delayed join and leave: In a group scheme, until all participants confirm their identical view of a new participant list (due to a member joining or leaving the room), they need to assume the status quo. This might delay a new participant from joining a chat or, if no further measure is taken, enable a participant to deny join/leave for the whole group. While various mitigation methods are possible against such attacks (all summarized under the umbrella term "Denial of Service" ) they are not included in threat model considered in (n+1)sec protocol.

Based on the above differences, we selected a group key scheme for the proposed protocol. This is primarily because room consistency is one of the main security properties desired. However, when it is critical, the sub-protocol described by Section VIII.2 Sending and receiving messages while joining is in progress allows for communication with users while they are waiting for the join procedure to complete.

Participatory vs individually independent computation of group key(s)

Most AKGE offer some degree of contributiveness in computing the group secret. This roughly means that (at least in the absence of an insider) the group secret is derived using contribution from all members of the group. There has been criticism of the importance of this property such as in ^[Da14]. In this section we consider briefly the arguments for each side and describe the rational for our choice.