ISO/IEC 24727-2:2008
(Main)Identification cards — Integrated circuit card programming interfaces — Part 2: Generic card interface
Identification cards — Integrated circuit card programming interfaces — Part 2: Generic card interface
ISO/IEC 24727-2:2008 defines a generic card interface for integrated circuit cards. This interface is presented as: command-response pairs for interoperability, card and application capability description and determination. ISO/IEC 24727-2:2008 is based on ISO/IEC 7816-4, ISO/IEC 7816-8, ISO/IEC 7816-9, and ISO/IEC 7816-15.
Cartes d'identification — Interfaces programmables de cartes à puce — Partie 2: Interface de carte générique
General Information
- Status
- Published
- Publication Date
- 29-Sep-2008
- Technical Committee
- ISO/IEC JTC 1/SC 17 - Cards and security devices for personal identification
- Current Stage
- 9093 - International Standard confirmed
- Start Date
- 05-May-2021
- Completion Date
- 12-Feb-2026
Relations
- Effective Date
- 09-Feb-2026
- Effective Date
- 09-Feb-2026
- Effective Date
- 04-Dec-2021
Overview
ISO/IEC 24727-2:2008 specifies the Generic Card Interface (GCI) for integrated circuit cards (smart cards). As Part 2 of the ISO/IEC 24727 family, it defines a command-level programming interface presented as command–response pairs and mechanisms for card and application capability description and determination. The standard is a concretization of core APDU and data-object concepts from ISO/IEC 7816‑4, ‑8, ‑9 and ‑15 and is intended to maximize interoperable, independent implementations for contact and contactless cards.
Key Topics and Requirements
- Command–response model (APDU-equivalent): Requests and confirmations at the GCI are logically equivalent to ISO/IEC 7816 APDUs. The document even defines a simple programmatic interface example (ExecuteCommand(sequence-of-bytes command) → sequence-of-bytes response).
- Interoperability organization: A standardized subset of ISO/IEC 7816 commands and data structures is prescribed to ensure portability between implementations while minimizing optional behavior.
- Class and instruction byte rules: CLA usage on the GCI is constrained (e.g., CLA = 'FF' for requests acted on by ISO/IEC 24727‑2 implementations). Command chaining is supported only for data strings too long for a single command, with constant INS, P1 and P2 across the chain.
- Supported command set: Many common ISO/IEC 7816 instructions are handled via the translation script or by the Part 2 implementation (e.g., SELECT, READ BINARY, UPDATE BINARY, GET/PUT DATA, VERIFY, AUTHENTICATE, CRYPTOGRAPHIC OPERATIONS).
- Capability descriptions: Definitions and procedures for Card Capability Description (CCD) and Application Capability Description (ACD), including how procedural elements and determination rules are used to evaluate card/application capabilities.
- Translation code concept: Procedural software (translation code) can map GCI commands to the physical card’s native commands or structures.
- Limitations at GCI: Short file identifiers, logical channels, and record-structured files cannot be exposed via the generic card interface (physical cards may still use them internally).
Applications and Users
ISO/IEC 24727-2 is practical for:
- Smart card middleware developers implementing interoperable card interfaces.
- Card manufacturers and integrators mapping physical card features to a generic API.
- Government eID, payment, and digital-signature systems that require vendor-independent smart card access.
- Application developers and system architects building multi-vendor solutions that rely on standardized APDU-level interactions and capability discovery. Benefits include improved interoperability, predictable command semantics, and a standardized way to describe card and application capabilities (CCD/ACD).
Related Standards
- ISO/IEC 24727‑1 (Architecture), 24727‑3 (Application interface), 24727‑4 (API administration)
- ISO/IEC 7816‑4, 7816‑8, 7816‑9, 7816‑15 (base smart-card command and data object standards)
- ISO/IEC 20060 (Open Terminal Architecture reference)
Get Certified
Connect with accredited certification bodies for this standard

BSI Group
BSI (British Standards Institution) is the business standards company that helps organizations make excellence a habit.

NYCE
Mexican standards and certification body.
Sponsored listings
Frequently Asked Questions
ISO/IEC 24727-2:2008 is a standard published by the International Organization for Standardization (ISO). Its full title is "Identification cards — Integrated circuit card programming interfaces — Part 2: Generic card interface". This standard covers: ISO/IEC 24727-2:2008 defines a generic card interface for integrated circuit cards. This interface is presented as: command-response pairs for interoperability, card and application capability description and determination. ISO/IEC 24727-2:2008 is based on ISO/IEC 7816-4, ISO/IEC 7816-8, ISO/IEC 7816-9, and ISO/IEC 7816-15.
ISO/IEC 24727-2:2008 defines a generic card interface for integrated circuit cards. This interface is presented as: command-response pairs for interoperability, card and application capability description and determination. ISO/IEC 24727-2:2008 is based on ISO/IEC 7816-4, ISO/IEC 7816-8, ISO/IEC 7816-9, and ISO/IEC 7816-15.
ISO/IEC 24727-2:2008 is classified under the following ICS (International Classification for Standards) categories: 35.240.15 - Identification cards. Chip cards. Biometrics. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO/IEC 24727-2:2008 has the following relationships with other standards: It is inter standard links to CEN/TS 15480-3:2010, CEN/TS 15480-3:2014, ISO/IEC 24727-2:2008/Amd 1:2014. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
ISO/IEC 24727-2:2008 is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 24727-2
First edition
2008-10-01
Identification cards — Integrated circuit
card programming interfaces —
Part 2:
Generic card interface
Cartes d'identification — Interfaces programmables de cartes à puce —
Partie 2: Interface de carte générique
Reference number
©
ISO/IEC 2008
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO/IEC 2008
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2008 – All rights reserved
Contents Page
1 Scope . 1
2 Normative references . 1
3 Terms and definitions. 1
4 Abbreviated terms . 2
5 Organization for interoperability. 2
5.1 Command-response pairs for interoperability . 2
5.1.1 Command and response encoding. 2
5.1.2 Class byte . 3
5.1.3 Instruction byte . 3
5.1.4 File descriptor byte. 5
5.2 Card states for interoperability . 6
5.3 Status words for interoperability . 7
5.4 Data structures for interoperability. 8
5.5 Card-applications for interoperability. 9
5.5.1 Alpha card-application . 9
5.5.2 Cryptographic information application . 9
6 Capability descriptions . 10
6.1 Card capability description (CCD) . 10
6.2 Application capability description (ACD). 11
6.3 Procedural elements. 11
6.3.1 Model of computation for procedural elements . 12
6.3.2 Use of procedural elements. 12
6.4 Determining the value of capability descriptions. 13
6.4.1 General principle. 13
6.4.2 Determining the value of the CCD. 13
6.4.3 Determining the value of an ACD. 13
Annex A (informative) Profiles for the cryptographic information application on the generic card
interface . 14
A.1 Profile A . 14
A.1.1 EF.CIAInfo. 14
A.1.2 EF.OD . 14
A.1.3 EF.PrKD . 14
A.1.4 EF.PuKD. 14
A.1.5 EF.SKD. 15
A.1.6 EF.CD . 15
A.1.7 EF.AOD . 15
A.1.8 EF.DCOD. 15
Annex B (informative) Instances of profile A. 16
B.1 eSign K Specification . 16
Annex C (normative) Cryptographic information application for card-application service
description. 23
Annex D (informative) Example of cryptographic information application for card-application
service description . 28
Annex E (informative) DID Discovery . 33
Bibliography . 35
© ISO/IEC 2008 — All rights reserved iii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 24727-2 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 17, Cards and personal identification.
ISO/IEC 24727 consists of the following parts, under the general title Identification cards — Integrated circuit
card programming interfaces:
⎯ Part 1: Architecture
⎯ Part 2: Generic card interface
⎯ Part 3: Application interface
⎯ Part 4: API administration
The following parts are under preparation:
⎯ Part 5: Testing
⎯ Part 6: Registration authority procedures for the authentication protocols for interoperability
iv © ISO/IEC 2008 — All rights reserved
Introduction
ISO/IEC 24727 defines interoperable programming interfaces to integrated circuit cards. Programming
interfaces are defined for all card lifecycle stages and for use with integrated circuit cards.
ISO/IEC 24727 is written with sufficient detail and completeness that independent implementations of each
part are interchangeable and can interoperate with independent implementations of the other parts.
This part of ISO/IEC 24727 specifies a command-level programming interface to contactless integrated circuit
cards and cards with contacts that is a concretization of the concepts, data structures and commands found in
the following documents:
⎯ ISO/IEC 7816-4, Identification cards — Integrated circuit cards — Part 4: Organization, security and
commands for interchange
⎯ ISO/IEC 7816-8, Identification cards — Integrated circuit cards — Part 8: Commands for security
operations
⎯ ISO/IEC 7816-9, Identification cards — Integrated circuit cards — Part 9: Commands for card
management
⎯ ISO/IEC 7816-15, Identification cards — Integrated circuit cards — Part 15: Cryptographic
information application
⎯ ISO/IEC 20060, Information technology — Open Terminal Architecture (OTA) specification — Virtual
machine specification
The commands and data objects described in this part of ISO/IEC 24727 are consistent with the commands
and data objects found in these documents which will be referred to as the base documents.
This part of ISO/IEC 24727 maximizes the fungibility of independent realizations of its prescriptions. This
property of this part of ISO/IEC 24727 is realized by positing a minimally sufficient subset of the base
standards which realizes their core functionality through the minimization of the number of options provided.
© ISO/IEC 2008 — All rights reserved v
INTERNATIONAL STANDARD ISO/IEC 24727-2:2008(E)
Identification cards — Integrated circuit card programming
interfaces —
Part 2:
Generic card interface
1 Scope
This part of ISO/IEC 24727 defines a generic card interface for integrated circuit cards. This interface is
presented as:
— command-response pairs for interoperability,
— card and application capability description and determination.
This part of ISO/IEC 24727 is based on ISO/IEC 7816-4, ISO/IEC 7816-8, ISO/IEC 7816-9, and
ISO/IEC 7816-15.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 24727-1, Identification cards — Integrated circuit card programming interfaces — Part 1: Architecture
ISO/IEC 7816-4, Identification cards — Integrated circuit cards — Part 4: Organization, security and
commands for interchange
ISO/IEC 7816-8, Identification cards — Integrated circuit cards — Part 8: Commands for security operations
ISO/IEC 7816-9, Identification cards — Integrated circuit cards — Part 9: Commands for card management
ISO/IEC 7816-15, Identification cards — Integrated circuit cards — Part 15: Cryptographic information
application
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 24727-1 and the following
apply.
3.1
data object
information seen at the interface consisting of the concatenation of a mandatory ISO/IEC 8825 DER-encoded
tag field, a mandatory ISO/IEC 8825 DER-encoded length field and a conditional value field
© ISO/IEC 2008 — All rights reserved 1
3.2
file
structure for application and/or data in the card, as seen at the generic card interface when processing
commands
3.3
translation code
procedural software that transforms commands on the generic card interface to commands implemented on
an integrated circuit card
4 Abbreviated terms
For the purposes of this document, the abbreviated terms given in ISO/IEC 24727-1 and the following apply.
ATS answer to select, as defined in ISO/IEC 14443-3
DF dedicated file
DO data object
FCP file control parameters
FID file identifier
RFU reserved for further use
5 Organization for interoperability
This clause specifies a subset of the structure, commands and data structure defined in ISO/IEC 7816-4,
ISO/IEC 7816-8 and ISO/IEC 7816-9.
The following can not be specified at the generic card interface:
• short file identifiers;
• logical channels;
• files with record structure.
The physical card mapped to the generic card interface by the translation code may use a short EF identifier,
logical channels, and record structure files.
5.1 Command-response pairs for interoperability
5.1.1 Command and response encoding
Requests at the GCI are logically equivalent to command APDUs as specified in ISO/IEC 7816-4,
ISO/IEC 7816-8 and ISO/IEC 7816-9.
Confirmations at the GCI are logically equivalent to response APDUs as specified in ISO/IEC 7816-4,
ISO/IEC 7816-8 and ISO/IEC 7816-9.
The following interface may be used to send a generic card interface command directly to an implementation
of this part of ISO/IEC 24727:
sequence-of-bytes ExecuteCommand(sequence-of-bytes command)
This interface sends a command to the ISO/IEC 24727-2 implementation and returns as its value the
response of the ISO/IEC 24727-2 implementation.
Further interfaces may be defined in other parts of ISO/IEC 24727.
2 © ISO/IEC 2008 — All rights reserved
5.1.2 Class byte
Table 1 lists the class byte values that shall be used in commands on the generic card interface.
Table 1 – CLA Values on the GCI
b8 b7 b6 b5 b4 b3 b2 b1 Description
0 - - 0 - - - - The command is the last or only command of a chain
0 - - 1 - - - - The command is not the last command of a chain
1 1 1 1 1 1 1 1 The command is for the Part 2 implementation
This part of ISO/IEC 24727 shall support command chaining only for the transmission of data strings too long
for a single command; i.e. constant INS, P1 and P2 across all commands in the chain.
For transmission of requests acted upon by the ISO/IEC 24727-2 implementation, generally without
transmission of APDUs to the card, CLA = 'FF' shall be used.
5.1.3 Instruction byte
Tables 2 and 3 list the instruction byte values that should be used in commands at the GCI as these
commands guarantee the standardized independence of the ISO/IEC 24727-2 and ISO/IEC 24727-3
implementations.
A GCI request with an INS not found in Table 2 shall be sent directly to the card and the card-interface
response shall be returned to the entity having made the GCI request.
Commands with instruction bytes listed in Table 3 shall be acted on by the ISO/IEC 24727-2 implementation
and shall not be provided to the translation script.
Table 2 – Requests on the GCI Handled by the Translation Script
Command Name INS Package Limitations
SELECT by file identifier (P1-P2 = ’00-04’ or ’00-0C’) and
SELECT by DF name (P1-P2 = ’04-04’ or ’04-0C’) with
SELECT ‘A4’ A
return of FCP data object or no data shall be supported.
(See Note)
READ BINARY ‘B0’ A Bit 8 of P1 shall be set to 0.
READ BINARY ‘B1’ A P1 and P2 shall be set to ‘00’.
‘D6’
UPDATE BINARY A Bit 8 of P1 shall be set to 0.
UPDATE BINARY ‘D7’ A P1 and P2 shall be set to ‘00’.
‘CA’
GET DATA A None.
‘CB’
‘DA’
PUT DATA A When PUT DATA references a data object that already
‘DB’
exists it shall be overwritten.
GENERATE
‘46’ Out of scope
ASYMMETRIC KEY B
‘47’
PAIR
‘20’ P2 is not zero.
VERIFY A
P2 is not zero.
VERIFY ‘21’ A
CHANGE None.
‘24’ A
REFERENCE DATA
© ISO/IEC 2008 — All rights reserved 3
None.
GET CHALLENGE ‘84’ A
INTERNAL None.
‘88’ A
AUTHENTICATE
EXTERNAL None.
‘82’ A
AUTHENTICATE
MUTUAL None.
‘82’ A
AUTHENTICATE
GENERAL ’86’
A None.
AUTHENTICATE ‘87’
PERFORM P1=’9E’
SECURITY P2=’9A’
OPERATION: ‘2A’ A Command data field:
COMPUTE DIGITAL - Absent (hash value provided via PERFORM SECURITY
SIGNATURE OPERATION:HASH
PERFORM
P1=’00’
SECURITY
P2=’A8’
OPERATION: ‘2A’ A
Command data field:
VERIFY DIGITAL
- DO ‘9E’
SIGNATURE
P1=’90’
P2=’80’ or ’9A’
PERFORM Command data field:
SECURITY ‘2A’ A 1) - DO ‘90’ (intermediate hash value || amount of bits
OPERATION: HASH already hashed ) || DO ‘80’ (final text block)
or
2)- DO ‘90’ hash value
PERFORM P1-‘00’
SECURITY P2=’AE’ or ‘BE’
‘2A’ A
OPERATION:VERIFY Command data field:
CERTIFICATE - DO ‘7F21’ (card verifiable certificate)
PERFORM
P1=’86’
SECURITY
‘2A’ A P2=’80’
OPERATION:
Command data field: data to be enciphered
ENCIPHER
PERFORM P1=’80’
SECURITY P2=’86’
‘2A’ A
OPERATION: Command data field: data to be deciphered
DECIPHER (Pl || cryptogram)
MANAGE SECURITY SET (P1=’x1’) and RESTORE (P1=’F3’)
‘22’ A
ENVIRONMENT
Only FCP data objects in Table 9 are supported. The
CREATE FILE ‘E0’ B
created file becomes the current file.
Only P1-P2 = ’00-00’ is supported. After deletion of the
file the parent of the deleted file becomes the currently
DELETE FILE ‘E4’ B
selected dedicated file.
Only P1-P2 = ‘00-00’ is supported
ACTIVATE FILE ‘44’ B
DEACTIVATE FILE ‘04’ B Only P1-P2 = ‘00-00’ is supported
RESET RETRY
'2C' A None
COUNTER
Only P1-P2 = '00-00' is supported
GET RESPONSE 'C0' A
The status word 6985 means there are no data to retrieve
Note: In the case of SELECT by DF name with return of the FCP (P1-P2=’04-04’), a returned FCP data object
may contain a data object with tag ‘87’ indicating the elementary file that contains the card-application
capability description.
4 © ISO/IEC 2008 — All rights reserved
Table 3 – INS Values on the GCI Acted on by the ISO/IEC 24727-2 Implementation (CLA=’FF’)
Command Name INS P1 P2 Package Limitations
COLD RESET '00' '0000' A
Lc absent, Le = '00'.
WARM RESET '00' '00FF' A
DEACTIVATE
'00' '0100' A
CONTACTS
Lc and Le absent
DEACTIVATE
CONTACTS '00' '0200' A
AND EJECT
Lc in the range 5.16, Le absent.
SELECT A standard data field shall be an AID containing the OID of an
PROCEDURAL 'A4' '0400' A ISO standard defining the implementation, according to
ELEMENT ISO/IEC 7816-4. A data field proprietary to the implementation
shall start with 'FX' .
GET DATA CA A Unless the DOs to be transmitted have application-class tags
defined in ISO/IEC 7816 or ISO/IEC 24727, the tags shall be
of the context-dependent class.
When PUT DATA references a data object that already exists,
it shall be overwritten. Particular tags in a PUT DATA may
PUT DATA DA A trigger the execution of a procedure by the called element. If
there is more than one parameter to transmit to the
procedure, those parameters shall be transmitted within a
constructed DO. According to clause 5.2, the status code
'0000' indicates proper execution of the procedure.
Lc absent, Le = '00'
Returns the value of DO 7F64.
LIST READERS CA ‘7F64’ A
This value is a concatenation of DOs encapsulating reader
names in UTF8 format.
The physical card mapped to the generic card interface by the translation code may use other ISO/IEC 7816
compliant commands.
Instruction values received at the GCI including those in Table 2 may trigger a procedural element in a
capability description. See 6.3.
Package A shall be required for operational use. Packages A and B shall be required for card management
use.
A successful completion of the RESET command shall reset both the ISO/IEC 24727-2 implementation and
the card. The reset of the ISO/IEC 24727-2 implementation shall include setting the CCD and all the ACDs to
‘undefined’.
The response data in the R-APDU of the RESET C-APDU shall be the historical bytes of the card ATR, ATS
or answer to ATTRIB if they are available. The status words shall be ’0000’ for successful completion and
otherwise ‘0F00’.
5.1.4 File descriptor byte
Table 4 lists the file descriptor byte values that shall be used in the FCP on the GCI. Files seen on the GCI are
not shareable.
Table 4 – File Descriptor Byte Values on the GCI
b8 b7 b6 b5 b4 b3 b2 b1 Description
0 0 1 1 1 0 0 0 Dedicated file
0 0 0 0 0 0 0 1 Working elementary file, transparent structure
0 0 1 1 1 0 0 1 Working elementary file, TLV structure for
BER-TLV data objects
© ISO/IEC 2008 — All rights reserved 5
5.2 Card states for interoperability
Tables 5 and 6 list the states that shall be used in implementations of the generic card interface and describes
the state transition events between these states.
Table 5 – Card and Application States and State Transition Events on the GCI
Always Type of
State Name State Transition Event
Defined State Change
Currently
selected Yes Set SELECT by DF name; e.g., application identifier
application
Set SELECT by file identifier of a dedicated file
Currently
CREATE FILE with the new dedicated file
selected
Yes Set
becoming the currently selected dedicated file
dedicated
file
DELETE FILE of the currently selected
Set dedicated file with the new dedicated file
becoming the parent of the deleted dedicated file
Set SELECT by file identifier of an elementary file
CREATE FILE with the newly created
Set elementary file becoming the currently selected
elementary file
Currently
Unset SELECT by DF name
selected
No
elementary
Unset SELECT by file identifier of a dedicated file
file
DELETE FILE of the currently selected
Unset elementary file or currently selected dedicated
file
Unset CREATE FILE of a dedicated file
Table 6 – Currently selected files after the successful execution of commands on the GCI
COMMAND Current application/DF Current elementary file
Change to the specified
SELECT by DF name Cleared and non existent
application/DF
SELECT DF by file
Change to the specified DF Cleared and non existent
identifier
SELECT EF by file
No change Change to specified EF
identifier
CREATE FILE of DF Change to the specified DF Cleared and non existent
CREATE FILE of EF No change Change to the specified EF
Change to the parent DF in the Cleared and non existent in the case of
DELETE FILE of DF case of deletion of the currently deletion of the DF that have currently
selected DF selected EF
DELETE FILE of EF No change Clear and non existent
Immediately after the RESET command, the currently selected application/DF shall be MF or the default
selected application/DF. The currently selected EF is “cleared and non-existent”.
6 © ISO/IEC 2008 — All rights reserved
5.3 Status words for interoperability
The status words that shall be used on the generic card interface are listed in Table 7.
Table 7 – Status Words for Interoperability
Symbol Value Meaning
OK ‘9000’ Successful completion of command
Normal
Successful completion of command with at least
MORE ‘61xx’
xx bytes of additional response data available
Unexpected end of processing leaving the state
EOP- of non-volatile memory unchanged from its state
‘62xx’
NOCHANGE immediately before the start of the execution of
the command.
EOD ‘6282' End of data reached
Warning
EOP-RC ‘63Cx’ Wrong reference data – x tries left
Unexpected end of processing leaving the state
‘63xx’ other of non-volatile memory changed from its state
EOP-CHANGED
than ‘63Cx’ immediately before the start of the execution of
the command.
End of processing due to error condition leaving
ABORT-NO the state of non-volatile memory unchanged from
‘64xx’
CHANGE its state immediately before the start of the
execution of the command.
End of processing due to error leaving the state
Execution
ABORT- of non-volatile memory changed from its state
Error ‘65xx’
CHANGED immediately before the start of the execution of
the command.
End of processing due to error condition involving
ABORT-
‘66xx’ a security condition leaving the non-volatile
SECURITY
memory in an undefined state.
WRONG
‘6700’ Wrong length
LENGTH
SECURITY
‘6982’ Security condition not satisfied
CONDITION
REFERENCE
'6983' Reference data is blocked
DATA BLOCKED
CONDITION OF
‘6985’ Conditions of use not satisfied
USE
DATA FIELD ‘6A80’ Incorrect parameters in the command data field
Checking
FUNCTION NOT Function not supported; e.g. no additional logical
Error ‘6A81’
SUPPORTED channels available
FILE NOT
‘6A82’ File or application not found
FOUND
P1-P2 ‘6A86’ Incorrect parameters P1-P2
DATA NOT
‘6A88’ Referenced data not found
FOUND
BAD INS ‘6D00’ Instruction is not supported or invalid
BAD CLA ‘6E00’ Class code is not supported
UNDEFINED ‘6F00’ No precise diagnosis
Successful processing by ISO/IEC 24727-2
OK ‘0000’ implementation including CCD and ACD
procedural elements
SIGNATURE
‘02xx’ Signature on translation script not verifiable
INVALID
Response
produced by Response data contain a language-defined
EXCEPTION ‘0080’
Generic Card exception
Access Layer No translation provided by ISO/IEC 24727-2
NOT MAPPED ‘0A81’
procedural element
IFD NOT FOUND ‘0A82’ Interface device not available
CARD MISSING ‘0A88’ Card not found
UNDEFINED ‘0F00’ No precise diagnosis
© ISO/IEC 2008 — All rights reserved 7
All SW1 SW2 values, returned at the generic card interface, with SW1 not equal to '6X' or '9X' do not originate
from a response APDU from the card, but from the ISO/IEC 24727-2 middleware. '0X YZ' has the same
meaning as '6X YZ' issued by a card for X>0. Values defined so far appear in Table 7. More values may be
defined in further parts of this standard. For conformance to this part of the standard, status words from the
card and from procedural elements which are not found in this table shall be mapped to ‘6F00’ and ‘0F00’
respectively.
All SW1s starting with '0', '1', '2', '3', '4', '5', '7', '8', 'A', 'B', 'C', 'D', 'E' are either defined in this standard or RFU
by ISO/IEC JTC1/SC17.
The use of all SW1s starting with ‘F’ is proprietary.
5.4 Data structures for interoperability
Data structures for interoperability shall be implemented as files or BER-TLV data objects. These files and
BER-TLV data objects are defined in ISO/IEC 7816-4.
Data objects may be managed using the GET DATA and PUT DATA commands on the generic card interface.
Data objects may also be contained in and managed by card-applications. The security attributes of the data
objects in an elementary file of TLV structure are contained in the FCP of the elementary file.
Each card-application shall be universally identified by an ISO/IEC 7816-4 application identifier.
Tables 8 through 13 describe the templates and tags that shall be used on the generic card interface.
More templates and data objects may be included in further parts of ISO/IEC 24727.
Table 8 – Interoperability Data Objects for Templates
Symbol Tag Description Tag Class Context
FCP ‘62’ Data file control parameter template Application Global
AT 'A4' Control reference template for authentication Manage
CCT 'B4' Control reference template for cryptographic Security
Environment
checksum
Context- and Perform
DST 'B6' Control reference template for digital
Specific Security
signature
Operation
CT 'B8' Control reference template for confidentiality
commands
HT ‘AA’ Hash template
Table 9 – Interoperability Data Objects in the File Control Parameter Template (FCP)
Symbol Tag Description
SIZE ‘80’ Number of data bytes in the file excluding structural information
ALLOC ‘81’ Number of bytes allocated to the EF or the DF including structural
information
FDB ‘82’ File descriptor byte (1 byte)
FID ‘83’ File identifier
DFNAME '84' Dedicated file name; generally, an application identifier
FID-ACD ‘87’ Identifier of an EF containing an extension of the file control
information
SEC-EXP 'AB' Security attribute template in expanded format
SEC-COM ‘8C’ Security attribute in compact format
SEC-DO ‘A0’ Security attribute template for data objects
8 © ISO/IEC 2008 — All rights reserved
In Table 9, if FID-ACD (tag ‘87’) is present it shall be the file identifier of elementary file containing the
capability description of the card-application
Table 10 – Interoperability Data Objects in the Authentication Control Reference Template (AT)
Symbol Tag Description
CM-REF '80' Cryptographic mechanism reference
SEC- '83' Key reference of a secret key or public key reference
KEY/PuKR
SES- ‘84’ Key reference of a session key or private key reference
KEY/PrKR
Table 11 – Interoperability Data Objects in the Cryptographic Checksum Control Reference Template
(CCT)
Symbol Tag Description
CM-REF '80' Cryptographic mechanism reference
SEC-KEY '83' Key reference of a secret key
SES-KEY '84' Key reference of a session key
Table 12 – Interoperability Data Objects in Digital Signature Control Reference Template (DST)
Symbol Tag Description
CM-REF '80' Cryptographic mechanism reference
PuKR '83' Public key reference
PrKR '84' Private key reference
Table 13 – Interoperability Data Objects in the Confidentiality Control Reference Template (CT)
Symbol Tag Description
CM-REF '80' Cryptographic mechanism reference
SEC- '83' Key reference of a secret key or public key reference
KEY/PuKR
SES- '84' Key reference of a session key or private key reference
KEY/PrKR
Additional data objects, particularly those pertaining to secure messaging, appear in other parts of
ISO/IEC 24727.
5.5 Card-applications for interoperability
5.5.1 Alpha card-application
The card-application with application identifier ‘E8 28 81 C1 17 02’ shall be the alpha card-application. The
alpha card application shall exist and be selectable on the GCI or emulated at the SAL layer.
The alpha card-application shall provide application-independent card information as defined in
ISO/IEC 7816-4 such as card, file, and card-application management information.
5.5.2 Cryptographic information application
The cryptographic information application is defined in ISO/IEC 7816-15. If a cryptographic information
application profile is present as indicated in the CCD (see below), then the cryptographic information
application shall be selectable on the GCI.
© ISO/IEC 2008 — All rights reserved 9
An example of the implementation of the ISO/IEC 7816-15 cryptographic information application is shown in
Annex B.
6 Capability descriptions
There are two types of capability descriptions, the card capability description (CCD) and an application
capability description (ACD) for each card-application. When retrieved from the generic card interface the card
capability description shall be retrieved under tag ‘7F62’ and the application capability description shall be
retrieved under tag ‘7F63’.
6.1 Card capability description (CCD)
The alpha card-application shall support retrieval of CCD data object (tag ‘7F62’).
Table 14 lists the data objects that may be found in the CCD. These data objects shall apply to all
ISO/IEC 24727-compliant applications on the card and may include a list of card-applications available on the
card and procedural code mapping between the card’s native commands and the commands described in
Table 2.
Table 14 –Data Objects in the CCD (‘7F62’)
Symbol Tag Description Mandatory/Value Note
Optional
Profile of ISO/IEC
PRO ‘80’ 24727-2 with which Mandatory ‘00’ Provided by the card
this CCD complies
Sequence of May be constructed by
Concatenation of
application the ISO/IEC 24727-2
SAID ‘A0’ Optional data objects with
identifiers of card- implementation based on
tag ‘4F’
applications information from the card
May be constructed by
Procedural element Data objects as
the ISO/IEC 24727-2
description template defined in Table
LANG ‘A1’ Optional
implementation based on
(See 6.3) 16.
information from the card
URL of the code
LANG-URL ‘5F50’ that performs the Optional
translation
Bit i set to 1 indicates that
CIA profiles present profile i is present. Bit 0
CIA-
‘81’ on the generic card Optional Bit string indicates the presence of
PROFILES
interface the profile in Annex A. All
other bits are RFU.
Bit i set to 1 indicates that
the profile shall be
generated by the ISO/IEC
CIA- CIA profiles present
24727-2 implementation
PROFILES- ‘82’ on the generic card Optional Bit string
Bit 0 indicates the
AUTOMATIC interface
presence of the profile in
Annex A. All other bits
are RFU.
DIGITAL- Digital signature Data object of Key infrastructure for
SIGNATURE- ‘5F3D’ information for Optional digital signature digital signature is out of
ON-CODE procedural element block scope
Provided by the card.
If exists, the card
Profile of ISO/IEC
IF-PROFILE '83' Optional '00' supports
24727-3 interface
ISO/IEC 24727-3
interface.
10 © ISO/IEC 2008 — All rights reserved
This part of ISO/IEC 24727 defines profiles of the cryptographic information application, ISO/IEC 7816-15.
The cryptographic information application data in these profiles shall be found either in the alpha
card-application or in the cryptographic information application. See Annex A for a profile definition.
6.2 Application capability description (ACD)
Each card-application including the alpha card-application may be described by an ACD data object (‘7F63’).
Table 15 lists the data objects that may be found in an ACD. These data objects contain information about
the card-application with which it is associated.
Table 15 –Data Objects in Application Capability Description (‘7F63’)
Mandatory/
Symbol Tag Description Value Note
Optional
Procedural Provided by the
element card-application
Data objects as
LANG ‘A1’ description Optional or the
defined in Table 16
template ISO/IEC 24727-2
(See 6.3) implementation
URL of the code
LANG-URL
‘5F50’ that performs the Optional
translation
Value field of data
object is the
concatenation of a
Description of the DER-encoded
SERVICE- services CIAInfo value
‘7F66’ Optional
DESCRIPTION supported by the followed by DER-
card-application encoded ISO/IEC
7816-15 CIOChoice
values as described
in Annex C
Value of URL is the
location of the
URL of a resource containing
SERVICE- description of the the concatenation of
DESCIPTION- ‘7F67’ services Optional DER-encoded
LOCATION supported by the ISO/IEC 7816-15
card-application CIOChoice values
as described in
Annex C
Key
Digital signature
DIGITAL- infrastructure
information for Data object of digital
SIGNATURE- ‘5F3D’ Optional for digital
procedural signature block
ON-CODE signature is out
element
of scope
6.3 Procedural elements
A procedural element in a capability description shall be a translation code to process any GCI request
belonging to Table 2 and every relevant card-application confirmation according to the TranslationCode
function described below. Procedural elements in the CCD or an ACD are resident on the card itself or are
referenced using a URL.
The procedural element description template given in Table 16 describes the procedural description
technology used in the CCD or an ACD and contains and/or points to executable code in this procedural
© ISO/IEC 2008 — All rights reserved 11
description technology to perform the translations between GCI requests/confirmations and card interface
commands/responses APDU.
Table 16 – Data Objects in the Procedural Element Description Template (‘A1’)
Symbol Tag Description Mandatory/ Value
Optional
LANG-OID ‘06’ Object identifier of the Optional {iso(1) standard(0)
standard or specification iso20060(20060)}
describing the procedural
language.
LANG-CODE ‘81’ Translation code Optional LANG-OID specific
Tokens
When the procedural element (tag ‘A1’) in a capability description contains a data object for a URL (tag ‘5F50’)
and the URL refers to a document properly formatted as a capability description (see Tables 14 and 15), then
the procedural element in the capability description shall be augmented with the procedural element retrieved
from the referred document.
6.3.1 Model of computation for procedural elements
A procedural element in a capability description shall be a translation code intended to process the arguments
conveyed by the TranslationCode function. Procedural elements can be explicitly selected by a SELECT
command (see Table 3), especially if they do not mandate transmission of APDUs to the card. It is not
precluded that interactions with the card occur.
The other features of this model apply to scripts recovered from the card. They do not apply to code
downloaded from the outside world.
A procedural element in a capability description shall be a function with one Boolean argument and one byte
array argument.
When the procedural element is placed in execution to transform a GCI command APDU to one or more card
interface command APDUs, the Boolean argument shall be set to TRUE.
When the procedural element is placed in execution to transform a card response APDU to a GCI
confirmation, the Boolean argument shall be set to FALSE.
Upon entry, if the Boolean argument to the procedural element is TRUE, the other argument, the octet array,
shall contain the octets comprising the GCI command APDU.
Upon entry, if the Boolean argument to the procedural element is FALSE, the argument array shall contain the
octets comprising the confirmation.
Upon exit, the procedural element shall set the Boolean argument to TRUE to return the transformed byte
array argument to the Part 3 implementation. The procedural element shall set the Boolean argument to
FALSE to send the transformed byte array to the card.
The signature of the entry point to the translation code shall be
TranslationCode(Boolean b IN/OUT, Array c IN/OUT)
6.3.2 Use of procedural elements
The ACD of the currently selected card-application and the CCD shall be tried in this order to find the
procedural element in its ACD for handling a GCI request or card-interface response APDU.
12 © ISO/IEC 2008 — All rights reserved
If the currently selected application has provided a procedural element then each GCI request or card-
interface response APDU shall be given to this procedural element.
If the currently selected application has not provided a procedural element and the CCD has provided a
procedural element then each GCI request or card-interface response APDU shall be given to this procedural
element.
If a GCI request is received on the GCI for which there is no procedural element in either the CCD or ACD of
the currently selected application, then the request shall be sent to the card and the card-interface response
shall be returned to the entity having made the GCI request.
6.4 Determining the value of capability descriptions
6.4.1 General principle
If the value of the capability description is not already present in the ISO/IEC 24727-2 middleware then this
value shall be determined by retrieval of data objects according to the procedure described below.
6.4.2 Determining the value of the CCD
Determining the value of the CCD shall use application-independent card services defined by ISO/IEC 7816-4.
The value of the CCD may be determined immediately after card reset as follows. If the interindustry data
element 'initial access data' is present in the historical bytes of the ATR, ATS or answer to ATTRIB, the data
object '7F62' may be determined using the initial data string.
If not, the CCD shall be determined using one of the procedures below. The order in which the procedures
defined below shall be tried is not defined. If all these procedures fail to determine a CCD the card does not
comply with this standard.
• reading the EF.ATR, where data object ‘7F62’ may be present;
• a GET DATA command with either
o INS='CA'; P1-P2=’7F62’ and Le=’00’ or
o INS='CB'; P1-P2=’3FFF’ and command data field containing ‘5C027F62’
which may return the CCD in the response data field;
• by selection of the alpha card-application using the AID ‘E8 28 81 C1 17 02’ followed by a GET DATA
command as described above.
If the list of applications has not been determined using the above procedures, then EF.DIR shall be read to
determine the list of card-applications.
6.4.3 Determining the value of an ACD
Determining the value of an ACD may be performed immediately after the card-application has been selected
using one of the following procedures:
• reading a file referenced in the response to the SELECT command under tag '87';
• a GET DATA command with either
o P1-P2=’7F63’ and Le=’00’ or
o P1-P2=’3FFF’ and command data field containing ‘5C027F63’
which may return the ACD in the response data field.
© ISO/IEC 2008 — All rights reserved 13
Annex A
(informative)
Profiles for the cryptographic information application
on the generic card interface
A.1 Profile A
The presence of an ISO/IEC 7816-15 cryptographic information application conformant with this profile is
indicated by setting bit 1 of the first byte in the value field of the CIA-PROFILES data object in Table 14 to 1.
A.1.1 EF.CIAInfo
EF.CIAInfo is m
...




Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...