🔐

The chip that holdsyour keys.

The NXP J3R200 is an EAL6+ certified secure element — the same class of chip used in passports, bank cards, and government IDs. Your private key is generated inside it, lives inside it, and has never existed anywhere else. No server, no cloud, no seed phrase. Just the chip.

Look inside the silicon ↓

Lesson 1

What is a "secure element"?

🏰

A vault built to be used, never opened

A secure element is a tiny, single-purpose computer designed to do one thing: protect a secret. It is the same class of tamper-resistant silicon used in passports, SIM cards, and bank cards. It is built so the secret it holds can be used — to sign a transaction — but never read out. Not by the app, not by your phone, not by us.

FrostCard's chip is the NXP J3R200 — a member of NXP's JCOP4 / SmartMX3 (P71) family. It is not a general-purpose processor that happens to keep secrets. It is purpose-built so that secret-keeping is the only thing it is good at.

In plain wordsAn ordinary computer chip is a room anyone with the right tools can walk into. A secure element is a vault with no door — you can post a request through a slot and get an answer back, but you can never reach inside.

Lesson 2

What's inside the silicon

The whole chip is a handful of square millimetres, yet every block on it exists to protect one number. Here is what is actually etched into it:

ARM SecurCore processor

Designed for security, not performance. Every cycle is built around protecting secrets — not raw speed.

Hardware crypto accelerators

secp256k1, AES-256, SHA-256 all run on dedicated circuits. Not software running on a general CPU — actual dedicated silicon, which is both faster and far harder to spy on.

True Random Number Generator (TRNG)

Uses physical electrical noise — thermal fluctuations in transistors — to produce entropy. Not a pseudo-random algorithm. Actual physics. This is what generates your private key.

Persistent EEPROM

Where your private key lives. Retains data without power for 25+ years. The key goes from the TRNG into EEPROM and never touches an external bus.

Active shield mesh

A web of fine conductive traces covering the entire chip. If anyone tries to drill in, probe with a needle, or cut into the die, the mesh breaks and the chip wipes all keys instantly.

What "tamper resistance" meansThe chip doesn't just hide the secret — it actively watches itself for attack. Drill into it, freeze it, blast it with a laser, and its built-in sensors notice and erase the key before the attacker can read it. The defense is physical, not just a password.

Lesson 3

What "EAL6+ certified" actually means

You'll see the phrase "EAL6+ certified" attached to this chip. It sounds like marketing. It isn't — it's a measured, independently audited claim under an international standard called Common Criteria.

🏅

A grade earned in someone else's lab

Common Criteria is an international framework (ISO/IEC 15408) for evaluating how trustworthy a security product is. The Evaluation Assurance Level (EAL) runs from 1 to 7 — the higher the number, the more rigorously the design was inspected, the source reviewed, and the hardware physically attacked by an independent accredited lab. EAL6+ sits near the very top, the tier reserved for high-value targets like banking and government ID.

EAL6+, in plain wordsIt's a report card the manufacturer doesn't get to grade themselves. A separate licensed lab spent months trying to break the chip — power analysis, lasers, probes — and certified how far it held. EAL6+ means it survived attacks most chips are never even tested against.

Composite certificationA secure-element wallet has two layers: the silicon (hardware) and the JavaCard platform running on it. Composite certification means the certified operating layer was evaluated on top of the certified hardware — so the whole stack is assured together, not just one piece in isolation.

Lesson 4

JavaCard — the open standard on the chip

The hardware is only half the story. The other half is the code that runs on it. FrostCard's firmware is written in JavaCard — an open standard maintained by Oracle — and runs as an applet inside a JavaCard Virtual Machine on the chip.

🧩

A sealed sandbox for each program

The JavaCard VM is a tiny runtime that runs small programs (applets) inside strict, isolated walls. Two applets on the same chip physically cannot read each other's memory — the VM enforces it. It's the same isolation model SIM cards have used for decades. FrostCard's applet is fully open source: you can read the exact code that generates your key.

What the JavaCard VM isThink of it as a referee living on the chip. Every program must play by its rules, and the rules guarantee one program can never peek into another's private storage. The secure element provides the locked walls; the VM makes sure no code can climb over them.

Lesson 5

Open firmware vs. closed firmware

This is the single biggest difference between FrostCard and Tangem. Both use EAL6+ chips. The question is: what code runs on that chip, and can you see it?

FrostCard

OPENCard firmware (JavaCard applet)
OPENKey generation code
OPENRandom number usage
OPENSigning logic
OPENSecure channel protocol
OPENBackup linking code
OPENMobile app
OPENCovenant scripts

Tangem

CLOSEDCard firmware (proprietary OS)
CLOSEDKey generation code
CLOSEDRandom number usage
CLOSEDSigning logic
CLOSEDSecure channel protocol
CLOSEDBackup linking code
OPENNFC SDK (comms layer only)
No covenant support

Why this mattersFrostCard's applet is fully open source. You can read the exact code that generates your key, verify the randomness is real, and confirm there's no backdoor. Tangem runs a proprietary OS whose key-generation code has never been seen by anyone outside their company — you're trusting their engineers got it right.

Anyone can buy blank NXP J3R200 cards, compile the FrostCard applet from source, flash them themselves, and know exactly what code is running on their chip. Try that with Tangem.

Lesson 6

How your key is born

The private key never comes from a factory, a server, or the app. The chip mints it itself, inside the sealed walls. Here's the exact sequence:

1

Power the chip

You tap the card on your phone. The NFC field powers the chip — no battery, no wire, just harvested radio energy.

2

Request a key

The app sends a GENERATE_KEY command through the encrypted channel.

3

Roll physical dice

The chip's TRNG samples physical noise — thermal fluctuations in transistors — and produces 256 bits of true randomness.

4

Mint the key pair

The hardware crypto engine uses that entropy to generate a secp256k1 key pair — entirely inside the secure element. The private key goes straight from the generator into EEPROM.

5

Return only the public half

The 33-byte compressed public key is returned to the app. The private key stays on the chip — never in RAM, never on a bus, never visible to any external component.

The whole pointYou can read the open-source applet and verify the key generation uses the hardware TRNG, that no copy is made, and that the private key goes directly into protected storage. With Tangem you trust their closed firmware does the same. Maybe it does. You can't check.

Lesson 7

Every known attack — and why they all fail

The NXP J3R200 is certified EAL6+ by independent labs. Here's what that means in practice — every way someone could try to extract your key, and the hardware defense that stops them.

What a side-channel attack isMost of these don't try to read the secret directly — they watch the chip's side effects (power draw, electromagnetic leakage, timing) and try to infer the secret from how it behaves. A side-channel defense makes those side effects carry no useful signal.

Power analysis

Attacker measures the chip's power consumption during signing to statistically reconstruct the key.

Randomized execution order, dummy operations, constant-time crypto, noise injection. Each power trace is unique. Would require thousands of traces with physical wires soldered to the chip.

Electromagnetic emanation

Measuring EM radiation from the chip during operation to guess what it's computing.

Same randomization countermeasures as power analysis plus EM shielding in the metallization layers. Signal-to-noise ratio is too low.

Voltage glitching

Spiking the power supply to make the chip skip a security check or corrupt a comparison.

Hardware voltage monitors trigger an immediate reset. Critical operations use redundant checks across independent circuits.

Clock manipulation

Speeding up or slowing down the clock to cause timing errors in security logic.

Internal clock monitor compares external clock against an on-chip reference. Out-of-spec clock triggers reset.

Laser fault injection

Firing a focused laser at specific transistors to flip bits in memory or skip instructions.

Active shield mesh detects light penetration. Photodiodes on the die trigger a key wipe. Multi-layer metallization blocks access to lower circuits.

Physical probing

Using microscopic needles to tap into data buses and read the key as it moves through the chip.

Active shield mesh — probing breaks a trace, triggering a wipe. The key never travels on an external bus. Signing happens inside the crypto engine; the key goes from EEPROM to engine and back.

Focused Ion Beam (FIB)

Using a $2M particle beam machine to physically rewire individual traces on the chip at the nanometer scale.

Active mesh must be navigated without breaking it. Randomized layout changes between production batches. Multi-layer metallization. No publicly documented successful FIB attack on a JCOP4 chip. Ever.

Cold boot / memory freeze

Rapidly cooling the chip to preserve memory contents after power is removed.

The key is in EEPROM (persistent storage), not volatile SRAM. Nothing to freeze. Key material in temporary memory during signing is encrypted with hardware-derived session keys.

Malicious applet

Installing a second applet on the chip that tries to read the FrostCard applet's key storage.

JavaCard VM enforces strict memory isolation. Applet A physically cannot access Applet B's storage. GlobalPlatform controls installation with cryptographic authorization. Same isolation model SIM cards have used for decades.

NFC eavesdropping

Intercepting the radio signal between phone and card from nearby.

Every session uses ECDH key exchange + AES-256 encryption + HMAC-SHA256 authentication. Attacker sees encrypted noise. Ephemeral keys — no session is ever reusable.

The Bottom Line

Born on the silicon. Dies on the silicon.

No one has ever extracted a private key from this class of chip. Not with a $50K oscilloscope. Not with a $2M focused ion beam. Not with any known technique. The key is born on the silicon, lives on the silicon, and dies on the silicon.

And even if someone broke through all of that — past the chip, past the PIN, past the NFC encryption — they still face the covenants. The Kaspa network itself says: you can only send to these addresses. Or: these funds are frozen until 2027. That's the layer no other hardware wallet has.

Going Deeper

What happens during a tap

1

Field on

Phone's NFC antenna generates an electromagnetic field.

2

Boot from radio ~100 ms

Card's antenna harvests power from this field (a few milliwatts). Chip boots in ~100 ms.

3

Build the encrypted tunnel

ECDH key exchange — phone and card each generate a fresh ephemeral key pair, swap public keys, derive a shared AES-256 session key. Encrypted tunnel established.

4

Verify the PIN

PIN verification through the encrypted channel.

5

Send what to sign

App sends transaction hashes (32 bytes each) through the tunnel.

6

Sign inside the silicon

Chip's hardware crypto engine signs each hash with Schnorr. The private key goes from EEPROM into the signing circuit and back — never through an external bus.

7

Return the signatures

64-byte signatures return through the encrypted tunnel.

8

Power drops, session dies

Phone pulls away, power drops, chip shuts down. Ephemeral session keys are gone forever.

Don't Trust — Verify

Read the code that runs on the chip

Every line of firmware that touches your key is public. Because the applet is written in JavaCard — an open standard — and is fully open source, you don't have to take any of this on faith.

Compile and flash it yourself

Buy blank NXP J3R200 cards, compile the FrostCard applet from source, flash them, and know exactly what code is running on your chip. The randomness, the key generation, the signing logic, the secure channel — all of it is open.

The security contract

Keys stay in silicon. The private key is generated by the card's TRNG and never leaves the secure element. Nothing outside the card may accept, store, transport, or cache it — not raw, not encrypted, not split. It is the first non-negotiable rule of the project, and the reason the chip is built the way it is.