Herstellererklärung. Die. First Businesspost GmbH. Am Moosfeld 27. 81829 München



Ähnliche Dokumente
Herstellererklärung. für eine Signaturanwendungskomponente. Gateway Version 1.11

Bestätigung. TÜV Informationstechnik GmbH - ein Unternehmen der TÜV NORD Gruppe - Zertifizierungsstelle Langemarckstraße Essen

Bedienungsanleitung: Onlineverifizierung von qualifiziert signierten PDF-Dateien

Bestätigung. TÜV Informationstechnik GmbH Unternehmensgruppe TÜV NORD Zertifizierungsstelle Langemarckstraße Essen

Bestätigung. TÜV Informationstechnik GmbH - ein Unternehmen der RWTÜV-Gruppe - Zertifizierungsstelle Langemarckstraße Essen

Bestätigung. TÜV Informationstechnik GmbH - ein Unternehmen der RWTÜV-Gruppe - Zertifizierungsstelle Am Technologiepark 1.

multisign Signatur-Prüfwerkzeug Handbuch Security Networks AG Stand:

Bestätigung von Produkten für qualifizierte elektronische Signaturen

Welche technischen Voraussetzungen sind für die Nutzung von Zertifikaten notwendig?

Prodanet ProductManager WinEdition

Herstellererklärung. Die. IO Factory Limited Flughafenstrasse 52a - Haus C - Airport Center D Hamburg

Windows Vista Security

1. Die Signaturen auf den PDF-Dokumenten der Deutschen Rentenversicherung werden als ungültig ausgewiesen oder mit Gültigkeit unbekannt gekennzeichnet

Signatur-Prüfprotokoll

Nutzung von GiS BasePac 8 im Netzwerk

Step by Step Webserver unter Windows Server von Christian Bartl

Anleitung. Lesezugriff auf die App CHARLY Termine unter Android Stand:

ecaros2 - Accountmanager

Dokumentation. Black- und Whitelists. Absenderadressen auf eine Blacklist oder eine Whitelist setzen. Zugriff per Webbrowser

COSA. Portal Client Installation JAVA J2SE / JRE Version 1.4.2_09, Stand Copyright

Synchronisations- Assistent

(Text von Bedeutung für den EWR)

Dokumentation IBIS Monitor

Installationsanleitung für das Integrity Tool zur AusweisApp Version 1.7 (Microsoft Windows) Dokumentversion 1.0

Übung - Konfigurieren einer Windows 7-Firewall

ELSTER Daten versenden

MULTIWEB Banking. Installation und Update unter Windows

-Zertifikatsverwaltung

Installationsanleitung für Update SC-Line

TERRA Kasse Backup Service

Matrix42. Use Case - Sicherung und Rücksicherung persönlicher Einstellungen über Personal Backup. Version September

Anwendungsbeispiele Sign Live! Secure Mail Gateway

Tipps und Tricks zu den Updates

Sicherheitsbestätigung und Bericht. T-Systems SE Zertifizierungsdiensteanbieter Bundesnotarkammer

Installation / Update für die P aketdatenbank 1.x (Version )

ISA Server 2004 Erstellen einer Webverkettung (Proxy-Chain) - Von Marc Grote

Dieses Dokument beschreibt die Installation des Governikus Add-In for Microsoft Office (Governikus Add-In) auf Ihrem Arbeitsplatz.

Nikon Message Center

Das Handbuch zu Simond. Peter H. Grasch

Konfiguration IKMZ / Universitätsrechenzentrum des Cisco VPN-Clients v3.6 Netze und Datenkommunikation

Installation OMNIKEY 3121 USB

Installationsanleitung Sander und Doll Mobilaufmaß. Stand

Cisco AnyConnect VPN Client - Anleitung für Windows7

Firmware-Update, CAPI Update

AGROPLUS Buchhaltung. Daten-Server und Sicherheitskopie. Version vom b

Vorgehensweise bei Lastschriftverfahren

Updateseite_BuV-PlugIn-NERZ-Gesamt

Internet online Update (Mozilla Firefox)

Update von XBRL Publisher auf XBRL Publisher 1.7.2

Advoware mit VPN Zugriff lokaler Server / PC auf externe Datenbank

Einrichten einer DFÜ-Verbindung per USB

Downloadfehler in DEHSt-VPSMail. Workaround zum Umgang mit einem Downloadfehler

eurovat Magento Extension Magento - Extension Extension V1.4.2 Dokumentation Version 1.0 SNM-Portal UG (haftungsbeschränkt) & Co. KG Vorherstraße 17

TechNote. Produkt: TWINFAX 7.0 (ab CD_24), TWINFAX 6.0 Modul: SMTP, T611, R3 Kurzbeschreibung: Briefpapier- und Mailbodyunterstützung

WEKA Handwerksbüro PS Mehrplatzinstallation

Umzug der Datenbank Firebird auf MS SQL Server

Datenschutzerklärung:

Sicherheitsbestätigung und Bericht. T-Systems SW Zertifizierungsdienst Deutsche Post Com GmbH Geschäftsfeld Signtrust

LDAP Konfiguration nach einem Update auf Version 6.3 Version 1.2 Stand: 23. Januar 2012 Copyright MATESO GmbH

Kryptographische Anonymisierung bei Verkehrsflussanalysen

Auskunft über die Kassendaten

2. Die eigenen Benutzerdaten aus orgamax müssen bekannt sein

Update und Konfiguraton mit dem ANTLOG Konfigurations-Assistenten

Anleitung zur Konfiguration eines NO-IP DynDNS-Accounts mit der TOOLBOXflex-3.2

Wir freuen uns, dass Sie mit der VR-NetWorld Software Ihren Zahlungsverkehr zukünftig einfach und sicher elektronisch abwickeln möchten.

Handbuch Amos Ersteller: EWERK MUS GmbH Erstellungsdatum:

Elexis-BlueEvidence-Connector

Datenübernahme in ein Produkt der Lexware premium, professional oder plus line

Drucken aus der Anwendung

Bestätigung. TÜV Informationstechnik GmbH - ein Unternehmen der RWTÜV-Gruppe - Zertifizierungsstelle Am Technologiepark 1.

Benutzerhandbuch - Elterliche Kontrolle

ADSL Leistungsbeschreibung

HorstBox (DVA-G3342SD)

Bedienerhandbuch Toleranztabellen Version 1.2.x. Copyright Hexagon Metrology

Konfiguration von Igel ThinClients fu r den Zugriff via Netscaler Gateway auf eine Storefront/ XenDesktop 7 Umgebung

Firewalls für Lexware Info Service konfigurieren

mobilepoi 0.91 Demo Version Anleitung Das Software Studio Christian Efinger Erstellt am 21. Oktober 2005

Zertifikat in dakota einlesen Wie lese ich mein Zertifikat in dakota.le ein?

Elektronischer Kontoauszug

Auto-Provisionierung tiptel 31x0 mit Yeastar MyPBX

eridea AG Installation Eclipse V 1.4

Inhalt... 1 Einleitung... 1 Systemanforderungen... 1 Software Download... 1 Prüfdokumentation... 4 Probleme... 5 Hintergrund... 5

Windows-Sicherheit in 5 Schritten. Version 1.1 Weitere Texte finden Sie unter

2. Konfiguration der Adobe Software für die Überprüfung von digitalen Unterschriften

A. Ersetzung einer veralteten Govello-ID ( Absenderadresse )

Anleitung Inspector Webfex 2013

Verwendung des IDS Backup Systems unter Windows 2000

Umgang mit der Software ebuddy Ändern von IP Adresse, Firmware und erstellen von Backups von ewon Geräten.

Firewalls für Lexware Info Service konfigurieren

Neuinstallation Einzelplatzversion

Wichtige Hinweise zu den neuen Orientierungshilfen der Architekten-/Objektplanerverträge

Rechenzentrum der Ruhr-Universität Bochum. Integration von egroupware an der RUB in Outlook 2010 mit Funambol

Telefon-Anbindung. Einrichtung Telefonanlagen. TOPIX Informationssysteme AG. Stand:

Anti-Botnet-Beratungszentrum. Windows XP in fünf Schritten absichern

Anleitung zur Installation und Freischaltung der Signaturlösung S-Trust für Mitglieder der Rechtsanwaltskammer des Landes Brandenburg

Handbuch Fischertechnik-Einzelteiltabelle V3.7.3

10 Jahre ArchiSig Struktur nach dem Sozialgesetzbuch. Jürgen Vogler, Geschäftsführer Mentana-Claimsoft GmbH. mentana-claimsoft.de

Handbuch. TMBackup R3

AutoCAD Dienstprogramm zur Lizenzübertragung

Transkript:

Herstellererklärung Die First Businesspost GmbH Am Moosfeld 27 81829 München erklärt hiermit gemäß 17 Abs. 4 Satz 2 SigG in Verbindung mit 15 Abs. 5 Satz 1 SigV, dass das Produkt Downloadmanager 2.0 die nachstehend genannten Anforderungen des Signaturgesetzes 1 bzw. der Signaturverordnung 21 erfüllt. First Businesspost GmbH, München, den 08.09.2008 gez. Andreas Eichler, Geschäftsführer gez. Achim Kauffmann, Geschäftsführer Diese Herstellererklärung mit der Dokumentennummer D-HE02 besteht aus 16 Seiten. 1 2 Signaturgesetz vom 16. Mai 2001 (BGBl. I S. 876), zuletzt geändert durch Artikel 4 des Gesetzes vom 26. Februar 2007 Verordnung zur elektronischen Signatur (Signaturverordnung SigV), zuletzt geändert durch Artikel 9 Abs. 18 des Gesetzes vom 23. November 2007 Erklärung D-HE02, Version 1.2 Seite 1 von 16

Inhaltsverzeichnis 1. Handelsbezeichnung... 4 2. Lieferumfang und Versionsinformationen... 4 3. Funktionsbeschreibung... 5 3.1 Überblick... 5 3.2 Prüfen von Signaturen... 7 4. Erfüllung des Signaturgesetzes und der Signaturverordnung... 11 5. Maßnahmen in der Einsatzumgebung... 12 5.1 Einrichtung der IT- Komponenten... 12 5.2 Anbindung an ein Netzwerk... 13 5.3 Auslieferung und Installation... 13 5.4 Auflagen für den Betrieb des Produktes... 14 6. Algorithmen und zugehörige Parameter... 15 7. Gültigkeit der Herstellererklärung... 16 8. Zusatzdokumentation... 16 Erklärung D-HE02, Version 1.1 Seite 2 von 16

Versionshistorie Version Datum 1.0 24.08.2007 Fassung eingereicht bei der BNetzA 1.1 28.05.2008 Überarbeitete Fassung nach Prüfung 08.09.2008 Finalisierte Fassung zur Veröffentlichung Erklärung D-HE02, Version 1.1 Seite 3 von 16

1. Handelsbezeichnung Die Handelsbezeichnung lautet: Downloadmanager 2.0 (im Folgenden abgekürzt als DLM) Auslieferung: Die Auslieferung erfolgt entweder per CD oder per Download von www.firstbusinesspost.com, erforderliche Konfigurationsinformationen werden per Mail oder Fax separat ausgeliefert. Hersteller: First Businesspost GmbH, Am Moosfeld 27, 81829 München Handelsregisterauszug: HR München 136922 2. Lieferumfang und Versionsinformationen Nachfolgend ist der Lieferumfang einschließlich der Versionsinformationen aufgezählt: Name Art Version/Datum Downloadmanager Software a) Windows-Version b) Unix-Version Handbuch Dokumentation 2.0 Tabelle 1: Lieferumfang Bei der Software handelt sich um ein ausführbares Installationskit mit Handbuch auf CD und separaten Konfigurations- und Einrichtinformationen. Dabei werden zur Verwendung in Windows- und Unix-Umgebungen unterschiedliche Dateien zur Verwendung ausgeliefert. Das in der Tabelle genannte Handbuch enthält alle Vorgaben zur Installation und Nutzung von DLM. Als DLM-Rechner wird im Folgenden ein Rechner mit installiertem DLM verstanden. Zur bedarfsweisen sicheren Anzeige des Inhaltes von geprüften signierten Dateien sind für das jeweilige Dateiformat geeignete Anzeigeprogramme zu verwenden, die eine sichere Anzeige ( Secure Viewer ) gemäß Signaturgesetz ermöglichen; solche Viewer gehören jedoch nicht zum Lieferumfang des Produktes Downloadmanager 2.0 und sind nicht Bestandteil dieser Erklärung. Zur sicheren Anzeige von Prüfprotokollen (in den Betriebsarten Option 2 und Standardbetriebsart, s. Abschnitt 3.1) ist ebenso ein sicheres Anzeigeprogramm für das Dateiformat txt erforderlich, das jedoch nicht zum Lieferumfang des Produktes Downloadmanager 2.0 gehört und nicht Bestandteil dieser Erklärung ist. Für den sicheren Betrieb von DLM wird weiterhin ein Integritäts-Checker zur Prüfung der Unversehrtheit von DLM benötigt. Auf den Web-Seiten des Herstellers wird zu diesem Zweck das Tool Hash-Calc der Fa. Slasoft bereitgestellt, das jedoch nicht zum Lieferumfang des Produktes Downloadmanager 2.0 gehört und nicht Bestandteil dieser Erklärung ist. Für die Erzeugung von Signaturen steht die Komponente Gateway Version 2.00 der First Businesspost GmbH zur Verfügung, die jedoch nicht zum Lieferumfang des Produktes 2.0 Erklärung D-HE02, Version 1.2 Seite 4 von 16

Downloadmanager 2.0 gehört und nicht Bestandteil dieser Erklärung ist. Für dieses Produkt liegt eine separate Hersteller-Erklärung (Dokumentennummer G-HE02) vor. Im Zusammenhang mit DLM ist für die Signaturerzeugung die Nutzung des Produktes Gateway vorgesehen, d. h. DLM verifiziert solche Signaturen, die von Gateway Version 2.00 (oder einer früheren Version) erzeugt wurden. 3. Funktionsbeschreibung Bei dem Produkt handelt es sich um einen Teil einer Signaturanwendungskomponente (SAK) im Sinne von 2 Nr. 11 SigG, hier den Prozess der Prüfung von Massensignaturen (an elektronischen Rechnungen) betreffend. Das Szenario geht aus von - Rechnungsstellern, die elektronische Rechnungen im Rohformat bei einem Signaturserver (hier das Produkt Gateway Version 2.00) einliefern, - Dienstleistern, die eingelieferte Rechnungen in Standardformate umsetzen und im Auftrag qualifiziert elektronisch signieren (unter Nutzung des Signaturservers), - Rechnungsempfängern, die signierte Rechnungen vom Dienstleister erhalten und die Gültigkeit der Signaturen mit dem Produkt DLM verifizieren. 3.1 Überblick Die Java-Anwendung DLM prüft die Gültigkeit von Signaturen in CMS-Dateien von einem Gateway-Rechner (s. Hersteller-Erklärung G-HE02 zu Gateway Version 2.00) und protokolliert das Ergebnis. Hinweis: In den CMS-Dateien sind neben den Rechnungsdaten auch z. B. die Signatur, der Hashwert und das zur Signatur verwendete Zertifikat enthalten. Dabei wird vorausgesetzt, dass die Massensignaturen durch das Produkt Gateway Version 2.00 (oder einer früheren Version) des gleichen Herstellers erzeugt worden sind. Für dieses Produkt liegt eine separate Hersteller-Erklärung (Dokumentennummer G-HE02) vor. Rechner, auf denen das Produkt Gateway installiert ist, werden als Gateway-Rechner bezeichnet. Es stehen mehrere Betriebsarten zur Verfügung: Standard-Betriebsart von DLM: DLM steuert die Abholung der signierten Rechnungen vom Gateway-Rechner: DLM verbindet sich dazu in konfigurierbaren Intervallen über HTTP mit dem Gateway-Rechner und holt nach Authentisierung auf Anwendungsebene verschlüsselte Pakete mit Daten ab. Nach der Entschlüsselung werden die signierten Rechnungen extrahiert, ihre Signaturen überprüft und bei positivem Prüfergebnis schlussendlich die extrahierten Daten und die Ergebnisse der Prüfung lokal auf dem DLM-Rechner im Archiv-Verzeichnis gespeichert, bevor sie nachgelagerten Anwendungen (in aller Regel Fibu- und Warenwirtschaftssystem) zur Verfügung gestellt werden können. Bei negativem Prüfergebnis wird ein entsprechender Log-Eintrag erzeugt. Andere Betriebsarten bzw. Optionen sind konfigurierbar: Erklärung D-HE02, Version 1.1 Seite 5 von 16

Option 1: Es können von einem Gateway-Rechner eine oder mehrere CMS-Datei(en) an DLM mittels https übertragen werden. Die in den CMS-Dateien enthaltenen Signaturen werden geprüft, das zugehörige Signatur-Prüfprotokoll wird über https zurück an den Gateway-Rechner übertragen. Die weitere Verarbeitung obliegt dem Gateway-Rechner und dem Produkt Gateway Version 2.00. Option 2: Es kann eine vorhandene CMS-Datei zur (späteren) erneuten Prüfung über eine html-seite manuell an DLM übertragen werden. DLM liefert dann als Antwort ein Signaturprüfprotokoll, zeigt dieses an und bietet die Möglichkeit, die in der CMS-Datei enthaltenen signierten Daten auszugeben. Wird Windows als Plattform für DLM verwendet, kann die zu prüfende CMS-Datei auch als Matrixbarcode in einer Datendatei (TIFF / PDF) enthalten sein; in diesem Fall kann die CMS- Datei über ein OCR-Programm (OCR = Optical Character Recognition, Programm zur automatischen Texterkennung gescannter Vorlagen) aus der Datendatei wiederhergestellt werden. Als OCR-Programm ist ClearImage DataMatrix (Version 5.4.15 oder höher) der Firma Inlite zu verwenden. Die folgende Abbildung veranschaulicht die verschiedenen Betriebsarten und die Abläufe bei DLM. Erklärung D-HE02, Version 1.1 Seite 6 von 16

Standardbetrieb(Gateway) Option 1 (Gateway) Option 2 (man. Upload) http Authentisierung und Verschlüsselung auf Anwendungsebene https https Download Manager Einlieferungspfad Apache Service Apache Gui CMS Datei entschlüsseln Barcode OCR CMS Datei bereitstellen Extrahieren der Rechnungsdaten Prüfung mathematisch Prüfung Signatur- und Herausgeberzertifikate (OCSP) Erzeugung Prüfprotokoll Lokale Speicherung https https Übergabe Archiv-Verzeichnis Übergabe Gateway Anzeige Prüfprotokoll 3.2 Prüfen von Signaturen Voraussetzungen: Vor der Prüfung von Signaturen muss DLM von dem entsprechenden Administrationspersonal ordnungsgemäß installiert, konfiguriert und gestartet worden sein. Die Auflagen an eine gesicherte Einsatzumgebung (s. Kapitel 5) sind einzuhalten. Die regelmäßige Integritätsprüfung von DLM (s. Abschnitte 5.3 und 5.4) ist erforderlich, um Integritätsverletzungen erkennen zu können ( 15 (4) SigV). Der Zutritt zum Betriebsraum der DLM-Rechner ist gemäß der Rollenbeschreibung (s. Abschnitt 5) in einem Zutrittskonzept zu regeln; der Betriebsraum ist technisch als geschützter Einsatzbereich im Sinne von Einheitliche Spezifizierung der Einsatzbedingungen für Signa- Erklärung D-HE02, Version 1.1 Seite 7 von 16

turanwendungskomponenten (Bundesnetzagentur, Version 1.4, Stand: 19.07.2005) abzusichern. - Standardbetriebsart Bei der Installation von DLM für die Standardbetriebsart beim Nutzer (Rechnungsempfänger) wird zunächst für Zwecke der Authentisierung und der Verschlüsselung (auf Anwendungsebene) ein Schlüsselpaar mit einem Zertifikat erzeugt und der öffentliche Schlüssel gesichert an den Gateway-Rechner übertragen. Im Gateway-Rechner werden entsprechende Kundenstammdaten eingegeben und eine Identifikationsnummer für diesen Nutzer (Rechnungsempfänger) vergeben. Unter dieser ID wird der öffentliche Schlüssel gespeichert. So wird sichergestellt, dass nur autorisierte Empfänger Daten abholen und diese verschlüsselt übertragen werden. Nach der Installation sind verschiedene Konfigurationsschritte vom Nutzer durchzuführen: u. a. das Einrichten von Verzeichnissen für die Weiterverarbeitung der abgeholten Daten, das Einrichten der URL für den http-download, die Festlegung der Zeitpunkte der Datenabholung, die Vergabe eines Passwortes für den Zugriff auf DLM. Im Konfigurationsmenü werden die URLs der OCSP-Dienste für die verwendeten Zertifikate definiert. Dies sind derzeit die Dienste des ZDA der Deutschen Telekom und der Bundesnetzagentur. Weiterhin existiert eine Konfigurationsdatei, in der die Pfade zu den zur Signaturprüfung verwendeten Zertifikaten definiert werden. Alle zur Installation und Konfiguration erforderlichen Schritte sind im Kapitel 1 des Handbuchs beschrieben. Die Bereitstellung der zu prüfenden signierten Daten erfolgt durch die Software Gateway Version 2.00. Dabei wird in Abhängigkeit der Vorgaben des Empfängers jeweils ein Datenpaket bereitgestellt, das entweder aus einzelnen signierten Datensätzen / Rechnungen oder aus aggregierten Datensätzen mit mehreren Rechnungen besteht. Nach erfolgreicher Authentisierung zwischen Gateway-Rechner und Nutzer bzw. DLM- Rechner wird im Standardbetrieb dem DLM eine Liste der abzuholenden Datenpakete übertragen; danach erfolgt die Übertragung der auf Anwendungsebene verschlüsselten Datenpakete. - Option 1 und Option 2 In der Betriebsart Option 1 und Option 2 erfolgt die Authentisierung und Verschlüsselung über https unter Nutzung von Maschinen-Zertifikaten. Eine entsprechende Installation solcher Zertifikate ist sowohl auf dem Gateway-Rechner wie auch dem DLM-Rechner erforderlich. Eine weitere Ver-/Entschlüsselung auf Anwendungsebene findet dann nicht statt. Zur Nutzung der Betriebsarten Option 1 und Option 2 dürfen die Installation und Konfiguration in der konkreten Einsatzumgebung des Nutzers ausschließlich von Personal des Herstellers nach Hersteller-eigenen Anweisungen durchgeführt werden. Installation und Konfiguration werden deshalb im Handbuch für den Nutzer nicht dargestellt. Erklärung D-HE02, Version 1.1 Seite 8 von 16

Signaturprüfung: Nach Vorliegen der (entschlüsselten) Daten werden die Arbeitsschritte aus der folgenden Tabelle von DLM ausgeführt, und zwar jeweils in Abhängigkeit von der Standardbetriebsart bzw. der ausgewählten Option. Bearbeitungsschritt Standardfunktion Option 1 Option 2 1. Extrahieren der Daten: signierte Rechnung, Signatur, Zertifikat des Unterzeichners 2. Prüfung der Signatur (mathematisch, unter Nutzung des übertragenen Zertifikats des Unterzeichners) 3. Analyse des Zertifikats des Unterzeichners und Prüfung der Gültigkeit mittels OCSP*)**) 4. Prüfung der Gültigkeit des Zertifikats des Zertifikatsherausgebers mittels OCSP*)**) 5a. Erzeugen des Prüfprotokolls***) und Speichern im Archivierungspfad X X X X X X X X X X X X X 5b. Erzeugen des Prüfprotokolls***) und Übergabe per https X X 6. Speichern der Dateien (CMS-Datei und Originaldatei im Archivierungspfad, entschlüsselte TIFF / PDF und EDI Datei im Exportpfad nur sofern die Prüfung erfolgreich war) X Tabelle 2. Arbeitsschritte *) Die Prüfung der Gültigkeit des Zertifikats wird für die jeweils letzte Rechnung aus einer Übertragung durchgeführt. Man beachte hierzu, dass alle älteren Rechnungen aus der gleichen Übertragung mit dem gleichen (kundenspezifischen) Schlüssel bzw. Zertifikat signiert wurden, so dass eine OCSP-Auskunft "existiert und ist nicht gesperrt" für die neuste Rechnung automatisch auch eine positive Statusauskunft für alle älteren Rechnungen aus der gleichen Übertragung liefert. Bei negativer OCSP-Auskunft wird die Prüfung rekursiv für die nächst-älteste Datei der gleichen Übertragung wiederholt bis entweder eine positive Auskunft "existiert und ist nicht gesperrt" vorliegt oder das ganze Datenpaket als ungültig erkannt wird. **) Bei Nicht-Erreichbarkeit des OCSP-Dienstes erscheint eine Fehlermeldung. Die Verifikation wird abgebrochen und zu einem späteren Zeitpunkt wiederholt. Die Rechnungsdaten werden nicht zur weiteren Verarbeitung zu Verfügung gestellt. ***) Im Prüfprotokoll werden unter anderem folgende Informationen aufgezeichnet: - der bei der zu prüfenden Signatur verwendete Hashalgorithmus, Erklärung D-HE02, Version 1.1 Seite 9 von 16

- das Ergebnis der mathematischen Verifikation ( CMS content hash doesn't match computed hash oder CMS content hash matches computed hash ), - die Daten aller Zertifikate in der Zertifikatskette (Serial Number, Issued by, Name(Zertifikatsinhaber); verwendeter Signaturalgorithmus und Schlüssellänge), - Status der einzelnen Zertifikate ( Certificate exists and was not revoked, The ocsp responder doesn't know about this certificate ) und das Ergebnis der Statusauswertung ( Certificate is valid, Certificate is expired or not valid yet ), - das Gesamtergebnis aller Prüfungen, sofern dieses positiv ist ( CMS signature was successfully verified ). Schritt 1 (Tabelle 2) liefert zunächst eine Zuordnung von Signatur und signierter Datei, die auch im Prüfprotokoll festgehalten wird ( 17 (2) Satz 2 Nr. 1 SigG). Nach Schritt 1 kann in den Betriebsarten Standardbetrieb und Option 2 eine Anzeige der signierten Daten mit einem sicheren Anzeigeprogramm (Secure Viewer, s. Abschnitt 2) erfolgen ( 17 (2) Satz 3 SigG). Bei der Betriebsart Option 1 erfolgt eine solche Anzeige ablaufbedingt beim Produkt Gateway Version 2.00. Im Prüfprotokoll (s. *** im Anschluss an Tabelle 2) wird festgehalten, - ob die signierten Daten unverändert Ergebnis der mathematischen Verifikation im Schritt 2 sind ( 17 (2) Satz 2 Nr. 2 SigG), - wer der Signaturschlüsselinhaber ist ( 17 (2) Satz 2 Nr. 3 SigG), - welche Inhalte das Zertifikat hat ( 17 (2) Satz 2 Nr. 4 SigG). Bei der OCSP-Prüfung (Schritte 3 und 4) der beteiligten Zertifikate wird die Auswertung nach dem Kettenmodell vorgenommen und detailliert im Prüfprotokoll aufgezeichnet ( 15 (2) Nr. 2b SigV). Sobald sich im Prüfablauf ein Negativergebnis ergibt, wird die weitere Prüfung ausgesetzt: Bei der Standardbetriebsart wird ein Log-Eintrag mit dem Negativergebnis erzeugt, bei Option 1 wird ein entsprechender Fehlercode an den Gateway-Rechner übermittelt, bei der Option 2 wird das Prüfprotokoll (soweit erzeugt) ausgegeben und sodann das Negativergebnis durch DLM angezeigt. Bei der Standardbetriebsart wird das Prüfprotokoll in das Archiv-Verzeichnis (im txt-format) gespeichert und kann mit einem sicheren Anzeigeprogramm vom Nutzer inspiziert werden. Das Archiv-Verzeichnis gestattet nur dem DLM (sowie vertrauenswürdigen Administratoren) schreibenden Zugriff. Hierdurch wird die Manipulationssicherheit der gespeicherten Protokolle sichergestellt. Das Prüfprotokoll wird bei Option 1 und 2 mit https an den Nutzer übertragen; bei der Option 1 ist eine Anzeige des Prüfprotokolls erst zu einem späteren Zeitpunkt (nach Abholung der Daten durch einen DLM) vorgesehen. Bei der Option 2 erfolgt die Anzeige im Browser. Das Prüfprotokoll kann aber zusätzlich im Archiv-Verzeichnis gespeichert und wie bei der Standardbetriebsart angezeigt werden. Das Ergebnis der Nachprüfung der beteiligten Zertifikate wird somit vollständig und transparent dem Nutzer dargestellt ( 17 (2) Satz 2 Nr. 5 SigG und 15 (2) Nr. 2a SigV). Erklärung D-HE02, Version 1.1 Seite 10 von 16

4. Erfüllung des Signaturgesetzes und der Signaturverordnung Das Produkt DLM erfüllt die nachfolgend aufgeführten Anforderungen des SigG in dem jeweils erläuterten Sinne: 17 (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 Zu Nr. 1: 5. zu welchem Ergebnis die Nachprüfung von Zertifikaten nach 5 Abs. 1 Satz 3 geführt hat. Die Signatur ist mit den signierten Daten in einer CMS-Datei gespeichert, damit ist der Bezug von Signatur und signierten Daten hergestellt. Die Zuordnung ist außerdem dem Prüfprotokoll entnehmbar. Zu Nr. 2: Dies erfolgt durch die mathematische Prüfung der Signatur (Arbeitsschritt 2 in der Tabelle 2), das Ergebnis wird im Prüfprotokoll protokolliert (Arbeitsschritt 5a/b). Zu Nr. 3: Der Signaturschlüssel-Inhaber wird im Klartext ins Prüfprotokoll geschrieben (Arbeitsschritt 5a/b). Zu Nr. 4: Die Zertifikate werden aus der CMS-Datei exportiert und ihre Eigenschaften angezeigt. Zertifikate und Attributzertifikate werden vom DLM gespeichert; es existiert innerhalb des DLM eine Anzeigefunktion hierfür. Zu Nr. 5: Die Prüfung erfolgt in den Arbeitsschritten 3 und 4 aus Tabelle 2. Im Prüfprotokoll werden die entsprechenden Ergebnisse detailliert festgehalten (Arbeitsschritt 5a/b). 17 (2) Satz 3: Signaturanwendungskomponenten müssen nach Bedarf auch den Inhalt der zu signierenden oder signierten Daten hinreichend erkennen lassen. Da es sich um eine Massenanwendung handelt, existiert kein Bedarf, jede einzelne erhaltene Rechnung anzuzeigen. Da jedoch die geprüften Dateien in einem Standard-Textformat vorliegen, kann die Anzeige des Inhaltes bei Bedarf mit einem entsprechenden sicheren Anzeigeprogramm erfolgen. Erklärung D-HE02, Version 1.1 Seite 11 von 16

Das Produkt DLM erfüllt die nachfolgend aufgeführten Anforderungen der SigV in dem jeweils erläuterten Sinne: 15 (2) Signaturanwendungskomponenten nach 17 Abs. 2 des Signaturgesetzes müssen gewährleisten, dass 1. 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. Die Anforderungen unter Nr. 1 im Verordnungstext sind nicht relevant, da sich diese auf die Erzeugung von Signaturen beziehen. Der Punkt 2 a) ist erfüllt, da die Korrektheit der Signaturen im Arbeitsschritt 2 geprüft und das Ergebnis über das Prüfprotokoll (Arbeitsschritt 5a/b) zuverlässig und zutreffend angezeigt wird. Der Punkt 2 b) wird erfüllt, da DLM per OCSP-Requests die Gültigkeit aller beteiligten Zertifikate analysiert und überprüft (Arbeitsschritte 3 und 4) und das Ergebnis im Prüfprotokoll (Arbeitsschritt 5a/b) detailliert festhält. 15 (4) Sicherheitstechnische Veränderungen an technischen Komponenten nach den Absätzen 1 bis 3 müssen für den Nutzer erkennbar werden. Für eine SAK ist nur der Bezug auf den Absatz 2 von 15 SigV relevant. Dieser Punkt ist durch Vorkehrungen in der Einsatzumgebung (regelmäßiger IntegritätsCheck) erfüllt. 5. Maßnahmen in der Einsatzumgebung 5.1 Einrichtung der IT- Komponenten Die SigG-konforme Anwendung von DLM ist an folgende technische Einsatzumgebung gebunden, deren Bestandteile nicht Gegenstand dieser Hersteller-Erklärung sind: DLM ist auf allen Hard- und Softwareplattformen lauffähig, die ein Java-Runtime-Environment ab der Version 1.6 oder höher benutzen. Die aus dieser Anforderung resultierenden Mindestanforderungen für Hard- und Softwareplattform sind einzuhalten. Es wird mind. 500MB RAM Arbeitsspeicher empfohlen. Die Bedienung und Konfiguration kann über eine GUI oder die Konsole erfolgen. (Option 1) Sofern die Erstellung von Signaturprüfprotokollen von Gateway Version 2.00 aus initiiert werden soll, ist ein Apache Tomcat Webserver (Version 5.0 oder höher) mit installiertem https Zertifikat notwendig. (Option 2) Sofern die manuelle Übertragung von CMS Dateien genutzt werden soll, ist ein Apache Tomcat Webserver (Version 5.0 oder höher) notwendig. Liegt als Platt- Erklärung D-HE02, Version 1.1 Seite 12 von 16

form Windows vor und ist die CMS Datei in Form eines Matrix Barcodes gegeben, muss zunächst eine Umwandlung stattfinden, für welche die OCR Software ClearImage DataMatrix (Version 5.4.15 oder höher) der Firma Inlite notwendig ist. Für die Integritätsprüfung von DLM ist ein Integritäts-Checker zu verwenden. Auf den Web-Seiten des Herstellers wird zu diesem Zweck das Tool Hash-Calc der Fa. Slasoft bereitgestellt. Für die Anzeige des Inhaltes der signierten Rechnungen ist ein Secure Viewer (s. Abschnitt 2) als Anzeigeprogramm erforderlich. In den Betriebsarten Option 2 und Standardbetriebsart ist ein solcher Secure Viewer für das Dateiformat txt zur sicheren Anzeige der Prüfprotokolle erforderlich. Die Installationsanweisungen und Hinweise für den Betrieb der genannten Produkte sind zu beachten. Es ist dabei auf eine sichere Konfiguration zu achten. Für die Nutzung der Betriebarten Standardbetrieb und Option 1 ist weiterhin eine Installation des Produktes Gateway Version 2.00 bei einem Dienstleister erforderlich. Das Produkt DLM darf ausschließlich innerhalb der oben beschriebenen Hard- und Softwareausstattung und Konfiguration eingesetzt werden. 5.2 Anbindung an ein Netzwerk Die SigG-konforme Anwendung von DLM ist an folgende Voraussetzungen gebunden: Für die Abholung signierter Daten, die Übermittlung von Prüfprotokollen (abhängig von der Betriebsart) und die Überprüfung von Zertifikaten per OCSP benötigt das installierte Produkt eine Internetanbindung. Eine wird eine performante Internetanbindung über http mit einer Bandbreite von mind. 600 Kbit empfohlen. Der Internet-Zugang ist über eine Firewall abzusichern, der durch eine geeignete Konfiguration insbesondere den Zugriff auf DLM und den DLM-Rechner unterbindet. Die in diesem Abschnitt gemachten Auflagen müssen eingehalten werden. 5.3 Auslieferung und Installation Das Produkt wird vom Hersteller gemäß Abschnitt 1 ausgeliefert. Das spezifizierte Auslieferungsverfahren ist einzuhalten. Vor Installation von DLM ist durch fachkundiges Personal des Anwenders die Einsatzumgebung auf Tauglichkeit zu überprüfen. Dabei ist zu überprüfen, ob die Vorgaben der Installationsanweisungen für alle beteiligten Produkte eingehalten wurden. Danach ist die Integrität der Software DLM durch Nutzung des Integritäts-Checkers zu prüfen. Die Installation und Konfiguration für die Standardbetriebsart muss durch fachkundiges Personal des Anwenders gemäß den Vorgaben des Handbuchs ausgeführt werden. Die Installation und Konfiguration für die Betriebarten Option 1 und Option 2 darf ausschließlich durch fachkundiges Personal des Herstellers ausgeführt werden. Sie erfolgt nach Hersteller-internen Anweisungen. Es ist zu beachten, dass ein Versions-Update für DLM nur nach Vorliegen einer diesbezüglichen Hersteller-Erklärung oder Sicherheitsbestätigung erfolgen darf und nach dem Down- Erklärung D-HE02, Version 1.1 Seite 13 von 16

load die Integrität des Programms durch Nutzung des Integritäts-Checkers zu überprüfen ist. Solche Updates wie auch Fixes/Patches für DLM dürfen nur nach ordnungsgemäßer Freigabe eingespielt werden. Jede Einspielung von Updates und Fixes/Patches sowie jede Inbetriebnahme und jede Wiederinbetriebnahme von DLM, die eine Neuinstallation erfordert, muss durch fachkundiges Personal (des Anwenders bzw. des Herstellers entsprechend den Vorgaben bei den Betriebsarten) erfolgen. DLM darf nur in Verbindung mit vertrauenswürdigen Anwendungen eingesetzt werden. Anwendungen, die DLM nutzen, sind nicht Gegenstand dieser Hersteller-Erklärung. 5.4 Auflagen für den Betrieb des Produktes Die SigG-konforme Anwendung von DLM ist an folgende administrative Einsatzumgebung gebunden: Es ist ein rollenbasiertes Betriebskonzept mit mindestens folgenden Rollen vorzusehen: o Rolle 1: DLM-Benutzer Sie haben Zugriff auf DLM und den DLM-Rechner und dürfen den Download (in der Standardbetriebsart und Option 2) starten, sowie falls erforderlich Änderungen an der Konfiguration vornehmen. Administrator-Rechte sind hierfür nicht erforderlich. Hinweis: Die Begriffe DLM-Benutzer und Nutzer werden synonym verwendet und meinen den Rechnungsempfänger, der DLM verwendet. o Rolle 2: Administratoren Sie haben Zugriff auf auf DLM und den DLM- Rechner zur Ausführung von Updates / Fixes / Patches, zur Durchführung von Datensicherungen sowie Änderungen an der Konfiguration. DLM-Benutzer und Administratoren müssen vertrauenswürdig, qualifiziert und fachkundig sein. Diese Eigenschaften sind durch geeignete Maßnahmen wie regelmäßige Auskunftseinholung und Mitarbeitergespräche sowie geeignete Aus- und Fortbildung sicherzustellen. Die Rollen beim physischen Zugriff auf Rechner und Anwendung sind über Benutzerkonzepte z.b. mit Passwörtern umzusetzen. Die Passwörter zum benutzenden und administrativen Zugriff sind sorgfältig aufzubewahren. Der Zutritt zum Betriebsraum der DLM-Rechner ist gemäß der Rollenbeschreibung in einem Zutrittskonzept zu regeln; der Betriebsraum ist technisch als geschützter Einsatzbereich im Sinne von Einheitliche Spezifizierung der Einsatzbedingungen für Signaturanwendungskomponenten (Bundesnetzagentur, Version 1.4, Stand: 19.07.2005) abzusichern. Regelmäßige Updates des Betriebssystems des DLM-Rechners und ggf. weiterer verwendeter Produkte in der Einsatzumgebung sind erforderlich, um potenzielle neue Bedrohungen abwehren zu können. Updates/Fixes/Patches für das Betriebssystem der DLM-Rechner und weitere benötigte Software werden nur nach ordnungsgemäßer Erklärung D-HE02, Version 1.1 Seite 14 von 16

Freigabe eingespielt. Die Einspielung erfolgt durch qualifizierte, fachkundige und vertrauenswürdige Personen. Es ist eine Antivirensoftware zu installieren und regelmäßig zu aktualisieren. Vom DLM erzeugte Fehlermeldungen über die Benachrichtigungsfunktion und im Systemlog sind regelmäßig auszuwerten. DLM ist in regelmäßigen Abständen auf seine Integrität zu überprüfen. Hierzu werden die Hash-Werte der zum Betrieb benötigten Programmpakete auf der Website des Herstellers veröffentlicht. Der Anwender muss zur Prüfung die Hashwerte mit dem in Abschnitt 2 genannten Integritäts-Checker lokal erzeugen und mit den veröffentlichten Werten vergleichen. Die von DLM erzeugten Prüfprotokolle sind abhängig vom Anwendungskontext ggf. revisionssicher aufzubewahren. Eine Veränderung der Einsatzumgebung ist nicht zulässig bzw. nicht mehr von dieser Hersteller-Erklärung abgedeckt. Der Einsatz von DLM muss insgesamt in einer vertrauenswürdigen Umgebung stattfinden. Dies gilt insbesondere, wenn DLM als Dienst unter Windows gestartet wird. Hier wird dann das Passwort für den Zugriff auf den privaten Authentisierungs- und Verschlüsselungsschlüssel automatisch geladen und mit dem Passwort entschlüsselt, um die Steuerung des Datendownloads zu den vorher festegelegten Zeitpunkten starten zu können. Der Einsatz von DLM setzt die Signaturerzeugung durch einen Gateway-Rechner voraus; es ist somit zu beachten, dass nur solche Signaturen geprüft werden können, die von Gateway Version 2.00 (oder einer früheren Version) erzeugt wurden. Mit Auslieferung des Produktes ist der Betreiber auf die Einhaltung der oben genannten Bedingungen hinzuweisen. 6. Algorithmen und zugehörige Parameter Das Produkt DLM verwendet bei der Prüfung von Signaturen folgende Algorithmen: RSA-1024 und RSA-2048, die Hashverfahren SHA-1 und SHA-512. Diese kommen bei der Prüfung von Signaturen nur in den Kombinationen RSA-1024/SHA-1 und RSA-2048/SHA-512 zur Anwendung. Hinweise zur Erzeugung von Signaturen durch das Produkt Gateway: Bei der Erzeugung von Signaturen durch das Produkt Gateway Version 1.11 wurde bis 31.12.2007 die Kombination RSA-1024/SHA-1 verwendet. Nach diesem Datum ist die Nutzung von Gateway 1.11 und der genannten Algorithmenkombination nach Vorgabe des Herstellers nicht mehr zulässig. Ab dem 1.1.2008 ist nur die Nutzung der Gateway-Version 2.00 zulässig, die Signaturen mit der Kombination RSA-2048/SHA-512 erzeugt. Für die Prüfung von Signaturen durch DLM gilt: Falls dem DLM Rechnungen zur Prüfung vorgelegt werden, die mit der Kombination RSA- 1024/SHA-1 vor dem 31.12.2007 signiert wurden, wird im Prüfprotokoll neben dem Prüfergebnis ein Hinweis auf die zum 31.12.2007 abgelaufenen beteiligten Zertifikate ausgegeben. Erklärung D-HE02, Version 1.1 Seite 15 von 16

Die Kombination RSA-1024/SHA-1 gilt nach der Übersicht über geeignete Algorithmen der Bundesnetzagentur*) für die Prüfung von Signaturen nur bis 31.03.2008 als sicher und fällt deshalb nicht mehr unter diese Hersteller-Erklärung. Die Kombination RSA-2048/SHA-512 gilt nach der Übersicht über geeignete Algorithmen der Bundesnetzagentur*) jedoch mindestens bis Ende 2014 als sicher. Hinweis: Für die frühere Version 1.62 von DLM liegt ebenfalls eine Hersteller-Erklärung vor. Da dieses Produkt lediglich mit der Algorithmenkombination RSA-1024/SHA-1arbeitet, ist dessen Hersteller-Erklärung nicht mehr gültig. *) Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der Signaturverordnung (Übersicht über geeignete Algorithmen) vom 17. Dezember 2007, Bundesanzeiger Nr. 19, S. 376 vom 05. Februar 2008. 7. Gültigkeit der Herstellererklärung Diese Erklärung ist bei Nutzung von RSA-2048/SHA-512 bis zu ihrem Widerruf, längstens jedoch bis zum 31.12.2014 gültig. Der aktuelle Status der Gültigkeit der Erklärung ist bei der zuständigen Behörde (Bundesnetzagentur, Referat Qualifizierte Elektronische Signatur) zu erfragen 8. Zusatzdokumentation Folgende Bestandteile der Herstellererklärung wurden aus dem Veröffentlichungstext ausgegliedert und bei der zuständigen Behörde hinterlegt: Anlage 1: Anforderungsdokument, Version 1.1, 21 Seiten Anlage 2: Entwicklungsumgebung und Testdokumentation, Version 1.1, 15 Seiten Handbuch, Version 2.0.0, 43 Seiten DLM internal installation guideline (Hersteller-interne Installationsanweisung), Version 2.0, 4 Seiten. Ende der Hersteller-Erklärung. Erklärung D-HE02, Version 1.1 Seite 16 von 16