BSI-DSZ-CC-0332-2007 zu Virtuelle Poststelle des Bundes (Verifikationsmodul) Version 2.2.2.6 der bremen online services GmbH & Co. KG Im Auftrag des Bundesministerium des Innern Certification Report V1.0 ZS-01-01-F-325 V4.0 BSI - Bundesamt für Sicherheit in der Informationstechnik, Postfach 20 03 63, D-53133 Bonn Telefon +49 (0)228 9582-0, Fax +49 (0)228 9582-5477, Hotline +49 (0)228 9582-111 Bundesamt für Sicherheit in der Informationstechnik Godesberger Allee 185-189 - D-53175 Bonn - Postfach 20 03 63 - D-53133 Bonn Phone +49 (0)228 9582-0 - Fax +49 (0)228 9582-5477 - Infoline +49 (0)228 9582-111 BSI-DSZ-CC-0332-2007 Signaturanwendungskomponente Virtuelle Poststelle des Bundes (Verifikationsmodul) Version 2.2.2.6 von bremen online services GmbH & Co. KG im Auftrag von Bundesministerium des Innern Funktionalität: Produktspezifische Sicherheitsvorgaben Common Criteria Teil 2 erweitert Vertrauenswürdigkeit: Common Criteria Teil 3 konform EAL 3 mit Zusatz von ADO_DEL.2, ADV_IMP.1, ADV_LLD.1, ALC_TAT.1, AVA_MSU.3, AVA_VLA.4 Common Criteria Arrangement für Komponenten bis EAL4 Das in diesem Zertifikat genannte IT-Produkt wurde von einer akkreditierten und lizenzierten Prüfstelle nach der Gemeinsamen Evaluationsmethodologie für die Prüfung und Bewertung der Sicherheit von Informationstechnik (CEM), Version 2.3 und Anweisungen der Zertifizierungsstelle für Komponenten oberhalb von EAL 4 unter Nutzung der Common Criteria for IT Security Evaluation (CC), Version 2.3 (ISO/IEC 15408:2005) evaluiert. Dieses Zertifikat gilt nur für die angegebene Version des Produktes in der evaluierten Konfiguration und nur in Verbindung mit dem vollständigen Zertifizierungsreport. Die Evaluation wurde in Übereinstimmung mit den Bestimmungen des Zertifizierungsschemas des Bundesamtes für Sicherheit in der Informationstechnik durchgeführt. Die im Evaluationsbericht enthaltenen Schlußfolgerungen der Prüfstelle sind in Einklang mit den erbrachten Nachweisen. Dieses Zertifikat ist keine generelle Empfehlung des IT-Produktes durch das Bundesamt für Sicherheit in der Informationstechnik oder eine andere Organisation, die dieses Zertifikat anerkennt oder darauf Einfluss hatte. Eine Gewährleistung für das IT-Produkt durch das Bundesamt für Sicherheit in der Informationstechnik oder eine andere Organisation, die dieses Zertifikat anerkennt oder darauf Einfluss hatte, ist weder enthalten noch zum Ausdruck gebracht. Bonn, 23. November 2007 Der Präsident des Bundesamtes für Sicherheit in der Informationstechnik Dr. Helmbrecht L.S. Zertifizierungsreport BSI-DSZ-CC-0332-2007 IV Dies ist eine eingefügte Leerseite. BSI-DSZ-CC-0332-2007 Zertifizierungsreport Vorbemerkung Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat gemäß BSIG1 die Aufgabe, für Produkte (Systeme oder Komponenten) der Informationstechnik, Sicherheitszertifikate zu erteilen. Die Zertifizierung eines Produktes wird auf Veranlassung des Herstellers oder eines Vertreibers - im folgenden Antragsteller genannt - durchgeführt. Bestandteil des Verfahrens ist die technische Prüfung (Evaluierung) des Produktes gemäß den vom BSI öffentlich bekannt gemachten oder allgemein anerkannten Sicherheitskriterien. Die Prüfung wird in der Regel von einer vom BSI anerkannten Prüfstelle oder vom BSI selbst durchgeführt. Das Ergebnis des Zertifizierungsverfahrens ist der vorliegende Zertifizierungsreport. Hierin enthalten sind u. a. das Sicherheitszertifikat (zusammenfassende Bewertung) und der detaillierte Zertifizierungsbericht. Der Zertifizierungsbericht enthält die sicherheitstechnische Beschreibung des zertifizierten Produktes, die Einzelheiten der Bewertung und Hinweise für den Anwender. 1 Gesetz über die Errichtung des Bundesamtes für Sicherheit in der Informationstechnik (BSI- Errichtungsgesetz-BSIG) vom 17. Dezember 1990, Bundesgesetzblatt I S. 2834 V Zertifizierungsreport BSI-DSZ-CC-0332-2007 VI Gliederung Teil A: Zertifizierung Teil B: Zertifizierungsbericht Teil C: Auszüge aus den technischen Regelwerken Teil D: Anhänge BSI-DSZ-CC-0332-2007 Zertifizierungsreport A Zertifizierung 1 Grundlagen des Zertifizierungsverfahrens Die Zertifizierungsstelle führt das Verfahren nach Maßgabe der folgenden Vor- gaben durch: • BSIG2 • BSI-Zertifizierungsverordnung 3 • BSI-Kostenverordnung 4 • besondere Erlasse des Bundesministeriums des Innern • die Norm DIN EN 45011 • BSI-Zertifizierung: Verfahrensbeschreibung (BSI 7125) • Gemeinsame Kriterien für die Prüfung und Bewertung der Sicherheit von Informationstechnik (CC), Version 2.35 • Gemeinsame Evaluationsmethodologie für die Prüfung und Bewertung der Sicherheit von Informationstechnik (CEM), Version 2.3 • BSI-Zertifizierung: Anwendungshinweise und Interpretationen zum Schema (AIS) • Hinweise der Zertifizierungsstelle zur Methodologie für Vertrauenswürdigkeitskomponenten oberhalb von EAL 4 (AIS 34) 2 Anerkennungsvereinbarungen Um die Mehrfach-Zertifizierung des gleichen Produktes in verschiedenen Staa- ten zu vermeiden, wurde eine gegenseitige Anerkennung von IT-Sicherheits- zertifikaten - sofern sie auf ITSEC oder Common Criteria (CC) beruhen - unter gewissen Bedingungen vereinbart. 2 Gesetz über die Errichtung des Bundesamtes für Sicherheit in der Informationstechnik (BSI- Errichtungsgesetz-BSIG) vom 17. Dezember 1990, Bundesgesetzblatt I S. 2834 3 Verordnung über das Verfahren der Erteilung eines Sicherheitszertifikats durch das Bundesamt für Sicherheit in der Informationstechnik (BSI-Zertifizierungsverordnung- BSIZertV) vom 7.Juli 1992, Bundesgesetzblatt I S. 1230 4 Kostenverordnung für Amtshandlungen des Bundesamtes für Sicherheit in der Informati- onstechnik (BSI-Kostenverordnung-BSI-KostV) vom 3. März 2005, Bundesgesetzblatt I S. 519 5 Bekanntmachung des Bundesministeriums des Innern vom 10. Mai 2006 im Bundesanzeiger, datiert 19. Mai 2006, S. 19445 A-1 Zertifizierungsreport BSI-DSZ-CC-0332-2007 2.1 Europäische Anerkennung von ITSEC/CC - Zertifikaten Ein Abkommen über die gegenseitige Anerkennung von IT- Sicherheitszertifikaten, auf deren Grundlage ITSEC-Zertifikate für IT-Produkte unter gewissen Bedingungen anerkannt werden, ist im März 1998 in Kraft getreten (SOGIS-MRA). Es wurde von den nationalen Stellen der folgenden Staaten unterzeichnet: Deutschland, Finnland, Frankreich, Griechenland, Großbritannien, Italien, Niederlande, Norwegen, Portugal, Schweden, Schweiz und Spanien. Das Abkommen wurde zur gegenseitigen Anerkennung von IT- Sicherheitszertifikaten auf Basis der CC bis einschließlich der Evaluationsstufe EAL7 erweitert. Das BSI erkennt die Zertifikate der nationalen Zertifizierungsstellen von Frankreich und Großbritannien im Rahmen dieses Abkommens an. Das SOGIS-MRA-Logo auf dem Zertifikat zeigt, dass das Zertifikat unter den Bedingungen des Abkommens anerkannt wird. 2.2 Internationale Anerkennung von CC - Zertifikaten Im Mai 2000 wurde eine Vereinbarung (Common Criteria-Vereinbarung) über die gegenseitige Anerkennung von IT-Sicherheitszertifikaten und Schutzprofilen auf Basis der CC bis einschließlich der Vertrauenswürdigkeitsstufe EAL 4 verabschiedet (CC-MRA). Der Vereinbarung sind bis Februar 2007 die nationalen Stellen folgender Nationen beigetreten: Australien, Dänemark, Deutschland, Finnland, Frank- reich, Griechenland, Großbritannien, Indien, Israel, Italien, Japan, Kanada, Republik Korea, Neuseeland, Niederlande, Norwegen, Österreich, Schweden, Spanien, Republik Singapur, Tschechische Republik, Türkei, Ungarn, USA. Eine aktuelle Liste der Unterzeichnerstaaten bzw. der anerkannten Zertifizierungstellen kann auf der Internetseite http:\\www.commoncriteriaportal.org eingesehen werden. Das Common Criteria-Logo auf dem Zertifikat zeigt, dass das Zertifikat unter den Bedingungen des Abkommens anerkannt wird. Diese Evaluierung beinhaltet die Komponenten AVA_MSU.3 und AVA_VLA.4, die nicht unter der Common Criteria Vereinbarung über die gegenseitige Anerkennung von IT-Sicherheitszertifikaten anerkannt werden. Für die gegenseitige Anerkennung sind die EAL4 Komponenten dieser Vertrauenswürdigkeitsfamilien relevant. 3 Durchführung der Evaluierung und Zertifizierung Die Zertifizierungsstelle führt für jede einzelne Evaluierung eine Prüfbegleitung durch, um einheitliches Vorgehen, einheitliche Interpretation der Kriterienwerke und einheitliche Bewertungen sicherzustellen. A-2 BSI-DSZ-CC-0332-2007 Zertifizierungsreport Das Produkt Virtuelle Poststelle des Bundes (Verifikationsmodul), Version 2.2.2.6 hat das Zertifizierungsverfahren beim BSI durchlaufen. Für diese Evaluierung wurden bestimmte Ergebnisse aus dem Evaluierungsprozess BSI- DSZ-CC-0331-2007 wiederverwendet. Die Evaluation des Produkts Virtuelle Poststelle des Bundes (Verifikationsmodul), Version 2.2.2.6 wurde von T-Systems GEI GmbH durchgeführt. Die Evaluierung wurde am 22. November 2007 beendet . Das Prüflabor T-Systems GEI GmbH ist eine vom BSI anerkannte Prüfstelle (ITSEF)6 . Der Sponsor und Antragsteller ist: Bundesministerium des Innern Das Produkt wurde entwickelt von: bremen online services GmbH & Co. KG Die Zertifizierung wurde damit beendet, dass das BSI die Übereinstimmung mit den Kriterien überprüft und den vorliegenden Zertifizierungsreport erstellt hat. 4 Gültigkeit des Zertifikats Dieser Zertifizierungsreport bezieht sich nur auf die angegebene Version des Produktes. Das Produkt ist nur unter den folgenden Bedingungen konform zu den bestätigten Vertrauenswürdigkeitskomponenten: • alle Auflagen hinsichtlich der Generierung, der Konfiguration und dem Einsatz des EVG, die in diesem Report gestellt werden, werden beachtet. • das Produkt wird in der Umgebung betrieben, die in diesem Report und in den Sicherheitsvorgaben beschrieben ist. • das evaluierte Auslieferungsverfahren wird eingehalten. Die Bedeutung der Vertrauenswürdigkeitsstufen und die Stärke der Funktionen werden in den Auszügen aus dem technischen Regelwerk am Ende des Zertifizierungsreports erläutert. Das Zertifikat bestätigt die Vertrauenswürdigkeit des Produktes gemäß den Sicherheitsvorgaben zum Zeitpunkt der Ausstellung. Da Angriffe mit neuen oder weiterentwickelten Methoden in Zukunft möglich sind, besteht die Möglichkeit, die Widerstandsfähigkeit des Produktes im Rahmen des Assurance Continuity- Programms des BSI regelmäßig überprüfen zu lassen. Die Zertifizierungsstelle empfiehlt, regelmäßig eine Einschätzung der Widerstandsfähigkeit vornehmen zu lassen. Bei Änderungen am Produkt kann die Gültigkeit des Zertifikats auf neue Versionen ausgedehnt werden. Voraussetzung dafür ist, dass der Antragsteller die Aufrechterhaltung der Vertrauenswürdigkeit (d.h. eine Re-Zertifizierung oder 6 Information Technology Security Evaluation Facility A-3 Zertifizierungsreport BSI-DSZ-CC-0332-2007 A-4 ein Maintenance Verfahren) in Übereinstimmung mit den entsprechenden Regeln beantragt und die Evaluierung keine Schwächen aufdeckt. 5 Veröffentlichung Der nachfolgende Zertifizierungsbericht enthält die Seiten B-1 bis B-17 und D1 bis D-2. Das Produkt Virtuelle Poststelle des Bundes (Verifikationsmodul), Version 2.2.2.6 ist in die BSI-Liste der zertifizierten Produkte, die regelmäßig veröffentlicht wird, aufgenommen worden (siehe auch Internet: http://www.bsi.bund.de). Nähere Informationen sind über die BSI-Infoline 0228/9582-111 zu erhalten. Weitere Exemplare des vorliegenden Zertifizierungsreports können beim Her- steller des Produktes angefordert werden.7 . Der Zertifizierungsreport kann ebenso in elektronischer Form von der oben angegebenen Internetadresse heruntergeladen werden. 7 bremen online services GmbH & Co. KG Am Fallturm 9 28359 Bremen, Deutschland BSI-DSZ-CC-0332-2007 Zertifizierungsreport B Zertifizierungsbericht Der nachfolgende Bericht ist eine Zusammenfassung aus • den Sicherheitsvorgaben des Antragstellers für den Evaluationsgegen- stand, • den entsprechenden Prüfergebnissen des Prüflabors und • ergänzenden Hinweisen und Auflagen der Zertifizierungsstelle. B-1 Zertifizierungsreport BSI-DSZ-CC-0332-2007 Gliederung des Zertifizierungsberichtes 1 Zusammenfassung 3 2 Identifikation des EVG 6 3 Sicherheitspolitik 7 4 Annahmen und Klärung des Einsatzbereiches 8 5 Informationen zur Architektur 8 6 Documentation 10 7 Testverfahren 10 8 Evaluierte Konfiguration 11 9 Ergebnis der Evaluierung 12 9.1 CC spezifische Ergebnisse 12 9.2 Ergebnis der kryptographischen Bewertung 12 10 Auflagen und Hinweise zur Benutzung des EVG 13 11 Security Target 14 12 Definitionen 14 12.1 Abkürzungen 14 12.2 Glossar 15 13 Literaturangaben 16 B-2 BSI-DSZ-CC-0332-2007 Zertifizierungsreport 1 Zusammenfassung Im Rahmen des Projektes BundOnline 2005 wurde die Virtuelle Poststelle des Bundes entwickelt. Sie stellt als zentrales Kommunikations-Gateway Sicherheitsdienste für die gesicherte Kommunikation zwischen Behörden und externen Kommunikationspartnern (Bürger, Wirtschaft und andere Behörden) bereit. Dieses komplexe Produkt wird in drei Verfahren mit den Evaluationsgegenständen Virtuelle Poststelle des Bundes (Basis) bzw. Basiskomponente (EVG 1, blau markiert in Abbildung 1), Virtuelle Poststelle des Bundes (OSCI) bzw. OSCI -Komponente (EVG 2, gelb markiert in Abbildung 1) und Virtuelle Poststelle des Bundes (Verifikationsmodul) bzw. Verifikationsmodul (EVG 3, orange markiert in Abbildung 1 und Gegenstand dieses Zertifikats) evaluiert und zertifiziert. Ausschließlich die in Abbildung 1 farblich gekennzeichneten Teile der Virtuellen Poststelle des Bundes sind Bestandteil von Zertifizierungsverfahren. Alle weiteren Anteile, die in Abbildung 1 nicht farblich markiert sind, sind demzufolge nicht Gegenstand einer Zertifizierung. MTA 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- Verifikations- anwendung sierungs- anwendung Authentifizierungs- server Verifikations- server OSCI-Client- Enabler OSCI- Backend-Enabler Entry OSCI- Postfächer Web-Client Anwendungen Verwaltung Postbücher Mail Anwendung fachspezifisch zu implementieren: Mail Interface (MI) Trust-Center Virtuelle Poststelle des Bundes SMTP Proxy NetSigner Kartenleser Abbildung 1: Aufbau der Virtuellen Poststelle des Bundes Die Basiskomponente (EVG 1) wird zentral in einem gesicherten Bereich (z.B. in einem Rechenzentrum) betrieben und stellt folgende Funktionalitäten zentral zur Verfügung: • Unterstützung bei der Erzeugung qualifizierter elektronischer Batchsignaturen, B-3 Zertifizierungsreport BSI-DSZ-CC-0332-2007 • mathematische Prüfung qualifizierter elektronischer Signaturen (Verifikation) und • Statusprüfung qualifizierter Zertifikate (Validierung). Sowohl die OSCI-Komponente als auch das Verifikationsmodul greifen zur Bereitstellung ihrer eigenen Funktionalität auf die im Sinne eines Servers betriebene Basiskomponente zurück, so dass die Zertifizierung der Basiskomponente eine Voraussetzung für den sicheren Einsatz von EVG 2 und EVG 3 darstellt. Die OSCI-Komponente (EVG 2) beinhaltet eine Funktionsbibliothek (OSCI- Client-Enabler) für die sichere Anzeige und das Signieren von Dokumenten am Arbeitsplatz sowie zur Kommunikation über das OSCI-Protokoll. Die weiteren Anteile der OSCI-Komponente bilden eine Funktionsbibliothek zur Integration in ein Fachverfahren (OSCI-Backend-Enabler), die eine Anbindung über das OSCI-Protokoll erlaubt sowie die zentrale Serverkomponente für den Betrieb einer OSCI-konformen IT-Infrastruktur (OSCI-Manager). Das Verifikationsmodul (EVG 3) ist Gegenstand dieser Evaluierung und umfasst eine Signaturanwendungskomponente für das Verifizieren von Signaturen sowie von Zertifikaten am Arbeitsplatz des Endnutzers. Der EVG besteht aus einer Serverkomponente (Verifikationsserver), einem dazugehörigen Client (Verifikationsanwendung) sowie einem Tool zur Prüfung der Integrität der Verifikationsanwendung (Prüftool). Der Verifikationsserver wird zentral in einem gesicherten Bereich betrieben, während die Verifikationsanwendung für den Einsatz an Arbeitsplätzen im Home- oder Officebereich geeignet ist. Der Betrieb des EVG erfordert den Zugriff auf die Basiskomponente der Virtuellen Poststelle des Bundes mit Kernsystem und OCSP/CRL-Relay (s. Abbildung 1), wobei die Kommunikation zur Basiskomponente über den Verifikationsserver erfolgt. Die Sicherheitsvorgaben [6] stellen die Grundlage für die Zertifizierung dar. Sie verwenden kein zertifiziertes Protection Profile. Die Vertrauenswürdigkeitskomponenten sind dem Teil 3 der Common Criteria entnommen (siehe Teil C oder [1], Teil 3). Der EVG erfüllt die Anforderungen der Vertrauenswürdigkeitsstufe EAL 3 mit Zusatz von ADV_IMP.1, ADV_LLD.1, ALC_TAT.1, ADO_DEL.2, AVA_MSU.3, AVA_VLA.4. Die funktionalen Sicherheitsanforderungen (Security Functional Requirements SFR) an den EVG werden in den Sicherheitsvorgaben [6] Kapitel 5.2 beschrieben. Sie wurden dem Teil 2 der Common Criteria entnommen und durch neu definierte funktionale Sicherheitsanforderungen ergänzt. Der EVG ist daher gekennzeichnet als Teil 2 erweitert. Die funktionalen Sicherheitsanforderungen für die IT-Umgebung des EVG werden in den Sicherheitsvorgaben [6] im Kapitel 5.3 dargestellt. Die funktionalen Sicherheitsanforderungen werden durch die folgenden Sicherheitsfunktionen des EVG umgesetzt: B-4 BSI-DSZ-CC-0332-2007 Zertifizierungsreport Sicherheitsfunktion des EVG Thema SF1 Verifikation einer qualifizierten elektronischen Signatur Der EVG prüft eine gegebene Signatur unter Nutzung des mitgelieferten Zertifikats mathematisch. Weiterhin erstellt der EVG eine Anfrage an die Basiskomponente zur Prüfung des qualifizierten Zertifikats. Mit Hilfe der Sicherheitsfunktion SF.2 wird das Ergebnis der Basiskomponente überprüft und mittels SF.3 dem Benutzer authentisch angezeigt. SF2 Verifikation einer OCSP/CRL-Relay-Antwort bei der Validierung eines qualifizierten Zertifikats Die Antwort des OCSP/CRL-Relays zur Überprüfung eines qualifzierten Zertifikats wird von diesem fortgeschritten elektronisch signiert. Der EVG prüft diese Signatur mit Hilfe hinterlegter Zertifikate nach und stellt somit sicher, dass die Daten von einem authentischen OCSP/CRL-Relay stammen. SF3 Sichere und zuverlässige Anzeige Das Verifikationsmodul bietet eine sichere Anzeige für Text- Dateien und stellt weitere Anzeigefunktionen gemäß Signaturgesetz §17, Abs. 2 (wie z.B. für Inhalte des zugehörigen qualifizierten Zertifikats) zur Verfügung. SF4 Prüftool Mit Hilfe des Prüftools stellt der EVG dem Benutzer die Möglichkeit zur Verfügung, die Integrität der installierten Komponenten vor Gebrauch zu prüfen. SF5 Schutz der Konfigurationsdaten Diese Sicherheitsfunktion zeigt an, wenn die für die Sicherheit der Kommunikation mit dem Verifikationsserver wichtigen Konfigurationsdaten • Adresse des Verifikationsservers, • Zertifikat des OCSP/CRL-Relays ohne Wissen des Benutzers verändert wurden. Tabelle 1: Sicherheitsfunktionen des EVG Mehr Details sind in den Sicherheitsvorgaben [6], Kapitel 6 dargestellt. Die in den Sicherheitsvorgaben [6], Kapitel 8.4.2 für bestimmte Funktionen angegebene Stärke der Funktionen „hoch” wird bestätigt. Die Bewertung der Stärke der Funktionen erfolgte ohne Einbeziehung der für die Ver- und Entschlüsselung eingesetzten Kryptoalgorithmen (vgl. §4 Abs. 3 Nr. 2 BSIG). Für Details siehe Kap. 9 dieses Berichtes. Die Sicherheitsvorgaben stellen die Sicherheitsumgebung in Form von Annahmen, Bedrohungen und organisatorischen Sicherheitspolitiken in Kapitel 3 dar. B-5 Zertifizierungsreport BSI-DSZ-CC-0332-2007 Der EVG kann nur in einer Konfiguration betrieben werden. Für mehr Details siehe Kapitel 8. Dieses Zertifikat gilt nur für die angegebene Version des Produktes in der evaluierten Konfiguration und nur in Verbindung mit dem vollständigen Zertifizierungsreport. Dieses Zertifikat ist keine generelle Empfehlung des IT- Produktes durch das Bundesamt für Sicherheit in der Informationstechnik oder eine andere Organisation, die dieses Zertifikat anerkennt oder darauf Einfluss hatte. Eine Gewährleistung für das IT-Produkt durch das Bundesamt für Sicherheit in der Informationstechnik oder eine andere Organisation, die dieses Zertifikat anerkennt oder darauf Einfluss hatte, ist weder enthalten noch zum Ausdruck gebracht. 2 Identifikation des EVG Der Evaluierungsgegenstand (EVG) heißt: Virtuelle Poststelle des Bundes (Verifikationsmodul), Version 2.2.2.68 Der EVG wird an einen Betreiber der Virtuellen Poststelle des Bundes entweder online oder auf einem nicht wiederbeschreibbaren Medium ausgeliefert. Im Falle einer Online-Auslieferung wird der EVG in Form eines Archivs auf einem mit einem SSL-Zertifikat gesicherten Server bereitgestellt, auf dem auch der SHA-1-Wert des Archivs veröffentlicht wird. Auf einem zweiten Kommunikationsweg (E-Mail, Fax, o.ä.) wird dem Betreiber die URL zum Download des Archivs sowie dessen Hashwert mitgeteilt und auferlegt, den Hashwert vor der Installation des EVG gemäß den Sicherheitshinweisen zu prüfen. Im Falle einer Auslieferung des EVG auf einem nicht wiederbeschreibbaren Medium an einen Betreiber wird dieser über den erfolgten Versand informiert. Außerdem wird dem Empfänger der Hashwert des auf dem Medium enthaltenen Archivs mitgeteilt (z.B. per E-Mail oder Fax), den er dann gemäß den Sicherheitshinweisen prüfen muss. Der Betreiber stellt die Verfikationsanwendung dem Endbenutzer zur Verfügung. Mit Hilfe des Prüftools, das der Betreiber dem Endbenutzer über eine gesicherte Webseite zur Verfügung stellen muss, kann der Endbenutzer sich von der Authentizität der installierten Verifikationsanwendung überzeugen. Die folgende Tabelle beschreibt den Auslieferungsumfang: 8 In diesem Report auch Verifikationsmodul genannt. B-6 BSI-DSZ-CC-0332-2007 Zertifizierungsreport Nr System Art Teil Versio n Datum Art der Auslieferung 1 Software VPS Verifikationsmodul 2.2.2.6 06.09.2007 auf CD-ROM oder als Download 2 Verifikations- anwendung Dok Benutzerhandbuch der Verifikationsanwendung [11] 2.2.5 06.09.2007 pdf-Datei auf CD-ROM oder als Download 3 Software VPS Verifikationsmodul 2.2.2.6 06.09.2007 auf CD-ROM oder als Download 4 Verifikations- server Dok Betriebshandbuch [10] 2.2.5 06.09.2007 pdf-Datei auf CD-ROM oder als Download 5 Software VPS Verifikationsmodul 2.2.2.6 06.09.2007 auf CD-ROM oder als Download 6 Prüftool Dok Benutzer- und Betriebshandbuch Prüfwerkzeug [9] 2.3.4 06.09.2007 pdf-Datei auf CD-ROM oder als Download Tabelle 2: Auslieferungsumfang des EVG 3 Sicherheitspolitik Die Sicherheitspolitik wird durch die funktionalen Sicherheitsanforderungen ausgedrückt und durch die Sicherheitsfunktionen des EVG umgesetzt. Als Signaturanwendungskomponente hat der EVG dabei das Ziel, die relevanten Vorgaben aus dem Signaturgesetz [13] und der –verordnung [14] zu erfüllen. Dabei handelt es sich hauptsächlich um die folgenden Sachverhalte: • Der EVG zeigt an, dass signierte Daten unverändert sind und welchem Signaturschlüssel-Inhaber die Signatur zugeordnet ist. • Der EVG zeigt den Inhalt des qualifizierten Zertifikats, auf dem die Signatur beruht sowie die Prüfungsergebnisse des Zertifikats eindeutig an. • Bei der Anzeige von Daten in dem unterstützten Text-Format werden Regeln zur sicheren Behandlung von nicht-lesbaren Zeichen durchgesetzt. B-7 Zertifizierungsreport BSI-DSZ-CC-0332-2007 • Mit Unterstützung der Basiskomponente der Virtuellen Poststelle ist der EVG in der Lage, die Gültigkeit einer qualifizierten elektronischen Signatur zur prüfen. • Die Prüfung von qualifizierten Zertifikaten durch den EVG ergibt, ob nachgeprüfte qualifizierte Zertifikate im Verzeichnis der qualifizierten Zertifikate zum angegebenen Zeitpunkt vorhanden und nicht gesperrt waren. • Der EVG gibt dem Endbenutzer auf dem Arbeitsplatz-PC die Möglichkeit, die Integrität der installierten Programmteile zu prüfen. 4 Annahmen und Klärung des Einsatzbereiches Die Annahmen in den Sicherheitsvorgaben sowie Teile der Bedrohungen und organisatorischen Sicherheitspolitiken werden nicht durch den EVG selbst abgedeckt. Diese Aspekte setzen voraus, dass bestimmte Sicherheitsziele durch die EVG-Einsatzumgebung erfüllt werden. Hierbei sind die folgenden Punkte relevant: • Die IT-Umgebung muss die für den Betrieb benötigten SigG-konformen Komponenten bereitstellen. Dazu gehören insbesondere Server-Zertifikate mit geeigneten kryptographischen Verfahren zur Absicherung der Kommunikation zwischen den beteiligten Komponenten. • Die Basiskomponente der Virtuellen Poststelle des Bundes muss entsprechend den Anweisungen in der Benutzerdokumentation installiert und einsatzbereit sein. • Zum Betrieb von zentral betriebenen Serverkomponenten wird vertrauenswürdiges Personal eingesetzt, das den Verifikationsserver zusammen mit der Basiskomponente in einem vertrauenswürdigen Netz betreibt und sicherstellt, dass die Auflagen aus [15] an einen „geschützten Einsatzbereich (Regelfall/Standardlösung)“ umgesetzt werden. • Der Endnutzer betreibt die Verifikationsanwendung in einer Umgebung, in der ein Zugriff Unbefugter ausgeschlossen ist oder zumindest mit hoher Sicherheit erkennbar wird und die Anforderungen an einen geschützten Einsatzbereicht gemäß [15] in einer Home- oder Büroumgebung umgesetzt werden. Details finden sich in den Sicherheitsvorgaben [6] Kapitel 3. 5 Informationen zur Architektur Das Verifikationsmodul besteht aus den Teilsystemen • Verifikationsanwendung (Sub_1 in Abbildung 3) • Verifikationsserver (Sub_2 in Abbildung 3) • Prüftool (Sub_3 in Abbildung 3) • Administrationsanwendung (Sub_4 in Abbildung 3) B-8 BSI-DSZ-CC-0332-2007 Zertifizierungsreport Beim Verifikationsserver handelt es sich um eine Java-Anwendung, die auf einem Server in einem geschützten Bereich (z. B. einem Rechenzentrum) betrieben wird. Die Bedienung erfolgt durch Fachpersonal über Web- Oberflächen (GUIs) der Administrationsanwendung. Die Verifikationsanwendung ist eine Java Webstart-Anwendung, die über einen Link von einem Download-Server geladen und anschließend auf einem Rechner am Arbeitsplatz des Endnutzers betrieben wird. Das Prüftool stellt ein Java-Applet dar, das vom Betreiber des Verifikationsservers den Endbenutzern über eine gesicherte Webseite zur Verfügung gestellt wird. Der Enbenutzer kann dann mit Hilfe des Prüftools die Integrität der installierten Verifikationsanwendung auf seinem Arbeitsplatz-PC überprüfen. Abbildung 2 stellt das VPS Verifikationsmodul schematisch dar, wohingegen Abbildung 3 die Teilsysteme des Verifikationsmoduls und ihre Schnittstellen zeigt. Abbildung 2: Schematische Darstellung des Verifikationsmoduls B-9 Abbildung 3: Schnittstellen des Verifikationsmoduls Zertifizierungsreport BSI-DSZ-CC-0332-2007 6 Dokumentation Die evaluierte Dokumentation, die in Tabelle 2 aufgeführt ist, wird zusammen mit dem Produkt zur Verfügung gestellt. Hier sind die Informationen enthalten, die zum sicheren Umgang mit dem EVG in Übereinstimmung mit den Sicherheitsvorgaben benötigt werden. Zusätzliche Hinweise und Auflagen zum sicheren Gebrauch des EVG, die im Kapitel 10 enthalten sind, müssen befolgt werden. 7 Testverfahren 7.1 Testverfahren des Herstellers Der Hersteller hat das Verhalten jeder der in den Sicherheitsvorgaben (ST) [6] definierten Sicherheitsfunktionen getestet und dokumentiert. Die Tests wurden für folgende Konfigurationen durchgeführt: Hard- und Software für die Serverkomponenten: Betriebssysteme Hardware Sonstiges Linux (SuSE Linux Enterprise Server 9) i386-Architektur (Intel Xeon o.ä) Solaris 9 Sun UltraSparc- Architektur Windows 2003 Server i386-Architektur (Intel Xeon o.ä) • Java: SUN 1.4.2_04 • Application Server: JBoss 3.2.5 inkl. Tomcat 5.0.26 • Datenbank: MySQL 4.1 • Browser zur Administration Tabelle 3: Testkonfigurationen für den Verifikationsserver Hard- und Software der Clientkomponenten: Betriebssysteme Hardware Sonstiges Linux (SuSE Linux Professional 9.x) Windows 2000 Windows XP i386-Architektur (Intel Xeon o.ä) Java: SUN 1.4.2_04 Tabelle 4: Testkonfigurationen der Verifikationsanwendung und des Prüftools Die Testdokumentation zeigt, dass die Tests sowohl auf der Ebene der Teilsysteme des EVGs als auch auf der Modulebene durchgeführt wurden. Die Tests haben gezeigt, dass die Sicherheitsfunktionen des EVGs so implementiert wurden, wie im ST angegeben. 7.2 Testverfahren der Prüfstelle Die Prüfstelle hat bei ihren Tests die folgenden Kombinationen von Hard- und Software verwendet: B-10 BSI-DSZ-CC-0332-2007 Zertifizierungsreport Betriebssysteme Hardware Sonstiges Windows Server 2003 i386-Architektur (Intel Xeon o.ä) • Java: SUN 1.4.2_06 JDK • Application Server: JBoss 3.2.8 inkl. Tomcat 5.0.26 • Datenbank: MySQL 4.1 Tabelle 5: Testkonfiguration der Prüfstelle für den Verifikationsserver Betriebssysteme Hardware Sonstiges Windows XP i386-Architektur (Intel Xeon o.ä) • Java: SUN 1.4.2_04 Tabelle 6: Testkonfiguration der Prüfstelle für Verifikationsanwendung und Prüftool 7.2.1 Unabhängige Tests der Prüfstelle Die Evaluatoren haben die gemäß der gewählten Vertrauenswürdigkeitsstufe geforderten unabhängigen Tests anhand der folgenden Vorgehensweise ausgeführt: • Analyse der Testspezifikationen des Herstellers • Spezifikation eigener Tests der Evaluatoren • Wiederholung von Herstellertests und Vergleich mit den Testresultaten des Herstellers • Durchführung eigener Tests und Dokumentation der Testresultate In Übereinstimmung mit den Anforderungen wurden die Tests (Herstellertests und Evaluatortests) auf der Ebene der Teilsysteme des EVGs durchgeführt. Die Testergebnisse zeigen, dass der EVG sich verhält, wie es erwartet wurde. 7.2.2 Schwachstellenanalyse Basierend auf der Schwachstellenanalyse des Herstellers und ihrer eigenen unabhängigen Schwachstellenanalyse haben die Evaluatoren Penetrationstests entworfen, um zu erkennen, ob die identifizierten potentiellen Schwachstellen in der beabsichtigten Einsatzumgebung des EVGs ausnutzbar sind. Weitere potentielle Schwachstellen wurden durch geeignete Tests des Herstellers abgedeckt. Zusammenfassend kommen die Evaluatoren zu dem Ergebnis, dass beim vorliegenden EVG keine in der angenommenen Einsatzumgebung ausnutzbaren Schwachstellen gefunden wurden. 8 Evaluierte Konfiguration Der EVG wird nur in einer Konfiguration betrieben, bei der die serverseitigen Komponenten verschiedene Betriebszustände annehmen können. Die B-11 Zertifizierungsreport BSI-DSZ-CC-0332-2007 Evaluierung hat gezeigt, dass der EVG in allen Betriebszuständen die entsprechenden Sicherheitsleistungen zur Verfügung stellt. 9 Ergebnis der Evaluierung 9.1 CC spezifische Ergebnisse Der Evaluierungsbericht (Evaluation Technical Report, ETR), [7] wurde von der Prüfstelle gemäß den Common Criteria [1], der Methodologie [2], den Anforderungen des Schemas [3] und allen Interpretationen des Schemas (AIS) [4] erstellt, die für den EVG relevant sind. Die Evaluierungsmethodologie CEM [2] wurde für die Komponenten bis zur Vertrauenswürdigkeitsstufe EAL 4 verwendet. Darüber hinaus wurde die in der AIS 34 [4, AIS 34] definierte Methodologie verwendet. Das Urteil PASS der Evaluierung wird für die folgenden Vertrauenswürdigkeitskomponenten bestätigt: • Alle Komponenten der Klasse ASE • Alle Komponenten der Vertrauenswürdigkeitsstufe EAL 3 der CC (siehe auch Teil C des Zertifizierungsreports) • Die Komponenten ADV_IMP.1 – Teilmenge der Implementierung der TSF ADV_LLD.1 – Beschreibender Entwurf auf niedriger Ebene ALC_TAT.1 – Klar festgelegte Entwicklungswerkzeuge ADO_DEL.2 – Erkennung von Modifizierungen AVA_MSU.3 – Analysieren und Testen auf unsichere Zustände AVA_VLA.4 – Hohe Widerstandsfähigkeit Die Evaluierung hat gezeigt:: • Funktionalität: Produktspezifische Sicherheitsvorgaben Common Criteria Teil 2 erweitert • Vertrauenswürdigkeit Common Criteria Teil 3 konform EAL 3 mit Zusatz von ADO_DEL.2, ADV_IMP.1, ADV_LLD.1, ALC_TAT.1, AVA_MSU.3, AVA_VLA.4 • Die folgenden Sicherheitsfunktionen erfüllen die behauptete Stärke der Funktion hoch: SF5 Schutz der Konfigurationsdaten Die Ergebnisse der Evaluierung gelten nur für den EVG gemäß Kapitel 2 und für die Konfigurationen, die in Kapitel 8 aufgeführt sind. 9.2 Ergebnis der kryptographischen Bewertung Die folgenden Kryptoalgorithmen werden vom EVG verwendet, um seine Sicherheitspolitik umzusetzen: B-12 BSI-DSZ-CC-0332-2007 Zertifizierungsreport – Hashfunktionen: • SHA-1 – Signaturalgorithmen: • RSA mit einem Modulus von 1024 oder 2048 Bit Dies gilt für die folgenden Sicherheitsfunktionen: – SF1 Verifikation einer qualifizierten elektronischen Signatur – SF2 Verifikation einer OCSP/CRL-Relay-Antwort bei der Validierung eines qualifizierten Zertifikats – SF4 Prüftool Die Stärke der Kryptoalgorithmen wurde im Rahmen der Evaluierung nicht bewertet (vgl. §4 Abs. 3 Nr. 2 BSIG). Gemäß den Vorgaben der Bundesnetzagentur [12] sind die Kryptoalgorithmen geeignet zur Erzeugung und Prüfung von qualifizierten elektronischen Signaturen. Der Zeitraum, in dem diese Einschätzung gilt, ist im offiziellen Katalog [12] angegeben und im Kapitel 10 zusammengefasst. 10 Auflagen und Hinweise zur Benutzung des EVG Die in Tabelle 2 genannte Betriebsdokumentation enthält die notwendigen Informationen zur Anwendung des EVG und alle darin enthaltenen Sicherheitshinweise sind zu beachten. 10.1 Hinweise für den Betreiber und den Endbenutzer Die Webseite des Herstellers (http://www.bos-bremen.de/index.html) sollte regelmäßig angesehen werden, da dort Hinweise des Herstellers für die Handhabung des EVGs bereitgestellt werden. Die für die Verifikationsanwendung vorzunehmende Konfigurationseinstellung des Verifikationsservers sollte vor Inbetriebnahme explizit auf ihre Richtigkeit überprüft werden. Die für den Verifikationsserver vorzunehmende Konfigurationseinstellungen zur Verbindung mit dem Kernsystem und den anzubringenden Signaturen sollten vor Inbetriebnahme explizit auf ihre Richtigkeit überprüft werden. Die Integrität der Verifikationsanwendung sollte vor Gebrauch mit dem Prüfwerkzeug geprüft werden. Wenn es dabei zu einem negativen Prüfergebnis kommt, sollte die Verifikationsanwendung nicht verwendet werden. 10.2 Gültigkeitszeitraum der verwendeten Algorithmen Gemäß dem aktuell veröffentlichten Katalog der Bundesnetzagentur [12] sind die Algorithmen bis zu den nachfolgend aufgeführten Terminen zur Erstellung von qualifizierten elektronischen Signaturen geeignet: Hashfunktion: B-13 Zertifizierungsreport BSI-DSZ-CC-0332-2007 • SHA-1: Ende 2009 Erstellen von Signaturen: • RSA mit einer Bitlänge von 1024 Bit: Ende 2007 • RSA mit einer Bitlänge von 2048 Bit: Ende 2012 11 Sicherheitsvorgaben Die Sicherheitsvorgabe [6] wird zur Veröffentlichung in einem separaten Dokument im Anhang A bereitgestellt. 12 Definitionen 12.1 Abkürzungen BSI Bundesamt für Sicherheit in der Informationstechnik / Federal Office for Information Security, Bonn, Germany CCRA Common Criteria Recognition Arrangement CC Common Criteria for IT Security Evaluation EAL Evaluation Assurance Level - Vertrauenswürdigkeitsstufe EVG Evaluierungsgegenstand (EVG) IT Informationstechnologie ITSEF Information Technology Security Evaluation Facility – Prüfstelle für IT-Sicherheit OSCI Online Services Computer Interface9 PP Protection Profile - Schutzprofil SF Sicherheitsfunktion SFP Security Function Policy – Politik der Sicherheitsfunktion SOF Strength of Function – Stärke der Funktion ST Security Target – Sicherheitsvorgaben TOE Target of Evaluation –Evaluierungsgegenstand TSC TSF Scope of Control – Anwendungsbereich der TSF-Kontrolle TSF TOE Security Functions - EVG-Sicherheitsfunktionen TSP TOE security policy - EVG-Sicherheitspolitik 9 siehe auch www.osci.de B-14 BSI-DSZ-CC-0332-2007 Zertifizierungsreport 12.2 Glossar Anwendungsbereich der TSF-Kontrolle - Die Menge der Interaktionen, die mit oder innerhalb eines EVG vorkommen können und den Regeln der TSP unterliegen. Erweiterung - Das Hinzufügen von funktionalen Anforderungen, die nicht in Teil 2 enthalten sind, und/oder von Vertrauenswürdigkeitsanforderungen, die nicht in Teil 3 enthalten sind, zu den Sicherheitsvorgaben bzw. dem Schutzpro- fil. Evaluationsgegenstand - Ein IT-Produkt oder -System - sowie die da- zugehörigen Systemverwalter- und Benutzerhandbücher - das Gegenstand ei- ner Prüfung und Bewertung ist. EVG-Sicherheitsfunktionen - Eine Menge, die die gesamte Hardware, Soft- ware, und Firmware des EVG umfasst, auf die Verlass sein muss, um die TSP korrekt zu erfüllen. EVG-Sicherheitspolitik - Eine Menge von Regeln, die angibt, wie innerhalb eines EVG Werte verwaltet, geschützt und verteilt werden. Formal - Ausgedrückt in einer Sprache mit beschränkter Syntax und festge- legter Semantik, die auf bewährten mathematischen Konzepten basiert. Informell - Ausgedrückt in natürlicher Sprache. Objekt - Eine Einheit im TSC, die Informationen enthält oder empfängt und mit der Subjekte Operationen ausführen. Schutzprofil - Eine implementierungsunabhängige Menge von Sicherheitsan- forderungen für eine Kategorie von EVG, die besondere Anwenderbedürfnisse erfüllen. Semiformal - Ausgedrückt in einer Sprache mit beschränkter Syntax und fest- gelegter Semantik. Sicherheitsfunktion - Ein Teil oder Teile eines EVG, auf die zur Durchsetzung einer hierzu in enger Beziehung stehenden Teilmenge der Regeln der EVG-Si- cherheitspolitik Verlass sein muss. Sicherheitsvorgaben - Eine Menge von Sicherheitsanforderungen und Sicher- heitsspezifikationen, die als Grundlage für die Prüfung und Bewertung eines angegebenen EVG dienen. SOF-Hoch - Eine Stufe der EVG-Stärke von Funktionen, bei der die Analyse zeigt, dass die Funktionen einen geeigneten Schutz gegen geplantes oder organisiertes Brechen der EVG-Sicherheit durch Angreifer bieten, die über ein hohes Angriffspotential verfügen. SOF-Mittel - Eine Stufe der EVG-Stärke von Funktionen, bei der die Analyse zeigt, dass die Funktionen einen angemessenen Schutz gegen naheliegendes oder absichtliches Brechen der EVG-Sicherheit durch Angreifer bieten, die über ein mittleres Angriffspotential verfügen. B-15 Zertifizierungsreport BSI-DSZ-CC-0332-2007 SOF-Niedrig - Eine Stufe der EVG-Stärke von Funktionen, bei der die Analyse zeigt, dass die Funktionen einen angemessenen Schutz gegen zufälliges Bre- chen der EVG-Sicherheit durch Angreifer bieten, die über ein geringes An- griffspotential verfügen. Stärke der Funktionen - Eine Charakterisierung einer EVG-Sicherheitsfunk- tion, die den geringsten angenommenen Aufwand beschreibt, der notwendig ist, um deren erwartetes Sicherheitsverhalten durch einen direkten Angriff auf die zugrundeliegenden Sicherheitsmechanismen außer Kraft zu setzen. Subjekt - Eine Einheit innerhalb des TSC, die die Ausführung von Operationen bewirkt. Zusatz - Das Hinzufügen einer oder mehrerer Vertrauenswürdigkeitskompo- nenten aus Teil 3 der CC zu einer EAL oder einem Vertrauenswürdigkeitspaket. 13 Literaturangaben [1] Common Criteria for Information Technology Security Evaluation, Version 2.3, August 2005 [2] Common Methodology for Information Technology Security Evaluation (CEM), Evaluation Methodology, Version 2.3, August 2005 [3] BSI-Zertifizierung: Verfahrensbeschreibung (BSI 7125) [4] Anwendungshinweise und Interpretationen zum Schema (AIS), die für den EVG relevant sind. Inbesondere: - AIS 34, Version 1.00, 1 June 2004, Evaluation Methodology for CC Assurance Classes for EAL5+ - AIS 38, Version 1.1, 7 January 2004, Reuse of evaluation results [5] Deutsche IT-Sicherheitszertifikate (BSI 7148, BSI 7149), periodisch aktualisierte Liste, die auch auf der Internet-Seite des BSI veröffentlicht wird [6] Sicherheitsvorgaben BSI-DSZ-0332-2007, Version 1.0, 19.11.2007, Virtuelle Poststelle des Bundes, Version 2.2.x.x (Verifikationsmodul) Sicherheitsvorgaben (ST), bremen online services GmbH& Co., KG; datenschutz nord GmbHVersion [7] Evaluation Technical Report, Version 1.0, 21.11.2007, Evaluierungsbericht Zertifizierungs-ID: BSI-DSZ-CC-0332-2007 Signaturbestätigungs-ID: BSI.02071.TE.xx.2007, T-Systems GEI GmbH (vertrauliches Dokument) [8] Konfigurationsliste für den EVG, Datei "VPS2226-configurationlist.txt", 12.09.2007, bremen online services GmbH & Co. KG (vertrauliches Dokument) [9] Benutzer- und Betriebshandbuch Prüftool, Version 2.3.4, 06.09. 2007; bremen online services GmbH & Co., KG B-16 BSI-DSZ-CC-0332-2007 Zertifizierungsreport [10] Betriebshandbuch, Dokument-Version 2.2.5, 06.09.2007; bremen online services GmbH & Co. KG [11] Benutzerhandbuch der Verifikationsanwendung, Dokument-Version 2.2.5, 06.09.2007; bremen online services GmbH & Co. KG [12] Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der Signaturverordnung (Übersicht über geeignete Algorithmen) vom 22. Februar 2007, Veröffentlicht am 12. April 2007 im Bundesanzeiger Nr. 69, S. 3759 [13] Gesetz über Rahmenbedingungen für elektronische Signaturen (Signaturgesetz - SigG)1) vom 16. Mai 2001 (BGBl. I S. 876) zuletzt geändert durch Art. 1 des Ersten Gesetzes zur Änderung des Signaturgesetzes (1. SigÄndG), 01/04/2005, BGBl. volume 2005 part I p. 2 [14] Verordnung zur elektronischen Signatur (Signaturverordnung - SigV), 11/16/2001, BGBl. volume 2001 part I p. 876 [15] Einheitliche Spezifizierung der Einsatzbedingungen für Signaturanwendungskomponenten – Arbeitsgrundlage für Entwickler/Hersteller und Prüf-/Bestätigungsstellen, Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (Bundesnetzagentur), Version 1.4, 19.07.2005 D B-17 BSI-DSZ-CC-0332-2007 Zertifizierungsreport C Auszüge aus den Kriterien Anmerkung: Die folgenden Auszüge aus den technischen Regelwerken wurden aus der englischen Originalfassung der CC Version 2.3 entnommen, da eine vollständige aktuelle Übersetzung nicht vorliegt. CC Part1: Conformance results (chapter 7.4) „The conformance result indicates the source of the collection of requirements that is met by a TOE or PP that passes its evaluation. This conformance result is presented with respect to CC Part 2 (functional requirements), CC Part 3 (assurance requirements) and, if applicable, to a pre-defined set of requirements (e.g., EAL, Protection Profile). The conformance result consists of one of the following: – CC Part 2 conformant - A PP or TOE is CC Part 2 conformant if the functional requirements are based only upon functional components in CC Part 2. – CC Part 2 extended - A PP or TOE is CC Part 2 extended if the functional requirements include functional components not in CC Part 2. plus one of the following: – CC Part 3 conformant - A PP or TOE is CC Part 3 conformant if the assurance requirements are based only upon assurance components in CC Part 3. – CC Part 3 extended - A PP or TOE is CC Part 3 extended if the assurance requirements include assurance requirements not in CC Part 3. Additionally, the conformance result may include a statement made with respect to sets of defined requirements, in which case it consists of one of the following: – Package name Conformant - A PP or TOE is conformant to a pre-defined named functional and/or assurance package (e.g. EAL) if the requirements (functions or assurance) include all components in the packages listed as part of the conformance result. – Package name Augmented - A PP or TOE is an augmentation of a pre- defined named functional and/or assurance package (e.g. EAL) if the requirements (functions or assurance) are a proper superset of all components in the packages listed as part of the conformance result. Finally, the conformance result may also include a statement made with respect to Protection Profiles, in which case it includes the following: – PP Conformant - A TOE meets specific PP(s), which are listed as part of the conformance result.“ C-1 Zertifizierungsreport BSI-DSZ-CC-0332-2007 CC Part 3: Protection Profile criteria overview (chapter 8.2) “The goal of a PP evaluation is to demonstrate that the PP is complete, consistent, technically sound, and hence suitable for use as a statement of requirements for one or more evaluatable TOEs. Such a PP may be eligible for inclusion within a PP registry.” “Assurance Class Assurance Family TOE description (APE_DES) Security environment (APE_ENV) Class APE: Protection Profile evaluation PP introduction (APE_INT) Security objectives (APE_OBJ) IT security requirements (APE_REQ) Explicitly stated IT security requirements (APE_SRE) Table 3 - Protection Profile families - CC extended requirements ” Security Target criteria overview (Chapter 8.3) “The goal of an ST evaluation is to demonstrate that the ST is complete, consistent, technically sound, and hence suitable for use as the basis for the corresponding TOE evaluation.” “Assurance Class Assurance Family TOE description (ASE_DES) Security environment (ASE_ENV) ST introduction (ASE_INT) Class ASE: Security Target evaluation Security objectives (ASE_OBJ) PP claims (ASE_PPC) IT security requirements (ASE_REQ) Explicitly stated IT security requirements (ASE_SRE) TOE summary specification (ASE_TSS) Table 5 - Security Target families - CC extended requirements ” C-2 BSI-DSZ-CC-0332-2007 Zertifizierungsreport Assurance categorisation (chapter 7.5) “The assurance classes, families, and the abbreviation for each family are shown in Table 1. Assurance Class Assurance Family CM automation (ACM_AUT) ACM: Configuration management CM capabilities (ACM_CAP) CM scope (ACM_SCP) ADO: Delivery and operation Delivery (ADO_DEL) Installation, generation and start-up (ADO_IGS) Functional specification (ADV_FSP) High-level design (ADV_HLD) Implementation representation (ADV_IMP) ADV: Development TSF internals (ADV_INT) Low-level design (ADV_LLD) Representation correspondence (ADV_RCR) Security policy modeling (ADV_SPM) AGD: Guidance documents Administrator guidance (AGD_ADM) User guidance (AGD_USR) Development security (ALC_DVS) ALC: Life cycle support Flaw remediation (ALC_FLR) Life cycle definition (ALC_LCD) Tools and techniques (ALC_TAT) Coverage (ATE_COV) ATE: Tests Depth (ATE_DPT) Functional tests (ATE_FUN) Independent testing (ATE_IND) Covert channel analysis (AVA_CCA) AVA: Vulnerability assessment Misuse (AVA_MSU) Strength of TOE security functions (AVA_SOF) Vulnerability analysis (AVA_VLA) Table 1: Assurance family breakdown and mapping” C-3 Zertifizierungsreport BSI-DSZ-CC-0332-2007 Evaluation assurance levels (chapter 11) “The Evaluation Assurance Levels (EALs) provide an increasing scale that balances the level of assurance obtained with the cost and feasibility of acquiring that degree of assurance. The CC approach identifies the separate concepts of assurance in a TOE at the end of the evaluation, and of maintenance of that assurance during the operational use of the TOE. It is important to note that not all families and components from CC Part 3 are included in the EALs. This is not to say that these do not provide meaningful and desirable assurances. Instead, it is expected that these families and components will be considered for augmentation of an EAL in those PPs and STs for which they provide utility.” Evaluation assurance level (EAL) overview (chapter 11.1) “Table 6 represents a summary of the EALs. The columns represent a hierarchically ordered set of EALs, while the rows represent assurance families. Each number in the resulting matrix identifies a specific assurance component where applicable. As outlined in the next section, seven hierarchically ordered evaluation assurance levels are defined in the CC for the rating of a TOE's assurance. They are hierarchically ordered inasmuch as each EAL represents more assurance than all lower EALs. The increase in assurance from EAL to EAL is accomplished by substitution of a hierarchically higher assurance component from the same assurance family (i.e. increasing rigour, scope, and/or depth) and from the addition of assurance components from other assurance families (i.e. adding new requirements). These EALs consist of an appropriate combination of assurance components as described in chapter 7 of this Part 3. More precisely, each EAL includes no more than one component of each assurance family and all assurance dependencies of every component are addressed. While the EALs are defined in the CC, it is possible to represent other combinations of assurance. Specifically, the notion of “augmentation” allows the addition of assurance components (from assurance families not already included in the EAL) or the substitution of assurance components (with another hierarchically higher assurance component in the same assurance family) to an EAL. Of the assurance constructs defined in the CC, only EALs may be augmented. The notion of an “EAL minus a constituent assurance component” is not recognised by the standard as a valid claim. Augmentation carries with it the obligation on the part of the claimant to justify the utility and added value of the added assurance component to the EAL. An EAL may also be extended with explicitly stated assurance requirements. C-4 BSI-DSZ-CC-0332-2007 Zertifizierungsreport Assurance Class Assurance Family Assurance Components by Evaluation Assurance Level EAL1 EAL2 EAL3 EAL4 EAL5 EAL6 EAL7 Configuration management ACM_AUT 1 1 2 2 ACM_CAP 1 2 3 4 4 5 5 ACM_SCP 1 2 3 3 3 Delivery and operation ADO_DEL 1 1 2 2 2 3 ADO_IGS 1 1 1 1 1 1 1 Development ADV_FSP 1 1 1 2 3 3 4 ADV_HLD 1 2 2 3 4 5 ADV_IMP 1 2 3 3 ADV_INT 1 2 3 ADV_LLD 1 1 2 2 ADV_RCR 1 1 1 1 2 2 3 ADV_SPM 1 3 3 3 Guidance documents AGD_ADM 1 1 1 1 1 1 1 AGD_USR 1 1 1 1 1 1 1 Life cycle support ALC_DVS 1 1 1 2 2 ALC_FLR ALC_LCD 1 2 2 3 ALC_TAT 1 2 3 3 Tests ATE_COV 1 2 2 2 3 3 ATE_DPT 1 1 2 2 3 ATE_FUN 1 1 1 1 2 2 ATE_IND 1 2 2 2 2 2 3 Vulnerability assessment AVA_CCA 1 2 2 AVA_MSU 1 2 2 3 3 AVA_SOF 1 1 1 1 1 1 AVA_VLA 1 1 2 3 4 4 Table 6: Evaluation assurance level summary” C-5 Zertifizierungsreport BSI-DSZ-CC-0332-2007 Evaluation assurance level 1 (EAL1) - functionally tested (chapter 11.3) “Objectives EAL1 is applicable where some confidence in correct operation is required, but the threats to security are not viewed as serious. It will be of value where independent assurance is required to support the contention that due care has been exercised with respect to the protection of personal or similar information. EAL1 provides an evaluation of the TOE as made available to the customer, including independent testing against a specification, and an examination of the guidance documentation provided. It is intended that an EAL1 evaluation could be successfully conducted without assistance from the developer of the TOE, and for minimal outlay. An evaluation at this level should provide evidence that the TOE functions in a manner consistent with its documentation, and that it provides useful protection against identified threats.” Evaluation assurance level 2 (EAL2) - structurally tested (chapter 11.4) “Objectives EAL2 requires the co-operation of the developer in terms of the delivery of design information and test results, but should not demand more effort on the part of the developer than is consistent with good commercial practice. As such it should not require a substantially increased investment of cost or time. EAL2 is therefore applicable in those circumstances where developers or users require a low to moderate level of independently assured security in the absence of ready availability of the complete development record. Such a situation may arise when securing legacy systems, or where access to the developer may be limited.” Evaluation assurance level 3 (EAL3) - methodically tested and checked (chapter 11.5) “Objectives EAL3 permits a conscientious developer to gain maximum assurance from positive security engineering at the design stage without substantial alteration of existing sound development practices. EAL3 is applicable in those circumstances where developers or users require a moderate level of independently assured security, and require a thorough investigation of the TOE and its development without substantial re- engineering.” C-6 BSI-DSZ-CC-0332-2007 Zertifizierungsreport Evaluation assurance level 4 (EAL4) - methodically designed, tested, and reviewed (chapter 11.6) “Objectives EAL4 permits a developer to gain maximum assurance from positive security engineering based on good commercial development practices which, though rigorous, do not require substantial specialist knowledge, skills, and other resources. EAL4 is the highest level at which it is likely to be economically feasible to retrofit to an existing product line. EAL4 is therefore applicable in those circumstances where developers or users require a moderate to high level of independently assured security in conventional commodity TOEs and are prepared to incur additional security- specific engineering costs.” Evaluation assurance level 5 (EAL5) - semiformally designed and tested (chapter 11.7) “Objectives EAL5 permits a developer to gain maximum assurance from security engineering based upon rigorous commercial development practices supported by moderate application of specialist security engineering techniques. Such a TOE will probably be designed and developed with the intent of achieving EAL5 assurance. It is likely that the additional costs attributable to the EAL5 requirements, relative to rigorous development without the application of specialised techniques, will not be large. EAL5 is therefore applicable in those circumstances where developers or users require a high level of independently assured security in a planned development and require a rigorous development approach without incurring unreasonable costs attributable to specialist security engineering techniques.” Evaluation assurance level 6 (EAL6) - semiformally verified design and tested (chapter 11.8) “Objectives EAL6 permits developers to gain high assurance from application of security engineering techniques to a rigorous development environment in order to produce a premium TOE for protecting high value assets against significant risks. EAL6 is therefore applicable to the development of security TOEs for application in high risk situations where the value of the protected assets justifies the additional costs.” C-7 Zertifizierungsreport BSI-DSZ-CC-0332-2007 C-8 Evaluation assurance level 7 (EAL7) - formally verified design and tested (chapter 11.9) “Objectives EAL7 is applicable to the development of security TOEs for application in extremely high risk situations and/or where the high value of the assets justifies the higher costs. Practical application of EAL7 is currently limited to TOEs with tightly focused security functionality that is amenable to extensive formal analysis.“ Strength of TOE security functions (AVA_SOF) (chapter 19.3) “Objectives Even if a TOE security function cannot be bypassed, deactivated, or corrupted, it may still be possible to defeat it because there is a vulnerability in the concept of its underlying security mechanisms. For those functions a qualification of their security behaviour can be made using the results of a quantitative or statistical analysis of the security behaviour of these mechanisms and the effort required to overcome them. The qualification is made in the form of a strength of TOE security function claim.” Vulnerability analysis (AVA_VLA) (chapter 19.4) "Objectives Vulnerability analysis is an assessment to determine whether vulnerabilities identified, during the evaluation of the construction and anticipated operation of the TOE or by other methods (e.g. by flaw hypotheses), could allow users to violate the TSP. Vulnerability analysis deals with the threats that a user will be able to discover flaws that will allow unauthorised access to resources (e.g. data), allow the ability to interfere with or alter the TSF, or interfere with the authorised capabilities of other users.” "Application notes A vulnerability analysis is performed by the developer in order to ascertain the presence of security vulnerabilities, and should consider at least the contents of all the TOE deliverables including the ST for the targeted evaluation assurance level. The developer is required to document the disposition of identified vulnerabilities to allow the evaluator to make use of that information if it is found useful as a support for the evaluator's independent vulnerability analysis.” “Independent vulnerability analysis goes beyond the vulnerabilities identified by the developer. The main intent of the evaluator analysis is to determine that the TOE is resistant to penetration attacks performed by an attacker possessing a low (for AVA_VLA.2 Independent vulnerability analysis), moderate (for AVA_VLA.3 Moderately resistant) or high (for AVA_VLA.4 Highly resistant) attack potential.” BSI-DSZ-CC-0332-2007 Zertifizierungsreport D Anhänge Liste der Anhänge zu diesem Zertifizierungsreport Anhang A: Die Sicherheitsvorgaben [6] werden in einem eigenen Dokument zur Verfügung gestellt. D-1 Zertifizierungsreport BSI-DSZ-CC-0332-2007 D-2 Dies ist eine eingefügte Leerseite.