PKI für das System und Service

Größe: px
Ab Seite anzeigen:

Download "PKI für das System und Service"

Transkript

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

2 Dokumentinformationen Änderungen zur Vorversion Die zunächst in Kap. 4.3 angeführten Zertifikatsprofile werden im Dokument Festlegungen zu den X.509-Komponentenzertifikaten der Server und (Fach-) Dienste [gemx.509_sd] definiert und demzufolge hier gestrichen. In den Abschnitten 4.3.2, und wurden Formulierungen an andere PKI-Dokumente angepasst. Die Bezeichnungen der Zertifikate, technischen Rollen und Zertifikatstypen wurden an die neuen Vorgaben angepasst. Der offene Punkt bezüglich Suspendierung der Zertifikate wurde entfernt, da diese Funktion erforderlich ist. Der Zertifikatstyp wird nun in der Extension CertificatePolicy kodiert. Die Extension AdditionalInformation wurde gestrichen. In Anhang A2 wird jetzt verbindlich vorgegeben, dass die Zulassungsanforderungen für TSPs um die Berücksichtigung der Vorgaben aus gemsysslm erweitert werden. Inhaltliche Änderungen gegenüber der letzten freigegebenen Version sind gelb markiert. Sofern ganze Kapitel bzw. Abschnitte eingefügt wurden, wurde zur besseren Lesbarkeit lediglich die Überschrift durch gelbe Markierung hervorgehoben. Referenzierung Die Referenzierung in weiteren Dokumenten der gematik erfolgt unter: [gempki_mon] gematik: Einführung der Gesundheitskarte - PKI für das System und Service Level Monitoring () Dokumentenhistorie Version Stand Kap./ Seite Grund der Änderung, besondere Hinweise Bearbeitung Neuerstellung gematik, AG AG8-interne QS gematik, AG AG8-interne QS durch SSLM gematik, AG Kap. 5 Inhalt eingefügt gematik, AG Monitoring für einen OCSP-Responder überarbeitet Abb. 1 an neue Version [gemsysslm] angepasst gematik, AG8 gematik, AG8 gematik_pki_x 509_SSL_Monitoring.doc Seite 2 von 42

3 Version Stand Kap./ Seite Grund der Änderung, besondere Hinweise Einarbeitung Kommentare gematik-qs altes Kapitel 5 in neues Dok. ausgelagert Bearbeitung gematik, AG Formale Überprüfung gematik QS Einarbeitung Kommentare QS gematik, AG Abs. 2.5 an abgestimmte Formulierung angepasst. Extensionen Admission und Additional- Information zum Zertifikatsprofil hinzugefügt. Liste der Referenzen ergänzt. SPE/ZD freigegeben gematik OID-Referenzen für Rolle und Zertifikatstyp gemäß [gemspec_oid] angepasst und Inhalt common name im Zertifikat in Angabe des FQDN geändert formelle Überarbeitung QM SPE/ZD Einarbeitung Reviewergebnisse SPE/ZD freigegeben gematik Anpassungen Zertifikatstypen, Rollen und Extensions Einarbeitung Reviewergebnisse Kapitel 4.3 stark vereinfacht Anhang A3 aufgenommen SPE/ZD SPE/ZD freigegeben gematik gematik_pki_x 509_SSL_Monitoring.doc Seite 3 von 42

4 Inhaltsverzeichnis Dokumentinformationen...2 Inhaltsverzeichnis Zusammenfassung Einführung Zielsetzung und Einordnung des Dokuments Zielgruppe Geltungsbereich Arbeitsgrundlagen Abgrenzung des Dokuments Methodik Verwendung von Schüsselworten Hinweis auf offene Punkte Anforderungen PKI für das System und Service Level Monitoring Grundlagen Vertrauensmodell Zertifikatsaufbau Festlegungen zur Definition der Betreiber- bzw. gematik-identität Übersicht: Attribute im SubjectDN (X.509-Zertifikat für MON) Nutzung der Attribute im SubjectDN Aufbau der serialnumber im Feld SubjectDN Aufbau des gesamten SubjectDN Notwendige Zertifikatsfelder Kennzeichnung von Rollen in Extension Admission Extension Kennzeichnung von Angaben zum Zertifikatstyp in der Extension CertificatePolicy Zertifikatsprofile Zertifikat für einen Betreiber bzw. für die gematik (C.MGMTSS.SSL) CA-Zertifikat der CA-MON (C.MGMTSS.CA) Umgang mit den Zertifikaten für das Monitoring Registrierung/Zertifikatsgenerierung Registrierung der Betreiber und Information des TSP Ausstellen eines X.509-Zertifikats für Monitoring Nutzen/Verifizieren der Zertifikate Suspendieren, Desuspendieren bzw. Sperren der Zertifikate...30 gematik_pki_x 509_SSL_Monitoring.doc Seite 4 von 42

5 4.5 Verzeichnisdienste der CA-MON Vorgaben für die Policy der CA-MON Produktiv-/Test-CA-MON...33 Anhang A...34 A1 Monitoring für einen Broker...34 A2 Monitoring für einen OCSP-Responder...37 A3 Im Rahmen des Monitoring verwendete Rollen...38 Anhang B...39 B1 Abkürzungen...39 B2 Glossar...39 B3 Abbildungsverzeichnis...39 B4 Tabellenverzeichnis...39 B5 Referenzierte Dokumente...40 B6 Klärungsbedarf...41 gematik_pki_x 509_SSL_Monitoring.doc Seite 5 von 42

6 1 Zusammenfassung Für das System und Service Level Monitoring der Komponenten der Telematikinfrastruktur sammeln und verarbeiten die Betreiber der dezentralen Services die benötigten Daten in ihren eigenen Managementsystemen. Teile dieser Daten müssen aber für eine zentrale Überwachung und Darstellung der Performanz und Verfügbarkeit der dezentralen Services an das zentrale Managementsystem der gematik übermittelt werden. Der Austausch dieser Daten geschieht dabei nicht über das Netzwerk der Telematikinfrastruktur, sondern über ein gesondertes Management-VPN. Die Betreiber der dezentralen Services und die gematik implementieren zu diesem Zweck eine einheitliche Managementschnittstelle gemäß den Vorgaben aus [gemsysslm]. Hinweis: Der Begriff "dezentrale Services" wird in diesem Dokument, wie in [gem- SysSLM] definiert in seiner ursprünglichen allgemeinen Bedeutung verwendet und nicht in der engeren Definition aus [gemgesarch]. Für den Datenaustausch über das Management-VPN müssen sich die Kommunikationspartner gegenseitig authentisieren. Zu diesem Zweck erhalten alle Betreiber dezentraler Services und die gematik spezielle X.509-Zertifikate. Diese Zertifikate werden durch eine spezielle CA (CA-MON) ausgestellt. Die gematik wird nach einer Ausschreibung einen TSP mit dem Betrieb dieser CA beauftragen. Die Anforderungen an die PKI für die Zertifikate des System und Service Level Monitoring sind im Wesentlichen vergleichbar zu den Anforderungen an die PKI für die Komponentenzertifikate der Server und (Fach-) Dienste (siehe [gemx.509_sd]). Aufgrund der sehr einfachen Kommunikationsstruktur über das Management-VPN können die Anforderungen an die PKI (und damit die Anforderungen an den TSP bezüglich des Betriebs der CA- MON) aber zum Teil vereinfacht werden. So ist zum Beispiel eine OCSP-Abfrage im Rahmen des Verifizierens eines Zertifikats nicht notwendig, d. h. der TSP muss für die Zertifikate für das System und Service Level Monitoring keinen OCSP-Responder zur Verfügung stellen. Das vorliegende Dokument enthält in Kap. 4 neben der Festlegung des Aufbaus der X.509-Zertifikate für das System und Service Level Monitoring (im Sinne eines s) die Beschreibung der vereinfachten Anforderungen für einen TSP für den Betrieb der CA-MON. Beschrieben werden u. a. das Zusammenspiel zwischen gematik und TSP bei der Registrierung der Betreiber und bei dem Generieren der Zertifikate, Vorgaben für den Einsatz und das Verifizieren der Zertifikate sowie Regelungen für das Sperren der Zertifikate. Neben den Anforderungen an den Aufbau und Betrieb der CA-MON ergeben sich aus der Spezifikation des System und Service Level Monitoring auch weitere Vorgaben für andere PKI der Telematikinfrastruktur. Diese werden in Anhang A zusammengestellt. gematik_pki_x 509_SSL_Monitoring.doc Seite 6 von 42

7 2 Einführung 2.1 Zielsetzung und Einordnung des Dokuments Beim Datenaustausch im Rahmen des System und Service Level Monitoring müssen sich die Kommunikationspartner gegenseitig authentifizieren. Dabei werden X.509-Zertifikate genutzt, die gemäß den Vorgaben aus [gemsysslm] aus einer gesonderten (von den anderen PKIen der Telematikinfrastruktur getrennten) PKI stammen. In dem vorliegenden Dokument werden im Sinne eines s die wesentlichen Anforderungen an diese PKI beschrieben. Primäres Ziel dieses Dokuments ist es, den Leistungsumfang des TSP festzulegen, der die für das Ausstellen der benötigten X.509-Zertifikate zuständige CA betreibt. Dieses Dokument wird u. a. Bestandteil der Ausschreibung des Betriebs des TSP sein. Anmerkung: Die gematik wird (voraussichtlich) einen externen Dienstleister mit dem Betrieb des zentralen System und Service Level Monitoring beauftragen. Hierauf wird in diesem Dokument nicht weiter eingegangen. Es wird daher immer der Begriff gematik für den Betreiber des zentralen System und Service Level Monitoring verwendet. 2.2 Zielgruppe Das Dokument richtet sich im Wesentlichen an den TSP, der die CA-MON für das Ausstellen der benötigten X.509-Zertifikate für das System und Service Level Monitoring betreibt. Zusätzlich richtet es sich an die Betreiber einer Managementschnittstelle für den Austausch von Daten zwischen einem dezentralen System und Service Level Monitoring und dem zentralen System und Service Level Monitoring der gematik. Anhang A enthält die Beschreibung von Problemen, die sich aus Auswirkungen des System und Service Level Monitoring auf andere PKIen der Telematikinfrastruktur ergeben. Die Lösungen dieser Probleme müssen im Rahmen der Spezifikationen dieser PKIen gelöst werden. Aus den Lösungen werden sich dann Anforderungen an Betreiber eines Brokers und an Betreiber von OCSP-Respondern ergeben. 2.3 Geltungsbereich Die in diesem enthaltenen Vorgaben sind verbindlich für den TSP, der die CA- MON betreibt, sowie für alle Betreiber, die ein durch die CA-MON ausgestelltes X.509- Zertifikat für das System und Service Level Monitoring besitzen und nutzen. 2.4 Arbeitsgrundlagen Die wesentliche Grundlage für die Vorgaben des s bilden die folgenden Dokumente: gematik_pki_x 509_SSL_Monitoring.doc Seite 7 von 42

8 Spezifikation System und Service Level Monitoring [gemsysslm] Festlegungen zu den X.509-Komponentenzertifikaten der Server und (Fach-) Dienste [gemx.509_sd] 2.5 Abgrenzung des Dokuments Die langfristige Bestimmung der Hash-Algorithmen, der Schlüssellängen und der Signatur- und Verschlüsselungsalgorithmen ist nicht Gegenstand der Betrachtung. Hier werden jeweils aktuell die Empfehlungen der international relevanten Gremien bzw. die Anforderungen von SigG/SigV [ALGCAT] berücksichtigt. 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] entsprechend der Technischen Richtlinie für ecard-projekte der Bundesregierung [BSI-TR03116] normativ vorgegeben. Die freie Auswahl aus den hier zugelassenen Algorithmen durch die Hersteller könnte zu Interoperabilitätsproblemen führen, während die Implementierung aller zulässigen Algorithmen erheblichen Aufwand verursacht. Dieser Konflikt wird durch [gemspec_krypt] adressiert. Ziel des Dokumentes Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur [gemspec_krypt] ist es, das Spektrum der zulässigen kryptographischen Algorithmen, sofern sie betreiberübergreifend verwendet werden, einzuschränken, um so mit einer minimalen Anzahl von Algorithmen kryptographische Interoperabilität herzustellen. Deshalb wird als Basis zur Referenzierung der kryptographischen Algorithmen auf o. g. Dokument, Abschnitt [gemspec_krypt#5.1.1] bzw. relevante Unterabschnitte verwiesen. Detaillierte Vorgaben zur Validierung von Zertifikaten und der Listen der vertrauenswürdigen Herausgeber werden in [gemverw_zert_ti] gemacht. Das vorliegende Dokument trifft nicht die Festlegungen zu den tatsächlich einzutragenden OIDs, sondern verwendet stattdessen eine gematik-oid-referenz. Die normative Festlegung der OIDs trifft das Dokument [gemspec_oid], dort ist die jeweilige Zuordnung der hier verwendeten OID-Referenz zur registrierten OID ersichtlich. Aktuell behandelt dieses nur die Aspekte der Nutzung der PKI im Rahmen des System und Service Level Monitoring. Die Nutzung im Rahmen weiterer Anwendungen wie z. B. Zertifikate über Schlüssel für Signaturen über Code bzw. Konfigurationen werden dagegen aktuell nicht betrachtet. Dieses geht auf alle PKI-relevanten Aspekte ein, die sich aus dem System und Service Level Monitoring ergeben. Die aufgeführten Vorgaben werden dabei jedoch nicht im Detail ausgearbeitet. Dies muss vielmehr in folgenden weiteren Tätigkeiten erfolgen: gematik_pki_x 509_SSL_Monitoring.doc Seite 8 von 42

9 Für den Aufbau und Betrieb der CA-MON muss eine Feinspezifikation erstellt werden. Dies muss gemäß Ausschreibung der gematik durch den Auftragnehmer durchgeführt werden, der als TSP für alle Komponenten-PKIen durch die gematik beauftragt wird. In der gematik müssen Prozesse für die Registrierung der beteiligten Betreiber etabliert werden. Hierfür muss die gematik entsprechende Konzepte erstellen und umsetzen. In der gematik müssen Prozesse für die Sperrung (ggf. auch die Suspendierung und Desuspendierung) von Zertifikaten etabliert werden. Hierfür muss die gematik entsprechende Konzepte erstellen und umsetzen. In der gematik müssen Prozesse für eine unverzügliche Information aller Betreiber im Falle der Änderung ihres eigenen MON-Zertifikats etabliert werden. Hierfür muss die gematik entsprechende Konzepte erstellen und umsetzen. Für das zentrale System und Service Level Monitoring muss der Umgang mit der White-List der MON-Zertifikate der Betreiber spezifiziert werden. Dies muss im Rahmen der Konzeption und Umsetzung des zentralen System und Service Level Monitoring erfolgen. Die in Anhang A zusammengestellten Probleme, die sich aus dem System und Service Level Monitoring für andere PKIen ergeben, müssen im Rahmen der Spezifikationen dieser PKIen gelöst werden. 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. gematik_pki_x 509_SSL_Monitoring.doc Seite 9 von 42

10 2.6.2 Hinweis auf offene Punkte Offene Punkte, die bis zur nächsten Dokumentenversion bearbeitet werden, sind vorläufig nach der folgenden Konvention gekennzeichnet. Das Kapitel wird in einer späteren Version des Dokumentes ergänzt. gematik_pki_x 509_SSL_Monitoring.doc Seite 10 von 42

11 3 Anforderungen Die Anforderungen müssen noch mit dem Anforderungsmanagement abgestimmt werden. Dieses Kapitel wird in einer späteren Version des Dokuments dann entsprechend vollständig überarbeitet. Die Notwendigkeit für eine PKI für die, für das System und Service Level Monitoring benötigten, X.509-Zertifikate ergibt sich direkt aus [gemsysslm]. Dabei müssen die folgenden wesentlichen Anforderungen berücksichtigt werden: Über die Managementschnittstelle DÜRFEN nur hierfür autorisierte Systeme kommunizieren. Teilnehmer des Management-VPN MÜSSEN sich authentisieren. Die gematik hat die Verantwortung für die Registrierung der berechtigten Teilnehmer. Die gematik MUSS die Interoperabilität dieser PKI sicherstellen. Es MUSS für die benötigten X.509-Zertifikate eine separate PKI aufgebaut und betrieben werden. Die X.509-Zertifikate werden nur im Rahmen der Kommunikation über die Managementschnittstelle zu dem Management-VPN genutzt. Die folgende Tabelle enthält die entsprechenden, bereits durch das Anforderungsmanagement erfassten relevanten Eingangsanforderungen: Tabelle 1: Bereits erfasste Eingangsanforderungen Quelle Anforderungsnummer Anforderungslevel Beschreibung 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 gemgesarch A_01260 MUSS Es MUSS sichergestellt sein, dass nur autorisierte Personen und Systeme über die Managementschnittstelle kommunizieren. gemsysslm A_01370 MUSS Das der Managementschnittstelle zugrunde liegende Netzwerk MUSS das System Management VPN sein. gemsysslm A_01399 MUSS Eine separate PKI MUSS zur Abdeckung sicher- gematik_pki_x 509_SSL_Monitoring.doc Seite 11 von 42

12 Quelle Anforderungsnummer Anforderungslevel Beschreibung heitsrelevanter Funktionalität im System und Service Level Monitoring System implementiert werden. Die für die Anwendungen der egk implementierten PKI der Telematikinfrastruktur DÜRFEN NICHT verwendet werden. gemsysslm A_01400 MUSS Die Registrierungsverantwortung der internen PKI zur Abdeckung sicherheitsrelevanter Funktionalität im System und Service Level Monitoring MUSS durch die zentralen Betriebsprozesse der gematik wahrgenommen werden. Neben den genannten Anforderungen MÜSSEN bei der PKI für das System und Service Level Monitoring auch die Vorgaben der Zertifizierungsrichtlinie der gematik [gemtsl_sp_cp] berücksichtigt werden. gematik_pki_x 509_SSL_Monitoring.doc Seite 12 von 42

13 4 PKI für das System und Service Level Monitoring 4.1 Grundlagen Gemäß [gemsysslm] sammeln die einzelnen Betreiber der dezentralen Services, die für das System und Service Level Monitoring (im Folgenden abkürzend mit MON bezeichnet) benötigten Daten in ihren eigenen Managementsystemen. Die für das zentrale System und Service Level Monitoring der gematik benötigten Daten, werden dann durch die einzelnen Betreiber an die gematik weitergeleitet. Die Betreiber und die gematik realisieren für diesen Datenaustausch die in [gemsysslm] spezifizierte Managementschnittstelle. Die folgende Abbildung (entnommen aus [gemsysslm]) zeigt die dabei verwendete Netzwerkarchitektur: Abbildung 1: Netzarchitektur dezentrales System und Service Level Monitoring Der Datenaustausch zwischen den Betreibern und der gematik erfolgt über ein separates Management-VPN. Durch [gemsysslm] sind hierfür die folgenden Vorgaben gegeben: Als Protokoll wird HTTPS verwendet. gematik_pki_x 509_SSL_Monitoring.doc Seite 13 von 42

14 Beim Verbindungsaufbau wird eine gegenseitige Authentisierung der beiden Kommunikationspartner durchgeführt. Bei der Authentisierung werden X.509-Zertifikate verwendet, die durch eine speziell hierfür zu betreibende PKI erzeugt werden. Im Rahmen der Authentisierung muss jede Seite die aktuelle Gültigkeit des Zertifikats der anderen Seite überprüfen. Bei dem Datenaustausch über die gematik-managementschnittsstelle ist die Größe der auszutauschenden Daten auf 10 MB beschränkt. Für große Datenmengen stellen die Betreiber und die gematik eine Up- und Download-Funktionalität für Software und Dateien zur Verfügung. Als Protokolle kommen HTTPS und SFTP dabei zum Einsatz. Eine Authentisierung der Kommunikationspartner findet ebenfalls statt, wobei X.509-Zertifikate aus der gleichen PKI genutzt werden. Beim Datenaustausch für das System und Service Level Monitoring findet eine Kommunikation immer zwischen einem Betreiber einerseits und der gematik andererseits statt. Eine direkte Kommunikation zwischen zwei Betreibern findet nicht statt. Aus logischer Sicht hat das Management VPN daher eine Sterntopologie mit der gematik als zentralen Knoten. Die folgende Abbildung zeigt die möglichen direkten Kommunikationswege: Management Schnittstelle Betreiber 2 Management Schnittstelle Betreiber 1 Management Schnittstelle Betreiber n Management Schnittstelle gematik Abbildung 2: Netztopologie für das dezentrale System und Service Level Monitoring Aus dieser logischen Sterntopologie können Vorgaben für die benötigte PKI abgeleitet werden, die den Aufbau und Betrieb insbesondere in Bezug auf das Verifizieren der Zertifikate wesentlich vereinfachen. Diese Punkte werden in den folgenden Abschnitten näher beschrieben. gematik_pki_x 509_SSL_Monitoring.doc Seite 14 von 42

15 4.2 Vertrauensmodell Alle X.509-Zertifikate für das System und Service Level Monitoring werden von einem zentralen TSP ausgestellt. Die gematik wird hierfür einen geeigneten Betreiber auswählen und mit dem Betrieb der CA beauftragen. Der TSP setzt für die Ausgabe der Zertifikate für das MON eine gesonderte (Sub-) CA- MON auf, die getrennt von CAs für andere PKIen der Telematikinfrastruktur betrieben wird. Das Zertifikat über den öffentlichen Schlüssel dieser (Sub-) CA-MON wird durch die Root-CA (Komponenten PKI) desselben TSP mit ihrem privaten Schlüssel signiert. Es ergibt sich somit folgende Hierarchie für die PKI für das System und Service Level Monitoring: TSP Root-CA Sub-CA Zertifikat Sub-CA Zertifikat Sub-CA Zertifikat Sub-CA PKI x CA-MON Sub-CA PKI y X.509 Zertifikat für SSLM X.509 Zertifikat für SSLM X.509 Zertifikat für SSLM Betreiber 1 Management Schnittstelle Betreiber n Management Schnittstelle gematik Management Schnittstelle Abbildung 3: Hierarchie PKI für System und Service Level Monitoring Alle Zertifikate für die Absicherung der Kommunikation zwischen dezentralem und zentralem System und Service Level Monitoring werden durch die gleiche CA-MON ausgestellt. Die Zertifikate werden auch nur zur Absicherung dieser Kommunikation eingesetzt. Die Anzahl der beteiligten Betreiber und damit die Anzahl der benötigten X.509-Zertifikate ist gering. Für die Verteilung dieser Zertifikate wird daher das folgende vereinfachte Vorgehen umgesetzt: Das aktuell gültige CA-Zertifikat der CA-MON wird auf der Webseite des TSP für einen Download zur Verfügung gestellt. Jeder beteiligte Betreiber (mit einem dezentralen System und Service Level Monitoring) sowie die gematik laden dieses Zertifikat von dieser Webseite. Die CA-MON stellt einen Fingerprint über sein CA-Zertifikat auf Anfrage schriftlich zur Verfügung. Siehe dazu auch den Abschnitt gematik_pki_x 509_SSL_Monitoring.doc Seite 15 von 42

16 gematik und Betreiber erhalten ihr X.509-Zertifikat für das Monitoring der CA-MON. Siehe dazu Abschnitt Das aktuell gültige X.509-Zertifikat für das Monitoring der gematik wird (zusätzlich) auf der Webseite der gematik und auf der Webseite des TSP für einen Download zur Verfügung gestellt. Jeder beteiligte Betreiber (mit einem dezentralen System und Service Level Monitoring) lädt dieses Zertifikat von einer dieser Webseiten. Die gematik informiert alle Betreiber per , falls sich ihr Zertifikat geändert hat. Die Betreiber laden dann das neue Zertifikat von einer der genannten Webseiten. Die gematik erhält von dem TSP eine White-List mit allen aktuell gültigen X.509-Zertifikaten für MON aller beteiligten Betreiber. Das genaue Vorgehen bei dem Austausch dieser White-List wird zwischen gematik und TSP bilateral abgestimmt. Die im Rahmen des Verbindungsaufbaus zwischen der gematik und einem Betreiber notwendige Überprüfung des Zertifikats des jeweiligen Kommunikationspartners kann bei diesem Vorgehen rein lokal geschehen. Eine Online-Überprüfung z. B. durch eine OCSP- Abfrage wird nicht benötigt. 4.3 Zertifikatsaufbau Der Aufbau der Zertifikate für Betreiber bzw. für die gematik MUSS dem Zertifikatsprofil C.SF.SSL entsprechen. Für das CA-Zertifikat MUSS das Profil C.SF.CA mit den Festlegungen für CAs von SSL- Zertifikaten eingerichtet werden. Diese Profile werden im Dokument Festlegungen zu den X.509-Komponentenzertifikaten der Server und (Fach-) Dienste [gemx.509_sd] definiert. Sie beschreiben Inhalt und Kodierung der Zertifikatsfelder bzw. Extensions. In diesem Kapitel werden nur die Zertifikatseigenschaften aufgeführt, deren Definition für System und Service Level Monitoring präzisiert werden muss Festlegungen zur Definition der Betreiber- bzw. gematik-identität Die Identität eines Betreibers bzw. der gematik ist durch den Inhalt des Feldes SubjectDN (subject distinguishedname) des X.509-Zertifikats für MON gegeben Übersicht: Attribute im SubjectDN (X.509-Zertifikat für MON) Tabelle 2: Attribute im SubjectDN Attribut OID Kodierung max. String-Länge Art commonname {id-at 3} UTF8 64 Pflicht givenname {id-at 42} UTF8 64 P serialnumber {id-at 5} PrintableString 64 P gematik_pki_x 509_SSL_Monitoring.doc Seite 16 von 42

17 streetaddress {id-at 9} UTF8 128 Option postalcode {id-at 17} UTF8 40 O localityname {id-at 7} UTF8 128 O stateorprovincename {id-at 8} UTF8 128 O organizationalunitname {id-at 11} UTF8 64 O organizationname {id-at 10} UTF8 64 P countryname {id-at 6} PrintableString 2 (ISO 3166 Code) P Die Eindeutigkeit der Identität eines Betreibers (bzw. der gematik) innerhalb der Telematikinfrastruktur ist bereits durch den Inhalt des Attributs commonname innerhalb des SubjectDN gegeben ([gemsysslm]). Zusätzlich enthält SubjectDN noch den Namen und das Land des Betreibers als weitere Pflichtangaben. Optionale Felder mit der Anschrift des Betreibers bzw. dem Namen einer relevanten Abteilung können ebenfalls in einem X.509-Zertifikat für das Monitoring enthalten sein Nutzung der Attribute im SubjectDN commonname Datenfeld: FQDN. Es MUSS der durch die gematik für die Managementschnittstelle des Betreibers vergebene FQDN eingetragen werden (näheres siehe 4.4.1). Feld Länge Kardinalität Datentyp Format Durch die gematik vergebener FQDN der Managementschnittstelle givenname AN UTF-8 Datenfeld: Name des Services. Zurzeit MUSS hier der konstante Wert "Managementschnittstelle" eingetragen werden. Zukünftig kann es hier zu Erweiterungen kommen. Feld Länge Kardinalität Datentyp Format Zurzeit konstanter Wert "Managementschnittstelle" serialnumber AN UTF-8 Datenfeld: Laufende Nummer der Komponente. Zurzeit MUSS der Wert "1" eingetragen werden. Zukünftig kann es hier zu Erweiterungen kommen. Feld Länge Kardinalität Datentyp Format Zurzeit konstanter Wert "1" AN Printable- String streetaddress Datenfeld: Straßenanschrift des Betreibers gematik_pki_x 509_SSL_Monitoring.doc Seite 17 von 42

18 Feld Länge Kardinalität Datentyp Format Straße Hausnummer (mehrere Wörter sind durch Blank getrennt) AN UTF-8 postalcode Datenfeld: Postleitzahl des Betreibers Feld Länge Kardinalität Datentyp Format Postleitzahl Deutsche Postleitzahlen werden in einer Länge von 5 Byte abgebildet localityname Datenfeld: Stadt des Betreibers AN UTF-8 Feld Länge Kardinalität Datentyp Format Stadt AN UTF-8 stateorprovincename Datenfeld: Bundesland der Anschrift des Betreibers Feld Länge Kardinalität Datentyp Format Bundesland AN UTF-8 organizationalunitname Datenfeld: Name der relevanten Einheit des Betreibers. Feld Länge Kardinalität Datentyp Format Name der relevanten Einheit des Betreibers. organizationname AN UTF-8 Datenfeld: Name des Betreibers. Es MUSS der gleiche Name eingetragen werden, wie er im Rahmen der Zulassung/Registrierung des Betreibers durch die gematik genannt wurde. Feld Länge Kardinalität Datentyp Format Name des Betreibers: Angabe wie bei der Registrierung durch die gematik (Ist die maximal zulässige Länge des Namens überschritten, muss dieser zusätzlich in die X.509-Extension SubjectAltNames (GeneralDN) eingetragen werden.) AN UTF-8 gematik_pki_x 509_SSL_Monitoring.doc Seite 18 von 42

19 countryname Datenfeld: Land der Anschrift des Betreibers Feld Länge Kardinalität Datentyp Format countryname AN Printable String Aufbau der serialnumber im Feld SubjectDN Zurzeit MUSS immer der konstante Wert "1" in das Attribut serialnumber aufgenommen werden, da bereits durch den Inhalt des Attributs commonname eine Managementschnittstelle eindeutig identifiziert wird (siehe auch [gemsysslm]). Zukünftig kann es hier jedoch zu Erweiterungen kommen, z. B. falls die Managementschnittstelle (aus Gründen der Hochverfügbarkeit) redundant mehrfach bei einem Betreiber vorhanden ist. Von der eindeutigen Seriennummer der Komponente muss die eindeutige Nummer des X.509-Zertifikats unterschieden werden. Diese wird durch die ausstellende CA (ganze Zahl, 1<=serialNumber<= ) definiert und ist nur innerhalb der Domäne der CA eindeutig zuzuordnen Aufbau des gesamten SubjectDN Der SubjectDN eines Betreibers bzw. der gematik setzt sich wie folgt zusammen (Optionale Daten sind grau hinterlegt): commonname = [FQDN], givenname = Managementschnittstelle, serialnumber = 1, streetaddress = [Straße und Hausnummer], postalcode = [Postleitzahl], localityname = [Stadt] stateorprovincename = [Bundesland], organizationalunitname = [Relevante Einheit des Betreibers], organizationname = [Name des Betreibers], countryname = [Herkunftsland des Betreibers, z. B. DE] Die Werte der Attribute givenname und serialnumber enthalten zurzeit die angegebenen konstanten Werte. Zukünftig kann es hier zu Erweiterungen kommen Notwendige Zertifikatsfelder Abweichend von Kapitel 5.3 Notwendige Zertifikatsfelder aus dem Dokument Festlegungen zu den Komponentenzertifikaten der Server- und (Fach-) Dienste [gemx.509_sd#5.3] ist die Extension AuthorityInfoAccess in allen Monitoring-Zertifikaten optional. Die folgende Tabelle gibt einen Überblick über die möglichen Extensions, die in einem Zertifikat enthalten sein MÜSSEN (P) bzw. enthalten sein KÖNNEN (O): Tabelle 3: Überblick der im Zertifikat enthaltenen Extensions Betreiberzertifikat (C.MGMTSS.SSL) CA-Zertifikat (C.MGMTSS.CA) SubjectKeyIdentifier O O gematik_pki_x 509_SSL_Monitoring.doc Seite 19 von 42

20 Betreiberzertifikat (C.MGMTSS.SSL) CA-Zertifikat (C.MGMTSS.CA) BasicConstraints - P KeyUsage P P SubjectAltNames O O CertificatePolicy P P CRLDistributionPoint O O AuthorityKeyIdentifier O O Admission P O AdditionalInformation P O ExtendedKeyUsage P O Die Extension BasicConstraints MUSS für das CA-Zertifikat den Wert "CA:true enthalten. Die Extension KeyUsage MUSS für ein Betreiberzertifikat den Wert "digitalsignature enthalten. Zusätzlich KANN der Wert "keyencipherment enthalten sein. Für das CA-Zertifikat MUSS die Extension den Wert "keycertsign enthalten. Die Extension ExtendedKeyUsage MUSS für ein Betreiberzertifikat die Werte "serverauth und "clientauth enthalten. Für die OIDs der anzugebenden Werte siehe [ISIS-MTT]. In allen Komponentenzertifikaten wird in der Extension Admission die technische Rolle des Zertifikatsinhabers (hier Management Schnittstelle [gemgesarch#anhb1]) angegeben. Die genaue Festlegung der OID erfolgt verbindlich im Dokument [gemspec_oid]. Zur Unterscheidung von Endnutzerzertifikaten wird neben den Referenzen auf die Policies auch der jeweilige Zertifikatstyp (OID) in der Extension AdditionalInformationCertificatePolicy gespeichert. Die genaue Festlegung der Inhalte erfolgt nun verbindlich im Dokument [gemspec_oid]. Die Kennzeichnung des Zertifikatstyps in der Extension AdditionalInformation kann sicherheitsrelevant sein. Es MUSS daher eine entsprechende Schutzbedarfsfeststellung im Rahmen des übergreifenden Sicherheitskonzepts der gematik durchgeführt werden. Die Schutzbedarfsfeststellung MUSS durchgeführt werden. Bis auf die Extension KeyUsage werden alle Extensions auf "nicht kritisch" gesetzt. Dieses ermöglicht den Einsatz der Zertifikate auch außerhalb der TI und innerhalb von ggf. zum Einsatz kommender Standardsoftware. Falls der Wert einer Extension für die Ablaufsteuerung einer Komponente der TI benötigt wird, MUSS diese Komponenten der TI jedoch die Extension korrekt auswerten. Dieses MUSS durch die Ablaufsteuerung dieser Komponenten sichergestellt werden. gematik_pki_x 509_SSL_Monitoring.doc Seite 20 von 42

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

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 Version: 1.5.0 Revision: main/rel_main/11 Stand: 12.06.2008 Status: freigegeben gematik_pki_x509_zertifikate_des_versicherten_egk.doc

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

Zertifikatsprofile für X.509 Basiszertifikate, Version 2.3.2

Zertifikatsprofile für X.509 Basiszertifikate, Version 2.3.2 Bundesärztekammer, Berlin Identifikation des Dokuments: Zertifikatsprofile für X.509, Bundesärztekammer Revisions-Datum.: 16.05.2011 10:38 Nr.:6 R:\eArztausweis\07_Fachfeinkonzept\05_Lieferung\01_X509-Zert\2011-05-12_Konzept_CertProfile_V2.3.2.doc

Mehr

Public Key Service. Profil der qualifizierten Attributzertifikate. Version: 1.2 Stand: 16.12.2015 Status: Freigegeben. Öffentliches Dokument

Public Key Service. Profil der qualifizierten Attributzertifikate. Version: 1.2 Stand: 16.12.2015 Status: Freigegeben. Öffentliches Dokument Public Key Service Profil der qualifizierten Attributzertifikate Version: 1.2 Stand: 16.12.2015 Status: Freigegeben Öffentliches Dokument Impressum Herausgeber T-Systems International GmbH Dateiname Dokumentennummer

Mehr

Zertifikatsprofile für X.509 Attributzertifikate V2.3.2

Zertifikatsprofile für X.509 Attributzertifikate V2.3.2 Bundesärztekammer, Berlin Identifikation des Dokuments: Zertifikatsprofile für X.509, Bundesärztekammer Revisions-Datum.: 12.05.2011 15:07 Nr.:4 Seite 2 von 25 Datum Name, Abteilung, Firma Autor, Ansprechpartner

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

Errata zu Release 1.5.1 Online-Rollout (Stufe 1) Erprobung und Produktivbetrieb. Release 1.5.2

Errata zu Release 1.5.1 Online-Rollout (Stufe 1) Erprobung und Produktivbetrieb. Release 1.5.2 Einführung der Gesundheitskarte Errata zu Release.5. Online-Rollout (Stufe ) Erprobung und Produktivbetrieb führt zu Release.5.2 Version:.0.0 Stand:.0.206 Status: freigegeben Klassifizierung: öffentlich

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

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

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

Trustcenter der Deutschen Rentenversicherung

Trustcenter der Deutschen Rentenversicherung Trustcenter der Deutschen Rentenversicherung Certificate Policy und Certification Practice Statement für nicht-qualifizierte Serverzertifikate der Zertifizierungsstelle der Deutschen Rentenversicherung

Mehr

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

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

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

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

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

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

Formate und Protokolle nach MTTv2

Formate und Protokolle nach MTTv2 Zertifizierungsinfrastruktur für die PKI-1-Verwaltung Technische Grundlagen der Wurzelzertifizierungsstelle Formate und Protokolle nach MTTv2 Bundesamt für Sicherheit in der Informationstechnik Version

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

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

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

PKI und X.509 Zertifikatsprofile Beschreibung eines Konzepts zur Erstellung und Verwaltung von X.509 Zertifikaten

PKI und X.509 Zertifikatsprofile Beschreibung eines Konzepts zur Erstellung und Verwaltung von X.509 Zertifikaten PKI und X.509 Zertifikatsprofile Beschreibung eines Konzepts zur Erstellung und Verwaltung von X.509 Zertifikaten Editor: Olaf Rode Dokumenten-ID: PKI und X.509 Zertifikatsprofile Verantwortlich: Fraunhofer

Mehr

Public Key Infrastrukturen

Public Key Infrastrukturen Public Key Infrastrukturen K l a u s u r SS 2008, 2008-07-07 Prof. Dr. Harald Baier Name, Vorname: Matrikelnummer: Hinweise: (a) Als Hilfsmittel ist nur der Taschenrechner TI-30 zugelassen. Weitere Hilfsmittel

Mehr

Anhang C: Public Key Infrastruktur für Smart Meter Gateways

Anhang C: Public Key Infrastruktur für Smart Meter Gateways Technische Richtlinie TR-03109 Anhang C: Public Key Infrastruktur für Smart Meter Gateways Version: 0.20 - Stand 10.10.2011 Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn

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

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

LDAP für PKI. von. Marc Saal

LDAP für PKI. von. Marc Saal LDAP für PKI von Inhalt - Einführung - Die Infrastruktur - Benötigte Objektklassen - Aufbau der Einträge in den Objektklassen - Quiz - Literatur Einführung PKI: System, welches es ermöglicht, digitale

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

VOLKSVERSCHLÜSSELUNGS-PKI FÜR X.509-ZERTIFIKATE

VOLKSVERSCHLÜSSELUNGS-PKI FÜR X.509-ZERTIFIKATE VOLKSVERSCHLÜSSELUNGS-PKI FÜR X.509-ZERTIFIKATE Zertifizierungsrichtlinie (CP) und Erklärung zum Zertifizierungsbetrieb (CPS) OID: 1.3.36.15.9.1.1.1 Version: 1.0 Datum: 29.06.2016 Impressum Herausgeber

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

SIC CA Zertifizierungsrichtlinien Certificate Practice Statement (CPS) der SIC Customer ID CA 1024 Level 2

SIC CA Zertifizierungsrichtlinien Certificate Practice Statement (CPS) der SIC Customer ID CA 1024 Level 2 SIC CA Zertifizierungsrichtlinien Certificate Practice Statement (CPS) der SIC Customer ID CA 1024 Level 2 Version 2.2 / Dezember 2012 1 Hinweise Die in diesem Dokument enthaltenen Angaben sind ohne Gewähr

Mehr

Einführung der Gesundheitskarte Verwendung von Zertifikaten in der Telematikinfrastruktur

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

Mehr

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

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

Mehr

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

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

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

Kleines SSL Handbuch. Inhaltsverzeichnis. Daniel Klaenbach 18.07.2007. 1 Einleitung 2

Kleines SSL Handbuch. Inhaltsverzeichnis. Daniel Klaenbach 18.07.2007. 1 Einleitung 2 Kleines SSL Handbuch Daniel Klaenbach 18.07.2007 Inhaltsverzeichnis 1 Einleitung 2 2 Selbstsignierte Zertikate erstellen 3 2.1 Einen privaten Schlüssel erstellen.................................... 3 2.1.1

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

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

Für die Ausgabe der Zertifikate betreibt die Hochschule Ulm eine Registrierungsstelle (RA).

Für die Ausgabe der Zertifikate betreibt die Hochschule Ulm eine Registrierungsstelle (RA). Inhaltsverzeichnis 1 Einleitung...2 1.1 Identifikation des Dokuments...2 2. Zertifikate...2 2.2 Server-Zertifikate...2 2.2.1 Antrag...2 2.2.1.1 Erzeugung des Antrags...3 2.2.1.1.1 Erzeugung des Antrags

Mehr

1. IKEv2 zwischen Windows 7 und Gateway mit Zertifikaten (PKCS#12)

1. IKEv2 zwischen Windows 7 und Gateway mit Zertifikaten (PKCS#12) 1. IKEv2 zwischen Windows 7 und Gateway mit Zertifikaten (PKCS#12) 1.1 Einleitung Im Folgenden wird die Konfiguration einer IPSec-Verbindung mit IKEv2 von einem Windows 7 Rechner zum bintec IPSec-Gateway

Mehr

Anleitung zur Nutzung von OpenSSL in der DFN-PKI

Anleitung zur Nutzung von OpenSSL in der DFN-PKI Anleitung zur Nutzung von OpenSSL in der DFN-PKI Kontakt: Allgemeine Fragen zur DFN-PKI: Technische Fragen zur DFN-PKI: pki@dfn.de dfnpca@dfn-cert.de DFN-Verein, Januar 2008; Version 1.2 Seite 1 1 OpenSSL

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

Certificate-Policy für SMC Typ B Version 1.0 des Krankenhaus-Sektors

Certificate-Policy für SMC Typ B Version 1.0 des Krankenhaus-Sektors Certificate-Policy für SMC Typ B Version 1.0 des Krankenhaus-Sektors Stand: 20090313h 1 1 EINLEITUNG... 4 1.1 Überblick... 4 1.2 Identifikation des Dokuments... 4 1.3 Teilnehmer der Zertifizierungsinfrastruktur...

Mehr

ELMA5-Verfahren. Benutzerleitfaden zur Massendatenschnittstelle des BZSt

ELMA5-Verfahren. Benutzerleitfaden zur Massendatenschnittstelle des BZSt ELMA5-Verfahren Benutzerleitfaden zur Massendatenschnittstelle des BZSt Stand: 08.03.2013 Seite 1 von 12 Inhaltsverzeichnis 1 Einleitung... 3 2 Voraussetzungen... 3 3 Dienste zur Teilnahme am ELMA5-Verfahren

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

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

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

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

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

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

Zertifizierungsrichtlinie der BTU Root CA

Zertifizierungsrichtlinie der BTU Root CA Brandenburgische Technische Universität Universitätsrechenzentrum BTU Root CA Konrad-Wachsmann-Allee 1 03046 Cottbus Tel.: 0355 69 3573 0355 69 2874 der BTU Root CA Vorbemerkung Dies ist die Version 1.3

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

Vorwort E-Mail ist heute für Unternehmen ein häufig eingesetztes Kommunikationsmittel, das zum Austausch von Informationen verwendet wird.

Vorwort E-Mail ist heute für Unternehmen ein häufig eingesetztes Kommunikationsmittel, das zum Austausch von Informationen verwendet wird. Vorwort E-Mail ist heute für Unternehmen ein häufig eingesetztes Kommunikationsmittel, das zum Austausch von Informationen verwendet wird. Auch die Unternehmensgruppe ALDI Nord steht mit einer Vielzahl

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

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

Leitfaden zur Anlage einer Nachforderung. Nachforderung. 04.04.2013 Seite 1 von 11 RWE IT GmbH

Leitfaden zur Anlage einer Nachforderung. Nachforderung. 04.04.2013 Seite 1 von 11 RWE IT GmbH Leitfaden zur Anlage einer 04.04.2013 Seite 1 von 11 Inhaltsverzeichnis 1 Aufruf des RWE smanagements...3 2 Eingabe der Benutzerdaten...4 3 Erfassen der...5 4 Neue...6 4.1 Allgemeine Daten...7 4.2 Beschreibung...7

Mehr

VPN KickStart. Eine Schritt-für-Schritt Anleitung für das sichere Verbinden zweier Netzwerke durch ein mguard basierendes IPsec-VPN

VPN KickStart. Eine Schritt-für-Schritt Anleitung für das sichere Verbinden zweier Netzwerke durch ein mguard basierendes IPsec-VPN VPN KickStart Eine Schritt-für-Schritt Anleitung für das sichere Verbinden zweier Netzwerke durch ein mguard basierendes IPsec-VPN Der VPN-Aufbau - Zwischen dem Firmennetz (erreichbar unter der IP-Adresse

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.0 Datum 18.03.2013 Bundesamt für Sicherheit in der Informationstechnik Postfach 20

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

Laborversuch. im Fachbereich Automatisierung und Informatik. Varianten für Signatur- und Verschlüsselungsinfrastrukturen / PKI

Laborversuch. im Fachbereich Automatisierung und Informatik. Varianten für Signatur- und Verschlüsselungsinfrastrukturen / PKI Laborversuch im Fachbereich Automatisierung und Informatik Varianten für Signatur- und Verschlüsselungsinfrastrukturen / PKI (am Beispiel SigG bzw. OpenPGP) Netzwerklabor Prof. Dr. H. Strack 1 Versuchsziele

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

Sichere Identitäten in Smart Grids

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

Mehr

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

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

Mehr

Anleitung zur Nutzung der DFN-Test-PKI

Anleitung zur Nutzung der DFN-Test-PKI Anleitung zur Nutzung der DFN-Test-PKI Kontakt: Zugang zur DFN-Test-PKI: www.pki.dfn.de/testpki-zugang Anfragen Zugangsberechtigung sowie Kommentare/Hinweise zu dieser Anleitung: pki@dfn.de Allgemeine

Mehr

Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013

Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013 Software Komponenten FS13 Gruppe 03 Horw, 16.04.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Estermann Michael

Mehr

Beantragung eines Softwarezertifikates für das EGVP-Backend

Beantragung eines Softwarezertifikates für das EGVP-Backend Beantragung eines Softwarezertifikates für das EGVP-Backend Anleitung Version 1.3 Stand 23.10.2009 Landesbetrieb für Statistik und Kommunikationstechnologie Niedersachsen (LSKN) Fachgebiet 243 Beratung

Mehr

S Sparkasse. UnnaKamen. Secure Mail Notwendigkeit?

S Sparkasse. UnnaKamen. Secure Mail Notwendigkeit? S Sparkasse UnnaKamen Secure Mail Notwendigkeit? Das sogenannte Sniffen, Ausspähen von E-Mailinhalten und Authentifizierungsdateien sowie das E-Mail Spoofing, das Erstellen einer E-Mail mit gefälschtem

Mehr

Studentenzertifikate für Online-Dienste der Fachhochschule Landshut

Studentenzertifikate für Online-Dienste der Fachhochschule Landshut Studentenzertifikate für Online-Dienste der Fachhochschule Landshut Die FH Landshut CA Entstanden aus einem Studienprojekt des Fachbereichs Informatik Start Sommersemester 2001 Ziel: CA für FH-Server,

Mehr

Informationen zur sicheren E-Mail-Kommunikation. Unternehmensgruppe ALDI SÜD

Informationen zur sicheren E-Mail-Kommunikation. Unternehmensgruppe ALDI SÜD Informationen zur sicheren E-Mail-Kommunikation Unternehmensgruppe ALDI SÜD Sichere E-Mail-Kommunikation Vorwort E-Mail ist heute für Unternehmen ein häufig eingesetztes Kommunikationsmittel, das zum Austausch

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

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

D2D-Anmeldung. Merkblatt für Arztpraxen zur D2D-Registrierung

D2D-Anmeldung. Merkblatt für Arztpraxen zur D2D-Registrierung Kassenärztliche Vereinigung Niedersachsen Unsere gebührenfreie IT-Servicehotline für Sie: 0800 5 10 10 25 Unsere Servicezeit für Sie: Mo.-Fr.: 08:00 h 18:00 h Serviceanfrage per email: it-service@kvn.de

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

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

Praxisbericht Zertifizierung Digitale Nachweise in IT-Grundschutz- Zertifizierungsverfahren

Praxisbericht Zertifizierung Digitale Nachweise in IT-Grundschutz- Zertifizierungsverfahren Praxisbericht Zertifizierung Digitale Nachweise in IT-Grundschutz- Zertifizierungsverfahren IT-Grundschutztag 13. Juni 2012, Bremen Dr. Sönke Maseberg "Es gilt auch Handschlagqualität in diesem Bereich,

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

Softwareentwicklungspraktikum Sommersemester 2007. Feinentwurf

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

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

Teilnahmebedingungen. für den elektronischen Datenaustausch. über das Internet. automatisierten gerichtlichen Mahnverfahren

Teilnahmebedingungen. für den elektronischen Datenaustausch. über das Internet. automatisierten gerichtlichen Mahnverfahren Automatisiertes gerichtliches Mahnverfahren in Hamburg und Mecklenburg-Vorpommern Teilnahmebedingungen für den elektronischen Datenaustausch über das Internet im automatisierten gerichtlichen Mahnverfahren

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

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

Public-Key-Infrastrukturen

Public-Key-Infrastrukturen TECHNISCHE UNIVERSITÄT DARMSTADT FACHGEBIET THEORETISCHE INFORMATIK PROF. DR. J. BUCHMANN J. BRAUN 10. Übung zur Vorlesung Public-Key-Infrastrukturen Sommersemester 2013 Aufgabe 1: Gültigkeitsmodelle -

Mehr

Weiterleiten von Bildern und Texten mittels SMTP

Weiterleiten von Bildern und Texten mittels SMTP E-Mail-Weiterleitung Weiterleiten von Bildern und Texten mittels SMTP Status: Freigegeben Dieses Dokument ist geistiges Eigentum der Accellence Technologies GmbH und darf nur mit unserer ausdrücklichen

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

Benutzerhandbuch für die Wirtschaftsteilnehmer

Benutzerhandbuch für die Wirtschaftsteilnehmer Benutzerhandbuch für die Wirtschaftsteilnehmer Vers. 02.08.2011 www.ausschreibungen-suedtirol.it Elektronische Vergaben 1 1 www.bandi-altoadige.it Gare telematiche Inhalt Digitale Signatur Adressenverzeichnis

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

Kundeninformation zu Secure E-Mail

Kundeninformation zu Secure E-Mail S Stadtsparkasse Felsberg Kundeninformation zu Secure E-Mail Einleitung Das sogenannte Sniffen, Ausspähen von E-Mailinhalten und Authentifizierungsdateien sowie das E-Mail Spoofing, das Erstellen einer

Mehr

Kundeninformation zu Secure E-Mail

Kundeninformation zu Secure E-Mail S Sparkasse Höxter Kundeninformation zu Secure E-Mail,,Digitale Raubzüge und Spionageangriffe gehören aktuell zu den Wachstumsbranchen der organisierten Kriminalität. Selbst modernste Sicherheitstechnologie

Mehr

Zertifikate Swiss Government SSL CA 01

Zertifikate Swiss Government SSL CA 01 Eidgenössisches Finanzdepartement EFD Bundesamt für Informatik und Telekommunikation BIT Kommunikation BIT Daniel Stich, 01. Mai 2014 Zertifikate Swiss Government SSL CA 01 Antrag erstellen Projektname:

Mehr

Auslandszahlungsverkehr im Datenaustausch zwischen Kunde und Bank

Auslandszahlungsverkehr im Datenaustausch zwischen Kunde und Bank Deutsche Bundesbank 60006 Frankfurt am Main Zentralbereich Statistik 069 / 9566-8565 S42-2 Auslandszahlungsverkehr im Datenaustausch zwischen Kunde und Bank (DTAZV) gültig ab 31. Oktober 2009 Stand 15.

Mehr

Collax VPN. Howto. Vorraussetzungen Collax Security Gateway Collax Business Server Collax Platform Server inkl. Collax Modul Gatekeeper

Collax VPN. Howto. Vorraussetzungen Collax Security Gateway Collax Business Server Collax Platform Server inkl. Collax Modul Gatekeeper Collax VPN Howto Dieses Howto beschreibt exemplarisch die Einrichtung einer VPN Verbindung zwischen zwei Standorten anhand eines Collax Business Servers (CBS) und eines Collax Security Gateways (CSG).

Mehr

Spezifikation der Schnittstellen für die Übermittlung von Nachrichten mittels http. gesetzlichen Krankenversicherung

Spezifikation der Schnittstellen für die Übermittlung von Nachrichten mittels http. gesetzlichen Krankenversicherung Datenaustausch mit Leistungserbringern und Arbeitgebern im Internet Spezifikation der Schnittstellen für die Übermittlung von (hypertext transfer protocoll) Stand der Spezifikation: 01. September 2001

Mehr