[mindslight]

> Apple doesn't want to do it to avoid setting a precedent

Unfortunately that's exactly what they're going to end up doing with this faux resistance. It seems like in this case there is a master key that only Apple has. If the device's security is broken in this manner, then this is a terrible place to make a stand, as Apple will have no choice but to eventually comply.

Next time, with an actually secure implementation, the stance will be "you protested last time and gave in, do that again". And when USG realizes Apple isn't bluffing that time, their bolstered entitlement will result in the inevitable law for Apple to go back to the backdoored nearly-just-as-secure scheme.

To the first order, USG doesn't care about the argument that foreign governments could also compel Apple, since that simply reduces to traditional physical jurisdiction. And governments seem to be more worried about protecting themselves from their own subjects than from other governments.

We can only hope that the resulting legal fallout is implemented in terms of the standard USG commercial proscriptions based on the power of default choices, leaving Free software to continue to be Free.

[themagician]

Apple doesn't have the master key. Apple can't create a master key. Apple can, if they are forced to, create a variant of their software (which doesn't exist today) that will allow the FBI to try all keys and hope that they find one that works.

Apple could be forced to write software that removes the rate limiter and the FBI could still be stuck without access because it's possible the user used a password with too much entropy.

[mindslight]

If this software variant can be installed on a locked device and post-facto modify its security model, then either that device was insecure or there is a master key.

[cmurf]

Disabling the bruteforce inhibiting code does not mean it was insecure or that there's a master key.

[mindslight]

It certainly means the bruteforce inhibiting was insecure.

[cmurf]

Explain.

Include in the explanation how removing code makes the prior state insecure.

[mindslight]

If an attacker can modify the code, they simply nullify that check (as we're discussing here). The prior state was insecure because the whole point of crypto/trusted hardware is to prevent against such attacks, and the prior state should have never allowed a code update on a locked device (if we're talking about trusted hardware).

If we're not talking about trusted hardware, then naive code which calls sleep() is defective for the same reason - the security of the system cannot depend on running "friendly" code. See Linux's LUKS which has a parameter for the number of hash iterations when unlocking, which sets the work factor for brute forcing.

If this still isn't apparent, you need to try thinking adversarially - what would you require to defeat various security properties of specific systems?

[venomsnake]

There is the most master of all keys - the one they sign the bootloader/os with.

[mindslight]

As long as anything like this exists, and can be used to flash a new system image while data remains intact, then Apple claiming they have a system secure against government is extremely negligent.

An OS signing key is never a replacement for a bona-fide user-initiated upgrade intent.

In designs with trusted hardware to prevent evil maid attacks, the boot trust chain should use a hash rather than a signature. This hash is updated only when the trusted chip is already unlocked.

To avoid creating useless bricks, said trusted hardware should allow the option to wipe everything simultaneously. But nothing more granular.