SPECIALISTS IN INFORMATION SECURITY MANAGEMENT SYSTEMS (ISO/IEC 27001)
YOU ARE IN GAMMA’S RESEARCH ARCHIVES — THIS PAGE IS OF HISTORIC INTEREST ONLY — EXIT
A SECURITY ARCHITECTURE for GLOBALPLATFORM SMART CARDS*
The security requirements for Open Platform (OP) smart cards are defined in the GlobalPlatform Card Specification (GPCS), and are recast in the language of ISO/IEC 15408 (the “Common Criteria”) in the Visa Open Platform Protection Profile (OP3[2, 3]). The GPCS does not elaborate on the security requirements for the underlying Runtime Environment (RTE) or the integrated circuitry (IC). However, OP3 does go into further detail by specifying the security properties of what it calls the “Card/Chip Operating Environment” (COE, see Figure 1) in terms of the security objectives, the anticipated security functions and the types of threat that the COE is expected to counter. This specification ought to be sufficient, but in practice there are other protection profiles that need to be considered. These include the Eurosmart Protection Profiles (PPs) 9806 and 9911, the Smart Card Security Users Group (SCSUG) PP, the Secure Silicon Vendors Group (SSVG) PP and, for JavaCard™ based systems, the JavaCard™ System (JCS) PP.
Unfortunately it is not straightforward to write a Security Target (ST) that is compliant with two or more PPs. For example, commonality of Security Function Requirements (SFRs) between PPs does not imply that the requirement is to be implemented by the same Target Of Evaluation (TOE) Security Function (TSF). In other cases, seemingly diverse requirements are implemented by the same TSF. In addition there is a problem in demonstrating compliance, as each PP addresses a different set of assumptions, policies, threats and objectives depending on its scope.
This paper proposes a solution to these difficulties by presenting a security architecture for OP smart cards that is strongly compatible with all the abovementioned PPs. In particular, the architecture is conformant with OP3 and the SCSUG, JCS and SSVG PPs, and covers all the optional functionality, such as delegated management and cardholder verification, that is defined in GPCS. This paper describes the architecture and how PP conformance may be demonstrated.
The Security Architecture
The Security Architecture is shown in Figure 2. This architecture may considered to be generic and applicable to all OP smart cards, regardless of whether the COE is JavaCard™ or not.
There are 8 hierarchical layers, called:
(a) Layer 1 – Physical Resistance
(b) Layer 2 – Electrical Interface
(c) Layer 3 – Software Control
(d) Layer 4 – Card Integrity
(e) Layer 5 – Card Management
(f) Layer 6 – Security Domain Management
(g) Layer 7 – Application Control
(h) Layer 8 – Application
Assuming the TOE is trusted, there are just three ways by which an attacker may attempt to gain access to the assets protected by the TOE: (a) as an application (Layer 8), which means that the attacker must somehow introduce an “agent” application onto the card; (b) as an off card entity via the input/output (I/O) facility (Layer 2), which is the normal method for an off card entity to communicate with the card; (c) by a direct attack on the card.
In the first instance, such a direct attack may attempt to penetrate the defences of the first layer – Physical Resistance. Subsequently the attacker has to contend with the defences of the second layer – Electrical Interface. An attack perpetrated via an off card entity via the I/O facility is also addressed at this layer. Thus, these two layers form the first line of defence against a direct attack on the card.
At Layer 3 – Software Control, OP takes control of security, ensuring that the security features of OP and the RTE are always invoked and cannot be bypassed, deactivated, corrupted or otherwise circumvented. Layer 3, building on memory management features included at Layer 2 and RTE “firewall” mechanisms embodied in Layer 3, also provides applet separation. Thus, another service provided by Layer 3 to the higher layers is that one application, including the SELECT-able OP applications (i.e. Card Manager and the various Security Domains) cannot interfere with each other.
At Layer 4 – Card Integrity, any problems resulting from premature withdrawal of the card from a card acceptance device or terminal, or any other form of power-failure are resolved. At Layer 5 – Card Management, access to the OP Card Management functions by off card entities is controlled, the necessary OP Card Manager functionality is provided and the various state transitions (e.g. card termination, application locking and unlocking) take effect. At Layer 6 – Security Domain Management, access to the OP Security Domain functions (e.g. the establishment of a Secure Channel) by off-card entities is controlled and the relevant functionality is provided. At Layer 7 – Application Control, access to the OP API by applications is controlled. Particular security functions of OP that operate at Layer 5 prevent the loading of applications, which execute at Layer 8, that are unauthorized by the Card Issuer (or some other Controlling Authority, see GPCS section 3.3).
In addition to the various layers, Figure 2 also identifies “bundles” of SFRs that have a like purpose. These represent the security features of the architecture, which may be referred to as the TOE Security Functions (TSFs).
Layers 1 and 2
The first two layers can be thought of broadly as representing the IC. However, even though there is a strong recommendation (see SSVG PP) to implement a high quality random number generator in hardware, the decision of whether to use hardware or software encryption is left to the card manufacturer. Consequently, Layer 2 is split into 2 sub-layers to allow the architecture to faithfully describe cards with and without hardware-based encryption. The “Crypto” TSF provides encryption/decryption services to various TSFs in Layers 5 and 6, such as the “Del Man” TSF, which provides OP’s delegated management functionality, which in turn is based on cryptography. In particular, the Card Issuer may permit an Application Provider to manage the loading, installation and deletion of their own applications, given suitable pre-authorisation. In the case of loading and installation the Card Issuer provides the Application Provider with a token that is a function of the authorised application signed using a private key by the Card Issuer. The “Del Man” TSF returns a similarly unforgeable token to confirm that the operation has been performed successfully.
The other TSFs in Layer 1 and 2 map elegantly onto the principal components that one would expect to find on an IC, such as the Central Processing Unit (CPU), Input/Output (I/O), Memory Management Unit (MMU) and the buses, as well as some whose primary function is security, such as the sensors. The purpose of the “Sensors” TSF is to detect when operating parameters, such as temperature, voltage and clock frequency, go beyond their safe operating limits. The “MMU” TSF controls access to memory, so that software, which has been restricted to use a particular address range, cannot access any part of memory outside of that range. Likewise security measures provided by the “Bus” TSF are designed to protect the confidentiality of data passing along the bus to and from the CPU and the other IC components.
The “Coating” TSF has the purpose of making any attempt to physically tamper with the card obvious and may perhaps, depending on the characteristics of the coating, lead to irrevocable damage to the IC.
Layer 3 provides most of the security features required by the RTE, the others being provided at Layers 4 and 5. The “Firewall” TSF controls application access to RTE objects and relies on the “Object ID” TSF to identify them. The primary purpose of the “Firewall” TSF, in association with the “MMU” TSF, is to provide “separation” – FDP.SEP.1 – that is, to prevent applications from communicating with each other by any means other than a RTE supported inter-application communication channel (e.g. via a shareable interface object in JavaCard™) and only then in accordance with a RTE specified access control policy and a RTE specified information flow control policy. In JavaCard™ these policies are specified in the JavaCard™ specifications  and recast into the language of the Common Criteria in the JCSPP. The “Exception” TSF implements handles RTE exceptions (e.g. in accordance with the JavaCard™ specifications ) but in addition caters for OP “exceptions”, such as the detection of potential security violations. In all cases, the resulting action must be in compliance with a Card Issuer defined policy, which is not defined in OP3 or any of the other PPs studied, called P.EVENT_ACTIONS. This policy instructs the Card Manager what to do under each particular circumstance. The actions range from “do nothing” to “terminate the card”, and provides the Card Issuer with the flexibility to adopt or reject the optional GPCS requirements that OP3 refers to as the “Intrusion Detection Package” [2, 3]. The Card Manager is a OP component that is the on card representative of the Card Issuer and is the central administrator of the entire card. This function is wrapped up in the “Supervisor TSF”, which also:
The “Object Reuse” TSF makes sure that any data left in any object is destroyed before that object is reused or could otherwise be accessed by a different application. There are a variety of such re-use conditions, involving temporary data storage objects, cryptographic buffers, the APDU buffer and the mutable persistent memory that should be vacated when an application is deleted. The “Card Audit” TSF allows the identity of the card to be revealed to an off card entity along with other, more traditional computer audit information, in accordance with the Card Issuer’s policies.
The SFRs that map to Layer 4 divide into two distinct categories: those that test the card and those that allow the card to recover itself to a secure state following some mishap, such as a power failure. Self-testing (amongst other things) allows the card to detect if it has been tampered with since it was last powered up. This is incredibly important, as a crucial aspect of information security is to know when you have been attacked. The action to be taken in this event would be in accordance with the P.EVENT_ACTIONS policy but could be to alert the Card Issuer and lock or terminate the card. The other TSF (R&R) deals with rollback and recovery. This is not as straightforward as some people might expect and, from a security perspective, some events must never be rolled back. For example, if the PIN retry counter was rolled back then the astute attacker may be able to gain an unlimited number of retries. The policies concerned are specified in OP3 .
Layer 5 provides the Card Manager features as defined in GPCS and the basic cryptographic key management services. The latter, implemented by the “Key Mgt” TSF, concern the generation, distribution, accessibility and destruction of cryptographic keys. Note that the TSF sits higher in the layered hierarchy than the “R&R” TSF because there are roll back policies associated with certain key management operations, such as the replacement of a key. Both OP and RTE key management operations are catered for, thereby allowing applications the ability to invoke standard RTE cryptographic functions (e.g. in JavaCard™, via set key and get key) instead of, or in addition to the OP API methods.
The “State Trans Cmd” TSF controls the transitions between the various Card Manager, Load File and Application lifecycle states defined by GPCS. In OP3, the applicable access control policy is P.STATE_TRANSITION. Of the remaining TSFs, “Del Mgt” has been previously discussed (see Layers 1 and 2), “Sec Mgt” and “CCMF” provide miscellaneous security management and Card Content Management Functions respectively and “CM Access” controls off card access (i.e. via APDU commands) to the Card manager. In OP3, the applicable access control policy is P.CARD_MANAGER. In future revisions of the Architecture, it is possible that the “Del Mgt” and “CCMF” TSFs will be combined because the GPCS delegated management function is just a special case of the more general rule that all CCMFs (e.g. the loading, installation and deletion of applications) must only be carried out with the pre-authorisation of the Card Issuer. Of course, when the Card Issuer issues the command, one would assume that it has “pre-authorised” itself!
Layers 6, 7 and 8
The TSFs in Layer 6 represent the various GPCS functions concerning Security Domains. Security Domains are the on-card representatives of Application Providers and Verification Authorities (collectively termed “Security Domain Users”, see OP3 ) and may manage the loading and installation of applications pre-approved by the Card Issuer. The multiplicity of Security Domains allows each Security Domain User’s security data (such as cryptographic keys) to be kept separate and private from that of other Security Domain Users and the Card Issuer. The Card Manager contains a Security Domain (referred to as the Issuer Security Domain) for the sole use of the Card Issuer in its role as an Application Provider or a Verification Authority. (Note that in the banking world this duality of role is the norm, rather than the exception.) The Verification Authority is a role that is essential in the case of JavaCard™ as its function is to confirm that applications have passed byte code verification. In the case where the Card Issuer is not the sole Application Provider, OP3 insists that confirmation of successful byte code verification is performed using the GPCS Data Authentication Pattern (DAP) Verification functions, via a separate Security Domain that is owned by the Verification Authority and is only used for that purpose. This function is provided by the “Confirm Code Verification” TSF.
The original GPCS purpose of DAP Verification is to allow Application Providers the opportunity to verify that applications loaded on their behalf by the Card Issuer, or some third party, are genuine. This is an optional GPCS function as the need to carry out this form of verification depends on the level of risk that is acceptable to the various parties concerned. The function is provided by the “Load File Verification” TSF and may be combined in a future revision of the Architecture with the “Confirm Code Verification” TSF as the mechanics of the two security mechanisms, albeit they are used for two entirely different purposes, are identical.
The “Secure Channel” TSF implements all the SFRs concerning the OP Secure Channel Protocol (SCP). The SCP provides a variety of card-host secure communications services including:
Although the SCP must be used for particular APDU commands, there are other communications, for example those between an off card entity and the applications, for which the use of the SCP is optional. The purpose of the “Non-Secure Channel” TSF is to ensure that this “non-secure channel” cannot be used to compromise the security of the card. Note that this rather quaint objective is reinforced in GPCS Version 2.1 as a SCP session will be automatically initiated as soon as a cryptographically protected APDU command is received, rather than having to wait for an INITIALIZE UPDATE which is the explicit command to initiate a SCP session.
The “CVM Handler” TSF provides the means for applications to share a common cardholder verification method (which is an optional GPCS facility) as well as providing the traditional RTE means for cardholder authentication such as Owner.PIN in JavaCard™. Off card entity access to all of these functions is controlled by the “SD Access” TSF (P.SECURITY_ DOMAIN in OP3). Access to these functions, and those at Layer 5, that are accessible to applications (i.e. via the OP API) are controlled by the “CVM Handler” TSF for cardholder authentication (P.CVM in OP3) and by the “OP API Access” TSF for all other functions (P.OP_API in OP3). Note that currently no TSFs are associated with the Application Layer, as none of the PPs studied so far cover applications.
During the allocation of SFRs to the Layer 2 TSFs it became evident that:
Assumptions, Threats, Policies and Objectives
Demonstrating CC Compliance
The TSF described in the previous section cover every SFR in all six PPs studied (see Appendix A). The question arises, “it is possible to demonstrate that a ST is compliant with more than one PP merely by showing that all of the SFRs are addressed?” The answer proposed by the authors  is “yes” as far as the functionality is concerned (Security Assurance Requirements are a different concern) provided that certain properties are satisfied by the Architecture.
The reason for this is twofold. First: mathematically, security objectives serve to map the SFRs to the threats and policies. Thus, if (a) the security objectives address all the threats and policies and (b) the SFRs address all the security objectives, then the SFRs must address all the threats and policies. Hence, given the same set of threats and policies and the same set of SFRs, it is possible to create different sets of security objectives that achieve exactly the same mapping of SFRs to threats and policies, even though there will be different mappings of objectives to threats and policies and objectives to SFRs. Naturally, it is unnecessary to identify all possible sets of security objectives, just one will do. Second: threats and policies are interchangeable. One PP could attribute a security objective to a threat and other to a policy. Thus, the SFRs will in practice meet many unstated threats and policies. In demonstrating the utility of the chosen SFRs a single minimal set of threats and policies will suffice. It is not necessary to identify all the unstated threats and policies. Indeed, this would be an endless task. In conclusion, it would therefore appear that to demonstrate compliance with more than one PP, it is only necessary to demonstrate compliance with the SFRs (and SARs): for this purpose the threats, policies and objectives are redundant.
However, as pointed out in the SCSUG PP, certain SFRs must be implemented in hardware. Therefore this conclusion is only valid if the TSFs are implemented in the “proper” place from an architectural perspective. Broadly speaking Layers 1 and 2 constitute the hardware of the OP Card; Layers 3 through 8 constitute the software. Inspection of the table in Appendix A shows that all SSVG PP SFRs (marked «) are allocated to the hardware layers, with one exception. The exception is FAU_SAS.1, which has been associated with the “Card Audit” TSF at Layer 3 because it concerns the writing of initialisation data into the audit records. Inspection will also show that all SCSUG PP SFRs that SCSUG does not intend to be implemented in hardware (marked W) are allocated to the software layers. Note that there are some SFRs that are allocated to Layer 2 which are similar in nature to those marked W, e.g. FDP_ACF.1. These derive from PP9806 and their use, although not incorrect, is discussed in SSVG PP, which points out, for example, that as the access control policies within the IC are so simple, the use of these SFRs is over-kill.
Note (by Figure 2 and the discussions that concern it) that the Architecture also possesses the following properties:
a) The layers are logically ordered, with the applications on the top and the interfaces to external devices at the bottom.
b) Each layer provides a security service to the higher layers.
c) For any given layer, inclusive of all lower layers, there are no unjustified missing dependencies. This would not be true if the allocation of TSFs to architectural layers was inappropriate.
Thus, it may be concluded that the TSFs are implemented in the “proper” place from an architectural perspective and therefore the conclusion concerning demonstrating PP-compliance using SFRs is valid.
Producing a ST
However, a ST still requires a set of relevant assumptions, threats, policies and objectives. Those required by the architecture are those defined by OP3, augmented as necessary in order to describe the additional SFRs required by JCSPP, SSVG-PP and SCSUG-SCPP. The choice of OP3 for this purpose was convenience but in principle any of the other PPs would have served equally as well. The augmentations were limited to these PPs as the goal of the original work  was to produce a ST that was only compliant to these PPs.
That OP3 was a good choice is founded on the observation that:
The principal conclusion of this work is that the Architecture provides an elegant way of showing how many types of smart card PP fit together. The various groupings are shown in Appendix A. In some cases different SFRs have been used to describe the same function. A good example is the “Message Authentication and Integrity” Security Function where in particular the SCSUG requirement FPT_RPL.1 (which concerns defences against replay attacks on the SCP) complements and adds clarity to the OP3 FCS_COP.1 requirements, which explain how the security mechanisms work. In other cases, e.g. in the “CPU” Security Function, some of the SFRs particularly those that originate from PP9806 confuse the issue and indeed are considered over-kill by SSVG.
There is some scope for combining some of the TSFs. For example, the “Confirm Code Verification” and “Load File Verification” TSFs might be combined to form a single “DAP Verification” TSF. There might also be scope for associating all of the management functions directly with the SFRs that they manage and thereby obviate the need for the “Security Management” TSF.
Application of the Architecture shows that there are missing SFRs and that it is evident that it can play a useful role in vulnerability analysis as it allows the interaction of countermeasures throughout the entire card – IC, RTE and OP – to be understood.
The original architecture work was performed under contract F-X2-K0017 for the Industrial Technology Research Institute (ITRI) in Taiwan, R.O.C. The authors would like to thank ITRI for its support and funding. The authors would also like to thank Marc Kekicheff of Visa International for his helpful advice and encouragement.
 The GlobalPlatform Card Specification, version 2.1, issued June 2001, obtainable from www.globalplatform.org
 Smart Cards: The Open Platform Protection Profile, Brewer, D.F.C., Kekicheff, M., Kashef, F., Proceedings of the Second International Common Criteria Conference, Brighton, UK, 2001
 The Open Platform Protection Profile, Version 0.9 issued March 2001, obtainable from Global Platform (www.globalplatform.org)
 Smart Card Integrated Circuit Protection Profile, PP9806, Version 1.0, September 1998
 Smart Card Integrated Circuit with Embedded Software Protection Profile, PP9911, Version 2.0, June 1999
 The Smart Card Security Users Group Smart Card Protection Profile, version 3.0 issued August 2001
 The Secure Silicon Vendors Group Smartcard IC Platform Protection Profile, version 1.0, July 2001, BSI-PP-0002.
 Go to the following web site for JavaCard™ documentation: www.javasoft.com
 Proving Protection Profile Compliance for the CCL/ITRI Visa Open Platform Smart Card, Brewer, D.F.C., Wang, C. and Tsai. P., Proceedings of the Third International Common Criteria Conference, Ottawa, Canada, 2002
Appendix A – Cross References of SFRs to Architectural Layer and TSF