Experts Stumble on PKI Security Project

Computerworld - Five years ago, before I was hired, my company rolled out a financial services application to 20,000 users at 900 companies in 18 countries. The company knew it needed something better than just user names and passwords for authentication, so it built a public-key infrastructure (PKI).
That technology decision has come back to haunt us. We're struggling to make the infrastructure work better, and finding qualified help hasn't been easy.
Using PKI, our central application that needs to verify a user's identity can ask the user to perform a calculation that is possible only with his private key. The private key isn't held in the central server, and it isn't transmitted, making it much harder to steal or intercept.
There are weaknesses, though. While working out the private key is difficult, it can be done if you have very fast computers - and enough time. And private keys can be stolen from users. Therefore, to ensure that the system remains secure, we set the keys to automatically expire every four years. That is where our problems began.
Key Headaches
A year and a half ago, we had to issue a new key to every user. It was a painful, manual process that took months and annoyed everyone. It hurt my group because we had to dedicate skilled staff to the low-level task of producing the keys and then following a manual process to send those keys to every user. We used encrypted, self-extracting executables to e-mail the keys out.
Many users' firewalls and e-mail gateways are configured to quarantine or strip attachments that are difficult to scan or that could be a virus. As each of the steps we used to send the keys was likely to hit a block, sometimes it was a problem for our users to even get the keys, let alone go through the process of installing them in the right place. Now that we've distributed the keys, we aren't looking forward to the next expiration.
When the system was built, PKI was rare in the commercial world. There weren't any mature, reasonably priced commercial products, so we built our own. It's clunky, and its bad interface adds to the work of issuing keys, but at least it conforms to the international standards that determine how to produce the keys.
Since then, PKI has grown in popularity, and competition has driven down the cost of PKI software. There are now several very slick packages available.
In order to reduce the pain of the next key reissue, we're investigating PKI product and service options. Our custom code is standards-based, so we can at least replace the core of the PKI without having to rewrite our application authentication code.
Consultant Concerns
I have a strong background in the academic theory of cryptography but not much direct experience with large-scale deployments of these PKI suites. Therefore, I decided to get some help from some highly recommended consultants who do this kind of thing all the time.
We began our meeting by explaining our situation and what we hoped to do. As the consultants spoke, however, I began to feel nervous. They seemed to be falling into the same kind of errors about cryptographic key sizes that I wrote about in my last column .
The strangest moment was when one of them informed us that the root key (the key we use to issue all the other users' keys) must be 512 bits larger than the users' keys.
Clearly, you should make the keys as large as possible so they will take longer to crack, while keeping them a reasonable length for easy storage and fast processing. The root key is more valuable than the user keys, because you could issue your own user keys if you cracked the root key. Therefore, making the root key larger than the user keys is sensible. But why an arbitrary value for how much larger it should be? I asked the consultant to explain. "Best practices," he said, but he could offer no further explanation.
Relations deteriorated further when we asked which vendors the consultant suggested we investigate for our particular needs. These consultants sometimes serve as a professional services arm of RSA Security Inc. in Bedford, Mass., and Entrust Inc. in Addison, Texas, so we weren't surprised to hear them recommended only those two firms.
VeriSign Inc. in Mountain View, Calif., RSA and Entrust are the three biggest names in the PKI market. We were hoping for tailored guidance, but instead the consultants pointed us at two of the three biggest suppliers. That wasn't the best way to convince us they're worth their startlingly high consultancy fees.
Then we explained that we need to migrate to a new PKI product quickly to ensure that everything will be completed before the next key expiration occurs. That would let us save staff time and ease the pain for users, as we could reissue their keys once, rather than twice, over a short time span. The response? "Why not just extend the root key for a few years to give you breathing space? The users would never know, right?"
This is like a grocery store deciding to make a little extra money by adding extra days to the expiration date on their milk. The customers would never know, right? Yes, but I know, and I'm the one responsible for security around here.
In the end, I'm afraid we didn't learn much about which PKI product we should buy. But we did learn that we wouldn't be using these consultants to help us with the choice. Now we have to decide what to do next.

Read more about Security in Computerworld's Security Topic Center.