A User Centric Security Model for Tamper-Resistant Devices

8.1 Introduction
8.1 Introduction
After an application is installed on to a smart card, it relies on the Smart Card Runtime
Environment (SCRT) for secure and reliable execution. An SCRT provides the platform
that facilitates the application execution and it contains a library of Application Programming
Interfaces (APIs). These APIs provide a secure and reliable interface between the
installed applications and on-card services. An SCRT's responsibility is to: 1) handle
communication between applications and external entities, 2) provide a secure and reliable
program execution, 3) enforce execution isolation and access to memory locations,
and 4) provide an interface to access cryptographic algorithms.
Although they are clearly not the same, the distinction between a smart card operating
system and a runtime environment is often blurred. For example, Java Card is considered
as a platform that provides a runtime environment (i.e. JCRE, see gure 3.3); whereas,
Multos is a smart card operating system that also has a runtime environment (i.e. AAM,
see gure 3.2). In this chapter, we will refer to an SCRT that semantically encapsulates
both the JCRE and AAM. However, we will focus primarily on the JCRE.
An SCRT has to protect the platform and installed applications from malicious or illformed
applications. In the ICOM, such issues have limited impact because of the strict
controls on application installation [190, 194, 195]. This means that compatibility, security,
and reliability of an application with respect to an SCRT are evaluated before installing it.
Even if a smart card allows post-issuance installation of applications, centralised control
means that it is dicult to introduce a malicious application into a smart card, as the card
issuer will vet individual applications along with the associated application providers.
In the early days of smart card technology, an adversary could remove the smart card hardware
protection layer and access its various components [196]. However, the smart card
industry responded to this attack vector and implemented adequate protection, which
simply make such attacks more dicult to mount. On the other hand, it led to the materialisation
of the side-channel analysis that provided an avenue to attack the smart card
platform, especially the cryptographic algorithms [197]. Nevertheless, most of the modern
smart cards employ both hardware and software mechanisms to counter side-channel analysis.
During early 2000, fault attacks became the modus operandi of adversaries to subvert
the implemented security measures in the smart card industry. Since then the technology
has evolved to counter these threats to some extent. There has been a growing interest in
combining the software and fault injection [194, 198, 199] attacks to subvert the protection
mechanisms on a smart card, and such an attack vector is referred as combined attacks.
These attacks have signicance in the ICOM; nevertheless, the openness of the UCOM
exacerbates their eects. In this chapter, we analyse the attacks that target the SCRT and
provide counter-measures. During this chapter, we will constantly refer to the JCRE as
188