BSI-DSZ-CC-0435-2007
zu
Gefäßidentifikationssystem
c-ident Version 1.0,
bestehend aus den Software-Komponenten
IWS_BSI.OBJ Version 1.1 und c-secure.exe
Version 1.1, sowie den dazugehörigen
Transpondern
der
c-trace GmbH
Zertifizierungsreport V1.0 ZS-01-01-F-325 V1.47
BSI- Bundesamt für Sicherheit in der Informationstechnik, Postfach 20 03 63, D-53133 Bonn
Telefon +49(0)3018 9582-0, Fax +49(0)3018 9582-5477, Infoline +49(0)3018 9582-111
Bundesamt für Sicherheit in der Informationstechnik
Godesberger Allee 185-189 - D-53175 Bonn - Postfach 20 03 63 - D-53133 Bonn
Telefon +49(0)3018 9582-0, Fax +49(0)3018 9582-5477, Infoline +49(0)3018 9582-111
BSI-DSZ-CC-0435-2007
Abfallbehälter-Identifikationssystem
c-ident
Version 1.0
von c-trace GmbH
PP-Konformität: Schutzprofil BSI-PP-0010-2004
Funktionalität: BSI-PP-0010-2004 konform plus
produktspezifische Ergänzungen
Common Criteria Teil 2 erweitert
Vertrauenswürdigkeit: Common Criteria Teil 3 konform
EAL 1
Common Criteria
Arrangement
Das in diesem Zertifikat genannte IT-Produkt wurde von einer akkreditierten und lizenzierten Prüfstelle nach
den Gemeinsamen Kriterien für die Prüfung und Bewertung der Sicherheit von Informationstechnik (CC),
Version 2.3 (ISO/IEC 15408:2005), unter Nutzung der Gemeinsamen Evaluationsmethodologie für die
Prüfung und Bewertung der Sicherheit von Informationstechnik (CEM), 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. Oktober 2007
Der Vizepräsident des Bundesamtes
für Sicherheit in der Informationstechnik
Hange L.S.
Zertifizierungsreport BSI-DSZ-CC-0435-2007
Dies ist eine eingefügte Leerseite.
IV
BSI-DSZ-CC-0435-2007 Zertifizierungsreport
V
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
Zertifizierungsreport BSI-DSZ-CC-0435-2007
VI
Gliederung
Teil A: Zertifizierung
Teil B: Zertifizierungsbericht
Teil C: Auszüge aus den technischen Regelwerken
BSI-DSZ-CC-0435-2007 Zertifizierungsreport
A-1
A Zertifizierung
1 Grundlagen des Zertifizierungsverfahrens
Die Zertifizierungsstelle führt das Verfahren nach Maßgabe der folgenden Vorgaben
durch:
• BSIG2
• BSI-Zertifizierungsverordnung3
• BSI-Kostenverordnung4
• 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)
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 Informationstechnik (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
Zertifizierungsreport BSI-DSZ-CC-0435-2007
A-2
2 Anerkennungsvereinbarungen
Um die Mehrfach-Zertifizierung des gleichen Produktes in verschiedenen Staaten zu
vermeiden, wurde eine gegenseitige Anerkennung von IT-Sicherheitszertifikaten - 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.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.
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, Frankreich, 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.
BSI-DSZ-CC-0435-2007 Zertifizierungsreport
A-3
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.
Das Produkt c-ident Version 1.0 hat das Zertifizierungsverfahren beim BSI durchlaufen.
Die Evaluation des Produkts c-ident Version 1.0 wurde von datenschutz nord GmbH
durchgeführt. Das Prüflabor datenschutz nord GmbH ist eine vom BSI anerkannte
Prüfstelle (ITSEF)6
.
Antragsteller, Hersteller und Vertreiber ist
c-trace GmbH
Westring 55
33818 Leopoldshöhe.
Den Abschluß der Zertifizierung bilden
• die Vergleichbarkeitsprüfung und
• die Erstellung des vorliegenden Zertifizierungsreports.
Diese Arbeiten wurden am 18. Oktober 2007 vom BSI abgeschlossen.
Das bestätigte Vertrauenswürdigkeitspaket gilt nur unter der Voraussetzung, daß
• alle Auflagen bzgl. Generierung, Konfiguration und Betrieb, soweit sie im
nachfolgenden Bericht angegeben sind, beachtet werden,
• das Produkt in der beschriebenen Umgebung - sofern im nachfolgenden Bericht
angegeben - betrieben wird.
Dieser Zertifizierungssreport gilt nur für die hier angegebene Version des Produktes. Die
Gültigkeit kann auf neue Versionen und Releases des Produktes ausgedehnt werden,
sofern der Antragsteller eine Re-Zertifizierung des geänderten Produktes entsprechend
den Vorgaben beantragt und die Prüfung keine sicherheitstechnischen Mängel ergibt.
Hinsichtlich der Bedeutung der Vertrauenswürdigkeitsstufen und der bestätigten Stärke
der Funktionen vgl. die Auszüge aus den technischen Regelwerken am Ende des
Zertifizierungsreports.
6
Information Technology Security Evaluation Facility
Zertifizierungsreport BSI-DSZ-CC-0435-2007
A-4
4 Veröffentlichung
Der nachfolgende Zertifizierungsbericht enthält die Seiten B-1 bis B-20.
Das Produkt c-ident Version 1.0 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 Hersteller7
des
Produktes angefordert werden. Unter der o. g. Internetadresse kann der
Zertifizierungsreport auch in elektronischer Form abgerufen werden.
7
c-trace GmbH
Westring 55
33818 Leopoldshöhe
BSI-DSZ-CC-0435-2007 Zertifizierungsreport
B-1
B Zertifizierungsbericht
Der nachfolgende Bericht ist eine Zusammenfassung aus
• den Sicherheitsvorgaben des Antragstellers für den Evaluationsgegenstand,
• den entsprechenden Prüfergebnissen des Prüflabors und
• ergänzenden Hinweisen und Auflagen der Zertifizierungsstelle.
Zertifizierungsreport BSI-DSZ-CC-0435-2007
B-2
Gliederung des Zertifizierungsberichtes
1 Zusammenfassung 3
2 Identifikation des EVG 8
3 Sicherheitspolitik 9
4 Annahmen und Klärung des Einsatzbereiches 10
5 Informationen zur Architektur 12
6 Dokumentation 13
7 Testverfahren 14
8 Evaluierte Konfiguration 14
9 Ergebnisse der Evaluierung 15
10 Kommentare und Empfehlungen 16
11 Anhänge 16
12 Sicherheitsvorgaben 16
13 Definitionen 17
14 Literaturangaben 19
BSI-DSZ-CC-0435-2007 Zertifizierungsreport
B-3
1 Zusammenfassung
Beim EVG handelt es sich um das Gefäßidentifikationssystem c-ident Version 1.0,
bestehend aus den Software-Komponenten IWS_BSI.OBJ Version 1.1 und c-secure.exe
Version 1.1, sowie den dazugehörigen Transpondern (ID-Tags). Dieser EVG ist konform
zum Schutzprofil „Protection Profile Waste Bin Identification System (WBIS-PP), Version
1.04“ [8] evaluiert worden.
Abfallbehälter-Identifikations-Systeme (WBIS) im Sinne dieses Dokumentes sind Systeme,
durch die Abfallbehälter mit einem ID-Tag (z.B. mit elektronischem Chip, dem
Transponder) identifiziert werden, um feststellen zu können, wie oft der einzelne
Abfallbehälter geleert worden ist. Dabei handelt es sich bei diesen Systemen nicht um die
direkte Identifizierung von Abfällen, sondern um die Identifizierung der Behälter, in denen
Abfälle zur Entsorgung bereitgestellt werden.
Der EVG prüft dazu die vom Transponder eingelesen Daten auf Integrität, ergänzt korrekte
Daten durch Datum und Uhrzeit der Leerung, fügt ein Gültigkeits- sowie ein
Intergritätsmerkmal an und speichert diese Daten dann redundant auf zwei getrennten
Speichern im Fahrzeugrechner, damit diese auch bei einem Verlust der Daten in einem
der beiden Speicher wiederhergestellt werden können. Bei der Übertragung in die
Bürosoftware prüft der EVG im Sicherheitsmodul die Daten erneut auf Gültigkeit und
Integrität und kennzeichnet diese entsprechend.
Damit ist der EVG in der Lage, die für die Abrechnung relevanten Daten
(Identifikationsdaten, Zeitstempel) vom Transponder bis in die Bürosoftware vor
Manipulation und Verlust zu schützen.
Die Evaluation des Produkts c-ident Version 1.0, bestehend aus den Software-
Komponenten IWS_BSI.OBJ Version 1.1 und c-secure.exe Version 1.1, sowie den
dazugehörigen Transpondern (ID-Tags) wurde von datenschutz nord GmbH durchgeführt
und am 22. August 2007 abgeschlossen. Das Prüflabor datenschutz nord GmbH ist eine
vom BSI anerkannte Prüfstelle (ITSEF)8
.
Antragsteller, Hersteller und Vertreiber ist
c-trace GmbH
Westring 55
33818 Leopoldshöhe
1.1 Vertrauenswürdigkeitspaket
Die Vertrauenswürdigkeitskomponenten des EVG sind konform zum Teil 3 der CC [1]. Der
EVG wurde erfolgreich mit der Prüfstufe EAL1 (funktionell getestet) evaluiert (siehe auch
Annex C oder [1], Teil 3). In Kapitel 9, Tabelle 5 dieses Reports sind die gewählten
Vertrauenswürdigkeitskomponenten mit dem Evaluierungsergebnis detailliert aufgeführt.
8
Information Technology Security Evaluation Facility
Zertifizierungsreport BSI-DSZ-CC-0435-2007
B-4
1.2 Funktionalität
Die im Schutzprofil ausgewählten und in die Sicherheitsvorgaben übernommenen
funktionalen Sicherheitsanforderungen (SFR – Security Functional Requirements) sind
CC, Teil 2 erweitert. Die Auflistung in der folgenden Tabelle zeigt die zu Teil 2 der CC
konformen SFRs:
Funktionale
Sicherheitsanforderungen
Bedeutung
FDP Schutz der Benutzerdaten
FDP_DAU.1 Einfache Datenauthentisierung
FDP_SDI.1 Überwachung der Integrität der gespeicherten Daten
FRU Betriebsmittelnutzung
FRU_FLT.1 Verminderte Fehlertoleranz
Tabelle 1: SFRs des EVG CC, Teil 2 konform
Die Auflistung in Tabelle 2 zeigt die explizit dargelegten (Teil 2 erweiterten) SFRs:
Funktionale
Sicherheitsanforderungen
Bedeutung
FDP Schutz der Benutzerdaten
FDP_ITT.5 Interne Transferintegrität
Tabelle 2: SFRs des EVG CC, Teil 2 erweitert
Hinweis: Es werden nur die Titel der SFRs genannt. Detailliertere Informationen befinden
sich in Kapitel 5.1.1 der Sicherheitsvorgaben [6].
Die funktionalen Sicherheitsanforderungen werden durch folgende Sicherheitsfunktionen
umgesetzt:
SF_ID_CHK Funktion, die aufgrund von übergebenen Identifikationsdaten (AT1)
aus dem Transponder (ID-Tag) mit anhängendem CRC-Wert den
CRC-Wert berechnet und das Ergebnis (gültig/ungültig) an den nicht-
EVG-Teil der Fahrzeugsoftware übergibt. Bei diesem Ergebnis handelt
es sich um eine Information, ob der aus dem Transponder
eingelesene CRC-Wert mit dem aktuellen durch den EVG
berechneten CRC-Wert übereinstimmt.
SF_CRC_AT Die Funktion, die an einen Leerungsdatensatz AT einen CRC-Wert
anhängt.
SF_CRC_AT+ Wird eine Übertragung der Leerungsdaten angestoßen, sammelt der
EVG eine bestimmte Anzahl von Leerungsdatensätzen (AT) zu einem
Leerungsdatenblock (AT+) zusammen. Über diesen
Leerungsdatenblock (AT+) wird von der Funktion ein CRC-Wert
anhängt.
SF_KEN Die Funktion, die in einen neu angelegten Leerungsdatensatz (AT)
und einen neu angelegten Leerungsdatenblock (AT+) die Kennung
des angeschlossenen Fahrzeugrechners schreibt.
BSI-DSZ-CC-0435-2007 Zertifizierungsreport
B-5
SF_SAFE Die Funktion, die die Leerungsdatensätze (AT) im primären und
sekundären Speicher ablegt und wieder ausliest.
SF_KEN_CHK Die Funktion, die die Gültigkeit der Fahrzeugkennung im
Leerungsdatensatz (AT) und im Leerungsdatenblock (AT+) prüft.
SF_AT_CHK_AT+_CHK Funktion, die aufgrund der vom EVG-Teil der Fahrzeugsoftware
an das Sicherheitsmodul übergebenen Leerungsdatenblöcke AT+ mit
beigefügtem CRC-Wert sowohl den CRC-Wert des Datenblocks (AT+)
berechnet und das Ergebnis (gültig/ungültig) anzeigt, als auch den
CRC-Wert für jeden im Datenblock enthaltenen Leerungsdatensatz
(AT) berechnet und das Ergebnis (gültig/ungültig) anzeigt. Bei diesem
Ergebnis handelt es sich um eine Information, ob der auf dem
Fahrzeugrechner für den Leerungsdatenblock und die darin
enthaltenen Leerungsdatensätze AT erzeugten CRC-Werte mit den
aktuellen, durch den EVG berechneten CRC-Werten übereinstimmen.
Die aus dem Vergleich resultierende Information über Integrität und
Vollständigkeit wird vom Sicherheitsmodul für die korrekte
Weiterverarbeitung genutzt.
1.3 Stärke der Funktionen
Da der EVG vor allem gegen unabsichtliche oder zufällige Veränderungen und Verluste
von Daten, z.B. durch technische Effekte, wie Handystrahlung, wirkt, genügt für seine
Prüfung zunächst die Vertrauenswürdigkeitsstufe EAL1. Diese enthält keine Familien der
Klasse AVA, insbesondere keine Komponenten der Familie AVA_SOF „Stärke der
Sicherheitsfunktionen“. Postulate zur EVG-Funktionsstärke sind somit nicht erforderlich.
1.4 Zusammenfassung der Bedrohungen und der organisatorischen Sicher-
heitspolitik, auf die das evaluierte Produkt ausgerichtet ist
Nachfolgend werden zunächst die schutzwürdigen Objekte, die Subjekte und die Urheber
von Bedrohungen definiert.
Schutzwürdige Objekte sind
- Leerungsdatensätze AT zu einer Leerung
Ein Leerungsdatensatz AT besteht aus den Datenfeldern AT1, Identifikationsdaten
des Abfallbehälters und AT2, Zeitstempel (Datum und Uhrzeit) des
Leerungsvorgangs.
- Leerungsdatenblöcke AT+
Bei der Übertragung der Leerungsdatensätze AT von der Fahrzeugsoftware zum
Sicherheitsmodul im Büro werden die Leerungsdatensätze zu einem
Leerungsdatenblock AT+ zusammengefasst.
Subjekte des EVG im Sinne der CC sind vertrauenswürdige Personen (S.Trusted) im
Umfeld des EVG. Dies sind die Besatzungen der Fahrzeuge, die Benutzer der
Bürorechner und Personen, die das System installieren oder warten, sowie die Personen,
die für die Sicherheit der Umgebung verantwortlich sind.
Urheber von Bedrohungen sind Angreifer (S.Attack), deren Hauptziel es ist, sensitive
Daten der Anwendung zu modifizieren oder zu verfälschen. Angreifer des EVG verfügen
höchstens über Kenntnisse offensichtlicher Schwachstellen.
Zertifizierungsreport BSI-DSZ-CC-0435-2007
B-6
Aufgrund der obigen Definitionen wurden folgende Bedrohungen identifiziert, denen der
EVG entgegenwirken muss:
T.Man Manipulierte Identifikationsdaten
Ein Angreifer (S.Attack) manipuliert die Identifizierungsdaten AT1 im ID-Tag durch Mittel
(z.B. mechanische Einwirkung), die die Identifizierungsdaten AT1 ausschließlich rein
zufällig verfälschen.
T.Jam#1 Gestörte Identifikationsdaten
Ein Angreifer (S.Attack) stört die Übertragung der Identifizierungsdaten AT1 vom ID-Tag
zum Leser im Fahrzeug durch Mittel (z.B. elektromagnetische Strahlung), die die
Identifizierungsdaten AT1 ausschließlich rein zufällig verfälschen.
T.Create Ungültige Leerungsdatenblöcke
Ein Angreifer (S.Attack) erzeugt beliebige Leerungsdatenblöcke AT+ und überträgt diese
an das Sicherheitsmodul.
T.Jam#2 Verfälschte Leerungsdatensätze
Ein Angreifer (S.Attack) verfälscht Leerungsdatensätze AT während der Bearbeitung und
der Speicherung innerhalb des Fahrzeuges oder stört die Übertragung der
Leerungsdatenblöcke AT+ von der Fahrzeugsoftware zum Sicherheitsmodul z.B. durch
elektromagnetische Strahlung, um die Daten der Leerungsdatenblöcke AT+ ausschließlich
rein zufällig zu verfälschen.
In Ergänzung zur Abwehr der Bedrohungen soll der EVG die folgende Sicherheitspolitik
unterstützen:
P.Safe Fehlertoleranz
Die Fahrzeugsoftware muss sicherstellen, dass die Daten der Leerungsdatenblöcke AT+
durch eine redundante Speicherung in einem sekundären Speicher so geschützt sind,
dass die Übertragung der Leerungsdatenblöcke von der Fahrzeugsoftware zum
Sicherheitsmodul nach einem Verlust der Daten in einem primären Speicher möglich ist.
1.5 Spezielle Konfigurationsanforderungen
Der Fahrzeugrechner wird von der c-trace GmbH zusammengestellt und die Software und
damit auch der EVG aufgespielt. Der Fahrzeugrechner wird also mit dem EVG komplett
ausgeliefert. Die Konfiguration des EVG-Teils der Fahrzeugsoftware wird im Handbuch
„Bedienungsanleitung c-trace Identsystem c-ident“ [9] beschrieben.
Die Konfiguration des Sicherheitsmoduls wird im „Systemverwalterhandbuch c-
secureoffice 1.1 zum Sicherheitsmodul c-secure.exe Version 1.1“ [12] detailliert
beschrieben.
BSI-DSZ-CC-0435-2007 Zertifizierungsreport
B-7
1.6 Annahmen über die Einsatzumgebung
Für den EVG werden folgende Annahmen an die Einsatzumgebung gestellt:
Annahme Inhalt
A.Id ID-Tag
A.Trusted Vertrauenswürdiges Personal
A.Access Zugangsschutz
A.Check Überprüfung der Vollständigkeit
A.Backup Datensicherung
A.Installation Systeminstallation
Tabelle 3: Annahmen an die Einsatzumgebung
Hinweis: An dieser Stelle werden nur die Titel der Annahmen genannt. Detailliertere
Informationen befinden sich in Kapitel 4 dieses Reports und in Kapitel 3.1 der
Sicherheitsvorgaben [6]. Die Annahme A.Installation wurde in den Sicherheitsvorgaben
gegenüber dem Schutzprofil ergänzt.
1.7 Gewährleistungsausschluß
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.
Zertifizierungsreport BSI-DSZ-CC-0435-2007
B-8
2 Identifikation des EVG
Der EVG heisst:
c-ident Version 1.0,
bestehend aus den Software-Komponenten IWS_BSI.OBJ Version 1.1 und
c-secure.exe Version 1.1, sowie den dazugehörigen Transpondern
Er besteht aus folgenden auszuliefernden Komponenten:
Nr. Typ Bezeichnung Version Anmerkungen
1 HW /
SW
Transponder (ID-Tags) Siehe Kapitel 10
Anhang „Transponder
Übersicht“ in den
Sicherheitsvorgaben [6]
Bei den ID-Tags handelt es sich
um passive Transponder, die
am oder im zu identifizierenden
Gegenstand befestigt werden.
Alle Transponder besitzen eine
unique ID mit einer
Datenstruktur von mind. 64 Bit
und sind sowohl nur lesbar
(Read Only und OTP) als auch
les- und beschreibbar
(Read/Write), wobei die unique
ID unveränderbar ist. Der
beschreibbare Teil des
Transponders ist nicht Teil des
EVG.
2 SW EVG-Teil der
Fahrzeugsoftware
IWS_BSI.OBJ
Version 1.1
Dateien:
IWS_BSI.C Version 1.1
IWS_BSI.H Version 1.1
Diese Library wird zusammen
mit der Firmware auf einem von
der Firma c-trace entwickelten
Fahrzeugrechner betrieben.
3 DOK Bedienungsanleitung c-
trace Identsystem c-ident
[9]
Version 1.11
4 DOK Technisches Handbuch
zum c-trace
Bedienterminal CTERM
CR1050 [10]
Version 1.6
5 DOK Technisches Handbuch
zum c-trace Identrechner
CIR [11]
Version 1.4
6 DOK c-ident
Kurzbedienungsanleitung
[13]
Version 1.2
7 SW Sicherheitsmodul c-secure.exe 1.1 Bei dem Sicherheitsmodul
handelt sich um den EVG-Teil
der Bürosoftware. Dieses Modul
muss in die Bürosoftware
eingebunden werden, die nicht
Bestandteil des EVG ist.
BSI-DSZ-CC-0435-2007 Zertifizierungsreport
B-9
Nr. Typ Bezeichnung Version Anmerkungen
8 DOK Systemverwalterhandbuch
c-secureoffice 1.1 zum
Sicherheitsmodul c-
secure.exe Version 1.1
[12]
Version 1.5
9 DOK Benutzerhandbuch c-
secureoffice 1.1 zum
Sicherheitsmodul
c-secure.exe Version 1.1
[14]
Version 1.5
Tabelle 4: Komponenten des EVG
Der Fahrzeugrechner wird von der c-trace GmbH zusammengestellt und die Software und
damit auch der EVG aufgespielt. Der Fahrzeugrechner wird also mit dem EVG komplett
ausgeliefert. Die Version des EVG-Teils der Fahrzeugsoftware wird über das
Bedienungsterminal angezeigt.
Die Auslieferung des Sicherheitsmoduls erfolgt auf einer CD, die von der c-trace GmbH
durch das Kopieren einer Master-CD erzeugt wurde. Es kann vom Kunden selbst installiert
und in Betrieb genommen werden. Zum Lieferumfang gehören die folgenden Dateien:
- c-secure.exe 1.1 (das Sicherheitsmodul)
- Systemverwalterhandbuch c-secureoffice 1.2.pdf
- Benutzerhandbuch c-secureoffice 1.2.pdf
Die Version des Sicherheitsmoduls wird durch Ausführen von c-secure.exe über die
Schaltfläche „Hilfe“ angezeigt.
3 Sicherheitspolitik
Der EVG soll Manipulationen an den, in einem ID-Tag gespeicherten Identifikationsdaten
während der Speicherung im ID-Tag und der Übertragung zwischen ID-Tag und Leser
erkennen.
Er soll Manipulationen an empfangenen Leerungsdatensätzen während des Leerungs-
prozesses und Speicherns im Fahrzeug erkennen, sowie Manipulationen der Leerungs-
datenblöcke bei zufälligen Störungen während des Transfers von der Fahrzeugsoftware
zum Sicherheitsmodul.
Der EVG soll sicherstellen, dass die Daten redundant in einem sekundären Speicher
gesichert werden. So ist der Transfer der Leerungsdatenblöcke von der Fahrzeugsoftware
zum Sicherheitsmodul auch noch möglich, sofern Leerungsdatenblöcke im Primärspeicher
der Fahrzeugsoftware verloren gehen.
Er soll jeden Versuch einer Übermittlung willkürlicher (z.B. ungültiger) Leerungsdaten-
blöcke an das Sicherheitsmodul erkennen.
Zertifizierungsreport BSI-DSZ-CC-0435-2007
B-10
4 Annahmen und Klärung des Einsatzbereiches
4.1 Annahmen über den Einsatz
A.Trusted: Vertrauenswürdiges Personal
Die Besatzung des Fahrzeuges und die Benutzer des Bürorechners (S.Trusted) sind
autorisiert und vertrauensvoll. Alle Personen, die das System installieren, initialisieren oder
warten sind autorisiert und vertrauenswürdig (S.Trusted). Alle Personen, die für die
Sicherheit der Umgebung verantwortlich sind, (S.Trusted), sind autorisiert und
vertrauenswürdig.
A.Check Check of completeness
Der Benutzer (S.Trusted) prüft in regelmäßigen Abständen, ob alle Daten von dem
Fahrzeugrechner in das Sicherheitsmodul übertragen wurden (Vollständigkeit der
Übertragung). Erkannte Datenverluste werden vom Benutzer (S.Trusted) in einem
bestimmten Zeitraum durch erneute Anforderung beim Fahrzeugrechner behoben. Dieser
Zeitraum ist konsistent mit der Kapazität des entsprechenden Speichers am
Fahrzeugrechner, der zur Speicherung der Leerungsdaten zur Verfügung steht.
A.Backup: Datensicherung
Der Benutzer (S-Trusted) sichert die vom Evaluierungsgegenstand erzeugten Daten
regelmäßig im Archiv. Der Evaluierungsgegenstand schützt nicht vor Datenverlusten im
Archiv.
A.Installation: Systeminstallation
Bei Installation des Identifikationssystems auf dem Fahrzeug wird sichergestellt, dass die
Leser richtig konfiguriert und zugeordnet sind. Dieses gilt sowohl bei der Neuinstallation,
als auch im Service- / Wartungsfall.
4.2 Angenommene Einsatzumgebung
A.Id: ID-Tag
Der ID-Tag befindet sich fest am Abfallbehälter. Die Identifikationsdaten (AT1) des
Abfallbehälters sind in dem ID-Tag gespeichert. Es werden nur ID-Tags mit einmaligen
Identifikationsdaten installiert. Die korrekte Zuordnung dieser Daten zum
Gebührenpflichtigen ist organisatorisch außerhalb des Evaluierungsgegenstandes
sicherzustellen.
A.Access: Zugangsschutz
Die Umgebung stellt durch geeignete Maßnahmen (Verschluss, Zugangskontrolle durch
Passwörter usw.) sicher, dass nur die Benutzer bzw. das Servicepersonal (S.Trusted) den
direkten Zugang zu allen Komponenten des Evaluierungsgegenstands, außer zum ID-Tag,
haben. Die Beeinflussung der internen Verbindungskanäle durch einen potentiellen
Angreifer (S.Attack) innerhalb der IT-Struktur des Bürorechners ist aufgrund geeigneter
Maßnahmen ausgeschlossen.
BSI-DSZ-CC-0435-2007 Zertifizierungsreport
B-11
4.3 Klärung des Einsatzbereiches
Der EVG gewährleistet mit seinen Sicherheitsfunktionen die Integrität und Vollständigkeit
der zu schützenden Daten. Er gewährleistet jedoch nicht die Vertraulichkeit der Daten,
dass heisst er beinhaltet keine Funktionalität zur Verschlüsselung.
Der EVG beinhaltet die Softwarekomponente IWS_BSI.OBJ, Version 1.1 als Teil der
Fahrzeugsoftware. Der EVG-Teil der Fahrzeugsoftware prüft die vom Transponder
eingelesen Daten auf Integrität, ergänzt korrekte Daten durch Datum und Uhrzeit der
Leerung, fügt ein Gültigkeits- sowie ein Integritätsmerkmal an und speichert diese Daten
dann redundant auf zwei getrennten Speichern im Fahrzeugrechner. Jegliche weitere
Funktionalität der Fahrzeugsoftware ist nicht Bestandteil der Zertifizierung. Die Speicher
gehören ebenfalls nicht zum EVG. Die Speicher sind zwei SD/MMC Karten. Die eine Karte
wird als Primärspeicher und andere Karte als Sekundärspeicher eingesetzt.
Die Daten werden über ein GSM/GPRS Modem an das Sicherheitmodul übertragen (Die
Daten können per Wählverbindung oder über das Internet übertragen werden). Die
Modemverbindung ist nicht Bestandteil der Zertifizierung.
Des Weiteren beinhaltet der EVG das Sicherheitsmodul, die Software-Komponente
c-secure.exe, Version 1.1 als Teil der Bürosoftware. Das Sicherheitsmodul prüft die Daten
erneut auf Gültigkeit und Integrität und kennzeichnet diese entsprechend für die
Weiterverarbeitung. Jegliche weitere Funktionalität der Bürosoftware ist nicht Bestandteil
der Zertifizierung.
Ebenfalls zum EVG gehören die Transponder (ID-Tags) mit den durch CRC-
Checksummen gegen Manipulationen geschützen Identifikationsdaten.
Zertifizierungsreport BSI-DSZ-CC-0435-2007
5 Informationen zur Architektur
Da dieser EVG lediglich auf der Stufe EAL 1 evaluiert wurde, gibt es keine
Architekturbeschreibung (High Level Design), die die Komponenten des EVG beschreibt.
Die folgende Abbildung gibt jedoch einen Überblick über das Abfallbehälter-Identifikations-
System.
Abfallsammelfahrzeug
EVG - Teil
nicht-EVG-
Teil
Fahrzeugrechner
Leser
Bürorechner
Externe
Speicher
Büro
Externe
Festplatte
Externe
Festplatte
Sicherheitsmodul
Bürosoftware
ID-Tag
Teil des EVG
Externe Schnittstelle
Datenübertragung
vertrauens-
würdiger
Benutzer
(S.Trusted)
Abbildung 1: Abfallbehälter-Identifikations-System
Das System besteht aus drei getrennten Teilen. Dies sind die Transponder (ID-Tag) mit
den Identifikationsdaten, das Abfallsammelfahrzeug mit dem Fahrzeugrechner und der
Bürorechner mit der Bürosoftware. Der Fahrzeugrechner beinhaltet den EVG-Teil der
Fahrzeugsoftware, den nicht-EVG-pflichtigen Teil der Fahrzeugsoftware und die externen
Speicher, die ebenfalls nicht zum EVG gehören. Die Bürosoftware auf dem Bürorechner
beinhaltet neben dem Sicherheitsmodul weitere Teile, die jedoch nicht zum EVG gehören.
Des Weiteren verfügt der Bürorechner über einen externen Speicher zur Aufnahme der
übertragenen Leerungsdaten und einen externen Speicher zur Archivierung der gepürften
Leerungsdaten. Die EVG-Teile sind in der Abbildung durch dicke schwarze Rahmen und
die verschiedenen Schnittstellen der EVG-Teile durch schwarze Pfeile gekennzeichnet.
B-12
BSI-DSZ-CC-0435-2007 Zertifizierungsreport
B-13
6 Dokumentation
Mit dem EVG wird folgende Dokumentation ausgeliefert:
- Systemverwalterhandbücher Fahrzeug für die Fahrzeugausstattung:
- c-trace GmbH, „Bedienungsanleitung c-trace Identsystem c-ident“,
Version 1.11 [9]
- c-trace GmbH, „Technisches Handbuch zum c-trace Bedienterminal CTERM
CR1050“, Version 1.6 [10]
- c-trace GmbH, „Technisches Handbuch zum c-trace Identrechner CIR“,
Version 1.4 [11]
- Systemverwalterhandbuch Office für die Büroausstattung:
- c-trace GmbH, „Systemverwalterhandbuch c-secureoffice 1.1 zum
Sicherheitsmodul c-secure.exe Version 1.1“, Version 1.5 [12]
- Benutzerhandbuch Fahrzeug für die Fahrzeugausstattung:
- c-trace GmbH, „c-ident Kurzbedienungsanleitung“, Version 1.2 [13]
- Benutzerhandbuch Office für die Büroausstattung:
- c-trace GmbH, „Benutzerhandbuch c-secureoffice 1.1 zum Sicherheitsmodul
c-secure.exe Version 1.1“, Version 1.5 [14]
Zertifizierungsreport BSI-DSZ-CC-0435-2007
B-14
7 Testverfahren
7.1 Testkonfiguration
Der Hersteller hat der Prüfstelle den EVG in folgender Form zur Verfügung gestellt:
- ein Vorführkoffer, in dem sich die Bestandteile des Systems funktionsfähig befinden,
die sonst am Müllfahrzeug angebracht sind – inkl. EVG-Teil der Fahrzeugsoftware;
- ein Bürorechner (Microsoft Windows XP Professional, Version 2002, SP2, auf Intel
Pentium 2.8GHz, 80GB Festplatte) mit dem Sicherheitsmodul c-secure.exe;
- mehrere Transponder von Sokymat und Envicomp (ID-Tags vom Typ EM 4105).
Die Evaluatoren haben sich davon überzeugt, dass der in den Sicherheitsvorgaben [6]
spezifizierte EVG für die Tests zur Verfügung steht:
- der Fahrzeugrechner zeigt im Display die Versionsnummer 1.1 des EVG-Teils der
Fahrzeugsoftware an
- das Sicherheitsmodul c-secure.exe zeigt seine Versionsnummer als 1.1 an
- die zur Verfügung gestellten Transponder stammen von Sokymat und Envicomp:
Die Transponder zeigen aufgrund des eingeschränkten Platzes lediglich den Namen
ihres „Verpackers“ an: die Transponder stammen von Sokymat und Envicomp. Für
die Produkte des Verpackers gibt es technische Datenblätter, aus denen die exakte
Angabe des integrierten Chips hervorgeht. Somit kann der Kunde feststellen, ob der
verwendete Transponder einen zulässigen Chip gemäß Transponder-Übersicht
enthält. Die Transponder von Sokymat und Envicomp besitzen einen EM 4105-Chip,
der konform zum Anhang in [6] ist.
7.2 Zusammenfassung der unabhängigen Prüfstellentests
Es wurden alle Sicherheitsfunktionen des EVG an den zugänglichen
Benutzerschnittstellen mit jeweils mindestens einem Testfall getestet, um das korrekte
Verhalten der Sicherheitsfunktionen zu überprüfen.
Insgesamt zeigen die Tests, dass sich der EVG wie in den Sicherheitsvorgaben [6]
spezifiziert verhält.
8 Evaluierte Konfiguration
Der EVG wird durch die Bezeichnung „c-ident Version 1.0, bestehend aus den Software-
Komponenten IWS_BSI.OBJ Version 1.1 und c-secure.exe Version 1.1, sowie den
dazugehörigen Transpondern (ID-Tags)“ identifiziert.
Alle Informationen und Hinweise aus den Sicherheitsvorgaben [6] und den Handbüchern
[9] – [14] zur Installation und Konfiguration der Fahrzeugsoftware und des
Sicherheitsmoduls müssen beachtet werden.
BSI-DSZ-CC-0435-2007 Zertifizierungsreport
B-15
9 Ergebnisse der Evaluierung
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 Evaluationsmethodology CEM [2] wurde für die Komponente aus dem
Vertrauenswürdigkeitsstufe EAL 1 verwendet.
Das Urteil für die CC, Teil 3 Anforderungen an die Vertrauenswürdigkeit (gemäß EAL 1
und die Klasse ASE für die Sicherheitsvorgaben) sind in der folgenden Tabelle dargestellt.
Vertrauenswürdigkeitsklassen und Komponenten Urteil
Security Target Evaluierung CC Klasse ASE PASS
EVG-Beschreibung ASE_DES.1 PASS
Sicherheitsumgebung ASE_ENV.1 PASS
ST-Einführung ASE_INT.1 PASS
Sicherheitsziele ASE_OBJ.1 PASS
PP-Postulate ASE_PPC.1 PASS
IT-Sicherheitsanforderungen ASE_REQ.1 PASS
Explizit dargelegte IT-Sicherheitsanforderungen ASE_SRE.1 PASS
EVG-Übersichtsspezifikation ASE_TSS.1 PASS
Konfigurationsmanagement CC Klasse ACM PASS
Versionsnummern ACM_CAP.1 PASS
Auslieferung und Betrieb CC Klasse ADO PASS
Installation, Generierung und Anlauf ADO_IGS.1 PASS
Entwicklung CC Klasse ADV PASS
Informelle funktionale Spezifikation ADV_FSP.1 PASS
Informeller Nachweis der Übereinstimmung ADV_RCR.1 PASS
Handbücher CC Klasse AGD PASS
Systemverwalterhandbuch AGD_ADM.1 PASS
Benutzerhandbuch AGD_USR.1 PASS
Testen CC Klasse ATE PASS
Unabhängiges Testen - Übereinstimmung ATE_IND.1 PASS
Tabelle 5: Urteil zu den Vertrauenswürdigkeitskomponenten (EAL1)
Zertifizierungsreport BSI-DSZ-CC-0435-2007
B-16
Die Evaluierung hat gezeigt, dass:
- der EVG konform zum PP BSI-PP-0010-2004 [8] ist
- die Sicherheitsanforderungen für den EVG aus den Sicherheitsvorgaben Common
Criteria Part 2 erweitert sind
- die Vertrauenswürdigkeit des EVG Common Criteria Teil 3 konform ist
Die Resultate der Evaluierung sind nur anwendbar auf den EVG
Gefäßidentifikationssystem c-ident Version 1.0 (siehe Kapitel 2 dieses Reports).
Die Gültigkeit kann auf neue Versionen bzw. Releases des Produktes erweitert werden.
Voraussetzung dafür ist, dass der Antragstelle die Re-Zertifizierung oder die Assurance
Continuity in Übereinstimmung mit den entsprechenden Regeln beantragt und die
Evaluierung keine Schwächen der Sicherheitsfunktionen aufdeckt.
10 Kommentare und Empfehlungen
Die Dokumente [9] - [14] enthalten die notwendigen Informationen über den die
Verwendung des EVG und alle Sicherheitshinweise sind darin enthalten.
11 Anhänge
keine
12 Sicherheitsvorgaben
Die Sicherheitsvorgaben [6] werden zur Veröffentlichung in einem separaten Dokument
bereitgestellt.
BSI-DSZ-CC-0435-2007 Zertifizierungsreport
B-17
13 Definitionen
13.1 Abkürzungen
BSI Bundesamt für Sicherheit in der Informationstechnik, Bonn
CC Gemeinsame Kriterien für die Prüfung und Bewertung der Sicherheit von
Informationstechnik
EAL Evaluation Assurance Level - Vertrauenswürdigkeitsstufe
IT Informationstechnik
PP Protection Profile - Schutzprofil
SF Sicherheitsfunktion
SOF Strength of Function - Stärke der Funktionen
ST Security Target - Sicherheitsvorgaben
EVG Evaluationsgegenstand
TSC TSF Scope of Control - Anwendungsbereich der TSF-Kontrolle
TSF TOE Security Functions - EVG-Sicherheitsfunktionen
TSP TOE security policy - EVG-Sicherheitspolitik
WBIS Waste Bin Identification System – Abfallbehälter-Identifikations-System
13.2 Glossar
Zusatz - Das Hinzufügen einer oder mehrerer Vertrauenswürdigkeitskomponenten aus
Teil 3 der CC zu einer EAL oder einem Vertrauenswürdigkeitspaket.
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 Schutzprofil.
Formal - Ausgedrückt in einer Sprache mit beschränkter Syntax und festgelegter
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 Sicherheitsanforderungen
für eine Kategorie von EVG, die besondere Konsumentenbedürfnisse erfüllen.
Sicherheitsfunktion - Ein Teil oder Teile eines EVG, auf die zur Durchsetzung einer
hierzu in enger Beziehung stehenden Teilmenge der Regeln der EVG-Sicherheitspolitik
Verlaß sein muß.
Zertifizierungsreport BSI-DSZ-CC-0435-2007
B-18
Sicherheitsvorgaben - Eine Menge von Sicherheitsanforderungen und Sicherheits-
spezifikationen, die als Grundlage für die Prüfung und Bewertung eines angegebenen
EVG dienen.
Semiformal - Ausgedrückt in einer Sprache mit beschränkter Syntax und festgelegter
Semantik.
Stärke der Funktionen - Eine Charakterisierung einer EVG-Sicherheitsfunktion, 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.
SOF-Niedrig - Eine Stufe der EVG-Stärke von Funktionen, bei der die Analyse zeigt, daß
die Funktionen einen angemessenen Schutz gegen zufälliges Brechen der EVG-Sicherheit
durch Angreifer bieten, die über ein geringes Angriffspotential verfügen.
SOF-Mittel - Eine Stufe der EVG-Stärke von Funktionen, bei der die Analyse zeigt, daß
die Funktionen einen angemessenen Schutz gegen naheliegendes oder absichtliches
Brechen der EVG-Sicherheit durch Angreifer bieten, die über ein mittleres Angriffspotential
verfügen.
SOF-Hoch - Eine Stufe der EVG-Stärke von Funktionen, bei der die Analyse zeigt, daß
die Funktionen einen geeigneten Schutz gegen geplantes oder organisiertes Brechen der
EVG-Sicherheit durch Angreifer bieten, die über ein hohes Angriffspotential verfügen.
Subjekt - Eine Einheit innerhalb des TSC, die die Ausführung von Operationen bewirkt.
Evaluationsgegenstand - Ein IT-Produkt oder -System - sowie die dazugehörigen
Systemverwalter- und Benutzerhandbücher - das Gegenstand einer Prüfung und
Bewertung ist.
EVG-Sicherheitsfunktionen - Eine Menge, die die gesamte Hardware, Software, und
Firmware des EVG umfaßt, auf die Verlaß sein muß, 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.
Anwendungsbereich der TSF-Kontrolle - Die Menge der Interaktionen, die mit oder
innerhalb eines EVG vorkommen können und den Regeln der TSP unterliegen.
BSI-DSZ-CC-0435-2007 Zertifizierungsreport
B-19
14 Literaturangaben
[1] Gemeinsamen Kriterien für die Prüfung und Bewertung der Sicherheit von
Informationstechnik (CC), 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..
[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-0435-2007, Version 1.12, 10.08.2007,
„Sicherheitsvorgaben für c-trace Gefäßidentifikationssystem c-ident Version 1.0“,
c-trace GmbH,
[7] Evaluierungsbericht, Version 1.2, 22.08.2007, „Evaluation Technical Report (ETR)
c-ident 1.0“(vertrauliches Dokument)
[8] Schutzprofil BSI-PP-0010-2004 „Protection Profile Waste Bin Identification System
(WBIS-PP), Version 1.04“
[9] c-trace GmbH, „Bedienungsanleitung c-trace Identsystem c-ident“, Version 1.11
[10] c-trace GmbH, „Technisches Handbuch zum c-trace Bedienterminal CTERM
CR1050“, Version 1.6
[11] c-trace GmbH, „Technisches Handbuch zum c-trace Identrechner CIR“, Version 1.4
[12] c-trace GmbH, „Systemverwalterhandbuch c-secureoffice 1.1 zum Sicherheitsmodul
c-secure.exe Version 1.1“, Version 1.5
[13] c-trace GmbH, „c-ident Kurzbedienungsanleitung“, Version 1.2
[14] c-trace GmbH, „Benutzerhandbuch c-secureoffice 1.1 zum Sicherheitsmodul c-
secure.exe Version 1.1“, Version 1.5
Zertifizierungsreport BSI-DSZ-CC-0435-2007
B-20
Dies ist eine eingefügte Leerseite.
BSI-DSZ-CC-0435-2007 Zertifizierungsreport
C-1
C Auszüge aus den technischen Regelwerken
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:
a) 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.
b) 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:
a) 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.
b) 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:
a) 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.
b) 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:
a) PP Conformant - A TOE meets specific PP(s), which are listed as part of the
conformance result.“
Zertifizierungsreport BSI-DSZ-CC-0435-2007
C-2
CC Part 3:
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”
BSI-DSZ-CC-0435-2007 Zertifizierungsreport
C-3
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.
Zertifizierungsreport BSI-DSZ-CC-0435-2007
C-4
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”
BSI-DSZ-CC-0435-2007 Zertifizierungsreport
C-5
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.”
Zertifizierungsreport BSI-DSZ-CC-0435-2007
C-6
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.”
BSI-DSZ-CC-0435-2007 Zertifizierungsreport
C-7
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.“
Zertifizierungsreport BSI-DSZ-CC-0435-2007
C-8
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.