Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 25185-1:2024 — Card Security — General Framework and Concepts
Foundational security architecture for identification card systems
ISO/IEC 25185-1:2024 establishes the general framework and foundational concepts for card security within the ISO/IEC identification card ecosystem. Published in its first edition, this standard addresses the growing need for a unified security architecture that spans payment cards, identity cards, access control credentials, and emerging use cases such as digital driver’s licenses and mobile embedded secure elements. For security engineers, the standard provides a threat-model-driven approach to defining security objectives and selecting appropriate cryptographic mechanisms.
ISO/IEC 25185-1 serves as the top-level security framework document for the 24727 series (card-application API) and the 7816 family (physical card characteristics). It is designed to be agnostic to the underlying card technology — contact, contactless, or dual-interface.
1. Threat Model and Security Objectives
The standard defines five threat categories: (T1) physical tampering and side-channel attacks, (T2) logical attacks including malware and protocol manipulation, (T3) cloning and counterfeiting, (T4) privacy compromise through unauthorized data access or tracking, and (T5) denial of service against card infrastructure. For each category, the standard maps mandatory and optional security objectives that a compliant card system must address.
From an engineering perspective, this threat taxonomy is the most valuable contribution of the standard. It forces product architects to systematically consider attack vectors rather than reactively patching vulnerabilities. For example, T4 (privacy) objectives require that card identifiers used in contactless transactions be diversified or session-specific — a design choice that directly influenced EMV contactless specifications and Apple Pay’s device account number scheme.
| Threat Category | Attack Vector | Security Objective | Typical Countermeasure |
|---|---|---|---|
| T1 — Physical | Probing, glitching, side-channel (DPA/SPA) | Tamper resistance, leakage resilience | Secure element with active shield, noise injection |
| T2 — Logical | Protocol downgrade, buffer overflow, relay attack | Secure channel, authenticated encryption | Session key agreement (ECDH), MAC-then-Encrypt |
| T3 — Cloning | Memory readout, key extraction | Uniqueness, hardware-bound key storage | Physically unclonable function (PUF), eFuse |
| T4 — Privacy | Tracking via static ID, data leakage | Data minimization, unlinkability | Pseudonymous identifiers, on-card data filtering |
| T5 — DoS | RF jamming, transaction flooding | Availability, fail-safe modes | Rate limiting, offline fallback with risk parameters |
Cloning (T3) remains the most financially damaging threat in the payment industry. The standard mandates hardware-bound key storage — pure software implementations cannot achieve compliance. Engineers should plan for a dedicated secure element or Trusted Execution Environment (TEE) from the architecture phase.
2. Cryptographic Protocols and Key Management
The framework requires support for mutual authentication between the card and the terminal, using either symmetric (AES-128/256 with CMAC) or asymmetric (ECDSA or RSA-PSS) mechanisms. Session key derivation must use a key agreement protocol that provides perfect forward secrecy (PFS). For privacy-sensitive applications, the card must support ephemeral key generation per transaction.
Key management is addressed at three levels: (L1) personalization key injection at the manufacturing stage, (L2) application-level keys for post-issuance updates, and (L3) session keys for each transaction. The standard mandates that L1 keys never leave the secure element in plaintext — a requirement that has significant implications for the card personalization supply chain.
Implementing PFS via ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) adds only 3–5 ms to a contactless transaction while ensuring that compromise of the card’s long-term key does not retroactively expose past sessions — a critical property for compliance with GDPR and similar data protection regulations.
3. Engineering Design Insights for Compliant Systems
A practical insight from deploying 25185-1-compliant systems: the standard’s layered approach maps naturally to a multi-microcontroller architecture where a dedicated security co-processor handles all cryptographic operations and key storage, while a separate application processor runs the card operating system and file system. This separation enforces the T1 (tamper resistance) objective by reducing the attack surface exposed to logical bugs in the application layer.
For contactless interfaces, the standard recommends limiting the data returned during the anti-collision and selection phases to a minimum — only the application identifier (AID) and an application label. Any additional data should require explicit terminal authentication. This recommendation addresses the privacy concerns raised by early MIFARE implementations that transmitted card metadata in cleartext during the polling phase.
A critical compliance pitfall: session keys derived without incorporating a terminal-generated nonce can be replayed. The standard requires that both card and terminal contribute entropy to the session key derivation. Implementations using only the card’s random number (a mistake found in several pre-certification designs) are non-compliant and vulnerable.
Frequently Asked Questions
Q: How does ISO/IEC 25185-1 relate to EMV specifications?
ISO/IEC 25185-1 provides the overarching security framework, while EMV specifications define application-specific protocols for payment. A card can be EMV-compliant and 25185-1-compliant simultaneously. In practice, EMVCo has aligned its security requirements with the 25185 framework starting from EMV 4.4.
ISO/IEC 25185-1 provides the overarching security framework, while EMV specifications define application-specific protocols for payment. A card can be EMV-compliant and 25185-1-compliant simultaneously. In practice, EMVCo has aligned its security requirements with the 25185 framework starting from EMV 4.4.
Q: Is 25185-1 applicable to mobile wallets (Apple Pay, Google Pay)?
Yes. The framework’s technology-agnostic design covers mobile embedded secure elements (eSE) and host-card emulation (HCE) implementations. For HCE, the standard requires that the cloud-based card profile enforce the same key management and session derivation rules as a physical card.
Yes. The framework’s technology-agnostic design covers mobile embedded secure elements (eSE) and host-card emulation (HCE) implementations. For HCE, the standard requires that the cloud-based card profile enforce the same key management and session derivation rules as a physical card.
Q: What is the minimum key length required for asymmetric cryptography?
The standard requires at least 2048-bit RSA or 256-bit ECC (NIST P-256) for asymmetric operations. For symmetric operations, AES-128 is the minimum, with AES-256 recommended for applications processing data classified above the baseline security level.
The standard requires at least 2048-bit RSA or 256-bit ECC (NIST P-256) for asymmetric operations. For symmetric operations, AES-128 is the minimum, with AES-256 recommended for applications processing data classified above the baseline security level.
Q: Does the standard require physical Common Criteria (ISO/IEC 15408) evaluation?
The standard does not mandate a specific evaluation scheme but strongly recommends that secure elements used in card products undergo evaluation at EAL5+ or higher under ISO/IEC 15408 (Common Criteria). This is particularly important for government identity programs and high-value payment systems.
The standard does not mandate a specific evaluation scheme but strongly recommends that secure elements used in card products undergo evaluation at EAL5+ or higher under ISO/IEC 15408 (Common Criteria). This is particularly important for government identity programs and high-value payment systems.
