Javacard hardwallet user stories

Archive UX and UXR
1

Several teams are (or will) work on the integration of the hardwallet (talking about the javacard only here). This post is to launch a discussion on the user stories we want to implement, define what we want and prioritize !

This will help for sure UX teams and client teams that will be working on this integration.

For memo, the hardwallet is a javacard with no user interface (no screen, no button) communicating with our clients with NFC (native in Android, need a bluetooth/usb reader for iOS & desktop).

A target is to have a first batch of product ready with all or selected user stories implemented and tested for Devcon4 end of October.

Overall rationale of the hardwallet

Just to back up for one second: the overall rationale of the hardwallet is to increase security and convenience of the Status user experience.

Improve security:

  • secret elements are separated (air gapped) from the status client on phone or PC. Thus eliminating the risk of malware intercepting some of these secrets.
  • sensitive operations (login, signing transactions) need a proof of possession (i.e. the hardwallet) on top of proof of knowledge (e.g PIN)

Improve convenience:

  • replace login with password by a tap of card + card PIN, assuming it’s easier to remember a pin than a password

Proposed user stories

For account set-up
0/ For an existing Status wallet and when user is logged into Status, the user can export its wallet into his hardwallet
The user can export the master key pair to the card. No need for the user to enter his mnemonic.
1/ For an existing BIP32 wallet (Status or not), the user can import its wallet in the hardwallet
The user is asked for its mnemonic
2/ Create a new Status wallet in the Javacard

Once the account is set-up
3/ The user sign transactions with card + PIN instead of entering the password
4/ the user login into status with card + PIN instead of input password

Other feature
5/ export whisper keys to client RAM
the interest is to not store the whisper keys in the client flash. This is not really a user story since there is no UX associated, it’s more of a security feature of the hardwallet.

A specific question that has both technical and UX consequences

We need to clarify if the end user that has ported his wallet (or created a new one) to a hardwallet still needs to define and memorize his Status password or not.

From a usability point of view, it’s better to replace all use of the password by the hardwallet + PIN.

We should discuss how this is handled from technical standpoint : with which password the database will be encrypted? how can we generate it ?

Thanks for your feedbacks !

1 Like
2

Hey @guylouis, nice topic, I’m really happy to start discussing about it!

0/ For an existing Status wallet and when user is logged into Status, the user can export its wallet into his hardwallet
The user can export the master key pair to the card. No need for the user to enter his mnemonic.

After a user created an account on the status app, we don’t have the master key anymore, we only save the BIP44 key for the first address. That would be enough to sign transactions though, do we need anything else?

In general do we need to save the master key in the javacard? I know it can derive child keys, so having that can help signing transactions with any child key, but I’m not sure about the final way we want to use it. Is there any user story with details about how we are going to use it?

3

Than you @guylouis!

For Devcon are we aiming to support all the user stories, or a subset?

4

The scenarios that have been discussed up to now are mainly :

  • signing transactions in the javacard (with m/44’/60’/0’/0/0 if I understood well)
  • (your thread actually) deriving this into m/44’/60’/0’/0/n to generate the whisper key, new wallet accounts, dapp key pairs

Not anything else in my knowledge but I am here since only yesterday :slight_smile:

However, and @michele can comment, my understanding is that the applet API is really designed to load m and not a m/44’/60’/etc derivation as a master key. Meaning that with current javacard user story 0/ is not possible because the client does not store m right ? also meaning that the user will have to enter its mnemonic.

5

Hi @chad, this is to be discussed all together because several teams are involved, and the time line is really tight. Obviously, we should support as many user stories as possible obviously, but the bare minimum is setup by creating a new mnemonic (2/) and signing transactions with the card (3/)

Of course using an existing BIP32 wallet (1/) would be really nice (but 2/ is a priority because we want users without a BIP32 wallet mnemonic to engage in the experience).
And 4/ (login with javacard) would be nice to from a user experience point of view too.

Exporting the whisper key is only a security feature, has no Ux implications, and is thus not really needed for devcon.

6

Hi @gravityblast, @guylouis

When you load a key, for the applet this is the master key. Of course, any key works. But then you have to keep a mapping between the actual path and the “virtual path” (because when the card thinks it is at m, it is at m/44’/60’/0’/0/0 so whatever path the card think it is, is a virtual path). If we want to keep the javacard compatible with other ethereum wallets and/or be sure it remains open for other usages, we should most likely store the master key, so that when the card is asked for its current path, the correct result is returned. The master key can always be restored using the mnemonic, so it should not be hard to migrate existing wallets this way.

1 Like
7

@michele thanks !

Well that means that the first user story (0/) - pushing wallet secrets to the hardwallet from a logged in state to the javacard without entering the mnemonic - is not possible. We can of course keep in the UX an entry for the user to push the secrets to the javacard when he’s logged in, but he will have to enter his mnemonic.

8

As for keeping the password, I don’t see it as necessary. The hardware + PIN replacing password for login is sufficient (effectively 2FA).

Addition of biometric features can augment this 2FA or upgrade to 3FA depending on user desire I’d say.

9

@hester has prepared some details on the integration flow and UI design Hardware wallet integration Flow and UI design · Issue #18 · status-im/design · GitHub that is worth a look.

10

Thanks @Chad, missed this post.