Superconductor

Lost knowledge

It was big news last year when Ed Felton’s group of security researchers released their paper “Lest We Remember: Cold Boot Attacks on Encryption Keys” in which they described at attack on full-disk encryption based on freezing DRAM and reading its contents before they’re lost. There was lots of media hype around this paper, with some people making claims like “full-disk encryption is totally non-secure.”

The fact that this paper was considered newsworthy is interesting in itself, and the interest in the so-called “cold boot” attack probably says more about how the background of information security professionals has changed over the past 20 years than it says about the security of full-disk encryption.

Security-conscious organizations like banks and governments have known for quite a while that it’s possible to recover cryptographic keys from DRAM. That’s why the standards that they’ve written often require the use of a hardware security modules to protect keys. So if it’s been known for quite a while that it’s easy to recover keys from DRAM, why the interest in the cold boot attack?

The reason for the interest is probably due to the way that background of the typical person who works in information security these days differs from their counterpart in the past. If you go back 20 years or so, the typical information security professional had a background in electrical engineering. If you study electrical engineering, attacks based on freezing DRAMs are fairly obvious. So are side-channel attacks, ways to recover cryptographic keys from physical measurements of operating cryptographic hardware. If you’ve designed and built hardware, the fact that the timing of calculations or the power consumed during calculations depends on the exact bits being processed is fairly obvious.

Today, however, the typical person who works in information security has a background in computer science. This means that they probably know a fair amount designing and writing software, but it also means that they probably don’t know much about hardware. And because they don’t know much about hardware, they’re often surprised by the properties of hardware that allow a cold boot attack to be carried out. It’s also why side-channel attacks aren’t that widely understood these days.

This doesn’t mean that today’s information security professionals are worse or inferior to those of 20 years ago. Instead, it just means that they know different things. If you go back 20 years, you’ll find that things like buffer overflow attacks, SQL injection attacks, or cross-site scripting attacks were totally unknown, but they’re fairly widely known today. They’re probably examples of the knowledge that’s replaced the understanding of hardware that was there in the past.

Add some rigor to information security

If you read scientific papers, you’ll find that there's a fair amount of precision in the way that data is analyzed, and that there’s a generally-accepted methodology for doing the analysis. This level of rigor is almost completely absent from studies about both the threats that information security deals with and the effectiveness of security technologies that address these threats. This makes making good decisions about information security harder than it needs to be.

Consider the fact that most people have an above-average number of legs. This is true, isn’t it? Most people have two legs, but a small number have either one or zero legs, so the average number of legs per person is probably close to 1.999. This means that most people actually do have an above-average number of legs. Without additional information about the distribution of the number of legs, it’s easy to jump to incorrect conclusions or to give unnecessary weight to this statement.

Similarly, it’s easy to create meaningless statistics about security. Suppose that most businesses have only one unit of security, but a few lucky ones have two units of security, making the average level of security close to 1.001. In this case, we can say that most businesses have a below-average level of security, can’t we? We can then act shocked that so many businesses don’t take security seriously. We might even try to lobby the government to create regulations that require a higher level of security as a way to address this problem. Without a more careful analysis of the data, it’s possible to reach conclusions that don’t make much sense.

So the next time a security vendor or industry analyst quotes statistics about threats or the effectiveness of security technologies, be sure to ask them for some additional detail to make sure that they are really telling you the full story. If they tell you what an average value is, ask them what the variance or standard deviation of the value is. If they show a model that predicts something, ask them about the sensitivity analysis that they did for the model. If they can’t answer questions like those, the numbers that they’re quoting may not be very useful.

There’s not much information available about threats or the effectiveness of security technologies, but there’s no reason to accept careless or sloppy analysis of the data that is available.

Avoid large data breaches - if you can

What happens after a data breach? Is the data recovered, or does it stay lost? Do lawsuits typically follow a breach? These statistics aren't widely known, but we can find reasonable estimates for them by looking at the a database of almost 2,000 data breaches that's available at datalossdb.org.

It turns out that the lost data is only recovered about 5 percent of the time. Usually, it's never seen again.

Oddly enough, lawsuits are even rarer, and only happen about 3 percent of the time.

For larger breaches, these statistics are quite different.

For data breaches that expose 1 million records or more, the data is recovered about 18 percent of the time and lawsuits happen 68 percent of the time.

Avoid those big breaches if you can.

Do you really need 256 bit AES?

Eric Rescorla, a noted security expert that we are honored to have on our advisory board, offers up a cogent analysis of the issue of AES-128 vs AES-256, an issue that we see many of our customers considering.  Definitely worth a read.

Why hackers hack

In his autobiography, Nobel Laureate Luis Alvarez said that he believes that one trait that a good scientist has to have is a passion for finding answers, even if there are obstacles in their way. He said that they'll ignore a "KEEP OUT" sign on a door if they really want to know what's behind it. This also seems to be a defining trait of many information security professionals, some of which are probably even motivated by a "KEEP OUT" sign to do things that they wouldn't otherwise do. This was certainly true of old-school hackers, although it may not be the case anymore.

When I worked for the government, I once had a class in how to open locks and safes. The final exam for this class included opening a four-wheel safe lock, the case of which was protected by a tamper-evident holographic seal. The seal was probably there to keep you from opening the lock to find what its combination was, although that was never explicitly stated. We were just told that we had to open the lock within four hours.

I probably wouldn't have thought to open the lock's case if the seal wasn't there, but I took the seal to be an interesting challenge (I hadn't had that particular class yet) and decided to try to beat it. This turned out to much easier than actually opening a lock by manipulation, which is actually fairly tedious once you know how to do it, and I finished by test well ahead of schedule.

I wasn't trying to finish my test faster by bypassing the tamper-evidenet seal; I did it just because it was an interesting challenge. That outlook was common in old-school hackers, who took security as a challenge and typically didn't do anything malicious once they defeated whatever security mechanisms that they came across.

Today, however, hacking is big business, and many people who do it are motivated by money instead by the intellectual challenge that bypassing security mechanisms poses. These days, instead of just looking behind the door labeled "KEEP OUT" and thinking, ah, this stairway leads to the roof, people are doing the equivalent of blowing the door to the safe and taking the money that's in it. Curiosity isn't the driver any more. Now it's just greed.

Thursday at the RSA Conference

Hackers are clever, and they’ll find a way to exploit almost anything. One example of this is how they’ve learned to use blogs to distribute spam and other malware. But for every hacker finding a new way to carry out attacks, there’s apparently a security vendor coming up with a response. At the RSA Conference this week, I saw some interesting demos of the counters that security vendors have created to the problem of hackers using blogs to help them carry out attacks.

In most cases, spam email outnumbers legitimate email by a huge margin. This seems to be true with comments that are posted to blogs also. If I go to the management console for this blog, for example, I now see over 3,400 attempts by spammers to get this blog to link their sites that claim to be selling interesting products, but are probably just trying to collect sensitive personal information. Looking through a queue of over 3,400 items just isn’t feasible, but security vendor Websense has a product that will do this for you, and in most cases, they’ll actually do this for free.

This product is Defensio, and I saw a demo of it at the RSA Conference yesterday. Websense claims to have sophisticated adaptive algorithms that let their technology adapt to the efforts of spammers to bypass their filtering. That’s not the sort of thing that’s easy to show in a demo, so I’ll have to trust that this really happens behind the scenes.

Defensio works by routing potential malicious posts through Defensio’s servers, which make a decision about whether or not the post is spam. This architecture also lets Defensio identify and react to new attacks on blogs as they’re developed and used by hackers. I seem to recall that anti-virus products worked this way at one time, but anti-virus vendors seem to have now discarded this model. It will be interesting to see if this also happens to Defensio’s technology in the future.

Unfortunately, Defensio is only available for blogs that are hosted by WordPress. This blog uses TypePad, which means that I can’t actually try it and see how well it works in practice.

In addition to blogs, it seems that newer social networking services like Twitter have already been abused by hackers. Twitter users are already receiving spam (twam?), and if you follow the Twitter user @spam, you’ll see updates on how this spam is happening, who it’s coming from, etc. You might even find it amusing that when you visit the Twitter page for the user @spam, you see the message “Hey there! spam is using Twitter.”

Maybe there’s a start-up out there right now that’s figuring out a way to keep Twitter uncluttered. I’ll have to look for this at next year’s RSA Conference.

Cloud security at the RSA Conference

Cloud computing seems to be one of the hot topics at this year’s RSA Conference, and many vendors seem to be trying to position themselves as leaders in “cloud security” in some way. I also heard several times in various presentations that cloud computing causes absolutely no additional security vulnerabilities, and that the real challenges of cloud computing are going to come from dealing with regulatory compliance issues.

It may be tricky to address data lineage (tracking data as it flows through an enterprise), data provenance (tracking the origin of data) and related issues, for example, if data is held in a cloud, yet these can be required by some regulations. These can certainly be considered parts of data integrity that information security products address, but not many vendors seemed to be looking at cloud security from that point of view. Until these issues are addressed, the data that’s suitable for being handled by cloud computing is probably limited to non-sensitive, non-regulated data - unless pro-active security measures e.g. end-to-end encryption are incorporated. Our own security SaaS solution, the Voltage Security Network, avoids data protection issues by not touching any content - simply providing keys for encrypting emails and documents.

Key management at the RSA Conference

There are lots of free copies of the latest issue of InformationWeek magazine floating around at this week's RSA Conference. I picked one of these up and looked at it because of the article that was featured on the cover: “Standards Matter.” Here's an interesting quote from this article:

If we’re not careful, standards for nascent technologies could be so splintered as to be worse than none at all.

This reminded me that the first meeting of the OASIS Key Management Interoperability Protocol (KMIP) Technical Committee is going to be this Friday. KMIP is probably the best example that you can think of for splintering standards that might turn out to be worse than none at all. The IEEE Security in Storage Working Group (SISWG) is already well underway with the P1619.3 Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data. The most recent project plan that I’ve seen for this standard shows it being completed late this year. SISWG plans to define two versions of its key management protocol in the P1619.3 standard: one that’s XML-based and another that’s TLV-based.

Oddly enough, an XML version and a TLV version also seems to be the plan for KMIP, which certainly should make you wonder exactly why KMIP is really needed. I seem to recall that the whole point of developing a standard for key management was to ensure interoperability between products from different vendors, and having two different standards for the same thing seems like the worst possible way to do this.

It certainly looks like IBM is responsible for the splintering into multiple and non-interoperable key management standards that the InformationWeek article talks about. They’re really the one behind the KMIP effort, even though they’re also involved in SISWG. It would be interesting to hear what their reason for essentially killing the possibility of interoperable key management was. Didn’t they like the direction that P1619.3 was moving in? If that’s the case, why didn’t they just speak up and make their opinion known? And do they really think that having two non-interoperable key management standards benefits anyone?

These questions shouldn't just be on a security vendor's blog; they're the sorts of questions that IBM's customers should be asking them. Maybe IBM has a good reason for starting KMIP, even though there seems to be a standard well underway that solves the same problem that KMIP does. If that's the case, then they certainly deserve support from those who will benefit from KMIP, which includes many security vendors and their customers. If they don't have a compelling reason, however, their customers should clearly explain to them that they want interoperable key management that they can use enterprise wide, and that the vendor community should act accordingly.

Another part of the InformationWeek article that caught my eye was this:

Technology must be developed and deployed with live customers before functionality can be standardized.

This is also relevant to the development of key management standards. Many vendors have shipping key management products. As I mentioned in an earlier post, the recent Burton Group report on enterprise key management seemed to indicate that only a few vendors (Voltage, RSA/EMC, nCipher, NetApp and SafeNet) have much experience in developing key management products that do much more than manage keys for their other products.

If this assessment is right, you might wonder how useful IBM’s thoughts on how to do key management will be. Their approach may be great for managing keys that IBM products need, but they may not be as useful for a general-purpose key management standard. It will be interesting to follow the development of KMIP to see if this turns out to be true or not.

ESPP at the RSA Conference

At the RSA Conference yesterday, I attended the Experienced Professional Program (ESPP). To attend this event, you nominally had to be invited by the Program Committee. I suspect that their criteria weren’t really that strict. If you had 10 years or more experience in the information security industry and signed up for the RSA Conference (even for just the expo), you were probably automatically invited.

I found one of the ESPP presentations particularly interesting. This was “The Ghosts of Security Past, Present, and Future.” The title of this talk tells about as much about its contents as the titles of some of my blog posts do (not much at all), but it was interesting nevertheless.

This talk could be summed up by the catch-phrase “there is nothing worse than a well enforced bad rule.” The Digital Millennium Copyright Act (DMCA) was used as an example of this, and there was lots of discussion that suggested that the Rockefeller-Snowe bill that’s now being considered by the Senate could be another example of it if it ever becomes law.

The problem with the DMCA is that it makes it very difficult to discuss any security vulnerabilities that you might find. If you find a security vulnerability, the responsible way to handle it usually considered to have two steps. First, you notify the vendor that makes the vulnerable product. After the vendor has a reasonable chance to patch it, you then publish your results. According to the lawyers that were on the panel for this discussion, this can get you in legal trouble.

If you do this, you might be threatened with legal action under the DMCA to keep any information about the vulnerability from being published. Instead of informing the vendor, the lawyers recommended that the first step after finding a security vulnerability is to talk to a lawyer about how to handle what you’ve learned in a way that will keep you out of court.

I had to wonder exactly what kind of advice you’d get from a lawyer if you actually did this. In my experience, lawyers tend to mention even very slight risks, sort of like a doctor telling you than any medical procedure could end in your death. That’s why you can get exchanges like this:

You: Should we go out for lunch today?

Laywer: You should be aware of the risks that can accompany going out for lunch. You could be involved in an accident that results in your death, the death of one or more of your coworkers, or of the driver or passengers of another vehicle.

You: Are you saying that we shouldn’t go out for lunch?

Lawyer: I can’t advise you on how to make that decision. I can only advise you of the possible consequences if you do.

It was interesting that Microsoft was mentioned more than once in this discussion as being an example of a company that tries to handle security vulnerabilities in their products in a reasonable way. Microsoft seems to be more interested in fixing security problems in their products, while other vendors may be more interested in threatening legal action against security researchers.

The authors of the DMCA may of may or may not have envisioned their legislation being used to threaten security researchers, but that’s apparently where it has ended up. The Rockefeller-Snowe bill also has the potential to have repercussions from unexpected consequences. The panelists claimed that this bill will effectively nationalize information security, making every computer in the US one of “national interest” that’s then covered by federal regulations. All panelists thought that this was an extremely bad idea.

The ESPP Program Committee plans to produce a “call to action” document, get feedback from the attendees at yesterday’s session, and then publish the document. This should happen in the next four months or so. This might be interesting to read when it comes out.

The RSA conference starts today

Today's the first day of the RSA Conference, where I'll be all week. If you believe Paul Stamp, I should be wearing sandals, long hair and a backpack and I should be hanging out at the Thirsty Bear.

He's actually not that far off.

Privacy and cloud computing

Cloud computing may or may not be a technology that changes enterprise computing, but it definitely has serious privacy implications. The World Privacy Forum recently sponsored a report, Privacy in the Clouds: Risks to Privacy and Confidentiality, that made nine findings about these implications. Here’s a summary of these findings that should give you a rough idea of the issues that cloud computing may cause.

• Cloud computing has significant implications for the privacy of personal information as well as for the confidentiality of business and governmental information.
• A user’s privacy and confidentiality risks vary significantly with the terms of service and privacy policy established by the cloud provider.
• For some types of information and some categories of cloud computing users, privacy and confidentiality rights, obligations, and status may change when a user discloses information to a cloud provider.
• Disclosure and remote storage may have adverse consequences for the legal status of or protections for personal or business information.
• The location of information in the cloud may have significant effects on the privacy and confidentiality protections of information and on the privacy obligations of those who process or store the information.
• Information in the cloud may have more than one legal location at the same time, with differing legal consequences.
• Laws could oblige a cloud provider to examine user records for evidence of criminal activity and other matters.
• Legal uncertainties make it difficult to assess the status of information in the cloud as well as the privacy and confidentiality protections available to users.
• Responses to the privacy and confidentiality risks of cloud computing include better policies and practices by cloud providers, changes to laws, and more vigilance by users.

The full report has more detail and is definitely worth reading for its more in-depth discussion. It's one of the more interesting and thought-provoking reports that I've read recently.

Parkinson's Law and Security Budgets

 

The fact that “work expands so as to fill the time available for its completion” is often called “Parkinson’s Law.” This was actually just the beginning of the article “Parkinson’s Law” by Cyril Northcote Parkinson that appeared in the November 19, 1955 issue of The Economist. This article actually had nothing to do with what’s now called “Parkinson’s Law.” Instead, it proposed a model of how government bureaucracies grow exponentially over time.

Parkinson actually expanded his original article into a book that actually included the first statement of the now-famous “What color is the bike shed?” argument that Poul-Henning Kamp first noted on the FreeBSD mailing list in 1999, but that’s a subject for another post.

An IT version of Parkinson’s Law seems appropriate in today’s economy. This version might be stated as “purchasing expands to fill the entire budget.” In other words, if an IT department has a budget of $8 million per year, then they’ll spend the full $8 million, but if they have $10 million, then they’ll spend the full $10 million.

The interesting observation is that the difference in the quality or quantity of the service that they provide with the two budgets usually isn’t really that big. If you cut your IT budget, your IT staff are forced to find less expensive ways to do things. These people are typically fairly smart, and they can often come up with some clever solutions that do the same things, but at a lower cost. It almost makes you wonder why they weren’t being as careful with the larger budget.

Tokenization is a form of cryptography

"Father," said one of the rising generation to his paternal progenitor, "if I should call this cow's tail a leg, how many legs would she have?" "Why five, to be sure." "Why, no, father; would calling it a leg make it one?"

Edward Josiah Stears, Notes on Uncle Tom's Cabin

Some security vendors are now promoting tokenization as an alternative to using cryptography. By not considering tokenization a form cryptography, it opens the door to using algorithms that are much weaker than would ever be considered for other uses. This is a mistake. Tokenization is definitely a form of cryptography and should be treated as such.

Both encryption and cryptographic hashing use the idea of a calculation being "easy" or "hard." If there's a polynomial time algorithm to perform a calculation, then we say that it's "easy." If a calculation isn't easy, we say that it's "hard." If a calculation is easy, it's feasible for an attacker to do; if a calculation is hard, it isn't.

Both cryptographic hash algorithms and encryption algorithms have the property that calculating them is easy, but reversing the calculation is hard. With a cryptographic hash function, there may be more than one way to reverse the calculation while there's a unique way to reverse encryption. It's also easy to reverse encryption if you have the right cryptographic key, while there's no easy way to reverse a cryptographic hash function.

If we consider what tokenization does, it certainly looks like it falls under what's commonly defined as either encryption or hashing. Tokenization takes an input value and creates a token from it. To protect the input value, it needs to be hard to recover the input value from the token. That's just like either encryption or hashing, isn't it? The only difference is that we're calling the output of the tokenization function a "token" instead of a "ciphertext" or a "message digest."

But because tokenization vendors don't call their technology "encryption" or "hashing," they can avoid having to worry about using peer-reviewed or standardized cryptographic algorithms. They can also use "security through obscurity" by claiming that their tokenization algorithm is proprietary. This has been known to be a bad idea for over 150 years, and it's still a bad idea today.

There are encryption technologies available that offer the same benefits as tokenization, but have rigorous proofs of their security. If you use one of these, you have a high level of assurance that your information is protected. If you don't, you're accepting the use of a potentially-weak cryptographic algorithm. Why would you want to do that?

Tokenization is definitely a form of cryptography. It should be treated like it is.

3DES 128 bit encryption does not exist

Understanding how to describe a cryptographic key in terms of "number of bits" can be tricky. Do you mean exactly how many bits comprise the key? That might not be very useful because algorithms like DES and 3DES don't actually use all of the bits in a key. A DES key actually has 64 bits, but eight of these are parity bits and aren't used to encrypt or decrypt, leaving only 56 bits for that.

Another definition is based on how much cryptographic strength a key provides. This is probably more useful, but it adds another source of confusion. A 3DES key has 192 bits, but only 168 are actually used to encrypt or decrypt. But when 3DES is used, there are attacks against it that reduce the strength provided by those 168 bits to about 112 bits.

That's too much information for most people, and it's really more than you should expect a non-specialist to understand.

On the other hand, it's definitely the sort of thing that any security vendor should know and understand. This is why I was surprised to see the term "3DES 128 bit encryption" again and again in Shift4's white paper Storing Credit Card Data.

I was surprised because 3DES 128 bit encryption doesn't exist.

Depending on your point of view, you might say that a 3DES key has either 192 bits or 168 bits. You might even say 112 bits if you're thinking about bits of strength instead of how many bits comprise a key. There's no way at all to justify saying that one has 128 bits.

You shouldn't expect the average guy on the street to know this, but it's the sort of thing that a security vendor really ought to know.

This error probably comes from a misunderstanding of an earlier version of the PCI DSS audit procedures that wasn't as clear as it could be. In particular, the testing procedures for version 1.1 of the PCI DSS had this:

3.4.a Obtain and examine documentation about the system used to protect stored data, including the vendor, type of system/process, and the encryption algorithms (if applicable).

Verify that data is rendered unreadable using one of the following methods:

• One-way hashes (hashed indexes) such as SHA-1

• Truncation or masking

• Index tokens and PADs, with the PADs being securely stored

• Strong cryptography, such as Triple-DES 128-bit or AES 256-bit, with associated key management processes and procedures

Note that the last bullet point isn't written as clearly as it could be. It looks like a combination of a missing comma and a cut-and-paste error. What they probably meant was this:

• Strong cryptography, such as Triple-DES, 128-bit or 256-bit AES, with associated key management processes and procedures

A security vendor should have been able to see the problems with the last bullet point and not just copied the confusing text. They certainly should have known that 3DES 128 bit encryption doesn't exist.

What on earth is tokenization?

Tokenization is a technology that's sometimes used to obscure sensitive information. I'm not convinced that it's a good solution in many cases, but I'm definitely convinced that calling it "tokenization" was a bad idea. "Tokenization" has a well-established meaning that most undergraduate computer science students learn, and it seems reasonable to assume that the marketing person who decided to overload this term didn't know this. I doubt that they were trying to confuse things by using an existing term in a totally unrelated way, but I may be giving them too much credit.

A token is one or more characters in a source code file that act as a single logical symbol in a high-level language when they're grouped together, and converting a source code file into tokens is called tokenization. An example of this is converting the code

commission=sales*rate;

into the following tokens

commission

=

sales

*

rate

;

Tokenization is also used by linguists who try to understand natural languages. Instead of parsing a file of source code, linguists want to parse a sentence into words. An example of this is converting the sentence

I flew to New York.

into the following tokens

I

flew

to

New York

Tokenization, particularly of natural languages, is actually fairly tricky. How do you know whether to parse "New York" into a single token or into "New" and "York," for example?

There have been a significant number of books and papers published over the past few decades that talk about how to do tokenization, both with source code and natural languages. Because this is true, why would a marketing person decide to use the same term for a totally unrelated concept? Particularly when many of the people they'll be talking to about their version of tokenization already understand the other concept? The average guy on the street doesn't think of tokenization as something that a compiler does, but many IT people do, and they're the ones who are going to be involved in deciding which technology to use. Overloading a term that they already know was probably a bad idea.

The Rockefeller-Snowe bill

The Rockefeller-Snowe bill that's being considered by the Senate is supposed to "address our nation’s vulnerability to cyber crime, global cyber espionage, and cyber attacks that could potentially cripple the United States’ critical infrastructure." Some parts of what this bill tries to do make sense, while other parts don't. I'm particularly concerned about how the federal government wants to create national information security standards.

As I've mentioned before, complying with government standards is usually enough to avoid being considered negligent. This means that if the government creates this proposed national information security standard and businesses comply with it, there's a good chance that they wouldn't be considered negligent if their security is defeated by a hacker as long as they had implemented government-approved security. This could be a problem because "government-approved security" and "good security" don't necessarily mean the same thing.

The government is often fairly slow to react to new developments. Because of this, if they're creating and maintaining a national standard for information security, this standard probably wouldn't address the most recent threats. This means that it's easy to think of scenarios where security researchers would discover new attacks, but businesses would be free to ignore the threat posed by them until the government standard was updated to reflect the new threats. And businesses would be relatively free of liability if they did this.

It's also easy to believe that a government standard wouldn't allow the most recent advances in security technology to be used until they're considered "approved" in some way. This already happens now. Some security vendors are caught in a Catch-22 in which the government can't use their technology until it's approved for government use, while being widely used by the government is a requirement for the new technology getting this necessary approval. If this type of reasoning is applied to more than the government market, it's easy to see how the Rockefeller-Snowe bill could easily kill innovation in the information security industry.

Hackers, of course, wouldn't be constrained by the same government regulation that businesses would, so they would continue to create new and innovative types of attacks. In the long run, this would lead to a situation that benefits absolutely nobody. Except, perhaps, the hackers.

That's why I'm concerned about where the Rockefeller-Snowe bill may be taking us. At least one part seems to have a good chance of this being in the wrong direction.

Software as a service

I recently stayed at a hotel in which I saw the following label on the minibar in my room: "This minibar has a tamper-evident seal for your protection." Because I was paid to beat things like tamper-evident seals in a previous job, and was actually fairly good at it, I couldn't resist the challenge that this posed. I only had a Swiss Army knife with me, which is a little too big for this kind of work, but it turned out to be good enough. In a minute or two I had the minibar seal removed yet intact.

After looking in the minibar, I had to wonder exactly how the seal was designed to protect me. Should I have felt safer because the seal guaranteed that the minibar wasn't being used by terrorists to store a few spare pounds of weapons-grade plutonium? Instead of protecting me, the seal was really there to protect the hotel's revenue, wasn't it? Why did they feel the need to lie to me about the reason that the seal was there?

It seems like a good rule of thumb to never believe what businesses tell you about why they're doing things. This applies to more than just hotels. It also applies to software. In particular, do customers really want software as a service like some software vendors would have you believe, or is this just another attempt to increase revenues or to do some accounting trick that makes things better for software companies?

I'm not convinced that some things are useful as a service. I have no interest at all in replacing my version of Microsoft Office with a software-as-a-service version of it, for example. Other applications, however, may make sense as a service, and many of these probably relate to security. This is because the controls that you need to run a reasonably-secure security application can be fairly expensive. This means that it may make sense to pay someone else to run a server for you in their secure data center. That way you're only paying part of the costs of the secure facility instead of all of it. If you're big enough to have your own secure facility, that may not be useful to you, but for many smaller businesses, some security applications seem to make sense as a service.

That's probably why most of the customers of Voltage's software-as-a-service offering, Voltage Security Network, are smaller companies. Not all of them are, of course, and the larger ones have an entirely different set of reasons for liking VSN, but the smaller ones seem to use VSN to avoid the costs of running their own key server, provisioning users, software distribution and overall systems management. For the smaller businesses, VSN is probably a good example of a software as a service offering that makes sense. Are there any other obvious examples where it's clearly better to use software as a service instead of licensing and running the software yourself?

The Snooze of Kilimanjaro

Kilimanjaro is a snow-covered mountain 19,710 feet high, and is said to be the highest mountain in Africa. Its western summit is called by the Masai "Ngàje Ngài," the House of God. Close to the western summit there are the dried and frozen carcasses of several people who died of boredom at the information security conference that was recently held there. No one has explained why the conference was held at that altitude.

Maybe I'll feel differently after the RSA Conference in a few weeks.

Another misunderstanding

There was an interesting press release on February 24 from Cellopoint, a company based in Taiwan that makes information security products. Here's part of it.

Cellopoint today announced the immediate availability of Cellopoint Email Encryption, a modular solution of products for data loss prevention and regulatory compliance that can simply the deployment processes and eliminate the management overhead. For financial institutes, sending and receiving inadequately secured email statement to customers was becoming a potential security risk. So they deployed email encryption products for secure message delivery. But some of them were using identity based encryption which employed social security number and some kind of username as secret keys. The security and strength of the keys were doubtful. Encryption technology can be divided into symmetric and asymmetric key algorithms. Symmetric key is to protect confidentiality while asymmetric key is providing authentication and non-repudiation. Each of them has its own pros and cons, so the better way is combine them into an integrated solution. Public key infrastructure (PKI) is the well-known cryptography system utilizes both symmetric and asymmetric algorithms but it is hard to install, deploy, maintain and is very costly. Cellopoint Email Encryption is an easy-to-use, gateway encryption solution. It simplifies CA management process and provides confidentiality, identity identification and non-repudiation.

I would think twice about buying encryption technology from these guys. It looks like they don't quite understand what identity-based encryption is, so they're probably not really encryption experts. IBE has a very clear and precise definition. It's defined in the paper "Identity based encryption from the Weil pairing" by Dan Boneh and Matt Franklin if you're really curious about it. Some things are properly called IBE while others aren't, and it certainly looks like the people at Cellopoint don't understand that. They also don't seem to understand that IBE is a public key technology, just like RSA or Diffie-Hellman. These aren't the kinds of things that you'd expect the average guy on the street to understand, but they're certainly the kinds of things that you'd expect a vendor of email encryption products to understand.

The IBE that Voltage uses has a formal and rigorous proof of its security, so claims like "the security and strength of the keys were doubtful" won't withstand much scrutiny, and it takes more than a competitor claiming that our technology isn't secure to make it so. If there's actually a problem with the security of our technology, that means that there's a flaw in the proof of its security. Thousands of cryptographers have looked at this proof, and none of them have found that it's incorrect. This means that if someone claims that Voltage's IBE isn't secure then either they really don't have the background to really make such a claim or they've found something significant that will get their paper accepted at the cryptography conference of their choice if they write it up. The chances of all the leading cryptographers being wrong is probably very small, so it's very likely that claims that Voltage's IBE is weak are also wrong.

Cloud computing

Cloud computing is one of the most overhyped phenomena to have hit the IT industry in a long time.

Cath Everett, ZDNet.co.uk

There seem to be three main reasons that are commonly used to justify cloud computing. The first is that it provides a cheap and easy way to create IT infrastructure. This makes it appealing to smaller businesses, which seems to be the set of customers that like cloud computing the most. Maybe the fact that they might only need the equivalent of half of a server for something makes cloud computing appealing to them when they don't want to pay for the entire server. In any event, this claim seems like a reasonable one.

Another reason that is used to justify cloud computing is that can provide "utility computing" that's always available and can easily scale. Cloud computing proponents claim that it's easier to just add additional cloud computing resources than to go through the hassles of getting additional budget approved, ordering more equipment and dealing with the overhead that operating the additional equipment would cause.

I have to say that I find this argument unconvincing. These sound more like management problems than technical problems, which means that trying to solve them with technology is probably doomed to fail. If your organization doesn't want to pay for additional computing resources that they run themselves, they're probably not going to want to pay for additional resources that someone else provides either.

Cloud computing is also supposed to give you the ability to react quickly to changing business requirements. It's supposed to let you bypass your corporate IT department that may be unresponsive and overstretched. This also sounds like a problem with management instead of with technology. Your IT department exists to support other business units, and if they can't react quickly enough to changing requirements, this may be more a reflection of the management of the IT department instead of limitations of the technology that they use. Because of this, I don't find this argument convincing either.

This leaves two of the three reasons for cloud computing in doubt. The way in which cloud computing has experienced success seems to support doubting the weak claims. After all, most of the success that cloud computing has experienced has been with start-ups and other small businesses. These are the very businesses that benefit from its ability to cheaply and easily create an IT infrastructure.

Enterprises, which are the ones that would tend to benefit from the two weaker claims, are also the ones that haven't been as interested in cloud computing. If the only reason to use cloud computing that can withstand much scrutiny is that it provides a cheap and easy way to create IT infrastructure, it may actually never end up experiencing much success in the enterprise market.

More than two

It seems that James McGovern didn't quite understand my reply to his blog post about identity-based encryption. One of James' issues with IBE is a perceived lack of algorithm agility. I pointed out that there are actually many different IBE schemes, two of which Voltage actually uses in our shipping products. James seems to have misunderstood my comment to be saying that there are only two IBE schemes.

This is far from the truth.

There are now more IBE schemes than one person can reasonably keep track of and more are being invented fairly regularly. I would actually say that the draft of the IEEE P1363.3 Standard for Identity-Based Cryptographic Techniques using Pairings has too many IBE schemes in it, and the P1363 working group is actually now voting on a motion that I made to remove some of the schemes that are in the current draft of the P1363.3 standard.

On the other hand, each of the schemes that are currently in the draft of the P1363.3 standard has a rigorous mathematical proof of their security, something that many the traditional PKI schemes that James refers to don't actually have. So even if I can't convince people to remove what I consider to be the unnecessary schemes, there won't be any problems with their security, it will just mean more work for me as the editor of the standard.

News from Maine

Yesterday, the Portland Press Herald reported how a federal judge has decided to look at the question of whether or not the Hannaford Brothers supermarker is liable for damages from the data breach that they suffered between December 7, 2007 and March 10, 2008.

This breach disclosed the personal information ofabout 4 million people and resulted in about 1,800 fraudulent charges to credit cards, none of which were passed on to consumers. This case may set some interesting precedents about exactly how responsible merchants are for protecting credit card data and what the consequences are if that data is stolen.

Hannaford is claiming that damages are inappropriate because its customers didn't actually suffer any financial damage and that all they suffered was some slight inconvenience. If the judge rules that the lack of financial damages is enough to greatly limit Hannaford's liability, that could have a dramatic effect on how legal actions from future data breaches can proceed.  

Is encryption hard and expensive?

Encryption is notoriously expensive and hard to use. Is this impression just based on anecdotal evidence, or is this really the case?

One way to answer this question is to look at a recent report from the US Government Accountability Office. GAO report GAO-08-525, “Federal Agency Efforts to Encrypt Sensitive Information Are Underway, but Work Remains” has some data that the GAO got from surveying 24 major federal agencies on their use of encryption and the obstacles that keep them from using it more widely. Here’s what the agencies said about how serious various obstacles are when it comes to impeding their deployment of encryption to protect sensitive information. The number in each cell of this table is how many agencies said that a particular problem caused a certain level of difficulty.

Hindrance	Little or no hindrance	Some hindrance	Moderate hindrance	Great or very great hindrance
Prohibitive costs	2	8	5	9
Lack of user acceptance	3	12	4	4
Difficulties with data backup and recovery	5	10	6	3
Insufficient training	4	13	3	2
Difficulties with archiving and retrieving	5	12	3	3
Lack of interoperability	3	6	7	5
Lack of infrastructure readiness	7	2	9	6
Lack of vendor support	8	8	6	1
Lack of FIPS-compliant products	7	6	4	4
Lack of management acceptance	7	9	1	2

Hindrances to Implementing Encryption at Federal Agencies (GAO-08-525).

The biggest obstacle is clearly prohibitive costs, which isn’t terribly surprising. The federal government seems to be committed to using encryption technologies like PKI. These technologies work, but they’re also extremely expensive.

When I’ve mentioned to government employees that certain technologies were better because they were cheaper to use and support, I’ve actually had them roll their eyes, saying, oh, no, not that annoying discussion of costs again! Because costs are the biggest obstacle to the use of encryption by the government, you have to wonder why they have that reaction. Federal agencies clearly understand that costs are an issue. You'd hope that they would look for technologies that can accomplish their goal of encrypting sensitive information, but can do this at a lower cost than the PKI that the government seems to like so much.

I found it somewhat surprising that the biggest obstacle after costs is lack of infrastructure readiness. In other words, lots of federal agencies can’t encrypt sensitive information because their existing networks can’t handle encrypted information. That’s not really that surprising. In any legacy system there’s often at least one component that assumes that all of the data that it’s processing is a particular format. Encryption usually changes the format of the data, which can make it impossible for such legacy systems to handle it. On the other hand, there are technologies available now that let you encrypt sensitive information while keeping its format unchanged. One has even been submitted to NIST as a new mode of AES. Maybe federal agencies just haven’t heard about this yet. It certainly sounds like it would address one of their most pressing problems.

Failing better

 

Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.

Samuel Beckett, Worstward Ho

Many technologies sound promising, but turn out to be less useful in practice. Public-key infrastructure (PKI) is a good example of this. There were some very smart people involved in the development of the standards that define how PKI operates, but this wasn’t enough to guarantee the success of the technology. It failed miserably when it encountered some of the real-world problems that its designers didn’t anticipate.

There’s now an effort that’s being organized to create the next generation PKI. This will be a Research Group (RG) in the IRTF, the Internet Research Task Force. This is a group that’s closely aligned with the IETF, the group that creates the standards that define how the Internet operates. Here’s part of the proposed charter of this new group:

The PKI Next Generation (PKING) Research Group will look into alternate certificate formats, semantics, and PKI services that could eventually replace PKIX if deployed. The PKING design work will be from the perspective of maximizing utility for the relying party and the identified party; issues of what would be best for a certificate authorities will be given much less priority.

Given this perspective, the design work will need to take into account how users could transition from PKIX to an eventual new PKI. Different design decisions could make this transition more or less easy, and such decisions need to be explicitly laid out. Designing a PKI that would be nearly impossible to use by current PKIX users would be considered a failure of the PKING RG.

The PKING RG will first develop a detailed list of desired features for a next-generation PKI. The resulting list will explicitly exclude the format for certificates or the design of protocols to meet the desired features. It is hoped that the RG can agree to one list, but if there is sufficient interest in having multiple lists, they will be permitted as long as each list gets significant review from the RG as a whole. The creation of this list or lists is expected to be a multi-year task.

After the feature list is created, the PKING RG will develop one or more experimental instantiations of PKIs based on the desired features. This development will include extensive evaluation of how different formats, semantics, and protocols meet the requirements, particularly the requirement for a sensible transition from PKIX to the new format and protocols. The PKING RG may develop proposals as input to the IETF for standardization, but that is not a primary goal of this research.

The research challenges expected to be faced by the PKING RG include devising a taxonomy for PKI that is based on maximal utility for a wide variety of users; avoiding features whose genesis derive from the semantics of PKIX rather than the general use cases for PKI; and determining how to evaluate differences in transition strategies given that such a transition has never taken place on the Internet. The IRTF is more amenable to this type of research than, say, the IETF, where a single "requirements document" would be expected to be finished in a short period of time and a single protocol would be expected to emerge by group consensus.

This certainly looks like a useful goal, but the people who are going to take part in this effort are probably the same ones that worked on the first set of PKI standards. If the PKING RG succeeds, the IETF will probably create new standards that can be used to implement the new architecture. But because the same people will be involved in this work that created the PKIX standards, I wouldn’t expect these to be very useful either. The next generation PKI will probably fail again, although it may fail better that the first generation did.

The transcript of yesterday's House hearing

FYI - the transcript and video of yesterday's hearing in the House of Representatives' Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology that tried to answer the question “Do the Payment Card Industry Data Standards Reduce Cybercrime?” is now available.

Fight global warming with the Common Criteria

There seems to be an unexpected benefit to Common Criteria certifications: they may actually be able to effectively combat global warming. Here's why.

There are essentially two ways to reduce the amount of carbon dioxide in the air: you can either stop adding more or you can find a way to take some out. Planting more trees is an easy way to remove carbon dioxide from the air because the cellulose fibers and the other components of wood are made from carbon dioxide that trees get from air. In the language that's used to discuss global warming, trees are a carbon dioxide "sink." Some businesses even promise to take advantage of this fact by planting additional trees to offset any emissions that their operations create. The information security industry may have its own way to take advantage of this, and it relates to the Common Criteria.

Buying security products can be tricky because you can't always tell if they're working or not. If you have an intrusion detection system running, for example, you know that you're going to have false alarms as well as missing some real intrusion attempts, and those missed attacks can cause trouble. You can hope to get the number of such missed attacks down to an acceptable level, but you'll never really know how many you missed. With spam filtering you have a similar trade-off between mislabeling legitimate e-mail as spam and letting spam sneak through your filter, and unless you check the list of messages that have been identified as spam on a regular basis, you'll never know how many messages were mislabeled.

If a vendor claims that their spam filtering technology only misidentifies 0.01 percent of legitimate e-mail as spam while catching 99.99 percent of all spam, you might be inclined to think that they got this estimate under laboratory conditions that may not reflect the real-world. On the other hand, if an independent testing laboratory comes up with the same estimate, you'd probably be more inclined to believe it. So one good way to work around the problem of the unknown quality of security products is to have an independent third-party test them and certify them as being good in some way. Doing this helps both security vendors and their customers. The vendors benefit from the trust that comes with such a certification as well as the shorter sales cycle that it can bring. Their customers benefit by the reduced effort required to test the products before buying them.

On the other hand, too many certifications can also be a problem. Getting products certified is expensive and time-consuming, so vendors certainly don't want to do separate certifications for each country or for each industry segment. So from the point of view of security vendors, the Common Criteria is very useful. As its name tells us, it’s supposed to be a single standard that’s widely accepted. So by getting their products Common Criteria certified, vendors only need to get a single certification rather than needing to get many different certifications.

But the Common Criteria uses a very generalized definition of a product that includes lots of additional specialized documentation that has little or no relevance to the actual security provided by the product. These documents are almost impossible for a non-specialist to get correct, and most of the time and effort spent on a Common Criteria certification is spent getting these documents just right. And because these documents are considered part of the product from the Common Criteria point of view, supporters of the Common Criteria can point to the errors that occur in these documents as proof that evaluations virtually always uncover “flaws” in security products. This is definitely not the kind of standard that security vendors or their customers would develop on their own, and it really doesn’t provide the type information that most customers find useful.

Because products (at least as most people would define it – which does not include this specialized documentation) almost never changes during the evaluation process, being Common Criteria certified doesn’t really give customers much useful information about the product that they might buy – it just verifies that lots of unnecessary paperwork was completed. Because of this, customers still need to do additional security testing of products that are Common Criteria certified, which eliminates one of the key advantages that a certified product is supposed to provide. On the other hand, the unnecessary paperwork created by a Common Criteria evaluation provides an additional benefit: it helps to fight global warming.

The reams of paper that are used for the Common Criteria documents come from trees, which are great carbon dioxide sinks. So the extra documentation that the Common Criteria process requires may actually have a beneficial side effect: the paper that's used for the Common Criteria documentation binds up carbon that came from carbon dioxide in the air, making it unavailable as a greenhouse gas that can contribute to global warming. Note that you just need to print these documents to get this advantage; you should feel lucky that you don't actually have to read them.