Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
BS ISO IEC 24727 โ Identification Cards โ Integrated Circuit Card Programming Interfaces Series
Identification Cards โ Integrated Circuit Card Programming Interfaces (2008โ2014 edition family)
๐ณ BS ISO/IEC 24727 is the British Standard family published by BSI adopting the ISO/IEC 24727 series on identification cards โ integrated circuit card (ICC) programming interfaces. The series comprises six documents and was developed with participation from BSI Technical Committee IST/17 (Cards and personal identification). It provides a technology-independent, unified programming-interface model for smart-card applications: through a layered architecture (card interface, application interface, application programming interface API), upper-layer applications can access different card types (contact, contactless, with or without cryptographic coprocessor) in a consistent way to perform identity authentication, digital signing, key management and data storage. The series is the foundational standard family for interoperability of electronic ID cards, e-passports, PKI smart cards, and banking and telecom card applications.
๐ก Some parts of this series are archived as scanned images; the related technical content in this article is compiled from public-domain knowledge. Always verify against the current BSI edition before citing.
1. Series Overview and Positioning ๐
Smart cards (CPU cards, cryptographic cards, Java Card, etc.) are widely used for identity authentication and secure storage, but differences among card chips, card operating systems (COS) and reader protocols (such as ISO 7816 and ISO 14443) make it hard to port upper-layer applications. The core idea of the ISO/IEC 24727 series is “layered abstraction”: decouple the application from card details and provide a standardized data-object model, service access points and security-mechanism description. In this way, the same application can run on contact, contactless or dual-interface cards without modifying business logic. BS ISO/IEC 24727 is the UK implementation of the series, underpinning eID, electronic signatures and smart-card interoperability.
โ ๏ธ This series provides “programming interfaces” and an abstract model; it does not define the physical interface of the card or specific cryptographic algorithms. Actual security strength still depends on the specific card COS implementation, key management and algorithm parameters. Card security evaluation (such as Common Criteria EAL) should also be checked during selection.
2. Series Structure and Technical Content ๐
The six documents of the BS ISO/IEC 24727 series (of varying edition years) form a complete card programming-interface system:
| Part | Subject | Main Content | Year |
|---|---|---|---|
| BS ISO IEC 24727-1 | Architecture | Overall architecture, layered model, data objects and service access points | 2014 |
| BS ISO IEC 24727-2 | Generic card interface | Card-technology-independent card interface services and data model | 2008 |
| BS ISO IEC 24727-3 | Application interface | Application-layer service interfaces, authentication and key management | 2008 |
| BS ISO IEC 24727-4 | Application Programming Interface (API) | Application-oriented API bindings and functionality | 2008 |
| BS ISO IEC 24727-5 | Interoperability testing (scanned) | Interoperability test specification for cards and applications (from public-domain knowledge) | 2011 |
| BS ISO IEC 24727-6 | Authentication and registration services (scanned) | Authentication/registration and certificate services (from public-domain knowledge) | 2010 |
The internal logic of the series: Part 1 defines the overall architecture and layering; Part 2 provides the card-technology-independent card interface (data objects, access control, command semantics); Part 3 provides application-layer services (authentication, signing, encryption, key management); Part 4 provides API bindings; Parts 5 and 6 handle interoperability testing and certificate services. In engineering, implementation proceeds layer by layer from card interface to application interface to API.
โ
Parts 1 to 4 of the series are available as full readable text; Parts 5 and 6 are scanned versions and are summarized here on the basis of general knowledge in the field.
3. Key Technical Requirements ๐ฌ
3.1 Architecture (Part 1)
Part 1 defines the overall architecture of the ICC programming interface: it establishes a layered model (card interface, application interface, application programming interface), and defines data objects (data structures in the card), service access points (communication endpoints between the application and the card) and operation semantics. The architecture stresses the decoupling of applications from card technology, so that the same business logic can adapt to different card types through different card interfaces.
3.2 Generic card interface (Part 2)
Part 2 specifies the Generic Card Interface: it defines services and data objects independent of specific card technology, providing abstractions for card open/close, command transport, data reading and writing, plus access control and security mechanisms. The interface shields the differences of underlying protocols such as ISO 7816 (contact) and ISO 14443 (contactless), so that upper-layer interfaces do not need to be aware of the specific card implementation.
3.3 Application interface and API (Parts 3 and 4)
Part 3 specifies application-layer services: identity authentication (external authentication, card authentication, mutual authentication), digital signing and verification, data encryption/decryption, key establishment and certificate management. Part 4 maps the application interface to concrete application-oriented API bindings (e.g., interfaces for a specific language/environment), providing a unified entry point for applications. Together they enable applications to safely perform card-based cryptographic operations.
โ ๏ธ Interoperability is a key concern of this series: the same card should be accessible by middleware from different vendors, and the same application should run on different cards. Implementations should follow the interoperability tests of Part 5 to verify the consistency of the data-object model and service semantics.
4. Engineering Practice ๐ ๏ธ
- ๐ eID and electronic ID cards: build identity-authentication and electronic-signature applications on this series for cross-system interoperability.
- ๐ง PKI smart cards: use Parts 3/4 to encapsulate certificates, private-key signing and encryption for enterprise-CA and identity-authentication use.
- ๐ Multi-card-type adaptation: use the generic card interface to uniformly support contact, contactless and dual-interface cards, reducing the integration cost of mixed card estates.
- ๐ Interoperability and compliance: run interoperability tests per Part 5 to ensure the collaboration and security of cards, middleware and applications.
5. Frequently Asked Questions โ
โ Q: How does this series relate to ISO 7816?
A: ISO 7816 defines the physical, electrical and command protocols of contact smart cards (the lower layers); ISO/IEC 24727 provides a technology-independent high-level programming interface and data model on top โ the two are complementary layers.
A: ISO 7816 defines the physical, electrical and command protocols of contact smart cards (the lower layers); ISO/IEC 24727 provides a technology-independent high-level programming interface and data model on top โ the two are complementary layers.
โ Q: Why is a “card-technology-independent” interface needed?
A: Card chips, COS and reader protocols differ greatly; without abstraction, the upper-layer application must be developed for each card separately. A unified interface lets an application be written once and adapt to many card types, significantly reducing integration and maintenance costs.
A: Card chips, COS and reader protocols differ greatly; without abstraction, the upper-layer application must be developed for each card separately. A unified interface lets an application be written once and adapt to many card types, significantly reducing integration and maintenance costs.
๐ Q: Why are Parts 5/6 marked as “scanned”?
A: In this batch of archive material, those parts exist as scanned images; the technical content is summarized from public-domain knowledge. Verify against the current BSI edition before formal citation.
A: In this batch of archive material, those parts exist as scanned images; the technical content is summarized from public-domain knowledge. Verify against the current BSI edition before formal citation.
โ Q: Does this series guarantee the security of the card itself?
A: No. The series defines programming interfaces and the data model; the physical and logical security of the card itself must be ensured by the card security evaluation (e.g., Common Criteria certification), COS implementation and key management.
A: No. The series defines programming interfaces and the data model; the physical and logical security of the card itself must be ensured by the card security evaluation (e.g., Common Criteria certification), COS implementation and key management.