Actually I worked on a project recently that had this scenario.
Paramedic team picks up heart attack/stroke/serious accident
patient. The paramedic tending the patient is using a laptop to
record EKG or other electronic medical process.
Even with the siren on they get in a serious accident that puts
the paramedic in a coma due to a concussion. The laptop with the
data is broken.
At the hospital they yank the hard drive and using an adapter
cable mount it on another computer. However, since medical data
is considered personal and private data the hard drive is
encrypted. The patient, especially if a stroke victim, needs to
have his condition understood immediately. Yes, they can do the
same tests again, but that does not give them a baseline to
compare to: Is the patient getting worse, staying the same, or
maybe even improving? With a stroke victim there is a very short
window for doing some types of treatment.
How do you recover the data?
Two solutions were considered, one was secret sharing and the
other was StrongAuth's commercial version of the open source
StrongKey. The StrongAuth approach was better than the secret
sharing but both were way ahead of the next possible choice.
The primary reason that the StrongAuth approach would work better
is that the medical data would be stored an a folder/partition
that every person with the same level of access rights or higher
could access the data with their own authentication via a stored
certificate. This would mean there would be many people's
certificate stored on the drive, but being relatively small this
would not pose a problem.
The secret sharing was next best because anyone at the hospital
could call a central paging system that would page all security
people with the number to login to. If enough shares were created
- we were thinking 99+ for a major medical system - then the
minimum needed - we were thinking three - to recover the key
would be available 24/7/366 to generate the needed key to allow
access.
Both would work, but in this scenario, the local certificate
would be faster by several minutes. If StrongAuth did not exist,
then the secret sharing approach would be the only approach that
could be made to work fast enough.
Granted this seems like a corner case, but, trust me, this
scenario happens several times a year in the USA. What with
medical diagnosis and treatment being pushed closer to the scene
of the emergency this is likely to become more common.
Except for time critical events, secret sharing is the easiest to
deploy and use in a robust way but there are very few, none that
I could find, implementations of it that would have enough shares
to cover vacations, out of range, and other vagaries of human
existence.
BTW, on the net is a demo of secret sharing:
http://point-at-infinity.org/ssss/demo.html
Allen
Peter Gutmann wrote:
"Charles Jackson" <[EMAIL PROTECTED]> writes:
Is anyone aware of a commercial product that implements secret sharing? If
so, can I get a pointer to some product literature?
It's available as part of other products (e.g. nCipher do it for keying their
HSMs), but I don't know of any product that just does... secret sharing. What
would be the user interface for such an application? What would be the target
audience? (I mean a real target audience, not some hypothesised scenario).
(This is actually a serious question. I talked with some crypto guys a few
years ago about doing a standard for secret sharing, but to do that we had to
come up with some general usage model for it rather than just one particular
application-specific solution, and couldn't).
Besides that, user demand for it was practically nonexistent... no, it was
completely nonexistent, apart from a few highly specialised custom uses we
couldn't even find someone to use as a guinea pig for testing, and the
existing specialised users already had specialised solutions of their own
for handling it.
Peter.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
