Or by intentionally allowing them to man-in-the-middle your site, allowing them to track and analyze every visitor, regardless of if you are using their Analytics product?
Yeah, but that doesn't play with the publicity stunt that a "tough on crime" district attorney wants to parlay into a seat in Congress, or a US Attorney seat, or a judgeship somewhere, etc.
Putting out a press release saying you are doing a thing, and then six months later not doing that thing because the story has faded is how county DAs become mayors, mayors become congressmen, congressmen become governors, etc.
I don't care what their motivations are. Their motivations have brought them to the correct side of the issue, regardless.
This is an insanely bad precedent that the FBI is trying to set. They probably don't even give a shit what's on the phone - they want the body of legal opinion that they can use in the future.
I hope Apple takes this thing all the way to the Supreme Court.
More than that, using the enshrined appeals process to make sure that you are being correctly compelled by a PRELIMINARY order means you are on the side of the terrorists.
It's not even an actual court order yet - that won't get issued until after the 26 February deadline (tomorrow) for Apple to file a motion that this would be unreasonably burdensome, which Apple will most certainly do. Then there will be a hearing on 22 March where the real decision from the Federal Magistrate will come down, and that will be the actual court order. Then, Apple (or the FBI) can (and will) request that the case get transferred to another district court judge, to see if they agree with the first one, during which time there will be a stay applied to the order. That will bring us some time into the summer before it's over. Then the appeal to the Ninth Circuit Court of Appeals begins, first with a 3-judge panel, and if the parties aren't satisfied by that, the full panel of appellate court judges.
Then, they can apply to have the Supreme Court hear the case. The road ends if they decline it, or continues all the way to a decision if they hear it.
This won't be over any time in 2016, and probably not in 2017 either, depending on how stubborn the FBI wants to be about it. We already know how stubborn Apple will be about it.
You would be surprised. The concept of Mobile Device Management is well known within large enterprise, but largely unknown outside of that. And here's why:
1. Government passes laws that require publicly traded companies to audit and positively manage access control and data safety (Sarbanes-Oxley, HIPAA, etc.) or the companies have institutional requirements for the same or beyond (PCI compliance). 2. Other companies make products that will allow large enterprises to comply with these rules and regulations, through things like data-at-rest encryption, IPSec, MDM, PKI, etc. 3. These companies then use these products and services to comply, so they don't get a massive bollocking at the hands of government. 4. The same laws don't apply to the government, so they don't bother. What's a "best practice"?
On this particular phone, it is possible. Thus, they are not taking that legal strategy.
If it was a 5S or a 6, that is exactly what they would have done, because it probably is impossible without having an untold amount of computing power for an untold amount of time.
Of course Apple can deliver what the FBI wants in this case - this phone doesn't employ the much more hardened security of the 5S and above. They could comment out a couple of functions in the code (wipe after 10 attempts, increase time delay between incorrect attempts), build it, sign it, put the phone into DFU mode and upload it. It would take one engineer less than a day.
They are fighting the legal precedent of allowing a Federal Court Judge to compel a company to compromise their product on a whim. This doesn't even stop at phones - are you telling me that some assistant District Attorney out there wouldn't try to use this precedent to compel a company who makes a secure USB stick to give law enforcement a peek? How about safe manufacturers? Manufacturers of bank deposit boxes?
This is how our legal system works. A prosecutor takes past legal precedent and tries to expand it to include whatever it is that they are trying to do. Thus, the use of the All Writs Act from 1789 to try to unencrypt a phone.
Because part of the key comes from a UID that is burned into the CPU, and not recorded anywhere else. This makes it so that you can't unlock the image without being on the hardware itself, unless you have some kind of magical crack for AES-256, or several hundred thousand years to brute force the key.
It's not conspiracy and conjecture, it's "legal precedent" and it's an actual thing. Once it's happened in a single instance, that single instance can be pointed to in future cases until it's refuted by a higher level judge. Which, in this case, would mean either the Federal Appeals Court, or the United States Supreme Court.
It's how the whole legal system has worked for 225+ years. And you can bet that there are hundreds of phones in evidence lockers with assistant District Attorneys and assistant US Attorneys lining up to get a court order to have Apple unlock them, depending on how this plays out.
A firmware update ALWAYS generates a new encryption key. The only difference is that if you have the passcode, you can get the old key out before that happens, and re-insert it after the update.
There are only two possible update modes for the Secure Enclave:
1. The passkey is entered, and the firmware is updated without wiping the keys contained within. 2. The passkey is not entered, and the firmware is updated with the key storage being overwritten with new keys, and the phone's user data is lost to time.
This is documented in Apple's technical notes about the Secure Enclave.
Well, it's an academic discussion because the phone in question is an iPhone 5C, which doesn't have the Secure Enclave.
If it did, then the FBI would be fucked. But, because it's the last model without it, this type of brute forcing of the PIN is still possible if the OS doesn't prevent it, which is exactly what they are asking for.
In versions past the 5C, it is in immutable memory within the "Secure Enclave." The only two ways to update that chip are to put in the right passcode, or have it wipe the existing AES-256 key when it takes it's new firmware.
The iPhone 5C is the last phone where Apple hasn't implemented the security in a fully separate chip that requires authentication, or a wipe to update the firmware.
So by your own standard, they're doing it properly now.
Who says they will be updating this remotely? Is the FBI and Apple incapable of buying a $9 cable from Amazon.com? Why in the name of everything that exists does everyone think they would be applying this update over-the-air, which would require the device to be unlocked?
If you have the physical device, you can put it into DFU (Device Firmware Update) mode which allows you to cable up with iTunes and push a new signed firmware image to the device, with userland remaining unmounted and encrypted. It then reboots onto the new firmware, with userland mounted and the device locked until the passcode is entered.
This is not a "back door" as the encrypted data stays locked and secure the whole time, and the only acceptable firmware images must be signed and valid at the time of upload to the device. There have been many articles in the past of Apple de-validating old versions of iOS, and they do this all the time with beta images in the developer program.
They have the fucking phone in a lab. There's absolutely no reason to have to do this over-the-air when they can just throw it into DFU mode and drop the new custom OS image directly to the phone and never even look at encrypted userland in the process. DFU mode will only upload an OS that has been signed with Apple's signing key, which I'm guessing that Apple has access to.
This is reasonably secure as long as the signing key is kept secure, or invalidated immediately if compromised.
Anyone could install arbitrary code on your phone if they have physical access and architectural knowledge. Do you really think that Samsung, LG, or Sony couldn't do the same? Do you think they'd bother resisting a court order?
My guess is that the iOS image is not encrypted with the rest of the device, meaning that they could pull the flash chips, make a backup, then swap a custom iOS image onto them which they signed with their signing certificate. Then solder back into the iPhone 5C and power it up. Commence cracking.
I guess I'm just curious as to if the federal judge would be satisfied by this solution:
1. A representative from the FBI is allowed to observe a labratory at Apple from behind a glass partition, after having any electronic devices removed from him / her, in order to prevent transmission or duplication of Apple proprietary technology, but be able to testify to chain-of-custody of the phone they want unlocked. 2. Apple takes a complete backup of the flash storage chips in the phone 3. Apple, in this lab, creates a specific branch of their iOS code to unlock this phone, where it is loaded onto this phone only. 4. Apple then downloads the contents of the phone and burns it to a DVD. 5. Apple then destroys the branch of code that allows this, and any binary copies of the iOS image, as well as the copy on the phone itself, resetting the on-device storage to the copy taken before. 6. The FBI is sent on their way, with the DVD copy of the phone's contents, unencrypted. 7. Apple is recognized by the federal judge as having complied with the court order.
No, it doesn't deal with the knowledge in the developers' heads, but the code would have to be signed and delivered in the lab, but it is presumed that Apple keeps their code signing certificates somewhat secure to prevent rogue hacked versions of their OS.
My guess is that it's probably not possible without doing some serious work, such as imaging the phone as a "backup", wiping it, updating the OS, and then restoring the "backup" over the top, which would then restore the encrypted data. Because this phone doesn't have the "Secure Enclave" the encryption key is stored somewhere in flash, and likely would be backed up with the rest of the data.
I know that every time there was an iOS update delivered over the air since they added that capability, it makes you put in your password / use your fingerprint to start the update, so I'm guessing that is the mechanism for getting access to the encryption key.
Yeah, because we should just let this legal precedent go, because it will in no way ever be used to justify an expansion of this practice, and in absolutely no way would it ever be used to pressure a company not named Apple to do the same.
Slashdot Mirror
Yeah, because Google never changes policies after people start using a service.
Or by intentionally allowing them to man-in-the-middle your site, allowing them to track and analyze every visitor, regardless of if you are using their Analytics product?
Yeah, but that doesn't play with the publicity stunt that a "tough on crime" district attorney wants to parlay into a seat in Congress, or a US Attorney seat, or a judgeship somewhere, etc.
Putting out a press release saying you are doing a thing, and then six months later not doing that thing because the story has faded is how county DAs become mayors, mayors become congressmen, congressmen become governors, etc.
You would think so, but I'll bet there are amazingly few organizations that have made that connection.
I don't care what their motivations are. Their motivations have brought them to the correct side of the issue, regardless.
This is an insanely bad precedent that the FBI is trying to set. They probably don't even give a shit what's on the phone - they want the body of legal opinion that they can use in the future.
I hope Apple takes this thing all the way to the Supreme Court.
More than that, using the enshrined appeals process to make sure that you are being correctly compelled by a PRELIMINARY order means you are on the side of the terrorists.
It's not even an actual court order yet - that won't get issued until after the 26 February deadline (tomorrow) for Apple to file a motion that this would be unreasonably burdensome, which Apple will most certainly do. Then there will be a hearing on 22 March where the real decision from the Federal Magistrate will come down, and that will be the actual court order. Then, Apple (or the FBI) can (and will) request that the case get transferred to another district court judge, to see if they agree with the first one, during which time there will be a stay applied to the order. That will bring us some time into the summer before it's over. Then the appeal to the Ninth Circuit Court of Appeals begins, first with a 3-judge panel, and if the parties aren't satisfied by that, the full panel of appellate court judges.
Then, they can apply to have the Supreme Court hear the case. The road ends if they decline it, or continues all the way to a decision if they hear it.
This won't be over any time in 2016, and probably not in 2017 either, depending on how stubborn the FBI wants to be about it. We already know how stubborn Apple will be about it.
You would be surprised. The concept of Mobile Device Management is well known within large enterprise, but largely unknown outside of that. And here's why:
1. Government passes laws that require publicly traded companies to audit and positively manage access control and data safety (Sarbanes-Oxley, HIPAA, etc.) or the companies have institutional requirements for the same or beyond (PCI compliance).
2. Other companies make products that will allow large enterprises to comply with these rules and regulations, through things like data-at-rest encryption, IPSec, MDM, PKI, etc.
3. These companies then use these products and services to comply, so they don't get a massive bollocking at the hands of government.
4. The same laws don't apply to the government, so they don't bother. What's a "best practice"?
I'm against the home builder being compelled to kick the door in for the police because they can't figure out the lock. That's a closer analogy.
Don't mix this case in TFA with what Secure Enclave brings to the table. iPhone 5C, the phone that all this is about, does not have a Secure Enclave.
On this particular phone, it is possible. Thus, they are not taking that legal strategy.
If it was a 5S or a 6, that is exactly what they would have done, because it probably is impossible without having an untold amount of computing power for an untold amount of time.
Of course Apple can deliver what the FBI wants in this case - this phone doesn't employ the much more hardened security of the 5S and above. They could comment out a couple of functions in the code (wipe after 10 attempts, increase time delay between incorrect attempts), build it, sign it, put the phone into DFU mode and upload it. It would take one engineer less than a day.
They are fighting the legal precedent of allowing a Federal Court Judge to compel a company to compromise their product on a whim. This doesn't even stop at phones - are you telling me that some assistant District Attorney out there wouldn't try to use this precedent to compel a company who makes a secure USB stick to give law enforcement a peek? How about safe manufacturers? Manufacturers of bank deposit boxes?
This is how our legal system works. A prosecutor takes past legal precedent and tries to expand it to include whatever it is that they are trying to do. Thus, the use of the All Writs Act from 1789 to try to unencrypt a phone.
Because part of the key comes from a UID that is burned into the CPU, and not recorded anywhere else. This makes it so that you can't unlock the image without being on the hardware itself, unless you have some kind of magical crack for AES-256, or several hundred thousand years to brute force the key.
It's not conspiracy and conjecture, it's "legal precedent" and it's an actual thing. Once it's happened in a single instance, that single instance can be pointed to in future cases until it's refuted by a higher level judge. Which, in this case, would mean either the Federal Appeals Court, or the United States Supreme Court.
It's how the whole legal system has worked for 225+ years. And you can bet that there are hundreds of phones in evidence lockers with assistant District Attorneys and assistant US Attorneys lining up to get a court order to have Apple unlock them, depending on how this plays out.
I imagine it works this way:
A firmware update ALWAYS generates a new encryption key. The only difference is that if you have the passcode, you can get the old key out before that happens, and re-insert it after the update.
At least, that would be the secure way.
There are only two possible update modes for the Secure Enclave:
1. The passkey is entered, and the firmware is updated without wiping the keys contained within.
2. The passkey is not entered, and the firmware is updated with the key storage being overwritten with new keys, and the phone's user data is lost to time.
This is documented in Apple's technical notes about the Secure Enclave.
Well, it's an academic discussion because the phone in question is an iPhone 5C, which doesn't have the Secure Enclave.
If it did, then the FBI would be fucked. But, because it's the last model without it, this type of brute forcing of the PIN is still possible if the OS doesn't prevent it, which is exactly what they are asking for.
In versions past the 5C, it is in immutable memory within the "Secure Enclave." The only two ways to update that chip are to put in the right passcode, or have it wipe the existing AES-256 key when it takes it's new firmware.
The iPhone 5C is the last phone where Apple hasn't implemented the security in a fully separate chip that requires authentication, or a wipe to update the firmware.
So by your own standard, they're doing it properly now.
Who says they will be updating this remotely? Is the FBI and Apple incapable of buying a $9 cable from Amazon.com? Why in the name of everything that exists does everyone think they would be applying this update over-the-air, which would require the device to be unlocked?
If you have the physical device, you can put it into DFU (Device Firmware Update) mode which allows you to cable up with iTunes and push a new signed firmware image to the device, with userland remaining unmounted and encrypted. It then reboots onto the new firmware, with userland mounted and the device locked until the passcode is entered.
This is not a "back door" as the encrypted data stays locked and secure the whole time, and the only acceptable firmware images must be signed and valid at the time of upload to the device. There have been many articles in the past of Apple de-validating old versions of iOS, and they do this all the time with beta images in the developer program.
Exactly.
They have the fucking phone in a lab. There's absolutely no reason to have to do this over-the-air when they can just throw it into DFU mode and drop the new custom OS image directly to the phone and never even look at encrypted userland in the process. DFU mode will only upload an OS that has been signed with Apple's signing key, which I'm guessing that Apple has access to.
This is reasonably secure as long as the signing key is kept secure, or invalidated immediately if compromised.
Anyone could install arbitrary code on your phone if they have physical access and architectural knowledge. Do you really think that Samsung, LG, or Sony couldn't do the same? Do you think they'd bother resisting a court order?
My guess is that the iOS image is not encrypted with the rest of the device, meaning that they could pull the flash chips, make a backup, then swap a custom iOS image onto them which they signed with their signing certificate. Then solder back into the iPhone 5C and power it up. Commence cracking.
I guess I'm just curious as to if the federal judge would be satisfied by this solution:
1. A representative from the FBI is allowed to observe a labratory at Apple from behind a glass partition, after having any electronic devices removed from him / her, in order to prevent transmission or duplication of Apple proprietary technology, but be able to testify to chain-of-custody of the phone they want unlocked.
2. Apple takes a complete backup of the flash storage chips in the phone
3. Apple, in this lab, creates a specific branch of their iOS code to unlock this phone, where it is loaded onto this phone only.
4. Apple then downloads the contents of the phone and burns it to a DVD.
5. Apple then destroys the branch of code that allows this, and any binary copies of the iOS image, as well as the copy on the phone itself, resetting the on-device storage to the copy taken before.
6. The FBI is sent on their way, with the DVD copy of the phone's contents, unencrypted.
7. Apple is recognized by the federal judge as having complied with the court order.
No, it doesn't deal with the knowledge in the developers' heads, but the code would have to be signed and delivered in the lab, but it is presumed that Apple keeps their code signing certificates somewhat secure to prevent rogue hacked versions of their OS.
My guess is that it's probably not possible without doing some serious work, such as imaging the phone as a "backup", wiping it, updating the OS, and then restoring the "backup" over the top, which would then restore the encrypted data. Because this phone doesn't have the "Secure Enclave" the encryption key is stored somewhere in flash, and likely would be backed up with the rest of the data.
I know that every time there was an iOS update delivered over the air since they added that capability, it makes you put in your password / use your fingerprint to start the update, so I'm guessing that is the mechanism for getting access to the encryption key.
Yeah, because we should just let this legal precedent go, because it will in no way ever be used to justify an expansion of this practice, and in absolutely no way would it ever be used to pressure a company not named Apple to do the same.