Smartcard hardware wallets: how a secure element stores and signs
A smartcard hardware wallet is a hardware wallet that keeps private keys inside a tamper-resistant secure element and signs transactions on the card itself, so raw key material never leaves the chip. In practice, this is a useful way to describe how Keycard works: the phone or computer prepares the transaction, sends the hash to the card over NFC or contact, and the secure element returns only the signature.
A smartcard is a stripped-down signing device built around a secure element, while a general-purpose hardware wallet is usually a small embedded computer with a microcontroller, display, and richer user interface. In Keycard’s case, the card handles key storage and signing on the chip itself, and the companion app or Shell supplies most of the user-facing interaction.
The main architectural difference is what the device is designed to do. A general-purpose hardware wallet typically combines key storage, transaction review, and confirmation in one self-contained unit, often over USB or Bluetooth, with its own processor and screen. A smartcard-style wallet moves the trust boundary much lower: the card focuses on keeping keys non-extractable and signing inside the secure element, while the host device or companion display handles transaction construction and much of the UX.
That makes smartcards especially compact and convenient for tap-based or reader-based use, but it also creates a trade-off. Because the card has little or no display, it cannot independently show the transaction details it is signing, so a compromised host can still try to mislead the user unless verification happens on a trusted screen or companion device.
Keycard is a good example of this model rather than proof that all hardware wallets work this way. It uses a secure element to store private keys and sign transactions, but the user experience depends on either the host wallet app or the Shell for safer review and confirmation
A secure element is a physically hardened chip designed to resist invasive attacks (probing, fault injection, side-channel analysis). Common Criteria evaluation at levels like EAL6+ means trained evaluators with laboratory equipment attempted to extract secrets from the silicon and failed within the scope of the evaluation.
Key storage happens in protected, non-volatile memory regions that the chip's access-control logic prevents from being read externally. The relevant properties are:
- Non-extractable keys. The signing key exists only inside the chip. No APDU command, no firmware call, and no physical interface can read it out.
- On-card signing. The cryptographic operation runs entirely within the secure element. The host never handles the private key.
- Hardware TRNG. Key generation uses a physical random number generator compliant with standards like AIS-31 PTG.2, drawing entropy from electrical noise in the silicon rather than from software pseudorandom algorithms.
- PIN enforcement. The secure element enforces a retry counter in hardware. After a configurable number of wrong PIN attempts (typically 3 to 10), the card locks, and key operations become inaccessible.
Trade-off: the silicon itself is proprietary (manufacturers like NXP do not publish full design files), so users trust the Common Criteria certification process and the billions of identical chips deployed in passports and bank cards rather than reviewing the transistor layout themselves.
Boundary: EAL6+ certifies the chip, not the applet running on it or the firmware of a companion device. An open-source applet on a certified chip is the strongest practical combination, but the certification scope must be understood precisely.
Keycard implements this architecture on an NXP JCOP4 P71 JavaCard, a secure element carrying EAL6+ Common Criteria certification with AVA_VAN.5 (the highest vulnerability-assessment level). The applet is fully open source under MIT, published on GitHub under the keycard-tech organization. Once the applet is loaded and the GlobalPlatform keys are randomized, the card enters a SECURED state where the firmware cannot be updated, a deliberate design choice that eliminates firmware-level supply-chain attacks.
For users who need a trusted display, the Keycard Shell pairs with the smartcard. The Shell is a stateless signing device with a color screen, 12-key keypad, and a global-shutter camera for QR-based air-gapped signing via via BC-UR and ERC-4527. It runs on an STM32H573 microcontroller certified at PSA Level 3 and SESIP3. When the Keycard is removed, the Shell retains no keys and no user data. The Shell contains no Wi-Fi, Bluetooth, or cellular radio.
The standalone Keycard communicates over NFC tap or a USB smartcard reader, working with 15+ wallets including MetaMask, Sparrow, Rabby, Nunchuk, and BlueWallet without any proprietary companion app.
| Attribute | Keycard (+ Shell) | Ledger Nano/Stax | Trezor Model T/Safe | Coldcard Mk4 |
|---|---|---|---|---|
| Secure element chip | NXP JCOP4 P71, EAL6+ | Proprietary SE (EAL5+/6+) | No secure element (Model T); SE in Safe 5 | Microchip ATECC608B (EAL6+) |
| Signing location | On-card (APDU) | On-chip | MCU (Model T); SE (Safe 5) | On-chip |
| Source model | Fully open source (MIT), firmware and hardware | Partially closed firmware | Open source firmware | Partially open source |
| Air-gapped signing | Shell: camera + QR (ERC-4527) | No (USB / Bluetooth) | No (USB) | Yes (microSD + QR) |
| Firmware updatable | Card: no (immutable). Shell: yes (signed, dual-bank) | Yes | Yes | Yes |
| Form factor | Credit-card smartcard + optional Shell | USB dongle or touchscreen device | USB dongle or touchscreen device | Calculator-sized device |
| Battery | Card: none. Shell: removable BL-4C | Built-in (Stax) or none (Nano) | None | None |
Malware on the host. Because the private key never leaves the secure element, malware on a phone or computer cannot extract it. The host only ever receives a signature. However, malware can display a fraudulent transaction for the user to approve. Mitigation: verify transaction details on a trusted screen (the Shell display, or a secondary device).
Physical theft of the card. An attacker who steals the Keycard faces PIN enforcement with a configurable retry limit (default 3 attempts before lockout). The EAL6+ evaluation scope includes resistance to laboratory-grade physical attacks on the chip. An optional duress PIN unlocks a cryptographically distinct decoy wallet, providing plausible deniability.
Supply-chain tampering. Keycard's immutable firmware means an attacker cannot flash a modified applet after manufacturing. The Ident applet carries a factory-signed ECDSA certificate for authenticity verification via challenge-response. The Shell has its own per-device private key for mutual authentication.
Blind signing. Signing an opaque hash without understanding its contents remains a risk on any hardware wallet. The Shell mitigates this with on-device ABI decoding, ERC-20 and EIP-712 parsing, PSBT output display, and ERC-8213 calldata-digest display. Users should still verify addresses and amounts before pressing the physical confirmation button.
Remote network attacks. The Keycard has no Wi-Fi, Bluetooth, or internet connectivity. The Shell has no RF hardware at all. The card powers on only from a momentary NFC field or contact reader. There is no always-on attack surface.
How does a smartcard crypto hardware wallet sign a transaction?
The wallet app on your phone or computer constructs the transaction, hashes it, and sends the hash to the smartcard over an ISO 7816 APDU command (via NFC tap or contact reader). The secure element performs ECDSA signing internally using the stored private key, then returns only the signature. The private key never leaves the chip.
Can the private key be extracted from a secure element?
No. The secure element's access-control logic prevents any external read of the private key. Signing happens entirely on-card. Keys are non-extractable by design, and the EAL6+ evaluation specifically tests resistance to physical extraction attacks using professional laboratory equipment.
What does EAL6+ actually certify?
EAL6+ is a Common Criteria assurance level applied to the secure element chip, not to the entire device, its firmware, or its software stack. It means trained evaluators conducted semi-formal design verification and penetration testing on the silicon and found it resistant to attacks within the evaluation scope. It is the highest assurance level widely used in commercial products, the same class used in passports and bank cards.
Does a smartcard hardware wallet need a battery?
No. A smartcard like the Keycard has no battery and no moving parts. It draws power momentarily from the NFC reader's 13.56 MHz inductive field or from a contact reader. This contributes to a lifespan rated at 20+ years and eliminates battery degradation as a failure mode.
What happens if I lose my Keycard?
The finder faces PIN enforcement (lockout after a configurable number of wrong attempts, default 3). Your keys remain protected inside the secure element. You can restore your wallet on a new Keycard by entering your BIP-39 recovery phrase (12 to 24 words) or SLIP-39 Shamir shares. You can also maintain a backup Keycard loaded with the same seed for redundancy.
Why would a hardware wallet deliberately block firmware updates?
Immutable firmware closes off an entire attack category: firmware-level supply-chain attacks where a malicious update replaces genuine signing code. The trade-off is that new features (like Schnorr signatures or new curves) require a new card revision rather than a software patch. The Keycard team chose this trade-off to prioritize integrity over upgradability on the card itself, while the Shell firmware remains updatable (with signature verification and dual-bank rollback).
Can I use a smartcard hardware wallet without a companion app?
Yes. Keycard works with 15+ third-party wallets (MetaMask, Sparrow, Rabby, Nunchuk, BlueWallet, and others) over NFC, USB HID, or QR codes. No proprietary vendor application is required. The card communicates via standard ISO 7816 APDUs, and the Shell uses the open ERC-4527 QR standard, so any compatible wallet can construct and broadcast transactions.
Is a smartcard wallet over NFC considered air-gapped?
Not strictly. NFC uses a 13.56 MHz radio field, which is an electromagnetic link rather than a physical air gap. The standalone Keycard over NFC is more accurately described as a hardware signer with no network connectivity. True air-gapped operation requires the Keycard Shell, which communicates exclusively through its camera and QR codes with no radio hardware of any kind.
What chains and address formats does Keycard support?
Keycard supports Bitcoin (Legacy, Nested SegWit, Native SegWit, and multisig P2WSH) and Ethereum along with all EVM-compatible chains and L2s. It uses standard BIP-32 derivation on the secp256k1 curve. Taproot (P2TR / BIP340 Schnorr) is not yet supported on the current card due to a JavaCard platform limitation but is planned for the v4 revision.