Mobile Devices as Identity Carriers
Transcript of Mobile Devices as Identity Carriers
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. [email protected] Office 1 512 257 3982 Mobile 1 512 825 3082 Twitter @Neville_Gemalto