Quick updates for 2010

I wanted to drop a quick note to let you know I'm still here.  Here's a quick run-down of what's happened to me over the last year:

The biggest event is that Google hired me last October to work on a Software Developer's Kit (SDK) for the new Chrome Native Client plugin.  This has been a lot of fun and I'm looking forward to seeing this technology go out to developers everywhere.  Native Client really has an opportunity to completely change the game, moving developers from Windows lock-in into being truly platform independent.  Cool stuff.

We're also doing another Key Management Summit, this time in Monterey, California, from March 30-31st, 2011.  This is a follow-on to the previous IEEE Key Management Summits, held in 2008 and 2010.  This is a good chance to catch up on the latest development in key management technology and standards.

I've also started competing at Topcoder as a way to sharpen my C++ skills.  I find it very useful to practice intense bursts of coding for 75 minutes.  I recommend it for anyone interested in pursuing coding jobs.

So that's about it for now.

Heartland Payment Systems Compromised

I just got a letter in the mail (dated February 5, 2009) from my credit union stating that my "Visa Credit Card may have been compromised as a result of an unauthorized intrusion into Heartland Payment Systems." This story hit the news on January 20, 2009, and was covered by USA Today, MSNBC and others. Heartland has put up a website on the Breach, mostly as P.R. damage control. The hacking occurred over several months, and could be the largest breach, with highly sophisticated hackers.

What this means to me is that I'm getting a new credit card and debit card, with new PINs. 20 years ago, I'd just have to activate the new cards and memorize the new PINs, and be done with it. Now, with the proliferation of on-line shopping, I also need to find all the websites that have my credit card on file and update my information for automatic payments. This includes Amazon, iTunes, GoDaddy, etc.

With credit cards, the truth is that I don't care much if my number is stolen. Visa carries a "Zero liability policy", which means that I pay nothing in the event of unauthorized use. Also, the scope of the breach is so large that the chance of my card being singled-out is low. I'd be more worried if it were a small breach.

In a down-economy, this kind of breach can be even worse because people might become more afraid to use their credit cards and might resort to cash or checks. I suspect this is part of why Visa has the zero liability policy -- to keep the fear down.

Overall, though, as a security professional, I'm glad to see that these are still news events. I work on the Sun Key Management Appliance and in the IEEE 1619 Security in Storage Working Group, and this is the kind of problem we are working to solve.

"Matt Ball on Technology" is now "Heisencoder"

Short story: I've changed the name and URL of this blog from "Matt Ball on Technology" (blog.mvballtech.com) to "Heisencoder" (heisencoder.net), and have updated the theme to better accommodate posting source code.

Long story:
As of last November, I started working at Sun Microsystems as a full time employee and have basically stopped my year-long consulting work with my company M.V. Ball Technical Consulting (MVBallTech). This blog was previously hosted on the mvballtech.com domain to increase MVBallTech's visibility, but now that I'm no longer trying to build this company, I've decided to choose a name that's more concise, and pick a more memorable domain.

Heisencoder:
The name 'Heisencoder' came to me while I was trying to think of a name that concisely and uniquely described the focus of this blog (programming and cryptography). My criteria came to me while listening to the StackOverflow podcast #37, where Jeff and Joel described how they came up with the name StackOverflow, and how they wanted to have another contest to name their new IT-centric spin-off. "StackOverflow" was picked because programmers know exactly what it means (i.e., a buffer overflow off the execution stack), but it has some meaning to the common person (i.e., it sounds like maybe there's a stack of papers on a desk that is overflowing...).

I tried to keep this in mind when I created Heisencoder. The term "Heisencoder" is a concatenation of Heisenberg (as in the Heisenberg Uncertainty Principle) and coder, as in one who writes code. (The name can also read as Heis-encoder, sounding somewhat like something that performs cryptographic encoding.) The name is also a little bit of a play on the term "Heisenbug", which means a computer bug that changes when a programmer attempts to monitor the bug (typically by adding in extra debugging code). The act of monitoring the bug changes the bug itself.

I'll leave it to the readers to think of clever meanings for "Heisencoder". The more self-deprecating, the better.

Joel Spolsky Co-Launches "Stack Overflow" programmer's forum

One of my favorite programming bloggers, Joel Spolsky, recently announced his latest co-project:  Stack Overflow.  This is basically a 'fixed' version of the question forum that you frequently encounter when searching for programming questions.  The improvement is that this is moderated, and the answer gets promoted to the top so that you don't have to wade through endless comments to find the answer (if you do find the answer).

It's still in beta, and it doesn't have too many users yet, so it's hard to say whether Google will give it enough PageRank to reach critical mass.  Just in case, I registered myself (using OpenID, with my blogger website -- this blog) so that I could get a low enough user number to have Web Cred.  I got #7448.  Not too bad.  If this ever grows to SlashDot proportions, people will be like "ahh, he's got a four digit user number -- he must know what he's talking about"  (says the 7-digit user number user).  Of course, it will be impossible to ever win the user number war against Jeff Atwood:  #1.

I browsed the site a little bit and couldn't find any big complaints about the user interface, although I haven't tried posting yet (I did get a 'bronze medal', though, for filling out my biographical information!).  They've got syntax highlighting on the code samples, so it can't be too bad...

I'm half tempted to move a bunch of the programming tidbits I've collected on this site over to Stack Overflow.  I just want to make sure that the answers still link over to this blog so that this blog can build web presence as well.  (One of the great things about posting useful answers in your blog is that it raises the blogs PageRank -- if these same answers are posted elsewhere, your blog doesn't improve).  Stack Overflow lets you link your website through your user profile, but you have to click the user profile first.  I've also noticed that the last person to edit the question gets the credit for asking it -- not the original asker.  This creates a situation like that game where you try to put your hand on top of another person's hand, who tries to put their hand on top of yours, until you both end up slapping each other instead of putting hands on hands...

In any case, I hope that this website builds to the point that Google gives it top PageRank for the questions it answers.  This would let me reap the benefits of this system without all the work... :)

Thales UK Acquires nCipher for US$100 Million

On July 11, 2008, Thales UK (a subsidiary of the French defense company Thales) submitted a proposal to acquire all the assets of nCipher for roughly US$100 million. nCipher produces cryptographic hardware, and recently acquired most of the assets of NeoScale Systems for just under US$2 million.

The deal is still pending a vote by the nCipher board, but the offer carries a 2x premium on previous stock prices, so it doesn't seem likely that this vote will fail.

The technical editor for the IEEE P1619.3 was employed by NeoScale and is currently employed by nCipher, soon to be acquired by Thales. nCipher is a strong supporter of the P1619.3 key management effort and I'm hoping that Thales will continue in this strong support.

It's a little unclear to me how to pronounce "Thales". The namesake is an ancient greek philosopher, and as such the name should be pronounced "Thay' - leaz". However, the French owners prefer to pronounce it more like "Tal-less".

Links:

• Thales Press Release
• Techworld Coverage
  

TrueCrypt Releases version 6.0

On July 4th, 2008, the TrueCrypt Foundation released TrueCrypt version 6.0. TrueCrypt is a very popular open-source disk encryption tool that is currently based on the XTS-AES encryption mode that the IEEE P1619 Task Group developed and standardized in December 2007. As the chair of the IEEE Security in Storage Working Group (SISWG) -- the group that oversaw the development of XTS -- I'm very pleased to see the continued adoption of XTS in the industry.

On a related note, NIST is currently considering XTS as an Approved Mode of Operation for protecting U.S. government confidential data under FIPS 140-2. If NIST accepts XTS, this will be a huge boon to TrueCrypt and similar tools that use XTS. If you use TrueCrypt or other tools that use XTS, please send NIST a comment (before Sept 2008).

For a limited time, you can pick up a free copy of XTS from IEEE. After September, you'll have to buy it from the IEEE store. See the P1619 homepage for instructions and other information.

How to Prevent the Random Number Bug in Debian OpenSSL in Other Implementations

As probably the entire hacker community has heard by now, there was a bug recently discovered in Debian's OpenSSL implementation that crippled the random number generator. For background, see Schneier's Coverage, Slashdot's Coverage, Debian's Announcement, Ubuntu's Announcement, and a Cartoon.

On the surface, this just looks like a stupid mistake by one Debian maintainer. But if you look at the details, it's not that obvious. Here one of the two lines in question, within md_rand.c

MD_Update(&m,buf,j); /* purify complains */

This function seeds the cryptographically secure pseudo-random number generator, which then generates important things like cryptographic keys. The security of a cryptographic key is solely in the difficulty of an attacker to guess the value (like a house key's tumbler positions), and if it is predictable, there is no security. The maintainer removed this line because the Purify and Valgrind tools complained about uninitialized data.

Truthfully, if I were in the same position as a maintainer, there's a good chance I might have commented out these lines too. Code analysis tools are very useful in helping to maintain high code quality, and crippling these tools also has consequences. The right action is not always obvious, and when you go through hundreds of lines of code it's easy to forget the significance of a single line like this.

The fundamental issue with random number generators (RNGs) is that they are infamously difficult to test. A standard software regression test takes a known input to a program and checks for a known output. RNGs aren't like that -- at least when used with good seeds. A good seed never repeats and cannot be tested against known answers. Instead, you have to perform statistical tests on several samples from the seed source (examples: DIEHARD, NIST's RNG suite).

This problem is much more widespread than people think. This is also a very common problem in embedded systems. Many instantiations of SSL don't properly seed their RNG. This won't cause the system to fail, testers won't ever catch it, and customers won't complaint. So from the vendor perspective, there's really no incentive to make it work. Most of the engineers adding OpenSSL don't know much about cryptography, and often won't know to or even bother to hook up a seed. Some systems don't have a good way to generate this seed.

Even NIST' Computer Security Division (the owner of FIPS 140-2, a major cryptographic standard for government agencies) has mostly washed their hands of this problem. FIPS 140-2 used to include statistical tests on the entropy (i.e, 'randomness') source used to create the seed, but now the only requirement is that the vendor justify a certain entropy level.

To solve this problem, I think that OpenSSL (and other SSL implementations) needs to add some kind of sanity check to the seed to make sure this mistake doesn't happen again. Here's a rough outline of this test:

1. During OpenSSL's initialization, immediately collect several samples from the seed source. The number depends on the constraints of the system, but NIST's old FIPS 140-2 statistical test collected 20,000 bytes, which is a reasonable number.
2. Run simple statistical tests on these samples (see FIPS 140-2 for an example) and make sure the entropy source is reasonable.
3. Store the first 100 bytes or so of this sample set in non-volatile memory, (e.g, hard disk, flash), and keep a history of several thousand of these initial samples. Discard the other samples (don't use them as part of the real seed)
4. Run another statistical test on the series of first samples. If there is a correlation between these samples (i.e,. the values tend to be the sample after initialization), then fail with a big obnoxious error that you'd hope no distribution maintainer or embedded software engineer would miss.
   

This test would have caught the bug in questions because the same seed would likely have occurred across power cycles. The default for this seed is the process ID, which by default is at most 32,768. According to the birthday paradox, you will on average see a duplicate random number in the range 1 to N after roughly the square root of N samples. In this case, the square root of 32,768 is 181. Someone would have seen the horrible error message by then.

Caveat: Make sure that the files that store these seeds are properly protect from access and modification. If the entropy source is poor, it's possible to leak information about the rest of the system, or even give hints as to what the subsequent seed will be as used by the real random number generator.

When it comes to security, you really can't rely on people to catch these kinds of mistakes through code reviews. You need to have good tools to automatically catch this. Unfortunately, making the tools is difficult, which is why we still mostly rely on code reviews.

Although code reviews are better than nothing, and in this case, it sounds like even a code review would have helped...

RSA 2008: Cryptographer's Panel

As one of the great highlights of the RSA Conference is the cryptographer's panel with the great experts of modern public key cryptography: Whitfield Diffie, Martin Hellman of Diffie-Hellman fame (discrete log crypto) and Ron Rivest and Adi Shamir of RSA fame (crypto based on the integer factorization problem -- used in SSL).

This is a rough draft post that will be cleaned up later, but contains the last part of the discussion:

Question from Burt: Where would you put your research effort?
Diffie: I'd put research into genetics - We'll see the first child made from two women, showing that men are an expensive and unnecessary thing to have around.
Hellman: We need to become more rational in our approach to security

Closing remarks:
Diffie: I'm optimistic about this subject. People are going to get along just fine -- cyber security is very important. The most important thing in the 20th century is client server computing. By putting important information onto a single computer, it's possible to control access. -- Something's going to happen that we don't expect, from younger people
Hellman: Don't be afraid to tackle problems
Rivest: (countering Diffie): There is a lot of cryto still to be discovered. We're still at the early stages of tying worst-case complexity to best-case complexity -- how to run crypto protocols in parallel so that they don't interfere -- we need the secure platform -- next problem is user interfaces
Shamir: It's about subtlety behind the schenes --- multiple lines of defense -- most of the basic elements are there. But we haven't reached nirvana -- we need to develop tools and techniques -- a GPS for data, need the ability to located where your data is. Use 160-bit sha-1 summary to help locate this data. This could help the information management problem

Burt: 1024-bit RSA -- how much longer before the publicly announced factorization
Shamir - next year
Hellman - I was at Certicom -- Elliptic curves have been rock-solid since inception
Rivest - Use Moores law - There are low-probability algorithms that are hard to predict
Burt -2010 is the transition to 2048 bit keys

These guests will be in the crypto commons for more discussion.

TechWorld article on P1619.3

There was an article yesterday in TechWorld about the IEEE P1619.3 standard, and HP and NetApp's (i.e., Decru) involvement in shaping the current state of this standard. See this link:

Security: the protocol is the key by Chris Mellor

While it's good to get lots of press on P1619.3, it's not clear that the article articulated its point very well. Aside from a plethora of misspelling errors, the content seemed somewhat questionable. I've pulled out a quote from the article below, with commentary:

Blair Semple, a security evangelist at NetApp, [s]ays that IEEE has initiatives, meaning working groups, relating to storage security. These are:-

- IEEE 1619.0 relates to disk security,
- IEEE 1619.1 relates to tape security,
- IEEE 1619.2 relates to securing big blocks on disk,
- IEEE 1619.3 relates to key management.

Sempl says that 1619.3 is much earlier along in the standards process than the disk and tape device focussed standards. NetApp sits on all these committees and submitted the API, jointly with HP, from the Decru DataFort's Lifetime Key Management product, the Open Key API, as technology to be used for the 1619.3 protocol. He said the: "spec is approved and is the foundation for 1619.3."

(For the record, P1619 and P1619.1 are both in submission to IEEE, and should be published by early next year. P1619.2 is still a little ways off, and does not have a tight time schedule, yet)

I'm a little confused about the part that says "[NetApp] submitted the API, jointly with HP". The P1619.3/D1 draft was submitted to my knowledge only by NetApp (Decru). If HP had a hand in it, they kept quiet about their part. In fact, HP has kept quite about all their partnerships with key management. All the key management vendors I've talked to think they are HP's secret mistress -- NetApp included.

Another point is the quote that the "spec is approved". The IEEE P1619.3 standard isn't approved until IEEE sponsor ballot completes with an affirmative vote. The draft was approved by the working group, but this is only providing a rough starting point. We expect there to be many changes before it's all done. It may look nothing like OpenKey (i.e., Decru's API for their DataFort key management appliance) -- although it's hard to say because you need a non-disclosure agreement (NDA) to even see OpenKey.

NetApp mentioned that it has several OpenKey partners, including Symantec and Quantum. From my experience, this has been a little bit of a marking-driven statement that hasn't had much engineering work to back it up. Quantum has announced its own QEKM (Quantum Enterprise Key Management), which is a rebranding of IBM's Java-based EKM. Quantum has not announced any products that use OpenKey.

With the general availability of the encrypting LTO-4 (using P1619.1 GCM encryption), the only remaining problem left is universal key management. Several groups are working on this problem, but at this stage, the group with the biggest industry membership is the IEEE P1619.3 group. HP wasn't sure if IEEE is the right place to do this standards work (according to the article), but I haven't seen a better place yet. The standard is still in the early stages of development and needs some more time, but it will get there.