Leveraging UICC with Open Mobile API for Secure Applications and Services

UICC UICC is a smart card used in mobile terminals in GSM and UMTS networks It provides the authentication with the networks secure storage crypto algorithms … Java Card as UICC can provide Hash functions: MD5, SHA-1, SHA-256 … Signature functions: HMAC … Public-key cryptography: RSA … Symmetric-key cryptography: AES, DES … ?

Toolkit SIM Application Toolkit is a standard of GSM which can be used by the MNO to provide value-added services It is a set of commands which define how the card should interact with the outside world But the update of toolkit application and menu stored in the UICC is difficult and there is no support for multimedia

Smart Card Web Server The SCWS is based on a standard HTTP 1.1 web server embedded in smart card, allowing communication with any HTTP client – particularly the handset browser It will benefit from all the latest improvement of particular client (JavaScript, XMLHttpRequest) and support s browser plug-ins such as Adobe Flash to bring Apps’ UI to the next level

Generic Bootstrapping Architecture (GBA) GBA extends the security infrastructure and establishes key agreement It uses the 3GPP Authentication and Key Agreement (AKA) mechanism, enables authenticated User Equipment (UE) access to the Network Application Function (NAF) services. But it requires to implement a GBA module to communicate with the browser, the NAF and the UICC

Open Mobile API Open Mobile API Open Mobile API is established by SIMalliance as an open API between the Secure Element and the applications Crypto Authentication Secure Storage PKCS#15 … Open Mobile API

Open Mobile API 3 Layers Transport Layer: using APDUs for accessing a Secure Element Service Layer: provide a more abstract interface for functions on SE Application Layer: represents the various applications using Open Mobile API Transport layer ist am wichtigsten. In SEEK-For-Android wird bisher auch nur transport layer implementiert. In service layer gibt es unterschiedliche Services, die von SE unterstützt werden, wie z.B. Crypto, File Management, Authentication. Aber alle dieser Services können auch nur mit APDU in transport layer aufgeruft werden. Figure 1: Architecture overview

OpenMobile API: Transport API Figure 2: Transport API class overview Usage pattern create SEService select Reader open Session Transit APDUs Channel open

Use cases NFC services Payment services Ticketing services Loyalty services (Kundenbindungsmaßnahmen) ID services

OpenID Overview Submit OpenID ID Association Log-On Relying Party Relying Parties Submit OpenID ID Association OpenID is a Web authentication framework based on common browser and server technology. 1. When a user logs on to a service, called a Relying Party, he submits his OpenID identifier – the equivalent of a user name to the service. The Relying party does not verify the identity, or authenticate, the user by itself, but uses an OpenID identity provider. 2. Relying party and OpenID Provider use standardised messages to build a trust relationship, called association, for the current user authentication. 3. The OpenID provider then authenticates a user, commonly by asking him to enter a password, into a Web form. 4. When the OpenID provider has verified the user‘s identity, an identity assertion is sent to the relying party and the user is logged on. 5. One of the features of OpenID is that users can use one identifier, or user name, with many services. Log-On Device User User authentication OpenID Provider

OpenID Weakness Phishing An “Identity System” without Trust: no authority can promise OpenID rzhou.myopenid.com is Ran Zhou. No single-sign-on Communication Overhead: lots of HTTP requests

SmartOpenID With Smart OpenID, we tackle the main problems of OpenID, while keeping its benefits. 1. The central idea of Smart OpenID is to introduce a function on the user device, called local OpenID Provider, or local OP for short. 2. The local OP acts as a trusted proxy of the OpenID provider in the Internet and has a pre-established trust relationship with it. 3. In Smart OpenID, the local OP is the endpoint of all message exchange with the browser for user authentication. 4. Also, the local OP can take a function of locally authenticating the user, for instance using a connected biometric device. 5. Now, there is no more messaging over the Internet for user authentication. 6. The local OP signs the identity assertion and sends it back to the Relying Party. 7. The message exchange with the OpenID Provider is significantly reduced in Smart OpenID

SmartOpenID Phishing Sensitive data remains on device An “identity system” without Trust: no authority can promise OpenID rzhou.myopenid.com is Ran Zhou. Trust between user and MNO (contract) No single-sign-on Local OP interface provide SSO Communication Overhead: lots of HTTP requests Significantly reduced authentication traffic

SmartOpenID Architecture Overview A browser which is able to communicate via HTTP with: the service/RP, and the local OP Local OP, which provides a web server interface for the browser and acts like a network based OpenID identity provider SIM communication API, which provides an API for the local OP to communicate with the application on the smart card: Open Mobile API Application on the UICC, which performs all the necessary crypto operations for the local OP A Long Term Secret shared between network OP and local OP, which is used to establish the Trust

SmartOpenID Architecture Overview The UICC application can handle local authentication by means of requesting a user Pin code to unlock the local OP functionality on the UICC The Local OP app receives an HTTP request from the browser containing all the message fields which have to be signed and also including the association handle The UICC application derives the signature key with the Long Term Secret and the association handle using key derivation function: PBKDF2 The UICC signs the message with the derived signature key using HMAC function: HMAC-SHA1 or HMAC-SHA256

Overview of the Master Thesis This master thesis is part of the project “SmartOpenID”, which is carried out by InterDigital, Novalyst and Morpho e-Document Within the thesis, different technologies, which intend to extend the UICC’s usage and bring the value-added services, will be discussed Then the Open Mobile API, which fills the gap between the UICC and the outside world, will be introduced As an use case, the SmartOpenID protocol will be introduced and analyzed The usage of Open Mobile API with UICC will then be shown. As a result, the services, which an UICC can provide, will be introduced and discussed An implementation of the SmartOpenID protocol on an Android device with UICC A test and analyze of the implementation Discussion and prospect of the other use cases with Open Mobile API

Development environment Android Emulator + Open Mobile API + PCSC Card Reader + Morpho UICC Android Handset (Samsung Galaxy S2 NFC) + Open Mobile API + Moupho UICC

Thanks!