A mighty fortress is our PKI, Part II
Have you ever wondered what would happen if malware started appearing that was authenticated by signing keys belonging to major hardware or software vendors? Over the last week or two we've had a chance to find out: One of the scariest scenarios for code signing is when the malware authors manage to get their hands on a legitimate developer's code-signing key. Since many development shops see the signing process as nothing more than an annoying speedbump that stands in the way of application deployment, not helped by the fact that code-signing tools like Windows SignTool and Unix' GPG are hard to use and poorly integrated into the development process, developers have generally used the most expedient means possible to sign their code, with signing keys left unprotected or with easy-to-guess passwords (password is a favourite in web advice columns that give examples of how to do code signing), or passwords hard-coded into the scripts that are needed in order to integrate the signing into the build process. Combine this with the existence of entire families of malware such as Adrenalin, Nuklus/Apophis, Ursnif, and Zeus, with key-stealing functionality and it's inevitable that legitimate code-signing keys will end up in the hands of malware authors. The most serious case of this occurred in mid-2010 when malware signed with a key belonging to the major semiconductor manufacturer Realtek started to appear [Rootkit.TmpHider, discussion thread, 12 July 2010, http://www.wilderssecurity.com/showthread.php?p=1712134.][Signed Malware Used Valid Realtek Certificate, Lucian Constantin, 16 July 2010, http://news.softpedia.com/news/Signed-Malware-Used-Valid-Realtek- Certificate-147942.shtml.]. Although PKI dogma states that a certificate belonging to such a key should be immediately revoked, the fact that vast numbers of Realtek drivers had already been signed by it and could now no longer be installed without unsigned-driver warnings or, in the case of 64-bit Windows, used at all, would no doubt have given both Realtek and the issuing CA cause for concern. After several days the certificate was revoked [VeriSign working to mitigate Stuxnet digital signature theft, Steve Ragan, 21 July 2010, http://www.thetechherald.com/article.php/201029/5921/VeriSign-working-to- mitigate-Stuxnet-digital-signature-theft.], although the CA had to wait until the story started to appear in news reports before they became aware of the need for the revocation. The decision to revoke the certificate was probably influenced by a combination of the fact that the majority of users will simply click through a driver install warning and that the hit-and-miss nature of revocation checking meant that many systems would keep on using the certificate regardless (if the certificate had only been used to sign 32-bit code so that the worst that could happen was a warning dialog on install for users to click past then this would have made the decision to revoke even easier). In any case since antivirus vendors had added the malware signature to their scanners as soon as it was discovered, the revocation likely had little actual effect in protecting users from harm. A few days later a new version of the malware appeared, this time signed with a key from another semiconductor manufacturer, JMicron [Win32/Stuxnet Signed Binaries, Pierre-Marc Bureau, 19 July 2010, http://blog.eset.com/2010/07/19/win32stuxnet-signed-binaries.][Another Signed Stuxnet Binary, Sean Sullivan, 20 July 2010, http://www.f-secure.com/weblog/archives/1993.html.][New Stuxnet-Related Malware Signed Using Certificate from JMicron, Lucian Constantin, 20 July 2010, http://news.softpedia.com/news/New-Stuxnet-Related-Malware-Signed-Using- Certificate-from-JMicron-148213.shtml.]. Making the debacle even more entertaining was the fact that one of the principal systems targeted by the malware is a Siemens SCADA (industrial control) system that uses a hardcoded password 2WSXcder that can't be changed because doing so causes the system to stop working [Siemens warns users: Don't change passwords after worm attack, Robert McMillan, 20 July 2010, http://www.infoworld.com/d/security-central/siemens-warns-users-dont-change- passwords-after-worm-attack-915.] and that had been circulating on the Internet for years, including being posted to a Siemens online forum in Russia [SCADA System.s Hard-Coded Password Circulated Online for Years, Kim Zetter, 19 July 2010, http://www.wired.com/threatlevel/2010/07/siemens-scada/.] and online lists of default passwords [default password list, http://www.defaultpassword.com/?action=dplchar=s.] (the reason for this poor level of security is that SCADA systems rate availability above everything else, so that anything that affects, or potentially affects, security is strongly avoided. In addition SCADA systems often use thoroughly out-of-date hardware and software that no-one wants to change for fear of breaking things and for which there's no way to
Re: Encryption and authentication modes
Florian Weimer wrote: I just want to create a generic API which takes a key (most of the time, a randomly generated session key) and can encrypt and decrypt small blobs. Application code should not need to worry about details (except getting key management right, which is difficult enough). More popular modes such as CBC lack this property, it's too easy to misuse them. As David [McGrew] mentioned -- thanks, David -- I've been working towards drafting a proposal for standardizing encrypt-then-authenticate generic composition, and David [McGrew, again] has been quite generous in sharing his work in this area. Working towards this is one aspect of our work (Vincent Rijmen and I) in making cryptography easier to get right at the implementation level, so that its true potential can be realized in practice. Developers shouldn't be making cryptographic decisions, which is one of the driving forces behind our push for standardizing encrypt-then-authenticate generic composition; they needn't be burdened with addressing the subtleties that go along with composite authenticated encryption schemes. The desire to push for this was born out of green cryptography, which Vincent and I introduced in IEEE Security Privacy last year. The premise behind green cryptography was to recycle cryptographic primitives whenever and wherever possible, and do so in a way that not only minimizes implementation complexity, but maximizes cryptographic security. What we ended up with is AES-based encrypt-then-authenticate (e.g., AES-CBC-then-AES-CMAC); this achieves the strongest notions of confidentiality and integrity per Bellare and Namprempre (i.e., IND-CCA2 /\ INT-CTXT) and -- here's the best part -- it's the easiest for developers to get right, since it is secure for all possible secure instantiations of its constituent primitives. If we are to standardize encrypt-then-authenticate generic composition, we would most likely have to include support for SHA-1, SHA-2, and SHA-3; this isn't exactly in line with the recycling paradigm, but a necessary compromise in regards to support across the board. You can get the same security out of AES-CMAC and SHA-*-HMAC, either way. Still, it's important to limit the number of options available, since the more options you have, the more complexity you introduce to the implementation. Perhaps having a standard that supports AES-CBC/AES-CTR-then-AES-CMAC/SHA-*-HMAC would work; this is where community feedback is really useful, since such a standard needs to be as flexible as it is secure. Any thoughts? I've recently spoke with Steve Weis and Ben Laurie at Google, who put together the open-source Keyczar (keyczar.org) cryptographic toolkit, aimed at making cryptography safe and simple for developers to use; they did say, however, that oftentimes, they found themselves backed into a corner with allowing configurations that may be secure, and reasonable, for niche applications, but insecure elsewhere -- in other words, no good for standards. I mention Keyczar because it may be something of interest to you, and I think it serves as a progressive model for the direction we need to be going in -- making cryptography easier to get right. You're absolutely right that you shouldn't have to worry about the details, and that it is easy to misuse. That needs to change. In closing, I'll mention that green cryptography's design paradigm of do a lot with a little; less is more has found its way into a conceptual framework we're working on, dubbed Mackerel, which looks at abstracting away as much of the cryptography as possible and, instead, focus on the higher level concepts of confidentiality and integrity, and why they're mutually necessary. Just as green cryptography is concerned with the assurance of cryptographic implementations, Mackerel is concerned with the tightness of the interface between cryptography and cryptographers, developers, and users. We're drawing a lot from the field of HCIsec, or Human Computer Interaction Security -- of which another Googler, Alma Whitten, is a pioneer*. So, that's a snapshot of what we -- Vincent Rijmen and I -- have been up to over the past couple of years, and I look forward to sharing more as it develops and evolves. I had hoped to have a draft together earlier, but it just wasn't in line with the workload and pace over the past few months; it does appear that I'll have something together by the end of August, which is a plus. We're wide open to thoughts on this. * http://gaudior.net/alma/johnny.pdf - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Intel to also add RNG
On 7/13/10, Perry E. Metzger pe...@piermont.com wrote: It is disturbing to me that people oppose this so much. Yes. A hardware RNG seems an obvious Good Thing. Not a complete solution, but a very useful component. For a lot of applications -- servers run in isolation, networking equipment, etc. -- having hardware RNGs available is a really big win, because there is no good local source of randomness. (We had a long discussion of ways to mitigate this some time ago.) Plugging in an external unit is not going to happen in practice. If it isn't nearly free and built in, it won't be used. IPsec gateways and web servers doing a lot of SSL are obvious cases. Neither has much mouse or keyboard activity, they may have solid state drives or smart RAID so disk timings are not random. Packet timings might be somewhat random, but they may also be knowable by an enemy. I would suggest that in most cases, you are better off with a very very mildly untrusted but ubiquitous hardware RNG than with the kinds of kludges to get random numbers on unattended hardware we end up with in the real world. In some cases, a non-kludge alternative is Turbid: http://www.av8n.com/turbid/paper/turbid.htm That uses a sound card or on-board equivalent. Some boards will have this, or it is cheap easy to stick in a slot. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
MITM attack against WPA2-Enterprise?
There is a claim of a flaw in WPA2-Enterprise -- see http://wifinetnews.com/archives/2010/07/researchers_hints_8021x_wpa2_flaw.html --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A Fault Attack Construction Based On Rijmen's Chosen-Text Relations Attack
Alfonso De Gregorio wrote: The last Thursday, Vincent Rijmen announced a new clever attack on AES (and KASUMI) in a report posted to the Cryptology ePrint Archive: Practical-Titled Attack on AES-128 Using Chosen-Text Relations, http://eprint.iacr.org/2010/337 On 7/21/10 at 11:49 AM, d...@cs.berkeley.edu (David Wagner) wrote, with some drastic editing which I hope doesn't change David's meaning: For what it's worth, I read Vincent Rijmen's paper ... as written with tongue embedded firmly in cheek: I took it as a serious argument, hidden behind some gentle humor. ... Personally, I found it an effective communication style. I thought the point came across very clearly. And, I have to admit I enjoyed seeing someone having a spot of fun with what can otherwise be a somewhat dry topic. I thought it was brilliantly done. My favorite paper in this style is one which has not (yet) been published. It turns out that at one time there were at least three Mark Millers active in computer science. One of them, cced above, wanted to publish a paper: Global Names Considered Harmful by Mark Miller, Mark Miller, and Mark Miller And the paper really doesn't need to go any further than this. Cheers - Bill --- Bill Frantz| I like the farmers' market | Periwinkle (408)356-8506 | because I can get fruits and | 16345 Englewood Ave www.pwpconsult.com | vegetables without stickers. | Los Gatos, CA 95032 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MITM attack against WPA2-Enterprise?
On Sat, 24 Jul 2010 20:38:07 -0400 Steven Bellovin s...@cs.columbia.edu wrote: There is a claim of a flaw in WPA2-Enterprise -- see http://wifinetnews.com/archives/2010/07/researchers_hints_8021x_wpa2_flaw.html Not quite a MITM attack. It is quite clever, though as with most such things, it seems in retrospect to be obvious. If only we always had hindsight. Quoting from another article: The Advanced Encryption Standard (AES) derivative on which WPA2 is based has not been cracked and no brute force is required to exploit the vulnerability, Ahmad says. Rather, a stipulation in the standard that allows all clients to receive broadcast traffic from an access point (AP) using a common shared key creates the vulnerability when an authorized user uses the common key in reverse and sends spoofed packets encrypted using the shared group key. http://www.networkworld.com/newsletters/wireless/2010/072610wireless1.html?page=1 All in all, this looks bad for anyone depending on WPA2 for high security. -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MITM attack against WPA2-Enterprise?
Perry E. Metzger writes: All in all, this looks bad for anyone depending on WPA2 for high security. Luckily, that describes nobody, right? ;D I used to think that non-end-to-end security mechanisms were wastefully pointless, but adorably harmless. However, in my experience people keep using link-layer garbage (and network-layer trash, and support protocol junk) as a way to put off the hard work of real (i.e. E2E) security. Non-E2E stuff hurts usability, availability, and security (by creating a false sense). Of course, we E2E fans have to get our usable security ducks in a row first. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MITM attack against WPA2-Enterprise?
It's always possible to make protocols more secure at higher cost. Should 802.11i have required one-time pads to be couriered to all mobile stations involved? Probably not, since it would kind of negate some of the benefits of Wi-Fi. For group keys, should it have added another layer of security where, say, a public was transmitted by the AP to each station using pairwise security and the AP signed and all stations verified every multicast/broadcast frame? Possible, but public key cryptography is a pretty big burden if you are, for example, streaming video to multiple stations using multicast. Seems like it would need significant hardware support. Anyway, if these people have found some clever way to use the fact that the group key is a shared secret key, that might be interesting. I don't see how it is clever or particularly interesting that they are able to read the standards document and understand one of the deliberate engineering compromises in 802.11i. (Actually, there 802 standards documents can be somewhat arcane... Maybe you do have to be clever to be able to understand them... :-) If you don't like Wi-Fi security, then also use IPSec or something for all the data you send through it. Thanks, Donald On Sun, Jul 25, 2010 at 6:08 PM, Perry E. Metzger pe...@piermont.comwrote: On Sat, 24 Jul 2010 20:38:07 -0400 Steven Bellovin s...@cs.columbia.edu wrote: There is a claim of a flaw in WPA2-Enterprise -- see http://wifinetnews.com/archives/2010/07/researchers_hints_8021x_wpa2_flaw.html Not quite a MITM attack. It is quite clever, though as with most such things, it seems in retrospect to be obvious. If only we always had hindsight. Quoting from another article: The Advanced Encryption Standard (AES) derivative on which WPA2 is based has not been cracked and no brute force is required to exploit the vulnerability, Ahmad says. Rather, a stipulation in the standard that allows all clients to receive broadcast traffic from an access point (AP) using a common shared key creates the vulnerability when an authorized user uses the common key in reverse and sends spoofed packets encrypted using the shared group key. http://www.networkworld.com/newsletters/wireless/2010/072610wireless1.html?page=1 All in all, this looks bad for anyone depending on WPA2 for high security. -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Hi Peter, I like your humorous subject line. After reading your email, I thought of my own humorous twist on a phrase from the same tradition: Doth our crypto community judge any CA, before it hear him, and know what he doeth? Readers are cordially invited to go to https://edgecastcdn.net and have a look at the subjectAltName extension in the certificate that it presents. An extract is shown at the end of this message, this is just one example of many like it. I'm not picking on Edgecast specifically, I just used this one because it's the most Sybilly certificate I've ever seen. I challenge your Sybil characterization. Wikipedia's definition: The Sybil attack in computer security is an attack wherein a reputation system is subverted by forging identities in peer-to-peer networks. It is named after the subject of the book Sybil, a case study of a woman with multiple personality disorder. A Sybil attack is one in which an attacker subverts the reputation system of a peer-to-peer network by creating a large number of pseudonymous entities, using them to gain a disproportionately large influence... In this context (SSL cert with many SAN entries for hosted CDN clients) I see these differences: a) Identities are not being forged. Each FQDN in the certificate is specifically authorized by the entity owning the domain in question. b) The entities are *not* pseudonymous -- nobody is using sound-alike or look-alike domain names in there. c) There is no attempt to gain large influence. Just to serve content over HTTPS. The only part that seems to fit is that this kind of certificate presents multiple personalities, however there is no intention to fool end-users. You'll find that this one Sybil certificate, among its hundred-and-seven hostnames, includes everything from Mozilla, Experian, the French postal service, TRUSTe, and the Information Systems Audit and Control Association (ISACA), through to Chainlove, Bonktown, and Dickies Girl (which aren't nearly as titillating as they sound, and QuiteSFW). Since this is a certificate we (DigiCert) have issued, I'm trying to understand if there is a vulnerability here that's more apparent to others than to me, or if we're looking at something that is more an issue of taste. If there is a vulnerability, I hope to understand its precise nature first, instead of taking a shoot first, ask questions later approach. The bulk of the FQDNs included in the certificate are for subdomains like media., www-cdn., static., and the like. Apply a different test: Is it bad for various organizations to use the same CDN for services over http? Is it bad for all those different FQDNs to CNAME to the same DNS entry and point to the same IP address? Is it bad for a CDN to host multiple individual SSL certificates for its customers on the same set of hardware? If not, then what is so abhorrent about their various FQDNs being included in a single SSL certificate? If it is considered safe to pass HTTP through your CDN, and it is considered safe to pass your HTTPS through a unique SSL certificate on your CDN, why does it cross the line when you put more than one FQDN into one certificate? Still, who needs to compromise a CA when you have these things floating around on multihomed hosts and CDNs. If you have 100 SSL sites to host, and they're going to live on a shared platform, is it safer to use an individual certificate for each site? If a hacker were to compromise your servers and have root access to your filesystem, would individual certificates present a hurdle versus a single certificate with 100 SAN entries? (Side note: It is a fair amount easier to manage the whole list in one certificate, and if needed to revoke one certificate in the event of a compromise than to hunt down and revoke all affected serials of individual certificates.) Considering the vulnerability landscape, is it safe to assume that there will be more opportunities for exploiting vulnerabilities in web applications and 3rd party packages at the origin level where the actual web application code is executed than at the CDN level where no PHP/ASP/Java/etc is allowed to run? There is a security maxim that says Complexity is the enemy of security. If you turn that around, into Simplicity is the friend of security, can it be argued that a CDN will generally be less likely to contain things like file disclosure vulnerabilities simply by virtue of running less application code? Considering the business incentives landscape, is it safe to assume a strong incentive for a CDN running all those sites to be vigilant about their own server security? Are there any inherently skewed incentives that I'm just not seeing which would lead a CDN to be negligent in its management of its network security and the SSL certificates it manages? I've spoken with my contacts at Edgecast, and they expressed that they're very willing to
Re: MITM attack against WPA2-Enterprise?
On Sun, 25 Jul 2010 18:48:56 -0400 Donald Eastlake d3e...@gmail.com wrote: It's always possible to make protocols more secure at higher cost. Should 802.11i have required one-time pads to be couriered to all mobile stations involved? Probably not, since it would kind of negate some of the benefits of Wi-Fi. For group keys, should it have added another layer of security where, say, a public was transmitted by the AP to each station using pairwise security and the AP signed and all stations verified every multicast/broadcast frame? Possible, but public key cryptography is a pretty big burden if you are, for example, streaming video to multiple stations using multicast. Seems like it would need significant hardware support. I think the fact that the protocol appears to allow people to impersonate the base station, order clients to use new keys, and then man in the middle all subsequent communications with little effort makes the per-endpoint keying largely moot. This does not seem like a minor defect. There is no need to use public key crypto to solve this, of course. A Needham-Schroeder protocol would seem to be sufficient, and would not require public key. Anyway, if these people have found some clever way to use the fact that the group key is a shared secret key, that might be interesting. I don't see how it is clever or particularly interesting that they are able to read the standards document and understand one of the deliberate engineering compromises in 802.11i. I don't know, if it is truly only a ten line change to a common WPA2 driver to read, intercept and alter practically any traffic on the network even in enterprise mode, that would seem like a serious issue to me. Setting up the enterprise mode stuff to work is a lot of time and effort. If it provides essentially no security over WPA2 in shared key mode, one wonders what the point of doing that work is. This doesn't seem like a mere engineering compromise. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
