A User Centric Security Model for Tamper-Resistant Devices

6.6 Analysis of the Proposed Protocols
The CasperFDR tool evaluated the protocols and did not nd any feasible attack(s).
6.6.3 Revisiting the Requirements and Goals
In this section, we take the security goals and requirements stipulated in section 6.2.3 and
provide a comparison of the proposed protocols with the selected protocols 6.2.2.
As shown in the table 6.2, the STS protocol meets the rst 11 goals along with goal 15.
The remaining goals are not met by the STS because of the design architecture and the
deployment environment, which did not require these goals. Similarly, the AD protocol
does not meet goals 6, 10 and 1319. In the AD protocol, the user reveals her identity by
sending the user certicate as plaintext along with the no mutual key conrmation.
The most promising results were from the ASPeCT and JFK protocols that meet a large
set of goals. Both of these protocols can be easily modied to provide the trust assurance
(requiring additional signature). However, both of these protocols are vulnerable to partial
chosen key attacks, but in the table 7.3 we opt for the possibility that the JFK can be
modied to overcome this problem. The reason behind this is based on the entity that
takes the initiator's role. Therefore, if in the JFK we opt for the assumption that an SP
will always take the initiator's role then this goal is met by the JKF.
The T2LS protocol meets the trust assurance goal by default. However, because it is based
on the TLS protocol, which does not meet most of the requirements of the STCP, the T2LS
also does not meet them. A note in favour of the SCP81, MM, and SM protocols is that
they were designed with the assumption that an application provider has a prior trusted
relationship with the smart card issuer; thus, they implicitly trust the respective smart
card. This assumption, which is fundamentally incompatible with the UCOM, is why
these protocols fail to support a large number of the listed goals. Most of these protocols
to some extent have an architecture similar to the one with which a server generates the key
and then communicates that key to the client (i.e. read smart card). They do not provide
non-repudiation because they do not use signatures in the protocol run. Nevertheless, the
proposed STCP ACA protocol meets all the listed goals. Table 6.2 provides a comparison
between the listed protocols in section 6.2.2 with the proposed protocols under the required
goals (see section 6.2.3).
In table 6.2, we show that STCP SC does not meet the goal 17 beside the fact that SPs
in STCP SC does not require user identication. Therefore, a malicious user can install
an application that does not belong to him. On the other hand, if the SP does require
the user's identication during the application personalisation (after the application is
installed) then the personalisation process [10] should take into account the platform &
152