4 ms·

So who changed the password? And why hasn't the FBI asked for the new password?

deathanatos 11y ago
The employer[1]: > 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-fafe53bb0002 http://www.politico.com/f/?id=00000152-fae6-d7cd-af53-fafe53... [2]: https://news.ycombinator.com/item?id=11137995 https://news.ycombinator.com/item?id=11137995
- hayksaakian 11y ago
  in terms of amount of information, would it be trivial to count the number of nonzero bytes on the phone's disk? then compare that to the backup?
  - deathanatos 11y ago
    This requires intimate knowledge on how the disk is encrypted by the software, I imagine. Speculating: 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.>" [1]: https://www.cacd.uscourts.gov/records https://www.cacd.uscourts.gov/records
    - MBCook 11y ago
      My understanding is that the device has iOS 7 and full disk encryption wasn't enabled by default until iOS 8. Do we actually know if the file system is encrypted?
  - striking 11y ago

The employer[1]: > 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-fafe53bb0002 http://www.politico.com/f/?id=00000152-fae6-d7cd-af53-fafe53... [2]: https://news.ycombinator.com/item?id=11137995 https://news.ycombinator.com/item?id=11137995

hayksaakian 11y ago
in terms of amount of information, would it be trivial to count the number of nonzero bytes on the phone's disk? then compare that to the backup?
- deathanatos 11y ago
  This requires intimate knowledge on how the disk is encrypted by the software, I imagine. Speculating: 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.>" [1]: https://www.cacd.uscourts.gov/records https://www.cacd.uscourts.gov/records
  - MBCook 11y ago
    My understanding is that the device has iOS 7 and full disk encryption wasn't enabled by default until iOS 8. Do we actually know if the file system is encrypted?
- striking 11y ago