A User Centric Security Model for Tamper-Resistant Devices

9.3 Application Deletion
tion of the SP. Therefore, after evaluating the operational and security capabilities of the
destination smart card, the SP can continue and lease its application. Furthermore, the
SP could rst block the lease of the previous application before leasing to the new smart
card. Nevertheless, there are certain concerns in the contents backup mechanism that are
related to the key that encrypts/decrypts the backup packages. The framework requires
the user to input a secret value that could be a long PIN, password, or passphrase that
can be exploited by an adversary. To avoid the use of weak user passwords it is recommended
the backup servers should take adequate measures by requiring users to choose
strong passwords. Furthermore, before a user can download authorisation tokens from
the backup server there should be some oine authorisation (e.g. activation of restoration
process on a backup server over the internet or telephone).
The migration mechanism is similar to the backup mechanism, except for one detail. It does
not require a backup server, so it avoids the need for user password-based cryptographic
keys. We consider that the backup & restoration manager of a given smart card should
support both the backup and migration mechanisms.
9.3 Application Deletion
In this section, we discuss the last stage in the lifecycle of an application: deletion of an
application.
9.3.1 Existing Framework
In the ICOM, post-issuance application installation or deletion is rare. Nevertheless, application
deletion is detailed in all of the major smart card platforms and operating systems.
In Multos, the application deletion process is the same as application loading depicted in
gure 5.2. The only dierences are that in the deletion process, there is no application
load unit generator, and an application provider or a card issuer requests the Multos
Certication Authority for the application deletion certicate instead of the application
load certicate [97]. The on-card deletion process simply deletes the application data and
code. As applications on a Multos card do not have interdependencies, the deletion process
does not need to be concerned about the feature interaction problem (section 3.5.3). In
the application sharing mechanism of the Multos cards (section 7.2.2), a client application
may still make a delegation request. However, because it is just an APDU message, the
delegation mechanism can return an error that should be handled by the client application.
217