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 />

erated <strong>for</strong> each method. In the control-ow graphs, child nodes represent jumps to other<br />

methods whether they are from the same application or from a dierent application. In a<br />

way, combining the method graphs of all classes can give the complete control-ow graph<br />

of the respective application. In addition to the control-ow graph, a MethodInfo also<br />

contains the hash value (of non-mutable code) of the respective method. This hash value<br />

can be generated at the compile time and added to the property le, or at the time of the<br />

application installation: the TEM calculates the hash value and stores it in the property<br />

le.<br />

8.3.5 Execution Environment<br />

The runtime environment of a UCTD plat<strong>for</strong>m is adequately modied to support the<br />

inclusion of the TEM (i.e. runtime security manager) that is shown in gure 8.3. At the<br />

time of application installation, the application bytecode is stored in the respective SP's<br />

domain along with the associated property le. The property le is sealed 1 by the TEM<br />

so that neither the application nor an o-card entity (e.g. an SP or/and adversary) can<br />

modify it. At the time of execution, the TEM will retrieve the le, verify the integrity of<br />

the le, and then decrypt it. If an SP wants to update its application on a UCTD then<br />

it will proceed with the update command 2 that will notify the TEM of the update. At<br />

the completion of the update, the TEM will verify the application security certicate (if<br />

available), and update the property le.<br />

8.3.6 Runtime <strong>Security</strong> Manager<br />

The purpose of the runtime security manager is to en<strong>for</strong>ce the security counter-measures<br />

(section 8.3.7) dened by the respective plat<strong>for</strong>m. To en<strong>for</strong>ce the security counter-measures,<br />

the runtime security manager has the access to the heap area (e.g. method area, Java stacks)<br />

and it can be implemented as either a serial or a parallel mode.<br />

A serial runtime security manager will rely on the execution engine of the JCVM (gure<br />

8.3) to per<strong>for</strong>m the required tasks. This means that when an execution engine encounters<br />

instructions that require an en<strong>for</strong>cement of the security policy, it will invoke the runtime<br />

security manager that will then per<strong>for</strong>m the checks. If successful the execution engine<br />

continues with execution, otherwise, it will terminate. A parallel runtime security manager<br />

will have its own dedicated hardware (i.e. processor) support that enables it to per<strong>for</strong>m<br />

1 Sealed: The data is encrypted by the TEM storage key. The storage key is a symmetric key to encrypt<br />

the sensitive data like property le so applications cannot change them<br />

2 Update Command: We do not propose any update command in this thesis but similar commands are<br />

dened as part of the GlobalPlat<strong>for</strong>m card specication. The update command enables an authorise entity<br />

(e.g. SP) to modify an application.<br />

199

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

Saved successfully!

Ooh no, something went wrong!