A User Centric Security Model for Tamper-Resistant Devices

6.6 Analysis of the Proposed Protocols
was at the time of evaluation. This does not mean that it will always be secure or that a
malicious user is not able to simulate the environment with a genuine signature key pair.
It only gives the assurance that the smart card is secure against attacks as evaluated by
the third party and stated in the issued certicate [56], and that it is a state-of-the-art
tamper-resistant device at the time of evaluation. Therefore, if the evaluation certicate
does not meet the SPs requirements or it out-dates the current attacker capability then the
SP should decline the application lease. As stated earlier, granting an application lease is
at the sole discretion of the SP, so if they are not satised with a smart card, they should
not lease the application to it.
6.6.1.6 Platform & Application User Separation Attack
In this attack, as discussed in section 6.2.3 and 5.5.2, a malicious user tries to install an
application that belongs to some other user on his smart card. Therefore, the identity of
the card owner and the leaseholder of the application are dierent.
Among the proposed protocols in this chapter, only the STCP SP and STCP ACA provide assurances
against this attack as they include the smart card owner's identity and ownership
proof (i.e. U i and signed message with a certicate) in the message. The ownership proof
comes from the signature generated using the smart card owner's signature key pair. This
signature and the certicate are associated with the smart card, providing a cryptographic
binding between the smart card and its current owner.
In the STCP SC , we intentionally omitted the inclusion of the user specic details in the
protocol. The rationale behind it is that in this protocol, the respective SP does not require
the user identication and the user wants to keep his or her privacy. This is necessary when
a user downloads applications that normally do not require user details.
6.6.1.7 Contractual Agreement
In the STCP ACA , the smart card generates and sends a contractual agreement to the SP.
Therefore, the smart card commits to the SP that it has downloaded the application but
this does not mean that the application is in the active state. The smart card will wait for
the SP to verify the contract message sent by the smart card and to check the hash value
of the downloaded application to correctly corresponds to the SP's application. Once the
SP veries these parameters, it generates the contractual agreement message to the smart
card that includes the validation message (VM) of the smart card (if online attestation
was requested by the SP) and/or hash of the downloaded application. The SP will proceed
150