Privacy Preserving Back-up and Recovery of Emergency Data                               Seminar on System Security for Mas...
Contents1 Introduction                                                                                                    ...
List of Figures  1    Overview of the entire architecture [Gem08a] . . . . . . .         .   .   .   .   .   .   .   .   ....
List of AbbreviationsDEC             Decryptione.g.            for exampleeHC             electronic Health CardENC       ...
1     IntroductionPreserving the privacy of the patient in case of emergency or by back-up/recovery of personal data onthe...
Figure 1: Overview of the entire architecture [Gem08a]                          Figure 2: Primary systems architecture [Ge...
2.3    Health Professional CardThe Health Professional Card (HPC), which nowadays is an immutable part of the eHC concept,...
in the atmosphere, causing mass ight cancellations all over Europe, spanning from the UK to      Russia over fears that th...
documentation there can be made two more back-ups, though they are not obligatory. First a docu-ment with the data concern...
3.3    Disadvantages of the solutionAfter we have scrutinized the process of saving the emergency data and creating a back...
Figure 6: Recovery of the emergency data on the eHC    From these examples we can conclude that the process possesses two ...
4.1     Secret Sharing Scheme (n,m)                               Figure 7: Secret Sharing Scheme(n,m) [Sch06]     Secret ...
The Shamirs Secret Sharing Scheme is    information-theoretically secure     (also    unconditionalsecure                 ...
1. randomly pick a symmetric key     K and encrypt symmetrically the secret S, building E= ENCk(S)    2. partitionE in n f...
Figure 11: Overview2. Complete the form for emergency data and/ or form for organs donation   In this phase all necessary ...
Figure 12: Our proposal solution one for back-up of emergency data(b) In case of emergency, if the eHC is not present (for...
Figure 13: Our proposal solution two for back-up of emergency data      The advantages of this proposal solution for back ...
2. Recovery   For the process of recovery of emergency data, we will present two proposal solutions as we did   for back-u...
Our proposal solution two for recovery of emergency data               By this solution (Figure 15)      we use Krawczyks ...
back-up and recovery of emergency data, which can be easily implemented. In our proposal scenario,we tolerate non-availabi...
[Sha79]      Adi Shamir.         How to share a secret.             ISSN 0001-0782. In Communi-             cations   of  ...
·   Glass eye      ·   Contact lens      ·   Obligatory dialysis renal insuciency      ·   Chronic liver insuciency      ·...
Figure 16: Standard form for organ donation [Gem08d]               Figure 17: Aris legend                         23
Upcoming SlideShare
Loading in …5
×

Privacy preserving back up and recovery of emergency data

790 views
736 views

Published on

Published in: Education, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
790
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
4
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Privacy preserving back up and recovery of emergency data

  1. 1. Privacy Preserving Back-up and Recovery of Emergency Data Seminar on System Security for Master Summer Semester 2010 Zdravko Danailov Matr.Nr.: 108003256581 3rd August 2010 Abstract The processes of back-up and recovery of emergency data play an important role within the Telematics system. Their completion has to be executed completely secure with no risk of a data loss and preserving the privacy of the patient. In this paper we will take a look at the existing/proposed scenario for back-up/recovery of emergency data and discuss the problems by its implementation. In order to improve this scenario and solve the problems we will put forward a new scenario. 1
  2. 2. Contents1 Introduction 52 Preliminaries 5 2.1 The Telematics infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Electronic Health Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Health Professional Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4 Hardware Security Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5 Emergency data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.6 Existing problems by donation of organs . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Scenario Back-up/Recovery of emergency information 8 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 Examination of the existing/ proposed solution . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 Disadvantages of the solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Krawczyks Secret Sharing Scheme 11 4.1 Secret Sharing Scheme (n,m) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2 Shamirs Secret Sharing Scheme (n,t) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3 Information Dispersal Scheme (n,m) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4 Krawczyks Secret Sharing Scheme (n,m) . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Our proposal solution 14 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2 Back-up of emergency data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.3 Recovery of emergency data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Conclusion 19A Appendix A 21B Appendix B 22C Appendix C 22 2
  3. 3. List of Figures 1 Overview of the entire architecture [Gem08a] . . . . . . . . . . . . . . . . . . . . . . . . 6 2 Primary systems architecture [Gem08a] . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4 Scenario for back-up/recovery of emergency data . . . . . . . . . . . . . . . . . . . . . . 9 5 Period of renewing of the eHC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6 Recovery of the emergency data on the eHC . . . . . . . . . . . . . . . . . . . . . . . . . 11 7 Secret Sharing Scheme(n,m) [Sch06] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8 Curve over 5 points [Sch06] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9 Information Dispersal Scheme (n,m) [Sch06] . . . . . . . . . . . . . . . . . . . . . . . . . 13 10 Krawczyks Secret Sharing Scheme(n,m) [Sch06] . . . . . . . . . . . . . . . . . . . . . . . 13 11 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12 Our proposal solution one for back-up of emergency data . . . . . . . . . . . . . . . . . 16 13 Our proposal solution two for back-up of emergency data . . . . . . . . . . . . . . . . . 17 14 Our proposal solution one for recovery of emergency data . . . . . . . . . . . . . . . . . 18 15 Our proposal solution two for recovery of emergency data . . . . . . . . . . . . . . . . . 19 16 Standard form for organ donation [Gem08d] . . . . . . . . . . . . . . . . . . . . . . . . . 23 17 Aris legend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3
  4. 4. List of AbbreviationsDEC Decryptione.g. for exampleeHC electronic Health CardENC EncryptionePrescription electronic Prescriptiongematik Gesellschaft für Telematikanwendungen der Gesundheitskarte mbHGMA German Medical AssociationHIS Hospital Information SystemsHPC Health Professional CardHSM Hardware Security ModuleIDS Information Dispersal SchemePAS Practice Administration SystemsPhAS Pharmacy Administration SystemsPIN Personal Identication NumberPTA Patient Transport AmbulanceSOA service-oriented architectureSS Secret SharingVPN Virtual Private Network 4
  5. 5. 1 IntroductionPreserving the privacy of the patient in case of emergency or by back-up/recovery of personal data onthe electronic Health Card (eHC) is an important aspect by the development of the Health Telematicsinfrastructure. Its very complex structure, in which there are several dierent groups of involvedpersons, as well as its usage for transfer and storage of signicant data, certainly arise the questionabout the security. The goal of this paperwork is to examine the existing/proposed scenario for back-up and recovery of emergency data made by gematik- Gesellschaft für Telematikanwendungen derGesundheitskarte mbH [SOZ09]. We will analyze how secure is this scenario, as regards to the risk ofexposing personal information about a patient and irreversibly losing an information.Outline In order to scrutinize the existing scenario for back-up and recovery of emergency data, thestructure of this paperwork proceeds as it follows: Chapter 2 focuses on the theoretical fundamentalsof the Health Telematics infrastructure, and gives brief information about the necessary types of cardsused by the scenario. Also pays attention to what are emergency data and Hardware Security Module.An analysis of the existing/proposed scenario within the Telematics infrastructure, as well as its dis-advantages will be performed in chapter 3. Chapter 4 is about the Krawczyks information dispersalscheme. It will pay attention to specic details, concerning the dispersal and recovery of importantdata. In chapter 5 our solution of the scenario will be presented, eliminating the disadvantages forthe proper execution of back-up/ recovery of emergency data, determined in chapter 3.Chapter 6 willconclude with a critical view on the existing scenario, which has already been examined in detail inthis paperwork. Before we start with the examination of the scenario prepared in order to store emergency data asa back-up or recover such data on the eHC of the patient we will make clear some of the basic termswhich are used in this paper.2 Preliminaries2.1 The Telematics infrastructureHealth Telematics designates the combination of telecommunication and informatics in the healthcaresector. In some countries, Health Telematics corresponds to the term Tele-health and also to the terme-Health, which seems to be currently establishing itself both in Germany and at an internationallevel. The entire architecture [Gem08a] is shown in Figure 1. For the purpose of this paper we need to clarify what are the primary systems in their essence. The primary systems (Figure 2 [Gem08a]) provide application programs for the medical careproviders and insurants. The programs used by the medical care providers are Practice Adminis-tration Systems (PAS) for medical specialists and dentists, Hospital Information Systems (HIS) forhospital, rehabilitation centers etc. and Pharmacy Administration Systems (PhAS) for pharmacies.The programs, which are relevant for the insurants are eKiosk and Versicherten@Home. They providefunctions for the insurants to access their data, in order to Hide/Show specic data as well as toadministrate the rights or in some cases to delete data. [Gem08a]2.2 Electronic Health CardIn order to improve the health insurance system the German government enacted a law [SOZ09], bywhich they started an enormous infrastructural Telematics project: the introduction of a nationalelectronic Health Card (eHealth Card). This microprocessor chip card is an important element in the 5
  6. 6. Figure 1: Overview of the entire architecture [Gem08a] Figure 2: Primary systems architecture [Gem08a]fast developing Telematics infrastructure. This card is simply the key to a health system data as wellas to applications for computing and processing such data. The main purpose by the initiation of thisproject is the enhancement of eciency, quality and transparency in medical care. TThe solution is apatient based sector-spanning network with persistent information ow.-[PRS07] For this reason the toporganizations of the national German health system assumed the responsibility to create and introducethe required infrastructure and therefore founded gematik - Gesellschaft für Telematikanwendungender Gesundheitskarte mbH [SOZ09] in 2005. [PRS07]The electronic health card (eHC) is a working out of the Fraunhofer Institute supported by the FederalMinistry of Health in Germany. The eHC is conceived and developed as a service-oriented architecture(SOA) with some restrictions, such as: tthe health card can only be accessed locally on the client side;or services should use remote procedure calls for communication due to performance and availabilityissues.-[LHM09] As a result, the system architecture is divided into dierent layers. This gives tothe system the possibility to provide ÿeveral service applications such as emergency data, electronicprescription (ePrescription), electronic medical report or an electronic health record system.-[LHM09] 6
  7. 7. 2.3 Health Professional CardThe Health Professional Card (HPC), which nowadays is an immutable part of the eHC concept, pri-marily was one independent construct. In 1996 the German Medical Association (GMA) together withthe National Association of Statutory Health Insurance Physicians founded a work group named Elek-tronischer Arztausweis, which concentrated on this subject. Rapidly came clear that the introductionof the HPC would not be possible without a reconcilement with the eHC. [Sch09] HPC can be denedas än individually programmed access authorization card held by the health professionals-[ILP06] (e.g.doctors and pharmacists). Despite of the integration with the eHC, the HPC has also its own sig-nicance. Thus, the particular medical associations as well as pharmacists associations, which areresponsible for the issuance of the cards, can provide applications of their own. For example, a medicalassociation can upload a database with specic medical data online, where the HPC serves as an accesskey instead of password and login id.2.4 Hardware Security ModuleBy denition the hardware security module is a device, which securely processes and saves security-relevant information, such as crypto keys and data. It can be also a chip card controller. [Gem08c]Via the HSM, a doctor can authenticate himself and write or edit data on an eHC with the permissionof the patient. To give permission for execution of such process the patient has to enter his PIN codeover the integrated keyboard on the HSM.2.5 Emergency dataWhat are emergency data and what information is kept within? By denition this is informationabout the data in case of emergency, including the declaration (the completed and signed form) fororgans spending. [Gem08b] There are dierent main categories such as relevant diagnoses, medicationor allergy/ intolerance (please, see Appendix A). The declaration for organs spending is part of theemergency data, but it can be completed or left blank. This means that both of them can be lledout independently from one another. An example of this form can be found in appendix B. [Gem08d]2.6 Existing problems by donation of organsAmong the many problems tightly connected with the donation of organs, for the illegal trade of organsand the transportation diculties by natural perils seems to have no wholly and permanent solution. • Criminal/illegal trade of organs The criminal/illegal trade of organs is the biggest existing problem by donation of organs. There are two dierent basic types of illegal organ trade. By the rst type because of indigent con- ditions people sell their own body organs for prot. By the second the organs are taken from executed prisoners. TThe black market trade of human organs is sustained by wealthy indi- viduals, sometimes on long waiting lists for transplants, traveling to foreign countries for the procedure.-[IL009] • Transportation diculties by natural perils Time plays very important role by transportation of organs for donation. If the specic organ cannot be transported betimes to the matching person (patient), it becomes unusable. Sometimes because of natural perils such as earthquakes, oods, re or even eruption of volcanoes can induce diculties and impossibility to transport the organs to the specic location. As proof of this statement the following facts are mentioned below: on the 14th April 2010 by the eruption of Eyjafjallajökull [URL10a], located in Iceland, an enormous cloud of volcanic ash was released 7
  8. 8. in the atmosphere, causing mass ight cancellations all over Europe, spanning from the UK to Russia over fears that the soot may be catastrophic to planes - such as causing engines to fail in-ight or severely reducing the pilots visibility. The ash clouds were drifting between six to nine thousand meters above the ground, and were moving eastwards, over northern France and Austria and towards Russia at about 40 kilometers per hour. Because of the embargo over ights there were dramatic consequences for the transportation of organs. Birgit Blome (50) from the German foundation for organ transplantation said : TThe organs -heart, lungs and liver, which are usually transported via ight, are now found locally and transported by car.-[URL10b] The director of the foundation for transplantation Eurotransplant Axel Rahmel also said:Ït is already a challenge, when the transportation is possible only via ambulances or PTA (Patient Transport Ambulance)-[URL10c]3 Scenario Back-up/Recovery of emergency information3.1 OverviewBefore we start examining the scenario for back/recovery of emergency data, it is important to makeclear, which are the persons involved, what types of HSM are used, as well as what are the possibleprocesses. Figure 3: Overview As illustrated in Figure 3, the persons involved in this scenario are patient, doctor and in case ofemergency - paramedic. Moreover, there are two dierent types of Hardware Security Modules, whichare used: 1.chip cards - eHC, HPC 2. chip card terminal. Regarding the possible processes within thisscenario, the emergency data can be updated, backed up or recovered.3.2 Examination of the existing/ proposed solutionThe proposed scenario for back-up/recovery of emergency data (including data for organ donation)proceeds as it follows. The whole process (Figure 4) is executed oine. After the obligatory authen-tication through the eHC of the patient and HPC of the doctor the data on the eHC can be edited orcreated and then saved. This data is overwritten/saved on the eHC. As it is explained in the gematik 8
  9. 9. documentation there can be made two more back-ups, though they are not obligatory. First a docu-ment with the data concerned can be printed out and given to the patient for personal preservation.Second a temporary copy of the data can be saved in the primary system of the doctor within thedocumentation. If the eHC is not usable (because of substitution process, loss or defect) the insurantmust turn to the doctor, who made the last save/back-up of the emergency data. He can recover thedata on the new eHC on basis of the document given to the patient, or using the stored data in hisprimary system. [Gem08d] Figure 4: Scenario for back-up/recovery of emergency data 9
  10. 10. 3.3 Disadvantages of the solutionAfter we have scrutinized the process of saving the emergency data and creating a back-up or recoveringit on the eHC will try to cover all disadvantages of the solution. For this purpose we will examinesome theoretical cases below. Figure 5: Period of renewing of the eHC • Renewing of the eHC, because of loss, defect or expiry In case of emergency the patient has to have the document, printed by his doctor (shown in Figure 5). There is no other option for the medical person to ind outtthe data, concerning the individual health characteristics of the patient, because the process is executed oine. On rst place the creation of this document is not obligatory. Second, it is only a sheet of paper, which can be lost, stolen or destroyed (e.g. during natural perils, re). Moreover it exposes private data. • Recovery of the emergency data on the eHC The back-up made in the primary system of the doctor is only temporary. This means that if the back-up is deleted after particular period of time and the optional ppaper pack-upïs not available (1. not created, 2. created, but lost/stolen or destroyed), there is no other way of recovering the data, so it is irreversibly lost.The whole process is shown in Figure 6. 10
  11. 11. Figure 6: Recovery of the emergency data on the eHC From these examples we can conclude that the process possesses two major disadvantages: it isexecuted oine and is completely unsecure. For this reason we will propose another solution in thefollowing chapter 5, which will solve these problems.4 Krawczyks Secret Sharing SchemeIn this section we will take a look at the Krawczyks Secret Sharing Scheme (shown in Figure 10 [Sch06]),which we use by our solution for recovery/ back-up of emergency data. Before we present this specicscheme we shall clarify what is secret sharing and what are its properties. 11
  12. 12. 4.1 Secret Sharing Scheme (n,m) Figure 7: Secret Sharing Scheme(n,m) [Sch06] Secret Sharing Scheme (Figure 7 [Sch06]) was invented by both Adi Shamir and George Blackley Sindependently of each other in 1979. It is a method for distribution of a secret among a group n Sof -participants. The reconstruction of is possible only when a sucient number of shares (in mthis case ≥ ) are combined together, which means that m-1 -shares provide no information aboutS . [Sch06] [Bla79] [WIKa] [WIKb]4.2 Shamirs Secret Sharing Scheme (n,t) Figure 8: Curve over 5 points [Sch06] Shamirs Secret Sharing Scheme is based on polynomial interpolation (Figure 8 [Sch06]). Theprocess of distribution proceeds as it follows: 1. pick t points to dene a polynomial of degree t-1 2. create a polynomial of degree t-1 with the secret S as the rst coecient (k ) and the remaining coecients (k ,...,k ) picked at random 0 t−1 1 3. nd n points on the curve and give one to each of the participants (in this case n) [Sch06] The process of reconstruction proceeds as it follows: t n 1. at least out of the players reveal their points, there is sucient information to t an (t-1)-th degree polynomial to them 2. the rst coecient of the polynomial is the secret S 12
  13. 13. The Shamirs Secret Sharing Scheme is information-theoretically secure (also unconditionalsecure S ), meaning that an attacker cannot extract any information about the secret (from less thanm shares), whatever how much computational time he invests. Additionally, the size of each share Shas to be equal (or ≥) to the size of the secret , which makes the Shamirs Secret Sharing Schemestorage ecient . [Sch06] [Sha79] [WIKc]4.3 Information Dispersal Scheme (n,m) Figure 9: Information Dispersal Scheme (n,m) [Sch06] The Information Dispersal Scheme (Figure 9 [Sch06]) is based on error correcting codes, such ase.g. Reed-Salomon Code. In comparison with the Secret Sharing Scheme, where a secret S is sharedamong the participants, the Information Dispersal Scheme is a method for distribution of informationF n among a group of -participants. The reconstruction is possible when sucient number of fragments m(≥ ) is combined together. By this specic method the secrecy is not important, so it is possible to F mgain information about from less than fragments. Every fragment has a length of |F | . [Sch06] m4.4 Krawczyks Secret Sharing Scheme (n,m) Figure 10: Krawczyks Secret Sharing Scheme(n,m) [Sch06] Krawczyks Secret Sharing Scheme (n,m) (Figure 10 [Sch06]) combines both Secret Sharing (SS)and Information Dispersal (IDS) Schemes in one. The process of distribution proceeds as it follows: 13
  14. 14. 1. randomly pick a symmetric key K and encrypt symmetrically the secret S, building E= ENCk(S) 2. partitionE in n fragments (e ), using an IDS i 3. disperse K in n shares (k ), using a SS i 4. send to every participant (in this case n) a share s i ek = ( i , i ) [Sch06] The process of reconstruction proceeds as it follows: 1. at leastm out of the n players reveal their shares s i ek = ( i , i ), i 1...m 2. reconstruct E from e , using the IDS i 3. reconstruct K from k , using the SS i 4. decrypt E: S=DECk(E) [Sch06]The Krawczyks Secret Sharing Scheme (n,m) is not information-theoretically secure, because by su- Kcient computational time an attacker can nd out the key , decrypt some shares, which are common S sto him, and extract some information about the secret . Additionally, the size of each share is | i |= K S m + | | | |. [Sch06]|S|The Krawczyks Secret Sharing Scheme (n,m) needs less storage and also bandwidth in comparisonto Shamirs SS. It is computationally secure , which means that practically from m-1 shares an Sattacker cannot extract any information about the secret . [Sch06] [Kra94]5 Our proposal solution5.1 OverviewBefore we present our proposal solution for back/recovery of emergency data, it is important to makeclear, which are the persons involved, what types of HSM are used, as well as what are the possibleprocesses. As illustrated in Figure 11, the persons involved are patient, doctor and in case of emergency -paramedic. By our proposal solution we use two types of HSMs as well: 1.chip cards - eHC, HPC 2.chip card terminal. Regarding the possible processes, the emergency data can be updated, backed upor recovered.First, in our proposal scenario, we tolerate non-availability, in order to grant more possibilities forrecovery of the specic emergency data. By this way despite that a particular source, containing ashare of emergency data is not accessible, the emergency data can be still recovered. Second, weminimize the risk of revealing emergency data (private personal data), by using Secret Sharing. Third,for the processes of back-up and recovery of emergency data we use no encryption, but Secret Sharing.5.2 Back-up of emergency dataThe process for back-up of emergency data is executed in four phases: 1. Phase of authentication For authentication can be used many dierent well-known methods. The patient and doctor (or paramedic) can authenticate themselves via e.g. PIN, ID-patient/ ID-doctor, ID-eHC/ID-HPC, Fingerprints, dierent types of digital signatures, etc. 14
  15. 15. Figure 11: Overview2. Complete the form for emergency data and/ or form for organs donation In this phase all necessary information, such as relevant diagnoses, operations, procedures or relevant medications in case of emergency is lled out. As already mentioned in section 2.5, the declaration for organs spending can be also completed or left blank.3. Conrmation of the data, e.g. via ngerprint or PIN by the patient and doctor In any case of changing the emergency data (e.g. creation or update), the new copy has to be veried. So the emergency data has be read by the patient and then conrmed by both patient and doctor via ngerprint (assuming that the chip card terminal has a touch screen) or PIN.4. Back-up In comparison to the existing/ proposed solution for back-up of emergency, made by gematik, where all four phases (if a back-up is made, because its optional) are executed oine, we suggest an obligatory back-up, executed oine and online. Our proposal solution one for back-up of emergency data (a) using Krawczyks SS - executed online via e.g. VPN In this case using Krawczyks SS, we can secure a back-up of emergency data on three dierent servers; more exactly we disperse fragments of the information S (emergency data) to each one of them. (b) using a portable device (e.g. USB-Stick) - executed oine As an extra back-up, a copy of emergency data is saved in the primary system database and also on portable device (e.g. USB stick), which is given to the patient. The advantages of this proposal solution (Figure 12) for back-up of emergency data, compared to the gematik solution are: (a) The creation of back-up is obligatory 15
  16. 16. Figure 12: Our proposal solution one for back-up of emergency data(b) In case of emergency, if the eHC is not present (for any reason), it is still possible that the paramedic can obtain emergency data online (via e.g. VPN) - from the three servers. Even if one of the servers is not accessible, the information S can be reconstructed. Otherwise the necessary data can be gained from the USB stick oine.(c) The risk of exposing private data is minimised.Our proposal solution two for back-up of emergency data By this solution (Figure 13)we use Krawczyks SS to disperse the information:(a) online (via e.g. VPN) - securing a back-up of emergency data on three dierent servers;(b) 2. oine - securing a back-up of emergency data on a portable device (e.g. USB-Stick) and in the primary system database;More exactly we disperse 5 fragments of the information S (emergency data) to each one of them(please, see Figure 13: Our proposal solution two for back-up of emergency data). 16
  17. 17. Figure 13: Our proposal solution two for back-up of emergency data The advantages of this proposal solution for back of emergency data, compared to the gematik solution are: (a) The creation of back-up is obligatory (b) In case of emergency, if the eHC is not present (for any reason), it is still possible that the paramedic can obtain emergency data online (via e.g. VPN) - from the three servers. Even if one of the servers is not accessible, the information S can be reconstructed from the fragments on the other two servers and on the USB stick.5.3 Recovery of emergency dataThe process for recovery of emergency data is executed in two phases: 1. Phase of authentication For authentication can be used many dierent well-known methods. The patient and doctor (or paramedic) can authenticate themselves via e.g. PIN, ID-patient/ ID-doctor, ID-eHC/ID-HPC, Fingerprints, dierent types of digital signatures, etc. 17
  18. 18. 2. Recovery For the process of recovery of emergency data, we will present two proposal solutions as we did for back-up (in the previous section 5.2). Figure 14: Our proposal solution one for recovery of emergency data Our proposal solution one for recovery of emergency data (a) using Krawczyks SS - executed online via e.g. VPN Using Krawczyks SS, we can reconstruct emergency data from the three dierent servers; more exactly we gather the fragments of the information S (emergency data) from each one of them. (b) using a portable device (e.g. USB-Stick) - executed oine The other option to recover a copy of emergency data is from the primary system database or also from the portable device (e.g. USB stick), which has been given to the patient. In case of emergency, if the eHC is not present (for any reason), it is still possible that the paramedic can obtain emergency data online (via e.g. VPN) - from the three servers. Even if one of the servers is not accessible, the information S can be reconstructed. Otherwise the necessary data can be gained from the USB stick oine, minimizing the risk of exposing private data. In case of renewing the eHC (lost, stolen or defect), the recovery is possible online from the three servers, as well as oine from the primary system database or the portable device (e.g. USB stick), given to the patient. 18
  19. 19. Our proposal solution two for recovery of emergency data By this solution (Figure 15) we use Krawczyks SS to reconstruct the information: (a) online (via e.g. VPN) - reconstructing emergency data from the three servers; (b) oine - reconstructing emergency data from the portable device (e.g. USB-Stick) and/ or the primary system database; Figure 15: Our proposal solution two for recovery of emergency data In case of emergency, if the eHC is not present (for any reason), it is still possible that the paramedic can obtain emergency data online (via e.g. VPN) - from the three servers. Even if one of the servers is not accessible, the information S can be reconstructed from the fragments on the other two servers and on the USB stick, because we need minimum 3 sources containing fragments of S. In case of renewing the eHC (lost, stolen or defect), the recovery is possible using the online sources (three servers), combining them with the oine ones (the primary system database or the portable device (e.g. USB stick), given to the patient), if one or two of the servers are not accessible.6 ConclusionThe Health Telematics infrastructure was created and is being developed to bring security and comfort,to save resources etc. So it is simply inevitable to set limits to the need of fast and practical solutionswithin this rapidly developing system. However, it arises the question about the functionality ofthese solutions. In this paperwork we have scrutinized a solution for the processes of back-up andrecovery of emergency data and we have shown some problems by their execution. Thats why, afterweve analyzed these problems, we have tried to eliminate them, by working out a better solution for 19
  20. 20. back-up and recovery of emergency data, which can be easily implemented. In our proposal scenario,we tolerate non-availability, in order to grant more possibilities for recovery of emergency data. Weminimize the risk of revealing emergency data (private personal data) and try to keep the solutioneasily applicable, by using Secret Sharing. This makes our proposal solution computationally secureand facile to implement within the existing Health Telematics infrastructure, which despite of itsstrengths or weaknesses is a reliable, trustworthy system that will play an enormous role for thefurther development of the health care sector.References[Bla79] G.R. Blakley. Safeguarding cryptographic keys. In Proceedings of the 1979 AFIPS National Computer Conference, volume 48, pages 313-317. AFIPS Press, Monval, NJ, USA. 1979.[Gem08a] Gematik. Einführung der Gesundheitskarte - Gesamtarchitektur. pages 325. September 2008.[Gem08b] Gematik. Einführung der Gesundheitskarte - PKI für CV-Zertikate Grobkonzept. pages 34. June 2008.[Gem08c] Gematik. Einführung der Gesundheitskarte - PKI für die X.509-Zertikate, Grobkonzept. pages 28. June 2008.[Gem08d] Gematik. Fachkonzept - Daten für die Notfallversorgung (Notfalldaten). pages 76. August 2008.[IL009] Illegal organ trade. http://www.mahalo.com/stub/illegal-organ-trade, 2009. data called on 27.05.2010.[ILP06] Robert Istepanian, Swamy Laxminarayan, Constantinos Pattichis. M-health: emerging mobile health systems. ISBN 978-0-387-26558-2. In International Top- ics in Biomedical Engineering, pages 623. Springer US, New York. 2006. http://www.springerlink.com/content/978-0-387-26558-2.[Kra94] Hugo Krawczyk. Secret sharing made short. Advances in Cryptology (CRYPTO). ISBN 0-387-57766-1. In Lecture Notes in Computer Science, volume 773, pages 136-146. Springer US, New York. 1994. http://www.cs.cornell.edu/courses/cs754/2001fa/secretshort.pdf.[LHM09] Roger Lee, Gongzu Hu, Huaikou Miao. Computer and Information Sci- ence. ISBN 978-3-642-01208-2. In Studies in Computational Intelligence, vol- ume 208, pages 304. Springer Berlin Heidelberg, Berlin/Heidelberg. May 2009. http://www.springerlink.com/content/j014155j5547/?v=editorial.[PRS07] Norbert Pohlmann, Helmut Reimer, Wolfgang Schneider. ISSE/SECURE 2007: Se- curing Electronic Business Processes: Highlights of the Information Security Solutions Europe / SECURE 2007 Conference. ISBN 978-3-834-80346-7. 1st edition, pages 444. Vieweg+Teubner, Wiesbaden. September 2007.[Sch06] Thomas Schneider. Verteilte Geheimnisse und Informationen. pages 44. August 2006. http://thomaschneider.de/talks/Verteilte_Geheimnisse_und_Informationen/handout.pdf.[Sch09] Klaus Schmeh. Elektronische Ausweisdokumente: Grundlagen und Praxisbeispiele. ISBN 978-3-446-41918-6. volume 14, pages 282. Carl Hanser Fachbuchverlag, München. Au- gust 2009. http://www.onleihe.de/static/content/carlhanser/20090804/978-3-446-42108- 0/v978-3-446-42108-0.pdf 20
  21. 21. [Sha79] Adi Shamir. How to share a secret. ISSN 0001-0782. In Communi- cations of the ACM, volume 22, pages 612-613. ACM, New York. 1979. http://crypto.csail.mit.edu/classes/6.857/papers/secret-shamir.pdf.[SOZ09] Sozialgesetzbuch Fünftes Buch (V). 2009. Ÿ 291 - http://www.sozialgesetzbuch- sgb.de/sgbv/291.html and Ÿ 291b - http://www.sozialgesetzbuch-sgb.de/sgbv/291b.html.[URL10a] Eruption of Eyjafjallajökull Volcano, Iceland. http://earthobservatory.nasa.gov/ IOTD/view.php?id=43252, 2010. data called on 28.05.2010.[URL10b] Noch Monate Asche-Chaos? http://www.bild.de/BILD/news/2010/04/19/ asche-chaos/noch-monate-chaos-nach-vulkan-ausbruch-in-island.html, 2010. data called on 28.05.2010.[URL10c] Vulkanasche-Chaos. http://www.berlinonline.de/berliner-zeitung/archiv/.bin/ dump.fcgi/2010/0419/tagesthema/0053/index.html, 2010. data called on 28.05.2010.[WIKa] Secret sharing. http://en.wikipedia.org/wiki/Secret_sharing. data called on 10.06.2010.[WIKb] Secret sharing. http://de.wikipedia.org/wiki/Secret_Sharing. data called on 10.06.2010.[WIKc] Shamirs secret sharing. http://de.wikipedia.org/wiki/Shamirs_Secret_Sharing. data called on 10.06.2010.A Appendix AThe following list was worked out by BAND (Bundesvereinigung der Arbeitsgemeinschaften der NotärzteDeutschlands), the DIVI (Deutschen interdisziplinären Vereinigung für Intensiv und Notfallmedizin),the DGAI (Deutschen Gesellschaft für Anästhesiologie und Intensivmedizin) and the BÄK (NKS)(Ausschuss Notfall-, Katastrophenmedizin und Sanitätswesen). It covers the current status and can beupdated anytime if necessary. The terms within this list should be used without any changes. [Gem08d] 1. relevant diagnoses, operations, procedures in case of emergency · Bronchial asthma · COPD (chronic obstructive pulmonary disease) · Coronary heart disease · Cardiac insuciency · Cardiac arrhythmia · Cardiac pacemaker · Internal Debrillator · Cerebral cramps · Neuropathy · Inborn coagulation disorder · acquired coagulation disorders · Medicinal induced coagulation disorders · Diabetes mellitus · Addisons syndrome · Glaucoma 21
  22. 22. · Glass eye · Contact lens · Obligatory dialysis renal insuciency · Chronic liver insuciency · Relevant infectious disease · Organ transplantation · Abdominal aortic aneurysm · further particulars 2. relevant medications in case of emergency · Beta-Blocker · ACE-Hemmer · Diuretic · Calcium-Antagonist · Nitro-preparation · Anti-arrhythmic drug · Digitalis · Beta mimetic · Cortisone · Immunosuppressant drug · Aldosterone antagonist · Anticonvulsant · Antidepressant drug · Antipsychotic · Platelet aggregation inhibitor · Phenprocoumonum, e.g. Marcumar R · Heparin · Factor VIII / IX · Desmopressin, e.g. Minirin R · Insulin · Cholinesterase · Opiate · NSAR · further particularsB Appendix BAn example of declaration for organs spending is shown in Figure 16 [Gem08d] below.C Appendix CIn Figure 17 are shown the basic notations in Aris, used for the creation of the process models. 22
  23. 23. Figure 16: Standard form for organ donation [Gem08d] Figure 17: Aris legend 23

×