Superconductor

It's not just software

Software is notoriously behind schedule, but my experience with book publishers tells me that it's not just software that has this problem. Starting in 1999, for example, F. Paul Wilson wrote a series of five novellas about a future in which almost-human genetically-engineered beings called "Sims" exist and cause the usual moral complications and intrigue that you'd expect in a work of science-fiction. He eventually consolided these novellas into a single novel which came out in 2003. The fifth of these novellas ended up being delayed for some reason and was actually just published this year, at least seven years after it was completed.

Just like there's usually a good reason why software is delayed, I'm sure that there's a prefectly good reason why the fifth Sims novella was delayed that long. I can't think of what it could possibly be, but it's sort of reassuring to see that big, unexpected delays aren't just something that you see with software.  

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.

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.

900D n19h7, mR. h0Lm32

It looks like we may have come a complete circle, from paper to digital and finally back to paper. Something that I recently stumbled across leads me to say this (although I really don't believe it).

In the Sherlock Holmes stories, for example, Holmes often gives his card to people to introduce himself. Maybe that's only in the Granada TV version of the stories. I can't quite keep straight the details of what I saw on TV and what I read because it's been so long since I read or saw either of them. In any event, Holmes certainly didn't send email or ask people to become his Facebook friends. He definitely didn't use Twitter. That sort of thing came much later. Holmes was definitely focused on printed ways to communicate.

It looks like Knock Knock, a store that sells that paper and paper products now has a paper-based answer to Twittter: Paper Tweet, pads of note paper that are marked with a grid of 140 characters so that your paper-based notes will have the same constraints as your tweets.

Maybe these are just meant to be clever gifts. I'm not sure that I'd want to leave an important message for someone on a piece of paper that's clearly labeled "PAPER TWEET." That's what Post-It Notes (preferably yellow) are for, after all.

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.

The tree house model of software engineering

When I was a kid I had a tree house. What I built ended up with looked something like the one shown here, but with only one level. It seemed like a good idea at the time, but what I really ended up with was a hideous blob of boards that looked like they had been nailed to a tree in some sort of random pattern. Looking at that picture more than reminds me of my own tree house; it also reminds me of designing software.

Just like I thought I was building a good, solid tree house, software architects think that they're designing useful and elegant software. Andjust like I realize that the tree house that I built back then wasn't really as good as I thought it was, the software that we're getting these days really isn't as good as it could be.

There are probably lots of good pictures of ugly tree houses on the Internet. Maybe I'll find a particularly dramatic one to use the next time that I have to give a talk about software engineering.

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!

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.  

We're now well into 2010 and it's still obviously wrong

In a previous post I mentioned how storage vendors were predicting that the amount of information would be doubling every 11 hours by the year 2010. They were saying this to get you to buy their products to help you keep pace with that overwhelming amount of information, of course.

We're now well into 2010 and it should be fairly clear by now that the amount of information really isn't doubling every 11 hours. It actually should have been obvious to most people that this particular claim was obviously wrong, but that didn't stop it from getting published in a few academic papers and being widely cited by storage vendors.

This led me to develop the following warning label that could be included in papers of questionable accuracy:

 

I'm not really sure that many editors of all publications really worry about the accuracy of what they publish, however. I used to review submissions to a few publications, but after I recommended that they not publish various submissions because they were just plain wrong, the editors stopped asking me to review submissions for them.

There's certainly a place for discussing controversial ideas, but I really don't like the idea of getting things into print that are obviously wrong, like the wildly inaccurate claim that the amount of information would be doubling every 11 hours by the year 2010. I would have recommended that that particular paper not be accepted. Apparently someone else didn't think so.

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.

Stand on Zanzibar

I just finished an interesting book, Stand on Zanzibar, by John Brunner. It's about a dystopian future in which the Earth's population grows to the point that governments take all sorts of extremely draconian measures to keep it in check. It was published in 1968 but is set in the year 2010, and it's interesting to see how accurate Brunner's predictions of the future were. Like in any other work of speculative fiction, he managed to get a few things right but he also got others totally wrong. In general, Brunner's vision of the year 2010 is very different from the real 2010. It may not be as different as George Orwell's vision of the year 1984 was from the real 1984, but it really didn't seem very close.

I also read this book because I managed to get a copy that was published in 2009 yet autographed by Brunner, who died in 1995. It seems that before he died he signed some signature pages for a book that never got published, and that the most recent publisher managed to get ahold of these and use them in their edition of Stand on Zanzibar.

It looked to me like Brunner totally missed the affects of IT on society. Or maybe he didn't. Brunner wrote Stand on Zanzibar to point out how overpopulation could end up being a problem. It wasn't meant to point out how the rise of IT could cause a dramatic decrease in privacy. I actually don't know of any books that focus on that particular angle, but I'd probably read one if someone wrote it.

I'm sure that it wouldn't be too hard to extrapolate from the dramatic loss of privacy that we've seen happen in the past decade to the point that it would make the basis for an interesting story. It's not clear to me, however, whether such a story would be better classified as science-fiction or as horror.

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.

Governments do worry about costs

I recently had an interesting discussion about the huge amounts of money that governments spend on IT projects. The US government alone, for example, has spent over $1 billion on PKI and doesn't seem to have $1 billion of value to show for this investment.

In this discussion, I claimed that the government just isn't sensitive to costs. The other person, who happens to be a government employee, claimed that I was wrong. He claimed that governments are indeed sentitive to costs - they're just not sensitive to bad ideas. That's a distinction that I hadn't heard before.

The dentist's office effect

I just came across what I call the "dentist's office effect" again. This happens to me when I'm waiting in my dentist's office for my appointment and I end up surprised by the reading material. The selection often isn't the best in dentist's offices, but I often find some sort of magazine about computers to pick up and read. When they were still publishing a printed version, this was often a copy of Computer Shopper. After that publication went to a web-only format, the magazine that I pick up seems to be different every time.

In any case, when I'm looking through whatever magazine that I pick up, I'm often surprised by the advertised price for some sort of computer. No way, I think, that price is outrageous.

Then I notice that the magazine is a year or more old.

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.

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.

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.

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.

The real benefit of cloud computing

Not too long ago, Amazon introduced its EC2 Spot Instances, a new approach to cloud computing. Here's how Amazon describes this:

Spot Instances are a new way to purchase and consume Amazon EC2 Instances. They allow customers to bid on unused Amazon EC2 capacity and run those instances for as long as their bid exceeds the current Spot Price. The Spot Price changes periodically based on supply and demand, and customers whose bids meet or exceed it gain access to the available Spot Instances. Spot Instances are complementary to On-Demand Instances and Reserved Instances, providing another option for obtaining compute capacity.

Essentially, EC2 Spot Instances lets you bid for unused time on Amazon's systems, and it's the first real step towards making computing a commodity service. I believe that the biggest impact of cloud computing will be from EC2 Spot Instances and similar offerings, but probably not in the way that most people would guess.

I really don't see cloud computing ever becoming a true commodity service. Despite all of the talk about standards for cloud computing, cloud vendors really have no incentive to make their technologies interoperable, so I doubt that we'll ever see it become a reality. The huge number of different national laws will also make it very difficult for cloud computing to ever become a true commodity. You'll always have requirements that certain data essentially can't leave national boundaries either due to regulatory restrictions or other political issues. I don't foresee an easy solution to these problems, so I don't foresee  the market for cloud computing ever becoming quite like markets for other commodities. I doubt that we'll ever see things like derivatives and hedging for cloud computing, for example.

Instead, I see the real change that Amazon's offering will create is that people will start to question the value of computing and do a better job of trying to quantify it. After all, you really shouldn't be bidding for computing services if you don't really know how much the computing is really worth to you. Once businesses get accurate metrics for the cost and benefits of enterprise software, the enterprise software market will change dramatically.

I believe that the opportunity to buy cloud computing as a commodity, even on a relatively small scale, will get businesses to start thinking about exactly how much computing is worth to them. This will then lead them to think about exactly which applications are really worth their cost. Once they have more accurate metrics, I believe that they'll find that some enterprise computing simply isn't worth what they're paying for it. We'll eventually find that while some types of enterprise applications make sense, others don't. 

This will lead to either the collapse of parts of the enterprise software market or some difficult times for some software vendors as they try to make their offerings add value that's substantially more than the cost of the software. The products that remain after this big shake up will be the ones that should have been there in the first place. The products that disappear will be the ones that never should have been deployed. What we'll be left with will be much more efficient that what we have today, and that increased efficiency will be one of the biggest benefits from cloud computing.

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.

Clod computing

Clod computing - when the only thing missing from cloud computing is "U."

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.  

The Information Age began in 2007

The Economist recently had a special report on managing information. There was some information in this report that I hadn't seen before, and that was the fact there's now more information being created each year than the amount of available storage to hold the new information. According to the IDC research that The Economist cites, it's actually been this way since 2007, so I'll claim that's when the Information Age really began. So we're not just  creating more and more information each year. We're also losing more and more information, because there's no place to store it.

The article in The Economistdoesn't do more than identify the trend of huge amounts of information being created and claim that the trend is important to understand. The experts that they quote in their report don't really do any better. They all agree that things are going to be very different in the future, and learning how to make sense of all of the available data is going to be even more important in the future than it is now, but that's about as much as they can say.

I'd guess that a dramatic loss of privacy is one of the biggest changes that we'll see in.the future from the huge amounts of information that will be available. Maybe that's not a big deal to people who grow up posting all the details of their lives on the Internet, but that's not something that I'm looking forward to.

Altering memories

I recently read an interesting article in the Wall Street Journal about altering memories, and I don't mean the DRAM that your desktop computer uses. Apparently it's possible to permanently change your memories. This sounds like something that Phillip K. Dick might have used in one of his science-fiction stories like "We Can Remember It For You Wholesale," the story that the movie Total Recall was based upon. Or maybe it's more like something from Richard Condon's The Manchurian Candidate, the basis for the movie with the same name.

And although researchers claim that their work is only meant to replace traumatic memories, like those that combat veterans or crime victims might have, with less troubling ones, the possibility for other uses seems to be even more attractive. Imagine how intelligence agencies could use the ability to selectively alter memories, for example.

The ethical implications of that use alone makes me wonder whether this research is really something that really we ought to be doing. Like Douglas Quail in "We Can Remember It For You Wholesale," we might end up now knowing exactly what's real and what's not.

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.

Jack Bauer Day - Spurring Innovation

“I know what it's like to feel like it's never going to end.” – Jack Bauer

One of the challenges which face many world-class engineering organizations is how to maintain an atmosphere of innovation while still delivering on customer commitments and scheduled releases. During the early stages of a start up innovation is rampant; there are typically no customers to worry about, no backward compatibility issues and no upgrade paths to test.

As a company matures I have seen many engineering teams stagnate, innovation slows down, and morale suffers. As a VP of Engineering I spend time on the lookout for the warning signs, at Voltage we are blessed with a strong highly motivated team.

Recently within the Voltage engineering team we held our first “Jack Bauer Day.” 24 hours of the engineering team doing anything they wanted to do. From 9 am in the morning of February 2^nd (2/4 for all us in the USA) until 9 am in the morning of February 3^rd the team had free rein with very little direction. The one condition: you had to present what you worked on to the rest of the team.

It was fascinating to watch how ad hoc teams formed; perhaps one of the most interesting was a team of three engineers who took on the task of developing Format Preserving Encryption on regular expressions as described by Bellare, Ristenpart, Rogaway and Stegers in their Format-Preserving Encryption paper.

Within the allocated time period the team was able to demonstrate features such as:

Given a regular expression R describing a regular language and a plaintext p which matches R, then p can be encrypted to a ciphertext c which also matches R and has the same length as p, and c can be decrypted back to p. For example:

Plaintext: jobs@voltage.com

Ciphertext: 3y90zagb@2GMK.com

Decrypted ciphertext: jobs@voltage.com

The team then expanded the initial implementation with some different length encryption. Given regular expressions R1 and R2 (each describing a regular language, with certain restrictions on R2) and a plaintext p which matches R1, then p can be encrypted to a ciphertext c which matches R2 (with varying options for the length of c), and c can be decrypted back to p.

For example:

Plaintext: 4005 Miranda Ave, Palo Alto, CA, 94043

Ciphertext: 8 Bauzvvbuwg Dr, Szptny Oqo, AZ, 25601

It never ceases to amaze me what a small team of focused engineers can achieve if left alone.

Was Jack Bauer day a success? Yes absolutely. We will be holding them on a regular basis.

Acknowledgments: Portions of this post was taken from team rugby’s write up of their Jack Bauer day.

Hacking chips

I recently came across an interesting blog post that describes how a clever hardware hacker managed to make a single-chip CMOS inverter at home. The hacker apparently worked out her own CMOS fabrication process using just equipment that's cheap and readily available.

A single inverter isn't that impressive - it has just a single PMOS transistor and a single NMOS transistor - but the fact that this hacker managed to develop a process to make a single-chip version at home is extremely impressive. The success of this project made me wonder about how successful hardware hackers who operate with a similarly-modest budget can be.

I have always said that the protection provided by hardware is fundamentally different from the protection provided by encryption. Once you have the right tools and expertise, a wide range of attacks become feasible. If you have a big budget, perhaps just a few million dollars, you can probably beat any hardware security mechanism at all. The more interesting question is really whether or not relatively low-budget attacks can beat the security provided by hardware.

The fact that a clever hardware hacker managed to make a single-chip CMOS device at home leads me to believe that hardware hackers may be much more capable then we might first think, and that they might be able to carry out some impressive attacks against smart cards and HSMs. Hardware security isn't perfect, but we tend to think of it as being better in some vague and ill-defined way than software-only security. Maybe the difference isn't really that big.  

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.

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.

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.

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.

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.

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.

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.

Intel's AES instructions

I finally got around to looking at how Intel's AES instructions work. These are a new set of processor instructions that will soon be introduced that implement AES encryption and decryption. There are a total of six new instructions that do this: AESENC, AESENCLAST, AESDEC, AESDECLAST, AESKEYGENASSIST and ASEIMC. The first four of these do the actual encryption and decryption, and do this a round at a time, with the *LAST being what you need to use on the last round. AESKEYGENASSIST and AESIMC do key expansion, and you need to use these before you can encrypt or decrypt.

When you hear that there are two separate instructions for non-final rounds and the final round of an encryption or decryption, you'll probably realize that using these instructions isn't as simple as calling a function that encrypts or decrypts data. Instead, to use these instructions, you need to have a fairly detailed understanding of how AES works.

Using these instructions, here's roughly what encrypting with AES-128 looks like, where the register xmm1 initially holds the plaintext input and xmm2 through xmm12 hold the round keys from the key expansion:

pxor xmm1, xmm2

aesenc xmm1, xmm3

aesenc xmm1, xmm4

aesenc xmm1, xmm5

aesenc xmm1, xmm6

aesenc xmm1, xmm7

aesenc xmm1, xmm8

aesenc xmm1, xmm9

aesenc xmm1, xmm10

aesenc xmm1, xmm11

aesenclast xmm1, xmm12

That's not as simple as I thought would be when I first heard about the AES instructions. I imagined something that would work more like this:

aesenc data, key

Using the key expansions instructions is even more complicated. If you really want to see how to do that, you can download Intel's white paper here.

It's good to see hardware support for encryption becoming more widespread. Encryption was often too hard to use in the past, and it looks like Intel's AES instructions should make it easier than ever to implement encryption. The fact that they also make it faster doesn't hurt, either.

Avoiding a technology monoculture

At the recent National Cyber Leap Year Summit, there were lots of ideas discussed about how to make our current computing environment more secure. One of the ideas discussed was how to deal with the monoculture that success in the marketplace tends to cause. Some people thought that a technical monoculture was a very bad idea that led to all sorts of problems. Others saw the benefits to a standard technology outweighing the problems that it might cause. Still others didn’t see a feasible way to get people to diversify the technology that they use.

Having a single technology that’s used everywhere has the potential to cause all sorts of problems because if the technology fails in one place it fails everywhere. That’s why some applications that need to be extremely reliable, like those that run nuclear power plants or aircraft, need to have redundant systems that are also different from each other.

If there’s a single operating system used on 100 percent of computers and hackers find a way to exploit it, then they can also exploit 100 percent of the computers. On the other hand, having only a single platform to support can give you significant cost savings in the areas of support and maintenance. For large businesses, it’s possible to save hundreds of millions of dollars (according to people from large businesses at the NCLY Summit) by standardizing on a minimal set of supported applications, and it’s not clear that doing this causes anything close to hundreds of millions of dollars in losses due to the increased ease with which hackers can exploit the businesses that have done this. So there’s definitely a cost to standardizing technologies, but it’s not clear that these costs outweigh the benefits from it.

On a more practical note, it’s not clear how you could get businesses to not standardize their technologies. Would you require each business to use a diverse set of technologies? Or would you let each business standardize on a set of technologies but force diversification of technologies from company to company? If you somehow required businesses to diversify the technologies that they use, how would you compensate them for the additional costs that they might experience?

And exactly how would you define diversity? Is version 2.0 of a product the same or different from version 3.0 of a product? A quick look at the National Vulnerability Database seems to show that the vulnerabilities that a product has change a lot over its lifetime, so maybe it’s reasonable to say that version 4.0 is different enough from version 2.0 to justify being classified a different product for this particular purpose. This, of course, could lead to the bizarre effect of encouraging businesses to only patch and upgrade part of their systems, so that they’ll have enough diversity to meet whatever monoculture-banning rules that we come up with.

So maybe that’s a good challenge: find a reasonable way to get businesses to diversify their technology purchases in a way that doesn’t cause huge side-effects. Can it even be done?

Progress in quantum computing?

In the past few weeks, I've heard lots of comments about quantum computing. Because I heard so much about it, I thought that there must have been a big breakthrough of some sort. The last I had heard was that a team at IBM had managed to factor 15 using Shor's algorithm. Because of the sudden interest, I thought that this record must have been beaten in some way, and I don't mean by factoring 17.

But when I looked around the Internet, however, I couldn't find anything that talked about bigger successes, although others have reproduced the factorization of 15. This leads me to wonder what caused the sudden interest in quantum computing. Are there quantum computers out there that can do more than factor 15?

Being able to factor 15 with a quantum computer is actually a very impressive technical accomplishment, but it's not one that leads me to believe that existing public-key technologies are in danger of being rendered ineffective by the existence of quantum computers any  time soon. Perhaps ever. Or is there research out there that I didn't find?

I just don't get this one

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

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

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

Vanish: self-destructing data

There’s been lots of talk recently about “self-destructing data,” or data that loses its ability to be decrypted over time. I’ve been asked about this enough times to make it worth putting here so that I can refer future questions to this post, so here it is.

Roxana Geambasu, Tadayoshi Kohno, Amit Levy and Henry M. Levy, all of the University of Washington, recently published a paper that described a system that they called “Vanish.” This system creates a way to encrypt data that makes it possible to decrypt the data for a while, but after enough time passes, this ability goes away. Here’s how Vanish works. It's based on a clever application of Shamir secret sharing.

Shamir secret sharing is a way to split a key into n parts, any m of which allow you to reconstruct the key. It works by encoding the n pieces of the key as points on the curve of a polynomial of degree m - 1. Recall that any d + 1 points uniquely determines a polynomial of degree d, so that any two points uniquely determine a line, any three points uniquely determine a quadratic equation, and so on.

With Shamir secret sharing we use the key that we want to split for the constant coefficient of a polynomial of degree m - 1 and create n points on the curve of the polynomial which then act as the split parts of the key. When we do this, we can then find the polynomial's coefficients from any m of these parts. One of these coefficients is the key that was split, so we can also find the key that we need from any m of these parts.

Vanish ties the ability to look up the parts of a split key to information that changes over time. Dynamic IP addresses, for example, change fairly often, so they can be used for this. If you use a user’s IP address to look up part of a split key, then when a user’s IP address changes, you’ll also lose the ability to look up part of the split key.

When you initialize this scheme, you’ll be able to get all n of the n possible parts of the split key, but eventually you’ll get down to having only m - 1 of them available as the information that you need to look up the parts gradually disappears or changes. When that happens, you’ll no longer be able to get enough parts of the split key to recover it. Note that this happens very suddenly. One minute you can decrypt your data just fine and the next minute you can't. There's no slow degradation in the ability to decrypt.

Vanish seems like a simple and elegant scheme, but I’m not convinced that it’s really that important. In the business world, instead of having data disappear, it’s more important to have guaranteed access to encrypted data. That’s something that people will pay for. Vanish probably isn’t.

Why do people work on open-source software?

As every individual, therefore, endeavours as much as he can both to employ his capital in the support of domestic industry, and so to direct that industry that its produce may be of the greatest value; every individual necessarily labours to render the annual revenue of the society as great as he can. He generally, indeed, neither intends to promote the public interest, nor knows how much he is promoting it. By preferring the support of domestic to that of foreign industry, he intends only his own security; and by directing that industry in such a manner as its produce may be of the greatest value, he intends only his own gain, and he is in this, as in many other cases, led by an invisible hand to promote an end which was no part of his intention.

Adam Smith, An Inquiry into the Nature and Causes of the Wealth of Nations

It's not hard to create a plausible economic model that explains why open-source software exists. One argument is that enterprise software has a minimum cost associated with developing and marketing it. These costs include the engineers that write the software, the people that test it, the sales engineers that install it at customer sites, the sales people who help customers through the sales cycle, the marketing people who let customers know what's available to solve their problems, etc. The total cost of all of these isn't cheap, so if a particular application isn't worth more than that fixed cost, it can't be the basis for a profitable business.

But if there's a demand for something at a lower cost, someone will probably find a way to make it happen. It's much like minimum-wage laws. There are some jobs that just aren't worth the minimum wage, and when this is the case, people find ways to get those low-value jobs done, even if it involves breaking the law. They might hire illegal immigrants for less than the minimum wage. Or they might agree to pay someone cash to avoid the taxes that, from the point of view of the employer, are also part of their cost of labor.

On the other hand, an argument like this only describes market forces, Adam Smith's invisible hand that makes things happen. It might explain why open-source software exists, but doesn't really tell us why any particular person would make a decision to work on open-source software. That may require a different explanation. Here's one, and it's based on modeling contributing to open-source software as a tournament. It's much like the model that Stephen Levitt and Stephen J. Dubner used in their book Freakonomics to explain why so many drug dealers earn roughly the equivalent of the minimum wage.

It turns out that almost all drug dealers don't make very much money. These are the ones that actually sell the drugs on the streets. The real money is in managing an organization of drug dealers, and Levitt and Dubner describe how the entry-level drug dealers tolerate the low pay because they hope to eventually become one of the managers. In this sense, drug dealing can be modeled as a tournament that selects the most fit drug dealers and promotes the winners into the more lucrative jobs.

Maybe this model also applies to open-source software. After all, being a recognized contributor to a big, successful open-source project is also a good way to get a high-paying programming job. So it might be the case that the programmers who donate their time to open-source projects do this in the hope of becoming an open-source superstar one day. This doesn't sound obviously false, and it does give you a good way to start a conversation: "Did you know that open-source programmers are like drug dealers?"

Is AES secure enough?

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

Absolutely not.

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

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

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

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

Why businesses aren't profitable

Conventional wisdom tells us that the global recession that we're seeing now is the result of the recent problems with financial markets. A closer look at IT industry analyst reports, however, might tell us that there's another reason that businesses aren't doing as well as they'd like to, and that's because of their use of IT. In particular, if you add up the TCO estimates for all of the IT products that a typical business uses, you'll find that the cost of their IT systems is much greater than their revenue. In other words, there's absolutely no way that a business can both use IT systems and be profitable at the same time.

This leads me to believe that one of two things has to be true. One possibility is that the TCO estimates that we often see aren't really very meaningful. Another possibility is that it's just impractical to use modern IT products because they cost more that they're worth. If the first of these two is true, then we have nothing to worry about, except perhaps wasting lots of time on TCO estimates that don't really tell us anything useful. If the second is true, then the global economy is doomed until we revert to more primitive, pre-dot-com-era technologies. Which one is more likely?

Challenges with point-of-sale devices

The point-of-sale devices that retail operations use need to be very easy to use because they're often used by relatively untrained people. I saw an example of this a few years ago when I went to the local sporting goods store to pick up a package of white athletic socks.

I handed my credit card to the clerk in the store, who swiped it through his POS device, keyed in the amount of the transaction and waited for an authorization code to appear. There was apparently a problem with the connection of the POS device to the authorization service. What appeared on the LCD screen of the POS device was a pattern of random LCD segments that looked something like this:

 

The clerk didn't recognize this as anything other than a valid authorization code, and proceeded to carefully copy this pattern into the space for the authorization code onto the credit card payment slip. Apparently, nobody had told him to expect a series of numbers for the authorization code.

I left the store wondering what other types of mistakes had happened when the store processed credit cards. I doubt that I saw the worst mistake that an untrained person ever made.