A User Centric Security Model for Tamper-Resistant Devices

5.2 GlobalPlatform Card Management Framework
5.2 GlobalPlatform Card Management Framework
In this section we discuss the GlobalPlatform card management framework along with how
it supports TSM-based card management.
5.2.1 Architecture Overview
The GlobalPlatform card security requirement specication [1], species nine entities that
perform various tasks in the overall card management architecture. The overall architecture
is depicted in gure 5.1, which is a simplistic representation of the architecture described
in [1]. The gure is then explained.
Card Issued
Cardholder
Smart Card
Provide Cards,
Platform data and keys
Application Load/Delete
Confirmation
Application
Loader
Request
Platform
Code
Card Issuer
SCOS Developer
Set Policies
Platform Code
Provide Enabled Cards
Card
Administrator
Application Installation
Deletion Authority
Card Enabler
Provide Security
Domain Keys and data
Application
Load/Delete
Confirmation
Application
Provider
Request Offcard
Application Code Verification
Application, Keys, and
Personalisation Data
Application
Load Permission
Code Verification Report
Figure 5.1: GlobalPlatform card management architecture [1]
Controlling
Authority
Request Application
Load
Verification
Authority
The shaded entities in gure 5.1 have dierent titles and roles, but together they form
the card issuer as dened in this thesis. The term card issuer as dened by GlobalPlatform
in [1] is restrictive, so that they only have the responsibility to acquire the smart
cards, set security policy, and issue them to individual cardholders. The card administrator
then manages the cards once they are issued to individual customers. If application
providers want to issue their applications, they rst have to get the applications veried
by the verication authority. The verication authority performs an o-card application
code verication to ascertain whether the given code conforms to the security policy set by
the card issuer. Once the verication is performed, the application provider requests the
controlling authority to give permission to load the application. The controlling authority
checks the verication authority's verication and issues the permission to load the application.
Now, if the application is going to be loaded at the pre-issuance stage then the
domain keys and data will be sent to the card issuer [157] through the card enabler. Otherwise,
the domain keys and data will be sent to the application loader. In gure 5.1, we
112