Superconductor

The security model for biometrics

I just came across an article that talks about how the use of biometric data for identification can cause a security problem. Here's what this article said:

When biometrics get down to the local gym, however, serious questions must be raised. Your biometric identifiers are immutable and, once stored on a computer, impossible to take back. So if the 24-Hour Fitness database gets hacked and some enterprising Black Hat team of computer experts makes off with this sensitive information, many people could forever lose control of this permanent identification marker. Of course, you could scrape off your fingerprints and replace them with new ones. (This is probably possible). But that's getting a little too close to Total Recall for my taste.

This seems to miss the point of biometrics. Biometric data isn't secret and the security model of biometric identification systems doesn't assume that it is. Instead, biometrics need to ensure that the data that they capture is fresh instead of stored. This subtlety seems to have been missed by the author of this article.

A novel idea in PKI

It looks like that back in 2006 the determned people at Izanpe tried to get their root certificate added to the Mozilla browser. It took them four years to do this, and you can find the story of their adventure here.

At a bit over 14,000 words, this story should probably be called a novelette instead of a full novel, but that's probably not much of a consolation to the people at Izanpe. 

Random thought of the day

The title of the article says it all: "The generation of random numbers is too important to be left to chance," (Robert R. Coveyou, Studies in Applied Mathematics, Vol. 3, 1969, pp. 70-111).

What an error on storefrontbacktalk.com tells us

On Storefrontbacktalk.com, QSA Walt Conway talks about why encrypting short fields, like the expiration date of a credit card, can let an adversary decrypt your entire database. His conclusion is just plain wrong, but his article is actually very useful in other ways, because it may give us some insight into what the industry really needs.

First, let's see why Walt's conclusion is wrong.

If you encrypt a small field with non-randomized encryption, it may be possible for an adversary to carry out a chosen-plaintext attack. To do this he builds a table of all possible plain-cipher pairs and then uses that table to decrypt ciphertexts that he sees. But just because an adversary can do a chosen-plaintext attack does not mean that they can do a key recovery attack. That's typically much harder.

Building a table of all possible expiration dates is very feasible. Trying to recover a key that's used to encrypt all of those expiration dates isn't. This means that the fundamental premise of Walt's article is totally wrong.

That’s not surprising, however, because encryption is a tricky subject that’s often inaccessible to non-specialists. If we look at exactly what it means for encryption to be secure we see a good example of this.

There are actually several definitions of security for encryption, and each of these formalize what it means to be secure against the different types attacks that an adversary might try. One of the most common of these is IND-CPA security, which provides a careful definition of how hard it is for an adversary to carry out a chosen-plaintext attack.

The precise definition of IND-CPA security is fairly incomprehensible to non-specialists, so you can’t really expect them to spend the time and effort to understand it. If you’re not a crypto specialist, look at the Wikipedia article on IND-CPA security and see if its definition makes sense to you.

There’s another notion of the security of encryption that’s called “perfect secrecy,” and that’s really the security model that tokenization systems try to attain. This definition is also fairly incomprehensible to non-specialists, so even though tokenization systems violate the assumptions of the security model that they’re trying to meet, that’s not clear to most people.

On the other hand, there's a definite need for careful and precise definitions of what it means for encryption to be secure. These definitions are what you use when you prove that a cryptographic scheme is secure, and without these careful definitions, these proofs really aren't possible. The unfortunate side effect, however, is that things really get a bit too complicated for most people to understand.

In any event, if the subtleties of encryption and its security aren’t clear to a QSA, what that’s probably telling us is that there’s a need for some way for them to get complicated concepts explained to them in an easy-to-understand way. Maybe some sort of industry forum in which QSAs and others can ask experts about these things in a way that won’t make them feel foolish would be good for this.

I’ve found that having a few beers with the sales people selling crypto products is a fairly effective way to do give them a chance to ask questions about exactly how their technology works and why it’s secure, but that approach probably doesn’t scale very well. Maybe that industry forum would be a better approach.

All but the simplest of metrics will fail

I'm now firmly convinced that all but the simplest of metrics for security are doomed to failure. Something as simple as the fraction of workstations with anti-virus software installed is probably simple enough, but anything more that that is probably too complicated to be useful. I think this because of a conversation that I recently had with someone who didn't understand the difference between "4 square yards" and "4 yards square."

The person who didn't understand this difference had an undergraduate degree in engineering, so they must have had a few math classes in college. (I suppose that I should mention that this engineer does not work at Voltage.) If a person with that much technical education can't understand that difference, I'd guess that people with even less of a technical background would have a very hard time understanding any metric for security that had even a relatively modest level of complexity. I'm now wondering if even talking about the "average" amount of something is too much for many people to really understand. Even that fairly simple concept is commonly misunderstood or misinterpreted.

Get your BN curve here

It looks like some researchers at RWTH Aachen University have an on-line tool for creating BN curves. These are elliptic curves that are particularly useful for pairing-based cryptography, like the identity-based encryption that Voltage uses. If you're interested in implementing pairing-based cryptography, this is a very useful resource to have.

It's generally true that there's no such thing as a free lunch, and this even applies to identity-based encryption. From the user's point of view IBE is great because it's simpler to use than alternatives. From an administrator's point of view IBE iss great because it's extremely simple to keep running. These two combine to make its TCO much lower than the TCO of alternatives.

On the other hand, all of these good features don't come for free, but they really involve things that users and administrators don't see. In particular, it can be very difficult to find elliptic curves that are suitable for use in IBE algorithms. Most elliptic curves don't work very well for this and it can be a bit tricky finding ones that do. BN curves happen to be an example of a type of curve that do work well, so having a place where you can get parameters for such curves can be very useful.

The parameters that you can get from this on-line tool aren't optimized to give you very good performance, so they're not what you'd want to use in a shipping commercial product, but if you're just doing development and testing they're very useful.

Information security as an alternative to horror novels

I know lots of people who are big fans of horror fiction. Many of them tell me that they read horror fiction because they like the way it makes them feel. Many of them apparently like the uneasy feeling that they get from reading it, even the really over-the-top stuff that does its best to make you feel the desperate need to take a shower after you finish it.

It seems to me that information security is also a bit like this - it also deals with lots of bad things happening, many which are really out of your control. Having an exploitable buffer overflow vulnerability discovered in your web server probably isn't as bad as the end of the world in which some sort of out-of-control secret government experiment leads to us all being eaten by zombies, for example, but it's not the sort of thing that you can really do much about, and neither one of these possibilities is really very appealing. 

There probably aren't many people why stay awake at night worrying about being eaten by zombies while there are people who stay awake at night worrying about the possibility of their web server having an exploitable vulnerability, so that's probably not the best example. But if there are people who like the feeling that they get from reading horror novels, I wouldn't be too surprised if there are also people who like thinking about information security for very similar reasons. If I remember to, I'll have to ask people about this at one of the vendor-sponsored parties at next year's RSA Conference.

More interesting fraud data from the Kansas City Fed

As I mentioned before, "The Changing Nature of U.S. Card Payment Fraud: Industry and Public Policy Options" by Richard J. Sullivan, has some interesting data about the nature of fraud. Here's what's in Table 2 in this document.

Card issuers	billions	Share of total loss
PIN debit	$0.028
Signature debit	$0.337
Credit cards	$1.240
ATM withdrawals	$0.397
Total issuer losses	$2.002	59%
Merchants
POS	$0.828
Internet, mail order, and telephone	$0.568
Total merchant losses	$1.396	41%
Total losses	$3.718

I noticed a few interesting things is this data:

• Banks actually suffer more from card payments fraud than merchants do - roughly 50 percent more
• For banks, ATM fraud is a almost one-third of credit card fraud
• Merchants actually have more POS losses than CNP losses

I wouldn't have expected any of those to be true.

Practice-oriented Provable-Security

In 2009, Mihir Bellare and Phil Rogaway shared the ACM's prestigous Paris Kanellakis Theory and Practice Award for their creation of the idea of "Practice-Oriented Provable-Security." Here's the citation for the award that explains why they received it:

Historically, cryptographic schemes used in practice were designed in ad hoc ways and subject to failure. Practice-Oriented, Provable-Security (POPS), developed by Bellare and Rogaway in a series of papers in the 1990s, changed this, giving us the means to create high-assurance practical cryptography, meaning schemes that were backed by the theoretical guarantee of provable security while meeting practical needs and expectations.

Today, POPS-based schemes are cornerstones of Internet security, implemented in most communication security protocols and software - these schemes are used every time someone makes a credit card-based Internet purchase. Meanwhile, the models, techniques and approaches that Bellare and Rogaway introduced, including the random oracle model, have become the foundation of a new subfield of cryptography, inspiring a great amount of follow-on work. Their papers are amongst the most cited in cryptography and their work is discussed in dozens of textbooks.

Bellare and Rogaway changed the perception of theory in practice. Prior to their work, practitioners ignored theory or were even antagonistic to it. Today, they not only choose to implement and standardize proven-secure schemes, but make provable security a requirement in some of their calls for algorithms. That this requirement can be met owes much to Bellare and Rogaway's work. 

In other words, Bellare and Rogaway created a framework for cryptographers to use to prove the security of their inventions and this framework is really the single thing that's most responsible for transforming cryptography from an art into a science.

Before POPS, the only way to ensure that a cryptographic scheme was secure was to wait a while to see if anyone could find a weakness with it. With the invention of POPS that's no longer necessary. It might even be a waste of time to wait to see if a weakness can be found because if there's a valid proof because the very existence of the proof tells you that there can't be one.

Many of the technologies that we use at Voltage have proofs of security. This includes both our Identity-based Encryption and Format-Preserving Encryption. The things that we use that don't have proofs of their security are just things that older standards define: techniques standardized before POPS typically don't have proofs of their security, but there's no really alternative to using them.

I'd hope that newer standards won't have this problem. All of the discussions that I've seen recently in various standards groups have required a proof of security before a new crypotgraphic scheme is taken seriously.

Is the US the worst place for credit card fraud?

The economists at the Federal Reserve Bank of Kansas City do lots of interesting research. One of their recent publications, "The Changing Nature of U.S. Card Payment Fraud: Industry and Public Policy Options" by Richard J. Sullivan, has some interesting data about the rates of fraud. Here's what you can find in Table 3 in this document. It's a list of fraud rates for various countries.

Country	Loss per $100
Australia	$0.024
France	$0.050
Spain	$0.022
U.K.	$0.086
U.S.	$0.092

That's not a comprehensive list of countries, but it certainly looks like there's more fraud in the U.S. than in any other country.

Quote of the week? Month?

Research in Motion has been in the news a lot recently. The governments of the United Arab Emirates and Saudi Arabia don't like the fact that RIM encrypts traffic to and from the ubiquitous BlackBerry phones and have threatened to shut down BlackBerry service unless RIM provides them a way to bypass the encryption.

In last Thursday's Wall Street Journal, Michael Lazaridis had the following to say about this:

This is about the Internet. Everything on the Internet is encrypted. This is not a BlackBerry-only issue. If they can't deal with the Internet, they should shut it off.

There's no easy solution to this problem. Governments want to be able to spy on people and people want privacy. You clearly can't have both.

A possible use for encryption in the future

I just read another interesting report from the Burton Group. This time it was "Information Confidentiality." The section of this report mentioned two possible uses of encryption that we may be seeing more of in the future. One of these was cloud computing. There's been so much talk about cloud computing in the past few years that it's probably not worth mentioning much more about the obvious use of encryption to protect data in a cloud environment. The second use was to cryptographically destroy information: encrypt data and throw away the key and the data is essentially gone for good.

Here's what this report said about this:

Information destruction is an important part of the information life cycle, but it's often neglected in information confidentiality architecture. An intensifying regulatory environment has caused organizations to pay closer attention to destruction. And with the increased use of encryption to protect data during its normal period of utility, the possibility of using encryption for destruction emerges. Specifically, disposing of encryption keys can effectively destroy at-rest data that is encrypted with strong ciphers and whose keys have been properly managed. Disposing of keys renders encrypted data unusable. Although some enterprises entertain the notion of using this data-disposal technique, caution is warranted to ensure that spare copies of keys or weak encryption implementation don't undermine destruction. Another caution is warranted: Combinations of ciphers and key lengths have anticipated protection life spans. In other words, encryption can protect sensitive information only for a certain time period, until advances in computing power or mathematics make recovery possible. This goes for information “destroyed” through intentional key loss or destruction, as well. If information is still valuable after a cipher or key length no longer protects it, then data may be exposed and cause harm.

I've heard of lots of cases where people unintentionally cryptographically shred data through careless key management or by using buggy products, but I haven't heard of many businesses using encryption to intentionally destroy data. Maybe we'll be hearing more about that in the future.

What do digital certificates really mean?

What do digital certificates really mean? The best discussion of this may be the one that I recently read in Peter Gutmann's book Engineering Security. Here's how Peter describes this:

As a pure speech act, what a certificate is saying is that at some point some entity who may or may not be the one named in the certificate probably requested that another entity who may or may not be the one named elsewhere in the certificate took the public components of a private key that the first entity may or may not control and asked the second entity to sign it using a private key that they may or may not control. However once it’s gone through many, many layers of software this has changed to (for example) a statement that the user has definitely connected to a web site controlled by the named entity, and by the time it gets to the user it’s jumped even further to become an assurance that it’s safe to enter sensitive personal and financial information on the web site!

More wisdom from the CIA

There's another bit of information in the CIA's book Psychology of Intelligence Analysis that seems particularly relevant to information security. This concerns how much information people need to make good decisions. Here's what Chapter 5, "Do You Really Need More Information?" says about this:

Key findings from this research are:

• Once an experienced analyst has the minimum information necessary to make an informed judgment, obtaining additional information generally does not improve the accuracy of his or her estimates. Additional information does, however, lead the analyst to become more confident in the judgment, to the point of overconfidence.
• Experienced analysts have an imperfect understanding of what information they actually use in making judgments. They are unaware of the extent to which their judgments are determined by a few dominant factors, rather than by the systematic integration of all available information. Analysts actually use much less of the available information than they think they do.

So maybe it's the case that information security professionals don't need as much information as we might think they do to make informed decisions and that too much information can actually be harmful instead of beneficial when it comes to this. And if security professionals are really using only some of the available information to help them make these decisions, I'd be very interested to learn exactly what information they do use. Hundreds of marketing people probably would also.

Biases in estimating probabilities

Understanding how often security breaches happen is important to understanding how many resources to allocate to preventing them. This can be tricky because there's not much reliable data about how often security breaches happen. People also don't estimate probabilities very well, so in the absence of good data we're likely to make mistakes that can lead to either too much or too little being spent. This problem isn't limited to just information security, of course. It also complicates things any time we don't have good estimates of probabilities.

I recently came across an interesting discussion of this in a book by the CIA: Psychology of Intelligence Analysis. Here's the book's summary of its Chapter 12, "Biases in Estimating Probabilities," and these comments seem to apply to information security just as well as it applies to intelligence analysis:

In making rough probability judgments, people commonly depend upon one of several simplified rules of thumb that greatly ease the burden of decision. Using the "availability" rule, people judge the probability of an event by the ease with which they can imagine relevant instances of similar events or the number of such events that they can easily remember. With the "anchoring" strategy, people pick some natural starting point for a first approximation and then adjust this figure based on the results of additional information or analysis. Typically, they do not adjust the initial judgment enough.

Expressions of probability, such as possible and probable, are a common source of ambiguity that make it easier for a reader to interpret a report as consistent with the reader's own preconceptions. The probability of a scenario is often miscalculated. Data on "prior probabilities" are commonly ignored unless they illuminate causal relationships.

So if you're interested in how people mis-estimate probabilities and ways to deal with this, this CIA book actually seems to have a fairly good discussion of it. And the price (free) is certainly right.

Measuring security

I recently received an email that asked me if the electric field and magnetic field of a propagating electromagnetic wave are always in phase. I vaguely recalled that you have something like

E = c B

in some situations, so the first thing that I did to check to see if this made sense was to compare the units of E to the units of cB. After all, if the units don't work out then something's wrong.

This led me to think about how the strength of encryption is probably the only place in the entire field of information security where it's easy to quantify something. In the case of encryption, the usual metric is the size of an ideal symmetric algorithm for which there no attack that's better that just trying all possible keys to see which one's the right one. By that metric, for example, encryption with either the 3DES or with 2,048-bit RSA provides 112 bits of security because cracking such a key takes about the same amount of effort as trying all possible 112-bit keys.

This metric isn't really that meaningful, of course, because there's always a better way for an adversary to beat a system than trying to beat encryption. The amount of work needed to crack a single 3DES key is huge. It's the sort of thing that takes much more that a person's lifetime on the world's most powerful supercomputers to do.

Key management is nowhere near as strong, so it's always better for an attacker to try to beat the key management that's used instead of trying to get billions of years of computing time somehow. But if we don't worry about the strength of key management and focus just on the strength of encryption, we find that we have a nice, clean way to measure the strength of that particular security mechanism.

After figuring out whether or not the electric field and magnetic field of a propagating electromagnetic wave are always in phase, I then thought about if there's any other part of information security where it's relatively easy to create a metric for the effectiveness of technologies that give the same level of information that the strength of encryption does. My conclusion was that there isn't one, but if you have a good one, I'd be happy to hear about it.

The effects of buying green

As I mentioned a few days ago, a recent article in Popular Science listed some research that did what might be called confirming the obvious. This article claimed that research has shown that "environmentalists can be smug jerks." I assumed that this was just the editors of Popular Science trying to be controversial and that if I looked at the actual paper that they cite that I might find something different. Here's what I found.

The paper that this article cites is "Do Green Products Make Us Better People?" by Nina Mazar and Chen-Bo Zhong, both of the University of Toronto. Here's the abstract of this paper, which was published in the March 2010 issue of Psychologial Science.

Consumer choices not only reflect price and quality preferences but also social and moral values as witnessed in the remarkable growth of the global market for organic and environmentally friendly products. Building on recent research on behavioral priming and moral regulation, we find that mere exposure to green products and the purchase of them lead to markedly different behavioral consequences. In line with the halo associated with green consumerism, people act more altruistically after mere exposure to green than conventional products. However, people act less altruistically and are more likely to cheat and steal after purchasing green products as opposed to conventional products. Together, the studies show that consumption is more tightly connected to our social and ethical behaviors in directions and domains other than previously thought.

In other words, the Popular Science people may have been trying to be controversial, but they don't seem to have really misrepresented what the research showed.

I have to wonder if generalizations of the Mazar-Zhong research are also true. There are certainly types of computer hardware and software that seem to cause a certain level of smugness in their users and it might be the case that these users compensate for this in some way.

People who drive cars equipped with manual transmissions also seem to feel a meaningless sense of moral superiority over people who can't do this. Maybe they also make up for this by doing bad things. I hope that's not the case. I'm one of those people who feel smug about driving a stick. I'd like to think that this doesn't make me do bad things, but I might be wrong about this.

SHARE in Boston in August

Phil Smith of Voltage will be talking at the SHARE meeting in Boston next month. His talk will be on Tuesday, August 3 from 9:30 - 10:30 am, and the topic is Enterprise Encryption 101. Here's a quick summary of what he'll be talking about:

We've all seen the seemingly weekly news about yet another data breach: millions of credit card numbers, SSNs, or other personal information exposed. Encryption is the technology that minimizes the cost of such data breaches, by making the "leaked" data useless to the thief. So more and more sites are investigating encryption, some even before a breach occurs. But where do you start with this technology? How do you make a sensible choice among dozens of vendors, between hardware and software? Where and when do you encrypt data, and is that sufficient? What about emerging standards and legislation, such as PCI DSS, Red Flag, GLBA, SB1386, Directive 95/46/EC, et al.? Come hear about implementing encryption from a business perspective -- what you need to worry about and how to approach it. This is not a comparison of encryption technologies per se, but rather a look at the issues surrounding them. While the presenter works for an encryption vendor, this is a general presentation, with minor content at the end that discusses the Voltage SecureData product as an example.

If you can't make it to Phil's talk, you can download the slides for his talk here. That's probably not quite the same as seeing the talk in person, but it's probably much cheaper.

Are cars the next Internet?

One big problem with the Internet is that security wasn't in its original design, so that security vendors need to provide products that try to overcome this original oversight. It looks like cars might have this same problem. A recent paper by a group of professors from UCSD and the University of Washington describes some of the security problems that cars have. Here's this paper's abstract:

Abstract—Modern automobiles are no longer mere mechanical devices; they are pervasively monitored and controlled by dozens of digital computers coordinated via internal vehicular networks. While this transformation has driven major advancements in efficiency and safety, it has also introduced a range of new potential risks. In this paper we experimentally evaluate these issues on a modern automobile and demonstrate the fragility of the underlying system structure. We demonstrate that an attacker who is able to infiltrate virtually any Electronic Control Unit (ECU) can leverage this ability to completely circumvent a broad array of safety-critical systems. Over a range of experiments, both in the lab and in road tests, we demonstrate the ability to adversarially control a wide range of automotive functions and completely ignore driver input— including disabling the brakes, selectively braking individual wheels on demand, stopping the engine, and so on. We find that it is possible to bypass rudimentary network security protections within the car, such as maliciously bridging between our car’s two internal subnets. We also present composite attacks that leverage individual weaknesses, including an attack that embeds malicious code in a car’s telematics unit and that will completely erase any evidence of its presence after a crash. Looking forward, we discuss the complex challenges in addressing these vulnerabilities while considering the existing automotive ecosystem.

There may be additional security issues that the automobile manufacturers don't feel comfortable letting researchers discuss in public, of course. But because people are looking at the problem now, it's probably only a matter of time until these issues are addressed, either by the automobile manufacturers or by third-party security vendors.

After reading this paper I was curious about how many processors a typical car has these. The last estimate heard of this was 14, but that was several years ago. After using Google for a few minutes I didn't find that particular bit of information, but I did learn that both the BMW 7 Series and the Mercedes S Series vehicles actually have over 100 microprocessors in them these days. I'd imagine that there's also a fairly sophisticated network connecting those processors, but that's something that I'll probably never get around to learning about.

DARPA's interest in homomorphic encryption

It looks like DARPA is interested in homomorphic encryption. Here's an extract from their recent call for proposals "PROgramming Computation on EncryptEd Data (PROCEED)."

PROgramming Computation on EncryptEd Data (PROCEED)

The Defense Advanced Research Projects Agency is soliciting proposals for innovative research in programming computation on encrypted data. The proposed research should investigate innovative approaches that enable revolutionary advances in science, devices, or systems. Specifically excluded is research that results primarily in evolutionary improvements to the existing state of practice.

Introduction

The goal of the PROCEED research effort is to develop practical methods for computation on encrypted data without decrypting the data and to develop modern programming languages to describe these computations. PROCEED is a comprehensive research effort with six primary research thrusts:

• Mathematical Foundations of Fully Homomorphic Encryption – Discovery and development of new mathematical underpinnings for efficient computation on encrypted data is needed in a noninteractive setting. The solution might involve fully homomorphic encryption [Gentry09, Gentry10, Smart10] that allow noninteractive computation on encrypted data. This area is captured in RA‐10‐80, and interested proposers are referred to that solicitation.

• Mathematical Foundations of Secure Multiparty Computation – Discovery and development of new mathematical underpinnings for efficient computation on encrypted data is needed in an interactive setting. Secure multiparty computation [Yao86, Bickson10] has a rich history of interactive computation on encrypted data, but requires further improvements to be truly practical.

• Mathematical Foundations of Supporting Security Technologies – Computation on encrypted data preserves the confidentiality of the data being computed on, but does not inherently protect the integrity of the computation, nor provide strong protection of the program, among other potentially desirable security goals. Techniques to address these and other related security issues are sought in the PROCEED research effort.

• Implementation/Measurement/Optimization – To make computation on encrypted data practical, highly optimized implementations, possibly including programmable hardware, will be needed. Experience shows there can be at least an order of magnitude difference in the performance of highly optimized cryptography implementations over less sophisticated implementations.

• Algorithms – Practical computation on encrypted data will require libraries of data structures and algorithms that are optimized for efficiency in the encrypted domain. Most current approaches to computation on encrypted data work by turning a program (with a bounded maximum input size) into a circuit.1 An important goal for optimization is minimizing circuit depth, which is traditionally a goal of hardware designers, not programmers.

• Programming Languages – More advanced languages are sought, with type systems that embed cryptographic knowledge, making programming computation on encrypted data no more difficult than conventional programming. Today’s languages for computation on encrypted data, such as the one in the FairPlay system [Malkhi04] are simple, imperative languages that have little, if any, type system support for cryptography.

I've heard lots of people call homomorphic encryption "interesting technology in search of an application," so I wonder exactly why DARPA is interested in this.

The location of the 2011 Key Management Summit

We're starting to look for good places to hold the 2011 Key Management Summit. It will almost certainly be held somewhere on the west coast of the US, and probably in California. We have several sites that we're looking at now that are good candidates for this, but we haven't yet decided which one we'll actually use. So if you're interested in attending this event and have a preference for a location for it, now's the time to let us know.  

RIVYERA from SciEngines

The clever engineers at SciEngines now have an off-the-shelf computer, the RIVYERA S3-5000, that will crack DES in roughly one day. In the unlikely event that you're a hacker who needs to recover DES keys, this is definitely how you'll want to do it. A RIVYERA is roughly 20 times more cost-effective than the EFF's dot-com era DES Cracker.

These RIVYERA machines use 128 Xilinx XC3S5000 FPGAs to get the ability to test 292 billion DES keys per second. That's very impressive. I haven't been involved in building computers for a while, but unless things have changed a lot, it's probably still pretty much like Tracy Kidder describes in The Soul of a New Machine, although I have to wonder if engineers still quit their jobs from the stress of making faster computers, leaving behind only a note that says "I'm going to a commune in Vermont and will deal with no unit of time shorter than a season."

In any case, I'd love to hear the engineers at SciEngines tell the story of how the RIVYERA came to be.

To put things in perspective, however, even at the rate that a RIVYERA S3-5000 can crack DES, cracking a 3DES key will take essentially forever - roughly 200 trillion years. So I doubt that we'll see anything capable of cracking a 3DES key any time soon.

Risk Assessment Methodologies: A Comparison

I came across another interesting report from the Burton Group. This one was "Risk Assessment Methodologies: A Comparison." Here's how they describe their findings:

Bottom Line: The operating phrase for using a risk assessment methodology is a “good starting point.” Enterprises will find value in the U.S. National Institute of Standards and Technology (NIST), Information Systems Audit and Control Association (ISACA), Information Security Forum (ISF), or Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) risk assessment frameworks, but each will need care and feeding for apt use. If system-level assessments are the goal, NIST and ISF are good bets. If enterprise-wide IT or information risk needs consideration, then ISACA's Risk IT should receive attention. OCTAVE's flexibility makes it good for a wide variety of uses, but it comes with some steep homework. Enterprises should choose a framework that correctly targets their assessment scope, complements their chosen control framework, and helps to socialize the risk assessment effort across the organization.

I've always been curious about how the various risk assessment methodologies would compare, and it really shouldn't be too surprising that each has its own particular strengths and weaknesses. After all, if one methodology was clearly better, it would probably end up being the only one used while people would lose interest in the others. So the fact that several methodologies exist is essentially proof that each has some area in which it excels, and this report seems to be a good summary of exactly what those areas are.

The next Key Management Summit

It looks like Terence Spies, the CTO of Voltage, will be the general chair of the next Key Management Summit. As soon as Terence gets a chance to get organized, we'll have a better idea of where and when the next event will be held.

Mercator's thoughts on EMV

In a previous post, I mentioned that when the UK rolled out EMV how card-not-present (CNP) fraud increased so much that the total amount of fraud actually increased instead of decreasing. Apparently the increase in CNP fraud isn’t limited to just the UK. Here’s what the Mercator Group said in their recent report “Encryption, Tokenization and the Top Tier Merchant: A Progress Report on PCI, Deployment and the Cost of Payment Security:”

CNP fraud rates in EMV countries have risen dramatically because of EMV’s effective protection against counterfeit cards. EMV does not address card not present (CNP) risk; it is one layer of security but hardly a blanket solution (there’s no such thing).

The summary of this report also proposes an interesting reality check on EMV:

There is plenty of misinformation swirling around tokenization, encryption and EMV. Some believe that all problems would be solved if only EMV were used in the US. If only that were true. Card number security requires layered defenses and that means using multiple techniques to limit counterfeit credentials (EMV) and to perform the Reverse Rumpelstiltskin of turning our digital gold into straw bits (encryption and tokenization).

There’s lots of other interesting information in this report, and it’s probably worth tracking down a copy if you’re interested in the business of protecting credit card information at large merchants.

Explaining the silence here

It looks like another big credit card processor has signed up to use Voltage's encryption technologies. This time it's Elavon, which means that three of the top five processors (Heartland, Fifth Third and Elavon) are now Voltage customers. Four of the top six POS vendors (Hypercom, Exadigm, UIC, XAC) are also.

This might explain why you don't actually see our sales guys in the office much. When they're not around it's much quieter and easier for the rest of us to work, so I certainly hope that their success in the payments industry continues.

The Dark Side of Cloud Computing

I recently came across an interesting report by the Burton Group - "The Dark Side of Cloud Computing." This report talks about the usual issues that people always talk about around cloud computing (security, vendor lock-in, etc.), but it also had an interesting list of the unintended consequences of cloud computing:

• Data loss
• Predictability of volume
• Core vs. commodity business strategy
• Organization dis-integration
• Inadequate knowledge of internal costs and business capabilities
• Unexpected expenditures
• Inadequate budget forecasting
• Unnecessary risk
• Unintended changes to operational procedures

This report is probably worth tracking down just for the discussion of those unintended consequences.

Webinar - Managing Third Party Data Privacy

Our marketing guys have yet another webinar planned, this time it will be held on June 16, 2010 from 10 am Pacific/1 pm Eastern and will last for 60 minutes. The topic this time is Managing 3rd Party Data Privacy - Protecting Your Own and Your Partners Information. Like some of our previous webinars, this one's also sponsored by FS-ISAC, the Financial Services - Information Sharing and Analysis Center.

Here's what they plan to talk about:

• How to ensure the protection of partner information and confidently manage third-party access to card holder and personal data, including protecting terabytes of files on mainframe and legacy systems
• Why a comprehensive end-to-end approach to data protection is critical to ensure the privacy of personal and sensitive information
• What market-leading organizations — such as AAA — really require in an enterprise data protection solution

The fact that one of the infrastructure consultants for AAA will be talking about his experiences is probably a good enough reason to check out this webinar. Every industry has it's own interesting set of problems that it faces and it's fascinating to see how they find clever uses of IT to solve these problems. I've never dealt with an organization like AAA, so I have no idea of the particular challenges that they face, but I'm certainly looking forward to hearing about them on this webinar.

Is PKI really that bad?

At the recent Key Management Summit, we scheduled a few minutes at the end of each day so that people could get up and talk about whatever issues they felt like talking about. The intent was to provide a way for people to tell the others about ideas that they had had while listening to the various speakers' presentations. I had never seen this done before, but it seemed to work fairly well.

The impromptu session at the end of the second day was particularly interesting. One of the attendees, Ben Gittins, got and asked for opinions on what he had read about PKI. Peter Gutmann, for example, is now working on a new book, and Ben had read a preliminary version of this book's chapter on PKI. Apparently Peter's new book does not describe PKI in a positive way (if you're familiar with Peter's thoughts on PKI, you'll know that that's a huge understatement), and Ben wanted to know if we really thought that PKI was as bad as Peter describes it to be.

It didn't take long for the group to reach a consensus. A few people simply said, "Yes, it really is." That's about as far as the discussion got. After that, there really wasn't much more to say.

It's not the crypto that's too hard

At the recent Key Management Summit, one theme that was mentioned frequently was how difficult it is for people to implement encryption in a secure way in their businesses. I heard lots of horror stories about how various IT organizations would try to add encryption to some sort of business application and do this in a way that had all sorts of security problems. Although many of the IT organizations had a reasonable understanding of encryption, they didn't really understand how keys need to be managed securely for the encryption to provide a useful level of protection.

Maybe we've reached a point where lots of people working in IT understand basic crypto concepts, but we apparently haven't reached a point where the same people understand basic key management concepts. It probably took about 10 years for a basic understanding of encryption to work its way into the IT world. I wonder how long it will take for the same level of understanding of key management to do the same.

Lots and lots of keys

The Key Management Summit has always been part of the IEEE Symposium on Mass Storage Systems and Technologies. This is mostly for historical reasons: the biggest use for key management products today is managing the keys use to encrypt storage: tape drives, disk drives, etc. The same vendors interested in mass storage systems were also interested in key management, so the two meetings seemed to fit together well.

From what I heard at this year's Key Management Summit, the connection between mass storage and key management may get even stronger in the future. The concensus of the participants in the KMS was that within 10 years it will not be uncommon for key management products to be managing at least one trillion keys. That's a lot of keys, and it will take at least several terabytes of storage just to hold them all.

Maybe it's time for people to take a closer look at key derivation functions. If you use a KDF instead of generating all of your keys randomly, you just need to store and securely backup the master secrets that are used in the KDF. That can reduce the amount of storage that you need from several terabytes down to a few dozen bytes. KDFs are useful today. Maybe they'll be even more useful in the future.

Hyperelliptic curves

Hyperelliptic curves are interesting for many reasons. The reason that we’re particularly interested in them at Voltage is that you can implement pairings using them and it might turn out that pairings on hyperelliptic curves can be more efficient than pairings on elliptic curves.

An elliptic curve is the set of points defined by an equation like

y² = x³ + ax + b

This gives you a structure that’s much like a torus – a shape that has a single hole in it, like a doughnut.

A hyperelliptic curve is defined by an equation like

y² = f(x)

where f is a monic polynomial of degree 2g + 1.

(There's really no reason to restrict the degree of f to being odd, and a polynomial of degree 2g + 2 will also work just as well. This makes some things trickier, so most people just stick to the odd degree case. One complication is that you actually get two different points at infinity instead of just one. More about that in a future post.)

When g = 1 this reduces to an elliptic curve, but the term “hyperelliptic curve” is usually reserved for the case where g is 2 or greater.

The number g defines the genus of the curve, a number which tells you how many holes the structure corresponding to an elliptic curve’s torus has. If the genus is 2, then the curve has a structure much like a doughnut with 2 holes, etc. The graph above is the graph of a hyperelliptic curve of genus 2.

Working with hyperelliptic curves causes some problems that aren’t there for elliptic curves. It’s possible to easily define a way to add points on an elliptic curve using the usual connect-the-dots algorithm, but this can’t be done for hyperelliptic curves. It’s possible, however, to add sets of g points on a hyperelliptic curve instead of single points. On a curve of genus 2, for example, we might add P = {P₁,P₂} to Q = {Q₁,Q₂} to get R = {R₁,R₂}. (Note that I've used brackets here instead of parentheses to make the notation more set-like. The order in which you list the elements isn't important for a set, and the order of the points isn't important here, either.)

The way that we add these sets of points is by thinking them as divisors, so that we're really adding divisors instead of adding points on a curve. The set of divisors on a curve, along with the rule that defines how to add them is called the Jacobian of the curve.

For a curve of genus g, we can reduce any divisor to one no bigger than one of the form

∑_i=1:g(P_i) – g(O)

For a curve of genus g = 2, for example, we can reduce any divisor to one like

P = (P₁) + (P₂) – 2(O)

So that when we calculate something like

P + Q = R

for a hyperelliptic curve we actually calculating

(P₁) + (P₂) – 2(O) + (Q₁) + (Q₂) – 2(O) = (R₁) + (R₂) – 2(O)

How we find R₁ and R₂ from P₁, P₂, Q₁ and Q₂ is very similar to how we add points on an elliptic curve. In the case of an elliptic curve, we fit a line through two points, find the third point where the line intersects the curve, and reflect this point across the x-axis.

In the case of a hyperelliptic curve of genus 2, we fit a cubic polynomial to the points P₁, P₂, Q₁ and Q₂. We then find the two additional points where this polynomial intersects the curve and then reflect each of those points across the x-axis to get R₁ and R₂. Here’s a picture that shows what it looks like when we add to points P (the red points) and Q (the green points) to get R (the black points).

Because doing operations on hyperelliptic curves are defined in terms of divisors, it shouldn't be much of a surprise that pairings, that are also calculated using divisors, work just as well on hyperelliptic curves as they do on elliptic curves. That means hyperelliptic curves might end up be useful in pairing-based cryptography. If there's a good use for them, they'll probably appear in Voltage's products in the future. Right now, however, elliptic curves seem to be good enough.

Pathetic spammers

I received another one of those annoying spam emails from one of those operations that will include you in their exclusive Who's Who book because of your significant contributions to your field (i.e., having a valid email address). This particular spam, however, was apparently from "Satellite TV Quote." So it looks to me like some spammer couldn't quite keep his scams straight and included text from one scam in a message designed for another scam.

Come on, spammers, at least make a reasonable effort to make your messages look legitimate.

A new approach to outsourcing

According to the BBC, government officials in India have developed a new approach to outsourcing. This involves using prisoners in jails to run outsourced IT operations. The first projects planned to be run are actually the back-office systems for banks. I'm not entirely sure that's a good idea.

A new approach to fighting spam?

Spam and the uncertainty that spam filters cause has dramatically reduced the effectiveness one of the most popular uses of the Internet. Maybe it’s time for a different approach to filtering email.

Phones and email are both about equally useful: given the choice between giving up their phone of giving up email, people are about evenly divided. When comparing e-mail to other Internet technologies, however, it's no contest. Given the choice between giving up email and giving up browser-based web access, people cheerfully give forgo the web in favor of email. The web may be nice to have, but email is a necessity, and most businesses really can’t function without it.

Unfortunately, almost all of today’s email traffic is spam so it’s necessary to separate the spam from the legitimate messages before they get to users’ inboxes. If you don’t do that, users are quickly overwhelmed by the sheer volume of spam that they receive.

Spammers are clever, however, and quickly find a way to get around the latest updates to spam filtering software. That’s possible because filtering applications use the latest models of what spam looks like to help them decide whether or not to let a message pass. Once spammers learn what filters look for, they quickly invent a way to get their spam past the filters.

Maybe an entirely new approach to filtering email is needed, and the fact that most email is actually spam may be the insight that we need for this. In particular, instead of trying to identify spam, why not try to identify legitimate email messages instead?

Note that this is entirely different from white-listing. With white-listing, an approved list of names, domains or IP addresses is used to allow incoming email. Instead, this approach looks at the content of an email and tries to decide if a particular message is legitimate. White listing doesn’t look for valid email messages. An entirely different model may be needed to do that.

Information security vendors have spent lots of time and effort over the past several years developing ways to identify spam. The benefits of this research have been temporary at best because spammers quickly learn to avoid the most recent versions of anti-spam filters. But while the arms race between spammers and anti-spam vendors has led to all sorts of unusual messages that are designed to pass filters undetected, the format of legitimate emails hasn’t changed much at all, and because of this, identifying legitimate emails may be a better strategy than identifying spam.

Looking for legitimate emails seems to be very simple to implement because it can be done with a minimal change to existing networks. All that’s needed is different logic on anti-spam filtering products. Everything else can stay the same. That seems much simpler than some of the alternatives that have been proposed. Simple is definitely good. It might even be effective.

I haven't heard of this approach being used. Maybe there's some obvious reason why it won't work.

Zipf's law for data breaches

As we've seen in previous posts, there's lots of structure in the available data on data breaches. In particular, the size of data breaches seems to follow a lognormal distribution as well as Benford's law. It looks like we can add a third law that this data follows, and that's Zipf's law.

Suppose that we rank our data from largest to smallest. Zipf's law tells us that if we plot the log of the data versus the log of the rank we get a straight line. Zipf's law was first formulated based on the observation by linguist George Zipf that the frequency of words is inversely proportional to the rank of the word in a word frequency table. It also seems to hold for other data sets, like the size of US cities.

Let's look at the  the data breaches from 2007 through 2009 that are listed in the OSF's data breach database. Here's what we get when when we plot the log of the rank of a breach versus the log of the size of the breach. The blue dots represent actual data breaches. The red dots are what we get from fitting a straight line to the log-log data.

 
Although the fit is much better for the breaches that aren't either too big or too small, the line actually fits the overall data fairly well, having a correlation coefficient R² = 0.873.

Applying Shamir's Third Law

Shamir's Third Law tells us that cryptography is always bypassed instead of beaten. Here's an example of why this is true.

Suppose that you're a hacker who wants to sell credit card numbers on the black market, but all of the credit card numbers that you can get are encrypted with DES. Not Triple-DES, but the old, obsolete DES that only gives you 56 bits of strength. The same encryption algorithm that everyone dismisses as being way too weak to use.

The most cost-effective way to crack DES is probably with a COPACOPBANA machine. One of these costs about $25,000 and can find a DES key in an average of about 6.4 days. These aren't quite as fast as the DES Cracker that the EFF built back in 1998, but they're much cheaper. The TCO of computer systems is always higher than the cost of just the hardware and software, but let's ignore that for purposes of this exercise.

A COPACOBANA machine will recover about 57 DES keys per year. Over three years, this will get us about 171 DES keys at a cost of $25,000, or about $146 per key. So if you're a hacker who wants to resell the credit card numbers that you decrypt you'll need to get at least $146 for them, and that's just to break even.

According to researchers who monitor black markets, credit card numbers are worth nowhere near $146 each. Estimates that I've seen recently say that they're worth anywhere from $3 to $20 each. That's much less that what it will cost a hacker to recover them by cracking DES, so he won't try to do it. He'll find a way to bypass the encryption instead, just like Shamir's Third Law tells us.

Finding primes

In cryptography, we often need to find large prime numbers. One way to do this is to pick random numbers that are the right size until you find one that's a prime. This might take a while when we're working with numbers that are as big as the ones that we typically use in cryptography. How long will this take?

One way to answer that question is by using the prime number theorem. Let the function π(x) be the number of primes less than or equal to x. The prime number theorem says that lim_x→∞π(x) / (x / log x) = 1, or that x / log x is a good approximation to π(x) for large values of x.

Here's how well π(x) (black) and x / log x (red) agree:

An even better approximation to π(x) is x / (log x + 1). Here's how well π(x) (black) and x / (log x + 1) (green) agree:

But since for numbers of the sizes that we often use in cryptography log x and log x + 1 are fairly close, so we can use the easier approximation without worrying too much.

One consequence of the prime number theorem is that the probability of a number n being prime is roughly 1 / log n. Here's what log n looks like for numbers that are the sizes of those that we often use in cryptography:

n	log n
2512	354.891
21,024	709.783
21,536	1064.67

So suppose that we want to generate two random 512-bit primes, like we might need to create a 1,024-bit RSA modulus. The chances of a randomly-chosen 512-bit integer being prime is about 1 in 355, so that we'd expect to find a prime in about 355/2, or about 177 attempts.

This obviously isn't the best strategy: half of randomly-chosen integers will be even, so we don't want to waste time considering them. If we look at only odd integers, this will reduce the expected number of trials by 1/2, or down to about 89 attempts. We could even continue this strategy for other small primes. One-third of randomly-chosen integers are multiples of 3, for example, so we might not want to consider multiples of 3, etc. But for the simple strategy of just trying random odd 512-bit integers, we should expect to find a 512-bit prime in about 89 tries.

Is cloud security a distraction?

An alert reader recently pointed me to an on-line comment that said the following about using computers in the classroom:

My school district blocks content but students are very good at finding and sharing proxy sites. They are also not as tech savvy as administrators and school board members seem to think they are. They are no more interested in using the laptops to learn than they are in using books. The laptops simply give them a more exciting way to be off task.

The alert reader then suggested that a similar comment about cloud computing security might be appropriate. Something like "CIOs are no more interested in cloud security than they are in other aspects of security. Cloud security just gives them a more exciting way to waste time."

I don't know how well it's actually understood by CIOs, but one of the biggest security challenges of cloud computing, is also the easiest to solve, and that's the problem of not exposing sensitive data in cloud computing environments. If you just encrypt your sensitive data that goes into the cloud then most of your problems disappear. That's not wasting time. It's solving a real security problem.

The main reason that all of your problems don't totally disappear is that key management is still a problem. There's actually a good discussion of this in the report Using Encryption to Protect Sensitive Data in Cloud Computing Environments that's available from the Burton Group. That's why Voltage is now developing key management technologies that work well in cloud computing. We have some fairly good solutions or this right now and we'll have some even better ones soon.

You'll probably see those discussed at future Voltage webinars.

Usability lessons from Progress Quest

Voltage is known for its innovative encryption technologies, but we're also known for how easy our products are to use. Not too many years ago, it was extremely hard for the average person to encrypt their email. The classic paper "Why Johnny Can't Encrypt" describes exactly how hard this can be for a typical user and anyone interested in the usability of encryption should read it.

With Voltage's SecureMail, on the other hand, a user doesn't have to do anything more than click on the "Send Secure" button instead of the "Send" button. If you're implementing SecureMail at a gateway appliance, they don't even have to do that – it can just happen automatically. Decrypting is just as easy.

Because we worry so much about the usability of our products, I'm very interested in seeing any enterprise security products that might actually be easier to use than SecureMail. If we ever find one of these, we'll probably be able to learn a thing or two from it. That's why I got so excited when I recently learned of an application that may actually be easier to use than SecureMail. In this case, however, it's not enterprise software. It's the game Progress Quest.

Progress Quest is a massively multiplayer online role-playing game (MMORPG). Before I heard of Progress Quest, I had never actually played a MMORPG, but that didn't stop me from being a government expert on the topic. I say that because I was actually the invited speaker at a government workshop on MMORPGs a couple of years ago. Unfortunately, the fact that I had to sign an NDA for this event means that I can't say much more about it.

Here's how the manual for Progress Quest describes the game:

Progress Quest is a next generation computer role-playing game. Gamers who have played modern online role-playing games, or almost any computer role-playing game, or who have at any time installed or upgraded their operating system, will find themselves incredibly comfortable with Progress Quest's very familiar gameplay. Progress Quest follows reverently in the footsteps of recent smash hit online worlds, but is careful to streamline the more tedious aspects of those offerings. Players will still have the satisfaction of building their character from a ninety-pound level 1 teenager, to an incredibly puissant, magically imbued warrior, well able to snuff out the lives of a barnload of bugbears without need of so much as a lunch break. Yet, gone are the tedious micromanagement and other frustrations common to that older generation of RPG's.

You start Progress Quest by picking the class and race of the character that you'll be playing. After that, the game does everything else for you. I even created a Progress Quest character: Elrond Hubbard, a Demicanadian Ur-Paladin with a name that's almost funny. If you're more adventurous you can pick races like Double Wookiee or Enchanted Motorcycle and classes like Fighter/Organist or Battle-Felon. I wasn't.

If you let Progress Quest run, your character will gradually increase in power and gain useful magical treasures. As I write this, Elrond Hubbard is currently Level 60 and has +23 Fine Gilded Plasma Vambraces. I'm not really sure if that's good or bad, but I certainly didn't have to pay any $9.95 monthly fees to get my character to where he is now.

Surprisingly enough, or at least surprisingly enough to surprise to a one-time government expert like me, Progress Quest seems to be fairly popular. The good reviews of it dramatically outnumber the bad reviews. And that's for a game where the player does absolutely nothing.

I'm never surprised to learn that most people really don't want to worry about encryption at all - they're too busy doing their jobs to worry about fighting with software that's hard to use. But I never would have thought that people would actually enjoy a game in which they do absolutely nothing.

In any event, I suppose that the bottom line is that we haven't quite figured out what we can learn from Progress Quest that will help us make SecureMail better, but that doesn't mean that we won't keep trying.

(If anyone wants to quote me about Progress Quest, here's my position on it: "Of all the games available for the PC, this is one of them.")

What were they thinking?

In a previous post, I noted a new social networking site called Blippy that basically lets you see what your friends are buying. Maybe if you're too young to remember the dot-com era, that sounds like a perfectly reasonable thing to do. To me it just sounds like a huge privacy problem just waiting to happen.

According the what's posted on Blippy's web site, the problems have already started. In particular, it looks like Blippy incorrectly considered raw transaction data to be harmless at one point, and some of it ended up the HTML on some of their web pages.

Yikes!

Blippy has a five-step plan for making sure that this doesn't happen again:

1. Hire a Chief Security Officer and associated staff that will focus solely on issues relating to information security.
2. Have regular 3rd-party infrastructure & application security audits.
3. Continue to invest in systems to aggressively filter out sensitive information.
4. Control caching of information in search engines.
5. Create a security and privacy center that contains information about what we are doing to protect you.

These steps look like a good move in the right direction, but why weren't these done in the first place? And with all the news about PCI DSS these days, who could possibly have thought that credit card transaction data wasn't sensitive and needed to be protected?

An unusual requirement for encryption

I recently came across what I thought was an unusual requirement for an enterprise encryption product. I heard this from the CEO of a company that wasn't encrypting their email yet and didn't plan to do so until they could find a product that met all of the CEO's requirements.

The particular requirement that I found somewhat surprising was that the user of an email encryption product would automatically be notified if a hacker somehow managed to decrypt an encrypted message.

I won't say that this is impossible to do, because someone might actually invent a clever way to do this some day, but it certainly seems as close to impossible as you can get. I certainly don't know of a good way to do it. But because they couldn't find a product that had this particular feature, at least one company out there isn't encrypting email messages that contains sensitive information.

The use of encryption has become much more widespread than it was just a few years ago, but there are still lots of cases where it's not used much. I have to wonder how much the adoption of encryption is being slowed by requirements that really aren't very practical.

Science 2.0

I read an interesting article “Science 2.0 -- Is Open Access Science the Future?” in Scientific American a while ago. This article essentially asked whether or not the easy collaboration that the Internet allows will be a good thing or a bad thing for science. Interestingly, this article was actually based on comments that the on-line article, “Science 2.0: Great New Tool, or Great Risk?” received on the Scientific American web site, so it’s actually an example of the very type of collaboration that it talks about.

Supporters of open and collaborative science claim that it’s inherently more productive. That's definitely good. Critics of it say that if scientists aren’t careful then open and collaborative work can lead to ideas being stolen. Less-than-ethical people might take credit for someone else’s work. They might even patent it. That's definitely bad.

I personally wouldn’t want every step of my research published on-line, say in a blog or on Twitter. This is because when I’ve had jobs where I did research I found that for each good idea I had I also had several bad ideas, and if I openly talked about all of the bad ideas I’d probably look fairly foolish. On the other hand, I can also think of one particular case where someone might have pointed out a mistake that I was making and saved me six months of frustration. Overall, though, I don’t think that I’d like Science 2.0.

It seems to me that there are really two outputs from research: new knowledge and the people who understand what it took to gain the new knowledge. And it seems to me that although you might still get the first of these two with Science 2.0, the second really wouldn’t be the same. I believe that I learned more from my failures than from the successes, and that if you took away the pain of the failures, you’d also take away most of what you really learn from doing research. You might reach the end more quickly with Science 2.0, but the people doing the research wouldn’t get the same benefits from getting there as they would otherwise. In the long run, this will probably erode the ability of people to actually do significant research.

It will probably take a while to see whether open and collaborative research works or not, but you might wonder how the same approach might work for information security. That’s one area where openness is strongly encouraged. The principle that security technologies should be fairly open has been known for over 150 years and is essentially codified in Kerckhoffs’ principle.

Maybe we’re really already there. Although you won’t hear about the details of the research on Twitter, you can already find electronic publication copies of lots of research in cryptography on the IACR’s e-print server. These papers may not be the exact version that gets published, but they’re very close, and they definitely contain all of the new ideas, even if a few of the details of how they’re presented may eventually change.

Come to think of it, you can also get electronic copies of papers in other fields also. The Cornell University Library’s arXiv e-print server now has close to 600,000 papers from physics, computer science and mathematics. There are probably other similar sources out there that I don’t know about.

I don’t really see people doing many blog posts or tweets about the details of their research while I do see lots of papers becoming available on pre-print servers, so I suspect that’s where Science 2.0 is really headed.

That's a lot of tax

A bit of tax trivia. It's based on the data in Wikipedia, so I can't guarantee its accuracy, but according to the leading collaborative reference web site, the country of East Timor, sometimes known as Timore-Leste, has the world's highest tax revenue as a fraction of GDP. In the case of East Timor, it's actually 109.7%.

So it's no wonder there aren't many Voltage customers there. The TCO of our products may be a factor of three or more less than competing products, but when you're paying that much tax, it's probably even hard to justify buying SecureMail.

Thoughts on the PBA attack on RSA

The recent PBA attack on RSA signatures has much in common with software-based attacks like SQL injection, buffer overflows, and cross-site scripting. In all of these cases, an attack can only work if data isn't properly validated. With the software attacks, we're learning how to handle these. Teaching programmers to think in terms of all data being designed with the express purpose of breaking their code is a big part of this. That's why Voltage regularly does training on secure coding practices for its engineers. It looks like this point of view isn't being taught to hardware engineers yet.

The PBA attack worked by varying the input voltage to an operating piece of hardware. And just like an application can be vulnerable to a SQL injection attack if it doesn't adequately validate user-input data, the hardware that implements RSA signatures can be vulnerable to the PBA attack if it doesn't validate all of its inputs. In this particular case, the relevant input was the power supply voltage for a device. I don't know for sure, but I'd guess that the specification for the hardware that was used to demonstrate the PBA attack specified correct operation for some range of input voltages, but didn't specify exactly how it would handle voltages outside that range.

A way to handle this is much like the white-listing approach to filtering data to prevent XSS attacks. In the case of white-listing, only certain inputs are allowed. A similar approach to hardware might guarantee operation over a certain range of parameters (voltage, temperature, clock speed, etc.) and also guarantee well-defined behavior outside those ranges. It's well known that hackers can cause all sorts of interesting behavior in hardware by varying parameters like voltage, temperature and clock speed, so it might be appropriate to also specify well-defined behavior outside the specified ranges.

When Security Measures Don't Catch Anyone

Suppose you implement a security measure. Maybe it's a home alarm, maybe it's a security checkpoint before entering a building, it might even be putting tighter login requirements to a network.

You now sit back and wait to see how many people you catch. How many thieves trip your alarm and are hauled off to jail? How many corporate spies are now discovered at the checkpoint? How many crackers are denied entry into your network because of the new login protocol?

Suppose there are none. Why is that? I would imagine there are three main reasons.

1. No one was trying to break in before and no one is trying to break in now.
2. The security measures are not working.
3. Anyone who might try to break in sees the new measures and does not try to infiltrate, or at least does not try to infiltrate at that point.

Let's look at number 3 with a story about people improperly using a parking lot. Voltage HQ is in an office complex near a high school. Every morning when school is in session, there's a security guard standing at the entrance to the parking lot nearest the high school. In the past, parents dropping their kids off would turn around in the parking lot, creating congestion for the valid tenants. A sign posted saying the parking lot is not for turning around apparently did not do the trick. So the building owners have to hire a security guard to watch the people entering the parking lot.

Every morning, the security guard does nothing but stand there. With him there, no one tries to improperly use the parking lot. The moral of the story? Implement a security measure and you don't need it. Don't implement and you need it.

A recent episode of "Real Sports with Bryant Gumbel" supplies another example. The show reported on the governing body charged with enforcing drug rules for US Olympic (and potential Olympic) athletes. The program makes life much more difficult for the athletes, and some think it is not a successful program. The measure of failure is that very few athletes have been caught using banned substances. However, another explanation for the low rate of capture, is that people don't try to cheat if they think there is a good chance they'll get caught.

Some people try to use fake security for this very reason. Maybe they've seen that burglers rarely rob houses with Pit Bulls, Rottweilers, or German Shepherds. So they put up signs announcing a guard dog on duty, even when there is none. Fake surveillance cameras, signs declaring a home security system is installed, mannequins, recordings of people noise, and randomly turning lights on and off are supposed to make the bad guys move on to an easier target.

My guess is, such fake security is easily found out to be fake. It's probably a case that if you want security, you pretty much have to pony up for it.

In IT, fake security would work even less effectively. Someone might not pay for email encryption, but still say, "You can't read this email, it's encrypted." It would take very little effort to see that the statement is false. How about someone announcing that they have just implemented new measures to protect credit card numbers while in storage. That might thwart attackers for all of 10 minutes.

In IT, if you want security, fake won't do it. Besides, some attackers will be attracted to an enterprise that announces security, it's a challenge. They will test it immediately and of course, see immediately if it is fake.

So in IT, if you implement security measures, and describe exactly what they are, some attackers will indeed move on. Others will try to break it anyway, and others still will not have heard the announcement and will try to break in anyway. And then others will look for other vulnerabilities.

It seems to me, though, that if you have some metrics on attack attempts, employing security might cause those numbers to go down. Then you might feel as if the problem has gotten so much smaller, that you're spending too much money.

This is why it's probably a bit more difficult to sell security. If you don't have it, you see a problem. If you do have it, it looks as if the problem went away, so why spend money on it?

But the real way to look at is this: "We had a problem, we spent money on security, and the problem is now gone. The security worked."

Following security policies

I just heard an interesting story that may show why having checklists for security isn't quite as good as having people use their good judgment to carry out the intent of security policies. This story concerned the way in which the TSA apparently inspected a traveler's luggage.

The storyteller's wife was recently flying from Albuquerque to San Jose. Knowing that the TSA randomly inspects luggage, she didn't lock the bags shut. Instead, she fastened the lock that came with her bag to one of the pull tabs of the zipper. This didn't stop the zipper from functioning, of course. To lock a bag shut you need to run the lock through two pull tabs. A lock on a single pull tab just makes a fancier pull tab and doesn't actually stop anyone from getting into your luggage.

When she got home, she noticed that the pull tabs of the bag had been torn from the bag, which contained a note from the TSA explaining how they had opened her bag for inspection. Apparently, the TSA just rips off any locks on luggage, even if they're not actually locking anything shut, and it doesn't leave it to the judgment of an individual TSA employee to decide whether or not a particular lock actually needs to be ripped off.

Data Masking: Runtime Data Aliasing

I just read an interesting Burton Group report Data Masking: Runtime Data Aliasing. Here's a high-level summary of the report's findings:

Bottom Line: Enterprises should increase their focus on developing an information-centric security strategy. Data aliasing can be used to reduce the amount of confidential data processed and the number of locations it's stored. Runtime data aliasing is the reversible replacement of confidential data with similarly formatted surrogates. Data can be aliased using format-preserving encryption or (pseudo) random replacement using a lookup database. Data modeling and architectural concerns drive the design and implementation of the enterprise data aliasing solution. Data aliasing can complement or replace traditional application- and database-level encryption used or considered by the enterprise.

This report does an excellent job of comparing and contrasting the different ways (suppression, redaction, aliasing and anonymization) to do data masking. Here's how this report summarizes these techniques:

Data masking method	Security and privacy properties	Data Management Properties
Suppression	Completely removing a set of data items to protect it from disclosure, as well as many privacy attacks, although some privacy attacks may make use of relationships with or in the unsuppressed items.	Alters the semantic value of the data by making data values inaccessible to applications.
Redaction	Irreversibly blocking part or all of a data item to protect a data item from full or partial disclosure, but which—although it often destroys relationships to other data—does not necessarily protect data from all privacy attacks.	Offers better context preservation than suppression but the semantic value of the remaining text may be incorrect or misleading.
Aliasing (pseudonymization)	Reversibly transforming part or all of a data item to protect a data item from full or partial disclosure, but which is not designed to protect data from all privacy attacks (e.g., inference attacks) because data relationships may be maintained.	Offers better context preservation than suppression but the semantic value of the remaining text may be incorrect or misleading.
Anonymization	Manipulating data to maintain desired information properties, using a combination of methods that is designed to create an irreversible transform resistant to disclosure and privacy attacks.	Best for semantic behavior preservation and certain statistical behavioral measures although the resultant data may be unsuitable for testing application logic.

This is the first time that I've seen a careful description of the different ways to mask sensitive data. There's more anaylsis of the strengths and weaknesses of each of the four approaches to data masking in this report. It looks like you can't buy a copy of this report from the Burton Group's web site - you might only be able to get a copy if you subscribe to their service. I hope that there are other ways for people to get copies of this report. It's definitely worth reading.

You can also contact the author of the report, Ramon Krikken (ramonkrikken on Twitter) if you have more questions about this report.  

Hacking hotels

According to a recent article in The Wall Street Journal, more credit card information is being stolen from hotels than from any other industry. This probably explains why Marriott is now involved in ASC X9F, the group that writes information security standards for the American financial services industry.

I wasn't quite sure why Marriott decided to get involved in security standards. Few users of security technology do. Most just leave it to security vendors to figure out how things ought to work. In light of the recent WSJ article, Marriott's participation in X9F makes a lot more sense. Other users ought to follow their lead in this area and make sure that their voices are heard.

If you don't get involved in the definition of standards then you shouldn't complain about them once they're done.

Key recovery vs. key escrow

An alert reader recently pointed out an interesting blog post that proposes a list of "red flags" that people should watch for when selecting a secure email solution. Apparently unhappy with this particular post, this reader suggested that the list of red flags in the interesting post be amended to include the following:

Red Flag #19. Alleged critics who disguise their opinions in pseudo scientific postings and don't declare their vested interest in competing firms and technology should not be trusted.

Red Flag #20. Industry Experts who quote themselves and reference only their own works in publications should not be trusted.

Red Flag #21. 4 year old competitive analysis papers do not have contemporary value.

I can't vouch for whether or not these additional red flags make sense or not, but I have to say that I was a bit puzzled by this particular red flag that the post mentioned:

Red Flag #3: It Just Works. Beware of hidden liabilities. For example, make sure that your keys are not escrowed in the servers providing the solution, as with IBE (Voltage). Nothing is safe in servers, not only from attackers but also from service providers and employees.

There's a big difference between the ability to do key recovery and key escrow, and this blog post (as well as some of the white papers available from the blog's web site) seems to badly confuse the two. Voltage's SecureMail lets you do key recovery. It doesn't do key escrow.

Key recovery lets you backup and restore cryptographic keys. If your CIO gets hit by a bus and you need access to their encrypted data, key recovery lets you do that. It also lets you recover your systems in the event of a failure, like a natural disaster might cause. Note the use of "you" here. A business doing key recovery backs up and restores their keys as needed and nobody else has access to these keys. Key recovery is often necessary for all sorts of legal and regulatory reasons, so it's a necessary feature of any enterprise encryption product.

With key escrow, on the other hand, a third-party gets copies of a cryptographic key. The US government led the push for key escrow back in the pre-dot-com era. The idea was for law enforcement agencies to have the ability to decrypt encrypted messages if they had the necessary court order. There was even talk of laws requiring all encryption to have this feature. It turned out that people weren't comfortable with the government having this ability and that technical problems plagued the proposed escrow schemes. In the end, the idea failed terribly. It's definitely not a feature that enterprise encryption products need.

Because IBE lets you calculate any private keys that you need, it makes key recovery easy. And because you can calculate any private keys that you need, you'll never be doing key escrow with IBE.

Key recovery is necessary. Key escrow isn't. Let's not confuse the two.