Invariant Properties

  • rss
  • Home

Introduction to Digital Certificates, Part 1

Bear Giles | May 29, 2012

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.

Categories
java, security
Comments rss
Comments rss
Trackback
Trackback

« ‘dropbox’ and noexec home directories Introduction to Digital Certificates, Part 2: IDs »

Leave a Reply

Click here to cancel reply.

You must be logged in to post a comment.

Archives

  • May 2020 (1)
  • March 2019 (1)
  • August 2018 (1)
  • May 2018 (1)
  • February 2018 (1)
  • November 2017 (4)
  • January 2017 (3)
  • June 2016 (1)
  • May 2016 (1)
  • April 2016 (2)
  • March 2016 (1)
  • February 2016 (3)
  • January 2016 (6)
  • December 2015 (2)
  • November 2015 (3)
  • October 2015 (2)
  • August 2015 (4)
  • July 2015 (2)
  • June 2015 (2)
  • January 2015 (1)
  • December 2014 (6)
  • October 2014 (1)
  • September 2014 (2)
  • August 2014 (1)
  • July 2014 (1)
  • June 2014 (2)
  • May 2014 (2)
  • April 2014 (1)
  • March 2014 (1)
  • February 2014 (3)
  • January 2014 (6)
  • December 2013 (13)
  • November 2013 (6)
  • October 2013 (3)
  • September 2013 (2)
  • August 2013 (5)
  • June 2013 (1)
  • May 2013 (2)
  • March 2013 (1)
  • November 2012 (1)
  • October 2012 (3)
  • September 2012 (2)
  • May 2012 (6)
  • January 2012 (2)
  • December 2011 (12)
  • July 2011 (1)
  • June 2011 (2)
  • May 2011 (5)
  • April 2011 (6)
  • March 2011 (4)
  • February 2011 (3)
  • October 2010 (6)
  • September 2010 (8)

Recent Posts

  • 8-bit Breadboard Computer: Good Encapsulation!
  • Where are all the posts?
  • Better Ad Blocking Through Pi-Hole and Local Caching
  • The difference between APIs and SPIs
  • Hadoop: User Impersonation with Kerberos Authentication

Meta

  • Log in
  • Entries RSS
  • Comments RSS
  • WordPress.org

Pages

  • About Me
  • Notebook: Common XML Tasks
  • Notebook: Database/Webapp Security
  • Notebook: Development Tips

Syndication

Java Code Geeks

Know Your Rights

Support Bloggers' Rights
Demand Your dotRIGHTS

Security

  • Dark Reading
  • Krebs On Security Krebs On Security
  • Naked Security Naked Security
  • Schneier on Security Schneier on Security
  • TaoSecurity TaoSecurity

Politics

  • ACLU ACLU
  • EFF EFF

News

  • Ars technica Ars technica
  • Kevin Drum at Mother Jones Kevin Drum at Mother Jones
  • Raw Story Raw Story
  • Tech Dirt Tech Dirt
  • Vice Vice

Spam Blocked

53,793 spam blocked by Akismet
rss Comments rss valid xhtml 1.1 design by jide powered by Wordpress get firefox