Sicherheitsinfrastruktur im Gesundheitswesen

Transkript

1 Sicherheitsinfrastruktur im Gesundheitswesen

2 Gliederung: 1. Ziele und Anforderungen 2. Standardisierung 3. Situation in Deutschland 4. Aufbau der EGK

3 Ziele und Anforderungen Ziel ist, eine Infrastruktur zu schaffen, um Informationen zwischen IT-Systemen auszutauschen und zu nutzen. Es müssen m Infrastrukturkonzepte für f r Möglichkeiten M wie Telematik,, Telemedizin und Shared Care,, die durch die IT- Systeme entstandenen sind, entwickelt werden.

4 Begriffsklärung: rung: Telematik: Gebildet aus Telekommunikation und Informatik. Datenbestände nde werden auf entfernten Rechnersystemen über eine Datenfernverbindung vernetzt. Telemedizin Diagnostik und Therapie unter Überbrückung einer räumlichen oder auch zeitlichen Distanz.

5 Begriffsklärung: rung: Shared Care: fortlaufenden und koordinierenden Tätigkeiten T verschiedener Personen, in verschiedenen Institutionen, unter Einsatz verschiedener Methoden, zu verschiedenen Zeiten. ehealth: Anwendungen der Telemedizin, die sich auf die Internet- Infrastruktur oder Internet -Technik stützen tzen.

6 Anforderungen: Als Basis für f r alle Dienste: sichere Authentifizierung und Verbindlichkeit durch die digitale Signatur. Alle Zugriffsberechtigten auf Daten authentifizieren sich mit ihrer Karte (EGK oder HBA) und signieren elektronisch alle neu erfassten Daten.

7 Anforderungen: Die Karten erlauben einen klar definierten, rollenabhängigen ngigen Zugang zu den Anwendungen und Zugriff auf die Daten. Die Sicherheit lässt l sich durch kryptographische Algorithmen garantieren (geheimen Schlüssel und Zertifikate )

8 Bisher verfügbare Anwendungen können k diese Anforderungen nur zum Teil erfüllen. Daraus entsteht die Notwendigkeit neue Konzepte zu erarbeiten und in die Infrastruktur des Gesundheitswesen zu integrieren. Die Rahmenbedingungen für f r solche Konzepte wurden durch die EU-Direktive zur Elektronischen Signatur sowie die Europäische Initiative zur Standardisierung der digitalen Signatur unter anderem auch für f r Deutschland festgeschrieben.

9 Standardisierung Gremien: deutsches (DIN), europäisches (CEN), internationalen (ISO) Gremien

10 Für r die EGK in Deutschland gilt, dass für f r die Nutzung ihrer Funktionen: die Nutzer zweifelsfrei identifiziert werden müssenm die Daten vertraulich bleiben und vor unbefugter Änderung geschützt sein müssen, m auch während w der Übermittlung der Zugriff auf und die Interpretation der Daten europaweit harmonisiert werden muss

11 Standardisierungsaktivitäten: ten: die Speicherung und die Struktur der Versichertendaten EU-Behandlungsschein E111 Notfalldatensatz.

12 Chancen zur Harmonisierung haben auf europäischer Ebene das elektronische Rezept und die Arzneimitteldokumentation. Zuzahlungsstatus, Kostenquittung, elektronischer Arztbrief, elektronische Patientenakte und auch persönliche Patienteneintragungen sind aber noch immer sehr stark von nationalen Prozessen und Prozeduren geprägt. gt.

13 Situation in Deutschland Rechtliche Grundlagen: in 291ff, SGB V ist u.a.. definiert Gestaltungsvorgaben an die EGK (Lichtbild, Unterschrift,..) Inhalte der EGK Pflichtinhalt nach Freiwilliger Inhalt

14 Rechtliche Grundlagen: Zugriffsberechtigungen auf den verpflichtenden Teil: Ärzte, Zahnärzte, Apotheker, sonstiges pharmazeutisches Personal, sonstige Leistungserbringer auf den freiwilligen Teil: Ärzte, Zahnärzte, Apotheker, bei der Notfallinformation: Notfallpersonal

15 Rechtliche Grundlagen: Zugriffsarten Freier Zugriff Kein Zugriff Autorisierung durch Versicherten (Freigeben der Daten durch PIN-Eingabe Eingabe) Ermächtigter Zugriff (Personen ohne HBA werden von entsprechenden HBA Besitzern ermächtigt, bestimmte Daten zu lesen)

16 Rechtliche Grundlagen: Rechte des Karteninhabers z.b.: Der Versicherte hat das Recht auf alle Daten zuzugreifen ( 291a,( Abs. (4), Satz 2). (rein lesender Zugriff)

17 Zugriffsberechtigungen kurz zusammengefasst:

18 Aufbau der EGK

19 Elementary Files(EF) ) auf MasterFile(MF)-Ebene für r einige allgemeine Datenobjekte, globale Schlüssel und Card Verifiable(CV)-Zertifikate Die Gesundheitsanwendung (health( care application,, HCA) mit den Versichertendaten Die ESIGN-Anwendung mit Unterstützung tzung von X.509 PKI-Funktionen (Chiffrierung von Schlüsseln, Client/Server-Authentisierung und elektronischer Signaturfunktion) - die kryptografische Informationsanwendung (CIA.ESIGN)

20 Elementary Files auf MF-Ebene: EF.ARR: (lineare Struktur mit Records variabler Größ öße) für f Speicherung von Zugriffsregeln. Karten, die kein EF.ARR enthalten, müssen m EF.ARR-Funktionalit Funktionalität unterstützen. tzen. EF.DIR: Enthält die Anwendungs-Schablonen für r die in der EGK vorhandenen Anwendungen.

21 EF.GDO: Enthält das Datenobjekt ICCSN (Integrated Circuit Card Serial Number) ) = EGK-Serien Serien-Nummer.

22 EF.GDO: Die Seriennummer (SN) in BCD kodiert. Das höherwertige h herwertige Halb-Byte der Prüfziffer (CheckDigit( Byte, CDB) wird nach der Luhn-Formel berechnet. Die Kenn-Nummer des Kartenherausgebers (issuer identification number,, IIN), auf deutsch Kartenausgeberschlüssel, ssel, hat weltweit eindeutige Kennung.

23 EF.GDO: In dieser Spezifikation werden die folgenden Elemente der ICCSN verwendet: SN (8 Bytes) in Authentisierungsprozessen Country Code Issuer Identifier SN (insgesamt 12 Bytes) in CV-Zertifikaten, verwendet als weltweit eindeutige Kennung des Kartenschlüssels ssels (PuK.eHC.AUT( PuK.eHC.AUT).

24 EF.C.EGK.AUT: Enthält das CV-Zertifikat der EGK. Dieses Zertifikat wird in Card-to to-card- Authentisierungsverfahren verwendet EF.C.CA_EGK.CS: Ist für f r die Aufnahme des Root-CV CV-Zertifikats vorgesehen. Es wird bei 2-stufigen 2 C2C-Authentisierungsverfahren (Card-to-Card)) benötigt.

25 EF.PIN: Enthält die globale PIN des Karteninhabers (PIN.CH). Die PIN wird in DF.HCA und auch in DF.ESIGN verwendet. Die PIN besteht aus 6 Ziffern (Mindestlänge nge ist änderbar). Der Fehlbedienungszähler hler muss den Anfangswert 3 besitzen. Anmerkung: Ein Resetting Code falls im Verfahren der betreffenden Krankenversicherung vorgesehen, besteht aus 8 Ziffern und muss mit der PIN.CH verknüpft sein.

26 EF.PrK: Für r C2C-Authentisierungsverfahren privater Schlüssel benötigt (ein globaler Schlüssel) PrK.EGK.AUT für r die gegenseitige Authentisierung von EGK/HBA bei lokalen Interaktionen ein Authentisierungsprotokoll ohne Vereinbarung von Sitzungsschlüsseln. sseln. für remote Interaktionenen ein Authentisierungsprotokoll mit Vereinbarung von Sitzungsschlüsseln. sseln.

27 EF.PrK: Als Public-Key Key-Algorithmus wird RSA verwendet (nach Rivest, Shamir, Adleman: Eine spezielle Methode für f r digitale Unterschriften und öffentliche Schlüssel)

28 EF.PuK: Prüfschl fschlüssel ssel zur Prüfung von CV-Zertifikaten der HBA. Public Keys bei der EGK-Initialisierung Initialisierung/Personalisierung in der EGK: PuK.RCA.CS (Public Key der Root- Zertifizierungsinstanz ) PuK.CA_EGK_NN.CS (Public Key der EGK ) PuK.CA_HBA.CS (Public Key der betreffenden HBA)

29 EF.PuK: Die Eintragung von PuK.CA_HBA.CS erlaubt die Abwicklung des zeitsparenden einstufigen CV-Pr Prüfverfahrens Die PuK-Referenz ist im jeweiligen CV-Zertifikat enthalten und muss beim Setzen des PuK für r die CV-Zertifikatspr Zertifikatsprüfung fung verwendet werden.

30 EF.SK: Für r Interaktion EGK/VSDD(Versichertenstammdaten VSDD(Versichertenstammdaten-DienstDienst ) und EGK/CMS (Card Management System) für f r das Nachladen von DES-3-Schl Schlüssel-Anwendungen bereitgestellt.

31 Gesundheitsanwendung HCA:

32 EF.ARR: Wird für f r die Speicherung von Zugriffsregeln verwendet. EF.Personal_Data (EF.PD): Enthält die Personendaten ( Stammdaten( Stammdaten ) EF. Health_Insurance_Data (EF.HID): Enthält Versichertendaten.

33 EF. Protected_HID (EF.PHID): Für r schutzbedürftige Versicherungsdaten Lesen der Daten ist möglich: m durch Heilberufler nach Authentisierung durch VSDD nach Authentisierung durch den Karteninhaber nach Präsentation der PIN.CH EF.Logging: EF.Protokollierung :: zyklisches Elementary File, enthält Protokollierungsinformation über die letzten 50 Einsätze der EGK durch Instanzen des Gesundheitswesens.

34 Struktur des Protokollierungsrecords:

35 ESIGN-Anwendung Anwendung:

36 Die ESIGN-Anwendung (DF.ESIGN) wurde entwickelt fürf elektronische Signatur Verschlüsselung sselung Client/Server-Authentisierung Sie verwendet separate asymmetrische Schlüsselpaare und X.509-Zertifikate.

37 Für r EGK gilt das folgende Konzept: OPTIONAL: Die elektronische Signaturfunktion (fortgeschrittene oder qualifizierte Signaturfunktion; Nachladen/Aktivieren nach EGK-Ausgabe Ausgabe) MANDATORY: Die Schlüssel ssel-chiffrierungsfunktion (Verwendung z.b. im Kontext elektronischer Rezepte) OPTIONAL: Die Client/Server-Authentisierung

38 EF.ARR: Dient dem Speichern von Zugriffsregeln. EF.PrK: Enthält die privaten RSA-Schl Schlüssel.. Zusätzliche Private Keys können vorhanden sein. EF.PIN: Für r Verwendung von PIN.SIG reserviert. PIN.SIG (6 Ziffern) ist änderbar. Auch ein Resetting Code zum Rücksetzen des Fehlbedienungszählers hlers kann verwendet werden.

39 EF.C.CH.KE: Dient der Speicherung des X.509-KE KE-Zertifikats des Karteninhabers. Eintragen eines Zertifikats nach Kartenausgabe erlaubt. EF.C.CH.AUT: Dient der Speicherung des X.509-AUT AUT-Zertifikats des Karteninhabers. EF.C.CH.ES: Ist für f r die Speicherung eines X.509-ES ES-Zertifikats reserviert.

40 Kryptografische Informationsanwendung:

41 Kryptografische Informationsanwendungen vorhanden, um Algorithmen, Dateikennungen etc. anzuzeigen, die für f entsprechende ESIGN-Anwendung relevant sind. In der EGK enthält das DF.CIA.ESIGN nur EF.CIAInfo,, das den Profile Identifier bereitstellt, welcher auf [DIN ] verweist. Mit diesem Profile Identifier wird mitgeteilt, dass alle Schlüssel ssel-ids etc. in [DIN ] definiert sind.

42 EF.ARR: Enthält die Zugriffsregeln für f EFs,, die DF.CIA.ESIGN zugehören. EF.CIAInfo: Enthält die CIA-Information, Information, insbesondere den Profile Identifier. Zusätzliche Funktionen können k ebenfalls in der CIA- Information angezeigt werden.

43 Literatur: rayserv.upb.de/fiff/themen/beh/egk/ /EGK/Brosh atg.gvg-zoeln.de/xpage/objects/infrastruktur/docs /8/files files/sicherh_sembritzki_0506.pdf

44 Vielen Dank für f r die Aufmerksamkeit!