Research: Multiple keys/addresses maps to one 3box

[coder5876]

When using multiple devices with different keys per device it is desirable to map all those keys to one 3box.

[coder5876]

First suggestion of a way to solve this:

Using multiple ETH addresses with one 3box

User has an ETH address A with corresponding private key a. The private key is used to generate a signature from which we derive a mnemonic seed m and from this seed we derive a symmetric encryption key s.

Suppose we know have a second device on which we generate another key pair (a', A'). We want to allow the user to access their 3box using this key pair.

Technical solution

Log into 3box in the normal way with A' by signing a message, deriving a mnemonic m' and a symmetric key s'.

Move the mnemonic m' over to the device containing the ETH address A. Using the symmetric key s' (derived from m') the user encrypts the original mnemonic m and posts the encrypted value E(s', m) in the Public Profile of A under the key "deviceKey_<A'>" (could be privacy issues in revealing A'?).

The user then instructs the Address Server to map the address A' to the same orbitDB instance as A, using a signed message from A and A'.

Next time the user logs in using A', the Address Server will retrieve the OrbitDB instance. The user checks that the key "deviceKey_<A'>" exists as a key in the Public Profile & retrieves the corresponding encrypted value E(s', m).

The user then decrypts E(s', m) using the key s' to get the mnemonic m and they can at that point read and write to the OrbitDB instance at will.

Description of Possible UX

When logging into 3box.io with the new device, click something like "I want to add new device/account/ethereum address to existing 3box".

This will display m' or s' as a QR code. There could also be a selection "Cannot scan?" which would display m' as 12 words.

On the device with Ethereum address A the user would log into 3box.io, click something like "Add new device to this 3box". This would hook into the camera and allow you to scan the code on the other device. Here there could also be a selection "Cannot scan?" which would allow you to manually enter the 12 word seed.

After scanning the code (or typing the words) we would show something like "New device <A'> added".

[coder5876]

@oed @zachferland @c-castillo Any comments/suggestions?

[michaelsena]

Sorry @christianlundkvist my comment was accidentally deleted, but we caught up today on standup! just making sure it doesn't look empty on the story :)

My feedback is mainly around onboarding UX. I think we should try to design a system that optimizes for onboarding new users seamlessly, and then letting them pair their new 3Box with the original 3Box.

[c-castillo]

@christianlundkvist I like the usage of QR codes to pair new devices. I think a little more detail on how the adding a new device will work from the user standpoint.
Technically it provides enough detail and it makes sense.

[michaelsena]

Hey @christianlundkvist bumping this story 👍 Where are we on this? It would be nice to post a bounty for this as soon as we have a solid opinion on implementation. Have you drafted up the scenarios yet? TY!

[coder5876]

Approach using asymmetric encryption

This approach relies on each 3box profile having a public encryption key in the public profile. The private decryption key would be derived from the users seed.

Given that an address A has such an encryption key we can denote the encryption of some data D to that key as E_A(D).

Technical description

Now, given an address A we can make an address B able to use A:s 3box by encrypting A:s seed s_A with B:s public encryption key.

We would do this by adding the following data to A:s public profile:

"shared" : {B : E_B(s_A)}

This is similar to the approach taken above. At this point, B is able to interact with the 3box of A since he has access to A:s seed.

The next time B logs into their 3box, B will need to merge their 3box with the 3box of A. We would need to decide exactly how that's done but a simple heuristic is to add the profile data from B to that of A and if there are conflicts in the case of identical keys we would have A:s data override that of B.

After B has merged their 3box into A, B can delete their public profile and private data and in the private profile they can store a redirect that will instruct dapps to use the 3box of A when storing and retrieving data:

"useOther3Box" : {"address" : A, "seed" : s_A}

After this, when B logs into a dapp, this dapp can check if the "useOther3Box" data is set. If it is, the dapp can retrieve the seed and use the keys derived from this seed to read and store user data.

Suppose we now want to merge in another address, C. This can now be done from either A or B since both of these addresses can access the seed s_A that controls access to the 3Box. We can add address C by updating the "shared" public profile entry to

"shared" : {B : E_B(s_A), C : E_C(s_A)}.

This now allows C to access the 3Box in the same way as A and B.

Possible user experience

When logging in to 3box.io (or perhaps another dapp) using address A the user chooses "I want to add new device/account/ethereum address to existing 3box".

The user then either scans a QR of the address B to be added or enters it into a text field. For use with Universal Logins, this step could be integrated in the steps needed to add a key to your Universal Logins profile.

Once the address has been scanned or entered in the user sees a message like "Login with

/new device to 3box.io to finish adding this device/account/address".

The next time the user logs in to 3Box.io with address B, they can choose "Merge with another 3Box" or similar. They can then enter address A (or in the case of Universal Logins type in the corresponding ENS name). This will then merge the 3Box of address B with the one for address A as described above.

From now on, when the user logs in to a dapp with address B the dapp will read from and write to the merged 3Box.

Potential issues

1. As with other schemes that uses asymmetric encryption it is vulnerable to attacks with quantum computers. This may or may not be an issue.

2. The data about which addresses are merged is public. This may potentially be a privacy issue.

[michaelsena]

Thanks @christianlundkvist. What’s your take on using asymmetric encryption for this, what are the risks here?

[oed]

That seems like a nice and pragmatic solution! I would change "useOther3Box" to be set in the root store of B. That way B would only need to open one orbitdb instance.

[oed]

If there is a key conflict, we can use the timestamp to decide which entry to use.

[coder5876]

@michaelsena Main risk is that if you have sensitive data in your private store someone can save all your encrypted data, then 15 or 20 years later when/if quantum computers are a thing they can decrypt all data and see your sensitive stuff. So it depends on the type of data you are storing wether or not this is an issue.

would change "useOther3Box" to be set in root store

@oed Sounds good to me!

use timestamp to decide which entry to use

Good idea!

[michaelsena]

@oed and @christianlundkvist where are we on this story coming out of the retreat? Has it fallen in prio? Or how should we proceed here?

[oed]

@michaelsena it seems like we got most of the research figured out already. As for an implementation I don't see an immediate need yet.

[michaelsena]

@oed bumping this issue after our conversations with the Bounties team. Thoughts? cc @dazuck

[oed]

Closing this as it's well defined and on the roadmap for implementation soon :)