I would be grateful for any advise regarding the secure transmission of patient data over the Internet. In Australia there is a PKI infrastructure (HESA) funded by the HIC (Health insurance commission). It works, but is quite complex.AS you have no doubt found out by now, any alternitive involving PKI is technologically complex. I won't weigh in on the technical aspects, instead I will risk that those of you participating in the discussion understand the priniciples of the technology.
I would suggest, no, I will state quite categorically, that whomever approved this project was taken in by a combination of vendor promotion, industry hype and poor due diligence on their part.
I have been responsible or partially responsible for similar decision making within several contexts:
A large regional health care system.
A large public research university.
Post 9/11 sensitive research operations. (tracking and movement of controlled substances, etc.)
Despite my fascination with PKI technology, almost from the day that Netscape enabled SSL in the browser, I have continuously concluded that the 'products' (as distinguished from the technology) are not suitable for widespread deployment. (i.e., we avoided wasting millions of dollars on a enterprise deployment).
I have based these conclusions on both my own evaluation of the technology which involved use case analysis of how typical users in the system would behave, the status of the PKI standards and market research.
Use case analysis: research has shown that end users don't understand 'key', despite the work keys seemingly familiar sounding. Carnegie Mellon did a research study involving PGP and discovered alarmingly high rates of mis-understanding which lead to mis-use. (n.b. I have seen similar behavior in the two pilots I have been part of, both e-mail based).
PKI standards: Take a look at the IETF PKI work (PKIX) at: http://www.ietf.org/html.charters/pkix-charter.html
25 Draft standards and 21 RFC's. Now compare this with kerberos: 9 Drafts.
Kerberos is often dismissed as being too complex to implement, you can decide how much more complex pki must be.
Market Research: All implementations that I know of have been either pilots or large rollouts into a completely controlled situation, i.e. where all aspects of client software can be controlled. There is little ROI to be found except in vendor white papers.
>
I anyone aware of a better, public key cryptography system that could be used for this purpose, or even a PKI system that is successful and widely deployed.Your question breaks down into two parts:
Secure transmission: The SSL (now TLS) implementation of what I will call server authentication is widely deployed and successful in creating encrypted data streams in the following protocols: HTTP, SMTP, IMAP, less used in telnet. The SSH protocol is more often used where telnet or ftp was used and essentially is a similar server side authentication model.
Principal authentication: No successful wide spread deployments that I know of, except in tightly controlled client side software.
From your description it sounds like HESA was more concerned with authentication then encrypted data streams. The idea that there will be some widespread authentication mechanism that furthermore uses a widespread namespace run's afoul of so many problems in the commerical and academic world, that I doubt, short of a strong central government, we will ever see it. (each authentication realm or domain is defined by it's namespace, thus while one could have 100 implementations of the same authentication technology, each could exist in it's own namespace, and probably does). Note the big discussion on this list about MPI's, the proof of multiple namespaces in practice.
There is some work being done in the academic network research world (Internet2) involving a technology broker to establish trust between various authentication realms. The idea being that one can't really expect people in a different organizational context to use your namespace, so let's install trust relationships between namespaces. The I2 work plays close attention to the end user, essentially allowing them to make a decision as to whether to allow sharing of credentialling information. This is a privacy issue.
http://shibboleth.internet2.edu/index.html
This work is called Shibboleth and is being used in pilot production for access to various electronic journal resources. I.e, a Univeristy of Michigan authenticated user can access any jstor archive via shibboleth without re-authenticating or the journal source relying on IP address authentication (which is widespread right now).
http://www.jstor.org/news/2003.10/shibboleth.html
Note that a similar effort involving PKI infrastructure is also being worked on, but that it has not gotten as far as fast as shibboleth.
Another type of solution, that does not involve the co-operation of each institution to install the trust brokers, is to control access yourself. The almost always leads to entering all your end users into a single namespace. (In essence what the pki vendor tried to do in HESA's case, only with an unwieldly technology) In order to avoid the problems of client side software installation, one can place a pki enabled infrastructure on a server and provide web server based access to messaging along with java applet or web-start style access where it will work. There are many companies doing this in the US as a form of HIPPA compliance. The most interesting version of this I have seen is the new product from PGP, PGP Universal:
To quote from their marketing:
"PGP Universal is entirely automatic and policy-managed, operating without the need for ongoing user or IT intervention. PGP Universal’s Self-Managing Security Architecture provides central security policy management; automatic key generation and life cycle management; and automatic encryption, decryption, and digital signatures."
see: http://www.pgp.com/products/enterprise/universal/universalfeatures.html
At least one security analyst, whose opinion I have some faith in, believes this system works in practice, so it's probably worth some more research.
:) How many of you have noted the pgp signature aspect of my messages and my information note below and been able to do anything with it?
--
Wayne Wilson
An attachment containing my pgp-signature is included.
My public key fingerprint is:
9325 05AD 866B BCCB 45BF E86A 63E1 C6ED 4130 5461
My public key can be downloaded from wwwkeys.us.pgp.net
pgp00000.pgp
Description: PGP signature
