Superconductor

More on the Cryptographers Panel misunderstanding

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

Why is this?

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

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

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

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

The PBA attack on RSA

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

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

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

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

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

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

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

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

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

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

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

HOT ROD: Universal greeting?

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

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

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

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

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

KUP: See, the universal greeting works every time.

Transformers: The Movie, 1986

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

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

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

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

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

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

How to protect test data

Like I mentioned in a previous post, many things are more complicated than you first think. Testing IT systems that handle sensitive data is a good example of this.

You probably don't want to use real data in testing because of the compliance issues that it can cause. On the other hand, you also want your test data to be as much like the real data as possible to make the results of any testing reflect the behavior of the system under real conditions as much as possible. This is actually tricky to do.

It looks like our marketing guys have put together a webinar that talks about how to solve this very problem, so if this is of interest to you, you might want to consider checking it out. You can sign up for it here if it sounds interesting.

Her's a quick summary of this webinar:

Securing Confidential Data in Non-Production Environments
End-to-End Data Protection for Test, Development and Outsourced Systems

Date: December 9, 2009

Time: 10 am PST / 1 pm EST

Duration: 60 minutes

This webinar doesn't have as clever a name as the last one that we had (The Renaissance of Enterprise Key Management and the Barbarian Hordes), but I'm sure that it will contain lots of useful information.

The limits of provable security

I've never quite understood the objections that people have to cryptographic schemes that are provably secure. If you have a proof of security then one of two things must be true: either the scheme is secure or there's a flaw in the proof. There's no other possible case.

All of the technologies that Voltage's products use have such proofs. The Boneh-Franklin IBE, the Boneh-Boyen IBE and our format-preserving encryption technology all have such proofs that have been published in peer-reviewed research journals. Because of this, I often don't understand the questions that I sometimes get about the security of our technologies.

Here's a situation that I've seen more than once. Someone asks about the security of our FPE technology, for example. We'll point them to the paper by cryptographers John Black and Phil Rogaway that has a proof for the security of the scheme. The next question is essentially, "But why should I believe that it's secure?" At that point, I'm never quite sure what to say next. If you have a proof in front of you, then either the proof is correct or there's an error in the proof. If this proof is of the security of a cryptographic scheme, then either the scheme is secure or there's an error in the proof. As mentioned above, there's no other possible alternative.

My recent experiences have led me to believe that there's a fundamental problem with this approach, and that's because many people really aren't comfortable with the idea of a proof. I've seen many cases recently where people essentially accept P and NOT P at the same time and don't seem bothered by doing this.

Every time I see this, I start thinking about the logical implications of it. After all, if you accept both P and NOT P then you can prove that absolutely anything is true. "If 2 = 3 then all cats are dogs" is absolutely true, for example. But because many people either don't understand this or don't believe this, I've come to the conclusion that proofs of security really aren't that useful. They may help specialists make sure that their work is correct, but to non-specialists they really don't say anything useful.

Key management for the barbarian hordes

It looks like our marketing guys are having another webcast about key management. The title of this one alone, "The Renaissance of Enterprise Key Management and the Barbarian Hordes Enterprise Key Management: Fact and Fiction", makes me think that it will be too good to pass up.

This entertaining and educational webcast will be held on November 17, at 10 AM PST (1 PM EST). You can sign up for it here.

More Bayesian thoughts

Encryption isn’t as widely used as it could be, and we might be able to understand this from the point of view of Bayesian statistics. Here’s why.

Much of the negative feelings that people have about encryption can probably be explained by the bad reputation that encryption has, and this reputation is probably justified. Many people who used some of the encryption products that were available back in the dot-com era are probably still suffering from the trauma that using encryption caused them. Older encryption products were hard to use, which made them expensive to support.

Even security specialists couldn’t use some of the early encryption products. When I worked at one of those dot-com era companies that made those early encryption products, I remember being stunned by a demo of an application that we had developed to let users authenticate to a server using the WTLS protocol. It was terrible, and this was from the point of view of a person who thought that using X.509-based client certificates was easy.

Many people suffered through using the early encryption products, and they’ve probably developed a significant bias against using encryption because of this. This is perfectly understandable. From a Bayesian point of view, they’ve built a knowledge base that tells them that encryption is hard and expensive, and this will affect how much they believe that newer products are actually easier to use.

Suppose that you tell a person who used older encryption technologies that the newer ones are much easier to use. If they're using Bayesian reasoning, they probably won't believe you, and this is because of what they're really estimating when you tell them this.

Let E represent how much someone believes that encryption is actually easy to use, N represent the claim that newer encryption technologies are easier to use than earlier ones, and K represent experience with the older technologies. If people are using Bayesian reasoning, instead estimating P(E|N), they're really estimating P(E|K∩N). If you’re really motivated, you can work through calculating P(E|K∩N), much like we did in an earlier post, and if you do this you’ll find that we can’t expect people to believe that the newer technologies are actually usable.

The problem is that they are.

Encryption has become much easier to use in the past five years or so, and it’s now feasible to use in many situations where it wasn’t practical at all in the past. That means that there’s now a solid business case for its use, even though people may not actually believe it. After all, the people who are making decisions about using encryption today are the same people who had to suffer through using the bad implementations of it that we had in the dot-com era. And because their experience has told them that encryption is hard and expensive, we can expect them to not believe that newer technologies are really any better.

One way to address this problem may be for researchers to look at the newer technologies and try to measure their usability. The famous paper “Why Johnny Can’t Encrypt” was followed by “Why Johnny Still Can’t Encrypt” a few years later, but the later work didn’t look at the newer technologies. Instead, it looked at how much the same technology used in the earlier study had improved. A more useful study might look at products like Voltage’s SecureMail, which is much easier to use than the previous generation of products.

The participants in the study that was described in “Why Johnny Can’t Encrypt” had to do some fairly low-level work with their keys. A user of SecureMail, on the other hand, doesn’t need to worry about those details at all. If they can click on the “Send Secure” button instead of the “Send” button in their email client then they can send encrypted messages. I can’t believe that any study would find that particular task too difficult for most people to do.

The problem may be finding a way to get people to believe that it’s really that simple. If they’re using Bayesian reasoning, however, they might not even believe it after they’re shown it. How do you work around that?

Why use Secure Mail?

I predict that some day we'll notice that very few consultants encrypt their email. This will be because of the secure email products that they were forced to use when they worked at larger companies. My experience with ice cream leads me to believe this.

When I was a kid, we would frequently get ice cream on the way home from school. I always wanted to get a clown cone, a scoop of ice cream in a sugar cone that's decorated with candy to look like a clown. Clown cones don't actually taste that good because they've usually been sitting out for quite a while before you buy them, but they certainly look good, and that's why I always wanted one.

My parents, however had different ideas. They knew that clown cones don't actually taste very good, and they never let me get one. After years of being cruelly denied clown cones, now I'm the dad, and nobody (except my wife of course) can tell me that I can't get one. I do this every time I take my kids out for ice cream, cheerfully ignoring the fact that the clown cones really don't taste that good as I do it.

Now consider the people who have to use email encryption on the job. Many of these people aren't lucky enough to be using Voltage's SecureMail, which is extremely easy to use. Some of them even use PKI and S/MIME to protect their email. They probably hate every minute of this, but are forced to use S/MIME anyway.

Some of these people are going to become consultants one day. They'll be their own boss and won’t have a security department to force them to use S/MIME. I expect that many of these people will rebel against their terrible experiences with S/MIME by intentionally avoiding using encrypted email as much as they can, ignoring that fact that they really should be protecting sensitive information.

What's the solution to this? Use Voltage's SecureMail, of course.

A big red flag

Seeing the phrase “up to” should make you very suspicious of what comes after it, particularly when it’s used in phrases like “may be up to 10 times faster.” One of Voltage’s competitors actually used that phrase to describe how the performance of their products compare to the performance of Voltage’s. In this particular case, they weren’t being totally honest.

Consider the statement “my salary could be up to $1 million this year.” The unfortunate and harsh reality is that I make much less than that, but the statement is certainly true nevertheless. Similarly, our competitor's claim that their performance “may be up to 10 times faster” is also true for much smaller multiples. It’s even true if they’re performance is actually worse, isn’t it? A multiple of 0.5 is also less than a multiple of 10, after all.

I’ve seen one case where the phrase “up to” actually made sense. That was in one of Symantec’s reports on the underground economy. When they estimated the value of stolen credit card numbers had to cyber-criminals, they said that it was “up to $5 billion,” but that was because they didn’t know how many of the credit card numbers being sold were actually valid. If all the credit card numbers were valid, they’d be worth the full $5 billion, but because some were probably invalid, the actual value was probably less than $5 billion, and it was hard to estimate by how much. That’s a case where saying “up to” seems to make sense. In most cases, however, it should be a warning that what’s being said probably isn’t very accurate.

I plan to do up to 100 more posts that talk about this in more detail.

Software as a service

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

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

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

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

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

Another misunderstanding

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

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

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

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

Maslow's hammer

I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.

Abraham Maslow, Psychology of Science: a Reconnaissance

Although he’s most famous for Maslow’s hierarchy of needs, Abraham Maslow also noted that people with incomplete knowledge or understanding tend to propose the same type of solution to every problem that they encounter. This phenomenon isn’t widely known as “Maslow’s hammer,” although there’s probably a good reason to use that term for it. Maslow may not have been the first person to notice it, but he was probably the first to describe it in a way that’s easy to understand and explain. I see Maslow’s hammer fairly often in the field of information security, but that’s probably just because that’s an area I know something about. It probably happens in other industries too, but I don’t know enough about those industries to see it.

There are lots of people out there that understand a little about PKI, for example. Some of them learned it when PKI was trendy and fashionable during the dot-com boom. Others learn a little about it when they get their MCSE certification. In most cases, they really don’t use it much because very few applications support it. So even if they’ve set up a PKI in their organization, they probably haven’t done much with it. But because they know a little bit about PKI, that becomes the hammer that Maslow’s hammer describes, and they often treat every encryption project that comes along as one that can be solved by PKI. Some can, but even more can’t.

Voltage’s sales managers often meet people who have the PKI hammer in their toolbox, and have to convince them that there’s a better alternative. That can be tricky, but the benefits of using identity-based encryption are fairly significant. In most cases, it turns out to be worth the time and effort that it takes customers to learn about how IBE can be a good alternative to PKI.

One day, someone will probably invent a technology that’s better that IBE in some way. IBE already has lots of users – roughly 10 million users at several hundred businesses. So when the better technology comes along, the company that’s selling it will probably have to overcome the resistance of customers who will be viewing IBE as the hammer with which to solve all of their encryption problems. But with any luck, Voltage will invent that next step.

Has secure email crossed the chasm?

 

The recent large deployment of secure email at Wells Fargo that Voltage recently announced is just one of many large deployments of Voltage's SecureMail in the past year or so. This might be enough to make you wonder exactly where secure email is on the technology adoption life cycle. Has it crossed the Chasm that was popularized by Geoffrey Moore and entered the Early Majority phase yet? Or is it still stuck in the Innovators phase?

To understand this, it might be helpful to describe exactly what the technology adoption life cycle is. It turns out to predate Moore's book Crossing the Chasm by over 30 years, and its first version actually modeled the adoption of a fairly different area: it was actually first used to describe how farmers adopt new agricultural technologies. The first discussion of the technology adoption life cycle was the 1957 report The Diffusion Process, by George Beal and Joe Bohlen that was published as a supplement to Iowa's Regional Extension Publication No. 1, How Farm People Accept New Ideas. This model was then described in the 1962 book Diffusion of Innovations by Everett Rogers, where Rogers generalized the process to more that adoption of agricultural technology by farmers.

Beal and Bohlen modeled the adoption of new technologies by farmers as a process with five stages: Awareness, Interest, Evaluation, Trial and Adoption. In the awareness phase, people know about a new technology, but lack details about it. In the interest stage, people want more information about a new technology. In the evaluation stage, people think about a new technology and whether or not it will benefit them. In the trial stage, people start small-scale experimental use. In the adoption stage people have large-scale, continued use of a new technology. What's interesting in Beal and Bohlen's discussion of these five stages is how the most common way for people to learn about new technologies change at each step in this process. The most common ways to learn about a new technology in each phase are shown below.

Awareness	Interest	Evaluation	Trial	Adoption
1. Mass media	1. Mass media	1. Neighbors and friends	1. Neighbors and friends	1. Neighbors and friends
2. Government agencies	2. Government agencies	2. Government agencies	2. Government agencies	2. Government agencies
3. Neighbors and friends	3. Neighbors and friends	3. Mass media	3. Mass media	3. Mass media
4. Salesmen	4. Salesmen	4. Salesmen	4. Salesmen	4. Salesmen

We can summarize this by saying that when people move past just interest in a technology and start to evaluate it, then the source of their information changes from the media to people that they know. At that point, it seems reasonable to assume that the marketing efforts of technology companies should change. I don't know if sales and marketing people at technology companies use this model, but I wouldn't be surprised if they do. Curiously, salesmen come in dead last in every phase. Maybe they're never perceived as being a good source of information because they can probably be relied on to give information that's biased towards their products.

When it comes to individuals, Beal and Bohlen divided them into categories that are determined by how soon they adopt new technologies. This is where they divided people into the categories of Innovators, Early Adopters, Early Majority, Majority and Nonadopters. This is the model that Moore popularized in Crossing the Chasm, changing Majority to Late Majority and Nonadopters to Laggards when he did. Where is secure email on the technology adoption curve? Has it made it past Moore's Chasm?

Technologies reach Moore's Chasm in the Early Adopters phase. This means that if a technology is in the Early Majority phase then it's definitely past the Chasm. If it's still in the Early Adopters phase, then it might or might not have. People who are early adopters tend to take risks, but only to achieve very focused goals. They'll even work with start-ups to do this. People in the Early Majority are pragmatic. They don’t like the risks associated with new technologies but are willing to look at technologies when they've been tested by others.

Based on my experience at Voltage in the past five years, it seems to me that secure email entered the Early Majority phase in the past year or two. Before then, it was definitely only used by Early Adopters. Back then, Voltage's customers were ones that felt willing to take the risk associated with a small company and a new technology because the technology solved certain problems cheaper and easier than alternatives. More recent customers, however, seem to see secure email as an established and proven technology. They're now willing to deploy it widely, and Voltage now has several customers with over 100,000 users of its SecureMail products.

If Voltage's experience is representative of the entire secure email market, then secure email has crossed Moore's Chasm and is on its way to becoming used by a majority of businesses. That means that we'll probably see even more adoption of secure email in the future, and large deployments like the one at Wells Fargo should get more and more common. They might even become so routine that they're not even interesting any more.

Mehrabian's rule

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

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

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

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

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

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

Size does matter

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

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

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

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

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.

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.

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.

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.

Largest Data Breach

It looks like Heartland Payment Systems is the latest victim of a data breach, although it might be more accurate to say that both they and their customers are the victims. In this case, hackers appear to have sniffed transactions with the Heartland system, all of which were unencrypted. Heartland's CEO has been quoted as explaining that they need to have the transaction data unencrypted to process it. Here's a summary of what's known so far:

• Heartland Payment Systems processes payroll and credit card payments for more than 250,000 businesses
• They reported that they discovered an intrusion last week that exposed consumer credit card data last year
• They were alerted to suspicious activity in processing Visa and MasterCard transactions—auditors then discovered malware that had compromised the company’s data
• Company spokesperson says they “understand that this incident may be the result of a widespread global cyber fraud operation, and we are cooperating closely with the United States Secret Service and Department of Justice"

This incident highlights the fact that achieving PCI compliance does not imply that a business has achieved real security. For example, PCI does not currently require that credit card data be encrypted as it is moved between machines on a corporate network, which is highly likely where this breach occurred. This incident should serve as a wake-up call that PCI should be used as a starting point instead of an end point in the effort to protect sensitive data.

Robust encryption technologies and innovative solutions that leverage them exist today that could have prevented this breach altogether. In fact, best-in-class businesses are currently implementing software that can address these types of attacks. However, Heartland appears to be an example of an organization which assumed that simply passing its PCI audit meant that it was truly secure.

Why were they targeted? Data can now be easily monetized, creating demand for criminal data theft, and increasingly, multi-tiered networks of organized hackers have replaced bored teenagers as the perpetrators of computer attacks. TJX, Hannaford, RBS Worldpay and now Heartland are just a few of the organizations that have fallen prey to orchestrated offensives. The perpetrators here are likely multi-tiered networks of hackers and social engineering manipulators who can gather and auction bulk data to the perpetrators of credit card fraud. This attack could potentially have been enabled or even initiated by an insider, even though Heartland says in this case it was not.

How can organizations reduce this type of risk? Most processors – even if PCI compliant – currently have, as standard practice, sections of their network where data is not encrypted or in the clear in order to communicate with the upstream clearinghouses and card companies (e.g. Visa, Mastercard, American Express). These gaps create excellent attack points for hackers, as data is fully exposed.The only solution to eliminate this threat is end-to-end encryption. New techniques such as Format-Preserving Encryption (FPE) and Identity-Based Encryption (IBE) allow organizations to encrypt information at the point of capture, and data is persistently protected all the way to the trusted clearinghouse. No air gaps, no exposure. Even if a hacker gains access to an intermediary system, no actual data can be stolen.

It's certainly true that many encryption technologies don't protect data as it moves through a network. Database encryption, for example, may protect data while it's in a database, but doesn't do anything for the data once it leaves the database. Even SSL doesn't protect data all the time. SSL may protect data while it's moving, but after it's moved, the sensitive data then typically sits on a server somewhere, where's the protection provided by SSL is gone.

Some encryption technologies, however, do indeed provide the capability to protect data no matter where it goes. Format-Preserving Encryption(FPE), the new mode of AES that's been submitted to NIST, lets you do this. Data encrypted with FPE has the very same format as unencrypted data. A 16-digit number gets encrypted to another 16-digit number, for example. If you use FPE to encrypt sensitive information, it's easy to keep the protection provided by the encryption, even as the encrypted information moves through a network.

Other ways to encrypt sensitive information may cause problems, particularly in legacy environments. In these, there's often a system somewhere that won't be able to handle encrypted information because it's format is different than the unencrypted information that it's expecting. If you encrypt a 16-digit credit card number, for example, and the encrypted credit card number may be longer than 16 characters or may be no longer just digits, This means that many legacy systems will be unable to handle encrypted information gracefully. On the other hand, if the format of the data is unchanged by encryption, then even the most complicated legacy systems will be able to easily handle it.

This is exactly what FPE does, which means that if you use FPE to protect sensitive information then there's absolutely no problem with keeping sensitive information encrypted at all times. If that's the case, all a hacker can get by sniffing a network is encrypted information, which is totally useless to him.

Can you crack a code?

The FBI has just posted the next installment in their cryptanalysis challenge. You can see this year's problem here. It's really not a very hard problem because there's a really long and obvious crib in it.

If you can correctly decrypt the FBI's message, e-mail me your solution and I'll get you a free one-year subscription to Voltage's hosted e-mail and file encryption service - the Voltage Security Network.

VHS, QWERTY and IBE?

It's commonly believed that having the right marketing is often more important than having a good product. The examples that are often used to support this position include the triumph of VHS videocassettes over Betamax and the triumph of the QWERTY keyboard over the Dvorak keyboard. The success of many Microsoft products is sometimes added to this list.

In their book Winners, Losers and Microsoft: Competition and Antitrust in High Technology, Stanley Liebowitz and Stephen Margolis argue that none of these examples will stand up to careful scrutiny, and that superior products almost always win in the marketplace. They give fairly solid arguments that support the position that VHS and QWERRY won on their merits, and claim that even Microsoft can’t use its marketing power to win when they have products that are inferior to the competition.

Now let's go back in time to five years ago. At that time, Voltage had no customers but had a good idea that related to how to make a better e-mail encryption product. Back then, people weren't sure what to make of the new "identity-based encryption" technology. It was based on difficult mathematics, so the average person in a corporate security department didn't really have much of a chance to understand how it worked. Even encryption specialists had a hard time understanding it at first. I know that I did.

But people didn't buy IBE because of the elegant mathematics that it uses. Instead, they found that it actually had some significant benefits compared to other encryption technologies. Not needing to look up keys is a big advantage. Not having to manage certificates is another. Maybe the most important of all is the fact that by calculating keys on the fly, the back end of an IBE system is extremely simple. This means that it's much simpler to support and operate, which also means that it costs less.

Enough people found these advantages compelling enough to convince them to buy a product that uses IBE, and there are now over 10 million users of the technology worldwide. If Liebowitz and Margolis are right, that’s probably proof that it's a useful technology. Maybe it will even up as a case study in a book that they write one day.

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?

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."

People of gender?

A few years ago, I hacked together a prototype of an IBE-encrypting IM client using an early version of the Voltage IBE Toolkit. It was interesting to use the Toolkit to IBE-enable a new application. Even more interesting was what I learned about usability and user interfaces from the experience.

After having finished the encryption part of the IM client, I thought that I’d ask people how they wanted the IM client’s user interface to indicate that a particular message was encrypted. I found the results to be a bit surprising - they were clearly divided along gender lines.

Men, it turned out, wanted a fairly in-your-face indication that a particular message was encrypted. They suggested things like changing the background color of an IM window to bright red or displaying the text "SECURE" in a large font. Every man that I asked about this gave a similar answer, although the particular way to indicate an encrypted message varied from man to man.

Women didn’t seem to like this idea at all. They all wanted a much more subtle indication. They thought that a small padlock icon was adequate to indicate that a message was encrypted, and that the padlock should be the familiar shade of gold that’s often used to indicate that a browser is using SSL for an encrypted connection. Every woman that I asked about this gave a similar answer. They even described the padlock icon that they wanted to see in a similar way.

Extrapolating from a single point is not a great idea, but based on this one data point, there seems to be a significant difference in the user interface that people would like to see based on their gender. Is there enough of a difference in the user interface that men want versus what women want to justify having two options – one that’s tailored to the expectations of men and another that’s tailored to the expectations of women?

Bart gets an elephant?

After reading the article “Identity-based Encryption Comes of Age” that I wrote for the August 2008 issue of IEEE Computer, I was reminded of the following dialog from the episode of The Simpsons “Bart Gets an Elephant” that happens right after Homer Simpson drives his car off the road and hits a statue of a deer.

Homer Simpson: “D’oh!”

Lisa Simpson: “A deer!”

Marge Simpson: “A female deer!”

The word “d’oh” is so useful that it now has its own entry in the Oxford English Dictionary. I certainly had a good use for it recently.

The editors at Computer always shorten things a bit, probably due to space constraints. To do this, they often rewrite parts of articles, doing their best to keep the original meaning intact. This time I missed an error that crept into “Identity-based Encryption Comes of Age” during the editing process when they did this. Instead of saying this:

“in an IBE system, the PKG’s security becomes as important as the key recovery system’s security,”

the edited version of the article said this:

“in a PKI, the PKG’s security becomes as important as the key recovery system’s security.”

While the first version makes perfect sense, the second version doesn’t, and that’s the version that got printed.

D’oh!

Better key words for standards

Standards can be very useful. Voltage’s products support dozens of them and we’re also involved in the development of new ones. On the other hand, standards sometimes reflect an ideal view of the world that doesn’t really exist. A good example of this is the RFC that defines what certain key words mean in IETF standards. Other RFCs refer to this when they say:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

The problem is that vendors don't always interpret these key words as they should. Not all vendors implement things that they MUST implement and some vendors do things that they MUST NOT do. Because of this, a more realistic set of key words that reflects this might be more useful. Here’s my proposed list. These reflect the expected percentage of vendors that will actually implement a particular feature.

Key word	Percentage of vendors expected to implement feature
MUST	90
SHOULD REALLY	80
SHOULD PROBABLY	70
SHOULD	60
MAY OR MAY NOT	50
SHOULD NOT	40
SHOULD PROBABLY NOT	30
SHOULD REALLY NOT	20
MUST NOT	10

This new set of key words might not appeal to many of the participants in standards groups, but they'd at least set expectations correctly. That's something that the current key words might not do as well as they could.

What's in a name?

"What's in a name? That which we call a rose
By any other name would smell as sweet."

William Shakespeare, Romeo and Juliet (II, ii, 43-44)

Identity-based encryption (IBE) is now a well-established technology. It has roughly 10 million users worldwide and is used by some of the world's largest companies. But it wasn't always this way.

Shortly after Dan Boneh and Matt Franklin invented the first practical and secure IBE scheme, Dan and some of his students founded Voltage to commercialize the IBE technology. In the early days of Voltage, the fact that the "I" in "IBE" stands for "identity" caused more that a few problems. Back then, I had more than one conversation that went roughly like this:

Me: "We have this great new technology called 'identity-based encryption.' It's a public key technology, but it doesn't use certificates, so you avoid lots of the headaches that using PKI for encryption causes. It will let you encrypt e-mail that contains sensitive or private information at a fraction of the cost of doing the same thing with PKI."

Customer: "Oh, we're the encryption group. You need to talk to our identity management group."

Me: "D'oh!"

Some people argue that IBE should really be called "identifier-based encryption," because the string that IBE uses for a public key comprises more than just an identity. It also contains information like the validity period of the key as well as the URL of the key server where a user gets his IBE private key. Despite this, the term "identity-based encryption" has stuck, and it has been identified so strongly with the technology that it's probably impossible to change things now. Using a different term sure would have made it easier in the early days, though.

The "killer app" for security

The information security industry has been in search of its "killer app" for many years, an application that is so compelling that it will be universally adopted. The killer app for information security is probably encrypted e-mail, but it will be a few years until that's widely realized.

People are inherently social creatures, and love to communicate with others of their kind. Because of this, voice calls seem to be the killer app for the telecommunications industry and e-mail seems to be the killer app for the Internet. Because of the lack of glamor with point-to-point communications, however, these two technologies are often overlooked, but they're the ones that people use and use often, and they seem to have roughly the same popularity.

Voice calls may be dull compared to flashier digital multimedia content, but they're still where the money is. The worldwide movie revenues are less than a week or two of the worldwide telephone revenues, for example. And the dull technologies are also wildly popular.

Given the choice between giving up their phone of giving up e-mail, people are about equally divided. When comparing e-mail to other Internet technologies, however, it's no contest. Given the choice between giving up e-mail and giving up browser-based web access, people cheerfully give forgo the web in favor of e-mail. The web may be nice to have, but e-mail is a necessity, and most businesses really can't function without it.

So if e-mail is the killer app for the Internet, it's likely that it will eventually need the protection that encryption can provide. Many people would currently like to encrypt their e-mail, but have found that it's just too difficult to do. Fortunately, this has recently changed, and we probably have the recent data security and privacy laws to thank for it.

Although it has been used by power users for many years, encrypting e-mail has been notoriously difficult for the average user to do. So difficult, that e-mail encryption remained a small and insignificant niche of the information security market. Recently, however, regulators have made it more difficult to justify sending many business e-mail unencrypted. This has created a huge interest in e-mail encryption products, with e-mail encryption now topping the lists of projects that corporate IT departments plan to roll out in the near future..

Motivated by the increased market for their products, e-mail encryption vendors have invested heavily in research and development, the result of which has been a new generation of products that are much easier to use than their predecessors. Messaging analyst firm Ferris Research estimates that one new technology, identity-based encryption (IBE), can reduce the TCO of encrypted e-mail by a factor of at least three to five, with most of the benefits coming from its improved ease of use. Such a reduction can make a big the difference between an ROI that is acceptable and one that is not. It can even create an ROI that is strong enough to stand on its own, even without the need of regulatory compliance to justify an investment in the technology.

So now that encrypting e-mail has become easy enough for widespread use, it's probably only a matter of time until it's widely adopted. But when that happens, it will seem to disappear as it becomes just another part of the communications infrastructure. It will be a dull technology, but one that's wildly popular. And given a choice between that option and being a flashy technology with limited adoption, the dull yet popular route is probably preferable. So although encrypted e-mail may indeed become one of the killer apps for the information security industry, we probably won't even notice when this has happened.

A new book on Identity-Based Encryption (IBE)

It's finally here - well it really came out in January - the definitive textbook on Identity-Based Encryption. If you are looking to understand the mathematical basis of IBE or are looking to implement an IBE system, or are merely curious about why there is so much attention being paid to pairing-based crypto, this will make an interesting read. It is however most certainly not "IBE for Dummies" - there are plenty of articles in the popular press that will give you that kind of overview, such as "What the heck is IBE?". This is a serious work that provides a wealth of practical techniques, algorithms and numerous worked examples that enable you to create a secure IBE system.

Who is the author - our very own Luther Martin. Currently a security architect at Voltage Security, Palo Alto, CA. He has published numerous journal articles on the topics of information security and risk management, is the technical editor of the IEEE P1363.3 standard for identity-based encryption and the principal author of the IETF standards that define identity-based encryption algorithms and their use in encrypting e-mail. Mr. Martin holds an M.S. in mathematics from the University of Cincinnati and an M.S. in electrical engineering from Johns Hopkins University.

Click here to browse a copy on Amazon.com: Introduction to Identity-Based Encryption (Information Security and Privacy Series)

AIDS/LifeCycle Ride

Our head of professional services, Dave Mulligan is doing the AIDS/LifeCycle ride - it's a 7-day, 545-mile (yes, really) bike ride from San Francisco to Los Angeles to raise money for organizations that help people living with HIV and AIDS. You can follow his progress here. - Wasim

Fox Business News features Voltage Security CEO

Voltage's CEO, Sathvik Krishnamurthy was recently featured in the CSuite Sitdown segment of the Money for Breakfast show on the Fox Business Channel discussing how Information Encryption solutions can dramatically reduce identity theft risks, speed time to regulatory compliance and enable developer access to production data without compromising sensitive customer information.

The interview focused on consumer privacy, identity theft and Voltage's information encryption strategy for persistently protecting sensitive data wherever it goes. Sathvik highlighted the problems the industry is facing, threats to consumers and the growing popularity of Voltage solutions in solving this problem.

For more details visit www.voltage.com/data_protection

Top Gear Data Protection

My favourite British commentator, journalist and presenter of "Top Gear" the fantastic BBC car show - Jeremy Clarkson- just had his identity hacked and his bank account breached. Unlike many victims of identity theft, he had recently published his bank account details in his column at the Sun newspaper. Why you ask ? Well he was simply fed up with the furor around the loss of 7.25 million records of British citizens lost by Her Majesty's Revenue and Customs agency in November. His thesis being that all those identities were not at all at risk and that bank security details are perfectly secure. This weekend he revealed in his Sunday Times column, that yes, his bank account had been tampered with and 500 GBP had been debited from his account and sent to the account of a British charity. Now he's advocating stringent measures to deal with people that commit identity fraud.

Here at Voltage we're about to introduce a new cryptographic approach, known as Format-Preserving Encryption, that will help foil identity theft in its entirety. Read about the solution that protects credit card numbers, bank account numbers and other structured personal data inside the vast databases and applications used by financial services companies around the world, here.

Innovation is Everybody's Business

For the upcoming FORTUNE Innovation Forum in New York City, two of the co-founders of Voltage Security, Matt Pauker and Rishi Kacker, discuss innovation and security in the FORTUNE Innovation blog.