JavaCard is the global standard for secure smart card applications, running on an estimated 15 billion cards worldwide. We develop on NXP JCOP 4.5 P71 — the most advanced JavaCard platform available.
JavaCard is a subset of the Java programming language tailored for resource-constrained smart cardhardware. It provides a portable, secure execution environment that isolates applets from each other andfrom the underlying hardware, making it the trusted foundation for identity, payment, and authenticationapplications worldwide.
The JavaCard architecture consists of three core components: the Java Card Virtual Machine (JCVM),which executes the compiled bytecode; the Java Card Runtime Environment (JCRE), which managesapplet lifecycle and inter-applet communication; and the JavaCard API, which exposes cryptographicprimitives, I/O channels, and security services to applet code.
Security is enforced at every layer. The JCVM’s bytecode verifier ensures that no applet can accessmemory outside its designated heap. The firewall mechanism prevents unauthorised sharing of objectsbetween applets. Cryptographic keys are stored in non-volatile memory and are never exported inplaintext — they are referenced only through opaque key handles within the applet’s own securitydomain.
The current specification, Java Card 3.1, introduced extended APDU support, improved multi-selectable
applet semantics, and extended the cryptographic API to include modern elliptic curve operations.
Cryptnox develops exclusively to Java Card 3.1 on the NXP JCOP 4.5 P71, which provides full compliance with this specification alongside significant hardware-level extensions.
Cards worldwide running JavaCard across payment, identity, and authentication use cases
JCVM, JCRE, and JavaCard API form the
complete runtime architecture
Current specification — the platform we target
for every development engagement
The NXP JCOP 4.5 P71 is the most capable secure element available on the commercial market. It is builton NXP’s P71 security controller, which combines an ARM SC300 processor core with the FAME3cryptographic coprocessor — a hardware accelerator supporting ECDSA, RSA, and symmetric operationsat speeds that make NFC-constrained transaction windows easily achievable.
The P71 carries an EAL6+ Common Criteria certification, the highest assurance level for commerciallyshipping secure elements. This certification covers the hardware, the JCOP operating system, and theGlobalPlatform implementation, giving integrators a complete security package without any additionalevaluation burden. The platform is compliant with EMVCo, FIDO2, and ISO/IEC 7816.
What distinguishes JCOP 4.5 from earlier generations is the SecureBox coprocessor environment, whichallows native C code to run inside the secure element alongside standard JavaCard applets. Thiscapability — unique to the P71 platform — allows Cryptnox to implement cryptographic algorithms thatare simply not available through the JavaCard API: Keccak-256, BLAKE2b, Poseidon, RedDSA, andBLS12-381 among others. The result is a platform that can address any cryptographic requirement,including the exotic primitives demanded by modern blockchain protocols.
JCOPX crypto extensions · ECCMath API · SecureBox environment
Standard crypto API · GlobalPlatform 2.3 · Applet lifecycle
ARM SC300 · FAME3 coprocessor · TRNG · EAL6+ certified
The JavaCard API covers a well-defined set of cryptographic primitives that have been stable for years:RSA, AES, 3DES, ECDSA over NIST curves, and a handful of hash functions. This set is sufficient fortraditional applications — payment, identity, FIDO2 authentication — but it leaves an entire generation ofmodern cryptographic protocols unsupported.
NXP SecureBox is the answer. It is a native C execution environment embedded in the JCOP 4.5 P71’ssecure enclave that runs alongside the JavaCard VM. SecureBox modules are compiled C binaries thatexecute directly on the hardware, with access to the full cryptographic coprocessor and without theabstraction overhead of the Java layer. They are callable from JavaCard applets through a definedinterface, bridging the gap between standard JavaCard and custom hardware-level implementations.
Cryptnox has implemented and productionised SecureBox modules for the following algorithms, all ofwhich are unavailable through any standard JavaCard API on any other commercial platform. Theseimplementations have been tested against official test vectors and are running in deployed Cryptnoxhardware wallets today.
Ethereum address derivation and transaction signing. The original Keccak variant used by Ethereum, distinct from the NIST SHA-3 standardisation.
Zcash protocol hashing as specified in RFC 7693. Used in the Zcash transaction commitment scheme and Sapling note commitments.
StarkNet zero-knowledge proof circuits. The specific Poseidon
instantiation used in StarkNet’s Cairo VM for on-chain state commitments.
Mina Protocol on-chain state hashing. The Kimchi-instantiated Poseidon variant used in Mina’s recursive SNARK proof system.
Zcash Orchard shielded transactions. The RedDSA signature scheme over
the Pallas curve used in Zcash’s Orchard protocol.
Ethereum 2.0, Filecoin, and Chia signatures. Pairing-friendly elliptic curve used for threshold signatures and proof aggregation.
APDU protocol design, command and response structure definition, security domain configuration, and non-volatile memory layout planning for optimal performance and longevity.
ECDSA, EdDSA, ECDH, SCP03 key agreement, certificate parsing and generation, key derivation schemes, and secure channel establishment over standard and extended APDU.
Security domain setup, SCP02 & SCP03 channel configuration, applet lifecycle management, delegated & authorised management, & multi-provider deployment architectures.
Hardware accelerator utilisation, NFC transaction timing analysis, APDU batching optimisation,
EEPROM write minimisation, and power budget profiling for contactless use cases.
Test vector validation against NIST & protocolspecifications, integration testing with PC/SC & NFC readers, stress testing under realistic transaction loads, & timing analysis for side-channel resistance assessment.
In addition to applet-level development, Cryptnox offers operating system level customisation of theJCOP 4.5 environment. OS customisation sits below the JavaCard layer and governs how the cardmanager, security domains, and lifecycle states are configured before any applets are loaded. Theseconfigurations are permanent and cannot be altered after card issuance, making correct initialspecification critical.
We work directly with NXP’s configuration toolchain to define root security domain key sets, establish thesecurity domain hierarchy, configure lifecycle state transition policies, and build personalisation scriptsfor production key injection. This service is typically required by enterprise customers who need tomaintain full operational control over issued cards, independent of any third-party applet provider.
Root security domain key definition, initial authentication mechanism selection, and card manager privilege assignments that govern all subsequent applet loading and management operations.
Multi-provider application isolation through supplementary security domains, delegated management privilege chains, and authorised management configurations for
controlled third-party applet deployment.
Per-state operation policies defining which commands are permitted in OP_READY, INITIALISED, SECURED, and LOCKED card states, with transition triggers appropriate
to the deployment model.
Production key injection sequences, card profile data personalisation, initial applet pre-loading, and post-issuance lock-down procedures for batch card manufacturing
workflows.
JavaCard development uses the high-level Java Card 3.1 API — well-documented, portable across JavaCard-compliant chips, and ideal for standard cryptography (RSA, ECDSA on P-256/P-384, AES, SHA-2/3) plus applet business logic. NXP SecureBox is a native C runtime, JCOP-specific, that exposes lower-level access to the FAME3 cryptographic coprocessor. SecureBox is the right choice when you need cryptography outside the JavaCard API — exotic curves (Pallas, BLS12-381), custom hash functions (Poseidon, BLAKE2), or signature schemes that have no JavaCard primitive. Most real projects are a hybrid: JavaCard for the applet shell and standard operations, SecureBox for the protocol-specific cryptography.
Yes. Cryptnox hardware wallet cards run on the same JCOP 4.5 P71 platform and support multi-application loading. A custom applet can coexist with the wallet applet, sharing the secure element’s tamper-resistance while staying isolated by GlobalPlatform secure channels. This is a common pattern for enterprises that want both a hardware wallet and a custom signing applet (document signing, identity attestation, or domain-specific tokens) on the same card.
Standalone JavaCard applets: 3–6 months from kickoff to production. Hybrid JavaCard + SecureBox projects: 6–9 months. Variation depends on the complexity of the applet logic, the host-side integration scope, and whether Common Criteria evaluation is required (add 6–12 months for the certification lab).
Yes. We supply JCOP 4.5 P71 cards in development quantities (50–100) for engineering and integration testing, then production quantities (1,000+) for rollout. Cards are available in dual-interface (contact + NFC) form factor with optional MIFARE DESFire EV2 4K coexistence. Custom artwork, embossing, and personalization are handled in the production phase.
Contact our engineering team to discuss your JCOP development project.
Overview of our development capabilities on NXP JCOP 4.5 P71. Learn more →
NXP JCOP P71 secure element integration for IoT, payments, identity, and blockchain. Learn more →
White-label hardware wallet cards for any blockchain protocol — including non-standard cryptography. Learn more →
Card-form-factor FIDO2 keys for enterprise authentication and passkey deployments. Learn more →
Dual-interface NFC smart cards for access, identity, supply chain and multi-application use cases. Learn more →
Real-world SecureBox / JavaCard projects on NXP JCOP P71 — verified on production hardware. Learn more →
