Virtuelle Poststelle des Bundes, Version 2.2.3.x (OSCI), Sicher- heitsvorgaben (ST) bremen online services GmbH & Co. KG datenschutz nord GmbH Version 1.1 11.03.2008 Zertifizierungs-ID: BSI-DSZ-CC-0505 Bestätigungs-ID: BSI.02099.TE.xx.200x Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Historie Version Datum geänderte Kapitel Grund der Änderung Geändert durch 0.1 02.02.2006 Erstellung Matthias Intemann Sönke Maseberg 0.2 14.03.2006 Einarbeitung der Kommentare von TSI, secunet und BSI; Kryptofunktionalität OSCI-Ma- nager präzisiert Matthias Intemann Sönke Maseberg 0.3 17.03.2006 Fußnote 16 kl. editorische Änderungen Matthias Intemann Sönke Maseberg 0.4 23.05.2006 Integration der Kommentare von BSI und TSI vom 13.4. bzw. 28.4.2006 Matthias Intemann Sönke Maseberg 1.0 19.11.2007 Verweise auf TIFF entfernt, kl. editorische Änderungen Matthias Intemann Ingo Schumann 1.1 11.03.2008 Verweise auf TIFF eingefügt, kl. editorische Änderungen Ingo Schumann Dokumenten-Überwachungsverfahren Status: final Prozess-/Dokumentbesitzer: Matthias Intemann (bremen online services GmbH & Co. KG) Ingo Schumann (bremen online services GmbH & Co. KG) Sönke Maseberg (datenschutz nord GmbH) bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 2/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Inhaltsverzeichnis 1 ST-Einführung............................................................................................................6 1.1 ST-Identifikation..................................................................................................6 1.2 ST-Übersicht........................................................................................................6 1.3 Postulat der Übereinstimmung mit den Common Criteria...................................8 2 EVG-Beschreibung..................................................................................................11 2.1 Kompositive Evaluierung...................................................................................11 2.2 Online Services Computer Interface (OSCI).....................................................12 2.3 EVG-Umfang.....................................................................................................13 2.4 Technische Realisierung...................................................................................16 2.5 Signaturgesetz (SigG) und -verordnung (SigV)................................................20 2.5.1 Rechtliche Grundlagen...............................................................................20 2.5.2 Signaturgesetz-Anforderungen an den EVG .............................................23 2.6 Produktbestandteile und EVG-Abgrenzung......................................................31 2.7 Absicherung .....................................................................................................33 2.8 Auslieferung......................................................................................................34 3 EVG-Sicherheitsumgebung.....................................................................................36 3.1 Rollen ...............................................................................................................36 3.2 Annahmen.........................................................................................................37 3.3 Bedrohungen.....................................................................................................41 3.4 Organisatorische Sicherheitspolitiken...............................................................41 4 Sicherheitsziele........................................................................................................43 4.1 EVG-Sicherheitsziele........................................................................................43 4.2 Sicherheitsziele für die Umgebung...................................................................45 5 IT-Sicherheitsanforderungen...................................................................................50 5.1 EVG-Sicherheitsanforderungen........................................................................50 5.1.1 Definition der funktionalen Sicherheitspolitik (SFP)...................................50 5.1.2 Funktionale EVG-Sicherheitsanforderungen..............................................51 5.1.3 Anforderungen an die Vertrauenswürdigkeit des EVG...............................59 5.2 Sicherheitsanforderungen an die IT-Umgebung...............................................60 5.3 Sicherheitsanforderungen an die Nicht-IT-Umgebung......................................63 6 EVG-Übersichtsspezifikation...................................................................................63 bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 3/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) 6.1 SF1 – Unterstützung bei der Erzeugung qualifizierter elektronischer Signaturen .................................................................................................................................64 6.2 SF2 – Schutz gegen Hashwertmanipulation.....................................................64 6.3 SF3 – Verifikation einer qualifizierten elektronischen Signatur ........................65 6.4 SF4 – Verifikation eines OSCI-Laufzettels bei der Validierung eines qualifizier- ten Zertifikats...........................................................................................................65 6.5 SF5 – Sichere und zuverlässige Anzeige.........................................................65 6.6 SF6 – Unterstützung bei der Validierung qualifizierter Zertifikate.....................66 6.7 SF7 – Identifikation und Authentisierung..........................................................67 6.8 SF8 – Prüftool...................................................................................................67 6.9 Maßnahmen zur Vertrauenswürdigkeit.............................................................68 7 PP-Postulate............................................................................................................69 8 Erklärungen..............................................................................................................69 8.1 Erklärung der organisatorischen Sicherheitspolitiken.......................................69 8.2 Erklärung der Sicherheitsziele...........................................................................71 8.3 Erklärung der Sicherheitsanforderungen..........................................................74 8.3.1 Erklärung zu den funktionalen Sicherheitsanforderungen..........................74 8.3.2 Erfüllung der Abhängigkeiten ....................................................................79 8.3.3 Analyse des Zusammenwirkens der funktionalen Anforderungen.............82 8.3.4 Analyse der Mindest-Stärkestufe................................................................82 8.3.5 Erklärung zu den Anforderungen an die Vertrauenswürdigkeit..................83 8.4 Erklärung der EVG-Übersichtsspezifikation......................................................83 8.4.1 Erfüllung der funktionalen Sicherheitsanforderungen................................83 8.4.2 Konsistenz der Mechanismenstärke-Postulate..........................................86 8.4.3 Analyse des Zusammenwirkens der Sicherheitsfunktionen.......................86 8.4.4 Zuordnung der Sicherheitsfunktionen zur Umsetzung der SigG-Anforderun- gen.......................................................................................................................87 8.4.5 Erklärung zu den Maßnahmen der Vertrauenswürdigkeit..........................90 9 Definition der Familie FDP_SVR .............................................................................92 10 Glossar ..................................................................................................................93 11 Literatur..................................................................................................................95 12 Anhang: Technische Einsatzumgebung................................................................97 12.1 Hard- und Software.........................................................................................97 12.2 Sichere Signaturerstellungseinheiten und Chipkartenleser ...........................98 12.3 Zertifikate und private Schlüssel.....................................................................98 bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 4/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) 12.4 Anfordernde Systeme......................................................................................99 Abbildungsverzeichnis Abbildung 1: Aufbau der Virtuellen Poststelle des Bundes...........................................7 Abbildung 2: EVG-Übersicht.......................................................................................11 Abbildung 3: Teilsysteme des EVG............................................................................17 Tabellenverzeichnis Tabelle 1: Umsetzung der SigG/SigV-Anforderungen................................................25 Tabelle 2: Lieferumfang EVG......................................................................................32 Tabelle 3: Funktionale Sicherheitsanforderungen an den EVG.................................51 Tabelle 4: Vertrauenswürdigkeitskomponenten..........................................................60 Tabelle 5: Funktionale Sicherheitsanforderungen an die IT-Umgebung....................60 Tabelle 6: Maßnahmen zur Erfüllung von EAL3+.......................................................68 Tabelle 7: Zuordnung Sicherheitsumgebung zu -zielen.............................................73 Tabelle 8: Zuordnung Sicherheitsziele zu -umgebung...............................................73 Tabelle 9: Zuordnung Sicherheitsziele zu Sicherheitsanforderungen an den EVG...76 Tabelle 10: Zuordung fkt. Sicherheitsanforderungen zu Sicherheitszielen................77 Tabelle 11: Zuordnung Sicherheitsziele zu Sicherheitsanforderungen an die IT-Um- gebung........................................................................................................................77 Tabelle 12: Zuordung fkt. Sicherheitsanforderungen an die IT-Umgebung zu Sicher- heitszielen...................................................................................................................78 Tabelle 13: Erfüllung der EVG-Abhängigkeiten..........................................................80 Tabelle 14: Angestrebten SOF-Stufen für die Sicherheitsfunktionen.........................82 Tabelle 15: Zuordnung fkt. Sicherheitsanforderungen durch Sicherheitsfunktionen..85 Tabelle 16: Zuordnung von Sicherheitsfunktionen zu Teilsystemen..........................86 Tabelle 17: Zusammenwirken der Sicherheitsfunktionen...........................................87 Tabelle 18: Umsetzung der SigG/SigV-Anforderungen durch Sicherheitsfunktionen 88 Tabelle 19: Erklärung der Maßnahmen zur Erfüllung von EAL3+..............................90 bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 5/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) 1 ST-Einführung 1.1 ST-Identifikation 1 ST-Name: Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) 2 ST-Version: 1.1 3 Datum: 11.03.2008 4 Autoren: bremen online services GmbH & Co. KG datenschutz nord GmbH 5 EVG-Name: Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI) – abkürzend mit „OSCI-Komponente“ bezeichnet 6 EVG-Version: 2.2.3.2 7 CC-Version: 2.31 8 Zertifizierungs-ID: BSI-DSZ-CC-0505 9 Bestätigungs-ID: BSI.02099.TE.xx.200x 1.2 ST-Übersicht 10 Im Rahmen des Projektes BundOnline 2005 wird die Virtuelle Poststelle des Bundes entwickelt. Sie stellt als zentrales Kommunikations-Gateway Sicher- heitsdienste für die gesicherte Kommunikation zwischen Behörden und exter- nen Kommunikationspartnern (Bürger, Wirtschaft und andere Behörden) be- reit. Entsprechend den zu erwartenden Kommunikationsszenarien im E- Government soll die Virtuelle Poststelle des Bundes folgende wesentliche Funktionen serverbasiert zur Verfügung stellen:  Signaturbildung und -prüfung;  Ver- und Entschlüsselung, wobei zentral entschlüsselte Kommunikations- daten vergleichbar der heute gängigen Praxis im Klartext weitergeleitet oder zur Weiterleitung im Hausnetz neu verschlüsselt werden;  Abwicklung (des kryptographischen Anteils) von Authentisierungsverfah- ren;  Bereitstellen von internen und externen Zeitstempeln;  Einbindung von Virenscannern;  Dokumentation aller Aktionen der Virtuellen Poststelle auf einem VPS- Laufzettel;  Einbindung interner und externer Verzeichnisdienste; 1 Dieses Dokument berücksichtigt die neue deutsche Rechtschreibung und passt die den CC entnommenen Texte teilweise an. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 6/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST)  Bereitstellung von benutzerfreundlichen Client-Komponenten. 11 Abbildung 1 illustriert die vollständige Virtuelle Poststelle des Bundes. : Adapter Fachverfahren OSCI- Bibliothek Web-Server Anwendungen Kernsystem Backend / Fach- verfahren OCSP/CRL- Relay Directory Interne Benutzer Directory Externe Benutzer Verwaltung Externe Benutzer Externer Zeit- stempeldienst Zeit-Server (NTP) Viren- scanner Log-Server Document Interface (DI) OSCI- Manager Entry Authenti- sierungs- anwendung Authentifizierungs- server Verifikations- anwendung Verifikations- server OSCI-Client- Enabler OSCI- Backend-Enabler Entry OSCI- Postfächer Mail Interface (MI) Web-Client Anwendungen Verwaltung Postbücher MTA SMTP Proxy Mail Anwendung 1 1 2 1 2 : Authentisierung: Business Delegate fachspezifisch zu implementieren: Mail Interface (MI) Trust-Center Virtuelle Poststelle des Bundes Abbildung 1: Aufbau der Virtuellen Poststelle des Bundes 12 Motivation für die Entwicklung der Virtuellen Poststelle des Bundes war, dass die Erfahrungen beim Einsatz kryptographischer Verfahren – um typische IT- Sicherheitsanforderungen wie Vertraulichkeit, Integrität und Authentizität zu erfüllen – gezeigt haben, dass diese bislang eher zögerlich genutzt werden. Idee der Virtuellen Poststelle ist, die zahlreichen praktischen Schwierigkeiten bei der ausschließlichen Anwendung von „Ende-zu-Ende-Sicherheit“ durch eine Alternative zu überwinden, die darin besteht, kryptographische Funktio- nen innerhalb von Behörden- und Firmennetzen serverbasiert anzubieten. Dabei darf aber nicht übersehen werden, dass es immer Kommunikationsbe- ziehungen oder -inhalte gibt, bei denen aufgrund ihrer Sensitivität eine zent- rale kryptographische Bearbeitung nicht zweckmäßig oder sogar ausge- schlossen ist. Eine vollständige Abschaffung der Ende-zu-Ende-Sicherheit sollte also nicht das Ziel von „Zentralisierungsbemühungen“ sein. 13 Die Evaluierung der Virtuellen Poststelle des Bundes wird im Rahmen einer kompositiven Evaluierung durchgeführt, in der die VPS in drei logische Ein- bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 7/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) heiten aufgeteilt wird, die jeweils als ein eigenständiger Evaluationsgegen- stand (EVG) evaluiert, zertifiziert und bestätigt werden. Die drei EVGs sind:  EVG1: Virtuelle Poststelle des Bundes, Version 2.2.x.x (Basis);  EVG2: Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI);  EVG3: Virtuelle Poststelle des Bundes, Version 2.2.x.x (Verifikationsmo- dul). 14 Die vorliegenden Sicherheitsvorgaben (Security Target – ST) fokussieren auf den Evaluationsgegenstand „Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI)“ – abkürzend als OSCI-Komponente bezeichnet. 15 Der Evaluationsgegenstand stellt folgende Funktionalitäten zur Verfügung:  Unterstützung bei der Erzeugung qualifizierter elektronischer Signaturen;  mathematische Prüfung qualifizierter elektronischer Signaturen (Verifikati- on);  Unterstützung bei der Statusprüfung (Validierung) qualifizierter Zertifikate;  sichere Anzeige von zu signierenden und signierten Daten sowie Verifika- tions- und Validierungsergebnissen. 16 Der Evaluationsgegenstand stellt als Teil einer Signaturanwendungskompo- nente nach SigG/SigV eine Funktionsbibliothek2 – und damit eine Basis für weitere Signaturanwendungskomponenten – dar, die gemäß § 15 Abs. 7 und § 17 Abs. 4 SigG [SigG] sowie § 11 Abs. 3 SigV [SigV] evaluiert, zertifiziert und bestätigt werden. 17 Dementsprechend wird im Folgenden ausschließlich die für die Erfüllung des Signaturgesetzes relevante Funktionalität der Virtuellen Poststelle des Bun- des – nämlich Funktionalitäten zur Signaturbildung und -prüfung – betrachtet. 18 Die der Zertifizierung zu Grunde liegende Evaluierung erfolgt nach Common Criteria (CC) (ISO/IEC 15408). Für die Bestätigung werden Signaturgesetz [SigG] und -verordnung [SigV] berücksichtigt. 1.3 Postulat der Übereinstimmung mit den Common Criteria 19 Der in Abschnitt 2 beschriebene Evaluationsgegenstand (EVG) „Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI)“ ist zu folgenden Teilen der Common Criteria entwickelt:  Teil 2 erweitert [CC-Teil2]; 2 Der Begriff „Teil einer Signaturanwendungskomponente“ wird in der Auflistung der Pro- dukte für qualifizierte elektronische Signaturen auf der Web-Site der Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (Bundesnetzagentur) un- ter www.bundesnetzagentur.de –- in Abgrenzung zu einer „vollständigen Signaturanwen- dungskomponente“ – verwendet und in Funktionsbibliotheken und Chipkartenleser unter- teilt. Die Funktionsbibliothek wird von Client- und Serversystemen genutzt. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 8/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST)  Teil 3 mit Zusatz, EAL3 [CC-Teil3] mit den Zusätzen ADO_DEL.2, ADV_IMP.1, ADV_LLD.1, ALC_TAT.1, AVA_MSU.3 und AVA_VLA.4 (ab- kürzend als EAL3+ bezeichnet). 20 Dabei wird die vom EVG zur Verfügung gestellte Sicherheitsfunktionalität so- wohl aus funktionalen Sicherheitskomponenten aus dem Teil 2 der CC als auch einer explizit dargelegten Sicherheitskomponente zur sicheren Anzeige hergeleitet (vgl. Abschnitt 9). 21 Hinsichtlich Teil 3 der CC soll die OSCI-Komponente als Teil einer Signatur- anwendungskomponente gemäß SigG/SigV die in Anlage 1 der Signatur- verordnung [SigV] definierte Vertrauenswürdigkeitsstufe EAL3 erreichen, wo- bei zusätzlich folgende Anforderungen an die Schwachstellenbewertung bzw. Mechanismenstärke formuliert sind: „Bei den Prüfstufen […] ‚EAL3’ […] ist er- gänzend zu den bei dieser Prüfstufe vorgeschriebenen Maßnahmen gegen ein hohes Angriffspotenzial zu prüfen und eine vollständige Missbrauchsana- lyse durchzuführen“ [SigV, Anlage 1]. Daraus ergibt sich, dass die Signatur- anwendungskomponente insgesamt nach EAL3+ mit folgenden Vertrauens- würdigkeitskomponenten evaluiert wird:  Vertrauenswürdigkeitskomponenten gemäß EAL3: o Konfigurationsmanagement:  ACM_CAP.3 Autorisierungskontrolle;  ACM_SCP.1 EVG-CM-Umfang; o Auslieferung und Betrieb:  ADO_DEL.13 Auslieferungsprozeduren;  ADO_IGS.1 Installations-, Generierungs- und Anlaufprozedu- ren; o Entwicklung:  ADV_FSP.1 Informelle funktionale Spezifikation;  ADV_HLD.2 Sicherheitsspezifischer Entwurf auf hoher Ebe- ne;  ADV_RCR.1 Informeller Nachweis der Übereinstimmung; o Handbücher:  AGD_ADM.1 Systemverwalterhandbuch;  AGD_USR.1 Benutzerhandbuch; o Lebenszyklus-Unterstützung:  ALC_DVS.1 Identifikation der Sicherheitsmaßnahmen; o Testen:  ATE_COV.2 Analyse der Testabdeckung; 3 Diese Vertrauenswürdigkeitskomponente wird durch die höherwertige Systemkompo- nente ADO_DEL.2 ersetzt, vgl. [AIS27]. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 9/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST)  ATE_DPT.1 Testen – Entwurf auf hoher Ebene;  ATE_FUN.1 Funktionales Testen;  ATE_IND.2 Unabhängiges Testen – Stichprobenartig; o Schwachstellenbewertung:  AVA_MSU.14 Prüfung der Handbücher;  AVA_SOF.1 Stärke der EVG-Sicherheitsfunktionen;  AVA_VLA.15 Schwachstellenanalyse des Entwicklers.  Die Prüfung gegen ein hohes Angriffspotential (SOF-hoch) korrespondiert gemäß [CC-Teil3, Abschnitt 14.4] und [CEM, Abschnitt B.8] mit der Ver- trauenswürdigkeitskomponente AVA_VLA.4, was über die Abhängigkei- ten folgende zusätzliche bzw. höhere Vertrauenswürdigkeitskomponenten impliziert: o Entwicklung:  ADV_IMP.1 Teilmenge der Implementierung der TSF;  ADV_LLD.1 Beschreibender Entwurf auf niedriger Ebene;  zugehörig erweiterter Umfang von ADV_RCR.1; o Lebenszyklus-Unterstützung:  ALC_TAT.1 Klar festgelegte Entwicklungswerkzeuge; o Schwachstellenbewertung:  AVA_VLA.4 Hohe Widerstandsfähigkeit.  Die vollständige Missbrauchsanalyse wird durch die folgenden Vertrau- enswürdigkeitskomponenten realisiert: o Auslieferung und Betrieb:  ADO_DEL.2 Erkennung von Modifizierungen; o Schwachstellenbewertung:  AVA_MSU.3 Analysieren und Testen auf unsichere Zustände. 22 Diese Vertrauenswürdigkeitskomponenten entsprechen den Anforderungen aus den im Entwurf vorliegenden „Anwendungshinweisen und Interpretatio- nen zum Schema (AIS)“ Nr. 27 [AIS27]. In AIS 27 werden Vertrauenswürdig- keitskomponenten aufgeführt, die zusätzlich zu den in den EAL-Stufen der Common Criteria ausgewählten Komponenten auszuwählen – d. h. zu aug- mentieren – sind, um den Anforderungen der ITSEC zu genügen. Relevant für diese Sicherheitsvorgaben sind die in Anlage 1 der Signaturverordnung [SigV] beschriebenen Anforderungen hinsichtlich der Stärke der Sicherheits- mechanismen, die mit „hoch“ bewertet werden müssen. 4 Diese Vertrauenswürdigkeitskomponente wird durch die höherwertige Systemkompo- nente AVA_MSU.3 ersetzt, vgl. [AIS27]. 5 Diese Vertrauenswürdigkeitskomponente wird durch die höherwertige Systemkompo- nente AVA_VLA.4 ersetzt. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 10/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) 2 EVG-Beschreibung 2.1 Kompositive Evaluierung 23 Die Evaluierung der Virtuellen Poststelle des Bundes (VPS) wird im Rahmen einer kompositiven Evaluierung durchgeführt, in der die VPS in drei logische Einheiten aufgeteilt wird, die jeweils als ein eigenständiger Evaluationsgegen- stand (EVG) evaluiert, zertifiziert und bestätigt werden. 24 Die drei EVGs sind in Abbildung 2 illustriert:  EVG1: Virtuelle Poststelle des Bundes, Version 2.2.x.x (Basis);  EVG2: Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI);  EVG3: Virtuelle Poststelle des Bundes, Version 2.2.x.x (Verifikationsmo- dul). 25 Diese Sicherheitsvorgaben fokussieren auf den EVG „Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI)“ – abkürzend als OSCI-Komponente be- zeichnet. Trust- Center OSCI- Backend OSCI- Client OSCI- Client- Enabler EVG1: Basis- komponente EVG3: Verifikations- modul EVG2: OSCI-Komponente Verifi- kations- server Verifi- kations- anwen- dung Kernsystem Virtuelle Poststelle des Bundes, Version 2.2 OSCI- Manager OSCI- Backend- Enabler OCSP/CRL-Relay Weitere Systeme Abbildung 2: EVG-Übersicht bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 11/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) 2.2 Online Services Computer Interface (OSCI) 26 Ein wichtiger Standard im E-Government ist das Online Services Computer Interface (OSCI) [OSCI]. Das im OSCI-Protokoll realisierte Kommunikations- modell weist eine Architektur über zwei Ebenen auf:  Absender- und Empfänger-Seite Auf Absender-Seite erzeugt ein Nutzer oder ein Fachverfahren mit Hilfe einer Client-Anwendung eine OSCI-konforme Nachricht. Die Client-Anwendung übernimmt unter anderem die Verschlüs- selung von Dokumenten, die Unterstützung des Signaturschlüs- sel-Inhabers beim Signieren von Daten, die Visualisierung von In- haltsdaten sowie die Verwaltung von Zertifikaten und Signaturen. Auf Empfänger-Seite verhält sich die Client-Anwendung spiegelbildlich: Die Client-Anwendung übernimmt die Entschlüsselung der Nachrichten, das Prüfen von Signaturen und möglicherweise die automatische Weiter- leitung der eingehenden Nachrichten in ein Backend bzw. Fachverfahren, also der elektronischen Datenverarbeitung in der Behörde. Absender- und Empfänger-Seite wird durch einen OSCI-Client bzw. OSCI-Backend realisiert.  OSCI-Intermediär Die Kommunikation zwischen Absender und Empfänger wird über einen Intermediär vermittelt, der wichtige Dienste wie die Zertifikatsprüfung, eine beweiskräftige Protokollierung des Nachrichtenweges oder die Zu- stellung der Nachrichten nach bestimmten Regeln zentral erbringt und damit die an der Kommunikation Beteiligten entlastet. 27 Aufgrund der strikten Trennung von Nutzungs- und Inhaltsdaten (Prinzip des doppelten Umschlags nach OSCI) können beliebig viele Kommunikationspro- zesse mit unterschiedlichen Beteiligten über den Intermediär abgewickelt werden, ohne den datenschutzrechtlichen Grundsatz der Datentrennung zu verletzen (Mehrmandantenfähigkeit). Der Intermediär bzw. die hinter ihm ste- henden Systemadministratoren sind zu keinem Zeitpunkt in der Lage, auf übermittelte Inhaltsdaten im Klartext zuzugreifen. 28 Weitere Informationen sind unter [OSCI] zu finden. 29 Für die OSCI-Kommunikation stellt der EVG wichtige Funktionalitäten zur Verfügung:  OSCI-Client-Enabler für einen OSCI-Client;  OSCI-Manager für den OSCI-Intermediär6 ;  OSCI-Backend-Enabler für ein OSCI-Backend. 30 Bei der OSCI-Kommunikation wird aufgrund des doppelten Umschlags zwi- schen Inhalts- und Nutzungsdaten unterschieden: 6 Zur Realisierung des OSCI-Intermediärs ist neben dem OSCI-Manager zusätzlich eine SigG-konformen Basiskomponente der Virtuellen Poststelle des Bundes notwendig (vgl. [bos_Basis_ST]). bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 12/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST)  Inhaltsdaten können vom Absender mit qualifizierten elektronischen Sig- naturen versehen und mit dem öffentlichen Schlüssel des Empfängers verschlüsselt (innerer Umschlag) werden.  Nutzungsdaten umfassen den inneren Umschlag sowie weitere Kommu- nikationsdaten – wie etwa das Zertifikat des Absenders – und können mit dem öffentlichen Schlüssel des Intermediärs verschlüsselt (äußerer Um- schlag) werden, so dass der Intermediär den o. g. Mehrwert für den Emp- fänger erbringen kann. Das OSCI-Transport-Protokoll erlaubt eine individuelle Konfiguration der Nutzung von Signaturen und Verschlüsselungen. 31 OSCI bedient sich für die Darstellung digitaler Signaturen des XML-Signa- ture-Standards7 . Darüber hinaus wurde für die flexible und performante Ver- arbeitung von Attachments die Realisierung als SOAP-Attachment gewählt. Das bedeutet im Wesentlichen, dass zum Anbringen von Signaturen alle zu signierenden Bereiche (bestehend aus SOAP-Attachments oder aus XML- Teil-Strukturen) über eine für die Kommunikation eindeutige ID sowie dem entsprechenden Hashwert referenziert werden. Über diese Referenzen wird ein Hashwert gebildet, der signiert wird (vgl. [OSCI-Transport, Kap. 4.1]). 32 Zur Darstellung von OSCI-Nachrichten: Der OSCI-Client-Enabler bietet eine sichere Anzeige von folgenden zu signierenden und signierten Daten:8  plain-text (UTF-8-codiert): In dieser Darstellung werden die in der XML- Struktur enthaltenen OSCI-Inhaltsdaten vom EVG interpretiert und ange- zeigt. In dieser Darstellung können in Attachments enthaltene tiff-Dateien – also Bilddaten – nicht angezeigt werden.  tiff-Dateien: In dieser Darstellung werden Bilddaten vom EVG sicher an- gezeigt. Unterstützend können die entsprechenden XML-Daten in Roh-Form, d. h. un- interpretiert, angezeigt werden. Neben der Darstellung der Inhaltsdaten in plain-text (UTF-8-codiert) oder tiff werden weitere Informationen vom OSCI-Client-Enabler dem Benutzer ange- zeigt – beispielsweise das zugehörige Zertifikat sowie Verifikations- und Vali- dierungsergebnisse. 2.3 EVG-Umfang 33 Der Evaluationsgegenstand „Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI)“ stellt zur Realisierung des OSCI-Transport-Protokolls (vgl. [OSCI]) für  OSCI-Client,  OSCI-Intermediär und 7 vgl. http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ 8 Nicht im Umfang der Evaluierung enthalten sind weitere unterstützte Datenformate. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 13/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST)  OSCI-Backend 34 folgende Funktionalitäten für die OSCI-Kommunikation bereit:  Unterstützung bei der Erzeugung qualifizierter elektronischer Signaturen;  mathematische Prüfung qualifizierter elektronischer Signaturen (Verifikati- on);  Unterstützung bei der Statusprüfung (Validierung) qualifizierter Zertifikate;  sichere Anzeige von zu signierenden und signierten Daten sowie Verifika- tions- und Validierungsergebnissen. 35 Der EVG ist eine Funktionsbibliothek2, die auf geeigneter Hardware mit ge- eigneten Betriebsmitteln – insbesondere mit SigG-konformem Chipkartenle- ser und sicheren Signaturerstellungseinheiten (in diesem Fall Signaturkar- ten9 ) – betrieben wird. 36 Der EVG nutzt Funktionalitäten einer SigG-konformen Basiskomponente der Virtuellen Poststelle des Bundes mit Kernsystem, OCSP/CRL-Relay und Net- Signer, die ebenfalls innerhalb der kompositiven Evaluierung der Virtuellen Poststelle des Bundes evaluiert, zertifiziert und bestätigt wird. Funktionalitä- ten und Eigenschaften der Basiskomponente sind in [bos_Basis_ST] näher beschrieben.10 37 Der EVG nutzt darüber hinaus Funktionalitäten von OSCI-Client und -Back- end zur Identifikation und Authentisierung zum Management von Sicherheits- attributen, d. h. den kryptographischen Schlüsseln und (System-)Zertifikaten. 38 Der EVG besteht aus den folgenden Teilsystemen:  OSCI-Client-Enabler;  OSCI-Manager;  OSCI-Backend-Enabler. 39 Der OSCI-Client-Enabler wird auf einem Rechner an einem Arbeitsplatz – beispielsweise in einem Büro – (in einem „geschützten Einsatzbereich (Re- gelfall/Standardlösung)“ [BNetzA2005]) mit einem OSCI-Client betrieben, der von einem Benutzer beispielsweise über eine GUI (Graphical User Interface) benutzt wird. Der OSCI-Client-Enabler verfügt über die Einbindung von Chip- kartenlesern. 40 OSCI-Manager und -Backend-Enabler werden auf Servern in einem Rechen- zentrum (in einem „geschützten Einsatzbereich (Regelfall/Standardlösung)“ [BNetzA2005]) betrieben, mit jeweiligen Web-Oberflächen (GUIs) von Admi- nistratoren konfiguriert und arbeiten im Produktivbetrieb automatisiert und ohne menschliche Aktivitäten. Der OSCI-Backend-Enabler wird von einem OSCI-Backend genutzt. 9 Sichere Signaturerstellungseinheiten gemäß SigG/SigV werden in diesem Kontext aus- schließlich als Chipkarten, also Signaturkarten, realisiert, so dass die Begriffe synonym genutzt werden. 10 Darüber hinaus wird die Basiskomponente für die Gewährleistung der Systemsicherheit genutzt (vgl. Abschnitt 2.4). bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 14/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) 41 Die Teilsysteme können räumlich voneinander getrennt betrieben werden. 42 Der Evaluationsgegenstand stellt folgende Funktionen zur Verfügung:  Der EVG stellt Funktionalitäten zur Unterstützung eines Signaturschlüs- sel-Inhabers bei der Erzeugung einer qualifizierten elektronischen Signa- tur (Individualsignaturen im Sinne der Bundesnetzagentur (vgl. [BNetzA_FAQ18])) bereit, die auf Anforderung des Benutzers lokal er- zeugt werden sollen. Der Signaturschlüssel-Inhaber hat an seinem Arbeitsplatz (mit Chipkar- tenleser) zur Signaturerzeugung unmittelbar Zugriff auf seine Signaturkar- te. Zum Signieren steckt der Benutzer seine Signaturkarte in den Chip- kartenleser, bestätigt die Aktion – woraufhin die zu signierenden Daten der sicheren Signaturerstellungseinheit zugeführt werden, in der sein pri- vater Signaturschlüssel vorgehalten wird – und autorisiert das Signieren durch Eingabe seiner PIN am PIN-Pad des Kartenlesegeräts. Anschlie- ßend wird die Signatur bzw. eine Fehlermeldung an den EVG zurückge- liefert. Der Benutzer wird durch entsprechende Anzeigen des EVG unter- stützt.  Der EVG prüft auf Anforderung des Benutzers die mathematische Kor- rektheit einer qualifizierten elektronischen Signatur. Der EVG führt eine Signaturprüfung durch, d. h. prüft die mathematische Korrektheit der Sig- natur mittels zugehörigem Prüfschlüssel (öffentlichem Schlüssel aus qua- lifiziertem Zertifikat) und geeigneten kryptographischen Verfahren und vi- sualisiert das Verifikationsergebnis (gültige oder ungültige Signatur oder Fehlermeldung).  Der EVG führt auf Anforderung des Benutzers die Statusprüfung eines qualifizierten Zertifikats durch. Gemäß OSCI-Protokoll führt der EVG die Statusprüfung als OSCI-Intermediär durch (siehe nächsten Spiegelstrich), prüft anschließend – aufgrund der Realisierung des EVG durch u. U. räumlich getrennte Teilsysteme – das Ergebnis der Zertifikats-Status- prüfung und visualisiert das Validierungsergebnis. Das Ergebnis der Statusprüfung zum Zeitpunkt der Prüfung beim OSCI- Intermediär – die zeitlich vorher erfolgte – bleibt gültig: Ein zum Prüfzeit- punkt gültiges Zertifikat kann nachträglich nicht ungültig geworden sein.11  Der EVG stellt als OSCI-Intermediär die Gültigkeit eines qualifizierten Zertifikats unter Zuhilfenahme einer Basiskomponente mit Kernsystem und OCSP/CRL-Relay fest. Die Basiskomponente stellt dabei fest, ob das qualifizierte Zertifikat zum Zeitpunkt des Eingangs beim OSCI-Intermediär vorhanden und nicht ge- sperrt war und der Gültigkeitszeitraum des qualifizierten Zertifikats zu die- sem Zeitpunkt bereits begonnen und noch nicht abgelaufen war, und übergibt das Ergebnis der Validierung in Form des Verzeichnisdienst-Er- gebnisses sowie einer Interpretation (gültig und nicht gesperrt, unbekannt oder gesperrt) an den EVG. 11 Für eine aktuelle Validierung sei auf EVG3 „Verifikationsmodul“ verwiesen. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 15/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST)  Der EVG erhält von einem OSCI-Backend die Anforderung12 , die mathe- matische Korrektheit einer qualifizierten elektronischen Signatur zu prü- fen. Der EVG führt eine Signaturprüfung durch, d. h. prüft die mathemati- sche Korrektheit der Signatur mittels zugehörigem Prüfschlüssel (öffentli- chem Schlüssel aus qualifiziertem Zertifikat) und geeigneten kryptogra- phischen Verfahren und liefert das Ergebnis (gültige oder ungültige Sig- natur oder Fehlermeldung) an das OSCI-Backend zurück.  Der EVG erhält von einem OSCI-Backend die Anforderung12, eine Statu- sprüfung eines qualifizierten Zertifikats durchzuführen. Während die ei- gentliche Statusprüfung gemäß OSCI-Protokoll vom OSCI-Intermediär durchgeführt wird, führt der EVG eine Plausibilitätsprüfung durch, in der der EVG prüft, ob das im OSCI-Laufzettel enthaltene Ergebnis der Zertifi- kats-Statusprüfung zum Zertifikat der OSCI-Nachricht passt, und gibt das Validierungsergebnis an das OSCI-Backend zurück. 43 Die Kommunikation zwischen OSCI-Client und OSCI-Client-Enabler sowie zwischen OSCI-Backend und OSCI-Backend-Enabler erfolgt derart abgesi- chert, dass die tatsächliche Anforderung bearbeitet und zutreffende Ergebnis- se zurückliefert werden.13 44 Der EVG wurde ISIS-MTT-konform entwickelt ([ISIS-MTT_SigG]). 45 Zum EVG-Umfang gehört darüber hinaus ein Prüftool zum Schutz vor unbe- fugter Veränderung (vgl. Abschnitt 2.7). 2.4 Technische Realisierung 46 Die OSCI-Komponente besteht aus den Teilsystemen  OSCI-Client-Enabler,  OSCI-Manager und  OSCI-Backend-Enabler inklusive einer Administrationsanwendung als Graphical User Interface (GUI) zur Administration des OSCI-Managers. illustriert die Teilsysteme der OSCI- Komponente. 12 Der EVG wird unter der Annahme betrieben, dass das OSCI-Backend, welches auf die- sen EVG zugreift, eine Signaturanwendungskomponente gemäß SigG/SigV darstellt. 13 Die Kommunikation zwischen OSCI-Client-Enabler und OSCI-Intermediär sowie zwi- schen OSCI-Backend-Enabler und OSCI-Intermediär ist über das OSCI-Transport-Proto- koll abgesichert. Das OSCI-Transport-Protokoll ist nicht Bestandteil der Evaluierung. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 16/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) OSCI- Backend OSCI- Client OSCI- Client- Enabler EVG2: OSCI-Komponente OSCI- Backend- Enabler Kernsystem aus Basis- komponente (EVG1) Administrations- anwendung (GUI) für OSCI-Manager OSCI-Manager Abbildung 3: Teilsysteme des EVG 47 OSCI-Client-Enabler, -Manager und -Backend-Enabler können voneinander getrennt betrieben werden, d. h. nicht innerhalb eines LANs (Local Area Net- works), sondern über ein Weitverkehrsnetz (Wide Area Network – WAN) ver- bunden. 48 Die wesentlichen Aufgaben der Teilsysteme:  OSCI-Client-Enabler:14 o Signieren: Der OSCI-Client-Enabler wendet auf die zu signieren- den Daten eine Hashfunktion gemäß OSCI-Transport (vgl. Ab- schnitt 2.2) an und führt den erzeugten Hashwert einer ange- schlossenen sicheren Signaturerstellungseinheit zu, die eine qua- lifizierte elektronische Signatur erzeugt. Am Arbeitsplatz-PC ist ein Kartenleser installiert. Vor jeder Signaturerzeugung erfolgt die Eingabe einer PIN. Signierte Daten werden im inneren Umschlag des OSCI-Protokolls transportiert. Daten, die dem OSCI-Client- Enabler vom OSCI-Client zum Signieren übergeben werden, sind in einer XML-Struktur codiert. Nachdem eine qualifizierte elektro- nische Signatur durch die Signaturkarte erzeugt wurde, wird die Signatur vom OSCI-Client-Enabler verifiziert; dazu wird das zum 14 Weitere Funktionalitäten, die allerdings nicht Bestandteil der Zertifizierung und Bestäti- gung sind, sind in Abschnitt 1.2 aufgeführt – beispielsweise die Ver- und Entschlüsselung zur Realisierung des doppelten Umschlags gemäß OSCI. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 17/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) privaten Schlüssel korrespondierende Zertifikat genutzt, das sich auf der Signaturkarte befindet und das vor dem Erzeugen der Sig- natur angezeigt wurde. o Verifizieren: Der OSCI-Client-Enabler verifiziert qualifizierte elekt- ronische Signaturen aus dem inneren Umschlag des OSCI-Proto- kolls und zeigt das Verifikationsergebnis sowie die signierten Da- ten an. o Validieren: Der OSCI-Client-Enabler validiert nicht selber, son- dern nutzt das Ergebnis der Validierung vom OSCI-Manager, wel- ches im OSCI-Laufzettel – mit einer elektronischen Signatur ver- sehen – enthalten ist. Der OSCI-Client-Enabler verifiziert diese elektronische Signatur mit dem – dem OSCI-Manager zugeordne- ten – (System-)Zertifikat des OSCI-Managers und prüft, ob das vom OSCI-Manager validierte Zertifikat dasjenige Zertifikat ist, welches der Signatur entspricht (Plausibilitätscheck). Der OSCI- Client-Enabler visualisiert das Validierungsergebnis. Das Ergebnis der Statusprüfung zum Zeitpunkt der Prüfung beim OSCI-Intermediär – die zeitlich vorher erfolgte – bleibt gültig: Ein zum Prüfzeitpunkt gültiges Zertifikat kann nachträglich nicht un- gültig geworden sein. o Sichere Anzeige: Der OSCI-Client-Enabler bietet eine sichere An- zeige von folgenden zu signierenden und signierten Daten:  plain-text (UTF-8-codiert;  tiff-Daten. Darüber hinaus bietet der EVG eine sichere Anzeige von Verifika- tions- und Validierungsergebnis und eine visuelle Unterstützung des Signier-Prozesses (insbesondere Autorisieren des Signie- rens). Der OSCI-Client-Enabler als Funktionsbibliothek nutzt kryptographi- sche Schlüssel und (System-)Zertifikate, die vom OSCI-Client zur Verfügung gestellt werden; eine geeignete Identifikation und Authenti- sierung zum Management dieser Sicherheitsattribute obliegt dem OSCI-Client.  OSCI-Manager:14 Der OSCI-Manager führt als OSCI-Intermediär die Statusprüfung eines qualifizierten Zertifikats durch. Dazu greift der OSCI-Manager auf eine Basiskomponente (vgl. [bos_Basis_ST])15 zu, der die eigentliche Validie- rung durchführt. Der OSCI-Manager interpretiert die Antwort der Basiskomponente und generiert ein eigenes Ergebnis ohne die Original-Verzeichnisdienst-Aus- 15 OSCI-Manager und Kernsystem der Basiskomponente (vgl. [bos_Basis_ST]) werden zusammen in einem vertrauenswürdigen Netz betrieben, so dass der OSCI-Manager dem Prüfergebnis des Kernsystems vertraut. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 18/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) künfte der Basiskomponente, welches der OSCI-Manager im OSCI-Lauf- zettel ablegt. Der OSCI-Laufzettel wird zur Gewährleistung der Systemsicherheit mit ei- ner elektronischen Signatur versehen: Dazu nutzt der OSCI-Manager un- terstützende Sicherheitsmechanismen16 des Kernsystems der Basiskom- ponente, indem das Kernsystem für den vom OSCI-Manager erzeugten und übergebenen Hashwert eine elektronische Signatur erzeugt. Anschließend übergibt der OSCI-Manager im Rahmen des OSCI-Proto- kolls den OSCI-Laufzettel an den OSCI-Client-Enabler bzw. an den OSCI-Backend-Enabler.  OSCI-Backend-Enabler:14 o Verifikation: Der OSCI-Backend-Enabler verifiziert qualifizierte elektronische Signaturen aus dem inneren Umschlag des OSCI- Protokolls.17 Der OSCI-Backend-Enabler übergibt das Verifikati- onsergebnis dem OSCI-Backend. o Validieren: OSCI-Backend-Enabler validiert nicht selber, sondern nutzt das Ergebnis der Validierung vom OSCI-Intermediär, wel- ches im OSCI-Laufzettel – vom OSCI-Manager mit einer elektro- nischen Signatur versehen – enthalten ist. Der OSCI-Backend- Enabler verifiziert diese elektronische Signatur mit dem – dem OSCI-Manager zugeordneten – (System-) Zertifikat des OSCI- Managers und prüft, ob das vom OSCI-Manager validierte Zertifi- kat der zu prüfenden Signatur zuordenbar ist (Plausibilitätscheck).17 Der OSCI-Backend-Enabler übergibt das Validierungsergebnis dem OSCI-Backend. Der OSCI-Backend-Enabler als Funktionsbibliothek nutzt kryptogra- phische Schlüssel und (System-)Zertifikate, die vom OSCI-Backend zur Verfügung gestellt werden; eine geeignete Identifikation und Au- thentisierung zum Management dieser Sicherheitsattribute obliegt dem OSCI-Backend. 49 Kommunikationssicherheit: 16 Das zur Gewährleistung der Systemsicherheit – in diesem Fall die Integrität und Au- thentizität des OSCI-Laufzettels durch eine vom Kernsystem erzeugte elektronische Sig- natur – notwendige Zertifikats- und Schlüssel-Management samt zugehörigen kryptogra- phischen Verfahren wurde in [bos-Basis_ST] beschrieben. Im Rahmen der Evaluierung von EVG1 „Virtuelle Poststelle des Bundes, Version 2.2.x.x (Basis)“ wurde geprüft und festgestellt, dass sichergestellt ist, dass  nur autorisierte Personen auf kryptographische Schlüssel zugreifen können,  sichere kryptographische Verfahren eingesetzt werden (vgl. Fußnote 41) und  Kernsystem und OSCI-Manager in einem vertrauenswürdigen Netz betrieben wer- den. 17 Analog zum OSCI-Client-Enabler, allerdings ohne jegliche Visualisierung. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 19/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST)  OSCI-Client und -Enabler resp. OSCI-Backend und -Enabler kommuni- zieren über (Java-)Funktionsaufrufe und dadurch integer und vertraulich, da die Daten die Virtual Machine nicht verlassen. OSCI-Client und -Client-Enaber sowie OSCI-Backend und -Backend-Enabler werden je- weils zusammen auf einem Rechner betrieben.  Der Kartenleser (in der IT-Umgebung) ist physikalisch über ein Kabel an den Rechner angeschlossen, auf dem der OSCI-Client-Enabler betrieben wird. Zusätzlich wird diese Kommunikation dadurch abgesichert, dass eine soeben erzeugte Signatur vom OSCI-Client-Enabler verifiziert wird.  OSCI-Manager und Kernsystem der Basiskomponente werden zusam- men innerhalb eines vertrauenswürdigen Netzes betrieben.  Die Kommunikation zwischen OSCI-Client und -Intermediär sowie zwi- schen OSCI-Backend und -Intermediär ist über die Mechanismen des OSCI-Transport-Protokolls18 abgesichert. Zusätzlich können OSCI-Ba- ckend und -Manager zusammen in einem vertrauenswürdigen Netz be- trieben werden. 50 Das Prüftool zum Schutz vor unbefugter Veränderung ist in Abschnitt 2.7 be- schrieben. 2.5 Signaturgesetz (SigG) und -verordnung (SigV) 2.5.1 Rechtliche Grundlagen 51 Signaturanwendungskomponenten werden in § 2 Nr. 11 SigG definiert als „Software- und Hardwareprodukte, die dazu bestimmt sind, a) Daten dem Prozess der Erzeugung oder Prüfung qualifizierter elektroni- scher Signaturen zuzuführen oder b) qualifizierte elektronische Signaturen zu prüfen oder qualifizierte Zertifika- te nachzuprüfen und die Ergebnisse anzuzeigen [...]“. 52 Sicherheitsanforderungen an Signaturanwendungskomponenten werden in § 17 Abs. 2 SigG und § 15 Abs. 2 SigV formuliert: 53 § 17 SigG „Produkte für qualifizierte elektronische Signaturen“: „(2) Für die Darstellung zu signierender Daten sind Signaturanwen- dungskomponenten erforderlich, die die Erzeugung einer qualifizier- ten elektronischen Signatur vorher eindeutig anzeigen und feststellen lassen, auf welche Daten sich die Signatur bezieht. Für die Überprü- fung signierter Daten sind Signaturanwendungskomponenten erfor- derlich, die feststellen lassen, 1. auf welche Daten sich die Signatur bezieht, 2. ob die signierten Daten unverändert sind, 3. welchem Signaturschlüssel-Inhaber die Signatur zuzuordnen ist, 18 Das OSCI-Transport-Protokoll ist nicht Bestandteil der Evaluierung. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 20/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) 4. welche Inhalte das qualifizierte Zertifikat, auf dem die Signatur be- ruht, und zugehörige qualifizierte Attribut-Zertifikate aufweisen und 5. zu welchem Ergebnis die Nachprüfung von Zertifikaten nach § 5 Abs. 1 Satz 2 geführt hat. Signaturanwendungskomponenten müssen nach Bedarf auch den In- halt der zu signierenden oder signierten Daten hinreichend erkennen lassen. Die Signaturschlüssel-Inhaber sollen solche Signaturanwen- dungskomponenten einsetzen oder andere geeignete Maßnahmen zur Sicherheit qualifizierter elektronischer Signaturen treffen.“ 54 § 15 SigV „Anforderungen an Produkte für qualifizierte elektronische Signatu- ren“: „(2) Signaturanwendungskomponenten nach § 17 Abs. 2 des Signa- turgesetzes müssen gewährleisten, dass 1. bei der Erzeugung einer qualifizierten elektronischen Signatur a) die Identifikationsdaten nicht preisgegeben und diese nur auf der jeweiligen sicheren Signaturerstellungseinheit gespeichert werden, b) eine Signatur nur durch die berechtigt signierende Person er- folgt, c) die Erzeugung einer Signatur vorher eindeutig angezeigt wird und 2. bei der Prüfung einer qualifizierten elektronischen Signatur a) die Korrektheit der Signatur zuverlässig geprüft und zutref- fend angezeigt wird und b) eindeutig erkennbar wird, ob die nachgeprüften qualifizierten Zertifikate im jeweiligen Zertifikat-Verzeichnis zum angegebe- nen Zeitpunkt vorhanden und nicht gesperrt waren.“ 55 Die Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (Bundesnetzagentur) fasst die Sicherheitsanforderungen in [BNetzA2005] zusammen und konkretisiert sie in Fußnoten: 56 „Erzeugung von Signaturen: Die Signaturanwendungskomponente muss beim Erzeugen einer Signatur gewährleisten, dass  das Erzeugen einer Signatur vorher eindeutig angezeigt wird19 ,  erkennbar ist, auf welche Daten sich die Signatur bezieht20 ,  bei Bedarf der Inhalt der zu signierenden Daten hinreichend zu erkennen ist21 , 19 „Z. B. durch einen Warnhinweis auf dem Bildschirm.“ [BNetzA2005] 20 „Z. B. durch Anzeigen des Dateinamens.“ [BNetzA2005] 21 „Z. B. bei Texten/Graphiken durch vollständige Anzeige des Inhaltes (keine „versteck- ten Texte“) mit eindeutiger Interpretation auf Bildschirm/Ausdruck.“ [BNetzA2005] bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 21/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST)  eine Signatur nur durch die berechtigt signierende Person erfolgt22 ,  die Identifikationsdaten nicht preisgegeben und nur auf der jeweiligen „si- cheren Signaturerstellungseinheit“ gespeichert werden23 . 57 Prüfung einer Signatur: Die Signaturanwendungskomponente muss beim Prüfen einer Signatur gewährleisten, dass  erkennbar wird, auf welche Daten sich die Signatur bezieht,  erkennbar wird, ob die Daten unverändert sind,  bei Bedarf der Inhalt der signierten Daten hinreichend zu erkennen ist,  erkennbar wird, welchem Signaturschlüssel-Inhaber die Signatur zuzu- ordnen ist,  erkennbar wird, welche Inhalte das qualifizierte Zertifikat, auf dem die Si- gnatur beruht, und zugehörige qualifizierte Attribut-Zertifikate aufweisen,  erkennbar wird, ob die nachgeprüften qualifizierten Zertifikate im jeweili- gen Zertifikatverzeichnis zum angegebenen Zeitpunkt vorhanden und nicht gesperrt waren,  die Korrektheit der Signatur zuverlässig geprüft und zutreffend angezeigt wird. 58 Schutz vor unbefugter Veränderung: Sicherheitstechnische Veränderungen an der Signaturanwendungskomponente müssen für den Nutzer erkennbar24 werden.” 22 „Als berechtigt signierende Person gilt, wer sich in der vorgesehenen Weise authenti- siert hat (z. B. durch Besitz = Karte und Wissen = PIN). Es muss sichergestellt sein, dass nach Authentifizierung und der damit verbundenen „Scharfschaltung“ des Signaturschlüs- sels nicht eine andere Person eine Signatur auslösen kann, indem mittels Hacking oder eines trojanischen Pferdes ein elektronisches Dokument (= Hashwert) ‚untergeschoben’ wird.“ [BNetzA2005] 23 „Dies erfordert einen gesicherten Übertragungsweg von der Eingabe der Identifikations- daten zur Signaturerstellungseinheit.“ [BNetzA2005] 24 „Dies kann – abhängig von der Art des Einsatzbereiches (vgl. Abschnitt 4 [BNetzA2005]) – z. B. auf folgende Weise erreicht werden:  Zugriffsicheres Verwahrgelass/zugriffsicherer (Betriebs-)Raum für die Aufbewah- rung der „Signatur-Arbeitstation“, so dass ein Zugriff Unbefugter ausgeschlossen ist oder zumindest mit hoher Sicherheit erkennbar wird,  Prüfsoftware, mit der sicherheitstechnische Veränderungen mit hoher Sicherheit festgestellt werden (dies erfordert, dass auch das „Prüfwerkzeug“ entsprechend vor Manipulation geschützt ist) oder  elektronische Selbstsicherung der Signaturanwendungskomponente, so dass diese im Falle sicherheitserheblicher Veränderungen z. B. automatisch funktionsunfähig wird und die Funktionsfähigkeit nur durch autorisiertes Wartungs-/Reparaturperso- nal wieder hergestellt werden kann.“ [BNetzA2005] bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 22/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) 2.5.2 Signaturgesetz-Anforderungen an den EVG 59 Der EVG ist eine Funktionsbibliothek zur Erzeugung und Prüfung qualifizier- ter elektronischer Signaturen. 60 Im Folgenden wird aufgezeigt und in Tabelle 1 zusammenfassend dargestellt, in welchem Umfang die Sicherheitsanforderungen des SigG und der SigV an Signaturanwendungskomponenten vom EVG erfüllt werden und welcher An- teil von der IT-Umgebung umgesetzt werden muss. Zur Erzeugung von Signaturen 61 Die Sicherheitsanforderungen, dass eine Signaturanwendungskomponente beim Erzeugen einer Signatur gewährleisten muss, dass  „das Erzeugen einer Signatur vorher eindeutig angezeigt wird“,  „erkennbar ist, auf welche Daten sich die Signatur bezieht“ und  „bei Bedarf der Inhalt der zu signierenden Daten hinreichend zu erkennen ist“ ([BNetzA2005]) werden durch den EVG umgesetzt: Der OSCI-Client-Enabler unterstützt den OSCI-Client bei der Erzeugung von qualifizierten elektronischen Signaturen durch eine geeignete Anzeige der prozeduralen Abläufe. Der OSCI-Client- Enabler wendet auf die zu signierenden Daten eine Hashfunktion gemäß OSCI-Transport (vgl. Abschnitt 2.2) an und nutzt eine sichere Signaturerstel- lungseinheit, auf die er über einen angeschlossenen Chipkartenleser zugreift. Darüber hinaus kann der OSCI-Client-Enabler dem Benutzer bei Bedarf die zu signierenden Daten anzeigen. 62 Die Sicherheitsanforderungen, dass eine Signaturanwendungskomponente beim Erzeugen einer Signatur gewährleisten muss, dass  „eine Signatur nur durch die berechtigt signierende Person erfolgt“ und  „die Identifikationsdaten nicht preisgegeben und nur auf der jeweiligen „sicheren Signaturerstellungseinheit“ gespeichert werden“ ([BNetzA2005]) obliegen Chipkartenleser und sichere Signaturerstellungseinheiten in der IT- Umgebung, die – per Annahme/Auflage – die SigG/SigV-Anforderungen er- füllen: Vom Chipkartenleser und der sicheren Signaturerstellungseinheit muss gewährleistet werden, dass eine Signatur nur durch die berechtigt sig- nierende Person erfolgt und dass Identifikationsdaten nicht preisgegeben und nur auf der jeweiligen sicheren Signaturerstellungseinheit abgespeichert wer- den. Zur Prüfung einer Signatur 63 Die Sicherheitsanforderungen, dass eine Signaturanwendungskomponente beim Prüfen einer Signatur gewährleisten muss, dass  „erkennbar wird, auf welche Daten sich die Signatur bezieht,“  „erkennbar wird, ob die Daten unverändert sind,“  „bei Bedarf der Inhalt der signierten Daten hinreichend zu erkennen ist,“ bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 23/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST)  „erkennbar wird, welchem Signaturschlüssel-Inhaber die Signatur zuzu- ordnen ist“,  „erkennbar wird, welche Inhalte das qualifizierte Zertifikat, auf dem die Si- gnatur beruht“, aufweist, 25  „erkennbar wird, ob die nachgeprüften qualifizierten Zertifikate im jeweili- gen Zertifikatverzeichnis zum angegebenen Zeitpunkt vorhanden und nicht gesperrt waren” und  „die Korrektheit der Signatur zuverlässig geprüft und zutreffend angezeigt wird“ ([BNetzA2005]) werden vom EVG umgesetzt: OSCI-Client-Enabler und -Backend- Enabler prüfen die Korrektheit qualifizierter elektronischer Signaturen. Die Anzeige ist nur beim OSCI-Client-Enabler verfügbar, da nur hier Benutzer involviert sind. 64 Die Validierung, „ob die geprüften qualifizierten Zertifikate im jeweiligen Zerti- fikat-Verzeichnis zum angegebenen Zeitpunkt vorhanden und nicht gesperrt waren“ (§ 15 Abs. 2 SigV) erfolgt  hinsichtlich der Validierung bei einer SigG-konformen Basiskomponente in der IT-Umgebung und beim OSCI-Manager,  hinsichtlich der Plausibilitätsprüfung (Gehört das validierte Zertifikat zur Signatur?) bei OSCI-Client-Enabler und -Backend-Enabler und  hinsichtlich der Anzeige beim OSCI-Client-Enabler. Schutz vor unbefugter Veränderung 65 Die Sicherheitsanforderungen zum Schutz vor unbefugter Veränderung – „um sicherheitstechnische Veränderungen an der Signaturanwendungskompo- nente“ [BNetzA2005] für den Nutzer erkennbar zu machen – sind hinsichtlich des EVG in der Weise umzusetzen, dass sowohl die Client-Komponenten am Arbeitsplatz als auch die Server-Komponenten im Serverraum in einem ge- schützten Einsatzbereich eingesetzt werden (vgl. nach [BNetzA2005]). Darü- ber hinaus wird für den OSCI-Client-Enabler ein Prüftool zur Verfügung ge- stellt (EVG-Umfang), um die Integrität zu gewährleisten. 25 Attributzertifikate werden vom EVG nicht unterstützt. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 24/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Tabelle 1: Umsetzung der SigG/SigV-Anforderungen Sicherheitsanforderungen an Si- gnaturanwendungskomponen- ten [BNetzA2005] Umsetzung der Anforderungen aus SigG und SigV in EVG in der IT-Umgebung „Erzeugung von Signaturen: Die Signaturanwendungskompo- nente muss beim Erzeugen ei- ner Signatur gewährleisten, dass zum Erzeugen wendet der OSCI-Client-Enabler auf die zu signierenden Daten eine Hashfunktion gemäß OSCI- Transport an und führt den erzeugten Hashwert der an- geschlossenen sicheren Si- gnaturerstellungseinheit zu; eine erzeugte Signatur wird anschließend verifiziert qualifizierte elektronische Si- gnatur wird durch sichere Si- gnaturerstellungseinheit er- stellt  das Erzeugen einer Signa- tur vorher eindeutig ange- zeigt wird,26 der OSCI-Client-Enabler un- terstützt den Benutzer durch entsprechende Anzeigen -  erkennbar ist, auf welche Daten sich die Signatur bezieht,27 wird im OSCI-Client-Enabler angezeigt -  bei Bedarf der Inhalt der zu signierenden Daten hin- reichend zu erkennen ist,28 kann im OSCI-Client-Enab- ler angezeigt werden -  eine Signatur nur durch die berechtigt signierende Person erfolgt,29 - wird durch sichere Signatur- erstellungseinheit gewähr- leistet 26 vgl. „Für die Darstellung zu signierender Daten sind Signaturanwendungskomponenten erforderlich, die die Erzeugung einer qualifizierten elektronischen Signatur vorher ein- deutlich anzeigen lassen [...]“ [§ 17 Abs. 2 SigG] sowie „Signaturanwendungskomponen- ten nach § 17 Abs. 2 des Signaturgesetzes müssen gewährleisten, dass [...] bei der Er- zeugung einer qualifizierten elektronischen Signatur [...]die Erzeugung einer Signatur vor- her eindeutig angezeigt wird [...].“ [§ 15 Abs. 2 Nr. 1c SigV] 27 vgl. „Für die Darstellung zu signierender Daten sind Signaturanwendungskomponenten erforderlich, die die Erzeugung einer qualifizierten elektronischen Signatur [...] feststellen lassen, auf welche Daten sich die Signatur bezieht.“ [§ 17 Abs. 2 SigG] 28 vgl. „Signaturanwendungskomponenten müssen nach Bedarf auch den Inhalt der zu si- gnierenden [...] Daten hinreichend erkennen lassen.“ [§ 17 Abs. 2 SigG] 29 vgl. „Signaturanwendungskomponenten nach § 17 Abs. 2 des Signaturgesetzes müs- sen gewährleisten, dass [...] bei der Erzeugung einer qualifizierten elektronischen Signa- tur [...] eine Signatur nur durch die berechtigt signierende Person erfolgt [...].“ [§ 15 Abs. 2 Nr. 1b SigV] bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 25/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Sicherheitsanforderungen an Si- gnaturanwendungskomponen- ten [BNetzA2005] Umsetzung der Anforderungen aus SigG und SigV in EVG in der IT-Umgebung „Erzeugung von Signaturen: Die Signaturanwendungskompo- nente muss beim Erzeugen ei- ner Signatur gewährleisten, dass zum Erzeugen wendet der OSCI-Client-Enabler auf die zu signierenden Daten eine Hashfunktion gemäß OSCI- Transport an und führt den erzeugten Hashwert der an- geschlossenen sicheren Si- gnaturerstellungseinheit zu; eine erzeugte Signatur wird anschließend verifiziert qualifizierte elektronische Si- gnatur wird durch sichere Si- gnaturerstellungseinheit er- stellt  die Identifikationsdaten nicht preisgegeben und nur auf der jeweiligen „si- cheren Signaturerstel- lungseinheit“ gespeichert werden.30 - wird durch sichere Signatur- erstellungseinheit sowie Ein- gabe der PIN am PIN-Pad des Chipkartenlesers ge- währleistet 30 vgl. „Signaturanwendungskomponenten nach § 17 Abs. 2 des Signaturgesetzes müs- sen gewährleisten, dass [...] bei der Erzeugung einer qualifizierten elektronischen Signa- tur [...] die Identifikationsdaten nicht preisgegeben und diese nur auf der jeweiligen siche- ren Signaturerstellungseinheit gespeichert werden [...].“ [§15 Abs. 2 Nr. 1a SigV] bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 26/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Sicherheitsanforderungen an Si- gnaturanwendungskomponen- ten [BNetzA2005] Umsetzung der Anforderungen aus SigG und SigV in EVG in der IT-Umgebung „Erzeugung von Signaturen: Die Signaturanwendungskompo- nente muss beim Erzeugen ei- ner Signatur gewährleisten, dass zum Erzeugen wendet der OSCI-Client-Enabler auf die zu signierenden Daten eine Hashfunktion gemäß OSCI- Transport an und führt den erzeugten Hashwert der an- geschlossenen sicheren Si- gnaturerstellungseinheit zu; eine erzeugte Signatur wird anschließend verifiziert qualifizierte elektronische Si- gnatur wird durch sichere Si- gnaturerstellungseinheit er- stellt Prüfung einer Signatur: Die Sig- naturanwendungskomponente muss beim Prüfen einer Signa- tur gewährleisten, dass OSCI-Client-Enabler und OSCI-Backend-Enabler prü- fen qualifizierte elektroni- sche Signaturen. Teilfunktionalitäten der Vali- dierung erfolgen beim OSCI-Manager; Plausibili- tätsprüfung bei OSCI-Client- Enabler und OSCI-Ba- ckend-Enabler;  erkennbar wird, auf welche Daten sich die Signatur bezieht,31 wird vom OSCI-Client-Enab- ler angezeigt -  erkennbar wird, ob die Da- ten unverändert sind,32 die Prüfung, ob Daten un- verändert sind, erfolgt bei OSCI-Client-Enabler und -Backend-Enabler; die entsprechende Anzeige wird vom OSCI-Client-Enab- ler geleistet - 31 vgl. „Für die Überprüfung signierter Daten sind Signaturanwendungskomponenten er- forderlich, die feststellen lassen, [...] auf welche Daten sich die Signatur bezieht [...].“ [§17 Abs. 2 Nr.1 SigG] 32 vgl. „Für die Überprüfung signierter Daten sind Signaturanwendungskomponenten er- forderlich, die feststellen lassen, [...] ob die signierten Daten unverändert sind [...].“ [§17 Abs. 2 Nr.2 SigG] bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 27/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Sicherheitsanforderungen an Si- gnaturanwendungskomponen- ten [BNetzA2005] Umsetzung der Anforderungen aus SigG und SigV in EVG in der IT-Umgebung „Erzeugung von Signaturen: Die Signaturanwendungskompo- nente muss beim Erzeugen ei- ner Signatur gewährleisten, dass zum Erzeugen wendet der OSCI-Client-Enabler auf die zu signierenden Daten eine Hashfunktion gemäß OSCI- Transport an und führt den erzeugten Hashwert der an- geschlossenen sicheren Si- gnaturerstellungseinheit zu; eine erzeugte Signatur wird anschließend verifiziert qualifizierte elektronische Si- gnatur wird durch sichere Si- gnaturerstellungseinheit er- stellt  bei Bedarf der Inhalt der signierten Daten hinrei- chend zu erkennen ist,33 kann vom OSCI-Client-Ena- bler angezeigt werden -  erkennbar wird, welchem Signaturschlüssel-Inhaber die Signatur zuzuordnen ist,34 wird vom OSCI-Cli- ent-Enabler ange- zeigt - 33 vgl. „Signaturanwendungskomponenten müssen nach Bedarf auch den Inhalt der [...] signierten Daten hinreichend erkennen lassen.“ [§17 Abs. 2 SigG] 34 vgl. „Für die Überprüfung signierter Daten sind Signaturanwendungskomponenten er- forderlich, die feststellen lassen, [...] welchem Signaturschlüssel-Inhaber die Signatur zu- zuordnen ist [...].“ [§17 Abs. 2 Nr.3 SigG] bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 28/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Sicherheitsanforderungen an Si- gnaturanwendungskomponen- ten [BNetzA2005] Umsetzung der Anforderungen aus SigG und SigV in EVG in der IT-Umgebung „Erzeugung von Signaturen: Die Signaturanwendungskompo- nente muss beim Erzeugen ei- ner Signatur gewährleisten, dass zum Erzeugen wendet der OSCI-Client-Enabler auf die zu signierenden Daten eine Hashfunktion gemäß OSCI- Transport an und führt den erzeugten Hashwert der an- geschlossenen sicheren Si- gnaturerstellungseinheit zu; eine erzeugte Signatur wird anschließend verifiziert qualifizierte elektronische Si- gnatur wird durch sichere Si- gnaturerstellungseinheit er- stellt  erkennbar wird, welche In- halte das qualifizierte Zerti- fikat, auf dem die Signatur beruht, und zugehörige qualifizierte Attribut-Zertifi- kate25 aufweisen,35 wird vom OSCI-Cli- ent-Enabler ange- zeigt, allerdings wer- den keine Attribut- Zertifikate unter- stützt - 35 vgl. „Für die Überprüfung signierter Daten sind Signaturanwendungskomponenten er- forderlich, die feststellen lassen, [...] welche Inhalte das qualifizierte Zertifikat, auf dem die Signatur beruht, und zugehörige qualifizierte Attribut-Zertifikate aufweisen [...].“ [§17 Abs. 2 Nr. 4 SigG] bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 29/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Sicherheitsanforderungen an Si- gnaturanwendungskomponen- ten [BNetzA2005] Umsetzung der Anforderungen aus SigG und SigV in EVG in der IT-Umgebung „Erzeugung von Signaturen: Die Signaturanwendungskompo- nente muss beim Erzeugen ei- ner Signatur gewährleisten, dass zum Erzeugen wendet der OSCI-Client-Enabler auf die zu signierenden Daten eine Hashfunktion gemäß OSCI- Transport an und führt den erzeugten Hashwert der an- geschlossenen sicheren Si- gnaturerstellungseinheit zu; eine erzeugte Signatur wird anschließend verifiziert qualifizierte elektronische Si- gnatur wird durch sichere Si- gnaturerstellungseinheit er- stellt  erkennbar wird, ob die nachgeprüften qualifizier- ten Zertifikate im jeweili- gen Zertifikatverzeichnis zum angegebenen Zeit- punkt vorhanden und nicht gesperrt waren,36 der OSCI-Manager erzeugt OSCI-Laufzettel mit Validie- rungsergebnis; Plausibilitätsprüfung (Gehört das validierte Zertifikat zur Signatur?) erfolgt bei OSCI- Client-Enabler und -Ba- ckend-Enabler; die entsprechende Anzeige des Validierungsergebnis- ses erfolgt beim OSCI-Cli- ent-Enabler, wobei der im OSCI-Laufzettel angegebe- ne Zeitpunkt der Zeitpunkt ist, zu dem die Nachricht beim OSCI-Manager einge- gangen ist37 die eigentliche Statu- sprüfung (Validie- rung) des Zertifikats erfolgt in der Basis- komponente 36 vgl. „Für die Überprüfung signierter Daten sind Signaturanwendungskomponenten er- forderlich, die feststellen lassen, [...] zu welchem Ergebnis die Nachprüfung von Zertifika- ten nach § 5 Abs. 1 Satz 2 geführt hat. [...].“ [§17 Abs. 2 Nr. 5 SigG] sowie „Signaturan- wendungskomponenten nach § 17 Abs. 2 des Signaturgesetzes müssen gewährleisten, dass [...] bei der Prüfung einer qualifizierten elektronischen Signatur [...] eindeutig erkenn- bar wird, ob die nachgeprüften qualifizierten Zertifikate im jeweiligen Zertifikat-Verzeich- nis zum angegebenen Zeitpunkt vorhanden und nicht gesperrt waren.“ [§ 15 Abs. 2 Nr. 2b SigV] 37 Das Ergebnis der Statusprüfung zum Zeitpunkt der Prüfung beim OSCI-Intermediär – die zeitlich vorher erfolgte – bleibt gültig: Ein zum Prüfzeitpunkt gültiges Zertifikat kann nachträglich nicht ungültig geworden sein. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 30/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Sicherheitsanforderungen an Si- gnaturanwendungskomponen- ten [BNetzA2005] Umsetzung der Anforderungen aus SigG und SigV in EVG in der IT-Umgebung „Erzeugung von Signaturen: Die Signaturanwendungskompo- nente muss beim Erzeugen ei- ner Signatur gewährleisten, dass zum Erzeugen wendet der OSCI-Client-Enabler auf die zu signierenden Daten eine Hashfunktion gemäß OSCI- Transport an und führt den erzeugten Hashwert der an- geschlossenen sicheren Si- gnaturerstellungseinheit zu; eine erzeugte Signatur wird anschließend verifiziert qualifizierte elektronische Si- gnatur wird durch sichere Si- gnaturerstellungseinheit er- stellt  die Korrektheit der Signa- tur zuverlässig geprüft und zutreffend angezeigt wird.38 führen OSCI-Client- Enabler und -Ba- ckend-Enabler durch - Schutz vor unbefugter Verände- rung: Sicherheitstechnische Veränderungen an der Signatur- anwendungskomponente müs- sen für den Nutzer erkennbar werden.” Prüftool für den OSCI-Client-Enabler zum Schutz vor un- befugter Verände- rung wird zur Verfü- gung gestellt für die serverseitigen Komponenten OSCI- Manager und -Back- end-Enabler muss der sichere Betrieb in der Umgebung ge- währleistet werden; für den OSCI-Client- Enabler ist muss der sichere Betrieb am Arbeitsplatz gewähr- leistet werden; zu- sätzliche Absiche- rung zum Integritäts- schutz durch Prüftool 2.6 Produktbestandteile und EVG-Abgrenzung 66 Der Lieferumfang des EVG ist in Tabelle 2 aufgeführt: 38 vgl. „Signaturanwendungskomponenten nach § 17 Abs. 2 des Signaturgesetzes müs- sen gewährleisten, dass [...] bei der Prüfung einer qualifizierten elektronischen Signatur [...] die Korrektheit der Signatur zuverlässig geprüft und zutreffend angezeigt wird [...].“ [§ 15 Abs. 2 Nr. 2a SigV] bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 31/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Tabelle 2: Lieferumfang EVG Liefergegenstand Typ Medium OSCI- Client- Enabler clientenabler.jar, Version 2.2.x.x, Datum, Größe plugin_sdk.jar, Version 2.2.x.x, Datum, Größe verification.jar, Version 2.2.x.x, Datum, Größe verification_modules.jar, Version 2.2.x.x, Datum, Größe standalone_visualization_plugins, Version 2.2.x.x, Da- tum, Größe visualization_modules.jar, Version 2.2.x.x, Datum, Größe Soft- ware Entwicklerdokumentation, Version 2.2.x.x, Datum Doku- mentati- on CD- ROM oder Ar- chiv-Da- tei OSCI- Mana- ger Gov2OsciManager.ear, Version 2.2.x.x, Datum, Größe Gov2OsciServer.ear, Version 2.2.x.x, Datum, Größe Soft- ware Betriebshandbuch, Version 2.2.x.x, Datum Doku- mentati- on CD- ROM oder Ar- chiv-Da- tei OSCI- Back- end- Enabler gov2Backend_Connectors_Common.jar, Version 2.2.x.x.x, Datum, Größe Gov2OsciBackendEnabler.ear, Version 2.2.x.x.x, Datum, Größe Soft- ware Betriebshandbuch, Version 2.2.x.x, Datum Entwicklerdokumentation, Version 2.2.x.x, Datum Doku- mentati- on CD- ROM oder Ar- chiv-Da- tei Prüftool Anwendung (genaue Bezeichnung, Version 2.2.x.x, Da- tum, Größe) Soft- ware Anleitung zum Prüftool, Version 2.2.x.x, Datum Doku- mentati- on CD- ROM oder Ar- chiv-Da- tei 67 Neben der in Tabelle 2 aufgeführten Software werden für den Betrieb des EVG folgende Komponenten benötigt, die somit die technische Einsatzumge- bung definieren:  geeignete Hard- und Software, auf der der EVG betrieben wird; bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 32/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST)  geeignete, SigG-konforme sichere Signaturerstellungseinheiten (Signa- turkarten39 mit entsprechendem Zertifikat) samt SigG-konformem Chip- kartenleser (mit PIN-Pad);  qualifizierte Zertifikate;  kryptographische Schlüssel und (System-)Zertifikate zur Gewährleistung der Systemsicherheit;  Basiskomponente der Virtuellen Poststelle des Bundes (vgl. [bos_Basis_ST]);  OSCI-Client und -Backend, die auf den EVG – d. h. auf OSCI-Client-Ena- bler bzw. -Backend-Enabler – zugreifen und welche die Funktionalitäten des EVG nutzen. Eine exakte Auflistung der technischen Einsatzumgebung findet sich im An- hang in Abschnitt 12. 2.7 Absicherung 68 Die Client-Komponenten40 des EVGs – d. h. der OSCI-Client-Enabler – ist durch ein Prüftool zum Schutz vor unbefugter Veränderung (Integritätsschutz) abgesichert, das im Folgenden näher beschrieben wird.  Das Prüftool überprüft die elektronische Signatur der JAR-Files des OSCI-Client-Enablers.  Das Prüftool kennt die Dateinamen aller JAR-Files, die überprüft werden müssen.  Die JAR-Files sind durch den Hersteller (vgl. Abschnitt 2.8) signiert; die zugehörigen Zertifikate des Herstellers, die die öffentlichen Schlüssel zwecks Verifikation enthalten, sind im Prüftool enthalten.  Dem Anwender wird zu jedem überprüften JAR-File der Dateiname, der Dateipfad, die Version, das jeweilige Prüfergebnis (Signatur korrekt, Sig- natur nicht korrekt) sowie das Gesamtergebnis (Produktintegrität bestä- tigt, Produktintegrität nicht bestätigt) angezeigt. Entsprechende Hinweise und Maßnahmen für den Fall, dass die Produktintegrität nicht bestätigt werden kann, werden im Benutzerhandbuch beschrieben.  Die Integritätsprüfung erfolgt bei gestartetem OSCI-Client-Enabler, d. h. im laufenden Betrieb.  Den Dateipfad der JAR-Files ermittelt das Prüftool aus einem Übergabe- parameter und dem in Java Web Start eingetragenen Pfad des Caches. 39 Sichere Signaturerstellungseinheiten gemäß SigG/SigV werden in diesem Kontext aus- schließlich als Chipkarten, also Signaturkarten, realisiert, so dass die Begriffe synonym genutzt werden. 40 Hinsichtlich der Server-Komponenten (OSCI-Manager und -Backend-Enabler) ist zu berücksichtigen, dass der Schutz vor unbefugter Veränderung durch bauliche und organi- satorische Maßnahmen sichergestellt wird (vgl. A.ServerBetrieb). bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 33/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST)  Werden die JAR-Archive vom Prüftool nicht gefunden, kann der Anwen- der den/die Speicherort/e über den Java-File-Explorer auswählen. 69 Die technische Realisierung des Prüftools:  Das Prüftool ist ein Java-Applet, das vom Hersteller signiert ist.  Der Anwender benötigt die Java Virtual Machine und einen Browser.  Genutzte Hashfunktion: SHA-1 (Mechanismenstärke „hoch“).  Genutzter Verifikationsalgorithmus: RSA mit 1024 bzw. 2048 Bit41 Schlüs- sellänge. 70 Für die Erzeugung der Signatur des Herstellers wird ein privater Schlüssel genutzt, der von einer Zertifizierungsinstanz für die bos KG zertifiziert wurde. 2.8 Auslieferung 71 Die Auslieferung wird wie folgt durchgeführt, wobei an der Auslieferung Her- steller, Vertreiber, Betreiber, Anwendungsentwickler sowie Benutzer beteiligt sind:  Hersteller der Virtuellen Poststelle des Bundes, Version 2.2.X.X (OSCI): bremen online services GmbH & Co. KG Am Fallturm 9 28359 Bremen Der Hersteller liefert den EVG gemäß Auflistung in Tabelle 2 an den Vertreiber (s. u.) aus. Die Auslieferung erfolgt via CD-ROM oder online auf gesicherte Weise.  Vertreiber der Virtuellen Poststelle des Bundes, Version 2.2.X.X (OSCI): bremen online services GmbH & Co. KG Am Fallturm 9 28359 Bremen Der Vertreiber erhält den EVG gemäß Auflistung in Tabelle 2 und reicht die erhaltene Auslieferung unverändert – d. h. via CD-ROM oder online – auf gesicherte Weise an den Betreiber oder einen Anwendungsentwickler weiter.  Betreiber der Virtuellen Poststelle des Bundes, Version 2.2.X.X (OSCI) sind beispielsweise Bundes- oder Landesbehörden. Der Betreiber erhält den EVG gemäß Auflistung in Tabelle 2 vom Vertreiber. Der Betreiber konfiguriert, installiert, administriert und betreibt OSCI-Manager und OSCI-Backend-Enabler. 41 Die Schlüssellänge richtet sich nach dem eingesetzten Zertifikat; Mindestlänge ist 1024 Bit. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 34/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Der Betreiber liefert den OSCI-Client-Enabler, das Prüftool und die zuge- hörige Dokumentation an den Benutzer aus. Die Auslieferung kann über ein Onlineverfahren (beispielsweise Java Web Start) oder durch Zustel- lung einer einmal beschreibbaren CD-ROM auf gesicherte Weise erfol- gen.  Anwendungsentwickler entwickelt auf die EVG-Schnittstellen aufsetzend Signaturanwendungskomponenten42 .  Benutzer sind Anwender des OSCI-Client-Enablers und des Prüftools. 42 Zur Information: Ein Anwendungsentwickler übergibt Signaturanwendungskomponen- ten, die die Funktionalitäten von OSCI-Client-Enabler und -Backend-Enabler nutzen, an den Betreiber. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 35/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) 3 EVG-Sicherheitsumgebung 3.1 Rollen 72 Es gibt im Kontext der OSCI-Komponente folgende Rollen, die hinsichtlich des Standortes differenziert werden: 73 serverseitig:  System-Administrator: Ein System-Administrator ist für die Verwaltung und Organisation der grundlegenden IT-Infrastruktur zuständig, die für den EVG (OSCI-Manager und -Backend-Enabler) benötigt werden.43 Ty- pische Aktivitäten – mit dedizierter Rechtebeschränkung und Protokollie- rung – des System-Administrators sind: o Konfiguration, Betriebsüberwachung und Sicherung von Servern, Be- triebssystem und Datenbank; o Konfiguration und Betriebsüberwachung der Netzwerkkomponenten.  Security-Administrator: Der Security-Administrator ist für den EVG (OSCI-Manager und -Backend-Enabler) zuständig. Typische Aktivitäten – mit dedizierter Rechtebeschränkung, Protokollierung und Vier-Augen- Prinzip – des Security-Administrators sind: o Verwaltung (Hinzufügen, Update, Löschen) der unterschiedlichen Me- thoden, die der EVG zur Verfügung stellt (kryptographische Funktio- nen, Sicherheitsdienste, Anbindung externer Systeme); o Software-Updates (Einbringung von Patches, Austausch von Soft- ware-Komponenten); o Datensicherung (Initiieren, Prüfung des Resultats, Setzen, Ändern und Löschen von periodischen Abläufen); o Konfiguration der Authentisierungssysteme für Administration (Rechte der Rollen setzen, ändern und löschen, Administratoren-Rollen konfi- gurieren) – in Zusammenarbeit mit dem Revisor; o System-Starts (Starten, Stoppen und Rücksetzen des EVGs).  Schlüssel-Administrator: Der Schlüssel-Administrator verwaltet die im EVG (OSCI-Manager) benötigte Referenz auf den kryptographischen Schlüssel zur Gewährleistung der Systemsicherheit.16  Revisor: Der Revisor prüft beim EVG (OSCI-Manager und -Backend- Enabler) die Sicherheitsparameter, konfiguriert die Protokollierung und wertet sie aus und begleitet den Security-Administrator zur Gewährleis- tung des Vier-Augen-Prinzips. Typische Aktivitäten des Revisors sind: o Aufruf der Monitoring-Konsole zum Check des System-Status; 43 Der System-Administrator kann beispielsweise ein Administrator bei einem Dienst- leister sein, der die Systeme hostet. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 36/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) o Lesen von Teilen der Konfiguration; kein Ändern der Konfiguration. 74 clientseitig:  Benutzer: Der Benutzer in der IT-Umgebung nutzt den OSCI-Client – und damit den OSCI-Client-Enabler. Typischerweise wird der Benutzer der Signaturschlüssel-Inhaber sein (s. u.).  Signaturschlüssel-Inhaber: Der Signaturschlüssel-Inhaber gibt am Chipkartenleser des OSCI-Client-Enablers in der IT-Umgebung seine PIN zur Erstellung einer qualifizierten elektronischen Signatur durch die siche- re Signaturerstellungseinheit ein. 75 allgemein:  Anwendungsentwickler: Eine Person, die auf Basis von OSCI-Client- Enabler oder -Backend-Enabler eine Signaturanwendungskomponente entwickelt.  nicht autorisierte Person: Eine nicht autorisierte Person ist jede Person – während des EVG-Betriebs –, die weder System-, Security- oder Schlüssel-Administrator noch Revisor, Benutzer oder Signaturschlüssel- Inhaber ist. 3.2 Annahmen 76 Die in diesem Abschnitt aufgeführten Annahmen stellen die Auflagen für den Betrieb dar. 77 A.PKI Die für den Betrieb der Virtuellen Poststelle notwendigen Systemkomponenten der Public-Key-Infrastruktur (PKI) sind vorhanden:  SigG-konforme sichere Signaturerstellungseinheiten;  SigG-konformer Chipkartenleser;  qualifizierte Zertifikate;  private Schlüssel und (System-)Zertifikate (zur Gewähr- leistung der Systemsicherheit);  Basiskomponente der Virtuellen Poststelle des Bundes für die Validierung von qualifizierten Zertifikaten (vgl. [bos_Basis_ST]). Dabei werden geeignete kryptographische Verfahren mit entsprechenden Schlüssellängen eingesetzt. Eine Verbindung zur Basiskomponente ist vorhan- den. Eine Auflistung findet sich im Anhang in Abschnitt 12. 78 A.SAK OSCI-Client und -Backend, die auf den EVG – d. h. auf OSCI-Client-Enabler bzw. -Backend-Enabler – zugreifen und die die Funktio- nalitäten des EVG nutzen, stehen zur Verfügung. Die Anforderungen von Sig- bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 37/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) naturgesetz und -verordnung an eine Signaturanwendungskomponente wer- den beachtet. Insbesondere gewährleisten sie die Funktionalitäten hinsicht- lich Identifikation und Authentisierung zum Management von Sicherheitsattri- buten, d. h. den kryptographischen Schlüsseln und (System-)Zertifikaten. Durch den OSCI-Client bzw. -Backend ist gewähr- leistet, dass auf Anforderung des Benutzers resp. Security-Administrators angezeigt wird, welcher OSCI-Manager angesprochen wird – durch Adresse und (System-) Zertifikat. 79 A.ServerBetrieb Für den Betrieb ist vertrauenswürdiges Personal eingesetzt, das einen Beitrag zur Sicherheit leistet, und die notwendigen räumlichen Ge- gebenheiten sowie Hard- und Software für den sicheren Betrieb der server- seitigen Komponenten des EVG (OSCI-Manager und -Backend-Enabler) sind vorhanden. Es sind verschiedene Administratoren für die ver- schiedenen Aufgaben benannt, die einen Beitrag zur Sicherstellung einer vertraulichen und integren Be- triebsumgebung des EVG leisten. Ein Vier-Augen- Prinzip mit Revisor ist für wichtige Aktivitäten organi- satorisch realisiert. Es wird gewährleistet, dass der EVG korrekt aufge- baut ist, inkl. Einhaltung der Vorgaben hinsichtlich der räumlichen Gegebenheiten und für die Realisie- rung der Netzwerkarchitektur und der internen Ver- bindungen zwischen den einzelnen Systemkompo- nenten mit Firewall, Demilitarisierter Zone (DMZ) etc. Vgl. dazu die Vorgaben und Auflagen zum Betrieb der Virtuellen Poststelle, die im „Generischen Sicher- heitskonzept für die Kern- und Webkomponenten der Virtuellen Poststelle“ beschrieben werden [VPS- SiKo]. OSCI-Manager und Kernsystem der Basis- komponente ([bos_Basis_ST]) werden zusammen in- nerhalb eines vertrauenswürdigen Netzes betrieben. Der OSCI-Backend-Enabler als Funktionsbibliothek nutzt kryptographische Schlüssel und (System-)Zerti- fikate, die vom OSCI-Backend zur Verfügung gestellt werden; eine geeignete Identifikation und Authenti- sierung zum Management dieser Sicherheitsattribute wird vom OSCI-Backend sichergestellt. Die Anforderungen aus [BNetzA2005] an einen „ge- schützten Einsatzbereich (Regelfall/Standardlösung)“ werden umgesetzt, um „potentielle Angriffen über das Internet, ein angeschlossenes Intranet, einen manuellen Zugriff Unbefugter und einen Datenaus- bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 38/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) tausch per Datenträger [...] durch eine Kombination von Sicherheitsvorkehrungen in der Signatur- anwendungskomponente selbst und der Einsatz- umgebung mit hoher Sicherheit“ hinsichtlich eines hohen Angriffspotentials abzuwehren:  Auflagen zur Anbindung an das Internet/Intranet: Es wird angenommen, dass Netzwerkverbindungen so abgesi- chert sind, dass Angriffe erkannt bzw. unterbunden wer- den – z. B. durch eine geeignet konfigurierte Firewall, geeignete Absicherung des LAN und durch die Verwen- dung geeigneter Anti-Viren-Programme;  Auflagen zur Sicherheit der IT-Plattform und Applikatio- nen: Es wird angenommen, dass gewährleistet wird, dass von der Hardware, auf der der EVG betrieben wird, keine Angriffe ausgehen. Insbesondere ist sicherzustel- len, dass die auf dem eingesetzten Computer installierte Software nicht böswillig manipuliert oder verändert wer- den kann, auf dem Computer keine Viren oder Trojani- schen Pferde eingespielt werden können, die Hardware des Computers nicht unzulässig verändert werden kann.  Auflagen zum Schutz vor manuellem Zugriff Unbefugter und Datenaustausch per Datenträger: Es wird angenom- men, dass die folgenden baulichen, personellen und or- ganisatorischen Anforderungen umgesetzt sind: o Rechner, Monitor und Tastatur befinden sich in einem Betriebsraum. o Für die Administratoren müssen Vertreterrege- lungen für Krankheit und Urlaub bestehen. o Wartungs- bzw. Reinigungspersonal erhält den Zugang zum zugriffssicheren Betriebsraum nur durch einen Administrator, der den Aufenthalt überwacht. 80 A.ClientBetrieb Signaturschlüssel-Inhaber leisten einen Beitrag zur Sicher- heit, indem sie sich beispielsweise vergewissern, dass sie bei der Eingabe ih- res Identifikationsmerkmals nicht beobachtet werden, oder ihr Identifikations- merkmal ändern, wenn sie den Verdacht oder die Gewissheit haben, Ihr Merkmal könnte nicht mehr geheim sein. Es wird gewährleistet, dass der OSCI-Client-Enabler korrekt aufgebaut ist, inkl. Einhaltung der Vorgaben hinsichtlich der räumlichen Gegebenheiten und für die Realisierung der Netzwerkarchitektur mit Firewall etc. Vgl. dazu die Vorgaben und Auflagen zum Be- trieb der Virtuellen Poststelle, die im „Generischen Sicherheitskonzept für die Kern- und Webkomponen- bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 39/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) ten der Virtuellen Poststelle“ beschrieben werden [VPS-SiKo]. Der OSCI-Client-Enabler als Funktionsbibliothek nutzt kryptographische Schlüssel und (System-)Zerti- fikate, die vom OSCI-Client zur Verfügung gestellt werden; eine geeignete Identifikation und Authenti- sierung zum Management dieser Sicherheitsattribute wird vom OSCI-Client sichergestellt. Der OSCI-Client sichert auch die Integrität der kryptographischen Schlüssel und (System-)Zertifikate – denkbar ist, dass diese Sicherheitsattribute Bestandteil der integ- ritätsgeschützten Software sind oder dass diese Konfigurationsdaten – ähnlich wie bei EVG3 – ge- sondert abgesichert werden. Die Anforderungen aus [BNetzA2005] an einen „ge- schützten Einsatzbereich (Regelfall/Standardlösung)“ werden umgesetzt, um „potentielle Angriffen über das Internet, ein angeschlossenes Intranet, einen manuellen Zugriff Unbefugter und einen Datenaus- tausch per Datenträger [...] durch eine Kombination von Sicherheitsvorkehrungen in der Signatur- anwendungskomponente selbst und der Einsatz- umgebung mit hoher Sicherheit“ hinsichtlich eines hohen Angriffspotentials abzuwehren:  Auflagen zur Anbindung an das Internet/Intranet: Es wird angenommen, dass Netzwerkverbindungen so abgesi- chert sind, dass Angriffe erkannt bzw. unterbunden wer- den – z. B. durch eine geeignet konfigurierte Firewall, und durch die Verwendung geeigneter Anti-Viren-Pro- gramme;  Auflagen zur Sicherheit der IT-Plattform und Applikatio- nen: Es wird angenommen, dass gewährleistet wird, dass von der Hardware, auf der der EVG betrieben wird, keine Angriffe ausgehen. Insbesondere ist sicherzustel- len, dass die auf dem eingesetzten Computer installierte Software nicht böswillig manipuliert oder verändert wer- den kann, auf dem Computer keine Viren oder Trojani- schen Pferde eingespielt werden können, die Hardware des Computers nicht unzulässig verändert werden kann, der verwendete Chipkartenleser nicht böswillig manipu- liert wurde, um Daten (z. B. PIN, Hashwerte etc.) auszu- forschen oder zu verändern.  Auflagen zum Schutz vor manuellem Zugriff Unbefugter und Datenaustausch per Datenträger: Es wird angenom- men, dass die folgenden baulichen, personellen und or- ganisatorischen Anforderungen umgesetzt sind: bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 40/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) o Aufbewahrung der PIN: Es wird angenommen, dass der Signaturschlüssel-Inhaber die PIN der Signaturkarte nicht weitergibt und die Regelun- gen zum Umgang mit der sicheren Signaturer- stellungseinheit, die der Hersteller dem Benutzer mitgeteilt hat, umsetzt. o Raum des Arbeitsplatzes: Es ist Sorge zu tragen, dass ein Zugriff Unbefugter ausgeschlossen ist oder zumindest mit hoher Sicherheit erkennbar wird – beispielsweise durch ein Sperren des Bild- schirmes oder Verschließen des Büros bei Ab- wesenheit. o Rechner und Chipkartenleser sind durch einen sicheren Kanal per Kabel verbunden. o Der Benutzer hat vor Gebrauch mit einem vom Hersteller zur Verfügung gestellten Prüftool die Integrität des OSCI-Client-Enablers zu prüfen – vgl. Abschnitt 2.7. o Bei der Installation hat der Benutzer die Integrität und Authentizität des OSCI-Client-Enablers mit dem vom Hersteller zur Verfügung gestellten Prüftool zu prüfen – vgl. Abschnitt 2.7. 81 A.ZufPIN In der Einsatzumgebung zwischen SigG-konformem Chip- kartenleser (mit PIN-Pad) und Signaturkarte wird gewährleistet, dass die Identifikationsdaten nicht preisgegeben und nur auf der jeweiligen sicheren Signaturerstellungseinheit gespeichert werden. 3.3 Bedrohungen 82 TE.RatePIN Falls eine nicht autorisierte Person in den Besitz der siche- ren Signaturerstellungseinheit gelangt, könnte diese Person versuchen, das Identifikationsmerkmal zu erraten. Die nicht autorisierte Person kann ein ho- hes Angriffspotenzial aufweisen und über Fachkenntnisse verfügen. 83 TE.SpähePIN Eine nicht autorisierte Person könnte versuchen, das Identifi- kationsmerkmal auszuspähen. Die nicht autorisierte Person kann ein hohes Angriffspotenzial aufweisen und über Fachkenntnisse verfügen. 84 Weitere Bedrohungen ergeben sich implizit durch Nennung organisatorischer Sicherheitspolitiken. 3.4 Organisatorische Sicherheitspolitiken44 85 P.SignaturZuf Der EVG (hier: OSCI-Client-Enabler) muss beim Erzeugen einer Signatur gewährleisten, dass auf die zu signierenden Daten eine Hash- 44 Die für den EVG relevanten organisatorischen Sicherheitspolitiken ergeben sich aus den Anforderungen von Signaturgesetz und -verordnung (vgl. Abschnitt 2.5). bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 41/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) funktion gemäß OSCI-Transport (vgl. Abschnitt 2.2) angewendet und der Hashwert einer sicheren Signaturerstellungseinheit zugeführt wird. 86 P.Anzeige Der EVG (hier: OSCI-Client-Enabler) muss gewährleisten, dass beim Erzeugen einer Signatur  das Erzeugen einer Signatur vorher eindeutig angezeigt wird,  erkennbar ist, auf welche Daten sich die Signatur be- zieht, und  bei Bedarf der Inhalt der zu signierenden Daten hinrei- chend zu erkennen ist und beim Prüfen einer Signatur  erkennbar wird, auf welche Daten sich die Signatur be- zieht,  erkennbar wird, ob die Daten unverändert sind,  bei Bedarf der Inhalt der signierten Daten hinreichend zu erkennen ist,  erkennbar wird, welchem Signaturschlüssel-Inhaber die Signatur zuzuordnen ist,  erkennbar wird, welche Inhalte das qualifizierte Zertifikat, auf dem die Signatur beruht, aufweist und  erkennbar wird, ob die nachgeprüften qualifizierten Zerti- fikate im jeweiligen Zertifikatverzeichnis zum angegebe- nen Zeitpunkt vorhanden und nicht gesperrt waren. 87 P.ValidZert Der EVG muss beim Prüfen einer Signatur gewährleisten, dass festgestellt wird, ob die nachgeprüften qualifizierten Zertifikate im jewei- ligen Zertifikatverzeichnis zum angegebenen Zeitpunkt vorhanden und nicht gesperrt waren. 88 P.VerifySign Der EVG muss beim Prüfen einer Signatur gewährleisten, dass die Korrektheit der Signatur zuverlässig geprüft wird. 89 P.Manipulation Der EVG muss zum Schutz vor unbefugter Veränderung am OSCI-Client-Enabler gewährleisten, dass sicherheitstechnische Veränderun- gen festgestellt werden können. Erklärung 1Die organisatorischen Sicherheitspolitiken entstammen den für den EVG relevanten Anforderungen des Signaturgesetzes und der -ver- ordnung, wie in [BNetzA2005] zusammenfassend dargestellt (vgl. Abschnitt 2.5.2 und Tabelle 1). bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 42/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) 4 Sicherheitsziele 4.1 EVG-Sicherheitsziele 90 O.SignaturZuf Der EVG (hier: OSCI-Client-Enabler) muss zum Erzeugen einer qualifizierten elektronischen Signatur auf die zu signierenden Daten eine Hashfunktion gemäß OSCI-Transport (vgl. Abschnitt 2.2) anwenden, den erzeugten Hashwert einer angeschlossenen sicheren Signaturerstel- lungseinheit zuführen, wo die qualifizierte elektronische Signatur erzeugt wird, und anschließend durch Verifikation der zuvor erzeugten Signatur mit dem auf der sicheren Signaturerstellungseinheit befindlichen Zertifikat prüfen, ob für die korrekten zu signierenden Daten eine Signatur generiert wurde. Erklärung 2Das Sicherheitsziel O.SignaturZuf deckt die organisatorische Si- cherheitspolitik P.SignaturZuf zur Erzeugung einer qualifizierten elektroni- schen Signatur ab und präzisiert, dass der OSCI-Client-Enabler die zu signie- renden Daten gemäß OSCI-Transport der Hashfunktion zuführt und den Hashwert einer sicheren Signaturerstellungseinheit in der IT-Umgebung (vgl. OE.PKI) zugeführt. Zusätzlich wird durch die Verifikation der zuvor durch die Signaturkarte generierte qualifizierte elektronische Signatur mit dem auf der Signaturkarte befindlichen Zertifikat gewährleistet, dass für die richtigen Da- ten eine Signatur erzeugt wurde. 91 O.Anzeige Der EVG (hier: OSCI-Client-Enabler) muss gewährleisten, dass dem Benutzer folgende Informationen angezeigt werden bzw. bei Be- darf – d. h. optional – angezeigt werden können:  Erzeugen einer Signatur durch prozedurale Anzeigetex- te;  Bezug zu den Daten, auf die sich die Signatur bezieht – beim Signieren und Verifizieren;  Ergebnis der Verifikation einer qualifizierten elektroni- schen Signatur;  Ergebnis der Validierung eines qualifizierten Zertifikats;  zu signierende und signierte Daten (optional);  Signaturschlüssel-Inhaber der Signatur (optional);  Zertifikatsinhalt (optional). Erklärung 3Das Sicherheitsziel O.Anzeige deckt die organisatorische Sicher- heitspolitik P.Anzeige zur sicheren und zuverlässigen Anzeige bei der Erzeu- gung und Prüfung qualifizierter elektronischer Signaturen beim OSCI-Client- Enabler ab. Dabei wird durch die Verifikation festgestellt, ob die Daten unver- ändert sind. Die Anzeige umfasst nicht nur, was signiert wird und wurde, son- dern auch ergänzende Informationen zur Nachricht, wie Zertifikatsinhalt, Sig- naturschlüssel-Inhaber und Verifikations- und Validierungsergebnisse. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 43/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) 92 O.ValidZert Der EVG muss bei der Gültigkeitsprüfung eines qualifizierten Zertifikats  die Funktionalitäten einer Basiskomponente45 anfordern (OSCI-Manager) und  eine Plausibilitätsprüfung (Prüfung, ob das validierte Zer- tifikat zur Signatur gehört.) sowie Verifikation des OSCI- Laufzettels mit dem Validierungsergebnis des OSCI-Ma- nagers beim OSCI-Client-Enabler und -Backend-Enabler vornehmen. Erklärung 4Das Sicherheitsziel O.ValidZert deckt die organisatorische Si- cherheitspolitik P.ValidZert zur Validierung qualifizierter Zertifikate ab und präzisiert die Aufgabenteilung. Zu berücksichtigen ist, dass die wesentlichen Aufgaben bei der Validierung in der IT-Umgebung durch die Basiskomponen- te (vgl. Sicherheitsziel für die IT-Umgebung OE.PKI) geleistet wird und dass zur Gewährleistung der Systemsicherheit (innerhalb des verteilten System) die Sicherheitsziele für die IT-Umgebung OE.ServerBetrieb und OE.ClientBetrieb benötigt werden. 93 O.VerifySign Der EVG muss die mathematische Korrektheit einer qualifi- zierten elektronischen Signatur zuverlässig prüfen, indem folgende Prüfun- gen durchgeführt werden:  Prüfung der Integrität: Der Hashwert des signierten Do- kuments muss mit dem übermittelten Hashwert überein- stimmen, wobei die Hashwertbildung gemäß OSCI- Transport (vgl. Abschnitt 2.2) zu berücksichtigen ist.  Prüfung der Authentizität: Dieser Hashwert muss gleich dem Ergebnis sein, das durch Anwendung des öffentli- chen Signaturschlüssels auf die elektronische Signatur mit einem geeigneten kryptographischen Algorithmus berechnet wird. Erklärung 5Das Sicherheitsziel O.VerifySign deckt die organisatorische Si- cherheitspolitik P.VerifySign zur Prüfung einer qualifizierten elektronischen Signatur ab und präzisiert, dass die Verifikation durch die Prüfung der Integri- tät und der Authentizität erfolgt (qualifizierte Zertifikate via Sicherheitsziel für die IT-Umgebung OE.PKI). 94 O.Manipulation Der EVG muss zum Schutz vor unbefugter Veränderung am OSCI-Client-Enabler gewährleisten, dass durch Integritätsprüfung festgestellt werden kann, ob Veränderungen am OSCI-Client-Enabler vorgenommen wurden. Erklärung 6Das Sicherheitsziel O.Manipulation deckt die organisatorische Sicherheitspolitik P.Manipulation zum Schutz vor unbefugter Veränderung des OSCI-Client-Enablers ab. 45 Wie bereits in Abschnitten 2.3 und 2.4 ausgeführt, wird die eigentliche Validierung von der Basiskomponente durchgeführt. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 44/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) 4.2 Sicherheitsziele für die Umgebung 95 Neben EVG-Sicherheitszielen sind Sicherheitsziele für die Umgebung not- wendig, um die Sicherheit des EVG zu gewährleisten. 96 OE.PKI Die IT-Umgebung muss die für den Betrieb benötigten SigG- konformen Komponenten bereitstellen:  sichere Signaturerstellungseinheit mit geeigneten krypto- graphischen Parametern (Verfahren und Schlüssellän- gen);  Chipkartenleser mit PIN-Pad;  qualifizierte Zertifikate mit geeigneten kryptographischen Parametern (Verfahren und Schlüssellängen);  private Schlüssel und (System-)Zertifikate mit geeigne- ten kryptographischen Parametern (Verfahren und Schlüssellängen) zur Gewährleistung der Systemsicher- heit;  Basiskomponente der Virtuellen Poststelle des Bundes für die Validierung von qualifizierten Zertifikaten (vgl. [bos_Basis_ST]), in der die Gültigkeit eines qualifizierten Zertifikats zuverlässig festgestellt wird, indem für das an- geforderte Zertifikat festgestellt wird, ob o das Zertifikat zum Prüfzeitpunkt (Eingang auf dem Server) vorhanden und nicht gesperrt war und o der Gültigkeitszeitraum des Zertifikats zum ange- gebenem Prüfzeitpunkt bereits begonnen und noch nicht abgelaufen war, und für die Zertifikate der Zertifikatskette festge- stellt wird, ob o ein Ausstellerzertifikat zum Signierzeitpunkt des ausgestellten Zertifikats vorhanden und nicht ge- sperrt war und o der Gültigkeitszeitraum eines Ausstellerzertifikats zum Signierzeitpunkt des ausgestellten Zertifi- kats bereits begonnen und noch nicht abgelau- fen war. Darüber hinaus wird ein unterstützender Sicher- heitsmechanismus der Basiskomponente für die Erzeugung einer elektronischen Signatur für ei- nen vom OSCI-Manager erzeugten und überge- benen Hashwert zum Signieren des OSCI-Lauf- zettels genutzt. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 45/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Erklärung 7Das Sicherheitsziel für die Umgebung OE.PKI zielt auf die gleichnamige Annahme A.PKI ab, wobei zu berücksichtigen ist, dass OE.PKI auch für die organisatorischen Sicherheitspolitiken P.SignaturZuf (für die Er- zeugung einer qualifizierten elektronischen Signatur durch die sichere Signa- turerstellungseinheit mittels Chipkartenleser), P.ValidZert (für die Gültigkeits- prüfung durch obige Funktionalitäten der Basiskomponenten, für die Existenz qualifizierter Zertifikate sowie die kryptographischen Schlüssel und (System-)Zertifikate zur Gewährleistung der Systemsicherheit) sowie P.VerifySign (für Existenz qualifizierter Zertifikate) benötigt werden. Zudem wehrt OE.PKI die Bedrohung TE.RatePIN durch Verwendung einer geeigne- ten Signaturkarte ab. 97 OE.SAK Die IT-Umgebung muss OSCI-Client und -Backend zur Ver- fügung stellen, die auf den EVG – d. h. auf OSCI-Client-Enabler bzw. -Ba- ckend-Enabler – zugreifen, die die Funktionalitäten des EVG nutzen und wel- che die Anforderungen von Signaturgesetz und -verordnung an eine Signa- turanwendungskomponente beachten. Insbesondere gewährleisten sie die Funktionalitäten hinsichtlich Identifikation und Authentisierung zum Manage- ment von Sicherheitsattributen, d. h. den kryptographischen Schlüsseln und den (System-) Zertifikaten. In der IT-Umgebung muss beim OSCI-Client bzw. -Backend gewährleistet sein, dass auf Anforderung des Benutzers resp. Security-Administrators ange- zeigt wird, welcher OSCI-Manager angesprochen wird – durch Adresse und (System-) Zertifikat. Erklärung 8Das Sicherheitsziel für die Umgebung OE.SAK zielt auf die gleichnamige Annahme A.SAK ab. 98 OE.ServerBetrieb Für den Betrieb muss vertrauenswürdiges Personal einge- setzt werden, das einen Beitrag zur Sicherheit leistet, und die notwendigen räumlichen Gegebenheiten sowie Hard- und Software für den sicheren Be- trieb der serverseitigen Komponenten des EVG (OSCI-Manager und -Ba- ckend-Enabler) sind vorhanden. Es müssen verschiedene Administratoren für die ver- schiedenen Aufgaben benannt sein, die einen Bei- trag zur Sicherstellung einer vertraulichen und integ- ren Betriebsumgebung des EVG leisten. Ein Vier-Au- gen-Prinzip mit Revisor muss für wichtige Aktivitäten organisatorisch realisiert sein. Es muss gewährleistet sein, dass der EVG korrekt aufgebaut ist, inkl. Einhaltung der Vorgaben hinsicht- lich der räumlichen Gegebenheiten und für die Reali- sierung der Netzwerkarchitektur und der internen Verbindungen zwischen den einzelnen Systemkom- ponenten mit Firewall, Demilitarisierter Zone (DMZ) etc. Vgl. dazu die Vorgaben und Auflagen zum Be- trieb der Virtuellen Poststelle, die im „Generischen bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 46/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Sicherheitskonzept für die Kern- und Webkomponen- ten der Virtuellen Poststelle“ beschrieben werden [VPS-SiKo]. OSCI-Manager und Kernsystem der Basiskompo- nente ([bos_Basis_ST]) müssen zusammen inner- halb eines vertrauenswürdigen Netzes betrieben werden. Der OSCI-Backend-Enabler als Funktionsbibliothek nutzt kryptographische Schlüssel und (System-)Zerti- fikate, die vom OSCI-Backend zur Verfügung gestellt werden; eine geeignete Identifikation und Authenti- sierung zum Management dieser Sicherheitsattribute muss durch den OSCI-Backend sichergestellt wer- den. Die Anforderungen aus [BNetzA2005] an einen „ge- schützten Einsatzbereich (Regelfall/Standardlösung)“ müssen umgesetzt sein, um „potentielle Angriffen über das Internet, ein angeschlossenes Intranet, ei- nen manuellen Zugriff Unbefugter und einen Daten- austausch per Datenträger [...] durch eine Kombinati- on von Sicherheitsvorkehrungen in der Signatur- anwendungskomponente selbst und der Einsatz- umgebung mit hoher Sicherheit“ hinsichtlich eines hohen Angriffspotentials abzuwehren:  Auflagen zur Anbindung an das Internet/Intranet: Netz- werkverbindungen müssen so abgesichert sind, dass Angriffe erkannt bzw. unterbunden werden – z. B. durch eine geeignet konfigurierte Firewall, geeignete Absiche- rung des LAN und durch die Verwendung geeigneter Anti-Viren-Programme;  Auflagen zur Sicherheit der IT-Plattform und Applikatio- nen: Es muss gewährleistet sein, dass von der Hard- ware, auf der der EVG betrieben wird, keine Angriffe ausgehen. Insbesondere muss sichergestellt sein dass die auf dem eingesetzten Computer installierte Software nicht böswillig manipuliert oder verändert werden kann, auf dem Computer keine Viren oder Trojanischen Pferde eingespielt werden können, die Hardware des Compu- ters nicht unzulässig verändert werden kann.  Auflagen zum Schutz vor manuellem Zugriff Unbefugter und Datenaustausch per Datenträger: Die folgenden baulichen, personellen und organisatorischen Anforde- rungen müssen umgesetzt sein: o Rechner, Monitor und Tastatur befinden sich in einem Betriebsraum. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 47/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) o Für die Administratoren müssen Vertreterrege- lungen für Krankheit und Urlaub bestehen. o Wartungs- bzw. Reinigungspersonal erhält den Zugang zum zugriffssicheren Betriebsraum nur durch einen Administrator, der den Aufenthalt überwacht. Erklärung 9Das Sicherheitsziel für die Umgebung OE.ServerBetrieb zielt auf die gleichnamige Annahme A.ServerBetrieb ab und ist zur Realisierung der organisatorischen Sicherheitspolitik P.ValidZert (für die Gewährleistung der Systemsicherheit aufgrund der Realisierung der Validierung innerhalb des verteilten Systems – d. h. dem Management des OSCI-Managers zum Sig- nieren des OSCI-Laufzettels durch das Kernsystem und des (System-) Zerti- fikats im OSCI-Backend-Enabler zur Verifikation des OSCI-Laufzettels) not- wendig. 99 OE.ClientBetrieb Für den Betrieb des OSCI-Client-Enablers muss der Signa- turschlüssel-Inhaber einen Beitrag zur Sicherheit leisten, sich beispielsweise vergewissern, dass er bei der Eingabe seines Identifikationsmerkmals nicht beobachtet wird, oder sein Identifikationsmerkmal ändert, wenn er den Ver- dacht oder die Gewissheit hat, sein Merkmal könnte nicht mehr geheim sein. Es muss gewährleistet sein, dass der OSCI-Client- Enabler korrekt aufgebaut ist, inkl. Einhaltung der Vorgaben hinsichtlich der räumlichen Gegebenheiten und für die Realisierung der Netzwerkarchitektur mit Firewall etc. Vgl. dazu die Vorgaben und Auflagen zum Betrieb der Virtuellen Poststelle, die im „Generi- schen Sicherheitskonzept für die Kern- und Web- komponenten der Virtuellen Poststelle“ beschrieben werden [VPS-SiKo]. Der OSCI-Client-Enabler als Funktionsbibliothek nutzt kryptographische Schlüssel und (System-)Zerti- fikate, die vom OSCI-Client zur Verfügung gestellt werden; eine geeignete Identifikation und Authenti- sierung zum Management dieser Sicherheitsattribute muss vom OSCI-Client sichergestellt werden. Der OSCI-Client muss auch die Integrität der kryptogra- phischen Schlüssel und (System-)Zertifikate sichern – denkbar ist, dass diese Sicherheitsattribute Be- standteil der integritätsgeschützten Software sind oder dass diese Konfigurationsdaten – ähnlich wie bei EVG3 – gesondert abgesichert werden. Die Anforderungen aus [BNetzA2005] an einen „ge- schützten Einsatzbereich (Regelfall/Standardlösung)“ müssen umgesetzt sein, um „potentielle Angriffen über das Internet, ein angeschlossenes Intranet, ei- nen manuellen Zugriff Unbefugter und einen Daten- bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 48/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) austausch per Datenträger [...] durch eine Kombinati- on von Sicherheitsvorkehrungen in der Signaturan- wendungskomponente selbst und der Einsatzumge- bung mit hoher Sicherheit“ hinsichtlich eines hohen Angriffspotentials abzuwehren:  Auflagen zur Anbindung an das Internet/Intranet: Netz- werkverbindungen müssen so abgesichert sein, dass Angriffe erkannt bzw. unterbunden werden – z. B. durch eine geeignet konfigurierte Firewall, und durch die Ver- wendung geeigneter Anti-Viren-Programme;  Auflagen zur Sicherheit der IT-Plattform und Applikatio- nen: Es muss gewährleistet sein, dass von der Hard- ware, auf der der EVG betrieben wird, keine Angriffe ausgehen. Insbesondere muss sichergestellt sein, dass die auf dem eingesetzten Computer installierte Software nicht böswillig manipuliert oder verändert werden kann, auf dem Computer keine Viren oder Trojanischen Pferde eingespielt werden können, die Hardware des Compu- ters nicht unzulässig verändert werden kann, der ver- wendete Chipkartenleser nicht böswillig manipuliert wur- de, um Daten (z. B. PIN, Hashwerte etc.) auszuforschen oder zu verändern.  Auflagen zum Schutz vor manuellem Zugriff Unbefugter und Datenaustausch per Datenträger: Die folgenden baulichen, personellen und organisatorischen Anforde- rungen müssen umgesetzt sein: o Aufbewahrung der PIN: Es wird angenommen, dass der Signaturschlüssel-Inhaber die PIN der Signaturkarte nicht weitergibt und die Regelun- gen zum Umgang mit der sicheren Signaturer- stellungseinheit, die der Hersteller dem Benutzer mitgeteilt hat, umsetzt. o Raum des Arbeitsplatzes: Es muss Sorge getra- gen werden, dass ein Zugriff Unbefugter ausge- schlossen ist oder zumindest mit hoher Sicher- heit erkennbar wird – beispielsweise durch ein Sperren des Bildschirmes oder Verschließen des Büros bei Abwesenheit. o Rechner und Chipkartenleser müssen durch ei- nen sicheren Kanal per Kabel verbunden sein. o Der Benutzer hat vor Gebrauch mit einem vom Hersteller zur Verfügung gestellten Prüftool die Integrität des OSCI-Client-Enablers zu prüfen – vgl. Abschnitt 2.7. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 49/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) o Bei der Installation hat der Benutzer die Integrität und Authentizität des OSCI-Client-Enablers mit dem vom Hersteller zur Verfügung gestellten Prüftool zu prüfen – vgl. Abschnitt 2.7. Erklärung 10Das Sicherheitsziel für die Umgebung OE.ClientBetrieb zielt auf die gleichnamige Annahme A.ClientBetrieb ab und ist zur Realisierung der organisatorischen Sicherheitspolitik P.ValidZert (für die Gewährleistung der Systemsicherheit aufgrund der Realisierung der Validierung innerhalb des verteilten Systems – d. h. dem Management des (System-) Zertifikats im OSCI-Client-Enabler zur Verifikation des OSCI-Laufzettels) notwendig. Zu- dem wehrt OE.ClientBetrieb die Bedrohung TE.SpähePIN durch geeignete Auflagen und Hinweise an den Signaturschlüssel-Inhaber zur Nutzung seiner Signaturkarte ab. 100 OE.ZufPIN Die IT-Umgebung muss gewährleisten, dass die Identifikati- onsdaten zwischen SigG-konformem Chipkartenleser (mit PIN-Pad) und si- cherer Signaturerstellungseinheit nicht preisgegeben und nur auf der jeweili- gen sicheren Signaturerstellungseinheit gespeichert werden. Erklärung 11Das Sicherheitsziel für die Umgebung OE.ZufPIN zielt auf die gleichnamige Annahme A.ZufPIN ab. 5 IT-Sicherheitsanforderungen 5.1 EVG-Sicherheitsanforderungen 5.1.1 Definition der funktionalen Sicherheitspolitik (SFP) 101 Bevor die funktionalen Sicherheitsanforderungen an den EVG aufgeführt wer- den, wird die funktionale Sicherheitspolitik (SFP) für die Zugriffskontrolle auf die Systemsicherheit (Systemsicherheit-Zugriffskontrollpolitik) definiert, wobei zu berücksichtigen ist, dass diese funktionale Sicherheitspolitik nicht für das Erzeugen oder die Prüfung einer qualifizierten elektronischen Signatur rele- vant ist:46 102 Der OSCI-Manager lässt den OSCI-Laufzettel vom Kernsystem der Basis- komponente mit einer elektronischen Signatur versehen16, welche OSCI-Cli- ent-Enabler und -Backend-Enabler verifizieren. 103 Dazu wird die Referenz auf den zu nutzenden privaten Schlüssel im OSCI- Manager verwaltet, während der private Schlüssel selber im Kernsystem der Basiskomponente16 und die (System-)Zertifikate in OSCI-Client resp. -Back- end außerhalb des EVG in der IT-Umgebung abgespeichert sind. 46 Der Zugriff auf einen privaten Schlüssel zur Erzeugung einer qualifizierten elektroni- schen Signatur bzw. ein qualifiziertes Zertifikat zur Prüfung einer qualifizierten elektroni- schen Signatur oder eines qualifizierten Zertifikats wird in der IT-Umgebung (in der siche- ren Signaturerstellungseinheit bzw. dem unterliegenden System) kontrolliert. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 50/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) 104 Für das Management der Referenz des privaten Schlüssels sind folgende Subjekte, Objekte und Operationen relevant:47  Subjekte: o Schlüssel-Administrator (für OSCI-Manager);  Objekte: o Referenz auf privaten Schlüssel;  Operationen: o Speichern der Referenz des privaten Schlüssels; o Löschen der Referenz des privaten Schlüssels. 105 Der Zugriff auf die Operationen Speichern und Löschen erfolgt nur nach er- folgreicher Authentisierung des Schlüssel-Administrators. 5.1.2 Funktionale EVG-Sicherheitsanforderungen 106 Die funktionalen Sicherheitsanforderungen sind zusammenfassend in Tabelle 3 aufgeführt und im Folgenden dargestellt. Die funktionalen EVG-Sicherheits- anforderungen entstammen überwiegend dem Teil 2 der CC [CC-Teil2]; eine EVG-Sicherheitsanforderung zur sicheren Anzeige ist explizit dargelegt (vgl. Abschnitt 9). 107 Die Notation der Sicherheitsanforderungen entspricht der in den Common Criteria vordefinierten semiformalen Sprache. In den Elementen ausgeführte Operationen Zuweisung und Auswahl sind fett dargestellt, während Verfeine- rungen unterstrichen gedruckt sind. Tabelle 3: Funktionale Sicherheitsanforderungen an den EVG Funktionale Sicherheits- anforderung an den EVG Beschreibung FCS_COP.1 (Hash) Kryptographischer Betrieb (für die kryptographische Operation „Hashen“ im Rahmen der Erzeugung einer qualifizierten elekt- ronischen Signatur durch die Signaturkarte) FCS_COP.1 (Valid) Kryptographischer Betrieb (für die kryptographische Operation „Verifizieren“ des OSCI-Laufzettels) FCS_COP.1 (OSCI) Kryptographischer Betrieb (für die kryptographische Operation „Hashen“ im Rahmen der Erzeugung einer elektronischen Sig- natur des OSCI-Laufzettels) FCS_COP.1 (Verify) Kryptographischer Betrieb (für die kryptographische Operation „Verifizieren“ einer qualifizierten elektronischen Signatur) FCS_COP.1 (VSign) Kryptographischer Betrieb (für die kryptographische Operation „Verifizieren“ einer zuvor von der Signaturkarte erzeugten quali- fizierten elektronischen Signatur) 47 Das Management der Sicherheitsattribute in OSCI-Client und -Backend obliegen der IT-Umgebung. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 51/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Funktionale Sicherheits- anforderung an den EVG Beschreibung FCS_COP.1 (Tool) Kryptographischer Betrieb (für die kryptographische Operation „Verifikation“ im Rahmen des Prüftools) FDP_SVR.148 Sichere Anzeige FDP_ACC.1 Teilweise Zugriffskontrolle FDP_ACF.1 Zugriffskontrolle basierend auf Sicherheitsattributen FDP_ITC.1 Import von Benutzerdaten ohne Sicherheitsattribute FIA_UID.2 Benutzeridentifikation vor jeglicher Aktion FIA_UAU.2 Benutzerauthentisierung vor jeglicher Aktion FMT_MSA.1 Management der Sicherheitsattribute FMT_MSA.3 Initialisierung statischer Attribute FMT_SMR.1 Sicherheitsrollen FTP_ITC.1 Inter-TSF Vertrauenswürdiger Kanal 108 Im Folgenden werden die funktionalen Sicherheitsanforderungen für den EVG beschrieben. 109 FCS_COP.1 (Hash) Kryptographischer Betrieb (für die kryptographi- sche Operation „Hashen“ im Rahmen der Erzeugung einer qualifizierten elektronischen Signatur durch die Signaturkarte) 110 FCS_COP.1.1/Hash Die TSF müssen im Zusammenhang mit der Erzeu- gung einer qualifizierten elektronischen Signatur durch die Signaturkar- te die kryptographische Operation „Hashen“ gemäß eines spezifizierten kryptographischen Algorithmus SHA-1 und kryptographischer Schlüssellän- gen, die bei einer Hashfunktion nicht relevant sind, die der folgenden Norm [SHA-1] entspricht, durchführen. Erklärung 12Die in FCS_COP.1.1/Hash spezifizierte Hashfunktion wird ge- mäß OSCI-Transport genutzt (vgl. Abschnitt 2.2). Erklärung 13Die funktionale Sicherheitsanforderung FCS_COP.1 (Hash) wird für die Umsetzung des Sicherheitsziels O.SignaturZuf benötigt. Erklärung 14Die Abhängigkeiten der funktionalen Sicherheitsanforderung FCS_COP.1 (Hash) sind nicht erfüllt, da keine Schlüssel involviert sind (we- der Schlüsselerzeugung gemäß FCS_CKM.1 oder Schlüsselimport gemäß FDP_ITC.1 noch Zerstörung eines Schlüssels gemäß FCS_CKM.4) und da- her kein Schlüsselmanagement gemäß FMT_MSA.2 notwendig ist. 48 Explizit dargelegte funktionale Anforderung (vgl. Abschnitt 9). bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 52/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) 111 FCS_COP.1 (Valid) Kryptographischer Betrieb (für die kryptographi- sche Operation „Verifizieren“ des OSCI-Laufzettels) 112 FCS_COP.1.1/Valid Die TSF müssen im Rahmen der Gewährleistung der Systemsicherheit die kryptographische Operation „Verifizieren“ gemäß eines spezifizierten kryptographischen Algorithmus RSA im Zusammenhang mit der Hashfunktion SHA-1 und kryptographischer Schlüssellängen, die entsprechend der X.509-Serverzertifikate derzeit 2048 Bit aufweisen, die den folgenden Normen [RSA] und [SHA-1] 49 entsprechen, durchführen. Erklärung 15Die funktionale Sicherheitsanforderung FCS_COP.1 (Valid) wird für die Umsetzung des Sicherheitsziels O.ValidZert in der Weise benö- tigt, dass OSCI-Client-Enabler und -Backend-Enabler die Signatur des OSCI- Laufzettels (vom OSCI-Manager mit Hilfe der Basiskomponente erzeugt) mit dem (System-)Zertifikat verifizieren müssen. Erklärung 16Die Abhängigkeiten der funktionalen Sicherheitsanforderung FCS_COP.1 (Valid) – Schlüsselerzeugung gemäß FCS_CKM.1 oder Schlüs- selimport gemäß FDP_ITC.1, Zerstörung eines Schlüssels gemäß FCS_CKM.4 und Schlüsselmanagement gemäß FMT_MSA.2) – sind in der IT-Umgebung im OSCI-Client bzw. -Backend, auf dem OSCI-Client-Enabler resp. -Backend-Enabler betrieben werden, zu realisieren. 113 FCS_COP.1 (OSCI) Kryptographischer Betrieb (für die kryptographi- sche Operation „Hashen“ im Rahmen der Erzeugung einer elektroni- schen Signatur des OSCI-Laufzettels) 114 FCS_COP.1.1/OSCI Die TSF müssen im Rahmen der Gewährleistung der Systemsicherheit die kryptographische Operation „Hashen“ gemäß ei- nes spezifizierten kryptographischen Algorithmus SHA-1 und kryptographi- scher Schlüssellängen, die bei einer Hashfunktion nicht relevant sind, die der folgenden Norm [SHA-1] entspricht, durchführen. Erklärung 17Die funktionale Sicherheitsanforderung FCS_COP.1 (OSCI) wird für die Umsetzung des Sicherheitsziels O.ValidZert in der Weise benö- tigt, dass der OSCI-Manager auf den OSCI-Laufzettel die Hashfunktion SHA-1 anwendet und durch das Kernsystem der Basiskomponente signieren lässt, so dass die elektronische Signatur des OSCI-Laufzettels dann von OSCI-Client-Enabler und -Backend-Enabler mit dem – dem OSCI-Manager zugeordneten – (System-) Zertifikat verifiziert werden kann. Erklärung 18Die Abhängigkeiten der funktionalen Sicherheitsanforderung FCS_COP.1 (OSCI) sind nicht erfüllt, da keine Schlüssel involviert sind (we- der Schlüsselerzeugung gemäß FCS_CKM.1 oder Schlüsselimport gemäß FDP_ITC.1 noch Zerstörung eines Schlüssels gemäß FCS_CKM.4) und da- her kein Schlüsselmanagement gemäß FMT_MSA.2 notwendig ist wird. 49 Hinsichtlich des Paddings wird PKCS#1 [PKCS#1] umgesetzt. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 53/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) 115 FCS_COP.1 (Verify) Kryptographischer Betrieb (für die kryptographi- sche Operation „Verifizieren“ einer qualifizierten elektronischen Signa- tur) 116 FCS_COP.1.1/Verify Die TSF müssen für die Verifikation einer qualifizier- ten elektronischen Signatur die kryptographische Operation „Verifizie- ren“ gemäß eines spezifizierten kryptographischen Algorithmus RSA im Zu- sammenhang mit der Hashfunktion SHA-1 und kryptographischer Schlüs- sellängen, die entsprechend der X.509-Zertifikate derzeit 1024 oder 2048 Bit aufweisen, die den folgenden Normen [RSA] und [SHA-1]49 entspre- chen, durchführen. Erklärung 19Die funktionale Sicherheitsanforderung FCS_COP.1 (Verify) wird für die Umsetzung des Sicherheitsziels O.VerifySign benötigt. Erklärung 20Die Abhängigkeiten der funktionalen Sicherheitsanforderung FCS_COP.1 (Verify) sind nicht erfüllt, da die für die Verifikation genutzten öf- fentlichen Schlüssel aus den Zertifikaten öffentliche Informationen sind und keine Sicherheitsattribute darstellen (keine Schlüsselerzeugung gemäß FCS_CKM.1, kein Schlüsselimport gemäß FDP_ITC.1 , keine Zerstörung ei- nes Schlüssels gemäß FCS_CKM.4, kein Schlüsselmanagement gemäß FMT_MSA.2). 117 FCS_COP.1 (VSign)Kryptographischer Betrieb (für die kryptographi- sche Operation „Verifizieren“ einer zuvor von der Signaturkarte erzeug- ten qualifizierten elektronischen Signatur) 118 FCS_COP.1.1/VSignDie TSF müssen für die Verifikation einer qualifizier- ten elektronischen Signatur die kryptographische Operation „Verifizie- ren“ gemäß eines spezifizierten kryptographischen Algorithmus RSA im Zu- sammenhang mit der Hashfunktion SHA-1 und kryptographischer Schlüs- sellängen, die entsprechend der X.509-Zertifikate derzeit 1024 oder 2048 Bit aufweisen, die den folgenden Normen [RSA] und [SHA-1]49 entspre- chen, durchführen. Erklärung 21Die funktionale Sicherheitsanforderung FCS_COP.1 (VSign) wird für die Umsetzung des Sicherheitsziels O.SignaturZuf in der Weise be- nötigt, dass eine zuvor erzeugte qualifizierte elektronische Signatur mit Hilfe des zum privaten Schlüssel korrespondierenden Zertifikats, das sich auf der Signaturkarte befindet, verifiziert wird. Erklärung 22Die Abhängigkeiten der funktionalen Sicherheitsanforderung FCS_COP.1 (VSign) – Schlüsselimport gemäß FDP_ITC.1, Zerstörung eines Schlüssels gemäß FCS_CKM.4 und Schlüsselmanagement gemäß FMT_MSA.2) – sind in der IT-Umgebung für die Signaturkarte zu realisieren; eine Schlüsselerzeugung gemäß FCS_CKM.1 ist nicht anwendbar, da Zertifi- kate auf der Signaturkarte abgespeichert, dort aber nicht erzeugt werden. 119 FCS_COP.1 (Tool) Kryptographischer Betrieb (für die kryptographi- sche Operation „Verifizieren“ im Rahmen des Prüftools) bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 54/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) 120 FCS_COP.1.1/Tool Die TSF müssen im Zusammenhang mit dem Prüftool die kryptographische Operation „Verifizieren“ gemäß eines spe- zifizierten kryptographischen Algorithmus RSA im Zusammenhang mit der Hashfunktion SHA-1 und kryptographischer Schlüssellängen, die 1024 bzw. 2048 Bit aufweisen, die den folgenden Normen [RSA] und [SHA-1]49 ent- sprechen, durchführen. Erklärung 23Die funktionale Sicherheitsanforderung FCS_COP.1 (Tool) wird für die Umsetzung des Sicherheitsziels O.Manipulation benötigt. Erklärung 24Die Abhängigkeiten der funktionalen Sicherheitsanforderung FCS_COP.1 (Tool) – Schlüsselimport gemäß FDP_ITC.1 (Schlüsselerzeu- gung gemäß FCS_CKM.1 ist bei Zertifikaten nicht anwendbar), Zerstörung eines Schlüssels gemäß FCS_CKM.4 und Schlüsselmanagement gemäß FMT_MSA.2) – sind in der IT-Umgebung für das Prüftool zu realisieren, da die für die Prüfung notwendigen Zertifikate vom Hersteller in das Tool einge- bracht und mit dem Tool ausgeliefert werden. 121 FDP_SVR.1 Sichere Anzeige 122 FDP_SVR.1.1 Die TSF müssen sicherstellen, dass der dem Benutzer angezeigte Inhalt eines Dokumentes (also die zu signierenden oder signier- ten Daten) entsprechend den folgenden Normen plain-text (UTF-8-codiert) und tiff sowie hinsichtlich dem Erzeugen einer Signatur durch prozedurale Anzeigetexte, dem Bezug zu den Daten, auf die sich die Signatur bezieht – beim Signieren und Verifizieren –, dem Ergebnis der Verifikation einer qualifi- zierten elektronischen Signatur, dem Ergebnis der Validierung eines qualifi- zierten Zertifikats, dem Signaturschlüssel-Inhaber der Signatur (optional) und dem Zertifikatsinhalt (optional) eindeutig ist. 123 FDP_SVR.1.2 Die TSF müssen sicherstellen, dass der dem Benutzer anzuzeigende Inhalt eines Dokumentes frei von aktiven oder verdeckten In- halten ist. Die TSF müssen sicherstellen, dass der Benutzer darüber infor- miert wird. 124 FDP_SVR.1.3 Die TSF müssen sicherstellen, dass der Benutzer über einen nicht darstellbaren Inhalt eines anzuzeigenden Dokumentes informiert wird. Erklärung 25Die funktionale Sicherheitsanforderung FDP_SVR.1 wird für die Umsetzung des Sicherheitsziels O.Anzeige benötigt. Erklärung 26FDP_SVR.1 hat keine Abhängigkeiten. 125 FDP_ACC.1 Teilweise Zugriffskontrolle 126 FDP_ACC.1.1 Die TSF müssen die SFP für die Zugriffskontrolle auf die Systemsicherheit (Systemsicherheit-Zugriffskontrollpolitik) für  die betrachteten Subjekte: o Schlüssel-Administrator; bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 55/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST)  die betrachteten Objekte: o Referenz auf privaten Schlüssel;  und die betrachteten Operationen: o Speichern der Referenz des privaten Schlüs- sels; o Löschen der Referenz des privaten Schlüs- sels; durchsetzen. Erklärung 27Die funktionale Sicherheitsanforderung FDP_ACC.1 ergibt sich aus der Abhängigkeit von FDP_ITC.1 und wird daher implizit für die Umset- zung des Sicherheitsziels O.ValidZert in der Weise benötigt, dass der OSCI- Manager den OSCI-Laufzettel durch das Kernsystem der Basiskomponente signieren lässt und dazu den zu nutzenden Schlüssel referenziert. In dieser Sicherheitsanforderung werden Subjekt, Objekt sowie zulässige Operationen zwischen Subjekten und Objekten hinsichtlich der Systemsicherheit-Zugriffs- kontrollpolitik definiert. Erklärung 28Die Abhängigkeit von FDP_ACC.1 – FDP_ACF.1 – ist aufge- nommen. 127 FDP_ACF.1 Zugriffskontrolle basierend auf Sicherheitsattribu- ten 128 FDP_ACF.1.1 Die TSF müssen die SFP für die Zugriffskontrolle auf die Systemsicherheit (Systemsicherheit-Zugriffskontrollpolitik) für Ob- jekte, die auf den Sicherheitsattributen Rolle, Benutzerkennzeichen und Rechte basieren, durchsetzen. 129 FDP_ACF.1.2 Die TSF müssen die folgenden Regeln durchsetzen, um festzustellen, ob eine Operation zwischen kontrollierten Subjekten und kont- rollierten Objekten zulässig ist: Speichern und Löschen der Referenz des pri- vaten Schlüssels erfolgt nur nach erfolgrei- cher Authentisierung des Schlüssel-Admini- strators. 130 FDP_ACF.1.3 Die TSF müssen den Zugriff von Subjekten auf Objekte basierend auf den folgenden zusätzlichen Regeln explizit autorisieren: Die TSF müssen hierbei keine zusätzlichen Regeln berücksichtigen. 131 FDP_ACF.1.4 Die TSF müssen den Zugriff von Subjekten auf Objekte, basierend auf keinen zusätzlichen Regeln explizit verweigern. Erklärung 29Die funktionale Sicherheitsanforderung FDP_ACF.1 ergibt sich aus der Abhängigkeit von FDP_ACC.1 und wird daher implizit für die Umset- zung des Sicherheitsziels O.ValidZert in der Weise benötigt, dass der OSCI- Manager den OSCI-Laufzettel durch das Kernsystem der Basiskomponente signieren lässt und dazu den zu nutzenden Schlüssel referenziert. In dieser bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 56/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Sicherheitsanforderung wird thematisiert, dass eine zulässige Operation (vgl. FDP_ACC.1) erst nach erfolgreicher Authentisierung des Schlüssel-Administ- rators erfolgen kann. Erklärung 30Die Abhängigkeiten von FDP_ACF.1 – FDP_ACC.1 und FMT_MSA.3 sind aufgenommen. 132 FDP_ITC.1 Import von Benutzerdaten ohne Sicherheitsattribute 133 FDP_ITC.1.1 Die TSF müssen die SFP für die Zugriffskontrolle auf die Systemsicherheit (Systemsicherheit-Zugriffskontrollpolitik beim Im- port von unter Kontrolle der SFP stehenden Benutzerdaten von außerhalb des TSC durchsetzen. 134 FDP_ITC.1.2 Die TSF müssen die mit den Benutzerdaten (hier: Refe- renz auf privaten Schlüssel) verknüpften Sicherheitsattribute ignorieren, wenn diese von außerhalb des TSC importiert werden. 135 FDP_ITC.1.3 Die TSF müssen die folgenden Regeln beim Import un- ter Kontrolle der SFP stehender Benutzerdaten von außerhalb des TSC durchsetzen: Keine zusätzlichen Importkontrollregeln. Erklärung 31Die funktionale Sicherheitsanforderung FDP_ITC.1 wird für die Umsetzung des Sicherheitsziels O.ValidZert in der Weise benötigt, dass der OSCI-Manager den OSCI-Laufzettel durch das Kernsystem der Basiskompo- nente signieren lässt – und dazu den zu nutzenden Schlüssel referenziert –, so dass die Signatur dann von OSCI-Client-Enabler und -Backend-Enabler mit dem (System-)Zertifikat verifizieren werden kann. Erklärung 32Die Abhängigkeiten von FDP_ITC.1 – FDP_ACC.1 für die Zu- griffskontrolle und FMT_MSA.3 zum Management des privaten Schlüssels sind aufgenommen. 136 FIA_UID.2 Benutzeridentifikation vor jeglicher Aktion 137 Ist hierarchisch zu: FIA_UID.1 138 FIA_UID.2.1 Die TSF müssen erfordern, daß sich jeder Benutzer (hier: Schlüssel- und Security-Administrator) identifiziert, bevor für diesen jeg- liche andere TSF-vermittelte Aktionen erlaubt werden. Erklärung 33Die funktionale Sicherheitsanforderung FIA_UID.2 ergibt sich aus der Abhängigkeit von FMT_SMR.1, wobei statt FIA_UID.1 die hierarchi- sche Anforderung FIA_UID.2 genutzt wird. FIA_UID.2 wird damit implizit für die Umsetzung des Sicherheitsziels O.ValidZert benötigt. Erklärung 34FIA_UID.2 hat keine Abhängigkeiten. 139 FIA_UAU.2 Benutzerauthentisierung vor jeglicher Aktion 140 Ist hierarchisch zu: FIA_UAU.1 bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 57/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) 141 FIA_UAU.2.1 Die TSF müssen erfordern, daß jeder Benutzer (hier: Schlüssel- und Security-Administrator) erfolgreich authentisiert wurde, bevor diesem jegliche andere TSF-vermittelte Aktionen erlaubt werden. Erklärung 35Die funktionale Sicherheitsanforderung FIA_UAU.2 wird – wie FIA_UID.2 auch – für die Umsetzung des Sicherheitsziels O.ValidZert benö- tigt. Erklärung 36FIA_UAU.2 hat die Abhängigkeit FIA_UID.1, die durch die hier- archische Anforderung FIA_UID.2 realisiert wird. 142 FMT_MSA.1 Management der Sicherheitsattribute 143 FMT_MSA.1.1 Die TSF müssen die SFP für die Zugriffskontrolle auf die Systemsicherheit (Systemsicherheit-Zugriffskontrollpolitik) zur Be- schränkung der Fähigkeit zum Modifizieren und Löschen der Sicherheits- attribute Rolle, Benutzerkennung und Rechte auf den Security-Administ- rator durchsetzen. Erklärung 37Die funktionale Sicherheitsanforderung FMT_MSA.1 ergibt sich aus der Abhängigkeit von FMT_MSA.3 und wird implizit für die Umsetzung des Sicherheitsziels O.ValidZert benötigt. Im Fokus der Betrachtung steht hierbei das Management der Rolle des Schlüssel-Administrators durch den Security-Administrator; die zulässigen Operationen mit den privaten Schlüs- seln werden in FDP_ACC.1 und FDP_ACF.1 thematisiert. Erklärung 38Die Abhängigkeiten von FMT_MSA.1 – FDP_ACC.1 und FMT_SMR.1 – sind aufgenommen. 144 FMT_MSA.3 Initialisierung statischer Attribute 145 FMT_MSA.3.1 Die TSF müssen die SFP für die Zugriffskontrolle auf die Systemsicherheit (Systemsicherheit-Zugriffskontrollpolitik) zur Be- reitstellung von vorgegebenen Standardwerten mit einschränkenden Eigen- schaften für Sicherheitsattribute, die zur Durchsetzung der SFP benutzt wer- den, durchsetzen. 146 FMT_MSA.3.2 Die TSF müssen dem Security-Administrator gestat- ten, bei der Erzeugung eines Objekts oder von Informationen alternative An- fangswerte zu spezifizieren, die die vorgegebenen Standardwerte ersetzen. Erklärung 39Die funktionale Sicherheitsanforderung FMT_MSA.3 ergibt sich aus den Abhängigkeiten von FDP_ITC.1 und FDP_ACF.1 und wird daher im- plizit für die Umsetzung des Sicherheitsziels O.ValidZert benötigt. Im Fokus der Betrachtung steht hierbei das Management der Rolle des Schlüssel-Ad- ministrators durch den Security-Administrator; die zulässigen Operationen werden in FDP_ACC.1 und FDP_ACF.1 thematisiert. Erklärung 40Die Abhängigkeiten von FMT_MSA.3 – FMT_MSA.1 und FMT_SMR.1 – sind aufgenommen. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 58/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) 147 FMT_SMR.1 Sicherheitsrollen 148 FMT_SMR.1.1 Die TSF müssen die Rollen Schlüssel-Administrator und Security-Administrator erhalten. 149 FMT_SMR.1.2 Die TSF müssen Benutzer mit Rollen verknüpfen kön- nen. Erklärung 41Die funktionale Sicherheitsanforderung FMT_SMR.1 ergibt sich aus den Abhängigkeiten von FMT_MSA.1 (für die Rolle des Security-Admi- nistrators für die Konfiguration der Rechte, Rollen und Berechtigungen) und FMT_MSA.3 (für die Rolle des Schlüssel-Administrators zum Management der Referenz der privaten Schlüssel) und wird implizit für die Umsetzung des Sicherheitsziels O.ValidZert benötigt. Erklärung 42Die Abhängigkeit von FMT_SMR.1 – FIA_UID.1 – ist aufge- nommen. 150 FTP_ITC.1 Inter-TSF Vertrauenswürdiger Kanal 151 FTP_ITC.1.1 Die TSF müssen einen Kommunikationskanal zwischen sich und einem entfernten vertrauenswürdigen IT-Produkt bereitstellen, der logisch von den anderen Kommunikationskanälen getrennt ist und eine gesi- cherte Identifikation seiner Endpunkte sowie den Schutz der Daten des Ka- nals vor Modifizierung oder Preisgabe bereitstellt. 152 FTP_ITC.1.2 Die TSF müssen den TSF erlauben, eine Kommunikati- on über den vertrauenswürdigen Kanal einzuleiten. 153 FTP_ITC.1.3 Die TSF müssen für die Erzeugung einer qualifizier- ten elektronischen Signatur eine Kommunikation über den vertrauenswür- digen Kanal einleiten. Erklärung 43Die funktionale Sicherheitsanforderung FTP_ITC.1 wird implizit für die Umsetzung des Sicherheitsziels O.SignaturZuf benötigt, wobei ein vertrauenswürdiger Kanal zwischen EVG und Signaturkarte aufgebaut wird. Erklärung 44FTP_ITC.1 hat keine Abhängigkeiten. 5.1.3 Anforderungen an die Vertrauenswürdigkeit des EVG 154 Die Anforderungen an die Vertrauenswürdigkeit des EVG sind in Tabelle 4 aufgeführt und genügen den in Abschnitt 1.3 beschriebenen Anforderungen. 155 Als Mindest-Stärke der Sicherheitsmechanismen des EVG wird SOF-hoch postuliert. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 59/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Tabelle 4: Vertrauenswürdigkeitskomponenten Vertrauenswür- digkeitsklasse Vertrauenswürdigkeitskomponente Konfigurations- management ACM_CAP.3 Autorisierungskontrolle ACM_SCP.1 EVG-CM-Umfang Auslieferung und Betrieb ADO_DEL.2 Erkennung von Modifizierungen ADO_IGS.1 Installations-, Generierungs- und Anlaufprozeduren Entwicklung ADV_FSP.1 Informelle funktionale Spezifikation ADV_HLD.2 Sicherheitsspezifischer Entwurf auf hoher Ebene ADV_IMP.1 Teilmenge der Implementierung der TSF ADV_LLD.1 Beschreibender Entwurf auf niedriger Ebene ADV_RCR.1 Informeller Nachweis der Übereinstimmung Handbücher AGD_ADM.1 Systemverwalterhandbuch AGD_USR.1 Benutzerhandbuch Lebenszyklus- Unterstützung ALC_DVS.1 Identifikation der Sicherheitsmaßnahmen ALC_TAT.1 Klar festgelegte Entwicklungswerkzeuge Testen ATE_COV.2 Analyse der Testabdeckung ATE_DPT.1 Testen – Entwurf auf hoher Ebene ATE_FUN.1 Funktionales Testen ATE_IND.2 Unabhängiges Testen – Stichprobenartig Schwach- stellen- bewertung AVA_MSU.3 Analysieren und Testen auf unsichere Zustände AVA_SOF.1 Stärke der EVG-Sicherheitsfunktionen AVA_VLA.4 Hohe Widerstandsfähigkeit 5.2 Sicherheitsanforderungen an die IT-Umgebung 156 Die funktionalen Sicherheitsanforderungen an die IT-Umgebung sind zusam- menfassend in Tabelle 5 aufgeführt und im Folgenden aufgeführt bzw. refe- renziert. Die funktionalen EVG-Sicherheitsanforderungen entstammen dem Teil 2 der CC [CC-Teil2]. Tabelle 5: Funktionale Sicherheitsanforderungen an die IT-Umgebung Funktionale Sicherheits- anforderung an die IT- Umgebung Beschreibung FCS_CKM.150 Kryptographische Schlüsselgenerierung bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 60/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Funktionale Sicherheits- anforderung an die IT- Umgebung Beschreibung FDP_ITC.150 Import von Benutzerdaten ohne Sicherheitsattribute FCS_CKM.4 Zerstörung des kryptographischen Schlüssels FMT_MSA.2 Sichere Sicherheitsattribute FCO_NRO.1 Selektiver Urheberschaftsbeweis (vgl. [bos_Basis_ST]) FCS_CKM.4 Zerstörung des kryptographischen Schlüssels (vgl. [bos_Basis_ST]) FCS_COP.1 (Verify) Kyptographischer Betrieb (für die kryptographische Operation „Verifizieren“ einer qualifizierten elektronischen Signatur) (vgl. [bos_Basis_ST]) FCS_COP.1 (SVVE51 ) Kyptographischer Betrieb (für die Erzeugung einer elektroni- schen Signatur für Verifikations- und Validierungsergebnisse) (vgl. [bos_Basis_ST]) FCS_COP.1 (VVE52 ) Kyptographischer Betrieb (für die Verifikation eines Validie- rungsergebnisses) (vgl. [bos_Basis_ST]) FDP_ACC.1 (Sys) Teilweise Zugriffskontrolle (Systemsicherheit-Zugriffskontroll- politik) (vgl. [bos_Basis_ST]) FDP_ACF.1 (Sys) Zugriffskontrolle basierend auf Sicherheitsattributen (Systemsi- cherheit-Zugriffskontrollpolitik) (vgl. [bos_Basis_ST]) FDP_ITC.1 Import von Benutzerdaten ohne Sicherheitsattribute (vgl. [bos_Basis_ST]) FIA_UID.2 Benutzeridentifikation vor jeglicher Aktion (vgl. [bos_Ba- sis_ST]) FMT_MSA.1 (Sys) Management der Sicherheitsattribute (Systemsicher- heit-Zugriffskontrollpolitik) (vgl. [bos_Basis_ST]) FMT_MSA.2 Sichere Sicherheitsattribute (vgl. [bos_Basis_ST]) FMT_MSA.3 (Sys) Initialisierung statischer Attribute (Systemsicherheit -Zugriffs- kontrollpolitik) (vgl. [bos_Basis_ST]) FMT_SMR.1 (Sys) Sicherheitsrollen (Systemsicherheit -Zugriffskontrollpolitik) (vgl. [bos_Basis_ST]) funktionale Sicherheitsanforderungen, die an SigG-konforme sichere Signaturerstellungsein- heiten und Chipkartenleser gestellt werden, sind den Sicherheitsvorgaben bestätigter Pro- dukte zu entnehmen (vgl. beispielsweise www.bundesnetzagentur.de); weitere Anforderun- 50 In der IT-Umgebung ist zu realisieren, ob Schlüssel generiert (FCS_CKM.1) oder Schlüssel importiert (FDP_ITC.1) werden. 51 Signieren von Verifikations- und Validierungs-Ergebnissen 52 Verifizieren eines Validierungs-Ergebnisses bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 61/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Funktionale Sicherheits- anforderung an die IT- Umgebung Beschreibung gen werden nicht benötigt 157 FCS_CKM.150 Kryptographische Schlüsselgenerierung 158 FCS_CKM.1.1 Die Sicherheitsfunktionen in der IT-Umgebung müssen die kryptographischen Schlüssel gemäß eines spezifizierten Algorithmus zur kryptographischen Schlüsselgenerierung mit einem geeigneten Algorith- mus zur kryptographischen Schlüsselgenerierung und spezifizierte kryp- tographische Schlüssellängen, die 2048 Bit aufweisen, die den folgenden Normen [RSA] und [SHA-1]49 entsprechen, generieren. 159 FDP_ITC.150 Import von Benutzerdaten ohne Sicherheitsattribute 160 FDP_ITC.1.1 Die Sicherheitsfunktionen in der IT-Umgebung müssen eine SFP für Zugriffskontrolle und/oder Informationsflußkontrolle in der IT-Umgebung beim Import von unter Kontrolle der SFP stehenden Benutzer- daten von außerhalb des TSC durchsetzen. 161 FDP_ITC.1.2 Die Sicherheitsfunktionen in der IT-Umgebung müssen die mit den Benutzerdaten verknüpften Sicherheitsattribute ignorieren, wenn diese von außerhalb des TSC importiert werden. 162 FDP_ITC.1.3 Die Sicherheitsfunktionen in der IT-Umgebung müssen die folgenden Regeln beim Import unter Kontrolle der SFP stehender Benut- zerdaten von außerhalb des TSC durchsetzen: zusätzliche Importkontroll- regeln, sofern in der IT-Umgebung notwendig. 163 FCS_CKM.4 Zerstörung des kryptographischen Schlüssels 164 FCS_CKM.4.1 Die Sicherheitsfunktionen in der IT-Umgebung müssen die kryptographischen Schlüssel nach einer spezifizierten Methode zur Zer- störung des kryptographischen Schlüssels durch Löschen bzw. Entfernen aus entsprechendem Verzeichnis oder einen anderen geeigneten Me- chanismus, die […] keiner speziellen Norm entspricht, zerstören. 165 FMT_MSA.2 Sichere Sicherheitsattribute 166 FMT_MSA.2.1 Die Sicherheitsfunktionen in der IT-Umgebung müssen sicherstellen, daß nur sichere Werte für Sicherheitsattribute akzeptiert wer- den. Erklärung 45Die drei funktionalen Sicherheitsanforderungen an die IT-Um- gebung – FCS_CKM.1 oder FDP_ITC.1 sowie FCS_CKM.4 und FMT_MSA.2 – ergeben sich aus den Sicherheitszielen O.ValidZert (bzgl. Schlüsselerzeu- gung oder -import, Zerstörung und Schlüsselmanagement des (System-) Zer- tifikats in OSCI-Client bzw. -Backend, auf dem OSCI-Client-Enabler resp. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 62/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) -Backend-Enabler betrieben werden), O.SignaturZuf (bzgl. Schlüsselimport, - zerstörung und -management des zum privaten Schlüssel korrespondieren- den Zertifikats, das sich auf der Signaturkarte befindet,) O.Manipulation (bzgl. Schlüsselimport, -zerstörung und -management in Prüftool), OE.PKI (bzgl. Schlüsselerzeugung oder -import, Schlüsselzerstörung und -management für Schlüssel und korrespondierende (System-) Zertifikate in IT-Umgebung) und OE.SAK (bzgl. der Sicherstellung, dass nur sichere Sicherheitsattribute – ins- besondere für die (System-) Zertifikate – akzeptiert werden). Die Ausgestal- tung der Operationen der funktionalen Sicherheitsanforderungen sowie die Abhängigkeiten dieser Anforderungen sind in der IT-Umgebung zu realisie- ren, da Schlüsselerzeugung, -import und -löschung sowie Management der Sicherheitsattribute in der IT-Umgebung außerhalb des EVG liegt. Erklärung 46Die in Tabelle 5 referenzierten funktionalen Sicherheitsanforde- rungen an die IT-Umgebung FCO_NRO.1, FCS_CKM.4, FCS_COP.1 (Verify), FCS_COP.1 (SVVE), FCS_COP.1 (VVE), FDP_ACC.1 (Sys), FDP_ACF.1 (Sys), FDP_ITC.1, FIA_UID.2, FMT_MSA.1 (Sys), FMT_MSA.2, FMT_MSA.3 (Sys) und FMT_SMR.1 (Sys) lassen sich auf das Sicherheitsziel der IT-Umgebung OE.PKI hinsichtlich der Validierung qualifizierter Zertifikate und des unterstützenden Sicherheitsmechanismus’ zur Erzeugung einer elektronischen Signatur für einen vom OSCI-Manager erzeugten und über- mittelten Hashwert, für die die Basiskomponente der Virtuellen Poststelle des Bundes (vgl. [bos_Basis_ST]) benötigt wird, zurückführen. Erklärung 47Die funktionalen Sicherheitsanforderungen an die IT-Umge- bung zu den SigG-konformen sicheren Signaturerstellungseinheiten und Chipkartenlesern, die den Sicherheitsvorgaben bestätigter Produkte zu ent- nehmen sind (vgl. beispielsweise www.bundesnetzagentur.de), lassen sich auf die Sicherheitsziele der IT-Umgebung OE.PKI und OE.ZufPIN hinsichtlich der SigG-konformen sicheren Signaturerstellungseinheiten und Chipkartenle- ser sowie der qualifizierten Zertifikate zurückführen; weitere Anforderungen werden nicht benötigt. 5.3 Sicherheitsanforderungen an die Nicht-IT-Umgebung 167 Sicherheitsanforderungen an die Nicht-IT-Umgebung werden nicht formuliert. 6 EVG-Übersichtsspezifikation 168 In diesem Abschnitt werden die EVG-Sicherheitsfunktionen (TSF – TOE Se- curity Functions) dargestellt, die vom EVG zur Verfügung gestellt werden: SF1 Unterstützung bei der Erzeugung qualifizierter elektronischer Signatu- ren (Hashen und Zuführen zu signierender Dokumente zu einer siche- ren Signaturerstellungseinheit); SF2 Schutz gegen Hashwertmanipulation; SF3 Verifikation einer qualifizierten elektronischen Signatur; bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 63/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) SF4 Verifikation eines OSCI-Laufzettels bei der Validierung eines qualifi- zierten Zertifikats; SF5 Sichere und zuverlässige Anzeige; SF6 Unterstützung bei der Validierung qualifizierter Zertifikate; SF7 Identifikation und Authentisierung; SF8 Prüftool. 6.1 SF1 – Unterstützung bei der Erzeugung qualifizierter elektroni- scher Signaturen 169 Die Sicherheitsfunktion SF1 „Unterstützung bei der Erzeugung qualifizierter elektronischer Signaturen (Hashen und Zuführen zu signierender Dokumente zu einer sicheren Signaturerstellungseinheit)“ ist wie folgt definiert:  Der OSCI-Client-Enabler wendet auf Initiative des Benutzers des OSCI- Client-Enablers auf die zu signierende Daten gemäß OSCI-Transport (vgl. Abschnitt 2.2) die Hashfunktion SHA-1 an und führt den erzeugten Hashwert einer angeschlossenen sicheren Signaturerstellungseinheit zu, die eine qualifizierte elektronische Signatur erzeugt und an den OSCI-Cli- ent-Enabler zurückliefert.53  Vor jeder Signaturerzeugung erfolgt der EVG die Eingabe einer PIN.  Signierte Daten werden im inneren Umschlag des OSCI-Protokolls trans- portiert. Daten, die dem OSCI-Client-Enabler vom OSCI-Client zum Sig- nieren übergeben werden, sind in einer XML-Struktur codiert. 6.2 SF2 – Schutz gegen Hashwertmanipulation 170 Die Sicherheitsfunktion SF2 „Schutz gegen Hashwertmanipulation“ ist wie folgt definiert:  Der OSCI-Client-Enabler vergleicht den von der sicheren Signaturerstel- lungseinheit signierten Hashwert (vgl. SF1), den er von der Signaturkarte erhält, mit dem Hashwert, den er an die Signaturkarte gesendet hatte.  Dazu werden folgende Schritte ausgeführt: o Zuerst wird die Signatur mit dem zum privaten Signaturschlüssel korrespondierenden öffentlichen Schlüssel verifiziert. Kann die Si- gnatur nicht verifiziert werden, erfolgt eine Fehlermeldung und der Signaturvorgang wird abgebrochen. o Kann die Signatur verifiziert werden, erfolgt ein Vergleich der bei- den Hashwerte. Sind die beiden Hashwerte nicht identisch, erfolgt eine Fehlermeldung und der Signaturvorgang wird abgebrochen, da der Hashwert zwischen EVG und Signaturkarte manipuliert wurde. 53 Dazu ist am Arbeitsplatz-PC in der IT-Umgebung ein Kartenleser installiert. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 64/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST)  Das für die Verifikation benötigte Zertifikat lädt der OSCI-Client-Enabler von der Signaturkarte. 6.3 SF3 – Verifikation einer qualifizierten elektronischen Signatur 171 Die Sicherheitsfunktion SF3 „Verifikation einer qualifizierten elektronischen Signatur“ ist wie folgt definiert:  OSCI-Client-Enabler und -Backend-Enabler verifizieren eine qualifizierte elektronische Signaturen aus dem inneren Umschlag des OSCI-Proto- kolls. Initiator ist beim OSCI-Client-Enabler der Benutzer und beim OSCI- Backend-Enabler das OSCI-Backend in der IT-Umgebung.  Die Verifikation nutzt neben der qualifizierten elektronischen Signatur das mitgelieferte zugehörige Zertifikat mit dem Prüfschlüssel sowie den Verifi- kationsalgorithmus RSA und die Hashfunktion SHA-1. Benutzte Schlüs- sellängen sind entsprechend der X.509-Zertifikate derzeit 1024 oder 2048 Bit.  Während beim OSCI-Client-Enabler das Verifikationsergebnis via SF5 angezeigt wird, übergibt der OSCI-Backend-Enabler das Verifikationser- gebnis an das angeschlossene OSCI-Backend in der IT-Umgebung. 6.4 SF4 – Verifikation eines OSCI-Laufzettels bei der Validierung eines qualifizierten Zertifikats 172 Die Sicherheitsfunktion SF4 „Verifikation eines OSCI-Laufzettels bei der Vali- dierung eines qualifizierten Zertifikats“ ist wie folgt definiert:54  OSCI-Client-Enabler und -Backend-Enabler verifizieren die elektronische Signatur des OSCI-Laufzettels mit dem (System-)Zertifikat des OSCI-Ma- nagers. Initiator ist beim OSCI-Client-Enabler der Benutzer und beim OSCI-Backend-Enabler das OSCI-Backend in der IT-Umgebung.  OSCI-Client-Enabler und -Backend-Enabler führen einen Plausibili- tätscheck durch, in der OSCI-Client-Enabler bzw. -Backend-Enabler prü- fen, ob das im OSCI-Laufzettel enthaltene Ergebnis der Zertifikats-Status- prüfung zum Zertifikat der OSCI-Nachricht passt.  Während beim OSCI-Client-Enabler das Verifikationsergebnis via SF5 angezeigt wird, übergibt der OSCI-Backend-Enabler das Verifikationser- gebnis an das angeschlossene OSCI-Backend in der IT-Umgebung. 6.5 SF5 – Sichere und zuverlässige Anzeige 173 Die Sicherheitsfunktion SF5 „Sichere und zuverlässige Anzeige“ ist wie folgt definiert: 54 OSCI-Client-Enabler und -Backend-Enabler validieren nicht selber, sondern nutzen das Ergebnis der Validierung vom OSCI-Manager, welches im OSCI-Laufzettel – mit einer elektronischen Signatur versehen – enthalten ist. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 65/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST)  Der OSCI-Client-Enabler bietet eine sichere Anzeige von folgenden zu si- gnierenden und signierten Daten: o plain-text (UTF-8-codiert); o tiff-Daten.  Darüber hinaus bietet der OSCI-Client-Enabler eine sichere Anzeige wei- terer signatur-relevanten Informationen; o Verweis, auf welche Daten sich eine Signatur bezieht; o der Signatur zugeordnete Signaturschlüssel-Inhaber; o Inhalte des zugehörigen qualifizierten Zertifikats.  Der OSCI-Client-Enabler bietet des Weiteren hinreichende Anzeigen für folgende Prozesse: o Signierprozess:  Das Erzeugen einer Signatur wird vorher eindeutig ange- zeigt.  Das zur Signatur korrespondierende Zertifikat wird ange- zeigt.  Das Verifikationsergebnis zum Schutz vor Hashwertmani- pulation (vgl. SF2) wird angezeigt. o Verifikationsprozess: Das Ergebnis der Verifikation wird ange- zeigt, d. h. es wird angezeigt, ob Daten unverändert sind. o Validierungsprozess: Das Ergebnis der Validierung wird ange- zeigt, d. h. es wird angezeigt, ob die nachgeprüften qualifizierten Zertifikate im jeweiligen Zertifikatverzeichnis zum angegebenen Zeitpunkt vorhanden und nicht gesperrt waren. 6.6 SF6 – Unterstützung bei der Validierung qualifizierter Zertifika- te 174 Die Sicherheitsfunktion SF6 „Unterstützung bei der Validierung qualifizierter Zertifikate“ ist wie folgt definiert:  Der OSCI-Manager führt in der OSCI-Rolle des OSCI-Intermediärs die Statusprüfung eines qualifizierten Zertifikats durch. Dazu greift der OSCI- Manager auf eine Basiskomponente in der IT-Umgebung zu, wobei der OSCI-Manager zusammen mit dem Kernsystem der Basiskomponente in- nerhalb eines vertrauenswürdigen Netzes betrieben wird: Der OSCI-Ma- nager sendet einen Request an das Kernsystem – das Request umfasst neben dem nachzuprüfenden Zertifikat die SystemID (Identifier des anfra- genden Systems) des OSCI-Managers sowie die OperationID (Identifier der auszuführenden Operation) für das Validieren – und empfängt das Response mit dem Validierungsergebnis. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 66/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST)  Der OSCI-Manager interpretiert die Antwort der Basiskomponente und generiert ein eigenes Ergebnis, das der OSCI-Manager im OSCI-Laufzet- tel ablegt.  Den OSCI-Laufzettel versieht der OSCI-Manager mit einer elektronischen Signatur: Dazu o führt der OSCI-Manager die zu signierenden Daten der Hashfunk- tion SHA-1 zu, o übergibt den erzeugten Hashwert dem Kernsystem der Basiskom- ponente, welches die elektronische Signatur für den OSCI-Mana- ger erzeugt und an den OSCI-Manager zurückliefert.16  Daraufhin übergibt der OSCI-Manager im Rahmen des OSCI-Protokolls diesen OSCI-Laufzettel an den OSCI-Client-Enabler bzw. an den OSCI- Backend-Enabler. 6.7 SF7 – Identifikation und Authentisierung 175 Die Sicherheitsfunktion SF7 „Identifikation und Authentisierung“ zur Realisie- rung der Zugriffskontrollpolitik (vgl. Abschnitt 5.1.1) sowie zur Administration des OSCI-Managers (vgl. Abschnitt 3.1) ist wie folgt definiert:55  Bevor ein Schlüssel-Administrator im OSCI-Manager die Referenz des privaten Schlüssel zur Absicherung der Systemsicherheit, mit dem der OSCI-Laufzettel signiert wird, speichern oder löschen kann, muss er sich gegenüber dem OSCI-Manager identifizieren und authentisieren.  Bevor ein Security-Administrator den OSCI-Manager – in Zusammenar- beit mit dem Revisor – konfiguriert (Rechte der Rollen setzen, ändern und löschen, Administratoren-Rollen konfigurieren), muss er sich gegenüber OSCI-Manager identifizieren und authentisieren.  Zur Güte des Passwortes realisiert der EVG: o keine Trivialpasswörter (z. B. „BBBBBBBB“ oder „12345678“); o mindestens ein Zeichen pro Passwort, das kein Buchstabe ist (Sonderzeichen oder Zahl); o mindestens 8 Zeichen lang. 6.8 SF8 – Prüftool 176 Die Sicherheitsfunktion SF8 „Prüftool“ zur Gewährleistung der Integrität des OSCI-Client-Enablers ist wie folgt definiert:  Das Prüftool überprüft die elektronische Signatur der JAR-Files des OSCI-Client-Enablers.56 55 Der OSCI-Manager versieht den OSCI-Laufzettel mit einer elektronischen Signatur, dessen privater Schlüssel durch die in Abschnitt 5.1.1 definierte Zugriffskontrollpolitik ab- gesichert wird. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 67/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST)  Die zugehörigen Zertifikate des Herstellers, die die öffentlichen Schlüssel zwecks Verifikation enthalten, sind im Prüftool enthalten.  Das Prüftool kennt die Dateinamen aller JAR-Files, die überprüft werden müssen.  Dem Anwender wird zu jedem überprüften JAR-File der Dateiname, der Dateipfad, die Version, das jeweilige Prüfergebnis (Signatur korrekt, Sig- natur nicht korrekt) sowie das Gesamtergebnis (Produktintegrität bestä- tigt, Produktintegrität nicht bestätigt) angezeigt.  Den Dateipfad der JAR-Files ermittelt das Prüftool aus einem Übergabe- parameter und dem in Java Web Start eingetragenen Pfad des Caches.  Werden die JAR-Archive vom Prüftool nicht gefunden, kann der Anwen- der den/die Speicherort/e über den Java-File-Explorer auswählen. 177 Das Prüftool ist ein Java-Applet, das vom Hersteller signiert ist. Genutzte Hashfunktion ist SHA-1 (Mechanismenstärke „hoch“), genutzter Verifikations- algorithmus ist RSA mit 1024 bzw. 2048 Bit41 Schlüssellänge. 6.9 Maßnahmen zur Vertrauenswürdigkeit 178 Um die Vertrauenswürdigkeitsstufe EAL3+ zu erhalten, werden folgende Maßnahmen durchgeführt (vgl. Tabelle 6: Maßnahmen zur Erfüllung von EAL3+): Tabelle 6: Maßnahmen zur Erfüllung von EAL3+ Anforderungen gemäß EAL3+ Maßnahmen der Entwickler Konfigurations- management ACM_CAP.3 ACM_SCP.1 Einsatz eines QM-Systems inklusive Konfigurati- onskontrolle Auslieferung und Betrieb ADO_DEL.2 ADO_IGS.1 Dokumentation der zum Schutz des EVG bei Auslieferung, Installation und Wartung getroffe- nen Maßnahmen in Form dokumentierter Auslie- ferungsprozeduren sowie Installations-, Generie- rungs- und Anlaufprozeduren Entwicklung ADV_FSP.1 ADV_HLD.2 ADV_IMP.1 ADV_LLD.1 ADV_RCR.1 Definition von Anforderungen gemäß CC an die Entwicklungsprozeduren und Dokumentation Handbücher AGD_ADM.1 AGD_USR.1 Erstellung und Auslieferung eines Systemverwal- ter- und Benutzerhandbuchs 56 Dazu wird der OSCI-Client-Enabler als signiertes JAR-Archiv ausgeliefert, vgl. Ab- schnitt 2.7. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 68/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Anforderungen gemäß EAL3+ Maßnahmen der Entwickler Lebenszyklus- Unterstützung ALC_DVS.1 ALC_TAT.1 Gewährleistung des Entwicklungsprozesses durch physikalische, personelle und organisatori- sche Sicherheitsmaßnahmen Testen ATE_COV.2 ATE_DPT.1 ATE_FUN.1 ATE_IND.2 Verwendung eines werkzeugbasierten und auto- matisierten Testsystems zum Test der Sicher- heitsfunktionen, Tests auf Subsystem-Ebene und Tests der funktionalen Spezifikation. Dokumenta- tion der Ergebnisse sowie unabhängiges Testen durch den Evaluator Schwach- stellen- bewertung AVA_MSU.3 AVA_SOF.1 AVA_VLA.4 Erstellung von Missbrauchsanalysen, Analyse für die sicherheitsrelevanten Mechanismen in Bezug auf die Mechanismenstärke „hoch“ sowie Schwachstellenanalyse für alle Schwachstellen des EVG 7 PP-Postulate 179 Für die Sicherheitsvorgaben (ST) zur Evaluierung der Virtuellen Poststelle des Bundes wird kein Schutzprofil (Protection Profile – PP) postuliert. 8 Erklärungen 8.1 Erklärung der organisatorischen Sicherheitspolitiken 180 Der OSCI-Client-Enabler ist eine Funktionsbibliothek zum Erzeugen und Prü- fen qualifizierter elektronischer Signaturen samt Anzeige. Der OSCI-Ba- ckend-Enabler ist eine Funktionsbibliothek zum Prüfen qualifizierter elektroni- scher Signaturen ohne Anzeige. 181 In Abschnitt 2.5 ist beschrieben, in welchem Umfang die Sicherheitsanforde- rungen des SigG und der SigV an Signaturanwendungskomponenten vom EVG erfüllt werden und welcher Anteil von der IT-Umgebung umgesetzt wer- den muss. 182 Zusammenfassend muss der EVG damit die folgenden Anforderungen um- setzen, die in den organisatorischen Sicherheitspolitiken in Abschnitt 3.4 auf- geführt sind:  Erzeugung von Signaturen: o Der OSCI-Client-Enabler muss beim Erzeugen einer Signatur auf die zu signierenden Daten eine Hashfunktion gemäß OSCI-Transport (vgl. Abschnitt 2.2) anwenden und den erzeugten Hashwert der ange- schlossenen sicheren Signaturerstellungseinheit zuführen. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 69/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) o Der OSCI-Client-Enabler muss beim Erzeugen einer Signatur ge- währleisten, dass das Erzeugen einer Signatur vorher eindeutig an- gezeigt wird. o Der OSCI-Client-Enabler muss beim Erzeugen einer Signatur ge- währleisten, dass erkennbar ist, auf welche Daten sich die Signatur bezieht. o Der OSCI-Client-Enabler muss beim Erzeugen einer Signatur ge- währleisten, dass bei Bedarf der Inhalt der zu signierenden Daten hinreichend zu erkennen ist.  Prüfung von Signaturen: o OSCI-Client-Enabler und OSCI-Backend-Enabler müssen qualifizierte elektronische Signaturen prüfen. o OSCI-Client-Enabler und OSCI-Backend-Enabler müssen hinsichtlich der Validierung eine Plausibilitätsprüfung durchführen. o Der OSCI-Manager führt die Validierung mittels der Basiskomponente durch. o Der OSCI-Client-Enabler muss beim Prüfen einer Signatur gewähr- leisten, dass erkennbar wird, auf welche Daten sich die Signatur be- zieht. o Der OSCI-Client-Enabler muss beim Prüfen einer Signatur gewähr- leisten, dass erkennbar wird, ob die Daten unverändert sind. o Der OSCI-Client-Enabler muss beim Prüfen einer Signatur gewähr- leisten, dass bei Bedarf der Inhalt der signierten Daten hinreichend zu erkennen ist. o Der OSCI-Client-Enabler muss beim Prüfen einer Signatur gewähr- leisten, dass erkennbar wird, welchem Signaturschlüssel-Inhaber die Signatur zuzuordnen ist. o Der OSCI-Client-Enabler muss beim Prüfen einer Signatur gewähr- leisten, dass erkennbar wird, welche Inhalte das qualifizierte Zertifi- kat, auf dem die Signatur beruht, aufweisen. o Der OSCI-Client-Enabler muss beim Prüfen einer Signatur gewähr- leisten, dass erkennbar wird, ob die nachgeprüften qualifizierten Zerti- fikate im jeweiligen Zertifikatverzeichnis zum angegebenen Zeitpunkt vorhanden und nicht gesperrt waren. o OSCI-Client-Enabler und -Backend-Enabler müssen beim Prüfen ei- ner Signatur gewährleisten, dass die Korrektheit der Signatur zuver- lässig geprüft wird.  Schutz vor unbefugter Veränderung: o Für den OSCI-Client-Enabler wird ein Prüftool zur Verfügung gestellt (EVG-Umfang), um die Integrität zu gewährleisten. 183 In der IT-Umgebung müssen insbesondere folgende Anforderungen des SigG durch geeignete Signaturanwendungskomponenten umgesetzt werden bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 70/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) (vgl. Annahmen und Sicherheitsziele für die Umgebung in den Abschnitten 3.2 und 4.2):  Erzeugung von Signaturen: o Die sichere Signaturerstellungseinheit muss gewährleisten, dass eine Signatur nur durch die berechtigt signierende Person erfolgt. o Sichere Signaturerstellungseinheit und Chipkartenleser müssen ge- währleisten, dass die Identifikationsdaten nicht preisgegeben und nur auf der jeweiligen sicheren Signaturerstellungseinheit gespeichert werden.  Prüfung von Signaturen: o Die Basiskomponente in der IT-Umgebung muss beim Prüfen einer Signatur gewährleisten, dass festgestellt wird, ob die nachgeprüften qualifizierten Zertifikate im jeweiligen Zertifikatverzeichnis zum ange- gebenen Zeitpunkt vorhanden und nicht gesperrt waren.  Schutz vor unbefugter Veränderung: o Sicherheitstechnische Veränderungen an OSCI-Manager sowie OSCI-Client-Enabler und -Backend-Enabler müssen für den Adminis- trator bei den Serverkomponenten und den Benutzer bei den Client- komponenten erkennbar werden (vgl. Annahmen A.ServerBetrieb und A.ClientBetrieb). 8.2 Erklärung der Sicherheitsziele 184 Im Folgenden wird dargestellt und in Tabelle 7 und Tabelle 8 zusammenge- fasst, wie die einzelnen Annahmen, Bedrohungen und organisatorischen Si- cherheitspolitiken durch Sicherheitsziele für den EVG und die Umgebung ab- gedeckt werden.  Das Sicherheitsziel für die Umgebung OE.PKI zielt auf die gleichnamige Annahme A.PKI ab, wobei zu berücksichtigen ist, dass OE.PKI auch für die organisatorischen Sicherheitspolitiken P.SignaturZuf (für die Erzeu- gung einer qualifizierten elektronischen Signatur durch die sichere Signa- turerstellungseinheit mittels Chipkartenleser), P.ValidZert (für die Gültig- keitsprüfung durch obige Funktionalitäten der Basiskomponenten, für die Existenz qualifizierter Zertifikate sowie die kryptographischen Schlüssel und (System-)Zertifikate zur Gewährleistung der Systemsicherheit) sowie P.VerifySign (für Existenz qualifizierter Zertifikate) benötigt werden. Zu- dem wehrt OE.PKI die Bedrohung TE.RatePIN durch Verwendung einer geeigneten Signaturkarte ab.  Das Sicherheitsziel für die Umgebung OE.SAK zielt auf die gleichnamige Annahme A.SAK ab. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 71/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST)  Das Sicherheitsziel für die Umgebung OE.ServerBetrieb zielt auf die gleichnamige Annahme A.ServerBetrieb ab und ist zur Realisierung der organisatorischen Sicherheitspolitik P.ValidZert (für die Gewährleistung der Systemsicherheit aufgrund der Realisierung der Validierung innerhalb des verteilten Systems – d. h. dem Management des OSCI-Managers zum Signieren des OSCI-Laufzettels durch das Kernsystem und des (System-) Zertifikats im OSCI-Backend-Enabler zur Verifikation des OSCI-Laufzettels) notwendig.  Das Sicherheitsziel für die Umgebung OE.ClientBetrieb zielt auf die gleichnamige Annahme A.ClientBetrieb ab und ist zur Realisierung der organisatorischen Sicherheitspolitik P.ValidZert (für die Gewährleistung der Systemsicherheit aufgrund der Realisierung der Validierung innerhalb des verteilten Systems – d. h. dem Management des (System-) Zertifikats im OSCI-Client-Enabler zur Verifikation des OSCI-Laufzettels) notwendig. Zudem wehrt OE.ClientBetrieb die Bedrohung TE.SpähePIN durch geeig- nete Auflagen und Hinweise an den Signaturschlüssel-Inhaber zur Nut- zung seiner Signaturkarte ab  Das Sicherheitsziel für die Umgebung OE.ZufPIN zielt auf die gleichnami- ge Annahme A.ZufPIN ab.  Das Sicherheitsziel O.SignaturZuf deckt die organisatorische Sicherheits- politik P.SignaturZuf zur Erzeugung einer qualifizierten elektronischen Si- gnatur ab und präzisiert, dass der OSCI-Client-Enabler die zu signieren- den Daten gemäß OSCI-Transport der Hashfunktion zuführt und den Hashwert einer sicheren Signaturerstellungseinheit in der IT-Umgebung (vgl. OE.PKI) zugeführt. Zusätzlich wird durch die Verifikation der zuvor durch die Signaturkarte generierte qualifizierte elektronische Signatur mit dem auf der Signaturkarte befindlichen Zertifikat gewährleistet, dass für die richtigen Daten eine Signatur erzeugt wurde.  Das Sicherheitsziel O.Anzeige deckt die organisatorische Sicherheitspoli- tik P.Anzeige zur sicheren und zuverlässigen Anzeige bei der Erzeugung und Prüfung qualifizierter elektronischer Signaturen beim OSCI-Client- Enabler ab. Dabei wird durch die Verifikation festgestellt, ob die Daten unverändert sind. Die Anzeige umfasst nicht nur, was signiert wird und wurde, sondern auch ergänzende Informationen zur Nachricht, wie Zertifi- katsinhalt, Signaturschlüssel-Inhaber und Verifikations- und Validierungs- ergebnisse.  Das Sicherheitsziel O.ValidZert deckt die organisatorische Sicherheitspo- litik P.ValidZert zur Validierung qualifizierter Zertifikate ab und präzisiert die Aufgabenteilung. Zu berücksichtigen ist, dass die wesentlichen Aufga- ben bei der Validierung in der IT-Umgebung durch die Basiskomponente (vgl. Sicherheitsziel für die IT-Umgebung OE.PKI) geleistet wird und dass zur Gewährleistung der Systemsicherheit (innerhalb des verteilten Sys- tem) die Sicherheitsziele für die IT-Umgebung OE.ServerBetrieb und OE.ClientBetrieb benötigt werden. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 72/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST)  Das Sicherheitsziel O.VerifySign deckt die organisatorische Sicherheits- politik P.VerifySign zur Prüfung einer qualifizierten elektronischen Signa- tur ab und präzisiert, dass die Verifikation durch die Prüfung der Integrität und der Authentizität erfolgt (qualifizierte Zertifikate via Sicherheitsziel für die IT-Umgebung OE.PKI).  Das Sicherheitsziel O.Manipulation deckt die organisatorische Sicher- heitspolitik P.Manipulation zum Schutz vor unbefugter Veränderung des OSCI-Client-Enablers ab. Tabelle 7: Zuordnung Sicherheitsumgebung zu -zielen EVG-Sicherheitsumgebung zugehörige Sicherheitsziele A.PKI OE.PKI A.SAK OE.SAK A.ServerBetrieb OE.ServerBetrieb A.ClientBetrieb OE.ClientBetrieb A.ZufPIN OE.ZufPIN TE.RatePIN OE.PKI TE.SpähePIN OE.ClientBetrieb P.SignaturZuf O.SignaturZuf, OE.PKI P.Anzeige O.Anzeige P.ValidZert O.ValidZert, OE.PKI, OE.ServerBetrieb, OE.ClientBetrieb P.VerifySign O.VerifySign, OE.PKI P.Manipulation O.Manipulation Tabelle 8: Zuordnung Sicherheitsziele zu -umgebung Sicherheitsziele zugehörige EVG-Sicherheitsumgebung O.SignaturZuf P.SignaturZuf, A.PKI O.Anzeige P.Anzeige O.ValidZert P.ValidZert, A.PKI, A.ServerBetrieb, A.ClientBetrieb O.VerifySign P.VerifySign, A.PKI O.Manipulation P.Manipulation OE.PKI A.PKI, TE.RatePIN, P.SignaturZuf, P.ValidZert, P.VerifySign OE.SAK A.SAK OE.ServerBetrieb A.ServerBetrieb, P.ValidZert OE.ClientBetrieb A.ClientBetrieb, P.ValidZert, TE.SpähePIN bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 73/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Sicherheitsziele zugehörige EVG-Sicherheitsumgebung OE.ZufPIN A.ZufPIN 8.3 Erklärung der Sicherheitsanforderungen 8.3.1 Erklärung zu den funktionalen Sicherheitsanforderungen 185 Wie die Sicherheitsziele, die sich auf IT beziehen, durch die funktionalen Si- cherheitsanforderungen erfüllt werden, ist im Folgenden dargestellt und in Tabelle 9 und Tabelle 10 hinsichtlich des EVG und in Tabelle 11 und Tabelle 12 hinsichtlich der IT-Umgebung zusammengefasst:  Die in FCS_COP.1.1/Hash spezifizierte Hashfunktion wird gemäß OSCI- Transport genutzt (vgl. Abschnitt 2.2).  Die funktionale Sicherheitsanforderung FCS_COP.1 (Hash) wird für die Umsetzung des Sicherheitsziels O.SignaturZuf benötigt.  Die funktionale Sicherheitsanforderung FCS_COP.1 (VSign) wird für die Umsetzung des Sicherheitsziels O.SignaturZuf in der Weise benötigt, dass eine zuvor erzeugte qualifizierte elektronische Signatur mit Hilfe des zum privaten Schlüssel korrespondierenden Zertifikats, das sich auf der Signaturkarte befindet, verifiziert wird.  Die funktionale Sicherheitsanforderung FDP_SVR.1 wird für die Umset- zung des Sicherheitsziels O.Anzeige benötigt.  Die funktionale Sicherheitsanforderung FCS_COP.1 (Valid) wird für die Umsetzung des Sicherheitsziels O.ValidZert in der Weise benötigt, dass OSCI-Client-Enabler und -Backend-Enabler die Signatur des OSCI-Lauf- zettels (vom OSCI-Manager mit Hilfe der Basiskomponente erzeugt) mit dem (System-)Zertifikat verifizieren müssen.  Die funktionale Sicherheitsanforderung FCS_COP.1 (OSCI) wird für die Umsetzung des Sicherheitsziels O.ValidZert in der Weise benötigt, dass der OSCI-Manager auf den OSCI-Laufzettel die Hashfunktion SHA-1 an- wendet und durch das Kernsystem der Basiskomponente signieren lässt, so dass die elektronische Signatur des OSCI-Laufzettels dann von OSCI- Client-Enabler und -Backend-Enabler mit dem – dem OSCI-Manager zu- geordneten – (System-) Zertifikat verifiziert werden kann.  Die funktionale Sicherheitsanforderung FDP_ACC.1 ergibt sich aus der Abhängigkeit von FDP_ITC.1 und wird daher implizit für die Umsetzung des Sicherheitsziels O.ValidZert in der Weise benötigt, dass der OSCI- Manager den OSCI-Laufzettel durch das Kernsystem der Basiskompo- nente signieren lässt und dazu den zu nutzenden Schlüssel referenziert. In dieser Sicherheitsanforderung werden Subjekt, Objekt sowie zulässige Operationen zwischen Subjekten und Objekten hinsichtlich der Systemsi- cherheit-Zugriffskontrollpolitik definiert. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 74/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST)  Die funktionale Sicherheitsanforderung FDP_ACF.1 ergibt sich aus der Abhängigkeit von FDP_ACC.1 und wird daher implizit für die Umsetzung des Sicherheitsziels O.ValidZert in der Weise benötigt, dass der OSCI- Manager den OSCI-Laufzettel durch das Kernsystem der Basiskompo- nente signieren lässt und dazu den zu nutzenden Schlüssel referenziert. In dieser Sicherheitsanforderung wird thematisiert, dass eine zulässige Operation (vgl. FDP_ACC.1) erst nach erfolgreicher Authentisierung des Schlüssel-Administrators erfolgen kann.  Die funktionale Sicherheitsanforderung FDP_ITC.1 wird für die Umset- zung des Sicherheitsziels O.ValidZert in der Weise benötigt, dass der OSCI-Manager den OSCI-Laufzettel durch das Kernsystem der Basis- komponente signieren lässt – und dazu den zu nutzenden Schlüssel refe- renziert –, so dass die Signatur dann von OSCI-Client-Enabler und -Ba- ckend-Enabler mit dem (System-)Zertifikat verifizieren werden kann.  Die funktionale Sicherheitsanforderung FIA_UID.2 ergibt sich aus der Ab- hängigkeit von FMT_SMR.1, wobei statt FIA_UID.1 die hierarchische An- forderung FIA_UID.2 genutzt wird. FIA_UID.2 wird damit implizit für die Umsetzung des Sicherheitsziels O.ValidZert benötigt.  Die funktionale Sicherheitsanforderung FIA_UAU.2 wird – wie FIA_UID.2 auch – für die Umsetzung des Sicherheitsziels O.ValidZert benötigt.  Die funktionale Sicherheitsanforderung FMT_MSA.1 ergibt sich aus der Abhängigkeit von FMT_MSA.3 und wird implizit für die Umsetzung des Sicherheitsziels O.ValidZert benötigt. Im Fokus der Betrachtung steht hierbei das Management der Rolle des Schlüssel-Administrators durch den Security-Administrator; die zulässigen Operationen mit den privaten Schlüsseln werden in FDP_ACC.1 und FDP_ACF.1 thematisiert.  Die funktionale Sicherheitsanforderung FMT_MSA.3 ergibt sich aus den Abhängigkeiten von FDP_ITC.1 und FDP_ACF.1 und wird daher implizit für die Umsetzung des Sicherheitsziels O.ValidZert benötigt. Im Fokus der Betrachtung steht hierbei das Management der Rolle des Schlüssel- Administrators durch den Security-Administrator; die zulässigen Operatio- nen werden in FDP_ACC.1 und FDP_ACF.1 thematisiert.  Die funktionale Sicherheitsanforderung FMT_SMR.1 ergibt sich aus den Abhängigkeiten von FMT_MSA.1 (für die Rolle des Security-Administra- tors für die Konfiguration der Rechte, Rollen und Berechtigungen) und FMT_MSA.3 (für die Rolle des Schlüssel-Administrators zum Manage- ment der Referenz der privaten Schlüssel) und wird implizit für die Umset- zung des Sicherheitsziels O.ValidZert benötigt.  Die funktionale Sicherheitsanforderung FCS_COP.1 (Verify) wird für die Umsetzung des Sicherheitsziels O.VerifySign benötigt.  Die funktionale Sicherheitsanforderung FCS_COP.1 (Tool) wird für die Umsetzung des Sicherheitsziels O.Manipulation benötigt.  Die funktionale Sicherheitsanforderung FTP_ITC.1 wird implizit für die Umsetzung des Sicherheitsziels O.SignaturZuf benötigt, wobei ein ver- trauenswürdiger Kanal zwischen EVG und Signaturkarte aufgebaut wird. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 75/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST)  Die drei funktionalen Sicherheitsanforderungen an die IT-Umgebung – FCS_CKM.1 oder FDP_ITC.1 sowie FCS_CKM.4 und FMT_MSA.2 – er- geben sich aus den Sicherheitszielen O.ValidZert (bzgl. Schlüsselerzeu- gung oder -import, Zerstörung und Schlüsselmanagement des (System-) Zertifikats in OSCI-Client bzw. -Backend, auf dem OSCI-Client-Enabler resp. -Backend-Enabler betrieben werden), O.SignaturZuf (bzgl. Schlüs- selimport, -zerstörung und -management des zum privaten Schlüssel kor- respondierenden Zertifikats, das sich auf der Signaturkarte befindet,) O.Manipulation (bzgl. Schlüsselimport, -zerstörung und -management in Prüftool), OE.PKI (bzgl. Schlüsselerzeugung oder -import, Schlüsselzer- störung und -management für Schlüssel und korrespondierende (System-) Zertifikate in IT-Umgebung) und OE.SAK (bzgl. der Sicherstel- lung, dass nur sichere Sicherheitsattribute – insbesondere für die (Sys- tem-) Zertifikate – akzeptiert werden). Die Ausgestaltung der Operationen der funktionalen Sicherheitsanforderungen sowie die Abhängigkeiten die- ser Anforderungen sind in der IT-Umgebung zu realisieren, da Schlüssel- erzeugung, -import und -löschung sowie Management der Sicherheits- attribute in der IT-Umgebung außerhalb des EVG liegt.  Die in Tabelle 5 referenzierten funktionalen Sicherheitsanforderungen an die IT-Umgebung FCO_NRO.1, FCS_CKM.4, FCS_COP.1 (Verify), FCS_COP.1 (SVVE), FCS_COP.1 (VVE), FDP_ACC.1 (Sys), FDP_ACF.1 (Sys), FDP_ITC.1, FIA_UID.2, FMT_MSA.1 (Sys), FMT_MSA.2, FMT_MSA.3 (Sys) und FMT_SMR.1 (Sys) lassen sich auf das Sicherheitsziel der IT-Umgebung OE.PKI hinsichtlich der Validierung qualifizierter Zertifikate und des unterstützenden Sicherheitsmechanis- mus’ zur Erzeugung einer elektronischen Signatur für einen vom OSCI- Manager erzeugten und übermittelten Hashwert, für die die Basiskompo- nente der Virtuellen Poststelle des Bundes (vgl. [bos_Basis_ST]) benötigt wird, zurückführen.  Die funktionalen Sicherheitsanforderungen an die IT-Umgebung zu den SigG-konformen sicheren Signaturerstellungseinheiten und Chipkartenle- sern, die den Sicherheitsvorgaben bestätigter Produkte zu entnehmen sind (vgl. beispielsweise www.bundesnetzagentur.de), lassen sich auf die Sicherheitsziele der IT-Umgebung OE.PKI und OE.ZufPIN hinsichtlich der SigG-konformen sicheren Signaturerstellungseinheiten und Chipkartenle- ser sowie der qualifizierten Zertifikate zurückführen; weitere Anforderun- gen werden nicht benötigt. Tabelle 9: Zuordnung Sicherheitsziele zu Sicherheitsanforderungen an den EVG Sicherheitsziele funktionale Sicherheitsanforderungen an den EVG O.SignaturZuf FCS_COP.1 (Hash), FCS_COP.1 (VSign), FTP_ITC.1 O.Anzeige FDP_SVR.1 O.ValidZert FCS_COP.1 (Valid), FCS_COP.1 (OSCI), FDP_ACC.1, FDP_ACF.1, FDP_ITC.1, FIA_UID.2, FIA_UAU.2, FMT_MSA.1, FMT_MSA.3, FMT_SMR.1 bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 76/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) O.VerifySign FCS_COP.1 (Verify) O.Manipulation FCS_COP.1 (Tool) Tabelle 10: Zuordung fkt. Sicherheitsanforderungen zu Sicherheitszielen funktionale Sicherheitsanforderungen an den EVG Sicherheitsziele FCS_COP.1 (Hash) O.SignaturZuf FCS_COP.1 (Valid) O.ValidZert FCS_COP.1 (OSCI) O.ValidZert FCS_COP.1 (Verify) O.VerifySign FCS_COP.1 (VSign) O.SignaturZuf FCS_COP.1 (Tool) O.Manipulation FDP_SVR.1 O.Anzeige FDP_ACC.1 O.ValidZert FDP_ACF.1 O.ValidZert FDP_ITC.1 O.ValidZert FIA_UID.2 O.ValidZert FIA_UAU.2 O.ValidZert FMT_MSA.1 O.ValidZert FMT_MSA.3 O.ValidZert FMT_SMR.1 O.ValidZert FTP_ITC.1 O.SignaturZuf Tabelle 11: Zuordnung Sicherheitsziele zu Sicherheitsanforderungen an die IT-Um- gebung Sicherheitsziele funktionale Sicherheitsanforderungen an die IT-Umgebung O.SignaturZuf FDP_ITC.1, FCS_CKM.4, FMT_MSA.2 O.Anzeige - O.ValidZert FCS_CKM.1 oder FDP_ITC.1, FCS_CKM.4, FMT_MSA.2 O.VerifySign - O.Manipulation FCS_CKM.1 oder FDP_ITC.1, FCS_CKM.4, FMT_MSA.2 bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 77/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) OE.PKI zu sicheren Signaturerstellungseinheiten, zu Chipkartenlesern, zu qualifizierten Zertifikaten: vgl. Sicherheitsvorgaben bestätigter Pro- dukte zu privaten Schlüsseln und (System-)Zertifikaten: FCS_CKM.1 oder FDP_ITC.1, FCS_CKM.4, FMT_MSA.2 zur Validierung eines qualifizierten Zertifikats und zur Erzeugung ei- ner elektronischen Signatur: FCO_NRO.1, FCS_CKM.4, FCS_COP.1 (Verify), FCS_COP.1 (SVVE), FCS_COP.1 (VVE), FDP_ACC.1 (Sys), FDP_ACF.1 (Sys), FDP_ITC.1, FIA_UID.2, FMT_MSA.1 (Sys), FMT_MSA.2, FMT_MSA.3 (Sys) und FMT_SMR.1 (Sys) OE.SAK FMT_MSA.2 OE.ZufPIN vgl. Sicherheitsvorgaben bestätigter Produkte Tabelle 12: Zuordung fkt. Sicherheitsanforderungen an die IT-Umgebung zu Sicher- heitszielen funktionale Sicherheitsanforderungen an die IT-Umgebung Sicherheitsziele FCS_CKM.1 oder FDP_ITC.1 O.ValidZert, O.SignaturZuf, O.Manipulation, OE.PKI (bzgl. privater Schlüssel und (Sys- tem-)Zertifikate) FCS_CKM.4 O.ValidZert, O.SignaturZuf, O.Manipulation, OE.PKI (bzgl. privater Schlüssel und (Sys- tem-)Zertifikate) FMT_MSA.2 O.ValidZert, O.SignaturZuf, O.Manipulation, OE.PKI (bzgl. privater Schlüssel und (Sys- tem-)Zertifikate), OE.SAK FCO_NRO.1, FCS_CKM.4, FCS_COP.1 (Verify), FCS_COP.1 (SVVE), FCS_COP.1 (VVE), FDP_ACC.1 (Sys), FDP_ACF.1 (Sys), FDP_ITC.1, FIA_UID.2, FMT_MSA.1 (Sys), FMT_MSA.2, FMT_MSA.3 (Sys) und FMT_SMR.1 (Sys) OE.PKI funktionale Sicherheitsanforderungen, die an SigG-konforme sichere Signatur- erstellungseinheiten und Chipkartenle- ser gestellt werden, sind den Sicher- heitsvorgaben bestätigter Produkte zu entnehmen OE.PKI (sichere Signaturerstellungseinheiten und Chipkartenleser) OE.ZufPIN bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 78/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) 8.3.2 Erfüllung der Abhängigkeiten 186 Die EVG-Abhängigkeiten sind berücksichtigt, wie im Folgenden ausgeführt und in Tabelle 13 zusammenfassend dargestellt:  Die Abhängigkeiten der funktionalen Sicherheitsanforderung FCS_COP.1 (Hash) sind nicht erfüllt, da keine Schlüssel involviert sind (weder Schlüs- selerzeugung gemäß FCS_CKM.1 oder Schlüsselimport gemäß FDP_ITC.1 noch Zerstörung eines Schlüssels gemäß FCS_CKM.4) und daher kein Schlüsselmanagement gemäß FMT_MSA.2 notwendig ist.  Die Abhängigkeiten der funktionalen Sicherheitsanforderung FCS_COP.1 (VSign) – Schlüsselimport gemäß FDP_ITC.1, Zerstörung eines Schlüs- sels gemäß FCS_CKM.4 und Schlüsselmanagement gemäß FMT_MSA.2) – sind in der IT-Umgebung für die Signaturkarte zu realisie- ren; eine Schlüsselerzeugung gemäß FCS_CKM.1 ist nicht anwendbar, da Zertifikate auf der Signaturkarte abgespeichert, dort aber nicht erzeugt werden.  FDP_SVR.1 hat keine Abhängigkeiten.  Die Abhängigkeiten der funktionalen Sicherheitsanforderung FCS_COP.1 (Valid) – Schlüsselerzeugung gemäß FCS_CKM.1 oder Schlüsselimport gemäß FDP_ITC.1, Zerstörung eines Schlüssels gemäß FCS_CKM.4 und Schlüsselmanagement gemäß FMT_MSA.2) – sind in der IT-Umge- bung im OSCI-Client bzw. -Backend, auf dem OSCI-Client-Enabler resp. - Backend-Enabler betrieben werden, zu realisieren.  Die Abhängigkeiten der funktionalen Sicherheitsanforderung FCS_COP.1 (OSCI) sind nicht erfüllt,  Die Abhängigkeit von FDP_ACC.1 – FDP_ACF.1 – ist aufgenommen.  Die Abhängigkeiten von FDP_ACF.1 – FDP_ACC.1 und FMT_MSA.3 sind aufgenommen.  Die Abhängigkeiten von FDP_ITC.1 – FDP_ACC.1 für die Zugriffskontrol- le und FMT_MSA.3 zum Management des privaten Schlüssels sind auf- genommen.  FIA_UID.2 hat keine Abhängigkeiten.  FIA_UAU.2 hat die Abhängigkeit FIA_UID.1, die durch die hierarchische Anforderung FIA_UID.2 realisiert wird.  Die Abhängigkeiten von FMT_MSA.1 – FDP_ACC.1 und FMT_SMR.1 – sind aufgenommen.  Die Abhängigkeiten von FMT_MSA.3 – FMT_MSA.1 und FMT_SMR.1 – sind aufgenommen.  Die Abhängigkeit von FMT_SMR.1 – FIA_UID.1 – ist aufgenommen. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 79/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST)  Die Abhängigkeiten der funktionalen Sicherheitsanforderung FCS_COP.1 (Verify) sind nicht erfüllt, da die für die Verifikation genutzten öffentlichen Schlüssel aus den Zertifikaten öffentliche Informationen sind und keine Sicherheitsattribute darstellen (keine Schlüsselerzeugung gemäß FCS_CKM.1, kein Schlüsselimport gemäß FDP_ITC.1 , keine Zerstörung eines Schlüssels gemäß FCS_CKM.4, kein Schlüsselmanagement ge- mäß FMT_MSA.2).  Die Abhängigkeiten der funktionalen Sicherheitsanforderung FCS_COP.1 (Tool) – Schlüsselimport gemäß FDP_ITC.1 (Schlüsselerzeugung gemäß FCS_CKM.1 ist bei Zertifikaten nicht anwendbar), Zerstörung eines Schlüssels gemäß FCS_CKM.4 und Schlüsselmanagement gemäß FMT_MSA.2) – sind in der IT-Umgebung für das Prüftool zu realisieren, da die für die Prüfung notwendigen Zertifikate vom Hersteller in das Tool eingebracht und mit dem Tool ausgeliefert werden.  FTP_ITC.1 hat keine Abhängigkeiten.  Zu den funktionalen Sicherheitsanforderungen in der IT-Umgebung: o Die Abhängigkeiten der drei funktionalen Sicherheitsanforderun- gen FCS_CKM.1 oder FDP_ITC.1, FCS_CKM.4 und FMT_MSA.2 sind in der IT-Umgebung zu realisieren, da Schlüsselerzeugung, - import und -löschung sowie Management der Sicherheitsattribute in der IT-Umgebung außerhalb des EVG liegt. o Die funktionalen Sicherheitsanforderungen in der IT-Umgebung, die sich aus der Nutzung der Basiskomponente zur Validierung eines qualifizierten Zertifikats und Erzeugung einer elektronischen Signatur – FCO_NRO.1, FCS_CKM.4, FCS_COP.1 (Verify), FCS_COP.1 (SVVE), FCS_COP.1 (VVE), FDP_ACC.1 (Sys), FDP_ACF.1 (Sys), FDP_ITC.1, FIA_UID.2, FMT_MSA.1 (Sys), FMT_MSA.2, FMT_MSA.3 (Sys) und FMT_SMR.1 (Sys) ergeben –, sind in der IT-Umgebung zu realisieren; wie [bos_Basis_ST] zu entnehmen ist, sind diese hinsichtlich der Abhängigkeiten in sich abgeschlossen. Tabelle 13: Erfüllung der EVG-Abhängigkeiten funktionale Sicherheits- anforderungen an den EVG Abhängigkeiten Bemerkung FCS_COP.1 (Hash) FDP_ITC.1 oder FCS_CKM.1 FCS_CKM.4 FMT_MSA.2 formal nicht erfüllt wg. Hashfunktion FCS_COP.1 (Valid) FDP_ITC.1 oder FCS_CKM.1 FCS_CKM.4 FMT_MSA.2 sind in der IT-Umge- bung zu realisieren FCS_COP.1 (OSCI) FDP_ITC.1 oder FCS_CKM.1 formal nicht erfüllt wg. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 80/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) funktionale Sicherheits- anforderungen an den EVG Abhängigkeiten Bemerkung FCS_CKM.4 FMT_MSA.2 Hashfunktion FCS_COP.1 (Verify) FDP_ITC.1 oder FCS_CKM.1 FCS_CKM.4 FMT_MSA.2 formal nicht erfüllt wg. Nutzung öffentlicher Zertifikate FCS_COP.1 (VSign) FDP_ITC.1 oder FCS_CKM.1 FCS_CKM.4 FMT_MSA.2 sind in der IT-Umge- bung zu realisieren FCS_COP.1 (Tool) FDP_ITC.1 oder FCS_CKM.1 FCS_CKM.4 FMT_MSA.2 sind in der IT-Umge- bung zu realisieren FDP_SVR.1 - formal erfüllt FDP_ACC.1 FDP_ACF.1 erfüllt FDP_ACF.1 FDP_ACC.1 FMT_MSA.3 erfüllt erfüllt FDP_ITC.1 FDP_ACC.1 oder FDP_IFC.1 FMT_MSA.3 erfüllt für FDP_ACC.1 erfüllt FIA_UID.2 - formal erfüllt FIA_UAU.2 FIA_UID.1 erfüllt durch FIA_UID.2, das hier- archisch zu FIA_UID.1 ist FMT_MSA.1 FDP_ACC.1 oder FDP_IFC.1 FMT_SMR.1 erfüllt für FDP_ACC.1 erfüllt FMT_MSA.3 FMT_MSA.1 FMT_SMR.1 erfüllt erfüllt FMT_SMR.1 FIA_UID.1 erfüllt durch FIA_UID.2, das hier- archisch zu FIA_UID.1 ist FTP_ITC.1 - formal erfüllt bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 81/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) 8.3.3 Analyse des Zusammenwirkens der funktionalen Anforderungen 187 Aus den vorigen Ausführungen wird deutlich, dass die funktionalen Sicher- heitsanforderungen eine in sich geschlossene Einheit bilden und geeignet sind, gemeinsam alle Sicherheitsziele zu erfüllen. 188 Da alle von den CC geforderten Abhängigkeiten der einzelnen Sicherheitsan- forderungen – soweit auf den vorliegenden EVG anwendbar – erfüllt werden, ist das ordnungsgemäße Zusammenwirken dieser Sicherheitsanforderungen gewährleistet. 8.3.4 Analyse der Mindest-Stärkestufe 189 Gemäß SigG/SigV muss eine Signaturanwendungskomponente die in Anlage 1 der Signaturverordnung [SigV] definierte Vertrauenswürdigkeitsstufe EAL3 erreichen, wobei folgende Anforderungen an die Schwachstellenbewertung bzw. Mechanismenstärke formuliert ist: „Bei den Prüfstufen […] ‚EAL3’ […] ist ergänzend zu den bei dieser Prüfstufe vorgeschriebenen Maßnahmen gegen ein hohes Angriffspotenzial zu prüfen und eine vollständige Missbrauchsana- lyse durchzuführen“. 190 Die Prüfung gegen ein hohes Angriffspotential (SOF-hoch) korrespondiert ge- mäß CC-Teil 3, Abschnitt 14.4, [CC-Teil3], und CEM, Abschnitt B.8, [CEM], mit der Vertrauenswürdigkeitskomponente AVA_VLA.4. Hierbei sind zusätz- lich die Anforderungen aus den „Anwendungshinweisen und Interpretationen zum Schema (AIS)“ Nr. 27 [AIS27] zu berücksichtigen. In AIS 27 werden Ver- trauenswürdigkeitskomponenten aufgeführt, die zusätzlich zu den in den EAL-Stufen der Common Criteria ausgewählten Komponenten auszuwählen – d. h. zu augmentieren – sind, um den Anforderungen der ITSEC zu genü- gen. Relevant für diese Sicherheitsvorgaben sind die in Anlage 1 der Signa- turverordnung [SigV] beschriebenen Anforderungen hinsichtlich der Stärke der Sicherheitsmechanismen, die mit „hoch“ bewertet werden müssen. 191 Die angestrebten SOF-Stufen der einzelnen Sicherheitsfunktionen sind in Ta- belle 14 aufgeführt. Tabelle 14: Angestrebten SOF-Stufen für die Sicherheitsfunktionen Sicherheits- funktion Mechanismentyp Angestrebte Stärke SF1 Wahrscheinlichkeits- oder Permutationsmechanismen (Hashfunktion) SOF-hoch SF2 Wahrscheinlichkeits- oder Permutationsmechanismen (Verifikationsalgorithmus, Hashfunktion) SOF-hoch SF3 Wahrscheinlichkeits- oder Permutationsmechanismen (Verifikationsalgorithmus, Hashfunktion) SOF-hoch SF4 Wahrscheinlichkeits- oder Permutationsmechanismen (Verifikationsalgorithmus, Hashfunktion) SOF-hoch SF5 deterministisch nicht anwendbar bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 82/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Sicherheits- funktion Mechanismentyp Angestrebte Stärke SF6 Wahrscheinlichkeits- oder Permutationsmechanismen (Hashfunktion) SOF-hoch SF7 Wahrscheinlichkeits- oder Permutationsmechanismen (Passwort) SOF-hoch SF8 Wahrscheinlichkeits- oder Permutationsmechanismen (Verifikationsalgorithmus, Hashfunktion) SOF-hoch 8.3.5 Erklärung zu den Anforderungen an die Vertrauenswürdigkeit 192 Die Auswahl der Vertrauenswürdigkeitskomponenten ergibt sich direkt aus den Anforderungen von Signaturgesetz und -verordnung, wie in Abschnitt 1.3 ausführlich dargelegt wird. 8.4 Erklärung der EVG-Übersichtsspezifikation 8.4.1 Erfüllung der funktionalen Sicherheitsanforderungen 193 Die Sicherheitsfunktionen wirken mit den funktionalen Sicherheitsanforderun- gen wie folgt (vgl. Tabelle 15, wobei ein „X“ eine für die jeweilige Sicherheits- funktion zutreffende funktionale Sicherheitsanforderung signalisiert):  Für die Sicherheitsfunktion SF1 „Unterstützung bei der Erzeugung qualifi- zierter elektronischer Signaturen (Hashen und Zuführen zu signierender Dokumente zu einer sicheren Signaturerstellungseinheit)“ werden folgen- de Komponenten benötigt: o Komponente FCS_COP.1 (Hash) zum Hashen zu signierender Daten.  Für die Sicherheitsfunktion SF2 „Schutz gegen Hashwertmanipulation“ werden folgende Komponenten benötigt: o Komponente FCS_COP.1 (VSign) zum Verifizieren einer zuvor erzeugten qualifizierten elektronischen Signatur. o Komponente FTP_ITC.1 für den vertrauenswürdigen Kanal zwi- schen EVG und Signaturkarte. o In der IT-Umgebung ist FCS_CKM.1 oder FDP_ITC.1, FCS_CKM.4 und FMT_MSA.2 umzusetzen.  Für die Sicherheitsfunktion SF3 „Verifikation einer qualifizierten elektroni- schen Signatur“ werden folgende Komponenten benötigt: o Komponente FCS_COP.1 (Verify) zur Verifikation einer qualifizier- ten elektronischen Signatur. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 83/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST)  Für die Sicherheitsfunktion SF4 „Verifikation eines OSCI-Laufzettels bei der Validierung eines qualifizierten Zertifikats“ werden folgende Kompo- nenten benötigt: o Komponente FCS_COP.1 (Valid) für die Verifikation des signier- ten OSCI-Laufzettels, auf dem die Validierungsergebnisse vor- handen sind. o In der IT-Umgebung – im OSCI-Client bzw. OSCI-Backend – ist FCS_CKM.1 oder FDP_ITC.1, FCS_CKM.4 und FMT_MSA.2 um- zusetzen.  Für die Sicherheitsfunktion SF5 „Sichere und zuverlässige Anzeige“ wer- den folgende Komponenten benötigt: o Komponente FDP_SVR.1 für die sichere Anzeige.  Für die Sicherheitsfunktion SF6 „Unterstützung bei der Validierung qualifi- zierter Zertifikate“ werden folgende Komponenten benötigt: o Komponente FCS_COP.1 (OSCI) für das Hashen des OSCI-Lauf- zettels. o In der IT-Umgebung wird die Basiskomponente zur Validierung ei- nes qualifizierten Zertifikats und zur Erzeugung einer elektroni- schen Signatur benötigt; FCO_NRO.1, FCS_CKM.4, FCS_COP.1 (Verify), FCS_COP.1 (SVVE), FCS_COP.1 (VVE), FDP_ACC.1 (Sys), FDP_ACF.1 (Sys), FDP_ITC.1, FIA_UID.2, FMT_MSA.1 (Sys), FMT_MSA.2, FMT_MSA.3 (Sys) und FMT_SMR.1 (Sys) sind umzusetzen. o Diverse weitere Komponenten sind aufgenommen: FDP_ITC.1, FDP_ACC.1, FDP_ACF.1, FMT_MSA.3, FMT_MSA.1, FMT_SMR.1, FIA_UID.2, FIA_UAU.2.  Für die Sicherheitsfunktion SF7 „Identifikation und Authentisierung“ wer- den folgende Komponenten benötigt: o Komponenten FDP_ACC.1, FDP_ACF.1, FMT_MSA.3, FMT_MSA.1, FTM_SMR.1, FIA_UID.2, FIA_UAU.2 zur Zugriffs- kontrolle für das Management im OSCI-Manager.  Für die Sicherheitsfunktion SF8 „Prüftool“ werden folgende Komponenten benötigt: o Komponente FCS_COP.1 (Tool) zum Verifizieren von Daten. o Über die Abhängigkeiten ist in der IT-Umgebung – im Prüftool – FCS_CKM.1 oder FDP_ITC.1, FCS_CKM.4 und FMT_MSA.2 um- zusetzen. 194 Darüber hinaus werden funktionale Sicherheitsanforderungen in der IT-Um- gebung für SigG-konforme sichere Signaturerstellungseinheiten und Chipkar- tenleser referenziert, die den Sicherheitsvorgaben bestätigter Produkte zu entnehmen sind (vgl. beispielsweise www.bundesnetzagentur.de. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 84/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Tabelle 15: Zuordnung fkt. Sicherheitsanforderungen durch Sicherheitsfunktionen Fkt. Sicherheitsanfor- derungen an EVG bzw. IT-Umgebung SF1 SF2 SF3 SF4 SF5 SF6 SF7 SF8 FCS_COP.1 (Hash) X FCS_COP.1 (Valid) X FCS_COP.1 (OSCI) X FCS_COP.1 (Verify) X FCS_COP.1 (VSign) X FCS_COP.1 (Tool) X FDP_SVR.1 X FDP_ACC.1 X X FDP_ACF.1 X X FDP_ITC.1 X FIA_UID.2 X X FIA_UAU.2 X X FMT_MSA.1 X X FMT_MSA.3 X X FMT_SMR.1 X X FTP_ITC.1 X FCS_CKM.1 oder FDP_ITC.1 X X X FCS_CKM.4 X X X FMT_MSA.2 X X X FCO_NRO.1, FCS_CKM.4, FCS_COP.1 (Verify), FCS_COP.1 (SVVE), FCS_COP.1 (VVE), FDP_ACC.1 (Sys), FDP_ACF.1 (Sys), FDP_ITC.1, FIA_UID.2, FMT_MSA.1 (Sys), FMT_MSA.2, FMT_MSA.3 (Sys) und FMT_SMR.1 (Sys) X bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 85/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) 195 Die Sicherheitsfunktionen wirken in den drei Teilsystemen OSCI-Client-Enab- ler, -Manager und -Backend-Enabler wie folgt (Tabelle 16): Tabelle 16: Zuordnung von Sicherheitsfunktionen zu Teilsystemen OSCI-Client- Enabler OSCI-Mana- ger OSCI-Ba- ckend- Enabler SF1 – Unterstützung bei der Erzeugung qualifizierter elektronischer Signaturen X SF2 – Schutz gegen Hashwertmanipula- tion X SF3 – Verifikation einer qualifizierten elektronischen Signatur X X SF4 – Verifikation eines OSCI-Laufzet- tels bei der Validierung eines qualifizier- ten Zertifikats X X SF5 – Sichere und zuverlässige Anzeige X SF6 – Unterstützung bei der Validierung qualifizierter Zertifikate X SF7 – Identifikation und Authentisierung X SF8 – Prüftool X 8.4.2 Konsistenz der Mechanismenstärke-Postulate 196 Die geforderte Stärke der Sicherheitsmechanismen von SOF-hoch findet sich in den Angaben zu den Maßnahmen zur Vertrauenswürdigkeit wieder (vgl. Tabelle 6 und Tabelle 19). 8.4.3 Analyse des Zusammenwirkens der Sicherheitsfunktionen 197 Im Folgenden ist ausgeführt und in Tabelle 17 zusammengefasst, wie die Si- cherheitsfunktionen  SF1 – Unterstützung bei der Erzeugung qualifizierter elektronischer Sig- naturen (Hashen und Zuführen zu signierender Dokumente zu einer si- cheren Signaturerstellungseinheit),  SF2 – Schutz gegen Hashwertmanipulation,  SF3 – Verifikation einer qualifizierten elektronischen Signatur,  SF4 – Verifikation eines OSCI-Laufzettels bei der Validierung eines quali- fizierten Zertifikats,  SF5 – Sichere und zuverlässige Anzeige,  SF6 – Unterstützung bei der Validierung qualifizierter Zertifikate, bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 86/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST)  SF7 – Identifikation und Authentisierung,  SF8 – Prüftool zusammenwirken, wobei ein „X“ in Tabelle 17 ein Zusammenwirken signali- siert. Tabelle 17 ist nicht symmetrisch. 198 Da bei der Unterstützung der Erzeugung einer qualifizierten elektronischen Signatur sowie der Verifikation einer qualifizierten elektronischen Signatur und der Validierung beim OSCI-Client-Enabler der Benutzer bzw. Signatur- schlüssel-Inhaber durch geeignete Anzeigen unterstützt wird, wirkt SF5 stets bei SF1, SF2, SF3 und SF4. 199 Da im Rahmen der Erzeugung einer qualifizierten elektronischen Signatur der zuvor erzeugte Hashwert geprüft wird, wirken SF1 und SF2 stets zusammen. 200 Da die Validierung durch den OSCI-Manager ausgeführt wird, der wiederum das Validierungsergebnis OSCI-Client-Enabler und -Backend-Enabler auf dem OSCI-Laufzettel zur Verfügung stellt, setzt SF4 voraus, dass zuvor SF6 ausgeführt wurde. 201 Da der OSCI-Manager den OSCI-Laufzettel signiert und entsprechende pri- vate Schlüssel in den OSCI-Manager eingebracht werden müssen, setzt SF6 voraus, dass SF7 für die Identifikation und Authentisierung des Schlüssel-Ad- ministrator ausgeführt wurde. Tabelle 17: Zusammenwirken der Sicherheitsfunktionen SF1 SF2 SF3 SF4 SF5 SF6 SF7 SF8 SF1 X X SF2 X X SF3 X SF4 X SF5 X X X X X SF6 X X SF7 X X SF8 X 8.4.4 Zuordnung der Sicherheitsfunktionen zur Umsetzung der SigG-Anforde- rungen 202 In Abschnitt 2.5.2 wurde beschrieben, in welchem Umfang die Sicherheitsan- forderungen des SigG und der SigV an Signaturanwendungskomponenten vom EVG erfüllt werden und welcher Anteil von der IT-Umgebung umgesetzt werden muss (vgl. Tabelle 1). Im Folgenden wird angegeben, durch welche Sicherheitsfunktion die SigG/SigV-Anforderungen umgesetzt wurden. Zu die- sem Zweck wird Tabelle 1 wiederholt und erweitert (vgl. Tabelle 18), wobei zu berücksichtigen ist, bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 87/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST)  dass bei der Erzeugung einer qualifizierten elektronischen Signatur SF1 für die Bildung des Hashwertes und SF5 für die Anzeige,  dass bei der Prüfung einer qualifizierten elektronischen Signatur SF3 für die Verifikation und SF5 für die entsprechende Anzeige,  dass bei der Statusprüfung eines qualifizierten Zertifikats SF6 für die ei- gentliche Validierung, SF4 für die Verifikation des OSCI-Laufzettels, SF7 für das Management des OSCI-Managers und SF5 für die entsprechende Anzeige und  dass zum Schutz vor unbefugter Veränderung SF8 benötigt werden. Tabelle 18: Umsetzung der SigG/SigV-Anforderungen durch Sicherheitsfunktionen Sicherheitsanforderungen an Si- gnaturanwendungskomponen- ten [BNetzA2005] Umsetzung der Anforderungen aus SigG und SigV in EVG Sicherheits- funktion „Erzeugung von Signaturen: Die Signaturanwendungskompo- nente muss beim Erzeugen ei- ner Signatur gewährleisten, dass zum Erzeugen wendet der OSCI-Client- Enabler auf die zu signierenden Daten eine Hashfunktion gemäß OSCI-Trans- port an und führt den erzeugten Hashwert der angeschlossenen sicheren Signatur- erstellungseinheit zu; eine erzeugte Sig- natur wird anschließend verifiziert SF1 SF2  das Erzeugen einer Signa- tur vorher eindeutig ange- zeigt wird, der OSCI-Client-Enabler unterstützt den Benutzer durch entsprechende Anzeigen SF5  erkennbar ist, auf welche Daten sich die Signatur bezieht, wird im OSCI-Client-Enabler angezeigt SF5  bei Bedarf der Inhalt der zu signierenden Daten hin- reichend zu erkennen ist, kann im OSCI-Client-Enabler angezeigt werden SF5  eine Signatur nur durch die berechtigt signierende Person erfolgt, -  die Identifikationsdaten nicht preisgegeben und nur auf der jeweiligen „si- cheren Signaturerstel- lungseinheit“ gespeichert werden. - bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 88/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Sicherheitsanforderungen an Si- gnaturanwendungskomponen- ten [BNetzA2005] Umsetzung der Anforderungen aus SigG und SigV in EVG Sicherheits- funktion „Erzeugung von Signaturen: Die Signaturanwendungskompo- nente muss beim Erzeugen ei- ner Signatur gewährleisten, dass zum Erzeugen wendet der OSCI-Client- Enabler auf die zu signierenden Daten eine Hashfunktion gemäß OSCI-Trans- port an und führt den erzeugten Hashwert der angeschlossenen sicheren Signatur- erstellungseinheit zu; eine erzeugte Sig- natur wird anschließend verifiziert SF1 SF2 Prüfung einer Signatur: Die Sig- naturanwendungskomponente muss beim Prüfen einer Signa- tur gewährleisten, dass OSCI-Client-Enabler und OSCI-Backend- Enabler prüfen qualifizierte elektronische Signaturen. Teilfunktionalitäten der Validierung erfol- gen beim OSCI-Manager; Plausibilitäts- prüfung bei OSCI-Client-Enabler und OSCI-Backend-Enabler; SF3 SF6, SF4, SF7  erkennbar wird, auf welche Daten sich die Signatur bezieht, wird vom OSCI-Client-Enabler angezeigt SF5  erkennbar wird, ob die Da- ten unverändert sind, wird vom OSCI-Client-Enabler geleistet SF5  bei Bedarf der Inhalt der signierten Daten hinrei- chend zu erkennen ist, kann vom OSCI-Client-Enabler angezeigt werden SF5  erkennbar wird, welchem Signaturschlüssel-Inhaber die Signatur zuzuordnen ist, wird vom OSCI-Client-Enabler an- gezeigt SF5  erkennbar wird, welche In- halte das qualifizierte Zerti- fikat, auf dem die Signatur beruht, und zugehörige qualifizierte Attribut-Zertifi- kate aufweisen, wird vom OSCI-Client-Enabler an- gezeigt, allerdings werden keine Attribut-Zertifikate unterstützt SF5  erkennbar wird, ob die nachgeprüften qualifizier- ten Zertifikate im jeweili- gen Zertifikatverzeichnis zum angegebenen Zeit- punkt vorhanden und nicht gesperrt waren, wird vom OSCI-Client-Enabler angezeigt, wobei der im OSCI-Laufzettel angegebe- ne Zeitpunkt der Zeitpunkt ist, zu dem die Nachricht beim OSCI-Manager angekom- men ist SF5 bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 89/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Sicherheitsanforderungen an Si- gnaturanwendungskomponen- ten [BNetzA2005] Umsetzung der Anforderungen aus SigG und SigV in EVG Sicherheits- funktion „Erzeugung von Signaturen: Die Signaturanwendungskompo- nente muss beim Erzeugen ei- ner Signatur gewährleisten, dass zum Erzeugen wendet der OSCI-Client- Enabler auf die zu signierenden Daten eine Hashfunktion gemäß OSCI-Trans- port an und führt den erzeugten Hashwert der angeschlossenen sicheren Signatur- erstellungseinheit zu; eine erzeugte Sig- natur wird anschließend verifiziert SF1 SF2  die Korrektheit der Signa- tur zuverlässig geprüft und zutreffend angezeigt wird. führen OSCI-Client-Enabler und - Backend-Enabler durch SF3 SF5 Schutz vor unbefugter Verände- rung: Sicherheitstechnische Veränderungen an der Signatur- anwendungskomponente müs- sen für den Nutzer erkennbar werden.” Prüftool für den OSCI-Client-Ena- bler zum Schutz vor unbefugter Veränderung wird zur Verfügung gestellt SF8 8.4.5 Erklärung zu den Maßnahmen der Vertrauenswürdigkeit 203 Die Maßnahmen zur Erfüllung der Vertrauenswürdigkeitsstufe EAL3+ werden wie folgt erfüllt (vgl. Tabelle 19): Tabelle 19: Erklärung der Maßnahmen zur Erfüllung von EAL3+ Anforderungen ge- mäß EAL3+ Maßnahmen der Entwickler Konfigurations- management :  ACM_CAP. 3  ACM_SCP. 1 Ein Qualitätssicherungssystem mit Konfigurationskontrolle unterstützt den Entwickler bei der Entwicklung des EVG. Alle der Konfigurationskontrolle unterliegenden Objekte werden ein- deutig identifiziert. Es stellt sicher, dass Unbefugte keine Modifikatio- nen vornehmen. Das Konfigurationskontrollsystem ermöglicht eine Historie von Imple- mentierung, Design, Tests und Dokumentation. Auslieferung und Betrieb:  ADO_DEL. 2  ADO_IGS. 1 Es werden Maßnahmen zur Umsetzung der Anforderungen hinsicht- lich der Auslieferungsprozeduren sowie Installations-, Generierungs- und Anlaufprozeduren dokumentiert. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 90/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Anforderungen ge- mäß EAL3+ Maßnahmen der Entwickler Entwicklung:  ADV_FSP. 1  ADV_HLD. 2  ADV_IMP.1  ADV_LLD. 1  ADV_RCR. 1 Entwicklungsprozeduren und Dokumentation erfolgen in einer Weise, so dass sie den Anforderungen der CC genügen. Handbücher:  AGD_ADM. 1  AGD_USR. 1 Systemverwalter- und Benutzerhandbuch werden erstellt und mit dem EVG ausgeliefert. Lebenszyklus-Un- terstützung:  ALC_DVS. 1  ALC_TAT.1 Der Entwicklungsprozess ist durch physikalische, personelle und or- ganisatorische Sicherheitsmaßnahmen gewährleistet. Für die Entwicklung des EVG werden festgelegte Entwicklungswerk- zeuge genutzt. Testen:  ATE_COV. 2  ATE_DPT. 1  ATE_FUN. 1  ATE_IND.2 Der Entwickler verwendet ein werkzeugbasiertes und automatisiertes Testsystem. Damit können  Tests der Sicherheitsfunktionen,  Tests auf Subsystem-Ebene und  Tests der funktionalen Spezifikation durchgeführt und die Ergebnisse dokumentiert werden. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 91/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Anforderungen ge- mäß EAL3+ Maßnahmen der Entwickler Schwachstellen- bewertung:  AVA_MSU. 3  AVA_SOF. 1  AVA_VLA. 4 Basierend auf den Handbüchern werden Missbrauchsanalysen er- stellt. Für die sicherheitsrelevanten Mechanismen wird eine Analyse in Be- zug auf die Mechanismenstärke „hoch“ durchgeführt und dokumen- tiert. Es wird eine Schwachstellenanalyse für alle Schwachstellen des EVG durchgeführt. 9 Definition der Familie FDP_SVR57 204 Um die funktionalen IT-Sicherheitsanforderungen an den EVG zu definieren wird hier eine zusätzliche Familie (FDP_SVR) der Klasse FDP (Schutz der Benutzerdaten) definiert. Diese Familie beschreibt die funktionalen Anforde- rungen an eine sichere Anzeige im Umfeld elektronischer Signaturen. 205 FDP_SVR Sichere Anzeige 206 Familienverhalten Diese Familie definiert Anforderungen an eine sichere Anzeige im Umfeld elektronischer Signaturen. In diesem Umfeld ist es erforder- lich, dass der Benutzer den Inhalt des zu unterschreibenden Doku- mentes eindeutig, ohne verdeckte bzw. aktive Inhalte informiert wird. Der Benutzer muss auf die nicht darstellbaren Inhalte hingewiesen werden. 207 Komponentenabstufung FDP_SVR Sichere Anzeige --- 1 FDP_SVR.1 Sichere Anzeige erfordert von den TSF die Fähigkeit zu einer eindeutigen Anzeige der Inhalte, die frei von verdeckten oder aktiven Inhalten ist, und zur Information des Benutzers über nicht dar- stellbare Inhalte. 208 Management: FDP_SVR.1 Für diese Komponente sind keine Management-Aktivitäten vorgesehen. 209 Protokollierung: FDP_SVR.1 Es sind keine Ereignisse identifiziert, die protokollierbar sein sollen, wenn FAU_GEN Generierung der Sicherheitsprotokolldaten Bestand- teil des PP/ der ST ist. 210 FDP_SVR.1 Sichere Anzeige 57 aus [SignCubes] bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 92/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) 211 Ist hierarchisch zu: Keinen anderen Komponenten 212 FDP_SVR.1.1 Die TSF müssen sicherstellen, dass der dem Benutzer angezeigte Inhalt eines Dokumentes entsprechend den folgenden Normen [Zuweisung: Normen für die Darstellung eines Inhalts] eindeutig ist. 213 FDP_SVR.1.2 Die TSF müssen sicherstellen, dass der dem Benutzer anzuzeigende Inhalt eines Dokumentes frei von aktiven oder verdeckten In- halten ist. Die TSF müssen sicherstellen, dass der Benutzer darüber infor- miert wird. 214 FDP_SVR.1.3 Die TSF müssen sicherstellen, dass der Benutzer über einen nicht darstellbaren Inhalt eines anzuzeigenden Dokumentes informiert wird. 215 Abhängigkeiten: Keine Abhängigkeiten 10 Glossar Basiskomponente Basiskomponente der Virtuellen Poststelle des Bundes mit Kernsystem, OCSP/CRL-Relay und NetSigner (vgl. [bos_Ba- sis_ST]).10 Chipkarte gemeint ist stets eine SigG-konforme Chipkarte CRL Certificate Revocation List (Sperrliste) [CRL] GUI Graphical User Interface LDAP Lightweight Directory Access Protocol [LDAP] Objekt „Eine Einheit im TSC, die Informationen enthält oder empfängt und auf der Subjekte Operationen ausführen.“ [CC- Teil1] OCSP Online Certificate Status Protocol (Protokoll zur Zertifikats- status-Anfrage) [OCSP] OperationId Identifier für auszuführende Operationen Prüfzeitpunkt Als Prüfzeitpunkt wird der Zeitpunkt bezeichnet, an dem die aktuelle Prüfung durchgeführt wird. Die Unterscheidung zum Signaturzeitpunkt ist insbesondere von Bedeutung, weil im Laufe der Zeit die Sicherheit mathematischer Verfahren als unzureichend bewertet werden kann. Wenn der Prüfende sich über den Signaturzeitpunkt nicht sicher sein kann, kann er hilfsweise den Prüfzeitpunkt [...] als Signaturzeitpunkt anneh- men. ([BSI_SigI_A6]) SAK Signaturanwendungskomponente SFP funktionale Sicherheitspolitik Sicherheitsattribut „Informationen, die mit Subjekten, Benutzern und/oder Objek- ten verknüpft sind und die zur Durchsetzung der TSP benötigt werden.“ [CC-Teil1] bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 93/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) Signaturkarte sichere Signaturerstellungseinheit (Die sichere Signaturerstel- lungseinheit gemäß SigG/SigV wird in diesem Kontext aus- schließlich über eine Chipkarte, also eine Signaturkarte, reali- siert. Die Begriffe werden synonym genutzt.) Signaturzeitpunkt Als Signaturzeitpunkt wird ein angenommener Erzeugungs- zeitpunkt einer digitalen Signatur bezeichnet. Der Zeitpunkt, zu dem die Signatur tatsächlich erzeugt wurde wird als objek- tiver Signaturzeitpunkt bezeichnet. Dieser Zeitpunkt kann von Dritten häufig nur schwer festgestellt werden. Der objektive Si- gnaturzeitpunkt kann nur unter bestimmten Bedingungen und nur im Rahmen der technisch realisierbaren Genauigkeit durch Dritte beweissicher nachvollzogen werden, z. B. mit ei- ner unmittelbar auf die Signaturerzeugung folgenden Zeit- stempelerzeugung. Prüfende müssen in der Regel Annahmen zum Signaturzeitpunkt treffen (deshalb angenommener Erzeu- gungszeitpunkt). Vom Signaturzeitpunkt zu unterscheiden ist der Prüfzeitpunkt. ([BSI_SigI_A6]) Subjekt ”Eine Einheit innerhalb des TSC, die die Ausführung von Operationen bewirkt.” [CC-Teil1] SystemId Identifier für anforderndes System, d. h. OSCI-Manager ge- genüber Basiskomponente (System-)Zertifikat Ein (System-)Zertifikat ist ein X.509-Zertifikat, das für die si- chere Kommunikation innerhalb des EVG genutzt wird. Ein (System-)Zertifikat wird als ein Trust Anchor (Sicherheits- anker) genutzt, d. h. als ein vertrauenswürdiges Zertifikat auf- gefasst, dem „vertraut“ wird und dessen Korrektheit nicht wei- ter geprüft zu werden braucht oder kann (etwa bei einem Selbstzertifikat). TSC Anwendungsbereich der TSF-Kontrolle (TSF Scope of Con- trol): Die Menge der Interaktionen, die mit oder innerhalb ei- nes EVG vorkommen können, werden als Anwendungsbe- reich der TSF-Kontrolle (TSC) bezeichnet. Der TSC umfasst eine definierte Menge von Interaktionen, basierend auf Sub- jekten, Objekten und Operationen innerhalb des EVG; er muss aber nicht alle Betriebsmittel eines EVG einschließen. TSF TOE Security Function (EVG-Sicherheitsfunktionen): „Eine Menge, die die gesamte Hardware, Software, und Firmware des TOE (EVG) umfasst, auf die Verlaß sein muss, um die TSP korrekt zu erfüllen.“ [CC-Teil1] TSP EVG-Sicherheitspolitik (TOE security policy, TSP) – „Eine Menge von Regeln, die angibt, wie innerhalb eines TOE (EVG) Werte verwaltet, geschützt und verteilt werden.“ [CC- Teil1] bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 94/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) 11 Literatur [AIS27] Bundesamt für Sicherheit in der Informationstechnik (BSI), „Application Notes and Interpretations of the Scheme (AIS), AIS 27, Version 1/20050204“, Entwurf vom 04.02.2005. [BNetzA2005] Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (Bundesnetzagentur), „Einheitliche Spezifizierung der Einsatzkomponenten für Signaturanwen- dungskomponenten – Arbeitsgrundlage für Entwickler/Herstel- ler und Prüf-/Bestätigungsstellen“, Version 1.4, 19.07.2005. [BNetzA_Algo2005] Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (Bundesnetzagentur), vormals Regu- lierungsbehörde für Telekommunikation und Post, „Bekannt- machung zur elektronischen Signatur nach dem Signaturge- setz und der Signaturverordnung (Übersicht über geeignete Algorithmen)“, 2. Januar 2005. [BNetzA_FAQ18] Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (Bundesnetzagentur), „FAQ, Frage 18“, www.bundesnetzagentur.de. [bos_Basis_ST] bremen online services GmbH & Co. KG, „Virtuelle Poststelle des Bundes, Version 2.2.x.x (Basis), Sicherheitsvorgaben (ST)“, 2006. [BSI] Bundesamt für Sicherheit in der Informationstechnik (BSI). [BSI_SigI_A6] Bundesamt für Sicherheit in der Informationstechnik, „Spezifi- kation zur Entwicklung interoperabler Verfahren und Kompo- nenten nach SigG/SigV, Signatur-Interoperabilitäts- spezifikation SigI, Abschnitt A6 Gültigkeitsmodell“, Version 1.1A, 17. Juni 1999. [BSI-VPS_Präsentat] Bundesamt für Sicherheit in der Informationstechnik, BundOn- line 2005, „Die Virtuelle Poststelle als BundOnline 2005 Basis- komponente ‚Datensicherheit’ – Informationen zu Konzept und Realisierung“, Februar 2004. Verfügbar unter http://www.bsi.bund.de/fachthem/egov/download/6_VPS_Info folien.pdf [CC-Teil2] „Common Criteria – Gemeinsame Kriterien für die Prüfung und Bewertung der Sicherheit von Informationstechnik, Teil 2: Funktionale Sicherheitsanforderungen“, Version 2.1, August 1999. [CC-Teil3] „Common Criteria – Gemeinsame Kriterien für die Prüfung und Bewertung der Sicherheit von Informationstechnik, Teil 3: Anforderungen an die Vertrauenswürdigkeit“, Version 2.1, Au- gust 1999. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 95/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) [CEM] „Common Criteria – Common Methodology for Information Technology Security Evaluation, CEM-2001/0015R, Part 2: Evaluation Methodology“, Version 1.1, Februar 2002. [CRL] Network Working Group: „Internet X.509 Public Key In- frastructure – Certificate and CRL Profile. Request for Com- ments 2459“, Januar 1999. [Fachkonzept_v2.3.1] Bundesamt für Sicherheit in der Informationstechnik, BSI, und IBM Deutschland GmbH, IBM Global Services, „Fachkonzept für die Virtuelle Poststelle als Basiskomponente Datensicher- heit von BundOnline 2005“, Version 2.3.1, 30.05.2003. [ISIS-MTT] Common ISIS-MTT Specifications for Interoperable PKI Appli- cations from T7 & TeleTrusT: “Specification”, Version 1.1, 16. März 2004. [ISIS-MTT_SigG] Common ISIS-MTT Specifications for Interoperable PKI Appli- cations from T7 & TeleTrusT: “Specification – Optional Profile – SigG-Profile”, Version 1.1, 16. März 2004. [LDAP] Network Working Group: „Internet X.509 Public Key In- frastructure – Operational Protocols – LDAPv2. Request for Comments 2559“, April 1999. [OCSP] Network Working Group: „Internet X.509 Public Key In- frastructure – Online Certificate Status Protocol – OCSP. Re- quest for Comments 2560“, Juni 1999. [OSCI] Online Services Computer Interface (OSCI), www.osci.de. [OSCI-Transport] OSC Leitstelle, „OSCI-Transport 1.2”, 06.06.2002. [PKCS#1] RSA, „PKCS #1 v2.1: RSA Cryptographic Standard“, 14.6.2002. [RSA] R. Rivest, A. Shamir, L. Adleman: A method for obtaining dig- ital signatures and public key cryptosystems, Communications of the ACM, vol. 21 no. 2, 1978. [SHA-1] National Institute of Standards and Technology (NIST): FIPS Publication 180-2: Secure Hash Standard (SHS), August 2002 und Change Notice 1, Februar 2004. [SigG] Gesetz über Rahmenbedingungen für elektronische Signatu- ren (Signaturgesetz – SigG), 16. Mai 2001. [SignCubes] OPENLiMiT SignCubes 1.6, „Sicherheitsvorgaben (ST)“, Ver- sion 1.0, 20.7.2004. [SigV] Verordnung zur elektronischen Signatur (Signaturverordnung – SigV), 16. November 2001. [SigV_Begr] Begründung zum Entwurf einer Verordnung zur elektroni- schen Signatur in der Fassung des Kabinettbeschlusses vom 24.10.2001. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 96/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) [VPS-SiKo] BundOnline 2005, Bundesamt für Sicherheit in der Informati- onstechnik, bremen online services GmbH & Co. KG, daten- schutz nord GmbH, „Generisches Sicherheitskonzept für die Kern- und Webkomponenten der Virtuellen Poststelle“, 2004.58 12 Anhang: Technische Einsatzumgebung 216 Neben der in Tabelle 2 aufgeführten Software werden für den Betrieb des EVG folgende Komponenten benötigt, die somit die technische Einsatzumge- bung definieren. 12.1 Hard- und Software 217 Hinsichtlich der Serverkomponenten für OSCI-Manager und -Backend-Enab- ler werden folgende Systemumgebungen unterstützt:  Hardware: o 2 GHz i386 (Intel Xeon o.ä) Prozessor mit 2 GB RAM und 40 GB Harddisk; o Sun Sparc mit 300 MHz-Prozessor mit mindestens 2 GB RAM und 20 GB Harddisk;  Betriebssysteme: o Linux (SuSE Linux Enterprise Server 9); o Windows 2003 Server; o Solaris 9;  Java: SUN 1.4.2_04;  Application Server: JBoss 3.2.5 inkl. Tomcat 5.0.26;  Datenbank: MySQL 4.1. 218 Hinsichtlich der Clientkomponenten für OSCI-Client-Enabler werden folgende Systemumgebungen unterstützt:  Hardware: o 1 GHz i386 (Intel Xeon o.ä) Prozessor mit 256 MB RAM und 20 GB Harddisk;  Betriebssysteme: o Linux (SuSE Linux Professional 9.x); o Windows 2000; o Windows XP; 58 Das generische Sicherheitskonzept für die Kern- und Webkomponenten der Virtuellen Poststelle ist u.a. auf der E-Government-Seite des Bundesamtes für Sicherheit in der In- formationstechnik (BSI) unter www.bsi.bund.de/fachthem/egov/vps.htm verfügbar. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 97/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST)  Java: SUN 1.4.2_04. 12.2 Sichere Signaturerstellungseinheiten und Chipkartenleser 219 Folgende SigG-konforme sichere Signaturerstellungseinheit wird unterstützt:  DATEV Signaturkarte e:secure-Card, Version 1.2 (Nachtrag zur Bestäti- gung TUVIT.09341.TE.03.2001 vom 05.03.2001);  Telesec Signaturkarte PKS-Card, E4KeyCard, E4NetKeyCard, Version 3.0 (TUVIT.09339.TE.12.2000 vom 15.12.2000);  Signaturkarte D-TRUST-CARD, Nachfolge-Varianten D-TRUST Card Version 1.1, (Nachtrag zur Bestätigung TUVIT.09361.TE.10.2001 vom 23.10.2001)59 ;  Signtrust Signaturkarte SEA-Card, Version 2.0 (TUVIT.09346.TU.03.2001 vom 23.03.2001);  STARCOS SPK2.3 with Digital Signature Application StarCert (limited signature generation configuration), TC-TrustCenter AG (debi- sZERT.02036.TE.03.2001);  Signaturerstellungseinheit ZKA Banking Signature Card, Version 6.2b NP & 6.2f NP, Type 3, Giesecke & Devrient GmbH (TÜVIT. 09395.TU.01.2005);  ZKA-Signaturkarte, Version 5.02, Gemplus-mids GmbH (TÜVIT.09385. TU.09.2005). 220 Folgende SigG-konformen Chipkartenleser werden unterstützt:  KOBIL Systems GmbH, KAAN Professional (TUVIT.09331.TE.03.2002), nur RS232-Version;  Reiner SCT Kartengeräte GmbH & Co. KG, cyberJack e-com, Version 2.0 (TÜVIT.09363.TE.06.2002), nur USB und Windows;  Reiner SCT Kartengeräte GmbH & Co. KG, cyberJack pinpad, Version 2.0 (TÜVIT.09362.TE.05.2002), nur USB und Windows. 12.3 Zertifikate und private Schlüssel 221 Folgende X.509v3-Zertifikate werden unterstützt:  SigG-konforme qualifizierte Zertifikate;  (System-)Zertifikate zur Gewährleistung der Systemsicherheit. 222 Darüber hinaus werden private Schlüssel zur Gewährleistung der Systemsi- cherheit unterstützt. 59 Die Kombination D-Trust Signaturkarte mit dem Kobil KAAN Professional wird in dieser Kombination aus technischen Gründen nicht betrachtet. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 98/99 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) 12.4 Anfordernde Systeme 223 OSCI-Client und -Backend, die auf den EVG – d. h. auf OSCI-Client-Enabler bzw. -Backend-Enabler – zugreifen, welche die Funktionalitäten des EVG nutzen und die Anforderungen des Signaturgesetzes an eine Signaturanwen- dungskomponente erfüllen. bremen online services GmbH & Co. KG 11.03.2008 datenschutz nord GmbH 99/99