3 ms·
Although I agree with the premise -- a sufficiently dedicated attacker can defeat many mechanisms you can come up with to protect your data -- many of the point
by jwise0 12y ago
Although I agree with the premise -- a sufficiently dedicated attacker can defeat many mechanisms you can come up with to protect your data -- many of the points that the author makes seem to be based on either incorrect or implausible assumptions.
For instance, the claim that modern cell protocols can be "silently" MITMed is not really true; the current known attack to spoof a GSM tower, I believe, is limited to using some vulnerabilities in older GSM protocols, and may not work against modern 3G or LTE. And, indeed, the paper cited on a cryptosystem in GSM 3G being weak enough to pull data off the air does not say that at all: it simply weakens the cipher, but the conclusion of that paper itself says that the attack may not be viable for current networks.
The author's view of how the UID works in the Secure Enclave is weak at best, as well. The article that the author cites the possibility of the "Secure Enclave code being able to read the UID key"; as comex mentioned yesterday [1], this isn't true. (I know also that other SoCs work the same way that comex mentions; this is a common pattern.) The author then goes on to discuss what could be done even if the key bits were extracted from fuses (an attack that I agree is possible); he claims a cycle time of 800 per iteration if executed on a CPU, but in reality, the encryption is done on a dedicated AES engine; I believe a cycle time closer to 4 per iteration is more likely, giving timescale estimates over 2 orders of magnitude worse than the author suspects.
It's not all bad, though. The author makes at least one very good point: 0day on the device, while it is powered on, could be enough to simply run the entire device through the onboard crypto. The exploit doesn't need to be complicated enough to modify the system software permanently -- as long as it can be used once, that's good enough.
I think the crux of the matter is that this crypto scheme is not designed to stop the NSA, anyway: it's designed to stop comex and to stop the local police. If you need an NSA-proof device, you need a much much smaller attack surface to begin with.
[1] https://news.ycombinator.com/item?id=8410819 https://news.ycombinator.com/item?id=8410819
- jokoon 12y ago> I think the crux of the matter is that this crypto scheme is not designed to stop the NSA I think the NSA has so many tools available when it comes to hack into people's data, it doesn't really matter how you secure yourself, there are many ways for the NSA to spy on people if they really want to. Right now I don't think anyone can really pretend to secure their data from the NSA. It might make it harder for them, but if you really want to hide from the NSA, I don't think it's really realistic to just be informed about cryptography and computer security. You would really need to just not use computers at all.
- aftbit 12y agoAirgaps and secured physical access are probably good enough.
- stouset 12y agoYou are only considering technological attacks.
- deleted 12y ago[deleted]
- x0x0 12y agoNot least of which is using 210 to ask your nuts for your password...
- scott_karana 12y agoWhat's 210?
- x0x0 12y agovolts ac
- scott_karana 12y agoDuh! Thanks. :-) (120v country resident here)
- azonenberg 12y ago> The article that the author cites the possibility of the "Secure Enclave code being able to read the UID key"; as comex mentioned yesterday [1], this isn't true. We don't know that, we just know Apple says it's the case and nobody's broken it yet. Without a full reverse engineering of the Secure Enclave firmware, plus the IC, there's no way to know if there's a hidden backdoor, bug, or debug mode allowing the data to be read.
- bjornsing 12y agoI thought the question was whether the UID is protected from malicious Secure Enclave firmware or not, no?