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

PKI für X.509-Zertifikate. Registrierung eines Trust Service Provider (TSP)

PKI für X.509-Zertifikate. Registrierung eines Trust Service Provider (TSP) Einführung der Gesundheitskarte PKI für X.509-Zertifikate Registrierung eines Trust Service Provider Version: 1.2.0 Stand: 19.03.2008 Status: freigegeben gematik_pki_x.509_registrierung_tsp_v1_2_0.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 X.509- Komponentenzertifikaten der Server- und (Fach-) Dienste

Festlegungen zu den X.509- Komponentenzertifikaten der Server- und (Fach-) Dienste Einführung der Gesundheitskarte Festlegungen zu den X.509- Komponentenzertifikaten der Server- und (Fach-) Dienste Version: 1.3.0 Revision: main/rel_main/20 Stand: 03.07.2008 Status: freigegeben OID: 1.2.276.0.76.4.63

Mehr

Funktionale Spezifikation der OCSP Responder für die PKI der e-arztausweise Version 2.3.2

Funktionale Spezifikation der OCSP Responder für die PKI der e-arztausweise Version 2.3.2 Seite 1 von 9 Funktionale Spezifikation der der e-arztausweise Version Bundesärztekammer, Berlin Identifikation des Dokuments: Funktionale Spezifikation der, Bundesärztekammer Revisions-Datum.: 12.05.2011

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

Zulassung Produkte der Telematikinfrastruktur hier: gematik Root-CA

Zulassung Produkte der Telematikinfrastruktur hier: gematik Root-CA Einführung der Gesundheitskarte Verfahrensbeschreibung Zulassung Produkte der Version: 1.0.0 Revision: \main\17 Stand: 15.05.2014 Status: freigegeben Klassifizierung: öffentlich Referenzierung: [gemzul_prod_x509root]

Mehr

PKI für CV-Zertifikate

PKI für CV-Zertifikate Einführung der Gesundheitskarte PKI für CV-Zertifikate Version: 1.4.0 Stand: 19.03.2008 Status: freigegeben gematik_pki_cv-zertifikate V1.4.0.doc Seite 1 von 33 Dokumentinformationen Änderungen zur Version

Mehr

PKI für das Signieren von Konfigurationsdaten und

PKI für das Signieren von Konfigurationsdaten und Einführung der Gesundheitskarte PKI für das Signieren von Konfigurationsdaten und Version: 1.1.0 Revision: main/rel_main/21 Stand: 01.07.2008 Status: freigegeben gematik_pki_x 509 Signieren.doc Seite 1

Mehr

SRQ - Specification Related Question

SRQ - Specification Related Question SRQ-ID: 1202 Betrifft: Themenkreis PKI und Zertifikate Schlagwort zu Dokument / Datei (evtl. ersetzt SRQ) [gemx.509_tsp] Version 1.2.0 Bezug (Kap., Abschnitt, Tab., Abb.) 4.2.1, 5.2.1, 5.2.3, 5.2.6, 5.3.1,

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 die Erfüllung

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

Sicherheit der Komponenten der Telematik-Infrastruktur

Sicherheit der Komponenten der Telematik-Infrastruktur Sicherheit der Komponenten der Telematik-Infrastruktur IT - Sicherheit im Gesundheitswesen Regelungen und Maßnahmen für eine sichere TI im Zuge der Einführung der egk ( BSI ) Bundesamt für Sicherheit in

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

Public Key Infrastructure (PKI) Funktion und Organisation einer PKI

Public Key Infrastructure (PKI) Funktion und Organisation einer PKI Public Key Infrastructure (PKI) Funktion und Organisation einer PKI Übersicht Einleitung Begriffe Vertrauensmodelle Zertifikatswiderruf Verzeichnisse Inhalt eines Zertifikats 29.10.2003 Prof. Dr. P. Trommler

Mehr

Maintenance & Re-Zertifizierung

Maintenance & Re-Zertifizierung Zertifizierung nach Technischen Richtlinien Maintenance & Re-Zertifizierung Version 1.2 vom 15.06.2009 Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 22899 9582-0

Mehr

(Text von Bedeutung für den EWR)

(Text von Bedeutung für den EWR) 9.9.2015 L 235/37 DURCHFÜHRUNGSBESCHLUSS (EU) 2015/1506 R KOMMISSION vom 8. September 2015 zur Festlegung von Spezifikationen für Formate fortgeschrittener elektronischer Signaturen und fortgeschrittener

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 Festlegungen zu den X.509 Zertifikaten der Versicherten

Einführung der Gesundheitskarte Festlegungen zu den X.509 Zertifikaten der Versicherten Einführung der Gesundheitskarte Festlegungen zu den X.509 Zertifikaten der Versicherten Version: 1.0.0 Stand: 12.12.2005 Status: freigegeben gematik_pki_x509_zertifikate_egk_v1.0.0.doc Seite 1 von 14 Dokumentinformationen

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

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

Netzsicherheit I, WS 2008/2009 Übung 12. Prof. Dr. Jörg Schwenk 20.01.2009

Netzsicherheit I, WS 2008/2009 Übung 12. Prof. Dr. Jörg Schwenk 20.01.2009 Netzsicherheit I, WS 2008/2009 Übung 12 Prof. Dr. Jörg Schwenk 20.01.2009 Aufgabe 1 1 Zertifikate im Allgemeinen a) Was versteht man unter folgenden Begriffen? i. X.509 X.509 ist ein Standard (Zertifikatsstandard)

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

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

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

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

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

Signatur-Workshop. Neue Signaturformate und ausländische Zertifikate in MOA-SPSS. Klaus Stranacher Wien, 05.12.2013

Signatur-Workshop. Neue Signaturformate und ausländische Zertifikate in MOA-SPSS. Klaus Stranacher Wien, 05.12.2013 Signatur-Workshop Neue Signaturformate und ausländische Zertifikate in MOA-SPSS Wien, 05.12.2013 Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU Graz

Mehr

PKI für die X.509 Zertifikate

PKI für die X.509 Zertifikate Einführung der Gesundheitskarte PKI für die X.509 Zertifikate Version: 1.3.0 Revision: main/rel_main/12 Stand: 18.06.2008 Status: freigegeben gematik_pki-_x509-zertifikate.doc Seite 1 von 28 Dokumentinformationen

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

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

Verfahrensgrundlage Vergabe von Registrierungskennzahlen für Informationsobjekte

Verfahrensgrundlage Vergabe von Registrierungskennzahlen für Informationsobjekte Verfahrensgrundlage Vergabe von Registrierungskennzahlen für Informationsobjekte März 2006 Version 1.0 Inhaltsverzeichnis 1 Anwendungsbereich... 3 2 Ziel und Zweck des Registers... 3 3 Mitteilungspflicht

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

Die Telematikinfrastruktur als sichere Basis im Gesundheitswesen

Die Telematikinfrastruktur als sichere Basis im Gesundheitswesen Die Telematikinfrastruktur als sichere Basis im Gesundheitswesen conhit Kongress 2014 Berlin, 06.Mai 2014 Session 3 Saal 3 Gesundheitsdaten und die NSA Haben Patienten in Deutschland ein Spionageproblem?

Mehr

A-CERT Certificate Policy

A-CERT Certificate Policy ARGE DATEN A-CERT Certificate Policy [gültig für Stamm-Zertifikate für einfache und fortgeschrittene Signaturen] Version 1.3/Juli 2009 - a-cert-company-policy.doc OID-Nummer: 1.2.40.0.24.1.1.2.1 Gültigkeitshistorie

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

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

Methode zur Dokumentation der Berechtigungen in der Telematikinfrastruktur

Methode zur Dokumentation der Berechtigungen in der Telematikinfrastruktur Einheitliche Methoden der Informationssicherheit Methode zur Dokumentation der Berechtigungen in der Telematikinfrastruktur Version: 1.1.0 Revision: \main\rel_online\17 Stand: 30.05.2013 Status: freigegeben

Mehr

Elektronischer Zahnarztausweis

Elektronischer Zahnarztausweis Elektronischer Policy Version 1.0 Bundeszahnärztekammer, 17.12.2012 Object-Identifier (OID) 1.2.276.0.76.4.147 2 / 11 AUTOREN: Jochen Gottsmann, BZÄK Dokumentvariablen ÄNDERUNGSHISTORIE Datum Version Autor

Mehr

smis_secure mail in der srg / pflichtenheft /

smis_secure mail in der srg / pflichtenheft / smis_secure mail in der srg / pflichtenheft / Dok.-Nr: Version: 1.1 PH.002 Status: Klassifizierung: Autor: Verteiler: Draft Erik Mulder, Thanh Diep Erik Mulder, Thanh Diep Pflichtenheft, Seite 2 / 2 Änderungskontrolle

Mehr

SRQ - Specification Related Question

SRQ - Specification Related Question SRQ-ID: 1204 Betrifft: Themenkreis Schlagwort zu Dokument / Datei (evtl. ersetzt SRQ) PKI und Zertifikate Welche Auswirkungen haben notwendige Aktualisierungen auf die Spezifikation? gemx.509_egk, ersetzt

Mehr

OSCI-Transport 1.2 Korrigenda 05/2011 Status: Entwurf OSCI Leitstelle

OSCI-Transport 1.2 Korrigenda 05/2011 Status: Entwurf OSCI Leitstelle OSCI-Transport 1.2 Korrigenda 05/2011 Status: Entwurf OSCI Leitstelle Bremen, 3. Februar 2011 OSCI-Transport 1.2 Korrigenda vom 3.5.2011 Seite 2 Inhaltsverzeichnis 1 Einleitung... 3 1.1 Anlass der Korrigenda...

Mehr

Kartenanforderung einstellen

Kartenanforderung einstellen Anwendungsfall: Beschreibung: Ausloeser: Ergebnisse: einstellen Ein Versicherter benötigt eine Ersatzkarte. Mögliche Gründe sind z.b. Verlust oder Unbrauchbarkeit der Karte. Der Mitarbeiter stellt eine

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

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

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

Signaturprüfbericht für qualifizierte Signaturen

Signaturprüfbericht für qualifizierte Signaturen Seite: 1 von 5 Signaturprüfbericht für qualifizierte Signaturen Prüfprotokoll nach 17 Abs. 2 Signaturgesetz (SigG) 1. Zusammenfassung der Prüfergebnisse Signaturprüfung: Erfolgreich Datei: muster-rechnung_signiert.pdf

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

Signatur- und Zertifikatsprüfung in der Praxis

Signatur- und Zertifikatsprüfung in der Praxis Signatur- und Zertifikatsprüfung in der Praxis ADV Tagung Elektronische Signatur Der Weg in die Praxis 21.11.2006 Zentrum für sichere Informationstechnologie - Austria Agenda Grundlagen zur Signaturprüfung

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

Bei falscher Zuordnung: Verlust der Vertraulichkeit. Bei falscher Zuordnung: Verlust der Datenauthentizität

Bei falscher Zuordnung: Verlust der Vertraulichkeit. Bei falscher Zuordnung: Verlust der Datenauthentizität Vorlesung am 12.05.2014 7 Vertrauensmodelle Problem: Zuordnung eines Schlüssels zum Schlüsselinhaber Beispiel 1: Verschlüsselung mit pk, Entschlüsselung mit sk: Bei falscher Zuordnung: Verlust der Vertraulichkeit

Mehr

2. Konfiguration der Adobe Software für die Überprüfung von digitalen Unterschriften

2. Konfiguration der Adobe Software für die Überprüfung von digitalen Unterschriften 1. Digital signierte Rechnungen Nach 11 Abs. 2 zweiter Unterabsatz UStG 1994 gilt eine auf elektronischem Weg übermittelte Rechnung nur dann als Rechnung im Sinne des 11 UStG 1994, wenn die Echtheit der

Mehr

Elektronische Signaturen. LANDRATSAMT BAUTZEN Innerer Service EDV

Elektronische Signaturen. LANDRATSAMT BAUTZEN Innerer Service EDV Elektronische Signaturen Rechtsrahmen Signaturgesetz (SigG) Signaturverordnung (SigV) Bürgerliches Gesetzbuch (BGB), 125 ff. über die Formen von Rechtsgeschäften Verwaltungsverfahrensgesetz (VwVfG), 3a

Mehr

Sicherheitstechnische Qualifizierung (SQ), Version 9.0

Sicherheitstechnische Qualifizierung (SQ), Version 9.0 Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen RWE Effizienz GmbH Freistuhl 7 44137 Dortmund für den Webshop RWE SmartHome Shop die Erfüllung aller Anforderungen

Mehr

Definition der Schnittstelle zur Übertragung der. gemäß Deponieselbstüberwachungsverordnung NRW

Definition der Schnittstelle zur Übertragung der. gemäß Deponieselbstüberwachungsverordnung NRW Jahresberichte gemäß Deponieselbstüberwachungsverordnung NRW Inhaltsverzeichnis... 1 Historie der Änderungen... 2 Einleitung... 2 Rückblick... 2 Auswirkungen der neuen Verordnung... 2 Auslieferung... 2

Mehr

Aktuelles von der gematik: Testvorbereitungen

Aktuelles von der gematik: Testvorbereitungen Aktuelles von der gematik: Testvorbereitungen Benno Herrmann Leiter Unternehmenskommunikation und Marketing gematik Gesellschaft für Telematikanwendungen der Gesundheitskarte mbh Friedrichstraße 136 10117

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

Whitepaper. EDIFACT-Signatur-, Verschlüsselungs- und Mailcockpit

Whitepaper. EDIFACT-Signatur-, Verschlüsselungs- und Mailcockpit Whitepaper EDIFACT-Signatur-, Verschlüsselungs- und Mailcockpit Funktionsumfang: Plattform: Verschlüsselung, Signierung und email-versand von EDIFACT-Nachrichten des deutschen Energiemarktes gemäß der

Mehr

Beantragen und installieren eines Nutzerzertifikats der CA HS-Bochum - Basic

Beantragen und installieren eines Nutzerzertifikats der CA HS-Bochum - Basic CAMPUS IT DEPARTMENT OF INFORMATION TECHNOLOGY Beantragen und installieren eines Nutzerzertifikats der CA HS-Bochum - Basic Seite 1 Ein Dokument der Campus IT Hochschule Bochum Stand 12.2013 Version 0.02

Mehr

1 Allgemeines... 2 2 Initialisierung... 2 3 Zertifikatserzeugung... 4

1 Allgemeines... 2 2 Initialisierung... 2 3 Zertifikatserzeugung... 4 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 Bedienungsanleitung Fremd-bPK-CA Dipl.-Ing. Mario Ivkovic Graz, am 24.

Mehr

Sonstige Marktregeln Gas

Sonstige Marktregeln Gas Sonstige Marktregeln Gas Kapitel 7 Elektronischer Austausch von Netzabrechnungsdaten Marktregeln Gas 2013 Version 1.0 Dokument-Historie Version Release Veröffentlichung Inkrafttreten Anmerkungen 1 0 20.09.2013

Mehr

Kartenmanagement egk. Facharchitektur

Kartenmanagement egk. Facharchitektur Einführung der Gesundheitskarte Kartenmanagement egk Version: 1.6.0 Revision: main/rel_main/8 Stand: 07.07.2008 Status: freigegeben gematik_cms Kartenmanagement_eGK.doc Seite 1 von 81 Dokumentinformationen

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

Use Cases. Use Cases

Use Cases. Use Cases Use Cases Eigenschaften: Ein Use Case beschreibt einen Teil des Verhaltens eines Systems aus externer Sicht (Formuliert in der der Fachsprache der Anwendung) Dies geschieht, indem ein Systemdialog beschrieben

Mehr

Dok.-Nr.: Seite 1 von 6

Dok.-Nr.: Seite 1 von 6 Logo Apotheke Planung, Durchführung und Dokumentation von QM-Audits Standardarbeitsanweisung (SOP) Standort des Originals: Dok.-Nr.: Seite 1 von 6 Nummer der vorliegenden Verfaßt durch Freigabe durch Apothekenleitung

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

GRUNDLAGEN TECHNIK UND METHODEN. Prof. Dr. Norbert Pohlmann, Malte Hesse. Zertifizierungshierarchie und Vertrauensmodelle

GRUNDLAGEN TECHNIK UND METHODEN. Prof. Dr. Norbert Pohlmann, Malte Hesse. Zertifizierungshierarchie und Vertrauensmodelle Prof. Dr. Norbert Pohlmann, Malte Hesse Kryptographie: Von der Geheimwissenschaft zur alltäglichen Nutzanwendung (VII) Vertrauensmodelle von Public-Key-Infrastrukturen Im letzten Artikel haben wir PKI-Infrastrukturen

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

r die Anbindung an die Telematikinfrastruktur

r die Anbindung an die Telematikinfrastruktur Start: Die Institutionenkarte (SMC) Voraussetzung fürf r die Anbindung an die Telematikinfrastruktur IT-Trends Trends Medizin Health Telematics 6.September 2007 Dr.Harald Ahrens SignCard GmbH & Co KG 1

Mehr

IT-Sicherheit Kapitel 5 Public Key Infrastructure

IT-Sicherheit Kapitel 5 Public Key Infrastructure IT-Sicherheit Kapitel 5 Public Key Infrastructure Dr. Christian Rathgeb Sommersemester 2014 1 Einführung Problembetrachtung: Alice bezieht den Public Key von Bob aus einem öffentlichen Verzeichnis, verschlüsselt

Mehr

TeleTrusT Bundesverband IT-Sicherheit e.v. Der IT-Sicherheitsverband. Selbsterklärung. zur Teilnahme an der TeleTrusT European Bridge CA

TeleTrusT Bundesverband IT-Sicherheit e.v. Der IT-Sicherheitsverband. Selbsterklärung. zur Teilnahme an der TeleTrusT European Bridge CA TeleTrusT Bundesverband IT-Sicherheit e.v. Der IT-Sicherheitsverband. Selbsterklärung zur Teilnahme an der TeleTrusT European Bridge CA Informationen zum Dokument Version 2.5 17.07.2014 TeleTrusT Bundesverband

Mehr

Vertrag zur Integrierten Versorgung in der Rheumatologie gemäß 140 a SGB V Anlage 17

Vertrag zur Integrierten Versorgung in der Rheumatologie gemäß 140 a SGB V Anlage 17 Diese Anlage 17 regelt die Anforderungen an die Erstellung und Nutzung der Vertragssoftware und ihre Zulassung gemäß 15 des Vertrages. Sie wird durch fortlaufende nach Maßgabe von 4 dieser Anlage 17 aktualisierte

Mehr

Public Key Infrastrukturen (PKI)

Public Key Infrastrukturen (PKI) IT-Sicherheit heute - Angriffe, Schutzmechanismen, Umsetzung Public Key Infrastrukturen (PKI) safuat.hamdy@secorvo.de Seite1 Inhalt Komponenten einer PKI Zertifikate PKI-Anwendungen Zusammenfassung Seite2

Mehr

Digitale Signaturen. im Kontext der Biometrie. Thomas Kollbach kollbach@informatik.hu-berlin.de

Digitale Signaturen. im Kontext der Biometrie. Thomas Kollbach kollbach@informatik.hu-berlin.de Digitale Signaturen im Kontext der Biometrie Thomas Kollbach kollbach@informatik.hu-berlin.de 2005 Veröffentlicht (mit Ausnahme der Bilder) unter einer Creative Commons Lizenz Details siehe http://creativecommons.org/licenses/by-nc-sa/2.0/de/

Mehr

Inhalt Einleitung 2 Anmeldung 3 Oberfläche und Bedienung Bearbeitungsablauf 12

Inhalt Einleitung 2 Anmeldung 3 Oberfläche und Bedienung Bearbeitungsablauf 12 Inhalt Einleitung 2 Anmeldung 3 Neues Konto anmelden 3 Passwort vergessen? 4 Oberfläche und Bedienung 5 Projektbereiche 5 Startseite 6 Übersicht 6 Probleme anzeigen 7 Probleme eingeben 10 Änderungsprotokoll

Mehr

egk: Einsatz einer Trust-service Status List in der Telematikinfrastruktur

egk: Einsatz einer Trust-service Status List in der Telematikinfrastruktur Wolfgang Schwab egk: Einsatz einer Trust-service Status List in der Telematikinfrastruktur Zukünftig soll das deutsche Gesundheitswesen mittels einer Telematikinfrastruktur digital, sektorübergreifend

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

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 e-netz Südhessen GmbH & Co. KG Dornheimer Weg 24 64293 Darmstadt für das IT System Querverbundleitstelle Darmstadt

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

Verzeichnisdienstkonzept

Verzeichnisdienstkonzept Einführung der Gesundheitskarte Verzeichnisdienstkonzept der gematik- Version: 1.2.0 Revision: main/rel_main/24 Stand: 15.07.2008 Status: freigegeben gematik_pki_verzeichnisdienstkonzept.doc Seite 1 von

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

Public-Key-Infrastrukturen

Public-Key-Infrastrukturen TECHNISCHE UNIVERSITÄT DARMSTADT FACHGEBIET THEORETISCHE INFORMATIK DR. ALEXANDER WIESMAIER PROF. DR. J. BUCHMANN J. BRAUN 8. Übung zur Vorlesung Public-Key-Infrastrukturen Sommersemester 2014 Aufgabe

Mehr

Kryptografische Verfahren für sichere E-Mail

Kryptografische Verfahren für sichere E-Mail Kryptografische Verfahren für sichere Roadshow Sicheres Internet Prof. Dr. Christoph Karg Hochschule Aalen Studiengang Informatik 28. November 2013 Kommunikation Prof. Dr. Christoph Karg Kryptografische

Mehr

Sonstige Marktregeln

Sonstige Marktregeln Sonstige Marktregeln Kapitel 7 Elektronischer Austausch von Netzabrechnungsdaten Version 1.4 Dokument-Historie Version Release Veröffentlichung Inkrafttreten Anmerkungen 1 0 31.08.2007 01.11.2007 Erstversion

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

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

Sicherheitsbestätigung und Bericht. T-Systems. 03188.SE.06.2007. Zertifizierungsdiensteanbieter Bundesnotarkammer

Sicherheitsbestätigung und Bericht. T-Systems. 03188.SE.06.2007. Zertifizierungsdiensteanbieter Bundesnotarkammer Sicherheitsbestätigung und Bericht T-Systems. 03188.SE.06.2007 Zertifizierungsdiensteanbieter Bundesnotarkammer Bestätigung für die Umsetzung von Sicherheitskonzepten gemäß 15 Abs. 2 Gesetz über Rahmenbedingungen

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

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

multisign Signatur-Prüfwerkzeug Handbuch Security Networks AG Stand: 24.06.05

multisign Signatur-Prüfwerkzeug Handbuch Security Networks AG Stand: 24.06.05 multisign Signatur-Prüfwerkzeug Handbuch Security Networks AG multisign Signatur Prüfwerkzeug Benutzerhandbuch 1 1 Einleitung Die multisign-produktfamilie ermöglicht die automatische Erstellung qualifizierter

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

Hinweis 1781277 - B2A: Fehlersuche BusinessConnector LStA, LStB, ELStAM

Hinweis 1781277 - B2A: Fehlersuche BusinessConnector LStA, LStB, ELStAM Hinweissprache: Deutsch Version: 1 Gültigkeit: gültig seit 29.10.2012 Zusammenfassung Symptom Der Hinweis bezieht sich auf die Lohnsteueranmeldung(LStA), Lohnsteuerbescheinigung(LStB) und die elektronische

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

Signaturprüfbericht für qualifizierte Signaturen Prüfprotokoll nach 17 Abs. 2 Signaturgesetz (SigG)

Signaturprüfbericht für qualifizierte Signaturen Prüfprotokoll nach 17 Abs. 2 Signaturgesetz (SigG) Seite: 1 von 5 Signaturprüfbericht für qualifizierte Signaturen Prüfprotokoll nach 17 Abs. 2 Signaturgesetz (SigG) 1. Zusammenfassung der Prüfergebnisse Signaturprüfung: Erfolgreich Datei: test_m_sig_2.pdf

Mehr

Spezifikation für Testkarten (egk, HBA, (g)smc) der Generation 2

Spezifikation für Testkarten (egk, HBA, (g)smc) der Generation 2 Einführung der Gesundheitskarte Spezifikation für Testkarten Version: 1.0.0 Revision: \main\rel_online\22 Status: freigegeben Klassifizierung: öffentlich Referenzierung: [gemspec_tk] gemspec_tk_v1.0.0.doc

Mehr

10 W-Fragen im Umgang mit elektronischen Rechnungen (erechnung)

10 W-Fragen im Umgang mit elektronischen Rechnungen (erechnung) Version 2.0 Mentana- Claimsoft GmbH Seite 2 10 W-Fragen im Umgang mit 1. Wieso kann ich eine erechnung nicht einfach ausdrucken? 2. Wieso kann ich eine erechnung nicht einfach ausdrucken? 3. Warum muss

Mehr

Kurzanleitung Umschlüsselungstool

Kurzanleitung Umschlüsselungstool Eidgenössisches Departement für Verteidigung, Bevölkerungsschutz und Sport VBS Schweizer Armee Führungsunterstützungsbasis FUB Bern, 31. Oktober 2014 Kurzanleitung Umschlüsselungstool 1 Wann braucht es

Mehr

Lenkung von Dokumenten

Lenkung von Dokumenten Beispiel Verfahrensanweisung Dok.-Nr. 1.8.2 Lenkung von Dokumenten Revision 0 erstellt am 11.02.2010 Seite 1 von 5 Ziel und Zweck: In den betrieblichen Vorgabedokumenten werden Handlungs- oder Verhaltensweisen

Mehr