A User Centric Security Model for Tamper-Resistant Devices

7.3 UCTD Firewall
application. There are two ways the current state of individual applications might be
veried: both of the SPs can opt for a third party evaluation of their respective applications,
or they can issue a certicate to each other's application that contains the hash of the
application. In both of these cases, the certied state of the application is treated as a
trusted state by the other entity.
The state validation of individual applications is carried out by the Trusted Environment
& Execution Manager (TEM), requesting the application and issued certicates.
Consider the scenario of application sharing between App C and App S . When App C is
installed onto a smart card, the relevant TEM establishes a secure relationship (shared
key: K AppC −T EM) with the installed application. The TEM does not calculate the application
state validation message (i.e. hash of the application), unless it is authorised
to do so by the application itself, or by the application's SP. When an application authorises
the TEM to generate its hash value, it generates a message encrypted with the
shared symmetric key. The authorisation message generated by an application is referred
to as an Integrity Measurement Authorisation (IMA) message. The IMA sent by the
client application will be E AppC −T EM(App C ||App S ||RandomNumber AppS ). The contents
of the messages are the identity of the client and server application, along with a random
number generated by the server application. The state validation message would be
E AppS −T EM(App C ||App S ||RandomNumber AppS ||hash(App C )) that is encrypted with the
TEM and the server application's shared key as this message is intended for the server
application. The server application can match the hash calculated by the TEM with the
one in the client application's certicate that is issued either by a third party evaluator or
by the server application's SP. If they match, the server application can securely ascertain
that the state of the client application is secure. A similar process can be performed in the
opposite direction where a client application veries the state of the server application.
After applications authenticate and validate their states to each other, they generate a
cryptographic key that is referred to as the application binding key. This key is used in all
future communications between the applications.
7.3.3 Using Shareable Resources
A client application can request to use the server application's shareable resources if required
(subject to valid access permissions) as illustrated by gure 7.4.
The request message sent to the corresponding ARM consists of a ClientAID, an authenticator
(message encrypted with the application binding key), access permission, the
required resource and a random number to provide freshness [132]. By verifying the authenticator,
the ARM ascertains the origin of the message that is, the client application.
167