1. Mobile Authentication at Different Levels of Assurance
IDY-T11
Mobile Authentication at Different Levels of Assurance
Conny Balazs
Security Consultant
Certezza

2. Why is the interest rapidly growing?
Mobile devices have become a natural part of peoples lives
Rapid increase in mobile applications with access to sensitive/valuable information
Mobile user/work patterns
Do you want to fight these trends or provide means for them?

3. An example of the rapid growth of mobile ID
Amount of issued EIDs from this issuer
Mobile ID
ID on card
ID on file
Statistik
Mbid lanserades

4. An example of the rapid growth of mobile ID
Amount of uses of EIDs
2016 the total amount of uses were more than 1.8 billion with EIDs from this issuer
Mobile ID
ID on card
ID on file
Statistik

5. What you’ll learn from this session
Common identity assurance frameworks
Examples of requirements when specifically using mobile devices as bearer of identity at high levels of assurance
Examples of how an identity with high level assurance can be issued

6. How Do You Measure Assurance?

7. Criteria for assurance

8. The four classic levels of assurance
LoA1 – Low (or extremely low)
LoA2 – Medium
LoA3 – High
LoA4 – Very high
Note that the eIDAS regulation and SP in its current form does not directly map to all four levels

9. Criteria for assurance
If going for LoA3 a soft token on a mobile device might act as the actual bearer of identity
LoA4 only allow hardware crypto tokens

10. Criteria for assurance
If going for LoA4 only hard tokens will pass as the bearer of the identity
LoA4 only allow hardware crypto tokens

11. Criteria for assurance
What makes a (commercial) mobile device special in comparison to (some) “hard” identity bearers?
Cannot be considered a secure environment
Multipurpose device
Main purpose is not to act as a general purpose identity bearer
Multiuser behavior is a factor to consider

12. Some general advice
The operating environment of a commercial mobile device (Android, iOS, Windows) does not offer out-of-the-box means for enrollment, storage and usage of an identity at high levels of assurance
You need to isolate the identity from other applications on the device, as well as from the operating system
Unless you settle for low levels of assurance
OS:ets sandboxing räcker inte då det finns annat på enheten som kan exekveras med för högra privilegier och därmed få åtkomst till saker i en app sandbox. Även sårbarheter i mjukvara med för höga privilegier är en faktor att beakta

13. Some general advice
DO NOT go down the route with inter app dependencies when using mobile identity for authentication in mobile applications
I.E. do not make one app dependent on another app
Not allowed on the Apple app store
Be really careful about dependencies to proprietary vendor API:s
Use verified and open standards for integration to identity

14. Some general advice What about platform specific cryptos?
iOS Core Crypto Module
Samsung Crypto Module
Etc.
These are examples of cryptos not meant for persistent key storage
Solid crypto implementations but highly unsuitable for storage of persistent keys
It is not a random coincidence that vendors use other types of keystores on their platforms
Keychain, Java keystore etc.

15. Shared devices Don’t store soft LoA3-identity on shared devices
You end up sharing one of the factors (something you have)

16. ID life cycle management
Identify
Issue
Revoke
Renew

17. ID life cycle management
Regarding enrollment of LoA3-LoA4 identities
RA:s must NOT be able to issue identity to itself
RA:s must NOT at anytime have access to identity bearer and activation data
Separation of duties is critical

18. Enrollment process
Distribution/management of activation data
Cannot use distribution mechanism where the mobile device is the endpoint receiver
Often implemented in the form of “activation data RA”-role or “signed for” snail mail

19. Identification of subjects at LoA3-LoA4
Inherited identification
Requires that the subject already has an existing LoA3-LoA4 identity
Allows self service enrollment
Not allowed at LoA4

20. Real world example - inherited ID
Person with existing LoA3-LoA4 ID visits and authenticates to self service portal
Authenticate
Identity proofing completed as part of the issuance of the original – trust to identity is inherited

21. Real world example - inherited ID
User initiates enrollment of mobile ID and is given enrollment code via the self service portal
Enrollment code
Identity proofing completed as part of the issuance of the original – trust to identity is inherited

22. Real world example - inherited ID
User is instructed to install mobile ID app on mobile device
Identity proofing completed as part of the issuance of the original – trust to identity is inherited

23. Real world example - inherited ID
User starts mobile ID app and starts enrollment with issued enrollment code
Enrollment request
Verify enrollment data
Identity proofing completed as part of the issuance of the original – trust to identity is inherited

24. Real world example - inherited ID
If user agrees to terms and conditions a mobile ID is issued
Issue mobile ID
Identity proofing completed as part of the issuance of the original – trust to identity is inherited

25. Identification of subjects at LoA3-LoA4
Non inherited identification
The issuer will have to identify and prove the identity of the subject as part of the enrollment procedure
Requires physical identification
No self service

26. Real world example – non inherited ID
Person visits identification agent for identity proofing
Identity proofing
Identity proofing completed as part of the issuance of the original – trust to identity is inherited

27. Real world example – non inherited ID
If identity proofing is successful identification agent provides enrollment data
Enrollment data
Identity proofing completed as part of the issuance of the original – trust to identity is inherited

28. Real world example - non inherited ID
User visits enrollment agent and is once again identified and identity issuance is activated
Identity activation
Identity proofing completed as part of the issuance of the original – trust to identity is inherited

29. Real world example - inherited ID
User is instructed to install mobile ID app on mobile device
Identity proofing completed as part of the issuance of the original – trust to identity is inherited

30. Real world example – non inherited ID
User starts mobile ID app and completes enrollment with previously issued enrollment code
Enrollment request
Verify enrollment data
Identity proofing completed as part of the issuance of the original – trust to identity is inherited

31. Real world example – non inherited ID
If user agrees to terms and conditions a mobile ID is issued
Issue mobile ID
Identity proofing completed as part of the issuance of the original – trust to identity is inherited

32. Use of mobile ID in applications
Different integration scenarios depending on application
Native/hybrid/Javascript driven HTML-apps
Web applications
“Rich clients”

33. Use of mobile ID
Be VERY conservative regarding proprietary interfaces/protocols for integration with an application
Identity proofing completed as part of the issuance of the original – trust to identity is inherited

34. Use of mobile ID Use open standards where they make sense
OpenID Connect/UMA/OAuth/SAML etc.
Be extremely careful about how you use standards like the ones above
Exempel på dålig användning av code grant flow där enheten lagrar client secret eller Facebook proprietära implementation av implicit flow.
Implicit flow saknar bindning mellan appen och autentiseringen vilket gör att man kan inte vara säker på att en utsälld token verkligen ställdes ut till den app som använder sig av en token – tilliten ligger till enheten att säkerställa detta

35. Use of mobile ID Consider the need for offline authentication
Identity proofing completed as part of the issuance of the original – trust to identity is inherited

36. What about FIDO? The “middleware” is built into some browsers
The subject choose services where to register service specific public keys
Means that you will have to onboard the subject by other means (and other identity) if the desire is above LoA1

37. Is the market ready?
Today…..not a vast selection of vendors that sell products that meet all requirements for LoA3-4
More to choose from if using the inherited ID- model
Solid lifecycle management at high levels of assurance is not something that you buy
It is mainly a strict set of procedures that you wield and adhere to

38. How to apply
Identify the needs for mobile authentication AND at what levels of assurance
Think about what benefits mobile authentication can bring to the table
Translate assurance frameworks into real world requirements
Do not expect mobile identity tokens to pass a LoA3-4 audit just because some vendor use that as part of their selling pitch

39. Some recommended reference material
NIST SP draft
publication
eIDAS Regulation
content/EN/TXT/?uri=uriserv:OJ.L_ ENG
Do not expect mobile identity tokens to pass a LoA3-4 audit just because some vendor use that as part of their selling pitch

40. Questions/comments?