Superconductor

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.

The PBA attack on RSA

I understand that we’re now living in a world in which everyone feels like they deserve their 15 minutes of fame, but I found the way that unwitting journalists managed to get it for security researchers Andrea Pellegrini, Valeria Bertacco and Todd Austin of the University of Michigan get their 15 minutes to be a bit frustrating.

Pelligrini, Bertacco and Austin actually did some fairly clever work: they found a way to cause bit errors in a microprocessor by carefully altering its input voltage, and then used these errors to help recover an RSA private signing key. For each bit error they were able to recover about 8 bits of private key, and were able to recover an entire 1,024-bit RSA key in about 100 hours.

If you’re interested in side-channel analysis and implementations of cryptography, their paper is well worth reading. On the other hand, their attack really isn’t the sort of thing to worry about too much. Devices that are designed to be secure, like HSMs and smart cards, filter the power so that you can't do attacks like the PBA attack, and with devices that aren't designed to be secure, there's always an easier way to recover a key from them than doing something like the PBA attack. This means that we won't be seeing hackers using the PBA attack any time soon, but you'd never think this from seeing the way it was reported by the media.

One headline read “'Severe' OpenSSL vuln busts public key crypto." That really doesn't seem to be a good summary of the PBA attack. The rest of the article didn't really to do much better.

Another headline said “RSA 1024-bit private key encryption cracked,” which was also a bit misleading. RSA-1024 wasn’t actually cracked. Instead, a particular implementation of it was beaten, and beaten in a way that really doesn’t pose a threat to most people. There’s absolutely nothing fundamentally wrong with RSA, although you really can’t tell that from this particular story.

The big problem seems to be that for each person who read and understood the PBA paper, there are probably thousands out there now wasting lots of time and energy worrying about whether or not the RSA-1024 that they use for SSL is secure enough. It almost certainly is, but you really can’t tell that from the media coverage of the PBA attack. 

Maybe some reporters ought to attend the next cryptography boot camp that our marketing guys hold. They did this at the RSA Conference last week, and from what I heard, the people who attended found it to be a very good use of a couple of hours. Maybe I’ll suggest that they invite some reporters to it the next time they organize it. Encryption is a tricky subject, and it's hard to understand all of the details of how it works. But if we had a few journalists who understood the basics of cryptography, we might not have had to spend so much time explaining exactly why this "severe vulnerability" isn't really worth worrying about.

Fortunately, Voltage's products use DSA for signatures instead of RSA. That will save us lots of time trying to explain to customers that while the PBA attack is actually some very clever research, it can't really be done to our products. Just saying that we don't use RSA for signatures is much easier.

Cloud computing at the RSA show

While too many of the pitches on the expo floor at this year's RSA Conference were about how various products or services could make you PCI DSS compliant, way too many of the talks this year were about cloud computing. Few of these talks really seemed to have anything new and interesting to say. Some seemed to be just thinly-veiled pitches for a cloud computing offering from vendors who had essentially bought speaking slots at the show with their sponsorship dollars.

Now, while cloud computing can be a very useful technology in some cases, it's also one that can create some interesting security challenges. But while talk after talk went on and on about the security challenges of cloud computing, one fairly obvious approach was rarely mentioned: encrypt your data before you put it into an external cloud computing environment.

The RSA Conference started out as a conference about cryptography. Despite this bit of history and the fact that cryptography can go a long way towards solving some of the tricky problems that cloud computing can cause, it was rarely mentioned at this year's conference. This struck me as being a bit ironic.

Tuesday at the RSA Conference - Bah-weep-graaaaagnah wheep ni ni bong

(Dozens of menacing SHARKTICONS appear in front of KUP and HOT ROD.)

KUP: Don't act hostile. I'll use the universal greeting.

HOT ROD: Universal greeting?

KUP: Watch. I'll have them eating out of my hand.

(KUP holds out his hands to show that he's unarmed and then addresses the SHARKTICONS.)

KUP: Bah-weep-graaaaagnah wheep ni ni bong.

HOT ROD: (puzzled) Bah-weep-graaaaagnah wheep ni ni bong?

SHARKTICONS: Bah-weep-graaaaagnah wheep ni ni bong.

KUP: See, the universal greeting works every time.

Transformers: The Movie, 1986

Many of the vendors at this year's RSA Conference seem to have adopted the idea of a universal greeting. Maybe they got this idea from Transformers: The Movie. Maybe they didn't, but if they didn't, it sure was hard to tell today.

The universal greeting that many of the vendors at this year's conference seem to have decided upon is "You'll never be PCI compliant without my product." Apparently they tired of the previous universal greetings "You'll never be HIPAA compliant without my product" and "You'll never be SOX compliant without my product."

In a few cases, the vendors could actually give a reasonable explanation of exactly what parts of the PCI DSS their products were designed to help customers address, but in even more cases they clearly hadn't really given this much thought. Instead, they seemed to be relying on the fear, uncertainty and doubt that the PCI DSS seems to have caused to get potential customers interested in their products.

I doubt that this is going to be a successful strategy. It certainly didn't work for the previous universal greetings, and I doubt that it will work this time, either.

On the other hand, I was happy to see that Voltage's partners who were exhibiting at the show didn't seem to have this problem at all. I turned my badge backwards to that they couldn't see that I was from Voltage and asked some of them a few questions about how their technology worked and exactly how it could help someone reach PCI compliance, and they all seemed to understand exactly what was required by the PCI DSS and how their technologies helped their customers comply with the PCI DSS. 

Maybe this was because our business development team is fairly selective about who they partner with. Maybe there's some other reason. I don't know for sure, but I do know that after hearing this year's universal greeting over and over again, it was a pleasant change of pace to actually talk to people who seemed to actually understand their customers' problems and how to solve them.

Monday at the RSA Conference - Miranda?

The exhibit hall of the RSA Conference was open for a couple of hours last night, so I got a chance to walk around and see what vendors were talking about this year. I have to say that I was not impressed in lots of cases - some vendors seemed to actually be moving backwards instead of forwards. It almost reminded me of the horror novella Miranda by John R. Little that won the 2008 Bram Stoker Award for Best Long Fiction. (No - this book has nothing to do with the planet Miranda from the movie Serenity.)

The protagonist of Miranda is a man who moves backwards through time instead of forwards. The book opens with him returning to life in a hospital at age 65 and ends, well, I'd hate to ruin a truly excellent book, so I'll just let you use your imagination. 

The entire book reinforces this backward-through-time theme. It starts with chapter 15 and counts down to chapter 1, for example, and the pages are also numbered in the reverse order. For me, this produced a particularly chilling effect because you could tell exactly how many pages were left of the protagonist's life. You can easily look at the last page of a book to see how many pages are left before the story is going to end, but that doesn't seem to provide the same effect that the reverse page numbering in Miranda does.

In any event, the parallel between a man moving backwards through time and the vendors who seemed to be moving backwards instead of forwards definitely struck me when I made my first circuit through the expo hall of the RSA Conference this year. I doubt that the vendors that I saw yesterday will suffer the same horrific end that the protagonist of Miranda did, but I doubt that things are going to work out well for them in the long run.

A maturity model for enterprise key management

Although it hasn't been posted on the web site yet, the schedule for the 2010 Key Management Summit is now all set. One of the talks sounds particularly interesting: "A Maturity Model for Enterprise Key Management," which will be presented by Keith Sollers and Chris Kostick of Ernst & Young.

E&Y seems to be one of leaders in many aspects of information security, at least among the big consulting firms. I haven't heard of any others who have enough experience with enterprise key management to give them the background for a talk like this one, for example, and I'm looking forward to hearing what they have to say about 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.

Sign up now for the 2010 Key Management Summit

It looks like the agenda for the 2010 Key Management Summit is all set. This year's event will include an interesting range of presentations: talks by industry analysts, vendors, users of key management technology, and even a talk or two about cutting-edge research. We're also considering having some time set aside for impromptu presentations.

Suppose that you're sitting through one of the talks and what the speaker says gives you an idea that the rest of us would be interested to hear. The intent is to have some time allocated to hear these ideas - probably something that can be summarized in a slide or two.

I'm not sure how well that will actually work in practice, but it sounds like an interesting idea. I hope that we'll get a chance to try it in May.

Key Management Summit - deadline for submissions approaching

The deadline for submissions for the 2010 Key Management Summit is rapidly approaching - you have until December 31 to submit proposals for talks, panel discussions, etc. That's not that far off.

Like the weasel-wording that you often see in financial statements says, past performance is no guarantee of what the future will bring, but if the 2010 Key Management Summit is anything at all like the previous one, then the 2010 meeting will be fairly good. The last one was actually one of the best meetings of its type that I've been to in the past several years.

Like the meeting's web site says:

Topics include, but are not limited to:

• Standards efforts relating to key management
• Government policies around key management
• Customer case-studies
• Panel discussions
• Key management technologies (avoid specific vendor references when possible)

If you have anything interesting to say in any of those areas, there's not much time left for a chance to tell other fans of key management what you know.

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.

Intel's AES instructions

I finally got around to looking at how Intel's AES instructions work. These are a new set of processor instructions that will soon be introduced that implement AES encryption and decryption. There are a total of six new instructions that do this: AESENC, AESENCLAST, AESDEC, AESDECLAST, AESKEYGENASSIST and ASEIMC. The first four of these do the actual encryption and decryption, and do this a round at a time, with the *LAST being what you need to use on the last round. AESKEYGENASSIST and AESIMC do key expansion, and you need to use these before you can encrypt or decrypt.

When you hear that there are two separate instructions for non-final rounds and the final round of an encryption or decryption, you'll probably realize that using these instructions isn't as simple as calling a function that encrypts or decrypts data. Instead, to use these instructions, you need to have a fairly detailed understanding of how AES works.

Using these instructions, here's roughly what encrypting with AES-128 looks like, where the register xmm1 initially holds the plaintext input and xmm2 through xmm12 hold the round keys from the key expansion:

pxor xmm1, xmm2

aesenc xmm1, xmm3

aesenc xmm1, xmm4

aesenc xmm1, xmm5

aesenc xmm1, xmm6

aesenc xmm1, xmm7

aesenc xmm1, xmm8

aesenc xmm1, xmm9

aesenc xmm1, xmm10

aesenc xmm1, xmm11

aesenclast xmm1, xmm12

That's not as simple as I thought would be when I first heard about the AES instructions. I imagined something that would work more like this:

aesenc data, key

Using the key expansions instructions is even more complicated. If you really want to see how to do that, you can download Intel's white paper here.

It's good to see hardware support for encryption becoming more widespread. Encryption was often too hard to use in the past, and it looks like Intel's AES instructions should make it easier than ever to implement encryption. The fact that they also make it faster doesn't hurt, either.

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?

Progress in quantum computing?

In the past few weeks, I've heard lots of comments about quantum computing. Because I heard so much about it, I thought that there must have been a big breakthrough of some sort. The last I had heard was that a team at IBM had managed to factor 15 using Shor's algorithm. Because of the sudden interest, I thought that this record must have been beaten in some way, and I don't mean by factoring 17.

But when I looked around the Internet, however, I couldn't find anything that talked about bigger successes, although others have reproduced the factorization of 15. This leads me to wonder what caused the sudden interest in quantum computing. Are there quantum computers out there that can do more than factor 15?

Being able to factor 15 with a quantum computer is actually a very impressive technical accomplishment, but it's not one that leads me to believe that existing public-key technologies are in danger of being rendered ineffective by the existence of quantum computers any  time soon. Perhaps ever. Or is there research out there that I didn't find?

I just don't get this one

Here’s another case where I just don’t get what the excitement is all about. In this case, it’s around the announcement of a new technology that identifies sensitive information on its way to a monitor and substitutes some sort of inoffensive pattern in place of the sensitive data. This technology is called Masking Gateway for Enterprises, or MAGEN.

I’m sure that this new technology is very impressive, but I’m also fairly sure that there’s going to be a better way to spend your security budget, like on encryption technology that protects the data both on its way to the monitor and after its displayed. You can even do this while keeping your encrypted data the same format at the unencrypted data, so integrating the encryption into existing applications really isn't that hard. You can encrypt a credit card number using format-preserving encryption, for example, and the encrypted credit card number will look just like an unencrypted one.

I haven’t heard of monitors being a big source of data leakage. What problem is this technology really trying to address?

Vanish: self-destructing data

There’s been lots of talk recently about “self-destructing data,” or data that loses its ability to be decrypted over time. I’ve been asked about this enough times to make it worth putting here so that I can refer future questions to this post, so here it is.

Roxana Geambasu, Tadayoshi Kohno, Amit Levy and Henry M. Levy, all of the University of Washington, recently published a paper that described a system that they called “Vanish.” This system creates a way to encrypt data that makes it possible to decrypt the data for a while, but after enough time passes, this ability goes away. Here’s how Vanish works. It's based on a clever application of Shamir secret sharing.

Shamir secret sharing is a way to split a key into n parts, any m of which allow you to reconstruct the key. It works by encoding the n pieces of the key as points on the curve of a polynomial of degree m - 1. Recall that any d + 1 points uniquely determines a polynomial of degree d, so that any two points uniquely determine a line, any three points uniquely determine a quadratic equation, and so on.

With Shamir secret sharing we use the key that we want to split for the constant coefficient of a polynomial of degree m - 1 and create n points on the curve of the polynomial which then act as the split parts of the key. When we do this, we can then find the polynomial's coefficients from any m of these parts. One of these coefficients is the key that was split, so we can also find the key that we need from any m of these parts.

Vanish ties the ability to look up the parts of a split key to information that changes over time. Dynamic IP addresses, for example, change fairly often, so they can be used for this. If you use a user’s IP address to look up part of a split key, then when a user’s IP address changes, you’ll also lose the ability to look up part of the split key.

When you initialize this scheme, you’ll be able to get all n of the n possible parts of the split key, but eventually you’ll get down to having only m - 1 of them available as the information that you need to look up the parts gradually disappears or changes. When that happens, you’ll no longer be able to get enough parts of the split key to recover it. Note that this happens very suddenly. One minute you can decrypt your data just fine and the next minute you can't. There's no slow degradation in the ability to decrypt.

Vanish seems like a simple and elegant scheme, but I’m not convinced that it’s really that important. In the business world, instead of having data disappear, it’s more important to have guaranteed access to encrypted data. That’s something that people will pay for. Vanish probably isn’t.

Why do people work on open-source software?

As every individual, therefore, endeavours as much as he can both to employ his capital in the support of domestic industry, and so to direct that industry that its produce may be of the greatest value; every individual necessarily labours to render the annual revenue of the society as great as he can. He generally, indeed, neither intends to promote the public interest, nor knows how much he is promoting it. By preferring the support of domestic to that of foreign industry, he intends only his own security; and by directing that industry in such a manner as its produce may be of the greatest value, he intends only his own gain, and he is in this, as in many other cases, led by an invisible hand to promote an end which was no part of his intention.

Adam Smith, An Inquiry into the Nature and Causes of the Wealth of Nations

It's not hard to create a plausible economic model that explains why open-source software exists. One argument is that enterprise software has a minimum cost associated with developing and marketing it. These costs include the engineers that write the software, the people that test it, the sales engineers that install it at customer sites, the sales people who help customers through the sales cycle, the marketing people who let customers know what's available to solve their problems, etc. The total cost of all of these isn't cheap, so if a particular application isn't worth more than that fixed cost, it can't be the basis for a profitable business.

But if there's a demand for something at a lower cost, someone will probably find a way to make it happen. It's much like minimum-wage laws. There are some jobs that just aren't worth the minimum wage, and when this is the case, people find ways to get those low-value jobs done, even if it involves breaking the law. They might hire illegal immigrants for less than the minimum wage. Or they might agree to pay someone cash to avoid the taxes that, from the point of view of the employer, are also part of their cost of labor.

On the other hand, an argument like this only describes market forces, Adam Smith's invisible hand that makes things happen. It might explain why open-source software exists, but doesn't really tell us why any particular person would make a decision to work on open-source software. That may require a different explanation. Here's one, and it's based on modeling contributing to open-source software as a tournament. It's much like the model that Stephen Levitt and Stephen J. Dubner used in their book Freakonomics to explain why so many drug dealers earn roughly the equivalent of the minimum wage.

It turns out that almost all drug dealers don't make very much money. These are the ones that actually sell the drugs on the streets. The real money is in managing an organization of drug dealers, and Levitt and Dubner describe how the entry-level drug dealers tolerate the low pay because they hope to eventually become one of the managers. In this sense, drug dealing can be modeled as a tournament that selects the most fit drug dealers and promotes the winners into the more lucrative jobs.

Maybe this model also applies to open-source software. After all, being a recognized contributor to a big, successful open-source project is also a good way to get a high-paying programming job. So it might be the case that the programmers who donate their time to open-source projects do this in the hope of becoming an open-source superstar one day. This doesn't sound obviously false, and it does give you a good way to start a conversation: "Did you know that open-source programmers are like drug dealers?"

Is AES secure enough?

There's been a lot of discussion in the past day or so about the security of the AES encryption algorithm. There's a paper by Alex Biryukov and Dmitry Khovratovich that describes an attack against AES-256 that can be done in much less time that brute-force exhaustion: 2¹¹⁹ trial encryptions instead of 2²⁵⁶. That's a huge difference. Is AES now so weak that we need to worry about it?

Absolutely not.

The attack that Biryukov and Khovratovich found also takes lots of data for it to work. Their attack that can be done in 2¹¹⁹ time also takes the same amount of data: 2¹¹⁹. That's a lot of ciphertexts.

The best estimates that I've seen say that the entire world produces a few exabytes of data per year. This estimate is actually from a few years ago, so it isn't that current. Let's suppose that the amount of data being created doubles each year. If that's the case, we probably have a few zettabytes of data being created per year right now.

A zettabyte is 10²¹ bytes, or about 2⁷⁰ bytes. That's a lot of data, but it's still a long way from 2¹¹⁹ ciphertexts. This means that an attack that takes that much data is totally impractical. Even if we assume that all of the data in the world is being used in an attack that's trying to recover a single AES key, it's still not enough. It would take roughly the amount of data that the entire world will produce in the next 50 years or so to get the amount of data that we'd need. And even then, the amount of time required is still prohibitive.

It's interesting that Biryukov and Khovratovich found a significant weakness in AES, and their work may give useful insights into how to design better symmetric encryption algorithms, but it's not the sort of weakness that anyone can actually use to actually recover data that's encrypted with AES.

Why businesses aren't profitable

Conventional wisdom tells us that the global recession that we're seeing now is the result of the recent problems with financial markets. A closer look at IT industry analyst reports, however, might tell us that there's another reason that businesses aren't doing as well as they'd like to, and that's because of their use of IT. In particular, if you add up the TCO estimates for all of the IT products that a typical business uses, you'll find that the cost of their IT systems is much greater than their revenue. In other words, there's absolutely no way that a business can both use IT systems and be profitable at the same time.

This leads me to believe that one of two things has to be true. One possibility is that the TCO estimates that we often see aren't really very meaningful. Another possibility is that it's just impractical to use modern IT products because they cost more that they're worth. If the first of these two is true, then we have nothing to worry about, except perhaps wasting lots of time on TCO estimates that don't really tell us anything useful. If the second is true, then the global economy is doomed until we revert to more primitive, pre-dot-com-era technologies. Which one is more likely?

Challenges with point-of-sale devices

The point-of-sale devices that retail operations use need to be very easy to use because they're often used by relatively untrained people. I saw an example of this a few years ago when I went to the local sporting goods store to pick up a package of white athletic socks.

I handed my credit card to the clerk in the store, who swiped it through his POS device, keyed in the amount of the transaction and waited for an authorization code to appear. There was apparently a problem with the connection of the POS device to the authorization service. What appeared on the LCD screen of the POS device was a pattern of random LCD segments that looked something like this:

 

The clerk didn't recognize this as anything other than a valid authorization code, and proceeded to carefully copy this pattern into the space for the authorization code onto the credit card payment slip. Apparently, nobody had told him to expect a series of numbers for the authorization code.

I left the store wondering what other types of mistakes had happened when the store processed credit cards. I doubt that I saw the worst mistake that an untrained person ever made.

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.

Time really isn't money

The saying that "time is money" probably isn't true. It may sound true, but peoples' behavior tells us that they really don't believe it. We tend to have a strong bias in favor or things that we get right now at the expense of things that we'll get later. This is why people are easily tempted by low introductory interest rates on credit cards, for example, even if the rate becomes unattractive after six months or so. We'd apparently rather pay less now, even when we know that it will cost us more later. This means that time really isn't money. It also may explain why open-source software is so popular.

Some open-source software is very good. Linux is a very good operating system and MySQL is a fairly good database (at least for some applications). On the other hand, some open-source software isn't quite as good. It's cheap, but it can be much harder to use than commercial alternatives. Sometimes it's much harder to use. OpenSSL, for example, is free, but can be very tricky to use. Some people tell me that I should use harsher language to describe it, but I'll let them do that themselves.

RSA's BSAFE SSL-C, on the other hand, is fairly easy to use, but isn't free. It doesn't actually cost that much, but it's definitely not free. You'd think that people would prefer BSAFE SSL-C over OpenSSL when they look at how many hours of engineering time they'd save by using BSAFE SSL-C, but this doesn't seem to happen very often. They'd prefer to pay the lower costs today that are measured in money, even though they'll have higher costs in the long run that are measured in time. The fact that time apparently really isn't money seems to be why this happens.

Lost knowledge

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

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

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

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

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

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

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.

Privacy and cloud computing

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

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

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

Cloud computing

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

Cath Everett, ZDNet.co.uk

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

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

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

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

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

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

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.

Information security is easy

Some things may seem easy, but turn out to be fairly difficult once you start looking at the details. Economics may provide a good example of this. Once when I was in a college class in economics, one of the other students asked the professor what we should study for our upcoming exam. "Economics is easy," he replied. "If you know how to increase the GDP without causing inflation or unemployment, you'll do just fine on the exam." This may sound easy enough, but nobody's quite figured out how to do it yet.

Information security is much the same way: it sounds easy in principle, but the details of getting it right are very difficult. And much like economists still don't really know how to do what sounds very simple, information security specialists still don't really know how to keep computer networks secure, although we're definitely getting better at it.

Technology is making some things easier to do, but much of it is still too hard for the average user to use. Information security seems to attract people with an uncommon set of aptitudes, and these people sometimes don't understand exactly how hard some things can be for the average user, who typically doesn't share the same uncommon set of aptitudes.

Unless security technologies are easy enough for the average user, they won't be used widely enough to make a difference. Until then, information security will stay harder that it first sounds. After all, it's really nothing more that ensuring that people can get the data that they're allowed to get and that others can't. That doesn't sound too hard, does it?

Why we need IP telephony

 

The reasons for and against IP telephony are the source of endless discussions between technologists. I finally heard a statement that may be useful in deciding whether or not the technology is as useful as its proponents claim:

IP telephony makes your phone as reliable as your computer.

Size does matter

Voltage is known for its innovative technologies. We're also a small company. It turns out that that might not be a coincidence. I learned this while reading "Entrepreneurial Risk and Market Entry," by Brian Wu and Anne Marie Knott. This paper talks about two things that I found interesting. The first relates to how risk-averse entrepreneurs are. The second relates to how big companies behave differently that small ones do.

One of the common misperceptions about entrepreneurs concerns their willingness to accept risks. It turns out that entrepreneurs really don't like to take risks – they're actually more risk averse than average. This is apparently balanced by their overestimation of their own abilities. They think that they're smarter than they really are. This means that they'll do things that others wouldn't think to do. They don't do these things because they willingly accept risk. Instead, they accept the risk because they don't know any better. Economists call this the difference between "demand uncertainty" and "ability uncertainty."

When it comes to big companies versus small companies, it turns out that there are three big differences in how they behave. Big companies tend to have broad and general strategies, which leaves parts of markets under-served. Small companies tend to take advantage of this and go after the under-served parts. Large companies tend to engage in slow and gradual innovation, while small companies tend to engage in more radical innovations. And when big companies do innovate, they tend to abandon their innovations because they don't fit well with their existing plans. Small companies don't do this.

Not surprisingly, this sums up fairly well how Voltage has succeeded. Larger security companies have broad product strategies in which encryption is just a small part. These strategies didn't create products that made secure email easy enough for most people to use, which left the opportunity for Voltage to succeed with its SecureMail products. The ease of use of SecureMail is based on identity-based encryption, a fairly radical innovation that makes encryption simpler and easier to use. Just to show that we follow all three of the differences that Wu and Knott list, I could mention that we don't have any plans to abandon our IBE technology, but that should be fairly obvious.

The Winchester Horror

I just finished reading The Winchester Horror, by William F. Nolan, the writer who's probably most famous for Logan's Run. The Winchester Horror is a novella that tells the story of a ghost that haunts the Winchester mansion in San Jose, California. If you don't have much time to read, novellas are great. They let you trick yourself into thinking that you're reading more than you really are because they're much shorter than most other books. Between January 1, 2009 and March 1, 2009, I actually managed to read 18 books. This may sound impressive, but when you consider the fact that that time includes part of my Christmas vacation and that most of the 18 books are actually novellas, it actually turns out to be much less impressive.

The Winchester mansion was built by Sara Winchester from 1884 to 1922 at a cost of roughly $5.5 million. Apparently, she was concerned that the ghosts of people killed by Winchester firearms would kill her if she stopped construction of the unusual building. The result of this 38-year project is a 160-room house that's truly bizarre. It has only 17 chimneys for its 47 fireplaces. It has stairs that lead to the ceiling. It has cupboards that open onto brick walls. It even has a door on one of the upper floors that opens onto a drop straight to the ground below. Much of it doesn't make any sense at all. It seems to have built without much planning, and it was fairly expensive. In other words, it's just like today's computer networks.

Much like the Winchester mansion grew in an unplanned way into what's there today, today's networks have also evolved in a similar way. And just like it's hard to make sense of some parts of the Winchester mansion, it's also hard to understand exactly how some networks could have ever got to the point where they are now. Nobody lives in the Winchester mansion today – it's now a tourist attraction. After Sara Winchester's death, it probably proved to be too annoying to actually live in. Unfortunately, it's not practical to just walk away from the networks that have grown over time into the unwieldy beasts that they are today. And although they may seem to be just as confusing as the Winchester mansion, it's unlikely that we'll be able to turn them into attractions that we can charge admission to, so we're stuck using them.

Because they've grown over time instead of being carefully planned, it's always very difficult to integrate two or more networks. Businesses often try to do this when they acquire other companies or try to work more closely with partners, and it's almost always much harder than you think it's going to be. You may have your version of the Winchester mansion, but the people that you want to integrate with have their own version, and it hasn't evolved in the same way that yours did. Your network may assume that all of your data is handled by the equivalent of the stairs that lead to the ceiling, and the other network may assume that all of its data gets handled by the equivalent of the cupboard that opens onto a brick wall. Getting these two networks to work together can be hard. Sometimes it's even impossible.

It's well known that most acquisitions don't out work very well. Incompatible corporate cultures are one big cause of this, but I have to wonder how many of these failures can be traced to the difficulties in getting different networks to work together.

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.

Machiavellian software engineering

The term "Machiavellian" has come to mean behaviour that combines diabolical cunning with a ruthless disregard for morality, but this may be due to the fact that the Niccolò Machiavelli's irony was missed by many readers of The Prince. Supporters of this interpretation point out that all of Machiavelli’s other writings supported a more republican view of politics, the fact that he had been imprisoned and tortured on the rack by the Medici family to whom he dedicated The Prince, and that Casare Borgia, whom Machiavelli cited as a role model in this book, was widely known as a fool and a failure. If this interpretation is correct, The Prince is probably one of the most widely-misunderstood books ever written.

From our point of view, almost 500 years after Machiavelli wrote The Prince, it's impossible to know for sure whether or not he meant the book to be taken literally, but the fact that many people interpret it as a serious guide to politics shows that if he meant the book to be a satire, he was much too subtle. This shouldn't be too surprising, for even less subtle arguments can be misunderstood, and the origins of what's now know as the waterfall model of software development provides an interesting example of this.

Winston Royce summarized the lessons that he had learned in large government software projects in his 1970 paper "Managing the Development of Large Software Systems." This paper is often cited as the basis for the waterfall model, but Royce's discussion of software development in this paper certainly doesn't suggest that the waterfall model is a good one that should be followed. Although Royce did describe what came to be known as the waterfall model, he also noted that it is "risky and invites failure." He also suggested that a more iterative process would be better, a process much like what we call agile models today.

Thus Royce was even less subtle than Machiavelli - he was fairly clear in expressing his disapproval of what came to be known as the waterfall model. So we might wonder why the model that Royce described as being bad was widely adopted while the agile models which Royce described as being good were largely ignored for many years. And although cynics might be tempted to note a possible similarity between Machiavelli being tortured by the Medicis and Royce's work on large government contracts, it's unlikely that Royce’s paper was ever interpreted as satire. So we need to find another reason to explain the adoption of the waterfall model.

One reason that the waterfall model was adopted soon after Royce wrote his famous paper may have been that it’s much easier to understand and define than agile methods. It's relatively easy to write standards that define the use of waterfall-like methods, but doing the same for agile methods is very difficult. As early as 1974, for example, the US Navy had already used the waterfall model as the basis for their MIL-STD-1679 standard, "Weapon System Software Development." By 1995, this had evolved into the ISO/IEC 12207 standard "Software Life Cycle Processes," keeping a strong bias towards the waterfall model as it did. But while the more rigid waterfall process has found its way into several standards, the more complicated agile methods have yet to find the same level of acceptance by standards bodies, and this may be because agile methods are more difficult to understand and define than more rigid models are. It may even be the case that even though we can easily list general principles that they may follow, we still don’t exactly know how to define agile methods, and this makes creating standards for them extremely difficult.

Many of the early discussions of software development models were based on the experiences in large government projects, where rigid, hierarchical structures tend to be preferred, and this probably led to a bias that favoured such structures in managing software projects. Software project managers may also have just supported what they believed to be feasible in the large government software projects with which they were familiar instead of promoting what they really thought was the best way to manage their projects. Even if they believed that agile models were better, it may have been the case that it wasn’t practical to use these within the constraints of their projects, so that they may have accepted an alternative that was practical for them to use, hoping that it would at least reduce some of the problems that they faced.

The adoption of the waterfall model may also have been a reaction to the more chaotic processes that were common in the early days of software engineering. When these processes were seen to not be working well, a natural reaction may have been to try to impose a more rigid structure, and the waterfall model provided an easy way to formalize this additional structure. So the eventual return to agile models that we see today may have been caused by the realization that rigid structures also had shortcomings. Because agile models are also not perfect, we shouldn't be too surprised if the pendulum swings back towards more structured approaches in the future. If the past is an accurate guide to this, we might expect this to start in the next ten years or so.

So it may have been the case that software project managers didn't misinterpret Royce's first discussion of the waterfall model as satire. Instead, they may have adopted the waterfall model because it was relatively easy, fit within the constraints they were accustomed to and seemed to be an adequate solution to some of the problems that they faced at the time. The fact that Royce first described it in a less-than-positive way may have been ignored because of these perceived advantages. So early software engineers didn’t develop the waterfall model from Royce’s work – they probably developed it in spite of it.

Machiavelli's reaction to this would probably depend on his intent when he wrote The Prince. If he meant it to be taken literally, he would probably admire the audacity that early software engineers showed when they pointed to Royce's paper as the first description of the waterfall model. But if he meant The Prince to be interpreted as satire, he might be surprised by how writing that was even less subtle that his could be misinterpreted by its readers.

Scrum seems to work

I once worked for a security product company that had serious management and organizational issues. This wasn't obvious at first, but it quickly became painfully clear. The point when I realized that there was absolutely no hope for this company was when I was told that people in marketing weren't allowed to talk to people in engineering. Instead, all communications between the two departments had to be through formal meetings. That's right - all of them.

Because the product management function was part marketing and the project management function was part of engineering, this meant that there was a huge obstacle to any communications at all. The project manager, who had done this sort of stuff for many years, assured me that this was the right way to do things. I believed that he was wrong back then and I still believe that he was wrong today. In retrospect, this was one of the worst ideas that I've ever seen. If you feel the need to ban all direct communications between marketing and engineering, you're probably doomed to failure. If you get to that point, why bother actually spend your time on making and selling products? It's only a matter of time until your organization fails, and you might as well as get a head start by updating your resume before you really need to.

At Voltage, we use an iterative and incremental process called Scrum. Scrum is somewhat trendy. Scrum isn't perfect, but it seems to have allowed us to get more useful features into our products more quickly than our previous software engineering processes allowed. It's certainly worked for us. It probably makes some people very uncomfortable - the type of people who insist that all discussions between marketing and engineering take place in formal meetings. But even if that's all that it can accomplish, it's probably worth looking at.

German farm animals in software

eierlegende Wollmilchsau

egg-laying wool-milk-sow, or a pig that lays eggs, in addition to making wool and milk

Developing enterprise software is tricky. In addition to being able to operate in the complicated IT environments that have grown and evolved over time, enterprise software also has to address the many, and sometimes conflicting, requirements that users have. In some cases, it seems that the best reason for studying formal logic in school isn't to understand what rarely-used terms like modus ponens and modus tollens mean. Instead, it's needed to help you reconcile requirements that can be represented as "P AND NOT P" in the language of formal logic because that's a reasonable way to model many customer requirements.

It's even more difficult than dealing with multiple conflicting requirements, because customers don't always give accurate or complete requirements to vendors. I was at a meeting recently where a customer of a particular vendor's key management solution mentioned that the key management technology was useless to them because it didn't support key hierarchies with more than six levels. The surprised vendor walked away grumbling that the customer had never mentioned this problem before, and was more than slightly upset that the customer chose to mention this problem in a public forum instead of bringing it up with either the vendor's support team or the sales representative that's responsible for that customer.

Most software vendors try fairly hard to provide customers with useful products. Voltage certainly does. Our product managers are routinely in their offices until fairly late at night trying to work all of the requirements that they're aware of into the development schedules for their products. Some of this work is probably reconciling conflicting requirements, or trying to figure out if they should really try to make an eierlegende Wollmilchsau. I know that I spent a fair amount of time on these problems when I was a product manager. That was several years ago, at the time of the dot-com boom, but it seems that that aspect of the job hasn't changed since then. I suppose that's part of the reason why product managers are worth what they're paid.

New tools for terrorists

Terrorism is one of the more serious threats that national governments have to deal with these days. Fortunately, academics have thought about what sort of dirty tricks terrorists may try next and how to prepare for them. Here's what one paper said:

"If recent trends in terrorism have taught us anything, it is that terrorists are nimble actors who can be innovative when necessary. At the same time, technological development is inherently dynamic, with one of the negative externalities of this dynamism being the opportunities it can provide for malefactors. New technologies include cheap, accessible sprayers to disperse chemical agents, nanotech, proteinacious microspheres, aerosol vaccine delivery, bioinformatics, SNP's (single nucleotide polymorphisms) and Bose-Einstein condensates."

Bose-Einstein condensates? That's a state of matter that you get when you cool things down to temperatures of a few nanokelvins. When you get things very cold, enough atoms collapse into a single quantum state that you can actually see quantum effects. Liquids will crawl up the sides of a bottle, for example, because there's essentially no friction between the condensate and the bottle.

This doesn't sound like a good weapon for a terrorist to use. The equipment needed to keep a few thousand atoms of Bose-Einstein condensate cold is pretty big. It's definitely not the sort of thing that a terrorist can sneak past the TSA and onto an airplane. And if they could, what could they do with their exotic matter to cause trouble?

There is, however, a bizarre effect that's been called a "bosenova" that can occur when you put a Bose-Einstein condensate in the right kind of magnetic field. The word is based on the word "supernova," because the magnetic field can make the Bose-Einstein condensate fly apart in a dramatic explosion. Physicists don't seem to fully understand why bosenovas happen yet, but I doubt whether they're a suitable weapon for a terrorist to use.

In addition to having the equipment needed to make the Bose-Einstein condensate, you also need specialized equipment for making the precise kind of magnetic field that's needed to make the bosenova. And even if you have all of this equipment, it takes a huge amount of energy to make just a few thousand atoms of Bose-Einstein condensate. None of this equipment is cheap, and it's definitely not the kind of stuff that the average person could put together, even with a few million dollars in funding. I think that terrorists could probably find a better use for their time and money, so worrying about attacks using Bose-Einstein condensates is close to the bottom of the list of things that I worry about.

Happy Turkey Day

Today is Thanksgiving, the American holiday that's loosely based on the feast that the settlers of Plymouth, Massachusetts had to celebrate surviving their first New England winter. It's traditional to serve turkey on this holiday, so it's sometimes referred to as "Turkey Day." There may be another day, however, that's just as deserving of that name. This is a day in August instead of November.

August is the month that ITU-T Recommendation X.509 (1997): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework was approved. This is the standard that defined the format for digital certificates as well as the framework for using them. It was probably the first step in the wrong direction for public-key technology, and a step that has made public-key technology more difficult than it needs to be.

It's also probably the reason that the adoption of public-key technology was negligible for many years. During this time, PKI vendors insisted that products that supported the X.509 standard were the only ones worthy of adopting, despite the many serious problems that PKI technology has. Customers seemed to believe this. Consultants made lots of money writing documents with important-sounding titles like "PKI Strategic Plan," that described how the use of X.509 certificates could solve lots of pressing security problems. Many customers tried the technology, but not too many deployed it on a wide scale, despite the pressing need for encryption of lots of sensitive data.

In retrospect, it seems odd that customers didn't question vendors' claims. It was really little more than a handful of vendors claiming that only technology that they happened to sell was the only solution worth considering and customers accepting this without asking too many questions.

Public-key technology was a significant breakthrough when it was invented in the 1970s. It made some things practical for the first time that were extremely cumbersome and expensive to do with just symmetric cryptography. But as the technology evolved, the idea of digital certificates that the X.509 standard defines proved to too difficult and expensive to implement and support. Aside from the single use in SSL for authenticating web servers, the use of X.509 certificates has found little use outside government projects, where its high costs don’t seem to matter as much. It's a technology that has definitely proven to be a turkey. If we could only find the exact day in August on which the first version of the X.509 standard was approved, we could add "X.509 Day" to the list of days that observe significant historical events. "Turkey Day" might also be a good name for it.

Counterfactual what?

If quantum cryptography and quantum computing seem to defy any reasonable intuition, counterfactual computing pushes this to an extreme limit. In counterfactual computing, we use the fact that a quantum system is in multiple states at once, but use this in an unusual way.

Instead of having a quantum system that is in multiple state that correspond to different calculations, like we do with quantum computing, in counterfactual computing, we think of a computer as being in two states at once: on and off. So if we interact with a computer, we will be interacting with it as it were both on and off at the same time.

Carrying this to the next logical step, we can then interact with a computer that is turned off, but get information out of it as if it were actually on. This may seem to make absolutely no sense, but it has actually been demonstrated in a laboratory by researchers.

Fortunately, there seem to be limits to what this technology is capable of, and it may turn out to be impossible to take advantage of its bizarre properties. Otherwise we could imagine assuming that a computer is in states that correspond to either having finished cracking a 256-bit cryptographic key or not having finished this calculation, and be able to break military-strength cryptography just by interacting with a computer that is in these two states. This would allow such attacks without even having to spend any computing resources on the attack.

With any luck, researchers will find that counterfactual computing is little more than a laboratory curiosity that only works in small, well-defined experiments, and is not suitable for use in anything more than trivial demonstrations.

Quantum computing

Quantum computing takes advantage of the ability of quantum information to be in more than one state at a time, and allows the construction of computers with very different properties than the ones that exist today. They also have some fairly unusual theoretical properties. Computations on existing computers are not reversible. In the simplest case, two bits go into an AND gate, but only one bit comes out, and there is no way to reverse the computation and determine the inputs of an AND gate from the outputs.

On quantum computers, however, every calculation is inherently reversible. This means that it's theoretically possible to use a quantum computer to perform a calculation, print out the result, and then step through the steps of the calculation in reverse, ending up back where it started.

The security of modern cryptography depends on certain mathematical problems being easy to compute one way and hard to compute the other way. Multiplying two numbers together is easy, but factoring a large number is hard, which is the basis for the security of the RSA scheme. Quantum computers make it possible to turn the hard mathematical problems that provide the basis for public-key cryptography, like integer factoring and calculation of discrete logarithms, into easy problems. This would make decrypting as easy as encrypting, which eliminates the security provided by the algorithms.

Because this would make encrypting and decrypting equally easy, there would be no way to overcome this problem just by making keys longer. All of the commonly-used public-key algorithms would be affected by the existence of quantum computers.

Quantum computers can also make it easier to defeat symmetric cryptography, like DES or AES, but only by a relatively small amount, and it is easy to increase the sizes of keys to keep them secure, even if quantum computers are available to an adversary. In particular, algorithms that can run on a quantum computer can reduce the effective key size of a symmetric algorithm by half, reducing the strength of a 256-bit key down to only 128 bits, for example.

Unlike public-key algorithms, where quantum computers totally eliminate the security provided by the algorithms, it is easy to increase the strength of symmetric algorithms to compensate for the existence of quantum computers: just double the key size. While speaking at the 30^th Anniversary of Public Key Cryptography event recently, Brian Snow, the former Technical Director of the NSA’s Information Assurance Directorate, said that this was the reason that the standard for AES defines keys up to 256 bits in length, keys that provide more security that will ever be needed. If quantum computing ever becomes practical, 256-bit AES keys will still provide the equivalent of 128 bits of strength, which is still more than adequate for almost all purposes.

Quantum computers have been built that use a small number of quantum bits, but they are not yet capable of performing useful calculations. A quantum computer with seven quantum bits has managed to factor the number 15 using an algorithm designed to run on a quantum computer, a result that is interesting because it shows that quantum computers can actually be constructed, but building one with enough quantum bits to threaten even 1,024-bit RSA keys is still a daunting engineering challenge.

Some experts believe that it will prove impossible to build such computers with enough quantum bits to do such calculations. Only time will tell if useful quantum computers can be built that can threaten the security of existing public-key cryptography, but even if this turns out to be possible, it is probably still several decades in the future.

Keeping data valuable

According to the Association for Information and Image Management, only 20 percent of corporate data is structured data, but structured data consumes 75 percent of corporate IT resources. Examples of structured data are the information in ERP systems, CRM systems, and finance systems. In each of these cases, the data is well understood. It's fairly easy to know both where it is and its exact format. This makes protecting it easy, whether you're using encryption or some alternative. Maybe saying that it's easy is an oversimplification.

It can still be tricky to integrate encryption with legacy systems that handle structured data because the size and format of data typically changes when you encrypt it. The new technology of Format-preserving Encryption goes a long way towards making legacy computing environments simpler to deal with, but even that will only protect 20 percent of your data. The remaining 80 percent is much harder to protect.

The remaining 80 percent of corporate data is unstructured. Examples of unstructured data are the information in e-mail, documents, spreadsheets. Even voicemails count as unstructured data. With unstructured data, you often don't know exactly where it is or what it's exact format it.

Suppose that you encrypt all of your unstructured data. Maybe you can do this with the DLP technology offered by vendors like EMC. Once you've encrypted your data, however, it may become much less valuable than it once was because you're probably unable to search it.

A significant part of the value of Google, after all, is due to the fact that they let you search lots of the world's data. If you couldn't do this, the world's data would be much less useful and much less valuable, and Google is valuable because they make the world’s data more valuable. Similarly, if you can't search your corporate data then it's less valuable than it could otherwise be. If you believe that most of the value of modern businesses is determined by the value of their information, this might make you think twice about trying to encrypt unstructured data. On the other hand, using identity-based encryption may provide a good way to encrypt data, yet still keep it searchable.

One feature of IBE is that all keys are calculated as needed. This means that you don't need to keep a database of private keys to do key recovery. This is because you can recalculate any private keys when they're needed. This means there's no need to store private in a secure key archive to do useful things like key recovery. This also lets you do clever things like doing content filtering of encrypted e-mail by delegating the permission to get IBE private keys to a filtering appliance.

It also can let you easily search encrypted data in much the same way. Delegate the permission to get IBE private keys to a search appliance and it can decrypt encrypted unstructured data, search it, and return the results of the search. You can even restrict the result of such a search to users that are authorized to decrypt the encrypted data that the search finds. By doing this, you can protect your unstructured data without greatly reducing its value, staying compliant the data security and privacy laws that complicate business these days, but keeping the value of one of your most valuable assets.

Unstructured data isn’t commonly encrypted today, but when it is, I wouldn't be surprised to find that encrypting it is a good application for IBE.

How much does US-VISIT really cost?

There's a recent article that describes how wasteful the US government's US-VISIT (U.S. Visitor and Immigration Status Indicator Technology) program has been. This Department of Homeland Security program uses new technologies, most notably biometrics, to collect and maintain data on people entering the US. Some people claim that over $15 billion have spent so far on this program, but it has only managed to catch a few suspicious people trying to enter the US. This certainly sounds like a lot of money.

It turns out that the $15 billion estimate probably isn't very accurate. The Government Accountability Office report on the US-VISIT program shows (Table 2 on page 13 of this document) the budget of the US-VISIT program to be this:

Budget ($ million)	2003	2004	2005	2006	2007
US-VISIT	$362	$328	$340	$337	$362

There's nowhere near $15 billion in the budget that the GAO lists. This means that either the GAO is off by roughly a factor of 10 or the news report that mentions the costs of the US-VISIT program is. The DHS certainly spends lots of money on security technology, and some of it is probably spent on things that aren't as useful as they could be.

The US-VISIT program installed new technology at 170 border crossings, and if the $15 billion figure was accurate, that would be roughly $88 million in equipment of each crossing point. Even with the high prices that the government pays for some technology, you'd probably be hard pressed to put that much high-tech gear at a border crossing. I'm betting that the GAO got this one right.

Quantum cryptography

Our intuition is developed by watching the world around us. This intuition works fairly well in situations that we usually encounter, but when we stray too far from these, our intuition fails miserably, and we have to fall back on mathematics and physics to understand how things work. In particular, if things get too big or go too fast, then our intuition fails, and we need to fall back on Einstein's theories of relativity to explain things accurately. GPS satellites, for example, are affected by both of these possibilities. They are near a big, heavy object (the Earth) and they go fairly fast in their orbits. Relativity tells us that time gets distorted in either of these cases, and we find that we need the framework of relativity if we want to make GPS satellites accurate enough to be useful. Without the use of relativity to correct for the slight time distortions that these satellites experience, position errors in a GPS system would accumulate at a rate of roughly 6 miles per day.

Our intuition also fails when things get very small. This is the realm of quantum mechanics, and the models that predict things accurately on this scale are nothing like what we see in our daily lives. In particular, quantum mechanics tells us that quantum systems exist in all possible states at once, and that measuring such a system collapses it into one of the possible states, losing information about the other states when it does this. So while a classical bit is either a logical 0 or a logical 1, a quantum bit can be both 0 and 1 at the same time, and if we measure its state it will turn into either a 0 or a 1, losing all of the information about the other state. This means that any information that we encode as quantum states has very different properties than the information that we encode using classical bits and bytes. It also provides the basis for three interesting technologies: quantum cryptography, quantum computing, and counterfactual computing. The most mature of these is quantum cryptography.

The term "quantum cryptography" is a bit misleading. The term describes a technology that is used to distribute cryptographic keys that are encoded as quantum information, so "quantum key distribution" is a more descriptive name for it.

An adversary who intercepts a transmission protected with quantum cryptography will destroy some of this quantum information when he tries to determine the state of what he intercepted. When this happens, he will be unable to make exact copies of the information, so he will be unable to retransmit an exact copy of what he received. Because of this, the intended receiver will be able to tell that this transmission was intercepted, and decide to not use the key that was observed by the eavesdropper. So quantum cryptography cannot stop an adversary from eavesdropping, but it can detect when such eavesdropping has happened. The first quantum cryptography protocol was invented by 1984 by Charles Bennett and François Brassard, and is commonly called the BB84 protocol.

In the BB84 protocol, for each bit that the sender needs to transmit, he needs to pick a coordinate system with which to encode the bit. This defines what states the quantum information contains. He can use coordinates based on the familiar binary 0 and 1, or he can use other sets of coordinates. He then encodes the bits using the appropriate coordinate system and transmits them. After this, he sends a list of the coordinate systems that he used for each bit. The recipient needs both the encoded bits and the coordinate systems that were used to encode them to recover the information that was sent in this way.

An eavesdropper who intercepts the encoded bits will destroy some of the quantum information in them when he checks their state. This loss of information will cause errors that will be detected by the recipient – some errors usually happen in any transmission, but too many errors indicates that eavesdropping has occurred. An eavesdropper can also intercept the list of coordinate systems that is sent, but without the information that was encoded with them, knowing the coordinate systems is useless.

Information protected by quantum cryptography needs to be encoded in quantum states, and existing implementations use individual photons that are then transmitted over a fiber-optic link. Because any hardware in a communication channel that boosts the fading signal strength needs to interact with the signal, existing quantum cryptography technologies are limited to a single fiber-optic link. Repeaters act just an eavesdropper, and destroy quantum information when they interact with it.

Quantum cryptography is an established and proven technology. There have been commercially-available quantum cryptography products since 1999, and there are now two vendors from which the technology is available. On the other hand, while the problems of key distribution and key management are indeed difficult, they have not become so difficult that quantum cryptography is an attractive alternative for most commercial deployments. So although the technology has been available for quite a while, it has not yet become a commercial success. Maybe we'll be seeing more of it in the future.

Different points of view

Both customers and vendors like standards, and both groups get involved in the development of standards that are important to them. On the other hand, these efforts tend to stay fairly separate, with one set of standards groups representing the needs of customers and another set representing the needs of vendors. This is probably not the best situation.

Vendors tend to have much more technical expertise than their customers do, and they could certainly use this superior knowledge to help the customer-focused standards groups produce better standards. Customers, on the other hand, have a much better understanding of their needs than the vendors do, and the vendors could almost certainly use customer input in the standards that they develop.

Historically, there seems to be little interaction between the customer-centric standards groups and the vendor-centric standards groups, and this probably shouldn't be too surprising. Customers may feel daunted by the superior technical knowledge that vendors have and feel that they can’t contribute much to the vendor-centric standards. Vendors may feel daunted by the superior knowledge of business requirements and related issues that customers have and feel that they can't contribute much to customer-centric standards.

How to get the two types of standards groups talking to each other may be a tricky problem. Even if vendors wanted to help the customer-centric standards groups, it’s not clear that they can justify the resources to do this. Similarly, customers of technology might not be able to justify the resources required to actively participate in vendor-centric standards groups. I'm not sure what the best way to solve this problem is, but both customers and vendors would benefit from finding a way to incorporate each others' points of view into their efforts.

The standards balancing act

Standards are very useful, but defining exactly what's covered by a standard and what's not is a balancing act between the needs of customers and vendors. If the scales tip too far in either direction, bad things happen.

Customers of technology like interoperability. Just imagine a world without networking standards in which we'd need separate copies of the Internet that run each vendor’s equipment. This would probably lead to years of competition between competing vendors before the market settled on the winning technology. Before this happened, there would be a very inefficient and chaotic market. Customers who bought the losing technology would end up being stuck with incompatible products. The advance of technology would probably slow until the market sorted out which technology to move ahead with. This is a situation that customers want to avoid, and standards that guarantee interoperability is a good way to avoid these problems.

Vendors, on the other hand, need the ability to innovate and to differentiate their products from those of their competitors, and they need standards that are flexible enough to let them do this. Without this ability, their technology becomes commoditized and they have little incentive to invest millions of dollars in the research and development needed to create new technologies if the new technologies are destined to quickly become commodities.

The PKIX standards developed by the IETF may provide an example of what can happen when too many aspects of a technology are standardized. The PKIX standards ended up defining how most parts of a PKI operate and left little room for vendor innovation. This resulted in PKI technology quickly becoming a commodity and disappearing into the network infrastructure, and the market for PKI products essentially disappeared.

So a useful standard needs to guarantee some level of interoperability to be useful to customers, but it also needs to give vendors room for their innovations. In the Security in Storage Working Group, we’re developing a standard for key management technology. This standard should be completed by late 2009. Suppose that products that support it don’t appear until 2010. This means that we might not know if we found a reasonable balance between these competing needs for a couple of years, maybe not until 2012. So even though we’re aware of the need to balance the needs of customers with the needs of vendors, but we won’t know if we've done it well until it’s too late.

Moore or less

At the IEEE Symposium on Massive Storage Systems and Technologies last month, a common theme was that storage densities are increasing very quickly. Moore’s law, the observation that the number of transistors that can be manufactured on a single integrated circuit doubles roughly every two years, seemed to predict the progress of technology for over 40 years, although it has slowed somewhat recently. At MSST 2008 it was common to hear about how the density of storage is increasing at an even faster rate.

It doesn't take much of a difference to end up making a huge difference in the long run. If a country's GDP grows by 3 percent a year instead of 2 percent a year it will end up being about 28 percent larger after 25 years, which can make a huge difference in peoples' standard of living. If you believe storage people, the capacity of storage is increasing much faster than Moore's law. If this is true, it may lead to some interesting security architectures in a few decades.

Let's suppose that current security architectures are some sort of optimal mixture of computing power, storage and networking. Now if each of these resources is getting cheaper at a different rate, then we should expect to get a big difference in the optimal mixture of resources after a few decades. If storage is getting cheaper relative to computing power, for example, we should expect to see more storage in future security architectures and less computing power.

You probably need to account for more variables to actually get a reasonable idea of how future security architectures might differ from those of today. It's not just the amount of storage, for example - you probably also need to consider how fast access is to the storage. But even if we can't get an accurate idea of what future architectures will look like, we can be reasonably sure that they'll be fairly different from what we have today.

Software liability is a bad idea

Because all software seems to contain bugs, some people have called for laws that require software vendors to assume the liability that the license agreements for software almost always let them avoid. This is a bad idea. Doing this will make software extremely expensive. Plus, people have clearly shown that they really prefer buggy software with lots of features to more secure and reliable software.

To understand why requiring software vendors to assume the liability of problems caused by their products will just make things worse, consider the work of Ronald Coase. Coase showed that the total cost of things doesn't change if we change their ownership - it just moves around how it gets paid for. He was even awarded the Nobel Prize in Economics in 1991 for his work in this area, so it's probably a fairly significant result.

Suppose that you have a buggy application that has a TCO of $200, but using this software also causes you $300 in damage from the security and reliability problems that using it causes. In this case, your total cost is really $500. Currently, most software license agreements do their best to absolve the software vendor of any responsibility for the damage that buggy products cause, so their customers end up, in effect, paying more for the software. In this example, the users’ true cost is really $500 instead of just $200.

How does this change if we require that the software vendor assume the $300 liability? In that case, they will just increase the price of the product by $300. So the customers will still pay the same total amount, but the additional cost is now more obvious, not hidden like it was before. The insight that won the Nobel Prize for Coase was that this is always the case. So businesses are already paying the higher price for using buggy software. Because it's not just software licensing and support costs, this cost is probably in more than one part of their budgets, but it's still there somewhere.

Requiring the liability to be reflected in the licensing and support cost of software will probably increase its cost even more that we would expect using Coase’s analysis. This is because we really don’t know what bugs a particular piece of software has until it has been used for a while in real operational environments. If vendors have to assume the liability for this unknown risk, they're almost certain to be very conservative. After all, if they estimate too low, then they'll quickly go out of business. So we should expect to pay too much for software under such a scheme.

On the other hand, businesses have demonstrated fairly convincingly that features other than security and reliability are more important when they decide on which software to purchase. In the early days of operating system security, for example, it was possible to get systems certified at levels of security that ranged from a low of D (minimal protection) to a high of A1 (verified design). This system was called the Trusted Computer System Evaluation Criteria (TCSEC), and was more commonly called the "Orange Book" due to the orange cover of the document.

A few security vendors actually spent the time and effort to get their systems certified at the A1 level, but found that this turned out to be little more than an expensive exercise in paperwork. Customers really didn't want the highly-secure systems when they could get less expensive commodity systems that also had many more useful features and making highly-secure systems turned out to be a sure way to lose money.

Eventually the TCSEC evolved into the Common Criteria, but the use of the higher levels of security is still essentially confined to government customers. Governments are typically much more averse to risk than businesses are. The private sector accepts that losses will happen, and that cost-benefit tradeoffs need to be made when investing in risk management. From this point of view, if it will cost you $2 million to eliminate $1 million in fraud, then it's better to just accept the loss as cost of doing business.

Governments, however, are less willing to accept this, and will often spend much larger amounts of money to eliminate relatively small losses, and their security spending behavior reflects this. Because of this, they're the natural market for highly-secure yet expensive systems, but even government customers were historically uninterested in TCSEC level A1 systems and don't seem that interested in systems that have been certified to the highest levels that the Common Criteria defines.

If not even government customers are willing to use such technology, there's almost no chance at all that commercial customers will be. So it appears that there's really little interest in highly-secure and reliable software when customers need to choose between the higher quality and additional features.

Thus the arguments for requiring software vendors to assume the liability for damages caused by their products are bad for two reasons. It really won't make software any cheaper. Some businesses may even be reluctant to buy software at all if they have to pay all of its costs up front. It also seems that businesses have shown that they really don't want higher quality software, so by requiring software vendors to assume the liability for their products we're giving customers what they have shown that they really don't want. Requiring software vendors to assume liability for damages caused by the use of their products just doesn't make sense.

Trust, but verify

At the IEEE Symposium on Massive Storage Systems and Technologies last month, there were a number of vendors with booths in the exhibit area. Almost all of these were storage vendors. It was interesting hearing their pitches. They were quite different from the ones that you hear at information security shows. Here's the generic information security pitch that's commonly used today:

More than <random big number> data breaches occur each <random unit of time> causing over <random big number> dollars of loss annually

Source: <reference to an analyst report that's too vague to actually verify>

And the only way to stop this massive problem is to buy my product

The pitches of storage vendors seem to be different, yet also similar in some ways to the pitch that security vendors use. Here's a generic version of what I frequently heard at MSST 2008:

The amount of data that your business handles is growing at a rate of over <random big number> of terabytes per <random unit of time>

Source: <vague reference to some obscure academic paper>

And the only way to deal with this huge amount of data is to buy my product

One common fact that was mentioned was that it's been estimated that the amount of information will be doubling every 11 hours by the year 2010.

Yikes! That’s fairly soon. It looks like I'd better buy some of the leading-edge technologies that I saw at MSST 2008.

Wait a minute. The year 2010 isn't really that far off, and I don't see information doubling at anything approaching that rate. Because of this, I looked up the reference that the storage vendors point to. Here's the reference:

Nick Bontis and Jac Fitz-enz, "Intellectual capital ROI: a causal map of human capital antecedents and consequents," Journal of Intellectual Capital, Vol. 3, No. 3, 2002, pp. 223-247.

It turns out that this paper, in turn, just refers to an earlier one:

Nick Bontis, "Managing organizational knowledge by diagnosing intellectual capital: framing and advancing the state of the field," International Journal of Technology Management, Vol. 18, Nos. 5/6/7/8, 1999, pp. 433-463.

When I finally found a copy of this paper, here's what it said:

"The more knowledge is supplied (or shared) the more highly it is valued. Furthermore, when was the last time the demand for knowledge went down? In fact, scientific folklore in the early 1900s stated that all the information in the world doubled every 30 years. As the 1970s approached, that number was reduced to seven years. Prognosticators have pushed this notion further and state that by the year 2010 all the information in the world will double every 11 hours."

You can't get much vaguer than "prognosticators have pushed this notion further" without any further reference cited, can you? And when the paper containing that vague claim was then cited by other papers, there was no obvious way to see that it was probably not to be taken seriously. That took a bit of detective work.

So it certainly seems that there's probably no basis for believing that the information in the world will really be doubling every 11 hours in just a couple of years. That doesn't mean that you won't need lots of storage then. It just won't be so much storage that you'll need to learn what zetabytes and yottabytes are any time soon.

Another look at availability

The goals of an information security program are to provide confidentiality, integrity and availability of an organization’s information. Of these three, availability is probably the most overlooked by information security professionals. That's not terribly surprising. The people who worry the most about the availability of information are often not even part of a typical information security organization. They're more likely found in the organization that manages storage or keeps the networks running. This type of specialization is necessary with today's complex technology, but it's probably a good idea for security people to at least have a rough idea of what technology is available to keep information highly available.

There were some interesting examples of this at this year's IEEE Symposium on Massive Storage Systems and Technologies (MSST). This was held in the same location as the IEEE Key Management Summit and the IEEE Security in Storage Workshop last week, and provided a good opportunity for security specialists to see some of the recent developments in storage technology that make providing high availability of data possible. One interesting vendor at MSST 2008 was John Bordynuik, Inc., a company that specializes in recovering data from damaged or obsolete storage media.

The problems with reading damaged media should be fairly obvious. If your backup tapes get damaged to the point that they're unreadable, that's just as bad as not having backed up the data to begin with.

Another problem with storage media is that vendors often don't support more than a few generations of legacy technology. And because three generations of technology can appear over a five-year period, this can leave you unable to read storage media that are not really that old.

Some businesses are reluctant to encrypt backup tapes due to concerns about being able to decrypt them in the future. After all, if you can't get the right key needed to decrypt data, then encrypting your data is really nothing more than a cryptographic shredding process. You can avoid encrypting backup tapes if you really want to and still keep a reasonable level of security. You could do this by using addition physical security where the tapes are stored and using bonded couriers to transport them, for example.

On the other hand, the fact that you can't prevent using some sort of storage device to store your data is obvious, and with this use of storage devices comes some inherent risks of losing data. And although this appears to be an unavoidable risk, there are also technologies available now that greatly reduce these risks. Even if you're a security specialist who doesn't deal with these issues on a regular basis, it's probably good to know that this technology is available if you need it.

Product management is heck

Business is much like bloodless war, and it’s common for business leaders find inspiration in classics of military strategy like Sun Tzu’s The Art of War. So it might not be too surprising that the lessons learned from the recent war in Iraq may provide some useful insights into how to compete in the business world. In particular, what was learned about situational awareness may be particularly relevant for product managers.

Situational awareness focuses on the knowledge and understanding of their environment that helps people make complex decisions. It’s particularly important in cases where there is a lot of information available and a poor decision can have severe consequences. Thus situational awareness is critical for people like air traffic controllers, military commanders and doctors.

You can probably add product management to this list. There are often large amounts of information available to product managers and poor product management can bring down a company as easily as poor air traffic control can cause planes to crash. And although billions of dollars are spent each year on research and development of systems designed to increase the situational awareness in many fields, there seem to be few advances that help product managers do their jobs better.

Military commanders have two types of situational awareness to be concerned with.: situational awareness of friendly units and situational awareness of enemy units. Inadequate situational awareness of your own units can lead to casualties from friendly fire, which are just as serious as casualties caused by enemy action. Inadequate situational awareness of enemy units can lead to being outmaneuvered and defeated, even by a weaker enemy force. A good military commander should have both of these types of situational awareness.

This roughly parallels the two roles that a product manager plays. They need to work with their engineering organization to guide the development of their products. Doing this requires a situational awareness of their engineering organization that’s much like the situational awareness of their own units that military commanders need. Product managers also need situational awareness of the market in which their products compete and of their competitors in this market. This is much like the situational awareness that military commanders need of enemy units. And much like a successful military commander needs to understand both his units and those of the enemy, a product manager needs to understand both the development of his products as well as the way in which they will compete in their market if he’s going to be successful.

An ideal product manager should be able to excel at managing both his engineering organization as well as working with his marketing organization, but not everyone is equally skilled in both aspects of the job or has the time to do both well. So if you have to pick one area to excel in over the other, which one should it be? The lessons learned from the recent war in Iraq may provide some useful insight in this area.

One of the lessons learned in this war was that situational awareness of enemy units is more important that situational awareness of friendly ones. If you don’t keep track of friendly forces, they’ll usually try to cover your mistakes because they’re also keeping track of your units. On the other hand, enemy units are not so helpful. They don’t go out of their way to make sure that your mistakes don’t cause problems. They do the exact opposite, in fact – they look for your mistakes and try to exploit them for their benefit.

This suggests that product managers who need to focus on either dealing with their engineering organizations or dealing with their marketing organizations might do better to focus on marketing. If you don’t work with engineering as closely as you’d like to, it’s likely that your engineering organization will still try their best to deliver what’s needed. On the other hand, if you neglect marketing, then your competitors will eventually notice any missteps and will do their best to exploit them.

In an ideal world, all product managers would have an aptitude for both engineering management and marketing as well as the time to effectively manage both aspects of their products. In the real world, however, this never seems to happen, and it might be the case that product managers who need to decide how to spend their limited time should focus on marketing instead of engineering.