|
|
DEALING WITH SMART CARDS AS EVALUATED SYSTEMS
David Brewer |
Marc Kekicheff |
Gamma Secure Systems Limited
Diamond House, 149 Frimley Rd
Camberley, Surrey GU15 2PS, UK |
Global Platform Inc
900 Metro Center Boulevard
Foster City, CA 94404, USA |
* PUBLISHED AT THE
4rd INTERNATIONAL COMMON CRITERIA CONFERENCE, 8-9 SEPTEMBER 2003,
STOCKHOLM,
SWEDEN © 2003 GAMMA & GLOBALPLATFORM. 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 GLOBALPLATFORM. |
 |
Following a brief introduction, I will explain what the CSRS is
and consider its relationship to the CC through SFRs and STs. I will
then address the main topic of this presentation - “dealing with the
environment” and “system certification”. I then then summarise our
contribution to this track. |
Note that the CSRS and other GlobalPlatform specifications are
available free-of-charge from this website. |
 |
 |
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. |
So what is it? |
 |
 |
Well simply it is a comprehensive semi-formal specification for
GP, the RTE, OS and the IC. Naturally , the CSRS complies with
the Card Specification, but it also addresses every requirement
specified in the SCSUG, SSVG and JCS PPs. It is not a PP, but it
closely follows the structure of one. The assets are enumerated in
considerable detail. The threats are borrowed from the SCSUG and
augmented to cover specific GP requirements and the other PPs. There
are no objectives or assumptions, just policies – more about this
later. The CSRS covers all possible card configurations, and is
considerably more comprehensive than OP3And finally, I should remark
that the semiformal specification of the required security
functionality allows not only the detail to to captured but also the
dynamics. |
So lets look at it. |
 |
 |
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. |
 |
The third type are also functions, which ought to work (unless
there is a programming exception or power failure – which are dealt
with by other tables). These have only one outcome. Note the
corresponding SFR. |
 |
The security features are grouped in accordance with this diagram,
which is closely related to the architecture proposed by Brewer et al
at ICCC3. We started with that model and changed it quite dramatically
at times, but eventually finished with really just a few minor
amendments. The real value of our work lies in the detail. |
 |
Here’s some of it. |
 |
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. |
 |
 |
Let me know say something briefly about STs |
 |
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! |
Let’s move on now to dealing with the environment. |
 |
 |
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 |
|
|
|