A User Centric Security Model for Tamper-Resistant Devices

9.1 Introduction
9.1 Introduction
One of the main features of the UCOM is dynamic (wherever, whenever) acquisition of
applications by users. Therefore, the UCOM framework enables a user to have most if not
all of her applications on a single device. However, this also increases the potential damage
if the device is lost. To expedite the recovery process after theft or loss, customers should
be able to have their applications restored as quickly as possible to a new devices.
A backup mechanism enables a user to backup her smart card contents. In adverse circumstances,
such as losing her smart card, she could retrieve and restore the contents onto a
new smart card. Furthermore, a similar mechanism referred to as a migration mechanism
can also be used if a user decides to upgrade to a new feature-rich UCTD.
There are some subtle challenges to backup and migration mechanisms in the UCOM, especially
in the case of card-bound application leases (section 5.4.3) that restrict applications
to their host smart cards. Furthermore, there is a possibility that the remote location (e.g.
backup server) might not be tamper-proof and a malicious user could take advantage of it.
Therefore, it would be safe to assume that instead of transferring whole applications (i.e.
code and data), we should only transfer application download credentials. These credentials
can be considered as authorisation tokens that are issued by the respective SPs, so a
user could use them to acquire the application in future.
Finally, we discuss the last lifecycle stage of an application application deletion. As the
UCOM allows a user to install and delete any application they desire, this privilege might
lead to feature interaction problems discussed as SCR8 and SPR9 in section 3.5. Feature
interaction problems arise from environments where two applications share resources and
later at some point one of the applications is deleted. The second application's dependencies
on the rst application might not be resolved, which leads to a situation where
the second application tries to access the rst application, which no longer exists on the
platform. Such scenarios may lead to possible security breaches in the UCTD environment.
We analyse the application deletion process in prominent smart card frameworks: Java
Card, GlobalPlatform, and Multos, focusing on how they resolve deadlock conditions. A
deadlock condition arises when a user tries to delete an application `A' which is sharing resources
with an application `B'. Deleting the application `A' might aect the operations of
the application `B', eventually leading to a feature interaction problem. To avoid such scenarios,
we propose a framework that tries to resolve such deadlocks during the application
deletion process.
Structure of the Chapter: Section 9.2 begins with a discussion on smart card contents
backup and migration mechanisms, followed by the application deletion process in section
212