Superconductor

Warning message message message message message

I recently looked into getting a copy of the Sage open-source math software. I was curious about how it compared to the software that I'm used to, like Mathematica or Maple. Like you seem to get with lots of open-source software, this wasn't as simple as I'd hoped. I first had to download Sun's VirtualBox software. When I installed this, I was surprised to get the following warning message:

Seeing this once was somewhat educational. Ah, this software hasn't been fully tested as being compatible with Windows.

I Continued Anyway and was surprised to see the same warning message FOUR additional times. I'm not sure exactly when it happened, but this message stopped being useful after a while. Probably after the second time that I saw it. There might be a good a reason why I had to see the same warning FIVE times, but it's not obvious to me exactly why that is.

I never did get a chance to try Sage. This might explain why:

 
  
 

Blog to book software

A few people have asked me about me creating a hardcopy book from the contents of this blog. Trying to find things to do other than look for errors in a math-heavy standards document, I recently tried out a couple of the available services that let you do this to see how hard it is and what's involved in doing it. I was stunned by how bad the available options were.

In one case, the first few posts were loaded into the book-making software with no problems, but the rest after that ended up badly garbled. That made that particular offering totally useless.

The next one I tried couldn't handle subscripts and superscripts, among other things, so it ended up being useless also.

I doubt that I'm the only person who does things like indenting text or using superscripts. Why can't the current versions of blog-to-book software handle the use of these things?

The source of bad decisions

I doubt that anyone tries to make a bad decision. Even the people who designed the automated wake-up call system that I described in a previous post probably didn't try to design a system with the worst user interface that they could think of. In this particular case, I can imagine that the following discussion between two product managers Alice and Bob that led to this particular feature:

Alice: Let's have the message that indicates that the call has been set say something like "Your wake-call has been set for 8 a.m. Have a nice day."

Bob: The problem with that is that many of our customers have guests from many other countries. If we have the message in English, then some guests won't be able to understand it. We need a message that doesn't use any language at all. It needs to be totally independent of human languages.

Alice: What are you thinking of?

Bob: What about a series of tones? It would have to be fairly loud, so that guests who are hard of hearing can hear them. And we'd also have to use a single tone to make sure that it's not mistaken for the series of four annoying tones that the phone company used to use to indicate that you dialed a non-working number.

Alice: Are you suggesting that we just play a sound like "BEEP BEEP BEEP BEEP ..." to indicate that a wake-up call has been set?

Bob: Yes.

Alice: Uh, I guess that makes sense.

Bob: OK, I'll make sure that it gets in our next release.

Alice: How should we tell a user that they've already set a wake-up call?

In many cases, I'd guess that the bad decision makes sense when it's made, although it may be hard to reconstruct the thought process that led to this decision at a later date.

I wonder what it would have been like to be at the meetings where the design of the Department of Defense's PKI system was discussed. I'm sure that it made perfect sense at the time. I almost wish that I could have been there to see it happen.

The worst user interface ever

I recently encountered one of the worst user interfaces that's even been designed. I came across this on a recent trip to Las Vegas when I stayed at one of the big-name hotels, although I won't say which one.

This particular hotel had an automated system that you could use to set a wake-up call for the morning. You were supposed to dial "*7" and then enter the time you wanted your call set for. When I did this, I heard a loud beeping sound: "BEEP BEEP BEEP BEEP...," with the beeps coming at about three or four per second.

"D'oh!" I thought. "That's not right. Let me try that again." (That's not really what I thought, but that's a version that's suitable for repeating in mixed company.)

I tried again and encountered another annoying sound. This one was a constant tone: "BEEEEEEEEEE."

Giving up on the automated system, I called the hotel operator, who proceeded to tell me that my wake-up call had been set and that the "BEEP BEEP BEEP BEEP..." was how you were told that you had done this and that the "BEEEEEEEEE" was the system's way of telling you that you already had a wake-up call set.

Now I'm not an expert on user-interface design, but I have to believe that using the message "BEEP BEEP BEEP BEEP..." has to be one of the worst ways to tell a user that they've successfully set a wake-up call. Most systems have a message that's closer to, "Your wake up call for .... eight ... a.m..... has been set. Have a nice day." That's one that most users quickly and easily understand. It's also one that probably keeps the number of calls to the hotel operator fairly low, which probably also keeps the support costs for the system fairly low.

On the other hand, the message that I encountered seems like one that's designed to do the exact opposite: to keep the number of calls to the hotel operator as high as possible and to thus keep the support costs for the system as high as possible.

The only way that I can explain the user interface that I experienced is that when a marketing person tried to quantify usability in some way they accidentally dropped a minus sign somewhere. Then, when they passed their design to the engineering department and asked them to maximize the usability of their system the usability was actually minimized instead of maximized. I find it hard to believe that someone really thought that "BEEP BEEP BEEP BEEP ..." was a good way to tell a user anything.

Friendly names for certificates

The naming of keys is a difficult matter,

It isn't just one of your holiday games;

You may think at first that I'm mad as a hatter

When I tell you a key needs to have a good name.

It should be the one that its users use daily,

Such as "This one's for email" or "For VPN,"

Such as "This one's for signing," or "Intranet access,"

All of them sensible everyday names.

If you use X.509 certificates, one problem that you might encounter is figuring out which certificate to use. Every certificate that I have has the same name for me in them, so unless I know the expiration date or the serial number of a particular certificate (which I never do), it's always a matter of trial and error when I try to figure out which one I need to use.

In Internet Explorer, however, there's a field for "friendly name" in the Certificates window that you can open by going to Tools→Internet Options→Content→Certificates. Once you get there, however, it's not obvious how to change the friendly name. You can do this if you select the Personal tab and then select a particular certificate. Then go to View→Details→Edit Properties, and you'll see a field where you can enter both a "friendly name" and "details" for your certificate. If you do that, you'll be able to easily tell the difference between your certificates without having to know their expiration dates.

In Firefox, it doesn't seem as easy. If you go to Tools→Options→Advanced→View Certificates, you can see which certificates you have, but I can't find a way to assign a friendly name to them. It looks like you'll just have to remember whether you need to use the one with serial number 48:CB:F9:8D:65:9E:B5:84:5F:AF:A4:A8:B4:08:E9:D1 or the one with serial number 22:4D:02:80:BC:DE:AD:E7:73:81:BF:6C:74:8A:B4:BF when you want to encrypt email. Or you can just try to remember the expiration date. Neither way seems to be very useful.

Hardware Engineers and Their Software

Over the years I have dealt with a lot of different security hardware, from tokens (PCMCIA cards, USB devices, etc.) and coprocessors, to crypto accelerators and "HSMs" (Hardware Security Modules). With the hardware product comes the software interface. If you're building a product that wants to take advantage of the chip or device, your code will call the supplied set of functions that will actually send the messages to the hardware informing it of the operations to perform.

Over the years I have complained bitterly about some of the software interfaces I have come across. I have seen some software that I thought was awful. I would be angry that a company would build a device, invite people to use it, then make the software interface so terrible.

Let me interject something here. I write software for a living. Most of the software I have written has gotten good reviews, but I must admit, there have been some bad reviews in there. Or sometimes the review was not so much bad, as the reviewer was a bit frustrated by complexity. For example, I read part of a book about Crypto APIs, and one of the APIs was BSAFE. Although I was not the original designer of BSAFE, I was a major contributor to that product. Furthermore, I'm on board with the design. I think it is a great design. (In fact, the Voltage toolkit is my design and the similarities to BSAFE are very evident, although I think I did make some improvements). Anyway, this book said that one of the best things about BSAFE is that it could do anything you could possibly want to do in crypto. The worst thing about it is that it can do anything you could possibly want to do in crypto. That made it complicated. Simple tasks were not necessarily simple. The point is, when I complain about someone else's software, I fully admit that someone can look at my designs and complain about aspects of it. I'm not saying my code has no flaws or problems for the customer.

But some of that software from the hardware vendors was terrible.

Well, now I might not be so quick to label it "terrible". Recently, I was talking with a hardware engineer. He said something that I think explains a lot of the "awfulness". He said the H/W person will design the software interface to mimic what the hardware does. Put another way, the difference between a hardware engineer and a software engineer is that the H/W engineer designs software based on what the hardware can do, the S/W engineer will design software based on what the user wants to do.

Who is the user? For the security hardware, the user is the application developer. That's the same user of the Voltage toolkit. So let's look at an example of two interfaces performing SHA-256.

Let's say you have an app that needs to perform SHA-256. Maybe it's for a digital signature, or maybe for a checksum, or maybe it's for a key derivation function. You need to digest something.

The Voltage toolkit says, "build an object that can perform SHA-256, then call Init, Update, Final. Provide the data to digest as a byte array. If you need to digest something else, keep the object around and reuse it, just call Init again to start over. If you have so much data that you want to perform the operation in parts, or maybe the data is from multiple sources and you don't want to collect it into a single buffer, call Update, Update, and so on until you have no more data, then call Final." In the end you have 32 bytes, the digest.

The interface to a hardware device might say, "provide 64 bytes and the eight h-values and the return is the updated h-values".

Great, what does that mean?

It turns out there is some rationality to that interface. You see, SHA-256 works this way.

• Start with 32 bytes, represented as eight 32-bit words, these are the h-values. Give them an initial value.

• Take the first 64 bytes of input and perform a function on them, call this function SHA256Transform. This SHA256Transform combines the h-values with the 64-byte input to update the h-values.

• Now operate on the next 64 bytes of input, and the next, and so on. Each call to SHA256Transform will use the h-values that were the result of the last call and combine them with the new input to create a new set of h-values.

• When there's no more output, apply padding. If the input data was not a multiple of 64 bytes, you need to pad so that you have a complete block on which the algorithm can operate (SHA256Transform can only operate on 64 bytes, no more, no less). Even if the input was a multiple of 64 bytes, you must apply padding (the padding scheme increases the security of the algorithm).

• After the padded block has been processed, the result is the 32 bytes that make up the last set of h-values.

Suppose you're a hardware vendor and you want to make a chip that can perform SHA-256. You'd really only do the SHA256Transform in hardware. Your chip would not do the work of breaking the input data into 64-byte blocks, nor would it perform the padding. The time-consuming and compute-intensive operation is the SHA256Transform. All the chip would be built to perform is the Transform operation.

When it comes time to build the software interface, what do you do? Do you build something that takes in byte array input and returns a digest (as the Voltage toolkit does)? Or do you put together a function call that is a "mirror image" of the hardware, namely the SHA256Transform?

A software engineer would probably say that while a SHA256Transform can be useful, that alone does not generate a digest. Most users will want to simply call a routine that takes in input and generates a digest. So the right thing to do is to perform all that "bookkeeping" as well as the transform.

The hardware engineer might say, "What do you mean? The hardware does the Transform function, therefore the interface should be the Transform function. Why should the interface do the bookkeeping if the hardware doesn't?"

The answer is that someone will have to do the bookkeeping. If the hardware interface does not do it, then the customer will. Or more precisely, each customer will. Suppose the hardware vendor has 50 customers. Each customer will write their own version of the bookkeeping code. That's 50 versions of the same code, quite a duplication of effort. Everyone has to "re-invent the wheel". Doesn't it make much more sense to do that work once?

This does not explain all the awful software I've seen come from the hardware vendors, but it does explain some of it. I don't agree with the philosophy, "The software interface is designed to do what the hardware can do, no more, no less." I suspect most people would think it is not the right philosophy a business venture should take. But at least I can understand it.

Challenges with point-of-sale devices

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

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

 

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

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

R. C. Matheson gets a certificate

Web site.

Find page.

Click "Login."

Enter Username.

Enter Password.

Click "OK."

Click "certificates."

Click "request certificate."

Click "request."

Click "request."

Yes, again.

Doesn't work.

IE8 problem.

Try Firefox.

Repeat steps.

First 10.

It works.

Click "next."

Select email.

Click "next."

Click "next."

Another duplicate.

Click "accept."

Click "next."

Click "finish."

Wait.

Check email.

Open email.

Click link.

Click "OK."

Certificate installed.

Now what?

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 Journey to the Center of the Earth

Jules Verne's book A Journey to the Center of the Earth might be able to give us some insights into what some people put up with some of the more complicated and less user-friendly information security products.

In Verne's book, Professor Lidenbrock hires an Icelandic man named Hans Bjelke as a guide. Bjelke turns out to be unflappable, and tolerates all of the dangers of the book's subterranean journey without complaining. The only thing that he insists on is getting paid three rix-dollars every Saturday. As long as he gets paid, he cheerfully puts up with hungry prehistoric creatures, lightning storms and travel by geyser through a volcano.

People who work in the 21^stcentury seem to be inspired by Bjelke to some degree, particularly when it comes to putting up with using some information security products. Some of these products don't even come close to being user-friendly, but people put up with them because they need to use them to do their jobs. And much like Bjelke didn't complain when he had to put up with the dangers that he found below ground, many people tolerate using difficult products because they're getting paid to do it. Maybe it's just because they feel they have to. Not many people will walk away from a job just because they have to use really annoying security products.

Because of that, I hope one day to do an interview for a job that I have no interest at all in getting that will go something like this:

Me: So how do you protect sensitive information that you send to customers?

HR person: We use encrypted email for that. Everyone has a "digital certificate," you see…

Me: Stop! I've heard enough! There's no way that I'll do that! You'll have to find someone else to fill this position.

That ought to create an interesting discussion in the HR department.

Time really isn't money

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

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

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

What clocks can tell us about usability

 

Information security is easy. You just want to keep unauthorized users from getting data that they’re not allowed to get and let authorized users get the data that they’re allowed to get. That doesn’t sound that hard, does it? You can do that by using cryptography. How hard can that be?

I may be even more biased than the typical information security person. Except for a few years working in mergers and acquisition consulting, I've been working with cryptography for over 20 years and I’ve more or less figured out how things work by now. I've actually never thought that it was that difficult, but I also understand that not everyone feels this way about it. So although I can both encrypt and decrypt S/MIME messages, I also understand that most people find it hard. Mechanical clocks played a role in getting me to understand this.

Every time I visit the British Museum, I visit the horological gallery, a collection of over 300 spectacular examples of mechanical clocks and watches from medieval times onwards. This exhibit makes me feel lucky that I was born in the twentieth century. If I had been born in medieval times I would probably have only had the skills to qualify for the position of village idiot. I can look at medieval clocks for hours and still not quite understand how they work. I apparently just don't have the right aptitude needed to understand mechanical clocks.

Many people in the information security industry would probably benefit from a similar experience. The people who make security products are often very out of touch with what the average user can and can’t do, but understanding this would almost certainly help them make better products. Many enterprise security architects would also benefit from this for a similar reason.

Both of these groups often assume that just because a technology seems simple to them that it’s simple to everyone. That’s often not the case. Sometimes, it’s not even close. Useful technologies even need to be usable by those of us who don’t quite understand how those clocks work.

Information security is easy

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

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

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

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

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.

Security by default

OpenBSD is designed to be secure by default. After you install an OpenBSD system, you need to explicitly make any changes that allow things that could cause security problems. The system administrators at a place that I once worked seemed to have a similar philosophy when it came to security, but it ended up not working quite as well as it does with OpenBSD.

At one time, I worked in the west coast office of a research institution whose main office was on the east coast. Oddly enough, our default printer was one that was in the east coast office, which was over 2,700 miles from our desks. Due to security concerns that I still don't quite understand, we couldn't change our default printer. Instead, we had to manually select the local printer every time that we printed something. If we didn't, our stuff would end up in Princeton, New Jersey instead of La Jolla, California. This happened fairly often.

Because we were working on classified government projects, all of the documents that we printed out were classified because they came off a classified system. This meant that the unlucky guys in New Jersey had to treat all of our printouts as if they were classified when they showed up on their printer, even if it was just directions to lunch. Because of this, every few days we'd get an email from the annoyed people on the east coast reminding us to be careful about our printer settings. This system might have been secure by default, but I don't see what good it did in this particular case.

So security by default may be a good idea, but you should probably make sure that your settings at least make sense before making them the defaults.

Disappearing technology

Back in the '90s I did worked with semiconductors. Semiconductor manufacturing technology is quantified by half of the distance between two adjacent metal lines in a DRAM. If this distance is 100 nm, then the technology is known as "50 nm" technology, and the name of a manufacturing process gives you a rough idea of how small the features of chips made with that technology are. The first CMOS that I saw was made with a 7,000 nm process. By today's standards, that's huge. We'll be seeing processors made with 32 nm processes soon.

You can see things with a microscope that are bigger that about half of the wavelength of the light that you're using to look at them. Visible light ranges from roughly 400 nm to 700 nm in wavelength, so the smallest features that you can see with a microscope measure about 200 nm.

This means that the old 7,000 nm technology was easy to see under a microscope, but the newer technology is essentially invisible. If you try to use light with a wavelength of 400 nm to look at things that are only 32 nm in size, you essentially can't see them. The components are still there and still function like they used to. It's just harder to see them. If you can afford an electron microscope, for example, you can still see the features of modern devices, but these are more expensive than an optical microscope and typically can’t be used by the average person.

Encryption seems to have followed a path similar to semiconductor technology. It still works like it used to, but it's gradually disappearing from view. That doesn't mean that it's gone. It just means that it's harder to see it.

Back in the dot-com era, when you used encryption, it was often painfully obvious. It typically meant fighting with digital certificates, which doesn't really appeal to most people. Even the most dedicated and passionate fans of digital certificates had a hard time using them on wireless devices when they were used in WTLS, the version of SSL that was designed for these very devices.

Today, however, encryption has become much easier. If you can click on the "Send Secure" button instead of the "Send" button, you can now send encrypted email. Gateway encryption makes it even easier than that when it automatically encrypts outgoing email as needed with absolutely no additional action required by the sender at all.

The most common use of encryption is probably to authenticate users of a Windows system. When you log in to Windows on your desktop PC, there's actually a complicated cryptographic handshake that takes place that provides a way to use your Windows authentication to authenticate to other places on your network. The average user doesn't know that this is going on, of course, and probably doesn’t even care. To them, the technology is totally invisible even though it still works.

So encryption is definitely used more today than it ever was in the past, even though it's invisible to users in many cases. Maybe that's the natural evolution of all information technologies – once they become widely used, they also disappear from view. On the other hand, becoming invisible to users may be the very reason that some technologies become successful. The best case seems to be when users don't even know they're using the new technologies. Some encryption technologies have already reached this goal and others are very close. Encryption will almost certainly be around for the foreseeable future - you just may not be able to see it.

Why PKI is still used

It's always fun to watch babies. They're born knowing absolutely nothing and have to learn how the world around them by watching how things work. Once they get a bit older, they seem to start doing experiments to check if what they think is actually true. When they're very young, for example, they notice that everything falls when it's dropped. When they get a bit older they'll try dropping things again and again to see if things really do fall every time they're dropped. After a while, they seem to decide that they've tested their hypothesis enough times and they stop dropping things. This is why adults don't do some of the things that babies do. Adults typically don't drop things just to see if they'll fall because they already did it hundreds of times when they were babies.

When they're learning about how the world around them works, babies will eventually give up if they find something doesn't work. They just file that away as part of their understanding of the world. On the other hand, adults also seem unwilling to learn from experience the same way that babies do. Some even insist on moving forward with technologies that have always failed in the past. It's enough to remind you of the following exchange in The Princess Bride:

Wesley: "Aha! Your pig fiancé is too late! A few more steps and we'll be safe in the fire-swamp."

Buttercup: "We'll never survive."

Wesley: "Nonsense! You're only saying that because no one ever has."

Some people seem to believe that they'll be able to succeed with difficult technologies, even though most others fail. PKI is probably a good example of this. PKI has been around for quite a while. The digital certificate was invented over 30 years ago and the first version of the X.509 standard that defines how to use certificates was completed over 20 years ago. But except for the single notable use in SSL, the technology has essentially gone nowhere in the past few decades. The root of the problem is essentially that while machines don't mind using digital certificates, people hate them.

Despite this clear evidence of failure, some organizations have still not noticed the trend in which trying to have people use digital certificates has a very high chance of failure. Maybe they see themselves as Wesley in The Princess Bride, who does indeed manage to survive the Fire Swamp despite the failure of those that come before him. On the other hand, Wesley had one thing going for him that most corporate IT departments don't: the fact that the scriptwriter was on his side. Consultants can help with many difficult issues, but even the best consultants don't have that level of influence.

Using HSMs

Avez-vous jamais été témoin de la fureur du bon bourgeois Jacques Bonhomme, quand son fils terrible est parvenu à casser un carreau de vitre? Si vous avez assisté à ce spectacle, à coup sûr vous aurez aussi constaté que tous les assistants, fussent-ils trente, semblent s'être donné le mot pour offrir au propriétaire infortuné cette consolation uniforme: "À quelque chose malheur est bon. De tels accidents font aller l'industrie. Il faut que tout le monde vive. Que deviendraient les vitriers, si l'on ne cassait jamais de vitres?"

Frédéric Bastiat, Ce qu'on voit et ce qu'on ne voit pas (1850)

Using hardware security modules that do cryptographic operations is fairly difficult unless that's what you specialize in. This means that if you're a security vendor, you often need to hire a consultant to help you integrate an HSM into your products. This might sound like a good idea, particularly in uncertain economic times.

By hiring a consultant, we're giving the consultant money that he then uses to buy stuff in the local economy. The people that he buys stuff from do the same, and the result is a chain of purchases that multiplies the effect of the money that we spent on the consultant and makes the local economy grow. This certainly sounds like a good thing, doesn't it? So maybe the fact that HSMs are extremely difficult to use is actually a good thing. It's like a government stimulus package for the economy, but on a smaller scale.

But as Frédéric Bastiat pointed out over 150 years ago, the idea that such spending is good for the economy is not true. It assumes that we wouldn't do anything else with the money that we'd have to spend on a consultant. This is never the case. In any business, there is never enough of anything. There's always more demand for cash than we have cash to spend. We could hire additional sales people. Or we could spend the money helping our channel partners. Or we could hire additional engineers. We could even buy some more of those balls that light up when they're bounced that are so popular at trade shows.

There's never enough money to do all of these, so when we have to spend money on consultants to help us get an HSM functioning, that means that we can't spend it on other things, like giving customers features that will make our products easier to use and thus save them money on the costs of supporting and operating our products.

The fact that HSMs are hard to use doesn't really benefit anyone, not even the manufacturers of the devices. You really have to wonder why they don't take the time to make their products more usable.   

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

Buggy hardware?

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

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

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

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

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

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

He never called back.

Technology is hard

Back in the days of the dot-com boom, I was talking to a major US airline about replacing their username/password system with certificate-based authentication. They already had a PKI deployed, at least in a minimal way – the people in the security division all had certificates and they had plans to roll the PKI out enterprise wide. They planned to use hardware tokens to hold users’ keys, and that’s why I was talking to them.

Apparently the people from other token vendors didn’t know much about side-channel attacks and other ways to hack hardware tokens. Because I was at least able to talk about this stuff in detail, they probably assumed that our tokens were proof against such attacks, although I certainly didn’t say that. But that was enough to make us the leading contender for a big order of hardware tokens. Hoping that an in-person meeting and demo would convince them to buy our USB tokens, a few of us hopped on a plane (taking flights operated by the airline that we were visiting, of course) and flew to the airline’s offices to show them how well our USB tokens worked.

We failed miserably.

A representative from the airline’s security group brought in his laptop for us to use in the demo, but when we plugged our token into the laptop’s USB port absolutely nothing happened. We had tested our tokens on a wide range of machines before flying out for the demo, of course, and we felt very confident that our demo would go off flawlessly. We were stunned by this failure and flew home determined to find out why we failed.

After a painful week of testing and research we found that there was a well-known problem with a particular chip set that made it not work with USB hardware, and it turned out that were unlucky enough for that particular chip set to be the one used in the laptop that was used in the demo. We hadn’t done our testing on any computers that used this chip set, so we were totally unaware that this problem existed. Even if we had, it would have been difficult to avoid the problem caused by it. Imagine asking a user if their computer uses a particular chip set – almost nobody would know the answer. So even if we knew about this problem in advance, it would have been hard to avoid in the demo.

Things like this happen all the time. Modern technology is complicated and doesn’t always work like it’s supposed to. If you’re in the business of developing new technology, this can make your job very tricky at times. Whatever you create has to work with the huge installed base of other technologies, each of which has their own particular set of bugs.

Before this particular incident, I sort of expected technology to work. Now I accept that there are going to be problems and that it’s probably impossible to find them all.

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?

A usability story

Almost 10 years ago, I was talking to a large media company about how to authenticate subscribers who had paid for digital content. Being focused on cryptography at the time, my idea was to use a USB token that held a digital certificate and the corresponding private key. The user experience was to be like this: when the token was present, a user could get the paid content but when the token wasn’t present they couldn’t. Behind the scenes, the token was going to authenticate to a content server using the its certificate and private key, but all of the cryptographic details were going to be hidden from the user.

The people from the media company thought that this sounded interesting and thought that this could even be the basis for a trendy and cool product. Teenagers might wear USB tokens as a fashion accessory to show that they were cool enough to be subscribers, for example. They would make lots of money. I would make lots of money. Everyone would be happy.

The media company then proceeded to do a usability study. They were planning on charging roughly $20 a month for the digital content, and by their estimation, a support call from a customer once every three to four months would make that particular customer unprofitable for them. Because of this, anything that they added to their system had to be extremely simple and easy to use.

The USB tokens failed miserably. Depending on how they asked them, between 25 and 50 percent of users could actually find the USB port on their computer. This made the solution that I had proposed very impractical, and the huge multi-million-dollar deal that I was dreaming of never materialized. My kids never got the Sony Aibo robotic dog I was planning on getting for them and I never got the the beach-front condo that I was hoping for, but I learned a bit about usability in the process.

Users have become more familiar with their USB ports in the past 10 years, and if you did a similar usability study today, the results would almost certainly be very different, but at the time, what I proposed turned out to be impractical. What new technologies are this way today – seemingly easy, but not quite easy enough for the average user? I would probably be as surprised at the answer today as I was 10 years ago.

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.

Google encrypts your Gmail - or does it ?

Lots of buzz around Google making your Gmail safer by making it easier to turn on encryption. Two things come to mind - firstly it's interesting how just by changing a simple default it's possible to increase overall security. Eliminating user clicks is critical in providing useable security - bravo Gmail team.

The second point is that simply securing the pipe between your computer and Gmail is not really enough to protect your most sensitive communication. Emails by definition travel all over the place, so if you really want to make sure you are protecting your email then you need to encrypt the email itself. No other way to do it. But of course the problem with email encryption solutions over the past 15 years has been that they are all too difficult to use - a few clicks too many for the ordinary user.

One easy to use approach that you may want to try is the Voltage Security Network, especially if you routinely send work documents home via gmail (or any other public email system) - take the free trial.