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.
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.
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.
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.
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.
Half a day is better than my MBP. I'm never not near a power source, though, so its a moot point; my MBP was only allowed to run down because I took it in the bathroom with when when I took a shit and didn't plug it back in right away after. Yes, my Mac comes to the bathroom when I shit, because it's in good company there.
You also must have missed where I stated:
This is actually the 2nd time I've taken the MBP out since I moved. The first was yesterday, after I finally got my office set up fully and started leaving my Windows laptop there.
That's a far cry from "you only use it at your desktop at work"; it's my primary machine, my office is a 15 foot walk from my couch. You couldn't possibly know the exact distance, but you cold probably guess it was in my home from the above quote. My windows Laptop has a 4K display and is plugged into two more of them; it's a hassle to move it once it's set up, thus why I use the inferior machine for mobility.
Honestly, you're not even a good troll; not worth my time. Good day, sir.
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.
No, I looked at the data and confirmed that the summary is correct. You, on the other hand... well, other responses already said what I was about to type, no need to repeat it.
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.
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.
I'm not sure there's a strong argument for $30 instead of $50 when this is the heart of your business...
Oh, I don't know about that...
and lost sales when the oh-so-responsible (that's why they work as a pizza driver, after all) driver forgets to charge the reader or can't figure out how to pair it with their new phone, but didn't realize until they already made the delivery.
Honestly, for brick-and-mortar stores with stationary POS systems, there's not much of an argument for Square in the first place; other solutions have much lower fees. I guess they're not iPad-powered, so your POS system doesn't benefit from that shiny Apple logo...
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.
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.
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.
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.
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.
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.
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?
They have a chip reader that plugs into the 3.5mm as well... and for cards that don't have chips yet (I've got two in my wallet), that stripe reader is still useful. Old rules regarding fraud liability still apply to non-chipped cards, by the way.
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.
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.
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?
On a machine with the "Pro" moniker, there might be more people who care about that Ethernet port that you realize. There's a reason they started selling a Lightning to Ethernet adapter shortly after they began selling the thinner models without the port; true professionals only begrudgingly accepted the machine without Ethernet.
As for 3.5mm, only a few people care right now and yes, people will make that initial excited post. Then, they'll watch their favorite show or play a game where sound timing is critical, or they'll try to use them in a crowded area like on a bus or train (where everyone else has just upgraded their iPhone and is now using the same headphones in a crowded space, sharing crowded spectrum) and declare, on the very same Facebook page, how much Bluetooth headphones suck. The alternative, which is actually more likely than Bluetooth headphones, is for Apple to include Lightning headphones that drain the phone's battery faster (find my other posts on this topic for an explanation) or require batteries of their own (yay! something else to keep charged or carry batteries for) and is only compatible with iDevices; they might be excited for all of 10 seconds, then they'll try and plug them into their Mac or iPod and the honeymoon will be over.
The first time someone using bluetooth only because there's no 3.5mm jack, or using Lightning headphones (with a weaker connector) drops and breaks their phone while listening to music, where reaching the end of a headphone cord would have slowed the fall and saved the device, they'll care about that, as well.
These are all thing normal, average, non-audiophile, non-geek, non-tech, non-purist, guy-next-door-with-a-wife-and-three-kids types do care about. That they don't realize the issues they'll face in giving up that cord only means they don't care about the cord; trust when I say the do care about the other issues and they'll quickly begin to care about the cord once they face them.
An iPhone without a 3.5mm jack won't be the first phone to ship that way, nor will the Moto Z; the G1 shipped without a headphone jack and, well, that design feature didn't exactly trend. I wonder why...
Slashdot Mirror
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.
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.
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.
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.
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.
You also must have missed where I stated:
This is actually the 2nd time I've taken the MBP out since I moved. The first was yesterday, after I finally got my office set up fully and started leaving my Windows laptop there.
That's a far cry from "you only use it at your desktop at work"; it's my primary machine, my office is a 15 foot walk from my couch. You couldn't possibly know the exact distance, but you cold probably guess it was in my home from the above quote. My windows Laptop has a 4K display and is plugged into two more of them; it's a hassle to move it once it's set up, thus why I use the inferior machine for mobility.
Honestly, you're not even a good troll; not worth my time. Good day, sir.
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.
No, I looked at the data and confirmed that the summary is correct. You, on the other hand... well, other responses already said what I was about to type, no need to repeat it.
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.
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.
I'm not sure there's a strong argument for $30 instead of $50 when this is the heart of your business...
Oh, I don't know about that...
and lost sales when the oh-so-responsible (that's why they work as a pizza driver, after all) driver forgets to charge the reader or can't figure out how to pair it with their new phone, but didn't realize until they already made the delivery.
Honestly, for brick-and-mortar stores with stationary POS systems, there's not much of an argument for Square in the first place; other solutions have much lower fees. I guess they're not iPad-powered, so your POS system doesn't benefit from that shiny Apple logo...
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.
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.
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.
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.
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.
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.
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.
They have a chip reader that plugs into the 3.5mm as well... and for cards that don't have chips yet (I've got two in my wallet), that stripe reader is still useful. Old rules regarding fraud liability still apply to non-chipped cards, by the way.
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.
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.
The decryption key is burned into the processor
How do they pull that off for the emulator?
They might claim that, but the iPhone emulator provided with XCode has no problem doing the job. That should tell you something.
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?
On a machine with the "Pro" moniker, there might be more people who care about that Ethernet port that you realize. There's a reason they started selling a Lightning to Ethernet adapter shortly after they began selling the thinner models without the port; true professionals only begrudgingly accepted the machine without Ethernet.
As for 3.5mm, only a few people care right now and yes, people will make that initial excited post. Then, they'll watch their favorite show or play a game where sound timing is critical, or they'll try to use them in a crowded area like on a bus or train (where everyone else has just upgraded their iPhone and is now using the same headphones in a crowded space, sharing crowded spectrum) and declare, on the very same Facebook page, how much Bluetooth headphones suck. The alternative, which is actually more likely than Bluetooth headphones, is for Apple to include Lightning headphones that drain the phone's battery faster (find my other posts on this topic for an explanation) or require batteries of their own (yay! something else to keep charged or carry batteries for) and is only compatible with iDevices; they might be excited for all of 10 seconds, then they'll try and plug them into their Mac or iPod and the honeymoon will be over.
The first time someone using bluetooth only because there's no 3.5mm jack, or using Lightning headphones (with a weaker connector) drops and breaks their phone while listening to music, where reaching the end of a headphone cord would have slowed the fall and saved the device, they'll care about that, as well.
These are all thing normal, average, non-audiophile, non-geek, non-tech, non-purist, guy-next-door-with-a-wife-and-three-kids types do care about. That they don't realize the issues they'll face in giving up that cord only means they don't care about the cord; trust when I say the do care about the other issues and they'll quickly begin to care about the cord once they face them.
An iPhone without a 3.5mm jack won't be the first phone to ship that way, nor will the Moto Z; the G1 shipped without a headphone jack and, well, that design feature didn't exactly trend. I wonder why...