Apple Says iOS Kernel Cache Left Unencrypted Intentionally, Nothing To Worry About (loopinsight.com)

The iOS 10 kernel, which Apple released to enthusiasts last week, is not encrypted, according to a report. Security experts expressed their surprise and puzzlement over this in a report by MIT News. The iPhone maker, after remaining tight-lipped over the matter for a week, has now offered an explanation. In a statement to The Loop, Apple said: 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.It is worth mentioning that Apple is talking about kernel's cache, whereas MIT News' original report talks about kernel code.

Comments

Apple is gay corp (5, Informative)

[Anonymous Coward]

Faggot corp makes pooo into mobile phones and people eat that poop. Pooop for the masses and now without encryption!

Re:Apple is gay corp (5, Informative)

[Anonymous Coward]

Very informative, +5

Re:Apple is gay corp (5, Informative)

[Anonymous Coward]

Apple is not a gay corp. It's a corp with a gay CEO. Get it right.

Re:Apple is gay corp (5, Informative)

[Anonymous Coward]

Wait, you mean it's not gay to kiss the ass of a gay man?

Re: Apple is gay corp (5, Informative)

[Anonymous Coward]

Probably no less gay than kissing the ass of a straight guy

What?

[110010001000]

How is it possible that manishs doesn't know the difference between code and cache?

Re:What?

[DamnOregonian]

To be fair, Apple uses a weird terminology with regard to the kernel in iOS (don't know about macs or any other XNU-running devices, don't have any experience with them)
the kernel in iOS is in fact called a kernel cache. It's prelinked, ready to be dumped into memory and executed.
Apple is in fact referring to the kernel when are talking about the kernel cache.
Apple and "security experts" are talking about the same thing.

Even unencrypted...

[Anonymous Coward]

BSD-based is still more secure than the Windows kernel. In fairness though some folks probably enjoy ransomware.

Like smacking your hand with a hammer then stopping, it feels so good after making that bitcoin payment and getting your precious Office docs back.

Re: Even unencrypted...

[Anonymous Coward]

Not really... considering BSD is a monolithic kernel and Windows uses a (mostly) microkernel... I'd wager Linux and BSD have had far more kernel security issues than Windows... but that's like saying notepad is more secure than LibreOffice... relatively meaningless.

KERNEL vs. CACHE

[mrthoughtful]

So there seems to be some difference over assertions here.
Apple is only talking about the iOS 10 kernel CACHE and that private data is never stored there (fair enough), whereas TFA is talking about the kernel code which is left open to exploitation.

I personally consider that opening the kernel is a wise move. It will, most likely, assist in closing holes in the code and, eventually, would make a stronger kernel. However, as the article suggests, it was probably a mistake...

Re:KERNEL vs. CACHE

[110010001000]

It is sad that most Slashdot readers (and editors) now don't know the difference between CACHE and code.

Re:KERNEL vs. CACHE

[cryptizard]

Kernel cache is what they call the encrypted container that has the kernel in it. The article is not wrong, just a nonstandard use of the term.

Re:KERNEL vs. CACHE

[fustakrakich]

The article is not wrong, just a nonstandard use of the term.

My new campaign slogan! I am not lying. I am just using nonstandard definitions.

Re:KERNEL vs. CACHE

[tbuddy]

I think they should open source the kernel too. If they do they travel back in time to 1996 and put it here so everyone thinks they have always had a transparent security process in regards to the XNU kernel long since before OS X or iOS existed.

Re:KERNEL vs. CACHE

[Diss Champ]

You are late to the party. c.f. Clinton and what the definition of "is" is

Re:KERNEL vs. CACHE

[Anonymous Coward]

"This is the operative statement. The others are inoperative." - Ronald Zeigler

Can't beat that one. Can't define its meaning, either, which is why you can't beat it.

Re:KERNEL vs. CACHE

[DamnOregonian]

Apple is talking about the kernel itself, which it calls the "kernel cache"
TFA is talking about the kernel, which Apple calls the "kernel cache"
They're talking about the same thing, Apple just uses a funny term for it.

Re:KERNEL vs. CACHE

[DamnOregonian]

It's actually Apple that uses the nonstandard term... I had never heard of a kernel referred to as a "kernel cache" before I started hacking iOS back in ye olden days.

Re:KERNEL vs. CACHE

[Parafilmus]

Bill was being pedantic, but he was using the standard (ie, present tense) definition if "is."

It's not a bug

[Anonymous Coward]

It's a feature. Now look at the shiny phone!

Security Researcher == any random idiot

[BitZtream]

Just because you jump up and down and say you're a 'security researcher' doesn't mean you have even a tiny bit of a clue.

Anyone who freaked out over this is an idiot who knows absolutely nothing at all about security and is also to stupid to know how ignorant they are.

Guess what ... the old 'encrypted' kernels ... they have the decryption key in the kernel for you to get and decrypt them anyway ... THATS HOW IT FUCKING READS THEM SO YOU COULD READ THE ENCRYPTED CONTENT THE ENTIRE FUCKING TIME IT WAS ENCRYPTED ANYWAY IF YOU HAD HALF A CLUE.
AT NO POINT WAS THE ENCRYPTION PREVENTING ANYONE WHO REALLY WANTED TO FROM GETTING AT THE DATA IN THE FIRST PLACE.

Encrypted data or code is worthless, it has to be decrypted to be used. So at no point was the data actually truly hidden.

Its digitally signed to ensure it isn't tampered with, thats all that can be done.

Re:Security Researcher == any random idiot

[Anonymous Coward]

Since you used ALL CAPS and "swear" words you clearly must be authoritative on the subject.

Re:Security Researcher == any random idiot

[Megol]

You are wrong. To prove otherwise please upload your custom Intel microcode update.

Re:Security Researcher == any random idiot

[Anonymous Coward]

They are right up there with people who don't know the difference between 'to' and 'too'. They're the worst.

Re:Security Researcher == any random idiot

[cryptizard]

That's actually not how it works. The decryption key is burned into the processor, that is why there is a different firmware image for different versions of the phone. Only some of the phone versions (older ones) have had their keys extracted and released. Also, with new technologies like SGX (shipped in some current desktop CPUs and soon phones) software publishers will be able to write code that can only be decrypted in the hardware's trusted enclave, so the key can never be observed. So stop yelling please when you don't know what you're talking about.

Re:Security Researcher == any random idiot

[iCEBaLM]

Not saying the guy is right, but how does a custom intel microcode update prove anything about a custom iphone kernel?

Re:Security Researcher == any random idiot

[Anonymous Coward]

Excessive, pointless use of all-caps: a clear sign of autism.

Re:Security Researcher == any random idiot

[BronsCon]

Yes, you have the decryption key, but not the encryption key. Before you read on, try and guess what I'm getting at; then read on to see if you were right.

--

It is possible to modify an unencrypted binary, pad it so the checksums match, and get it onto the device, either by slipping that binary back into the original update blob or by desoldering the NVRAM from the phone, flashing it, and soldering it back in. The various TLAs you types are always worried about can do either of those.

Just thought you might like to know. Would you like some tinfoil, now?

Re:Security Researcher == any random idiot

[Anonymous Coward]

It's bitztream, the annoying, screaming, autism-hating Slashdot troll!

Re:Security Researcher == any random idiot

[BronsCon]

The decryption key is burned into the processor

How do they pull that off for the emulator?

Re:Security Researcher == any random idiot

[mccrew]

You may have had a point, but I stopped reading at the first very unnecessary F-bomb.

Re:Security Researcher == any random idiot

[BitZtream]

... says the AC idiot.

Re:Security Researcher == any random idiot

[BitZtream]

heh, thats cute. Not done much embedded work have you?

I have. With those processors specifically. Extracting the encryption key is non-trivial but documented if you know where to look (not the processor documentation mind you (OH FACE)

I assure you that anyone who actually knew what they were doing can easily 'decrypt' the code and nothing you've said changes what I've said, other than you think that because they've embedded it in prom on the CPU that its secure. Just because its a custom chip apple laided out doesn't mean its magically doing things that no one else figured out how to break years ago.

You may not be able to change the key, but you most certainly can extract it.

Re: Security Researcher == any random idiot

[Anonymous Coward]

Umm, no you couldn't read it at any time at least on 64-bit devices. The decryption keys are generated on the device by hardware which is disabled before user land starts. So without being able to hijack the boot process or have some super fancy hardware reversing capability you can't get to the keys.

There is a known exploit for the boot loader on 32 bit devices and people have used that to retrieve keys for those. Such a thing may exist for 64 bit, but it is kept very hush hush if so, and nobody is publicly posting 64bit keys.

The only other way to get a decrypted kernel is to have a kernel exploit that enables arbitrary kernel memory read, at which point you can just dump out the kernel. Even then there are chunks that aren't needed at run time that are jettisoned, so you don't get the entire thing (like symbols).

So no it's not that easy to do.

Re:Security Researcher == any random idiot

[Anonymous Coward]

*Their the wurst.

FTFY, since your an idiot.

Re:Security Researcher == any random idiot

[Anonymous Coward]

Because it's a Simulator not an emulator. It's a special version of the OS compiled for x86.

Re: Security Researcher == any random idiot

[Anonymous Coward]

Since your A idiot

FTFY.

Re:Security Researcher == any random idiot

[Anonymous Coward]

It's here, it's bitztream, the autism-hating Slashdot troll!

Re:Security Researcher == any random idiot

[Anonymous Coward]

No, you're wrong. And you have serious mommy issues, see a shrink.

Re:Security Researcher == any random idiot

[Anonymous Coward]

They are right up there with people who don't know the difference between 'to' and 'too'. They're the worst.

Damn right, I hate those people to.

Re:Security Researcher == any random idiot

[cryptizard]

Then please explain to me why there are tons of models of the phone that don't have their keys extracted yet. They are specifically designed to not have the key leave the enclave. Why don't you go ahead and do it then since you're some kind of expert and it's so easy? The jailbreak community would appreciate it. Or just keep talking out of your ass on Slashdot.

Re:Security Researcher == any random idiot

[BronsCon]

So you're saying that version isn't encrypted? Or that it's encrypted but the key is readily accessible by disassembling the simulator code? Or... what, exactly, are you saying? Is the kernel in the x86 version encrypted or not?

You're focusing your argument on the wrong point.

Re:Security Researcher == any random idiot

[DamnOregonian]

AES is symmetrical. The kernelcache is encrypted using AES. You're describing a hash collision on a signature. You're ignorant of the topic being discussed, please stop posting with such a confident posture.

Re:Security Researcher == any random idiot

[cryptizard]

Usually the firmwares are checked with a cryptographic hash though, so it is not as simple as just fiddling with it a bit to make the checksum match. It should be (nearly) impossible to make changes to the binary without them being detected.

Re: Security Researcher == any random idiot

[BronsCon]

Eh? Jailbreak, disable the code that disabled the hardware keygen, done. Yes, this has been done; it's a bit beyond me how to actually pull it off, mostly because I haven't looked into it because I don't care (don't have an iPhone), but it's been done.

Re:Security Researcher == any random idiot

[BronsCon]

Do you have documentation you can point me to stating that AES is being used? Given that the user is literally handed the key, that would be an idiotic choice. I don't think Apple necessarily has the best and brightest engineers, but they also don't employ idiots.

Re:Security Researcher == any random idiot

[BronsCon]

Yes, the firmware is checked during an upgrade; it is not verified during the boot process as this would take too long (the flash used doesn't read that fast). Te is definitely open to a physical attack (desolder/flash/resolder) during which the install-time hash check can also be disabled, allowing the attacker to push their own updates remotely. As for the "nearly" impossible, yes, for you or I it likely is; for someone with a government budget for computing power, perhaps not so much.

I'm gonna go ahead and call an end to this conversation before the tinfoil hatters come out of the woodwork.

Re:Security Researcher == any random idiot

[cryptizard]

That is interesting, I didn't know that it wasn't checked during boot. That seems like a bad idea. As to whether or not some people can break cryptographic hashes, I would lean toward not. It is not a matter of computing power, but some theoretic break on the algorithm itself. And a lot of really smart people in academia have been looking at, for instance, SHA-2 for over 15 years now with no substantial attacks.

Re:Security Researcher == any random idiot

[cryptizard]

This security document from Apple implies that every stage of the boot process does a complete verification on the next stage before booting continues, first the Low Level Bootloader, then iBoot and finally the iOS kernel. So you could mess with the userland stuff but not the kernel. If you think about it, the whole boot chain including the kernel is probably only 10 MB or less. That is not so burdensome to verify every boot.

Re:Security Researcher == any random idiot

[cryptizard]

Whoops forgot to put the URL https://www.apple.com/business...

Re:Security Researcher == any random idiot

[BronsCon]

It's not a matter of breaking the hash, simply finding a collision. Whenever what you're hashing is larger than your hash, there will always be collisions.

Re:Security Researcher == any random idiot

[BronsCon]

Which security document? You seem to have not linked to anything. But yes, it's verified by attempting to decrypt; if decryption fails, it's been tampered with. The encryption was removed from the kernel, ergo the kernel can no longer be verified.

Re:Security Researcher == any random idiot

[cryptizard]

Yes there will always be collisions, in fact infinitely many, but it is computationally infeasible to find them. To date there have never been found two inputs that create the same hash in SHA-2. Since the output is 256 bits, you would have to try about 2^128 inputs in expectation before you find one, which is quite a few. You would need something like 10^20 times more storage than exists on the whole planet.

Re:Security Researcher == any random idiot

[BronsCon]

I see...

Each step of the startup process contains components that are cryptographically signed by Apple to ensure integrity and that proceed only after verifying the chain of trust. This includes the bootloaders, kernel, kernel extensions, and baseband firmware. When an iOS device is turned on, its application processor immediately executes code from read-only memory known as the Boot ROM. This immutable code, known as the hardware root of trust, is laid down during chip fabrication, and is implicitly trusted.

The Boot ROM code contains the Apple Root CA public key, which is used to verify that the Low-Level Bootloader (LLB) is signed by Apple before allowing it to load. This is the first step in the chain of trust where each step ensures that the next is signed by Apple. When the LLB finishes its tasks, it verifies and runs the next-stage bootloader, iBoot, which in turn verifies and runs the iOS kernel.

I stand corrected, the binary decrypting properly was merely a secondary protection. The primary protection is the signature, which is made much weaker by the removal of the encryption, as the binary no longer has to both be signed properly and be able to be decrypted with the public key. If you think there's not a datacenter in Utah with the compute power to "solve" this in a matter of hours (maybe days), you're mistaken.

Also, thank you for providing that document, hopefully DamnOregonian sees and reads it. AES. Laughable.

Re:Security Researcher == any random idiot

[cryptizard]

I'm pretty positive there isn't, or else if there is we have much bigger problems than our iPhones. Literally all of internet security relies on hash functions. If they are broken then we might as well just give up.

Also, testing if something is "able to be decrypted" implicitly relies on a hash because how else do you know if what you decrypted is valid? If you use something simple like a checksum or padding to check, it actually leads to an attack that can be used to decrypt the file called a padding oracle attack https://en.wikipedia.org/wiki/...

Re: Security Researcher == any random idiot

[Anonymous Coward]

I don't think the simulator is a full x86 version of iOS. It provides a user land that you can test apps in but I don't think it has a real kernel. IIRC it actually calls down into the Mac OS X kernel when it needs system services. it's basically a sandbox that pretends to be iOS.

Re:Security Researcher == any random idiot

[BronsCon]

Since the output is 256 bits, you would have to try about 2^128 inputs in expectation before you find one

Or one lucky guess. Or double that and you still haven't found one. Don't oversimplify for my sake, I do understand these things, you can speak to me as a peer.

You would need something like 10^20 times more storage than exists on the whole planet.

Perhaps, if you were storing all of your test inputs. However, you can just as easily programmatically generate them and only store the ones that match.

Re: Security Researcher == any random idiot

[Anonymous Coward]

You can't do that with a modern jailbreak. To disable that code you have to have your jailbreak hijack control in the BootRom or the boot loader. The last public jailbreak that had that capability died with the iPhone 4s.

There is a researcher named iH8sn0w who has a jailbreak for the 4s through 5c, but he only shares with a small handful of people. He does upload keys from time to time though.

There are no known jailbreaks for 64bit devices that offer that capability. It's likely that they exist but no one has admitted to it, and it's certainly not available for anyone to download.

All jailbreaks in recent years get you kernel privileges, but that's not enough to disable the boot chain of trust.

Re:Security Researcher == any random idiot

[BronsCon]

Nice argumentum per viam modum. Here's a reference (thanks to cryptizard for providing that) in case you need it. No, AES is not used; AES does not have a public and private key (as you stated, it's symmetric) and Apple specifically states the existence of a public key, which implies a separate private key.

Re:Security Researcher == any random idiot

[Anonymous Coward]

There are substantial differences in utility between arbitrary collisions and useful ones. See preimage attacks and collision attacks. HTH. -PCP

Re: Security Researcher == any random idiot

[BronsCon]

Interesting that they'd do that; seems it'd introduce a fair bit of inconsistency in how things work between the simulator and the real device. An ideal solution would execute the same code in the same way at the same speed; an acceptable tradeoff would be one that executed the same code in the same way, with speed constraints based on the actual hardware being used. Anything that causes the same code to execute differently in the simulator vs the real device is, IMO, a bug.

Re: Security Researcher == any random idiot

[BronsCon]

I never said anything about disabling the chain of trust, I referenced disabling the code that disables the hardware keygen, the piece of hardware that allows system binaries to be decrypted, actually quite the opposite. Since that is done by a command issued by the kernel during boot, before userland components are loaded, it certainly can be skipped.

Re: Security Researcher == any random idiot

[Anonymous Coward]

It's not the kernel that turns it off. It's the boot loader, iBoot. By the time the kernel gets control its off. So you have to hijack iBoot or earlier.

But even if it was the kernel you couldn't stop it. The kernel is encrypted and signed, so You would have to be able to decrypt the kernel, modify its code, then reencrypt and sign with Apples private key. Otherwise iBoot will tell you to fuck off.

Re: Security Researcher == any random idiot

[Anonymous Coward]

Emulation of an arm CPU is slow and cannot be done as fast as the iPhone CPU is.
So xcode makes a x86 binary of your application so that it actually fast (probably faster than your iPhone).

Since iOS and macOS are basically the same operating system underneath, with basically just another GUI library. The simulation of an iPhone on a Mac is pretty accurate.

You may also be interesting to know that your application is now released on the App Store as LLVM's Intermediate Code. The App Store will build optimised binaries for every different iPhone/iPad CPU (different ARMs for now, but they could even change to Intel). So you already are not developing for a consistant platform.

Re: Security Researcher == any random idiot

[BronsCon]

Understood; however, there is no reason it cannot run as a VM with its own kernel and resources. My point wasn't at all related to the underlying architecture, just the software that runs on it.

Re: Security Researcher == any random idiot

[BronsCon]

The kernel loads several kernel-mode drivers, which are encrypted and signed, requiring this hardware to still be available for a short while after the kernel takes control. Doing otherwise would open the device to kernel-level vulnerabilities injected by modified drivers, which would be a gold-mine for jailbreakers.

Also of note: the very article we're discussing happens to be about the kernel no longer being encrypted so, no, you don't need to re-encrypt it, you're left with the (still difficult, but much easier) task of making your modified binary match the checksum and hash of the original.

Re:Security Researcher == any random idiot

[BronsCon]

I love how you assume I'm speaking from a position of ignorance. Look at my posting history and you'll learn that I tend not to do that; and when someone does manage to teach me something I thank them for doing so.

Re: Security Researcher == any random idiot

[Anonymous Coward]

The kernel does not load the drivers: they are already pre linked together, which is why it's called a kernel cache. IBoot decrypts the entire kernelcache, drivers and all, and loads it into memory. OS X has the same capability but the kernelcache can be updated there unlike iOS.

The kernel does do some initialization of the drivers, like calling constructors and updating symbol tables to account for ASLR, but it doesn't have to decrypt and load them. As for whether iBoot would load a modified kernel that isn't encrypted... That's a good question. Since iBoot still is encrypted we don't know if it's doing any new validation. It was possible to find iBoot still hanging around in physical memory on iOS 8, but that doesn't appear to be the case in iOS 9 and above.... It's erased before user land is started. but if they used a strong hash and require the size of the hashed image to be the same it would be almost impossible to find a collision of the same size that was also a fully working kernel.

The dynamic linker does this as well in user land. All of the shared libraries that come with the system are linked together into a giant half gig blob that gets mapped into memory in one go, then the kernel just adds a mapping for this blob to each process. That way all libraries only have to be loaded one time.

Re: Security Researcher == any random idiot

[BronsCon]

Huh, interesting. Learn something every day...

Also, and I'm not sure why I didn't think of this earlier, it's not necessary to load a modified kernel with the same hash; it would be much easier to move the kernel and replace it with a binary that loads the kernel, patches it in RAM, then hands off execution. The binary itself would be small, leaving plenty of "slack" which can be modified as needed to match the hashes, while allowing the file size to remain constant.

Re:Security Researcher == any random idiot

[DamnOregonian]

AES is (well, was prior to most recent beta referenced in TFA) in fact used.
I need not read the reference, as I'm intimately familiar with the boot process.
My guess is that you read "signature" in there and something about a cert, and assumed that actually applied to the encryption used on the kernel binary itself rather than the signature for it.
A signature must necessarily be asymmetric so that someone can decrypt it without being able to encrypt a new signature.
This concept exists in regular SSL as well. One need not encrypt an entire certificate with trusted information in it, only the signature.
The kernel is *still* protected by the asymmetrically encrypted signature in the new versions of iOS, it simply isn't encrypted anymore.
That is to say, the KBAG field (containing the AES GID encrypted AES KEY/IV for the kernel) of the kernel header is now blank.
The OP was referring to the fact that the symmetric encryption did nothing to help things, it was always the asymmetric encrypted signature that did the real protection.

Re:Security Researcher == any random idiot

[BronsCon]

My guess is that you read "signature" in there and something about a cert, and assumed that actually applied to the encryption used on the kernel binary itself rather than the signature for it.

No, I read the following, on page 5, under the heading "Secure boot chain":

The Boot ROM code contains the Apple Root CA public key, which is used to verify that the Low-Level Bootloader (LLB) is signed by Apple before allowing it to load. This is the first step in the chain of trust where each step ensures that the next is signed by Apple. When the LLB finishes its tasks, it verifies and runs the next-stage bootloader, iBoot, which in turn verifies and runs the iOS kernel.

Yes, that does specifically mention the signature; no, it does not mention the encryption used, if any, on the various components of the boot chain. The remainder of the document does make many mentions of the use of AES, on the data partition, for secure communications, in the secure enclave for storing fingerprint hashes, for ApplePay, but no mention of its use anywhere in the boot process.

Perhaps you do need to read the reference? You don't seem to be as familiar with the boot process as you think.

Re:Security Researcher == any random idiot

[DamnOregonian]

Perhaps you do need to read the reference? You don't seem to be as familiar with the boot process as you think.

No, I really don't. Because I helped author literature that describes the process, as I was writing software to decrypt, and dump the symbol tables in the kernel. For your reference, here's the iOS IMG3 boot-chain container structure:
typedef struct img3File {
uint32_t magic; // ASCII_LE("Img3")
uint32_t fullSize; // full size of fw image
uint32_t sizeNoPack; // size of fw image without header
uint32_t sigCheckArea;// although that is just my name for it, this is the
// size of the start of the data section (the code) up to
// the start of the RSA signature (SHSH section)
uint32_t ident; // identifier of image, used when bootrom is parsing images
// list to find LLB (illb), LLB parsing it to find iBoot (ibot),
// etc.
img3Tag tags[]; // continues until end of file
};

typedef struct img3Tag {
uint32_t magic; // see below
uint32_t totalLength; // length of tag including "magic" and these two length values
uint32_t dataLength; // length of tag data
uint8_t data[dataLength];
uint8_t pad[totalLength - dataLength - 12]; // Typically padded to 4 byte multiple
};

VERS: iBoot version of the image
SEPO: Security Epoch
SDOM: Security Domain
PROD: Production Mode
CHIP: Chip to be used with. example: 0x8900 for S5L8900.
BORD: Board to be used with
KBAG: Contains the IV and key required to decrypt; encrypted with the GID Key
SHSH: RSA encrypted SHA1 hash of the file
CERT: Certificate
ECID: Exclusive Chip ID unique to every device
TYPE: Type of image, should contain the same string as the header's ident
DATA: Real content of the file

KBAG is the symmetric key (protected by hardware AES engine- but that's useless if someone already has arbitrary code execution on the device [the main reason they stopped using I suspect.])
SHSH is the asymmetric signature to ensure that it won't boot something that *has* been modified.

It has been this way since forever. it is still this way now.
Whether or not the reference completely outlines the boot process as (we) security researchers know it is not relevant to our understanding of it.

Every single stage of the boot process is protected under this scheme. A symmetric key/IV encrypted by the hardware GID key to obfuscate it, which in turn obfuscates the kernel, and an SHA signature encrypted asymmetrically with RSA to make it tamper-proof.

TFA is about them no longer bothering with the symmetric encryption on the kernel portion. (The boot stages before that are still encrypted).

Re:Security Researcher == any random idiot

[BronsCon]

See? This is why credentials are important. We could have avoided this whole back-and-forth if you'd just described your experience at the start (and not even in this much detail).

I've watched enough of Louis Rossmann's videos that I should have expected Apple's own documentation to be incorrect or, at the very least, incomplete.

I stand corrected and kindly thank you for the information.

If it was intentional...

[Anonymous Coward]

why did it take so long to release a statement about the situation?

Explanation?

[Anonymous Coward]

Explanation?

Sounds like furious backpedaling to me.

Re:Explanation?

[Anonymous Coward]

Explanation?

Sounds like furious backpedaling to me.

Their backpedaling is so furious you can smell the skid marks.

And that is just their underwear.

Translation

[Opportunist]

Our pervasive snooping through our customers' habits and information taught us that they do notice when the phone is slow, but they don't have a clue about security or consider their privacy in any way important.

Re:Translation

[Anonymous Coward]

Our pervasive snooping through our customers' habits and information taught us that they do notice when the phone is slow, but they don't have a clue about security or consider their privacy in any way important.

Which homosexual modded this Troll? This is an exact fact.

Re:Translation

[Opportunist]

I dared to paint the sacred cow hot pink and made it look FABULOUS, what did you expect.

Go ahead, I got Karma to burn.

In other words....

[evolutionary]

Canary Warrant. The Government got to them in spite of the public display of resisting.You can be anyone who was relying on Apple phones to keep secrets will use other means now. Doh.As for the claim that kernel cache doesn't contain user data (and bear in mind this took a week of "consideration", and I'm not a security expert), wouldn't it be possible to extrude data from the kernal cache that could lead to the ability to access other encrypted data? seems odd to encrypt it and then remove that encryption, especially given the timing. I could be wrong but I think Apple is giving a half truth. why take a week for a response to a question they had to know others would ask?

Re:In other words....

[Anonymous Coward]

why take a week for a response to a question they had to know others would ask?

Marketing. It gets people talking about them. Like we're doing right now. :)

Re:In other words....

[evolutionary]

Perhaps but I could think of better ways to create hype. All this would do is create concern and possibly distrust. Not what I think apple's stockholders would have in mind. If anything, this could move more people to Android just to see if it's more secure (or just the same, but less expensive phones). Apple is already slowing down on profits from their iphones recently. Not the best timing on something like this. Marketing typically tries to put a positive spin. This doesn't feel positive as much as reluctant.

Re:In other words....

[BronsCon]

I don't want to say one way or the other because I still want to believe things don't actually work this way, despite clear evidence to the contrary, but you may be right about this. You can't tamper with an encrypted binary unless you have both keys; an unencrypted binary can be messed with and, as long as they checksums match, dropped right in with minimal hassle. And we've already learned that it's not hard to make checksums match.

Re:In other words....

[tibit]

we've already learned that it's not hard to make checksums match.

That'd be big news for hashes that are currently considered secure. Got some links?

Re:In other words....

[BronsCon]

Anyone with a basic understanding of hashing algorithms knows that to brute-force any hash is a 2^n proposition, where n is the number of bits in the hash. I seem to recall something about a datacenter being built in Utah in the past year or two by an organization that might be interested in the subject.

Re:In other words....

[tibit]

There isn't enough material in the entire Universe (that we're aware of, at least) to build a datacenter to brute-force a 512 bit hash. The Universe has roughly 2^400 atoms, the Earth has roughly 2^170, a billion billion is 2^60 only and you'd be very lucky to have a "datacenter" that can do that many hashes per second. End of story. I don't think you have that basic understanding.

Re:In other words....

[BronsCon]

GPUs of 2014 were able to calculate a little over 100 million SHA-512 hashes per second, dual GPUs double that per system. We can expect that this number has doubled yearly for the past 2 years, giving us 400 million per GPU, per second; 800 million per dual-GPU system. 100k such systems (well within the reach of a government budget) would be able to churn through 80 trillion hashes per second, roughly 7 quintillion (7 billion billion) hashes per day. That is quite a number of years, indeed, to brute-force.

That assumes that someone backed by a government budget doesn't have access to an exploit against the SHA-512 algorithm.

Mind you, my point here is to keep the area tinfoil-free, so I'm not going to claim that it's likely that such an exploit exists. However, it's certainly within the realm of possibility and should be assumed to be the case if you're actually taking security against state actors in any way seriously. Keeping the kernel cache encrypted adds just one more layer of security.

If I were the conspiracy theorist type, I'd be pointing to the removal of encryption form the iOS kernel cache as meaning two things: A) That Apple and some government agency are working together to backdoor iOS and B) That said government agency has a working exploit for the hash being used. But, again, I'm trying to keep this a tinfoil-free area.

Just because, as far as we know, the hash used is perfectly secure, that's no excuse to remove a very cheap and effective additional layer of protection. That's really the only point I'm making. Some day, SHA-512 will be broken and that encrypted kernel cache will have made all the difference.

Re:In other words....

[tibit]

7 billion billion per day is still 2^63, 58 orders of magnitude short of 2^256, 135 orders of magnitude short of 2^512. Whatever "datacenter" you think of is irrelevant, pretty much.

The extra layer of protection offered by asymmetric encryption will be moot once a key secure hash falls.

Re:In other words....

[BronsCon]

7 billion billion per day is still 2^63, 58 orders of magnitude short of 2^256, 135 orders of magnitude short of 2^512.

You must've stopped reading before you finished my first paragraph... I actually admit as much.

The extra layer of protection offered by asymmetric encryption will be moot once a key secure hash falls.

Not if the asymmetric encryption isn't vulnerable to the same exploit as the failed hash. Seriously, think about that for half a second; if you're able to keep up an argument on this topic (and I'd say you've been doing a fine job of it until now) you shouldn't need any longer than that. You're a smart fella, act like it.

no subject at all

[Anonymous Coward]

There is no story here.

Re:no subject at all

[Anonymous Coward]

Whaaaaaaaaaa! Your beloved Apple not getting perfect press? Whaaaaaa whaaaa mommy mommy.

Re:no subject at all

[Anonymous Coward]

I think you need your nappy (diaper) changed.

Huh?

[Viol8]

I thought the encryption key was securely stored in the iPhone hardware and can only be accessed by firmware running on that hardware which then decrypts the kernel.

Re:Huh?

[BronsCon]

They might claim that, but the iPhone emulator provided with XCode has no problem doing the job. That should tell you something.

LINUX NOT SECURE

[CajunArson]

The Linux Kernel: NOT ENCRYPTED. Go panic now, the world is ending.

In fact, do you know that Linus Torvalds has personally made it possible for the MUTHAFUCKIN NSA to read every single line of source code in the Linux Kernel??

Just think about that the next time "they" tell you that it's OK for your computer to SEND IT'S DAMN IP ADDRESS OUT TO THE INTERNET!

The black helicopters are coming for me man!!

Re:LINUX NOT SECURE

[Anonymous Coward]

I find it ironic about people fearing the NSA. They wrote SELinux, which has done a lot of good overall with Linux security. They also have a lot of decent guides for server hardening.

To me, I've found their publications and security work, as well as hardening of operating systems, well worth my tax dollars.

Re:LINUX NOT SECURE

[NotInHere]

The NSA has two tasks: snooping and protecting US data. It takes the first task more seriously, and because of the snooping many people fear NSA, but it does stuff to fulfill the second task as well, like writing SELinux.

Re:LINUX NOT SECURE

[Anonymous Coward]

Lucky you man! You get to ride in a helicopter!

Re:LINUX NOT SECURE

[Anonymous Coward]

The black helicopters are coming for me man!!

You know, I always thought that they would blend much better if they were painted a very light bluish gray, maybe a little foliage painted on the sides to hide when they're on the ground, except their returning guys wouldn't see the chopper and walk into the tail rotor... OUCH!

Re:LINUX NOT SECURE

[fustakrakich]

it does stuff to fulfill the second task as well, like writing SELinux.

Yeah, I like to think we're getting the "Pro" version. But with sufficient network sniffing there is little to worry about, right?

Re:LINUX NOT SECURE

[crtreece]

OMG! I just checked on the websites for FreeBSD, OpenBSD, and NetBSD, they all have source code available too! Drug dealers, pedophiles, terrorists, and the NSA ALL have access to this source code.

They all leak IP addresses to the internet as well. It looks like they only leak MAC addresses to the local network, so they've done a little better there.

Re:LINUX NOT SECURE

[tbuddy]

OMG Apple does too!

Re:LINUX NOT SECURE

[TangoMargarine]

They don't send them for you during the day, dude. Middle of the night.

Re:LINUX NOT SECURE

[Anonymous Coward]

Oh yeah, that's true, if it's dark out, you have to paint them black. Otherwise...

rofl

[Anonymous Coward]

this was an oversight. Probably heads will roll...

Filesystem change?

[nine-times]

Is the new iOS running on Apple's new filesystem? Supposedly part of the features of the new filesystem is that it has greater control over file encryption. Given this explanation, it may be that they previously encrypted the kernel because it was the best way to encrypt user data, whereas with a new filesystem they may be able to encrypt the files they want to encrypt without needing to encrypt anything else.

Just a shot in the dark, though.

Re:Filesystem change?

[BronsCon]

It might for new phones, but I highly doubt they'll convert the filesystem during an upgrade. Even with perfect code doing the conversion on a clean filesystem, it's a risky operation.

Re:Filesystem change?

[Anonymous Coward]

Although they've done it before, at least on Mac.

When the version of OS X with the recovery partition came out it partitioned things and set up corestorage volumes. Since they control the hardware and software there's less of a risk but still risky but they might do it anyway.

Re:Filesystem change?

[Anubis IV]

The new filesystem, APFS, doesn't yet run on the phones. In fact, it can't even be used for a boot drive yet. They seem to be aiming for a 2017 release with it, but filesystems tend to suffer from catastrophic failure when bugs occur, so it's no surprise that Apple is playing this very carefully and getting it into the hands of developers well in advance. They'll doubtless re-add missing functionality over that time, such as being able to boot from it, use it for Time Machine, use it with FileVault, etc., but most of those will need to be significantly reworked because of how they function right now.

Re:Filesystem change?

[cryptizard]

Encrypting the kernel image didn't do anything to protect user data though, since it is decrypted during boot time so the phone can actually run. It was done, presumably, to prevent people from decompiling the binary and trying to find holes in it to make jailbreaks and such. Once the phone is booted, the kernel will of course refuse to dump itself so it only needs to be protected while the device is off.

Re:Filesystem change?

[BronsCon]

Eh? You're referring to Lion and no, it did not do that during an upgrade if user files resided on the drive. If installed from EFI recovery, yes, it would create those partitions, but it certainly did not during an upgrade involving existing user data.

Re:Filesystem change?

[Anonymous Coward]

New filesystem is not productized until next year.

Re:Filesystem change?

[SvnLyrBrto]

Who would take that chance anyway? On my Mac, I do a full data backup to an external drive, then physically disconnect it, before routine OS updates. On my iDevices, I do backups to both iCloud and my Mac before updates. I've never actually lost data. But I'm a bit paranoid on that score and, as they say, better to have the backup and not need it than the other way around. And really, if anything calls for a backup, re-partition, re-format, and install everything from scratch; a filesystem update s that thing.

Re:Filesystem change?

[BronsCon]

Who would take that chance? The more than 90% of the population who doesn't have backups.

NSA to Apple

[Anonymous Coward]

NSA: Ease it out folks or else we will eat into your Irish shortcuts.

Apple:It is already easy and open.

Case closed.

Encryption or obfuscation?

[Anonymous Coward]

From what I understand the kernel was obfuscated before and not encrypted. When you obfuscate machine code you usually have to execute more instructions per actual instruction. So this is probably just a move to free resources, as security trough obscurity isn't really that good anyways.

The takeaway...

[Anonymous Coward]

cute butt Tim.

It doesn't matter that it's burned in

[YesIAmAScript]

The key is burned into the processor, but you can employ the key in the processor to decrypt it. Just as the boot code decrypts the kernel cache, you can use the hardware to decrypt it for your own nefarious ends.

It just means you have to do the decryption on the device.

So the original writer was correct in that this encryption didn't stop all observers, just casual ones. Anyone who could get a significant jailbreak on a device could decrypt the kernel caches.

Re:It doesn't matter that it's burned in

[cryptizard]

Good point, that is true, but it is a bit of a chicken and egg problem. People want the unencrypted kernel code so they can make jailbreaks.

OMG WHY DO YOU SCRAM ALL THE TIME

[Anonymous Coward]

OMG WHY DO YOU SCREAM ALL THE TIME YOU FUCKING JACKASS FUCKTARD DICKHEAD

OMG why do you fucking scream all the time you fucking jackass fucktard dickhead!

OMG! WHY DO YOU SCREAM ALL THE TIME YOU FUCKING JACKASS FUCKTARD DICKHEAD

Re: KERNEL vs. CACHE - standards

[Anonymous Coward]

"That is the good thing about standards,
there are so many to choose from."

They are not wrong

[wwalker]

As much as I dislike Apple, they are not wrong here. What's the point of encrypting *code*?! Sign it, check sum it - yes, by all means, so that it's not replaced by something malicious. But why would you need to hide the actual content of the code?! Haven't we learned that security by obscurity doesn't work?

STRAIGHT MEN HAVE NOTHING TO DO WITH FAGS

[Anonymous Coward]

(6, GUARANTEED)

Slashdot heading wrong.

[Anonymous Coward]

So, the last slashdot headline specifically said that "Nobody knows why".

Clearly, Apple fucking knew why all along.

What the fuck, Slashdot? Quit it with misleading clickbait.