Superconductor

Right hand, say hello to the left hand

At the recent X9 meeting, I noticed an interesting pattern in the discussions about the appropriate level of security around various on-line banking transactions. In every case that I can remember, we had a discussion that went something like this:

Bank A representative: So we think that this new technology has the potential to really revolutionize banking. Bank A loves it.

Bank B representative: Our concern with that particular technology is that we'll never be able to make it secure enough. Plus, our customers really don't want it.

Bank A representative: We don't see security as a problem at all. We've actually been using this technology for over two years now and customers love it.

Because these opinions were often so far apart, I had to wonder exactly how much thought went into creating some of the banks' positions. Had they really thought through the security implications of using a new technology? Did they really have an idea of what their customers really want?

With opinions as different as the ones that I saw, I suspect that not everyone had been as careful in forming their opinions as they should have been, although it was hard to see which position could have benefitted from some additional research.  

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.

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.

Some perspective on industry certifications

I recently had an interesting discussion about the value of information security certifications, like CISSP, CISA, etc. The person I was talking to believed that commercial pressures would eventually make any such certification valueless. In this conversation I learned about the existence of on-line churches that will ordain you as a minister if you fill out a form on their web site. In many cases there's not even a fee for doing this.

Intrigued by this, I found the web site of one of these organizations and submitted a request to be ordained. I got an email almost immediately addressing me as "Reverend Martin" and welcoming me to the ranks of ordained ministers:

Congratulations! You are now a legally ordained minister for life, though you may relinquish your credentials at any time. AS OF Wednesday the 17th of February 2010 YOU HAVE BECOME A MEMBER OF THE PRESTIGIOUS CLERGY. You have earned a title worthy of admiration and respect.

The web site of the organization that ordained me claims that I'm now allowed to do things like baptisms, funerals and marriages. For only $30 this organization will even sell you a certificate that's apparently good enough to convince government officials of some states that you're a legitimate minister. They even sell a product called "Ministry-in-a-Box," but at $139.99, it's way more than I can afford.  

I'm sure that there are some people who get ordained on-line who take their responsibilities as a minister very seriously, but there are probably just as many who don't. But because there's no way to easily tell which one a particular minister is, those certificates that you can get for $30 don't really tell you anything useful. All they tell you is that the person listed on it filled in a form on a web page and then spent $30 on a certificate.

I hope that industry certifications like the CISSP and the CISA don't end up being as devalued as credentials for ministers seem to be now. But because there are now lots of competing certification programs for information security professionals, I wouldn't be surprised if the standards for certifications do indeed loosen up over time.

(I haven't actually done any baptisms, funerals or marriages yet, but I have to admit that I'm less likely to swear now, even when editing standards documents or working on the paperwork for our FIPS 140-2 validation. I'll definitely have to relinquish my credentials, though, when we start our next Common Criteria evaluation.)

A maturity model for enterprise key management

Although it hasn't been posted on the web site yet, the schedule for the 2010 Key Management Summit is now all set. One of the talks sounds particularly interesting: "A Maturity Model for Enterprise Key Management," which will be presented by Keith Sollers and Chris Kostick of Ernst & Young.

E&Y seems to be one of leaders in many aspects of information security, at least among the big consulting firms. I haven't heard of any others who have enough experience with enterprise key management to give them the background for a talk like this one, for example, and I'm looking forward to hearing what they have to say about it.

Why X9.31 key generation is so odd

There was recently an interesting discussion on the sci.crypt Google group. A member of the group asked why the X9.31 standard has such an odd process for how RSA keys need to be generated. One response claimed that there was an easy work-around for the cumbersome process, and that involved using XML:

What you need here is a boat load of XML. XML will solve this problem.

We can have:

<cipher type="Asymmetric" name="RivestShamirAdleman">
 <keygeneration method="outdated,outmoded" result="pointless" />
</cipher>

Then you have someone write a parser in twelve different, slightly
incompatible, libraries and call that a standard.

Then, and only then, have you created a standard that will be defunct
before it's even officially recongised. 
 

A more insightful, if not as entertaining, post described how the content of X9.31 was driven by political maneuvering within the X9 group.

According to a person who claims to have been involved in writing the X9.31 standard, a company who was trying to make their elliptic curve technology look good relative to RSA insisted on the unusual key generation process. The non-crypto people in the group apparently agreed with their arguments and the result was the key generation process that's now in the X9.31 standard. Reading the full discussion of this doesn't take long, and may give an interesting insight or two into exactly how standards are actually developed.

Outis - S/MIME for Gmail

There's apparently an add-on for Firefox that lets you do S/MIME-based email through Gmail. When I first saw this, my first reaction was something like Why on Earth is anyone doing this!?!?

According to the IETF's outcomes tracking database, S/MIME hasn't been a success. They somewhat charitably say that it has experienced "poor adoption."

For some reason, the heroic efforts of the S/MIME Working Group in creating the dozens of documents that they've finished so far remind me of the part of the Odyssey where Odysseus and his companions escape from the hungry Cyclops Polyphemus by blinding him and running away while his cries that "nobody (ουτις, or outis) was hurting him" were ignored by the other Cyclopes.

Maybe "Outis" is a good code name for the Firefox S/MIME add-on for Gmail. I expect that's who will be using it.

Security of NFC

The NFC Forum has what seems to be an extremely optimistic claim about the security of near-field communications. Here's what they claim:

Because the transmission range is so short, NFC-enabled transactions are inherently secure.

NFC is a wireless technology that's designed to work over fairly short distances - 10 centimeters or less. The NFC Forum seems to think that this short range makes NFC technology inherently secure. I'm fairly sure that this isn't true.

Because lots of the uses that are anticipated for NFC are things like mobile payments, making sure that NFC is reasonably secure is important, and relying on NFC being inherently secure because of its short range probably isn't a good way to do this. Even over a distance of only 10 centimeters, you still need to encrypt any sensitive data that you're transmitting.

Can wireless be more secure than wired?

We had an interesting discussion about wireless security in the recent X9 meeting. This was in the context of the new X.112 Part 2 standard, Wireless Management and Security — Part 2: ATM and POS. The interesting part was that the claim was made that wireless connectivity to ATM and POS devices can actually increase security. This may have been the first time that I ever heard someone make this claim about wireless technology.

The claim that wireless is more secure that wired connections to ATM and POS devices is based on the fact that it’s harder to cut the connection to a wireless device than to a device with a wired connection. Many ATM and POS devices trigger alarms when they’re tampered with, and it’s easier for a hacker to cut a wired connection than to cut a wireless connection. Cut the connection for the alarm and you can attack an ATM at your leisure.

Some payment devices also only transmit transaction data to a back-end system in large batch transactions that take place once every day or two. If this is the case, then an attacker has a fairly big window of opportunity in which to attack one of these systems. The claim is that wireless connections will eliminate the need for such batch processing, which will then limit the exposure of the wireless systems to hackers.

From what I heard from banks at the X9 meeting, it sounds like wireless banking and wireless payments are becoming fairly widespread. I found it interesting that banks perceive wireless to have advantages as well as disadvantages in these cases.

What is end-to-end encryption?

End-to-end encryption is often mentioned as one of the best ways to greatly reduce identity theft, but what exactly is end-to-end encryption? It turns out that there are actually conflicting definitions of it, so there’s no quick and easy answer to this question.

The US government’s Federal Standard 1037C, Telecommunications: Glossary of Telecommunication Terms, defines end-to-end encryption as “the encryption of information at its origin and decryption at its intended destination without any intermediate decryption.”

Another US government document, Special Publication 800-12 – An Introduction to Computer Security – NIST Handbook, takes a different approach. SP 800-12 distinguishes between link encryption and end-to-end encryption, where link encryption encrypts routing information and end-to-end encryption doesn’t.

Which of these definitions is more useful depends on your point of view. If you’re a credit card processor, for example, if the transactions that you process are encrypted on each link between the merchant where credit card data is captured and your systems, that doesn’t necessarily provide a useful level of protection to the credit card information. It might be possible for a hacker to capture it between where it’s in the clear between links.What’s probably more useful to you is for the credit card information to be encrypted as soon as it’s collected and only decrypted when it’s needed for some sort of processing. If that’s done in a hardware security module, that gives you fairly strong protection against any hackers that might be targeting you. You really don’t care about whether or not the routing information that’s used to process your transactions is encrypted or not.

I’m not sure what the motivation was for the SP 800-12 definition. It must have made sense when it was written. Maybe it’s just out of date. SP 800-12 was published back in October 1995. It probably went through the extensive review that government documents typically go through, so it was probably actually written at least a year or two before that. Maybe it’s safe to ignore it today and stick with the FS 1037C version.

Weak cipher suites with EV certificates

We had an interesting discussion of EV certificates in the X9 meeting last week. Apparently, EV certificates guarantee that some non-trivial means of authentication was used to authenticate the entity requesting an EV certificate, but there are minimal requirements other than that authentication. In particular, some people at the X9F4 meeting were a bit concerned by the fact that you can apparently use an EV certificate with an extremely weak cipher suite, which means that it's possible to have a connection to a server that uses an EV certificate yet creates a connection that's extremely easy for a hacker to beat.

The administrator of the server that uses an EV certificate can always configure his server to not allow weak cipher suites, and most of them probably do, but the people at the X9F4 meeting thought that the use of strong cipher suites really ought to be required with EV certificates.

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.

Sign up now for the 2010 Key Management Summit

It looks like the agenda for the 2010 Key Management Summit is all set. This year's event will include an interesting range of presentations: talks by industry analysts, vendors, users of key management technology, and even a talk or two about cutting-edge research. We're also considering having some time set aside for impromptu presentations.

Suppose that you're sitting through one of the talks and what the speaker says gives you an idea that the rest of us would be interested to hear. The intent is to have some time allocated to hear these ideas - probably something that can be summarized in a slide or two.

I'm not sure how well that will actually work in practice, but it sounds like an interesting idea. I hope that we'll get a chance to try it in May.

Warning message message message message message

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

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

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

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

 
  
 

Information security in two sentences

In privacy and computer security, real information is too hard to find. Most people don't know what's really going on, and many people who do know aren't telling.

EFF, Preface to Cracking DES, 1998

It hasn't changed much since 1998, has it?

National Cyber Leap Year follow-up

Last year, the US government held the National Cyber Leap Year Summit. Lots of smart people got together and made a series of recommendations to the government. You can read their recommendations here. 

This report came out last September. Some of its recommendations were things like this:

6.8 Idea - Removing Barriers to Entry for Crypto Products into Federal Use

Streamline and expedite the approval process for Federal use of new security technologies.

6.8.1 Description

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.

6.8.2 Inertia

This has not been done yet because the Federal agencies involved in approving new security technologies have relied on the "wait and see if it's secure" model so far. This approach usually determines which technologies are sound and which ones are not, but takes many years and leaves Federal agencies unable to use the innovative security technologies that are being invented today.

6.8.3 Progress

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?

6.8.4 Action Plan

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.

6.8.5 Jumpstart Plan

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.

I haven't heard of any progress in the government on this particular issue. I'm fairly sure that NIST hasn't developed a plan to approve provably-secure technologies for government use and that no government pilot projects of provably-secure technologies have started.

Has there been progress in any of the other areas that the summit participants recommended?

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.

Is information security like preventive health care?

It's hard to find a good model for the cost-effectiveness of information security. Traditional risk management methodologies fail miserably because the unknowns that information security addresses typically can't be quantified like the unknowns that risk management methodologies are designed to handle. This means that the model of information security as an insurance policy really doesn't work very well.

What other models might work better? What about preventive health care? Preventive care is similar to information security in some ways. In both cases we spend money to prevent bad things from happening, and we hope that this will reduce the need to spend money after the bad things have happened.

According to the survey of medical literature done by Joshua Cohen, Peter Neumann and Milton Weinstein that was recently published in the prestigious New England Journal of Medicine, it turns out that most types of preventive care really aren't worth doing. Their analysis shows that, on average, it's really no better to spend money on preventive care than to treat existing conditions. This doesn't mean that all types of preventive care aren't worth doing. There are many cases where preventive care pays. Counseling adults to quit smoking is apparently an example of this, as is providing flu vaccines.

Cohen, Neumann and Weinstein also list cases where preventive care is beneficial but very expensive, things like "newborn screening for medium-chain acyl-coenzyme, a dehydrogenase deficiency." (Yes, I'll admit that I have absolutely no idea of what that means.)

In some cases, preventive care actually increases costs and worsens health. Treatments like "antibiotic prophylaxis (amoxicillin) for children with moderate cardiac lesions who are undergoing urinary catheterization" is apparently an example of this.

So if information security is like preventive health care, how well would popular information security technologies fare in a similar analysis? It's probably not too hard to come up with examples of technologies where it's no better to use a security technology than to just absorb the cost of not using the technology at all. Are there any obvious examples of technologies where you'll probably end up both spending more and getting worse security if you use them?

How is compliance really perceived?

Carl Ellison has an interesting story that may give some insight into how people in the business world really view the maze of data security and privacy laws that they have to navigate these days. Here's his story (told with his permission, of course):

I remember being in a workshop with health-care IT pros. We were talking
security - especially access control.  I asked what their #1 threat was.
The answer:  HIPAA.  They weren't worried about whether a patient's records
were disclosed to a wrong person. They were worried only if they might go to
jail.  They wanted a security solution that kept them out of jail with the
minimum effort and disruption for them.

In other words, the regulation itself is seen as a bigger threat than any disclosure of any Protected Health Information! I wouldn't be surprised if you can hear similar discussions at meetings where other compliance issues are discussed.

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.

Was he really talking about PKI?

It's a vestige of the old superstitious Dark Ages when nobody knew anything and the whole world was sinking deeper and deeper into filth and disease and poverty and ignorance. It is one of those delusions that isn't called insane only because there are so many people involved.

Robert Pirsig, Lila

Key Management Summit - deadline for submissions approaching

The deadline for submissions for the 2010 Key Management Summit is rapidly approaching - you have until December 31 to submit proposals for talks, panel discussions, etc. That's not that far off.

Like the weasel-wording that you often see in financial statements says, past performance is no guarantee of what the future will bring, but if the 2010 Key Management Summit is anything at all like the previous one, then the 2010 meeting will be fairly good. The last one was actually one of the best meetings of its type that I've been to in the past several years.

Like the meeting's web site says:

Topics include, but are not limited to:

• Standards efforts relating to key management
• Government policies around key management
• Customer case-studies
• Panel discussions
• Key management technologies (avoid specific vendor references when possible)

If you have anything interesting to say in any of those areas, there's not much time left for a chance to tell other fans of key management what you know.

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.

Certificate-based authentication

Authentication is one of the big uses that's often hypothesized for PKI, and if you had to pick a use outside of SSL where PKI might actually succeed one day, authentication is probably a good one to pick. Using certificates for authentication avoids the troublesome discussion about whether or not you really have non-repudiation that you often get when certificates are used for digital signatures. You also avoid the headaches that accompany using certificates are used for encryption, like key recovery and key lookup.

On the other hand, authentication is also the case where I've seen certificates misused most often. This is probably, at least in part, due to the careless way that people often talk about using certificates. I've even done that here, haven't I?

People often talk about using a certificate to authenticate a user. This has led to more than one case where a certificate is attached to a message as an authentication credential. The recipient then checks the name in the certificate. If it says Alice, then the message is assumed to be from Alice.

This is absolutely useless as a means of authentication. Despite this, I've seen this done more than once. Other security people that I've talked to often have similar stories about seeing it.

A digital certificate carries a user's public key, which is, well, public. Because of this, it's reasonable to assume that Eve can get Alice's certificate and attach it to a message just as easily as Alice can, which means that using a certificate in this way isn't providing any useful authentication at all. Or it's just as useful as using other public information as a means of authentication.

A better way to use an authentication certificate is as part of a protocol that proves that a user has the private key that corresponds to the public key in the certificate. In addition to defining the format of certificates, the X.509 standard actually describes how to do this. Doing this is much trickier that just attaching a certificate and checking the name in it. On the other hand, it's also much more secure. So if someone says that they're doing "certificate-based authentication," it's probably worth asking for more details about exactly how they're doing this. It may not be as secure as it first sounds.

Is it profitless to use stronger keys?

Security should result in zero profit, but from an economic point of view, not an accounting point of view. Economists define profit as the difference between revenue and opportunity cost, where opportunity cost is the value of the next-best choice. As economist and comedian Yoram Bauman likes to point out, if someone gives you a candy bar that’s worth a dollar, your profit from that transaction is a dollar. But if they offer you the choice between two identical candy bars, your profit is zero, the value of the one that you pick minus the value of the one that you don’t pick. This means that it’s easily possible to show a profit from the accounting point of view yet have a zero or negative profit from the economic point of view.

So it should be clear that if we’re allocating resources to various information security projects, we should end up in a similarly profitless situation. If we don’t end up there then we could have allocated our resources better, so we should go back and reallocate things.

I was recently thinking about this in the context of the push to move to stronger cryptographic key that’s happening now. Today, a 1,024-bit RSA key is considered adequate for most uses, but soon, using 2,048-bit RSA keys will be considered a best practice.

Is it really worth doing this? Is doing this profitable in the sense that economists use?

The work needed to crack those 1,024-bit keys that we’ll soon be phasing out is extremely high, so an attacker always has a better alternative than trying to defeat the cryptography. These other forms of attacks don’t go away if you move to a 2,048-bit key. They’re still there, and they’re still the preferred approach for hackers to use. This means that when we upgrade to the 2,048-bit keys, the systems that use them really aren’t any more secure than they were when they were using the 1,024-bit keys because hackers will never actually try to beat the cryptography. All that we’ve really done is to add cost and complexity to our system, but we’ve added no additional security when we’ve done this.

(This was actually noted by Adi Shamir in the lecture that he gave when he won the Turing Award in 2002. One of his Three Laws of Security is that cryptography is typically bypassed, not beaten. Come to think of it, that's probably a better starting point for thinking about this, but people tell me that blog posts should reflect your train of thought instead of being more carefully written, so I won't go back and redo this from the better point of view.)

There will always be someone out there who will says scary things like “Using anything weaker than the strongest possible cryptography borders on criminal negligence!” but they’re usually not the ones who need to balance the cost of security and the benefits that it provides.

Upgrading to longer keys may seem fairly simple. It might be no more effort than changing a setting on a server. That’s all there is to it with Voltage’s products. But there are always other costs to consider. Those bigger keys take more computing power to handle, for example. You can expect the computing time of the operations that public-key cryptography uses to scale roughly like the cube of the key length, so if you double the key length, you’ll probably use about eight times the computing power to carry out the operations with the longer keys. There are also often issues with compatibility with the older keys that appear after a while. All of these issues cost money to address. On the other hand, using these longer keys doesn't really increase the security of your system.

If you’ve already taken care of all of the other threats that your organization faces then maybe it’s worth worrying about upgrading to longer keys soon. If you haven’t, doing it now seems like a profitless venture.

How to protect test data

Like I mentioned in a previous post, many things are more complicated than you first think. Testing IT systems that handle sensitive data is a good example of this.

You probably don't want to use real data in testing because of the compliance issues that it can cause. On the other hand, you also want your test data to be as much like the real data as possible to make the results of any testing reflect the behavior of the system under real conditions as much as possible. This is actually tricky to do.

It looks like our marketing guys have put together a webinar that talks about how to solve this very problem, so if this is of interest to you, you might want to consider checking it out. You can sign up for it here if it sounds interesting.

Her's a quick summary of this webinar:

Securing Confidential Data in Non-Production Environments
End-to-End Data Protection for Test, Development and Outsourced Systems

Date: December 9, 2009

Time: 10 am PST / 1 pm EST

Duration: 60 minutes

This webinar doesn't have as clever a name as the last one that we had (The Renaissance of Enterprise Key Management and the Barbarian Hordes), but I'm sure that it will contain lots of useful information.

The limits of provable security

I've never quite understood the objections that people have to cryptographic schemes that are provably secure. If you have a proof of security then one of two things must be true: either the scheme is secure or there's a flaw in the proof. There's no other possible case.

All of the technologies that Voltage's products use have such proofs. The Boneh-Franklin IBE, the Boneh-Boyen IBE and our format-preserving encryption technology all have such proofs that have been published in peer-reviewed research journals. Because of this, I often don't understand the questions that I sometimes get about the security of our technologies.

Here's a situation that I've seen more than once. Someone asks about the security of our FPE technology, for example. We'll point them to the paper by cryptographers John Black and Phil Rogaway that has a proof for the security of the scheme. The next question is essentially, "But why should I believe that it's secure?" At that point, I'm never quite sure what to say next. If you have a proof in front of you, then either the proof is correct or there's an error in the proof. If this proof is of the security of a cryptographic scheme, then either the scheme is secure or there's an error in the proof. As mentioned above, there's no other possible alternative.

My recent experiences have led me to believe that there's a fundamental problem with this approach, and that's because many people really aren't comfortable with the idea of a proof. I've seen many cases recently where people essentially accept P and NOT P at the same time and don't seem bothered by doing this.

Every time I see this, I start thinking about the logical implications of it. After all, if you accept both P and NOT P then you can prove that absolutely anything is true. "If 2 = 3 then all cats are dogs" is absolutely true, for example. But because many people either don't understand this or don't believe this, I've come to the conclusion that proofs of security really aren't that useful. They may help specialists make sure that their work is correct, but to non-specialists they really don't say anything useful.

Federated key management as the basis for secure cloud computing

Cloud computing creates security problems that most organizations have not yet had to face on a large scale: protecting data when the location of the data is generally unknown. Encryption is a useful tool for solving this problem, but using it in the cloud is hard because of the key management problems that this causes. Fully federated key management can provide the basis for protecting sensitive data in the cloud, and it's probably the basis for how we’ll eventually protect such data. Let's look at exactly what this means and how it will probably work.

Key management

A cryptographic key is much like the combination to a safe: if you have the right combination, it’s easy to open a safe, but it’s hard to open one without the right combination. Similarly, if you have the right key, decrypting encrypted data is easy, but decrypting it is impractical without this key.

If you’re careless with the combination to your safe, someone else can easily use it to open your safe, and 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 encryption can be essentially eliminated.

Key management covers all the details of how to handle keys carefully enough to ensure 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.

Encryption only involves complicated mathematics that's incomprehensible to most people. Key management involves technology, people and processes, so it's even more difficult. Encryption provides an extremely high level of protection. Even with the world's most powerful supercomputers, hackers would need billions of years to beat modern encryption. Key management is nowhere near as robust. It's usually the weak link that limits how much protection data really gets, so it’s important to get it right if you’re serious about protecting sensitive data.

Federation

Federation describes how different computer systems can work together. In the context of key management, federation includes how different applications can get keys from the same key server. This is an important aspect of key management that needs to be addressed before encryption can be used to protect sensitive data in the cloud, and the lack of the ability to do federation dramatically limits the usefulness of many encryption and key management products today.

Encrypting a backup tape in a data center and decrypting it in an off-site disaster recovery site is a very simple example of federation. In this case, two different tape drives need to work with the same key server to get the key that's needed to encrypt or decrypt the backed-up data. But even extremely simple cases of federated key management can create problems that are hard to solve in practice.

The 2009 Encryption and Key Management Industry Benchmark Report from industry analyst firm Trust Catalyst estimates that only 41 percent of businesses encrypt backup tapes, and that issues relating to key management are the most common reason for not doing so. If the simple cases are that hard, it’s not hard to understand why there’s no solution for the harder cases yet, but that’s what we need to protect data in the cloud.

Cloud computing needs fully federated key management

In cloud computing, we have sensitive data that could be anywhere, and we need the ability for any application that needs access to this data to be able to decrypt it. To do this, we need a way for any application to be able to get the keys that it needs to decrypt data that it gets from the cloud and to use these keys in a careful way that keeps the data protected. More concisely, that's fully federated key management.

Federated key management for cloud computing

If today's systems can't implement fully federated key management, what are the missing pieces? If we look more closely at how cryptographic keys are handled today, we can probably get a good idea of what's needed in the more general case.

A cryptographic key always has additional information associated with it that uniquely identifies it. When a tape drive gets a key to use to encrypt stored data, for example, it also gets a unique key identifier which it stores with the encrypted data. To decrypt the encrypted data, the tape drive requests the key that corresponds to the key identifier that it finds with the encrypted data.

It's possible to extend the idea of a key identifier to include information about the key server where the right key can be obtained. Instead of having a key identifier like this

we might have one like this

 

where the additional information indicates the URL of the key server where the key can be obtained. If all applications understand how to handle such information when it's included in a key identifier, then they can easily use this information as the basis for federated key management.

How it's used today

This approach has already been used with great success in existing key management technologies. Systems that use Identity-Based Encryption (IBE), for example, already use more general key identifiers. In these systems, the identity of a user plus other policy information functions as the key identifier. In the case of using IBE to encrypt an email message, such an identifier might look like this

which indicates the email address of the recipient of the encrypted message, the time after which the private key can be downloaded from the key server, and the URL where the recipient can get the private key that he needs to decrypt the message. Any recipient that can interpret this type of key identifier can then contact the key server and request the IBE key needed to decrypt this message.

This approach hasn't quite made it to other encryption technologies yet, although it probably will soon. The most recent draft of the IEEE P1619.3 Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data uses this approach to define unique identifiers for keys from which it's easy to find the URL of the key server where the key can be obtained. Once that standard is implemented, key management for encrypting backup tapes will certainly get much easier.

Once this idea is extended to other technologies, we’ll have the fully federated key management that we need to protect sensitive data in the cloud. This sounds simple enough, but actually writing a standard that will be the basis for doing this in an interoperable way isn’t easy. Using technologies like IBE may be as close as we can come to fully federated key management until the necessary standards are completed.

How serious is phishing?

How serious is phishing? According to a paper by Cormac Herley and Dinei Florêncio of Microsoft Research, it may not be as serious as we're led to believe. Here's what they say about this.

We find the oft-quoted survey-based estimates of phishing losses unreliable. In particular the victimization rate found in most surveys is smaller than the margin of error, and dollar losses are estimated by averaging unverified self-reported numbers. We estimate that recent public estimates overstate phishing losses by as much as a factor of fifty.

In other words, they claim that the victimization rate for phishing is statistically indistinguishable from zero and that estimates of the losses due to phishing are wildly inaccurate. Herley and Florêncio then try to make their own estimate of the annual losses due to phishing and come up with the figure of $61 million, which is much lower than we're usually led to believe. If that estimate is accurate then it's essentially not worth doing anything about phishing because any industry-wide effort to fight it will cost more than the $61 million in losses it could prevent.

If phishing is really not as lucrative as we're usually led to believe, why do people keep doing it? Herley and Florêncio have an answer for that too:

Repetition of questionable survey results and unsubstantiated anecdotes makes things worse by ensuring a steady supply of new entrants.

In other words, people keep trying it because they're mislead into believing that they can make money doing it. If this is the case, the best strategy is to ignore phishing and it will probably go away.

Which is true? Is phishing as serious a threat as we're often led to believe, or is it essentially not worth worrying about? Unfortunately, there's not enough accurate data to answer this question, so we'll have to keep making decisions about how to deal with phishing based on our own experiences and the data that's available.

Really expensive encryption

According to the recent trust catalyst (their use of capitalization, not mine) 2009 Encryption and Key Management Industry Benchmark Report, 10 percent of people think that the reason that more people don't encrypt backup tapes is that encrypting tapes costs more than a data breach so that encrypting backup tapes isn't cost-effective.

What I learned from reading that is that 10 precent of people will pretty much believe anything.

Visualizing key strength

I came across an interesting YouTube movie the other day. This particular movie shows bullets hitting various things in slow motion. The movie is really a clever advertisement for a high-speed camera that can take 1 million frames per second, but that doesn't make it any less impressive.

Most people probably just think, "Wow, that's pretty cool," when they see bullets in slow motion. When I saw it, however, it made me think of a way to visualize cryptographic key strength.

Suppose that you had an animation of the future of the Earth that shows the continents drifting around its surface. Something like the movies here. You'd have some of slider that lets you pick a multiple of the computing power of the EFF DES Cracker. Once you set that parameter, you'd watch the continents drift around and watch as the number of bits of key that that level of computing power has let you exhaust appears somewhere on the screen. If you picked 1 billion times the power of the DES Cracker, for example, at 116 bits we'd see the continents collide to form one massive supercontinent.

Or you could do a similar thing with the Andromeda galaxy that's currently approaching the Milky Way at something like 120 kilometers per second. As time passes, Andromeda would get bigger and bigger in the sky. At the same level of computing power, you'd see the two galaxies collide when roughly 119 bits of key were exhausted. At about 120 bits, the Sun would become a red giant, destroying the Earth, so the movie might stop at that point. 

Another option would be to go on a tour of the universe at the speed of light and see what sort of things you pass as as you reach various key lengths. The universe is apparently at least 156 billion light-years wide, so you'd be able to see a fair amount of stuff as your key cracking machine does its work.

With the Internet, of course, there's a good chance that someone else has already done that and I just haven't seen it yet.

Key management for the barbarian hordes

It looks like our marketing guys are having another webcast about key management. The title of this one alone, "The Renaissance of Enterprise Key Management and the Barbarian Hordes Enterprise Key Management: Fact and Fiction", makes me think that it will be too good to pass up.

This entertaining and educational webcast will be held on November 17, at 10 AM PST (1 PM EST). You can sign up for it here.

Thoughts on non-repudiation

What exactly is "non-repudiation?" This question has been asked many times but rarely answered, at least in a reasonable way. Part of the problem seems to be caused by the fact that "repudiation" means something particular to lawyers, and that meaning isn't the same as the one that technologists think of, and most of the debates over the meaning of "non-repudiation" can probably be reduced to the misunderstanding that using that particular term caused. If a term like "origin authentication and data integrity" (OADI) had been used instead, we'd probably have reached an agreement as to what the term actually means long ago, but it wasn't, so we're stuck with a more confusing term instead.

OADI can be ensured in more than one way. A digital signature can be the basis for ensuring OADI, but doing this gives you a scheme that's only as good as the controls around the private key that's used to create the signature. If a digital certificate is used in an OADI scheme, then you have even more controls to worry about: those used by the CA that creates the certificate. So without the right controls in place, a digital signature isn't very useful for ensuring OADI.

A MAC can also be used as the basis for ensuring OADI, and it's also only as good as the controls around the key that's used to create or verify the MAC. If you have controls in place that ensure that the sender of a message can only use a key to create a MAC and that the recipient of a message can only use a key verify a MAC, then a MAC is useful as a means of OADI. There are systems today that do this, although they're not as common as the ones used to create and verify digital signatures.

So it seems that the difference between using a digital signature for OADI and using a MAC for OADI aren't as great as you might first think. In either case, the usefulness of the OADI scheme is limited by the controls in place that limit how cryptographic keys are used. In one case you're trusting the controls that the sender of a message has in place, and probably the controls that a CA has in place as well. In the other case, you're trusting that the controls in place at both the sender and recipient. The biggest difference between the two cases seems to be the practical difficulties that limit the usefulness of MACs, but if you want to ensure OADI, either type of scheme can be used.

How to be PCI compliant yet weak

It’s possible to comply with the PCI DSS yet provide essentially no protection to credit card numbers. Here’s why.

Section 3.3 of the PCI DSS requires this:

Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).

Then section 3.4 requires this:

Render PAN, at minimum, unreadable anywhere it is stored (including on portable digital media, backup media, in logs) by using any of the following approaches:

• One-way hashes based on strong cryptography
• Truncation
• Index tokens and pads (pads must be securely stored)
• Strong cryptography with associated key-management processes and procedures

Each of these techniques seems to provide a reasonable level of protection for credit card numbers, but when you combine the two, it turns out that the combination can actually be fairly weak. Here’s why.

If you mask a credit card number, you can keep the middle six digits and hide the rest. So you might turn this credit card number

1234 5678 9012 3456

into this

1234 56XX XXXX 3456

Now suppose that you also know that the SHA-1 hash of this credit card number is the value

0xdeed2a88e73dccaa30a9e6e296f62be238be4ade

This is enough information to let a hacker quickly and easily find the complete credit card number: all he has to do is calculate the SHA-1 hashes of all possible credit card numbers that begin with 123456 and end with 3456. There are only one million of these, and it’s possible to calculate that many hashes extremely quickly. Even on extremely my old laptop, I can do that in less than a couple of seconds. Hackers who have even more modern computers can do it even more quickly.

So if you have both the hash of a credit card number and a masked version of the same credit card number, then it can be extremely easy to find the entire credit card number. Each of the ways to protect credit card numbers may be good enough by themselves, but together they can provide essentially no security.

I've heard of more than one case where masked data from one application and hashed data from a different application gets stored in a common database, so this particular vulnerability is not purely of academic interest.

What merchants want from the PCI DSS

More interesting stuff from the recent X9 meeting. In this case it relates to what merchants want to help them comply with the PCI DSS. At least this is what the merchants who attended the X9 meeting said that they want.

Apparently merchants don't like how vague the PCI DSS is on several points. In particular, it tells you what you have to do in general terms, but not exactly how to do this. It leaves deciding whether or not a particular approach is good enough to the QSAs. Merchants don't like this arrangement at all. They'd rather be told more details and have to live with a possibly-imperfect solution, particularly if it's one that will guarantee to make them PCI compliant.

I don't think that we'll see that level of detail in anything from either X9 or the PCI SSC, but that seems to be what merchants want. I have an easy solution for them: they should all buy and use Voltage's SecureData. I'm not sure that I can get the PCI SSC to require all merchants and payment processors to standardize on Voltage's products, but it would certainly make life easier for them.

The birth of X9.119

Standardization is crushing the heart and soul, the blood and guts, out of humanity and the eventual result will be either complete and unrelieved slavery or the destruction of civilization and return to barbarism.

Robert E. Howard, letter to H. P. Lovecraft, October 31, 1931

At the recent ASC X9 meeting, we learned that the designation X9.119 had been assigned to the new standard that will be called Protection of Sensitive Data between Device and Acquiring System. At this meeting, it actually took over an hour for the X9F6 working group to decide that this document should be a standard instead of something else, like a technical guideline (TG).

The most amazing part was the fact that after over an hour of loud and bitter debate over this, it was actually unanimously decided that the document should indeed become a standard! In other words, we spent over an hour arguing over a point over which there was total and complete agreement. That might give you some idea of how long it takes to resolve points over which there is actually some disagreement.

I should also mention that I was impressed by the people from Heartland Payment Systems during this hour-long discussion. While people from other organizations were willing to spend lots of time talking about things that weren't really related to the issue at hand, Heartland did their best to keep the discussion on track. Unfortunately, their efforts weren't quite enough to do this, but I hope that they won't be discouraged by this experience. We need more of that type of contribution at standards meetings instead of less.

Thoughts on penetration testing

In the recent X9F4 meeting we discussed the most recent draft of the X9.111 standard, Penetration Testing within the Financial Service Industry. There was lots of discussion of how disciplined, methodical and careful the penetration testing industry is these days. Most people seemed to think that this was a good thing. Some people even think that it’s a good idea to require your penetration testers to give you a complete list of all the tools that they plan to use in their testing, including the exact versions of the tools that they’ll be using.

On the other hand, I have to wonder if that sort of approach really gives an accurate impression of how well protected you are against hackers. After all, some hackers may use a similarly disciplined, methodical and careful approach, but others probably don’t. And if you restrict your testing to only attacks that the more disciplined hackers would use, you’ll almost certainly miss some of the attacks that less careful ones would use.

I’m out of touch with exactly how hackers operate these days, but I’d guess that most of them aren’t as careful and disciplined as professional penetration testers. If that’s the case, professional penetration tests may not really be giving you a good idea of how well you’re defended against hackers. But because that may not actually be the point of penetration tests, this may not really be a problem.

A Bayesian approach to understanding data breaches

A new report from Javelin Research, Data Breach Notifications: Victims Face Four Times Higher Risk of Fraud, has some interesting information in it. In particular, it says that 11 percent of American consumers received a data breach notification letter in the past year. Of the people who received these letters, 19.5 percent claimed to have been victims of identity theft in the same period, while only 4.3 percent of those who didn't receive such a letter were victims.

Any time I see data like this, the first thing I do is try to apply Bayes' theorem to it. Here's what I get when I do that.

Let T represent the event that a person suffers identity theft and N be the event that a person receives a breach notification letter. If my interpretation of Javelin's data is correct, this means that we're given that

 P(T|N) = 0.195

P(T|not N) = 0.43

P(N) = 0.11

and

P(not N) = 0.89

From the data that the Department of Justice has, it looks like

P(T) = 0.0275

Using Bayes' theorem we have that

P(not N|T) = P(T|not N) P(not N) / P(T)

= (0.43) (0.89) / 0.0275

= 0.22

In other words, if you're a victim of identity theft, there's probably about a 22 percent chance that you won't have received a breach notification letter. On the other hand, that also means that there's about a 78 percent chance that you will have received a breach notification letter. I'll bet that number's higher than it was a few years ago.

Why PKI failed

I came across an intesting paper that may explain why PKI technology failed. This paper is "Test of Influence from Future in Large Hadron Collider; A Proposal," by Holger Nielsen and Masao Ninomiya. Nielsen and Ninomiya essentially argue that the LHC may be plagued by problems because if it actually worked it would produce effects that are so ugly that they would actually send ripples of bad luck back through time to thwart the creation of the ugly effects. This may sound like something from a bad science-fiction movie, but this paper appears to be quite serious about this.

Similarly, maybe the possible future in which everything is PKI-enabled and digital certificates are ubiquitous is so horrendous that it actually sent ripples of bad luck back through time that sabotaged the development and deployment of PKI technology. Some things actually seem to make a lot of sense from this point of view.

I'll leave it to someone else to work out the physics of exactly how this could have happened. The paper by Nielsen and Ninomiya is probably a good place to start.

Really big symmetric keys

I recently came across an interesting security product, although it's not exactly "interesting" in the sense that I might want to buy and use it. This particular product is CRYPTETO from Hawthorne Davies, a UK vendor of encryption technology. Here's what they claim:

The strongest Diplomatic Standard Algorithm key strength is Hawthorne Davies’ TOUAREG Encryption Algorithm used in CRYPTETO. It uses a session key equivalent to 49,152 bits.

Let's assume that this is true and that they're using a public-key algorithm to transport or otherwise protect these keys. According to the formula that NIST uses in Section 7.5 the Implementation Guidance for FIPS 140-2, it would take an RSA key with slightly more than 15 billion bits to give the same strength as a 49,152-bit symmetric key. Operations on an RSA key that big are totally impractical, so they're definitely not using RSA for key transport.

Maybe they use an elliptic-curve scheme for key transport. If that's the case, it would still take an elliptic-curve key with slightly less than 100,000 bits to give the same strength. That's also impractical, so I don't think that they're doing that either.

This leads me to believe that one of two things is true: either they're using a key much weaker than one with 49,152-bits of strength for key management, or they're using no public-key technology for key management at all. If the first is true, then the CRYPTETO system doesn't really provide 49,152-bits of strength. In this case, its cryptographic strength is limited by the size of the public keys that it uses, and these are almost certainly provide much less than 49,152 bits of strength.

If the second is true, then key management is going to be a serious headache for user of the CRYPTETO system. They won't even be able to use SSL to securely transport keys. I doubt that's the case, so we can probably assume that CRYPTETO doesn't provide anywhere near 49,152 bits of strength, and that the claim that is uses a session key that's the equivalent of 49,152 bits is nothing more than a red herring designed to distract and impress potential customers with information that's really not very relevant.

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

Security insights from the history of radar

I seem to recall reading something interesting a while ago about the invention of radar. I believe that I read this in Luis Alvarez's autobiography Alvarez: Adventures of a Physicist, but I'm not sure. I think that it was Alvarez who said that physicists were better suited for inventing radar because of the biases that electrical engineers had. It seems that engineers in the '30s and '40s typically focused on eliminating or reducing electromagnetic emanations in the radios that they designed, and the very idea that you'd want a system that intentionally radiated EM energy didn't sit well with them. Physicists, on the other hand, had no such bias, so they were better suited for research on radar.

It seems to me that the same sort of biases creep into information security. These biases affect all sorts of things, including what we expect to be feasible and what we consider to be secure.

If you go back 20 years, for example, most people who worked in information security had degrees in either Mathematics or Electrical Engineering. The biases of people with those types of backgrounds are apparent today. Electrical Engineers, for example, wrote the standard that evolved into today's Security Requirements for Cryptographic Modules, otherwise known as FIPS 140-2. These engineers were apparently comfortable with the idea of a circuit board or an integrated circuit, and the FIPS 140-2 standard seems to reflect this mind-set.

On the other hand, they didn't know much about software, and that's also reflected in the FIPS 140-2 standard. If you want an interesting point of view on this, try tracking down the people who navigated OpenSSL through its FIPS 140-2 validation. From what I've heard, one of the hardest and most time-consuming parts of doing this was getting the people at NIST comfortable with some of the concepts that software engineers take for granted but hardware engineers don't really think about at all.

Today, most people working in information security seem to have degrees in Computer Science. This typically means that they understand software fairly well, but don't really know much about hardware. That's probably why so many people were impressed by the so-called "cold boot attacks" that took advantage of properties of hardware. To the previous generation of information security professionals, particularly those with a background in Electrical Engineering, this type of attack seems fairly obvious. On the other hand, if you have little or no exposure to hardware, such attacks can seem like magic.

Today, at the beginning of the twenty-first century, we still don't know how to make secure software. It's actually worse than that: we really don't know how to make software yet. Maybe we could find outsiders from another discipline that could give us some useful insights into how to do this, although I'm not sure who would be good to use in this role.

Some historical perspective

The year 1977 is often described as the year in which public-key cryptography was born. That's when "New Directions in Cryptography," by Whit Diffie and Martin Hellman was published. The people at GCHQ actually knew about the technology a few years before that, but their work was classified. That's why we now talk about the RSA algorithm instead of the Cocks algorithm. It's also why most people think of 1977 as when public-key cryptography was invented instead of 1973, when Cliff Cocks really invented it.

1977 was 32 years ago. To put that into some perspective, 32 years before that takes you back to 1945, which was when World War II was ending. This means that today we're just as close to the invention of public-key cryptography as the invention of public-key cryptography is to the end of World War II.