Identity - Using passphrase to generate temporary Key pairs.

[joaosantos15]

This issue tracks the passphrase usage discussion related to #9 .

[satazor]

Copy pasting to be easier to discuss:

Next, in step 4, Alice retrieves her authorization from the Guest-list. She decrypts the message using TemPrivKeyDoc-Alice, and extracts the documents read and write keys. The TemPrivKeyDoc-Alice is generated using a user defined passphrase as a seed. This means that the user can reconstruct the private key, regardless of the device she is in

Regarding using a passphrase to generate the TmpKey:

The issue with a passphrase is that a malicious node may try to guess the password of a entry in the guest-list via a brute-force attack. The attacker has access to the guestlist because it's public. A successful guess would give access to the document keys, exposing the document contents.

I propose a different approach:

To request access, Alice would send her presentation package (DID + pubkey + pubkey signed with root private key) as well as the document id signed with her device's private key. After Bob verifies the authenticity of Alice as described in Step 2, Bob generates an entry in the guest-list for each one of Alice's devices present in his Address Book, by cyphering the document keys with each device's public keys.

If Alice tries to access the document in a device known to Bob, the access would be transparently given. But for a device unknown to Bob, Alice would not be able to retrieve the document keys because there's no entry for that device in the guest-list. Still, Alice could use one of her other previously authorized devices to authorize herself. This could be done in a nice UI/UX where we make it clear to Alice that her device hasn't yet been authorized but she can do so.

This solution does not have the downside of using passwords. In the best case scenario, Bob generated an entry for all of Alice devices and she is able to access the document in all of them. In the worse case scenario, Alice must "self authorize" all of her other devices with the one authorized by Bob.

To further improve on this, Alice could have a list of devices associated with her DID. This would allow Bob to generate an invitation to all of her devices, hence always achieving the best case scenario. Still, new devices would have to follow the "self authorization" mechanism previously described.
Another improvement on top of the previous one, is that Alice could optionally and selectively enable the replication of keys that unlock resources. This way, any resource previously accessed in a device would be made available to any of her devices that have replication enabled. This would be useful to any kind of resources, like a peerpad document, a kipster page, etc. This would be a opt-in feature that would improve the user-friendliness but reduce security. I will create a separate issue in order to further elaborate on this.

[joaosantos15]

I agree that a passphrase would be the weakest point in this design, and the easier to attack. However, I see two main issues with using the device's key pair to transmit the document's keys:

1. Key exposure

However, using a device's private key pair (eg smart-phone key pair, or laptop key pair) to transmit document keys could result in the private key being overly exposed.

Let's assume that n is the set of documents Alice has access to, and that m is the set of documents an attacker has access to, m is contained inside n.

For each document in m the attacker will have access to the documents' keys encrypted with Alice's public keys. The attacker also has access to the documents' Write keys. This means he would have access to the encrypted text (which would be in the document's authorization list) and to the decrypted text. I need to do some further research, but I believe this would increase the vulnerability to a cryptoanalysis attack.

2. Consequences of key compromise

If Alice's device key was compromised, an attacker would have access to all the documents Alice has access to.

An alternative

Based on @satazor 's idea, I believe we could merge the passphrase concept with using the device keys:

• The document Write key would be encrypted using Alice's device public key. This produces {WriteKey}Alice-Device-Pub
• {WriteKey}Alice-Pub would then be encrypted with the document temporary key, which uses the passphrase. Producing {{WriteKey}Alice-Device-Pub}TempPubKey

This way, even if an attacker discovers the temp keys' passphrase, he would still need to have control of Alice's-Device-Pub. This also solves another problem of the device's key being compromised. Since the TempPubKeyPair is not derived from the Alice-Device-KeyPair, the disclosure of Alice-Device-Private key would not reveal the write keys of all of Alice's documents.

This would effectively be two-factor authentication. Something you know, the passphrase, something you have, the device with the DeviceKeyPair.

Extra tought:
To improve performance, we could make the temporary key be a symmetric one, we could make a diffie-helman exchange (where two parties exchange two numbers in the open, and from there are able to compute a symmetric key for encrypted communication) in the request for access part of the process.

[satazor]

Like @diasdavid said, we may change a few knobs to increase security while decreasing usability and the other way around.

Having a password combined with Alice's keys will increase security but will require her to remember the password for each document. She might end up using the same password in every document so that she doesn't have to remember different passwords. This will make the additional security weaker.

What I'm saying is that the additional passphrase might make sense for some apps, or even in a subset of features of an app. I don't know if that's the case for peerpad documents in general. Perhaps, that could be a opt-in definition of the document itself?

[satazor]

Regarding compromised keys:

To further improve on this, Alice could have a list of devices associated with her DID. This would allow Bob to generate an invitation to all of her devices, hence always achieving the best case scenario

By doing this, Alice could not only have a list of devices associated with her DID but also flag the ones that were compromised. This way, if Bob interacts with one of Alice's compromised devices, he could be warned and take action, like showing a big warning 🔥in the UI/UX as well as to remove the compromised device from its addressbook.
Additionally and to be more "real-time", when Alice flags a device as compromised, she could disseminate this somehow so that Bob and other peers could take action earlier.

After reading a bit of TUF (The Update Framework), they have a similar strategy to deal with compromised devices.

[joaosantos15]

@satazor

This way, peers interacting with one of her compromised devices could be warned and take action, like showing a big warning 🔥in the UI/UX as well as to remove the compromised device from its addressbook.

So, in this scenario, everytime two entities interact which each other they would have to reauthenticate themselves? Alice sends me a message, I once again verify her DID-Document to make sure she hasn't flagged new devices as compromised?

In this case the address book would only need to contain DIDs with verified identities (the manual process through which a user verifies another user's proofs of personhood) and not need to contain the device keys associates with each DID, right? Because everytime a new interaction occurred you would get the device keys from the DID-Document to make sure that you're not receiving flagged keys.

Or would this process be something like sending an email to your contact list saying "hey, people, this key has been compromised, so please update your address book"

[satazor]

So, in this scenario, everytime two entities interact which each other they would have to reauthenticate themselves? Alice sends me a message, I once again verify her DID-Document to make sure she hasn't flagged new devices as compromised?

Essentially, yes.

I would say that "reauthenticate" is not a good name to describe what I wrote above. Essentially, it's a check that can be made on an previously known device to see if it was flagged as compromised since the last check. The when and/or frequency at which this check is made should perhaps be discussed further. In the case of TUF, the check is made during an update process.

[satazor]

In this case the address book would only need to contain DIDs with verified identities (the manual process through which a user verifies another user's proofs of personhood) and not need to contain the device keys associates with each DID, right? Because everytime a new interaction occurred you would get the device keys from the DID-Document to make sure that you're not receiving flagged keys.

If we indeed have a way to associate devices to a DID, perhaps we won't need the addressbook. Still it's a good piece to have for offline usage.

Or would this process be something like sending an email to your contact list saying "hey, people, this key has been compromised, so please update your address book"

I think that a manual process should be the worst case scenario. Ideally, Alice would flag the device as being compromised and everyone interacting with this compromised device could verify if it's compromised or not.

[daviddias]

I see a very good a productive discussion here. In order to avoid reinventing the wheel or missing some perfectly shiny wheel all together, I recommend doing a research on what other Apps are doing for Identity in the browser first. Understand how the following apps work:

• https://www.uport.me/
• https://keybase.io/
• https://jaxx.io/
• https://www.myetherwallet.com/
• https://metamask.io/
• https://www.ledgerwallet.com/apps
• http://minilock.io/

Namely on things like:

• What is what they are trying to do (e.g Authenticate users)
• Their attack vectors (XSS, hardware device stolen, etc)
• How they mitigate those
• Shortcomings still to solve
• Eval on UX of each

[joaosantos15]

Thanks, @diasdavid . I'd also like to add DID-Auth to the list. They explore how different DID methods can be used for authentication, there is a particularly good explanation of uPort.

• https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/draft-documents/did_auth_draft.md