Match-on-Card Technology

How match-on-card biometric verification works: template storage, matching algorithms, FAR/FRR performance, and privacy benefits.

| 4 min read

Match-on-Card Technology

Match-on-CardMatch-on-CardBiometricBiometric matching performed inside the smart card chip.Click to view → (MoC) is the architectural principle that both the biometric templatebiometric templateBiometricMathematical representation of biometric data stored on card.Click to view → storage and the comparison algorithm reside inside the card's secure element. A live fingerprint image is captured by the sensor, processed on the card, and the card returns only a Boolean match result. The raw biometric data — both the enrolled template and the live scan — never crosses the card boundary in plaintext.

This contrasts with Match-on-Host (where the card transmits a template to the terminal for comparison) and Match-on-Server (centralised biometric database) architectures.

Template Storage

Fingerprint templates in MoC implementations typically use one of two formats:

Format Standard Description
Minutiae template ISO/IEC 19794-2 Encoded ridge endings and bifurcations (type, x, y, θ)
Finger image ISO/IEC 19794-4 Compressed grayscale image (JPEG2000 / WSQ)
Proprietary compact Vendor-specific Optimised for on-card storage and comparison

A minutiae template for one finger typically occupies 500–2,000 bytes in ISO 19794-2 format. Cards store 1–2 fingers (some store up to 4) in EEPROM or Flash memory protected by the secure element access control.

ISO/IEC 19794-2 Minutiae Record (simplified):
┌──────────────────────────────────────────────────────┐
│ Format ID (4B) │ Version (4B) │ Total Length (4B)    │
│ Width (2B) │ Height (2B) │ Resolution X/Y (2B each) │
│ Finger count (1B) │ [Finger View records...]         │
│   Finger position │ View count │ Quality              │
│   Minutia count (1B)                                 │
│   [Minutia: type(2b) | X(14b) | Y(14b) | θ(8b)](×N) │
└──────────────────────────────────────────────────────┘

On-Card Comparison Algorithm

The matching algorithm must run within severe constraints: < 3 mW power budget, < 100 KB RAM, and produce a result within 300–500 ms to remain inside the ISO 14443ISO 14443StandardStandard for contactless smart cards.Click to view → activation window for contactless use.

Minutiae-Based Matching (Most Common)

  1. Feature extraction: Convert the live sensor image to a minutiae set.
  2. Local structure generation: For each minutia, encode the spatial relationship to its K nearest neighbours as a rotation-invariant descriptor.
  3. Matching: Align probe and gallery (enrolled) minutiae sets using a combination of geometric hashing and score accumulation.
  4. Threshold comparison: If the alignment score exceeds the configured threshold τ, return match; otherwise return fail.

The threshold τ controls the FAR/FRRFAR/FRRBiometricError rate metrics for biometric authentication accuracy.Click to view → trade-off:

τ (lower = stricter) FAR FRR Use Case
High threshold < 0.0001% ~3–5% Government ID, high security
Medium threshold < 0.001% ~1–2% EMVEMVApplicationGlobal chip payment card standard.Click to view → payment (typical)
Low threshold < 0.01% ~0.5% Convenience-focused

ECC-Enhanced Templates (Privacy-Preserving)

Advanced MoC implementations combine biometric matching with ECC key binding using fuzzy commitment schemes:

  1. At enrolment: encode a random ECCECCCryptographyEfficient public-key cryptography using elliptic curves.Click to view → private key k with the template using an error- correcting code tolerant of typical biometric variation.
  2. At match time: the live scan corrects the codeword and recovers k if and only if the match succeeds.
  3. k signs the transaction challenge — if the biometric match fails, k is not recoverable and no signature is produced.

This approach provides cryptographic proof of biometric match without storing the template in recoverable form.

Security Properties

Property MoC Match-on-Host Match-on-Server
Template at rest In secure element On card, read by host In database
Template in transit Never extracted Transmitted to host Transmitted to server
Revocability Card destruction or re-enrolment Card-level Database update
Privacy risk on compromise Card only Card + host RAM All enrolled users
Common CriteriaCommon CriteriaSecurityInternational IT security evaluation standard.Click to view → evaluation EAL 4+/5+ Lower N/A

FAR and FRR in Practice

FAR (False Accept Rate) and FRR (False Reject Rate) are measured per ISO/IEC 19795-1 using large multivendor datasets. For EMV biometric certification, Mastercard and Visa require:

  • FAR ≤ 0.001% (false accept no more than 1 in 100,000 impostors)
  • FRR ≤ 3% (true user rejected no more than 3 times in 100)

Independent evaluation is performed by accredited biometric test laboratories using Test Method ISO/IEC 19795-2 (scenario evaluation) with a population ≥ 500 subjects.

For the payment integration context, see Biometric Payment Cards. For the broader card market, see Biometric Smart Cards Overview.

よくある質問

Our guides cover a range of experience levels. Getting Started guides introduce smart card fundamentals. Security guides address Common Criteria certification and key management. Programming guides target developers working with APDU commands, JavaCard applets, and GlobalPlatform card management.