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 Funktionsbibliothek LibSigG, 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 Koelzer Vorstand secunet Security Networks AG gez. ppa. Thomas Stürznickel Leiter Geschäftsbereich secunet Security Networks AG Diese Herstellererklärung in Version 1.6 mit der Dokumentennummer HE-LIBSIGG_5.1.1 besteht aus 29 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ß Berichtigung der Referenzen auf die Algorithmenkataloge 2008 und Jürgen Foß Neue Version 5.1.1: Erweiterung des Auslieferungsverfahrens, Änderung einer Betriebssystemplattform von SunOS nach Linux 64bit, Versionsanpassungen und Referenzaktualisierungen Jürgen Foß Einarbeitung der Kommentare aus dem atsec-prüfbericht vom Jürgen Foß Einarbeitung der Kommentare aus dem atsec-prüfbericht v2 vom HE-LIBSIGG_5.1.1 Seite 2 von 29

3 1. Handelsbezeichnung Die Handelsbezeichnung lautet: multisign Funktionsbibliothek LibSigG, Version Auslieferung: CD-ROM, persönliche Übergabe oder FTP-Server Hersteller: secunet Security Networks AG Handelsregisterauszug: HRB 13615, Amtsgericht Essen Die vorliegende Herstellererklärung bezieht sich auf das Produkt multisign Funktionsbibliothek LibSigG, Version für die Betriebssystem-Plattformen Windows XP (32bit), Linux 32bit sowie Linux 64bit (beide mit Kernel 2.6) der secunet Security Networks AG, HRB 13615, Amtsgericht Essen (Hersteller). Die Auslieferung durch den Hersteller erfolgt 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. Dies geschieht durch die Bildung dieser Hashsummen über die ausgelieferten Softwaremodule. Die zu überprüfenden Hashsummen werden alle in der Textdatei Hashsummen.txt mit ausgeliefert. Über diese Textdatei muss wiederum eine Hashsumme gebildet werden, welche mit dem Hersteller telefonisch abgeglichen werden muss. Dazu muss sich der Anwendungsentwickler, der LibSigG in sein Produkt integriert, an die Support-Hotline des Herstellers wenden. Die Hashsummen werden mit dem linuxeigenen Betriebssystemwerkzeug sha1sum berechnet (auch für die Windows-Version der LibSigG). Die weiterführenden Hinweise zum Auslieferungsverfahren und zur Installation in Kapitel 5.3 sind zu beachten. 2. Lieferumfang und Versionsinformationen Da es sich bei dem Produkt um eine Funktionsbibliothek handelt, ist zur Einbindung des Produktes in eine Anwendung ein C-Compiler notwendig, dessen Befehlssatz der ANSI/ISO C Norm entspricht (siehe auch Kapitel 5.4). Der C-Compiler gehört nicht zum Lieferumfang des Produktes. Die einbindende Anwendung gehört ebenfalls nicht zum Lieferumfang des Produktes und ist auch nicht Bestandteil dieser Herstellererklärung. Die einbindende Anwendung bedarf einer SigG Bestätigung oder einer Herstellererklärung, damit qualifizierte elektronische Signaturen erzeugt werden können (siehe auch Kapitel 3.3 und 5.6) Zum Lieferumfang gehörende Komponenten Die Auslieferung der multisign Funktionsbibliothek LibSigG, Version umfasst folgende Bestandteile, die gemäß Kapitel 5.3 entweder auf CD-ROM oder via FTP-Server zur Verfügung gestellt werden: HE-LIBSIGG_5.1.1 Seite 3 von 29

4 Bezeichnung Beschreibung Version / Datum / Übergabeform LibSigGAPI.h Headerdatei zur dynamischen Funktionsbibliothek libsigg.dll sowie libsigg.a Revision 38 / / CD-ROM oder Online- Verfahren gemäß Kapitel 5.3 LibSigGDef.h LibSigGErrors.h LibSigG.dll LibSigG.lib liblibsigg.a Headerdatei zur dynamischen Funktionsbibliothek libsigg.dll sowie libsigg.a Headerdatei zur dynamischen Funktionsbibliothek libsigg.dll sowie libsigg.a Dynamische Funktionsbibliothek für Windows 32 Bit Stublib zum Einbinden der dynamischen Funktionsbibliothek für Windows 32 Bit Statische Funktionsbibliothek für Linux 32 und 64 Bit Revision 48 / / CD-ROM oder Online- Verfahren gemäß Kapitel 5.3 Revision 21 / / CD-ROM oder Online- Verfahren gemäß Kapitel 5.3 Version / / CD-ROM oder Online- Verfahren gemäß Kapitel 5.3 Ohne Version / / CD-ROM oder Online- Verfahren gemäß Kapitel 5.3 Version / / CD-ROM oder Online- Verfahren gemäß Kapitel 5.3 CertificateDatabase.dat Zertifikatsdatenbank Ohne Version / / CD-ROM oder Online- Verfahren gemäß Kapitel 5.3 configmodule.ini LibSigG.reg Konfigurationsdatei für Funktionsbibliothek unter Linux Konfigurationsdatei für Funktionsbibliothek unter Windows Ohne Version / / CD-ROM oder Online- Verfahren gemäß Kapitel 5.3 Ohne Version / / CD-ROM oder Online- Verfahren gemäß Kapitel 5.3 HE_LIBSIGG_BD_5.1.1.pdf Betriebsdokumentation HE_LIBSIGG_SV_5.1.1.pdf Sicherheitsvorgaben Version 1. / / Digitale Form Version 1. / / Digitale Form HE_LIBSIGG_EU_5.1.1.pdf Entwicklungsumgebung Version 1.2 / / Digitale Form Hashsummen_LibSigG txt Textdatei mit Hashwerten Version / Tabelle 1: Lieferumfang und Versionsinformationen HE-LIBSIGG_5.1.1 Seite 4 von 29

5 2.2. Nicht zum Lieferumfang gehörende Produkte 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 pinpad; Version 3.0 TUVIT TU Kartenleser Reiner cyberjack e-com; Version 3.0 TUVIT TE Tabelle 2: Zusätzliche Produkte, die gemäß Signaturgesetz und Signaturverordnung geprüft und bestätigt sind. 3. Funktionsbeschreibung Das Produkt multisign Funktionsbibliothek LibSigG, Version (im folgenden kurz Lib- SigG genannt) stellt eine Funktionsbibliothek zur Realisierung einer Signaturanwendungskomponente dar, die mit Hilfe von Chipkartensystemen (Chipkartenleser, Chipkartenbetriebssystem, personalisierte Chipkarte) elektronische Dokumente zur Wahrung deren Integrität und Authentizität mit einer qualifizierten elektronischen Signatur versehen kann. Neben der Möglichkeit zur Erzeugung einer qualifizierten elektronischen Signatur können solche Signaturen auch verifiziert werden. Zeitstempelerzeugung und Zeitstempelprüfung werden nicht unterstützt. Das Produkt multisign Funktionsbibliothek LibSigG ist eine Teil- Signaturanwendungskomponente, die in eine Applikation eingebunden werden muss. Die einbindende Applikation bedarf einer SigG Bestätigung oder einer Herstellererklärung, damit qualifizierte elektronische Signaturen erzeugt werden können (siehe auch Kapitel 3.3 und 5.6). Die Funktionsbibliothek LibSigG stellt keine Mechanismen zur Verfügung, um gemäß SigG 17 Abs. 2 Satz 1 dem Erzeuger vor Signaturerstellung kenntlich zu machen auf welche Daten sich die Signatur bezieht. Dies muss die einbindende Applikation leisten und kann z.b. durch Anzeige des Dateinamens oder im Batchbetrieb entsprechende Aspekte erfolgen. Gemäß SigG 17 Abs. 2 Satz 3 muss zusätzlich auch der Inhalt der zu signierenden oder signierten Daten bei Bedarf hinreichend erkennbar sein, was durch Anzeige des vollständigen Inhaltes z.b. mittels secure viewer oder im Batchbetrieb entsprechenden Aspekten erfolgt. Auch dies wird nicht durch die Funktionsbibliothek LibSigG geleistet, sondern muss durch die einbindende Applikation gewährleistet werden. Das Produkt LibSigG trägt als Teil-Signaturanwendungskomponente zur Erfüllung folgender gesetzlicher Kriterien bei, die in Kapitel 4 ausführlich erläutert werden: HE-LIBSIGG_5.1.1 Seite 5 von 29

6 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. LibSigG hat unter Berücksichtigung der Forderungen des SigG und der SigV folgende Aufgaben: Daten, die über eine Schnittstelle an LibSigG übergeben werden, dem Prozess der Erzeugung qualifizierter elektronischer Signaturen zuzuführen. Die eigentliche Signaturerzeugung erfolgt durch die sicheren Signaturerstellungseinheit (SSEE). qualifizierte elektronische Signaturen zu prüfen oder qualifizierte Zertifikate nachzuprüfen und die Ergebnisse anzuzeigen Anstoßen einer qualifizierten elektronischen Signaturerzeugung Zum Anstoßen einer qualifizierten Signaturerzeugung erfolgt zunächst die Inbetriebnahme und Initialisierung der SSEE durch Übergabe einer PIN via Pinpad-Leser (die zugelassenen Leser lassen sich Kapitel 2.2 entnehmen) an die SSEE. Die PIN muss hierbei vor jedem Anstoßen einer qualifizierten Signaturerzeugung erneut am Pinpad-Leser eingeben werden. LibSigG unterstützt daneben auch die Erstellung von qualifizierten elektronischen Signaturen im Massensignaturbetrieb (siehe hierzu auch Kapitel 3.6 (lsgactivatecryptofunctionsecurepin) und Betriebsdokumentation zur LibSigG Kapitel 8.1). Zur Realisierung von Batchsignatur-Szenarien / Massensignatur ist es möglich, nach einmaliger Eingabe der PIN mehrere qualifizierte Signaturerzeugungen nacheinander anzustoßen. Die verwendete SSEE muss hierbei den Batchbetrieb unterstützen. Die Applikation, welche LibSigG einbindet, muss im Rahmen des Einsatzes von Batch-Signaturen / Massensignaturbetrieb eine Möglichkeit zur Verfügung stellen, die Anzahl der zu erstellenden Signaturen zu beschränken. Dies kann durch ein Zeitfenster realisiert werden, welches bei der Freischaltung der Kryptofunktionalität (also beim Aufruf der Funktion lsgactivatecryptofunctionsecurepin) gestartet wird. Nach Ablauf des Zeitfensters muss die Kryptofunktionalität der SSEE dann durch die aufrufende Applikation deaktiviert werden (mittels lsgdeactivatecryptofunction). Des Weiteren muss vor der Erzeugung einer Signatur (bzw. vor dem Anstoßen der Erzeugung) von der Applikation ein geeigneter Warnhinweis gemäß 15(2) Nr.1c SigV angezeigt werden. Dies muss sowohl für das Anstoßen qualifizierter Einzelsignaturen geschehen als auch vor dem Anstoßen von Signaturen im Batchbetrieb. Ein Batch-Betrieb darf ausschließlich zur Erstellung von Signaturen für gleichwertige Dokumente geschehen (z.b. Signaturen zu Zahlungsanweisungen bei Großanwendern). Dies ist organisatorisch vom Endanwender sicher zu stellen. Das Produkt selbst führt technisch keine solche Prüfung auf Gleichwertigkeit der zu signierenden Dokumente durch. Zur Erzeugung einer qualifizierten elektronischen Signatur muss die PIN zwingend über das Pinpad des Kartenlesers an die Chipkarte (SSEE) übergeben werden. Die PIN ist zu jedem Zeitpunkt geheim zu halten. Diese Anforderung wird technisch nicht vom Produkt, sondern durch die Nutzung der Chipkarte (SSEE), verbunden über einen Kartenleser mit Pinpad, der im Modus Sichere PIN-Eingabe betrieben werden muss, umgesetzt. Sowohl die SSEE als auch die in Frage kommenden Kartenleser müssen bestätigt sein. Sie sind in Kapitel 2 gelistet und zwingend einzusetzen. Die aufrufende Applikation hat dafür Sorge zu tragen, dass zur Erzeugung einer qualifizierten Signatur die PIN-Eingabe zur Freischaltung der SSEE nur über das PINPad des Kartenlesers erfolgen darf. Dazu ist ausschließlich die LibSigG Funktion zu nutzen, die den Kartenleser in den Modus Sichere PIN-Eingabe versetzt (lsgactivatecryptofunctionsecurepin, siehe Kapitel 3.6). Eine Eingabe über die Applikation ist in einem SigG-konformen Betrieb nicht erlaubt. Falls die PIN nicht via Pinpad, sondern als Parameter an LibSigG übergeben wird, werden keine qualifizierten elektroni- HE-LIBSIGG_5.1.1 Seite 6 von 29

7 schen Signaturen erstellt. Im Falle der Übergabe der PIN als Parameter an LibSigG muss dem Nutzer dementsprechend per Applikation angezeigt werden, dass damit nachfolgend keine SigG konforme qualifizierte Signatur erzeugt wird. Nach korrekter Initialisierung der Chipkarten erzeugt LibSigG dann über die zu signierenden Daten einen Hashwert, der anschließend unter Zuhilfenahme eines privaten Signaturschlüssels innerhalb der Chipkarte verschlüsselt wird. Als Hashalgorithmus wird sha2-224, sha2-256, sha2-384, sha2-512 unterstützt; als asymmetrischer Kryptographiealgorithmus wird RSA 2048 unterstützt (StarCOS der Kryptoalgorithmus wird von der jeweils eingesetzten SSEE zur Verfügung gestellt). Diese Unterstützung ist aber davon abhängig, ob die jeweiligen Algorithmen in der Konfiguration von LibSigG als geeignet konfiguriert sind. Der Administrator hat bei der Installation und bei möglichen Wartungsarbeiten dafür Sorge zu tragen, dass in der Konfiguration zur LibSigG die korrekten Werte für die Gültigkeit der Algorithmen gemäß Bundesnetzagentur (siehe Kapitel 6) hinterlegt sind (siehe hierzu auch Kapitel 5.3). 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 mittels LibSigG nicht zugelassen und LibSigG liefert eine Fehlermeldung. Wird beispielsweise am der Versuch unternommen, mittels sha2-224 eine Signatur zu erstellen, so wird dies von LibSigG verhindert, da der Hashalgorithmus sha2-224 gemäß Bundesnetzagentur (siehe Kapitel 6) nur bis zum als geeignet eingestuft ist. Der verschlüsselte Hashwert stellt die qualifizierte elektronische Signatur der Daten dar. Die signierten Daten und die Signatur werden von LibSigG in einen Datencontainer abgelegt: Folgende Signaturformate werden hierbei unterstützt: PKCS#7 (detached und embedded Signature), gemäß RFC 2315 PKCS#1, gemäß RFC 3447 XML Dsig, gemäß W3C XML-Signature Syntax and Processing PDF (integrierte Signatur), gemäß PDF Standard ISO Zusätzlich wird in den Datencontainer noch die zur Signatur korrespondierende Zertifikatskette eingebunden, wobei die Zertifikate von der Chipkarte gelesen werden. Zertifikate, die sich nicht auf der Chipkarte befinden (z.b. CA-Zertifikat), werden aus der Zertifikatsdatenbank (realisiert als Datei) gelesen. Des Weiteren wird für die Signaturformate PKCS#7, XML und PDF die aktuelle Systemzeit als Signaturerstellungszeitpunkt in den Datencontainer integriert. LibSigG überprüft während des Arbeitsschrittes Erzeugung einer Signatur nicht, ob die Signatur auch tatsächlich korrekt erstellt wurde. Der Kunde hat jedoch die Möglichkeit mit LibSigG oder einem anderen, geeigneten Verifikationswerkzeug die Signatur nach der Erstellung selbst auf Korrektheit zu überprüfen (Details zur Verifikation siehe Kapitel 3.2). Bei der Verwendung von LibSigG hat dazu die einbindende Applikation die Funktion lsgverify- WithVerificationReport aufzurufen (Details zur Funktion siehe Kapitel 3.6). Es muss zudem organisatorisch dafür Sorge getragen werden (geschützter Einsatzbereich gemäß Bundesnetzagentur Einheitliche Spezifizierung der Einsatzbedingungen für Signaturanwendungskomponenten, Version 1.4, ), dass keine Daten bei der Übertragung über die Schnittstelle zum/vom Chipkartenleser manipuliert werden können, um das Einspeisen falscher Signaturdaten zu verhindern (siehe hierzu Kapitel 3.5.2) Verifikation einer qualifizierten elektronischen Signatur HE-LIBSIGG_5.1.1 Seite 7 von 29

8 Neben der Möglichkeit zur Erzeugung einer qualifizierten elektronischen Signatur können solche Signaturen auch verifiziert werden. Folgende Signaturformate werden für die Prüfung einer Signatur unterstützt: PKCS#7 (detached und embedded Signature), gemäß RFC 2315 PKCS#1, gemäß RFC 3447 XML Dsig, gemäß W3C XML-Signature Syntax and Processing PDF (integrierte Signatur), gemäß PDF Standard ISO Die qualifizierte elektronische Signatur wird anhand des öffentlichen Signaturprüfschlüssels des Unterzeichners geprüft. Zu diesem Zweck müssen von der Applikation, welche LibSigG nutzt, folgende Daten übergeben werden: Signaturumfang Qualifizierte elektronische Signatur über den Signaturumfang Zugehöriges qualifiziertes Zertifikat Der Vertrauensanker (Root-Zertifikat) wird von der Chipkarte bzw. aus der Zertifikatsdatenbank der LibSigG 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 LibSigG 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 und in Kapitel näher beschrieben. Es wird im Rahmen der Verifikation von LibSigG geprüft, ob es sich beim verwendeten Hashalgorithmus um einen zum Prüfzeitpunkt (dies kann entweder der aktuelle Verifikationszeitpunkt oder die im PKCS#7-Container oder XML-DSIG-Signatur enthaltene Signing- Time sein) gemäß Bundesnetzagentur zugelassenen Algorithmus handelt (zur Gültigkeit der Algorithmen siehe Kapitel 6). Der Administrator hat bei der Installation und bei möglichen Wartungsarbeiten dafür Sorge zu tragen, dass in der Konfiguration zur LibSigG die korrekten Werte für die Gültigkeit der Algorithmen gemäß Bundesnetzagentur hinterlegt sind (siehe hierzu auch Kapitel 5.3 und Kapitel 6). Es wird von der LibSigG ebenfalls geprüft, ob es sich beim Kryptographie- Signieralgorithmus um einen zum Prüfzeitpunkt (dies kann entweder der aktuelle Verifikationszeitpunkt oder die im PKCS#7-Container enthaltene SigningTime sein) gemäß Bundesnetzagentur zugelassenen Algorithmus handelt. Der Administrator hat auch hier bei der Installation und bei möglichen Wartungsarbeiten dafür Sorge zu tragen, dass in der Konfiguration zur LibSigG die korrekten Werte für die Gültigkeit der Algorithmen gemäß Bundesnetzagentur hinterlegt sind (siehe hierzu auch Kapitel 5.3 und Kapitel 6). Die Prüfungen hinsichtlich der Gültigkeit der verwendeten Algorithmen werden ebenfalls auf die Zertifikatssignaturen in der Zertifikatskette angewandt. Der Administrator hat ebenfalls HE-LIBSIGG_5.1.1 Seite 8 von 29

9 für die hier verwendeten Algorithmen bei der Installation und bei möglichen Wartungsarbeiten dafür Sorge zu tragen, dass in der Konfiguration zur LibSigG die korrekten Werte für die Gültigkeit der Algorithmen gemäß Bundesnetzagentur hinterlegt sind (siehe hierzu auch Kapitel 5.3 und Kapitel 6). Bei der Prüfung von qualifizierten elektronischen Signaturen durch LibSigG 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 in LibSigG 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. War er bereits zum Zeitpunkt der Signaturerstellung ungültig, so wird bei der Verifikation ein negatives Ergebnis geliefert (Prüfung nicht bestanden) und der Grund dafür 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. Ist er nach dem Signaturerstellungszeitpunkt abgelaufen, so gibt es zwei mögliche Varianten, da der Prüfzeitpunkt vom Benutzer wählbar ist: a.) Prüfzeitpunkt ist Signaturerstellungszeitpunkt oder b.) Prüfzeitpunkt ist aktuelle Systemzeit: a.) Wird als Prüfzeitpunkt Signaturerstellungszeitpunkt gewählt und ist der Signaturerstellungszeitpunkt im vorliegenden Signaturformat enthalten, liefert die Prüfung ein positives Ergebnis (qualifizierte elektronische Signatur). Allerdings wird zusätzlich der oben aufgeführte Hinweistext ausgegeben, dass der Algorithmus an Beweiskraft verloren hat. b.) Wird als Prüfzeitpunkt der aktuelle Verifikationszeitpunkt (Systemzeit) gewählt, so ist der Signaturerstellungszeitpunkt dem Produkt nicht verlässlich bekannt. Der Benutzer wählt diese Option in der Regel dann, wenn er den Angaben zum Signaturerstellungszeitpunkt nicht vertraut oder der Signaturerstellungszeitpunkt nicht bekannt ist. In diesem Falle kann das Produkt keine Aussage darüber treffen, ob der verwendete Algorithmus vor oder nach dem Signaturerstellungszeitpunkt abgelaufen ist. Somit wird das Gesamtergebnis als negativ dargestellt und angegeben, dass die Signatur ungültig ist. Der Grund dafür wird in Form eines Hinweistextes (siehe oben) ausgegeben. Hinweis: Ein Signaturerstellungszeitpunkt kann z.b. innerhalb eines PKCS#7- Containers oder einer XML-DSIG-Signatur hinterlegt sein. In einer PKCS#1-Signatur ist der Signaturerstellungszeitpunkt grundsätzlich nicht hinterlegt. Auch PKCS#7- Signaturen können, aber müssen nicht den Zeitpunkt der Signaturerstellung enthalten. Wenn der Benutzer die Option a.) wählt (Prüfzeitpunkt = Signaturerstellungszeitpunkt), sucht LibSigG diesen Signaturerstellungszeitpunkt im vorliegenden Signaturformat. Liegt er dort als unterschriebener Teil der Signatur vor, so wird dieser Signaturerstellungszeitpunkt gemäß a.) verwendet. Liegt der Signaturerstellungszeitpunkt im übergebenen Signaturformat nicht vor, so wird der Verifikationszeitpunkt immer als Prüfzeitpunkt verwendet (Variante b.). Der verwendete Prüfzeitpunkt (Signaturerstellungszeitpunkt oder Verifikationszeitpunkt) wird im Prüfprotokoll angegeben. Das Ergebnis der Signaturprüfung, die Hinweise hinsichtlich der verwendeten Algorithmen und der verwendete Prüfzeitpunkt werden innerhalb eines XML-Prüfprotokolls oder PDF- HE-LIBSIGG_5.1.1 Seite 9 von 29

10 Prüfprotokolls an die Applikation übergeben (Detailangaben zu den Prüfberichten sind HE_LIBSIGG_BD_5-1 Kapitel zu entnehmen) Anbindung an einer Anwendung Um die oben beschriebenen Funktionen nutzen zu können, muss LibSigG in eine Anwendung/Applikation eingebunden werden, da es selber kein eigenständig lauffähiges Programm darstellt. LibSigG stellt über die LibSigG-API eine Reihe von Schnittstellenfunktionen zur Verfügung, auf deren Basis ein Applikations-Programmierer die Funktionen von LibSigG nutzen kann (C-Programmierschnittstelle). Diese einbindende Anwendung bedarf einer SigG Bestätigung oder einer Herstellererklärung, damit qualifizierte elektronische Signaturen erzeugt werden können und muss dementsprechende Aspekte berücksichtigen (siehe auch Kapitel 5.6). Abbildung 1: LibSigG in ihrer Einsatzumgebung 3.4. Rollendefinition HE-LIBSIGG_5.1.1 Seite 10 von 29

11 An dieser Stelle sollen Begriffe zum Rollenkonzept definiert werden, da diese im folgenden Verwendung finden: Anwendungsentwickler / Applikations-Programmierer Das Produkt wird von einem Anwendungsentwickler / Applikations-Programmierer in eine Anwendung / Applikation eingebunden. Administrator Der Administrator installiert und wartet die vom Anwendungsentwickler entwickelte Applikation auf dem Zielsystem. Da LibSigG Teil dieser Applikation ist, installiert und wartet der Administrator zugleich das Produkte LibSigG. Benutzer / Endanwender Der Benutzer nutzt die vom Anwendungsentwickler programmierte und vom Administrator installierte Applikation zur Erstellung und Verifikation von qualifizierten elektronischen Signaturen. Da LibSigG Teil dieser Applikation ist, nutzt der Benutzer zugleich das Produkte LibSigG Schnittstellen des Produktes Es existieren vier Schnittstellen des Produktes: Online-Verbindung für OCSP-Anfragen zum ZDA, Verbindung zur SSEE über den Kartenleser, eine Programmierschnittstelle und eine Dateischnittstelle, welche im Folgenden beschrieben werden 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 LibSigG 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 Verbindung zur SSEE über den Kartenleser LibSigG ermöglicht mit Hilfe von Chipkartensystemen (Chipkartenleser, SSEE) elektronische Dokumente zur Wahrung deren Integrität und Authentizität mit einer qualifizierten elektronischen Signatur zu versehen. Es dürfen dabei nur geprüfte und bestätigte Chipkarten-Terminals und sichere Signaturerstellungseinheit (SSEE) zum Einsatz kommen (siehe HE-LIBSIGG_5.1.1 Seite 11 von 29

12 Kapitel 2.2). Die Schnittstelle zu diesen Geräten erfolgt wahlweise über PC/SC oder CTAPI. Auf dem Rechner, auf dem die Funktionen von LibSigG genutzt werden, muss der notwendige Kartenleser-Treiber installiert und aktiviert sein. Unter Windows ist dies beispielsweise der PC/SC-Dienst (Treiber zur Unterstützung der Schnittstelle PC/SC; WINSCARD.DLL). PC/SC wird nur für Windows und Linux (Kernel 2.6) unterstützt. Zur Nutzung der CTAPI müssen die vom Chipkartenleserhersteller zur Verfügung gestellten Treiber installiert sein und genutzt werden. Diese sind vom Administrator in die Konfiguration zur LibSigG gemäß Betriebsdokumentation einzutragen. Das Produkt muss in einer geschützten Einsatzumgebung betrieben werden (Bundesnetzagentur Einheitliche Spezifizierung der Einsatzbedingungen für Signaturanwendungskomponenten, Version 1.4, ). Im Batchbetrieb muss das Produkt mitsamt Kartenleser und SSEE zusätzlich in einem verriegelten Elektroschrank betrieben werden, um einem manuellen Zugriff Unbefugter auf den Signaturschlüssel im Rahmen von Batchsignaturen während des Zeitfensters entgegenzuwirken. Dieser Elektro- /Serverschrank muss so beschaffen sein, dass ein manueller Zugriff Unbefugter und Datenaustausch per Datenträger mit hoher Sicherheit abgewehrt werden. Dies ist vom Administrator bei der Installation zu gewährleisten und vom Hersteller der Applikation, die Lib- SigG integriert, in die Dokumentation zum Batchbetrieb der Applikation aufzunehmen Programmierschnittstelle LibSigG wird in eine Anwendung eingebunden, da es selber kein eigenständig lauffähiges Programm darstellt. LibSigG stellt über die LibSigG-API eine Reihe von C- Schnittstellenfunktionen zur Verfügung, auf deren Basis ein Applikations-Programmierer die Funktionen von LibSigG nutzen kann. Die Einbindung in die Applikation muss mit einem C- Compiler realisiert werden, dessen Befehlssatz der ANSI/ISO C++ Norm entspricht. Siehe dazu auch die Betriebsdokumentation zur LibSigG, Kapitel 5.2. Diese Schnittstellenfunktionen werden im Kapitel 3.6 näher beschrieben. Der Anwendungsentwickler darf diese Programmierschnittstelle nur in der hier beschriebenen Art und Weise verwenden. Der Anwendungsentwickler hat ferner dafür Sorge zu tragen, dass die Einsatzumgebung, in welcher die Entwicklung stattfindet, abgesichert ist und die Software der einbindenden Applikation vor Manipulation geschützt ist. Es muss gewährleistet werden, dass Unbefugte nicht die Software der einbindenden Applikation manipulieren können (siehe auch Kapitel 5) Dateischnittstelle Daten zur Signaturerstellung und zur Signaturverifikation können mittels der Programmierschnittstelle entweder direkt übergeben werden, oder es können an der Programmierschnittstelle Dateinamen zu diesen Datenobjekten angegeben werden. LibSigG liest in diesem Fall die zu signierenden oder zu verifizierenden Daten aus diesen Dateien. Hierbei dürfen nur solche Dateipfade angegeben werden, die vor Zugriffen Unbefugter geschützt sind. Dies sind zum einen Pfade auf dem Rechner, auf welchem LibSigG installiert ist und der in einem geschützter Einsatzbereich betrieben wird (siehe hierzu Kapitel 5.4). Bei der Verwendung von Netzwerkpfaden ist durch Zugriffsbeschränkungen und Firewall sicher zu stellen, dass kein Zugriff Unbefugter auf diese Dateipfade erfolgen kann Abbildung der Anforderungen des Signaturgesetzes und der Signaturverordnung auf die Applikationsschnittstelle Folgende Funktionen, die an der Umsetzung der in Kapitel 4.1 beschrieben Anforderungen beteiligt sind, werden von LibSigG an der Applikationsschnittstelle wie folgt bereitgestellt. Es ist zu beachten, dass für den SigG-konformen Betrieb der LibSigG der Funkti- HE-LIBSIGG_5.1.1 Seite 12 von 29

13 onsparameter noptions (falls vorhanden, z.b. bei lsgsign) zusätzlich mit dem Wert e_nouserinterface belegt werden muss. Es werden mittels e_nouserinterface alle Interaktion mit dem Benutzer (Dialoge, Fehlermeldungen) durch die Funktionsbibliothek LibSigG unterdrückt. Alle Interaktionen mit dem Benutzer müssen im SigG-konformen Betrieb über die aufrufende Applikation geschehen. lsgsign: Diese Funktion erstellt eine qualifizierte elektronische Signatur der gegebenen Daten im PKCS#1, PKCS#7, PDF- oder XML-DSIG-Format. Die SSEE selbst liefert dabei lediglich eine Rohdatensignatur in der Länge des zugehörigen Schlüssels. Diese Rohdatensignatur wird von LibSigG in die genannten Signaturformate eingebettet. Es können nur Signaturen mit Hash- und Kryptographie-Signieralgorithmen erzeugt werden, deren Algorithmen gemäß Bundesnetzagentur als geeignet eingestuft sind. lsgverifywithverificationreport: Diese Methode prüft signierte Datencontainer und liefert einen ausführlichen Prüfbericht im XML- oder PDF-Format zurück. Die Methode kann PKCS#1, PKCS#7, PDF- oder XML-DSIG-Formate prüfen. Bei der Prüfung von qualifizierten elektronischen Signaturen durch LibSigG 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 in Lib- SigG nicht implementiert ist, so wird dies dem Nutzer ebenfalls zutreffend angezeigt. lsgcheckcertificate: Diese Funktion prüft das gegebene Zertifikat. Zunächst wird die entsprechende Zertifikatskette ermittelt. Anschließend erfolgt die mathematische Prüfung dieser Kette, d.h. es wird überprüft, ob die Signaturen der Zertifikate intakt sind. Dann werden die Gültigkeitszeiträume der Zertifikate geprüft. Abschließend kann zusätzlich mit dieser Funktion der Sperrstatus (Online-Prüfung) des Benutzerzertifikats ermittelt werden. Die Ergebnisse werden in einer C-Struktur zurück gegeben. lsgcheckcertificateverbose: Diese Funktion prüft das gegebene Zertifikat genau wie lsgcheckcertificate, jedoch wird anstatt einer C-Struktur ein ausführlicheres Prüfprotokoll im PDF- oder XML- Format zurück geliefert. lsgactivatecryptofunctionsecurepin: Diese Funktion stößt die Prüfung der über das Pinpad eines Pinpad-Lesers eingegebenen PIN an. Nach erfolgreicher Prüfung wird das PSE für die entsprechende Kryptofunktion freigeschaltet. Nachdem die PIN einmal am Pinpad eingegeben wurde, können anschließend (beliebig) viele Krypto-Operationen mit dieser LibSigG Instanz durchgeführt werden. Eingeschränkt ist die Eingabe durch das Zeitfenster, nach dessen Ablauf die Chipkarte deaktiviert wird und dann keine weiteren Signaturerstellungen möglich sind, bis lsgactivatecryptofunctionsecurepin erneut aufgerufen und die PIN erneut am Kartenleser eingegeben wird. Für Client-(nicht Server) Anwendungen ist bei der Verwendung dieser Funktion zur SigG-konformen Anwendung zwingend erforderlich, dass nach anschließender, einmaliger Signaturerstellung die Funktion lsgdeactivatecryptofunction aufgerufen und damit die Kryptofunktionalität der SSEE nach einmaliger Nutzung wieder deaktiviert wird. HE-LIBSIGG_5.1.1 Seite 13 von 29

14 lsgdeactivatecryptofunction: Diese Funktion deaktiviert die momentan freigeschaltete Kryptofunktion des PSEs. Nachdem die PIN einmal an die LibSigG übergeben wurde, können anschließend beliebig viele Krypto-Operationen mit dieser LibSigG Instanz durchgeführt werden. Dieser Zustand kann durch den Aufruf dieser Funktion wieder beseitigt werden. lsgacquirelsginstance: Bevor eine Funktion der Applikationsschnittstelle verwendet werden kann, muss zunächst ein LSGInstanceHandle angefordert werden. Dieses Handle muss anschließend an alle Funktion übergeben werden. Das Handle ermöglich die parallele Verwendung verschiedener LibSigG Instanzen. lsgacquirelsginstancectapi: Bevor eine Funktion der Applikationsschnittstelle verwendet werden kann, muss zunächst ein LSGInstanceHandle angefordert werden. Diese Methode entspricht der oben beschriebenen Funktion lsgacquirelsginstance. Jedoch wird anstelle eines UserFriendlyNames eine Portnummer für die CT-API Schnittstelle angegeben Sicherheitstechnische Veränderungen Sicherheitstechnische Veränderungen an der multisign Funktionsbibliothek LibSigG müssen erkennbar sein. Die Wahrung von Integrität und Authentizität im laufenden Betrieb wird immer mit einem Binärvergleich realisiert. Ein integerer und authentischer Initialzustand wird durch entsprechende Auslieferungsverfahren mittels Hash-Summenvergleiche (FTP) oder durch Binärvergleich (CD) sichergestellt (siehe Kapitel 1 und 5.3). Für Überprüfungen während des Betriebs muss ein Abbild des integeren authentischen Initialzustandes (FTP) bzw. die überlieferte CD (persönliche Übergabe der CD) selbst für weitere Binärvergleiche herangezogen werden (sichere Aufbewahrung der CD ist Vorraussetzung). Dies geschieht im Einzelnen wie folgt: Bei vorhergehender Auslieferung durch persönlich übergebene Auslieferungs-CD: Hier werden die auf der Auslieferungs-CD befindlichen Softwarebestandteile herangezogen und mit den im Einsatz befindlichen Softwarebestandteilen binär verglichen. Der Binärvergleich kann beispielsweise für die Windows-Variante mit dem Betriebssystemkommando comp und für die Unix-Variante mit dem Betriebssystemkommando diff durchgeführt werden. Bei vorhergehender Auslieferung per FTP-Server: Hier müssen die Hashsummen der einzelnen Softwaremodule mit allen Hashsummen in der mit ausgelieferten Textdatei Hashsummen.txt verglichen werden. Über diese Textdatei muss wiederum eine Hashsumme gebildet werden, welche mit dem Hersteller telefonisch abgeglichen werden muss. Dazu muss sich der Anwendungsentwickler, der LibSigG in sein Produkt integriert, an die Support-Hotline des Herstellers wenden. Die Hashsummen werden mit dem linuxeigenen Betriebssystemwerkzeug sha1sum berechnet (auch für die Windows-Version der Lib- SigG). Optional bei vorhergehender Auslieferung per FTP-Server: Nach Auslieferung per FTP- Server und Prüfung aller Softwarekomponenten mittels der Hashsummenvergleiche, kann vom Anwendungsentwickler, der LibSigG in sein Produkt integriert, eine CD mit den überprüften Softwarekomponenten erstellt und sicher aufbewahrt werden. Ist dies geschehen, kann die Integritäts- und Authentizitätsprüfung auch nach dem Verfahren durchgeführt werden, welches für den Fall der persönlich übergebenen Auslieferungs-CD beschrieben ist (Binärvergleich mit den Daten auf der CD). HE-LIBSIGG_5.1.1 Seite 14 von 29

15 Für den Fall, dass das Root-Zertifikat in der Zertifikatsdatenbank hinterlegt wird, muss dafür Sorge getragen werden, dass Änderungen der Zertifikatsdatenbank nur unter Einhaltung des 4-Augenprinzips erfolgen dürfen, was zur Folge hat, dass LibSigG durch 2 Nutzer administriert werden muss. 4. Erfüllung der Anforderungen des Signaturgesetzes und der Signaturverordnung 4.1. Erfüllte Anforderungen Anforderung 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. Erfüllung Diese Aspekte sind von der aufrufenden Applikation (siehe auch Kapitel 5.6) zu gewährleisten. LibSigG setzt diese Anforderung nicht um. Die Funktionsbibliothek LibSigG stellt keine Mechanismen zur Verfügung, um dem Erzeuger vor Signaturerstellung kenntlich zu machen auf welche Daten sich die Signatur bezieht. Dies muss die einbindende Applikation leisten und kann z.b. durch Anzeige des Dateinamens oder im Batchbetrieb entsprechende Aspekte erfolgen. Die zu signierenden Daten müssen von der Applikation vollständig an die Programmierschnittstelle von LibSigG übergeben werden. Des Weiteren muss vor der Erzeugung einer Signatur (bzw. vor dem Anstoßen der Erzeugung) von der Applikation ein geeigneter Warnhinweis angezeigt werden. Dies muss sowohl für das Anstoßen qualifizierter Einzelsignaturen geschehen als auch vor dem Anstoßen von Signaturen im Batchbetrieb. HE-LIBSIGG_5.1.1 Seite 15 von 29

16 Anforderung 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. Erfüllung Die aufrufende Applikation hat dafür Sorge zu tragen, dass die Daten, auf die sich die Signatur bezieht, vorher dem Benutzer mittels secure viewer angezeigt oder im Batchbetrieb entsprechende Aspekte berücksichtigt werden. Es wird ein detailliertes Prüfprotokoll im XML- oder PDF-Format erzeugt, anhand dessen sich die geforderten Inhalte feststellen lassen. Die Anwendung, die LibSigG verwendet, übergibt Signatur, signierte Daten und Zertifikat mitsamt öffentlichem Signaturprüfschlüssel über die Programmierschnittstelle an LibSigG (siehe auch Kapitel 3.2). Dies kann entweder durch direkte Übergabe der Daten erfolgen oder durch Angabe von Dateinamen, unter welchen Signaturumfang und signierte Daten zu finden sind. LibSigG wendet auf die übergebene Signatur eine Kryptooperation mit dem öffentlichen Signaturprüfschlüssel an. Über die an LibSigG übergebenen Daten wird ein Hashwert erstellt. Dieser Hashwert wird mit dem Ergebnis der Kryptooperation verglichen und das Ergebnis in dem Prüfprotokoll eingetragen. Nur wenn diese beiden Werte gleich sind, liegen die Daten unverändert vor. LibSigG liest die Inhalte, wie den Signaturschlüssel-Inhaber, aus dem Zertifikat und dem Attributzertifikat (falls vorhanden) aus und gibt diese Inhalte im Prüfbericht an. LibSigG testet die gesamte Zertifikatskette gemäß Kettenmodell und das Benutzerzertifikat mit Online-Sperrstatusprüfung (wie in Kapitel 3.2 und näher beschrieben) und gibt die Ergebnisse im Prüfbericht an. HE-LIBSIGG_5.1.1 Seite 16 von 29

17 Anforderung Signaturanwendungskomponenten müssen nach Bedarf auch den Inhalt der zu signierenden oder signierten Daten hinreichend erkennen lassen. 15 Abs. 2 SigV: Signaturanwendungskomponenten nach 17 Abs. 2 des Signaturgesetzes müssen gewährleisten, dass 1) bei der Erzeugung einer qualifizierten elektronischen Signatur Erfüllung Dieser Aspekt ist von der aufrufenden Applikation (siehe auch Kapitel 5.6) zu gewährleisten. Die zu signierenden Daten müssen vollständig an die Programmierschnittstelle von LibSigG übergeben und die signierten Daten von der Applikationen an der Programmierschnittstelle vollständig angenommen werden. Die aufrufende Applikation hat dafür Sorge zu tragen, dass zu signierende Daten vorher dem Benutzer mittels secure viewer angezeigt oder im Batchbetrieb entsprechende Aspekte berücksichtigt werden. HE-LIBSIGG_5.1.1 Seite 17 von 29

18 Anforderung a) die Identifikationsdaten nicht preisgegeben und diese nur auf der jeweiligen sicheren Signaturerstellungseinheit gespeichert werden, Erfüllung Zur Erzeugung einer qualifizierten elektronischen Signatur muss die PIN zwingend über das Pinpad des Kartenlesers an die Chipkarte (SSEE) übergeben werden. Die PIN ist zu jedem Zeitpunkt geheim zu halten. Diese Anforderung wird technisch nicht vom Produkt, sondern durch die Nutzung der Chipkarte (SSEE), verbunden über einen Kartenleser mit Pinpad, der im Modus Sichere PIN-Eingabe betrieben werden muss, umgesetzt. Sowohl die SSEE als auch die in Frage kommenden Kartenleser müssen bestätigt sein. Sie sind in Kapitel 2 gelistet und zwingend einzusetzen. Die aufrufende Applikation hat dafür Sorge zu tragen, dass zur Erzeugung einer qualifizierten Signatur die PIN-Eingabe zur Freischaltung der SSEE nur über das PINPad des Kartenlesers erfolgen darf. Dazu ist ausschließlich die LibSigG Funktion zu nutzen, die den Kartenleser in den Modus Sichere PIN-Eingabe versetzt (lsgactivatecryptofunctionsecurepin, siehe Kapitel 3.6). Eine Eingabe über die Applikation ist in einem SigG-konformen Betrieb nicht erlaubt. Falls die PIN nicht via Pinpad, sondern als Parameter an LibSigG übergeben wird, werden keine qualifizierten elektronischen Signaturen erstellt. Im Falle der Übergabe der PIN als Parameter an Lib- SigG muss dem Nutzer dementsprechend per Applikation angezeigt werden, dass damit nachfolgend keine SigG konforme qualifizierte Signatur erzeugt wird. HE-LIBSIGG_5.1.1 Seite 18 von 29

19 Anforderung b) eine Signatur nur durch die berechtigt signierende Person erfolgt, Erfüllung Das Anstoßen einer qualifizierten Signaturerzeugung ist nur möglich, nachdem die Übergabe der korrekten PIN der SSEE am Pinpad-Kartenleser erfolgt ist. Somit liegt die PIN, die ausschließlich der zur Signatur berechtigten Person bekannt ist, nur im Chipkartenleser vor und wird nicht durch die Software LibSigG, der einbindenden Applikation oder den verwendeten Rechner geleitet. Das Rechnersystem, auf dem die nutzende Applikation betrieben wird, muss gegen eine unberechtigte Benutzung gesichert sein. Der Benutzer der Applikation muss sich davon überzeugen, dass jede auf dem Rechner installierte Software weder böswillig manipuliert noch in irgendeiner anderen Form verändert wurde, um Daten auszuforschen, zu verändern oder die Funktion anderer Programme unzulässig zu verändern. Das Produkt muss in einer geschützten Einsatzumgebung betrieben werden (Bundesnetzagentur Einheitliche Spezifizierung der Einsatzbedingungen für Signaturanwendungskomponenten, Version 1.4, ). Im Batchbetrieb muss das Produkt mitsamt Kartenleser und SSEE zusätzlich in einem verriegelten Elektroschrank betrieben werden, um einem manuellen Zugriff Unbefugter auf den Signaturschlüssel im Rahmen von Batchsignaturen während des Zeitfensters entgegenzuwirken. Die erforderlichen technischen und organisatorischen Maßnahmen (diese beinhalten auch entsprechende Anforderungen an die nutzende Applikation) in der Einsatzumgebung sind zu beachten. Durch diese Maßnahmen wird gewährleistet, dass ausschließlich die zur Signatur berechtigte Person Signaturen erstellen kann. HE-LIBSIGG_5.1.1 Seite 19 von 29

20 Anforderung 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 Abs. 4 SigV: Erfüllung Dieser Aspekt ist von der aufrufenden Applikation (siehe auch Kapitel 5.6) zu gewährleisten. LibSigG setzt diese Anforderung nicht um. Vor der Erzeugung einer Signatur (bzw. vor dem Anstoßen der Erzeugung) muss von der Applikation ein geeigneter Warnhinweis angezeigt werden. Dies muss sowohl für das Anstoßen qualifizierter Einzelsignaturen geschehen als auch vor dem Anstoßen von Signaturen im Batchbetrieb. 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 und Prüfung der gesamten Zertifikatskette gemäß Kettenmodell - Integrität der vollständigen Zertifikatskette (Zertifikatssignaturen) - Sperrstatus des Signaturzertifikats - Eignung der verwendeten Hashund Kryptographiealgorithmen Dies wird durch Einsatz des Online Certificate Status Protocols (OCSP) realisiert. HE-LIBSIGG_5.1.1 Seite 20 von 29

21 Anforderung Sicherheitstechnische Veränderungen an technischen Komponenten nach den Absätzen 1 bis 3 müssen für den Nutzer erkennbar werden. Erfüllung Sicherheitstechnischen Veränderungen können vom Benutzer mittels eines Binärvergleichs durch Abgleich der ausgelieferten Bestandteile mit den installierten Bestandteilen erkannt werden. Für den Fall, dass das Root-Zertifikat in der Zertifikatsdatenbank hinterlegt wird, muss dafür Sorge getragen werden, dass Änderungen der Zertifikatsdatenbank nur unter Einhaltung des 4-Augenprinzips erfolgen dürfen, was zur Folge hat, dass LibSigG durch 2 Nutzer administriert werden muss. 5. Maßnahmen in der Einsatzumgebung Grundlage dieser Erklärung ist der Einsatz der multisign Funktionsbibliothek LibSigG in einer gesicherten Einsatzumgebung. Insbesondere gilt unter das in Kapitel 2 und 4.1 genannte ausschließlich unter der Voraussetzung, dass folgende Auflagen und Hinweise in Bezug auf Integration, Installation, Administration und Betrieb gewährleistet bzw. beachtet werden Auflagen und Hinweise Es sei darauf hingewiesen, dass im Rahmen der Erfüllung der Anforderung aus 15 Abs. 2 Nr. 1 b) insbesondere bei Nutzung in so genannten Batchsignatur-Szenarien die erforderlichen technischen und organisatorischen Maßnahmen (diese beinhalten auch entsprechende Anforderungen an die nutzende Applikation) in der Einsatzumgebung zu beachten sind. Eine Applikation muss die Sicherheitsfunktionen der multisign Funktionsbibliothek LibSigG in vorgeschriebener Art nutzen Anbindung an ein Netzwerk Das Produkt multisign Funktionsbibliothek LibSigG, Version darf nur in Verbindung mit einer Firewall an ein Netzwerk angeschlossen werden. Das Produkt multisign Funktionsbibliothek LibSigG, Version darf nur in Verbindung mit einem Virenscanner an das Internet angeschlossen werden. Die in diesem Abschnitt gemachten Auflagen müssen eingehalten werden Auslieferung und Installation Die multisign Funktionsbibliothek LibSigG ist eine Funktionsbibliothek, die alleine nicht lauffähig ist und von einem Anwendungsentwickler verwendet werden kann, um Funktionen zur Erzeugung und Prüfung qualifizierter elektronischer Signaturen in Anwendungen zu integrieren. Hierbei darf die multisign Funktionsbibliothek LibSigG nur in Verbindung mit vertrauenswürdigen Anwendungen eingesetzt werden. Diese Anwendungen sind nicht Gegenstand dieser Herstellererklärung. Anforderungen an solche Anwendungen sind unter anderem in Kapital 5.6 aufgeführt. HE-LIBSIGG_5.1.1 Seite 21 von 29