Judge Tells Apple To Help FBI Access San Bernardino Shooters' iPhone (engadget.com) 610
An anonymous reader writes: After a couple shot 14 people in San Bernardino, CA before being killed themselves on December 2nd, the authorities recovered a locked iPhone. Since then, the FBI has complained it is unable to break the device's encryption, in a case that it has implied supports its desire for tech companies to make sure it can always have a way in. Today the Associated Press reports that a US magistrate judge has directed Apple to help the FBI find a way in. According to NBC News, the model in question is an iPhone 5c, but Apple has said that at least as of iOS 8 it does not have a way to bypass the passcode on a locked phone.
I can see it now... (Score:5, Insightful)
"Judge orders arsonist to unburn-down house"
Good luck with that.
Re: (Score:2)
Re: (Score:3, Funny)
Taking apart the chip gets you what? They've already got the encrypted data. If they key was on the phone and did not rely on any external key then they could just turn on the phone and it'd be done. So there's an external key that they don't have and will never get off of any chip.
What the FBI is really saying is that they don't believe Apple. They're so used to spying that they probably find it inconceivable (yes it means what I think it means) that a big corporation would not also have a backdoor for
Re:I can see it now... (Score:5, Insightful)
Re:I can see it now... (Score:5, Informative)
As it happens, I don't support or have an iphone, so I have no idea what apple does, but I find it very plausible that there is absolutely nothing they can do, especially if they got pissed at their treatment early and removed any method they previously had to unlock it, even if it was for the cops when they have a proper warrant for the information. In which case, don't forget your key or it's toast.
Re:I can see it now... (Score:5, Informative)
I support the full line of Apple prodcuts at work so I have a slightly better understanding of how this process works.
Unlike firmware updates on many devices, and older Apple iOS devies, the new ones require the firmware to be "signed", each time it is installed. This means the device will roll up its own salt, and will send a request to Apple's Firmware Signing Server. This server uses the salt and the checksum on the fimware to generate a verifiable cryptographic signature, using public key tech. iTunes sends this signature back to the phone during the restore. If it's invalid, the phone's hardware will refuse to install it. (iTunes normally will prevent it sooner, but this is assuming you have hacked iTunes, no easy task)
Around 1-2 weeks after Apple releases a new iOS, they stop signing the old one. This prevents you from downgrading your phone's firmware. It doesn't matter if you've already downloaded and kept a copy of it. Apple won't sign it with the new salt the phone is going to generate during the installation process. So users cannot hack the firmware OR install an older version to take advantage of a patched bug.
BUT... Apple has the secret part of the key for signing. They can roll their own custom firmware, sign it, and using a well-known public process, select the firmware and upload it. Their key servers will sign it, and the device will accept it. If Apple really wanted to fullly cooperate, it would be trivial to do. The new "security enclave" prevents them from simply ignoring the pin or displaying it on the screen, but it's possible that one or more of their requests could be accomodated. It really depends on how the SE is designed. If it's designed well, and I think we can assume it is, (they're not morons, and they have a functionally unlimited budget for such a minor thing) we should assume the SE does rate limiting in hardware. (usually via MANY hashes to dig down to the key) which is not bypassable unless you can rip the data from the hardware and feet it into a supercomputer. The USB/BT code entry is probably doable since its outside the scope of the SE. The master key should be stored inside the SE so software can't get around that.
End game: to give them what they want will require physical hacking of the SE, to recover the encrypted key and the internal salt the SE has generated for it, and feeding that data into an emulator for the SE (or a physically redesigned/hacked SE) that can work the passcode. The hardware on the phone itself right now CANNOT be used to recover the passcode. The FBI doesn't want to break the chip trying to recover the data. They have the techniques but (A) there's a good chance they break it and they get just one try, and (B) this will go a lot faster with Apple cooperating on bypassing the SE. (they can probably still DO it, they may even have the process already developed, but it will probably be faster with Apple's cooperation)
That leads us to another point... what if they already can access the data, or have accessed the data, and this is just a show? It's been said that the best form of deception is making your opponent believe you have fallen for his deception. Right now the terrorists are keeping a close eye on this case, trying to decide whether it's a "good idea" to use the iphone. If Apple gives them the finger, (and I hope they do) and the FBI shrugs and goes away moping, and suddenly has a breakthrough a few months from now from a "classified source", well, guess what. And that, sir, is where all my chips are placed.
Remember, this is one case. You have to think BIG. You have to think long term. This is neither of those things. The FBI either already has this data, or will have it before th
Re:I can see it now... (Score:4, Insightful)
Good luck with that.
Failure might be what the judge wants. And in a very public forum. Can't crack the password? Oh noes! Tragedy! Something must be done. The terrorists have gotten away with it.
For all we know, there is nothing on the phone other than a bunch of duck-face terrorist selfies. But this is very much in the public's eye. So now is the time for the dog and pony show.
Re:I can see it now... (Score:5, Insightful)
Re:I can see it now... (Score:5, Insightful)
Presumably they want info on who they where talking to. If the shooters had accomplices, the FBI wants to know who they are.
If only we had an agency who is (lawfully or otherwise) intercepting every electronic signal known to mankind, who could be consulted when national security concerns arise...
Re:I can see it now... (Score:4, Funny)
There's No Such Agency in the US, you know :P
Re:I can see it now... (Score:5, Funny)
Its pretty trivial to use this technique with Visual Basic, once you've identified the iOS device's IP address, you're home free.
Re: (Score:2)
...and, as I understand it, the IP Address is 512.276.128.17.
Re: (Score:2)
Ah yes, I now have access. Very interesting. He was talking with Gr.........NO CARRIER
Re:I can see it now... (Score:5, Interesting)
...and, as I understand it, the IP Address is 512.276.128.17.
I've noticed TV shows lately have started using the non-routeable class Cs, rather than completely invalid IP addresses. Which actually makes very good sense, since the 555 telephone exchange is the direct equivalent.
Re: I can see it now... (Score:5, Funny)
They want to make it somewhat realistic ...
Re: (Score:2)
I don't think it's that dire. One can almost always break in if you have physical control of the device. At worse you have to hook up JTAG and watch the instructions being executed, look for the pattern in the code where encryption is checked and force signals to be in the configuration you want.
That only works if the key is stored on the device, and the text the user types is merely a password to authorize use of the key, which would be a damn silly implementation.
OTOH, the phone probably has a short key, and brute force would likely work, though you may need to physically bypass the CPU (in inbuilt software) in order to bypass any limit on number of attempts.
Re: (Score:2)
1. In my experience apps can run in the background and use wifi while the device is locked.
2. That really shouldn't be that difficult for the company that manufactured the thing.
Re: (Score:2)
1. In my experience apps can run in the background and use wifi while the device is locked.
Letting the thing actually run sounds dangerous to me, and certainly not a normal forensic technique. Heck, it could do something as simple as wipe all files when a certain date is reached. Best not to let it.
Re:I can see it now... (Score:5, Informative)
2. That really shouldn't be that difficult for the company that manufactured the thing.
Would you expect a safe manufacturer to be able to easily crack open a random safe they manufactured? If so, why? If not, why do you think encryption for a mobile device should be any different?
The company that installed our safe said they could open it when we asked what would happen if we lost the combination. They said "No problem, we'll just bring in a cutting torch and grinder and a few hours later we'll have it open. You'll need to sign a waiver first absolving us of any damage to the room."
Re:I can see it now... (Score:5, Insightful)
Re: (Score:3, Insightful)
Since the iPhone 4, the NAND memory has been encrypted. With a key unavailable to software.
It's why a complete phone wipe on iPhone 3GS and prior took several hours, while only taking seconds on an iPhone 4 and up.
So dumping the NAND does absolutely nothing - the key used to encrypt
Re: I can see it now... (Score:2, Insightful)
"and to the really smart criminals"
You mean the FBI?
Re: (Score:3)
Over the years, I've seen many people try to use an analogy that involves a physical object or action and something to do with computers. Often, the analogy is made with a car. Yet, very seldom has it been successful.
You can physically crack a safe with tools and a little bit of time. This is not possible with good encryption. No, I can't think of a good analogy.
It's like a car with like a billion ignitions and you need to, you know, get all the keys, but they're like a metre long and have to go in the right order or something....and are made of unobtainium.
Nope.
On-device key useful for secure deletion (Score:2)
That only works if the key is stored on the device, and the text the user types is merely a password to authorize use of the key, which would be a damn silly implementation.
Actually isn't that how it works on a modern iPhone, the key to decrypt storage is only on-device? What makes it not silly is that to "erase" a phone prior to transfer to someone else all that needs to be done is that the on-device key is destroyed and replaced with a new key by which data on media will now be encrypted/decrypted.
Re: (Score:2)
Any key that's stored on the device can easily (but not cheaply) be retrieved, unless the device is FIPS 140-2 Level 3 (and eventually be retrieved unless it's Level 4). It can be as trivial as bypassing the instruction that checks the password, or as tedious as forcing the key to leak through side-channel attacks, but Apple could certainly do it.
Re:On-device key useful for secure deletion (Score:5, Insightful)
Apple devices from the iPhone 5s and onward use a "Secure Enclave" [apple.com] which is basically tamper-proof hardware key management.
This phone in question is the 5c, so Apple might actually be able to attack it. Unfortunately, this will make the judge think any iPhone can be attacked by Apple.
Although, I'm really not clear under what authority the Judge believes he has the power to compel Apple to do all this work against their business interests. It used to be they'd have to threaten, in secret, to put the CEO in prison [wikipedia.org] to get this kind of cooperation. Now a judge just commands it? #ussa
Re: (Score:2)
How will the phone decrypt without the keys? If the phone could decrypt on its own then there's be no need to pull in special experts here you could just turn on the phone and read the data.
Re: (Score:2)
That will get you past the lock screen but it's not much help if the phone's data is actually encrypted.
Only the correct passcode will help there.
Re: (Score:2)
Re:I can see it now... (Score:4, Informative)
Re:I can see it now... (Score:5, Informative)
Hardware key storage should wipe itself after so many failed attempts.
/sigh, RTFA... This is exactly what happens after 10 bad entries. So the gov't wants Apple to write them software to let them bypass the wipe and continue brute forcing the unlock code.
Re:I can see it now... (Score:5, Interesting)
It should be possible to bypass the erase operation with physical access to the device. Most NAND devices have a write protect pin which when pulled low will disable program and erase operations.
It may also be possible to add a socket and duplicate the encrypted flash chip so that the original is never in the phone. This could be complicated if the flash device supports a unique ID and the encryption platform makes use of it. I could think of several ways to bypass even that though. One way is to use an FPGA to create a flash emulator that can simulate the NAND device. One other advantage of this is that it could guarantee that the data is never erased. The encryption hardware itself must also store the number of authentication attempts in some non-volatile storage. Usually this would be on another chip or die since it's still not very common to mix flash and logic on the same chip.
Unless the encryption and erase functionality is built into the Toshiba NAND device Apple uses it should be possible to pop the NAND device and use an FPGA and/or other hardware for forensic purposes since the iPhone is not built to FIPS standards (which usually pot the boards in epoxy and provide a number of methods to prevent physical intrusion).
Even the secure keys that are not known by Apple should be accessible with physical access to the device. It's expensive, but it should be possible to read the blown fuses by digging through the layers if the exact location is known on a chip.
https://media.blackhat.com/bh-... [blackhat.com]
Re:I can see it now... (Score:4, Informative)
> it should be possible to pop the NAND device
This is not a reliable thing. You can desolder a BGA, but the odds of breaking the device in the process are pretty good. Maybe if you are the police you find the risk of destroying the potential evidence unacceptable, even if you cannot get at the evidence any other way because crypto and physical security done well works.
Re: (Score:3)
It's actually fairly reliable today and is fairly common. I regularly work with boards with BGAs with over 1000 balls that are replaced.
Also, look up what is possible with FIB. You can basically cut through traces and build new traces on the fly on a chip, going through multiple layers or even adding new layers on top of a chip. It's not even particularly expensive and it is done regularly in the semiconductor industry especially during chip prototyping. Hell, a recent chip I worked with had to be "Fibed" t
Re:I can see it now... (Score:5, Interesting)
You are describing some aspects of my day job. I know the statistics of these operations.
Replacing a BGA is one thing. Pulling a BGA, depackaging it and FIBing it is likely to fail. This isn't a problem if you can just do 10 and pick the ones that work. But if it's a single chip from a single phone, the odds are not good.
Re:I can see it now... (Score:5, Insightful)
Isn't this the exact attack that physical anti-tamper is meant to defeat?
It is one attack model that an anti tamper system might be designed to resist. However it is also an attack model that some systems choose not to defend against in a simple cost/benefit analysis. If the secret on the chip has a commercial cost less that the cost of the attack, then why defend against it? The gear to mount a FIBing attack is millions of dollars. Paying a reverse engineering company is less, but > $10E6. This is related to whether or not your system has BORE properties (Break One, Reuse Everwhere).
This does not apply here. The perception of the worth of product like a smartphone can be very tied up with perceptions of how secure it is, and being required to pull the rabbit out of the hat by a court and then you actually unlock a phone you claimed you can't unlock, then that might well destroy those perceptions of security and cost a lot in lost sales. So designing it so you can't yourself defeat the security you put in is the only sane option.
The court order [regmedia.co.uk] presumes that the auto erase functionality can be bypassed with software to be provided by Apple. This is likely be unbypassable either because the key management system is enforcing the retry limit in hardware or protected firmware, away from the main application code, or the software that does it simply doesn't have a back door.
The company I work for is in the same position. We can't and won't put in back doors because being found to have lied about the security of the devices would be an existential threat to the company. That doesn't stop people who don't know lying on the internet, claiming we put in back doors, but it's not a rational thing to do.
Huh? (Score:4, Informative)
There's no word on exactly which model of iPhone was recovered
Huh? The article clearly states a model:
According to NBC News, the model in question is an iPhone 5c
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Re:Huh? (Score:5, Informative)
Re:Huh? (Score:4, Funny)
Haha well... have you seen any APK spam lately?
If you've managed to neuter that obnoxious scumbag (or even just slowed him way down), I salute you. Seriously.
Re:Huh? (Score:4, Funny)
Haha well... have you seen any APK spam lately?
God-fucking bless man. Thank you. Dude must be stewing in his own juices angry
Re: (Score:3)
"Can your new site do 16 things?"
Re: (Score:2)
Re: (Score:2)
The 5c originally shipped with iOS 7, which apple can get into if they want. It will be interesting to see what happens. Maybe apples claims about being 'locked out' of iOS 8 is bunk. Maybe they didn't password protect their phone. Maybe apple can guess their iCloud password ('12345'?), or access their gmail and reset the password. Once they have the iCloud password, and if there's an online backup, they can restore the backup to another phone. There are plenty of options beside brute forcing that hardware.
Re: (Score:2)
Assuming they used the 4 digit pin instead of a password yup just 10K passwords.
Everyone just uses the 4 digit pin because typing anything longer several times a day just to use your phone is a serious pita.
Otherwise what do they expect to find that they haven't already gotten from the phone company call recor--err "metadata"?
Re:Huh? (Score:5, Informative)
You mistake an iPhone's unlock code with the iPhone's encryption key. the iPhones do typically use a 4-6 digit pin as an unlock code. The user also has the ability to create a full alphanumeric password for the unlock code as well. However, that is simply the code that's used to unlock the actual full encryption key that is stored within dedicated crypto hardware. Apple uses a dedicated chip to store and process the encryption. They call this the Secure Enclave. The secure enclave stores a full 256-bit AES encryption key.
Within the secure enclave itself, you have the device's Unique ID (UID) . The only place this information is stored is within the secure enclave. It can't be queried or accessed from any other part of the device or OS. Within the phone's processor you also have the device's Group ID (GID). Both of these numbers combine to create 1/2 of the encryption key. These are numbers that are burned into the silicon, aren't accessible outside of the chips themselves, and aren't recorded anywhere once they are burned into the silicon. Apple doesn't keep records of these numbers. Since these two different pieces of hardware combine together to make 1/2 of the encryption key, you can't separate the secure enclave from it's paired processor.
The second half of the encryption key is generated using a random number generator chip. It creates entropy using the various sensors on the iPhone itself during boot (microphone, accelerometer, camera, etc.) This part of the key is stored within the Secure Enclave as well, where it resides and doesn't leave. This storage is tamper resistant and can't be accessed outside of the encryption system. Even if the UID and GID components of the encryption key are compromised on Apple's end, it still wouldn't be possible to decrypt an iPhone since that's only 1/2 of the key.
The secure enclave is part of an overall hardware based encryption system that completely encrypts all of the user storage. It will only decrypt content if provided with the unlock code. The unlock code itself is entangled with the device's UDID so that all attempts to decrypt the storage must be done on the device itself. You must have all 3 pieces present: The specific secure enclave, the specific processor of the iphone, and the flash memory that you are trying to decrypt. Basically, you can't pull the device apart to attack an individual piece of the encryption or get around parts of the encryption storage process. You can't run the decryption or brute forcing of the unlock code in an emulator. It requires that the actual hardware components are present and can only be done on the specific device itself.
The secure enclave also has hardware enforced time-delays and key-destruction. You can set the phone to wipe the encryption key (and all the data contained on the phone) after 10 failed attempts. If you have the data-wipe turned on, then the secure enclave will nuke the key that it stores after 10 failed attempts, effectively erasing all the data on the device. Whether the device-wipe feature is turned on or not, the secure enclave still has a hardware-enforced delay between attempts at entering the code: Attempts 1-4 have no delay, Attempt 5 has a delay of 1 minute. Attempt 6 has a delay of 5 minutes. Attempts 7 and 8 have a delay of 15 minutes. And attempts 9 or more have a delay of 1 hour. This delay is enforced by the secure enclave and can not be bypassed, even if you completely replace the operating system of the phone itself. If you have a 6-digit pin code, it will take, on average, nearly 6 years to brute-force the code. 4-digit pin will take almost a year. if you have an alpha-numeric password the amount of time required could extend beyond the heat-death of the universe. Key destruction is turned on by default.
Even if you pull the flash storage out of the device, image it, and attempt to get around key destruction that way it won't be successful. The key isn't stored in the flash itself, it's only stored within the secure enclave itself which you can't remove the stora
Re:Huh? (Score:5, Informative)
That isn't correct, according to the white paper:
"The backup set is stored in the user’s iCloud account and consists of a copy of the user’s files, and the iCloud Backup keybag. The iCloud Backup keybag is protected by a random key, which is also stored with the backup set. (The user’s iCloud password is not utilized for encryption so that changing the iCloud password won’t invalidate existing backups.)
While the user’s keychain database is backed up to iCloud, it remains protected by a UID-tangled key. This allows the keychain to be restored only to the same device from which it originated, and it means no one else, including Apple, can read the user’s keychain items.
On restore, the backed-up files, iCloud Backup keybag, and the key for the keybag are retrieved from the user’s iCloud account. The iCloud Backup keybag is decrypted using its key, then the per-file keys in the keybag are used to decrypt the files in the backup set, which are written as new files to the file system, thus re-encrypting them as per their Data Protection class."
The relevant sections begin at page 38, in which the paper discusses iCloud, Apple ID, and general Internet Services security. Your misunderstanding stems from the mistaken belief that you can just "restore" the iCloud backup of your phone to a new device. But to do this, you need access to the user's Apple ID password. If two-step verification is turned on, Apple definitely has no way to circumvent this.
Where's my tinfoil hat? (Score:5, Insightful)
I wouldn't be surprised if this was nothing more than a joint PR stunt to mislead people into assuming privacy on their cellphone so they wouldn't be afraid to use it for sensitive information. Government has nothing to win by disclosing they have a backdoor, neither does the cellphone manufacturer. Even thinking lo-fi decryption, how long must the passcode be before brute-forcing gets more inconvenient for the government than for the user?
Re:Where's my tinfoil hat? (Score:5, Insightful)
Comment removed (Score:5, Informative)
Let's also order the gun manufacturer (Score:5, Funny)
to revive the dead people.
What does he expect? (Score:2)
Apple to setup a cloud system to try to brute force PBKDF2???
Re: (Score:3)
Brute forcing BPKDF2 is easy in comparison to what he wants. This is about breaking a secure microcontroller. A few orders of magnitude harder and pure software-attacks will very likely not work.
Re: (Score:3)
Re: (Score:2)
You just gotta ask yourself in these situations... What Would The Donald Do?
Let Apple Try (Score:2)
Re: (Score:2)
I doubt that kind of thing is in an iphone, but who knows.
I would expect that Apple knows. And if there is a procedure that involves getting at the phone's innards or encrypted disk, they will know how.
The code is.... (Score:4, Funny)
It's easy Mr Judge (Score:5, Insightful)
All you gotta do is put the password here and it opens right up. What's that? You don't know the password? Neither do we.
Re: (Score:2)
I honestly think that the FBI doesn't believe this and think Apple is holding out. Well, the FBI workers probably believe it, but the FBI managers who don't understand technology don't believe it. They've got so much experience with data leaking out left and right from unsecure web sites that they suspect the same thing from Apple.
Re:It's easy Mr Judge (Score:4, Insightful)
Re: (Score:3)
The idea that a judge doesn't understand technology is NOT absurd, however.
What if Apple cannot access the info? (Score:5, Interesting)
Re: (Score:3, Insightful)
The phone is encrypted so that it takes a key that is randomly generated and unguessable, however the password that encrypts the key is not unguessable. Running a password guessing program against the key would work, except that the hardware limits how many guesses can be tried over a period of time. What you could do is modify the hardware to allow guessing the password without the limits, but modifying the hardware is extremely difficult. I know that many years ago when I worked with machines intended to
Re: (Score:2, Informative)
And since we have judges who do not understand encryption or technology whatsoever, the judge will simply find Apple didn't do enough to decrypt the phone.
Re: What if Apple cannot access the info? (Score:5, Insightful)
This is why you pay a team of lawyers to show what extravagant actions were done in order to comply with the court order, and convince the judge.
You act like a Federal Judge is a fucking moron or something. They may not understand technology, but they aren't stupid by any means.
Re: What if Apple cannot access the info? (Score:4, Insightful)
how do you show that you tried when it is something you cannot really show progress on until you succeed, and you do not have any ability to guarantee success?
The reason the fbi is blocked is because they don't know the passcode, and this would be equally true for Apple. Apple may be utterly unable to do anything that the fbi cannot do and may have even already tried
The judge may as well have told them to try and go faster than light. There are mathematical reasons why breaking encryption is hard, and being a big company with lots of money doesn't allow one to break the rules of mathematics
I want to post (Score:2)
fock it. Clap, clap, clap
Did they write down their passwords? (Score:4)
Maybe they should ask one of the 5,000,000 various reporters, journalists, and random people eating popsicles if they saw what looked like an iPhone passcode written down somewhere in their house while it was being ransacked live on television a day or two after the attack.
4 Digit Pin? (Score:2, Funny)
Re:4 Digit Pin? (Score:5, Informative)
No problem. 0000. Nope. 0001. Nope. 0002. Nope...
0009. Too many invalid password attempts. Full disk encryption key has been erased. Initiating factory reset of device...
Judges are not bright. (Score:2)
But they do have an inflated sense of power and get all pissy when people don't do the impossible if they demand it.
Judge tells man to lick own elbow (Score:2)
You can't order someone to do the impossible. For practical purposes, breaking the end to end encryption on an iphone is impossible. Who better than the people who developed the software to know this??
Re: (Score:2)
You can't order someone to do the impossible. For practical purposes, breaking the end to end encryption on an iphone is impossible. Who better than the people who developed the software to know this??
I thought that once you had physical access to a device, it was just a matter of time and expertise before you could crack it. Does Apple know some secret techniques that nobody else does, such that an iPhone 5c is physically tamper-proof even by the people who built it and know everything about its design and manufacturing?
That's possible I suppose, but I doubt it.
Re: (Score:2)
The reality would belay that conclusion. There was a news article today about a guy that had a marshals swat team raid is house, arrest him and take him to jail then court where a bank lawyer acting as a prosecutor took him before a judge about an unpaid student loan from 30 year ago that they didn't even bother writing him a letter about. He was ordered to pay triple the amount in 2 weeks or they would arrest him again.
Debtors prisons are apparently back.
They could try this... (Score:2)
If the OS was updated to IOS 9 then there's this fun hack... [ibtimes.com]
Maybe Apple could try a web search to find other vulnerabilities.
Just a thought.
The vast majority of passcodes are 4 digits. (Score:2)
That's 10,000 possibilities. It seems someone could put together a lego robot to try all 10,000. If they were forced to wait 60 minutes between attempts it would be 416 days at most.
Re: (Score:2)
And if you pace attempts correcty, it appears that you only have to wait 1 or 2 minutes between attempts, which is 14 days at worst.
Re: (Score:2)
I'm assuming the FBI could build one of these. [techcrunch.com]
Fishing Expedition (Score:2)
The FBI is trying to find out whether Apple is telling the truth. If not, great, they have their data. If yes, they at least get Apple to reveal everything about their hardware, firmware and software to provide Big Brother with something to work on.
My question is, will we ever know whether is phone is cracked?
read the Ex Parte DOJ filing for the correct story (Score:5, Insightful)
The government is not asking that Apple give out the user's password, or decrypt the phone, both of which they cannot just do (i.e. are incapable of performing). The request is that Apple produce a piece of iOS software or boot image (as I understand it), that would:
1) Disable the auto-erase feature
2) Allow the FBI to brute force submit password guesses to the phone, and
3) Disable or reduce the increasing-delay-between-guesses feature of the passcode lock.
I would be curious to know whether for this iPhone 5c (with iOS 9) this is even possible for Apple to do.
You can see why Apple wanted to get very far away from the business of being in a position to be asked constantly by law enforcement to help decrypt its phones, just for the sheer volume of requests that will be coming if they do....
Re:read the Ex Parte DOJ filing for the correct st (Score:5, Informative)
After reading Apple's iOS Security Guide white paper, it is doubtful that Apple can write any kind of software to load onto the device to permit any of those options. This is because once the device is locked, it will not install any updates to the operating system. The boot firmware is already installed and automatically runs when the device is turned on. Updating the operating system requires the device password. These functions are cryptographically secured. See the section "Keybags," subsection "Escrow Keybag" in the paper. The auto-erase and time delay features are enforced by the Secure Enclave in hardware, and cannot be circumvented.
Re: (Score:3)
NO!
If he had it on icloud, Apple could turn it over. The icloud backups are encrypted BY APPLE.
Check page 4:
www.apple.com/privacy/docs/legal-process-guidelines-us.pdf
Here's some guidelines:
http://manhattanda.org/sites/d... [manhattanda.org]
There's a part where the document sort of complains that users aren't required to back everything up to icloud, because they can just ask for anything in icloud at all and get it in plaintext immediately (as documented by the first link).
If you promise to encrypt "hunter2" your end with A
They do not need that phone (Score:3)
The perpetrators are contained. Finding out why they did it has time and can be done slowly and the old-fashioned way. The only thing they are doing here is to push (again) stupidly for a thing that makes everybody much less safe: backdoors. They must not be allowed to make the current global computing infrastructure even less secure as it is today, just to cater to their laziness. These people are more of a threat than any criminal could ever be.
why? guilt is not in question (Score:3)
This is why Touch ID is a problem (Score:5, Informative)
If the iPhone 5c had Touch ID this wouldn't be a problem, they could just use the persons finger to unlock the device. This illustrates why Touch ID is a bad idea if you care about your privacy. Since we only have ten fingers and the auto erase doesn't activate until after 10 failed attempts, the only thing needed to get into a Touch ID phone is a court order. The Fifth Amendment protection against self incrimination only applies to the contents of your mind, it's established precedent that it doesn't apply to your body (i.g. blood, DNA, finger prints, etc.) or property.
Re:The deed is done (Score:5, Insightful)
It stands to reason that the purpose of trying to decrypt the phone after the event, and after the death of the perpetrators, is to see if there might be any information that might implicate other individuals as accomplices or sympathizers, so that those individuals can be investigated. But if it is not possible for Apple to decrypt the phone, then other avenues of investigation will need to be considered.
Of course, mathematics being what it is, and lawyers and judges being who they are, it is not the least bit surprising that the latter should be ignorant of the former. It's a unique form of hubris to think that one can somehow circumvent a secure cryptographic system by the mere force of law, as if jurisprudence supersedes mathematical truth.
Re:The deed is done (Score:5, Insightful)
Or you know the FBI can look through all the phone records and use their other sources of information. These people had twitter, they know that, they can also easily find their email accounts.
It's the FBI being whiney.
Re:The deed is done (Score:5, Insightful)
The problem is that cryptography is mathematics and doesn't know the difference between criminals and innocent people.
It also doesn't know the difference between law enforcement requests to unlock the phone and criminal requests.
If they can get into a criminal's phone, they can get into anybody's phone. If they can get into anybody's phone, any criminal who gets the key can get into anybody's phone. As to "how likely is it for the criminals to get the keys?"... well, pretty much every system (FBI, DHS, Apple, etc) that could theoretically hold the keys has been breached at some point. Holding that capability also makes a huge target. So "Very Likely", even to the point that when things were previously unlockable, hackers were doing so already.
Thus it comes down to "Do you want to allow criminals to access your iPhone so that law enforcement can also access a criminal's iPhone?" at that level. And in the event that a smart criminal had an indication that Apple could defeat the encryption and lockout, they'd just store the important data in a place that no company controlled or had access to.
Re: (Score:3)
From one point of view, it could be said that I did not say the encryption scheme would be broken in that case. It would be the misappropriation of "legitimate" keys used to access the back door of the encryption system.
From another point of view, if the point of the encryption is to prevent any but explicitly-authorized entities - as defined by the data holder and assumed to not include the pool of "and whoever has backdoor keys to the encryption system" - from accessing the data, the very existence of a b
Re:The deed is done (Score:5, Insightful)
> Except for the Criminal Rights crowd
You mean like the Son's of Liberty? THAT "criminal rights" crowd.
You're such an ignorant moron.
Re:The deed is done (Score:5, Interesting)
Re: (Score:2)
I don't understand why he keeps posting dead links.
Re:Try all combinations (Score:4, Informative)
They can be set so 10 failed tries wipes the phone. They can also set larger passwords than 4 digits.
Re: (Score:2)
I assume they would image the drive first...
Re: (Score:2)
Iirc iPhones use hardware encryption when the reset is hit it changes the hardware key. So then that backup is worthless.
Re: (Score:2)
No. In short: The iPhone's encryption is tied to the physical hardware. Within the chips themselves lies a full 256-bit AES encryption key. The 4-digit pin simply unlocks the encryption key from the chips. They are tamper resistant and you can't just write software to get around their protection of the full encryption key as it's all hardware enforced.
For a full explanation, see my previous post earlier in the article: http://yro.slashdot.org/commen... [slashdot.org]
Re: (Score:2)