SPHINX. Sichere . Testspezifikation Client-Produkte: Interoperabilität und Funktionalität

Transkript

1 Sichere Testspezifikation Client-Produkte: Interoperabilität und Funktionalität Version Juni 2004

2 Thomas Beckmann, Theo Fischer Atos Origin GmbH Lohberg 10 D Meppen Michael Thiel Bundesamt für Sicherheit in der Informationstechnik Godesberger Allee 183 D Bonn - Dieses Dokument einschließlich aller Teile ist urheberrechtlich geschützt - Die unveränderte Weitergabe (Vervielfältigung) des Dokuments ist ausdrücklich erlaubt. Jede weitergehende Verwertung außerhalb der engen Grenzen des Urhebergesetzes ist ohne Zustimmung des Bundesamtes für Sicherheit in der Informationstechnik unzulässig und strafbar Bundesamt für Sicherheit in der Informationstechnik Godesberger Allee 183, Bonn Telefon: 0228/ Telefax: 0228/

3 Inhaltsverzeichnis Abbildungsverzeichnis...4 Tabellenverzeichnis...4 Abkürzungsverzeichnis...5 Literaturverzeichnis...6 Änderungshistorie Einleitung Rahmenorganisation Technische Rahmenbedingungen Beschreibung des Testlabors Beschreibung des X.500-Verzeichnisses Testkategorien und -arten Testdaten Allgemeine Daten PCA- und CA-Zertifikate Endanwender-Zertifikate Sperrlisten Beschreibung der Testfälle Übersicht der Testfälle Interoperabilität und Funktionalität (Gutfalltests) Schlechtfalltests Interoperabilität und Funktionalität (Gutfalltests) PKI-Management Zertifikate und Sperrlisten Nachrichtenaustauschformate Verzeichnisdienst Gültigkeitsprüfungen Token Schlechtfalltests Bewertungskatalog Produktkategorien für die Einsatzempfehlung Bundesamt für Sicherheit in der Informationstechnik Seite 3 von 73

4 7.2 Bewertungskriterien Bewertungsschema Kategorie besonders empfehlenswert Kategorie empfehlenswert Kategorie bedingt empfehlenswert Kategorie nicht bewertbar Anhang Prüfprotokoll Interoperabilität und Funktionalität...55 Abbildungsverzeichnis Abbildung 1: Testlabor bei CCI GmbH Abbildung 2: Zeichensatz UTF8/ISO (Latin-1) Tabellenverzeichnis Tabelle 1: Allgemeine Testdaten Tabelle 2: Erweiterungen und Belegung der Zertifikate der Test-PCA und der CAs Tabelle 3: Erweiterungen und Belegung der Endanwender-Zertifikate Tabelle 4: Erweiterungen und Belegung von Sperrlisten Tabelle 5: Übersicht aller Gutfalltestfälle Tabelle 6: Übersicht aller Schlechtfalltestfälle Tabelle 7: Pflichtkriterien der Gutfalltests Tabelle 8: Pflichtkriterien der Schlechtfalltests Bundesamt für Sicherheit in der Informationstechnik Seite 4 von 73

5 Abkürzungsverzeichnis Anh Anhang ASN.1 Abstract Syntax Notation 1 BIN Binary BSI Bundesamt für Sicherheit in der Informationstechnik CA Certification Authority (Zertifizierungsinstanz) CCI Competence Center Informatik GmbH CRL Certificate Revocation List (Sperrliste) DES Data Encryption Standard DN Distinguished Name ISIS Industrial Signature Interoperability Specification ISO International Organization for Standardization LDAP Lightweight Directory Access Protocol MIME Multipurpose Internet Mail Extension MTT MailTrust PKI Public Key Infrastructure PSE Personal Security Environment RPC Remote Procedure Call RSA (Rivest-Shamir-Adleman)-Verfahren SHA Secure Hash Algorithm S/MIME Secure MIME UCS Universal Character Set UTF UCS Transformation Formats Bundesamt für Sicherheit in der Informationstechnik Seite 5 von 73

6 Literaturverzeichnis [MTTv1] TeleTrusT Deutschland e.v.: MailTrusT-Spezifikation, Version 1.1, Ed. F. Bauspieß; 1996 [MTTv2] TeleTrusT Deutschland e.v.: MailTrusT-Spezifikation, Version 2, Ed. F. Bauspieß, J. Biester, D. Fox; [Formate] Zertifizierungsinfrastruktur für die PKI-1-Verwaltung: Technische Grundlagen der Wurzelzertifizierungsstelle: Formate und Protokolle nach MTTv2; Bundesamt für Sicherheit in der Informationstechnik; Version 2.0 vom [ISIS-MTT] T7 & TeleTrusT: ISIS-MTT Specification; Common ISIS-MTT Specification for PKI Applications; Introduction and general Overview; Version 1.0.2; July 19th 2002 T7 & TeleTrusT: ISIS-MTT Specification; Common ISIS-MTT Specification for PKI Applications; Profile, SigG-conforming Systems and Applications; Version 1.0.1; November 15th 2001 [Besch_Empf] SPHINX Sichere Beschaffungsempfehlung; Version 1.2; 20. November 2000 [Namen] Zertifizierungsinfrastruktur für die PKI-1-Verwaltung: Namensregeln und formate; Bundesamt für Sicherheit in der Informationstechnik; Version 1.3 vom [RFC 822] Standard for the format of ARPA Internet text messages; August 1982 [RFC 2253] Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names; December 1997 [RFC 3280] Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile; April 2002 Änderungshistorie Version Datum Status, Änderung Autoren Abgestimmte Version Theo Fischer Überarbeiten des Literaturverzeichnisses, des Kapitels 5 und des Anhangs; Einfügen der Kommentare von Herrn Albrecht Schmidt (BSI) Aktualisieren der Komponenten für die Standardkonfiguration (Abschnitt 3.1) Einarbeiten von Kommentaren und Hinweisen mehrerer Hersteller; Einfügen eines neuen Testfalls (Testfall 15: Interoperabilität zur virtuellen Poststelle) Theo Fischer Theo Fischer Theo Fischer Bundesamt für Sicherheit in der Informationstechnik Seite 6 von 73

7 1 Einleitung Während des Pilotversuchs SPHINX Sichere von wurde die Interoperabilität und Funktionalität der kryptografischen Produkte zur Verschlüsselung und elektronischen Signatur überprüft. Vor dem Einsatz der Produkte im europaweit geführten Feldversuch wurden sie auf Basis der Minimal-Testspezifikation getestet. Als das Projekt SPHINX Anfang 2001 in den Wirkbetrieb überführt wurde, sollte die notwendige Interoperabilität und Funktionalität der Produkte weiterhin durch vom Bundesamt für Sicherheit in der Informationstechnik (BSI) beauftragte Tests sichergestellt werden. Aufgrund der stetigen Fortentwicklung wird der Test in regelmäßigen zeitlichen Abständen wiederholt. Mit der Durchführung der Aufgaben des Tests und der Bereitstellung eines Testbed wurde ein branchenweit etabliertes Testlabor beauftragt. Es sorgt außerdem für die Fortentwicklung und Anpassung der Testspezifikation in Abstimmung mit dem BSI und den Herstellern. Die vorliegende Testspezifikation bildet die Grundlage für die Durchführung der Tests. Sie basiert auf der im Pilotversuch SPHINX erarbeiteten Testspezifikation zur 2. Testreihe, Version 1.0 vom 10. Mai 2000 und schafft damit Kontinuität in der Betrachtung. Sie berücksichtigt die aktuellen Anforderungen, indem sie im Hinblick auf die aktuelle technische Entwicklung und die Anforderungen aus der Beschaffungsempfehlung [Besch_Empf], der PKI-1- Verwaltung und der Spezifikation ISIS-MTT [ISIS-MTT] überarbeitet wurde. Diese Testspezifikation wird laufend fortgeschrieben und den aktuellen Anforderungen angepasst. Organisatorische Aspekte zu den Interoperabilitätstests, wie Anmeldungen zum Test, Termine etc. sind in Kapitel 2 beschrieben. Die technischen Randbedingungen, zu denen der Aufbau des Testlabors und die verwendeten Verzeichnisserver zählen, sind in Kapitel 3 dargestellt. Das Kapitel 4 beschreibt die zur Unterteilung der Testfälle verwendeten Kategorien und die verschiedenen Arten von Testfällen. Die verwendeten Testdaten für Zertifikate und Sperrlisten sind in Kapitel 5 aufgeführt. Das Kapitel 6 beschreibt die einzelnen Testfälle, ihre Ziele, das Vorgehen zu ihrer Durchführung und die erwarteten Ergebnisse. In Kapitel 7 ist ein Bewertungskatalog dargestellt, der für eine Freigabe der getesteten Produkte herangezogen wird. Im Anhang ist das zur Dokumentation der Testergebnisse verwendete Protokoll aufgeführt. Bundesamt für Sicherheit in der Informationstechnik Seite 7 von 73

8 Bundesamt für Sicherheit in der Informationstechnik Seite 8 von 73

9 2 Rahmenorganisation Die Tests werden regelmäßig einmal pro Kalenderquartal durchgeführt. Die genauen Testtermine werden zwischen dem Bundesamt für Sicherheit in der Informationstechnik und dem Testlabor vereinbart und anschließend veröffentlicht. Hersteller, die beabsichtigen, ihr Produkt einem SPHINX-Interoperabilitätstest zu unterziehen, können sich an folgende Adresse wenden und ihr Produkt für einen Test anmelden: Herr Michael Thiel Bundesamt für Sicherheit in der Informationstechnik Godesberger Allee D Bonn Tel: Fax: WWW: Das Bundesamt für Sicherheit in der Informationstechnik teilt dem Testlabor die zu testenden Produkte mit. Vor jedem Quartalstest wird ein Vortest vom Testlabor angeboten. Der Vortest dient dazu, die wirtschaftliche Durchführung des Quartalstests zu gewährleisten. Ein Vortest ist für die Hersteller vorgeschrieben, - die zum ersten Mal mit einem Produkt am SPHINX-Test teilnehmen möchten, - deren Produkt den vorhergehenden SPHINX-Test nicht wenigstens mit dem Urteil "bedingt empfehlenswert" abgeschlossen haben oder - die eine neue Version ihres Produkts im SPHINX-Test einbringen möchten. Der Schwerpunkt der Vortests liegt auf der Interoperabilität der Produkte beim Nachrichtenaustausch untereinander. Getestet wird beim Vortest zwischen Testlabor und Hersteller ausschließlich über das Internet. Im Vortest werden die Produkte selektiert, die wesentliche Interoperabilitätsprobleme aufweisen und daher keine erfolgreiche Durchführung des Quartalstests erwarten lassen. Produkte, die den Vortest erfolgreich durchlaufen, werden zum Quartalstest zugelassen. Um einen problemlosen Ablauf der Quartalstests zu ermöglichen, sollen die Hersteller ihre Produkte mindestens zehn Tage vor Beginn der Tests beim Testlabor einreichen. Das Testlabor installiert die Produkte vorab und informiert den Hersteller bei Installationsproblemen. Dieser hat dadurch vor Testbeginn die Möglichkeit, zu reagieren bzw. die Fehlerursache zu ermitteln, Änderungen vorzunehmen und die Teilnahme seines Produkts am Test sicherzustellen. Durch diese Vorgehensweise wird zusätzlich eine Überschreitung der vorgesehenen Testdauer vermieden und die Einhaltung des Zeitplans mit Erstellung von Testbericht, Abnahme, Freigabe der Produkte, Veröffentlichung der Freigabeliste etc. gewährleistet. Das Testlabor dokumentiert die Ergebnisse der Tests in einem Testbericht. Bestandteil dieses Berichts ist eine Freigabeempfehlung. In dieser schlägt das Labor dem Bundesamt für Sicherheit in der Informationstechnik die Produkte vor, die für eine Freigabe geeignet erscheinen. Bundesamt für Sicherheit in der Informationstechnik Seite 9 von 73

10 Das Bundesamt für Sicherheit in der Informationstechnik entscheidet, welches Produkt eine Freigabe erhält. Dazu wird über die Internet-Seiten des BSI zum SPHINX-Projekt ( eine Liste mit freigegebenen Produkten veröffentlicht. Bundesamt für Sicherheit in der Informationstechnik Seite 10 von 73

11 3 Technische Rahmenbedingungen Zur Durchführung der Tests hat die Atos Origin GmbH (Standort Meppen) ein Testlabor eingerichtet. Dieses Kapitel beschreibt das Testlabor und den Aufbau des für die Tests verwendeten X.500-Verzeichnisses. 3.1 Beschreibung des Testlabors Das Testlabor für die Prüfung der Produkte wurde in einem Raum mit mehreren PC aufgebaut. Die Rechner sind vernetzt und über das interne Netz der Atos Origin GmbH an das Internet angeschlossen. Auf vier Rechnern sind mehrere Partitionen installiert, so dass insgesamt für jedes zu testende Client-Produkt eine Partition vorhanden ist. So muss nicht für jedes hinzukommende Produkt ein neuer PC beschafft, sondern nur eine neue Partition eingerichtet werden. Die Rechner sind hardwaremäßig wie folgt ausgestattet: - Prozessor: Intel PIV 2.6GHz 800MHz FSB Processor - Arbeitsspeicher: 1GB DDR SDRAM - Grafikkarte: Integrated Intel Extreme Graphics - Festplatte: 120GB IDE (40 GB pro Partition) - Netzwerkkarte: Integrated Intel Pro/1000 MT Auf einem weiteren Rechner ist die Software für die Dienste der Zertifizierungsstelle installiert. Die Testumgebung ist erweiterbar, so dass sie um weitere Rechner ergänzt werden kann (z.b. PC mit Betriebssystem ERPOSS, PC für virtuelle Poststelle etc.). Als Mail-Server werden der interne Exchange-Server und der interne Lotus-Notes-Server der Atos Origin GmbH (Standort Meppen) sowie ein Groupwise-Server, der ebenfalls an das interne Netz angeschlossen ist, verwendet. Als Standardplattform wird folgende Konfiguration verwendet: MS Windows NT 4.0 SP6a, MS-Outlook 98 und Microsoft-Exchange-Server 5.5, Lotus-Notes-Client und Lotus-Notes-Server 5.0.5, Novell Groupwise 5.5. Weiterhin sind noch folgende Komponenten installiert: MS Office 97, ServiceRelease SR-2, Internet Explorer 6.0, aktuellste Version von MCAfee VirusScan. Bundesamt für Sicherheit in der Informationstechnik Seite 11 von 73

12 Der Aufbau des Testlabors ist in Abbildung 1 grafisch dargestellt. Abbildung 1: Testlabor bei Atos Origin GmbH Hinweis: Die gestrichelte Linie in Abbildung 1 vom Internet zum X.500-Verzeichnis bedeutet, dass nicht bekannt ist, wie die Anbindung an das Internet erfolgt. Für den Aufbau des Testlabors gelten nachstehende Rahmenbedingungen: - Das Testlabor ist an das Internet angeschlossen. - Für die Tests wurde eine eigene PKI aufgebaut. Alle Zertifikate werden mit dem CA Management der Firma Secude erstellt. - Für jedes Produkt wird ein Testnutzer eingerichtet bzw. jedem Testnutzer wird ein Produkt eines Herstellers zugewiesen. - Die Client-Produkte eines Herstellers werden auf einer separaten Partition installiert. - Jeder Testnutzer (bis auf den Groupwise-Nutzer) erhält einen Account auf dem Exchange-Server der Atos Origin GmbH (Standort Meppen). - Die Testnutzer von Produkten für Lotus Notes erhalten einen Account auf dem Notes- Server der Atos Origin GmbH (Standort Meppen). Die s werden durch eine Weiterleitung vom Notes-Server zum Exchange-Server an den Testnutzer geleitet. - Der Testnutzer für Groupwise erhält einen Account auf dem Groupwise-Server. - Jedem Testnutzer wird der Zugang zum Internet ermöglicht. Bundesamt für Sicherheit in der Informationstechnik Seite 12 von 73

13 3.2 Beschreibung des X.500-Verzeichnisses Für die Tests wird der folgende Server verwendet: - Adresse: Test-x500.bund.de - Port: 389 (LDAP) - Suchbasis: O=Test-PKI, C=DE. Die während der Tests ausgestellten Zertifikate und Sperrlisten wurden nach ihrer Erzeugung in das X.500-Verzeichnis eingestellt. Dazu werden die Zertifikate per von der Atos Origin GmbH an die T-Systems International GmbH (Betreiber des Verzeichnisses) gesendet und im Test-Verzeichnis veröffentlicht. Bundesamt für Sicherheit in der Informationstechnik Seite 13 von 73

14 Bundesamt für Sicherheit in der Informationstechnik Seite 14 von 73

15 4 Testkategorien und -arten Insgesamt werden die Testfälle nach Gutfalltests und Schlechtfalltests unterschieden. Mittels der Gutfalltests werden die Interoperabilität und Funktionalität der Produkte ermittelt. Bei den Schlechtfalltests handelt es sich um Tests, die wissentlich nicht korrekte Zustände beinhalten oder simulieren und zu bestimmten Ergebnissen führen sollen. Die Gutfalltests sind in insgesamt fünf Teilbereiche gegliedert, die sich wie folgt darstellen: PKI-Management: Gegenstand dieser Testfälle sind im Wesentlichen die Schlüsselerzeugung, der Zertifizierungsablauf und die Verwaltung von Schlüsseln und Zertifikaten. Zertifikate und Sperrlisten: Diese Testfälle prüfen den Umgang bzw. die Beherrschung der vereinbarten Profile von Zertifikaten und Sperrlisten. Nachrichtenaustauschformate: Wesentlicher Bestandteil sind die Austauschformate auf Basis von S/MIME. Weiterhin gehören hierzu der Umgang mit Mehrfachsignaturen und Quittungen sowie mit gelesenen und gespeicherten, verschlüsselten Nachrichten. Verzeichnisdienst: Hierbei handelt es um die Abfrage von Zertifikaten und Sperrlisten vom Verzeichnisdienst sowie die Suche im Verzeichnis. Der genutzte Verzeichnisdienst ist das Testverzeichnis des Informationsverbunds Berlin-Bonn (IVBB). Gültigkeitsprüfungen: Diese Testfälle befassen sich mit dem Gültigkeitsmodell und der korrekten Prüfung des Zertifizierungspfades. Token: Hier werden die vom Produkt unterstützen kryptographischen Token und weitere Komponenten, wie z.b. Chipkartenleser, erfasst. Jedem einzelnen Testfall (Gutfall und Schlechtfall) wird zusätzlich eine der folgenden Testkategorien zugeordnet: Funktionstest: Mit Hilfe von Testdaten (Zertifikaten, Sperrlisten) werden ganz bestimmte Ergebnisse erwartet. Ziel ist es, Fehler in den zu testenden Produkten zu entdecken. Usability-Test: Bei den Produkten wird festgehalten, welche der vorgegebenen und eventuell weiteren Funktionen das Produkt erfüllt. Ziel ist dabei, zu ermitteln, ob die Mindestfunktionalität vorhanden ist und darüber hinaus, weitere Merkmale zu identifizieren. GUI-Test: Es wird geprüft, ob das Programm die spezifizierten Anforderungen (sei es in der Dokumentation oder durch die Spezifikation) erfüllt. Ziel ist es, Fehler in den Darstellungen (Schreibfehler, Übersetzungsfehler, unverständliche Meldungen usw.) zu finden. Bundesamt für Sicherheit in der Informationstechnik Seite 15 von 73

16 Neben den Testkategorien wird zu jedem Testfall angegeben, um welche Art von Prüfung es sich handelt bzw. wie das Testergebnis geprüft wird: Visuelle Prüfung: Hierbei werden vom Produkt die grafischen Gestaltungen sowie die grafischen Veränderungen, die im Verlauf eines Tests auftreten, geprüft. Blackbox-Prüfung: Beim Blackbox-Test wird das Verhalten des Produkts aufgrund der jeweiligen Testparameter geprüft. Wirksamkeitsprüfung: Hier wird geprüft, ob die vorgenommenen Einstellungen greifen. Bundesamt für Sicherheit in der Informationstechnik Seite 16 von 73

17 5 Testdaten In diesem Kapitel werden alle verwendeten Testdaten, wie Zertifikats- und Sperrlistenextensions, Algorithmen etc. aufgeführt. In Abschnitt 5.1 werden allgemeine Daten dargestellt, die für alle verwendeten Zertifikate gelten. Diese Daten treffen ebenfalls für alle Sperrlisten zu, falls sie in Sperrlisten Verwendung finden. Die Zertifikate der PCA und der CA werden zusammen in dem Abschnitt 5.2 dargestellt, da die Extensions und Belegungen nur geringfügig differieren. Die Darstellung der Endanwender-Zertifikate erfolgt in dem Abschnitt 5.3. Die Erweiterungen der Sperrlisten und deren Belegung sind in Abschnitt 5.4 beschrieben. 5.1 Allgemeine Daten In Tabelle 1 sind allgemeine Testdaten aufgeführt, die alle Zertifikate und, falls verwendet, alle Sperrlisten betreffen. Kriterium Zertifikatsformat Sperrlistenformat X.509v3 CRLv2 Belegung Signatur-Algorithmus sha1withrsaencryption (OID ) Mögliche Attribute für Namen 1 Validity BusinessCathegory (BC), CommonName (CN=Nachname Titel Vorname Initial), Country (C), GivenName (GN), Locality (L), PostalCode (PC), OrganizationalUnit (OU), Organization (O), StateOrProvinceName (ST), Surname (SN), SerialNumber, Address ( ) UTC, GTC oder beide Public-Key-Länge PCA: 2048; CA und TN: 1024 oder 2048 Fingerprintalgorithmus SHA-1 Tabelle 1: Allgemeine Testdaten 1 Mehrfachnennung bei bestimmten Attributen des DN sind möglich. Bundesamt für Sicherheit in der Informationstechnik Seite 17 von 73

18 5.2 PCA- und CA-Zertifikate In Tabelle 2 werden die verwendeten Extensions des PCA-Zertifikats und der CA-Zertifikate und deren Belegung dargestellt. Extension Belegung des PCA-Zertifikats Belegung der CA-Zertifikate BasicConstraints (critical) CA-Flag pathlenconstraint True -1 CertificatePolicies policyidentifier CRLDistributionPoint distributionpoint KeyUsage (critical) KeyCertSign crlsign AuthorityKeyIdentifier authoritycertissuer authoritycertserialnumber True 3 ldap://test-x500.bund.de/cn=sphinx-wzs, O=Test-PKI, C=DE?certificate- RevocationList True True - - True True CN=SPHINX-WZS, O=Test-PKI, C=DE <Seriennummer des PCA-Zertifikats> Tabelle 2: Erweiterungen und Belegung der Zertifikate der Test-PCA und der CAs 5.3 Endanwender-Zertifikate In Tabelle 3 werden die Extensions und deren Belegung in Zertifikaten der Endanwender dargestellt. Extension Belegung der Endanwender-Zertifikate Certificate Policies policyidentifier CRLDistributionPoint distributionpoint KeyUsage (critical) Digital Signature Non Repudiation Key Encipherment AuthorityKeyIdentifier authoritycertissuer authoritycertserialnumber SubjectAlternativeName -Adresse ldap://test-x500.bund.de/cn=sphinx-zs1, O=Test-PKI, C=DE?certificate- RevocationList 1. Fall 2 2. Fall 3 3. Fall 4 True False True True False True False True True <DN des Ausstellers des CA-Zertifikats>5 <Seriennummer des CA-Zertifikats> local-part@domain.de Tabelle 3: Erweiterungen und Belegung der Endanwender-Zertifikate 2 Signaturzertifikat. 3 Verschlüsselungszertifikat. 4 Signatur- und Verschlüsselungszertifikat. 5 In diesem Fall CN=SPHINX-PCA, O=Test-PKI, C=DE. Bundesamt für Sicherheit in der Informationstechnik Seite 18 von 73

19 5.4 Sperrlisten In Tabelle 4 werden die bezüglich CRLv2-Sperrlisten verwendeten Extensions und deren Belegung aufgeführt. Extension AuthorityKeyIdentifier authoritycertissuer authoritycertserialnumber CRLNumber Belegung der Sperrlisten <DN des Ausstellers des CA-Zertifikats> <Seriennummer des CA-Zertifikats> <Laufende Nummer der Sperrliste> Tabelle 4: Erweiterungen und Belegung von Sperrlisten Bundesamt für Sicherheit in der Informationstechnik Seite 19 von 73

20 Bundesamt für Sicherheit in der Informationstechnik Seite 20 von 73

21 6 Beschreibung der Testfälle Um einen Überblick über die einzelnen Prüffälle zu erhalten, sind diese und deren Bezeichnung, aufgeteilt nach Testkategorien, im Abschnitt 6.1 in tabellarischer Form dargestellt. Die Testfälle sind nach Gutfall- und Schlechtfalltests unterteilt. Mittels der Gutfalltests werden die Interoperabilität und die generelle Funktionalität bzw. Basisfunktionalität ermittelt. Die entsprechenden Testfälle sind in Abschnitt 6.2 beschrieben. Mit den Schlechtfalltests (Abschnitt 6.3) werden praxisnahe Situationen nachgebildet, die Fehlermeldungen oder entsprechende Reaktionen der Produkte hervorrufen sollen. Für den Test werden willkürlich einige Fälle aus den beschriebenen Schlechtfalltestfällen ausgewählt, die dann mit allen Produkten durchgeführt werden. Die Gutfalltestfälle werden alle durchgeführt. 6.1 Übersicht der Testfälle In den beiden folgenden Abschnitten wird ein Überblick aller Testfälle in tabellarischer Form gegeben. Diese werden nach Gutfall- und Schlechtfalltest getrennt dargestellt Interoperabilität und Funktionalität (Gutfalltests) Kategorie Testfall Beschreibung 1 Konfiguration a Einstellen der -Adresse der Zertifizierungsstelle b Festlegen der Bestandteile des DN c Festlegen der Reihenfolge des DN d Vorbelegen des Root-Zertifikats e Nachladen weiterer Root-Zertifikate durch Supervisor 2 Schlüsselgenerierung a Dezentrale Schlüsselgenerierung b Zentrale Schlüsselgenerierung 3 Verwendung des Zeichensatzes 4 Reihenfolge im DN bei der Schlüsselerzeugung 5 PKI-Management-Nachrichten im Request-Format PKCS#10 6 PKI-Management-Nachrichten im Response-Format PKCS#7 7 Zusammenwirken mit Zertifizierungsstellen der PKI-1-Verwaltung a Verarbeiten eines vom Produkt erzeugten Requests von der CA b Verarbeiten eines von der CA erzeugten Replies vom Produkt c Verarbeiten einer von der CA erzeugten PKCS#12-Datei vom Produkt 8 PSE Management a Erzeugung einer PSE im Format PKCS#12 b Import einer PSE im Format PKCS#12 c PSE-Format PKCS#12 9 Management lokal gespeicherter Zertifikate a Export des Zertifikatsspeichers b Export und Import des gesamten Zertifikatsspeichers c Verarbeiten der Liste der vertrauenswürdigen Zertifizierungsstellen der Bridge-CA d Abfrage bei neuem Root-Zertifikat PKI-Management Bundesamt für Sicherheit in der Informationstechnik Seite 21 von 73

22 Kategorie Testfall Beschreibung 10 Zertifikate Zertifikate und Sperrlisten Nachrichtenaustauschformate Verzeichnisdienst Gültigkeitsprüfungen Token a b Korrekte Anzeige des Zertifikats im Format X.509v3 Korrekte Prüfung der Erweiterungen (Extensions in X.509v3-Zertifikaten) 11 DN-Attribute 12 Auswertung von Sperrlisten a b c Korrekte Anzeige der Sperrliste im Format CRLv2 Korrekte Anzeige der Sperrlistenextensions Aktualisierung der Sperrlisten 13 Prüfung des Zertifikatsspeichers gegen die Sperrliste 14 S/MIME-Formate 15 Interoperabilität zur virtuellen Poststelle 16 Mehrfachsignaturen a b Serielle Signaturen Parallele Signaturen 17 Endung auf.p7m 18 Quittungen 19 Aufheben der Verschlüsselung nach dem Lesen 20 Abspeichern versendeter Nachrichten in entschlüsselter Form 21 Aufprägen der Signatur 22 Konfiguration a b Default-Verzeichnis Weitere Verzeichnisse 23 Verzeichnisabfrage per LDAP a b LDAPv2 LDAPv3 24 Manuelle Suche im Verzeichnis per LDAP a b c Nach CommonName Nach -Adresse Suchabfrage mit Wildcards 25 Zeichensatz beim Abruf von Zertifikaten 26 Datenschutzkonformer Zugriff 27 Manueller Abbruch der Suche 28 Gültigkeitsmodell a b Schalenmodell Kettenmodell 29 Prüfung des Zertifizierungspfades 30 Unterstützte Chipkarten und leser a b c d Bestätigte Chipkarten Weitere Chipkarten Kartenleser Weitere Token Bundesamt für Sicherheit in der Informationstechnik Seite 22 von 73

23 Tabelle 5: Übersicht aller Gutfalltestfälle Schlechtfalltests Testfall Beschreibung 31 Abgelaufene Zertifikate 32 Interpretation von Sperrlisten 33 Nachricht endet nicht auf *.p7m 34 Prüfung der korrekten Auswertung der Zertifikatsextension KeyUsage aller Zertifikate a KeyCertSign b crlsign c digitalsignature d nonrepudiation e KeyEncipherment 35 Verhalten bei nicht vorhandener Sperrliste 36 Prüfung der Aktualität und Eignung von Sperrlisten 37 Fehlerhafte Signatur a in Zertifikaten b in Sperrlisten c in Nachrichten 38 Prüfung der korrekten Auswertung der Zertifikatsextension BasicConstraints 39 Sicheres Abspeichern von Entwürfen 40 Schutz von s mit Anhängen während der Erstellung Tabelle 6: Übersicht aller Schlechtfalltestfälle Bundesamt für Sicherheit in der Informationstechnik Seite 23 von 73

24 6.2 Interoperabilität und Funktionalität (Gutfalltests) In den folgenden Abschnitten werden die Gutfalltestfälle beschrieben PKI-Management Testfall 1 Konfiguration Bei dem Produkt müssen verschiedene Einstellungen bezüglich des PKI-Managements konfigurierbar sein. Diese sollten vom Supervisor (in Organisationen der IT-Administrator, sonst der Anwender) bei der Installation vorgenommen werden können. Eine weitere Variante ist die Vorbelegung durch den Hersteller, so dass die von einer Organisation bzw. vom Anwender gewünschte Konfiguration nach der Installation vorhanden ist. Testziel: Ermittlung, ob bei dem Produkt folgende Einstellungen konfigurierbar sind: a) -Adresse der Zertifizierungsstelle: Es sollen -Adressen von Zertifizierungsstellen voreingestellt werden können, an die Zertifizierungsanfragen von Anwendern gesendet werden. b) Bestandteile und Inhalt des DN: Es sollen die DN-Attribute festgelegt werden können, die Bestandteil des DN sein sollen. Nicht verwendete Attribute sollen ausgeblendet werden können. Der Inhalt bestimmter Attribute soll vorbelegt werden können (z.b. C=DE oder O=Bund oder -Adresse des Anwenders). c) Reihenfolge des DN: Es soll einstellbar sein, in welcher Reihenfolge die in b) gewählten Attribute im DN erscheinen. d) Vorbelegung des Root-Zertifikats durch den Hersteller: Das Root-Zertifikat soll nach der Installation bereits im lokalen Zertifikatsspeicher enthalten sein. e) Nachladen weiterer Root-Zertifikate durch Supervisor Rootzertifikate sollen in den lokalen Zertifikatsspeicher sicher nachgeladen werden können. Die Funktionalität soll das Aussprechen von Vertrauen umfassen. Testkategorie: Usability-Test Testart: Wirksamkeitsprüfung Bei Konfiguration durch Installierenden oder Anwender: - Vornehmen der Einstellungen. - Prüfen der Wirksamkeit der Einstellungen. Bei (Vor-)Konfiguration durch den Hersteller: - Prüfen der Wirksamkeit der Einstellungen. Erwartetes Ergebnis: Es wird erwartet, dass mindestens die genannten Einstellungen konfigurierbar sind und entweder vom Anwender, Administrator oder im Ausnahmefall dem Hersteller selbst vorgenommen werden können. Hinweis: Die gewünschte Konfiguration wird vorab allen Produktherstellern mitgeteilt, so dass diese vor Lieferung des Produkts an das Testlabor die Vorkonfiguration vornehmen können. Bundesamt für Sicherheit in der Informationstechnik Seite 24 von 73

25 Testfall 2 Schlüsselgenerierung Testziel: Ermittlung, ob das Produkt die dezentrale und zentrale Schlüsselerzeugung und weitere diesbezügliche Anforderungen (z.b. Schlüssellänge, Algorithmen etc.) beherrscht. Testkategorie: Usability-Test Testart: Blackbox- und visuelle Prüfung a) Dezentrale Schlüsselgenerierung - Erzeugen eines Schlüsselpaars für den jeweiligen Nutzer. - Prüfen der Übernahme des Schlüsselmaterials in eine PSE1. - Prüfen weiterer Anforderungen (z.b. Schlüssellänge, Algorithmen etc.) bei der Zertifizierung der öffentlichen Schlüssel mittels visueller Kontrolle. b) Zentrale Schlüsselgenerierung - Prüfen der Anforderung durch visuelle Kontrolle, ob zentral generierte Schlüssel in eine PSE eingelesen werden können. Erwartetes Ergebnis: Das Produkt muss die dezentrale Schlüsselerzeugung beherrschen und weitere Anforderungen, wie Schlüssellänge und Algorithmen, erfüllen. Das Produkt muss eine gesicherte PSE unterstützen. Es müssen die verwendeten Passworte auf Länge, verwendete Zeichen, Wiederholung alter Passworte, usw. geprüft werden und die Änderbarkeit des Passwortes unterstützt werden. Die PSE muss die Verwaltung mehrerer Schlüsselpaare für unterschiedliche Zwecke (Verschlüsselung, Signatur oder beides) beherrschen. Weiterhin wird erwartet, dass das Produkt zentral generierte Schlüssel einliest. 1 Im Testbed werden i.d.r. Software-PSE eingesetzt. In Ausnahmefälle können durch Produktbeistellungen der Hersteller auch Hardware-PSE (Smartcard) verwendet werden. Die Eigenschaften der jeweiligen Smartcard werden nicht mitgeprüft. Bundesamt für Sicherheit in der Informationstechnik Seite 25 von 73