HERSTELLERERKLÄRUNG. Der Hersteller. secunet Security Networks AG Kronprinzenstraße Essen (HRB 13615, Amtsgericht Essen)

Transkript

1 Stand: HERSTELLERERKLÄRUNG Der Hersteller secunet Security Networks AG Kronprinzenstraße Essen (HRB 13615, Amtsgericht Essen) erklärt hiermit gemäß 17 Abs. 4 Satz 2 SigG 1 in Verbindung mit 15 Abs. 5 Satz 1 SigV 2, dass sein Produkt multisign Enterprise, Version als Teil-Signaturanwendungskomponente die Anforderungen des Signaturgesetzes 1 bzw. der Signaturverordnung 2 erfüllt und die Erzeugung und Verifizierung von qualifizierten elektronischen Signaturen unterstützt. Essen, den Essen, den gez. Thomas Pleines Vorstand secunet Security Networks AG gez. ppa. Thomas Stürznickel Leiter Geschäftsbereich secunet Security Networks AG Diese Herstellererklärung in Version 1.5 mit der Dokumentennummer HE_multisign_Enterprise_4.1.1 besteht aus 33 Seiten. 1 Gesetz über Rahmenbedingungen für elektronische Signaturen (Signaturgesetz SigG) vom 16. Mai 2001 (BGBl. I S. 876), zuletzt geändert durch Artikel 4 des Gesetzes vom 17. Juli 2009 (BGBl. I S. 2091). Im Folgenden kurz SigG oder Signaturgesetz genannt. 2. Verordnung zur elektronischen Signatur (Signaturverordnung SigV) vom 16. November 2001 (BGBl. I S. 3074), zuletzt geändert durch die Verordnung vom 15. November 2010 (BGBl. I S. 1542). Im Folgenden kurz SigV oder Signaturverordnung genannt.

2 Dokumentenhistorie Version Datum Autor Bemerkung Jürgen Foß Initialversion Jürgen Foß Einarbeitung der Kommentare aus dem MTG-Prüfbericht vom Jürgen Foß Einarbeitung der Kommentare aus dem MTG-Prüfbericht vom Jürgen Foß Neue Version 4.1.1: Erweiterung des Auslieferungsverfahrens, Änderung einer Betriebssystemplattform von SunOS nach Linux 64bit, Versionsanpassungen und Referenzaktualisierungen Thorsten Weins, Jürgen Foß Einarbeitung der Kommentare aus dem atsec-prüfbericht vom Jürgen Foß Einarbeitung der Kommentare aus dem atsec-prüfbericht vom HE_multisign_Enterprise_4.1.1 Seite 2 von 33

3 1. Handelsbezeichnung Die Handelsbezeichnung lautet: multisign Enterprise, Version Auslieferung: Hersteller: Handelsregisterauszug: Variante 1 (Server-Plattform): CD-ROM (persönliche Übergabe) oder FTP-Server. Variante 2 (Signaturbox): vorinstalliert auf einer CompactFlash-Karte, die fest innerhalb der Signaturbox eingebaut ist (persönliche Übergabe) Updates via FTP-Server secunet Security Networks AG HRB 13615, Amtsgericht Essen Die vorliegende Herstellererklärung bezieht sich auf das Software-Produkt multisign Enterprise, Version (im folgenden multisign Enterprise genannt) des Herstellers secunet Security Networks AG, HRB 13615, Amtsgericht Essen. Bei diesem Produkt handelt es sich um eine Teil-Signaturanwendungskomponente. Die Auslieferung durch den Hersteller erfolgt für Variante 1 (Server-Plattform) entweder auf einer CD-ROM, die persönlich übergeben wird oder durch Bereitstellung der Module auf einem FTP-Server des Herstellers nach einem Auslieferungsverfahren, bei welchem die Integrität und Authentizität der ausgelieferten Software durch Hashsummen gewährleistet wird. Für Variante 2 (Signaturbox) erfolgt die Erstauslieferung durch den Hersteller auf einer CompactFlash-Karte, die fest innerhalb einer verschlossenen und versiegelten Signaturbox eingebaut ist und im Updatefall durch Bereitstellung der Software auf einem FTP-Server des Herstellers nach einem Auslieferungsverfahren, bei welchem die Integrität und Authentizität der ausgelieferten Software durch eine Signatur über die Software gewährleistet wird, welche durch die verschlossene und versiegelte Signaturbox geprüft wird. Zusätzlich zur Signaturbox wird die Client-API Bibliothek entweder auf CD-ROM oder durch Bereitstellung auf einem FTP-Server des Herstellers ausgeliefert. Hierbei handelt es sich um eine Funktionsbibliothek, die alleine nicht lauffähig ist und von einem Anwendungsentwickler verwendet werden kann, um die Funktionalität von multisign Enterprise über das Network-Interface zu nutzen. Die weiterführenden Hinweise zum Auslieferungsverfahren und zur Installation in Kapitel 5.3 sind zu beachten. 2. Lieferumfang und Versionsinformationen 2.1 Variante 1 (Server-Plattform) Zum Lieferumfang gehörende Komponenten Die Auslieferung des Produkts umfasst folgende Bestandteile, die gemäß Kapitel 5.3 entweder auf CD-ROM oder via FTP-Server zur Verfügung gestellt werden: Bezeichnung Beschreibung Version / Datum / Übergabeform signaturserver Ausführbares Programm des Signaturservers unter / / HE_multisign_Enterprise_4.1.1 Seite 3 von 33

4 Linux 32 Bit und 64 Bit libsignserverclientapi.a/.so libsignserverclientapi.a/.so libsignserverclientapi.a/.so ClientApi.dll ClientApi.lib ClientCAPI.h ClientAPITypes.h SharedClientApiTypes.h CertificateDatabase.dat configmodule.ini signaturserver.conf HE_multisign_Enterprise_B D_4.1.1.pdf Statische/Dynamische Client-API-Bibliothek für Linux, 32-Bit-Variante Statische/Dynamische Client-API-Bibliothek für Solaris, 32-Bit-Variante Statische/Dynamische Client-API-Bibliothek für Linux, 64-Bit-Variante Dynamische Client-API- Bibliothek für Windows 32 Bit Stublib zum Einbinden der dyn. Client-API-Bibliothek für Windows 32 Bit Headerdatei zu den Client- API-Funktionsbibliotheken Headerdatei zu den Client- API-Funktionsbibliotheken Headerdatei zu den Client- API-Funktionsbibliotheken Zertifikatsdatenbank des Signaturservers Konfigurationsdatei für die vom Signaturserver genutzte Funktionsbibliothek Lib- SigG Konfigurationsdatei des Signaturservers Benutzerdokumentation / / / / / / / / / / Revision 16 / / Revision 18 / / Revision 10 / / Ohne Version / / Ohne Version / / Ohne Version / / Version 1. / Stand / Digitale Form Hashsummen_multisign txt Textdatei mit Hashwerten Version / Tabelle 1: Lieferumfang und Versionsinformationen für Variante 1 (Server-Plattform) HE_multisign_Enterprise_4.1.1 Seite 4 von 33

5 Bei den clientseitigen Bestandteilen (Client-API Bibliothek) handelt es sich um eine Funktionsbibliothek, die alleine nicht lauffähig ist und von einem Anwendungsentwickler verwendet werden kann, um die Funktionalität von multisign Enterprise über das Network-Interface zu nutzen Nicht zum Lieferumfang gehörende Komponenten (SigG bestätigt) Die Verwendung sicherer Signaturerstellungseinheiten nach 17 Abs. 1 Signaturgesetz, bzw. 15 Abs. 1 Signaturverordnung, sowie nach den Anforderungen von Signaturgesetz und Signaturverordnung geprüfter und bestätigter Chipkarten-Terminals, wird vorausgesetzt. Diese gehören nicht zum Lieferumfang und sind nicht Gegenstand dieser Erklärung. Die Auflagen aus den Bestätigungen zu den Produkten sind zwingend einzuhalten. Erst dann ist die Sicherheit der jeweiligen Komponente gewährleistet, wie sie in der zugehörigen Bestätigung angegeben wird. Insbesondere handelt es sich hierbei um folgende Komponenten: Produktklasse Bezeichnung Bestätigung SSEE G&D Starcos 3.2 QES Version 2.0 BSI TE Nachtrag zur Bestätigung vom : T-Systems TU Kartenleser Reiner cyberjack e-com; Version 3.0 TUVIT TE Tabelle 2: Zusätzliche SigG bestätigte Produkte für Variante 1 (Server-Plattform) Sonstige, nicht zum Lieferumfang gehörende Komponenten Produktklasse Beschreibung Compiler Die Einbindung der Client-API Bibliothek in eine Applikation zur Nutzung des Network-Interface muss mit einem C-Compiler realisiert werden, dessen Befehlssatz der ANSI/ISO C Norm entspricht. Unter Windows kann dies beispielsweise mit Microsoft Visual C++ 9.0, unter Unix mit dem Compiler gcc 3.4 erfolgen. Tabelle 3: Zusätzliche nicht SigG bestätigte Produkte für Variante 1 (Server-Plattform) 2.2 Variante 2 (Signaturbox) Zum Lieferumfang gehörende Komponenten Das Produkt wird gemäß Kapitel 5.3 ausgeliefert. Des Weiteren wird ein Tool zur Konfiguration der Signaturbox ( Boxkonfigurator ) bei Erstinstallation an den Kunden auf einer separaten CD-ROM oder im Updatefall via FTP-Server gemäß Kapitel 5.3 ausgeliefert. HE_multisign_Enterprise_4.1.1 Seite 5 von 33

6 Das Kartenlesegerät ist fest in das versiegelte Gehäuse der Signaturbox integriert. Es handelt sich um das Gerät: Reiner cyberjack e-com, Version 3.0, Bestätigungs-ID: TU- VIT TE Das Produkt hat folgende Komponenten: Bezeichnung Beschreibung Version / Übergabeform Signaturbox Signaturbox-Hardware mit folgende Eigenschaften: - Betriebssystem Linux (Kernel = 2.6) - x86 kompatibler Prozessor - mindestens 256 MB-RAM - keine Festplatte und kein CD- ROM-Laufwerk - mindestens 32 MB Compact- Flash Card - eine USB-Schnittstelle (intern) - eine USB-Schnittstelle (extern) - ein eingebauter USB- Chipkartenleser Reiner cyberjack e-com; Version 3.0, Bestätigungs-ID: TUVIT TE , welcher die CT-API- Schnittstelle unterstützt --/ persönliche Übergabe. Tabelle 4: Lieferumfang für Variante 2 (Signaturbox) Hardware-Komponenten Bezeichnung Beschreibung Version / Datum Übergabeform signaturserver Ausführbares Programm des Signaturservers unter Linux 32 bit / / in Signaturbox vorinstalliert; zum Update via FTP als Bestandteil des signierten ISO- Image gemäß Kapitel 5.3. CertificateDatabase.dat configmodule.ini Zertifikatsdatenbank des Signaturservers Konfigurationsdatei für die vom Signaturserver genutzte Funktionsbibliothek LibSigG Ohne Version / / in Signaturbox vorinstalliert; zum Update via FTP als Bestandteil des signierten ISO- Image gemäß Kapitel 5.3. Ohne Version / / in Signaturbox vorinstalliert signaturserver.conf Konfigurationsdatei des Ohne Version / / HE_multisign_Enterprise_4.1.1 Seite 6 von 33

7 Runlevelscript: /etc/init.d./signaturserver Runlevelscript: /etc/init.d/boxconfigurator Runlevelscript: /etc/init.d/boxupdater Runlevelscript: /etc/init.d/certdbupdater signaturecheck Signaturservers Skript, das zum Starten des Signaturservers im Rahmen von Variante 2 benötigt wird. Skript, das zum Aufspielen neuer Konfigurationsdateien im Rahmen von Variante 2 benötigt wird. Skript, das zum Aufspielen der signierten Software (ISO- Image) im Rahmen von Variante 2 benötigt wird. Skript, das zum Aufspielen der signierten Zertifikatsdatenbank im Rahmen von Variante 2 benötigt wird. Ausführbares Programm, mit welchem die Signaturprüfung der Softwarekomponenten durchgeführt wird, welche auf das System via USB-Stick aufgebracht werden sollen. in Signaturbox vorinstalliert Script ohne Versionsangabe / / in Signaturbox vorinstalliert; zum Update via FTP als Bestandteil des signierten ISO- Image gemäß Kapitel 5.3 Script ohne Versionsangabe / / in Signaturbox vorinstalliert; zum Update via FTP als Bestandteil des signierten ISO- Image gemäß Kapitel 5.3 Script ohne Versionsangabe / / in Signaturbox vorinstalliert; zum Update via FTP als Bestandteil des signierten ISO- Image gemäß Kapitel 5.3 Script ohne Versionsangabe / / in Signaturbox vorinstalliert; zum Update via FTP als Bestandteil des signierten ISO- Image gemäß Kapitel / / in Signaturbox vorinstalliert; zum Update via FTP als Bestandteil des signierten ISO- Image gemäß Kapitel 5.3 Tabelle 5: Lieferumfang und Versionsinformationen für Variante 2 (Signaturbox) serverseitige Software-Komponenten Die serverseitigen Bestandteile des Produktes sind bereits durch den Hersteller vorinstalliert. Bei den clientseitigen Bestandteilen (Client-API Bibliothek) handelt es sich um eine Funktionsbibliothek, die alleine nicht lauffähig ist und von einem Anwendungsentwickler verwendet werden kann, um die Funktionalität von multisign Enterprise über das Network-Interface zu nutzen. Bezeichnung Beschreibung Version / Übergabeform libsignserverclientapi.a/.so Statische/Dynamische Client-API-Bibliothek für Linux, 32-Bit-Variante / / HE_multisign_Enterprise_4.1.1 Seite 7 von 33

8 libsignserverclientapi.a/.so libsignserverclientapi.a/.so ClientApi.dll ClientApi.lib ClientCAPI.h ClientAPITypes.h SharedClientApiTypes.h Statische/Dynamische Client-API-Bibliothek für Solaris, 32-Bit-Variante Statische/Dynamische Client-API-Bibliothek für Linux, 64-Bit-Variante Dynamische Client-API- Bibliothek für Windows 32 Bit Stublib zum Einbinden der dyn. Client-API-Bibliothek für Windows 32 Bit Headerdatei zu den Client- API-Funktionsbibliotheken Headerdatei zu den Client- API-Funktionsbibliotheken Headerdatei zu den Client- API-Funktionsbibliotheken / / / / / / / / Revision 16 / / Revision 18 / / Revision 10 / / Tabelle 6: Lieferumfang und Versionsinformationen für Variante 2 (Signaturbox) clientseitige Software-Komponenten Des Weiteren werden noch Dokumentationen ausgeliefert, die unabhängig von client- oder serverseitiger Verwendung sind: Produktbestandteile Bezeichnung Version / Datum Übergabeform HE_multisign_Enterprise_B D_4.1.1.pdf Benutzerdokumentation Version 1. / Stand / Digitale Form Tabelle 7: Lieferumfang und Versionsinformationen für Variante 2 (Signaturbox) Nicht zum Lieferumfang gehörende Komponenten (SigG bestätigt) Die Verwendung sicherer Signaturerstellungseinheiten nach 17 Abs. 1 Signaturgesetz, bzw. 15 Abs. 1 Signaturverordnung, wird vorausgesetzt. Diese gehören nicht zum Lieferumfang und sind nicht Gegenstand dieser Erklärung. Die Auflagen aus den Bestätigungen zu den Produkten sind zwingend einzuhalten. Erst dann ist die Sicherheit der jeweiligen Komponente gewährleistet, wie sie in der zugehörigen Bestätigung angegeben wird. Insbesondere handelt es sich hierbei um folgende Komponenten: HE_multisign_Enterprise_4.1.1 Seite 8 von 33

9 Produktklasse Bezeichnung Bestätigung SSEE G&D Starcos 3.2 QES Version 2.0 BSI TE Nachtrag zur Bestätigung vom : T- Systems TU Tabelle 8: Zusätzliche SigG bestätigte Produkte für Variante 2 (Signaturbox) Sonstige, nicht zum Lieferumfang gehörende Komponenten Produktklasse Beschreibung Hardware Im Rahmen der Nutzung des File-Interface kommt zusätzlich ein dedizierter Rechner mit Festplatte und installiertem SMB-Dienst zum Einsatz, auf dem das Eingangs- und Ausgangsverzeichnis für das File-Interface angelegt ist. Weitere Details sind Kap zu entnehmen Compiler Die Einbindung der Client-API Bibliothek in eine Applikation zur Nutzung des Network-Interface muss mit einem C-Compiler realisiert werden, dessen Befehlssatz der ANSI/ISO C Norm entspricht. Unter Windows kann dies beispielsweise mit Microsoft Visual C++ 9.0, unter Unix mit dem Compiler gcc 3.4 erfolgen. Tabelle 9: Zusätzliche nicht SigG bestätigte Produkte für Variante 2 (Signaturbox) Um den Inhalt der zu signierenden oder signierten Daten bei Bedarf einsehen zu können, wird ein externer secure viewer benötigt, beispielsweise für das Dokumentenformat PDF der Adobe Reader. 3. Funktionsbeschreibung Das Produkt multisign Enterprise stellt eine Lösung im Bereich der qualifizierten elektronischen Signatur (insbesondere im Szenario Batchsignaturen) zur Verfügung. Das Produkt bindet die herstellererklärte multisign Funktionsbibliothek LibSigG Version statisch ein. Diese repräsentiert die konkrete Anbindung des Systems an eine sichere Signaturerstellungseinheit (SSEE). Die SSEE ist nicht Bestandteil des Signaturservers. Das Produkt liegt in zwei möglichen Varianten vor, die sich in der Einsatzumgebung unterscheiden (unterschiedliche Hardwareplattformen, siehe auch Abschnitt 5.1): Variante1: Server-Plattform Hierbei wird multisign Enterprise auf einem Standard-Rechner mit x86 kompatiblem Prozessor betrieben (Betriebssysteme Linux 32 Bit und Linux 64 Bit beides Kernel 2.6). Variante2: Signaturbox Hierbei wird multisign Enterprise auf einer speziellen Hardware-Plattform mit folgenden Eigenschaften betrieben: HE_multisign_Enterprise_4.1.1 Seite 9 von 33

10 o Betriebssystem Linux 32 Bit (Kernel 2.6) o x86 kompatibler Prozessor o mindestens 256 MB-RAM o keine Festplatte und kein CD-ROM-Laufwerk o mindestens 4 GB Compact-Flash Card o eine USB-Schnittstelle (intern) o eine USB-Schnittstelle (extern) o ein eingebauter USB-Chipkartenleser Reiner cyberjack e-com; Version 3.0, Bestätigungs-ID: TUVIT TE , welcher die CT-API- Schnittstelle unterstützt Die folgenden Funktionen werden durch das Produkt grundsätzlich bereitgestellt Signaturerstellung Signaturprüfung Zertifikatsprüfung Mandantenfähigkeit Das Produkt erfüllt folgende gesetzliche Kriterien, die in Kapitel 4 ausführlich erläutert werden: SigG, 17 Absatz 2 SigV, 15 Absatz 2 SigV, 15 Absatz 4 wird durch organisatorische und technische Maßnahmen umgesetzt, die ebenfalls in Kapitel 4 erläutert sind. 3.1 Schnittstellen Das Produkt kann über unterschiedliche Schnittstellen angesprochen werden; jede Schnittstelle bietet spezifische Möglichkeiten zur Integration des Systems in bestehende Umgebungen. Folgende Schnittstellen stehen grundsätzlich zur Verfügung: File-Interface Network-Interface Des Weiteren existiert eine Schnittstelle zur Kommandozeile, welche über die Einsatzumgebung abgesichert ist (Betrieb in einem verriegelten Elektroschrank). Außerdem gibt es eine Schnittstelle in Form einer Online-Verbindung für OCSP-Anfragen zum ZDA File-Interface Die Trennung der Mandanten erfolgt beim File-Interface über unterschiedliche Eingangsund Ausgangsverzeichnisse, beim Network-Interface über Benutzername/Passwort. Die Zuführung der zu signierenden Dokumente zum File-Interface des Produkts muss integritätsgesichert und authentisch erfolgen. Diese Anforderung muss durch die Einsatzumgebung realisiert werden. Sie muss die Anforderungen an einen geschützten Einsatzbereich gemäß Bundesnetzagentur Einheitliche Spezifizierung der Einsatzbedingungen für Signaturanwendungskomponenten, Version 1.4, erfüllen. Die Integrität und Authentizität der über das File-Interface zugeführten Dokumente können durch ein gesichertes LAN oder durch physikalisch geschützte Netzleitungen oder den Betrieb von Signaturbox und dedizierter Rechner in einem gemeinsamen Elektroschrank gewährleistet werden. HE_multisign_Enterprise_4.1.1 Seite 10 von 33

11 3.1.2 Network-Interface Das Produkt besteht aus einer serverseitigen und einer clientseitigen Komponente. Die clientseitige Komponente ist als Funktionsbibliothek realisiert und repräsentiert das clientseitige Network-Interface zur Nutzung der vom Server bereitgestellten Sicherheitsfunktionalität. Des Weiteren wird von der clientseitigen Komponente die Initialisierung eines sicheren Kanals zur serverseitigen Komponente zur Verfügung gestellt. Die Integrität und Authentizität der über das Network-Interface zugeführten Dokumente wird über die SSL-Verbindung des Produktes gewährleistet Online-Verbindung für OCSP-Anfragen zum ZDA Signaturanwendungskomponenten nach 17 Abs. 2 des Signaturgesetzes müssen gemäß 15 Abs. 2 SigV gewährleisten, dass bei der Prüfung einer qualifizierten elektronischen Signatur eindeutig erkennbar wird, ob die nachgeprüften qualifizierten Zertifikate im jeweiligen Zertifikat-Verzeichnis zum angegebenen Zeitpunkt vorhanden und nicht gesperrt war. Dies wird durch Einsatz des Online Certificate Status Protocols (OCSP) realisiert. Über eine Online-Verbindung zu einem SigG-konformen Trustcenter-Verzeichnisdienst (OCSP-Responder) wird der aktuelle Status des Benutzertifikats (bzgl. Vorhandensein und Sperrstatus) abgefragt. Zu diesem Zweck wird via OCSP-Protokoll das zu prüfende Benutzer-Zertifikat in einer Anfrage (Request) an den Verzeichnisdienst des ausstellenden Zertifizierungsdiensteanbieters (ZDA) gesendet. Das Ergebnis der Prüfung wird multisign Enterprise seitens des Zertifizierungsdiensteanbieters in einer signierten Nachricht übermittelt, welche mit dem der Nachricht beigefügten Verzeichnisdienst-Zertifikat des ZDA verifiziert werden kann. Das Verzeichnisdienstzertifikat wiederum kann mit Hilfe des öffentlichen Schlüssels der nationalen Behörde (BNetzA) verifiziert werden. Eine zusätzliche Online- Prüfung des Verzeichnisdienstzertifikats findet nicht statt. Das Ergebnis der Gültigkeits-/Statusprüfung eines Zertifikats wird innerhalb eines XML- Prüfberichts oder PDF-Prüfberichts an die Applikation übergeben. Details zu den Prüfberichten und den möglichen Antworten des Verzeichnisdienstes sind der Betriebsdokumentation zur LibSigG zu entnehmen. Die Online-Überprüfung mittels OCSP ist bei der Verifikation qualifizierter elektronischer Signaturen zwingend erforderlich 3.2 Anstoßen einer qualifizierten elektronischen Signaturerzeugung Im Rahmen des Anstoßens einer qualifizierten Signaturerzeugung erfolgt zunächst die Inbetriebnahme und Initialisierung der SSEE durch Übergabe einer PIN via Pinpad-Leser an die SSEE. Die PIN darf ausschließlich über das Pinpad des Kartenlesers eingegeben werden (siehe dazu auch Kapitel 5.4). Vor dem Anstoßen einer qualifizierten Signaturerzeugung (d.h. vor PIN-Eingabe) wird vom Produkt ein geeigneter Warnhinweis angezeigt (gemäß 15(2) Nr.1c SigV). Dies erfolgt durch Anzeige des Textes Signatur-PIN? auf dem Display des Kartenlesers. Im Rahmen von Variante 1 (Server-Plattform) wird zusätzlich folgender Hinweis auf der Kommandozeile angezeigt: Bitte geben Sie die PIN zur Erzeugung qualifizierter Signaturen für die Chipkarten von ChipcardPool <poolname> an den entsprechenden Kartenlesern über das PinPad ein. Der Signaturschlüsselinhaber muss hinsichtlich des Warnhinweises entsprechend geschult werden. Ihm muss bewusst sein, dass mit Eingabe seiner Signatur-Pin am Kartenleser der Prozess der Massensignatur für das vordefinierte Zeitfenster freigeschaltet wird und nach- HE_multisign_Enterprise_4.1.1 Seite 11 von 33

12 folgend in dem Zeitfenster zu signierende Dokumente, die über das Network-Interface oder das File-Interface der Server-Komponente des Produktes zugeführt werden, rechtsverbindlich mit seinem Signaturschlüssel signiert werden. Die Anzeige auf dem Display Signatur- PIN? hat er dann als Warnhinweis zu interpretieren. Der Signaturschlüsselinhaber muss sich durch diesen Warnhinweis bewusst sein, dass er im nächsten Schritt mit der Pin- Eingabe den kontrollierten Massensignaturprozess auslöst. Es können ausschließlich qualifizierte elektronische Signaturen nach Eingabe der Signatur- PIN erzeugt werden. Voraussetzung für die Erzeugung qualifizierter elektronischer Signaturen ist die Verwendung bestätigter Produkte (SSEE und Kartenleser) bzw. der Signaturbox inklusive bestätigtem Kartenleser gemäß Kapitel 2. Die PIN-Eingabe erfolgt durch den Systemverwalter. Dieser ist der Signaturschlüsselinhaber und wird durch einen Mandanten zur Signaturerzeugung beauftragt. Die verwendete SSEE muss hierbei den Batchbetrieb unterstützen, d.h. es ist möglich, nach einmaliger Eingabe der PIN mehrere qualifizierte Signaturerzeugungen nacheinander anzustoßen. Zur Beschränkung der Signaturanzahl ist ein Zeitfenster implementiert. Nach der PIN-Eingabe wird die SSEE für ein Zeitfenster definierbarer Länge freigeschaltet. Um den kontinuierlichen Betrieb fortzuführen, ist die PIN vor Ablauf des Zeitfensters erneut einzugeben. Dadurch wird die SSEE für ein weiteres Zeitfenster freigeschaltet. Läuft das Zeitfenster aus, ohne dass die PIN erneut eingegeben wurde, wird die LibSigG-Instanz deaktiviert und die SSEE steht für weitere Operationen nicht mehr zur Verfügung. Die Konfiguration des Zeitfensters erfolgt über die Konfigurationsdatei des Signaturservers. Bei der Aktivierung des Zeitfensters wird geprüft, ob das qualifizierte Zertifikat für die gesamte, konfigurierte Aktivierungsdauer gültig ist. Läuft das Zertifikat während des Zeitfensters ab, so wird die SSEE nicht aktiviert und eine entsprechende Fehlermeldung generiert. Es muss verhindert werden, dass Unberechtigte in den Massensignaturprozess eingreifen können. Dies wird unter anderem durch einen geschützten Einsatzbereich gemäß Bundesnetzagentur Einheitliche Spezifizierung der Einsatzbedingungen für Signaturanwendungskomponenten, Version 1.4, mittels Betrieb in verriegeltem Elektroschrank und abgesicherte Netzwerkkommunikation realisiert. In Kapitel 5 sind dazu geeignete Maßnahmen in der Einsatzumgebung aufgezeigt. Insbesondere die technischen und organisatorischen Maßnahmen aus Kapitel 5.2 (Anbindung an ein Netzwerk) und Kapitel 5.4 (Auflagen für den Betrieb des Produkts) sind dahingehend zu beachten. Ein Batch-Betrieb darf ausschließlich für gleichwertige Dokumente erfolgen (z.b. Signaturen zu Zahlungsanweisungen bei Großanwendern). Zu diesem Zweck muss im Hauptzertifikat der SSEE zusätzlich eine entsprechende Beschränkung (z.b. Nur für Rechnungssignatur ) vorhanden sein, um die qualifizierte Signaturerzeugung auf einen bestimmten Zweck zu beschränken. Das Produkt selbst führt technisch keine Prüfung auf Gleichwertigkeit der zu signierenden Dokumente durch. Eine Darstellung des Inhalts der zu signierenden Daten erfolgt nicht von multisign Enterprise. Eine qualifizierte Signaturerzeugung kann von einem Mandanten entweder über das File- Interface oder das Network-Interface des Produktes angestoßen werden. In Abhängigkeit der verwendeten Schnittstelle sind folgende Signaturformate möglich: Signaturformate File-Interface PKCS#7 (detached und embedded) XML - DSig PDF Network-Interface PKCS#1 PKCS#7 (detached und embedded) XML - DSig PDF Tabelle 10: Signaturformate beim Anstoßen einer qualifizierten Signaturerzeugung HE_multisign_Enterprise_4.1.1 Seite 12 von 33

13 Nach korrekter Initialisierung der SSEE erzeugt das Produkt dann über die zu signierenden Daten einen Hashwert, der anschließend unter Zuhilfenahme eines privaten Signaturschlüssels innerhalb der SSEE verschlüsselt wird. Der verschlüsselte Hashwert stellt die qualifizierte elektronische Signatur der Daten dar. Als Hashalgorithmus zur Signaturerzeugung wird sha2-224, sha2-256, sha2-384 und sha2-512 unterstützt. Diese Unterstützung ist davon abhängig, ob die jeweiligen Algorithmen in der Konfiguration von multisign Enterprise als geeignet konfiguriert sind. Der Systemverwalter hat dafür Sorge zu tragen, dass in der Konfiguration die korrekten Werte für die Gültigkeit der Algorithmen gemäß Bundesnetzagentur (siehe Kapitel 6) hinterlegt sind. Ist einer der oben aufgeführten, technisch unterstützten Algorithmen zum Zeitpunkt der Signaturerstellung abgelaufen und damit als nicht geeignet markiert, so wird die Signaturerstellung nicht zugelassen und eine Fehlermeldung zurückgeliefert. Im Rahmen des Anstoßens einer qualifizierten Signaturerzeugung wird nicht geprüft, ob die Signatur auch tatsächlich korrekt erstellt wurde. Die Korrektheit der erstellten Signatur kann vom Anwender jedoch im Rahmen der Verifikation einer qualifizierten elektronischen Signatur überprüft werden (siehe Kapitel 3.3). Zur Verhinderung von Datenmanipulationen auf dem Übertragungsweg zwischen dem Produkt und dem eingesetzten Chipkartenleser müssen die Server-Plattform bzw. die Signaturbox sowie die eingesetzten Chipkarten und Chipkartenleser in einem verriegelten Elektroschrank betrieben werden ( Geschützter Einsatzbereich gemäß Bundesnetzagentur Einheitliche Spezifizierung der Einsatzbedingungen für Signaturanwendungskomponenten, Version 1.4, siehe auch Kapitel 5.1). Sowohl die SSEE als auch die in Frage kommenden Kartenleser müssen bestätigt sein. Bei der Erzeugung einer qualifizierten elektronischen Signatur muss sich vorher eindeutig feststellen lassen, auf welche Daten sich die Signatur bezieht. Dies geschieht über den Dateinamen. Im Falle des File-Interface geschieht die Anzeige des Dateinamens mittels des Betriebssystems, welches geeignete Werkzeuge bereitstellt, um die Dateinamen der zu signierenden Dateien anzuzeigen (graphische Systemprogramme zur Anzeige des Dateibaums, Kommandozeilensystemprogramme wie das ls-kommando, usw.). Die zu signierenden Dateien müssen vor Signaturerstellung aktiv in das Eingangsverzeichnis des File- Interface kopiert werden. Bei dieser Operation sind dem Kopierenden die Dateinamen bekannt. Im Falle der Netzwerkschnittstelle muss die aufrufende Applikation dafür Sorge tragen, dass dem Erzeuger kenntlich gemacht wird, auf welche Daten sich die Signatur bezieht. Dies muss die einbindende Applikation leisten und kann z.b. ebenso durch Anzeige des Dateinamens erfolgen. Eine Darstellung des Inhalts der zu signierenden Daten erfolgt nicht von multisign Enterprise. Das Produkt bindet die herstellererklärte multisign Funktionsbibliothek LibSigG Version statisch ein und nutzt dessen Signierfunktionalität. Weitere Details wie LibSigG die Signaturerstellung vornimmt, sind der Herstellererklärung zu LibSigG Kapitel 3 zu entnehmen (HE_LIBSIGG_5.1.1). 3.3 Verifikation einer qualifizierten elektronischen Signatur Neben der Möglichkeit zur Erzeugung einer qualifizierten elektronischen Signatur können solche Signaturen auch verifiziert werden. Folgende Signaturformate werden in Abhängigkeit der verwendeten Schnittstelle für die Prüfung einer Signatur unterstützt: HE_multisign_Enterprise_4.1.1 Seite 13 von 33

14 File-Interface Network-Interface Signaturformate PKCS#7 XML Dsig PDF PKCS#1 PKCS#7 XML-DSig PDF Tabelle 11: Signaturformate bei der Verifikation einer qualifizierten elektronischen Signatur Die qualifizierte elektronische Signatur wird anhand des öffentlichen Signaturprüfschlüssels des Unterzeichners geprüft. Zu diesem Zweck müssen folgende Daten übergeben werden: Signaturumfang Qualifizierte elektronische Signatur über den Signaturumfang Zugehöriges qualifiziertes Zertifikat Der Vertrauensanker (Root-Zertifikat) wird von der SSEE bzw. aus der Zertifikatsdatenbank der gelesen. Zusätzlich benötigte Zertifikate (z.b. CA-Zertifikate) werden aus der Zertifikatsdatenbank (realisiert als Datei) gelesen. Über die signierten Daten wird ein Hashwert gebildet und anschließend mit dem Wert verglichen, der sich aus der kryptographischen Entschlüsselung der angehängten qualifizierten elektronischen Signatur mit dem öffentlichen Schlüssel des Unterzeichners ergibt. Der Vergleich der beiden Werte gibt Aufschluss über die mathematische Korrektheit der Signatur. Im Rahmen der Verifikation von qualifizierten elektronischen Signaturen führt das Produkt eine Zertifikatsprüfung durch. Hierbei wird zunächst eine Prüfung bezüglich der mathematischen Korrektheit des Benutzerzertifikats sowie des CA-Zertifikats innerhalb der Zertifikatskette durchgeführt (als lokale Offline-Prüfung), wobei zusätzlich die zeitliche Gültigkeit der Zertifikate gemäß dem so genannten Kettenmodell überprüft wird. Darüber werden im Rahmen einer Online-Prüfung Zertifikatsstatusinformationen zu einem Benutzerzertifikat (bzgl. Vorhandensein und Sperrstatus) bei einem externen Verzeichnisdienst via OCSP- Protokoll eingeholt. Die Online-Überprüfung mittels OCSP ist bei der Verifikation qualifizierter elektronischer Signaturen zwingend erforderlich. Im Rahmen der Verifikation wird außerdem geprüft, ob es sich beim verwendeten Hashalgorithmus und Signieralgorithmus um einen zum Prüfzeitpunkt (dies kann entweder der aktuelle Verifikationszeitpunkt oder der Signaturerstellungszeitpunkt sein) gemäß Bundesnetzagentur (siehe Kapitel 6) zugelassenen Algorithmus handelt. Die Prüfungen hinsichtlich der Gültigkeit der verwendeten Algorithmen werden ebenfalls auf die Zertifikatssignaturen in der Zertifikatskette angewandt. Der Systemverwalter hat dafür Sorge zu tragen, dass in der Konfiguration die korrekten Werte für die Gültigkeit der Algorithmen gemäß Bundesnetzagentur (siehe Kapitel 6) hinterlegt sind. Das Ergebnis der Signaturprüfung, die Hinweise hinsichtlich der verwendeten Algorithmen und der verwendete Prüfzeitpunkt werden innerhalb eines XML-Prüfprotokolls oder PDF- Prüfprotokolls zurückgeliefert. Das Prüfprotokoll wird durch die Komponente multisign Lib- SigG erzeugt und kann mit einem handelsüblichen XML- bzw. PDF-Viewer angezeigt werden. In den Prüfberichten ist unter anderem festgehalten, welcher Prüfzeitpunkt verwendet wurde. Er ist dort nicht nur als Datumsangabe hinterlegt, sondern zusätzlich wird in den Prüfberichten angegeben, ob der Prüfzeitpunkt oder der Signaturerstellungszeitpunkt zur Prüfung herangezogen wurde: HE_multisign_Enterprise_4.1.1 Seite 14 von 33

15 PDF-Prüfbericht: "Die Gültigkeitsprüfungen wurden für den Prüfzeitpunkt durchgeführt" - bzw. "Die Gültigkeitsprüfungen wurden für den Signaturzeitpunkt durchgeführt" XML-Prüfbericht: <VerificationTimeUsedForValidation/> bzw. <SigningTimeUsedForValidation/> Weitere Angaben zu den Prüfberichten sind der Betriebsdokumentation zur Herstellererklärung der verwendeten Bibliothek LibSigG (HE_LIBSIGG_BD_5.1.1) Kapitel 8.1 zu entnehmen. Hier sind ebenfalls weitere Erläuterungen zur Zertifikatsprüfung von LibSigG gemäß Kettenmodell zu finden, die im Rahmen der Signaturprüfung für das Benutzerzertifikat durchgeführt wird. Bei der Prüfung von qualifizierten elektronischen Signaturen wird auch dann eine zuverlässige Prüfung und zutreffende Anzeige des Ergebnisses gemäß 15 Abs. 2 Nr. 2a SigV erfolgen, wenn die geprüfte Signatur auf einem Algorithmus beruht, der als nicht mehr geeignet und damit als nicht mehr hinreichend sicher eingestuft ist. Die Prüfung zeigt bei abgelaufenen Algorithmen dem Nutzer deutlich an, dass die geprüfte Signatur mit einem Algorithmus erzeugt wurde, der nicht mehr dem Stand der Wissenschaft und Technik entspricht. Ferner wird der Zeitpunkt, zu dem der Algorithmus seine Eignung verloren hat, zutreffend angezeigt. Ist bei der Prüfung einer Signatur ein Algorithmus zu verwenden, der nicht implementiert ist, so wird dies dem Nutzer ebenfalls zutreffend angezeigt. Es ist hinsichtlich abgelaufener Algorithmen zu unterscheiden, ob der betroffene Algorithmus bereits vor der Signaturerstellung als ungeeignet eingestuft war oder ob er nach der Signaturerstellung seine Gültigkeit verloren hat. 1. War der Algorithmus bereits zum Zeitpunkt der Signaturerstellung ungültig, so wird bei der Verifikation ein negatives Gesamtergebnis zurückgeliefert (Prüfung nicht bestanden). Zusätzlich wird folgender Hinweistext ausgegeben: Die geprüfte Signatur wurde mit einem Algorithmus erzeugt (Angabe des Algorithmus), der nicht mehr dem Stand der Wissenschaft und Technik entspricht. Der Algorithmus hat am (Datum) seine Eignung verloren. 2. Ist der Algorithmus nach dem Signaturerstellungszeitpunkt abgelaufen, so gibt es zwei mögliche Varianten: a.) Ist als Prüfzeitpunkt der Signaturerstellungszeitpunkt konfiguriert und ist der Signaturerstellungszeitpunkt im vorliegenden Signaturformat enthalten, liefert die Prüfung hinsichtlich der Gültigkeit der Algorithmen ein positives Ergebnis. Zusätzlich wird der unter 1. aufgeführte Hinweistext ausgegeben. b.) Ist als Prüfzeitpunkt der aktuelle Verifikationszeitpunkt (Systemzeit) konfiguriert, kann das Produkt keine Aussage darüber treffen, ob der verwendete Algorithmus vor oder nach dem Signaturerstellungszeitpunkt abgelaufen ist. Somit wird bei der Verifikation ein negatives Gesamtergebnis zurückgeliefert (Prüfung nicht bestanden). Zusätzlich wird der unter 1. aufgeführte Hinweistext ausgegeben. Der verwendete Prüfzeitpunkt (Signaturerstellungszeitpunkt oder Verifikationszeitpunkt) wird im Prüfprotokoll angegeben. Die Eignung der qualifizierten elektronischen Signatur definiert sich über die Eignung der Algorithmen und die Prüfung der Zertifikatskette. Das Produkt bindet die herstellererklärte multisign Funktionsbibliothek LibSigG Version statisch ein und nutzt dessen Verifikationsfunktionalität. Weitere Details wie LibSigG die Verifikation vornimmt, sind der Herstellererklärung zu LibSigG Kapitel 3 zu entnehmen (HE_LIBSIGG_5.1.1). HE_multisign_Enterprise_4.1.1 Seite 15 von 33

16 3.4 Sicherheitstechnische Veränderungen Sicherheitstechnische Veränderungen an multisign Enterprise müssen erkennbar sein. Eine Beschreibung der Vorgehensweise zur Erkennung von Veränderungen ist Bestandteil von Kapitel 5.4. HE_multisign_Enterprise_4.1.1 Seite 16 von 33

17 4. Erfüllung der Anforderungen des Signaturgesetzes und der Signaturverordnung 4.1 Erfüllte Anforderungen 17 Abs. 2 SigG 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. Das Produkt zeigt vor dem Anstoßen einer qualifizierten Signaturerzeugung (d.h. vor der Aktivierung des Zeitfensters) einen Hinweis auf dem Display des Kartenlesers an, dass die Identifikationsdaten (Anzeige: Signatur-PIN? ) übergegeben werden müssen. Es können ausschließlich qualifizierte elektronische Signaturen nach Eingabe der Signatur-PIN erzeugt werden. Des Weiteren wird im Rahmen von Variante 1 (Server-Plattform) zusätzlich folgender Hinweis auf der Kommandozeile angezeigt: Bitte geben Sie die PIN zur Erzeugung qualifizierter Signaturen für die Chipkarten von ChipcardPool <poolname> an den entsprechenden Kartenlesern über das PinPad ein. Der Signaturschlüsselinhaber muss hinsichtlich des Warnhinweises entsprechend geschult werden (siehe auch Kapitel 3.2). Das Produkt darf nur von fachlich versiertem, geschultem und vertrauenswürdigem Personal bedient werden, um Fehlbedienungen zu verhindern, die zu ungewollten Signaturen bei Massensignaturen führen. Da es sich hier um ein Batchsignaturszenario handelt, muss gewährleistet sein, dass der Verwendungszweck der Signaturerzeugung beschränkt wird. (siehe auch Begründung zur SigV: Insbesondere bei der automatischen Erzeugung von Signaturen ("Massensignaturen") muss sichergestellt sein, dass Signaturen nur zu dem voreingestellten Zweck (z. B. Signaturen zu Zahlungsanweisungen bei Großanwendern) vorgenommen werden können. ) Gem. den Anforderungen an die administrative Einsatzumgebung wird eine Beschränkung über ein Attribut im Hauptzertifikat adressiert. Über den Dateinamen lässt sich feststellen, auf welche Daten sich die Signatur bezieht. Im Falle des File- Interface geschieht die Anzeige des Dateinamens mittels des Betriebssystems, welches geeignete Werkzeuge bereitstellt. Im Falle des Network-Interface muss die aufrufende Applikation dafür Sorge trage (siehe dazu auch Kapitel 3.2). HE_multisign_Enterprise_4.1.1 Seite 17 von 33

18 Für die Überprüfung signierter Daten sind Signaturanwendungskomponenten erforderlich, die feststellen lassen, 1) auf welche Daten sich die Signatur bezieht, 2) ob die signierten Daten unverändert sind, 3) welchem Signaturschlüssel-Inhaber die Signatur zuzuordnen ist, 4) welche Inhalte das qualifizierte Zertifikat, auf dem die Signatur beruht, und zugehörige qualifizierte Attribut-Zertifikate aufweisen und 5) zu welchem Ergebnis die Nachprüfung von Zertifikaten nach 5 Abs. 1 Satz 2 geführt hat. Signaturanwendungskomponenten müssen nach Bedarf auch den Inhalt der zu signierenden oder signierten Daten hinreichend erkennen lassen. Das Produkt nutzt zur Überprüfung signierter Daten die entsprechende Funktionalität der eingebundenen multisign Funktionsbibliothek LibSigG Version Es wird von LibSigG ein detailliertes Prüfprotokoll im XML- oder PDF-Format erzeugt, welches dann über das Network-Interface an den Client weiter gegeben bzw. beim File-Interface in einem entsprechenden Ausgabeverzeichnis zur Verfügung gestellt wird. Anhand des Prüfprotokolls lassen sich die geforderten Inhalte feststellen: PDF: 1. Dateiname 2. Mathematische Prüfung bestanden/ nicht bestanden 3. Signiert von (aus Zertifikat ausgelesen) 4. Zertifikat (qualifiziertes Zertifikat, qualifiziertes Attribut-Zertifikat) 5. Zertifikatsprüfung bestanden/ nicht bestanden (Zertifikatskette), Sperrstatusprüfung bestanden/ nicht bestanden XML: 1. XML-Tag: File (Dateiname) 2. XML-Tag: Math Checks (ok/error) 3. XML-Tag: Certificate Subject (aus Zertifikat ausgelesen) 4. XML-Tag: User Certificate (qualifiziertes Zertifikat, qualifiziertes Attribut-Zertifikat) 5. XML-Tag: Certificate Chain (ok/ error), Revocation (not checked/ not revoked/ revoked/ not present/ unknown/ error) Im Falle des Network-Interface ist hinsichtlich des Dateinamens zu beachten, dass dieser von der Clientapplikation korrekt an die ClientAPI übergeben wird. Der Dateiname wird dann mitsamt der Verifikationsanfrage zur Serverkomponente transferiert und dort in das Prüfprotokoll eingetragen. Das Produkt verfügt über keinen secure viewer. Um den Inhalt der zu signierenden oder signierten Daten bei Bedarf einsehen zu können, wird ein externer secure viewer benötigt, beispielsweise für das Dokumentenformat PDF der Adobe Reader. HE_multisign_Enterprise_4.1.1 Seite 18 von 33

19 Anforderung 15 Abs. 2 SigV: 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, Erfüllung Diese Anforderung wird nicht durch multisign Enterprise, sondern durch die eingesetzten Chipkartenleser und die eingesetzte SSEE realisiert. Voraussetzung hierfür ist, dass multisign Enterprise derart konfiguriert ist (Konfigurationsdatei des Signaturservers signaturserver.conf ; siehe Kapitel 5.4), dass eine PIN-Eingabe ausschließlich unter Verwendung des PINPads möglich ist. Darüber hinaus tragen weitere physikalische Maßnahmen (vgl. Kapitel 5) bzgl. Der Einsatzumgebung zur Erfüllung der Anforderung bei. Eine qualifizierte Signaturerzeugung ist nur nach Eingabe der Identifikationsdaten (PIN) der SSEE durch den Signaturschlüsselinhaber möglich. (wird durch die eingesetzten Chipkartenleser und die eingesetzte SSEE realisiert). Im Rahmen des Batchbetriebes wird jeder Chipcard-Pool (SSEE) nach Eingabe der PIN nur für ein konfigurierbares Zeitfenster aktiviert. Erfolgt keine erneute Freischaltung für die SSEE dieses Pools innerhalb der angegebenen Zeitspanne, wird er automatisch deaktiviert und eine qualifizierte Signaturerzeugung ist somit nicht mehr möglich. Es muss verhindert werden, dass Unberechtigte in den Massensignaturprozess eingreifen können. Dies wird unter anderem durch einen geschützten Einsatzbereich gemäß Bundesnetzagentur Einheitliche Spezifizierung der Einsatzbedingungen für Signaturanwendungskomponenten, Version 1.4, mittels Betrieb in verriegeltem Elektroschrank und abgesicherte Netzwerkkommunikation realisiert. In Kapitel 5 sind dazu geeignete Maßnahmen in der Einsatzumgebung aufgezeigt. Insbesondere die technischen und organisatorischen Maßnahmen aus Kapitel 5.2 (Anbindung an ein Netzwerk) und Kapitel 5.4 (Auflagen für den Betrieb des Produkts) sind dahingehend zu beachten. HE_multisign_Enterprise_4.1.1 Seite 19 von 33

20 Anforderung c) die Erzeugung einer Signatur vorher eindeutig angezeigt wird Erfüllung Das Produkt zeigt vor dem Anstoßen einer qualifizierten Signaturerzeugung (d.h. vor der Aktivierung des Zeitfensters) einen Hinweis auf dem Display des Kartenlesers an, dass die Identifikationsdaten (Anzeige: Signatur-PIN? ) übergegeben werden müssen. Es können ausschließlich qualifizierte elektronische Signaturen nach Eingabe der Signatur-PIN erzeugt werden. Des Weiteren wird im Rahmen von Variante 1 (Server- Plattform) zusätzlich folgender Hinweis auf der Kommandozeile angezeigt: Bitte geben Sie die PIN zur Erzeugung qualifizierter Signaturen für die Chipkarten von Chipcard- Pool <poolname> an den entsprechenden Kartenlesern über das PinPad ein. Der Signaturschlüsselinhaber muss hinsichtlich des Warnhinweises entsprechend geschult werden. Ihm muss bewusst sein, dass mit Eingabe seiner Signatur-Pin am Kartenleser der Prozess der Massensignatur für das vordefinierte Zeitfenster freigeschaltet wird und nachfolgend in dem Zeitfenster zu signierende Dokumente, die über das Network-Interface oder das File-Interface der Server- Komponente des Produktes zugeführt werden, rechtsverbindlich mit seinem Signaturschlüssel signiert werden. Die Anzeige auf dem Display Signatur-PIN? hat er dann als Warnhinweis zu interpretieren. Der Signaturschlüsselinhaber muss sich durch diesen Warnhinweis bewusst sein, dass er im nächsten Schritt mit der Pin-Eingabe den kontrollierten Massensignaturprozess auslöst (siehe auch Kapitel 3.2). Da es sich hier um ein Batchsignaturszenario handelt, muss gewährleistet sein, dass der Verwendungszweck der Signaturerzeugung beschränkt wird. (siehe auch Begründung zur SigV: Insbesondere bei der automatischen Erzeugung von Signaturen ("Massensignaturen") muss sichergestellt sein, dass Signaturen nur zu dem voreingestellten Zweck (z. B. Signaturen zu Zahlungsanweisungen bei Großanwendern) vorgenommen werden können. ) Gem. den Anforderungen an die administrative Einsatzumgebung wird eine Beschränkung über ein Attribut im Hauptzertifikat adressiert. HE_multisign_Enterprise_4.1.1 Seite 20 von 33

21 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 Abs. 4 SigV: Sicherheitstechnische Veränderungen an technischen Komponenten nach den Absätzen 1 bis 3 müssen für den Nutzer erkennbar werden. Bei der Prüfung einer qualifizierten elektronischen Signatur wird ein Prüfprotokoll im XML- oder PDF-Format erzeugt. Folgende Teilprüfungen werden dabei berücksichtigt - Mathematische Gültigkeit der Signatur - Gültigkeitszeitraum des Signaturzertifikats - Integrität der vollständigen Zertifikatskette (Zertifikatssignatur) - Eignung der verwendeten Algorithmen - Sperrstatus des Signaturzertifikats Dies wird durch Einsatz des Online Certificate Status Protocols (OCSP) realisiert. Serverseitige Bestandteile: Variante 1 (Server-Plattform) Sicherheitstechnische Veränderungen können mittels eines Binärvergleichs durch Abgleich der ausgelieferten Bestandteile mit den installierten Bestandteilen erkannt werden. Variante 2 (Signaturbox) Das Gehäuse der Box ist vom Hersteller versiegelt, so dass ein Austausch der CF-Karte, auf der sich die serverseitigen Bestandteile befinden, erkannt werden kann. Über die nicht versiegelte externe USB-Schnittstelle können ausschließlich vom Hersteller elektronisch signierte Versionen von multisign Enterprise eingespielt werden. Clientseitige Bestandteile: Sicherheitstechnische Veränderungen können mittels eines Binärvergleichs durch Abgleich der ausgelieferten Bestandteile mit den installierten Bestandteilen erkannt werden. HE_multisign_Enterprise_4.1.1 Seite 21 von 33

22 5. Maßnahmen in der Einsatzumgebung Die Umgebung, in der das Produkt betrieben wird, wird gemäß Bundesnetzagentur Einheitliche Spezifizierung der Einsatzbedingungen für Signaturanwendungskomponenten, Version 1.4, als Geschützter Einsatzbereich kategorisiert. Grundlage dieser Erklärung ist der Einsatz von multisign Enterprise in einem solchen geschützten Einsatzbereich. Insbesondere gilt in Kapitel 4.1 Genanntes ausschließlich unter der Voraussetzung, dass folgende Auflagen und Hinweise in Bezug auf Integration, Installation, Administration und Betrieb gewährleistet bzw. beachtet werden. Das Produkt bindet die herstellererklärte multisign Funktionsbibliothek LibSigG Version statisch ein. Somit müssen die in der Herstellererklärung zu LibSigG 5.1.1, Kapitel 5 beschriebenen Maßnahmen in der Einsatzumgebung auch bei multisign Enterprise Beachtung finden, soweit sie die einbindende Applikation also hier multisign Enterprise betreffen. 5.1 Einrichtung der IT-Komponenten Serverseitige Einsatzumgebung Variante 1 (Server-Plattform) Das Produkt in der Variante 1 kann serverseitig auf Rechnern mit folgenden Konfigurationen betrieben werden: - x86 kompatibler Prozessor - Linux 32 Bit und 64 Bit mit Kernel mindestens 128 MB RAM - mindestens eine freie serielle Schnittstelle bzw. USB-Schnittstelle Neben diesen Voraussetzungen an die Rechnerkomponenten sind für den korrekten serverseitigen Betrieb des Produktes die folgenden Anforderungen an die technische Einsatzumgebung zu erfüllen: - Chipkartenleser mit Pinpad Reiner cyberjack e-com, Version 3.0, Bestätigungs-ID TU- VIT TE Auf dem Rechner, auf dem das Produkt betrieben wird, muss der notwendige Kartenleser-Treiber installiert und aktiviert sein. - Eine nach SigG bestätigte Prozessorchipkarte (SSEE) folgenden Typs: o Sichere Signaturerstellungseinheit G&D StarCOS 3.2 QES Version 2.0 (Bestätigungs-ID: BSI TE , Nachtrag zur Bestätigung vom : T-Systems TU ) Die SSEE muss durch einen Zertifizierungsdiensteanbieter personalisiert sein und sowohl einen privaten Signaturschlüssel als auch das zugehörige qualifizierte Zertifikat tragen. Zusätzlich muss die SSEE den öffentlichen Schlüssel der Bundesnetzagentur (BNetzA) tragen. Die SSEE übernimmt einen Teil der Schutzfunktionen (Schutz vor dem Auslesen des privaten Signaturschlüssels und der PIN, Fehlbe- HE_multisign_Enterprise_4.1.1 Seite 22 von 33

23 dienungszähler 3 für das Identifikationsmerkmal (PIN), auf welche das Produkt aufbaut. Beim Einsatz von Batch-Signaturen muss die Prozessorchipkarte nach einer einmaligen Übergabe der PIN in einem Zustand bleiben, der kontinuierlich Zugriff auf die Sicherheitsdienstleistungen der Karte bietet. Die PIN braucht hierbei nicht vor jeder Nutzung einer Sicherheitsdienstleistung der Karte übergeben werden. - Der Rechner, auf dem der Signaturserver betrieben wird, sowie die eingesetzten Chipkarten und Chipkartenleser müssen in einem verriegelten Elektroschrank ( Geschützter Einsatzbereich gemäß Bundesnetzagentur Einheitliche Spezifizierung der Einsatzbedingungen für Signaturanwendungskomponenten, Version 1.4, ) eingesetzt werden Variante 2 (Signaturbox) Für das Produkt in der Variante2 wird eine spezielle Plattform (Box) mit folgender Hardware und Software eingesetzt: - Betriebssystem Linux 32 Bit mit Kernel x86 kompatibler Prozessor - mindestens 256 MB-RAM - keine Festplatte und kein CD-ROM-Laufwerk - mindestens 32 MB Compact-Flash Card - eine USB-Schnittstelle (intern) - eine USB-Schnittstelle (extern) - ein eingebauter USB-Chipkartenleser Reiner cyberjack e-com; Version 3.0, Bestätigungs-ID: TUVIT TE , welcher die CT-API-Schnittstelle unterstützt. Neben diesen Voraussetzungen an die Rechnerkomponenten sind für den korrekten serverseitigen Betrieb des Produktes in der Variante 2 die folgenden Anforderungen an die technische Einsatzumgebung zu erfüllen: - Ein handelsüblicher USB-Stick zum Einspielen der benutzerspezifischen Konfigurationswerte, welche mit dem Zusatztool Boxkonfigurator erstellt wurden, sowie der signierten Softwareupdates. Diese werden beim Start der Signaturbox geladen, sobald der USB-Stick mit diesen Komponenten an der USB-Schnittstelle vorgefunden wird. - Eine nach SigG bestätigte Prozessorchipkarte (SSEE) folgenden Typs: o Sichere Signaturerstellungseinheit G&D StarCOS 3.2 QES Version 2.0 (Bestätigungs-ID: BSI TE , Nachtrag zur Bestätigung vom : T-Systems TU ) Die SSEE muss durch einen Zertifizierungsdiensteanbieter personalisiert sein und sowohl einen privaten Signaturschlüssel als auch das zugehörige qualifizierte Zertifikat tragen. Zusätzlich muss die SSEE den öffentlichen Schlüssel der Bundesnetzagentur (BNetzA) tragen. Die SSEE übernimmt einen Teil der Schutzfunktionen (Schutz vor dem Auslesen des privaten Signaturschlüssels und der PIN, Fehlbe- 3 Innerhalb der Chipkarte ist ein Fehlbedienungszähler eingerichtet, der nur eine begrenzte Anzahl von Fehlversuchen (ein Fehlversuch entspricht der Eingabe einer falschen PIN) zulässt. Wird diese Anzahl überschritten, so sperrt sich die Chipkarte gegen jede weitere PIN-Eingabe. HE_multisign_Enterprise_4.1.1 Seite 23 von 33