Herstellererklärung. Die. BDC EDV-Consulting GmbH. Gredlerstrasse 4 / 2. A-1020 Wien. dass das Produkt. BDC hotinvoice Version 4.0.

Herstellererklärung Die BDC EDV-Consulting GmbH Gredlerstrasse 4 / 2 A-1020 Wien erklärt hiermit gemäß 17 Abs. 4 Satz 2 SigG 1 in Verbindung mit 15 Abs 5 Satz 1 SigV 2, dass das Produkt BDC hotinvoice Version 4.0.0 eine Teil- Signaturanwendungskomponente ist, die es ermöglicht qualifizierte elektronische Signaturen zu erstellen und zu prüfen. Wien, den 24.01.2011 gez. DI Klaus Dillinger Geschäftsführer gez. Ing. Markus Punz Prokurist Diese Herstellererklärung in Version 1.4 besteht aus 17 Seiten einschließlich Deckblatt. 1 Gesetz über Rahmenbedingungen für elektronische Signaturen in der Fassung vom 16. Mai 2001 (BGBL. I S. 876). Geändert durch Art. 4 des Gesetzes vom 17. Juli 2009 (BGBL. I S. 2091) 2 Verordnung zur elektronischen Signatur in der Fassung vom 16. November 2001 (BGBL. I S. 3074). Geändert durch die Verordnung vom 15. November 2010 (BGBL. I S. 1542) Seite 1 von 17

Dokumentenhistorie Version Datum Autor Bemerkung 1.0 26.07.2010 Markus Punz Initialversion 1.1 17.11.2010 Markus Punz Überarbeitung entsprechend Auszug aus dem Prüfbericht zur Herstellererklärung V0.1 vom 17.11.2010 1.2 17.01.2011 Markus Punz Überarbeitung entsprechend Auszug aus dem Prüfbericht zur Herstellererklärung V0.2 vom 14.01.2011 1.3 21.01.2011 Markus Punz Überarbeitung entsprechend Auszug aus dem Prüfbericht zur Herstellererklärung V0.2 vom 21.01.2011 1.4 24.01.2011 Markus Punz Unterschrift eines Geschäftsführers ergänzt Seite 2 von 17

1 Handelsbezeichnung Die Handelsbezeichnung lautet: Auslieferung: hotinvoice 4.0.0 Download-Server von BDC (HTTPS Verbindung und Benutzerauthentifizierung erforderlich bzw. Read-only Datenträger - CD-ROM (per Post zugestellt oder persönlich übergeben) Hersteller: BDC EDV-Consulting GmbH Gredlerstrasse 4 / 2 A-1020 Wien Tel.: 01 / 219 78 46 Firmenbuchnummer: FN 162798 i 2 Lieferumfang und Versionsinformationen Nachfolgend ist der Lieferumfang, einschließlich der Versionsinformationen aufgezählt: Produktart Bezeichnung Version Übergabeform Software hotinvoice 4.0.0 Installationsfiles als Archiv (self-extracting EXE) oder auf CD Handbuch hotinvoice Desktop Handbuch 4.0.0 PDF-Datei im Archiv oder auf CD Tabelle1: Lieferumfang und Versionsinformationen hotinvoice 4.0.0 nutzt die folgenden nach SigG bestätigten Produkte, die von Dritten hergestellt werden und nicht Bestandteil dieser Erklärung sind: Produktklasse Bezeichnung Beschreibung + Registrierungsnummer der Bestätigung SSEE Kartenleser D-Trust, D-TRUST multicard (D-Trust c-card V 2.3/2.4) Chipkartenleser SCM SPR 532, Firmware Version 5.10 Für den Massensignaturbetrieb geeignete Karte basierend auf Chipkarte mit Prozessor SLE66CX322P oder SLE66CX642P, Betriebssystem CardOS V4.3B Re_Cert mit Applikation für digitale Signatur, Registrierungsnummer: T-Systems.02182.TE.11.2006 inklusive Nachtrag 1 vom 06.02.2007 und Nachtrag 2 vom 06.05.2008 BSI.02080.TE.10.2006 Kartenleser CyberJack e-com, Version 2.0 TUVIT.09363.TE.06.2002 Kartenleser CyberJack pinpad, Version 2.0 TUVIT.09362.TE.05.2002 Seite 3 von 17

Kartenleser CyberJack pinpad, Version 3.0 TUVIT.93107.TU.11.2004 Kartenleser Omnikey CardMan Trust CM3621 / CM3821, Version 6.00 BSI.02057.TE.12.2005 Tabelle 2: Zusätzliche Produkte nach SigG bestätigt Ein Secure Viewer ist nicht Bestandteil des Lieferumfangs. Die Anzeige muss gegebenenfalls im Vorfeld durch die Client-Applikation oder andere Zusatzapplikationen erfolgen. Derartige Programme sind nicht Gegenstand dieser Herstellererklärung. 3 Funktionsbeschreibung und Eigenschaften hotinvoice 4.0.0 ist Teil einer Signaturanwendungskomponente gemäß 2 Nr. 11 SigG, die zur Verifikation qualifizierter elektronischer Signaturen, Nachprüfung qualifizierter Zertifikate sowie in Verbindung mit einer sicheren Signaturerstellungseinheit 3 zur Erzeugung von qualifizierten elektronischen Signaturen verwendet werden kann. Zur Erhöhung der Signaturrate können mehrere sichere Signaturerstellungseinheiten gleichzeitig verwendet werden. Die Signaturanwendungskomponente ist für den Einsatz in einer gesicherten oder isolierten Einsatzumgebung bestimmt. Damit ist sichergestellt, dass qualifizierte Massensignaturen nur in einem abgesicherten Environment erfolgen. Für die Nutzung der oben genannten Funktionalität stehen definierte Schnittstellen zur Verfügung, die von Applikationen integriert werden müssen. Ein häufiger Anwendungsbereich von hotinvoice 4.0.0 ist beispielsweise die elektronische Rechnungslegung, wobei der Einsatzbereich keinesfalls ausschließlich darauf beschränkt ist. Mittels organisatorischer Maßnahmen muss gewährleistet werden, dass nur Dokumente signiert werden, die dem vorgesehenen Zweck entsprechen (zb: elektronische Rechnungen) hotinvoice 4.0.0 enthält diesbezüglich keine Einschränkungen und nimmt auch keine etwaigen Prüfungen vor. hotinvoice 4.0.0 gliedert sich in funktionale Module, die mittels eines Lizenzcodes aktiviert/deaktiviert werden. Folgende Module stehen zur Verfügung: Signaturformat PDF: Ermöglicht die Erstellung von Signaturen im PDF-Signaturformat. Signaturformat XMLDSIG: Ermöglicht die Erstellung von XMLDSIG-Signaturen. Signaturformat SMIME: Ermöglicht die Erstellung von SMIME-Signaturen. Schnittstelle Mail: Ermöglicht die Anlieferung zu signierender Daten per SMTP-Protokoll. Nach Signatur der Daten werden diese entsprechend dem SMTP-Kommando weiter verarbeitet. Im Normalfall handelt es sich hierbei um die Zustellung der signieren Daten per E-Mail an den Empfänger. Schnittstelle File: Ermöglicht die Anlieferung zu signierender Daten in Form von Dateien. Die Dateien müssen dazu in ein definiertes Verzeichnis (=Quellverzeichnis) gestellt werden. Nach Anbringung der Signatur werden die signierten Dateien in konfigurierbare Ausgangsverzeichnisse kopiert. 3 Die Verwendung sicherer Signaturerstellungseinheiten nach 17 Abs. 1 Signaturgesetz, bzw. 15 Abs. 1 Signaturverordnung wird vorausgesetzt. Diese gehören nicht zum Lieferumfang des Produkts und sind daher auch nicht Gegenstand dieser Erklärung. Seite 4 von 17

Schnittstelle Web-Service: Ermöglicht die Anlieferung der zu signierenden Daten per Web-Service Schnittstelle. Die signierten Daten werden in der Antwortnachricht an das aufrufende System übergeben. Mandantenfähigkeit: Ermöglicht die Verwendung unterschiedlicher Signaturschlüssel in Abhängigkeit des jeweiligen Mandaten. Signaturverifikation: Automatische Signaturverifikation für signierte Daten. Für die Signaturverifikation werden ebenfalls die gleichen Signaturformate unterstützt wie für die Signaturerstellung also PDF, XMLDSIG, SMIME. Ebenso werden die gleichen Schnittstellen unterstützt Mail, File, Web-Service. Da hotinvoice 4.0.0 die Massensignatur von elektronischen Dokumenten in Verbindung mit der D-Trust multicard unterstützt, ist der typische Anwendungsbereich die elektronische Rechnungslegung. Das Konzept besteht darin, Anwendungen (zb: ERP-Systemen) geeignete Schnittstellen für die Erstellung / Verifikation von qualifizierten Signaturen zur Verfügung zu stellen, ohne dass die Anwendungen selbst ein Evaluierungs- u. Bestätigungsverfahren durchlaufen oder dass für diese Anwendungen eine Herstellererklärung gemäß 17 Abs. 4 Satz 2 SigG abgegeben werden müssen. Dieses Ziel wird durch die Kapselung sämtlicher sicherheitsspezifischer und sicherheitsrelevanter Funktionen erreicht, die nur über wohldefinierte Schnittstellen zugänglich sind. 3.1 > Schnittstellen Hinsichtlich der Schnittstellen sind grundsätzlich folgende beiden Aspekte zu beachten: Sicherstellung der Integrität der übertragenen Daten Sicherstellung der Authentizität des Aufrufers (also der Client-Applikation) Für die unterschiedlichen Schnittstellen wird dies folgendermaßen gewährleistet: 3.1.1 > Mail Integrität der übertragenen Daten: Sofern dies ohnehin nicht aufgrund der Einsatzumgebung gewährleistet ist, kann in der hotinvoice-konfiguration ebenfalls der SSL-Modus aktiviert werden. Die Kommunikation zwischen Aufrufer und hotinvoice 4.0.0 findet in diesem Fall ausschließlich SSL-verschlüsselt statt. Authentizität des Aufrufers: In der hotinvoice-konfiguration muss die Authentifizierung aktiviert werden. Der Aufrufer muss sich somit mit dem korrekten Usernamen / Passwort authentifizieren, um mit hotinvoice 4.0.0 zu kommunizieren. 3.1.2 > Web-Service Integrität der übertragenen Daten: Wie auch schon bei der SMTP-Schnittstelle, kann auch bei der Web- Service Schnittstelle der SSL-Modus aktiviert werden. Die Kommunikation zwischen Aufrufer und hotinvoice 4.0.0 findet in diesem Fall ausschließlich SSL-verschlüsselt statt. Authentizität des Aufrufers: In der hotinvoice-konfiguration muss die Authentifizierung aktiviert werden. Der Aufrufer muss sich somit mit dem korrekten Usernamen / Passwort authentifizieren, um mit hotinvoice 4.0.0 zu kommunizieren. Seite 5 von 17

3.1.3 > File Für beide Aspekte (Integrität der Daten und Authentizität des Aufrufers) gilt: hotinvoice 4.0.0 stellt hierfür keine eigenen Mechanismen zur Verfügung. Stattdessen müssen diese mittels geeigneter organisatorischer Maßnahmen (zb: Absicherung der Einsatzumgebung) bzw. auch IT-Security Maßnahmen (zb: Netzwerkverschlüsselung, Firewalls) gewährleistet werden. 3.1.4 > Chipkartenleser Über die Verbindung zum Chipkartenleser sendet hotinvoice 4.0.0 zu signierende Daten an die Signaturkarten und empfängt über diese Schnittstelle die Signaturen, die von den Signaturkarten erstellt wurden. Die Absicherung der Schnittstelle wird mittels geeigneter organisatorischer Maßnahmen der Einsatzumgebung gewährleistet. 3.1.5 > Grafische Bedienungsoberfläche hotinvoice 4.0.0 nutzt eine grafische Oberfläche (GUI) als Schnittstelle zum Benutzer. Die Verwendung dieses Programmteils ist dem Signaturschlüssel-Inhaber vorbehalten. Die Absicherung erfolgt mittels geeigneter organisatorischer Maßnahmen der Einsatzumgebung. 3.1.6 > Schnittstellen zur Zertifikatsprüfung (CRL / OCSP): Sowohl Sperrlisten (CRLs) als auch OCSP-Responses sind mit einer elektronischen Signatur des Ausstellers versehen. Im Zuge von Zertifikatsprüfungen prüft hotinvoice 4.0.0 die Signaturen der abgerufenen CRLs bzw. der eingelangten OCSP-Responses. Nur wenn die Aussteller-Signatur korrekt ist, wird die Zertifikatsprüfung durchgeführt. Die Korrektheit der Aussteller-Signatur gewährleitet sowohl die Integrität als auch die Authentizität der Daten. 3.2 > Signaturerstellung Die Teil-Signaturanwendungskomponente erfüllt die Anforderungen nach 17 Abs. 2 Signaturgesetz und 15 Abs. 2 und Abs. 4 Signaturverordnung. Die Signaturerstellung wird durch den Inhaber der massensignaturfähigen Signaturkarte in der grafischen Bedienungsoberfläche von hotinvoice 4.0.0 gestartet. Dazu muss der Signator die zulässige Anzahl an Signaturen eingeben, für die die Signaturerstellungseinheit freigeschaltet wird. In der Folge wird der Signator zur Eingabe der Identifikationsdaten (PIN) aufgefordert. Zusätzlich wird dem Signator ein Warnhinweis angezeigt, dass in der Folge Signaturen erstellt werden, für die er rechtlich verantwortlich ist. Der Signator muss dabei sicher gehen können, dass nur Dokumente signiert werden, die er vorher explizit geprüft hat (zb: durch Anzeige in einem Secure Viewer) oder von denen er weiß, dass diese korrekt sind, da sie aus Vorgängerprozessen stammen, deren Integrität gewährleistet ist. Dies muss mit organisatorischen Maßnahmen der Einsatzumgebung und gegebenenfalls IT-Security Maßnahmen gewährleistet werden. Diese sind nicht Gegenstand dieser Herstellererklärung. Im Zuge der Signaturerstellung stellt hotinvoice 4.0.0 sicher, dass nur die eingegebene Anzahl an Signaturoperationen mit dem spezifischen Signaturschlüssel vorgenommen wird. Im Anschluss wird die Signaturerstellungseinheit elektrisch deaktiviert. Ohne neuerliche PIN-Verifikation und Freischaltung für eine bestimmte Signaturanzahl sind keine weiteren Signaturen möglich. Die Signaturerstellung eines einzelnen Dokuments wird von den aufrufenden Applikationen angestoßen, indem zu signierende Daten über die definierten Schnittstellen (Mail, Web-Service, File) an hotinvoice 4.0.0 übergeben werden. In der Folge führt hotinvoice 4.0.0 die Authentifizierung des Aufrufers durch. Bei positiver Authentifizierung prüft hotinvoice 4.0.0 im nächsten Schritt den Signaturzähler der Signaturkarte, Seite 6 von 17

ob noch Signaturtransaktionen durchgeführt werden können. Im Fehlerfall wird mit einer Fehlermeldung abgebrochen. Bei positiver Prüfung des Signaturzählers führt hotinvoice 4.0.0 die Hashwertberechnung durch es wird immer SHA-256 verwendet. Im Anschluss sendet hotinvoice 4.0.0 den Hashwert an den Kartenleser, der ihn an die Signaturkarte weitergibt. Die Signaturkarte berechnet schließlich die RSA- Signatur, die über den Kartenleser an hotinvoice 4.0.0 zurückgeliefert und dort unter Zuhilfenahme des öffentlichen Signaturschüssels verifiziert (kryptografische Signaturverifikation) wird. Damit wird sichergestellt, dass die Signatur korrekt erzeugt wurde. Im Anschluss wird der Signaturzähler dekrementiert. Die signierten Daten werden danach je nach Schnittstelle weiterverarbeitet. Im Falle der Mail-Schnittstelle handelt es sich um eine Zustellung der signierten Daten per E-Mail an die E-Mail Empfänger-Adressen. Im Falle der Web-Service Schnittstelle werden die signierten Daten in der Antwortnachricht an das aufrufende System zurückgeliefert. Im Falle der File-Schnittstelle werden die signierten Dateien in ein konfiguriertes Ausgangsverzeichnis kopiert. hotinvoice 4.0.0 verarbeitet ebenfalls Daten, die bereits mit einer elektronischen Signatur versehen sind. In diesem Fall wird durch die Signaturerstellung eine weitere Signatur angebracht, die sich über alle Daten einschließlich aller bisherigen Signaturen erstreckt (= Übersignatur). hotinvoice 4.0.0 selbst bietet keine Möglichkeit zur Anzeige von Daten. Die Weitergabe von Daten über die genannten Schnittstellen (File, SMTP, Web-Service) an hotinvoice 4.0.0 hat eine Signaturerstellung zur Folge. Die Anzeige muss gegebenenfalls im Vorfeld durch die aufrufende Applikation oder andere Zusatzapplikationen erfolgen. Derartige Programme sind nicht Gegenstand dieser Herstellererklärung. Die Anbringung von Zeitstempeln wird von hotinvoice 4.0.0 nicht unterstützt. 3.3 > Signaturverifikation Die Teil-Signaturanwendungskomponente erfüllt die Anforderungen nach 17 Abs. 2 Satz 2 und Satz 4 Signaturgesetz sowie 15 Abs. 2 Nr. 2 Signaturverordnung hinsichtlich der Verifikation qualifizierter elektronischer Signaturen. Die Signaturverifikation wird von den aufrufenden Applikationen angestoßen, indem signierte Daten über die definierten Schnittstellen (Mail, Web-Service, File) an hotinvoice 4.0.0 übergeben werden. Im Falle der Mail-Schnittstelle prüft hotinvoice 4.0.0 konfigurierbare E-Mail Konten auf neu eingelangte E- Mails, die gegebenenfalls abgerufen werden. Sofern E-Mails signierte Daten enthalten, werden diese einer Signaturverifikation unterzogen. Je nach Status der Signaturverifikation, wird das Ergebnis im Betreff der entsprechenden Nachricht vermerkt. Es gibt 4 verschiedene Signatur-Stati: << Betreff der Original-Nachricht >> + [ BDC hotmail Status: GÜLIG DD-MM_YY HH:MM:SS.sss ] [ BDC hotmail Status: UNGÜLTIG OK DD-MM_YY HH:MM:SS.sss ] [ BDC hotmail Status: UNBEKANNT OK DD-MM_YY HH:MM:SS.sss ] [ BDC hotmail Status: NICHT SIGNIERT OK DD-MM_YY HH:MM:SS.sss ] Der Status GÜLTIG wird nur dann gesetzt, wenn alle Signaturen der im E-Mail enthaltenen Dokumente gültig sind also wenn ein E-Mail beispielsweise 2 Dokumente enthält und jedes Dokument wiederum 2 Seite 7 von 17

Signaturen enthält, dann müssen insgesamt alle 4 Signaturen gültig sein, damit der Status GÜLTIG gesetzt wird. Sobald eine Signatur ungültig ist, gilt das E-Mail als ungültig signiert. An das E-Mail wird ein Prüfbericht als zusätzliches E-Mail Attachment angehängt. Darin befinden sich die Details zur Signaturverifikation. Bezüglich Übersignaturen siehe 3.3.1 >Prüfungen im Detail. Bei der File-Schnittstelle werden konfigurierbare Quellverzeichnisse überwacht und auf signierte Dokumente überprüft. Diese Dateien werden automatisch geladen und einer Signaturverifikation unterzogen. In Abhängigkeit des Prüfergebnisses werden diese auf unterschiedliche Ausgangsverzeichnisse verteilt: Gültig signierte Dokumente Ungültig signierte Dokumente Gültigkeit der Signaturen unbekannt Enthalten die Dokumente mehrere Signaturen, werden alle Signaturen überprüft. Ein Dokument wird nur dann als gültig erachtet, wenn alle enthaltenen Signaturen gültig sind. Sobald eine Signatur ungültig ist, gilt das Dokument als ungültig signiert. In das jeweilige Verzeichnis wird ebenfalls der Prüfbericht mit den Details zur Signaturverifikation gespeichert. Die Verbindung zwischen dem geprüften Dokumente und dem Prüfbericht wird über den Dateinamen hergestellt. Bezüglich Übersignaturen siehe 3.3.1 >Prüfungen im Detail. Signierte Dokumente, die über die Web-Service Schnittstelle übergeben werden, werden einer Signaturverifikation unterzogen. Das Ergebnis wird in der Antwort (Response) zurückgeliefert. Sofern sich im Dokument mehrere Signaturen befinden, wird je Signatur der Status der Signaturverifikation zurückgeliefert. Weiters wird ebenfalls der Prüfbericht mit den Details zur Signaturverifikation zurückgeliefert. Bezüglich Übersignaturen siehe 3.3.1 >Prüfungen im Detail. 3.3.1 > Prüfungen im Detail Korrektheit der Signatur Die signierten Daten werden auf kryptografische Korrektheit geprüft. Dazu wird mithilfe des öffentlichen RSA-Signaturschüssels aus der Signatur der Hashwert (SHA-256) berechnet. Aus den Daten wird der erwartete Hashwert (ebenfalls SHA-256) berechnet. Der Hashwert aus der Signatur wird mit dem erwarteten Hashwert verglichen. Sind die beiden Hashwerte ident, dann ist die Signatur kryptografisch korrekt. Sofern ein Dokument mehrere Signaturen enthält, werden Übersignaturen (=Signaturen, die sich über zuvor erstellte Signaturen erstrecken) und parallele Signaturen (= Signaturen die sich nur auf die reinen Daten beziehen) nicht unterschieden. Im Falle von Übersignaturen werden bereits vorhandene Signaturen als Teil der Daten betrachtet, die in die kryptografische Signaturprüfung eingehen. Es erfolgt keine Kennzeichnung, dass es sich um eine Übersignatur handelt. Korrektheit der Zertifikatskette Seite 8 von 17

In diesem Zusammenhang wird die Zertifkatskette vom Signaturzertifikat (das Teil der signierten Daten ist) bis zu einem Wurzelzertifikat (Root-Zertifikat) aufgelöst. hotinvoice 4.0.0 unterstützt die Protokolle HTTP und LDAP um Zertifikate zu laden, die für die Auflösung der Zertifikatskette benötigt werden. Das Wurzelzertifikat ist in der Konfiguration von hotinvoice 4.0.0 hinterlegt und dient somit als vertrauenswürdiger Anker. Konnte die Zertifikatskette erfolgreich aufgelöst werden, werden die Zertifikatssignaturen überprüft und die Gültigkeit nach dem Kettenmodell verifiziert. Für die Signaturverifikation wird ausschließlich das Signaturzertifikat herangezogen. Eventuelle Attributzertifikate bleiben gänzlich unberücksichtigt. In dieser Hinsicht findet keine Verifikation, Verarbeitung oder Auswertung statt. Zertifikatsstatus In diesem Zusammenhang wird geprüft, ob ein Zertifikat der Zertifikatskette widerrufen / gesperrt wurde. Nur wenn alle Prüfungen positiv verlaufen, also die Signatur korrekt ist die Zertifikatskette korrekt ist und keines der Zertifikate in einer Sperrliste enthalten ist wird die Signatur als gültig betrachtet. Die Ergebnisse aller Prüfschritte werden im zugehörigen Prüfbericht eingetragen. Eventuelle Zeitstempel werden bei der Signaturverifikation ignoriert. 3.3.2 > Schwach werdende Algorithmen und Zeitstempel Das Produkt hotinvoice 4.0.0 erfüllt die Anforderungen an schwach werdende Algorithmen und qualifizierte Zeitstempel wie folgt: Anforderung Erfüllung und Verhalten der Software hotinvoice 4.0.0 a) Abgelaufene Algorithmen: Sofern die Signaturen einen Signaturerstellungszeitpunkt beinhalten, prüft hotinvoice 4.0.0 die Signaturen immer zu diesem Zeitpunkt. Wenn kein Signaturzeitpunkt enthalten ist, verwendet hotinvoice 4.0.0 die aktuelle Systemzeit als Signaturerstellungszeitpunkt. Sind zu diesem Zeitpunkt Algorithmen gemäß Algorithmenkatalog als schwach eingestuft, wird dies im Prüfbericht mittels eines definierten Hinweises angezeigt. Im Detail: Szenario 1: Die Signatur wurde mit einem Algorithmus erstellt, der zum Zeitpunkt der Signaturerstellung bereits abgelaufen war: hotinvoice 4.0.0 führt die Signaturverifikation durch, wie im Abschnitt 3.3.1 >Prüfungen im Detail beschrieben. Zusätzlich zu den Prüfergebnissen wird im Prüfbericht vermerkt, dass zum Signaturerstellungszeitpunkt der verwendete Algorithmus abgelaufen war und es sich daher um eine ungültige qualifizierte elektronische Signatur handelt. Szenario 2: Die Signatur wurde mit einem Algorithmus erstellt, der zum Zeitpunkt der Signaturerstellung gültig war, aber zum Seite 9 von 17

Zeitpunkt der Verifikation abgelaufen ist: hotinvoice 4.0.0 führt die Signaturverifikation durch, wie im Abschnitt 3.3.1 >Prüfungen im Detail beschrieben. Zusätzlich zu den Prüfergebnissen wird im Prüfbericht vermerkt, dass der verwendete Algorithmus zwar zum Zeitpunkt der Signaturerstellung gültig war, zum aktuellen Zeitpunkt (= Zeitpunkt der Signaturverifikation) allerdings nicht mehr gültig ist. Der Benutzer wird darauf hingewiesen, dass eine verminderte Beweiskraft der qualifizierten elektronischen Signatur gegeben ist. Szenario 3: Die Signatur wurde mit einem Algorithmus erstellt, der zum Zeitpunkt der Signaturerstellung und zum Zeitpunkt der Signaturverifikation gültig ist: hotinvoice 4.0.0 führt die Signaturverifikation durch, wie im Abschnitt 3.3.1 >Prüfungen im Detail beschrieben. Zusätzlich zu den Prüfergebnissen wird im Prüfbericht vermerkt, dass die verwendeten Algorithmen sowohl zum Zeitpunkt der Signaturerstellung, als auch zum Zeitpunkt der Signaturprüfung (= aktueller Zeitpunkt) gültig sind. b) Nicht implementierte Algorithmen: Signaturen die mit unbekannten Algorithmen erstellt wurden, werden von hotinvoice 4.0.0 grundsätzlich als unbekannt eingestuft. Der zugehörige Prüfbericht enthält die Information, dass die Gültigkeit der Signatur nicht geprüft werden konnte, weil ein zugehöriger Algorithmus unbekannt ist. c) Qualifizierte Zeitstempel: hotinvoice 4.0.0 bringt im Rahmen der Signaturerstellung keine qualifizierten Zeitstempel an. Bei der Signaturverifikation erfolgt keine Interpretation von qualifizierten Zeitstempeln. Seite 10 von 17

4 Erfüllung des Signaturgesetzes und der Signaturverordnung hotinvoice 4.0.0 erfüllt die nachfolgenden Anforderungen des SigG: ZITAT 17 ABS. 2 SATZ 1 Für die Darstellung zu signierender Daten sind Signaturanwendungskomponenten erforderlich, die die Erzeugung einer qualifizierten elektronischen Signatur vorher eindeutig anzeigen und feststellen lassen, auf welche Daten sich die Signatur bezieht. Der Signator erkennt die Erstellung einer qualifizierten Signatur dadurch, dass gemeinsam mit der Eingabe der Identifikationsdaten ebenfalls eine Warnmeldung angezeigt wird, dass in der Folge Signaturen erstellt werden, für die er rechtlich verantwortlich ist. Alle unterstützten Signaturformate (PDF, XML, SMIME) sehen vor, dass die erstellte Signatur in die Daten (bzw. das Dokument) eingebettet wird. Die Signatur ist somit Bestandteil der signierten Daten. Der Bezug ist somit eindeutig hergestellt. ZITAT 17 ABS. 2 SATZ 2 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. Nr. 1: Ein essentieller Bestandteil der Signatur ist der Hashwert. Im Zuge der Signaturverifikation wird dieser Hashwert aus der Signatur mit dem Hashwert des Prüfobjekts verglichen. Damit ist die Verbindung zwischen Signatur und Daten hergestellt. Nr. 2: Dies wird durch den Hashwert-Vergleich aus Nr. 1 gewährleistet. Hierbei handelt es sich um mathematische Algorithmen, die Prüfsummen (= Hashwerte) über Daten berechnen. Sollten die Daten verändert worden sein, ergibt dies einen anderen Hashwert, der nicht mit dem Hashwert aus der Signatur übereinstimmt. Damit kann zweifelsfrei festgestellt werden, ob die Daten verändert wurden oder nicht. Nr. 3: Der Signaturschlüssel-Inhaber wird aus den Zertifikatsdaten ermittelt. Hierbei handelt es sich um folgende Daten aus dem Signatur-Zertifikat: - Seriennummer - Aussteller - Antragsteller Diese Informationen identifizieren das Zertifikat eindeutig und werden in den Prüfbericht aufgenommen. Nr. 4: Da die Signaturverifikation automatisch erfolgt, gibt es keine Möglichkeit aus hotinvoice 4.0.0 heraus die Inhalte der Zertifikate ausgenommen die unter Nr. 3 genannten Zertifikatsdaten einzusehen. Seite 11 von 17

Attributzertifikate werden von hotinvoice 4.0.0 gänzlich ignoriert. Für die Anzeige der Zertifikatsdaten kann der Signator Applikationen von anderen Herstellern verwenden (zb: Acrobat Reader für PDF-Dokumente). Derartige Produkte sind nicht im Lieferumfang von hotinvoice 4.0.0 beinhaltet. Nr. 5: Bei der Verifikation von qualifizierten elektronischen Signaturen wird die gesamte Zertifikatskette bis zum Wurzelzertifikat geprüft. Durch die Prüfung von Widerrufslisten (CRL / OCSP) ist sichergestellt, dass die nachgeprüften Zertifikate zum angegebenen Zeitpunkt nicht gesperrt waren. Das Prüfergebnis wird im Prüfbericht festgehalten. Details zur Signaturverifikation befinden sich im Kapitel 3.3 >. ZITAT 17 ABS. 2 SATZ 3 Signaturanwendungskomponenten müssen nach Bedarf auch den Inhalt der zu signierenden oder signierten Daten hinreichend erkennen lassen. hotinvoice 4.0.0 ist eine Teil-Signaturanwendungskomponente. Das Produkt selbst bietet keine Möglichkeit zur Anzeige von Daten. Die Anzeige muss gegebenenfalls durch die aufrufende Applikation oder andere Zusatzapplikationen erfolgen. Derartige Programme sind nicht Gegenstand dieser Herstellererklärung. hotinvoice 4.0.0 erfüllt die nachfolgenden Anforderungen der SigV: ZITAT 15 ABS. 2 NR. 1 A 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 Identifikationsdaten werden nicht preisgegeben und sind nur auf der jeweiligen sicheren Signaturerstellungseinheit gespeichert. Für die sichere PIN-Eingabe werden Chipkarten-Terminals mit Pinpad unterstützt, die für diesen Zweck nach SigG/SigV bestätigt sind. Eine Preisgabe der Identifikationsdaten kann hierdurch ausgeschlossen werden. ZITAT 15 ABS. 2 NR. 1 B Signaturanwendungskomponenten nach 17 Abs. 2 des Signaturgesetzes müssen gewährleisten, dass 1. bei der Erzeugung einer qualifizierten elektronischen Signatur b) eine Signatur nur durch die berechtigt signierende Person erfolgt Die Erzeugung von Signaturen erfolgt nur durch die berechtigt signierende Person, da Signaturvorgänge explizit durch den Signaturschlüssel-Inhaber freigegeben werden. Erst nach erfolgreicher Eingabe der Identifikationsdaten wird der Signaturerstellungsprozess gestartet. Der Signaturkarteninhaber darf die PIN seiner Signaturkarte nicht an Dritte weitergeben und muss diese geheim halten. ZITAT 15 ABS. 2 NR. 1 C Signaturanwendungskomponenten nach 17 Abs. 2 des Signaturgesetzes müssen gewährleisten, dass 1. bei der Erzeugung einer qualifizierten elektronischen Signatur c) die Erzeugung einer Signatur vorher eindeutig angezeigt wird Seite 12 von 17

Der Signator erkennt die Erstellung einer qualifizierten Signatur dadurch, dass gemeinsam mit der Eingabe der Identifikationsdaten ebenfalls eine Warnmeldung angezeigt wird, dass in der Folge Signaturen erstellt werden, für die er rechtlich verantwortlich ist. ZITAT 15 ABS. 4 Sicherheitstechnische Veränderungen an Produkten für qualifizierte elektronische Signaturen nach den Absätzen 1 bis 3 müssen für den Nutzer erkennbar werden. Die hotinvoice 4.0.0 zugrunde liegende Software ist digital signiert ( Code Signing ). Vor der Installation müssen die verantwortlichen Personen die Software dahingehend überprüfen, ob sie unverändert gegenüber dem Auslieferungszustand ist. Dazu muss der separat gelieferte Hashwert mit dem tatsächlichen Hashwert der Software verglichen werden. Darüber hinaus kann der Nutzer vor jedem Systemstart die Integrität sicherheitskritischer Programmteile prüfen und damit Veränderungen an Signaturanwendungskomponenten erkennen. ZITAT 15 ABS. 2 NR. 2A Signaturanwendungskomponenten nach 17 Abs. 2 des Signaturgesetzes müssen gewährleisten, dass 2. bei der Prüfung einer qualifizierten elektronischen Signatur a) die Korrektheit der Signatur zuverlässig geprüft und zutreffend angezeigt wird und Die Signaturverifikation besteht aus 2 Schritten: Prüfung der Korrektheit der Signatur durch: o Hashwert -Berechnung und Verifikation Prüfung der Korrektheit der Zertifikatskette durch: o o Prüfung der Zertifikatskette bis zu einem vertrauenswürdigen Wurzelzertifikat und Abfrage der Sperrlisten Details sind dem Kapitel 3.3.1 >zu entnehmen. Die Anzeige erfolgt derart, dass das Ergebnis der Signaturprüfung im Prüfbericht festgehalten wird. Je nach Gültigkeit der verwendeten Algorithmen gibt es unterschiedliche Szenarien - diese sind im Abschnitt 3.3.2 > beschrieben. ZITAT 15 ABS. 2 NR. 2B Signaturanwendungskomponenten nach 17 Abs. 2 des Signaturgesetzes müssen gewährleisten, dass 2. bei der Prüfung einer qualifizierten elektronischen Signatur b) eindeutig erkennbar wird, ob die nachgeprüften qualifizierten Zertifikate im jeweiligen Zertifikatsverzeichnis zum angegebenen Zeitpunkt vorhanden und nicht gesperrt waren. Bei der Verifikation von qualifizierten elektronischen Signaturen wird die gesamte Zertifikatskette bis zum Wurzelzertifikat geprüft. Durch die Prüfung von Widerrufslisten (CRL / OCSP) ist sichergestellt, dass die nachgeprüften Zertifikate zum angegebenen Zeitpunkt nicht gesperrt waren. Seite 13 von 17

5 Maßnahmen in der Einsatzumgebung 5.1 > Einrichtung der IT-Komponenten Das Produkt hotinvoice 4.0.0 darf ausschließlich innerhalb der in der Folge beschriebenen Hard- und Softwareausstattung und Konfiguration eingesetzt werden: Computer mit unterstütztem Betriebssystem und folgenden Hardware-Mindestanforderungen Kartenlesegeräte (siehe 2 Lieferumfang und Versionsinformationen Tabelle 2 - Kartenleser) Sichere Signaturerstellungseinheiten (siehe 2 Lieferumfang und Versionsinformationen Tabelle 2 - SSEE) Hardware-Mindestanforderungen Intel Pentium III/AMD K6 1000 MHz 512 MB RAM 100 MB freier Festplattenspeicher mindestens 256 Farben Unterstützte Betriebssysteme Windows XP / 2003 Windows VISTA Windows 7 Zusätzliche Software Für den Zugriff auf die Signaturerstellungseinheiten ist ein PKCS#11 Treiber erforderlich. Es ist jener Treiber zu verwenden, der von D-Trust empfohlen wird. 5.2 > Anbindung an ein Netzwerk Das Computersystem, auf dem hotinvoice 4.0.0 installiert ist, darf nicht direkt mit potentiell unsicheren Netzen (z.b. Internet) verbunden sein. Geeignete Firewall Systeme müssen den sicheren Betrieb gewährleisten. Nicht unbedingt benötigte Services sind zu deaktivieren, nicht benötigte Ports sind zu schließen. Die fehlerfreie Erstellung einer qualifizierten Signatur kann nicht sichergestellt werden, wenn das benutzte Betriebssystem durch Viren oder Ähnliches verseucht ist. Der Benutzer hat darauf zu achten, dass auf dem benutzten Computer eine regelmäßig aktualisierte Version eines gängigen Virenscanners zum Einsatz kommt. Weiters dürfen nur solche Kartenlesegeräte verwendet werden, deren Sicherheitsmerkmale nicht verändert wurden. Falls nicht die empfohlenen PKCS#11-Treiber installiert sind, kann die Erstellung einer qualifizierten Signatur nicht garantiert werden. Weiters wird eine Aufdeckung der Signatur PIN nur dann ausgeschlossen, wenn keine anderen als die genannten unterstützten Kartenlesegeräte zum Erstellen der Signatur und zum Management der Signatur Karte verwendet werden. Die in diesem Abschnitt gemachten Auflagen müssen eingehalten werden. Seite 14 von 17

5.3 > Auslieferung und Installation Die Installationsdateien können per Download von der BDC-Homepage nach Authentifizierung mittels Benuterzname und Kennwort über eine HTTPS-Verbindung bezogen werden. Alternativ wird die Auslieferung auf CD (read-only Datenträger) angeboten. Die CD wird entweder per Post zugestellt oder persönlich übergeben. Unabhängig davon ob hotinvoice 4.0.0 per Download oder CD bezogen wird, wird immer eine Installationsdatei übergeben, die gestartet werden muss. Der Benutzer muss daraufhin den Anweisungen der Installationsroutine folgen, um hotinvoice 4.0.0 zu installieren. Anforderungen für die Installation: hotinvoice 4.0.0 ist auf einem dezidierten Rechner zu installieren. Dabei darf es sich ausschließlich um organisatorisch gesicherte Environments (nicht-öffentlicher Bereich) mit Zutrittskontrolle handeln. Nur autorisierten Personen darf Zutritt gewährt werden. Auf dem System darf keine virtuelle Maschine installiert sein, weder als Gastsystem noch als Wirtsystem. Alle nicht benötigten Benutzeraccounts müssen entfernt werden. Vorhandene Nutzer dürfen keine Administratorrechte besitzen. BIOS bzw. EFI sind so zu konfigurieren, dass nur von internen Festplattenlaufwerken gebootet werden kann. Die in diesem Abschnitt gemachten Auflagen müssen eingehalten werden. 5.4 > Auflagen für den Betrieb des Produktes Entsprechend dem Dokument Einheitliche Spezifizierung der Einsatzbedingungen für Signaturanwendungskomponenten, Version 1.4 vom 19.07.2005 muss der Betrieb von hotinvoice 4.0.0 in einem Geschützten Einsatzbereich erfolgen. Folgende Auflagen sind einzuhalten: Der Betrieb von hotinvoice 4.0.0 muss unbedingt mit einem Benutzer, der keine Administratorrechte am System besitzt erfolgen. Während der Erstellung einer qualifizierten Signatur und während des Benutzens der Verwaltungsfunktionen darf der benutzte Computer nicht ferngewartet werden. In diesem Fall kann die fehlerfreie Erstellung einer qualifizierten Signatur und die Geheimhaltung des zu signierenden Dokuments, der PINs und der PUKs nicht sichergestellt werden. Die Integrität und Sicherheit des Computersystems ist jederzeit durch geeignete Maßnahmen sicherzustellen (Virenscanner, Intrusion Detection, Root Kit Detection). Dazu gehört ebenfalls die Überprüfung der CodeSigning Signatur der signierten Programmkomponenten. Das verwendete Betriebssystem ist laufend zu aktualisieren, insbesondere Sicherheitsupdates sind einzuspielen. Die Systemzeit muss korrekt sein. Die Systemzeit muss mindestens täglich aktualisiert werden (z.b. via NTP Service) Die verwendeten Kartenlesegeräte müssen direkt am Computersystem angeschlossen sein. Es dürfen keine weiteren Anwendungen installiert sein, welche auf die angeschlossenen Kartenlesegeräte zugreifen. Seite 15 von 17

Zur Erzeugung qualifizierter elektronischer Signaturen sind Kartenlesegeräte mit Pinpad, sichere Signaturerstellungseinheiten (Signaturkarten) und qualifizierte Zertifikate einzusetzen, deren Eignung nach SigG und SigV geprüft und bestätigt wurden. Vorhandene Sicherheitssiegel (zb bei Kartenlesegeräten) müssen regelmäßig auf Unversehrtheit geprüft werden. Der Signaturkarteninhaber darf die PIN seiner Signaturkarte nicht an Dritte weitergeben und muss diese geheim halten. Die in diesem Abschnitt gemachten Auflagen müssen eingehalten werden. 5.5 > Wartung/Reparatur Bei der Wartung und der Reparatur des Signaturrechners gelten die Voraussetzungen der vorangegangenen Kapitel. Bei Erkennen von Fehlern, die die Sicherheit der Teil- Signaturanwendungskomponente betreffen können, stellt die BDC EDV-Consulting GmbH umgehend aktualisierte Versionen der Programmkomponenten zur Verfügung. Die Anwender des Programms werden per E-Mail oder Telefon über das Auftreten einer solchen Situation informiert. Mit der Veröffentlichung einer neuen Softwareversion von hotinvoice 4.0.0 verliert die aktuelle Herstellererklärung ihre Gültigkeit. In diesem Fall hinterlegt die BDC EDV-Consulting GmbH umgehend entweder einen Nachtrag zu dieser Herstellererklärung oder gegebenenfalls eine neue Herstellererklärung bei der Bundesnetzagentur. 6 Algorithmen und zugehörige Parameter Signaturerstellung hotinvoice 4.0.0 unterstützt den RSA-Algorithmus der D-Trust multicard mit der Schlüssellänge von 2048 Bit. Das unterstützte RSA-Verfahren gilt nach der Übersicht über geeignete Algorithmen der Bundesnetzagentur 4 bis Ende 2016 als sicher. hotinvoice 4.0.0 unterstützt das Hash-Verfahren SHA-256. Diese Hash-Funktion gilt nach der Übersicht über geeignete Algorithmen der Bundesnetzagentur bis Ende 2016 als sicher. Signaturverifikation hotinvoice 4.0.0 unterstützt RSA-Schlüssel mit einer Schlüssellänge von 1024 / 1536 und 2048 Bit. Weiters unterstützt hotinvoice 4.0.0 die Hash-Verfahren SHA-1, SHA-256 und RipeMD160. Sofern Algorithmen zum Zeitpunkt der Signaturverifikation laut Algorithmenkatalog als schwach eingestuft sind, wird dies von hotinvoice 4.0.0 im Prüfbericht mittels eines definierten Hinweises angezeigt. 7 Gültigkeit der Herstellererklärung Diese Erklärung ist bis zu ihrem Widerruf, längstens jedoch bis zum 31.12.2016, gültig. Die Herstellererklärung kann durch den Hersteller selbst oder durch die Bundesnetzagentur zurückgezogen werden. 4 Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der Signaturverordnung (Übersicht über geeignete Algorithmen), Veröffentlicht am 04. Februar 2010 im Bundesanzeiger Nr. 19, Seite 426 Seite 16 von 17

Die Gültigkeit kann sich ebenfalls im Falle des vorzeitigen Ablaufs der Vertrauenswürdigkeit der Hashalgorithmen SHA-256 oder des Signaturverfahrens (RSA 2048 Bit) verkürzen. Der aktuelle Status der Gültigkeit dieser Herstellererklärung ist bei der zuständigen Behörde (Bundesnetzagentur, Referat Elektronische Signatur) zu erfragen oder kann auf den Webseiten der Bundesnetzagentur nachgeprüft werden. 8 Zusatzdokumentation Folgende Bestandteile der Herstellererklärung wurden aus dem Veröffentlichungstext ausgegliedert und bei der zuständigen Behörde hinterlegt: 1. Sicherheitskonzept Version 1.2 vom 17.01.2011 (29 Seiten) 2. Testplan Version 1.2 vom 17.01.2011 (31 Seiten) 3. Testprotokoll Version 1.0 vom 17.01.2011 (6 Seiten) 4. Dokumentation der Entwicklungsumgebung Version 1.0 vom 26.07.2010 (5 Seiten) 5. Benutzerhandbuch hotinvoice Desktop Version 4.0.0 vom 17.01.2011 (63 Seiten) Die vorgenannten Dokumente sind nicht zur Veröffentlichung bestimmt. - Ende der Herstellererklärung - Seite 17 von 17