InfoSecPodcast.com

From a mobile device in the enterprise standpoint RIM’s Blackberry devices are extremely popular. Also in the government and military circles it’s a very common platform. There is even a STIG (Security Technical Implementation Guide) published by DISA (Defense Information Systems Agency) to secure the Blackberry Enterprise Server. So why then is the experience so poor when sending or receiving S/MIME signed or encrypted emails? Probably because a decade after “The year of PKI”, secure email still remains a niche technology. Now from a personal device standpoint I totally understand that. But why is that still the case on the enterprise side?

There was an article I read many years ago that was called something like “Why Johnny can’t encrypt”. The gist of the article was that email encryption (and the underlying technologies like PKI) were so poorly implemented that the average user couldn’t use them or understand them. In my opinion that is as relevant today as it was a decade ago. There seems to be 2 schools of thought as to why this is. The first is that the implementation and resulting user experience of these technologies frankly sucks so nobody wants to use them. The second is that the masses are not asking for secure email so what gets implemented is core functionality that is just enough to say it works, depending on your definition of “works”. Call it what you will but I believe if it was easy to use then more people would use it, even if they don’t fully understand the concepts.

So how far have we come? Let’s take a look at Blackberry 5.0 infrastructure and handheld OS to see how they well they have implemented S/MIME. Contrary to what you may think after this article I am a huge Blackberry fan. I think when it comes to enterprise grade handheld devices and infrastructure (i.e. the BES) they have got it right for the most part. Let’s take a look at some of the issues that we have found during our Blackberry secure email evaluation.

NOTE: It’s been a while since I was working on this. If I am mistaken on any of these feel free to correct me.

Not enough of email is downloaded to the device to verify the certificate
Blackberry devices download something like the first 2K of an email. In most cases this is not enough to verify the status of the signing certificate for digitally signed emails. You have to open the message and do a “more” or “more all” to get enough of the email to verify the signature. I am not sure why the BES cant verify the status on the server and just send the results of the signature verification.

Forwarding / replying S/MIME emails silently drops any attachments
When you forward or reply to a digitally signed or encrypted email with an attachment there is a problem. The recipient will not receive the attachment and you will not see an error. The email just shows up with no attachment or errors. This is apparently due to the architecture that RIM uses, specifically the Attachment Service on the BES.

Inconsistent certificate status messages
If you receive a digitally signed email that cannot be verified for one reason or another the colored line that indicates status will be Red. However the exact same email digitally signed and encrypted will have a Yellow line. Why does signed and encrypted = Yellow and signed only = Red????

Stale Certificate status
Blackberry devices have significant issues checking certificate status properly. One of the main issues is that the device is apparently trying to check the status of all certificates in the chain, either via extensions in the certificates or CRL / OCSP servers specified in the configuration. This includes the Root certificate. The Root certificate does not publish a CRL on itself nor will anyone else. There is no certificate status when it comes to the root certificate. This causes Blackberry to show a Stale Status since it cannot obtain the status of the root certificate.

Handheld devices require additional software
The Blackberry devices require that the S/MIME support package be installed. This is accomplished through the Desktop Manager application. Basically you install the Desktop Manager on your workstation, connect your Blackberry to your workstation then install the software. Sounds simple enough and it is for a user. That model breaks down quickly when you are talking about an enterprise that has dozens or hundreds of these devices. Pushing this as an over the air update would make it much simpler.

User’s private keys need to be imported manually
To get the user’s private keys installed on the Blackberry device you must again connect to the Desktop Manager. As noted above this is something that a few users can handle but becomes a huge support burden as the number of devices grow. This is a hard one to solve given that you need to be careful when dealing with a user’s private key. You shouldn’t (in my opinion) give the users private keys to the Help Desk and let them install them on the users’ device. I may be a bit more cautious when it comes to this than most but non-repudiation goes out the window as you lose control of your private keys. Many organizations stand up a Microsoft CA as part of the domain infrastructure. A link from BES to the CA that generates a new signing key and recovers any encryption keys then pulls them down over the air might be an interesting solution.

One thing I haven’t looked at is how many encryption certificates the device can hold. When my current certificate expires I’ll get a new one. Will the handheld be able to store both so I can read encrypted email that was encrypted with either certificate?

What has your experience been like?

–Chris

Technorati Tags: Blackberry, S/MIME, PKI