Custom Smart Card Development

Smart Card Development Case Studies

Real-world NXP SecureBox and JavaCard implementations on JCOP P71 — exoticcryptography, blockchain protocol integration, and custom algorithm implementationsverified on production hardware.

Case Study 01

HashLibSB: Exotic Hash Functions on Secure Elements

The Challenge

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.

The Solution

We implemented HashLibSB as a native C library 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.

Verified Results

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

What This Project Demonstrates

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. The HashLibSB library is now available as a foundation for any project requiring non-standard hash operations on JCOP P71 hardware.

Case Study 02

RedDSA/Pallas: Zcash Orchard Shielded Transaction Signing

The Challenge

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 JavaCardAPI 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.

The Solution

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:

Host

arrow-down

Secure Element

Verified Results

Signing performance was measured over 100 consecutive signatures on production hardware. All signatures were validated by Zcash consensus
verification routines.

256ms

Median signing time

3.8 sig/s

Throughput

100

Signatures — stress test completed

What This Project Demonstrates

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.

Case Study 03

BLS12-381: Ethereum 2.0 and Multi-Chain BLS Signatures

The Challenge

BLS12-381 is the most widely deployed pairing-friendly elliptic curve, used for validator key signing in Ethereum 2.0, Filecoin storage proofs, andChia 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.

The Solution

We implemented BLS12-381 G1 arithmetic entirely in NXP SecureBox native C, with iterative performance optimization over five development versions. Key techniques included transitioning from projective to affine coordinate representation, implementing windowed exponentiation for modular inversion, deploying binary GCD for variable-time inversion in non-secret code paths, leveraging the phClRsa hardware accelerator ROM for modular arithmetic (a 14x speedup for field inversions), and applying the GLV (Gallant-Lambert-Vanstone) endomorphism to reduce scalarmultiplication to 128 doublings.

Multi-Protocol Support

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:

Performance & Optimization Journey

num-v1

Baseline

3,285ms signing 16s hash-to-curve First working build

num-v2

Affine Coordinates

Switched from projective. windowed fp_pow optimization for inversion

num-v3

Binary GCD

Variable-time inversion for public Z coordinate; further reduction

num-v4

phClRsa ROM

14× speed improvement for field inversions via hardware accelerator

num-v5

Current

1,800ms signing 4.1s hash-to-curve 45% total improvement

1,800ms

Fastest path signing time

45%

Improvement from baseline

128

Doublings via GLV endomorphism

What This Project Demonstrates

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 45% reduction 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.

What These Projects Demonstrate About SecureBox Capabilities

These three case studies span the full spectrum of cryptographic primitive implementation on JCOPP71 — 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:

Breadth

Hash functions, signature schemes, and field arithmetic across the full spectrum of modern cryptographic primitives. From Keccak and Poseidon sponge constructions to Pallas andBLS12-381 curve arithmetic — all on a single hardware platform.

Depth

Constant-time execution, hardware coprocessor integration (FAME3, phClRsa), GLV endomorphism optimization, windowed scalar multiplication, and security-labeled APIs— production-grade engineering throughout the stack.

Verification

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.

Have a Cryptographic Challenge That Needs Secure Element Hardware?

Let’s discuss your project — we deliver verified results on production hardware.

Gradient Line

Continue Exploring Our Smart Card Development Services

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 →

JavaCard 3.1 applet development, JCOP 4.5 extensions, GlobalPlatform integration. 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 →