Why Apple's iPhone encryption won't stop NSA
41–50 of 71 posts
Re: Why Apple's iPhone encryption won't stop NSA
#42I'd like for people to start thinking about security measures, including encryption, as a cost function rather than as a boolean condition (e.g. safe vs. unsafe; stop the NSA vs. not stop the NSA). I doubt there is anyone who can stop the NSA from executing a targeted attack that breaches that information. My feeling is that good security measures increase the marginal cost per person surveilled. As the article point…
> I'd like for people to start thinking about security measures, including encryption, as a cost function rather than as a boolean condition (e.g. safe vs. unsafe; stop the NSA vs. not stop the NSA) Great point and one that I think typical computer savvy users already do. It is in the security-expert-fantasy-world that the perfect quickly becomes the enemy of the good. For example, using SSL to send sensitive data li…
In a traditional economic sense, the optimal amount to spend on security measures is when the marginal costs equal the marginal benefits.
Re: Why Apple's iPhone encryption won't stop NSA
#43Earlier quoted context omitted.
> I'd like for people to start thinking about security measures, including encryption, as a cost function rather than as a boolean condition (e.g. safe vs. unsafe; stop the NSA vs. not stop the NSA) Great point and one that I think typical computer savvy users already do. It is in the security-expert-fantasy-world that the perfect quickly becomes the enemy of the good. For example, using SSL to send sensitive data li…
In a traditional economic sense, the optimal amount to spend on security measures is when the marginal costs equal the marginal benefits.
Yes, but it's hard to quantify the benefits (or even the costs) of a security measure—it's just as much a risk evaluation as it is a cost one.
Re: Why Apple's iPhone encryption won't stop NSA
#44Although 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 usi…
> 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…
I thought the question was whether the UID is protected from malicious Secure Enclave firmware or not, no?
Re: Why Apple's iPhone encryption won't stop NSA
#45I'd like for people to start thinking about security measures, including encryption, as a cost function rather than as a boolean condition (e.g. safe vs. unsafe; stop the NSA vs. not stop the NSA). I doubt there is anyone who can stop the NSA from executing a targeted attack that breaches that information. My feeling is that good security measures increase the marginal cost per person surveilled. As the article point…
I agree to some extent (and I'm excited by the progress in "opportunistic encryption"), but I'd like for people to also start thinking about what's possible and what's simply not.
For example, modern block ciphers like AES can protect data against an attacker that does not have access to the encryption key. However, in this case we're talking about an attacker that has perhaps 90% of the encryption key, the UID, in its physical possession. The UID can be concealed in many ingenious ways, but that doesn't change the fact that the attacker is in physical possession of the atoms that encode it. This is essentially "security by obscurity", albeit on a high level.
In contrast I would argue that message exchange over the internet can be made secure, even against a nationstate adversary.
Re: Why Apple's iPhone encryption won't stop NSA
#46Earlier quoted context omitted.
In a traditional economic sense, the optimal amount to spend on security measures is when the marginal costs equal the marginal benefits.
Yes, but it's hard to quantify the benefits (or even the costs) of a security measure—it's just as much a risk evaluation as it is a cost one.
Like so much of economics, the hard part is coming up with a price tag that everyone agrees on in all contexts. How much would you pay to save your grandmother's life from an illness? How much would you accept to allow me to hunt her for sport?
So, in that sense, coming up with a precise measure of marginal cost / marginal benefit would be hard in practice.
Re: Why Apple's iPhone encryption won't stop NSA
#47I'd like for people to start thinking about security measures, including encryption, as a cost function rather than as a boolean condition (e.g. safe vs. unsafe; stop the NSA vs. not stop the NSA). I doubt there is anyone who can stop the NSA from executing a targeted attack that breaches that information. My feeling is that good security measures increase the marginal cost per person surveilled. As the article point…
Exactly.
Good security is not an unbreakable lock, it's a lock that costs significantly more to break than the value of what it's guarding.
Re: Why Apple's iPhone encryption won't stop NSA
#48What is stopping companies from implementing timers to prevent brute force attacks? Limit password entry attempts to 3 then if still wrong then wait 1 minute. One more wrong entry then wait 3 minutes then 15 minutes then 1 hour, 4 hours, 8 hours, 24 hours etc.
Doesn't iOS do this if you don't have "erase data after 10 failed attempts" set?
Why can't all systems have this implemented or is this bypassed another way which then allows someone to brute force to their heart's content?
Re: Why Apple's iPhone encryption won't stop NSA
#49What is stopping companies from implementing timers to prevent brute force attacks? Limit password entry attempts to 3 then if still wrong then wait 1 minute. One more wrong entry then wait 3 minutes then 15 minutes then 1 hour, 4 hours, 8 hours, 24 hours etc. Doesn't iOS do this if you don't have "erase data after 10 failed attempts" set? Why can't all systems have this implemented or is this bypassed another way wh…
1) This article seems to describe actually having physical access to the device.
2) As for "all systems," if you mean a place where public guessing is possible (like a web app), then this measure opens up an easy DOS surface. Want someone not to be able to access their account? Know their email / username? Just burn up all their 'guesses' and they'll have to wait.
Re: Why Apple's iPhone encryption won't stop NSA
#50What is stopping companies from implementing timers to prevent brute force attacks? Limit password entry attempts to 3 then if still wrong then wait 1 minute. One more wrong entry then wait 3 minutes then 15 minutes then 1 hour, 4 hours, 8 hours, 24 hours etc. Doesn't iOS do this if you don't have "erase data after 10 failed attempts" set? Why can't all systems have this implemented or is this bypassed another way wh…
1) This article seems to describe actually having physical access to the device. 2) As for "all systems," if you mean a place where public guessing is possible (like a web app), then this measure opens up an easy DOS surface. Want someone not to be able to access their account? Know their email / username? Just burn up all their 'guesses' and they'll have to wait.
Good points. What do you think about a 2FA-type of setup where if someone tries this then it sends a message to the device that asks if you are trying to access something through a webapp and if you say no then it blocks access until the correct password is entered or until it is accessed from the same device that previously successfully accessed it on a consistent basis (say 5 times within the past week or month).
Could IP-blocking be implemented or a double timer where if someone tries to DoS the account by entering too many passwords too quickly then that is also limited such as trying to submit too many comments to HN too quickly?