A User Centric Security Model for Tamper-Resistant Devices

3.5 Security and Operational Requirements of the UCOM
3.5.2 Cardholder's Requirements
A cardholder is an entity that uses a smart card to access authorised services. In the
UCOM, the control of a smart card is with its user. Therefore, cardholders have complete
control over the choice of applications on their smart cards. They will have the exibility
to change the installed applications on their smart cards. Furthermore, they could install
or delete any applications they are entitled to at their convenience. The framework will
provide the mechanism that ensures the secure control and the ubiquitous management of
applications on smart cards. A cardholder's requirements in UCOM are listed below:
CR1. Security: If a smart card is inherently insecure, or if it becomes vulnerable to new
threats, it can aect the security of applications installed on the card. We cannot
expect that each cardholder is technically capable of ensuring and managing the
security of the smart card; therefore, a cardholder would require an assurance that
the card platform will be secure and reliable even if it is in the possession of an
illiterate or malicious user.
CR2. Privacy: Applications installed on a smart card represent the identities of the
cardholder in dierent contexts. For example a college card, a health card and a
credit card represent a cardholder's identity as a student, a patient, and a consumer
respectively. These identities are in the form of applications that have some unique
characteristics (e.g. student ID, patient ID, and Primary Account Number: PAN)
to identify a particular user. Therefore, applications on a smart card can be treated
as the identities of the cardholder. In the ICOM, these identities may not have any
connections with each other. However, in the UCOM, any or all of these identities
could be on the same card, creating a privacy issue if one application becomes aware
of the existence of others on a smart card. Therefore, the identities on a particular
card should not have any links between them. For example, a college application
should not be able to nd out about a medical application(s) installed on the same
card.
CR3. Least Interaction (Seamless Framework): Most users do not understand the
technology behind a particular product (i.e. mobile phone applications). Therefore,
the framework should not be based on the assumption that an average user can
perform technically challenging tasks. The UCOM should be seamless and should
perform all necessary tasks by itself, and only involve the user when required.
CR4. Interoperability: The smart card user will not want to buy a separate smart card
for each application. Smart card suppliers should provide cards that support most
of the available functionalities and SPs should oer applications in many formats to
support as many dierent execution environments as possible.
72