Secure Authentication for Mobile Internet Services · 1.1 The vulnerability of the mobile ... and...

Secure Authentication for Mobile Internet Services Critical Considerations

December 2011 – V1

Secure element architects for today’s generation Secure Authentication for Mobile Internet Services 2

Security, Identity, Mobility

Table of Contents

Executive summary ....................................................................................... 3

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

2. Today’s challenges .................................................................................. 6

2.1 User/password authentication ........................................................................................... 6

2.2 One Time Password (OTP) authentication ........................................................................ 7

2.3 Public Key Infrastructure (PKI) authentication ................................................................... 9

2.4 Moving to a Secure Element ........................................................................................... 10

3. Integrating a secure element into mobile internet service architectures . 11

3.1 The mobile internet market and white paper scope ......................................................... 11

3.2 Introducing the different Secure Elements ....................................................................... 12

3.3 Introducing the Trusted Service Manager ........................................................................ 13

3.4 Introducing the SIMalliance Open Mobile API .................................................................. 13

4. Applying the Secure Element Model to user centric security .................. 15

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

4.2 Model Two: direct issuance of MicroSD cards ................................................................. 18

4.3 Model Three: eSE - SE distributed by OEM .................................................................... 20

5. Conclusion ............................................................................................. 22

6. Abbreviations and definitions ................................................................. 23



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.



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.



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

Traditional mobile security is most often based on a very conventional log-in and password

authentication - on ‘something you know’ such as a password or PIN number. This is single

factor authentication and it’s easy to deploy and great for offering secure email access on the

move.

However, 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

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.



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



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.

…

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

ns

po

rtL

aye

rS

erv

ice

La

ye

rA

pp

lic

ati

on

La

ye

r

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



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:

On the UICC, distributed and owned by the mobile operator

On a secure microSD card, distributed by the service/application provider (for example a bank or

retailer)

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.



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.



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 Services · 1.1 The vulnerability of the mobile ... and...

Documents

Transcript of Secure Authentication for Mobile Internet Services · 1.1 The vulnerability of the mobile ... and...