Superconductor

More on the Cryptographers Panel misunderstanding

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

Why is this?

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

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

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

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

The PBA attack on RSA

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

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

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

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

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

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

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

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

Misunderstanding what was said at the Cryptographers Panel

As usual, the Cryptographers Panel at the RSA Conference was interesting. Unfortunately, some of the remarks made by the panelists seem to have been taken out of context by people who apparently didn’t understand the context to begin with. This has apparently led to some people claiming that cryptography is totally broken and shouldn’t be used to protect sensitive information.

As Dave Barry would say, I’m not making this up.

The remarks that Adi Shamir made about attacks on AES seem to be at the root of this misunderstanding. Let’s look at exactly what Shamir said and see how close it comes to saying that cryptography is totally broken. You can find a recording of the talk here if you missed the RSA Conference last week. Some of the question and answer period has been edited out, and I’m not exactly sure why that happened.

In his opening remarks Shamir notes that progress has been made in the cryptanalysis of AES. Last year, Alex Biryukov and Dmitry Khovratovich found a related-key attack against the full AES-256 algorithm that has both time and memory complexity of 2^99.5.

This attack is much better than an exhaustive search, but it’s also not even close to being feasible. (If that’s not obvious, do a quick Google search to find out roughly how much information exists in the world today and compare it with the 2^99.5 memory required by this attack.) If that’s the best that an attacker can do, then you’re still very safe. The fact that the way that standards require you to use AES also eliminates the possibility of actually carrying out a related key attack should make you feel even safer. If you use AES like the standards specify, then this attack can’t be used against you.

Shamir also mentioned an attack on AES-128 that was also found by Biryukov and Khovratovich that runs in 2⁴⁵ time. That’s so fast that it’s practical to do on a typical PC. On the other hand, Shamir also mentions that this attack also assumes that you use AES-128 in a way that is forbidden by the AES standard. In this case, the attack works if you use AES-128, but try to fake AES-256 using the shorter 128-bit key. Again, this isn’t allowed by the AES standard, so it shouldn’t really come as a surprise that it doesn’t work well. Once again, it you use AES like the standards specify, then this attack can’t be used against you.

So I’m not sure exactly how someone heard Shamir’s remarks and interpreted them as saying that encryption is fatally flawed and isn’t suitable for use in protecting sensitive information. It seems to me that a better interpretation is that you really need to follow the standards that specify how encryption is used. If you do that then it provides protection that’s incredibly secure. On the other hand, if you decide to not follow these standards and instead decide to invent new ways to use encryption that haven’t had any sort of independent review, then there’s a possibility that you can do things that dramatically reduce the security that the encryption provides.

There are definitely innovative ways to use encryption safely. These will always come with a peer-reviewed proof that the new technique is secure. If you use one of these, encryption will still provide an essentially unbreakable level of security. But if you use techniques that don’t have such a proof of security then you’re taking a significant risk. Maybe that’s too subtle an interpretation for the opening remarks at the Cryptographers Panel, but it’s certainly more accurate than saying that cryptography is totally broken and shouldn’t be used to protect sensitive information.

Cloud computing at the RSA show

While too many of the pitches on the expo floor at this year's RSA Conference were about how various products or services could make you PCI DSS compliant, way too many of the talks this year were about cloud computing. Few of these talks really seemed to have anything new and interesting to say. Some seemed to be just thinly-veiled pitches for a cloud computing offering from vendors who had essentially bought speaking slots at the show with their sponsorship dollars.

Now, while cloud computing can be a very useful technology in some cases, it's also one that can create some interesting security challenges. But while talk after talk went on and on about the security challenges of cloud computing, one fairly obvious approach was rarely mentioned: encrypt your data before you put it into an external cloud computing environment.

The RSA Conference started out as a conference about cryptography. Despite this bit of history and the fact that cryptography can go a long way towards solving some of the tricky problems that cloud computing can cause, it was rarely mentioned at this year's conference. This struck me as being a bit ironic.

Wednesday at the RSA Conference

If the number or size of the parties put on by vendors at this year's RSA Conference is any indication, the information security industry has fully recovered from any affects of the recent recession. Luckily, I recently saw an episode of Mythbusters that made surviving these parties much easier than it was in previous years.

The Mythbusters episode that I saw compared the hangover caused by drinking from beer to the hangover caused by drinking liquor. Somewhat surprisingly, they found that beer causes a much worse hangovers.

Armed with this research, I developed a strategy to deal with the numerous parties at this year's RSA Conference: stick to martinis and drink no beer. Drinking martinis also helps in another way. Martinis taste terrible so you're much less likely to drink too many of them. After a single sip from a martini, you're usually more than happy to wait a long time before taking another sip. Beer, on the other hand, doesn't have this built-in rate-limiting feature, so you're more likely to drink too much of it.

This strategy worked perfectly. By sticking to martinis I was easily able to keep my blood alcohol content well within the limits allowed for driving, and the next morning I felt no obvious effects from the parties at the RSA Conference the previous night.  

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

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

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

HOT ROD: Universal greeting?

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

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

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

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

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

KUP: See, the universal greeting works every time.

Transformers: The Movie, 1986

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

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

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

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

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

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

Monday at the RSA Conference - Miranda?

The exhibit hall of the RSA Conference was open for a couple of hours last night, so I got a chance to walk around and see what vendors were talking about this year. I have to say that I was not impressed in lots of cases - some vendors seemed to actually be moving backwards instead of forwards. It almost reminded me of the horror novella Miranda by John R. Little that won the 2008 Bram Stoker Award for Best Long Fiction. (No - this book has nothing to do with the planet Miranda from the movie Serenity.)

The protagonist of Miranda is a man who moves backwards through time instead of forwards. The book opens with him returning to life in a hospital at age 65 and ends, well, I'd hate to ruin a truly excellent book, so I'll just let you use your imagination. 

The entire book reinforces this backward-through-time theme. It starts with chapter 15 and counts down to chapter 1, for example, and the pages are also numbered in the reverse order. For me, this produced a particularly chilling effect because you could tell exactly how many pages were left of the protagonist's life. You can easily look at the last page of a book to see how many pages are left before the story is going to end, but that doesn't seem to provide the same effect that the reverse page numbering in Miranda does.

In any event, the parallel between a man moving backwards through time and the vendors who seemed to be moving backwards instead of forwards definitely struck me when I made my first circuit through the expo hall of the RSA Conference this year. I doubt that the vendors that I saw yesterday will suffer the same horrific end that the protagonist of Miranda did, but I doubt that things are going to work out well for them in the long run.

The RSA Conference begins

Today's the first day of the RSA Conference. If you can manage to cut through the marketing hype that surrounds this event, you can actually learn all sorts of useful things at it. This year, there are two parts of the conference that look particularly interesting.

The first is the Cryptographer's Panel, which will be on Tuesday at 10:30 am. Brian Snow will be on this panel, along with Whitfield Diffie, Martin Hellman, Ron Rivest and Adi Shamir. Hearing any of these people talk is always an excellent opportunity to learn all sorts of interesting things, but hearing Brian is probably the best opportunity of all. Before he retired, Brian was the Technical Director of the Information Assurance Directorate of the National Security Agency, sort of like the NSA's chief scientist on the defensive side, so he knows what really happened in lots of cases where others can only speculate.

Want to know about what really happened in the early history of public-key cryptography? Listen to Brian talk about it. Want to know about what really happened in the US government's pre-dot-com-era efforts to discourage the use of cryptography through export controls? Listen to Brian talk about it.

Another part of the conference that will probably be very interesting is Phil Rogaway's presentation "Format-Preserving Encryption: How to Encipher CCNs, SSN, and the Like," which will be on Friday at 10:20 am. It was a paper by Phil and John Black that was part of the Cryptographer's Track at the 2002 RSA Conference that gave the first proofs of security for format-preserving encryption, so he's been working on it from the beginning. Today, the technology is now commercially available and is being used by lots of businesses to help them comply with the PCI DSS without causing too many problems with their complex, legacy environments.

Format-preserving encryption is what's described in the FFX mode of AES that NIST is now working on, and here's even a part of the draft of the X9.119 standard: Retail Financial Services — Requirements for Protection of Sensitive Payment Data — Part 1:  Using Encryption / Tokenization Methods that's dedicated to describing how to use the technology to protect payments information.

Phil's presentation isn't part of the Cryptographer's Track this year, so it will probably be at a level that's accessible to people who don't like to worry about all of the details about exactly how format-preserving encryption works and the details of the proofs of why it's secure. Instead, it will probably focus more on system-level issues like why it's useful and how to use it. If that's of interest to you, then you'll probably to make sure that you get a chance to hear Phil talk about format-preserving encryption.

The right stuff

I recently read an article in The Washington Post about how the US government is having a hard time finding qualified information security people. One of their proposed solutions is to take existing government employees and retrain them to make them information security specialists. This is almost certainly a bad idea.

When I worked for the government, we had a similar staffing problem at the end of the Cold War. At that time, we had lots of Russian linguists but not enough people in technical fields. To solve this problem, the government decided to to retrain the Russian linguists into engineers and other technical jobs. It didn't work very well.

Imagine you're a government employee who has been translating Russian for maybe 10 or 20 years, and you're suddenly told that you need to retrain to become an engineer. You probably became a Russian translator because of your particular skills and aptitudes, and those skills and aptitudes are very different from those needed to succeed as an engineer. You may have the right stuff for a particular job, but that right stuff doesn't necessarily translate into the right stuff for another job.

I taught some of the classes that were supposed to do this retraining, and it didn't seem to me that this effort was going to work very well. This really shouldn't have surprised anyone.

Your typical cryptographer, for example, has probably spent several years studying the math that you need to understand the foundations of cryptography. In the government, our rule of thumb was that it took about three years on the job before a person with that background could make significant contributions on the job. This is definitely not the sort of training that you can fit into a class or two, and it's definitely not the sort of thing that you can easily pass on to mid-career Russian linguists who are stressed about losing their job if they can't learn material for which they have absolutely no aptitude.

Let's hope that the government remembers how well the previous attempt worked, and doesn't try it again today. Our attempt at cross-training people didn't work very well at the end of the Cold War, and I'd expect a similar attempt to fail today.

Making change

My wife went out for pizza last week and came back with an incredible story. She ordered two pizzas on-line and went to the store to pick them up. When she arrived at the pizza store their computer was down. When she paid with cash, she was surprised to see the cashier pull out a calculator that she used to calculate the change due from my wife's purchase. The cashier explained that they had to use a calculator to figure out how much change to give a customer and that they would get fired if they were caught making change without the use of the calculator.

I'd guess that the pizza store didn't just make the use of calculators mandatory for no reason. They almost certainly did this because their employees couldn't do it accurately without a calculator.

It's somewhat popular these days to criticize the exit exam that California high school students have to pass to graduate. Opponents like to say that it forces teachers to teach just the material that's covered on the test, and that this reduces the overall quality of education. Supporters of the exam maintain that it's just testing basic skills and that its requirements are quite reasonable. If pizza stores have to require their employees to use calculators to make change accurately, I'd guess that the exit exam isn't testing enough.

The fact that people can pass the exit exam and still can't make change accurately may account for the following joke:

Question: What is 2+2?

Answer: A question on the California high-school exit exam

A discussion with a lobbyist

I recently had an interesting discussion with a lobbyist, one of those people who hang around Washington and try to influence laws on behalf of whoever's paying them. I met this particular lobbyist at a standards meeting, and we had an interesting discussion about the behavior of politicians. This particular lobbyist told me that he found that most politicians are actually fairly reasonable most of the time and try to get reasonable laws passed and are generally open to reasonable compromises to get that to happen.

At least that's until an issue starts making headlines. At that point, everything changes. That's when people start voting along party lines and the chances for reasonable compromises seem to go out the window.

The discussion that I had was actually about the lobbyist's efforts to influence Congress to pass laws changing how credit card companies do business in the US, but his comments seem applicable to more situations that just that one. Like the stuff that's making the headlines these days.

What are they thinking?

There's a new social networking site that just made me think, "What are they thinking?!" This is Blippy, which apparently lets you broadcast to the entire world what you're buying. What worries me about this is the fact that the payments information that this service needs to use is fairly sensitive. How are they getting this? Is the process secure?

Here's what the Blippy web site says:

Blippy is a fun and easy way to see and discuss the things people are buying.

Automatically share your favorite purchases from iTunes, Amazon, Zappos, Visa, MasterCard, and more.

Yikes! Are they actually getting data about purchases from Visa and MasterCard? This is one (of many) social networking site that I definitely won't be signing up for.

Factoring RSA-768

It was recently announced that a team of cryptographers (Thorsten Kleinjung and Kazumaro Aoki and Jens Franke and Arjen Lenstra and Emmanuel Thomé and Joppe Bos and Pierrick Gaudry and Alexander Kruppa and Peter Montgomery and Dag Arne Osvik and Herman te Riele and Andrey Timofeev and Paul Zimmermann) managed to factor a 768-bit RSA modulus. Although the technical work required to do this was very impressive, I'd say that this really wasn't a very newsworthy event.

According to the Implementation Guidance for FIPS 140-2, a 768-bit RSA key provides almost 70 bits of strength, so that it's about 13,700 times stronger than the 56-bit keys that the EFF DES Cracker was able to crack back in 1998. Taking into account the progress in technology over the past 12 years, it shouldn't be surprising to anyone that a massively-parallel network of computers can crack a 70-bit key today. It's so unsurprising that I have to wonder if funding projects like this one is really a good idea. Aren't there better uses for the resources?

HR 2221 - the DATA Act

The House of Representatives passed HR 2221, the Data Accountability and Trust Act, last month, a bill that tries to set up a nation-wide, common way to handle data breaches. I really don't like the way the US government feels the need to make almost-clever names for laws that also create related acronyms (CAN-SPAM, DATA, etc.), but that doesn't make the content of HR 2221 any less interesting.

Here's how the House summarizes this bill:

Data Accountability and Trust Act - Requires the Federal Trade Commission ( FTC) to promulgate regulations requiring each person engaged in interstate commerce that owns or possesses electronic data containing personal information to establish security policies and procedures.

Authorizes the FTC to require a standard method or methods for destroying obsolete nonelectronic data.

Requires information brokers to submit their security policies to the FTC in conjunction with a security breach notification or on FTC request.

Requires the FTC to conduct or require an audit of security practices when information brokers are required to provide notification of such a breach.

Authorizes additional audits after a breach.

Requires information brokers to:

(1) establish procedures to verify the accuracy of information that identifies individuals;

(2) provide to individuals whose personal information it maintains a means to review it;

(3) place notice on the Internet instructing individuals how to request access to such information; and

(4) correct inaccurate information. Directs the FTC to require information brokers to establish measures which facilitate the auditing or retracing of access to, or transmissions of, electronic data containing personal information. Prohibits information brokers from obtaining or disclosing personal information by false pretenses (pretexting). Prescribes procedures for notification to the FTC and affected individuals of information security breaches.

Sets forth special notification requirements for breaches:

(1) by contractors who maintain or process electronic data containing personal information;

(2) involving telecommunications and computer services; and

(3) of health information.

Preempts state information security laws.

You can find the full text of the bill here.

Similar bills (HR 958, HR 3997, and HR 4127) have been introduced before, but none made it out of the House before this one.

There's a similar bill making its way through the Senate – S 1490, the Personal Data Privacy Act of 2009. Previous efforts in the Senate (S 495, S 1332 and S 1789) didn't go anywhere. It will be interesting to see how the House's attempt at addressing the problem of data breaches is received by the Senate.

Video of relay attack on a smart card

I just came across an interesting video clip yesterday. This clip shows a relay attack on a chip-and-PIN smart card that lets attackers perform fraudulent transactions. It's definitely proof that nothing is as secure as you think it is. Not even hardware-based cryptography.

A relay attack lets an adversary impersonate someone else during an authentication protocol. To do a relay attack, an adversary doesn't need to understand the underlying authentication protocol. If the authentication protocol is based on cryptography, they don't need to worry about the cryptography at all.

Relay attacks aren't a new idea. They've been known at least since 1976 when John Conway mentioned the idea in his book On Numbers and Games.  Here's a rough idea of how a relay attack works.

Suppose that I'm sitting in my car in the parking lot and you want to open the door to my office using the proximity card in my wallet. To do this, you get the door to issue the challenge that it issues to proximity cards when they're used to open it. You collect this wireless signal from a place close to the door and pass the signal to a friend manning another transmitter close to my car. The second transmitter passes the challenge to my proximity card and then passes the response from my card back to you where you use the response to authenticate to the door.

It's not much more complictated than that to do a similar attack against some smart cards that use a cryptographic challenge-response protocol. That's what's shown in this video.

In a relay attack on a chip-and-PIN smart card, you can't just intercept wireless signals like you could do with a relay attack on a proximity card. In this case you need to control a PIN entry device as well as a smart card that's modified to carry out the attack. 

A PIN entry device probably isn't too hard to get. You can get almost anything on eBay these days, after all. On the other hand, the modified smart card isn't something that's likely to go unnoticed. Most merchants will probably figure out that something's not right if you try to make a purchase with a smart card that has wires coming out of it that attach to a nearby laptop. But even if this attack isn't something that we'll probably see cybercriminals using on a wide scale, it definitely shows that designing secure systems is hard.

Google AdWords for the Key Management Summit

Because I'm on the program committee for the 2010 Key Management Summit, I knew that there's a Google AdWords campaign happening now to increase awareness of the event. Despite this, I was surprised to see the following ad when I last read my Gmail:

Key Management Summit - 2010.KeyManagementSummit.org - IEEE Conference on Encryption Lake Tahoe, NV. May 3-7 2010

While I'm probably the right kind of person to target with this ad, I have to wonder exactly how Google chose to show it to me. I don't get work-related email at my Gmail address, and the email that's in my Gmail Inbox right now is stuff like announcements of end-of-year sales that various small presses are having (up to 75 percent off in some cases), information about my kids' Boy Scout camp for next Summer, and confirmations that various Christmas gifts have shipped. There's nothing there that's even remotely related to encryption or key management.

Maybe the logic behind AdWords is even more clever than you might first think. Or there might be terms like "encryption" or "key management" hidden somewhere in those emails about Christmas gifts.

Another strategic industry?

GAME SHOW HOST: Karl Marx, your final question, who won the FA Cup in 1949?

MARX: The workers' control of the means of production? The struggle of the urban proletariat?

GAME SHOW HOST: No. It was in fact, Wolverhampton Wanderers who beat Leicester 3 to 1.

Monty Python's Flying Circus

According to an article on the Forbes web site, the Chinese government has decided to ban foreign companies from investing in domestic on-line gaming operations. I seem to recall learning that Communists have some suitably-Communist term for industries that are vital to economies, although I can't quite recall what this term is right now. I certainly never expected this term to be applied to games like World of Warcraft.

The report from the National Cyber Leap Year Summit

The recommendations from the information security experts (and so-called experts like me) who attended the National Cyber Leap Year Summit is now available. I found three of these recommendations particularly interesting.

On page 73 in section 3.8 of the National Cyber Leap Year Summit 2009 Participants' Ideas Report you'll find the idea Global Identity-Based Cryptography. Interestingly enough, this idea came out of a group that I wasn't part of, so someone who's not from Voltage thought this idea was important and also convinced the other members of his group that it's important. Curiously, one of the perceived obstacles to the adoption of IBE is "no proven technology." That's definitely proof that I wasn't in the working group that came up with this idea.

If I was there I would have mentioned that there are now at least 10 million users of IBE worldwide, a number that's probably roughly equal (if not greater than) the number of users of PKI. The technology is definitely a proven one. The other perceived obstacles to the adoption of IBE also don't agree with the actual adoption of the technology, but the fact that it's "not proven" is probably the least accurate of these perceptions.

On page 103 in section 6.3 of this report you'll find the idea Global Post-Quantum Secure Cryptography Based on Identity, or IBE that's resistant to attacks that you can run on a quantum computer. I'm not sure that this idea is really worth putting on a research agenda. I don't think that we'll see quantum computers with enough q-bits to actually beat the key sizes that are currently used any time soon. I actually doubt whether we'll ever see these.

On page 113 in section 6.8 of this report you'll find the idea Removing Barriers to Entry for Crypto Products into Federal Use. Here's the description of this idea:

Many commercial security technologies are unavailable for Federal use even though they are well accepted and widely deployed in the private sector. These technologies often allow dramatic cost savings and efficiency gains over older technologies, but Federal agencies are unable to use them because the technologies have not received the necessary certifications and approvals. In some cases, the existence of rigorous, formal proofs of security should eliminate the need for the long certification and review process and allow Federal agencies to receive the same benefits that the private sector is now realizing. A decade or more is too long for Federal agencies to wait to realize the benefits of new security technologies. Let's find a way to get new technologies used more rapidly.

The report goes on to say

Provable security has made the "wait and see" model unnecessary in many cases. If there is a peer-reviewed formal proof of the security of a technology, that should be enough to get approval for Federal use. If the proof is correct then the technology is secure. Why wait ten years or more if that's the case?

I find it hard to argue with that claim. If there's a proof of security then one of two things has to be true: either the scheme is secure or there's an error in the proof. There's no other possible option. So if there's a proof of security, why not let government agencies use the technology?

Here's what the report proposes as an "action plan" for this idea:

NIST should determine a way to quickly approve provably-secure technologies for Federal use and should review existing regulations and identify ways to allow provably secure technologies within them. This should involve, as a minimum, granting a blanket IATO to new encryption technologies with peer-reviewed proofs of security, and adding provably-secure public-key encryption technologies to the list of techniques that are allowed by FIPS 140-2. In the long run, standards and policies should be changed to allow the rapid adoption of new technologies that are provably secure.

And here's how the report recommends that the government start doing this:

Within 90 days, NIST should define and implement a way to approve provably secure technologies for Federal use. Within 180 days, a pilot of one of these technologies should be started at a Federal agency.

This report came out fairly recently. Let's see if NIST actually does what this report recommends

The HITECH act and compliance trends

The Health Information Technology for Economic and Clinical Health (HITECH) Act that recently went into effect has provisions that encourage, but don't require, covered entities to encrypt PHI. The Interim Final Rule (45 CFR Parts 160 and 164) that implements part of the HITECH Act requires notification of the unauthorized use or disclosure of unencrypted PHI that "poses a significant risk of financial, reputational, or other harm" to an individual.

Some conspiracy theorists seem to believe that this wording was included to allow businesses to avoid the high costs of breach notifications by arguing that their analysis shows that their breach didn't cause a significant risk of harm. A more reasonable explanation is that similar language dates back as far at the original Privacy Act of 1974, and is already included in the existing state breach notification laws.

But if the breach notification requirements of the HITECH Act aren't there to let businesses freely violate our privacy while giving us the illusion of it being protected, why are they there?

The breach notification requirements of the HITECH Act are probably best understood as part of a trend that's slowly but surely increasing the protection that sensitive data needs to have. This started with laws and regulations that required organizations to protect sensitive information, although the exact way in which they protect it is typically very flexible. It then moves to requiring notification of breaches of unencrypted sensitive information. At this point, encryption still isn't required, but there's a strong incentive to use it to avoid expensive breach disclosures. The next step is to require organizations to encrypt sensitive information.

The HIPAA Privacy Rule was the first step in this process for PHI. It required health care organizations to protect PHI, although they could implement this protection in many ways. The HITECH Act is the next step. It essentially requires the notification of breaches of PHI that isn't encrypted. In the future, we will probably see a federal law that actually requires the encryption of PHI. This has already happened in some states.

In 2008, Nevada law (NRS 597.970) required the encryption of Nevada residents' sensitive information when it's transmitted outside a business' secure network. The Massachusetts encryption law (201 CMR 17.00) did the same for Massachusetts residents a short while later. Legislators are now considering similar laws in other states, and similar data encryption laws will probably become widespread over the next several years. It's now hard to avoid complying with these state laws, and it's going to get even harder in the future.

How to comply with these laws in a reasonable way is still an unsolved problem. Legislators want businesses to protect sensitive information, but not at cost that's too high to be practical for a business that needs to be profitable to survive.

Encryption is notoriously hard and expensive to use, but a combination of newer technologies and motivated IT departments is leading to solutions that are much more practical than they were a few years ago. Technologies like identity-based encryption, for example, are at least a factor of three less expensive to own and operate than the aging PKI technology that dates back to the dot-com boom. That's often enough of a difference to make encryption practical where it once wasn't.

Once the states find what works and what doesn't, it's likely that the federal government will raise the bar and require the encryption of all PHI, and when they do this, they will probably base exactly what they require on the lessons that the states have learned. Let's hope that this happens soon.

There has been lots of media coverage of the recent data breaches that have exposed millions of credit card numbers to hackers. But while it's relatively easy to cancel a compromised credit card and get a new one, it's not really practical to cancel and get a new medical history. Once it's compromised, it's compromised forever. Because of this, PHI deserves to have strong protection, and encrypting PHI is the best way to do this. The breach notification requirements of the HITECH Act only encourage encryption, but they're a good step towards ensuring that PHI gets the protection that it deserves.

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.

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.

Is AES secure enough?

There's been a lot of discussion in the past day or so about the security of the AES encryption algorithm. There's a paper by Alex Biryukov and Dmitry Khovratovich that describes an attack against AES-256 that can be done in much less time that brute-force exhaustion: 2¹¹⁹ trial encryptions instead of 2²⁵⁶. That's a huge difference. Is AES now so weak that we need to worry about it?

Absolutely not.

The attack that Biryukov and Khovratovich found also takes lots of data for it to work. Their attack that can be done in 2¹¹⁹ time also takes the same amount of data: 2¹¹⁹. That's a lot of ciphertexts.

The best estimates that I've seen say that the entire world produces a few exabytes of data per year. This estimate is actually from a few years ago, so it isn't that current. Let's suppose that the amount of data being created doubles each year. If that's the case, we probably have a few zettabytes of data being created per year right now.

A zettabyte is 10²¹ bytes, or about 2⁷⁰ bytes. That's a lot of data, but it's still a long way from 2¹¹⁹ ciphertexts. This means that an attack that takes that much data is totally impractical. Even if we assume that all of the data in the world is being used in an attack that's trying to recover a single AES key, it's still not enough. It would take roughly the amount of data that the entire world will produce in the next 50 years or so to get the amount of data that we'd need. And even then, the amount of time required is still prohibitive.

It's interesting that Biryukov and Khovratovich found a significant weakness in AES, and their work may give useful insights into how to design better symmetric encryption algorithms, but it's not the sort of weakness that anyone can actually use to actually recover data that's encrypted with AES.

The 2010 Key Management Summit

The web site for the 2010 IEEE Key Management Summit is now up. This event will be held on May 4-5, 2010 in Lake Tahoe, Nevada, and will be collocated with the IEEE Symposium on Mass Storage  Systems and Technologies.

We're already looking for speakers for this event and hope to finalize the list in roughly November of this year. So if you're interested in presenting at this event, it's not too early to send in your submissions.

A new type of standard

On May 7 there was a meeting in Plano, Texas, to discuss the plans for developing a standard for end-to-end encryption. This standard is a new work item that was recently approved by the X9 Accredited Standards Committee, the group that creates information security standards for the financial services industry. The meeting was jointly sponsored by Heartland Payment Systems and the Merchant Advisory Group, both of which clearly showed that they're now taking the security of credit card information very seriously.

The usual suspects showed up at this meeting - a combination of banks and security vendors. What was good to see was that some businesses also showed up that accept credit cards for payment for either goods or services. This was a good thing, and it should happen more often.

Most standards groups comprise just the vendors who make whatever technology is being standardized. This is usually bad, because vendors tend to create standards that reflect how they want to do things instead of how their customers want things to be done. But because their customers usually don't take part in the standards process, that's they best that the vendors can do.

Because the customers usually don't get involved in developing new standards, it's sometimes hard to feel sympathy for them when then end up with a standard that doesn't reflect their needs. So the fact that the merchants who will be using the end-to-end encryption standard are interested enough to get involved in developing a standard for it is definitely a good sign. There seems to be a good chance that the unprecedented level of involvement by the end users of the standard will end up making the standard fairly useful. It will be interesting to see how this standard develops over the next few months.

Update on the Hannaford suit

In a recent post, I mentioned how a US District Judge was considering whether or not consumers had the necessary standing to sue Hannaford Brothers over the data breach that Hannaford suffered in 2008. There's now been a ruling on this that may have interesting implications for both security and privacy.

The judge essentially ruled that if consumers didn't suffer any financial damage from the data breach then they have no damages to recover, and their claims were thrown out. In most data breaches involving credit cards, consumers end up suffering no financial damages - those are typically absorbed by the merchants that accepted the fraudulent transactions on the stolen credit cards. Because of this, consumers who have their credit card number stolen may find their options limited if they don't actually suffer any losses from the breach.

Here's how the Judge summarized his thoughts:

But if the merchant is not negligent, or if the negligence does not produce that completed direct financial loss and instead causes only collateral consequences—for example, the customer’s fear that a fraudulent transaction might happen in the future, the consumer’s expenditure of time and effort to protect the account, lost opportunities to earn reward points, or incidental expenses that the customer suffers in restoring the integrity of the previous account relationships—then the merchant is not liable.

This ruling may make data breaches much less costly for the businesses who suffer the breaches, and may leave the PCI DSS as the only effective tool to use to get businesses to take the security of credit card information seriously.

Key management at the RSA Conference

There are lots of free copies of the latest issue of InformationWeek magazine floating around at this week's RSA Conference. I picked one of these up and looked at it because of the article that was featured on the cover: “Standards Matter.” Here's an interesting quote from this article:

If we’re not careful, standards for nascent technologies could be so splintered as to be worse than none at all.

This reminded me that the first meeting of the OASIS Key Management Interoperability Protocol (KMIP) Technical Committee is going to be this Friday. KMIP is probably the best example that you can think of for splintering standards that might turn out to be worse than none at all. The IEEE Security in Storage Working Group (SISWG) is already well underway with the P1619.3 Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data. The most recent project plan that I’ve seen for this standard shows it being completed late this year. SISWG plans to define two versions of its key management protocol in the P1619.3 standard: one that’s XML-based and another that’s TLV-based.

Oddly enough, an XML version and a TLV version also seems to be the plan for KMIP, which certainly should make you wonder exactly why KMIP is really needed. I seem to recall that the whole point of developing a standard for key management was to ensure interoperability between products from different vendors, and having two different standards for the same thing seems like the worst possible way to do this.

It certainly looks like IBM is responsible for the splintering into multiple and non-interoperable key management standards that the InformationWeek article talks about. They’re really the one behind the KMIP effort, even though they’re also involved in SISWG. It would be interesting to hear what their reason for essentially killing the possibility of interoperable key management was. Didn’t they like the direction that P1619.3 was moving in? If that’s the case, why didn’t they just speak up and make their opinion known? And do they really think that having two non-interoperable key management standards benefits anyone?

These questions shouldn't just be on a security vendor's blog; they're the sorts of questions that IBM's customers should be asking them. Maybe IBM has a good reason for starting KMIP, even though there seems to be a standard well underway that solves the same problem that KMIP does. If that's the case, then they certainly deserve support from those who will benefit from KMIP, which includes many security vendors and their customers. If they don't have a compelling reason, however, their customers should clearly explain to them that they want interoperable key management that they can use enterprise wide, and that the vendor community should act accordingly.

Another part of the InformationWeek article that caught my eye was this:

Technology must be developed and deployed with live customers before functionality can be standardized.

This is also relevant to the development of key management standards. Many vendors have shipping key management products. As I mentioned in an earlier post, the recent Burton Group report on enterprise key management seemed to indicate that only a few vendors (Voltage, RSA/EMC, nCipher, NetApp and SafeNet) have much experience in developing key management products that do much more than manage keys for their other products.

If this assessment is right, you might wonder how useful IBM’s thoughts on how to do key management will be. Their approach may be great for managing keys that IBM products need, but they may not be as useful for a general-purpose key management standard. It will be interesting to follow the development of KMIP to see if this turns out to be true or not.

The RSA conference starts today

Today's the first day of the RSA Conference, where I'll be all week. If you believe Paul Stamp, I should be wearing sandals, long hair and a backpack and I should be hanging out at the Thirsty Bear.

He's actually not that far off.

The Rockefeller-Snowe bill

The Rockefeller-Snowe bill that's being considered by the Senate is supposed to "address our nation’s vulnerability to cyber crime, global cyber espionage, and cyber attacks that could potentially cripple the United States’ critical infrastructure." Some parts of what this bill tries to do make sense, while other parts don't. I'm particularly concerned about how the federal government wants to create national information security standards.

As I've mentioned before, complying with government standards is usually enough to avoid being considered negligent. This means that if the government creates this proposed national information security standard and businesses comply with it, there's a good chance that they wouldn't be considered negligent if their security is defeated by a hacker as long as they had implemented government-approved security. This could be a problem because "government-approved security" and "good security" don't necessarily mean the same thing.

The government is often fairly slow to react to new developments. Because of this, if they're creating and maintaining a national standard for information security, this standard probably wouldn't address the most recent threats. This means that it's easy to think of scenarios where security researchers would discover new attacks, but businesses would be free to ignore the threat posed by them until the government standard was updated to reflect the new threats. And businesses would be relatively free of liability if they did this.

It's also easy to believe that a government standard wouldn't allow the most recent advances in security technology to be used until they're considered "approved" in some way. This already happens now. Some security vendors are caught in a Catch-22 in which the government can't use their technology until it's approved for government use, while being widely used by the government is a requirement for the new technology getting this necessary approval. If this type of reasoning is applied to more than the government market, it's easy to see how the Rockefeller-Snowe bill could easily kill innovation in the information security industry.

Hackers, of course, wouldn't be constrained by the same government regulation that businesses would, so they would continue to create new and innovative types of attacks. In the long run, this would lead to a situation that benefits absolutely nobody. Except, perhaps, the hackers.

That's why I'm concerned about where the Rockefeller-Snowe bill may be taking us. At least one part seems to have a good chance of this being in the wrong direction.

The transcript of yesterday's House hearing

FYI - the transcript and video of yesterday's hearing in the House of Representatives' Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology that tried to answer the question “Do the Payment Card Industry Data Standards Reduce Cybercrime?” is now available.

Does the PCI DSS reduce crime?

Today I listened to the podcast of the hearing before the House Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology on the topic of “Do the Payment Card Industry Data Standards Reduce Cybercrime?”

Lots of the testimony was very predictable.

• The PCI SSC stuck to their position that no PCI DSS compliant organization has ever suffered a data breach, and dodged questions about exactly how much feedback on the standard from banks and merchants they’ve actually listened to.

• Visa stuck to their position that lots of issues with the PCI DSS aren’t their problem because they’re really issues between merchants and acquiring banks.

• Retailers complained about the cost of complying with the PCI DSS. They also want increased security in the form of smart cards, and they want the credit card brands to pay for it.

• The PCI SSC and Visa dodged the question about metrics that indicate success or failure of the PCI DSS by saying that’s information that acquiring banks need to track.

To her credit, the Chair of the Subcommittee, Yvette D. Clarke (D-NY), did seem concerned that the costs of complying with the PCI DSS are significant yet there is no data available that shows that the PCI DSS is actually having any measurable benefits. Acquiring banks have that information. They should probably be more forthcoming with it.

It's legal in Florida

The term 'corpus delicti' is technical, and means the body of the crime, or the substantial fact that a crime has been committed.

Melville Davidson Post, The Strange Schemes of Randolph Mason

Even though the RIAA’s ad campaigns say it is, copying your friends’ music CDs isn’t theft. That doesn’t mean it isn’t illegal. If you copy a CD you may be committing a crime, but that crime isn’t theft. One important element of the corpus delicti for theft is that property is lost by the owner, and this clearly isn’t the case for copying music. If you copy a CD, the owner of the music doesn’t lose their property, so you haven’t committed theft. What you’ve done is violate copyright law.

So suppose that a business dumps lots of documents containing sensitive personal information in their dumpster. Have they committed a crime or not, and if it’s a crime, exactly what law did they break?

In Sarasota, Florida, for example, a company recently dumped lots of documents containing sensitive information including Social Security numbers and driver's license numbers into their trash. Workers at a nearby business noticed this and called the police, but when the police arrived, they found that no actual crime had been committed. Apparently disposing of sensitive information in a way that makes it easy for it to be compromised isn’t actually against the law in Florida.

What's even stranger about this incident, is that it has been established that there's no reasonable expectation of privacy when things are left in the trash. That's what California v. Greenwood established in 1988. So it's apparently legal to dump sensitive information in a place where there's no expectation that it will stay private. At least it is in Florida.

Another big data breach?

It looks like there has been another data breach at a large credit card processing operation. The details haven’t been made public yet, but it’s already being discussed on web sites that track data breaches. As soon as the forensics experts finish collecting the evidence that they need, there will probably be a public announcement that describes exactly what happened. We’ll probably find that the operation that has hacked has passed their PCI DSS audit yet was still vulnerable to hackers. This shouldn’t be too surprising to anyone by now. It probably shouldn’t even be considered newsworthy any more.

As I’ve mentioned before, there are good reasons to require any business that handles credit card transactions to be PCI DSS compliant. Credit card numbers are the main target of the determined cyber-criminals that are part of the multi-million dollar underground economy in sensitive information. The number of stolen credit card numbers outnumbers other sensitive information that’s traded by cyber-criminals by roughly a factor of 20 to 1, so they’re much more popular than even information like ATM PINs or bank account numbers.

Even though many politicians seem painfully oblivious to it, the law of supply and demand affects all markets, even those in stolen sensitive information: as the number of credit card numbers stolen in data breaches has increased dramatically over the past few years, the value of each stolen credit card number has dropped just as dramatically. This means that cyber-criminals now need to get millions of credit card numbers from a single hacking operation to justify the risk and the expense of such an operation. This seems to have led them to target credit card processing operations instead of merchants, and they’ve apparently been fairly successful at this, despite the increased level of security that the PCI DSS have required. This is probably because the evolution of the PCI DSS wasn’t designed to keep up with the current threat.

The first version of the PCI DSS didn’t require much more than what are considered best practices for information security. The subsequent versions increased the level of security required, and future versions will probably increase it even more. This has been a gradual and incremental process, and it clearly hasn’t kept up with the threat that professional cyber-criminals pose. As long as this process stays gradual and incremental, it seems likely that the cyber-criminals will be able to stay ahead of the security that PCI DSS compliance requires. What’s probably needed is a bigger step forward in security, and the combination of encryption and key management is probably the way to make that step.

The current version of the PCI DSS requires encryption of sensitive cardholder information, but it doesn’t require particularly strong key management processes, even though strong encryption and key management provide the basis for protecting sensitive information against even the most determined cyber-criminals. That’s how national governments protect their diplomatic and military secrets, after all. It seems to have worked fairly well for them, and there’s no reason to believe that the same model can’t also be applied to protecting other types of sensitive information. Any other way seems to be too weak to stop determined adversaries.

If the PCI Security Standards Council is serious about protecting sensitive cardholder information, and there’s no reason to believe that they’re not, we’ll probably see strong encryption and key management required in future versions of the PCI DSS. Until then, we’ll probably see more of the large-scale data breaches that have been in the news recently.

That's why we have standards

There's a story in The Local, a web site that has news from Sweden in English, that talks about the problems that the Swedish air force is having with their new JAS 39 Gripen aircraft. Apparently Sweden uses a proprietary protocol to communicate with older aircraft, and the newer models use the NATO standard for encrypted communications. This causes problems because but no other equipment that Sweden uses supports the NATO standard. That means that the new Swedish aircraft can't communicate with Swedish units on the ground unless they do so in the clear. D'oh!

It seems that standards are only useful if you actually follow them.

An idea that won't work

The recent story by The Sunday Times about the energy cost of using Google for a search seems to have been revealed as an exaggeration. We'll have to wait a while and see which people remember more - the correction or the original inaccurate claim:

Performing two Google searches from a desktop computer can generate about the same amount of carbon dioxide as boiling a kettle for a cup of tea, according to new research.

That's not just wrong – it's obviously wrong. The Times eventually added a few extra words to their original article that tried to clarify what they actually meant, but it still looks like a case of people trying to use statistics who shouldn't be using them. The fact that this article created such a stir may tell us that one of the ways proposed to combat spam may be impractical due to environmental concerns. This is the idea that one way to stop spam is to force senders of email to pay a tax in the form of lots of computation when they send an email.

The problem is, of course, that the computation that would be needed to send an email could also be quantified in terms of carbon dioxide. Imagine the uproar if the following was claimed about this anti-spam technique:

Sending a single email can generate the same amount of carbon dioxide as boiling two gallons of water, according to new research.

So it certainly looks like the idea of paying tax in computing power won't fly as a means of preventing spam these days. It's never been a very popular idea, but it certainly looks like the anti-spam researchers need to come up with another idea or two.

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.

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.

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?

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?

2008 Dubious Data Awards

Information security is a field in which it's often frustratingly difficult to get accurate and useful data. Much of the data that is widely quoted isn't actually accurate. We've mentioned this before when we talked about the misperceptions around the insider threat and the cost of managing passwords. And even if you have accurate data, the fact that technology changes rapidly means that the field of information security also changes rapidly as new vulnerabilities are discovered and old ones patched.

It looks like having statistics that aren't quite accurate isn't limited to just information security. There are enough cases of the improper or misleading use of statistics to justify a group of researchers forming STATS, a non-profit, non-partisan research organization affiliated with George Mason University. The mission of STATS is to point out the common misuse and abuse of statistics. The STATS web site has both quick summaries that describe cases where statistics aren't used quite as accurately as they could be as well as longer case studies. Both are interesting reading.

STATS just released the 2008 installment of their Dubious Data Awards. None of this year's awards seem to relate to information security, but they're still interesting to read about. We should certainly be skeptical of any data that's used to support either the sale of a product or a public policy decision. In both of these cases, there's little incentive to present a balanced, unbiased view of what's really what.

NRS 597.970

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

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

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

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

2. As used in this section:

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

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

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

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

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

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

UPDATE: From the WSJ - October 16th, 2008

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

Putting it into perspective

The potential government bailout of the US banking industry is big news these days, and it's widely reported that this will probably require about $700 billion of government funding. That's a lot of money. Its so much money that it's somewhat trendy today to make comparisons that give this number some meaningful context.

$700 billion is roughly equal to the GDP of Taiwan. Or it's roughly 12 times Bill Gates' fortune. It's also almost five times the $150 billion cost of the bailout of the US savings and loan industry that happened in the 1990s.

On the other hand, $700 billion may not be that bad, at least compared to other costs. The Sarbanes-Oxley Act alone might have imposed even bigger costs on US businesses, for example. One study estimated the total costs of the Sarbanes-Oxley Act to be roughly $1.4 trillion. This estimate was reduced to only $1 trillion in a more careful follow-up study, but even the smaller figure is still a huge amount.

So although $700 billion is certainly a lot of money, it may not be that much more that the costs imposed by some government regulations.

Why key management?

There's lots of talk these days about key management. It certainly looks like lots of it is from vendors trying to position themselves as leaders in key management, although it's not always clear what they mean by that. So what exactly is key management and why should you care about it?

A cryptographic key is much like the combination to a safe. If you have the combination, it's easy to open a safe, but it's hard to open one without the combination. Similarly, if you have the right key, decrypting encrypted data is easy, but it's impractical without this key. But if you're careless with the combination to your safe, someone else can easily find it, and once they have it, the protection provided by the safe is compromised. Similarly, the cryptographic keys that you use to encrypt data need to be handled carefully. If you're careless with them then the protection provided by cryptography can be essentially eliminated. Key management covers all the details of how to handle keys carefully enough to ensure that this does not happen. It ensures that you don't do the cryptographic equivalent of writing the combination to your safe on a Post-it note and sticking it to the wall next to your desk.

An example of why key management is important can be seen in the recent news of ATM PINs being hacked. The news stories that covered these security breaches didn't give much detail about exactly what happened, but you can be fairly sure that the cryptography itself wasn't broken. That's just too hard to make it worth doing. On the other hand, there have been cases in the past where ATM systems have suffered security breaches, and these breaches have been caused by poor key management. That's probably what happened in the recent cases of PINs being hacked, too.

ATM systems have been hacked when key installation, generation or storage has not followed the relevant standards developed by the X9F subcommittee of the Accredited Standards Committee X9, the group that defines information security standards for the financial services industry. There have also been cases where inappropriate access to hardware security modules has made it possible for hackers to get keys that they shouldn't have been able to get. None of these is involves an attack on the cryptographic algorithms; they're all attacks that take advantage of poor key management. Keys weren’t handled carefully enough, and hackers took advantage of the careless processes.

So encryption alone isn't enough to protect sensitive data. It's part of a good solution, but it’s not the entire solution. To get a complete solution you also need good key management. It's almost always much easier for hackers to defeat key management than to defeat cryptography, so that’s probably where they'll focus their efforts. They'll attack your key management not your encryption. This means that to to protect your sensitive data you need to ensure that your key management is done carefully and securely. That's why you should care about key management.

The Key Management Summit

It will soon be time for the IEEE Key Management Summit, which will be held September 23-24 in Baltimore, Maryland. It will bring together academics, customers and key management vendors to discuss the requirements for key management technology and how the evolving key management standards can work together, at least that's the plan. It looks like it might not quite work out as well as the organizers had hoped – it looks like almost everyone coming is from a security vendor. This means that we won’t be getting much of the customers' point of view on key management at all.

That's disappointing. I'll be attending the event, and the panel discussions with customers were the part that I was looking forward to the most. It's hard to find out what customers really want without talking to them, and I was hoping to use these panel discussions to get a better idea of what people are looking for in key management products.

After the customer panels, my favorites are probably a toss-up between the talks by NSA and NIST and the panel discussion about the different key management standards. NSA seems to influence the thinking at NIST, and the thinking at NIST seems to influence the rest of the world, at least when it comes to information security. Because of this, I'd like to hear what their thoughts are on the subject.

The panel discussion about the different key management standards might also be interesting. There are already a number of standards out there on key management, but these focus more on what to do, not on how to do it. Because of this, they really don't provide the level of detail that vendors need to make interoperable products. There are three main standards for key management that are being developed now that will actually allow the creation of interoperable products, and each has their own set of strengths and weaknesses.

The Provisioning of Symmetric Keys (KEYPROV) working group of the IETF is working on the Dynamic Symmetric Key Provisioning Protocol (DSKPP). This lets you initialize a device with a symmetric key, but without using any public-key operations. It's an interesting and useful idea, but one that seems to have rather limited uses.

The Enterprise Key Management Infrastructure (EKMI) Technical Committee of OASIS is working on the Symmetric Key Services Markup Language (SKSML), an XML-based protocol for managing symmetric keys and the policies that govern their use. This standard seems to just represent the work of a single small company, and has little support from other vendors. Because of this, I don't think that it will be very widely adopted.

The Security in Storage Working Group of the IEEE is working on the P1619.3 Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data. This one looks like a winner – it solves a pressing problem and has lots of vendor support. On the other hand, the progress of the standard has apparently been crippled recently by politics and the inability of the working group to make the simplest of decisions. If the working group can overcome these difficulties, this standard probably stands the best chance of being successful.

So I'm looking forward to seeing the panel discussion on standards to see how the various groups position their work relative to the others. It will be particularly interesting to see how the comparison between SKSML and P1619.3 turns out. Those two seem to have a bit of overlap, but the working groups that are developing them will almost certainly have an explanation prepared that explains how the two differ. I'm looking forward to hearing what they have to say.

Why I don't watch the Olympics

I used to enjoy watching the Olympics on TV, but I don’t any more. This is probably because of my experience in sports. I used to compete in triathlons. The best that I ever managed to do was finish just behind the first-place woman. That's probably not a bad performance for the average guy on the street, but it's not really competitive with the winning men.

It turned out that there were other triathletes that I simply had no chance at all of beating. I just didn’t have the right stuff while the guys who managed to win races did. This meant that no matter how hard I trained, there was no way that I could ever be as good as they were. The people who have the ability to win triathlons seem to be born that way, and if you don’t end up with the right genes, it’s out of your hands. Winning triathletes train hard, but they also have an advantage that the rest of us can’t match.

Other sports seem to be this way too, and once I realized this, the Olympics lost some of their appeal. The people who win Olympic medals aren’t just dedicated and hard working. They’re also the lucky ones who happen to get the right genes.

Public-key cryptography is a bit like an Olympic medalist in some ways, at least when compared to symmetric key cryptography. It does some things much better and cheaper that symmetric key cryptography can ever do them.

Using SSL, for example, you only need a single public/private key pair for the server. That’s enough to let anyone in the world authenticate the server and set up a secure connection to it. You could duplicate this functionality with symmetric cryptography but you probably wouldn’t want to actually do it. It’s just too hard and too expensive. Just like an Olympic medalist has an advantage that average athletes will never be able to compete with, public-key cryptography has an overwhelming advantage over symmetric cryptography in this application.

Some public-key technologies seem to have definite advantages over other public-key technologies. Elliptic-curve cryptography has some advantages over some other public-key technologies, for example, because it's more secure and more efficient. The use of elliptic-curve algorithms in the NSA's Suite B cryptography is probably proof that it has won the battle with the older technologies. The fact that it took about 20 years to win this battle, however, probably indicates that its advantages over the older technologies are not that great.

Identity-based encryption, one of the newer public-key technologies also has its own set of advantages over older technologies. Because it lets you use an arbitrary string as a user's public key, there are no problems with key look-up. Because it makes short-lived keys practical, it also provides an easy way to work around the problem of key validation that other public-key technologies have. Because it requires only a single connection to a server to look-up of a set of mathematical parameters before it can calculate any public key, it's particularly useful in distributed computing environments where connections are routinely lost.

Identity-based encryption seems to be having fairly rapid success. The first secure and practical identity-based encryption scheme was invented only seven years ago, but there are already over 10 million users of the technology. Its fairly rapid success probably indicates that it has important advantages over other public-key technologies. It might be a small advantage, like the difference between an Olympic gold medalist and an Olympic silver medalist. It might be a big advantage, like the big difference between winning triathletes and me. Its rapid adoption and success makes me think that it has proven to have a fairly significant advantage, but only time will tell if this is true or not.   

Convergence may be a bad idea

"Convergence" is again a hot topic. In the past, it meant the trend of IP networks and telephone networks to move towards common technology. Now it refers to the trend of integrating information security groups and other corporate risk management organizations. There are good reasons for doing this, but a closer look at some aspects of information security may indicate that this may not be such a good idea.

Three of the major security professional organizations, ASIS International (ASIS), Information Systems Audit and Control Association (ISACA) and Information Systems Security Association (ISSA), recently sponsored a study on the convergence of information security and risk management. The result was the 2005 report Convergence of Enterprise Security Organizations by Booz Allen Hamilton, which discussed the trend of convergence and the reasons for it.

The desire for a single organization that's responsible for all aspects of regulatory compliance is one driver for convergence. Another is the migration of more corporate assets to information technology. This has caused a change in what the most valuable assets of businesses are and a corresponding change in the focus of risk management. These reasons seem fairly compelling, and seem to allow for more cost-effective risk management strategies. On the other hand, a closer look at information security casts some doubt on whether this strategy will be effective in the long run.

The fundamental problem is that the factors that are used to quantify a risk – the probability of an event happening and the loss that accompanies the event – are almost always never known in information security. In information security, it's often difficult to make estimates that are even close to being accurate. What is the probability of one of your e-mails being intercepted and read while it's on the Internet? If this happens, how much loss does it actually cause?

This means that the usual techniques of risk management don’t work very well on the problems that information security deals with. On the other hand, applying information security methodologies, where decisions are often made without any reliable data at all, to other risk management functions will also probably result in poorly-managed risks.

The best solution is probably to understand the differences between the types of risk that exist and to manage them differently. If you're doing that, does it make sense to merge the two functions into a single organization? Unifying information security and other corporate risk-management organizations may not necessarily be a good idea.

Yikes!

It looks like a hacker was somehow able to penetrate Red Hat, get access to the keys that they use to sign their code, and include bogus OpenSSH packages in some versions of their software. Fortunately, this problem was caught fairly quickly, and you can now download clean versions of the affected software as well as a tool to check to make sure that you haven't been compromised.

I'd assume that the hackers went after their highest priority targets first, which in this case happened to be OpenSSH. That's an interesting choice, but I'm not sure that I would have done the same thing. If you were a hacker and had a chance to change just one package, which one would it be?

How many Nigerian scammers are there?

In a recent article in The Sydney Morning Herald, a Nigerian official tried to make it seem that not that many Nigerians try to pull Nigerian scams on people. He claimed that of the roughly 140 million inhabitants of Nigeria, less that 0.1 percent are involved in these scams. That doesn't sound too bad, does it?

Wait a minute! Just 0.1 percent of 140 million people is still 140,000 people. Microsoft has roughly 91,000 full-time employees; Intel has roughly 86,000. So saying that less that 0.1 percent of Nigerians are involved in these scams just limits the number of people involved to the size of some of the world's biggest companies. That's hardly encouraging.

Spam, spam, spam, spam

"No one in this world, so far as I know — and I have researched the records for years, and employed agents to help me — has ever lost money by underestimating the intelligence of the great masses of the plain people."

H. L. Mencken, "Notes On Journalism," Chicago Tribune, September 19, 1926

A recent study estimates slightly more that 29 percent of Internet users have bought something after clicking on a link in a spam e-mail. That's right - over 29 percent. Our in-boxes are flooded with spam because it's profitable!

The astounding thing isn't just that people are buying things advertised by spam, but that they're buying things like V!agara or R0lex watches and applying for m0rtgages. Would you really trust an on-line merchant that can't even spell the name of their product correctly? Apparently more than one in four people don't have a problem with that.

As much as I hate to say it, it looks like H. L. Mencken might have been right.

The system seems to work

The system seems to work some of the time. Maybe even most of the time. The latest proof of this is the ruling today by a federal judge that overturned the previous ruling that had prevented three MIT students from discussing the results of their research that had discovered vulnerabilities in the payment system that the Massachusetts Bay Transportation Agency (MBTA) uses.

The students only got into legal trouble because they were helpful enough to discuss the results of their research with MBTA before openly discussing it at DEFCON. So if things had not worked out this way, the message that hackers would have gotten is that it’s best to not warn people of potential vulnerabilities before publicly discussing them. We’re probably very lucky that that scenario was avoided by today’s ruling.

New Cyber Crime bill passes Senate - Identity Theft Enforcement and Restitution Act

A new act - the Identity Theft Enforcement and Restitution Act of 2007 was passed by the Senate Committee on the Judiciary. Introduced by Senator Patrick Leahy, the Chair of that Committee, last October, the bill's purpose is “to enable increased federal prosecution of identity theft crimes and to allow for restitution to victims of identity theft.” This Anti-Cyber Crime act has now passed passage in the Senate and now needs action by the House to be enacted into law.

This bill will make it easier to prosecute criminals, but the onus still remains on corporations to protect sensitive data that they hold on consumers and employees. Another act - Identity Theft Red Flags - will provide the impetus to ensure that companies create pro-active identity theft protection plans that are signed off - in Sarbanes-Oxley style - by their boards.

Recently companies have begun employing a new form of cryptography - format-preserving encryption - to protect structured information like credit card numbers and social security numbers in databases and applications - the primary beneficiary of this approach is you and me - the consumers - as data that is encrypted - even if it is stolen - cannot be used to steal identities. The FPE approach is available as part of Voltage SecureData which can be deployed on average 5 times faster than other approaches - saving huge amounts of time and cost.