[messaging] Multiple devices and key synchronization: some thoughts

[Sam Lanning]

On 03/01/15 16:15, Joseph Bonneau wrote:
> 
> However, I think it's also possible (and indeed common) to make a design
> error by assuming all users have the same values as we do, or would "if
> only they knew" and therefore we should try to force them into a high
> level of security.
> 
> Personally, I think many users' desire for end-to-end security ends well
> short of printing backup codes or running a pairing protocol that
> prevents them from instantly using a new device. If this is required to
> use multiple devices, I'm worried that the result will be a large number
> of users signing up for some new cloud service which manages a single
> private key for them and lets them fetch their messages from any device
> (using passwords and HTTPS), at which point end-to-end security is gone.

Couldn't agree more!

I have a controversial idea for a system which would get around this
(heavily inspired by Nadim Kobeissi's miniLock).

The system is comprised of:

* A master key and key generation (for each user). THE IDENTITY.
* Metadata associated with a master key (e.g. name, email, work etc...)
* Individual service master keys for each service a user uses (e.g.
  some Axolotl chat system, bitcoin id, etc...), signed by the master
  key, and bound to some well known UID for the service.
* A network of keyservers, similar to PGP (exactly what we store here
  will be described later).

## Master Key Generation & Storage:

This is the critical part, and the beautiful bit about this is that no
key management is needed, and users will not, for example, resort to
cloud services to store their secrets.

When prompted to create a new ID, a user enters their full name, and a
password (with appropriate UI to encourage strong passwords). Now this
data is then solely used to generate pseudorandom data for key
generation of the master keypair. (e.g. using PBKDF2)

The master keypair is NEVER stored on a device, it is in memory for only
when it needs to be used, and each time a user is prompted for the
password (the full name used in generation will be saved to each device,
and in essence performs the function of a password salt).

## Metadata:

A user will have the option to add matadata to their identity, which can
be publicly published, like social networking identities, other names,
email addresses etc. This data will be signed by the master key, and
uploaded along with the master public key to any keyserver. The master
password will be required for any changes to the metadata.

## Activating a service:

I'm making the assumption here that the use of this system will be baked
into any app that wishes to use it, for example, TextSecure. On first
use it asks for creation of a new identity / name and password for an
existing one.

To add a service, with the master private key in memory, generate a new
keypair for the service (or whatever other data needs to be generated),
then create a signed message (A) using the master private key. Encrypt
any secrets (i.e. the private key) into a message (B) using the master
public key. Upload both (A) and (B) to the keyserver.

Use of the key data for a specific service is then up to the discretion
of that service.

In the case of axolotol (and following what we have already said in this
thread) the service key may be used to only generate a signed message
for a new device specific keypair which gets stored on the device, and
the service key gets disposed of (or only stored encrypted on the device).

## Adding a new device to an existing service:

Take for example the service above. A user will start the app, say "I
have an ID", enter their name and password, keypair will be generated.
Device will then look up public master key on keyserver, check if it
already has the service activated, and if so it will download the
encrypted keypair for particular service, generate a new key for the
device etc... voila.

All the user needed to do was enter their name and password.

# Conclusions

## The Good

* It's really simple, and "just works". New device, enter name and
  password, done! (subject to keyserver availability + propagation).
* No master keys are stored on a device, revoking a device is as simple
  as entering your master password on one of your other devices (or
  even a new one). So loss / theft of devices is not a problem.
* Similar paradigms to what users are already used to "I enter my
  password and I have access"
* No key management required whatsoever.
* Those who wish to can generate and store their private keys
  differently and still be part of the same system by submitting to
  keyservers. It plays safe with the paranoid.

## The Bad

* Relies on good user passwords, can be offline brute-forced (but brute
force is with respect to a particular full name).
* Randomness of keys relies on randomness of hash functions and passwords.

Thoughts?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20150103/169585c1/attachment.sig>