Update: Apple has provided iMore with the following statement:
"The kernel cache doesn't contain any user info," an Apple spokesperson told iMore, "and by unencrypting it we're able to optimize the operating system's performance without compromising security."
The kernel is the heart of an operating system and handles all the core operations of the computer. In iOS 10, the kernel cache is unencrypted. That's a marked difference from previous versions of Apple's iPhone and iPad software, and has led to some speculation that Apple either changed its policy on security, or that someone screwed up. My understanding is that the reason was something else entirely:
Streamlining the operating system.
Since it contains only the kernel, device drivers, and configuration files — and absolutely no user data — the iOS 10 kernel cache can be left unencrypted without any concerns over security or privacy.
And since it can be, it was.
Reader comments
Here's why the iOS 10 kernel cache is unencrypted
This is not correct; access to the kernal is a huge security issue. Major vulnerabilities in the system are found in the kernal. Many jailbreaks are implemented by finding these vulnerabilities.
The upside is it kicks the vulnerability hoarder's in the ****, since it will make them more public and be much more likely to reported to Apple. Hence why Linux is open and largely still a secure OS.
So, while, initially, yes, some vulns and bugs will be overflowing.. long term, it will give Apple a leg up on them ..
In an ideal world yes.
I’ll take Apple’s word over yours anytime.
The technical term for that is "security through obscurity". The vast majority of security researchers and experts have one of the following opinions about STO:
(A) it is no better then nothing
(B) it is worse then nothing because it falsely gives a feeling of security but no actual security (some will use the term "fraudulent" here)
(C) it is just barely better then nothing, but by such a slim margin that it is seldom worth the trouble of doing (spend the time on real security!), nor the risk of being confused with people that think it actually helps
Camp (C) is actually the smallest (I'm in that camp).
Real security is preventing jailbreaks, not hiding a key in the shed and hoping nobody thinks to look for it there.
Are you saying that Apple isn't proactive about security? The jailbreaks that Are found are few and far between. I am no security person, just trying to understand the situation and your thoughts.
You don't even know how to spell "kernel".
Kernels on Windows, Linux and Android (Linux) devices are unencrypted.
Are they also insecure?
You got me.
I dont understand why Apple doesn't just come out - ON THE RECORD - and give a reason for this. The fact they dont do this just leads to speculation.
This explanation makes no sense. The kernelcache has never contained user data - so why encrypt it all along up until now? Also, what all of the press in the last 24 hours or so has failed to mention is that it's only the 64-bit kernelcache that was left unencrypted in the iOS 10 beta. The 32-bit kernelcache is still encrypted. This makes it seem to me more like a mistake than a deliberate decision, otherwise why not make them both available unencrypted?
Maybe it's because that many 32bit iOS devices won't get the iOS 10 update. Vulnerabilities found in an unencrypted 32bit kernel can be used against these devices because it's unlikely that Apple will patch iOS 7, 8 or 9 after 9.3.3 finally is released.
It's actually pretty interesting. In 64 bit architectures, Address Space Layout Randomization (ASLR) is used to make sure code is not in predictable locations in memory in the event that malicious code was looking for kernel / application code to attack. ASLR is not quite as secure on 32 bit CPU's so other methods are usually deployed to make them more secure... like encryption.
I think we're losing sight of the fact that it's the kernel's cache - assuming I'm reading this correctly as well, heh heh. Decrypting the cache is certainly a speed vs. benefit architectural decision. My guess is that by leaving the cache decrypted, Apple will gain the speed boost it's seeking without having to re-work flash memory modules or having to procure faster storage into their next device family.
I'm betting it will get re-encrypted when flash storage pricing comes down, to their liking, on whatever speedy flash modules they've set their sights on for the next generation of devices. In short, probably a stop gap for the iPhone 7.
Go BlackBerry cough cough. Yes they are still alive and kicking.
Sent from the iMore App
Sooooooo encryption slows down the system now? Apple told us for year it doesn't. And this tiny bit of the system is such a bottleneck? Every little helps I guess.
Sent from the iMore App
Will Apple, as a parting gift to the iPhone 4s and iPads 2-4, please decrypt the kernel there? There are plenty of still serviceable units out there that could benefit from such optimization.
So, if it contain no user data and nothing to gain, why did Apple only do this now ?
Even without opening up the kernal, developers were reporting stuff back...
What gain is this ?
Are we to believe that since Apple opened the phone up to allow third party keyboards, extension support and what not, Apple just decided "hey, lets do the same thing for the Kernal." ? Given the fact Apple has encrypted the phone by default would probably encourage this as well.
my question is, is this just for the beta and then will it be encrypted once they are done testing?