Apple intentionally left iOS 10 kernel unencrypted to optimize system performance

Responding to speculation as to why the iOS 10 beta kernel was left unencrypted, Apple on Wednesday confirmed the move was made deliberately to streamline system performance.

Explaining the decision, an Apple spokesperson toldTechCrunch that because iOS 10's kernel cache does not contain sensitive information, it does not need to be encrypted.

"The kernel cache doesn't contain any user info, and by unencrypting it we're able to optimize the operating system's performance without compromising security," the representative said.

Apple traditionally obfuscates the kernel in order to protect its prized operating system from unwanted probing or reverse engineering, potentially by nefarious agents. The small risk — or no risk, according to Apple — of furnishing unobscured kernel cache data is likely outweighed by potential benefits.

As noted by experts earlier this week, Apple's decision allows security researchers to — legitimately — dive into the "heart" of iOS for the first time. In particular, white hats, or researchers who find and disclose vulnerabilities publicly in an effort to secure consumer devices, now have unprecedented access to Apple's code, meaning more eyes are on the lookout for potential weaknesses.

Further, Apple's move could deflate the iOS exploit market run by so-called "gray hats," or experts who take part in the ethically questionable practice of selling software vulnerabilities to government agencies or companies. The issue is of particular interest to Apple, a company that just this year tussled in court with the U.S. Justice Department over data privacy.

In February, Apple was ordered to bypass iOS security mechanisms to gain access to an iPhone linked to last year's San Bernardino terror attack. The company refused, mounting a legal defensive in response, but the case was rendered moot when the FBI cracked the device on its own using a purchased zero-day vulnerability.

12 Comments

elijahg 2823 comments · 18 Years

About 8 years ago

So it was the kernel cache that was unencrypted rather than the kernel itself? That's vastly different to previous reports.

redefiler 323 comments · 11 Years

elijahg said:

So it was the kernel cache that was unencrypted rather than the kernel itself? That's vastly different to previous reports.

And the rampant internet nerd press speculation... it's a system performance driven change.

Soli 9981 comments · 9 Years

elijahg said:

So it was the kernel cache that was unencrypted rather than the kernel itself? That's vastly different to previous reports.

As I understand it, the kernel is unencrypted—which isn't a big deal for security since their XNU kernel has been open source since the beginning, even if only when pulled from Darwin, not a shipping OS on their devices—but their mention of the kernel cache being unencrypted is because that's the only part of the kernel that could potentially contain sensitive user data. This confirms that the cache doesn't.

misa 827 comments · 13 Years

Soli said:

elijahg said:

So it was the kernel cache that was unencrypted rather than the kernel itself? That's vastly different to previous reports.

As I understand it, the kernel is unencrypted—which isn't a big deal for security since their XNU kernel has been open source since the beginning, even if only when pulled from Darwin, not a shipping OS on their devices—but their mention of the kernel cache being unencrypted is because that's the only part of the kernel that could potentially contain sensitive user data. This confirms that the cache doesn't.

To be more specific, Two things have to be unencrypted for a computer to operate:
a) The Kernel (not necessarily the drivers)
b) The root/boot file system (sometimes launched from a ramdisk like on Linux)

The bootloader will still only run a signed kernel. So that's why the "danger" doesn't exist.

ppietra 288 comments · 14 Years

It is not a very convincing reason. That is the sort of justification one would give for less capable hardware and older software not a justification for further evolution of a system that leaves behind older hardware that had proven to be able to handle that encryption.
It would only make sense if it was somehow necessary for iOS transition to the new Apple file system, but since that won’t happen for another year it would also be a bit premature.