Identity Management in `cert-wallet`

Technical
1

This is really about mnemonic passphrase and key management, but what it really represents is Identity. How do we know a certificate has been issued to an individual? They have to own the private key associated with the public bitcoin address in a certificate

Problem Statement

Our model for identity management now is simple. Generate a mnemonic passphrase, and that pretty much is your identity. You own all public bitcoin addresses that generate from that mnemonic, and that mnemonic alone.

Unfortunately, reality is a bit more messy, and it’s very likely that an individual will want to have multiple keychains with different mnemonic passphrases associated with them. If you accidentally requested a certificate from a new phone before importing your old passphrase, you should still own any certificates issued to that address. So really, your identity isn’t a single mnemonic, but a collection of mnemonics and their associated keychains.

Proposed Solution

We would need to add a handful of features to the iOS app to get this right.

  1. Add a settings screen where you can see any keychains (& their mnemonics)
  2. From that screen, you can add a new keychain. This can be seeded with a random mnemonic, or you can paste an existing one
  3. When you add an issuer, you would need to be prompted about which keychain you would like to send that issuer a public address from.
  4. Any keychains that have had public addresses sent to issuers can’t be deleted.

There would also likely need to be some ability to name/rename these keychains to disambiguate them without revealing their mnemonic passphrase.

Migration Approach

This feature is purely additive, so there’s nothing to migrate in the UI.
We would likely need to change how the private mnemonics (and the # of public addresses) are stored in secure storage, but that would be a minor change.

Questions & Feedback

Do we need to support importing of individual private keys?

I’d argue no, or at least not yet. If that private address is on a keychain you know the mnemonic to, then you should import that mnemonic to get access to that private address. If you don’t know the mnemonic, then that means someone is just handing you a private key and promising not to claim it as their own. I can’t think of any secure case where a user would have the private key, but not the mnemonic associated with it

Should we encourage paper backup of these keys?

Yes, absolutely. There would be another issue for making the first-run experience highlight the importance of paper backups of all mnemonic phrases. That’s just not what I want to talk about in this issue. :slight_smile:

1 Like
2

I think this is an excellent addition to the wallet functionality.

One question about the mnemonic passphrases. You write that there will be a screen where the keychains and mnemonics can be displayed, and you also talk about secure storage for the mnemonics.

Where are the passphrases and private keys stored? Are they stored together?

My understanding of the passphrase is that it protects private keys from being used by a third party. It seems a reasonable expectation for users to memorize their mnemonic passphrases.

The blockcerts wallet might already be doing this for the wallet-generated keys, but I worry about the security implications.

3

This might be a bit confusing, since the words are overloaded. But bear with me. :slight_smile:

The mnemonic passphrase are stored in the iOS device’s Keychain. This is a secure storage mechanism that encrypts it at rest. Private keys aren’t stored. They’re generated from the HD Bitcoin wallet’s Keychain with the mnemonic as the seed. All private keys and public addresses can be regenerated when given the mnemonic.

As for memorization… that’s tough. It’s a security/ease-of-use tradeoff. Industry standard bitcoin wallets will heavily encourage the use of paper backups, but will still present the mnemonic when asked. Coinbase doesn’t even show you the mnemonic before it starts using it. I think for most users, leaning towards the ease-of-use side of that is the right call. But if folks want to be super secure, maybe we’ll later add in a “never show me my mnemonic” at the end of a “be sure you wrote this thing down” wizard?

I’m not sure what “the passphrase protects private keys from being used by a third party” means. Could you clarify?

4

What I meant is that if a third party were to get control of encrypted private keys they would not be able to use them without the passphrase. Is there a fundamental difference (from a security perspective) if you store or generate the private keys, as long as an attacker could use them if they have access to the mnemonic?

I agree it’s a trade off. How do you control access to the iOS Keychain from the wallet at the moment? It’s probably ok if the user is required to authenticate with Touch ID or a long master-password everytime when s/he is trying to generate keys or access the mnemonic from the iOS Keychain. Robin Hood does a pretty good job of not allowing access without Touch ID (and aggressively timing out authenticated sessions).

5

This is a bit of a simplification, but for our purposes, there’s no such thing as an “encrypted private key”.

  • There is the mnemonic passphrase, which isn’t encrypted. (Technically, it’s encrypted at rest in the system, but it’s decrypted for us before use.)
  • That mnemonic passphrase generates private keys. These keys are not encrypted. If an attacker gets this, then they can pass a public/private key signing change for the public bitcoin address associated with the key. They do not need any other information to do so.
  • Storing the mnemonic rather than all private keys is more efficient (requires less space on disk)

As to your second question, right now there is absolutely no access. We don’t expose the mnemonic at all. I think passing a Local Authentication check (either with password or Touch ID) is the right middle ground between security & ease of use.

6

When you say, you don’t “expose” the mnemonic, do you mean that you don’t make them visible to the user through the UX? Because the wallet still needs access in order to generate the keys. It would be trivial to add the ability to display so I don’t think that really makes a difference.

My point was that from a security perspective it doesn’t matter if you store the encrypted keys or generate them, as long as the mnemonic is the only thing you need to do that. But as long as the user can only access the wallet through PW/Touch ID and gets logged out aggressively, it sounds reasonable.

7

Correct. Right now, we don’t make the mnemonic passphrase visible to the user in the app (and that’s what I meant by “we don’t expose it at all”)