4 Konzept für die Sicherung von Publikationen auf dem Dokumentenserver der HU Berlin

Wie bereits im Kapitel 2 dargestellt worden ist, umfasst das Thema Langzeitarchivierung von digitalen Dokumenten eine Reihe von Aspekten. In diesem Rahmen wird ein Konzept vorgestellt, wie elektronische Signaturen und Zeitstempel genutzt werden können, um die Authentizität und Integrität der Veröffentlichungen auf dem Dokumentenserver der HU Berlin langfristig zu gewährleisten. Die Betrachtungen erfolgen am Beispiel der elektronischen Dissertationen, da sie die mit Abstand größte Gruppe von Publikationen ist. Eine Erweiterung auf andere Publikationsformen ist jedoch problemlos möglich.

4.1  Aufgabenstellung

Folgende Teilaufgaben werden im Rahmen der Konzeption betrachtet:

1. Analyse und Bewertung des derzeitigen Prozesses (Wie ist die Effizienz des aktuellen Systems zu beurteilen? Welche Schwachpunkte gibt es?)
2. Entwicklung eines technischen Konzepts für die Sicherung der Authentizität und Integrität der Dokumente unter Berücksichtigung der derzeitigen praktischen Erfahrungen. Die entstehende Lösung soll sich weitestgehend in die derzeitigen Strukturen und Abläufe integrieren und kurzfristig umsetzbar sein.
3. Beschreibung der notwendigen Schritte für die Erstellung und Nutzung von Signaturen und Zeitstempeln (Hierzu gehören Anforderungen an den Archivserver und seine Einsatzbedingungen sowie alle Fragen zur Beantragung der benötigten Zertifikate.
4. Entwicklung einer Migrationsstrategie für die bereits ausgestellten Signaturen und Zeitstempel
5. Beschreibung von Geschäftsvorfällen im Rahmen des Bearbeitungs-Prozesses und Vorgabe von technischen und organisatorischen Rahmenbedingungen
6. Bewertung der vorgeschlagenen Lösung und Aufzeigen von Optimierungsmöglichkeiten und Weiterentwicklungen

Basierend auf dem Beschluss des Akademischen Senats 1998 wurden in Zusammenarbeit zwischen CMS und UB der Humboldt-Universität die organisatorischen und technischen Grundlagen für die elektronische Abgabeform geschaffen. Dies erfolgte anfangs insbesondere im Rahmen der Projekte „Digitale Dissertationen (DiDi) und Teilprojekt 3 von „Dissertationen Online“. Um die Ergebnisse der Projekte langfristig zu sichern und weiter zu entwickeln, wurde die „Arbeitsgruppe Elektronisches Publizieren“ geschaffen:

Zu den wichtigsten organisatorischen Aufgaben der Arbeitsgruppe gehören: 

• Der Aufbau und die ständige Verbesserung eines Geschäftsprozesses, der von der Abgabe der Dissertation bis zur Veröffentlichung und Archivierung der relevanten Dokumente reicht. Hierzu gehört auch die Definition von Rollen, die innerhalb des Prozesses bestimmte Aktionen durchführen.
• Die Überführung der Tätigkeiten im Rahmen dieses Prozesses vom Projekt- in den Regelbetrieb von CMS und UB, sowie die Erarbeitung von Richtlinien und Standards für die Durchführung dieser Tätigkeiten.
• Die Erstellung von Dokumentationen, die Durchführung von Schulungen, die persönliche Betreuung von Autoren sowie andere Maßnahmen, um den Autoren aber auch den Betreibern der zugrunde liegenden Infrastruktur die technischen Anforderungen an die elektronischen Publikationen zu vermitteln.

Technisch orientierte Aufgaben der Arbeitsgruppe sind u.a. : 

• Die Evaluierung, Erarbeitung und Verbesserung von Standards und Standardprodukten im Rahmen des elektronischen Publizierens (Dazu gehören u.a. Standards für Dateiformate, Metadaten, Geschäftsprozesse, Archivierungssysteme sowie die Dokumentensicherung)
• Die Erstellung von Programmen oder Vorlagen für die reale Umsetzung dieser Standards in konkrete IT-Systemarchitekturen
• Der Betrieb der technischen Infrastruktur für die Publikation und Archivierung elektronischer Dokumente
• Die Entwicklung und der Betrieb von Workflow-Anwendungen zur IT-technischen Unterstützung des definierten Geschäftsprozesses

Ein Kernaspekt des an der Humboldt-Universität angewendeten Verfahrens ist neben der Publikation von Dokumenten in einem layoutorientierten Format wie PDF die Konvertierung der Originaldateien des Autors in das struktur-orientierte Format SGML/XML. Dies weist insbesondere Vorteile bei Archivierungs- und Recherchefragen auf.  Ein Schwerpunkt des Publikationsverfahrens resultiert deshalb in der Beschäftigung mit Fragen der Konvertierung von Standard-Textverarbeitungsformaten, vorzugsweise MS Word, in SGML/XML auf der Basis einer vorgegebenen Dokumenttyp-Definition (DTD).

Ein weiterer Schwerpunkt, der schon sehr früh als wichtiger Aspekt im Rahmen des Publikationsprozesses erkannt wurde, ist die Frage der Sicherheit von elektronischen Dokumenten und den zugrunde liegenden IT-Systemen. Im vorangegangenen Kapitel wurde der Einsatz  elektronischer Signaturen und Zeitstempel für die Sicherung von Dokumenten motiviert. Bereits seit 1998, also mit dem Erscheinen des Signaturgesetzes in seiner ersten Fassung, wurden am CMS Signaturen auf der Basis von Zertifikaten eines akkreditierten Zertifizierungsdiensteanbieters (Telesec) eingesetzt. Dazu wurden für diejenigen Mitarbeiter des CMS, die berechtigt sind, Signaturen über Dokumenten zu erstellen,  persönliche Chipkarten beantragt. Die Zertifikate wurden auf Pseudonyme ausgestellt und mit einer Selbstbeschränkung versehen. Durch Nutzung der Anwendung PKS-Crypt der Telesec werden an bestimmten Stellen des Geschäftsprozesses Signaturen und Zeitstempel über den relevanten Dokumenten erzeugt. Dies findet auf einem separaten Archivserver statt, der für die Zeit der Nutzung der Signaturkomponenten einen Netzzugang besitzt. Nach erfolgreicher Durchführung der Aktion wird ein Backup des Servers erstellt und der Rechner komplett abgeschaltet.

Ziel dieses Abschnittes ist die Darstellung der sicherheitsrelevanten Teile des derzeitigen Geschäftsprozesses sowie deren Evaluierung. Aufgrund der Anforderungsanalyse im ersten Abschnitt dieses Kapitels sowie der erkannten Probleme bzw. Unzulänglichkeiten des jetzigen Verfahrens lässt sich im Weiteren eine fortgeschrittene Architektur für die Sicherung der elektronischen Dokumente entwerfen.

Die folgende Abbildung stellt einen Ausschnitt aus dem Publikationsprozess dar und referenziert im Wesentlichen nur die Stellen, an denen sich Dokumentformate ändern bzw. Signaturen oder Zeitstempel über den Dokumenten erstellt werden.

	Abbildung 4.1 Dokumenten-Workflow

Im Folgenden werden die Kritikpunkte am derzeitigen Verfahren aufgeführt:

1. Im Rahmen des Publikationsprozesses durchläuft ein Dokument eine Reihe von Konvertierungen, die zu folgenden Gruppen zusammengefasst werden können: Das Originaldokument, das durch den Autor abgegeben wird, die PDF-Version, die ebenfalls noch vom Autor erzeugt wird, die SGML-Version und evtl. zusätzliche Dokumente sowie die HTML-Version. Diese Versionen bestehen im Allgemeinen aus mehreren Dateien. Für die Erstellung der Signatur werden sie in einem ZIP-Archiv zusammengefasst und dann signiert. Da in dem derzeitigen Signaturformat auch die Originaldatei vorhanden ist, wurde in einigen Fällen die erhaltene Signaturdatei manuell gesplittet, in dem der intern vorhandene Header und der Footer in separaten Dateien gespeichert und nur diese archiviert wurden. Ein Prüfen der Signatur erfordert dann zunächst ein Zusammensetzen zur Originaldatei.
   Die Nutzung einer ZIP-Datei für die Zusammenfassung der Dokumenten-Version ist insofern problematisch, als dass keine Prüfung der Integrität von einzelnen Dateien möglich ist. Entweder muss das ZIP-Archiv für die Signatur-Validierung vorhanden sein, oder es muss aus allen Einzeldateien neu erstellt werden, was schwierig ist, da z.B. durch die Verwendung unterschiedlicher Programme oder auch nur bei Nutzung anderer Kompressions-Level unterschiedliche Archive entstehen, zu denen dann die Signatur nicht passt.
2. Ein nicht direkt aus der Darstellung erkennbarer Aspekt ist die Art der Zertifikate, die im Rahmen des jetzigen Prozesses verwendet werden. Sie werden - konform zum Signaturgesetz - immer für eine natürliche Person ausgestellt. Das heißt, dass bei den derzeit verwendeten Zertifikaten bei einer Prüfung nicht erkennbar ist, welche Institution eigentlich hinter der Person steht, die die Signatur erzeugt hat. Einsichtig ist, dass eine Signatur der Person „Anja Mustermann“ erst dann für das Verfahren relevant ist, wenn z.B. ihre Rolle als Mitarbeiterin der Universitätsbibliothek oder des Computer- und Medienservice erkennbar ist. Nur in dieser Eigenschaft ist sie berechtigt, die Signaturen zu erzeugen. Im Rahmen des Lösungskonzepts ist also eine Möglichkeit vorzusehen, diesen organisatorischen Bezug abbilden zu können.
3. Bereits in den jetzt genutzten Zertifikaten wird eine Selbstbeschränkung in Form eines Attributzertifikats verwendet: „Das Zertifikat dient ausschließlich der Erzeugung digitaler Dokumente der Humboldt-Universität zu Berlin.“ Diese Formulierung ist insofern nicht korrekt, als dass zum einen die Erzeugung von Signaturen und nicht allgemein von digitalen Dokumenten gemeint ist und dass Signaturen natürlich nicht von Zertifikaten, sondern von Signaturschlüsseln erzeugt werden. Die Intention der Selbstbeschränkung war sicherlich, dass die Nutzung des Signaturschlüssels auf die Erstellung von Signaturen digitaler Dokumente der HU Berlin beschränkt sein soll. In der Konzeption ist ein Vorschlag für eine Neuformulierung zu unterbreiten.
4. Die derzeitigen Zertifikate wurden auf das Pseudonym „Dig. Dissertationen“ ausgestellt. Die Nutzung eines Pseudonyms ist sinnvoll, da es dem Empfänger einer Signatur wenig weiterhilft, wenn er bei der Prüfung nur den Namen eines ihm persönlich meist unbekannten Mitarbeiters der HU findet. Allerdings ist die derzeitige Formulierung zu einschränkend, da sie sich nur auf einen Teil der Publikationen des Dokumentenservers bezieht. Besser wäre ein organisatorischer Bezug und eine Referenz auf das Gesamtangebot elektronischer Publikationen.
5. Es wird derzeit keine zentrale Dokumentation über die ausgestellten Zertifikate und die Erzeugung von Signaturen und Zeitstempeln geführt. Dies ist jedoch zum Nachweis einer ordnungsgemäßen Tätigkeit im Rahmen des Publikationsprozesses erforderlich. Zur Erhöhung der Transparenz sollten auch über die Policy hinaus die Arbeitsgrundsätze für die Erstellung und Nutzung von Signaturen formuliert und veröffentlicht werden.

Das Lösungskonzept gliedert sich in die folgenden Bereiche:

1. Es werden die zu sichernden Daten im Rahmen der elektronischen Veröffentlichung einer Dissertationen festgelegt. Zum Nachweis der Authentizität und Integrität der verarbeiteten Daten werden elektronische Signaturen und Zeitstempel eingesetzt.
2. Ein Archivierungspaket wird entworfen, das zu signieren und zu zeitstempeln ist. Dieses Paket verweist auf zu sichernde Daten und bezieht Änderungen, wie sie z.B. durch Aktualisierung von Metadaten auftreten, ein. Es wird eine Möglichkeit vorgeschlagen, das Präsentationsproblem beim Signieren von Daten zu berücksichtigen.
3. Es wird ein Anbieter von Zertifikaten und die benötigte Software zur Erstellung der Signaturen ausgewählt. Weiterhin werden Anforderungen an die Systemumgebung für den Rechner definiert, auf dem die Signaturen erzeugt werden sollen.
4. Diejenigen Stellen des derzeitigen Geschäftsprozesses zur Publikation von Dissertationen, die sicherheitsrelevante Aktionen durchführen, werden identifiziert und, wenn notwendig, dem neuen Konzept angepasst.
5. Bei der langfristigen Nutzung von Zertifikaten und elektronischen Signaturen kann eine Reihe von Ereignissen, wie z.B. das Ablaufen der Gültigkeit eines Zertifikats, oder die Kompromittierung des privaten Signaturschlüssels eintreten, die bestimmte Aktionen notwendig machen. Diese Ereignisse werden benannt und entsprechende Maßnahmen vorgeschlagen.
6. In Form einer Policy werden Vorschriften zum Umgang mit den erzeugten Signaturen erstellt und die zu dokumentierenden Ereignisse definiert.
7. Es wird ein Verfahren vorgeschlagen, die bereits in der Vergangenheit ausgestellten Signaturen und Zeitstempel in die neue Architektur zu integrieren.

Im Rahmen des Geschäftsprozesses zur Publikation von Dissertationen werden folgende Gruppen von Daten erzeugt bzw. verarbeitet:

1. Vom Autor eingereichte Dateien
2. Die PDF-Version der Dissertation
3. Die SGML-Version der Dissertation
4. Die HTML-Version der Dissertation
5. Erzeugte Metadaten

Die vom Autor einzureichenden Dateien umfassen gemäß den Anforderungen der „Arbeitsgruppe Elektronisches Publizieren“ der HU [EDOC02a]:

• Originaldateien des verwendeten Textverarbeitungsprogramms (in den meisten Fällen wird es sich hier um Winword-Dateien handeln). Des Weiteren gehören hierzu alle weiteren Bestandteile der Dissertationen, wie z.B. nicht integrierte Bilder, Videos, Audios oder Programme.
• Die durch den Autor erzeugte PDF-Version der Dissertation. Diese wird ohne weitere Änderung auf dem Dokumentenserver publiziert. Bei Problemen ist sie durch den Autor oder in Zusammenarbeit mit dem CMS neu zu erzeugen.
• Jeweils eine Datei mit Schlagwörtern in deutscher und englischer Sprache als unformatierter ASCII-Text.
• Jeweils eine Datei mit dem Abstract der Dissertation in deutscher und englischer Sprache als unformatierter ASCII-Text.

Die SGML-Version entsteht durch automatische Konvertierung der Originaldateien des Autors. Diese müssen den technischen Vorgaben des CMS entsprechen, was in den meisten Fällen durch die Verwendung der angebotenen Formatvorlage realisiert wird. Des Weiteren entsteht ein gewisser manueller Nachbearbeitungsaufwand. Diese Version wird nicht auf dem Dokumentenserver veröffentlicht, sondern dient Zwecken der Recherche und Archivierung.

Die HTML-Fassung der Dissertation wird durch eine automatische Konvertierung aus der SGML-Version gewonnen und auf dem Dokumentenserver publiziert. Hierbei wird die Seiten-Identität der Arbeit gewährleistet, d.h. die Originaldatei, die PDF-Version und die HTML-Version sind auf Seitenebene identisch und damit zitierfähig.

Es lassen sich somit fünf verschiedene Gruppen von Dateien identifizieren, die jeweils zu sichern und zu archivieren sind. Die Inhalte der Gruppen können sich dabei überlappen. Dies sind:

• Original
  Hierunter fallen alle vom Autor dem CMS übergebenen Dateien, also die Originaldateien aus dem verwendeten Textverarbeitungssystem (meist MS Word, aber auch LaTeX) inklusive der benötigten Styles u.ä., die durch den Autor zu erzeugende PDF-Datei der Arbeit, nicht integrierte Anhänge, wie z.B. Programme, Audiodateien und ggf. auch Bilder) sowie die geforderten Dateien mit Metadaten und Abstract.
• PDF
  Die PDF-Version wird durch den Autor selbst erzeugt und nach Prüfung auf Korrektheit durch die Mitarbeiter des CMS auf dem Dokumentenserver veröffentlicht. Falls hier Fehler bemerkt werden, muss die Version durch den Autor neu erstellt werden. Hinzu kommen eventuell Anhänge zur Arbeit, die nicht in das PDF integriert werden können, wie z.B. Programme oder Videos.
• SGML
  Die SGML-Version wird durch die Mitarbeiter des CMS mit Hilfe von Tools aus den Original-Dateien des Autors (meist MS Word) erzeugt. Die Erstellung dieser Version stellt das Kernstück des Ansatzes der HU zur Archivierung von digitalen Dokumenten dar, da hiermit versucht wird, ein nicht proprietäres Dateiformat für die Langzeitarchivierung zu nutzen. Die SGML-Version wird nicht direkt auf einem Dokumentenserver veröffentlicht, sondern dient vielmehr nur der Archivierung und der Recherche. Auch hierzu gehören wieder Anhänge, die nicht integriert, sondern aus den Dokumenten verlinkt sind.
• HTML
  Die HTML-Version wird direkt aus der SGML-Version erzeugt und auf dem Dokumentenserver veröffentlicht. Dabei entstehen einzelne Dateien, die über eine zentrale Einstiegsseite verlinkt sind. So gibt es z.B. separate HTML-Dokumente für die einzelnen Kapitel, das Inhaltsverzeichnis, den Lebenslauf usw. Hinzu kommen die bereits bei der SGML-Version erwähnten Anhänge, die aus dem HTML heraus referenziert werden.
• Metadaten
  Hierunter fallen nicht nur die grundsätzlich zu archivierenden Bestandteile der Arbeit, sondern vielmehr Daten, die der bibliothekarischen Erfassung dienen. Dazu gehören die vom Autor eingereichten Dateien mit Schlagwörtern und Abstract in deutscher und englischer Sprache, aber auch während des Publikations-Workflows erstellte Metadaten.

Für die Nutzung von elektronischen Signaturen ist eine Reihe von Voraussetzungen nötig, deren technische Grundlagen im Kapitel 3 erläutert wurden. Dazu gehört z.B. die sichere Erzeugung von Schlüsselpaaren, die Ausstellung und Sperrung von Zertifikaten oder der Betrieb von Verzeichnisdiensten. Anhand der Anforderungen muss also eine Entscheidung dahingehend getroffen werden, ob diese Leistungen durch eine eigene Infrastruktur oder durch Fremdanbieter in Anspruch genommen werden sollen. Die Erfüllung dieser Anforderungen ist eine zwingende Voraussetzung, um die langfristige Vertrauenswürdigkeit des Archivierungs-Konzepts zu sichern.

Der Computer- und Medienservice der HU Berlin betreibt seit längerer Zeit eine eigene Zertifizierungsinstanz (HU-CA), die Zertifikate für Angehörige der Universität sowie für Server ausstellt. Hierbei handelt es sich um Zertifikate nach dem X509-Standard, die als Dateien gespeichert werden. Der Einsatz von Chipkarten zur Speicherung der Schlüssel ist in Planung. Obwohl die Nutzung der Zertifikate nicht auf bestimmte Anwendungen beschränkt ist, werden diese derzeit hauptsächlich für Zwecke der Authentisierung verwendet. Damit erstellte Signaturen würden einfache Signaturen im Sinne des Signaturgesetzes darstellen (siehe Abschnitt 3.2)

Die HU-CA ist ein hervorragendes Angebot für eine Reihe von Diensten, die innerhalb der Universität genutzt werden. Zur Anwendung im Rahmen des hier vorgestellten Konzepts für die Sicherung der Online-Publikationen auf dem Dokumentenserver wird jedoch die Nutzung der Dienste eines akkreditierten Trustcenters im Sinne des Signaturgesetzes empfohlen:

• Mit den zertifizierten Signaturschlüsseln können qualifizierte Signaturen nach Signaturgesetz erzeugt werden, d.h. dass im Rahmen eines möglichen Verwaltungsgerichtsverfahrens diese einen gesetzlich verordneten Anschein der Echtheit besitzen und somit problemlos als Beweismittel einsetzbar sind. So führt z.B. die Habilitationsordnung der Medizinischen Fakultät Charité in §17 aus: „Für alle verfahrensmäßigen wie die Leistung wertenden Entscheidungen im Habilitationsverfahren gelten die Vorschriften des Verwaltungsverfahrensgesetzes“ und weiter „Alle verfahrenserheblichen Mitteilungen an die Habilitandin oder den Habilitanden bedürfen der Schriftform, dies gilt insbesondere für belastende Entscheidungen und Fristenregelungen“. Zwar erscheint es derzeit noch etwas weit vorgegriffen, dass es zu Gerichtsverfahren im Zusammenhang mit elektronischen Publikationen kommen wird. Ohne eine genauere juristische Betrachtung durchzuführen, kann es aber eine Reihe von Fällen geben, in denen relevant ist, welche Dokumente wann vorgelegen haben. Beispielsweise könnte ein Promovend oder Habilitand abstreiten, ein bestimmtes Original eingereicht zu haben, oder bei urheberrechtlichen Streitigkeiten könnte nachgewiesen werden, dass ein Dokument zu einem bestimmten Zeitpunkt als Veröffentlichung bei der HU Berlin vorgelegen hat. Dies könnte zukünftig besonders dann interessant werden, wenn es um Publikationen geht, bei denen die Papierversion nicht mehr zum Nachweis genutzt werden kann, z.B. bei zusätzlich veröffentlichten multimedialen Dokumenten, die auch Gegenstand der Begutachtung sind.
• Für eine vertrauenswürdige Erstellung der Signaturen ist eine Reihe von Voraussetzungen erforderlich, die vom akkreditieren Anbieter schon durch die gesetzliche Verpflichtung erfüllt und behördlich überprüft werden, wie z.B. die sichere Identifizierung der Antragsteller oder die Speicherung der Schlüssel auf Chipkarten, wodurch eine Nichtabstreitbarkeit der Signaturerzeugung erreicht wird. Wesentlich für das hier vorgestellte Konzept ist der Betrieb eines Zeitstempeldienstes und die langfristige Prüfbarkeit der Zertifikate, die bei einem akkreditierten Anbieter mindestens noch 30 Jahre nach Ablauf der Gültigkeit gewährleistet ist.
• Die Realisierung vieler der oben genannten technischen Konzepte ist bei einer eigenständigen Umsetzung sehr kosten- und personalintensiv. Deshalb ist es sinnvoller, für einen kleinen Anwendungsbereich mit besonderen Anforderungen ein externes Angebot in Anspruch zu nehmen, als das interne Angebot mit Funktionen aufzurüsten, die für einen Großteil der Anwendungen nicht relevant ist. So ist z.B. die sehr aufwändige Inbetriebnahme eines vertrauenswürdigen Zeitstempeldienstes für Zwecke der Verschlüsselung oder Authentisierung nicht zwingend erforderlich, für die langfristige Prüfbarkeit von Signaturen jedoch unerlässlich.

Ausgehend von den vorhergehenden Betrachtungen sollen deshalb qualifizierte Signaturen mit Anbieterakkreditierung eingesetzt werden. In Deutschland gibt es dafür eine Reihe von Anbietern. Folgende betreiben eine eigene Infrastruktur: Authentidate, Datev, D-Trust, Signtrust, TC Trustcenter und Telesec. Es gibt weitere so genannte „virtuelle Trustcenter“, die die Infrastruktur dieser Anbieter zum Aufbau eines eigenen Angebots nutzen, wie z.B. einige Notar- und Steuerkammern. Diese bieten ihre Dienstleistungen aber in der Regel nur Angehörigen bestimmter Berufsgruppen an.

Jeder Mitarbeiter der „Arbeitsgruppe Elektronisches Publizieren“, der berechtigt ist, am Archivserver zu arbeiten, erhält eine persönliche Chipkarte. Derzeit sind dies vier Personen. Bis auf Telesec und Signtrust sind keine Anbieter bekannt, die auch Zertifikate in diesem geringen Umfang ausstellen und keine Zugehörigkeit zu einem bestimmten Verband oder einer Berufsgruppe verlangen. Authentidate hat sich auf die Integration von Lösungen zur Nutzung von Zeitstempeldiensten und zum Scannen und nachträglichen Signieren von Dokumenten spezialisiert. D-Trust wendet sich mit seinem Angebot insbesondere an kleine und mittelständische Firmen, wobei die Beantragung von Zertifikaten grundsätzlich über die zuständige IHK erfolgt. Die Datev hat das Angebot auf Mitglieder eingeschränkt, wie z.B. Steuerberater, die ihre Infrastruktur dort betreiben lassen. TC Trustcenter scheint trotz Akkreditierung zum jetzigen Zeitpunkt gar keine qualifizierten Zertifikate anzubieten. Zumindest ist auf den Webseiten keinerlei Information darüber zu finden; auch die angebotenen Root-Zertifikate sind selbst signiert und nicht von der RegTP ausgestellt.

Bei der Telesec kann der Antrag in jedem T-Punkt vorgenommen werden, eine Einschränkung auf besondere Standorte mit Business-Service oder auch ein Online-Antrag sind jedoch vorgesehen. Es können Hauptzertifikate und Attributzertifikate beantragt werden. Auf Wunsch gibt es auch ein Paket mit Chipkartenleser. Als Anwendung steht PKS-Crypt 1.3 für Windows und SecuBusiness 1.5 zur Verfügung. PKS Crypt erlaubt durch die Integration in den Windows Explorer alle elementaren Operationen über Dateien und basiert auf einer bestätigten Funktionsbibliothek, besitzt selbst jedoch keine Bestätigung der RegTP. Die Software SecuBusiness wird von einem Partner, der Secu-Online AG, entwickelt. Sie integriert sich u.a. auch in Winword und erlaubt eine einfache Erstellung von Signaturen inklusive der Visualisierung der zu signierenden Daten. Es liegt für dieses Produkt aber weder eine Bestätigung noch eine Herstellererklärung zum signaturgesetzkonformen Einsatz vor.

Die Kosten für das Zertifikat des Telesec belaufen sich für die Beantragung einmalig auf EUR 27,35. Die jährliche Gebühr beträgt EUR 49,83. Darin enthalten sind die Ausstellung eines Attributzertifikats sowie die unbegrenzte Nutzung von Verzeichnisdiensten und Zeitstempeldienst.

Signtrust bietet seit einiger Zeit wieder die Möglichkeit der Beantragung von qualifizierten Zertifikaten auch für Einzelpersonen. Nachdem Signtrust den Betrieb bereits einmal eingestellt hatte, wurde er einige Monate später aufgenommen. Die Angebote beschränkten sich dann aber auf Business-Kunden. Nun scheint man das Angebot wieder erweitert zu haben. Die Beantragung erfolgt online auf der Website von Signtrust. Dabei wird ein PDF-Dokument erstellt, das ausgedruckt und an Signtrust gesendet wird. Die Authentifizierung erfolgt über das PostIdent-Verfahren. Als Applikationen scheinen nur Mailkomponenten zur Verfügung zu stehen, diese besitzen jedoch eine Bestätigung der RegTP.

Die Kosten für das Zertifikat betragen im ersten Jahr und in den Folgejahren EUR 45,24 . Bei Nutzung von Attributen im Hauptzertifikat oder in separaten Attributzertifikaten verdoppelt sich der jährliche Betrag auf EUR 90,48.

Aus folgenden Gründen wird empfohlen, die Zertifikate weiterhin beim Anbieter Telesec zu beziehen:

• Es liegen bereits Erfahrungen bei der Nutzung des Telesec-Angebots, insbesondere der Anwendung PKS-Crypt, vor.
• Die Kosten liegen durch die zwingende Inanspruchnahme eines Attributzertifikats zur Selbstbeschränkung niedriger als bei Signtrust (Jahresgebühr für vier Mitarbeiter bei Telesec ca. EUR 199, bei Signtrust ca. EUR 361).
• Als Anwendung werden bei Signtrust derzeit nur Mailkomponenten angeboten. Für die Zwecke des Archivservers ist jedoch eine einfache Anwendung auf Dateiebene erforderlich und ausreichend. Ob die Signtrust-Komponenten dies implizit mit enthalten, konnte jedoch nicht geprüft werden.

Ausgehend von der Analyse der Ist-Situation sind bei der zukünftigen Beantragung von Zertifikaten folgende zusätzliche Anforderungen zu erfüllen:

• Es ist auf geeignete Art und Weise deutlich zu machen, dass die Signaturen, die durch die autorisierten Mitarbeiter erstellt werden, in Vertretung eines Dritten, nämlich der juristischen Person der Humboldt-Universität zu Berlin, erfolgen. Dies ist erforderlich, da das Zertifikat grundsätzlich erst einmal an eine natürliche Person gebunden ist, die Signatur aber in der Rolle als Mitarbeiter der HU und nicht als Privatperson zu erfolgen hat. Daraus ergibt sich, dass die HU auch die Möglichkeit haben muss, ein Zertifikat eines Mitarbeiters ohne seine Mitwirkung zu sperren. Dies ist insbesondere dann erforderlich, wenn der Mitarbeiter die Universität verlässt oder aus anderen Gründen nicht mehr berechtigt ist, Signaturen für den vereinbarten Anwendungszweck zu erstellen.
  Diese Anforderung wird im Folgenden als Vertretungsmacht bezeichnet.
• Die Nutzung der Zertifikate ist in geeigneter Form auf die Signatur und Zeitstempelung von Dokumenten zu beschränken, die im Rahmen der Bearbeitung von elektronischen Publikationen gemäß den Leitlinien des Dokumentenservers der HU Berlin anfallen. Damit wird zunächst einmal verhindert, dass die ausgestellten Zertifikate durch die Mitarbeiter für Zwecke benutzt werden, für die sie möglicherweise keine Legitimation besitzen. Das ist besonders relevant, da ja die Nutzung der Zertifikate in Vertretung der Humboldt-Universität erfolgt.
  Diese Anforderung wird im Weiteren als Selbstbeschränkung bezeichnet.

Für die beiden formulierten Anforderungen werden in den kommenden Abschnitten verschiedene Lösungsvarianten vorgestellt, diskutiert und bewertet.

Das Signaturgesetz sieht diesen Anwendungsfall explizit vor und gibt den Nutzern die Möglichkeit, für diesen Zweck so genannte Attribute zu definieren. Diese Attribute können entweder direkt im Zertifikat oder als separates Attributzertifikat angegeben werden.

Die Nutzung eines Attributzertifikats hat einige Vorteile aufzuweisen. Durch die Trennung in zwei verschiedene Zertifikate kann der Zertifikateinhaber bei jedem Vorgang entscheiden, ob er die Signatur als Privatperson oder in Vertretung des Dritten vornimmt. Auch mehrere Vertretungen einer dritten Person über verschiedene Attributzertifikate sind möglich. Damit erhöht sich die Flexibilität des Einsatzes der Zertifikate. Vor der Beantragung eines Attributzertifikats zur Vertretung Dritter ist dessen Einwilligung einzuholen. Hierzu sieht das derzeitige Antragsverfahren der Telesec eine notarielle Bestätigung über ein gesondertes Formular vor. Diese Anforderung wird in Zukunft auf eine einfache schriftliche Bestätigung reduziert, so dass sich der Aufwand für die Beantragung des Attributzertifikats deutlich reduziert.

Die beantragten Zertifikate für die Mitarbeiter der „Arbeitsgruppe Elektronisches Publizieren“ sollen jedoch ausschließlich für die Signatur von elektronischen Dokumenten genutzt werden. Eine Nutzung als Privatperson ist nicht vorgesehen, die Nutzung als Mitarbeiter der HU zwingend. Dies lässt sich über ein optionales Attributzertifikat nicht erreichen.

Eine weitere Möglichkeit, die Vertretungsmacht abzubilden, besteht darin, diese in das Namensfeld des Zertifikats mit aufzunehmen, z.B. „Peter Müller, HU Berlin“. Damit kommt die Verbindung zur vertretenden Stelle deutlich zum Ausdruck, und auch hier wäre eine Bestätigung notwendig, dass diese Vertretung tatsächlich besteht.

Schließlich kommt noch die Verwendung eines Pseudonyms in Frage. Das Zertifikat wird weiterhin auf eine natürliche Person ausgestellt, die auch alle im Antrag geforderten Angaben machen muss. Allerdings erscheint im Zertifikat nur das Pseudonym, das max. 20 Zeichen lang sein darf. Die dahinter stehende Person darf durch das Trustcenter nur in besonderen Fällen, wie z.B. auf Anforderung von Strafverfolgungsbehörden, offen gelegt werden. Während in vertraglichen Beziehungen die Verwendung eines Pseudonyms eher hinderlich sein dürfte, erfüllt es hier genau den beabsichtigen Zweck. Nicht der Name des Mitarbeiters, der die Signatur zu einem elektronischen Dokument erstellt hat, ist bei einer Prüfung interessant, sondern nur die Tatsache, dass diese Signatur mit einem gültigen Zertifikat der „Arbeitsgruppe Elektronisches Publizieren“ erzeugt wurde. Durch Führung und optional sogar Veröffentlichung einer internen Dokumentation zu ausgestellten Zertifikaten kann die hinter dem Zertifikat stehende Person problemlos ermittelt werden.

Die Intention des Gesetzgebers zum Konstrukt des Pseudonyms war es, aus datenschutzrechtlichen Gründen den Nutzern auch die Möglichkeit zu geben, in bestimmten Anwendungsfällen ohne Erscheinen ihres Namens agieren zu können. Insofern wird das Pseudonym in diesem Zusammenhang etwas zweckentfremdet. Allerdings machen die Zertifizierungsdiensteanbieter selbst Gebrauch davon, wie man an den CA-Zertifikaten leicht sieht, z.B. „Telesec PKS SigG CA 1:PN“. Auch diese Zertifikate sind letztendlich auf eine konkrete Person ausgestellt, die jedoch im Zusammenhang mit einem CA-Zertifikat nicht relevant ist.

Auch Pseudonyme dürfen Hinweise auf eine Vertretung Dritter enthalten [SigG01 §5(3)]. Eine Bestätigung der vertretenden Stelle ist dem Zertifikatsantrag beizufügen.

Für die Zertifikate wird die Verwendung eines Pseudonyms empfohlen. Als Eintrag wird „EDOC CMS HU-BERLIN“ festgelegt. Eine Unterscheidung der Zertifikate bei gleichem Namen wird automatisch durch den Zertifizierungsdiensteanbieter vorgenommen, in dem er das Kürzel „PN“ zur Kennzeichnung des Namens als Pseudonym und eine Zahl zur Unterscheidung hinzufügt. Die ersten beiden Einträge werden also „EDOC CMS HU-BERLIN:PN 1“ sowie „EDOC CMS HU-BERLIN:PN 2“ lauten.

Auch für diesen Zweck sieht das Signaturgesetz die Möglichkeit der Nutzung von Attributen vor. Die Selbstbeschränkung kann dabei in das Hauptzertifikat aufgenommen werden, was bei der derzeitigen Zertifikatsstruktur der Telesec nicht vorgesehen ist, oder als separates Attributzertifikat ausgestellt werden. Im Unterschied zu einem Attributzertifikat zur Vertretung Dritter gibt es hier zumindest im Hauptzertifikat einen Hinweis, dass eine Selbstbeschränkung in Form eines Attributzertifikats existiert. Der Empfänger sollte eine Signatur dann ablehnen, wenn dieses Attributzertifikat nicht mitgeliefert wird.

Folgende Formulierung der Selbstbeschränkung wird vorgeschlagen:

Die Nutzung des Signaturschlüssels ist auf die Signatur von elektronischen Dokumenten beschränkt, die zur Veröffentlichung auf dem Dokumentenserver der HU Berlin bestimmt sind oder im Rahmen der durch die Leitlinien des Dokumentenservers der HU Berlin vorgegebenen Aufgaben verarbeitet werden.

Diese etwas kompliziert wirkende Formulierung schränkt den Handlungsspielraum so ein, dass alle regulären Aufgaben zur Archivierung der Dokumente erfüllt werden können, aber keine weitergehenden Möglichkeiten zur Nutzung der Signatur vorhanden sind. So musste z.B. ausgeschlossen werden, dass die Signatur für Bestellungen, Konferenzanmeldungen o.ä. genutzt werden kann.

Es ist zu prüfen, ob im Zuge der Umstellung des Telesec-Trustcenters auf einen ISIS-MTT-kompatiblen Betrieb die Möglichkeit besteht, die Selbstbeschränkung direkt im Hauptzertifikat unterzubringen. Dies würde noch eine höhere Transparenz erzeugen und die Nutzung von Attributzertifikaten überflüssig machen.

Nachdem im vorangegangenen Abschnitt der ZDA Telesec für die Ausstellung der Zertifikate gewählt wurde, beschäftigt sich dieser Abschnitt konkret mit dem Verfahren der Beantragung der Zertifikate. Die Telesec bietet für diesen Zweck ein Paket mit allen notwendigen Formularen an, das bei den T-Punkten oder über den zentralen Service bezogen werden kann. Im Folgenden wird auf die Antragsversion vom Juli 2002 Bezug genommen. Das Paket besteht aus folgenden Formularen:

• Antrag auf Teilnahme am Public Key Service gemäß den Anforderungen des deut schen Signaturgesetzes (PKS-SigG)
  Dies ist das eigentliche Formular zur Beantragung der Zertifikate. Es fordert Angaben zur Person, zu Details der beantragten Zertifikate sowie zur Bezahlung der Leistungen aus diesem Vertrag. Das Formular findet sich im Anhang. Weiter unten in diesem Abschnitt folgen konkrete Hinweise zum Ausfüllen des Formulars.
• Leitfaden zum Ausfüllen des Antrags auf Teilnahme am Public Key Service
  Hier werden Hinweise zum Ausfüllen des Hauptformulars gegeben.
• Informationen zur Teilnahme am Public Key Service
  Diese Broschüre vermittelt grundsätzliche Informationen zu digitalen Signaturen, der praktischen Anwendung und den rechtlichen Grundlagen ihres Einsatzes.
• Attribut-Zertifikat zur Selbstbeschränkung
  Dieses Formular ist zu benutzen, wenn eine Beschränkung der Nutzung des Zertifikats, z.B. auf die ausschließliche Signatur von Dokumenten im Rahmen des elektronischen Publikationsprozesses, vorgesehen ist.
• Attribut-Zertifikat zur berufsrechtlichen oder sonstigen Zulassung (Erlaubnis, Geneh migung, Konzession, Bewilligung o.ä.)
  Mit diesem Formular können spezielle Berufsbezeichnungen, wie z.B. Facharzt für Allgemeinmedizin oder Notar, als Attribut-Zertifikat integriert werden. Da diese Ausstellung eine Prüfung der Zulässigkeit des Führens dieser Bezeichnung einschließt, muss der Antrag von einer für die Bezeichnung zuständigen Stelle (z.B. Bundesnotarkammer) bestätigt werden.
• Attribut-Zertifikat zur Vertretungsmacht für einen Dritten (Teil I für den Antragsstel ler, Teil II für den Dritten)
  Da Zertifikate immer nur für natürliche Personen ausgestellt werden, bei Signaturen jedoch häufig ein Agieren der Person in einer bestimmten Rolle einer juristischen Person erforderlich ist (z.B. Sachbearbeiter der Techniker Krankenkasse) kann hiermit wieder in einem zusätzlich ausgestellten Attribut-Zertifikat diese Vertretung eines Dritten nachgewiesen werden. Dazu ist eine Einverständniserklärung des Dritten erforderlich, und dieser erhält damit auch das Recht, das Zertifikat zu widerrufen.
• Preisliste Public Key Service
  

Wie bei der Durchsicht der vielen Formulare ersichtlich, ist eine Reihe von eigenhändigen Unterschriften notwendig, bevor endlich elektronisch signiert werden darf.

Die meisten Angaben des Antragsformulars sind selbsterklärend und vom Antragsteller persönlich auszufüllen. Da auch einige organisatorische Angaben verlangt werden, ist es sinnvoll, den Antrag gemeinsam mit der Verwaltungsleitung auszufüllen.

Unter Punkt 4 ist ein so genanntes Telepasswort anzugeben, das z.B. bei der telefonischen Sperrung eines Zertifikates abgefragt wird. Es ist bei der Verwaltungsleitung sicher zu hinterlegen. Die Zustellung der PKS-Karte kann per Post erfolgen. Das Zertifikat soll zum Abruf über das Zertifikatsverzeichnis freigegeben werden. Die Zahlungsweise für den PKS-Service ist durch die Verwaltungsleitung festzulegen, die Zahlung per Rechnung ist sicherlich die einfachste Variante. Der Antrag ist erst bei der Abgabe an der entsprechenden Registrierungsstelle zu unterschreiben. Es wird eine Kopie des Personalausweises erstellt und an das Trustcenter geschickt.

Für das Attributzertifikat zur Selbstbeschränkung ist der in diesem Kapitel vorgeschlagene Text einzutragen. Die Zustellung kann per E-Mail erfolgen, da das Zertifikat mit dem öffentlichen Schlüssel aus dem Hauptzertifikat verschlüsselt wird.

Das Pseudonym hat einen Bezug zu einer zu vertretenden dritten Person. Deshalb ist laut Signaturgesetz §5 (3) eine Einwilligung einzuholen. Derzeit gibt es bei der Telesec nur ein vorgegebenes Verfahren bei Einholung eines Attributzertifikats zur Vertretung Dritter. Die Einwilligung ist sogar notariell zu bestätigen. Es wird eine Vereinfachung durch das Trustcenter angestrebt, bei der eine schriftliche Bestätigung ausreicht. Das Verfahren ist jedoch noch nicht genau definiert und muss vor der Beantragung geklärt werden.

	Abbildung 4.2 Telesec Chipkarte

Nach der Zusendung der Karte muss diese zunächst freigeschaltet werden. Das erfolgt über die Funktion „Karte freischalten“ der Anwendung PKS-Crypt, was zugleich auch eine Sicherheitsfunktion darstellt, da die Freischaltung nur einmal pro Karte erfolgen kann. Falls sie fehlschlägt, muss die Karte vorher manipuliert worden sein. Die Zertifikate können dann von der Karte in die Anwendung gelesen und auf Korrektheit geprüft werden.

Anschließend muss noch ein Formular über den Erhalt der Karte ausgefüllt und an die Telesec zurückgesendet werden. Erst danach wird das Zertifikat in das Zertifikatsverzeichnis aufgenommen und ist offiziell zur Nutzung freigegeben. Falls die zugesendete Karte eine Wiederausstellung für ein abgelaufenes Zertifikat sein sollte, wird das alte gesperrt.

Im Folgenden wird eine Dateisystemstruktur für die Ablage der Dokument-Dateien entworfen, um einen effizienten Zugriff im Rahmen aller Archivierungsaufgaben zu ermöglichen. Dabei ist insbesondere zu berücksichtigen, dass sich Teile des Dokuments im Rahmen des Publikationsprozesses ändern können. Dies ist z.B. der Fall, wenn

• zusätzliche Konvertierungen in weitere Dateiformate durchgeführt werden,
• Änderungen an Metadaten erfolgen,
• im Rahmen der Langzeitsicherung der Dokumente alte Dateiformate in neue konvertiert werden.

Alle erfolgten Änderungen sind zu archivieren und die Dateien zu sichern. Damit nicht bei jeder Archivierung die gesamten Dateien separat gehalten werden müssen, werden nur die Unterschiede innerhalb der Verzeichnisstruktur gespeichert. Es wird ein Algorithmus definiert, mit dem neue Dokumente erkannt, geänderte aktualisiert und Löschungen vorgenommen werden können. Das Löschen eines Teildokuments ist ein eher seltener Fall und könnte z.B. dann erfolgen, wenn gegen das Datenschutzgesetz verstoßen wurde.

Die Ordnerstruktur wird durch eine dreistufige Hierarchie abgebildet. Auf der ersten Ebene werden Ordner mit dem URN des Dokuments angelegt. Auf der zweiten Ebene folgen Ordner mit Zahlen beginnend mit der Ziffer 1. Dadurch ergibt sich eine Chronologie, in der Änderungen am Dokument gespeichert werden können. Auf der dritten Ebene schließlich werden Ordner angelegt, um die Dateien entsprechend ihrer Zugehörigkeit zu den bereits weiter oben festgelegten Dokumentgruppen zu speichern. Die Dateien werden dabei trotz ihrer Zugehörigkeit zu mehreren Gruppen nur einmal innerhalb der Ordnerstruktur gespeichert. Auf dieser Ebene werden folgende Verzeichnisse angelegt:

• ORIGINAL: Für die Originaldateien aus dem Textverarbeitungssystem des Autors, die Abstract-Dateien, die Keyword-Dateien.
• PDF: Die vom Autor generierte PDF-Datei.
• SGML: Die durch die Konvertierung erzeugten SGML-Dateien gemäß der DiML mit der Dateiendung .did .
• HTML: Durch Konvertierung aus den SGML-Dateien gewonnene HTML-Version des Dokuments.
• BINARY: Alle zusätzlichen Teile des Dokuments, wie z.B. Bilder, Videos, Audios oder Programme. Dabei werden durch die Konvertierung nach SGML/HTML erzeugte Dateien im Unterordner CONV und bereits vorhandene Dateien im Unterordner ORIG abgelegt.
• METADATA: Eine XML-Datei mit den Metadaten aus der bibliografischen Erfassung des Dokuments.
• ARCHIVEDATA: Hier wird die erzeugte Archiv-Sicherungsdatei (siehe nächster Abschnitt) sowie die Signatur- und Zeitstempeldatei gespeichert.

Der Ordner mit der Nummer 1 wird die Dateien enthalten, die im Original vom Autor eingereicht werden. Der Ordner 2 wird im allgemeinen zusätzlich die konvertierte SGML- bzw. HTML-Version sowie die Metadaten aufnehmen. Ab Ordner 3 werden in der Regel Änderungen am Dokument abgelegt.

Es ist nicht praktikabel und notwendig, jede für die Archivierung gemäß Abschnitt 4.4.2 relevante Datei einzeln zu signieren und zu zeitstempeln. Vielmehr ist es ausreichend, eine Metadatei (Archiv-Sicherungsdatei) zu erzeugen, die eindeutige Referenzen auf die zugrunde liegenden Dateien enthält. Die eindeutige Referenz wird durch Bildung eines Hash-Wertes mit einem im Abschnitt „Hash-Verfahren“ beschriebenen und vom BSI empfohlenen kryptografischen Algorithmus erstellt. Zusätzlich wird dieses verwendete Verfahren innerhalb der Archiv-Sicherungsdatei dokumentiert. Zusammen mit weiteren Informationen, die in diesem Abschnitt noch beschrieben werden, wird dann nur diese Datei signiert und mit einem Zeitstempel versehen. Dies stellt keine Verringerung der Sicherheit des Verfahrens dar, da bei der Signatur einer einzelnen Datei auch nur der Hash-Wert verwendet wird. Durch die schon beschriebenen kryptografischen Eigenschaften von Hash-Verfahren ist die praktische Eindeutigkeit des Hash-Wertes zu einem Originaldokument gewährleistet. Bei der Prüfung der Integrität und Authentizität des Gesamtdokuments oder auch nur von Teilen ist diese für die Archiv-Sicherungsdatei vorzunehmen und ein Vergleich zwischen dem in der Datei gespeicherten Hash-Wert und einem gerade aus dem vorliegenden und zu prüfenden Dokument errechneten Wert durchzuführen. Stimmen die beiden Werte überein und wurde die Prüfung für die ASD erfolgreich durchgeführt, gilt die Integrität und Authentizität genauso für die zu prüfende Datei.

Die Definition der Archiv-Sicherungsdatei leistet aber noch mehr als eine Zusammenfassung mehrerer inhaltlich zusammengehörender Dateien eines Dokuments und eine Verringerung des Signaturaufwands. Vielmehr wird durch entsprechende Zusatzinformationen auch die Bedeutung der angebrachten Signatur bzw. des Zeitstempels definiert. Während das einfache Signieren und Zeitstempeln einer Datei zunächst einmal nichts weiter bedeutet, als dass eine bestimmte Bitfolge spätestens zu diesem Zeitpunkt dem Signierer vorlag, können aus der Archiv-Sicherungsdatei noch folgende Informationen bezogen werden:

• Alle einzelnen und durch ihren Hash-Wert und Namen vertretenen Dateien wurden vom Signierer mit einem zum zusätzlich definierten MIME-Type passenden Viewer in einer bestimmten Systemumgebung betrachtet und somit auf korrekte Darstellung und grobe Fehler geprüft. Selbstverständlich kann hierbei weder inhaltliche Richtigkeit garantiert werden noch jeder mögliche Darstellungsfehler ausgeschlossen werden. Geprüft werden kann aber beispielsweise (z.T. sicherlich auch nur stichprobenartig), ob die Seiten-Identität zwischen PDF- und HTML-Dokument gesichert ist oder ob grobe Darstellungsfehler vorhanden sind, die die Bedeutung des Textes beeinflussen können. Damit wird im Wesentlichen also das bereits beschriebene Präsentationsproblem adressiert. Es ist leicht zu ersehen, dass hier nur ansatzweise das in [Pordesch01] vorgeschlagene Verfahren der „Standardpräsentation“ umgesetzt wurde und die Vertrauenswürdigkeit von der Sorgfalt des Bearbeiters abhängt. Jedoch sichert es zumindest die korrekte Anzeigbarkeit unter den definierten Systemparametern und weiteren inhaltlichen Kriterien, die u.U. auf eine manuelle Kontrolle des Autors nach Konvertierung erweitert werden kann. Dies erscheint insbesondere unter dem Aspekt sinnvoll, dass naturgemäß Unterschiede im Layout zwischen der PDF-Version und der nach HTML konvertierten Version vorliegen.
  Die jeweils für den MIME-Type gültigen Systemparameter wie Hardware und Software werden in einer separaten Dokumentation erfasst. So kann unter Benutzung des Zeitstempels der ASD jederzeit geprüft werden, womit die relevante Datei auf korrekte Darstellung geprüft wurde. Vorgaben zum Inhalt des Prüfverfahrens sind ebenfalls zu dokumentieren.
• Die einzelnen Dateien innerhalb der Archiv-Sicherungsdatei können Dateigruppen zugeordnet werden, um die Zugehörigkeit zu den jeweiligen Präsentationsformen darzustellen. Derzeit verwendete Gruppen sind z.B. 'PDF','SGML','HTML','Original','Metadaten'. Dabei kann eine Datei mehreren Gruppen zugeordnet werden, um Doppelerfassungen zu vermeiden, z.B. Bilder, die sowohl Bestandteil der SGML- als auch der HMTL-Version sind. Durch dieses Verfahren ist es sehr einfach möglich festzustellen, welche Dateien bei der Veröffentlichung der jeweiligen Präsentationsform genutzt werden, d.h. es ist möglich, jeweils sowohl für eine Gruppe als auch für das Gesamtdokument eine Vollständigkeitsinformation abzuleiten. Die Annahme und Konvertierung einer Dissertation verläuft üblicherweise in mehreren Stufen, so dass beim Hinzukommen von Dateien diese in einem weiteren Archivierungspaket einfach ergänzt werden oder die Zugehörigkeit zu einer Dateigruppe erweitert wird. Zum Beispiel gehört ein Softwareprogramm, das zu einer Arbeit abgeliefert wird, sicherlich zu allen vier Gruppen, während die separate Metadaten-Datei nur in die Gruppe 'Metadaten' einsortiert und derzeit in keiner anderen Publikationsform veröffentlicht wird.
• Zur Identifikation und Einordnung der Archiv-Sicherungsdatei werden zwei Merkmale genutzt. Zum einen wird schon frühzeitig für das Gesamtdokument ein Uniform Resource Name (URN) genutzt, der eine serverunabhängige Identifikation und Auffindbarkeit der elektronischen Version ermöglichen soll. Dieser wird in Form einer National Bibliographic Number (NBN) vergeben. Das Resolving der URN auf eine konkrete URL erfolgt auf einem Server der Deutschen Bibliothek. Informationen zur Verwendung innerhalb des CMS sind in [Dobratz03] beschrieben. Grundlagen zur Anwendung von URNs findet man ebenfalls auf dem Server der Deutschen Bibliothek [DDB03a]. Der URN bildet somit die Identifkation für das Gesamtdokument und eine Klammer um die einzelnen Dateien in der Archiv-Sicherungsdatei.
  Des Weiteren ist es notwendig, eine Chronologie zwischen mehreren ASDs herstellen zu können. ASDs ändern sich immer dann, wenn Dateien hinzukommen, wie z.B. bei einer zeitlich entkoppelten Konvertierung von PDF und HTML oder auch bei der Änderung von Dateien, z.B. von Metadaten-Einträgen. Die Reihenfolge wird durch eine Zahl beginnend mit 1 festgelegt, die mit dem Vorhandensein jeder neuen Version erhöht wird. Weiterhin wird das Erstellungsdatum integriert. Die letzte Archiv-Sicherungsdatei kann dann leicht als aktuellste Datei oder aus den Logeinträgen des Workflow-Systems bestimmt werden. Die Zusammengehörigkeit von verschiedenen ASDs wird durch den URN definiert. Eine nachträgliche Änderung des URN zu einem Dokument ist in diesem Rahmen derzeit nicht vorgesehen.
  Zusätzlich enthält eine ASD immer die Referenzen auf die vorhergehende ASD sowie die Signatur und den Zeitstempel. Damit wird eine Verkettung der ASDs und eine kontinuierliche kryptografische Sicherung der vorhergehenden Dateien erzielt, da diese bei der Neuerstellung eventuell mit neuen Algorithmen oder größeren Schlüssellängen referenziert werden und dadurch trotz Verlust der Sicherheitseignung ein Nachweis von Authentizität und Integrität vorheriger ASDs möglich ist.
• Um die Bedeutung der Signatur unter einer Archiv-Sicherungsdatei zu definieren, enthält diese einen Disclaimer, der Angaben zu ihrer Bedeutung enthält:

Dieses Dokument ist eine Archiv-Sicherungsdatei für elektronische Publikationen der HU Berlin.

Sie enthält Referenzen auf alle im Archiv aufbewahrten Dateien zu diesem Dokument.

Die Erstellung dieser Datei erfolgte gemäß den Richtlinien für die Archivierung und den Dokumentenserver der HU Berlin.

Die Hash-Werte der Dateien wurden innerhalb einer besonders gesicherten Systemumgebung mit einem vertrauenswürdigen Programm erstellt. Alle Dateien wurden mit einem zum MIME-Type passenden Viewer geprüft.

Für die Archiv-Sicherungsdatei wurde eine qualifizierte Signatur mit Anbieterakkreditierung der „Arbeitsgruppe Elektronisches Publizieren“ sowie ein Zeitstempel erzeugt.

Fragen zum Inhalt dieses Dokuments werden unter der angegebenen Kontaktadresse beantwortet.

Die technische Realisierung der Archiv-Sicherungsdatei erfolgt in Form einer XML-Datei mit einem im weiteren beschriebenen Schema. Dadurch kann die ASD mit einem beliebigen Text-Viewer betrachtet und der Inhalt intuitiv erfasst werden. Obwohl eine solche Datei im Wesentlichen auch manuell erstellt werden kann, ist die automatische Erzeugung im Rahmen des Workflows für elektronische Publikationen dringend zu empfehlen, da insbesondere die Konvertierung nach SGML bzw. HTML eine ganze Reihe Einzeldateien erzeugt.

Der folgende Abschnitt beschreibt, wie die einzelnen Tags bei Erstellung der Archiv-Sicherungsdatei zu füllen sind und wie Änderungen an Dokumenten verarbeitet werden. Es wird dazu das XML-Schema aus Anhang B verwendet.

Die Angaben in den Tags <documentType>, <title>, <author> dienen nur der Verbesserung der Lesbarkeit und Erleichterung der Zuordnung der Archiv-Sicherungsdatei. Für die Zwecke der Archivierung ist die Angabe des URN sowie die Referenzen auf die Dateien ausreichend.

Bei Änderungen an der Publikation wird ein weiterer Ordner mit der festgelegen Struktur (und leeren Inhalten) angelegt, wobei der Ordner als Namen den letzten Wert von <counter>+1 erhält. Dann werden alle geänderten oder neuen Dateien in die entsprechenden Ordner kopiert. Anschließend wird eine neue Archiv-Sicherungsdatei urn_<counter>+1.xml erstellt, die die gesamte Arbeit vollständig erfasst. Dabei wird wie folgt vorgegangen:

1. Es wird ein Index aller Dateien der letzten Archiv-Sicherungsdatei urn_<counter>.xml angelegt.
2. Für jede Datei, die sich in der neuen Ordnerstruktur <counter>+1/ befindet, wird geprüft, ob sie im Index vorhanden ist. Wenn ja, stellt dies eine Änderung der Datei dar. In der ASD wird ein Eintrag für diese Datei mit einer Referenz auf den Ordner
   <coun ter>+1/ erzeugt.
3. Für jede andere Datei im Index wird geprüft, ob sie sich noch an der angegebenen Stelle befindet. Wenn ja, dann hat sich an der Datei nichts geändert und sie ist weiterhin vorhanden. Es wird eine Referenz auf den Ordner erzeugt, diese ist identisch mit der in der letzten ASD erzeugten. Falls die Datei nicht mehr gefunden wird, ist der seltene Fall einer Löschung eingetreten. Es wird keine Referenz in der neuen ASD erzeugt, es wird jedoch zwingend ein Kommentar eingefügt, der den Grund für die Löschung enthält.
4. Schließlich werden für alle Dateien, die sich in der Ordnerstruktur <counter>+1/ befinden und nicht in der aktuellen ASD vorhanden sind, neue Referenzeinträge auf die neue Struktur erzeugt.

Im Regelfall werden zunächst zwei oder drei Archiv-Sicherungsdateien erzeugt, die erste bei Abgabe des Dokuments durch den Autor, die weiteren bei Konvertierung nach PDF und SGML/HTML oder bei Hinzufügung der bibliothekarisch erzeugten Metadaten. In größeren zeitlichen Abständen wird gemäß der Verpflichtung zur Langzeitarchivierung eine Konvertierung bestimmter Dateien in andere Formate erfolgen.

Aufgrund dessen, dass nur die Änderungen abgelegt werden, entstehen in der ASD zwar Einträge mit Referenzen auf unterschiedliche Ordnerstrukturen unterhalb des Hauptverzeichnisses des Dokuments, allerdings wird dadurch weitestgehend eine Redundanz von Dateien vermieden. Bei den erzeugten Datenmengen und der Anzahl der publizierten Dokumente wird so eine erhebliche Speicherplatzmenge eingespart. Es ergibt sich von selbst, dass jeweils der gesamte Dokumentenordner durch ein Backup gesichert werden muss, da sich zu prüfende Dateien in allen Unterverzeichnissen befinden können.

Die Löschung von Dateien wird nur im Einzelfall vorkommen, wenn es sich im Nachhinein aus datenschutzrechtlichen oder urheberrechtlichen Aspekten ergibt oder mit dem Inhalt gegen andere Gesetze oder Regelungen verstoßen wird. Möglich wäre z.B., dass der Autor Bilder in seiner Arbeit verwendet hat, die Rechte anderer verletzen. Ältere Archiv-Sicherungsdateien und die zugeordneten Zeitstempel und Signaturen, die sich auf einen Dokumentenstatus vor der Löschung der Datei beziehen, werden trotzdem nicht ungültig, da nur zu bestimmten Referenzeinträgen in der Archivierungsstruktur keine Datei mehr gefunden werden kann. Ein Blick in eine der nachfolgenden ASD enthält dann im Kommentarfeld auch den Grund für die Löschung.

Dieser Abschnitt beschreibt anhand einer real existierenden Dissertation den Ablauf für die Erstellung der Archiv-Sicherungsdateien sowie das Vorgehen bei Änderung, Neuerfassung und Löschung von Dateien. Es werden die zu erzeugenden Ordnerstrukturen und die wesentlichen Teile der jeweils dazu generierten ASDs dargestellt.

Das Beispiel umfasst die Dissertation von Frank Mertens aus dem Jahre 2000 an der Charité. Folgendes Szenario wird abgehandelt:

1. Abgabe der Originaldateien der Dissertation, der PDF-Version und der Abstract-und Keyword-Dateien.
2. Konvertierung der Arbeit nach SGML und HTML. Hinzufügen der bibliothekarischen Metadaten.
3. Löschung des hinzugefügten Programms aus urheberrechtlichen Gründen. Aktualisierung der Metadaten-Datei.

Da bisher noch keine reguläre URN-Vergabe erfolgt, wird ein fiktiver URN gewählt: 089-1234567890.

Der Ordner mit dem URN und der erste Unterordner werden angelegt:

	Abbildung 4.3 Ordnerstruktur Archiv

Anschließend werden die für Schritt 1 genannten Dateien in diese Struktur kopiert. Aus Gründen der Darstellbarkeit wurden nicht alle der zur Arbeit gehörenden Bilder berücksichtigt.

	Abbildung 4.4 Abgabedateien des Autors

An dieser Stelle wird die erste Archiv-Sicherungsdatei erzeugt, mit der belegt werden kann, wann der Autor die Arbeit abgegeben hat.

In Schritt 2 erfolgt die Konvertierung der Dissertation nach SGML und HTML. Außerdem wird aus dem Bibliothekssystem ein Extrakt der erfassten Metadaten in Form einer XML-Datei bereitgestellt. Es ergibt sich (unter Einbeziehung der ersten ASD mit ihrer Signatur und dem Zeitstempel) folgende Dateistruktur:

	Abbildung 4.5 Konvertierung SGML/HTML

Da in diesem Schritt nur Dateien hinzugekommen sind, besteht die neue Archiv-Sicherungsdatei aus den Referenzen auf die Dateien aus dem Ordner 1/ sowie aus dem Ordner 2/.

Im dritten und letzten Schritt wird das Programm virtarj.exe aus dem Ordner 1/binaries/orig gelöscht, was in der neuen Archiv-Sicherungsdatei im Kommentar vermerkt wird. Des Weiteren wird die Metadaten-Datei erneuert. Die neue Dateistruktur sieht wie folgt aus:

	Abbildung 4.6 Änderung Metadaten

Aus Platzgründen werden hier nur die Änderungen an der ASD aufgeführt, die sich im Gegensatz zur Version 2 geändert haben:

Alle Funktionen, die im Zusammenhang mit der Archivierung der Dokumente stehen, werden auf einem speziell zu sichernden System, dem Archivserver ausgeführt. Er erfüllt im Einzelnen folgende Aufgaben:

• Speicherung aller auf dem Dokumentenserver publizierten Dokumente in der beschriebenen Ordnerstruktur
• Erzeugung der Archiv-Sicherungsdateien
• Erstellung der Signaturen und Zeitstempel für die ASDs
• Initiierung der eigentlichen Archivierung auf dem zentralen Backup-System der HU

Als Ansatz für die Konfiguration des Archiv-Server kann das Dokument „Einheitliche Spezifizierung der Einsatzbedingungen für Signaturanwendungskomponenten“ der RegTP [RegTP02a] dienen. Dort werden Anforderungen an die Sicherheit von Signaturanwendungskomponenten sowie die Einsatzumgebungen formuliert. Es werden drei Umgebungen dargestellt:

• Ungeschützter Einsatzbereich mit ungesicherter Anbindung an das Internet und ohne signaturspezifische Sicherheitsvorkehrungen in der Einsatzumgebung (gegen Bedrohungen über Internet/Intranet und manuellen Zugriff Unbefugter/Datenaustausch per Datenträger).
• Geschützter Einsatzbereich mit Sicherheitsvorkehrungen, die eine hohe Sicherheit gegenüber potentiellen Angriffen über das Internet, ein angeschlossenes Intranet, einen manuellen Zugriff Unbefugter und Datenaustausch per Datenträger gewährleisten.
• Isolierter Einsatzbereich mit folgendem Schutz gegen potentielle Bedrohungen: Es erfolgt zu keinem Zeitpunkt eine Anbindung an ein Kommunikationsnetz, und in der Einsatzumgebung sind Sicherheitsvorkehrungen vorhanden, die potentielle Angriffe über manuellen Zugriff Unbefugter/Datenaustausch per Datenträger mit hoher Sicherheit abwehren.

Dabei werden die erste und die letzte Lösung sinnvollerweise als Sonderlösung und der geschützte Einsatzbereich als Regellösung betrachtet. Für den Archivserver ergibt sich schon automatisch, dass eine zumindest temporäre Anbindung an das Intranet (Übertragung der Dokumente von den Mitarbeiter-PCs auf den Archivserver, Zugriff auf das zentrale Backup-System) sowie das Internet (Herstellen der Verbindung zum Trustcenter für Zertifikatsprüfung und Zeitstempeldienst) erforderlich ist. Das Dokument schlägt weiterhin allgemeine Maßnahmen gegen die einzelnen Bedrohungsszenarien vor:

Es werden folgende Maßnahmen zur Erfüllung der Sicherheitsanforderungen vorgeschlagen:

• Der Archivserver wird im Recherraum des CMS aufgestellt. Damit wird ein hoher Zutrittsschutz erreicht.
• Es wird ein W2K-System mit allen derzeit empfohlenen Service Packs und Hotfixes installiert. Die Installationsdateien sind aus einer vertrauenswürdigen Quelle zu beziehen, z.B. von den Original-CDs aus dem MS Select-Vertrag.
• Der Archivserver wird nur dann eingeschaltet, wenn damit konkret gearbeitet wird. Wenn der Server ausgeschaltet ist, ist das Netzwerk-Kabel zu ziehen, um z.B. Angriffen über Wake-on-LAN zu entgehen.
• Zur weiteren Erhöhung des Zugangsschutzes sollte ein Festplattenverschlüsselungstool eingesetzt werden, wie z.B. Utimaco Safeguard. Die Zugangsdaten werden dabei sicher hinterlegt und ein unberechtigter Zugriff auf den Server deutlich erschwert.
• Der interne Zugriff auf die zu archivierenden Dateien soll über ein Transferlaufwerk eines dedizierten Fileservers erfolgen. Ein direkter Zugriff vom Archivserver auf Mitarbeiter-Rechner ist nicht zulässig.
• Zur Absicherung des Rechners gegenüber dem Internet und Intranet ist eine Firewall zu installieren, die nur den absolut notwendigen Datenverkehr zulässt. Die Verbindung zum Internet ist auf die benötigten Server des Trustcenters zu beschränken. Die Verbindung ins Intranet darf nur zum Transferserver und zum zentralen Backup-System zugelassen werden.
• Es ist ein vertrauenswürdiger Virenscanner zu installieren und regelmäßig mit den aktuellen Virensignaturen zu aktualisieren.
• Es ist ein nach den Anforderungen von Signaturgesetz bzw. Signaturverordnung geprüfter und bestätigter Chipkartenleser einzusetzen. Die bestätigten Produkte können auf der Website der RegTP abgerufen werden [RegTP03a].
• Es ist eine bestätigte und geprüfte Signaturanwendungskomponente einzusetzen. Derzeit ist problematisch, dass lediglich die Funktionsbibliothek, auf der PKS-Crypt basiert, eine Bestätigung besitzt, aber nicht das Produkt selbst. Es kann nur auf eine Herstellererklärung auf der Website von Telesec verwiesen werden. Dies beeinträchtigt nicht die ordnungsgemäße Erstellung und Prüfung von Signaturen, jedoch wäre eine Klärung des Status von PKS-Crypt hilfreich, da damit eine amtliche Bestätigung für viele der in [RegTP02a] formulierten Anforderungen gegeben wird und in der Bestätigung die genauen Einsatzbedingungen formuliert werden.
• Wartungsarbeiten und Reparaturen am Archivserver sind durch das technische Personal nur nach Absprache mit einem für den Archivserver berechtigten Mitarbeiter durchzuführen.

Die Konfiguration des Archivservers ist wie beschrieben zu dokumentieren.

Nach der Generierung der Archiv-Sicherungsdateien werden diese signiert. Über der Signatur wird ein Zeitstempel angebracht, um den Signaturzeitpunkt authentisch festzuhalten. Der folgende Abschnitt beschreibt die Nutzung von PKS-Crypt in der Version 1.3 zur Erstellung der Signaturen und Zeitstempel.

Vor dem Beginn des Vorgangs ist die Internetverbindung zu aktivieren, um den Zeitstempeldienst kontaktieren zu können. Dabei ist auf korrektes Funktionieren der bereits erwähnten Firewall-Funktionen zu achten.

Da die Anwendung sich in den Windows-Explorer integriert, kann auf dem Archivserver direkt in das Verzeichnis mit der ASD gewechselt werden. Mit der rechten Maustaste wird zunächst die Funktion „Signatur erstellen“ aufgerufen, da eine Kombination Signatur/Zeitstempel derzeit nicht unterstützt wird. Nach Eingabe der PIN zur Freischaltung der Chipkarte wird zunächst das Attributzertifikat für die Selbstbeschränkung ausgewählt.

Das Attributzertifikat wird unterhalb des Programmverzeichnisses von PKS-Crypt im Verzeichnis cert_server/data gespeichert. Anschließend erscheint das Fenster mit Informationen zur zu erstellenden Signatur:

Im Ergebnis entsteht eine Datei mit dem gleichen Dateinamen wie die Originaldatei ergänzt um die Endung .sig. Diese wird jetzt mit dem Zeitstempel versehen. Dazu wird die Funktion „Zeitstempel erzeugen“ im Kontextmenü der gerade erstellten Signaturdatei aufgerufen. Es erscheint insgesamt dreimal das folgende Bestätigungsfenster:

Damit wird das Absenden der Zeitstempel-Anfrage an den Server sowie der Erhalt des Zeitstempels bestätigt. Es wird geprüft, ob der Nutzer berechtigt ist, den Zeitstempeldienst in Anspruch zu nehmen. Es erfolgt keine weitere Meldung, sondern es wird eine Datei mit der Endung .tsm abgelegt, die den Zeitstempel enthält.

Die Prüfung erfolgt analog mit dem Aufruf der Funktion „Zeitstempel prüfen“ im Kontextmenü der tsm-Datei. Anschließend ist als Ursprungsdatei die Signaturdatei auszuwählen. Bei erfolgreicher Prüfung erscheint das folgende Fenster, das bestätigt, dass der Zeitstempel zu der angegebenen Datei erzeugt wurde und die Signatur des Zeitstempeldienstes korrekt ist.

Die Prüfung der Signaturdatei erfolgt durch Aufruf der Funktion „Signatur prüfen“ im Kontextmenü. Es erscheint ein Auswahlfenster mit mehreren Optionen zur Prüfung des Signaturzertifikats.

Grundsätzlich sollte immer online im Trustcenter geprüft werden, da nur so sichergestellt ist, dass Sperrlisteneinträge korrekt berücksichtigt werden. Es müssen zwei Signatur-Bestätigungen an das Trustcenter gesendet werden. Da die Signaturdatei in der derzeitigen Version von PKS-Crypt auch die Originaldatei enthält, wird diese standardmäßig im aktuellen Verzeichnis abgelegt. Falls sie dort schon vorhanden sein sollte, erscheint eine Sicherheitsabfrage. Schließlich erscheint das Fenster mit der Signaturprüfung und der Anzeige, ob die Signatur selbst und die zugrunde liegende Zertifikatskette gültig sind.

Im Rahmen der Publikation von Dissertationen und anderen Arbeiten wurde bereits ein komplexer Geschäftsgang von der Abgabe der Arbeit durch den Autor über die Konvertierung in verschiedene Zielformate bis zur Veröffentlichung auf dem Dokumentenserver der HU definiert. Im Folgenden werden Geschäftsvorfälle aufgeführt, die im Zusammenhang mit der Authentizitäts- und Integritätssicherung der Dokumente stehen. Es werden die durchzuführenden Schritte und die Einordnung in den übergeordneten Geschäftsgang betrachtet.

Die Geschäftsvorfälle, die im Rahmen der Langzeitarchivierung relevant sind – der Verlust der Sicherheitseignung der eingesetzten Signatur- bzw. Hash-Algorithmen – werden hier nicht detailliert betrachtet. Die derzeitig eingesetzten Signatur- und Hash-Algorithmen sind nach Einschätzung der RegTP auch noch Ende 2008 gültig [Regtp01]. Es ist also sehr unwahrscheinlich, dass in den nächsten Jahren eine Neusignatur von in diesem Projekt erzeugten Dateien notwendig sein wird. Es werden sich zukünftig Standards und Produkte für die Verarbeitung von elektronischen Signaturen entwickeln, die auch die Problematik der Langzeitarchivierung abdecken. Diese Entwicklungen sind zu verfolgen und das Konzept ggf. anzupassen. Es sei jedoch angemerkt, dass mit dem hier vorgestellten Konzept einer Archiv-Sicherungsdatei schon gute Voraussetzungen für eine notwendige Erneuerung von Signaturen geschaffen worden sind. So muss im Falle des Unsicherwerdens des Signaturalgorithmus, nur die ASD unter Einschluss alter Signaturen signiert werden. Ein Zugriff auf die archivierten Dateien ist nicht erforderlich, so dass diese Neusignatur auch einen externen Diensleister ausgelagert werden könnte. Bei Unsicherwerden des Hash-Algorithmus müssen die Dateien mit dem neuen Algorithmus gehasht und dann neu signiert werden. Da dieses Verfahren relativ aufwendig ist, könnte z.B. jede Datei mit einem zweiten Hash-Algorithmus gehasht und dieser Wert zusätzlich in die ASD eingetragen werden. Dadurch wäre eine Neuerstellung der ASD nur dann erforderlich, wenn diese zwei Algorithmen gleichzeitig unsicher werden, was sehr unwahrscheinlich sein dürfte.

Die Erstellung von Signaturen und Zeitstempeln erfolgt immer im Zusammenhang mit der Erstellung einer Archiv-Sicherungsdatei. Die erstmalige Erstellung sollte unmittelbar nach Abgabe der Originaldateien des Autors durchgeführt werden, um einen Nachweis für die elektronische Abgabe zu besitzen. Weitere ASD werden nach durchgeführten Konvertierungen in die Zielformate, bei Verfügbarkeit und Änderung von Metadaten sowie im Rahmen der Langzeitarchivierung bei Konvertierungen in neue verfügbare Formate erstellt.

Zunächst sind die zu archivierenden Dateien auf das Transferlaufwerk zu kopieren, damit vom Archivserver darauf zugegriffen werden kann. Der Archivserver wird dann gestartet. Es ist auf eine korrekte Funktion der Sicherungsmaßnahmen, insbesondere der installierten Firewall-Software zu achten. Die Dateien werden vom Transferlaufwerk in die Archivierungsstruktur übertragen. Falls noch keine vorhanden ist, kann diese z.B. aus einem Template erzeugt werden, das nur die oben beschriebenen Ordner enthält. Dazu ist natürlich die vorherige Vergabe eines URN für das Dokument notwendig. Alle zu archivierenden Dateien sind gemäß Verfahrensanweisung mit dem dokumentierten Viewer zu betrachten, falls dies nicht in geeigneter Weise schon auf dem Mitarbeiter-PC durchgeführt wurde.

Anschließend ist die Archiv-Sicherungsdatei zu erzeugen. Diese Aufgabe ist gut automatisierbar und kann über ein Skript erfolgen, das die Dateien einsammelt, einen MIME-Type vorschlägt, den Hash-Wert berechnet und die festen Bestandteile der ASD einfügt. Die variablen Angaben zu Autor, Titel, Grund der Erstellung usw. können leicht über ein Formular abgefragt werden.

Die automatisch generierte ASD sollte noch einmal manuell auf Richtigkeit geprüft werden. Dann wird das Programm PKS-Crypt gestartet und die Signatur für die ASD erstellt. Dabei ist auf die Einbeziehung des Attributzertifikats zu achten. Danach kann der Zeitstempel für die Signaturdatei beim ZDA angefordert werden.

Somit ist der Archivierungsvorgang für dieses Dokument abgeschlossen und es können bei Bedarf weitere bearbeitet werden. Bevor der Archivserver dann wieder abgeschaltet werden kann, muss eine Sicherung der Daten auf das zentrale Backup-System initiiert werden.

Zur kompletten Prüfung einer ASD ist der Zugriff auf die Signaturen und Zeitstempel, die ASD selbst sowie die referenzierten Archiv-Dateien notwendig. Diese sind bei Bedarf aus dem zentralen Backup-System zu beziehen.

Die Prüfung erfolgt in drei Stufen:

1. Prüfung der Gültigkeit des Zeitstempels
   Diese erfolgt mit PKS-Crypt. Damit kann bei Erfolg nachgewiesen werden, dass die Signatur über der ASD spätestens zum angegebenen Zeitpunkt erzeugt worden ist.
2. Prüfung der Gültigkeit der Signatur
   Hier kommt ebenfalls PKS-Crypt zum Einsatz. Da die Anwendung derzeit nicht in der Lage ist, auf den Signaturzeitpunkt zu prüfen, ist bei abgelaufener Gültigkeitsdauer des zugrunde liegenden Zertifikats kein positives Ergebnis zu erwarten. Alternativ kann die mathematische Prüfung der Signatur durchgeführt und zur Zertifikatsprüfung eine zeitgestempelte OCSP-Antwort herangezogen werden.
3. Prüfung der Hash-Werte der in der ASD referenzierten Dateien
   Es werden die Hash-Werte über die Archiv-Dateien gebildet und mit den Werten in der ASD verglichen. Wenn jeder Wert übereinstimmt und alle Dateien vorhanden sind, ist die Prüfung erfolgreich.

Die Gültigkeit von Zertifikaten ist nach den Vorgaben der Signaturverordnung auf maximal 5 Jahre beschränkt und muss innerhalb des Gültigkeitszeitraums der zugrunde liegenden kryptografischen Algorithmen liegen. Beim Anbieter Telesec ist die Gültigkeit derzeit auf 3 Jahre begrenzt. Vor dem regulären Ablauf wird die neue Karte durch den Anbieter automatisch neu verschickt. Nach der Freischaltung ist auf einem Formular der Erhalt schriftlich gegenüber Telesec zu bestätigen. Erst danach wird das Zertifikat in das Verzeichnis aufgenommen und darf genutzt werden.

Die Ausgabe der neuen Chipkarte ist wie unter dem Punkt Dokumentation beschrieben festzuhalten. Die alte Karte wird zurückgegeben und unbrauchbar gemacht. Die Gültigkeit der mit dem alten Signaturschlüssels erzeugten Signaturen bleibt hiervon unberührt.

Durch die Speicherung des Signaturschlüssels in der Hardware der Chipkarte wird ein Auslesen des Schlüssels wirksam verhindert. Signaturoperationen können nur nach Eingabe der PIN auf der Karte selbst durchgeführt werden. Eine Kompromittierung durch direkten Zugriff auf den Schlüssel ist also sehr unwahrscheinlich. Eine Kompromittierung tritt jedoch auch dann ein, wenn die PIN Unbefugten bekannt geworden ist und nicht ausgeschlossen werden kann, dass diese auch Zugriff auf die Chipkarte erlangt haben. In diesen Fällen ist eine Sperrung des Zertifikats vorzunehmen. Die Sperrung kann durch den Mitarbeiter selbst oder auch die Organisation selbst erfolgen. Sie kann durch eine signierte Sperranforderung an den ZDA, telefonisch unter Angabe des Telepassworts oder auch schriftlich erfolgen. Das Zertifikat wird auf die Sperrliste des Anbieters gesetzt. Nachträglich erstellte Signaturen sind nicht mehr gültig, zuvor erstellte Signaturen bleiben weiterhin gültig. Die Chipkarte ist unbrauchbar zu machen (z.B. durch Shreddern oder Ausstanzen des Chips), um zu verhindern, dass weiterhin mit ihr signiert wird. Die Sperrung und der Grund sind zu dokumentieren. Falls der betroffene Mitarbeiter weiterhin berechtigt ist, Signaturen zu erzeugen, ist eine neue Karte beim ZDA zu beantragen.

Eine Sperrung des Zertifikats durch die Organisation ist auch dann vorzunehmen, wenn der Verdacht besteht, dass der Mitarbeiter die Chipkarte missbräuchlich verwendet hat.

Entsprechend der Verfahrensregelung sind die von den Mitarbeitern gewählten PINs sicher bei der Verwaltungsleitung zu hinterlegen, um nicht jedesmal neue Karten ausstellen zu müssen, nur wenn eine PIN vergessen wurde. Insofern wird diesem Fall wirksam vorgebeugt. Falls aus irgendwelchen Gründen die PIN nicht korrekt hinterlegt wurde, ist die Chipkarte entsprechend unbrauchbar zu machen. Eine Sperrung des Zertifikats ist nicht notwendig, da keine Kompromittierung vorliegt.

Falls ein Mitarbeiter die Organisation verlässt, ist die Chipkarte durch ihn an die Verwaltungsleitung zurückzugeben, die sie unbrauchbar macht. Der PIN-Brief ist ebenfalls zu vernichten. Eine Sperrung des Zertifikats ist nicht notwendig, da keine Kompromittierung vorliegt.

Das Signaturgesetz regelt im §13 das Verfahren bei Einstellung der Tätigkeit eines Zertifizierungsdiensteanbieters. Im Falle eines akkreditierten Anbieters gilt zusätzlich §15 (6). Danach ist die Einstellung der Tätigkeit der zuständigen Behörde anzuzeigen; die Signaturschlüsselinhaber sind zu informieren. Falls kein anderer akkreditierter Anbieter der Übernahme der Verträge zustimmt, ist dafür die zuständige Behörde verantwortlich, ebenso wie für die Übernahme der Dokumentation gemäß §10 (1).

Rein rechtlich ist also die korrekte Abwicklung der Verträge und damit die korrekte Signaturerstellung weiterhin gewährleistet. Der konkrete Fall ist jedoch erst einmal eingetreten, und zwar als die Deutsche Post im Jahre 2002 die Einstellung ihres Dienstes Signtrust bei der RegTP bekannt gab, ohne jedoch einen genauen Termin zu nennen. Die Anzeige wurde wenig später wieder zurückgezogen, wahrscheinlich aufgrund von möglichen Schadenersatzklagen bereits existierender Kunden, wie z.B. der Medizon AG und von Bundesnotarkammern. Die Rücknahme der Einstellungsanzeige erfolgte auch vor der Übernahme der Zertifikate und der Dokumentation durch einen anderen Dienstleister, so dass bisher keine praktischen Erfahrungen vorliegen. Falls ein ZDA seinen Betrieb einstellt, können die bisherigen Chipkarten weiter genutzt werden. Der neue Zertifizierungsdiensteanbieter bzw. die RegTP hat die Kunden über Änderungen, wie z.B. die Ausgabe neuer Chipkarten, die Verfügbarkeit neuer Signaturanwendungskomponenten, die Änderung von Serveradressen usw., zu informieren. Es kann also nur empfohlen werden, aufmerksam die Veröffentlichungen in Bezug auf die Tätigkeitseinstellung zu verfolgen und in Abhängigkeit davon, die Entscheidung für einen Wechsel zu einem anderen Anbieter oder den Verbleib unter den geänderten Rahmenbedingungen zu treffen.

Wichtig ist, in jedem Falle die langfristige Prüfbarkeit der ausgestellten Signaturen sicherzustellen. Dazu ist ggf. auch die genutzte Software weiterhin vorzuhalten. Im Zuge der Standardisierung der Dienste und Formate mit ISIS-MTT sollte jedoch auch die Prüfung mit anderen Produkten möglich sein. Auch wenn das Zertifikatsverzeichnis von einem neuen Anbieter übernommen werden muss, sollte rechtzeitig für alle existierenden Zertifikate eine zeitgestempelte OCSP-Anfrage eingeholt und archiviert werden.

Der bisherige Einsatz von elektronischen Signaturen und Zeitstempeln für die Dokumentensicherung unterscheidet sich von dem hier vorgeschlagenen Verfahren. Dennoch ist es wichtig, die bereits erstellten Signaturen auch weiterhin verfügbar zu halten und zu archivieren.

Auf dem derzeitigen Archivserver werden die Original-Dateien sowie die konvertierten Versionen aufbewahrt. Alle Originaldateien befinden sich in einem Ordner, der nach folgender Konvention bezeichnet ist: Nachname-Vorname-Original. Die PDF-, SGML- und HTML-Version befindet sich in einem Ordner mit der Bezeichnung „Nachname-Vorname-Archiv.“ Wenn die Konvertierungen vorliegen und alle Signaturen und Zeitstempel erzeugt wurden, befinden sich dort jeweils ein ZIP-Archiv mit allen Dateien der jeweiligen Version, eine .sig-Datei mit der elektronischen Signatur des ZIP-Archivs sowie eine .tsm-Datei mit dem Zeitstempel über der Signaturdatei. Für einige Dokumente wurden keine Signaturen erzeugt. Diese könnten im Rahmen dieser Migrationsstrategie nachträglich erzeugt werden.

	Abbildung 4.7 Alte Archivstruktur

Da die durch PKS-Crypt erzeugten Signaturdateien auch die Originaldatei selbst enthalten, wurde teilweise aus Gründen der Platzersparnis die Originaldatei von den Signaturdateien getrennt. Dabei entstanden drei Dateien: ein Signatur-Header, die Originaldatei sowie ein Signatur-Footer. Es wurden dann nur die vergleichsweise kleinen Signaturteile archiviert. Vor einer Prüfung der Signatur werden die drei Dateien einfach wieder zusammengesetzt. Es muss getestet werden, ob eine neue Version von PKS-Crypt in der Lage ist, sofort getrennte Signaturdateien zu erzeugen.

Eine Variante für die Übernahme der alten Signaturen besteht darin, alle Dateien in die neue Ordnerstruktur zu überführen, anschließend die XML-Struktur zu erweitern, um auch Dateien vom Typ Signatur und ZIP-Archiv aufnehmen zu können, und danach neue Archiv-Sicherungsdateien zu generieren, für die neue Signaturen und Zeitstempel erzeugt werden. Diese Lösung ist sehr aufwändig, da die Überführung in die neue Struktur nur teilweise automatisch vorgenommen werden kann.

Eine effizientere Möglichkeit ist die Nutzung des Konstrukts Archiv-Sicherungsdatei unter Beibehaltung der alten Ordnerstrukturen. Dabei wird ein reduziertes XML-Schema genutzt, das keinen Header mit Informationen zum Dokument und keine MIME-Types enthält. Alle Dateien, die sich in den entsprechenden Ordnern befinden, werden automatisch in der ASD erfasst und mit einem Hash-Wert versehen. Im Anhang C befindet sich das zugehörige XML-Schema. Für den oben abgebildeten Ausschnitt aus der Ordnerstruktur eines Dokuments würde sich folgendes XML-Dokument ergeben:

Die Integration von weiteren zu archivierenden Dateien auch in Ordnerstrukturen ist mit diesem Schema problemlos möglich. Die Erstellung kann automatisch erfolgen. Anschließend wird auch nicht jede erzeugte XML-Datei separat signiert und zeitgestempelt, sondern eine Metadatei mit Referenzen auf alle XML-Dateien und ihren jeweiligen Hash-Werten:

Mit dem vorgeschlagenen Migrationskonzept können die bereits vorhandenen Dokumente und die bereits erstellten Signaturen sowie Zeitstempel auf einheitliche Weise übernommen und noch nicht signierte Dokumente nachgetragen werden.

Vorhandene Zertifikate auf den alten Chipkarten sollten baldmöglichst erneuert und damit an die neuen Anforderungen angepasst werden. Chipkarten, die durch vergessene PINs nicht mehr benutzt werden können, sind an die Verwaltungsleitung zurückzugeben und unbrauchbar zu machen. Zertifikate zu Signaturschlüsseln, die eventuell kompromittiert wurden, sind zuvor beim ZDA zu sperren. Die Gültigkeit der bereits erstellten Signaturen bleibt davon unberührt, sofern durch einen Zeitstempel der Zeitpunkt der Erstellung nachweisbar ist.

Für die Umsetzung des Konzepts ist es erforderlich, dass auch eine Reihe von organisatorischen Regelungen getroffen und dokumentiert wird. Nur so lässt sich eine reibungslose Integration in den Geschäftsablauf unter gleichzeitiger Wahrung eines hohen Sicherheitsstandards erreichen.

Im Folgenden werden Formulierungsvorschläge unterbreitet, die in entsprechende Dokumente eingearbeitet werden können.

1. Verfahrensregelung zum Umgang mit Zertifikaten

Für die Sicherung von Authentizität und Integrität der elektronischen Publikationen, die auf dem Dokumentenserver der Humboldt-Universität zu Berlin veröffentlicht sind, werden qualifizierte Signaturen und Zeitstempel mit Anbieterakkreditierung gemäß dem deutschen Signaturgesetz [SigG01] eingesetzt. Dazu werden Zertifikate für die mit diesen Aufgaben betrauten Mitarbeiter beantragt. Die Zertifikate werden unter dem Namen des jeweiligen Mitarbeiters ausgestellt, wobei der angezeigte Name ein Pseudonym ist, das auch die Referenz auf die Humboldt-Universität enthält. Des weiteren ist eine Selbstbeschränkung einzutragen. Die Beantragung des Zertifikats erfolgt durch die Verwaltungsleitung des CMS und Abstimmung mit der Leitung der „Arbeitsgruppe Elektronisches Publizieren“. Die Ausgabe und Zurücknahme der Chipkarte ist jeweils durch die Verwaltungsleitung zu dokumentieren.

Die Nutzung der Zertifikate ist nur für dienstliche Aufgaben im Rahmen des in der Selbstbeschränkung definierten Spektrums zulässig. Eine private Nutzung ist strikt untersagt. Eine Sperrung des Zertifikats kann jederzeit durch die Verwaltungsleitung auch ohne Mitwirkung des Zertifikatsinhabers erfolgen. Der jeweilige Mitarbeiter ist für die Rechtsfolgen, die aus einer unberechtigten Nutzung des Zertifikats entstehen, in vollem Umfang selbst verantwortlich.

Die Karte ist sorgfältig aufzubewahren. Die nach Freischaltung der Karte gewählte PIN ist vertraulich zu behandeln und insbesondere keiner anderen Person mitzuteilen. Es erfolgt eine Hinterlegung in einem verschlossenen Umschlag bei der Verwaltungsleitung. Jeglicher Hinweis auf einen möglichen Missbrauch ist sofort der Leitung der „Arbeitsgruppe Elektronisches Publizieren“ zu melden, die ggf. eine Sperrung des Zertifikats veranlasst. Mit dem Ende der Gültigkeit des Zertifikats oder nach dessen Sperrung ist die Chipkarte der Verwaltungsleitung zu übergeben und unbrauchbar zu machen.

2. Verfahrensregelung zur Archivierung von elektronischen Publikationen

Die Nutzung der ausgestellten Zertifikate ist nur im Rahmen der Archivierung elektronischer Dokumente gemäß dem definierten Geschäftsgang zulässig. Die Erstellung von Signaturen und Zeitstempeln darf nur in der vorgeschriebenen technischen Umgebung und mit den zugelassenen Komponenten des Archivservers erfolgen. Der Einsatz der Chipkarte bzw. des Signaturschlüssels ist zu dokumentieren, z.B. in einem Logfile.

Es ist sicherzustellen, dass alle zu archivierenden Dateien mit einem zum MIME-Type passenden Viewer gemäß aktuell gültiger Liste geprüft wurden. Bei der Neuerstellung von Archiv-Sicherungsdateien sind nur die jeweils geänderten oder neu hinzugekommenen Dateien zu betrachten.

Für den Betrieb des Dokumenten- und Publikationsservers der Humboldt-Universität wurde eine Policy veröffentlicht [EDOC01a], die die Ziele und Arbeitsweise des Systems darstellt sowie technische und organisatorische Rahmenbedingungen vorgibt. Solch eine Policy ist keineswegs Standard, betrachtet man die Angebote digitaler Dokumente deutscher Hochschulen. Sie demonstriert den offiziellen Charakter des Angebots und gewährleistet gegenüber Autoren und Nutzern, dass die Publikationen gemäß definierter und kontrollierter Bedingungen veröffentlicht werden. So wurde die Policy der HU auch von der Medienkommission des Akademischen Senats bestätigt.

In Bezug auf die Langzeitsicherung von Dokumenten werden in der Policy folgende Aussagen getroffen:

• 1. „Der Dokumenten- und Publikationsserver bietet durch besondere Maßnahmen wie digitale Signaturen und Zeitstempel einen Schutz gegen Verfälschungen. Darüber hinaus wird eine Langzeitarchivierung der elektronischen Dokumente gewährleistet“
• 5.1 „Durch die Vergabe und den Nachweis qualifizierter elektronischer Signaturen erhalten die elektronischen Dokumente ein rechtswirksames Echtheitszertifikat. Die Vergabe der qualifizierten elektronischen Signaturen erfolgt entsprechend dem Gesetz über Rahmenbedingungen für elektronische Signaturen (Signaturgesetz – SigG)“
• 5.2 „Die elektronischen Dokumente werden mit individuellen und dauerhaften Adressen versehen, welche einen unmittelbaren Zugriff auf die Dokumente erlauben“
• 5.5 „Bei Verwendung des Formates SGML/XML wird eine Archivierungsgarantie von 50 Jahren gegeben. Die Archivierungsdauer anderer Formate hängt von der Verfügbarkeit des Formates, der Betrachtungssoftware sowie den Konvertierungsmöglichkeiten ab.

Abschnitt 1 enthält die grundsätzliche Aussage, dass Vorkehrungen für die Dokumente getroffen werden, um ihre langfristige Verfügbarkeit zu sichern. Dies wird im Abschnitt 5 konkretisiert, in dem die wesentlichen Anforderungen angesprochen werden, nämlich die Lesbarkeit der Dateien durch Orientierung auf ein konvertierbares Dateiformat, der permanente Zugriff durch eine sich nicht ändernde Internet-Adresse sowie die Sicherung der Integrität und Authentizität der veröffentlichten Dokumente durch qualifizierte Signaturen.

Die Aussage des Absatzes 5.1 ist auch unter Berücksichtigung der Ergebnisse dieser Arbeit weiterhin gültig; allerdings könnte eine präzisere Formulierung noch besser die Vorteile des verwendeten Verfahrens demonstrieren. Im Folgenden wird eine Neufassung des Absatzes vorgeschlagen, die bei einer Überarbeitung der Policy berücksichtigt werden könnte:

Zur Sicherung von Authentizität und Integrität der elektronischen Dokumente werden qualifizierte Signaturen und Zeitstempel mit Anbieterakkreditierung gemäß dem deutschen Signaturgesetz eingesetzt. Die langfristige Prüfbarkeit der Signaturen wird gewährleistet. Die aktuell gültigen technischen und organisatorischen Rahmenbedingungen werden auf dem Dokumentenserver veröffentlicht.

Um jederzeit den Nachweis der korrekten Umsetzung der in diesem Konzept formulierten Anforderungen führen zu können, ist eine Reihe von Dingen zu dokumentieren:

• Die Ausgabe sowie Sperrung oder Rückgabe der Zertifikate für die Mitarbeiter
• Die für die Signaturerstellung genutzte Software sowie die technische Umgebung des Archivservers
• Die für die Betrachtung der Dateien des Archivs gemäß zugeordnetem MIME-Type definierte Viewer-Software

Die Dokumente sind von der Leitung der „Arbeitsgruppe Elektronisches Publizieren“ zu führen und ständig zu aktualisieren. Sie werden gemäß dem Vorschlag für die Policyänderung auf dem Dokumentenserver veröffentlicht.

1. Zertifikatsverzeichnis

Die Ausgabe und Rücknahme der Chipkarten mit den Zertifikaten erfolgt durch die Verwaltungsleitung. Das Verzeichnis enthält Informationen darüber, wann Mitarbeiter eine Chipkarte für das Signieren elektronischer Dokumente erhalten oder diese zurückgegeben haben. Im Einzelnen sollen folgende Daten erfasst werden:

Bei Ausgabe der Karte bestätigt der Mitarbeiter durch seine Unterschrift die Kenntnisnahme von den Verfahrensregelungen zum Einsatz des Zertifikats.
Wenn der Mitarbeiter eine Karte neu erhalten hat, muss diese entsprechend dem vom Zertifizierungsdiensteanbieter vorgegebenen Verfahren freigeschaltet werden. Hierbei wird von Telesec das Nullpin-Verfahren genutzt. Hierbei wird eine spezielle Freischaltungsfunktion genutzt, die nur einmal aufgerufen werden kann. Wenn sich diese Funktion nicht korrekt durchführen lässt, ist dies ein Indiz für eine mögliche missbräuchliche Verwendung. Wenn der Mitarbeiter die PIN erfolgreich geändert hat, ist diese auf einem Blatt Papier zu notieren und in einem Umschlag zu verschließen, der mit dem Namen des Mitarbeiters versehen wird. Dieser PIN-Brief ist unverzüglich der Verwaltungsleitung zu übergeben, die ihn an einem sicheren Ort (z.B. Safe) verwahrt. Vergessene PINs sind die häufigste Ursache für nicht mehr nutzbare Chipkarten. Mit der zentralen Hinterlegung kann dem vorgebeugt werden. Selbstverständlich ist durch die Verwaltungsleitung sicherzustellen, dass Mitarbeiter nur auf ihre eigenen PIN-Briefe Zugriff erhalten.

2. Signaturerstellungsumgebung

Die technische Erstellungsumgebung für die Signaturen ist zu dokumentieren und bei Änderungen anzupassen. Zu den zu pflegenden Angaben gehören:

3. Viewer-Software

Die für die Betrachtung der einzelnen Dateien des Dokuments genutzte Software ist für jeden gemäß Definition der Archiv-Sicherungsdatei gültigen MIME-Type anzugeben und natürlich regelmäßig anzupassen. Es ist ein Hinweis zu eventuellen Abweichungen in den Softwareversionen zwischen der Referenz auf dem Archivserver und den Arbeitsplatzrechnern der mit der Bearbeitung betrauten Mitarbeiter aufzuführen. Eine mögliche Softwareliste findet sich in der folgenden Tabelle:

Die Erstellung der Ordnerstruktur für die Dokumente sowie der Archiv-Sicherungsdatei lässt sich weitgehend automatisieren. Auch wenn im Rahmen dieses Konzepts keine diesbezügliche Implementation vorgenommen wurde, sollen dennoch einige Hinweise zu einer möglichen Umsetzung in eine entsprechende Software gegeben werden.

• Die Ordnerstruktur für einen Archiveintrag kann als Template hinterlegt werden. Ein Programm könnte dann z.B. nur noch den URN für den neu zu erstellenden Eintrag abfragen, daraufhin den letzten Counter ermitteln und die neue Struktur erzeugen.
• Die Erstellung der Archiv-Sicherungsdatei lässt sich ebenfalls weitgehend automatisieren. Einige Inhalte können selbstständig ermittelt, andere durch einfache Nutzereingabe abgefragt werden. Beim Durchlaufen der Ordnerstruktur werden für jede gefundene Datei die Einträge mit URI, Hash-Wert und dem MIME-Type erzeugt, der aus einer Tabelle mit den dazugehörigen Dateiendungen ermittelt werden kann. Trotzdem ist die Datei natürlich noch einmal manuell zu überprüfen.
• Die Hash-Werterzeugung kann z.B. mit Hilfe von Programmen aus der OpenSSL-Bibliothek vorgenommen werden. OpenSSL ist ein weltweites Projekt, das es sich unter anderem zum Ziel gesetzt hat, eine frei verfügbare Bibliothek von kryptografischen Funktionen auch für kommerzielle Anwendungen bereitzustellen. Die Software liegt derzeit in der Version 0.9.7b vor und ist Teil vieler Produkte und kann für diese Zwecke als Referenz und damit als hinreichend vertrauenswürdig angesehen werden. Für die Hash-Werterzeugung wird das Programm sha1 eingesetzt, das z.B. mit folgendem Aufruf den gewünschten Hash-Wert für eine Datei erzeugt:
  >openssl sha1 -sha1 -binary mertens.pdf | openssl base64
  >SHA1(mertens.pdf)= mTjVYmwfASSSTa8QmdqqLSwiQCE=
  Der ermittelte Wert kann dann direkt in die XML-Datei übernommen werden. Das Programm wird von der Kommandozeile aufgerufen, es kann auch die Funktion der bereits vorkompilierten Library ssleay32.lib genutzt werden. Eine Integration in eigene Anwendungen ist somit problemlos möglich.

Die vorgeschlagene Lösung ist in der Lage, die formulierten Anforderungen zu erfüllen. Sie stellt jedoch eine individuelle Entwicklung dar und ist an einer Reihe von Stellen auf die speziellen Anforderungen bei der Verarbeitung digitaler Dokumente im CMS der HU Berlin und auf eine schnelle Umsetzbarkeit im Rahmen des derzeitigen Workflows optimiert. So orientiert sich z.B. die erstellte Archivierungsstruktur an den derzeit verarbeiteten Dateiformaten und der Ablage von Dateien auf dem Dokumenten- bzw. Archivserver. Dennoch lässt sich das Kernstück der Lösung – die Archiv-Sicherungsdatei – durch die einfache Spezifikation als XML-Schema problemlos an neue Anwendungsfälle anpassen. Die ASD besitzt folgende wesentliche Eigenschaften:

• Durch die Integration aller zu einem Dokument gehörenden Dateien wird die entsprechende Zusammengehörigkeit und eine Vollständigkeitsinformation ausgedrückt.
• Die Zusammenfassung der Referenz auf die Dateien und der Hash-Werte erfordert nur die Erzeugung einer Signatur und eines Zeitstempels.
• Es werden weitere Informationen zum Dokument erfasst, wie Metadaten, die Zugehörigkeit von Dateien zu entsprechenden Dokumentversionen und geprüfte Dateitypen.

Das Grundprinzip einer XML-Datei mit Referenzen auf zugrunde liegende Dokumente wird auch im „Metadata Encoding and Transmission Standard“ der Library of Congress verwendet [METS03]. Das Format erlaubt im Wesentlichen die Erstellung einer XML-Datei mit administrativen und beschreibenden Metadaten über ein Dokument, die Auflistung aller zum Dokument gehörenden Einzeldateien mit Ablageort als URN und weiteren Eigenschaften sowie die Abbildung einer Datei-Hierarchie und Verlinkungen zwischen den Dateien. Der Standard kann somit z.B. zur Implementation eines Archival Information Package gemäß OAIS genutzt werden. METS bietet eine höhere Funktionalität als die in dieser Arbeit vorgestellte Archiv-Sicherungsdatei, dies erfordert jedoch auch einen höheren Aufwand bei der Erstellung und verschlechtert die intuitive Erfassung der Inhalte. Des Weiteren ist derzeit keine Möglichkeit vorgesehen, die Integrität der referenzierten Dateien kryptografisch zu sichern, was jedoch über eine Erweiterung des Standards sicherlich möglich wäre.

Im Projekt „Archisig“, das im Kapitel 3 bereits erwähnt wurde und das sich speziell mit dem Aspekt der Langzeitarchivierung von Signaturen auseinander setzt, werden Hash-Trees zur Zusammenfassung von Dateien genutzt. Eine Abbildung von Dokumenthierarchien ist hierdurch jedoch aufgrund fehlender Flexibilität nicht ohne weiteres möglich. In der ASD sind die referenzierten Dateien linear angeordnet, aber einer oder mehrerer Dokumentversionen, wie z.B. PDF oder SGML, zuordenbar. Auch bei „Archisig“ wird nur eine Signatur bzw. ein Zeitstempel benötigt, um die gesamte Dokumentstruktur zu sichern. Sowohl die ASD als auch das Archisig-Konzept lassen die nachträgliche Löschung von Dateien zu, ohne die Prüfbarkeit insgesamt zu gefährden. Durch den Fokus von „Archisig“ auf die Langzeitarchivierung wurden Konstrukte entworfen, um die Erneuerung von Signaturen und Zeitstempeln signaturgesetzkonform abbilden zu können. Dies wird im Wesentlichen durch die Integration alter Zeitstempel in die Baumstruktur und die anschließende Neusignatur erreicht. Dabei wurde der Fall des Unsicherwerdens des Signaturalgorithmus als auch des verwendeten Hash-Algorithmus berücksichtigt. Die Konzepte werden im Projektrahmen prototypisch umgesetzt und sind teilweise als Vorschläge für die Integration in existierende Standards (ISIS-MTT) eingereicht.

Bereits jetzt gibt es interessante Konzepte und erste Implementationen von Archiv-Systemen, die auch den Aspekt der Langzeitarchivierung berücksichtigen, z.B. das Open Archival Information System (OAIS), das eine modulare Struktur unter Berücksichtigung verschiedener Anforderungen und Rollen im Archivierungsprozess beschreibt [OAIS02]. Im Februar wurde ein Internet Draft zur Spezifikation eines „Trusted Archive Protocol“ vorgelegt [IETF03], der die Langzeitarchivierung kryptografischer Informationen in Archiven betrachtet. Die Entwicklung von solchen Standards aber auch der Markt der kommerziellen Anbieter ist weiter zu beobachten und die Lösung kontinuierlich anzupassen und zu optimieren.

Viele Dokumente enthalten eine Reihe von Abbildungen und Grafiken. Diese werden derzeit einzeln als Objekt in der Archiv-Sicherungsdatei abgelegt. Bei einer hohen Anzahl von Elementen kann die ASD schnell sehr unübersichtlich werden. Eine Möglichkeit der Optimierung wäre eine stärkere Gruppierung der verschiedenen Elemente oder auch eine Auslagerung von bestimmten Dateigruppen, um die ASD klein und übersichtlich zu halten.

Die derzeitig verwendete Signaturanwendungskomponente PKS-Crypt ist hinsichtlich ihrer Bedienerfreundlichkeit und der Transparenz des Signiervorgangs noch optimierbar. So könnten z.B. Präsentationskomponenten integriert werden, um die Darstellung dessen, was zu signieren ist, zu verbessern. Auch eine Erweiterung der Funktionalität ist wünschenswert, wie z.B. die korrekte Prüfung auf den Signaturzeitpunkt oder die integrierte Erstellung von Signatur und Zeitstempel. Durch Standards von Signaturanwendungsumgebungen könnte die Vertrauenswürdigkeit der erstellten Signaturen erhöht werden, da nicht jede Maßnahme im Einzelnen nachgewiesen und bewertet werden müsste, die zum Schutz des Archivservers umgesetzt wurde. Weitere Fortschritte sind bei praktischen Verfahren für die Langzeitarchivierung von Signaturen zu erwarten. Durch die Integration von Signaturkomponenten in Archivsysteme oder auch durch Nutzung der Dienstleistungen kommerzieller Archivierungsdienste müssen diese Aufgaben künftig nicht mehr manuell durchgeführt werden. Die Ergebnisse des Projekts „Sichere Signaturerstellungsumgebung“ [TC03], das derzeit von der TC Trustcenter AG im Auftrag des BSI realisiert wird, sind bei der Konfiguration des Archivservers zu berücksichtigen.

Mit der Umsetzung von Standards für Signaturen, wie z.B. ISIS-MTT, werden Applikationen verfügbar sein, die interoperabel zu den Strukturen anderer ZDA arbeiten und deren Nutzung nicht abhängig von einer vertraglichen Bindung zum jeweiligen Anbieter ist. Derzeit lässt sich die Anwendung PKS-Crypt selbst für die Prüfung von Signaturen nur dann nutzen, wenn man eine Chipkarte der Telesec besitzt. Dies ist technisch jedoch nicht erforderlich. Bei Verfügbarkeit von offenen Applikationen könnten die Archiv-Sicherungsdatei sowie die erstellten Signaturen und Zeitstempel veröffentlicht werden, so dass die Nutzer des Dokumentenservers in der Lage sind, Prüfungen auf Authentizität und Integrität der ihnen vorliegenden Dateien selbst durchzuführen. Dies würde die Transparenz der durchgeführten Maßnahmen zur Sicherung der Dokumente wesentlich erhöhen.

Die Nutzung der elektronischen Signaturen könnte zukünftig für eine Reihe weiterer Aufgaben im Rahmen Publikationsprozesses genutzt werden. So könnte z.B. die Abgabebescheinigung für den Autor, die derzeit durch CMS erstellt wird, um die vollständige und korrekte Abgabe der elektronischen Dokumentenversion nachzuweisen, als signierte E-Mail an die Bibliothek verschickt werden. Des Weiteren könnte die Kommunikation zwischen verschiedenen Organisationseinrichtungen der Universität vollständig auf elektronischem Wege erfolgen, z.B. mit den Prüfungsämtern. Für viele dieser Aufgaben wird es nicht erforderlich sein, qualifizierte Signaturen mit Anbieterakkreditierung zu verwenden. Die Nutzung einfacher oder fortgeschrittener Signaturen einer selbst betriebenen PKI mit einem von allen Beteiligten akzeptierten Sicherheitsniveau ist durchaus möglich. Bei der Erweiterung des Einsatzspektrums ist auch die Verschlüsselung von Daten zu berücksichtigen. Eine elektronische Signatur allein schützt nicht die Vertraulichkeit der übertragenen Daten, wie es z.B. für den Austausch von Gutachten oder Prüfungsunterlagen erforderlich ist.

Mit elektronischen Publikationen ergeben sich völlig neue Darstellungsmöglichkeiten, die durch papiergebundene Dokumente nicht erreicht werden, wie z.B. Videos, Audios oder andere multimediale Elemente. Weiterhin können auch dynamische Dokumente erzeugt werden, deren konkrete Erscheinungsform erst durch den Betrachter und die Auswertung von übergebenen Parametern bestimmt wird. So können z.B. - basierend auf in einer Datenbank gespeicherten Messwerten - statistische Auswertungen erzeugt und als Grafiken dargestellt werden. Für eine Archivierung müssten die Datenbankstruktur und die Inhalte, die Programme zur Erzeugung der Auswertungen und Angaben zur Präsentation gespeichert werden. Um eine langfristige Integritätssicherung auf dieser Ebene erzeugen zu können, sind geeignete Speicherstrukturen zu entwickeln.