A User Centric Security Model for Tamper-Resistant Devices

7.7 Analysis of the Proposed Protocols
7.7.3 CasperFDR Analysis of the Proposed Protocols
The intruder's capability modelled in the Casper scripts (appendices B.6, B.7, and B.8)
for the proposed protocol is shown below:
1. An intruder can masquerade as any entity in the network.
2. An intruder can read the messages transmitted by each entity in the network.
3. An intruder cannot inuence the internal process of an agent in the network.
The security specication for which the CasperFDR evaluates the network is shown below.
The listed specications are dened in the #Specication section of appendices B.6, B.7,
and B.8:
1. The protocol run is fresh and both applications/smart cards are alive.
2. The keys generated during the protocol run are known only to the authenticated
participants of the protocol and an adversary cannot retrieve the session keys.
3. Entities mutually authenticate each other and have mutual key assurance at the
conclusion of the protocol.
4. Long-term keys of communicating entities are not compromised.
The protocol description dened in the Casper scripts is a simplied representation of the
proposed protocols. The o-card agents like the SPs of client and server applications are
not modelled in the Casper script as they do not play an active role in the protocol run.
The CasperFDR tool evaluated the protocol and did not nd any attack(s).
7.7.4 Implementation Results and Performance Measurements
The overall architecture of the test-bed is the same as the architecture discussed in section
4.8.3, consisting of a laptop and two Java Cards (e.g. C1 and C2). We executed individual
protocol for 1000 iterations to get the performance measurements.
Our implementation model for the ABPL is based on three applets taking the roles of
the TEM, client, and server application on a Java Card (16bit smart card) that take
in total 8938 bytes. At the time of testing, we did not have access to an SCOS that
184