Skip to content

SIM-less authentication

The “SIM-less” in this context is a collection of all those techniques that do not use a SIM as a secure tamper proof hardware to implement the place for running the secure element function with a precisely known runtime environment.

 

Some technology vendors are claiming that they can do secure mobile authentication without a SIM.

That is fine, if they have found a way to create a security container that fullfills required Level of Assurance (LoA). Such is trivial for a very low LoA, but highest levels are harder to meet.

This is also easy to confuse with Common Criteria Evaluation Assurance Level (EAL).  They are somewhat different thing: LoA says about identity, and sets effectively but not explicitly a minimum EAL levels for implementation, plus adds additional requirements on how the registration is done.

To produce Level of Assurance 4 authentication everything must be tight: Registration method, Identity verification, the security module implementation must be hard (EAL3 or higher,) and finally the user interface must be unambiguous.

SIM-less Platforms

In addition to SIM card holding the trusted applications, recent developments have been around so called Trusted Execution Environment (TEE) specification by Global Platform.  Any other security environment requires that a general purpose platform (iOS, Android) is hardened against third parties accessing files and memory of the phone.

This general purpose protection does not happen in either Apple iOS, or in Android platforms.  Other platforms (Blueberry, Windows Phone) are in definite minority and less well known. [1, 2, 3, 4]  (Store files on Android internal filesystem, and they are somewhat protected. Store files on external memory card of Android, and they are open to everybody.)

In spring 2016 the FBI paid somebody a lot for a tool that can access recent iOS phone memory, and Apple does not know how it is done. Although Apple did find a suspicuous thing that was fixed in iOS 8.1 [5, 6]

Apple has done flash memory block erasing easy, but in earlier models nothing prevents physical access to device from replacing the flash device with another one in previous hardware generations [5].  Only most recent “A7” processor has an internal security enclave that is harder to access.

Keeping Secrets in Phone

Both Android and iPhone platforms have something called secure key storage API for PKI key material.

Latest high-end Androids document using TEE mechanism for this, but it is just API, and it can be implemented in many ways, not necessarily strongly secure. This API has a query method to find out if the key storage is strongly secure, but in case of cheapest model phones, the expectance value is that it will report “this is secure” while it isn’t.

The iPhones have similar mechanism, and given Apple’s attitude to security matters, it probably works correctly. (Subject to bugs. See iOS8.1 update above.)

If the Android or iPhone is “jail broken”, access to TEE mechanism can be compromised, and again neither the application nor the user can know for sure that the secret key data is truly unextractable.

Nevertheless we have seen several professionally security paranoid parties using Android as platform for a general population access token application:

  • Google Authenticator
  • Banks

In each case the application vendor is barely trusting their own thing, and nobody is trusting external vendor’s product.

How to do SIM-less Mobile Authenticator

In a few “easy” steps:

  1. Ensure platform trustworthiness
    • Let the platform to be audited and observed to be trustworthy
    • Let the end user to know in a trustworthy way of when the platform is in trusted mode
  2. Ensure the authenticator trustworthiness
    • Let the authenticator to be audited by third parties to be trustworthy

What kind of user interactions will it do?  The TEE UI specification defines specific graphical elements when a trusted application is in control, but anybody could do similar looking graphics.  Blueberry devices used to light up special (red?) LEDs when the secure mode was running.

Finally things like communication setup, possible encryptions and messaging start to be an issue but we stop here. If you have EAL3+ for secret keeping, the communication security becomes easier.

By the way: Even the SIM based security module authenticators fail in letting the user to know in secure way that they are interacting in secure mode.  The SIM-toolkit API implementations at phones are decently secure, but there are no special LEDs lighting up when that mode is interacting with keyboard and display. This is mostly due to historical evolution of the mobile phone systems.  Next evolution step is to have those special indication LEDs.

References

[LoA]

  1. http://www.whitehouse.gov/sites/default/files/omb/memoranda/fy04/m04-04.pdf
  2. https://sites.google.com/a/aniltj.org/ficam/loa
  3. http://www.smartcardalliance.org/resources/pdf/identity_council_assurance_levels_brief.pdf
  4. https://www.cdc.informatik.tu-darmstadt.de/fileadmin/user_upload/Group_CDC/Documents/Lehre/SS13/Seminar/CPS/cps2014_submission_1.pdf

[1] https://developer.android.com/training/articles/security-tips.html#StoringData
[2] https://developer.android.com/training/best-security.html
[3] https://www.raywenderlich.com/45645/ios-app-security-analysis-part-1
[4] https://www.apple.com/business/docs/iOS_Security_Guide.pdf
[5] http://arstechnica.com/apple/2016/03/there-are-ways-the-fbi-can-crack-the-iphone-pin-without-apple-doing-it-for-them/
[6] http://arstechnica.com/tech-policy/2016/09/media-outlets-sue-fbi-to-find-out-details-of-secret-iphone-unlocking-deal/