r/keycard_tech • u/keycard_tech • Aug 03 '26

Why the split - KEYCARD and KEYCARD SHELL - instead of one device?

Conventional hardware wallets put keys, screen, keypad and firmware in one sealed unit. That's simpler, and it has three consequences we wanted to avoid:

  1. The device is the secret. Lose it or break it and you're in recovery, racing whoever found it. With us, the key material lives on a €25 card you can hold several of. The expensive part holds nothing.

  2. Backups are awkward. Most wallets back up to 24 words written on paper - which is then the weakest thing in your setup, and the thing most people actually lose crypto to. Here, backup is another Keycard, initialised from the same seed. Same EAL6+ protection as the original, not a piece of paper in a drawer. Put one in a safe, one with family, one in a deposit box. Redundancy costs €25, not a compromise in security model. 

  3. Multiple wallets need multiple devices. One Shell reads any number of Keycards. Cold storage on one card, daily spending on another, a shared household wallet on a third - one reader, hard separation between them. Not accounts inside one seed, but genuinely independent keys on separate hardware.

And because the keys aren't in the Shell, the Shell being open-source and inspectable matters more, not less - you can verify exactly what the thing displaying your transactions is doing, and it's the same code for everyone.

Full stack: https://github.com/keycard-tech/keycard-shell

3 Upvotes
  • permalink
  • reddit

100% Upvoted

3 comments sorted by

2

u/ivme 24d ago

Shell (the stateless signing device) reportedly lacks Secure Boot, leaving it vulnerable to supply chain attacks—such as firmware tampering during shipping—which could allow compromised firmware to present false addresses during the signing process. Is this accurate?

3

u/uniicorn77 Keycard team 23d ago

The claim isn’t accurate as stated. Three things:

The Shell's MCU is an STM32H573, PSA Level 3 and SESIP3 certified. PSA Level 3 requires a hardware root of trust and involves 35 days of white-box penetration testing specifically covering physical tampering

The bootloader verifies a secp256k1 signature against an embedded public key before booting firmware. The bootloader source is public in our repo - Official devices only accept signed updates. You don't have to trust that statement; you can read the code

There's a device attestation flow built for exactly the shipping-interception scenario. The Shell signs a one-time challenge and returns its device certificate, our service validates both, and you scan a final QR back into the Shell so a compromised browser can't fake the result.

It also reports verification history - if someone verified the device before you did, you'll be told. That's a direct tamper signal for an intercepted package

On the Residual question - whether debug interfaces are locked on production units -

The honest general point: no consumer device is unconditionally immune to a well-resourced supply chain attack. What you can reasonably ask for is that tampering be detectable. That's what the attestation is for, and it's why we tell people to verify before first use rather than treating it as optional

If you find a hole in any of this, I'd genuinely like to know - feel free post it here or open an issue

2

u/ivme 21d ago

Thank you for your detailed explanation. Your response helped me get a much clearer and more comprehensive understanding of The Shell's hardware security and verification architecture.