Apple opens cryptographic libraries to developers in bid to encourage more security
Apple has opened its Security Framework and Common Crypto libraries to developers, hoping to foster tighter levels of security in third-party apps.
The Security Framework is used in iOS and OS X for managing keys, certificates, and trust policies, including storing the first two in the platforms' keychains. Common Crypto is tied to functions like symmetric encryption, hash-based message authentication codes, and digests. The pair both depend on a shared library known as corecrypto.
"Although corecrypto does not directly provide programming interfaces for developers and should not be used by iOS or OS X apps, the source code is available to allow for verification of its security characteristics and correct functioning," Apple said.
The company is typically slow to publish the source code for open-source components in its software. It has yet to do so for OS X El Capitan for instance, and while its Swift programming language is due to become open-source, that will only happen sometime before the end of 2015.
Security though is an important issue for Apple in light of growing privacy and malware threats. The company previously marketed its devices as virtually immune to malware, but both iOS and OS X have come under increasing levels of attack.
The Security Framework is used in iOS and OS X for managing keys, certificates, and trust policies, including storing the first two in the platforms' keychains. Common Crypto is tied to functions like symmetric encryption, hash-based message authentication codes, and digests. The pair both depend on a shared library known as corecrypto.
"Although corecrypto does not directly provide programming interfaces for developers and should not be used by iOS or OS X apps, the source code is available to allow for verification of its security characteristics and correct functioning," Apple said.
The company is typically slow to publish the source code for open-source components in its software. It has yet to do so for OS X El Capitan for instance, and while its Swift programming language is due to become open-source, that will only happen sometime before the end of 2015.
Security though is an important issue for Apple in light of growing privacy and malware threats. The company previously marketed its devices as virtually immune to malware, but both iOS and OS X have come under increasing levels of attack.
Comments
Is this being done to appease the US government or to actually help developers provide even stronger encryption?
I can't imagine any scenario where this could be viewed as a move of appeasement to the U.S. Government. Quite the contrary. Remember that crypto - in general - is STILL regarded as "munitions" and regulated under arms control export regulations.
There might be a small element of "help developers provide even stronger encryption" but it would be quite small. The algorithms used are well-known to all in the community and those doing research would probably not be using Apple's source as a base. However, the implementation might be a bit different and that could be advantageous.
The real reason for this is so that we all can verify that what's in Apple's libraries is actually what we think is there. No "extras", no backdoors. And no flawed implementation either.
It's worth noting that OS X will not boot if the boot-time self-check on the corecrypto library fails. Apple has really tightened things in this whole area over the last few years.
The crypto libraries implement standards like MD2, MD4, MD5, DES, 3DES, RC2, and RC4. The security community has recommended against even offering these standards as options for years. I definitely appreciate the view into Apple's crypto source for more modern algorithms, but they really need to remove the old stuff.
Using DES is worse than using nothing. With DES, developers can tell their clients that they use "government-level encryption" and be technically correct. The algorithm is badly, badly broken to the point that saying that is effectively lying, and Apple needs to not facilitate it.
Also, since few good developers are using that code, bugs in it may go undetected for quite some time. Heartbleed existed for years before anybody noticed it, and that was in one of the most widely-used pieces of cryptographic software ever made. Bugs in these old algorithms probably wouldn't have nearly the same impact, but they're still bugs.
Even Apple cannot say no if the government forces them.
This is actually just a mask to also give the Obama administration the ability to do what they said previously-develop their own frameworks for backdoor access.
Even Apple cannot say no if the government forces them.
Actually you don't know what you're talking about. It's past time to put the tinfoil hat away.
1. the "Obama administration" has not said that it would develop a framework to include backdoor access
2. there is no mechanism by which "the government" [in the U.S.] can force Apple to include to include some particular framework or other
If you dispute the accuracy of either of these two (2) statements then explain why - including links for the statement(s) and the legal foundation.
The crypto libraries implement standards like MD2, MD4, MD5, DES, 3DES, RC2, and RC4. The security community has recommended against even offering these standards as options for years. I definitely appreciate the view into Apple's crypto source for more modern algorithms, but they really need to remove the old stuff.
Using DES is worse than using nothing. With DES, developers can tell their clients that they use "government-level encryption" and be technically correct. The algorithm is badly, badly broken to the point that saying that is effectively lying, and Apple needs to not facilitate it.
Also, since few good developers are using that code, bugs in it may go undetected for quite some time. Heartbleed existed for years before anybody noticed it, and that was in one of the most widely-used pieces of cryptographic software ever made. Bugs in these old algorithms probably wouldn't have nearly the same impact, but they're still bugs.
You make a good point.But it's worth remembering that Apple has said that developers should not be using corecrypto directly but instead use the higher-level APIs.
If a developer wants to be silly enough to use DES then he[she] will do that - the code's available and it doesn't matter a great deal whether it's Apple's or roll-your-own. Stupid is as stupid does.
But there are still a few places where these old, deprecated algorithms need to be used for dealing with old stuff.
So I wouldn't recommend that they be removed - just fenced off with big "DANGER Will Robinson" signs all around.
https://assets.documentcloud.org/documents/2430092/read-the-obama-administrations-draft-paper-on.pdf
He's probably referring to this document which hardly goes so far as he infers.
https://assets.documentcloud.org/documents/2430092/read-the-obama-administrations-draft-paper-on.pdf
Thanks - that could quite well be the case. As you say, that's not at all where the administration is now.