The purpose of the GP is to provide a secure environment for loading, executing and deleting applications.

Because the applications may belong to different organisations, each has a secure representative onboard, referred to as the Issuer Security Domain (for the Card Administrator, who for the operational life of the card will be the Card Issuer) or as a Security Domain (shown here as an Application Provider Security Domain).

There are GP functions in support of these Security Domains, called the OPEN, and a means for the applications to invoke them, the OP API.

Also in support of the applications, and the OPEN, is the RTE (e.g. JavaCard <<point to RTE>>) which is accessible through the RTE API.

In support of the RTE is the Card OS and the IC.

I have mentioned that there may be many organisations involved, for example a bank (as Card Issuer and the Application Provider for various payment applications) and various retailers, each with their own loyalty application.  Indeed, as shown in this diagram, there are many roles.  Sometimes, many of these roles will be played by the same actor.  In other cases, many different actors will play the same role.

The principal user of GP is the Card Administrator, who owns the Issuer Security Domain and has ultimate control of the card.

Other off-card entities that are recognised by the card are referred to as Security Domain Users.  Each has its own Security Domain.  What they can do, in terms of card content management, however, depends on the privileges granted to their Security Domain by the Card Administrator.

Applications may also invoke GP.  Again, what they can do is governed by Application privilege.

The cardholder is also a user of the card.  They may be authenticated by GP, although, strictly speaking it is the application that invokes GP’s cardholder verification methods that is the user, rather than the cardholder per se.

There are also some commands, which do not require authentication. e.g. the GETDATA command.  For these commands, the card does not necessarily know who issued them, and there we need to contend also with the “unknown user”

Please appreciate that the Card Specification is full of optional functionality, shown here grouped into 37 different packages.  Choosing one package, however, may require the presence of others.  It may look rather complicated, but its purpose is to allow the card configuration to be tailored to suit the business requirements, and, as we shall see later, also the risk environment.  As the CC does not seem readily to cope with optional functionality, this real-life requirement, has always presented problems to GP.

Finally, it is useful to reflect on the history of the CSRS.

At the turn of the century, the smart card world become extremely enthusiastic about the CC as it promised, through the CCRA, “evaluated once – approve everywhere”.  Sadly this promise remains illusory, but over the next two years a variety of smart card protection profiles emerged.  We, at Visa, produced one for the precursor to GP – “Open Platform”.  It was innovative, and provided solutions to the problems of card configurations and evaluation by parts.

In 2002 Visa assigned the IPR in OP to GP.  It seemed natural to assign the IPR in OP3 as well, but the GP Board questioned the wisdom of producing yet another PP.

In May 2002, at ICCC3 in Ottawa, David Brewer, one of the authors of OP3 published the innovations behind the work he had been doing in Taiwan to produce a Security Target compliant with OP3 and all these other smart card PPs.  GP embraced those innovations as the way ahead and accordingly produced the CSRS, which we published in May.

The functions are represented by tables.  There are three types, blue, green and yellow.  Blue tables are access control tables.  They are expressed in terms of the usual parameters – users, subjects, objects, security attributes and operations – and have a yes/no outcome.  Formality is introduced by rigorously adhering to this format and using a standard way of referring to the various parameters. 

In addition, each table identifies the security preconditions and post conditions.  This is how we express the security dynamics

Here is the corresponding CC SFR taken from the SCSUG PP.  Note the differences in the generic and specific forms.

The relationship between all CSRS security features and the PP SFRs is given in a table in Appendix A to the CSRS.  The table also shows the threats and policies that those features counter.  Note that each CSRS security feature may address several SFRs.

The next type of security feature table addresses functions, such as APDU commands and API invocations.  Unlike access control tables, there are no users or subjects, as the access control decisions have already been made. 

Functions, such as these, can, however, fail.  For example, having decided that role X may load an application, there might not be enough memory to complete the operation.

Here are the SFRs that correspond to this table.  In OP3 the rules for function failure and success were closely coupled with those that directly concerned access control.  There aren’t really any CC SFRs that tease out this sort of function failure requirement, which have much to do with integrity and availability and little to do with authorization.

And here is the rest

We could spend a lot of time navigating this diagram, and in doing so you will really start to understand how the smart card works, and in particular the interactions between the various security features.

However, let me give just one example…

Let us imagine the the card is in a reader, is powered up, the Issuer Security Domain is the SELETED application but a Secure Channel Protocol session is not in progress.  Here are the parts of the architecture that we need to look at 

An APDU command (INSTALL [for INSTALL]) arrives at the card. It is validated and dispatched. 

As there is no SCP session, the command is dealt with by table A (unknown user) and is rejected.

So start again, this time sending the commands necessary to initiate a Secure Channel Protocol session.

Asserting that the initiation completes successfully, the post condition becomes known_user = CA (since the ISD is the SELECTED application)

Now we can issue the INSTALL [for INSTALL] command.

This time it is processed by Table B and results in a request accepted post condition which initiates the installation function itself.

Thus we see that the pre and post conditions capture the dynamics.

Just as a reminder then, there are three types of table, each instance of which is mapped to the corresponding SFRs, threats and policies in the smart card PPs

But in passing we noted that some functions, such as the actual load command that completed the operation I have just illustrated are not well handled by the CC.

There is quite a lot of interest in producing STs from the CSRS.

This ought to be straightforward as the CSRS architecture was itself derived from a ST, however here are some of the questions that need to be addressed.

The first is essential.

The next three address the possible objections that an evaluator might have in proving compliance of the ST with the various PPs.  It would not be useful to go through this every time a ST was evaluated so should the rules for generating STs from the CSRS be established and themselves evaluated, or otherwise agreed by the evaluation community?

Lastly perhaps the efficiency of evaluations could be enhanced still further by devising a set of security tests that demonstrate compliance with the CSRS – food for thought eh!

I have mentioned that the CSRS uses policies instead of assumptions.

From the perspective of the CC it is appropriate for the PP/ST to make assumptions, or more correctly speaking assertions, about the environment of the TOE.  From a system perspective, all such environmental assertions are in-scope, they are not assumptions, an organisation cannot assume that, in our case, these off-card requirements are met.  It must do something about them as a matter of policy.

So from a system perspective we have policies and not assumptions.

Here is an example – it reflects the type of “non deterministic” requirement that Dr. Nash spoke about.

Here is another.

This one, however, comprises a number of alternative policy statements.  You chose just one of these.

The choice determines what functionality packages are required.  The CSRS spells all of this out.

Knowing what packages are required determines the security requirements as each function table explains its package dependence.

So key to determining the card configuration is the choice of alternative policy statements.  How do we do this?  By …

Risk assessment.

There is a core package.  This defines the minimum security requirements for a GP card, implying that GP itself considers that some risks are unacceptable under any circumstances.  The acceptability of other risks may be determined by the actors involved.

Here is a list of the questions raised in the CSRS that those actors should ask.

As an example, suppose actor X detects some event which has to be fixed by actor Y.  Consider the acceptability of risk if actor Y is exposed but X is not.  X could be the cardholder who loses his card.  Y is the Card Issuer, who assumes liability for fraudulent activity once the loss of the card has been reported.  The onus is therefore on X to report the loss.

But suppose it is the other way round, i.e. Y could be the Application Provider and X is the Application Loader, who some how loads a virus infected application.

Ha ha you say let’s place some contractual penalty on X.  Now both actors are exposed, but it the time delay in taking the legal recourse acceptable or should there be on-card measures to allow Y to detect as well as X.

The CSRS explains this philosophy in some detail and reminds the reader to “bottom out the risk”, i.e.  consider the acceptability of the risk when the event happens, and not the likelihood of it happening.  (Remember how you felt on 9/11).

Of course, if neither actor is involved, no special action is required.

The CSRS also considers more complex cases.  Please download and read.  This analysis of risk is applicable to probably all business situations and not just those to do with smart cards.

The remarks that I have just made ought to suggest to you that the CSRS is about the security of a smart card system and not just the smart card itself.  And here we are talking about a business system, not just the technology, and therefore before we ever get started these are the sort of questions that we ought to be asking.

Once answered, the CSRS tells us what we need in place for operational risk management  and indeed for banking applications, what we need to satisfy the requirements for Basle II

This is operational risk management

From a standards perspective, this implies that we need a combination of the Common Criteria and 7799

The CC to give assurance in the card technology.

7799 to give assurance in operational risk management.

The CSRS …. (read slide)

It …

But perhaps the greatest contributing factor to this Track is …

Which …

THANK YOU