Slashdot Mirror
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.
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...
This comment was written with the intention to opt out of advertising.
Since you used ALL CAPS and "swear" words you clearly must be authoritative on the subject.
You are wrong. To prove otherwise please upload your custom Intel microcode update.
They are right up there with people who don't know the difference between 'to' and 'too'. They're the worst.
There is no story here.
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.
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.
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!!
AntiFA: An abbreviation for Anti First Amendment.
Not saying the guy is right, but how does a custom intel microcode update prove anything about a custom iphone kernel?
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.
"Imagination is more important than knowledge" - Einstein
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.
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?
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
The decryption key is burned into the processor
How do they pull that off for the emulator?
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
You may have had a point, but I stopped reading at the first very unnecessary F-bomb.
Hey, Windows users, there is no such thing as "forward" slash, there is only slash and backslash.
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Because it's a Simulator not an emulator. It's a special version of the OS compiled for x86.
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.
http://lkml.org/lkml/2005/8/20/95
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.
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.
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
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.
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
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.
Whoops forgot to put the URL https://www.apple.com/business...
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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/...
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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?
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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?
A successful API design takes a mixture of software design and pedagogy.
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
A successful API design takes a mixture of software design and pedagogy.
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
A successful API design takes a mixture of software design and pedagogy.
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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 the data section (the code) up to
// the start of the RSA signature (SHSH section) // identifier of image, used when bootrom is parsing images
// list to find LLB (illb), LLB parsing it to find iBoot (ibot),
// etc. // continues until end of file
// see below // length of tag including "magic" and these two length values // length of tag data // Typically padded to 4 byte multiple
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
uint32_t ident;
img3Tag tags[];
};
typedef struct img3Tag {
uint32_t magic;
uint32_t totalLength;
uint32_t dataLength;
uint8_t data[dataLength];
uint8_t pad[totalLength - dataLength - 12];
};
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).
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.