A User Centric Security Model for Tamper-Resistant Devices

9.4 Decommissioning Process
process only tries to nd dependent applications and point out to the user the list of applications
that cannot resolve their dependencies on App D . The application removal process
will then iterate through the applications for deletion and delete them one at a time.
In cases where the deletion request was initiated by the SP of the App D , and it requires
deletion of other applications that do not belong to the SP, the user will still be notied. If
the user opts for not deleting it, the SP can then proceed with blocking the App D . In the
block state, an application is not accessible to the user; however, dependent applications
can still access it through the application sharing mechanism.
As discussed before, the UCOM deletion process only provides dependent applications
with an opportunity to gracefully resolve their dependencies. If an application does not
have such a mechanism, the UCOM deletion process marks that application for deletion.
Furthermore, during the deletion process the App D 's resource manager that maintains the
access to the application via the smart card rewall is removed. Thus, if a dependent
application tries to access App D resources, the rewall mechanism will reject that request.
If the application does not gracefully proceed after the rewall rejects its request, the card
security manager can either block the application or mark it for deletion. Therefore, any
application that aects the reliability of the smart card platform will be removed or at
least blocked by the card security manager.
9.4 Decommissioning Process
The decommissioning process in the UCOM involves deletion of all applications from a
UCTD and removal of any user-specic data stored by the respective TEM or UCTD
platform managers (section 4.2). The decommissioning process is initiated by the user
in a manner similar to the ownership acquisition process (section 4.6.3). However, in the
decommissioning process the user requests a UCTD to delete all applications in a manner
similar to the one discussed in the previous section but this time the UCTD does not check
for dependencies. Once all applications are deleted, the card security manager will delete
the user-specic cryptographic keys (e.g. user signature key) and associated certicates.
It will then request the deletion of ownership credentials that the user has set during the
ownership acquisition process. After the decommissioning process is completed, the UCTD
reverts to the state it was in when the user acquired it from the card manufacturer (or
UCTD suppliers). In other words, it is a blank UCTD.
222