Apple Says iOS Kernel Cache Left Unencrypted Intentionally, Nothing To Worry About (loopinsight.com) 124
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.
Re:What? (Score:5, Informative)
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.
KERNEL vs. CACHE (Score:2, Interesting)
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: (Score:2, Troll)
Re:KERNEL vs. CACHE (Score:5, Informative)
Re: (Score:3, Funny)
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: (Score:3)
You are late to the party. c.f. Clinton and what the definition of "is" is
Re: (Score:2)
Bill was being pedantic, but he was using the standard (ie, present tense) definition if "is."
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
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.
Translation (Score:1, Troll)
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: (Score:2)
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.... (Score:1)
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
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.
Re: (Score:2)
no subject at all (Score:1)
There is no story here.
LINUX NOT SECURE (Score:4, Funny)
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: (Score:1)
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: (Score:2)
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: (Score:1)
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: (Score:1)
Lucky you man! You get to ride in a helicopter!
Re: (Score:2)
They don't send them for you during the day, dude. Middle of the night.
Re: (Score:3)
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: (Score:2)
Filesystem change? (Score:5, Interesting)
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: (Score:2)
Re: (Score:2)
Re: (Score:2)
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 tha
Re: (Score:2)
Re: (Score:2)
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., b
Re: (Score:2)
They are not wrong (Score:2)
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?
Re: (Score:2)
Since you used ALL CAPS and "swear" words you clearly must be authoritative on the subject.
Re: (Score:2)
You are wrong. To prove otherwise please upload your custom Intel microcode update.
Re: (Score:2)
Not saying the guy is right, but how does a custom intel microcode update prove anything about a custom iphone kernel?
Re: (Score:2)
They are right up there with people who don't know the difference between 'to' and 'too'. They're the worst.
Huh? (Score:3)
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: (Score:2)
Re:Security Researcher == any random idiot (Score:5, Informative)
Re: (Score:2)
The decryption key is burned into the processor
How do they pull that off for the emulator?
Re: (Score:1)
Because it's a Simulator not an emulator. It's a special version of the OS compiled for x86.
Re: (Score:2)
You're focusing your argument on the wrong point.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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 laid
Re: (Score:3)
It doesn't matter that it's burned in (Score:2)
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: (Score:2)
Re: (Score:2)
--
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 m
Re:Security Researcher == any random idiot (Score:4, Insightful)
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
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 w
Re: (Score:2)
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 referenc
Re: (Score:2)
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: // ASCII_LE("Img3") // full size of fw image // size of fw image without header
// size of the start of
typedef struct img3File {
uint32_t magic;
uint32_t fullSize;
uint32_t sizeNoPack;
uint32_t sigCheckArea;// although that is just my name for it, this is the
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
I'm gonna go ahead
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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: (Score:3)
Re: (Score:3)
Re: (Score:3)
Re: (Score:2)
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 an
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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 muc
Re: (Score:2)
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.