Apple intentionally left iOS 10 kernel unencrypted to optimize system performance

Posted:
in iPhone edited June 2016
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.

Comments

  • Reply 1 of 12
    elijahgelijahg Posts: 2,759member
    So it was the kernel cache that was unencrypted rather than the kernel itself? That's vastly different to previous reports.
    lollivermejsricjbishop1039netmagedoozydozenirelanddysamoriaredgeminipajony0
  • Reply 2 of 12
    redefilerredefiler Posts: 323member
    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.
    elijahg
  • Reply 3 of 12
    SoliSoli Posts: 10,035member
    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.
    elijahg
  • Reply 4 of 12
    misamisa Posts: 827member
    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.

    numenorean
  • Reply 5 of 12
    ppietrappietra Posts: 288member
    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.
  • Reply 6 of 12
    ppietrappietra Posts: 288member
    I have read from Mathew Solnik that it could be because of Apple WatchOS. That could make some sense, since it is basically the same kernel and any performance boost is welcomed, but it still seems a step backwards.
  • Reply 7 of 12
    dysamoriadysamoria Posts: 3,430member
    ppietra said:
    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.
    Every new version of the OS is bigger and slower. This might be a minor attempt to address that (or compensate for iOS 10's inevitable speed reduction compared to its predecessor) without spending an entire is release optimizing everything (which REALLY SHOULD be done, but it takes away development time from new features they need to market new devices with). 
    edited June 2016
  • Reply 8 of 12
    dugbugdugbug Posts: 283member
    ppietra said:
    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.
    Less capable hardware like the apple watch running live apps now?
  • Reply 9 of 12
    ppietrappietra Posts: 288member
    dysamoria said:
    ppietra said:
    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.
    Every new version of the OS is bigger and slower. This might be a minor attempt to address that (or compensate for iOS 10's inevitable speed reduction compared to its predecessor) without spending an entire is release optimizing everything (which REALLY SHOULD be done, but it takes away development time from new features they need to market new devices with). 
    from the little I understand most of the impact from kernelcache encryption would be on system boot, the kernel always ran unencrypted and most of its code was on RAM, so no much of an impact on system use speed from this, specially when Apple’s encryption and flash speed has only got better with every device.
    However they seem to have made a lot of changes and might be aiming to make the kernel more efficient for devices like the Watch, not so much a problem with the iPhone
  • Reply 10 of 12
    ppietrappietra Posts: 288member
    dugbug said:
    ppietra said:
    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.
    Less capable hardware like the apple watch running live apps now?
    yes that can be one reason like I said already, though it would be interesting to know in what way.
  • Reply 11 of 12
    What's a back-of-the-envelope guess on the speed change for a powerful iPhone? 1%?
  • Reply 12 of 12
    volcanvolcan Posts: 1,799member
    Soli said:
    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.
    If the there is full disk encryption then the kernel cache would also be encrypted so in that case the boot process would involve booting from a different partition that was not encrypted because the drivers necessary to link against the kernel would be unavailable otherwise. I'm not sure this is anything new. It has probably been that way since the beginning. 

    Also I don't think there would be anything user specific in the kernel cache since it is literally just the kernel itself and all the kernel extensions linked together into a single file to expedite the boot loading process.
    edited June 2016
Sign In or Register to comment.