« Rethinking stored document encryption: Part 8 | Main | Site Specific browsers »

Rethinking stored document encryption: Part 9

We have one remaining issue to consider but it is probably the most difficult of all: deployment.


Designing and building software is easy. Establishing a critical mass of users is the hard part.


At this point we need to go back and consider what advantages CLE provides that existing schemes such as whole disk encryption or directory level encryption do not. In my view the answer is that storage level encryption can provide security when used correctly, CLE makes it much harder to make the type of mistake that can lead to a breach. Whole disk encryption is good but it only works as long as the authorized user does not copy the data to a USB thumb drive. Directory level encryption is even more fragile and can fail when an application unexpectedly makes a copy of the sensitive data in an unencrypted location.


A part of any CLE deployment strategy must be developing programming toolkits that allow an existing application to be CLE enabled with minimal effort. One of the reasons that SSL has become so popular is the fact that by design the API for SSL toolkits look almost identical to the traditional BSD socket API.


We have most of the PKI infrastructure required to support CLE. All we are missing at this point is the key management server. If we are going to make CLE a reality though we need to establish a critical mass of applications.


Although I have focused on the 'network CLE' problem, this is in fact a superset of the single user CLE problem and even applied at the single user level, CLE provides considerable value. I would like to be able to copy files to a USB thumb drive without worrying about creating copies of possibly confidential information.


Ubiquitous deployment of CLE will take many years, perhaps a decade or more. But in the meantime niche deployment of CLE can address the most difficult, highest risk activities.


For example, the typical data breach occurs when an auditor loses a laptop or thumb drive containing sensitive personnel data. Why is it always an auditor? Possibly because they are the only people who confess. But regardless, deployment of CLE to every desktop in an enterprise is hard. Integrating CLE into the export function of the HR database and insisting that the auditor install an open standards based plug-in into their spreadsheet is much easier.


Another area that might be the killer application of CLE that creates the necessary critical mass is CAD/CAM. A large part of the CAD/CAM market is involved in classified government work or designs that are commercially sensitive and unlike the office applications market, the market for CAD/CAM applications is fiercely competitive.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)