A User Centric Security Model for Tamper-Resistant Devices

5.3 Multos Card Management Framework
a signature key pair and application code; the private key of the application provider along
with the application code is securely communicated to the application load unit generator.
The signature key is used to generate a cryptographically protected application load unit
(i.e. downloadable application). The application provider will also send its signature verication
key and application to the card issuer, which forwards it to the Multos Certication
Authority (M-CA). The application header is a data structure that contains information
regarding the respective application, which includes the application identity, hash of the
application code, and code and data size [159]. The M-CA can be either the card manufacturer,
or an authorised entity of the Multos consortium [29]. The role of the M-CA is to
issue an application load or delete certicate to the card issuer for the application. In addition,
the M-CA also provides the list of public keys for individual Multos cards that the
card issuer has issued to its customers. This list of public keys is stored by the application
load unit generator as the keys are used to encrypt individual applications. This transfer
of public keys is marked as user personalisation data in gure 5.2. The application load
unit generator will create individual application load units for individual smart cards, if
the load unit has to be encrypted. Finally the load unit will have a signed digest of the
application, using the application provider's signature key and if required the application
encrypted by the respective smart card's public key. The application load facility now
has the application load units and associated M-CA's issued certicates that it will use to
download the application to individual smart cards.
As it is apparent from gure 5.2 that application providers have to communicate their
application (in plaintext) and private key to the application load unit generator (i.e. card
issuer). Furthermore, the application management tasks (i.e. installation, deletion, and
updating etc.) have to be performed through the card issuer and/or M-CA. Unlike the
GlobalPlatform, Multos specications do not provide independent application management
architecture. To delete an application, the process is similar to the Multos application
installation except there is no need to generate the application load unit only an application
delete certicate that is similar to application load certicate is required from the
M-CA.
5.3.2 Support for Trusted Service Manager Architecture
To date we have not seen any ocial proposal on how to incorporate Multos into the
proposed TSM architecture for NFC mobile phones. However, in a centralised environment
a TSM can take the role of the M-CA and application load unit generator.
115