Hacker News new | past | comments | ask | show | jobs | submit login

Why would they have made the Secure Enclave allow updates on a locked device without wiping the key in the first place? Either they didn't think it through, assumed they would never be compelled to use it as a backdoor, or perhaps they were afraid some bug could end up having catastrophic consequences of locking a billion people out of their phones with no way to fix it? Do we even know for certain that the Secure Enclave on the 6s can be reflashed on a locked phone without wiping the key?



From what's been said, it seems like it was made to be updated so that Apple could easily issue security updates. They've already increased the delay between repeated attempts at password entry. Probably they were worried about vulnerabilities or bugs that hadn't been found and wanted to maintain debugging connections to make repairs easier. A tamper-resistant self-destruct mechanism with no possibility of recovery introduces extra points of failure, and it seems that until now, they didn't think it was necessary.

Look at the controversy over the phone not booting with third-party fingerprint reader repairs as an example. People were upset when they found out that having their device worked on could make it unbootable, but Apple was able to easily fix it with a software update. If it had been designed more securely, it might have wiped data when it detected unauthorized modifications, which would have meant even more upset people. Now that this has become a public debate, there will be a very different response to making it more secure.


How much easier? If all they had to do to not have access to it themselves is to ask the user for his password when there's a new update, that's hardly that inconvenient...


I'm not saying that it was the right thing to do in hindsight, but I get a little nervous even when updating a small web server, so I understand the tendency to leave repair options open on something as big as iPhones. Real hardware-based security is about more than just about asking for a password. It means making the device unreadable if it's been disassembled or tampered with, and that could have unintended side-effects if any mistakes are made or something is overlooked. It's definitely worth pursuing considering the political situation the world is in right now.


As I understand it, Secure Enclave firmware is just a signed blob of code on main flash storage that's updated along with the rest of iOS, which can be done via DFU without pin entry. I assume DFU updates are very low level, with no knowledge of the Secure Enclave or ability to prompt the user to enter their pin.

Making the DFU update path more complex increases the risk of bugs and thus the risk of permanently bricking phones.

You could imagine an alternative where on boot the Secure Enclave runs some code from ROM which checks that a hash of the SE firmware matches a previously signed hash, which is only updated by the Secure Enclave if the user entered their pin during the update. If it doesn't match, either wipe the device or don't boot until the previous firmware is restored.

This way Secure Enclave firmware updates and updates via DFU are still possible, but not together without wiping the device.


Let us direct our attention to the superhero Mike Ash and his latest post on secure enclave. https://www.mikeash.com/pyblog/friday-qa-2016-02-19-what-is-...

Honestly, this is really the shit..


Yeah, the key question is how Secure Enclave firmware updates work, and whether they can be prevented without pin entry. One former Apple security engineer thinks they are not subject to pin entry: https://twitter.com/JohnHedge/status/699892550832762880


> or perhaps they were afraid some bug could end up having catastrophic consequences of locking a billion people out of their phones with no way to fix it?

That basically happened (at a smaller scale) just last week. When Apple apologized and fixed the "can't use iPhone if it's been repaired by a 3rd party" thing, the fix required updating phones which were otherwise bricked. It's not an unreasonable scenario.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: