Hacker News new | ask | show | jobs
by tfinniga 3768 days ago
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.

6 comments

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.