That's true, but a bit off topic.

The question here is whether or not the law says the DoJ can compel Apple to hand over these items.

We do not need to allow the DoJ to win in order to get to a point where Apple and others provide us with self-controlled data security. We can both fight the DoJ's position and demand better security from Apple.

Let's focus on the DoJ for now because that is the immediate threat.

This case should be discussed in Congress, not the courts, and the American people should have a say in the matter.

I was heartened to see the video of Senator Lindsey Graham's questioning of US Attorney General Loretta Lynch today on this topic [1]. His delivery and conclusion was perfect. Mike Lee also did a good job [2]. Feinstein was scary to watch (51:00 in the C-Span full video).

[1] https://www.youtube.com/watch?v=uk4hYAwCdhU

[2] https://www.youtube.com/watch?v=XOZLEhTlr6E

[3] http://www.c-span.org/video/?406201-1/attorney-general-loret...

Good videos. Graham summed up a lot of the layman's evolving thoughts on the topic. The first days of the PR war had the FBI winning, but their hubris caused them to underestimate Apple's PR machine. As the public learned more about the case, they have definitely turned against the FBI. It also helps that Apple is on the right side of this issue, but thinking about the (children|terrorists|guns|drugs|boogyman) has unfortunately worked before in similar situations.

Pretty sure Lavabit tried to fight this exact same type of ruling, and lost: https://en.wikipedia.org/wiki/Lavabit

While i'm not a legal expert, it seems the major difference is the size and name recognition of the companies.

Yes, and it makes a hell of difference in lobbying fire power.

I'm not really a Apple fan but I hope they win on this.

Lavabit eventually decided to close instead of giving access to the data of their customers. Apple won't close but I wonder if they would go as far as leaving the USA, both the country and the market. That would be more than extreme but if they lose it would be the only alternative to caving in. My very safe bet: it's not going to happen (leaving the USA).

I'm not sure if that would really work, with extradition agreements and all. A lot of other countries' governments will actually agree with the FBI's position, not the position of the American people.

In other news, Apple has been complying all along with Chinese authority requests, including placing Chinese user data on Chinese servers and hand over relevant data when asked. In China if they made a fit over this they'd be thrown out and blocked along with Google and Facebook. For them, complying with Chinese authorities is a revenue-driven business decision.

In the absolute worst case outcome of the FBI case, I imagine they would end up complying with US authorities as well, as a business decision.

For some smaller countries, providing the right privacy-friendly legal protections could be used to attract large multi-nationals.

Iceland is already poised to take advantage of this. A little bit of legislation, a few moderate tax breaks, and they could court Apple rebasing their corporate home, at least mostly on paper, there.

Apple could take the Galt Gulch option: buy a small country and move there where there sre no extradition treaties to bother with.

I always wonder how hard it would be and just how effective it would be if it was done.

Sovereignty is a funny topic... If Apple "buys" a country with a land border the "abdication of existing government" could be considered by their neighbours over the border as grounds to consider the territory "vacant" ... If Apple "bought" an island nation or a country comprising multiple islands, then they would have to "defend" their new home from the newfound "enemy" of the USA ( and I hear the Navy is quite formidable ;-) ) who might be a little bit pissed off, or may just decide like to "consider" that Apple purchasing the country makes it not a country and they don't have to listen to Apple when they ask nicely not to enter their territory with aircraft carriers, or say ... submarines that tap into undersea cables...

Right now Apple has a fair amount of protection by virtue of being an American company, an American company that is also considered an American person with rights under the constitution, such as not being "compelled to speak", which is why we're hearing about this sort of possible change in tactics. The FBI can't force them to talk so they ask for the script so they can talk for them.

If you don't have either (a) a competent military of your own, or (b) countries which have strong enough economic or cultural relations with you to want to protect your interests with their military, it is meaningless to form a micronation for the purpose of evading a large country's laws. The US or any other army could just invade, capture, or colonize your little country, which is pretty much how the world has worked throughout history.

Furthermore, without good relations with other nations, you're not going to get very far with exports, internet connections, food, passenger transport, investment, and just about everything else you need to sustain basic life and business.

What you describe is already how the iPhone works. The FBI has vaguely threatened to seek the signing key (not any master encryption key, which doesn't exist) so they can make an operating system that disables software-imposed wipe-on-10-incorrect-attempts and software-imposed-delay-ramp-up, so they can run a brute-force attack. If the phone had used a long passcode, this would be impossible. The only reason this is even a case is because this phone has a numeric passcode, which is within the reach of brute forcing with these UI barriers removed.

The mathematics already impose an 80ms duration ("delay") of each attempt. The FBI knows there is no way around that.

Contrary to other replies, even phones without the secure enclave are protected in this way.

That is in fact how iPhones' encryption works, except the vast majority of users don't set a high-entropy passphrase [1] because a) it's not enabled by default (because of (b) and (c)), b) it's not great user experience, and c) most people don't understand or care.

This is why Apple also implemented the brute forcing protections that the FBI is trying to bypass via a firmware update.

However, I do think that it should be impossible to update the firmware (including via DFU) without either a) the passcode, or b) wiping the phone. If the owner doesn't know their passcode they'll need to wipe the phone anyway. Anyone else doesn't have any business updating the owner's firmware without their permission.

[1] https://support.apple.com/en-us/HT204060 "Change your passcode. Enter a new, six-digit passcode. Or tap Passcode Options to switch to a four-digit numeric code, a custom numeric code, or a custom alphanumeric code"

You've pretty much described the secure enclave already included in newer iPhone models.

They are probably looking for the code signing key, not a data encryption key.

The problem is, with the code signing key, they can load a new modified OS, brute force the password and get at the data because the data isn't mathematically secure to begin with.

iPhone data shouldn't be encrypted on the basis of a 4-digit PIN. It should have a much longer password that's entered at startup. The 4-digit PIN can be a "screen lock" to prevent casual friends grabbing your phone and swiping pictures but shouldn't be the thing that encrypts your data. There isn't enough entropy in a 4-digit PIN, period.

The iPhone then adds a feature to self-destruct after N attempts. This is where a modified OS comes in. This isn't true security. Get rid of the self-destruct feature and you have brute forcing ability and can decrypt the data in minutes.

In a truly secure system, I would be able to safely just give you an image of the flash storage and all the signing keys. You pick your tools, OS, hardware, and you would still have no shot at decryption, at least not with classical computers and as long as P!=NP.

On the most recent iPhone, data isn't encrypted based on a 4 digit PIN. It uses a tremendously long piece of data as the encryption key, but the encryption key is only accessible through some special hardware they have (which is essentially tamper proof and brute-force proof) with the 4 digit PIN. But as you said, since they can remotely update the software for this special piece of hardware, it is still susceptible to being compromised.

A lot of the conversation happening in regards to this FBI case is only due to it being an older iPhone that doesn't have this special hardware. Which is why people are confused with the FBI chose this case as their poster child when it would have made a lot more sense with the most recent iPhone.

What's the "tremendously long piece of data as the encryption key"? Are you refering to the 6 digit code?

No, they're referring to the 256-bit AES keys in the CPU and Secure Enclave, which are entangled with the user PIN to derive the crypto key.

Would you explain how 256-bit AES keys CPU and Secure Enclave and user PIN all work together to provide encryption on the iPhone? Is this documented anywhere?

Is this same method employed across different generations of iPhones?

Thanks

Apple's description is here https://www.apple.com/business/docs/iOS_Security_Guide.pdf, and you can find varying quality of discussion in the media by searching for Secure Enclave.

Basically, the Secure Enclave contains a 256-bit AES key physically fused into the silicon during the chip fabrication process. Apple don't know this key, and neither do the manufacturers. It's different on every iPhone. The key cannot be read by any software, or the OS, or even firmware. All that can be seen is the result of using it in a crypto operation.

The key used for actual encryption on iOS is derived by taking an intermediate key derived from the PIN, and then entangling it with the Secure Enclave key (and, I believe, the CPU's key, which is also unique and fused into the hardware, but not quite so secretive). This effectively ties the crypto process to the phone - if you take a data dump of storage and try to brute force it on some more powerful kit, cracking the PIN isn't enough. You'll also have to crack both the AES keys.

This isn't universal across all iPhones - I think the 5S onwards have it.

Awesome. Thank you! I'm guessing Android doesn't have anything like this being that there's no single chip SoC design across Android phones.

> iPhone data shouldn't be encrypted on the basis of a 4-digit PIN. It should have a much longer password that's entered at startup.

As the iOS security documentation details, iOS uses a KDF to generate secure keys rather than just relying on a short PIN.

> The 4-digit PIN can be a "screen lock" to prevent casual friends grabbing your phone and swiping pictures but shouldn't be the thing that encrypts your data.

Photos ARE your data. You either require a full passphrase 100% of the time, or as Apple has done, only allow limited attempts with a PIN. Yes, they* could enforce a passphrase at all times, but this might make iOS less user friendly and drive regular consumers to less secure devices.

* A user can choose to always require a full passphrase/TouchID at all times. I don't use a short PIN on my iPhone.

Disagree - I want to be able to have my phone "casually" locked (when it's on) and "securely" locked (when it's off). If the casual lock is harder to break, that's icing on the cake, but the important thing is that I can quickly prevent access to the phone, and that it will revert to that state automatically after some time.

Ideally my phone would go into "secure" locking mode (requiring my 7 word passphrase) after not being unlocked "casually" for more than X hours.

If the user has to enter the code by hand, it's very impractical to require more than a memorizable number of symbols for the initial decryption code, unfortunately. Plenty of users turn off their phones periodically.

iPhones don't require a four-digit PIN. You can set a nice, long passphrase, which would then make brute forcing completely impossible even with modified OS shenanigans.

The only reason brute forcing is even potentially an option in this case is because the person in question didn't bother to use a secure passphrase.

So, it sure sounds to me like iOS is already doing what you describe. Do you just object to giving the user an insecure option?

Can someone explain how the encryption works on the iPhone? I was under the impression that the 4 digit code is just a screen lock and had nothing to do with the encryption.

Also is there a reason they can't just use this piece of hardware to brute force the phone?

https://www.intego.com/mac-security-blog/iphone-pin-pass-cod...

Lots of info here:

https://www.apple.com/business/docs/iOS_Security_Guide.pdf

The short version is that your passcode (whether four digits, six digits, or a full password) is combined with an encryption key embedded in the device in a way that's supposed to be impossible to extract, and used to derive the encryption key used to protect your data.

The device you linked to relies on a vulnerability in the US, where it would report that a passcode entry failed before recording that failure to nonvolatile storage. Normally, the device starts adding more and more delays to passcode entry after a few failures. By cutting power to the device immediately after it reported failure, it bypasses those escalating delays. As your link mentions, Apple fixed this vulnerability in a subsequent OS update, so that hardware only works on older OSes. This phone's OS is too new.

Thanks for the clarification. Does anyone know how Android's crypto at rest compares to iOS?

I'm not an expert on such things, but I believe people have been saying that the newer iPhones are more or less impossible to do this kind of thing for. The iPhone in question is old enough that it doesn't have the new security features apparently.

Yes, and more-recent iOS devices have stronger security features than the one in question here. Regardless of the outcome of this case, I expect that trend to continue as a result.