[Fed-Talk] unsubscribe
[Fed-Talk] unsubscribe
- Subject: [Fed-Talk] unsubscribe
- From: Court Kizer <email@hidden>
- Date: Wed, 16 Apr 2014 12:03:21 -0700
On Apr 16, 2014, at 12:00 PM, email@hidden wrote:
> Send Fed-talk mailing list submissions to
> email@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.apple.com/mailman/listinfo/fed-talk
> or, via email, send a message with subject or body 'help' to
> email@hidden
>
> You can reach the person managing the list at
> email@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Fed-talk digest..."
>
>
> Today's Topics:
>
> 1. DISA to test mobile ID, replacement for CAC (Dan O'Donnell)
> 2. Re: DISA to test mobile ID, replacement for CAC
> (Martin, Robert A.)
> 3. Re: DISA to test mobile ID, replacement for CAC
> (Blumenthal, Uri - 0558 - MITLL)
> 4. Re: DISA to test mobile ID, replacement for CAC
> (Miller, Timothy J.)
> 5. Re: DISA to test mobile ID, replacement for CAC (Neely, Lee)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 15 Apr 2014 16:17:01 -0700
> From: "Dan O'Donnell" <email@hidden>
> To: Fed Talk <email@hidden>
> Subject: [Fed-Talk] DISA to test mobile ID, replacement for CAC
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset="windows-1252"
>
> DISA has apparently announced the start of testing on a replacement or supplement for CAC.
>
> http://www.c4isrnet.com/article/M5/20140409/C4ISRNET07/304090032/DISA-tests-move-away-from-CAC
>
> One month ago, the National Institute for Standards and Technology released draft guidance for government agencies looking to institute derived credentials, which store security certificates directly on a device instead of through a separate piece – in the case of DoD, the CAC. NIST’s guidelines for derived credentials outline the use of secure, standards-based public-key infrastructure (PKI) credentials that use digital tokens instead of a physical card reader.
>
> “We’ve gotten huge benefits from the PKI infrastructure in DoD and the CAC has carried us a long way; we're now doing a similar thing on SIPRNet,” said Mark Orndorff, DISA chief information assurance executive. “So our main effort in mobility is to bring that technology into the mobile platform, and the way I see it, the key is the derived credential and using the capabilities that the leading-level device vendors have built in to their platforms so we can bring our certificate into their devices.”
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.apple.com/mailman/private/fed-talk/attachments/20140415/333b6cd7/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 16 Apr 2014 07:45:50 -0400
> From: "Martin, Robert A." <email@hidden>
> To: "Dan O'Donnell" <email@hidden>, Fed Talk
> <email@hidden>
> Subject: Re: [Fed-Talk] DISA to test mobile ID, replacement for CAC
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Dan,
>
> Saw the same article and its very misleading.
>
> It is my understanding that this is not a replacement for CAC but rather
> DoD is experimenting on using the CAC issuance infrastructure to
> trustably place a credential derived from your CAC on mobile devices so
> they can use the derived credential instead of the actual CAC for
> authentication in the mobile space.
>
> This would only be for mobile devices that have a "trustable storage"
> capability for such a cert. It is my understanding that the trustable
> storage would be TEE/TPM based.
>
> The point being to no longer need CAC readers/sleds for each device -
> instead you'll use the derived credential from your CAC that was placed
> on your mobile device.
>
> Bob
>
> On 4/15/14, 7:17 PM, Dan O'Donnell wrote:
>> DISA has apparently announced the start of testing on a replacement or
>> supplement for CAC.
>>
>> http://www.c4isrnet.com/article/M5/20140409/C4ISRNET07/304090032/DISA-tests-move-away-from-CAC
>>
>> One month ago, the National Institute for Standards and Technology
>> released draft guidance for government agencies looking to institute
>> derived credentials, *which store security certificates directly on
>> a device instead of through a separate piece* – in the case of DoD, the
>> CAC. NIST’s guidelines for derived credentials outline the use of
>> secure, standards-based public-key infrastructure (PKI) credentials that
>> use digital tokens instead of a physical card reader.
>>
>> “We’ve gotten huge benefits from the PKI infrastructure in DoD and the
>> CAC has carried us a long way; we're now doing a similar thing on
>> SIPRNet,” said Mark Orndorff, DISA chief information
>> assurance executive. “So our main effort in mobility is to bring that
>> technology into the mobile platform, and the way I see it, the key is
>> the derived credential and using the capabilities that the leading-level
>> device vendors have built in to their platforms so we can bring our
>> certificate into their devices.”
>>
>>
>> _______________________________________________
>> 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
>>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 16 Apr 2014 15:44:42 +0000
> From: "Blumenthal, Uri - 0558 - MITLL" <email@hidden>
> To: Fed Talk <email@hidden>
> Subject: Re: [Fed-Talk] DISA to test mobile ID, replacement for CAC
> Message-ID: <CF741D2E.143B0%email@hidden>
> Content-Type: text/plain; charset="utf-8"
>
> On 4/16/14 7:45 , "Martin, Robert A." <email@hidden> wrote:
>
>> Dan,
>>
>> Saw the same article and its very misleading.
>
> I thought so. :-)
>
>> .....DoD is experimenting on using the CAC issuance infrastructure to
>> trustably place a credential derived from your CAC on mobile devices...
>>
>> This would only be for mobile devices that have a "trustable storage"
>> capability for such a cert. It is my understanding that the trustable
>> storage would be TEE/TPM based.
>
> I wonder what *current* mobile devices have a "trustable storage"?
>
>
>
>> On 4/15/14, 7:17 PM, Dan O'Donnell wrote:
>>> DISA has apparently announced the start of testing on a replacement or
>>> supplement for CAC.
>>>
>>>
>>> http://www.c4isrnet.com/article/M5/20140409/C4ISRNET07/304090032/DISA-tes
>>> ts-move-away-from-CAC
>>>
>>> One month ago, the National Institute for Standards and Technology
>>> released draft guidance for government agencies looking to institute
>>> derived credentials, *which store security certificates directly on
>>> a device instead of through a separate piece* – in the case of DoD, the
>>> CAC. NIST’s guidelines for derived credentials outline the use of
>>> secure, standards-based public-key infrastructure (PKI) credentials that
>>> use digital tokens instead of a physical card reader.
>>>
>>> “We’ve gotten huge benefits from the PKI infrastructure in DoD and the
>>> CAC has carried us a long way; we're now doing a similar thing on
>>> SIPRNet,” said Mark Orndorff, DISA chief information
>>> assurance executive. “So our main effort in mobility is to bring that
>>> technology into the mobile platform, and the way I see it, the key is
>>> the derived credential and using the capabilities that the leading-level
>>> device vendors have built in to their platforms so we can bring our
>>> certificate into their devices.”
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>> _______________________________________________
>> 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
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 5144 bytes
> Desc: not available
> URL: <https://lists.apple.com/mailman/private/fed-talk/attachments/20140416/141ce2c7/attachment-0001.p7s>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 16 Apr 2014 18:21:00 +0000
> From: "Miller, Timothy J." <email@hidden>
> To: "'Blumenthal, Uri - 0558 - MITLL'" <email@hidden>, Fed Talk
> <email@hidden>
> Subject: Re: [Fed-Talk] DISA to test mobile ID, replacement for CAC
> Message-ID:
> <email@hidden>
> Content-Type: text/plain; charset=utf-8
>
>> 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.
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 16 Apr 2014 18:28:18 +0000
> From: "Neely, Lee" <email@hidden>
> To: "Miller, Timothy J." <email@hidden>, "'Blumenthal, Uri - 0558
> - MITLL'" <email@hidden>, Fed Talk <email@hidden>
> Subject: Re: [Fed-Talk] DISA to test mobile ID, replacement for CAC
> Message-ID:
> <email@hidden>
>
> Content-Type: text/plain; charset=utf-8
>
> Interesting thread! Thanks for sharing.
>
> Interestingly, the PKI community I work with would love to have some form of derived credential to allow Encryption certificates that are stored in a PIV (or CAC) card to be used on a smartphone without a PIV/CAC reader. I'm differentiating Signing certificates as non-repudiation is a different level of assurance and sends us into compliance land. So talk of DISA or other folks working this get my attention.
>
> Lee
>
>
> -----Original Message-----
> From: fed-talk-bounces+neely1=email@hidden [mailto:fed-talk-bounces+neely1=email@hidden] On Behalf Of Miller, Timothy J.
> Sent: Wednesday, April 16, 2014 11:21 AM
> To: 'Blumenthal, Uri - 0558 - MITLL'; Fed Talk
> Subject: Re: [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
>
>
>
> ------------------------------
>
> _______________________________________________
> Fed-talk mailing list
> email@hidden
> https://lists.apple.com/mailman/listinfo/fed-talk
>
> End of Fed-talk Digest, Vol 11, Issue 48
> ****************************************
_______________________________________________
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