Superconductor

How many users?

Encrypted email is getting very popular these days. Voltage now has roughly 10 million users of its SecureMail product, for example, and other secure email vendors probably have similar numbers that they could cite. That's why I wasn't really surprised to see the counter on the Zix Corporation web site that shows how many users they have. When I checked this, the number was roughly 14 million. That's a respectable number, isn't it?

But as I looked at this web site, this number increased by one. A short while later it increased by one again. The number of users of Voltage's SecureMail typically increase by several thousand at a time instead of one by one, so this seemed a bit odd. To see what was really going on, I looked at the source code of Zix's web page. You can do this in Internet Explorer, for example, by going to the View menu and then selecting the Source option of the menu that appears.

When I did this, I was a bit surprised to see that the counter that shows how many users they have is based on the clock of the computer where the web browser's running and has no obvious connection to the actual number of users that Zix has! Here's part of what I found. This is the code that creates the number of users that is displayed on the Zix web site.

function ZixCount2()
{
    today = new Date ();
 startDate = new Date (2009,0,06);  //months in js run 0-11 (must reset when changing goal)
 startVal = 13885156;  //starting Value (must reset when changing goal)
 var one_day=1000*60*60*24;
 
 perWeek = 100000;  //set rate per week
 rate = 604800/perWeek;
 
 goalDate = new Date (2009,0,8);  //Set a Goal Date (months in js run 0-11)
 goalVal = 13996467;  //Set a Goal Value
 
 if (goalDate <= today){
  startDate = goalDate;
  startVal = goalVal;
 }
 
 currentVal = Math.round(startVal + (today.getTime() - startDate.getTime())/1000/rate);
 
 if (goalDate > today){
  daysLeft = Math.ceil((goalDate.getTime()-today.getTime())/(one_day));
  daysTotal = Math.ceil((goalDate.getTime()-startDate.getTime())/(one_day));
  dailyOffset = (goalVal-currentVal)/daysTotal;
  currentVal = Math.round(currentVal + (dailyOffset*(daysTotal-daysLeft)));
 }
 
 
 //document.write("Current Val = " + currentVal);
 //document.write("<br />");
 //document.write("daysLeft = " + daysLeft);
 //document.write("<br />");
 //document.write("daysTotal = " + daysTotal);
 ChangeValue(2, currentVal);
    timerID = setTimeout("ZixCount2()",rate) } // -->

So the number of users that the Zix web site shows doesn't really seem to be related to how many users they actually have. Instead, it's just based on what time it is. You can even change the number of users that the web site shows by changing the date and time on your computer's clock!

I'm not sure why Zix did this. I don't doubt that they have millions of users of their email encryption product, but it certainly looks like the number on their web site doesn't really correspond to the number of users that they actually have.

Enterprise key management

There’s a new report, Enterprise Key Management Systems, from the Burton Group. Many vendors talk a lot about key management, but this report seems to show that many of them don’t really have much of an interest in it beyond what’s needed to make their own products work. This report lists 10 areas that use key management: file encryption, laptop encryption, email encryption, etc. For 13 vendors, including Voltage, RSA/EMC, nCipher, NetApp, SafeNet and eight others, it lists which vendors have an offering in each area.

Voltage has more offerings than any other vendor, having something in seven of the 10 areas. RSA/EMC is a close second, offering something in six of the 10. Three more, nCipher, NetApp and SafeNet offer something in five of the 10.

The top five enterprise key management vendors all have an offering in at least half of the 10 areas, and seem to be ones that are fairly serious about enterprise key management. Their offerings overlap in some, but not all, areas, which makes it looks like the five leaders aren't really direct competitors in most cases. There's some overlap between the areas that Voltage covers and the ones that RSA/EMC covers, for example, but not enough to really say that the two companies are really competitors.

The other eight vendors seem to be more niche players, and don’t seem to have an interest in developing solutions tthat address he broader enterprise key management problem. They seem content to just manage keys that their applications need.

Another big data breach?

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

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

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

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

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

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

That's why we have standards

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

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

Perception vs. reality

The popular perception of many things may not be an accurate reflection of reality. In Silicon Valley, for example, every few years a mountain lion finds its way from the nearby mountains into one of the densely-inhabited neighborhoods. These mountain lions often end up being shot and killed by the local authorities. This often causes the local residents to be outraged that the animal was killed instead of just incapacitated.

The local authorities then explain that tranquilizer darts don’t actually immediately knock out an animal. Instead, they tend to create an enraged animal that’s potentially dangerous for several minutes before they lose consciousness. On the other hand, almost everyone has seen tranquilizer darts work immediately in TV shows and movies. The result is that the popular perception of how tranquilizer darts work is very different from reality.

The inaccurate portrayal of such effects isn’t just limited to TV and movies. The effects of drugs and poisons are portrayed so inaccurately in espionage stories that it prompted the article “WANTED: A Pharmacologist for M.I. 5” in The Journal of Irreproducible Results that pointed out some of the common inaccuracies. An example of this is the fact that despite its depiction in popular fiction, curare isn’t really suitable for coating a blowdart that’s meant to kill a person. Curare darts are actually so ineffective against larger animals that South American native tribes actually only use them on small prey. Few people take the time to learn the real effects of curare, but many are exposed to the fictionalized effects. The net result of this is a misperception in exactly how deadly curare darts are.

The field of information security also suffers from a few mismatches between perception and reality. Part of this is probably due to the way in work of the marketing efforts of security vendors, while another part is probably due to the inaccurate portrayal of some security technologies by TV shows and movies. Here's an example of how encryption was portrayed in The Adventures of Buckaroo Banzai across the 8th Dimension:

(RAWHIDE and BILLY TRAVERS are trying to access information on Yoyodyne's network, but are being thwarted by encryption. Yoyodyne is a defense contractor, so they probably have cryptography that's certified by the NSA and other super-secret government organizations.)

RAWHIDE: Try a G-cipher.

BILLY TRAVERS: G-cipher. (types "G-cipher" on the keyboard) There.

RAWHIDE: Ah. That's more like it.

BILLY TRAVERS: Looks like we've accessed their restricted data file. Could be highly revealing.

If it's used correctly, however, encryption provides virtually unbreakable security. If that's the case, then there's always a better way for a hacker to accomplish his goals than to try to beat the encryption. And even if a determined and well-funded adversary decides to try to beat the encryption, it will take a huge amount of effort. It's never as easy as just typing "G-cipher."

Unfortunately, encryption is never shown that way by TV shows and movies. That's probably because if it was shown more accurately, it wouldn't be very entertaining. A more realistic way to show it would just involve watching hackers sit back and wait for billions of years as their expensive computers try to recover a single encryption key. That's how hard it is to really beat cryptography. If you need to protect sensitive information, it's definitely the best way to do it.

An idea that won't work

The recent story by The Sunday Times about the energy cost of using Google for a search seems to have been revealed as an exaggeration. We'll have to wait a while and see which people remember more - the correction or the original inaccurate claim:

Performing two Google searches from a desktop computer can generate about the same amount of carbon dioxide as boiling a kettle for a cup of tea, according to new research.

That's not just wrong – it's obviously wrong. The Times eventually added a few extra words to their original article that tried to clarify what they actually meant, but it still looks like a case of people trying to use statistics who shouldn't be using them. The fact that this article created such a stir may tell us that one of the ways proposed to combat spam may be impractical due to environmental concerns. This is the idea that one way to stop spam is to force senders of email to pay a tax in the form of lots of computation when they send an email.

The problem is, of course, that the computation that would be needed to send an email could also be quantified in terms of carbon dioxide. Imagine the uproar if the following was claimed about this anti-spam technique:

Sending a single email can generate the same amount of carbon dioxide as boiling two gallons of water, according to new research.

So it certainly looks like the idea of paying tax in computing power won't fly as a means of preventing spam these days. It's never been a very popular idea, but it certainly looks like the anti-spam researchers need to come up with another idea or two.

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.

Altered Photos

When I worked at RSA Data Security, we got very excited about a particular use of public-key cryptography: digitally signed photographs.

At the time UN weapons inspectors were using special cameras. The pictures they took were converted into bits inside a special tamper-resistant module inside the camera. Inside this module was also an RSA private key, used to sign the photo. Later on, if someone claimed that the photo was altered (say, with photoshop), the signature could be checked.

Incidentally, tamper-resistant chips or modules work just like regular hardware, except they have some sort of shield that prevents regular monitoring techniques (such as logic analyzers) from seeing anything on the device. Furthermore, the shield is constructed such that the act of removing it causes the device to "self-destruct". For example, a "simple" technique is to coat the module with a plastic or resin. That's the shield, plus if someone tries to peel off the coating, the chips are destroyed. Think of tearing a price tag off of a cardboard box. Sometimes the price tag is glued on so well, that the only way to get it off is to tear some of the box as well.

Back to the cameras. When the camera is built, the tamper-resistant module generates an RSA key pair, keeps the private key on the module, and exports the public key. If someone alters a photo, the signature is no longer valid. So to break this system, someone will have to either get the private key from the module (no one was able to do that) or break RSA at 2048 bits (I still think no one has been able to do that).

This would be an interesting feature to have on cameras other than those used by UN weapons inspectors. In fact, compaines that sell security cameras do indeed advertise that their products apply a digital signature to images. If something ever ends up in court, judges and juries can see that they are looking at unaltered images.

However, this feature will almost certainly never be part of consumer cameras. It would simply raise the cost of cameras too much.

But what's interesting is that is another example of PKI that worked. But why did it work? I think because it only did one-sided authentication for a specific purpose. That's it, no encryption, no wide-scale auth, no auth for anything other than photos, no cross-certification. It would be easy for the camera manufacturer to get a CA cert from a readily available root (such as Verisign). Then create a cert for each camera.

So if someone peddling PKI points to this example, then point out that this is a very simple case. Not many nodes, not many features, one company controls all the nodes and cert generation. How well does PKI work in complex situations? Does someone have an example?

Waiting for PKI

VLADIMIR: What are you insinuating? That we’ve made a mistake?

ESTRAGON: It should be here.

VLADIMIR: They did say for sure that it would come.

ESTRAGON: And if it doesn’t come?

VLADIMIR: We’ll come back tomorrow.

ESTRAGON: And then the day after tomorrow.

VLADIMIR: Possibly.

ESTRAGON: And so on.

VLADIMIR: The point is-

ESTRAGON: Until we see the success of PKI.

VLADIMIR: You're merciless.

The engineer's tale

A “frame story” is one in which the author uses some sort of meta-story to link together several shorter stories. This trick has been used for at least 3,000 years, going at least as far back as the Mahabharata, which was probably written starting in roughly the 8^th century BC. It worked so well that One Thousand and One Nights, also known as Arabian Nights, used it again several hundred years later.

Even later came the Decameron and The Canterbury Tales. In both of these, the meta-story explains why the characters who tell the shorter stories happen to be together. In the case of the Decameron, they’ve fled the city because of the plague. In The Canterbury Tales, they’re on a pilgrimage to Canterbury Cathedral. In both these cases, they tell stories to pass the time.

This trick has worked so well over the years that it might be time to make an updated version that reflects what more contemporary people might do to pass the time these days. You could easily have a meta-story in which a group of executives flee their corporate headquarters to an off-site meeting in Las Vegas and tell stories to pass the time until they return to work. That might not be feasible, however. These people talk about things like “leveraging core competencies to execute game-changing paradigm shifts.” It’s hard enough to translate the medieval Italian of the Decameron into modern English. Imagine how difficult it would be to try to translate those sorts of phrases into any modern language at all.

Maybe a better idea would be Silicon Valley Tales: while the executives are in Las Vegas trying to figure out how leverage their core competencies, the workers at a Web 2.0 start-up in Palo Alto pass the time by telling stories instead of working, and these stories make up this collection. You have an engineer, a sysadmin, a product manager, an executive assistant, a tech writer, a sales manager and a consultant. All the others have taken advantage of the executives’ absence and are working from home, leaving only these few in the corporate headquarters building. After a few hours of boredom, they all decide to go to Fry’s for lunch, and tell stories to pass the time as they're stuck in traffic on Highway 101. Maybe that’s not such a good idea. It would be tough to fit all seven people into a single car for this trip, so that particular meta-story might require more suspension of disbelief than most readers are willing to tolerate.

I'll start work on the engineer's tale as soon as I get some free time.

Yet another big deployment

Today, Voltage announced that Wells Fargo has dramatically increased the size of their deployment of SecureMail, Voltage's line of products that's used to encrypt email. The new Wells Fargo deployment will be hundreds of thousands of users. While this might have been a big deal a few years ago, these days, it's almost not even newsworthy. After all, there are roughly 600,000 SecureMail users at a large retail business and another 250,000 SecureMail users at a large health care business. Each of these deployment was fairly easy, and required minimal support from Voltage's support team. If you're new to secure email, this may not sound impressive, but if you've used it for a while, this is simply astounding. Just a few years ago, there was no way to realistically deploy secure email to a few hundred thousand users unless you were the US government and didn't mind spending a billion dollars or so.

I almost feel sorry for people who are just getting their first exposure to secure email these days, because it's not really very interesting anymore. Not long ago, it definitely appealed more to computer hobbyists who enjoyed tinkering with the secure email system to get it working much like ham radio operators enjoy tinkering with their radios to get them to work. Now, it's much easier and cleaner, and hobbyists have to find other ways to amuse themselves.

The people for who Voltage's SecureMail is their first exposure to secure email won't be able to tell stories to their coworkers one day about how they overcame seemingly insurmountable obstacles and actually managed to send an encrypted email. Some might not even know they're using it. There's still plenty of difficult software out there, though, so they won't miss out on the experience of fighting with it. This seems to be an unavoidable part of working in the twenty-first century.

Ease of use

Any security product needs to be very simple to use if it’s going to become successful. If they’re not simple to use then the cost of supporting difficult products can easily outweigh any benefits from them. That’s why Voltage’s SecureMail has the minimal level of user involvement. If a person sending an email can click on the "Send Secure" button instead of the "Send" button, the can use SecureMail. There’s nothing else that they need to do.

It’s probably possible for people to use more complicated secure mail systems. President Obama probably has no difficulty using secure email on his BlackBerry, but he has a fairly large staff to configure it for him. He probably has fairly good tech support too. Similarly, generals don’t seem to mind using digital certificate from the Department of Defense’s PKI to send signed and encrypted email, but they also have a staff to take care of any problems that might occur.

People that don’t happen to be the President of the United States or a general officer still need to encrypt email, however, and they normally have to do it on their own. In these cases, ease of use is critical.

There are also probably good reasons why people simply don’t want to use secure email that takes more effort than clicking on "Send Secure" instead of "Send." It’s probably very similar to the reason that many people don’t use the latest social networking application, or whatever the trend du jour is. This may be because they just have better things to do.

When you’re young, you tend to have lots of free time, but also don’t get paid much. This means that you have the time to do what you want to do but sometimes can’t afford to do these things. You’re resource constrained, not time constrained. Not too many years later, most people find that this situation has reversed. At that point, they find that they’re married, have children and that their job now carries more responsibilities than can easily be done in an eight-hour day. At this point, there are more demands on their time than there are hours in the day, and they’re now time constrained instead of resource constrained. When that happens, learning a new security technology is now competing with dozens of other priorities for the little time that’s available.

To most people, spending the time to learn a complicated security application never becomes a high enough priority that they decide to do it. There’s always something else that’s more important. This isn’t limited to security, of course. This may also explain why you see lots of younger people using the newest social networking applications while those that a bit older often don’t get around to using them: there's often a better use of their time.

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.

It's like brewing beer

Several years ago I used to brew beer. If you've never done this, you let the beer ferment in a glass container called a carboy that's topped by a fermentation lock. A fermentation lock is a clever device that lets the carbon dioxide from the fermenting beer escape but doesn't let the outside air get in and contaminate your beer.

Once I noticed that the fermentation lock on a batch of fermenting beer had become clogged, so I took it off to clean it. This caused a dramatic reaction. Imagine shaking a five-gallon bottle of beer and then opening it. That's pretty much what happened. But because a five-gallon container is much bigger than a 12-ounce beer this didn't happen right away. Instead, I got to watch the bubbles streaming up from the bottom of the carboy for a second or two, fully knowing that there was no possible way to stop them and that they would almost certainly make the biggest mess that I'd ever seen once they made good their escape from the carboy. Fortunately, my wife was in Japan on business for a few weeks, so I had plenty of time to clean up the spill that resulted from this incident.

Every now and then I'm reminded of the mess that this particular incident caused. There's no clear analogy to popping off the fermentation lock, but the unstoppable flow of fermenting beer and the mess it made often reminds me of the huge amounts of sensitive information that's routinely revealed in data breaches and the high costs of cleaning up after the breaches. I was lucky enough to have a few weeks to clean up after the mess that I made. Few companies are as lucky with data breaches.

Who can you trust?

Good data about the information security market and the threats that it addresses is hard to find. It seems to be even harder to get reliable and accurate data. How many businesses encrypt their laptops? Two recent surveys gave very different estimates for this. One estimated 20 percent, the other estimate 50 percent. They can't both be right.

The estimate of 20 percent comes from page 13 of the report 2008 Annual Study: U.S. Enterprise Encryption Trends. This report summarizes the results of surveys done by the Ponemon Institute on behalf of PGP which surveyed 975 people. This report estimates that 20 percent of businesses encrypted mobile data most of the time in 2008. That probably includes more than just laptops. Things like USB drives and other portable storage are probably part of this category too. When we're looking at laptops, we also don't have to worry about the odd wording about using the technology "most of the time." Laptop encryption isn't something that you turn on and off; it's always on.

The estimate of 50 percent comes from page 11 of the 2008 edition of The Global State of Information Security. This report summarizes the results of surveys done by a combination of PricewaterhouseCoopers, CIO and CSO magazines that surveyed 7,000 people. This report estimates that 50 percent of businesses use laptop encryption, so we don't need to worry about the number being not quite what we’re looking for.

Both of these estimates can't be right. I'd bet that the Ponemon Institute's survey is the one that's wrong, and this is just based on the cynical "follow the money" reasoning. After all, PGP sells full disk encryption, and has an incentive to make things sound worse than they really are to encourage interest in their products, and they probably had a role in designing the survey. PricewaterhouseCoopers is an accounting and auditing firm, who has more of an incentive to do an independent and unbiased survey, as do CIO and CSO magazines. The PricewaterhouseCoopers survey also polled many more people than the Ponemon survey did, so it's probably more likely to be accurate.

The Ponemon report also estimates that only 17 percent of businesses encrypt their email. Any guesses as to what the true number really is?

Not really a trillion

I’ve commented before on the lack of accurate data for information security threats. It certainly looks like you really can’t trust vendors to give you accurate and unbiased data, and the latest news from McAfee’s blog is probably an example of this.

McAfee estimates that lost data cost the world’s economy a trillion dollars last year. Unless it’s the U.S. government talking about how much they’re going to spend, you should probably be suspicious of the accuracy of any number that large. I certainly was. Puzzled by this number, I found a copy of the McAfee report, Unsecured Economies – A Trillion Dollar Headwind, that this blog cites.

I wasn’t terribly surprised when the $1 trillion number didn’t actually appear in this report. The report does estimate that the average company lost $4.6 million in data last year. I have to assume that someone just estimated the number of businesses in the world and multiplied it by $4.6 million to get the astounding $1 trillion estimate.

I don’t believe this estimate at all. Part of my skepticism is due to the fact that it’s so much larger than other estimates. The fact that it’s from a security vendor who wants to sell you products and services that can reduce the amount of data that you lose doesn’t help, either.

The 2008 CSI Computer Crime & Security Survey gives a much lower estimate for the value of lost data, for example. And in the several years that this survey has been done, it hasn’t even come close to the McAfee estimates. The 2008 estimate was $288,618, which was down from the $345,005 estimate in 2007. Two years ago, the estimate was $167,713. None of these are close to $4.6 million.

And without estimates of exactly how much information is out there, it’s hard to put estimates of information loss into a useful context. The November 2008 issue of Johns Hopkins Magazine had a feature about the high cost of health care in the U.S. and how to control it. They mention that uninsured people and others who can’t pay their bills cost the U.S. health care system about $30 billion per year. That certainly sounds like a lot of money, but when you consider that it’s only 1.4 percent of the total $2.1 trillion that’s spent on health care in the U.S. every year, it sounds much less important.

So let’s suppose for a moment that McAfee’s estimate of $1 trillion in loss is actually accurate. Does that $1 trillion represent 20 percent of the total value of information, or is it only 0.1 percent of the total value of the information? Without knowing that, the $1 trillion number isn’t really of much value.

Algorithm agility with IBE

In his recent blog post, enterprise architect extraordinaire James McGovern mentions that he’s concerned that there’s no algorithm agility with identity-based encryption. His thoughts may be based on a misunderstanding of what IBE actually is. Here's why.

IBE is really a family of public-key technologies that share a common set of properties, and there are actually several different IBE schemes. Voltage’s shipping products actually support two of these:Boneh-Franklin IBE and the Boneh-Boyen IBE. So even within the technology used by a single vendor, there’s still the opportunity for algorithm agility while keeping the useful properties of IBE.

Most of Voltage’s customers use Boneh-Franklin IBE. It was the first IBE scheme that was both practical and secure. It’s also the easiest to understand. Boneh-Boyen IBE is harder to understand. It also has a number of properties that differentiate it from the Bohen-Franklin scheme, most of which only matter to specialists in the field of pairing-based cryptography. Most people really don’t care, for example, whether an identity gets hashed to a point on an elliptic curve or it gets hashed to an integer. Boneh-Franklin IBE hashes an identity to a point on an elliptic curve. Boneh-Boyen IBE hashes an identity to an integer.

The likelihood of a weakness being found in either the Boneh-Franklin of the Boneh-Boyen scheme is also quite low. Both of these schemes have formal proofs of their security. Lots of smart people have reviewed these proofs, so they’re probably correct. This means that it’s very unlikely that there’s a weakness in either the Bohen-Franklin or the Boneh-Boyen IBE scheme that can be exploited.

There are also other vendors that use IBE technology in their products. I can’t say for sure, but I wouldn’t be surprised if their products have the same level of algorithm agility that Voltage’s products do. I can say with certainty that the concerns around algorithm agility really don’t apply to Voltage’s products. You’ll have to ask other vendors about exactly how they do things.

Epithets

Epithets are common in classical Greek and Roman literature. These are a descriptive phrase that's commonly attached to the name of a person, place or thing. For example, in the Iliad, Hector is called "tamer of horses" 410 times. Achilles is often called "swift-footed." He's actually called "shepherd of the people" much more often, but "swift-footed" is the epithet that people seem to most often remember for him.

Epithets were useful in classical literature because it was often memorized instead of being written down, and having a stock phrase that's commonly used makes memorizing things easier. Works like the Iliad are also written in dactylic hexameter, so it was probably easier for the author to have a stock phrase that fit the meter that he could use again and again. Sort of an early version of object reuse.

So you might wonder what epithet would be used for more contemporary people in the unlikely event that an epic poem in classical Greek is written about them. Ronald Reagan might be the "fighter of the Cold War." You can probably think of all sort of clever epithets for other modern politicians. Most of these will strongly depend on whether or not you are a supporter or not. For some, it might even be appropriate to reuse the epithet of Theristes. He was a Greek soldier in the Trojan War who was often referred to in the Iliad as "loose tongued," which is sometimes translated as "of the endless speech."

If you really get carried away, you might even start to wonder what a suitable epithet for yourself might be. In my case, it could be based on my experience with getting Voltage's Common Criteria certification. This process involved overwhelming amounts of paperwork, so I might be one day known as the "slayer of trees." That almost sounds heroic, although it's certainly not in the same league as Odysseus, who was known as "sacker of cities," or "mastermind of war."

Is compliance a cost?

There's a post on McAfee's web site that answers the question "Is information security compliance really a cost center?" like this:

No. Absolutely and unequivocally not. I am drawing the line in the sand. Business leaders need to understand there is no more need for proper security to justify itself over and over again. It saves you time and money (period).

Properly implemented information security provides business process improvement, technology improvement and threat reduction. Compliance controls that cover each of these areas to accepted “best practices” will save your organization money by the truckload and provide for expansion of your business tenfold if not more.

Far too often businesses require “measurable” savings when the cost reductions and business enablement is as obvious as a freight train hitting you while you are siting on the tracks. Below I will detail a simple walk-through of a compliance driven organization versus a non-compliant organization which makes it obvious that it is better and more efficient to be compliant as a business.

In most situations, the term "compliance" means regulatory compliance, or being compliant with data security and privacy laws and regulations. If this is how we interpret "compliance," then compliance is definitely a cost center, at least in many cases. Here's why.

Businesses tend to make investment decisions that maximize the benefits that they receive from the investments. They might be maximizing profit, or something else like market share. This means that when they decide to use a particular security technology, there's probably a good reason for doing so. It also means that when they decide not to use certain security technologies, there's probably a reason for that also. This means that you'll almost never hear discussions like the following:

CSO: We should encrypt the hard drives on our laptops. Our model shows a 60 percent ROI over a three-year period for the total cost of deploying and supporting full-disk encryption software.

CFO: Bah! I don't care about ROI arguments. Instead, we should wait for the government to mandate that we use that technology.

So it's reasonable to assume that investments that are made purely as a requirement for regulatory compliance are ones that wouldn't have been made on the basis of the value of the investment alone. This means that they don't make sense from a business point of view, and that mandating them forces businesses to make investments that they really shouldn't make.

Passing data security and privacy laws may force some security spending, but it's probably at the cost of other security projects that deserved to be funded instead. This means that the net result of data security and privacy laws may be just to reallocate spending from projects that had a good justification to ones whose only justification is to become regulatory compliant. That's probably not a good idea.

There are cases where it makes sense to do some of the things that are also required by regulatory compliance. Data breaches can be extremely expensive, for example, so it's often the case that there's a valid business case for using encryption. This means that there's a strong business case for using persistent encryption of sensitve information. There's also a strong business case for using encrypted email.

If you're really curious about the details of these business cases and don't mind slogging through some detailed risk models, you can take a look at Kevin Soo Hoo's doctoral dissertation "How Much Is Enough? A Risk-Management Approach to Computer Security." He did a careful analysis of the cost-benefit analysis of several information security technologies and found that the case for encryption is strong. The business case for encryption is still valid in the absence of the need for compliance. Other security technologies aren't as lucky.

Compliance may not always be a cost center, but in many cases it is.

IBE for key management

A few months ago, Trust Catalyst released their 2008 Encryption and Key Management Industry Benchmark Report. Here's the data from this report that shows how challenging the 330 people who responded to Trust Catalyst's survey rated various areas of key management. What's interesting is that all of the top three challenges listed here are ones that are particularly easy to solve if you use identity-based encryption (IBE).

       

With IBE, it's easy to calculate keys as they're needed. This makes it practical to use short-lived keys, and if you do this, there's no need at all to revoke keys.

And because IBE keys are calculated, there's no need at all to back them up. Calculating an IBE key a second time is no more difficult that calculating it the first time, so instead of keeping a secure archive of keys, you don’t need to archive IBE keys at all. Instead of getting a key from the secure archive server, you just recalculate it when you need it, which makes backing up and recovering IBE keys extremely easy.

Similarly, because you can calculate any IBE decryption keys from just a single system-wide master secret when you need them, making IBE keys accessible to a disaster recovery site is extremely easy. Even if you can't reach an IBE key server from a disaster recovery site, it's easy to get a key server up and running in the disaster recover site in just a few minutes. All you need to do is configure a key server with the master secret, and you're done. This takes no more than a few minutes, so this problem is also extremely easy if you're using IBE.

In the light of Trust Catalyst's report, I have to wonder why more people aren't using IBE for things other than email. It seems to be the logical choice because it makes what seems to be the biggest challenges of key management extremely easy.

Should standards be free?

There's one big difference between the IETF and other standards bodies: IETF standards are free while most other standards aren't. The standards that you need to pay for usually aren't very expensive. You might pay $100 or less for most of them, which is a very small cost relative to the other costs that engineering organizations incur. Despite this, the modest prices for standards seem to dramatically limit how widely they're adopted.

One of the IETF working groups that Voltage monitors but doesn't actively participate in received an email from a member of one of the standards bodies that charges for its documents. The email asked why the working group seemed to be reinventing that the other group had already standardized. Although nobody in the IETF working group seemed to be inclined to even look at the other standard, and the reason was almost certainly that they would have had to pay to see a copy of it.

So the IETF working group went ahead and reinvented the content of the non-free standard. They probably ended with up something that's close to the other standard, but totally incompatible with it. I'll never know if this is true or not. I'm certainly not going to spend $100 to find out, and few other people seem to be either. Standards seem to need to be free to useful.

Another point of view

It's hard to explain to many people exactly how strong a 128-bit cryptographic key is. This is probably due to the difference between the numbers 128 and 2¹²⁸. They certainly sound very similar, but while 128 isn't too big, 2¹²⁸ is mind-bogglingly huge. And because 2¹²⁸ is so big, it can be hard to explain to people exactly how strong a 128-bit key is. Here's a new approach that might work:

The chances of guessing a 128-bit key are the same as your chances of plugging in a USB cable the right way 128 times in a row. How often does that happen?

Questioning risk models

A critical look at the safety estimates for the Large Hadron Collider (LHC) may give us some useful insights into estimating the risks that information security tries to address. Here’s why.

The LHC is the world's largest particle accelerator. By smashing beams of protons or heavy ions together at extremely high energies, physicists doing experiments with the LHC are able to test predictions of high-energy physics and perhaps even give us additional insight into the structure of the universe a short time after its creation in the Big Bang almost 14 billion years ago. But because it works at such high energies, some people believe that it might be able to create microscopic black holes that could destroy the Earth. There has even been a law suit filed to stop the operation of the LHC based on these concerns. The legal challenge to the operation of the LHC was eventually dismissed, but a new paper questions the methodology of the study that estimated that the chances of a black hole being formed by the LHC are too low to worry about.

"Probing the Improbable," by Toby Ord, Rafaela Hillerbrand and Anders Sandberg questions the accuracy of the estimates that the chances of the LCH destroying the Earth are too small to worry about. They don't claim that the LHC is dangerous. They just question the methodology of the safety study.

The basis for questioning the methodology of the safety study is that the probabilities of the dangerous events that the study estimates are so low that they are dwarfed by other errors. The LHC safety report estimates that there's roughly a 1 in 1 billion chance per year of the LHC destroying the world. On the other hand, the chances of the model used to produce the estimate being in error or of an error happening in scientific calculations are much higher. This means that the 1 in 1 billion number isn't really an estimate of the safety of the LHC. Instead, it's really a conditional probability: the probability of the LHC being safe given that the model is accurate and there's no error in the calculations. According to "Probing the Improbable," roughly 1 in 1,000 is a reasonable estimate for both the chances of a peer-reviewed scientific papers turning out to be inaccurate as well as the chances of an error in calculations happening. Accounting for these possible sources of error can increase the overall estimate of the danger posed by the LHC by a significant margin, perhaps by a factor of 100 or so.

Information security deals with a similar situation. In quantifying the risks from using computer systems, we also deal with relatively rare events, but ones that can have severe or catastrophic consequences. This suggests that you could probably make a similar criticism of many risk models. In many cases, the probability that there's an error in the threat model or in a calculation may be greater than the actual probability of an event. After all, most risk models don't really get the same level of scrutiny that peer-reviewed scientific publications do. But just like the paper by Ord, Hillerbrand and Sandberg doesn't say that the LHC is dangerous, this doesn't mean that inaccurate risk models tell you that systems are not secure. It just means that you might want to question exactly what a risk model can actually tell you.

Who Responds to Spam?

Over the years, I have talked to several people in the spam-prevention industry. I almost always ask the same question. And the conversation almost always goes like this.

Me: Who are the people who respond to spam? Has anyone done any research on why they respond?

Spam-Prevention Rep: The spammers don't need many people to respond. At even well below 1% response rate, they make a profit.

M: Yes, I understand that. I'm not asking that question. I'm asking, who are the people who respond to the spam?

S: It doesn't matter, all the spammers need are a small percentage to respond and they make a profit.

M: Look, I'm not sure you understand the question. Do we know anything about the people who respond to spam? If we did, maybe we could do a better job of educating the public on spam so that fewer people will respond. Besides, I'm curious as to why people buy products from spammers.

S: I don't know how I can be any clearer, even if only a very small percentage of people respond, the spammers make a profit.

At first I was a little offended, did the rep really think I didn't know what they were telling me? Then I realized what was going on. The people in spam prevention did NOT know anything about the people who respond, and rather than simply say, "We don't know," they deflect the question. In my opinion they were being dishonest.

Finally, one day someone from the spam prevention industry said it, they don't know who responds, nobody has done any research on why people respond. He said that information might be helpful in crafting strategies to eliminate spam. I have a lot of respect for that guy.

How does one find the people who respond to spam? Ask the spammers? Well, here's a story about one spammer's customer list that saw the light of day. The problem is, this is an example of a data breach, the spammer had a security problem that allowed anyone to see the customer list. The first question should be, is it ethical to use that list? If you are not a thief, but just a researcher or reporter, is it ethical to use information that was supposed to be private? I say no.

Hence, we still don't have a list of people who respond to spam.

I think this would be a great project for a Sociology major, maybe even a master's thesis or doctoral dissertation. Advertise on the internet, find people who have responded, or people who know people who have responded to spam. Pay them some money to answer some questions. Then come up with some analysis, why do people respond to spam? Why do they click on the links and why do they buy the products advertised?

Although that would not test my theory: wiring in the brain. We're all wired differently, for some of us, certain activities are easier, or other activities provide more enjoyment. For example, here is an example of researchers looking at brain activities of gamblers to see if there are differences between those with gambling problems and those without.

That would be another great test, watch people's brains while they read spam. Maybe even ask them to click through. What happens in the brains of those who buy the spammers' products, and those who do not.

Hardware random number generation may be harder than you think

It's very difficult to find a source of entropy that's truly random, but sources that are based on some sort of physical process are usually good places to start. You might think that radioactive decay would be a good process to use to create random bits, but new research has actually shown a correlation between decay rates and the Earth's orbit around the Sun.

The researchers who found this unexpected correlation were puzzled by the conflicting measurements of radioactive decay rates that other researchers had measured and tried to find which estimates were the right ones. It turns out that all of the measurements may have been right, and the variation between experiments may be due to unexpected effects instead of errors on the part of the researchers.

By the Hoary Hosts of Hoggoth! This certainly is strange. What's going on here?

When I first heard of this research, I wasn't too surprised. After all, General Relativity tells us that time is distorted when you go fast or are near a very massive object. These effects are significant enough that the GPS system won't work without accounting for them, so they're very real. Knowing this, my first thought was that the change in decay rates were probably due to similar effects from the elliptical orbit of the Earth around the Sun. Maybe when the Earth is closer to the Sun, time is just slowed a bit more that when the Earth is further away from the Sun. Maybe the difference in speed between when the Earth is the closest to the Sun and when it's farthest away is also part of this.  

The researchers who found the correlation between decay rates and the Earth's orbit don't mention this as a possible cause of the variations in decay rates, however. Instead they suggest that the changing rate of solar neutrino flux may be responsible for it. This something that I know absolutely nothing about, and it looks like my first guess wasn't even close.

So it looks like a source of entropy that based on radioactive decay may have non-random components that are actually measurable. In light of this research, one thing is still certain: it's hard to find a source of entropy that's truly random.

More quantum strangeness

Many people who study Mathematics or Computer Science in college often learn about Gödel's First Incompleteness Theorem. This essentially says that any axiomatic system will always be incomplete, because there will always be things that are true that you can't prove from the axioms. This also means that if you keep adding axioms to your system, you'll eventually be able to find propositions that are logically independent from your axioms, so that they can't be either proven or disproven from the axioms. Such logically independent propositions are called "undecidable." Ever since Gödel proved his First Incompleteness Theorem in 1931, the concepts of logical independence and undecidability have been confusing students of mathematics and computer science. They may also start confusing students of physics soon.

Last year, a group of physicists suggested that there's a link between undecidability and randomness. In particular, they show that quantum systems can encode axioms, and that measurements of such systems can tell whether or not logical propositions are decidable or not within the axioms. This means that undecidability can limit what you can learn from physical measurements. They then argue that quantum randomness is really just a physical manifestation of undecidability. Could there be implications of this connection in quantum computing or quantum cryptography?

Now THAT'S a blacklist

No, hacker's didn't really take over the entire Internet this weekend. Instead, a glitch at Google caused them to add the "This site may harm your computer" warning message to every search result roughly between 6 AM and 8 AM yesterday.

I've always found that message particularly annoying. Neither a manual process nor an automated one is ever perfect, but every web site that I've seen that warning for hasn't seemed to be trying to harm my computer in any way. It's been wrong so often that I just ignore the warning when I see it. Maybe I just don't visit the right kind of web sites.