[messaging] Best practices (if any) for backing up message key data server-side

[Mikalai Birukou]

  - It seems that ProtonMail used option (1) with two passes, one for 
login into service, and one to open keys. Later they switched to one 
password.

  - Zooming out, I see matrix as communication protocol. Key storage and 
backup are storage questions. Keep it as an optional separate storage 
protocol, even though it may come from the same server. Having separate 
passwords and use of a server-based storage becomes a choice of an app 
developer.

  - What happens if user's device is stolen? Ideally, a logged off 
device should have as much information any server out there. Therefore, 
if you make key encryption and storage scheme, let app developers to 
take advantage of it for securing info on a device against mundane theft.

  - Have a flag in a message that asks other side not to store it 
permanently, so that application exclude so marked messages from storage 
(message key storing is a proxy for storing plain text message). This 
will help opsec.

Mikalai


On 2017-11-30 02:28 PM, Matthew Hodgson wrote:
> Hi all,
>
> We're currently tackling the problem of backing up message keys in 
> Matrix.org's end-to-end encryption architecture.  The aim is to give 
> users a way to recover their message history if they only have one 
> client app (aka 'device') which they then lose.
>
> For context: Matrix's E2EE strategy is that each device in a chatroom 
> establishes a 1:1 Double Ratchet between each other in a full mesh 
> (using the Olm ratchet: https://matrix.org/docs/spec/olm.html).  Each 
> device then maintains a simpler hash ratchet (Megolm: 
> https://matrix.org/docs/spec/megolm.html) which it uses to encrypt 
> sequences of messages it sends to the other devices in the room via 
> Matrix (HTTPS+JSON).  The state of each device's megolm ratchet (its 
> "megolm key") is sent to all the other devices in the room over the 
> secure 1:1 Olm channel, such that they can decrypt the messages and 
> message history as long as they have the necessary megolm session 
> keys. The sessions are regularly re-established to avoid reusing the 
> same key throughout the lifetime of the room (especially as users 
> join/part the room).
>
> So far we let users manually export/import their megolm keys for a 
> given device as a passphrased blob (HMAC'd AES-256-CTR, using a PBKDF2 
> derived key from the passphrase).  We've also just added the ability 
> for users to sync megolm keys on demand between their own trusted 
> devices via so-called "keyshare requests" over the Olm channel.
>
> However, this fails for the scenario where the user is logging into a 
> new device but doesn't have any other active devices online (e.g. 
> having lost them, or because they're turned off, etc).  So we've been 
> trying to establish the best approach for *optionally* backing up the 
> keys serverside.  The options we've considered so far are:
>
> 1. Prompt the user for a passphrase at login (or launch?), which is 
> stored to encrypt the megolm keys and sync them to the server. If the 
> client is missing any megolm keys for whatever reason it can retrieve 
> them from the server.  The disadvantage is the bad UX of needing the 
> user to remember and enter a passphrase whenever they login (as well 
> as doing a more normal login/password sign-in), and the fact a 
> passphrase-equivalent needs to hang around on the client.
>
> 2. Generate a recovery keypair for the account, and give the private 
> key to the user as a 'recovery code' to keep safe.  We sync the public 
> key between the user's verified devices, and they encrypt the megolm 
> keys with the public key and store them on the server.  If the user 
> has a disaster and needs to recover the keys, they enter their 
> 'recovery code' and sync the keys back to their client.  This has the 
> advantage of not storing this master private key anywhere (other than 
> out-of-band by the user), and only prompting the user when things are 
> going wrong. However, it means the server-side keys can't be used to 
> transparently recover missing keys on an ad hoc basis, and the UX of 
> storing and entering long 'recovery codes' is perhaps questionable.
>
> 3. Same as option 1, but we sync the passphrase-equivalent between the 
> user's verified devices over the Olm channel.  This means trusted 
> devices magically get access to the history keys stored on the server 
> - but means that we are enthusiastically copying an unprotected master 
> key between devices (albeit trusted devices), which feels dangerous. 
> However, we are effectively doing a subset of this today already when 
> we transfer specific megolm keys between devices using keyshare requests.
>
> I've been going around in circles on this, and given the whole idea of 
> "storing private keys serverside" generally rings alarm bells, I 
> thought I'd ask for opinions from the wider community before we screw 
> something up.  Feedback on the overall scheme would be appreciated 
> too: it feels slightly wrong that we're going through all the hassle 
> of Olm and Megolm ratchets only to then go and deliberately store 
> message keys or master recovery keys in order to decrypt history.  
> (That said, it's worth noting that rooms can theoretically be 
> configured to deliberately discard old session keys if PFS is more 
> important than serverside history).
>
> thoughts welcome!
>
> thanks,
>
> Matthew
>
>