GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
CPAS04 Authenticator Options Version 1.0 11 November 2015
This is a Non-binding Permanent Reference Document of the GSMA
Security Classification: Non-confidential Access to and distribution of this document is restricted to the persons permitted by the security classification. This document is confidential to the Association and is subject to copyright protection. This document is to be used only for the purposes for which it has been supplied and information contained in it must not be disclosed or in any other way made available, in whole or in part, to persons other than those permitted under the security classification without the prior written approval of the Association.
Copyright Notice Copyright © 2016 GSM Association Disclaimer The GSM Association (“Association”) makes no representation, warranty or undertaking (express or implied) with respect to and does not accept any responsibility for, and hereby disclaims liability for the accuracy or completeness or timeliness of the information contained in this document. The information contained in this document may be subject to change without prior notice. Antitrust Notice The information contain herein is in full compliance with the GSM Association’s antitrust compliance policy.
V1.0 Page 1 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options Table of Contents
1 Introduction 3 1.1 Overview 3 1.2 Scope 3 1.3 Abbreviations 3 1.4 References 5 2 Level of Assurance (LoA) 5 3 Mobile Connect Pluggable Architecture 5 4 Inventory of Candidate Authenticators 7 4.1 Seamless Authenticators 8 4.1.1 Header Enrichment-based Authenticators 8 4.1.2 MO SMS-based Authenticator 10 4.1.3 Device Agent/Library-based Authenticator 11 4.2 SIM Applet-based (using MSSP) Authenticator 12 4.2.1 SFRA Recommendations on Mitigations 13 4.3 Fast Identity Online (FIDO) Authenticator 13 4.3.1 FIDO Authenticator Using SIM as the Secure Element 15 4.4 QR Code-based Authenticator 16 4.5 Network Initiated USSD-based Authenticator 17 4.5.1 SFRA Recommendations on Mitigations 18 4.6 SMS and URL-based Authenticator 18 4.6.1 SFRA Recommendations on Mitigations 19 4.7 Smartphone App Authenticator 19 4.7.1 Setup Mode 19 4.7.2 Authentication Mode 20 4.8 “Points in a Picture” App Authenticator 22 4.8.1 Authentication Mode 23 5 Other Potential Authentication Approaches 24 5.1 GBA: Generic Bootstrapping Architecture 3GPP TS 33.220 24 5.2 Secure Quick Reliable Login (SQRL) 25 5.3 Hybrid Authenticator 26 5.4 OTP Generated on the Device (HOTP)-based Authenticator 27 6 Account Chooser 27 7 SFRA Analysis of the key Authenticators 29 7.1 General mitigation recommendations from the SFRA analysis 36 Annex A Document Management 37 A.1 Document History 37 A.2 Other Information 37
V1.0 Page 2 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options 1 Introduction
1.1 Overview The GSMA Personal Data Programme is focused on positioning operators as trusted providers of identity services to third party service providers. Within this context, the programme identifies a set of propositions - including authentication, identity, attribute validation, attribute brokerage - that are collectively referred to as Mobile Connect.
This document identifies a number of different Authenticator options that an operator may choose to deploy and support. A separate document, CPAS8 [1], focuses specifically on the use of an applet on the SIM as an authentication option and is based around the ETSI Mobile Signature Service (MSS) specifications that enable a mobile operator deploying this authentication method to easily migrate to a full MSS solution in Step 2 (Identity & Attributes).
Step 3: Personal Step 2: data Centralising Iden ty & A ributes and controlling Step 1: Provision of iden ty services and your personal enhancement of digital transac ons through informa on Authen ca on the provision or verifica on of a ributes Enabling users to authen cate to and authorise transac ons within 3rd party services
Very strong LoA Authen ca on Current Age An -fraud Example (MC_A3) Very high address >18yrs no fica ons services Strong Authen ca on High (MC_A2) A ribute A ribute A ribute Mobile Verifica on Provision Publish Connect Medium (MC_AV) (MC_AP) (MC_APS) Simple Authen ca on capabili es (MC_A1) Low
Figure 1: Mobile Connect roadmap
1.2 Scope This document provides the description, architecture and functioning of the key authenticators for Mobile Connect along with the pros and cons and SFRA analysis for some of the authenticators. This is a non-exhaustive list of the key authenticators, as Mobile Connect uses a "Pluggable Authenticator" principle – where authenticators can be plugged- in to the system with minimum impact.
1.3 Abbreviations Term Description AuthN Authentication AuthZ Authorisation BSF Bootstrapping Server Function
V1.0 Page 3 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
Term Description BSS Business Support System CRM Customer Relationship Management DOB Date Of Birth ECC Elliptic Curve Cryptography ESB Enterprise Service Bus ETSI European Telecommunications Standard Institute FIDO Fast Identity Online GBA Generic Bootstrapping Architecture HOTP HMAC based One Time Password HSS Home Subscriber Server ID GW Identity Gateway IDP Identity Provider IMEI International Mobile Station Equipment Identity IMSI International Mobile Subscriber Identity JMS Java Messaging Service LoA Level Of Assurance LTE Long Term Evolution MFA Multi-Factor Authentication MO Mobile Originated MSISDN Mobile Station International Subscriber Directory Number MSS Mobile Signature Service MSSP Mobile Signature Service Platform NAF Network Application Function OIDC OpenID Connect OPCO Operating Company OSS Operational Support System OTA Over The Air OTP One Time Password QR Quick Response RFC Request For Comment SMSC Simple Message Service Centre SOAP Simple Object Access Protocol SP Service Provider SFRA Security and Fraud Risk Assessment SDK Software Development Kit SPCR Service Provider Customer Reference SQRL Secure Quick Reliable Login TEE Trusted Execution Environment
V1.0 Page 4 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
Term Description UAF Universal Authentication Framework UE User Experience UI User Interface USP Unique Selling Point
1.4 References Ref Doc Number Title [1] CPAS8 CPAS8 SIM Applet Authentication Specification [2] CPAS3 CPAS3 Level of Assurance Definition [3] CPAS6 CPAS6 Identity GW Functional Architecture [4] CPAS5 CPAS5 OpenID Connect Specification [5] CPAS13 CPAS13 Mobile Signature Service
2 Level of Assurance (LoA) The Level of Assurance describes the degree of confidence in the process of authentication and the level of identity proofing achieved in user registration for identity services. It provides assurance that the entity claiming a particular identity is in fact the entity to which the identity was assigned. The assurance is a reflection of the processes and the technical controls implemented.
The following table provides the four levels of assurance identified as per ISO/IEC 29115 Clause 6 in Mobile Connect.
Level Description 1 – Low Little or no confidence in the asserted identity. 2 – Medium Some confidence in the asserted identity. 3 – High High confidence in the asserted identity. 4 – Very High Very high confidence in the asserted identity.
Table 1: Levels of Assurance in Mobile Connect
More information on the definitions, security requirements, risk profile, threats and controls needed for the threats can be found in CPAS3 [2].
At runtime, an authenticator is selected based on the LoA indicated in the OpenID Connect (OIDC) request by the service provider along with the mobile operator implementation policies and additional context information (e.g. device capability, connectivity, eligibility, etc.).
3 Mobile Connect Pluggable Architecture One of the key aspects of the Mobile Connect architecture is the pluggability of the authenticators (known as authentication mechanisms). This is achieved through an abstraction architecture using a logical component, the Identity Gateway (ID GW), which
V1.0 Page 5 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options separates out the interface to the service provider and the authenticator implementation used providing functional control to the service provider to indicate the Level of Assurance needed for the use case and with the ID GW interfacing to the appropriate authenticator based on the configured policy. More information on the ID GW can be found in CPAS6 [3].
Figure 2: Mobile Connect logical architecture
The Mobile Connect architecture has 2 logical subsystems:
The Exposure subsystem The Authenticator subsystem
The Exposure subsystem is the entry point for the Mobile Connect architecture and contains the ID GW as the logical component. The Mobile Connect services are exposed by this subsystem using the OpenID Connect protocol, according to CPAS5 [4]. The Authenticator subsystem is an internal subsystem to Mobile Connect. The service providers do not interact with this subsystem directly but via the ID GW. This subsystem contains the authenticators selected and implemented within the Mobile Connect deployment. A number of different authenticators can be used, based on the LoA needed and the implementation choice of the mobile operator. One of the key architecture principles used in Mobile Connect is the pluggable authenticator principle, where the integration of the authenticators with the Mobile Connect system is done in a loosely coupled manner, using adaptors, so that the implementation of the integration can be abstracted within the adapters. The following diagram illustrates the logical architecture of the Authentication System through the ID GW components.
V1.0 Page 6 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
Figure 3: Identity Gateway functional components
4 Inventory of Candidate Authenticators This section identifies some of the authenticators that might be used within the Mobile Connect proposition as well as providing an indication of how they could be mapped to the levels of assurance defined within CPAS3 [2].
Level of Description Authentication Context Assurance 1 – Low Little or no confidence N/A (Out-of-scope) 2 – Medium Some confidence 1 Factor Authentication 3 – High High confidence 2 Factor Authentication 4 – Very high Very high confidence 2 factor Authentication + PKI (Step 2)
Table 2: Levels of Assurance
1 Factor Authentication (1FA). Authentication based on the entity having something (Something I have). E.g. the user has the device. 2 Factor Authentication (2FA). Authentication based on the entity having something and knowing something else (Something I have and Something I know). E.g. the user has the device. The user knows a PIN. Going forward, the factor of user knowing something may be replaced by the user is someone (Something I am). The authentication would be based on biometric attributes. Multi-factor Authentication (MFA). Authentication based on more than one factor (Something I have, Something I know and/or Something I am). This approach may be added in a later step for LoA4.
Authenticator LoA Seamless authenticators LoA2 HTTP Header enrichment-based Seamless authenticator LoA2 Mobile Originated (MO) SMS-based authenticator LoA2
V1.0 Page 7 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
Device agent/library-based authenticator LoA2 FIDO authenticator LoA3 FIDO authenticator using SIM as the secure element LoA3 Quick Response (QR) code-based authenticator LoA2 NI USSD-based authenticator LoA2 (OK), LoA3 (PIN) SIM applet authenticator LoA2 (OK), LoA3 (PIN) SMS and URL-based authenticator LoA2 Smartphone app authenticator LoA2 (OK), LoA3 (PIN) “Points on a Picture”-based authenticator LoA2 Future Authenticators Human Gait-based authenticator (keystroke behaviour) LoA2 Ambient sound-based authenticator LoA2 Voice signature-based authenticator LoA3 (Voice Code)
Table 3: Inventory of authenticators in the Mobile Connect architecture
NOTE: This inventory is not intended to be exhaustive. Other authenticators might be used given the pluggable nature of the Mobile Connect architecture.
More detail on each of the authentication mechanisms is included in the following sections.
4.1 Seamless Authenticators Seamless authenticators are generally authenticators using a single factor of authentication (1FA) where there is minimal, if any, user interaction involved in the authentication process. This authenticator is usually suitable for lower LoAs (LoA2) and the user consent is implicit or taken during the registration phase (the user is not explicitly asked to authenticate but is given access to a service by their mobile operator authenticating on their behalf).
There are three implementation approaches to delivering a seamless authentication user experience:
HTTP Header Enrichment-based implicit authenticator Application sending MO SMS to Application Backend Device agent/library-based authenticator
4.1.1 Header Enrichment-based Authenticators
4.1.1.1 Seamless Authenticator This authentication mechanism is a unique added value from mobile networks and provides a non-intrusive seamless authentication experience for the user as well as a smooth integration experience for service providers.
V1.0 Page 8 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
Figure 4: Seamless authenticator logical architecture
1. The application sends the OIDC request to the ID GW through the mobile operator core network. 2. The mobile operator core network authenticates the user and adds the authenticated Mobile Station International Subscriber Directory Number (MSISDN) in the request (HTTP Header). 3. AuthZ (authorisation) code is returned, without prompting the user to log in. 4. The user is effectively identified and authenticated by the fact that their device is attached to the network. Consent is assumed to be implicit here. 5. The app requests an Access Token and an ID Token using the AuthZ code. 6. The Access Token and ID Token are returned, asserting the identity of the user to the requesting application.
Pros Cons Seamless user experience for the user. Not compatible with HTTPS No additional integration needed for the service provider. Not suitable for higher LoA use cases It reuses the existing mobile operator core network authentication. 1 factor authentication established. The user has the device (which is authenticated using the network authentication). Security and Fraud Risk Assessment (SFRA) Feedback Simple and seamless. Inadvertent approvals where people accidentally tap on mobile device. This applies to legitimate and illegitimate access requests. It uses the mobile operator core network and existing security Device takeover. infrastructure. It uses authenticated identity information from the network. It uses operator security model.
V1.0 Page 9 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
Table 4: Pros and cons of the Header Enrichment-based authenticator architecture
4.1.1.2 SFRA Recommendations on Mitigation User education and clear messaging. ID proofing as part of robust business processes (step 2).
4.1.2 MO SMS-based Authenticator This approach uses MO SMS in conjunction with OIDC request.
Figure 5: MO SMS-based authenticator logical architecture
7. The app sends an OIDC request to the ID GW. 8. The app sends a MO SMS to a configured short code/virtual MSISDN, including the same state value as in the OIDC request. 9. The Simple Message Service Centre (SMSC) routes the SMS to a configured endpoint through the MSG GW. 10. The MSG GW calls an API (callback API, e.g. OneAPI) at the ID GW endpoint, passing the MSISDN state value. 11. The ID GW validates the state parameter, generates the PCR and returns back the OIDC response.
Pros Cons Seamless user experience for the user. Device dependent (for MO SMS). No additional integration needed for the service provider, except Short codes are local to the for using the device APIs to send SMS. operator, needing configuration per SMSC. It reuses the existing mobile operator network assets. Cost aspects for the SMS. It establishes 1 factor authentication: The user has the device (which is authenticated using the network authentication for sending MO SMS). Voice signature-based authenticator LoA3 (Voice Code)
V1.0 Page 10 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
Table 5: Pros and cons of the MO SMS-based authenticator architecture
4.1.3 Device Agent/Library-based Authenticator In this mechanism, a device agent/library is deployed to the user’s smartphone.
Figure 6: Device Agent/Library-based authenticator logical architecture
1. Setup phase. The first time the device attaches to the mobile operator network, the AuthN (authentication) Library sends a request to the mobile operator Authentication Service to get the seed – a shared secret, through the mobile operator core network, passing the International Mobile Subscriber Identity (IMSI) read from the device Software Development Kit (SDK). The authenticated MSISDN is added to the HTTP request.
a) The Authentication Service gets the associated IMSI from the network (for the MSISDN) and compares against the IMSI passed in the setup request. b) The Authentication Service stores the seed against the IMSI, MSISDN.
2. When an application needs authentication, it requests an authentication token from the AuthN Library.
a) The AuthN Library generates an OTP using the seed and the device/SIM identifiers (e.g. IMSI) based on the HMAC based One Time Password (HOTP) algorithm (RFC 4226). It then sends the OTP to the mobile operator Authentication Service to request the authentication token. The Authentication Service creates the same OTP using the seed and the device/SIM IDs. On validating, the OTP sends the authentication token back to the AuthN Library and to the application.
3. The application includes the authentication token in the login_hint of the OIDC call.
V1.0 Page 11 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
a) The ID GW validates the authentication token with the Authentication Service and gets back the MSISDN associated.
One key feature of this authenticator is that it is access-channel independent, and works with Wi-Fi as well.
Pros Cons Seamless user experience. Dependency on the device hosting the library and provision of a device SDK to the service provider (SP) to use in developing their app. Access-channel independent, working with Wi-Fi. Library deployment logistics is not straightforward. Seamless experience between mobile network and Wi-Fi.
Table 6: Pros and cons of the Device Agent/Library-based authenticator
4.2 SIM Applet-based (using MSSP) Authenticator CPAS8 and CPAS13 detail how a SIM applet can be used for authenticating the user to Levels of Assurance 2-3 [1] and to Level 4 in the future [5].
Figure 7: SIM applet authenticator logical architecture
1. The application (desktop, tablet or mobile phone) sends an OIDC request. 2. The ID GW sends a request to the Mobile Signature Service Platform (MSSP) using the ETSI 102 204 SOAP API. 3. The MSSP sends a Class 2 SMS through the SMSC. 4. The SIM applet pops up a user interface (UI) to present a Click OK experience for LoA2 or PIN experience for LoA3. 5. The applet validates the PIN (for LoA3). 6. The applet sends the authentication response with an encrypted MO SMS through the SMSC, MSSP to the ID GW. 7. The ID GW returns back with the OIDC response.
V1.0 Page 12 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
Pros Cons It reuses mobile operator assets – SIM, Dependency on SIM supporting Java Card applet SMSC. download and installation; higher LoA requires PKI support (SIM swap); SMS Over The Air (OTA) push mechanisms for distributing the applet not robust; logistical issues of distributing new SIMs. Simple user experience. It needs an MSSP to be deployed. PIN is always stored in the SIM, never Complex architecture, messaging and interaction transmitted. model. It works with LoA2, LoA3, LoA4. It does not work over non-mobile operator network (e.g. Wi-Fi). SFRA Feedback Well understood dynamic PIN/password Potentially standard imposter/DOS attack (imposter approach. uses own phone) if the initial ID and entered MSISDN are not coupled within the system. It uses the SIM as a secure element and a secure execution environment and builds on proven security model for telcos. The authenticator interactions and messages happen over an encrypted channel - both at the transport level and also at the application/messaging level-making MitM/MitB unlikely during authentication.
Table 7: Pros and cons of the SIM applet authenticator
4.2.1 SFRA Recommendations on Mitigations Augment MSISDN as user ID by another element requested from the user, which is captured during user registration (e.g. a spam code or date of birth, DOB) or based on the context (e.g. model of the phone or location), depending on the implementation.
4.3 Fast Identity Online (FIDO) Authenticator The FIDO Alliance has defined a framework that enables a local device authentication to be used for online approvals.
Figure 8: FIDO authenticator framework
V1.0 Page 13 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
The solution consists of:
an authentication client that is installed on the user’s device. an authentication server that integrates with the service provider (or mobile operator). an authentication protocol that allows the client and the server to communicate - Universal Authentication Framework (UAF) protocol: discovery, provisioning and authentication.
Unique key per user/authenticator/SP. High entropy asymmetric keys instead of passwords. Secrets not exposed to user (protection against phishing, key logging, etc.).
The following figure illustrates how the FIDO framework could be integrated into the Mobile Connect architecture as another authentication mechanism: FIDO authenticator logical architecture.
Figure 9: Fido authenticator framework
Pros Cons It uses the device capabilities (iris scans from Complex architecture. It needs specific protocol to the camera; voice recognition as well as be implemented between client and the server. fingerprint sensing where supported). Secrets and credentials are stored on the Dependencies on device based clients to provide device under user control, and never shared integration with device agents, capabilities. outside. SPs can discover the available authenticators on the device. Users and SPs can get assurance from the attestation process/attestation server about the authenticator implementation. Option of using the SIM for storing the FIDO FIDO uses Elliptic Curve Cryptography (ECC) keys - business opportunity and/or Unique which reduces key size, but having a unique key Selling Point (USP) for mobile operators. for each SP will take up a lot of SIM memory. Alternative approach is to encrypt the keys, store them on the handset and use the SIM to decrypt them (SIM only stores the key for decrypting the
V1.0 Page 14 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
FIDO keys rather than storing the FIDO keys themselves).
Table 8: Pros and cons of the FIDO authenticator
4.3.1 FIDO Authenticator Using SIM as the Secure Element
Figure 10: FIDO authenticator using SIM logical architecture
For this authenticator, the FIDO authenticator is implemented in the SIM (as an applet), and the FIDO client interacts with the FIDO authenticator using Open Mobile APIs.
1. The SP app sends an OIDC request to the ID GW. 2. The ID GW sends an authentication request to the FIDO server. 3. The FIDO server interacts with the application on the device using UAF protocol. 4. The application uses the FIDO stack in the device to perform the authentication and sends the authentication response back to the FIDO server, which is then sent back to the SP.
V1.0 Page 15 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
4.4 QR Code-based Authenticator
Figure 11: QR code-based authenticator logical architecture
1. The SP application sends an OIDC request to the ID GW.
a) The ID GW generates a QR code with a session ID and returns it to the application as part of the redirect flow. b) The application displays the QR code.
2. At the same time, the ID GW invokes the device app using the platform specific Push Messaging Service. 3. The application is then used to read the QR code. 4. The QR code contains a link back to the ID GW or an Authentication Server connected to the ID GW.
a) The ID GW validates the session ID and the user is authenticated. b) Response is sent to the SP.
Pros Cons Very simple user experience. The user experience (UE) is a disconnected UE as the user needs to actively use the device/camera for the app to read the QR code. It uses the device capabilities available in the smartphones.
Table 9: Pros and cons of the QR code-based authenticator
V1.0 Page 16 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
4.5 Network Initiated USSD-based Authenticator
Figure 12: USSD-based authenticator logical architecture
1. The application (desktop, tablet or mobile phone) calls an OIDC Authorisation towards the mobile operator ID GW to authenticate the user. 2. The mobile operator ID GW interacts with the USSD GW to send USSD messages. 3. The USSD GW sends a message to the device. 4. For LoA3, the device pops up a USSD menu to type the PIN. For seamless login, this can simply type 1 to authorise and 0 to cancel, if 1FA is sufficient. 5. The USSD message is sent back to the ID GW, through the USSD GW. 6. The ID GW service responds to the application.
This mechanism would support both the Click OK and the Enter PIN authentication modes (user’s PIN being validated by the ID GW). In terms of security:
USSD is plain text and presumably cannot be easily hashed as there is no device- side application. However, in theory USSD cannot be easily intercepted (man-in-the-middle attacks would entail significant effort and equipment). It would work for the Click OK service (LoA1) and possibly also for the Enter PIN variant (LoA3).
Pros Cons It uses the mobile operator assets. Minimal user experience. It is not dependent on a data channel, it It does not work for Long Term Evolution (LTE). works on the signalling plane. It works in roaming conditions, across devices. It potentially supports both LoA2 and LoA3. Transmission security possibly not secure enough for LoA3.
V1.0 Page 17 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
SFRA Feedback USSD messages can only be sent by the Potentially standard imposter attack (imposter uses mobile operator systems (ID GW) and not by own phone/own PIN) if the initial ID and entered other entities. MSISDN are not coupled within the system (why does it ask user to enter MSISDN if it is coupled?). If this is not the case then SIM Swap could be an issue.
Table 10: Pros and cons of the USSD-based authenticator
4.5.1 SFRA Recommendations on Mitigations Augment MSISDN as user ID by another element requested from the user, which is captured during user registration (e.g. a spam code or DOB) or based on the context (e.g. model of the phone or location) depending on the implementation.
4.6 SMS and URL-based Authenticator The authenticator is an enhancement to the SMS OTP-based approach where a disconnected user experience (the user needs to copy the OTP from the SMS to the web page) takes place. Here, the user has an in-device experience for authentication. This is more suitable for the LoA2 (Click OK) scenario. However, the URL in the SMS can be made to point to a page requesting the PIN, making a LoA3 experience. The SMS and URL authenticator is not recommended for LoA3.
Figure 13: SMS and URL-based authenticator logical authenticator
1. User accesses service provider's web page via PC, mobile phone, tablet or any Internet device over any type of Internet access (3G, WLAN, fixed line network, CATV, etc.). 2. The user clicks on the Mobile Connect link. 3. The SP app sends an OIDC request to the mobile operator ID GW in LoA2. An OTP in the form of a session ID/Transaction ID is added in the URL passed in the SMS.
V1.0 Page 18 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
4. The ID GW generates an OTP in the form of a session ID/Transaction ID and adds it in a URL, which is then sent to the authentication device of the user as an SMS. The user receives the SMS message. The user may need to unlock the mobile phone at this time. The user opens the SMS message and clicks the URL provided in the message. 5. The URL points to the ID GW (or an alternative Authentication Server connected to the ID GW). 6. The OTP in the URL is verified. The ID GW sends the authentication response to the SP.
Pros Cons It reuses mobile operator assets – SMSC. It is not suitable for higher LoA use cases. Simple user experience by embedding OTP SMS can be intercepted by apps on the device. in URL rather than requiring user to retype. SFRA Feedback Accidental approval for legitimate and illegitimate access requests. Device Takeover. Potentially standard imposter/DOS attack (imposter uses own phone) if the initial ID and entered MSISDN are not coupled within the system.
Table 11: Pros and cons of the SMS and URL-based authenticator
4.6.1 SFRA Recommendations on Mitigations ID proofing as part of robust business processes. Augment MSISDN as user ID by another element requested from the user, which is captured during user registration (e.g. a spam code or DOB) or based on the context (e.g. model of the phone or location), depending on the implementation.
4.7 Smartphone App Authenticator The authenticator uses the richness of the UE and device features available in the smartphone to enhance the experience when using the authenticator.
The smartphone app authenticator has a 2 step-mode process for its overall functioning:
Setup Mode (a one-time setup for the smartphone app) Authentication Mode
4.7.1 Setup Mode During the Setup Mode, the smartphone app is prepared for the Authentication mode.
V1.0 Page 19 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
Table 12: Smartphone app authenticator – Setup Mode logical architecture
1. The smartphone app connects using the mobile network. 2. The app reads the IMSI and the International Mobile Station Equipment Identity (IMEI) using the native SDK. 3. The app sends a setup request to the Setup Server through the mobile network. 4. The app passes the IMSI and IMEI in the request. 5. The mobile operator core network adds the authenticated MSISDN into the HTTP header. 6. The Setup Server asks the Operational Support System (OSS)/Business Support System (BSS) through internal APIs to get the associated IMSI and the IMEI of the attached device for the MSISDN. 7. The Setup Server validates the setup request from the smartphone app by comparing the IMSI, IMEI set from the 2 sources:
From the app in the request From the network
8. The Setup Server generates a token based on the IMSI, IMEI and MSISDN. 9. The token is sent in the response to the smartphone app. 10. The smartphone app securely stores the token. 11. The token is used for signing the interactions between the smartphone app and the authentication system at later stages.
4.7.2 Authentication Mode This mode is the operational mode for the smartphone app authenticator when it is used for authenticating the end user.
V1.0 Page 20 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
Figure 14: Smartphone app authenticator – Authentication Mode logical architecture
1. The user accesses service provider's web page via PC, mobile phone, tablet or any Internet device over any type of Internet access (3G, WLAN, fixed line network...).
a) The SP implementation uses a discovery mechanism, like the OneAPI Exchange to identify the operator and required parameters.
2. The SP backend server sends an authentication request using the OpenID Connect protocol. 3. The ID GW policy engine decides to use and route to the smartphone app authenticator.
a) The ID GW sends a message to the smartphone app through the Push Messaging Service depending on the platform. b) The smartphone app prompts the user to click OK or to enter the PIN.
4. The encrypted response is sent back to the ID GW using HTTPs, adding a signature using the token received during the setup phase.
a) The ID GW decrypts and validates the message. b) A signature validation is performed at the ID GW to establish the validity of the application.
5. The OIDC response is sent to the SP backend.
Pros Cons Rich User Experience. App cloning issues, especially in compromised devices.
V1.0 Page 21 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
Usage of device capabilities Secure storage needs on the device. It can be extended to use of biometrics, using the SIM for crypto processing, secure storage, etc.
Table 13: Pros and cons of the smartphone app authenticator
4.8 “Points in a Picture” App Authenticator This authenticator uses the richness of the UE and the device features available in the smartphone to enhance the experience when using the authenticator. It also uses the enhanced interaction options with the device screen and also the high resolution image presentation on the device.
The “Points in a Picture” app authenticator has a 2 step-mode process for its overall functioning:
Setup Mode (a one-time setup for the app) Authentication Mode
Figure 15: “Points in a Picture” app authenticator – Setup Mode logical architecture
1. The user uploads a picture in the app.
a) The user clicks on a number of points in the picture as the authentication matrix.
2. The app sends the picture and the points securely to the Setup Server along with a device signature (e.g. using the IMEI, platform version etc.).
a) The Setup Server securely stores the picture, the points and the device signature.
NOTE: An alternative approach of the setup is to keep the picture and the points in the device and only send the positive or negative authentication response signed with the device signature back to the ID GW.
V1.0 Page 22 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
4.8.1 Authentication Mode This mode is the operational mode for the app authenticator, when it is used for authenticating the end user.
Figure 16: “Points in a Picture” app authenticator – Authentication Mode logical architecture
1. User accesses service provider's web page via PC, mobile phone, tablet or any Internet device over any type of Internet access (3G, WLAN, fixed line network, etc.).
a) The SP implementation uses a discovery mechanism, like the API Exchange to identify the operator and needed parameters.
2. The SP sends an authentication request using the OpenID Connect protocol. 3. The ID GW policy engine decides to use and route to the “Points in a Picture” app authenticator.
a) The ID GW sends a message to the app through the Push Messaging Service depending on the platform. b) The app prompts the user with the picture and asks to click on the points.
4. The clicked points along with the device signature is sent back to the ID GW using HTTPs.
a) The ID GW decrypts and validates the message. b) A signature validation is performed at the ID GW to establish the validity of the application.
5. The OIDC response is sent to the SP backend.
V1.0 Page 23 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
NOTE: As mentioned in the Setup Phase, an alternative implementation could be to validate the user clicks on the device and send the positive or negative authentication message signed with the device signature to the ID GW.
Pros Cons Rich User Experience. App cloning issues, especially in compromised devices. Usage of device capabilities. Secure storage needs on the device. It can be extended to usage of the SIM for crypto processing, secure storage of the points of the picture, etc. Existing vendors such as PixelPIN provide these kinds of solution.
Table 14: Pros and cons of the “Points in a Picture” app authenticator
5 Other Potential Authentication Approaches There are other potential approaches which can be used for implementing authenticators:
5.1 GBA: Generic Bootstrapping Architecture 3GPP TS 33.220 The Generic Bootstrapping Architecture (GBA) leverages the mobile operator’s existing Home Subscriber Server (HSS) and SIM and adds some addition components – Bootstrapping Server Function (BSF), Network Application Function, (NAF) - to provide an authentication mechanism.
Figure 17: Generic Bootstrapping architecture framework
1. The mobile device (SIM) makes an identity request to the BSF. 2. The BSF fetches the AuthN vector and the user profile from the HSS.
V1.0 Page 24 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
3. The BSF challenges the mobile device to authenticate with the digest passed. 4. The mobile device computes the digest and returns the response.
On authenticating the response, the BSF returns a session key (B-TID).
5. The UE requests for service from the Network Application Function (NAF), using the session key (B-TID). 6. NAF sends authentication request to BSF passing the session key (B-TID).
The request is authenticated.
Pros Cons It reuses mobile operator assets – SIM, It needs additional network component (BSF). Authentication Vectors, Network credentials and crypto. Simple user experience. Complicated integration implementation. It works with non-mobile network access It needs specific SIMs for GBA. channels as well (e.g. Wi-Fi).
Table 15: Pros and cons of the Generic Bootstrapping architecture
5.2 Secure Quick Reliable Login (SQRL) SQRL (Secure Quick Reliable Login) is a QR code authentication method using signed messages to protect the authentication mechanism and using a device-based app.
Figure 18: SQRL-based authenticator logical architecture
1. The web application, displaying the UE on the tablet or desktop device, requests a SQRL-based QR code (containing the AuthN URL with a nonce) from the ID GW AuthN Service.
The AuthN Service generates a SQRL-based QR code (with a nonce) to the web app. The web page displays the QR code.
2. The SQRL app on the device reads the QR code.
V1.0 Page 25 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
It hashes the domain name using the unique private key in the app and generates a site specific key pair.
3. The app posts to the AuthN Service URL passing the site-specific public key and the signed URL.
The AuthN service validates the signature of the URL with the nonce and returns “200 OK”.
Pros Cons Simple user experience. Dependency on a device app (or otherwise a click-based interface). Unique site specific token for the device. It does not use a standard/open protocol for authentication request (uses a custom POST message). It works for off-channel scenario.
Table 16: Pros and cons of the SQRL-based authenticator
5.3 Hybrid Authenticator
Figure 19: Hybrid authenticator logical architecture
This authenticator model follows the principle of “best fit” by using:
A device application for optimised and enhanced user experience (requesting the user to consent via Click OK or PIN). SIM as a secure storage for shared secrets and credentials and a secure crypto engine (verifying the PIN and encrypting the response).
The interaction with the SIM is managed using the SIM Alliance APIs (SIMAlliance Open Mobile API). The interaction is facilitated by on-device library (Authentication Library).
Pros Cons It uses what is best for user experience (device Dependencies on device library to provide open app) and what provides better security for mobile API. credential and secrets storage (SIM). It uses the mobile operator assets so Sub optimal implementation of Open mobile API maximising the reuse. on the library/SDK can expose security threats. Independent of device storage.
V1.0 Page 26 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
Table 17: Pros and cons of the hybrid authenticator
5.4 OTP Generated on the Device (HOTP)-based Authenticator
Figure 20: HOTP-based authenticator logical architecture
1. The SP AuthN page asks the user to enter the MSISDN/Alias. It then asks the user to use the OTP app on the phone to generate the OTP and add the OTP into the page. 2. The user uses the OTP app to generate the OTP. 3. The user types the generated OTP on the app to the SP AuthN page. 4. The SP AuthN page checks with the AuthN service to validate the OTP and authenticate the user.
The HOTP server generates the OTP at the server and matches this with the OTP received.
Pros Cons It does not rely on communication channel Synchronisation issues of HOTP counters. (offline OTP generation). Simple user interface. User needs to invoke the app on the device. Intrusive user experience.
Table 18: Pros and cons of the HOTP-based authenticator
6 Account Chooser A user may have a number of user accounts from a number of different Identity Providers (IDP). The accounts may represent different personas and the user may want to use different personas depending on the service being accessed. In order to provide support to the authentication mechanism and allow the user to use multiple accounts, one option would be to adopt the Account Chooser mechanism standardised by the OpenID Foundation. This mechanism allows:
The SP to store different account references of the user along with the IDP references. The user to select the account that he or she wants to use for the service.
V1.0 Page 27 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
Figure 21: Account Chooser framework
A JavaScript-based integration (ac.js). It works with or without an external IdP.
First step towards integrating with an IdP.
The account gets associated with the device using device side storage. Multiple accounts associated, and the Account Chooser presents the associated accounts for the device to the user to select.
Implementation is supported by:
Janrain (login helper) OpenCart Google (Identity Toolkit)
V1.0 Page 28 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
7 SFRA Analysis of the key Authenticators Transport Authenticator Rating Authenticator Description Mechanism LoA Security Pros Security Cons Mitigations (High/Medium/Low) Initial Inadvertent approvals where * Simple, seamless people * Uses the MNO core accidentally tap network and existing User education and clear Zero/One Click on mobile device. security infrastructure messaging Seamless when accessing Applies to Mobile network 2 * Uses authenticated Medium (HTTP Header) via mobile legitimate and identity information from network illegitimate access the network requests. * Uses operator security model ID proofing as part of Device takeover robust business processes Potentially Augment MSISDN as standard user ID by another imposter/DOS element requested from attack (imposter the user, which is SIM Applet with * Uses SIM as a secure Medium/High (assuming second uses own phone) captured during user basic profile, element and a secure element such as “spam code” or SIM Applet if the initial ID and registration (e.g. a "spam using 3DES as Mobile network 2/3 execution environment similar used - recommend excluding (3DES) entered MSISDN code", DOB etc.) or the application and builds on proven public data such as DOB) and High are not coupled based on the context layer encryption security model for telcos using PIN (LoA3) within the system. (e.g. make/model of the phone, location etc.) depending on the implementation.
V1.0 Page 29 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
Account Takeover ID proofing as part of robust business processes Potentially standard imposter attack (imposter uses own phone/own PIN) if Augment MSISDN as the initial ID and user ID by another * USSD messages can entered MSISDN element requested from Medium (assuming second element Authenticator USSD based USSD / Mobile only be sent by the MNO are not coupled the user, which is such as "spam code" or similar used at based on NI- 2/3 authenticator network systems (ID GW) and not within the system captured during user transaction initiation - recommend USSD by other entities. (why does it ask registration (e.g. a "spam excluding public data such as DOB) user to enter code", DOB etc.) or MSISDN if it is based on the context coupled?). If this (e.g. make/model of the is not the case phone, location etc.) then SIM Swap depending on the could be an issue. implementation. Accidental approval for legitimate and illegitimate access requests Fallback DeviceTakeover ID proofing as part of Low / Medium (if second element such solution SMS / Mobile as "spam code" or similar used - SMS+URL 2 robust business providing network processes recommend excluding public data such simple click OK as DOB) Potentially Augment MSISDN as standard user ID by another imposter/DOS element requested from attack (imposter the user, which is uses own phone) captured during user
V1.0 Page 30 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
if the initial ID and registration (e.g. a "spam entered MSISDN code", DOB etc.) or are not coupled based on the context within the system. (e.g. make/model of the phone, location etc.) depending on the implementation. Provisioning and Robust process for PKI enrolment and using Trusted Fallback Execution Environment * Builds on well solution (TEE) Smartphone Data / Mobile understood PKI security supporting both 2/3 Reliance of Usage of TEE Medium (if PIN is used - LoA3) app (PKI) network model familiar to potential Click OK and security on the customers enter PIN device Device takeover Require PIN / Robust business processes
V1.0 Page 31 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
Mid Term * Well understood dynamic PIN/password approach * Uses SIM as a secure Augment MSISDN as element and a secure user ID by another SIM Applet Potentially execution environment element requested from using AES or standard and builds on proven the user, which is OATH OCRA imposter/DOS security model for telcos captured during user SIM Applet as the attack (imposter Data / Mobile * The Authenticator registration (e.g. a "spam High (spam-code or equivalent and (AES or OATH application 2/3 uses own phone) network interactions and code", DOB etc.) or PIN used) OCRA) layer if the initial ID and messages happen over based on the context encryption. entered MSISDN an encrypted channel - (e.g. make/model of the Robust Level of are not coupled both at the transport level phone, location etc.) Assurance 3 within the system. and also at the depending on the application/messaging implementation. level-making MitM/MitB unlikely during authentication.
V1.0 Page 32 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
* Builds on well understood PKI security model familiar to potential Augment MSISDN as customers user ID by another * The Authenticator Potentially element requested from interactions and standard the user, which is messages happen over imposter/DOS captured during user an encrypted channel - attack (imposter SIM Applet Bank grade Data / Mobile registration (e.g. a "spam High (spam-code or equivalent and 4 both at the transport level uses own phone) (PKI) security network code", DOB etc.) or PIN used) and also at the if the initial ID and based on the context application/messaging entered MSISDN (e.g. make/model of the level-making MitM/MitB are not coupled phone, location etc.) unlikely during within the system. depending on the authentication. implementation. * Uses secure storage for the user secrets (SIM secure storage). Augment MSISDN as user ID by another * Can tie app ID and Potentially element requested from MSISDN to the original standard the user, which is statement of ID imposter/DOS captured during user Hybrid Using SIM to * This uses the secure attack (imposter Medium assuming "Spam Code" or Data / Mobile registration (e.g. a "spam SIM/smartphone enhance app 2/3 element as the SIM for uses own phone) other used at initiation / High if PIN network code", DOB etc.) or app security secure storage and crypto if the initial ID and used for LoA3 based on the context services. This is the entered MSISDN (e.g. make/model of the model used by the NFC are not coupled phone, location etc.) apps as well. within the system. depending on the implementation. Initial
V1.0 Page 33 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
Inadvertent approvals where * Simple, seamless people * Uses the MNO core accidentally tap network and existing User education and clear Zero/One Click on mobile device. security infrastructure messaging Seamless when accessing Applies to Mobile network 2 * Uses authenticated Medium (HTTP Header) via mobile legitimate and identity information from network illegitimate access the network requests. * Uses operator security model ID proofing as part of Device takeover robust business processes Potentially Augment MSISDN as standard user ID by another imposter/DOS element requested from attack (imposter the user, which is uses own phone) captured during user SIM Applet with * Uses SIM as a secure if the initial ID and registration (e.g. a "spam Medium/High (assuming second basic profile, element and a secure entered MSISDN code", DOB etc.) or element such as "spam code" or SIM Applet using 3DES as Mobile network 2/3 execution environment are not coupled based on the context similar used - recommend excluding (3DES) the application and builds on proven within the system. (e.g. make/model of the public data such as DOB) and High layer encryption security model for telcos phone, location etc.) using PIN (LoA3) depending on the implementation. Account Takeover ID proofing as part of robust business processes
V1.0 Page 34 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
Potentially standard imposter attack (imposter uses own phone/own PIN) if Augment MSISDN as the initial ID and user ID by another * USSD messages can entered MSISDN element requested from Medium (assuming second element Authenticator USSD based USSD / Mobile only be sent by the MNO are not coupled the user, which is such as "spam code" or similar used at based on NI- 2/3 authenticator network systems (ID GW) and not within the system captured during user transaction initiation - recommend USSD by other entities. (why does it ask registration (e.g. a "spam excluding public data such as DOB) user to enter code", DOB etc.) or MSISDN if it is based on the context coupled?). If this (e.g. make/model of the is not the case phone, location etc.) then SIM Swap depending on the could be an issue. implementation. Accidental approval for legitimate and illegitimate access requests DeviceTakeover ID proofing as part of Fallback robust business Low / Medium (if second element such solution SMS / Mobile processes as "spam code" or similar used - SMS+URL 2 providing network recommend excluding public data such Potentially Augment MSISDN as simple click OK as DOB) standard user ID by another imposter/DOS element requested from attack (imposter the user, which is uses own phone) captured during user if the initial ID and registration (e.g. a "spam entered MSISDN code", DOB etc.) or based on the context
V1.0 Page 35 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
are not coupled (e.g. make/model of the within the system. phone, location etc.) depending on the implementation.
Provisioning and Robust process for PKI enrolment and using TEE (Trusted Fallback Execution Environment) * Builds on well solution Smartphone Data / Mobile understood PKI security Reliance of Usage of TEE supporting both 2/3 Medium (if PIN is used - LoA3) app (PKI) network model familiar to potential security on the Click OK and customers device enter PIN Device takeover Require PIN / Robust business processes
V1.0 Page 36 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options
7.1 General mitigation recommendations from the SFRA analysis Usage of an additional user entered information along with MSISDN (e.g. Spam Code or DOB) to prevent targeted or mass spam. Usage of TEE for smartphone applications. User education and clear messaging. ID proofing as part of the business processes when possible (already in scope for Mobile Connect step 2). Robust business processes to handle device takeover, lost/stolen, SIM cloning detection etc. situations.
V1.0 Page 36 of 38 GSM Association Non-confidential Official Document PDATA.03 - CPAS04 Authenticator Options Annex A Document Management
A.1 Document History Version Date Brief Description of Change Approval Editor / Authority Company 1.0 16-11- Document approved by PSMC CPAS / PSMC Gautam Hazari 2015 / GSMA
A.2 Other Information Type Description Document Owner Personal Data Editor / Company Gautam Hazari / GSMA
It is our intention to provide a quality product for your use. If you find any errors or omissions, please contact us with your comments. You may notify us at [email protected]
Your comments or suggestions & questions are always welcome.
V1.0 Page 37 of 38