It doesn't have to be mutually exclusive, but I mean, it doesn't offer any user data and from what we know there is no way to get user data from this. I don't know...I could be wrong.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Confirms Unencrypted Kernel in iOS 10 Beta is Intentional
- Thread starter MacRumors
- Start date
- Sort by reaction score
I suspect this was the result of a compromise with law enforcement to make the platform more accessible. With the base operating system running unencrypted they can indirectly access the user's data by jailbreaking the phone. Apple can still say it has no access to the user's data and so they'll be able to shift the burden of actually breaking into the phone back onto the government.
Last edited:
So has anyone in the tech press asked them why only the 64-bit kernelcache was left unencrypted while the 32-bit kernelcache remains encrypted? What about the update and restore ramdisks, which also remain encrypted? The rest of the boot chain? Why not let us peek at those, too?
Apple PR's statement that "[t]he kernel cache doesn't contain any user info" is ridiculously obvious to anyone with technical knowledge in this area. That statement is clearly only intended to placate the non-technical masses who might hear "Apple" and "unencrypted" in the same sentence and get worried about the privacy battle.
Secondly, what sort of performance improvement can this possibly make? Even assuming the kernelcache has to be decrypted once per boot, that must take what, a couple hundred milliseconds for the hardware-accelerated AES engine to do its thing?
I am really baffled by Apple's response. If it was indeed intentional, it must have been for reasons other than what they are saying.
Apple PR's statement that "[t]he kernel cache doesn't contain any user info" is ridiculously obvious to anyone with technical knowledge in this area. That statement is clearly only intended to placate the non-technical masses who might hear "Apple" and "unencrypted" in the same sentence and get worried about the privacy battle.
Secondly, what sort of performance improvement can this possibly make? Even assuming the kernelcache has to be decrypted once per boot, that must take what, a couple hundred milliseconds for the hardware-accelerated AES engine to do its thing?
I am really baffled by Apple's response. If it was indeed intentional, it must have been for reasons other than what they are saying.
Last edited:
mmmmmm... unencrypted corn....
People who aren't going to do there research are going to see this and freak out. My grandfather (who looks for reasons to hate technology) loved reading this on his Facebook. He told me, "See! Apple isn't encrypting there next update! They aren't that safe!" I just laughed and explained what it was...explaining this to people who don't know what tech is, is going to be next to impossible.
Performance ? Yeah ! And you find it out after 10 major iterations of iOS while now every iOS device has a dedicated hardware Advanced encryption engine ?!
How does it affect performance other then boot time (when the kernel is decrypted) ?!
It's ******** damage control !
How does it affect performance other then boot time (when the kernel is decrypted) ?!
It's ******** damage control !
I would imagine it would help jailbreak the current OS, as for future I guess it depends how many report exploits.
I highly doubt un encrypting those ~12 MB files will noticeably increase performance. The way I see it is Apple unintentionally forget to encrypt it.
Yep, total garbage. Some background deal w/ the feds or something if this makes it to release version. There's no reason to un-encrypt something when, apparently, there was a reason to do so before. The performance gains are most likely minimal. If Apple is touting encryption/privacy everywhere, this is a very strange, shady move.
The media have seemed to forgot what "beta" is in software. Must be a slow day in the news room.
Pssh. What's $215K compared to earning an attaboy in the release notes?
But seriously, excellent post. Apple needs to get a bounty program cobbled together, like yesterday. Not going all tin foil, but if they won't pay for exploits, someone else might.
They didn't release XNU-ARM64 or 32's source just decrypted the kernel, incredibly different things. macOS by default has an unencrypted kernel which is also open source. This is more akin to the switch from the optional FileVault 1 which encrypted just the home folder to FileVault 2 which is a full disk encryption on the fly, except in reverse order. The reasoning makes sense, decryption and encryption on the fly can be resource taxing. This may prelude full source release in a few years.
To review unencrypted simply means they are not "scrambling" the binary, a file only readable by MACHINES.
Open source means they release the source code which is what programmers type to make the program and it's logic.
XNU-ARM the core or kernel of iOS is NOT open source, but even if it were that would be fine if not preferable. XNU-x86 of macOS, Linux, BSD, etc are all open source kernels and far more secure than many closed source systems such as Microsoft's NT kernel.
While i totally get your point.. it would suggest that Microsoft's bounty program is meaningless as well (because over $1Million is far more than one could hope to get from Microsoft). You would have to have a bounty program that paid far more. And if i was a betting man, i would bet that the government would have paid whatever was necessary.
A conscious person would help MS rather than the FBI/NSA, and it have been working for years. Google also have bug bounty program for Android and just now there's a report that they've paid over half a million last year.
In Android marketing terms, it's called nothing.
No Android phone has the kernel encrypted, and nobody is giving a slight reference.
What now?
No, personally, you both don't have a clue.
If Apple put a backdoor, then now it would be completely visible.
I wouldn't say completely visible. Disassembling a binary and then reading the unlabeled undocumented assembly looking for vulnerabilities is akin to putting a blind man in the middle of a football stadium and asking him to find his way out with all the doors and entrances locked. It's not impossible but it will take some time and perseverance plus it's super boring and frustrating. There is a reason most kernels are written mostly in C and C++ outside of the basest parts, even well written assembly is a pita.
