[cryptography] Math corrections [was: Let's go back to the beginning on this]
Note: I've had to paraphrase some of the content from the archives, so please excuse me if this does not appear in the context of the original thread. I remember enough of my Advanced Statistics from school to know that the following line of reasoning is fallacious, and can leads to erroneous conclusions: On 09/15/2011 12:15 PM, Ian G wrote: >> >> Trust in a CA might be more like 99%. > > Now, if we have a 1% untrustworthy rating for a CA, what happens when > we have 100 CAs? > > Well, untrust is additive (at least). We require to trust all the > CAs. So we have a 100% untrustworthy rating for any system of 100 CAs > or more. On Thu, Sep 15, 2011 at 7:16 PM, Marsh Ray writes: > The CAs can each fail on you independently. Each one is a potential > weakest link in the chain that the Relying Party's security hangs > from. So their reliability statistics multiply: > > one CA: 0.99 = 99% reliability > two CAs: 0.99*0.99 = 98% reliability > 100 CAs: 0.99**100 = 37% reliability > I don't know many people who would consider a critical system that is > only 37% reliable to be meaningfully better than "100% untrustworthy" > though. When you say a widget is 99% reliable, this is another way of saying that there is a 0.01 probability of the widget failing. If you have a 100 widgets and you use them individually, then the probability does not change - there is still a 0.01 probability of any given widget failing. It is not, as IanG writes, additive so that if you have 100+ widgets, they will all fail. (Bear with me, I'm getting to the CA's). When you use two widgets combined together, the probability of *either* of the two widgets failing is *still* 0.01. However, the probability of *both* widgets failing - i.e. its conditional probability - is 0.01 of a certain event (which already had a 0.01 probability). This means it has a probability of 0.01 * 0.01 failure rate, which equates to 0.0001, a 1 in 10,000 occurrence (not a 2% failure rate as Marsh Ray writes). What does all this have to do with trust in CAs? When you establish a session with a given web-server, you're trusting ONE issuer of the SSL certificate. If we assume that one in 100 CA's in your browser is incompetent and has been compromised, then the probability of connecting to a web-site whose SSL cert was issued by the compromised CA is 0.01. If the Incompetent-CA's certificate was issued by some self-signed Root CA, and if we assume the same probabilities apply to the Root CA, then the conditional probabilities of the cert-chain being compromised at both levels is, at best 0.0001 and at worst, 0.01. (If there were three CA's in the chain, then the conditional probabilities are, at best 0.01 - one in a million that all three CAs are compromised in the chain - and at worst, 0.01). When one connects to a web-site, one does not trust all 500 CA's in one's browser simultaneously; one only trusts the CA's in that specific cert-chain. The probability of any specific CA from your trust-store being compromised does not change just because the number of CA's in the trust-store increase (unless the rate of failure incidents across all CA's do go up). For the Dutch people, the probabilities were, unfortunately, skewed by their own government restrictions on which CA's could be used. If DigiNotar was the only approved CA, then they changed the original (assumed) probability of failure from 0.01 to a 1 - a certainty. Arshad Noor StrongAuth, Inc. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Math corrections [was: Let's go back to the beginning on this]
On Sep 17, 2011, at 8:54 PM, Arshad Noor wrote: > When one connects to a web-site, one does not trust all 500 CA's in > one's browser simultaneously; Actually, that is exactly the situation. If, and only if, the person operating the browser inspects the certificate chain and knows what to expect — e.g. that the real accounts.google.com is signed Verisign -> Thawte -> accounts.google.com — then they can be fooled by any misuse of any of the ~1,500 signing certificates. In effect, the user either expects and understands all this complicated stuff, or they expect and understand one bit of information ("Did I get a padlock in the URL bar or not"). Obviously, people don't know what exact certificate chains to expect for arbitrary sites. Because the information available to most people is just that one bit, they are exposed on every connection to every signer. Thus, having more signers or longer certificate chains does not reduce the probability of failure; it gives attackers more chances to score a hit with (our agreed-upon hypothetical) 0.01 probability. After just 100 chances, an attacker is all but certain to score a hit. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Math corrections [was: Let's go back to the beginning on this]
On 09/17/2011 09:14 PM, Chris Palmer wrote: Thus, having more signers or longer certificate chains does not reduce the probability of failure; it gives attackers more chances to score a hit with (our agreed-upon hypothetical) 0.01 probability. After just 100 chances, an attacker is all but certain to score a hit. Agreed. But, that is just a consequence of the numbers involved. The real problem, however, is not the number of signers or the length of the cert-chain; its the quality of the "certificate manufacturing" process. Arshad Noor StrongAuth, Inc. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Math corrections [was: Let's go back to the beginning on this]
On 09/17/2011 11:59 PM, Arshad Noor wrote: The real problem, however, is not the number of signers or the length of the cert-chain; its the quality of the "certificate manufacturing" process. No, you have it exactly backwards. It really is the fact that there are hundreds of links in the chain and that the failure of any single weak link results in the failure of the system as a whole. When the number of CAs is large like it is, it becomes impossible to make all the CAs reliable enough ("give them enough nines" of reliability) to end up with an acceptable level of security. On 09/15/2011 06:32 PM, d...@geer.org wrote: The source of risk is dependence, perhaps especially dependence on expectations of system state. This is an extreme example of that principle. Your insecurity gets exponentially worse with the the number of independent CAs. Something this analysis doesn't capture probably even causes it understate the problem: CAs aren't failing randomly like earthquakes. Intelligent attackers are choosing the easiest ones to breach. In other cases, the CAs themselves will willfully sell you out! Now you may be a law-and-order type fellow who believes that "lawful intercept" is a magnificent tool in the glorious war on whatever. But if so, you have to realize that on the global internet, your own systems are just as vulnerable to a "lawfully executed" court order gleefully issued by your adversary (as if they'd even bother with the paperwork). And don't let anybody tell you that it will be hard for him to pull off an active attack on the internet, because in normal circumstances it just isn't. It was demoed for DefCon 18: http://www.wired.com/threatlevel/2008/08/how-to-intercep/ http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html In the case of Kapela and Pilosov’s interception attack, Martin Brown of Renesys analyzed that incident and found that within 80 seconds after Kapela and Pilosov had sent their prefix "advertisement" to hijack DefCon’s traffic, 94 percent of the peers from whom Renesys collects routing traffic had received the advertisement and begun to route DefCon traffic to the eavesdroppers’ network in New York. Yep, that's right. IP routes are agreed on based on the honor system. - Marsh ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Math corrections [was: Let's go back to the beginning on this]
On 2011-09-18 3:37 PM, Marsh Ray wrote: Now you may be a law-and-order type fellow who believes that "lawful intercept" is a magnificent tool in the glorious war on whatever. But if so, you have to realize that on the global internet, your own systems are just as vulnerable to a "lawfully executed" court order gleefully issued by your adversary (as if they'd even bother with the paperwork). Doubtless verisign will issue whatever certificates the CIA needs to intercept Al Quaeda communications, if they were silly enough to use https to secure their communications. Unfortunately, chances are that PakExperts will issue whatever certificates Al Quaeda needs to intercept CIA communications, if they were silly enough to use https to secure their communications. Even within a single country, things can get tense. I am pretty sure that the Pentagon and the State Department would have no difficulty, and no hesitation, in getting certificates to spy on each other. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Math corrections [was: Let's go back to the beginning on this]
On Sun, Sep 18, 2011 at 1:37 AM, Marsh Ray wrote: > On 09/17/2011 11:59 PM, Arshad Noor wrote: >> >> The real problem, however, is not the number of signers or the length >> of the cert-chain; its the quality of the "certificate manufacturing" >> process. > > No, you have it exactly backwards. > > It really is the fact that there are hundreds of links in the chain and > that the failure of any single weak link results in the failure of the > system as a whole. When the number of CAs is large like it is, it > becomes impossible to make all the CAs reliable enough ("give them > enough nines" of reliability) to end up with an acceptable level of > security. "acceptable level of security" is fine when discussing the likelihood of SSN egress'ing out the proverbial door. But I find it hard to quantify personal safety (or how many theoretical 9's it would take). > On 09/15/2011 06:32 PM, d...@geer.org wrote: >> >> The source of risk is dependence, perhaps especially dependence on >> expectations of system state. > > This is an extreme example of that principle. > > Your insecurity gets exponentially worse with the the number of > independent CAs. > > Something this analysis doesn't capture probably even causes it > understate the problem: CAs aren't failing randomly like earthquakes. > Intelligent attackers are choosing the easiest ones to breach. In other > cases, the CAs themselves will willfully sell you out! Right. > Now you may be a law-and-order type fellow who believes that "lawful > intercept" is a magnificent tool in the glorious war on whatever. But if > so, you have to realize that on the global internet, your own systems > are just as vulnerable to a "lawfully executed" court order gleefully > issued by your adversary (as if they'd even bother with the paperwork). When searching for a threat model, let me suggest the adversaries for modeling: government and corporate. It does not matter to me if its the US government and an illegal wiretap, or the Iranian government and MITM. If you can secure the system from the government and corporate adversaries, many of the the other adversaries simply fall by the wayside. But you will never be totally secure against government, since many courts will happily issue orders to aide or benefit the adversary. i know Its not a popular opinion when your firm/company is vying for post 9/11 funding, but it is what it is. > And don't let anybody tell you that it will be hard for him to pull off an > active attack on the internet, because in normal circumstances it just > isn't. > > It was demoed for DefCon 18: > http://www.wired.com/threatlevel/2008/08/how-to-intercep/ > http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html >> >> In the case of Kapela and Pilosov’s interception attack, Martin >> Brown of Renesys analyzed that incident and found that within 80 >> seconds after Kapela and Pilosov had sent their prefix >> "advertisement" to hijack DefCon’s traffic, 94 percent of the peers >> from whom Renesys collects routing traffic had received the >> advertisement and begun to route DefCon traffic to the eavesdroppers’ >> network in New York. > > Yep, that's right. IP routes are agreed on based on the honor system. DNS appears to be in the same boat. Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Math corrections [was: Let's go back to the beginning on this]
On 18/09/11 2:59 PM, Arshad Noor wrote: On 09/17/2011 09:14 PM, Chris Palmer wrote: Thus, having more signers or longer certificate chains does not reduce the probability of failure; it gives attackers more chances to score a hit with (our agreed-upon hypothetical) 0.01 probability. After just 100 chances, an attacker is all but certain to score a hit. Agreed. But, that is just a consequence of the numbers involved. You guys have a very funny way of saying probability equals 100% but hey, ... as long as we get there in the end, who am I to argue :) The real problem, however, is not the number of signers or the length of the cert-chain; its the quality of the "certificate manufacturing" process. Which is a direct consequence of the fact that the vendors unwound the K6 mistake of PKI (my words), and hid the signature chain (your words). Hence the commonly cited "race to the bottom." So, causes and effects. The real question is, how to reverse the race to the bottom? What tweak do we have in mind? iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Math corrections [was: Let's go back to the beginning on this]
On 18/09/11 1:54 PM, Arshad Noor wrote: When one connects to a web-site, one does not trust all 500 CA's in one's browser simultaneously; one only trusts the CA's in that specific cert-chain. The probability of any specific CA from your trust-store being compromised does not change just because the number of CA's in the trust-store increase (unless the rate of failure incidents across all CA's do go up). Right, but the user doesn't care about any specific CA. She cares about the system of all CAs. My words segwayed from an individual CA to the system of CAs ... perhaps a bit too briefly. And, the attacker has the luxury of choosing the CA, apparently :) iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography