Mobile Devices as Identity Carriers

Pre Conference Workshop October 14th 2013

Mobile Market

2

0

200,000

400,000

600,000

800,000

1,000,000

1,200,000

1,400,000

2011 2012 2013 2014 2015

Worldwide Smartphones Market by OS (in thousands of units)

Android Symbian iOS RIM Microsoft BADA Others

WW Tablets Market from ~ 70 million in 2011 growing to 300 million in 2015

Source - Gartner - 3Q2011

Mobile “as a token”

 Users want to use their mobile phones as the 2nd factor authentication device   The Mobile phone is a personal token of choice. Always associated to an individual

and always with them.   Instead of dedicated HW devices (OTP tokens, Smart Cards)   Out of Band Authentication

 Primary use case: Remote access through their laptop / desktop

 Secondary use cases: Win Logon, Encryption, Signature, Physical Access

 Third use case: Securing an APP

3

Use Case #1

Use Case #2

Mobile “as a laptop”

 Security solutions on this devices must be at par with security solutions on laptops & desktops   BYOD culture becoming prevalent   Users want to access corporate resources (regular mail, encrypted mail, online corporate

services) through their smart phones and PADs) …   … and they are doing so, whether CIOs/CSOs like it or not!   Corporations don’t want to constrain their users by imposing restrictive policies

 Primary Use Cases: Secure Email Encryption/decryption, VPN access.

 Secondary Use Cases: Data at rest encryption, Digital signature, Device un/Lock, SSO.

4

The Playing Field It is a complex, immature environment for Identity

Diversity of: Mobile OS platforms:

  IOS, Android, Windows phone, Blackberry OS, Symbian … Mobile OS versions

  IOS versions : Android’s Gingerbread, Honeycomb, IceCream: Windows Phone 7, 8, … Bada(Samsung)

Phone vendors:  Windows Phone: Nokia, HTC, Samsung  Android: Samsung, LG, HTC, SonyEricsson, …

Options for storage of credentials (Secure Elements)  Each one requiring specific drivers for each Mobile platform

Middleware  Middleware will also be specific to each Mobile OS

Applications and application providers?  No standard Smart Card support to rely on. PKCS11 seems best

option  No Base CSP on Windows Phone 7.

5

Mobile Platform Technology Solution options

• Bluetooth reader • Software Certificates in Mobile device applications • SD Micro • Directly connected reader • NFC coupled • Trusted Security Module/ Trusted Execution

Environment • CAC/PIV applet embedded in the SIM

6

Bluetooth CAC reader

7

Working today in DoD “cumbersome”, “battery life issues”, “only Blackberry”, “expensive” Blackberry OS – controlled by RIM™

Bluetooth CAC integration achieved with RIM™ collaboration in O/S Blackberry Smart Card Reader Apriva™ BT200 Bluetooth reader

Bluetooth CAC/PIV readers with other handsets?

8

?

Software Certificates

Not an LOA4 option Soft cert considered LOA3 These certificates can be loaded into Apps such as Touchdown

(Activesync Email) and browsers to enable secure use of mobile. Creates a duality of credentials (One encryption cert; two signing

certs)  In the PIV/CAC.  In the phone.

FIPS 201-2, SP800-157 to define derived credential policy

9

Connected Reader – for secure services

Attach a simple reader via the Apple™ port in USB mode or to an Android™ via micro USB connector in USB mode

Uses existing CAC or PIV full form factor Smart Card Requires O/S integration; email & Brower support etc Low cost reader. No extra credentials needed Physically cumbersome?

10

CAC/PIV via NFC Phone – for secure services

With an NFC enabled smart phone the CAC/PIV could be connected and utilized in close proximity

Uses existing CAC or PIV full form factor Smart Card Requires NFC integration into Operating System; email & Brower support etc No extra credentials needed Physically easy but a little practical to hold card next to phone FIPS201-2 introduces “Virtual Contact Interface” for NFC operation Challenges with FIPS140-2 power-up self tests and NFC timeouts Not all NFC phones act as a reader – most are acting as “cards”

  Power/Battery life issues 11

Solutions – SD Micro integration

Combine CAC/PIV chip on SD Micro device No Mobile operator involvement (no SIM impact) Handset middleware support required. SDMicro not universally supported on all handsets (Not on Apple™

platforms) How to provision CAC/PIV applet? On SDMicro on Laptop or via the

Data connection? Needs a specific App on the phone NFC can be provided on SD Micro form factor too

12

Securing Mobile applications (Apps)

13

" Software to be executed must to be secured (code and data such as cryptographic keys) •  Principle: isolation in a secure environment

1.  Use of Trusted Execution Environment (TEE) 2.  Use of external component: Secure Element

" User Interface must to be secured •  Sensitive information entry (e.g. password) •  Transaction data to be validated (e.g. transaction amount) •  Principle: Trusted User Interface via Trusted Execution

Environment

Integration into Trusted Execution Environment

14

Secure Element (Removable or Embedded) • Certified tamper-resistant • For secure storage and

processing of the most valuable and sensitive data

Trusted Execution Environment • Protects input and output and transient processing of sensitive data • Applicable to a broad array of new connected devices

Gemalto, ARM and Giesecke & Devrient are forming a joint venture to offer an open software-hardware security platform to provide a Trusted Execution Environment in connected devices

Solutions – Mobile CAC/PIV in SIM Physical Access & Remote services

15

SIM/UICC architecture

16

UICC MNO TSM Keys

Security Domain 1 Vendor TSM Keys

Vendor App 1-1

Vendor App 1-2

Security Domain 2 Vendor TSM Keys

Vendor App 2-1

Vendor App 2-2

PIV Security Domain PIV TSM

Keys

PIV Applet

Provisioning & usage

17

Government/Enterprise owned TSM, IDM, CA & CMS

xMNO

API Exposure Point Government/Enterprise Owned External PKI

Certification Authority PKI

18

Mobile Operating Systems

• IOS – controlled by Apple tightly. • Android – Led by Google – Open source. NFC supported

• Windows Mobile – Controlled by Microsoft • Blackberry OS – Controlled by RIM All require support for PKI credentials where ever stored/implemented.

Mobile Apps

Within the Identity Ecosystem there will be different levels of Identity Assurance credentials.

For example: LOA4 Digital PKI Credential in hardware + PIN LOA3 Soft PKI Certs with PIN (in app) LOA2 Username/Password + OTP LOA1 Username/Password (in app)

21

Software Apps

MicroSD

UICC

Badge via NFC

TEE eSE

Where to store the Identity credentials?

Badge via Mobile Contact reader

Badge via Bluetooth

Semi-detached

credentials

Detached

credentials

Embedded Credentials

Hardware

Secure Element Options

22

Conclusion Mobiles and how they fit into the Identity Ecosystem

There are several implementation options emerging which address a subset of the problem space.

Use cases will drive the adoption, along with various LOA credentials Requirements must be defined for each LOA credential.

 Handsets; Operating Systems; Mobile Operators; Provisioning, Management, soft or hard etc

Security Policies critical for technology selection and secure trusted implementations.

Standard are needed for implementation and interoperability

23

 Smart Card Alliance  191 Clarksville Rd. · Princeton Junction, NJ 08550 · (800) 556-6828  www.smartcardalliance.org

Neville Pattinson SVP Government Sales, Gemalto, Inc. Neville.pattinson@gemalto.com Office 1 512 257 3982 Mobile 1 512 825 3082 Twitter @Neville_Gemalto