A User Centric Security Model for Tamper-Resistant Devices

10.1 Summary and Conclusions
with other applications (if required), the next lifecycle stage is the application execution.
The smart card runtime environment provides a secure and reliable platform for the executing
applications. From an adversary's point of view, attacking an application while it
is executing might yield desirable results, such as skipping any security checks (e.g. PIN
verication). To achieve this, the runtime environment is subjected to dierent types of
attacks, including fault injections. Most of the attacks proposed in the literature target an
open smart card on which an adversary can install his application, which is dicult in the
traditional ICOM framework. However, the open and dynamic nature of the UCOM allows
such a facility. This opens up the UCOM proposal to attacks that are specically designed
to target the reliable and safe execution of an application. We described the architecture
of the Java Card runtime environment, which was followed by a discussion on how an
adversary can aect the execution of an application. To harden the runtime environment
from adversarial perturbations, we proposed protection mechanisms. We proposed that the
TEM should take a vital role in providing dynamic protection by getting involved during
the execution of an application. These mechanisms were then analysed for their latency
and performance measurements. This discussion can be considered as a survey of the vulnerabilities
of the smart card runtime environment that will have an adverse eect on the
UCOM proposal, along with the limitations of the proposed protection mechanisms. We
articulated that any protection mechanism built on top of the runtime environment would
inadvertently introduce a performance penalty. We concluded from this survey that at the
time when the Java Card virtual machine was designed, the focus was on reliability and
performance. Their design did not take into account the fault injection and combined attacks.
We recommend that a bottom-up approach should be taken rather than putting
extra layers on top of the runtime environment, redesigning it might be a better option.
Finally, we discussed the last lifecycle state of a smart card and an application in the
UCOM framework. A user might lose and want to recover contents onto her new smart
card, or want to upgrade to a feature-rich smart card. We proposed contents backup
and migration mechanisms that support both of these scenarios without compromising the
SP's security requirements. Furthermore, we detailed the application deletion mechanism
deployed in both Java Card and Multos, illustrating that they may both be unsuitable
for the UCOM architecture. The main issue was that if application dependencies are not
resolvable, the application will not be deleted. To mitigate this, we proposed a cascade
deletion process that supports the deletion of dependent application, if authorised by the
user. This discussion completed the lifecycle for both a smart card and an application,
supporting a dynamic and open framework that allows a user to have the choice to install
or delete applications from their smart cards.
228