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.3 Runtime Protection Mechanism<br />

8.3.4 Application Compilation<br />

It might be considered adequate to modify the Java virtual machine specication <strong>for</strong> the<br />

smart card environment to provide an eective runtime protection mechanism; <strong>for</strong> example,<br />

reducing the number of opcodes and removing opcode zero from opcode list. However, we<br />

avoid it <strong>for</strong> the sake of simplicity. Instead we use the property les that include meta-data<br />

about the respective application. The property le is downloaded to the smart card as part<br />

of the application and veried by the respective TEM during the bytecode verication as<br />

shown in gure 8.1.<br />

A Java compiler will take a Java le and convert it to a (bytecode) class le. The class<br />

le not only has opcodes, but it also includes in<strong>for</strong>mation about various segments (e.g.<br />

methods, and classes) of an application that is necessary <strong>for</strong> the JCVM to execute the application.<br />

However, <strong>for</strong> our proposal we introduce a property le that includes additional<br />

in<strong>for</strong>mation about an application. If a JCVM knows how to process property les then it<br />

will proceed with them; otherwise, it will silently ignore them. In our proposal a property<br />

le is stored and used by the TEM during the execution of the associated application. In<br />

order to integrate the TEM into the runtime environment, the JCVM is required to be modied<br />

so it can communicate with the TEM in order to safeguard the execution environment.<br />

1 A p p l i c a t i o n I n f o {<br />

2 A p p l i c a t i o n _ I d e n t i f i e r A p p l i c a t i o n I d e n t i f i e r ;<br />

3 C l a s s I n f o r m a t i o n C l a s s I n f o [ class_count ] ; }<br />

4 C l a s s I n f o {<br />

5 C l a s s _ I d e n t i f i e r C l a s s I d e n t i f i e r ;<br />

6 MethodIn<strong>for</strong>mation MethodInfo [ method_count ] ; }<br />

7 MethodInfo {<br />

8 Method_Identifier M e t h o d I d e n t i f i e r ;<br />

9 MethodIntegrity HashValue ;<br />

10 ControlFlowGraph Graph [ jumps_count ] }<br />

Listing 8.1: Structure of the property le of a Java Card application.<br />

The property le contains security and reliability in<strong>for</strong>mation concerning an application<br />

that the runtime environment can utilise to execute an application. The structure of the<br />

property le is illustrated in listing 8.1, which includes in<strong>for</strong>mation regarding the control-<br />

ow graph, and integrity matrix (hash values of the non-mutable part of the individual<br />

methods in a class).<br />

The ApplicationInfo data structure includes the application identier (e.g. AID) and an<br />

array of classes that are part of the respective application. For each class in the application,<br />

we have a ClassInfo structure that contains the MethodIn<strong>for</strong>mation array that<br />

contains in<strong>for</strong>mation regarding all methods associated with the given class. Each method<br />

is represented by MethodInfo structure that includes the control-ow graphs that are gen-<br />

198

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

Saved successfully!

Ooh no, something went wrong!