What if after all this drama and forcing everyone to install backdoors and disable encryption they find out that they used it only to play Clash of Clans and take pictures of food?
Maybe that's why the FBI is so wound up over this. They often confuse hummous and hamas.
how some secret 3 letter agency has gone rogue and has a long and complex plan to incite a couple of people to terrorism, making sure they conveniently die, leaving no witnessed.
This shadow group then invoke the hearts and minds of the people, through the fear of a series of terror acts to relinquish their privacy rights, happily accepting a legal precedent to remove encryption from the masses. Their end goal being total population control and surveillance on order to control the masses on behalf of a secret and powerful governing elite.
A bunch of FBI agents suspect this secret group have programmed these people to commit these terror acts, and since they are now dead they need to recover the data from the phone to prove this dastardly conspiracy.
Starring Matt Damon as the one rogue ex-agent who brings the whole almost perfect plan crashing down, and Liam Neeson as the FBI agent who is determined to bring this shadowy elite to justice.
However, the auto-backup feature, which would have pushed the most recent data from the phone onto iCloud just by leaving the phone powered on... apparently that is disabled when the iCloud password is reset. Which makes sense if you think about it, the phone still has the old iCloud password, and it would need the new password in order to authenticate to iCloud. So they inadvertently disabled the backup feature by locking the phone out of iCloud!
The first question this raises is can the auto-backup be made to start working again by Apple changing their backend iCloud authentication code to specifically allow this device to login to iCloud with the "wrong" (old) passsword? That would not involve touching the phone and seems like a much cleaner solution. Unless there is code on the phone which disables or destroys the iCloud authentication token / stored password after encountering a login error, which really would surprise me, because API errors could be spurious, but I guess it's possible if they are looking specifically for an "invalid login" return code and then dumping the old token in order to trigger a UI prompt to enter a new password.
The second question is why are the existing backups a month and a half old? Doesn't this imply the device was not even turned on or connected to the network for that last month and a half?
The other interesting tidbit in the article is the statement the FBI was able to verify that the phone was never paired with any devices to obtain data. How in the world could they know that?
(Cross-posting this comment from another article, because it's more relevant here)
"The government says the access being sought could only be used on this one phone, but Apple's executives noted that there is widespread interest in an iPhone backdoor, noting that Manhattan District Attorney Cyrus Vance said Thursday that his office has 175 Apple devices he'd like cracked."
The device in question is an iPhone 5 and doesn't have a Touch ID sensor, so the question is moot anyway.
How about simply photographing the fingers, or, at worst, just fingerprint the dead without removing the digits (which I assume is SOP)?
Edit: or are you suggesting iCloud be programmed to accept any password for this account?
/s
Maybe put the hard drive on a dev board of sorts. AFAIK, most cell-phones have dev board versions that the mfg's engineers use to test various component hardware revisions no?. There they can access it through root? I might be missing something here.
It would be hilarious if after all this, they find nothing on the phone. GENIUS!
> The FBI obtained a warrant to search the iPhone, and the owner of the iPhone, Farook's employer
> the owner, in the hours after the attack, was able to reset the password remotely, but that had the effect of eliminating the possibility of an auto-backup
(the first quote is on page 1 of [1]; the second quote is footnote 7 on page 18 of [1] as pointed out by another commenter[2].)
I think — and frankly, the document isn't too clear on it; it'd be great if an iPhone owner could clarify — is that this is the Apple App Store account password, and the phone has a separate and different passcode. The FBI knows the password, and can access the account, but not the phone; the phone I'm guessing won't back up until the passcode is given to it.
Supposedly the previous backup on the account is allegedly too old: "nearly one-and-a-half months prior to the IRC shooting incident", and even weirder, "back-ups do not appear to have the same amount of information as is on the phone itself" How can the FBI know this if they can't access the information on the phone?
The FBI's point is that this is a one-time use of the software Apple would write, and Apple would maintain possession of the software throughout using it:
> Indeed, it is less so because the software requested would not reside permanently on the SUBJECT DEVICE, and Apple can retain control over it entirely.
> Moreover, to the extent that Apple has concerns about turning over software to the government so that the government can run the passcode check program, the Order permits Apple to take possession of the SUBJECT DEVICE to load the programs in its own secure location, similar to what Apple has done for years for earlier operating systems, and permit the government to make its passcode attempts via remote access. […] no one outside Apple would have access to the software required by the Order unless Apple itself chose to share it. This eliminates any danger that the software required by the Order would go into the "wrong hands" and lead to criminals' and bad actors' "potential to unlock any iPhone in someone's physical possession."
(from page 20 of [1])
Frankly, that sounds rather convincing against the section of Apple's "A Message to Our Customers" headed "The Threat to Data Security" (but I'd love to be proved wrong! why is this a threat to data security given the above?). That said, I'm unsure about the section headed "A Dangerous Precedent" — this does seem like a bad precedent. Are we to now assume that our manufacturer should be included in our threat models for whether our device is secure?
Also, has Apple submitted anything to the court detailing their argument as to why they should not be forced to follow the Order?
[1]: http://www.politico.com/f/?id=00000152-fae6-d7cd-af53-fafe53...
This is because said signing generally takes a whole complicated physical process of assembling physically secure separately kept modules that hold different parts of the signing key, and likely takes the sign-off and personal involvement of multiple senior engineers at the company.
This is absolutely necessary, because the security of literally every iPhone depends on there being absolutely no chance that the signing key ever gets into unauthorized hands.
Now think about what happens to the company when more and more judges start issuing writs that require that this complicated process happens, and when a judge unhappy with the increasingly long processing time for every "software created for a specific device" instance instead issues a writ that demands an insecure version of iOS that can be installed on any iPhone.
I believe you've basically got it. The iCloud password was changed (different from iTunes account), and the phone doesn't know the new password. That means the phone can't backup to iCloud. The solution is to unlock the phone and iOS would prompt you pretty fast for the new password, or you could go straight to settings.
So they need the pin to get in and update the password so they can get the data from iCloud or the pin to get straight in. They're stuck and NEED the pin (short of getting the CIA/NSA or someone to go hardcore and start capping chips or something else more extreme).
The 'erase data after 10 attempts' thing is an OPTION. There is a chance that's not on. The increasing delays when you get the code wrong would probably still make brute-forcing impractical.
then compare that to the backup?
Unfortunately resetting the iCloud password disabled automatic iCloud backups when the phone was on a known wifi network.
7th paragraph or search the text for "One such method."
One can imagine that it is possible, for unused blocks on the disk, to simply encrypt a zeroed out block; essentially, initialize the disk to a state of random data. From the cryptotext, you wouldn't be able to know how much is used. However, for efficiency, I could see this not being done, and disk blocks that never saw use actually being zero.
That said, a previously-used-but-now-freed block might still contain the encrypted content, and just be unlinked from the filesystem. Unless freed sectors actually get zeroed, I would say that the number of non-zero blocks on the disk only indicate an upper bound on the data, and there may be less. (And thus, your backup might appear to have less data than the disk while still containing all the data.)
AFAIK, the filing doesn't elaborate, but I also haven't read all of the filing yet. Nor is this particular filing the only document in the case, and I sadly don't have access to the court documents. It would seem that in the United States, these are behind a paywall (see PACER), though I believe it should be legal to mirror them; it seems that archive.org is attempting to do this with their RECAP project, but they don't seem to have the case (or I can't find it).
The case ID is on the filing in my first post: "5:16-cm-00010-SP"; the format is described here[1]. Essentially, "5 <division of Riverside> :16 <last two digits of the year> -cm <"misc" case>-00010 <the case number, tenth of the year, I think?> -SP <no idea.>"
Since they can't get into the phone, they now can't do that even if they know what the password is (which they probably do).
If they can't keep passwords secure, they aren't going to be able to keep this backdoored iOS version secure either.
The phone is critical evidence, according to the FBI and the legal actions around this phone. If the phone's password was changed after the crime without authority the person who did this would have been charged with tampering with evidence.
> I'd bet they have simply forgotten what they changed it to.
What possible reasoning are you using to conclude that a government employee changing the password of a phone after it was known the phone was used by a terrorist would have "simply forgotten what they changed it to"?
I'm basing all this on this snippet from the article:
> It was then that they discovered that the Apple ID password associated with the iPhone had been changed. (The FBI claimed earlier Friday that this was done by someone at the San Bernardino Health Department.)
Apple see this as the thin end of a wedge, establishing the principle that the feds can force Apple to put backdoors in iOS and Apple can't say no. The thick end of the wedge will have much wider scope and much less oversight.