Match-on-Card Technology
How match-on-card biometric verification works: template storage, matching algorithms, FAR/FRR performance, and privacy benefits.
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)
- Feature extraction: Convert the live sensor image to a minutiae set.
- Local structure generation: For each minutia, encode the spatial relationship to its K nearest neighbours as a rotation-invariant descriptor.
- Matching: Align probe and gallery (enrolled) minutiae sets using a combination of geometric hashing and score accumulation.
- 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:
- At enrolment: encode a random ECCECCCryptographyEfficient public-key cryptography using elliptic curves.Click to view → private key
kwith the template using an error- correcting code tolerant of typical biometric variation. - At match time: the live scan corrects the codeword and recovers
kif and only if the match succeeds. ksigns the transaction challenge — if the biometric match fails,kis 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.