On Tue, 2003-12-23 at 02:21, Wayne Wilson wrote: > Richard D Piper wrote: > > 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.
The underlying reason the HeSA PKI has floundered (it ihas not failed, but the take-up rates have been very low considering how much money has been spent on it) is because they took a hierarchical PKI design designed for compliant employees working in hierarchical organisations, and try to promote it to GPs who are independent businesspeople who traditionally value their autonomy from govt. > > 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. I suspect that one of the problems is the insistence on single large scale deployments of X509 PKIs. As Adrian Midgley has pointed out, most health professional interaction is quite local, so it makes sense to use PKI which reflects that. > > 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). Did CMU publish the research? I think these observations (which I am sure are correct) underline the need for "wrappers" around the technology, such as Argus, or Cryptonit. Bare-bone GPG is never going to fly, nor will simple GUI wrappers around the GPG operations and components. The technology needs to be even more hidden that that - users just supply a passphrase, once, and everything else happens automatically and transparent for the rest of the day - that's one of the design aims of Argus and similar systems. Similarly public key distribution, maintenance of keyrings etc etc needs to be entirely transparent to the user - as far as they are concerned, they just look someone up in a directory and send him/her encrypted mail. Perhaps the system might warn the user if the level of trust in that persons' identity is insufficient. > > 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. Yeah, its a mess. > > 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. Yes, as HeSA has discovered here in Australia, the real world is rather chaotic and anarchic. > > > > 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. As an aside, namespaces are a problem with the GPG web-of-trust model as it stands, but can be addressed, I think, by weaving GPG and OpenLDAP directories together - many projects do that. But attention to namespaces **is** very important. > > 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. Fascinating pointers - thanks! > > :) 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? So far I have exchanged GPG encrypted mail with 4 people on this list (Wayne is one of them). That's the sum total of my encrypted mail universe so far - rather disappointing. -- Tim C PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0
signature.asc
Description: This is a digitally signed message part
