Running on this bench today
running at the jNet bench
Javelin OS-PQC
Designed for FIPS 140-3. ML-DSA and ML-KEM run in the OS core. Java Card 3.3* PQC APIs.
running at the jNet bench
In-field upgrade
OS, crypto library, and applets are updated with all on-card data retained.
running at the jNet bench
Eclipse PQC plug-in
Wizard-generated PQC applet source matching the crypto-accelerated APIs.
running at the jNet bench
Windows enablement
Minidriver, KSP, and Credential Provider smart card logon.
running at the jNet bench
Cross-platform and mobile
PKCS#11 on Windows, Linux, and macOS; CCID + NFC for Android and iOS.
running at the jNet bench
PQC applets
PIV and FIDO2 first; crypto wallet, OpenPGP, EMV, ICAO, and mDoc.
Harvest now, decrypt later
Encrypted identity, payment, and authentication data collected today may remain readable after Q-Day.
Signature forgery at scale
Post-CRQC attacks on ECDSA could enable impersonation of trusted credentials and signing authorities.
Deployment lifetime mismatch
Devices approved today may still be active in the Q-Day window, making PQC a manufacturing-time decision.
The Threat Model
ECC still underpins credentials
ECC remains embedded in credential stacks shipping today across identity, payment, travel, and authentication use cases.
Algorithm Deep Dive
Two NIST standards
One Java Card OS
From Java Card runtime to PQC extension layers: structured for deployment, migration, and certification planning.
ML-DSA
NIST FIPS 204
CRYSTALS-Dilithium
Digital Signature Algorithm
ML-DSA is NIST's primary post-quantum digital signature standard. Android 17 ships ML-DSA for Verified Boot, Remote Attestation, and Keystore signing, the same scheme Javelin OS-PQC runs in the Java Card OS core. ML-DSA replaces ECDSA for code signing, applet attestation, ePassport active authentication, and PIV card authentication.
TECHNICAL PARAMETERS
Security level
ML-DSA-44 (L2), ML-DSA-65 (L3), ML-DSA-87 (L5)
Public key size
2,592 bytes (vs. 64 bytes for P-256)
Signature size
2,420 to 4,627 bytes
Java Card API
Java Card 3.3* API (final class names follow Oracle's
release)
Use in Javelin
PIV, FIDO2 attestation, applet signing
FIPS status
FIPS 204, final standard (August 2024)
MIGRATION ARCHITECTURE
Three deployment modes, one migration path
Javelin OS-PQC enables a phased migration from classical cryptography to hybrid and PQC-native deployment. Each mode is designed to support real production timelines, certification planning, and gradual rollout.
Mode 1
Classical
Today.
ECDSA / RSA / AES only
Full Java Card v3.2 compliance
Existing applets remain unchanged
No native PQC support
MODE 2
Hybrid
Through the 2030 and 2031 federal deadlines.
Classical + ML-KEM / ML-DSA in parallel
Dual-signature operation where required
Backward-compatible deployment path
Protected against both classical and quantum attacks
RECOMMENDED NOW
MODE 3
PQC Native
After migration, per issuer policy.
ML-KEM and ML-DSA only
Classical crypto disabled where required
Full FIPS 203 / 204 alignment
Lowest long-term attack surface
HYBRID IMPLEMENTATION
Same Java Card API surface across classical, hybrid, and PQC-native deployment modes
// Illustrative. Final class and constant names follow Oracle's
// Java Card 3.3* release. Javelin OS-PQC tracks the Java Card Forum draft.
Signature ecdsa = Signature.getInstance(Signature.ALG_ECDSA_SHA_256, false);
Signature mldsa = Signature.getInstance(PQC_ML_DSA_65 /* JC 3.3 identifier */,
false);
// Hybrid: two signatures over the same data, returned together
short len = ecdsa.sign(data, off, dlen, out, (short) 0);
len += mldsa.sign(data, off, dlen, out, len);
// ML-KEM decapsulation replaces ECDH for key establishment
// (KEM class per Java Card 3.3*; hybrid with ECDH supported)
HARDWARE SIZING
Sizing the part
Choose the silicon around the applet set, key set, and working-memory requirements of your PQC deployment.
SLC27
Contactless & dual-interface
Smartcards, eID and ePassport. Infineon’s Common Criteria-certified ML-KEM and ML-DSA library. In-field update and crypto agility.
SLC22
Tokens & embedded IC
TEGRION SLx22 family. jNet reference for tokens and embedded IC deployments. Size memory to the applet set and key set for your target configuration.
ML-DSA key generation and signing need working RAM, not just storage. Size the part to the applet set, then to the key set.
IN-FIELD UPGRADE
Upgrading a card already in the field
Update the OS, crypto library, and applets on cards already in the field while retaining critical on-card data. Separate upgrade paths keep the platform and applet layers manageable without card reissue.
Technical FAQ
