[Note: the following is primarily about U.S. Government policies, but I believe several points can be generalized to other countries.]

I was editing a section of my website, when I ran across a link to a paper I had forgotten that I wrote. I'm unsure how many people actually saw it then or since. I know it faded from my memory! Other than CERIAS WWW sites and the AAAS itself, a Google search reveals almost no references to it.

As background, in early April of 2002, I was asked, somewhat at the last moment, to prepare a paper and some remarks on the state of information security for a forum, Technology in a Vulnerable World, held on science in the wake of 9/11. The forum was sponsored by the AAAS, and held later that month. There were interesting papers on public health, risk communication, the role of universities, and more, and all of them are available for download.

My paper in the forum wasn't one of my better ones, in that it was somewhat rushed in preparing it. Also, I couldn't find good background literature for some of what I was writing. As I reread what I wrote, many of the points I raised still don't have carefully documented sources in the open literature. However, I probably could have found some published backup for items such as the counts of computer viruses had I spent a little more time and effort on it. Mea culpa; this is something I teach my students about. Despite that, I think I did capture most of the issues that were involved at the time of the forum, and I don't believe there is anything in the paper that was incorrect at that time.

Why am I posting something here about that paper, One View of Protecting the National Information Infrastructure, written seven years ago? Well, as I reread it, I couldn't help but notice that it expressed some of the same themes later presented in the PITAC report, Cyber Security: A Crisis of Prioritization (2005), the NRC report Towards a Safer and More Secure Cyberspace (2007), and my recent Senate testimony (2009). Of course, many of the issues were known before I wrote my paper -- including coverage in the NRC studies Computers at Risk: Safe Computing in the Information Age (1991), Trust in Cyberspace (1999) and Cybersecurity Today and Tomorrow (2002) (among others I should have referenced). I can find bits and pieces of the same topics going further back in time. These issues seem to be deeply ingrained.

I wasn't involved in all of those cited efforts, so I'm not responsible for the repetition of the issues. Anyone with enough background who looks at the situation without a particular self-interest is going to come up with approximately the same conclusions -- including that market forces aren't solving the problem, there aren't enough resources devoted to long-term research, we don't have enough invested in education and training, we aren't doing enough in law enforcement and active defense, and we continue to spend massive amounts trying to defend legacy systems that were never designed to be secure.

Given these repeated warnings, it is troubling that we have not seen any meaningful action by government to date. However, that is probably preferable to government action that makes things worse: consider DHS as one notable example (or several).

Compounding the problem, too many leaders in industry are unwilling to make necessary, radical changes either, because such actions might disrupt their businesses, even if such actions are in the public good. It is one of those "tragedy of the commons" situations. Market forces have been shown to be ineffective in fixing the problems, and will actually lead to attempts to influence government against addressing urgent needs. Holding companies liable for their bad designs and mistakes, or restricting spending on items with known vulnerabilities and weaknesses would be in the public interest, but too many vendors affected would rather lobby against change than to really address the underlying problems.

Those of us who have been observing this problem for so long are therefore hoping that the administration's 60 day review provides strong impetus for meaningful changes that are actually adopted by the government. Somewhat selfishly, it would be nice to know that my efforts in this direction have not been totally in vain. But even if nothing happens, there is a certain sense of purpose in continuing to play the role of Don Quixote.

Sancho! Where did I leave my horse?

Why is it that Demotivators® seem so appropriate when talking about cyber security or government? If you are unfamiliar with Despair.com, let me encourage you to explore the site and view the wonderfully twisted items they have for sale. In the interest of full disclosure, I have no financial interest or ties to the company, other than as a satisfied and cynical customer.

On a more academic note, you can read or purchase the NRC reports cited above online via the National Academies Press website.

Yesterday, I posted a long entry on the recent news about how some researchers obtained a “rogue” certificate from one of the Internet Certificate Authorities. There are some points I missed in the original post that should be noted.

 
• The authors of the exploit have a very readable, interesting description of what they did and why it worked. I should have included a link to it in the original posting, but forgot to edit it in. The interested reader should definitely see that article online, include the animations.
 
• There are other ways this attack can be defeated, certainly, but they are stop-gap measures. I didn’t explain them because I don’t view them as other than quick patches. However, if you are forced to continue to use MD5 and you issue certificates, then it is important to randomize the certificate serial number that is issued, and to insert a random delay interval in the validity time field. Both will introduce enough random bits so as to make this particular attack against the CA infeasible given current technology.
 
• I suggested that vendors use another hash algorithm, and have SHA-1 as an example. SHA-2 would be better, as SHA-1 has been shown to have a theoretical weakness similar to MD5, although it has proven more resistant to attack to date. Use of SHA-1 could possible result in a similar problem within a few years (or, as suggested in the final part of my post, within a few weeks if a breakthrough occurs). However, use of SHA-1 would be preferable to MD5!
 
• MD5 is not “broken” in a complete way. There are several properties of a message digest that are valuable, including collision resistance: that it is infeasible to end up with two inputs giving the same hash value. To the best of my knowledge, MD5 has only been shown to be susceptible to “weak collisions”—instances where the attacker can pick one or both inputs so as to produce identical hash values. The stronger form of preimage resistance, where there is an arbitrary hash output H and an attacker cannot form an input that also produces H, still holds for MD5. Thus, applications that depend on this property (including many signing applications and integrity tools) are apparently still okay.
 
• One of our recent PhD grads, William Speirs, worked on defining hash functions for his PhD dissertation. His dissertation, Dynamic Cryptographic Hash Functions, is available online for those interested in seeing it.

I want to reiterate that there are more fundamental issues of trust involved than what hash function is used. The whole nature of certificates is based around how much we trust the certificate authorities that issue the certificates, and the correctness of the software that verifies those certificates then shows us the results. If an authority is careless or rogue, then the certificates may be technically valid but not match our expectations for validity. If our local software (such as a WWW browser) incorrectly validates a certificate, or presents the results incorrectly, we may trust a certificate we shouldn’t. Even such mundane issues as having one’s system at the correct time/date can be important: the authors of this particular hack demonstrated that by backdating their rogue certificate.

My continuing message to the community is to not lose sight of those things we assume. Sometimes, changes in the world around us render those assumptions invalid, and everything built on them becomes open to question. If we forget those assumptions—and our chains of trust built on them—we will continue to be surprised by the outcomes.

That is perhaps fitting to state (again) on the last day of the year. Let me observe that as human beings we sometimes take things for granted in our lives. Spend a few moments today (and frequently, thereafter) to pause and think about the things in your life that you may be taking for granted: family, friends, love, health, and the wonder of the world around you. Then as is your wont, celebrate what you have.

Best wishes for a happy, prosperous, safe—and secure—2009.

[12/31/08 Addition]: Steve Bellovin has noted that transition to the SHA-2 hash algorithm in certificates (and other uses) would not be simple or quick. He has written a paper describing the difficulties and that paper is online.

There are several news stories now appearing (e.g., Security News) about a serious flaw in how certificates used in online authentication are validated. Ed Felten gives a nice summary of how this affects online WWW site authentication in his Freedom to Tinker blog posting. Brian Krebs also has his usual readable coverage of the problem in his Washington Post article. Steve Bellovin has some interesting commentary, too, about the legal climate.

Is there cause to be concerned? Yes, but not necessarily about what is being covered in the media. There are other lessons to be learned from this.

Short tutorial

First, for the non-geek reader, I’ll briefly explain certificates.

Think about how, online, I can assure myself that the party at the other end of a link is really who they claim to be. What proof can they offer, considering that I don’t have a direct link? Remember that an attacker can send any bits down the wire to me and may access to faster computers than I do.

I can’t base my decision on how the WWW pages appear, or embedded images. Phishing, for instance, succeeds because the phishers set up sites with names and graphics that look like the real banks and merchants, and users trust the visual appearance. This is a standard difficulty for people—understanding the difference between identity (claiming who I am) and authentication (proving who I am).

In the physical world, we do this by using identity tokens that are issued by trusted third parties. Drivers licenses and passports are two of the most common examples. To get one, we need to produce sufficient proof of identity to a third party to meet its standards of proof. Then, the third party issues a document that is very difficult to forge (almost nothing constructed is impossible to forge or duplicate—but some things require so much time and expenditure it isn’t worthwhile). Because the criteria for proof of identity and strength of construction of the document are known, various other parties will accept the document as “proof” of identity. Of course, other problems occur that I’m not going to address—this USACM whitepaper (of which I was principal author) touches on many of them.

Now, in the online world we cannot issue or see physical documents. Instead, we use certificates. We do this by putting together an electronic document that gives the information we want some entity to certify as true about us. The format of this certificate is generally fixed by standards, the most common one being the X.509 suite. This document is sent to an organization known as a Certificate Authority (CA), usually along with a fee. The certificate authority is presumably well-known, and performs a check (to their own standards) that the information in the document is correct, and it has the right form. The CA then calculate a digital hash value of the data, and creates a digital signature of that hash value. This is then added to the certificate and sent back to the user. This is the equivalent of putting a signature on a license and then sealing it in plastic. Any alteration of the data will change the digital hash, and a third party will find that the new hash and the hash value signed with the key of the CA don’t match. The reason this works is that the hash function and encryption algorithm used are presumed to be so computationally difficult to forge that it is basically not possible.

As an example of a certificate , if you visit “https://www.cerias.purdue.edu” you can click on the little padlock icon that appears somewhere in the browser window frame (this is browser dependent) to view details of the CERIAS SSL certificate.

You can get more details on all this by reading the referenced Wikipedia pages, and by reading chapters 5 & 7 in Web Security, Privacy and Commerce.

Back to the hack

In summary, some CAs have been negligent about updating their certificate signing mechanisms in the wake of news that MD5 is weak, published back in 2004. The result is that malicious parties can generate and obtain a certificate “authenticating” them as someone else. What makes it worse is that the root certificate of most of these CAs are “built in” to browser and application trust lists to simplify look-up of new certificates. Thus, most people using standard WWW browsers can be fooled into thinking they have connected to real, valid sites—even through they are connecting to rogue sites.

The approach is simple enough: a party constructs two certificates. One is for the false identity she wishes to claim, and the other is real. She crafts the contents of the certificate so that the MD5 hash of the two, in canonical format, is the same. She submits the real identity certificate to the authority, which verifies her bona fides, and returns the certificate with the MD5 hash signed with the CA private key. Our protagonist then copies that signature to the false certificate, which has the same MD5 hash value and thus the same digital signature, and proceeds with her impersonation!

What makes this worse is that the false key she crafts is for a secondary certificate authority. She can publish this in appropriate places, and is now able to mint as many false keys as she wishes—and they will all have signatures that verify in the chain of trust back to the issuer! She can even issue these new certificates using a stronger hash algorithm than MD5!

What makes this even worse is that it has been known for years that MD5 is weak, yet some CAs have continued to use it! Particularly unfortunate is the realization that Lenstra, Wang and de Weger described how this could be done back in 2005. Methinks that may be grounds for some negligence lawsuits if anyone gets really burned by this….

And adding to the complexity of all this is the issue of certificates in use for other purposes. For example, certificates are used with encrypted S/MIME email to digitally sign messages. Certificates are used to sign ActiveX controls for Microsoft software. Certificates are used to verify the information on many identity cards, including (I believe) government-issued Common Access Cards (CAC). Certificates also provide identification for secured instant messaging sessions (e.g., iChat). There may be many other sensitive uses because certificates are a “known” mechanism. Cloud computing services , software updates, and more may be based on these same assumptions. Some of these services may accept and/or use certificates issued by these deficient CAs.

Fixes

Fixing this is not trivial. Certainly, all CAs need to start issuing certificates based on other message digests, such as SHA-1. However, this will take time and effort, and may not take effect before this problem can be exploited by attackers. Responsible vendors will cease to issue certificates until they get this fixed, but that has an economic impact some many not wish to incur.

We can try to educate end-users about this, but the problem is so complicated with technical details, the average person won’t know how to actually make a determination about valid certificates. It might even cause more harm by leading people to distrust valid certificates by mistake!

It is not possible to simply say that all existing applications will no longer accept certificates rooted at those CAs, or will not accept certificates based on MD5: there are too many extant, valid certificates in place to do that. Eventually, those certificates will expire, and be replaced. That will eventually take care of the problem—perhaps within the space of the next 18 months or so (most certificates are issued for only a year at a time, in part for reasons such as this).

Vendors of applications, and especially WWW browsers, need to give careful thought about updates to their software to flag MD5-based certificates as deserving of special attention. This may or may not be a worthwhile approach, for the reason given above: even with a warning, too few people will be able to know what to do.

Bigger issue

We base a huge amount of trust on certificates and encryption. History has shown how easy it is to get implementations and details wrong. History has also shown how quickly things can be destabilized with advances in technology.

In particular, too many people and organizations take for granted the assumptions on which this vast certificate system is based. For instance, we assume that the hash/digest functions in use are computationally difficult to reverse or cause collisions. We also assume that certain mathematical functions underlying public/private key encryption are too difficult to reverse or “brute force.” However, all it takes is some new insight or analysis, or maybe new, affordable technology (e.g., practical quantum computing, or massively parallel computing) to violate those assumptions.

If you look at the way our systems are constructed, too little thought is given to what happens to existing infrastructure when something breaks. Designs can include compensating and recovery code, but doing so requires some cost in space or time. However, all too often people are willing to avoid the investment by putting off the danger to “if and when that happens.” Thus, we instance such as the Y2K problems and the issues here with potentially rogue CAs.

(I’ll note as an aside, that when I designed the original version of Tripwire and what became the Signacert product, I specifically included simultaneous use of several different message digest functions in different families for this very reason. I knew it was a matter of time before one or two were broken. I still believe that it is beyond reason to find files that will match multiple, different algorithms simultaneously.)

Another issue is the whole question of who we trust, and for what. As noted in the USACM whitepaper, authentication is always relative to a third party. How much do we trust those third parties? How much trust have we invested in the companies and agencies issuing certificates? Are they properly verifying identities? How good is there internal security? How do we know, and how much is at risk from our trust in those entities?

Let me leave you with a final thought. How do we know that this problem has not already been quietly exploited? The basic concept has been in the open literature for years. The general nature of this attack on certificates has been known for well over a decade, if not two. Given the technical and infrastructure resources available to national agencies and organized criminals, and given the motivation to use this hack selectively and quietly, how can we know that it is not already being used?

[Added 12/31/2008]: A follow-up post to this one is available in the blog.

[tags]interview,certification[/tags]I was recently interviewed by Gary McGraw for his Silver Bullet interview series.  He elicited my comments on a number of topics, including security testing, ethical hacking, and why security is difficult.If you like any of my blog postings, you might find the interview of some interest.  But if not, you might some of the other interviews of interest – mine was #18 in the series.

[tags]Windows,MacOS, security flaws, patches, press coverage[/tags]
There’s been a lot of froth in the press about a vulnerability discovered in a “Hack the Mac” contest conducted recently.  (Example stories here and here.)  I’m not really sure where this mini-hysteria is coming from—there isn’t really anything shocking here.

First of all, people shouldn’t be surprised that there are security flaws in Apple products.  After all, those are complex software artifacts, and the more code and functionality present, the more likely it is the case that there will be flaws present—including serious flaws leading to security problems.  Unless special care is taken in design and construction (not evident in any widely-used system) vulnerabilities are likely to be present.

Given that, the discovery of one serious flaw doesn’t necessarily mean there are hundreds more lurking beneath the surface and that MacOS X is as bad (or worse) than some other systems.  Those bloggers and journalists who have some vulture genomes seem particularly prone to making sweeping announcements after each Apple-based flaw (and each Linux bug) is disclosed or a story about vulnerabilities is published.  Yes, there are some problems, and there are undoubtedly more yet to be found.  That doesn’t mean that those systems are inherently dangerous or even as buggy and difficult to protect as, for example, Windows XP.  Drawing such conclusions based on one or two data points is not appropriate; these same people should likewise conclude that eating at restaurants anywhere in the US is dangerous because someone got food poisoning at a roadside stand in Mexico last year!

To date, there appear to be fewer flaws in Apple products than we have seen in some other software.  Apple MacOS X is built on a sturdy base (BSD Unix) and doesn’t have a huge number of backwards compatibility features, which is often a source of flaws in other vendors’ products.  Apple engineers, too, seem to be a little more careful and savvy about software quality issues than other vendors, as least as evidenced by the relative number of crashes and “blue screen” events in their products.  The result is that MacOS X is pretty good right out of the box.

Of course, this particular flaw is not with MacOS X, but with Java code that is part of the Quicktime package for WWW browsers.  The good news is that it is not really a MacOS problem; the bad news is that it is a serious bug that got widely distributed; and the worse news is that it potentially affects other browsers and operating systems.

I have been troubled by the fact that we (CERIAS, and before that COAST) have been rebuffed on every attempt over the last dozen years to make any contact with security personnel inside Apple.  I haven’t seen evidence that they are really focused on information security in the way that other major companies such as Sun, HP and Microsoft are, although the steady patching of flaws that have not yet been widely reported outside the company does seem to indicate some expertise and activity somewhere inside Apple.  Problems such as this Quicktime flaw don’t give warm fuzzy feelings about that, however.

Apple users should not be complacent.  There are flaws yet to be discovered, and users are often the weakest link.  Malware, including viruses, can get into MacOS X and cause problems, although they are unlikely to ever be of the number and magnitude as bedevil Windows boxes (one recent article noted that vendors are getting around 125 new malware signatures a day—the majority are undoubtedly for Windows platforms).  And, of course, Mac machines (and Linux and….) also host browsers and other software that execute scripts and enable attacks.  Those who use MS Word have yet more concerns. 

The bottom line. No system is immune to attacks.  All users should be cautious and informed.  Apple systems still appear to be safer than their counterparts running Windows XP (the jury is out on Vista so far), and are definitely easier to maintain and use than similarly secured systems running Linux.  You should continue to use the system that is most appropriate for your needs and abilities, and that includes your abilities to understand and configure security features to meet your security needs.  For now, my personal systems continue to be a MacBook Pro (with XP and Vista running under Parallels) and a Sun Solaris machine.  Your own milage should—and probably will—vary.