Apple CEO: http://www.apple.com/customer-letter/

FBI: https://www.lawfareblog.com/we-could-not-look-survivors-eye-if-we-did-not-follow-lead

Twitter CEO: https://twitter.com/jack/status/700457149227360256

Google CEO: https://storify.com/cmgnationalnews/google-ceo-supports-apple-in-fight-over-federal-co

Microsoft CEO indirectly (Retweeted the MS CLO): https://twitter.com/BradSmi/status/700156393794351104

I'm not sure how this couldn't set a precedent. "We want this now, but don't worry, we won't ask for it again."

Besides, aren't there still other avenues they can try? I thought I saw one report that Apple could increase the guy's iCloud storage limit, which might start the backups going again. I don't think I'd have a problem with that. I assume I don't understand that situation properly though.

The FBI and the San Bernardino County changed the Apple ID/iCloud account password. There's a possible way they did this by using the iForgot support site and had access to the e-mail account tied to the account. Being that this phone was the property of San Bernardino County, it could have been his work e-mail address. The password reset that the two government agencies performed means the phone no longer can backup to iCloud, assuming that setting was still on. Being that they had success changing the password it indicates the account was not set up for two step verification. Or if it was, the government agencies involved reactivated the phone number on another device to receive the SMS with the verification code. They could have been attempting this path to gain access at http://icloud.com

If San Bernardino had the device under MDM control, they could flip that setting on, however they couldn't send the new password in via that path.

Since the FBI thinks that Apple can decrypt the phone, why don't they just give the phone to Apple, let Apple do whatever magic it is they do, then put just the data on a flash drive and give that to the FBI? If the FBI wants the phone back, then let Apple re-install the stock iOS on it and return it.

tanstaafl.

The reason your idea won't fly with Apple is because Apple wants to project the idea that your data is safe from anyone on their products, even from Apple. I'm sure this is a concern for some people while they post every detail of their life on Facebook they still want to be private.

I have mixed feelings about this. Especially since it looks to be a work phone. Most companies spell it out very clearly that any thing you do on their owned equipment is subject to their monitoring and is their data. So really the owner of the phone just wants their data.

The FBI is asking Apple to create a new instrument (in legal terms) to restore the ability to extract some data like what was possible from iOS 4 - iOS 7.

iOS 8 and above encrypt everything user created with the passcode entangled with the device UID, thus this instrument would be different then the past one. It would have to crack encryption too since the passcode is never sent to Apple.

Previous extraction was possible because that data wasn't encrypted by using the passcode, instead it only used the UID known to Apple at point of manufacturing. The previous instrument had no encryption breaking capabilities, it simply opened what was accessible with a known to Apple key unique to each phone. *edit* My explanation here is a bit off on the technical details, will add some diagrams that help explain the iOS 7 to iOS 8 changes easier then with words.

Specifically the FBI is asking Apple to create an instrument that defeats the following protections:

• Disable the Apple programmed time delays between passcode entry attempts
• Enable a way to attempt passcode entry over a USB, WiFi, Bluetooth or Cellular connection instead of direct touch screen entry.
• Disable the user/owner facing setting that wipes user data after 10 failed passcode entries, a setting that the terrorist or San Bernardino County may have turned on

Forgot MDM can also pop the passcode lock if needed. Seems San Bernardino County was paying $4 a month for some MDM solution, but never got around to ensuring it was on this particular iPhone they owned and handed over to their terrorist employee. Oops.

http://www.cbsnews.com/news/common-software-would-have-unlocked-san-bernardino-shooters-iphone/

I've blogged about this (broad summary, helpful analogy).

It's interesting to see how the employer and the FBI totally blew it with the whole MDM thing. Like, they should have been able to do this, but they screwed up, so now they're using that as a basis to go after something they've really wanted for a much longer time: a deep legal precedent.

The challenge, so far as I can tell, is trying to come up with a compelling way to even explain what the tech people are so upset about. The FBI's public statements are, needless to say, entirely one-sided on this.

Suspects are already dead, no?

Yeah, yeah. I was working to get that out fast, not necessary fully debugged. The real thing the FBI is presumably after is any accomplices.

Zdziarski gives it a try, expanding an analogy Bill Gates used. : http://www.zdziarski.com/blog/?p=5714

Also speaks to a $200 device that could crack 4 digit pass codes and a flaw not closed till iOS 8.1.1. The widening use of it was a factor in iOS 9 recommending 6 digit defaults. The device exploited a flaw where incorrect attempts wouldn't be stored in flash quickly, allowing a power interruption to stop the auto wipe counter.

I'm confused about one of their answers. The question says "Has Apple unlocked iPhones for law enforcement in the past?", and their answer is "no", but then they go on to explain exactly how they have indeed done it in the past. Was it a typo and they meant to answer "yes" there?

This reply covers it a bit and links to the law enforcement document Apple referred to: http://empegbbs.com/ubbthreads.php/posts/366035

Apple is defining unlock in that question as "Has Apple broken encryption or brute forced a PIN for law enforcement in the past?". Apple is stating that no they never have.

Apple with every iOS and iPhone release has continued to protect data on the device to prevent extraction (of already decrypted data) via methods both they, and 3rd parties were employing.

If that's true, then how did they get data from phones for law enforcement in the past?

I believe I have a basic understanding of the technology here, so I understand Apple's position. But let me play devil's advocate for a moment so that I can make my issue with their answer on their Q&A page more clear.

The thing that people want to know with that question is, "What's the big deal? You've helped law enforcement crack into the data on phones before, so why is this different than what you already did before?"

For me, reading their Q&A page, it's just saying, "We have never cracked a phone for the fuzz, except all those times in the past when we did". They're not making the answer to that question clear.

Tom, what I think you're saying is:

They've never cracked the encryption on a phone or changed the OS to allow brute force attacks on the password before. In the past, the data on their phones wasn't actually protected very well, so they were able to retrieve the data for the fuzz without the need for those things.

If that's true, then that's what they should say on the Q&A page. But they're not coming right out and saying that in their answer. Probably because it makes one wonder about the chronology:

1. In the olden days, phones weren't secure or encrypted, so the fuzz could get whatever they wanted, right off the phone.

2. Recently, mfrs started securing phones, but they weren't actually very secure, and the fuzz could always enlist the mfr's help to get the data. Apple always complied in those cases.

3. Very recently, Apple decided to really TRULY secure phones, and are now balking at the fuzz's request to crack it.

Looking at the chronology that way, I think this really cuts to the heart of the issue, which is: Back doors have always existed. Apple has recently closed one, and this time, they're drawing a line in the sand at that point. The question is, why is the line at #3 worse than the one at #2? I understand the difference from a technological point of view, but what about the general principle? Apple seemed happy to help the fuzz at #2.

Maybe they weren't happy at all, actually. It looks like the newest encryption features were a time bomb waiting to go off. And I think they knew it would come to this, even as they were developing the newest encryption features. It almost sounds like the development of the new encryption was a calculated passive-aggressive move on their part, a type of protest against the government requiring companies to reveal customer's data all along.

Maybe Apple thought that, after they created these new encryption features, that they could honestly answer the government with "nope, sorry, no way to crack it, not possible". And now the government got clever and said, "but wait, you can crack it *this* way", and Apple was like, "woops".

I wonder if the real heart of the issue here is that the "secure enclave" circuitry was mistakenly designed to place the retry-attempt-backoff-interval onus on the operating system rather than on the chip?

The secure enclave is not a factor with the iPhone 5c in the San Bernardino case. Only 64 bit iOS devices have the secure enclave portion of the SoC. The iPhone 5c was the last 32 bit iPhone Apple created. (Though the bitness of the CPU has nothing to do with the secure enclave, it's a convenient designation to know if it's there or not.)

So yes, for the iPhone 5c, only OS level software and the computational load limits retry attempts.

The 5s and above with the secure enclave may also be venerable to a method of bypassing delays somehow. It's unclear currently how in the discussion channels I've been following. The thought is that there is some sort of firmware upgrade path into the secure enclave that could be exploited.

Tony, I actually think there's a difference there, right in the general principle, rather than the technology.

In the past, precisely because data was not as well protected, Apple helped the authorities to retrieve data exploiting weaknesses in the system.

This time, they're being asked to weaken the system; to change it back to a previous, less secure state.

I think there's a significant different. One thing is to ask me to exploit weaknesses in my products, another thing is to force me to redesign them (worsen them).

The argument that this change will only affect this one phone is weak, also. FBI is already asking to use this same method on 12 more phones, and it could be used fraudulently on any other iPhone. Would I, as a consumer, consider an iPhone secure, at that point?

I've never been a fan of Apple, and while I think Apple products are great in many ways, unfortunately they have disappointed me more often than not. This case is winning me over to the iPhone, provided the Gov't does not force apple to break it.

Yeah. That is a really clear way of putting it. That's what the Q&A page should say.

Oh! Right! I was remembering that incorrectly. Good point.

This is a great interview. I just happen to agree on ALL Tim Cook said here.

http://www.theverge.com/2016/2/24/11110802/apple-tim-cook-full-interview-fbi-iphone-encryption

Apple's motion to vacate the order: https://www.documentcloud.org/documents/2722199-5-15-MJ-00451-SP-USA-v-Black-Lexus-IS300.html

Interesting article here:

http://www.nytimes.com/2016/02/25/techno...-cant-hack.html

It directly answers my earlier question, which was:


The answer, according to the article, was, they hadn't yet seen their security measures like that, but now are going to be working toward a day when they truly can't hack their own phones. My favorite quote from the article:

Very interesting way to put it.

Personally, the more I think about it, the more the "can of worms" argument gets relevant to me.

Once Apple is forced to write code as the Government wishes, for whatever reason, then it would have to constantly keep a shadow version of the code that complies with Government. Would this eventually be unsustainable, for technology or financial reasons? Would this eventually stop Apple from introducing new features that depend on encryption, or leverage some technology that would make it impossibile for the Government to break in?

I mean, this is so bad in so many ways.

I've been surprised by how much of the public has sided against Apple in this. I know that they have the more difficult side to explain (it's easy to say "the government needs this to stop terrorists"), but given how much affection the company has garnered over the past 15 years, I would expect them to have more people on their side. The numbers I've seen appear to hover around 50% of the public, however accurate that might be.

This is the sort of thing where polls can indicate quite differently depending on who is asking and what is asked. And whether the people being asked actually understand the issue.

Misunderstanding about precisely what Apple has actually been asked to do for the FBI also seems widespread.

Apple has been rather consistently portrayed by media, for years, as accidentally successful with imminent potential failure just around every turn. The contradictory and conflicted nature of how Apple is portrayed and perceived is itself worthy of study.

I agree. I've been looking at few videos these days, and many people just don't seem to know the issue at stake, let alone the implications. Questions such as "Should Apple help the FBI to crack a terrorist's iPhone" don't help at all.

Major decision out of New York that will hopefully help the case in California. http://techcrunch.com/2016/02/29/ny-judg...or-iphone-data/

Should also help quash other requests out of New York, where some parts of the government there were eager to see Apple lose to the DOJ in California.

Tony, I've still got a longer response I'll get to posting later in the week to respond to your questions elsewhere in the thread. Been keeping my limited free time focused on keeping up with the rapidly evolving situation.

Let me be clear that I'm on Apple's side here. I just had a problem with the wording of their qa page, and wondered if maybe this is a showdown they've been expecting.

Short answer, I believe yes based on watching the buildup to this for a while. It's part of the longer response I'm planning when I can give it the proper time to type it out. Including lightly touching on the technical aspects Apple has been building up that date back to the iPhone 3gs.