Superconductor

The limits of whole-disk encryption

There's an interesting post on Slashdot with the somewhat controversial title "Avoiding the PGP Whole Disk Encryption Craze." The original poster asks the Slashdot community for their views on the drawbacks or limitations that using PGP Whole Disk Encryption might cause. The replies seem to miss a few points, so I thought that I should mention them here.

First, there's the question about why people would ever encrypt the disks of a server. I've seen this done in at least a few cases, and the reason has always been to reduce theft of servers. In places where theft of servers is rampant, making stolen servers less useful to the thieves seems to reduce the number of servers stolen, and encrypting the disks seems to be a good way to do this.

Next, there's the question of the limits of encrypting laptops that seems to be overlooked. Encrypting laptops does a good job of protecting against some types of data breaches, but not all of them. If a laptop is lost or stolen, if its hard drive is encrypted, it's unlikely that the data on the laptop will be compromised. On the other hand, data on laptops gets compromised in ways other than by having the laptop getting lost or stolen. Data gets copied to USB drives or CDs, for example, and once it leaves the protection of the encrypted hard drive, it's unprotected. It's possible to work around this limitation of whole disk encryption in at least two ways.

The first way is to simply restrict the use of USB drives and CD drives. Some businesses do this today, but this isn't a perfect solution. At the recent ASC X9 meeting that I attended, we were routinely transferring documents back and forth with a USB drive, which left one unfortunate person unable to get the documents because his USB port was disabled due to security concerns. So there's definitely a price that's paid in lost productivity if that's the approach that's taken.

Another approach is to use a data-centric security model in which the data is encrypted and stays encrypted wherever it goes. If you do this, when you copy data from a hard drive onto a USB drive or CD, the data stays encrypted, so it's still protected if it's lost. Implementing data-centric security is probably more complex than other approaches because an application has to decide what data to encrypt and then actually do the encryption.

If you have a database of credit card numbers that you want to protect in this way, you need for some application to find the credit card numbers and to encrypt them. You also need to have applications be aware that the credit card numbers are stored encrypted, so that they can decrypt them when they're needed. This isn't necessarily hard, but it's certainly more complicated than just encrypting an entire column of a database or the entire hard drive of a laptop. It requires writing some code, but not very much. On the other hand, it's also much more effective at preventing data breaches. If data that's protected by data-centric security is transferred to another device, it's still encrypted, so that the loss or theft of that device won't compromise any sensitive data. Maybe that's the future of encryption.

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.   

Thoughts on passwords

"The password must be impossible to remember and never written down."

Richard E. Smith, Authentication: from Passwords to Public Keys

Passwords are an interesting technology. They're one of the few security technologies for which there currently no standard. The only attempt at such a standard was the Department of Defense Password Management Guideline (CSC-STD-002-85), which only  provides general guidance and hasn't been updated since 1985. They're also probably the clearest demonstration of the balancing act between security and usability: security administrators want users to use strong passwords, but users can't remember strong passwords, and there seems to be no way to keep both groups happy at the same time.

One of the more interesting studies of passwords is "A Large-Scale Study of Web Password Habits" by Dinei Florêncio and Cormac Herley of Microsoft Research. Florêncio and Herley looked at roughly 500,000 passwords over a three-month period and summarized their findings in this paper. Some of their findings include:

• The average user has 6.5 passwords which are shared across 3.9 web sites
• The average user has about 25 accounts that require passwords
• The average user types an average of about 8 passwords per day
• The average user chooses a password with about 40.54 bits of entropy
• About 4 percent of users forget their password over a three-month period

Of these findings, one looks a bit suspicious: the estimate of 40.54 bits of entropy for a typical password. That's based on just the space from which the characters comprising passwords are drawn. This means that it assumes that users will pick the letter 'q' as often as they pick the letter 'e.' This probably doesn't happen, so the actual entropy of passwords is probably much lower.

The estimate that 4 percent of users forget their password over a three-month quarter is also interesting. That means that about 15 percent of users forget a password over a one-year period. Let's assume that it takes 10 minutes of an administrator's time that's worth $50 per hour to do a reset. This means that the cost of resetting a password is probably roughly $1.25 per user per year, which is much less that the estimates the vendors of password-management products would have us believe.

Another study indicates that most users just use lower-case letters for their passwords and just make the first character upper case and append a number to the end if stronger passwords are required by their security policy. And if they have to change passwords regularly, they tend to just increment the number at the end of their password, turning "Password1" into "Password2," for example. So even passwords that are supposed to be somewhat strong often really aren't any stronger than weak passwords.

Passwords may not be one of the strongest means of authentication, but they're relatively inexpensive compared to the more secure alternatives and they seem to work well most of the time. This means that we'll probably be using them well into the future, much to the annoyance of security administrators who don't feel comfortable making the trade off between security and ease of use than passwords require.   

Dealing with risk

The uncertainly of events has two components: the likelihood of an event and the impact of an event. Likelihood is usually defined as a probability of an event occurring, while impact of an event is usually defined by the financial loss that accompanies an event. Multiplying the probability of an event by the loss that accompanies an event gives us a way to quantify the risk associated with an event. Risk is the amount that we expect to lose by a certain activity.

In a hypothetical example, suppose that the data on each of our laptop computers is worth $10,000 and the laptops themselves are worth $1,000, and that there is a 10 percent chance of a laptop being stolen in a one-year period, resulting in a loss of the data on the laptop as well as the laptop itself. This means that the risk from using laptops represents $1,100 of risk per laptop per year.

Once we understand the level of risk involved in using a particular technology, we need to decide how to manage this risk. We have four general ways to manage risks: avoidance, reduction, transfer, and acceptance.

If we decide to avoid a risk, we might simply refuse to use a technology that causes a risk. In our example of laptop computers, one way to deal with our hypothetical $1,100 of risk is to ban the use of all laptops in our organization and accept the implications of such a decision. In some cases, this may actually be the best way to deal with certain risks. In our hypothetical example, if we cannot demonstrate at least $1,100 of benefit from each laptop, this decision may be reasonable. In other cases it may not be feasible to avoid the risks associated with some technologies and we need to consider alternatives to avoidance.

If we decide to reduce a risk, we take an action to reduce either the likelihood or the impact of an event. In our example of laptop computers, we might be able to reduce the rate of laptop theft by investing in locks to make theft of the laptops more difficult. Or we could reduce the impact of having a laptop stolen, perhaps by deploying a full-disk encryption product, so that when we lose laptops to theft, the data on the laptops is not compromised. Because there is also loss associated with the physical loss of a stolen laptop, encryption does not eliminate the risks associated with using laptops, but only reduces it. Most investments in security technologies behave similarly, leaving some residual risk after they are implemented, and understanding the level of residual risk can be as important as understanding the original risk.

If we decide to transfer a risk, we get someone else to accept the risk, usually at a cost to us. Purchasing insurance is one way to do this, as is outsourcing the operation of a particular technology. Transferring risk often reduces the uncertainty of outcomes, but probably requires a cost roughly equal to the risk that we are transferring. So if we can purchase an insurance policy for $1,000 per year, this premium reflects the average loss that the insurance company expects its customers to experience. Losses above the average amount are reduced at the expense of increasing losses which would have been below the average amount, but we gain a level of predictability by doing this. In the terminology of statistics, we have slightly increased the mean of our loss but greatly decreased the variance of our loss.

The final way to address risks is by doing nothing, or by accepting a risk. In our example of the risk associated with the loss of laptops, if the cost of full-disk encryption products were much higher than they currently are, say $1,500 per laptop per year, then it would not be worth deploying the technology because the cost of reducing the impact of the risk would exceed the risk itself. In this case it would be reasonable to not encrypt the data on the laptops, and to just accept the risk associated with losing the laptops that we expect to lose. Many organizations are dealing with many risks in this way without fully understanding the implications of their actions; doing nothing is certainly the default way to manage risks, but it may not always be the best way.

Learning from the Marines

Information security concerns managing the risks that come with using IT systems. Actually, it's probably even vaguer than that. There is so little known about some security vulnerabilities, that information security is probably closer to managing uncertainty than managing risk. Because of this, we may be able to find useful insights that are relevant to information security in research that has been done on how people make decisions under uncertainty. In particular, a study by the United States Marine Corps may give some insight into how we can expect some decisions to be made by security managers. One USMC publication describes the uncertainty that Marines face in the following way:

"While we try to reduce these unknowns by gathering information, we must realize that we cannot eliminate them. The very nature of war makes absolute certainty impossible; all actions in war will be based on incomplete, inaccurate, or even contradictory information."

If you replace "war" with "business," this statement is still accurate, so it seems general enough to be applied to more than just the USMC. But while all businesses face uncertainties, those faced by information security managers are probably greater that those faced by many other managers, and some of the research that the USMC has done about decision-making under uncertainty may be particularly useful for providing insights that information security managers can use.

One interesting report is Tactical Decision-Making Under Uncertainty: Experiments I and II, which describes the results of experiments that looked as the ability of leaders to make decisions in a Combat Operations Center under varying levels of uncertainty. One interesting result was that although both inexperienced leaders and experienced leaders made decisions just as quickly, the less experienced leaders chose the "wait and see" option more often than their more experienced counterparts did. Choosing to wait for the situation to develop can lead to problems, so it’s probably reasonable to summarize this finding as experienced leaders make better decisions than inexperienced ones.

The unusual finding in this USMC study is that experience that helped leaders make better decisions was not general experience, but rather experience doing a particular job. So while years of service or rank didn't help reduce the tendency to wait and see, experience in a COC did. The performance of leaders with more COC experience was also not affected as the uncertainty that they were exposed to increased.

If we try to generalize the conclusions of this USMC study, it seems that there may be no substitute for relevant experience, not just experience. So we might expect information security managers with more experience in information security organizations to make better decisions that their less-experienced counterparts, even those with more experience managing other types of organizations. This study also seems to question the assumption that a competent manager can manage any organization. It may be the case that direct experience instead of general experience is actually more important. Even though the fact that managers are fairly generic seems to be widely believed, I don’t recall seeing any evidence that supports this claim.

How not to manage keys

Iñigo Montoya: "You keep using that word. I do not think it means what you think it means."

The Princess Bride (movie version only - it's not in the book)

Key management is a hot topic these days. The need to be regulatory compliant has driven the adoption of encryption, and with the use of encryption has come the need to manage the cryptographic keys that are used to encrypt and decrypt data. Encryption has always been a fairly arcane subject, but it's apparently even more difficult than you might first think. Maybe it's just more difficult that I might first think, but I probably have a fairly biased point of view from having worked in the information security industry for roughly 20 years.

I recently talked to a person who works for a large bank who was having a hard time getting upper management to understand some of the issues related to key management. In particular, this particular bank had decided that they needed to store their digital certificates in a very secure location. Why? Because a certificate contains a public KEY, so it needs to be protected just like any other key does. The argument from the security person that a certificate actually contains a PUBLIC key apparently fell on deaf ears, so now this particular bank is now keeping their certificates really secure.

I have to wonder if the troublesome management could be swayed by the argument that the LDAP server storing the certificates is actually secure enough because it's behind a locked door. Maybe I'll mention that possible strategy the next time I get a chance.

Specifying secure code

A look at the National Vulnerability Database might lead you to believe that writing secure software is almost impossible; security flaws for almost every popular application appear in the NVD. Part of the reason that secure software is hard may be due to the way that specifications are written and the way that computer science classes are taught today.

Many of the worst security vulnerabilities that software has are due to the way an adversary can take advantage of careless processing of user-supplied data. Buffer overflows, SQL injection and cross-site scripting are all examples of attacks that are easily prevented if user-provided data is carefully checked for validity. These attacks all work by taking advantage of how invalid data is handled.

If an application carefully checks data for validity then these attacks can be avoided, and it may be possible to write specifications that require this. The problem is that most specifications aren't written with this in mind. The way in which algorithms and data structures are typically taught today seems to reinforce this.

It's common for computer science students to see proofs of the correctness of algorithms. These proofs typically show something like "given a particular input, this algorithm produces the correct output." What's typically not discussed is the case where unexpected inputs are provided. So an algorithm that processes a character string assumes that it's provided a valid and well-formed character string, for example. Algorithms designed under this assumption may be vulnerable to out-of-range or unexpected input, because what happens in these cases is totally undefined in their specification.

So one way to avoid vulnerabilities that are based on unexpected input might be to define the specification of the software more carefully. Instead of "given a particular input, this algorithm produced the correct output," such a specification might be extended to "given a particular input, this algorithm produces the correct output and raises an error condition if other input is provided." This may be fairly tricky to do, but it may also provide a way to eliminate most of the exploitable security flaws that software now has.

Different points of view

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

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

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

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

The standards balancing act

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

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

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

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

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

Moore or less

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

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

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

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

How common is encryption?

Protect information, not just systems - that's one of the big lessons that's mentioned in the 2008 edition of The Global State of Information Security, an annual study that's done by PricewaterhouseCoopers along with CIO and CSO magazines. There are lots of ways to protect information, but encryption is probably the most effective. Data from the PricewaterhouseCoopers report that estimates how many companies use various types of encryption is shown below.

So 55 percent of businesses encrypt their databases, 50 percent encrypt their laptops, and 47 percent encrypt backup tapes, and each of these estimates increased significantly compared to where they were the previous year.

It's not surprising that most business encrypt their databases. Most database software has the option to encrypt that's fairly easy to enable, and it's actually surprising to see that 45 percent don't encrypt databases.

The fact that only half of businesses encrypt laptops, however, is a bit surprising. Analysts estimate that there's roughly a 10 percent chance of any laptop being lost and roughly a 20 percent chance of one being lost or misplaced, and all of these laptops probably contain lots of sensitive information.

Perhaps even more surprising is the fact that only 47 percent encrypt backup tapes. There's more information on a single backup tape than a hacker can get from years of eavesdropping, so backup tapes make one the best targets of all. It may be the case that people worry about problems with key management that could turn the encryption of backup tapes into the cryptographic shredding of the tapes, losing the data forever. That's certainly possible. Key management technology isn't as good as it could be. It's too bad that the PricewaterhouseCoopers survey didn't ask why people do or don't encrypt their data. That would be very interesting to learn.

Why elliptic curves are good

It's commonly thought that elliptic curve cryptography is "more secure" than some alternatives. This may be true from a certain point of view, but probably not for the reason that most people probably first guess.

In a previous post, we talked about how the security of the Diffie-Hellman key exchange is based on the computational Diffie-Hellman problem (CDHP). We can summarize the CDHP like this:

CDHP: Given g, g^a, g^b, find g^ab

If it's hard to solve the CDHP then it's hard for an adversary to find a Diffie-Hellman shared secret from what he can observe in a Diffie-Hellman key exchange. In some cases, we’d like to make it even more difficult for an adversary. In some cases, we’d like to make it so that it's even hard for him to guess a shared secret and check if it's right or not. (The checking is the part that's hard - not the guessing.) This can be summarized in what’s called the decision Diffie-Hellman problem (DDHP):

DDHP: Given g, g^a, g^b, g^c determine whether or not g^c = g^ab

Note that if you can solve the CDHP then you can solve the DDHP. If you can find g^ab by solving the CDHP, you just check to see if it's equal g^c. But if you can solve the DDHP that doesn't mean that you can solve the CDHP.

If the DDHP is hard, things are even more difficult for an attacker. He can't even guess a solution to the CDHP and check to see if it's right. So if the DDHP is hard, then it's hard to tell g^ab from a random value. This is a nice property to have, but it turns out that the CDHP is actually easy in the usual setting for the Diffie-Hellman key exchange.

The Diffie-Hellman key exchange is usually done using multiplication of integers modulo some large prime number. In this setting, the DDHP is actually easy to solve, which means that g^ab doesn't really look random.

On the other hand, suppose that we replace multiplying integers modulo a large prime number by adding points on an elliptic curve. In this case we can create a scheme just the Diffie-Hellman key exchange that works like this:

1. Alice picks a point P and uses her private key a to calculate aP, which she sends to Bob along with P
2. Bob uses his private key b to calculate bP, which he sends to Alice
3. Alice calculates the shared secret abP as a(bP)
4. Bob calculates the shared secret abP as b(aP)

This is called elliptic-curve Diffie-Hellman (ECDH). The name's different, but the idea is really the same as the integer version of Diffie-Hellman. On the other hand, it turns out that the DDHP is hard when you're working with points on an elliptic curve. This means that using elliptic curves offers an additional bit of protection that doing operations in the integers doesn't. Using elliptic curves, it’s even hard for an adversary to guess an ECDH shared secret and check to see if it solves the CDHP, which is written this way when we're working with points on an elliptic curve:

CDHP: Given P, aP, bP, find abP

So there’s probably a good reason for claiming that elliptic curve cryptography is more secure that some alternatives, but the reason isn’t what most people probably think of. It's fairly well known that elliptic curve cryptography lets you use a shorter key that other public key technologies and still attain the same level of security. It only takes 160 bits of elliptic curve key is roughly equal to 1,024 bits of Diffie-Hellman, for example. But that's not really a basis for claiming that the elliptic curve alternative is more secure.

If the security attained by a fixed number of bits was a useful metric for security, then we'd be justified in claiming that all public-key algorithms are less secure than symmetric algorithms. It only takes 80 bits of symmetric key to provide the same security as 160 bits of elliptic curve key, for example.

So a good reason for claiming that elliptic curves are more secure than some alternatives is because they create a setting where the DDHP is hard while some alternatives create a setting where the DDHP is easy.

Security Consultants vs. Simple Products

People want products that are easy to use. Whether the product is a DVD player, software game, or theater ticket, people want to know what to do once the money has exchanged hands.

Is that wise with security products? What if the product is so difficult to use, the customer has to hire an expert or consultant to get it up and running? Then the cusomer will probably not make any mistakes. Oh the consultant might make some mistakes, but the customer won't, and the expert is less likely to make a mistake.

I was once working for a company that sold crypto software. This software included an implementation of the RSA algorithm. A customer called complaining that the ciphertext was the same as the plaintext. We discovered that he had used 1 as the public exponent.

Maybe if the software had been so difiicult to use, he would have hired someone who would have known that 1 is a bad key. By the way, we can laugh at that mistake, but really, if you aren't that familiar with the algorithm, and just want to use a test key that will be faster than the production key, is it really that bad of a mistake?

What other security products are there that can be misused? A hardware module? An anti-virus package? What if you don't use it properly? Will you be more vulnerable than if you had done nothing?

Maybe security products should be so easy to use it's impossible to make a mistake, or so hard only the experts can use them. Or maybe the alternative would be to make products easy to use, but give the user information on how to use it properly.

Which solution is likely to produce good security?

Diffie-Hellman and discrete logs

The security of the Diffie-Hellman key exchange is related to the difficulty of calculating discrete logarithms, but a closer look at the problems shows that it's actually a bit more subtle than you might first think.

We can describe the Diffie-Hellman key exchange roughly like this:

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

So an adversary who sees Alice and Bob carry out these steps sees g, g^a and g^b. From this information, the adversary wants to find the shared secret g^ab. We can summarize this in what's called the computational Diffie-Hellman problem (CDHP):

CDHP: Given g, g^a, g^b, find g^ab

We assume that the only way that an adversary can do this is by calculating discrete logarithms. In particular, we assume that they either need to find the value of a from g^a and then use it to calculate g^ab, or to find the value of b from g^b and then use it to calculate g^ab. There's no proof that this is actually the case, although it’s probably true. This means that there may be ways to defeat the security of the Diffie-Hellman key exchange that don't require calculating discrete logarithms. But if you can calculate discrete logarithms then you can clearly solve the CDHP.

So the security of the Diffie-Hellman key exchange is really based on two assumptions. The first is that the only way to solve the CDHP is by calculating discrete logarithms. The second is that calculating discrete logarithms is hard. So although people often talk about the security of the Diffie-Hellman key exchange as being based on the difficulty of calculating discrete logarithms, it's actually a bit more complicated than that. It's really based on the difficulty of solving the CDHP.

Unexpected costs

PKI is an interesting technology that has received its share of bad press. These negative comments have typically focused on the problems that most implementations of PKI have – they tend to be expensive and too hard for average users. What's often not considered is the fact that not many applications can use the digital certificates that PKI creates and manages. This means that after you spend a fair amount of money deploying your PKI, you'll find that you can't do much with your certificates except encrypt and sign e-mail or authenticate to a web server. Just those two uses probably doesn't justify the cost of deploying and supporting a PKI. Most applications don't support PKI and modifying them so that they do can be expensive, perhaps even very expensive.

I recently gave a talk about some innovative applications of cryptography in the entertainment industry. In this talk I mentioned that I'd heard that the Department of Defense has requested $5 billion to PKI-enable their core mission-critical applications. It turned out that a person in the audience was involved in that budgeting exercise and she told me that this estimate was way off.

It seems that the estimate of $5 billion came from a call which polled various departments about their needs and how much it would take to PKI-enable their most important applications. According to the person at my talk, most of the people on this call had no idea what PKI was or why they'd need budget to PKI-enable their applications. So when they were asked how much they needed, they said that they needed nothing. This means that the $5 billion number probably grossly underestimates the actual costs. Because of this, a more realistic estimate for the cost of PKI-enabling the DoD's applications might be more like $10-20 billion.

Ouch.

A simple misunderstanding

A while back a heated discussion started on a mailing list that I subscribe to. This particular list is for the discussion related a certain security standard, and the cost of using PKI was the topic that seemed to get peoples' interest.

The opponents of PKI pointed out that it's typically very expensive and too hard for the average user to use. There are certainly real-world statistics to back up these claims. According to a report by the GAO , the average cost of PKI in the US federal government has been a bit over $220 per certificate. Another analyst report estimates that the TCO of a secure e-mail solution based on PKI is over $800 per user per year. I don't recall any compelling arguments from the proponents of PKI. Instead, they focused on the need for some way to verify the origin of e-mail and to protect it from eavesdropping. I don't recall any claims that PKI was the best way to do this, but just that it's a way that's available now.

I usually try to stay out of heated discussions on the Internet, but this time I couldn't help adding a comment that didn’t really add anything useful to the discussion. I did this by mentioning that if PKI is really as expensive as the GAO report would have us believe, then in many cases there’s probably a cheaper alternative. I proposed that you could use your FedEx account number as a way for people to be able to securely get information to you, so that it would more or less be acting like a public key. Using FedEx isn't cryptographically secure, but it's probably good enough for most uses. In cases where you're not sending too many documents, this has a good chance of being cheaper that using PKI-based e-mail. This wasn't meant to be taken seriously, of course.

Like many other comments via e-mail that aren't meant to be taken seriously, this one was misunderstood. The first reply to it asked if I was suggesting that a FedEx account number could be used as a user's identity in some sort of identity-based encryption scheme. So I was stuck explaining that I wasn't being serious and that my comment wasn't meant to be taken literally. Identity-based encryption may be very useful in some applications, but this probably isn't one of them.

Going the way of Pluto?

In August 2006, astronomers at the meeting of the International Astronomical Union in Prague voted to adopt a new definition of the term "planet" that reduced the number of planets in the solar system to eight. Pluto was reclassified as a "dwarf planet," much to the dismay of many astronomers and much of the general public. The trend of "convergence," in which information security becomes integrated into corporate risk management organizations, may soon result in a similar type of reclassification of the discipline.

There are valid scientific reasons to support the new definition of a planet. Pluto is more similar to the icy bodies that form the Kuiper belt, the large disk-shaped region past Neptune that is home to many such objects, than to the other planets. Many people, however, find this distinction somewhat arbitrary, and have argued that Pluto should remain a planet. Some have even started a campaign to have its place as one of the nine planets restored. Only time will tell whether or not they are successful.

There have two main reasons advanced for reclassifying Pluto as a planet again: nostalgia and politics. The argument based on nostalgia is essentially that everyone knows that Pluto is a planet, so it should remain a planet. Six billion people cannot be wrong, can they?

The argument based on politics is essentially that it is easier for scientists to get funding for research on planets than on dwarf planets, trans-Neptunian objects or Plutonian objects, other terms for bodies that do not qualify as being planets in some way. It is no secret that there are lots of small, icy bodies in the Kuiper belt, making it hard to justify funding for research that tries to find more of them. Any why would NASA spend $675 million on the New Horizons spacecraft if it is just going to visit one of these many icy rocks? On the other hand, the goal of finding another planet sounds much more important and worth of funding.

The field of information security may be due for a similar reclassification soon, as the trend towards combining information security and other risk management operations moves information security away from its roots in information technology and into the business world. The reasons for justifying the merging of security organizations seems to make sense from the business point of view, but not everyone agrees that such a change is the right thing to do. The arguments against doing this are eerily similar to the arguments for keeping Pluto classified as a planet.

One obvious argument against merging security organizations can be summarized as nostalgia, or the fact that information security practitioners have grown accustomed to not having to justify investments in information security technologies like others might have to do in their business. This has even been institutionalized in using different metrics to justify investments.

The return on security investment (ROSI) concept seems to have been created to overcome the obstacles that information security practitioners face because it is often difficult to justify investments in information security by using the conventional ROI metric. Some industry analysts have even argued that information security should be exempt from traditional risk analysis and management methodologies because the traditional methodologies do not work well in information security. Such special treatment might disappear if information security merges with other risk management disciplines.

Another argument against merging information security into a business-wide risk management organization can be summarized as politics. Many information security organizations now have the attention of upper management due to the recent increased focus on regulatory compliance. If information security becomes part of a corporate-wide risk management organization, the political influence that comes with the attention of upper management maybe reduced. If such convergence happens, many information security investments will probably be questioned if they competing for funding with other risk management projects. Can you really justify the TCO of PKI-based encrypted e-mail if the same investment can be used to reduce slips, trips and falls?

The business forces that are pushing for the convergence of information security and other risk management functions seem to be fairly strong, which may lead to the eventual disappearance of information security as a separate discipline. For many information security professionals, it seems that understanding the business where they work has already become as important as understanding information security technology. As the trend of convergence continues, understanding the business aspects of their jobs will probably become even more important. And unlike the possibility that exists of reinstating Pluto as a planet, there seems to be little chance for this trend to be reversed. So information security professionals should note the trend of convergence and try to understand what it can mean for them in the future.

The Hand rule

The Hand rule is a principle that everyone working in the field of information security should know about. It's an example of a balancing test. In such tests, courts try to make outcomes depend on a reasonable balance between competing interests.

The Hand rule can be traced back to the 1947 ruling in the case United States v. Carroll Towing Co., in which judge Learned Hand ruled that determining liability depends on comparing the cost of preventing an accident to the expected loss from an accident. Here's what Hand actually said:

"Possibly it serves to bring this notion into relief to state it in algebraic terms: if the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B < PL."

This means that if it costs $2,000 to prevent an average loss of $1,000, you're not negligent if you don't spend the $2,000. Hand's ruling has been extensively studied by economists and game theorists, who seem to love finding pathological cases where the general principle can end up causing unexpected outcomes. An example of this can be found here.

The Hand rule is a good general principle to know and understand, but it can be difficult to apply to the decisions that information security managers need to make because the data that's needed often isn't available. In most cases, neither the probability of security incidents happening nor the damages that result from an incident are known very well.

Consider the simple case of a web server. Almost all software has some sort of security vulnerability. Some just haven't been discovered yet. In such a situation, what's the probability of your web server being hacked? And if it is hacked, how do you put a dollar value on the damage that's caused? Because it's hard to answer questions like these accurately, it's hard to apply the Hand rule in a meaningful way. So although the Hand rule is often used in other risk management disciplines, it's typically not very useful in information security.

Software liability is a bad idea

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

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

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

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

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

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

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

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

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

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

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

The real insider threat

Despite what you may have heard, the insider threat is probably not the greatest threat to your organization. The most detailed study of the insider threat is probably the one performed at Carnegie Mellon University at the CERT Coordination Center. In 2002, the Insider Threat Study was started jointly by CERT and the U.S. Secret Service National Threat Assessment Center, the goal of which was a careful and systematic study of insider threats. One source of the data that this joint operation uses is the annual E-Crime Watch Survey.

Since 2004, the E-Crime Watch Survey has been jointly run by CERT, the U.S. Secret Service and CSO Magazine, and it provides a good summary of the state of information security threats. The results of this survey concerning the relative frequency of insider and outsider attacks are shown below in Figure 1. Note that in the years 2004 and 2005, survey participants were not given the choice to indicate that they did not know the source of attacks on their networks. It appears that the incidents that were later classified as coming from an unknown source may have actually been earlier classified as coming from outsiders, but there's no way to be sure.

Figure 1: Data from the E-Crime Watch Survey from 2004 through 2007.

Other studies have found similar results. The 2007 CSI Computer Crime and Security Survey is the latest in a series of 12 annual studies of the state of information security. In each of the years that this study has been conducted, it has never found the insider threat to be greater that the outsider threat, and the 2007 report even comments on this:

"A great deal is made of the insider threat, particularly by vendors selling solutions to stop insider security infractions. It's certainly true that some insiders are particularly well-placed to do enormous damage to an organization, but this survey's respondents seem to indicate that talk of the prevalence of insider criminals may be overblown."

It's unlikely that the mistaken belief that insider attacks are more numerous than those from outside will disappear any time soon. But it might make sense to not base your purchasing decisions on one of the legends of information security that refuses to die. There are certainly some cases where the risk from insider attacks is so serious that it justifies either technology or other controls to limit the exposure to damage from it. These cases are probably the exception rather than the rule. In most cases there are probably better uses for your security budget.

Overheard in passing

You know that you talk to too many cryptographers when you hear things like this:

"Opinions are like free 60-day VeriSign Class 1 certificates - everybody has one."

A smoking gun?

In a previous post we mentioned how risk-risk trade-offs can make it tricky to measure the overall cost of trying to manage a risk. In some cases, the measures taken to reduce a risk actually cause more damage than they eliminate, making them cause a net loss rather than a net gain. Requiring drivers to wear seat belts in cars is probably a good example of this. Studies have suggested that people feel safer while wearing a seat belt and compensate by driving less carefully than they would otherwise and that this riskier driving actually kills more people than the seat belts save. In the face of complications like this, it's extremely difficult to create an effective risk-management program.

Another problem can be caused by the fact that it can be hard to accurately measure the total costs in many situations because unexpected benefits can sometimes accompany the costs. The recent legal battles between the American states and tobacco companies provide an example of this.

The basis for the multi-billion-dollar settlement between the states and the tobacco companies was the notion that the tobacco companies are causing the states to experience higher costs, and that the tobacco companies should compensate the states for these costs. A closer look at this situation, however, shows that the tobacco companies really aren't causing any net additional costs for the states at all. They're actually decreasing the states' costs.

Studies estimate that states incur medical costs associated with smoking cigarettes of roughly $0.58 per pack. There are also other costs like about $0.43 per pack in foregone taxes because of smokers dying early, higher life insurance costs of about $0.14 per pack, the cost of additional sick leave taken by smokers of about $0.02 per pack fires and the cost of fires caused by cigarettes of about $0.01 per pack. These add up to about $1.18 per pack of cigarettes.

On the other hand, the fact that smokers tend to die before non-smokers mean that they also tend to not be around to cause some costs. In particular, the lower retirement pension costs amount to about $1.26 per pack and the lower cost of nursing home care to about $0.24 per pack. This means that there’s a benefit to the states of about $1.50 per pack that's caused by smokers dying earlier than non-smokers. This means that there's actually a net benefit of $0.32 per pack of cigarettes to the states. So although there are very good reasons to reduce smoking, the costs that the states incur from smokers probably isn't one of them.

Is information security exempt from this particular problem? It's hard to imagine a case where the damage caused by being hacked is outweighed by the benefits that the hacking might bring. On the other hand, there are certainly security technologies that probably aren't worth their cost.

Trust, but verify

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

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

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

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

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

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

Source: <vague reference to some obscure academic paper>

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

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

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

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

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

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

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

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

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

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

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

NRS 597.970

We've have seen more than 39 states adopt data breach disclosure laws since California Senate Bill 1386, these laws help with cleaning up the mess left behind by a breach. Now, however we are starting to see the first laws trying to address the problem of preventing the breach from happening in the first place. The first state to do this is Nevada with Massachusetts, Washington and Michigan to follow shortly. These laws mandate the use of encryption to prevent sensitive customer information from being compromised when that information is transmitted out of the business.

Nevada Revised Statue (NRS) 597.970, which is effective October 1, 2008.

NRS 597.970 Restrictions on transfer of personal information through electronic transmission.

1. A business in this State shall not transfer any personal information of a customer through an electronic transmission other than a facsimile to a person outside of the secure system of the business unless the business uses encryption to ensure the security of electronic transmission.

2. As used in this section:

(a) "Encryption" has the meaning ascribed to it in NRS 205.4742.

(b) "Personal information" has the meaning ascribed to it in NRS 603A.040.

This certainly looks like it requires encryption, but a closer look at the law also shows that there's no penalty for breaking it.

NRS 597.100 Criminal penalty. A person who willfully and intentionally violates any provision of NRS 597.010 to 597.090, inclusive, is guilty of a misdemeanor.

However, this law opens up businesses to law suits and in combination with the prevailing data breach disclosure law, having encryption will limit a businesses liability in the event of a data breach. So adding some low cost encryption software seems like a small price to pay for protecting your customer and employee data from being exposed after all.

Nevada businesses - take a look at www.voltage.com/nevada

UPDATE: From the WSJ - October 16th, 2008

"In Nevada, companies that suffer a security breach but comply with the new law would cap their damages at $1,000 per customer for each occurrence. Those that don't comply would be subject to unlimited civil penalties under the proposed enforcement plan, said James Earl, executive director of the state's task force for technological crimes."

Another look at availability

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

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

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

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

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

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