secure authentication for mobile internet services · network vulnerability ... 85% of new mobile...
TRANSCRIPT
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
Secure Authentication for Mobile Internet Services December 2011 – V1 - 3/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.
Secure Authentication for Mobile Internet Services December 2011 – V1 - 4/24
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
Secure Authentication for Mobile Internet Services December 2011 – V1 - 5/24
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
Secure Authentication for Mobile Internet Services December 2011 – V1 - 6/24
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.
Secure Authentication for Mobile Internet Services December 2011 – V1 - 7/24
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
Secure Authentication for Mobile Internet Services December 2011 – V1 - 8/24
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.
Secure Authentication for Mobile Internet Services December 2011 – V1 - 9/24
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
Secure Authentication for Mobile Internet Services December 2011 – V1 - 10/24
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
Secure Authentication for Mobile Internet Services December 2011 – V1 - 11/24
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.
Secure Authentication for Mobile Internet Services December 2011 – V1 - 12/24
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.
Secure Authentication for Mobile Internet Services December 2011 – V1 - 13/24
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).
Secure Authentication for Mobile Internet Services December 2011 – V1 - 14/24
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
Secure Authentication for Mobile Internet Services December 2011 – V1 - 15/24
(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
Secure Authentication for Mobile Internet Services December 2011 – V1 - 16/24
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.
Secure Authentication for Mobile Internet Services December 2011 – V1 - 17/24
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.
Secure Authentication for Mobile Internet Services December 2011 – V1 - 18/24
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.
Secure Authentication for Mobile Internet Services December 2011 – V1 - 19/24
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.
4.2.1. So how does it work?
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.
Secure Authentication for Mobile Internet Services December 2011 – V1 - 20/24
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
Secure Authentication for Mobile Internet Services December 2011 – V1 - 21/24
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.
3.3.1. So how does it work?
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.
Secure Authentication for Mobile Internet Services December 2011 – V1 - 22/24
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.
Secure Authentication for Mobile Internet Services December 2011 – V1 - 23/24
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.
Secure Authentication for Mobile Internet Services December 2011 – V1 - 24/24
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.