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 theTelematics system. Their completion has to be executed completely secure with no risk of adata loss and preserving the privacy of the patient. In this paper we will take a look at theexisting/proposed scenario for back-up/recovery of emergency data and discuss the problems byits implementation. In order to improve this scenario and solve the problems we will put forwarda new scenario.

1

Contents

1 Introduction 5

2 Preliminaries 52.1 The Telematics infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Electronic Health Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Health Professional Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4 Hardware Security Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5 Emergency data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.6 Existing problems by donation of organs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Scenario Back-up/Recovery of emergency information 83.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2 Examination of the existing/ proposed solution . . . . . . . . . . . . . . . . . . . . . . . 83.3 Disadvantages of the solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4 Krawczyk's Secret Sharing Scheme 114.1 Secret Sharing Scheme (n,m) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2 Shamir's Secret Sharing Scheme (n,t) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.3 Information Dispersal Scheme (n,m) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.4 Krawczyk's Secret Sharing Scheme (n,m) . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5 Our proposal solution 145.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145.2 Back-up of emergency data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145.3 Recovery of emergency data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6 Conclusion 19

A Appendix A 21

B Appendix B 22

C Appendix C 22

2

List of Figures

1 Overview of the entire architecture [Gem08a] . . . . . . . . . . . . . . . . . . . . . . . . 62 Primary systems architecture [Gem08a] . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Scenario for back-up/recovery of emergency data . . . . . . . . . . . . . . . . . . . . . . 95 Period of renewing of the eHC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Recovery of the emergency data on the eHC . . . . . . . . . . . . . . . . . . . . . . . . . 117 Secret Sharing Scheme(n,m) [Sch06] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Curve over 5 points [Sch06] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Information Dispersal Scheme (n,m) [Sch06] . . . . . . . . . . . . . . . . . . . . . . . . . 1310 Krawczyk's Secret Sharing Scheme(n,m) [Sch06] . . . . . . . . . . . . . . . . . . . . . . . 1311 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1512 Our proposal solution one for back-up of emergency data . . . . . . . . . . . . . . . . . 1613 Our proposal solution two for back-up of emergency data . . . . . . . . . . . . . . . . . 1714 Our proposal solution one for recovery of emergency data . . . . . . . . . . . . . . . . . 1815 Our proposal solution two for recovery of emergency data . . . . . . . . . . . . . . . . . 1916 Standard form for organ donation [Gem08d] . . . . . . . . . . . . . . . . . . . . . . . . . 2317 Aris' legend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3

List of Abbreviations

DEC Decryption

e.g. for example

eHC electronic Health Card

ENC Encryption

ePrescription electronic Prescription

gematik Gesellschaft für Telematikanwendungen der Gesundheitskarte mbH

GMA German Medical Association

HIS Hospital Information Systems

HPC Health Professional Card

HSM Hardware Security Module

IDS Information Dispersal Scheme

PAS Practice Administration Systems

PhAS Pharmacy Administration Systems

PIN Personal Identi�cation Number

PTA Patient Transport Ambulance

SOA service-oriented architecture

SS Secret Sharing

VPN Virtual Private Network

4

1 Introduction

Preserving 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 di�erent groups of involvedpersons, as well as its usage for transfer and storage of signi�cant 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 Krawczyk's information dispersalscheme. It will pay attention to speci�c 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 Preliminaries

2.1 The Telematics infrastructure

Health 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 term'e-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 care

providers 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' speci�c data as well as toadministrate the rights or in some cases to delete data. [Gem08a]

2.2 Electronic Health Card

In 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

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 e�ciency, 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 di�erent 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

2.3 Health Professional Card

The 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 de�nedas ä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-ni�cance. 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 speci�c medical data online, where the HPC serves as an accesskey instead of password and login id.

2.4 Hardware Security Module

By de�nition 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 data

What are emergency data and what information is kept within? By de�nition this is informationabout the data in case of emergency, including the declaration (the completed and signed form) fororgans' spending. [Gem08b] There are di�erent 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 organs

Among the many problems tightly connected with the donation of organs, for the illegal trade of organsand the transportation di�culties by natural perils seems to have no wholly and permanent solution.

• Criminal/illegal trade of organsThe criminal/illegal trade of organs is the biggest existing problem by donation of organs. Thereare two di�erent basic types of illegal organ trade. By the �rst type because of indigent con-ditions people sell their own body organs for pro�t. By the second the organs are taken fromexecuted 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 theprocedure.-[IL009]

• Transportation di�culties by natural perilsTime plays very important role by transportation of organs for donation. If the speci�c organcannot be transported betimes to the matching person (patient), it becomes unusable. Sometimesbecause of natural perils such as earthquakes, �oods, �re or even eruption of volcanoes can inducedi�culties and impossibility to transport the organs to the speci�c location. As proof of thisstatement the following facts are mentioned below: on the 14th April 2010 by the eruption ofEyjafjallajökull [URL10a], located in Iceland, an enormous cloud of volcanic ash was released

7

in the atmosphere, causing mass �ight cancellations all over Europe, spanning from the UK toRussia over fears that the soot may be catastrophic to planes - such as causing engines to failin-�ight or severely reducing the pilot's visibility.

The ash clouds were drifting between six to nine thousand meters above the ground, and weremoving eastwards, over northern France and Austria and towards Russia at about 40 kilometersper hour.

Because of the embargo over �ights there were dramatic consequences for the transportation oforgans. Birgit Blome (50) from the German foundation for organ transplantation said : TTheorgans -heart, lungs and liver, which are usually transported via �ight, are now found locally andtransported by car.-[URL10b] The director of the foundation for transplantation EurotransplantAxel Rahmel also said:Ït is already a challenge, when the transportation is possible only viaambulances or PTA (Patient Transport Ambulance)-[URL10c]

3 Scenario Back-up/Recovery of emergency information

3.1 Overview

Before 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 di�erent 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 solution

The 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 o�ine. 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

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

3.3 Disadvantages of the solution

After 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 expiryIn case of emergency the patient has to have the document, printed by his doctor (shown inFigure 5). There is no other option for the medical person to �ind outtthe data, concerning theindividual health characteristics of the patient, because the process is executed o�ine. On �rstplace the creation of this document is not obligatory. Second, it is only a sheet of paper, whichcan be lost, stolen or destroyed (e.g. during natural perils, �re). Moreover it exposes privatedata.

• Recovery of the emergency data on the eHCThe back-up made in the primary system of the doctor is only temporary. This means that if theback-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 thedata, so it is irreversibly lost.The whole process is shown in Figure 6.

10

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 o�ine and is completely unsecure. For this reason we will propose another solution in thefollowing chapter 5, which will solve these problems.

4 Krawczyk's Secret Sharing Scheme

In this section we will take a look at the Krawczyk's 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 speci�cscheme we shall clarify what is secret sharing and what are its properties.

11

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 Blackleyindependently of each other in 1979. It is a method for distribution of a secret S among a groupof n-participants. The reconstruction of S is possible only when a su�cient number of shares (inthis case ≥m) are combined together, which means that m-1-shares provide no information aboutS. [Sch06] [Bla79] [WIKa] [WIKb]

4.2 Shamir's Secret Sharing Scheme (n,t)

Figure 8: Curve over 5 points [Sch06]

Shamir's Secret Sharing Scheme is based on polynomial interpolation (Figure 8 [Sch06]). Theprocess of distribution proceeds as it follows:

1. pick t points to de�ne a polynomial of degree t-1

2. create a polynomial of degree t-1 with the secret S as the �rst coe�cient (k0) and the remainingcoe�cients (kt−1,...,k1) picked at random

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:

1. at least t out of the n players reveal their points, there is su�cient information to �t an (t-1)-thdegree polynomial to them

2. the �rst coe�cient of the polynomial is the secret S

12

The Shamir's Secret Sharing Scheme is information-theoretically secure (also unconditionalsecure), meaning that an attacker cannot extract any information about the secret S (from less thanm shares), whatever how much computational time he invests. Additionally, the size of each sharehas to be equal (or ≥) to the size of the secret S, which makes the Shamir's Secret Sharing Schemestorage e�cient. [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 among a group of n-participants. The reconstruction is possible when su�cient number of fragments(≥m) is combined together. By this speci�c method the secrecy is not important, so it is possible togain information about F from less than m fragments. Every fragment has a length of |F |m . [Sch06]

4.4 Krawczyk's Secret Sharing Scheme (n,m)

Figure 10: Krawczyk's Secret Sharing Scheme(n,m) [Sch06]

Krawczyk's 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

1. randomly pick a symmetric keyK and encrypt symmetrically the secret S, building E= ENCk(S)

2. partition E in n fragments (ei), using an IDS

3. disperse K in n shares (ki), using a SS

4. send to every participant (in this case n) a share si = (ei,ki) [Sch06]

The process of reconstruction proceeds as it follows:

1. at least m out of the n players reveal their shares si = (ei,ki), i ε 1...m

2. reconstruct E from ei, using the IDS

3. reconstruct K from ki, using the SS

4. decrypt E: S=DECk(E) [Sch06]

The Krawczyk's Secret Sharing Scheme (n,m) is not information-theoretically secure, because by su�-cient computational time an attacker can �nd out the key K, decrypt some shares, which are commonto him, and extract some information about the secret S. Additionally, the size of each share is |si|=|S|m + |K| <|S|. [Sch06]The Krawczyk's Secret Sharing Scheme (n,m) needs less storage and also bandwidth in comparisonto Shamir's SS. It is computationally secure, which means that practically from m-1 shares anattacker cannot extract any information about the secret S. [Sch06] [Kra94]

5 Our proposal solution

5.1 Overview

Before 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 speci�c 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 data

The process for back-up of emergency data is executed in four phases:

1. Phase of authenticationFor authentication can be used many di�erent well-known methods. The patient and doctor (orparamedic) can authenticate themselves via e.g. PIN, ID-patient/ ID-doctor, ID-eHC/ID-HPC,Fingerprints, di�erent types of digital signatures, etc.

14

Figure 11: Overview

2. Complete the form for emergency data and/ or form for organs' donationIn this phase all necessary information, such as relevant diagnoses, operations, procedures orrelevant medications in case of emergency is �lled out. As already mentioned in section 2.5, thedeclaration for organs' spending can be also completed or left blank.

3. Con�rmation of the data, e.g. via �ngerprint or PIN by the patient and doctorIn any case of changing the emergency data (e.g. creation or update), the new copy has to beveri�ed. So the emergency data has be read by the patient and then con�rmed by both patientand doctor via �ngerprint (assuming that the chip card terminal has a touch screen) or PIN.

4. Back-upIn 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 it's optional) are executed o�ine, we suggestan obligatory back-up, executed o�ine and online.

Our proposal solution one for back-up of emergency data

(a) using Krawczyk's SS - executed online via e.g. VPNIn this case using Krawczyk's SS, we can secure a back-up of emergency data on threedi�erent 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 o�ineAs an extra back-up, a copy of emergency data is saved in the primary system databaseand 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, comparedto the gematik' solution are:

(a) The creation of back-up is obligatory

15

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 theparamedic can obtain emergency data online (via e.g. VPN) - from the three servers. Evenif one of the servers is not accessible, the information S can be reconstructed. Otherwisethe necessary data can be gained from the USB stick o�ine.

(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 Krawczyk's SS to disperse the information:

(a) online (via e.g. VPN) - securing a back-up of emergency data on three di�erent servers;

(b) 2. o�ine - securing a back-up of emergency data on a portable device (e.g. USB-Stick) andin 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

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 thatthe 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 thefragments on the other two servers and on the USB stick.

5.3 Recovery of emergency data

The process for recovery of emergency data is executed in two phases:

1. Phase of authenticationFor authentication can be used many di�erent well-known methods. The patient and doctor (orparamedic) can authenticate themselves via e.g. PIN, ID-patient/ ID-doctor, ID-eHC/ID-HPC,Fingerprints, di�erent types of digital signatures, etc.

17

2. RecoveryFor the process of recovery of emergency data, we will present two proposal solutions as we didfor 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 Krawczyk's SS - executed online via e.g. VPNUsing Krawczyk's SS, we can reconstruct emergency data from the three di�erent servers;more exactly we 'gather' the fragments of the information S (emergency data) from eachone of them.

(b) using a portable device (e.g. USB-Stick) - executed o�ineThe other option to recover a copy of emergency data is from the primary system databaseor 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 theparamedic can obtain emergency data online (via e.g. VPN) - from the three servers. Evenif one of the servers is not accessible, the information S can be reconstructed. Otherwise thenecessary data can be gained from the USB stick o�ine, minimizing the risk of exposing privatedata. In case of renewing the eHC (lost, stolen or defect), the recovery is possible online fromthe three servers, as well as o�ine from the primary system database or the portable device (e.g.USB stick), given to the patient.

18

Our proposal solution two for recovery of emergency data By this solution (Figure 15)we use Krawczyk's SS to reconstruct the information:

(a) online (via e.g. VPN) - reconstructing emergency data from the three servers;

(b) o�ine - reconstructing emergency data from the portable device (e.g. USB-Stick) and/ orthe 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 theparamedic can obtain emergency data online (via e.g. VPN) - from the three servers. Even ifone of the servers is not accessible, the information S can be reconstructed from the fragmentson the other two servers and on the USB stick, because we need minimum 3 sources containingfragments of S. In case of renewing the eHC (lost, stolen or defect), the recovery is possible usingthe online sources (three servers), combining them with the o�ine ones (the primary systemdatabase or the portable device (e.g. USB stick), given to the patient), if one or two of theservers are not accessible.

6 Conclusion

The 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. That's why, afterwe've analyzed these problems, we have tried to eliminate them, by working out a better solution for

19

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 NationalComputer Conference, volume 48, pages 313-317. AFIPS Press, Monval, NJ, USA. 1979.

[Gem08a] Gematik. Einführung der Gesundheitskarte - Gesamtarchitektur. pages 325. September2008.

[Gem08b] Gematik. Einführung der Gesundheitskarte - PKI für CV-Zerti�kate Grobkonzept. pages 34.June 2008.

[Gem08c] Gematik. Einführung der Gesundheitskarte - PKI für die X.509-Zerti�kate, Grobkonzept.pages 28. June 2008.

[Gem08d] Gematik. Fachkonzept - Daten für die Notfallversorgung (Notfalldaten). pages 76. August2008.

[IL009] Illegal organ trade. http://www.mahalo.com/stub/illegal-organ-trade, 2009. datacalled 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). ISBN0-387-57766-1. In Lecture Notes in Computer Science, volume 773, pages 136-146. SpringerUS, 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 SolutionsEurope / 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. ISBN978-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

[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 on10.06.2010.

[WIKb] Secret sharing. http://de.wikipedia.org/wiki/Secret_Sharing. data called on10.06.2010.

[WIKc] Shamirs secret sharing. http://de.wikipedia.org/wiki/Shamirs_Secret_Sharing. datacalled on 10.06.2010.

A Appendix A

The 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 insu�ciency· Cardiac arrhythmia· Cardiac pacemaker· Internal De�brillator· Cerebral cramps· Neuropathy· Inborn coagulation disorder· acquired coagulation disorders· Medicinal induced coagulation disorders· Diabetes mellitus· Addison's syndrome· Glaucoma

21

· Glass eye· Contact lens· Obligatory dialysis renal insu�ciency· Chronic liver insu�ciency· 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 particulars

B Appendix B

An example of declaration for organs' spending is shown in Figure 16 [Gem08d] below.

C Appendix C

In Figure 17 are shown the basic notations in Aris, used for the creation of the process models.

22

Figure 16: Standard form for organ donation [Gem08d]

Figure 17: Aris' legend

23