Account backups
Make it possible for the user to backup their Briar account to another device. The backup should use much stronger PBKDF parameters as it's likely to be stored insecurely and doesn't need to be decrypted quickly.
Activity
Saving some long list discussions from the architecture channel:
Torsten:
This made me think of something. Just imagine, I made the effort to visit people in my network personally to add them to Briar. Maybe I even did a backup of my Briar database once or twice. And now I get a new phone and put back the backup, I still lose many of my social contacts and without backup, I would lose my complete Briar identity.
str4d
It would be tricky to have a good self-contained solution to this. If we added integration with file storage apps like Dropbox, or Google's backup mechanism then it would be easier, or at least user friendly, but that's unlikely. One possibility is nominating contacts to act as backups, to whom Briar sends backups encrypted to a preselected passphrase. Then on restore, the user only has to meet that one contact in person and remember the passphrase they set. Kinda like how many email accounts let you add a backup email address for password recovery.
akwizgran:
yup, that's an idea we've discussed before (along with a variant that uses secret sharing, so you have to meet up with any k of n nominated contacts). i'll see whether we have a ticket for it...
@Dymaxion and i talked about backups last time we met. one of the difficult issues is reconnecting to contacts without storing any key material in the backup that would defeat forward secrecy (you can't just store a snapshot of your current transport keys, for example)
we may need a new protocol for connecting to a contact over a long-range transport and agreeing fresh transport keys, using the long-term identity keys stored in the backup to authenticate the key agreement
but if we want that protocol to be indistinguishable from random, like btp, it will require a way of mapping an ephemeral public key to a random string, such as elligator which greatly restricts our future choices of public key algorithms
dymaxion:
Oh, hey, once we have multiple devices, we could use that as a backup tool -- we backup content and contacts, but use the keychains of a separate device, so when you restore from backup, you can roll those keys forward and re-establish contact, but not actually decrypt old content. You'll have to resend anything that was in-flight, but you're also going to have to resync missing message state anyway, so that doesn't seem like a big deal, although it'll have to be explained.
akwizgran:
good point, and we can do something similar withhout multi-device support by deriving a second set of backup transport keys that run parallel to the primary set. but there are a couple of issues: first, it doubles the number of tags we need to recognise (not a huge deal), and second, we have to be sure the backup's destroyed before we start using the backup transport keys. i don't think we can be sure of that, because who knows what wonderfully robust multi-site, multi-provider backup strategy the user has. but there's a possible compromise. we use the keys from the backup only to obfuscate a fresh key exchange authenticated with long-term identity keys. this frees us from elligator while preserving forward secrecy. if the backup is later compromised, the key exchange connection can be deobfuscated. but the backup also contains our long-term identity keys, which can be used to connect to our contacts and re-sync all our old messages - so the loss of obfuscation is far from our biggest worry at that point
hmm, thinking about how we might implement this, there's some overlap with #61 (ratcheting)
we use the backup keys to create a pair of btp streams, which aren't assumed to be forward secret because the backup may not have been destroyed. we only use those streams to agree a fresh set of transport keys. the key agreement protocol is similar, hopefully identical to the one we'd use to ratchet forward to a fresh set of transport keys in normal operation. we terminate the streams and use the fresh keys to create new streams on the same transport connection. we now have forward secrecy and the new streams can be used for sync etc
Edited by Torsten Grotementioned in issue #983
mentioned in issue #1050
OK, here's a plan of attack:
- Transport keys are not stored in backups
- For each contact, derive a set of rotating recovery keys from the initial shared secret
- Recovery keys are only used when we or the contact (or both) are recovering from a backup
- Recovery keys are used to obfuscate and authenticate the messages of a new recovery protocol
- The recovery protocol doesn't need forward secrecy, so we don't lose security by keeping backups after we've recovered from them, or recovering more than once from the same backup
- The recovery protocol may lose obfuscation (due to tag reuse) if we recover from the same backup more than once in a given rotation period
The recovery protocol has three messages:
- Request: Sent by Bob to start the protocol, skipped if Alice starts the protocol
- Alice's key: Sent by Alice to start the protocol, or in response to a request from Bob. Contains a fresh Diffie-Hellman public key and timestamp
- Bob's key: Sent by Bob in response to Alice's key. Contains a fresh Diffie-Hellman public key and timestamp
The protocol may need some sort of session ID, because either party may restore from backup during the protocol, causing them to start a new session that needs to be distinguished from any existing sessions.
A recovery stream starts with a tag and contains a single recovery message, encrypted and authenticated with the corresponding cipher key. Each party sends recovery streams containing the current message of the recovery protocol, over all available transports, until the next message or a data stream using the new transport keys is received.
Alice can use the new transport keys for outgoing data streams after receiving Bob's key, as this tells her that Bob has started rotating the new transport keys.
Bob can start using the new transport keys for outgoing data streams after receiving an incoming data stream that uses the new keys, as this tells him that Alice has started rotating the new keys.
Transport connections used for recovery streams can be reused for subsequent recovery or data streams, so it should be possible to negotiate and start using a new set of transport keys over a single duplex transport connection.
-
The sync protocol and its clients will need to be aware of the possibility of a contact reverting to an earlier state (for example, no longer having a message they've previously acked) due to recovering from a backup.
One way to handle this would be to reset the contact to an initial state (no shared groups, messages, etc) when either side recovers from a backup. But this might not be what users expect from a backup feature!
If we don't reset state then the issues here are similar to those we face with multi-device support (#887).
-
Wow! Thanks for continuing to thing about this! Sounds like a great start!
One way to handle this would be to reset the contact to an initial state (no shared groups, messages, etc) when either side recovers from a backup. But this might not be what users expect from a backup feature!
We might get away with calling this a contact backup feature.
mentioned in issue #474 (closed)
mentioned in issue #1179
