Superconductor

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).

That's a lot of users

Our marketing people issued an interesting press release last week. There was some stuff in it about a huge growth rate, lots of consecutive quarters of profitability, and similar things, but what I found the most interesting is that we now have over 4.5 million licensed users of our SecureMail product.

Note that that's 4.5 million licensed users. Our sales guys typically license our email product to an enterprise by the number of internal users, so the actual number of users is actually much greater than that. Perhaps even much greater. So although it's impossible to get an accurate estimate for how many users we really have, it's not hard to believe that there are probably over 20 million users of SecureMail now.

That's a lot of users.

Another case of where it's not just a problem with IT

Before I came to Voltage I did mergers and acquisitions consulting. This can be very frustrating work because you put in lots of hard work and most M&A deals end up not closing. You typically have 90 days to do all of your due diligence for a deal, but you lose a week or two up front when you're getting organized and you lose a week or two at the end when you have to write reports and give presentations on what you learned. This means that you really have more like 60 days to learn everything, and that can mean lots of 20-hour days.

Fortunately, the work's interesting enough and the pay's high enough that you tend to not really mind that. On the other hand, it's very frustrating to see all of that work be for nothing when deals don't work out, and most of them don't.

I was having lunch with a former co-worker recently and was reminiscing about this particular frustration when it was pointed out to me that big IT projects have the same problem: most of them fail. The Standish Group has been tracking the success of IT projects for quite a while, at least since 1995, and here's what they had to say about how things are going now: 

"This year's results show a marked decrease in project success rates, with 32% of all projects succeeding which are delivered on time, on budget, with required features and functions" says Jim Johnson, chairman of The Standish Group," 44% were challenged which are late, over budget, and/or with less than the required features and functions and 24% failed which are cancelled prior to completion or delivered and never used."

"These numbers represent a downtick in the success rates from the previous study, as well as a significant increase in the number of failures", says Jim Crear, Standish Group CIO, "They are low point in the last five study periods. This year's results represent the highest failure rate in over a decade"

So IT projects, which have always been challenging in the past, have apparently gotten worse recently. I don't follow the Standish Group's CHAOS reports, their annual reports on the state of IT project management, like I used to, but I seem to recall that the trend was moving in the right direction in the past. Maybe cutting project management and risk management overhead due to the recent recession is responsible for this trend.

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.  

Rising credit card rates

There was an article in The Wall Street Journal this week about how the spread between the prime rate and credit card interest rates is the biggest that it's been in 22 years and is increasing. In light of the data that I recently posted about how the charge-off rates for credit cards are dramatically higer now than they've been in the past, I'm not surprised by this at all. I'd even guess that that's the main factor for the rising rates, not the recent Credit Card Accountability Responsibility and Disclosure Act of 2009.

Not quite my new favorite game

I've mentioned before how I recently came across a game called Progress Quest. In this game you do absolutely nothing after you create your character except watch the game run and watch your character, well, make progress. I recently came across a new game that I thought might be able to displace Progress Quest as my favorite game, but it turns out that I was mistaken. This game is Foldit.

In Foldit, you play games that involve folding proteins. Knowing the three-dimensional structure of a protein is apparently very important if you want to understand how the protein will work in the chemical reactions that biologists are interested in, but it's apparently not obvious from the chemical formula for a protein exactly what its structure will be.

There are sophisticated computer programs that will try to find the right structure for a protein, but it seems that these programs aren't quite as good as skilled people. To take advantage of this fact, a team of computer scientists and biologists made Foldit, a game that teaches you how to work out the right way in which a protein will fold. You learn the basic principles through a series of example problems and can then move on to working on bigger structures. This is apparently a valuable aid to research, and "Foldit players" were actually listed as co-authors of a recent biochemistry paper that was published in the journal Nature.

In any event, I thought that Foldit sounded interesting, downloaded and installed the game and tried the first few protein folding challenges. After the first several, I realized that I just don't have the right stuff to be a champion protein folder. I might not even be able to become a competent Foldit player. Fortunately, Progress Quest is still there (where my character Elrond Hubbard is now level 71.). It seems to be a game that's more aligned with my game-playing skills.   

While trying Foldit I did wonder if if would be possible to create a similar graphical interface for a game in which the players are really doing cryptanalysis, but I didn't see an easy way to do that.

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.

The market for positive feedback

Even though it's been almost four years since John Morgan and Jennifer Brown published "Reputation in Online Auctions: The Market for Trust," it looks like things haven't changed much since then. This article describes how people use lots of small transactions at on-line auction sites to artificially inflate their reputation. In some cases they then use that positive reputation to give unlucky buyers unwarranted confidence in them that they then exploit.

This article has a story, for example, about a person who bought lots of items being sold on eBay for the very purpose of increasing a user's reputation. They apparently spent about $100 on this and then used the positive reputation from lots of successful $0.01 transactions to open the door to shady real estate deals in which they made several thousand dollars.

In any event, I was curious whether this was still the case. In Internet time, four years is quite a while, so I thought that things might have changed since then.

Apparently they haven't.

A quick search for "positive feedback" on eBay returns a list of lots of items that are still being sold just to increase a user's reputation. I didn't see what things were like back in 2005 to 2006 when Morgan and Brown were doing research for their paper, but I'd guess that they weren't much different.

Morgan and Brown talk about things being sold for $0.01 that were designed to just boost a user's reputation, and it looks like prices are a bit higher these days. I don't see any "Buy It Now" auctions for $0.01 for which you really don't get anything, and it looks like $1 is a more typical price now. This makes be think that scams that take advantage of the trust created by positive feedback are probably more prevalent now than they were four years ago.

Charge-off rates for credit card loans

A reader recently commented that he'd heard that the charge-off rates (the fraction that banks write off as bad debt) for credit card loans are typically around 4 percent, but hadn't seen a reference to that fact. Here’s a graph of the data from the Federal Reserve that shows the charge-off rates on credit card loans since 1985. Until recently, the rate hovered around 4 percent. It’s jumped to roughly 10 percent in the past year or two, but I’d expect it to go back down to about 4 percent again in the next year or two.

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.

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!

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.