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.

4.4 <strong>Security</strong> Assurance and Validation Mechanism<br />

the individual smart cards that have the same validity as the associated PAC.<br />

4.4.2.2 Application Evaluation Phase.<br />

An SP would create an ST according to its security requirements and get it evaluated<br />

by the CLEF. If the SP's application is approved, the CB would issue a cryptographically<br />

signed Application Assurance Certicate (AAC) that would contain the EAL level achieved<br />

by the SP's application and the hash of its immutable application code.<br />

The structure of the AAC is similar to the PAC, except <strong>for</strong> few changes. Details of data<br />

elds included in the AAC are: the SP's ID, the evaluator's (CLEF) ID, reference to the<br />

evaluation target documents (PPs and ST), a digest of immutable application code, the<br />

SP's signature key, and the certicate's validity period.<br />

The certicate chain traversal and verication of the individual certicates in the chain<br />

are comparatively easy <strong>for</strong> the SPs as they have more computational power than a smart<br />

card and independent access to an external network (i.e. the internet). To per<strong>for</strong>m such<br />

tasks would no doubt be challenging <strong>for</strong> a smart card; there<strong>for</strong>e, it would request the SP<br />

to provide the certicate hierarchy that leads back either to the smart card manufacturer<br />

or the third party evaluator of the smart card (i.e. to an entity that is considered trusted<br />

by the smart card). In this way, the smart card can easily verify the certicate as the root<br />

of the certicate chain provided the SP's certicate chain has entities (certicate issuers)<br />

that the smart card trusts.<br />

4.4.3 Validation Phase<br />

This phase deals with the process that provides a dynamic and remote attestation of the<br />

current state of the smart card or applications. The attestation mechanism combines the<br />

self-test manager and attestation handler of the TEM to provide the state validation of<br />

the UCTD. For validation of applications the TEM attestation handler only generates the<br />

hash of the application in question, but the attestation mechanism <strong>for</strong> UCTD validation<br />

has two modes of operation: oine and online. In the oine mode, the validation process<br />

is independent of the card manufacturer and the smart card provides a security validation<br />

message to the requesting entity. In the online mode the card manufacturer provides the<br />

security validation message (i.e. a signed message from the card manufacturer) to the<br />

requesting entity.<br />

92

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

Saved successfully!

Ooh no, something went wrong!