We design, develop, and deploy custom secure-element applets on NXP JCOP 4.5 P71 — in both JavaCard and native C via NXP SecureBox. Our core specialty is blockchain and wallet applets: on-card transaction signing, key custody, and on-card policy. The same team also delivers FIDO2 authentication, PIV identity, and OpenPGP applets — the PIV and OpenPGP applets build on the open-source OpenFIPS201 and SmartPGP (ANSSI) projects; see our open-source software notices.
The NXP JCOP 4.5 P71 pairs a JavaCard virtual machine with NXP’s SecureBox coprocessor for native C execution. That dual capability is what sets our blockchain work apart: when a protocol needs a curve, hash, or signature scheme that standard JavaCard APIs cannot express, we implement it in SecureBox native C — on certified secure-element hardware.
The JCOP P71 exposes three distinct programming surfaces. Cryptnox has mastered all three, enabling us to meet any custom development requirements.
These are not proofs-of-concept. Each project shipped to production hardware, passed comprehensive test vectors, and enabled real transactions on live networks.
The client required a hardware-rooted signing device capable of producing cryptographic hashes for multiple blockchain protocols — Ethereum(Keccak-256), Zcash (BLAKE2b-512, BLAKE2s-256), StarkNet (Poseidon-Stark252), and Mina Protocol (Poseidon-Mina/Kimchi). None of these hash functions is available in the standard JavaCard API. Implementing them in pure Java on the JVM would produce output too slowly for production use. The requirement was to run all five algorithms on a single card, with output verified against each protocol’s published test vectors.
We implemented a custom hash library in native C running in the NXP SecureBox environment on the JCOP P71. Each algorithm was implemented from its specification using constant-time C, with BLAKE2 variants sharing a common code base to conserve ROM space. The Poseidon implementations required adapting the MDS matrix and round constant parameters for both the Stark252 and Kimchi field configurations. A JavaCard host applet exposes all five hash functions to the card reader via a clean APDU command interface, with algorithm selection and output length validated at the API boundary.
All five hash function implementations were verified against the complete published test vectors for each protocol ecosystem.
| Algorithm | Output Size | Use Case | Status |
|---|---|---|---|
| Keccak-256 | 32 bytes | Ethereum | Verified |
| BLAKE2b-512 | 64 bytes | Zcash | Verified |
| BLAKE2s-256 | 32 bytes | Zcash / Filecoin | Verified |
| Poseidon-Stark252 | 32 bytes | StarkNet | Verified |
| Poseidon-Mina/Kimchi | 32 bytes | Mina Protocol | Verified |
This project demonstrates that exotic cryptographic hash functions — including sponge constructions, tree hashing, and algebraic hash functions optimized for zero-knowledge proof systems — can be implemented securely and efficiently on JCOP P71 using NXP SecureBox. It establishes that a single production smart card can serve as a hardware security module for multiple independent blockchain ecosystems simultaneously, with each implementation verified against protocol consensus requirements. This hash library is now available as a foundation for any project requiring non-standard hash operations on JCOP P71 hardware.
Zcash Orchard shielded transactions require a custom signature scheme called RedDSA over the Pallas elliptic curve — a prime-order curve defined over a 255-bit prime field, part of the Pasta curve family designed for recursive zero-knowledge proofs. The signature scheme requires BLAKE2b-based nonce derivation, randomized key derivation, and scalar multiplication on the Pallas curve, none of which exist in the JavaCard API or any standard smart card library. The client needed a hardware signing device capable of producing valid Orchard signatures accepted by the Zcash consensus layer, with private key material never leaving the secure element.
We implemented the full Pallas curve arithmetic in NXP SecureBox native C, including field arithmetic for F, point addition, point doubling, and scalar multiplication. The RedDSA signing protocol distributes operations between the host and secure element, keeping all private key operations exclusively on the card:
Signing performance was measured over 100 consecutive signatures on production hardware. All signatures were validated by Zcash consensus
verification routines.
Median signing time
Throughput
Signatures — stress test completed
This project demonstrates full end-to-end implementation of a modern privacy-preserving blockchain transaction signing protocol on production secure element hardware. It shows that Cryptnox can implement novel elliptic curve arithmetic for curves not present in any hardware security module vendor’s standard library, that the split host/card protocol architecture maintains Orchard’s security properties while delegating all critical private key operations exclusively to tamper-resistant hardware, and that the resulting implementation can produce signatures accepted by real blockchain consensus. The on-chain confirmation in a real Zcash regtest block validates the correctness of every step of the protocol, from key derivation through signature serialization.
BLS12-381 is the most widely deployed pairing-friendly elliptic curve, used for validator key signing in Ethereum 2.0, Filecoin storage proofs, and Chia consensus. Implementing BLS12-381 signing on a smart card requires G1 point arithmetic over a 381-bit prime field — significantly larger than the 256-bit fields common in Bitcoin/Ethereum ECDSA — combined with a hash-to-curve algorithm (hash_to_field + map_to_curve) that is computationally intensive. The initial challenge was performance: the first working implementation took 3,285ms for signing and 16 seconds for hash-to-curve, both far too slow for production use. The objective was to reduce total signing time to below 2 seconds without sacrificing correctness or security properties.
We implemented BLS12-381 G1 arithmetic entirely in NXP SecureBox native C, refined across several development iterations — moving to more efficient coordinate representations and leveraging the secure element’s hardware accelerators to make pairing-friendly curve operations viable on-card.
The implementation supports the BLS signature variants required by three major protocol ecosystems, sharing the same underlying G1 arithmetic with protocol-specific hash-to-curve and domain separation parameters:
Baseline
3,285ms signing 16s hash-to-curve First working build
Affine Coordinates
Switched from projective. windowed fp_pow optimization for inversion
Binary GCD
Variable-time inversion for public Z coordinate; further reduction
Hardware-accelerated
14× speed improvement for field inversions via hardware accelerator
Current
Optimized signing and hash-to-curve, constant-time
Fastest path signing time
Improvement from baseline
Optimized scalar multiplication
This project demonstrates that even computationally demanding pairing-friendly curve operations can be made viable on JCOP P71 through systematic optimization of NXP SecureBox native code and strategic use of hardware coprocessors. It shows the full optimization methodology available on this platform — from algorithmic improvements through hardware accelerator integration — and confirms that performance constraints are not a fixed limit but an engineering problem. The optimization path from first working build to production confirms that SecureBox enables a level of low-level performance engineering not available on any other smart card platform, and that multi-protocol BLS signing from a single hardware token is achievable at speeds compatible with production deployment.
These three case studies span the full spectrum of cryptographic primitive implementation on JCOP P71 — from hash functions to signature schemes to full field arithmetic for multi-protocol support. Together, they establish a proven capability baseline across three critical engineering dimensions:
Hash functions, signature schemes, and field arithmetic across the full spectrum of modern cryptographic primitives. From Keccak and Poseidon sponge constructions to Pallas and BLS12-381 curve arithmetic — all on a single hardware platform.
Constant-time execution, hardware-coprocessor integration and production-grade engineering throughout the stack.
Every implementation verified against published test vectors and real blockchain consensus validation. The RedDSA implementation was validated by an on-chain transaction in Zcash regtest. No claims without evidence.
Blockchain & Cryptocurrency
Custom hardware wallets for any blockchain protocol, including exotic curve and hash support unavailable in off-the-shelf products.
Financial Services & Payments
Payment applets, banking tokens, and the Cryptnox proprietary Card Wallet as a Service (C-WAAS) platform for financial-grade transaction security.
Digital Identity & Government
ePassports, government credentials, and high-assurance identity documents on CC EAL6+ certified hardware.
Enterprise Authentication
Custom FIDO2 security keys, corporate badge systems, and multi-application smart cards for enterprise identity programs.
IoT Device Security
Embedded secure element integration, device attestation, and secure firmware delivery for connected hardware platforms.
Cryptnox’s Card-Wallet-as-a-Service (C-WAAS) programme gives blockchain enterprises a complete white-label hardware wallet solution built on the same NXP JCOP 4.5 P71 secure element platform that powers our own retail product line. You receive a finished, certified hardware wallet card bearing your brand — without the multi-year development timeline of building secure element firmware from scratch.
Every white-label card ships with our production-tested wallet applet pre-loaded and personalised to your specifications. The card supports NFC tap-to-sign with iOS and Android, meaning your users can sign transactions by tapping their card to their phone — no USB cables, no dongles, no companion hardware required.
For blockchain protocols that require cryptographic primitives beyond the standard JavaCard API —including the RedDSA/Pallas signature scheme used by Zcash Orchard, or BLS12-381 used by Ethereum 2.0 validators — we implement these via NXP SecureBox native C and integrate them seamlessly into your white-label card’s applet.
Custom branding and visual design on the physical card
Pre-loaded wallet applet supporting required blockchain protocols
NFC tap-to-sign with iOS and Android mobile phones
BIP-32/39/44 hierarchical deterministic key derivation
SDK integration with your existing mobile application
Every protocol below has been implemented, tested with official test vectors, and verified on production hardware. Where a protocol requires a SecureBox native C implementation — such as the exotic curves and hash functions used by zero-knowledge proof systems — we have already done that work and can integrate it into your custom card engagement.
Bitcoin, Ethereum, all EVM chains
Zcash Orchard shielded transactions
Ethereum 2.0, Filecoin, Chia
Ethereum address derivation, EIP-712
Zcash protocol hashing
StarkNet
Mina Protocol
Solana, Cardano and more
The dominant hardware wallet form factor — a USB device with a screen and buttons — was designed for a desktop world where users manage crypto from a PC. The NFC card form factor was designed for a mobile-first world where users sign transactions from their phone. The hardware security guarantees are identical; the user experience is categorically different.
For enterprises building consumer-facing blockchain products, the card form factor offers an additional commercial advantage: the physical card is a branding surface. A white-label hardware wallet card can carry your logo, your colours, and your product identity in the same way a payment card does — reinforcing brand trust every time the user reaches for their wallet.
| Feature | USB Hardware Wallet | NFC Card Wallet |
|---|---|---|
| Size | Separate device | Fits in your wallet |
| Battery | Requires charging | No battery needed |
| Connectivity | USB cable | NFC tap |
| Durability | Screen can break | No moving parts |
| Cost at scale | Higher per unit | Lower per unit |
| Mobile use | Needs adapter | Native NFC tap |
FIDO2 and WebAuthn have become the global standard for phishing-resistant authentication. Most FIDO2 keys come as USB dongles — convenient for individual users but problematic at enterprise scale. Smart card form factor changes the equation entirely: the same ISO 7816 plastic credential that your employees already carry for physical access can simultaneously serve as their FIDO2 authentication token, accessible over NFC from any modern smartphone or reader.
Cryptnox implements FIDO2 natively on the NXP JCOP 4.5 P71 secure element — the same platform behind our own FIDO2 card product. The P71 holds a Common Criteria EAL6+ certification, the highest level commercially available in the smart card market, and is the basis for FIDO Alliance certification. Every private key generated for WebAuthn authentication never leaves the secure element and is protected against physical extraction even under laboratory conditions.
Our custom FIDO2 development service enables enterprises, governments, and platform providers to issue their own branded, customized FIDO2 credentials. You control the attestation certificates, the card art, the additional applications co-resident on the card, and the issuance infrastructure. The result is a FIDO2 deployment that is fully under your operational and security governance, not dependent on a third-party vendor’s credential store.
The NFC interface on JCOP P71 conforms to ISO 14443 Type A, enabling tap-to-authenticate on iOS 14+, Android 7+, and all modern NFC card readers. Authentication round-trip completes in under 500ms — indistinguishable from contactless payment in user experience. No drivers, no dongles, no USB-C adapters required.
Employees already carry their wallet everywhere. Smart card credentials live alongside payment cards and IDs — the natural home for authentication tokens. Lower loss rates than USB dongles that get left in laptop ports or forgotten at home.
One card replaces door badge, login smart card, and FIDO2 authentication token. A single physical credential manages physical access, Windows Hello for Business login, and WebAuthn authentication across all enterprise applications simultaneously.
Smart cards at enterprise volumes are significantly less expensive than USB keys per unit. Combined with reduced helpdesk burden from lost or broken tokens, the total cost of ownership improvement is substantial at deployments of 1,000 seats or more.
NFC tap works with any NFC-enabled phone on iOS 14+ or Android 7+. Employees authenticating from personal devices, kiosks, or shared workstations get the same phishing-resistant FIDO2 experience without needing a USB port or a specific cable adapter.
Standard FIDO2 certification is just the baseline. The JCOP P71 platform enables a range of customizations that are impossible with off-the-shelf security keys. Cryptnox has implemented each of these in production engagements and can deliver them as part of a custom development project.
Control the trust chain end-to-end. With your own attestation CA embedded in the card during manufacturing, your organization’s FIDO2 keys are
cryptographically distinguishable from all other credentials in any WebAuthn relying party. This enables conditional access policies that enforce “only our cards
can authenticate to these resources” at the protocol level, not just at the policy layer.
FIDO2 and PIV (Personal Identity Verification) co-resident on a single credential, or FIDO2 combined with a cryptocurrency hardware wallet on the same card. The JCOP P71’s multi-application JavaCard environment enables entirely novel credential combinations that solve operational problems no single-purpose token can address.
Custom provisioning workflows integrated with your identity provider, SCIM directory, or HR system. Deprovisioning that revokes the card’s FIDO2 applet remotely via GlobalPlatform Secure Channel without requiring physical retrieval. Inventory management APIs that give your security operations center real-time visibility into issued credentials.
Custom printing with your organization’s logo, employee photo, name, and access tier. Holographic overlaminates, UV-visible security features, and laser-engraving options are all available through our manufacturing partners. The card your employees carry every day becomes an expression of your security posture and organizational identity.
Financial services organizations face the most demanding authentication requirements of any industry. PSD2 in Europe, FFIEC guidance in the United States, and equivalent frameworks in every major banking jurisdiction mandate strong multi-factor authentication for customer-facing and internal operations alike. FIDO2 satisfies these requirements at the protocol level — and smart card form factor satisfies the physical security requirements that USB tokens cannot meet.
For customer-facing deployments, the smart card FIDO2 credential pairs naturally with existing payment card infrastructure. Your customers already receive a plastic card from your institution. Adding FIDO2 capability to that card — or issuing a companion authentication card — is operationally straightforward and leverages existing card issuance processes. The NFC tap gesture for authentication is identical to the contactless payment gesture customers already perform daily, reducing friction to essentially zero.
For internal bank operations, the convergence of physical access control and FIDO2 authentication onto a single employee credential is transformative. Treasury operations, wire transfer authorization, trading platform access, and administrative control panels all benefit from FIDO2’s phishing resistance. A compromised password alone cannot authorize a wire transfer if FIDO2 is in the path— the attacker would need to physically steal the employee’s card, which triggers physical security protocols entirely.
PSD2, FFIEC guidance, and national banking regulations mandate strong authentication. FIDO2 satisfies these requirements at the protocol level with cryptographic proof that cannot be phished or replayed.
The same tap gesture as contactless payments makes FIDO2 authentication familiar and intuitive for banking customers. Zero friction, zero new hardware required on the customer’s side beyond a smartphone.
Treasury, wire transfers, trading platforms, admin control panels — all protected by phishing-resistant FIDO2. Physical card possession becomes a mandatory factor in every sensitive operation.
Every custom FIDO2 implementation we deliver is built on a consistent technical foundation derived from our production FIDO2 card product. The following specifications apply to standard engagements; we support custom cryptographic profiles and interface configurations for specialized requirements.
| Specification | Detail |
|---|---|
| Standards | FIDO2 WebAuthn Level 2, CTAP 2.1, FIDO U2F |
| Communication | NFC via ISO 14443 Type A |
| Cryptography | ECDSA P-256 for FIDO2 key operations |
| Secure Element | NXP JCOP 4.5 P71, Common Criteria EAL6+ |
| Certification | FIDO Alliance certified |
| NFC Performance | Under 500ms complete authentication round trip |
| Identity Providers | Azure AD, Okta, Duo, Google Workspace, any WebAuthn IdP |
| Developer Resources | Open-source libraries on GitHub, sample integration code |
Headquartered in Geneva, Switzerland — one of the world’s strongest data protection and IP frameworks. Your project is protected by Swiss law from day one.
Years of hands-on development on NXP JCOP and SecureBox tooling — including native-C cryptography that the standard JavaCard environment cannot express.
Every methodology we apply has been validated in real Cryptnox products that ship to thousands of customers worldwide on the JCOP P71 platform.
Cryptnox holds granted and pending patents in the US, Europe, and China — a foundation of original innovation that underpins every engagement. View patent portfolio →
A structured five-phase process ensures your project is delivered securely, on schedule, and with
full IP ownership transferred to you at completion. Hover each phase to expand details.
Requirements Analysis &
Feasibility
We work with your team to capture cryptographic, performance, form-factor, and certification requirements. We assess feasibility on JCOP P71 and identify any constraints before any code is written.
Architecture & Prototype
We select the optimal development layer — JavaCard, SecureBox native C, or a hybrid — and deliver a working prototype with benchmarks for your review and approval.
Security Hardening &
Optimization
Side-channel mitigations, fault injection defenses, constant-time execution, and performance tuning are applied at this phase to meet production security standards.
Integration & Testing
Applet and host-side integration are completed together. We run comprehensive test vectors, interoperability testing, and stress tests before sign-off.
Production Deployment & Support
We support your manufacturing partner during initial card personalization and provide post-launch engineering support under an agreed SLA.
We develop the full range of smart-card applications: standard JavaCard 3.1 applets (PKI, signing, key management, GlobalPlatform secure channels), payment and banking applets, FIDO2/WebAuthn implementations, multi-application identity cards, and advanced NXP SecureBox native C implementations for non-standard cryptography — custom elliptic curves, exotic hash functions, and novel signature schemes such as RedDSA/Pallas, BLS12-381, and Poseidon.
NXP SecureBox is a native C execution environment that runs alongside the JavaCard VM on the JCOP P71. It lets us implement cryptography that JavaCard’s high-level API cannot express — exotic curves, custom hash functions, and signature schemes outside the standard library — while still using the FAME3 cryptographic coprocessor that powers the certified JavaCard primitives. SecureBox is the only path to hardware-rooted signing for blockchain protocols that rely on non-standard cryptography (Zcash Orchard, Ethereum 2.0 BLS, Mina, StarkNet) without sacrificing the secure element’s tamper-resistance.
A full engagement typically runs 6–12 months. Architecture and prototype: 2–3 months. Applet development and on-card integration: 3–6 months. Host-side integration (mobile/desktop SDK, backend) and benchmarking: 1–2 months. Card personalization and production rollout: 1–2 months. If Common Criteria evaluation is required, add 6–12 months for the certification lab on top.
Custom applet code, business logic, and project-specific integrations are owned by the client. Cryptnox retains rights to its pre-existing libraries, SecureBox utilities, and host-side SDKs that are reused across projects. Specific IP terms — including exclusivity, source-code escrow, and rights to derivative works — are negotiated per engagement and captured in the Master Services Agreement.
For the development phase we supply 50–100 prototype cards for engineering and integration testing. For production, MOQs typically start at 1,000–5,000 cards depending on the chip variant and personalization complexity. We can advise on volume pricing once the bill of materials and personalization profile are defined.
Yes. We deliver host-side SDKs for iOS (Core NFC), Android (NFC and USB OTG via the Cryptnox Wallet app), and Windows/macOS/Linux desktop middleware (PC/SC), along with REST and GraphQL backend services. We have shipped integrations against Microsoft Entra ID, Okta, custom KMS/HSM stacks, and bespoke enterprise platforms — integration with your existing IAM is part of the standard engagement scope.
The JCOP 4.5 P71 base platform is Common Criteria EAL6+ certified by NXP. For custom applets we support composite evaluation (typically CC EAL4+ on top of the EAL6+ base) and FIPS 140-3 validation. Cryptnox provides design documentation, security policy, test vectors, and engineering support for the certification lab; the client funds the lab fees.
Yes, in most cases. Our feasibility evaluation process is designed to answer this question definitively before you commit to an engagement. We review the cryptographic specification of your signature scheme, assess whether it can be implemented within the P71’s computational constraints using SecureBox native C, and provide a written feasibility report with performance projections. If your protocol uses a standard elliptic curve — even a less common one — or a hash function that can be described mathematically, we can almost certainly implement it. The main constraint is computational time on the P71’s ARM Cortex-M33: some very expensive pairing operations may not achieve acceptable signing latency. We will tell you this upfront.
Yes. Custom attestation is one of the primary reasons enterprises commission custom FIDO2 development rather than purchasing off-the-shelf keys. During the card manufacturing process, we embed your organization’s attestation certificate — issued from your own PKI or a CA we provision on your behalf — into each card’s secure element. When your cards authenticate to any WebAuthn relying party, the attestation statement carries your certificate, which your access policies can use to enforce “only our organization’s cards can authenticate here.” This is fully compliant with FIDO2 metadata service requirements and works with all major identity providers, including Azure AD, Okta, and Duo.
On iOS 14+, Apple’s Core NFC framework exposes FIDO2 NFC authentication natively through Safari and most WebAuthn-capable apps. The user taps the card to the top of their iPhone when prompted during authentication — the same gesture as Apple Pay. The entire exchange completes in under 500ms. On Android 7+, the experience is similar through the native WebAuthn platform authenticator support in Chrome and other browsers. No companion app is required on either platform for standard FIDO2 authentication. For custom enterprise apps that need deeper integration, we provide iOS and Android SDK wrappers around the core NFC APDU exchange.
White-label crypto wallet cards — our productized custom-development offering.
Granted and pending patents across the US, Europe and China.
Our shipped NFC hardware-wallet card on an EAL6+ secure element.
