Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I agree. I was under the impression that Apple's security was such that even they didn't have the power to decrypt a device because the crypto made it impossible without the password/pin/key. I'm interested to understand the reasons that it was not done this way.


The current implementation is done this way indeed: even Apple cannot decrypt without using the right password.

The right password can be obtained by either knowing it, or by guessing it.

As an additional security measure, the software shipped with the phone prevents brute force attacks by wiping the device after a given number of failed attempts.

Apple has been asked to modify the software so that it won't wipe the phone, thus allowing the authorities to try many passwords.

If anybody could circumvent this additional security measure, actual security would be lower. The authorities are not asking Apple to ship this change to all users: they only want to install it on the device in their possession.

However, Apple is concerned that once they provide the authorities such a modified software, it could be leaked and thus be used by third parties to breach the security of any Apple device.

It should be noted that currently all data encrypted for example on your laptop's hard drive is already subject to this kind of brute force attacks. It's a well known fact that authorities or malicious users can already attempt brute force attacks on encrypted data if they can access the data on a passive device such as a hard-drive.

It's important to understand that Apple (at least not in this case) is not being asked to implement a backdoor in the encryption software. It's also important to understand that even if Apple was forced to install a backdoor, it would affect only the ability to access future data and not help the investigation of the San Bernardino case.

This very request by the Authorities suggests that Apple does not currently install any backdoor on stock phones.

However there is a logical possibility that the Authorities are either not aware of any such backdoor or in the worst case they are publicly requesting this feature just to hide the real reason of a possible future success at decrypting the phone: they can claim that Apple didn't have any backdoor, and they were just lucky at bruteforcing the device; in fact Apple wasn't even cooperating with them at relaxing the brute force prevention limit, so they could claim they did it in house.

(I'm personally not inclined to believe in such improbably well coordinated smoke and mirrors strategies, but they are a logical possibility nevertheless).


Why doesn't the FBI simply clone the current device, make brute force attempts and then clone again if locked out? Yes, lots of work but also doesn't force Apple to participate.


I thought @csoghoian's take was interesting. The FBI doesn't want one specific phone unlocked, they want precedent.

https://twitter.com/csoghoian/status/699841360963108864


The iPhone uses AES encryption which would prevent cloning the flash storage [1]. There was an informative discussion of this over on AppleInsider - http://forums.appleinsider.com/discussion/191851

[1] http://www.darthnull.org/2014/10/06/ios-encryption


from that discussion, super informative details on how secure enclave is actually implemented:

http://forums.appleinsider.com/discussion/comment/2832533/#C...


Would it be infeasible to construct part of the private key out of hardware-specific id's + time-of-creation hashes? I assume it's not only the PIN?


That's what the A7 (iPhone 5S and later) design does:

“Each Secure Enclave is provisioned during fabrication with its own UID (Unique ID) that is not accessible to other parts of the system and is not known to Apple. When the device starts up, an ephemeral key is created, entangled with its UID, and used to encrypt the Secure Enclave’s portion of the device’s memory space. Additionally, data that is saved to the file system by the Secure Enclave is encrypted with a key entangled with the UID and an anti-replay counter.”

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

The device in question is an iPhone 5C, which uses the older A6 design.


Thanks for the link! I knew there had to be more technical information out there but couldn't find it on an initial search.


Yeah, it wasn't exactly unknown before but it wasn't terribly common outside of certain security / compliance circles. I think I've seen more links today than in the previous year.


Each device has a device-specific AES key (UID) burned into it such that you cannot clone devices (or move flash chips between them).

Everything is encrypted with a derivative of this UID, and extracting the UID is not a thing you can do without destroying the device.


I'm really curious as I have been hearing this many times.

"even Apple cannot decrypt without using the right password."

Could you please explain?


You can read more about it in this well written article: https://www.mikeash.com/pyblog/friday-qa-2016-02-19-what-is-...


It sounds like it has been built that way - the data cannot be decrypted without the correct passphrase - but the user secured the phone with a 4-digit PIN, giving a mere 10,000 possible combinations - easily brute-forceable.

The iPhone prevents this by locking up (and potentially erasing the phone) after 10 failed attempts, but this a restriction created in iOS. If they provision a new backdoored version of iOS to the phone, that restriction wouldn't apply any more, and they could brute-force away.


To clarify, on A6 and earlier this is enforced in software. On A7 and later this is enforced in hardware.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: