abl-16
Dieses Dokument ist Teil der Anfrage „Amtsblätter bis 2018“
Amtsblatt der Bundesnetzagentur
für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen
2810 – Mitteilungen, Qualifizierte elektronische Signatur, 16 2010
Teil A, Mitteilungen der Bundesnetzagentur –
Herstellererklärung – multisign Enterprise, Version 4.1
Anforderung Erfüllung
Für die Überprüfung signierter Daten sind Es wird ein detailliertes Prüfprotokoll im
Signaturanwendungskomponenten erfor- XML- oder PDF-Format erzeugt, anhand
derlich, die feststellen lassen, dessen sich die geforderten Inhalte feststel-
len lassen:
1) auf welche Daten sich die Signatur
bezieht, PDF:
1. Dateiname
2) ob die signierten Daten unverändert
sind, 2. Mathematische Prüfung bestanden/
nicht bestanden
3) welchem Signaturschlüssel-Inhaber die
Signatur zuzuordnen ist, 3. Signiert von (aus Zertifikat ausgelesen)
4) welche Inhalte das qualifizierte Zertifi- 4. Zertifikat (qualifiziertes Zertifikat, qualifi-
ziertes Attribut-Zertifikat)
kat, auf dem die Signatur beruht, und
zugehörige qualifizierte Attribut- 5. Zertifikatsprüfung bestanden/ nicht be-
Zertifikate aufweisen und standen (Zertifikatskette), Sperrstatus-
prüfung bestanden/ nicht bestanden
5) zu welchem Ergebnis die Nachprüfung
XML:
von Zertifikaten nach § 5 Abs. 1 Satz 2
geführt hat. 1. File-Interface: Dateiname der signierten
Datei ist im Dateinamen des XML-
Prüfprotokolls enthalten
Network-Interface: Dateiname ist nicht
im XML-Prüfprotokoll enthalten, son-
dern muss von der nutzenden Client-
API-Applikation angezeigt werden. Die-
se ruft die entsprechende Methode zur
Prüfung an der Client-API auf, wobei
das zu prüfende Dokument übergeben
wird.
2. XML-Tag: Math Checks (ok/error)
3. XML-Tag: Certificate Subject (aus Zerti-
fikat 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)
Signaturanwendungskomponenten müssen Das Produkt verfügt über keinen „secure
nach Bedarf auch den Inhalt der zu signie- viewer.“ Um den Inhalt der zu signierenden
oder signierten Daten bei Bedarf einsehen
renden oder signierten Daten hinreichend
zu können, wird ein externer „secure vie-
erkennen lassen. wer“ benötigt, beispielsweise für das Doku-
mentenformat „PDF“ der Adobe Reader.
HE_multisign_Enterprise_4-1 Seite 16 von 26
Bonn, 25. August 2010
Amtsblatt der Bundesnetzagentur
für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen
16 2010 – Mitteilungen, Qualifizierte elektronische Signatur, 2811
Teil A, Mitteilungen der Bundesnetzagentur –
Herstellererklärung – multisign Enterprise, Version 4.1
5. Maßnahmen in der Einsatzumgebung
Die Umgebung, in der das Produkt betrieben wird, wird gemäß dem Dokument „Einheitliche
Spezifizierung der Einsatzbedingungen für Signaturanwendungskomponenten“ 4 als ge-
schützter Einsatzbereich kategorisiert.
Grundlage dieser Erklärung ist der Einsatz von multisign Enterprise in einer geschützten
Einsatzumgebung. Insbesondere gilt unter 4.1 genanntes ausschließlich unter der Voraus-
setzung, dass folgende Auflagen und Hinweise in Bezug auf Integration, Installation, Admi-
nistration und Betrieb gewährleistet bzw. beachtet werden.
5.1 Einrichtung der IT-Komponenten
5.1.1 Serverseitige Einsatzumgebung
5.1.1.1 Variante 1 (Server-Plattform)
Das Produkt in der Variante 1 kann serverseitig auf Rechnern mit folgenden Konfiguratio-
nen betrieben werden:
- x86 kompatibler Prozessor bzw. SPARC-Prozessor
- Linux (= Kernel 2.6.), Sun Solaris Version 9
- mindestens 128 MB RAM
- mindestens eine freie serielle Schnittstelle bzw. USB-Schnittstelle (für den Ausbau:
PCI-Slot für Mux-Karten)
Neben diesen Voraussetzungen an die Rechnerkomponenten sind für den korrekten ser-
verseitigen Betrieb des Produktes die folgenden Anforderungen an die technische Einsatz-
umgebung zu erfüllen:
- Chipkartenleser mit PIN-Pad „Reiner cyberjack e-com, Version 3.0“, Bestätigungs-ID
TU-VIT.93155.TE.09.2008 oder „Kobil Kaan Advanced, Firmware Version 1.02, Hard-
ware Version K104R3“, Bestätigungs-ID: BSI.02050.TE.12.2006). Auf dem Rechner,
auf dem das Produkt betrieben wird, muss der notwendige Kartenleser-Treiber instal-
liert 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.02114.TE.12.2008, Nachtrag zur Bestätigung vom
08.03.2010: T-Systems.02243.TU.03.2010)
Die SSEE muss durch einen Zertifizierungsdiensteanbieter personalisiert sein und
sowohl einen privaten Signaturschlüssel als auch das zugehörige qualifizierte Zerti-
fikat tragen. Zusätzlich muss die SSEE den öffentlichen Schlüssel der Bundesnetz-
agentur (BNetzA) tragen. Die SSEE übernimmt einen Teil der Schutzfunktionen
(Schutz vor dem Auslesen des privaten Signaturschlüssels und der PIN, Fehlbe-
4
Einheitliche Spezifizierung der Einsatzbedingungen für Signaturanwendungskomponenten, Version 1.4, Stand
19.07.2005, - Arbeitsgrundlage für Entwickler/Hersteller und Prüf- und Bestätigungsstellen -
http://www.bundesnetzagentur.de/cae/servlet/contentblob/37092/publicationFile/2443/SpezifiziergEinsatzBedinggn
Id2648pdf.pdf
HE_multisign_Enterprise_4-1 Seite 17 von 26
Bonn, 25. August 2010
Amtsblatt der Bundesnetzagentur
für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen
2812 – Mitteilungen, Qualifizierte elektronische Signatur, 16 2010
Teil A, Mitteilungen der Bundesnetzagentur –
Herstellererklärung – multisign Enterprise, Version 4.1
dienungszähler 5 für das Identifikationsmerkmal (PIN), auf welche das Produkt auf-
baut.
Beim Einsatz von Batch-Signaturen muss die Prozessorchipkarte nach einer ein-
maligen Ü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 Chip-
karten und Chipkartenleser müssen in einem verriegelten Elektroschrank eingesetzt
werden.
5.1.1.2 Variante 2 (Signaturbox)
Für das Produkt in der Variante2 wird eine spezielle Plattform (Box) mit folgender Hardware
und Software eingesetzt:
- 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äti-
gungs-ID: TUVIT.93155.TE.09.2008, welcher die CT-API-Schnittstelle unterstützt.
Neben diesen Voraussetzungen an die Rechnerkomponenten sind für den korrekten ser-
verseitigen Betrieb des Produktes in der Variante 2 die folgenden Anforderungen an die
technische Einsatzumgebung zu erfüllen:
- ein handelsüblicher USB-Stick zur Hinterlegung der frei konfigurierbaren Konfigurati-
onswerte
- 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.02114.TE.12.2008, Nachtrag zur Bestätigung vom
08.03.2010: T-Systems.02243.TU.03.2010)
Die SSEE muss durch einen Zertifizierungsdiensteanbieter personalisiert sein und
sowohl einen privaten Signaturschlüssel als auch das zugehörige qualifizierte Zerti-
fikat tragen. Zusätzlich muss die SSEE den öffentlichen Schlüssel der Bundesnetz-
agentur (BNetzA) tragen. Die SSEE übernimmt einen Teil der Schutzfunktionen
(Schutz vor dem Auslesen des privaten Signaturschlüssels und der PIN, Fehlbe-
dienungszähler 6 für das Identifikationsmerkmal (PIN), auf welche das Produkt auf-
baut.
Beim Einsatz von Batch-Signaturen muss die Prozessorchipkarte nach einer ein-
maligen Übergabe der PIN in einem Zustand bleiben, der kontinuierlich Zugriff auf
5
Innerhalb der Chipkarte ist ein Fehlbedienungszähler eingerichtet, der nur eine begrenzte Anzahl von Fehlversu-
chen (ein Fehlversuch entspricht der Eingabe einer falschen PIN) zulässt. Wird diese Anzahl überschritten, so
sperrt sich die Chipkarte gegen jede weitere PIN-Eingabe.
6
Innerhalb der Chipkarte ist ein Fehlbedienungszähler eingerichtet, der nur eine begrenzte Anzahl von Fehlversu-
chen (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 Seite 18 von 26
Bonn, 25. August 2010
Amtsblatt der Bundesnetzagentur
für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen
16 2010 – Mitteilungen, Qualifizierte elektronische Signatur, 2813
Teil A, Mitteilungen der Bundesnetzagentur –
Herstellererklärung – multisign Enterprise, Version 4.1
die Sicherheitsdienstleistungen der Karte bietet. Die PIN braucht hierbei nicht vor
jeder Nutzung einer Sicherheitsdienstleistung der Karte übergeben werden.
- Die Signaturbox sowie die eingesetzten Chipkarten und Chipkartenleser müssen in
einem verriegelten Elektroschrank eingesetzt werden.
Bemerkung:
- Für das File-Interface kommt zusätzlich ein dedizierter Rechner mit Festplatte und in-
stalliertem SMB-Dienst zum Einsatz, auf dem das Eingangs- und Ausgangsverzeichnis
für das File-Interface angelegt ist. Dieser Rechner muss über eine Netzwerkanbindung
verfügen, so dass Dateien in das entsprechende Eingangsverzeichnis übermittelt wer-
den können und eine Verbindung zur Signaturbox besteht, so dass die Festplatte die-
ses Rechners per SMB angesprochen werden kann. Weiter muss dieser Rechner auf
einem Betriebsystem betrieben werden, dass über Zugriffskontrollmechanismen
(einschl. einer zugrunde liegenden I&A) verfügt, so dass nur autorisierte Personen
Zugriff auf das Eingangs-/ Ausgangverzeichnis haben. Des Weiteren müssen sich Sig-
naturbox und der dedizierte Rechner mit Festplatte sowie die Netzwerkkabel innerhalb
eines verriegelbaren Elektroschranks befinden, damit die integere Übermittlung der zu
signierenden Daten von diesem Rechner zur Signaturbox gewährleistet ist. Bezüglich
Hardwareausstattung werden an diesen Rechner keine zusätzlichen Anforderungen
gestellt.
5.1.2 Clientseitige Einsatzumgebung (beide Varianten)
Für den korrekten clientseitigen Betrieb des Produktes sind die folgenden Anforderungen
an die technische Einsatzumgebung zu erfüllen:
- Applikationen, in welche die clientseitige Funktionsbibliothek eingebunden ist, können
auf Rechnern mit folgenden Konfigurationen betrieben werden:
o x86 kompatibler Prozessor bzw. SPARC-Prozessor
o Betriebssystem Windows XP, Linux (Kernel=2.6), Sun Solaris Version 9,
o mindestens 128 MB RAM
o eine Netzverbindung (z.B. mittels eines Modems) zum Signaturserver
- Die Einbindung in die Applikation muss mit einem C-Compiler realisiert werden, dessen
Befehlssatz der ANSI/ISO C Norm entspricht. Unter Windows kann dies beispielsweise
mit Microsoft Visual C++ 7.0, unter Unix mit dem Compiler gcc 3.4 erfolgen.
5.2 Anbindung an ein Netzwerk
Die Netzwerkverbindung zur Server-Plattform (Variante 1) bzw. zur Signaturbox (Variante
2) sowie zum Client-Rechner ist durch eine Firewall entsprechend abzusichern, so dass nur
befugte Zugriffe möglich sind.
Bei Verwendung eines dedizierten Rechners für das File-Interface im Rahmen von Variante
2 (Signaturbox) ist die Netzwerkverbindung zu diesem Rechner ebenfalls durch eine Fire-
wall entsprechend abzusichern.
Zur Bestimmung des Online-Status von Zertifikaten ist für die Server-Plattform (Variante 1)
bzw. die Signaturbox (Variante 2) eine Netzverbindung zum Verzeichnisdienst eines SigG-
konformen Zertifizierungsdiensteanbieters (ist konfigurierbar) erforderlich.
Im Falle der Nutzung des File-Interfaces muss die Einsatzumgebung die Kommunikation in
Bezug auf Integrität und Authentizität absichern (z.B. Verwendung einer VPN-Lösung).
HE_multisign_Enterprise_4-1 Seite 19 von 26
Bonn, 25. August 2010
Amtsblatt der Bundesnetzagentur
für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen
2814 – Mitteilungen, Qualifizierte elektronische Signatur, 16 2010
Teil A, Mitteilungen der Bundesnetzagentur –
Herstellererklärung – multisign Enterprise, Version 4.1
5.3 Auslieferung und Installation
Das vorliegende Produkt multisign Enterprise darf nur in der hier beschriebenen Hard- und
Softwareausstattung und Konfiguration eingesetzt werden. Lieferumfang und Versionsin-
formationen sind Kapitel 2 zu entnehmen.
5.3.1 Serverseitige Bestandteile Variante 1 (Server-Plattform)
Das Produkt wird auf einer Single-Session CD-ROM ausgeliefert. Die Installation der ser-
verseitigen Bestandteile des Produktes wird durch den Hersteller beim Kunden durchge-
führt.
5.3.2 Serverseitige Bestandteile Variante 2 (Signaturbox)
Die serverseitigen Bestandteile werden auf einer CompactFlash-Karte, die fest innerhalb
der Signaturbox eingebaut ist, ausgeliefert. Die serverseitigen Bestandteile des Produktes
sind bereits durch den Hersteller vorinstalliert.
5.3.3 Clientseitige Bestandteile (beide Varianten)
Die clientseitigen Bestandteile werden auf einer Single-Session CD-ROM ausgeliefert.
Bei den clientseitigen Bestandteilen (Client-API Bibliothek) handelt es sich um eine Funkti-
onsbibliothek, die alleine nicht lauffähig ist und von einem Anwendungsentwickler verwen-
det werden kann, um die Funktionalität von multisign Enterprise über das Network-Interface
zu nutzen. Die Installation der clientseitigen Bestandteile erfolgt gemäß Benutzerdokumen-
tation.
5.4 Auflagen für den Betrieb des Produkts
5.4.1 Serverseitige Einsatzumgebung (beide Varianten)
Nachfolgend werden die administrativen Bedingungen dargestellt, die für den sicheren Be-
trieb des Produktes erforderlich sind. Soweit keine weitere Unterscheidung für die Varianten
erfolgt, sind die Bedingungen jeweils für beide Varianten gültig.
- Der Systemverwalter ist der Signaturschlüsselinhaber. Er verfügt über die SSEE und
die zugehörige PIN. Der Systemverwalter wird durch einen Mandanten (Endanwender)
zur Signaturerzeugung von Dokumente (z.B. Rechnungen) beauftragt. Hierzu erhält er
eine entsprechende Vollmacht. Für welchen Mandanten die Signaturerzeugung erfolgt,
ist über das Pseudonym im Zertifikat ersichtlich.
- Der Systemverwalter hat sich davon zu überzeugen, dass das auf der SSEE bzw. in
der Zertifikatsdatenbank gespeicherte Root-Zertifikat der BNetzA authentisch und inte-
ger ist (z.B. durch Vergleich mit Angaben aus dem Bundesanzeiger [BANZ]), da dieses
den Vertrauensanker innerhalb der Zertifikatskette darstellt.
- Für den Fall, dass das Root-Zertifikat in der Zertifikatsdatenbank hinterlegt wird, muss
dafür Sorge getragen werden, dass die Zertifikatsdatenbank nur im 4-AP (4-
Augenprinzip) geändert werden kann.
HE_multisign_Enterprise_4-1 Seite 20 von 26
Bonn, 25. August 2010
Amtsblatt der Bundesnetzagentur
für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen
16 2010 – Mitteilungen, Qualifizierte elektronische Signatur, 2815
Teil A, Mitteilungen der Bundesnetzagentur –
Herstellererklärung – multisign Enterprise, Version 4.1
- Ein Austauschen von SSEE oder Chipkartenlesern muss eindeutig erkennbar sein (z.B.
durch Versiegelung).
- Der Systemverwalter muss sich ebenfalls davon überzeugen, dass die verwendeten
Chipkartenleser weder böswillig manipuliert noch in irgendeiner anderen Form verän-
dert wurden, um Daten auszuforschen (PIN) oder zu verändern.
- Sicherheitstechnische Veränderungen müssen erkennbar sein. Der Systemverwalter ist
dazu angehalten, in regelmäßigen Abständen die Integrität des Produktes zu überprü-
fen.
Variante 1 (Server-Plattform): Bei dieser Variante kann man während des
Betriebs die Integrität der serverseitigen Bestandteile mittels des Unix Kom-
mandos diff verifizieren. Damit wird gewährleistet, dass das im Betrieb be-
findliche Produkt authentisch ist. Hierzu wird der auf der Auslieferungs-CD
befindliche Signaturserver herangezogen und mit dem im Einsatz befindli-
chen Produkt mit dem Unix Kommando diff verglichen, welches die Pfadan-
gabe der beiden Programme als Parameter entgegennimmt:
diff Pfadangabe_auf_Rechner Pfadangabe_auf_Original_CD
Variante 2 (Signaturbox): Das Gehäuse der Signaturbox muss so versiegelt
werden, dass ein Austausch der CF-Karte, auf der sich die serverseitigen
Bestandteile befinden, erkannt werden kann. Der Systemverwalter ist dazu
angehalten, in regelmäßigen Abständen die Integrität der Siegel zu überprü-
fen.
Die externe USB-Schnittstelle, über die neben dem Einlesen von Konfigurati-
onswerten auch ein Einspielen von Daten auf die CF-Karte (Flashen) möglich
ist, wird mit Hilfe eines Prüftools (Signaturprüfung) abgesichert, das vom
Hersteller vor der Auslieferung der Signaturbox auf der CF-Karte installiert
wurde. Hierbei können ausschließlich vom Hersteller elektronisch signierte
Produkt-Versionen über die externe USB-Schnittstelle eingespielt werden
(Wahrung der Integrität und Authentizität).
- Es muss ein vertrauenswürdiger Umgang mit SSEE und PIN erfolgen. Dies umfasst die
vertrauenswürdige Eingabe der PIN. Der Benutzer (d.h. der bevollmächtigte System-
administrator) hat dafür Sorge zu tragen, dass die Eingabe der PIN weder beobachtet
wird noch dass die PIN anderen Personen bekannt gemacht wird.
- Das Rechnersystem, auf dem das Produkt im Rahmen von Variante 1 (Server-
Plattform) betrieben wird, muss gegen eine unberechtigte Benutzung gesichert sein.
Der Systemverwalter muss sich davon überzeugen, dass jede auf dem Rechner instal-
lierte Software weder böswillig manipuliert noch in irgendeiner anderen Form verändert
wurde, um Daten (insbesondere die PIN) auszuforschen, zu verändern oder die Funkti-
on anderer Programme unzulässig zu verändern.
- Im Rahmen der Nutzung des File-Interface muss die Integrität und Authentizität
a) der zu signierenden Dokumente (Kontext: Signaturerzeugung), die vom
Mandanten an den Signaturserver übergeben werden, und
b) des Verifikationsergebnisses (Kontext: Signaturprüfung), welches vom
Signaturserver an den Mandanten übermittelt wird,
über eine entsprechende Einsatzumgebung (z.B. Betriebsystemmechanis-
men zur Zugriffskontrolle sowie eine Übertragungssicherung für die Zufüh-
rung der Dokumente zum Signaturserver) gewährleistet werden.
- Im Falle der Verwendung des Network-Interface wird die Gewährleistung der Integrität
und Authentizität bei der Übermittlung der zu signierenden Daten sowie Verifikationser-
HE_multisign_Enterprise_4-1 Seite 21 von 26
Bonn, 25. August 2010
Amtsblatt der Bundesnetzagentur
für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen
2816 – Mitteilungen, Qualifizierte elektronische Signatur, 16 2010
Teil A, Mitteilungen der Bundesnetzagentur –
Herstellererklärung – multisign Enterprise, Version 4.1
gebnisse durch das Produkt via SSL realisiert. Hierbei wird die Geheimhaltung des für
den SSL-Handshake erforderlichen privaten Schlüssels des Signaturservers durch ei-
nen physikalischen Zugangsschutz (verriegelter Elektroschrank) gewährleistet.
- Der Systemverwalter muss für die Nutzung des Network-Interface ein gültiges SSL-
Server-Zertifikat im Signaturserver einbringen. Wie das Zertifikat erzeugt oder wo es
beantragt wird, stimmt der Mandant mit dem Signaturservice-Provider ab.
- In Batchsignatur-Szenarien muss im Hauptzertifikat zusätzlich eine entsprechende Be-
schränkung (z.B. „Nur für Rechnungssignatur“) vorhanden sein, um die qualifizierte
Signaturerzeugung auf einen bestimmten Zweck zu beschränken.
- Der Systemverwalter hat regelmäßig die Uhrzeit des Rechners, auf welchem der Signa-
turserver betrieben wird, zu überwachen.
- Der Systemverwalter ist für die Verwaltung der Benutzeraccounts (inklusive Passwort-
verwaltung) am File-Interface verantwortlich. In diesem Zusammenhang hat der Sys-
temverwalter dafür Sorge zu tragen, dass der Umgang mit den Benutzerpasswörtern
vertraulich erfolgt. Bei Verwendung des File-Interface muss jeder Benutzer ein eigenes
Eingangs- und Ausgangsverzeichnis besitzen, auf welches nur der jeweilige Nutzer
zugriffsberechtigt ist. Je nach Art der Realisierung der Datenübermittlung am File-
Interface (SMB, FTP, HTTP) muss der Anwender als Nutzer des Dienstes eingerichtet
und mit entsprechenden Zugriffsrechten auf das File-System ausgestattet sein.
- Ausschließlich Dokumente, die auch signiert werden sollen, dürfen dem Signaturserver
durch den Endanwender zugeführt werden.
- Bei Verwendung von PDF-Prüfberichten ist es für Variante 1 (Server-Plattform) mög-
lich, ein vom Systemverwalter hinterlegtes Logo in den Prüfbericht einzubinden. Zu die-
sem Zweck muss vom Systemverwalter ein Logo im PNG-Format mit der Dateibe-
zeichnung vr_logo.png oder vrlogo.png in demjenigen Verzeichnis abgelegt werden,
das in der LibSigG Konfigurationsdatei configmodule.ini unter dem Eintrag database
eingetragen wurde. Das korrekte Ablegen des Logos obliegt dem Systemverwalter.
- Der Systemverwalter muss sich über die Eignung und Gültigkeit der im Rahmen der
Signaturprüfung verwendeten Hashalgorithmen auf der Web-Seite der Bundesnetz-
agentur informieren und den Zeitpunkt, bis zu dem die Verwendung des jeweiligen Al-
gorithmus erlaubt ist, in der Konfiguration des Signaturservers eintragen.
5.4.2 Clientseitige Einsatzumgebung (beide Varianten)
Folgende administrative Bedingungen sind bezüglich der clientseitigen Funktionsbibliothek
erforderlich:
- Der Anwendungsentwickler, der die clientseitige Funktionsbibliothek statisch in eine
Client-Applikation einbindet, hat dem Endanwender ein Verfahren zur Integritätsprüfung
der entwickelten Applikation bereitzustellen. Im Falle der Verwendung der dynamischen
Variante der Funktionsbibliothek wird die Integritätsprüfung durchgeführt, indem die auf
der Auslieferungs-CD befindliche Client-API Funktionsbibliothek herangezogen und
durch den Endanwender mit der im Einsatz befindlichen mit dem DOS-Kommando
comp verglichen.
- Der Anwendungsentwickler hat die korrekte Nutzung des Network-Interface des Signa-
turservers in der Benutzerdokumentation der entwickelten Applikation darzulegen. Die-
se muss folgende Sicherheitshinweise enthalten:
o Der Endanwender ist darauf hinzuweisen, dass er mit den Authentisierungsda-
ten vertraulich umzugehen hat. Mit Hilfe der Authentisierungsdaten kann ein
Datentransfer zum Signaturserver und somit eine Auftragserteilung zur Signa-
turerstellung bzw. Signaturprüfung erfolgen.
HE_multisign_Enterprise_4-1 Seite 22 von 26
Bonn, 25. August 2010
Amtsblatt der Bundesnetzagentur
für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen
16 2010 – Mitteilungen, Qualifizierte elektronische Signatur, 2817
Teil A, Mitteilungen der Bundesnetzagentur –
Herstellererklärung – multisign Enterprise, Version 4.1
o Der Endanwender ist darauf hinzuweisen, dass nur folgende Signaturformate
an am Network-Interface unterstützt werden:
PKCS#1
PKCS#7
XML-DSig
PDF
o Der Endanwender ist darauf hinzuweisen, dass nur folgende Verifikationsfor-
mate am Network-Interface unterstützt werden:
PKCS#1
PKCS#7
XML-DSig
PDF
o Der Endanwender hat dafür Sorge zu tragen, dass der Client-Rechner mit ei-
nem physikalischen (z.B. Schrank) und technischen (z.B. Betriebssysteman-
meldung) Zugriffschutz versehen sein muss, so dass nur der berechtigte An-
wender Zugriff zur Client-Applikation besitzt.
o Der Endanwender ist für den Schutz des Client-Rechners vor manipulativer
Software (Viren, Trojaner) selbst verantwortlich. Hierzu gehört z.B. die Absiche-
rung des Clients durch Firewall und Virenscanner. Der Endanwender muss sich
davon überzeugen, dass jede auf dem Rechner installierte Software weder
böswillig manipuliert noch in irgendeiner anderen Form verändert wurde.
o Der Endanwender ist darauf hinzuweisen, wie er die Integrität der Applikation
überprüfen kann.
o Bezüglich der Prüfung der clientseitigen Bestandteile während des Betriebs ist
ein entsprechendes Verfahren vom Entwickler der Applikation, welche die
Client-API verwendet, zu definieren.
o Ausschließlich Dokumente und Hashwerte, die auch signiert werden sollen,
dürfen dem Signaturserver durch den Endanwender zugeführt werden.
6. Algorithmen und zugehörige Parameter
Zur Erzeugung von qualifizierten elektronischen Signaturen werden die Hashalgorithmen
RIPEMD-160 und sha2-224, sha2-256, sha2-384, sha2-512 unterstützt.
Zur Prüfung von qualifizierten elektronischen Signaturen wird zusätzlich der Hashalgo-
rithmus sha1 unterstützt.
Zur Erzeugung von qualifizierten elektronischen Signaturen wird der Kryptographiealgo-
rithmus RSA mit der Schlüssellänge 2048 unterstützt.
Zur Prüfung von qualifizierten elektronischen Signaturen werden zusätzlich die RSA-
Schlüssellängen 1024, 1280, 1536, 1728, 1976 unterstützt.
Bei der Erzeugung und Prüfung qualifizierter Signaturen wird geprüft, ob ein verwendeter
Algorithmus noch geeignet ist. In der Standardeinstellung ist jeder Algorithmus als ungültig
markiert. Für jeden als gültig zu akzeptierenden Algorithmus muss dessen Enddatum der
Gültigkeit vom Administrator in der Konfiguration angegeben werden.
HE_multisign_Enterprise_4-1 Seite 23 von 26
Bonn, 25. August 2010
Amtsblatt der Bundesnetzagentur
für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen
2818 – Mitteilungen, Qualifizierte elektronische Signatur, 16 2010
Teil A, Mitteilungen der Bundesnetzagentur –
Herstellererklärung – multisign Enterprise, Version 4.1
Die gemäß Anlage 1 Abs. I Nr. 2 SigV festgestellte Eignung für die verwendeten krypto-
graphischen Algorithmen sind gemäß den Angaben der Bundesnetzagentur in BNet-
zA_Algo_2010 7 wie folgt als geeignet eingestuft:
Gültigkeit von Hashalgorithmen zur Erzeugung und Prüfung von qualifizierten
elektronischen Signaturen:
ripemd160 = 31.12.2010
sha2-224 = 31.12.2015
sha2-256 = 31.12.2016
sha2-384 = 31.12.2016
sha2-512 = 31.12.2016
Gültigkeit von Hashalgorithmen zur Prüfung von Zertifikatssignaturen:
ripemd160-cert= 31.12.2015
sha-1-cert = 31.12.2015
sha2-224-cert = 31.12.2015
sha2-256-cert = 31.12.2016
sha2-384-cert = 31.12.2016
sha2-512-cert = 31.12.2016
Gültigkeit von Kryptographiealgorithmen zur Erzeugung und Prüfung von qualifi-
zierten elektronischen Signaturen und zur Prüfung von Zertifikatssignaturen:
rsa1728 = 31.12.2010
rsa1976 = 31.12.2016
rsa2048 = 31.12.2016
Es dürfen nur Signaturen mit Hash- und Kryptographie-Signieralgorithmen erzeugt werden,
deren Algorithmen gemäß Bundesnetzagentur als geeignet eingestuft sind.
Ausschließlich zur Signaturprüfung dürfen auch bereits abgelaufene Algorithmen Verwen-
8 9
dung finden. Diese wurden gemäß BNetzA_Algo_2008 und BNetzA_Algo_2009 wie folgt
eingestuft:
Ablaufdatum von Hashalgorithmen zur Prüfung von qualifizierten Signaturen:
sha-1 = 30.06.2008
Ablaufdatum von Kryptographiealgorithmen zur Prüfung von qualifizierten Signa-
turen und zur Prüfung von Zertifikatssignaturen:
rsa1024 = 31.03.2008
rsa1280 = 31.12.2008
rsa1536 = 31.12.2009
7
Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der Signaturverordnung: Übersicht
über geeignete Algorithmen, Bundesnetzagentur, vom 06. Januar 2010, veröffentlicht am 04. Februar 2010 im
Bundesanzeiger Nr. 19, S. 426
8
Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der Signaturverordnung: Übersicht
über geeignete Algorithmen, Bundesnetzagentur, vom 17. Dezember 2007, veröffentlicht am 05. Februar 2008 im
Bundesanzeiger Nr. 19, S. 376
9
Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der Signaturverordnung: Übersicht
über geeignete Algorithmen, Bundesnetzagentur, vom 17. November 2008, veröffentlicht am 27. Januar 2009 im
Bundesanzeiger Nr. 13, S. 346
HE_multisign_Enterprise_4-1 Seite 24 von 26
Bonn, 25. August 2010
Amtsblatt der Bundesnetzagentur
für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen
16 2010 – Mitteilungen, Qualifizierte elektronische Signatur, 2819
Teil A, Mitteilungen der Bundesnetzagentur –
Herstellererklärung – multisign Enterprise, Version 4.1
7. Gültigkeit der Herstellererklärung
Diese Erklärung ist bis auf Widerruf durch den Hersteller
secunet Security Networks AG
Kronprinzenstraße 30
45219 Essen
oder die zuständige Behörde
Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen
Canisiusstraße 21
55122 Mainz
gültig. Die Gültigkeit der Herstellererklärung ist weiter beschränkt durch die in Kapitel 6
aufgeführten Gültigkeiten der Algorithmen. Die Gültigkeit der vorliegenden Herstellererklä-
rung endet spätestens, sobald der durch die SSEE zur Signaturerstellung unterstützte Kryp-
tographiealgorithmus RSA-2048 von der Bundesnetzagentur als nicht mehr als geeignet
eingestuft wird (Stand heute: 31.12.2016). Die Gültigkeit der vorliegenden Herstellererklä-
rung endet ebenfalls spätestens dann, wenn ALLE zur Signaturerstellung unterstützten
Hashalgorithmen (RIPEMD-160, sha2-224, sha2-256, sha2-384, sha2-512) von der Bun-
desnetzagentur als nicht mehr als geeignet eingestuft wurden und somit kein geeigneter
Algorithmus zur Signaturerstellung mehr implementiert ist (Stand heute: 31.12.2016).
Der aktuelle Status der Gültigkeit der Erklärung ist bei der zuständigen Behörde (Bundes-
netzagentur, Referat Qualifizierte Elektronische Signatur – Technischer Betrieb) zu erfra-
gen.
HE_multisign_Enterprise_4-1 Seite 25 von 26
Bonn, 25. August 2010
