Infotech Signer Common Criteria Evaluation · Dieses Dokument beinhaltet das Benutzerhandbuch (AGD) der Komponente „ Infotech Signer“

Infotech Signer Common Criteria Evaluation Handbuch / Guidance Document

Infotech GmbH

Autor: Stephan Slabihoud, TÜVIT GmbH Christian Weber, Infotech GmbH

Kategorie: CC Evaluation

Version: 1.3

Letzte Änderung: 2013-04-29

Dateiname: ZEDAL30_AGD_1.3.docx

Auszug Dieses Dokument beinhaltet das Benutzerhandbuch (AGD) der Komponente „Infotech Signer“.

Stichwörter CC, AGD, Common Criteria

Revisionshistorie Datum Version Autor Bemerkung

15-Jan-13 0.1 Infotech GmbH Erstellt

17-Jan-13 0.2 Infotech GmbH Vervollständigt

22-Jan-13 1.0 Infotech GmbH Eingereicht zum Review

14-Feb-13 1.1 Infotech GmbH Kleine Korrekturen nach Review

22-Apr-13 1.2 Infotech GmbH Ergänzungen und editorische Korrekturen

29-Apr-13 1.3 Infotech GmbH Referenzen korrigiert

Handbuch (AGD) Seite 2/133

Diese Seite wurde absichtlich leer gelassen


Inhaltsverzeichnis Seite

1 EINLEITUNG .................................................................................................................... 11 2 INSTALLATION UND PROGRAMMSTART ..................................................................... 12

2.1 Voraussetzungen ....................................................................................................... 12 2.2 Auslieferung der SAK ................................................................................................. 14 2.3 Vorbereitungen zur Installation ................................................................................... 14 2.4 Programminstallation ................................................................................................. 15 2.5 Überprüfung der Integrität .......................................................................................... 18 2.6 Starten der SAK ......................................................................................................... 19 2.7 Betrieb der SAK ......................................................................................................... 19 2.8 Wartung und Pflege ................................................................................................... 20 2.9 Uninstallation ............................................................................................................. 20

3 BENUTZERHANDBUCH - ALLGEMEINES ..................................................................... 21 3.1 Benutzerrollen ............................................................................................................ 21 3.2 Betriebsmodi .............................................................................................................. 21 3.3 Sichere Umgebung .................................................................................................... 21

4 BENUTZERHANDBUCH FÜR DEN ENDANWENDER .................................................... 23 4.1 Sicherheitsfunktionen ................................................................................................. 23

4.1.1 SF1 - Hashberechnung und elektronische Signaturen ............................................ 24 4.1.2 SF2 - Hashverifikation und elektronische Signaturen .............................................. 26 4.1.3 SF3 - Eindeutige Anzeige der zu signierenden Daten ............................................. 29 4.1.4 SF4 - Schutz vor Hashwert Manipulationen ............................................................ 30 4.1.5 SF5 - Behandlung von OCSP Daten zur Zertifikatsvalidierung ............................... 30 4.1.6 SF6 - Anbringung von Zeitstempeln ........................................................................ 31 4.1.7 SF7 - Validierung von Zeitstempeln ........................................................................ 32 4.1.8 SF8 - Verwaltung der SFs mit der Konfigurationsdatei ............................................ 32 4.1.9 SF9 - Schutz vor Manipulation der Programmdatei ................................................. 33 4.1.10 SF10 - Entfernte Geräte ......................................................................................... 33 4.1.11 SF11 - Anzeige sicherheitsrelevanter Informationen ............................................... 34

4.2 Benutzerschnittstelle .................................................................................................. 35 4.2.1 TrayIcon ................................................................................................................. 35 4.2.2 Informationsdialog .................................................................................................. 36 4.2.3 Statusdisplay .......................................................................................................... 37 4.2.4 Multisignatureinstellungen ...................................................................................... 48 4.2.5 Detailanzeige .......................................................................................................... 49 4.2.6 Dateiexporte ........................................................................................................... 60 4.2.7 Fernsignatur ........................................................................................................... 67

4.3 Sicherheitshinweise und -empfehlungen .................................................................... 73 4.3.1 Fehleranzeige und -behandlung ............................................................................. 74 4.3.2 Automatische Prüfung von Dokumenten nach der Signatur .................................... 82 4.3.3 Überprüfung von Dokumenten vor der Signatur ...................................................... 83 4.3.4 Überprüfung von Dokumenten nach der Signatur ................................................... 83


5 BENUTZERHANDBUCH FÜR DEN ENTWICKLER ......................................................... 85 5.1 Sicherheitsfunktionen ................................................................................................. 85 5.2 Benutzerschnittstelle .................................................................................................. 85 5.3 Sicherheitshinweise und -empfehlungen .................................................................... 85

5.3.1 Fehlermeldung und -behandlung ............................................................................ 85 5.3.2 Wahl geeigneter Metadaten .................................................................................... 87 5.3.3 Informationspflichten zur Integritätsprüfung ............................................................ 87

6 ANHANG .......................................................................................................................... 88 6.1 Datendefinitionen ....................................................................................................... 88

6.1.1 XML.CONTENT ...................................................................................................... 89 6.1.2 XML.DOCUMENT .................................................................................................. 89 6.1.3 XML.SIGNATURE .................................................................................................. 90 6.1.4 XML.CERTIFICATE ................................................................................................ 94 6.1.5 XML.ATTRIBCERT ................................................................................................. 95 6.1.6 XML.OCSP ............................................................................................................. 96 6.1.7 XML.TIMESTAMP .................................................................................................. 97 6.1.8 XML.STOREPARAM .............................................................................................. 98 6.1.9 XML.PATH ........................................................................................................... 103 6.1.10 DOCUMENT.FORMAT ......................................................................................... 103 6.1.11 DOCUMENT.STATUS .......................................................................................... 104 6.1.12 SIGNATURE.STATUS .......................................................................................... 104 6.1.13 SIG.TIMESOURCE............................................................................................... 104 6.1.14 OCSP.STATUS .................................................................................................... 105 6.1.15 REVOCATION.STATUS ....................................................................................... 105 6.1.16 CERTOCSP.STATUS ........................................................................................... 105 6.1.17 CERTIFICATE.STATUS ....................................................................................... 106 6.1.18 VERIFICATION.STATUS...................................................................................... 106 6.1.19 TIMESTAMP.STATUS .......................................................................................... 107 6.1.20 SAK.STATUS ....................................................................................................... 107 6.1.21 READER.STATUS................................................................................................ 108 6.1.22 CARD.STATUS .................................................................................................... 108 6.1.23 BINARY.EXPORT ................................................................................................ 109 6.1.24 SIGNATURE.METHOD ........................................................................................ 109 6.1.25 HASH.METHOD ................................................................................................... 110

6.2 Applikationsschnittstelle ........................................................................................... 110 6.2.1 Grundlagen ........................................................................................................... 111 6.2.2 TSF-Protokoll ........................................................................................................ 111 6.2.3 Basis-Kommunikationsprotokoll ............................................................................ 112 6.2.4 Aktivierungsphase ................................................................................................ 112 6.2.5 Funktionen des TOE ............................................................................................. 114 6.2.6 Statusübergänge .................................................................................................. 124


6.3 NetSignerService ..................................................................................................... 127 6.3.1 Datentypen ........................................................................................................... 127 6.3.2 Authentisierungsphase ......................................................................................... 128 6.3.3 Zugriffsmethoden .................................................................................................. 128

6.4 Referenzen .............................................................................................................. 132 6.5 Glossar .................................................................................................................... 133




Tabellen Seite

Tabelle 6.1 - Einfache Datenformate ........................................................................................ 88 Tabelle 6.2 - DOCUMENT.FORMAT ...................................................................................... 103 Tabelle 6.3 - DOCUMENT.STATUS ....................................................................................... 104 Tabelle 6.4 - SIGNATURE.STATUS ....................................................................................... 104 Tabelle 6.5 - SIG.TIMESOURCE ............................................................................................ 104 Tabelle 6.6 - OCSP.STATUS ................................................................................................. 105 Tabelle 6.7 - REVOCATION.STATUS .................................................................................... 105 Tabelle 6.8 - CERTOCSP.STATUS ........................................................................................ 105 Tabelle 6.9 - CERTIFICATE.STATUS .................................................................................... 106 Tabelle 6.10 - VERIFICATION.STATUS ................................................................................. 106 Tabelle 6.11 - TIMESTAMP.STATUS ..................................................................................... 107 Tabelle 6.12 - SAK.STATUS .................................................................................................. 107 Tabelle 6.13 - READER.STATUS ........................................................................................... 108 Tabelle 6.14 - CARD.STATUS ............................................................................................... 108 Tabelle 6.15 - BINARY.EXPORT ............................................................................................ 109 Tabelle 6.16 - SIGNATURE.METHOD ................................................................................... 110 Tabelle 6.17 - HASH.METHOD .............................................................................................. 110 Tabelle 6.18 - Vordefinierte Selektoren .................................................................................. 117 Tabelle 6.19 - Statusübergänge ............................................................................................. 125




Abbildungen Seite

Abbildung 2.1 - Screenshot Setup - Einleitung ......................................................................... 15 Abbildung 2.2 - Screenshot Setup - Installationsart .................................................................. 16 Abbildung 2.3 - Screenshot Setup - Verzeichniswahl ............................................................... 16 Abbildung 2.4 - Screenshot Setup - Installationsprotokoll ......................................................... 17 Abbildung 2.5 - Screenshot Setup - Fertigstellung .................................................................... 17 Abbildung 4.1 - Screenshot TrayIcon ....................................................................................... 35 Abbildung 4.2 - Screenshot TrayMenü ..................................................................................... 35 Abbildung 4.3 - Screenshot TrayMenü - erweitert ..................................................................... 36 Abbildung 4.4 - Screenshot Informationsdialog ........................................................................ 36 Abbildung 4.5 - Screenshot Statusdisplay - Initialisierung......................................................... 37 Abbildung 4.6 - Screenshot Statusdisplay - Integrität verletzt ................................................... 37 Abbildung 4.7 - Screenshot Statusdisplay - Konfigurationsdatei veraltet .................................. 38 Abbildung 4.8 - Screenshot Statusdisplay - Inventarisierung .................................................... 39 Abbildung 4.9 - Screenshot Statusdisplay - Applikationsanmeldung ......................................... 39 Abbildung 4.10 - Screenshot Statusdisplay - Applikationsgrafik ............................................... 40 Abbildung 4.11 - Screenshot Statusdisplay - Datenblöcke geladen .......................................... 41 Abbildung 4.12 - Screenshot Statusdisplay - Attributzertifikat laden ......................................... 42 Abbildung 4.13 - Screenshot Dateiauswahldialog (Fachapplikation) ......................................... 43 Abbildung 4.14 - Screenshot Statusanzeige - Attributzertifikat geladen .................................... 43 Abbildung 4.15 - Screenshot Statusanzeige - Signaturbeginn .................................................. 44 Abbildung 4.16 - Screenshot Statusanzeige - Signatur nach PIN ............................................. 45 Abbildung 4.17 - Screenshot Statusanzeige - Signatur ausgeführt ........................................... 45 Abbildung 4.18 - Screenshot Statusdisplay - Verifikationsbeginn ............................................. 46 Abbildung 4.19 - Screenshot Statusdisplay - Verifikation durchgeführt ..................................... 46 Abbildung 4.20 - Screenshot Multisignatureinstellungen .......................................................... 48 Abbildung 4.21 - Screenshot Detailanzeige .............................................................................. 50 Abbildung 4.22 - Screenshot Detailanzeige - Navigationsbaum ............................................... 50 Abbildung 4.23 - Screenshot Detaildisplay - Kartenleser .......................................................... 52 Abbildung 4.24 - Screenshot Detaildisplay - Dokument ............................................................ 53 Abbildung 4.25 - Screenshot Detaildisplay - Signatur ............................................................... 54 Abbildung 4.26 - Screenshot Detaildisplay - Zertifikat ............................................................... 56 Abbildung 4.27 - Screenshot Detaildisplay - Attributzertifikat .................................................... 58 Abbildung 4.28 - Screenshot Detaildisplay - Zeitstempel .......................................................... 60 Abbildung 4.29 - Screenshot Export - Verzeichniswahl ............................................................ 61 Abbildung 4.30 - Screenshot Export – Exportverzeichnisinhalt ................................................. 62 Abbildung 4.31 - Screenshot Authentisierungsmodul - Freischaltung ....................................... 68 Abbildung 4.32 - Screenshot Authentisierungsmodul - Aktivierung ........................................... 68 Abbildung 4.33 - Screenshot Authentisierungsmodul - Aktiviert ................................................ 69 Abbildung 4.34 - Screenshot Authentisierungsmodul - Schutzfunktion ..................................... 69 Abbildung 4.35 - Screenshot Anzeigen unter Android .............................................................. 71 Abbildung 4.36 - Screenshot Fehleranzeigen unter Android ..................................................... 71 Abbildung 4.37 - Screenshot Anzeigen unter iOS ..................................................................... 72


Abbildung 4.38 - Screenshot Fehleranzeigen unter iOS ........................................................... 72 Abbildung 4.39 - Screenshot Anzeigen unter Windows 7 ......................................................... 73 Abbildung 4.40 - Screenshot Fehleranzeigen unter Windows 7 ................................................ 73 Abbildung 4.41 - Screenshot Statusanzeige - Integrität verletzt ................................................ 74 Abbildung 4.42 - Screenshot Statusanzeige - Konfigurationsdatei veraltet ............................... 75 Abbildung 4.43 - Screenshot Statusanzeige - Parametersatz unvollständig ............................. 76 Abbildung 4.44 - Screenshot Statusanzeige - Signaturkarte nicht gelesen ............................... 77 Abbildung 4.45 - Screenshot Statusanzeige - Schlüssellänge unbestimmt ............................... 77 Abbildung 4.46 - Screenshot Statusanzeige - Sicherheitseignung abgelaufen ......................... 78 Abbildung 4.47 - Screenshot Statusanzeige - Zertifikat nicht qualifiziert ................................... 79 Abbildung 4.48 - Screenshot Statusanzeige - Signaturzertifikat nicht vertrauenswürdig ........... 79 Abbildung 4.49 - Screenshot Statusanzeige - Signaturzertifikat noch nicht gültig ..................... 79 Abbildung 4.50 - Screenshot Statusanzeige - Signaturzertifikat nicht mehr gültig ..................... 80 Abbildung 4.51 - Screenshot Statusanzeige - Signaturzertifikat nicht lesbar ............................ 80 Abbildung 4.52 - Screenshot Statusanzeige - Attributzertifikat Ladefehler ................................ 81 Abbildung 4.53 - Screenshot Statusanzeige - Attributzertifikat Referenzfehler ......................... 81 Abbildung 4.54 - Screenshot Statusanzeige - Attributzertifikat noch nicht gültig ....................... 81 Abbildung 4.55 - Screenshot Statusanzeige - Attributzertifikat nicht mehr gültig ....................... 82 Abbildung 4.56 - Screenshot Statusanzeige - Signaturausführungsfehler ................................ 82 Abbildung 4.57 - Screenshot Statusanzeige - Urdokument verändert ....................................... 83 Abbildung 6.1 - Statusübergänge ........................................................................................... 125


1 Einleitung Dieses Dokument ist das Handbuch zur Signaturanwendungskomonente Infotech Signer, Version „V3.0 / Win32“. In Kapitel 2, „Installation und Programmstart“, vermittelt es die für alle Anwender des Produkts fundierte Kenntnisse zur eindeutigen Identifikation, zur Installation und zum sicheren Umgang mit dem Produkt. Kapitel 3, „Benutzerhandbuch - Allgemeines“, dient der weiteren Aufteilung des Handbuchs zur Ermittlung der für den Leser relevanten Teile. Es stellt die vorgesehene Einsatzumgebung und die zum sicheren Betrieb einzuhaltenden Maßnahmen vor. Kapitel 4, „Benutzerhandbuch für den Endanwender“ ist dem Endanwender gewidmet. Hier werden die Eigenschaften des Produkts, die implementierten Sicherheitsfunktionen und ihre Wirkungsweise dargelegt. Es enthält alle im Betrieb auftretenden Anzeigen und erklärt die verwendeten Symbole und Bedienelemente. Der Abschnitt „Dateiexporte“ zeigt die Verwendug der Exportfunktion und stellt den Inhalt der bei durchgeführten Exporten anfallenden Daten dar. Im Abschnitt „Fernsignatur“ findet man eine Erläuterung der zur Nutzung der Fernsignatur vorgesehenen Einstellmöglichkeiten und der Anzeigen auf Mobilgeräten oder entfernten Desktops. Der letzte Abschnitt des Kapitels, „Sicherheitshinweise und -empfehlungen“ enthält eine Beschreibung der im Fehlerfall auftretenden Anzeigen und implementierten automatischen Prüfungen. Es zeigt ferner die Möglichkeiten zur manuellen Prüfung der korrekten Signaturdurchführung. Kapitel 5, „Benutzerhandbuch für den Entwickler“, sowie der Anhang enthält weitere Zusatzinformationen, die für den Entwickler, der das Produkt in seine Anwendungen integrieren möchte, vorgesehen sind. Dieses Handbuch ist obligatorisch für den Evaluierungs- und Zertifizierungsprozess des TOE Infotech Signer und der NetSignerService Bibliotheken nach den CC. Es deckt die Anforderungen bezüglich der Vertrauenskomponente AGD_OPE.1 und AGD_PRE.1 ab.


2 Installation und Programmstart

2.1 Voraussetzungen Infotech Signer, Version „V3.0 / Win32“ ist eine Signaturanwendungskomponente (SAK) zur signaturgesetzkonformen Erstellung und Verifikation qualifizierter Signaturen in den Dokumentformaten RSA PKCS#7, PDF und XML-DSig. Es handelt sich um eine verbesserte und funktional erweiterte Version des Vorgängers Infotech Signer, Version „V2.0 / Win32”. Infotech Signer wurde zur Verwendung mit folgenden Betriebssystemen entwickelt:

• Windows 7 von Microsoft im 32-Bit Modus (bei 64-Bit Installationen enthalten) Die korrekte Installation des Systems wird vorausgesetzt. Der Rechner, auf dem Infotech Signer betrieben werden soll, muss über einen Intel 586 kompatiblen Prozessor und sollte zum Programmstart über mindestens 128 MB freien Arbeits-speicher (RAM) verfügen. Die Dateien des Infotech Signer belegen etwa 8,5 Megabyte Festplattenplatz. Zur Anfertigung von Signaturen werden mindestens ein Kartenlesegerät und eine Signaturkarte für qualifizierte Signaturen benötigt. Die zum Betrieb des Kartenlesegeräts erforderlichen Treiber müssen installiert sein. Die zur Verwendung geeigneten Kartenlesegeräte müssen über eine Tastatur zur sicheren PIN Eingabe verfügen. Infotech Signer unterstützt die Verwendung folgender Kartenlesegeräte:

• Cherry: SmartBoard xx44, Firmware-Version 1.04 (BSI.02048.TE.12.2004)

• Reiner SCT cyberJack pinpad, Version 3.0 (TUVIT.93107.TU.11.2004)

• Reiner SCT cyberJack e-com Version 3.0 (TUVIT.93155.TE.09.2008)

• Reiner SCT cyberJack e-com plus Version 3.0 (TUVIT.93156.TE.09.2008)

• Reiner SCT cyberJack RFID komfort, Version 2.0 (TUVIT.93180.TU.12.2011) Folgende bestätigte Signaturkarten werden unterstützt: D-Trust, TC TrustCenter:

• G&D: STARCOS 3.4 Health QES C1 (auf C2 erweitert) (BSI.02120.TE.05.2009 mit Nachtrag 1 vom 15.11.2010)

S-Trust:

• Gemalto: ZKA-Signaturkarte, Version 6.32 (TUVIT.93184.TU.11.2010 mit Nachtrag 1 vom 19.05.2011)


• Gemalto: ZKA-Signaturkarte, Version 6.32 M (TUVIT.93176.TU.05.2011)

Signtrust:

• G&D: STARCOS 3.2 QES, Version 2.0 (BSI.02114.TE.12.2008 mit Nachtrag 1 vom 08.03.2010)

TeleSec: • T-Systems: TCOS 3.0 Signature Card, Version 1.1

(TUVIT.93146.TE.12.2006 mit Nachtrag 1 vom 07.05.2010)

• T-Systems: TCOS 3.0 Signature Card, Version 2.0, Release 1/SLE78CLX1440P (SRC.00016.TE.11.2012)

Die vorgenannten Kartenlesegeräte und Signaturkarten genügen den Anforderungen des Signaturgesetztes. Die zugehörigen Bestätigungsurkunden sind in den Veröffentlichungen der Bundesnetzagentur verfügbar (siehe http://www.bundesnetzagentur.de). Der Betrieb mit anderen Kartenlesegeräten oder Signaturkarten ist möglich, liegt jedoch außerhalb der Bestätigung der SAK. Infotech Signer gestattet während der Signaturausführung die Anbringung von Zeitstempeln an die signierten Dokumente und die Statusüberprüfung verwendeter Zertifikate beim Aussteller. Beide Funktionen bedürfen der Unterstützung der Fachapplikation. Diese leitet die von Infotech Signer formulierten Anfragen an die jeweiligen Responder weiter und liefert die Antworten an den Infotech Signer zurück. Dazu ist eine Online-Verbindung erforderlich, die den Rechner, auf dem Infotech Signer ausgeführt wird, über das Internet mit den Respondern der Aussteller verbindet. Derartige Verbindungen sind über Firewalls abzusichern, die den Rechner vor unberechtigten Zugängen schützen und die Integrität des installierten Betriebssystems sicherstellen. Näheres dazu erfahren Sie im Kapitel 3.3, Sichere Umgebung. Infotech Signer kann nicht nur von lokalen Fachapplikationen, sondern auch von entfernten Arbeitsplätzen oder von Mobilgeräten (Smartphones oder Tablets) verwendet werden, sofern diese Geräte über eine geeignete Anwendung verfügen, die sie unter Verwendung der NetSignerService Bibliothek mit dem Infotech Signer über ein Netzwerk verbinden kann. Die Bibliothek ist in Version „1.0“ für folgende Systeme verfügbar:

• Mobilgeräte mit Android-Betriebssystem von Open Handset Alliance • Mobilgeräte mit iOS Betriebssystem von Apple • Arbeitsstationen mit Betriebssystem Windows 7 von Microsoft (im 32-Bit Modus)

Für diese Nutzung des Infotech Signer ist er zusammen mit einer speziellen Anwendung zu installieren, die seine Verwendung über das Netzwerk ermöglicht. Die Fachapplikation wird dann unter Verwendung der NetSignerService Bibliothek auf entfernten Arbeitsplätzen oder Mobilgeräten als App betrieben.


2.2 Auslieferung der SAK Infotech Signer wird in der Regel zusammen mit einer spezialisierten Fachanwendung ausgeliefert und installiert. Die Fachanwendung nutzt die SAK wie eine Signaturbibliothek. Die Auslieferung des Infotech Signer erfolgt i.d.R. per Webdownload von der Firmenhomepage des Herstellers der Fachanwendung. Der Download soll über einen SSL-gesicherten Kanal stattfinden, damit der Endanwender die Identität des Servers über das Serverzertifikat ermitteln kann. Bei der Verwendung von entfernten Arbeitsplätzen oder Mobilgeräten kann die Fachanwendung über den vorgenannten Vertriebsweg oder als App1 von einem Onlineshop (App Store für iOS Geräte oder Google Play für Android Geräte) bezogen werden. Infotech Signer ist auch als Entwicklerversion zur Verwendung in weiteren Fachanwendungen verfügbar. Die Entwicklerversion wird auf Anfrage mit weiteren Dokumentationen und Klassen zur Integration in Anwendungen auf einem Installationsmedium (CD-ROM) ausgeliefert. Bei Bezug über ein Installationsmedium ist sicherzustellen, dass die Sicherheitsmerkmale der Verpackung (Laminierungen und Siegel) unbeschädigt sind. Wenn Beschädigungen erkennbar sind, darf das Installationsmedium nicht verwendet werden. Sobald das Medium der Verpackung entnommen ist, muss es vor dem Zugriff unberechtigter Dritter geschützt werden.

2.3 Vorbereitungen zur Installation Benutzer sowie ggf. Administratoren und Wartungspersonal mit Zugang zu den Installationsdateien oder den installierten Dateien müssen vertrauenswürdig sein und den Anweisungen der Benutzerdokumentation Folge leisten. Vor der Installation ist sicherzustellen, dass das Betriebssystem frei von jedweder Schadsoftware (Viren, Trojaner und Backdoor-Programme) ist. Dazu sind geeignete Virenscanner mit aktuellen Virendefinitionsdateien zu verwenden. Wenn die Installation aus einem Backup wiederhergestellt wurde, ist ihre Integrität in jedem Fall vor der ersten Inbetriebnahme sicherzustellen (siehe 2.5, Überprüfung der Integrität). Des Weiteren sind für den gesamten Installationsprozess die im Abschnitt 3.3, Sichere Umgebung, genannten Maßnahmen einzuhalten.

1 Anwendungssoftware für Mobilgeräte (Smartphones oder Tablet-Computer)


2.4 Programminstallation Bei der Installation kann, je nach Installationsstand des Betriebssystems, die Vervollständigung der erforderlichen Laufzeitbibliotheken notwendig sein. Diese wird durch das Setupprogramm im Rahmen der Installation vorgenommen. Die Komponenten von Infotech Signer werden in ein Verzeichnis, zusammen mit der Fachanwendung, installiert. Das Verzeichnis kann im Rahmen des Setupprogramms frei gewählt werden. Die Installation beginnt mit der Aktivierung des Installationsprogramms. Dieses trägt i.d.R. den Namen Setup.exe. Es gibt eine Vielzahl möglicher Setupprogramme. Darunter auch solche, die für automatische Installationen (und Updates) vorgesehen sind (“unattended“ oder “silent“ Setups). Auch bei solchen Setupprogrammen ist die Integrität der SAK vor ihrer ersten Verwendung durch geeignete Maßnahmen sicherzustellen. Im Folgenden wird der Installationsablauf am Beispiel einer interaktiven Installation der Fachanwendung E-Form Plugin dargestellt. Das Setupprogramm zeigt zunächst eine kurze Einleitung:

Abbildung 2.1 - Screenshot Setup - Einleitung

Die Installation kann oftmals für einen einzelnen Benutzer oder für alle Benutzer der Arbeitsstation vorgenommen werden. Der folgende Dialog bietet die entsprechenden Auswahlmöglichkeiten:


Abbildung 2.2 - Screenshot Setup - Installationsart

Die Wahl des Zielverzeichnisses richtet sich nach den Anforderungen der Fachapplikation, kann aber zur Anpassung an spezielle Gegebenheiten angepasst werden:

Abbildung 2.3 - Screenshot Setup - Verzeichniswahl

Nach Aufnahme der änderbaren Installationsparameter wird die Installation durchgeführt und der Installationsfortschritt üblicherweise angezeigt und ggf. ein Installationsprotokoll angefertigt.


Abbildung 2.4 - Screenshot Setup - Installationsprotokoll

Zum Abschluss der Installation wird eine Meldung angezeigt, die über den Erfolg des Installationsvorgangs informiert. Die Bestätigung der Abschlussmeldung beendet das Setupprogramm.

Abbildung 2.5 - Screenshot Setup - Fertigstellung

Nach erfolgter Installation ist der Zugriff und die Verwendung der SAK durch den Benutzer sicherzustellen. Der Computer-Administrator räumt dem Endanwender die dazu nötigen Rechte ein.


2.5 Überprüfung der Integrität Infotech Signer besteht aus einer ausführbaren Programmdatei, einer Treiber-dll für Kartenlesegeräte und einer Konfigurationsdatei. Zur Prüfung der Integrität der Installation ist jede dieser drei Dateien mit einer separaten Signaturdatei signiert. Jede Signaturdatei trägt denselben Namen wie die signierte Datei, jedoch mit der zusätzlichen Endung “.p7s“. Alle 6 Dateien liegen zusammen in einem Installationsverzeichnis, das i.d.R. mit dem der Fachapplikation identisch ist. Die Integrität der Installation muss vor der ersten Verwendung mit dem Infotech Signer Integrity Tool (ITSigner.Check.exe) verifiziert werden. Das Infotech Signer Integrity Tool prüft die Signaturen und weist die Hashwerte der signierten Dateien zusammen mit den Prüfergebnissen aus. Der SHA-256 Hashwert der Programmdatei ITSigner.exe, Version „V3.0 / Win32“ lautet: 356470049e1c018a33e75ae3d3fb2502004d37750e542f46d7bf32f22368987c

Bei Nutzung der NetSignerService Bibliothek auf Mobilgeräten oder entfernten Arbeitsstationen erfolgt die Hashwertermittlung innerhalb der Bibliothek vor der ersten Verbindungsaufnahme zu einem Infotech Signer. Die Bibliothek zeigt den ermittelten Hashwert nur dann an, wenn ihre Unversehrtheit sichergestellt ist. Andernfalls wird eine Fehlermeldung angezeigt und die Bibliothek gesperrt. Auf Mobilgeräten wird zum Aufbau des sicheren Kanals zusätzliche Zufallsdaten (Entropie) benötigt, die aus dem vorausgesetzten Lagesensor bezogen werden. Bei Fehlfunktion des Lagesensors wird eine Fehlermeldung angezeigt und die Bibliothek gesperrt. Screenshots der Anzeigen finden sich in den Abschnitten 4.2.7.2.1 und 4.2.7.2.2. Die Hashwerte der Bibliothek sind unterschiedlich nach eingesetztem Betriebssystem und bei iOS auch nach der Fachapplikation. Sie lauten für:

• Android, Version „1.0“ ff0614c3156c1e5939c9ea7ae01b492d4c846068bf7a72b5c74148f27064475d

• iOS, Version „1.0“, mit „Zedal Mobil“, Version „1.10“, Build:346 86da92ab121f22bf53602b6e4e5c586525a76c544dac20b878654a3c6d7f98e1

• Windows 7, Version „1.0“ 3ff85919c33aeaa5c89c4b41292d0d81b5226f3e42b1a7d58c1a8707ca747460

Die Hashwerte können (außer bei iOS) auch mit anderen geeigneten Anwendungen berechnet, auf der Hersteller-Webseite https://www.infotech.de/cc eingesehen und bei Bedarf telefonisch erfragt werden. Die NetSignerService Bibliothek kann für Entwickler zur Integration in eigene Apps lizensiert werden. Für iOS (Apple Mobilgeräte) wird eine Objektdatei zur statischen Einbindung in eigene Apps ausgeliefert. Der SHA-256 Hashwert der Objektdatei lautet: 927dbd4b8c3f05d9d76797a08c22e3794bada1d7e0fc3f221d762d14bddab3e8

https://www.infotech.de/cc


Telefonische Unterstützung und Auskunft über die korrekten Hashwerte erhalten Sie bei der

Infotech Zentrale unter: +(49) 2361 9130 0

2.6 Starten der SAK Infotech Signer wird durch die sie verwendende Fachapplikation gestartet. Der Start erfolgt je nach Applikation ggf. verzögert, spätestens jedoch vor der ersten Ausführung oder Verifikation einer Signatur.

Sobald Infotech Signer gestartet ist, zeigt er in der Taskbar das Trayicon , über dessen Kontextmenü während der gesamten Programmlaufzeit die Statusanzeige und der Informationsdialog angefordert werden kann. Unmittelbar nach Programmstart führt Infotech Signer eine Reihe interner Prüfungen aus und zeigt deren Fortschritt auf der Statusanzeige. Näheres dazu ist im Abschnitt 4.2, Benutzerschnittstelle, zu finden. Wenn Infotech Signer die Signatur der beiliegenden Signaturdatei nicht verifizieren kann oder die Konfigurationsdatei veraltet ist, wird dieser Sachverhalt in der Statusanzeige angezeigt und jedwede Funktionalität eingestellt. Die Anzeige wird auf Bestätigung des Benutzers oder nach längstens 15 Sekunden automatisch beendet. Siehe dazu Abschnitt 4.3, Sicherheitshinweise und -empfehlungen. Nach erfolgreichem Abschluss der Prüfungen wird die Statusanzeige verborgen und erst auf Benutzeranforderung, bei Signatur- oder Verifikationsaktivität wieder angezeigt.

2.7 Betrieb der SAK Infotech Signer wird im Betrieb von der Fachapplikation als Child-Prozess wie eine Signaturbibliothek betrieben. Dazu erfolgt eine Anmeldung der Fachapplikation bei der laufenden Infotech Signer Instanz. Nach erfolgreicher Anmeldung übernimmt Infotech Signer das nach Fachapplikation zugewiesene Icon und den Handelsnamen aus der Konfigurations-datei und verwendet beides in der Taskbar und den Dialogköpfen. Ein Beispiel dafür findet man in Abbildung 4.4 - Screenshot Informationsdialog. Der zugewiesenen Handelsname, die verwendende Fachapplikation sowie weitere Kenndaten des Infotech Signer werden dort angezeigt.


2.8 Wartung und Pflege Die Integrität der Installation des Infotech Signer muss regelmäßig, mindestens jedoch monatlich, geprüft werden. Das Verfahren dazu ist im Abschnitt 2.5, Überprüfung der Integrität, beschrieben. Die in der Konfigurationsdatei enthaltenen Informationen (Sicherheitseignungen und Zertifikats-stämme) müssen stets auf aktuellem Stand gehalten werden. Um dies gewährleisten zu können, enthält die Konfigurationsdatei ein Ablaufdatum. Wenn dieses Datum überschritten ist, weist Infotech Signer auf diesen Sachverhalt hin und verweigert die weitere Ausführung (siehe 4.3.1.1, Startfehler). Die Aktualisierung der Konfigurationsdatei kann von der den Infotech Signer verwendenden Fachapplikation unterstützt werden. In diesem Fall sorgt sie für den Download und die Hinterlegung im Dateisystem. Andernfalls muss der Benutzer die Konfigurationsdatei und die zugehörige Signaturdatei manuell aktualisieren. Vor der Aktualisierung sind alle laufenden Instanzen der SAK zu beenden. Zudem müssen die Berechtigungen des Anwenders zur Aktualisierung hinreichen. Aktuelle Sätze aus Konfigurationsdatei und zugehöriger Signaturdatei können über die Firmenhomepage des Herstellerunternehmens (über einen sicheren Kanal) geladen werden.

2.9 Uninstallation Die Uninstallation des Infotech Signer erfolgt i.d.R. zusammen mit der Uninstallation der Fachanwendung durch deren Setupprogramm (bzw. dem mit installierten Uninstaller). Sie kann aber auch manuell durch Löschung der Dateien im Installationsverzeichnis vorgenommen werden.


3 Benutzerhandbuch - Allgemeines

3.1 Benutzerrollen Dieses Handbuch wendet sich an den Endanwender der SAK ebenso wie an den Entwickler, der Infotech Signer in einer Fachapplikation einsetzen möchte. Für den Endanwender enthält es die erforderlichen Informationen, um Infotech Signer innerhalb der bestätigten Umgebung sicher verwenden zu können. Es spezifiziert die erforderlichen Maßnahmen zur Herstellung der zulässigen Einsatzumgebung und den Umgang mit den Hilfsmitteln zur rechtssicheren Erstellung und Prüfung qualifizierter Signaturen. Dem Entwickler dient es als Leitfaden, wie die Dokumentation zu seiner Fachapplikation zu ergänzen ist, um den Endanwender in die Lage zu versetzen eine sichere Einsatzumgebung herzustellen, die Integrität der SAK vertrauenswürdig zu prüfen und sie sicher zu verwenden.

3.2 Betriebsmodi Infotech Signer genügt in der Standardkonfiguration den Anforderungen des Signaturgesetzes und der Signaturverordnung (SigG i.V.m. SigV). Die Standardkonfiguration wird nach jedem Programmstart angenommen. Infotech Signer kommuniziert zu jeder Zeit mit höchstens einer sie verwendenden Fachapplikation. Der gleichzeitige Betrieb mehrerer SAK Instanzen ist allerdings möglich. Jede den Infotech Signer verwendende Fachapplikation ist dann einer dedizierten Instanz zugeordnet.

3.3 Sichere Umgebung Infotech Signer verfügt über Mechanismen zur Prüfung der Integrität des eigenen Programmcodes, die jedwede Manipulation zuverlässig feststellten. Infotech Signer terminiert mit einer Fehlermeldung, falls der Programmcode verändert wurde. Um sicherzustellen, dass von der Fachapplikation das richtige Programm verwendet wird, ist die Integrität der Installation vor der ersten Inbetriebnahme und dann regelmäßig, wenigstens jedoch monatlich zu prüfen. Infotech Signer weist den Namen und Speicherort der eigenen Programmdatei in dem Informationsdialog aus. Es ist sicherzustellen, dass die Fachapplikation diese Programmdatei verwendet und dass eine Nachberechnung des Hashwertes über die Programmdatei den korrekten, öffentlich bekannten Wert aufweist. Das Verfahren zur Feststellung der Integrität ist in Abschnitt 2.5, Überprüfung der Integrität, beschrieben.


Die Arbeitsstation, d.h. der Rechner und das Betriebssystem mit dem Infotech Signer verwendet wird, muss frei von jedweder Schadsoftware (Viren, Trojaner, Backdoor-Programme) sein. Infotech Signer verfügt über keinerlei Mechanismus die Unversehrtheit des Betriebssystems festzustellen. Zur Diagnose sind geeignete Virenscanner mit aktuellen Virendefinitionsdateien zu verwenden. Rechner und Betriebssystem sind vor Eingriffen unberechtigter Dritter zu schützen, jede Kommunikation mit dem Internet ist über geeignet konfigurierte Firewalls zu führen. Im Fall des Einsatzes in einer Terminalserver-Umgebung muss der Server in einem zutrittsgeschützten Bereich betrieben und die Verbindung zwischen Terminalclient und Terminalserver zuverlässig verschlüsselt werden. Für den Terminalserver und den Terminalclient sind Sicherungsmaßnahmen zu ergreifen, wie für eine eigenständige Arbeitsstation. Der Endanwender muss zu jedem Zeitpunkt die volle Kontrolle über die eingelegten Speichermedien und Netzwerkfreigaben haben. Der Installationsort des Infotech Signer darf zu keiner Zeit durch unberechtigte Dritte erreichbar sein. Das bei Signaturvorgängen eingesetzte Kartenlesegerät ist vor Manipulationen Dritter zu schützen. Vor der Inbetriebnahme ist zu prüfen, ob die angebrachten Siegel unbeschädigt sind. Falls eine Beschädigung erkennbar ist, darf das betroffene Kartenlesegerät nicht zu Signaturzwecken verwendet werden. Die Geheimhaltung und Unversehrtheit des privaten Schlüsselmaterials obliegt der eingesetzten Signaturkarte. Die Verwendung der Signaturkarte ist personengebunden, die PIN zur Authentisierung ist vertraulich. Zu keiner Zeit darf die PIN weitergegeben, niedergeschrieben oder sonst irgendwie bekannt gemacht werden. Wenn Zweifel an der Vertraulichkeit der PIN bestehen, ist die Signaturkarte unverzüglich beim Aussteller zu sperren. Die Signaturkarte ist vor dem Zugriff unberechtigter Dritter zu schützen und muss sich stets im unmittelbaren Einflussbereich des Endanwenders befinden. Dieser Schutzbedarf besteht in gesteigertem Maß für Multisignaturkarten. Zur Signaturausführung freigeschaltete Signatur-karten dürfen den unmittelbaren Einflussbereich des Endanwenders zu keiner Zeit verlassen. Infotech Signer trägt in den angefertigten Signaturen die Uhrzeit des Rechners ein, auf dem sie ausgeführt wird. Generell wird als Zeitbasis Datum und Uhrzeit in UTC verwendet. Infotech Signer verfügt über keinerlei Mechanismus zur Feststellung der korrekten Uhrzeit. Der Anwender hat die zutreffende Einstellung des Datums, der Uhrzeit und der Zeitzone auf der verwendeten Arbeitsstation sicherzustellen.


4 Benutzerhandbuch für den Endanwender Dieses Handbuch beschreibt die Eigenschaften der SAK und enthält Screenshots typischer Anzeigen während der Programmausführung. Es enthält die zum sicheren Umgang mit der SAK erforderlichen Informationen. Abschnitt 4.2.6, Dateiexporte, enthält tiefere Detailinformationen zu den Ausgaben unter Bezugnahme auf die im Anhang 6.1, Datendefinitionen beschriebenen Definitionen. Die Schnittstellen der SAK werden im Folgenden mit E.APP1, E.APP2, E.DISPLAY und E.SYSTEM bezeichnet. Eine kurze Erklärung der Schnittstellen findet sich im Glossar am Ende des Handbuchs.

4.1 Sicherheitsfunktionen In diesem Kapitel sind die Sicherheitsfunktionen der SAK beschrieben. Diese Beschreibung ist in folgende dem ST, Kapitel 7.1 ff., “TOE summary specification“, entsprechenden Abschnitte unterteilt:

• SF1 - Hashberechnung und elektronische Signaturen

• SF2 - Hashverifikation und elektronische Signaturen

• SF3 - Eindeutige Anzeige der zu signierenden Daten

• SF4 - Schutz vor Hashwert Manipulationen

• SF5 - Behandlung von OCSP Daten zur Zertifikatsvalidierung

• SF6 - Anbringung von Zeitstempeln

• SF7 - Validierung von Zeitstempeln

• SF8 - Verwaltung der SFs mit der Konfigurationsdatei

• SF9 - Schutz vor Manipulation der Programmdatei

• SF10 - Entfernte Geräte

• SF11 - Anzeige sicherheitsrelevanter Informationen Hinweis: In dieser Dokumentation wird unterschieden zwischen der Verifikation (Prüfung der mathematischen Korrektheit) und der Validierung (Prüfung der Einhaltung von Profilen bei prüfbedürftigen Signaturen). Bei Validierungen2 wird stets das Kettenmodell gemäß Common.PKI verwendet:

Auch historische Signaturen sollen prüfbar sein. Diese können durchaus nach ungültig gewordenen Verfahren angefertigt worden sein (und wurden ggf. übersigniert). Die Verwendung

2 Ermittlung der Gültigkeit von Signaturen oder Zertifikaten.


eines nicht mehr sicherheitsgeeigneten Verfahrens oder abgelaufener Zertifikate wird nicht unterbunden, jedoch dem Benutzer zur Kenntnis gebracht (FDP_DSP.4). Auch historische Signaturen sollen prüfbar sein. Diese können durchaus nach ungültig gewordenen Verfahren angefertigt worden sein (und wurden ggf. übersigniert). Die Verwendung eines nicht mehr sicherheitsgeeigneten Verfahrens oder abgelaufener Zertifikate wird nicht unterbunden, jedoch dem Benutzer zur Kenntnis gebracht (FDP_DSP.4).

4.1.1 SF1 - Hashberechnung und elektronische Signaturen Eine elektronische Signatur wird erstellt, indem über die zu signierenden Daten ein Hashwert berechnet und dieser Hashwert mit einem privaten Schlüssel verschlüsselt wird. Bei Signaturen nach PKCS#7 besteht die Alternative, den Hashwert über den gesamten Datenblock für zu verschlüsseln (Signatur 1. Ordnung) oder die Hashmethode und den Hashwert in die authentisierten Attribute einzutragen und diese gemeinsam mit weiteren authentisierten Attributen (z.B. Signaturzeit) zu signieren (Signatur 2. Ordnung). Der TOE verwendet bei der Signaturerzeugung nach PKCS#7 stets die 2. Variante. XML-Signature verwendet ebenfalls die Signatur 2. Ordnung. Es werden zunächst die Reference-Knoten innerhalb des SignedInfo-Knotens ausgewertet, daraus Hashwerte gebildet und diese in die Reference-Knoten eingetragen. Aus dem SignedInfo-Knoten wird dann der Hashwert für die Signatur gebildet. PDF-Signaturen werden als weitere Variante der Signatur 2. Ordnung angefertigt. Hierbei wird das vorgelegte Dokument entsprechend den Vorgaben des mit ihm übergebenen Parameter-blocks durch incremental Update mit dem erforderlichen Signature-Objekt ausgestattet, in das die nach PKCS#7 im Format (DER, detached) berechneten Signaturdaten eingebettet werden. Die Anwendung des incremental Update-Verfahren sorgt für binäre Identität des Urdokuments. Zur Hashwertberechnung wird eine der Methoden SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 oder RIPE-MD 160 verwendet (FCS_COP.1 (SHA-1), FCS_COP.1 (SHA-224), FCS_COP.1 (SHA-256), FCS_COP.1 (SHA-384), FCS_COP.1 (SHA-512), FCS_COP.1 (RIPE-MD 160)). Nachdem der Hashwert berechnet wurde, initiiert der TOE dessen Signierung3 mit Hilfe einer Signaturkarte und geeignetem Kartenleser4 über die Schnittstelle E.CARD zum Kartenleser5.

Die elektronische Signatur wird in dem SSCD mit Hilfe des RSA- bzw. ECDSA-Algorithmus berechnet (FCS_COP.1 (RSA2-1024 bis 8192) und FCS_COP.1 (ECDSA)). Der TOE integriert den erhaltenen Signaturwert in den vorhandenen Datenbestand nach:

• PKCS#7

• XMLDsig, XAdES

• PDF

3 Signierung des Hashwerts mit dem privaten Schlüssel der Karte (Signaturschlüssel). 4 Es werden mehrere Kartenleser gleichzeitig unterstützt. 5 Ein externer Treiber stellt hierbei die Verbindung zu den Schnittstellen PC/SC oder CT-API oder einem

herstellerspezifischen Treiber her.


Durch die elektronische Signatur wird die Authentizität des Datenblocks sichergestellt. Durch das zusätzliche Hinzufügen des Zertifikats ist es zudem möglich den Datenblock zu verifizieren. Der TOE stellt sicher, dass der Datenblock während der Signaturausführung nicht unbemerkt verändert wird. Bevor die Berechnung eines Hashwerts startet, wird eine eindeutige Meldung angezeigt (über E.DISPLAY), dass nun eine elektronische Signatur erzeugt wird. Es wird zudem angezeigt, welche Daten signiert werden (FDP_DAU.2). Durch die Eingabe einer PIN am Kartenleser und dem notwendigen Besitz eines SSCD, ist es gewährleistet, dass nur autorisierte Personen eine elektronische Signatur erstellen können. Der TOE erlaubt es, dem signierten Datenblock optional einen Zeitstempel hinzuzufügen. Es wird eine Massensignatur unterstützt, sofern geeignete Signaturkarten zum Einsatz kommen (s. Folgeabschnitt). Wenn der Anwender einen Signaturvorgang abbricht, werden alle bereits erzeugten Signaturen verworfen und alle geladenen Dokumente in den Zustand vor der Signatur versetzt. Diese Sicherheitsfunktion benötigt eine Konfigurationsdatei (siehe SF8 - Verwaltung der SFs mit der Konfigurationsdatei) mit den derzeit gültigen Algorithmen und Parametern, sowie ein SSCD. Anderenfalls wird den Benutzer eine eindeutige Fehlermeldung angezeigt, dass eine Signatur nicht erstellt werden kann (siehe Abbildung 4.56 - Screenshot Statusanzeige - Signaturausführungsfehler). Wenn die Signatur auf einem nicht sicherheitsgeeigneten Algorithmus beruht, wird dies dem Benutzer in einer Warnmeldung angezeigt (siehe Abbildung 4.46 - Screenshot Statusanzeige - Sicherheitseignung abgelaufen). Die benutzte kryptographische Methode ist gemäß §17 Paragraph 1 bis 3 SigG 22.05.2001 in Verbindung mit Anhang 1, Paragraph 1 Nr. 2 SigV 22.11.2001 als geeignet identifiziert. Verwendung von Multisignaturkarten Neben den Standard-Signaturkarten, die für jede Signatur eine PIN-Eingabe erfordern, gibt es Multisignaturkarten, die nach der PIN-Eingabe eine beliebige Anzahl von Signaturen zulassen. Diese Karten werden u.a. in folgenden typischen Fällen eingesetzt:

• ein Benutzer muss eine Vielzahl an Dokumenten in kurzer Zeit signieren. Die Eingabe einer PIN pro Dokument wäre mühsam, zeitaufwendig und fehlerträchtig.

• an einer Arbeitsstation ist durch Kundenverkehr in kurzen Abständen eine Signatur zu leisten. Eine PIN-Eingabe in einer solchen Umgebung würde den Arbeitsablauf stören und hätte ggf. auch die Möglichkeit des leichteren Ausspähens der PIN zur Folge.

Um diese und weitere Fälle zu unterstützen, kann die Verwendung von Multisignaturkarten individuell eingestellt werden. Die Einstellungen werden an das Signaturzertifikat des SSCD


gebunden und können nur dann verändert werden, wenn eine Signaturkarte über ein Kartenlesegerät verbunden ist. Folgende paarweise exklusiven Einstellungen sind vorgesehen:

• Multisignaturen sperren (Standardeinstellung)

• Multisignaturen für die geladenen Dokumente zulassen

• Multisignaturen speziell zulassen, beschränkt auf: - maximale Zeit für Signaturausführungen, Vorgabe: Trennung nach 5 Minuten - maximale Anzahl der Gesamtsignaturen, Vorgabe: Anzahl der geladenen Dokumente

• Multisignaturen über die gesamte Programmlaufzeit zulassen Der Einstelldialog wird nach der ersten, vor der folgenden Signatur mit derselben Signaturkarte angezeigt. Bei dieser Signatur muss der Benutzer die Einstellungen bestätigen. Nach der Bestätigung der Einstellungen wird die Multisignatur aktiviert und beim ersten auftretenden Abbruchkriterium beendet. Lehnt der Benutzer die Multisignatur ab, wird eine einzelne Signatur getätigt. Die Einstellungen bleiben erhalten. Wenn für eine Karte keine Einstellungen vorliegen, es sich um eine Multisignaturkarte handelt und mit der Karte innerhalb der Vorgabezeit (5 Minuten) bereits eine Signatur getätigt wurde, wird der Benutzer auf die Möglichkeit der Multisignatur hingewiesen. Bestätigt der Benutzer die Multisignatur, wird diese mit dem Vorgabewert von 5 Minuten Nichtbenutzung aktiviert. Bei Ablehnung wird die Multisignatur gesperrt und muss später manuell aktiviert werden. Ist eine Ablaufzeit oder die Anzahl der Gesamtsignaturen angegeben, wird die Multisignatur nach einem dieser Abbruchkriterien gesperrt und muss manuell aktiviert werden. Wurde nur die Zeit für die Nichtbenutzung manuell eingestellt, verbleibt die Einstellung auch nach der Dauer der Nichtbenutzung und es wird bei der nächsten Signatur sofort die Bestätigung zur Multisignatur eingeholt. Die Multisignatur ist in jedem Fall beendet, wenn die Multisignaturkarte gezogen und damit die Verbindung zur Karte unterbrochen wurde. Die Verwendung eines nicht mehr sicherheitsgeeigneten Verfahrens oder abgelaufener Zertifikate wird nicht unterbunden, jedoch dem Benutzer zur Kenntnis gebracht (FDP_DSP.4).

4.1.2 SF2 - Hashverifikation und elektronische Signaturen Der TOE kann elektronische Signaturen verifizieren, die auf SHA-1, SHA-224, SHA-256, SHA384. SHA-512 oder RIPE-MD 160 Hashwerten beruhen. Die Verifikation wird durchgeführt, indem der Hashwert über die zu prüfenden Daten berechnet (FCS_COP.1 (SHA-1), FCS_COP.1 (SHA-224), FCS_COP.1 (SHA-256), FCS_COP.1 (SHA-384), FCS_COP.1 (SHA-512), FCS_COP.1 (RIPE-MD 160)) und anhand der angegebenen Signaturmethode, des im Dokument enthaltenen Signaturzertifikats und des ebenfalls enthaltenen Signaturwerts auf mathematische Korrektheit geprüft wird. Das anzuwendende Prüfverfahren wird in Abhängigkeit von der eingesetzten Signaturmethode wie folgt durchgeführt.


RSA (FCS_COP.1 (RSA2-1024 to 8192)) Der tatsächlich signierte Hashwert wird aus der Signatur mit Hilfe des RSA-Algorithmus (FCS_COP.1 (RSA2-1024 to 8192)) mit dem im Zertifikat enthaltenen öffentlichen Schlüssel entschlüsselt und mit dem übergebenen Hashwert verglichen. Das Prüfergebnis ist das Vergleichsergebnis zwischen dem signierten und dem nachberechneten Hashwert. ECDSA (FCS_COP.1 (ECDSA)) Bei der Signaturausführung mit diesem Signaturverfahren wird mit Hilfe des ECDSA-Algorithmus (FCS_COP.1 (ECDSA)) im ersten Teil einer Einwegfunktion unter Einbeziehung des privaten Schlüssels und des Hashwerts6 der Signaturwert, bestehend aus den Parametern r und s, erzeugt. Die Verifikation erfolgt durch Berechnung eines Punktes der Gruppe im zweiten Teil der Einwegfunktion unter Einbeziehung des im Zertifikat enthaltenen öffentlichen Schlüssels und des nachberechneten Hashwerts6. Das Prüfergebnis ist das Vergleichsergebnis zwischen der x-Koordinate des berechneten Punkts und dem in der Signatur enthaltenen Parameter r7.

Bei allen beschriebenen Prüfverfahren wird das Zertifikat des Erstellers stets mitgeführt (in PKCS#7, in XMLDsig mit XAdES und in PDF). Die SAK bekommt das zu prüfende „Dokument“ als Datenblock, sowie die Klasse des Blocks übergeben (PKCS#7, XMLDsig mit XAdES oder PDF). PKCS#7 Im Falle von PKCS#7 wird zunächst die ggf. vorhandene Base64-Transportkodierung entfernt, so dass die Rohdaten vorliegen. Auf diese wird ASN.1 angewandt und der Signaturwert extrahiert. Anschließend wird über den Datenblock der gewünschte Hashwert gebildet. Wenn die Signatur authentisierte Attribute enthält, wird geprüft, ob diese den ermittelten Hashwert enthalten und über alle authentisierten Attribute erneut der Hashwert gebildet. Die Signaturzeit wird den authentisierten Attributen, oder im Fall des Vorliegens eines gültigen Zeitstempels in den unauthentisierten Attributen, diesem entnommen. Dieser Vorgang wird wiederholt, wenn die Rohdaten wiederum im PKCS#7-Format vorliegen. XML Bei XML werden zunächst die Knoten ermittelt, die Signaturdaten nach dem XML-Signature-Standard enthalten. Die innerhalb der SignedInfo-Struktur enthaltenen Reference-Knoten werden ausgewertet und die XML-Daten entsprechend des XML-Signature-Standards gefiltert und nach Canonical-XML transformiert. Über die resultierenden Datenblöcke werden Hashwerte

6 Falls die Länge des Hashwerts die Länge der Gruppenordnung Ln übersteigt, werden in beiden Teilen der Einwegfunktion nur die Ln höchstwertigen Bits des Hashwerts verwendet. 7 Zu den Parametern r und s, sowie zum öffentlichen Schlüssel müssen weitere Bedingungen eingehalten sein, bei deren Nichterfüllung die Signatur ungültig ist.


gebildet und mit den Reference-Einträgen verglichen. Die SignedInfo-Struktur wird ebenfalls nach Canonical-XML transformiert. Über dieses Transformationsergebnis wird der Hashwert anhand der mit der Signaturmethode angegebenen Hashmethode nachberechnet. Die Signaturzeit wird ggf. aus den erweiterten Signaturdaten nach XAdES ermittelt. Dieser Vorgang wird über alle gefundenen Signaturknoten iteriert. PDF Der TOE erkennt die in PDF-Dokumenten als Signature Field, als Widget Annotation oder der Kombination von beidem (mit gemeinsamem Dictionary) angebrachten Signaturen. In dem gefundenen Dictionary befindet sich die Referenz auf das zugehörige Signature-Objekt, das wiederum den ByteRange enthält, über den sich die Signatur erstreckt. Eine mit diesem TOE verifizierbare Signatur ist mit Subfilter „adbe.pkcs7.detached“ angefertigt worden. Sie enthält im Feld Contents des Signature-Objects eine als HexString kodierte PKCS#7 Signatur im Format (DER, detached) . Diese wird zusammen aus dem im ByteRange angegebenen, signierten Dokumentteil der PKCS#7 Verifikation, wie oben beschrieben, zugeführt. Der dargestellte Vorgang wird über alle lokalisierten Signature-Objekte iteriert. In allen Fällen wird der Signaturwert anhand des nachberechneten Hashwerts und des öffentlichen Schlüssels des enthaltenen Zertifikats nach RSA (FCS_COP.1 (RSA2-1024 to 8192)) oder ECDSA (FCS_COP.1 (ECDSA)) wie beschrieben verifiziert. Anschließend wird die Zertifikatskette des verwendeten Signaturzertifikats aus dem in der Konfigurationsdatei enthaltenen Zertifikatsstamm ermittelt und nach Common PKI geprüft. Der TOE zeigt eine eindeutige Meldung an, ob die Validierung der nachberechneten Hashwerte die Korrektheit der Signatur nachweist und die signierten Daten authentisch sind (FDP_DAU.2). Durch die Verwendung einer internen Anzeige ist sichergestellt, dass der Status der Signaturprüfung und die Meta-Informationen über die Daten eindeutig angezeigt werden. Die Daten können optional für den Anwender exportiert werden, so dass sie in einem geeigneten externen Viewer zur Kontrolle nochmals angezeigt werden können. Im Falle von XML wird zu jedem gebildeten Hashwert eine eigene Datei exportiert. Das Ergebnis der Signaturprüfung wird ebenfalls der Anwendung zur Verfügung gestellt. Der TOE bietet die Möglichkeit, den Anwender, der die elektronische Signatur erstellt hat, zu identifizieren. Der Benutzer, der die elektronische Signatur mit dem TOE verifiziert, kann sich Kenndaten des für die Erzeugung der Signatur verwendeten Zertifikats anzeigen lassen (FDP_DAU.2) und es ebenfalls exportieren. Während der Verifikation wird der Aussteller des Zertifikats ermittelt und die Gültigkeit seines Zertifikats validiert. Wenn das Zertifikat ungültig ist, wird diese Information über E.DISPLAY angezeigt. Der Benutzer kann die Einholung von Gültigkeitsinformationen zu Signaturzertifikaten bekannter Aussteller mittels OCSP veranlassen. Erhaltene OCSP-Informationen werden angezeigt und können exportiert werden.


Wenn in den Daten ein Signaturzeitstempel enthalten ist, wird dieser ebenfalls angezeigt und dazu verwendet, zu prüfen, ob das Signaturzertifikat zum Zeitpunkt der Signaturerstellung gültig war. Grundsätzlich wird die Prüfung mit der in den Daten kodierten Signaturzeit durchgeführt. Diese ist i.d.R. die Systemzeit, zu der die Signatur ausgestellt wurde. Falls keine Zeit verfügbar ist, wird die aktuelle Systemzeit verwendet. Diese Sicherheitsfunktion benötigt eine Konfigurationsdatei (siehe SF8) mit vertrauenswürdigen Zertifikatsstämmen und den derzeit gültigen Algorithmen und Parametern. Eingelesen wird die Konfigurationsdatei über E.SYSTEM. Wenn eine geprüfte Signatur auf einem unbekannten oder zum Prüfzeitpunkt nicht sicherheits-geeigneten Algorithmus oder Parameter beruht, wird dies in der Detailauskunft zur Signatur angezeigt und die Signatur wird als ungültig ausgewiesen. Die Sicherheitsfunktionalität wird über E.APP1 oder E.APP2 aufgerufen. Über E.APP1 läuft auch die Kommunikation mit der Applikation. So werden die Netzwerkzugriffe über E.APP1 an die Applikation weitergeben. Alle Bildschirmausgaben finden über E.DISPLAY statt, um den Benutzer über z.B. Fehler und Betriebszustände zu informieren. Wenn eine Signatur basierend auf einem veralteten oder unbekannten kryptografischen Algorithmus während der Verifikation erkannt wird, liefert die Verifikation das korrekte Ergebnis und dieser Umstand wird angezeigt (FDP_DSP.4). Die benutzte kryptographische Methode ist gemäß §17 Paragraph 1 bis 3 SigG 22.05.2001 in Verbindung mit Anhang 1, Paragraph 1 Nr. 2 SigV 22.11.2001 als geeignet identifiziert.

4.1.3 SF3 - Eindeutige Anzeige der zu signierenden Daten Der TOE stellt sicher, dass der Inhalt eines Datenblocks eindeutig durch die Anzeige von Meta-Daten über E.DISPLAY identifizierbar ist (FDP_DSP.1.1). Die Metainformationen beinhalten keine versteckten oder aktiven Inhalte (FDP_DSP.1.2 und FDP_DSP.1.3). Prinzipiell können alle Dateitypen signiert werden, da die Signaturkomponente intern diese (bis auf XML-Daten) nur als „Datenblock“ behandelt. Datenblock und Meta-Daten werden der SAK zusammen übergeben und in demselben Ablagefach gespeichert, so dass ein unmittelbarer Zusammenhang hergestellt werden kann und erhalten bleibt. Bei Bedarf liegen die Daten an einer externen Schnittstelle an (E.SYSTEM), die dann mit einem für dieses Format speziellen Viewer (nicht innerhalb der Evaluierung) betrachtet werden können. Im Falle von XML werden die Daten nach Anwendung der Filter- und Transformationsregeln nach XML-Signature exportiert, die auch bei der Signatur zum Einsatz kommen. Für den SignedInfo-Block und jeden Reference-Knoten wird eine eigene Datei erstellt.


4.1.4 SF4 - Schutz vor Hashwert Manipulationen Nachdem die elektronische Signatur erstellt wurde (siehe SF1), verifiziert der TOE diese mit Hilfe des öffentlichen Schlüssels aus dem Zertifikat der Signaturkarte (FDP_ITC.1 und FCS_COP.1 (RSA2 1024 to 8192) und FCS_COP.1 (ECDSA))8. Wenn die Verifikation nicht zu dem Ergebnis „Signatur gültig“ führt, wurde der Hashwert bei der Übertragung vom SSCD verändert und es wird eine eindeutige Meldung ausgegeben. Durch den Vergleich des Hashwerts, der für die Erstellung der Signatur berechnet wurde, und dem Hashwert, der vom SSCD für die Erstellung der elektronischen Signatur verwendet wurde, ist sichergestellt, dass die Daten zum und vom SSCD nicht manipuliert wurden (FTP_ITC.1). Die Signierung des Datenblocks (die Erstellung der Transport-Datenstruktur) wird nicht weiter durchgeführt, wenn die Überprüfung der Signatur fehlschlägt. Dieses wird dem Benutzer angezeigt.

4.1.5 SF5 - Behandlung von OCSP Daten zur Zertifikatsvalidierung Der TOE ermöglicht es, OCSP Informationen in die Prüfung eines Zertifikats mit einzubeziehen. Der Zugriff auf den OSCP Dienst erfolgt über die Applikation. Der TOE erstellt die Anfrage und übergibt diese der Anwendung mit der zugehörigen URL. Die Applikation führt die konkrete Anfrage durch und stellt die OCSP Antwort bereit. Damit der TOE eine OCSP Antwort mit einbeziehen kann, muss die elektronische Signatur der Antwort verifiziert werden. Die OCSP Antwort wird von einem OCSP Dienst bereitgestellt bzw. steht zwischengespeichert schon zur Verfügung. Eine OCSP Antwort zu einem bereits geprüften Zertifikat wird über die Lebenszeit der Instanz des TOE bis maximal zu der in der Antwort hinterlegten Gültigkeitszeit der Antwort vorrätig gehalten. Der OCSP Anfrage wird ein Zufallswert mitgegeben, der in der zugehörigen Antwort zurückgeliefert wird. Stimmen die Werte nicht überein, wird die Antwort verworfen. Die Gültigkeit der Antwort wird durch die Verifikation der Signatur sichergestellt (FDP_ITC.2 (1)). Die Verifikation besteht aus der mathematischen Prüfung der Signatur der OSCP Antwort gegen das in der Antwort enthaltene Responder Zertifikat. Zu dem Responderzertifikat muss eine Zertifikatskette erstellt werden können, deren Wurzelzertifikat mit einem der aus der Konfigurationsdatei bekannten Wurzelzertifikate identisch ist. Zur Erstellung der Zertifikatskette verwendet der TOE die Zertifikate aus der Konfigurationsdatei. Die Signatur der OCSP Antwort basiert auf den Algorithmen spezifiziert in (FCS_COP.1 (SHA-1), FCS_COP.1 (SHA-224), FCS_COP.1 (SHA-256), FCS_COP.1 (SHA-384), FCS_COP.1 (SHA-512) oder FCS_COP.1 (RIPE-MD 160)) und FCS_COP.1 (RSA2 1024 to 8192). Falls der TOE nicht in der Lage sein sollte die Signatur zu verifizieren, wird die OCSP Antwort nicht importiert und eine entsprechende Meldung ausgegeben. Eine gültige OCSP Antwort wird vom TOE zur weiteren Verwendung zwischengespeichert. Wenn der TOE die OCSP Information zur Verifikation eines Zertifikats benutzt, wird die OCSP Signatur geprüft. Die Signatur basiert auf o.g. Hashes. Für die Verifikation wird der Hash der

8 Der verwendete Algorithmus wird über das Konfigurationsfile, welches eine Aufstellung über die aktuell gültigen

Algorithmen und Parameter beinhaltet, festgelegt.


signierten Daten berechnet, der Original-Hash aus der Signatur mit dem RSA-Algorithmus extrahiert (FCS_COP.1 (RSA2 1024 to 8192)) und der öffentliche Schlüssel aus dem OCSP Signierzertifikat verwendet. Anschließend wird noch das Zertifikat des Erstellers der OCSP Antwort verifiziert (FCS_COP.1 (RSA2 1024 to 8192)). Nach Prüfung der elektronischen Signatur wird eine entsprechende Meldung über die Gültigkeit der OCSP Antwort ausgegeben (FDP_DAU.2) und diese im Rahmen der Signaturverifikation (SF2) angezeigt. Weiterhin kann der Inhalt der OCSP Antwort mit dem entsprechenden Zertifikat angezeigt werden. Die URL für die OCSP Anfrage wird über die in der Konfiguration hinterlegte Zuordnung zum Ausstellerzertifikat ermittelt. OCSP-Anfragen werden über E.APP1 an die Applikation weitergeben. Alle Bildschirmausgaben finden über E.DISPLAY statt, um den Benutzer über z.B. Fehler und Betriebszustände zu informieren.

4.1.6 SF6 - Anbringung von Zeitstempeln Der TOE ermöglicht den Einsatz von Zeitstempeln. Hierzu wird ein externer Zeitstempeldienst verwendet. Der Zugriff auf den Zeitstempeldienst erfolgt über die Applikation. Der TOE generiert die Anfrage und übergibt diese der Applikation. Diese entscheidet darüber, welcher konkrete Zeitstempeldienst in Anspruch genommen wird und stellt die Antwort bereit. Die Korrektheit des Zeitstempels wird durch den TOE sichergestellt. Der TOE verifiziert die elektronische Signatur des Zeitstempels mit dem öffentlichen Schlüssel des Zertifikats, das benutzt wurde, den Zeitstempel zu signieren (FDP_ITC.2 (2)). Die Verifikation besteht aus der mathematischen Prüfung der Signatur der TSP Antwort gegen das in der Antwort enthaltene Responder Zertifikat. Das Responderzertifikat muss gültig sein. Die Signaturprüfung erfolgt durch Vergleich des nachberechneten Hashwerts der Signatur, der auf SHA-1, SHA-224, SHA-256 SHA-384, SHA-512 oder RIPE-MD 160 (FCS_COP.1 (SHA-1), FCS_COP.1 (SHA-224), FCS_COP.1 (SHA-256), FCS_COP.1 (SHA-384), FCS_COP.1 (SHA-512), FCS_COP.1 (RIPE-MD 160)) basiert, mit dem in der Signatur enthaltenen Hashwert, der mit dem öffentlichen Schlüssel des Zeitstempel-Signierzertifikats nach dem RSA-Algorithmus (FCS_COP.1 (RSA2 1024 to 8192)) aus dem Signaturwert extrahiert wird. Antworten zu Zeitstempelanfragen werden nur dann akzeptiert, wenn diese mit einem Zertifikat signiert wurden zu dem eine Zertifikatskette erstellt werden kann, die der Validierung nach dem Kettenmodell gemäß Common-PKI standhält. Zur Erstellung der Zertifikatskette verwendet der TOE ausschließlich Zertifikate der in der Konfigurationsdatei enthaltenen Zertifikatstämme. Nachdem der Zeitstempel importiert wurde, wird dieser in die Daten integriert. Über E.APP1 läuft die Kommunikation mit der Applikation. Zeitstempelanfragen werden über E.APP1 an die Applikation weitergeben. Alle Bildschirmausgaben finden über E.DISPLAY statt, um den Benutzer über z.B. Fehler und Betriebszustände zu informieren.


4.1.7 SF7 - Validierung von Zeitstempeln Der TOE verifiziert die elektronische Signatur des Zeitstempels mit dem öffentlichen Schlüssel aus dem Zertifikat mit dem der Zeitstempel signiert wurde. Das Zertifikat, mit dem der Zeitstempel signiert wurde, muss für den TOE verifizierbar sein. Er ist dann verifizierbar, wenn zu ihm eine Zertifikatskette erstellt werden kann, die der Validierung nach dem Kettenmodell gemäß Common-PKI standhält. Zur Erstellung der Zertifikatskette verwendet der TOE ausschließlich Zertifikate der in der Konfigurationsdatei enthaltenen Zertifikatstämme. Die Signatur kann auf SHA-1, SHA-224, SHA-256 SHA-384, SHA-512 oder RIPE-MD 160 Hashwerten beruhen. Für die Verifizierung wird der Hashwert der signierten Daten mit den in FCS_COP.1 (SHA-1), FCS_COP.1 (SHA-224), FCS_COP.1 (SHA-256), FCS_COP.1 (SHA-384), FCS_COP.1 (SHA-512), FCS_COP.1 (RIPE-MD 160) spezifizierten Algorithmen berechnet und mit dem in der Signatur enthaltenen Hashwert verglichen, der mit dem öffentlichen Schlüssel des Zeitstempel-Signierzertifikats nach dem RSA-Algorithmus (FCS_COP.1 (RSA2 1024 to 8192)) aus dem Signaturwert extrahiert wird. Das Ergebnis der Zeitstempelprüfung und die im Zeitstempel enthaltenen Informationen werden dem Anwender angezeigt (FDP_DAU.2). Weiterhin kann das Zertifikat mit dem der Zeitstempel signiert wurde angezeigt werden (FDP_DAU.2.2).

4.1.8 SF8 - Verwaltung der SFs mit der Konfigurationsdatei Variable Programmkonfigurationen werden anhand eines signierten Konfigurationsfiles bereitgestellt, das über E.SYSTEM eingelesen wird. Das umfasst die Einstellungen zur Sicherheitseignung von Parametern (FMT_SMF.1). Das Programm sieht weiterhin eine Aktualisierung der Konfigurationsdatei vor (FMT_SMF.1). Die Konfigurationsdatei besitzt eine festgelegte Gültigkeitsdauer, nach deren Ablauf diese nicht mehr geladen wird und das Programm mit einer entsprechenden Meldung (FDP_DAU.2) den Start verweigert. Das Konfigurationsfile wird bei jedem Programmstart geladen und anhand einer digitalen Signatur verifiziert (FCS_COP.1 (SHA-256) und FCS_COP.1 (RSA1 1024 to 8192)). Falls kein Konfigurationsfile gefunden wird, wird der Anwender darauf hingewiesen, ein solches zur Verfügung zu stellen. Die Signatur des Konfigurationsfiles wird vom TOE verifiziert und nur bei Korrektheit wird das Konfigurationsfile geladen und die Parameter werden übernommen und angewandt (FMT_MOF.1). Die folgenden Parameter werden durch das Konfigurationsfile festgelegt:

• Gültigkeit/Ablaufdatum des Konfigurationsfiles Nach diesem Datum wird das Konfigurationsfile vom Programm nicht mehr geladen und muss durch ein aktuelleres ersetzt werden.


• Tabelle mit den gültigen Hash-Algorithmen und deren Laufzeit bzw. Ablaufdatum ihrer Sicherheitseignung9.

• Tabelle mit den gültigen Verschlüsselungs-Algorithmen (RSA und ECDSA), Parametern (Schlüssellänge) und dem Ablaufdatum ihrer Sicherheitseignung9.

• Zertifikatsstämme bekannter Zertifikatsaussteller in Dateiform.

• Tabelle mit einer Zuordnung von Zertifikatsstämmen zu Responder-URLs für die OCSP Abfrage.

• Tabelle mit sprachspezifischen Strings für andere Sprachen außer de-DE (optional).

• Tabelle mit einwegverschlüsselten Applikationsnamen und Passwörtern zur Aktivierung

• Tabelle mit ergänzenden OIDs, deren Kurz- und Langname, soweit nicht bereits in den Bibliotheken hinterlegt.

• Tabelle mit XML-IDs für XML-Signature. Da die SAK ohne die Kenntnis von Schemadateien arbeitet, wird die Festlegung weiterer ID-Attribute und ihrer URI benötigt. Diese werden ggf. hier über die Konfiguration ergänzt.

Alle Bildschirmausgaben finden über E.DISPLAY statt, um den Benutzer über z.B. Fehler und Betriebszustände zu informieren.

4.1.9 SF9 - Schutz vor Manipulation der Programmdatei Die Programmdatei und die zugehörige Konfigurationsdatei sind vom Hersteller signiert. Das Programm verfügt über den zugehörigen öffentlichen Schlüssel und verifiziert bei Programmstart die mathematische Korrektheit der Signatur. Schlägt die Verifikation fehl, wird der Anwender auf diesen Umstand hingewiesen und das Programm verweigert die weitere Ausführung. (FCS_COP.1 (SHA-256) und FCS_COP.1 (RSA1 1024 to 8192), FPT_TST.1). Alle Bildschirmausgaben finden über E.DISPLAY statt, um den Benutzer über z.B. Fehler und Betriebszustände zu informieren.

4.1.10 SF10 - Entfernte Geräte Bevor der TOE zur Fernsignatur oder -validierung verwendet werden kann, muss das entfernte Gerät zunächst erfolgreich identifiziert und die Kenntnis eines hinterlegten Benutzernamens mit zugeordnetem Passwort und der Fernzugriffs-PIN nachgewiesen werden. Dazu ist jedes Gerät mit einem eindeutigen Zertifikat und zugehörigem privaten Schlüssel ausgestattet, der auf dem Gerät erzeugt und verschlüsselt hinterlegt wurde. Zum Aufbau des sicheren Kanals wird der Benutzername klarschriftlich ausgetauscht. In der Aushandlung der Sitzung erfolgt eine SRP Authentisierung nach RFC 5054 unter Verwendung des Zufallszahlengenerators (FCS_RNG.1) auf Basis des Passworts. Dabei werden das

9 Die Verwendung von Hash-Algorithmen sowie von Verschlüsselungsalgorithmen und –Parametern zur Signaturausführung wird nach Ablauf ihrer Sicherheitseignung nicht unterbunden, jedoch dem Benutzer durch eine eindeutige Warnmeldung zur Kenntnis gebracht (FDP_DAU.2).


Gerätezertifikat und das des TOE (Signer) ausgetauscht. Wenn das vom NetSignerService in der Authentisierung verwendete Passwort nicht mit dem für den Benutzer hinterlegten übereinstimmt, kommt der gesicherte Kanal nicht zustande und die Verbindung wird abgebaut (FIA_UAU.2.1 (1)). Vor dem weiteren Datenaustausch prüft der TOE (NetSignerService), ob das vorgelegte Zertifikat des Kommunikationspartners (Infotech Signer) vertrauenswürdig ist. Falls dies nicht zutrifft, baut der NetSignerService die Verbindung ab. Wenn der durch Benutzername und Passwort gesicherte Kanal zustande kommt, nimmt der TOE (Signer) die Fernzugriffs-PIN entgegen, die unmittelbar vor der Aktivierung der Signaturkarte (durch PIN-Eingabe (FIA_UID.2.1)) als pseudozufällige 6-stellige Ziffernfolge erzeugt und dem Benutzer angezeigt wurde (FTP_ITC.1 (REMOTE)). Der TOE (Signer) antwortet mit einer gleichförmigen Fehlermeldung und baut den gesicherten Kanal ab, wenn mindestens eine der folgenden Situationen eintritt:

• Der Benutzername ist unbekannt (FIA_UID.2), • Der Zugriff erfolgt außerhalb des optional hinterlegten Gültigkeitszeitraums (FIA_ATD.1) • Das Gerätezertifikat ist dem Benutzer nicht zugeordnet oder gesperrt (FIA_AFL.1) • Das Signaturzertifikat ist dem Benutzer nicht zugeordnet • Die Fernzugriffs-PIN stimmt nicht mit der im Arbeitsspeicher hinterlegten PIN überein

(FIA_UAU.2.1 (2)) Es werden stets alle vorgenannten Prüfungen ausgeführt, bevor die Fehlermeldung übertragen und der Kanal abgebaut wird, um Rückschlüsse auf den internen Zustand des TOE zu erschweren. Wenn alle Prüfungen erfolgreich durchlaufen werden, jedoch die Fernzugriffs-PIN abweicht, wird ein Fehlerzähler (FIA_AFL.1.1) inkrementiert. Falls er den in der Benutzerkonfigurationsdatei hinterlegten Schwellwert erreicht, wird eine entsprechende Meldung angezeigt und jede weitere Verbindungsaufforderung für eine Sperrzeit oder bis zur Freigabe durch Quittierung der Warnmeldung abgelehnt (FIA_AFL.1.2). Der Schwellwert des Fehlerzählers kann innerhalb des Wertebereichs 1..10 (Voreinstellung: 3) und die Sperrzeit im Wertebereich 1..99999 Sekunden (Voreinstellung 900) gewählt werden. Falls die übertragene Fernzugriffs-PIN mit der im Speicher hinterlegten übereinstimmt, ist der Benutzer als Karteninhaber identifiziert und kann die Funktionalität der remote Signatur und Verifikation nutzen. Eine erfolgreiche Identifikation setzt den Fehlerzähler auf den 0 zurück.

4.1.11 SF11 - Anzeige sicherheitsrelevanter Informationen Zur Verwendung des TOE (Signer) in der Fernsignatur wird ihm zuvor ein einzelner Kartenleser zugeordnet, den er samt eingelegter SSCD verwaltet. Nachdem sich der Inhaber einer Multisignaturkarte durch PIN-Eingabe als Besitzer identifiziert hat, zeigt der TOE (Signer) eine (animierte) Bereitschaftsmeldung und erwartet die Verbindungsaufnahme von einem entfernten Gerät.


Wenn der TOE (Signer) von entfernten Geräten kontaktiert wird und die vorgezeigte Fernzugriffs-PIN die vorkonfigurierte Anzahl (Voreinstellung: 3) in Folge von der im Speicher befindlichen Pseudozufallszahl abweichen, wird ein Warnhinweis in Form eines Dialogs (FDP_DSP.3.1) angezeigt und jede weitere Verbindungsaufforderung bis zum Ablauf der vorkonfigurierten Sperrzeit (Voreinstellung: 900 Sekunden) oder bis zur Bestätigung des Dialogs abgelehnt. Während jeder neuen Signaturausführung wird durch den TOE (NetSignerService) auf dem entfernten Gerät ein entsprechender Hinweis angezeigt (FDP_DSP.2.1). Dieser Hinweis kann von der aufrufenden Applikation weder verändert noch unterdrückt werden.

4.2 Benutzerschnittstelle Im Folgenden sind die Anzeigen und Bedienelemente der SAK beschrieben. Die Gestaltung und Farbgebung der Dialoge ist von dem verwendeten Betriebssystem und Oberflächeneinstellungen abhängig. Die folgenden Screenshots wurden unter Windows 7 mit Standarddialogeinstellungen vorgenommen. In diesem Abschnitt wird die reguläre Arbeitsweise und die zugehörigen Anzeigen dargestellt. Zu ggf. auftretenden Fehlersituationen und deren Handhabung finden Sie nähere Hinweise im Abschnitt 4.3, Sicherheitshinweise und -empfehlungen.

4.2.1 TrayIcon Infotech Signer erzeugt zu Programmstart ein Trayicon, welches während der gesamten Programmlaufzeit bestehen bleibt:

Abbildung 4.1 - Screenshot TrayIcon

Zu dem TrayIcon gehört ein TrayMenü. Durch Klick mit der rechten Maustaste auf das TrayIcon wird die Anzeige des TrayMenüs ausgelöst. Das TrayMenü enthält Einträge zur Anzeige der Statusanzeige und des Informationsdialogs:

Abbildung 4.2 - Screenshot TrayMenü


Infotech Signer kann in den regulären Arbeitszuständen nur von der ihn verwendenden Applikation beendet werden. In besonderen Fällen, unter Abbruch der Verbindung mit der Applikation, kann Infotech Signer manuell durch den Benutzer beendet werden. Ist dies der Fall, wird das Menü um den Menüpunkt „Beenden“ erweitert, dessen Betätigung zur Beendigung des Infotech Signer führt:

Abbildung 4.3 - Screenshot TrayMenü - erweitert

Durch Klick mit der linken Maustaste auf das TrayIcon oder durch Aktivierung des Menüpunkts „Statusanzeige“ im TrayMenü wird die Statusanzeige aktiviert und im Vordergrund dargestellt.

4.2.2 Informationsdialog Die Anzeige des Informationsdialogs erfolgt durch Aktivierung des Traymenüpunktes „Über Infotech Signer“ und führt zur Ausgabe der Versionsinformationen, des Speicherortes der Programmdatei der SAK und des in der Konfigurationsdatei hinterlegten Ablaufdatums:

Abbildung 4.4 - Screenshot Informationsdialog


4.2.3 Statusdisplay Das Statusdisplay besteht aus einer Gruppe von Anzeigeelementen, die über den Zustand der SAK Auskunft erteilen. Die Gruppe besteht aus einer Liste der Kartenlesegeräte, der Ablagefächer, einer Dialogfläche und einem Statusbalken mit einer kleinen Darstellungsfläche für ein weiteres Icon an der linken Seite. Während der Startphase sind noch keine Kartenlesegeräte bekannt und alle Ablagefächer leer. Die Dialogfläche dient zur Informationsausgabe und bei Bedarf zur Entgegennahme von Benutzerentscheiden. Der Statusbalken zeigt den aktuellen Gesamtzustand der SAK:

Abbildung 4.5 - Screenshot Statusdisplay - Initialisierung

Während der Startphase (Reset) erfolgen die programminternen Prüfungen. Wenn dabei das Fehlen einer Komponente oder der zugehörigen Signatur festgestellt wird oder die Verifikation der Signatur einer Komponente fehlschlägt, wird dies in der Dialogfläche angezeigt:

Abbildung 4.6 - Screenshot Statusdisplay - Integrität verletzt

Es werden die Programmdatei, die Konfigurationsdatei und die Kartentreiber-Bibliothek geprüft und anhand der zugehörigen Signaturdateien verifiziert. Die möglichen Prüfergebnisse lauten:


• “ungeprüft“ Das Prüfergebnis wurde nicht festgestellt. Dieses Ergebnis tritt regulär nicht auf. Es besteht der Verdacht der Programmanipulation!

• “OK“ Die vorstehende Datei ist authentisch

• “nicht lesbar“ Die vorstehende Datei wurde nicht gefunden oder kann nicht gelesen werden.

• “Signatur nicht lesbar“ Die Signaturdatei zu der vorstehenden Datei wurde nicht gefunden oder kann nicht gelesen werden.

• “verändert“ Die Verifikation der vorstehenden Datei ist fehlgeschlagen.

• “Schreibschutz versagt“ (nur Konfigurationsdatei) Die Einrichtung des Schreibschutzes für diese Datei ist fehlgeschlagen.

• “Datenlesefehler“ (nur Konfigurationsdatei) Beim Einlesen der Daten sind Fehler aufgetreten. Die Datei ist unvollständig oder hat das falsche Format.

In der Startphase wird ferner die Aktualität der Konfigurationsdatei geprüft. Ist sie veraltet wird dies mit dem in der Konfigurationsdatei enthaltenen Ablaufdatum auf der Dialogfläche dargestellt:

Abbildung 4.7 - Screenshot Statusdisplay - Konfigurationsdatei veraltet

Wenn eine der beiden vorangegangenen Fehlersituationen eintritt, beendet sich Infotech Signer nach Betätigung der Schaltfläche „OK“ sofort, längstens jedoch nach 15 Sekunden selbsttätig. Andernfalls erfolgt die Inventarisierung, bei der die in der Konfigurationsdatei enthaltenen Informationen weiterverarbeitet und die verfügbaren Kartenlesegeräte ermittelt werden:


Abbildung 4.8 - Screenshot Statusdisplay - Inventarisierung

Nach durchgeführter Inventarisierung sind die angeschlossenen Kartenlesegeräte bekannt und ihre Namen und Zustände werden in der Liste der Kartenlesegeräte angezeigt. Anschließend wird die Kommunikation mit der Applikation aufgenommen und deren Anmeldung erwartet.

Abbildung 4.9 - Screenshot Statusdisplay - Applikationsanmeldung

Die Anzeige stellt ein gefundenes Kartenlesegerät dar. Der Treiber zu dem Kartenlesegerät wurde noch nicht geladen, eine möglicherweise vorhandene Signaturkarte wurde noch nicht bestimmt. Der Name des Kartenlesergeräts wird in dem angezeigten Eingabefeld dargestellt. In der Liste der Kartenlesegeräte können simultan bis zu 3 Kartenlesegeräte angezeigt werden. Falls mehr Kartenlesegeräte erkannt werden, erhält die Liste Scrollemente ( und ) zur Navigation. Jeder Listeneintrag besteht aus:

• Einer laufenden Nummer, beginnend mit 1

• Symbol für den Zustand von Kartenleser / Treiber, entsprechend READER.STATUS 0 Undefiniert Kartenlesertreiber wurde noch nicht geladen 1 Bereit Treiber geladen, Kartenleser verbunden 2 Fehler Fehlerzustand im Treiber aufgetreten


• Symbol für den Zustand der Signaturkarte, nach CARD.STATUS 0 Undefiniert Der Zustand wurde noch nicht bestimmt 1 SingleClose Einfachsignaturkarte, geschlossen 2 SingleOpen Einfachsignaturkarte, geöffnet 3 MultiClose Mehrfachsignaturkarte, geschlossen 4 MultiOpen Mehrfachsignaturkarte, geöffnet 5 Fehler Fehlerzustand eingetreten

• Der Anzeige des Kartenlesergerätenamens, wie er an die Applikation weitergegeben und von Ihr zur Benennung des für einen Signaturvorgang zu verwendenden Kartenlesegeräts verwendet wird. Der Hintergrund der Anzeige wird in Abhängigkeit von der Verwendung der Signaturkarte und ihrem Zustand eingefärbt. Weiß Leerlaufzustand, Signaturkarte geschlossen Cyan Kartenlesegerät zur Signaturausführung ausgewählt Gelb Signaturkarte zur Signaturausführung geöffnet Rot Leerlaufzustand, Signaturkarte geöffnet

Wenn die Anmeldung der Applikation fehlschlägt oder nicht innerhalb einer Minute durchgeführt ist, beendet sich der Infotech Signer. Nach erfolgreicher Anmeldung wird der Anmeldename der Applikation in die Titelleiste integriert und Infotech Signer durch die Applikation nutzbar. Abhängig von der angemeldeten Applikation kann eine Grafik unterhalb der Titelleiste, unterhalb der Statuszeile, am linken oder am rechten Fensterrahmen integriert werden. Die Grafik enthält keine aktiven Elemente und bleibt während der Programmlaufzeit bestehen.

Abbildung 4.10 - Screenshot Statusdisplay - Applikationsgrafik

Zur Durchführung oder Verifikation von Signaturen übergibt die Applikation einen oder mehrere Datenblöcke mit Meta- und Parameterdaten. Die Datenblöcke werden mit ihren Begleitdaten in Ablagefächer hinterlegt und die Metadaten zusammen mit den Bearbeitungszuständen in der Liste der Ablagefächer angezeigt.


Abbildung 4.11 - Screenshot Statusdisplay - Datenblöcke geladen

In der Liste der Ablagefächer können simultan bis zu 5 Ablagefächer dargestellt werden. Falls mehr als 5 Ablagefächer verwendet werden, erhält die Liste Scrollelemente ( und ) zur Navigation. Jeder Listeneintrag besteht aus

• Einer laufenden Nummer, beginnend mit 1

• Symbol für den Verarbeitungszustand in Abhängigkeit vom geladenen Datenblock Bei Dokumenten nach DOCUMENT.STATUS 0 unbearbeitet Dokument ist unbearbeitet 1 wird signiert Dokument wird gerade signiert 2 wird verifiziert Dokument wird gerade verifiziert 3 signiert Dokument ist signiert 4 geprüft Dokument ist verifiziert 5 signiert und geprüft Dokument ist signiert und verifiziert 6 ungültig Dokument ist ungültig Bei Zertifikaten nach CERTIFICATE.STATUS (nur Verifikation) 0 undefiniert Zertifikat ist unbearbeitet 1 gültig Zertifikat ist gültig 2 ungültig Zertifikat ist ungültig

• Symbol für das Prüfergebnis in Abhängigkeit vom geladenen Datenblock Bei Dokumenten nach VERIFICATION.STATUS 0 undefiniert Dokument ist ungeprüft 1 gültig Dokument ist geprüft und gültig 2 ungültig Dokument ist geprüft und ungültig 11 bestreitbar Dokument ist unvollständig validiert Bei Zertifikaten nach CERTOCSP.STATUS 0 ungeprüft Es ist noch keine OCSP Prüfung erfolgt 1 gut Zertifikat ist beim Aussteller als gültig bekannt 2 zurückgerufen Zertifikat wurde beim Aussteller zurückgerufen 3 unbekannt Zertifikat ist beim angefragten Aussteller nicht bekannt 4 abfragefehler Es konnte keine gültige Antwort eingeholt werden


5 aussteller unbekannt Der Aussteller des Zertifikats ist nicht bekannt 6 verifikationsfehler Fehler bei Verifikation des Responderzertifikats

• Der Anzeige der Metadaten zu dem im Ablagefach befindlichen Datenblock

• Dem Navigationselement zur Anzeige der Detailinformation zu den im Ablagefach befindlichen Daten (siehe 4.2.5, Detail).

4.2.3.1 Statusanzeige bei Signaturausführung Zur Durchführung von Signaturaufträgen wird das zu verwendende Kartenlesegerät von der Applikation benannt. Sofern die zur Signaturausführung erforderlichen Parameter vorliegen, stellt Infotech Signer die Verbindung zum benannten Kartenlesegerät her und ermittelt die Eigenschaften der Signaturkarte. Der Eintrag des für den Signaturvorgang verwendeten Kartenlesegeräts wird durch Einfärbung des Hintergrunds hervorgehoben. Wenn die Signaturkarte gelesen werden konnte und zur Multisignatur geeignet ist, wird dies durch den Einstelldialog zur Multisignatur angezeigt, sofern die Einstellungen nicht bereits innerhalb der letzten 5 Minuten vorgenommen wurden und die eingestellten Beschränkungen noch erfüllt sind. Der Dialog und die Einstellmöglichkeiten sind im Abschnitt 4.2.4, Multisignatureinstellungen, beschrieben. Wenn das Signaturzertifikat den Hinweis auf ein Attributzertifikat enthält, kann der Benutzer ein vorhandenes Attributzertifikat durch die Applikation hinzufügen lassen:

Abbildung 4.12 - Screenshot Statusdisplay - Attributzertifikat laden

Bei Bejahung des Dialogs fordert Infotech Signer die Applikation zur Übermittlung eines Attributzertifikats auf. Die Applikation lässt einen entsprechenden Dialog zum Öffnen einer Datei erscheinen und übermittelt die in der Datei befindlichen Daten zur SAK.


Abbildung 4.13 - Screenshot Dateiauswahldialog (Fachapplikation)

Infotech Signer nimmt den Dateiinhalt entgegen und prüft, ob es sich dabei um ein Attributzertifikat handelt, ob es das Signaturzertifikat referenziert und gültig (nicht abgelaufen) ist. Wenn das Attributzertifikat den Prüfungen genügt, wird dies wie folgt angezeigt:

Abbildung 4.14 - Screenshot Statusanzeige - Attributzertifikat geladen

Zur Aufnahme des Attributzertifikats in die Signaturen ist der vorstehende Dialog zu verneinen.


Wenn das zu verwendende Zertifikat und ggf. das Attributzertifikat für den Signaturvorgang festgelegt sind, führt Infotech Signer die Signatur für alle in den Ablagefächern befindlichen Dokumente durch. Dabei kann die Signaturkarte nicht gewechselt werden. Zu einer Signaturausführung muss die Signaturkarte durch Benutzereingabe (PIN) geöffnet vorliegen. Wenn es sich bei der Signaturkarte um eine Einzelsignaturkarte (silbernes Schloss) handelt, ist die PIN zu jeder Signatur einzugeben. Falls es sich jedoch um eine Mehrfachsignaturkarte handelt (goldenes Schloss), kann der Zustand bereits vorliegen und die Signaturkarte wird ohne weitere Nachfrage zur Signaturausführung verwendet. Auch Multisignaturkarten sind mindestens bei der ersten Signaturausführung durch PIN- Eingabe zu öffnen. Wenn die Signaturkarte die eingegebene PIN ablehnt, die PIN nicht innerhalb der vorgegebenen Zeit eingegeben wurde, oder andere korrigierbare Fehler auftreten, kann der Benutzer die PIN-Eingabe wiederholen. Das Auftreten nicht korrigierbarer Fehler, wie das Entfernen der Signaturkarte, führen zum Abbruch des gesamten Signaturauftrags und zum Verwerfen aller in dem aktuellen Signaturauftrag erzeugten Signaturen. Die folgende Anzeigesequenz zeigt die Ausführung eines Signaturauftrags:

Abbildung 4.15 - Screenshot Statusanzeige - Signaturbeginn


Abbildung 4.16 - Screenshot Statusanzeige - Signatur nach PIN

Abbildung 4.17 - Screenshot Statusanzeige - Signatur ausgeführt

Zum Abschluss des Signaturauftrags ist die Übergabe der signierten Daten an die Applikation zu bestätigen. Der Benutzer kann Details zu den geladenen Daten zu jeder Zeit durch Anforderung der Detailanzeige einsehen. Die Detailanzeige ist zu jeder Zeit zwischen der Datenübernahme der Rohdaten, mindestens bis zur Übergabe der Ergebnisdaten, verfügbar. Die Details nach Signaturausführung enthalten zu jedem Dokument nur die Daten zu der gerade angefertigten Signatur, nicht zu bereits vor der Signaturausführung im Dokument vorhandenen Signaturen. Alle Signaturen können durch einen unmittelbar folgenden Verifikationsauftrag untersucht werden, soweit dies durch die Applikation unterstützt wird.


4.2.3.2 Statusdisplay bei Verifikationsausführung Zur Durchführung von Verifikationsaufträgen ist kein Kartenlesegerät erforderlich. Die angeschlossenen Kartenlesegeräte verbleiben in ihrem Zustand, es findet kein Datenaustausch mit einer Signaturkarte statt. Die Applikation belässt vorhandene, gerade signierte Dokumente in den Ablagefächern oder überträgt zu prüfende Dokumente oder Zertifikate und leitet dann den Auftrag ein. Infotech Signer informiert den Benutzer über die Durchführung des Auftrags durch folgende Anzeige:

Abbildung 4.18 - Screenshot Statusdisplay - Verifikationsbeginn

Zu Beginn der Verifikation werden zunächst alle Signaturen ermittelt und anschließend verifiziert. Nach Abschluss des Verifikationsauftrags ist die Übertragung des Ergebnisses an die Applikation zu bestätigen.

Abbildung 4.19 - Screenshot Statusdisplay - Verifikation durchgeführt


In diesem Zustand kann der Benutzer die Details zur Verifikation einsehen, weitere Prüfungen und auch Exporte vornehmen. Die Detaildaten stehen in demselben Umfang wie nach einer Signaturausführung für alle ermittelten Signaturen zur Verfügung

4.2.3.3 Prüfergebnis und Prüfzeitpunkt Nach einer Signaturausführung wird das Ergebisdokument verifiziert. Die Verifikation erstreckt sich nur auf gerade ausgeführte Signatur. Bei Verifikationsaufträgen werden alle Signaturen und Zertifikate der vorgelegten Prüfobjekte (Dokumente und / oder Zertifikate) geprüft. In der Statusanzeige wird für jedes Prüfobjekt das Symbol des schlechtesten Prüfergebnisses aller durchgeführten Prüfmethoden (Validierung, OCSP-Prüfung) angezeigt.

Wenn noch keine Prüfung durchgeführt wurde, wird dies mit dem leeren Platzhalter angezeigt. Nur wenn bei keiner der durchgeführten Prüfungen ein Fehler erkannt wurde, kann die Signatur oder das Zertifikat gültig sein. Wenn eine der Prüfungen Inkonsistenzen aufweist (z.B. weil ein Dokument nach der Signatur verändert wurde oder das Zertifikat zum Prüfzeitpunkt zurückgerufen war) wird dies mit dem Symbol angezeigt. Ergeben sich bei der Prüfungen Warnungen, jedoch keine Fehler, wird dies mit symbolisiert. In diesem Fall konnte die Güligkeit einer Signatur oder eines Zertifikats nicht vollständig bestimmt werden (z.B. weil das Signaturzertifikat nicht mitsigniert wurde oder beim Zertifikatsausstelle nicht bekannt ist). Die Gültigkeit eines Dokuments kann dann ggf. nur aus weiteren Informationen (etwa dem Signaturzeitpunkt einer Archivierung) ermittelt werden. In jedem Fall sollten die Detailinformatinen zu dem Prüfobjekt (Zertifikate und Signaturen von Dokumenten) eingesehen und zur Bewertung herangezogen werden (siehe Abschnitt 4.2.5, Detailanzeige). Die Gültigkeit von Signaturen und Zertifikaten werden zu Prüfzeitpunkten festgestellt. Dokumente tragen i.d.R. ihren Prüfzeitpunkt in Form eines Zeitstempels oder einer mitsignierten Systemzeit (die Signaturzeit). Fehlt dieser Prüfzeitpunkt im Dokument, oder wurde ein Zertifikat zur Prüfung vorgelegt, wird die aktuelle Systemzeit als Prüfzeitpunkt verwendet. Der Prüfzeitpunkt wird während der Prüfung bestimmt und die Zeitquelle bei Signaturen in deren Detailanzeigen ausgewiesen (siehe Abschnitt 4.2.5.4, Einzelauskunft (Signatur)). Er kann nicht durch die Fachapplikation oder Benutzerangaben beeinflusst werden. Für Zertifikate erhält man die Gültigkeitsinformation stets zur aktuellen Systemzeit. Die Prüfergebnisse werden anhand der durchgeführten Prüfungen in der Statusanzeige verdichtet am Prüfobjekt angezeigt. Wenn eine Prüfmethode wie die OCSP Prüfung noch nicht angewandt wurde, wird sie in das Ergebnis nicht einbezogen. Durch die Validierung der Objekte zusammen mit der optionalen Einbeziehung der Zustandsinformation ihrer Zertifikate vom ihren Ausstellern erhält man eine umfassende Aussage über die Gültigkeit der Signaturen.


4.2.4 Multisignatureinstellungen Der Dialog zu Multisignatureinstellungen wird nach der Prüfung des Kartenlesegeräts und der Signaturkarte vor der Signaturausführung angezeigt, wenn:

• das Kartenlesegerät verfügbar ist und eine Multisignaturkarte enthält – und –

• in dem aktuellen Signaturvorgang mehr als die nach der wirksamen Einstellung zuge-lassene Anzahl von Signaturen zu leisten sind – oder – die letzte Signatur mit diesem Kartenlesegerät unter Verwendung derselben Signatur-karte durchgeführt und innerhalb der vergangenen 5 Minuten in dem Dialog nicht der Einzelsignaturmodus gewählt wurde (Option: Multisignatur nicht zulassen).

Der Dialog gestattet die Änderung der Handhabung von Multisignaturkarten. Voreingestellt ist die Nutzung von Multisignaturkarten als Einzelsignaturkarte. D.h. für jede Signaturausführung ist die Eingabe der PIN zur Authentisierung des Benutzers gegen die Signaturkarte erforderlich und die Multisignaturkarte wird nach jeder Signatur geschlossen. Dieses Verhalten ermöglicht anderen Applikationen zwischen den Signaturausführungen über dasselbe Kartenlesegerät auf dieselbe Signaturkarte zuzugreifen.

Abbildung 4.20 - Screenshot Multisignatureinstellungen

Der Dialog zeigt den Namen des zur Signaturausführung festgelegten Kartenlesegeräts und einige Einstellmöglichkeiten zur Nutzung der Multisignaturkarte.


Die Optionen bedeuten im Einzelnen

• „Multisignatur nicht zulassen (PIN-Eingabe für jede Signatur erforderlich)“ Das Setzen dieser Option entspricht der Voreinstellung. Zwischen Signaturausführungen wird die Signaturkarte geschlossen und steht anderen Applikationen zur Verfügung.

• „Multisignatur zulassen, nur für die geladenen Dokumente“ Diese Option bewirkt das Halten der Signaturkarte in geöffnetem Zustand für die Anzahl von Signaturen, die zur Signaturausführung auf allen Ablagefächern erforderlich ist.

• „Multisignatur zulassen, bis zur automatischen Trennung nach <Zeitangabe> oder nach höchstens <Anzahl> Signaturausführungen“. Diese Option gestattet die Einstellung spezieller Beschränkungen der Nutzung der Signaturkarte. Die Karte bleibt geöffnet, bis die eingestellte Zeit verstrichen ist oder die eingestellte Anzahl zugelassener Signatur-ausführungen erschöpft ist.

• „Multisignatur zulassen, solange die Signaturkarte gesteckt bleibt“ Durch Anwahl dieser Option bleibt die Multisignaturkarte nach erfolgter Authentisierung in geöffnetem Zustand gehalten, bis sie entfernt oder das Programm beendet wird.

Die Anwahl der letzten Option versetzt Infotech Signer in einem nicht Signaturgesetzkonformen Betriebszustand, weil die zur Signatur vorgelegten Dokumente vor der Signatur ggf. nicht eingesehen werden können. Für signaturgesetzkonformen Betrieb darf sie nicht verwendet werden. Die Felder zur Einstellung der Zeit beschränken die zugelassene Nutzungszeit der geöffneten Signaturkarte. Die Karte wird nach Verstreichen der eingestellten Zeit geschlossen. Die Einstellung von „0“ bei allen Feldern bedeutet, dass die Nutzungszeit unbeschränkt ist. Das Feld zur Einstellung der zugelassenen Signaturausführungen ist mit der Anzahl gefüllter Ablagefächer vorbelegt. Die Einstellung von „0“ bedeutet, dass die Anzahl der Signatur-ausführung nicht beschränkt ist. Das Feld hat einen Wertebereich von „0“ bis „9999“. Bei Bejahung des Dialogs werden die getätigten Einstellungen wirksam. Wird er verneint, gilt die Voreinstellung bis der laufende Signaturvorgang abgeschlossen ist, jedoch wird die wiederholte Anzeige des Dialogs ermöglicht.

4.2.5 Detailanzeige Die Detailanzeige besteht aus einer Gruppe von Anzeigeelementen, die wiederum in zwei Darstellungsformen angezeigt werden: Dem Navigationsbaum im oberen Fensterbereich und der Detailanzeige im unteren Fensterbereich. Die in der Detailanzeige dargestellte Information bezieht sich auf das im Navigationsbaum ausgewählte Element.


Abbildung 4.21 - Screenshot Detailanzeige

Die in den Detailanzeigen angebrachten Schaltflächen für Benutzeraktionen (hier: “Untersuchen“, “Export“ und “Anzeigen“) sind nur nach ausgeführter Signatur oder Verifikation verwendbar. In allen anderen Zuständen führt ihre Verwendung zu einer Fehlermeldung.

4.2.5.1 Navigationsbaum Der Navigationsbaum enthält diejenigen Elemente zu den Einzelauskünfte angezeigt werden können. Wurzel des Baums ist der Knoten „Objektspeicher“. Unter diesem befinden sich die in den Ablagefächern gespeicherten Objekte.

Abbildung 4.22 - Screenshot Detailanzeige - Navigationsbaum

Die Objekte werden mit einem Kürzel ihres Typs (in eckigen Klammern) und ausgewählten Kenndaten angezeigt. Mögliche Typen sind:


• [PC/SC] Kartenleser Im Navigationsbaum wird der Kartenlesername angezeigt.

• [P7], [PDF] oder [XML] Dokument Das Dokument wurde von der Applikation übergeben oder ist bereits signiert. Angezeigt werden die übergebenen Metadaten.

• [SIG] Signatur Angezeigt wird der X509-Name des Inhabers des verwendeten Signaturzertifikats, „/“, die zugrundegelegte Signaturzeit, „/“, die Signaturrolle (nur bei PKCS#7-Signaturen), „/“, die Signatur ID (nur bei XML-Signaturen), „/“ und das Signaturformat („PKCS#7“, „PDF“ oder „XML-DSig“)

• [ATZ] Attributzertifikat Angezeigt wird der der Holder und das Ende der Gültigkeit des Zertifikats. Der Holder ist entweder der X509-Name des Zertifikatsausstellers und der Seriennummer des Zertifikats, der den Eigentümer identifiziert oder der X509-Name des Eigentümers, wie er in seinem Zertifikat eingetragen ist

• [TST] Zeitstempel Bei einem Zeitstempel wird nur der mitsignierte Erzeugungszeitpunkt angezeigt.

• [*] (Aus der Applikation vorgegeben) Die Applikation kann ein beliebiges Objekt (Datenblock) mit beliebigem Typkennzeichen zur Signatur nach PKCS#7 vorlegen. Das angegebene Typkennzeichen wird zusammen mit den übergebenen Metadaten angezeigt.

Vor einem Objekteintrag wird ein Expansionssymbol angezeigt, welches bei Anzeige der abhängigen Objekte als Minuszeichen ( ), sonst geschlossen als Pluszeichen ( ) dargestellt wird.

4.2.5.2 Einzelauskunft (Kartenleser) Das Anzeigeelement enthält mindestens den Button „Neu verbinden“. Bei Betätigung des Buttons wird der Treiber reinitialisiert und der Status aktualisiert. Dabei geht der Zustand einer etwa freigeschalteten Multisignaturkarte verloren. Sofern der Kartenleser eine Multisignaturkarte enthält, wird zusätzlich der Button „Multisignatur“ angezeigt. Betätigung dieses Buttons bewirkt die Anzeige des Multisignaturdialogs.


Abbildung 4.23 - Screenshot Detaildisplay - Kartenleser

Die angezeigten Detailinformationen sind:

• der systemweit eindeutige Name des Kartenlesers • der Zustand des Kartenlesertreibers (nicht verbunden/bereit/…) • der Zustand einer ggf. eingelegten Signaturkarte (nicht verbunden/bereit/…)

Wenn eine Signaturkarte eingelegt ist und gelesen wurde, wird zusätzlich angezeigt:

• der Typ der Signaturkarte • die Seriennummer der Signaturkarte (soweit ermittelbar) • die stärkste unterstützte Signaturmethode der Signaturkarte • das Ende der Sicherheitseignung der ermittelten Signaturmethode

Der Benutzer kann folgende Operationen auf einem Kartenleser auslösen:

• „Neu Verbinden“ Diese Operation führt eine Reinitialisierung des Kartenlesertreibers durch. Eine ggf. verbundene und Signaturkarte wird getrennt und erneut angeschlossen. Dabei geht eine ggf. vorhandene Authentisierung gegen die Signaturkarte verloren. Durch den Neuanschluss wird ermittelt, ob sich im Kartenleser eine Signaturkarte befindet. Falls das zutrifft, wird das Zertifikat ausgelesen und die Zertifikatskette ermittelt. Details zu den Zertifikaten sind in dem Zweig des Kartenlesers einsehbar.

• „Multisignatur“ Betätigung dieser Schaltfläche löst die Anzeige des Multisignaturdialogs aus (siehe Abbildung 4.20 - Screenshot Multisignatureinstellungen). Diese Schaltfläche wird nur angezeigt, wenn eine geschlossene Multisignaturkarte erkannt wurde.

4.2.5.3 Einzelauskunft (Dokument) Dieses Anzeigeelement enthält bis zu drei Buttons für die Benutzeraktionen „Untersuchen“, „Export“ und „Anzeigen“, die Gruppenbezeichnung der dargestellten Detailinformationen „Dokument“ und die Detailinformationen selbst. Die Einzelauskunft ist einsehbar, sobald ein Dokument von der Applikation übergeben wurde, bis das zugeordnete Ablagefach wieder geleert wird.


Die Leerung des Ablagefachs erfolgt durch die Applikation, jedoch frühestens nach der Bestätigung der Datenübergabe nach ausgeführter Signaturanfertigung oder Validierung.

Abbildung 4.24 - Screenshot Detaildisplay - Dokument

Alle angezeigten Detailinformationen werden von der Applikation zusammen mit dem Datenblock übertragen. Folgende Detailinformationen werden angezeigt:

• Typ Je nach Signaturart können XML-Dokumente nach XML-DSig oder beliebige Datenblöcke nach PKCS#7 signiert werden. Der Typ gibt das Format der übergebenen Datenblöcke nach DOCUMENT.FORMAT an.

• Meta Dieses Feld zeigt die übergebenen Metadaten, wie sie auch im Statusdisplay angezeigt werden. Der konkrete Inhalt wird von der Applikation vorgegeben und soll ein eindeutiges Ordnungsmerkmal für den Dokumentinhalt tragen.

• SHA256-Hash (Urdokument) Hashwert der (exportierten) Urdaten nach SHA256. Dieser Wert kann zur Feststellung der Integrität der Urdaten verwendet werden.

• SHA256-Hash (Bezugsdokument) Hashwert des geladenen Bezugsdokuments. Der Führungstext und der Hashwert werden nur bei Verifikation von Dokumenten in der Kodierung PKCS#7 mit den Formatoptionen (DER, detached) angezeigt.

• SHA256-Hash (Signiertes Dokument) Hashwert des signierten Dokuments nach SHA256. Dieser Wert kann zur Feststellung der Integrität des signierten Dokuments verwendet werden. Der Führungstext und der Hashwert werden nur nach vorangegangener Signatur angezeigt.

• Inhalt Freitext zur Anzeige eines weiteren beschreibenden Textes. Inhaltsangabe des Dokuments. Der Inhalt ist von der Applikation vorgegeben.


Der Benutzer kann folgende Operationen auf einem Dokument auslösen:

• „Untersuchen“ Diese Operation bewirkt die Validierung der angezeigten Signaturzertifikate. Zu jedem Zertifikat wird eine OCSP-Auskunft eingeholt, sofern sie nicht bereits vorliegt.

• „Export“ Mit dieser Operation löst der Benutzer den Export des gesamten Dokuments mit allen abhängigen Daten aus. Vor einer Signaturausführung oder Verifikation liegen lediglich die von der Applikation übergebenen Daten vor. Diese werden zusammen mit einer Beschreibungsdatei nach XML.CONTENT stets exportiert. Wenn das Dokument signiert wurde, werden zusätzliche Daten zur ausgeführten Signatur exportiert. Wenn das Dokument verifiziert wurde, werden die Daten zu allen gefundenen Signaturen exportiert. Zum Umfang der exportierten Daten bei Export von Signaturen siehe Folgeabschnitt 4.2.5.4.

• „Anzeigen“ Diese Operation wird nur bei XML- oder PDF-Dokumenten angeboten. Wenn die Operation ausgelöst wird, wird das Dokument in eine temporäre Datei geschrieben und dem Betriebssystem zur Anzeige übergeben.

4.2.5.4 Einzelauskunft (Signatur) Die Einzelauskunft zur Signatur ist nach ausgeführter Signaturanfertigung oder Verifikation verfügbar. Sie enthält einen Button zur Durchführung der Benutzeraktion “ExportSig“.

Abbildung 4.25 - Screenshot Detaildisplay - Signatur

Die Details der angezeigten Signatur sind in Abhängigkeit vom Signaturformat gefüllt. Stets befüllt sind:

• Status Gültigkeit der Signatur nach allen durchgeführten Prüfungen nach VERIFICATION.STATUS (s. 6.1.18)


• Cryptographie-Status Gültigkeit der Signatur nach mathematischer Verifikation nach SIGNATURE.STATUS (s. 6.1.12).

• Format Festtext, abhängig vom verwendeten Signaturformat: „XML-DSig“ für XML-DSig-, „PDF“ für PDF- und „PKCS#7“ für PKCS#7-Signaturen.

• Signaturzeit (<Quelle>) Anzeige der Signaturzeit und ihrer Quelle. Als Signaturzeit wird die lokale Systemzeit herangezogen, soweit keine weitere Zeitinformation vorliegt. Wenn die Signatur eine mitsignierte Zeitangabe enthält, wird diese angezeigt. Wenn die Signatur einen Signaturzeitstempel enthält, wird dieser angezeigt. Die Anzeige der Quelle der angezeigten Zeitangabe erfolgt nach SIG.TIMESOURCE, 6.1.13.

• Sicherheitsgeeignet bis Anzeige des Ablaufdatums der Sicherheitseignung der verwendeten Signaturmethode. Angezeigt wird das frühste Ablaufdatum der Hashmethode und das Verschlüsselungs-verfahrens mit Schlüssellänge.

Optional befüllte Detailangaben:

• Signierte Systemzeit Optional mitsignierte Systemzeit, wird bei XML nur dann ausgewiesen, wenn die Signatur eine Referenz auf ein XAdES Element mit der Systemzeit umschließt und die Referenz gültig ist. Bei den Formaten PKCS#7 und PDF wird das Element stets angezeigt, weist jedoch bei fehlender Systemzeit keinen Wert aus.

• Id Optionales Id-Attribut des Elements Signature, wenn die Signatur im Format XML-DSig vorliegt

• SigHint Optionale mitsignierte Signaturrolle bei PKCS#7 Signaturen. Dieses Feld wird befüllt, wenn in der Signatur ein Element „unstructuredName“ nach PKCS#9 vorliegt, jedoch davon abweichend mit ASN.1-Typ OctetString.

• unstructuredName Optionales Namenselement nach PKCS#9 (nur bei PKCS#7 Signaturen)

• unstructuredAddress Optionales Adressfeld nach PKCS#9 (nur bei PKCS#7 Signaturen)

• emailAddress Optionale Mailadresse nach PKCS#9 (nur bei PCKS#7 Signaturen)

Folgende Benutzeraktion ist möglich

• „Export“ Diese Operation besteht aus dem Export der Signatur (s. 6.1.3, XML.SIGNATURE) und aller abhängigen Detaildaten zu dem verwendeten Signaturzertifikat (s. 6.1.4, XML.CERTIFICATE), einem optionalen Attributzertifikat (s. XML.ATTRIBCERT, 6.1.5),


einem optionalen Zeitstempel (s. 6.1.7, XML.TIMESTAMP) und optionalen OCSP Auskünften (s. 6.1.6, XML.OCSP), jeweils mit der Zertifikatskette, soweit diese bestimmt werden konnte. Zusätzlich werden Detaildaten zu Referenzen exportiert (s. 6.1.3.1, XML.SIGNATURE.XML für XML-DSig, 6.1.3.2, XML.SIGNATURE.PKCS7 für PKCS#7 und 6.1.3.3, XML.SIGNATURE.PDF für PDF-Signaturen).

4.2.5.5 Einzelauskunft (Zertifikat) Die Detailansicht zu einem (Haupt-) Zertifikat enthält ungeachtet der Herkunft des Zertifikats (von Applikation geladen, in einer Signatur verwendet, Responder- oder Ausstellerzertifikat) stets dieselben Schaltflächen für Benutzeraktionen („OCSP“ „Export“ und „Anzeigen“) und dieselben Detailinformationen.

Abbildung 4.26 - Screenshot Detaildisplay - Zertifikat

Folgende Detailinformationen werden angezeigt:

• Status Information zum vorliegenden Prüfergebnis des Zertifikats nach 6.1.17, CERTIFICATE.STATUS. Der Wert „Referenzfehler“ ist für Attributzertifikate vorgesehen und taucht bei Hauptzertifikaten niemals auf.

• OCSP-Status Information zum Ergebnis einer OCSP-Prüfung nach 6.1.16, CERTOCSP.STATUS.

• OCSP-Abfragedatum (Systemzeit) Systemzeit zum Zeitpunkt der Entgegennahme der OCSP Response nach deren Prüfung.


• Inhaber Einzeilige Darstellung der Attribute des Namens des Zertifikatseigentümers aus dem Zertifikat. Der Name kann einige kommaseparierte Attribute enthalten. Attributname und -wert werden durch Gleichheitszeichen „=“ separiert ausgegeben.

• Aussteller Einzeilige Darstellung der Attribute des Namens des Zertifikatsausstellers, sonst wie vor.

• Seriennummer Eindeutige Seriennummer des vorliegenden Zertifikats beim Aussteller.

• Gültigkeitszeitraum von - bis Zeitangabe über den Beginn und das Ende des Gültigkeitszeitraums des Zertifikats nach den im Zertifikat hinterlegten Einträgen.

• Attributzertifikate Kennzeichnung, ob das Zertifikat die Anbringung von Attributzertifikaten vorsieht „Ja“ oder nicht „Nein“.

• Geeignet für Signaturen Kennzeichnung, ob das Zertifikat zur Anbringung von Signaturen geeignet ist.

• Qualifizierungseintrag Kennzeichnung, ob und welcher Eintrag das Zertifikat nach Common PKI V2.0 zur Erstellung qualifizierter Signaturen ausweist.

• Selbstbeschränkung Attribut „Restriction“ aus dem Zertifikat, Freitext

• Vertretungsmacht Attribut „Procuration“ aus dem Zertifikat, in mehrzeiliger Darstellung.

• Weitere Informationen Attribut „AdditionalInformation“ aus dem Zertifikat, Freitext

• Zulassung Attribut „Admission“ aus dem Zertifikat, in mehrzeiliger Darstellung.


• „OCSP“ Diese Operation bewirkt die Einholung einer Online-Statusauskunft zu dem Zertifikat bei seinem Aussteller. Das Ergebnis der Auskunft wird nach Übernahme in den Feldern „OCSP-Status“ und „OCSP-Abfragedatum“ dargestellt und samt Zertifikatskette in den Navigationsbaum aufgenommen.

• „Export“ Durch Auslösen dieser Operation wird das Zertifikat mit seiner Zertifikatskette sowie einer ggf. vorliegenden OCSP Auskunft mit Responderzertifikat und Zertifikatskette exportiert.


• „Anzeige“ Durch Auslösen dieser Operation wird das Zertifikat in einer temporären Datei dem Betriebssystem zur Anzeige übergeben.

4.2.5.6 Einzelauskunft (Attributzertifikat) Die Detailansicht zu einem Attributzertifikat ähnelt der zu einem Zertifikat. Sie enthält dieselben Schaltflächen für Benutzeraktionen:

Abbildung 4.27 - Screenshot Detaildisplay - Attributzertifikat


• Status Information zum vorliegenden Prüfergebnis des Zertifikats nach 6.1.17, CERTIFICATE.STATUS. Der Wert „Referenzfehler“ wird angenommen, wenn sich das Attributzertifikat nicht auf das Signaturzertifikat bezieht.

• OCSP-Status Information zum Ergebnis einer OCSP-Prüfung nach 6.1.16, CERTOCSP.STATUS.

• OCSP-Abfragedatum (Systemzeit) Systemzeit zum Zeitpunkt der Entgegennahme der OCSP Response nach deren Prüfung.

• Inhaber Einzeilige Darstellung der Attribute des Namens des Zertifikatseigentümers aus dem Zertifikat oder Zertifikatsreferenz. Eine Zertifikatsreferenz besteht aus dem Namen des Ausstellers mit der Seriennummer des von Ihm ausgestellten Zertifikats, dessen Inhaber auch Inhaber des Attributzertifikats ist. Im Fall der Zertifikatsreferenz ist der Ausstellername bis auf die Zertifikatsnummer mit dem im Folgenden beschriebenen Feld identisch.


Der Name kann einige kommaseparierte Attribute enthalten. Attributname und -wert werden durch Gleichheitszeichen „=“ separiert ausgegeben.

• Aussteller Einzeilige Darstellung der Attribute des Namens des Zertifikatsausstellers.

• Seriennummer Eindeutige Seriennummer des vorliegenden Zertifikats beim Aussteller.

• Gültigkeitszeitraum von - bis Zeitangabe über den Beginn und das Ende des Gültigkeitszeitraums des Zertifikats nach den im Zertifikat hinterlegten Einträgen.

• Selbstbeschränkung Attribut „Restriction“ aus dem Attributzertifikat, Freitext

• Vertretungsmacht Attribut „Procuration“ aus dem Attributzertifikat, in mehrzeiliger Darstellung.

• Weitere Informationen Attribut „AdditionalInformation“ aus dem Attributzertifikat, Freitext

• Zulassung Attribut „Admission“ aus dem Attributzertifikat, strukturiert, in mehrzeiliger Darstellung.


• „OCSP“ Diese Operation bewirkt die Einholung einer Online-Statusauskunft zu dem Zertifikat bei seinem Aussteller. Das Ergebnis der Auskunft wird nach Übernahme in den Feldern „OCSP-Status“ und „OCSP-Abfragedatum“ dargestellt und samt Zertifikatskette in den Navigationsbaum aufgenommen.

• „Export“ Durch Auslösen dieser Operation wird das Zertifikat mit seiner Zertifikatskette sowie einer ggf. vorliegenden OCSP Auskunft mit Responderzertifikat und Zertifikatskette exportiert.

4.2.5.7 Einzelauskunft (Zeitstempel) Die Detailansicht zu einem Zeitstempel enthält kein Bedienelement für Benutzeraktionen.


Abbildung 4.28 - Screenshot Detaildisplay - Zeitstempel

Ein Zeitstempel dokumentiert das Vorliegen eines Datenblocks zu der in ihm angegebenen Zeit. Im Fall eines Signaturzeitstempels wird die Signatur zeitgestempelt, was die späteste Signaturzeit dokumentiert10.


• Status Zustand des Zeitstempels nach 6.1.19, TIMESTAMP.STATUS nach allen vorgenommenen Prüfungen. Wenn ein Zeitstempel sich nicht auf den Signaturwert bezieht oder seine Zertifikatskette nicht gebildet werden kann, ist er ungültig.

• Erzeugungszeit signierte (amtliche) Zeitangabe aus dem Zeitstempel

• Sicherheitsgeeignet bis Ablaufdatum der Sicherheitseignung der verwendeten Hashmethode

• Eingetragene Hashmethode Bei der Hashberechnung des Imprints verwendete Methode

• Eingetragener Hashwert Hashwert des Datenblocks, auf den sich der Zeitstempel bezieht

4.2.6 Dateiexporte Infotech Signer bietet durch Dateiexporte die Möglichkeit vorgelegte Dokumente vor der Signaturausführung oder bereits signierte und verifizierte Dokumente vor der Übergabe an die Applikation in sämtlichen Details zu prüfen. Der Export wird auf Anweisung des Benutzers durch Betätigen der Schaltfläche “Export“ in einer der Detailanzeigen eingeleitet. Es wird ein Eingabefeld zum Eintrag des Verzeichnisses angezeigt, in den der Export vorgenommen werden soll (hier bereits eingetragen):

10 Zur Einholung eines Zeitstempels wird dem Zeitstempeldienstanbieter (TSP) ein Imprint (Hashmethode und Hashwert) des zeitzustempelnden Datenblocks vorgelegt, den der TSP signiert zurückgibt.


Abbildung 4.29 - Screenshot Export - Verzeichniswahl

Durch Betätigung der Schaltfläche “Abbrechen“ wird der Exportvorgang storniert, “Exportieren“ startet den Exportvorgang. Für den Export wird im gewählten Verzeichnis ein Unterverzeichnis mit dem Namen “export_<timestamp>_<lfdnr>“ angelegt, in das die Exportdateien geschrieben werden. Die beiden variablen Anteile des Unterverzeichnisses sind:

• <timestamp> Zeitstempel des Beginns des Exports in der Form “YYYY-MM-DD_HHMISS“ in UTC

• <lfdnr> Laufende Nummer des Exports, dreistellig mit führenden Nullen

In dem erstellten Exportverzeichnis findet man nach Fertigstellung des Exports stets die Beschreibungsdatei unter dem Namen “content.xml“ nach 6.1.1, XML.CONTENT und eine Reihe von Binärexporten nach 6.1.23, BINARY.EXPORT. Der Umfang des Exports hängt von dem Objekt ab, auf dessen Detailansicht die Export-Schaltfläche betätigt wurde. Durch Auslösen des Exports auf der Detailanzeige des Dokuments wird das geladene Urdokument mit allen abhängigen Daten nach 6.1.2, XML.DOCUMENT ausgegeben. Wenn das Dokument gerade signiert wurde, werden zusätzlich das signierte Dokument und die Detaildaten zur angefertigten Signatur ausgegeben (s.u.). Wenn das Dokument verifiziert wurde werden die Detaildaten zu allen ermittelten Signaturen ausgegeben. Das Auslösen des Exports auf der Detailanzeige zu einer Signatur bewirkt die Ausgabe der Signaturdaten nach 6.1.3, XML.SIGNATURE mit allen abhängigen Daten, wie Signaturzertifikat, Attributzertifikat und Zeitstempel (s.u.). Der Export auf der Detailanzeige eines Zertifikats oder Attributzertifikats bewirkt die Ausgabe der Zertifikatsdaten nach 6.1.4, XML.CERTIFICATE bzw. 6.1.5, XML.ATTRIBCERT mit den Rohdaten des Zertifikats und seiner Zertifikatskette11 sowie vorliegenden OCSP Responsen, jeweils mit Responderzertifikat und Zertifikatskette.

11 Jedes Zertifikat ist von seinem Aussteller mit seinem Zertifikat signiert. Daraus ergibt sich eine Kette von Zertifikaten, die durch ein selbstsigniertes Zertifikat (Wurzelzertifikat) abgeschlossen wird. Bei Zertifikatexporten werden stets alle Zertifikate der Kette bis zum (aus der Konfigurationsdatei bekannten) Wurzelzertifikat exportiert.


Im Folgenden ein Beispiel zum Inhalt eines Exportverzeichnisses zu einem mit Signatur- und Attributzertifikat signierten XML Dokument mit Signaturzeitstempel:

Abbildung 4.30 - Screenshot Export – Exportverzeichnisinhalt

Beispiel eines möglichen Inhalts des Exportverzeichnisses nach Export auf der Detailanzeige eines signierten XML Dokuments. Die Dateinamen sind von der SAK automatisch generiert und mit den in der Beschreibungsdatei “content.xml“ hinterlegten Selektoren identisch. Die Dateinamen werden aus einem Präfix “Dokument_<n>“ (mit <n> = Nummer des Ablagefachs in der SAK, beginnend mit 1), weiteren Namensbestandteilen und einem typabhängigen Suffix gebildet. Der Suffix von Urdokument und signierten Dokument wird nach dem Dokumentformat (s. 6.1.10, DOCUMENT.FORMAT) unterschieden. Für XML Dokumente ist er fest auf “xml“, für PKCS# Dokumente fest auf “p7m“ eingestellt. Das geladene Urdokument wird als “Dokument_<n>_StoredObject.<suffix>“ exportiert. Wenn es signiert wurde, wird es unter dem Namen “Dokument_<n>_SignedObject.<suffix>“ und die übergebenen Signaturparameter unter dem Namen “Dokument_<n>_StoreParams.<suffix>“ exportiert. Beide Dokumente können mit geeigneten Viewern eingesehen werden.


Signaturbezogene Daten tragen als ersten Namensbestandteil stets “Dokument_<n>_sig_<m>“ (mit <m> = laufende Nummer der Signatur, bei XML Dokumenten in der natürlichen Abfolge des Dokuments, bei PKCS#7 Dokumenten von „außen“ nach „innen“, beginnend mit 1). Zu Signaturen werden fünf unterschiedliche Datenarten nach 6.1.23, BINARY.EXPORT ausgegeben:

• Signaturinhalt Selektor: “Dokument_<n>_sig_<m>“ mit Suffix “.xml“ bei XML Dokumenten Der in 1. Ordnung signierte Inhalt. Bei XML Dokumenten ist dies der kanonisierte Inhalt des SignedInfo Knotens der Signatur, bei PKCS#7 der Binärkodierte Inhalt der SignedAttributes.

• Signaturreferenz Selektor: “Dokument_<n>_sig_<m>_ref_<r>“ mit Suffix “.xml“ bei XML Dokumenten Der in 2. Ordnung signierte Inhalt der <r>-ten Referenz (in der Abfolge des Signaturinhalts, beginnend mit 1). Bei XML Dokumenten ist es der Teil des Dokuments, auf den sich die Referenz bezieht, nach Anwendung der im SignedInfo Knoten angegebenen Kanonisierungs- und Transformationsanweisungen. Bei PKCS#7 Dokumenten existiert höchstens eine Signaturreferenz - den signierten Inhalt (das Urdokument).

• Signaturzertifikat Selektor: “Dokument_<n>_sig_<m>_cert_<c>.crt“ Das X509 Zertifikat mit dem die Signatur ausgeführt wurde in Binärform. Die SAK unterstützt keine Co-Signaturen, daher ist <c> stets 1. Exportierte Zertifikate können mit dem Zertifikatsmanager des Betriebssystems in allen Details untersucht werden. Die Zertifikate der zugehörigen Zertifikatskette tragen denselben Namen mit zusätzlich angehängten Bestandteilen “_issuer_cert_1“.

• Attributzertifikat Selektor: “Dokument_<n>_sig_<m>_attcert_<a>.atz“ Attributzertifikat zum Signaturzertifikat in Binärform. Die SAK unterstützt die Verwendung von höchstens einem Attributzertifikat zu einer Signatur, daher ist <a> stets 1. Die Zertifikate der zugehörigen Zertifikatskette tragen denselben Namen mit zusätzlich angehängten Bestandteilen “_issuer_cert_1“.

• Signaturzeitstempel Selektor: “Dokument_<n>_sig_<m>_timestamp_<t>.tsr“ Zeitstempel einer Signatur in Binärform. Die SAK unterstützt die Verwendung höchstens eines Signaturzeitstempels zu einer Signatur, daher ist <t> stets 1. Der Imprint des Zeitstempels gehört zu dem Signaturinhalt (s.o.). Die Zertifikate der zugehörigen Zertifikatskette tragen denselben Namen mit zusätzlich angehängten Bestandteilen “_issuer_cert_1“.

Die Datei mit dem Namen “Dokument_<n>_Syslog.txt“ enthält textuelle Loginformatinen, vorwiegend zur Fehlerdiagnose im UNIX-Textformat (Zeilenenden ohne <CR>, nur <LF>).


4.2.6.1 Beschreibungsdatei Bei jedem Export legt die SAK eine Beschreibungsdatei mit festem Namen “content.xml“ im Exportverzeichnis an. Bei der Beschreibungsdatei handelt es sich um eine wohlgeformte XML Datei nach 6.1.1, XML.CONTENT ff. mit impliziter Zeichenkodierung nach UTF8. Sie enthält die Namen aller weiteren im Exportverzeichnis angelegten Dateien (in “Selector“ Attributen) und stellt sie untereinander in Beziehung. Sie dient ferner als Informationsquelle wichtiger bei der Ausführung von Signaturen oder deren Verifikation anfallender Informationen. Dazu gehören die Gültigkeit von Signaturen und Zertifikaten, die den Signaturen zugrunde liegenden Funktionen und Parameter sowie Prüfergebnisse. Die Beschreibungsdatei gibt insbesondere Aufschluss über die in der Statusanzeige wiedergegebenen Verifikations- und Validierungsergebnisse. Im Folgenden sind die Pfade zu den Elementen der Beschreibungsdatei “content.xml“ nach 6.1.9, XML.PATH angegeben.

4.2.6.1.1 Verifikationsergebnis und Signaturen Das in der Statusanzeige dargestellte Verifikationsergebnis zu einem Dokument ist nur dann “gültig“, wenn jede untersuchte Signatur “gültig“ ist. Wenn das Verifikationsergebnis zu einem Dokument “ungültig“ ausweist, findet man anhand der Beschreibungsdatei schnell diejenige Signatur, die zu diesem Ergebnis führt. Die Angaben zu der s-ten Signatur des d-ten Dokuments findet man unter dem Signaturpfad “Content/Document[d]/Signature[s]“. Das Ergebnis über alle durchgeführten Verifikationen und Validierungen zu einer Signatur wird im Element <Status> (Signaturstatus) ausgewiesen und kann einen der Werte aus 6.1.12, SIGNATURE.STATUS annehmen. Der Signaturstatus “Content/Document[d]/Signature[s]/Status“ ist “gebrochen“, wenn die Nachberechnung des zugrunde liegenden Hashwerts nicht mit dem ausgewiesenen Hashwert übereinstimmt. Wenn dies auf die Signatur 1. Ordnung zutrifft, nimmt das Element “Content/Document[d]/Signature[s]/Consistent“ den Wert “false“ an. Der Signaturstatus ist ebenfalls dann “gebrochen“, wenn die Nachberechnung eines der Hashwerte der in 2. Ordnung signierten Referenzen nicht mit den ausgewiesenen Hashwerten übereinstimmt. In diesen Fällen nimmt das zugehörige Element “Content/Document[d]/Signature[s]/Referece[r]/Consistent“ der r-ten Referenz den Wert “false“ an.


Der Wert “ungültig“ wird dem Signaturstatus zugewiesen, wenn das verwendete Signaturzertifikat nicht ermittelt werden konnte, es selbst zum Zeitpunkt der Signatur12 “Content/Document[d]/Signature[s]/SigningTime“ nach dem anzuwendenden Gültigkeitsmodell ungültig war, nicht zur Anfertigung qualifizierter Signaturen geeignet markiert ist oder seine Zertifikatskette nicht auf ein bekanntes Wurzelzertifikat führt. Bei XML Signaturen ist ein Signaturstatus “ungesichert“ möglich, der dann angenommen wird, wenn das Signaturzertifikat zwar korrekt verwendet, jedoch nicht mitsigniert wurde. Es werden nur solche Zertifikate als (mögliches) Signaturzertifikat betrachtet, deren Wert im Unterelement <KeyInfo> der Signatur hinterlegt sind. Als mögliche Signaturmechanismen werden alle Referenzen der betrachteten Signatur sowie die XAdES Elemente (unterhalb <Signature> in “.../SigningCertificates/Cert“) berücksichtigt. Im Fall einer Signatur nach XAdES wird der in <CertDigest> ausgewiesene Hashwert über das Zertifikat nachberechnet und muss zu demselben Ergebnis führen. Die in <IssuerSerial> ausgewiesenen Idente sind hinsichtlich der Interoperabilität problematisch. Sie bleiben daher unberücksichtigt,

4.2.6.1.2 Zertifikate und Attributzertifikate Die SAK berücksichtigt zu jeder Signatur nur ein Signaturzertifikat. Wenn es in der Signatur enthalten ist und ihr zugeordnet werden konnte, ist der Zertifikatsstatus in der Beschreibungsdatei im Unterelement “Certificate/Status“ des Signaturpfades hinterlegt. Die übrigen optional in der Signatur enthaltenen Zertifikate werden nicht berücksichtigt. Der Gültigkeitszeitraum eines Zertifikats wird bei dessen Verifikation und bei der Einholung von OCSP-Auskünften ggf. korrigiert, sodass die in den Elementen “Certificate/NotBefore“ und “Certificate/NotAfter“ angegebenen Zeiten unmittelbar mit der Signaturzeit verglichen werden können. Das Vergleichsergebnis wird zur Gültigkeitsbewertung des Zertifikats (s.o.) verwendet. Der Zertifikatsstatus ist “ungültig“, wenn seine Zertifikatskette nicht mit einem bekannten Wurzelzertifikat abschließt oder die Ausstellersignatur für irgendein Zertifikat der Zertifikatskette nicht verifiziert werden kann. Die Merkmale des Ausstellerzertifikats eines jeden Zertifikats finden sich unter dem Element “Certificate“. Dies gilt für die gesamte Zertifikatskette bis zum selbstsignierten Wurzelzertifikat. Alle aus der Konfigurationsdatei geladenen Zertifikate erhalten den Zertifikatsstatus “vertrauenswürdig“.

12 Als Zeitpunkt der Signatur wird der in einem Signaturzeitstempel eingetragene Zeitpunkt verwendet, wenn der Zeitstempel selbst gültig ist und sich auf die Singnatur bezieht. Liegt kein Signaturzeitstempel vor oder ist er nicht gültig, so wird die in der Signatur mitsignierte Zeitangabe verwendet. Wenn keine mitsignierte Zeitangabe vorliegt, wird die lokale Systemzeit als (spätester) Zeitpunkt der Signatur angenommen.


Der Zertifikatsstatus “ungeprüft“ wird als Anfangszustand jedem neu gelesenen Zertifikat zugeordnet. Alle Signaturzertifikate werden geprüft. Sie verbleiben in diesem Zustand nur dann, wenn die mathematische Verifikation des Zertifikats nicht durchgeführt werden kann und tritt im regulären Betrieb nicht auf. Attributzertifikate enthalten eine Referenz auf das Signaturzertifikat. Attributzertifikate mit beschränkendem Inhalt sollen nach Common-PKI bei Signaturen stets zusammen mit dem Signaturzertifikat verwendet werden. Wenn ein bei einer Signatur verwendetes Attributzertifikat nicht das Signaturzertifikat referenziert, erhält es den Zertifikatsstatus “referenzfehler“. Die SAK hat keine Kenntnis vom Inhalt möglicher Attributzertifikate und ob sie beschränkend wirken. Daher fließt die Gültigkeit eines Attributzertifikats in die Gültigkeitsbewertung einer Signatur nicht ein. Die Merkmale des Attributzertifikats werden in der Beschreibungsdatei als Element “AttribCert“ unterhalb des Signaturpfades hinterlegt. Auch zu Attributzertifikaten wird die vollständige Zertifikatskette (in dem Unterelement “Certificate“) ausgewiesen.

4.2.6.1.3 Zeitstempel Zum Nachweis des spätesten Erzeugungszeitpunkts einer Signatur kann zu der Signatur ein Zeitstempel eingeholt werden. Ein Signaturzeitstempel enthält neben der amtlichen Zeit insbesondere einen Hashwert über die Signatur. Die SAK berücksichtigt zu jeder Signatur den ersten vorhandenen Signaturzeitstempel. Die Merkmale eines Signaturzeitstempels findet man in der Beschreibungsdatei im Signaturpfad als Unterelement “TimeStamp“. Der Zeitstempelstatus enthält das vorgenannte Prüfergebnis als Unterelement “Status“. Die SAK fügt der Signatur nur dann einen Signaturzeitstempel hinzu, wenn sie dazu in dem Parametersatz zur Signatur dazu angewiesen wurde und sein Ausstellerzertifikat verifiziert werden konnte. Bei der Signaturprüfung ist die Herkunft eines in die Signaturzeitstempels nicht bekannt, der Zeitstempelstatus wird daher mit “ungeprüft“ vorbelegt. Bei der nachfolgenden Prüfung erhält er den Zeitstempelstatus “gültig“, wenn die die Nachberechnung des Hashwerts über die Signatur mit dem im Zeitstempel angegebenen Hashwert übereinstimmt und das Ausstellerzertifikat verifiziert werden konnte. Wenn eine der beiden Prüfungen fehlschlägt, wird dem Zeitstempelstatus “ungültig“ zugewiesen und die enthaltene Zeitangabe bleibt beider Signaturprüfung unberücksichtigt. Das Ausstellerzertifikat wird mit Zertifikatskette im Unterelement “Certificate“ ausgewiesen.


4.2.6.1.4 OCSP Prüfergebnisse Jedes Zertifikat eines bekannten Ausstellers kann online geprüft werden, sofern dies von der Applikation unterstützt wird. Die Merkmale der Antwort (Response) werden, sofern sie importiert werden konnten, in der Beschreibungsdatei als Unterelement des Zertifikats “OCSP“ eingetragen. Das Unterelement “Status“ von OCSP gibt die Aussage der Response wieder. Wenn das Zertifikat zurückgerufen wurde, sind die Details dazu in den weiteren Unterelementen hinterlegt. Das Unterelement “OCSPStatus“ des Beschreibungsblocks des Zertifikats nimmt bei vorliegender Response den der Response entsprechenden Wert an. Falls noch keine OCSP Anfrage gestellt wurde, enthält es den Initialwert “ungeprüft“. Wenn der SAK der Aussteller des Zertifikats nicht bekannt ist, wird der Wert “aussteller unbekannt“ eingetragen. Wenn die Verifikation der Response fehlschlägt, enthält es “verifikationsfehler“ und wenn keine interpretierbare Antwort zurückgemeldet wurde den Wert “abfragefehler“. OCSP Prüfergebnisse können auch zu Attributzertifikaten eingeholt werden. Sie werden analog denen zu den übrigen Zertifikaten bearbeitet. Infotech Signer enthält einen Zwischenspeicher (Cache) bereits importierter OCSP-Antworten mit den Zertifikaten, auf die sich die Antworten beziehen. Bei erneuter Anfrage zur Gültigkeit eines Zertifikats wird zunächst geprüft, ob eine Antwort zu dem Zertifikat im Cache enthalten ist und ob sie nach Erzeugung der Signatur eingeholt wurde. Falls eine solche Antwort vorliegt und sie vor nicht länger als einer Stunde importiert wurde, wird sie zur Gültigkeitsbewertung des Zertifikats verwendet, andernfalls wird erneut eine aktuelle Auskunft vom Aussteller eingeholt.

4.2.7 Fernsignatur Die Nutzung des Infotech Signer kann über eine lokale Fachapplikation oder mittels Apps auf Mobilgeräten oder entfernten Arbeitsstationen unter Verwendung der NetSignerService Bibliothek erfolgen. Hierzu muss zunächst das Authentisierungsmodul des Infotech Signer aktiviert werden (siehe 6.2.5.2, Erweiterte Funktionen).

4.2.7.1 Anzeigen des Authentisierungsmoduls Das Authentisierungsmodul wird durch die verwendende Applikation aktiviert. Vor der Aktivierung wird der Benutzer als Inhaber der Signaturkarte identifiziert. Unmittelbar vor der Identifikation erhält der Benutzer eine Fernzugriffs-PIN. Der Benutzer bekundet seine Zustimmung zum Fernzugriff auf die Signaturfunktion seiner Signaturkarte im Aktivierungsdialog, der auch die Fernzugriffs-PIN anzeigt:


Abbildung 4.31 - Screenshot Authentisierungsmodul - Freischaltung

Wenn der Benutzer den Dialog quittiert, wird er zur Eingabe der Signatur-PIN aufgefordert. Wenn der Benutzer erfolgreich identifiziert wurde, wird der Multisignaturdialog angezeigt (siehe Abschnitt 4.2.4, Multisignatureinstellungen). Nach Abschluss der Multisignatureinstellungen wird ein Informationsdialog zur Aktivierung des Authentisierungsmoduls angezeigt.

Abbildung 4.32 - Screenshot Authentisierungsmodul - Aktivierung

Dieser Dialog zeigt das zugeordnete Kartenlesegerät mit einer Signaturkarte im geöffneten Zustand. Der Dialog wird nach Bestätigung sofort oder nach 5 Sekunden automatisch geschlossen. Solange das Authentisierungsmodul aktiv ist, wird der folgende Dialog angezeigt:


Abbildung 4.33 - Screenshot Authentisierungsmodul - Aktiviert

Der Dialog zeigt den Namen des Kartenlesers, der die zur Signatur geöffnete Multisignaturkarte enthält sowie den Namen des Zertifikatsinhabers. In diesem Zustand ist der Signer nach erfolgter Kontaktaufnahme und positiver Authentisierung von Mobilgeräten verwendbar. Wenn in diesem Zustand eine der im Multisignaturdialog eingestellten Nutzungsbeschränkungen (Anzahl ausgeführter Signaturen, Ablauf der gestatteten Zeit) erreicht wird, wird die Signaturkarte geschlossen. Der Signer kann mehrfach kontaktiert und genutzt werden. Falls die Authentisierung des remote devices allein aufgrund des Vorweisens falscher Fernzugriffs-PINs fehlschlägt, wird der interne Authentisierungsfehlerzähler inkrementiert. Bei Erreichen eines in der Benutzerkonfigurationsdatei hinterlegten Schwellwerts wird die Schutzfunktion des Authenti-sierungsmoduls aktiviert und folgender Dialog angezeigt:

Abbildung 4.34 - Screenshot Authentisierungsmodul - Schutzfunktion

Bei aktivierter Schutzfunktion wird jeder folgende Authentisierungsversuch für einen ebenfalls in der Benutzerkonfigurationsdatei hinterlegten Zeitraum oder bis zur Bestätigung des Dialogs abgelehnt. Die Schutzfunktion verhindert das systematische Ausprobieren aller möglichen Fernzugriffs-PINs (Brute-Force-Attacken).


Im regulären Betrieb durch ein remote device werden bei Signaturausführungen, Verifikationen oder Zertifikatsprüfungen die bereits beschriebenen, zugehörigen Dialoge angezeigt. Alle Quittungs- und Bestätigungsdialoge werden hingegen unterdrückt. Die weitere Bearbeitung folgt den voreingestellten Rückgabewerten.

4.2.7.2 NetSignerService Zur Nutzung der Bibliothek muss sie mit einem Schlüsselwert initialisiert werden. Während der Initialisierung ermittelt die Bibliothek den Hashwert über den eigenen Programmcode und prüft, ob der ermittelte Hashwert zu dem Schlüsselwert passt. Nur wenn dies zutrifft, aktiviert die Bibliothek ihre Funktionen und zeigt den ermittelten Hashwert in einem Dialog an. Andernfalls zeigt sie einen Dialog mit einem Fehlerhinweis an und bleibt deaktiviert. Während der Anzeige des Initialisierungsdialogs greift die Bibliothek bei Mobilgeräten auf Messwerte des Beschleunigungssensors zu. Diese Werte werden zur Initialisierung des Zufallszahlengenerator benötigt. Falls der Beschleunigungssensor keine Daten liefert, (defekt oder nicht verfügbar), kann sie trotz zutreffenden Hashwerts nicht aktiviert werden. Sie bleibt in diesem Fall deaktiviert. Die App (Fachapplikation) darf nur verwendet werden, wenn der angezeigte Hashwert mit dem veröffentlichten Hashwert für das verwendete Betriebssystem (im Fall von iOS in Kombination mit der App) übereinstimmt. Nur dann ermöglicht die Bibliothek die Verbindungsaufnahme zu einem Infotech Signer und dessen Nutzung. Der Benutzer muss den angezeigten Dialog durch Betätigung der enthaltenen Schaltfläche bestätigen. Wenn die Bibliothek mit einem Infotech Signer verbunden ist und das Kommando zu einem Signaturauftrag überträgt, erzeugt sie einem Warnhinweis über die laufende Signaturausführung, der bis zum Abschluss der Ausführung angezeigt wird. Die folgenden Abschnitte zeigen die von der NetSignerService Bibliothek erzeugten Anzeigen je nach verwendetem Betriebssystem.


4.2.7.2.1 Android Abbildung 4.35 - Screenshot Anzeigen unter Android

Die linke Seite der Abbildung zeigt den Bestätigungsdialog, der nach der Initialisierung angezeigt wird. Auf dem rechten Teil ist die Anzeige der Signaturdurchführung abgebildet.

Abbildung 4.36 - Screenshot Fehleranzeigen unter Android

Bei fehlschlagender Integritätsprüfung wird der linke Dialog angezeigt. Während der Entropie-ermittlung aus dem Lagesensor kann bei langsamen Geräten die mittlere Forschrittsanzeige kurzfristig eingeblendet werden. Wenn nicht hinreichend Entropie ermittelt werden konnte, wird der rechte Dialog angezeigt. Die Bibliothek kann nach Anzeige einer der beiden Dialoge nicht verwendet werden.


4.2.7.2.2 iOS Abbildung 4.37 - Screenshot Anzeigen unter iOS

Die linke Seite der Abbildung zeigt den Bestätigungsdialog, der nach erfolgreicher Initialisierung angezeigt wird. Auf dem rechten Teil ist die Anzeige der Signaturdurchführung abgebildet.

Abbildung 4.38 - Screenshot Fehleranzeigen unter iOS

Bei fehlschlagender Integritätsprüfung wird der linke Dialog angezeigt. Während der Entropie-ermittlung aus dem Lagesensor kann bei langsamen Geräten die mittlere Forschrittsanzeige kurzfristig eingeblendet werden. Wenn nicht hinreichend Entropie ermittelt werden konnte, wird der rechte Dialog angezeigt. Die Bibliothek kann nach Anzeige einer der beiden Dialoge nicht verwendet werden.


4.2.7.2.3 Windows 7 Abbildung 4.39 - Screenshot Anzeigen unter Windows 7

Die linke Seite der Abbildung zeigt den Bestätigungsdialog, der nach der Initialisierung angezeigt wird. Auf dem rechten Teil ist die Anzeige der Signaturdurchführung abgebildet. Sie wird auf dem Desktop an Position (0,0) eingeblendet.

Abbildung 4.40 - Screenshot Fehleranzeigen unter Windows 7

Nach fehlgeschlagener Intergitätsprüfung wird der obenstehende Dialog angezeigt und die Bibliothek kann nicht verwendet werden. Unter Windows 7 wird die für den Kanalaufbau erforderliche Entropie aus den Systemressourcen bezogen. Das Ausbleiben der erforderlichen Entropie die damit verbundenen Fehleranzeigen bei Mobilgeräten kommen nicht vor.

4.3 Sicherheitshinweise und -empfehlungen Es ist sicherzustellen, dass die Systeme, auf denen der TOE betrieben wird, frei sind von jedweder Schadsoftware (Viren, Trojaner) und über zum Betrieb hinreichend Ressourcen verfügen (freier Speicherplatz im RAM und auf persistenten Speichermedien). Die installierten Betriebssystemkomponenten sollen unversehrt sein. Beim Einsatz von Mobilgeräten ist der Betrieb nur mit den originalen Betriebssystemkomponenten (ohne Jailbreak) bestätigt. Infotech Signer ist zum Betrieb in einer geschützten Umgebung vorgesehen. Der Rechner, auf dem Infotech Signer betrieben wird, hat unter vollständiger Kontrolle des Benutzers stehen. Er trägt dafür Sorge, dass der eingesetzte Rechner mit geeigneter und aktueller Virenschutz-Software ausgestattet und der Netzwerkzugang durch eine geeignet konfigurierte Firewall abgesichert ist. Es muss die korrekte Systemzeit eingestellt sein.


Die eingesetzte Hardware darf nicht unzulässig verändert worden sein. Dies betrifft sowohl den PC oder Server, auf dem Infotech Signer betrieben wird, als auch die Kartenlesegeräte. Angebrachte Sicherheitssiegel sind auf ihren Zustand zu prüfen. Die Signaturerzeugung ist nur mit den im ST angegebenen Signaturerstellungseinheiten (Smartcards) bestätigt. Die PIN der Smartcard darf nur dem Inhaber bekannt sein und anderen Personen nicht bekannt gemacht werden. Bei der PIN-Eingabe ist dafür Sorge zu tragen, dass sie nicht beobachtet oder anderweitig ausgespäht wird. Letzteres ist nur durch Verwendung der im ST angegebenen Kartenlesegeräte mit Eingabe über das PIN-Pad gewährleistet.

4.3.1 Fehleranzeige und -behandlung Im Folgenden sind Fehlersituationen beschrieben, die im regulären Betrieb nicht auftreten. Zu den Fehlersituationen sind die zugehörigen Anzeigen des Infotech Signer dargestellt. Unter den Screenshots der Anzeigen sind mögliche Fehlerursachen und Korrekturmaßnahmen beschrieben.

4.3.1.1 Startfehler Während der Startphase (Reset) erfolgen programminterne Prüfungen. Wenn dabei das Fehlen einer Komponente oder der zugehörigen Signatur festgestellt wird oder die Verifikation der Signatur einer Komponente fehlschlägt, wird dies in der Statusanzeige dargestellt:

Abbildung 4.41 - Screenshot Statusanzeige - Integrität verletzt

Infotech Signer beendet sich nach Betätigung der Schaltfläche „OK“ sofort, längstens jedoch nach 15 Sekunden selbsttätig. Wenn diese Fehlersituation eintritt, ist die Integrität der Installation verletzt und kann im Allgemeinen nur durch eine Neuinstallation korrigiert werden. Sofern ausschließlich die Konfigurationsdatei betroffen ist, könnte deren regelmäßig erforderliche Aktualisierung fehlerhaft sein. Dies geschieht insbesondere dann, wenn eine aktive Instanz der SAK jede Änderung der Konfigurationsdatei, nicht jedoch der zugehörigen Signaturdatei, unterbindet.


Es werden die Programmdatei, die Konfigurationsdatei und die Kartentreiber-Bibliothek geprüft und anhand der zugehörigen Signaturdateien verifiziert. Die möglichen Prüfergebnisse lauten:

• “ungeprüft“ Das Prüfergebnis wurde nicht festgestellt. Dieser Fehler tritt regulär nicht auf. Es besteht der Verdacht der Programmmanipulation!

• “OK“ Die vorstehende Datei ist authentisch und integer

• “nicht lesbar“ Die vorstehende Datei wurde nicht gefunden oder kann nicht gelesen werden.

• “Signatur nicht lesbar“ Die Signaturdatei zu der vorstehenden Datei wurde nicht gefunden oder kann nicht gelesen werden.

• “verändert“ Authentizität und / oder Integrität der vorstehenden Datei ist verletzt.

• “Schreibschutz versagt“ (nur Konfigurationsdatei) Die Einrichtung des Schreibschutzes für diese Datei ist fehlgeschlagen.

• “Datenlesefehler“ (nur Konfigurationsdatei) Beim Einlesen der Daten sind Fehler aufgetreten. Die Datei ist unvollständig oder hat das falsche Format.

Falls die Programmdatei oder die Kartenleser-Bibliothek als verändert gemeldet werden, liegt der Verdacht nahe, dass Programmteile durch Schadsoftware verändert wurden. In diesem Fall ist die Ursache der Veränderung dringend zu ermitteln und zu beseitigen. In der Startphase wird die Aktualität der Konfigurationsdatei geprüft. Ist sie veraltet wird dies auf der Dialogfläche dargestellt:

Abbildung 4.42 - Screenshot Statusanzeige - Konfigurationsdatei veraltet

Infotech Signer beendet sich nach Betätigung der Schaltfläche „OK“ sofort, längstens jedoch nach 15 Sekunden selbsttätig.


In dieser Fehlersituation muss zunächst die aktuelle Systemzeit geprüft werden. Wenn sie korrekt eingestellt ist, muss anstelle der vorliegenden Konfigurationsdatei eine Aktuelle samt Signaturdatei installiert werden. Die Installation gelingt nur, wenn keine Instanz der SAK die Änderung der Konfigurationsdatei unterbindet. Es sind daher vor der Installation alle laufenden Instanzen der SAK zu beenden. Zudem müssen die Berechtigungen des Anwenders zur Aktualisierung hinreichen. Aktuelle Sätze aus Konfigurationsdatei und zugehöriger Signaturdatei können über die Firmenhomepage des Herstellerunternehmens (über einen sicheren Kanal) geladen werden.

4.3.1.2 Anmeldefehler Wenn die Anmeldung der Applikation fehlschlägt oder nicht innerhalb einer Minute durchgeführt ist, beendet sich Infotech Signer ohne weitere Anzeige. Ein Benutzereingriff ist nicht möglich.

4.3.1.3 Parameterfehler Infotech Signer prüft vor jeder Signatur, ob die von der Fachapplikation übergebenen Signaturparameter zur Signaturausführung hinreichen. Wenn sie nicht alle zur Signatur erforderlichen Angaben enthalten sind, wird dies angezeigt und die Signaturausführung abgebrochen:

Abbildung 4.43 - Screenshot Statusanzeige - Parametersatz unvollständig

Ein Benutzereingriff ist in dieser Fehlersituation nicht möglich. Die Bestätigung dieses Dialogs leitet die Information über den Abbruch an die aufrufende Applikation weiter. Es empfiehlt sich, die Aktionen, die zu dieser Fehlermeldung führten, möglichst genau zu dokumentieren und dem Hersteller der Fachapplikation zukommen zu lassen.


4.3.1.4 Signaturkarten Falls sich in dem Kartenlesegerät keine Signaturkarte befindet, oder die darin befindliche Signaturkarte nicht unterstützt wird, sollte eine andere Signaturkarte verwendet werden und folgender Dialog wird angezeigt:

Abbildung 4.44 - Screenshot Statusanzeige - Signaturkarte nicht gelesen

Stellen Sie sicher, dass sich die Signaturkarte in dem Kartenleser befindet und der Kartenleser richtig mit der Arbeitsstation verbunden ist. Prüfen Sie, ob das Kartenlesegerät nicht bereits von einer anderen Applikation belegt ist. Wenn Sie die Signaturkarte aus dem Kartenlesegerät entfernen und wieder einstecken, wird jede bis dahin bestehende Verbindung zur Signaturkarte getrennt. Falls die mit der Signaturkarte ausführbare Signaturmethode nicht ermittelt werden kann oder die Sicherheitseignung der unterstützten Signaturmethode abgelaufen ist wird einer der folgenden Hinweise angezeigt:

Abbildung 4.45 - Screenshot Statusanzeige - Schlüssellänge unbestimmt


In dieser Fehlersituation kann die vorliegende Signaturkarte nicht verwendet werden. Sie ist keine der bekannten Signaturkarten. Verwenden Sie eine der in 2.1, Voraussetzungen aufge-listeten Signaturkarten. Ein Benutzereingriff ist in dieser Fehlersituation nicht möglich. Die Be-stätigung dieses Dialogs leitet die Information über den Abbruch an die aufrufende Applikation weiter.

Abbildung 4.46 - Screenshot Statusanzeige - Sicherheitseignung abgelaufen

Diese Fehlersituation tritt ein, wenn Sie eine ältere Signaturkarte verwenden wollen, deren unterstütze Signaturverfahren nicht mehr sicherheitsgeeignet sind. Wenn Sie diesen Dialog bejahen werden ungültige Signaturen erzeugt, die nicht mehr den aktuellen Sicherheitsstandards entsprechen.

4.3.1.5 Signaturzertifikate Vor der Signaturausführung wird das zu verwendende Signaturzertifikat aus der Signaturkarte ausgelesen und intern geprüft. Wenn das ausgelesene Signaturzertifikat nicht zur Signatur qualifiziert, nicht vertrauenswürdig oder nicht gültig (noch nicht gültig oder abgelaufen) ist, wird einer der folgenden Hinweise angezeigt:


Abbildung 4.47 - Screenshot Statusanzeige - Zertifikat nicht qualifiziert

Abbildung 4.48 - Screenshot Statusanzeige - Signaturzertifikat nicht vertrauenswürdig

Abbildung 4.49 - Screenshot Statusanzeige - Signaturzertifikat noch nicht gültig


Abbildung 4.50 - Screenshot Statusanzeige - Signaturzertifikat nicht mehr gültig

Falls mehrere der genannten Bedingungen zutreffen, werden die entsprechenden Hinweise nacheinander angezeigt. Wenn einer dieser Dialoge verneint wird, wird der Signaturvorgang abgebrochen. Andernfalls werden ungültige Signaturen erzeugt. Falls das Signaturzertifikat nicht gelesen werden kann, wird der Signaturvorgang abgebrochen:

Abbildung 4.51 - Screenshot Statusanzeige - Signaturzertifikat nicht lesbar

Ein Benutzereingriff ist in dieser Fehlersituation nicht möglich. Die Bestätigung dieses Dialogs leitet die Information über den Abbruch an die aufrufende Applikation weiter.

4.3.1.6 Attributzertifikate Bei der Signaturausführung kann dem Signaturzertifikat, wenn es einen entsprechenden Hinweis enthält, auch ein Attributzertifikat hinzugefügt werden. Attributzertifikate werden über die Applikation geladen und vor der Signatur geprüft. Wenn das Attributzertifikat nicht geladen


werden konnte, nicht das Signaturzertifikat referenziert oder nicht gültig (noch nicht gültig oder abgelaufen) ist, wird einer der folgenden Hinweise angezeigt:

Abbildung 4.52 - Screenshot Statusanzeige - Attributzertifikat Ladefehler

Abbildung 4.53 - Screenshot Statusanzeige - Attributzertifikat Referenzfehler

Abbildung 4.54 - Screenshot Statusanzeige - Attributzertifikat noch nicht gültig


Abbildung 4.55 - Screenshot Statusanzeige - Attributzertifikat nicht mehr gültig

Bei Bejahung eines der dargestellten Dialoge wird der Ladevorgang wiederholt. Bei Verneinung wird der Signaturvorgang ohne Attributzertifikat fortgesetzt.

4.3.2 Automatische Prüfung von Dokumenten nach der Signatur Unmittelbar nach der Signaturausführung erfolgt eine automatische Prüfung, ob die angebrachte Signatur korrekt ist. Wenn die Signatur nicht korrekt ausgeführt werden konnte, wird der folgende Dialog angezeigt und alle bis dahin erzeugten Signaturergebnisse verworfen.

Abbildung 4.56 - Screenshot Statusanzeige - Signaturausführungsfehler

Es wird ferner geprüft, ob das geladene Urdokument bis zum Abschluss des Signaturvorgangs unverändert geblieben ist. Falls eine Veränderung festgestellt wird, wird der nachfolgende Dialog angezeigt und alle bis dahin erzeugten Signaturergebnisse verworfen.


Abbildung 4.57 - Screenshot Statusanzeige - Urdokument verändert

4.3.3 Überprüfung von Dokumenten vor der Signatur Um ein geladenes Dokument vor der Signaturausführung einzusehen, bricht man die PIN-Eingabe ab (z.B. durch Betätigung des “Abbruch“-Knopfes auf dem Tastenfeld des Kartenlesegeräts), fordert mit dem Navigationselement ( ) der Statusanzeige (siehe 4.2.3, Statusdisplay) die Detailanzeige des interessierenden Dokuments an und führt dessen Export durch (siehe 4.2.6, Dateiexporte). Im Exportverzeichnis findet man unter dem Namen “Dokument_<n>_StoredObject“ (mit Suffix “.xml“ oder “.p7m“) das zur Signatur anstehende Dokument. Die Integrität des (exportierten) Urdokuments kann anhand des in der Detailanzeige ausgewiesenen SHA-256 Hashwerts geprüft werden (siehe 4.2.5.3, Einzelauskunft (Dokument)).

4.3.4 Überprüfung von Dokumenten nach der Signatur Nachdem eine Signatur ausgeführt wurde, muss die Übertragung der Ergebnisdaten an die Applikation bestätigt werden (siehe 4.2.3, Statusdisplay). Während der Anzeige des Bestätigungsdialogs führt man den Export des Dokuments durch, wie im vorangegangenen Abschnitt beschrieben. Nach durchgeführtem Export enthält das Exportverzeichnis u.a. das signierte Dokument unter dem Namen “Dokument_<n>_SignedObject“ (mit Suffix “.p7m“, “.pdf“ oder “.xml“) und eine Zusammenstellung signaturrelevanter Datenextrakte (siehe 4.2.6, Dateiexporte ff.). Die Integrität des (exportierten) signierten Dokuments kann anhand des in der Detailanzeige des Dokuments ausgewiesenen SHA-256 Hashwerts geprüft werden (siehe 4.2.5.3, Einzelauskunft (Dokument)).


Der signierte Anteil eines gerade signierten Dokuments wird i.d.R. durch die erste Referenz unter dem Namen “Dokument_<n>_sig_1_ref_1“ (mit Suffix “.p7m“, “.pdf“ oder “.xml“) exportiert. Der Hashwert der referenzierten Daten wird in der Beschreibungsdatei zusammen mit dem Hashverfahren ausgewiesen. Die SAK hat keine Kenntnis über das Schema (im Fall eines signierten XML Dokuments) oder das Datenformat (bei PKCS#7 Signaturen). Der Datengehalt des von der Signatur überdeckten Anteils wird stets als Ganzes exportiert. Der Bedeutungsgehalt dieser Daten ist nicht Gegenstand der SAK.


5 Benutzerhandbuch für den Entwickler Für Entwickler gelten die Ausführungen aus Kapitel 4, dem Benutzerhandbuch für den Endanwender. Die folgenden Abschnitte dieses Kapitels enthalten die für den Entwickler relevanten Ergänzungen. Dieses Kapitel und der Anhang können von Endanwendern ausgelassen werden.

5.1 Sicherheitsfunktionen Die Beschreibung der Sicherheitsfunktionen ist mit derjenigen aus 4.1, Sicherheitsfunktionen identisch. Der vorgenannte Abschnitt ist gleichfalls Bestandteil dieses Handbuchs.

5.2 Benutzerschnittstelle Die Beschreibung der Oberflächenteile muss hinsichtlich der Namensgebung der SAK und des Programmicons gegen die bei der Registrierung der Fachapplikation mit dem Hersteller vereinbarten ausgetauscht werden. Mit der Veröffentlichung ist das aktualisierte Benutzerhandbuch verfügbar zu machen. Der Austausch des Programmicons und des Programmnamens hat keinerlei Auswirkungen auf die Sicherheitsfunktionalitäten der SAK. Alle für den Endbenutzer verfügbaren Informationen sind auch von der verwendenden (Fach-) Applikation durch eine Schnittstelle abrufbar. Die Schnittstellenbeschreibung befindet sich im Anhang Kapitel 6.1, Datendefinitionen, bis 6.3, NetSignerService.

5.3 Sicherheitshinweise und -empfehlungen

5.3.1 Fehlermeldung und -behandlung Im Folgenden werden mögliche Fehlermeldungen und die empfohlene Behandlung der Fehlersituation beschrieben.

5.3.1.1 Startfehler Während der Startphase des Infotech Signer (Reset) erfolgen programminterne Prüfungen. Wenn dabei das Fehlen einer Komponente oder der zugehörigen Signatur festgestellt wird, die Verifikation der Signatur einer Komponente fehlschlägt oder die Konfigurationsdatei veraltet ist,


beendet sich Infotech Signer auf Benutzeranforderung, sonst längstens nach 15 Sekunden selbstständig. Während dieser Zeit zeigt Infotech Signer dem Benutzer in der Statusanzeige den Grund des Abbruchs (siehe 4.3.1.1, Startfehler). Unmittelbar vor dem Abbau der Applikationsschnittstelle (siehe 6.1 6.2.4, Aktivierungsphase) setzt sie anstelle der Bereitschaftsmeldung eine Fehlermeldung ab. Die Fehlermeldung lautet: “Integrität der Installation verletzt“, wenn die Integrität der Installation nicht verifiziert werden konnte, oder "Konfigurationsdatei veraltet", wenn die Konfigurationsdatei veraltet ist. Die Applikation sollte den Benutzer mindestens darauf hinweisen, dass die Signatur- und Verifikationsfunktionen nicht zur Verfügung stehen, besser jedoch über die kommunizierte Abbruchursache Auskunft erteilen. Wenn die Konfigurationsdatei veraltet ist, sollte die Applikation die Aktualisierung Konfigurationsdatei und der zugehörigen Signaturdatei unterstützen (ggf. durch Download aus der in 2.8, Wartung und Pflege angegebenen Quelle) und Infotech Signer erneut starten. Bei Verwendung der NetSignerService Bibliothek stellt diese während der Initialisierungsphase fest, ob sie unversehrt ist. Nur wenn sie ihre Unversehrtheit festgestellt hat, zeigt sie einen Dialog mit dem ermittelten Hashwert (siehe Abbildung 4.35 - Screenshot Anzeigen unter Android bis Abbildung 4.39 - Screenshot Anzeigen unter Windows 7) und lässt nach Quittierung des Dialogs durch den Endanwender die Nutzung der Funktionen zu. Andernfalls bleibt sie uninitialisiert und die Methoden der Schnittstelle bleiben gesperrt.

5.3.1.2 Anmeldefehler Sobald Infotech Signer die Selbstprüfung und die Inventarisierung der Kartenlesegeräte abgeschlossen hat, leitet er die Anmeldephase ein. Die Anmeldung erfolgt durch das Kommando “Activate“ (siehe 6.2.4, Aktivierungsphase) von der Applikation zu Infotech Signer. Wenn die Applikation das Kommando “Activate“ nicht innerhalb von 5 Sekunden absetzt, terminiert Infotech Signer mit der Fehlermeldung “Authentisierung überfällig“. Andernfalls prüft Infotech Signer die mit dem Kommando übergebene Authentisierung (siehe 6.2.4, Aktivierungsphase). Wenn die Prüfung fehlschlägt, terminiert Infotech Signer mit der Fehlermeldung “Authentisierung fehlgeschlagen“.


Die hier beschriebenen Fehler sollten im regulären Betrieb nicht auftauchen. Falls sie dennoch vorkommen, setzen Sie sich zur Registrierung Ihrer Applikation mit der Herstellerfirma in Verbindung.

5.3.1.3 Parameterfehler Der mit dem Kommando StoreObject übergebene Parametersatz nach 6.1.8, XML.STOREPARAM wird insbesondere zum Transport der Signaturparameter verwendet. Wenn die übergebenen Daten verifiziert werden sollen, darf der Parametersatz leer sein, sollte jedoch stets die Inhaltsangabe (Element <Description>) zu den übergebenen Daten enthalten. Zu Signaturzwecken übergebe Parametersätze müssen wohlgeformt sein und im Fall von XML Signaturen genau ein Element <XmlSignature>, im Fall vom PKCS#7 Signaturen genau ein Element <PKCS7Signature> und im Fall von PDF genau ein Element <PDFSignature> enthalten. Über die Art der Signatur entscheidet das mit StoreObject übergebene Datenformat.

5.3.2 Wahl geeigneter Metadaten Für den Endbenutzer ist es von entscheidender Bedeutung den Inhalt zu signierender Dokumente anhand der Metadaten, die mit dem Dokument zusammen übertragen werden, eindeutig identifizieren zu können. Die Metadaten müssen daher für jedes vorgelegte Dokument eindeutig, mit möglichst engem Bezug zu dem Inhalt gewählt werden. Mögliche Idente sind z.B. Rechnungsnummer, Tagesdatum, Dokumentart, Vorgangsnummer, etc.. Zusammen mit den Dokument- und Metadaten kann die Applikation im Parameterblock eine Inhaltsangabe mitteilen (siehe 6.1.8, XML.STOREPARAM, Element <Description>), die in der Detailanzeige des Dokuments mit dem Führungstext „Inhalt“ ausgegeben wird. Die Inhaltsangabe ist zum Transport weiterer Detailinformationen über das Dokument vorgesehen.

5.3.3 Informationspflichten zur Integritätsprüfung Der Hersteller von Applikationen hat die zur Prüfung der Integrität der verwendeten Bestandteile (Infotech Signer und/oder NetSignerService) erforderlichen Daten und Prüfwerkzeuge (entsprechend Absatz 2.5, Überprüfung der Integrität) zu veröffentlichen und die Endanwender über die Prüfmöglichkeiten und -werkzeuge in Kenntnis zu setzen.


6 Anhang Die folgenden Abschnitte enthalten Beschreibungen der Protokoll- und Bibliotheksschnittstelle, der Datenstrukturen und der internen Betriebsstati der SAK. Sie sollen insbesondere Entwicklern die Integration der SAK über ihre externen Schnittstellen ermöglichen. Der letzte Abschnitt enthält eine Auflistung der öffentlichen Referenzen, auf die in diesem Handbuch Bezug genommen wird.

6.1 Datendefinitionen Der Applikation wird über E.APP1 oder E.APP2 der gleiche Umfang an Daten angeboten wie dem Benutzer über E.DISPLAY und die Exportfunktionen. Die verwendeten Datenstrukturen werden hier übergreifend beschrieben und später referenziert. In den Abschnitten 6.1.1 bis 6.1.8 werden die XML Strukturen (Container) beschrieben, wie sie der Applikation über E.APP1, E.APP2 oder über E.SYSTEM als Datei bzw. Datenblock bereitgestellt werden. Abschnitt 6.1.9 beschreibt eine Konvention zur Angabe einer Position innerhalb eines XML Dokuments. In den restlichen Abschnitten 6.1.10 bis 6.1.25 sind die Aufzählungstypen mit Kurzbezeichnung beschrieben. In der folgenden Strukturbeschreibung verwendete einfache Datenformate

Tabelle 6.1 - Einfache Datenformate

Formatbezeichnung Bedeutung ArrayOfInt[<n>] Kommasepariertes Integer-Feld mit <n> Elementen, begrenzt mit “[“ und “]“

Bool Wahrheitswert “true” oder “false”

DateTime Datumsangabe in “YYYYMMDDHHMISS”, optional mit angehängtem “Z“ zur Markierung der Zeitangabe als UTC

HexString String aus [“0“..“9“], [“a“..“f“]

Int String aus optionalem Vorzeichen (“+“|“-“) und Dezimalzeichen [“0“..“9“]

String Kette beliebiger UTF8-kodierter Unicode Zeichen (RFC 3629)

Konvention: In der Beschreibung der Elemente und Attribute der XML-Strukturen werden Attribute des Elements mit “Element:Attribut“ notiert.


6.1.1 XML.CONTENT Diese Struktur umfasst den vollständigen Umfang der in der SAK gespeicherten Informationen. Als Unterelemente stehen alternativ das Dokument und das Zertifikat zur Verfügung

Content Container, Wurzelelement der Übersicht

Content:TimeOfExport DateTime, Systemzeit zum Zeitpunkt des Exports

Document optionales Unterelement für ein einzelnes abgelegtes Dokument und seine Begleitdaten nach XML.DOCUMENT

Certificate optionales Unterelement für ein einzelnes abgelegtes Zertifikat und seine Begleitdaten nach XML.CERTIFICATE.

6.1.2 XML.DOCUMENT Diese Struktur beinhaltet die Übersichtsdaten zu einem geladenen Dokument.

Document Container, Wurzelelement der Übersichtsdaten zu einem Dokument

Document:Meta Die bereitgestellten Meta-Daten

Document:Format Erkanntes Datenformat. nach DOCUMENT.FORMAT

Signature Container, Informationen zu Signaturen nach XML.SIGNATURE

SignedObject Stellt den Selektor für das signierte Objekt/Dokument bereit

StoredObject Stellt den Selektor für das ursprünglich geladene Objekt bereit

StoredSubdata Stellt den Selektor für das Bezugsdokument bei detached Signaturen

Status Gesamtstatus des Dokuments nach DOCUMENT.STATUS

Status:Info String, textuelle Darstellung des Status (s.v.)

Log Stellt den Selektor für das Systemlog zum Dokument

Log:Selector Selektor für den zugehörigen Datenblock

<Content TimeOfExport>

<Document> XML.DOCUMENT <Certificate> XML.CERTIFICATE

<Document Meta Format>

<Signature> XML.SIGNATURE <SignedObject Selector> <StoredObject Selector> <StoredSubdata Selector> <Status Info> DOCUMENT.STATUS <Log Selector>


6.1.3 XML.SIGNATURE Übersichtsdaten zu einer Signatur.

Signature Container, Wurzelelement der Signaturübersicht

Signature:Selector Selektor für den Datenblock, auf den sich der Signaturwert bezieht (Signatur 1. Ordnung). Abhängig vom Signaturtyp: SignedInfo-Knoten, bei XML, Signed Attributes (oder Urdokument) bei PKCS#7.

Status Ergebnis der Signaturprüfung nach VERIFICATION.STATUS

Status:Info Textuelle Darstellung des Status (s.v.)

CryptoStatus Ergebnis der Signaturprüfung nach SIGNATURE.STATUS

CryptoStatus:Info Textuelle Darstellung des CrypoStatus (s.v.)

SigningTime Signaturzeit aus Zeitstempel (sofern vorhanden und gültig), sonst aus Eintragung in der Signatur (i.d.R. Systemzeit, sofern vorhanden), sonst aktuelle Systemzeit.

SigningTimeSource Angabe der Quelle der Signaturzeit (s.v.) nach SIG.TIMESOURCE

SigningTimeSource:Info Textuelle Darstellung der Quelle der Signaturzeit (s.v.)

SignatureMethod Algorithmen und Parameter, die zur Signaturerzeugung genutzt wurden s. SIGNATURE.METHOD.

SignatureMethod:SecurityBits Sicherheitsmaß des verwendeten Cryptographischen Verfahrens. Hier: RSA PKCS#1, Sicherheitsmaß = Schlüssellänge = Länge Modulus oder ECDSA, Sicherheitsmaß = Länge der Ordnung des privaten Schlüssels.

<Signature Selector>

<Status Info> VERIFICATION.STATUS <CryptoStatus Info> SIGNATURE.STATUS <SigningTime > DateTime <SigningTimeSource Info> SIG.TIMESOURCE <SignatureMethod SecurityBits> String <Consistent> Bool <SecureUntil> DateTime <SignatureHashMethod> HASH.METHOD <SignatureHashValue> HexString <SignatureValue> HexString <XMLSignature ID Path> XML.SIGNATURE.XML <PKCS7Signature Mime Detached Reference> XML.SIGNATURE.PKCS7 <PDFSignature> XML.SIGNATURE.PDF <Certificate> XML.CERTIFICATE <AttribCert> XML.ATTRIBCERT <TimeStamp> XML.TIMESTAMP


Consistent Aussage, ob die Signatur 1. Ordnung integer (ungebrochen) ist. Wenn true, reproduziert die Nachberechnung des Hashwerts des Signaturgegenstands 1. Ordnung (s.o. Selector) den im SignedHash enthaltenen und mit SignedHashValue ausgewiesenen Hashwert

SecureUnltil Frühester Zeitpunkt, an dem die Sicherheitseignung der Hashmethode oder des Verschlüsselungsverfahrens ausläuft.

SignatureHashMethod Algorithmus zur Hashwertbildung nach HASH.METHOD aus entschlüsseltem Signaturwert (s.u.: SignedHash).

SignatureHashValue Hex-Darstellung des über den signierten Dokumentteil nachberechneten Hashwertes.

SignatureValue Hex-Darstellung des Signaturwerts

XMLSignature Container (nur bei XML-Signaturen), siehe XML.SIGNATURE.XML

PKCS7Signature Container (nur bei PKCS#7-Signaturen), siehe XML.SIGNATURE.PKCS7

PDFSignature Container (nur bei PDF-Signaturen), siehe XML.SIGNATURE.PDF

Certificate Daten des ersten Signaturzertifikats, siehe XML.CERTIFICATE

AttribCert Daten des ersten Attributzertifikats, siehe XML.ATTRIBCERT

TimeStamp Daten des ersten Zeitstempels, siehe XML.TIMESTAMP

6.1.3.1 XML.SIGNATURE.XML Struktur spezifischer Übersichtsdaten zu XML-Signaturen. Die Referenzknoten entstammen dem SignedInfo Element. Sie sind von der Signatur umschlossen (Signatur 2. Ordnung).

XMLSignature Container, Wurzelelement XML-spezifischer Signaturdaten

XMLSignature:ID ID aus dem Signature-Knoten, sofern vorhanden

XMLSignature:Path Absoluter Pfad zum Signature-Knoten nach XML.PATH.

Reference Container, Wurzelelement eines Reference-Knotens

Reference:URI Im Reference-Knoten eingetragenes URI

Reference:Type Im Reference-Knoten verwendetes Type-Attribut

Consistent Aussage, ob die Signatur integer (ungebrochen) ist Wenn true, reproduziert die Nachberechnung des Hashwerts nach der in HashMethod ausgewiesenen Methode auf den referenzierten Daten

<XMLSignature ID Path>

<Reference URI Type XAdES Selector>

<Consistent> Bool <SecureUntil> DateTime <HashMethod> HASH.METHOD <HashValue> HexValue <CoveredSignatures> String


(s.o. Selector) den in der Referenz enthaltenen und mit HashValue ausgewiesenen Wert

SecureUntil Zeitpunkt, an dem die Sicherheitseignung der Hashmethode ausläuft.

SignatureHashMethod Algorithmus zur Hashwertbildung s. HASH.METHOD

SignatureHashValue HEX-Darstellung des nachberechneten Hashwertes

SignatureValue Verschlüsselter Signaturwert

XMLSignature Container für spezifische Angaben bei XML-Signaturen siehe Abschnitt 6.1.3.1, XML.SIGNATURE.XML

PKCS7Signature Container für spezifische Angaben bei PKCS#7 Signaturen siehe Abschnitt 6.1.3.2, XML.SIGNATURE.PKCS7

PDFSignature Container für spezifische Angaben bei PDF-Signaturen siehe Abschnitt 6.1.3.3, XML.SIGNATURE.PDF

6.1.3.2 XML.SIGNATURE.PKCS7 Spezifische Übersichtsdaten zu PKCS#7-Signaturen.

PKCS7Signature Container, Wurzelelement PKCS#7-spezifischer Signaturdaten

PKCS7Signature:Mime true, wenn ein Ausgabeformat nach S/MIME vorliegt

PKCS7Signature:Detached true, wenn die Signatur als detached signature vorliegt

Reference Container für die signierten Urdaten (nur bei Signatur 2. Ordnung)

Reference:Selector Selektor für den Datenblock (das Urdokument)

Consistent Aussage, ob die Signatur 2. Ordnung integer (ungebrochen) ist. Wenn true, reproduziert die Nachberechnung des Hashwerts nach der in HashMethod ausgewiesenen Methode auf den referenzierten Daten (das Urdokument, s.o. Selector) den in der Referenz enthaltenen und mit HashValue ausgewiesenen Wert

SigHint Wird aus dem ersten String von unstructuredName nach PKCS#9 belegt, sofern vorhanden und der ASN1-Typ gleich OCTET_STRING ist.

<PKCS7Signature Mime Detached>

<Reference Selector>

<Consistent> Bool <SecureUntil> DateTime <HashMethod> HASH.METHOD <HashValue> HexString

<sigHint> String <unstructuredName> String <unstructuredAddress> String <emailAddress> String


SecureUntil Zeitpunkt, an dem die Sicherheitseignung der Hashmethode ausläuft.

HashMethod Algorithmus zur Hashwertbildung s. HASH.METHOD

HashValue HEX-Darstellung des im Dokument gefundenen Hashwertes

unstructuredName Wird aus dem ersten String von unstructeredName nach PKCS#9 belegt, sofern vorhanden.

unstructuredAddress Wird aus dem ersten String von unstructuredAddress nach PKCS#9 übernommen, sofern vorhanden.

emailAddress Wird aus dem ersten String von emailAddress nach PKCS#9 übernommen, sofern vorhanden.

6.1.3.3 XML.SIGNATURE.PDF Struktur spezifischer Übersichtsdaten zu PDF-Signaturen.

PDFSignature Container, Wurzelelement PDF-spezifischer Signaturdaten

PDFSignature:Filter String, Name aus Signature-Dict, Attribut /Filter (Bezeichnung des Programms, mit dem die Signatur erstellt wurde)

PDFSignature:Subfilter String. Name aus Signature-Dict, Attribut /SubFilter (Kurzbezeichnung des Signaturverfahrens (Definiert: adbe.x509.rsa.sha1, adbe.pkcs7.detached, oder adbe.pkcs7.sha1))

Consistent true, wenn die Nachberechnung des Hashwerts über den in ByteRange angegebenen Dokumentbereich mit dem in der Signatur hinterlegten Hashwert übereinstimmt, false sonst.

HashMethod Algorithmus zur Hashwertbildung s. HASH.METHOD

HashValue HEX-Darstellung des nachberechneten Hashwertes

ByteRange Paar aus Offset und Länge zur Festlegung, über welchen Dokumentbereich die Signatur gilt (Gesamtdokument in der signierten Version, jedoch ohne Signaturwert).

Reference Dokumentbereich, der von ByteRange überdeckt wird (sollte ohne Signature-Dict, Wert des Attributs /Contents sein.

DocVersion Das signierte Dokument in der Version, in der diese Signatur angebracht wurde.

<PDFSignature Filter Subfilter>

<Consistent> Bool <SecureUntil> DateTime <HashMethod> HASH.METHOD <HashValue> HexString <ByteRange> ArrayOfInt[4] <Reference Selector> <Docversion Selector>


6.1.4 XML.CERTIFICATE Diese Struktur beschreibt jeweils ein Zertifikat und seine Begleitdaten

Certificate Container, Beschreibungsblock für ein Zertifikat.

Certificate:Selector Ein Ident für das Zertifikat, über das die Binärform des Zertifikats über E.APP1 oder E.APP2 angefordert werden kann. Beim Export bestimmt dieses den angehängten Anteil des Dateinamen.

Status Ergebnis der Zertifikatsprüfung nach CERTIFICATE.STATUS


OCSPStatus Ergebnis der Online Zertifikatsprüfung nach CERTOCSP.STATUS

OCSPStatus:Info Textuelle Darstellung des OCSPStatus (s.v.)

OCSPStatus:Sysdate Systemdatum zur Einholung der OCSP-Information

Subject Voll qualifizierter Name des Karteninhabers

NotBefore Beginn des Gültigkeitszeitraums in UTC

NotAfter Ende des Gültigkeitszeitraums in UTC

Serial Seriennummer des Zertifikats

Issuer voll qualifizierter Name des Ausstellers

Certificate Container, Ausstellerzertifikat nach XML.CERTIFICATE (sofern verfügbar.

AttributeCertificates Wert von LiabilityLimitationFlag, default „false“

<Certificate Selector>

<Status Info> Int <OCSPStatus Info Sysdate> Int <Subject> String <NotBefore> DateTime <NotAfter> DateTime <Serial> String <Issuer> String <Certificate> XML.CERTIFICATE <AttributeCertificate> Bool <QualifiedForSignature> Bool <QualificationEntries> String <Procuration> String <Restriction> String <AdditionalInformation> String <Admission> String <OCSP> XML.OCSP


QualifiiedForSignature true, wenn das Zertifikat für die Erstellung von Signaturen geeignet ist13.

QualificationEntries “qcStatement: QcCompliance“ und / oder “Policy: cp-sigconform“, sofern das Zertifikat über die entsprechenden Eintragungen verfügt.

Procuration Angaben zur Vertretungsmacht

Restriction Selbstbeschränkung, Freitext

AdditionalInformation Zusatzinformationen, Freitext

Admission Angaben zur beruflichen Zulassung

OCSP Container, Daten eines OCSP-Checks nach XML.OCSP, wenn ein OCSP-Check erfolgreich durchgeführt werden konnte

6.1.5 XML.ATTRIBCERT Diese Struktur beschreibt jeweils ein Zertifikat und seine Begleitdaten

AttribCert Container, Beschreibungsblock für ein Attributzertifikat.

AttribCert:Selector Ein Ident für das Zertifikat, über das die Binärform des Zertifikats über E.APP1 oder E.APP2 angefordert werden kann. Beim Export bestimmt dieses den angehängten Anteil des Dateinamen.

Status Ergebnis der Zertifikatsprüfung nach CERTIFICATE.STATUS


OCSPStatus Ergebnis der Online Zertifikatsprüfung nach CERTOCSP.STATUS

13 Der Wert wird dann true, wenn in dem Bitfeld keyUsage nur das Bit KU_NON_REPUDIATION oder zusätzlich das Bit KU_DIGITAL_SIGNATURE gesetzt ist und keine extendedKeyUsage eingetragen ist, oder dort XKU_SMIME enthalten ist.

<AttribCert Selector>

<Status Info> Int <OCSPStatus Info Sysdate> Int <Holder> String <NotBefore> DateTime <NotAfter> DateTime <Serial> String <Issuer> String <Certificate> XML.CERTIFICATE <Procuration> String <Restriction> String <AdditionalInformation> String <Admission> String <OCSP> XML.OCSP


OCSPStatus:Info Textuelle Darstellung des OCSPStatus (s.v.)

OCSPStatus:Sysdate Systemdatum zur Einholung der OCSP-Information

Holder Voll qualifizierter Name des Attributinhabers oder des Ausstellers mit Seriennummer eines Zertifikats des Inhabers

NotBefore Beginn des Gültigkeitszeitraum in UTC

NotAfter Ende des Gültigkeitszeitraums in UTC

Serial Seriennummer des Zertifikats

Issuer Voll qualifizierter Name des Ausstellers

Certificate Container, Ausstellerzertifikat nach XML.CERTIFICATE (sofern verfügbar.

AttributeCertificates Wert von LiabilityLimitationFlag, default „false“

QualifiiedForSignature true, wenn das Zertifikat für die Erstellung qualifizierter Signaturen geeignet ist.

Procuration Angaben zur Vertretungsmacht

Restriction Selbstbeschränkung, Freitext

AdditionalInformation Zusatzinformationen, Freitext

Admission Angaben zur beruflichen Zulassung

OCSP Container, Daten eines OCSP-Checks nach XML.OCSP, wenn eine OCSP-Check erfolgreich durchgeführt werden konnte

6.1.6 XML.OCSP Struktur für die Response-Daten eines OCSP-Checks

OCSP Container, Ergebnisdaten des einer durchgeführten OCSP-Abfrage

OCSP:Selector Selektor für die binären Daten der OCSP-Response.

Date Datum und Uhrzeit aus der OCSP-Response

Status Gemeldeter Zustand des Zertifikats aus der OCSP-Response. nach OCSP.STATUS.

Status:Info Textuelle Darstellung des Status (s.v)

RevocationTime Zeitpunkt des Rückrufs

Reason Grund des Rückrufs nach REVOCATION.STATUS

Reason:Info Textuelle Kurzbeschreibung der Reason (s.v.).

<OCSP Selector>

<Date> DateTime <Status Info> Int <RevocationTime> DateTime <Reason Info> Int <Certificate> XML.CERTIFICATE


Certificate Zertifikat des Responders nach XML.CERTIFICATE

6.1.7 XML.TIMESTAMP Daten zu einem Zeitstempel.

TimeStamp Wurzelelement für die Daten zu einem Zeitstempel.

TimeStamp:Selector Ident für den Abruf der Daten des Zeitstempels über LoadObject oder Name der Exportdatei

Status Ergebnis der Prüfung des Zeitstempels gegen die Signatur nach TIMESTAMP.STATUS


Time Zeitpunkt der Zeitstempelausstellung

ImprintHashMethod Algorithmus zur Hashwertbildung s. HASH.METHOD

ImprintHashValue Hex-Darstellung des im Imprint des Zeitstempels gefundenen Hashes

StampedData Leerlement zur Ermittlung der zeitgestempelten Daten 14

StampedData:Seclector Ident für den Abruf der Daten, über die sich der Zeitstempel erstreckt.

Certificate Zertifikatsdaten des Responders nach XML.CERTIFICATE

14 Das Element existiert nur bei Zeitstempeln zu XML-Signaturen. Diese werden über einen Hashwert über das kanonisierte <SignatureValue> Element des Dokuments gebildet (welches als Signaturwert einen Hashwert über die Signaturdaten enthält). Im Unterschied dazu wird der Hashwert für den Zeitstempel bei einer PKCS#7-Signatur über die Signaturdaten selbst berechnet. Die Signaturdaten werden in beiden Fällen über XML.SIGNATURE, Containerelement <Signature>, Attribut „Selector“ bekanntgemacht. Die Hashmethode und -wert sind in beiden Fällen im Imprint des Zeitstempels enthalten.

<TimeStamp Selector>

<Status Info> Int <Time> DateTime <ImprintHashMethod> HASH.METHOD <ImprintHashValue> HexString <StampedData Selector> <Certificate> XML.CERTIFICATE


6.1.8 XML.STOREPARAM Diese Parameterstruktur enthält die erforderlichen Angaben für die Erstellung einer Signatur. Je nach Art und Umfang der Signatur werden unterschiedliche Teile benötigt.

<Params>

<Description> String <XMLSignature ID ParentPath BeforeElement>

<Comment> String <Canonicalization Comments Exclusive> <Reference URI Type>

<EnvelopedSignature> <Base64> <Xpath> String <XpathFiltering Filter> String <Canonicalization Comments Exclusive>

<PKCS7Signature Mime Detached>

<sigHint> String <unstructuredName> String <unstructuredAddress> String <emailAddress> String

<PDFSignature certify>

<Name Label hide> String <Reason Label hide> String <Location Label hide> String <X509Name Label hide> <Date Label Format hide> <ContactInfo> String <FieldTitle> String <FieldName> String <Annotation page hide>

<Box xoff yoff width height> String <Text scale render> <Image scale showmode> Base64Data


Params Root-Element der Parameter. Hat für sich selbst keine Bedeutung.

Description Optionale Inhaltsangabe zu dem Dokument. Dieses Element darf nur einmal pro Parametersatz vorkommen. Dieser Text wird in der Detailanzeige zu dem geladenen Dokument angezeigt. Einfache Textformatierungen bleiben nur bei folgender Kodierung erhalten: Zeilenwechsel:
Tabulator:

XMLSignature Kennzeichnet die Parameter für eine Signatur nach XML-Signature. Muss genau einmal und darf nicht zusammen mit PKCS7Signature auftreten. Dieser Parameter wird nur für die Erstellung einer Signatur herangezogen.

XMLSignature:ID Pflichtattribut zu XMLSignature. Bezeichnet die ID, die der ds:Signature-Knoten tragen soll. Die angegebene ID darf in dem Dokument nicht bereits verwendet sein.

XMLSignature:ParentPath Pflichtattribut zu XMLSignature. Bezeichnet, in welchem Parent-Knoten der Signature-Knoten einzutragen ist. Der angegebene Parent-Knoten muss existieren. Die Prüfung, ob dieser Knoten existiert, wird bei der Signaturausführung durchgeführt. Der Aufbau des Pfads wird unter XML.PATH beschrieben.

XMLSignature:BeforeElement Attribut zu XMLSignature. Gibt das Element im Parent-Knoten an, vor dem der Signature-Knoten eingefügt werden soll. Fehlt die Angabe, wird am Ende eingefügt. Die Zählung beginnt bei 1. Bei Werten < 1 wird der Wert 1 angenommen. Bei Werten > Anzahl der Elemente im Parent-Knoten wird am Ende eingefügt.

Comment Optionaler Kommentar, der in das ds:SignedInfo-Element eingetragen und mit signiert wird, darf mehrfach vorkommen.

Canonicalization Dieses Element bestimmt die Canonicalization des SignedInfo Elements des signierten Dokuments.

Canonicalization:Comments Bool, default: true. Wenn true, dann werden Kommentare in der Canonicalization berücksichtigt

Canonicalization:Exclusive Bool, default: true. Wenn true, wird eine Transformation nach Exclusive-Canonical-XML durchgeführt

Reference XML-Signature erwartet die Angabe der zu signierenden Daten in Reference-Knoten. Dieser Parameter legt fest, dass ein Reference-

<TimeStamp>

<URL> String <Userid> String <Pass> String <Policy> String <Digest> HASH.METHOD


Knoten zu bilden ist und legt die Bildungsregeln fest. Die Transformationen werden in der Reihenfolge eingesetzt, wie sie hier angegeben sind.

Reference:URI Attribut zu Reference, optional. String, der in das Attribut URI des Reference-Knotens übernommen wird. Da keine externen Ressourcen vorgesehen sind, muss dieser Parameter mit einem ‚#’ beginnen (Referenziert lokales Element mit Id) oder leer sein. Falls leer, wird das Gesamtdokument referenziert.

Reference:Type Attribut zu Reference, optional. String, der in das Attribut Type des Reference-Knotens übernommen wird. Dieser Parameter ist beliebig und wird nicht weiter geprüft.

EnvelopedSignature Fügt die Transformation nach XML-Signature für enveloped signatures ein. Es sind keine weiteren Angaben vorgesehen.

Base64 Eine Transformation eines Base64-Blocks. Für die Signatur eines originären Binär-Datenblocks.

Xpath Fügt eine Transformation nach Xpath ein.

XpathFiltering Fügt eine Transformation nach XpathFiltering ein

XpathFiltering:Filter Attribut zu XpathFiltering. Belegung des gleichnamigen Attributs in der zu erstellenden Transformation (Spezifikation http://www.w3.org/TR/xmldsig-filter2/). Erlaubt sind „intersect“, „subtract“ und „union“.

Canonicalization Dieses Element bestimmt die Art und Weise der Canonicalization der Referenz

Canonicalization:Comments Bool, default: true. Wenn true, dann werden Kommentare in der Canonicalization berücksichtigt

Canonicalization:Exclusive Bool, default: true. Wenn true, wird eine Transformation nach Exclusive-Canonical-XML durchgeführt

PKCS7Signature Kennzeichnet die Parameter für eine Signatur nach PKCS#7. Muss genau einmal und darf nicht zusammen mit XMLSignature auftreten.

PKCS7Signature:Mime Bool, default: false. Wenn true, wird ein Ausgabeformat nach S/MIME erstellt

PKCS7Signature:Detached Bool, default: false. Wenn true, wird die Signatur als detached signature erstellt

sigHint String, optional. Dieser Parameter ist optional und ist dafür vorgesehen, die applikationsspezifische Rolle zu bestimmen, in der signiert wird. Der Parameter belegt den ersten String in unstructuredName nach PKCS#9 mit „sigHint=Wert“. Darf nicht zusammen mit unstructuredName verwendet werden. Dieser Wert wird mitsigniert.

unstructuredName String, optional. Füllt den ersten String in unstructeredName nach PKCS#9 aus. Darf nicht zusammen mit sigHint gesetzt sein. Dieser Wert wird mitsigniert.


unstructuredAddress String, optional. Füllt den ersten String in unstructuredAddress nach PKCS#9 aus. Dieser Wert wird mit signiert.

emailAddress String, optional. Füllt den ersten String in emailAddress nach PKCS#9 aus. Dieser Wert wird mit signiert.

PDFSignature Kennzeichnet die Parameter für eine Signatur nach PKCS#7

PDFSignature:certify Integer [1..3], Zertifizierungsmodus default: nicht gesetzt, Festlegung der zugelassenen Änderungen des signierten Dokuments: 1: keine Änderungen 2: Ausfüllen existenter Felder 3: wie 2 und Anbringung von Kommentaren

Name String, optional. Überschreibt den in SignatureDict angegebenen Namen des Unterzeichners, default: Name aus Zertifikat

Name:Label String, default: „Digital unterschrieben von “, Führungstext der Namenszeile bei Textanzeige

Name:hide Bool, default: false. Falls true, wird der Name nicht angezeigt

Reason String, optional. Angabe des Signaturgrundes

Reason:Label String, default: „Grund: “, Führungstext zum Signaturgrund bei Textanzeige

Reason:hide Bool, default: false. Falls true, wird der Signaturgrund in der Textanzeige nicht angezeigt

X509Name Attribute zur Textausgabe des Distinguished Name aus dem Signaturzertifikat

X509Name:Label String, default: „DN: “, Führungstext zum X509-Namen (alle Attribute) für Textanzeige

X509Name:hide Bool, default: false. Falls true, wird der X509-Name in der Textanzeige nicht angezeigt

Location String, optional. Signaturort

Location:Label String, default: „Ort: “, Führungstext zum Signaturort

Location:hide Bool, default: false. Falls true, wird der Signaturort in der Textanzeige nicht angezeigt

Date Attribute zur Textausgabe des Signaturdatums

Date:Label String, default: „Datum: “, Führungstext zum Signaturdatum für Textanzeige

Date:Format String, default: „DD.MM.YYYY HH:MI:SS TZD“, Steuerung des Ausgabeformats des Signaturdatums. Die Länge der Ergebnisausgabe darf 40 Bytes nicht überschreiten!

Date:hide Bool, default: false. Falls true, wird das Signaturdatum in der Textanzeige nicht angezeigt

ContactInfo String, optional. Kontaktinformation des Unterzeichners (z.B. Adresse, Telefonnummer

FieldTitle String, optional. Partieller Feldname des Signaturfeldes, default: „Signatur“

FieldName String, optional. Feldname zur Referenz im Dokument, soll (unter allen Feldern) eindeutig sein


Contents String, optional. Inhaltsangabe des Annotation Widgets der Signatur

Annotation Container zur Festlegung der Eigenschaften des Annotation Widgets

Annotation:page Ganzzahl, optional, default: 1, Auswahl der Seite, auf der das Annotation Widget zur angezeigt werden soll. Falls negativ: Zählung von Dokumentende, falls nicht im Bereich enthaltener Seiten (beginnend mit 1): erste Seite sonst Seite der Angegebenen Zahl.

Annotation:hide bool, optional, default: false. Falls true: Annotation Widget (sichtbarer Anteil der Signatur) nicht anzeigen.

Box Positionsangabe auf der Seite [t|m|b][l|c|r], ausgerichtet an Zentrum der Box, verschoben, sodass die Box im MediaRect liegt. Es bedeuten: top middle bottom, left, center, right. Default: Ursprung des Koordinatensystems (unten, links) =^= (0,0), Skala: 1/72“

Box:xoff Ganzzahl, optional, default: 0. Verschiebung nach rechts

Box:yoff Ganzzahl, optional, default: 0. Verschiebung nach oben

Box:width Ganzzahl, optional, default: 0. Breite der Anzeige

Box:height Ganzzahl, optional, default: 0. Höhe der Anzeige

Text Container zur Festlegung des textuellen Anteils der Signatur. Der Text wird nach Bedarf an Leerzeichen umgebrochen und unter Erhalt der einzelnen Zeilen in den Darstelllungsbereich eingepasst, sodass er vollständig sichtbar wird.

Text:scale String, default: „righthalf“, wenn Image angegeben, sonst „full“. Attribut zur Steuerung, wo der Text dargestellt werden soll: „lefthalf“: linke Hälfte der angegebenen Box, „righthalf“: rechte Hälfte der angegebenen Box, „full“ kompletter Boxbereich nutzbar.

Text:render String, default: „text“. Falls „image“: erzeugt ein Image des sichtbaren Textanteils (erhält pdf-a Konformität bei Signatur), sonst pdf-Text mit Referenz auf Font (Helvetika, 10 pt).

Image Base64-Kodierung einer Grafik in einem der Formate bmp, png, gif

Image:scale String, default: „lefthalf“, wenn Text angegeben, sonst „full“. Attribut zur Steuerung, wo das Bild dargestellt werden soll: „lefthalf“: linke Hälfte der angegebenen Box, „righthalf“: rechte Hälfte der angegebenen Box, „full“ kompletter Boxbereich nutzbar. Skalierung erfolgt unter Erhalt der Proportionen, ganzes Bild sichtbar.

TimeStamp Kennzeichnet die Parameter zur Integration von Zeitstempeln in die Signaturen. Dieser Knoten ist optional. Wenn er fehlt, wird bei Signaturen kein Zeitstempel angefordert.

URL String, URL unter der der Zeitstempeldienstanbieter einen Responder nach RFC 3161 über das Protokoll HTTP zur Verfügung stellt.

Userid String, optional. Benutzername zur Authentisierung gegen den Zeitstempeldienstanbieter

Pass String, optional. Passwort zur Authentisierung gegen den Zeitstempeldienstanbieter

Policy String, optional, OID der ggf. vom Zeitstempeldienstanbieter geforderten Policy in Punktnotation


Digest String, optional. Identifikation des bei der Zeitstempelanfrage zu verwendenden Digests nach HASH.METHOD, vorbelegt mit “SHA256“

6.1.9 XML.PATH Der Pfad zur Angabe einer Position innerhalb des XML-Dokuments besteht aus wiederholbaren Angaben der Form

Prefix:Elementname[Index] / …

Elementname Name des XML-Knotens ohne Prefix. Es wird nach Unterelementen mit diesem Namen gesucht. Alle gefundenen Unterelemente bekommen Indexnummern beginnend bei 1 zugewiesen.

Prefix: Dieser Teil ist optional. Wird er angegeben, wird zusätzlich auf diesen Prefix geprüft. Wird nur der Doppelpunkt “:“ angegeben, wird nach Elementen mit leeren Prefix gesucht.

[Index] Dieser Teil ist optional. Wird er angegeben, wird das Unterelement mit der angegebenen Indexnummer verwendet. Fehlt dieser Teil, wird Index mit 1 angenommen. Wird Index < 1 oder größer als die Anzahl der Unterelemente gewählt, wird die Suche abgebrochen.

/ Bedeutet, dass eine weitere Angabe folgt. Die Suche wird in den Unterelementen des vorher gefundenen Elements fortgesetzt. Das Zeichen wird hinter allen Angaben außer der letzten benutzt.

Leerzeichen und Steuerzeichen sind nicht zulässig. Die Suche beginnt immer vor dem Root-Knoten. D.h. die erste Positionsangabe enthält immer den Namen des Root-Knotens.

6.1.10 DOCUMENT.FORMAT Datenformat des geladenen Dokuments. Das Format wird zusammen mit dem Dokument und den Metadaten bereitgestellt.

Tabelle 6.2 - DOCUMENT.FORMAT

Typ Bemerkung P7M Dokument mit nach PKCS#7 integrierter Signatur

P7S Abgesetzte Signatur nach PKCS#7

P7 Dokument (oder Daten zur Signatur nach PKCS#7)

PDF Dokument im PDF-Format

XML Dokument im XML-Format


Typ Bemerkung CRT

CER

DER

X509 Zertifikatsdatei

Alle weiteren Formatangaben werden nur zur Information herangezogen.

6.1.11 DOCUMENT.STATUS Definition des Verarbeitungsstatus eines Dokuments. Status bezeichnet den Status. Msg bezeichnet den für de-DE angezeigten Text in E.DISPLAY. Dieser Text wird zusätzlich als Info-Attribut in der XML-Struktur ausgegeben.

Tabelle 6.3 - DOCUMENT.STATUS

Status Msg Bemerkung 0 unbearbeitet das Dokument wurde geladen und es wurden noch keine weiteren

Operationen ausgeführt

1 wird signiert auf diesem Dokument wird gerade ein Signaturvorgang ausgeführt

2 wird verifiziert das Dokument wird gerade verifiziert

3 signiert Das Dokument ist signiert, aber nicht verifiziert

4 geprüft Das Dokument ist verifiziert worden. Es wurde keine Signatur ausgeführt

5 signiert und geprüft Es wurde eine Signatur ausgeführt und das Dokument ist verifiziert worden.

6 ungültig Das Urdokument wurde während der Signatur verändert

6.1.12 SIGNATURE.STATUS Cryptographie-Status einer Signatur. Konvention s.v.

Tabelle 6.4 - SIGNATURE.STATUS

Status Msg Bemerkung 0 unbekannt keine Signatur gefunden / keine Prüfung durchgeführt

1 konsistent die mathematische Konsistenz der Signatur wurde bestätigt

2 gebrochen die mathematische Prüfung hat Inkonsistenzen aufgezeigt

6.1.13 SIG.TIMESOURCE Quelle der ausgewiesenen Signaturzeit

Tabelle 6.5 - SIG.TIMESOURCE

Status Msg Bemerkung


Status Msg Bemerkung 0 unbekannt es liegt keine bekannte Zeitquelle vor

1 Systemzeit aktuelle Systemzeit

2 Signatur Angabe aus Signatur, Systemzeit während der Signatur

3 Zeitstempel Zeitangabe aus gültig geprüftem Zeitstempel

6.1.14 OCSP.STATUS Status einer OCSP-Response nach RFC 2560. Konvention s.v.

Tabelle 6.6 - OCSP.STATUS Status Msg Bemerkung 0 gültig Das geprüfte Zertifikat ist im Verzeichnis des Ausstellers vorhanden und nicht

zurückgerufen.

1 zurückgerufen Das geprüfte Zertifikat ist im Verzeichnis des Ausstellers und wurde zurückgerufen

2 unbekannt Das angefragte Zertifikat ist im Verzeichnis des Ausstellers nicht vorhanden oder nicht veröffentlicht

6.1.15 REVOCATION.STATUS Beschreibt den Grund des Rückrufs eines Zertifikats.

Tabelle 6.7 - REVOCATION.STATUS Status Bedeutung (englisch) 0 Unspecified

1 keyCompromize

2 cACompromize

3 affiliationChanged

4 Superseded

5 cessationOfOperation

6 certificateHold

6.1.16 CERTOCSP.STATUS Status einer OCSP-Anfrage zu einem Zertifikat. Konvention s.v. Dieser Status berücksichtigt den Umstand, dass bei einer OCSP-Anfrage auch selbst Fehler auftreten können.

Tabelle 6.8 - CERTOCSP.STATUS Status Msg Bemerkung 0 ungeprüft es ist noch keine Prüfung erfolgt


Status Msg Bemerkung 1 gut das Zertifikat ist beim Aussteller als gültig bekannt

2 zurückgerufen das Zertifikat wurde beim Aussteller zurückgerufen (ungültig)

3 unbekannt das Zertifikat ist beim angefragten Aussteller nicht bekannt

4 abfragefehler es konnte (temporär) keine gültige Antwort eingeholt werden.

5 aussteller unbekannt

der Aussteller des Zertifikats ist nicht bekannt

6 verifikationsfehler das Zertifikat des OCSP-Responders konnte nicht verifiziert werden

7 zertifikat fehlt es liegt kein Zertifikat vor

6.1.17 CERTIFICATE.STATUS Status zum Prüfergebnis eines Zertifikats. Konvention s.v.

Tabelle 6.9 - CERTIFICATE.STATUS

Status Msg Bemerkung 0 ungeprüft das Zertifikat ist nicht geprüft worden

1 gültig das Zertifikat ist nach dem Prüfmodell gültig

2 ungültig das Zertifikat ist nach dem Prüfmodell ungültig

3 vertraut Zertifikat vertrauenswürdig, im Zertifikatsstamm

4 kettenfehler die Zertifikatskette ist fehlerhaft oder unvollständig

5 referenzfehler das Attributzertifikat referenziert nicht das Signaturzertifikat15

6 ungesichert das Attributzertifikat ist nicht mitsigniert, die Wirksamkeit ist unsicher16

6.1.18 VERIFICATION.STATUS Gesamtstatus zum Prüfergebnis von Dokumenten und Signaturen. Konvention s.v.

Tabelle 6.10 - VERIFICATION.STATUS Status Msg Bemerkung 0 Signatur ungeprüft es steht kein Verifikationsstatus zur Verfügung.

1 Signatur gültig keine Prüfung hat einen Fehler festgestellt

2 Signatur ungültig mindestens ein Fehler ist aufgetreten

3 Signaturzertifikat ungültig

das Signaturzertifikat ist ungültig (abgelaufen)

4 Signaturzertifikat nicht das Signaturzertifikat wurde nicht mitsigniert

15 Dieser Zustand wird ausschließlich Attributzertifikaten zugeordnet, wenn sie nicht das Hauptzertifikat (Signaturzertifikat) referenzieren. Die Referenz erfolgt über die Struktur Holder des Attributzertifikats. 16 Dieser Zustand wird nur Attributzertifikaten dann zugeordnet, wenn sie nicht mitsigniert wurden und daher die Wirksamkeit der enthaltenen Attribute unsicher ist.


Status Msg Bemerkung mitsigniert

5 Signaturzertifikat nicht gefunden

das Signaturzertifikat ist nicht in der Signatur enthalten

6 Zertifikat für qualifizierte Signaturen ungeeignet

das Zertifikat ist zur Erstellung qualifizierter Signaturen nicht geeignet

7 Signaturzertifikat unbekannt

das Signaturzertifikat ist beim Aussteller unbekannt

8 Signaturzertifikat zurückgerufen

das Signaturzertifikat wurde beim Aussteller zurückgerufen

9 Zertifikatsaussteller unbekannt

der Aussteller des verwendeten Zertifikats ist nicht bekannt

10 Sicherheitseignung abgelaufen

ein in der Signatur verwendeter Algorithmus gilt zum Prüfzeitpunkt als unsicher

11 Unbekannter Algorithmus

bei der Verifikation der Signatur ist mindestens ein unbekannter Algorithmus verwendet worden. Keine Aussage zur Gültigkeit.

12 Validierung unvollständig

bei der Validierung der Signatur sind Warnungen aufgetreten, die Gültigkeit kann bestritten werden

6.1.19 TIMESTAMP.STATUS Gesamtstatus zum Prüfergebnis eines Zeitstempels.

Tabelle 6.11 - TIMESTAMP.STATUS

Status Msg Bemerkung 0 ungeprüft es wurde keine Prüfung durchgeführt

1 gültig keine Prüfung hat einen Fehler festgestellt

2 ungültig mindestens ein Fehler ist aufgetreten

6.1.20 SAK.STATUS Arbeitsstatus der SAK. Dieser Status bestimmt, welche Operationen ausgelöst werden können.

Tabelle 6.12 - SAK.STATUS Status Bezeichnung Bemerkung 0 Reset Infotech Signer befindet sich in einem Zustand, der dem unmittelbar nach

dem Start entspricht

1 Initialized Der Integritätstest war erfolgreich, es sind keine Objekte geladen

2 Loading Es ist mindestens ein Objekt geladen, es wurde noch keine Folgeoperation ausgelöst.

3 Loaded Die Objekte sind geladen und es wurde eine Folgeoperation ausgelöst. Es wurde keine (erfolgreiche) Signatur durchgeführt. Das Auslösen einer Signatur ist zulässig.


Status Bezeichnung Bemerkung 4 Signing Die geladenen Objekte werden gerade signiert. Dieser Zustand wird

automatisch beendet. Währenddessen kann keine weitere Operation ausgelöst werden.

5 Confirm Der Benutzer nach erfolgter Signatur oder Verifikation zur Bestätigung aufgefordert.

6 Signed Alle geladenen Objekte sind erfolgreich signiert worden. Es kann keine weitere Signatur ausgelöst werden.

7 Verifying Die geladenen Objekte werden gerade verifiziert. Dieser Zustand wird automatisch beendet. Währenddessen kann keine weitere Operation ausgelöst werden.

8 Checking Auf den Objekten wird gerade eine Zertifikats- oder Signaturprüfung ausgeführt. Dieser Zustand wird automatisch beendet. Währenddessen kann keine weitere Operation ausgelöst werden.

9 Exporting Über E.DISPLAY ist ein Export ausgelöst worden

10 Online Eine Onlineanfrage über die Applikation wird ausgeführt. Dieser Zustand wird automatisch beendet. Währenddessen kann keine weitere Operation ausgelöst werden.

11 Exit Die Instanz terminiert, es werden keine Kommandos angenommen.

6.1.21 READER.STATUS Zustand des Kartenlesers bzw. des Treibers

Tabelle 6.13 - READER.STATUS Status Bezeichnung Bemerkung 0 Undefiniert Der Treiber wurde noch nicht verwendet, oder der Zustand des

Kartenlesers ist noch nicht bestimmt worden

1 Bereit Der Treiber ist geladen, das Kartenlesegerät ist verwendbar

2 Fehler Es sind Fehler aufgetreten

6.1.22 CARD.STATUS Zustand der Signaturkarte

Tabelle 6.14 - CARD.STATUS

Status Bezeichnung Bemerkung 0 Undefiniert Der Zustand der Signaturkarte ist noch nicht bestimmt worden

1 SingleClose Signaturkarte ist bekannt und geschlossen

2 SingleOpen Signaturkarte ist zur Signatur geöffnet

3 MultiClose Multisignaturkarte ist bekannt und geschlossen

4 MultiOpen Multisignaturkarte ist zur Signatur geöffnet

5 Fehler Es sind Fehler aufgetreten


6.1.23 BINARY.EXPORT Zu allen XML-Elementen mit dem Attribut „Selector“ ist ein Export von Binärdaten vorgesehen. Die Binärdaten werden über die Funktion LoadObject von E.APP1 oder E.APP2 von der Applikation angefordert oder durch Anforderung von E.DISPLAY über E.SYSTEM in das Dateisystem ausgegeben. Die Applikation kann über LoadObject einen Datenblock nach XML.CONTENT anfordern und kann so die Selector-IDs ermitteln. Beim Export der Daten werden alle Binärdaten als Dateien bereitgestellt und die Namen der Dateien in den Selector-Attributen hinterlegt. Zusätzlich wird die Datei nach XML.CONTENT erstellt, die alle exportierten Dateien in einen Zusammenhang bringt.

Tabelle 6.15 - BINARY.EXPORT Element Format Bemerkung Signature XML/Binär Erstellt den Datenblock, aus dem der Hashwert gebildet wurde,

der der Signatur zugeführt wurde. Bei XML ist das der transformierte SignedInfo-Block und bei PKCS#7 die Rohdaten

Reference XML In XML-Signature werden die zu signierenden Daten durch Reference-Strukturen angegeben. Zu jedem Reference-Knoten wird ein eigener Hashwert gebildet. Als Binärdaten wird der aus den Reference-Informationen gebildete transformierte Datenblock exportiert.

Certificate X509 Es wird das Zertifikat in seiner X509-Struktur exportiert

OCSP OCSP Es wird die OCSP-Response bereitgestellt, so wie sie empfangen wurde.

TimeStamp TS Es wird der TimeStamp so bereitgestellt, wie er empfangen wurde bzw. wie er im Dokument hinterlegt wurde.

SignedObject XML/PKCS#7 Das fertig signierte Dokument, abhängig von der Art des Dokuments und der Art der angefertigten Signatur.

StoredObject Das Dokument oder Zertifikat, so wie es mit StoreObject übergeben wurde

StoredSubdata Das von einer Detached-Signature nach PKCS#7 referenzierte Dokument. Wird ausschließlich bei Erstellung oder Prüfung von Detached-Signatures nach PKCS#7 bereitgestellt.

6.1.24 SIGNATURE.METHOD Kürzel der bei einer Signatur verwendeten Algorithmen und Parameter. Das Sicherheitsmaß in Bits wird im Attribut SecurityBits des Elements verzeichnet. Im Fall von RSA ist dies die Länge des verwendeten Modulus, bei ECDSA die Länge der Ordnung des privaten Schlüssels.


Tabelle 6.16 - SIGNATURE.METHOD

Kürzel Bedeutung RSA SHA1 Verschlüsselung RSA PKCS#1, Hash SHA-1

RSA SHA224 Verschlüsselung RSA PKCS#1, Hash SHA-224




RSA RIPEMD160 Verschlüsselung RSA PKCS#1, Hash RIPEMD-160

ECDSA SHA1 Verschlüsselung ECDSA, Hash SHA-1





ECDSA RIPEMD160 Verschlüsselung ECDSA, Hash RIPEMD-160

Weitere Signaturmethoden sind vorhanden, aber nicht Teil des TOE.

6.1.25 HASH.METHOD Kürzel des bei der Hashwertbildung eingesetzten Hashalgorithmus

Tabelle 6.17 - HASH.METHOD Kürzel Bedeutung SHA1 Hash SHA-1

SHA224 Hash SHA-224

SHA256 Hash SHA-256

SHA384 Hash SHA-384

SHA512 Hash SHA-512

RIPEMD160 Hash RIPEMD-160

Weitere Hashmethoden sind vorhanden, sind aber nicht Teil des TOE.

6.2 Applikationsschnittstelle Über diese Schnittstelle kommuniziert die Fachapplikation mit dem TOE. Der Schnittstelle liegt folgendes Modell zugrunde:

• Der TOE verfügt über mehrere Ablagefächer, in denen jeweils ein Objekt zur Bearbeitung abgelegt werden kann.


• Alle Daten werden vor der Bearbeitung in den TOE übertragen und nach der Bearbeitung von dort angefordert.

• Nach dem Auslösen einer Bearbeitung können keine weiteren Objekte bereitgestellt werden.

• Für eine neue Signatur müssen die Ablagefächer neu belegt werden. Eine Verifikation kann ohne erneutes Laden der Objekte wiederholt werden.

• Eine Bearbeitungsfunktion wirkt immer auf alle Ablagefächer. Jedes Ablagefach wird über XML.STOREPARAM spezifisch mit Parameterdaten versorgt.

6.2.1 Grundlagen Die Kommunikation zwischen Applikation und TOE erfolgt über eine bidirektionale Stream-Schnittstelle. Alle Daten werden serialisiert zur anderen Seite übertragen. Zum Aufbau der Kommunikation führt der aufrufende Prozess eine Umlenkung der Standard-Input-Output-Streams auf eigene Handles durch und hat so eine exklusive Stream-Schnittstelle zur SAK, über die beidseitig Daten übertragen werden können.

6.2.2 TSF-Protokoll Aufbauend auf der Stream-Schnittstelle findet eine Strukturierung der ein- und ausgehenden Daten nach folgenden Prinzipien statt

• Die Kommunikation erfolgt über eine Sequenz von Feldern

• Jedes Feld wird von dem folgenden durch einen Tabulator (ASCII 09) separiert

• Die Sequenz wird durch ein einzelnes Linefeed (ASCII 10) abgeschlossen

• In den Feldern treten keine Steuerzeichen auf. Bei der Kodierung werden diese in eine Zeichensequenz \xx umgesetzt, wobei xx die hexadezimale Repräsentation des Steuerzeichens ist. Ein im Feldinhalt vorkommender Tabulator würde also als \09 im Stream kodiert. Der Backslash selbst wird einfach verdoppelt.

• Auf der lesenden Seite werden alle Steuerzeichen außer Tabulator und Linefeed überlesen.

• Alle anderen Zeichen werden ohne Veränderung übertragen.

• Durch die Art der Kodierung können in allen Feldern Binärdaten übertragen werden. Dieses ermöglicht auch eine Verschachtelung von Feldsequenzen.

• Textuelle Feldinhalte in ASCII-, ISO-8859- oder UTF-8-Kodierung werden abgesehen vom Backslash unverändert übertragen.

• Sequenzen werden immer vollständig übertragen


6.2.3 Basis-Kommunikationsprotokoll Für die Realisierung der Funktionen werden für das TSF-Protokoll (Namensgebung: Tab Separierte Felder) folgende Festlegungen getroffen:

• Das erste Feld enthält eine Anfragenummer, um das Ergebnis der Anfrage zuordnen zu können. Die Anfragenummer kann leer bleiben, wenn sichergestellt ist, dass das Ergebnis eindeutig zugeordnet werden kann, z.B. weil die Ergebnisbezeichnung schon ausreicht oder nur ein bestimmtes Ergebnis erwartet wird. Eine vorhandene Anfragenummer wird in der zugehörigen Ergebnissequenz verwendet.

• Das zweite Feld einer Sequenz bezeichnet die Funktion oder das Ergebnis

• Alle weiteren Felder enthalten die Parameter oder die Rückgabewerte, soweit diese vorgesehen sind.

Funktionsaufrufe und Ergebnisse werden prinzipiell immer gleich übertragen. Sie werden nur durch das zweite Feld unterschieden. Bei der Kommunikation von Ergebnissequenzen wird in dem zweiten Feld ein Kürzel über den Returncode der Funktion mit nachgestelltem Doppelpunkt und eine Wiederholung der Funktion übertragen. Der Returncode kann einen der folgenden Werte annehmen:

• OK Die Funktion wurde sachgerecht verarbeitet.

• ERR Bei der Funktionsausführung ist ein Fehler aufgetreten. Details über die Funktionsausführung oder die Fehlerursache können abfragbar oder in der Sequenz selbst enthalten sein.

• WRN Warmhinweis. Ein Warnhinweis signalisiert eingeschränkte Funktionsfähigkeit, die im Regelfall der Bestätigung des Benutzers bedarf (z.B. Nutzung einer abgelaufenen Konfigurationsdatei). Applikationen, die diesen Rückgabewert verarbeiten, können die reguläre Kommunikation fortsetzen. Sie sollten dann das Einverständnis des Benutzers eingeholt haben.

• AAA Informationen an den NetSignerServer zur Authentisierung, Autorisierung und Accounting bei Nutzung der remote Signatur und Verifikation.

6.2.4 Aktivierungsphase In der Aktivierungsphase wird zwischen Infotech Signer und der Applikation eine der folgenden Sequenzen ausgetauscht.


1) Nach fehlgeschlagener Selbstprüfung

1.Feld 2.Feld 3.Feld 4. Feld Richtung (leer) ERR ITSigner V3.0 / Win32 <Fehlermeldung> APP

Die Kommunikation wird seitens des TOE abgebrochen, der TOE beendet sich. Die Fehlermeldung gibt ggf. Aufschluss über die Ursache des Abbruchs. 2) Nach erfolgreicher Selbstprüfung des TOE, bei abgelaufener Konfigurationsdatei

1.Feld 2.Feld 3.Feld 4. Feld 5. Feld Richtung (leer) WRN ITSigner V3.0 / Win32 <Fehlermeldung> <Ablaufdatum> APP

Die weitere Kommunikation erfolgt wie in 3) 3) Nach erfolgreicher Selbstprüfung des TOE

1.Feld 2.Feld 3.Feld 4. Feld weitere Felder Richtung (leer) OK ITSigner V3.0 / Win32 <Zufallswert> <Infofelder> APP

(leer) Activate <AppName> <AUTH> SAK

(leer) OK:Activate APP

Der Signer übergibt in <Infofelder> das Ablaufdatum der Konfigurationsdatei, das Erzeugungsdatum und eine Nachricht zur Anzeige bei remote devices. Die Applikation übergibt den Applikationsnamen und einen Authentisierungswert, der aus dem Zufallswert, dem Applikationsnamen und einem der Applikation bekannten geheimen Schlüssel gebildet wird, zur Prüfung gegen die Konfiguration. Im Anschluss wird der reguläre Betrieb nach dem Protokoll mit den nachfolgend benannten Funktionen fortgeführt. 4) Bei fehlschlagenden Authentisierung der Applikation

1.Feld 2.Feld 3.Feld 4. Feld Richtung (leer) OK ITSigner V3.0 / Win32 <Zufallswert> APP

(leer) Activate <AppName> <AUTH> SAK

(leer) ERR:Activate <Fehlermeldung> APP

Die Kommunikation wird seitens des TOE abgebrochen, der TOE beendet sich. Die Fehlermeldung gibt ggf. Aufschluss über die Ursache des Abbruchs. In der Konfigurationsdatei sind weder der Applikationsname, noch das Passwort klarschriftlich hinterlegt. Zur Prüfung der Authentizität der Applikation mit dem Applikationsnamen


<AppName> und dem Passwort <AppPath> befinden sich in der Konfigurationsdatei stattdessen folgende Wertepaare:

ID1 := Bin2Hex(SHA1(<AppName> + ’\x20’ + <AppPass>)) ID2 := Bin2Hex(SHA1(<ID1> + ‘\20’ + <AppName>))

Die Applikation muss das Ergebnis AUTH folgender Berechnung mit dem aus der Einschaltmeldung der SAK erhaltenen Zufallswert zusammen mit ID2 vorlegen:

AUTH = Bin2Hex(SHA1(<ID1> + ’\x20’ + <Zufallswert>)) Infotech Signer berechnet zu jedem registrierten Wert ID1 nach derselben Regel den Authentisierungswert AUTH und vergleicht ihn mit dem vorgelegten. Nur wenn dieser Vergleich Identität liefert und die vorgelegte ID2 ebenfalls mit dem Wert aus der Konfigurationsdatei übereinstimmt, wird die Applikationsanmeldung akzeptiert

6.2.5 Funktionen des TOE Die Darstellung der Funktionen sieht vor, dass auf der rechten Seite in Klammern sie Aufrufparameter und auf der linken Seite in Klammern die Rückgabewerte im Erfolgsfall dargestellt werden. Wenn nur die erfolgreiche Durchführung der Operation zurückgemeldet wird, stehen auf der linken Seite keine Parameter. Die Reihenfolge der Felder im TSF-Protokoll bestimmt sich durch die Reihenfolge der Aufruf- oder Rückgabewerte in der Funktionsbeschreibung. Alle textuellen Parameter und Rückgabewerte werden UTF-8-kodiert bereitgestellt und erwartet. Unbekannte Funktionen werden entsprechend dem Basis-Protokoll als Fehler zurückgegeben. Unbekannte Antworten (die einen Doppelpunkt enthalten) werden nicht beantwortet.

6.2.5.1 Grundfunktionen Infotech Signer stellt über die Schnittstellen E.APP1 und E.APP2 folgende Funktionen zur Nutzung durch die Applikation bereit: Activate(AppName, Auth)

Führt die Anmeldung der Applikation durch (siehe 6.2.4, Aktivierungsphase). Während der Aktivierungsphase werden andere Kommando als “Activate“ mit einer Fehlermeldung quittiert. Die Nutzung dieser Funktion ist auf E.APP1 beschränkt. AppName Name der Applikation (i.A. Applikationstitel)

Auth Berechneter Authentisierungswert


Die Funktion liefert bei erfolgreicher Anmeldung den Returncode “OK:Activate“, sonst “ERR:Activate“ und eine Fehlermeldung. Die möglichen Fehlermeldungen sind:

"3:Authentisierung überfällig" Authentisierung wurde nicht rechtzeitig durchgeführt

"4:Authentisierung fehlgeschlagen" Authentisierung fehlgeschlagen

(Results) CheckCertificates(Selection) Führt eine OCSP-Prüfung der ausgewählten Zertifikate durch. Die Zertifikate sind vorher durch VerifyObjects ermittelt worden. Durch die Beschreibungsdatei nach 6.1.1, XML.CONTENT erfährt der Aufrufer, welche Signaturen in dem Dokument vorkommen und kann deren Zertifikate gezielt prüfen lassen. Selection Eine Liste mit Tupeln aus (storageindex, signatureindex), beginnend mit

der Anzahl der Tupel. storageindex bezeichnet das Ablagefach beginnend bei 1. Bei Prüfungen von Signaturzertifikaten ist signatureindex mit der Nummer der Signatur zu wählen, beginnend bei 1 in der Reihenfolge, wie sie in XML.CONTENT aufgeführt werden. Bei Prüfungen übergebener Zertifikate ist Signatureindex stets 0.

Results Liste mit den Zertifikatsprüfergebnissen, beginnend mit der Anzahl der Einträge (identisch zu Selection), gefolgt von den Prüfergebnissen nach CERTOCSP.STATUS.

Die Funktion kehrt nicht unmittelbar zurück und erlaubt während der Bearbeitung weitere Funktionsaufrufe. In diesem Zustand unzulässige Funktionsaufrufe werden mit Fehlern abgewiesen (siehe 6.2.6). Die Funktion liefert im Erfolgsfall den Returncode “OK:CheckCertificates“ mit der Ergebnisliste, sonst “ERR:CheckCertificates“ mit einer der folgenden Fehlermeldungen: "Operation nicht ausführbar" Die Funktion wurde in einem anderen Zustand als Loading,

Loaded oder Signed aufgerufen

"Threadwechsel nicht möglich" Es ist bereits ein anderer Auftrag in Bearbeitung

"Selektorliste falsch" Die Selektorliste enthält eine falsche Anzahl von Einträgen

"Objekt zu Index nicht vorhanden" Eine Adressierung aus der Liste konnte nicht zugeordnet werden

DropObjects ()

Löscht alle Ablagefächer Die Funktion kehrt unmittelbar zurück. Es werden zwischenzeitlich keine weiteren Funktionen akzeptiert. Bei Aufruf in einem unzulässigen Zustand liefert Sie den Returncode ERR:DropObjects und die Fehlermeldung "Operation nicht ausführbar", sonst OK:DropObjects.


Export(Path) Führt einen Export aller Ablagefächer durch Path Basispfad des Verzeichnisses in das der Export erfolgen soll

Diese Funktion kehrt unmittelbar nach Ausführung zurück. Sie ist für Debugzwecke vorgesehen und wird in der Produktionsversion im TOE nicht verwendet. Sie liefert stets die Quittungsmeldung “OK:Export“.

(Properties) GetCardProperties(Readername) Liefert die Properties der eingesteckten Karte zur Unterstützung der Applikation. Diese Funktion ist nicht Bestandteil des TOE. Readername Name des Kartenlesers

Properties Liste von Name/Wert-Paaren, wie sie von den Funktionen GetCardProps() und GetCardSigGCert() von E.CARD bereitgestellt werden.

Die Funktion kehrt unmittelbar zurück. Es werden zwischenzeitlich keine weiteren Funktionen akzeptiert. Diese Funktion ist zur Ermittlung von Eigenschaften und Zuständen des Kartenlesers und der Signaturkarte vorgesehen. Sie ist nicht Bestandteil des TOE. Bei Aufruf in einem unzulässigen Zustand liefert Sie den Returncode ERR:GetCardProperties mit der Fehlermeldung "Operation nicht ausführbar", sonst ERR:GetCardProperties (ohne Fehlermeldung).

(Liste) GetReaderNames() Liefert eine Liste mit den Namen der Kartenleser, wie sie über E.CARD ermittelt wurde. Die Liste wird in der Initialisierungsphase ermittelt und ist danach konstant. Diese Funktion kann während der Funktionen, die weitere Funktionsaufrufe zulassen, ausgeführt werden. Liste Eine Liste mit den Namen der Kartenleser

Die Funktion kehrt unmittelbar zurück. Es werden zwischenzeitlich keine weiteren Funktionen akzeptiert. Sie liefert stets den Returncode OK:GetReaderNames und den Rückgabewert (die aktuelle Liste).

(Status) GetStatus() Liefert eine Aussage zum Zustand der SAK. Diese Funktion kann während der Funktionen, die weitere Funktionsaufrufe zulassen, ausgeführt werden. Status Der ermittelte Zustand der SAK nach SAK.STATUS


Die Funktion kann jederzeit ausgeführt werden und kehrt unmittelbar zurück. Sie liefert stets den Returncode OK:GetStatus und den Zahlenwert des aktuellen Status.

(ObjectList) LoadObject (index, selectorlist) Liest das durch index bezeichnete Ablagefach aus. Es werden das signierte Dokument, die Zusatzdaten zur Signatur und Verarbeitungsprotokoll bereitgestellt. index Nummer des Ablagefachs, beginnend bei 1

selectorlist Eine Stringliste mit Selektoren, die festlegen, welche Daten bereitgestellt werden sollen. Die Liste beginnt mit der Anzahl der Selektoren, gefolgt von den Selektoren selbst. Ein leerer selector liefert nur die Inhaltsangabe. Aus der Inhaltsangabe lassen sich über die Selector-Attribute die Idente für alle weiteren Objekte ermitteln. Einige selector-Idente sind festgelegt (s.u.).

ObjectList Die Liste der angeforderten Objekte in der Reihenfolge der Angaben in selectorlist. Die Liste beginnt mit der Anzahl der Einträge, gefolgt von jeweils einem Tripel aus (selectorid, exists, binarydata) pro Eintrag.

Tabelle 6.18 - Vordefinierte Selektoren ID Bedeutung <leer> Inhaltsangabe im Format XML.CONTENT

syslog Das System-Protokoll

signedobject das signierte Dokument

storedobject der über StoreObject() abgelegte Datenblock

storedsubdata der über StoreObject() abgelegte Subdatenblock

Die Funktion kehrt unmittelbar zurück. Es werden zwischenzeitlich keine weiteren Funktionen akzeptiert. Bei Aufruf in einem unzulässigen Zustand liefert Sie den Returncode ERR:LoadObject mit der Fehlermeldung "Operation nicht ausführbar". Wenn das mit index bezeichnete Ablagefach nicht existiert, liefert sie ERR:LoadObject mit der Fehlermeldung "Objekt zu Index nicht vorhanden" andernfalls liefert sie OK:LoadObject und die Exporte der selektierten Objekte.

Quit () Beendet die Kommunikation mit der SAK. Diese Funktion kann jederzeit ausgeführt werden und kehrt unmittelbar zurück. Sie liefert stets den Returncode OK:Quit. Wenn Daten zur Bearbeitung geladen sind, bietet die SAK dem Benutzer die Möglichkeit, die Beendigung wahlfrei durchzuführen, andernfalls terminiert sie.


SetLanguage(lang) Legt die Dialogsprache der SAK fest. Diese Funktion wird nur dann ausgeführt, wenn keine Daten zur Bearbeitung anliegen. lang Spezifikation der Sprache nach RFC 4646. Über die Sprachkonfiguration

können verschiedene Sprachen unterstützt werden. Teil der Bestätigung ist jedoch nur die deutsche Sprache (de-DE). Dieses ist die Voreinstellung beim Start. Es werden nur die konfigurierten Sprachkennungen akzeptiert.

Die Funktion kehrt unmittelbar zurück. Es werden zwischenzeitlich keine weiteren Funktionen akzeptiert. Bei Aufruf in einem anderen Zustand als Initialized liefert Sie den Returncode ERR:SetLanguage mit der Fehlermeldung "Operation nicht ausführbar", sonst OK:SetLanguage.

SignObjects(Readername, Objektanzahl) Führt die Signaturerstellung aus. Die Parameter für die Signaturerstellung wurden vorher bei StoreObject mitgegeben. Readername Name des Kartenlesers, wie er vorher über GetReaderNames() bekannt

gemacht wurde. Es werden nur die bekannten Kartenleser akzeptiert.

Objektanzahl Optionale Anzahl der für diesen Signaturvorgang vorgesehenen Objekte. Die angegebene Objektanzahl kann die Anzahl der geladenen Dokumentblöcke übersteigen.

Die Optionale Objektanzahl dient der Vorbelegung möglicher Signaturen bei Einsatz von Multisignaturkarten, wenn die der Applikation bekannte Anzahl auszuführender Signaturen die Anzahl der geladenen Objekte übersteigt. Die Funktion kehrt nicht unmittelbar zurück und erlaubt während der Bearbeitung weitere Funktionsaufrufe. In diesem Zustand unzulässige Funktionsaufrufe werden mit Fehlern abgewiesen (siehe 6.2.6). Als Returncode liefert sie nur dann OK:SignObjects, wenn auf allen Objekten eine Signatur ausgeführt werden konnte, sonst ERR:SignObjects mit einer der folgenden Fehlermeldungen: "Operation nicht ausführbar" Die Funktion wurde in einem anderen Zustand als Loading oder

Loaded aufgerufen


"Kein Objekt vorhanden" Kein Ablagefach allokiert, kein Objekt geladen

"Parameterblock fehlerhaft" Einer der übergebenen Paramerblöcke ist fehlerhaft

"Kartenleser nicht verfügbar" Der angegebene Kartenleser ist nicht verfügbar

"Signaturkarte nicht verfügbar" Der angegebene Kartenleser enthält keine Signaturkarte

"Zertifikat nicht verfuegbar" Das Signaturzertifikat konnte nicht gelesen werden


"Sicherheitseignung abgelaufen" Die Sicherheitseignung der mit der Signaturkarte erzeugbaren Signaturen ist abgelaufen

"Zertifikatsnutzung ohne Signatur" Dem Zertifikat fehlt die Markierung ist zur Nutzung in Signaturen

"Zertifikat nicht vertrauenswürdig" Das Zertifikat ist nicht vertrauenswürdig. Es konnte keine Zertifikatskette mit bekannter Wurzelinstanz ermittelt werden.

"Zertifikat noch nicht gültig" Das Zertifikat ist noch nicht gültig

"Zertifikat nicht mehr gültig" Das Zertifikat ist nicht mehr gültig

"Signaturausführungsfehler" Fehler bei der Signaturausführung aufgetreten

"Freigabe von Benutzer verneint" Der Benutzer hat die Übergabe der Ergebnisdaten an die Applikation abgelehnt

"Unbekannter Ausnahmefehler" Bei der Signaturausführung ist ein unbekannter Ausnahmefehler aufgetreten

StoreObject(Metadaten, Datenformat, Datenblock, Parameter, Subdatenblock)

Speichert den Datenblock des Dokuments zusammen mit den Metadaten und Parametern im nächsten verfügbaren Ablagefach. Metadaten Ein String, der den Inhalt des Dokuments eindeutig erkennen lässt.

Datenformat Angabe der Applikation, in welchem Datenformat der Datenblock angeliefert wird. Siehe DOCUMENT.FORMAT. Wenn diese Angabe fehlt, versucht die SAK das Format festzustellen. Wird das Format angegeben, wird der Datenblock gegen das angegebene Format geprüft, sofern das Format festgelegt ist.

Datenblock Die Daten für die Erstellung oder Prüfung der Signatur im Format nach PKCS#7, XML, X509-Zertifikat oder unbestimmt. Das unbestimmte Format ist nur für die Signatur nach PKCS#7 geeignet. Die Erkennung des Datenformats erfolgt innerhalb der SAK.

Parameter Ein XML-Datenblock, der weitere optionale Parameter enthält, die innerhalb der Folgeoperationen auf den Daten benötigt werden. s. XML.STOREPARAM

Subdatenblock Bei PKCS#7 muss zur Verifikation einer abgesetzten Signatur (detached signature) das Bezugsobjekt mitgeliefert werden, da sonst keine Prüfung möglich ist. Der Parameter wird nur in diesem Fall benötigt. In allen anderen Fällen bleibt der Parameter leer.

Die Funktion kehrt unmittelbar zurück. Es werden zwischenzeitlich keine weiteren Funktionsaufrufe akzeptiert. Sie liefert den Returncode OK:StoreObject, wenn der Parameterblock leer oder wohlgeformt ist und das Objekt in einem Ablagefach gespeichert werden konnte. Sonst liefert sie den Returncode ERR:StoreObject mit einer der Fehlermeldungen: "Operation nicht ausführbar" Die Funktion wurde in einem anderen Zustand als Initialized

oder Loading aufgerufen


"Allokationsfehler" Das Ablagefach konnte nicht allokiert oder die Daten nicht darin gespeichert werden

"Parameterblock fehlerhaft" Der übergebene Parameterblock ist fehlerhaft oder der Datenblock entspricht nicht dem angegebenen Format.

VerifyObjects()

Führt die Prüfung der Signaturen durch. Bei XML werden alle vorhandenen Signaturen ermittelt und einer mathematischen Prüfung unterzogen. Bei PKCS#7 werden die enthaltenen Datenblöcke nach weiteren PKCS#7-Signaturen untersucht. Die Ergebnisse der Prüfung werden zum Objekt im Ablagefach gespeichert und können mit LoadObject() abgefragt werden.

Die Funktion kehrt nicht unmittelbar zurück und erlaubt während der Bearbeitung weitere Funktionsaufrufe. In diesem Zustand unzulässige Funktionsaufrufe werden mit Fehlern abgewiesen (siehe 6.2.6, Statusübergänge). Sie liefert den Returncode OK:VerifyObjects wenn jedes der geladenen Objekte über mindestens eine Signatur verfügt und alle lokalisierten Signaturen verifiziert werden konnten. Sonst liefert sie ERR:VerifyObjects mit einer der folgenden Fehlermeldungen: “Operation nicht ausführbar" Die Funktion wurde in einem anderen Zustand als Loading,

Loaded oder Signed aufgerufen


"Verifikationsfehler" Für mindestens ein geladenes Objekt konnte keine Signatur gefunden werden oder mindestens eine Signatur ist fehlerhaft

6.2.5.2 Erweiterte Funktionen Die folgenden Funktionen dienen der Konditionierung des Signers für die Nutzung durch ein remote device. AuthClient(Connectstring, Usage)

Diese Funktion wirkt nur bei bereits aktiviertem und nicht gesperrtem Authentisierungsmodul. Sie löst das Einlesen der Benutzerkonfiguration aus und öffnet ein 5-sekündiges Zeitfenster zur Kontaktaufnahme durch ein remote device über den im Vorfeld vereinbarten Netzwerk-Stream. Wenn der Stream zustande kommt, wird er zu einem SSL-gesicherten Kanal ausgebaut. Das Authentisierungsmodul führt einen Authentisierungsfehlerzähler mit, der dann inkrementiert wird, wenn ein sicherer Kanal zustande kommt und alle Authentizitätsprüfungen des remote device bis auf die Prüfung der vorgelegten Fernzugriffs-PIN mit positivem Ergebnis durchlaufen werden und die vorgelegte Fernzugiffs-PIN nicht mit der gespeicherten übereinstimmt. Wenn der Fehlerzähler einen in der Benutzerkonfigurationsdatei festgelegten Schwellwert erreicht hat, sperrt sich das Authentisierungsmodul für einen in der Benutzerkonfigurationsdatei hinterlegten Zeitraum.


Das Ablaufen dieses Zeitraums, die Bestätigung des angezeigten Sperrdialogs oder einer erfolgreiche Authentisierung setzt den Authentisierunszähler auf 0 zurück. Connectstring Identifikation des Kommunikationspartners als String des Formats

<Port>:<Adresse>

Usage Information über die Nutzung des Streams (hier: Port und Adresse des remote device)

Diese Funktion liefert keinen Returnwert.

(Port)AuthModBind() Diese Funktion wirkt nur bei bereits aktiviertem Authentisierungsmodul. Der Aufruf veranlasst das Authentisierungsmodul einen lokalen Netzwerk-Port zur Verbindungsannahme zu allokieren. Es liefert im Erfolgsfall OK:AuthModBind und die Nummer eines geöffneten TCP-Ports, im Fehlerfall ERR:AuthModBind und eine der folgenden Fehlermeldungen:

“Operation nicht ausführbar“ Die Funktion wurde in einem anderen Zustand als Initialized aufgerufen

“Authentisierungsmodul nicht aktiviert“ Das Authentisierungsmodul ist nicht aktiviert.

“Bindung an lokalen Port fehlgeschlagen“ Die Öffnung eines Ports zur Entgegennahme der Verbindungsanfrage des remote device ist fehlgeschlagen.

AuthModEnable(Readername)

Diese Funktion kehrt nach Ausführung sofort zurück. Der Aufruf veranlasst den Signer, alle bis auf den angegebenen alle verfügbaren Kartenleser aus der Kartenleserliste (und damit aus seinem Zuständigkeitsbereich) zu entfernen und aktiviert im Erfolgsfall das Authentisierungsmodul. Readername Name des Kartenlesers, für den die Signer-Instanz zuständig sein soll.

Sie liefert im Erfolgsfall die Quittungsmeldung OK:AuthModEnable, im Fehlerfall ERR:AuthModEnable und eine der folgenden Fehlermeldungen zurück:

“Operation nicht ausführbar“ Die Funktion wurde in einem anderen Zustand als Initialized aufgerufen.

“Kartenleser nicht verfügbar“ Der im Parameter angegebene Kartenleser befindet sich nicht in der Kartenleserliste des Signers.

“Authentisierungsmodul nicht aktiviert“ Das Authentisierungsmodul konnte nicht aktiviert werden.

(MainStatus, ConnStatus, CardStatus)AuthModStatus(Options) Diese Funktion liefert den Zustand des Signers und des Authentisierungsmoduls. Options Unterkommando zur Zustandsermittlung. Das einzig gültige

Kommandowort “reconnect“ bewirkt, dass bei der Zustandsermittlung


der Kartenleser und der Signaturkarte nötigenfalls eine erneute Kontaktaufnahme durchgeführt wird.

MainStatus Zustand des Signers (siehe 6.2.6, Statusübergänge)

ConnStatus Bitmaske. Das entsprechende Bit ist gesetzt, wenn der Zustand zutrifft, sonst gelöscht. - b0: Der Stream von E.APP2 ist betriebsbereit - b1: Der Stream von E.APP2 ist in Benutzung

CardStatus Bitmaske. Das entsprechende Bit ist gesetzt, wenn der Zustand zutrifft, sonst gelöscht. - b0..3: Zustand des Kartenlesertreibers b0: API ist konfiguriert b1: Kontext errichtet, API verwendbar b2: Signaturkarte angeschlossen b3: Fehlerzustand, API nicht verwendbar - b16..19: Zustand der Signaturkarte (0..8) 0: Zustand unbekannt 1: Keine Karte im Kartenleser (nicht verbunden) 2: SSEE wurde ausgetauscht (noch nicht neu gelesen) 3: Zustand nach Reset, ATR der Karte bekannt 4: Karte verfügbar, Kartendaten bekannt 5: Karte ist zur Signatur geöffnet 6: Karte in Transaktion (Kommandoausführung) 7: Fehlerzustand nach Kommandoausführung 8: Karte geschlossen (Verbindung getrennt, ausgeworfen) - b24..31: Multisignatureigenschaft der Signaturkarte 0: Karte ist keine Multisignaturkarte 1: Karte ist unbegrenzt multisignaturfähig n: Karte kann unterstützt bis zu n Signaturen

Die Funktion kehrt sofort zurück und liefert im Erfolgsfall die Quittungsmeldung OK:AuthModStatus mit den Zustandsdaten, andernfalls ERR:AuthModStatus und folgende Fehlermeldung:

„Authentisierungsmodul nicht aktiviert“ Das Authentisierungsmodul ist nicht aktiviert.

AuthSubject() Prüft den Zustand der angeschlossenen Signaturkarte und leitet die Identifikation des Eigentümers der verwalteten Signaturkarte durch PIN-Eingabe ein. Sollte kein Zugriff auf eine Signaturkarte bestehen, wird versucht, die dazu erforderliche Verbindung herzustellen. Die Funktion löst die Erstellung einer Fernzugriffs-PIN aus führt die Benutzerdialoge und liefert bei erfolgreicher Identifizierung die Quittungsmeldung OK:AuthSubject, im Fehlerfall ERR:AuthSubject und eine der Fehlermeldungen: “Operation nicht ausführbar“ Die Funktion wurde in einem anderen Zustand als Initialized

aufgerufen.



“Freigabe abgelehnt“ Der Benutzer hat den Dialog zur Freigabe der Signaturkarte für die Fernsignatur verneint.

“Benutzeridentifikation fehlgeschlagen“ Die Identifikation des Benutzers gegen die Signaturkarte war nicht erfolgreich (Timeout, falsche PIN, …)

ClientLogon(Username, RemotePIN) Diese Funktion ist für E.APP2 vorgesehen und steht in E.APP1 nicht zur Verfügung. Sie dient der Authentisierung des Clients eines remote device und zum Nachweis der Kenntnis der Fernzugriffs-PIN. Die Kontaktaufnahme und die Erstellung des sicheren Kanals müssen innerhalb des durch den Aufruf von AuthClient() geöffneten Zeitfensters abgeschlossen sein. Nur wenn der sichere Kanal bereits besteht, wird dieser Funktionsaufruf vom remote device zum Signer übertragen.

Username Name des Benutzers des remote device (redundant, wurde im Aufbau des sicheren Kanals bereits bekanntgemacht)

RemotePIN Fernzugriffs-PIN, wie sie dem Karteneigentümer während des Aufrufs von AuthSubject() mitgeteilt wurde.

Die Funktion liefert bei erfolgreicher Authentisierung die Quittungsmeldung OK:ClientLogon, sonst ERR:ClientLogon und eine der folgenden Fehlermeldungen: “Operation nicht ausführbar“ Die Funktion wurde in einem anderen Zustand als Initialized

aufgerufen.


“Benutzeranmeldung zurückgewiesen“ Die Authentisierung des remote device ist fehlgeschlagen.

6.2.5.3 Callback-Funktionen Die Applikation stellt folgende Funktionen zur Nutzung durch den Infotech Signer über E.APP1 bereit: (Response) GetFile (Message, Wildcard)

Veranlasst einen Dateizugriff über die Applikation. Message Bezeichnung des erwarteten Dateiinhalts.

Wildcard Suchkriterium zum Auffinden der Datei (Posix-ähnlich).

Response der Dateiinhalt, sofern vorhanden.

Die Funktion wird von der Applikation mit OK:GetFile und dem Ergebnis oder ERR:GetFile und einer Fehlermeldung beantwortet.


(Response) GetUrl (URL, Parameter) Veranlasst einen Netzwerkzugriff über die Applikation. Das Ergebnis der Anfrage wird einer Plausibilitätsprüfung unterzogen. Die Funktion wird derzeit nicht verwendet und ist nicht Bestandteil des TOE. Sie ist für zukünftige Anpassungen oder Erweiterungen vorgesehen. URL Die Internet-Adresse der Ressource, die angefordert wird.

Parameter enthält einen Textblock mit Parametern zu einer http-Anfrage. Dieser Text ist so gestaltet, dass er 1:1 in den Header der http-Anfrage übernommen werden kann.

Response der Datenblock, wie er aus der http-Anfrage zurückkommt.

Die Applikation muss aus der URL, den übergebenen Parametern und seinen eigenen Parametern eine http-Anfrage zusammenstellen und diese an den in der URL angegeben Server weitergeben. Die Funktion wird von der Applikation mit OK:GetUrl und dem Ergebnis oder ERR:GetUrl und einer Fehlermeldung beantwortet. Diese Funktion ist für zukünftige Erweiterungen vorgesehen und wird gegenwärtig nicht verwendet. Sie ist nicht Bestandteil des TOE.

(Response) PostUrl (URL, Parameter, Datenblock) Veranlasst einen Netzwerkzugriff über die Applikation mit dem angegebenen Datenblock. Das Ergebnis der Anfrage wird einer Plausibilitätsprüfung unterzogen. Diese Funktion wird für die OCSP-Prüfung verwendet. URL Die Internet-Adresse der Ressource, über die die Anfrage erfolgen soll

Parameter enthält einen Textblock mit Parametern zu einer http-Anfrage. Dieser Text ist so gestaltet, dass er 1:1 in den Header der http-Anfrage übernommen werden kann.

Datenblock Ein beliebiger Datenblock, der an das Ziel übermittelt werden soll

Response der Datenblock, wie er aus der http-Anfrage zurückkommt.

Die Applikation muss aus der URL, den übergebenen Parametern, seinen eigenen Parametern und dem Datenblock eine http-Anfrage zusammenstellen und diese an den in der URL angegeben Server weitergeben. Die Funktion muss von der Applikation mit OK:PostUrl und dem Ergebnis oder ERR:PostUrl und einer Fehlermeldung beantwortet werden.

6.2.6 Statusübergänge Im Folgenden werden die Zustände des Infotech Signer und die Übergänge zwischen ihnen beschrieben.


Abbildung 6.1 - Statusübergänge

Tabelle 6.19 - Statusübergänge Status n Operation Status n+1 Bemerkung - Programmstart Reset Anfangszustand

Reset Initialisierung und Integritätsprüfung

Initialized automatischer Übergang nach erfolgreicher Integritätsprüfung

Exit Deinitialisiserung und Cleanup

Die Instanz wird beendet und nimmt keine Kommandos mehr an.

* Quit - Es kann jederzeit ein Quit ausgeführt werden

* GetStatus * Der Status kann jederzeit abgefragt werden und verändert den Status nicht

* GetReaderNames * Die Liste der Kartenleser kann jederzeit erfragt werden. Bei nicht durchgeführter Initialisierung ist die Liste leer.

Initialized DropObjects Initialized bewirkt effektiv nichts, ist aber zulässig

SetLanguage Initialized Die Sprache kann nur gewechselt werden, wenn die SAK ordnungsgemäß initialisiert ist und noch kein Objekt zur Bearbeitung geladen wurde.

StoreObect Loading

Loading StoreObject Loading

LoadObject Loading

SignObjects Signing

VerifyObjects Verifying

Checking Loaded


Signing17 - Loaded automatischer Übergang bei nicht erfolgreicher Signatur. Vorliegende Signaturergebnisse werden gelöscht und die Objekte in ihren ursprünglichen Zustand versetzt.

ConfirmS automatischer Übergang bei erfolgreicher Signatur

ConfirmS,18 - Loaded Benutzer hat Übergabe des Signaturergebnisses

verneint. Vorliegende Signaturergebnisse werden gelöscht und die Objekte in ihren ursprünglichen Zustand versetzt.

Signed Benutzer hat Übergabe des Signaturergebnisses bejaht

Signed LoadObject Signed

DropObject Initialized


Checking Signed

Loaded SignObjects Signing

DropObjects Initialized


LoadObject Loaded

Checking Loading

Verifying - ConfirmV automatischer Übergang nach abgeschlossenenr Verifikation

ConfirmV,19 - Loaded Wenn vorher auf den Objekten keine Signatur

ausgeführt wurde

Signed Wenn vorher auf den Objekte eine Signatur ausgeführt wurde

Die beiden Zustände ConfirmS und ConfirmV unterscheiden sich aus Applikationssicht nur durch die vorangegangene Operation. Beiden gemein ist der Wartezustand auf eine Benutzeraktion (Bestätigung) und die Möglichkeit einer Online-Anforderung aus der SAK. Dieser Zustand dient der Umsetzung der Anforderungen aus dem Signaturgesetz.

17 Aus diesem Zustand kann Infotech Signer kurzfristig in den Zustand „Online“ übergehen, wenn externe Daten benötigt werden (Zeitstempel, OCSP-Anfrage, Laden eines Attributzertifikats). Sie nimmt anschließend wieder den vorangegangenen Zustand an. 18 Dieser Zustand wird nach erfolgreich ausgeführter Signatur automatisch angenommen. Infotech Signer zeigt einen Bestätigungsdialog mit der Benutzerwahl, ob das Ergebnis zur Übertragung an die Applikation freigegeben werden soll. 19 Dieser Zustand wird nach ausgeführter Verifikation automatisch angenommen. Infotech Signer zeigt einen Bestäti-gungsdialog zur Kenntnisnahme des Ergebnisses.


6.3 NetSignerService Die Bibliothek NetSignerService dient der Verwendung des Infotech Signer von Mobilgeräten oder entfernten Arbeitsstationen. Sie ist Bestandteil der SAK und enthält alle zur Sicherung und Nutzung eines Kanals zu einem Infotech Signer Infotech Signer erforderlichen Funktionalitäten. Der sichere Kanal wird auf Basis eines verlässlichen Kommunikationskanals errichtet. Die in der Bibliothek enthaltene öffentliche C++ Klasse LibSakService ist ein Wrapper um das bereits beschriebene Protokoll und implementiert die Schnittstelle E.APP2. Die Schnittstelle existiert nur nach vorangegangener Konditionierung des Infotech Signer über E.APP1. Zur Verwendung eines LibSakService muss die Bibliothek einmalig initialisiert werden. Wird sie vor ihrer ersten Verwendung nicht initialisiert, wird die Initialisierung im Konstruktor durchgeführt. Während der Initialisierung wird geprüft, ob der in den Speicher geladene Code der Bibliothek mit dem Auslieferungszustand identisch ist. Das Ergebnis der Prüfung wird dem Benutzer des remote device angezeigt. Die Anzeige muss durch Betätigung eines enthaltenen Buttons quittiert werden. Screenshots der Anzeigen der Bibliothek finden sich in Abschnitt 4.2.7.2, NetSignerService. Wenn der Bestätigungsdialog quittiert wurde und das Prüfergebnis unveränderten Code ausweist, wird im Konstruktor der Klasse LibSakService ein sicherer Kanal zwischen dem Mobilgerät und einem Infotech Signer auf Basis einer SSL TLS Verbindung mit SRP und RSA-Zertifikaten etabliert. Das Protokoll in diesem Kanal ist mit dem von E.APP1 identisch. Bereits während dieses Kanalaufbaus wird der Signer-Instanz der Benutzername mitgeteilt, aufgrund des beiden Seiten bekannten Passworts ein Sitzungsschlüssel ausgehandelt und die Zertifikate gegenseitig bekanntgemacht.

6.3.1 Datentypen Die Schnittstelle über die von LibSakService angebotenen Methoden verwenden folgende Datentypen:

• bool Wahrheitswert. Der Zustand „false“ wird durch den Wert 0 abgebildet, alle anderen Werte sind dem Zustand „true“ zugeordnet.

• if_stream Abstraktion eines verlässlichen Streams (z.B. Netzwerkverbindung über TCP/IP).

• int Vorzeichenbehafteter Zahl- und Zählwert im Wertebereich von -231 bis 231-1.

• uBuffer Klasse eines Puffers für binäre Zeichenketten einer Länge von bis zu 231-2 Bytes.


6.3.2 Authentisierungsphase Unmittelbar nach dem Aufbau des sicheren Kanals dient auf Protokollebene die Funktion ClientLogon (siehe Abschnitt 6.2.5.2, Erweiterte Funktionen) der Authentifizierung des Benutzers des remote devices. Zu einer erfolgreichen Authentisierung muss die Kenntnis der Fernzugriffs-PIN, die unmittelbar vor der Identifizierung gegen die Signaturkarte (PIN-Eingabe) angezeigt wurde, nachgewiesen werden. Die Funktion wird automatisch im Konstruktor der Klasse LibSakService aufgerufen. Wenn der Kanalaufbau gelingt, ist der Signer-Instanz der vorgelegte Benutzername bekannt und das in der Benutzerkonfigurationsdatei hinterlegte, zugehörige Passwort stimmt mit demjenigen, welches dem Konstruktor der Klasse LibSakService als Parameter übergeben wurde, überein. Die Signer-Instanz verweigert den Zugriff, wenn:

• der Benutzername nicht bekannt ist • das Passwort nicht verifiziert werden konnte • für den Benutzer ein Gültigkeitszeitraum hinterlegt wurde und die Verbindungsaufnahme

außerhalb dieses Zeitraums liegt • das während des Kanalaufbaus vorgelegte Zertifikat dem Benutzer nicht zugeordnet

oder gesperrt ist • das Signaturzertifikat der von der Instanz verwalteten SSEE dem Benutzer nicht zuge-

ordnet ist • die vorgelegte Fernzugriffs-PIN mit der gespeicherten nicht übereinstimmt

6.3.3 Zugriffsmethoden Die C++ Klasse LibSakService implementiert einen Wrapper um das in 6.2, Applikationsschnittstelle beschriebene Protokoll. Die nachfolgende Beschreibung der verfüg-baren Methoden folgt der C++ Notation. LibSakService::LibSakService(if_stream *sak_str, const uBuffer &Name, const uBuffer &Pass, const uBuffer& remPin, const uBuffer& channelCertKey, const uBuffer& keyPass, int timeout = 0) Dieser Konstruktor liefert eine Instanz der Klasse LibSakService. Zunächst wird geprüft, ob die Bibliothek bereits erfolgreich geprüft wurde. Falls das noch nicht geschehen ist, wird die Prüfung durchgeführt. Wenn die Prüfung die Unversehrtheit der Bibliothek ausweist, erfolgt der Ausbau des übergebenen Streams zum sicheren Kanal.

sak_str Zeiger auf einen zuverlässigen Stream .

Name Benutzername zur Authentisierung

Pass Passwort zum Benutzernamen zur Errichtung des sicheren Kanals

remPIN Fernzugriffs-PIN zur Authentisierung

channelCertKey Zertifikat und privater Schlüssel zur Authentisierung und für den Ausbau zum sicheren Kanal


keyPass Passwort zur Entschlüsselung des in channelCertKey enthaltenen, verschlüsselten privaten Schlüssels.

timeout Optionale Zeitvorgabe zur Errichtung des Sicheren Kanals (in Millisekunden), sonst 0

Zum Gelingen des Kanalaufbaus muss der verbundenen Signer-Instanz der in den Parametern übergeben Benutzername bekannt sein und das ebenfalls übergebene Passwort muss mit dem für den Benutzer hinterlegten übereinstimmen. Ferner muss, sofern ein Zertifikat übergeben wurde, der ebenfalls übergebene private Schlüssel mit dem übergebenen Passwort entschlüsselt werden können und zum Zertifikat passen. Wenn der Kanalaufbau gelingt, wird das oben beschriebene Protokoll mit reduziertem Funktionsumfang zum internen Datenaustausch aktiviert. Falls die Initialisierung nicht erfolgreich durchgeführt wurde, der sichere Kanal nicht etabliert werden konnte, oder die Aktivierung des Protokolls nicht rechtzeitig stattfindet, ist ein Daten-austausch mit der Signer-Instanz nicht möglich. Dieser Zustand ist durch die Auskunfts-methoden isInitialized() und isConnected() erkennbar. bool LibSakService::CheckCertificate(const uBuffer &depot, const uBuffer &index, uBuffer &result) Diese Methode dient der Prüfung eines Zertifikats in dem mit depot bezeichneten Ablagefach, beginnend mit 0. Falls das Ablagefach ein Zertifikat enthält, muss der index den Wert 0 enthalten und der OCSP-Status des Zertifikats wird ermittelt. Falls es ein Dokument enthält, wird das Zertifikat der index-ten Signatur geprüft. Die Prüfung besteht aus einer Verifikation der Signatur mit anschließender Ermittlung des OCSP-Status. Bei angeschlossener Signer-Instanz und im Fall eines adressierten Dokuments mit erfolgreicher Verifikation liefert die Methode den Status des adressierten Zertifikats nach CERTOCSP.STATUS und den Rückgabewert true. bool LibSakService::DropObjects() Diese Methode löscht alle Ablagefächer der angeschlossenen Signer-Instanz und liefert true, wenn die Löschung erfolgreich durchgeführt wurde, sonst false. const uBuffer LibSakService::GetLastError() Diese Methode liefert einen Fehlerhinweis des zuletzt aufgetretenen Fehlers zur Anzeige für den Benutzer. bool LibSakService::GetCardProperties(const uBuffer &readername, uBuffer &cardprops)


Diese Methode ist nicht Bestandteil des TOE. Sie ermittelt die Eigenschaften des an die verbundene SAK-Instanz angeschlossenen Kartenlesers sowie der Signaturkarte und füllt den übergebenen Puffer. Sie liefert true, wenn die Eigenschaften ermittelt werden konnten, sonst false und der Puffer bleibt unberührt. bool LibSakService::GetReaderName(uBuffer &readername) Diese Methode liefert den Rückgabewert true und füllt den referenzierten Puffer mit dem Kartenlesernamen, wenn dieser für die verbundene SAK-Instanz ermittelt werden konnte. Andernfalls liefert sie false und der Inhalt des referenzierten Puffers bleibt unverändert. bool LibSakService::GetStatus(int &status) Diese Methode liefert den Rückgabewert true, wenn der Status der verbundenen SAK-Instanz erfolgreich ermittelt werden konnte. In diesem Fall ist der Statuswert in der referenzierten Variable eingetragen. Andernfalls liefert sie false und der Inhalt der referenzierten Variablen bleibt unverändert. static bool LibSakService::Init() Diese Methode dient der Initialisierung der Bibliothek. Sie dient der Prüfung der Unversehrtheit der Bibliothek im Speicher, der Anzeige des Prüfergebnisses und der Einholung der Bestätigung des Benutzers. Sie liefert true, wenn das Prüfergebnis die Unversehrtheit der Bibliothek ausweist und der Benutzer den angezeigten Dialog bestätigt hat, sonst false. Diese Methode ist statisch und damit unabhängig vom Vorliegen einer LibSakService-Instanz. bool LibSakService::isConnected() Diese Auskunftsmethode liefert true, wenn die vorliegende LibSakService Instanz in Verbindung mit einer Singer-Instanz steht, sonst false. static bool LibSakService::isInitialized() Diese Auskunftsmethode liefert true, wenn die Bibliothek initialisiert wurde und unversehrt ist. Sie ist statisch und damit unabhängig vom Vorliegen einer LibSakService-Instanz. bool LibSakService::LoadObject(const int index, const uBuffer &selector, uBuffer &content)


Diese Methode liefert das mit dem Selektor adressierte Objekt im index-ten Ablagefach und den Rückgabewert true, wenn eine Signer-Instanz angeschlossen ist, sonst false. bool LibSakService::LoadObject(const int index, const uBuffer &selector, bool &exists, uBuffer &content) Diese Methode liefert das mit dem Selektor adressierte Objekt im index-ten Ablagefach, den Indikator, ob das selektierte Objekt vorliegt und den Rückgabewert true, wenn eine Signer-Instanz angeschlossen ist, sonst false. void LibSakService::Release() Diese Methode löscht die vorliegende LibSakService-Instanz mit den zugehörigen Ressourcen. bool LibSakService::StoreObject(const uBuffer &meta, const uBuffer &format, const uBuffer &objectdata, const uBuffer &parameter, const uBuffer &objectsubdata) Diese Methode dient der Übertragung eines Datenpuffers mit Metadaten des in dem mit format angegebenen Formats, dem Paramterblock und detachten Daten an die angeschlossene Signer-Instanz. Nach erfolgreicher Übertragung und Annahme von der Signer-Instanz liefert sie true, sonst false. bool LibSakService::VerifyObjects() Diese Methode liefert true, wenn eine Signer-Instanz angeschlossen ist, in ihr mindestens ein Ablagefach gefüllt ist, das Ablagefach verifizierbaren Inhalt hat und alle Verifikationen mit dem Ergebnis Valide ausgeführt werden konnten, andernfalls liefert sie false.


6.4 Referenzen Öffentliche Dokumente [Common PKI] COMMON PKI SPECIFICATIONS FOR INTEROPERABLE APPLICATIONS, VERSION

2.0, T7 & TeleTrust, Januar 2009 [ISO/IEC 32000-1] Document management -- Portable document format -- Part 1: PDF 1.7,

Adobe Systems Incorporated, 2008 [PDF] PDF Reference - Adobe Portable Document Format, Version 1.7, Adobe

Systems Incorporated, November 2006 (siehe auch: ISO 32000-1) [RFC2560] X.509 Internet Public Key Infrastructure - Online Certificate Status Protocol

– OCSP, The Internet Society, Juni 1999 [RFC3161] Internet X.509 Public Key Infrastructure - Time-Stamp Protocol (TSP), The

Internet Society, August 2001 [RFC3280] Internet X.509 Public Key Infrastructure Certificate and Certificate

Revocation List (CRL) Profile, The Internet Engineering Task Force (IETF), April 2002

[RFC3629] UTF-8, a transformation format of ISO 10646, The Internet Society, November 2003

[RFC4646] Tags for Identifying Languages, The Internet Society, September 2006 [RFC5054] Using the Secure Remote Password (SRP) Protocol for TLS

Authentication, The Internet Engineering Task Force (IETF), November 2007

[RFC5652] Cryptographic Message Syntax (CMS), IETF Trust - Standards Track, September 2009

[RSA PKCS#7] PKCS #7: Cryptographic Message Syntax Standard, Version 1.5, RSA Laboratories, November 1993 (siehe auch: RFC 5652)

[XAdES] XML Advanced Electronic Signatures (XAdES), Version 1.3.2, European Telecommunications Standards Institute (ETSI), März 2006

[XML-DSig] XML Signature Syntax and Processing, World Wide Web Consortium (W3C), Juni 2008,

http://www.w3.org/

http://www.w3.org/


6.5 Glossar E.APP1 Schnittstelle zum bidirektionalen Datenaustausch zwischen Fachapplika-

tion und SAK. Sie wird zur Übertragung von Dokumentdaten und Steuerbefehlen an die SAK, zur Abholung von Ergebnissen und zur Entgegennahme von Anforderungen (OCSP- und Zeitstempel-Anfragen) aus der SAK, je nach Ausprägung der Fachapplikation, asynchron oder synchron verwendet.

E.APP2 Bibliotheksschnittstelle zum synchronen, bidirektionalen Datenaustausch zwischen einer App auf einem Mobilgerät oder einer Fachapplikation auf einem entfernten Desktoprechner und der SAK. Die Verwendung der Schnittstelle ist optional.

E.CARD Schnittstelle zu Kartenlesern und darin betriebenen Smartcards (SSEE). Die Schnittstelle dient der Abstraktion der verfügbaren Kartenleserschnitt-stellen des Betriebssystems. Sie wird von der SAK erzeugt und ausschließlich lesend verwendet.

E.DISPLAY Schnittstelle zur Anzeige von Dialogen (Statusanzeige, Detailanzeige) und zur Benutzerinteraktion mit der SAK.

E.SYSTEM Schnittstelle zwischen SAK und Betriebssystem. Insbesondere das Lesen der Konfigurationsdatei und die Ausgabe des Exportergebnisses in das Dateisystem sind über diese Schnittstelle realisiert.

Documents

Infotech Signer Common Criteria Evaluation · Dieses Dokument beinhaltet das Benutzerhandbuch (AGD) der Komponente „ Infotech Signer“