Changes
change the message structure, added nuance, changed transcript consistency, add own_seq_num and check, still need work
[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].
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 XMPP 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.
* <span>'''Forward secrecy'''</span> 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.
* <span>'''Room consistency'''</span>, 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.
* <span>'''Transcript consistency'''</span>, where all participants are confident that they have been participating in the same conversation; as the conversation continues, they are confident that they have seen 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 [[#Design_rationale|Section III]]. The next section will introduce formal definitions covering these elements.
==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'' <math>\mathcal{A}_{cons}</math> is given the ability to invoke all functions in sections [[''(n+1)sec''#Adversarial_power|IV.1.1.1]] and [[''(n+1)sec''#Adversarial_power|IV.1.1.3]]. We say the protocol is secure against ''Consensus Adversary'' if at least two uncorrupted accepted instances <math>\Pi^S_i, \Pi^S_j</math> possess the transcripts chain <math>TransChain_{\Pi^S_i}(l) \neq TransChain_{\Pi^S_j}(l)</math> and they believe they have the <math>TransChain_{\Pi^S_i}(l) = TransChain_{Pi^S_j}(l) with non-negligible probability.
# <span>'''Deniable authenticated signature key and session key exchange'''</span>, where participants deniably authenticate each other and agree on session key(s), while also exchanging ephemeral signing keys
# <span>'''Communication'''</span>, where parties send authenticated confidential messages
# <span>'''Transcript consistency verification'''</span>, where parties verify that all have received and seen an identical transcript in the same order, since the start of the chat sessionafter 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.
After the session key is established, participants will use Algorithms [[''(n+1)sec''#Send|5]] and [[''(n+1)sec''#Receive|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 need inorder 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(n+1)sec Message structure=== Every (n+1)sec message sent after establishment of a session has the following format: np1sec:3Base64EnocodedMessage:3 The Base64EncodedMessage is decoded as: sid, Encrypted part of the message Encrypted message can be decrypted by the session key and has the following structure Signed message, Signature corresponding to the signed message Signed Message consists of following parts sid, sender ID, User message, meta message, hash of TranscriptChain of the message, naunce The "session ID" and the "sender ID" are prepended in part to address concerns of [Da01]. The nuance 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. meta message contains a message has the following format ustate_1, ..., ustate_n, current_load ustate_i flag ={=0 sender has no key update from U_i, =1 sender has received a new ephemeral key from U_i, =2 user has received secret share from U_i} current_loadload_flag, load load_flag = 0 no loadload_flag = 1 load contains new ephemeral public key from senderload_flag = 2 load contains new secret share from the sender
<math>H(H(parent(m)), H(TransciptChain[parent(m)-1])))</math>
Note that we defined <math>H(parent(m))</math> rather than <math>H(m)</math>. 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.
====Send====
'''Algorithm 8'''
!align="center"|Pseudo-code
!align="center"|Type
|-
|align="right" | prepend session id and sender id
|align="center"|<math> m \leftarrow (sid, U_i, m) </math>
|align="center"|Computation
|-
|align="right"| Generate new DH Key or new secret share if needed and append
|align="center"|<math> m \leftarrow (sidm, s,m) </math>|align="center"|Computation|-|align="right"| Increment own sequence number|align="center"|<math> own_seq_num \leftarrow own_seq_num+1 </math>
|align="center"|Computation
|-
|align="right"| Append the hash of the TranscriptChain, up to the parent of the message being sent
|align="center"|<math> m \leftarrow (m, H(H(parent(m)), H(TransciptChain^S_i[parent(m)-1])), parent\_id(m)), own_seq_num) </math>
|align="center"|Computation
|-
|align="right" |Generate a random nuance and append to the message|align="center"|<math> m \leftarrow (m, rand(128bit)) </math>|align="center"|Computation|-|align="right"| Sign the messageand append the signature|align="center"|<math>\sigma m \leftarrow (m, Sign_{x_i}(m))</math>
|align="center"|Computation
|-
|-
|align="right"| Broadcast the message
|align="center"|<math>(sid_i, e, \sigma)</math>
|align="center"|Broadcast
|}
!align="center"|Pseudo-code
!align="center"|Type
|-
|align="right"| Decrypt message
|align="center"|<math> sid_{rec}, sender_id, m, s, h, parent\_id, \sender_seq_num, sigma \leftarrow Dec_k(m) </math>
|align="center"|Computation
|-
|align="right"| Check signature
|align="center"|<math> VerifyVerify_{sender_id}(m,\sigma) </math>|align="center"|Computation|-|align="right"| Compute message sequence number|align="center"|<math> seqnum(m) \leftarrow ComputeSeqNum(m) </math>
|align="center"|Computation
|-
|align="right"| Update TranscriptChainVerify session id and transcript consistency and sender sequence number, issue a warning in case of failure|align="center"|<math> Insertsid_i \stackrel{?}{=} sid_{rec} \; \textrm{and} \; h \stackrel{?}{=} H(H(parent(m)), H(TranscriptChain^S, S_i[parent(m) -1])) \textrm{and} sender_seq_num \stackrel{?}{>} last_own_seq_nums[sender_id] </math>
|align="center"|Computation
|-
|align="right"| decrypt messageUpdate TranscriptChain if possible|align="center"|<math> sid_{rec}, s, TranscriptChain^S_i[seqnum(m)] = (H(m), h, parent\_id \leftarrow Dec_kH(TranscriptChain^S_i[seqnum(m)-1])) </math>
|align="center"|Computation
|-
|align="right"| Verify session id and transcript consistency, issue a warning in case of failureUpdate sender sequence number record|align="center"|<math> sid_i \stackrel{?}{=} sid_{rec} \; \textrm{and} \; h \stackrel{?}{=} (H(parent(m)), TranscriptChain^S_ilast_own_seq_nums[parent(m)-1sender_id]) \leftarrow sender_seq_num </math>
|align="center"|Computation
|-
|-
|align="right"| Compare hash of TranscriptChain_j[p] with own value of it, issue a warning if it fails.
|align="center"|<math>H(TranscriptChain^S_j[p]) \stackrel{?}{== } H(TranscriptChain^S_i[p])</math> for all <math>U_k \in plist^S_i</math>
|align="center"|Computation
|-
