Herstellererklärung. Die. TIME SIGNATURE SYSTEMS GmbH. Nartenstraße 19. D Hamburg

Transkript

1 Herstellererklärung Die TIME SIGNATURE SYSTEMS GmbH Nartenstraße 19 D Hamburg erklärt hiermit gemäß 17 Abs. 4 Satz 2 SigG in Verbindung mit 15 Abs. 5 Satz 1 SigV. dass sein Produkt QSS 400 V4.00 als Teil-Signaturanwendungskomponente zur Erzeugung qualifizierter elektronischer Signaturen die nachstehend genannten Anforderungen des SigG und der SigV in Teilen erfüllt. Hamburg, den gez. Peter Albus Geschäftsführer Diese Herstellererklärung in Version 1.3 mit der Dokumentennummer QSSHE10 besteht aus 19 Seiten. Signaturgesetz vom 16. Mai 2001 (BGBl. I S. 876), zuletzt geändert durch Artikel 4 des Gesetzes vom 17. Juli 2009 (BGBl. I S. 2091) Signaturverordnung vom 16. November 2001 (BGBl. I S. 3074), zuletzt geändert durch die Verordnung vom 17. Dezember 2009 (BGBl. I S. 3932) Seite 1 von 19

2 1. Handelsbezeichnung Die Handelsbezeichnung lautet: QSS 400 V4.00 Auslieferung: Die Auslieferung erfolgt wahlweise durch Mitarbeiter der Time Signature Systems GmbH oder per Spedition Installation, Konfiguration und Integration des QSS 400 V4.00 können wahlweise durch den Kunden selbst oder durch qualifiziertes Personal der Time Signature Systems erfolgen. Hersteller: Handelsregisterauszug: TIME SIGNATURE SYSTEMS GmbH HRB B Amtsgericht Charlottenburg Handelsregister Abteilung B Zur Auslieferung kommen folgende Komponenten: 1. Hardware 2. Software Trustbox QSS 400 Version 4.00, 19-Zoll Rackmount-Einheit, 3 Höheneinheiten (3HE) a) Protokollserver (pserver.jar) Version 4.01, Rel.1 b) SSL-Proxy (sslproxy) Version 1.36 c) Integritätstest (intetest.jar) Version 1.51 Die Auslieferung der Softwarekomponenten erfolgt auf CD-ROM. 3. Dokumentation a) Bedienungsanleitung Version 1.03 b) Sicherheitshandbuch Version 1.01 Seite 2 von 19

3 2. Lieferumfang und Versionsinformationen Nachfolgend ist der Lieferumfang, einschließlich der Versionsinformationen, aufgeführt: Produktart Bezeichnung Version Übergabeform Hardware QSS 400 Trustbox Gerät 3 Höheneinheiten (3HE) Software Protokollserver 4.01 Rel.1 auf CD-ROM Software SSL-Proxy 1.36 auf CD-ROM Software Integritätstest 1.51 auf CD-ROM Handbuch QSS ausgedruckt und auf CD-ROM Sicherheitshandbuch Handbuch QSS 400- Bedienungsanleitung 1.01 ausgedruckt und auf CD-ROM Tabelle 1: Lieferumfang und Versionsinformationen Das Produkt QSS 400 unterstützt die folgenden nach SigG bestätigten sicheren Signaturerstellungseinheiten, die nicht Bestandteil dieser Erklärung sind : Lfd. Handelsbezeichnung Nr. 1 Signaturerstellungseinh eit ZKA-Signaturkarte, Version 5.11M 2 Signaturerstellungseinheit (SSEE) TCOS 3.0 Signature Card, Version 1.1 Ausprägung: Signature Card 3.0M Version 1.0 & NetKey 3.0M, Version Signaturerstellungseinheit Chipkarte mit Prozessor SLE66CX322P, Betriebssystem CardOS V4.3B mit Applikation für digitale Signatur TUVIT T E T-Systems TE Hersteller Gemplus GmbH (Gemalto) Adalperostrasse 45, Ismaning Deutsche Telekom AG, Produktzentrum Telesec, Untere Industriestraße 20, Netphen Siemens AG, MED GS SEC, Charlesde-Gaulle-Str. 2, München Bestätigungs- ID TUVIT T U Herausgeber Betriebssystem Schlüssellänge S-Trust SECCOS Bit Telesec TCOS 3.0 2kB D-Trust CardOS V4.3B 2kB 4 Signaturerstellungseinheit Chipkarte mit Prozessor SLE66CX322P, Betriebssystem CardOS V4.3B mit Applikation für digitale T-Systems TE Siemens AG, MED GS SEC, Charlesde-Gaulle-Str. 2, München QuoVadis CardOS V4.3B 2kB Seite 3 von 19

4 Signatur 5 Signaturerstellungseinheit Chipkarte mit Prozessor SLE66CX322P, Betriebssystem CardOS V4.3B mit Applikation für digitale Signatur T-Systems TE Siemens AG, MED GS SEC, Charlesde-Gaulle-Str. 2, München TC-Trust CardOS V4.3B 2kB TC-QSign 2.0 unlimited Tabelle 2: Zusätzliche Produkte, nach SigG bestätigt Das Produkt QSS 400 nutzt folgende weiteren Komponenten, die ebenfalls nicht Bestandteil dieser Erklärung sind : Komponente Version Java-VM 1.5 oder 1.6 OpenSSL-Library 0.98 Tabelle 3: zusätzliche nicht bestätigte Komponenten Zur Auslieferung kommen folgende Komponenten: 1. Hardware Trustbox QSS 400 Version 4.00, 19-Zoll Rackmount-Einheit, 3 Höheneinheiten (3HE) 2. Software a) Protokollserver (pserver.jar) Version 4.01, Rel.1 b) SSL-Proxy (sslproxy) Version 1.36 c) Integritätstest (intetest.jar) Version 1.51 Die Auslieferung der Softwarekomponenten erfolgt auf CD-ROM. 3. Dokumentation a) Bedienungsanleitung Version 1.01 b) Sicherheitshandbuch Version 1.01 Die Auslieferung der Dokumentation erfolgt ausgedruckt und auf CD-ROM. Seite 4 von 19

5 3. Funktionsbeschreibung Identifikation Diese Herstellererklärung bezieht sich auf das Produkt QSS 400 V4.00 (im Folgenden QSS 400 genannt). Das Produkt QSS 400 ist ein aus Hard- und Softwarekomponenten bestehendes Serversystem, das unter Verwendung sicherer massensignaturfähiger Signaturerstellungseinheiten (SSEE) zur Erzeugung qualifizierter elektronischer Massensignaturen dient und ist damit entsprechend 2 Nr. 11 Signaturgesetz eine Teil-Signaturanwendungskomponente, die Daten dem Prozess der Erzeugung qualifizierter elektronischer Signaturen zuführt. Das Produkt nimmt keine Prüfung von Signaturen oder Zertifikaten vor. Die Massensignaturerzeugung muss einem bestimmten Zweck dienen, z.b. für die Signatur elektronischer Rechnungen nach 14 Abs.3 Nr. 1 UStG. Das Produkt QSS 400 basiert auf dem zuletzt am mit Nachtrag vom gemäß 15 Abs.7 und 17 Abs.4 SigG und 11 Abs.3 SigV bestätigten Produkt TSS 400 V4.01 (TUVIT TU ). Definition und Art der Nutzung Das Produkt QSS 400 ist als serverbasierter Bestandteil von Systemen einsetzbar, die automatisiert qualifizierte elektronische Signaturen für einen bestimmten Zweck, z.b. für die Signatur elektronischer Rechnungen nach 14 Abs.3 Nr. 1 UstG, erzeugen und ist damit Teil einer Signaturanwendungskomponente im Sinne des Signaturgesetzes. Zur Nutzung des Systems wird zusätzlich eine geeignete Client-Anwendung (z.b. eine Signaturanwendungskomponente gem. 17 Abs.2 SigG) - im folgenden Client-Anwendung genannt - benötigt, die dem QSS 400 die zu signierenden Daten zuführt (nicht Bestandteil des Produkts QSS 400 oder dieser Herstellererklärung). Das QSS 400 dient ausschließlich der Erzeugung von qualifizierten elektronischen Signaturen und ermöglicht keine Darstellung der zu signierenden Daten. Die Darstellung der zu signierenden Daten obliegt der Client-Anwendung, welche zudem den Benutzer feststellen lassen kann, auf welche Daten sich die Signatur bezieht. Die Kommunikation einer Client-Anwendung mit dem QSS 400 Signatur-Serversystem verläuft im Request/Response-Verfahren über eine SSL/TLS-gesicherte TCP/IP-Verbindung. Die vom System erzeugten Signaturen entsprechen dem in PKCS#7/CMS definierten Format (signeddata, detached/abgesetzt, siehe RFCs 2315, 2630 und 3369). Das Produkt QSS 400 besteht aus folgenden Hauptkomponenten : QSS 400-Trustbox (Hardware) Protokollserver (Software) SSL-Proxy (Software) Desweiteren wird ein dedizierter Server-Rechner (Hardware, nicht Bestandteil des Produkts oder dieser Herstellererklärung) benötigt, auf dem die zum Produkt QSS 400 gehörige Software (Protokollserver, SSL-Proxy) installiert wird. Seite 5 von 19

6 Die QSS 400 Trustbox ist eine aus einem Touch-Panel, einer sicheren Uhr mit DCF77-Empfänger, einem Maincontroller und 1-9 Smartcardslot(s) bestehende Hardware in 19"-Bauweise (3 Höheneinheiten). Sie vereinigt Signaturkomponenteninterface und sichere Uhr zu einer Einheit und stellt sicher, dass nur die gesetzlich gültige Zeit als Signaturzeiteintrag in der ausgestellten Signatur ("signingtime") verwendet wird. Die Trustbox veranlasst die eigentliche Signaturerstellung, indem die zu signierenden Daten (sog. signed/authenticatedattributes ) an eine der maximal neun SSEEs in der Trustbox übergeben werden. Hierzu muss die Trustbox zunächst ordnungsgemäß in Betrieb genommen worden sein (Vier-Augen- Prinzip) und der Signaturschlüsselinhaber muss seine Signaturkarte(n) (SSEE) unter Angabe der Begrenzung nach Zeit oder Anzahl der Signaturen, Eingabe der PIN und abschließender Quittierung des Warnhinweises, dass ab diesem Zeitpunkt Signaturen erzeugt werden können, eingebucht haben. Die Eingabe der SSEE-PIN erfolgt manuell ausschließlich am Touchpanel der Trustbox. Die wesentlichen Informationen der zu signierenden Daten sind der im Client-Request enthaltene Hashwert (z.b. einer elektronisch erzeugten Rechnung) und die aktuelle Zeit (Signaturzeitpunkt). Der Hashwert wird zusammen mit weiteren benötigten Informationen (z.b. dem verwendeten Hashalgorithmus) vom Protokollserver (s.u.) über eine serielle Verbindung (RS232) an die Trustbox gesendet. Die Signaturzeit (gesetzliche Zeit) wird den Signaturdaten in der Trustbox hinzugefügt. Die von den SSEEs erzeugte Signatur (Ergebnis der RSA-Verschlüsselung, encrypteddigest ) wird ebenfalls mit den weiteren benötigten Daten wie die in der Trustbox ermittelte (gesetzliche) Signaturzeit - von der Trustbox über die serielle Leitung an den Protokollserver zurückgesendet, der daraus die komplette PKCS#7/CMS-Signaturstruktur erzeugt. Es erfolgt kein PIN-Caching, d.h. die PIN der SSEE wird Trustbox-intern nicht gespeichert, sondern sofort nach Übertragung an die SSEE gelöscht (d.h. der Speicherbereich, in dem die PIN hinterlegt ist, wird nach Übertragung an die SSEE mit Null-Bytes überschrieben). Die zum Einsatz kommenden SSEEs müssen nach der einmaligen Übergabe der PIN in einem Zustand bleiben, der kontinuierlich Zugriff auf die Signaturfunktion der Karte bietet, d.h. die PIN wird nicht vor jeder Signaturerstellung, sondern nur einmal an die Karte übergeben (multi-signaturfähige SSEE). Wird eine in Betrieb genommene SSEE aus der Trustbox entfernt, wird eine auf dieser SSEE laufende Operation unmittelbar abgebrochen. Um mit dieser SSEE erneut Signaturen auszustellen, muss sie erneut in Betrieb genommen werden. Da es sich bei den zum Einsatz kommenden SSEEs um nach SigG bestätigte Komponenten handelt, wird die Korrektheit der von der SSEE erzeugten Signatur bzgl. der an sie übermittelten Daten vorausgesetzt, d.h. eine Überprüfung, ob die Daten von der SSEE korrekt signiert wurden, obliegt der Client-Anwendung. Das QSS 400 kann beim Einbuchen von SSEEs Begrenzungen der Signatur nach Zeit und Anzahl ermöglichen. Folgende Fälle sind möglich: keine Begrenzung. Die SSEE wird eingebucht und bleibt bis zu ihrer Entnahme für Signaturen freigeschaltet. In diesem Fall muss die benötigte Client-Anwendung die Begrenzung nach Zeit oder Anzahl realisieren. Begrenzung nach Anzahl. Beim Einbuchungsprozess wird eine Anzahl maximal erlaubter Signaturen vorgegeben. Die SSEE bleibt dann für Signaturen freigeschaltet, bis entweder diese Anzahl Signaturen erstellt oder sie entnommen wurde, je nachdem, was früher eintritt. Seite 6 von 19

7 Begrenzung nach Zeit. Hier wird ein zeitliches Limit vorgegeben, bis zu dem Signaturen erlaubt sind. Nach Ablauf der eingestellten Zeit werden keine Signaturen mehr erstellt. Zur Eingabe einer Begrenzungs-Zeit gibt es zwei Möglichkeiten: Begrenzung nach Zeit relativ: Es wird ein Zeitintervall bis maximal 24 Stunden vorgegeben, in dem Signaturen erlaubt sind. Begrenzung nach Zeit absolut. Es wird eine absolute Endzeit vorgegeben, bis zu der Signaturen erlaubt sind. Diese Endzeit kann maximal 24 Stunden in der Zukunft liegen. Zur Unterstützung der korrekten Eingabe wird in dem Eingabedialog die aktuelle Zeit angezeigt. Die Begrenzung wird während des Einbuchens der SSEE mit der PIN-Eingabe vorgenommen und ist nachträglich nicht änderbar. Sie können weder durch einen Neustart des Systems, noch durch Administratoren oder andere Benutzereingaben verlängert werden. Eine Verkürzung (auf Null) ist jederzeit durch physische Entnahme der SSEE möglich. Nach Eingabe der PIN und Signaturbegrenzung erscheint ein Warnhinweis auf dem Display, dass die SSEE freigeschaltet wurde und ab diesem Zeitpunkt eine Signaturerstellung möglich ist.. Der Warnhinweis muss bestätigt werden. Der physikalische Zugriff auf die SSEEs sowie das QSS 400-System (Trustbox und Server) ist durch die Einsatzumgebung auf die berechtigten Administratoren und Signaturschlüsselinhaber zu beschränken (z.b. Zutrittskontrolle). Seite 7 von 19

8 Protokollserver (Software) Der Protokollserver stellt das direkte Interface zur QSS 400-Trustbox dar. Er nimmt die Signatur-Requests des SSL-Proxies (s.u.) über lokale TCP/IP-Verbindungen entgegen, stellt daraus die zur Signaturerstellung benötigten Daten zusammen und überträgt diese über die serielle Verbindung an die Trustbox. Die von den in der Trustbox vorhandenen SSEEs erzeugte Signatur (Ergebnis der RSA-Verschlüsselung, encrypteddigest ) wird mit den signierten Attributen über die serielle Verbindung an den Protokollserver zurückgesendet. Dieser erstellt mit den vorhandenen Informationen eine Signatur-Struktur nach PKCS#7/CMS ("signeddata") und sendet diese als Response über die lokale TCP/IP-Verbindung an den SSL-Proxy zurück. Alle ausgestellten Signaturen werden in Signaturprotokolldateien gespeichert, so dass sich zu einem späteren Zeitpunkt prüfen lässt, ob eine bestimmte Signatur von einem bestimmten QSS 400-System erzeugt wurde. Aufgrund der in der Signatur enthaltenen gesetzlichen Zeit und der Speicherung der Signaturen wird der Signaturersteller (bei Erfüllung der Auflagen) in die Lage versetzt, den Zeitpunkt einer bestimmten Signatur eindeutig nachzuweisen. Zurückgeliefert wird eine Signatur im PKCS#7/CMS-Format ( signeddata, detached/abgesetzt). Der Protokollserver muss so konfiguriert sein, dass er Requests nur auf dem lokalen Interface ( ) entgegennehmen kann, d.h. er darf von außen nicht erreichbar sein, sondern nur vom ebenfalls lokal installierten SSL-Proxy. Seite 8 von 19

9 SSL-Proxy (Software) Der SSL-Proxy stellt die einzige Schnittstelle des QSS 400-Systems nach außen dar und dient zur Realisierung der sicheren Verbindung zwischen Client-Anwendung und Server per SSL/TLS und kann optional zur Erreichung der Mandantenfähigkeit des QSS 400-Systems verwendet werden. Der SSL/TLS- Port (Service-Port), unter dem der SSL-Proxy erreichbar ist, ist frei konfigurierbar. Der SSL-Proxy ist dem Protokollserver lokal vorgeschaltet und ermöglicht es in Verbindung mit diesem, Client-Signaturrequests einer bestimmten SSEE in der QSS 400-Trustbox zuzuordnen. Die Zuordnung eines Client-Signaturrequests wird dadurch realisiert, dass jeder Client beim TLS/SSL- Verbindungsaufbau ein ihm zugeordnetes X509V3-Zertifikat übertragen muss, so dass SSL-Proxy-seitig eine Unterscheidung verschiedener Clients möglich ist (SSL client authentication). Damit TLS/SSL-Signaturrequests vom Proxy an den Protokollserver weitergeleitet werden, muss zum einen das vom Client mitgeschickte Zertifikat zugelassen sein, zum anderen muss eine Zuordnung dieses Zertifikats zu einem QSS 400-Signaturzertifikat über dessen ESSCertID (SHA1-Hashwert des Zertifikats) vorhanden sein. Die Zertifikatszulassung erfolgt über die Installation der DER-codierten Zertifikatsdatei in einem speziellen Client-Zertifikatsverzeichnis, die Zuordnung zu einem Signaturzertifikat einer SSEE in der Trustbox über eine entsprechende Zuordnungsdatei (eine detaillierte Beschreibung findet sich in der Bedienungsanleitung).. Typisches Einsatzszenario Ein typisches Szenario für den Einsatz des QSS 400 ist die stapelweise Erstellung von Signaturen für Ausgangsrechnungen gem. 14 UStG. Hierbei wird eine vom QSS 400 erzeugte und der Client- Anwendung übermittelte Signatur von der Client-Anwendung gemäß ihres Bestimmungszweckes und den Einstellungen der Client-Anwendung entweder als abgesetzte Signaturdatei (.p7s) abgelegt oder in das zu signierende Dokument (.pdf) eingebettet. Technische Realisierung Das Produkt QSS 400 ist ein aus folgenden Komponenten bestehendes Serversystem : QSS 400-Trustbox (Hardware) Protokollserver (Software) SSL-Proxy (Software) Die genannten Softwarekomponenten sind auf einem dedizierten Rechner zu betreiben. Es ist sicherzustellen, dass die Softwarekomponenten nur auf einem Betriebssystem installiert werden, welches in der Lage ist, Benutzerrechte (lesen, schreiben, ausführen) zu verwalten. Dieses muss bei der Installation so konfiguriert werden, dass alle Dateien, die zur Ausführung der Serversoftware benötigt werden, geschützt sind. Dies sind alle Dateien in den Installationsverzeichnissen der Serversoftware sowie deren Unterverzeichnissen. Zur Nutzung des Systems wird zusätzlich eine geeignete Client-Anwendung benötigt, die dem QSS 400 Seite 9 von 19

10 die zu signierenden Daten zuführt (nicht Bestandteil des Produkts QSS 400 oder dieser Herstellererklärung). Die Kommunikation einer Client-Anwendung mit dem QSS 400 Signatur-Serversystem verläuft im Request/Response-Verfahren über eine SSL/TLS-gesicherte TCP/IP-Verbindung. Hierbei muss die Client-Anwendung den Hashwert über die zu signierenden Daten berechnen und diesen zunächst zusammen mit dem ObjectIdentifier des verwendeten Hashalgorithmus in folgende binär kodierte ASN.1-Struktur einfügen : MessageImprint ::= SEQUENCE { hashalgorithm AlgorithmIdentifier, // OID des Hashalgorithmus hashedmessage OCTET STRING // Hashwert über die zu signierenden Daten }; Anschließend muss der MessageImprint von der Client-Anwendung in folgende Signatur-Requeststruktur eingebettet werden : PKCS7Request ::= CHOICE [3] { SEQUENCE { version INTEGER { V1(0) } // immer 1 messageimprint MessageImprint // s.o. } } Über die vorab aufgebaute sichere SSL/TLS-Verbindung wird der Signaturrequest an den SSL-Proxy gesendet. Der SSL-Proxy leitet den Request an den Protokollserver weiter. Der Protokollserver übergibt der QSS 400-Trustbox die zu signierenden Daten, die diese mittels der eingesetzten SSEEs (Smartcards) signiert. Die von der QSS 400-Trustbox erzeugten und über den Protokollserver und den SSL-Proxy an die Client- Anwendung über SSL/TLS zurückgesendeten Signaturen entsprechen dem in PKCS#7/CMS definierten Format (signeddata, detached/abgesetzt, siehe RFCs 2315, 2630 und 3369). Die vollständige Client-Schnittstelle des QSS 400 ist im ausgelagerten öffentlichen Dokument Externe Schnittstelle der timeproof Serversoftware beschrieben. Seite 10 von 19

11 Funktionen des Produktes im Kontext des SigG und der SigV Die Teil-Signaturanwendungskomponente QSS 400 erfüllt die Anforderungen 17 Abs.2 SigG und 15 Abs.2 SigV in Teilen Das QSS 400 dient ausschließlich der Erzeugung von qualifizierten elektronischen Signaturen und ermöglicht keine Darstellung der zu signierenden Daten ( 17 Abs. 2 Satz 1 und 3 SigG) und keine Überprüfung signierter Daten ( 17 Abs. 2 Satz 2. SigG). Beides muss durch die Client-Anwendung umgesetzt werden. Detaillierte Ausführungen zur Erfüllung des Signaturgesetzes und der Signaturverordnung siehe Kapitel 4. Die Anforderung, dass Signaturen nur anlässlich eines voreingestellten Zweckes erfolgen, ist durch die Einsatzumgebung (z.b. Client-Anwendung) sicherzustellen. Durch die Verwendung entsprechender Attribute bzgl. Art oder Umfang der Nutzung der Signaturzertifikate ist der Signaturzweck eindeutig zu bezeichnen Einsatzumgebung Die Softwarekomponenten sind auf einem dedizierten Rechner zu betreiben. Es ist ein Betriebssystem zu verwenden, das in der Lage ist, Benutzerrechte zu verwalten und die zur Ausführung der Softwarekomponenten notwendigen Dateien vor unberechtigtem Zugriff zu schützen. Der Rechner ist in einem geschützten Netzwerk zu betreiben, das keine direkte Verbindung zum Internet hat und ist so abzusichern, dass Angriffe erkannt oder unterbunden werden. Es darf nur der Service-Port erreichbar sein. Um dieses zu erreichen kann eine Firewall, die lediglich den ServicePort routet, eingesetzt werden. Zum Schutz vor Viren soll die verwendete Firewall über einen Virenfilter verfügen. Alternativ kann ein Virenschutzprogramm auf dem Serverrechner eingesetzt werden. Siehe hierzu auch das von der Bundesnetzagentur veröffentlichte Dokument Einheitliche Spezifizierung der Einsatzbedingungen für Signaturanwendungskomponenten Version 1.4 vom Abschnitt 4.2 Geschützter Einsatzbereich. Der Rechner ist an einer unterbrechungsfreien Stromversorgung anzuschließen. Desweiteren wird eine Antenne zum Empfang des externen Zeitsignals benötigt. Administrative Einsatzumgebung: siehe ausgegliedertes öffentliches Dokument QSS 400 Sicherheitshandbuch. Erkennung sicherheitstechnischer Veränderungen Die Softwarekomponenten des QSS 400 müssen regelmäßig auf Manipulationsfreiheit überprüft werden. Dazu müssen die auf der Auslieferungs-CD-ROM hinterlegten Original-Hashwerte der Softwarekomponenten mit den tatsächlichen Hashwerten der installierten Software verglichen werden. Die Hashwerte müssen übereinstimmen. Zur Prüfung kann das auf CD-ROM mitgelieferte Programm intest.jar verwendet werden. Die Bedienung des Programms ist im öffentlichen Dokument QSS 400 Bedienungsanleitung beschrieben (Kapitel 6.4 Integritätstester). Seite 11 von 19

12 Sicherheitstechnische Veränderungen an der Trustbox sind wie folgt erkennbar: - regelmäßige Sichtprüfung der Siegel auf Unversehrtheit - regelmäßiger Vergleich der an der Trustbox angezeigten Uhrzeit mit einer vertrauenswürdigen Zeitquelle (z.b. telefonische Zeitansage) Ausschließliche Erzeugung von Signaturen durch den Signaturschlüsselinhaber Die einzig berechtigt signierende Person ist der Signaturschlüsselinhaber. Er ist dafür verantwortlich, dass die PIN(s) seiner in der Trustbox befindlichen SSEE(s) Dritten nicht zugänglich gemacht wird (werden). Die Zuführung der zu signierenden Daten zur QSS 400 muss authentisiert erfolgen (Verwendung von X509-Zertifikaten mit Passwort). Diese Anforderung ist durch die Einsatzumgebung sicherzustellen. Seite 12 von 19

13 4. Erfüllung der Anforderungen des Signaturgesetzes und der Signaturverordnung Das Produkt QSS 400 erfüllt die nachfolgend aufgeführten Anforderungen des SigG wie folgt: Referenz Gesetzestext Beschreibung 17 Abs. 2 Satz 1. 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 QSS 400 dient ausschließlich der Erzeugung von qualifizierten elektronischen Signaturen und ermöglicht keine Darstellung der zu signierenden Daten. Die Darstellung der zu signierenden Daten obliegt der Client-Anwendung (Teil der Einsatzumgebung). Die Erzeugung einer Signatur wird durch ein Symbol auf dem Touchpanel der QSS Abs. 2 Satz 2. SigG 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 3 geführt hat. Trustbox angezeigt. Das QSS 400 dient ausschließlich der Erzeugung von qualifizierten elektronischen Signaturen und ermöglicht keine Überprüfung der Signatur. Eine Überprüfung der Signatur muss durch die Client- Anwendung (Teil der Einsatzumgebung) erfolgen. 17 Abs. 2 Satz 3. SigG Signaturanwendungskomponenten müssen nach Bedarf auch den Inhalt der zu signierenden oder signierten Daten hinreichend erkennen lassen. Die Signaturschlüssel-Inhaber sollen solche Signaturanwendungskomponenten einsetzen oder andere geeignete Maßnahmen zur Sicherheit qualifizierter elektronischer Signaturen treffen. Das QSS 400 dient ausschließlich der Erzeugung von qualifizierten elektronischen Signaturen und ermöglicht keine Darstellung der zu signierenden oder signierten Daten. Eine Darstellung der zu signierenden oder signierten Daten muss durch die Client- Anwendung (Teil der Einsatzumgebung) erfolgen. Seite 13 von 19

14 Das Produkt QSS 400 erfüllt die nachfolgend aufgeführten Anforderungen der SigV wie folgt: Referenz Gesetzestext Beschreibung 15 Abs. 2 Nr. 1 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, Die PIN zur Aktivierung einer SSEE kann nur manuell am rollierenden Tastenfeld des Touch-Panels der Trustbox eingegeben werden. Innerhalb der Trustbox erfolgt kein PIN- Caching, d.h. die PIN der SSEE wird Trustbox-intern nicht gespeichert, sondern sofort nach Übertragung an die SSEE gelöscht, indem der Speicherbereich, in dem die PIN hinterlegt ist, nach Übertragung an die SSEE mit Null-Bytes überschrieben wird. b) eine Signatur nur durch die berechtigt signierende Person erfolgt, Die einzig berechtigt signierende Person ist der Signaturschlüsselinhaber. Er ist dafür verantwortlich, dass die PIN(s) seiner in der Trustbox befindlichen SSEE(s) Dritten nicht zugänglich gemacht wird (werden). Die Zuführung der zu signierenden Daten zur QSS 400 muss authentisiert erfolgen (Verwendung von X509- Zertifikaten mit Passwort). Diese Anforderung ist durch die Einsatzumgebung sicherzustellen. c) die Erzeugung einer Signatur vorher eindeutig angezeigt wird Nach Angabe der Begrenzung nach Zeit oder Anzahl der Signaturen und Eingabe der SSEE-PIN wird auf dem Touch- Panel der Trustbox ein zu quittierender Warnhinweis angezeigt, dass mit der entsprechenden SSEE ab sofort eine Signaturerstellung möglich ist. Die Erzeugung einer Signatur wird durch ein Symbol auf dem Seite 14 von 19

15 Touchpanel der QSS 400- Trustbox angezeigt. 15 Abs. 4 Sicherheitstechnische Veränderungen an technischen Komponenten nach den Absätzen 1 bis 3 müssen für den Nutzer erkennbar werden. Die Softwarekomponenten des QSS 400 müssen regelmäßig auf Manipulationsfreiheit überprüft werden. Dazu müssen die auf der Auslieferungs-CD-ROM hinterlegten Original-Hashwerte der Softwarekomponenten mit den tatsächlichen Hashwerten der installierten Software verglichen werden. Die Hash-werte müssen übereinstimmen. Sicherheitstechnische Veränderungen an der Trustbox sind wie folgt erkennbar : - regelmäßige Sichtprüfung der Siegel auf Unversehrtheit - regelmäßiger Vergleich der an der Trustbox angezeigten Uhrzeit mit einer vertrauenswürdigen Zeitquelle (z.b. telefonische Zeitansage) Seite 15 von 19

16 5. Maßnahmen in der Einsatzumgebung 5.1 Einrichtung der IT-Komponenten Für den Betrieb des QSS 400 werden folgende Anforderungen an den bereitzustellenden dedizierten Rechner für die Softwarekomponenten gestellt: mindestens 1024 MB Hauptspeicher eine serielle Schnittstelle eine Netzwerkschnittstelle mindestens 80 GByte freier Festplattenspeicher CD-ROM-Laufwerk ein Prozessor mit einer Rechenleistung vergleichbar einer Sun UltraSPARC IIi mit 550MHz bzw. AMD Opteron 2GHz Voraussetzung für den Betrieb der Protokollserversoftware ist eine Sun-kompatible Java-VM der Version 1.5.x oder 1.6.x Zugelassene Betriebssysteme sind Solaris 10 und SuSE Linux 10. Es ist sicherzustellen, dass die Serversoftware nur auf einem der genannten Betriebssysteme installiert wird da diese in der Lage sind, Benutzerrechte (lesen, schreiben, ausführen) zu verwalten. Das Betriebssystem muss bei der Installation so konfiguriert werden, dass alle Dateien, die zur Ausführung der Softwarekomponenten und der virtuellen Maschine benötigt werden, geschützt sind. Dies sind alle Dateien in den Installationsverzeichnissen der Softwarekomponenten und der virtuellen Maschine sowie deren Unterverzeichnissen. Installation, Konfiguration und Integration des QSS 400 können wahlweise durch den Kunden selbst oder durch qualifiziertes Personal der Time Signature Systems erfolgen. Weiterhin erforderlich siehe Tabelle 2: Zusätzliche Produkte, nach SigG bestätigt und Tabelle 3: zusätzliche nicht bestätigte Komponenten Zum Betrieb weiterhin erforderlich sind ein Stromanschluss (230 V) mit Unterbrechungsfreier Stromversorgung (USV) sowie: für den direkten Zeitsignalempfang: eine Empfangsantenne für das externe Zeitsignal ( DCF), Blitzschutz sofern Antenne im Außenbereich montiert ist bzw. für den indirekten Zeitsignalempfang: aufbereitetes Zeitsignal, das den gesetzlichen Forderungen und Genauigkeitsanforderungen genügt. Das Produkt QSS 400 darf ausschließlich innerhalb der oben beschriebenen Hard- und Softwareausstattung und Konfiguration eingesetzt werden. Die Administration, Konfiguration und Wartung der Signaturarbeitsstation darf nur von fachkundigem und berechtigtem Personal durchgeführt werden. Seite 16 von 19

17 5.2 Anbindung an ein Netzwerk Der Signaturserver muss in einem geschützten Netzwerk betrieben werden, das keine direkte Verbindung zum Internet hat und muss so abgesichert sein, dass Online-Angriffe aus dem Netzwerk erkannt oder unterbunden werden. Nur der Service-Port des Signaturservers (SSL-Proxy) darf erreichbar sein. Um dieses zu erreichen kann eine Firewall, die lediglich den Serviceport routet, eingesetzt werden. Siehe hierzu auch das von der Bundesnetzagentur veröffentlichte Dokument Einheitliche Spezifizierung der Einsatzbedingungen für Signaturanwendungskomponenten Version 1.4 vom Abschnitt 4.2 Geschützter Einsatzbereich. Die in diesem Abschnitt der Herstellererklärung gemachten Auflagen müssen eingehalten werden. 5.3 Auslieferung und Installation Die Auslieferung erfolgt wahlweise durch Mitarbeiter der Time Signature Systems GmbH oder per Spedition. Lieferumfang: siehe Tabelle 1: Lieferumfang und Versionsinformationen Bei Auslieferung durch Mitarbeiter der Time Signature Systems GmbH ist die Integrität des Produktes QSS 400 gewährleistet. Bei Auslieferung durch Spedition ist der Empfänger verpflichtet, unverzüglich die Unversehrtheit der Siegel an der Trustbox sowie der Verpackung der CD-ROM zu prüfen. Installation, Konfiguration und Integration des QSS 400 V4.00 können wahlweise durch den Kunden selbst oder durch qualifiziertes Personal der Time Signature Systems erfolgen. Die Installation der Softwarekomponenten erfolgt durch Kopieren der benötigten Dateien von der mitgelieferten CD-ROM auf den dedizierten Rechner. Eine genaue Beschreibung findet sich im öffentlichen ausgelagerten Dokument QSS 400 Bedienungsanleitung. Das spezifizierte Auslieferungs- und Installationsverfahren ist einzuhalten. 5.4 Auflagen für den Betrieb des Produktes Es muss durch räumliche und organisatorische Maßnahmen und auf seine Vertrauenswürdigkeit geprüftes Personal sichergestellt sein, dass der Zugang zum QSS 400 im Betrieb ausschließlich den Administratoren und Signaturschlüsselinhabern vorbehalten ist. Die Passwörter für den Zugriff auf die Trustbox und den dedizierten Rechner sind geheimzuhalten. Protokollserver- und SSL-Proxy-Software müssen auf dem dedizierten Rechner installiert sein. Nur der Service-Port des Signaturservers (SSL-Proxy) darf erreichbar sein. Die PIN-Eingabe der SSEE darf nach Signaturgesetz ausschließlich durch den Signaturschlüsselinhaber erfolgen. Die PIN muss geheim gehalten werden. Seite 17 von 19

18 Die Softwarekomponenten des QSS 400 müssen regelmäßig auf Manipulationsfreiheit überprüft werden. Die Siegel der Trustbox sind regelmäßig auf Unversehrtheit zu prüfen. Die an der Trustbox angezeigte Uhrzeit ist regelmäßig mit einer vertrauenswürdigen Zeitquelle zu vergleichen. Mit Auslieferung des Produktes QSS 400 ist der Anwender auf die Einhaltung der oben genannten Einsatzbedingungen hinzuweisen. 6. Algorithmen und zugehörige Parameter Zur Erzeugung qualifizierter elektronischer Signaturen werden vom Produkt QSS 400 die Hashfunktionen SHA-224 und SHA-256 eingesetzt. Laut der "Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der Signaturverordnung (Übersicht über geeignete Algorithmen) vom 06. Januar 2010 " (veröffentlicht im Bundesanzeiger Nr Seite 426 vom 04. Februar 2010) ist SHA-224 bis Ende 2015 und SHA-256 bis Ende 2016 für die Anwendung bei qualifizierten elektronischen Signaturen geeignet. Das als Signaturalgorithmus eingesetzte RSA-Verfahren mit den unterstützten Bitlängen von 1976 und 2048 ist danach bis Ende 2016 gültig. Der Anwender wird bei Änderungen dieser Gültigkeiten vom Hersteller per informiert und auf notwendige Maßnahmen hingewiesen. Die Konfiguration des Systems bezüglich der erlaubten Hash-Algorithmen ist im öffentlichen Herstellerdokument Bedienungsanleitung QSS 400 im Kapitel 6.1 Protokollserverversoftware -Sektion [HashAlgorithms]- beschrieben (siehe nachfolgenden Auszug aus dem genannten Dokument). Sektion [HashAlgorithms] MD5=false RIPEMD160=true SHA1=false SHA224=true SHA256=true Dieser Eintrag definiert, ob MD5 unterstützt wird, default=false Dieser Eintrag definiert, ob RIPEMD160 unterstützt wird, default=true Dieser Eintrag definiert, ob SHA1 unterstützt wird, default=false Dieser Eintrag definiert, ob SHA224 unterstützt wird, default=true Dieser Eintrag definiert, ob SHA256 unterstützt wird, default=true Tabelle 4: Auszug aus Bedienungsanleitung, Konfiguration erlaubter Hash-Algorithmen 7. Gültigkeit der Herstellererklärung Diese Erklärung ist bis zu ihrem Widerruf, längstens jedoch bis zum gültig (beschränkt durch die in Kapitel 6 aufgeführten Gültigkeiten der Hash-Funktionen und des RSA-Verfahrens). Die Gültigkeit kann sich verkürzen, wenn z.b. neue Feststellungen hinsichtlich der Sicherheit des Produktes oder der Eignung des RSA-Verfahrens oder der Hash-Funktionen im Bundesanzeiger veröffentlicht werden. Der aktuelle Status der Gültigkeit der Erklärung ist bei der zuständigen Behörde (Bundesnetzagentur, Referat Qualifizierte Elektronische Signatur Technischer Betrieb) zu erfragen. Diese Herstellererklärung kann von der zuständigen Behörde (Bundesnetzagentur) sowie vom Hersteller Seite 18 von 19

19 selbst zurückgezogen werden. 8. Zusatzdokumentation Folgende Bestandteile der Herstellererklärung wurden aus dem Veröffentlichungstext ausgegliedert und bei der zuständigen Behörde hinterlegt: Öffentliche Dokumente: 1. QSS 400 Bedienungsanleitung (V1.03, Stand Juni 2010, 92 Seiten) 2. QSS 400 Sicherheitshandbuch (V1.03, Stand Juni 2010, 26 Seiten) 3. Externe Schnittstelle der timeproof Serversoftware (V2.20, Stand , 33 Seiten) Nicht-öffentliche Dokumente: 4. Sicherheitsvorgaben des QSS 400-Signatursystems (V1.02, Stand , 30 Seiten) 5. Architekturentwurf des QSS 400-Signatursystems (V1.00, Stand , 36 Seiten) 6. Feinentwurf Firmware Steuerung (V1.00, Stand , 18 Seiten) 7. Feinentwurf Firmware Signatur (V1.00, Stand , 29 Seiten) 8. Feinentwurf Firmware Uhr (V1.00, Stand , 42 Seiten) 9. Schnittstelle Bus (V1.90, Stand , 30 Seiten) 10. Feinentwurf des QSS Protokollserversoftware (V1.00, Stand , 13 Seiten) 11. Schnittstelle Sicherheitsbox (Trustbox) - Host (V1.00, Stand , 26 Seiten) 12. Spezifikation des QSS SSL-Proxy (V1.00, Stand , 8 Seiten) 13. Architektur des Integritätstesters (V1.00, Stand , 26 Seiten) 14. QSS 400 Testspezifikation (V1.03, Stand , 94 Seiten) 15. Konfigurationskontrolle Entwicklung (V1.0 Stand , 16 Seiten) Ende der Herstellererklärung Seite 19 von 19