BSI-DSZ-CC-0330-2007
zu
Virtuelle Poststelle des Bundes (OSCI)
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-0330-2007
Signaturanwendungskomponente
Virtuelle Poststelle des Bundes (OSCI)
Version 2.2.2.6
von bremen online services GmbH & Co. KG
im Auftrag des 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
EAL 4
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-0330-2007
IV
Dies ist eine eingefügte Leerseite.
BSI-DSZ-CC-0330-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-0330-2007
VI
Gliederung
Teil A: Zertifizierung
Teil B: Zertifizierungsbericht
Teil C: Auszüge aus den technischen Regelwerken
Teil D: Anhänge
BSI-DSZ-CC-0330-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 Methodology 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. Zertifikate der Unterzeichnerstaaten werden
damit in den jeweils anderen Unterzeichnerstaaten anerkannt.
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-0330-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-0330-2007 Zertifizierungsreport
Das Produkt Virtuelle Poststelle des Bundes (OSCI), 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 (OSCI), 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 Produkt wird über das geprüfte Auslieferungsverfahren ausgeliefert.
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
ein Maintenance Verfahren) in Übereinstimmung mit den entsprechenden
Regeln beantragt und die Evaluierung keine Schwächen aufdeckt.
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.
6
Information Technology Security Evaluation Facility
A-3
Zertifizierungsreport BSI-DSZ-CC-0330-2007
A-4
5 Veröffentlichung
Der nachfolgende Zertifizierungsbericht enthält die Seiten B-1 bis B-26 und D-1
bis D-2.
Das Produkt Virtuelle Poststelle des Bundes (OSCI), 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 werden7
. 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-0330-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-0330-2007
Gliederung des Zertifizierungsberichtes
1 Zusammenfassung 3
2 Identifikation des EVG 6
3 Sicherheitspolitik 8
4 Annahmen und Klärung des Einsatzbereiches 8
5 Informationen zur Architektur 9
6 Dokumentation 11
7 Testverfahren 11
8 Evaluierte Konfiguration 13
9 Ergebnis der Evaluierung 13
9.1 CC spezifische Ergebnisse 13
9.2 Ergebnis der kryptographischen Bewertung 14
10 Auflagen und Hinweise zur Benutzung des EVG 15
11 Sicherheitsvorgaben 22
12 Definitionen 22
12.1 Abkürzungen 22
12.2 Glossar 23
13 Literaturangaben 24
B-2
BSI-DSZ-CC-0330-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 Gegenstand dieses Zertifikats) und Virtuelle Poststelle des
Bundes (Verifikationsmodul) bzw. Verifikationsmodul (EVG 3, orange markiert
in Abbildung 1) 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-
sierungs-
anwendung
Authentifizierungs-
server
Verifikations-
anwendung
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-0330-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.
Das Verifikationsmodul (EVG 3) umfasst eine Signaturanwendungskomponente
für das Verifizieren von Signaturen und Zertifikaten am Arbeitsplatz des
Endnutzers. Diese besteht aus einer Serverkomponente (Verifikationsserver)
und einem dazugehörigen Client (Verifikationsanwendung).
Gegenstand dieses Zertifikats ist die OSCI-Komponente (EVG 2). Der EVG 2
beinhaltet die folgenden Anteile (siehe auch Kapitel 2 in diesem Report):
• Eine Funktionsbibliothek (OSCI-Client-Enabler) zur Integration in eine
Client-Software, mit der die sichere Anzeige und das Signieren von
Dokumenten am Arbeitsplatz sowie die Kommunikation über das OSCI-
Protokoll zur Verfügung gestellt wird.
• Ein Prüftool, das über einen Browser vom Endbenutzer aufgerufen werden
kann und die Integrität des OSCI-Client-Enablers überprüft.
• Eine Funktionsbibliothek (OSCI-Backend-Enabler) zur Integration in
Fachverfahren, so dass diese Fachverfahren signaturgesetzkonform über
das OSCI-Protokoll mit der Basiskomponente kommunizieren. Dabei werden
die Fachverfahren in einer geschützten Einsatzumgebung betrieben.
• Die zentrale Serverkomponente für den Betrieb einer OSCI-konformen IT-
Infrastruktur (OSCI-Manager), die zusammen mit der Basiskomponente in
einem vertrauenswürdigen Netz eingesetzt wird.
Der OSCI-Client-Enabler und der –Backend-Enabler müssen entsprechend den
Vorgaben der evaluierten Benutzerdokumentation in geeignete Programme
eingebunden und zusammen mit geeigneter Hardware – insbesondere mit
SigG-konformen Chipkartenlesern und sicheren Signaturerstellungseinheiten –
entsprechend den Annahmen an die jeweilige Einsatzumgebung betrieben
werden.
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 Zusatzvon 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.1
beschrieben. Sie wurden dem Teil 2 der Common Criteria entnommen und
B-4
BSI-DSZ-CC-0330-2007 Zertifizierungsreport
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.2 dargestellt.
Die funktionalen Sicherheitsanforderungen werden durch die folgenden
Sicherheitsfunktionen des EVG umgesetzt:
Sicherheitsfunktion
des EVG
Thema
SF1 Unterstützung bei der Erzeugung qualifizierter elektronischer
Signaturen
Hierunter fällt insbesondere das Bilden von Hashwerten zu
Dokumenten und Zuführen der Hashwerte zu einer sicheren
Signaturerstellungseinheit.
SF2 Schutz gegen Hashwertmanipulation
Der OSCI-Client-Enabler prüft die von einer sicheren
Signaturerstellungseinheit erzeugte Signatur mathematisch nach
um sicherzustellen, dass der Hashwert nicht manipuliert worden
ist.
SF3 Verifikation einer qualifizierten elektronischen Signatur
Der OSCI-Client- und –Backend-Enabler prüfen qualifizierte
elektronische Signaturen unter Zuhilfenahme des RSA-Algorithmus
mit Bitlängen von 1024 und 2048 Bit sowie dem Hashalgorithmus
SHA-1. Mit Hilfe der Sicherheitsfunktion SF 6 werden die
zugehörigen qualifizierten Zertifikate validiert.
SF4 Verifikation eines OSCI-Laufzettels bei der Validierung eines
qualifizierten Zertifikats
Im Rahmen des OSCI-Protokolls fertigt der OSCI-Manger einen
signierten OSCI-Laufzettel zur Dokumentation durchgeführter
Prüfungen an (s. SF6). OSCI-Client und –Backend-Enabler prüfen
die Signatur mathematisch anhand von hinterlegten Zertifikaten
nach.
SF5 Sichere und zuverlässige Anzeige
Der OSCI-Client-Enabler bietet eine sichere Anzeige für Text-
Dateien und stellt weitere Anzeigefunktionen gemäß
Signaturgesetz §17, Abs. 2 (wie z.B. die Inhalte des zugehörigen
qualifizierten Zertifikats) zur Verfügung.
SF6 Unterstützung bei der Validierung qualifizierter Zertifikate
Der OSCI-Manager übergibt zu validierende qualifizierte Zertifikate
an die Basiskomponente der Virtuellen Poststelle (siehe Abbildung
1) und wertet das Ergebnis selber aus. Die Auswertung der
Prüfung trägt der OSCI-Manager gemäß dem OSCI-Protokoll in
den OSCI-Laufzettel ein und lässt ihn durch die Basiskomponente
signieren. Der Laufzettel wird durch die dezentralen Komponenten
OSCI-Client- bzw. –Backend-Enabler geprüft (s. SF4).
B-5
Zertifizierungsreport BSI-DSZ-CC-0330-2007
Sicherheitsfunktion
des EVG
Thema
SF7 Identifikation und Authentisierung
Der Zugriff auf die Administration des OSCI-Managers über eine
Webschnittstelle ist nur nach erfolgreicher Identifikation und
Authentisierung möglich.
SF8 Prüftool
Mit Hilfe des Prüftools ist es möglich, die Integrität des dezentral
auf Arbeitsplatzrechnern eingesetzten OSCI-Client-Enablers zu
überprüfen.
Tabelle 1: Sicherheitsfunktionen des EVG
Mehr Details sind in den Sicherheitsvorgaben [6], Kapitel 6 dargestellt.
Die Stärke „hoch” der Funktionen des EVG für bestimmte Funktionen, wie in
den Sicherheitsvorgaben [6], Kapitel 8.3.4 angegeben, 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.
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 (OSCI), Version 2.2.2.68
Die folgende Tabelle beschreibt den Auslieferungsumfang:
8
In diesem Report auch OSCI-Komponente genannt.
B-6
BSI-DSZ-CC-0330-2007 Zertifizierungsreport
Nr. System Art Teil Version Datum Art der
Auslieferung
1 Software VPS OSCI 2.2.2.6 06.09.2007 auf CD-ROM
oder als
Download
2
OSCI-
Manager
Dokument Betriebshandbuch [10] 2.2.5 06.09.2007 pdf-Datei auf
CD-ROM oder
als Download
3 Software VPS OSCI 2.2.2.6 06.09.2007 auf CD-ROM
oder als
Download
4
OSCI-Client-
Enabler
OSCI-
Backend-
Enabler
Doku. Entwicklerhandbuch
[11]
2.3.2 06.09.2007 pdf-Datei auf
CD-ROM oder
als Download
5 Software VPS OSCI 2.2.2.6 06.09.2007 auf CD-ROM
oder als
Download
6
Prüftool
Doku. Benutzer- und
Betriebshandbuch
Prüftool [9]
2.3.4 06.09.2007 pdf-Datei auf
CD-ROM oder
als Download
Tabelle 2: Auslieferungsumfang des EVG
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 bzw.
Anwendungsentwickler 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 bzw. Anwendungsentwickler 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 ist dafür verantwortlich, dem Endbenutzer das Prüftool sowie die
Funktionsbibliotheken für den OSCI-Client bzw. –Backend-Enabler über eine
mit SSL gesicherte Verbindung zur Verfügung zu stellen. Weiterhin stellt der
B-7
Zertifizierungsreport BSI-DSZ-CC-0330-2007
Betreiber dem Endbenutzer die zur Konfiguration des OSCI-Client-Enabler
benötigte Adresse des OSCI-Managers sowie dessen Zertifikat zur Verfügung.
Die Authentizität des Prüftools wird weiterhin durch die Signatur des Applets mit
Hilfe eines fortgeschrittenen Zertifikats sichergestellt, dessen zugehöriger
geheimer Schlüssel ausschließlich beim Hersteller vertrauenswürdig verwahrt
und angewendet wird. Der Endbenutzer kann mit Hilfe des Prüftools
überprüfen, ob er den authentischen OSCI-Client-Enabler erhalten hat.
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 ermöglicht es, die Erzeugung einer qualifizierten elektronischen
Signatur vorher eindeutig anzuzeigen und feststellen zu lassen, auf welche
Daten sich die Signatur bezieht.
• 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.
• Mit Unterstützung der Basiskomponente der Virtuellen Poststelle ist der
EVG in der Lage, die Gültigkeit einer qualifizierten elektronischen Signatur
zur prüfen und das Ergebnis der Prüfung anzuzeigen.
• 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 ob sie 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 sichere
B-8
BSI-DSZ-CC-0330-2007 Zertifizierungsreport
Signaturerstellungseinheiten mit qualifizierten Zertifikaten und unterstützte
Chipkartenleser. Zur Absicherung der Kommunikation werden Server-
Zertifikate mit geeigneten kryptographischen Verfahren bereitgestellt.
• 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 OSCI-Manager
zusammen mit der Basiskomponente und entsprechenden Fachverfahren in
einem vertrauenswürdigen Netz so betreibt und sicherstellt, dass die
Auflagen aus [15] an einen „geschützten Einsatzbereich
(Regelfall/Standardlösung)“ umgesetzt werden.
• Die IT-Umgebung muss einen OSCI-Client- oder –Backend-Enabler zur
Verfügung stellen, welche die entsprechenden Funktionsbibliotheken des
EVG gemäß der Benutzerdokumentation nutzen und die Anforderungen von
Signaturgesetz und -verordnung an eine Signaturanwendungskomponente
umsetzen. Insbesondere gewährleisten sie die Funktionalitäten hinsichtlich
Identifikation und Authentisierung zum Management von
Sicherheitsattributen, d. h. den kryptographischen Schlüsseln und den
(System-) Zertifikaten.
• Der Endnutzer des OSCI-Clients gibt seine Identifikationsmerkmale nicht
preis. Er betreibt den EVG in einer Umgebung, in der ein Zugriff Unbefugter
ausgeschlossen ist oder zumindest mit hoher Sicherheit erkennbar wird und
die Anforderungen an einen geschützten Einsatzbereich gemäß [15] in einer
Home- oder Büroumgebung umgesetzt werden.
Details finden sich in den Sicherheitsvorgaben [6], Kapitel 3.
5 Informationen zur Architektur
Die OSCI-Komponente besteht aus den folgenden Teilsystemen:
• OSCI-Client-Enabler (Sub_1 in Abbildung 2)
• OSCI-Backend-Enabler (Sub_2 in Abbildung 2),
• OSCI-Manager (Sub_3 in Abbildung 2),
• Administrationsanwendung (Sub_4 in Abbildung 2) und
• Prüfwerkzeug (auch Prüftool genannt, Sub_5 in Abbildung 2).
Die Aufteilung in die obigen Teilsysteme ergibt sich aus der Architektur und der
OSCI-Kommunikation, bei der ein OSCI-Client, ein –Intermediär und ein –
Backend gefordert wird. Diese Rollen werden wie folgt durch die Teilsysteme
belegt:
• OSCI-Client-Enabler für einen OSCI-Client,
• OSCI-Manager für den OSCI-Intermediär,
B-9
Zertifizierungsreport BSI-DSZ-CC-0330-2007
• OSCI-Backend-Enabler für ein OSCI-Backend.
Hierbei ist zur Realisierung des OSCI-Intermediärs neben dem OSCI-Manager
zusätzlich eine SigG-konforme Basiskomponente der Virtuellen Poststelle des
Bundes notwendig. Die Administrationsanwendung ist für die Bedienung des
OSCI-Managers zuständig. Das Prüftool wird zum Schutz vor unbefugter
Veränderung des OSCI-Client-Enablers eingesetzt.
Der EVG stellt folgende Funktionen zur Verfügung:
• Der OSCI-Client-Enabler ist eine Funktionsbibliothek, die von einem OSCI-
Client angesprochen wird und insbesondere folgende Dienste zur Verfügung
stellt:
– Unterstützung bei der Erzeugung qualifizierter elektronischer Signaturen;
– mathematische Prüfung qualifizierter elektronischer Signaturen
(Verifikation);
– mathematische Prüfung elektronischer Signaturen des OSCI-Laufzettels
(im Rahmen der Validierung);
– sichere Anzeige von zu signierenden und signierten Daten sowie
Verifikations- und Validierungsergebnissen.
• Der OSCI-Backend-Enabler ist eine Funktionsbibliothek, die von einem
OSCI-Backend angesprochen wird und insbesondere folgende Dienste zur
Verfügung stellt:
– mathematische Prüfung qualifizierter elektronischer Signaturen
(Verifikation);
– mathematische Prüfung elektronischer Signaturen des OSCI-Laufzettels
(im Rahmen der Validierung).
• Der OSCI-Manager stellt folgende Funktionalitäten zur Verfügung:
– Unterstützung bei der Validierung qualifizierter elektronischer Signaturen
mit Hilfe der Basiskomponente;
– Unterstützung bei der Erzeugung einer elektronischen Signatur für den
OSCI-Laufzettel mit Hilfe der Basiskomponente.
• Die Administrationsanwendung dient zur Administration des OSCI-
Managers. Sie erfolgt über dieselbe Browser-basierte
Administrationsanwendung, die auch für die Administration und Bedienung
der Basiskomponente genutzt wird.
• Der OSCI-Client-Enabler wird durch das Prüftool vor unbefugter
Veränderung geschützt (Integritätsschutz). Dazu wird die Integrität der JAR-
Files des OSCI-Client-Enablers geprüft.
Die Aufteilung des EVG in die entsprechenden Subsysteme zeigt auch die
folgende Abbildung.
B-10
BSI-DSZ-CC-0330-2007 Zertifizierungsreport
Abbildung 2: Aufteilung des EVG2 in Subsysteme
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 OSCI-Manager und OSCI-Backend Enabler
B-11
Zertifizierungsreport BSI-DSZ-CC-0330-2007
Hard- und Software der Clientkomponente:
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 des OSCI-Client-Enablers
Die erfolgreich getesteten Kombinationen von Betriebssystem, Chipkartenleser
und sicheren Signaturerstellungseinheiten sind im Kapitel 10 aufgeführt.
Die Testdokumentation zeigt, dass die Tests sowohl auf der Ebene der
Teilsysteme des EVGs als auch auf 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 sowie einige der in Kapitel 10 genannten Kombinationen von
Betriebssystem, Chipkartenleser und sicherer Signaturerstellungseinheit
verwendet:
Betriebssysteme Hardware Sonstiges
Suse Enterprise 9 i386-Architektur (Intel Xeon o.ä) • Java: SUN 1.4.2 JDK
• Application Server: JBoss 3.2.8
• Datenbank: MySQL 4.1
Windows Server 2003 i386-Architektur (Intel Xeon o.ä) • Java: SUN 1.4.2 JDK
• Application Server: JBoss 3.2.8
• Datenbank: MySQL 4.1
Tabelle 5: Testkonfiguration der Prüfstelle für die OSCI-Manager und OSCI-Backend-Enabler
Betriebssysteme Hardware Sonstiges
Windows XP i386-Architektur (Intel Xeon o.ä) • Java: SUN 1.4.2
• Application Server: JBoss 3.2.8
• Datenbank: MySQL 4.1
Tabelle 6: Testkonfiguration der Prüfstelle für den OSCI-Client-Enabler
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:
B-12
BSI-DSZ-CC-0330-2007 Zertifizierungsreport
• 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 (nachvollzogene
Herstellertests und unabhängige 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
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 Evaluation Technical Report (ETR), [7] wurde von der Prüfstelle gemäß den
Common Criteria [1], der Methodology [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 definierte Methodologie verwendet [4, AIS 34].
Das Urteil PASS der Evaluierung wird für die folgenden
Vertrauenswürdigkeitskomponenten bestätigt:
• Alle Komponenten der Klasse ASE
B-13
Zertifizierungsreport BSI-DSZ-CC-0330-2007
• 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 folgende Sicherheitsfunktion erfüllt die behauptete Stärke der Funktion
hoch:
• SF7 Identifikation und Authentisierung
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:
– Hashfunktionen:
• SHA-1
– Signaturalgorithmen:
• RSA mit einem Modulus (Bitlänge) von 1024 und 2048 Bit
Dies gilt für die folgenden Sicherheitsfunktionen:
– SF1 Unterstützung bei der Erzeugung qualifizierter elektronischer
Signaturen
– SF2 Schutz gegen Hashwertmanipulation
– SF3 Verifikation einer qualifizierten elektronischen Signatur
– SF4 Verifikation eines OSCI-Laufzettels bei der Validierung eines
qualifizierten Zertifikats
– SF6 Unterstützung bei der Validierung qualifizierter Zertifikate
– SF8 Prüftool
B-14
BSI-DSZ-CC-0330-2007 Zertifizierungsreport
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 Dokumente [9] - [11] aus Tabelle 2 enthalten die notwendigen
Informationen über die Verwendung des EVG und alle Sicherheitshinweise sind
darin enthalten.
10.1 Empfehlungen und Hinweise an den Anwender
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.
Benutzer eines OSCI-Clients oder OSCI-Backends sollten beachten, dass zum
Signieren, zur Signaturprüfung und zur Anzeige von signierten oder zu
signierenden Daten nur solche OSCI-Clients oder OSCI-Backends (allgemein:
Signaturanwendungskomponenten) benutzt werden, die nach den Vorgaben
des Signaturgesetzes und der Signaturverordnung evaluiert und
sicherheitsbestätigt wurden.
Vor jeder Inbetriebnahme eines OSCI-Clients sollte die Integrität des OSCI-
Client-Enablers und ggf. des OSCI-Clients mit dem Prüfwerkzeug geprüft
werden. Bei negativen Prüfergebnissen darf die jeweilige Komponente nicht in
Betrieb genommen werden.
Die für den OSCI-Manager vorzunehmenden Konfigurationseinstellungen zur
Verbindung mit dem Kernsystem und den anzubringenden Signaturen sollten
vor Inbetriebnahme explizit auf ihre Richtigkeit überprüft 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:
• 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
B-15
Zertifizierungsreport BSI-DSZ-CC-0330-2007
10.3 Unterstützung von Chipkartenlesern und sicheren
Signaturerstellungseinheiten
Die folgenden Tabellen zeigen die Kombinationen aus Betriebssystemen,
Chipkartenlesern und sicheren Signaturerstellungseinheiten, die erfolgreich
getestet worden und daher Bestandteil dieses Zertifikats sind. Der Wert „OK“ in
einer Spalte zeigt dabei, dass die entsprechende Kombination funktionsfähig
ist. Der Wert „F“ zeigt, dass die Tests nicht erfoglreich ausgeführt werden
konnten.
Windows XP
Kartenbezeichnung und Bestätigungsnummer Kartenleser
ReinerSCT
e:com
Kartenleser
ReinerSCT
PinPad
Kartenleser
Kobil
KAAN Pro
Telesec Signaturkarte PKS-Card, Version 3.0
(TUVIT.09339.TE.12.2000)
OK OK OK
Telesec Signaturkarte E4NetKeyCard, Version
3.0
(TUVIT.09339.TE.12.2000 (1. Nachtrag))
OK OK OK
Telesec Signaturkarte PKS-Card, Version 3.01
(TUVIT.09339.TE.12.2000 (2. Nachtrag))
OK OK OK
Telesec Signaturkarte E4NetKeyCard, Version
3.01
(TUVIT.09339.TE.12.2000 (2. Nachtrag))
OK OK OK
Telesec Signaturkarte E4NetKeyCard, Version
3.01
(TUVIT.09339.TE.12.2000 (2. Nachtrag))
OK OK OK
DATEV Signaturkarte e:secure-Card Version 1.10
(TUVIT.09341.TE.03.2001 (Nachtrag vom
25.02.2004))
OK OK OK
DATEV Signaturkarte e:secure-Card Version 1.20
(TUVIT.09341.TE.03.2001 (Nachtrag vom
25.02.2004))
OK OK OK
Signtrust Signaturkarte SEA-Card, Version 2.0
(TUVIT.09346.TU.03.2001)
OK OK OK
Signtrust Signaturkarte SEA-Card, Version 2.01
(TUVIT.09346.TU.03.2001 (Nachtrag vom
09.05.2006))
OK OK OK
Signtrust Signaturkarte SEA-Card, Version 2.01
(TUVIT.09346.TU.03.2001 (Nachtrag vom
09.05.2006))
OK OK OK
B-16
BSI-DSZ-CC-0330-2007 Zertifizierungsreport
Windows XP
Kartenbezeichnung und Bestätigungsnummer Kartenleser
ReinerSCT
e:com
Kartenleser
ReinerSCT
PinPad
Kartenleser
Kobil
KAAN Pro
Signaturkarte D-TRUST-CARD, Version 1.1
(TUVIT.09361.TE.10.2001 (Nachtrag vom
24.03.2004))
OK OK OK
Signaturerstellungseinheit "Prozessorchipkarte
mit Prozessor P8WE5032V0G und STARCOS
SPK 2.3 v 7.0 with Digital Signature Application
StarCert v 2.2"
(T-Systems.02078.TE.12.2001)
OK OK OK
Signaturerstellungseinheit „Chipkarte mit
Prozessor SLE66CX322P, Betriebssystem
CardOS V4.3B mit Applikation für digitale
Signatur“
(T-Systems.02122.TE.05.2005)
OK OK OK
Signaturerstellungseinheit ZKA-Signaturkarte,
Version 5.02 der Gemplus-mids GmbH
(TUVIT.09385.TU.09.2004)
OK OK F
Signaturerstellungseinheit ZKA Banking Signature
Card, Version 6.2b NP und 6.2f NP, Type 3 der
Giesecke & Devrient GmbH
(TUVIT.09395.TU.01.2005)
OK OK F
Signaturerstellungseinheit ZKA Banking Signature
Card, Version 6.31 NP, Type 3 der Giesecke &
Devrient GmbH (TUVIT.09397.TU.03.2005)
OK OK F
Signaturerstellungseinheit ZKA Banking Signature
Card, Version 6.32 NP, Type 3 der Giesecke &
Devrient GmbH (TUVIT.93125.TU.12.2005)
OK OK F
Signaturerstellungseinheit ZKA Banking Signature
Card, Version 6.4 der Giesecke & Devrient GmbH
(TUVIT.93123.TU.12.2006)
OK OK F
Signaturerstellungseinheit STARCOS 3.0 with
Electronic Signature Application V3.0 der
Giesecke & Devrient GmbH
(TUVIT.93100.TE.09.2005)
OK OK F
Signaturerstellungseinheit ZKA-Signaturkarte,
Version 5.10 der Gemplus GmbH
(TUVIT.93132.TU.06.2006)
OK OK F
B-17
Zertifizierungsreport BSI-DSZ-CC-0330-2007
Windows XP
Kartenbezeichnung und Bestätigungsnummer Kartenleser
ReinerSCT
e:com
Kartenleser
ReinerSCT
PinPad
Kartenleser
Kobil
KAAN Pro
Signaturerstellungseinheit ZKA-Signaturkarte,
Version 5.11 der Gemplus GmbH
(TUVIT.93138.TU.11.2006)
OK OK F
Signaturerstellungseinheit ZKA Banking Signature
Card, Version 6.6 der Giesecke & Devrient GmbH
(TUVIT.93130.TU.05.2006)
OK OK F
Signaturerstellungseinheit ZKA Banking Signature
Card, Version 6.6 der Giesecke & Devrient GmbH
(TUVIT.93130.TU.05.2006 (Nachträge vom
28.8.2006 und 18.10.2006))
OK OK F
Signaturerstellungseinheit ZKA Banking Signature
Card, Version 6.51 der Giesecke & Devrient
GmbH (TUVIT.93129.TU.03.2006)
OK OK F
Signaturerstellungseinheit ZKA Banking Signature
Card, SecV1.5.3 Sagem ORGA
(BSI.02076.TE.12.2006)
OK OK F
Tabelle 7: Unterstützung von Chipkartenlesern und sicheren Signaturerstellungseinheiten unter
Windows XP Professional SP2
B-18
BSI-DSZ-CC-0330-2007 Zertifizierungsreport
Windows 2000
Kartenbezeichnung und
Bestätigungsnummer
Kartenleser
ReinerSCT
e:com
Kartenleser
ReinerSCT
PinPad
Kartenleser
Kobil KAAN
Pro
Telesec Signaturkarte PKS-Card, Version 3.0
(TUVIT.09339.TE.12.2000)
OK OK OK
Telesec Signaturkarte E4NetKeyCard, Version
3.0 (TUVIT.09339.TE.12.2000 (1. Nachtrag))
OK OK OK
Telesec Signaturkarte PKS-Card, Version 3.01
(TUVIT.09339.TE.12.2000 (2. Nachtrag))
OK OK OK
Telesec Signaturkarte E4NetKeyCard, Version
3.01 (TUVIT.09339.TE.12.2000 (2. Nachtrag))
OK OK OK
Telesec Signaturkarte E4NetKeyCard, Version
3.01 (TUVIT.09339.TE.12.2000 (2. Nachtrag))
OK OK OK
DATEV Signaturkarte e:secure-Card Version
1.10 (TUVIT.09341.TE.03.2001 (Nachtrag vom
25.02.2004))
OK OK OK
DATEV Signaturkarte e:secure-Card Version
1.20 (TUVIT.09341.TE.03.2001 (Nachtrag vom
25.02.2004))
OK OK OK
Signtrust Signaturkarte SEA-Card, Version 2.0
(TUVIT.09346.TU.03.2001)
OK OK OK
Signtrust Signaturkarte SEA-Card, Version 2.01
(TUVIT.09346.TU.03.2001 (Nachtrag vom
09.05.2006))
OK OK OK
Signtrust Signaturkarte SEA-Card, Version 2.01
(TUVIT.09346.TU.03.2001 (Nachtrag vom
09.05.2006))
OK OK OK
Signaturkarte D-TRUST-CARD, Version 1.1
(TUVIT.09361.TE.10.2001 (Nachtrag vom
24.03.2004))
OK OK OK
Signaturerstellungseinheit "Prozessorchipkarte
mit Prozessor P8WE5032V0G und STARCOS
SPK 2.3 v 7.0 with Digital Signature Application
StarCert v 2.2"
(T-Systems.02078.TE.12.2001)
OK OK OK
B-19
Zertifizierungsreport BSI-DSZ-CC-0330-2007
Windows 2000
Kartenbezeichnung und
Bestätigungsnummer
Kartenleser
ReinerSCT
e:com
Kartenleser
ReinerSCT
PinPad
Kartenleser
Kobil KAAN
Pro
Signaturerstellungseinheit „Chipkarte mit
Prozessor SLE66CX322P, Betriebssystem
CardOS V4.3B mit Applikation für digitale
Signatur“ (T-Systems.02122.TE.05.2005)
OK OK OK
Signaturerstellungseinheit ZKA-Signaturkarte,
Version 5.02 der Gemplus-mids GmbH
(TUVIT.09385.TU.09.2004)
OK OK F
Signaturerstellungseinheit ZKA Banking
Signature Card, Version 6.2b NP und 6.2f NP,
Type 3 der Giesecke & Devrient GmbH
(TUVIT.09395.TU.01.2005)
OK OK F
Signaturerstellungseinheit ZKA Banking
Signature Card, Version 6.31 NP, Type 3 der
Giesecke & Devrient GmbH
(TUVIT.09397.TU.03.2005)
OK OK F
Signaturerstellungseinheit ZKA Banking
Signature Card, Version 6.32 NP, Type 3 der
Giesecke & Devrient GmbH
(TUVIT.93125.TU.12.2005)
OK OK F
Signaturerstellungseinheit ZKA Banking
Signature Card, Version 6.4 der Giesecke &
Devrient GmbH (TUVIT.93123.TU.12.2006)
OK OK F
Signaturerstellungseinheit STARCOS 3.0 with
Electronic Signature Application V3.0 der
Giesecke & Devrient GmbH
(TUVIT.93100.TE.09.2005)
OK OK F
Signaturerstellungseinheit ZKA-Signaturkarte,
Version 5.10 der Gemplus GmbH
(TUVIT.93132.TU.06.2006)
OK OK F
Signaturerstellungseinheit ZKA-Signaturkarte,
Version 5.11 der Gemplus GmbH
(Bestätigungsnummer nicht bekannt)
OK OK F
Signaturerstellungseinheit ZKA Banking
Signature Card, Version 6.6 der Giesecke &
Devrient GmbH (TUVIT.93130.TU.05.2006)
OK OK F
B-20
BSI-DSZ-CC-0330-2007 Zertifizierungsreport
Windows 2000
Kartenbezeichnung und
Bestätigungsnummer
Kartenleser
ReinerSCT
e:com
Kartenleser
ReinerSCT
PinPad
Kartenleser
Kobil KAAN
Pro
Signaturerstellungseinheit ZKA Banking
Signature Card, Version 6.6 der Giesecke &
Devrient GmbH (TUVIT.93130.TU.05.2006
(Nachträge vom 28.8.2006 und 18.10.2006))
OK OK F
Signaturerstellungseinheit ZKA Banking
Signature Card, Version 6.51 der Giesecke &
Devrient GmbH (TUVIT.93129.TU.03.2006)
OK OK F
Signaturerstellungseinheit ZKA Banking
Signature Card, SecV1.5.3 Sagem ORGA
(BSI.02076.TE.12.2006)
OK OK F
Tabelle 8: Unterstützung von Chipkartenlesern und sicheren Signaturerstellungseinheiten unter
Windows 2000
Suse Linux 9.3
Kartenbezeichnung und Bestätigungsnummer Kartenleser Kobil
KAAN Pro
Telesec Signaturkarte PKS-Card, Version 3.0
(TUVIT.09339.TE.12.2000)
OK
Telesec Signaturkarte E4NetKeyCard, Version 3.0
(TUVIT.09339.TE.12.2000 (1. Nachtrag))
OK
Telesec Signaturkarte PKS-Card, Version 3.01
(TUVIT.09339.TE.12.2000 (2. Nachtrag))
OK
Telesec Signaturkarte E4NetKeyCard, Version 3.01
(TUVIT.09339.TE.12.2000 (2. Nachtrag))
OK
Telesec Signaturkarte E4NetKeyCard, Version 3.01
(TUVIT.09339.TE.12.2000 (2. Nachtrag))
OK
DATEV Signaturkarte e:secure-Card Version 1.10
(TUVIT.09341.TE.03.2001 (Nachtrag vom 25.02.2004))
OK
DATEV Signaturkarte e:secure-Card Version 1.20
(TUVIT.09341.TE.03.2001 (Nachtrag vom 25.02.2004))
OK
Signtrust Signaturkarte SEA-Card, Version 2.0
(TUVIT.09346.TU.03.2001)
OK
Signtrust Signaturkarte SEA-Card, Version 2.01
(TUVIT.09346.TU.03.2001 (Nachtrag vom 09.05.2006))
OK
B-21
Zertifizierungsreport BSI-DSZ-CC-0330-2007
Suse Linux 9.3
Kartenbezeichnung und Bestätigungsnummer Kartenleser Kobil
KAAN Pro
Signtrust Signaturkarte SEA-Card, Version 2.01
(TUVIT.09346.TU.03.2001 (Nachtrag vom 09.05.2006))
OK
Signaturkarte D-TRUST-CARD, Version 1.1
(TUVIT.09361.TE.10.2001 (Nachtrag vom 24.03.2004))
OK
Signaturerstellungseinheit "Prozessorchipkarte mit Prozessor
P8WE5032V0G und STARCOS SPK 2.3 v 7.0 with Digital Signature
Application StarCert v 2.2"
(T-Systems.02078.TE.12.2001)
OK
Signaturerstellungseinheit „Chipkarte mit Prozessor SLE66CX322P,
Betriebssystem CardOS V4.3B mit Applikation für digitale Signatur“
(T-Systems.02122.TE.05.2005)
OK
Tabelle 9: Unterstütze Chipkartenleser und sichere Signaturerstellungseinheiten unter Suse
Linux 9.3
Die o.g. Chipkartenleser sind unter den folgenden IDs bestätigt worden:
• KOBIL KAAN Professional, nur RS232-Version, KOBIL Systems GmbH,
(TUVIT.09331.TE.03.2002),
• cyberJack e-com, Version 2.0, nur USB und Windows, Reiner SCT
Kartengeräte GmbH & Co. KG
(TÜVIT.09363.TE.06.2002);
• cyberJack pinpad, Version 2.0, nur USB und Windows, Reiner SCT
Kartengeräte GmbH & Co. KG,
(TÜVIT.09362.TE.05.2002).
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
B-22
BSI-DSZ-CC-0330-2007 Zertifizierungsreport
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
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.
9
siehe auch www.osci.de
B-23
Zertifizierungsreport BSI-DSZ-CC-0330-2007
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.
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. Insbesondere:
B-24
BSI-DSZ-CC-0330-2007 Zertifizierungsreport
- 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-0330-2007, Version 1.0, 19.11.2007,
Virtuelle Poststelle des Bundes Version 2.2.x.x (OSCI)
Sicherheitsvorgaben (ST); bremen online services GmbH & Co. KG;
datenschutz nord GmbH
[7] Evaluation Technical Report, Version 1.0, 21.11.2007,
Evaluierungsbericht Zertifizierungs-ID: BSI-DSZ-CC-0330-2007
Signaturbestätigungs-ID: BSI.02069.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
[10] Betriebshandbuch, Dokument-Version 2.2.5, 06.09.2007; bremen online
services GmbH & Co. KG
[11] Entwicklerhandbuch, Dokument-Version 2.3.2, 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
B-25
Zertifizierungsreport BSI-DSZ-CC-0330-2007
B-26
Dies ist eine eingefügte Leerseite.
BSI-DSZ-CC-0330-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-0330-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-0330-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-0330-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-0330-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-0330-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-0330-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-0330-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-0330-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-0330-2007
D-2
Dies ist eine eingefügte Leerseite.