Merge remote-tracking branch 'origin/master' into pedroc/android_e2e_dev

4 files changed, 231 insertions, 10 deletions

diff --git a/docs/Axolotl.svg b/docs/double_ratchet.svg
index 26ee8c3..26ee8c3 100644
--- a/docs/Axolotl.svg
+++ b/docs/double_ratchet.svg
diff --git a/docs/megolm.rst b/docs/megolm.rst
index 7853963..03ee426 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.
 
@@ -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`:
 
@@ -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,79 @@ 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
+-----------
+
+Message Replays
+---------------
+
+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 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
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+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
 -------
@@ -285,6 +357,6 @@ Version 2.0 <http://www.apache.org/licenses/LICENSE-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
diff --git a/docs/olm.rst b/docs/olm.rst
index 99417e0..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
@@ -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
@@ -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
 ---
 
@@ -323,4 +354,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
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 <olm.html>`_ 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
+<http://www.apache.org/licenses/LICENSE-2.0>`_.
+
+Feedback
+--------
+
+Questions and feedback can be sent to richard at matrix.org.
+
+.. _`Ed25519`: http://ed25519.cr.yp.to/