A User Centric Security Model for Tamper-Resistant Devices

6.6 Analysis of the Proposed Protocols
Communicating entities in the STCPs share signed messages with each other that include
the session information, thus providing mutual non-repudiation (SOG-11).
6.6.1.2 Trust Assurance (Trustworthiness)
One of the requirements was to establish a trusted channel between a smart card and
an SP. It is apparent that the required and proposed trusted channel is unidirectional in
relation to the trust assurance and validation. Only smart cards provide the assurance that
their current state is secure and trustworthy to SPs, not the other way around. The reason
behind this is the deployment environment of the UCTD where smart cards are considered
inherently untrustworthy, SPs are not. In the UCOM, a UCTD assumes that an SP can
be malicious but it will result in the lease of a malicious application(s). Therefore, security
and reliability analysis (e.g. bytecode verication [128, 161]) of the downloaded application
and not of the SP which supplied it is adequate to protect the UCTD. Furthermore, an
adequate protection mechanism implemented by the UCTD runtime environment avoids
malicious runtime activities (discussed in chapter 8)
Establishing a trusted channel between a smart card and an SP is based on the security
and trustworthiness of the SC (section 4.4). The trust in the established protocol session
comes from the assurance that the smart card complies with the evaluated state, which is
certied to be secure and trustworthy by a third party evaluation. The respective SP has
implicit or explicit trust in the third party evaluation.
6.6.1.3 Denial-of-Service Protection
The aim of DoS protection is to provide a level of assurance that the proposed protocols
cannot be used to mount a DoS attack against an SP. This is achieved by a) adding a
session cookie to the protocol messages that serve as the session identier, which includes
the smart card's IP address, and b) by not requiring the SP to perform any public key
operations unless it receives user or platform authentication.
The session cookie is generated by the SP and it is the smart card's responsibility to include
the cookie in every message. On receiving a message from a smart card, the SP veries the
session cookie and if it belongs to an active session, then it can ascertain that the message
came from a genuine host and not from an entity that is trying to mount a DoS attack.
The second feature requires that the smart card has to provide a signed message (with
either the user- or platform-key) before the SP has to perform any heavy computations.
148