Secure Authentication for Mobile Internet Services

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

Secure element architects for today s generation Secure Authentication for Mobile Internet Services 3 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 element architects for today s generation Secure Authentication for Mobile Internet Services 4 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.

Secure element architects for today s generation Secure Authentication for Mobile Internet Services 5 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.

Secure element architects for today s generation Secure Authentication for Mobile Internet Services 6 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

Secure element architects for today s generation Secure Authentication for Mobile Internet Services 7 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 element architects for today s generation Secure Authentication for Mobile Internet Services 8 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 element architects for today s generation Secure Authentication for Mobile Internet Services 9 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 element architects for today s generation Secure Authentication for Mobile Internet Services 10 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.

Secure element architects for today s generation Secure Authentication for Mobile Internet Services 11 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

Secure element architects for today s generation Secure Authentication for Mobile Internet Services 12 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).

Secure element architects for today s generation Secure Authentication for Mobile Internet Services 13 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

Transport Layer Access Control Service Layer Generic Transport File Management Secure Channel Secure Storage Secure Element Provider Interface Application Layer Secure element architects for today s generation Secure Authentication for Mobile Internet Services 14 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. Mobile Applications Mobile Applications Test Specifications SE provider APIs Crypto API (PKCS / JCE) Crypto provider Transport SIM Plug in ASSD Plug in Further SE Further SE Mobile Device Storage File system Access Control Further Further Functions Further Functions Functions Secure Elements (e.g. SIM, Secure µsd, ) Figure Eight: Architecture covered by SIMalliance s Open Mobile API

Secure element architects for today s generation Secure Authentication for Mobile Internet Services 15 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.

Secure element architects for today s generation Secure Authentication for Mobile Internet Services 16 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

Secure element architects for today s generation Secure Authentication for Mobile Internet Services 17 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.

Secure element architects for today s generation Secure Authentication for Mobile Internet Services 18 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 element architects for today s generation Secure Authentication for Mobile Internet Services 19 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.

Secure element architects for today s generation Secure Authentication for Mobile Internet Services 20 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. 4.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.