Application-Binding Protocol in the User Centric ... - Semantic Scholar

Application-Binding Protocol in the User Centric Smart Card Ownership Model Raja Naeem Akram, Konstantinos Markantonakis, and Keith Mayes

Information Security Group Smart card Centre, Royal Holloway, University of London Egham, Surrey, United Kingdom {R.N.Akram, K.Markantonakis, Keith.Mayes}@rhul.ac.uk

The control of the application choice is delegated to the smart card users in the User Centric Smart Card Ownership Model (UCOM). There is no centralised authority that controls the card environment, and it is dicult to have implicit trust on applications installed on a smart card. The application sharing mechanism in smart cards facilitates corroborative and interrelated applications to co-exist and augment each other's functionality. The already established application sharing mechanisms (e.g. in Java Card and Multos) do not fully satisfy the security requirements of the UCOM that require a security framework that provides runtime authentication, and verication of an application. Such a framework is the focus of this paper. To support the framework, we propose a protocol that is veried using CasperFDR. In addition, we implemented the protocol and provide a performance comparison with existing protocols. Abstract.

1

Introduction

On a multi-application smart card, the application sharing mechanism achieves optimised memory usage, data and service sharing between applications [20]. A major concern in such a mechanism is the unauthorised inter-application communication. The framework that ensures that the application sharing is secure and reliable even in adverse conditions (i.e. malicious application, developer's mistake, or design oversight) is referred as a smart card rewall [36]. In this paper, the term rewall or smart card rewall is used interchangeably. The predominant business model in the smart card based service industry (e.g. banking, transport, and Telecom, etc.) is referred as the Issuer Centric Smart Card Ownership Model (ICOM) [13] and in this model card issuers retain the control of smart cards. Applications installed on an ICOM based smart card requires prior authorisation from the respective card issuer. This establishes an implicit trust relationship between installed applications as they are authorised/trusted by the card issuer. Furthermore, card issuers ensure that their smart card platform, and installed applications are secure, reliable, and trustworthy. Traditionally, card issuers have a business agreement with an application provider before they sanction the application installation. This agreement

dictates the behaviour of an application and sanctioned actions that it may perform. Such an assumption is dicult to conclude in the User Centric Smart Card Ownership Model (UCOM) [14]. In the UCOM, cardholders have the choice to install, or/and delete any application from their smart cards for which they are entitled [13]. The entitlement to install an application is attained once a customer is registered with a Service Provider (SP). An SP is an organisation that develops a smart card application(s) to assist in their service architecture (i.e. bankcards in banking, and SIM cards in mobile telecom sector, etc.) and issues it to their customers. Customers can then download the application after their smart cards satisfy the Application Lease Policy (ALP) of the SP, and utilise it to access sanctioned services [11]. The ALP stipulates the minimum set of security and operational requirements that a smart card has to satisfy before the SP lease its application(s). Therefore, if an SP leases its application then it has ascertained a certain level of trustworthiness of the host platform. Furthermore, it does not imply that the SP also trusts other applications installed on the same smart card. Firewall mechanisms are well-dened [1, 8, 17, 22] and studied [15, 18, 29, 37] in the ICOM. However, the ICOM based rewalls do not satisfy the criteria for the UCOM [14]. This paper illustrates the issue of gaining assurance and validation between communicating applications that are not satised (dynamically at runtime) by the ICOM based rewall mechanisms. The runtime assurance and validation of communicating applications, and subsequent generation of a cryptographic key between them is termed as application-binding. The open and dynamic nature of the UCOM requires that application sharing should be allowed only after participating applications verify, and validate current-state to be secure, and authenticate each other's identity/credentials. The protocol that achieves these requirements is referred as Application-Binding Protocol (ABP). In section two, a short introduction to traditional smart card rewall mechanisms is provided. The discussion is then extended to the UCOM framework. Section three emphasises on the threat model, and requirements of the ABP; ending the section with a description of the proposed protocol. Protocol analysis is provided in section four that includes model checking (using CasperFDR), analytical analysis, and practical implementation results. Section ve provides the concluding remarks along with future research directions.

2

Application Sharing Mechanism

In this section, we open the discussion with a short description of the existing rewall mechanisms. Next, we describe the UCOM and its rewall mechanism together with the UCOM card architecture.

2.1

Smart Card Firewall Mechanism

The rewall mechanism prohibits any cross application communication; unless sanctioned by the communicating applications. As depicted in gure 1, appli-

cation

A is authorised to access the resources shared by application B, where C cannot access application B.

depicted application

In subsequent sections, we will disFirewall

Application A

rewall mechanisms from a large set of smart card platforms. The reason

Platform Runtime Environment

among the most deployed in the smart two contrasting approaches of smart card rewall implementation. We will

Application C

Firewall

for this is: 1) these two frameworks are card industry and 2) they illustrate

Application B

Firewall

X

cuss the Java Card, and the Multos

A Generic Application Sharing Mechanism Fig. 1.

not discuss the GlobalPlatform specication [7] in this paper as GlobalPlatform Card Security Requirement Specication [4, see section 5.9.2] states that the GlobalPlatform relies on the underlying platform's (e.g. Java Card, and Multos) implementation of the rewall mechanism.

Java Card.

In Java Card, cross application communication is achieved by the

Shareable Interface Objects (SIO), and communication between applications and platform is controlled by the Java Card Runtime Environment (JCRE) Entry Point Objects [19], as shown in gure 2. The Entry Point Objects are instances of Java Card APIs used by applications to access platform services. These objects provide a secure way for applications to execute privileged commands.

Context A

Context B

Package A

SIO

Package B

Applet A1

Applet B1

Applet A2

Applet B2 Java Card Firewall

.

Java Card Runtime Environment (JCRE) Framework Classes (APIs)

JCRE Entry Point Objects System Context

System Classes Java Card Virtual Machine (JCVM)

Native Methods

Smart Card Hardware Fig. 2.

Java Card Firewall Architecture

The SIO enables an application to share its data and resources (functionality) with other authorised applications. To use the SIO functionality a server application (Package B in gure 2) should implement the shareable interface. The data and functionality dened in the shareable interface then becomes available to the client application (Package A in gure 2). Each application on a smart card has

an Application Identier (AID) [5] that in theory is unique to it across all the smart cards on which it is installed. In Java Card, a client application invokes the

JCSystem.getAppletShareableInterface (Server AID, parameter)

to

request sharing with the server application. The client application needs to specify the AID of the respective server application and a parameter (that can be an authorisation token encrypted with a pre-shared key) to the rewall. The rewall then asks the server application whether or not it will allow the sharing request. This framework is t for the purpose in the ICOM; however, in an open card scenario [41], a malicious user can masquerade the AID of a client application and replay the application sharing request message (section 3.2).

Multos.

The rewall mechanism on Multos cards is implemented with the as-

sumption that the applications installed on them have prior authorisation from a centralised authority (i.e. the card issuer or/and Multos Certication Authority) [9]. The security of the rewall mechanism in the Multos is actually managed by the o-card agreements between dierent application providers. The rewall in Multos is based on the concept of Delegation. In the delegation mechanism, the client application is called the delegator and the server application is called the delegate. The delegation process is described as below.

A creates an Application Protocol Data Unit (APDU) [34] in A and B along with the request. 2. Application A initiates the delegate command, requesting Multos operating system to invoke application B, which then reads and processes the APDU. 3. On completion; application B generates an APDU in the public memory. 1. Application

the public memory that has the AIDs of

4. The Multos operating system switches back to the execution of the application

2.2

A, which retrieves the results of the request from the public memory.

User Centric Smart Card Firewall

The rewall mechanism in the UCOM assumes that the smart card may be under the control of a malicious user, or/and there might be malicious applications on it. However, this does not imply that the underlying card platform is either compromised or malicious. We assume that card platform is not malicious; its trustworthy and has necessary functionality to provide tangible and veriable evidence of the implemented security mechanisms [12]. The UCOM rewall is summarised in gure 3 and in subsequent sections, we will discuss critical components which are relevant to this paper.

Resource Manager. The request for an application's shareable resource is handled by its Application Resource Manager (ARM) and the Runtime Resource Manager (R2M) handles the access to the platform's resources (APIs): gure 3. When a client application requests shareable resources, the rewall invokes the ARM of the server application. The ARM then veries, and validates the client application's credentials, and current state as secure for sanctioning the application sharing (as part of the ABP). If successful, the ARM issues the shareable resources to the requesting application.

Context A Package B UCOM Firewall

ACL

Applet A1 Applet A2 Application Resource Manager (ARM)

Application Resource Manager (ARM)

Package A

Context B

ACL SIOs Applet B1

Application Context

Applet B2

UCOM Firewall Runtime Environment

Runtime Resource Manager (R2M) Runtime Environment Entry Point Objects

System Context

Application Programming Interfaces (APIs) System Classes Virtual Machine

Native Code

Trusted Environment Manager (TEM) Smart Card Hardware ACL: Access Control List. SIO: Shareable Interface Object. ARM: Application Resource Manager

Fig. 3.

UCOM Smart Card and Firewall Architecture

Trusted Environment Manager (TEM). The complete architecture and functionality of a TEM [10] for smart cards is still under research but for completeness we discuss those elements of the design that are most relevant to this paper. The TEM provides assurance and validation of installed applications and the underlying smart card platform. Each application, and platform can have a security evaluation performed by a third party; most notably under the Common Criteria (CC) scheme [6]. In the ICOM, CC certicates are static and oine [12, 42]. However, in the UCOM a CC certicate can be digital that facilitates a dynamic assurance and validation mechanism [12]. The digital certicate will have a digest of the secure-evaluated state of the platform/application. During the ABP, both applications provide their certicates, and the TEM validates the current state as secure as it was at the time of the CC evaluation. In the UCOM, the security evaluation is only mandatory for the smart card platform. When an application is installed onto a smart card, the TEM calculates the hash of the application and, then establishes a secure relation (shared key) with the installed application. The TEM does not calculate the hash of an application, unless it is authorised by the application itself, a cardholder or the application's SP. When an application authorises the TEM to generate its hash value; it generates a message encrypted with the Application-TEM shared symmetric

1

key (KApp−T EM ) . The authorisation message generated by an application is

2

referred as an Integrity Verication Authorisation (IVA) message .

1

2

The Application-TEM shared Key (KApp−T EM ) is generated at the time of the application installation. Both the TEM and the application have this key, and it is used to encrypt communication between them. The IVA structure is EAppA −T EM (AppA , AppB , RandomN umberAppA ); contents of the messages are the identity of the authorising application and application for whom TEM generates the hash value, and a random number [35].

3

Applications-Binding Protocol (ABP)

In this section, we open the discussion by explaining the concept of applicationbinding along with the threat model for the ABP. Next we discuss the application enrolment process, and nally describe the proposed protocol.

3.1

Application-Binding

The application-binding is a process in which two applications (on the same smart card) establish trust in each other's identity, credentials, and current state. Following from that they generate a cryptographic key that they will use in all future communications. The generated key binds a client application with the corresponding server application and acts as an authentication credential. Why is application-binding required in the UCOM, but not needed in the ICOM? The obvious reason for not being included in the ICOM is the centralised control of smart cards. The issuers always know which applications are installed on their smart cards along with having a trust relationship, so there is an oine understanding (or agreement) that applications will not be malicious. Nevertheless, in the UCOM such assumptions are dicult to sustain. In the absence of a centralised authority an application is unable to verify and authenticate the identity of other applications. Therefore, an application can masquerade as either a server or client application (section 3.2). Avoiding masquerading is possible if: a) the AID allocation is centralised, and b) have an AID enforcement mechanism to forbid the application installation with an unauthorised AID. Similarly, to the ICOM it might not be necessary to have an ABP in the UCOM; only if an SP knows what other applications are installed on a smart card before leasing its application, and there is a secure AID enforcement mechanism in place. One solution is to scan the smart card to analyse installed applications but this approach violates the privacy requirement of the UCOM [13].

3.2

Threat Model

The following threat model is mapped to the practical attacks demonstrated in [16, 32, 37, 47]; that an UCOM rewall also has to deal with.

Application Masquerading.

In this scenario, a malicious application can

masquerade as a server or client application. As an example, in Java Card when a client application sends the request for application sharing it generates the request that contains the server application's AID. Now if a malicious application is masquerading as a server application; it only has to inform the rewall that it accepts the application sharing request without validating that it has the knowledge of the shared secret. Thus the client application thinks that it is accessing the shared resource of the server application; whereas it is communicating with a malicious application. Now the fake server application can resend the application sharing request message to a genuine server application on another smart card and gain access to shared resources; this scenario is illustrated in gure 4.

Smart Card A Server Application

Sharing Request

Fake Client Application

Message transfer by the malicious user

Smart Card B Fake Server Application

Smart Card Runtime Environment

Fig. 4.

Sharing Request

Client Application

Smart Card Runtime Environment

Application Masquerading and Relay Attack Scenario

Unresolved Binding Instances.

When an application is deleted the appli-

cation sharing with other applications may not be revoked. In this scenario, a malicious application can masquerade as either a client or a server application and try to communicate with other applications on the smart card. Obviously, for such an attack the malicious user requires the knowledge of the object reference to the shareable resources. Nonetheless, in the UCOM it is necessary that bindings are revoked when one of the participating applications is deleted. The deletion of a binding instance is performed by simply deleting the application binding instance in the participating application's ACL (gure 3).

Dierent User's Applications.

Consider a scenario in which we have two

Mu while the other is an AppA (server application) and

users and two applications. One is a malicious user authorised user

AppB

Au .

The two applications are

(client application) that have a client-server relationship.

Both users are authorised to

AppA , howMu is not authorised to download application AppB .Now at some point, the Mu obtains the AppB 's credentials for the Au and manages to download AppB

download application

Request for AppA Credentials (Mu)

ever

SP of AppA

Mu

Smart Card of Mu

on to his or her smart card. The application sharing between the

Mu 's AppA

and the

Au 's AppB

SP of AppB

AppA Credentials (Mu) AppB Request for AppB Credentials (Au) Credentials (Au) Server Application (AppA-Mu)

Sharing

Client Application (AppB-Au)

Smart Card Runtime Environment

can be established. This can lead to some nancial benets for the

Mu

to which he or she was not

entitled.

3.3

Application Sharing among Dierent User's Applications Fig. 5.

Requirements for the Protocol

Based on the threat model described in the previous section and on general UCOM requirements; the ABP should support the following features: 1. Provide mutual entity authentication. 2. Provide protection against application masquerading and relay attacks. 3. A malicious user should not be able to deduce the binding (share secret) by eavesdropping on the communication between client and server application. 4. Binding should be between two applications that belong to the same user.

5. Both applications should mutually provide assurance and validation that their current state is the same as expected (trusted star). 6. Binding should be unique to a specic instance of applications. If one of the applications is deleted the binding should be revoked. When the deleted application is installed again a new binding should be generated. 7. A shared secret key is generated at the successful conclusion of the ABP. 8. Entire protocol should execute on the smart card without using any external entity. The requirement four may appear counter intuitive as communication buses on smart cards are encrypted [34], and it is dicult to monitor the communication over them if not impossible. However, a conguration similar to the one illustrated in gure 4 can be used to monitor the communication.

3.4

Enrolment Process

During the enrolment process, SPs of a client and server application agree on the business and technical terms for sharing their application resources on an UCOM based smart card. In this process, an SP of a client application provides assurance and validation from a third party evaluation [6] to

Common Criteria Certification Authority

an SP of a server application, and vice versa. If third party evaluation is not available then both client and server application's SPs can decide on any other adequate way to establishing trust in each

Server Application’s Service Provider’s certificate

Client Application’s Service Provider’s Certificate

other's application and its functionality.

Application Certificate (Includes User details)

During this process, they decide the details of the ABP, such as: to perform an on-card verication and validation of applications; the SP of the server applica-

Hierarchy of a Client Application's Certicate Fig. 6.

tion issues a certicate to the client application, and vice versa. The certicate hierarchy in the ABP is illustrated in gure 6. In the absence of the CC evaluation; the certicate hierarchy shown in gure 6 will not include "Common Criteria Certication Authority". The client application certicate has the hash value (generated either by the CC or by the SP of the server application) of the application and user's details to which the application is issued. Similar contents will also be included in the server application certicate. Basically, the enrolment process denes the restrictions and mechanisms (i.e. certicates, and cryptographic algorithms, etc.) that a client/server application's SPs agree for the ABP.

3.5

Proposed Application-Binding Protocol

The aim of the ABP is to facilitate both the client and server applications to establish trust in each other's identity, and current state. Enabling them to

establish a unique binding for future communications. Figure 7 depicts a generic representation of the proposed ABP and subsequently explanation along with the description of individual messages is provided. Before we illustrate the ABP, we rst describe the notation in table 1 that is used in the protocol description.

Server Application

Client Application

Smart Card Firewall

Trusted Platform Module

1) Binding Request (Server AID) Verify whether the application exists on smart card or not. Request Sharing (Client AID) Deny Request Request Denied 2) Forwarded Binding Request (Client AIB) 3) Request Validation (Client AID) Perform Validation of Client and Server Application

4) Response Validation (Validation of Client and Server, Temporary Shared Key) Verify the Validation of Client 5) Response Binding(Server Validation, Shared Secret, Resource Manager Reference) Verify the Validation of Server 6) Validate Shared Key Knowledge

Fig. 7.

Generic Representation of the Application-Binding Protocol

Based on the generic ABP framework in gure 7 a number of dierent protocols can be deployed. The proposed protocol is our attempt to provide a secure, and robust implementation of the ABP. In addition, the proposed protocol provides the trust assurance and validation; enabling it to be a secure and trusted secure channel protocol [24]. The rationale for not opting for protocols like SSL/TLS [21], and Kerberos [38] is twofold; rst they have a large set of options and lengthy handshake messages that might slow down the performance on a smart card (see section 4.3), and secondly they do not support trust assurance and validation mechanism for the communicating parties. This is true to some extent for other protocols that are designed for the internet communication [24]. Even those protocols that are designed for the smart card environment; partially run on the smart card and they try to balance the computation load by performing computational intense processes ocard [7, 33, 39, 43].

Notation Description S C T EM F irewall KA−B t KS−C SA , VA

Table 1.

Protocol Notation

Represents the identity of the server application. Represents the identity of the client application. Represents the identity of a TEM on a smart card. Represents the identity of the UCOM rewall on a smart card. Long term symmetric key shared between entity A and B. Session key generated by TEM. Signature and verication key pair of entity A.

CertA CertA−B nx nx + num

Signature key pair certicate of entity A. Certicate for entity B issued by entity A. Random number generated by an entity X. Random number incremented by the value of num is a natural number

A→B X|Y X||Y EK (Z)

Message sent by an entity A to an entity B. Represents the concatenation of the data items X, and Y. Represents the XOR binary operation on the data items X, Y. Result of encrypting data Z with the key K using a symmetric algorithm.

SignK (Z)

Signature on data Z with the key K using a signature algorithm [23].

Hash(Z)

Is the result of generating a hash of data Z.

The messages listed below have a one-to-one relation with the generic protocol illustrated in gure 7. 1.

C → F irewall : C|S|SignC (C|S|nc|EKC−T EM (C, S, nc))|CertC

The request message contains the identities of the client and server application together with a random number [35] generated by the client application. In addition, the client application also creates an IVA message (i.e.

EKC−T EM (C, S, nc))

for the TEM (see section 2.2). The client application signs the message and appends its certicate. 2.

F irewall → S : C|S|SignC (C|S|nc|EKC−T EM (C, S, nc))|CertC

The rewall mechanism receives the application-binding request and it will query the server application. If the server application wants to proceed with the ABP, it forwards the message; otherwise, it registers an exception. 3.

S → T EM : C|S|EKC−T EM (C, S, nc )|EKS−T EM (S, C, ns )

The server application veries the client's signature. If successful, it generates an IVA message for the client application. The server application then sends the message to the TEM that contains the identities and IVA messages from both the client and server applications.

t t , , nc +1)|EKS−T EM (Hash(C), KS−C T EM → S : EKC−T EM (Hash(S), KS−C ns + 1) 4.

The TEM veries the IVA messages from both the client and server application. Then it will calculate the hash value of the server application, encrypt it with the client-TEM shared key and sends it to the client application, and vice versa. The encrypted messages also contains a session key generated by the TEM; this key is valid only during the ABP run.

t t S → C : S|C|EKC−T EM (Hash(S), KS−C , nc +1)|EKS−C (KS−C , nc +2, ns )| SignS (S|C|ns |EKS−C (AccessP ermission, ObjectRef erence, nc ||ns ))|CertS 5.

Following the message 4; the server application veries the hash value of the client application to be the same as listed either by the server application's SP or by the CC evaluation authority. It then generates an application-binding key; encrypts it with the session key. In addition, the message also contains the object

reference to the server application's shared resources and access permission. The client application directly calls the server application's shared resource in all subsequent requests, using the binding key for authentication and authorisation. The access mechanism for shared resource is beyond the scope of this paper. 6.

C → S : C|S|EKS−C (AccessP ermission|(nc ||ns ) + 1)

This message gives the assurance to the server application that the client also has the same key thus achieving mutually key verication.

4

Proposed Protocol Analysis

We open the discussion by analytically reviewing the protocol then the formal analysis using CasperFDR tool, and nally providing the implementation results.

4.1

Analytical Analysis

In this section, we consider the proposed protocol and analyse it with respect to the threat model, and the protocol requirements listed in section 3.2 and 3.3.



Masquerading: A malicious application can be installed with either a server

or a client application's AID. However, the ABP does not allow a malicious application to masquerade as a server or client application because to prove the identity of an application; the ABP does not rely on the AIDs. It has a dynamic mechanism with bi-directional exchanges of messages that ascertain the entity and verify its credentials (based on cryptographic certicate and signature generation/verication). Therefore, for a masquerading application it might be dicult to match the cryptographic hash (generated by the TEM) and have the signature key of the genuine application.



Replay attack: A malicious user can relay the binding request messages,

but when these messages are forwarded to the TEM to generate the hash of the client and server application. A malicious application's hash will not match the certied hash of the client and server application. This problem is equivalent to violating the 2nd pre-image property of the hash functions [35]. In addition, IVA messages include random numbers that eectively prevent any replay attacks.



Mutual Authentication: The server and client applications authenticate

one another. The authentication is achieved through signing the messages along with communicating the application's certicate. The authentication gives an assurance to each of the participant applications that the other application is genuine (eectively avoiding masquerading).



State Verication: Although an application may have genuine credentials

but its state might be modied since it was last evaluated by respective SP(s) or the CC evaluation laboratory. To verify whether the state of an application is secure enough to initiate an application sharing. The ABP requires the TEM to generate a hash of both applications and encrypt them with the corresponding keys. The applications have no inuence on the outcome of the hash generation; so they cannot fake their current state. If the current state is considered to have

deviated from the stated secure state in the application certicate [12]. The recipient can then decide whether to continue the protocol or not.



Dierent User Applications: The application certicate contains the user

details to whom the application was issued. Therefore, if a client application tries to establish an application sharing with a server application, but their customer credential does not match; the request is denied. This avoids application sharing between two applications from dierent users.



Unresolved Binding Instances: The binding is based on the application-

binding key that is the outcome of the ABP. If one of the applications (client or server) is to be deleted by the user. The application deletion process will notify the other application that simply deletes the instance of the application-binding key from its ACL. The ABP provides a framework that facilitates the process; enabling the participant applications to establish a trust relationship on an open, and dynamic environment of the UCOM.

4.2

Protocol Verication by CasperFDR

The CasperFDR approach was adopted to test the soundness of the proposed protocol under the dened security properties. In this approach, the Casper compiler [2] takes a high-level description of the protocol, together with its security requirements. It then translates the description into the process algebra of Communicating Sequential Processes (CSP) [28]. The CSP description of the protocol can be machine-veried using the Failures-Divergence Renement (FDR) model checker [40]. The intruder's capability modelled in the Casper script (Appendix A) for the proposed protocol is as below:

1. An intruder can masquerade any application's identity in the network. 2. An intruder is not allowed to masquerade the identity of any SP or TEM. 3. An intruder application has a trust relationship with the TEM. 4. It can read the messages transmitted by each entity in the network. 5. An intruder cannot inuence the internal process of an agent in the network. The security specication for which the CasperFDR evaluates the network is as shown below. The listed specications are dened in the # Specication section of Appendix A:

1. Session and application-binding keys are not revealed to an unauthorised entity. 2. The protocol run is fresh and both applications were alive. 3. The key generated by the server application is known only to the client application. 4. Applications mutually authenticate each other and have mutual key assurance at the conclusion of the protocol.

The protocol description dened in the Casper script (Appendix A) is a simplied representation of the proposed protocol. The o-card agents like SPs of client and server applications are not model in the Casper script as they do not play active role in the protocol run. The CasperFDR tool evaluated the protocol and did not nd any feasible attack(s).

4.3

Practical Implementation

The proposed protocol in section 3.5 does not specify actual details of the cryptographic algorithms that are left to the respective SPs. However, in our implementation we used AES 128bit key in Cipher Block Chaining mode with padding [30]. The signature algorithm was chosen to be RSA with 512bit key [35] and SHA-256 [3] for generating hash values . Our implementation model was based on three applets taking the roles of the TEM, client, and server application on a Java Card (16bit smart card). At the time of writing the paper; we did not have access to a smart card platform that will enable us to implement the TEM at the underlying platform level. We implement the TEM at the application level and consider that similar or better performance can be attained if the TEM is implemented as part of the platform (which we plan to do in future). As the application level implementation of the TEM cannot have memory access to measure the hash value of the client and server applications. Therefore, we generated the hash values of a xed array of size 556 bytes to represent an application state. The performance of the hash algorithm is based on the size of the input data and in real deployment of the protocol scenario it denitively depends on the size of the applications. The proposed protocol's raw implementation running on a 16bit Java Card takes 2484 ms (2.484 seconds approximately) to complete, and we consider that with adequate code optimisation we can achieve better results. For the sake of comparison, the Kilobyte SSL [26] (KSSL: is a small footprint SSL for hand-held devices) running on a 20Mhz Palm CPU with RSA keys of length 768 and 1024 took 10-13 seconds for only server side authentication [25]. A Kerberos' implementation on a mobile device as performed by Herbitter et al. [27] (performance measures were taken from a mobile device with 100MHz CPU and 16MB of RAM) showed that the best performance was 4.240 seconds; however, based on a trusted proxy architecture the performance was 10.506 seconds. Kambourakis et al. [31] provided performance measures for the SSL based AKA mechanism that took 10 seconds to complete the protocol. For above performance measures; in the SSL implementations the server, and for Kerberos both the Key Distribution Centre (KDC) server and second communication entity, were on desktop computers. In implementations, where smart cards act as a node in a communication protocol Pascal Urien [44] showed that a high-end SSL Smart Card establishes a SSL session in 4.2 seconds , and for smart cards as a TLS-based network node the performance was in the range of 4.3 seconds (for 32bit smart card) and 26.8 seconds (for 8bit smart card) [45, 46, 48]. The protocol performance mentioned in this section either do not rely on smart cards or partially base

their implementation on smart cards. However, if we implement these protocols with all nodes on a smart card along with trust assurance, there performance will degrade. At the time of writing this paper, the authors were not aware of any performance measures of these protocols implemented in full (all communicating nodes) on a smart card. It can be argued that the above mentioned performance measures cannot be comparable as the complete protocol were not executing on a smart card. This is a valid argument but the reason we mention them here is to augment the rationale based on the computational restrictions that prohibited us from implementing these protocols as part of the ABP. Nevertheless, the proposed protocol performance is considered adequate. The performance measure is only for the reference of our implementation, as the actual performance will vary depending upon the size of the client and server applications (i.e. hash generation), and performance of public key operation, symmetric encryption, and random number generation.

5

Conclusion and Future Research Direction

In this paper, we discussed the application sharing mechanism from the point of view of two contrasting smart card ownership models. The rewall mechanism in the ICOM is t for the purpose and is designed with the underlying assumption that the smart card remains under the control of a centralised authority. These rewall mechanisms and associated frameworks to establish application sharing can be considered as the state of the art in the ICOM. Nevertheless, in the UCOM such assumptions are invalid and this requires a dierent set of requirements for the application sharing mechanism. We have discussed these requirements along with the threat model and provided a possible approach to resolve them. The proposed protocol meets these requirements under the assumption of the threat model both as a generic model, and then providing a practical protocol based on the generic model. We have veried the security properties for the proposed protocol in the Casper/FDR. Furthermore, an analytical analysis of the protocol is described. Finally, we implemented the protocol to provide the performance measure for the proposed approach. As part of the future research directions we will concentrate on the architecture and functionality of the TEM for smart cards. The TEM on an UCOM based smart card provides security assurance and validation service to the smart card platform and installed applications. Furthermore, we also like to extend the TEM's capability to not only provide static assurances, but also dynamically ensure the runtime security and reliability of the platform.

6

Acknowledgements

We would like to extend our appreciation to the anonymous reviewers for their valuable time and feedback. Additionally, thanks to Min Chen for patience while proof reading drafts.

References 1. Multos: The Multos Specication,. Online 2. Casper: A Compiler for the Analysis of Security Protocols, Journal of Computer Security (June 1998) 3. FIPS 180-2: Secure Hash Standard (SHS) (2002) 4. GlobalPlatform Card Security Requirement Specication 1.0 (May 2003) 5. ISO/IEC 7816-5, "Information Technology - Identication cards - Integrated Circuit(s) cards with contacts - Part 5: Numbering systems and registration procedure for application identiers, International Organization for Standardization (2004) 6. Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and general model, Part 2: Security functional requirements, Part 3: Security assurance requirements, (August 2006) 7. GlobalPlatform: GlobalPlatform Card Specication, Version 2.2 (March 2006) 8. Java Card Platform Specication; Application Programming Interface, Runtime Environment Specication, Virtual Machine Specication (March 2006) 9. Multos: Guide to Loading and Deleting Applications. Tech. Rep. MAO-DOC-TEC008 v2.21, MAOSCO (2006) 10. Trusted Module Specication 1.2: Part 1- Design Principles, Part 2- Structures of the TPM, Part 3- Commands (July 2007) 11. Akram, R.N., Markantonakis, K., Mayes, K.: Application Management Framework in User Centric Smart Card Ownership Model. In: YOUM, H.Y., Yung, M. (eds.) The 10th International Workshop on Information Security Applications (WISA09). vol. 5932/2009, pp. 2035. Springer, Busan, Korea (August 2009) 12. Akram, R.N., Markantonakis, K., Mayes, K.: A Dynamic and Ubiquitous Smart Card Security Assurance and Validation Mechanism. In: Rannenberg, K., Varadharajan, V. (eds.) 25th IFIP International Information Security Conference (SEC 2010). pp. 161172. IFIP AICT, Springer, Brisbane, Australia (September 2010) 13. Akram, R.N., Markantonakis, K., Mayes, K.: A Paradigm Shift in Smart Card Ownership Model. In: Apduhan, B.O., Gervasi, O., Iglesias, A., Taniar, D., Gavrilova, M. (eds.) Proceedings of the 2010 International Conference on Computational Science and Its Applications (ICCSA 2010). pp. 191200. IEEE Computer Society, Fukuoka, Japan (March 2010) 14. Akram, R.N., Markantonakis, K., Mayes, K.: Firewall Mechanism in a User Centric Smart Card Ownership Model. In: Gollmann, D., Lanet, J.L., Iguchi-Cartigny, J. (eds.) Smart Card Research and Advanced Application, 9th IFIP WG 8.8/11.2 International Conference, CARDIS 2010. vol. 6035/2010, pp. 118132. Springer, Germany (April 2010) 15. Andronick, J., Chetali, B., Ly, O.: Using COQ to Verify Java Card Applet Isolation Properties. In: 16th International Conference on Theorem Proving in Higher Order Logics. No. 2758 in LNCS, Springer-Verlag (2003) 16. Barbu, G., Thiebeauld, H., Guerin, V.: Attacks on Java Card 3.0 Combining Fault and Logical Attacks. In: Gollmann, D., Lanet, J.L., Iguchi-Cartigny, J. (eds.) Smart Card Research and Advanced Application, 9th IFIP WG 8.8/11.2 International Conference, CARDIS 2010. LNCS, vol. 6035/2010, pp. 148163 (2010) 17. Bernardeschi, C., Martini, L.: Enforcement of Applet Boundaries in Java Card Systems. In: IASTED Conf. on Software Engineering and Applications. pp. 96 101 (2004) 18. Caromel, D., Henrio, L., Serpette, B.P.: Context Inference for Static Analysis of Java Card Object Sharing. In: E-SMART '01: Proceedings of the International

19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33.

34. 35. 36. 37.

38.

Conference on Research in Smart Cards. pp. 4357. Springer-Verlag, London, UK (2001) Chen, Z.: Java Card Technology for Smart Cards: Architecture and Programmer's Guide. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA (2000) Deville, D., Galland, A., Grimaud, G., Jean, S.: Smart Card Operating Systems: Past, Present and Future. In: In Proceedings of the 5th NORDU/USENIX Conference (2003) Dierks, T., Rescorla, E.: RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2. Tech. rep. (August 2008) Éluard, M., Jensen, T.P., Denney, E.: An Operational Semantics of the Java Card Firewall. In: E-SMART '01: Proceedings of the International Conference on Research in Smart Cards. pp. 95110. Springer-Verlag, London, UK (2001) Furlani, C.: FIPS 186-3 : Digital Signature Standard (DSS). Online (June 2009) Gasmi, Y., Sadeghi, A.R., Stewin, P., Unger, M., Asokan, N.: Beyond Secure Channels. In: STC '07: Proceedings of the 2007 ACM workshop on Scalable trusted computing. pp. 3040. ACM, New York, NY, USA (2007) Gupta, V., Gupta, S.: Securing the Wireless Internet. IEEE Communications 39(12), 6874 (December 2001) Gupta, V., Gupta, S.: KSSL: Experiments in Wireless Internet Security. Tech. rep., Mountain View, CA, USA (2001) Harbitter, A., Menascé, D.A.: The Performance of Public Key-Enabled Kerberos Authentication in Mobile Computing Aplications pp. 7885 (2001) Hoare, C.A.R.: Communicating Sequential Processes, vol. 21. ACM, New York, NY, USA (1978) Huisman, M., Gurov, D., Sprenger, C., Chugunov, G.: Checking Absence of Illicit Applet Interactions: A Case Study. In: Fundamental Approaches to Software Engineering, FASE 2004. No. 2984 in LNCS, Springer (2004) Joan Daemen and Vincent Rijmen: The Design of Rijndael: AES - The Advanced Encryption Standard. Springer Verlag, Berlin, Heidelberg, New York (2002) Kambourakis, G., Rouskas, A., Gritzalis, S.: Experimental Analysis of an SSLBased AKA Mechanism in 3G-and-Beyond Wireless Networks. Wirel. Pers. Commun. 29, 303321 (June 2004) Lanet, J.L., Iguchi-Cartigny, J.: Developing a Trojan applet in a Smart Card . Journal in Computer Virology 6(1) (2009) Markantonakis, K., Mayes, K.: A Secure Channel Protocol for Multi-application Smart Cards based on Public Key Cryptography. In: Chadwick, D., Prennel, B. (eds.) CMS 2004 - Eight IFIP TC-6-11 Conference on Communications and Multimedia Security. pp. 7996. Springer (September 2004) Mayes, K., Markantonakis, K. (eds.): Smart Cards, Tokens, Security and Applications. Springer (2008) Menezes, A.J., van Oorschot, P.C., Vanstone, S.A.: Handbook of Applied Cryptography. CRC (October 1996) Montgomery, M., Krishna, K.: Secure Object Sharing in Java Card. In: WOST'99: Proceedings of the USENIX Workshop on Smartcard Technology. USENIX Association, Berkeley, CA, USA (1999) Mostowski, W., Poll, E.: Malicious Code on Java Card Smartcards: Attacks and Countermeasures. In: CARDIS '08: Proceedings of the 8th IFIP WG 8.8/11.2 international conference on Smart Card Research and Advanced Applications. pp. 116. Springer-Verlag, Berlin, Heidelberg (2008) Neuman, C., Hartman, S., Raeburn, K.: RFC 4120: The Kerberos Network Authentication Service (V5). Tech. rep. (July 2005)

39. Rantos, K., Markantonakis, C.: An Asymmetric Cryptography Secure Channel Protocol for Smart Cards. In: Deswarte, Y., Cuppens, F., Jajodia, S., Wang, L. (eds.) Security and Protection in Information Processing Systems, IFIP 18th WorldComputer Congress, TC11 19th International Information Security Conference, 22-27 August 2004, Toulouse, France. pp. 351366. Kluwer (2004) 40. Ryan, P., Schneider, S.: The Modelling and Analysis of Security Protocols: the CSP Approach. Addison-Wesley Professional (2000) 41. Sauveron, D.: Multiapplication Smart Card: Towards an Open Smart Card? Inf. Secur. Tech. Rep. 14(2), 7078 (2009) 42. Sauveron, D., Dusart, P.: Which Trust Can Be Expected of the Common Criteria Certication at End-User Level? Future Generation Communication and Networking 2, 423428 (2007) 43. Sirett, W.G., MacDonald, J.A., Mayes, K., Markantonakis, C.: Design, Installation and Execution of a Security Agent for Mobile Stations. In: Domingo-Ferrer, J., Posegga, J., Schreckling, D. (eds.) Smart Card Research and Advanced Applications, 7th IFIP WG 8.8/11.2 International Conference, CARDIS. LNCS, vol. 3928, pp. 115. Springer, Tarragona, Spain (April 2006) 44. Urien, P.: Collaboration of SSL Smart Cards within the WEB2 Landscape. Collaborative Technologies and Systems, International Symposium on 0, 187194 (2009) 45. Urien, P., Elrharbi, S.: Tandem Smart Cards: Enforcing Trust for TLS-Based Network Services. Applications and Services in Wireless Networks, International Workshop on pp. 96104 (2008) 46. Urien, P., Marie, E., Kiennert, C.: An Innovative Solution for Cloud Computing Authentication: Grids of EAP-TLS Smart Cards. Digital Telecommunications, International Conference on pp. 2227 (2010) 47. Vétillard, E., Ferrari, A.: Combined Attacks and Countermeasures. In: Gollmann, D., Lanet, J.L., Iguchi-Cartigny, J. (eds.) Smart Card Research and Advanced Application, 9th IFIP WG 8.8/11.2 International Conference, CARDIS 2010. LNCS, vol. 6035/2010, pp. 133147 (2010) 48. Yu, D., Chen, N., Tan, C.: Design and Implementation of Mobile Security Access System (MSAS) Based on SSL VPN. Education Technology and Computer Science, International Workshop on 3, 152155 (2009)

A

Casper/FDR Script

# Free variables S, C, spS, spC : Agent TEM : Server nc, ns, nm : Nonce ksc, abKsc : SessionKey f : HashFunction ServerKey : Agent -> ServerKeys VKey : Agent -> Publickey SKey : Agent -> SecretKey realAgent : Server -> Bool InverseKeys = (ksc, ksc), (abKsc, abKsc), (ServerKey, ServerKey),(VKey, SKey) #Actual variables CApp, SApp, MAppl : Agent

TM : Server Nc, Ns, Nm : Nonce Ksc, ABKsc : SessionKey InverseKeys = (Ksc, Ksc), (ABKsc, ABKsc) #Processes INITIATOR(C, TEM, S, nc) knows f(S), ServerKey(C), SKey(C), VKey RESPONDER(S, TEM, C, ns, abKsc) knows f(C), ServerKey(S), SKey(S), VKey SERVER(TEM, ksc) knows ServerKey #System INITIATOR(CApp,TM, SApp, Nc) RESPONDER(SApp,TM, CApp, Ns, ABKsc) SERVER(TM, Ksc) #Protocol description 0. -> C : S 1. C -> S : C, S, {C, S, nc, {C, S, nc}{ServerKey(C)}% mTEM}{SKey(C)} 2. S -> TEM : S, TEM, C, {S, C, ns}{ServerKey(S)},mTEM % {C,S,nc}{ServerKey(C)} [realAgent(TEM)] 3. TEM -> S : TEM, S, {f(S), ksc, nc}{ServerKey(C)}%TEMC [realAgent(TEM)] 3a. TEM -> S : TEM, {f(C), ksc, ns}{ServerKey(S)} 4. S -> C : S, C, TEMC % {f(S), ksc, nc} {ServerKey(C)} 4a. S -> C : {abKsc, nc, ns}{ksc},{S, C, nc(+)ns}{abKsc} 5. C -> S : C, S,{nc(+)ns}{abKsc} #Specification StrongSecret(TEM, ksc, [S,C]) StrongSecret(S, abKsc, [C]) Aliveness(S, C) Aliveness(C, S) Agreement(S, C, [abKsc]) Agreement(C, S, [abKsc]) #Inline functions symbolic ServerKey symbolic VKey, SKey realAgent(TM)=true realAgent(_)=false #Intruder Information Intruder = MAppl IntruderKnowledge = {CApp, SApp, MAppl, Nm, ServerKey(MAppl), SKey(MAppl),VKey}