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: Stand: Status: freigegeben gematik_pki_verwendung_zertifikate_der_ti_v1.1.0.doc Seite 1 von 70

2 Dokumentinformationen Änderungen zur Vorversion Inhalt der abgestimmten Änderungen: 1. Erreichbarkeit der TSL (TSL Downloadpunkt, Auflösbarkeit und Erreichbarkeit derselben Adresse aus TI und Internet) 2. der Lokalisierung des CRL-Downloadpunktes (Aus TCL in Service- SupplyPoint, ), Abrufbarkeit der Konzentrator-CRLs aus dem Internet und Anforderungen an Komponenten, die CRLs unterstützen müssen (LDAP,...). 3. Vorbedingungen für die Initialisierung des Vertrauensraums ändern, da sonst initial keine TSL ausgewertet werden kann 4. Tiefer gehende Spezifikation der Bedingung für die Bildung des Keystores (Vertrauensraum). Es dürfen nur CA-Zertifikate eingelesen werden, die den Stat s "inacc rd" besitzen. Referenzierung Die Referenzierung in weiteren Dokumenten der gematik erfolgt unter: [gemverw_zert_ti] gematik ( ): Einführung der Gesundheitskarte - Verwendung von Zertifikaten in der Telematikinfrastruktur Version 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_v1.1.0.doc Seite 2 von 70

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 gematik_pki_verwendung_zertifikate_der_ti_v1.1.0.doc Seite 3 von 70

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 AdditionalInformation 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"...26 gematik_pki_verwendung_zertifikate_der_ti_v1.1.0.doc Seite 4 von 70

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" TUC_PKI_016 "Download der TSL" TUC_PKI_017 "Lokalisierung Download-Adresse" 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_010 "Abgleich ob Zertifikatsherausgeber berechtigt ist" Weitere Prüfungen Umgang mit kritischen Extensions Bestätigte Zertifikatsinformationen TUC_PKI_007 "Unterscheidung von Zertifikatstypen (Zertifikatsbasiert)" TUC_PKI_009 "Rollenermittlung" 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 Festlegungen zur Zertifikatsprüfung bei SSL Festlegungen in den Standards Festlegungen der gematik Vorgaben zur Fehlerbehandlung...66 Anhang...67 A1 - Abkürzungen...67 gematik_pki_verwendung_zertifikate_der_ti_v1.1.0.doc Seite 5 von 70

6 A2 - Glossar...67 A3 - Abbildungsverzeichnis...67 A4 - Tabellenverzeichnis...68 A5 - Referenzierte Dokumente...68 A6 Klärungsbedarf / Offene Punkte...70 gematik_pki_verwendung_zertifikate_der_ti_v1.1.0.doc Seite 6 von 70

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, von auf viele Dokumente verteilten Informationen, 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. 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_v1.1.0.doc Seite 7 von 70

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_v1.1.0.doc Seite 8 von 70

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. Abschließend werden in Kapitel 12 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. 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. gematik_pki_verwendung_zertifikate_der_ti_v1.1.0.doc Seite 9 von 70

10 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 11 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 entsprechend der Technischen Richtlinie für ecard-projekte der Bundesregierung [BSI-TR03116] normativ vorgegeben. Die freie Auswahl aus den hier zugelassenen Algorithmen durch gematik_pki_verwendung_zertifikate_der_ti_v1.1.0.doc Seite 10 von 70

11 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 keine Vorgaben für die QES-Prüfung, hierfür sind die spezifischen Policies der Berufsständischen Organisationen, welche HBAs herausgeben, und das Verhalten der jeweiligen OCSP-Responder der ZDA 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. Formale noch offene Inhalte sind blau markiert. gematik_pki_verwendung_zertifikate_der_ti_v1.1.0.doc Seite 11 von 70

12 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.> Zugehörige Diagramme <Verweis auf das zugehörige Diagramm> gematik_pki_verwendung_zertifikate_der_ti_v1.1.0.doc Seite 12 von 70

13 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_v1.1.0.doc Seite 13 von 70

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_v1.1.0.doc Seite 14 von 70

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_v1.1.0.doc Seite 15 von 70

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_v1.1.0.doc Seite 16 von 70

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_v1.1.0.doc Seite 17 von 70

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 "Additional- Information 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 AdditionalInformation Zur Unterscheidung von Zertifikaten wird das jeweilige Kennzeichen in die Extension additionalinformation gespeichert. Der Zertifikatstyp wird als OID im Format Directory- String in das AdditionalInformation Attribut gespeichert. Die genaue Festlegung der OID wird im Dokument [gemspec_oidfestl] spezifiziert. ASN.1-Struktur nach [ISIS-MTT]: id-isismtt-at-additionalinformation OBJECT IDENTIFIER ::= AdditionalInformationSyntax ::= DirectoryString (SIZE( )) {id-isismtt-at 15} 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. Die genaue Festlegung der OID wird im Dokument [gemspec_oidfestl] 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, gematik_pki_verwendung_zertifikate_der_ti_v1.1.0.doc Seite 18 von 70

19 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_v1.1.0.doc Seite 19 von 70

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: Typen der Zertifikate aus dem zentralen Repository der gematik gematik_pki_verwendung_zertifikate_der_ti_v1.1.0.doc Seite 20 von 70

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_v1.1.0.doc Seite 21 von 70

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_v1.1.0.doc Seite 22 von 70

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 wird 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_v1.1.0.doc Seite 23 von 70

24 bedingungen jedoch nicht in jedem Fall vollständig automatisch hergestellt bzw. überprüft werden. Dies gilt für die Fälle der Die Erst-Inbetriebnahme und Die Wiederinbetriebnahme nach mehrmonatiger Nicht-Nutzung bzw. Systemwiederherstellung. Hierbei ist jedoch sicher zu stellen, dass der Vertrauensanker sicher in das System eingebracht wurde. Der Vertrauensanker der TSL kann von der Webseite des TSL-Service- Providers herunter geladen werden. Zur Verifikation der Zertifikate ist dort der Fingerprint veröffentlich. Dieser wird auch parallel per Post versandt. Organisatorisch MUSS diese Verifikation sichergestellt werden. Die OCSP-Abfrage im TUC_PKI_011 "Prüfung der Integrität des Signaturschlüssels" ist in diesen Sonderfällen auch nicht wie spezifiziert durchführbar, da die OCSP-Adresse nicht aus der TSL ermittelt werden kann. Die TSL ist zu diesem Zeitpunkt noch nicht überprüft. Zur Prüfung der TSL-Service-Provider Zertifikate MUSS in diesem Fall die statische OCSP-Adresse "http://tsl.ocsp.gematik.de verwendet werden. 8.4 Referenzierbare Use Cases Aus diesem Kapitel sind folgende Use Cases von anderen gematik Dokumenten referenzierbar: TUC_PKI_016 "Download der TSL" TUC_PKI_001 "Initialisierung Vertrauensraum" TUC_PKI_012 "XML Signatur Prüfung" TUC_PKI_013 "Bereitstellen neuer Vertrauensanker" Weitere hier nicht aufgeführte Use Cases aus diesem Kapitel dienen zur internen Strukturierung und können nicht direkt referenziert werden. 8.5 Erreichbarkeit der TSL Der Downloadpunkt der TSL ist sowohl aus dem Internet als auch aus der Telematikinfrastruktur über dieselbe Adresse auflösbar und erreichbar. Die Lokalisierung der Adresse ist in Abschnitt 8.13 detailliert beschrieben. 8.6 TUC_PKI_001 "Initialisierung Vertrauensraum" Name Anwendungsumfeld TUC_PKI_001 "Initialisierung Vertrauensraum" Dieser Use Case beschreibt den gesamten Ablauf zur Initialisierung einer TSL. Dabei verwendet er weitere TUCs, die im Laufe des Kapitels detailliert spezifiziert werden. System, das die TSL auswertet gematik_pki_verwendung_zertifikate_der_ti_v1.1.0.doc Seite 24 von 70

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.2.0 Revison: main/rel_main/21 Stand: 16.07.2008 Status: freigegeben gematik_pki_verwendung_zertifikate_der_ti.doc

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 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 Ü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

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

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

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

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

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

Ö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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Attribut Kürzel Beispiele Bemerkungen Country Name C DE bitte Großbuchstaben State or Province Name ST Nordrhein-Westfalen

Attribut Kürzel Beispiele Bemerkungen Country Name C DE bitte Großbuchstaben State or Province Name ST Nordrhein-Westfalen Erzeugen eines externen Schlüssels außerhalb des Browsers für Nutzerzertifikate Sollten bei Ihnen Abhängigkeiten zwischen ihrem privaten Schlüsselteil und verwendeter Hardware und oder Software bestehen,

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

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

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

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

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

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

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

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

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

Die angegebenen Versionsnummern beziehen sich jeweils auf die Datei DbbLxGui.exe.

Die angegebenen Versionsnummern beziehen sich jeweils auf die Datei DbbLxGui.exe. Change Log: DBB/LX Die angegebenen Versionsnummern beziehen sich jeweils auf die Datei DbbLxGui.exe. 1. Version 4.5.0.1243 1. AF: Das Tool Datenbank neu aufbauen wurde ergänzt. Damit können Datenbanken,

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

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

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

E-Mail-Verschlüsselung mit Geschäftspartnern

E-Mail-Verschlüsselung mit Geschäftspartnern E-Mail-Verschlüsselung mit (Anleitung für Siemens Mitarbeiter) 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 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

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

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

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

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

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

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

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

Software Requirements Specification

Software Requirements Specification Software Requirements Specification Identifikation von Sehenswürdigkeiten basierend auf Bildinhalten Iterationsschritt: 3 Abgabedatum: 08.06.2010 Gruppe 37: Matthias Hochsteger 0627568 Josef Kemetmüller

Mehr

Anwenderdokumentation AccountPlus GWUPSTAT.EXE

Anwenderdokumentation AccountPlus GWUPSTAT.EXE AccountPlus Inhaltsverzeichnis Inhaltsverzeichnis Anwenderdokumentation AccountPlus GWUPSTAT.EXE (vorläufig) ab Version 6.01 INHALTSVERZEICHNIS...1 1 ALLGEMEINES...2 2 INSTALLATION UND PROGRAMMAUFRUF...2

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

Bedienerhandbuch. TCO-Inventar. Netzwerk Scanner

Bedienerhandbuch. TCO-Inventar. Netzwerk Scanner Bedienerhandbuch TCO-Inventar Netzwerk Scanner Zimmer IT-Solution Am Hart 9f 85375 Neufahrn Tel.: 08165 / 6476443 Fax.: 08165 / 6476445 www.zimmer-it-solution.de Inhaltsverzeichnis 1 Der Inventar-Scanner...4

Mehr

BAYERISCHES STAATSMINISTERIUM DES INNERN

BAYERISCHES STAATSMINISTERIUM DES INNERN BAYERISCHES STAATSMINISTERIUM DES INNERN Bayer. Staatsministerium des Innern 80524 München Einsatznachbearbeitung und vermeintlicher Zertifikatfehler unter Internet Explorer bzw. Mozilla Firefox Bei sicheren

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

Installationshandbuch für den DAKOSY J Walk Windows Client

Installationshandbuch für den DAKOSY J Walk Windows Client Installationshandbuch für den DAKOSY J Walk Windows Client Version 1.1 DAKOSY Datenkommunikationssystem AG Mattentwiete 2 20457 Hamburg Telefon: 040 370 03 0 Fax: - 370 Erstellt von : Jan Heins Geprüft

Mehr

Die elektronische Gesundheitskarte

Die elektronische Gesundheitskarte Die elektronische Gesundheitskarte und ihre Anwendung im Gesundheitswesen Die egk als Schlüssel zur Sicherheit für den Patienten in der Telematikinfrastruktur Tel.: 0271/708-1607 Rainer.Moos@T-Systems.com

Mehr

Ausarbeitung zum Referat. Public - Key Infrastruktur mit OpenSSL / OpenCA

Ausarbeitung zum Referat. Public - Key Infrastruktur mit OpenSSL / OpenCA Ausarbeitung zum Referat Public - Key Infrastruktur mit OpenSSL / OpenCA von Christiane Hein (Matr.Nr. 192215) und Madlen Behlert (Matr.Nr. 148495) Vorlesung: Seminar Informationstechnik Dozent: Herr Prof.

Mehr

Anforderungen an elektronische Signaturen. Michel Messerschmidt

Anforderungen an elektronische Signaturen. Michel Messerschmidt Anforderungen an elektronische Signaturen Michel Messerschmidt Übersicht Kryptographische Grundlagen Rechtliche Grundlagen Praxis Michel Messerschmidt, 2006-03-16 2 Kryptographische Grundlagen Verschlüsselung

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

Versionsdokumentation 8.41sp4134 "SEPA-Version"

Versionsdokumentation 8.41sp4134 SEPA-Version Versionsdokumentation 8.41sp4134 "SEPA-Version" Stand 20.01.2014 In dieser Version sind die Änderungen zur SEPA-Einführung zum 1.2.2014 enthalten. Mit der SEPA-Einführung werden die bisher üblichen Kontonummern

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation Softwareentwicklungspraktikum Sommersemester 2007 Testdokumentation Auftraggeber Technische Universität Braunschweig

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

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