Superconductor

Key management in PCI DSS 1.2

The Payment Card Industry Data Security Standard (PCI DSS) version 1.2 came out in October 1, 2008. It has a few changes from the earlier 1.1 version, but one of them seemed worth of mentioning. This particular change is actually in the glossary, where "strong cryptography" is defined.

Here's how "strong cryptography" is defined in PCI DSS v1.1:

General term to indicate cryptography that is extremely resilient to cryptanalysis. That is, given the cryptographic method (algorithm or protocol), the cryptographic key or protected data is not exposed. The strength relies on the cryptographic key used. Effective size of the key should meet the minimum key size of comparable strengths recommendations. One reference for minimum comparable strength notion is NIST Special Publication 800-57, August, 2005 (http://csrc.nist.gov/publications/) or others that meet the following minimum comparable key bit security:

• 80 bits for secret key based systems (for example TDES)

• 1024 bits modulus for public key algorithms based on the factorization (for example, RSA)

• 1024 bits for the discrete logarithm (for example, Diffie-Hellman) with a minimum 160 bits size of a large subgroup (for example, DSA)

• 160 bits for elliptic curve cryptography (for example, ECDSA)

Here's how "strong cryptography" is defined in PCI DSS v1.2;

Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). SHA-1 is an example of an industry-tested and accepted hashing algorithm. Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher).

See NIST Special Publication 800-57 (http://csrc.nist.gov/publications/) for more information.

It's interesting to see that proper key management practices are now part of the definition. I have to wonder why this was added. It might have been an oversight in the earlier version. It's easy to overlook things when you're writing, and the people who wrote the earlier versions of the PCI DSS might have just forgotten to include it.

It might be part of a conscious effort to gradually make the PCI DSS more and more stringent with each version. That might be the PCI Security Standards Council's way of getting the payment card industry to continue to improve over time.

A third possibility is that it's in reaction to merchants or banks that tried to be minimally compliant with PCI DSS v1.1 by using encryption but having sloppy key management practices. Sound key management can be expensive, so it's certainly possible that people tried to do this. I've seen it happen on more than one occasion myself. It's hard to say what the exact reason for this change was, but I'd bet on the last reason: that people tried to be minimally compliant with PCI DSS and ended up with solutions that really didn't provide any additional security but managed to technically comply with the standard.

Security Errors in Code, Part 3

In Part 1 I said one of the main reasons the "Top 25 Most Dangerous Programming Errors" exist is lazy programming. In Part 2 I gave the following as an example.

void DisplayMsg (char *domain, char *file) {
  char *b, *p = "Processing  from ";
  int d = strlen (domain);
  int f = strlen (file);
  int l = strlen (p);

  b = malloc (d + f + l + 1);
  memcpy (b, p, 11);
  memcpy (b + 11, file, f);
  memcpy (b + 11 + f, p + 11, 6);
  memcpy (b + 17 + f, domain, d + 1);

  DisplayString (b);
}

I pointed out that not checking whether the malloc succeeded or not was an example of lazy programming. But I said there were more examples in that code. Here they are.

1. The function name. "DisplayMsg" could mean a lot of things, but this routine really displays a specific type of message built from a domain and file name. A better name would be "DisplayMsgFromDomainFile". "But," the lazy programmer exclaims, "that's a lot to type. I can code faster if I have less to type." Right, and how much typing you do is more important than good code. Other people will have to use and maintain this code, the more descriptive you are, the easier it is.

2. Single-character variable names. In Java, longer variable names increase code size, but not in C, so there's no reason to use single-character variable names. Besides, in Java, there are obfuscators that will convert descriptive variable names to single characters to reduce code size. In fact, think of it this way, if you use single-character variable names, you are, by definition, writing obfuscated code. In the above example, the single-character variables are not that bad, but lazy here means lazy elsewhere. Single-character variable names are harder to search for and it's harder for someone to know what they mean. And look at the variable lower-case L, is that a one or an ell?

3. No free. The buffer is allocated but never freed.

4. No comments. There's no description of what this function does, nothing about the arguments (is domain allowed to be NULL?). Although this is a simple routine, it will still take someone reading this a couple minutes to figure out if this routine does what they want it to do and how to use it. Comments would be easier to follow.

Documentation is important in code. People using your code and people updating and maintaining your code will need to know what the function is supposed to do. Descriptive function and variable names are part of documentation. Comments are part as well.

I have heard programmers declare that their code is so well-written, they don't need comments. Well, if you use descriptive function and variable names, that might be true to some extent. But suppose you're writing a multi-precision Montgomery multiply routine. We can know that's what the function does, but in the code itself, you do a shift, why? There's a 32-bit value called n0, what is that?

"If anyone is reading this code, they must know Montgomery multiplication first, they shouldn't have to learn it by reading this code." True, but what part of MontMul is a particular part of the code doing? Is that shift by 2 really a divide by 4 or a shift for some other reason? If there's a bug in the code, debugging will be made so much easier if there are comments.

Personally, I think it's bad to say that if you want to know what a function does, read the source code. There really are people who say that, usually in the O---l community. The problem is that there can be so many functions it would take forever to go through a .h file, look at a semi-descriptive name and then look at the source code for that routine (which contains single character variable names and calls other subroutines, so now I'll have to understand those functions to understand the one I'm investigating).

Programmers sometimes say, "I'll put the comments in later." Maybe that has happened but I have never seen it. I have actually put comments into other people's code after the fact, but I've never seen an original programmer do that. I have only seen programmers who put the comments in while coding, or never put them in.

I once worked with a guy who couldn't get his own code to work because he couldn't remember how to use it. He wrote the code 3 months prior, but he still couldn't remember which function to call in which order with which arguments. Looking at the source code did no good. He liked to use nondescriptive function names and single character variable names. I think the only comments he ever put into code was the copyright notice. And work he did three months ago was lost. The company paid him to do something and it was a waste of money. That's why your code needs to be well-written, easy to follow, and documented.

Lazy programmers say that so long as the code gets the right answer, that's all that matters. But you can have code that gets the right answer but has security flaws and is unmaintainable.

Craft your code so that it looks good, is not just correct. Write a description of what a subroutine does (every subroutine, not just the "important" ones), and what the arguments are before you even write the code. Comment the code as you write. Everyone says they know they should and sometimes they do, but so many never follow through. If you're too lazy to write function descriptions or comments, get out of the business.

Here's an analogy. Part of the grocery store clerk's job is to handle the coupons, either scan them or manually make the appropriate deductions. Any clerk who says, "Yeah, I should, but sometimes I don't so things move faster," is not doing their job. You wouldn't say, "It's up to the discretion of the clerk to decide if the customers' coupons are to be accepted. If they don't feel like it, then oh well." No, it's part of the job.

Making sure your code is documented right from the start, making sure your code is easy to read, making sure your code is completely correct (not just "it completes the task") is part of your job. If you don't do those things, you're not doing your job. If you don't want to do it, find another job.

The need for persistent encryption

The recent data breach at credit card processor Heartland Payment Systems may be the biggest ever, and it happened even though Heartland passed the PCI DSS security audit that credit card companies require. Heartland fell victim to a well-organized attack by cyber-criminals. These are adversaries that are part of the huge underground economy that obtains sensitive information and sells it for a profit. They're both determined and well funded.

It certainly looks like traditional security mechanisms aren't able to defeat such attackers. New approaches are needed, and the businesses that handle sensitive information that's valuable to cyber-criminals need to ensure that security vendors develop technologies and products that meet their needs. This isn't happening yet.

Encryption is probably the best way to protect against data breaches. If a cyber-criminal manages to get encrypted data but not the key used to encrypt it, the data is useless to him. If this is the case, then cyber-criminals won't be able to run profitable businesses that steal and resell sensitive information, and they'll have to look for another line of work. Unfortunately, the encryption products that are commonly used today don't provide enough protection for data. They provide good protection for it in some situations, but not in all situations.

In many cases, sensitive information was encrypted while it was stored in a database, but it loses this protection when it leaves the database. That can leave the door open to an attack that can compromise millions of credit card numbers. Almost all uses of encryption work similarly, providing protection in some situations but not others. This means that they don't stop cyber-criminals. Instead, they just limit the number of places where they can carry out their attacks. As long as there is a single place where the data is vulnerable, cyber-criminals will find it and exploit it.

Persistent encryption: protection by default

The best way to stop cyber-criminals is probably to encrypt data in a way that the data always stays encrypted until it's needed by business logic. You might call this "persistent encryption," or "protection be default," and it's a fundamentally different approach to information security than what's used today.

In today's IT environments, data is only encrypted if an application explicitly encrypts it. If no application encrypts data, it's in the clear where it's vulnerable. You might say that data is unprotected by default.

An alternative to this model is to have all sensitive data encrypted, and to only decrypt the data when it's needed by authorized business logic. You might say that data is protected by default in this situation. If data is protected by default with persistent encryption, then it's much tougher for cyber-criminals to get it. No matter where they manage to collect the data, it's going to be encrypted, and there's now no place at all where the data is vulnerable.

If you're using persistent encryption, you can copy sensitive data to your laptop and not worry about it being compromised if your laptop is lost or stolen. You can also copy the sensitive data to a USB drive or CD-ROM and not worry about the data being compromised if the drive or disk is lost or stolen. In each of these cases, because there's no authorized business logic that's decrypting the data, the data stays encrypted. This means that it's useless to an unauthorized user who might get it, either by accident or other means. Persistent encryption keeps it safe all the time.

Unfortunately, security vendors have been slow to create products that provide persistent encryption. This means that it's up to their customers to demand it. Software vendors finally took security vulnerabilities in their products seriously when their customers demanded security audits of their products as a condition of buying them. The result of this has been software that isn't vulnerable to some attacks that were once common. It seems likely that security vendors will be similarly reluctant to develop the tools that let enterprises implement persistent encryption. If you could benefit from this technology, let your security vendors know, and the rest will probably take care of itself.

Was Scott McNealy right?

"You have zero privacy anyway. Get over it."

Scott McNealy

Scott McNealy made his famous comment about privacy in the digital age at an event launching Sun Microsystems's Jini technology back in January 25, 1999. His comment immediately drew angry comments from privacy advocates. Some claimed that they were "astonished" that he could say that we don’t have privacy any more. Others called his comment "irresponsible." It's probably more telling, however, that nobody actually said that he was wrong. Perhaps they knew better. Today is Data Privacy Day, so it might be a good day to think about this.

Privacy may be an admirable goal, but it's not clear that people really want it. People claim that they want privacy, but their behavior doesn't always support this claim. People may say that they want to keep their shopping habits private, but will shop at on-line retailers that keep a record every click of the mouse they make and every web page they view.

On the bright side, it's not clear that the companies who get our private information actually do much with it. On-line giant Amazon.com has been logging everything that I do on their web site for several years now, and still feels compelled to recommend things that aren't even remotely related to anything that I've ever bought from them or would ever consider buying from them. Sometimes their recommendations can almost be entertaining. Almost all of what I've bought from Amazon.com over the past several years has been books, electronics or software. Despite this history, they still feel the need to recommend that I look at women's underwear on a fairly regular basis, and the fact that they continue to recommend it after I still haven't looked at or purchased any of the underwear that they've recommended makes me wonder exactly how well they're using all of that data that they've collected.

The real and serious threat to privacy is probably from the underground economy of cyber-criminals who steal huge amounts of personal information and resell it to other criminals who then use it to commit all sorts of fraud. Based on interviews with McNealy after his controversial comment on privacy, it certainly looks like he was thinking about the case that Amazon.com represents. In this case, he's probably right. You really don't have any privacy when you do on-line shopping, but there's probably not much harm that results from that particular loss of privacy. The convenience that you gain and money that you save from shopping on-line probably makes up for the privacy that you give up to do it.

Back in 1999, however, cyber-criminals weren't as numerous or as well organized as they are today, so it's unlikely that McNealy was thinking about the threat that they represent. The data that cyber-criminals are after is the data that they can make money from. Today, that limits the valuable data to things like credit card numbers, bank account numbers, and ATM PINs. There's a huge market in this type of information, and there's so much of this information available that the law of supply and demand has dramatically reduced its value to cyber-criminals. Data that might have been worth $20 to them a few years ago can now be worth as little as $1. And because cyber-criminals are determined and well equipped adversaries, they seem to succeed fairly often. The recent data breach at Heartland Payment Systems is just the latest example of this.

Because the financial fraud that results from the misuse of the data that's compromised in data breaches is now a real a significant cost to the financial services industry, it's now worth taking privacy seriously. In the past, the worst that you might suffer from your privacy being compromised was being shown recommendations for products that you had absolutely no interest in. Today, the stakes are much higher. So although McNealy's comment about getting over the lack of privacy might have made sense in 1999, ten years later, it probably doesn't. Instead of just accepting that fact that it has been hard to keep any significant level of privacy on-line, it's now time for businesses that handle sensitive data to get serious about protecting it. That won't be cheap or easy, but it's a step that they need to take.

Security Errors in Code, Part 2

In Part 1I talked about the CWE and SANS 25 security coding errors. My contention was many of them are caused by lazy programming. In this part I'll be talking a bit more about lazy programming.

The best example of lazy programming I can think of is allocating memory without checking the result. Suppose you have a function that builds a message from a set of input strings, then displays the message. The function might look like this.

void DisplayMsg (char *domain, char *file) {
  char *b, *p = "Processing  from ";
  int d = strlen (domain);
  int f = strlen (file);
  int l = strlen (p);

  b = malloc (d + f + l + 1);
  memcpy (b, p, 11);
  memcpy (b + 11, file, f);
  memcpy (b + 11 + f, p + 11, 6);
  memcpy (b + 17 + f, domain, d + 1);

  DisplayString (b);
}

There are many examples of lazy code here, but let's start with the malloc. The question is, what if the malloc fails? Then b will be NULL and the first memcpy will crash the program. "But," declares the lazy programmer, "I've been programming for 8 years plus 4 years in college and I have never seen a malloc fail (except of course when there's a bug in the code somewhere). In the real world it's not going to fail, so why bother? Besides, what do I do if it does fail? There's nothing I can do."

The lazy programmer says, "There's nothing I can do." There are things you can do, it's just that the things to do require more work. So really what the lazy programmer is saying is, "There's nothing I can do that is quick and easy, I don't want to have to spend time writing code or expend energy using my brain to figure them out."

1. Have an "Out of Memory" message ready. If the malloc fails, display that.

  char *memoryMsg = "Out of Memory: Message Cannot be Displayed"

  if (b == NULL) {
    DisplayString (memoryMsg);
    return;
  }

2. Return an error. The subroutine DisplayMsg returns void, instead, have it return an error code.

  int DisplayMsg (char *domain, char *file) {
    ...
  if (b == NULL)
    return (M_ERROR_MEMORY);

The lazy programmer says, "But handling errors is hard. Now the calling routine has to deal with an error." Yes, it's hard. But it's better than dealing with bad code. Besides, that's what you're paid to do, write good code and solve the hard problems.

I think any programmer who writes code like the above is doing it that way because it takes effort to write good code. And now that we know this programmer does indeed prefer to take the easy route and hope nothing bad happens, we will be suspicious of all code they produce.

By the way, there are other examples of lazy programming in the example above. See what you find and in Part 3 I'll discuss what I think is lazy.

Security Errors in Code, Part 1

A couple of organizations, CWE and SANS (see their websites for a description of what the acronyms mean and what they do), have published a list of the "Top 25 Most Dangerous Programming Errors". This list enumerates common security problems in commercial code. See the list either here or here.

Some of the errors most programmers have heard of, even if some might not know exactly what they are. For example, "SQL Injection" and "Cross-site scripting" are well-known among some programmers because this is part of what they deal with everyday. Other programmers have not done any database or web site programming so might not fully understand these terms yet. Others are well-known, such as "Buffer overflow" and "Hardcoded passwords".

I was glad to see "Use of a Broken or Risky Cryptographic Algorithm", one of my Crypto Blunders (see this previous blog post). Another was "Use of Insufficiently Random Values". That has been one of my favorite topics for years. Back when I was the one who selected speakers for the Developers Track at the RSA Conference, I always made sure there was a talk on random number generation (Bob Baldwin's talk on hardware random number generation was probably the best conference talk I have ever seen in my life, at any conference, even better than Ron Rivest's talk on RC5).

In my opinion, many of the mistakes (not necessarily all) are caused by lazy programming. Let me give you an example of lazy programming.

In the C language, you allocate memory. This is usually a malloc or calloc or similar call. I have seen code that does not free the memory (memory leak). I have heard programmers say things like, "So what, I forgot to call the free. It doesn't really matter, once the process completes the Operating System will figure out that the memory is no longer used." By the way, is that true? Do modern systems have the ability to garbage collect? But even if that is true, it's lazy programming. Another thing I see is memory allocation and no check to see if it was successful or not. The excuse? "On modern computers, there's so much memory, no one ever runs out of memory." This is lazy programming.

And the thing about lazy programming is that if you're lazy in one place, you're lazy in other places. If you're lazy with memory allocation, you're probably lazy with "Improper Input Validation" and "Race Conditions".

For example, when you write an API, a function your customer can call might include 5 or 6 input variables. Do you check all of them to make sure they're valid? Do you have a way to know whether an input value is valid? Do you assume no one calling the function will make a mistake? The lazy programmer will simply write the function to work no matter what the input. That's lazy and it leads to the "Improper Input Validation" error. Anyone who is lazy with input validation is probably lazy with "Execution with Unnecessary Privileges".

Another way to put it is this, if you see code that does a bad job of input validation, but that error somehow does not cause a problem, some other error you don't see right now probably will cause a problem.

In part 2 I'll talk about how to avoid lazy code.

Creating useful standards

Determining exactly how big a cryptographic key needs to be can be confusing. Even in the case of symmetric algorithms it can be tricky. DES, for example, uses a 64-bit key, but that doesn't mean that it provides 64 bits of strength. Eight of the 64 bits are parity bits, which don't give cryptographic strength. Only the remaining 56 bits do that. In the case of Triple-DES, you have 192 bits of key. Of these, 24 are parity bits, leaving only 168 that can provide cryptographic strength. There's an attack, however, that can be done in much less time that trying all 2¹⁶⁸ Triple-DES keys. Because this attack can be done in the time needed to try only 2¹¹² keys, Triple-DES is said to provide 112 bits of strength.

It's even trickier when it comes to public-key algorithms. Even experts disagree on exactly how much work it takes to defeat a 1,024-bit RSA key. You can find a comparison of several different points of view here.

The issue of determining exactly how many bits of strength an asymmetric key provides is apparently so bitterly debated that if you pick any one of the expert opinions and try to incorporate it into a standards document, there will always be someone who complains. This seems to be why the IEEE P1363 Standard Specifications For Public-Key Cryptography doesn't even try to tell how many bits of key are needed to provide standard levels of cryptographic protection. Instead, they just give vague and general guidance that's useless to a person trying to implement the algorithms described in standard. This is unfortunate. I've seen people make mistakes because they didn't understand how many bits of RSA key are needed to get the same protection as a Triple-DES key, and this confusion could have been avoided if standards documents were clearer.

It seems to me that the people who write the papers that give different estimates for asymmetric key strength are missing an important point. What's not really very important is exactly how much work is needed to attack a particular RSA key. Instead, what's important is what size key customers say they want to use. Both NIST and ASC X9 have made this very clear, and their needs are reflected in standards like FIPS 140-2, even if other standards can't quite manage to decide what to say.

If customers say that's what they want, then security vendors should give them that, even if arcane academic arguments say that the estimates are off by a few bits. Leaving this information out of standards and hoping that customers will be able to figure it out for themselves isn't a good idea at all. The customers that care have clearly said what they want. The participants in standards bodies should listen to this advice and use it when they create standards.

Why PCI DSS?

It's probably no secret to anyone reading this that the information security requirements for anyone handling credit cards have been increased dramatically recently. These requirements are reflected in the Payment Card Industry Data Security Standard (PCI DSS). As you'd expect, there's been a fair amount of grumbling by the merchants who are the most affected by the new standards. This is to be expected, of course. Nobody wants to spend money on information security that they don't need. So one question to ask is whether or not the PCI DSS is really needed. A look at the market for stolen or compromised sensitive information seems to show that PCI DSS is badly needed and may not even be enough.

One of the best studies on the underground economy of stolen or compromised sensitive information is probably the one done by Jason Franklin, Vern Paxson, Adrian Perrig and Stefan Savage. Their paper that describes their research and what they learned is "An Inquiry into the Nature and Causes of the Wealth of Internet Miscreants." You can find a copy of it here. It's well worth the time and effort that it takes to read. One graph from this paper shows the most common types of data that were advertised as being for sale by cyber-criminals. Here's what that graph looks like. 

     

This graph seems to show that credit card information is widely available. It's more available than Social Security numbers or ATM PINs by a factor of roughly 20 to 1. This means that it's probably the case that credit card information needs to be protected much more than it's being protected now.

The PCI DSS is probably a good first step in this direction, but even complying with the latest version of the PCI DSS isn't enough to guarantee that credit card information won't be lost or stolen, as the recent data breach at Heartland Payment Systems shows. Heartland passed their PCI DSS audit, but hackers still managed to penetrate their system and compromise millions of credit card numbers.

Stages of Ethics

In a previous post, here, I discussed the stages of ethics. To recap, they are

1. Something is wrong because I'll get punished for it.
2. Something is wrong because a higher authority says so.
3. Something is wrong because society/the people around me say so.
4. Something is wrong because it's wrong.

The 4th stage is ethics, someone thinks about why something is wrong (or right). Most people would claim they are in the 4th stage, but we know there are some who are not. It would be great if there was a test one could take which would tell us which stage we were in.

The problem with ethics tests is that people know what the answers are supposed to be. How someone answers a question on a test and how someone behaves in real life can be two different things. For example, this Wall Street Journal article reports that some employers require applicants to take personality tests, which purportedly measure work ethic and honesty, among other traits. However, cheaters simply give the answers the test wants, sometimes even getting answer keys online. As one cheater put it, this type of test "weeds out people who are honest and selects those who lie."

A true test of ethics would see how people behave when no one is looking. But then we wouldn't be able to obtain results. If we watch people behave, then they don't behave naturally. This is an example of quantum physics played out in real life: the act of observing something alters the thing being observed.

But I'm not looking for a test that allows outside observers to determine your ethics, I'm looking for a self-administered test that individuals can take to assess their own ethics. This would be like those tests that measure political philosophy (are you conservative, liberal or libertarian?)

When no one else will see the results of the test, I suspect that people will be more honest. However, I also think they still will be able to know what the correct answer is supposed to be and there will be a bias. I also think that people might think they're answering honestly, but how they think of ethics and how they act might be two things. For example, someone who says it's wrong to take office supplies home for personal use might take a computer keyboard home, justifying it by saying the office has so many unused ones hanging around, they won't miss one. This is where theory and practice clash.

Maybe the best test would be this. Present a scenario that describes someone behaving in a way that might or might not be ethical. The test-taker then lists reasons the bahavior might be considered ethical and reasons the behavior might not be. Maybe the way someone debates an issue will be the way we can gain insight into that person's ethics.

For example, here's a scenario. It's winter in the San Francisco Bay Area. At 6:00 PM it's already dark. A man is driving home from work. His daughter is in a school play tonight, beginning at 6:30. He wants to be on time, he promised his daughter he would be there. But traffic is really bad. It looks like he'll be late. Unless he drives in the carpool lane. That lane is for cars carrying two or more people. But he's alone. Describe some arguments that say ethically it is OK for him to drive in the carpool lane, but also give some arguments that say ethically that it is not OK for him to drive in the carpool lane.

My guess is that the arguments people describe would tell a lot about the stage of ethics they are in. I'm not saying I could necessarily interpret them, but I think we might be able to gain insight. For instance, does someone say, as an argument for it's OK, "It's dark, the probability that the Highway Patrol will be able to see that he is solo is so low, he won't get caught." That seems to imply stage 1. Or someone who says, as an argument for it's not OK, "Too bad, you should have planned for the possibility of traffic, the law is the law." That implies stage 2.

What they aren't saying

The big data breach at Heartland Payment Systems was announced two days ago, and Heartland quickly set up a web site to announce the breach. Here's the headline from the web site:

Heartland Payment Systems Uncovers
Malicious Software In Its Processing System

No merchant information or cardholder Social Security numbers compromised.

If you read further, you find this:

No merchant data or cardholder Social Security numbers, unencrypted personal identification numbers (PIN), addresses or telephone numbers were involved in the breach. Nor were any of Heartland's check management systems; Canadian, payroll, campus solutions or micropayments operations; Give Something Back Network; or the recently acquired Network Services and Chockstone processing platforms.

That certainly doesn't look too bad, does it? What they don't include in the list of information that wasn't compromised is customer's credit card numbers. So it certainly looks like credit card numbers were what the hackers were after and were also what the hackers got. Why not be clearer about this? Why not replace the headline on the we site with this one?

Heartland Payment Systems Uncovers
Malicious Software In Its Processing System

Millions of credit card numbers compromised.

The truth is going to come out eventually. Probably very soon. If credit card numbers were compromised, why not just admit it? Hoping that people won't read your announcement too carefully probably isn't the best way to deal with a data breach.

Why I like RC5 and RC6, Part 3

In Part 1 I talked about how great RC5 was, in Part 2 I discussed the major complaint against RC5 and the attempt to overcome that complaint in RC6. Now let's compare these two algorithms to other ciphers.

First up, DES. You might be thinking, "DES is broken, it's old, it's a bad cipher." Actually, DES was never broken, the only problem was that it used a 56-bit key, and computers got so fast it was possible to do a brute-force on a 56-bit key in 24 hours. That is, the algorithm is still strong, it's the key that's weak.

Incidentally, the 56-bit limit on the key size is artificial, imposed by the US National Security Agency to make it easier to break. The NSA doesn't like other people to have the ability to keep secrets, so they would rather no one used encryption. However, they knew that they couldn't stop it, that people would use encryption. Hence, they chose to direct the development of DES as a standard. That way, if people were going to encrypt, they could make sure people used the algorithm they wanted them to use. And they made sure it had this 56-bit key.

So how does RC5 compare to DES? It's faster (20 to 80 times faster), smaller (20 times smaller), has a variable round count (more rounds for more security), and much easier to analyze. As for analysis, here's an interesting story about DES. The original algorithm (called Lucifer) used various tables of values, called "S-boxes". There are 16 of them, each with 64 32-bit numbers like 0x00108000 or 0x20101004. During encrpytion, the algorithm performs XOR operations with different values in the tables, table entries determined based on the key and input data. However, the NSA suggested some changes to the tables. At the time, no one outside the NSA knew why the proposed tables would be better, but the change was made. Years later, someone in the industry came up with an attack called differential cryptanalyis. It turned out that DES with the old tables was susceptible to the attack, but with the new, NSA tables, it was secure.

Companies that wanted keys bigger than 56 bits had to use DESX or TripleDES if they wanted to follow the standard. Those who were willing to use a non-standard algorithm used RC2, IDEA, Cast, Safer, and Blowfish (there were others, but these were the leaders). But RC5 was the next generation beyond all these algorithms. It was faster, smaller, and used less memory. It also did not use S-boxes. Other algorithms followed the DES model and had these look-up tables. But now people were thinking, "How do we know the S-boxes are good? After all, we know that there can be bad tables, look at DES." In the late nineties, RSA Data Security was selling RC5 to companies that liked its speed and size. Companies making small devices, such as cell phones or other hand held equipment, especially liked it. We even were able to put it onto a pacemaker (that project never went through, but we were able to do it).

The main problem with RC5 now was that it was patented. Anyone who wanted to use it had to pay RSA. Because DES, TripleDES, and other algorithms were free, you could write the code yourself or sometimes even find Open Source code. Why pay for something when you could get the competition for free? Trust and support might be reasons, but the main reason people paid for RC5 was the speed and size. If they simply couldn't afford more than a few hundred bytes of code size or memory, RC5 was about the only game in town.

The next hurdle was AES. The US government declared a competition: submit your algorithm and we'll choose one to replace DES. There were 15 original applicants, narrowed down to 5: RC6, Rijndael, Serpent, Mars, and Twofish.

The first question might be, why not simply update DES to use bigger keys? Remember, the algorithm itself was never broken, it was still strong, it was the key size that was the problem. Well, that's pretty much what Rijndael is. The actual DES algorithm is so slow, a version that simply uses bigger keys would never win. But researchers Rijmen and Daemen, developed an algorithm that updated the DES model of XOR operations based on S-boxes. They also supplied good mathematical evidence to show that the S-boxes were secure. It was much faster.

Researchers from around the world examined all five algorithms. One thing came through among all independent researchers: RC6 was much smaller in code size and memory usage, and almost universally significantly faster than all the other algorithms. Someone found an issue with the RC6 key table, but that was resolved. Others were upset that RC6 "barely" exceeded the security requirements, whereas the others were way over the bar. Then there was the multiply. Those testing the algorithms on Smart cards found RC6 very slow on those cards that did not have a fast multiply. Finally, people who build chips pointed out that making an RC6 chip would not be as easy as making a Rijndael chip (a chip that has the algorithm built in, rather than a sequence of instructions, the algorithm is performed on the chip).

In my opinion, the complaints were not that important. "Barely cleared the security bar?" That's just stupid. If the requirements were to have a cipher that has security level 500 (a made-up number for illustrative purposes only), and RC6 has level 510 but the other algorithms have level 620 - 740, so what? You need 500, you have 500. If you don't think 500 is enough, then set the bar to 600. RC6 will be 22 or 24 rounds instead of 20 and be 610. But then the detractors would say, "Well, 610 barely clears the bar, so that's not good enough." OK, then make the bar 700, or 800 or 1000, or 1,000,000 or 500 quintillion. Add more rounds and the algorithm will meet the requirement. But you can't say, "You must meet this minimum requirement, but what I really want is for you to meet minimum + extra."

That's like saying, "You must be at least 4 feet 5 inches tall to ride this roller coaster," then denying someone who is 4 feet 6 inches because they just barely met the minimum. If 4 ft 6 is too small, then make 4 ft 7 the minimum. But then someone 4 ft 8 barely meets the min, so make the min 4 ft 9. And so on until the min is 8 ft tall and no one rides.

The multiply? As Rivest pointed out, the idea of AES was to be the algorithm for the next 20 years, not for just the year 2000, and all chip makers, including Smart card chip makers, were either now, or very soon going to be, making chips with fast 32-bit multiplies, regardless of the AES selection.

The algorithm in hardware? That will account for less than 1/100 of 1% of the usage of the algorithm. You're saying that you want to deny 99.99 % of the users of the algorithm the advantages of RC6 so that .001% of the users get something better? And it's not like the alternative was all that much better. RC6 got an A- from the hardware designers, Rijndael got an A.

However (and this is the big however), some of the other algorithms (including Rijndael) did not have those complaints. In other words, the drawbacks to RC6 were small (in my opinion invalid), but other algorithms had virtually no drawbacks. Well, they all had one drawback: size and speed.

In the end, Rijndael was chosen as the AES algorithm. In my opinion here's why.

1. The patent. None of the other algorithms had any intellectual encumbrances at all. The developers of all the other algorithms had relinquished all intellectual property rights, whether the algorithm was selected or not. RSA said they would relinquish IP rights only if RC6 were selected. Too many people just didn't want to have even a hint of IP issues.

2. Size was no longer important. One of the big advantages of RC6 was not seen as important. Where Rijndael would be about 15,000 bytes of code size plus memory, RC6 was less than 1,000. But 15K on even a cell phone or other constrained device was soon to be no issue.

3. Speed was not as important. Chips are getting so fast that a "slow" algorithm will still be fast enough. If you need 12,000 bytes per second, and with RC6 you get 100,000 and with Rijndael you get 30,000, how much does it really matter?

4. Trival complaints. RC6 had some perceived drawbacks (the multiply, etc.), which generally wouldn't be real issues. But when you need to make a decision between two very good things, the insignificant or even invalid complaints might be the only thing you have to differentiate.

5. New vs. old. The main component of RC6 is the data-dependent rotation, an idea almost 20 years younger than DES. In the crypto community, age is often better. The longer something has been around and studied, and survived in good shape, the more confidence it inspires and the less likely someone is willing to switch. Because Rijndael uses the same philosophy of DES, some will always feel it is the "safer" choice.

So I like RC5 best because it is so fast, small, and elegant. No matter what system you're using, with computers smaller and faster is always better. Small and fast can never hurt and sometimes help. Big and slow can sometimes hurt you. And you don't have to sacrifice security for the elegance.

RC6 solves the rotate count issue, but I still like RC5 better because I don't think the rotate count issue is a real problem. It's solved by adding more rounds, each of which is much faster than an RC6 round. As Terence Spies says, "Throw rounds at it."

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.

CERT coding standards

Writing software that works correctly is hard enough. Writing software that works securely is even harder, but the CERT Coding Standards at least provide a good checklist of things to do or not do if you’re programming in C, C++ or Java. Following these checklists won’t guarantee that you’ll avoid all security problems that software can have, but you’ll be much less likely to make the really common and obvious mistakes. Following these standards to write secure code isn't easy, however. The book that discusses just the standard for secure coding in C has 720 pages.

Why I like RC5 and RC6: Part 2

In Part 1 I talked about how great RC5 was. Secure, easy to analyze, fast and small, it seems like there's nothing bad to say about it. Well, here is the number 1 complaint: The rotation count in a round is based on 5 of 32 bits. I'll explain.

Here are the guts of RC5 (one roumd).

   A = A XOR B
   A = A rotate left by B
   A = A + keyTable[i]
   B = B XOR A
   B = B rotate left by A
   B = B + keyTable[i+1]

A 32-bit number can be rotated 0 to 31 bits. Any other rotate count is the same as some value in the range 0 to 31. That is, a 32-bit rotate is equivalent to a 0-bit rotate, a 33-bit and a 1-bit rotate are equivalent, and so on. Hence, when rotating A left by B, what is really happening is "rotate A left by the number that is in the last 5 bits of B." For example, if A = 0x4C1D7152 and B = 0xB199AF31, then A will be rotated by 17 bits.

   0x4C1D7152 ROTL 0xB199AF31 =
   0x4C1D7152 ROTL 0x00000011 = 0xE2A4983A

Why is this bad? Because so much of the security of RC5 comes from the rotate, and two similar plaintext blocks will produce very similar results. Maybe it's easiest to show with examples.

   A = 0xFD84DE63
   B = 0xB199AF31

   1/2 round:

   A = A XOR B             A = 0x4C1D7152
   A ROTL B                A = 0xE2A4983A
   A = A + table[i]        A = 0x7105B361

Now let's suppose the A and B are slightly different (one bit difference, the most significant bit of B)

   A = 0xFD84DE63
   B = 0x3199AF31

   1/2 round:

   A = A XOR B             A = 0xCC1D7152
   A ROTL B                A = 0xE2A5983A
   A = A + table[i]        A = 0x7106B361

Compare the results of the two.

   A =
   0x7105B361  case 1
   0x7106B361  case 2

When you have two plaintext blocks that are very similar (they differ by only one bit), if the ciphertext is similar, you have a problem. An attacker can look at two ciphertext blocks, see the similarities and deduce things about the plaintext.

In the case above, the two ciphertexts differ by only 2 bits out of 32 (7105... vs. 7106...). What you'd like is to have, on average, 16 bits differ.

On the other hand, that's only one round of RC5. Remember, there will be 20. In the next round, maybe one of the rotation counts will be different. In fact, in the example above, in the second round, after the first rotate, the two cases would look like this.

   A =
   0xD72829EB   case 1
   0xEB341481   case 2

The two ciphertexts are starting to differ more. In other words, two similar plaintexts produced similar ciphertexts after 1 round, but after 2 rounds, they are very different. And the differences will only compound in the later rounds (as Ron Rivest put it, "an avalanche of change").

So why the complaint? Because if the rotation count were based on ALL the bits of the "other word", then the divergence would happen in the first round, not the second. Furthermore, analysts were able to come up with cases where the differences were smaller than the example here, and the divergence didn't happen until the third or fourth or even a later round.

Some analysis claimed that by the tenth round, the probability of no divergence was so low that it was virtually impossible. That is, the avalanche will begin by the 10th round at the latest. It was also true that it would be a very rare case that the avalanche begins later than the 3rd round. However, other analysis showed that it was possible the divergence could be so late that if only 12 rounds were used, it would be possible to apply differential cryptanalysis.

When the AES competition opened, Ron Rivest thought it might be a good idea to adjust RC5 so that all the bits of one word would be used to compute a rotation count. That would silence the only real technical criticism of the algorithm, thereby making the adjusted algorithm a much better candidate. The solution was to introduce a multiply in the round.

   r = B * ((B shift left 1) + 1)
   r ROTL 5
   A = A XOR r
   A ROTL r
   A = A + table[i]

(Note that this is not the exact RC6. However, for ease of illustrating the point I have "adjusted" it slightly, but the operations are the same.)

If we used this form of RC5 in our example, the two cases would have generated the following r values in the first round.

   r =
   0xD0B7BE7E   case 1
   0x3E57BE66   case 2

In case 1, the round count would be 30, and in case 2 it would be 6. The divergence would happen in the first round, not the second.

In fact, researchers showed that RC6 is highly resistant to differential cryptanalysis. The avalanche began in the first round virtually every time.

However, there is the problem of the multiply. This slows down the algorithm. People believe a multiply is expensive. Futhermore, one important use of encryption is on Smart cards, and many of them were originally 8-bit processors so a 32-bit multiply would be disastrous.

On most chips, an add and XOR are 1 cycle each. A rotate is either 1 cycle if a rotate instruction exists (such as Pentium) or 4 cycles if not (it has to be done using a copy, 2 shifts, and an add). On the other hand, back in the 80's, a multiply on most chips was 20 cycles.

But we weren't talking about the 80's. In the 90's, chips could do multiplies in 6 - 8 cycles. By 2000, Intel had a 2-cycle multiply, and almost all chip manufacturers had multiplies that were 4 or fewer cycles (Sparc was a notable exception, in 2000 their multiply took over 20 cycles. Why? I don't know and I'd like to talk to the people who were responsible to find out). Even the Smart card makers, by 2000, used 32-bit processors that had fast multiplies. However, the preception was still there, multiplies are expensive.

In Part 3 I'll compare RC5 and RC6 to other algorithms and look at why RC6 was not selected as the AES algorithm.

Largest Data Breach

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

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

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

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

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

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

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

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

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

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

Why I like RC5 and RC6: Part 1

In a previous entry, I said that RC5 is the greatest block cipher ever. A colleague thought I would declare the Goat Cipher the greatest (that's the one I designed), but I have to admit, Ron Rivest is a better block cipher desiger than I am. Who'd have thought that?

By the way, Rivest, the inventor of RC5, is the "R" in RSA and also designed RC4, a stream cipher that, because of SSL, has almost certainly encrypted more data than any other cipher in the history of the world.

In the early 1990's, Ron Rivest developed RC5. It employed data-dependent rotations in its main mixing operation, something, for the most part, new and untried in block ciphers. He and RSA Data Security patented the algorithm.

Later on, Rivest, along with RSA Labs researchers Matt Robshaw, Lisa Yin, and Ray Sidney, devised RC6, a variant of RC5, to be a contender in the AES competition. That algorithm was also patented.

You might be asking, "If RC5 is so great, why wasn't it the AES submission, and why didn't RC6 win?" Well, I'll get to that in parts 2 and 3. But first ...

DISCLAIMER
I used to work for RSA Data Security. In fact, I worked for RSA when RC5 was released and was still working there when RC6 was released. I had nothing to do with the development of the algorithms, but because I worked for the company, you might think I'm biased. Maybe I am a little, but I think I would like RC5 and RC6 even if I had never worked for the company. Besides, I was laid off by RSA, so maybe I am biased against the company, maybe I'm bitter about being let go after 9 years there.
END DISCLAIMER

One thing I'd like to point out is that Ron Rivest, in designing RC5, had the stated goal of building an algorithm that would be secure, fast in software, and small in size. And to obtain speed, he didn't think in terms of O(n) (order of number of operations, see the earlier blog post, "Algorithm Performance in Academic Papers and Practice"), he thought in terms of possible assembly code implementations. In other words, right from the beginning, how the operations would really run on a machine was incorporated into the design. I wonder how many other algorithm designers think at that low a level (I don't know, maybe most of them, but from my experience writing assembly code versions of several crypto algorithms, I haven't seen much evidence that they do).

The security of a block cipher is a complicated thing, but probably the best way to describe it is this: A block cipher is secure if the fastest attack is brute-force on the key. So when you present an algorithm to the world, you must also supply research that shows your algorithm withstands all known attacks, or that any "weakness" is exploitable only at a level that is slower than brute-force. For example, you have to show that a "known-plaintext" attack would require so many plaintext/ciphertext pairs that to generate and analyze them would take longer than simply trying every possible key.

Clearly there might be future attacks that have not been devised/discovered yet. But even the crypto world does not demand that you be able to see into the future to defend your design. However, you must do the work of analyzing your algorithm from a cryptanalytic point of view (or pay someone to do it) before submitting it to the world. You don't create an algorithm then demand the rest of the world analyze it. Of course, even though you do supply analysis, if the algorithm seems to be catching on, many other crypto people will subject it to more scrutiny.

It turns out that there are plenty of algorithms that meet this security criteria. So how does one choose a cipher? Look at speed and code/memory size. Look also at speed and size on several platforms and in several languages. Is an algorithm fast on a Sparc chip but not so fast on an Intel? Is it fast if you have 64-bit registers, but very slow if you don't, or so slow on smart cards that it would not be usable? Does it require 1 megabyte of memory? Or 512K of code size? Does that make it prohibitive on a cell phone?

Another thing to look at is how easy it is to analyze. A simple algorithm that is easy to understand and analyze will be studied more, and the analysis will inspire more confidence. There are lots of people who have the skills to analyze a simple algorithm, not so many have the skills to analyze a complicated one. If both the skilled and highly skilled analyze an algorithm and it passes muster, that inspires confidence. If only a few people have the ability to analyze the complicated algorithms (and how can we know they really have the skills to overcome the greater complexity?), we might not feel so assured.

An analogy would be analyzing two mutual funds, one is an index fund and the other pours its money into derivatives, futures, hedge funds, REIT buyback paper, and other hard-to-understand investments. Maybe the complicated fund is better, maybe not, but not many people have the skills to examine the complex fund, so how can we know for sure?

Back to RC5. Rivest published RC5 in 1994 and had accompanying analysis. Because it was Rivest (one of the biggest names in crypto) and RSA Data Security (the crypto company with by far the most customers at the time, including Microsoft and IBM), it received attention. It also started getting traction in the market (as an alternative to DES). Hence, cryptanalysts outside of the RSA "family" started analyzing it. A few minor issues arose, the worst being that the algorithm was susceptible to differential cryptanalysis at 12 or fewer rounds. That was no real problem because the recommended round count was 20, and at that level it was still 40 to 80 times faster than DES (which has a fixed round count of 16).

Note that every block cipher, and I mean every, is susceptible to attacks at low round counts. That's not a problem. It's determining where the threshold is and showing that more rounds solves the problem and does not degrade performance too much. In other words, if an algorithm employs 20 rounds, you can't say it is broken because it is not safe at 12 rounds. That's like saying a six-step ladder is no good because if you stand on the second step you can't reach the ceiling. To declare a 20-round cipher unsecure, you either have to find the weakness at 20 rounds, or else break it at 12, then 14, then 16 rounds, and show a trend.

One of the beauties of RC5, however, was that each round was so fast, adding more rounds to be more secure was not a very big penalty.

The other beauty was code size. The encryption part of the algorithm was 7 lines of code. Add in key setup and data formatting, and an RC5 implementation could be less than 500 bytes of compiled code size. The key table itself at 20 rounds would be less than 200 bytes of memory. That means when you add RC5 to your application, you add about 500 bytes of object code and increase your memory requirements by 200 bytes. That's not megabytes or kilobytes, that's bytes.

Furthermore, this small, simple cipher was easy to analyze. Because it did so little (each round consisted of 6 simple steps: XOR, rotate, add, XOR, rotate, add), and had no complicated tables, it was easy to trace data and watch the transformation. Many people had no problem testing its security.

RC5 is secure, easy to analyze, fast, and small. However, nothing is perfect, so I'll discuss the drawbacks in Part 2. Also, no matter how good something is, you can't look at it in a vacuum, the next step is to compare it to other algorithms. That will be in part 3.

Is audit logging useful?

Do audit logs really help prevent security incidents or not? They don't directly stop anything from happening. Instead they rely on the threat of being discovered to keep people from doing things that they shouldn't do. They certainly help identify exactly who did something, but that's not 100 percent accurate. A hacker might be able to impersonate someone else, in which case the logs would show the impersonated identity as the one who's causing trouble. Or hackers could just delete the logs or the part of the logs that what they've done. So does logging really help or not?

This is very similar to the situation where police use video cameras to record what's happening on the street. Video cameras also don't directly stop criminals from behaving badly, but rely on the threat of being caught to keep them from committing crimes. In the case of video cameras, there seem to be studies that both support their effectiveness as well as claim that they don't do any good. Like in most public policy debates, both sides of this particular issue probably selectively quote statistics that support their position, which makes it hard to decide what's really true. So video cameras might or might not be effective at preventing crime, but they're probably effective at helping catch criminals after they've committed a crime.

I've never seen any reliable data on the effectiveness of audit logging, but I'd guess that it's very similar to the use of video cameras. That's not very helpful, of course, because that means that we can probably say that audit logging either helps prevent security incidents or doesn't help prevent security incidents, just like video cameras apparently either do or don't prevent crime. I'd be very interested to see data which clarifies exactly how effective audit logs are at preventing security incidents as well as exactly how frequently they're compromised by hackers, but I don't think that that information is easy to find.

Algorithm Performance in Academic Papers and Practice

A few years ago I had the opportunity to be the peer in a peer-reviewed paper. The subject of the paper was a more efficient way to perform modular inverse (an operation used in DSA and other public key crypto).

But first ... the starting point in computing the modular inverse is the "Extended Euclidian Algorithm". Over the years, researchers have come up with improvements/variations that can find the result much quicker. Peter Montgomery (of Montgomery Method of Modular Multiplication fame) probably started it, but others have come up with algorithmic improvement.

In the paper I reviewed, a team of researchers had come up with an improvement on a technique previously published. Both papers described the performance in terms of O(n), the order of number of operations. They both claimed that the technique (the original and the improvement) would be faster than the existing methods based on this number.

I was skeptical, so I wrote code to test the performance. First, the technique described in the paper worked, it found the mod inverse. But performance was only marginally better than the Extended Euclidian, and much slower than the algorithm I tested against, a form of Montgomery inverse. (All my implementations used the same underlying multi-precision arithmetic code, so any assembly code or other optimizations used by one algorithm were used by both.)

I sent my results to the journal (I recommended they not publish) along with my comments and my code that tested the algorithm. I asked if the researchers wanted to look at my code to see if I had done something wrong. I never heard back from anyone. The journal never asked me to review again (I suspect they did not want to get a review back that recommended do not publish, so they never wanted to take a chance on me again).

Had the researchers ever written code to test their algorithm? Probably not. I suspect that there are many academic papers out there for which an algorithm is proposed, an O(n) is computed, and that's it. No one ever tests the paper by writing an actual program that implements the algorithm. I say this not based only on this "random sample" of 1, but I have heard other stories of people implementing algorithms based on papers that are not as fast as claimed.

Maybe the researchers got the O(n) wrong, but I don't think so. I just think there's a difference between theory and practice.

(At this point what probably jumps into your mind is the quote "In theory there's no difference between theory and practice, but in practice there is," attributed to Jan L.A. van de Snepscheut, Yogi Berra, and even Albert Einstein.)

What can cause the difference? Maybe one algorithm has fewer operations but more of them are multiplies and divides, and the savings of fewer operations is overwhelmed by the expense of divides and mutliplies. Or more likely, an operation (in number of operations) is not a single add or multiply, but a function, and some functions are more expensive. For example, in computing the mod inverse of a 1024-bit number, a multiply operation can actually consist of 1,024 individual multiplies and thousands more individual additions. A divide can similarly consist of 31 divides and thousands of mulitplies and adds.

In one case I heard of, an improvement reduced the number of operations by half, but each operation was 4 times longer. Think of it this way, suppose you had a loop that's 10 cycles. Do 1,000 of them. The cost is 10,000 cycles. Now suppose you have a way to get the same thing done using 500 loops, but each loop is now 40 cycles. That's 20,000 cycles.

At a previous job, we would look at only number of assembly code adds, multiplies, and divides (a subtract is equivalent to an add). That is, an algorithm's O(n) was order of number of assembly code instructions. That is probably the only true way to measure an algorithm's performance.

Getting reliable data

Reliable data is hard to come by for almost anything connected with information security. There's little data that accurately quantifies information risks and how effectively information security technologies mitigate these risks. This makes it very difficult to make informed decisions about what security products to use.

One of the few sources of such data is the CSI Computer Crime & Security Survey, a survey that's done each year by the Computer Security Institute. This survey can give you an idea of how many security incidents the typical company experiences in a year and the average losses experienced due to security incidents. It also tells how widespread certain security technologies are. Unfortunately, the CSI reports don't talk about the correlation between losses and the use of security technologies. That's what I'd really like to see.

For example, 94 percent of businesses run a firewall and 13 percent reported having their systems penetrated. What would be interesting is the correlation between these two numbers. Do the businesses that don't run a firewall account for more than their share of the total number of penetrations or not?

Similarly, 53 percent of business report encrypting data at rest, and 17 percent reported losing sensitive customer data. Of those who encrypted data at rest, how many lost sensitive data? This could happen, for example, if data is encrypted in a database, but it's not encrypted outside the database. If that's the case, then the data is still vulnerable to being lost when it's pulled to a laptop or burned to a CD, because database encryption stops protecting data once it leaves the database.

So the CSI seems to be a good position to offer provide information on the effectiveness of security technologies. They have the raw data that they can estimate the necessary correlations and conditional probabilities from their data. Maybe they'll add this information to future reports.

Another "Crypto" Algorithm Broken

I used to give a talk called "Crypto Blunders". It was my most popular presentation, I received invitations from conferences all over the world to give it. I loved that talk because of all the free trips it got me.

Blunder #3 was "Don't use the best available algorithm." There are governments and companies that want to keep things secret, yet they use bad crypto, even though good crypto is readily available, often for free. In other cases, people who are not cryptographers, who have not studied the art, will design their own algorithms and use them.

Blunder #4 was "Implement the Algorithm Incorrectly". When implementing crypto, people will get sloppy and do a bad job of implementing the algorithm. These are mistakes that go beyond the classification of "bug" and become blunders.

Well, here's a case, I believe, of a company committing Blunders #3 and 4.

The Nov. 28, 2008 issue of Science reports on a group of Ph.D. students in The Netherlands that was able to break an RFID card. They totally broke it. Using their techniques they were able to continuously refill a subway token without paying, and "clone" cards used to open a garage gate.

I don't know if they performed other experiments, but I doubt they did anything particularly nefarious. However, in order to prove they actually broke the system, and that it was possible to implement the break in the real world, they did indeed show how to get free subway rides and gain access to a building for which they had no true authorization.

In the title, I put the word Crypto in quotes. Here's why. The way they broke the system was to break a key derivation, or pseudo-random number generating (PRNG) function. That's crypto. However, they also discovered that the function used a "linear feedback shift register" (LFSR), which, in my opinion is not true crypto. When you need secure random numbers for a key, or key stream, or any other purpose, you should use a cryptographically secure PRNG. The card maker, however, used something that has been shown many times to be unsecure. So the break looks like crypto, but the card maker used a non-crypto algorithm where crypto should be.

That's blunder #3, using an unsecure PRNG, when secure algorithms are readily available. Why did they use an unsecure algorithm? Here are some theories.

1: The designers didn't know that the random number generator has to be secure. Many developers probably know that the encryption algorithm must be secure, and that the key must be long (80 bits at least, usually 128 bits are used). But sometimes people just never make the connection between how the key material is generated and security.

2: The designers didn't know that LFSR was not secure. I can believe that, before I learned that LFSR was not secure, I didn't know that LFSR was not secure. You can't blame people for not knowing something. But who were the security experts on the team? Did they have any? Did anyone review the design? Possibly not, I've seen companies in the past build security products or add security to a product using personnel with no security experience. The belief is, security and crypto is easy, anyone can learn it.

3: They were dealing with severe constraints on size and speed (remember, this is a chip on a credit card, yet transactions had to be practically instantaneous). They had to come up with a solution that would not add too much size or complexity to the chip, nor slow things down. They probably did not have the space to load software, so the solution had to be hardware. Communications had to be very quick, performing some crypto algorithms might have taken too long. They felt the constraints eliminated AES or SHA-1 or RC4 or RC5 (the greatest block cipher ever). Of course, one of the constraints should have been security. Furthermore, DES on a chip is a problem solved long ago. Don't use DES to encrypt, but it can be used safely as the foundation of a PRNG.

Now on to blunder #4. Apparently, one thing the attackers were able to do was force the chip to accept 48 bits when it was supposed to accept only 32. In a communication between card and reader, the card sends a 32-bit ID. But the attackers sent a 48-bit ID, the reader accepted it and that helped them in acquiring the secret bits. Is that a bug? Accepting a 48-bit ID when IDs are defined as 32 bits? I think that goes beyond bug and into the realm of blunder.

Looking for the data

The information security industry has its share of disinformation and misinformation that's spread by vendors, most of which is meant to make their products look more useful than they really are. Because of this, I've learned to be skeptical of any numbers than vendors use to help sell their products. If you take a close look at the data and the ways in which vendors spin it, you often find that their interpretation doesn't withstand much careful examination. This knee-jerk reaction to question data and its interpretation recently led me to look for data that quantifies the "credit crunch" that's widely discussed in the media.

The best source of raw data that I found is Federal Reserve Statistical Release H.8, Assets and Liabilities of Commercial Banks in the United States. You can find this here. The data that I looked at gives weekly values from January 3, 1973 through December 31, 2008. There may be more recent data available now.

If you look at this data, it's hard to find signs of credit decreasing. Here's the data for total bank credit.

Here's the data for the past two years. It's hard to see signs of credit decreasing on this time scale either.

 

So if there's a shortage of available credit, it's hard to see it from this data. This doesn't mean that there's no credit crunch. It just means that it's not obvious from the data that the Federal Reserve has on the amount of loans being made by banks. It might be the case that businesses in capital-intensive sectors like life sciences, telecommunications, utilities and energy don't get their funding from banks, so their loans aren't reflected in this data. Maybe there's other data somewhere that shows a downward trend in credit. Any ideas where it is?

Financial risk tradeoffs

Risk homeostasis is the theory that people like a certain level of risk in their lives and will tend to change their behavior, possibly increasing risks in one area if the risks that they experience in another area are reduced. Experiments seem to show that there's some basis for believing that this actually happens in some cases, although it's not clear exactly how much behavior is changed and how important the effects of the changed behavior are.

If one risk is reduced, people may change their behavior to include other risky activities, and the new situation may actually either be better or worse than the original situation. If the new behavior causes more loss than the original behavior, then reducing the original risk will actually result in a net loss. If the new behavior causes less loss than the original behavior, then the reducing the original risk will result in a net gain. Two examples from the financial services industry may illustrate this.

At the heart of the recent financial crisis, for example, is the rate at which American home-buyers are defaulting on their mortgages. A careful look at the available historical data from the FDIC shows that the default rate for mortgages has actually been steadily increasing since 1972, and that the current situation was probably inevitable in light of this trend. The FDIC report that gives this historical data also shows that the trend  towards consumers accepting more and more financial risk is the most important cause of the increasing default rate on mortgages. So if the increased default rate on mortgages is caused by consumers' willingness to accept more financial risk, why have people been willing to accept more and more financial risk?

One possible explanation for this trend is that the increased acceptance of financial risk was caused by the safer environment caused by the stricter health and safety standards that were adopted over roughly the same period. Perhaps people that live and work in a safer environment found assuming additional financial risk as a new way to keep their lives exciting. If this is the case, the trillions of dollars in losses that we're now seeing in the financial services industry may actually outweigh the benefits from the safer environment.

Another example of substituting one risk for another may be seen in the ways in which credit unions make their money. One difference between credit unions and commercial banks is that more customers of credit unions have overdraft protection on their checking accounts than customers of commercial banks do. Having this service in place makes writing a bad check less risky than it would be otherwise, and credit union members probably make up for this decreased risk by being less careful about the checks that they write. The fact that over 60 percent of the revenue of credit unions comes from charges from overdrafts indicates that this may indeed be the case. For commercial banks, less that 18 percent of their revenue comes from overdraft charges.

So it seems that credit unions may essentially be possible because of the increased risks that they get their customers to accept and the fees that they can charge to support this risky behavior. Credit unions seem to serve very useful purposes, so it might be the case that the services that are subsidized by their customers carelessly writing checks may more than make up for the costs that the careless customers incur.

The benefits of provable security

When I was in graduate school, I had a teaching assistantship that paid my tuition and fees and gave me a few thousand dollars to live on. In return, I had to teach a few undergraduate math classes. To prepare us for this, we had to sit through a class that gave us an overview of how to teach math classes. I don't think that the class lasted that long. I'm fairly sure that it was more than one hour but less than two hours. After this, we were set loose on the unsuspecting undergraduates.

In this class, we were told that studies have estimated that many people don't have the cognitive ability to understand much past high-school algebra. This means that if you're teaching a math class, there will probably be people in your classes who are smart and hard-working, but they won't be able to understand the more advanced math and there's not much they can do about it.

At the time, I believed it. Now, I'm not so sure that this is actually true. Today, I'm more inclined to believe that understanding complicated things is just a question of having enough interest to spend the time and effort needed to understand the complicated things. Math is just one example of something that's complicated, and it's far from being the only example.

Not many people understand the math behind public-key cryptographic algorithms. The math behind the pairing-based algorithms that Voltage uses is particularly difficult, and most people don't get around to understanding it. Most of them don't need to, of course. For most people, knowing that there are formal proofs that Voltage's IBE is secure is good enough, and they don't want to understand the details of exactly why this is true. This is as it should be.

All businesses have more important things to worry about than the details of exactly why their secure e-mail is actually secure. If my theory about interest being mistaken for aptitude is right, most people could actually understand the math behind public-key cryptography if they had enough interest in the subject. On the other hand, most people just don't have enough interest to get them to take the time to understand the technology. They have things that are more important to them, and those are the things that they spend their time thinking about. If someone who understands these details showed that it's secure, that's good enough for them. Maybe that's the real benefit from provable security.

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.

Stages of Ethics

This is a post about ethics. What does ethics have to do with security? Well, if everyone were ethical, there would be no need for security. So I'm going to justify this entry by saying that understanding ethics (or the lack thereof) helps us to understand how to implement security measures.

Over the years, I've read various versions of the stages of ethics. They tend to be very similar, but there's one I like so I'll present it here.

Four Stages of Ethics

Stage 1, the baby/toddler years: Something is wrong because you'll get punished. Children learn, "If I hit my sibling I'll get a time out or I won't get to play with a particular toy." So they know hitting the sibling is wrong. However, if they don't get caught, children in this stage don't feel bad, or have a guilty conscience, or suffer remorse. If there's no punishment, it's OK.

Stage 2, early childhood: Something is wrong because a higher authority says so. When the parents declare, "Don't ride your bike beyond 6th street," the child won't. Even if no one is looking, even if they know they wouldn't get caught, children in this stage won't do something because the parents said so. But they also start thinking in loopholes, "My parents never said I COULDN'T climb onto the roof, so it's OK."

Stage 3, late childhood, teens: Something is wrong because the group says so. Older kids and teenagers behave the way they see the group behaving. Most teenagers are a bit rebellious, but most of them also follow a dress code at school, so most teenagers follow the dress code (a bit of circular logic, but trust me, it makes sense). Of course, the teenager who hangs out with kids who shoplift will find it easier to accept the group ethic of shoplifting.

Stage 4, adulthood: Something is wrong because it's wrong. In this stage, people have ethics. They think about what is right and wrong and why. People with ethics do what they feel is right, regardless of punishment (or lack of punishment), regardless of what higher authorities say, regardless of what the people around them say. People who fought against racial segregation in the US (despite the higher authority and the threat of punishment), and people who don't call in sick when they're healthy (despite an almost zero chance of being caught) are ethical people.

The problem is that some people never advance beyond one of the three early stages. There are adults, still in stage 1, who will not hesitate to do something illegal/immoral/wrong if it benefits them and they won't get caught. Most criminals are this way. The offenders who express remorse at sentencing are often remorseful because of the bad things happening to them, not for the harm they did to other people.

Those stuck in stage 2 are more likely to unquestioningly follow the declarations of a church/priest or the boss and politician ("My country, right or wrong", "My religion says birth control is wrong, so I don't use it"). They are also the people who look for loopholes and look for alternate interpretations of commands that suit their purpose. When the company policy is "No side businesses at work," someone will justify a side business saying, "I only do it during my lunch hour, so technically I'm not at work."

Someone still in stage 3 will steal office supplies or cheat on their taxes or improperly download movies or music or software, saying, "Everyone does it."

If you presented the stages of ethics (in this form or something similar) to most people, I imagine most would agree with the general idea (maybe quibble on the details). I also think that most people would believe they are in stage 4. You can probably think of some people who are clearly stage 1 or 2 people (probably not stage 3 and at least definitely not stage 4), and I'll bet you they would say they are in stage 4. No one is going to say, "Yeah, I'm someone who will do anything and not feel guilty so long as there is no punishment."

The reason most people would say this is because they do contemplate ethics. That's one of the ways to recognize stage 4, thinking about ethics. The problem is that most of us to some degree try to figure out how a situation that would benefit us personally could be considered ethical. That is, the train of thought is not "This is beneficial to me, but is it ethical?" Rather, it is, "This would be to my advantage, how can I construe this to be ethical?" Not explicitly, but that is what is happening.

For example, suppose you have two tickets to a show with unassigned seating. Suppose also that the show has in-and-out privileges, just show your ticket on the way out and the way in. You and a friend could use the two tickets to get in, then you could take both tickets, go outside (showing one ticket on the way out), hand the second ticket to a third party and now you and the third party get in. Three people on two tickets. Is this ethical?

"The show is nowhere near a sellout, so we're not causing overcrowding."

"They make most of their money on concessions, so they want more people to show up, even if they don't buy tickets."

"We'd never buy three tickets -- if we couldn't do this 3-for-2 trick our third party simply would not join us -- so we're not depriving them of any income, in fact, we might be adding to it because we might buy concessions."

"If we like the show, we'll buy more tickets in the future, so they might make more money in the long run."

Is this rationalizing? Or is it a valid ethical conclusion? Sometimes rationalizations are valid ("Even though a right turn on red is illegal at this light, I needed to get out of the way of that ambulance.") In the example above, it is entirely possible the people running the show would be glad to have extra people come in, even though they did not pay, for exactly the reasons given (concession sales and possible future ticket sales). However, in my opinion, the above thinking would be true ethics only if the ticket holder contacted the show people and asked if they would be OK with a 3-for-2 trick. If not, then this is an example of "This would be to my advantage, how can I construe this to be ethical?"

More on this topic in upcoming posts.

The Common Configuration Enumeration

The National Vulnerability Database (NVD) is probably the best place to check for any known security vulnerabilities in software products. It now contains information on over 34,000 different security vulnerabilities. Its Common Vulnerabilities and Exposures (CVE) naming scheme is the most common way in which security vulnerabilities are identified, and many commercial security testing products now report their findings with CVE numbers attached to them.

The vulnerabilities that CVE names cover all relate to design or implementation flaws in products. That covers many security vulnerabilities, but not all of them. Many other vulnerabilities are caused by the way in which products are configured. The National Checklist Program that's run by NIST now has 142 checklists for 78 different products that list ways to configure them securely, but there's no database of ways in which configuring or misconfiguring products can cause security problems. This is changing, however, and this information will eventually be part of the NVD.

The new scheme is the Common Configuration Enumeration (CCE). From the MITRE web site, here's a description of what the CCE scheme will cover:

CCE™ provides unique identifiers to system configuration issues in order to facilitate fast and accurate correlation of configuration data across multiple information sources and tools. For example, CCE Identifiers can be used to associate checks in configuration assessment tools with statements in configuration best-practice documents.

So once CCE is rolled out and added to the NVD, we'll have a repository of all known security vulnerabilities caused by configuration or misconfiguration of products. That should make the NVD even more useful than it is now.

Is risk homeostasis real?

Is risk homeostasis real? There are studies that both confirm and deny its existence. Many of these studies are biased, but research that tries to eliminate the bias seems to indicate that risk homeostasis is real.

Risk homeostasis is the theory that people like a certain level of risk in their lives, and that if you eliminate one form of risk, people will tend to compensate by taking additional risks. If this really happens, it has significant public policy implications. Wearing seatbelts, for example, might make people feel safer so that they compensate by taking other risks. If the dangers from these additional risks exceeds the danger from not wearing a seatbelt, then we may actually be better off by not requiring people to wear seatbelts than by requiring people to wear them.

In the case of seatbelts, it can be difficult to get an unbiased answer as to what’s best. Some researchers, particularly those with Libertarian leanings, seem to want to prove that making people wear seatbelts doesn’t make sense. You can see an example of this here. Other researchers, like those working for insurance companies or government health and safety organizations, seem to want to prove that making people wear seatbelts is a good idea. You can see an example of this here.

Supporters of either side in this debate may selectively cite statistics that support their position while ignoring those that don’t. Because of this, there are studies that have shown that requiring drivers to wear seatbelts is both a good idea and not a good idea, which makes it difficult for policy-makers to make an intelligent and informed decision about what’s best to do.

There are also areas of information security in which we might expect to see the effects of risk homeostasis if the effect is actually real. We might expect people running anti-virus software, or example, to be less careful when opening emails or attachments to emails if they believe that their anti-virus software is protecting them.

Jeremy Jackson, while a student at Simon Frasier University, decided to test whether or not risk homeostasis is real. To do this he carefully created an experiment that tried to eliminate all of the sources of potential bias that earlier experiments might have had. His experiment tried to test the accuracy of the original study that claimed that drivers compensate for the additional safety that wearing seatbelts provides by driving more recklessly. You can get his full findings here.

The bottom line is that the effects of risk homeostasis seem real, so that we can expect to see people compensate for decreased risks in one area by taking additional risks in another area. It’s still not clear, however, whether or not this compensating for decreased risks in one area leads to an overall gain or loss.

It might be the case, for example, that if you eliminate a risk that's causing $10 million in loss that you get people taking compensating risks that only cause $5 million in loss. If that's the case, then trying to eliminate the first risk makes sense. If the compansating risks cause $15 million in loss, however, then you're better off not trying to eliminate the first risk. Because it's impossible to tell which of these will happen for any particular risk, the best way to manage any given risk needs to be looked at on a case-by-case basis.

Can you crack a code?

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

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

The future of the Internet

A non-generative information ecosystem advances the regulability of the Internet to a stage that goes beyond addressing discrete regulatory problems, instead allowing regulators to alter basic freedoms that previously needed no theoretical or practical defense.

J. Zittrain, The Future of the Internet and How to Stop It

I recently heard that Jonathan Zittrain's book The Future of the Internet and How To Stop It was worth reading. There are supposed to be interesting insights into information security in this book, along with a discussion of ways that it either will or will not work on the Internet. I started reading this book, over my recent Christmas vacation but had to give it up after a while. There may be useful insights in this book, but I couldn't understand exactly what it was trying to say in many places. The quote above is from one of those places.

I can't quite understand stuff that's written this way. That doesn't mean that it's a bad book; it just means that it's written in a way that's not suitable for me. You can even download a free copy of the book here if you want to take a closer look at it. If the style of the quote above doesn't bother you, you'll probably be able to find those useful insights that others have found in this book.

After I put down The Future of the Internet and How to Stop It, I picked up a copy of The Cellar by Richard Laymon, which I managed to finish in a few hours. The Cellar is a horror novel from the '80s in which you learn what's been killing unlucky visitors to a small town in California. It has absolutely nothing to do with information security, but that turns out to be OK every now and then.

Classic crypto fun

It turns out that there's a much better way to kill a few minutes than looking at movies of cats playing with their favorite toys on YouTube. Instead, you can try a simulator of the classic Enigma machines, the devices that the Germans used to encrypt diplomatic and military communications in World War 2. The picture above may be a bit hard to see, but it shows that if you use the key "LWM" to encrypt the message "HELLOWORLD" with a three-rotor Enigma, you get the ciphertext "KSWKUXBXOV." This simulator also shows how the Enigma works. At each step, it shows you the path through the machine that creates each letter of ciphertext and how the rotors move to change the setup that the machine will use to create the next letter of the ciphertext. If you're even more interested, you can also find a paper that describes how to break the Enigma's encryption here.

Machiavellian software engineering

The term "Machiavellian" has come to mean behaviour that combines diabolical cunning with a ruthless disregard for morality, but this may be due to the fact that the Niccolò Machiavelli's irony was missed by many readers of The Prince. Supporters of this interpretation point out that all of Machiavelli’s other writings supported a more republican view of politics, the fact that he had been imprisoned and tortured on the rack by the Medici family to whom he dedicated The Prince, and that Casare Borgia, whom Machiavelli cited as a role model in this book, was widely known as a fool and a failure. If this interpretation is correct, The Prince is probably one of the most widely-misunderstood books ever written.

From our point of view, almost 500 years after Machiavelli wrote The Prince, it's impossible to know for sure whether or not he meant the book to be taken literally, but the fact that many people interpret it as a serious guide to politics shows that if he meant the book to be a satire, he was much too subtle. This shouldn't be too surprising, for even less subtle arguments can be misunderstood, and the origins of what's now know as the waterfall model of software development provides an interesting example of this.

Winston Royce summarized the lessons that he had learned in large government software projects in his 1970 paper "Managing the Development of Large Software Systems." This paper is often cited as the basis for the waterfall model, but Royce's discussion of software development in this paper certainly doesn't suggest that the waterfall model is a good one that should be followed. Although Royce did describe what came to be known as the waterfall model, he also noted that it is "risky and invites failure." He also suggested that a more iterative process would be better, a process much like what we call agile models today.

Thus Royce was even less subtle than Machiavelli - he was fairly clear in expressing his disapproval of what came to be known as the waterfall model. So we might wonder why the model that Royce described as being bad was widely adopted while the agile models which Royce described as being good were largely ignored for many years. And although cynics might be tempted to note a possible similarity between Machiavelli being tortured by the Medicis and Royce's work on large government contracts, it's unlikely that Royce’s paper was ever interpreted as satire. So we need to find another reason to explain the adoption of the waterfall model.

One reason that the waterfall model was adopted soon after Royce wrote his famous paper may have been that it’s much easier to understand and define than agile methods. It's relatively easy to write standards that define the use of waterfall-like methods, but doing the same for agile methods is very difficult. As early as 1974, for example, the US Navy had already used the waterfall model as the basis for their MIL-STD-1679 standard, "Weapon System Software Development." By 1995, this had evolved into the ISO/IEC 12207 standard "Software Life Cycle Processes," keeping a strong bias towards the waterfall model as it did. But while the more rigid waterfall process has found its way into several standards, the more complicated agile methods have yet to find the same level of acceptance by standards bodies, and this may be because agile methods are more difficult to understand and define than more rigid models are. It may even be the case that even though we can easily list general principles that they may follow, we still don’t exactly know how to define agile methods, and this makes creating standards for them extremely difficult.

Many of the early discussions of software development models were based on the experiences in large government projects, where rigid, hierarchical structures tend to be preferred, and this probably led to a bias that favoured such structures in managing software projects. Software project managers may also have just supported what they believed to be feasible in the large government software projects with which they were familiar instead of promoting what they really thought was the best way to manage their projects. Even if they believed that agile models were better, it may have been the case that it wasn’t practical to use these within the constraints of their projects, so that they may have accepted an alternative that was practical for them to use, hoping that it would at least reduce some of the problems that they faced.

The adoption of the waterfall model may also have been a reaction to the more chaotic processes that were common in the early days of software engineering. When these processes were seen to not be working well, a natural reaction may have been to try to impose a more rigid structure, and the waterfall model provided an easy way to formalize this additional structure. So the eventual return to agile models that we see today may have been caused by the realization that rigid structures also had shortcomings. Because agile models are also not perfect, we shouldn't be too surprised if the pendulum swings back towards more structured approaches in the future. If the past is an accurate guide to this, we might expect this to start in the next ten years or so.

So it may have been the case that software project managers didn't misinterpret Royce's first discussion of the waterfall model as satire. Instead, they may have adopted the waterfall model because it was relatively easy, fit within the constraints they were accustomed to and seemed to be an adequate solution to some of the problems that they faced at the time. The fact that Royce first described it in a less-than-positive way may have been ignored because of these perceived advantages. So early software engineers didn’t develop the waterfall model from Royce’s work – they probably developed it in spite of it.

Machiavelli's reaction to this would probably depend on his intent when he wrote The Prince. If he meant it to be taken literally, he would probably admire the audacity that early software engineers showed when they pointed to Royce's paper as the first description of the waterfall model. But if he meant The Prince to be interpreted as satire, he might be surprised by how writing that was even less subtle that his could be misinterpreted by its readers.

Forging certificates with the latest attack on MD5

There’s yet another development in the history of cryptographic weaknesses associated with the MD5 hash function. After showing that it’s not too hard to find a collision in MD5 and that it's possible to use MD5 collisions to create certificates with identical signatures, researchers have now shown how to use the weakness in MD5 to create a CA certificate that most browsers will verify as being valid. Many others have commented on this, so I won’t repeat what’s been said before. I will, however, mention two thoughts that relate to this new work that haven’t been mentioned by others yet.

The first relates to how serious this newly-demonstrated vulnerability is. This research shows that it’s feasible for hackers to create valid SSL server certificates. On the other hand, carrying out the attack that takes advantage of the weakness in MD5 requires a fair amount of sophistication. It’s definitely impractical for the typical hacker, although it’s probably practical for more sophisticated cybercriminals. On the other hand, I don’t expect it to be used any time soon. There’s so much sensitive information available to cybercriminals that there’s almost certainly a better way for them to get what they want that by using a web site with a forged SSL certificate.

Suppose that you’re a cybercriminal who wants lots of sensitive information to help you carry out your insidious plans. One approach that’s now available is to take the time and effort to carry a sophisticated cryptanalytic attack that lets you create a phishing web site that’s more likely to collect information for you. Another approach is to compromise a single backup tape that holds gigabytes of the very information that you’re after. It’s not that hard to get such backup tapes, and roughly half of them aren’t encrypted today, mainly out of concerns about how difficult the key management is that’s needed to encrypt and decrypt tapes.

One approach is hard; one approach is easy. If I were a cybercriminal, I’d probably take the easy alternative. Most cybercriminals would probably make the same choice, choosing to steal a tape instead of doing complicated cryptanalysis. Because of this, I don’t think that we’ll be seeing many phishing sites with forged SSL certificates any time soon.

The second thought relates to the computers used to carry out the clever attack on MD5. In this case, a cluster of roughly 200 PlayStation 3s was used. It seems that one PS3 provides the same computing power as about 30 PCs, so they're fairly useful for projects that needs lots of computing power.

Using PS3s for high-end computing isn’t new. Stanford’s Folding@home project, for example, has been using volunteers' PS3s to help calculate the shape of protein molecules since March 22, 2007. PCs greatly outnumber PS3s in the Folding@home project, but PS3s actually provide the biggest contribution of computing power of any platform.

Not too many years ago, big computing projects were almost exclusively done only by governments or by government-funded labs. But with inexpensive computing power like the PS3 provides, it’s now much easier for others to do the same computing-intensive research. The new MD5 research shows that doing cryptanalysis is now much more feasible that it once was. Can predicting the weather or designing nuclear weapons be far behind?