Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG datenschutz nord GmbH Version 1.0 19.11.2007 Zertifizierungs-ID: BSI-DSZ-CC-0330 Bestätigungs-ID: BSI.02069.TE.xx.2006 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 2/98 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- Manager 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 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) Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 3/98 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...............................................................................................14 2.4 Technische Realisierung ............................................................................17 2.5 Signaturgesetz (SigG) und -verordnung (SigV)..........................................21 2.5.1 Rechtliche Grundlagen ...........................................................................21 2.5.2 Signaturgesetz-Anforderungen an den EVG..........................................24 2.6 Produktbestandteile und EVG-Abgrenzung ...............................................29 2.7 Absicherung ................................................................................................31 2.8 Auslieferung ................................................................................................32 3 EVG-Sicherheitsumgebung..................................................................................34 3.1 Rollen..........................................................................................................34 3.2 Annahmen...................................................................................................35 3.3 Bedrohungen ..............................................................................................39 3.4 Organisatorische Sicherheitspolitiken ........................................................40 4 Sicherheitsziele ....................................................................................................41 4.1 EVG-Sicherheitsziele..................................................................................41 4.2 Sicherheitsziele für die Umgebung.............................................................43 5 IT-Sicherheitsanforderungen................................................................................48 5.1 EVG-Sicherheitsanforderungen..................................................................48 5.1.1 Definition der funktionalen Sicherheitspolitik (SFP) ...............................48 5.1.2 Funktionale EVG-Sicherheitsanforderungen..........................................49 5.1.3 Anforderungen an die Vertrauenswürdigkeit des EVG ..........................58 5.2 Sicherheitsanforderungen an die IT-Umgebung ........................................59 5.3 Sicherheitsanforderungen an die Nicht-IT-Umgebung...............................62 6 EVG-Übersichtsspezifikation................................................................................63 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 4/98 6.1 SF1 – Unterstützung bei der Erzeugung qualifizierter elektronischer Signaturen................................................................................................................63 6.2 SF2 – Schutz gegen Hashwertmanipulation ..............................................63 6.3 SF3 – Verifikation einer qualifizierten elektronischen Signatur..................64 6.4 SF4 – Verifikation eines OSCI-Laufzettels bei der Validierung eines qualifizierten Zertifikats............................................................................................64 6.5 SF5 – Sichere und zuverlässige Anzeige...................................................65 6.6 SF6 – Unterstützung bei der Validierung qualifizierter Zertifikate..............65 6.7 SF7 – Identifikation und Authentisierung....................................................66 6.8 SF8 – Prüftool .............................................................................................67 6.9 Maßnahmen zur Vertrauenswürdigkeit.......................................................67 7 PP-Postulate ........................................................................................................68 8 Erklärungen..........................................................................................................68 8.1 Erklärung der organisatorischen Sicherheitspolitiken ................................68 8.2 Erklärung der Sicherheitsziele....................................................................70 8.3 Erklärung der Sicherheitsanforderungen....................................................73 8.3.1 Erklärung zu den funktionalen Sicherheitsanforderungen .....................73 8.3.2 Erfüllung der Abhängigkeiten .................................................................78 8.3.3 Analyse des Zusammenwirkens der funktionalen Anforderungen.........81 8.3.4 Analyse der Mindest-Stärkestufe............................................................81 8.3.5 Erklärung zu den Anforderungen an die Vertrauenswürdigkeit .............82 8.4 Erklärung der EVG-Übersichtsspezifikation ...............................................82 8.4.1 Erfüllung der funktionalen Sicherheitsanforderungen............................82 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- Anforderungen......................................................................................................87 8.4.5 Erklärung zu den Maßnahmen der Vertrauenswürdigkeit......................89 9 Definition der Familie FDP_SVR..........................................................................91 10 Glossar............................................................................................................92 11 Literatur ...........................................................................................................94 12 Anhang: Technische Einsatzumgebung .........................................................96 12.1 Hard- und Software.....................................................................................96 12.2 Sichere Signaturerstellungseinheiten und Chipkartenleser .......................97 12.3 Zertifikate und private Schlüssel.................................................................97 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 5/98 12.4 Anfordernde Systeme .................................................................................98 Abbildungsverzeichnis Abbildung 1: Aufbau der Virtuellen Poststelle des Bundes...........................................7 Abbildung 2: EVG-Übersicht .......................................................................................12 Abbildung 3: Teilsysteme des EVG.............................................................................18 Tabellenverzeichnis Tabelle 1: Umsetzung der SigG/SigV-Anforderungen ................................................26 Tabelle 2: Lieferumfang EVG......................................................................................29 Tabelle 3: Funktionale Sicherheitsanforderungen an den EVG..................................49 Tabelle 4: Vertrauenswürdigkeitskomponenten..........................................................59 Tabelle 5: Funktionale Sicherheitsanforderungen an die IT-Umgebung ....................59 Tabelle 6: Maßnahmen zur Erfüllung von EAL3+.......................................................67 Tabelle 7: Zuordnung Sicherheitsumgebung zu -zielen .............................................72 Tabelle 8: Zuordnung Sicherheitsziele zu -umgebung................................................73 Tabelle 9: Zuordnung Sicherheitsziele zu Sicherheitsanforderungen an den EVG ...76 Tabelle 10: Zuordung fkt. Sicherheitsanforderungen zu Sicherheitszielen ................76 Tabelle 11: Zuordnung Sicherheitsziele zu Sicherheitsanforderungen an die IT- Umgebung............................................................................................................77 Tabelle 12: Zuordung fkt. Sicherheitsanforderungen an die IT-Umgebung zu Sicherheitszielen ..................................................................................................77 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..84 Tabelle 16: Zuordnung von Sicherheitsfunktionen zu Teilsystemen ..........................85 Tabelle 17: Zusammenwirken der Sicherheitsfunktionen...........................................87 Tabelle 18: Umsetzung der SigG/SigV-Anforderungen durch Sicherheitsfunktionen87 Tabelle 19: Erklärung der Maßnahmen zur Erfüllung von EAL3+ ..............................90 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 6/98 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.0 3 Datum: 20.11.2007 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.2.6 7 CC-Version: 2.11 8 Zertifizierungs-ID: BSI-DSZ-CC-0330 9 Bestätigungs-ID: BSI.02069.TE.xx.2006 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 ex- ternen Kommunikationspartnern (Bürger, Wirtschaft und andere Behörden) bereit. 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; 1 Dieses Dokument berücksichtigt die neue deutsche Rechtschreibung und passt die den CC entnommenen Texte teilweise an. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 7/98  Einbindung interner und externer Verzeichnisdienste;  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. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 8/98 13 Die Evaluierung der Virtuellen Poststelle des Bundes wird im Rahmen einer kompositiven Evaluierung durchgeführt, in der die VPS in drei logische Ein- 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 (Verifika- tion);  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: 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) unter www.bundesnetzagentur.de –- in Abgrenzung zu einer „vollständigen Signaturan- wendungskomponente“ – verwendet und in Funktionsbibliotheken und Chipkartenleser unterteilt. Die Funktionsbibliothek wird von Client- und Serversystemen genutzt. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 9/98  Teil 2 erweitert [CC-Teil2];  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 (abkürzend als EAL3+ bezeichnet). 20 Dabei wird die vom EVG zur Verfügung gestellte Sicherheitsfunktionalität sowohl 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 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“ [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; 3 Diese Vertrauenswürdigkeitskomponente wird durch die höherwertige Systemkompo- nente ADO_DEL.2 ersetzt, vgl. [AIS27]. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 10/98 o 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; 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 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. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 11/98 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. 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 Evaluationsge- genstand (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. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 12/98 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 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üsselung von Doku- menten, die Unterstützung des Signaturschlüssel-Inhabers beim Signie- ren von Daten, die Visualisierung von Inhaltsdaten 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. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 13/98 Absender- und Empfänger-Seite wird durch einen OSCI-Client bzw. OS- CI-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, ei- ne beweiskräftige Protokollierung des Nachrichtenweges oder die Zustel- lung 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:  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 Nut- zung von Signaturen und Verschlüsselungen. 31 OSCI bedient sich für die Darstellung digitaler Signaturen des XML- Signature-Standards7 . Darüber hinaus wurde für die flexible und performante Verarbeitung von Attachments die Realisierung als SOAP-Attachment ge- wählt. Das bedeutet im Wesentlichen, dass zum Anbringen von Signaturen 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]). 7 vgl. http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 14/98 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. 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) werden weitere Informationen vom OSCI-Client-Enabler dem Benutzer angezeigt – beispielsweise das zugehörige Zertifikat sowie Verifikations- und Validierung- sergebnisse. 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  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 (Verifika- tion);  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. 8 Nicht im Umfang der Evaluierung enthalten sind weitere unterstützte Datenformate. 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. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 15/98 36 Der EVG nutzt Funktionalitäten einer SigG-konformen Basiskomponente der Virtuellen Poststelle des Bundes mit Kernsystem, OCSP/CRL-Relay und NetSigner, die ebenfalls innerhalb der kompositiven Evaluierung der Virtuel- len Poststelle des Bundes evaluiert, zertifiziert und bestätigt wird. Funktionali- tä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. 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. [BNet- zA_FAQ18])) bereit, die auf Anforderung des Benutzers lokal erzeugt 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- 10 Darüber hinaus wird die Basiskomponente für die Gewährleistung der Systemsicher- heit genutzt (vgl. Abschnitt 2.4). Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 16/98 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 diesem Zeitpunkt bereits begonnen und noch nicht abgelaufen war, und übergibt das Ergebnis der Validierung in Form des Verzeichnisdienst- Ergebnisses sowie einer Interpretation (gültig und nicht gesperrt, unbe- kannt oder gesperrt) an den EVG.  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 kryp- tographischen Verfahren und liefert das Ergebnis (gültige oder ungültige Signatur oder Fehlermeldung) an das OSCI-Backend zurück.  Der EVG erhält von einem OSCI-Backend die Anforderung12 , eine Sta- tusprü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- 11 Für eine aktuelle Validierung sei auf EVG3 „Verifikationsmodul“ verwiesen. 12 Der EVG wird unter der Annahme betrieben, dass das OSCI-Backend, welches auf diesen EVG zugreift, eine Signaturanwendungskomponente gemäß SigG/SigV darstellt. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 17/98 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 Ergeb- nisse 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. Abbildung 3 illustriert die Teilsysteme der OSCI-Komponente. 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- Protokoll abgesichert. Das OSCI-Transport-Protokoll ist nicht Bestandteil der Evaluie- rung. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 18/98 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- 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. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 19/98 nische Signatur durch die Signaturkarte erzeugt wurde, wird die Signatur vom OSCI-Client-Enabler verifiziert; dazu wird das zum 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- Protokolls und zeigt das Verifikationsergebnis sowie die signierten Daten 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. 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 kryptographische Schlüssel und (System-)Zertifikate, die vom OSCI-Client zur Verfügung ge- stellt werden; eine geeignete Identifikation und Authentisierung zum Mana- gement 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. 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. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 20/98 Der OSCI-Manager interpretiert die Antwort der Basiskomponente und generiert ein eigenes Ergebnis ohne die Original-Verzeichnisdienst- Auskünfte der Basiskomponente, welches der OSCI-Manager im OSCI- Laufzettel ablegt. Der OSCI-Laufzettel wird zur Gewährleistung der Systemsicherheit mit einer elektronischen Signatur versehen: Dazu nutzt der OSCI-Manager unterstützende Sicherheitsmechanismen16 des Kernsystems der Basis- komponente, indem das Kernsystem für den vom OSCI-Manager erzeug- ten und übergebenen Hashwert eine elektronische Signatur erzeugt. Anschließend übergibt der OSCI-Manager im Rahmen des OSCI- Protokolls 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 e- lektronische 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äts- check).17 Der OSCI-Backend-Enabler übergibt das Validierung- sergebnis dem OSCI-Backend. Der OSCI-Backend-Enabler als Funktionsbibliothek nutzt kryptographische Schlüssel und (System-)Zertifikate, die vom OSCI-Backend zur Verfügung gestellt werden; eine geeignete Identifikation und Authentisierung zum Mana- gement dieser Sicherheitsattribute obliegt dem OSCI-Backend. 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 kryp- tographischen Verfahren wurde in [bos-Basis_ST] beschrieben. Im Rahmen der Evaluie- rung 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. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 21/98 49 Kommunikationssicherheit:  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 ei- ne 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- Backend und -Manager zusammen in einem vertrauenswürdigen Netz betrieben werden. 50 Das Prüftool zum Schutz vor unbefugter Veränderung ist in Abschnitt 2.7 beschrieben. 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 Signaturanwendungs- komponenten erforderlich, die die Erzeugung einer qualifizierten elektroni- schen Signatur vorher eindeutig anzeigen und feststellen lassen, auf welche Daten sich die Signatur bezieht. Für die Überprüfung signierter Daten sind Signaturanwendungskomponenten erforderlich, die feststellen lassen, 1. auf welche Daten sich die Signatur bezieht, 2. ob die signierten Daten unverändert sind, 18 Das OSCI-Transport-Protokoll ist nicht Bestandteil der Evaluierung. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 22/98 3. welchem Signaturschlüssel-Inhaber die Signatur zuzuordnen ist, 4. welche Inhalte das qualifizierte Zertifikat, auf dem die Signatur beruht, 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 Inhalt der zu signierenden oder signierten Daten hinreichend erkennen lassen. Die Sig- naturschlüssel-Inhaber sollen solche Signaturanwendungskomponenten ein- setzen oder andere geeignete Maßnahmen zur Sicherheit qualifizierter elekt- ronischer Signaturen treffen.“ 54 § 15 SigV „Anforderungen an Produkte für qualifizierte elektronische Signatu- ren“: „(2) Signaturanwendungskomponenten nach § 17 Abs. 2 des Signaturgeset- zes müssen gewährleisten, dass 1. bei der Erzeugung einer qualifizierten elektronischen Signatur a) die Identifikationsdaten nicht preisgegeben und diese nur auf der jewei- ligen sicheren Signaturerstellungseinheit gespeichert werden, b) eine Signatur nur durch die berechtigt signierende Person erfolgt, 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 zutreffend ange- zeigt wird und b) eindeutig erkennbar wird, ob die nachgeprüften qualifizierten Zertifikate im jeweiligen Zertifikat-Verzeichnis zum angegebenen Zeitpunkt vor- handen 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] Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 23/98  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 Signatur beruht, und zugehörige qualifizierte Attribut-Zertifikate aufwei- sen,  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 Signatur- schlüssels nicht eine andere Person eine Signatur auslösen kann, indem mittels Hacking oder eines trojanischen Pferdes ein elektronisches Dokument (= Hashwert) ‚unterge- schoben’ wird.“ [BNetzA2005] 23 „Dies erfordert einen gesicherten Übertragungsweg von der Eingabe der Identifikati- onsdaten 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 Aufbewahrung 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-/Reparaturpersonal wieder hergestellt werden kann.“ [BNetzA2005] Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 24/98 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 erfül- len: Vom Chipkartenleser und der sicheren Signaturerstellungseinheit muss gewährleistet werden, dass eine Signatur nur durch die berechtigt signieren- de Person erfolgt und dass Identifikationsdaten nicht preisgegeben und nur auf der jeweiligen sicheren Signaturerstellungseinheit abgespeichert werden. 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,“ Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 25/98  „erkennbar wird, welchem Signaturschlüssel-Inhaber die Signatur zuzu- ordnen ist“,  „erkennbar wird, welche Inhalte das qualifizierte Zertifikat, auf dem die Signatur 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. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 26/98 Tabelle 1: Umsetzung der SigG/SigV-Anforderungen Umsetzung der Anforderungen aus SigG und SigV Sicherheitsanforderungen an Signaturanwendungskomponen- ten [BNetzA2005] in EVG in der IT-Umgebung „Erzeugung von Signaturen: Die Signaturanwendungskomponen- te muss beim Erzeugen einer 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 angeschlossenen sicheren Signaturerstellungseinheit zu; eine erzeugte Signatur wird anschließend verifiziert qualifizierte elektronische Signatur wird durch sichere Signaturerstellungseinheit erstellt  das Erzeugen einer Signa- tur vorher eindeutig ange- zeigt wird,26 der OSCI-Client-Enabler unterstützt den Benutzer durch entsprechende An- zeigen -  erkennbar ist, auf welche Daten sich die Signatur be- zieht,27 wird im OSCI-Client-Enabler angezeigt -  bei Bedarf der Inhalt der zu signierenden Daten hinrei- chend zu erkennen ist,28 kann im OSCI-Client- Enabler angezeigt werden -  eine Signatur nur durch die berechtigt signierende Per- son 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 vorher 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 signierenden [...] 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] Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 27/98 Umsetzung der Anforderungen aus SigG und SigV Sicherheitsanforderungen an Signaturanwendungskomponen- ten [BNetzA2005] in EVG in der IT-Umgebung  die Identifikationsdaten nicht preisgegeben und nur auf der jeweiligen „sicheren Signaturerstellungseinheit“ gespeichert werden.30 - wird durch sichere Signatur- erstellungseinheit sowie Eingabe der PIN am PIN- Pad des Chipkartenlesers gewährleistet 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 elektro- nische Signaturen. Teilfunktionalitäten der Vali- dierung erfolgen beim OS- CI-Manager; Plausibilitäts- prüfung bei OSCI-Client- Enabler und OSCI- Backend-Enabler;  erkennbar wird, auf welche Daten sich die Signatur be- zieht,31 wird vom OSCI-Client- Enabler 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- Enabler geleistet -  bei Bedarf der Inhalt der signierten Daten hinrei- chend zu erkennen ist,33 kann vom OSCI-Client- Enabler angezeigt werden - 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] 31 vgl. „Für die Überprüfung signierter Daten sind Signaturanwendungskomponenten erforderlich, 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 erforderlich, die feststellen lassen, [...] ob die signierten Daten unverändert sind [...].“ [§17 Abs. 2 Nr.2 SigG] Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 28/98 Umsetzung der Anforderungen aus SigG und SigV Sicherheitsanforderungen an Signaturanwendungskomponen- ten [BNetzA2005] in EVG in der IT-Umgebung  erkennbar wird, welchem Signaturschlüssel-Inhaber die Signatur zuzuordnen ist,34 wird vom OSCI-Client- Enabler angezeigt -  erkennbar wird, welche In- halte das qualifizierte Zerti- fikat, auf dem die Signatur beruht, und zugehörige qualifizierte Attribut- Zertifikate25 aufweisen,35 wird vom OSCI-Client- Enabler angezeigt, aller- dings werden keine Attribut- Zertifikate unterstützt -  erkennbar wird, ob die nachgeprüften qualifizierten Zertifikate im jeweiligen Zertifikatverzeichnis zum angegebenen Zeitpunkt vorhanden und nicht ge- sperrt 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 - Backend-Enabler; die entsprechende Anzeige des Validierungsergebnis- ses erfolgt beim OSCI- Client-Enabler, wobei der im OSCI-Laufzettel angegebe- ne Zeitpunkt der Zeitpunkt ist, zu dem die Nachricht beim OSCI-Manager einge- gangen ist37 die eigentliche Statusprü- fung (Validierung) des Zerti- fikats erfolgt in der Basis- komponente 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 erforderlich, die feststellen lassen, [...] welchem Signaturschlüssel-Inhaber die Signatur zuzuordnen ist [...].“ [§17 Abs. 2 Nr.3 SigG] 35 vgl. „Für die Überprüfung signierter Daten sind Signaturanwendungskomponenten erforderlich, 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] 36 vgl. „Für die Überprüfung signierter Daten sind Signaturanwendungskomponenten erforderlich, die feststellen lassen, [...] zu welchem Ergebnis die Nachprüfung von Zertifi- katen nach § 5 Abs. 1 Satz 2 geführt hat. [...].“ [§17 Abs. 2 Nr. 5 SigG] sowie „Signatur- anwendungskomponenten nach § 17 Abs. 2 des Signaturgesetzes müssen gewährleis- Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 29/98 Umsetzung der Anforderungen aus SigG und SigV Sicherheitsanforderungen an Signaturanwendungskomponen- ten [BNetzA2005] in EVG in der IT-Umgebung  die Korrektheit der Signatur zuverlässig geprüft und zu- treffend angezeigt wird.38 führen OSCI-Client-Enabler und -Backend-Enabler durch - Schutz vor unbefugter Verände- rung: Sicherheitstechnische Veränderungen an der Signa- turanwendungskomponente müssen für den Nutzer erkenn- bar werden.” Prüftool für den OSCI- Client-Enabler zum Schutz vor unbefugter Veränderung wird zur Verfügung gestellt für die serverseitigen Kom- ponenten OSCI-Manager und -Backend-Enabler muss der sichere Betrieb in der Umgebung gewährleistet werden; für den OSCI-Client-Enabler ist muss der sichere Betrieb am Arbeitsplatz gewährleis- tet werden; zusätzliche Ab- sicherung zum Integritäts- schutz durch Prüftool 2.6 Produktbestandteile und EVG-Abgrenzung 66 Der Lieferumfang des EVG ist in Tabelle 2 aufgeführt: Tabelle 2: Lieferumfang EVG Liefergegenstand Typ Medium ten, dass [...] bei der Prüfung einer qualifizierten elektronischen Signatur [...] eindeutig erkennbar wird, ob die nachgeprüften qualifizierten Zertifikate im jeweiligen Zertifikat- Verzeichnis 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. 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] Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 30/98 Liefergegenstand Typ Medium 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 OSCI- Client- Enabler Entwicklerdokumentation, Version 2.2.x.x, Datum Doku- menta- tion CD- ROM oder Archiv- Datei Gov2OsciManager.ear, Version 2.2.x.x, Datum, Größe Gov2OsciServer.ear, Version 2.2.x.x, Datum, Größe Soft- ware OSCI- Mana- ger Betriebshandbuch, Version 2.2.x.x, Datum Doku- menta- tion CD- ROM oder Archiv- Datei 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 OSCI- Back- end- Enabler Betriebshandbuch, Version 2.2.x.x, Datum Entwicklerdokumentation, Version 2.2.x.x, Datum Doku- menta- tion CD- ROM oder Archiv- Datei Anwendung (genaue Bezeichnung, Version 2.2.x.x, Da- tum, Größe) Soft- ware Prüftool Anleitung zum Prüftool, Version 2.2.x.x, Datum Doku- menta- tion CD- ROM oder Archiv- Datei 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; Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 31/98  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- Enabler 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 OS- CI-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. 39 Sichere Signaturerstellungseinheiten gemäß SigG/SigV werden in diesem Kontext ausschließlich als Chipkarten, also Signaturkarten, realisiert, so dass die Begriffe syn- onym 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 orga- nisatorische Maßnahmen sichergestellt wird (vgl. A.ServerBetrieb). Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 32/98  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. 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 Ver- treiber (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. 41 Die Schlüssellänge richtet sich nach dem eingesetzten Zertifikat; Mindestlänge ist 1024 Bit. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 33/98 Der Betreiber erhält den EVG gemäß Auflistung in Tabelle 2 vom Vertrei- ber. Der Betreiber konfiguriert, installiert, administriert und betreibt OSCI- Manager und OSCI-Backend-Enabler. 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. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 34/98 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: 43 Der System-Administrator kann beispielsweise ein Administrator bei einem Dienst- leister sein, der die Systeme hostet. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 35/98 o Aufruf der Monitoring-Konsole zum Check des System-Status; 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 vorhanden. Eine Auflistung findet sich im Anhang in Abschnitt 12. 78 A.SAK OSCI-Client und -Backend, die auf den EVG – d. h. auf OS- CI-Client-Enabler bzw. -Backend-Enabler – zugreifen und die die Funktionalitäten des EVG nutzen, stehen zur Verfü- Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 36/98 gung. Die Anforderungen von Signaturgesetz und -ver- ordnung an eine Signaturanwendungskomponente werden beachtet. Insbesondere gewährleisten sie die Funktionalitä- ten hinsichtlich Identifikation und Authentisierung zum Ma- nagement von Sicherheitsattributen, d. h. den kryptographi- schen Schlüsseln und (System-)Zertifikaten. Durch den OSCI-Client bzw. -Backend ist gewährleistet, dass auf Anforderung des Benutzers resp. Security- Administrators angezeigt wird, welcher OSCI-Manager an- gesprochen 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 Gegebenheiten sowie Hard- und Software für den sicheren Betrieb der serverseitigen Komponenten des EVG (OSCI-Manager und -Backend-Enabler) sind vorhan- den. Es sind verschiedene Administratoren für die verschiedenen Aufgaben benannt, die einen Beitrag zur Sicherstellung einer vertraulichen und integren Betriebsumgebung des EVG leis- ten. Ein Vier-Augen-Prinzip mit Revisor ist für wichtige Aktivi- täten organisatorisch realisiert. Es wird gewährleistet, dass der EVG korrekt aufgebaut ist, inkl. Einhaltung der Vorgaben hinsichtlich der räumlichen Gegebenheiten und für die Realisierung der Netzwerkarchi- tektur und der internen Verbindungen zwischen den einzel- nen Systemkomponenten mit Firewall, Demilitarisierter Zone (DMZ) etc. Vgl. dazu die Vorgaben und Auflagen zum Be- trieb der Virtuellen Poststelle, die im „Generischen Sicher- heitskonzept für die Kern- und Webkomponenten der Virtuel- len Poststelle“ beschrieben werden [VPS-SiKo]. OSCI-Manager und Kernsystem der Basiskomponente ([bos_Basis_ST]) werden zusammen innerhalb eines ver- trauenswürdigen Netzes betrieben. Der OSCI-Backend-Enabler als Funktionsbibliothek nutzt kryptographische Schlüssel und (System-)Zertifikate, die vom OSCI-Backend zur Verfügung gestellt werden; eine ge- eignete Identifikation und Authentisierung zum Management dieser Sicherheitsattribute wird vom OSCI-Backend sicher- gestellt. Die Anforderungen aus [BNetzA2005] an einen „geschützten Einsatzbereich (Regelfall/Standardlösung)“ werden umge- setzt, um „potentielle Angriffen über das Internet, ein ange- schlossenes Intranet, einen manuellen Zugriff Unbefugter und einen Datenaustausch per Datenträger [...] durch eine Kombination von Sicherheitsvorkehrungen in der Signatur- Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 37/98 anwendungskomponente selbst und der Einsatzumgebung mit hoher Sicherheit“ hinsichtlich eines hohen Angriffspoten- tials 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 ange- nommen, dass die folgenden baulichen, personellen und organisatorischen 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 ihres Identifikationsmerkmals nicht beo- bachtet werden, oder ihr Identifikationsmerkmal ä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 Betrieb der Virtuellen Poststelle, die im „Generischen Sicherheitskonzept für die Kern- und Web- komponenten der Virtuellen Poststelle“ beschrieben werden [VPS-SiKo]. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 38/98 Der OSCI-Client-Enabler als Funktionsbibliothek nutzt kryp- tographische Schlüssel und (System-)Zertifikate, die vom OSCI-Client zur Verfügung gestellt werden; eine geeignete Identifikation und Authentisierung 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 integritätsgeschützten Software sind oder dass diese Konfigurationsdaten – ähnlich wie bei EVG3 – gesondert abgesichert werden. Die Anforderungen aus [BNetzA2005] an einen „geschützten Einsatzbereich (Regelfall/Standardlösung)“ werden umge- setzt, um „potentielle Angriffen über das Internet, ein ange- schlossenes Intranet, einen manuellen Zugriff Unbefugter und einen Datenaustausch per Datenträger [...] durch eine Kombination von Sicherheitsvorkehrungen in der Signatur- anwendungskomponente selbst und der Einsatzumgebung mit hoher Sicherheit“ hinsichtlich eines hohen Angriffspoten- tials 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- 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, 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 ange- nommen, dass die folgenden baulichen, personellen und organisatorischen Anforderungen umgesetzt sind: 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- Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 39/98 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 Bildschirmes oder Verschließen des Büros bei Abwesenheit. 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ährleis- tet, dass die Identifikationsdaten nicht preisgegeben und nur auf der jeweiligen sicheren Signaturerstellungseinheit ge- speichert 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 hohes Angriffspotenzial aufwei- sen und über Fachkenntnisse verfügen. 83 TE.SpähePIN Eine nicht autorisierte Person könnte versuchen, das Identi- fikationsmerkmal auszuspähen. Die nicht autorisierte Person kann ein hohes Angriffspotenzial aufweisen und über Fach- kenntnisse verfügen. 84 Weitere Bedrohungen ergeben sich implizit durch Nennung organisatorischer Sicherheitspolitiken. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 40/98 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 Hashfunktion gemäß OSCI-Transport (vgl. Ab- schnitt 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 jeweiligen Zertifikatverzeichnis zum angegebe- nen 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 sicherheitstechni- sche Veränderungen festgestellt werden können. 44 Die für den EVG relevanten organisatorischen Sicherheitspolitiken ergeben sich aus den Anforderungen von Signaturgesetz und -verordnung (vgl. Abschnitt 2.5). Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 41/98 Erklärung 1 Die 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). 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 signie- renden Daten eine Hashfunktion gemäß OSCI-Transport (vgl. Abschnitt 2.2) anwenden, den erzeugten Hashwert ei- ner angeschlossenen sicheren Signaturerstellungseinheit zuführen, wo die qualifizierte elektronische Signatur erzeugt wird, und anschließend durch Verifikation der zuvor erzeug- ten Signatur mit dem auf der sicheren Signaturerstellungs- einheit befindlichen Zertifikat prüfen, ob für die korrekten zu signierenden Daten eine Signatur generiert wurde. Erklärung 2 Das Sicherheitsziel O.SignaturZuf deckt die organisatorische Sicherheitspolitik 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 wer- den bzw. bei Bedarf – 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). Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 42/98 Erklärung 3 Das Sicherheitsziel O.Anzeige deckt die organisatorische Sicherheitspolitik 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 wur- de, sondern auch ergänzende Informationen zur Nachricht, wie Zertifikatsin- halt, Signaturschlüssel-Inhaber und Verifikations- und Validierungsergebnis- se. 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- Managers beim OSCI-Client-Enabler und -Backend- Enabler vornehmen. Erklärung 4 Das Sicherheitsziel O.ValidZert deckt die organisatorische Sicherheitspolitik 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üfungen 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 5 Das Sicherheitsziel O.VerifySign deckt die organisatorische Sicherheitspolitik P.VerifySign zur Prüfung einer qualifizierten elektronischen Signatur ab und präzisiert, dass die Verifikation durch die Prüfung der Integri- 45 Wie bereits in Abschnitten 2.3 und 2.4 ausgeführt, wird die eigentliche Validierung von der Basiskomponente durchgeführt. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 43/98 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äts- prüfung festgestellt werden kann, ob Veränderungen am OSCI-Client-Enabler vorgenommen wurden. Erklärung 6 Das Sicherheitsziel O.Manipulation deckt die organisatori- sche Sicherheitspolitik P.Manipulation zum Schutz vor unbefugter Verände- rung des OSCI-Client-Enablers ab. 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 angeforderte 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 an- gegebenem Prüfzeitpunkt bereits begonnen und noch nicht abgelaufen war, und für die Zertifikate der Zertifikatskette festgestellt wird, ob o ein Ausstellerzertifikat zum Signierzeitpunkt des ausgestellten Zertifikats vorhanden und nicht ge- sperrt war und Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 44/98 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 Sicherheitsme- chanismus der Basiskomponente für die Erzeugung ei- ner elektronischen Signatur für einen vom OSCI- Manager erzeugten und übergebenen Hashwert zum Signieren des OSCI-Laufzettels genutzt. Erklärung 7 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 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 geeigneten 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. -Backend-Enabler – zugreifen, die die Funktio- nalitäten des EVG nutzen und welche die Anforderungen von Signaturgesetz und -verordnung an eine Signaturan- wendungskomponente beachten. Insbesondere gewährleis- ten sie die Funktionalitäten hinsichtlich Identifikation und Au- thentisierung zum Management von Sicherheitsattributen, d. h. den kryptographischen Schlüsseln und den (System-) Zer- tifikaten. In der IT-Umgebung muss beim OSCI-Client bzw. -Backend gewährleistet sein, dass auf Anforderung des Benutzers resp. Security-Administrators angezeigt wird, welcher OSCI- Manager angesprochen wird – durch Adresse und (System-) Zertifikat. Erklärung 8 Das 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 Betrieb der serverseitigen Komponenten des EVG (OSCI-Manager und -Backend- Enabler) sind vorhanden. Es müssen verschiedene Administratoren für die verschie- denen Aufgaben benannt sein, die einen Beitrag zur Sicher- Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 45/98 stellung einer vertraulichen und integren Betriebsumgebung des EVG leisten. Ein Vier-Augen-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 hinsichtlich der räumlichen Gegebenheiten und für die Realisierung der Netzwerkarchi- tektur und der internen Verbindungen zwischen den einzel- nen Systemkomponenten mit Firewall, Demilitarisierter Zone (DMZ) etc. Vgl. dazu die Vorgaben und Auflagen zum Be- trieb der Virtuellen Poststelle, die im „Generischen Sicher- heitskonzept für die Kern- und Webkomponenten der Virtuel- len Poststelle“ beschrieben werden [VPS-SiKo]. OSCI-Manager und Kernsystem der Basiskomponente ([bos_Basis_ST]) müssen zusammen innerhalb eines ver- trauenswürdigen Netzes betrieben werden. Der OSCI-Backend-Enabler als Funktionsbibliothek nutzt kryptographische Schlüssel und (System-)Zertifikate, die vom OSCI-Backend zur Verfügung gestellt werden; eine ge- eignete Identifikation und Authentisierung zum Management dieser Sicherheitsattribute muss durch den OSCI-Backend sichergestellt werden. Die Anforderungen aus [BNetzA2005] an einen „geschützten Einsatzbereich (Regelfall/Standardlösung)“ müssen umge- setzt sein, um „potentielle Angriffen über das Internet, ein angeschlossenes Intranet, einen manuellen Zugriff Unbefug- ter und einen Datenaustausch per Datenträger [...] durch ei- ne Kombination von Sicherheitsvorkehrungen in der Signa- turanwendungskomponente 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 An- ti-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. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 46/98  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. 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 9 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 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 Verdacht 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 hinsicht- lich der räumlichen Gegebenheiten und für die Realisierung der Netzwerkarchitektur mit Firewall etc. Vgl. dazu die Vor- gaben und Auflagen zum Betrieb der Virtuellen Poststelle, die im „Generischen Sicherheitskonzept für die Kern- und Webkomponenten der Virtuellen Poststelle“ beschrieben werden [VPS-SiKo]. Der OSCI-Client-Enabler als Funktionsbibliothek nutzt kryp- tographische Schlüssel und (System-)Zertifikate, die vom OSCI-Client zur Verfügung gestellt werden; eine geeignete Identifikation und Authentisierung zum Management dieser Sicherheitsattribute muss vom OSCI-Client sichergestellt werden. Der OSCI-Client muss auch die Integrität der kryp- tographischen Schlüssel und (System-)Zertifikate sichern – denkbar ist, dass diese Sicherheitsattribute Bestandteil der integritätsgeschützten Software sind oder dass diese Konfi- Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 47/98 gurationsdaten – ähnlich wie bei EVG3 – gesondert abgesi- chert werden. Die Anforderungen aus [BNetzA2005] an einen „geschützten Einsatzbereich (Regelfall/Standardlösung)“ müssen umge- setzt sein, um „potentielle Angriffen über das Internet, ein angeschlossenes Intranet, einen manuellen Zugriff Unbefug- ter und einen Datenaustausch per Datenträger [...] durch ei- ne Kombination von Sicherheitsvorkehrungen in der Signa- turanwendungskomponente selbst und der Einsatzumge- bung mit hoher Sicherheit“ hinsichtlich eines hohen Angriffs- potentials 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. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 48/98 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. 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 10 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. 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 sicherer Signaturerstellungseinheit nicht preis- gegeben und nur auf der jeweiligen sicheren Signaturerstel- lungseinheit gespeichert werden. Erklärung 11 Das 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 werden, 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 relevant ist:46 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- Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 49/98 102 Der OSCI-Manager lässt den OSCI-Laufzettel vom Kernsystem der Basis- komponente mit einer elektronischen Signatur versehen16 , welche OSCI- Client-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. 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- Sicherheitsanforderungen 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) schen Signatur oder eines qualifizierten Zertifikats wird in der IT-Umgebung (in der siche- ren Signaturerstellungseinheit bzw. dem unterliegenden System) kontrolliert. 47 Das Management der Sicherheitsattribute in OSCI-Client und -Backend obliegen der IT-Umgebung. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 50/98 Funktionale Sicherheits- anforderung an den EVG Beschreibung 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) 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 Erzeu- gung 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 Signaturkarte die kryptographische Ope- ration „Hashen“ gemäß eines spezifizierten kryp- tographischen Algorithmus SHA-1 und kryptographi- 48 Explizit dargelegte funktionale Anforderung (vgl. Abschnitt 9). Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 51/98 scher Schlüssellängen, die bei einer Hashfunktion nicht relevant sind, die der folgenden Norm [SHA-1] entspricht, durchführen. Erklärung 12 Die in FCS_COP.1.1/Hash spezifizierte Hashfunktion wird gemäß OSCI-Transport genutzt (vgl. Abschnitt 2.2). Erklärung 13 Die funktionale Sicherheitsanforderung FCS_COP.1 (Hash) wird für die Umsetzung des Sicherheitsziels O.SignaturZuf benötigt. Erklärung 14 Die 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. 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 kryptographi- schen Algorithmus RSA im Zusammenhang mit der Hashfunktion SHA-1 und kryptographischer Schlüssel- längen, die entsprechend der X.509-Serverzertifikate derzeit 2048 Bit aufweisen, die den folgenden Nor- men [RSA] und [SHA-1] 49 entsprechen, durchführen. Erklärung 15 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- Laufzettels (vom OSCI-Manager mit Hilfe der Basiskomponente erzeugt) mit dem (System-)Zertifikat verifizieren müssen. Erklärung 16 Die 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 Erzeu- gung einer elektronischen Signatur des OSCI-Lauf- zettels) 49 Hinsichtlich des Paddings wird PKCS#1 [PKCS#1] umgesetzt. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 52/98 114 FCS_COP.1.1/OSCI Die TSF müssen im Rahmen der Gewährleistung der Systemsicherheit die kryptographische Operation „Hashen“ gemäß eines spezifizierten kryptographi- schen Algorithmus SHA-1 und kryptographischer Schlüssellängen, die bei einer Hashfunktion nicht re- levant sind, die der folgenden Norm [SHA-1] ent- spricht, durchführen. Erklärung 17 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 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 zuge- ordneten – (System-) Zertifikat verifiziert werden kann. Erklärung 18 Die 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. 115 FCS_COP.1 (Verify) Kryptographischer Betrieb (für die kryptographi- sche Operation „Verifizieren“ einer qualifizierten e- lektronischen Signatur) 116 FCS_COP.1.1/Verify Die TSF müssen für die Verifikation einer qualifizier- ten elektronischen Signatur die kryptographische Operation „Verifizieren“ gemäß eines spezifizierten kryptographischen Algorithmus RSA im Zusammen- hang mit der Hashfunktion SHA-1 und kryptographi- scher Schlüssellä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 19 Die funktionale Sicherheitsanforderung FCS_COP.1 (Verify) wird für die Umsetzung des Sicherheitsziels O.VerifySign benötigt. Erklärung 20 Die 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 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 53/98 Signaturkarte erzeugten qualifizierten elektroni- schen Signatur) 118 FCS_COP.1.1/VSignDie TSF müssen für die Verifikation einer qualifizier- ten elektronischen Signatur die kryptographische Operation „Verifizieren“ gemäß eines spezifizierten kryptographischen Algorithmus RSA im Zusammen- hang mit der Hashfunktion SHA-1 und kryptographi- scher Schlüssellä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 21 Die 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 22 Die 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üf- tools) 120 FCS_COP.1.1/Tool Die TSF müssen im Zusammenhang mit dem Prüf- tool die kryptographische Operation „Verifizieren“ gemäß eines spezifizierten kryptographischen Algorith- mus 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 entsprechen, durchfüh- ren. Erklärung 23 Die funktionale Sicherheitsanforderung FCS_COP.1 (Tool) wird für die Umsetzung des Sicherheitsziels O.Manipulation benötigt. Erklärung 24 Die 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. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 54/98 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 signie- renden oder signierten Daten) entsprechend den fol- genden Normen plain-text (UTF-8-codiert) sowie hin- sichtlich dem Erzeugen einer Signatur durch prozedura- le Anzeigetexte, dem Bezug zu den Daten, auf die sich die Signatur bezieht – beim Signieren und Verifizieren –, dem Ergebnis der Verifikation einer qualifizierten elekt- ronischen Signatur, dem Ergebnis der Validierung eines qualifizierten Zertifikats, dem Signaturschlüssel-Inhaber der Signatur (optional) und dem Zertifikatsinhalt (optio- nal) 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 Inhalten ist. Die TSF müssen sicher- stellen, dass der Benutzer darüber informiert 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 25 Die funktionale Sicherheitsanforderung FDP_SVR.1 wird für die Umsetzung des Sicherheitsziels O.Anzeige benötigt. Erklärung 26 FDP_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-Zugriffs- kontrollpolitik) für  die betrachteten Subjekte: o Schlüssel-Administrator;  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 27 Die funktionale Sicherheitsanforderung FDP_ACC.1 ergibt sich aus der Abhängigkeit von FDP_ITC.1 und wird daher implizit für die Um- setzung des Sicherheitsziels O.ValidZert in der Weise benötigt, dass der Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 55/98 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 Ope- rationen zwischen Subjekten und Objekten hinsichtlich der Systemsicherheit- Zugriffskontrollpolitik definiert. Erklärung 28 Die Abhängigkeit von FDP_ACC.1 – FDP_ACF.1 – ist auf- genommen. 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-Zugriffs- kontrollpolitik) für Objekte, die auf den Sicherheits- attributen 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 kontrollierten Objekten zulässig ist: Speichern und Löschen der Referenz des privaten Schlüssels erfolgt nur nach erfolgreicher Authenti- sierung des Schlüssel-Administrators. 130 FDP_ACF.1.3 Die TSF müssen den Zugriff von Subjekten auf Objekte basierend auf den folgenden zusätzlichen Regeln expli- zit autorisieren: Die TSF müssen hierbei keine zusätz- lichen 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 29 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 Operati- on (vgl. FDP_ACC.1) erst nach erfolgreicher Authentisierung des Schlüssel- Administrators erfolgen kann. Erklärung 30 Die 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-Zugriffs- Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 56/98 kontrollpolitik beim Import 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 Sicherheitsatt- ribute ignorieren, wenn diese von außerhalb des TSC importiert werden. 135 FDP_ITC.1.3 Die TSF müssen die folgenden Regeln beim Import unter Kontrolle der SFP stehender Benutzerdaten von außerhalb des TSC durchsetzen: Keine zusätzlichen Importkontrollregeln. Erklärung 31 Die 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 Basis- komponente signieren lässt – und dazu den zu nutzenden Schlüssel referen- ziert –, so dass die Signatur dann von OSCI-Client-Enabler und -Backend- Enabler mit dem (System-)Zertifikat verifizieren werden kann. Erklärung 32 Die Abhängigkeiten von FDP_ITC.1 – FDP_ACC.1 für die Zugriffskontrolle 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 jegliche andere TSF-vermittelte Aktio- nen erlaubt werden. Erklärung 33 Die funktionale Sicherheitsanforderung FIA_UID.2 ergibt sich aus der Abhängigkeit von FMT_SMR.1, wobei statt FIA_UID.1 die hie- rarchische Anforderung FIA_UID.2 genutzt wird. FIA_UID.2 wird damit implizit für die Umsetzung des Sicherheitsziels O.ValidZert benötigt. Erklärung 34 FIA_UID.2 hat keine Abhängigkeiten. 139 FIA_UAU.2 Benutzerauthentisierung vor jeglicher Aktion 140 Ist hierarchisch zu: FIA_UAU.1 141 FIA_UAU.2.1 Die TSF müssen erfordern, daß jeder Benutzer (hier: Schlüssel- und Security-Administrator) erfolgreich au- thentisiert wurde, bevor diesem jegliche andere TSF- vermittelte Aktionen erlaubt werden. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 57/98 Erklärung 35 Die funktionale Sicherheitsanforderung FIA_UAU.2 wird – wie FIA_UID.2 auch – für die Umsetzung des Sicherheitsziels O.ValidZert benötigt. Erklärung 36 FIA_UAU.2 hat die Abhängigkeit FIA_UID.1, die durch die hierarchische 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-Zugriffs- kontrollpolitik) zur Beschränkung der Fähigkeit zum Modifizieren und Löschen der Sicherheitsattribute Rolle, Benutzerkennung und Rechte auf den Securi- ty-Administrator durchsetzen. Erklärung 37 Die funktionale Sicherheitsanforderung FMT_MSA.1 ergibt sich aus der Abhängigkeit von FMT_MSA.3 und wird implizit für die Umset- zung 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. Erklärung 38 Die 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-Zugriffs- kontrollpolitik) zur Bereitstellung von vorgegebenen Standardwerten mit einschränkenden Eigenschaften für Sicherheitsattribute, die zur Durchsetzung der SFP benutzt werden, durchsetzen. 146 FMT_MSA.3.2 Die TSF müssen dem Security-Administrator gestat- ten, bei der Erzeugung eines Objekts oder von Informa- tionen alternative Anfangswerte zu spezifizieren, die die vorgegebenen Standardwerte ersetzen. Erklärung 39 Die funktionale Sicherheitsanforderung FMT_MSA.3 ergibt sich aus den Abhängigkeiten von FDP_ITC.1 und FDP_ACF.1 und wird da- her implizit für die Umsetzung des Sicherheitsziels O.ValidZert benötigt. Im Fokus der Betrachtung steht hierbei das Management der Rolle des Schlüs- sel-Administrators durch den Security-Administrator; die zulässigen Operatio- nen werden in FDP_ACC.1 und FDP_ACF.1 thematisiert. Erklärung 40 Die Abhängigkeiten von FMT_MSA.3 – FMT_MSA.1 und FMT_SMR.1 – sind aufgenommen. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 58/98 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 41 Die funktionale Sicherheitsanforderung FMT_SMR.1 ergibt sich aus den Abhängigkeiten von FMT_MSA.1 (für die Rolle des Security- Administrators 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. Erklärung 42 Die 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 gesicher- te Identifikation seiner Endpunkte sowie den Schutz der Daten des Kanals vor Modifizierung oder Preisgabe be- reitstellt. 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ürdigen Kanal einleiten. Erklärung 43 Die funktionale Sicherheitsanforderung FTP_ITC.1 wird im- plizit für die Umsetzung des Sicherheitsziels O.SignaturZuf benötigt, wobei ein vertrauenswürdiger Kanal zwischen EVG und Signaturkarte aufgebaut wird. Erklärung 44 FTP_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. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 59/98 Tabelle 4: Vertrauenswürdigkeitskomponenten Vertrauenswür- digkeitsklasse Vertrauenswürdigkeitskomponente ACM_CAP.3 Autorisierungskontrolle Konfigurations- management ACM_SCP.1 EVG-CM-Umfang ADO_DEL.2 Erkennung von Modifizierungen Auslieferung und Betrieb ADO_IGS.1 Installations-, Generierungs- und Anlaufprozeduren 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 Entwicklung ADV_RCR.1 Informeller Nachweis der Übereinstimmung AGD_ADM.1 Systemverwalterhandbuch Handbücher AGD_USR.1 Benutzerhandbuch ALC_DVS.1 Identifikation der Sicherheitsmaßnahmen Lebenszyklus- Unterstützung ALC_TAT.1 Klar festgelegte Entwicklungswerkzeuge ATE_COV.2 Analyse der Testabdeckung ATE_DPT.1 Testen – Entwurf auf hoher Ebene ATE_FUN.1 Funktionales Testen Testen ATE_IND.2 Unabhängiges Testen – Stichprobenartig AVA_MSU.3 Analysieren und Testen auf unsichere Zustände AVA_SOF.1 Stärke der EVG-Sicherheitsfunktionen Schwach- stellen- bewertung AVA_VLA.4 Hohe Widerstandsfähigkeit 5.2 Sicherheitsanforderungen an die IT-Umgebung 156 Die funktionalen Sicherheitsanforderungen an die IT-Umgebung sind zu- sammenfassend in Tabelle 5 aufgeführt und im Folgenden aufgeführt bzw. referenziert. Die funktionalen EVG-Sicherheitsanforderungen entstammen dem Teil 2 der CC [CC-Teil2]. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 60/98 Tabelle 5: Funktionale Sicherheitsanforderungen an die IT-Umgebung Funktionale Sicherheits- anforderung an die IT- Umgebung Beschreibung FCS_CKM.150 Kryptographische Schlüsselgenerierung 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_Basis_ST]) FMT_MSA.1 (Sys) Management der Sicherheitsattribute (Systemsicherheit- 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]) 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 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 61/98 Funktionale Sicherheits- anforderung an die IT- Umgebung Beschreibung funktionale Sicherheitsanforderungen, die an SigG-konforme sichere Signaturerstellungs- einheiten und Chipkartenleser gestellt werden, sind den Sicherheitsvorgaben bestätigter Produkte zu entnehmen (vgl. beispielsweise www.bundesnetzagentur.de); weitere Anforde- rungen 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 spezifi- zierten Algorithmus zur kryptographischen Schlüsselge- nerierung mit einem geeigneten Algorithmus zur kryptographischen Schlüsselgenerierung und spezi- fizierte kryptographische 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 Informati- onsflußkontrolle in der IT-Umgebung beim Import von unter Kontrolle der SFP stehenden Benutzerdaten 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 Sicherheitsattri- bute 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 Benutzerdaten von außerhalb des TSC durchsetzen: zusätzliche Importkontrollregeln, so- fern 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 spezifizier- ten Methode zur Zerstörung des kryptographischen Schlüssels durch Löschen bzw. Entfernen aus ent- sprechendem Verzeichnis oder einen anderen ge- eigneten Mechanismus, die […] keiner speziellen Norm entspricht, zerstören. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 62/98 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 Sicherheitsattri- bute akzeptiert werden. Erklärung 45 Die drei funktionalen Sicherheitsanforderungen an die IT- Umgebung – FCS_CKM.1 oder FDP_ITC.1 sowie FCS_CKM.4 und FMT_MSA.2 – ergeben sich aus den Sicherheitszielen O.ValidZert (bzgl. Schlüsselerzeugung 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üsselimport, -zerstörung und -management des zum privaten Schlüssel korrespondierenden Zertifikats, das sich auf der Signaturkarte befindet,) O.Manipulation (bzgl. Schlüsselimport, -zerstörung und -management in Prüf- tool), 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 Si- cherheitsattribute – insbesondere für die (System-) Zertifikate – akzeptiert werden). Die Ausgestaltung der Operationen der funktionalen Sicherheitsan- forderungen sowie die Abhängigkeiten dieser Anforderungen sind in der IT- Umgebung zu realisieren, da Schlüsselerzeugung, -import und -löschung so- wie Management der Sicherheitsattribute in der IT-Umgebung außerhalb des EVG liegt. Erklärung 46 Die in Tabelle 5 referenzierten funktionalen Sicherheitsan- forderungen 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 e- lektronischen Signatur für einen vom OSCI-Manager erzeugten und übermit- telten Hashwert, für die die Basiskomponente der Virtuellen Poststelle des Bundes (vgl. [bos_Basis_ST]) benötigt wird, zurückführen. Erklärung 47 Die funktionalen Sicherheitsanforderungen an die IT- Umgebung zu den SigG-konformen sicheren Signaturerstellungseinheiten und Chipkartenlesern, 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 hin- sichtlich der SigG-konformen sicheren Signaturerstellungseinheiten und Chipkartenleser sowie der qualifizierten Zertifikate zurückführen; weitere An- forderungen werden nicht benötigt. 5.3 Sicherheitsanforderungen an die Nicht-IT-Umgebung 167 Sicherheitsanforderungen an die Nicht-IT-Umgebung werden nicht formuliert. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 63/98 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; 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- Client-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. 53 Dazu ist am Arbeitsplatz-PC in der IT-Umgebung ein Kartenleser installiert. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 64/98  Dazu werden folgende Schritte ausgeführt: o Zuerst wird die Signatur mit dem zum privaten Signaturschlüssel korrespondierenden öffentlichen Schlüssel verifiziert. Kann die Signatur 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.  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- Protokolls. 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- Managers. Initiator ist beim OSCI-Client-Enabler der Benutzer und beim OSCI-Backend-Enabler das OSCI-Backend in der IT-Umgebung. 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. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 65/98  OSCI-Client-Enabler und -Backend-Enabler führen einen Plausibilitäts- check durch, in der OSCI-Client-Enabler bzw. -Backend-Enabler prüfen, ob das im OSCI-Laufzettel enthaltene Ergebnis der Zertifikats- Statusprü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:  Der OSCI-Client-Enabler bietet eine sichere Anzeige von folgenden zu signierenden und signierten Daten: o plain-text (UTF-8-codiert).  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: Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 66/98  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 innerhalb eines vertrauenswürdigen Netzes betrieben wird: Der OSCI- Manager sendet einen Request an das Kernsystem – das Request um- fasst neben dem nachzuprüfenden Zertifikat die SystemID (Identifier des anfragenden Systems) des OSCI-Managers sowie die OperationID (Iden- tifier der auszuführenden Operation) für das Validieren – und empfängt das Response mit dem Validierungsergebnis.  Der OSCI-Manager interpretiert die Antwort der Basiskomponente und generiert ein eigenes Ergebnis, das der OSCI-Manager im OSCI- Laufzettel 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 Basis- komponente, welches die elektronische Signatur für den OSCI- Manager 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“); 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 abgesichert wird. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 67/98 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  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 ACM_CAP.3 Konfigurations- management ACM_SCP.1 Einsatz eines QM-Systems inklusive Konfigurati- onskontrolle Auslieferung ADO_DEL.2 Dokumentation der zum Schutz des EVG bei 56 Dazu wird der OSCI-Client-Enabler als signiertes JAR-Archiv ausgeliefert, vgl. Ab- schnitt 2.7. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 68/98 Anforderungen gemäß EAL3+ Maßnahmen der Entwickler und Betrieb ADO_IGS.1 Auslieferung, Installation und Wartung getroffe- nen Maßnahmen in Form dokumentierter Auslie- ferungsprozeduren sowie Installations-, Generie- rungs- und Anlaufprozeduren ADV_FSP.1 ADV_HLD.2 ADV_IMP.1 ADV_LLD.1 Entwicklung ADV_RCR.1 Definition von Anforderungen gemäß CC an die Entwicklungsprozeduren und Dokumentation AGD_ADM.1 Handbücher AGD_USR.1 Erstellung und Auslieferung eines Systemverwal- ter- und Benutzerhandbuchs ALC_DVS.1 Lebenszyklus- Unterstützung ALC_TAT.1 Gewährleistung des Entwicklungsprozesses durch physikalische, personelle und organisatori- sche Sicherheitsmaßnahmen ATE_COV.2 ATE_DPT.1 ATE_FUN.1 Testen ATE_IND.2 Verwendung eines werkzeugbasierten und au- tomatisierten 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 AVA_MSU.3 AVA_SOF.1 Schwach- stellen- bewertung 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- Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 69/98 Backend-Enabler ist eine Funktionsbibliothek zum Prüfen qualifizierter elekt- ronischer 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 an- geschlossenen sicheren Signaturerstellungseinheit zuführen. 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. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 70/98 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 (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 OS- CI-Client-Enabler und -Backend-Enabler müssen für den Administra- tor 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. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 71/98  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.  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 OS- CI-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 ge- eignete Auflagen und Hinweise an den Signaturschlüssel-Inhaber zur Nutzung seiner Signaturkarte ab  Das Sicherheitsziel für die Umgebung OE.ZufPIN zielt auf die gleichna- mige Annahme A.ZufPIN ab.  Das Sicherheitsziel O.SignaturZuf deckt die organisatorische Sicherheits- politik P.SignaturZuf zur Erzeugung einer qualifizierten elektronischen 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 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 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 72/98 wurde, sondern auch ergänzende Informationen zur Nachricht, wie Zerti- fikatsinhalt, Signaturschlüssel-Inhaber und Verifikations- und Validierung- sergebnisse.  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 Auf- gaben 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.  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 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 73/98 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 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- Laufzettels (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 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 74/98 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.  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 - Backend-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 Operati- onen werden in FDP_ACC.1 und FDP_ACF.1 thematisiert. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 75/98  Die funktionale Sicherheitsanforderung FMT_SMR.1 ergibt sich aus den Abhängigkeiten von FMT_MSA.1 (für die Rolle des Security- Administrators für die Konfiguration der Rechte, Rollen und Berechtigun- gen) 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.  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.  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 Sicherstellung, dass nur sichere Sicherheitsattribute – insbesondere für die (System-) Zertifi- kate – akzeptiert werden). Die Ausgestaltung der Operationen der funkti- onalen Sicherheitsanforderungen sowie die Abhängigkeiten dieser Anfor- derungen sind in der IT-Umgebung zu realisieren, da Schlüsselerzeu- gung, -import und -löschung sowie Management der Sicherheitsattribute 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 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 76/98 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 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 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 77/98 Tabelle 11: Zuordnung Sicherheitsziele zu Sicherheitsanforderungen an die IT- Umgebung 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 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 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) OE.SAK FMT_MSA.2 OE.ZufPIN vgl. Sicherheitsvorgaben bestätigter Produkte Tabelle 12: Zuordung fkt. Sicherheitsanforderungen an die IT-Umgebung zu Si- cherheitszielen 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 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 78/98 funktionale Sicherheitsanforderungen an die IT-Umgebung Sicherheitsziele 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 Signa- turerstellungseinheiten und Chipkarten- leser gestellt werden, sind den Sicher- heitsvorgaben bestätigter Produkte zu entnehmen OE.PKI (sichere Signaturerstellungseinheiten und Chipkartenleser) OE.ZufPIN 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- Umgebung 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. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 79/98  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.  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. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 80/98 Tabelle 13: Erfüllung der EVG-Abhängigkeiten funktionale Sicher- heitsanforderungen 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- Umgebung zu reali- sieren FCS_COP.1 (OSCI) FDP_ITC.1 oder FCS_CKM.1 FCS_CKM.4 FMT_MSA.2 formal nicht erfüllt wg. 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- Umgebung zu reali- sieren FCS_COP.1 (Tool) FDP_ITC.1 oder FCS_CKM.1 FCS_CKM.4 FMT_MSA.2 sind in der IT- Umgebung zu reali- sieren 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 hie- rarchisch 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 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 81/98 funktionale Sicher- heitsanforderungen an den EVG Abhängigkeiten Bemerkung 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 hie- rarchisch zu FIA_UID.1 ist FTP_ITC.1 - formal erfüllt 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 gemäß 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 Tabelle 14 aufgeführt. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 82/98 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 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. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 83/98 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.  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 umzusetzen.  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 quali- fizierter Zertifikate“ werden folgende Komponenten benötigt: o Komponente FCS_COP.1 (OSCI) für das Hashen des OSCI- Laufzettels. o In der IT-Umgebung wird die Basiskomponente zur Validierung eines 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. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 84/98 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 umzusetzen. 194 Darüber hinaus werden funktionale Sicherheitsanforderungen in der IT- Umgebung für SigG-konforme sichere Signaturerstellungseinheiten und Chipkartenleser referenziert, die den Sicherheitsvorgaben bestätigter Produk- te zu entnehmen sind (vgl. beispielsweise www.bundesnetzagentur.de. 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 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 85/98 Fkt. Sicherheitsanfor- derungen an EVG bzw. IT-Umgebung SF1 SF2 SF3 SF4 SF5 SF6 SF7 SF8 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 195 Die Sicherheitsfunktionen wirken in den drei Teilsystemen OSCI-Client- Enabler, -Manager und -Backend-Enabler wie folgt (Tabelle 16): Tabelle 16: Zuordnung von Sicherheitsfunktionen zu Teilsystemen OSCI-Client- Enabler OSCI- Manager OSCI- Backend- 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 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 86/98 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 Sicherheitsfunktionen  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,  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- Administrator ausgeführt wurde. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 87/98 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- Anforderungen 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,  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 Umsetzung der Anforderungen aus SigG und SigV Sicherheitsanforderungen an Signaturanwendungskomponen- ten [BNetzA2005] in EVG Sicherheits- funktion Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 88/98 Umsetzung der Anforderungen aus SigG und SigV Sicherheitsanforderungen an Signaturanwendungskomponen- ten [BNetzA2005] in EVG Sicherheits- funktion „Erzeugung von Signaturen: Die Signaturanwendungskomponen- te muss beim Erzeugen einer 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 be- zieht, wird im OSCI-Client-Enabler angezeigt SF5  bei Bedarf der Inhalt der zu signierenden Daten hinrei- chend zu erkennen ist, kann im OSCI-Client-Enabler angezeigt werden SF5  eine Signatur nur durch die berechtigt signierende Per- son erfolgt, -  die Identifikationsdaten nicht preisgegeben und nur auf der jeweiligen „sicheren Signaturerstellungseinheit“ gespeichert werden. - 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 be- zieht, 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 Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 89/98 Umsetzung der Anforderungen aus SigG und SigV Sicherheitsanforderungen an Signaturanwendungskomponen- ten [BNetzA2005] in EVG Sicherheits- funktion  erkennbar wird, welchem Signaturschlüssel-Inhaber die Signatur zuzuordnen ist, wird vom OSCI-Client-Enabler angezeigt SF5  erkennbar wird, welche In- halte das qualifizierte Zerti- fikat, auf dem die Signatur beruht, und zugehörige qualifizierte Attribut- Zertifikate aufweisen, wird vom OSCI-Client-Enabler angezeigt, allerdings werden keine Attribut-Zertifikate unterstützt SF5  erkennbar wird, ob die nachgeprüften qualifizierten Zertifikate im jeweiligen Zertifikatverzeichnis zum angegebenen Zeitpunkt vorhanden und nicht ge- sperrt 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 ange- kommen ist SF5  die Korrektheit der Signatur zuverlässig geprüft und zu- treffend angezeigt wird. führen OSCI-Client-Enabler und - Backend-Enabler durch SF3 SF5 Schutz vor unbefugter Verände- rung: Sicherheitstechnische Veränderungen an der Signa- turanwendungskomponente müssen für den Nutzer erkenn- bar werden.” Prüftool für den OSCI-Client-Enabler 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): Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 90/98 Tabelle 19: Erklärung der Maßnahmen zur Erfüllung von EAL3+ Anforderungen gemäß 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 Imp- lementierung, 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. 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- Unterstü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. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 91/98 Anforderungen gemäß 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 e- lektronischer Signaturen. In diesem Umfeld ist es erforderlich, dass der Be- nutzer den Inhalt des zu unterschreibenden Dokumentes 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 darstellbare 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 Bestandteil des PP/ der ST ist. 210 FDP_SVR.1 Sichere Anzeige 211 Ist hierarchisch zu: Keinen anderen Komponenten 57 aus [SignCubes] Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 92/98 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 Darstel- lung 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 Inhalten ist. Die TSF müssen sicher- stellen, dass der Benutzer darüber informiert 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_Basis_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] Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 93/98 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 Signaturzeitpunkt 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 Er- zeugungszeitpunkt). Vom Signaturzeitpunkt zu unterscheiden ist der Prüfzeitpunkt. ([BSI_SigI_A6]) Subjekt ”Eine Einheit innerhalb des TSC, die die Ausführung von Ope- rationen 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 Control): Die Menge der Interaktionen, die mit oder innerhalb eines 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] Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 94/98 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 Entwick- ler/Hersteller 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 Ba- siskomponente ‚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. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 95/98 [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 Infrastruc- ture – Certificate and CRL Profile. Request for Comments 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 Infrastruc- ture – Operational Protocols – LDAPv2. Request for Com- ments 2559“, April 1999. [OCSP] Network Working Group: „Internet X.509 Public Key Infrastruc- ture – Online Certificate Status Protocol – OCSP. Request 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 digi- tal 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. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 96/98 [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- Enabler 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; 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 Informationstechnik (BSI) unter www.bsi.bund.de/fachthem/egov/vps.htm verfügbar. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 97/98 o Windows XP;  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 (debisZ- ERT.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. Virtuelle Poststelle des Bundes, Version 2.2.x.x (OSCI), Sicherheitsvorgaben (ST) bremen online services GmbH & Co. KG 20.11.2007 datenschutz nord GmbH 98/98 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.