Live data from Hacker News

The Feds Can Now Probably Unlock Every iPhone Model

forbes.com

161–162 of 162 posts

Re: The Feds Can Now Probably Unlock Every iPhone Model

#161

Earlier quoted context omitted.

It’s absolutely untrue that ex-Apple employees are helping them break in. Apple employees do not have an advantage in creating this type of thing.

Sure they do, they're familiar with the design. Unless it is completely open source or has been totally reverse engineer (which I doubt) then that is an advantage.

It’s not an advantage, in practice. Writing exploits against iOS is a very scarce skill, and the people who can do this might be slightly more productive if aided by the source, but the reverse isn’t true. Having the source doesn’t teach you anything about finding and exploiting these bugs.

It might seem logical to those unfamiliar with how these hacks work, but consider that such hacks do not depend on the secrecy of the design. Also consider that Apple hires regular software and hardware engineers, who do their best to design a system, and Apple then hires hackers (both internally, as well as external consultants) to find weaknesses in their designs. These weaknesses are then fixed before the product ships, meaning even those who were paid to break it no longer know how. This alone should tell you that people who know the system intimately are not the ones who understand how to break it.

Put another way, if I need to make this product, and there are two candidates I can hire, one person who wrote the software and one who knows nothing about the software but is demonstrably skilled at finding exploits in similar systems, I’ll take the latter in a heartbeat.

Re: The Feds Can Now Probably Unlock Every iPhone Model

#162
post #153

Earlier quoted context omitted.

I'll be the first to admit that to a DNS expert my original phrasing was not fully precise or fully complete, but calling it "factually not correct" is unfair. As the GP hints the idea is that you cycle through a large number of open resolvers around the world, putting the key into, let's say, 10 of them each time for redundancy & availability. As you usually cannot extend the timeout on those servers, you simply mov…

> As you usually cannot extend the timeout on those servers, you simply move to a different set of 10 servers during each refresh. Think about that from a technical perspective and you’ll realize the flaw. :) You can’t cycle to a new set unless the authoritative server is still responding with the key. If the authoritative server still has it, what difference does the fact a caching name server has it? Furthermore, t…

> You can’t cycle to a new set unless the authoritative server is still responding with the key.

Yes - during a refresh you'd (re-)add the key to an authoritative server that you control, query it from X open resolvers that you do not control, then delete the records from the authoritative server that you control, such that the only remaining copies are held by the open resolvers. Care would be taken to make the key forensically unrecoverable on the authoritative resolver whenever it's not participating in this refresh process.

> there’s zero guarantees a caching resolver will cache for the ... [full] TTL

To deal with that you can test them first using useless/random data, and use many (10+) to deal with the risk that policy changes after your test. The hope being that it's unlikely for all 10+ to go offline, time out, etc, before your next refresh. But it is true that some availability risk is the price you must pay for the "unrecoverability after X seconds, using HW you don't own" benefit of the scheme.

Post reply on HN