TrustWeaver SigG Library v1.8

Transkript

1 HERSTELLERERKLÄRUNG TrustWeaver GmbH Buschkauler Weg Alfter erklärt hiermit gemäß 17 Abs. 4 Satz 2 SigG in Verbindung mit 15 Abs. 5 Satz 1 SigV, dass ihr Produkt die nachstehend genannten Anforderungen des Signaturgesetzes 1 und der Signaturverordnung 2 erfüllt. Alfter: gez. Anders Hellermark Geschäftsführer TrustWeaver GmbH Buschkauler Weg 27, Alfter Bonn HRB Diese Herstellererklärung mit der Dokumentennummer MD1 umfasst 12 Seiten. 1 Gesetz über Rahmenbedingungen für elektronische Signaturen und zur Änderung weiterer Vorschriften (Signaturgesetz SigG), zuletzt geändert durch Art. 3 (9) des Zweiten Gesetzes zur Neuregelung des Energiewirtschaftsgesetzes (EnWG) vom 07. Juli 2005 (BGBl. Jahrgang 2005, Teil I, Nr. 42) 2 Verordnung zur elektronischen Signatur (Signaturverordnung SigV), zuletzt geändert durch Art. 2 des Ersten Gesetzes zur Änderung des Signaturgesetzes (1. SigGÄndG) vom 04. Januar 2005 (BGBl. Jahrgang 2005, Teil I, Nr. 1)

2 1. Handelsbezeichnung Die Handelsbezeichnung lautet: Produktname: Auslieferung: wird auf einer CD-ROM ausgeliefert Hersteller: TrustWeaver GmbH Handelsregistereintrag: Bonn HRB Deutschland 2. Lieferumfang und Versionsinformationen Nachfolgend ist der Lieferumfang einschließlich der Versionsinformationen angegeben: Typ Name Version Auslieferungsart Software TrustWeaver SigG Library: sigglib.dll 1.8 CD-ROM Manual Hashwert (SHA1): b69eb88b0b1c6c94b29634aceaf4614be8b4b1cb Technische Beschreibung TrustWeaver SigG Library v 1.8 Hashwert: 99d67b77701c80bb6728eba6897b39b28f Per Download von repository/technischebesch reibung.pdf Tabelle 1: Lieferumfang und Versionsinformation Das Produkt verwendet die folgenden SigG-konformen Produkte, die nicht Teil der sind: Produktklasse Produktname/Hersteller Beschreibung und Registriernummer des Zertifikats SSEE 3 PKS-Card Version 3.01, Telesec/Deutsche Telekom SSEE konfiguriert zur Erzeugung von Massensignaturen; Registriernummer TUVIT TE (Nachtrag 2) SSEE Chipkartenleser D-TRUST-CARD_MS v1.0, D-Trust cyberjack PINpad version 3.0 by Reiner- SCT SSEE konfiguriert zur Erzeugung von Massensignaturen; Registriernummer TUVIT TE (Nachtrag vom ) Chipkartenleser; Registriernummer TUVIT TU Tabelle 2: Zusätzliche SigG-konforme Produkte 3 SSEE = Sichere Signaturerstellungseinheit Herstellererklärung Dokumentennummer MD1 Seite 2 von 12

3 Die SSEE in Tabelle 2 können wahlweise verwendet werden. 4 Die verwendet weitere technische Komponenten, die nicht im Lieferumfang des Produkts enthalten sind: Produkttyp Name Version Lieferung Software Software Anwendung Trust Server e-invoice Hersteller: TrustWeaver GmbH inkl. Trust Server Administrator s Guide File Checksum Integrity Verifier (FCIV) Hersteller: Microsoft 1.8 CD-ROM Per Download von der Webseite von Microsoft Tabelle 3: Weitere notwendige Produkte Die Anwendung Trust Server e-invoice wird in der Regel auf derselben CD-ROM geliefert wie die. Sie kann als Anwendung genutzt werden, um die TrustWeaver SigG Library zur Signierung und Prüfung elektronischer Rechnungen zu verwenden. Die Software FCIV wird zur Integritätsprüfung der gelieferten Software genutzt. Sie berechnet die Hashwerte der einzelnen Produktkomponenten und vergleicht sie mit den in Tabelle 1 angegebenen Werten. Zur vollständigen Erfüllung von 17 (2) Satz 1 SigG und 15 (2) Satz 1 Nr. 1c SigV sowie 17 (2) Satz 3 SigG können Applikationen von Drittanbietern eingesetzte werden, s. Weitere Informationen zur Anwendung im folgenden Kapitel. Ohne eine solche Applikation ist die Erfüllung der angegebenen Gesetzanforderungen wie in Tabelle 4 und 5 vermerkt nicht vollständig gegeben. 3. Funktionsbeschreibung Im Sinne des SigG ist das Produkt Teil einer Signaturanwendungskomponente. Die ist eine isolierte kryptografische Funktionsbibliothek, die zur Erzeugung und Prüfung SigG-konformer qualifizierter elektronischer Signaturen für elektronische Rechnungen ( e-invoices ) genutzt wird. Für die Prüfung qualifizierter elektronischer Signaturen enthält das Produkt außerdem einen OCSP-Client. ist für den Einsatz in Verbindung mit dem Produkt "Trust Server e-invoice" gedacht (siehe Tabelle 3), auf das im Folgenden als Anwendung verwiesen wird Zukünftig können weitere zulässige SSEE verwendet werden vorausgesetzt, dass ausreichende Integrationstests durchgeführt wurden und ein entsprechender Nachtrag zu dieser Herstellererklärung bei der Bundesnetzagentur vorgelegt worden ist. Diese Informationen werden vom Hersteller auf der Webseite veröffentlicht. Die ist prinzipiell auch für die Integration mit anderen Anwendungen konzipiert, die elektronische Rechnungen mit qualifizierten elektronischen Signaturen verarbeiten. Um die Herstellererklärung Dokumentennummer MD1 Seite 3 von 12

4 Die Erzeugung qualifizierter elektronischer Signaturen geschieht im Zusammenhang mit mindestens einer SigG-konformen SSEE (siehe Tabelle 2). ist aus Gründen der Skalierbarkeit zur parallelen Durchführung von Transaktionen mit mehreren SSEE entwickelt worden. Bei jeder verwendeten SSEE wird der PIN-Code nur über das PIN-Pad des Kartenlesers eingegeben und zu keinem Zeitpunkt außerhalb der SSEE gespeichert 6. Durch die Eingabe der PIN wird die SSEE für die Erzeugung einer unbegrenzten Anzahl von Signaturen aktiviert. Die nach dem Signaturgesetz auch für den Fall von Massensignaturen erforderliche Begrenzungen der Signaturerzeugung (nach Anzahl der erzeugbaren Signaturen oder nach einem Zeitfenster), nach der eine erneute PIN-Eingabe erforderlich wird, werden durch die Anwendung vorgegeben, welche die nutzt. Der Signaturprozess verläuft wie folgt: a. Die Anwendung wählt den Hash-Algorithmus, der für die Signatur verwendet werden soll. b. Die erzeugt mittels des gewählten Algorithmus einen Hashwert über die durch die Anwendung bereitgestellte elektronische Rechnung. c. Die ausgewählte SSEE signiert den Hashwert im PKCS #1-Format. Die möglichen RSA-Schlüssellängen werden durch die verwendete SSEE vorgegeben 7. d. Die sendet die PKCS #1-Signatur an die Anwendung zurück. Die Signatur- und Zertifikatsprüfung geschieht auf der Basis des Kettenmodells und mittels des OCSP-Clients, der in die integriert ist. Die Prüfung des Zertifikats umfasst den gesamten Zertifikatsbaum bis zur Wurzel-Zertifizierungsstelle. Der Prüfungsprozess verläuft wie folgt: a. Die durch die Anwendung bereitgestellte (signierte) elektronische Rechnung wird gehasht 8. b. Die PKCS#1-Signatur wird mittels des öffentlichen Schlüssels im Signaturzertifikat entschlüsselt. c. Der Hashwert aus Schritt a wird mit dem entschlüsselten Hashwert aus Schritt b verglichen. Bei Übereinstimmung der Werte ist die Signatur kryptografisch korrekt. d. Das Signaturzertifikat wird wie folgt überprüft: Die CA-Signatur wird mithilfe des CA-Zertifikats kryptografisch überprüft. Das Ablaufdatum wird überprüft. Der Zertifikatsstatus (zum Zeitpunkt des Aufrufs) wird vom OCSP-Responder der CA abgerufen und geprüft. e. Das CA-Zertifikat wird wie folgt überprüft: Die CA-Signatur wird mittels des Wurzelzertifikats kryptografisch überprüft. Das Ablaufdatum wird überprüft. Integration mit anderen Applikationen zu ermöglichen, verfügt die SigG Library über eine C#-Schnittstelle. Bei der Verwendung mit anderen Anwendungen gilt diese Herstellererklärung jedoch nicht Dies bedeutet, dass es keinen automatisierten Prozess gibt, der den PIN-Code nach Eingabe auf dem PC speichert, zum Zwecke der Signaturerzeugung bereitstellt und an die SSEE überträgt. Ab dem 1. Januar 2008 ist ausschließlich die Nutzung deutscher SSEE mit einer Schlüssellänge von 2048 Bit vorgesehen. Folgende Hash-Algorithmen werden unterstützt: SHA1 (160 Bit), SHA256, SHA384, SHA512, RIPEMD160. Herstellererklärung Dokumentennummer MD1 Seite 4 von 12

5 Soweit anwendbar 9 wird der Zertifikatsstatus des CA-Zertifikats vom OSCP- Responder der Bundesnetzagentur abgerufen und geprüft. f. Die sendet die Prüfungsergebnisse (Signaturprüfung und Rückmeldungen des OCSP-Responders) an die Anwendung zurück. Weitere Informationen zur Anwendung: Die Anwendung "Trust Server e-invoice" umfasst drei logische Komponenten, die die kryptografischen und weitere Funktionen der verwenden: Signaturdienst : Eine (nach SigG und SigV) zu signierende elektronische Rechnung wird dem Signaturdienst über das Web übermittelt (SSL-gesichert, Client-Authentisierung). Nach der Entgegennahme übergibt der Signaturdienst die elektronische Rechnung an die zur Erzeugung einer qualifizierten elektronischen Signatur 10. Zur Erzeugung der Signatur wählt der Signaturdienst anhand der Charakteristiken der Rechnung eine geeignete (z.b. kunden- bzw. länderspezifische) SSEE aus. Durch den beschriebenen Ablauf ist eine eindeutige Korrespondenz zwischen zu signierender Datei und der zu nutzenden SSEE gegeben ( 17(2) Satz 1 SigG). Verifikationsdienst : Eine signierte, (nach SigG und SigV) zu prüfende elektronische Rechnung wird dem Verifikationsdienst über das Web übermittelt (SSL-verschlüsselt, Server-Authentisierung 11 ). Der Verifikationsdienst akzeptiert elektronische Rechnungen in den in der Fußnote 12 aufgeführten Formaten. Er übermittelt jedoch ausschließlich die extrahierte PKCS #1-Signatur an die TrustWeaver SigG Library v1.8, die ihrerseits die Verifikationsergebnisse zurückgibt 13. Die Verifikationsergebnisse (Prüfprotokoll) werden zusammen mit der signierten elektronischen Rechnung unter der Kontrolle des Archivprüfdienstes gelagert (siehe folgender Absatz). Archivprüfdienst : In Verbindung mit der Installation des Trust Server gibt der Hersteller Richtlinien zur Konfiguration eines Archivs für elektronische Rechnungen vor. Bei der Nutzung des Archivs hat der Nutzer die Möglichkeit, elektronische Rechnungen einzeln zu extrahieren 14 und der erneuten Verifikation durch den Archivprüfdienst 15 zuzuführen. Die Signaturprüfung (mathematisch und mittels OCSP- Anfragen) wird durch die durchgeführt. Der Signaturdienst kann getrennt von den anderen Diensten (Verifikations- und Archivprüfdienst) installiert und ausgeführt werden. Zu diesem Zweck ist es möglich, Trust Server e-invoice entweder auf zwei verschiedenen physikalischen Servern oder aber verschiedenen virtuellen Servern (z.b. mithilfe von VMware) auf demselben physikalischen Server zu installieren. Ein Server führt ausschließlich Signaturoperationen aus, während der andere Server Operationen zur Verifikation und Archivprüfung von Signaturen ausführt. Zusätzlich stellt die Applikation "Trust Server e-invoice" einer geeigneten Anwendung eines Drittanbieters, die dem autorisierten Unterzeichner Rechnungen anzeigt und die Optionen accept / deny zur Auswahl anbietet, ein Kontroll- Interface bereit. Bei Bedarf sendet das Interface die zu signierende Rechnung und erwartet die Antwort accept (true) oder deny (false); im Fall von accept wird die Rechnung durch signiert, im Fall deny dagegen nicht Dies ist nicht anwendbar, wenn die CA lediglich einen angezeigten Betrieb fährt und nicht akkreditiert ist. Im angezeigten Fall endet der Zertifikatsbaum beim Wurzelzertifikat, das normalerweise durch den CA selbst ausgestellt wurde. Derzeit werden die folgenden Signaturformate unterstützt: PKCS #7, CAdES-T/A, XML Signatur, XAdES-T/A, S/MIME, PDF Signatur. Andere Signaturformate basierend auf PKCS #1 können in zukünftigen Versionen von Trust Server aufgenommen werden. Je nach Einsatzgebiet erfordert ein Reverse-Proxy Client-Authentisierung auch für den Verifikationsdienst. Die folgenden Signaturformate können geprüft werden: PKCS #7, CAdES-T/A, XML Signatur, XAdES-T/A, S/MIME, PDF Signatur. Andere Signaturformate basierend auf PKCS #1 können in zukünftigen Versionen von Trust Server aufgenommen werden. Dies geschieht durch die Kontaktaufnahme mit OCSP-Respondern (1) der entsprechenden deutschen CA, die das Signaturzertifikat zur Verfügung stellt, sowie gegebenenfalls (2) der Wurzel-Zertifizierungsstelle der Bundesnetzagentur. Im Falle von archivierten elektronischen Rechnungen mit CAdES-A- oder XAdES-A-Signaturen (mit darin enthaltenen Zertifikats- und Statusinformation) wird der Verifikationsprozess ohne Nutzung von Online- Diensten durchgeführt. Der Dienst wird über das Web abgerufen (SSL-gesichert, Server-Authentisierung). Herstellererklärung Dokumentennummer MD1 Seite 5 von 12

6 4. Erfüllung der Anforderungen des Signaturgesetzes und der Signaturverordnung Die folgende Tabelle beschreibt den Erfüllungsgrad der Anforderungen des Signaturgesetzes durch das Produkt, ggf. in Verbindung mit Produkten in Einsatzumgebung. In der 3. und 4. Spalte bezeichnet P das Produkt und A die Anwendung "Trust Server e-invoice". Anforderung Erfüllung Erläuterung 17 (2) Satz 1 Für die Darstellung zu signierender Daten sind Signaturanwendungskomponenten erforderlich, die die Erzeugung einer qualifizierten elektronischen Signatur vorher eindeutig anzeigen und feststellen lassen, auf welche Daten sich die Signatur bezieht. teilweise 16 durch A ablaufbedingt gegeben (1) Eine Prozedur zur Einbeziehung des Nutzers steht zur Verfügung. (2) A übergibt die zu signierenden Daten Datei für Datei an P, die ihrerseits die ausgewählte SSEE ansteuert; somit ist ein eindeutiger Bezug zwischen Signiervorgang und betreffender Datei durch den Ablauf gegeben, d. h. es ist feststellbar, auf welche Daten sich die Signatur bezieht. 16 vgl. Ende des Abschnitts Weitere Informationen zur Anwendung. Die Anwendung A bietet ein entsprechendes Interface für eine Anwendung eines Drittanbieters an. Für den Kontext von Massensignaturen ist die Einbeziehung des Nutzers für jede einzelne Signatur jedoch nicht üblich. Herstellererklärung Dokumentennummer MD1 Seite 6 von 12

7 17 (2) Satz 2 Für die Überprüfung signierter Daten sind Signaturanwendungskomponenten erforderlich, die feststellen lassen, 1. auf welche Daten sich die Signatur bezieht, durch P in Verbindung mit A. 1. A übergibt die zu überprüfenden Daten Datei für Datei an P, aus dem Ablauf ist somit eindeutig feststellbar, auf welche Daten sich die Signatur bezieht. 2. ob die signierten Daten unverändert sind, durch P 2. s. Beschreibung des Prüf- Ablaufs in Kapitel 3 (Punkte a-f) 3. welchem Signaturschlüssel- Inhaber die Signatur zuzuordnen ist, durch P 3. s. Beschreibung des Prüf- Ablaufs in Kapitel 3 (Punkte a-f) 4. welche Inhalte das qualifizierte Zertifikat, auf dem die Signatur beruht, und zugehörige qualifizierte Attribut-Zertifikate aufweisen und teilweise 17 durch P in Verbindung mit A 4. s. Beschreibung des Prüf- Ablaufs in Kapitel 3 (Punkte a-f). Die Zertifikatsinhalte werden im Prüfprotokoll (s. Nr. 5) wiedergegeben. Es werden von P keine Attributzertifikate verwendet / ausgewertet. 5. zu welchem Ergebnis die Nachprüfung von Zertifikaten nach 5 Abs. 1 Satz 3 geführt hat. durch P in Verbindung mit A 5. Die von P an A übergebenen Verifikationsergebnisse werden dem Anwender von A in einem Prüfprotokoll zur Verfügung gestellt. 17 (2) Satz 3 Signaturanwendungskomponenten müssen nach Bedarf auch den Inhalt der zu signierenden oder signierten Daten hinreichend erkennen lassen. teilweise 18 durch A Eine Anzeige des Inhalts einer Datei vor / nach der Signaturerzeugung ist bei Bedarf möglich. Tabelle 4: Erfüllung des Signaturgesetzes Die folgende Tabelle beschreibt den Erfüllungsgrad der Anforderungen der Signaturverordnung durch das Produkt, ggf. in Verbindung mit Produkten in Einsatzumgebung Die Einschränkung teilweise bezieht sich darauf, dass keine Attributzertifikate verwendet / ausgewertet werden. Für den Fall signierten Daten : s. Beschreibung der Archivprüfdienstes im Abschnitt Weitere Informationen zur Anwendung. Für den Fall zu signierende Daten vgl. Fußnote 16. Herstellererklärung Dokumentennummer MD1 Seite 7 von 12

8 Anforderung Erfüllung Erläuterung 15 (2) Satz 1 Signaturanwendungskomponenten nach 17 Abs. 2 des Signaturgesetzes müssen gewährleisten, dass 1. bei der Erzeugung einer qualifizierten elektronischen Signatur a) die Identifikationsdaten nicht preisgegeben und diese nur auf der jeweiligen sicheren Signaturerstellungseinheit gespeichert werden, b) eine Signatur nur durch die berechtigt signierende Person erfolgt, c) die Erzeugung einer Signatur vorher eindeutig angezeigt wird und 2. bei der Prüfung einer qualifizierten elektronischen Signatur a) die Korrektheit der Signatur zuverlässig geprüft und zutreffend angezeigt wird und b) eindeutig erkennbar wird, ob die nachgeprüften qualifizierten Zertifikate im jeweiligen Zertifikat- Verzeichnis zum angegebenen Zeitpunkt vorhanden und nicht gesperrt waren. 15 (4) Sicherheitstechnische Veränderungen an technischen Komponenten nach den Absätzen 1 bis 3 müssen für den Nutzer erkennbar werden. durch die in der Einsatzumgebung verwendeten Chipkartenleser durch die SSEE in Verbindung mit A teilweise durch A durch P durch A in Verbindung mit P durch P durch Maßnahmen in der Einsatzumgebung 1a) PIN-Eingabe erfolgt durch den Karteninhaber ausschließlich an der sep. Tastatur des sicherheitsbest. Kartenlesers 1b) Durch zutreffende Auswahl der Karte durch A i.v. mit der PIN-Eingabe 1c) Bei Bedarf kann der Karteninhaber sich in den Workflow einklinken und eine Anzeige erhalten; im Normalbetrieb bei Massensignaturen ist dies nicht sinnvoll. 2a) Die Verifikation wird von P durchgeführt. Die von P an A übergebenen Verifikationsergebnisse werden dem Anwender von A in einem Prüfprotokoll zur Verfügung gestellt. 2b) Erforderliche Daten werden von P erstellt (und sind im Prüfprotokoll enthalten). Vergleich von Hashwerten der SW-Komponenten mit Referenzwerten. Tabelle 5: Erfüllung der Signaturverordnung Herstellererklärung Dokumentennummer MD1 Seite 8 von 12

9 5. Maßnahmen in der Einsatzumgebung 5.1 Technische Einsatzumgebung benötigt die folgende Hard- und Software: ein IBM-kompatibler Computer mit mindestens 256 MB RAM und mindestens 200 MB freiem Festplattenspeicherplatz Betriebssystem Microsoft Windows Server 2003 SP1 oder höher Microsoft.NET Framework Release 2.0 Software "Trust Server e-invoice" (Anwendung, siehe Tabelle 3) mindestens ein Kartenlesegerät (siehe Tabelle 2) mindestens eine SSEE (siehe Tabelle 2) Microsoft File Checksum Integrity Verifier (FCIV) (siehe Tabelle 3) Anwendung Trust Server e-invoice (siehe Tabelle 3). Das Produkt ist ausschließlich mit der oben beschriebenen Hard- und Software zu nutzen. Die und dazugehörige Anwendung sollten in einer geschützten technischen Einsatzumgebung betrieben werden. Die erforderlichen Rahmenbedingungen sowie die Einrichtung der technischen Komponenten (Auslieferungskontrolle, Konfiguration und Installation) sind in Technische Dokumentation: (siehe Tabelle 1) und in Trust Server Administrator s Guide (siehe Tabelle 3) beschrieben. Diese Richtlinien berühren folgende Themen: Sicherung des Betriebssystems Netzwerk- und Firewallkonfiguration Konfiguration des Betriebssystems und Definition des Patch-Levels Betrieb in einer virusfreien Umgebung (je nach der Systemumgebung des Kunden besteht die Notwendigkeit des Einsatzes von Antiviren-Software) Sicherheitsscans und Backup-Prozeduren (hauptsächlich zur Sicherung des Geschäftsbetriebs), Konfiguration der Anwendung Trust Server e-invoice, insbesondere das Problem der Begrenzung der Anzahl von Signaturen (durch die Anwendung) betreffend. Diese Richtlinien müssen befolgt werden. 5.2 Lieferung und Installation Das Produkt wird auf einer CD-ROM an den Kunden ausgeliefert. Als Standardprozedur wird die CD-ROM einem Vertreter des Kunden durch den Hersteller überreicht. Eine Lieferung der CD-ROM per Post oder Kurierdienst ist als Alternative möglich. Diese Lieferungsprozedur darf nicht geändert werden. Vor der Installation muss die Integrität der gelieferten Software geprüft werden, indem der File Checksum Integrity Verifier von Microsoft genutzt und ein Vergleich der berechneten Hashwerte mit den in Tabelle 1 vorgegebenen Werten vorgenommen wird, müssen sämtliche physikalischen und administrativen Sicherheitsmaßnahmen sowie die Konfigurationen der Hardware-/Software-Ausstattung aus Abschnitt 5.1, des Netzwerks und der Firewall auf die Erfüllung der Anforderungen und Richtli- Herstellererklärung Dokumentennummer MD1 Seite 9 von 12

10 nien in der "Technischen Dokumentation: TrustWeaver SigG Library v 1.8" und Trust Server Administrator s Guide überprüft werden, muss bestätigt werden, dass sämtliche Anforderungen erfüllt sind, die in den Sicherheitsbestätigungen der SSEE und Kartenleser (siehe Tabelle 2) aufgeführt sind. Die Installation darf nur durch ausgebildetes und erfahrenes Personal erfolgen. 5.3 Betrieb Die gemeinsame Einsatzumgebung für TrustWeaver SigG Library v 1.8 und die in Abschnitt 5.1 aufgeführte Hardware/Softwareausstattung muss die Charakteristik eines Rechenzentrums mit hoher Sicherheit besitzen. Im Sinne der "Einheitlichen Spezifizierung der Einsatzbedingungen für Signaturanwendungskomponenten" 19 ist die erforderliche Einsatzumgebung als geschützter Einsatzbereich klassifiziert. Zum Schutze der Einsatzumgebung sind angemessene administrative, physische und organisatorische Sicherheitsmaßnahmen zu treffen. Details sind der "Technical Dokumentation: TrustWeaver SigG Library v 1.8" und Trust Server Administrator s Guide zu entnehmen. Die wichtigsten Punkte sind in der folgenden Liste aufgeführt: Der Zugang zu dem Bereich, in dem die, die Produkte laut Tabelle 2 und die Anwendung betrieben werden, sollte streng kontrolliert werden. Die Nutzung starker Authentisierungsmechanismen (z.b. Smartcards, biometrische Systeme) wird empfohlen. Der Bereich sollte über Überwachungssysteme wie Videoüberwachung (optional in einem eigenen Netz betrieben), Bewegungssensoren und Alarmsysteme verfügen. Der Zugriff auf die, die Produkte in Tabelle 2 und die Anwendung muss physikalisch und logisch geschützt sein, z.b. durch verschließbare Serverracks und die Nutzung spezifischer kopiergeschützter Schlüssel. Die SSEEen müssen mithilfe eines dafür vorgesehenen Siegels mit dem Kartenleser versiegelt werden um jeglichen Versuch, eine SSEE zu entfernen oder auszutauschen, erkennbar zu machen. Die Siegel müssen in regelmäßigen Abständen überprüft werden. Die Nutzung eines Protokollbuchs ist dringend erforderlich. In regelmäßigen Abständen ist ein Vergleich zwischen den Hashwerten der installierten Binärversionen (mindestens) der einschließlich der Anwendung und denen der Originaldateien auf der CD-ROM durchzuführen 20. Die ist mit der beschriebenen Hardware-/ Softwareausstattung ausschließlich von vertrauenswürdigem Personal zu betreiben. Zur Identifikation verwendete Informationen (PIN) müssen streng geheim gehalten werden und dürfen nicht an unautorisierte Personen weitergegeben werden. Ein rollenbasiertes Sicherheitskonzept muss angewendet werden und mindestens die folgenden Rollen umfassen: "Sicherheitsbeauftragter" (Managementverantwortung für das gesamte Trust Server System), zwei "Administratoren" (Installation, Betrieb und Wartung; ein Administrator für den Signaturdienst, ein Administrator für den Verifikations- und Archivprüfdienst), "Autorisierter Unterzeichner" (Inhaber der verwendeten SSEE) Bei der Bundesnetzagentur erhältlich; aktuelle Version: 1.4 vom Diese Operation sollte je nach der Anzahl der erzeugten Signaturen wöchentlich bzw. monatlich durchgeführt werden. Herstellererklärung Dokumentennummer MD1 Seite 10 von 12

11 Um den erforderlichen Grad an Sicherheit aufrechtzuerhalten, muss die vollständige und andauernde Erfüllung aller Anforderungen während des Betriebs garantiert werden. Vor einer Modifikation der Einsatzumgebung ist eine gründliche Analyse vorzunehmen, um zu vermeiden, dass bekannte Schwachstellen in der Konstruktion und/oder im Betrieb der, der Anwendung und der Produkte in Tabelle 2 ausgenutzt werden können oder neue Schwachstellen auftreten. Mit Auslieferung der ist der Kunde darauf hinzuweisen, die für den Betrieb der und der Anwendung vorgeschriebenen Bedingungen zu erfüllen und aufrechtzuerhalten. 6. Algorithmen und zugehörige Parameter Das Produkt stellt für die Verifikation von Signaturen die folgenden Hash-Funktionen bereit: SHA1 (160 Bit), SHA256, SHA384, SHA512 und RIPEMD160. Für Signieroperationen wird je nach Typ der sicheren Signaturerstellungseinheit mindestens SHA1 als Hash-Funktion verwendet. Sofern die sichere Signaturerstellungseinheit SHA256 unterstützt, wird diese Hash-Funktion standardmäßig verwendet. Entsprechend der "Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der Signaturverordnung (Übersicht über geeignete Algorithmen)" 21 sind die Hash-Funktionen als sicher freigegeben bis mindestens Ende für SHA1 Ende 2010 für RIPEMD160, Ende 2011 für SHA256, SHA384, SHA512 Das Produkt verwendet zur SigG-konformen Prüfung von Signaturen den RSA-Algorithmus mit möglichen Schlüssellängen von 1024 and 2048 Bit. Entsprechend der "Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der Signaturverordnung (Übersicht über geeignete Algorithmen)" ist RSA als sicher freigegeben bis mindestens Ende 2007 Schlüssellänge 1024 Bit über das Jahr 2011 hinaus Schlüssellänge 2048 Bit. 7. Gültigkeit der Herstellererklärung Der Gültigkeitszeitraum dieser Herstellererklärung ist von der Schlüssellänge des RSA-Algorithmus (bei der Verifikation von Signaturen) und der gewählten Hash-Funktion (bei der Verifikation und Erzeugung von Signaturen) abhängig. Tabelle 6 listet die Mindest-Gültigkeit für die möglichen Kombinationen auf. Hash-Funktion/ RSA- Schlüssellänge SHA1 SHA256 SHA384 SHA512 RIPEMD Tabelle 6: Gültigkeit dieser Herstellererklärung Bei der Bundesnetzagentur verfügbar (letzte Ausgabe vom 12. April 2007) 2010 nur für die Signierung und Prüfung von Zertifikaten Herstellererklärung Dokumentennummer MD1 Seite 11 von 12

12 Im Zweifelsfall kann der Status dieser Herstellererklärung bei der Bundesnetzagentur erfragt werden. 8. Zusatzdokumentation Folgende Bestandteile der Herstellererklärung wurden aus dem Veröffentlichungstext ausgegliedert und bei der zuständigen Behörde hinterlegt: Sicherheitsvorgaben, Dokument MD2, 18 Seiten Testdokumentation, Dokument MD3, 19 Seiten Ende der Herstellererklärung. Herstellererklärung Dokumentennummer MD1 Seite 12 von 12