[ANN] Keycard Shell – Open-Source, Multi-Card Hardware Wallet

[guylouis]

I think I understand. Do you mean SEEDLESS in the sense that no display ever shows the seed phrase?

Nope, broadly speaking, seedless refers to a wallet that doesn’t rely on seed phrase to generate/recover its private key. AFAIK Tangem is currently the only hardware wallet that fully implements this approach, embedding the private key directly into the card itself. That said, we might see more seedless solutions in the domain of HW, especially if the developers behind certain projects stay committed to this concept. You can find more details about Tangem’s implementation over there. Once again, I’d like to refer to Zack Herbert's opinion, where he suggests that seed phrases will soon become obsolete.

When you use the 'seedless' mode with Tangem to setup your cards, one attacker that gets access to two of your cards can access to all your funds (without knowing your pin of course). We considered this type of recovery optionality is opening a too big attack surface.

Oh and also, based on your feedbacks, we confirm 25th passphrase will be implemented in Shell UI (it's already supported in keycard software), being tracked here: github issue

[walletbro]

I think I understand. Do you mean SEEDLESS in the sense that no display ever shows the seed phrase?

Nope, broadly speaking, seedless refers to a wallet that doesn’t rely on seed phrase to generate/recover its private key. AFAIK Tangem is currently the only hardware wallet that fully implements this approach, embedding the private key directly into the card itself. That said, we might see more seedless solutions in the domain of HW, especially if the developers behind certain projects stay committed to this concept. You can find more details about Tangem’s implementation over there. Once again, I’d like to refer to Zack Herbert's opinion, where he suggests that seed phrases will soon become obsolete.

Well, what do does and could 'seedless' mean? What about Keycard?
1) The wallet doesn’t show you a mnemonic, or
2) The wallet doesn’t even generate or store a mnemonic internally (it keeps only raw key material)

Not showing the words removes the classic paper backup. Great for physical-theft risk, bad if you lose the device.

Not having/generating/storing the words is merely an implementation choice.
Storing security hinges on how the underlying secret is protected. It's usually stored via master key, not mnemonic.
Generating a private key never 'relies on a seed phrase' in that sense. The seed phrase is just a human-readable encoding of the initial entropy.
The BIP-39/BIP-32 flow: Random entropy -> mnemonic 'seed phrase' -> 512-bit seed -> Master key pair -> keys/addresses

Tangem in its default setup is type (2): the secure element generates one ECC private key and clones it to 2-3 cards.
No BIP-32, which means you only get one address per asset. (there's a BIP-39 seed mode, which makes it 'non-seedless' if you will. but in that mode you only get the first address on each path.)

Keycard can be seedless (1) where you burn the paper after creating backup cards. Full BIP-32, so you can have as many addresses as you like.

We all agree that a pice of paper with 12 words is a single point of failure. That’s the gist of Zack Herbert’s argument as well: keep the secret encrypted, sharded, or inside hardware. I'm sure he'd like Keycard as encrypted backups.

[satscraper]

~

It seems we have a bit of different perspective on seedless wallets, but that’s totally fine ^{everyone is free to have their own views on this stuff}.

I do have one more question, though. Does the Keycard support the multisig scheme? In my opinion, having support for multisig would help alleviate some of my concerns about potential sidechain attacks, which could even originate from the manufacturer’s side. Sorry to bring this up, but it’s something I’ve been thinking about.

[dkbit98]

Good point on interoperabilty! Technically, any JavaCard can work with Shell. I've pinged Satochip to see if they'd like to integrate. Again, our full stack is open to contribution 

I would really like to see Keycared Shell supporting Satochip cards, and two teams working together.

Well, what do does and could 'seedless' mean? What about Keycard?

Please disregard any silly seedless ideas for hardware wallets, especially if they are not giving alternative option to users.
We already saw how ''seedless'' closed source tangem really is when they leaked keys via their mobile app resulting in people losing coins.
Tangem even had a bug in 2024 that exposed seed phrases via email, so I would never use or recommend crap like that to anyone.

[NotATether]

• Radical Open Source: Hardware & software are MIT-licensed – schematics, PCB layouts, BOM, Java Card applet, CAD files… audit, modify, even 3D-print your own case

Now, due the type of work I do, I happen to know a bit about CAD and Java, but where on earth do I learn about how PCB layouts work? How schematics work? What BOM is and so on so forth.

It's good that all this is open-source, but I think we need to spend some time educating people on what these items actually are.

• Duress PIN: enter a second PIN under coercion to reveal a decoy wallet

I feel like Duress PINs are flawed because they can keep hitting you until you reveal all of the PINs.

[satscraper]

Well, what do does and could 'seedless' mean? What about Keycard?

Please continue working on implementing the "seedless" functionality along side with traditional SEED. As Zack Herbert ^{who is far from being silly} pointed out, it’s an important step for progress in the HW domain. Ensuring that the Keycard Shell can support unlimited number of cards with the ability to back up seedless keys will greatly enhance the utility of such mode. The availability of this feature would expand the Keycard's niche. Just because some users may not require this mode doesn't mean others wouldn't benefit from it.

BTW, expecting to hearing back regarding my previous question on multisig support.

[walletbro]

~

It seems we have a bit of different perspective on seedless wallets, but that’s totally fine ^{everyone is free to have their own views on this stuff}.

I do have one more question, though. Does the Keycard support the multisig scheme? In my opinion, having support for multisig would help alleviate some of my concerns about potential sidechain attacks, which could even originate from the manufacturer’s side. Sorry to bring this up, but it’s something I’ve been thinking about.

Yes, multisig is planned for Shell until release in October. And, Shell's current fw supports UR2.0 and uses PSBT - so, you would be able to check networks based on derivation path

[walletbro]

Our new release (v0.9.17) improves a couple of aspects of BIP39 Mnemonic entry. Including passphrases: https://github.com/keycard-tech/keycard-shell/releases

[dkbit98]

Our new release (v0.9.17) improves a couple of aspects of BIP39 Mnemonic entry. Including passphrases: https://github.com/keycard-tech/keycard-shell/releases

This is a very good update, but I would recommend adding support for SLIP39 in future.
I also hope there is optional way to use Keycard Shell only with Bitcoin code, if possible.

Can you tell me from what country you are sending Keycard Shell devices, is it Switzerland or some other country?

[walletbro]

Another week, another update: https://github.com/keycard-tech/keycard-shell/releases

Shell supports Bitcoin Multisigs now.
Also, SeedQR import.

SLIP39 is definitely worth a consideration.

[dkbit98]

Keycard just released their new affiliate program that can earn 10% commission on each referral you make, and give your referred friend a 5% discount.
This is a good idea if you are planning to purchase their new Ke<card Shell wallet, but please note that you need to wait for Keycard team to approve your application.
You can find more information on this page:
https://affiliates.keycard.tech/

[tenant48]

Crypto Guide has released a video review of the Keycard Shell wallet and how it works with Java cards.

[dkbit98]

Crypto Guide has released a video review of the Keycard Shell wallet and how it works with Java cards.

He made a really good first review of Keycard Shell, and it's even better that he is going to try and make DIY version in future, since they released everything as open source.
It's also interesting that CryptoGuide is going to make Keycard cross-compatible with Seedsigner/Satochip soon.
Stupid projects like c0ldcard and NVK should learn something from Keycard guys.

[Meuserna]

Crypto Guide has released a video review of the Keycard Shell wallet and how it works with Java cards.

That guy is the best. His channel is such a great source of information.

For opsec purposes, I wish the Keycard cards didn't have that Key logo on them, but it's subtle, and it's a relatively generic logo, so it's not bad.

I'm impressed by this device. I'm a big fan of stateless devices.

[n0nce]

Our security model is quite different. It's modular: Shell is kept as simple as possible, while Keycard has the SE.
Even during signing, the keys don't leave Keycard

I see a problem when you physically separate the display from the secure element: address replacement attacks.
Sure, if you use an uncompromised 'Shell', it will display the recipient's address, but there are 2 scenarios where this falls short:

• The Shell has no secure element, no secure boot, i.e. it can be compromised (flashed with hacked firmware) and show a different address from what it's actually signing.
• Even easier: the cards work through NFC, so users may opt not to use the Shell at all, in which case the software wallet on their smartphone could be compromised and show a wrong address, without any way for the card to show that the transaction got tampered with.

This reduces security guarantees in regards to the attacker model 'address replacement attacks' to what one gets from any regular software wallet.
I hope I got something wrong, though, it's a pretty device!

[dkbit98]

That guy is the best. His channel is such a great source of information.

I totally agree, and he is one of the rear youtube guys I follow for hardware wallet and general wallet content.

I see a problem when you physically separate the display from the secure element: address replacement attacks.

I don't see any of examples you mentioned as real threat.
First they would need to javacard that is same as credit card secure element, and nobody did that so far.
And they don't have their own software wallet, so you need to use trusted open source wallets.

PS
They have everything released as open source, so I guess in theory it would be possible to implement second secure element on device.