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;"

 

This was AFAIK introduced due to anticipated 
requirements put by HIPPA, GLBA, etc.

 

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.

 

Media Encryption

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.

 

Selective Data 
Encryption

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.

 

User-initiated 
Encryption

However, making explicit encryption and decryption 
by users, a major activity seems less attractive for a number of reasons which I 
will try to explain.

 

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.

 

Solution

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...

 

The "Super User" - A remaining 
problem?

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.

 

Legislators do 
typically not specify technology

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. 

 

From an implementation point of view, message 
encryption, severely complicates the design as well.

 

Anders Rundgren

 

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.