secure authentication for mobile internet...

December 2011 – V1

Secure Authentication for Mobile Internet Services

Critical Considerations

Secure Authentication for Mobile Internet Services December 2011 – V1 - 2/24

Table of Contents

Part 1: Understanding the risks associated with mobile internet services based on today’s authentication

methods ............................................................................................................................................................. 4 1.1. The Vulnerability of the Mobile Device ................................................................................................... 4 1.2. Network Vulnerability .............................................................................................................................. 5

Part 2: Today’s challenges ................................................................................................................................ 7 2.1. User/Password Authentication ................................................................................................................ 7 2.2. One Time Password (OTP) Authentication ............................................................................................. 8 2.3. Public Key Infrastructure (PKI) Authentication ...................................................................................... 10 2.4. Moving to a Secure Element ................................................................................................................. 11

Part 3: Integrating a secure element into mobile internet service architectures .............................................. 12 3.1. The Mobile Internet Market and White Paper Scope ............................................................................ 12 3.2. Introducing the different Secure Elements ............................................................................................ 13 3.3. Introducing the Trusted Service Manager ............................................................................................. 14 3.4. Introducing the SIMalliance Open Mobile API ...................................................................................... 14

Part 4: Applying the Secure Element Model to User Centric Security ............................................................ 16 4.1. Model One: Secure authentication where the SE is the UICC ............................................................. 16 4.2. Model Two: Direct issuance of MicroSD cards ..................................................................................... 19 4.3. Model Three: eSE - SE distributed by OEM ......................................................................................... 21

Part 5: Conclusion ........................................................................................................................................... 23 Part 6: Abbreviations & Definitions .................................................................................................................. 24


Executive summary

While the sources vary, the message is clear; attacks on mobile internet devices and connected

smartphones are rising rapidly. McAfee Labs released a report in September 2011 highlighting a 76% jump

in malware targeting Android devices in the previous quarter alone.

Similarly, IBM’s X-Force research group commented that while the number of known vulnerabilities in mobile

operating systems only increased incrementally between 2010 and 2011, the number of exploits based on

these flaws will likely double; leading to sensational headlines such as ‘2012: The Year of the Mobile

Security Breach’ and ‘Mobile Security Breaches Inevitable’.

While calmer heads prevail, there is little doubt that the mobile threat level has been on a steady incline for a

decade, and has recently exploded in line with the growing market penetration of internet connected

smartphones and tablets.

And with these new enabling devices have come a myriad of applications for which security is paramount –

from mobile wallet and NFC payment through to the growth in mobile healthcare applications. But it isn’t just

these ‘usual suspect’ applications that are causing concern.

Security is now a major issue for consumers when selecting applications and services across the board –

from video and photo sharing, to messaging and business apps. Indeed, according to a poll by ThreatMetrix

and the Ponemon Institute, 85% of consumers are overwhelmingly dissatisfied with the level of protection

online businesses are providing to stop fraudsters.

The question is whether current levels of protection are capable of securing today and tomorrow’s mobile

devices and applications – and the message seems to be ‘no’.

In this paper we look in detail at the issue of mobile internet security, analyze existing authentication

methods, and ask whether it is time for the widespread adoption of the Secure Element by the mobile

community.


Part 1: Understanding the risks associated with mobile internet services based on today’s authentication methods

With the 300% growth of smartphone connections in 2010 alone, mobile internet devices will soon

outnumber the PC in everyday use and become the de facto consumer channel for accessing the internet.

Indeed, by the end of 2011, 85% of new mobile devices will be able to access the mobile web, while the

increase in broadband speeds up to 2Mbps by 2015 will further accelerate the significant growth in rich

media and transactional services across the board. M-banking will reach 500 million users by 2015, and the

value of mobile transactions is set to exceed $1 trillion by the same period.

So, while this growth in the quality and relative value of data being transferred across the web from mobile

devices offers consumers, retailers and brands huge benefits, it also highlights significant challenges as the

malware, virus and hacking threats of the wired internet go mobile – as Figure One illustrates.

Figure One: The growth of malware (Bullguard 2011)

1.1. The vulnerability of the mobile device

In contrast to the PC environment, attacks are not limited to a particular operating system. iOS, Windows and

Android have all been subject to attacks – which are growing in sophistication, volume and impact as the

smartphone and tablet revolution gathers pace.

The simplest way of attacking the mobile device is through the application. By the beginning of 2011 10

billion apps had been downloaded from Apple’s app store, and analyst house Gartner predicts a rise in

downloads across all platforms to a massive 185 billion by 2014. By any measure there is little doubt that the

threat level is growing.

Attacks range in volume and severity, but all have the potential to cause chaos at both a device and network

level, and just like in the conventional fixed internet world the threat comes in all shapes and sizes – from


phishing, spyware and worms to trojan’s, man-in-the-middle and more. An overview of the most virulent

attacks is detailed in Figure Two below.

Figure Two: Mobile malware attacks (Source Bullgard 2011)

1.2. Network vulnerability

Of course, it is not only the mobile device that is vulnerable to attack; data is similarly threatened as the vast

majority of applications are hosted externally. Most often these services require some element of

authentication to the external server based on user identity.

And these too range in sophistication; from a simple user ID and password to a certificate issued by a

recognized provider. However, while malicious access to the stored data may be more challenging (as it

eliminates the user-click factor) the rewards are great.

Rather than attacking an individual, hackers are able to target entire databases of service users. Added to

this, detection times of server-side attacks tend to be long, and discovery may only occur when the server –

and the service – goes down as a result. The incidents of such attacks are frequent and highly publicized –

take for example the 2011 incidents which included the Sony Playstation password hack, Sega’s million +

accounts breach and a CitiBank credit-card cyber-attack.

So clearly, with access gained, the data can be manipulated, stolen, distributed across the net or sold to the

highest bidder. And if that wasn’t bad enough, it’s also possible for the hacker to duplicate the server, issue


log-in and credential details, and then retrieve all kinds of sensitive data directly from the user who assumes

they are simply accessing their secure portal.


Part 2: Today’s challenges

Such attacks and vulnerabilities are well known, and the security community has been working hard to

develop solutions and deliver these out into the market. However, security has traditionally been a very

reactive industry, responding to threats and often running to catch up with a community of very dynamic

hackers. As we move into a smartphone and tablet dominated world, the issue is becoming more

pronounced as today’s authentications methods have yet to adapt to the threat levels that mobile devices are

now exposed to.

2.1. User/password authentication

Mobile application security is frequently based on a very conventional log-in and password authentication

(see Figure Three). Based on ‘something you know’ such as a password or PIN number, this is single factor

authentication and it’s totally inadequate when it comes to tackling today’s threats.

There are two main issues here – on the device-side and on the server-side. From an access point

perspective, ‘known’ password or PIN information can be stolen at the client side – either through user-error

or key-logging spyware. Similarly, with the password and username stored in the server, a successful breach

would expose all users’ details to the attacking code. And finally, if the communication channel lacks of point

to point encryption, data can be attacked in transit…over the wired or wireless internet. Because of single

factor authentication, a username and password can be used by the attacker and authenticate to the

corresponding service.

Figure Three: Authentication by login and password


2.2. One Time Password (OTP) authentication

Moving up the levels, One Time Password (OTP) solutions offer more stringent authentication by creating a

single time-bound password and adding a second level of security. For instance, an OTP secured service

will request a PIN code or password and then require an additional ‘something you have’ which may be a

token, a device or channel that provides this one time password. In the case of online banking that ‘token’

will be a code from a card reader, while gaining password reminders online may involve keying in a code

received by SMS after providing a user name online. This is commonly referred to as two factor

authentication.

However, as highlighted in the above examples, OTP is intended to deliver a secure transaction via a PC or

laptop. The token is a separate device and here we cover the most popular options:

2.2.1. OTP through SMS (Figure Four)

In an SMS scenario the OTP code is generated on the server side and sent through to the user’s mobile

handset. As the OTP is sent as a plain text non-encrypted message, it is readable wherever the device

stores its SMS. The code is also transmitted twice; from the server to the user, and then from the client back

to the server.

Figure Four: OTP via SMS (generated at server side)

This achieves a higher level of security than standard password authentication because of the use of this

second channel of communication – meaning the potential attacker will have to gain access to both channels

to log in. However, today’s smartphones reduce the effectiveness of this security concept by reducing the

two channels needed in a feature phone scenario down to one. Today, it is likely that the device asking for

the code is the same as the one receiving it to log in; which of course then reduces the security (and the

point) of the separate channels.


2.2.2. OTP generator (Figure Five)

The second method is wheret the OTP is generated on behalf of an OTP device. Here the code is generated

offline and transmitted only once, from the client to the server. In this example, the OTP device is most often

a card reader or USB key. In a mobile environment, the OTP device can be stored within the handset’s

Secure Element.

So again, added assurance comes from this second device. However, if the OTP generating device is the

same as the device running the application users are logging into, the security improvement is considerably

diminished.

This is particularly relevant in a mobile environment where a smartphone (for example) is used as both

access point and OTP device. From a top level architectural perspective, both factors should independent of

the resource being used to authenticate the service. And if you’re using the mobile phone as the OTP

generator (resource), it isn’t.

And then there’s the user experience. It is rather impractical in many situations to retrieve a passcode with

an application and then copy it into another application on the device. So security becomes a compromise,

with users often choosing convenience over assurance – and that’s when they are most at risk. Similarly

services that offer this kind of dual factor authentication may be shunned by today’s ‘one-click’ consumers.

And that can have significant repercussions for the adoption of mobile services.

Figure Five: OTP via OTP generator


2.3. Public Key Infrastructure (PKI) authentication

Today, the strongest level of security is achieved through Public Key Infrastructure (PKI). Here every party is

known to each other through the use of unique certificates. Indeed, PKI is an internationally accepted

combination of hardware, software, people, policies, and procedures needed to create, manage, distribute,

use, store and revoke digital certificates (Figure Six).

Secure online services based on PKI support user Identification, user authorization and transport channel

encryption. The user is verified with their electronic signature. Only they are able to initial a transaction, and

once they do that communication is encrypted using certificates. Two factor authentication is achieved by

combining the user’s PIN number or code with the ’certificate’ they are carrying with them on the device.

For example, user wants to login to a web service (either over Wi-Fi or the mobile network) so enters their

username. The service provider checks the username against the corresponding account then creates a

document signed with that service provider’s certificate. The document is sent with a signing request to the

user’s device. The device authenticates the signed document and if the service provider’s signature is valid

the end user is prompted to enter their PIN – and so signing their certificate. Assuming the PIN is valid the

document is signed again and sent back to the service provider who receives the end users electronic

signature grants access.

As discussed, this level of authentication heightens security levels. However, just as in the previous

example, PKI suffers from serious limitations if a Secure Element is not used to store user credentials. For

example, user credentials (certificates and keys) can be easily manipulated at the client side.

Figure Six: PKI’s Authentication


2.4. Moving to a Secure Element

So, with a lack of security inherent in these ‘solutions’ what is the best way forward for service providers and

brands?

For the SIMalliance the most effective route to securing today’s generation of smart open devices is through

the adoption of a Secure Element within mobile security architectures. The most common Security Element,

and indeed the most widely used secure platform in the world, is the SIM. But with deployment flexibility and

choice now key in today’s market, the same level of functionality and security can be delivered through other

Secure Element form factors – and this unique combination of hardware and software can be hardwired

directly into the handset or added through a secure Micro SD card.

And crucially, it can be securely managed remotely– a feature that’s critical when one considers the potential

number of devices in the field today. The different form factors and remote administration will be further

described in the next chapters. Deciding which Secure Element form factor to use will depend on the

business model, with best-fit options for operators, financial services providers, governments and over-the-

top players based on use case.

For the SIMalliance, the introduction and wide scale adoption of the Secure Element as the de facto security

for mobile devices and applications will significantly increase levels of assurance across the mobile sector,

combating the ever-growing sophistication and volume of attacks much more comprehensively and much

more successfully than the conventional solutions discussed above. It will and lock down identity and content

from prying code, and in doing so provide the catalyst for a new generation of mobile services from a

growing community of enterprise, retail and government applications and service providers.


Part 3: Integrating a secure element into mobile internet service architectures

3.1. The mobile internet market and white paper scope

The growth of the mobile community and the myriad of services and applications available to end-users

require new approaches in security and authentication methods - that much is clear. However, because of

the increasing fragmentation of the applications eco-system and the entry of a host of new players, being

able to deliver a cohesive security strategy is predicated on effectively segmenting the market into core

areas of focus.

For the SIMalliance, these areas are illustrated in Figure Seven below:

Figure Seven: SIMalliance’s mobile internet market segmentation

In each of these focus areas, the different market dynamics at play further complicates the picture and

creates a confusing mesh of solutions, vendors and service providers, each with their own challenges,

agendas and solutions. When it comes to the mobile eco-system nothing is simple.

For example, the ecosystem players range from traditional broadcasters, mobile network operators, financial

institution, utilities companies, FMCG retailers, emerging online applications and service providers,

consumer cloud service providers, search companies, public authorities and OEM device manufacturers.

The list goes on.

In certain circumstances these players come together to support one another and develop or extend the

scope and attraction of mobile services; Google’s recent licensing of contactless payment card technology to

support its mobile wallet is a good example of collaboration between potentially competing industry giants. In

other areas, the rise of what is commonly termed the ‘over-the-top’ internet players – be that Facebook,

Google or the Microsoft-owned Skype – is creating significant tension within the mobile space as old and

new players collide and compete for the hearts and wallets of the consumer.

For the SIMalliance, a not-for-profit association, the task is how to deliver solutions and services that protect

users while offering revenue opportunities and shared benefits across the mobile ecosystem. Which means

assisting these new ecosystems – which are reforming around operators, financial services and internet

players – to implement clear strategies to assure security across the length and breadth of their service and

applications portfolios, and advising on the best way forward.


In helping to do just that, the following sections will build on the authentication discussions above and,

focusing specifically on the User-Centric Security focus, detail how brands and service/application providers

can best utilize the Secure Element in their service deployment strategies.

Future papers will analyze Corporate Security and Content Protection, while Mobile Transactions and M2M

are covered by other SIMalliance Workgroups. For more information, go to www.simalliance.org

3.2. Introducing the different Secure Elements

The Secure Element is the component within the connected mobile device that provides the application, the

network and the user with the appropriate level of security and identity management to assure the safe

delivery of a particular service.

Today, the Secure Element is a combination of hardware and software, built to exacting standards and

developed and delivered in controlled white room manufacturing environments.

Going back almost three decades, the most common secure element

within the mobile space, and indeed the most widely used security

platform in the world, is the SIM - or more accurately in today’s world,

the Universal Integrated Circuit Card (UICC).

But the Secure Element can also be an Embedded Secure Element or

a Secure Memory Card (Secure Micro SD) – both of which can also be

delivered simply and cost effectively into the mobile environment.

• The Secure Micro SD form factor holds an embedded chip

which can be used as a SE, along with a Flash memory. This form

factor is usually distributed by the branded service provider directly to

the end user audience.

• Embedded Secure Element (eSE): a security component

embedded in a mobile device and capable of storing and handling

business and personal information in a secure manner. This dedicated

smart card chip is embedded in the device at the time of manufacturing.

Deploying a Secure Element-based security architecture eliminates the inherent security limitations of single

factor password-based authentication systems by adding that critical second level. While PKI is the best

possible authentication method, it is only truly secure when the certificates are stored in the SE. Simply

storing the certificates or keys on the device (and off the SE) make them vulnerable to access. Storing them

on the SE eliminates this risk.

Connecting the application to the Secure Element within the device is the only way to guarantee the highest

levels of security for connected mobile devices in an IP world. And it is for this reason that the SIMalliance is

encouraging the o/s, application developer and mobile community at large to come together to utilize these

essential security features - that in many case are already available on the mobile device through the UICC

(SIM card).

http://www.simalliance.org/


3.3. Introducing the Trusted Service Manager

One of the main advantages of the Secure Element is its

remote management capabilities. Its life cycle is

managed by a server called TSM (Trusted Service

Manager). The TSM is the trusted third party who

provides trusted services to the application issuer and

the owner of the SE.

The TSM handles the provisioning and management

processes so that application issuers do not need to

deal with multiple entities, phone models, operating

systems; and MNOs do not need to deal with multiple

application issuers.

The TSM role could be played by many different entities, including the MNO, the application issuers, the

personalization bureau, the payments processor, or some other neutral third party. But whatever the provider

the primary role of the TSM remains the same; to facilitate management of the credentials and/or secure

applications on the various SEs. However, they can also be responsible for the activation, provisioning and

life-cycle management of secure applications and/or their credentials.

Core elements of the process, and so of the TSM relationship, include preparing the data and accessing the

appropriate security keys required to initially provision the credentials – and to keep it updated once in the

‘field’.

3.4. Introducing the SIMalliance Open Mobile API

Of course, there is a big difference between having the security on the device and actually maximizing its

value – particularly if the Secure Element in question is not an operator-owned UICC or there is a business

requirement to develop multi-issuer models on the single Secure Element. Secure, standardized access is

key which is why the SIMalliance has developed its Open Mobile API initiative, and in doing so is offering

that missing link between the Secure Element and the secure mobile applications nested on the device.

From a business perspective the creation of this common API is a very positive step forward. It delivers a

single, consistent specification and interface across multiple operating systems – and in doing so eliminates

the need to reengineer applications to each specific operating system.

This of course then results in reduced application development costs,

time-to-market and time-to-revenue.

From a security perspective, connecting the applications to the Secure

Element delivers a higher security while the credentials (passwords,

codes, license keys, etc.) are stored in a secure environment and the

access to it is regulated. In this ideal scenario (system setup) the

credentials are never exposed to the outside world in plain text.

The SIMalliance Open Mobile API Specification describes how a mobile

application running on an open smartphone operating system can access

a Secure Element. In Release 1.2, the specification describes the

process of managing the transport layer to allow applications to transmit

messages to the SE. The format of those messages is called APDU


(Application Protocol Data Unit). Future versions will further streamline development time and cost by

defining a common set of reusable high level services, such as file encryption. One example could be an E-

Mail application that uses a signature function nested on the SE to encrypt the content.

Having a specific API for accessing the Secure Element enhances the overall usability and opportunities for

the platform for using services, including:

NFC services

Payment services (e.g. mobile Wallet)

Ticketing services and public transport

Access control

ID services

Identity management

Loyalty services

Diagram Eight below illustrates the architecture covered by the SIMalliance Open Mobile API.

Figure Eight: Architecture covered by SIMalliance’s Open Mobile API

…

Further

Functions

Further

Functions

Mobile Applications

Transport

Access C

on

tro

l

SIM Plug in

APIs

Gen

eri

c

Tra

nsp

ort

Crypto API

(PKCS / JCE)

Crypto

provider

File

Man

ag

em

en

t

Secu

re

Ch

an

nel

Secu

re

Sto

rag

e

…

ASSD Plug in

Secu

re E

lem

en

t

Pro

vid

er

Inte

rface

Further SEFurther SE

Mobile Device

Secure Elements (e.g. SIM, Secure µSD, …)

SE

providerTest SpecificationsMobile Applications

Storage File systemFurther

Functions

Access

Control

Tra

nsp

ort

Layer

Serv

ice

Layer

Ap

pli

cati

on

Layer


Part 4: Applying the Secure Element Model to user centric security

Having agreed that the Secure Element is the most appropriate way of managing mobile device and

application security, the question is how to deliver this into a market of multiple players, scenarios and

business models; in effect, how service providers can launch a service that utilizes the protection afforded by

the Secure Element.

As discussed, while there are multiple use cases, this paper focuses specifically on user-centric security;

how we can use the Secure Element to protect personal data, applications and mobile internet services.

Typically, in this end-user service environment the Secure Element-enabled service will be deployed in three

ways:

1. On the UICC, distributed and owned by the mobile operator

2. On a secure microSD card, distributed by the service/application provider (for

example a bank or retailer)

3. On an embedded Secure Element within the handset, distributed by the OEM

The best way to bring clarity to these discussions is by following the deployment journey of a service that

demands the kind of security afforded by the Secure Element. So in this case we will use a fictional photo-

sharing service that we are calling ShareZone.

Understanding ‘ShareZone’

ShareZone started life as a photo-sharing portal based in the cloud and offering access through

the PC. Today ShareZone has moved on and now offers a converged solution via an app store

to allow smartphone users to upload and share their picture on the move. ShareZone also

allows users to manage their online picture database as well as viewing connected friends’ videos and

pictures.

ShareZone is an over-the-top brand offering its services via an operator’s mobile network. It sees huge

opportunity to gain market share and subscribers through a mobile service but needs to assure the highest

level of security. At the same time, it needs to deliver a seamless user experience and convenient access.

The people behind ShareZone understand the need to move beyond simple password and username

authentication and are exploring different models (in line with the distribution models above) that will allow

the application to retrieve credentials from the Secure Element within the handset to authenticate and

validate access for its users.

4.1. Model One: secure authentication where the SE is the UICC

The UICC is the most widespread Secure Element and is available in every mobile phone. Even if some

countries use CDMA (3GPP2) protocols where the UICC is not mandatory, the arrival of LTE/4G networks

will make its use mandatory for network authentication. So from ShareZone’s perspective this option would

allow it to reach almost all its users across the globe.


4.1.1. So how does it work?

Step One: MNO agreements

The UICC is owned by the mobile network operator – and there are over 400 worldwide. This highlights a

problem of scale because in theory ShareZone must reach agreement with each one to install the service on

their cards. In practice, however, things are a little easier as it will typically reach agreement with the biggest

operators in the largest markets first; and so be able to address hundreds of millions of users quickly.

Step Two: user registration

New mobile users (or existing PC users) sign up directly to the ShareZone mobile service by creating an

account on the web. However, in this mobile scenario ShareZone could, with the right agreements in place,

be marketed directly by the mobile operator and sign-up offered on the operator’s own website.

Step Three: certificate distribution

ShareZone provides the user certificate to the network operator for distribution. The certificate is created as

soon as the user opens a ShareZone account and managed by the operator to allow seamless,

authenticated access to the service on the Secure Element.

Step Four: SE management

The operator utilizes a Trusted Service Manager (TSM) to store and manage the certificate lifecycle and

applications on the Secure Element via an Over-The-Air (OTA) platform.

Step Five: mobile application access UICC

The ShareZone App access the UICC after user PIN verification and gets access to the credentials that will

be used to establish the digital signature. The App can access the UICC thanks to the Open Mobile API

included in the OS distribution.

Step Six: secure connection to SE

After successful user PIN verification the application establishes a secure connection based on the keys

stored in the UICC, authenticating the user by accessing the encrypted/signed information in the certificate.


4.1.2. Benefits for the Mobile Network Operator

From an operator perspective, having the ShareZone service on its UICC means it is able to leverage

additional revenues from ‘renting’ ShareZone space on its cards and by managing the third party certificates

needed to provide authentication, validation and access.

4.1.3. Benefits for the Service Provider (ShareZone)

From ShareZone’s perspective, it benefits significantly from access to a proven business model. Today’s

UICCs already host secured third party data; NFC services have been successfully deployed where

operators store, manage and update applications over-the-air on behalf of payment and transport authorities.

ShareZone also benefits from low cost distribution, since renting space and services of an existing Secure

Element is less expensive than distributing and managing a new one; not to mention the fact that ShareZone

has instant access to a pool of millions of existing subscribers and is able to take advantage of the network

operator’s powerful marketing machine.

4.1.4. Benefits for the End User

Quite simply, the end user enjoys a seamless experience. They sign up and the service is delivered – with

the highest levels of security. Crucially, utilizing the UICC as the Secure Element means that users don’t

need to use additional devices or cards to enable secure access to the service.

4.1.5. Key considerations

The network operator is able to provide security services to different service providers on a

single UICC.

The application can access the security functions of the UICC through the SIMalliance

open mobile API.

Using the SIMalliance Open Mobile API, ShareZone developers can rapidly create an

application able to access the UICC without the need for UICC specific

knowledge/language.

The various secure elements (UICC, eSE, µSD) are certified and audited in order to

ensure the secure storage and handling of credentials.

4.1.6. ShareZone as an ID provider (OpenID)

ShareZone is a trusted brand. Many internet users have a ShareZone account and would be comfortable

with using its account information to log in to other connected services. Once ShareZone deploys its

authentication framework, it can leverage it to provide secure authentication for other service and application

providers. This will allow user access to other services using ShareZone’s credentials.


4.1.7. The ID broker concept

As discussed above, signing agreements with over 400 global mobile network operators can be a major

barrier for smaller service and applications providers. The success of UICC based authentication model,

could led to the creation of ID brokerage services. The ID broker would sit between ShareZone and the

mobile network operator community and manage access to all the UICCs belonging to a group of operators

– either at a single country or international level. In doing so his would solve ShareZone’s initial challenges of

scale and reach.

4.2. Model Two: direct issuance of MicroSD cards

In the same way as with the operator distribution model, the ShareZone service is designed to make use of

other Secure Elements holding the credentials and log-in information of the user. However, in this scenario

ShareZone wants to own the Secure Element so another form factor is required.

For costs and distribution reasons deploying the Secure Element on a secure microSD is the most

appropriate option here.


Step One: registration

Registration for Sharezone can be done via its website or at the retail outlet. In doing so, the consumer will

receive a personalized microSD.

In the first scenario ShareZone will manage the relationship with the user; gaining the user’s credentials

through the information given on log in to the website. This data is then stored on Sharezone’s secure

servers (or a third party-managed data centre), and linked to the microSD card; which is likely to be

distributed by mail.

The link between the user credentials and the microSD card is established through the generation of an alias

ID that is associated to the microSD’s unique serial number. In this case there is no way to proof the real ID

of that user.


By registering and collecting the microSD at a bank branch or retailer outlet, ShareZone is able to establish a

link with the real ID of the User and its microSD. The credentials will be stored directly in the microSD.

Step Two: installation

Now that the user has registered and received their microSD card, the ShareZone app can be installed on

the device that contains the microSD. With the implementation of the guidelines of the SIM Alliance Open

Mobile API taken into account, this ShareZone app is able to access the microSD.

Step Three: verification

Every time the ShareZone app requests a signature’s verification, the microSD will be accessed and

ShareZone will only grant access to their services if verification is performed correctly.

Step Four: usage

With registration complete the user can securely use the ShareZone app confident in the knowledge their

credentials are safely stored in the microSD Secure Element. Only the issuer/owner of the microSD will be

able to address the Secure Element from the ShareZone app. And should any updates be required during its

life-time, a TSM should be put in place to assure comprehensive management in the field.

4.2.2. Benefits for the Service Provider

With no intermediary, ShareZone is in complete control of distribution channels and of its customer base.

When the distribution scheme is in place and potentially a TSM is connected, the ShareZone will be able to

introduce partners into its scheme and so increase incremental revenue now it has the infrastructure in

place. The additional of partners with associated compelling services may also make the ShareZone service

more attractive to consumers. And of course, consumers and brand will both benefits from the high levels of

security afforded by the Secure Element.

4.2.3. Benefits for the End User

The flexible distribution model will allow the end user to access the ShareZone service from a wide variety of

channels – this ease of purchase should increase market adoption. Significantly, the microSD card can also

be used by the end user as a storage device for a host of downloaded applications.

4.2.4. Limitations

During the on-line registration process no ‘real’ identity is required. For example, users could use a dummy

name which would mean that ShareZone won’t have true visibility of the end-user. Other schemes can be

put in place to capture real details; for example when the end-user obtains the microSD they must identify

themselves, or the on-line registration is linked to an already existing and proven identity provider. Both of

these solutions will however eliminate the convenience factor and potentially stifle adoption.

And while architecture is only able to deploy a limited number of services, ShareZone must establish a

relationship with a TSM in order to update the services – which can be an expensive option.

4.2.5. Key Considerations

Securing the microSD


The microSD is developed and personalized in a secure environment to assure complete integrity of the card

and the data held within (for example, the keys that will be used later in life-time for a certificate upgrade).

Integrating the app and Secure Element

The ShareZone application is developed using the SIMalliance Open Mobile API to assure seamless access

to the Secure Element on the device. (The ShareZone app cannot be used without the presence of the

microSD in the device).

Managing the Certificate

Depending on the service, the certificate stored in the microSD may be upgraded, or others may be

introduced, giving access to additional services. A TSM should be used for this, although this will depend on

the services deployed. For example, a banking service is unlikely to want to share the same Secure Element

as ShareZone, while other services will be less strict in terms of architecture. Then it may as well be that an

upgrade solution based on TSM is too expensive and it’s more interesting to distribute a new microSD

towards the user.

4.3. Model Three: eSE - SE distributed by OEM

In this scenario the device manufacturer (OEM) has embedded a Secure Element directly into the hardware

of the device.


Step One: user and device registration

Having bought the mobile device with an embedded SE, and opened a ShareZone photo sharing account,

the user’s identity will have been checked and mobile device registered. This ensures that each time the

user logs in, each session will be completely secure and a private content protection feature enabled to

make sure that photos will only be shared and transmitted to other end users with the permission of the user.

Within the registration process the end user has published their device or eSE serial number on the their

ShareZone account.


Step Two: software download

The download of the device specific application can be initiated directly from ShareZone or downloaded by

the end user himself. Another option is to offer the application preloaded on the device if, for example,

ShareZone is also distributing the device.

Step Three: credential provisioning to eSE

During registration process, ShareZone has recognized the targeted mobile device, and its serial number is

transmitted to the TSM service for credential distribution. The TSM then transfers the credentials (for

example: the application license code, certificate, etc.) to the embedded Secure Element on the end user

device and the service is ready to go.

Step Four: access to eSE

The downloaded and installed ShareZone application has access to the eSE (via the Open Mobile API, for

example) where the SP and end user credentials are securely stored. To grant access to the eSE the end

user has to enter their PIN.

Step Five: credentials verification and content access

When ShareZone application on the device is started, the credentials (certificates) on the eSE are verified

and the access to contend is granted.

4.3.2. Benefits for the Mobile Network Operator

From a mobile operator perspective, the carrier is able to generate a new revenue stream by acting as the

identity and security provider. Significantly, they are also able to increase their service offering and so gain

competitive advantage in their markets.

4.3.3. Benefits for the Service and Applications Provider

ShareZone is able to concentrate on developing its service rather than on distribution and management –

which of course happens on a totally secure environment.

4.3.4. Benefits for End User

Similarly, they will be able to access ShareZone with a single PIN number – as the device holding the SC is

automatically identified - safe in the knowledge they are protected by advanced two factor authentication.

And should the device be lost or stolen, all services can be quickly disabled over-the-air.

4.3.5. Limitations

From a management perspective, agreement must be reached between ShareZone, the handset provider

and the operator (if the latter acts as ID provider). This can be a complex process. And should the user churn

their handset, they will instantly lose their mobile service and have to download the app for their new mobile.


Part 5: Conclusion

With attacks on the mobile internet connected handset growing in pace and sophistication, application

providers must look beyond existing methods of user authentication. The Secure Element is recognized as

the leading security option for today’s generation of mobile devices, offering two-factor authentication without

the challenges associated with older methods.

The real question is less about whether to adopt and utilize the Secure Element, but which deployment

option to choose. Clearly, as an applications and service provider, understanding your business case and

capabilities is key to making the right decision. But decide you must if you want to maximize the

opportunities, and minimize the risks of service delivery in today’s challenging markets.


Part 6: Abbreviations and definitions

Abbreviation What it stands for

SE Secure Element

AP Application Programming Interface

APDU Application Protocol Data Unit (as per ISO/IEC 7816-4)

OTP One Time Password

WPKI Wireless Public Key Infrastructure

OTA Over The Air

IMEI International Mobile Equipment Identity

OEM Original Equipment Manufacturer

TSM Trusted Service Manager

Term Definition

Secure Element

The Secure Element (SE) is an embedded or removable token of security within the

mobile device built in clean room environments and featuring a unique combination of

hardware and software to create the most secure environment in which to deliver

mobile services manageable remotely. The SIM is the most widely distributed Secure

Element, in the world with over 18bn units shipped since its inception.

OTP

Strong authentication method that provides a second factor of authentication by the

means of a single-use password provided by an external device, in addition to the

password known by the user. The OTP can be generated by a user device or by the

authentication server.

Open Mobile API An API specified by the SIMalliance allowing a mobile application to access the

resources of a Secure Element whatever the operating System

Digital Signature

A digital signature is a scheme for demonstrating the authenticity of a digital message

or document. A valid digital signature allows the Service Provider to verify that he

message was created by a known user, and that it was not altered in transit. The user

will use its private key to sign (encrypt) the message (digital certificate) and the Service

Provider will use the user’s public key to verify (decrypt) the message.

WPKI

The Public Key Infrastructure is a combination of hardware, software, people, policies,

and procedures needed to create, manage, distribute, use, store and revoke digital

certificates. In a Wireless PKI, a mobile is used to store the credentials and sign the

digital certificates.

Certificate

A public key certificate or digital certificate is an electronic document which uses a

digital signature to bind a public key with an identity. The certificate can be used to

verify that a public key belongs to an individual. It provides a strong authentication

mechanism for a Service Provider.

TSM

The TSM is the Trusted Third Party who provides trusted services to the application

issuer and the owner of the SE. The TSM handles the provisioning and management

processes so that application issuers do not need to deal with multiple entities, phone

models and operating systems. MNOs do not need to deal with multiple application

issuers.

OTA Platform Server platform that allows remote access and management of a SE

IMEI Unique identifier of a mobile phone

Application Device/Terminal/Mobile application: an application which is installed in the mobile

device and runs within the mobile device.

secure authentication for mobile internet...

Documents