Hacker News new | ask | show | jobs
by jonlucc 3768 days ago
It's true, but very narrow, I think. FBI means that Apple could sign the update to only work on that phone. Apple means that once the compromised version of the OS is built, the only thing stopping it from being widespread is changing the device id check code to other phones or taking it out entirely.
8 comments

Right. If you look at it from a security point of view, once the compromised OS is created you've created a much more valuable and vulnerable target for hacking.

Let's say that some attacker wants to create a compromised OS and install it on a certain device.

If apple never creates the compromised OS, they would need to hack into apple, get all of the source code necessary to build iOS, figure out how to build it, figure out how to modify it in the desired ways, how to get it installed on a phone, steal the crypto keys necessary to do the signing, and sign the bad build.

If apple has created the compromised OS, they would just need to hack into apple and get the compromised OS build, steal the crypto keys, and sign it.

The first scenario is a large-scale software engineering project. Anyone that's been given a large source dump will tell you that it's horrible and takes forever to do anything, and iOS is going to be absolutely huge and tricky. You'd need a large, highly trained team of security/OS devs, which is hard to come by and would be extremely expensive.

The second scenario could conceivably be done by a single hacker, if they can find vulnerabilities in apple's security.

Apple also has a huge firewall (in the figurative sense) right now in that it is a large amount of effort for them to create this new security-relaxed version of the OS, and the government can't be compelled to force them to produce it.

Now, let's say that they have written it for some reason, but it is restricted to a single device id. Well, it's now a lot easier for the government to compel Apple to hack another phone, because they can creditably argue that all Apple has to do is change some string constant and re-sign the package. The burden of work is now much, much less than if the tool itself doesn't already exist.

Apple doesn't want to ever create the tool. If they have to create it for any reason, even if it starts out being locked to a single device id, they've lost the war.

You while it makes things easier you don't need to have a source code to break protections.

Crackers broke copy protections for decades without having access to source code of protected games.

The only thing you would need is to have access to private key needed to sign the new code so that phone will accept it, but even that could be broken by hardware engineer.

Anyway the whole thing does not make much sense. Those shooters are already dead, they destroyed their private phones, this was a work phone, they already can access metadata (outgoing/incoming calls etc) from cell provider. FBI went public with this even though in their best interest would be to do it secretly. What does FBI expect in doing this publicly? Did they expect is to cheer for them and complain about evil Apple not helping to break evil terrorists' phone?

It doesn't make much sense... unless the real goal was to make people trust Apple more after Snowden's disclosures. Isn't interesting that Google, Facebook, Microsoft... every company which was previously involved in PRISM supporting Apple? Trusting them benefits both, the agencies and those corporations.

> Did they expect us to cheer for them and complain about evil Apple not helping to break evil terrorists' phone?

I think that is exactly what they expected. Terrorists and pedophiles are the best way for federal TLAs to expand their powers.

Except digital signing makes the compromised OS totally and utterly useless for other phones. Changing the OS would cause the signature check to fail.

And if you can get around the digital signage, you don't need the compromised OS.

Conway's technical interpretation of the Apple deliverables is right. There's a legal precedent which could cause reuse (and is rightly matter for debate/utter refusal of the FBI position), but if you just debate the technical merits Apple has been very misleading about the consequences.

For this one case you're right because the FBI will allow Apple to lock the special OS build to this device's ID. The problem is if the FBI can force Apple to create a special build to order, with features specified by the FBI, they can also be ordered by the FBI to create an OS build that isn't locked to one device. And if the FBI can make them do this, so can any law enforcement or government agency capable of finding an amenable judge, such as say the CIA, the DEA, the NSA, or any random public prosecutor. THAT is the problem.
Not to mention that once this is done in the US, what is to prevent other governments in countries where Apple does business to compel Apple to do the same?

China (or Russia or Germany or whoever) could force Apple to backdoor phones used by CIA informants in that country.

And the fact that who is to assure that Apple doesn't leave one or multiple bugs around that makes the compromised OS not so tied to a single device as they meant it to be?

It's a ticking bomb, man.

The FBI can't legally do any of that.
"Except digital signing makes the compromised OS totally and utterly useless for other phones."

This carries with it the assumption that the digital signing and verification mechanisms are infallible and impervious to attack. That is an unwise assumption. Even if a software system appears to be perfectly secure at a given time, it is reasonable to assume that at some point a vulnerability will be discovered.

> And if you can get around the digital signage, you don't need the compromised OS.

Not necessarily. Someone could get their hands on the signing keys or find a vulnerability in the signature verification without having the knowledge or resources to create something worth signing. Or figure out a way to bypass the check by changing something that isn't covered by the signature, or use something like rowhammer or hardware hacking to flip the bit from saying the check failed to saying the check passed, etc.

It is useful on other phones if someone figures out how to hack whatever mechanism is used to do the phone ID check. If that happens, suddenly this patch works vs all phones
> And if you can get around the digital signage, you don't need the compromised OS.

signing <> encrypting

Find?

Wait three weeks or three months for the FBI to request n copies of the evil thing, tailored to each of the n phones it wants to open. Better still, wait for a few others to make similar requests. Now penetrate or impersonate a law enforcement agency of your choice and send Apple a routine request for the n+1th copy, tailored to the phone of your choice.

> steal the crypto keys

Once you have done that, the other steps are easy.

That is an interesting assertion that you do not back up in any way. I don't know about you I don't see the other steps as anything like easy. And I've been doing this software thing for a while now so I think I some benefit from experience to draw on.
Every single version of the iOS kernel has been dumped. That gives you most [0] of what you need to craft a modified version. The largest barrier to running these modified versions is getting the target hardware to accept them as authentic. All public bootrom/iBoot exploits on the iPhone 3GS/4 patch the bootloaders' RSA authentication out in some form or another. There are no public bootrom exploits out for iPhone 4S+ devices.

Thus, having the signing key (or the power to compel signing at will) is an incredible ability privy only to Apple.

[0] Some Mach-O information is lost. Decryption of the imgX formatted kernel is preferable.

How hard do you think it is to sign software with keys you already have? Cracking software to avoid erasing the device and to support talking to the security hardware without a timeout... I don't even know what one would think is hard there.
Why do you say that the first scenario requires a large-scale software engineering effort? They don't want new features, or major changes to the crypto systems - just disable the function that causes the phone to lock for longer and longer times when wrong PIN codes are entered.

Comment out the function call. Change the number of allowed guesses to MAX_INT. Change the time increment to zero. Click build.

This is not a hard task!

That's a good point that I was assuming it would be difficult. I've since done a little bit of reading up on what we know about how difficult it would be.

This is the best writeup I found: http://blog.trailofbits.com/2016/02/17/apple-can-comply-with...

So, you'd need an update to iOS/the phone firmware, and for newer devices you'd also need an update to the secure enclave firmware. You can't do anything about the 80ms delay, because that's baked into the hashing function (and changing the hashing function would generate invalid results). The FBI is also asking for the ability to enter passcodes electronically rather than via the touchscreen, which would be new code.

If iOS and the SE firmware are really nicely factored to disable security, and it's not hard to add the new functionality, then this might not be too much work. However I doubt that that is going to be the case. The whole point of the security system is to make it difficult to crack, so there might be other countermeasures involved, tricky dependencies, and low-level hardware hackery. If it were simple to do, why wouldn't it have already been done by others reverse-engineering the compiled code? There is certainly financial motivation to do so.

> Click Build

I'm willing to bet iOS has a huge build infrastructure, many different components, and about a snowball's chance in hell of having a single nice clean Makefile for you to type one command to get a build without access to that infrastructure.

But the point is that Apple has that infrastructure. If the FBI asked the right person or people, I would bet they could get this done on their lunch break.

People are making it out like the FBI is asking Apple to rewrite a big part of iOS. That's not the part of the request that's the problem.

It depends on the source code you find: if you find a source code without comments or even worse an obfuscated code it would be a really really difficult task to modify it the right way.
But what it's really about is the legal precedent it would set, allowing the government to force companies to unlock devices for them.
It's not the unlocking that's the precedent. It's the door into "modify your source code in such and such a way."

Come to think of it, why aren't free market standard bearers rallying against this as government intrusion into market features?

The answer is they are and this is somewhat a litmus test for who stands behind free markets and those who don't despite what they often claim.

Example from organization supporting free markets. http://fee.org/articles/apple-defies-fbi/

And then there is no shortage of examples from the presidential candidates who claim to support free markets, yet none are standing behind Apple.

Because it isn't politically expedient for them to do so, as Apple is very very successful, and as such, most people (voters in this case) who are uninformed love the theater and cheap political pot shots lobbed at Apple. It's clear that there is no discussion at a national nor international level of the actual implications of what this means for not just Apple, but indeed for the American economy and software built in the US.

For instance, do you really think Microsoft will be able to sell Office software to the Netherlands Government if the DOJ/NSA/whoever can use the All-Writs Act to force Microsoft to implement a backdoor into their software? Would the NSA be able to use the AWA in conjunction with a NSL and a secret court to force the hand of companies? Politicians / the public don't really grasp what's at stake here. What we're really talking about creating a complete and real artificial handicap for all software companies located/based out of the US. Already there is pushback in China, Europe and Australia to ditch American-made software after the Snowden revelations. A ruling in favor of the FBI will only compound and accelerate this issue and will have a marked and measurable effect on the revenues of software and hardware companies located in the US.

While Google/Apple/Facebook/Microsoft/Cisco et al may not be able to relocate, this will definitely cause small and medium sized firms to relocate or possibly to never incorporate within the US to begin with. This may be effectively and preemptively scaring away the next Google. Law of unintended consequences and all that.

Cause most of them never were actually for the free market.

Also: Terrorism.

Correct. That's what I should have written.
"why aren't free market standard bearers rallying against this"

because it has nothing to do with the "free market".

Even worse than that, the precedent will be set that government agencies can ask any tech company to subvert their own security. So TVs, phones, echoes, webcams, computers, analytics.js could all legally be modified to become surveillance devices, and if doing one, why not do them all?
My question is: why hasn't the fbi gone after a smaller player to set this kind of precedent? One that wouldn't have had the huge legal resources to oppose the request that Apple has.

I think what's coming out of this is that the Fbi is riddled with incompetence and inability to face modern threats, plus a silly hybris that is the foundation for silly strategical mistakes.

Presumably because smaller players don't have such elaborate security. Those can always argue that the government should use one of the well-known exploits.

I also could imagine that Apple would aid such a case anyways.

There is nothing in the digital signature check that allows it to be locked to a device, so that's logic that has to kick in AFTER the trusted layer has validated the code. At that point, it is a simple matter of altering the device ID check in unsecured RAM and you've now got another cracked phone.
Actually, I would argue that this is not true. Before installing, the device wants a ticket to be signed by apple that contains a hash of the firmware to be installed, the phone's identifier and a nonce it has just generated. See here: https://www.theiphonewiki.com/wiki/SHSH

So by not signing any requests for that particular firmware hash, Apple can effectively neuter that firmware and make sure it's never installed anywhere but on the target phone.

The problem is though: If apple can be compelled to do this once, they can also be compelled to do this any other time.

That's not part of the boot chain. That's for OTA updates.
So would a signature check on the trusted layer against a signature generated with the device id (you'd need to distribute a different binary against every device id) permit the generation of an OS image that could only run on a single device?
It would, in theory. If there weren't any catches with this approach though... Apple could have avoided having itself in this position in the first place.
Once you've changed the device id check code, you'd still need to sign it again if you wanted to distribute it widely
Sure, but once the FBI has forced Apple to write the code, forcing them to update the device ID and sign the new build is trivial by comparison, which means that breaking into any random iPhone will become routine.
Is it possible to change a phone's device id to match the initial target, though?
I believe the FBI is suggesting that Apple tie the update to the phone's IMEI, which I believe phone thieves routinely change by desoldering and replacing a chip.
Apple firmware updates are signed on a per-install basis.
Not sure why this got downvoted, I'm not too familiar with iOS but AFAIK this is exactly how the SHSH system works with the modern iPhones.

Quick googling seems to support this.

I didn't downvote you, but I think you're being downvoted because the information content isn't much more than "but cryptography something something!"

I mentioned that the most common method for uniquely identifying a handset (the IMEI) can be changed by switching a chip on the iPhone's main board. (At least this was true 6 years ago.)

So, unless Apple uses an interactive signature scheme or prevents the FBI/intelligence agencies from ever seeing the signature (using TLS with hard-coded certs), then the signature can be replayed.

If the signature can be replayed, then in order to prevent FBiOS being used on multiple phones, it must be tied to one or more unique identifiers, probably excluding the IMEI.

Many people understood my post as shorthand for the above. Responding to this with "[But] Apple firmware updates are signed on a per-install basis." doesn't add to the conversation unless you provide further details. At least, that's my best guess as to why you've been downvoted.

Yes, but that is not nearly the same burden as actually writing the compromised OS. It's probably as easy to compel them to sign the update as it is to compel them to turn over iCloud data.
They could easily request the device signing keys via a different case or again using the all-writs act stating that it's necessary for whatever.

Not turning over the encryption/signing keys would be followed up with jail time / contempt of court charges for any officers/developers/etc refusing to remand the keys into federal custody.

Yes someone can modify the OS image to take out the check for phone ID and then it can work on any phone.

Also the FBI would want to use it on other phones as well. They might modify it themselves to work with other phones.

Moreover, once the compromised OS is created, Apple will be compelled to unlock iPhones in every country where it does business, including countries like China and Russia.
Apple releases updates for their phones often. They could engineer a hack that can then be patched by new versions of iOS.