1. Leveraging UICC with Open Mobile API for Secure Applications and Services

2. 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 … ?

3. 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

4. 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

5. 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

6. 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

7. 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

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

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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

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

18. Thanks!