The recovery key is also something that enterprise and government users can manage, as Apple provided for using FileVaultMaster.keychain as a way to set a known recovery key. If you need more information about how to use FileVaultMaster.keychain as your FileVault
2 recovery key, I recommend picking up a copy of the August 2011 issue of MacTech. In that issue, there's an article covering FileVault 2 use in the enterprise. (Disclaimer: I wrote the article.)
For anyone planning to attend the upcoming MacTech conference in LA, I'll be giving a session on FileVault 2 which will include information about how to set up a managed deployment of FileVault 2.
Thanks,
Rich
On Oct 11, 2011, at 9:53 AM, Rowe, Walter wrote:
If any of you are part of the developer program, this was discussed in length on the developer forums. There was a WWDC session that detailed the changes coming in Lion for the encryption modules and engine. Lion uses all new stuff. If I recall correctly, it
is based on the work done with iOS 5 that is currently going through the FIPS process. The rationale for rolling their own was that Apple wanted a stable, controlled encryption platform on which their products rely rather than the often changing OpenSSL platform
over which Apple had no control. This lets Apple retain FIPS validated status more easily (my thought, not Apple's) across OS upgrades (iOS, OS X) and across devices (iPad, iPhone, Mac).
--
Walter Rowe, System Hosting
Enterprise Systems / OISM
301-975-2885
On Oct 11, 2011, at 9:39 AM, Link, Peter R. wrote:
Shawn,
I'd like to second this request and ask for a detailed explanation on the algorithms used for FileVault 2. We received an exception from our DAA for the original FileVault because it was in process. I would like to put together paperwork for another exception
for the much more secure FileVault 2 but it would be better if I was able to cite specific encryption algorithms and their (hopefully) validated status as a starting point. A statement from Apple on where FV2 fits into the FIPS validation process would also
be nice. We're not asking Apple to divulge secrets, just to give us some information to make our DAA feel comfortable enough to accept the risk. Of course, I'd also like to better understand which algorithms Apple software is using as well as which non-Apple
applications are still using the CDSA/CSP module. This is where it gets real complex and where we'll need Apple's assistance in preparing an exception document.
If you can make this happen, I'd also like to know if there's any way to add an acceptance banner either before the initial unlocking (single sign-on) logon or on the same screen as the unlocking (with the ability to cancel, which shuts down the Mac). Of course,
Recovery Key protection is something that will cause all sorts of problems for enterprise and government users since I doubt anyone will be able to allow Apple to store this key. I know the answer to my next question but I'll ask it anyway. Any chance of adding
this capability to Lion Server (or any other locally-managed system)?
stuff I've found so far
http://support.apple.com/kb/HT4790 good support article
http://csrc.nist.gov/groups/STM/cavp/#08 closest I could find to XTS-AES 128 but not sure if these are approved or still in review
On Oct 11, 2011, at 5:05 AM, Miller, Timothy J. wrote:
On 10/9/11 10:32 PM, "Shawn Geddis" <email@hidden> wrote:
The addition of "Apple FIPS Cryptographic Module" to the Modules in
Process list [3] is a reflection of the "re-validation" of the CDSA/CSP
module shipped in Mac OS X 10.6 and validated on March 9, 2011. OS X
Lion (v10.7) does not use the CDSA/CSP module, but Apple is performing
this re-validation to provide continued validation for all third-party
applications using this module.
Ok, great, but when will Lion's new architecture enter CMVP? You know how
this works, Shawn--we can get exceptions in C&A only as long as we can
file POA&Ms, emphasis on 'M' (milestones).
-- T
_______________________________________________
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
Peter Link
Cyber Security Analyst
Cyber Security Program
Lawrence Livermore National Laboratory
PO Box 808, L-315
Livermore, CA 94550
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
_______________________________________________
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
---
JFRC Help Desk
phone: x4030
The best way to get in touch with me is through email.
|