cpas04 authenticator options version 1.0 11 november 2015 · 7 sfra analysis of the key...

GSM Association Non-confidential

Official Document PDATA.03 - CPAS04 Authenticator Options

V1.0 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.



V1.0 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.6 SMS and URL-based Authenticator 18


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



V1.0 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



V1.0 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



V1.0 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.



V1.0 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



V1.0 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.



V1.0 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.



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



V1.0 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.



V1.0 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.



V1.0 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



V1.0 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



V1.0 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.



V1.0 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



V1.0 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.



V1.0 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


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


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



V1.0 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.



V1.0 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.



V1.0 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.



V1.0 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.



V1.0 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.



V1.0 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.



V1.0 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.



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



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



V1.0 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


the user, which is



code", DOB etc.) or




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


the user, which is




V1.0 of 38


entered MSISDN

are not coupled

within the system.


code", DOB etc.) or




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



V1.0 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






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


entered MSISDN

are not coupled

within the system.

Augment MSISDN as

user ID by another


the user, which is



code", DOB etc.) or




depending on the

implementation.

High (spam-code or equivalent and

PIN used)



V1.0 of 38

SIM Applet

(PKI)

Bank grade

security

Data / Mobile

network 4

* Builds on well



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)


entered MSISDN

are not coupled

within the system.

Augment MSISDN as

user ID by another


the user, which is



code", DOB etc.) or




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)


entered MSISDN

are not coupled

within the system.

Augment MSISDN as

user ID by another


the user, which is



code", DOB etc.) or




depending on the

implementation.

Medium assuming "Spam Code" or

other used at initiation / High if PIN

used for LoA3

Initial



V1.0 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






Potentially

standard

imposter/DOS

attack (imposter

uses own phone)


entered MSISDN

are not coupled

within the system.

Augment MSISDN as

user ID by another


the user, which is



code", DOB etc.) or




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



V1.0 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


the user, which is



code", DOB etc.) or




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)


entered MSISDN

Augment MSISDN as

user ID by another


the user, which is



code", DOB etc.) or




V1.0 of 38

are not coupled

within the system.



depending on the

implementation.

Smartphone

app (PKI)

Fallback

solution

supporting both

Click OK and

enter PIN

Data / Mobile

network 2/3

* Builds on well



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



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.



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.

mailto:[email protected]

cpas04 authenticator options version 1.0 11 november 2015 · 7 sfra analysis of the key...

Documents