Invariant Properties

This is the first entry in a series on the how, what and why of digital certificates. Especially the ‘what’ and ‘why’ since we developers tend to focus too much on the ‘how’.

The tentative topics include

• Introduction
• IDs
• X.509v3 Certificates
• Creating Certs with Bouncy Castle
• RA, CA and repository
• Policies and Practices
• Certificate Authority, Registration Authority and Registry

I’m also working on a set of related katana(*) projects. The current topics include

• writing a certificate builder
• writing test certificates into a KeyStore
• storing certs in a JPA database
• writing dao unit tests using Spring 3.1.1 @Configuration and @Profile beans
• using X509 certificates with container-provided authentication
• using X509 certificates with application-provided authentication
• writing a webapp using Google App Engine (GAE)
• writing a UI using Google Web Toolkit (GWT)
• more to follow…

Why GAE and GWT? Because this is a katana and I’ve never worked with GAE and only briefly with GWT. What better time to learn them?

(* A ‘katana’ (which may be the wrong word) in this context is a small programming problem to keep your skills sharp and learn new technologies. This effort is much bigger than a traditional katana but still a modest effort since it’s not intended for production use. Yet.)

Why do we care?

Why do we care about digital certificates? There are four common stories: securing a connection to a server, identifying a client, identifying a stranger, and storing public keys.

Securing a connection to a server

For most people the most common use of digital certificates is the ‘secure’ payment pages on websites. Behind the scenes the browser gets a digital certificate from the server, checks it, and only proceeds to establish an encrypted connection if it’s valid.

Developers can also use certificates to establish secure connections to other services, e.g., to a relational database or mail server.

In practice? Corners are often cut. In the worst case an ill-informed developer won’t perform any validation of the server’s certificate. More conscientious developers may perform additional checks but be forced to ignore the results because of ‘valid’ bad certs in the wild.

Identifying a client

How do you identify your clients? The traditional approach has been username and password but we all know that’s an extremely weak standard. In many environments clients are now required to provide their own digital certificate in order to establish a connection. The details are often hidden in the browser or a ‘smart card’ so the user may be unaware that this is happening.

Identifying a stranger

How do you know who a stranger is? Can you take them at their word? Rarely. Can you find somebody you both trust to vouch for them? Again, rarely. What we’re left with is a third party we both trust, e.g., the government agency that issued the passport or driver’s license. But this has its own limitations – do you know what a Freedonian passport looks like? Do you know how to verify its authenticity?

Public certificate authorities can act as trusted third parties to identify unknown parties. In fact that’s what we do when we use our browser – we shouldn’t trust the website claiming to be amazon.com to really be amazon.com, we want a third party (the certificate authority) to vouch for them.

In contrast we often know who the other party is. We might have been given the necessary certificates earlier via a separate trusted mechanism.

Storing public keys

Sometimes we need to manage our own keys for other reasons. A java “keystore”, or more generally a PKCS12 container, is a very good place to hold the private key. But where do we store the public key? How do we keep track of it if there are several other public keys? How do we provide it to others? How do they keep track of it?

These are all questions that lead to the initial digital certificates. Wrap the public key in a certificate and it’s easy to keep in a java KeyStore or PKCS12 container.

N.B., never store naked keys! Jasypt isn’t good enough! Proper storage of keys is a deep topic but a good start is to always keep your keys in a java or PKCS12 keystore. You then provide the password to the keystore via the appserver, e.g., via a JNDI property. The keystore itself should never be stored in the database. If you don’t have exclusive access to the appserver a good place for a read-only keystore is the webapp’s classpath. You can then load the keystore using the standard classloader methods. It’s more complicated if you need an updateable keystore, e.g., for working keys to minimize the exposure of the long-lived keys.

Sidenote: a recent major breach possibly involving millions of credit card purchases happened because the data was encrypted with a key that was itself kept in the database. Access to the database gave them access to everything they needed to decrypt the data!

What scale do we care about as developers?

On one extreme are very tightly controlled environments with only a few, rarely-changing, certificates. Developers at these sites can find everything they need in a quick google search and/or reading the OpenSSL documents.

One step up are what might be called departmental or even small enterprise environments. These can be large organizations, e.g., a university with tens of thousands of students, facility and staff, but there’s a straightforward hierarchy or well-defined set of hierachies. This is an environment where a small team of developers can do interesting work.

Then there’s the large enterprise and public certificate authority realms. Federated realms, unclear hierarchies, ambiguous legal environments. If you’re working in this environment my blog comments won’t be much help… but hopefully won’t be good for a quick laugh!

Danger, Danger, Will Robinson!

If you read nothing else in this series, read this!

Top 10 PKI Risks

Everything you Never Wanted to Know about PKI but were Forced to Find Out (Peter Gutmann)

Finally there was a recent uproar after it was learned that one CA, TrustWave, was selling a network firewall that used its trusted root certificate to create fake certificates that allowed all encrypted traffic to be intercepted. This is bad when employees check their bank balance at work, it’s far worse when employees are working with legally privileged information (e.g., personal medical or legal issues). Nobody realized that there was a problem since TrustWave was one of the standard root certificates accepted by all of the major browsers – the Firefox and Chrome browsers that people download immediately to replace the corporate-mandated MSIE didn’t give any warnings about untrusted certificates and nobody thought to check the actual certificates.

This drives home the fact that public digital certificates are only as trustworthy as the least trustworthy CA on your list. Check your browser – there’s now typically several hundred trusted CAs by default and all it takes is one of them to have a breach to be able to convince you to hand over your credit card information. Or worse.