Apple

Walter,

As noted in my previous email message....

There will be the standard corresponding "Role Guide document for the Crypto Officer" available when the validation is complete that will explain in much more detail about the Operational Environment, FIPS 140-2-Approved Algorithms, their corresponding CAVP Certificates, the use and maintaining of the modules, etc.

To restate quickly here for you again what I have noted a few times on the list before.....

** OSX *** Will be covered by

Service Crypto moduleApple's FIPS 140-2 Validation

• FIleVault 2 CoreCrypto Kernel YES
• TLS/SSL CoreCryptoYES - *IF* using FIPS Approved Algorithms
• S/MIME CoreCryptoYES - *IF* using FIPS Approved Algorithms
• SSH (OpenSSH) Uses OpenSSL NO
• SSL (OpenSSL) Uses its Own CryptoNO
• Heimdal KerberosUses its Own CryptoNO

• ...

How about the SSL provided in OS X Server web server?

Apache uses OpenSSL --> No.

How about the SSL embedded in Safari and Mobile Safari?

There is no SSL embedded in Safari or Mobile Safari. That would indicate a misunderstanding of the architecture. Safari relies on built-in OS services such as SecureTransport / CFNetwork / etc. which all use the CoreCrypto module.

How about the device encryption on iOS devices?

Yes. CoreCrypto Kernel.

- Shawn
________________________________________
Shawn Geddis
Security Consulting Engineer
Apple Enterprise Division

On Feb 13, 2013, at 10:54 AM, "Rowe, Walter" <email@hidden> wrote:

Hi Shawn,

Can you enumerate (either now or with the official certificate is announced) what Apple-distributed applications will solely use the Apple CoreCrypto modules for encryption? That is what people need to know.

We all understand that 3rd party application providers are responsible for any statements regarding applications they distribute that leverage Apple's CoreCrypto. Apple also needs to enumerate which Apple applications and services (both on iOS and OS X) will use CoreCrypto and therefore allow us as users to legitimately claim they are FIPS compliant. For example, will FileVault 2 rely on CoreCrypto? How about SSH? How about the SSL provided in OS X Server web server? How about the SSL embedded in Safari and Mobile Safari? How about the device encryption on iOS devices?

We have to be able to defend to our security officers where Apple draws the line and only Apple can tell us.

Thanks,

Walter

--

Walter Rowe, System Hosting

Enterprise Systems / OISM

email@hidden

301-975-2885

On Feb 13, 2013, at 10:19 AM, Shawn Geddis <email@hidden> wrote:

Hello Allan. Providing responses inline with your previous message....

On Feb 11, 2013, at 2:37 PM, "Marcus, Allan B" <email@hidden> wrote:

Good news Shawn, but what will it mean when iOS is FIPS compliant?

There will be the standard corresponding "Role Guide document for the Crypto Officer" available when the validation is complete that will explain in much more detail about the Operational Environment, FIPS 140-2-Approved Algorithms, their corresponding CAVP Certificates, the use and maintaining of the modules, etc.

It will mean that iOS 6 and higher will be using two FIPS 140-2 Conformance Validated Cryptographic Modules. Since the Validation will be for Overall Level 1, the module is not required to limit the use of the module by Applications or Services to only the FIPS 140-2-Approved algorithms that are provided by the modules.

Will is mean that when a program uses core crypto it's FIPS compliant?

As has always been the case, ANY Application/Service that relies on a FIPS 140-2 Validated Cryptographic Module AND uses FIPS 140-2 Approved Algorithms, can claim FIPS 140-2 Compliance. Keeping in mind again that this will be an Overall Level 1 Validation, it does not mean that iOS 6 will force ALL Third-party Applications to ONLY use FIPS 140-2 Approved Algorithms. That is the responsibility of the Application / Service and is not in Apple's control. Notable iOS Applications used by US Federal Government Agencies are using their own Cryptographic Modules for various reasons and therefore are not using the Crypto APIs provided by Apple.

How will we end users be able to know if an app is using core crypto in a FIPS compliant state?

Communicating whether a given Product is using a FIPS 140-2 Validated Cryptographic Module is the responsibility of the corresponding vendor. Apple's iOS and its corresponding services are using the CoreCrypto / CoreCrypto Kernel modules for the various cryptographic functions. Wether ANY given third-party Product (Application / Accessory) is utilizing the soon to be FIPS 140-2 Validated and built-in CoreCrypto / CoreCrypto Kernel module would come from the provider of that product.

Or will it mean there will be a way to turn FIPS compliant encryption on for the whole device?

iOS 6 has been engineered to always be in what the community has commonly referred to as "FIPS Mode" meaning all of the mandatory self-tests, continual tests, etc. are already enforced by the Product. In the case of iOS 6, Apple is simply waiting for the Validation Certificates for the two modules to be able to Claim FIPS 140-2 Validation for the crypto modules and FIPS 140-2 Compliance for iOS 6. Explanation of this will also come in the Role Guide document for the Crypto Officer.

By this I mean with a "pre-use" authentication?

Not sure I understand what you are getting at here. I am not aware of any such concept as a "Pre-Use Authentication" when it comes to the use of FIPS 140-2 validated cryptography. Are you referring to the approach some products take with allowing the user to turn On/Off FIPS Mode within their Product ?

Even with a password now I can access any non-encrypted data on the device before the password is entered (with out jailbreaking, simply by using a USB cable and freeware device access software)

Please allow me to clarify what is actually taking place. ALL User data on the iOS device (since iOS 4) is ALWAYS encrypted ALL the time. It is not an either or, or sometimes, or maybe, etc. All data is always encrypted and ALL of the File Encryption Keys (unique to ever single file) are then encrypted / protected by its corresponding Class Key (Key Encryption Key). In the case of files marked as "Always Available" (a.k.a. "ProtectionNone"), the keys are automatically able to be decrypted by that device's Unique/Unknown Device Key which is etched into the silicon. This means that, yes, those KEKs and hence the corresponding files are accessible to iOS after the device boots up without human interaction -- that is by design. ANY data that ANY Application or Service wishes to protect even to requiring the device to be unlocked at least once (a.k.a. "On First Unlock") would do so by requesting so upon initial File Write or File Re-write. Nothing new here and has been the case since iOS 4 with the initial availability of "Enhanced Data Protection".

Hopefully, this helped to further clear things up for you and others.