Hacker News Reader

Comment by saurik | Hacker News Reader

Your analogy to me falls extremely flat given that in this situation you own the iPhone in question and are just asking for the right to put arbitrary software... on your own phone.

(My comment is now at -1. I challenge anyone considering to downvote this response to actually answer how asking for the right to modify the software on the one phone in your possession--the one whose security features, if you really want to insist that this is about a security feature, only affects you--is even remotely comparable in an honest setting to "go[ing] to Google or Facebook and ask[ing] them to, say, turn off some key security features on their site".)

View on HN

This has been my biggest complaint about the iPhone from the very beginning of the app store and remains my primary reservation about committing to Apple devices to this day.

Thankfully the UX on Android has caught up to the point where it's as good as or even better, in some respects, than iOS. At least for my purposes, anyway.

I didn't down-vote, and don't know enough of this field to be sure, but I think there's an edge case that can affect other users: opening any door a bit may make it easier to retrieve keys that allows hackers to break into other phones.

For example, if they open the secure enclave so that security researchers can see in full detail how it works, that may expose some master key.

Countermeasure would be to have separate keys, ideally for each such phone, but having them for only this class of phones might be sufficient, too, if they also restrict access to this class of phones. I think that's technically easy, but may be expensive, process wise.

A system designed like that is flawed and insecure, and someone else with more resources--probably someone much more evil, sadly--is going to have figured out a way to get to that key... we should want to air that to the light of day and get that fixed.

I mean, at some level your comment turns into "we should try to hide the security flaws we have as much as possible, even from the people who are actively trying to help the world be more secure"... if you aren't serious about finding bugs, why bother with security?

I don't understand that logic. Apple built a safe. If I want to check that it is secure, it would be helpful if they built one from glass, so that I can see how the mechanism works, and thus verify the design. My argument is that that may expose a secret stored in that safe that then can be used to break into 'real' safes.

Your argument seems (to me) to be there should be no secrets on that phone that make attackers any the wiser (might well be possible, given the existence of asymmetric encryption). If so, why did Apple go to the effort to add the secure enclave?

The goal of the secure enclave is to protect your information (the signature of your fingerprint, the encryption key of your flash memory, etc.) from people who want to steal your device and access that information without your passcode by decapping the chip and reading its content. It is not there to protect some kind of global security key from Apple (we live in a world with public/private key cryptography... there's almost no reason why some key would exist on the device that is somehow critical to its security, and if it did exist it would mean a complete security failure).

Saurik is correct about security through obscurity not really being helpful, but for what it is worth, this:

> Countermeasure would be to have separate keys, ideally for each such phone, but having them for only this class of phones might be sufficient, too, if they also restrict access to this class of phones. I think that's technically easy, but may be expensive, process wise.

...is already something Apple does with the special development devices. Different keys and certificates used, probably to allow easier access for engineers while tightly monitoring and auditing production infrastructure.

You own an iPhone designed to work in a specific way. You don't need Apple's permission to put arbitrary software on your own phone.

You can just do it! If you can figure out how and don't mind maybe breaking your iPhone.

Apple doesn't sell infinitely customizable devices. Anyone who buys an iPhone knows this going in or is being intentionally obtuse. The idea that it's my phone I should be able to do anything I want with it is completely antithetical to the brand Apple has built over the last 40 years.

I am not certain what conversation you think you are joining, but this is one about "people invited by Apple to take part in a bug bounty program--one with an in-person onboarding process and which involved a meeting with Apple's security team, all expenses paid, in Cupertino--with the stated goal of working together to improve the security of the device have asked to be given the ability to modify the software on a limited number of test devices to aid in their security research". Your response is trying to tackle the general argument for arbitrary customers. I still think you are wrong, but that isn't the argument today.

Here's the concern I have, if you're able to "unlock" a single device, how do you do it where it's useful to the researcher, but can't be done to an unsuspecting 3rd party's phone?

The only way I can think of that doesn't have an endless array of problematic edge cases is for Apple to have a "researcher edition" of the phone, but even that isn't problem free.

Thoughts?

Apple already solves this problem by way of their TSS update server: they can whitelist specific ECIDs to be able to sign and install developer customized firmwares. What the argument was was "if we sign on to your program, can you add us to your whitelist?".

The only issue I can come up with would be "what if a researcher who was registered with and known to Apple gave their phone to someone else as a fake gift to spy on them". If you really want to go there we could argue it, but it seems a little far fetched in terms of "amount of damage that can be done via this route that couldn't be done via other ones".

> The only issue I can come up with would be ....

If it's locked to specific hardware, then no, I definitely wouldn't argue the edge case scenario you mentioned.

Apple has DEV-fused devices which use separate development certificates and keys.

The bootloaders and kernels for production devices still retain the code for the "special" functionality, that is how researchers are aware of it, but it simply will not work without an actual dev-fused device.

I agree with you here, you can get to other parts of the OS with this ability and will find different flaws. I would say that this comparable to an external penetration test vs a more formal internal practices and code review. Both are acceptable approaches finding different results.

Many of the phone’s security features don’t only benefit the user - they also make widespread piracy virtually impossible, and they ensure that nobody can set up a rival software ecosystem on Apple’s hardware.

Your comment agrees with my world view (and why I even pointed out that "if you really want to insist..."), but comes across as an attempt to answer my question or refute my point, so I will then respond by saying "and giving a handful of security researchers the ability to run arbitrary software doesn't lead to rampant piracy" (but you know what does? the "free developer" tier added by the Swift team ;P).

Reply on news.ycombinator.com