Keycard - Perfect balance of security and usability

Keycard
1

tl;dr: Pair directly wallet browser extension to keycard via Waku + Mobile app to enjoy the keycard usability, while reducing software supply chain risk.

Capturing discussions happening on several places - and also this twitter thread

Do note that a lot of the assumptions below are based on my personal experience and opinion. I did not survey hardware wallet users and am happy to be told that I represent 0.1% of the users.

Problem

I have been reviewing my cold storage habits recently - both for Ethereum and Bitcoin assets.
Trying to find an easy middle between security, usability and also privacy/opensource.

The Ledger ecosystem has great usability, but rates much lower on privacy, and FOSS. But also security with their regular firmware updates and UK based “recovery” solutions.

Problem Statement

The problem I usually encountered are:

  • Having to enter pin and other information using small buttons on a tiny device with a tiny screen - feeling like I am using a rotary phone all over again.
  • Scanning QR code from my laptop is a PITA as I use hardware switches on my webcams
    • For smaller screens, it simply does not scan from the laptop
    • Otherwise, need to be very fiddly
  • When using mobile, QR code is ok but you do have to handle 2 devices at the same time - ideal for ambidextrous people, but I am not one of those.
  • USB connection is fine on desktop, but you usually do not want to leave the hardware plugged in
  • USB can be fiddly on mobile - this is the only scenario where I need to find my usb-c to usb-c cable (android) - I assume it’s similar on iOS
  • Bluetooth never works 100% of the time - and not really great for security
  • Airgapped devices will lack enough context to show how impactful your transaction is - devices with small screen lack the display estate.

Keycard

Keycard solves a lot of the problems exposed above. No bluetooth and no cable. No fiddling with small button.
The mobile app can show full context of a transaction.

However, there is a trust assumption on the application that sends the data to the keycard. If this application is compromised, then the user cannot double check before signing on the keycard.
Moreover there is no need to upgrade the firmware on a keycard, removing potential attacks there. Because it is cheap, if you need a new feature on the keycard firmware, you can just buy a new keycard.

Keycard shell solves this security issue, by taking a route similar to existing hardware devices.

I am looking forward to getting my hands on it. I think the FOSS approach, swappable keycard design, and connectivity diversity (QR or USB) are great.

Ideal UX

The gain in security with keycard shell does reduce some of the UX.

I love the idea of just tapping a card on my phone for any transactions.

  • There is no fiddling with the keycard, just tap and hold
  • A phone is a better place to enter a pin with my fat fingers - and pull relevant data to get transaction context

However, the main risk is similar to Bybit: what if the mobile app (Status Mobile in this case) gets compromised?

Dapp Browser

IMHO, dapp browser only exist due to poor connectivity UX and reliability. Most users would prefer to use their regular browser to navigate dapps.

Using in-wallet dapp browsers are usually clunky - no matter the wallet.

Finally, while mobile is first for everything - I don’t do heavy finances on my mobile and usually prefer my desktop - maybe another opinion that makes me a 0.1% user.

Supply chain attack

The main security risk with keycard (without keycard shell) is for an attacker to compromise the mobile software (Status Mobile app) installed on the user’s device.
What the mobile app shows to the user could be different from what is sent to the keycard to sign.

Please note that as signing happens on the keycard, extraction of private key is not possible.

Dual software to reduce supply chain attack

A way to combine ideal UX (IMHO) and increased security, would be to have two different piece of software confirming the same information.

A way to do so would be as follows:

  1. Browser extension exposes ethereum API to allow dapp usage in (desktop) browser
  2. Browser extension communicate with mobile app (over Waku) - secure session must be setup
  3. Keycard and browser extension are paired directly with each other - using mobile app and waku as intermediary (or maybe use usb card reader just for pairing)
  4. User initiates transaction via browser
  5. Extension sends bundle to sign for keycard - encrypted and auth with MAC from pairing session - over Waku to mobile app - User must enter PIN at this stage
  6. Extension includes
    a. decryption key of bundle for mobile app to view bundle
    b. but does not include secret MAC key - so that mobile cannot alter the bundle
    c. Can also included tx context - such as full data of EIP-712 signature - that is not usually included in bundle to sign (only hash is)
  7. Mobile decrypts bundle to show user before sending it to keycard

UX summary:

  1. Use desktop browser to initiate transaction, enter PIN in browser extension
  2. Open app to verify transaction, potentially reject if not matching expectation - app can show a full context of the transaction and even run simulation
  3. If approved, hold keycard on phone
  4. Done

Security summary:

  1. If extension is compromised: the user will be alerted when double checking details on mobile app
  2. If mobile app is compromised: the app cannot change the data to be signed. worst case, it shows wrong details to user who then abort transaction

Enhanced security:

The extension and mobile app need a secure session to exchange information. However, it could be possible to extend this secure session to other devices/apps. So users could “triple” check the data, between several devices before sending it to keycard.

1 Like
2

That’s a quite interesting scheme indeed! I am trying to see how that could be turned into a product, here are a couple of considerations; If you could review them that would be great.

I guess the mobile app should never get the card’s pin: if any of the mobile app features needs the PIN (e.g set up the card) then a malveillant version of the app could sign something else than what is shown on the mobile UI and extension UI, and it would be already too late, the app wouldn’t even have to answer back to the extension, it could directly broadcast a malveillant signed tx. Is that right? or I am missing something?

If that is the case, the mobile app could hardly be Status app, and this app should ‘only’ be a simple bridging app with a good UI to decode tx. Also in this case, this extension+bridging app scheme would be an additional feature for keycard and not a self contained product (for the simple reason that they need an other app to set-up their card)

I’m really looking forward to continue the discussion and see how this could be productivized for keycard users.

1 Like
3

Yes, I assume that if the mobile app gets hold of the card pin, it could then push whatever it wants to the card.

This is actually one of my question, could a different pin be set for each paired device? this would allow mobile<>keycard pairing while resolving this security concern.

I agree that there is flexibility here in terms of mobile software. It could be a simple “companion” app for keycard, which would be paired with the extension at first for secure communication.

Also note that you could even have several instances of this app across the user devices, if they want to “triple” check the transaction is correct, they could view it from several devices, as long as they are all in the same secure session with the extension.

4

The current deployed applet doesn’t function this way … additionally, users typically associate their PIN with their card rather than the device they enter it on, so altering this mental framework could be challenging.

1 Like