Superconductor

Right hand, say hello to the left hand

At the recent X9 meeting, I noticed an interesting pattern in the discussions about the appropriate level of security around various on-line banking transactions. In every case that I can remember, we had a discussion that went something like this:

Bank A representative: So we think that this new technology has the potential to really revolutionize banking. Bank A loves it.

Bank B representative: Our concern with that particular technology is that we'll never be able to make it secure enough. Plus, our customers really don't want it.

Bank A representative: We don't see security as a problem at all. We've actually been using this technology for over two years now and customers love it.

Because these opinions were often so far apart, I had to wonder exactly how much thought went into creating some of the banks' positions. Had they really thought through the security implications of using a new technology? Did they really have an idea of what their customers really want?

With opinions as different as the ones that I saw, I suspect that not everyone had been as careful in forming their opinions as they should have been, although it was hard to see which position could have benefitted from some additional research.  

More on the Cryptographers Panel misunderstanding

After pondering the odd reactions that I saw from some people who saw the Cryptographers Panel at the RSA Conference ("Oh no! Crypto is broken! We can't use it to protect sensitive data!"), I started to wonder why people don't have a similar reaction to tokenization. Except for the article that I recently wrote for the ISSA Journal, there's been absolutely no careful discussion of tokenization at all. Almost nobody can tell you exactly what it is and why you'd expect it to be secure. There are absolutely no standards for tokenization, and tokenization systems receive absolutely no peer review. Despite this, people are cheerfully willing to blindly assume that something is secure just because it's called "tokenization."

Why is this?

Now Voltage sells both encryption AND tokenization products. Which one we recommend to customers depends on exactly how they need to handle sensitive data after it's either encrypted or tokenized. And because we offer both options, we can afford to be fairly impartial in the battle that's apparently being fought by marketing people who don't really understand either encryption or tokenization.

Are people just afraid of encryption because it's hard? I'll admit that encryption is a difficult subject that's hard to master. Is the blind acceptance of the security of tokenization that we see a reaction to the previous generations of encryption technology that actually were too hard and expensive for most uses? There must be some good reason that people are willing to make a huge leap of faith just because a technology is called "tokenization."

Of course to really make people who blindly accept tokenization uncomfortable, ask them about that database of encrypted information that's used in the detokenization algorithm. If you can't trust the security of encryption, why would you trust the security of that database?

The bottom line is that the security of encryption is based on a solid foundation of rigorous research. There's no similar foundation for the security of tokenization. Maybe it's time to correct this oversight.

Misunderstanding what was said at the Cryptographers Panel

As usual, the Cryptographers Panel at the RSA Conference was interesting. Unfortunately, some of the remarks made by the panelists seem to have been taken out of context by people who apparently didn’t understand the context to begin with. This has apparently led to some people claiming that cryptography is totally broken and shouldn’t be used to protect sensitive information.

As Dave Barry would say, I’m not making this up.

The remarks that Adi Shamir made about attacks on AES seem to be at the root of this misunderstanding. Let’s look at exactly what Shamir said and see how close it comes to saying that cryptography is totally broken. You can find a recording of the talk here if you missed the RSA Conference last week. Some of the question and answer period has been edited out, and I’m not exactly sure why that happened.

In his opening remarks Shamir notes that progress has been made in the cryptanalysis of AES. Last year, Alex Biryukov and Dmitry Khovratovich found a related-key attack against the full AES-256 algorithm that has both time and memory complexity of 2^99.5.

This attack is much better than an exhaustive search, but it’s also not even close to being feasible. (If that’s not obvious, do a quick Google search to find out roughly how much information exists in the world today and compare it with the 2^99.5 memory required by this attack.) If that’s the best that an attacker can do, then you’re still very safe. The fact that the way that standards require you to use AES also eliminates the possibility of actually carrying out a related key attack should make you feel even safer. If you use AES like the standards specify, then this attack can’t be used against you.

Shamir also mentioned an attack on AES-128 that was also found by Biryukov and Khovratovich that runs in 2⁴⁵ time. That’s so fast that it’s practical to do on a typical PC. On the other hand, Shamir also mentions that this attack also assumes that you use AES-128 in a way that is forbidden by the AES standard. In this case, the attack works if you use AES-128, but try to fake AES-256 using the shorter 128-bit key. Again, this isn’t allowed by the AES standard, so it shouldn’t really come as a surprise that it doesn’t work well. Once again, it you use AES like the standards specify, then this attack can’t be used against you.

So I’m not sure exactly how someone heard Shamir’s remarks and interpreted them as saying that encryption is fatally flawed and isn’t suitable for use in protecting sensitive information. It seems to me that a better interpretation is that you really need to follow the standards that specify how encryption is used. If you do that then it provides protection that’s incredibly secure. On the other hand, if you decide to not follow these standards and instead decide to invent new ways to use encryption that haven’t had any sort of independent review, then there’s a possibility that you can do things that dramatically reduce the security that the encryption provides.

There are definitely innovative ways to use encryption safely. These will always come with a peer-reviewed proof that the new technique is secure. If you use one of these, encryption will still provide an essentially unbreakable level of security. But if you use techniques that don’t have such a proof of security then you’re taking a significant risk. Maybe that’s too subtle an interpretation for the opening remarks at the Cryptographers Panel, but it’s certainly more accurate than saying that cryptography is totally broken and shouldn’t be used to protect sensitive information.

Why X9.31 key generation is so odd

There was recently an interesting discussion on the sci.crypt Google group. A member of the group asked why the X9.31 standard has such an odd process for how RSA keys need to be generated. One response claimed that there was an easy work-around for the cumbersome process, and that involved using XML:

What you need here is a boat load of XML. XML will solve this problem.

We can have:

<cipher type="Asymmetric" name="RivestShamirAdleman">
 <keygeneration method="outdated,outmoded" result="pointless" />
</cipher>

Then you have someone write a parser in twelve different, slightly
incompatible, libraries and call that a standard.

Then, and only then, have you created a standard that will be defunct
before it's even officially recongised. 
 

A more insightful, if not as entertaining, post described how the content of X9.31 was driven by political maneuvering within the X9 group.

According to a person who claims to have been involved in writing the X9.31 standard, a company who was trying to make their elliptic curve technology look good relative to RSA insisted on the unusual key generation process. The non-crypto people in the group apparently agreed with their arguments and the result was the key generation process that's now in the X9.31 standard. Reading the full discussion of this doesn't take long, and may give an interesting insight or two into exactly how standards are actually developed.

Outis - S/MIME for Gmail

There's apparently an add-on for Firefox that lets you do S/MIME-based email through Gmail. When I first saw this, my first reaction was something like Why on Earth is anyone doing this!?!?

According to the IETF's outcomes tracking database, S/MIME hasn't been a success. They somewhat charitably say that it has experienced "poor adoption."

For some reason, the heroic efforts of the S/MIME Working Group in creating the dozens of documents that they've finished so far remind me of the part of the Odyssey where Odysseus and his companions escape from the hungry Cyclops Polyphemus by blinding him and running away while his cries that "nobody (ουτις, or outis) was hurting him" were ignored by the other Cyclopes.

Maybe "Outis" is a good code name for the Firefox S/MIME add-on for Gmail. I expect that's who will be using it.

Can wireless be more secure than wired?

We had an interesting discussion about wireless security in the recent X9 meeting. This was in the context of the new X.112 Part 2 standard, Wireless Management and Security — Part 2: ATM and POS. The interesting part was that the claim was made that wireless connectivity to ATM and POS devices can actually increase security. This may have been the first time that I ever heard someone make this claim about wireless technology.

The claim that wireless is more secure that wired connections to ATM and POS devices is based on the fact that it’s harder to cut the connection to a wireless device than to a device with a wired connection. Many ATM and POS devices trigger alarms when they’re tampered with, and it’s easier for a hacker to cut a wired connection than to cut a wireless connection. Cut the connection for the alarm and you can attack an ATM at your leisure.

Some payment devices also only transmit transaction data to a back-end system in large batch transactions that take place once every day or two. If this is the case, then an attacker has a fairly big window of opportunity in which to attack one of these systems. The claim is that wireless connections will eliminate the need for such batch processing, which will then limit the exposure of the wireless systems to hackers.

From what I heard from banks at the X9 meeting, it sounds like wireless banking and wireless payments are becoming fairly widespread. I found it interesting that banks perceive wireless to have advantages as well as disadvantages in these cases.

What is end-to-end encryption?

End-to-end encryption is often mentioned as one of the best ways to greatly reduce identity theft, but what exactly is end-to-end encryption? It turns out that there are actually conflicting definitions of it, so there’s no quick and easy answer to this question.

The US government’s Federal Standard 1037C, Telecommunications: Glossary of Telecommunication Terms, defines end-to-end encryption as “the encryption of information at its origin and decryption at its intended destination without any intermediate decryption.”

Another US government document, Special Publication 800-12 – An Introduction to Computer Security – NIST Handbook, takes a different approach. SP 800-12 distinguishes between link encryption and end-to-end encryption, where link encryption encrypts routing information and end-to-end encryption doesn’t.

Which of these definitions is more useful depends on your point of view. If you’re a credit card processor, for example, if the transactions that you process are encrypted on each link between the merchant where credit card data is captured and your systems, that doesn’t necessarily provide a useful level of protection to the credit card information. It might be possible for a hacker to capture it between where it’s in the clear between links.What’s probably more useful to you is for the credit card information to be encrypted as soon as it’s collected and only decrypted when it’s needed for some sort of processing. If that’s done in a hardware security module, that gives you fairly strong protection against any hackers that might be targeting you. You really don’t care about whether or not the routing information that’s used to process your transactions is encrypted or not.

I’m not sure what the motivation was for the SP 800-12 definition. It must have made sense when it was written. Maybe it’s just out of date. SP 800-12 was published back in October 1995. It probably went through the extensive review that government documents typically go through, so it was probably actually written at least a year or two before that. Maybe it’s safe to ignore it today and stick with the FS 1037C version.

Weak cipher suites with EV certificates

We had an interesting discussion of EV certificates in the X9 meeting last week. Apparently, EV certificates guarantee that some non-trivial means of authentication was used to authenticate the entity requesting an EV certificate, but there are minimal requirements other than that authentication. In particular, some people at the X9F4 meeting were a bit concerned by the fact that you can apparently use an EV certificate with an extremely weak cipher suite, which means that it's possible to have a connection to a server that uses an EV certificate yet creates a connection that's extremely easy for a hacker to beat.

The administrator of the server that uses an EV certificate can always configure his server to not allow weak cipher suites, and most of them probably do, but the people at the X9F4 meeting thought that the use of strong cipher suites really ought to be required with EV certificates.

National Cyber Leap Year follow-up

Last year, the US government held the National Cyber Leap Year Summit. Lots of smart people got together and made a series of recommendations to the government. You can read their recommendations here. 

This report came out last September. Some of its recommendations were things like this:

6.8 Idea - Removing Barriers to Entry for Crypto Products into Federal Use

Streamline and expedite the approval process for Federal use of new security technologies.

6.8.1 Description

Many commercial security technologies are unavailable for Federal use even though they are well accepted and widely deployed in the private sector. These technologies often allow dramatic cost savings and efficiency gains over older technologies, but Federal agencies are unable to use them because the technologies have not received the necessary certifications and approvals. In some cases, the existence of rigorous, formal proofs of security should eliminate the need for the long certification and review process and allow Federal agencies to receive the same benefits that the private sector is now realizing. A decade or more is too long for Federal agencies to wait to realize the benefits of new security technologies. Let's find a way to get new technologies used more rapidly.

6.8.2 Inertia

This has not been done yet because the Federal agencies involved in approving new security technologies have relied on the "wait and see if it's secure" model so far. This approach usually determines which technologies are sound and which ones are not, but takes many years and leaves Federal agencies unable to use the innovative security technologies that are being invented today.

6.8.3 Progress

Provable security has made the "wait and see" model unnecessary in many cases. If there is a peer-reviewed formal proof of the security of a technology, that should be enough to get approval for Federal use. If the proof is correct then the technology is secure. Why wait ten years or more if that's the case?

6.8.4 Action Plan

NIST should determine a way to quickly approve provably-secure technologies for Federal use and should review existing regulations and identify ways to allow provably secure technologies within them. This should involve, as a minimum, granting a blanket IATO to new encryption technologies with peer-reviewed proofs of security, and adding provably-secure public-key encryption technologies to the list of techniques that are allowed by FIPS 140-2. In the long run, standards and policies should be changed to allow the rapid adoption of new technologies that are provably secure.

6.8.5 Jumpstart Plan

Within 90 days, NIST should define and implement a way to approve provably secure technologies for Federal use. Within 180 days, a pilot of one of these technologies should be started at a Federal agency.

I haven't heard of any progress in the government on this particular issue. I'm fairly sure that NIST hasn't developed a plan to approve provably-secure technologies for government use and that no government pilot projects of provably-secure technologies have started.

Has there been progress in any of the other areas that the summit participants recommended?

HTML entities for math

Because of this blog, I often find myself looking up the HTML entities for mathematical symbols. The primitive software that runs this blog apparently can't handle most mathematical symbols, so I'm often stuck looking up the HTML codes and entering them by hand. Because of this, I'm probably one of few people in the world who knows that the code for the Weierstrass ℘-function is &weierp;, for example.

I recently came across an HTML code that I found somewhat entertaining. The code for ∈ is &in;, which makes a certain degree of sense. Probably by analogy to this code, the code for ∋ is &ni;, which is probably meant to be "in" backwards. On the other hand, I have no trouble at all imagining people at some standards meeting walking around saying "Ni!" and making jokes about shrubberies when this was being discussed.

After thinking about it for a minute or two, I'm now fairly sure that's what happened.

Classic interactive fiction and standards meetings

Before PCs had the flashy graphics that they have today, computer games were much different. Back in the '70s and '80s, the most popular type of computer game was interactive fiction, like the classic games Adventure and Zork. If you've a fan of these games, then the following ought to look familliar:

YOU ARE STANDING AT THE END OF A ROAD BEFORE A SMALL BRICK
BUILDING . AROUND YOU IS A FOREST. A SMALL
STREAM FLOWS OUT OF THE BUILDING AND DOWN A GULLY.

Before the days of the Internet, college students had to find other ways to waste time instead of studying, and interactive fiction was one of the most popular ways to do this, at least with students studying science or engineering.

One of the more memorable interactive fiction games was Bureaucracy. In this game you tried to get to Paris for the weekend, but ended up being thwarted by bureaucratic obstacles at every step in your journey. The part that I remember most clearly about Bureaucracy is it's innovative scoring system. As each bureaucratic obstacle thwarted you, the score that represented your blood pressure increased. If it got too high, you'd die and lose the game.

Bureaucracy was the only Infocom game that I bought but never actually finished.

The title of this post is "Classic interactive fiction and standards meetings," but I think that the reason for that should be fairly clear at this point, so I won't bother explaining it in more detail.

Federated key management as the basis for secure cloud computing

Cloud computing creates security problems that most organizations have not yet had to face on a large scale: protecting data when the location of the data is generally unknown. Encryption is a useful tool for solving this problem, but using it in the cloud is hard because of the key management problems that this causes. Fully federated key management can provide the basis for protecting sensitive data in the cloud, and it's probably the basis for how we’ll eventually protect such data. Let's look at exactly what this means and how it will probably work.

Key management

A cryptographic key is much like the combination to a safe: if you have the right combination, it’s easy to open a safe, but it’s hard to open one without the right combination. Similarly, if you have the right key, decrypting encrypted data is easy, but decrypting it is impractical without this key.

If you’re careless with the combination to your safe, someone else can easily use it to open your safe, and the protection provided by the safe is compromised. Similarly, the cryptographic keys that you use to encrypt data need to be handled carefully. If you’re careless with them then the protection provided by encryption can be essentially eliminated.

Key management covers all the details of how to handle keys carefully enough to ensure this does not happen. It ensures that you don’t do the cryptographic equivalent of writing the combination to your safe on a Post-it™ note and sticking it to the wall next to your desk.

Encryption only involves complicated mathematics that's incomprehensible to most people. Key management involves technology, people and processes, so it's even more difficult. Encryption provides an extremely high level of protection. Even with the world's most powerful supercomputers, hackers would need billions of years to beat modern encryption. Key management is nowhere near as robust. It's usually the weak link that limits how much protection data really gets, so it’s important to get it right if you’re serious about protecting sensitive data.

Federation

Federation describes how different computer systems can work together. In the context of key management, federation includes how different applications can get keys from the same key server. This is an important aspect of key management that needs to be addressed before encryption can be used to protect sensitive data in the cloud, and the lack of the ability to do federation dramatically limits the usefulness of many encryption and key management products today.

Encrypting a backup tape in a data center and decrypting it in an off-site disaster recovery site is a very simple example of federation. In this case, two different tape drives need to work with the same key server to get the key that's needed to encrypt or decrypt the backed-up data. But even extremely simple cases of federated key management can create problems that are hard to solve in practice.

The 2009 Encryption and Key Management Industry Benchmark Report from industry analyst firm Trust Catalyst estimates that only 41 percent of businesses encrypt backup tapes, and that issues relating to key management are the most common reason for not doing so. If the simple cases are that hard, it’s not hard to understand why there’s no solution for the harder cases yet, but that’s what we need to protect data in the cloud.

Cloud computing needs fully federated key management

In cloud computing, we have sensitive data that could be anywhere, and we need the ability for any application that needs access to this data to be able to decrypt it. To do this, we need a way for any application to be able to get the keys that it needs to decrypt data that it gets from the cloud and to use these keys in a careful way that keeps the data protected. More concisely, that's fully federated key management.

Federated key management for cloud computing

If today's systems can't implement fully federated key management, what are the missing pieces? If we look more closely at how cryptographic keys are handled today, we can probably get a good idea of what's needed in the more general case.

A cryptographic key always has additional information associated with it that uniquely identifies it. When a tape drive gets a key to use to encrypt stored data, for example, it also gets a unique key identifier which it stores with the encrypted data. To decrypt the encrypted data, the tape drive requests the key that corresponds to the key identifier that it finds with the encrypted data.

It's possible to extend the idea of a key identifier to include information about the key server where the right key can be obtained. Instead of having a key identifier like this

we might have one like this

 

where the additional information indicates the URL of the key server where the key can be obtained. If all applications understand how to handle such information when it's included in a key identifier, then they can easily use this information as the basis for federated key management.

How it's used today

This approach has already been used with great success in existing key management technologies. Systems that use Identity-Based Encryption (IBE), for example, already use more general key identifiers. In these systems, the identity of a user plus other policy information functions as the key identifier. In the case of using IBE to encrypt an email message, such an identifier might look like this

which indicates the email address of the recipient of the encrypted message, the time after which the private key can be downloaded from the key server, and the URL where the recipient can get the private key that he needs to decrypt the message. Any recipient that can interpret this type of key identifier can then contact the key server and request the IBE key needed to decrypt this message.

This approach hasn't quite made it to other encryption technologies yet, although it probably will soon. The most recent draft of the IEEE P1619.3 Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data uses this approach to define unique identifiers for keys from which it's easy to find the URL of the key server where the key can be obtained. Once that standard is implemented, key management for encrypting backup tapes will certainly get much easier.

Once this idea is extended to other technologies, we’ll have the fully federated key management that we need to protect sensitive data in the cloud. This sounds simple enough, but actually writing a standard that will be the basis for doing this in an interoperable way isn’t easy. Using technologies like IBE may be as close as we can come to fully federated key management until the necessary standards are completed.

How to be PCI compliant yet weak

It’s possible to comply with the PCI DSS yet provide essentially no protection to credit card numbers. Here’s why.

Section 3.3 of the PCI DSS requires this:

Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).

Then section 3.4 requires this:

Render PAN, at minimum, unreadable anywhere it is stored (including on portable digital media, backup media, in logs) by using any of the following approaches:

• One-way hashes based on strong cryptography
• Truncation
• Index tokens and pads (pads must be securely stored)
• Strong cryptography with associated key-management processes and procedures

Each of these techniques seems to provide a reasonable level of protection for credit card numbers, but when you combine the two, it turns out that the combination can actually be fairly weak. Here’s why.

If you mask a credit card number, you can keep the middle six digits and hide the rest. So you might turn this credit card number

1234 5678 9012 3456

into this

1234 56XX XXXX 3456

Now suppose that you also know that the SHA-1 hash of this credit card number is the value

0xdeed2a88e73dccaa30a9e6e296f62be238be4ade

This is enough information to let a hacker quickly and easily find the complete credit card number: all he has to do is calculate the SHA-1 hashes of all possible credit card numbers that begin with 123456 and end with 3456. There are only one million of these, and it’s possible to calculate that many hashes extremely quickly. Even on extremely my old laptop, I can do that in less than a couple of seconds. Hackers who have even more modern computers can do it even more quickly.

So if you have both the hash of a credit card number and a masked version of the same credit card number, then it can be extremely easy to find the entire credit card number. Each of the ways to protect credit card numbers may be good enough by themselves, but together they can provide essentially no security.

I've heard of more than one case where masked data from one application and hashed data from a different application gets stored in a common database, so this particular vulnerability is not purely of academic interest.

What merchants want from the PCI DSS

More interesting stuff from the recent X9 meeting. In this case it relates to what merchants want to help them comply with the PCI DSS. At least this is what the merchants who attended the X9 meeting said that they want.

Apparently merchants don't like how vague the PCI DSS is on several points. In particular, it tells you what you have to do in general terms, but not exactly how to do this. It leaves deciding whether or not a particular approach is good enough to the QSAs. Merchants don't like this arrangement at all. They'd rather be told more details and have to live with a possibly-imperfect solution, particularly if it's one that will guarantee to make them PCI compliant.

I don't think that we'll see that level of detail in anything from either X9 or the PCI SSC, but that seems to be what merchants want. I have an easy solution for them: they should all buy and use Voltage's SecureData. I'm not sure that I can get the PCI SSC to require all merchants and payment processors to standardize on Voltage's products, but it would certainly make life easier for them.

The birth of X9.119

Standardization is crushing the heart and soul, the blood and guts, out of humanity and the eventual result will be either complete and unrelieved slavery or the destruction of civilization and return to barbarism.

Robert E. Howard, letter to H. P. Lovecraft, October 31, 1931

At the recent ASC X9 meeting, we learned that the designation X9.119 had been assigned to the new standard that will be called Protection of Sensitive Data between Device and Acquiring System. At this meeting, it actually took over an hour for the X9F6 working group to decide that this document should be a standard instead of something else, like a technical guideline (TG).

The most amazing part was the fact that after over an hour of loud and bitter debate over this, it was actually unanimously decided that the document should indeed become a standard! In other words, we spent over an hour arguing over a point over which there was total and complete agreement. That might give you some idea of how long it takes to resolve points over which there is actually some disagreement.

I should also mention that I was impressed by the people from Heartland Payment Systems during this hour-long discussion. While people from other organizations were willing to spend lots of time talking about things that weren't really related to the issue at hand, Heartland did their best to keep the discussion on track. Unfortunately, their efforts weren't quite enough to do this, but I hope that they won't be discouraged by this experience. We need more of that type of contribution at standards meetings instead of less.

Thoughts on penetration testing

In the recent X9F4 meeting we discussed the most recent draft of the X9.111 standard, Penetration Testing within the Financial Service Industry. There was lots of discussion of how disciplined, methodical and careful the penetration testing industry is these days. Most people seemed to think that this was a good thing. Some people even think that it’s a good idea to require your penetration testers to give you a complete list of all the tools that they plan to use in their testing, including the exact versions of the tools that they’ll be using.

On the other hand, I have to wonder if that sort of approach really gives an accurate impression of how well protected you are against hackers. After all, some hackers may use a similarly disciplined, methodical and careful approach, but others probably don’t. And if you restrict your testing to only attacks that the more disciplined hackers would use, you’ll almost certainly miss some of the attacks that less careful ones would use.

I’m out of touch with exactly how hackers operate these days, but I’d guess that most of them aren’t as careful and disciplined as professional penetration testers. If that’s the case, professional penetration tests may not really be giving you a good idea of how well you’re defended against hackers. But because that may not actually be the point of penetration tests, this may not really be a problem.

What really happens at standards meetings

Standards meetings aren't just mind-numbing line-by-line reviews of drafts of documents and bitter debates by partisan vendors trying to promote the technology that their products use. Here's what actually happened at the recent ASC X9 meeting.

(The phone rings. A bored attendee of the meeting answers it.)

Bored meeting attendee: Hello?

Man on the line: Yes, I'm calling about the chairs. You need an additional five chairs brought up, right?

Bored meeting attendee: No, that should have been fifty: five zero.

Man on the line: Really!?!?

Bored meeting attendee: No, not really. You really just dialed the wrong number.

Man on the line: Oh, that's good.

Good and bad notation

In the P1363.3 Standard for Identity-based Public Key Cryptography using Pairings, there's one particular bit of notation that seems to confuse and annoy people. That's the use of "ID" to indicate the string that represents a users identity. Every other variable in the document is represented by a single letter, and the fact that this particular variable is represented by two letters seems to be the source of the trouble. I hope that this particular bit of notation doesn't cause people too much trouble, although it certainly seems to have the potential for doing that: a good notation is its own heaven, a bad notation is its own h**l.

Quantum mechanics is an example of a field that seems to defined by its bad notation. Quantum mechanics, at least the material that I learned, is really nothing more than looking at how certain linear operators on Hilbert spaces behave. In other words, it's essentially just linear algebra, but with a notation that does its best to obscure that fact.

The notation that we used in a class on quantum electrodynamics that I had in graduate school is probably why I decided to not study physics any more and to stick to things that used a notation that I could understand. I probably made the right choice. If I had stuck with physics, I'd have spent a significant part of the rest of my life converting between the bra-ket notation and something that actually made sense to me. 

With any luck, the notation in the P1363.3 standard isn't bad enough to make someone decide to give up cryptography.

The report from the National Cyber Leap Year Summit

The recommendations from the information security experts (and so-called experts like me) who attended the National Cyber Leap Year Summit is now available. I found three of these recommendations particularly interesting.

On page 73 in section 3.8 of the National Cyber Leap Year Summit 2009 Participants' Ideas Report you'll find the idea Global Identity-Based Cryptography. Interestingly enough, this idea came out of a group that I wasn't part of, so someone who's not from Voltage thought this idea was important and also convinced the other members of his group that it's important. Curiously, one of the perceived obstacles to the adoption of IBE is "no proven technology." That's definitely proof that I wasn't in the working group that came up with this idea.

If I was there I would have mentioned that there are now at least 10 million users of IBE worldwide, a number that's probably roughly equal (if not greater than) the number of users of PKI. The technology is definitely a proven one. The other perceived obstacles to the adoption of IBE also don't agree with the actual adoption of the technology, but the fact that it's "not proven" is probably the least accurate of these perceptions.

On page 103 in section 6.3 of this report you'll find the idea Global Post-Quantum Secure Cryptography Based on Identity, or IBE that's resistant to attacks that you can run on a quantum computer. I'm not sure that this idea is really worth putting on a research agenda. I don't think that we'll see quantum computers with enough q-bits to actually beat the key sizes that are currently used any time soon. I actually doubt whether we'll ever see these.

On page 113 in section 6.8 of this report you'll find the idea Removing Barriers to Entry for Crypto Products into Federal Use. Here's the description of this idea:

Many commercial security technologies are unavailable for Federal use even though they are well accepted and widely deployed in the private sector. These technologies often allow dramatic cost savings and efficiency gains over older technologies, but Federal agencies are unable to use them because the technologies have not received the necessary certifications and approvals. In some cases, the existence of rigorous, formal proofs of security should eliminate the need for the long certification and review process and allow Federal agencies to receive the same benefits that the private sector is now realizing. A decade or more is too long for Federal agencies to wait to realize the benefits of new security technologies. Let's find a way to get new technologies used more rapidly.

The report goes on to say

Provable security has made the "wait and see" model unnecessary in many cases. If there is a peer-reviewed formal proof of the security of a technology, that should be enough to get approval for Federal use. If the proof is correct then the technology is secure. Why wait ten years or more if that's the case?

I find it hard to argue with that claim. If there's a proof of security then one of two things has to be true: either the scheme is secure or there's an error in the proof. There's no other possible option. So if there's a proof of security, why not let government agencies use the technology?

Here's what the report proposes as an "action plan" for this idea:

NIST should determine a way to quickly approve provably-secure technologies for Federal use and should review existing regulations and identify ways to allow provably secure technologies within them. This should involve, as a minimum, granting a blanket IATO to new encryption technologies with peer-reviewed proofs of security, and adding provably-secure public-key encryption technologies to the list of techniques that are allowed by FIPS 140-2. In the long run, standards and policies should be changed to allow the rapid adoption of new technologies that are provably secure.

And here's how the report recommends that the government start doing this:

Within 90 days, NIST should define and implement a way to approve provably secure technologies for Federal use. Within 180 days, a pilot of one of these technologies should be started at a Federal agency.

This report came out fairly recently. Let's see if NIST actually does what this report recommends

A new use for anti-virus software

One of the unfortunate realities of life is that standards meetings are often fairly boring. If you're attending one, you might only be interested in an hour or two of a four-hour meeting. If you sit through this for a few days in a row, you can end up fighting a losing battle to stay awake. Or you can try to get other work done. In many cases, people play solitaire or minesweeper on their laptops. If you have Internet connectivity, you can even use your favorite social networking web site to keep yourself entertained until the material that you're actually interested in comes up.

Apparently this happens at more that standards meetings. It seems to affect politicians also, at least ones from Maryland. Maybe that's why the Maryland General Assembly recently banned all elected officials and staff from Facebook and MySpace. Maryland's politicians may not have to sit through an extensive and through discussion of several types of random-number generators before they get to the material they're interested in, but they probably have fairly similar problems.

The memo that announced the ban said it was due to viruses coming from Facebook and MySpace, an assessment that doesn't seem to make much sense. Could Maryland have tried to save money by not keeping their anti-virus software up to date? It seems that would do a fairly good job of stopping viruses, even ones that are claimed to come from social networking sites. Having updated anti-virus software might even help keep politicians awake during meetings. That's a benefit that the marketing people at anti-virus vendors don't seem to have tried to market yet.

Another use for standards documents

It looks like there may be unexpected benefits from reading standards documents. That's what I thought when I read the abstract to "Connections From Kafka: Exposure to Meaning Threats Improves Implicit Learning of an Artificial Grammar" by Travis Proulx and Steven Heine. Here's the abstract for this paper that was published in the July 2009 issue of Psychological Science:

ABSTRACT—In the current studies, we tested the prediction that learning of novel patterns of association would be enhanced in response to unrelated meaning threats. This prediction derives from the meaning-maintenance model, which hypothesizes that meaning-maintenance efforts may recruit patterns of association unrelated to the original meaning threat. Compared with participants in control conditions, participants exposed to either of two unrelated meaning threats (i.e., reading an absurd short story by Franz Kafka or arguing against one's own self-unity) demonstrated both a heightened motivation to perceive the presence of patterns within letter strings and enhanced learning of a novel pattern actually embedded within letter strings (artificial-grammar learning task). These results suggest that the cognitive mechanisms responsible for implicitly learning patterns are enhanced by the presence of a meaning threat.

In other words, reading things that are hard to make sense of, like an absurd short story by Kafka, may actually make you smarter. If this is true, I think that I may have found a good use for all of those documents that the PKIX Working Group of the IETF creates.

NIST approval for AES-XTS

It look like the fact that AES-XTS will become an approved mode of AES is more than just a rumor. Last month, NIST posted a draft of SP 800-38E, Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Block-Oriented Storage Devices. SP 800-38E actually just refers to the IEEE P1616 standard, so it looks like NIST has essentially approved IEEE Std 1619-2007. The only additional requirement seems to be that a single key can't be used to encrypt more than 2²⁰ blocks of data.

NIST doesn't approve new modes of AES very often, so it's interesting to see what they think is worth of approval.

You can find the draft of SP 800-38E here.

 

Avoiding a technology monoculture

At the recent National Cyber Leap Year Summit, there were lots of ideas discussed about how to make our current computing environment more secure. One of the ideas discussed was how to deal with the monoculture that success in the marketplace tends to cause. Some people thought that a technical monoculture was a very bad idea that led to all sorts of problems. Others saw the benefits to a standard technology outweighing the problems that it might cause. Still others didn’t see a feasible way to get people to diversify the technology that they use.

Having a single technology that’s used everywhere has the potential to cause all sorts of problems because if the technology fails in one place it fails everywhere. That’s why some applications that need to be extremely reliable, like those that run nuclear power plants or aircraft, need to have redundant systems that are also different from each other.

If there’s a single operating system used on 100 percent of computers and hackers find a way to exploit it, then they can also exploit 100 percent of the computers. On the other hand, having only a single platform to support can give you significant cost savings in the areas of support and maintenance. For large businesses, it’s possible to save hundreds of millions of dollars (according to people from large businesses at the NCLY Summit) by standardizing on a minimal set of supported applications, and it’s not clear that doing this causes anything close to hundreds of millions of dollars in losses due to the increased ease with which hackers can exploit the businesses that have done this. So there’s definitely a cost to standardizing technologies, but it’s not clear that these costs outweigh the benefits from it.

On a more practical note, it’s not clear how you could get businesses to not standardize their technologies. Would you require each business to use a diverse set of technologies? Or would you let each business standardize on a set of technologies but force diversification of technologies from company to company? If you somehow required businesses to diversify the technologies that they use, how would you compensate them for the additional costs that they might experience?

And exactly how would you define diversity? Is version 2.0 of a product the same or different from version 3.0 of a product? A quick look at the National Vulnerability Database seems to show that the vulnerabilities that a product has change a lot over its lifetime, so maybe it’s reasonable to say that version 4.0 is different enough from version 2.0 to justify being classified a different product for this particular purpose. This, of course, could lead to the bizarre effect of encouraging businesses to only patch and upgrade part of their systems, so that they’ll have enough diversity to meet whatever monoculture-banning rules that we come up with.

So maybe that’s a good challenge: find a reasonable way to get businesses to diversify their technology purchases in a way that doesn’t cause huge side-effects. Can it even be done?

More free riding in security

Last week I mentioned how many businesses get a "free ride" on the effort that the US government has put into creating Social Security numbers or credit card companies have put into creating credit card numbers. In both cases, creating a unique identifier is hard and expensive, so there's a strong incentive to use the unique identifier that someone else has already made instead of creating one yourself.

It turns out that there's another area of information security that's full of people getting a free ride at someone else's expense, and this case is much bigger than what you get with Social Security numbers or credit card numbers. This case covers almost all aspects of information security. It's caused when foreign businesses and governments use the work of the US National Institute for Standards and Technology(NIST) without paying for it.

NIST creates dozens of security standards that cover everything from checklists for secure configurations for operating systems to the details of how to implement encryption securely. And because they're a US government agency, people are free to use these documents without worrying about any annoying copyright issues. And they do.

Is this really a good idea?

Do other countries absorb the cost of creating other standards? Is there some sort of international effort to coordinate the development of standards so that everyone contributes something? Or is the US just contributing their work on security standards while other countries get a free ride at their expense?

Comparing key sizes

Not all cryptographic algorithms provide the same level of security for a fixed size of key. A 128-bit AES key provides roughly the same security as a 256-bit elliptic curve key or as a 3,072-bit RSA key. We need to look at exactly how the security provided by cryptography is defined to understand why this is true.

Leading cryptographic standards like FIPS 140-2 define the strength of encryption in terms of how much work it takes for an adversary to find the key that he needs to decrypt encrypted data. So if the work needed to recover a 128-bit AES key is roughly the same as the work needed to recover a 256-bit elliptic curve key or a 3,072-bit RSA key, then we say that encryption using each of these keys provides the same level of cryptographic strength.

In the case of a symmetric algorithm, it's easy to understand how much work is needed. An ideal symmetric algorithm is one for which there's no better way to recover a key than just trying all possible keys to see which one is the right one, and for an n-bit key, this takes 2ⁿ tries. In practice, this can be more difficult to understand than it sounds. A Triple-DES key, for example, actually has 192 bits, only 168 of which are actually used to encrypt or decrypt data (the rest are parity check bits). But for Triple-DES, there's a way for an attacker to recover a key in only 2¹¹² tries, so that the 168 bits of key that are used to encrypt data really only provide 112 bits of strength.

For an elliptic curve algorithm, it's slightly more complicated. There's an algorithm called "Pollard's rho algorithm" that can find an elliptic curve key, and this takes much less time than just trying all possible keys. It only has to try the square root of the number of keys on average. So instead of needing 2ⁿ tries, an attack based on this technique only needs about the square root of 2ⁿ tries, or 2^n/2tries. This is why a 256-bit elliptic curve key is about as strong as a 128-bit AES key: the work needed to find a 256-bit elliptic curve key (the square root of 2²⁵⁶, or 2¹²⁸) is about the same as the work needed to find a 128-bit AES, which also requires performing 2¹²⁸ operations.

With other public key algorithms, it's trickier. Suppose that you want to find an RSA key by factoring an RSA modulus into n = pq. There's a complicated algorithm called the "general number field sieve" that's fairly fast, and it can factor a 3,072-bit number with about the same level of work that it would take to try all 2¹²⁸ possible 128-bit AES keys. Because of this, we say that a 3,072-bit RSA key provides the same level of security as a 128-bit AES key.

Null terminate with extreme prejudice

I've been asked several times about Dan Kaminski's recent hack against X.509 certificates, so here's my explanation of it. I'd say it's not really an attack against X.509 certificates, but an attack that takes advantage of how some web browsers work. It all has to do with null-terminated strings.

A string is a sequence of characters. The string "hello," for example, is the sequence of characters 'h,' 'e,' 'l,' 'l,' and 'o,' which would be encoded as the sequence 104, 101, 108, 108, 111 if we're using the ASCII encoding rules. One way to indicate the end of a string is to add a special character to the end of a string that marks its end, and a common way to do this is with the null character, the character that encodes the value 0. To tell where the end of the string "hello" is, for example, we would add an additional null character to it so that it's represented as the sequence 104, 101, 108, 108, 111, 0, so that the five-character string "hello" is stored as a six-character null-terminated string. Programs that handle null-terminated strings would recognize the 0 as marking the end of the string, and ignore anything after that, and Dan Kaminski found a clever way to take advantage of that fact.

Suppose that you're a hacker who owns the domain yourehacked.com. Because you're the legitimate owner of this domain, you can get SSL certificates that identify your servers. You might want to get a certificate that can be used to authenticate www.yourehacked.com, for example, so that your hacker friends can tell that they're really on your web site and not on a web site run by law enforcement or some other part of the government. If you've set up subdomains to help you manage your web site, you might want to get an SSL certificate for something like www.hacks.yourehacked.com. If you're really creative, you might even request an SSL certificate for www.somebank.com%00.yourehacked.com, where I've indicated the null character by "%00," and Kaminski's hack takes advantage of how some browsers will display a URL like this one.

If a web browser assumes that a URL is a null-terminated string, when it looks at this URL, it's going to stop at www.somebank.com and ignore the rest of it. The part of the browser that handles certificates, however, handles more general strings, and it uses a tag-length-value (TLV) format to do this. In a TLV format, there's a tag that tells you that the following bytes are a string, then there's a length value that tells you how long the string is and then there's the value of the string itself.

This takes a bit more overhead than just handling null-terminated strings does, but it also lets you handle more general values. It also happens to be the way that information in a digital certificate is encoded. Because it's designed to handle more general strings, the part of the browser that handles certificates won't have any problem handling the URL www.somebank.com%00.yourehacked.com, but the parts of the browser that expect null-terminated strings will. In particular, a browser might display this URL as "www.somebank.com" in the its address bar even though it's really connected to part of the yourehacked.com site. So if a hacker can get people to go to this URL, they may think that they're really on the somebank.com web site even though they're really on the yourehacked.com web site. After all, there's a valid SSL connection, and the URL www.somebank.com appears in the address bar of their browser.

Apparently right after Kaminski gave his talk that described this hack, there was a flood of requests at public CAs for new certificates that contained null characters, but I haven't heard that any of these certificates were actually issued. We'll probably hear more about that in the next few weeks.

What you can and can't do in 39 days

The court order for the sale of the assets of General Motors went into effect a few days ago, 39 days after GM filed for Chapter 11 protection, paving the way for the new and improved GM to start business. That's a remarkably short time. Particularly when you compare it to how long it takes to do some other things, like creating, editing and issuing a technology standard. If GM can do it in 39 days, why can't standards groups do it in anything less than a few years?

Apparently it's possible to get a huge company through bankruptcy in only 39 days. It's too bad you can't complete a standard in the same amount of time.

Gresham's law

There's a little-known observation called "Gresham's law" that may or may not have some relevance to today's security market. Gresham's law says roughly that the introduction of debased currency will tend to make non-debased currency disappear from circulation when people tend to hold onto the currency with more intrinsic value and spend the rest. It's named for Thomas Gresham, an advisor to Queen Elizabeth, but Gresham wasn't the first to note this behavior. Nicole Oresme described it in his 1357 book De origine, natura, jure et mutationibus monetarum.

This principle doesn't apply to all cases where low-quality and high-quality alternatives compete in the marketplace. It also needs some sort of regulation to make it happen. In the case of coins, there are laws that say that both the non-debased coins and the debased ones are worth the same amount, so the non-debased ones tend to disappear from circulation. In cases where there is no requirement that the low quality alternative be worth the same as the high quality alternative, Gresham's law doesn’t predict that the high-quality alternative will disappear.

In the case of the PCI DSS, however, we may have a situation where Gresham's law does hold. This is because compliance officers are often looking for a solution that lets them pass their PCI DSS audit instead of a solution that actually provides strong and useful security. The PCI DSS now acts like a regulation that makes the high-quality and low-quality products equal because they both will let their users pass their PCI DSS audit. If this is the case, then we would expect high-quality security products to disappear, leaving their low-quality competitors as the only alternatives. This hasn't happened yet. Should we expect it to happen soon?

According to "Gresham's Law or Gresham's Fallacy," a paper recently written by Arthur Rolnick and Warren Weber of The Federal Reserve Bank of Minneapolis, Gresham's law isn't as true as we might think. Here's the abstract for their paper that sums up what they found:

The claim that bad money drives out good is one of the oldest and most cited in economics. Economists refer to this claim as Gresham’s law. Yet despite its seemingly universal acceptance, this claim does not warrant its status as a law. We find it has no convincing explanations and many overlooked exceptions. We propose an alternative hypothesis based on the costs of using a medium of exchange at a nonpar price: small-denomination currency undervalued at the mint tends to disappear from circulation while large-denomination currency usually circulates at premium. Examining a variety of historical episodes when market and legal prices were different, we find our “law” can explain history much better than Gresham’s.

Like most things, the applicability of Gresham's law turns out to be more complicated that you might first think, and it takes a more careful understanding of a particular situation to predict exactly what will or will not happen. If this is the case, it looks like we may not have to worry about high-quality security products disappearing because of the PCI DSS.

Ancient format-preserving encryption in FIPS 74

Although the format-preserving encryption algorithms that Phil Rogaway invented are very useful for encrypting data in a way that makes integrating encryption with legacy applications and complex IT environments particularly easy, it turns out that he wasn't the first to do this. An old, retired NIST document that describes how to use the DES encryption algorithm actually described a way to do it.

The NIST document that does this is the retired FIPS 74, "Federal Information Processing Standards Publication 1981 Guidelines for Implementing and Using the NBS Data Encryption Standard." This document is so old that it even refers to NIST as the National Bureau of Standards (NBS), a name that hasn't been used since 1988. FIPS 74 was withdrawn in 2005, so this technique should probably be considered obsolete. Here's how it works.

Suppose that we want to encrypt a credit card number that has 16 digits. The FIPS 74 technique encrypts one digit at a time. To do this it creates four bits that are XORed with the four bits that represent a digit. These four bits come from the lowest four bits of the output of a DES encryption. If the result of the XOR operation isn't a valid digit, then the next lowest four bits of the DES output are tried, etc. If all 16 of the four-bit values in the DES output don't give a valid digit, then the binary value 1001 is XORed with the plaintext input to get the ciphertext output. A new output of a DES encryption is used for each digit. Here's a diagram that shows how this works. This can easily be extended to more than digits. FIPS 74 describes techniques for encrypting both alphanumerics and arbitrary alphabets.

  

This technique seems to be fairly slow. Each digit it will take an average of (10/16)(1) + (6/16)(10/16)(2) + (6/16)²(10/16)(3) + ... + (6/16)¹⁴(10/16)(15) + (6/16)¹⁵(16) = 1.6 DES encryptions to encrypt, so that it will take an average of 25.6 DES encryptions to encrypt a single 16-digit credit card number.

Curiously, it looks like NIST hasn't defined a similar way to do format-preserving encryption with AES. Maybe there's really no need to do that because there exist other techniques that have strong proofs of security. The fact that a format-preserving encryption technique was included in FIPS 74 makes me think that there was an interest in the technology well before the PCI DSS increased the level of interest in encryption. Is the FIPS 74 technique used anywhere these days?

NIST gets in the Cloud Computing game

It looks like NIST is now getting interested in cloud computing. I found it somewhat interesting that the information on their web site about Cloud Computing is provided by their Computer Security Division, possibly indicating that security is one of the most important issues that need to be addressed before Cloud Computing can become more accepted.

Apparently, it's even tricky for NIST to sort through some of the claims that people make about Cloud Computing. According to the NIST's "Presentation on Effectively and Securely Using the Cloud Computing Paradigm v20", for example, there's a fairly wide range of estimates for the potential cost savings that Cloud Computing can allow: from 18 percent to 90 percent. That's a fairly big range.

Something that saves you 90 percent is certainly a much bigger deal than something that can save you 18 percent. If I had to bet, I'd say that the estimates of 90 percent are way off, and the real savings that are possible are much lower.

The 2010 Key Management Summit

The web site for the 2010 IEEE Key Management Summit is now up. This event will be held on May 4-5, 2010 in Lake Tahoe, Nevada, and will be collocated with the IEEE Symposium on Mass Storage  Systems and Technologies.

We're already looking for speakers for this event and hope to finalize the list in roughly November of this year. So if you're interested in presenting at this event, it's not too early to send in your submissions.

A better way to define cryptographic security

The level of protection that using cryptography actually provides can be confusing to many people. An 80-bit Skipjack key provides the same level of security as a 160-bit elliptic curve key or as a 1,024-bit RSA key, but understanding why this is true requires knowing more math than most people care to learn.

When it comes to quantifying the strength of cryptographic hash functions it gets even worse, because the strength of a hash function is very dependent on how it used. Finding a collision is the easiest attack on hash functions, and is the usual metric that's used to quantify the strength of one. But even if you can find a collision in a hash function, that doesn't mean that you can actually use that collision to defeat a cryptographic protocol. It's almost always more complicated than that.

This means that an accurate answer to exactly how secure something is can be so full of arcane crypto-details that only a specialist can understand it. This also means that the answer is useless to anyone other than specialists, which includes most of the almost 7 billion or so people that are currently alive.

Maybe there's a better way to quantify security that giving it in terms of bits of security. Maybe an arcane government regulation that dates back to 1967, 32 FR 11467, provides an example of a better way to do this.

32 FR 11467 defines the United States Standards for Grades of Green Olives. It's where the olive sizes like Large, Jumbo, Giant, Colossal, Mammoth, etc., are defined. It's also why olives always sound bigger that they are. If you open a can of Large olives, you'll probably be surprised by how small they really are. You need to get Colossal or Mammoth olives to really impress your holiday guests.

But despite the way in which it tricks people into buying a can of Large olives at least once in their life, the olive standard that's defined in 32 FR 11467 has been fairly successful and people seem to understand it better than they understand the way in which cryptographic security is quantified. Because it seems to work so well, why not model a standard for cryptographic security on it?

Instead of using bits of strength to quantify the strength of cryptography, the government could define several security levels that are defined by words instead of numbers. We could have levels like Secure, Very Secure, Highly Secure, Extremely Secure, etc. The level defined by "Secure" would have to be roughly the same as a fairly low level of security, of course, so that we'd be following the model that's worked so well with the United States Standards for Grades of Green Olives.

Some people might be tricked into buying something that is only Secure, but that wouldn't happen too often. People quickly learn that Large olives aren't really very big, and they'd learn quickly that something that's called "Secure" doesn't really provide that much protection against hackers.

I'll have to mention this idea to the people at NIST the next time that I talk to them.

The Philosophy of Tokenization

In 1846, Edgar Allen Poe published the essay "The Philosophy of Composition" in which he described how he came to write The Raven. What Poe says in this essay probably isn't true, but it almost certainly tells you how Poe wanted people to believe how he came to write The Raven. In other words, Poe may have invented more than the detective story. He may also have invented marketing.

Over 160 years after Poe wrote "The Philosophy of Composition" we see security vendors telling us things about their products that aren't really true but they want you to believe are true. What some tokenization vendors are claiming about their technology is a good example of this.

A tokenization system implements two functions: tokenize and detokenize. When a requesting application calls the tokenize function with a plaintext input, a tokenization system creates a token from the plaintext using a proprietary tokenization algorithm. The tokenization system then encrypts the plaintext using a cryptographic key that it gets from a key server. It then archives a copy of both the resulting ciphertext and the key used to encrypt it, and returns the token to the requesting application. When a requesting application calls the detokenize function with a token input, a tokenization system retrieves the archived ciphertext that corresponds to the token from its encrypted data archive and the key that was used to encrypt the ciphertext from its key archive. It then decrypts the ciphertext and returns the decrypted value to the requesting application.

Note that the secure operation of a tokenization system relies on the secure operation of several components: the tokenization server itself, as well as the key server that it uses, the key archive system and the encrypted data archive. The failure or compromise of any one of the components of this system will compromise the entire tokenization system.

The chances of an application being inappropriately implemented, configured or maintained is much greater that the chances of an adversary being able to defeat modern cryptography, so the reliability of a security system is limited by the chances of the system failing rather than an attacker defeating any type of cryptography. This means that tokenization systems are inherently less secure than systems with fewer components, which includes systems that implement encryption.

The security of a tokenization system also relies on the security of a proprietary tokenization algorithm. The operation performed by this algorithm is identical to the operations performed by well-known cryptographic algorithms like hash functions or encryption algorithms, which transform a message into a form from which it's infeasible to recover the original message. Oddly, the fact that its output is called a "token" instead of a "ciphertext" or a "message digest" has let tokenization algorithms avoid the careful public review that other cryptographic algorithms are subject to.

"Security through obscurity" has been known to be a bad system design principle for over 125 years - ever since Auguste Kerckoffs wrote "La cryptographie miltaire" in 1883. There's no reason why tokenization algorithms should be exempt from this general principle, and anyone thinking of using tokenization to protect sensitive data should ensure that the technology that they're considering is secure enough to withstand careful public review.

Tokenization really isn't more secure than encryption. Tokenization vendors just want us to think that it is.

A new type of standard

On May 7 there was a meeting in Plano, Texas, to discuss the plans for developing a standard for end-to-end encryption. This standard is a new work item that was recently approved by the X9 Accredited Standards Committee, the group that creates information security standards for the financial services industry. The meeting was jointly sponsored by Heartland Payment Systems and the Merchant Advisory Group, both of which clearly showed that they're now taking the security of credit card information very seriously.

The usual suspects showed up at this meeting - a combination of banks and security vendors. What was good to see was that some businesses also showed up that accept credit cards for payment for either goods or services. This was a good thing, and it should happen more often.

Most standards groups comprise just the vendors who make whatever technology is being standardized. This is usually bad, because vendors tend to create standards that reflect how they want to do things instead of how their customers want things to be done. But because their customers usually don't take part in the standards process, that's they best that the vendors can do.

Because the customers usually don't get involved in developing new standards, it's sometimes hard to feel sympathy for them when then end up with a standard that doesn't reflect their needs. So the fact that the merchants who will be using the end-to-end encryption standard are interested enough to get involved in developing a standard for it is definitely a good sign. There seems to be a good chance that the unprecedented level of involvement by the end users of the standard will end up making the standard fairly useful. It will be interesting to see how this standard develops over the next few months.

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.

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.

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.

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.

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.

Multi-factor authentication

The Accredited Standards Committee X9 develops American National Standards for the financial services industry. One of these standards, ANS X9.49, Secure Remote Access Mutual Authentication, is undergoing its mandatory 5-year review now. In a recent X9 meeting when we discussed updating this standard, we had an interesting discussion about exactly what “multi-factor authentication” is. Everyone agreed on the two following points:

1. It’s not really defined in any standard

2. The generally-accepted definition and its interpretation is really the result of vendors’ marketing efforts rather than anything substantial

Many books, articles, etc., define three “factors of authentication” which are typically defined roughly as:

1. Something that you know, like a password

2. Something that you have, like a token of some sort

3. Something that you are, like a biometric

There’s clearly some fuzziness here because of the way these are defined. One type of biometric is a behavioral biometric, like biometrics that look at how you type on a keyboard or write with a pen. Within this framework, you could argue that a password is just a behavioral biometric that tests whether or not you can remember a particular string. You could even argue that proving possession of a cryptographic key, like you do in the X.509 authentication protocol, is just like a behavioral biometric that tests whether or not you can flip a coin and get a particular series of heads and tails, although you probably wouldn't get many people to agree with you at this point.

Multi-factor authentication is usually assumed to be a technique that uses more than one of these factors. It’s often claimed that multi-factor authentication is inherently more secure than single-factor authentication, but if you look at the history of this claim, it actually came from a vendor that wanted to make their multi-factor authentication product sound better than competitors’ products.

Is there any substance to this claim?

Let’s compare two authentication schemes:

Scheme A, which requires a username/password plus a biometric 

Scheme B, which requires two different username/password combinations

Which one is more secure and why? Is there any reason to say that one is inherently more secure than the other? Particularly because it’s easy to force people to use reasonably strong passwords but essentially impossible to get the same level of security from biometrics, does using a biometric just because it’s a different authentication factor really add anything? Or will it actually provide an overall weaker authentication scheme when it's used?

Nobody at the X9 meeting was convinced that authentication using two or more authentication factors is actually any more secure than authentication using two or more independent means of authentication that happen to be the same factor, so the updated standard will probably reflect this. I’m looking forward to seeing the comments on this when the document gets voted on.

PCI DSS needs to be stricter

Complying with PCI DSS is a good first step towards protecting credit card numbers from the cyber-criminals who steal them and resell them to other cyber-criminals. On the other hand, the large and high-profile data breaches that we've seen in the past few years show that what the PCI DSS doesn't actually do is to actually provide any reasonable assurance that credit card numbers won't be stolen. Because there's a significant gap between complying with the PCI DSS and real security, the PCI DSS may actually end up protecting businesses who just worry about complying with the standard instead of using more meaningful security. Here's why.

Negligence is the failure to use reasonable care. If you don't meet an appropriate standard for care then you're negligent, and you’re liable for any damages that you might cause. If you do meet the standard of care then your unlucky victim bears the full cost of his injuries. As a general rule, government regulations can be used to establish a standard for reasonable care. So if you're in compliance with government regulations then you can argue that you're using reasonable care and you're not liable for injuries that you might accidentally cause. This is true for government regulations, but it wouldn't be too surprising if other regulations might also work this way. In particular, because there's no government standard for protection of credit card information, it wouldn't be too surprising if you could successfully argue that the PCI DSS establishes a standard for reasonable care.

This means that it's not hard to imagine a case where a company that's suffered a data breach but has also passed their PCI DSS audit can argue that they've used reasonable care with the credit card numbers that they lost. Suppose that they can also show that they've passed other audits. Maybe their data center has passed a Type 2 SAS 70 audit and they have an ISO 27002 Certificate of Compliance. In this case, it's probably even easier for them to convince a judge or jury that they've used reasonable care. The problem is, of course, is that there may not actually be a connection between passing these audits and having strong and meaningful security. But if they can make a convincing case that they've used reasonable care, they may be off the hook, even if their security is weak enough to allow hackers to easily bypass it.

In the case of PCI DSS, there doesn't seem to be much of a connection between being compliant with the PCI DSS and having strong security. Could this end up actually protecting companies that focus just on compliance instead of trying to actually protect their sensitive data against hackers?

Security for mobile banking

It looks like the Accredited Standards Committee X9, the group that makes American National Standards for the financial services industry, is soon going to start work on its ANS X9.112 Part 3, Wireless Management and Security Part 3: Mobile Banking, even though work on Part 2: ATM and POS hasn’t even started yet. The sudden interest in mobile banking security is apparently due to the introduction of vans that go to events like fairs and other festivals. These vans act like a mobile bank and have a wireless connection back to a brick-and-mortar bank. These banks-in-a-van use commonly accepted protocols like SSL to protect transactions that are sent over wireless connections, but that’s not good enough for the more security-conscious banks.

Banking information security standards are fairly strict, particularly when it comes to the use of cryptography, and there are X9 standards that define in great detail how encryption and key management need to be done if it’s to be considered good enough to protect financial transactions. The use of SSL in off-the-shelf web servers doesn’t even come close to the level of care required by X9’s key management standards, and the ANS X9.112 Part 3 will try to correct that.

Creating an SSL server certificate is relatively easy with most web servers, but the process isn’t done in a way that meets the level of security that security-conscious banks want to see. They’re used to the careful key management processes that are used to generate and install the keys that are used to protect ATMs, for example, and these are much stricter that what controls that a web server can provide. They require the generation of keys in secure hardware devices instead of in software, and require careful protection of the keys throughout their life. Most commercial web servers don’t provide a way to do key management that carefully, but that’s what ANS X9.112 Part 3 wants to require.

There’s probably a fairly small market for web servers that are secure enough to keep security-conscious banks happy, but security-conscious banks may be willing to pay a fairly high price for products that meet their needs. It will be interesting to see how the ANS X9.112 Part 3 standard evolves and how widely it’s implemented.

Updating FIPS 140-2

In the early days of Internet security, security consultants would often show a picture of an unplugged computer and tell you that the only safe computer was one that was unplugged. Only slightly more risky was one that was turned on but not connected to a network. Connecting your computer to a network was supposed to have the potential to cause all sorts of Bad Things to happen to you, and it made achieving a reasonable level of security extremely difficult to achieve.

Today, not connecting a computer to a network is almost unthinkable, and devices like PDAs and cell phones are part of the same networks that desktop computers are. The security of such networks is not perfect, but they certainly function well enough to keep businesses running. Many new security technologies have been invented to make such networks practical for business use. Some security technologies have fallen behind, however, and one of these is encryption, although it might be more accurate to say that some standards for cryptography haven't kept up with changing technology.

The leading encryption standard is the U.S. government's Security Requirement for Cryptographic Modules, also known as FIPS 140-2. This standard defines the best practices that cryptographic engineers should follow, and being validated as following these practices is required for any cryptography used by the US government.

FIPS 140-2 is a relatively successful standard. It is now recognized by many countries outside the U.S. and is the basis for the new ISO 19790 standard. It has its roots in the world of hardware, however, and doesn't adapt as well as it could to today's world where cryptography in software is far more common than cryptography in hardware.

The FIPS 140-2 standard evolved over the past few decades from the original standard for the venerable DES encryption algorithm. The first standard for DES mandated that the algorithm be implemented in hardware, a requirement that lasted for 11 years until the requirements were finally loosened to also allow implementing DES in software. The FIPS 140-2 standard is the direct descendant of these ancient standards for DES and they still strongly reflect their hardware roots.

So why can this be a problem? The recent experiences of an unlucky defense contractor may illustrate this.

I recently talked to people in the information security department large defense contractor. They had just received a mandate to encrypt all email messages tothe government using a product that was FIPS 140-2 validated and was operating in a government-approved mode, so that all cryptographic functions were performed as required by the FIPS 140-2 standard. As they looked into doing this, they were surprised to learn that none of the available email encryption products they found would actually operate in a useful way in a FIPS-approved mode.

By following the requirements of the standard, they had to effectively disconnect their computer from the network, putting their system in the same fairly risk-free state that security consultants used to joke about. They couldn't actually send an encrypted email using a FIPS-validated email encryption product because the restrictions of FIPS 140-2 were so strict. Their systems would probably be very secure when operating in an approved mode, but they would also be relatively useless.

The root of the problem turned out to be a requirement of FIPS 140-2 that makes perfect sense for hardware, but doesn't make as much sense for software. And when the email encryption products were configured to operate in strict accordance with the standard, they couldn't actually function. If the defense contractor operated any of the available products in non-approved mode they would work just fine, of course, and it seems that many users of FIPS-validated products end up having to implement such a workaround to get their products to function.

You can't help but wonder if the provisions of a standard that frequently require workarounds in this way are even worth having. If products can't actually be used in an approved mode, is the standard useful, or should it be updated to reflect the realities of a world in which cryptography is implemented in software?

Cryptography is a difficult and arcane subject, so having a standard that rigorously validates its correct operation is a good idea. But the current version of the FIPS 140-2 standard seems to have gone a bit too far and needs to be updated to reflect the realities of modern technologies and the way in which they are used. This standard is currently being reviewed and updated, and NIST should ensure that the result of their efforts is compatible with the technologies that need to be used by both the public and private sectors. Software is here to stay, and the security standards need to reflect this reality.

Ten little Soldiers

Ten little Soldier boys went out to dine;

One choked his little self and then there were nine.

Agatha Christie, And Then There Were None

The number of key management standards has grown dramatically in the past few years, and now there are over a dozen of them either completed or being worked on. With that many different standards, it’s sometimes hard to keep track of exactly what has been defined and in which document. Luckily, there’s a good summary of all of the different efforts here.

Not all of these standards overlap. Some just tell you what you need to do, but they don't tell you how to do it. Others tell you how to do it in a precise, interoperable way. The older standards tend to be the ones that just tell you what to do. The newer ones actually tell you how to do it.

We’re now seeing two interoperability standards emerge as the ones that vendors will actually implement, and we’ve now seen the first key management standard admit that it’s going nowhere. This happened yesterday when Arshad Noor, the person driving the Enterprise Key Management Infrastructure standard, withdrew his support from it. Here’s what he said about this:

I believe the policies at OASIS makes it difficult to put out a coherent message [on key-management] that benefits users in the IT industry. In light of the following facts:

* that charter members of the KMIP TC chose not to engage with the EKMI TC despite observing its activities for over two years [from within the OASIS EKMI TC];

* that some of [the KMIP charter members] were surreptitiously working on [the KMI] protocol while giving the appearance of engaging with [the IEEE 1619.3] industry standards group;

* that OASIS facilitated the creation of a new TC with overlapping charters rather than encourage charter members of the KMIP TC to engage in a constructive discussion with an existing OASIS TC that has a Committee Specification; and

* that there is nothing in OASIS policy to prevent yet another splinter group from the KMIP charter members to start yet another [key-management] related TC within OASIS, if it serves the splinter group' purposes

it appears that OASIS' policies are more sympathetic to IT vendors than to IT customers. In light of this, I believe that the [key-management] industry is better served by having the EKMI vision evolve in the 'do-or-die' competitive environment of the global open-source community, where technology and standards are largely driven by IT users than by vendors.

In other words, it looks like he’s throwing in the towel because EKMI never found support from other vendors. That’s definitely not a problem with the other two leading standards, the IEEE P1619.3 standard and the OASIS Key Management Interoperability Protocol (KMIP). The big security storage and security vendors are still backing them, and we’ll probably seem them both supported in shipping products before too long. Don't be surprised if other key management standards join EKMI soon. There are still too many of them.

Mehrabian's rule

Albert Mehrabian’s 7-38-55 rule is almost always misinterpreted. These misinterpretations probably aren’t too far from the truth, however, and they can probably explain why the Internet is such an obstacle to communicating effectively. Mehrabian’s 7-38-55 rule actually says that when we communicate face-to-face, how well we like the person that we’re communicating with depends on three factors: the words used, the tone of voice used, and the body language used. He first described this in his 1971 book Silent Messages, where he estimated that 7 percent of the overall level is due to the words used, 38 percent is due to the tone of voice used, and 55 percent due to the body language used. 

This is often generalized to saying that in any face-to-face communication that 7 percent of the information that we send is verbal, 38 percent is sent in our tone of voice and 55 percent is sent through body language. Mehrabian’s research doesn’t actually support this generalized result, but that hasn’t stopped people from calling this conjecture “Mehrabian’s rule,” or inaccurately attributing the generalized result to Mehrabian.

It’s probably the case that most communication is non-verbal, even if it doesn’t follow the 7-38-55 rule, and that’s why the Internet causes so many problems. Even if the exact fraction of the information that’s lost when we communicate on-line isn’t exactly 93 percent, it’s probably a significant part of it, and this causes many more misunderstandings than you would ever get face to face. Here’s an example of how this recently affected me.

There are now three IETF RFCs that describe identity-based encryption and how to use it in secure email. While getting one of these standards through the IETF bureaucracy I had to get three new media types defined for the types of data that get transported over HTTP when IBE is used: IBE public parameters, an IBE private key request and the IBE key that a of key server returns to a user.

There’s a mailing list where you propose new media types and other list subscribers get to critique your proposal. In my case, we had a heated debate over my proposal that turned out to be just over a slight misunderstanding in how one particular parameter was defined. If we were sitting down face to face, this misunderstanding would have been obvious almost immediately. But because we were only communication over email, lots of information was lost. Maybe it wasn’t exactly 93 percent of it, but it was a significant amount. This led to wasting several days in a debate that wouldn’t have taken more than a few minutes to settle face to face.

Lots of communications over the Internet seem to be plagued by the same problem, and because there’s no easy way to indicate tone of voice or body language over the Internet, we’re probably stuck with the imperfect communication that it allows. I suppose that you could write an IETF standard of some sort that might help fill the gaps in communication that the Internet creates, tags like <humor> and </humor> that you could use to indicate where you’re not being serious. But because you’d have to develop this standard over the Internet, it would be much harder to do than it needs to be.

What color pen to use

Sometimes it can be difficult to deal with large organizations because of the rigid policies and procedures that they often have. In some cases, they may not even know exactly what their own policies and procedures are. I came across an example of this several years ago when I worked for the US government and had to travel to Europe for a week or so. When I arrived at my destination, another US government office, I had to fill out some sort of paperwork, and I used the pen that I had in my pocket to do this. This prompted a conversation that went roughly like this:

Woman behind the counter: I’m sorry, I can’t accept that form. You used a BLUE pen to fill it out and regulations require that it only be filled out with a BLACK pen.

Me: Really? I don’t believe that. Show me the regulation that says that I can’t use a black pen.

The woman behind the counter then disappeared for a few minutes, clearly stunned by my unwillingness to accept that the use of blue pens was banned. When she finally returned she decided to accept the paperwork that I had filled out with a blue pen, but I could tell that she really didn't want to. I’ll never know if she gave up trying to find the regulation that banned the use of blue pens or realized that no such regulation existed. I know which one I think probably happened.

Another big data breach?

It looks like there has been another data breach at a large credit card processing operation. The details haven’t been made public yet, but it’s already being discussed on web sites that track data breaches. As soon as the forensics experts finish collecting the evidence that they need, there will probably be a public announcement that describes exactly what happened. We’ll probably find that the operation that has hacked has passed their PCI DSS audit yet was still vulnerable to hackers. This shouldn’t be too surprising to anyone by now. It probably shouldn’t even be considered newsworthy any more.

As I’ve mentioned before, there are good reasons to require any business that handles credit card transactions to be PCI DSS compliant. Credit card numbers are the main target of the determined cyber-criminals that are part of the multi-million dollar underground economy in sensitive information. The number of stolen credit card numbers outnumbers other sensitive information that’s traded by cyber-criminals by roughly a factor of 20 to 1, so they’re much more popular than even information like ATM PINs or bank account numbers.

Even though many politicians seem painfully oblivious to it, the law of supply and demand affects all markets, even those in stolen sensitive information: as the number of credit card numbers stolen in data breaches has increased dramatically over the past few years, the value of each stolen credit card number has dropped just as dramatically. This means that cyber-criminals now need to get millions of credit card numbers from a single hacking operation to justify the risk and the expense of such an operation. This seems to have led them to target credit card processing operations instead of merchants, and they’ve apparently been fairly successful at this, despite the increased level of security that the PCI DSS have required. This is probably because the evolution of the PCI DSS wasn’t designed to keep up with the current threat.

The first version of the PCI DSS didn’t require much more than what are considered best practices for information security. The subsequent versions increased the level of security required, and future versions will probably increase it even more. This has been a gradual and incremental process, and it clearly hasn’t kept up with the threat that professional cyber-criminals pose. As long as this process stays gradual and incremental, it seems likely that the cyber-criminals will be able to stay ahead of the security that PCI DSS compliance requires. What’s probably needed is a bigger step forward in security, and the combination of encryption and key management is probably the way to make that step.

The current version of the PCI DSS requires encryption of sensitive cardholder information, but it doesn’t require particularly strong key management processes, even though strong encryption and key management provide the basis for protecting sensitive information against even the most determined cyber-criminals. That’s how national governments protect their diplomatic and military secrets, after all. It seems to have worked fairly well for them, and there’s no reason to believe that the same model can’t also be applied to protecting other types of sensitive information. Any other way seems to be too weak to stop determined adversaries.

If the PCI Security Standards Council is serious about protecting sensitive cardholder information, and there’s no reason to believe that they’re not, we’ll probably see strong encryption and key management required in future versions of the PCI DSS. Until then, we’ll probably see more of the large-scale data breaches that have been in the news recently.

That's why we have standards

There's a story in The Local, a web site that has news from Sweden in English, that talks about the problems that the Swedish air force is having with their new JAS 39 Gripen aircraft. Apparently Sweden uses a proprietary protocol to communicate with older aircraft, and the newer models use the NATO standard for encrypted communications. This causes problems because but no other equipment that Sweden uses supports the NATO standard. That means that the new Swedish aircraft can't communicate with Swedish units on the ground unless they do so in the clear. D'oh!

It seems that standards are only useful if you actually follow them.

Design goals

Our current Internet runs on the TCP/IP protocol suite that was designed for use in the ARPANET, which completed its switch from the old Network Control Program (NCP) to TCP/IP on January 1, 1983. There's an interesting paper by David Clark called "The Design Philosophy of the DARPA Internet Protocols" that describes how TCP/IP came to be. We can also trace some of the security problems that have plagued the Internet since its beginning to the design criteria that this paper describes. The ARPANET was retired in 1990, but we're still feeling its influence today.

This paper tells us that there was a single fundamental goal in the design of TCP/IP and seven second-level goals. The fundamental goal was this:

The top level goal for the DARPA Internet Architecture was to develop an effective technique for multiplexed utilizations of existing interconnected networks.

There's probably no way that you can interpret that as laying the foundation for today's security problems. The second-level goals are where this creeps in. Those were the following:

1. Internet communications must continue despite the loss of networks or gateways.

2. The Internet must support multiple types of communications services.

3. The Internet architecture must accommodate a variety of networks.

4. The Internet architecture must permit distributed management of its resources.

5. The Internet architecture must be cost effective.

6. The Internet architecture must permit host attachment with a low level of effort.

7. The resources used in the Internet architecture must be accountable.

The last three of these are the ones aren't quite what today's business use of the Internet needs. In particular, cost effectiveness can be detrimental to security, a low-cost of attachment can be detrimental to quality-of-service guarantees, and accountability can be detrimental to efficiency.

You might argue that being cost effective doesn't really conflict with being secure if the costs of not being secure are properly accounted for, but security just didn't seem to be a concern of the architects of TCP/IP.

Is interoperable key management dead?

Could this be the end of the dream of interoperable key management? At Pulse 2009 last week, IBM talked about its new Key Management Interoperability Protocol (KMIP) that it intends to get standardized through OASIS and then support in its products. KMIP is a fairly complete standard, but it doesn’t address many of the issues that need to be addressed in key management products, particularly those that manage keys for encryption of data in storage. That’s where the IEEE P1619.3 Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data seems to work the best, which is why this standard has support from a wide range of storage and storage security vendors. 

But since KMIP doesn’t work with any of the other key management standards that are being developed, this means that interoperability can now only be attained in one of two ways: either IBM’s products need to support other standards like P1619.3, or vendors that currently plan to support P1619.3 need to also support KMIP. Either of these seems to defeat the purpose of having standards, which means that either is a bad idea. Customers need to provide some loud and clear feedback to key management vendors that explains how they don’t need multiple key management standards that will kill any possibility of interoperability between products from different vendors. Othewise, the problems that users of key management products are facing will never be solved. That’s not good for anyone.