ISO IEC 7816-9:2017 download free.Identification cards – Integrated circuit cards Part 9 : Commands for card management.
lSO/IEC 7816 Is a series of International Standards specifying Integrated circuit cards and the use of such cards for interchange. These cards are identification cards intended for information exchange negotiated between the outside world and the integrated circuit In the card. As a result of an information exchange, the card delivers information (computation result, stored data) and/or modifies its content (data storage, event memorization),
— Five parts in the series are specific to cards with galvanic contacts and three of them specify electrical interfaces.
— ISO/IEC 7816-1 specifies physical characteristics for cards with contacts.
— ISO/IEC 7816.2 specIfies dimensions and location of the contacts,
— ISO/IEC 7816-3 specifIes electrical interface and transmission protocols Iorasynchronous cards.
— lSO/IEC 7816-10 specifies electrical interface and answer to reset for synchronous cards.
— lSO/IEC 7816-12 specIfies electrical interlace and operating procedures for USB cards.
— All the other parts In the series are Independent from the physical Interface technology. They apply to cards accessed by contacts and/or by radio frequency.
— ISO/IEC 78 16-4 specifies organization, security and commands for interchange.
— ISO/IEC 7816-5 specifies registration of application providers.
— ISO/IEC 7816.6 specIfies interindustry data elements for Interchange.
— ISO/IEC 7816-7 specifies commands for structured card query language.
— lSO/W.C 7816-8 specifies commands for security operations.
— ISO/JEC 7816-9 specifies commands for card management.
— ISO/IEC 7816.11 specIfies personal verification through biometric methods.
— ISO/1EC 7816-13 specifies commands for application management in a multi-application environment.
— lSO/IEC 7816-15 specifies cryptographic information application.
ISO/IEC 10536 (all parts) specifies access by close coupling. ISO/IEC 14443 (all parts) and ISO/IEC 15693 (all parts) specify access by radio frequency. Such cards are also known as contactless cards.
SCB security condition byte
SM secure messaging
SPT security parameter template (using DO’AD’ under DO’62’)
SWI-SWZ status bytes
tag, length, value
validity area
S Life cycle
5.1 General properties
A tile cycle status (see coding in ISO/IEC 7816’4:2013, 7.4.10) may he associated with any object in the card and with the card itself. The card shall use the life cycle status in combination with additional security attributes when present and applicable, unless defined otherwise by the application, to determine whether an operation on an object is in accordance with a security policy. The life cycle status determines the use of objects when the card supports Life cycle status dependent security attributes according to the following rules.
— If an object Is in creation state, then no security attribute shall apply unless otherwise specified.
— LI an object is in initialization state, then any security attribute specific to this state may apply.
— II an object is in operational state, then any associated security attribute specific to this state shall apply.
— han object is in termination state, then thevalue oftheobject shall notbeaccessed unlessdetermlned otherwise by its associated security attributes, e.g. it can be deleted.
In addition to the behaviour described above, distinguishing characteristics for primary states of life cycle are defined as follows.
— Creation state — an object is newly created (e.g. by CREATE OF CREATE FILE command) or appended (e.g. UPDATE DATA, PUT DATA commands) to an existing object. These operations may fit the created item with its control parameters and may provision it with data elements.
— Initialization state — a newly created objector an existing object In creation state may be Initialized. The object is not active but selectable and may be provisioned with data.
Operationatstate comprlsestwo secondarystates: operational activated and operational deactivated. When activated, the object and its contents may be accessed according to Its security attributes. When deactivated, the object is logically reduced with restricted capabilities or functionality but selectable and the access to its content depends on the application. From these states, the object can be terminated.
— Termination state — the object is logically reduced with restricted capabilities or lunetlonallty but selectable. The only applicable command is for object deletion unless determined otherwise by the application. Upon selection of a selectable terminated object, the warning status SW1-5W2 = ‘6285’ shall be returned; otherwise, i.e. not selectable object, an error code shall be returned. Further possible actions are not defined in ISO/IEC 7816 (all parts).
— Card Termination state — after a successful completion of the TERMINATE CARD USAGE command. the card shall reject the SELECT command.
After creation, the object Is either in creation state or In initialization state or operational (activated or deactivated) state. Tk’ansitions between primary life cycle statuses are irreversible and occur only
5,3 Command-dependent life cycle status transitIon
A command-dependent LCS transition (or an object is an LCS transition triggered by a command according to the execution rules applicable for the object.
The security handling or operation commands GENERAL AUThENTICATE, GENERATE ASYMMETRIC KEY PAIR, RESET RETRY COUNTER and CHANGE REFERENCE DATA, and commands Initiating the modification of the current template contents as PUT/PUT NEXT/UPDATE DATA may have a command-dependent LCS transition effect of InitiatIng an LCS transition. Unlike the rest of the transitions Initiated by other commands and that are said explicit (see Table 1). these transitions are provided as optional functionality.
In the last step of command processing onto an object featuring CP. the assigned CP shall be evaluated to check for the requirement to perform a command-dependent I.CS transition.
To be applicable, command-dependent L.CS transition functionality shall conform to the following rules:
— for an existing object, all transitions from Figure 1 could be triggered by a command-dependent LCS transition;
— the command-dependent LCS transition applicable for the object shall be executed after successful execution ofthe command. i.e. the response trailer indicates normal processing (see ISO/IEC 7816- 4:2013, Table 5);
— such a transition shall be declared during object creation phase with the use of CREATE command only; the use of any other command to achieve the same goal Is out of scope of this document;
— the payload of CREATE shall contain within CP template (DO’62’) a data object AE nesting one or more context-specific configuration DOA1, each of which features a value field describing the conditions for a command-dependent I.CS transition and is comprised of:
— an LCS DO’8A according to ISO/IEC 7816-4:2013, Table 14 denoting the starting LCS for the transition;
— one or more access mode DO from ‘81’ to ‘HF’ according to lSG/IEC 7816-4:2013. Tables 31 and 32. optionally followed by security condition data objects according to lSO/IEC 7816-4:2013, Table 33; access mode and security condition compose an access rule; the LCS transition occurs if and only if this access rule is fulfilled;
— an ICS DO’HA’ denoting the targeted 1,CS for the transition.