So, We're siding with Apple, right?

[zxcvbob]

Let's say the courts (all of them) side with .gov and Apple refuses to comply.  What happens next?  APPL packs up and moves to Belize?

[KD5NRH]

Let's say the courts (all of them) side with .gov and Apple refuses to comply.  What happens next?  APPL packs up and moves to Belize?

Could happen.  Not quite going Galt, but pretty darn close, since it would leave the majority of their nonessential personnel out of work (and essential ones with a tough choice) and all the taxes they pay here going to some other government.

I still don't get the frontend issue, though; the memory is a separate SK hynix chip that doesn't appear to have any special security features of its own, so couldn't they pull the raw (encrypted) data, make as many copies as necessary, and (assuming it's not feasible to crack it outside iOS) clone the hell out of the original phone (ask the Chinese how) and work on all their copies in parallel to brute force the code?  For chain of custody/data integrity issues, they could do it non-destructively, work only with their clones, and then open the original once the code is found.

I mean, a) this is the government we're talking about, who should be pretty good at dealing with crypto, and b) they have access to all our pocketbooks to offer a reward to anyone coming up with a better cracking method.

ETA, IMO, they should approach this in terms of what they would do if instead of Apple, they needed to get potentially critical data off of a Highscreen cell phone, or any other manufacturer that isn't based here and doesn't even normally market its products here. 

[brimic]

I mean, a) this is the government we're talking about, who should be pretty good at dealing with crypto, and b) they have access to all our pocketbooks to offer a reward to anyone coming up with a better cracking method.

The king has no clothes!

[dogmush]

I still don't get the frontend issue, though; the memory is a separate SK hynix chip that doesn't appear to have any special security features of its own, so couldn't they pull the raw (encrypted) data, make as many copies as necessary, and (assuming it's not feasible to crack it outside iOS) clone the hell out of the original phone (ask the Chinese how) and work on all their copies in parallel to brute force the code?  For chain of custody/data integrity issues, they could do it non-destructively, work only with their clones, and then open the original once the code is found.

An iPhone can use a 6 digit custom alpha numeric code.

6 digits, with respect given to their order, from a set of 36 characters (I don't know if they can use special characters, or if caps matter, but lets err conservative.) gives us 1,402,410,240 permutations.  10 tries per cloned phone before it bricks means you will need 140,241,024 cloned phones.

[birdman]

Could happen.  Not quite going Galt, but pretty darn close, since it would leave the majority of their nonessential personnel out of work (and essential ones with a tough choice) and all the taxes they pay here going to some other government.

I still don't get the frontend issue, though; the memory is a separate SK hynix chip that doesn't appear to have any special security features of its own, so couldn't they pull the raw (encrypted) data, make as many copies as necessary, and (assuming it's not feasible to crack it outside iOS) clone the hell out of the original phone (ask the Chinese how) and work on all their copies in parallel to brute force the code?  For chain of custody/data integrity issues, they could do it non-destructively, work only with their clones, and then open the original once the code is found.

I mean, a) this is the government we're talking about, who should be pretty good at dealing with crypto, and b) they have access to all our pocketbooks to offer a reward to anyone coming up with a better cracking method.

Better yet, do so in a virtualized emulator environment.  No need to physically brute force.

That said, the way the apple encryption works is part of the key is, in effect, hardware, and can't be read out in a clone...this is the whole secure enclave idea.

It also renders my previous thought of simply grabbing the flash (btw, the Hynix isn't the user data store, the sandisk is, the SK Hynix chip is the ram), as the new phones hardware encrypt the data they are looking for.

The timeout and try count functions aren't hardware, hence the whole govt push, as disabling those is pretty much the only way to get it to work.

[KD5NRH]

10 tries per cloned phone before it bricks means you will need 140,241,024 cloned phones.

Unless it burns traces out of the chips, it's just erased.  Reload your dataset and start where you left off.

Where is the "hardware part" of the key physically located?  Now I'm thinking a constant cycle of cloned data chips (like a jukebox; pull one, drop in the next while taking the one just removed to be reloaded with the original data and a buffer of enough chips to balance out whatever the bottleneck turns out to be) or even a virtual data chip (acts just like the real thing except that it only pretends to erase itself when the command is sent) plugged into the real logic board.

[birdman]

Unless it burns traces out of the chips, it's just erased.  Reload your dataset and start where you left off.

Where is the "hardware part" of the key physically located?  Now I'm thinking a constant cycle of cloned data chips (like a jukebox; pull one, drop in the next while taking the one just removed to be reloaded with the original data and a buffer of enough chips to balance out whatever the bottleneck turns out to be) or even a virtual data chip (acts just like the real thing except that it only pretends to erase itself when the command is sent) plugged into the real logic board.

Inside the CPU.  It's a unique code to that chip, and no other chip, so you can't "clone" the chip.  If you clone everything else, you will never have the full key.  Otherwise, emulation would work for the reasons you suggest.  Also, the reason why it's done the way it is.

See page 7 here:
https://www.apple.com/business/docs/iOS_Security_Guide.pdf

And while you could brute force the UID part and the normal passcode, it would make the problem computationally problematic from a time standpoint.

[Ben]

Some interesting new information:

http://twitchy.com/2016/02/19/changed-the-password-on-san-bernardino-terrorists-phone-and-then-forgot-it/

EDIT: Updated link with correction. Apparently a county employee changed the password while the phone was in the FBI's possession. The FBI did not change the password.

[French G.]

Some interesting new information:

http://twitchy.com/2016/02/19/changed-the-password-on-san-bernardino-terrorists-phone-and-then-forgot-it/

EDIT: Updated link with correction. Apparently a county employee changed the password while the phone was in the FBI's possession. The FBI did not change the password.

So today's lesson is that there is no cloud, it's just someone else's computer. And by someone else we mean the government.

Never back up your phone to icloud apparently.

[MechAg94]

I missed that little factoid.  I guess that IT guy who reset the phone was promoted and is now making more money. 

[zahc]

Still not enough tinfoil in this thread.

Recent revelations that the password on the device was recently changed suggest the obvious..the feds planted evidence on the phone and then changed the password deliberately so the planted evidence could be used later. The password change was required because without it, icloud backup history would have shown the evidence appeared after the shooter was dead.

As you know, the feds are trying to charge the weapons supplier with terrorism charges. Without the planted evidence to establish intent and knowledge of intended end-use of the weapons, they will only be able to stick mere weapons charges.

[Battle Monkey of Zardoz]

http://money.cnn.com/2016/02/20/technology/apple-fbi-san-bernardino-shooting/index.html

Sounds like someone f'ed up.

[230RN]

zahc pointed out.

Recent revelations that the password on the device was recently changed suggest the obvious..the feds planted evidence on the phone and then changed the password deliberately so the planted evidence could be used later. The password change was required because without it, icloud backup history would have shown the evidence appeared after the shooter was dead.

I wondered about that chain of custody thing even before the revelation of the password change because of the possible salting of the info on the phone by agencies or persons unknown as the phone was handed around.

Even if "reasonable suspicion" data is recovered from it such that accomplices might be implicated, how could the FBI (or anyone else) now, with possibly contaminated data, legally go after those "accomplices" with valid search or arrest warrants?

I ain't no lawyer, but I suspect if it comes to a trial of these "accomplices," the first thing I'd try to do is impeach the possibly false data on which the warrants were obtained in the first place.

Thus, carrying this further, it struck me a while ago that, what with it being handed back and forth even without the supposed password change,  the data on the phone would be worthless anyhow.

No validated chain of custody, no evidence.

If that's the case, then it becomes apparent to me that the only valid reason for pursuing the lawsuit is so that the FBI can hopefully obtain a "universal" back door.

Terry

[Ben]

The other thing we haven't discussed: Was the guy really lame enough to do his planning on a work phone versus a throwaway?

[230RN]

^ Good point, although I don't think grocery store phones would have any encryption at all, so they went with the Apple marketing as to how secure their stuff was.

And I wonder why a county phone would need all that encryption protection anyhow.  What's the county trying to hide? :D

Unless Apple gave them a good discount?

(I remember Apple used to donate Apple 2es to high schools, which got them a solid foothold in the  computer market back then.)

More spec'lating from this suspicious old coot:

Presumably the county kept records of individual passwords.  This was a requirement where I used to work. So presumably  the county IT employee knew the original password, right?  Wouldn't he or she have had to have the original password to change it anyhow?  So why did this county employee change it?

Indeed, why?

What is his or her name?

Terry

[KD5NRH]

^ Good point, although I don't think grocery store phones would have any encryption at all, so they went with the Apple marketing as to how secure their stuff was.

FreedomPop $30 service with a free Kyocera Icon.  Load up Orbot for secure connectivity and APG for local and email encryption.

And of course, if there's anything useful on it, pitch it in the ocean right before the suicide mission.

[French G.]

The other thing we haven't discussed: Was the guy really lame enough to do his planning on a work phone versus a throwaway?

Was the world's richest golfer too effin' dumb to use a throwaway phone when screwing around on his wife?

Never bet against the house or human stupidity.

[dogmush]

Given that he and his wife did actually have a second set of iPhones, and they took the time to destroy not only the other phones, but their computer's hard drives as well before the attack I'm thinking he had at least thought about INFOSEC and there's nothing useful on this phone.

But that's kinda beside the point as far as forcing the unlock.

And I wonder why a county phone would need all that encryption protection anyhow.

It's built in to all iPhones these days.

[MikeB]

The plot thickens. And once again, the government shows incompetence and then wants to take actions that can or could limit rights by citizens as the recourse to their screw ups.

Looks like the FBI told the Health Department to change the iCloud Password. Any competent IT person should have known that was not the best option at that time. If you want to do forensics on Computers, you never ever make changes without considering all the potential implications. If they had taken their time they would have realized that was not the best first option.

https://www.washingtonpost.com/world/national-security/fbi-asked-san-bernardino-to-reset-the-password-for-shooters-phone-backup/2016/02/20/21fe9684-d800-11e5-be55-2cc3c1e4b76b_story.html

[Ben]

But that's kinda beside the point as far as forcing the unlock.

No argument there. It actually reinforces the point, given that there is little chance of finding useful information on the county phone.

[Angel Eyes]

http://www.zdziarski.com/blog/?p=5645

[230RN]

No argument there. It actually reinforces the point, given that there is little chance of finding useful information on the county phone.

Well, that's what I was getting at.  Seems logical (in Terry's "logic") that there could not be anything useful on the phone.

Things pointed out after my post, i.e., that they destroyed their computers, confirm Terry's "logic."

Pursuing the implications of that, the only reason for the Feds to put the screws to Apple is to force Apple to provide a back door (or methodology to break into secure systems) for them to use in future on anybody.

Which seems to go beyond any reasonable search and seizure, at least to this native English speaker:

The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized.

Terry, 230RN

[RoadKingLarry]

Never let a crisis go to waste.

[230RN]

^ Especially when you've created them in the first place.

http://www.zdziarski.com/blog/?p=5645

In that article, I find: "Should Apple comply in providing a tool, it will inevitably end up abused and in the wrong hands."

[230RN]

Double post