On Jan 14, 2015, at 12:20 PM,
email@hidden wrote:
On Jan 14, 2015, at 15:00 ,Beatty, Daniel D CIV NAVAIR, 474300D wrote:
2) The capabilities that allow this attack are the same ones that would e.g. allow the installation of PIV/CAC card drivers for use with Filevault 2 at boot.
I'm actually kind of curious how much interest there would be in 2), since it seems like a fun project to me.
Well, ignoring my great dis-satisfaction with he complexity and fragility of PKI and token readers*, and the vulnerabilities introduced by depending on an external device of any sort….
While Apple and the Fed may feel free to ignore relevant standards, I do not feel so empowered. X.509 PKI and one of the several smart card “standards” would seem to be the way to go. I do agree on both your points though.
I'd worry that introducing this would require the authentication to happen "too far into" the boot sequence. From a reliability/surety perspective, limiting the complexity of the crypto stuff, and in particular verifying and
then unlocking the disk as early as possible, would seem to me to be a good principle.
Well, there’s no doubt that it would increase the complexity and decrease the reliability — requiring additional infrastructure complexity to deal with the failures. However, if it can be done “properly” then it should just be a different mechanism for getting
the top-level disk key at the same pre-disk point in the boot process.
But what would people think of something like Apple's iPhone fingerprint sensor as part of a mutli-factor authentication scheme for laptops?
Fingerprints (and other biometrics) can’t be administratively changed if stolen. Due to noise in the reading process fingerprints can only provide a small single-digit number of bits of entropy for cryptographic applications.
If the reader can be properly protected (guard with an M16?) and the use is strictly local, then they provide a useful addition to other authentication factors. For a cell phone the user/owner may be a reasonable guard. As the device gets larger the likelihood
of the device being left unattended long enough to be compromised increases. As usual, it depends.
For myself, there isn’t a lot I’d protect with that as the *only* factor, but there’s a lot I’d enjoy protecting with it as a second/third factor.
dave
* for those who argue in favor of CAC as a token for use in deployed ground forces, I offer them a CAC-enabled rifle and a trip to Afghanistan. (If the CAC can't be authenticated, the rifle won't fire.)
LOL 8-D
People designing generic mechanisms also assume generic use cases. Understandable, but not reliable as a design process. You need to verify the design against the real use case.
Personal email.
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