From 6d80d934cd3727f2fec320e722124562ffb7dd21 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Wed, 28 Sep 2016 18:49:56 +0100 Subject: typo --- docs/megolm.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/megolm.rst b/docs/megolm.rst index 7853963..2ea0b94 100644 --- a/docs/megolm.rst +++ b/docs/megolm.rst @@ -27,7 +27,7 @@ The Megolm ratchet is intended for encrypted messaging applications where there may be a large number of recipients of each message, thus precluding the use of peer-to-peer encryption systems such as `Olm`_. -It also allows a receipient to decrypt received messages multiple times. For +It also allows a recipient to decrypt received messages multiple times. For instance, in client/server applications, a copy of the ciphertext can be stored on the (untrusted) server, while the client need only store the session keys. -- cgit v1.2.3 From 63800ad8e61ebdfa756d8bde8466b70337b85d67 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Sun, 2 Oct 2016 00:47:29 +0100 Subject: s/PCKS/PKCS/ --- docs/megolm.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs') diff --git a/docs/megolm.rst b/docs/megolm.rst index 2ea0b94..1f04840 100644 --- a/docs/megolm.rst +++ b/docs/megolm.rst @@ -143,7 +143,7 @@ copy of the counter, ratchet, and public key. Message encryption ~~~~~~~~~~~~~~~~~~ -This version of Megolm uses AES-256_ in CBC_ mode with `PCKS#7`_ padding and +This version of Megolm uses AES-256_ in CBC_ mode with `PKCS#7`_ padding and HMAC-SHA-256_ (truncated to 64 bits). The 256 bit AES key, 256 bit HMAC key, and 128 bit AES IV are derived from the megolm ratchet :math:`R_i`: @@ -285,6 +285,6 @@ Version 2.0 `_. .. _`SHA-256`: https://tools.ietf.org/html/rfc6234 .. _`AES-256`: http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf .. _`CBC`: http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf -.. _`PCKS#7`: https://tools.ietf.org/html/rfc2315 +.. _`PKCS#7`: https://tools.ietf.org/html/rfc2315 .. _`Olm`: ./olm.html .. _`Protocol Buffers encoding`: https://developers.google.com/protocol-buffers/docs/encoding -- cgit v1.2.3 From 68ec41f8ca731b8e9335dbfd691b8339f030ee4d Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Sun, 2 Oct 2016 00:48:06 +0100 Subject: s/PCKS/PKCS/ --- docs/olm.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs') diff --git a/docs/olm.rst b/docs/olm.rst index 99417e0..af42215 100644 --- a/docs/olm.rst +++ b/docs/olm.rst @@ -279,7 +279,7 @@ Olm Authenticated Encryption Version 1 ~~~~~~~~~ -Version 1 of Olm uses AES-256_ in CBC_ mode with `PCKS#7`_ padding for +Version 1 of Olm uses AES-256_ in CBC_ mode with `PKCS#7`_ padding for encryption and HMAC-SHA-256_ (truncated to 64 bits) for authentication. The 256 bit AES key, 256 bit HMAC key, and 128 bit AES IV are derived from the message key using HKDF-SHA-256_ using the default salt and an info of @@ -323,4 +323,4 @@ an entirely new implementation written by the Matrix.org team. .. _`SHA-256`: https://tools.ietf.org/html/rfc6234 .. _`AES-256`: http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf .. _`CBC`: http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf -.. _`PCKS#7`: https://tools.ietf.org/html/rfc2315 +.. _`PKCS#7`: https://tools.ietf.org/html/rfc2315 -- cgit v1.2.3 From d48dc8197680dce2bb810c5714f17d1a35dcb3d0 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Wed, 19 Oct 2016 17:27:24 +0100 Subject: Document the unknown key-share attacks and mitigation (#29) --- docs/olm.rst | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) (limited to 'docs') diff --git a/docs/olm.rst b/docs/olm.rst index af42215..34bf9ba 100644 --- a/docs/olm.rst +++ b/docs/olm.rst @@ -298,6 +298,37 @@ and the IV :math:`AES\_IV_{i,j}` to give the cipher-text, :math:`X_{i,j}`. Then the entire message (including the Version Byte and all Payload Bytes) are passed through HMAC-SHA-256. The first 8 bytes of the MAC are appended to the message. +Message authentication concerns +------------------------------- + +To avoid unknown key-share attacks, the application must include identifying +data for the sending and receiving user in the plain-text of (at least) the +pre-key messages. Such data could be a user ID, a telephone number; +alternatively it could be the public part of a keypair which the relevant user +has proven ownership of. + +.. admonition:: Example attacks + + 1. Alice publishes her public Curve25519 identity key, :math:`I_A`. Eve + publishes the same identity key, claiming it as her own. Bob downloads + Eve's keys, and associates :math:`I_A` with Eve. Alice sends a message to + Bob; Eve intercepts it before forwarding it to Bob. Bob believes the + message came from Eve rather than Alice. + + This is prevented if Alice includes her user ID in the plain-text of the + pre-key message, so that Bob can see that the message was sent by Alice + originally. + + 2. Bob publishes his public Curve25519 identity key, :math:`I_B`. Eve + publishes the same identity key, claiming it as her own. Alice downloads + Eve's keys, and associates :math:`I_B` with Eve. Alice sends a message to + Eve; Eve cannot decrypt it, but forwards it to Bob. Bob believes the + Alice sent the message to him, wheras Alice intended it to go to Eve. + + This is prevented by Alice including the user ID of the intended recpient + (Eve) in the plain-text of the pre-key message. Bob can now tell that the + message was meant for Eve rather than him. + IPR --- -- cgit v1.2.3 From df04cd509a13fb1a3c8b953de4f987b15fcde9b1 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Wed, 19 Oct 2016 19:16:23 +0100 Subject: Add notes on limitations to megolm spec --- docs/megolm.rst | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 65 insertions(+), 4 deletions(-) (limited to 'docs') diff --git a/docs/megolm.rst b/docs/megolm.rst index 1f04840..4929349 100644 --- a/docs/megolm.rst +++ b/docs/megolm.rst @@ -199,9 +199,9 @@ session. In order to maintain the ability to decrypt conversation history, inbound sessions should store a copy of their earliest known ratchet value (unless they -explicitly want to drop the ability to decrypt that history). They may also -choose to cache calculated ratchet values, but the decision of which ratchet -states to cache is left to the application. +explicitly want to drop the ability to decrypt that history - see `Partial +Forward Secrecy`_\ ). They may also choose to cache calculated ratchet values, +but the decision of which ratchet states to cache is left to the application. Data exchange formats --------------------- @@ -269,7 +269,68 @@ protocol). The MAC protects all of the bytes preceding the MAC. The length of the signature is determined by the signing algorithm being used (64 bytes in this version of the protocol). The signature covers all of the -bytes preceding the signaure. +bytes preceding the signature. + +Limitations +----------- + +Lack of Transcript Consistency +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In a group conversation, there is no guarantee that all recipients have +received the same messages. For example, if Alice is in a conversation with Bob +and Charlie, she could send different messages to Bob and Charlie, or could +send some messages to Bob but not Charlie, or vice versa. + +Solving this is, in general, a hard problem, particularly in a protocol which +does not guarantee in-order message delivery. For now it remains the subject of +future research. + +Lack of Backward Secrecy +~~~~~~~~~~~~~~~~~~~~~~~~ + +Once the key to a Megolm session is compromised, the attacker can decrypt any +future messages sent via that session. + +In order to mitigate this, the application should ensure that Megolm sessions +are not used indefinitely. Instead it should periodically start a new session, +with new keys shared over a secure channel. + +.. TODO: Can we recommend sensible lifetimes for Megolm sessions? Probably + depends how paranoid we're feeling, but some guidelines might be useful. + +Partial Forward Secrecy +~~~~~~~~~~~~~~~~~~~~~~~ + +Each recipient maintains a record of the ratchet value which allows them to +decrypt any messages sent in the session after the corresponding point in the +conversation. If this value is compromised, an attacker can similarly decrypt +those past messages. + +To mitigate this issue, the application should offer the user the option to +discard historical conversations, by winding forward any stored ratchet values, +or discarding sessions altogether. + +Dependency on secure channel for key exchange +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The design of the Megolm ratchet relies on the availability of a secure +peer-to-peer channel for the exchange of session keys. Any vulnerabilities in +the underlying channel are likely to be amplified when applied to Megolm +session setup. + +For example, if the peer-to-peer channel is vulnerable to an unknown key-share +attack, the entire Megolm session become similarly vulnerable. For example: +Alice starts a group chat with Eve, and shares the session keys with Eve. Eve +uses the unknown key-share attack to forward the session keys to Bob, who +believes Alice is starting the session with him. Eve then forwards messages +from the Megolm session to Bob, who again believes they are coming from +Alice. Provided the peer-to-peer channel is not vulnerable to this attack, Bob +will realise that the key-sharing message was forwarded by Eve, and can treat +the Megolm session as a forgery. + +A second example: if the peer-to-peer channel is vulnerable to a replay +attack, this can be extended to entire Megolm sessions. License ------- -- cgit v1.2.3 From 5f1b93bd0fa06a603d5d4a88af71bef7fd5143fb Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Wed, 19 Oct 2016 19:18:58 +0100 Subject: s/ephemeral/one-time/ in olm spec We're standardising on 'one-time keys' as a term for the thing that Bob uploads for prekey messages. --- docs/olm.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/olm.rst b/docs/olm.rst index 34bf9ba..093cb47 100644 --- a/docs/olm.rst +++ b/docs/olm.rst @@ -30,7 +30,7 @@ Initial setup ~~~~~~~~~~~~~ The setup takes four Curve25519_ inputs: Identity keys for Alice and Bob, -:math:`I_A` and :math:`I_B`, and ephemeral keys for Alice and Bob, +:math:`I_A` and :math:`I_B`, and one-time keys for Alice and Bob, :math:`E_A` and :math:`E_B`. A shared secret, :math:`S`, is generated using `Triple Diffie-Hellman`_. The initial 256 bit root key, :math:`R_0`, and 256 bit chain key, :math:`C_{0,0}`, are derived from the shared secret using an -- cgit v1.2.3 From 8c4a11a92d2eac501e06659dff062d84d5c855ec Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Fri, 21 Oct 2016 15:13:20 +0100 Subject: Document the potential for message replays and possible mitigations --- docs/megolm.rst | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'docs') diff --git a/docs/megolm.rst b/docs/megolm.rst index 4929349..56e5f1d 100644 --- a/docs/megolm.rst +++ b/docs/megolm.rst @@ -274,6 +274,16 @@ bytes preceding the signature. Limitations ----------- +Message Replays +--------------- + +A message can be decrypted successfully multiple times. This means that a MITM +server can send multiple copies of a message and they will successfully decrypt. + +To mitigate this it is recomendend that applications track the message indicies +they have recieved and that they reject messages with indicies that they've +already decrypted. + Lack of Transcript Consistency ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- cgit v1.2.3 From 0a7d4e35ccee89c34adeb03b112d243a27326fda Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Fri, 21 Oct 2016 15:44:53 +0100 Subject: Reword and s/message index/ratchet index/ --- docs/megolm.rst | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) (limited to 'docs') diff --git a/docs/megolm.rst b/docs/megolm.rst index 56e5f1d..0994100 100644 --- a/docs/megolm.rst +++ b/docs/megolm.rst @@ -277,12 +277,13 @@ Limitations Message Replays --------------- -A message can be decrypted successfully multiple times. This means that a MITM -server can send multiple copies of a message and they will successfully decrypt. +A message can be decrypted successfully multiple times. This means that an +attacker can re-send a copy of an old message, and the recipient will treat it +as a new message. -To mitigate this it is recomendend that applications track the message indicies -they have recieved and that they reject messages with indicies that they've -already decrypted. +To mitigate this it is recomendend that applications track the ratchet indicies +they have recieved and that they reject messages with a ratchet index that +they've already decrypted. Lack of Transcript Consistency ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- cgit v1.2.3 From 092bf880f5adaf9897b1c869b67f6d9c5284eda5 Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Fri, 21 Oct 2016 15:45:33 +0100 Subject: s/they've/they have/ --- docs/megolm.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/megolm.rst b/docs/megolm.rst index 0994100..dce64d7 100644 --- a/docs/megolm.rst +++ b/docs/megolm.rst @@ -283,7 +283,7 @@ as a new message. To mitigate this it is recomendend that applications track the ratchet indicies they have recieved and that they reject messages with a ratchet index that -they've already decrypted. +they have already decrypted. Lack of Transcript Consistency ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- cgit v1.2.3 From 884ad02413e334473a338986c2291a717defb662 Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Fri, 21 Oct 2016 17:07:26 +0100 Subject: Spelling --- docs/megolm.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs') diff --git a/docs/megolm.rst b/docs/megolm.rst index dce64d7..03ee426 100644 --- a/docs/megolm.rst +++ b/docs/megolm.rst @@ -281,8 +281,8 @@ A message can be decrypted successfully multiple times. This means that an attacker can re-send a copy of an old message, and the recipient will treat it as a new message. -To mitigate this it is recomendend that applications track the ratchet indicies -they have recieved and that they reject messages with a ratchet index that +To mitigate this it is recommended that applications track the ratchet indices +they have received and that they reject messages with a ratchet index that they have already decrypted. Lack of Transcript Consistency -- cgit v1.2.3 From 807fec2ebfa8b33fa75d51a795b9663f0d26fa5c Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Mon, 24 Oct 2016 15:17:27 +0100 Subject: double_ratchet.svg --- docs/double_ratchet.svg | 1007 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1007 insertions(+) create mode 100644 docs/double_ratchet.svg (limited to 'docs') diff --git a/docs/double_ratchet.svg b/docs/double_ratchet.svg new file mode 100644 index 0000000..26ee8c3 --- /dev/null +++ b/docs/double_ratchet.svg @@ -0,0 +1,1007 @@ + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + Initial Shared Secret + + + + + + + Secret + + HKDF + + + Root Key + + + + Chain Key + + + + Info + + "OLM_ROOT" + + + + Salt + + "" + + + + + + + Key + + + + Data + + HMAC + + + Chain Key + + "\x02" + + + + + + "\x01" + + + + + Key + + + + Data + + HMAC + + + Message Key + + + + + + + Secret + + + + + Salt + + "" + + + + Info + + "OLM_KEYS" + + HKDF + + + Cipher Key + + + + Mac Key + + + + IV + + + + + + + + + + Secret + + HKDF + + + Root Key + + + + Chain Key + + + + Info + + "OLM_RATCHET" + + + + Salt + + + + + + Alice's Chain + Bob's Chain + + + + + + Bob's Key + + + + Alice's Key + + ECDH + + + Shared Secret + + + -- cgit v1.2.3 From 05b48086a4918b2cb4b23ffbabef564555131186 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Mon, 24 Oct 2016 15:52:05 +0100 Subject: remove redundant svg --- docs/Axolotl.svg | 1007 ------------------------------------------------------ 1 file changed, 1007 deletions(-) delete mode 100644 docs/Axolotl.svg (limited to 'docs') diff --git a/docs/Axolotl.svg b/docs/Axolotl.svg deleted file mode 100644 index 26ee8c3..0000000 --- a/docs/Axolotl.svg +++ /dev/null @@ -1,1007 +0,0 @@ - - - - - - - - - - - - - - image/svg+xml - - - - - - - - - Initial Shared Secret - - - - - - - Secret - - HKDF - - - Root Key - - - - Chain Key - - - - Info - - "OLM_ROOT" - - - - Salt - - "" - - - - - - - Key - - - - Data - - HMAC - - - Chain Key - - "\x02" - - - - - - "\x01" - - - - - Key - - - - Data - - HMAC - - - Message Key - - - - - - - Secret - - - - - Salt - - "" - - - - Info - - "OLM_KEYS" - - HKDF - - - Cipher Key - - - - Mac Key - - - - IV - - - - - - - - - - Secret - - HKDF - - - Root Key - - - - Chain Key - - - - Info - - "OLM_RATCHET" - - - - Salt - - - - - - Alice's Chain - Bob's Chain - - - - - - Bob's Key - - - - Alice's Key - - ECDH - - - Shared Secret - - - -- cgit v1.2.3 From f6c05be8c5d35e725a8a2ed5ad661398ac9f8cd2 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Thu, 27 Oct 2016 11:53:55 +0100 Subject: Add a document on signing keys --- docs/signing.rst | 118 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 118 insertions(+) create mode 100644 docs/signing.rst (limited to 'docs') diff --git a/docs/signing.rst b/docs/signing.rst new file mode 100644 index 0000000..7387794 --- /dev/null +++ b/docs/signing.rst @@ -0,0 +1,118 @@ +.. Copyright 2016 OpenMarket Ltd +.. +.. Licensed under the Apache License, Version 2.0 (the "License"); +.. you may not use this file except in compliance with the License. +.. You may obtain a copy of the License at +.. +.. http://www.apache.org/licenses/LICENSE-2.0 +.. +.. Unless required by applicable law or agreed to in writing, software +.. distributed under the License is distributed on an "AS IS" BASIS, +.. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +.. See the License for the specific language governing permissions and +.. limitations under the License. + + +Signature keys and user identity in libolm +========================================== + +The use of any public-key based cryptography system such as Olm presents the +need for our users Alice and Bob to verify that they are in fact communicating +with each other, rather than a man-in-the-middle. Typically this requires an +out-of-band process in which Alice and Bob verify that they have the correct +public keys for each other. For example, this might be done via physical +presence or via a voice call. + +In the basic `Olm `_ protocol, it is sufficient to compare the public +Curve25519 identity keys. As a naive example, Alice would meet Bob and ensure +that the identity key she downloaded from the key server matched that shown by +his device. This prevents the eavesdropper Eve from decrypting any messages +sent from Alice to Bob, or from masquerading as Bob to send messages to Alice: +she has neither Alice's nor Bob's private identity key, so cannot successfully +complete the triple-DH calculation to compute the shared secret, :math:`S`, +which in turn prevents her decrypting intercepted messages, or from creating +new messages with valid MACs. Obviously, for protection to be complete, Bob +must similarly verify Alice's key. + +However, the use of the Curve25519 key as the "fingerprint" in this way makes +it difficult to carry out signing operations. For instance, it may be useful to +cross-sign identity keys for different devices, or, as discussed below, to sign +one-time keys. Curve25519 keys are intended for use in DH calculations, and +their use to calculate signatures is non-trivial. + +The solution adopted in this library is to generate a signing key for each +user. This is an `Ed25519`_ keypair, which is used to calculate a signature on +an object including both the public Ed25519 signing key and the public +Curve25519 identity key. It is then the **public Ed25519 signing key** which is +used as the device fingerprint which Alice and Bob verify with each other. + +By verifying the signatures on the key object, Alice and Bob then get the same +level of assurance about the ownership of the Curve25519 identity keys as if +they had compared those directly. + +Signing one-time keys +--------------------- + +The Olm protocol requires users to publish a set of one-time keys to a key +server. To establish an Olm session, the originator downloads a key for the +recipient from this server. The decision of whether to sign these one-time keys +is left to the application. There are both advantages and disadvantages to +doing so. + +Consider the scenario where one-time keys are unsigned. Alice wants to initiate +an Olm session with Bob. Bob uploads his one-time keys, :math:`E_B`, but Eve +replaces them with ones she controls, :math:`E_E`. Alice downloads one of the +compromised keys, and sends a pre-key message using a shared secret :math:`S`, +where: + +.. math:: + S = ECDH\left(I_A,\,E_E\right)\;\parallel\;ECDH\left(E_A,\,I_B\right)\; + \parallel\;ECDH\left(E_A,\,E_E\right) + +Eve cannot decrypt the message because she does not have the private parts of +either :math:`E_A` nor :math:`I_B`, so cannot calculate +:math:`ECDH\left(E_A,\,I_B\right)`. However, suppose she later compromises +Bob's identity key :math:`I_B`. This would give her the ability to decrypt any +pre-key messages sent to Bob using the compromised one-time keys, and is thus a +problematic loss of forward secrecy. If Bob signs his keys with his Ed25519 +signing key (and Alice verifies the signature before using them), this problem +is avoided. + +On the other hand, signing the one-time keys leads to a reduction in +deniability. Recall that the shared secret is calculated as follows: + +.. math:: + S = ECDH\left(I_A,\,E_B\right)\;\parallel\;ECDH\left(E_A,\,I_B\right)\; + \parallel\;ECDH\left(E_A,\,E_B\right) + +If keys are unsigned, a forger can make up values of :math:`E_A` and +:math:`E_B`, and construct a transcript of a conversation which looks like it +was between Alice and Bob. Alice and Bob can therefore plausibly deny their +partition in any conversation even if they are both forced to divulge their +private identity keys, since it is impossible to prove that the transcript was +a conversation between the two of them, rather than constructed by a forger. + +If :math:`E_B` is signed, it is no longer possible to construct arbitrary +transcripts. Given a transcript and Alice and Bob's identity keys, we can now +show that at least one of Alice or Bob was involved in the conversation, +because the ability to calculate :math:`ECDH\left(I_A,\,E_B\right)` requires +knowledge of the private parts of either :math:`I_A` (proving Alice's +involvement) or :math:`E_B` (proving Bob's involvement, via the +signature). Note that it remains impossible to show that *both* Alice and Bob +were involved. + +In conclusion, applications should consider whether to sign one-time keys based +on the trade-off between forward secrecy and deniability. + +License +------- + +This document is licensed under the `Apache License, Version 2.0 +`_. + +Feedback +-------- + +Questions and feedback can be sent to richard at matrix.org. + +.. _`Ed25519`: http://ed25519.cr.yp.to/ -- cgit v1.2.3