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.

3.5 <strong>Security</strong> and Operational Requirements of the UCOM<br />

3.4.6.3 Application Services Authentication Server (ASAS)<br />

An ASAS authenticates the valid lease of an application that the requesting card holds. In<br />

the UCOM, multiple smart cards of a single user may have an SP's application, depending<br />

on the particular SP's ALP. If the ALP allows multiple smart cards to have a valid lease<br />

of its applications, an ASAS is necessary to verify the validity of the lease to the smart<br />

card. Once a smart card is authenticated as holding the valid leased application, it can<br />

access services oered by the SP, subject to successful authentication by the user (user's<br />

application).<br />

The ASAS is already implemented in the ICOM, and is referred as a back-oce or transaction<br />

clearance system. Each industry has its unique way of implementing the ASAS and<br />

part of the design philosophy of the UCOM is that we do not require a modication (in<br />

most cases) to the existing architecture of the ASAS in the ICOM.<br />

3.4.7 Service Access Point (SAP)<br />

Any device that a cardholder can use to access services provided by an SP is called a<br />

Service Access Point (SAP). A SAP can be a mobile phone, a kiosk, a computer, or an<br />

access panel. The main function of all these devices is to connect with the SP through a<br />

smart card and provide services to the cardholder. We consider that SAPs do not have<br />

to be secure; there<strong>for</strong>e, during the course of this thesis SAPs will be treated as insecure<br />

terminals.<br />

3.5 <strong>Security</strong> and Operational Requirements of the UCOM<br />

The UCOM delegates control of the smart card to its user. This scenario introduces unique<br />

requirements that were not present in the ICOM.<br />

3.5.1 General Requirements<br />

In this section, we discuss the requirements that are not specic to a particular entity in<br />

the UCOM but are instead common to the overall architecture.<br />

GR1. Control: The UCOM should provide a mechanism(s) that enables cardholders to<br />

manage applications on their smart cards. It should also ensure that only the autho-<br />

70

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

Saved successfully!

Ooh no, something went wrong!