ISO7816-4 section 9 - Application-independent Card Services
9.1 Definitions and scope
This clause describes the application-independent card services, referred to as “card services” in the following text. Their purpose is to provide interchange mechanisms between a card and an interface device knowing nothing about each other except that both comply with this part of ISO/IEC 7816.
Card services are supported by any combination of
- historical bytes
- contents of one or more reserved EFs
- sequences of interindustry commands
The commands use CLS=’00’ (see 5.4.1), i.e. no secure messaging and the basic logical channel.
There is no need for an application to comply with this clause once it has been identified and selected in the card. It is possible for an application to use other mechanisms compatible with this part of ISO/IEC 7816 for achieving similar functions. Therefore such solutions may not guarantee interchange.
The following card services are defined
- Card identification service – This service allows the interface device to identify the card as well as how to deal with it.
- Application selection service – This service allows the interface device to know what application is active in the card (if any) as well as how to select and start an application in the card.
- Data object retrieval service – This service allows to retrieve data objects defined either in this part or in other parts of ISO/IEC 7816. This clause describes standard mechanisms only for interindustry data objects.
- File selection service – This service allows selection of un-named DFs and EFs.
- File I/0 service – This service allows access to data stored in EFs.
9.2 Card identification service
This function consists of the card providing information to the outside world on its logical content as well as some general data objects all applications might be interested in (e.g. interindustry data objects). The information, called “card identification data”, is given by the card in the historical bytes and possibly in a file implicitly selected immediately after the answer to reset.
Access to this file is indicated in the initial access data information (see 8.3.3).
If the initial access data of the historical bytes does not denote a READ command, then the response to the command to perform contains card identification data.
9.3 Application selection service
9.3.1 Implicit application selection
When an application is implicitly selected in a card, the application identifier as defined in part 5 of ISO/IEC 7816 should be indicated in the card identification data. If not present in the card identification data, then it shall be present in the ATR file.
9.3.2 Direct application selection
A card in a multi-application environment shall be able to respond positively to a direct application selection performed by a SELECT FILE command specifying the application identifier as DF name.
The application identifier should be provided completely in the command APDU. In case of an application selection by partial DF name, the next application matching with the name proposed may be selected and the full DF name will be made available in the response message of the SELECT FILE command as the file control parameter with tag ’84’ (see table 2 ).
The APDU of the command to perform is the following.
|CLA||’00’ (see 5.4.1)|
|Lc field||Length in bytes of the data field|
|Data field||Full or partial DF name|
|Le field||Present, contains only zeroes|
9.4 Data object retrieval service
Data objects used for application-independent international interchange are defined in this part and other parts of ISO/IEC 7816.
The retrieval of those data objects relies on one or both of the following menthods :
- presence of a data object in the card identification data (see 9.2),
- presence of a data object in the DIR file (path=’3F002F00′) or in the ATR file (path=’3F002F01′).
The information necessary to retrieve data objects by an indirect method is defined in part 6 of ISO/IEC 7816.
9.5 File selection service
When the path to an EF is known, the number of SELECT FILE commands to be issued equals the length of the path divided by two, minus one (the path always starts with the current DF).
If the path length is more than four bytes, then until all available DF identifiers of the path have been used, one or more SELECT FILE commands shall be performed with the following command APDU.
|CLA||’00’ (see 5.4.1)|
|Data field||DF identifier (from bytes 3 and 4 of the path)|
The last and possibly only selection is an EF selection with the following command APDU.
|CLA||’00’ (see 5.4.1)|
|Data field||DF identifier (last two bytes of the path)|
9.6 File I/O service
Once a file used for interindustry interchange has been selected, the contents relevant to interchange shall be returned by one of the following command APDUs.
- If the first software function table is absent, or does not denote the support of record-oriented commands, then the following command shall be performed.
CLA ’00’ (see 5.4.1) INS ‘B0’ P1-P2 ‘0000’ Lc field Empty Data field Empty Le field Present, contains only zeroes
- If the first software function table denotes the support of record-oriented commands, then the following commands shall be performed.
CLA ’00’ (see 5.4.1) INS ‘B2’ P1-P2 ‘0005’ Lc field Empty Data field Empty Le field
Present, contains only zeroes
- Easy-to-use chip card integration with .NET library
with C# and VB.NET sample code for Mifare, DESFire EV1, JavaCard, KVK, eGK, SIM, PIV, CAC, HID Prox, iCLASS, SEOS and many more