agsc-tpki-requirements.txt - The Encryption "Business Requirement"

"2) The ability to encrypt web-form content using public-key
   cryptography with public-keys embedded in the form, or that
   can be found using URIs at encrypt-time. The encrypted
   transaction must propogate all the way to the end-application
   as opposed to just the web-server;"

At 50000 ft. it indeed seems quite reasonable to consider encryption as a general solution to reduce data breaches. But since TPKI is targeted to also function where "the rubber meets the road", I believe it is wise to perform some initial feasibility studies before casting things in stone. Here are my current findings.

It is obvious that encryption is a natural solution for protecting against data theft for backup tapes and for disks in mobile computers. This type of encryption is already widely deployed, and is usually transparent for users. Such facilities are also likely to very soon be a part of the operating systems itself due to the advent of Trusted Platform Modules (TPMs). In fact, Windows Vista will reportedly support volume encryption in its very first incarnation.

In health care systems there is a whish to make certain data encrypted so that only the right group of people can make use of it. This is particularly interesting for research applications where you gather statistics on patients, but preferably without violating their privacy. Nevertheless, even when performed in a server environment (outside of TPKI territory), encryption create issues regarding key management and much slower operations (like short-circuiting Indexes in databases), making other options such as "data filtering" an alternative way of dealing with these requirements.

Encryption during data capture may not seem like a problem since you could use the storage server's public key to encrypt data for secure storage. However, the primary reason for storing data, is presumably for using it a number of times in the future. This opens a can of worms. First, hardly any financial or health data is likely to only be accessed by a single person. Due to this, there will be a need for multiple keys and server-based decryption schemes, or distribution of the same secret key to multiple persons. This breaks the nice and clean picture, as well as introducing new kinds of vulnerabilities. Secondly, no matter what security scheme you use, it is in an organizational context unthinkable to not have a master key (stored in a safe deposit box), which is the 21st century version of "open sesame".

Personally, I am a firm believer in transparent security. A PIN-code every now and when is OK, but selecting encryption keys for carrying out day-to-day tasks seems quite a bit over the top. Even Doctors are only humans.

Strong user authentication, transport encryption using SSL, TPM-hardened operating systems, master keys, and transparent media encryption should in my opinion sufficiently address the technical part of current and future data protection regulations and directives. The rest is "simply" procedures...

In a paper found on the Internet, the problem with the super-user was mentioned. It is true that if a server is compromised and somebody is able to login as "root" (UNIX) or Administrator (Windows), data could be stolen. TPM-hardened operating systems address this problem. But even then the super-user is actually a problem; In spite of the fact that you trust the super-user for administering accounts, creating backups and installing applications, you don't not necessarily approve of unrestricted access to sensitive data. However, it appears that strong authentication using PKI and thus eliminating the need for "password reset", together with new account administration modes, requiring user consent or access to the corporate master key, can enable that fine balance between flexibility and rigidity that advanced data protection schemes require.

Few if any current data protection acts specify technical solutions[1], but rather the goals of data protection. This is similar to HSPD-12 (PIV) which does not specify how the identity scheme is to be engineered, but what it is supposed to accomplish. That NIST, the technology arm of the US government, forged PIV in PKI, is because NIST found that PKI was the most suitable technology for the task. There is though little reason to assume that legislators will begin to deal with technical solutions. Somehow, even legislators in all their power and glory, feel their limits...

My conclusion FWIW, is that there is no apparent reason for adding message encryption to Transaction PKI, and if there is, it is at least lacking a description showing how this would work in real-world applications.

1) The signature directives are exceptions to this rule but they are not really about data protection, but about enabling computer applications to replace critical paper-based processes.

pki-guidelines message