Status-react: Can we abstract pairing code & PUK from the seed to simplify the user experience ?

[yenda]

User Story

As a User I don't want to deal with pair code and PUK code because I already have a card, a pin code and a seed phrase to deal with.

Description

Since the app is setting both when creating the keycard account, both code could be replaced by something derived from the seed phrase (to be recoverable by elements I already know instead of new ones). I would suggest sha3 of seed phrase + keycard uuid (I think there is such a thing?) and then only take the first n chars (these code don't have to be that long)

This means that during account creating we could remove the pair and puk code screen entirely.
During pairing on new device the user enters his seed phrase and account Status does the transformations to get the code and pair the card.
During card unlocking (after multiple wrong PINs) user enters seed phrase and card is unlocked

@andremedeiros @andremedeiros @guylouis @gravityblast @dmitryn @hesterbruikman @corpetty

[guylouis]

This is a nice idea to simplify user's complexity and the numbers of 'codes' he needs to remember/write down

Just to clarify current model:
The pairing code + PUK + PIN are attributes of the cards and:

• are set-up at initialization stage, before any seed is loaded
• are independent of the seed
  So in current model, a user could have a card fully set-up and then reset it (removes seed), he'd keep his PUK, pairing code and PIN and can recover another seed.

@bitgamma (michele) if we were to go in @yenda directions what are the security and flow consequences you'd see ?

[bitgamma]

From a security point of view, you'd be entering the seed on all your devices, so you are widening the attack window a lot. With the current solution, the attack window for the seed phrase (which the most valuable secret) exists only when you load a seed phrase on the card and that should happen once per seed phrase. With the proposed solution, the attack window is every time you pair a device or unblock the PIN. I cannot estimate real-life impact, but it is surely a compromise.

From an implementation point of view, it means the client must change PUK/pairing code whenever a new passphrase is loaded. This does not break existing pairings, so it might not be too bad. It however means that it should reset PUK/pairing code to some sort of default if REMOVE KEY is used and hope no other software changes it, otherwise it becomes impossible to load a new key (unless we provide a pairing code prompt when autopairing fails).

Another complication might come from the fact that the PUK must be numeric. This is something we can change but it is a breaking change or the derived code from the seed phrase must be made a 12 digit number (should not be too difficult). The pairing code instead can be anything, it does not need to be alphabetic, it can even be sha3(seed + uuid) directly if it is not mean to be input.

This also makes it impossible to generate keys on card and then using the DUPLICATE KEY to make backups on spare card. I know we have not planned that yet, so it is not an immediate concern, but that would actually be the best way to go about getting rid of the seed phrase completely and thus closing the attack window at initialization and the weak spot of a paper backup.

[yenda]

@bitgamma I think it can still be solved in an elegant way for the user. There is two possible cases where the user would pair the keycard with a new device:

• user has a new device, and still has the old one: we can have a flow that allows the old device to show a qr code of the pairing code and the new one to scan it, that way the user doesn't have to enter any seed phrase, with this flow the user would even avoid having to put his seedphrase in a new device for recovering a normal account. In that case the pairing code could be sha3 of the sha3 of the seedphrase, which the old devices knows, and the UUID of the card.
• user lost the old device: user has to input his seedphrase (can't think of a trick for now), he needs it to encrypt the db on the new device anyway

[bitgamma]

The idea of transferring the codes from one device to the other is great! It is both more secure and more convenient than typing the seed phrase everytime. I think the loss of old device scenario is at least less likely to happen and so the security compromise becomes much easier to accept.

Since the user can change pairing code and PUK (using a different app for example) however we must also be sure to provide a fallback pairing code input field to the user. Less critical, but similarly a fallback PUK input field could be provided when unblocking the PIN. These would only be used by users who deliberately changed PUK/pairing code outside of Status

[hesterbruikman]

The idea of transferring the codes from one device to the other is great! It is both more secure and more convenient than typing the seed phrase everytime. I think the loss of old device scenario is at least less likely to happen and so the security compromise becomes much easier to accept.

• 
  
  1. The reverse would be great for desktop onboarding as well. Although I imagine more complex as the old device somehow needs to know if the QR code of a new device can be trusted. For another time.
  
  

I cannot estimate real-life impact, but it is surely a compromise.

I see this compromise totally dependent on the use case of Keycard. Meaning the use of Keycard as a _cold storage_ vs keycard as a _cash alternative_. For the scenario of a cash alternative, the amount of assets could be capped by only allowing a pre-configured amount (seems like this would need a contract to safeguard transferring larger amounts).

If the amount is capped, I'd love a solution in which seed phrase, PUK and pairing code aren't required at all. At maximum a passcode set by the user and a unique card ID to recognize a card. Lose the card, lose access; Same as cash.

Dreaming away here 🐭

[yenda]

The reverse would be great for desktop onboarding as well. Although I imagine more complex as the old device somehow needs to know if the QR code of a new device can be trusted. For another time.

Could you describe what you mean by reverse here @hesterbruikman

If the amount is capped, I'd love a solution in which seed phrase, PUK and pairing code aren't required at all. At maximum a passcode set by the user and a unique card ID to recognize a card. Lose the card, lose access; Same as cash.

this can already be done by just removing the seed phrase.

[bitgamma]

For the scenario of a cash alternative, the amount of assets could be capped by only allowing a pre-configured amount (seems like this would need a contract to safeguard transferring larger amounts).

@hesterbruikman this is a scenario we have considered. Version 2.3 of Keycard (unreleased) also includes a KeycardCash applet which has no authentication code at all (not even PIN and the keypair is generated automatically on card) and is meant to be used as a cash equivalent with payment terminals. The applet is parallel and separate from the main wallet applet so one could use only one applet or both at the same time but they never interfere

[hesterbruikman]

@yenda with reverse I mean accessing a multiaccount you already have on mobile on desktop. As I imagine desktop can't necesarily scan a QR code shown on the mobile client, I suspect the mobile client needing some sort verification that the desktop client can be trusted. In other words, I'm not clear on how that would work.

@bitgamma cool, I didn't realize KeycardCash was already implemented!

[yenda]

@hesterbruikman it is not really relevant to this issue anymore but then we could have a dedicated flow on desktop that shows a QRCode and when you scan from the mobiles it recovers the account on the desktop. Unless we are planning to have the wallet on desktop I think the way it would work would be that the desktop has a special flow that creates and starts a throaway account, when the mobile scans the qrcode it sends a message to the desktop that contains the chat key.

[corpetty]

There might be something in the way WhatsApp does desktop, where it pairs
with a phone. @3esmit has spent some time thinking about this and it's
worth looking into. I'm trying to get caught up on this on the phone.

On Mon, Sep 30, 2019, 9:00 AM yenda [e-mail] wrote:

@hesterbruikman https://github.com/hesterbruikman it is not really
relevant to this issue anymore but then we could have a dedicated flow on
desktop that shows a QRCode and when you scan from the mobiles it recovers
the account on the desktop. Unless we are planning to have the wallet on
desktop I think the way it would work would be that the desktop has a
special flow that creates and starts a throaway account, when the mobile
scans the qrcode it sends a message to the desktop that contains the chat
key.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/status-im/status-react/issues/9064?email_source=notifications&email_token=AASYT4JSGXVNZ6KZJOPSTXDQMHZ6PA5CNFSM4I3N2JIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD75RSIA#issuecomment-536549664,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AASYT4PDEU6CS5NPMZPD7QTQMHZ6PANCNFSM4I3N2JIA
.

[hesterbruikman]

Will move the conversation to a more relevant place. 👍

[guylouis]

After discussion on 01/10, one possible implementation:

• pairing code and puk are derived from seed (exact hash tbd)
• design impact
  
  
  
  • no more puk+pairing code screen in onboarding
    
    
    
    
    
    • no more mention of puk + pairing code in leaflet
    
    
    
  
  
  • to manage case of a user that wants to use a new phone
    
    - one screen to show pairing code in the form a QR code
    
    - in 'recover from keycard' add the possibility to scan this QR code
  
  
  • reset keycard. When keycard is reset, secret is wiped, TBD what value do we set for pin, puk, pairing code. 0 ?
    
    
    
    
    
    • since other app can change the secret or puk or pin, we need a screen to allow the user to change his Pairing code and Puk. Probably needs a way to set them with the derived value from seed.
    
    
    
    • when user types PIN 3X wrongly, need a screen that asks to the user his seed instead of the PUK.
    
    
    
  
  

[3esmit]

PUK could be derived from the first word of seedphrase, so user would just have to memorize the first word of his seed phrase to use as PUK

[hesterbruikman]

cc @andmironov

• since other app can change the secret or puk or pin, we need a screen to allow the user to change his Pairing code and Puk. Probably needs a way to set them with the derived value from seed.

This item I'm not clear on what it could look like in the UI. If both are derived from the seed phrase is it more like a button to trigger this?

[guylouis]

in the end the user is responsible for remembering his PUK and pairing code since they cannot be queryed to the card
https://status.im/keycard_api/apdu/changepin.html
@bitgamma please slap me if that's not true :)

So the most we can propose is probably is feature for advanced users who know or think that their puk and pairing is not corresponding with their seed any more

• ask PIN and SEED
• PUK and PAIRING CODE are set back to derived values from the seed

There is no way for the user to know if the PUK and PAIRING CODE were really changed in fact.

[bitgamma]

if we were to derive the pairing code and the PUK from the seed phrase it would mean we wouldn't be able to pair the card with any other app that doesn't take the same approach at pairing/PUK generation. For the PUK it is less sensitive as it is not supposed to be used too much. However we would need at least 3 words from the seed phrase to obtain the same number of combination as we have for the PUK now (it is a 12-digit number, whereas words are choosen from a list of 65535 elements).

This would also mean hiding the real PUK and pairing code from the user, so maybe we should at least add a function to the cli tool or something to calculate it from (part of) seed the phrase for advanced users.

All in all, I am afraid the simplicity advantage we gain during the onboarding will turn into a series confusing issue as soon as the Keycard ecosystem becomes any larger. I think the step of simplyfing the pairing code will already greatly improve the onboarding the experience since that is the longest credential.