Einführung der Gesundheitskarte Verwendung von Zertifikaten in der Telematikinfrastruktur

Größe: px
Ab Seite anzeigen:

Download "Einführung der Gesundheitskarte Verwendung von Zertifikaten in der Telematikinfrastruktur"

Transkript

1 Einführung der Gesundheitskarte Verwendung von Zertifikaten in der Telematikinfrastruktur Version: Revison: main/rel_main/21 Stand: Status: freigegeben gematik_pki_verwendung_zertifikate_der_ti.doc Seite 1 von 102

2 Dokumentinformationen Änderungen zur Vorversion Anpassung des Speicherorts für den Zertifikatstyp von AdditionalInformation nach CertificatePolicies. Anpassung des Use Case zur Ermittlung des Zertifikatstyps. Die Zertifikatsprüfung wird um das Eingangsdatum Referenzzeitpunkt erweitert. Aufnahme der QES-Prüfung in Kap. 12. Anpassung der SSL-Prüfung in Kap. 11. Inhaltliche Änderungen gegenüber der letzten freigegebenen Version sind gelb markiert. Sofern ganze Kapitel eingefügt oder umfassend geändert wurden, wurde zur besseren Lesbarkeit lediglich die Überschrift durch gelbe Markierung hervorgehoben. Referenzierung Die Referenzierung in weiteren Dokumenten der gematik erfolgt unter: [gemverw_zert_ti] gematik: Einführung der Gesundheitskarte - Verwendung von Zertifikaten in der Telematikinfrastruktur Dokumentenhistorie Version Stand Kap./ Seite Grund der Änderung, besondere Hinweise Bearbeitung Neuerstellung gematik AG Bearbeitung gematik AG Neue Diagramme, Überarbeitung gematik AG Validierungspfad, Rollenermittlung gematik AG Überarbeitung gematik AG Neue TUC und Überarbeitung gematik AG Erweiterung TUC gematik AG Präzisierung der TUCs gematik AG ,8 der TUCs gematik AG TUC-Erweiterungen SPE/ZD Einarbeitung Kommentare Komplette Überarbeitung mehrer Kapitel SPE/ZD gematik_pki_verwendung_zertifikate_der_ti.doc Seite 2 von 102

3 Version Stand Kap./ Seite Grund der Änderung, besondere Hinweise Bearbeitung Einarbeitung Kommentare (nach weiterer IQS) SPE/ZD freigegeben gematik ,9 Überarbeitung SPE/ZD Einarbeitung Kommentare SPE/ZD freigegeben gematik , 12 QES-Prüfung, Einführung Referenzzeitpunkt SPE/ZD Einarbeitung Kommentare SPE/ZD freigegeben gematik gematik_pki_verwendung_zertifikate_der_ti.doc Seite 3 von 102

4 Inhaltsverzeichnis Dokumentinformationen...2 Inhaltsverzeichnis Zusammenfassung Einführung Zielsetzung und Struktur des Dokumentes Zielgruppe Geltungsbereich Arbeitsgrundlagen Abgrenzung des Dokumentes Methodik Verwendung von Schüsselworten Hinweis auf offene Punkte Technische Use Cases (TUC) Anforderungen Gesamtüberblick der verwendeten Zertifikate Standardvorgaben für Zertifikate Angaben zum Zertifikatstyp in der Extension CertificatePolicies Admission Einordnung der Zertifikate innerhalb der Gesamtarchitektur Einteilung der Zertifikate Vertrauensraum Prozesse zur Nutzung des Vertrauensraums Initialisierung im Offline-Fall Initialisierung ohne Vorbedingungen Referenzierbare Use Cases Erreichbarkeit der TSL TUC_PKI_001 "Initialisierung Vertrauensraum" TUC_PKI_019 "Prüfung der Aktualität der TSL"...27 gematik_pki_verwendung_zertifikate_der_ti.doc Seite 4 von 102

5 8.8 TUC_PKI_020 "XML Dokument validieren" TUC_PKI_011 "Prüfung der Integrität des Signaturschlüssels" TUC_PKI_012 "XML Signatur Prüfung" TUC_PKI_013 "Bereitstellen neuer Vertrauensanker" TSL-Einträge für die Bereitstellung neuer Vertrauensanker TUC_PKI_016 "Download der TSL" TUC_PKI_017 "Lokalisierung Download-Adressen" Zertifikatsprüfung Prüfung im Offline-Fall Referenzierbare Use Cases TUC_PKI_018 "Zertifikatsprüfung" TUC_PKI_002 "Gültigkeitsprüfung des Zertifikats" TUC_PKI_003 "CA Zertifikat in TSL finden" TUC_PKI_004 "Mathematische Prüfung der Zertifikatssignatur" TUC_PKI_005 "OCSP Adresse ermitteln" TUC_PKI_006 "OCSP-Abfrage" TUC_PKI_021 "CRL-Check" TUC_PKI_009 "Rollenermittlung" Weitere Prüfungen Umgang mit kritischen Extensions Bestätigte Zertifikatsinformationen TUC_PKI_007 "Unterscheidung von Zertifikatstypen" TUC_PKI_010 "Abgleich ob Zertifikatsherausgeber berechtigt ist" TSL Extension Spezifikation der Extension OIDs für die Dienste für TSL Überprüfung der Zertifikate auf Transportebene Generelle Vorgaben der Gesamtarchitektur zu SSL SSL-Verbindungsaufbau Definition der Error Condition für TLS Festlegungen der gematik QES-Zertifikatsprüfung TUC_PKI_030 "QES-Zertifikatsprüfung" TUC_PKI_031 "QES-Zertifikatspfad bilden und prüfen" TUC_PKI_032 "QES-Zertifikatspfad validieren"...81 gematik_pki_verwendung_zertifikate_der_ti.doc Seite 5 von 102

6 12.4 TUC_PKI_033 "QES-Sperrstatus prüfen" TUC_PKI_034 "QES-Sperrstatus über OCSP" TUC_PKI_035 "QES-Sperrstatus über CRL" Vorgaben zur Fehlerbehandlung...96 Anhang...97 A1 - Abkürzungen...97 A2 - Glossar...97 A3 - Abbildungsverzeichnis...98 A4 - Tabellenverzeichnis...98 A5 - Referenzierte Dokumente...99 A6 Klärungsbedarf / Offene Punkte gematik_pki_verwendung_zertifikate_der_ti.doc Seite 6 von 102

7 1 Zusammenfassung Das Dokument Verwendung von Zertifikaten in der Telematikinfrastruktur legt normativ fest, wie die Prüfung und Auswertung der X.509-Zertifikate in der Telematikinfrastruktur erfolgen muss. Hierzu beschreibt dieses Dokument im Sinne einer Zusammenfassung die unterschiedlichen Typen von Zertifikaten und deren Herausgabe und Nutzung in der Telematikinfrastruktur. Zur Identifikation von Personen, Objekten, Organisationen, Geräten, Rechten und Rollen werden elektronische Zertifikate verwendet, bei denen die Identität durch eine übergeordnete vertrauenswürdige Instanz mittels einer elektronischen Signatur bestätigt wird. In der Telematikinfrastruktur werden diese Zertifikate genutzt um dann die jeweilige Rolle bzw. Identität zu bestätigen. Ein zentrales hierarchisches Root-Modell ist v. a. aufgrund der Heterogenität und Komplexität der beteiligten Zertifikate und der Vielfalt der beteiligten Organisationen nicht praktikabel umsetzbar. Daher wird für die übergeordneten X.509-Zertifikate der ausstellenden Organisationen, der sog. Trust Service Provider (TSP), das Konzept der zentralisierten (Online-) Zertifikatsprüfung umgesetzt. Hierbei werden die Zertifikatsprüfinformationen der TSPs zentral erfasst und in einer Trust-service Status List (TSL) zusammengesetzt [ETSI], welche wiederum von der gematik bzw. einem beauftragten Dienstleister (gematik TSL-Service-Provider) signiert wird. Die gematik verwendet für die Telematikinfrastruktur zwei dieser Listen, eine für Personen und Organisationen und eine für Infrastruktur-Komponenten. Damit stellt die jeweilige TSL den gemeinsamen Vertrauensraum im Sinne einer White-List dar. Im weiteren Verlauf wird nur von der TSL gesprochen. Damit sind aber beide Listen gemeint. Neben den X.509-Zertifikaten werden innerhalb der Telematikinfrastruktur auch CV- Zertifikate eingesetzt. Diese dienen der C2C-Authentisierung von Chipkarten, hier insbesondere der egk und HBA (bzw. SMC). Bei Anwendung der CV-Zertifikate erfolgt zwischen egk und HBA (bzw. SMC) die vorgeschriebene gegenseitige Authentifikation. Die wichtigsten Aspekte zum Einsatz dieses Zertifikatstyps werden in diesem Dokument zusammenfassend beschrieben. Für die Auswertung der Zertifikate sind normative Festlegungen bzgl. Prüfung des Vertrauensraums (kommt das Zertifikat aus einer vertrauenswürdigen Quelle?) und des Zertifikatsstatus (ist es gültig oder gesperrt?) essentiell. Die Prüfaufgaben lassen sich wie folgt formulieren: Ist diesem Zertifikat zu vertrauen? Welche Rolle bestätigt dieses Zertifikat? Welche Identität bestätigt dieses Zertifikat? Dafür ist zum Einen sicherzustellen, dass die prüfende Komponente über eine lokal vorliegende und auf Gültigkeit geprüfte TSL verfügt, zum anderen muss die im Dokument detailliert beschriebene Validierungskette komplett durchlaufen werden, um die aktuelle Gültigkeit des Zertifikats bewerten zu können. Die einzelnen Prüfschritte werden im Dokument in Form von "Technischen Use Cases" dargestellt. gematik_pki_verwendung_zertifikate_der_ti.doc Seite 7 von 102

8 Aus den Personen- bzw. Organisationszertifikaten muss die Rolle des Datenbearbeiters ermittelt werden können. Für die Rollenermittlung werden verbindliche Vorgaben getroffen und Algorithmen beschrieben. Da ein Großteil der Komponentenzertifikate zum Aufbau von SSL-Verbindungen eingesetzt wird, macht das Dokument Vorgaben zum Verhalten und der Zertifikatsprüfung beim Aufbau dieser SSL/TLS-Verbindungen. Abschließend werden konkrete Vorgaben zur generellen Behandlung von Fehlerfällen bei der Überprüfung des Vertrauensraums und dem Abarbeiten der Validierungskette getroffen. gematik_pki_verwendung_zertifikate_der_ti.doc Seite 8 von 102

9 2 Einführung 2.1 Zielsetzung und Struktur des Dokumentes Das Dokument Verwendung von Zertifikaten in der Telematikinfrastruktur beschreibt einerseits die unterschiedliche Nutzung von Zertifikaten in der Telematikinfrastruktur und stellt andererseits normative Vorgaben zur Prüfung dieser auf. Ziel ist die Vorgabe der Verfahren und Rahmenbedingungen für die Spezifikation zur Prüfung von Zertifikaten der einzelnen Komponenten und Dienste der Telematikinfrastruktur. Die Kapitel 4 bis 7 bieten eine Hilfestellung zum Verständnis des Einsatzes der diversen Zertifikate im Rahmen der Einführung der egk. Dabei wird eine überblicksartige Zusammenfassung der Informationen zu den eingesetzten Zertifikaten und deren Nutzung aus den genannten Architektur- und Spezifikationsdokumenten gesammelt und in einem Dokument wiedergegeben. Das Kapitel 8 setzt normative Vorgaben zur Ermittlung des Vertrauensraums. Hierbei werden Vorgaben zur Überprüfung der TSL festgelegt und detailliert in Form von Text und UML-Diagrammen beschrieben. Bestandteil des Kapitel 9 ist die Zertifikatsprüfung. Beginnend mit einem groben Ü- berblick des Validierungsprozesses werden nachfolgend die jeweiligen Teilprüfungen im Detail spezifiziert. Hierbei liegt der Fokus auf der Gültigkeit der Zertifikate gemäß den zugrunde liegenden internationalen Standards. In Ergänzung dazu werden im Kapitel 10 die normativen Vorgaben zur Prüfung der fachspezifischen Inhalte eines Zertifikats beschrieben. Grundlage ist die Ermittlung der Rolle des Handelnden aus einem Zertifikat. Das Kapitel 11 beschreibt die Überprüfung der Zertifikate auf Transportebene. Vorgaben zum Verhalten beim SSL Verbindungsaufbau finden sich hier wieder. Das Kapitel 12 beschreibt die QES-Prüfung. Abschließend werden in Kapitel 13 Vorgaben zur Fehlerbehandlung gemacht. In den Kapiteln 8-11 werden Fehlercodes aus diesem Kapitel referenziert. 2.2 Zielgruppe Das Dokument richtet sich an Mitarbeiter der gematik, die mit folgenden Aufgaben betraut sind: Erstellung von Spezifikationen und Architekturen Definition von Betriebsabläufen Definition und Durchführung von Testprozessen Entwicklung von Prototypen der Telematikinfrastruktur. gematik_pki_verwendung_zertifikate_der_ti.doc Seite 9 von 102

10 Es soll dabei das für deren Aufgaben notwendige Verständnis für den Einsatz und die Bewertung von Zertifikaten vermitteln und setzt normative Vorgaben. Des Weiteren richtet sich das Dokument an die externen Beteiligten zur Einführung der Gesundheitskarte, insbesondere diejenigen, die Komponenten der Telematikinfrastruktur entwerfen, erstellen oder testen, die Zertifikate prüfen oder aus ihnen Informationen ermitteln müssen. Für alle hier genannten Gruppen sind die Vorgaben aus Kapitel 8 bis 12 normativ. 2.3 Geltungsbereich Das vorliegende Dokument soll bei den Beteiligten im deutschen Gesundheitswesen für eine einheitliche Sichtweise auf die Verwendung von Zertifikaten sorgen. Gleichzeitig spezifiziert es für die genannten Zielgruppen die Prozesse zur Prüfung der Gültigkeit und der fachspezifischen Inhalte mit normativem Charakter. 2.4 Arbeitsgrundlagen Grundlage für dieses Dokument sind die internationalen Standards: ETSI Technical Specification TS ( Provision of harmonized Trust Service Provider (TSP) status information ) (Mai 2005) ISIS-MTT Common ISIS-MTT Specifications for Interoperable PKI Applications RFC 2560: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol OCSP RFC 3280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Es wurden die in Anhang 5 referenzierten Dokumente berücksichtigt. 2.5 Abgrenzung des Dokumentes Die langfristige Bestimmung der Hash-Algorithmen, der Schlüssellängen und der Signaturalgorithmen ist nicht Gegenstand der Betrachtung, hier werden jeweils aktuell die Empfehlungen der international relevanten Gremien und die Anforderungen von SigG/SigV [ALGCAT] berücksichtigt. Die Festlegungen zum Aktivieren qualifizierter Zertifikate [gemqes] und die Vorgaben für die Vereinheitlichung der Public-Key-Infrastrukturen, insbesondere hinsichtlich der Policy-Aspekte [gemtsl_sp_cp], werden in gesonderten Dokumenten getroffen. Im vorliegenden Dokument werden ebenfalls keine Aussagen zum Management der kryptographischen Schlüssel getroffen. Diesbezüglich wird auf das übergreifende Sicherheitskonzept der gematik [gemsiko] verwiesen, insbesondere auf Abschnitt F5 [gemsi- Ko#AnhF5]. Die für die Verwendung in der TI zulässigen Algorithmen, Schlüssellängen und maximalen Gültigkeitsdauern von Schlüsseln und Zertifikaten werden in [gemsiko] sowie entspre- gematik_pki_verwendung_zertifikate_der_ti.doc Seite 10 von 102

11 chend der Technischen Richtlinie für ecard-projekte der Bundesregierung [BSI-TR03116] normativ vorgegeben. Die freie Auswahl aus den hier zugelassenen Algorithmen durch die Hersteller könnte zu Interoperabilitätsproblemen führen, während die Implementierung aller zulässigen Algorithmen erheblichen Aufwand verursacht. Dieser Konflikt wird durch [gemspec_krypt] adressiert. Ziel des Dokumentes Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur [gemspec_krypt] ist es, das Spektrum der zulässigen kryptographischen Algorithmen, sofern sie betreiberübergreifend verwendet werden, einzuschränken, um so mit einer minimalen Anzahl von Algorithmen kryptographische Interoperabilität herzustellen. Deshalb wird als Basis zur Referenzierung der kryptographischen Algorithmen auf o. g. Dokument, Abschnitt [gemspec_krypt#5.1.1] verwiesen. Des Weiteren werden keine Vorgaben bezüglich der Speicherung und des Schutzes der Zertifikate und der zugehörigen privaten Schlüssel getroffen. Das Dokument trifft Vorgaben für die QES-Prüfung in Kapitel 12, jedoch sind hierfür auch die spezifischen Policies der Berufsständischen Organisationen, welche HBAs herausgeben [BÄK_POL], maßgeblich. 2.6 Methodik Verwendung von Schüsselworten Für die genauere Unterscheidung zwischen normativen und informativen Inhalten werden die dem RFC 2119 [RFC2119] entsprechenden in Großbuchstaben geschriebenen, deutschen Schlüsselworte verwendet: MUSS bedeutet, dass es sich um eine absolutgültige und normative Festlegung bzw. Anforderung handelt. DARF NICHT bezeichnet den absolutgültigen und normativen Ausschluss einer Eigenschaft. SOLL beschreibt eine dringende Empfehlung. Abweichungen zu diesen Festlegungen sind in begründeten Fällen möglich. Wird die Anforderung nicht umgesetzt, müssen die Folgen analysiert und abgewogen werden. SOLL NICHT kennzeichnet die dringende Empfehlung, eine Eigenschaft auszuschließen. Abweichungen sind in begründeten Fällen möglich. Wird die Anforderung nicht umgesetzt, müssen die Folgen analysiert und abgewogen werden. KANN bedeutet, dass die Eigenschaften fakultativ oder optional sind. Diese Festlegungen haben keinen Normierungs- und keinen allgemeingültigen Empfehlungscharakter Hinweis auf offene Punkte Offene Punkte, die bis zur nächsten Dokumentversion bearbeitet werden, sind vorläufig mit den folgenden Konventionen gekennzeichnet Offene Punkte, die arbeitsgruppenübergreifend abgestimmt werden müssen, sind Magenta eingerahmt. Durch die Abteilung Zentrale Dienste/Infrastruktur aufgrund bereits erfolgter Abstimmungen noch zu erweiternde Punkte sind violett markiert. gematik_pki_verwendung_zertifikate_der_ti.doc Seite 11 von 102

12 Formale noch offene Inhalte sind blau markiert. Das Kapitel wird in einer späteren Version des Dokumentes ergänzt. 2.7 Technische Use Cases (TUC) In den Kapiteln 8-10 werden Technische Use Cases beschrieben. Diese dienen einerseits dazu, gemeinsames Verhalten der hier beschriebenen konkreten Use Cases nichtredundant zu definieren. Andererseits bilden sie auch die Grundlage für die Definition fachdienstspezifischer Use Cases in den Facharchitekturen und können dort referenziert werden. Die Notation der Use Cases richtet sich an die allgemeinen Vorgaben und ist wie folgt aufgebaut: TUC_PKI_NNN Operation. Die Use Cases sind in Form einer tabellarischen und teilweise von UML Diagrammen definiert. Tabelle 1: Muster der von technischen Use Cases Name Anwendungsumfeld Vorbedingungen Auslöser Eingangsdaten Komponenten Ausgangsdaten <Bezeichnung des Use Case> <, was Gegenstand und Ziel der Bearbeitung ist> <Beschr. des fachlichen Umfelds, in dem der Use Case relevant ist> <Referenzen auf Gesetze, Normen oder Beispiele, Dokumentation, etc.> <Auflistung der vorgegebenen (z. B. gesetzlichen) Anforderungen> <Ereignis/Aktion und Akteur, welche den Use Case auslösen> <für die Bearbeitung benötigte Eingangsdaten> <Komponenten, die an der Bearbeitung beteiligt sind> <Ergebnisse der Bearbeitung> Referenzen <Referenzen auf Beispiele, weiterführende Dokumente etc. für diesen Anwendungsfall> Standardablauf Ablaufschritte für den Normal-/Idealfall. Die Schritte werden nummeriert. 1. <[Akteur:] Bezeichnung und des Arbeitsschritts> kann auch sein: <Name des Extension Points: > Varianten/Alternativen Ablaufschritte, welche eine vollständige Alternative zum Standardfall beschreiben bzw. Abweichungen und Verzweigungen des Normalfalls darstellen: 1a. <Eintrittsbedingung> 1a.1 "<[Akteur:] eines Sonderfall-Ablaufs>" kann auch sein: <Name des Extension Points: > 2. der Nachbedingung Fehlerfälle < der Fehlerfälle> Technische Fehlermeldung Verarbeitung vermutet werden.> <Technische Fehlermeldungen, die vorgegeben werden oder im Rahmen der Sicherheitsanforderungen <Anforderungen aus dem Sicherheitskonzept oder vom Gesetzgeber> Anmerkungen, Bemerkungen <Use Case spezifische Besonderheiten, etc.> gematik_pki_verwendung_zertifikate_der_ti.doc Seite 12 von 102

13 Zugehörige Diagramme <Verweis auf das zugehörige Diagramm> Offene Punkte <Use Case spezifischer Klärungsbedarf, etc.> In der Tabelle sind die jeweils relevanten Bereiche gefüllt. Nicht relevante Bereiche werden nicht angezeigt. gematik_pki_verwendung_zertifikate_der_ti.doc Seite 13 von 102

14 3 Anforderungen Die Anforderungen müssen noch mit dem Anforderungsmanagement abgestimmt werden. Das Kapitel wird in einer späteren Version des Dokumentes entsprechend überarbeitet. Die Notwendigkeit für normative Vorgaben zur Verwendung von Zertifikaten ergibt sich aus mehreren Anforderungen zur Sicherstellung der Interoperabilität und zur Bildung eines mindest Sicherheitsniveaus der PKI durch die gematik. Die folgende Tabelle enthält die entsprechenden Eingangsanforderungen, wie sie aktuell bereits identifiziert werden können: Tabelle 2: Bereits erfasste Eingangsanforderungen Quelle Anforderungsnummer Anforderungslevel [gempolicy] A_01298 MUSS gematik MUSS die Interoperabilität aller Telematikkomponenten sicherstellen. Dies gilt im Sinne der: * Spezifikationsverantwortung * Verantwortung für das Test- und Zulassungsverfahren * Betriebsverantwortung (Betriebsprozesse sowie das einzuhaltende Sicherheitsniveau) * Sicherstellung der Interoperabilität über alle PKI-Strukturen der Telematikinfrastruktur des Gesundheitswesens [gemsiko] AS-AI MUSS Die Integrität der Infrastrukturdienste sowie der sicherheitsrelevanten technischen Komponenten MUSS gewährleistet werden. [gemspec_kon] AF_KON_051 MUSS OCSP-Abfrage OCSP [RFC2560] MUSS als primäres Verfahren zur Statusprüfung für Zertifikate unterstützt werden, auch im Falle von nicht qualifizierten Zertifikaten. Diese Prüfung ist nur auf das Nutzerzertifikat und nicht auf CA-Zertifikate anzuwenden. Als alternatives Verfahren MUSS der Konnektor auch die Prüfung gegen CRLs unterstützen. [gemspec_kon] AF_KON_052 MUSS Vertrauensanker Vertrauensanker für Root- und CA-Zertifikate sind die signierte Trust-service Status List (TSL) und die Trusted Component List (TCL) der gematik Bridge-CA. [gemgesarch] A_01209 MUSS Zertifikate zur Authentisierung von Akteuren in der Telematikinfrastruktur (AUT von HBA, BA, Diensten und OSIG von SMC-B) MÜSSEN eine Kennung für die durch das Zertifikat bestätigte Rolle enthalten (ausgenommen die Rolle Versicherter ). gematik_pki_verwendung_zertifikate_der_ti.doc Seite 14 von 102

15 Quelle Verwendung von Zertifikaten in der Telematikinfrastruktur Anforderungsnummer Anforderungslevel AM A_00575 MUSS Im Protokolldatensatz MUSS ein eindeutiges Kennzeichen für die Institution aufgenommen werden. Die eindeutige Identifikation der Person ist NICHT notwendig. AM A_00875 MUSS Das Vertrauensmodell der PKI MUSS auf einer gematik Bridge CA, die als zentrale Instanz a- giert und auf die alle Zertifikate zurückführbar sein MÜSSEN, basieren. Die Verbindung zwischen weiteren Root CAs und der gematik Bridge CA MUSS durch Trust-service Status Lists (TSLs) hergestellt werden. AM A_00876 MUSS Die Verbindung zwischen weiteren Root CAs und der gematik Bridge CA MUSS durch Trusted-service Status Lists (TSLs) hergestellt werden, die durch die gematik signiert und herausgegeben werden MÜSSEN. Innerhalb der PKI MÜSSEN zwei getrennte TSLs existieren: die Infrastruktur TSL und die Personen TSL. AM A_00877 MUSS Die Infrastruktur-TSL (Trust-service Status List) MUSS alle CAs enthalten, die Service- und Netzzertifikate ausstellen dürfen. AM A_00881 MUSS Jede CA MUSS einen OCSP-Responder betreiben, über den die durch diese CA ausgestellten Zertifikate überprüft werden können. Aus Performanzgründen KÖNNEN zwei Optimierungen eingeführt werden: 1. Die spätere Einführung von CRLs bzw. Caching von OCSP-Anfragen. 2. Die maximalen Caching-Zeiten MÜSSEN bei der Verwendung von Caching vor dem Rollout festgelegt werden. AM A_01086 MUSS Nachrichtenkommunikation zwischen verschiedenen Anwendungsservices in der Telematik MUSS Authentifizierung, Autorisierung, Vertraulichkeit und Integritätsschutz über SSL/TLS unter Verwendung von X.509 Zertifikaten (für Clientund Serverauthentifizierung) implementieren. AM A_01110 MUSS Der Status von Zertifikaten der Telematikinfrastruktur MUSS immer über das Online Certificate Status Protocol (OCSP) erfolgen. AM A_01196 MUSS Der durch eine CA benannte OCSP-Responder MUSS Auskunft über den Status jedes Zertifikates dieser CA geben können. AM A_01197 MUSS Zum Widerrufen eines Zertifikates (revoke) MUSS dieses im Backendsystem der CA als gesperrt markiert werden und durch den OCSP Responder ab diesem Zeitpunkt als gesperrt gemeldet werden, um einzelne an der Telematik teilnehmende Identitäten (Personen, Institutionen oder Dienste/Geräte sowie Baugruppen) zu sperren. gematik_pki_verwendung_zertifikate_der_ti.doc Seite 15 von 102

16 Quelle Verwendung von Zertifikaten in der Telematikinfrastruktur Anforderungsnummer Anforderungslevel AM A_01706 SOLL Zur besseren Handhabbarkeit und für eine effiziente Umsetzung von Sicherheitsvorgaben SOLL die Rolle in den verschiedenen Zertifikaten einheitlich (d.h. z.b. gleiches Feld/Attribut, gleiches Encoding und Datenformat) kodiert werden. Anmerkung: Gemäß [gemspec_kon] werden die Anforderungsnummern in der Konnektorspezifikation evtl. noch geändert. gematik_pki_verwendung_zertifikate_der_ti.doc Seite 16 von 102

17 4 Gesamtüberblick der verwendeten Zertifikate Der Gesamtüberblick der verwendeten Zertifikate wird in der Gesamtarchitektur beschrieben. Für weitere Details wird hier auf den Anhang B der Gesamtarchitektur verwiesen [gemgesarch#anhang B]. gematik_pki_verwendung_zertifikate_der_ti.doc Seite 17 von 102

18 5 Standardvorgaben für Zertifikate Initial MUSS in das sich auf den Vertrauensraum stützende System das Root-Zertifikat der TSL sicher eingebracht werden, um den Vertrauensanker zu gewährleisten [gemsi- Ko#AnhC2.77]. Zur Unterscheidung von Zertifikatstypen und zur eindeutigen Ermittlung der Rolle enthalten alle Zertifikate in der Telematikinfrastruktur die Zertifikatserweiterungen "CertificatePolicies und "Admission. Die egk-zertifikate bilden hier jedoch als einzige eine Ausnahme. Da sie keine Rolle bestätigen entfällt die Erweiterung Admission in diesem Profil. 5.1 Angaben zum Zertifikatstyp in der Extension CertificatePolicies Die Extension MUSS neben den Referenzen auf die zugrunde liegenden Policies für die Zertifikate auch die Angaben zum Zertifikatstyp enthalten. Die Extension ist non-critical. ASN.1-Struktur nach [ISIS-MTT] (nur relevanter Teil): CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation PolicyInformation ::= SEQUENCE policyidentifier CertPolicyId, policyqualifiers SEQUENCE SIZE(1..MAX) OF PolicyQualifierInfo OPTIONAL CertPolicyId ::= OBJECT IDENTIFIER Es ist möglich mehrere Policies aufzunehmen. Wenn Anforderungen (z. B. Sicherheitsanforderungen) einer aufgeführten Policy durch eine andere aufgeführte Policy im selben Zertifikat vermindert werden, dann gelten stets die jeweiligen schärferen Anforderungen. Für die Angabe des Zertifikatstyps MUSS ein PolicyInformation eingefügt werdem, das die OID für den Zertifikatstyp als Wert des Unterelements policyidentifier enthält. Dieses PolicyInformation enthält kein Unterelement policy- Qualifier. Das vorliegende Dokument trifft nicht die Festlegungen zu den tatsächlich einzutragenden OIDs. Die normative Festlegung der OIDs trifft das Dokument [gemspec_oid]. 5.2 Admission Die Admission-Extension beinhaltet die Rolle der Identität sowohl als Text als auch in Form einer maschinenlesbarer OID. Vorgaben zum Format und in welchem Feld diese Angaben gespeichert werden, findet sich am Ende des Abschnitts im Bereich Belegte Felder und Formate. gematik_pki_verwendung_zertifikate_der_ti.doc Seite 18 von 102

19 Die genaue Festlegung der OID wird im Dokument [gemspec_oid] spezifiziert. ASN.1-Struktur nach [ISIS-MTT]: AdmissionSyntax ::= SEQUENCE admissionauthority GeneralName OPTIONAL, contentsofadmissions SEQUENCE OF Admissions Admissions ::= SEQUENCE admissionauthority [0] EXPLICIT GeneralName OPTIONAL, namingauthority [1] EXPLICIT NamingAuthority OPTIONAL, professioninfos SEQUENCE OF ProfessionInfo NamingAuthority ::= SEQUENCE namingauthorityid OBJECT IDENTIFIER OPTIONAL, namingauthorityurl IA5String OPTIONAL, namingauthoritytext DirectoryString (SIZE(1..128)) OPTIONAL ProfessionInfo ::= SEQUENCE namingauthority [0] EXPLICIT NamingAuthority OPTIONAL, professionitems SEQUENCE OF DirectoryString (SIZE(1..128)), professionoids SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, registrationnumber PrintableString (SIZE(1..128)) OPTIONAL, addprofessioninfo OCTET STRING OPTIONAL Belegte Felder und Formate: Art der Kennzeich-Ornung Bezeichnung Format Rolle Admission/ ProfessionItem Text ProfessionInfo ProfessionOID OID [ISO ] Entgegen der Optionalität aus [ISIS-MTT] MUSS das Feld ProfessionOID gefüllt werden. gematik_pki_verwendung_zertifikate_der_ti.doc Seite 19 von 102

20 6 Einordnung der Zertifikate innerhalb der Gesamtarchitektur Dieses Kapitel wird in einer späteren Version (nach R2.3.2) finalisiert(geplant für Release 3). Dieser Abschnitt definiert die kryptographischen Identitäten der Telematikinfrastruktur für die egk im deutschen Gesundheitswesen gemäß 291a (SGB V) und ihre Verteilung auf Bereiche und Schlüsselträger. Als kryptographische Identität wird dabei die Zusammenstellung privater Schlüssel und zugehöriger Zertifikate bezeichnet. Da hierbei der private Schlüssel inkludiert ist, kann eine Identität nur jeweils einmal bei ihrem Eigentümer vorhanden sein (der Fall des Klonens privater Schlüssel wird hierbei außer acht gelassen, spielt aber für die nachfolgenden Ausführungen keine Rolle). Die Nutzung der Zertifikate ist im Rahmen der Verteilung der Identitäten nicht modelliert. Die folgenden Identitäten auf Basis von X.509 Zertifikaten sind beschrieben: Abbildung 1: Beschriebene Typen der Zertifikate auf Basis von 509 Zertifikaten aus dem zentralen Repository der gematik gematik_pki_verwendung_zertifikate_der_ti.doc Seite 20 von 102

21 7 Einteilung der Zertifikate Dieses Kapitel wird in einer späteren Version finalisiert (geplant für Release 3). gematik_pki_verwendung_zertifikate_der_ti.doc Seite 21 von 102

22 8 Vertrauensraum Generell gilt für die Zertifikatsprüfung, dass zum einen das End-Entity-Zertifikat per OCSP, zum anderen das Aussteller-Zertifikat gegen die TSL auf Gültigkeit geprüft wird.. Die TSL hat dabei die Funktion eines gemeinsamen Vertrauensraums im Sinne einer White-List der zugelassenen Herausgeber. Um ein Aussteller-Zertifikat gegen die TSL prüfen zu können, muss zunächst eine aktuelle und gültige TSL im zertifikatsprüfenden System vorliegen. Im Folgenden werden die notwendigen Prüfschritte zur Prüfung des Vertrauensraums in Form von Technischen Use Cases dargestellt. Die Schritte werden hier kurz aufgelistet: Download der TSL Prüfung der Aktualität und Validierung der TSL Prüfung des TSL-Signaturzertifikats gegen einen sicher verwahrten gematik- TSL-Root-Schlüssel Prüfung der Integrität der TSL durch Prüfung der Signatur der TSL gematik_pki_verwendung_zertifikate_der_ti.doc Seite 22 von 102

23 8.1 Prozesse zur Nutzung des Vertrauensraums Abbildung 2: Use Case Diagramm "Prozesse zur Nutzung des Vertrauensraums" 8.2 Initialisierung im Offline-Fall Im Offline-Fall werden Use Cases TUC_PKI_006 "OCSP-Abfrage" und TUC_PKI_005 "OCSP Adresse ermitteln" zur Zertifikatsprüfung nicht berücksichtigt. Jedoch DÜRFEN Komponenten, die nicht für den Offline-Fall vorgesehen sind, diese Einschränkung NICHT nutzen. Des Weiteren ist der Offline-Fall nur in bestimmten Umgebungen zulässig. Die Initialisierung bzw. die Prüfung des Signaturzertifikats einer TSL für den Offline-Fall muss näher beschrieben werden. Dies ist arbeitsgruppenübergreifend zu diskutieren und eine Spezifikation ist für Release 3 geplant. 8.3 Initialisierung ohne Vorbedingungen Einige TUCs im Prozess der Initialisierung des Vertrauensraums sind nur aufgrund bestimmter Vorbedingungen, wie TSL mit gültiger Signatur und TSL mit gültigem Zeitraum, durchführbar. Zum Zeitpunkt der Initialisierung eines Systems können diese Vor- gematik_pki_verwendung_zertifikate_der_ti.doc Seite 23 von 102

Einführung der Gesundheitskarte Verwendung von Zertifikaten in der Telematikinfrastruktur

Einführung der Gesundheitskarte Verwendung von Zertifikaten in der Telematikinfrastruktur Einführung der Gesundheitskarte Verwendung von Zertifikaten in der Telematikinfrastruktur Version: 1.1.0 Stand: 28.02.2008 Status: freigegeben gematik_pki_verwendung_zertifikate_der_ti_v1.1.0.doc Seite

Mehr

PKI für das System und Service

PKI für das System und Service Einführung der Gesundheitskarte PKI für das System und Service Level Monitoring Version: 1.2.0 Revision: main/rel_main/17 Stand: 30.06.2008 Status: freigegeben gematik_pki_x 509_SSL_Monitoring.doc Seite

Mehr

Akzeptanz von Vertrauensräumen in IT-Infrastrukturen

Akzeptanz von Vertrauensräumen in IT-Infrastrukturen Frédéric Naujokat, Arno Fiedler, Wolfgang Schwab Akzeptanz von Vertrauensräumen in IT-Infrastrukturen Bildung nicht hierarchischer Vertrauensräume mittels des ETSI TSL-Konzeptes im Gesundheitswesen Für

Mehr

Gültigkeitsmodell der elektronischen Arztausweise und Laufzeit der Zertifikate

Gültigkeitsmodell der elektronischen Arztausweise und Laufzeit der Zertifikate Seite 1 von 6 Autor: G. Raptis Gültigkeitsmodell der elektronischen Arztausweise und Laufzeit der Zertifikate Gültigkeitsmodelle beschreiben den Algorithmus nach dem ein Client oder Dienst entscheidet,

Mehr

Festlegungen zu den Notationen

Festlegungen zu den Notationen Einführung der Gesundheitskarte Festlegungen zu den Notationen von Schlüsseln und Zertifikaten kryptographischer Objekte in der TI Version: 1.0.0 Stand: 17.03.2008 Status: freigegeben gematik_pki_notationen_schl_und_zert_v1.0.0.doc

Mehr

PKI für CV-Zertifikate

PKI für CV-Zertifikate Einführung der Gesundheitskarte PKI für CV-Zertifikate Registrierung einer CVC-CA der zweiten Ebene Version: 1.5.0 Stand: 18.03.2008 Status: freigegeben gematik_pki_cvc_registrierung_subca_v1_5_0.doc Seite

Mehr

Registrierungsverfahren für die kryptographische Identität von Server- und (Fach-) Diensten

Registrierungsverfahren für die kryptographische Identität von Server- und (Fach-) Diensten Einführung der Gesundheitskarte Registrierungsverfahren für die kryptographische Identität von Server- und (Fach-) Diensten Version: 1.2.0 Revision: main/rel_main/32 Stand: 01.07.2008 Status: freigegeben

Mehr

Einführung der Gesundheitskarte Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur

Einführung der Gesundheitskarte Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur Einführung der Gesundheitskarte Verwendung kryptographischer Algorithmen in der Version: 1.3.0 Stand: 26.03.2008 Status: freigegeben gematik_ga_spezifikation_kryptographischer_algorithmen_v1_3_0.doc Seite

Mehr

Public-Key-Infrastrukturen

Public-Key-Infrastrukturen TECHNISCHE UNIVERSITÄT DARMSTADT FACHGEBIET THEORETISCHE INFORMATIK PROF. DR. J. BUCHMANN DR. A. WIESMAIER 9. Übung zur Vorlesung Public-Key-Infrastrukturen Sommersemester 2011 Aufgabe 1: Indirekte CRL

Mehr

Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen

Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen D-TRUST GmbH Kommandantenstraße 15 10969 Berlin für den Zertifizierungsdienst D-TRUST SSL Class 3 CA 1 EV

Mehr

Internet Security: Verfahren & Protokolle

Internet Security: Verfahren & Protokolle Internet Security: Verfahren & Protokolle 39 20 13 Vorlesung im Grundstudium NWI (auch MGS) im Sommersemester 2003 2 SWS, Freitag 10-12, H10 Peter Koch pk@techfak.uni-bielefeld.de 30.05.2003 Internet Security:

Mehr

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com Merkblatt: HSM Version 1.01 Systemvoraussetzungen, Setup und Trouble Shooting Kontakt: pdfsupport@pdf-tools.com Besitzer: PDF Tools AG Kasernenstrasse 1 8184 Bachenbülach Schweiz www.pdf-tools.com Copyright

Mehr

Digitale Signatur. Digitale Signatur. Anwendungen der Kryptographie. Secret Sharing / Splitting. Ziele SSL / TLS

Digitale Signatur. Digitale Signatur. Anwendungen der Kryptographie. Secret Sharing / Splitting. Ziele SSL / TLS Digitale Signatur Digitale Signatur kombiniert Hash Funktion und Signatur M, SIGK(HASH(M)) wichtige Frage: Wie wird der Bithaufen M interpretiert Struktur von M muss klar definiert sein Wie weiss ich,

Mehr

Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen

Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen TC TrustCenter GmbH Sonninstraße 24-28 20097 Hamburg für den Zertifizierungsdienst TC TrustCenter Class 2

Mehr

Programmiertechnik II

Programmiertechnik II X.509: Eine Einführung X.509 ITU-T-Standard: Information Technology Open Systems Interconnection The Directory: Public Key and attribute certificate frameworks Teil des OSI Directory Service (X.500) parallel

Mehr

E-Mail-Verschlüsselung Vorrausetzungen

E-Mail-Verschlüsselung Vorrausetzungen E-Mail-Verschlüsselung Vorrausetzungen Datum: 09.08.2011 Dokumentenart: Anwenderbeschreibung Version: 2.0 : Redaktionsteam PKI cio.siemens.com Inhaltsverzeichnis 1. Zweck des Dokumentes:...3 2. Voraussetzungen...4

Mehr

Allgemeine Erläuterungen zu

Allgemeine Erläuterungen zu en zu persönliche Zertifikate Wurzelzertifikate Zertifikatssperrliste/Widerrufsliste (CRL) Public Key Infrastructure (PKI) Signierung und Verschlüsselung mit S/MIME 1. zum Thema Zertifikate Zertifikate

Mehr

Use Case Beschreibung:

Use Case Beschreibung: <Name (Nummer)> Dokument-Art UC Geltungsbereich Use Case Beschreibung: Version Autor Ausgabe vom Ersetzt Dokument Ausgabestelle Prüfstelle Freigabestelle

Mehr

Einführung der elektronischen Gesundheitskarte Informationsbroschüre G2 Karten

Einführung der elektronischen Gesundheitskarte Informationsbroschüre G2 Karten Einführung der elektronischen Gesundheitskarte Informationsbroschüre G2 Karten Version: 1.0.0 Stand: 23.07.2012 Status: freigegeben Klassifizierung: öffentlich Referenzierung: [geminfo_g2_karten] Autor:

Mehr

Konfigurieren der Netzwerksicherheit mit Hilfe von PKI (Public Key Infrastructure)

Konfigurieren der Netzwerksicherheit mit Hilfe von PKI (Public Key Infrastructure) Unterrichtseinheit 5: Konfigurieren der Netzwerksicherheit mit Hilfe von PKI (Public Key Infrastructure) Verschlüsselung mit öffentlichen Schlüsseln ist eine bedeutende Technologie für E- Commerce, Intranets,

Mehr

Literatur. ISM SS 2015 - Teil 18/PKI-2

Literatur. ISM SS 2015 - Teil 18/PKI-2 Literatur [18-1] Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile http://tools.ietf.org/html/rfc5280 [18-2] Verifikation digitaler Signaturen http://www.informatik.tu-darmstadt.de/

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.0-09.05.2011 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

Web Service Security

Web Service Security Hochschule für Angewandte Wissenschaften Hamburg Fachbereich Elektrotechnik und Informatik SS 2005 Masterstudiengang Anwendungen I Kai von Luck Web Service Security Thies Rubarth rubart_t@informatik.haw-hamburg.de

Mehr

OFTP2 - Checkliste für die Implementierung

OFTP2 - Checkliste für die Implementierung connect. move. share. Whitepaper OFTP2 - Checkliste für die Implementierung Die reibungslose Integration des neuen Odette-Standards OFTP2 in den Datenaustausch- Workflow setzt einige Anpassungen der Systemumgebung

Mehr

Einsatz von Public Key Infrastrukturen in großen heterogenen Organisationen. Christoph Thiel

Einsatz von Public Key Infrastrukturen in großen heterogenen Organisationen. Christoph Thiel Einsatz von Public Key Infrastrukturen in großen heterogenen Organisationen Christoph Thiel Stuttgart, 4. November 2014 Das extented enterprise SSL E-Mail Grundlegende Sicherheitsanforderungen Authentisierung

Mehr

Gemeinsame Zertifizierungs- Richtlinie für Teilnehmer der gematik- TSL zur Herausgabe von X.509-

Gemeinsame Zertifizierungs- Richtlinie für Teilnehmer der gematik- TSL zur Herausgabe von X.509- Einführung der Gesundheitskarte - Certificate Policy - Gemeinsame Zertifizierungs- Richtlinie für Teilnehmer der gematik- TSL zur Herausgabe von X.509- ENC/AUT/OSIG-Zertifikaten Version: 1.3.0 Revision:

Mehr

Information der Landesärztekammer Brandenburg zum earztausweis Beantragung und Herausgabe des elektronischen Arztausweises

Information der Landesärztekammer Brandenburg zum earztausweis Beantragung und Herausgabe des elektronischen Arztausweises Information der zum earztausweis Beantragung und Herausgabe des elektronischen Arztausweises Aktuelle Rahmenbedingungen zum earztausweis 1. Zurzeit können elektronische Arztausweise der Generation 0 produziert

Mehr

Digitale Signaturen für Ï Signaturzertifikate für geschützte email-kommunikation

Digitale Signaturen für Ï Signaturzertifikate für geschützte email-kommunikation Digitale Signaturen für Ï Signaturzertifikate für geschützte email-kommunikation Ein Großteil der heutigen Kommunikation geschieht per email. Kaum ein anderes Medium ist schneller und effizienter. Allerdings

Mehr

ÖSTERREICH RECHNET MIT UNS. Standard e-rechnungs-webservice (SERWS) - Ideen DI Philip Helger, BRZ 17.02.2015

ÖSTERREICH RECHNET MIT UNS. Standard e-rechnungs-webservice (SERWS) - Ideen DI Philip Helger, BRZ 17.02.2015 ÖSTERREICH RECHNET MIT UNS Standard e-rechnungs-webservice (SERWS) - Ideen DI Philip Helger, BRZ 17.02.2015 www.brz.gv.at BRZ GmbH 2015 AGENDA Ausgangsbasis Webservice bei E-RECHNUNG.GV.AT SERWS Ziele

Mehr

E-Mail-Verschlüsselung mit Geschäftspartnern

E-Mail-Verschlüsselung mit Geschäftspartnern E-Mail-Verschlüsselung mit (Anleitung für Geschäftspartner) Datum: 13.07.2011 Dokumentenart: Anwenderbeschreibung Version: 3.0 : Redaktionsteam PKI cio.siemens.com Inhaltsverzeichnis 1. Zweck des Dokumentes:...3

Mehr

Einführung der Gesundheitskarte Spezifikation TelematikTransport-Details

Einführung der Gesundheitskarte Spezifikation TelematikTransport-Details Einführung der Gesundheitskarte Spezifikation Version: 1.6.0 Revision: main/rel_main/rel_r2.3.x/9 Stand: 27.06.2008 Status: freigegeben gematik_ga_spezifikation_telematik-transport-details.doc Seite 1

Mehr

Fachhochschule Frankfurt am Main Fachbereich 2: Informatik WS 2008/2009. IT-Security. Teil 2: Zertifikate, X.509, PKI Dr.

Fachhochschule Frankfurt am Main Fachbereich 2: Informatik WS 2008/2009. IT-Security. Teil 2: Zertifikate, X.509, PKI Dr. Fachhochschule Frankfurt am Main Fachbereich 2: Informatik WS 2008/2009 IT-Security Teil 2: Zertifikate, X.509, PKI Dr. Erwin Hoffmann E-Mail: it-security@fehcom.de Einsatz von Zertifikaten Ein Zertifikat

Mehr

Anleitung zur Prüfung von qualifizierten elektronischen Signaturen nach schweizerischem Signaturgesetz

Anleitung zur Prüfung von qualifizierten elektronischen Signaturen nach schweizerischem Signaturgesetz Anleitung zur Prüfung von qualifizierten elektronischen Signaturen nach schweizerischem Signaturgesetz Das schweizerische Signaturgesetz (ZertES) ist die gesetzliche Grundlage für qualifizierte digitale

Mehr

Stammtisch 04.12.2008. Zertifikate

Stammtisch 04.12.2008. Zertifikate Stammtisch Zertifikate Ein Zertifikat ist eine Zusicherung / Bestätigung / Beglaubigung eines Sachverhalts durch eine Institution in einem definierten formalen Rahmen 1 Zertifikate? 2 Digitale X.509 Zertifikate

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.1-21.02.2014 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

E-Mail-Verschlüsselung mit Geschäftspartnern

E-Mail-Verschlüsselung mit Geschäftspartnern E-Mail-Verschlüsselung mit (Anleitung für Geschäftspartner) Datum: 15.07.2013 Dokumentenart: Anwenderbeschreibung Version: 3.2 : Redaktionsteam PKI cio.siemens.com Inhaltsverzeichnis 1. Zweck des Dokumentes:...

Mehr

Erklärung zum Zertifizierungsbetrieb der TU Dortmund Chipcard CA in der DFN-PKI. - Sicherheitsniveau: Global -

Erklärung zum Zertifizierungsbetrieb der TU Dortmund Chipcard CA in der DFN-PKI. - Sicherheitsniveau: Global - Erklärung zum Zertifizierungsbetrieb der TU Dortmund Chipcard CA in der DFN-PKI - Sicherheitsniveau: Global - Technische Universität Dortmund CPS der TU Dortmund Chipcard CA V1.3 01.10.2011 1 Einleitung

Mehr

1 Status des Dokuments... 3. 3 Datenmodell... 3 3.1 Person... 3. 5 Zuständigkeit und Mutationswesen... 8. 6 Sicherheitsüberlegungen...

1 Status des Dokuments... 3. 3 Datenmodell... 3 3.1 Person... 3. 5 Zuständigkeit und Mutationswesen... 8. 6 Sicherheitsüberlegungen... E-Government-Standards Seite 1 von 10 ech-0046 Datenstandard Kontakt Name Standard-Nummer Kategorie Reifegrad Datenstandard Kontakt ech-0046 Standard Definiert Version 2.0 Status Genehmigt Genehmigt am

Mehr

Erinnerung Public Key Infrastruktur

Erinnerung Public Key Infrastruktur Erinnerung Public Key Infrastruktur Certification Authority (CA) (pk CA, sk CA ) Nutzer 1 (pk 1, sk 1 ), C 1 Nutzer n (pk n, sk n ), C n Angaben zum Nutzer: Name, Organisation, usw. C i = öff. Schl. pk

Mehr

Secure Socket Layer (SSL) 1: Allgemeiner Überblick. Gilt für die Geräte: HL-4040CN HL-4050CDN HL-4070CDW DCP-9040CN DCP-9045CDN MFC-9440CN MFC-9840CDW

Secure Socket Layer (SSL) 1: Allgemeiner Überblick. Gilt für die Geräte: HL-4040CN HL-4050CDN HL-4070CDW DCP-9040CN DCP-9045CDN MFC-9440CN MFC-9840CDW Secure Socket Layer (SSL) Gilt für die Geräte: HL-4040CN HL-4050CDN HL-4070CDW DCP-9040CN DCP-9045CDN MFC-9440CN MFC-9840CDW Inhalt 1) Allgemeiner Überblick 2) Kurzer geschichtlicher Rückblick 3) Vorteile

Mehr

Elektronische Unterschriften mit Adobe Acrobat 9. Version 1.0 14. April 2009

Elektronische Unterschriften mit Adobe Acrobat 9. Version 1.0 14. April 2009 Version 1.0 14. April 2009 Einleitung Diese Anleitung beschreibt in Kurzform wie (Standard, Pro und Pro Extended) PDF Dokumente signiert oder zertifiziert respektive die Signatur(en) geprüft werden können.

Mehr

Anleitung zur Überprüfung der Signatur von Elektronischen Kontoauszügen

Anleitung zur Überprüfung der Signatur von Elektronischen Kontoauszügen Seite 1 Anleitung zur Überprüfung der Signatur von Elektronischen Kontoauszügen Zur Prüfung, ob die qualifizierte Signatur eines elektronischen Kontoauszugs gültig ist, können verschiedene Softwarelösungen

Mehr

Notfalldaten und Datenerhalt mit der elektronischen Gesundheitskarte

Notfalldaten und Datenerhalt mit der elektronischen Gesundheitskarte Notfalldaten und Datenerhalt mit der elektronischen Gesundheitskarte Smartcard-Workshop Darmstadt, 9. Februar 2012 Georgios Raptis Bundesärztekammer Notfalldatensatz auf der egk 2003 291a SGB V die egk

Mehr

Ist das so mit HTTPS wirklich eine gute Lösung?

Ist das so mit HTTPS wirklich eine gute Lösung? SSL/TLS und PKI im Internet Erik Tews erik@datenzone.de Ist das so mit HTTPS wirklich eine gute Lösung? 21.05.2012 Erik Tews 1 Was ist PKI Asymmetrische Kryptographie ist echt praktisch Schlüssel bestehen

Mehr

Inhalt... 1 Einleitung... 1 Systemanforderungen... 1 Software Download... 1 Prüfdokumentation... 4 Probleme... 5 Hintergrund... 5

Inhalt... 1 Einleitung... 1 Systemanforderungen... 1 Software Download... 1 Prüfdokumentation... 4 Probleme... 5 Hintergrund... 5 Inhalt Inhalt... 1 Einleitung... 1 Systemanforderungen... 1 Software Download... 1 Prüfdokumentation... 4 Probleme... 5 Hintergrund... 5 Dieses Dokument gibt ist eine Anleitung zur sicheren und einfachen

Mehr

Kurzanleitung digiseal reader

Kurzanleitung digiseal reader Seite 1 von 13 Kurzanleitung digiseal reader Kostenfreie Software für die Prüfung elektronisch signierter Dokumente. Erstellt von: secrypt GmbH Support-Hotline: (0,99 EURO pro Minute aus dem deutschen

Mehr

IT-Sicherheit WS 2012/13. Übung 5. zum 28. November 2012

IT-Sicherheit WS 2012/13. Übung 5. zum 28. November 2012 Prof. Dr. C. Eckert Thomas Kittel IT-Sicherheit WS 2012/13 Übung 5 zum 28. November 2012 Institut für Informatik Lehrstuhl für Sicherheit in der Informatik 1 X.509-Zertifikate Zertifikate nach dem X.509-Standard

Mehr

Einführung der Gesundheitskarte Schemaversion 5.2 VSD - Überblick und Änderungen

Einführung der Gesundheitskarte Schemaversion 5.2 VSD - Überblick und Änderungen Einführung der Gesundheitskarte Schemaversion 5.2 VSD - Version: 1.2.0 Stand: 14.09.2015 Status: freigegeben Klassifizierung: öffentlich Referenzierung: [gemschema_vsdm_5_2] gemschema_vsdm_5_2_v1_2_0.doc

Mehr

Erklärung zum Zertifizierungsbetrieb der GRS CA in der DFN-PKI

Erklärung zum Zertifizierungsbetrieb der GRS CA in der DFN-PKI Erklärung zum Zertifizierungsbetrieb der GRS CA in der DFN-PKI - Sicherheitsniveau: Global - Gesellschaft für Anlagen- und Reaktorsicherheit (GRS) mbh CPS der GRS CA V2.1 12.07.2011 CPS der GRS CA Seite

Mehr

Installationsanleitung

Installationsanleitung 1 Inhalt 1 Inhalt 1 2 Sicherheitshinweise 2 2.1 Allgemeine Richtlinien und Empfehlungen 2 2.2 Allgemeine Sicherheitskriterien 2 3 Zugriffsmöglichkeiten 3 3.1 Browserbasierte Zugriffe auf Dienste im BVN

Mehr

Denn es geht um ihr Geld:

Denn es geht um ihr Geld: Denn es geht um ihr Geld: [A]symmetrische Verschlüsselung, Hashing, Zertifikate, SSL/TLS Warum Verschlüsselung? Austausch sensibler Daten über das Netz: Adressen, Passwörter, Bankdaten, PINs,... Gefahr

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Yellowbill Adapter Spezifikationen Voraussetzungen Datum : 22.08.2013 Version : 1.0.0.2 22.08.2013 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung...3 2 Architektur...3 2.1 Grundsätze

Mehr

Zertifizierungsrichtlinien

Zertifizierungsrichtlinien Zertifizierungsrichtlinien Certification Practice Statement (CPS) Migros Corporate PKI NG-PKI 2014 Interne CA Hierarchie keyon AG Schlüsselstrasse 6 8645 Jona Tel +41 55 220 64 00 www.keyon.ch Switzerland

Mehr

Informationssicherheit in Unternehmen

Informationssicherheit in Unternehmen Informationssicherheit in Unternehmen Erfahrungen aus 5 Praxisprojekten mit mittleren und großen Unternehmen IT-Showcase 21. Juni 2001 Prof. Dr. Hartmut Pohl Hartmut.Pohl@fh-bonn-rhein-sieg.de Forschungsstelle

Mehr

Gemeinsame Zertifizierungs- Richtlinie für Teilnehmer der gematik- TSL zur Herausgabe von X.509-

Gemeinsame Zertifizierungs- Richtlinie für Teilnehmer der gematik- TSL zur Herausgabe von X.509- Einführung der Gesundheitskarte - Certificate Policy - Gemeinsame Zertifizierungs- Richtlinie für Teilnehmer der gematik- TSL zur Herausgabe von X.509- ENC/AUT/OSIG-Zertifikaten Version: 1.0.0 Stand: 16.10.2006

Mehr

Prüfvorschriften. Update Flag Service (UFS)

Prüfvorschriften. Update Flag Service (UFS) Einführung der Gesundheitskarte Prüfvorschriften Prüfvorschriften ID Test_PVo_UFS Version: 1.2.0 ClearCase Version: \main\25 Stand: 24.11.2008 Status: freigegeben gematik_test_pvo_ufs_v1.2.0.doc Seite

Mehr

Einführung der Gesundheitskarte Spezifikation Fehlerbehandlung

Einführung der Gesundheitskarte Spezifikation Fehlerbehandlung Einführung der Gesundheitskarte Spezifikation Version: 1.3.0 Stand: 18.12.2007 Status: freigegeben gematik_ga_spezifikation V1_3_0.doc Seite 1 von 50 Dokumentinformationen Änderungen zur Vorversion Eine

Mehr

Metadaten. Organisationsstrukturen und Sicherheit in Shibboleth. Authentifizierung, Autorisierung und Rechteverwaltung

Metadaten. Organisationsstrukturen und Sicherheit in Shibboleth. Authentifizierung, Autorisierung und Rechteverwaltung Authentifizierung, Autorisierung und Rechteverwaltung Metadaten Organisationsstrukturen und Sicherheit in Shibboleth 3. Shibboleth-Workshop Freiburg, 10. Oktober 2006 Bernd Oberknapp, UB Freiburg E-Mail:

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Paynet Adapter Spezifikationen Voraussetzungen Datum : 21.07.08 Version : 1.0.0.2 21.07.2008 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung... 3 2 Architektur... 3 2.1 Grundsätze

Mehr

Einführung in OpenSSL und X.509-Zertifikate. Martin Kaiser http://www.kaiser.cx/

Einführung in OpenSSL und X.509-Zertifikate. Martin Kaiser http://www.kaiser.cx/ Einführung in OpenSSL und X.509-Zertifikate Martin Kaiser http://www.kaiser.cx/ Über mich Elektrotechnik-Studium Uni Karlsruhe System-Ingenieur UNIX und IP-Netze (2001-2003) Embedded Software-Entwicklung

Mehr

Roadmap Fortgeschrittene Signaturen

Roadmap Fortgeschrittene Signaturen Roadmap Roadmap Fortgeschrittene Signaturen Version 1.0.1, 13.02.2013 Klaus Stranacher klaus.stranacher@egiz.gv.at Arne Tauber arne.tauber@egiz.gv.at Zusammenfassung: Das vorliegende Dokument stellt eine

Mehr

Smart Metering PKI - Public Key Infrastruktur für Smart Meter Gateways

Smart Metering PKI - Public Key Infrastruktur für Smart Meter Gateways Technische Richtlinie BSI TR-03109-4 Smart Metering PKI - Public Key Infrastruktur für Smart Meter Gateways Version 1.1.1 Datum: 18.05.15 Bundesamt für Sicherheit in der Informationstechnik Postfach 20

Mehr

SSL/TLS und SSL-Zertifikate

SSL/TLS und SSL-Zertifikate SSL/TLS und SSL-Zertifikate Konzepte von Betriebssystem-Komponenten Informatik Lehrstuhl 4 16.06.10 KvBK Wolfgang Hüttenhofer sethur_blackcoat@web.de Motivation Sichere, verschlüsselte End-to-End Verbindung

Mehr

Infrastruktur: Vertrauen herstellen, Zertifikate finden

Infrastruktur: Vertrauen herstellen, Zertifikate finden TeleTrusT Bundesverband IT-Sicherheit e.v. Infrastruktur: Vertrauen herstellen, Zertifikate finden Allgemeines zur TeleTrusT EBCA Seit 2001 Zusammenschluss einzelner, gleichberechtigter n zu -Verbund einfacher,

Mehr

Die Spezifikation der Lösungsarchitektur zur Umsetzung der Anwendungen der elektronischen Gesundheitskarte Management Summary Prof. Dr.

Die Spezifikation der Lösungsarchitektur zur Umsetzung der Anwendungen der elektronischen Gesundheitskarte Management Summary Prof. Dr. Die Spezifikation der Lösungsarchitektur zur Umsetzung der Anwendungen der elektronischen Gesundheitskarte Management Summary Prof. Dr. Herbert Weber Von Dezember 2004 bis Februar 2005 haben die Fraunhofer-Institute

Mehr

Netzsicherheit Architekturen und Protokolle Grundlagen PKI/PMI

Netzsicherheit Architekturen und Protokolle Grundlagen PKI/PMI Grundlagen PKI/PMI 1 Motivation 2 Digitale Zertifikate 3 Infrastrukturen 4 PKI (Bausteine) 5 Vertrauensmodelle Wiederholung Kryptographie Symmetrische Kryptographie 1 Schlüssel für Ver- und Entschlüsselung

Mehr

X.509-Zertifikate mit OpenSSL Mario Lorenz mailto:ml@vdazone.org. 18. November 2002

X.509-Zertifikate mit OpenSSL Mario Lorenz mailto:ml@vdazone.org. 18. November 2002 X.509-Zertifikate mit OpenSSL Mario Lorenz mailto:ml@vdazone.org 18. November 2002 1 Grundlagen Wir nehmen an, dass mathematische Algorithmen zur sicheren Verschlüsselung und zur Signatur verfügbar seien

Mehr

Serviceanweisung Austausch Globalsign Ausstellerzertifikate

Serviceanweisung Austausch Globalsign Ausstellerzertifikate Serviceanweisung Austausch Globalsign Ausstellerzertifikate Version: Stand: 1.0 03.03.2014 Leipziger Straße 110, 04425 Taucha Tel.: +49 34298 4878-10 Fax.: +49 34298 4878-11 Internet: www.procilon.de E-Mail:

Mehr

Installationsanleitung für die h_da Zertifikate

Installationsanleitung für die h_da Zertifikate Zentrale Serverdienste Installationsanleitung für die h_da Zertifikate Dokumentennummer: IT-ZSD-008 Version 1.3 Stand 23.05.2013 Historie Version Datum Änderung Autor 1.0 22.10.2008 Dokument angelegt tbo

Mehr

Hochschule Mittweida. UML-Dokumenation. Franziska Frenzel [Wählen Sie das Datum aus]

Hochschule Mittweida. UML-Dokumenation. Franziska Frenzel [Wählen Sie das Datum aus] Hochschule Mittweida UML-Dokumenation Franziska Frenzel [Wählen Sie das Datum aus] Inhalt UML-Dokumenation Inhalt... 1 /PF 000/ App ausführen inkl. Tracking und UUID erstellen... 2 /PF 001/ Modus wechseln...

Mehr

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-3

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-3 Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen Agfa HealthCare GmbH Konrad-Zuse-Platz 1-3 53227 Bonn für das IT-System IMPAX/web.Access die Erfüllung aller

Mehr

A506 Backup Software. IKT-Standard. Ausgabedatum: 2015-02-03. Version: 1.13. Ersetzt: 1.12

A506 Backup Software. IKT-Standard. Ausgabedatum: 2015-02-03. Version: 1.13. Ersetzt: 1.12 Eidgenössisches Finanzdepartement EFD Informatiksteuerungsorgan des Bundes ISB A506 Backup Software Klassifizierung: Typ: Nicht klassifiziert IKT-Standard Ausgabedatum: 2015-02-03 Version: 1.13 Status:

Mehr

nachfolgende Vereinbarung zum Inhalt und zur Anwendung der elektronischen Gesundheitskarte

nachfolgende Vereinbarung zum Inhalt und zur Anwendung der elektronischen Gesundheitskarte Vereinbarung zum Inhalt und zur Anwendung der elektronischen Gesundheitskarte Stand: 1. Januar 2015 Zwischen dem GKV-Spitzenverband (Spitzenverband Bund der Krankenkassen) K.d.ö.R, Berlin und der Kassenärztlichen

Mehr

Zertifikate Exchange Server / WLAN. Referent: Marc Grote

Zertifikate Exchange Server / WLAN. Referent: Marc Grote Zertifikate Exchange Server / WLAN Referent: Marc Grote Agenda Verwendungszweck von Zertifikaten Krytografiegrundlagen Symmetrische / Asymmetrische Verschluesselungsverfahren Windows Zertifizierungsstellen

Mehr

Releasenote zur AusweisApp Version 1.13.1 RC1 (Windows) Dokumentversion 1.1

Releasenote zur AusweisApp Version 1.13.1 RC1 (Windows) Dokumentversion 1.1 Releasenote zur AusweisApp Version 1.13.1 RC1 (Windows) Dokumentversion 1.1 Inhaltsverzeichnis 1 Vorbemerkung... 2 2 Unterstützte Systeme... 2 3 Änderungen zur vorherigen Version... 5 4 Anmerkungen...

Mehr

HANDBUCH KAPITAL UND DARLEHEN

HANDBUCH KAPITAL UND DARLEHEN HANDBUCH KAPITAL UND DARLEHEN KIGST-GMBH SYSTEMHAUS DER KIRCHEN STAND: OKTOBER 2010 KIGST GmbH 2010 Seite 1 von 38 Inhalt Allgemeine Hinweise... 3 Grundlegendes... 4 Stammdaten der Kassengemeinschaft...

Mehr

Prüfspezifikation für Anforderungen (Lastenheft) für WiBe 4.0. Version: 1.3

Prüfspezifikation für Anforderungen (Lastenheft) für WiBe 4.0. Version: 1.3 -Prüfung: Prüfspezifikation Dokument- Prüfspezifikation für Anforderungen (Lastenheft) für WiBe 4.0 Version: 1.3 Projektbezeichnung Projektleiter Verantwortlich Erstellt am 11.03.2005 Zuletzt geändert

Mehr

Linux-Info-Tag Dresden - 8. Oktober 2006

Linux-Info-Tag Dresden - 8. Oktober 2006 E-Mails signieren & verschlüsseln Linux-Info-Tag Dresden - 8. Oktober 2006 1 Einleitung 1.1 Willkommen Karl Deutsch Österreich Seit 1985 im IT-Bereich Seit 1997 Linux als Desktopbetriebssystem IT Berater

Mehr

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-3

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-3 Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen RWE Effizienz GmbH Flamingoweg 1 44139 Dortmund für das IT-System RWE eoperate IT Services die Erfüllung aller

Mehr

Verschlüsselungsverfahren

Verschlüsselungsverfahren Verschlüsselungsverfahren Herrn Breder hat es nach dem Studium nach München verschlagen. Seine Studienkollegin Frau Ahrend wohnt in Heidelberg. Da beide beruflich sehr stark einspannt sind, gibt es keine

Mehr

Ingo Schubert Technical Consultant Central Europe +49 89 540 523-01 ischubert@baltimore.com

Ingo Schubert Technical Consultant Central Europe +49 89 540 523-01 ischubert@baltimore.com 1 Ingo Schubert Technical Consultant Central Europe +49 89 540 523-01 ischubert@baltimore.com 2 Baltimore auf einen Blick Weltmarktführer für e security Produkte, Service, und Lösungen Weltweite Niederlassungen

Mehr

Vorlesung IT-Sicherheit FH Frankfurt Sommersemester 2007

Vorlesung IT-Sicherheit FH Frankfurt Sommersemester 2007 Vorlesung IT-Sicherheit FH Frankfurt Sommersemester 2007 Dr. Volker Scheidemann Digitale Zertifikate Public Key Infrastrukturen (PKI) Sicherheitsprozesse Seite: 2 Gefahr bei PKC: Die Man in the Middle-Attacke

Mehr

BSI TR-03108. Sicherer E-Mail-Transport. Anforderungen an E-Mail-Diensteanbieter für einen sicheren Transport von E-Mails

BSI TR-03108. Sicherer E-Mail-Transport. Anforderungen an E-Mail-Diensteanbieter für einen sicheren Transport von E-Mails BSI TR-03108 Sicherer E-Mail-Transport Anforderungen an E-Mail-Diensteanbieter für einen sicheren Transport von E-Mails Version: 0.9 Entwurf Datum: 20.08.15 Änderungshistorie Version Datum Name Beschreibung

Mehr

Kontakt: Bundesdruckerei GmbH Oranienstraße 91, D-10969 Berlin Tel +49 (0) 30-2598-0 Fax +49 (0) 30-2598-2205 E-Mail: vertrieb@bdr.

Kontakt: Bundesdruckerei GmbH Oranienstraße 91, D-10969 Berlin Tel +49 (0) 30-2598-0 Fax +49 (0) 30-2598-2205 E-Mail: vertrieb@bdr. D-TRUST Advanced EV SSL Mit dem D-TRUST Advanced EV SSL Zertifikat erwerben sie die höchste Stufe in der SSL Sicherheit. Dieses D-TRUST SSL Zertifikat unterscheidet sich optisch von der Advanced Variante

Mehr

Elektronische Vollmachten - Demonstrator

Elektronische Vollmachten - Demonstrator www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria Elektronische Vollmachten - Demonstrator Version 1.0.0, 09.01.2007 DI

Mehr

S Kreis- und Stadtsparkasse

S Kreis- und Stadtsparkasse S Kreis- und Stadtsparkasse Kaufbeuren im September 2011 Informationen zum sicheren E-Mailverkehr Mit diesem Schreiben wollen wir Ihnen Inhalt: 1. die Gründe für die Einführung von Sichere E-Mail näher

Mehr

Freie Zertifikate für Schulen und Hochschulen

Freie Zertifikate für Schulen und Hochschulen Freie Zertifikate für Schulen und Hochschulen Dr. Thomas Bremer CAcert Inc. Public Key Kryptographie Zwei Schlüssel: ein Öffentlicher und ein Privater Damit kann man Daten verschlüsseln und digital signieren

Mehr

PKI (public key infrastructure)

PKI (public key infrastructure) PKI (public key infrastructure) am Fritz-Haber-Institut 11. Mai 2015, Bilder: Mehr Sicherheit durch PKI-Technologie, Network Training and Consulting Verschlüsselung allgemein Bei einer Übertragung von

Mehr

Sichere Identitäten in Smart Grids

Sichere Identitäten in Smart Grids Informationstag "IT-Sicherheit im Smart Grid" Berlin, 23.05.2012 Sichere Identitäten in Smart Grids Dr. Thomas Störtkuhl, Agenda 1 2 Beispiele für Kommunikationen Digitale Zertifikate: Basis für Authentifizierung

Mehr

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. "For your eyes only" Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo.

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. For your eyes only Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo. Karlsruher IT-Sicherheitsinitiative - 26. April 2001 "For your eyes only" Sichere E-Mail in Unternehmen Dr. Dörte Neundorf neundorf@secorvo.de Secorvo Security Consulting GmbH Albert-Nestler-Straße 9 D-76131

Mehr

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-5

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-5 Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen SLA Software Logistik Artland GmbH Friedrichstraße 30 49610 Quakenbrück für das IT-System Meat Integrity Solution

Mehr

Terravis - Hinweise zur Implementierung der SSL-Verbindung

Terravis - Hinweise zur Implementierung der SSL-Verbindung Terravis - Hinweise zur Implementierung der -Verbindung Version: 1.0 Datum: 19.04.2013 Autoren: Claude Eisenhut -Hinweise.docx 19.04.2013 Seite 1/8 Verzeichnis: Einführung... 3 Kontaktpersonen 3 Allgemeines...

Mehr

X.509v3 Zertifizierungsinstanz der Universität Würzburg

X.509v3 Zertifizierungsinstanz der Universität Würzburg X.509v3 Zertifizierungsinstanz der Universität Würzburg Markus Krieger Rechenzentrum Uni Würzburg ca@uni-wuerzburg.de 22.01.06 1 Notwendigkeit von Zertifikaten Steigende Anzahl von Kommunikationsbeziehungen

Mehr

Christian J. Dietrich. 9. Kryptotag

Christian J. Dietrich. 9. Kryptotag Extended Access Control (epa epa) Christian J. Dietrich 2008-11-10 9. Kryptotag Inhalt 1. Einleitung 2. Der elektronische Personalausweis 3. Die Authentisierungsfunktion im Detail 4. Kurzvorstellung der

Mehr

Anlage 1 Vertragssoftware

Anlage 1 Vertragssoftware Anlage 1 Vertragssoftware Diese Anlage 1 zum HzV-Vertrag regelt die Anforderungen an die Erstellung und Nutzung der Vertragssoftware gemäß 11 Abs. 1 Satz 1 und ihre Zulassung gemäß 11 Abs. 2 des HzV-Vertrages.

Mehr

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Andreas Armbrecht Siemens AG Darmstadt, 01. 02. Dezember 2009 Business Unit Rail Automation Systeme der Eisenbahnautomatisierung

Mehr

Rückmeldungen Empfangsprozess

Rückmeldungen Empfangsprozess Management Beratungs- und Beteiligungsgesellschaft m.b.h. V 1.12 Freigabe Rückmeldungen Empfangsprozess Ausgabe: September / 2003 Rechtliche Hinweise Microsoft, MS, MS-DOS und Windows sind Warenzeichen

Mehr

Digitales Zertifikat für die Authentifizierung

Digitales Zertifikat für die Authentifizierung Single Sign On Waisenhausgasse 36-38a 50676 Köln Tel.: +49 221 4724-1 Fax +49 221 4724-444 posteingang@dimdi.de www.dimdi.de Ansprechpartner: Helpdesk Technik Tel: +49 221 4724-270 helpdesk@dimdi.de Digitales

Mehr

emails digital signieren und verschlüsseln mit Zertifikaten

emails digital signieren und verschlüsseln mit Zertifikaten emails digital signieren und verschlüsseln mit Zertifikaten Martin Heinold, Andreas Hirsch Werdenfels-Gymnasium, Garmisch-Partenkirchen GAPONLINE Bürgernetzverein für den Landkreis Garmisch-Partenkirchen

Mehr

meine-homematic.de Benutzerhandbuch

meine-homematic.de Benutzerhandbuch meine-homematic.de Benutzerhandbuch Version 3.0 Inhalt Installation des meine-homematic.de Zugangs... 2 Installation für HomeMatic CCU vor Version 1.502... 2 Installation für HomeMatic CCU ab Version 1.502...

Mehr