Horst,
most excellent. You seem to have implemented what I have
been thinking of implementing for our practice for a long
time. (Although then I'd be lacking the trusted third party ...)
I will try to review the code and also try to advocate
it to Germany's GP top level organisation (KBV -
Kassenärztliche Bundesvereinigung as you may recall).
I have been thinking of this scenario:
A trusted Third Party maintains a Stratum 2 server (time
synced with Stratum 1 servers, those with actual atomic
clocks, that is) running the notary server and "nasty"
security software (portsentry, iptables, hostsentry,
selinux, chrooted demons, ssl, ssh, et cetera). Clients
connect, authorize (mainly for bandwith management
issues) and send a chunk of data. Ususally this chunk
would consist of the following:
- sender identification (not needed if the server
returns an unique ID which makes it possible to
match client side and server side data)
- sender-local timestamp
- file name
- file size
- file ripemd-160
- optionally other file hashes
The notary server would server-local timestamp, sign,
ID and save the request. It would then send the server side
timestamped, cleartext signed and ID'd request back to the
initial sender who stores it along with the file.
Preferably all this would run over ssl protected channels.
Now, whether that file was a 1 GB backup of an entire
medical software package including apps and data, a
transaction log at 23:59 Wednesday the 7th of March 2001
or some other random file does not matter.
I am excited. Let's get to the source :-)
It sure sounds like one of those killer medico-legal apps
that also have the potential to backdoor themselves into
official organizational structures.
In fact, the server demon need not be concerned about
GUI, tar, gz, bz2, whatever. That may well be left for
the client(s) (which you seem to build in wxRiper).
Regards,
Karsten
--
GPG key ID E4071346 @ certserver.pgp.org
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
