Superconductor

Limitations of chip and PIN

In the US, credit cards use a magnetic stripe to carry the information that's needed to carry out a credit card purchase. In other parts of the world, more sophisticated cards are used. These so-called "smart cards" actually contain lots of very advanced technology that protects the cryptographic keys that authenticate the card when its used.  

If you want to try to find a protected key using advanced tricks like measuring the timing of cryptographic operations or by measuring the power consumed by the card's processor while it's doing a cryptographic operation, for example, then these cards have built-in features to thwart you. They're not perfect, but they're much more secure than cards that use just magnetic stripes are.

If the US credit card market moved to smart cards, how much would it affect the total amount of credit card fraud? It certainly wouldn't eliminate it, because smart cards don't protect against all threats. They do nothing at all, for example, to reduce losses in card-not-present transactions, like you have when you buy something on the Internet.

It's even possible that moving to smart card wouldn't reduce the total amount of fraud at all. It might just move it from face-to-face transactions to card-not-present transactions. That's apparently what happened in the UK market when they moved from magnetic stripe cards to smart cards. This is described in "Can Smart Cards Reduce Payments Fraud and Identity Theft?" by Richard Sullivan, an economist at the Federal Reserve Bank of Kansas City. You can get the paper here, if you want to read it.

So moving to smart cards probably isn't a way to totally eliminate credit card fraud. It might not even reduce it if it just makes cyber-criminals move to different types of attacks. Based on the data from the UK, it might even not reduce it at all.

Would moving to smart cards reduce credit card fraud? Like any question in information security, this one also turns out to be more difficult than you might think. 

Fake identities from honeypots

At the National Cyber Leap Year Summit last week, I heard an interesting story. I haven’t found a reference that talks about this yet, so I’m still thinking of it as a rumor instead of a fact. The story that I heard was that information stolen from honeypots is starting to take on a life of its own.

Honeypots are fake targets that are designed to attract hackers. By watching how hackers attack the honeypots, the theory goes, we learn about how the attackers operate and learn how to counter them in the future. To make a target that looks interesting to hackers, researchers populate honeypots with fake data that’s designed to look as real as possible. The fake data might include names, addresses, Social Security numbers, bank account numbers, and so on. All of it fake.

The rumor that I heard was that hackers have taken the bogus information from honeypots and used it to create fake identities, and that these fake identities are now opening bank accounts, getting credit cards, and so on. It’s not hard to imagine fake identities getting preapproved credit card offers at their fake addresses, but nobody actually mentioned that that’s happening.

Yet.

To be an attractive target for hackers, a honeypot has to contain lots of bogus data, because few hackers are going to take the time and effort to hack a system steal a few identities. So if hackers have millions of fake identities from honeypots and these fake identities are actually taking on lives of their own, I have to wonder how many times this has happened. I’d guess that if it actually happened once it could just as easily happen a million times.

I wouldn’t even be surprised if some of these fake people were actually working for the government right now. That might explain a lot.

Using location data

One of the speakers at last week’s National Cyber Leap Year Summit was Jeff Jonas, the founder of the company that became IBM’s Entity Analytic Solutions in 2005. He talked about the amount of location data that’s available and what you can do with it. It was a very interesting talk. It seems that the funding for Jonas' technology originally came from In-Q-Tel, the organization that essentially acts like the venture capital arm of the CIA. You'll soon understand why they funded him.

It’s easy for wireless companies to track the location of the devices on their network. In the case of cell phones, for example, the E911 system provides both caller location and identification. Other technologies have similar capabilities, and it turns out that databases of location and caller identification are routinely sold to third parties. The data is anonymized (if that’s really a word) before it’s sold, but that apparently doesn’t really provide much protection because there are technologies available that can easily identify who caller 0123456789 really is, even though his true identity has been replaced with 0123456789.

It’s also apparently possible to identify a person from just a few pieces of location data. By tracking where your cell phone is during the day, for example, it’s easy to get a very good idea of where you live, where you work, and other similar information. With just a few pieces of such data it’s possible to determine who the person carrying the phone is.

It seems that every day we see more and more proof that Scott McNealy was right when he said, “You have zero privacy anyway. Get over it.”

Getting reliable data

At the National Cyber Leap Year Summit last week, the thing that the cyber-economics working group though was the most important is how to deal with the current lack of reliable data about information security. Right now, there’s really no reliable data on the frequency of security incidents, the effects of security incidents, the effectiveness of security technologies at mitigating risks, and so on. Without accurate data, it’s hard to determine what the best way to defend against both existing and future threats is, and the cyber-economics working group spent a significant amount of time talking about ways to ensure that better data is available.

Unfortunately, this particular working group had almost no representation from industry, so the most favored solutions weren’t ones that for-profit businesses would tend to favor. Instead, solutions like government-mandated reporting of security incidents and their effects were popular.

I hope that the government finds a way to collect more data about the nature of security incidents, but I also hope that they avoid any type of mandatory reporting. If they really feel that mandatory reporting is the best way to proceed, they should try it at government agencies first. If they can find a way to create a workable system of mandatory reporting that works there, then they might want to consider extending it to the people for which time is actually money.

Until then, they should rely on other ways to gather data. I don’t see any reason why a sampling of incident data isn’t almost as useful as all of the incident data, for example, and you can collect a sampling of incident data through surveys. Several thousand surveys is almost certainly less of a problem to American business that several million mandatory reports, and will probably give data that’s just as useful.

We definitely need more and more accurate information about the nature of information security incidents. But because we also don’t want to make gathering the data more damaging than the security incidents themselves, the government should be careful about requiring too much information from businesses.

The free rider problem, SSNs and PANs

The free rider problem has been studied extensively by economists. We get the free rider problem when we have a good or service that's free to others once it's been paid for once. If this happens, then the people who get the good or service for free have no incentive to pay for it.

This why, for example, that some things are paid for out of taxes instead of being privately funded. National defense is the most commonly-used example of this. Once you have a system of national defense in place, it protects you whether or not you were one of those that paid for it. Because of this, it would be hard to create a workable system of privatizing national defense because of the strong incentive for people to have someone else pay for it while still getting the benefits from it.

It certainly looks like Social Security numbers are another example of this. The government has created a unique identifier for people. It's hard and expensive to create a system that creates and manages such unique identifiers, so there's a strong incentive for others to use an existing unique identifier instead of creating their own.

Credit card numbers are yet another example of this. Many of the parties who process a credit card transaction need a unique identifier, and the credit card number is a handy one that happens to be readily available. And just like there's absolutely no reason why you need to use an SSN to identify people, there's absolutely no reason why you need to use a credit card number in this particular case. But because it's hard and expensive to create an alternative, there's no incentive to create an alternative.

Economists have proposed a number of ways of dealing with the free rider problem. Maybe some of them could be applied to Social Security numbers and credit card numbers. If we could eliminate the use of those numbers in inappropriate situations, we'd also reduce their exposure to cyber-criminals, and that's probably a good thing. The big question is which of the solutions that economists have proposed would actually be workable in the real world. I'm not sure that anyone has thought about that particular question much.

The National Cyber Leap Year Summit

The government’s current approach to cyber-security isn’t working. The government has apparently acknowledged this, and last week, held the National Cyber Leap Year Summit, a meeting that was sponsored by the White House Office of Science and Technology Policy (OSTP) and the Federal Networking and Information Technology Research and Development Program (NITRD).

This event was designed to bring together experts from academia, industry and government to find “game-changing” ideas and ways to implement them. I was one of the people from industry who were invited to participate in this event, so I spent last week at the Crystal Gateway Marriott in Arlington, Virginia, talking about how to change the government’s approach to cyber-security.

I was one of very few representatives from security vendors at the meeting, and I’m not sure how to interpret this. There were industry representatives, like people from the big government contractors, but including people like that isn’t really the same thing as including security vendors.

From one point of view, it’s good to see that Voltage is being recognized as being a thought leader in the area of cyber-security. We’ve certainly created our share of innovations and continue to do so. On the other hand, it was also a bit puzzling that more security vendors weren’t invited. Even vendors that aren’t known for lots of innovation have a solid understanding of the security market, what the current threats are and how their customers are dealing with them, and we definitely could have used more of this point of view at the meeting to balance the views of academics and government people.

We talked about five main areas at this meeting:

• Cyber-economics, or how to create the right incentives and disincentives that we need for cyber-security to succeed
• Digital provenance, or how to base trust decisions on verified assertions
• Health-inspired network defense, or how to move from forensics to real-time diagnosis of security problems
• Moving-target defense, or how to ensure that attacks work only once, if at all
• Hardware-enabled trust, or how to leverage hardware security to create a more secure computing environment

I’m not a big fan of management fads, so for me, the biggest downside to the meeting was the fact that the organizers tried to use the “colored hats” framework that Edward de Bono describes in his book Six Thinking Hats. Even this didn’t work out to badly, however.

The biggest problem was that even though the meetings went from roughly 8 am to 10 pm each day, that still wasn’t enough time to discuss any ideas in much detail. Because of this, many good ideas didn’t really get the attention that they deserve, and I hope that the organizers of the event will find a way to deal with this.

Over the next few days, I’ll be talking about some of the things that I learned at this meeting.

An end of an era

Today marks the end of an era. It's the day that the web cam on the coffee pot in the Trojan Room of the University of Cambridge Computer Laboratory was turned off in 2001, after roughly 10 years of operation. This was the first web cam. It was also probably one of more useful ones, and its demise is worth commemorating.

iCloud versus eCloud

I had some interesting discussions last week about cloud computing. I've always thought that some of the arguments for cloud computing don't make sense. If you're a large business, for example, you probably have the same economy of scale that a cloud provider has. This means that you may be able to provide the same service at the same price, but as an internal cloud (iCloud) instead of as an external cloud (eCloud).

From what I heard last week, this is turning out to be true: some large businesses are finding that they can provide a cloud service just as cheaply as a cloud provider can. This doesn't mean that there's no reason for cloud computing. It just means that iClouds can be just as useful as eClouds, and might even be cheaper in some cases.

Obstacles to identity management

When was at a security strategy meeting for a big bank last week, one of the big topics of discussion was identity management. It's probably fairly well known that almost no enterprise has a single directory infrastructure that they use. A typical enterprise actually has dozens of directories, most of which came packaged with various applications. Each of these applications has its own idea of what an identity is, which makes it very hard to create a single, unified directory that works for them all. It turns out that this is a fairly common obstacle to rolling out more advanced identity infrastructures, and there's no easy fix for the problem.

In addition to having its own idea of what an identity is, each application's directory also has its own set of errors that have been introduced over time. It's very expensive to correct all of these errors, but that's what you need to do to create a single, unified directory. And until every application's directory information is scrubbed, it doesn't make sense to move to a single, unified directory.

This is possible, but it's also very expensive, which means that nobody really wants to do it. The consensus at last week's meeting was, however, that until this is done, identity management technology really can't advance much. Getting funding for identity-scrubbing projects is apparently very hard, so we may not see this happen for a while.  

Bayesian Scouting

I recently heard some interesting statistics about Scouting. Apparently, even though only one in four boys join Scouting, three out of four of adults holding leadership positions in the business world (representing five percent of jobs) were in Scouting. When I heard this, my first thought was to apply Bayes' theorem. After all, we're given P(S|L), so I was curious to apply Bayes' theorem to find P(L|S), or to use the available information to find what the chances of a Scout ending up a future leader are.

We have that P(S) = 1/4, P(L) = 1/20, P(S|L) = 3/4, and calculate P(L|S) = P(S|L) P(L) / P(S) = 3/20. A similar calculation tells us that P(L| not S) = 1/60, so that it seems that boys who join Scouting are nine times more likely to end up as leaders than boys who don't.

I haven't seen that number before, so I'd guess that the Scouting organization isn't as big a fan of Bayes' theorem as I am.

Hyperjacking

Last week, I heard lots of talk about "hyperjacking," which was described as a new threat that we'll be facing soon. Hyperjacking is a hypothetical attack that goes after a computer that's running one or more virtual machines, like you might get in a cloud computing environment. The idea is that an attacker would target the operating system that's below the VMs, so that his attack program can run and the applications on the VMs above it will be totally oblivious to its presence.

I don't think that anyone's actually demonstrated hyperjacking yet, but it certainly sounds like an interesting idea. Maybe the move towards cloud computing will encourage hackers to move the idea from just idea to actual implementations. We'll probably hear more about this in the future.

First four vs. last four

Last week, I heard something interesting about credit card numbers. Someone that I was talking to claimed that a recent study showed that over 95 percent of people can be tricked into thinking an email is actually from their bank if the email includes the first four digits of their credit card number. We're used to seeing the last four digits being used this way, and that makes some sense, but the first four digits really aren't suitable for being used this way. 

In a 16-digit credit card number, the first six digits form the issuer identification number (IIN) that identifies the bank that issued the card. The next ninedigits are the account number, and the last digit is a checksum that's calculated from the previous 15 digits. In most cases, it's fairly easy to guess the IIN. There's a list of known prefixes to IINs here, and some of these are very easy to guess. In some cases, the first four digits are actually the same for fairly broad categories of cards.

I haven't been able to find the paper that this discussion was based on, but I wouldn't be surprised if it does exist. People in the payments industry know the structure of card numbers and know that the first four digits of a card number isn't a good way to authenticate someone. The average guy on the street probably doesn't know that, however, but that might need to change. Apparently, it's becoming necessary for people to learn more about payments processing than they really want to know.

Twin primes and RSA

I just noticed an interesting quirk in how the RSA algorithm works if you use twin primes for the p and q that are used to calculate the modulus N = pq. Twin primes are those that differ by 2, so instead of writing p and q, let’s write p and p + 2 so that N = p (p + 2) and we have that f(N) = (p -1) (p +1) = p² – 1.

Now let’s pick our public key to be e = p. Then we need that the private key d has the property that ed = 1 (mod f(N)). Note that d = p satisfies this because p² = 1 (mod p² – 1). So if we have that the modulus is the product of twin primes, then we can find a case where the public key and the private key are the same.

I doubt that this is the first time that someone’s though of this, but it was new to me.

Comparing key sizes

Not all cryptographic algorithms provide the same level of security for a fixed size of key. A 128-bit AES key provides roughly the same security as a 256-bit elliptic curve key or as a 3,072-bit RSA key. We need to look at exactly how the security provided by cryptography is defined to understand why this is true.

Leading cryptographic standards like FIPS 140-2 define the strength of encryption in terms of how much work it takes for an adversary to find the key that he needs to decrypt encrypted data. So if the work needed to recover a 128-bit AES key is roughly the same as the work needed to recover a 256-bit elliptic curve key or a 3,072-bit RSA key, then we say that encryption using each of these keys provides the same level of cryptographic strength.

In the case of a symmetric algorithm, it's easy to understand how much work is needed. An ideal symmetric algorithm is one for which there's no better way to recover a key than just trying all possible keys to see which one is the right one, and for an n-bit key, this takes 2ⁿ tries. In practice, this can be more difficult to understand than it sounds. A Triple-DES key, for example, actually has 192 bits, only 168 of which are actually used to encrypt or decrypt data (the rest are parity check bits). But for Triple-DES, there's a way for an attacker to recover a key in only 2¹¹² tries, so that the 168 bits of key that are used to encrypt data really only provide 112 bits of strength.

For an elliptic curve algorithm, it's slightly more complicated. There's an algorithm called "Pollard's rho algorithm" that can find an elliptic curve key, and this takes much less time than just trying all possible keys. It only has to try the square root of the number of keys on average. So instead of needing 2ⁿ tries, an attack based on this technique only needs about the square root of 2ⁿ tries, or 2^n/2tries. This is why a 256-bit elliptic curve key is about as strong as a 128-bit AES key: the work needed to find a 256-bit elliptic curve key (the square root of 2²⁵⁶, or 2¹²⁸) is about the same as the work needed to find a 128-bit AES, which also requires performing 2¹²⁸ operations.

With other public key algorithms, it's trickier. Suppose that you want to find an RSA key by factoring an RSA modulus into n = pq. There's a complicated algorithm called the "general number field sieve" that's fairly fast, and it can factor a 3,072-bit number with about the same level of work that it would take to try all 2¹²⁸ possible 128-bit AES keys. Because of this, we say that a 3,072-bit RSA key provides the same level of security as a 128-bit AES key.

The security crisis

An import part of understanding a risk is understanding exactly how often a particular loss-causing event happens. It's hard to get an accurate picture of some of these chances due to the way that some things are covered by the media. It's fairly clear that the foreclosure rate for houses is now much higher that it was in the past few years, but exactly how high is it? If you watch TV news, you'll see lots of pictures of Stockton, California, the city where the most foreclosures per capita are currently happening. And because of the media coverage, many people's understanding of the housing market isn't quite as accurate as it could be.

A few months ago, I did an informal poll of people, asking them what they thought the rate of foreclosures was in the US. The answers clustered around 20 percent, with a significant number of estimates being closer to 40 percent. On the other hand, the actual rate is more like 2 percent. It seems fairly clear to me that the way that foreclosures were reported in the media is responsible for the gap between perception and reality in this case.

And just like it's useful to know whether the foreclosure rate is closer to 20 percent or to 2 percent if you're making public policy decisions, it's useful to know how serious some of the risks are that information security addresses if you're trying to figure out how to best spend your security budget. It's hard to get an accurate estimate of foreclosure rates from what you see on TV, and it's probably just as hard to get an accurate estimate of the severity of information security risks from the media.

There's certainly not as much accurate information as we'd like about security threats, but you don't need to make your IT investment decisions based on wildly inaccurate information. Basing decisions to elect politicians based on what the media shows us is bad enough. Don't make the same mistake with your information security purchases.

Are you secure or are you safe?

Charlie Miller, the Mac expert who won the Mac hacking contest at CanSecWest for the past two years, had an interesting comment about the security of Macs. He said that Macs are safer than Wintel PCs, but they're not as secure. That's an interesting distinction.

According to Miller, the lack of effective security products for Macs easily makes them less secure than a Wintel PC. He also claims that there aren't many attacks against Macs because hackers just haven't bothered to create them. He claims that if hackers spent the time and effort to target Macs, they'd find that it's actually easier for them than targeting Wintel PCs. This means that Macs aren't as secure an PCs.

On the other hand, the fact that there are actually fewer attacks against Macs makes them safer than a PC. So even though hackers could exploit then if they wanted to, they don't actually do it. Because of this, the chances of a Mac being hacked are actually less than the chances of a PC getting hacked. This makes them safe, even though they're not secure.

So Miller's distinction seems to be that you're secure if you can't get exploited, and you're safe if you won't get exploited. The fact that many businesses didn't start using security technologies until regulatory compliance forced them to tells me that they thought that they were safe, even though they weren't secure, although they probably wouldn't have described it exactly that way.

Conservation of money

A while back I noted that if you find a metric for security that acts like you'd expect such a metric to act, then the metric essentially has to be information-theoretical entropy. I just read "The Physics of the Shannon Limits" by physicist Neri Merhav, a paper that shows the connection between information-theoretical entropy and thermodynamic entropy. The basis for thermodynamic entropy is conservation of energy, so I had to wonder if there's a similar conservation law that you can use to explain a metric for information security that's just entropy in disguise.

The second law of thermodynamics roughly says that entropy increases over time, but it doesn't have to. If you have energy, you can decrease entropy. Maybe there's a similar principle for security: that it tends to decrease over time. But what you need to do to increase security is to spend money. Maybe there's some conservation of money principle that you can use to create a principle that's just like the second law.

Another non-alternative to encryption

There seems to be yet another technology vendor that’s trying to claim that their approach to protecting data is better than encryption. They claim that this is true for the following reasons: that future processing power makes today’s encryption too weak; that key management is a big, unsolved problem; and that you still have problems with disclosure laws if you lose encrypted data. Key management is indeed still an unsolved problem, but the other two of these claims aren’t even close to being true.

As I’ve mentioned before, aside from assuming that quantum computing eventually becomes a reality, there’s absolutely no way to make a set of reasonable assumptions that lead you to believe that it will ever be possible to defeat the protection provided by 128 bits of cryptographic security. Even if you scale up today’s most powerful computers by factors of millions, you’ll find yourself watching the continents collide as they drift around the surface of the Earth or the Andromeda galaxy collide with the Milky Way as you wait for this hypothetical computer to find a single key.

There are well-defined standards for exactly how strong a key to use, and this is based on when you’re going to encrypt the data and how long you need it to be protected. In the case of 128 bits of strength, this is anticipated to be good for the foreseeable future, so the claim that future processing power makes today’s encryption too weak isn’t even close to being true.

(Even if you assume that quantum computing eventually becomes a reality, it doesn’t really affect symmetric algorithms that much. It just cuts the number of bits of security in half, reducing 256 bits of strength down to 128 bits of strength, so that 256-bit symmetric keys are still secure if quantum computers are available.)

The claim that losing encrypted data will still cause you disclosure problems also isn’t true. Disclosure laws require you to notify the victims of a breach if you lose unencrypted data, not if you lose encrypted data, and this makes perfect sense. Encrypted data is indistinguishable from random bits: if you give an adversary who has unlimited computing power both a ciphertext and a block or random bits, he can’t find an efficient way to tell the difference between the two. So not requiring companies to disclose the loss of encrypted data is perfectly reasonable. It would be just as meaningful to require them to notify people about the disclosure of the output of a random number generator.

The products that people are trying to sell that can act as alternatives to encryption may have advantages over encryption in some situations, but these certainly don’t relate to the alternatives being more secure than encryption or the nature of existing disclosure laws.

I just don't get this one

Here’s another case where I just don’t get what the excitement is all about. In this case, it’s around the announcement of a new technology that identifies sensitive information on its way to a monitor and substitutes some sort of inoffensive pattern in place of the sensitive data. This technology is called Masking Gateway for Enterprises, or MAGEN.

I’m sure that this new technology is very impressive, but I’m also fairly sure that there’s going to be a better way to spend your security budget, like on encryption technology that protects the data both on its way to the monitor and after its displayed. You can even do this while keeping your encrypted data the same format at the unencrypted data, so integrating the encryption into existing applications really isn't that hard. You can encrypt a credit card number using format-preserving encryption, for example, and the encrypted credit card number will look just like an unencrypted one.

I haven’t heard of monitors being a big source of data leakage. What problem is this technology really trying to address?

More on visualizing data breaches

How much do big data breaches contribute to the overall number of records exposed? This picture, which is based on the breaches in the OSF's database since the beginning of 2006 might give an idea of how important the contributions of the big ones are. The area of each circle is proportional to the number of records exposed in each breach. Can you find your favorite data breaches here?

 

A BMI for security

It would be nice if there was an easy way to quantify security with a single number. If you had a security score of 85 last week and ended up with a security score of 91 this week, that might justify thinking that all of the time and effort that you spent on rolling out that new DLP system was finally paying off. Or it might just end up being a game that you play, spending your budget on things that increase your security score, even if they don’t really increase the level of security that your organization is providing. On the other hand, it’s probably impossible to find a single number that works well for every organization. It’s probably even impossible to find one that works well for most organizations. My experience with the body mass index (BMI) leads me to believe that this is the case.

I’ve only been in the “normal” range for the BMI at one point in my life, and that’s when I was training for long course triathlons, races that combine a 1.2-mile swim, and 56-mile bike race and a 13.1-mile run. I was training about four hours a day back in those days, and I was just at the upper end of the “normal” range for the BMI, even though I was incredibly thin. The problem is that I’m a bit more muscular that the average guy on the street. When I backed off to only two hours of training per day, I crept back up into the “overweight” range, even though I was still incredibly thin.

I wasn’t doing long-course triathlons at that point, but I was still doing Olympic-distance races (1.5 km swim, 40 km bike, 10 km run) and marathons. I was extremely thin, had a resting heart rate in the 40s, and probably had an extremely low chance of developing any sort of obesity-related disease despite my BMI saying that I was overweight. Apparently the BMI wasn’t designed to account for people who were both thin and muscular at the same time.

I’d guess that any single number that you can come up with has a similar limitation. A single number might be able to give you a rough idea of how good something is, but that estimate is probably only accurate for the sample that was used to create the single number. So if we create a way to quantify security by looking at companies in the financial services industry, it might be a useful indicator for companies in the financial services industry but not for ones that make consumer products. These industries operate in very different ways, and what makes sense in on may not make sense at all in the other.

It seems unlikely that we’ll ever be able to create a single number that quantifies how much security that we have, but I often wonder how close we can come. Can you find three or four numbers that quantify security well? What if you go up to 12? At some point you should be able to capture enough information to be useful. It’s just not clear that the number of numbers that you need to do this is small enough to be manageable.

Null terminate with extreme prejudice

I've been asked several times about Dan Kaminski's recent hack against X.509 certificates, so here's my explanation of it. I'd say it's not really an attack against X.509 certificates, but an attack that takes advantage of how some web browsers work. It all has to do with null-terminated strings.

A string is a sequence of characters. The string "hello," for example, is the sequence of characters 'h,' 'e,' 'l,' 'l,' and 'o,' which would be encoded as the sequence 104, 101, 108, 108, 111 if we're using the ASCII encoding rules. One way to indicate the end of a string is to add a special character to the end of a string that marks its end, and a common way to do this is with the null character, the character that encodes the value 0. To tell where the end of the string "hello" is, for example, we would add an additional null character to it so that it's represented as the sequence 104, 101, 108, 108, 111, 0, so that the five-character string "hello" is stored as a six-character null-terminated string. Programs that handle null-terminated strings would recognize the 0 as marking the end of the string, and ignore anything after that, and Dan Kaminski found a clever way to take advantage of that fact.

Suppose that you're a hacker who owns the domain yourehacked.com. Because you're the legitimate owner of this domain, you can get SSL certificates that identify your servers. You might want to get a certificate that can be used to authenticate www.yourehacked.com, for example, so that your hacker friends can tell that they're really on your web site and not on a web site run by law enforcement or some other part of the government. If you've set up subdomains to help you manage your web site, you might want to get an SSL certificate for something like www.hacks.yourehacked.com. If you're really creative, you might even request an SSL certificate for www.somebank.com%00.yourehacked.com, where I've indicated the null character by "%00," and Kaminski's hack takes advantage of how some browsers will display a URL like this one.

If a web browser assumes that a URL is a null-terminated string, when it looks at this URL, it's going to stop at www.somebank.com and ignore the rest of it. The part of the browser that handles certificates, however, handles more general strings, and it uses a tag-length-value (TLV) format to do this. In a TLV format, there's a tag that tells you that the following bytes are a string, then there's a length value that tells you how long the string is and then there's the value of the string itself.

This takes a bit more overhead than just handling null-terminated strings does, but it also lets you handle more general values. It also happens to be the way that information in a digital certificate is encoded. Because it's designed to handle more general strings, the part of the browser that handles certificates won't have any problem handling the URL www.somebank.com%00.yourehacked.com, but the parts of the browser that expect null-terminated strings will. In particular, a browser might display this URL as "www.somebank.com" in the its address bar even though it's really connected to part of the yourehacked.com site. So if a hacker can get people to go to this URL, they may think that they're really on the somebank.com web site even though they're really on the yourehacked.com web site. After all, there's a valid SSL connection, and the URL www.somebank.com appears in the address bar of their browser.

Apparently right after Kaminski gave his talk that described this hack, there was a flood of requests at public CAs for new certificates that contained null characters, but I haven't heard that any of these certificates were actually issued. We'll probably hear more about that in the next few weeks.

No bucks, no Buck Rogers

 

The Buck Rogers comic that ran in American newspapers from 1929 to 1965 is probably responsible for creating, or at least popularizing, many ideas that are taken for granted in today's science-fiction. Things like rocket ships, anti-gravity technology, traveling to other planets, and dealing with their non-human inhabitants that find human women irresistible. I was recently reading a collection of these classic comics when I noticed another element of advanced technology that appeared in the Buck Rogers comics, and that's paying by credit.

In comic number 694 from 1931, Buck Rogers and Wilma Deering have made it to the legendary undersea world of Atlantis. When they're shown the technological marvels that make it such an advanced place, universal payment by credit is one of these. Apparently, in 1931, paying by credit was one of those things that seemed an advanced idea that might become true at some point in the future, and had enough of a "wow factor" to justify its mention in the comic.

I don't know if people in 1931 read Buck Rogers and marveled at what it would be like if you could buy anything that you need using credit, but it seems that that's one of the few things from Buck Rogers that has actually come to be. We don't have flying belts or rocket ships, and we haven't met any aliens who have an unexplained attraction to Earth women, but we certainly have credit cards that are accepted more places than they're not. Maybe we'll have the others some day, too.