ISO/IEC 7816-4
Identification cards — Integrated circuit cards — Part 4: Organization, security and commands for interchange
Cartes d’identification — Cartes à circuit intégré — Partie 4: Organisation, sécurité et commandes pour les échanges

Security architecture
This clause describes security status, security attributes and security mechanisms.
Security status——The security status represents the current state possibly achieved after completion of the answer to reset and a possible protocol and parameter selection and / or a single command or a sequence of commands possibly performing authentication procedures. The security status may also result from completion of a security procedure related to the identification of the involved entities, if any, e.g., by proving knowledge of a password (e.g., using a VERIFY command) or knowledge of a key (e.g., using a GET CHALLENGE command followed by an EXTERNAL AUTHENTICATE command, or using a sequence of GENERAL AUTHENTICATE commands), or by secure messaging (e.g., message authentication). Four security statuses are considered.

Global security status — In a card using a hierarchy of DFs, it may be modified by completion of an MFrelated authentication procedure (e.g., entity authentication by a password or a key attached to the MF).
Application-specific security status — It may be modified by completion of an application-related authentication procedure (e.g., entity authentication by a password or a key attached to the application); it may be maintained, recovered or lost by application selection; this modification may be relevant only for the application to which the authentication procedure belongs. If logical channels apply, then the application-specific security status may depend on the logical channel.
File-specific security status — It may be modified by completion of a DF-related authentication procedure (e.g., entity authentication by a password or by a key attached to the specific DF); it may be maintained, recovered or lost by file selection; this modification may be relevant only for the application to
which the authentication procedure belongs. If logical channels apply, then the file-specific security status may depend on the logical channel.
Command-specific security status — It only exists while processing a command using secure messaging and involving authentication; such a command may leave the other security status unchanged.

Security attributes——The security attributes, when they exist, define which actions are allowed, and under which conditions. The security attributes of a file depend on its category (DF or EF) and on optional parameters in its file control information and / or in that of its parent file(s). Security attributes may also be associated with commands, data objects and tables & views. In particular, security attributes may
–specify the security status of the card to be in force before accessing data;
–restrict access to data to certain functions (e.g., read only) if the card has a particular status;
–define which security functions shall be performed to obtain a specific security status.

Security mechanisms——This clause considers the following security mechanisms.
–Entity authentication with password — The card compares data received from the outside world with secret internal data. This mechanism may be used for protecting the rights of the user.
Entity authentication with key — The entity to authenticate has to prove the knowledge of the relevant secret or private key in an authentication procedure (e.g., a GET CHALLENGE command followed by an EXTERNAL AUTHENTICATE command, a sequence of GENERAL AUTHENTICATE commands).
Data authentication — Using internal data, either a secret key or a public key, the card checks redundant data received from the outside world. Alternately, using secret internal data, either a secret key or a private key, the card computes a data element (cryptographic checksum or digital signature) and inserts it in the data sent to the outside world. This mechanism may be used for protecting the rights of a provider.
Data encipherment — Using secret internal data, either a secret key or a private key, the card deciphers a cryptogram received in a data field. Alternately, using internal data, either a secret key or a public key, the card computes a cryptogram and inserts it in a data field, possibly together with other data. This mechanism may be used to provide a confidentiality service, e.g., key management and conditional access. In addition to the cryptogram mechanism, data confidentiality can be achieved by data concealment. In this case, the card computes a string of concealing bytes and adds it by exclusive-or to bytes received from or sent to the outside world. This mechanism may be used for protecting privacy and for reducing possibilities of message filtering.
The result of an authentication may be logged in an internal EF according to application requirements.

Cryptographic mechanism identifier template
Referenced by tag ‘AC’, one or more cryptographic mechanism identifier templates may be present in the control parameters of any DF (see Table 12). Each one explicitly indicates the meaning of a cryptographic mechanism reference in the DF and its hierarchy. Such a template shall consist of two or more data objects.
–The first data object shall be a cryptographic mechanism reference, tag ’80′ (see Table 33).
–The second data object shall be an object identifier, tag ’06′, as defined in ISO/IEC 8825-1. The identified object shall be a cryptographic mechanism specified or registered within a standard, e.g., an ISO standard. Examples of cryptographic mechanisms are encryption algorithms (e.g., ISO/IEC 18033[18]),
message authentication codes (e.g., ISO/IEC 9797[7]), authentication protocols (e.g., ISO/IEC 9798[8]), digital signatures (e.g., ISO/IEC 9796[6] or 14888[16]), registered cryptographic algorithms (e.g., ISO/IEC 9979[9]), and so on.
–If present, one or more subsequent data objects shall either identify a mechanism, tag ’06′, used by the previous mechanism (i.e., a mode of operation, e.g., ISO/IEC 10116[11], or a hash-function, e.g., ISO/IEC 10118[12]), or indicate parameters (tag dependent on the previous mechanism).
EXAMPLES (see explanations in annex A)
{‘AC’ – ’0B’ – {’80′-’01′-’01′} – {’06′-’06′-’28818C710201′}}
The template associates the local reference ’01′ to the first encryption algorithm in ISO/IEC 18033-2[18].
{‘AC’ – ’11′ – {’80′-’01′-’02′} – {’06′-’05′-’28CC460502′} – {’06′-’05′-’28CF060303′}}
The first object identifier refers to the second authentication mechanism in ISO/IEC 9798-5[8]. The second object identifier refers to the third dedicated hash-function in ISO/IEC 10118-3[12]. Therefore the template associates the local reference ’02′ to GQ2 using SHA-1.