A User Centric Security Model for Tamper-Resistant Devices

7.2 Application Sharing Mechanism
FiR-2 Application Authentication: In both Java Card and Multos, applications rely on
the AID to locate, request and access shareable resources/data. The AID is a 516
byte identier that consists of two components: a Registered Identier (RID) and
a Proprietary Application Identier Extension (PIX). The RID is 5 bytes long and
compulsory; on the other hand the PIX can be 09 bytes long and it is optional. If
you are developing an application that will be used either nationally or internationally,
you need to get a RID from designated authorities (i.e. national standardisation
authorities). AIDs are issued by a designated authority but there is no enforcement
mechanism that prevents an adversary from masquerading as an application on a
smart card. In the ICOM, this situation does not arise because application installation
is only authorised by the card issuer and even this is to a restricted group of
trusted application providers. However, in the UCTD environment such a measure
is dicult.
FiR-3 Application State Validation: An application App A might be modied either intentionally
or accidentally. This might have a malign aect on applications that
share resources with, or use the resources of App A . Therefore, before establishing
sharing it would be benecial to ascertain the current state of App A . In addition,
the rewall should also notify the server application if the client application is modied
(i.e. if there have been application updates), so if the client application wants,
it can revoke the sharing, and vice versa.
FiR-4 Access Control: The rewall should facilitate a exible mechanism that enables a
server application to implement a hierarchical access-level rewall. In such a rewall,
a server application assigns shareable resources according to dierent access levels.
In addition, it can also revoke, upgrade, or demote the existing privileges of a client
application.
FiR-5 Application Binding: Two applications that share each other's resources should
be able to bind the sharing instance (cryptographic binding) in order to provide
authentication, condentiality and reliability to all future communication.
FiR-6 Application-Platform Communication. This requirement deals with bi-directional
communication between an application and a smart card platform and it is subdivided
into two sections as listed below.
(a) Application to Platform Communication: Platforms make their services available
to applications either through Entry Point Objects [28] or standard APIs
[29]. In both cases, applications may have access to more platform services
than required. That would not be desirable in the UCTD [10]. In the UCTD,
applications are only given access to those platform services that are authorised
by their SPs. The rewall ensures that an application cannot have access
to any other services from the platform for which it is not authorised. This
162