Published information, whether in the form of periodicals, journals or files transferred around the internet needs to be trusted, if it is to be truly useful. In order to trust information, it is important to know who prepared it and where the raw data came from.
It is equally important to know that the presented information has not been altered since it was prepared. Achieving such aspects of security is the central goal of Identification, Authentication and (digital) Signature (IAS) systems. These are security systems that make use of personal tokens, often smart card based, to establish the trustworthiness of information.
ISO/IEC 24727 – Identification cards – Integrated circuit card programming interfaces is a six part International Standard whose purpose is the enhanced interoperability of IAS systems (see figure 1 for a schematic overview). Five parts of ISO/IEC 24727 have completed the standards development process and are currently designated as International Standards. These parts are:
- Application Programming Interface
- Generic Card Interface
- API Administration
- Authentication Protocol Registration Authority
The sixth part, a conformance testing standard called ISO/IEC 24727-5, is currently at the Final Draft International Standard stage. ISO/IEC 24727 establishes interoperability for token-based systems, defined as ‘independent implementations are interchangeable’, in a number of ways. It enhances:
- the interchangeable use of tokens among diverse IAS systems
- the independence of middleware components and tokens
- the independence of token administration and of component certification procedures
Current work on the standard focuses on amendments to accommodate recent enhancements to the state of the art.
Digital transaction systems typically include one or more of the facilities that are collectively referred to as computer-security facilities. These include:
Authentication refers to reliably distinguishing one person from all other people, a concept also called identification, and verifying that identification within the context of a specific interaction.
Authorization refers to the application of rules (policy) based on authentication.
Secrecy refers to shielding an interaction process, and its salient information, from eavesdroppers.
- Data integrity
Data integrity refers to the assurance that the source of information can be authenticated and that the information has not changed during the course of an interaction.
Non-repudiation refers to some means of assuring that the actions of participants to an interaction actually emanated from the authenticated participants.
All of these facilities are derived from basic concepts of interaction mechanics long practiced by humans. Through a variety of biophysical and social processes, people seek to achieve predictable outcomes of interactions. This is another way of saying that people seek to establish trust within interactions. The means of providing security, and hence trust, in digital interactions are based largely on cryptographic mechanisms that are generically referred to as Identification, Authentication and Signature (IAS) systems. These comprise the nucleus of all digital identification systems.
At the present time, most digital identification systems are quite insular in their construction and use. This isolation encourages significant duplication of personal information storage and retrieval across the diverse domains in which the various systems operate. Such duplication gives rise to threats leading to diminished trust, to identity theft or to infringement of personal privacy. Achieving interoperability across the domains of discrete IAS systems helps to mitigate these threats, thus greatly enhancing the trust on which highly distributed applications are so dependent for effective operation. Adopting as a working definition that ‘independent implementations are interchangeable’, interoperability was a major impetus for the development of the ISO/IEC 24727 – Identification cards – Integrated circuit card programming interfaces standard aimed at token-based IAS systems.
Principles for achieving interoperability
Interoperability across independently developed systems can be achieved through the application of several well-understood principles. In the case of ISO/IEC 24727, these include ‘common architectures’, ‘common semantics’, ‘formally defined interfaces’, ‘discoverability’, ‘extensibility’ and ‘backward compatibility’; all given standard form through ‘conformance testing’.
Based on the OSI Reference Model, the standard specifies a protocol stack architecture through which computer applications needing IAS services can obtain them from personal tokens; typically smart card based tokens. Such an architecture is often termed ‘middleware’, referring to software that forms a switch in the middle of the protocol stack allowing a variety of applications to access a variety of tokens. This is the prevalent architecture for existing token-based IAS systems. One of the distinguishing characteristics of the ISO/IEC 24727 stack model is its orientation toward end-application service semantics rather than lower level cryptographic or smart card semantics.
Since equivalent computer security services are encompassed by virtually any IAS system, establishing a set of common semantics describing those services is relatively straightforward. ISO/IEC 24727 adopts a design model comprised of two peer-level applications communicating through a well defined protocol stack: a ‘client application’ resident on some host computer platform accessing services provided by a ‘card application’ found resident on a token. The services required fall into several distinct categories:
• Differential identity
The general concept that we call identity has at least two rather distinct facets. One deals with distinguishing people; that is, simply telling them apart. In the standard, this facet is referred to as ‘differential identity’. It is the facet involved in the act of authentication and the connection of identity to cryptographic operations to facilitate secrecy, data integrity and non-repudiation within interactions. A separate facet is the attribution of information to a person, such as where they live, or whether they have a college degree. This facet is encompassed by the named-data services of IAS systems, and often includes the use of credentials such as digital certificates to enhance the trustworthiness of such information.
Each service provides a collection of actions aimed at various targets. It is through these actions on their respective targets that the facilities referred to earlier as computer security are operationally provided. A client application and a card application share a common security context in which differential identities can be authenticated, forming a common basis of trust across the two distinct platforms. Based on the authentication states of various differential identities, access control lists limit access to information or processing between connected client applications and card applications.
Interfaces of ISO/IEC 24727
ISO/IEC 24727 defines four interfaces that delineate the protocol stacks that connect client applications to card applications.
1. ISO/IEC 24727-3 API
This interface defines a programming interface that is semantically oriented toward the domains of client applications. That is, the API expresses actions and information in a form that closely follows the manner in which client applications typically address their respective problem domains.
2. ISO/IEC 24727-2 Generic Card Interface (GCI)
In a similar fashion, ISO/IEC 24727-2 Generic Card Interface (GCI) defines a programming/communication interface consistent with smart card token programming as specified in the ISO/IEC 7816-4 Organization, Security and Commands for Interchange standard. This more basic standard provides, in essence, a comprehensive toolkit for smart card programming. ISO/IEC 24727-2 focuses on a subset of the available smart card operational commands in order to achieve interoperability across more comprehensive token implementations in the IAS domain.
3. ISO/IEC 24727-4 API Administration
This interface addresses the various stack configurations through which interoperability can be achieved. Within this standard, two additional interfaces are defined:
• the Trusted Channel Interface (TC-API), which provides a general networking interface that allows stack components to be distributed across local or wide-area networks;
• the Interface Device API (IFD-API), which specifies a platform neutral interface through which token interface devices can be accessed by their host platform systems.
The above three interfaces are each specified in detail through formal language definitions, using the computer readable formal languages known as ASN-1 and XML. These formal language definitions are found in ISO/IEC 24727-3 & 4, allowing the respective interfaces to be conveyed across general communication channels.
4. the GCI defined in ISO/IEC 24727-2
This fourth interface actually comprises a communication interface in its own right, and hence is not given a separate, formal language definition. The GCI makes use of ‘application programming data units’ (APDUs), the communication channel message structure defined in ISO/IEC 7816-4, a standard for smart card based tokens.
With application systems developed in the highly insular fashion noted above, the operational procedures through which a client application accesses a card application on a token are fixed by the design of the application. If a token prepared in one application system is to be effectively used in a different application system, then there must either be a significant degree of commonality of information context and operational procedures, or an application system must be able to discover the context and procedures needed to access the token. Hence, ISO/IEC 24727 encompasses a significant degree of discoverability. The primary discovery mechanisms are a ‘card capability descriptor’ (CCD) and an ‘application capability descriptor’ (ACD). Think of these as cursory, computer software readable instruction manuals that can be presented by a token from one system to an application from a different system through a common structure of the middleware stack that connects the two. The CCD conveys instructions for the token as a whole while an ACD conveys instructions for a specific card application found on the token.
A significant component of an ACD is a collection of information unofficially termed ‘the Registry’. This set of information is expressed in the form of a data store fashioned according to ISO/IEC 7816-15 Cryptographic information application. Through the Registry, related information necessary for the provision of IAS services can be passed among disparate application systems. As an example of its utility, through this mechanism the popular name of an entity, perhaps a person, as known within some specific client application can be associated with a marker such as a biometric characteristic, a PIN or perhaps a private key. The same popular name can also be associated with a specific authentication protocol through which knowledge or possession of the marker can be used to authenticate the differential identity of the entity in question. Thus the Registry provides discoverability at an operational level, allowing distinct client applications to behave similarly while using the same token. In a corollary fashion, the same mechanism allows a single client application to behave consistently when using tokens from disparate IAS systems.
Obviously, the CCD and ACD mechanisms cannot be found on tokens created prior to the development of ISO/IEC 24727, and in fact may not be present on tokens in any case if their use across IAS domains was not anticipated. In order to provide a significant degree of backward compatibility with such tokens, these capability descriptors do not have to be physically present on the tokens to which they refer. They can either be contained within the standards-compliant middleware stacks, or they can be accessed from secure data stores, including distributed Internet stores.
An inherent benefit, and liability, of standards-based components is the long-term stability of the standards in question. That is, the process through which international standards are developed and through which they can be subsequently amended, is methodical but time-consuming at best. While the investment in developing standard components is protected from a dynamically changing capability set, this same stability precludes the rapid tracking of technology advances. To address this stability versus change issue, ISO/IEC 24727 encompasses two distinct extensibility facilities that support change at a pace somewhat faster than the usual standards-making process.
The first extensibility facility provides for ongoing adoption of authentication protocols. Such protocols are central to the establishment of shared trust environments between client applications and token-based card applications. ISO/IEC 24727-6 Authentication Protocol Registration Authority specifies an operational approach through which new or modified authentication protocols can be documented and registered in a form consistent with ISO/IEC 27472-3, but in a much more efficient manner. The Registration Authority exists as an organizational entity that can be accessed by individuals, companies or even the national bodies of standards organizations. Protocols enlisted with the Registration Authority become subject to open documentation and conformance testing. Thus, advances in authentication technology can be tracked in a much more responsive fashion than would be the case if only the standards-making process was available.
A second extensibility mechanism exists in the form of a procedural element that may be used by an implementation of ISO/IEC 24727-2 to map the GCI into a proprietary command set of a token implementation. The programming language for this procedural element is standardized, allowing generic GCI implementations to make use of code from many different token vendors. Also, much as is done with the CCD and ACD components, procedural elements can be drawn from sources other than tokens themselves. Thus, it is possible to map existing, proprietary tokens into the GCI and hence into standard implementations of ISO/IEC 24727 middleware stacks. Moreover, GCI access can be extended to newly-developed token systems.
Adherence to standards
Conformance to the standard is addressed through testing defined in ISO/IEC 24727-5 Testing. For the complex implementations addressed by ISO/IEC 24727, simply claiming that a particular system is conformant to the standard is generally not a realistic assessment. Many, if not most systems will only be addressed by certain parts of the standard. So, to allow greater visibility into just what parts are applicable to a given system, test vectors identify in detail which aspects of the full ISO/IEC 24727 standard are adhered to by specific components. The actual testing programs are effected through certified testing laboratories, much as is done with Common Criteria or FIPS certification.
To achieve the capabilities noted above, ISO/IEC 24727 has been developed in six parts. Five of these parts have now reached the state of International Standards. These are ISO/IEC 24727-1 Architecture, ISO/IEC 24727-2 Generic Card Interface, ISO/IEC 24727-3 API, ISO/IEC 24727-4 API Administration and ISO/IEC 24727-6 Authentication Protocol Registration Authority. The remaining part, ISO/IEC 24727-5 Testing, is currently being balloted at the Final Draft International Standard stage. It is anticipated that this part will achieve the state of International Standard during the last half of 2010. Looking forward, in an effort to keep ISO/IEC 24727 abreast of ongoing developments, an amendment process has been started for the first four parts of the standard. Amendments to the various parts of the standard allow addressing ambiguities that might arise as diverse implementations are actually made to interoperate. Moreover, the amendment process allows for adoption of enhancements that are sure to derive from a robustly evolving IAS domain.