cpas04 authenticator options version 1.0 11 november 2015 · 7 sfra analysis of the key...
TRANSCRIPT
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 1 of 38
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.
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 2 of 38
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
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 3 of 38
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).
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
Step1:Authen ca on
Enablinguserstoauthen catetoandauthorisetransac onswithin3rdpartyservices
Step2:Iden ty&A ributes
Provisionofiden tyservicesandenhancementofdigitaltransac onsthroughtheprovisionorverifica onofa ributes
Step3:Personaldata
Centralisingandcontrollingyourpersonalinforma on
LoA
Low
Veryhigh
Medium
High
StrongAuthen ca on(MC_A2)
SimpleAuthen ca on(MC_A1)
VerystrongAuthen ca on
(MC_A3)
A ributeVerifica on(MC_AV)
A ributeProvision(MC_AP)
A ributePublish
(MC_APS)
Age>18yrs
Currentaddress
An -fraudno fica ons
Exampleservices
MobileConnect
capabili es
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 4 of 38
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
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 5 of 38
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
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 6 of 38
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.
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 7 of 38
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
Assurance
Description Authentication Context
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
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 8 of 38
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.
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 9 of 38
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
infrastructure.
Device takeover.
It uses authenticated identity information from the network.
It uses operator security model.
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 10 of 38
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
for using the device APIs to send SMS.
Short codes are local to the
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)
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 11 of 38
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.
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 12 of 38
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.
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 13 of 38
Pros Cons
It reuses mobile operator assets – SIM,
SMSC.
Dependency on SIM supporting Java Card applet
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
transmitted.
Complex architecture, messaging and interaction
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
approach.
Potentially standard imposter/DOS attack (imposter
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
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 14 of 38
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
the camera; voice recognition as well as
fingerprint sensing where supported).
Complex architecture. It needs specific protocol to
be implemented between client and the server.
Secrets and credentials are stored on the
device under user control, and never shared
outside.
Dependencies on device based clients to provide
integration with device agents, capabilities.
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
keys - business opportunity and/or Unique
Selling Point (USP) for mobile operators.
FIDO uses Elliptic Curve Cryptography (ECC)
which reduces key size, but having a unique key
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
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 15 of 38
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.
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 16 of 38
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
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 17 of 38
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
works on the signalling plane.
It does not work for Long Term Evolution (LTE).
It works in roaming conditions, across
devices.
It potentially supports both LoA2 and LoA3. Transmission security possibly not secure enough
for LoA3.
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 18 of 38
SFRA Feedback
USSD messages can only be sent by the
mobile operator systems (ID GW) and not by
other entities.
Potentially standard imposter attack (imposter uses
own phone/own PIN) if the initial ID and entered
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.
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 19 of 38
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
in URL rather than requiring user to retype.
SMS can be intercepted by apps on the device.
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.
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 20 of 38
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.
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 21 of 38
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.
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 22 of 38
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.
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 23 of 38
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.
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 24 of 38
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.
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 25 of 38
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,
Authentication Vectors, Network credentials and
crypto.
It needs additional network component (BSF).
Simple user experience. Complicated integration implementation.
It works with non-mobile network access
channels as well (e.g. Wi-Fi).
It needs specific SIMs for GBA.
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.
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 26 of 38
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
app) and what provides better security for
credential and secrets storage (SIM).
Dependencies on device library to provide open
mobile API.
It uses the mobile operator assets so
maximising the reuse.
Sub optimal implementation of Open mobile API
on the library/SDK can expose security threats.
Independent of device storage.
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 27 of 38
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
(offline OTP generation).
Synchronisation issues of HOTP counters.
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.
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 28 of 38
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)
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 29 of 38
7 SFRA Analysis of the key Authenticators
Authenticator Description
Transport
Mechanism LoA Security Pros Security Cons Mitigations
Authenticator Rating
(High/Medium/Low)
Initial
Seamless
(HTTP Header)
Zero/One Click
when accessing
via mobile
network
Mobile network 2
* Simple, seamless
* Uses the MNO core
network and existing
security infrastructure
* Uses authenticated
identity information from
the network
* Uses operator security
model
Inadvertent
approvals where
people
accidentally tap
on mobile device.
Applies to
legitimate and
illegitimate access
requests.
User education and clear
messaging
Medium
Device takeover
ID proofing as part of
robust business
processes
SIM Applet
(3DES)
SIM Applet with
basic profile,
using 3DES as
the application
layer encryption
Mobile network 2/3
* Uses SIM as a secure
element and a secure
execution environment
and builds on proven
security model for telcos
Potentially
standard
imposter/DOS
attack (imposter
uses own phone)
if the initial ID and
entered MSISDN
are not coupled
within the system.
Augment MSISDN as
user ID by another
element requested from
the user, which is
captured during user
registration (e.g. a "spam
code", DOB etc.) or
based on the context
(e.g. make/model of the
phone, location etc.)
depending on the
implementation.
Medium/High (assuming second
element such as “spam code” or
similar used - recommend excluding
public data such as DOB) and High
using PIN (LoA3)
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 30 of 38
Account Takeover ID proofing as part of
robust business
processes
USSD based
authenticator
Authenticator
based on NI-
USSD
USSD / Mobile
network 2/3
* USSD messages can
only be sent by the MNO
systems (ID GW) and not
by other entities.
Potentially
standard imposter
attack (imposter
uses own
phone/own PIN) if
the initial ID and
entered 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.
Augment MSISDN as
user ID by another
element requested from
the user, which is
captured during user
registration (e.g. a "spam
code", DOB etc.) or
based on the context
(e.g. make/model of the
phone, location etc.)
depending on the
implementation.
Medium (assuming second element
such as "spam code" or similar used at
transaction initiation - recommend
excluding public data such as DOB)
SMS+URL
Fallback
solution
providing
simple click OK
SMS / Mobile
network 2
Accidental
approval for
legitimate and
illegitimate access
requests
Low / Medium (if second element such
as "spam code" or similar used -
recommend excluding public data such
as DOB)
DeviceTakeover ID proofing as part of
robust business
processes
Potentially
standard
imposter/DOS
attack (imposter
uses own phone)
Augment MSISDN as
user ID by another
element requested from
the user, which is
captured during user
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 31 of 38
if the initial ID and
entered MSISDN
are not coupled
within the system.
registration (e.g. a "spam
code", DOB etc.) or
based on the context
(e.g. make/model of the
phone, location etc.)
depending on the
implementation.
Smartphone
app (PKI)
Fallback
solution
supporting both
Click OK and
enter PIN
Data / Mobile
network 2/3
* Builds on well
understood PKI security
model familiar to potential
customers
Provisioning and
enrolment
Robust process for PKI
and using Trusted
Execution Environment
(TEE)
Medium (if PIN is used - LoA3) Reliance of
security on the
device
Usage of TEE
Device takeover Require PIN / Robust
business processes
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 32 of 38
Mid Term
SIM Applet
(AES or OATH
OCRA)
SIM Applet
using AES or
OATH OCRA
as the
application
layer
encryption.
Robust Level of
Assurance 3
Data / Mobile
network 2/3
* Well understood
dynamic PIN/password
approach
* Uses 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.
Potentially
standard
imposter/DOS
attack (imposter
uses own phone)
if the initial ID and
entered MSISDN
are not coupled
within the system.
Augment MSISDN as
user ID by another
element requested from
the user, which is
captured during user
registration (e.g. a "spam
code", DOB etc.) or
based on the context
(e.g. make/model of the
phone, location etc.)
depending on the
implementation.
High (spam-code or equivalent and
PIN used)
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 33 of 38
SIM Applet
(PKI)
Bank grade
security
Data / Mobile
network 4
* Builds on well
understood PKI security
model familiar to potential
customers
* 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.
* Uses secure storage for
the user secrets (SIM
secure storage).
Potentially
standard
imposter/DOS
attack (imposter
uses own phone)
if the initial ID and
entered MSISDN
are not coupled
within the system.
Augment MSISDN as
user ID by another
element requested from
the user, which is
captured during user
registration (e.g. a "spam
code", DOB etc.) or
based on the context
(e.g. make/model of the
phone, location etc.)
depending on the
implementation.
High (spam-code or equivalent and
PIN used)
Hybrid
SIM/smartphone
app
Using SIM to
enhance app
security
Data / Mobile
network 2/3
* Can tie app ID and
MSISDN to the original
statement of ID
* This uses the secure
element as the SIM for
secure storage and crypto
services. This is the
model used by the NFC
apps as well.
Potentially
standard
imposter/DOS
attack (imposter
uses own phone)
if the initial ID and
entered MSISDN
are not coupled
within the system.
Augment MSISDN as
user ID by another
element requested from
the user, which is
captured during user
registration (e.g. a "spam
code", DOB etc.) or
based on the context
(e.g. make/model of the
phone, location etc.)
depending on the
implementation.
Medium assuming "Spam Code" or
other used at initiation / High if PIN
used for LoA3
Initial
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 34 of 38
Seamless
(HTTP Header)
Zero/One Click
when accessing
via mobile
network
Mobile network 2
* Simple, seamless
* Uses the MNO core
network and existing
security infrastructure
* Uses authenticated
identity information from
the network
* Uses operator security
model
Inadvertent
approvals where
people
accidentally tap
on mobile device.
Applies to
legitimate and
illegitimate access
requests.
User education and clear
messaging
Medium
Device takeover
ID proofing as part of
robust business
processes
SIM Applet
(3DES)
SIM Applet with
basic profile,
using 3DES as
the application
layer encryption
Mobile network 2/3
* Uses SIM as a secure
element and a secure
execution environment
and builds on proven
security model for telcos
Potentially
standard
imposter/DOS
attack (imposter
uses own phone)
if the initial ID and
entered MSISDN
are not coupled
within the system.
Augment MSISDN as
user ID by another
element requested from
the user, which is
captured during user
registration (e.g. a "spam
code", DOB etc.) or
based on the context
(e.g. make/model of the
phone, location etc.)
depending on the
implementation.
Medium/High (assuming second
element such as "spam code" or
similar used - recommend excluding
public data such as DOB) and High
using PIN (LoA3)
Account Takeover ID proofing as part of
robust business
processes
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 35 of 38
USSD based
authenticator
Authenticator
based on NI-
USSD
USSD / Mobile
network 2/3
* USSD messages can
only be sent by the MNO
systems (ID GW) and not
by other entities.
Potentially
standard imposter
attack (imposter
uses own
phone/own PIN) if
the initial ID and
entered 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.
Augment MSISDN as
user ID by another
element requested from
the user, which is
captured during user
registration (e.g. a "spam
code", DOB etc.) or
based on the context
(e.g. make/model of the
phone, location etc.)
depending on the
implementation.
Medium (assuming second element
such as "spam code" or similar used at
transaction initiation - recommend
excluding public data such as DOB)
SMS+URL
Fallback
solution
providing
simple click OK
SMS / Mobile
network 2
Accidental
approval for
legitimate and
illegitimate access
requests
Low / Medium (if second element such
as "spam code" or similar used -
recommend excluding public data such
as DOB)
DeviceTakeover ID proofing as part of
robust business
processes
Potentially
standard
imposter/DOS
attack (imposter
uses own phone)
if the initial ID and
entered MSISDN
Augment MSISDN as
user ID by another
element requested from
the user, which is
captured during user
registration (e.g. a "spam
code", DOB etc.) or
based on the context
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 36 of 38
are not coupled
within the system.
(e.g. make/model of the
phone, location etc.)
depending on the
implementation.
Smartphone
app (PKI)
Fallback
solution
supporting both
Click OK and
enter PIN
Data / Mobile
network 2/3
* Builds on well
understood PKI security
model familiar to potential
customers
Provisioning and
enrolment
Robust process for PKI
and using TEE (Trusted
Execution Environment)
Medium (if PIN is used - LoA3) Reliance of
security on the
device
Usage of TEE
Device takeover Require PIN / Robust
business processes
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 36 of 38
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.
GSM Association Non-confidential
Official Document PDATA.03 - CPAS04 Authenticator Options
V1.0 Page 37 of 38
Annex A Document Management
A.1 Document History
Version Date Brief Description of Change Approval
Authority
Editor /
Company
1.0 16-11-
2015
Document approved by PSMC CPAS / PSMC Gautam Hazari
/ 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.