Hi Sebastian, Correct!
The lifetime of a digital signature is some environments is quite short, which is why one gets to change it periodically. However, for permanent records the digital signature of the creator can remain fixed since the record is fixed. You are correct re data transmission, but then to Requestor's and Receiver's digital signatures can be used (again short lifetime). While actively being handled/processed an audit trail is handy. A Historical Electronic Record in a Court of Law is required to emulate that of say a paper Historical Record. If the law states 30 years, then make it 30 or change the law. This is probably not feasible since changing this law that has existed for some time may have to satisfy other requirements that lead to its enactment. -Regards! -Thomas Clark Sebastian Garde wrote: >Hi, > >There is another issue with digital signatures in the context of EHRs: >Their value decreases over time and with them the value of digitally >signed documents as legal evidence. >In other words: securely signed documents don't necessarily provide a >secure basis for verifying authenticity for the required time-span of >EHRs (30 and more years). > >This is due to the following reasons: > - the employed cryptographic algorithms and the keys lose their >security qualification in the course of time. (algorithm may found to be >insecure, key length may be too short for increased computer power,..) >- It cannot be guaranteed that the directories and documents needed for >the verification of the underlying certificates are available for 30 >years or more. > >In addition, the use of digital signing procedures is often insecure and >information for the subsequent evaluation of the actual security is >missing. >To achieve high conclusiveness of digitally signed documents and to >realize their integration into practical use, the documents complete >life cycle ranging from generation of the document, generation of the >signature, presentation, communication to (long-time-)archiving and >later use have to be taken into account in a comprehensive way. > >For a truly long-term-solution for EHRs, a solution must be provided for >this problem. >If you are interested in details, see http://www.archisig.de/english > >Further, signed data may - of course - not be changed in order to keep >electronic signatures valid. But when data has to be exchanged across >networks, or in context of systems migration, such changes are >inevitably occuring. Trying to avoid this with the help of new >standardized and stable data formats contradicts experiences (although >openEHR itself might be a solution for this problem). >So, procedures are necessary to convert signed documents and preserve >their evidence value (legally secure transformation). See >http://www.transidok.de/index-en.html for details. > >Regards, >Sebastian > > >Dr Sebastian Garde >Faculty of Informatics and Communication >Central Queensland University >Rockhampton Qld 4702, Australia > >s.garde at cqu.edu.au >Ph +61 (0)7 4930 6542 >Fax +61 (0)7 4930 9729 >http://infocom.cqu.edu.au/hi > > > > > >-----Original Message----- >From: owner-openehr-technical at openehr.org >[mailto:owner-openehr-technical at openehr.org] On Behalf Of >lakewood at copper.net >Sent: Monday, 7 March 2005 5:20 AM >To: openehr-technical at openehr.org >Subject: Re: Authenticity Issues [was: Re: Demographics service] > > >Hi Bish, > >Periodic and immediate 'Bio' identification would satisfy certain >security requirements >re authenticity, e.g., official documents (e.g., post surgical release). > >Your comment re >'thumb imprint', or scan, provides a more secure means of authentication > >that may be >required. > >Requiring that a 'digital signature' be incorporated within a EHR is a >step forward but >if all that is required is the presence of a digital signature one can >be obtained from >multiple sources. > >As you indicated 'verification of authenticity' is required. >Verification, however, can be >'fooled' as well, e.g., where digital signatures are collected in >advance into a set of >'secure signatures' the presence of one or more of these signatures >within an EHR >indicates just that and no more. > >How is this solved in other fields? 'Bio ID' is one approach, e.g., >'finger and thumb imprint', >a digital photo and a voice track, in addition to other digital >signatures puts up a much >higher wall. I am intrigued by the combination of voice tracks with >background syn, >e.g., Practitioner and Practitioner + Patient.. > >An example would be a Hospital Delivery Room (multiple persons) and an >automatically >generated voice track Properly encrypted the track would be hard to >break and/or >deny. > >In other areas similar approaches are available, e.g., encrypted >time/date/voice tracks >can be integrated into Medical devices and then into EHRs. Side benefits > >include >integration of the time/date into the EHR. > >A major problem with the photo approach is that some persons become >unrecognizable >after a 12 hour shift. > >A problem with ordinary 'digital signatures' is that they can be hacked, > >patched and the >wrong ones, e.g., a reserved place in an EHR for a fixed-length digital >signature is bad >since one might be able to place another there. > >Regards! > >-Thomas Clark > > >USM Bish wrote: > > > >>-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA1 >> >>On Sat, Mar 05, 2005 at 07:34:47PM +0100, Karsten Hilbert wrote: >> >> >> >> >>>>The main issue here is varification of authenticity of digital data >>>>entry. There must be some mechanism to ensure that every entry >>>>placed in the EHR must be authenticated by the signitory, even if the >>>> >>>> > > > >>>>entry is made by a secretary, DEO or transcription- ist. >>>> >>>> >>>> >>>> >>>A first-step solution might be this: >>> >>>- writes are tracked (author, timestamp) >>>- regular clear-text database dumps are taken (say, twice daily) >>> this includes the tracked writes (eg audit logs) >>>- dumps are signed to be authentic by a, say, CMO >>>- dump hashes are timestamp-signed by non-affiliated third >>> parties (say, digital notary servers provided by medical >>> faculties, etc.) >>> >>> >>> >>> >>> >>This is a logical process to start with. The issue here is >>acceptance and institution of the 'notary servers' ... these need to >> >> > > > >>find a place within the system universally. >> >> >> >>[some snipped] >> >> >> >> >>>>Audit trails of visits are only to ensure read access by >>>>authorised agencies. >>>> >>>> >>>> >>>> >>>Even that does not really add any value. IF access occurred it must >>>have occurred with proper credentials (barring bugs in the software). >>> >>> >>> >>> >>Yup, as far as the technical side is concerned, this should be the end >> >> > > > >>point that we need to go for presently ... >> >> >> >> >> >>>The question is whether those credentials were abused by >>>someone who wasn't supposed to know them or by someone in the know >>>but who wasn't supposed to access that part of the data. One study >>>showed a decrease in the latter when "tracking reads" was announced to >>> >>> > > > >>>the regular users. >>> >>> >>> >>> >>These are human shortfalls. The fact is, if a sysadmin is happy to >>broadcast access passwords to all-and-sundry, ultimately, >>he/ she is to be held responsible. It is possible to >>incorporate much more stringent access methods by thumb imprint or >>pupil signature varification (and methods yet to come). However, >>such mathods may not be easily deployable or cost effective. >> >>Just my 2p >> >>Bish >> >> >> >>-----BEGIN PGP SIGNATURE----- >>Version: GnuPG v1.2.3 (GNU/Linux) >> >>iD8DBQFCKrmHr5z5toona28RAkTiAJ4hy3mVByXwyOIhPnzFQhoxQ+3powCfbiMq >>Chr+CL6Y/Z6uAj+fvXReau4= >>=4UHc >>-----END PGP SIGNATURE----- >>- >>If you have any questions about using this list, >>please send a message to d.lloyd at openehr.org >> >> >> >> >> >- >If you have any questions about using this list, >please send a message to d.lloyd at openehr.org > >- >If you have any questions about using this list, >please send a message to d.lloyd at openehr.org > > > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
