Superconductor

Should you rotate keys?

Some standards require you to periodically rotate your keys, or to decrypt encrypted data with the old key and then reencrypt it with a new key. The current version of the PCI DSS, requires this, for example. At the IEEE Key Management Summit last week, there was some discussion of whether or not rotating keys even makes sense these days.

Those arguing that rotating keys is unnecessary claimed that the desire to rotate keys is essentially a holdover from the days when the only standardized encryption algorithm was DES. DES has a fairly weak key – only 56 bits of key are actually used in the DES encryption algorithm. This means that defeating DES is feasible for an attacker with a relatively modest budget. In 1999, for example, the EFF built the DES Cracker, a special-purpose computer that can recover any DES key in just a few days of computation, for only $250,000. Against adversaries able to do this, rotating keys frequently may make sense.

On the other hand, a 128-bit AES key is much more secure than a 56-bit DES key. It's probably infeasible for even the richest national governments to build a special-purpose computer that can recover a 128-bit AES key in anything less than millions of years. For all practical purposes, adversaries can't beat AES.

If you periodically rotate your AES keys, there is a chance of some sort of problem happening every time that you decrypt and reencrypt your data. Maybe the hardware module that you use to do the encryption will fail. Maybe some sort of catastrophic error will occur in your key management system and you'll end up cryptographically shredding your data instead of protecting it. The chances of this happening may be small, but they’re probably much greater than the chances of an adversary beating AES. This means that rotating AES keys may actually cause a greater exposure to risk than not rotating them does.

But just because an adversary can't beat AES doesn't mean that they can't beat the key management system that creates and manages AES keys. So it might be the case that a more reasonable comparison is between an adversary's ability to beat a key management system and the chances of the same key management system causing a severe problem due to an unexpected failure of some sort. In this case, it's not clear which alternative offers the lowest risk. Key management technology and the products that implement it are still relatively new, so it may take a while to get enough data to say much about which alternative is really better. Until then, it's probably still a good idea to rotate keys regularly.

Putting it into perspective

The potential government bailout of the US banking industry is big news these days, and it's widely reported that this will probably require about $700 billion of government funding. That's a lot of money. Its so much money that it's somewhat trendy today to make comparisons that give this number some meaningful context.

$700 billion is roughly equal to the GDP of Taiwan. Or it's roughly 12 times Bill Gates' fortune. It's also almost five times the $150 billion cost of the bailout of the US savings and loan industry that happened in the 1990s.

On the other hand, $700 billion may not be that bad, at least compared to other costs. The Sarbanes-Oxley Act alone might have imposed even bigger costs on US businesses, for example. One study estimated the total costs of the Sarbanes-Oxley Act to be roughly $1.4 trillion. This estimate was reduced to only $1 trillion in a more careful follow-up study, but even the smaller figure is still a huge amount.

So although $700 billion is certainly a lot of money, it may not be that much more that the costs imposed by some government regulations.

A new report from ENISA

The European Network and Information Security Agency (ENISA) released the report Obtaining Support and Funding from Senior Management while Planning an Awareness Initiative last week. This report provides a framework for information security groups to follow that's supposed to help them maximize their chances of getting important security projects funded. The processes described by this report seems very similar to the one that consulting companies have been advising their clients to use for quite a while.

When I worked for a Big 4 consulting company about 10 years ago, we were advising our clients to use a strategy almost identical to the one that this report describes. Back then, the fact that information security is as much a business issue as a technical issue wasn't very widely understood. Once security groups accept this and learn to speak the same language that other business units do, getting support for security projects is always much easier. Just like the Big 4 were talking about how to do this ten years ago, the ENISA report tells you how to do this today. It's good to see that this is become more widely known.

If you're having trouble getting important security projects funded, this report may be able to give you some useful advice. It's certainly cheaper than hiring a Big 4 consultant.

The hard part of a key management standard

From a high level, a key management system only does a few things: it creates and manages cryptographic keys as well as the policies that govern their use. Defining exactly what keys are is fairly simple. Defining exactly what a policy is, on the other hand, can be fairly difficult, and defining a way to define policies is probably one of the most difficult parts of writing a useful key management standard. This is needed to guarantee interoperability between products from different vendors, so this is of more than just academic interest, at least to people trying to define standards for key management technologies. This is something that we'll probably have to address in the IEEE P1619.3 Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data, for example.

Some parts of a policy are fairly straightforward. Defining a validity period for a key is easy. It's even fairly easy to extend this idea to define how to allow keys to only be used certain ways at certain times. You might want to issue a key that only can be used to encrypt for the next 90 days, but can still be used to decrypt after that, and it's not hard to define a syntax for policies that can describe this particular case.

Users of encryption sometimes have rather unusual things that they want to include in a policy. One of the speakers at last week's Key Management Summit mentioned that he has a customer that needs to control the use of a key based on the geographical location of the user as defined by the output of a GPS system. An example of this might be that a key can only be issued to a user if the user is within 1 mile of (34º32'30''N, 115º47'30''W).

But while almost every key policy will need to define time periods of validity for keys, very few will probably need to define the geographic region in which keys can be used. So what we'll probably end up with a set of mandatory policy elements that all standards-compliant products can define and understand, plus a way for users to add additional optional policy elements to cover the rarer cases. Time periods of validity will probably be mandatory to implement while the location of a user will probably be one of the optional elements.

Don't abandon all hope

"Lasciate ogne speranza, voi ch'intrate."

Dante Alighieri, Inferno, 3.9

Identity-based encryption, or IBE, is just one of the many steps in the evolution of public-key technology. It has some definite advantages over other public-key technologies in some situations. That's why there are over 10 million users of IBE worldwide today. On the other hand, understanding why IBE works is fairly difficult. As public-key technology has evolved it has used more and more complicated mathematics, and IBE is just the next step in this evolution. Whatever comes after IBE will probably use even more complicated math.

The RSA and Diffie-Hellman schemes are the public-key schemes that were invented first. These aren't too difficult to understand. An undergraduate student in a technical subject probably has seen enough math to understand how they work. This means that there are probably millions of people worldwide who either understand these schemes or have the necessary background to understand them without too much effort.

Elliptic curve cryptography was probably the next major step in the evolution of public-key technology. It has some advantages over RSA and Diffie-Hellman, but it also relies on more difficult math. There are lots of people who understand enough to implement the technology, but there are relatively few people who really understand why it works. There are probably a few thousand people in the world with the necessary background for that. To the others who just want to implement it, it's just a "black box," and they trust that the algorithms that they implement make sense and do things in a secure way.

IBE builds on elliptic-curve cryptography and uses even more powerful mathematical machinery to do this. Unfortunately, using more and more powerful math also means that it's understandable to fewer and fewer people. It's even more of a "black box" that implementers tend to trust to do the right and secure thing. Voltage has lots of partners who use the Voltage IBE Toolkit to add IBE to their products, for example, but I don't think that any of them worry about exactly how the technology works or why it's secure. They're just interested in using the technology to solve their particular problems. There's a good reason why they don't need to worry about the security of IBE, and that's because there's a rigorous mathematical proof of its security.

As public-key technology became more and more complex, another change happened in the cryptographic community: proofs of security started becoming more and more common. Today, you'll almost never see a new public-key technology introduced without rigorous proofs of its security.  So if you're one of the vast majority of people who don't have the time or inclination to understand all of the details of how newer public-key technologies work and why they're safe to use, you don't have to abandon all hope. The proofs of security that are now commonplace should let you feel comfortable that the newer technologies are secure.

The lack of reliable data

One problem with the field of information security is that there's little reliable data about security vulnerabilities. Without reliable data on exactly what's a risk and what's not, it's very difficult to make good decisions about what's worth doing and what's not. It's even worse because information security deals with the vulnerabilities in very rapidly changing technology. So even if you had accurate data on the vulnerabilities that exist today, the changing technology landscape will probably make that data totally useless a year from now. Probably much sooner than that.

People have overcome similar problems in the past, and seeing how this was done might provide some insight into what could be done to get a better and more useful understanding of security vulnerabilities. The International Classification of Diseases (ICD) is probably a good model for this.

All members of the World Health Organization (WHO) report the causes of deaths in their country to the WHO in a standard format that's defined by the ICD. The most recent version of this scheme is ICD-10. If you're curious to see how people are dying throughout the world, you can find the combined data from all WHO members here, where it's broken down into the categories that ICD-10 defines. If you die from an intestinal nematode infection, your death will show up in category W032. If you die from an iodine deficiency, it's category W055. If you die in a traffic accident, it's code W150. If die from a snake bite, it's X20.

Having all WHO members report the causes of death in a standard format makes it easy to track the progress of many health and safety programs. If you want to learn how well the medical community is doing in eliminating bubonic plague, you can get the data that tracks this from the WHO. If you want to see how well safety features of automobiles are reducing the number of fatalities, you can learn this from the WHO data also.

If we'd like a system much like ICD-10, but applied to information security, we would need a way to report and classify security vulnerabilities. We're not that far from that today. NIST maintains the National Vulnerability Database which tracks known vulnerabilities, but there's not yet a good system to classify the vulnerabilities past a high-level description like a buffer-overflow vulnerability or a SQL injection vulnerability. Maybe that's good enough, but I doubt it. A better system might be needed. With the current NVD it's still hard to find exactly how many products have a particular class of vulnerability. That could just be a question of the user interface, however.

It would also be useful to know how many users are affected by each of the known security vulnerabilities. Vendors of commercial software probably know how many users there are of their products, but that information might be harder to get for open-source software. On the other hand, it might not be too difficult to get open-source projects to report how many downloads of their code that they have had, from which you can probably get a reasonable estimate of how many users have it installed. Having this data reported to a single organization might make it much easier to understand security vulnerabilities. NIST is probably the best organization to collect this data. Or is there a better alternative?

Getting predictable outcomes

COSO, the Committee of Sponsoring Organizations of the Treadway Commission, was formed in 1985 by the leading US accounting organizations to help address the problems of fraudulent financial reporting. Since then, COSO has written a number of reports that give guidance on many aspects of dealing with accounting issues, which includes elements of risk management. One of the more recent reports was the Enterprise Risk Management - Integrated Framework. The full report costs $75, but you can get the executive summary for free.

There are lots of interesting ideas in the Enterprise Risk Management - Integrated Framework. One of them concerns the big picture - why businesses should be interested in risk management and incorporate it into their strategic planning at the highest levels. One such idea that one of the important goals of risk management is ensuring predictability of outcomes. From this point of view, revenue of $200 million that's predictable is better that revenue that will average $200 million but could be anywhere in the range of $150 million to $250 million. So predictable outcomes should be preferred, even if they may be less desirable that some unpredictable outcomes.

This is essentially what insurance does. You pay slightly more for insurance than the average losses that you'd expect to incur without the insurance. The slight difference covers the operating costs of the insurance company. But by doing this, you gain predictability. Your loss will be no more that the cost of your insurance premiums plus whatever deductible you might have to pay.

Information security also provides a desirable level of predictability. Consider the case of laptop computers. About 1 in 10 laptops gets lost or stolen each year. Most of the lost laptops don't cause any problems. After all, most people really don't want the data on someone else's laptop.

Suppose that Alice is the VP of Marketing for an airline manufacturer and Bob is a sales manager for a plastic tubing company. Alice's laptop might contain marketing plans for her company, a few romantic comedies to watch on long flights and some classical music that she likes to listen to. Bob's laptop might contain the plans for his company's new line of narrow-threaded pipes that they plan to launch next quarter, a few action movies to watch on long flights and some rap music that he likes to listen to. Both Alice and Bob think that the information on their laptops is very valuable, but it's actually of no value at all to the other one. Alice doesn't care about what new types of pipe Bob will be selling next quarter, and has absolutely no interest in the movies and music on his laptop. Bob has a similar level of disinterest in everything on Alice's laptop.

This situation is probably typical, so that is a laptop is lost, the chances are that the person who ends up with it doesn't really want the data on the laptop, even if its original owner thought that it was worth millions of dollars. The serious trouble is caused by those rare cases where a lost laptop ends up in the hands of someone who does have an interest in the data on it. It doesn't happen often, but when it does, it can cause a major headache.

Encrypting the hard drive of laptops is good protection against these rare events. When they happen, the damage that they cause is greatly reduced. If you lose an encrypted laptop, the loss is limited to the value of the laptop and you're not gambling on who will end up with the data on the laptop. You'll have spent a little more, the cost of buying and supporting the encryption software, but you'll have gained a very predictable outcome by doing this. According to the COSO report, that's a goal that all businesses should have.

Was BlackBerry encryption really defeated?

The Economic Times has reported that the Indian government has developed the ability to read BlackBerry messages. If this is actually true, there are at least three ways in which this could have been done. Some are more likely than others. It's unlikely that the Indian government will tell us exactly how it can read BlackBerry messages, but we can probably get a good idea of what they actually can do.

The least likely way is that the Indian government actually developed a way to beat the encryption used by the BlackBerry devices. This is extremely unlikely. The encryption used by these devices is so strong that it's probably impossible for the Indian government to beat it.

Another possibility is that they might have found a way to defeat the key management used by the BlackBerry devices. It's almost always easier to attack key management that to attack encryption. It's possible that they found a way to do this, but it's still unlikely.

A third way is that the Indian government found a way to intercept BlackBerry messages when they're unencrypted. In most cases, the BlackBerry encryption just protects messages when they're transmitted wirelessly and doesn't protect them once they've moved off a wireless network. This means that there are lots of opportunities to intercept and read plaintext messages. This is relatively easy, and is probably what the Indian government managed to do.

What's going on?

People are clearly not losing interest in encryption. There are probably around 10 million users of identity-based encryption today, for example, which is 10 million more than there were just a few years ago. Voltage is doing fairly well. I suspect that other encryption vendors are also.

On the other hand, if you look at the number of Google searches for "encryption," you'll find that the number of searches has been gradually dropping for the past few years. There are now fewer than half as many of these searches than there were in 2004. What's going on? Are people finding information about encryption in some other way? Are more searches being done by other search engines? Or is there some other reason?

The Mpemba effect

Hot water freezes faster than cold water. Or does it? Cold water at 0.01 ºC will probably freeze before water at 99.99 ºC, and a small drop of cold water will probably freeze faster than a large quantity of hot water. So it's certainly not true that hot water always freezes faster than cold water. It is true in some cases, however, and there are enough of these cases to make the property interesting.

The fact that hot water sometimes freezes faster than cold water has been named the "Mpemba effect" after Erasto Mpemba, who brought it to the attention of the scientific community in 1963 while he was a high-school student in Tanzania. It turns out that stating the Mpemba effect in a careful way that's possible to verify experimentally is actually fairly tricky. You probably need something like this: "There exists a set of physical parameters and a pair of temperatures such that given two samples of water identical in these parameters and differing only in their initial uniform temperatures, the hotter of the two will freeze sooner."

If that's what it takes to say it carefully, it's easy to see why "hot water freezes faster than cold water" is preferred by most people.

You see the same preference for shorter yet not-quite-as-accurate descriptions of cryptographic schemes. It's easy to describe the Diffie-Hellman key exchange like this:

1. Alice uses her private key a to calculate g^a, which she sends to Bob
2. Bob uses his private key b to calculate g^b, which he sends to Alice
3. Alice calculates the shared secret g^ab as (g^b)^a
4. Bob calculates the shared secret g^ab as (g^a)^b

This is as sloppy as saying that hot water freezes faster than cold water, but it's also good enough for almost every time that you need to describe the Diffie-Hellman key exchange.

If you take the time to say everything precisely that you'll find that it takes too much long to say anything of consequence. So we accept a certain amount of inaccuracy in day-to-day conversation and reserve being careful to things that we put in writing. Try to describe something as simple as the Diffie-Hellman key exchange in careful and precise language and you'll find exactly how hard this can be.

It really just works

Encryption has a reputation of being notoriously difficult to use. There were probably good reasons to believe this at one time, but that time has passed. I finally realized this a while ago when I had to deal with the problems caused by a canceled credit card. I found some fraudulent charges on one of my credit cards. I had the old card canceled and a new one issued, but that caused another problem.

I collect books. Some books are hard to find, so I have standing orders placed with several book dealers. If they ever find a copy of books that I’m looking for in the price range that I can afford, they'll bill my credit card and ship me the book. So when the credit card number that I used for these orders was canceled, I had to get a new number to several book dealers throughout the world. I decided to send my credit card number in an encrypted e-mail, and used Voltage's VSN hosted e-mail service to do it.

Unsure that the recipients would be able to read the encrypted e-mails, I also sent another message that explained that an encrypted e-mail would follow that contained my new credit card number and that they should let me know if there were any problems.

Nobody asked for help.

Every single recipient was able to decrypt and read the messages that I sent them and update the credit card number that they had on file for me. That’s almost certainly proof that encryption is now easy enough for the average user.

Imagine trying to do that five years ago. You'd probably have an e-mail exchange that would go something like this:

"OK, you first need to get a digital certificate."

"A what?"

"No, really, it's easy. Just go to this URL and fill in the form."

"OK. Wait a minute. What's my 'organizational unit?' What's my 'locality?' Do I really have to read and understand this 'certificate policy?' That looks like a job for my lawyer."

"Never mind. I'll just e-mail you my credit card number in the clear."

It's still true today

“Heav’n has no rage like love to hatred turn’d,

Nor hell a fury like a woman scorn’d.”

William Congreve, The Mourning Bride (1697)

It certainly looks like PKI's time has past. Outside governments, very few organizations still use the technology for anything other than SSL. PKI probably peaked around the time of the dot-com boom, and has been on a steady decline ever since.

Most of the people who worked on the technology during the boom and were its biggest supporters have moved on to other things. Many of them are also now outspoken critics of the technology.

Maybe the words that William Congreve wrote over 300 years ago predict this.

Lovecraftian cryptography

"We live on a placid island in the midst of black seas of infinity and it was not meant that we should voyage far. Some day the piecing together of dissociated knowledge will open up such terrifying vistas of reality that we shall either go mad from the revelation or flee from the deadly light into the peace and safety of a new dark age."

H. P. Lovecraft, The Call of Cthulhu

H. P. Lovecraft was an early-twentieth-century American writer of horror, fantasy and science-fiction. He wasn't particularly successful, but he popularized some ideas that seem to have captured the imagination of many other writers. One of these ideas was that from time to time our world ends up being the battleground between ultra-powerful alien races who are vying for control of the universe and that whether mankind lives or dies is of little or no consequence in this vast cosmic struggle. The suggestion that everything that we do just doesn't matter in the big picture is an idea that some people find very compelling, perhaps even horrific.

Another idea was that there exist ancient tomes of forbidden knowledge that contain information about this great cosmic struggle that men are not meant to know. These fictional books include The Necronomicon by the mad Arab Abdul Alhazred, Cultes des Goules by Francois-Honore Balfour and Unaussprechlichen Kulten by Friedrich von Juntz. To read one of these books is to risk almost certain insanity. Sometimes reading even a few pages is enough to cause a nervous breakdown.

More that a few people that I've talked to recently have claimed that books on cryptography are much like Lovecraft's tomes of forbidden knowledge. They suggest that reading too much about cryptography carries the same risk of insanity that reading The Necronomicon does, for example.

It's not really that bad, is it?

For better or worse

A coworker of mine sometimes wonders if our modern technology has really made things any better for us. He probably has a point. In some cases, it probably hasn't really made things better. In other cases, it probably has.

When I bought my first house many years ago, I was surprised to see how many documents were being furiously faxed back and forth at the last minute between the various parties to the deal. Puzzled by this, I asked how they managed to close on mortgages before the days of fax machines. "Oh," I was told, "we didn't need this stuff back then."

So it looked like when fax machines created the ability to easily send additional paperwork back and forth, additional paperwork somehow became necessary when it wasn't necessary before. There was no drop in the foreclosure rate for mortgages after the introduction of fax machines, so that it looks like the additional faxed documents didn't decrease lenders' risks any. There was also no increase in the number of mortgages processed due to the ability to fax documents. So this use of fax machines is probably an example of modern technology that hasn't really made things better.

On the other hand, some technology does seem make things better. Using a fax machine didn't seem to make processing mortgages any better, but using e-mail does seem to do this. There's at least one mortgage company that I've heard of that uses encrypted e-mail for mortgage documents. This has let them make their process more efficient - so efficient that they're now processing about 20 percent more mortgages per year. This amounts to an increase in their revenue by about 20 percent, so this is probably a case where new technology actually made things better.

What's Eskimo for "security?"

It is common knowledge that there are many Eskimo words for "snow." Some references say that there dozens of different words; others say that there are hundreds. These estimates are all wrong. Geoffrey Pullum, in an article in Natural Language and Linguistic Theory ("The Great Eskimo Vocabulary Hoax", pp. 275-81, 1989), notes that this number is greatly inflated and gives a quick way to respond to people who will argue this point with you:

"C. W. Schultz-Lorentzen’s Dictionary of the West Greenlandic Eskimo Language (1927) gives just two possibly relevant roots: 'qanik,' meaning 'snow in the air,' and 'aput,' meaning 'snow on the ground.'"

He then suggests that you challenge your verbal adversary to provide a list of any others that they can think of. Most people probably won't take you up on this challenge.

Once you memorize the quote necessary to impress people with your knowledge of Eskimo languages and move on to the rest of the article, it turns out that Pullum's point is actually that it's only careless scholarship that has propagated the myth of lots of Eskimo words for "snow," and that facts should be checked more carefully than they often are.

The information security industry might learn a thing or two from "The Great Eskimo Vocabulary Hoax." In particular, some of the claims that vendors make about the benefits of their products won't survive careful fact checking any more than the claim that there are hundreds of Eskimo words for "snow" does.

The cost of managing passwords is probably a good example of this. Vendors of password management products combine data from various industry analysts to arrive at an estimate of over $110 per user per year for the cost of password resets. Some vendors' estimates are more than twice that high: over $300 per user per year.

The studies that vendors cite to support these alarming estimates are expensive, so customers rarely check them for accuracy or relevance. Don't let this stop you from verifying claims like this. If you don’t want to pay for the analysts' reports, you can always check with your in-house help-desk for their estimates for the cost of password management before you decide to deploy a password-management solution based on the business case you develop from vendor estimates. When I asked our system administrator how much time he spends on helping people with their password problems, he laughed and then told me that he spends almost no time at all doing this. Ask yours and see what they say.

Most organizations will find that their actual costs associated with passwords are much lower than the figures that vendors of password management products cite. The 2006 CSI/FBI Computer Crime and Security Survey estimated that the expense of supporting all deployed security technologies for large firms was roughly $142 per user per year, for example. If the cost of managing passwords was actually $110 of this $142, you would expect to see roughly three-fourths of the effort of security departments spent on password management alone, a situation that you'll rarely see.

So it looks like one of these estimates probably needs some work. Which are you inclined to believe - vendors trying to sell you password management products or the CSI/FBI survey?

Why key management?

There's lots of talk these days about key management. It certainly looks like lots of it is from vendors trying to position themselves as leaders in key management, although it's not always clear what they mean by that. So what exactly is key management and why should you care about it?

A cryptographic key is much like the combination to a safe. If you have the combination, it's easy to open a safe, but it's hard to open one without the combination. Similarly, if you have the right key, decrypting encrypted data is easy, but it's impractical without this key. But if you're careless with the combination to your safe, someone else can easily find it, and once they have it, 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 cryptography can be essentially eliminated. Key management covers all the details of how to handle keys carefully enough to ensure that 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.

An example of why key management is important can be seen in the recent news of ATM PINs being hacked. The news stories that covered these security breaches didn't give much detail about exactly what happened, but you can be fairly sure that the cryptography itself wasn't broken. That's just too hard to make it worth doing. On the other hand, there have been cases in the past where ATM systems have suffered security breaches, and these breaches have been caused by poor key management. That's probably what happened in the recent cases of PINs being hacked, too.

ATM systems have been hacked when key installation, generation or storage has not followed the relevant standards developed by the X9F subcommittee of the Accredited Standards Committee X9, the group that defines information security standards for the financial services industry. There have also been cases where inappropriate access to hardware security modules has made it possible for hackers to get keys that they shouldn't have been able to get. None of these is involves an attack on the cryptographic algorithms; they're all attacks that take advantage of poor key management. Keys weren’t handled carefully enough, and hackers took advantage of the careless processes.

So encryption alone isn't enough to protect sensitive data. It's part of a good solution, but it’s not the entire solution. To get a complete solution you also need good key management. It's almost always much easier for hackers to defeat key management than to defeat cryptography, so that’s probably where they'll focus their efforts. They'll attack your key management not your encryption. This means that to to protect your sensitive data you need to ensure that your key management is done carefully and securely. That's why you should care about key management.

Buggy hardware?

Several years ago, when I worked in a microelectronics research group, I received a panicked phone call from a person at one of the government's operations centers.

"My phone's been bugged," the caller said. "By the Russians." It turned out that he wanted me to come over to his office and find the bug that he thought was in his phone.

The caller sounded rather confused, so I didn't take him too seriously. I wondered why he thought the Russians had bugged his phone.  If my phone was bugged, I doubt that I'd know who bugged it. And even if you did manage to find a Russian bug, it probably wouldn't be labeled "Proudly made in the USSR" or something similar. People who bug phones probably like some degree of anonymity, after all.

The caller then explained how his phone would act strangely a few times every day. It would ring, but there would be no incoming call. The phone's buttons would light up by themselves and odd messages would scroll across its LCD display.

This sounded more than a bit like the power-on self-test for the caller's phone, so I suggested that he might be kicking the phone's power cord under his desk. I thought that this might have been causing his phone to lose power briefly and then start its self-test when power was restored by being bumped again.

The caller didn't like this idea at all. He was still convinced that his phone had been bugged by the Russians. I eventually asked him to keep an eye on the power cord for his phone and to call back the next day if the strange behavior of his phone wasn't connected with the power cord getting kicked.

He never called back.

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.

An idea for a new standard

An interesting issue concerning standards relates to weak cryptographic keys. Not long after a new cryptographic algorithm is invented, researchers find families of weak keys for that algorithm. These are keys whose properties result in a lower level of security than you'd expect. In some cases these weak keys can totally eliminate the protection provided by encryption. In other cases it just reduces it to a lower level. Once these weak keys are identified, any relevant standards are quickly amended to ban their use.

Each cryptographic algorithm has its own set of weak keys, and researchers have devoted a significant amount of time to finding them. In the case of the RSA algorithm, for example, if we have modulus N = pq and p-1 is relatively smooth, Pollard’s p-1 algorithm can quickly factor N, which then lets an attacker defeat RSA encryption. The MOV attack against elliptic curve cryptography, which can be done against curves with a low embedding degree, lets an attacker reduce the more difficult elliptic-curve discrete logarithm problem to the easier discrete logarithm problem in the multiplicative group of a finite field.

DES also has a set of four weak keys and 12 so-called semi-weak keys. These keys don't provide the same sort of advantage to an attacker that the weak keys of RSA or ECC do. The weak DES keys just produce 16 identical subkeys that are used in the DES key schedule. The semi-weak DES keys produce only two different subkeys, each of which ends up being used eight times.

Weak keys are actually fairly rare. In most cases, the chances of randomly picking a weak key are roughly like the chances of randomly guessing a key by chance. This happens so rarely that it's usually not even worth the effort to test for weak keys. Because this is the case, there might be a better use of researchers' time than looking for weak keys, and here's an idea for what they might want to think about instead.

If researchers were to focus its efforts on discovering the strongest possible key for each algorithm instead of finding weak keys, we could then standardize on this key to ensure that all users of the technology benefit from the strongest possible security. Maybe that's an approach worth trying. I should probably write this up as a new work item for the X9F1 working group. I'll have to make sure that I submit it on April 1.

Government Regulation in Security: Good or Bad

You want to protect yourself in cyberspace from the thieves and other criminals. So you probably take precautions, such as using anti-virus software and a Spam filter, and keeping your sensitive data secure on your computers.

The problem is that other entities have your sensitive information on their machines and in their databases. You have no control over what measures they take to protect your identity. No matter how much effort you expend to protect yourself, your safety is dependent on other people. Furthermore, some of these other people have very little incentive to protect your info. If they spend money on security, they reduce their profits. But if they don't spend money on security and something bad happens, the damage doesn't affect them, it affects other people.  The operator of some internet concern can take the attitude, "I wouldn't like it if someone stole our customers' identities, but it's not my identity. I'm not the one who suffers."

It's kind of like valet parking. The valet company might take the attitude, "I don't like it when people steal cars, but it's not my car. It doesn't really affect me."

That's not exactly a valid comparison, after all, a valet company can be held liable for losses if their security was too lax, or if they are negligent. That's government regulation. If you like using valet parking, you're probably glad that the government steps in and has created some laws to give the valet companies significant incentive to take precautions with your car.

In cyberspace, various governments have stepped in to create laws giving companies incentives to employ security if they possess people's personal information. As with valet parking it might be liability. The government does not mandate that the company take precautions, or if they do take precautions exactly what they should do, but if something goes wrong, the company can be forced to pay customers remuneration, or pay fines to the government. Other regulations describe the steps companies must take, or prohibit various activities.

A more libertarian approach would be "buyer beware". Do some research before doing business with a company. Or join a private organization that does the research for you. You pay a fee and get access to the reports. Or buy insurance. If something goes wrong, the insurance company reimburses you for your losses. The insurance companies would then have an incentive to do the research and advise you on which companies to avoid. Maybe they would even have lists of the bad companies, and declare they will not reimburse if you incur a loss with them. If a company is lax with security, customers will stay away. The company that spends money on security will have smaller profits, but that's better than going bankrupt.

Which is better? Government intervention or market forces? In some ways, government is similar to the mythical private company researcher (which is not that mythical when you look at Consumer Reports, Morningstar, and other such organizations). The difference is in whether payment is voluntary or not. Also, with most of the government solutions, if you incur a loss, you don't get any money back. The company loses, but so do you. On the other hand, the free market approach still requires a government that enforces private contracts. And with the market solutions, who keeps an eye on the organizations who claim to do research or the insurance companies? Other private watchdogs ("it's turtles all the way down").

Would somebody who favors the market approach be willing to say there is no liability? That there is very little right to collect from negligent or even fraudulent people? Only insurance companies? And let the insurance companies do research? The government then regulates only the insurance companies.

Would someone who favors government solutions be willing to live with the "lag" the time between discovering something new and government's response to it?

The Key Management Summit

It will soon be time for the IEEE Key Management Summit, which will be held September 23-24 in Baltimore, Maryland. It will bring together academics, customers and key management vendors to discuss the requirements for key management technology and how the evolving key management standards can work together, at least that's the plan. It looks like it might not quite work out as well as the organizers had hoped – it looks like almost everyone coming is from a security vendor. This means that we won’t be getting much of the customers' point of view on key management at all.

That's disappointing. I'll be attending the event, and the panel discussions with customers were the part that I was looking forward to the most. It's hard to find out what customers really want without talking to them, and I was hoping to use these panel discussions to get a better idea of what people are looking for in key management products.

After the customer panels, my favorites are probably a toss-up between the talks by NSA and NIST and the panel discussion about the different key management standards. NSA seems to influence the thinking at NIST, and the thinking at NIST seems to influence the rest of the world, at least when it comes to information security. Because of this, I'd like to hear what their thoughts are on the subject.

The panel discussion about the different key management standards might also be interesting. There are already a number of standards out there on key management, but these focus more on what to do, not on how to do it. Because of this, they really don't provide the level of detail that vendors need to make interoperable products. There are three main standards for key management that are being developed now that will actually allow the creation of interoperable products, and each has their own set of strengths and weaknesses.

The Provisioning of Symmetric Keys (KEYPROV) working group of the IETF is working on the Dynamic Symmetric Key Provisioning Protocol (DSKPP). This lets you initialize a device with a symmetric key, but without using any public-key operations. It's an interesting and useful idea, but one that seems to have rather limited uses.

The Enterprise Key Management Infrastructure (EKMI) Technical Committee of OASIS is working on the Symmetric Key Services Markup Language (SKSML), an XML-based protocol for managing symmetric keys and the policies that govern their use. This standard seems to just represent the work of a single small company, and has little support from other vendors. Because of this, I don't think that it will be very widely adopted.

The Security in Storage Working Group of the IEEE is working on the P1619.3 Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data. This one looks like a winner – it solves a pressing problem and has lots of vendor support. On the other hand, the progress of the standard has apparently been crippled recently by politics and the inability of the working group to make the simplest of decisions. If the working group can overcome these difficulties, this standard probably stands the best chance of being successful.

So I'm looking forward to seeing the panel discussion on standards to see how the various groups position their work relative to the others. It will be particularly interesting to see how the comparison between SKSML and P1619.3 turns out. Those two seem to have a bit of overlap, but the working groups that are developing them will almost certainly have an explanation prepared that explains how the two differ. I'm looking forward to hearing what they have to say.

Why I don't watch the Olympics

I used to enjoy watching the Olympics on TV, but I don’t any more. This is probably because of my experience in sports. I used to compete in triathlons. The best that I ever managed to do was finish just behind the first-place woman. That's probably not a bad performance for the average guy on the street, but it's not really competitive with the winning men.

It turned out that there were other triathletes that I simply had no chance at all of beating. I just didn’t have the right stuff while the guys who managed to win races did. This meant that no matter how hard I trained, there was no way that I could ever be as good as they were. The people who have the ability to win triathlons seem to be born that way, and if you don’t end up with the right genes, it’s out of your hands. Winning triathletes train hard, but they also have an advantage that the rest of us can’t match.

Other sports seem to be this way too, and once I realized this, the Olympics lost some of their appeal. The people who win Olympic medals aren’t just dedicated and hard working. They’re also the lucky ones who happen to get the right genes.

Public-key cryptography is a bit like an Olympic medalist in some ways, at least when compared to symmetric key cryptography. It does some things much better and cheaper that symmetric key cryptography can ever do them.

Using SSL, for example, you only need a single public/private key pair for the server. That’s enough to let anyone in the world authenticate the server and set up a secure connection to it. You could duplicate this functionality with symmetric cryptography but you probably wouldn’t want to actually do it. It’s just too hard and too expensive. Just like an Olympic medalist has an advantage that average athletes will never be able to compete with, public-key cryptography has an overwhelming advantage over symmetric cryptography in this application.

Some public-key technologies seem to have definite advantages over other public-key technologies. Elliptic-curve cryptography has some advantages over some other public-key technologies, for example, because it's more secure and more efficient. The use of elliptic-curve algorithms in the NSA's Suite B cryptography is probably proof that it has won the battle with the older technologies. The fact that it took about 20 years to win this battle, however, probably indicates that its advantages over the older technologies are not that great.

Identity-based encryption, one of the newer public-key technologies also has its own set of advantages over older technologies. Because it lets you use an arbitrary string as a user's public key, there are no problems with key look-up. Because it makes short-lived keys practical, it also provides an easy way to work around the problem of key validation that other public-key technologies have. Because it requires only a single connection to a server to look-up of a set of mathematical parameters before it can calculate any public key, it's particularly useful in distributed computing environments where connections are routinely lost.

Identity-based encryption seems to be having fairly rapid success. The first secure and practical identity-based encryption scheme was invented only seven years ago, but there are already over 10 million users of the technology. Its fairly rapid success probably indicates that it has important advantages over other public-key technologies. It might be a small advantage, like the difference between an Olympic gold medalist and an Olympic silver medalist. It might be a big advantage, like the big difference between winning triathletes and me. Its rapid adoption and success makes me think that it has proven to have a fairly significant advantage, but only time will tell if this is true or not.   

Convergence may be a bad idea

"Convergence" is again a hot topic. In the past, it meant the trend of IP networks and telephone networks to move towards common technology. Now it refers to the trend of integrating information security groups and other corporate risk management organizations. There are good reasons for doing this, but a closer look at some aspects of information security may indicate that this may not be such a good idea.

Three of the major security professional organizations, ASIS International (ASIS), Information Systems Audit and Control Association (ISACA) and Information Systems Security Association (ISSA), recently sponsored a study on the convergence of information security and risk management. The result was the 2005 report Convergence of Enterprise Security Organizations by Booz Allen Hamilton, which discussed the trend of convergence and the reasons for it.

The desire for a single organization that's responsible for all aspects of regulatory compliance is one driver for convergence. Another is the migration of more corporate assets to information technology. This has caused a change in what the most valuable assets of businesses are and a corresponding change in the focus of risk management. These reasons seem fairly compelling, and seem to allow for more cost-effective risk management strategies. On the other hand, a closer look at information security casts some doubt on whether this strategy will be effective in the long run.

The fundamental problem is that the factors that are used to quantify a risk – the probability of an event happening and the loss that accompanies the event – are almost always never known in information security. In information security, it's often difficult to make estimates that are even close to being accurate. What is the probability of one of your e-mails being intercepted and read while it's on the Internet? If this happens, how much loss does it actually cause?

This means that the usual techniques of risk management don’t work very well on the problems that information security deals with. On the other hand, applying information security methodologies, where decisions are often made without any reliable data at all, to other risk management functions will also probably result in poorly-managed risks.

The best solution is probably to understand the differences between the types of risk that exist and to manage them differently. If you're doing that, does it make sense to merge the two functions into a single organization? Unifying information security and other corporate risk-management organizations may not necessarily be a good idea.

Supply and demand

According to industry analysts, there's a critical shortage of qualified people in the information security industry. This simply isn't true. There may be a shortage of qualified people who are willing to work for the salaries that companies want to pay, but that's an entirely different situation. 

I'd like to be able to sell my house for $10 million. If I could do this, I'd sell it tomorrow, quit my job and do something else entirely. Maybe I'd train for triathlons full time. I wasn't good enough to be a professional triathlete when I was in my 20s, so I never got a chance to do it full time. If I had a huge windfall from selling my house, however, I could afford to be a full-time triathlete and I might actually try it. I still wouldn't be very good, but it would be fun to do it full-time.

Maybe I'd get around to writing a couple of books that I've meant to get around to writing for a few years now. Writing is almost certainly more fun during daylight hours, but I've always had to do it late at night when I can find the time for it because it's not part of my day job.

The reality, however, is that it doesn't matter how much I want to sell my house for. The market dictates the price that I'm able to get for it, and it looks like there's absolutely no way that I'll ever get $10 million for my house. The reality of market forces means that I won't be a full-time triathlete or writer any time soon.

Similarly, market forces dictate how many people you can get to fill the many open information security positions that are apparently now going unfilled. I'm sure that many businesses would like to pay their security people $25,000 (or even less) a year, but at that salary you'll find very few qualified people willing to fill those positions - probably absolutely nobody. Doing these jobs requires technical skills that not many people have. Doing them well also requires an understanding of business issues and the ability to deal with the politics that inevitably accompany any significant budget. So the supply of qualified people is limited while the demand for them is growing. The law of supply and demand tells us that market forces will eventually push the pay for skilled security people to the level at which there's an adequate supply of them. 

One way to deal with this situation is to ignore it and hope that it goes away. Maybe the need for information security staff will dramatically decrease in the future. If this happens, the current levels of pay will eventually become  good enough to attract the right people. This is unlikely to happen, so ignoring the problem may not be the best solution to it in this case.

Another approach is to accept the situation and to deal with it the best that you can. If the shortage of skilled people is real, it will have to be addressed one day, and that means that their price will have to increase. The market price for information security professionals seems to be higher than what some people want to pay, but what you want to pay doesn't really matter, does it?

All your Bayes are belong to us

Risk management deals with the losses that accompany uncertain events. To find the risk associated with a particular event, you multiply the probability of the event happening by the loss that the event would cause. So an event that causes $1 million is loss but happens with only a 0.1 percent chance represents $1,000 in risk.

In some cases, parts of a population can have a much greater chance of experiencing a particular event than others. This can lead to misleading ideas about risks. In some cases, conditional probabilities give a better understanding of risks.

It's commonly believed, for example, that it's safer to fly on a commercial airline than to drive your car to an airport. You can get this result by using the average number of fatalities per mile for travel by car and travel by airplane to estimate the chances of being killed on each trip. A closer look at the data, however, shows that a significant number of deaths in cars are caused by young, drunk men who are driving late at night. Because young, drunk men tend to not be on the road when people driving to airports are on the roads, it's actually much safer for them. People driving to airports are also typically not young, drunk men. So the more relevant probability in this case is the probability of being killed in a automobile accident given that you're the kind of person who would actually be traveling to an airport. Based on this conditional probability, it turns out that air travel is actually more dangerous than driving.

Gregory Baer's book Life: the Odds gives some interesting examples of conditional probabilities, although he doesn't call them that. For example, there are roughly 250 New York Times best-sellers each year and there are roughly 6.7 billion people in world today. If you look at the chances of writing an New York Times best-seller as being about 250 in 6.7 billion, the chances seem fairly small.

On the other hand, suppose that your book has been published. In this case your chances of having written an New York Times best-seller are roughly 1 in 220. That's better by a huge margin. If you relax the requirements for being a best-seller to include books on other lists, like those from USA Today and Publishers Weekly, the chances of writing a best-seller get even better. Using the broader definition, the probability of having written a best-seller, given that your book has actually been published, is more like 1 in 54.

Baer's book is very entertaining, but it definitely isn't too serious. It also estimates the chances of Satanic possession to be roughly 1 in 7,000 each year. That's roughly the same as the chances of dying in an vehicle accident in the US, which is about 1 in 6,535 per year. If Baer is right, there's a significant chance, roughly 1 in 100, that a typical person will be possessed at some point in their life. Maybe there's a bias towards young, drunk men in this estimate also.

Mostly a good idea

NIST has just released another draft of Special Publication 800-37, Guide for Security Administration of Federal Information Systems. It’s an interesting document, but parts of it probably really aren't suitable for use by the government. This is because this document tries an approach that works well in the commercial world, but one that probably won’t work well for many government agencies.

All organizations, both government and commercial, face many kinds of risks, and a good first step towards dealing with these risks is to understand an organization’s tolerance to risk. Some organizations are willing to accept greater risks because of the greater gains that can accompany the greater risks. Others are happy to limit themselves to smaller risks and the smaller gains that tend to accompany them. Knowing exactly how much risk your organization is willing to accept is one of the first things that you should do when creating a strategic risk management plan.

The problem with SP 800-37 is that it’s aimed at government agencies. Government organizations have extremely low tolerances for risk, and this is somewhat understandable. An unfortunate aspect of a market economy is the fact that businesses can and will fail, and this sometimes happens because of risks they take. The problems that accompany businesses failing, however, are more than compensated for by the gains that other businesses make from accepting risks. Thus having some failures but lots of successes seems to provide the basis for a system that works fairly well.

That’s probably how it should be. Voltage is doing quite well making and selling encryption products, but if Voltage somehow decides to risk their future by focusing on IBE-enabled lava lamps, for example, we deserve to fail miserably.

Governments, on the other hand, need to do their best to avoid some types of failure, which means that they need to avoid some types of risk. While it may be acceptable for some businesses to fail, when a government fails, the results can be catastrophic. This means that governments sometimes need to accept lower risks than for-profit businesses would be willing to accept because they need to keep this chance of catastrophic failure to a very low level.

It’s also the case that the way that government agencies are run doesn’t create an environment in which there’s any incentive to take risks. In the business world, people accept that risky ventures sometimes fail. In governments, however, this does not seem to be the case. In the public sector, failure is often rewarded quite differently. There’s always some partisan group that will act outraged that taxpayers’ funds were wasted when a government project fails, even if the failure is just the result of a risky venture that just experienced bad luck. This outrage often translates into public humiliation for the unlucky government officials responsible for the failed project. They’re often vilified by the media and forced to publicly explain to politicians exactly how and why their project failed. In this environment, there’s little incentive to take risks.

So government agencies aren’t better or worse than businesses - they’re just different because they work within an entirely different set of constraints. These differences can dramatically affect how they manage risks. Because of this, the strategies for managing risk that work well in the private sector may not work very well for government agencies. So although the ideas in the new version of SP 800-37 are good ones, some of them probably won't work well for that publication’s intended readers.