OpenCard Framework 1.2 Programmer's Guide - OpenSCDP

Working with credentials
Apart from simply improving the readability of applications, symbolic path names
imply an additional redirection when referencing files in the card. This redirection
can be used by card issuers to their advantage by letting them allocate ISO-based
file IDs independently of the application logical file structure. The net benefit to
application programmers is that the application becomes more portable by being
independent of the details of file reference usage.
At the start of a smart-card aware application, the card-external application and
the card-resident application usually engage in a procedure to establish a trusted
relationship prior to exchanging any sensitive information. This procedure may
involve one or more of the following measures:
1. The card-external application authenticates itself to the card-resident
application. In smart card parlance, this is called External Authentication.
2. The card-resident application authenticates itself to the card-external
application. In smart card parlance, this is called Internal Authentication.
3. The cardholder authenticates him or herself to the card. In smart card parlance,
this is called Cardholder Verification (CHV).
Steps 1 and 2 combined are sometimes called mutual authentication.
Mutual authentication typically relies on a challenge-response protocol involving
the computation of a response to a challenge using some cryptographic keys
shared between challenger and responder. Cardholder verification typically relies
on the cardholder proving his identity by revealing a shared secret (such as a
password or PIN code) or by presenting a biometric characteristic such as a finger
print or retina pattern scan. The card-resident application usually occupies a
directory (DF) and all the files underneath it. 14
Accordingly, granting access to an application can be equated with granting access
to a directory. Access conditions to files in the file system of a smart card are
typically defined during layout specification (see also “Developing applications
using OpenCard Framework” on page 2.) 15 To abstract from file-system oriented
cards, we call this a security domain. The access conditions for internal
authentication rely on cryptographic key(s) stored in the card as part of the
card-resident application, while the access condition for external authentication
relies on cryptographic key(s) provided by the card-external application. For access
conditions involving CHV, see “Performing cardholder verification” on page 39.
The cryptographic algorithms used in the computations of access conditions can
vary between different types of smart cards. Accordingly, in situations where a
card-external application has to interact with card-resident applications protected
via different cryptographic mechanisms, the card-external application must be able
to provide cryptographic keys for all these mechanisms.
Now what does this all mean to application programmers? It means that they must
have a way to make available in their (card-external) application proper credentials
(most often cryptographic keys or certificates) that fit the access conditions of the
files which the given application is supposed to interact with.
14. In the case of JAVACARDs, the model will be somewhat different, but the essence of what is said here remains valid.
15. This may be different in the case of emerging multi-function smart cards whose operating system allows for the post-issuance
deployment of applications.
Chapter 5. Advanced programming with OCF 37