Encryption - or Confidentiality?
I was recently invited to Terisa Systems of Los Altos, California, for a briefing on their latest encryption product, Secure Web Documents®.I believe that the term "encryption" is a major source of misunderstanding in this area. The term is technically correct. But, at least in my mind and in the minds of those with whom I have discussed this, it is misleading.
It brings up images of men with code books and radios concealed in suitcases, of the CIA and clandestine operations.
In fact, of course, the field is a lot broader and less sinister than the image I present.
It is simply an attempt to recreate the conditions of confidentiality we take for granted in the "real world". Like closing the door if you want to have a private conversation.
Efforts at Web security have hitherto concentrated on constructing an impregnable "pipe" between client and server. This has been achieved through the development of two protocols, SSL ("https") and Secure HTTP ("shttp").
Secure Web Documents® operates slightly differently within the "shttp" protocol. Through the use of both client and server plug-ins, virtually any document in almost any format can be "encrypted" - or made confidential - throughout the life of the document.
Here's how it works.
As a user, one is issued a "certificate" by a "trusted third-party". A "trusted third-party" is an organization which issues digital identity cards - or "certificates". Each certificate has two "keys" - a public one and a private one.
At its most basic level, a digital ID is verified through an eMail address. (You have probably collected a few certificates without realizing it. If you're using Netscape Navigator, go to the "Options" menu and click on "Security Preferences" and open
the "Certificates" menu. You will be presented with a list of cryptically named documents. Probably...)
Obviously, simply using an eMail address for verification is pretty low-level. Certificates can be ranked hierarchically, with increasing levels of verification - for example, the provision of a Social Security number, mother's maiden name and so forth.
In essence, your digital ID confirms that you are who you say you are. Its acquisition is the first step in being able to transfer data confidentially.
The second part of the process involves the document you wish to send confidentially.
Often, this will be a form which is filled out at a remote site, although it can be in pretty much any format - PDF, Word, Excel, for example.
By submitting the form - or clicking on a link - Secure Web Documents® takes a "snapshot" of the document. This is then bundled with the document itself and your digital ID. The whole package is "scrambled" and sent to the recipient.
The recipient checks your bona fides by checking your certificate against the one lodged in the third-party database, and then opens the document itself.
The document is verified by comparison with the "snapshot" which accompanies it. If the document has been intercepted and altered, the original will not match the snapshot and an alert is sounded.
Secure Web Documents®, then, allows two types of verification: one of the sender/recipient; and one of the document itself.
The catch (such as it is), is that both you and the recipient have the requisite client plug-ins, and that your servers both have the server plug-ins.