Re: [Fed-Talk] FIPS question
Re: [Fed-Talk] FIPS question
- Subject: Re: [Fed-Talk] FIPS question
- From: "Lamb, John (NIH/NHLBI) [C]" <email@hidden>
- Date: Tue, 28 Aug 2012 12:13:38 -0400
- Acceptlanguage: en-US
- Thread-topic: [Fed-Talk] FIPS question
Shawn,
Thanks for the clarification. Are we to take this to mean that once CoreCrypto Kernel for OS X 10.8 is validated and Filevault 2 can be considered "FIPS 140-2 Compliant" that this extends only to Filevault 2 in OS X 10.8, and does not retroactively apply to Mac OS X 10.7? (Hence, on the level of abstraction our superiors care about, there will be two separate FileVault 2s; one compliant, one not.)
--
John Lamb
Desktop Support Technician [Contractor]
Customer Support Branch
Center for Biomedical Informatics (CBI)
National Heart Lung and Blood Institute, NIH
10 Center Drive - Building 10 6C103
Bethesda, MD 20892-7994
Telephone (240) 751-6562 | Email: email@hidden |
NHLBI Computer Services: http://insider.nhlbi.nih.gov/computer
From: Shawn Geddis <email@hidden<mailto:email@hidden>>
Date: Tuesday, August 28, 2012 11:42 AM
To: "email@hidden<mailto:email@hidden>" <email@hidden<mailto:email@hidden>>
Subject: Re: [Fed-Talk] FIPS question
Allan, Bill, Peter, et. al.,
Your original question Allan was...
Is there any reason to use FIPS mode when not using FileVault?
This highlights the everyday challenge to always "doing the right thing." Thanks for asking. The short answer to your question is YES, but of course there are a lot of details behind that simple answer.
As government agency staff (Admins/Users/etc.), you are all charged with handling, processing and protecting public/private sector data at rest and during transmission. As I hope everyone is well aware of, the intent of requiring FIPS 140-2 Level 1 Conformance Validation for crypto modules leveraged by products you use is to ensure that they are following best practices, ensuring protection of the data (to the best practical levels known today), while providing a simpler way to identify those products that adequately meet these requirements. That is easier for me to write out in a sentence here than it is for many of you to ensure is the case on your large number of massively distributed systems across the enclave. Oversimplification of the goal is that all parties involved are following best practices.
Please keep in mind that the crypto modules used in OS X Mountain Lion v10.8 have not yet completed the validation process and have not yet received the CMVP Validation Certificate. As I hope everyone is aware, it is in Process and is expected to be complete in the coming months.
"FIPS Mode" is somewhat of a generic term in that it refers to putting a system or product in a specific mode that is then compliant with the validation it received -- usually in reference to the additional POST/Continual integrity test performed. Products could then ship preconfigured without the overheard of the tests, yet be easily enabled by those that need or require it. We all wish that products always performed the appropriate POST and continual integrity tests to ensure all is well with the process of cryptography on a given platform. Apple's goal has been to do just that -- have the platform always perform the required POST and continual integrity tests without the need for any modifications or configuration changes.
I had recently generated a quick chart of the OS versions, corresponding crypto modules in use, their status, etc. to help folks understand the complexities of what is really covered in the various validations. I hope this helps for this discussion as well as your internal discussions moving forward.
Snow Mountain
Leopard Lion Lion
v10.6 v10.7 v10.8
CDSA (YES) CDSA (YES) CDSA (NO)
FileVault 1 (CDSA) -- FileVault 1 (CDSA) -- FileVault 1 (CDSA)
CDSA - DeprecatedCDSA - Deprecated
CoreCrypto (NO) CoreCrypto (In-Process)
-- (Application Crypto) -- (Application Crypto)
CoreCrypto Kernel (NO)CoreCrypto Kernel (In-Process)
-- FileVault 2 (NO) -- FileVault 2 (CC)
Key:
YES - "Received" FIPS 140-2 Level 1 Conformance Validation
NO - "Never Received" FIPS 140-2 Level 1 Conformance Validation
CDSA - Common Data Security Architecture
FileVault 1 - Container Based FileVault (now referred to as "Legacy FileVault")
FileVault 2 - Full Disk Encryption (v2 which first appeared in OS X Lion)
Deprecated - Service has been removed from OS Use (may disappear from OS at any time)
CoreCrypto - Next Gen Crypto module - replaces CDSA as Crypto Module for Apps
CoreCrypto Kernel - Next Gen Crypto module - Embedded/Used only by Kernel
For OS X Lion v10.7:
• CDSA - FIPS 140-2 (revalidated), used by FileVault 1 (Legacy FileVault)
• All 3rd PArty Products using CDSA can claim FIPS 140-2 Compliance
• CoreCrypto Kernel - NOT FIPS 140-2 Validated - used by FileVault 2 (FDE)
For OS X Lion v10.8:
• CDSA - NOT FIPS 140-2 Re-validated -- used by FileVault 1 (Legacy FileVault)
• All 3rd PArty Products still using CDSA can no longer claim FIPS 140-2 Compliance
• CoreCrypto Kernel - FIPS 140-2 Validation - "In-Process" - used by FileVault 2 (FDE)
On Aug 28, 2012, at 8:33 AM, William Cerniuk <email@hidden<mailto:email@hidden>> wrote:
My understanding is that the security subsystem has been required for use by all Apple software now.
Where a piece of software on the system prior may have used open source SSL or some other implementation other than the common system resource, now all software is using the system supplied SSL. Other crypto technologies were similarly corralled.
Be careful here though. There are Algorithms included in the crypto module that were not / can not achieve FIPS 140-2 Level 1 validation for various reasons. This may pertain to the algorithm itself, the implementation used by Apple or even in some cases the Key-sizes used. It is not the case with Level 1 validation that only FIPS Approved Algorithms are available, but rather that you clearly know which algorithms (ie. AES) and corresponding algorithm modes (AES CBC) are compliant.
When the multiple modules (CoreCrypto & CoreCrypto Kernel) in OS X Mountain Lion v10.8 achieve FIPS 140-2 Level 1 Conformance Validation you will still need to be aware of what algorithms are in use, under what services, and whether those received a certificate from CAVP to ensure you are compliant.
Despite how many face discussions about FIPS 140-2 Conformance Validation, it is not simply a check-box and all is forgotten. It is intended to be that simple, but in reality it is much more complex.
While I would not assume, it would make sense that if Apple had a faster implementation of some crypto algorithm which was not cleared by NIST, turning FIPS mode off would kick in the afterburners for a given crypto technology in the system.
If a system allows you to disable the "FIPS Mode", the algorithms in use do not change, but rather the additional POST/Continual integrity test previously performed may not be enforced and hence the system would not actually be compliant.
Now let me address some additional points brought out by Peter Link...
On Aug 28, 2012, at 10:33 AM, "Link, Peter R." <email@hidden<mailto:email@hidden>> wrote:
just so we have the Apple references for each OS--
http://support.apple.com/kb/HT5396 FIPS-mode for Mountain Lion
http://support.apple.com/kb/HT5239 FIPS-mode for Lion
http://support.apple.com/kb/HT4603 FIPS-mode for Snow Leopard
"FIPS Mode" for various products can mean different scenarios as I mentioned earlier. What actually changes and the ramifications change between the three versions of OS X noted above. Let me try to explain here, but I will acknowledge up front that this is much more complex than can be easily conveyed to and understood by everyone on this list. I'll try...
As noted earlier, FIPS 140-2 Level 1 Conformance Validation for the Crypto Module used in Mac OS X Snow Leopard v10.6 and still available for third-party Apps only on OS X Lion v10.7 was for CDSA. That architecture and the logical boundary of the cryptographic module meant that as part of the POST (Power On Self Test) we had to calculate the HMAC-SHA-1 Hash of the whole mach kernel (/mach_kernel) and compare that to a stored value in a READ-ONLY EDC file. This was because the PRNG is embedded in the kernel and the kernel integrity could not be validated using an RSA Signature test.
This is the part that concerns me--
Important: Before performing any OS X Lion updates, such as via Software Update, you should disable “FIPS Mode”. Otherwise, the computer may not start up successfully after the restart. After performing the software update, the Crypto Officer will need to re-enable “FIPS-Mode” following the instructions in the Crypto Officer Role Guide.
Since ANY OS Update would potentially (and did) update the mach kernel, it would then invalidate the value stored in the EDC file and would cause a failure during the POST at next boot -- exactly what several folks experienced when they performed the 10.7.4 update while it was still configured in "FIPS Mode." It was an unfortunate requirement that Admins needed to disable "FIPS Mode" (moved Launchd item aside) prior to the OS update and a re-running of the FIPS Administration installer after the update, but that was because OS/Security Updates did not contain the necessary logic to be able to successfully/securely patch the EDC file during the OS/Security Update.
If you run the test command without having installed the test applications, you'll get a file not found error. All this means is it couldn't find the file, it doesn't necessarily mean the OS isn't in FIPS mode (which it should be by default).
The "test applications" on v10.6 & v10.7 you are referring to was the FIPSPerformSelfTest, cryptoKAT and postsig. They were the POST Tools which were also available to Crypto Officers for use at any time -- it was NOT the only tests taking place on the system. So much of the FIPS 140-2 Tests were embedded in the product and ALWAYS running. It was just necessary to have these additional tools and related files on those versions of the OS installed to force the required POST on all of the components, algorithms, etc.
For those sites managing software installation, a little test script would be required to disable FIPS mode, update the software, then re-enable it after restart. For those sites without an adequate level of Mac support, you get to hope things don't get messed up. Testing the existence of FIPS-mode should be part of the software update process from Apple, not something we have to remember to do ourselves. Of course, having the OS in FIPS-mode by default should be the way Apple protects its users.
Moving forward, Apple's goal has always been to ensure that the system was always running in "FIPS Mode." With the release of OS X Mountain Lion v10.8, we were close, but there were still challenges that require folks to install a patch. Please keep in mind that CoreCrypto / CoreCrypto Kernel modules in OS X Mountain Lion v10.8 have not yet received their FIPS 140-2 Level 1 Conformance Validation Certificate, so Apple is not claiming OS X Mountain Lion v10.8 is currently FIPS 140-2 Compliant. It will be, but until then we are providing what you will need to keep it in compliance.
NOTE: There is NO NEED to perform any modifications/disablement between OS/Security Updates for OS X Mountain Lion v10.8.x. That was an issue ONLY for the CDSA-based cryptographic module boundary used in v10.6 & 10.7. Once you patch your 10.8.x system [ http://support.apple.com/kb/DL1555 ], you will not need to perform any alterations for any subsequent minor release for 10.8.
I hope this helps to squelch the confusion folks may have on this.
For those that may no longer have or never saw the previous message I sent providing lots of information on the status and specifics on the FIPS 140-2 Level 1 Conformance Validation for the CoreCrypto / CoreCrypto Kernel modules, here it is.
_______________________________________________
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