Roger Fingas
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.
Malcolm Owen
Christine McKee
Andrew Orr
William Gallagher
11 Comments
This is an excellent move. Well done, Apple !
Just like SDK, apple is smart to continue holding developers hands, especially in the security department. Although attacks threw third party software shouldn't reflect on Apple itself, we all know there is a percentage of its users aren't as tech savvy and may not grasp such concepts as easily as its pro users.
Is this being done to appease the US government or to actually help developers provide even stronger encryption?
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.