David Brewer

Chilung Wang, Paulie Tsai

Gamma Secure Systems Limited

Diamond House, 149 Frimley Rd

Camberley, Surrey GU15 2PS, UK

Industrial Technology Research Institute

X200, Bldg. 51, 195-11, Sec. 4, Chung Hsing Rd., Chutung

Taiwan, R.O.C.

* PUBLISHED AT THE e-Smart 2002 CONFERENCE, 19-20 SEPTEMBER 2002, NICE, FRANCE © 2002 GAMMA & ITRI. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from both Gamma and ITRI.


The security requirements for Open Platform (OP) smart cards are defined in the GlobalPlatform Card Specification (GPCS[1]), 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[4] and 9911[5], the Smart Card Security Users Group (SCSUG) PP[6], the Secure Silicon Vendors Group (SSVG) PP[7] 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). 

Security Functions

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[7]) 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

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 [8] 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 [8]) 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:

  •  From a security perspective, ensures that all software implemented security features are invoked at the right time and cannot be bypassed, deactivated, corrupted or otherwise circumvented (FPT_RVM.1)

  • From a JavaCard™ perspective, executes the applets.

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.

Layer 4

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 [3].

Layer 5

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 [3]) 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:

  •  Mutual or peer authentication depending on the SCP that is used (GCPS version 2.1 defines two such protocols)

  •  Message encryption

  • Message integrity

  • A defence against “replay” attack

  • A secure means for key distribution and the uploading of “cardholder verification values”, e.g. PINs.

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.

An Observation

During the allocation of SFRs to the Layer 2 TSFs it became evident that:

  •  There were missing SFRs.  For example, one of the functions of the “RNG” TSF is to generate random wait states, but there is no corresponding SFR in any of the PPs that instructs the evaluator to look at what the IC does with them.

  • The relationship between SFRs plays a significant role in identifying attack scenarios that the IC must defend itself against.  For example, whatever method is used to protect the data that passes along the buses from disclosure, the method might be discovered as soon as the data leaves the IC via the I/O port, rendering the protection mechanism largely a waste of time.  For example, once the card is powered up, it will send an “Answer to Reset” off card. This is analogous to a plain text attack in cryptography.

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 [9] 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 [9] was to produce a ST that was only compliant to these PPs.

That OP3 was a good choice is founded on the observation that:

  • There were no changes or additions required by the Architecture to the OP3 assumptions

  • There were no changes or additions required by the Architecture to the OP3 threats (the threats to the RTE and the IC being adequately covered by OP3’s discussion of the threats to the COE)

  • There were no changes or additions required by the architecture to the OP3 organisational policies, but some additional policies were found to be required.  The most important of these is P.EVENT_ACTIONS, which has been described previously.  The remainder derive from the other PPs and are required because their SFRs refer to them.

  • It was found necessary to modify three OP3 security objectives, six COE security objectives and add two new ones, in order to better describe the SFRs that had been introduced by seeking compliance with these other PPs. 


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.


[1]          The GlobalPlatform Card Specification, version 2.1, issued June 2001, obtainable from www.globalplatform.org

[2]          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

[3]          The Open Platform Protection Profile, Version 0.9 issued March 2001, obtainable from Global Platform (www.globalplatform.org)

[4]          Smart Card Integrated Circuit Protection Profile, PP9806, Version 1.0, September 1998

[5]          Smart Card Integrated Circuit with Embedded Software Protection Profile, PP9911, Version 2.0, June 1999

[6]          The Smart Card Security Users Group Smart Card Protection Profile, version 3.0 issued August 2001

[7]          The Secure Silicon Vendors Group Smartcard IC Platform Protection Profile, version 1.0, July 2001, BSI-PP-0002.

[8]         Go to the following web site for JavaCard™ documentation: www.javasoft.com

[9]          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

Architectural Layer/ TOE Security Function

SFR (Bold means that the SFR originates from OP3 – it may also be included in one of the other protection profiles. Italics means that the SFR is not included in OP3, but originates from one of the other protection profiles, or the CCL security target).

« = SSVG requirement W = SCSUG non IC requirement



OP API Access Security Function



CVM Handler Access Security Function




Security Domain Access Security Function



Secure Channel Security Function


Invocation by an Application



Invocation by Security Domain Users



Host/Entity Authentication



Message Encryption



Message Authentication and Integrity



Key and other Secret Data Receiving Services

FCS_COP.1+2, FCS_COP.1+10


Non-Secure Channel Security Function



Confirm Code Verification Security Function



Load File Verification Security Function



CVM Handling Security Function




Card Manager Access Security Function



State Transition Command Security Function



Delegated Management Security Function

FCS_COP.1+6, FCS_COP.1+7


Key Management Security Function


Key Generation Services



Key Distribution Services



Key Access Services



Key Destruction Services



CCMF Security Function



Security Management Security Function




Self Test Security Function



Rollback and Recovery Security Function




Supervisor Security Function



Firewall Security Function



Object Reuse Security Function



Exception Handling Security Function



Object Identity Security Function



Card Audit Security Function




Sensor Security Function



Bus Security Function



Memory Management Security Function



Input/output Security Function



CPU Security Function



Random Number Generator Security Function



Cryptographic Security Function

FCS_COP.1 (instantiated for each algorithm)



Coating Security Function