
is secure (Grant, 2001) like, for instance, when a
biometric unlocks a private key on a smart card
(Castle, 2001). A clear advantage of this last
application scenario is that the owner retains always
the control of his biometric template. Furthermore,
the storage and matching of the master template can
be made inside this tamperproof device, providing a
more secure application environment – the master
biometric template never leaves the protected user
token.
3 A PIC HOLDER
AUTHENTICATION MODEL
As we have already highlighted, particularly in
mission-critical PIC systems, that is crucial to have
mechanisms for differentiating between the
authorised card user and someone else that has
obtained this identification and is making
illegitimate use of it – this can be achieved, most of
the times, with the right owner permission or
delegation. In other hand, it is equally important to
give emphasis to separate authorization trust level
according with organization security policies. In this
last case, one the most important elements is, for
example, the user access provenience or platform.
Many times, common sense puts the access
provenience problematic in the indoor versus
outdoor scenario. However, it is possible to have,
different trust level inside the institution walls. In
any case, must be always a central application
system to analyse and define the trust level
according with pre-defined security policies, i.e. the
type of second authentication factor demanded to the
end user.
In a trusted or controlled access zone, it is easy
to detect this PIC illegitimate use, however the same
could not be guaranteed, for instance, in a remote
access. What we want to obtain is the
implementation of a recognition model to strongly
enforce identity of authorised user from distrusted
access scenarios like a physically uncontrolled
installation and, at the same time, continuing to
allow the usage of single PIN/card pair in trusted
access areas (although the strongest control can be
practicable anywhere if desirable).
In summary, the proposed model imposes
different levels of user identification proof,
depending on security policies like the access origin,
trusted versus uncontrolled. It must guarantee that
the authorised person is at the remote access, not
being limited to prove that he provided a correct
authentication credentials. This is where the
biometrics can offer an effective contribution to the
problem (Hachez, 2001) (Alliance, 2002), by
replacing the pair smart card/PIN by the
authentication set smart card-biometry-PIN (“what
you have”-“what you are”-“what you know”).
3.1 Model Architecture
The first important aspect to emphasize is related
with the fact that is always the application server
that analyses and defines the trust level in every
access, i.e. the server forces, or not, the biometric
factor. When a user tries to access to the central
application, the server generates an access pre-ticket
that is sent to the client on-card application (the
javacard applet). This ticket includes an internal
timestamp element to prevent the capture and reply
attacks, a trust flag that defines the necessity of
biometric matching mechanism and the challenge-
response message to authentication purposes (Figure
2).
The smart card PIN that protects the PKC private
key sets, results from the processing of input
parameters owned by distinct intervenient elements
(user and server) and from a securely protected on-
card application stored at issue time. In other hand,
making use of an on-card Bio-API (like the Precise
BioMatch (Ola, 2003)), the user master template(s)
on the smart card is kept protected and totally
inaccessible. It is not possible to retrieve, in any
circumstances, a previously stored user template. In
operation mode, the card hosted client application
just has available a BioAPI “verify” function, that
accepts as input arguments the live template and the
Id of master template to make the matching. If the
match fails more that N consecutive times, the
respective master template container is locked.
The NIST/Biometric Consortium presented
recently a Java Card Biometric API (NIST, 2002). It
is a high level and biometric neutral on-card API
that supports, among other characteristics, secure
template Match-on-Card with resource to Java Card
smart cards. As referred, in this way the sensitive
user master template never leaves the secure
tamperproof token, with evident risk of capture and
misuse. Considering this, we are currently exploring
these new functionalities, in the second development
phase, including the migration of file-oriented crypto
smart cards to java cards technology and the
development of applications in Java language
(Microsystems, 2001), named cardlets, that are
stored and executed inside smart card environment.
This way, the presented model is very simplified,
reducing the risk attack to the physical layer.
Returning to the model architecture (Figure 2),
the second core element is the bypass to the
matching process dependent on the kind of the trust
policy included in the issued server pre-ticket. As
E-SERVICES IN MISSION-CRITICAL ORGANIZATIONS: IDENTIFICATION ENFORCEMENT
393