Hacker News Reader

Comment by rhino369 | Hacker News Reader

I totally agree the US government shouldn't compel anyone to weaken security generally. So Apple shouldn't be forced to build in a backdoor into products that are released for sale.

But this apple request is just exploiting a weakness that already exists. And it would only be doing it on a single phone. And it would be do it pursuant to a legal order by a US court.

Also, the US government only has zero credibility in the minds of hardcore activists or extremists. The bulk of the America public trust the FBI to investigate ISIS.

View on HN

I agree - this is the type of vulnerability that, assuming Apple is extremely careful about protecting their signing key, is only exploitable by court order or similar state request. This crypto implementation on iPhones and the like isn't really designed to protect against that, it's really more to prevent the common criminal from accessing your personal data. Apple already comply with law enforcement requests to access iCloud backups and other such data, so assisting with this passcode crack isn't really much of a stretch.

> I agree - this is the type of vulnerability that, assuming Apple is extremely careful about protecting their signing key, is only exploitable by court order or similar state request.

Apple has been trying to prevent jailbreaking for years - they've always failed, so I'm skeptical about this "only exploitable by court order" bit. Determined people will find ways around the protections. Heck, it is even possible that someone (think nation-states) has already found a way to circumvent the passcode lock. This will only lower the barrier of entry.

Jailbreaks address a different type of vulnerability - that of incorrectly written code or poorly designed systems, that can lead to a privilege escalation.

The vulnerability that the FBI are using is the ability of Apple to update the iPhone with arbitrary code, provided it has been signed with their secret key. It's an important feature, of course, but still a security vulnerability - albeit an irrelevant one for the vast majority of iPhone users.

The most important bit is that Apple can (and in fact, was asked to) make the change only work on a single phone. As in, there is no fear of it "falling into the wrong hands" as the FUD goes. If you believe in the security of cryptography, then you believe they can make this change cryptographically device locked.

Then once that happens: they have both precedent and legal case law on their side to compel Apple, or Microsoft, or Cisco, or Google, etc. to do the same for another secure product.

> Then once that happens: they have both precedent and legal case law

"Precedent" and "case law" are the same thing (and "legal case law" is just a silly construction), so it doesn't really add anything to say you have both of those, instead of one or the other.

All this case law talk is irrelevant. If Apple actually just voluntarily did this one time it wouldn't really set a legal precedent. Fighting it will probably set a legal precedent. And they are doing it on a case that maximizes the FBI's argument that this is needed for national security.

But sure, Apple will end up having to do this for a lot of phones the FBI has. But why is that a problem?

> And it would only be doing it on a single phone.

No, it would not. New custom software has to be developed. Software that can then fall into the wrong hands, from crooks with stolen phones, to nation states.

Seriously, it boggles the mind that they are asking for the security to be weakened, because terrorists. But they are not concerned that said terrorists will then be able to use the same software to crack their phones. Or Russia, or China. Maybe they are counting on the fact that it (for now) requires physical access?

>No, it would not. New custom software has to be developed. Software that can then fall into the wrong hands, from crooks with stolen phones, to nation states.

Only if Apple stupidly wrote a generic firmware that could run on any iPhone and then lost it. That risk is essentially zero.

If Apple reasonably complied with the order, it would be as dangerous as any other Apple update, which is to say not dangerous at all.

>Seriously, it boggles the mind that they are asking for the security to be weakened, because terrorists.

In this case, there is no weakening.

> Only if Apple stupidly wrote a generic firmware that could run on any iPhone and then lost it. That risk is essentially zero.

The updates they write now are generic and run on any iPhone. So theoretically any new code, by default, would be as well. They may not even have a way to limit firmware to specific devices without many man hours more of work on top of creating the modifications already being requested.

> They may not even have a way to limit firmware to specific devices

They do. The new firmware may not be distributed, but it should be easy enough to make it such that if it was distributed, it wouldn't change security at all on phones other than the target.

For example:

    function handleWrongPassword() {
      if (deviceId = 1234) {
        return;
      }
      //do the normal phone stuff, like a delay or wipe
    }

Since the firmware is signed, no phone will run the firmware if you change the hard coded 1234.

> if (deviceId = 1234) {

... Is that a backdoor within a backdoor? :)

I don't know what you mean... but it's pseudocode for what the FBI asked Apple to do. It's a backdoor that only applies to a single device. Since it must by signed by Apple, it can't itself be backdoored by the FBI or a hacker or anyone else without Apple's consent.

Edit: oh, I see what you mean. The single =. But it's pseudocode. That happens to look a lot like Javascript with a bug :)

Reply on news.ycombinator.com