06.11.2014 Views

A User Centric Security Model for Tamper-Resistant Devices

A User Centric Security Model for Tamper-Resistant Devices

A User Centric Security Model for Tamper-Resistant Devices

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

8.5 Summary<br />

representation; the abstract virtual machine takes the mnenomic bytecode representation<br />

of an application and searches <strong>for</strong> push, pop, and jump (e.g. method invokes) opcodes.<br />

Subsequently, we calculated the number of extra instructions required to be executed in<br />

order to implement the counter-measures discussed in previous sections.<br />

Table 8.2: Per<strong>for</strong>mance measurement (percentage increase in computational cost)<br />

Selected Applications Serial runtime<br />

security manager<br />

Parallel runtime<br />

security manager<br />

Wallet 29.43% 22.67%<br />

Java Purse 30.30% 25.82%<br />

Oine Attestation 17.64% 12.93%<br />

STCP SP 38.48% 33.23%<br />

To compute the per<strong>for</strong>mance overhead, we counted the number of instructions an application<br />

has and how long the application takes to execute on our test Java Cards (e.g. C1 and<br />

C3). After this measurement, we have associated costs based on additional instructions<br />

executed <strong>for</strong> each JCVM instruction and calculated as an (approximate) increase in the<br />

percentage of computational overhead and listed in table 8.2. Furthermore, to measure the<br />

cost of the hash generation we used the hash generation per<strong>for</strong>mance measurements <strong>for</strong><br />

the test Java Cards illustrated in gure 6.2.<br />

For each application, the counter-measures have dierent computational overhead value<br />

because they depend upon how many times certain instructions that invoke the countermeasures<br />

are executed. There<strong>for</strong>e, the computational overhead measurements in table 8.2<br />

can only give us a measure of how the per<strong>for</strong>mance is aected in individual cases - without<br />

generalising <strong>for</strong> other applications.<br />

8.5 Summary<br />

In this chapter we discussed the smart card runtime environment by taking the Java<br />

Card as a running example. The JCRE was described with its dierent data structures<br />

that it uses during the execution of an application. Subsequently, we discussed various<br />

attacks that target the smart card runtime environment and most of these attacks based<br />

on perturbation of the values stored by the runtime environment. These perturbations<br />

are called fault injection, which was dened and mapped to an adversary's capability in<br />

this chapter. Based on these recent attacks on the smart card runtime environment, we<br />

proposed an architecture that includes the provision of a runtime security manager. We also<br />

proposed various counter-measures and provided the computational cost imposed by these<br />

counter-measures. No doubt, counter-measures that do not change the core architecture<br />

the Java virtual machine, will almost always incur extra computational cost. There<strong>for</strong>e, we<br />

209

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!