They are probably looking for the code signing key, not a data encryption key.
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.
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.
Is this same method employed across different generations of iPhones?
Thanks
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.
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.
Ideally my phone would go into "secure" locking mode (requiring my 7 word passphrase) after not being unlocked "casually" for more than X hours.
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?
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...
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.