Entdecken Sie eBooks
Kategorien
Entdecken Sie Hörbücher
Kategorien
Entdecken Sie Zeitschriften
Kategorien
Entdecken Sie Dokumente
Kategorien
Produktversion 3.0
Dokumentversion 1.2.12
Erstellungsdatum 09. Januar 2008
Irrtümer und technische Änderungen vorbehalten. Im Zuge der Produktentwicklung behalten sich Authen-
tiDate Deutschland GmbH und AuthentiDate International AG das Recht vor Änderungen an Produkten
und Leistungen, auch ohne vorherige Benachrichtigung, vorzunehmen.
Seite 2 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Inhaltsverzeichnis
Abbildungsverzeichnis .............................................................................................................. 5
Tabellenverzeichnis ................................................................................................................... 6
1 Einleitung ............................................................................................................................ 8
1.1 Aufbau des Handbuchs ................................................................................................ 8
1.2 Einsatzbereich .............................................................................................................. 9
1.3 Prozessumgebung (stark/schwach).............................................................................. 9
1.4 Vorgangs-/Auftragssteuerung (Signaturerzeugung/Signaturprüfung) ........................ 11
1.5 Sichere Verzeichnisse ................................................................................................ 12
1.6 Authentisierung........................................................................................................... 12
2 Konfiguration von SLMBC............................................................................................... 14
2.1 Hauptkonfiguration ..................................................................................................... 14
2.1.1 Element <httpServer>......................................................................................... 15
2.1.2 Element <clientNetworkAccessParameter> ....................................................... 17
2.1.3 Element <logging>.............................................................................................. 20
2.1.4 Element <evgLogging>....................................................................................... 21
2.1.5 Element <weakProcessBoundEnvironment> ..................................................... 23
2.1.6 Element <knownAttributeOid> ............................................................................ 24
2.1.7 Element <authenticationPolicies>....................................................................... 24
2.1.8 Element <license> .............................................................................................. 25
2.1.9 Element <xmlProtocolHandlerPool>................................................................... 25
2.2 Nebenkonfiguration Chipkartenleser .......................................................................... 41
2.3 Nebenkonfiguration Benutzer ..................................................................................... 42
2.3.1 Hashwerte für Benutzerpasswörter .................................................................... 43
2.4 Nebenkonfiguration Gruppen ..................................................................................... 46
2.4.1 Hashwerte für Gruppenkonfigurationen.............................................................. 48
3 SLMBC-Schnittstelle ........................................................................................................ 51
3.1 Einsatzszenarien ........................................................................................................ 52
3.1.1 Vollständige SAK zur Signaturerstellung ............................................................ 52
3.1.2 Vollständige SAK zur Signaturprüfung ............................................................... 53
3.2 F1Sign – Signaturerstellung zu Hashwerten .............................................................. 54
3.2.1 F1Sign Anfragedokument ................................................................................... 55
3.2.2 F1Sign Antwortdokument ................................................................................... 57
3.2.3 F1Sign Fehlerdokument ..................................................................................... 57
3.3 F2Verify – Signaturprüfung zu Hashwerten................................................................ 58
3.3.1 F2Verify Anfragedokument ................................................................................. 58
3.3.2 F2Verify Antwortdokument ................................................................................. 59
3.3.3 F2Verify Fehlerdokument ................................................................................... 60
3.4 F3Lock – Anlegen eines Auftrags............................................................................... 61
3.4.1 F3Lock Anfragedokument................................................................................... 62
3.4.2 F3Lock Antwortdokument ................................................................................... 64
3.4.3 F3Lock Fehlerdokument ..................................................................................... 64
3.5 F4FetchTimeStamp – Anlegen eines Auftrags ........................................................... 65
3.5.1 F4FetchTimestamp Anfragedokument ............................................................... 66
3.5.2 F4FetchTimestamp Antwortdokument................................................................ 66
3.5.3 F4FetchTimestamp Fehlerdokument.................................................................. 66
3.6 F5SignFile – Ausführung eines Signierauftrags ......................................................... 67
3.6.1 F5SignFile Anfragedokument ............................................................................. 67
3.6.2 F5SignFile Antwortdokument.............................................................................. 68
3.6.3 F5SignFile Fehlerdokument................................................................................ 68
3.7 F6VerifyFile – Ausführung eines Verifikationsauftrags ............................................... 69
3.7.1 F6VerifyFile Anfragedokument ........................................................................... 69
Seite 3 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Seite 4 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Abbildungsverzeichnis
Seite 5 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Tabellenverzeichnis
Seite 6 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Seite 7 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
1 Einleitung
SLMBC kann alternativ zur Verwendung als SAK auch als technische Komponente für Zertifizie-
rungsdiensteanbieter mit Bestätigung gemäß Deutschem Signaturgesetz zwecks Erzeugung
qualifizierter elektronischer Zeitstempel eingesetzt werden. Eine Verwendung als SAK schließt
jedoch vorgenannten Einsatz aus.
Nähere Informationen hierzu entnehmen Sie bitte dem "Benutzer- und Administrationshandbuch
SLMBC als technische Komponente für ZDAs zur Erzeugung von Zeitstempeln".
Das vorliegende Handbuch „AuthentiDate SLM Base Component“ wendet sich an zwei ver-
schiedene Gruppen:
• Administratoren und
• Softwareentwickler
Administratoren werden durch dieses Dokument in die Lage versetzt, SLMBC zu konfigurieren
und zu warten.
Softwareentwickler sind mit diesem Dokument in der Lage, aus ihren eigenen Applikationen
heraus SLMBC anzusprechen und dessen Feature zu nutzen.
Bitte beachten Sie: Bei der Integration des SLMBC als technische Komponente für Zertifizie-
rungsdienste oder als Signaturanwendungskomponente müssen alle in diesem Handbuch ent-
haltenen Hinweise, die für einen sicheren Betrieb des SLMBC notwendig sind, vom Hersteller
der Anwendung („Integrator“) an die Endbenutzer dieser Anwendung weitergegeben werden.
Zu diesem Zweck sind alle derartigen Hinweise besonders gekennzeichnet.
Das vorliegende Handbuch “AuthentiDate SLM Base Component“ unterteilt sich in zwei Berei-
che: Die Administration von SLMBC bei Endanwendern und die Einbindung von SLMBC in Ap-
plikationen der jeweiligen Hersteller über die SLMBC-Schnittstelle.
Das Kapitel „Konfiguration von SLMBC“ behandelt den administrativen Bereich der SLMBC-
Dokumentation. Es beschreibt in allen Details die Konfigurationsdateien von SLMBC und wel-
che Parameter angepasst werden können.
Das Kapitel „Protokoll- und Fehlermeldungen“ dokumentiert die Fehlernummern und -texte, die
bei der Kommunikation mit SLMBC auftreten können. Außerdem werden mögliche Protokollein-
träge erläutert.
Seite 8 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
1.2 Einsatzbereich
Obwohl SLMBC auch in der Lage ist, auf Einzelplatz-PCs Signaturen durch manuelle Anforde-
rung zu erzeugen bzw. zu verarbeiten, ist es für den Bereich der hochvolumigen Erzeugung
bzw. Verarbeitung von qualifizierten Signaturen und Zeitstempeln zum Einsatz auf unterschied-
lichen Betriebssystemen (Windows, Linux) ausgelegt und dient der Optimierung und Automati-
sierung elektronischer Prozesse (Stapelsignaturen und Massensignaturen).
Bei der Erstellung qualifizierter elektronischer Signaturen schützt SLMBC die zu signierenden
Daten aktiv während des gesamten Prozesses der Signaturerstellung. Dazu gehören das Anle-
gen des Auftrags, die optionale Anzeige der Daten und das Erzeugen von Signaturen.
Für die Erzeugung von Signaturen können mehrere sichere Chipkartenterminals – gegebenen-
falls gruppiert - gleichzeitig verwendet werden. Bei der Erzeugung von Signaturen können opti-
onal qualifizierte Zeitstempel zum Nachweis des Zeitpunktes der Erstellung eingeholt und in die
Signatur eingebettet werden.
Bei der Prüfung elektronischer Signaturen schützt SLMBC die zu prüfenden Daten zusammen
mit den Prüfergebnissen aktiv während des gesamten Prozesses der Signaturprüfung. Dazu
gehören das Anlegen des Auftrags, die optionale Anzeige der Daten und das Prüfen der Signa-
turen.
Die Prüfung erfolgt nach Anforderung durch den Prüfenden entweder teilweise oder vollständig
unter Beachtung hinreichend aktueller Auskünfte zuständiger Zertifizierungsdienste zu der Exis-
tenz und Sperrung von Zertifikaten. Diese Auskünfte holt SLMBC bei Bedarf vom jeweiligen
Zertifizierungsdienst ein. In die zu prüfenden Signaturen eingebettete qualifizierte Zeitstempel
werden auf gleichem Wege überprüft.
Diese Prüfung findet in unterschiedlichen Prüftiefen, maximal bis zur Erlangung von nicht zu-
rückweisbaren Prüfergebnissen statt. Die Prüfergebnisse können dann ebenfalls mit den elek-
tronischen Dokumenten und Signaturen archiviert werden.
Hierbei ist es wichtig die Begriffe Anforderung und Erstellung von Zeitstempeln zu differenzie-
ren. Beim Einsatz von SLMBC bei einem Endkunden werden von SLMBC die Zeitstempel aus-
schließlich angefordert. Erstellt werden Zeitstempel bei (angezeigten oder akkreditierten) Zerti-
fizierungsdiensten in einer sicheren Server-Umgebung („Trust-Center“).
Nachfolgend werden die beiden Einsatzgebiete für den Einsatz als vollständige Signatur-
anwendungskomponente erläutert.
Seite 9 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
• Als schwach prozessgebundener Einsatz wird bezeichnet, wenn SLMBC auf einem
Arbeitsplatzsystem installiert ist, an dem ein Signaturkarteninhaber („Anwender“)
SLMBC die zu signierenden bzw. prüfenden Daten interaktiv zuführt. Die Zuführung ge-
schieht zwar immer über die Software-Applikation, die SLMBC dazu beauftragt, diese
wird aber durch den Anwender bedient.
Durch eine einfache Einstellung in der Hauptkonfigurationsdatei wird SLMBC mitgeteilt, in wel-
chem Einsatzumfeld gearbeitet wird. Für diese beiden Einsatzfelder erzwingt SLMBC unter-
schiedliche Abläufe der Vorgangsverarbeitung und unterstützt unterschiedliche Arten der Akti-
vierung und Deaktivierung von Signaturkarten.
Im stark prozessgebundenen Einsatz erlaubt SLMBC die Verwendung derselben Gruppe von
Signaturkarten durch mehrere Vorgänge gleichzeitig. Des Weiteren kann der Signaturkarten-
inhaber beim Starten des Dienstes einmalig durch Eingabe seiner PINs die Signaturkarten in-
nerhalb der Gruppe aktivieren und diese dann für einen längeren Zeitraum SLMBC zur Verfü-
gung stellen.
Voraussetzung für den stark prozessgebundenen Einsatz im Sinne des Signaturgesetzes ist die
Verwendung bestätigter Multisignatur-Signaturerstellungseinheiten (Multisignatur-SSEE); es
sind die Anforderungen der Multisignatur-SSEE zu erfüllen, d. h. sie dürfen ausschließlich in
besonders gesicherten Umgebungen, z. B. in einem Rechenzentrum, verwendet werden. Die
Anwendung (der Benutzer) muss dabei sicherstellen, dass die zu signierenden Daten plausibili-
siert werden und nur gleichartige Dokumente signiert werden.
Im schwach prozessgebundenen Einsatz hingegen nutzt ein Vorgang eine Gruppe exklusiv.
Nach Abschluss eines Vorgangs werden die Signaturkarten einer Gruppe automatisch deakti-
viert und müssen für die Bearbeitung des nächsten Vorgangs erneut aktiviert werden.
Mit der Aktivierung von Signaturkarten ist die Operation gemeint, mit der sich der Signaturkar-
teninhaber durch Eingabe seiner Identifikationsdaten gegenüber der Signaturkarte identifiziert
und diese daraufhin Signaturen erzeugen kann. Mit der Deaktivierung ist die Operation gemeint,
durch die die Signaturkarte dazu veranlasst wird, erst nach erneuter Authentifizierung des Be-
sitzers weitere Signaturen zu erzeugen.
Seite 10 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Der gesamte Prozess der Signaturverarbeitung (Erstellung und Prüfung von Signaturen und
Zeitstempeln) wird innerhalb von SLMBC durch eine Vorgangs- bzw. Auftragssteuerung umge-
setzt.
Diese Vorgangssteuerung wird intern für den Benutzer vollkommen transparent über eine so
genannte „Statemachine“ realisiert. Dies bedeutet, dass wie in einem Workflow-Prozess jeder
Auftrag, der an SLMBC übergeben wird, einen initialen Zustand hat und dann verschiedene
weitere Zustände durchläuft.
08:00 08:05
Schutz der Daten durch SLMBC
08:00 - 08:04
Den Zustand jedes Vorgangs kann der Benutzer jederzeit über SLMBC erfragen. Findet keine
Interaktion mit dem Benutzer statt, werden die Vorgänge vollkommen automatisiert verarbeitet
und wandern so von einem Zustand zum nächsten, bis sie verarbeitet wurden.
Die Vorgangssteuerung wurde für eine massenhafte und parallele Verarbeitung konzipiert. Das
bedeutet, dass der Benutzer SLMBC mehrere Aufträge gleichzeitig in Arbeit geben kann und
SLMBC jeden für sich sicher verarbeitet. Die Vorgänge werden dabei abhängig von der einge-
setzten Umgebung (Anzahl Chipkartenterminals, Prozessoren) in mehreren Prozessen (Mul-
tithreading) gleichzeitig verarbeitet.
09:00 09:15
Schutz der Daten durch SLMBC
09:02 - 09:12
Die Vorgangssteuerung verarbeitet und manipuliert für jeden Vorgang ein exklusiv zugeordne-
tes sicheres Verzeichnis (s. auch Kapitel 1.5 „Sichere Verzeichnisse“).
Seite 11 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Das sichere Verzeichnis enthält die vom Anwender übergebenen Daten. Während der aktiven
Erstellung bzw. Prüfung von Signaturen ist jeglicher Zugriff auf das sichere Verzeichnis aus-
schließlich SLMBC möglich. Zur restlichen Laufzeit eines Vorganges ist dem Benutzer (Soft-
ware-Applikation) und Anwendern der lesende Zugriff erlaubt, wohingegen nur SLMBC schrei-
ben und manipulieren darf.
Zwischen der Betrachtung eines Dokuments, der sicheren Eingabe der PIN am Kartenlesegerät
und der Signaturerstellung vergeht oftmals nur ein kurzer Zeitraum, der aber theoretisch aus
der Sicht eines Angreifers ausreicht, um Dokumente zu fälschen oder weitere Dokumente un-
entdeckt einem vorhandenen Stapel hinzuzufügen.
Um diese Art der Angriffsversuche zu unterbinden, übernimmt SLMBC aktiv den Schutz der zu
verarbeitenden Daten. Dabei unterstützt SLMBC die Absicherung von Benutzerdaten, Doku-
menten und eben auch Verzeichnissen.
Wird SLMBC zur Erstellung oder Prüfung von Signaturen betrieben, nimmt es die zu signieren-
den Dokumente in Form von Dateien entgegen. Die Dokumente werden in ein sicheres Ver-
zeichnis verschoben und verbleiben dort solange, bis ein Benutzer (Software-Applikation) ihre
Freigabe anfordert. Dies kann entweder nach der Erstellung bzw. Prüfung der Signaturen oder
aber auch vorzeitig geschehen.
SLMBC garantiert, dass entweder alle Signaturen erstellt bzw. geprüft werden oder der Prozess
keine Signaturen bzw. Prüfergebnisse erhält. Das heißt, für den Benutzer (Software-
Applikation) ist die Signaturerstellung und -prüfung für eine Menge von Dokumenten transakti-
onsorientiert.
1.6 Authentisierung
Bei jedem Aufruf einer Funktion von SLMBC identifiziert und authentifiziert SLMBC den aufru-
fenden Benutzer (Software-Applikation) anhand einer Benutzerkennung und eines Passwortes.
Dies dient dazu, die Berechtigung des Benutzers zum Aufruf der jeweiligen Funktion zu prüfen.
Verschiedene Benutzer können dabei dieselbe Benutzerkennung verwenden.
Für die Erstellung von Signaturen wird beim Aufruf der Funktion zur Erzeugung eines Signatur-
auftrages, beim Aufruf der Funktion zum Starten eines Signaturvorganges und beim Aufruf der
internen Funktion von SLMBC zur konkreten Erzeugung einer einzelnen Signatur eine weitere
Identifikation und Authentifizierung des Signaturkarteninhabers anhand einer Kennung und ei-
nes Passwortes durchgeführt. Sie dient SLMBC zum Zweck, die Berechtigung der Verwendung
einer konkreten Gruppe von Signaturerstellungseinheiten zu überprüfen.
Die Benutzerkennung zur Identifikation eines Benutzers (Software-Applikation) und die Benut-
zerkennung zur Identifikation eines Signaturkarteninhabers zu einer Gruppe von Signaturkarten
sind voneinander unabhängig.
Die Authentisierung des Besitzers einer Gruppe von Signaturkarten wird erst beim Aufruf der
internen Funktion von SLMBC zur Erzeugung einer einzelnen Signatur wirklich durchgeführt.
Die Funktionen zum Erzeugen eines Signaturauftrages und zum Starten der tatsächlichen Er-
stellung von Signaturen nehmen nur die Identifikation direkt beim Funktionsaufruf vor, während
Seite 12 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
sich SLMBC das zugehörige Passwort nur für den späteren Aufruf der internen Funktion merkt.
So wäre beim Erzeugen des Signaturauftrages eigentlich keine Angabe des Passwortes not-
wendig. Tatsächlich wird es aber durch SLMBC zum Vergleich mit dem Passwort verwendet,
welches der Benutzer beim Aufruf der Funktion zum Starten der Erstellung von Signaturen er-
neut angibt. Auf diese Weise wird bei der Funktion zum Starten der Urheber des Auftrages si-
cher identifiziert.
Seite 13 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Die Konfiguration von SLMBC geschieht ausschließlich über XML-Dateien. Es gibt eine Haupt-
konfigurationsdatei und mehrere Nebenkonfigurationsdateien.
Mit der Hauptkonfigurationsdatei, die beim Start von SLMBC als Parameter mit angegeben
wird, wird das gesamte Verhalten des Systems gesteuert.
2.1 Hauptkonfiguration
Der Name der Konfigurationsdatei wird SLMBC beim Start als Parameter übergeben. Das For-
mat dieser Datei ist wie bei allen anderen Konfigurationsdateien XML. Das XML-Schema dieser
Datei wird in mehreren Schema-Dateien (mit der Endung .xsd) definiert, die in elektronischer
Form in dem von AuthentiDate ausgelieferten komprimierten Archiv unter dem Verzeichnis
\developer\xml-schemata enthalten sind. Dabei ist das Wurzelelement <slmbcServer> in der
Datei slmbcServer.xsd definiert. Alle weiteren Dateien werden von dort aus namentlich refe-
renziert. Der Inhalt der Schema-Dateien wird hier nicht wiedergegeben, weil dies den Rahmen
dieses Dokuments überschreiten würde.
Die Konfiguration lässt sich hierbei in zwei Arten einteilen, den allgemeinen Teil und die Konfi-
guration der einzelnen Funktionen F1 – F14. F11 steht nicht zur Verfügung.
Die nachfolgenden Darstellungen und Tabellen erklären die einzelnen XML-Tags, die durch
erfahrene Administratoren bzw. Entwickler angepasst werden können.
Hierbei werden die Konfigurationsoptionen durch eine Angabe in der dritten Spalte („Level“)
folgendermaßen klassifiziert:
Zuerst werden die Parameter des allgemeinen Teils beschrieben (2.1.1 bis 2.1.7) und anschlie-
ßend die Elemente zu den einzelnen Funktionen von SLMBC. Hierbei ist zwischen der Konfigu-
ration der Funktionen von SLMBC und dem Zugriff auf diese Funktionen über die Schnittstelle
von SLMBC zu unterschieden.
Mit der Konfiguration der Funktionen sind die Einstellungen und das Reaktionsverhalten von
SLMBC auf Anfragen durch den Benutzer (Software-Applikation) gemeint, während die Schnitt-
stelle von SLMBC die eigentlichen Anfragen an diese Funktionen beschreibt
(siehe Kapitel 3 „SLMBC-Schnittstelle“).
Seite 14 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
schemata\, wobei hier zwischen der administrativen Konfiguration und der Entwickler-
Schnittstelle unterschieden wird. Die Schemata des erstgenannten befinden sich in dem Unter-
verzeichnis \configuration\ und die des letzteren in dem Unterverzeichnis \interface\.
Mit dem Element <httpServer> wird eingestellt, unter welcher Adresse (resp. unter welchen Ad-
ressen) und mit welchem Protokoll SLMBC angesprochen werden kann.
Im Element <listeners> kann zunächst eine beliebige Anzahl von Elementen <httpsListener>
aufgeführt werden. Mindestens ein direkt eingebettetes Element muss im umgebenden <liste-
ners> Element aufgeführt werden. Mit jedem <httpsListener> Element wird definiert, dass
SLMBC über eine bestimmte Adresse per HTTPS erreichbar ist.
Für die Konfiguration eines HTTPS-Ports steht das XML-Tag <httpsSignerInformation> samt
aller eingebetteten Tags zur Verfügung.
Im <baseSignerInformation> Element wird dann definiert, wo der private SSL-Schlüssel für das
HTTPS-Protokoll zu finden ist. Zum Betreiben von SLMBC wird eine PKCS#12-Datei benötigt,
welche den privaten Schlüssel für die SSL-Kommunikation und das zugehörige SSL-Zertifikat
unter einem bestimmten Eintrag enthält.
Eine PKCS#12-Datei mit SSL-Zertifikat kann entweder von einem entsprechenden Anbieter wie
Verisign oder TC Trustcenter erworben werden oder mit einem Tool wie OpenSSL erzeugt wer-
den. Die genaue Vorgehensweise hängt vom Einsatzzweck von SLMBC ab. Auf keinen Fall darf
die mitgelieferte PKCS#12-Datei im Produktivbetrieb genutzt werden.
Die Elemente <supportedCipherSuite> und <servlet> dürfen nicht geändert werden. Details, die
über die unten genannte Information hinausgehen, sind in den XML-Schemadateien zu finden.
01 <httpServer>
02 <listeners>
03 <httpsListener>
04 <hostname>localhost</hostname>
05 <port>443</port>
06 <minThreads>5</minThreads>
07 <maxThreads>10</maxThreads>
08 <maxIdleTimeMs>0</maxIdleTimeMs>
09 <httpsSignerInformation>
10 <baseSignerInformation>
11 <joinedSignerInformation>
12 <keyStoreJoinedSignerInformation>
13 <keyStore>
14 <keyStoreDef>
15 <keyStoreType>PKCS12</keyStoreType>
16 <keyStoreSource>
17 <uriStoredData>file:serverKey.p12</uriStoredData>
18 </keyStoreSource>
19 <password>pwdkey</password>
20 </keyStoreDef>
21 </keyStore>
22 <keyAlias>aliasKey</keyAlias>
23 <keyPassword>pwdkey</keyPassword>
24 </keyStoreJoinedSignerInformation>
Seite 15 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
25 </joinedSignerInformation>
26 </baseSignerInformation>
27 </httpsSignerInformation>
28 <supportedCipherSuite>TLS_RSA_WITH_AES_256_CBC_SHA
29 </supportedCipherSuite>
30 <supportedCipherSuite>SSL_RSA_WITH_3DES_EDE_CBC_SHA
31 </supportedCipherSuite>
32 </httpsListener>
33 </listeners>
34
35 <servlet>
36 <name>Interface for sigAnf</name>
37 <httpContext>/xml</httpContext>
38 <servletClass>de.authentidate.module.
39 xmlproto.XmlServlet</servletClass>
40 </servlet>
41
42 <servlet>
43 <name>File download handler</name>
44 <httpContext>/slmbc-download/*</httpContext>
45 <servletClass>de.authentidate.sir.
46 orderbook.DownloadServlet</servletClass>
47 </servlet>
48
49 <useDefaultNotFoundHandler>true</useDefaultNotFoundHandler>
50 </httpServer>
Seite 16 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Die hier genannten Daten können beispielsweise bei der Konfiguration der Funktion F1 genutzt
werden. Falls die Signatur mit einem Zeitstempel abgesichert werden soll, wird bei der Konfigu-
ration der Funktion F1 nur eine Referenz auf den hier definierten Zeitstempelnutzer angegeben.
Bei der Konfiguration des Zeitstempelnutzers kann dann auf eine URL-Verbindung, diese wie-
derum auf einen Proxy und dieser daraufhin auf die erstgenannte Benutzer-zu-Passwort-
Konfiguration zurückgreifen.
Dies bietet den Vorteil, dass die Netzwerk-Zugangsdaten nur an einer Stelle geändert werden
müssen, da alle weiteren Eigenschaften diese referenzieren. Alle Subelemente der genannten
fünf Elemente können mehrfach vorkommen.
Seite 17 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
01 <authenticationConfigs>
02 <httpAuthDef id="tsaAuth01">
03 <basicAuthDef>
04 <userName>streng</userName>
05 <password>geheim</password>
06 </basicAuthDef>
07 </httpAuthDef>
08 <httpAuthDef id="auth4InternalSlmbcCall">
09 <basicAuthDef>
10 <userName>admin</userName>
11 <password>pwadmin</password>
12 </basicAuthDef>
13 </httpAuthDef>
14 </authenticationConfigs>
01 <proxyConfigs>
02 <proxyServerConfigDef id="ID000001">
03 <host>localhost</host>
04 <port>9090</port>
05 <httpAuth>
06 <httpAuthRef>
07 <httpAuthDefId>auth4proxy</httpAuthDefId>
08 </httpAuthRef>
09 </httpAuth>
10 </proxyServerConfigDef>
11 </proxyConfigs>
01 <httpAccessConfigs>
02 <httpClientConfigDef id="defaultHttpAccessConfig"/>
03
04 <httpClientConfigDef id="internalSlmbcCallAccessConfig">
05 <authentication>
06 <httpAuthRef>
07 <httpAuthDefId>auth4InternalSlmbcCall</httpAuthDefId>
08 </httpAuthRef>
09 </authentication>
10 </httpClientConfigDef>
Seite 18 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
11
12 <httpClientConfigDef id="tsaAccount01">
13 <authentication>
14 <httpAuthRef>
15 <httpAuthDefId>tsaAuth01</httpAuthDefId>
16 </httpAuthRef>
17 </authentication>
18
19 <proxyServerConfig>
20 <proxyServerConfigDef>
21 <host>localhost</host>
22 <port>8080</port>
23 <httpAuth>
24 <httpAuthRef>
25 <httpAuthDefId>proxytest</httpAuthDefId>
26 </httpAuthRef>
27 </httpAuth>
28 </proxyServerConfigDef>
29 </proxyServerConfig>
30
31 <sslOptions>
32 <trustedServerCert>
33 <encodedCertificate>
34 <certType>X.509</certType>
35 <securityProviderName>AuthentiDate</securityProviderName>
36 <certSource>
37 <hexEncodedData>308202…0b7a7f</hexEncodedData>
38 </certSource>
39 </encodedCertificate>
40 </trustedServerCert>
41 </sslOptions>
42 </httpClientConfigDef>
43 </httpAccessConfigs>
01 <timestampClients>
02 <timestampClientDef id="tsa01">
03 <url>http://www.authentidate.de</url>
04 <config>
05 <httpClientConfigRef>
06 <httpClientConfigDefId>tsaAccount01</httpClientConfigDefId>
07 </httpClientConfigRef>
Seite 19 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
08 </config>
09 <defaultTimeStampFormatOidOrName>RFC3161
10 </defaultTimeStampFormatOidOrName>
11 </timestampClientDef>
12 </timestampClients>
Mit dem Element <logging> wird eingestellt, in welcher Detailtiefe und wohin Logdaten zu
schreiben sind.
Die für den Produktionsbetrieb empfohlene Einstellung ist INFO. In diesem Detailgrad werden
nicht zu viele Ressourcen für die Aufzeichnung von Ereignissen verwendet, es werden aber
dennoch der Beginn und das Ende eines Vorganges, das explizite (also nicht implizit durch
Vorgänge vorgenommene) Aktivieren und Deaktivieren von Signierkarten sowie das Einstecken
und Herausnehmen von Signierkarten aus dem Chipkartenlesegerät protokolliert.
01 <logging>
02 <logSinks>
03 <logLevel>DEBUG</logLevel>
04 <logSink>
05 <logFile>
06 <fileName>log/signer.log</fileName>
07 <maxFileSize>10485760</maxFileSize>
08 <oldLogsToKeep>30</oldLogsToKeep>
09 </logFile>
10 </logSink>
11 </logSinks>
12 </logging>
Seite 20 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Mit dem Element <evgLogging> wird das Logging für den gemäß Signaturgesetz benötigten
Betrieb konfiguriert. Dazu gehören z. B. die Neukonfiguration der Gruppen, das Erzeugen eines
neuen Auftrages oder der Zugriff auf die Signaturkarte. Das Protokoll wird dabei in einer eige-
nen Datei abgelegt.
Bitte beachten Sie: Die für den Produktionsbetrieb empfohlene Einstellung ist EVG_2. Die Ein-
stellung EVG_NONE darf nicht verwendet werden, falls der EVG in einem signaturgesetzkon-
formen Umfeld eingesetzt werden soll.
01 <evgLogging>
02 <secureLog>
03 <secureLoggingDef id="sl001">
04 <iSAMFileSecureLoggingAppenderDef>
05 <storageFolder>log</storageFolder>
06 <createIndex>true</createIndex>
07 <syncAfterEachLogWrite>true</syncAfterEachLogWrite>
08 <linkFiles>true</linkFiles>
09 <filePrefix>
10 <openLog>ol</openLog>
11 <timestampedLog>tl</timestampedLog>
12 </filePrefix>
13 <fileSuffix>
14 <dataFile>.log</dataFile>
15 <indexFile>.idx</indexFile>
16 <timestampFile>.tsr</timestampFile>
17 </fileSuffix>
18 <period4OpenLog>
19 <metronomeFactoryName>
Seite 21 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Seite 22 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Mit dem Element <weakProcessBoundEnvironment> wird die Art der Prozessbindung konfigu-
riert (siehe Kapitel 3.1.1.3 „Funktion F1Sign“).
01 <weakProcessBoundEnvironment>true</weakProcessBoundEnvironment>
Seite 23 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Mit dem Elementen <knownAttributeOid> werden die OIDs (Object Identifier) definiert, mit de-
nen die Eigenschaften der Attribute eines Zertifikates beschrieben werden. Dieses Element
kann mehrfach vorkommen.
01 <knownAttributeOid>
02 <oid>0.2.262.1.10.7.52</oid>
03 <name>LiabilityText</name>
04 <restriction>true</restriction>
05 </knownAttributeOid>
01 <authenticationPolicies>
02 <maxTryLimit>
03 <maxTryLimitForAuthentication>3</maxTryLimitForAuthentication>
04 <maxTryLimitForInformation>5</maxTryLimitForInformation>
05 <maxTryLimitForAuthorization>3</maxTryLimitForAuthorization>
06 </maxTryLimit>
07 <passwordPolicy>
08 <requiredPasswordLength>10</requiredPasswordLength>
09 <requiredDigitNumbers>3</requiredDigitNumbers>
10 <requiredSpecialChars>2</requiredSpecialChars>
11 <requiredUniqueChars>5</requiredUniqueChars>
12 </passwordPolicy>
13 </authenticationPolicies>
Seite 24 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Mit dem Element <license> wird der Pfad zu den zum Betrieb des SLMBC erforderlichen Li-
zenzdateien festgelegt.
01 <license>
02 <licenseFile>config/license.xml</licenseFile>
03 <counterFile>config/counter.xml</counterFile>
04 </license>
Das Element <xmlProtocolHandlerPool> besteht aus den Einstellungen für die Anzahl der vor-
gefertigten XML-Parserobjekte, den Zugangsüberprüfungen der einzelnen Funktionen (Element
<accessAA>) und den <implementationMap>-Elementen, die die einzelnen Funktionen darstel-
len. Details, die über die unten genannte Information hinausgehen, sind in den XML-Schema-
dateien zu finden; die Elemente dürfen nicht verändert werden.
01 <xmlProtocolHandlerPool>
02 <numHandlers>10</numHandlers>
03 <xmlConverterPool>
04 <numberOfInstances>10</numberOfInstances>
05 <namespacePrefixMapperClassName>
06 de.authentidate.sir.NamespacePrefixMapperImpl
07 </namespacePrefixMapperClassName>
08 <contextName>
09 de.authentidate.xml.ns.datastruct.slmbc.functions</contextName>
10 </xmlConverterPool>
11 <xmlProtocolHandler>
12 <maxRequestSize>102400</maxRequestSize>
13 ...
Seite 25 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Das Element <xmlProtocolHandlerPool> ist hier noch nicht beendet, sondern wird in den nächs-
ten Abschnitten weiter beschrieben.
Das Element <accessAA> steuert die Zugriffskontrolle der Benutzer auf die einzelnen Funktio-
nen der SLMBC-Schnittstelle.
Die hier konfigurierten User (Benutzer) erhalten Zugriff auf die konfigurierten Funktionen der
SLMBC-Schnittstelle. Bei einem Aufruf der Schnittstelle wird der Benutzer (Software-
Applikation) gegenüber SLMBC mittels Basic Authentication des HTTP-Requests authentifiziert.
Dabei werden der übergebene Benutzername und sein Passwort mit den hier konfigurierten
Werten verglichen. Nur bei Identität beider Werte führt SLMBC die Funktion im Namen des Be-
nutzers aus (siehe Kapitel 2.3 „Nebenkonfiguration Benutzer“). Das Kennwort wird während der
Kommunikation durch das SSL-Protokoll geschützt.
01 <accessAA>
02 <userAAServiceDef id="accessUaa">
03 <memoryUserAAService>
04 <userAAData>
05 <userId>User01</userId>
06 <secretFingerprint>
07 <hashAlgo>SHA-1</hashAlgo>
08 <hashValue>vQaWv3QA0oXH/t3wYlmYynqPDe8=</hashValue>
09 </secretFingerprint>
10
11 <authorization>
12 <thing>F1</thing>
13 <limit> - </limit>
14 </authorization>
15
16 <authorization>
17 <thing>F2</thing>
18 <limit> - </limit>
19 </authorization>
20 ...
Seite 26 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
01 <signingRequestHandlerConfig>
02 <maxSignRetries>2</maxSignRetries>
03 <retryTimeoutMillis>7000</retryTimeoutMillis>
04 <activationMode>onRequest</activationMode>
05 <supportedSignAlgo>SHA1withRSA</supportedSignAlgo>
06 <supportedSignAlgo>RIPEMD160withRSA</supportedSignAlgo>
07 <signServiceTemplateFileName>
08 signServiceTemplate.xml</signServiceTemplateFileName>
09
10 <signingOpLimitations>
11 <activationPeriod>0</activationPeriod>
12 <signatureOpLimitDuringActivationPeriod>
13 0</signatureOpLimitDuringActivationPeriod>
14 </signingOpLimitations>
15
16 <timestampAccess>
17 <contentTimestampSource includeTimestampAsDefault="false">
18 <timestampAccount>
19 <timestampAccountRef>
20 <timestampAccountDefId>tsa01</timestampAccountDefId>
21 </timestampAccountRef>
22 </timestampAccount>
23 <preferredDigestAlgorithm>
24 <digestAlgorithmNameOrOid>SHA-1</digestAlgorithmNameOrOid>
25 </preferredDigestAlgorithm>
26 <requestRetryLimit>3</requestRetryLimit>
27 </contentTimestampSource>
28 <signatureTimestampSource includeTimestampAsDefault="false">
29 <timestampAccount>
30 <timestampAccountRef>
31 <timestampAccountDefId>tsa02</timestampAccountDefId>
32 </timestampAccountRef>
33 </timestampAccount>
34 <preferredDigestAlgorithm>
35 <digestAlgorithmNameOrOid>SHA-1</digestAlgorithmNameOrOid>
36 </preferredDigestAlgorithm>
37 <requestRetryLimit>3</requestRetryLimit>
38 </signatureTimestampSource>
39 </timestampAccess>
40
41 <dynamicConfig>
42 <content>
43 <uriStoredData>file:config/token.xml</uriStoredData>
44 </content>
45 <confirmationSubDir>confirmed</confirmationSubDir>
46 <certPathCertsSubDir>ca-and-root-certs</certPathCertsSubDir>
47 <userAFileName>user.xml</userAFileName>
48 <reconfigPeriod>
49 <metronomeFactoryName>
50 general metronome factory</metronomeFactoryName>
51 <threadName>ConfigWatchdog</threadName>
52 <periodMillis>15000</periodMillis>
53 </reconfigPeriod>
54 <tokenJobWorkerPeriod>
Seite 27 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
55 <metronomeFactoryName>
56 general metronome factory</metronomeFactoryName>
57 <threadName>TokenJobManager/Worker</threadName>
58 <periodMillis>650</periodMillis>
59 </tokenJobWorkerPeriod>
60 <terminalInitMessage>Geraet gefunden</terminalInitMessage>
61 </dynamicConfig>
62
63 <commonGroupConfig>
64 <unmappedSignerFoundMessage>
65 : Signaturkarte ist keiner Gruppe zugeordnet
66 </unmappedSignerFoundMessage>
67 <groupIdDigestAlgo>
68 <algorithmName>SHA-1</algorithmName>
69 <requestedSecurityProvider>BC</requestedSecurityProvider>
70 </groupIdDigestAlgo>
71 </commonGroupConfig>
72
73 <ocfConfig>
74 <property>
75 <key>OpenCard.services</key>
76 <value>de.telesec.opencard.tcos20.
77 service.TCOS2CardServiceFactory</value>
78 </property>
79 <property>
80 <key>KOBIL.baudrate</key>
81 <value>57600</value>
82 </property>
83 <property>
84 <key>OpenCard.trace</key>
85 <value>opencard:5 de:5 com:5</value>
86 </property>
87 <property>
88 <key>OpenCard.trace.eventsOnly</key>
89 <value>true</value>
90 </property>
91 </ocfConfig>
92 </signingRequestHandlerConfig>
Seite 28 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Seite 29 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Das Element <implementationMap> beinhaltet das Element <validatorConfig>, mit der die
Funktion F2VerifyRequest konfiguriert werden kann.
01 <validatorConfig>
02 <certPathValidator>
03 <caches>
04 <persistentCacheDir>/persistentCache</persistentCacheDir>
05 <validatedCertPathCache>
06 <cacheUnits>30</cacheUnits>
07 <toleranceUnits>5</toleranceUnits>
08 <validationModel>chain</validationModel>
09 <garbageCollectionPeriod>600000</garbageCollectionPeriod>
10 </validatedCertPathCache>
11 </caches>
12
13 <trustAnchors>
14 <trustAnchor>
15 <certFile>trustAnchorCerts/RegTP/4R-CA.pem</certFile>
16 <qualified>true</qualified>
17 <public>true</public>
18 </trustAnchor>
19 <trustAnchor>
20 <certFile>trustAnchorCerts/RegTP/5R-CA.pem</certFile>
21 <qualified>true</qualified>
22 <public>true</public>
23 </trustAnchor>
24 </trustAnchors>
25
26 <certSelectors>
27 <certSelector>
28 <name>von RegTP ausgestellte Zertifikate</name>
29 <issuerStartsWith>O=Bundesnetzagentur,C=DE</issuerStartsWith>
30 </certSelector>
31 <certSelector>
32 <name>von TeleSec ausgestellte Zertifikate</name>
33 <issuerStartsWith>O=Deutsche Telekom AG,C=DE</issuerStartsWith>
34 </certSelector>
35 </certSelectors>
36
37 <certStatusSources>
38 <certStatusSource>
39 <resourceName>ALTE anonymous PKD der RegTP</resourceName>
40 <active>true</active>
41 <certStatusResourceReference>
42 <aPkdFile>
43 <url>file:persistentCache/anonymous PKD der
44 RegTP/aPkdFile.ttp</url>
Seite 30 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
45 <cachePersistently>false</cachePersistently>
46 <downloadPeriod>86700</downloadPeriod>
47 </aPkdFile>
48 </certStatusResourceReference>
49 <certSelectorRef>von RegTP ausgestellte
50 Zertifikate</certSelectorRef>
51 <issuerStartsWith>O=Regulierungsbeh\C3\B6rde f\C3\BCr
52 Telekommunikation und Post,C=DE</issuerStartsWith>
53 </certStatusSource>
54
55 <certStatusSource>
56 <resourceName>OCSP Server der Bundesnetzagentur</resourceName>
57 <active>true</active>
58 <certStatusResourceReference>
59 <ocspResponder>
60 <url>http://ocsp.nrca-ds.de:8080/ocsp-ocspresponder</url>
61 <substituteThisUpdateByProducedAt>true
62 </substituteThisUpdateByProducedAt>
63 <unknownInfoAction>RegTP</unknownInfoAction>
64 </ocspResponder>
65 </certStatusResourceReference>
66 <certSelectorRef>von RegTP
67 ausgestellte Zertifikate</certSelectorRef>
68 <issuerStartsWith>O=Bundesnetzagentur,C=DE</issuerStartsWith>
69 </certStatusSource>
70 </certStatusSources>
71
72 <validationModel>chain</validationModel>
73 </certPathValidator>
74
75 <algorithmAssessor>
76 <memoryAlgorithmAssessor>
77 <warningPeriodMillis>31536000000</warningPeriodMillis>
78 <algorithmExpiration>
79 <oid>1.2.840.113549.1.1.5</oid>
80 <paramSpec>1024</paramSpec>
81 <outdatedNotBefore>2008-12-31T23:00:00Z</outdatedNotBefore>
82 </algorithmExpiration>
83 </memoryAlgorithmAssessor>
84 </algorithmAssessor>
85
86 </validatorConfig>
Seite 31 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Seite 32 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Seite 33 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Seite 34 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Seite 35 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Das Element <implementationMap> beinhaltet das Element <orderBook>, mit der die Funktion
F3LockReqest konfiguriert werden kann.
01 <orderBook>
02 <baseDir>C:/secureDir</baseDir>
03 <baseHttpContext>http://localhost:9080/slmbc-download</baseHttpContext>
04 <helperProgramList>
05 <makeReadOnlyProgram>C:/secureDir/
06 helper-progs/takeOwnership.exe</makeReadOnlyProgram>
07 <checkAccessProgram>C:/secureDir/
08 helper-progs/checkAccess.exe</checkAccessProgram>
09 <makeNonAccessibleProgram>C:/secureDir/
10 helper-progs/revokeAccess.exe</makeNonAccessibleProgram>
11 <makeWorldAccessibleProgram>C:/secureDir/
12 helper-progs/makeWorldAccessible.exe</makeWorldAccessibleProgram>
13 <renameFileOrDirProgram>C:/secureDir/
14 helper-progs/renameFromTo.exe</renameFileOrDirProgram>
15 </helperProgramList>
16 </orderBook>
Das Element <implementationMap> beinhaltet das Element <fileSignerConfig>, mit der die
Funktion F5SignFileReqest konfiguriert werden kann. Das Element beinhaltet die drei Elemente
<signatureModule>, <listModule> und <deactivateModule>. Da diese Module auf dem gleichen
XML-Schema aufbauen, wird an dieser Stelle die Konfiguration der drei Module nur einmal dar-
gestellt.
01 <fileSignerConfig>
02 <workingThreads>3</workingThreads>
03 <tickInterval>250</tickInterval>
Seite 36 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
04
05 <signatureModule>
06 <httpClientDef>
07 <url>http://localhost:9080/xml</url>
08 <config>
09 <httpClientConfigDef>
10 <authentication>
11 <httpAuthDef>
12 <basicAuthDef>
13 <userName>admin</userName>
14 <password>pwadmin</password>
15 </basicAuthDef>
16 </httpAuthDef>
17 </authentication>
18 </httpClientConfigDef>
19 </config>
20 </httpClientDef>
21 <xmlConverterPool>
22 <numberOfInstances>5</numberOfInstances>
23 <namespacePrefixMapperClassName>
24 de.authentidate.sir.NamespacePrefixMapperImpl
25 </namespacePrefixMapperClassName>
26 <contextName>
27 de.authentidate.xml.ns.datastruct.slmbc.functions
28 </contextName>
29 </xmlConverterPool>
30 <nonceGenerator>
31 <randomNumberGenerator>
32 <secureRandomAlgorithm>SHA1PRNG</secureRandomAlgorithm>
33 <bytesForMantissa>16</bytesForMantissa>
34 </randomNumberGenerator>
35 </nonceGenerator>
36 </signatureModule>
37 </fileSignerConfig>
Seite 37 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Das Element <implementationMap> beinhaltet das Element <fileVerifierConfig>, mit der die
Funktion F6VerifyFileReqest konfiguriert werden kann.
01 <fileVerifierConfig>
02 <workingThreads>3</workingThreads>
03 <tickInterval>250</tickInterval>
04
05 <verificationModule>
06 <httpClientDef>
07 <url>http://localhost:9080/xml</url>
08 <config>
09 <httpClientConfigDef>
10 <authentication>
11 <httpAuthDef>
12 <basicAuthDef>
13 <userName>admin</userName>
14 <password>pwadmin</password>
15 </basicAuthDef>
16 </httpAuthDef>
17 </authentication>
18 </httpClientConfigDef>
19 </config>
20 </httpClientDef>
21 <xmlConverterPool>
22 <numberOfInstances>5</numberOfInstances>
23 <namespacePrefixMapperClassName>
24 de.authentidate.sir.NamespacePrefixMapperImpl
25 </namespacePrefixMapperClassName>
26 <contextName>
27 de.authentidate.xml.ns.datastruct.slmbc.functions
28 </contextName>
29 </xmlConverterPool>
30 <nonceGenerator>
31 <randomNumberGenerator>
32 <secureRandomAlgorithm>SHA1PRNG</secureRandomAlgorithm>
33 <bytesForMantissa>16</bytesForMantissa>
34 </randomNumberGenerator>
35 </nonceGenerator>
36 </verificationModule>
37 </fileVerifierConfig>
Seite 38 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Das Element <implementationMap> für die Funktion F7UnlockReqest bietet keine Konfigurati-
onsmöglichkeiten.
Das Element <implementationMap> für die Funktion F8DeactivateRequest bietet keine Konfi-
gurationsmöglichkeiten.
01 <listingRequestHandlerConfig>
02 <listProxy>
03 <listModule>
04 <httpClientDef>
05 <url>http://localhost:9080/xml</url>
06 <config>
07 <httpClientConfigDef>
08 <authentication>
09 <httpAuthDef>
10 <basicAuthDef>
11 <userName>admin</userName>
12 <password>pwadmin</password>
13 </basicAuthDef>
14 </httpAuthDef>
15 </authentication>
16 </httpClientConfigDef>
17 </config>
18 </httpClientDef>
19 <xmlConverterPool>
20 <numberOfInstances>10</numberOfInstances>
21 <namespacePrefixMapperClassName>
22 de.authentidate.sir.NamespacePrefixMapperImpl
23 </namespacePrefixMapperClassName>
24 <contextName>
25 de.authentidate.xml.ns.datastruct.slmbc.functions
26 </contextName>
27 </xmlConverterPool>
28 <nonceGenerator>
29 <randomNumberGenerator>
30 <secureRandomAlgorithm>SHA1PRNG</secureRandomAlgorithm>
31 <bytesForMantissa>16</bytesForMantissa>
32 </randomNumberGenerator>
Seite 39 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
33 </nonceGenerator>
34 </listModule>
35 <maxListRetries>3</maxListRetries>
36 <retryTimeoutMillis>10000</retryTimeoutMillis>
37 </listProxy>
38 </listingRequestHandlerConfig>
Das Element <implementationMap> für die Funktion F10GetStatusRequest bietet keine Konfi-
gurationsmöglichkeiten.
Das Element <implementationMap> für die Funktion F12FreezeRequest bietet keine Konfi-
gurationsmöglichkeiten.
Das Element <implementationMap> für die Funktion F13ThawRequest bietet keine Konfi-
gurationsmöglichkeiten.
Das Element <implementationMap> für die Funktion F14GetURLRequest bietet keine Konfi-
gurationsmöglichkeiten.
Seite 40 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Damit SLMBC die eindeutige Kontrolle über die angeschlossenen Chipkartenleser übernehmen
kann, müssen diese SLMBC bekannt gemacht werden. Dies geschieht über eine Nebenkonfigu-
rationsdatei, die in der Hauptkonfiguration über das XML-Tag <uriStoredData> im Element
<F1SignRequest> referenziert wird. Der voreingestellte Dateiname ist token.xml.
Alle unterstützen Kartenleser sind innerhalb dieser Datei beispielhaft exemplarisch definiert und
auskommentiert. Zur Integration eines dieser Kartenleser muss lediglich das Anfangszeichen
„<!--“ und -endzeichen „-->“ des Kommentars passend entfernt (bzw. verschoben) werden.
01 <userWrittenTriggerId>1231456711</userWrittenTriggerId>
02
03 <!-- Cherry -->
04 <!--
05 <terminal>
06 <name>Cherry Kartenleser1</name>
07 <config>com.authentidate.ctapi.ocf.
08 CtApiTerminalFactory|ChyCTApiSp.dll|cherry1|cherry1|1</config>
09 </terminal>
10 -->
Seite 41 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Der Begriff „Benutzer“ bezieht sich aus Sicht von SLMBC auf die Software-Applikation, die
SLMBC anspricht und die Vorgangsverarbeitung aktiviert. Da SLMBC eine vollständige Signa-
turanwendungskomponente darstellt, ist jede Software, die mit SLMBC kommuniziert als Benut-
zer zu sehen.
Eine natürliche Person, die im Besitz einer Signaturkarte ist, und diese an einem Arbeitsplatz
über ein Chipkartenterminal SLMBC zur Verfügung stellt, ist aus Sicht von SLMBC der Signa-
turkarteninhaber („Anwender“).
Damit ein Benutzer die Funktionen von SLMBC aufrufen kann, wobei hier nicht zwischen exter-
nen (z. B. F3, F5, F6) und internen (z. B. F1, F2) Funktionen unterschieden wird, muss sich
dieser gegenüber der Funktion authentifizieren. Dies wird durch die Basic Authentication im
HTTP-Request realisiert. Beim Aufruf werden im HTTP-Request der Benutzer und das Pass-
wort mitgegeben. Da die Kommunikation über SSL stattfindet, ist die Authentifizierung ver-
schlüsselt. Eine Aufnahme der SSL-Kommunikation ohne Verwendung eines der angebotenen
Algorithmen ist nicht möglich. Die Benutzerdaten für die Funktionen-Authentifizierung werden in
der Hauptkonfigurationsdatei im XML-Tag <accessAA> definiert (siehe Kapitel 2.1.9.1 „Element
<accessAA>“). Dort werden der Benutzername und der Hashwert des Passwortes gespeichert,
damit das Passwort nicht im Klartext hinterlegt wird.
Damit ein Benutzer bei der Erstellung von Signaturen auf einzelne Gruppen von Signaturkarten
zugreifen kann, muss er sich gegenüber der Gruppe authentifizieren. Dies geschieht beim Auf-
ruf einer Funktion, in dem der Benutzername und das Passwort im XML-Anfragedokument mit-
gegeben und diese Werte gegen die Konfigurationsdatei geprüft werden – diese Authentifikati-
on hat nichts mit der Basic Authentication des HTTP-Requests zu tun. Die Benutzer, die die
einzelnen Gruppen ansprechen dürfen, werden für jede Gruppe einzeln in einer XML-Datei ab-
gelegt. Der Dateiname wird in der Hauptkonfigurationsdatei über das XML-Tag <userAFileNa-
me> im Element <F1SignRequest> referenziert. Der vorgegebene Dateiname ist hierbei u-
ser.xml. Diese Datei muss sich im Gruppenverzeichnis befinden. Die Gruppenverzeichnisse
sind Unterverzeichnisse des Verzeichnisses signer-groups.
Achtung: für den Betrieb von SLMBC im signaturgesetzkonformen Umfeld, darf das Benutzer-
passwort auf Clientseite nicht gespeichert werden. Es muss für jeden Auftrag von einem An-
wender eingegeben werden. Ferner ist sicherzustellen, dass nur solche Anwender Benutzer-
passworte eingeben, die auch für die Gruppen der Signaturkarten konfiguriert sind. Auf diese
Weise wird sichergestellt, dass nur Anwender Signaturaufträge erteilen, die auch selbst signa-
turberechtigt sind.
Da mehrere Benutzer für eine Gruppe konfiguriert werden können, kann das unten beschriebe-
ne XML-Tag <userId> mehrfach in der Benutzerdatei vorkommen.
01 <groupUserA>
02 <userId>
03 <name>dummy</name>
04 <passwordFingerprint>
05 <hashAlgo>SHA-1</hashAlgo>
06 <hashValue>cTwdkZIlFT0TSZgkyq/EArD/S8A=</hashValue>
07 </passwordFingerprint>
08 </userId>
09 </groupUserA>
Seite 42 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Auch hier werden der Benutzername und der Hashwert des Passwortes gespeichert, damit das
Passwort nicht im Klartext hinterlegt wird.
Damit die einzelnen Passwörter für die Benutzer der Funktionen bzw. der Gruppen nicht im
Klartext in den Konfigurationsdateien abgelegt werden, werden die Passwörter dort in Form
ihrer Hashwerte gespeichert. Der Benutzer (Software-Applikation) gibt beim Funktionsaufruf
den Benutzer und das Passwort als Parameter mit (Basic Authentication für die Funktionen-
Authentifizierung bzw. das XML-Tag <requestorIdentifier> für die Gruppen-Authentifizierung der
Signaturkarten).
Die Kommunikation findet über SSL statt, so dass bei der Übertragung keine unverschlüsselten
Daten ausgelesen werden können. SLMBC berechnet intern den Hashwert des übergebenen
Passwortes und vergleicht diesen mit dem Wert aus der Konfigurationsdatei bzw. Benutzerda-
tei. Erst bei Gleichheit ist der Benutzer berechtigt, die Gruppe anzusprechen.
AuthentiDate bietet ein Hilfsprogramm zur sicheren Eingabe von Passwörtern und zur Erzeu-
gung von Hashwerten an. Dieses liegt in dem Verzeichnis \tools\PasswortFP\ unterhalb
des Installationsverzeichnisses als Java-Programm passwordFP.jar vor.
Das Programm wird durch den Aufruf java –jar passwordFP.jar gestartet und präsentiert
sich mit der folgenden Oberfläche.
Seite 43 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Durch Klick auf „Kennwort sicher eingeben“ wird ein Dialog gestartet, der durch die Bewegung
der Maus Zufallszahlen für die nächsten Berechnungen erzeugt. Wenn genug Zahlen berechnet
wurden (und nur dann), kann durch „Ok“ fortgefahren werden.
Seite 44 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Der nächste Dialog erstellt durch zufällige Anordnung der Tasten eine virtuelle Tastatur auf dem
Bildschirm. Durch den Mausklick auf die einzelnen Buchstaben und Zeichen kann das Kennwort
eingegeben werden. Wenn es den Sicherheitsanforderungen genügt, kann der Dialog fortge-
setzt werden.
Nach Auswahl des Signaturalgorithmus wird das Ergebnis der Berechnungen angezeigt. In der
unteren Textbox wird dabei ein exemplarisches XML-Tag für die Benutzerdatei user.xml ange-
geben, der nach Angabe des Benutzernamens in dieser Form in die Benutzerdatei kopiert wer-
den kann.
In der mittleren Textbox wird der Hashwert des Passwortes in der Base64-Kodierung angezeigt,
der dann in das XML-Tag für die Authentifizierung der Funktionsaufrufe kopiert werden kann.
Es ist zu beachten, dass das Kennwort nicht zwischengespeichert und erst recht nicht ange-
zeigt wird. Nur so kann gewährleistet werden, dass kein Trojaner die Daten ausspähen und
weiterleiten kann.
Bitte beachten Sie: Bei der Integration von SLMBC in eine andere Anwendung muss dieser
Hinweis vom Hersteller der Anwendung („Integrator“) an die Endbenutzer dieser Anwendung
weitergegeben werden.
Seite 45 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Die Signaturkarten werden über Chipkartenterminals angesprochen und sind in Gruppen orga-
nisiert. Jede Signaturkarte ist genau einer Gruppe zugeordnet.
Dadurch wird eine Mandantenfähigkeit erzeugt, mit der z. B. verschiedene Dokumenttypen ver-
schiedenen Mandanten zugeordnet werden können. Durch die Angabe der Gruppe beim Funk-
tionsaufruf an SLMBC, werden die einzelnen Signaturkarten für den Mandanten zur Signaturer-
stellung herangezogen.
Die Zuordnung der Signaturkarten zu Gruppen erfolgt durch das Anlegen von Unterverzeichnis-
sen in den Gruppenverzeichnissen, wie unten beschrieben. Dies kann zur Laufzeit geändert
werden. SLMBC erkennt die Änderung nach Veränderung des Triggerwertes <userWrittenTrig-
gerId> in der Nebenkonfiguration Chipkartenleser automatisch und übernimmt die neue Grup-
pierung nach einer Konsistenz- und Plausibilitätsprüfung (siehe Kapitel 2.2 „Nebenkonfiguration
Chipkartenleser“). Sind die neuen Angaben inkonsistent, wird dies in der Logdatei vermerkt.
SLMBC steht dann solange nicht zur Verfügung, bis die Gruppen wieder konsistent sind.
Die einzelnen Gruppenverzeichnisse müssen sich in dem gleichen Verzeichnis wie die oben
genannte „Nebenkonfiguration Chipkartenleser“ befinden. Das Verzeichnis wird als Konfigurati-
onsverzeichnis für Gruppen von Signaturerstellungseinheiten bezeichnet.
Zu jeder Gruppe enthält das Verzeichnis genau ein Unterverzeichnis, das nachfolgend als
Gruppenverzeichnis bezeichnet wird. Es existieren genau so viele Gruppen wie Unterverzeich-
nisse im Konfigurationsverzeichnis für Gruppen vorhanden sind.
Außer einer einzigen Datei enthält jedes Gruppenverzeichnis sonst ausschließlich weitere Un-
terverzeichnisse. Bei dieser Datei handelt es sich um die Benutzerzuordnung (siehe Kapitel 2.3
Seite 46 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
„Nebenkonfiguration Benutzer“). Dies sind die Benutzer, denen die Gruppe zugeordnet ist. Ver-
schiedene Gruppen können demselben Benutzer zugeordnet sein.
Hauptkonfigurationsdatei
verweist auf
verweist auf
Konfigurationsverzeichnis
für Gruppen von
Signaturerstellungseinheiten Nebenkonfigurationsdatei
Benutzerzuordnung
Benutzerzuordnung
Abbildung 7: Gruppenkonfiguration
Seite 47 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
lungseinheiten mit demselben Signaturschlüssel existieren. Er setzt weiterhin voraus, dass jede
Signaturerstellungseinheit das Zertifikat zum Signaturschlüssel enthält bzw. bereitstellt.
Wenn eine Signaturerstellungseinheit für SLMBC verfügbar wird, zum Beispiel weil sie in ein
von ihm verwaltetes Kartenlesegerät eingesteckt wird, erfragt SLMBC zuerst das Zertifikat zum
Signaturschlüssel von der Einheit. SLMBC stellt dann anhand der konfigurierten Schlüsselzerti-
fikate die Zuordnung der Einheit zu einer Gruppe und zu den Attributzertifikaten her. Dabei
muss dasselbe Schlüsselzertifikat in der Konfiguration auffindbar sein. Ist es nicht vorhanden,
wird die Einheit nicht verwendet. Ansonsten ordnet SLMBC die Einheit der Gruppe von Einhei-
ten zu, deren Schlüsselzertifikate in einem Unterverzeichnis desselben Gruppenverzeichnisses
vorhanden sind. Der Name des Gruppenverzeichnisses entspricht dem Namen der Gruppe, wie
er auch durch die Funktion F9 aufgelistet wird.
C:\
|- AD_SLMBC_3.0\
|
|- Server\
|
|- config\
|
|- groups\
|
|- token.xml
|- SIRA#1\
|
|- user.xml
|- A-017-3\
|
|- SW_USER-799765596.crt
|- SW_ATTR1-799765593.crt
|- ca-and-root-certs\
|
|- CA-13.cer
|- 6R.cer
Dem Signaturkarteninhaber wird vor der Erstellung eines Auftrags die Möglichkeit geboten, sich
alle zugeordneten Signaturerstellungseinheiten einer Signaturgruppe über die Funktion F9List
anzeigen zu lassen. Diese aufgelisteten Komponenten werden von SLMBC für jede Signatur-
gruppe jeweils zu einem eindeutigen Hashwert zusammengefasst, der ebenfalls über den Auf-
ruf von F9List an den Benutzer zurückgereicht wird. Bei der Auftragserstellung wird dieser
Hashwert – neben anderen Auftragsdaten – nun wieder an SLMBC übergeben, welches seiner-
seits die Übereinstimmung des Hashwerts mit dem der zu verwendenden Signaturgruppe er-
Seite 48 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
neut überprüft. Hierdurch stellt SLMBC sicher, dass der Auftrag auch dann ausschließlich mit
der zuvor angezeigten Signaturgruppenkonfiguration ausgeführt wird, wenn zwischen Signatur-
gruppenanzeige und Auftragserstellung ein längerer Zeitraum liegt, in dem die Signaturgrup-
penkonfigurationen sich theoretisch hätte ändern können.
Zusätzlich bietet AuthentiDate ein Hilfsprogramm zur Berechnung von Gruppen-Hashwerten an.
Dieses liegt in dem Verzeichnis \Server\tools unterhalb des Installationsverzeichnisses als
Java-Programm groupFP.jar vor.
Das Hilfsprogramm wird durch den Aufruf java –jar groupFP.jar gestartet und präsentiert
sich mit der folgenden Oberfläche.
Seite 49 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Seite 50 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
3 SLMBC-Schnittstelle
Für die massenhafte Erzeugung bzw. Prüfung von Signaturen stellt SLMBC sowohl Schnittstel-
len über TCP als auch über das lokale Dateisystem bereit.
Über das lokale Dateisystem werden die zu signierenden bzw. prüfenden Daten vom Benutzer
(Software-Applikation) an SLMBC übergeben und die signierten Daten bzw. Prüfergebnisse
dem Benutzer von SLMBC zurückgereicht.
Aus Gründen der Sicherheit setzt und kontrolliert SLMBC die Zugriffsrechte auf diese Daten,
um während kritischer Phasen den Zugriff auf die zu verarbeitenden Daten einzuschränken.
SLMBC stellt somit sicher, dass genau die Daten signiert bzw. verifiziert werden, welche der
Benutzer zu diesem Zweck bestimmt hat.
Über das TCP-Protokoll wird dem Benutzer jedoch eine Steuerungsmöglichkeit für seinen Auf-
trag zur Erstellung bzw. Prüfung von Signaturen gegeben. Auch diese Steuerungsmöglichkeit
ist zur Sicherheit eingeschränkt. Sie funktioniert nach einem klar definierten Regelwerk. Diese
Steuerungsmöglichkeit wird durch einzelne Funktionen in Form von Funktionsaufrufen für den
Benutzer bereitgestellt.
Die Aufrufparameter, exakter der Funktionsname und die Parameter, sind vom Benutzer als
XML-Dokument zu formulieren und über die Transportschicht HTTPS an SLMBC zu übergeben.
Der Benutzer hat unabhängig von der aufgerufenen Funktion stets denselben URL zu verwen-
den. SLMBC erkennt die aufgerufene Funktion eindeutig anhand des Wurzelelementes des
übergebenen XML-Dokuments.
SLMBC antwortet ebenfalls mit einem XML-Dokument. In den XML-Antworten werden auch
Zeitwerte als Elemente eingebettet. Sie werden immer sekundengenau und bezogen auf die
Zeitzone UTC (Coordinated Universal Time) dargestellt. UTC wird als Nachfolger der GMT
(Greenwich Mean Time) verwendet. Diese Klärung ist leider notwendig, weil die Datentypen zu
Zeitwerten gemäß XML-Schema mehrdeutige Zeitwerte ohne Angabe einer Zeitzone erlauben.
Während bestimmter Phasen der Bearbeitung seines Auftrages zur Erstellung bzw. Prüfung von
Signaturen kann der Benutzer auch über das TCP-Protokoll lesend auf seine zu verarbeitenden
Daten zugreifen. Diese Schnittstellen werden in den folgenden Abschnitten einzeln erklärt.
Die Schnittstelle von SLMBC basiert, wie bereits erwähnt, auf dem Austausch von XML-
Dokumenten. Diese Dokumente stellen wohlgeformte Dokumente dar, die durch XML-Sche-
mata beschrieben werden. In den nachfolgenden Kapiteln werden die Dokumente im Detail be-
schrieben.
Da jedoch einige XML-Schemata sehr komplexe XML-Subelemente beinhalten, die die Grenzen
dieses Handbuchs sprengen würden, verweisen wir hiermit auf die Schemata-Dateien, die an
die Entwickler mit ausgeliefert werden. Die Dateien befinden sich in dem Verzeichnis
\slmbc\developer\xml-schema\, wobei hierbei zwischen der administrativen Konfiguration
und der Entwickler-Schnittstelle unterschieden wird. Die Schemata des erstgenannten befinden
sich in dem Unterverzeichnis \configuration\ und des letzteren in dem Unterverzeichnis
\interface\.
Seite 51 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
3.1 Einsatzszenarien
Wie bereits in Kapitel 1.2 „Einsatzbereich“ beschrieben, kann SLMBC als vollständige Signatur-
anwendungskomponente (SAK) zum Erstellen bzw. Prüfen von Signaturen betrieben werden.
Die nächsten Abschnitte beschreiben diese Szenarien detaillierter, bevor die einzelnen Funktio-
nen der Schnittstelle dargestellt werden.
SLMBC konfiguriert und steuert dabei die unten genannten Funktionen, welche auch in getrenn-
ten Prozessen auf unterschiedlichen Rechnern zur Verfügung gestellt werden können. In der
Regel wird SLMBC aber auf einem Rechner betrieben, so dass die optionale Prozessgrenze
entfällt.
SLMBC
Benutzer SLMBC
(Funktion F3Lock)
(Software-Applikation) (Funktion F1Sign)
(Funktion F5SignFile)
Prozessgrenze optionale
Prozessgrenze
Die Funktion F3Lock übernimmt die Kontrolle der Vorgangssteuerung bei der Erzeugung von
Signaturen für Originaldateien (auch Parallelsignaturen) bzw. für Gegensignaturen bei bereits
signierten Dateien.
Hierzu legt F3Lock einen neuen Auftrag im Auftragsbuch an, übernimmt die vom Benutzer
(Software-Applikation) bereitgestellten Dateien und überführt diese nach Aufforderung in ein
sicheres Verzeichnis.
Dabei ist zu beachten, dass der Auftrag noch nicht ausgeführt, sondern nur angelegt wird.
Seite 52 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Die Funktion F5SignFile startet dann den eigentlichen Auftrag, erstellt für die zu signierenden
Daten Hashwerte und übergibt diese Hashwerte zusammen mit Steuerungs- und Authentifizie-
rungsinformationen über sichere, definierte Schnittstellen an die interne Funktion F1Sign.
Die Funktion F1Sign erstellt die Signaturen und reicht die Daten an die Funktion F5SignFile
zurück, welche diese im Dateisystem ablegt. Auf Auforderung des Benutzers werden diese Sig-
naturen nach erfolgreicher, kompletter Bearbeitung des Auftrages wieder im Dateisystem frei-
gegeben.
Die Funktion F1Sign übernimmt die Erzeugung der Signaturen. Hierzu hat die Funktion F1Sign
eine Anzahl sicherer Signaturerstellungseinheiten unter ihrer Kontrolle. Diese Signaturerstel-
lungseinheiten können mit Hilfe von Konfigurationsdateien zu Gruppen zusammengefasst wer-
den, welche dann zu einer performanten Erstellung von Signaturen verwendet werden können.
Zusätzlich ist F1Sign in der Lage, Zeitstempel von externen Zeitstempelquellen abzufragen und
in die erzeugten Signaturen zu integrieren.
SLMBC konfiguriert und steuert dabei die unten genannten Funktionen, welche auch in getrenn-
ten Prozessen auf unterschiedlichen Rechnern zur Verfügung gestellt werden können. In der
Regel wird SLMBC aber auf einem Rechner betrieben, so dass die optionale Prozessgrenze
wegfällt.
SLMBC
Benutzer SLMBC
(Funktion F3Lock)
(Software-Applikation) (Funktion F2Verify)
(Funktion F6VerifyFile)
Prozessgrenze optionale
Prozessgrenze
Seite 53 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Die Funktion F3Lock übernimmt die Kontrolle der Vorgangssteuerung bei der Prüfung von Sig-
naturen bzw. Zeitstempeln für Originaldateien bzw. für Gegensignaturen bei bereits signierten
Dateien.
Hierzu legt F3Lock einen neuen Auftrag im Auftragsbuch an, übernimmt die vom Benutzer
(Software-Applikation) bereitgestellten Dateien und Signaturen bzw. Zeitstempel und überführt
diese nach Aufforderung in ein sicheres Verzeichnis.
Dabei ist zu beachten, dass der Auftrag noch nicht ausgeführt, sondern nur angelegt wird.
Die Funktion F6VerifyFile startet den eigentlichen Auftrag und überführt die Dateien und Signa-
turen bzw. Zeitstempel über sichere, definierte Schnittstellen an die interne Funktion F2Verify.
Die Funktion F2Verify überprüft die Signaturen, Zeitstempel und Unterzeichner und reicht die
Daten an die Funktion F6VerifyFile zurück, welche die Prüfergebnisse im Dateisystem ablegt.
Auf Anforderung des Benutzers werden diese Prüfergebnisse nach erfolgreicher, kompletter
Bearbeitung des Auftrages wieder im Dateisystem freigegeben.
Die Funktion F2Verify übernimmt die Überprüfung von Signaturen, Zeitstempeln und Zertifikats-
ketten. Um diese Aufgabe zu erfüllen, werden neben der Überprüfung der mathematischen Sig-
natur auch die Statusinformationsquellen der entsprechenden Zertifizierungsdiensteanbieter
abgefragt und die erhaltenen Informationen in die Prüfergebnisse integriert.
Mit dem Aufruf der Funktion wird SLMBC veranlasst, eine Signatur mit Hilfe einer beliebigen
Signaturerstellungseinheit aus einer bestimmten Signaturgruppe zu erzeugen.
Unter dem Begriff „Signaturerstellung“ wird hier die sowohl die Erzeugung von Signaturen als
auch die Erzeugung von Parallelsignaturen und Gegensignaturen verstanden.
SLMBC benutzt diese Funktion selbst für die Erstellung einer Signatur zu einer Datei. Im Be-
trieb als vollständige Signaturanwendungskomponente stellt SLMBC die Funktion dem Benut-
zer nicht direkt zur Verfügung. Sie gehört deshalb eigentlich nicht zur externen Schnittstelle.
Dennoch ist sie hier beschrieben, da SLMBC in zwei Teilen betrieben werden kann, eventuell
sogar auf getrennten Rechnern (siehe Kapitel 3.1.1 „Vollständige SAK zur Signaturerstellung“).
Der Zweck dieser Funktion ist es, eine Signatur zu erstellen. Dazu müssen die zu signierenden
Daten mit den Funktionsparametern, also im XML-Dokument eingebettet, oder stellvertretend
durch einen Hashwert übergeben werden. In beiden Fällen wird in den Parametern der zu ver-
wendende Hash-Algorithmus durch den Aufrufenden der Funktion vorgegeben.
Seite 54 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Die Wirkung des Aufrufes dieser Funktion ist, dass SLMBC veranlasst wird, sofort eine der Sig-
naturerstellungseinheiten der benannten Gruppe zu verwenden und mit ihr eine Signatur zu
erzeugen.
Falls eine Aktivierung der Signaturerstellungseinheit vorher notwendig sein sollte, zeigt SLMBC
dies über die Anzeigen der jeweiligen Chipkarten-Terminals an. Die Aktivierung bleibt gegebe-
nenfalls für weitere Aufrufe dieser Funktion - abhängig von der konfigurierten Prozessbindung -
erhalten.
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Anfragedokuments, welches
vom Benutzer (Software-Applikation) an SLMBC gesendet wird.
Seite 55 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Seite 56 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Antwortdokuments, welches
vom SLMBC an den Benutzer (Software-Applikation) zurückgesendet wird.
Bei der Ausführung der Funktion F1Sign können Fehler auftreten. Einige davon werden in
Tabelle 62 erklärt. Alle anderen Fehler sind spezifisch für diese Funktion. Sie werden stets mit
einem XML-Dokument als Antwort signalisiert, welches das Element <errorResponse> als Wur-
zelelement hat. Die nachfolgende Tabelle beschreibt die speziellen Kategorien der Ursachen
der spezifischen Fehler anhand der konkreten Werte für das XML-Tag <code>.
Seite 57 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Mit dem Aufruf der Funktion wird SLMBC veranlasst, eine Signatur – bei Bedarf auch mit Hilfe
von Statusanfragen an Zertifizierungsdiensteanbieter - zu prüfen.
Unter dem Begriff „Signaturprüfung“ wird hier die sowohl die Prüfung von Signaturen als auch
die Prüfung von Parallelsignaturen, Gegensignaturen sowie Zeitstempeln verstanden.
SLMBC benutzt diese Funktion selbst für die Prüfung einer Signatur zu einer Datei. Im Betrieb
als vollständige Signaturanwendungskomponente stellt SLMBC dem Benutzer diese Funktion
nicht direkt zur Verfügung. Sie gehört deshalb eigentlich nicht zur externen Schnittstelle. Den-
noch ist sie hier beschrieben, weil SLMBC in zwei Teilen betrieben werden kann, eventuell so-
gar auf getrennten Rechnern (siehe Kapitel 3.1.2 „Vollständige SAK zur Signaturprüfung“).
Der Zweck der Funktion ist die Prüfung einer Signatur. Hierfür können die signierten Daten mit
den Funktionsparametern, also im XML-Dokument eingebettet, oder stellvertretend durch einen
Hashwert übergeben werden. Sind die signierten Daten in einer dieser beiden Formen angege-
ben, wird ihre kryptographische Bindung zur Signatur mit überprüft. Ansonsten erhält der Be-
nutzer den ehemals signierten Hashwert im Ergebnis der Funktion und kann die Bindung selbst
prüfen.
Die Wirkung des Aufrufes der Funktion ist, dass SLMBC veranlasst wird, sofort die Signatur zu
prüfen. Bei Bedarf wendet SLMBC sich dazu an Verzeichnisdienste und verwendet lokal konfi-
gurierte Vertrauensanker in der Form von Wurzelzertifikaten. Der Bedarf richtet sich nach der
vom Benutzer angeforderten Tiefe der Prüfung und nach den im Cache von SLMBC bereits
vorgefundenen Prüfergebnissen zu vormals geprüften Signaturen und Zertifikaten.
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Anfragedokuments, welches
vom Benutzer (Software-Applikation) an SLMBC gesendet wird.
Seite 58 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Das XML-Dokument, welches bei der Funktion F2Verify als Antwort entsteht, ist sehr komplex,
da die Signatur in Form eines Signatur-Containers selbst mannigfaltige Gestalt haben kann. Es
enthält das gesamte Prüfergebnis. Darüber hinaus beinhaltet es die Gültigkeitsnachweise (z. B.
OCSP-Antworten) zu den geprüften Zertifikaten in Form eines Evidence-Record, falls diese vom
Benutzer gewünscht wurden.
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Antwortdokuments, welches
vom SLMBC an den Benutzer (Software-Applikation) zurückgesendet wird.
Seite 59 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Bei der Ausführung der Funktion F2Verify können Fehler auftreten. Einige davon werden in
Tabelle 62 erklärt. Alle anderen Fehler sind spezifisch für diese Funktion. Sie werden stets mit
einem XML-Dokument als Antwort signalisiert, welches das Element <errorResponse> als Wur-
zelelement hat. Die nachfolgende Tabelle beschreibt die speziellen Kategorien der Ursachen
der spezifischen Fehler anhand der konkreten Werte für das XML-Tag <code>.
Seite 60 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Mit dem Aufruf der Funktion F3Lock wird ein Auftrag zur Verarbeitung von Signaturen erstellt.
Er dient gleichermaßen der Erstellung und der Prüfung von Signaturen.
Die Wirkung des Aufrufes der Funktion ist, dass die zu verarbeitenden Daten samt der Einstel-
lungen zur Erzeugung bzw. Prüfung von Signaturen unveränderbar festgelegt werden und zur
Betrachtung bereitstehen, bevor die eigentliche Verarbeitung stattfindet. Die zu verarbeitenden
Daten werden also durch SLMBC geschützt.
Der Auftrag wird hier nur initialisiert und nicht bereits gestartet, d. h. es werden noch keine Sig-
naturen erstellt bzw. geprüft.
Der Benutzer übergibt an SLMBC zur Ausführung der Funktion ein Verzeichnis und weitere
Steuerungsinformationen. Dieses Verzeichnis (mit seinen Unterverzeichnissen) legt die Menge
der Daten fest, welche später verarbeitet werden sollen.
Die Funktion überprüft dann, ob in dem benannten Verzeichnis keine Datei mit einem Namen
enthalten ist, welche SLMBC bei einer späteren Verarbeitung der Signaturen selbst anlegen
würde. Enthält das Verzeichnis eine solche Datei, erzeugt SLMBC keinen Vorgang, sondern
antwortet mit einem entsprechenden Fehler.
Verläuft diese Überprüfung erfolgreich, so verschiebt die Funktion das angegebene Verzeichnis
samt der darin enthaltenen Daten in das Auftragsbuch (ein durch die Konfiguration festgelegtes
Verzeichnis) von SLMBC, in dem alle Verzeichnisse zu allen aktuellen Vorgängen gesammelt
werden.
Dort stellt die Funktion die Zugriffsrechte auf die Daten, das benannte Verzeichnis und alle sei-
ne Unterverzeichnisse sicher ein, so dass außer durch SLMBC und durch vertrauenswürdige
Prozesse keine Manipulation der Daten erfolgen kann. Das Verzeichnis wird nach dieser Ände-
rung der Zugriffsrechte in diesem Dokument als „Sicheres Verzeichnis“ bezeichnet.
Erst nach der Veränderung aller Zugriffsrechte übermittelt SLMBC eine Antwort an den aufru-
fenden Benutzer. In dieser Antwort wird die Erstellung des sicheren Verzeichnisses bestätigt
und auch genannt, wie der absolute Pfad des „Sicheren Verzeichnisses“ lautet.
Durch den Schutz der Daten vor Manipulation ist sichergestellt, dass nur Daten, welche im si-
cheren Verzeichnis noch betrachten werden können, nach dem Aufruf einer der Funktionen
F5SignFile bzw. F6VerifyFile signiert werden.
Weiterhin bewirkt der Aufruf der Funktion, dass für die gesamte Lebensdauer des Vorganges im
sicheren Verzeichnis eine Status-Datei namens „jobStatus.xml“ von SLMBC gepflegt wird.
Die Datei wird vor der Antwort der Funktion F3Lock im sicheren Verzeichnis angelegt und bis
zum Aufruf der Funktionen „Abbruch“ oder „Löschen“ kontinuierlich aktualisiert.
Für den Benutzer dient sie als zusätzliche vertrauenswürdige Information, sofern er lesenden
Zugriff auf das sichere Verzeichnis hat. Der Inhalt der Datei „jobStatus.xml“ wird auch als Teil
der Antwort zu den Aufrufen der Funktionen „Statusabfrage“, „Löschen“ und „Abbruch“ zur Ver-
fügung gestellt.
Seite 61 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Anfragedokuments, welches
vom Benutzer (Software-Applikation) an SLMBC gesendet wird. Da das Anlegen eines Auftrags
sowohl für die Signaturerstellung als auch für die Signaturprüfung über diese Funktion stattfin-
det, kann das XML-Dokument als XML-Tag entweder Daten vom Typ <parametersForSigning>
oder aber Daten vom Typ <parametersForVerification> enthalten.
Seite 62 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Seite 63 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Antwortdokuments, welches
vom SLMBC an den Benutzer (Software-Applikation) zurückgesendet wird.
Bei der Ausführung der Funktion F3Lock können Fehler auftreten. Einige davon werden in
Tabelle 62 erklärt. Alle anderen Fehler sind spezifisch für diese Funktion. Sie werden stets mit
einem XML-Dokument als Antwort signalisiert, welches das Element <errorResponse> als Wur-
zelelement hat. Die nachfolgende Tabelle beschreibt die speziellen Kategorien der Ursachen
der spezifischen Fehler anhand der konkreten Werte für das XML-Tag <code>.
Seite 64 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Die Anforderung von Zeitstempeln durch SLMBC wird ohne eine vorherige Auftragserstellung
(Funktion F3Lock) nur mit der Funktion F4FetchTimestamp realisiert.
Die Funktion nimmt den Hashwert des zu zeitstempelnden Dokumentes entgegen, authentifi-
ziert sich gegenüber dem Zeitstempeldienst im AuthentiDate Trustcenter und übergibt diesem
die Daten, mit der Zeitstempelanforderung. Als Ergebnis wird der eigentliche Zeitstempel im
angegebenen Format (RF3161, PKCS#7) zurückgegeben. Dabei ist zu beachten, dass die Da-
ten direkt über den HTTPS-Request, und nicht über das sichere Verzeichnis ausgetauscht wer-
den.
Bitte beachten Sie: Diese Funktion ersetzt die Funktionalität des alten eTimeStamp Moduls aus
der AuthentiDate API 2.x.
Die Benutzerkonfiguration für den Zugriff auf den akkreditierten AuthentiDate Zeitstempeldienst
wird über die Konfiguration der Funktion F4FetchTimestamp umgesetzt, d.h. bei einer Anforde-
rung für Zeitstempel müssen diese Benutzerdaten im Gegensatz zum alten eTimestamp Modul
nicht mehr beim Aufruf übergeben werden, sondern liegen zentral in der oben genannten Konfi-
gurationsdatei.
Seite 65 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Anfragedokumentes, wel-
ches vom Benutzer (Software-Applikation) an SLMBC gesendet wird.
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Antwortdokumentes, wel-
ches vom SLMBC an den Benutzer (Software-Applikation) zurückgesendet wird.
Bei der Ausführung der Funktion F4TimeStamp können Fehler auftreten. Einige davon werden
in Tabelle 62 erklärt. Alle anderen Fehler sind spezifisch für diese Funktion. Sie werden stets
mit einem XML Dokument als Antwort signalisiert, welches das Element <errorResponse> als
Wurzelelement hat. Die nachfolgende Tabelle beschreibt die speziellen Kategorien der Ursa-
chen der spezifischen Fehler anhand der konkreten Werte für das XML-Tag <code>.
Seite 66 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Mit dem Aufruf der Funktion wird SLMBC veranlasst, die in einem sicheren Verzeichnis befindli-
chen Dateien nun auch zu signieren. Der Zweck der Funktion ist, SLMBC den „Startschuss“ für
die massenhafte Erstellung von Signaturen zu geben.
Die Wirkung der Funktion ist die eines Signalgebers, weshalb SLMBC auch nach Kenntnisnah-
me des Signals direkt ein XML-Dokument als Antwortdatenstruktur zurückgibt.
Aufgrund des Signals wird SLMBC die Zugriffsrechte des zum Vorgang gehörenden sicheren
Verzeichnisses und aller rekursiv darin enthaltenen Dateien und Unterverzeichnisse derart än-
dern, dass auf diese nur noch SLMBC selbst und vertrauenswürdige Prozesse schreibend und
lesend zugreifen können.
Danach wird unverzüglich damit begonnen, die geforderten Signaturen zu erstellen und gemäß
Auftrag des Benutzers neben den zu signierenden Dateien abzulegen oder in die zu signieren-
den Dateien einzubetten.
Nach der erfolgreichen Erzeugung aller Signaturen werden die temporär erzeugten Dateien mit
ihrem endgültigen Namen versehen. Danach werden die Dateirechte des sicheren Verzeichnis-
ses dahingehend verändert, dass der Benutzer Leserechte auf das sichere Verzeichnis und alle
Unterverzeichnisse erhält.
Tritt hingegen während der Erzeugung der Signaturen ein Fehler auf, wird der Ursprungszu-
stand des sicheren Verzeichnisses vor dem Aufruf der Funktion F5SignFile wiederhergestellt.
Danach werden die Dateirechte des sicheren Verzeichnisses dahingehend verändert, dass al-
len Prozessen voller Zugriff auf das sichere Verzeichnis gewährt wird. Nach dieser Modifikation
der Dateirechte ist das sichere Verzeichnis nicht mehr als sicher anzusehen.
Ein wiederholter Aufruf der Funktion für einen Auftrag bewirkt die Fehlermeldung 5002 als Ant-
wort für die wiederholten Aufrufe (s. Kapitel „F5SignFile Fehlerdokument“).
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Anfragedokuments, welches
vom Benutzer (Software-Applikation) an SLMBC gesendet wird.
Seite 67 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Antwort-Dokuments, wel-
ches vom SLMBC an den Benutzer (Software-Applikation) zurückgesendet wird.
Bei der Ausführung der Funktion F5SignFile können Fehler auftreten. Einige davon werden in
Tabelle 62 erklärt. Alle anderen Fehler sind spezifisch für diese Funktion. Sie werden stets mit
einem XML-Dokument als Antwort signalisiert, welches das Element <errorResponse> als Wur-
zelelement hat. Die nachfolgende Tabelle beschreibt die speziellen Kategorien der Ursachen
der spezifischen Fehler anhand der konkreten Werte für das XML-Tag <code>.
Seite 68 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Mit dem Aufruf der Funktion wird SLMBC veranlasst, die in einem sicheren Verzeichnis befindli-
chen Dateien zu prüfen. Der Zweck der Funktion ist, SLMBC den Startschuss für die massen-
hafte Prüfung von Signaturen zu geben.
Die Wirkung der Funktion ist die eines Signalgebers, weshalb SLMBC auch nach Kenntnisnah-
me des Signals direkt ein XML-Dokument als Antwortdatenstruktur zurückgibt.
Aufgrund des Signals wird SLMBC die Zugriffsrechte des zum Vorgang gehörenden sicheren
Verzeichnisses und aller rekursiv darin enthaltenen Dateien und Unterverzeichnisse so ändern,
dass nur noch SLMBC selbst und vertrauenswürdige Prozesse schreibend und lesend zugrei-
fen können.
Er wird danach unverzüglich begonnen, die geforderten Prüfergebnisse zu erstellen und gemäß
des Auftrages des Benutzers neben den signierten Dateien ablegen.
Nachdem alle Prüfungen erfolgreich durchgeführt wurden, werden die temporär erzeugten Da-
teien mit Ihrem endgültigen Namen versehen. Danach werden die Dateirechte des sicheren
Verzeichnisses dahingehend verändert, dass die aufrufende Rolle Leserechte auf das das si-
chere Verzeichnis und alle Unterverzeichnisse erhält.
Tritt hingegen während der Durchführung der Prüfungen der Signaturen ein Fehler auf, so wird
der Ursprungszustand des sicheren Verzeichnisses vor dem Aufruf der Funktion F6VerifyFile
wiederhergestellt. Danach werden die Dateirechte des sicheren Verzeichnisses dahingehend
verändert, dass allen Prozessen voller Zugriff auf das sichere Verzeichnis gewährt wird. Nach
dieser Modifikation der Dateirechte ist das sichere Verzeichnis nicht mehr als sicher anzusehen.
Ein wiederholter Aufruf der Funktion für einen Auftrag bewirkt eine Fehlerstruktur als Antwort für
die wiederholten Aufrufe.
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Anfragedokuments, welches
vom Benutzer (Software-Applikation) an SLMBC gesendet wird.
Seite 69 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Antwortdokuments, welches
vom SLMBC an den Benutzer (Software-Applikation) zurückgesendet wird.
Bei der Ausführung der Funktion F6VerifyFile können Fehler auftreten. Einige davon werden in
Tabelle 62 erklärt. Alle anderen Fehler sind spezifisch für diese Funktion. Sie werden stets mit
einem XML-Dokument als Antwort signalisiert, welches das Element <errorResponse> als Wur-
zelelement hat. Die nachfolgende Tabelle beschreibt die speziellen Kategorien der Ursachen
der spezifischen Fehler anhand der konkreten Werte für das XML-Tag <code>.
Mit dem Aufruf der Funktion F7Unlock wird SLMBC veranlasst, einen bestehenden Auftrag zur
Erstellung bzw. Prüfung von Signaturen (hier auch kurz „Vorgang“ genannt) vorzeitig abzubre-
chen oder regulär aufzulösen.
Der Zweck der Funktion F7Unlock ist zweigeteilt. Einerseits ermöglicht sie dem Benutzer die
Löschung eines Vorganges aus dem Auftragsbuch von SLMBC. Andererseits ermöglicht sie
dem Benutzer, den vorzeitigen Abbruch eines Vorganges in jedwedem Zustand. Welchem
Seite 70 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Zweck ein konkreter Aufruf dient, ergibt sich aus der Kombination der Aufrufparameter und dem
aktuellen Zustand des Vorganges.
Die Wirkung des Aufrufes der Funktion F7Unlock hängt von dem vom Benutzer beabsichtigten
Zweck und dem aktuellen Zustand des Vorganges ab:
Will der Benutzer den Vorgang aus dem Auftragsbuch von SLMBC löschen, muss er in den
Aufrufparametern den Pfad eines noch nicht existenten Verzeichnisses nennen, durch das das
sichere Verzeichnis dem Benutzer wieder zur Verfügung gestellt werden soll. In diesem Falle
wird ein XML-Dokument als Antwort erst dann erzeugt, wenn das ehemals sichere Verzeichnis
für den Benutzer unter dem angegebenen Pfad bereitsteht. Diese Art des Funktionsaufrufes
wird in diesem Dokument auch als blockierender Aufruf von F7Unlock bezeichnet.
Die genaue Wirkung des Funktionsaufrufes hängt noch von dem aktuellen Zustand des Vor-
ganges ab. Ist der Vorgang bereits abgeschlossen, das heißt, wurden alle beauftragten Signa-
turen erzeugt bzw. geprüft, dann löst der Aufruf nur recht wenig Aktion seitens SLMBC aus. Er
löscht die Datei namens „jobStatus.xml“ aus dem sicheren Verzeichnis und setzt die Zugriffs-
rechte rekursiv für das sichere Verzeichnis des Vorganges so, dass auch der Benutzer wieder
lesend und schreibend zugreifen kann. Das Löschen der Datei namens „jobStatus.xml“ ge-
schieht sicherheitshalber, weil nach dem Freigeben der Zugriffsrechte die darin enthaltene In-
formation nicht mehr gegen Manipulationen geschützt und deshalb nicht mehr vertrauenswürdig
ist. Danach wird das Verzeichnis zu der gewünschten Position verschoben.
In jedem anderen Zustand des Vorganges erfolgt ein zusätzlicher Schritt vor der Änderung der
Zugriffsrechte des Sicheren Verzeichnisses: SLMBC löscht eventuelle Zwischenergebnisse, wie
bereits erstellte Signaturen oder erzeugte Prüfergebnisse, und stellt damit den ursprünglichen
Zustand des Verzeichnisses wieder her. Ein wiederholter Aufruf der Funktion zum Zwecke der
Löschung des Vorganges, während ein erster Aufruf noch schwebt, bewirkt eine Fehlerstruktur
als Antwort auf die wiederholten Aufrufe.
Jede andere Art des Aufrufes der Funktion F7Unlock gibt SLMBC lediglich ein Signal, dass der
Vorgang abzubrechen ist. Diese Art des Funktionsaufrufes wird in diesem Dokument auch als
nicht blockierender Aufruf von F7Unlock bezeichnet. Sie ist daran erkennbar, dass der Benutzer
in den Aufrufparametern kein Zielverzeichnis benennt. Die Antwort auf diesen Aufruf ist dann
lediglich die Bestätigung, dass der Abbruch erfolgen wird.
Die Wirkung des Aufrufes hängt vom Zustand des Vorganges ab. Ist der Vorgang bereits abge-
schlossen, das heißt, wurden alle beauftragten Signaturen erzeugt bzw. geprüft, ist der Aufruf
wirkungslos, nur der Status des Auftrages wird von „signingCompleted“ oder „verifyingComple-
ted“ auf „terminatedWithSuccess“ gesetzt. Der Aufruf ist auch wirkungslos, wenn für den Vor-
gang bereits mit der Funktion F7Unlock das Signal zum Abbruch gegeben wurde oder wenn
bereits ein Aufruf zum Zwecke der Löschung des Vorganges besteht.
Ansonsten bewirkt der Aufruf, dass SLMBC alle eventuell vorhandenen Zwischenergebnisse
des Vorganges, wie bereits erstellte Signaturen oder erzeugte Prüfergebnisse, löscht und so
den ursprünglichen Zustand des sicheren Verzeichnisses wieder herstellt.
Die Übergabe des sicheren Verzeichnisses an den Benutzer und die vorherige Freigabe seiner
Zugriffsrechte erfolgen nicht durch diesen Aufruf. Hierfür muss der Benutzer die Funktion
F7Unlock blockierend aufrufen, also mit Angabe eines Rückgabeverzeichnisses.
Der asynchrone Modus wird von SLMBC bereitgestellt, da bei einem größeren blockierenden
Aufruf, Timeout-Fehler innerhalb der HTTP-Verbindung auftreten können.
Seite 71 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Anfrage-Dokuments, wel-
ches vom Benutzer (Software-Applikation) an SLMBC gesendet wird.
Das XML-Dokument, welches beim Aufruf der Funktion f7Unlock als Antwort entsteht, hat zwei-
erlei Gestalt. Sie richtet sich nach dem Zweck des Aufrufes der Funktion. Wurde sie nur zum
Zwecke der Anweisung des Abbruchs eines Vorganges an SLMBC aufgerufen, enthält die Ant-
wort nur das Element <lockedAsDir> als Bestätigung ihres Aufrufes.
Wurde die Funktion hingegen zum Zwecke der Löschung des Vorganges aufgerufen, enthält
die Antwort zusätzlich das Element <jobStatus>, in dem der letzte Zustand in vertrauenswürdi-
ger und detaillierter Form an den Benutzer übermittelt wird. Diese Darstellung des Zustandes ist
als verlässliche Quittung für den Benutzer gedacht.
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Antwortdokuments, welches
vom SLMBC an den Benutzer (Software-Applikation) zurückgesendet wird.
Seite 72 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Bei der Ausführung der Funktion F7Unlock können Fehler auftreten. Einige davon werden in
Tabelle 62 erklärt. Alle anderen Fehler sind spezifisch für diese Funktion. Sie werden stets mit
einem XML-Dokument als Antwort signalisiert, welches das Element <errorResponse> als Wur-
zelelement hat. Die nachfolgende Tabelle beschreibt die speziellen Kategorien der Ursachen
der spezifischen Fehler anhand der konkreten Werte für das XML-Tag <code>.
Mit dem Aufruf der Funktion F8Deactivate wird SLMBC veranlasst, eine oder mehrere Gruppen
von Signaturerstellungseinheiten zu deaktivieren. Mit der Deaktivierung ist gemeint, dass die
Signaturerstellungseinheiten mit einer erneuten Authentisierung durch eine PIN-Eingabe akti-
viert werden müssen, bevor sie weitere Signaturen erzeugen können.
SLMBC benutzt diese Funktion selbst, wenn ein Vorgang zur Erstellung von Signaturen in einer
schwach prozessgebundenen Umgebung abgeschlossen wird. Im Betrieb als vollständige Sig-
naturanwendungskomponente stellt SLMBC die Funktion dem Benutzer nicht direkt zur Verfü-
gung. Sie gehört deshalb eigentlich nicht zur externen Schnittstelle. Dennoch ist sie hier be-
schrieben, weil der SLMBC in zwei Teilen betrieben werden kann, eventuell sogar auf getrenn-
ten Rechnern (siehe Kapitel 3.1.1 „Vollständige SAK zur Signaturerstellung“).
Der Zweck der Funktion F8Deactivate ist, alle verfügbaren Signaturerstellungseinheiten einer
Gruppe oder mehrerer Gruppen in einen Zustand zu versetzen, der erst wieder die Erstellung
von Signaturen ermöglicht, wenn der Schlüsselinhaber sich zuvor durch eine PIN-Eingabe au-
thentisiert hat.
Die Wirkung des Aufrufes der Funktion F8Deactivate ist, dass die betroffenen Signatur-
erstellungseinheiten deaktiviert werden und laufende Vorgänge zur Erzeugung von Signaturen
fehlerhaft abgebrochen werden, sofern sie die jeweilige Gruppe von Signaturerstellungs-
einheiten akut benötigen, um eine oder mehrere Signaturen zu erstellen.
Seite 73 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Anfragedokuments, welches
vom Benutzer (Software-Applikation) an SLMBC gesendet wird.
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Antwortdokuments, welches
vom SLMBC an den Benutzer (Software-Applikation) zurückgesendet wird.
Bei der Ausführung der Funktion F8Deactivate können Fehler auftreten. Einige davon werden in
Tabelle 62 erklärt. Alle anderen Fehler sind spezifisch für diese Funktion. Sie werden stets mit
einem XML-Dokument als Antwort signalisiert, welches das Element <errorResponse> als Wur-
zelelement hat. Die nachfolgende Tabelle beschreibt die speziellen Kategorien der Ursachen
der spezifischen Fehler anhand der konkreten Werte für das XML-Tag <code>.
Seite 74 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Mit dem Aufruf der Funktion wird SLMBC veranlasst, eine Liste von Gruppen von Signaturer-
stellungseinheiten im gewünschten Detailgrad zu erstellen und an den Aufrufenden zu überge-
ben.
Der Zweck dieser Funktion ist es, dem Benutzer die gewünschte Detailinformation über die
Gruppen von Signaturerstellungseinheiten zur Verfügung zu stellen. So erfährt der Benutzer,
welche Gruppen zur Erstellung von Signaturen verwendet werden können. Diese Information
wird in der Regel benötigt, um mit Hilfe der Funktion F3Lock einen Vorgang zur Erzeugung von
Signaturen zu erstellen.
Der Benutzer kann die Detailgenauigkeit der Information bestimmen und kann die Liste auf be-
stimmte Gruppen einschränken, um das Kommunikationsvolumen zu verringern. Die Auswahl
trifft er durch entsprechende Parametrisierung des Aufrufes dieser Funktion. In jedem Fall wer-
den Informationen zu der Identität der Gruppen bereitgestellt.
Weiterhin kann der Benutzer auf seinen Wunsch hin getrennt nach Gruppen erfahren:
• wie viele Signaturerstellungseinheiten davon aktiviert sind (ohne weitere Interaktion mit
dem Inhaber Signaturen erstellen können),
Die Ausführung dieser Funktion ist für Vorgänge zur Erstellung von Signaturen ohne Auswir-
kung. Sie erstellt lediglich eine Liste basierend auf Informationen von SLMBC.
Seite 75 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Anfragedokuments, welches
vom Benutzer (Software-Applikation) an SLMBC gesendet wird.
Das XML-Dokument, welches bei der Funktion f9List als Antwort entsteht, ist vielgestaltig und
komplex. Seine konkrete Gestalt hängt von dem Detailgrad der angeforderten Informationen ab.
Deshalb wird hier auf das XML-Schema und die darin enthaltene Dokumentation verwiesen. Die
folgende Tabelle erklärt nur die direkt zum Wurzelelement <f9ListResponse> gehörenden Ele-
mente. Zwar nennt die Tabelle verschiedene Elemente, jede Antwort kann aufgrund der Sche-
madefinition nur genau eines davon enthalten.
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Antwortdokuments, welches
vom SLMBC an den Benutzer (Software-Applikation) zurückgesendet wird.
Seite 76 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Bei der Ausführung der Funktion F9List können Fehler auftreten. Einige davon werden in
Tabelle 62 erklärt. Alle anderen Fehler sind spezifisch für diese Funktion. Sie werden stets mit
einem XML-Dokument als Antwort signalisiert, welches das Element <errorResponse> als Wur-
zelelement hat. Die nachfolgende Tabelle beschreibt die speziellen Kategorien der Ursachen
der spezifischen Fehler anhand der konkreten Werte für das XML-Tag <code>.
Wert von
Bedeutung des Wertes
<code>
9001 Zu der bei den Aufrufparametern benannten Gruppe sind derzeit keine Signaturerstel-
lungseinheiten verfügbar, deren Daten aufgelistet werden können. Der/die Name(n) der
Gruppe(n) wurde(n) nicht gefunden.
9002 Der interne Aufruf der List-Funktion auf dem Zielrechner ist fehlgeschlagen. Diese Fehler-
meldung tritt nur auf, wenn SLMBC in zwei Teilen betrieben wird (siehe Kapitel 3.1.1
„Vollständige SAK zur Signaturerstellung“).
Tabelle 48: F9List Fehlerdokument
Mit dem Aufruf dieser Funktion wird SLMBC veranlasst, dem Benutzer Auskunft über den Zu-
stand eines oder mehrer Vorgänge zu geben. Mit Vorgängen sind sowohl Vorgänge zur Erzeu-
gung als auch zur Prüfung von Signaturen gemeint.
Der Zweck der Funktion ist, dem Benutzer aktuelle Information zum Zustand seiner Vorgänge
verfügbar zu machen. Die Funktion ist dazu gedacht, vom Benutzer wiederholt aufgerufen zu
werden, damit dieser zeitnah erfährt, ob die mit dem Vorgang beauftragte Arbeit bereits erledigt
ist. Erledigt sein kann der Vorgang auch aufgrund eines aufgetretenen Fehlers.
Der Aufruf dieser Funktion hat keine Wirkung auf irgendeinen Vorgang. Es wird nur aktuelle
Information aus dem Arbeitsspeicher von SLMBC zur Verfügung gestellt.
Seite 77 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Anfragedokuments, welches
vom Benutzer (Software-Applikation) an SLMBC gesendet wird.
Das XML-Dokument, welches bei der Funktion F10GetStatus als Antwort entsteht, ist vielgestal-
tig und komplex. Seine konkrete Gestalt hängt von den angeforderten Informationen ab. Des-
halb wird hier auf das XML-Schema und die darin enthaltene Dokumentation verwiesen. Die
folgende Tabelle erklärt nur die direkt zum Wurzelelement <f10GetStatusResponse> gehören-
den Elemente.
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Antwortdokuments, welches
vom SLMBC an den Benutzer (Software-Applikation) zurückgesendet wird.
Innerhalb eines jeden <job> Element befindet sich ein <jobStatus> Element, darin wiederum ein
Element namens <progressInfo> und darin wiederum eines mit dem Namen <jobState>. Letzte-
Seite 78 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
res enthält eine Kennung, welche den aktuellen Zustand des Vorgangs zusammenfassend be-
schreibt. Es hat für Vorgänge zur Erstellung von Signaturen einen der Werte, welche in der
nachfolgenden Tabelle aufgeführt und in der Bedeutung erklärt werden.
Zwei weitere wichtige aber optionale Elemente sind <frozenSince> und <baseUrlForDownlo-
ad>.
Wenn ein Auftrag durch die Funktion F12Freeze eingefroren wurde, ist das Element <frozen-
Since> vorhanden und gibt den Zeitpunkt des Einfrierens wieder Das Element <baseUrlFor-
Download> enthält die Basis-URL, mit der die einzelnen Dateien zur temporären Betrachtung
aus dem sicheren Verzeichnis heruntergeladen werden können.
Seite 79 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Bei der Ausführung der Funktion F10GetStatus können Fehler auftreten. Einige davon werden
in Tabelle 62 erklärt. Alle anderen Fehler sind spezifisch für diese Funktion. Sie werden stets
mit einem XML-Dokument als Antwort signalisiert, welches das Element <errorResponse> als
Wurzelelement hat. Die nachfolgende Tabelle beschreibt die speziellen Kategorien der Ursa-
chen der spezifischen Fehler anhand der konkreten Werte für das XML-Tag <code>.
Mit dem Aufruf dieser Funktion wird SLMBC veranlasst, einen bestehenden Vorgang zur Er-
zeugung von Signaturen oder Prüfergebnissen anzuhalten, damit der Benutzer die zu signie-
renden bzw. zu prüfenden Daten sichten kann.
Der Zweck dieser Funktion ist, SLMBC anzuweisen, für den Vorgang sämtliche Modifikationen
an den Daten des Benutzers vorübergehend anzuhalten und ihm damit die Möglichkeit der Be-
trachtung zu geben. Der Vorgang wird dabei eingefroren.
Während SLMBC die Signaturen zu einem Signaturauftrag erzeugt, kann der Benutzer nicht auf
das sichere Verzeichnis lesend zugreifen. Bei einem eingefrorenen Vorgang kann er jedoch mit
dem Aufruf der Funktion F14GetURL zu einer oder mehrer seiner Dateien jeweils einen URL
erfahren, unter dem ihm SLMBC die jeweilige Datei im Originalzustand zum Herunterladen an-
bietet.
Die Wirkung dieser Funktion ist, dass SLMBC den Vorgang nicht weiter bearbeitet. Diese Funk-
tion darf nicht für einen bereits eingefrorenen Vorgang aufgerufen werden. Ein Vorgang kann
nur eingefroren werden, wenn er sich in einem der Zustände „locked“, „signing“, „verifying“,
„signingCompleted“ oder „verifyingCompleted“ befindet.
Ist er eingefroren, ist kein weiterer Zustandswechsel möglich, bis die Funktion F7unlock oder
F13Thaw für den Vorgang aufgerufen wurde.
Nur wenn ein Vorgang eingefroren ist, kann die Funktion F14GetURL aufgerufen und können
Dateien per URL heruntergeladen werden.
Seite 80 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Anfragedokuments, welches
vom Benutzer (Software-Applikation) an SLMBC gesendet wird.
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Antwortdokuments, welches
vom SLMBC an den Benutzer (Software-Applikation) zurückgesendet wird.
Bei der Ausführung der Funktion F12Freeze können Fehler auftreten. Einige davon werden in
Tabelle 62 erklärt. Alle anderen Fehler sind spezifisch für diese Funktion. Sie werden stets mit
einem XML-Dokument als Antwort signalisiert, welches das Element <errorResponse> als Wur-
zelelement hat. Die nachfolgende Tabelle beschreibt die speziellen Kategorien der Ursachen
der spezifischen Fehler anhand der konkreten Werte für das XML-Tag <code>.
Seite 81 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Mit dem Aufruf dieser Funktion wird SLMBC veranlasst, einen mit Hilfe der Funktion F12Freeze
angehaltenen Vorgang zur Erzeugung von Signaturen fortzusetzen.
Der Zweck dieser Funktion ist, SLMBC mitzuteilen, dass der Benutzer die Daten genügend be-
trachtet hat und dass er deshalb die Fortsetzung der Arbeit des Vorganges wünscht.
Die Wirkung des Aufrufes der Funktion ist abhängig von dem Zustand, in welchem der Vorgang
eingefroren wurde. Nur ein zuvor mit F12Freeze eingefrorener Vorgang kann mit einem Aufruf
der Funktion aufgetaut werden.
Wurde er im Zustand „locked“ eingefroren, bewirkt der Aufruf nur die Löschung der Markierung,
die besagt, dass der Vorgang eingefroren ist. Ansonsten wird zusätzlich die Erstellung bzw.
Prüfung von Signaturen fortgesetzt.
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Anfragedokuments, welches
vom Benutzer (Software-Applikation) an SLMBC gesendet wird.
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Antwortdokuments, welches
vom SLMBC an den Benutzer (Software-Applikation) zurückgesendet wird.
Seite 82 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Bei der Ausführung der Funktion F13Thaw können Fehler auftreten. Einige davon werden in
Tabelle 62 erklärt. Alle anderen Fehler sind spezifisch für diese Funktion. Sie werden stets mit
einem XML-Dokument als Antwort signalisiert, welches das Element <errorResponse> als Wur-
zelelement hat. Die nachfolgende Tabelle beschreibt die speziellen Kategorien der Ursachen
der spezifischen Fehler anhand der konkreten Werte für das XML-Tag <code>.
Mit dem Aufruf dieser Funktion wird SLMBC veranlasst, dem Benutzer einen (oder mehrere)
URL(s) zu benennen, von dem (oder denen) er jeweils eine Datei des Vorganges zur Prüfung
oder Erstellung von Signaturen im Originalzustand herunterladen kann.
Mit Originalzustand ist derjenige Zustand einer Datei gemeint, in dem sie ehemals vom Aufruf
F3Lock in das sichere Verzeichnis verschoben wurde.
Der Zweck der Funktion ist lediglich, dem Benutzer auf komfortable Weise Information bereitzu-
stellen. Er könnte sich den jeweiligen URL zu einer Datei auch selbst anhand der in dem Hand-
buch dokumentierten Regeln konstruieren. Fehlen ihm dazu die Dateinamen, kann er sich über
den Aufruf der Funktion F10GetStatus eine Liste erstellen lassen.
Seite 83 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Der Aufruf der Funktion hat keine Wirkung auf den jeweiligen Vorgang oder die damit verbun-
denen Daten. Er liefert lediglich Status-Informationen.
Die Funktion kann nur für einen Vorgang aufgerufen werden, der zuvor mit einem Aufruf der
Funktion F12Freeze eingefroren wurde.
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Antwortdokuments, welches
vom Benutzer (Software-Applikation) an SLMBC gesendet wird.
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Antwortdokuments, welches
vom SLMBC an den Benutzer (Software-Applikation) zurückgesendet wird.
Seite 84 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Bei der Ausführung der Funktion F14GetURL können Fehler auftreten. Einige davon werden in
Tabelle 62 erklärt. Alle anderen Fehler sind spezifisch für diese Funktion. Sie werden stets mit
einem XML-Dokument als Antwort signalisiert, welches das Element <errorResponse> als Wur-
zelelement hat. Die nachfolgende Tabelle beschreibt die speziellen Kategorien der Ursachen
der spezifischen Fehler anhand der konkreten Werte für das XML-Tag <code>.
SLMBC stellt dem Benutzer, d. h. der aufrufenden Applikation, bei Bedarf eine Kopie der zu
verarbeitenden bzw. verarbeiteten Daten über einen verschlüsselten Download bereit. Zur An-
zeige müssen Mittel verwendet werden, die eine korrekte Darstellung der Daten gewährleisten.
Zum Aufruf der Funktion muss sich der Aufrufende an die HTTPS-Kommunikationsschicht von
SLMBC wenden und innerhalb des HTTP-Protokolls den Befehl GET für einen bestimmten URL
senden. Die URL kann der Aufrufende über die Funktion F14GetURL erfahren, oder das Ant-
wortdokument der Funktion F12Freeze beinhaltet das <baseUrlForDownload>-Tag, welches die
Basis-URL für den Datei-Download darstellt. Eine Kombination aus <baseUrlForDownload> und
übergebenem Dateinamen stellt den Download dar, der auch über einen normalen Web-
Browser realisiert werden kann.
Mit dem Aufruf der Funktion wird SLMBC veranlasst, dem Benutzer eine Kopie einer Datei aus
dem sicheren Verzeichnis eines Auftrages bereitzustellen. Bei der Kopie handelt es sich um
eine Datei in der Form, wie sie ehemals beim Aufruf der Funktion F3Lock an SLMBC überge-
ben wurde.
SLMBC stellt die Datei in Form eines binären Datenstromes als Antwort innerhalb der HTTP-
Kommunikationsschicht bereit. Dies entspricht gänzlich dem gewohnten Herunterladen einer
Datei per Web-Browser aus dem Internet.
Tritt bei der Bedienung der Funktion „download“ ein Fehler auf, wird SLMBC innerhalb der
HTTP-Kommunikationsschicht den Fehler in der dort üblichen Weise anzeigen: Entsteht der
Fehler, bevor der HTTP-Header der Antwort von SLMBC gesendet wurde, wird mit der Anzeige
eines entsprechenden HTTP-Fehlerwertes reagiert. Bei den Fehlerwerten handelt es sich um
diejenigen, die in [RFC 2616] im Abschnitt „Status Code Definitions“ erklärt sind. Tritt während
der Bereitstellung des Datenstromes zum Inhalt der Datei ein Fehler auf, wird der Datenstrom
abgebrochen. Der Aufrufende erkennt den Fehler daran, dass ihm nicht alle Daten gesendet
wurden. Denn SLMBC meldet im HTTP-Header der Antwort die exakte Menge der Daten des
Datenstromes, bevor er beginnt, den Datenstrom zu senden.
Seite 85 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Bitte beachten Sie: Bei der Integration des SLMBC als technische Komponente für Zertifizie-
rungsdienste müssen diese Hinweise vom Hersteller der Anwendung („Integrator“) an die End-
benutzer dieser Anwendung weitergegeben werden.
3.16 Prüftiefe
Die Prüfung der Signaturen kann in fünf verschiedenen Tiefen (Level) stattfinden. Die Prüftiefe
sagt aus, bis zu welcher Qualität eine Signatur verifiziert werden soll.
Je höher die Prüftiefe eingerichtet wird, desto genauer werden die Prüfungen der einzelnen
Signaturen realisiert. Wird eine bestimmte Prüftiefe erreicht, bedeutet dies, dass die Prüftiefe für
diese und alle darin enthaltenen Prüfungen positiv war. Im Grunde genommen bedeutet dies,
dass bei einer Prüfung einfach alle Prüfungsschritte von der niedrigsten Prüftiefe bis zur ange-
forderten Prüftiefe in der Reihenfolge durchgeführt werden, bis entweder alle Prüfungen erfüllt
wurden oder eine fehlschlug.
Welche Schritte bei der jeweiligen Prüftiefe durchgeführt werden und was die jeweilige Prüftiefe
im Prüfresultat bedeutet, ist im Folgenden kurz aufgeführt.
Für den Betrieb im signaturgesetzkonformen Umfeld muss die Prüftiefe fullStatus gewählt wer-
den.
• decode
Bei dieser Prüftiefe werden nur die binäre Datenstruktur decodiert und die daraus ge-
wonnene Information im Prüfresultat bereitgestellt. Wenn diese Prüftiefe erreicht wird, ist
also die Struktur der binären Datenstruktur intakt und entspricht den Formatspezifikatio-
nen.
• signature
Bei dieser Prüftiefe wird der Level decode und zusätzlich die Signaturen in den Daten-
strukturen mathematisch geprüft. Wenn diese Prüftiefe erreicht wird, ist also der Finger-
abdruck des Dokuments in Ordnung. Dies bedeutet, dass das Dokument nicht verändert
wurde und damit in der ursprünglichen Version existiert.
• chain
Bei dieser Prüftiefe werden die oben genannten Level geprüft und zusätzlich der Zertifi-
katspfad zu jeder Signatur geprüft. Damit wird dann abgesichert, dass der jeweils Unter-
zeichnende wirklich die benannte Person ist, weil dies durch die Zertifikate von vertrau-
enswürdiger Stelle bestätigt wird.
• signerStatus
Bei dieser Prüftiefe werden die oben genannten Level geprüft und zusätzlich der Status
des Zertifikats des Unterzeichners beim Zertifizierungsdienstanbieter eingeholt. Damit
wird bestimmt, ob der private Schlüssel des Unterzeichners zum Zeitpunkt, welcher als
Prüfzeitpunkt gewählt wurde, gültig war.
Bitte beachten Sie: Zum Erreichen dieser Prüftiefe muss in der Regel Online-
Kommunikation stattfinden.
• fullStatus
Bei dieser Prüftiefe werden die oben genannten Level geprüft und zusätzlich Statusin-
formationen zu sämtlichen anderen Zertifikaten der zur Prüfung notwendigen Zertifikats-
kette eingeholt. Dies geschieht in ebensolcher Weise wie beim Zertifikat des Unter-
Seite 86 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
zeichners. Dies wird für jede im Signaturcontainer enthaltene Signatur getrennt geprüft.
Bitte beachten Sie: Zum Erreichen dieser Prüftiefe muss in der Regel Online-
Kommunikation stattfinden.
Bei der gesetzten Prüftiefe „fullStatus“ greift der Caching-Mechanismus von SLMBC und ver-
mindert dadurch die Anzahl der Online-Zugriffe. Beim Cachen prüft SLMBC, ob es schon zu
den zu überprüfenden Zertifikaten eines Dokuments ein Ergebnis aus einer vorherigen Prüfung
gibt und nutzt dieses Ergebnis. Dies bedeutet, dass bei der Prüfung eines Stapels mit n-Seiten
bei der ersten Prüfung das Zertifikat des Signierenden online angefragt wird und alle weiteren
Prüfungen dann auf den Cache zugreifen, sofern die jeweiligen Zeitpunkte der Signaturerstel-
lung vor dem Zeitpunkt der Auskunft liegen.
Der erste Online-Zugriff kann im Vergleich zu Offline-Prüfungen abhängig von der Netzauslas-
tung langsamer sein. Jedoch ist jede weitere Prüfung innerhalb des Caches wesentlich schnel-
ler als die Erste. Auf einem Standard-PC können so bis zu vier Signaturen pro Sekunde geprüft
werden.
Auf Anforderung werden in den Prüfergebnissen Nachweise über die Existenz und Sperrung
von Zertifikaten im qualifiziert elektronisch signierten Original zusammen mit für die Prüfung
notwendigen und aus einem öffentlichen Verzeichnis abgefragten Zertifikaten bereitgestellt.
Diese Nachweise und Zertifikate sind zur Archivierung gedacht, damit auf Basis ihrer Informati-
on die Prüfung zu einem späteren Zeitpunkt wiederholt werden kann. Beim Erstellen eines Auf-
trages zur Prüfung von Signaturen kann SLMBC mitgeteilt werden, dass zu den zu prüfenden
Signaturen solche Nachweise und Zertifikate existieren, die sie dann anstelle erneut eingeholter
Nachweise ausschließlich verwendet. SLMBC prüft die Vertrauenswürdigkeit sowohl neu ein-
geholter als auch bereitgestellter Nachweise und Zertifikate anhand ihrer qualifizierten elektro-
nischen Signatur.
Zur Beurteilung der Vertrauenswürdigkeit von Zertifikaten und Nachweisen verlässt sich
SLMBC auf eine im lokalen Dateisystem sicher hinterlegte Menge von Vertrauensankern in
Form von Wurzelzertifikaten.
Das Ergebnis der Prüfung einer Signatur wird als so genannter „Evidence-Record“ in Form ei-
nes XML-Dokuments an den Aufrufenden zurückgegeben. Die Inhalte dieses „Evidence-
Record“ beschreiben:
• welche Inhalte das qualifizierte Zertifikat, auf dem die Signatur beruht, aufweist,
• zu welchem Ergebnis die Nachprüfung von Zertifikaten führte, durch die die Zuordnung
eines Signaturprüfschlüssels zu einer identifizierten Person durch ein qualifiziertes Zerti-
fikat zu bestätigen und dieses jederzeit für jeden über öffentlich erreichbare Kommunika-
tionsverbindungen nachprüfbar und abrufbar zu halten ist.
Seite 87 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Nachfolgend sind die Einträge in die Protokolldateien beschrieben. Es wird darauf hingewiesen,
welche Einträge auf Fehlerzustände hinweisen können.
Ferner sind die Fehlermeldungen aufgeführt, die beim Start von SLMBC auftreten können. Dies
betrifft in der Regel Fehler in der Konfigurationsdatei oder Fehler bei der Sicherheit der Einsatz-
umgebung.
Außerdem sind die allgemeinen Fehler der Schnittstelle von SLMBC beschrieben, die bei allen
Funktionsaufrufen auftreten können.
Protokolleinträge weisen das Tag <log4j:event> auf, dass das Protokollereignis kennzeichnet.
Bei der SLMBC-Protokolldatei wird dabei aufgeführt, welcher Programmteil das Ereignis ausge-
löst hat, wann es aufgetreten ist (Timestamp), welchem Protokolllevel das Ereignis zugeordnet
ist und aus welchem Programmfaden (Thread) es stammt. Die EVG-Protokolldatei führt zusätz-
lich auf, welcher Benutzer für das Ereignis verantwortlich ist; dabei ist zwischen dem Betriebs-
systembenutzer und dem HTTP-Benutzer zu unterscheiden. Der Betriebssystembenutzer muss
immer der Benutzer sein, unter dem SLMBC läuft. Der HTTP-Benutzer ist der Benutzer, der
aufgrund der HTTP-Basic Authentication beim Funktionsaufruf erkannt wurde. Für die Funktio-
nen F1, F2, F8 und F9 ist dies der entsprechend konfigurierte interne Benutzer. Darüber hinaus
wird der Zeitstempel in UTC-Zeit angegeben.
Der eigentliche Protokolleintrag befindet sich innerhalb des Tags <log4j:message> und be-
schreibt das Protokollereignis im Klartext.
Die EVG-Protokolldatei führt noch im Tag <log4j:locationInfo> die Referenz zur Java-Methode
auf, die den Protokolleintrag erzeugt hat.
Einträge im Tag <log4j:throwable> weisen auf schwere Fehler hin. Diese sind umgehend zu
beheben, die Fehlerursache ist zu klären.
Seite 88 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Seite 89 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Kann SLMBC nicht starten, liegt entweder ein Fehler in der Konfigurationsdatei vor, oder die
Zugriffsrechte auf die Verzeichnisse sind nicht passend gesetzt.
Fehlermeldung Ursache/Lösung
configuration read from Ursache: Die Zugriffsrechte sind fehlerhaft gesetzt.
C:\AD_SLMBC_3.0\Server\slmbc-config.xml SLMBC meldet, welcher Benutzer unberechtigterweise
is wrong: Zugriff hat. Es wird ebenfalls das Verzeichnis mitgeteilt,
checking access permissions failed für das diese Zugriffsrechte bestehen.
Lösung: Prüfen Sie, weshalb die Zugriffsrechte beste-
hen. Dies kann ein Missbrauchsversuch sein! Setzen
Sie die Zugriffsrechte entsprechend.
error when trying to parse the configuration Ursache: Die Konfigurationsdatei ist syntaktisch fehler-
from C:\AD_SLMBC_3.0\Server\slmbc- haft.
config.xml: Lösung: Prüfen Sie die Fehlermeldung. Sie enthält
javax.xml.bind.UnmarshalException: Element Hinweise auf die fehlerhafte Syntax. Korrigieren Sie die
type "xml" must be followed by either Konfigurationsdatei entsprechend.
attribute specifications, ">" or "/>".
error when trying to parse the configuration Ursache: Die XML-Struktur der Konfigurationsdatei ist
from C:\AD_SLMBC_3.0\Server\slmbc- nicht wohlgeformt.
config.xml: Lösung: Prüfen Sie die Fehlermeldung. Sie enthält
javax.xml.bind.UnmarshalException: The Hinweise auf die fehlerhafte XML-Struktur. Korrigieren
markup in the document preceding the root Sie die Konfigurationsdatei entsprechend.
element must be well-formed.
error when trying to parse the configuration Ursache: Die XML-Struktur der Konfigurationsdatei
from C:\AD_SLMBC_3.0\Server\slmbc- enthält ein unbekanntes Tag.
config.xml: Lösung: Prüfen Sie die Fehlermeldung. Sie enthält
javax.xml.bind.UnmarshalException: Unex- Hinweise auf die fehlerhafte XML-Struktur. Korrigieren
pected end of element {}:httpServer Sie die Konfigurationsdatei entsprechend.
Exception in thread "main" ja- Ursache: Die Konfigurationsdatei enthält einen falschen
va.lang.IllegalArgumentException: unsup- Wert innerhalb eines Tags.
ported logLevel: INFOS Lösung: Prüfen Sie die Fehlermeldung. Sie enthält
Hinweise auf das falsche Tag. Korrigieren Sie die Konfi-
gurationsdatei entsprechend.
usage: SIRServer <confFile> Ursache: Die Konfigurationsdatei wurde nicht angege-
ben.
Seite 90 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Fehlermeldung Ursache/Lösung
Lösung: Geben Sie beim Start von SLMBC die Konfigu-
rationsdatei als einzigen Parameter an.
Exception in thread "main" ja- Ursache: Es wurde ein falscher Hostname angegeben.
va.net.UnknownHostException: testhost: Lösung: Tragen Sie den korrekten Hostname in die
testhost Konfigurationsdatei ein.
Exception in thread "main" Ursache: Es wurde eine Portnummer angegeben, die
org.mortbay.util.MultiException[java.net.Bind bereits verwendet wird.
Exception: Address already in use: Lösung: Geben Sie eine andere Portnummer an, unter
JVM_Bind] der SLMBC erreicht werden kann.
Exception in thread "main" Ursache: Es wurde eine nicht unterstützte Ciphersuite
org.mortbay.util.MultiException[java.io.IOExc konfiguriert.
eption: Lösung: Die Ciphersuites sollten nicht geändert wer-
Could not create JsseListener: ja- den. Konfigurieren Sie die korrekten Ciphersuites.
va.lang.IllegalArgumentException: Unsup-
ported ciphersuite
TLS_RSA_WITH_AES_512_CBC_SHA]
Tabelle 63: Fehlermeldungen beim Start von SLMBC
Aufgrund der Verwendung mehrerer klar getrennter Protokollschichten über dem TCP-Protokoll
ist SLMBC in der Lage, Fehler innerhalb der jeweiligen Schichten differenziert zu melden.
Wird zum Beispiel mit dem Benutzer (d. h. mit der Software-Applikation) keine Einigung über
das zu verwendende Verschlüsselungsverfahren innerhalb der SSL-Schicht für das HTTPS-
Protokoll erzielt, wird innerhalb dieses Protokolls auch die übliche Fehlermeldung erzeugt.
Bei den Aufrufen per XML über HTTPS verlangt SLMBC immer eine Identifikation und Authenti-
sierung des Aufrufenden per HTTP Basic Authentication. Wird dies vom Aufrufenden nicht ü-
bermittelt, reagiert SLMBC mit der vom Standard [RFC 2617] für das HTTP-Protokoll spezifizier-
ten Fehlermeldung innerhalb der HTTP-Schicht.
Formale Fehler auf der Ebene des proprietären Protokolls des SLMBC, das aus einem XML-
Dokument für den Aufruf und einem XML-Dokument für die Antwort besteht, werden innerhalb
dieser Schicht mit einem XML-Dokument zur Fehlerbeschreibung signalisiert.
Name und Bedeutung der Werte der Attribute und eingebetteten Elemente sind in der folgenden
Tabelle erklärt.
Seite 91 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Mit dem Wert des Elementes <code> innerhalb des XML-Dokuments mit dem Wurzelelement
<errorResponse> wird die Kategorie der Ursache des Fehlers in einer Form dargestellt, die ma-
schinell einfach weiterverarbeitbar ist. Somit kann der Prozess des Benutzers auf einige Fehler
selbständig reagieren und zum Beispiel bei einem temporären Fehler die gewünschte Aktion
später erneut veranlassen. Einige der konkreten Werte für <code> werden bei Fehlern benutzt,
die bei allen Funktionen von SLMBC entstehen können. Diese generellen Fehler sind bezüglich
der Werte für <code> in der Tabelle 65 erklärt. Andere Werte sind jeweils bei der jeweiligen
Funktion beschrieben.
Seite 92 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Seite 93 von 94
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
5 Literaturverzeichnis
[1] Gesetz über Rahmenbedingungen für elektronische Signaturen, 16. Mai 2001, Stand:
Geändert durch Art. 1 G v. 4. 1.2005 I 2
[2] Verordnung zur elektronischen Signatur, 16. November 2001, Stand: Geändert durch
Art. 2 G v. 4. 1.2005 I 2
[3] AuthentiDate SLM Base Component V3.0 Sicherheitshandbuch, Version 1.2.6,
22.11.2007
Seite 94 von 94