Java Card is the platform that runs inside billions of smart cards worldwide. If you've ever tapped a Visa or Mastercard, you've interacted with a Java Card applet.
We built our own. Here's what that looks like.
What Is Java Card?
Java Card is a stripped-down Java environment designed for smart cards and secure elements. It runs on chips with:
- 1-5 KB RAM
- 32-128 KB EEPROM
- 8-32 bit processors
Despite these constraints, it supports cryptographic operations, secure storage, and the APDU (Application Protocol Data Unit) communication protocol that EMV relies on.
JCOP4: Our Chip Platform
JCOP4 (Java Card Open Platform 4) is NXP's latest Java Card platform. It supports:
- Java Card 3.0.5 API
- GlobalPlatform 2.3
- P-256 ECDSA (critical for our use case)
- ISO 14443 contactless interface
- Common Criteria EAL5+ certification
The OpenPasskey Applet
Our applet does four things:
1. Key Generation
On first initialization, the applet generates a P-256 key pair inside the card's secure element. The private key never leaves the chip.
// Simplified flow
KeyPair kp = new KeyPair(KeyPair.ALG_EC_FP, KeyBuilder.LENGTH_EC_FP_256);
kp.genKeyPair();
// Private key is stored in chip's secure storage
// Public key is exportable for on-chain registration
2. EMV Protocol Implementation
The applet implements the EMV contactless protocol so that payment terminals recognize it. This includes:
- Application selection (AID matching)
- Get Processing Options
- Read Record
- Generate Application Cryptogram
Our AID is registered under our IIN from ISO. When a terminal selects our AID, it follows the standard EMV flow.
3. Transaction Signing
On each tap, the applet:
- Receives transaction data (amount, merchant ID, nonce, timestamp)
- Signs it with P-256 ECDSA using the card's private key
- Returns the signature, public key reference, and transaction metadata
4. NFC Communication
All communication happens via ISO 14443 (13.56 MHz NFC). The card harvests power from the terminal's RF field. No battery needed. Tap-to-response in under 500ms.
Host Card Emulation (HCE)
The same protocol runs on Android phones via Host Card Emulation. Instead of a physical chip, the phone's NFC controller emulates the card. The private key is stored in the phone's secure element or TEE (Trusted Execution Environment).
From the terminal's perspective, a phone tap and a card tap are identical.
The On-Chain Bridge
The card's P-256 signature is the bridge between physical world and blockchain:
- Card signs with P-256 (in the chip)
- Signature submitted to Base L2
- RIP-7212 precompile verifies the signature (~3,450 gas)
- ClearingVault settles the payment in stablecoins
This is the key insight: EMV cards already produce cryptographic signatures. We just verify them on-chain instead of through Visa's network.
Why P-256 Over secp256k1?
Ethereum uses secp256k1. EMV cards use P-256. These are different elliptic curves.
We use P-256 because:
- It's the EMV standard (compatibility with 11B+ cards)
- Java Card chips have hardware acceleration for P-256
- RIP-7212 makes on-chain verification economical
- It's the same curve as TLS 1.3, FIDO2, and Apple Secure Enclave
The Result
3,200+ users across 20+ Sydney cafes. Three payment methods (card, phone, QR) through one settlement pipeline. All starting from a Java Card applet on a JCOP4 chip.
Top comments (0)