The "crown jewel" of McAfee is ePO -- "ePolicy Orchestrator". Basically centralized management for your AV deployment (and will even managed SYMC AV), as well as any other McAfee product, and a host of 3rd party security products that have integrated into the ecosystem.
It STILL dominates the enterprise market, no matter how crap McAfee AV is.
My (somewhat informed, but could still be wrong) guess as to what Intel was thinking at the time (remembering that this was about 5 years ago):
Intel had made a big investment in enterprise chipsets with features like VT and AMT. They were hoping to speed up enterprise hardware refresh rates for a decade or so by continuing to provide highly compelling enterprise features in hardware.
One area they thought held particular promise was security. They were interested in AV companies leveraging a combination of VT and AMT to provide a more secure environment-- basically they wanted to see host-based security technology live outside the end-user's OS, but still reach in to detect and protect. That way, if a box did get popped, you could still update signatures, etc and have some reasonable hope that you could actually repair the OS without wiping it. Lots of other little bits in the vision.
The big problem for Intel was that they needed security vendors to build and sell software on top of this platform. But it was a bit of a "chicken and egg" problem, where there wasn't enough of a hardware footprint to justify a product investment, and so there wasn't enough compelling reason for people to pay extra for the hardware.
Intel pushed most A/V companies hard for some investment in the area, and McAfee actually did peel off a SMALL team to work on it (quite possibly the best engineering team w/in McAfee actually). They spent maybe a year making some good progress, and then when DeWalt was trimming down to save costs, that team got cut.
I'd heard that Intel was enraged. I can imagine them thinking they needed to control their own destiny-- get the security software built that they thought would drive faster hardware refreshes. McAfee had been the most amenable, and was definitely primping itself to be acquired.
By the way, McAfee does NOT own PGP. They'd spun it back out, and it got re-acquired by Symantec.
Ben,
Thanks for the positive review.
I know the book has pissed some people off, especially when I take on their particular sacred cows (e.g., intrusion detection). But, the Schneier chapter isn't meant to piss him off, I have no beef with him whatsoever. I just think the fanboys do the world a disservice by not thinking for themselves, especially when they draw from material that's a decade old.
John
For most people, this will put them at MORE risk than selectively blacklisting rogue certs as they are identified:
It is very likely that no bad guys will ever get a chance to use this attack. For them to use the next MD5 attack they would need to be able to predict a sequence number several months in advance, instead of several days.
Any attack of this type will be pretty obvious from the CA's logs. CAs that sign with MD5 will need to invest some man power in manual validation, but this is not a huge cost. This is how you find the unknown certs, if there are any (which is highly likely).
Since many legitimate web sites use SSL/TLS certs from RapidSSL, taking your advice for remediation will just give them pop-ups on some legitimate sites, which is likely to desensitize them. When people get enough pop-ups for stuff that isn't a risk, it's well known that they start just clicking through, so this would put the average person more at risk.
The relative security between MD5 and SHA1 is currently more or less linear to the digest size, though more work has been done on practical applications on MD5, so it is a little weaker relatively. For cases where the birthday paradox applies, you lose 1/2 your bit length in the brute force case.
There's some confusion here. I'll try to clear it up. Let's imagine that you've got FredCA that got its CA credentials from Verisign. Let's say FredCA is perfectly legitimate. That means that they have a cert with a signature on it from Verisign. Let's say that Citibank wants to get a leigitimate certificate and they go to FredCA. The certificate they get back is signed by FredCA.
When your browser goes to Citibank, it gets to see the entire certificate chain (the server sends back a PKCS blob of the entire chain). It validates not only that the Citibank cert was signed by FredCA, but it also validates the signature on FredCA's certificate. If it trusts Verisign, then it makes sure that the certificate is definitely one it knows maps to verisign, and then everything is trusted.
A lot of people here seem to believe that the attack is that a bad guy can take the cert that FredCA endorsed for CitiBank or the cert that Verisign endorsed for FredCA (as long as the signature uses MD5), and steal the signature for their own certificate. If that were true, then we could not trust any certificate signed by MD5. Good thing that most certs have been issued via SHA1 for a while.
But, that is not true. In this attack, the bad guy can generate a pair of certificates, one that the CA signs, and another for which the same signature happens to be valid. You cannot do this to any cert on the internet, the pair of certificates have to be specially crafted.
In this attack, the bad guy gets FredCA to sign a certificate for DummyOrg, but when the bad guy created the DummyOrg cert, he created a matching cert for his own CA, call it EvilCA. Since the certs were created together in a particular way, the bad guy can take the signature off the DummyOrg cert and paste it onto the EvilCA cert and everything will work.
With the EvilCA cert, he can create certificates that claim to be from any site on the internet, even though they are not. When they get to the browser, the browser looks at the whole chain, and it looks good, even though FredCA never signed the EvilCA certificate. However, once we blacklist the signature for the DummyOrg cert, we will immediately blacklist everything endorsed by EvilCA, because when a browser goes to validate the whole chain, they'll see that the certs are issued by a blacklisted CA, and thus would know that the certificate is fake.
Also, note that there's a good reason to believe this hole will be closed well before any bad guys actually try the attack. At most, the world will have to blacklist a small handful of rogue CA certs.
Additionally, for the CAs other than RapidSSL, it's not clear they can be attacked easily. As far as I know, they all usually sign with SHA1. I don't know how you would get them to choose MD5, but I suspect none of them will do it anymore after this. And, even if they did, you would need to know how to predict their sequence number and the date values they add to the certificate. With RapidSSL that was all automated and very predictable. It could be with the other CAs, but it isn't necessarily the case.
I think you either didn't read my writeup at all, or didn't understand it. But, I most certainly got it right. Ask any other cryptographer out there. Or, just read the researchers write-up carefully. It is very clear.
From what I understand from your posts, you're saying I don't need to create two certs with the same hash, I "just" need to create a new cert that matches an existing web site's cert. That's not true, and some intuition should demonstrate it. If you understand the birthday paradox, it says that, with brute force for MD5 (that is, if we assume MD5 is perfect), my explanation (remember, brute force), would be O(2^64) to attack. Yours would be O(2^128). Now, if someone has tricks to do better than brute force, perhaps they'd work in your context but not mine, or vice versa. Or, more likely, any structural weaknesses in MD5 are likely to have implications for both kinds of attack. Now, since O(2^64) was already near the border of feasibility, while O(2^128) was very far from it, which kind of attack was likely to become more practical first?
The whole point of my post on O'Reilly was that people do seem to think the research in question represents the scenario you're talking about. If that were the case, we would indeed have to quickly stop allowing even legacy MD5 certificates, which would be a little painful. But, that is absolutely not the case. If the few risky CAs deal with the problem quickly, this will be a huge non-event.
There are lots of differences. The important one is the impact for dealing with the problem. If the signature for any cert in the world signed by MD5 could be stolen, then you couldn't trust anything with an MD5 signture and we'd therefore have to treat every web site serving up an MD5 cert as bad, which would cost lots of people time and money. With this attack, there's a very good chance that no bad guy will ever use the attack in real life, and even if they do, it is not too hard to identify and blacklist the few rogue CAs that will exist, which will automatically invalidate any fake certificates. Most web site certs out there today that were signed by MD5 are perfectly fine (probably through their entire validity period), and there is no need to incur the cost to have people replace them.
Actually, they should do both.
Whether true or not, I have visions of the CA being written by one guy n years ago, and it's been on autopilot ever since. I can imagine that he's got a hardcoded 16 byte value somewhere, and it's easier for him to randomize a sequence number than to make sure he got hardcoded values right across his code base.
If it were me, I'd have abandoned MD5 in 2004, when most other people did.
But, with a large random value, it is a "good enough" solution until MD5 is fully broken. I'm not sure which will happen first, a full break on MD5, or the same kind of collision attack on SHA1 that the researchers used here. I actually suspect the answer is that SHA1 is more vulnerable to this kind of attack than MD5 is to a full break. SHA1 has the same structural weaknesses. The only thing saving it is the bit length. As the complexity of this attack on MD5 comes down from brute force (O(2^64)) we can expect it's coming down on SHA1 as well. Maybe this same kind of attack is feasible given a year of time on a much bigger cluster, or something like that.
Yes, people here are going to misread this to think I mean MD5 is stronger than SHA1 (which it certainly isn't), but that's slashdot for you.
That's an entirely different thing. If you look at my article, I do explain this. But you can easily revoke them all by revoking the rogue CA's credentials. And, once the hole is plugged at the few CAs signing w/ MD5, that is all you have to do (tho it is best done in the browser, not through CRLs or OCSP). The Internet is not going to die. This is not a big deal.
I was talking about finding a new cert where the signature matches any arbitrary web site cert. That is, you can't take Citibank's cert and produce a new cert that says citibank that also has the same signature. I was mentioning this because most people seem to think that this is what the attack involves.
The actual attack involves getting your own rogue CA by tricking an existing CA that signs using MD5 to sign a carefully crafted certificate.
The actual attack does indeed work. It's been assumed this was approaching possible for a while, which is why most CAs long since moved to abandon MD5.
No, you misunderstand their attack. A CA definitely needs to be involved. You trick them into signing a web site cert, but then that signature can be pasted on to your other cert, which is a CA cert. You thus mint your OWN CA cert that a Thawte or whoever has accidentally endorsed, due to the collision you have generated. Note that this dependency on an existing valid CA is why there is a long section about how to anticipate the CA's serial numbers and validity periods.
You're wrong. Read the attack author's write-up here: http://www.win.tue.nl/hashclash/rogue-ca/
You will see that they absolutely need to get the CA to endorse the data they produce. They come up with two certificates in advance that, under the right conditions, will both validate when one of them is signed via MD5. That means, you cannot take an arbitrary cert on the internet and feasibly come up with an identical cert that is malicious, where the same signature applies.
Read the article carefully. Just because something is signed by MD5 doesn't make it broken. Signing future things with MD5 without proper randomization is bad, but I don't expect anyone other than the third tier CAs to do that kind of thing after this. I will also say that the attack will leave a pretty distinctive signature in CA logs.
Plus, nobody would say "revoke Thawte's cert retroactively", but it should probably not be used anymore, and no CA certs issued with it should be accepted anymore. In fact, those issued over the last year, Thawte should publish which ones it issued separately. If browsers respected that list (a one-time thing), it would close the remaining hole (for Thawte... each CA affected would need to do the same thing).
Ah, yes, who could forget Randy taking out his frustrations with a VCR by smashing it with a sledge hammer on the first day of class? I definitely credit Randy and that class for getting me to prioritize the end users above almost everybody else.
Haha, me too (I was one of Randy's students back when he was at UVa). I didn't get too into Doom, but when the Quake test code came out, many of us spent pretty much every waking hour playing, for several months. In the meantime, we were supposed to be working on an Alice deliverable for SIGGRAPH.
I think the turning point for my entire life was a few months before SIGGRAPH, when Randy called a couple of us out for being too much play and not enough work. I went cold turkey, and didn't pick up another video game for 10 years. I firmly believe if he hadn't done that, I'd have accomplished very little professionally, and would be holding down a crappy 9-5 mid-level programming job while thinking forward to what I was going to play on my XBox 360 on any given night. To this day, I can't really get much enjoyment out of a video game, but I think that's a good thing!
Randy definitely taught me to pick a prize and keep my eye on it. He used to like to tell me, "John, you're a strong rocket with no fins," that I would never get to the moon and would come crashing back to earth if I didn't focus. I didn't like it at the time, but I needed to hear it. I think about that advice all the time, and it is just as relevant to me today.
Randy has always attracted amazing talent and amazing people. The people in that lab were the greatest group of people I ever worked with in many respects. I'm proud they're my friends, and I'm thankful to Randy for providing the environment and putting us together.
Well, they pretty much didn't play. First, only one of their team members showed up. Then, he recruited some people, but by the time he did, the green team had totally owned them. They sat there the whole time, but they might have even been helping out the green team.
My guess is that this is going to be an application of a known (recent) result from djb, that hyperthreading can introduce some serious vectors for timing attacks. See this paper.
I said originally that there's the underlying assumption that the underlying block cipher is a PRP. The proof of security of the encryption scheme is secure relies on a weak assumption about the block cipher, but the attack then is on the block cipher, not the scheme for using the block cipher. The whole point is that, for the most part, we can prove security for almost everything we need, and can boil it down to a few minor assumptions that people strongly believe to be true (such as AES is a PRP).
Agreed that it is not strictly needed. However, it is useful to specify simply for the purposes of testability. It's easier to test that encryption is done properly if you have a decryption implementation to test against.
Slashdot Mirror
It STILL dominates the enterprise market, no matter how crap McAfee AV is.
Intel had made a big investment in enterprise chipsets with features like VT and AMT. They were hoping to speed up enterprise hardware refresh rates for a decade or so by continuing to provide highly compelling enterprise features in hardware.
One area they thought held particular promise was security. They were interested in AV companies leveraging a combination of VT and AMT to provide a more secure environment-- basically they wanted to see host-based security technology live outside the end-user's OS, but still reach in to detect and protect. That way, if a box did get popped, you could still update signatures, etc and have some reasonable hope that you could actually repair the OS without wiping it. Lots of other little bits in the vision.
The big problem for Intel was that they needed security vendors to build and sell software on top of this platform. But it was a bit of a "chicken and egg" problem, where there wasn't enough of a hardware footprint to justify a product investment, and so there wasn't enough compelling reason for people to pay extra for the hardware.
Intel pushed most A/V companies hard for some investment in the area, and McAfee actually did peel off a SMALL team to work on it (quite possibly the best engineering team w/in McAfee actually). They spent maybe a year making some good progress, and then when DeWalt was trimming down to save costs, that team got cut.
I'd heard that Intel was enraged. I can imagine them thinking they needed to control their own destiny-- get the security software built that they thought would drive faster hardware refreshes. McAfee had been the most amenable, and was definitely primping itself to be acquired.
By the way, McAfee does NOT own PGP. They'd spun it back out, and it got re-acquired by Symantec.
Actually, you can buy any of the prizes at Chuck E Cheese-- they charge you $.01 per ticket!
Ben, Thanks for the positive review. I know the book has pissed some people off, especially when I take on their particular sacred cows (e.g., intrusion detection). But, the Schneier chapter isn't meant to piss him off, I have no beef with him whatsoever. I just think the fanboys do the world a disservice by not thinking for themselves, especially when they draw from material that's a decade old. John
The relative security between MD5 and SHA1 is currently more or less linear to the digest size, though more work has been done on practical applications on MD5, so it is a little weaker relatively. For cases where the birthday paradox applies, you lose 1/2 your bit length in the brute force case.
When your browser goes to Citibank, it gets to see the entire certificate chain (the server sends back a PKCS blob of the entire chain). It validates not only that the Citibank cert was signed by FredCA, but it also validates the signature on FredCA's certificate. If it trusts Verisign, then it makes sure that the certificate is definitely one it knows maps to verisign, and then everything is trusted.
A lot of people here seem to believe that the attack is that a bad guy can take the cert that FredCA endorsed for CitiBank or the cert that Verisign endorsed for FredCA (as long as the signature uses MD5), and steal the signature for their own certificate. If that were true, then we could not trust any certificate signed by MD5. Good thing that most certs have been issued via SHA1 for a while.
But, that is not true. In this attack, the bad guy can generate a pair of certificates, one that the CA signs, and another for which the same signature happens to be valid. You cannot do this to any cert on the internet, the pair of certificates have to be specially crafted.
In this attack, the bad guy gets FredCA to sign a certificate for DummyOrg, but when the bad guy created the DummyOrg cert, he created a matching cert for his own CA, call it EvilCA. Since the certs were created together in a particular way, the bad guy can take the signature off the DummyOrg cert and paste it onto the EvilCA cert and everything will work.
With the EvilCA cert, he can create certificates that claim to be from any site on the internet, even though they are not. When they get to the browser, the browser looks at the whole chain, and it looks good, even though FredCA never signed the EvilCA certificate. However, once we blacklist the signature for the DummyOrg cert, we will immediately blacklist everything endorsed by EvilCA, because when a browser goes to validate the whole chain, they'll see that the certs are issued by a blacklisted CA, and thus would know that the certificate is fake.
Also, note that there's a good reason to believe this hole will be closed well before any bad guys actually try the attack. At most, the world will have to blacklist a small handful of rogue CA certs.
Additionally, for the CAs other than RapidSSL, it's not clear they can be attacked easily. As far as I know, they all usually sign with SHA1. I don't know how you would get them to choose MD5, but I suspect none of them will do it anymore after this. And, even if they did, you would need to know how to predict their sequence number and the date values they add to the certificate. With RapidSSL that was all automated and very predictable. It could be with the other CAs, but it isn't necessarily the case.
Hope this helps.
From what I understand from your posts, you're saying I don't need to create two certs with the same hash, I "just" need to create a new cert that matches an existing web site's cert. That's not true, and some intuition should demonstrate it. If you understand the birthday paradox, it says that, with brute force for MD5 (that is, if we assume MD5 is perfect), my explanation (remember, brute force), would be O(2^64) to attack. Yours would be O(2^128). Now, if someone has tricks to do better than brute force, perhaps they'd work in your context but not mine, or vice versa. Or, more likely, any structural weaknesses in MD5 are likely to have implications for both kinds of attack. Now, since O(2^64) was already near the border of feasibility, while O(2^128) was very far from it, which kind of attack was likely to become more practical first?
The whole point of my post on O'Reilly was that people do seem to think the research in question represents the scenario you're talking about. If that were the case, we would indeed have to quickly stop allowing even legacy MD5 certificates, which would be a little painful. But, that is absolutely not the case. If the few risky CAs deal with the problem quickly, this will be a huge non-event.
There are lots of differences. The important one is the impact for dealing with the problem. If the signature for any cert in the world signed by MD5 could be stolen, then you couldn't trust anything with an MD5 signture and we'd therefore have to treat every web site serving up an MD5 cert as bad, which would cost lots of people time and money. With this attack, there's a very good chance that no bad guy will ever use the attack in real life, and even if they do, it is not too hard to identify and blacklist the few rogue CAs that will exist, which will automatically invalidate any fake certificates. Most web site certs out there today that were signed by MD5 are perfectly fine (probably through their entire validity period), and there is no need to incur the cost to have people replace them.
Actually, they should do both. Whether true or not, I have visions of the CA being written by one guy n years ago, and it's been on autopilot ever since. I can imagine that he's got a hardcoded 16 byte value somewhere, and it's easier for him to randomize a sequence number than to make sure he got hardcoded values right across his code base. If it were me, I'd have abandoned MD5 in 2004, when most other people did. But, with a large random value, it is a "good enough" solution until MD5 is fully broken. I'm not sure which will happen first, a full break on MD5, or the same kind of collision attack on SHA1 that the researchers used here. I actually suspect the answer is that SHA1 is more vulnerable to this kind of attack than MD5 is to a full break. SHA1 has the same structural weaknesses. The only thing saving it is the bit length. As the complexity of this attack on MD5 comes down from brute force (O(2^64)) we can expect it's coming down on SHA1 as well. Maybe this same kind of attack is feasible given a year of time on a much bigger cluster, or something like that. Yes, people here are going to misread this to think I mean MD5 is stronger than SHA1 (which it certainly isn't), but that's slashdot for you.
That's an entirely different thing. If you look at my article, I do explain this. But you can easily revoke them all by revoking the rogue CA's credentials. And, once the hole is plugged at the few CAs signing w/ MD5, that is all you have to do (tho it is best done in the browser, not through CRLs or OCSP). The Internet is not going to die. This is not a big deal.
I was talking about finding a new cert where the signature matches any arbitrary web site cert. That is, you can't take Citibank's cert and produce a new cert that says citibank that also has the same signature. I was mentioning this because most people seem to think that this is what the attack involves. The actual attack involves getting your own rogue CA by tricking an existing CA that signs using MD5 to sign a carefully crafted certificate. The actual attack does indeed work. It's been assumed this was approaching possible for a while, which is why most CAs long since moved to abandon MD5.
No, you misunderstand their attack. A CA definitely needs to be involved. You trick them into signing a web site cert, but then that signature can be pasted on to your other cert, which is a CA cert. You thus mint your OWN CA cert that a Thawte or whoever has accidentally endorsed, due to the collision you have generated. Note that this dependency on an existing valid CA is why there is a long section about how to anticipate the CA's serial numbers and validity periods.
You're wrong. Read the attack author's write-up here: http://www.win.tue.nl/hashclash/rogue-ca/ You will see that they absolutely need to get the CA to endorse the data they produce. They come up with two certificates in advance that, under the right conditions, will both validate when one of them is signed via MD5. That means, you cannot take an arbitrary cert on the internet and feasibly come up with an identical cert that is malicious, where the same signature applies.
Read the article carefully. Just because something is signed by MD5 doesn't make it broken. Signing future things with MD5 without proper randomization is bad, but I don't expect anyone other than the third tier CAs to do that kind of thing after this. I will also say that the attack will leave a pretty distinctive signature in CA logs. Plus, nobody would say "revoke Thawte's cert retroactively", but it should probably not be used anymore, and no CA certs issued with it should be accepted anymore. In fact, those issued over the last year, Thawte should publish which ones it issued separately. If browsers respected that list (a one-time thing), it would close the remaining hole (for Thawte... each CA affected would need to do the same thing).
A lot of people in the twitterverse seem to think otherwise, but this is not a major breakage of the Internet. See my commentary at O'Reilly: http://broadcast.oreilly.com/2008/12/the-sky-is-not-falling-on-toda.html
Ah, yes, who could forget Randy taking out his frustrations with a VCR by smashing it with a sledge hammer on the first day of class? I definitely credit Randy and that class for getting me to prioritize the end users above almost everybody else.
Haha, me too (I was one of Randy's students back when he was at UVa). I didn't get too into Doom, but when the Quake test code came out, many of us spent pretty much every waking hour playing, for several months. In the meantime, we were supposed to be working on an Alice deliverable for SIGGRAPH. I think the turning point for my entire life was a few months before SIGGRAPH, when Randy called a couple of us out for being too much play and not enough work. I went cold turkey, and didn't pick up another video game for 10 years. I firmly believe if he hadn't done that, I'd have accomplished very little professionally, and would be holding down a crappy 9-5 mid-level programming job while thinking forward to what I was going to play on my XBox 360 on any given night. To this day, I can't really get much enjoyment out of a video game, but I think that's a good thing! Randy definitely taught me to pick a prize and keep my eye on it. He used to like to tell me, "John, you're a strong rocket with no fins," that I would never get to the moon and would come crashing back to earth if I didn't focus. I didn't like it at the time, but I needed to hear it. I think about that advice all the time, and it is just as relevant to me today. Randy has always attracted amazing talent and amazing people. The people in that lab were the greatest group of people I ever worked with in many respects. I'm proud they're my friends, and I'm thankful to Randy for providing the environment and putting us together.
He's supposed to be spending 50% of his time on Python itself, which is a lot more than he was able to spend on it in his last job.
Well, they pretty much didn't play. First, only one of their team members showed up. Then, he recruited some people, but by the time he did, the green team had totally owned them. They sat there the whole time, but they might have even been helping out the green team.
My guess is that this is going to be an application of a known (recent) result from djb, that hyperthreading can introduce some serious vectors for timing attacks. See this paper.
Uhhhh, the "/8" is an indication of the netmask being 255.0.0.0. The poster was not saying that 128 was reserved.
I said originally that there's the underlying assumption that the underlying block cipher is a PRP. The proof of security of the encryption scheme is secure relies on a weak assumption about the block cipher, but the attack then is on the block cipher, not the scheme for using the block cipher. The whole point is that, for the most part, we can prove security for almost everything we need, and can boil it down to a few minor assumptions that people strongly believe to be true (such as AES is a PRP).
Agreed that it is not strictly needed. However, it is useful to specify simply for the purposes of testability. It's easier to test that encryption is done properly if you have a decryption implementation to test against.
What does that have to do with the price of tea in China? As a matter of fact, if you were observant, you would have noticed that I co-authored GCM.