question re practical use of secret sharing

[Allen]

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" <cljt1 at jacksons.net> 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 majordomo at metzdowd.com
> 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com