Re: [Fed-Talk] DISA to test mobile ID, replacement for CAC
Re: [Fed-Talk] DISA to test mobile ID, replacement for CAC
- Subject: Re: [Fed-Talk] DISA to test mobile ID, replacement for CAC
- From: "Miller, Timothy J." <email@hidden>
- Date: Wed, 16 Apr 2014 18:21:00 +0000
- Thread-topic: [Fed-Talk] DISA to test mobile ID, replacement for CAC
>I wonder what *current* mobile devices have a "trustable storage"?
It depends on what you mean by Trusted Execution Environment (TEE).
All GSM phones have a Universal Integrated Circuit Card (UICC)--a.k.a. SIM--which provides a TEE. This is essentially a smart card, and most support the Global Platform standard and many are actually Java Card Open Platform (JCOP) cards--the same as the CAC and many PIV cards.
Any phone with Near Field Communications (NFC) has an Embedded Secure Element (eSE) which provides a TEE. The eSE is required to be Global Platform compliant and many are also JCOP devices [1].
Then there's Advanced Security Secure Digital (ASSD) cards which provide a TEE. These are external cards using any of the Secure Digital (SD) form factors--SD, miniSD, and microSD. ASSD devices are also Global Platform compliant and usually are JCOP as well.
Finally, modern ARM chips have a hardware based virtualization capability (TrustZone and similar features) that provides a TEE. Almost any application can run inside an ARM TEE, so you can (if you want) implement any interface. I've seen a demonstration of an Android Keystore running in an ARM TEE providing a PKCS#11 interface to Android applications [2].
While I don't have details of the project at DISA, I believe they'll focus on ARM TEEs. There are problems with the other secure elements that make them impractical, and they aren't available on iOS devices.
For the most part, a UICC/SIM or eSE would be unavailable for use because the keys needed to provision the device--i.e., securely generate key material, load applets, and load externally generated key material--are held by the Mobile Network Operator (MNO) or the mobile device manufacturer (OEM or Google), and they won't share. Allowing more than one entity hold these secure channel keys would violate requirements for eAuthentication Level 4 (see NIST SP 800-63 and SP 800-157) anyway.
ASSDs don't have this problem, but they are probably off the table because most OEMs are moving away from providing SD card slots. E.g., my last two Android phones had no SD card support.
-- T
[1] Interestingly, NFC includes a capability to use the eSE as a smartcard *over the NFC protocol* (called Host Card Emulation (HCE)); this would allow you to use the on-phone credentials with, say, an application running on a laptop. Suffice to say that HCE isn't the use case under discussion here.
[2] If you have a TEE with limited internal storage, secure storage for large items is trivial: encrypt stored material with a key stored in the TEE, and write the encrypted blob to general storage. This is how TPMs work using the Storage Root of Trust, and it's how Android Open Source Project (AOSP) has approached leveraging the ARM TEE for key storage (called Keymaster). I don't know enough about iOS internals, but TrustZone support for iOS security services wouldn't surprise me in the least.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden