DCS and SMIME

S/MIME is a three decades old technology which aimed to provide object level encryption capabilities to MIME messages carried over an SMTP transport, so it might be confusing as to why we would compare it to the much more recent Data Centric Security (DCS) approach to security proposed by NATO in their “DCS Vision and Strategy , to “enhance the principal benefits of operational agility and security.”  This is a three-layered approach, with Level 3 facilitating cryptographic object level protection to deliver enhanced post-release control and data leak protection.”

However, there are significant similarities in objectives; securing the data object, enabling operation of untrusted networks and systems, and they both use a public key cryptography approach to provide protection.

This blog is a personal perspective, based on 30 years of disappointment in S/MIME, which highlights the potential pitfalls for DCS that current research must avoid if the sought-after benefits of this approach are ever going to be realised.

S/MIME

I repeatedly encountered S/MIME in the 1990s and 2000s, firstly as part of the  Password (’93) and the EMA Challenge projects (’97), and later at Intercede in 2003 and Siemens in 2006.  Based on these experiences, in 2012 I wrote a blog explaining that encrypted email had failed to take off due to the difficulties in creating a key management infrastructure outside of a closed user group.  This was followed up by two further attempts over the next 4 years at overcoming the challenges in using S/MIME.  The first of these found that whilst improvements were being made to the infrastructure, usability remained a significant challenge.  In my second attempt in 2016 I found that it was possible to get it working if you are particularly technically savvy; but for people not willing to dedicate their lives to this task, usability remains unviable.

In summary, there were 3 core challenges:

○       Client usability;

○       Interoperability;

○       Key management infrastructure.

S/MIME was designed to provide object level security, but largely failed due to these problems. Instead of this technology becoming widespread, today your emails are almost certainly delivered by the likes of Office 365 and Google who provide secure email based on secure infrastructure stories, with secure communication paths, secure storage, and secure client access. EXACTLY the world DCS is trying to get away from!

Client Usability

Whilst seamless is always the ideal, at the very least a client needs to be simple in order for it gain widespread uptake.  S/MIME clients largely failed this test, although they did move in the right direction over time, with the exception of the key management aspects (more details on that below).  This is not an area where I have a great deal of expertise, but it is an aspect of DCS which needs to be considered if this approach is ever going to take off.

Interoperability

Achieving S/MIME interoperability may eventually have become largely resolved but it was a  long slog before we got there.  DCS is only starting on this journey, with experimentation like NATO CWIX interoperability experimentation events, NATO Tide sprints and UK/US interoperability trials at Bold Quest.

A key observation as an onlooker to S/MIME progression was the need for local implementer agreements to get interoperability to work. This is akin to S/MIME in the 1990s, where it took over 10 years from inception for standards to evolve and mature to iron out these challenges.

Key Management Infrastructure

One of the fundamental S/MIME failings was the dependence on a PKI.  PKI is a relatively straightforward technology, but fiendishly hard and expensive to deploy.

Robust security consists of the combination of people, products, and process.  The process element is a vital and often under invested element.  For key management in particular it is a very costly element to get right.  It works reasonably well in a closed user group, but in an open environment there needs to be bilateral agreements in place for a PKI to operate effectively.

This seems to be an area which current DCS research is consistently dealing with at a closed level, pushing the hard challenges out for future research.  This could prove to be a mistake as it was this issue that finally killed S/MIME – infrastructure-based security was ultimately deemed easier to deploy.

Lessons

As the saying goes ‘Those that fail to learn from history are doomed to repeat it’ and if we do not learn from the challenges and failures of S/MIME, alongside other relevant technologies and approaches, then DCS could also find itself on the losing side of a decades’ long battle for relevance. So, to reiterate, here are three key obstacles I’ve identified that DCS research and development must overcome before its potential as an approach can be realised.

DCS needs to:

• If not seamlessly integrate into other technologies, at the very least be simple to deploy for reasonably tech-aware individuals;

• Rapidly develop deployment standards to avoid lengthy interoperability challenges that will destroy faith in the solutions;.

• Grasp the difficult key management issues and find a deployable and manageable solution.