Querschnitt 21 / Februar 2007 - h_da: Hochschule Darmstadt

Weitere Magazine

Empfehlungen

Info

QUERSCHNITT 21 i i i i Abbildung 6 • Erzeugen elektronischer Signaturen: komprimierte Darstellung des Dokuments bilden und mit privatem Schlüssel verschlüsseln mit einer Eigenschaft zu versehen, die es in einzigartiger Weise allein vom Autor erhalten kann. Üblicherweise wird zu diesem Zweck auf ein asymmetrisches Verschlüsselungsverfahren zurückgegriffen, bei dem jeder Kommunikationspartner über zwei Schlüssel, einen öffentlichen (public) zum Chiffrieren und einen privaten Schlüssel (private) zum Dechiffrieren verfügt (Abbildung 5). Dieses Konzept wird Public-Key-Verfahren genannt. 3.1.1 Asymmetrische Verschlüsselung Ein Kommunikationsteilnehmer, der von seinen Partnern Dokumente chiffriert empfangen oder Dokumente chiffriert verwahren möchte, beschafft sich beispielsweise von einer entsprechenden Organisation, z. B. einem Zertifizierungsdiensteanbieter [BNA06] ein Schlüsselpaar. Die Festlegung welcher der private und welcher der öffentliche sein soll, ist willkürlich. Ein Schlüssel (der öffentliche) wird zum Chiffrieren der Allgemeinheit bekannt gegeben, der andere Schlüssel (der private) wird vom Besitzer zum Dechiffrieren benutzt. Der Besitzer des privaten Schlüssels verwahrt diesen sicher und gibt diesen niemand anderem preis. Zur geheimen Übermittlung eines Dokuments wird dieses mit dem öffentlich bekannten Schlüssel des Adressaten chiffriert. Allein mit dem passenden privaten Schlüssel kann das Dokument dechiffriert werden, der private Schlüssel ist aber nur dem Empfänger des Dokuments bekannt. Daher kann das Dokument weder auf dem Übertragungsweg noch an seinem Speicherort von anderen entziffert, gelesen oder verändert werden. Aufgrund einer speziellen Eigenschaft sind Public-Key-Verfahren für die Realisierung elektronischer Signaturen besonders geeignet. Der in Abbildung 5 dargestellte Mechanismus funktioniert nämlich unabhängig davon, in welcher Reihenfolge ein Schlüsselpaar auf ein Dokument angewandt wird. Mit dem privaten Schlüssel des Autors chiffrierte Dokumente lassen sich nur mit seinem öffentlichen Schlüssel wieder dechiffrieren. Das chiffrierte Dokument kann daher von jedem gelesen werden, der Zugang zum öffentlichen Schlüssel des Autors hat. Da aber nur der Besitzer des öffentlichen Schlüssels auch im Besitz des hier zum Chiffrieren benutzten privaten Schlüssels 70 Dokument komprimierte Darstellung bilden komprimierte Darstellung (Hash) mit privatem Schlüssel authentisieren Koffer mit komprimierter Darstellung nur mit öffentlichem Schlüssel zu öffnen sein kann, kann auch nur er der Autor sein. Damit ist das Dokument authentisiert. Diese Idee ist die Basis für die Realisierung elektronischer Signaturen. 3.1.2 Erzeugen elektronischer Signaturen Zum Erstellen einer elektronischen Signatur wird nicht das Dokument, sondern eine komprimierte Darstellung (Hash) verschlüsselt. Die so erstellte Signatur wird gemeinsam mit dem unveränderten Dokument übertragen. Das hat praktische Gründe: ein Dokument wie beispielsweise eine Notenliste soll während des Transports durch eine Prozesskette ohne zusätzlichen Aufwand für die Bearbeiter lesbar sein. Der Signaturprozess beginnt mit der Bildung einer komprimierten Darstellung des Dokuments (Abbildung 6). Das benutzte mathematische Verfahren wird als Hashing bezeichnet und das Ergebnis als Hash. Dieser besteht aus einer Bitfolge, die einige hundert bis tausend Bits umfasst. Die Qualität eines Hashs drückt sich darin aus, wie gering die Wahrscheinlichkeit ist, ein anderes Dokument zu finden, das den gleichen Hash liefert. Über einen Hash lässt sich so mit großer Sicherheit das zugehörende Dokument identifizieren. Im zweiten Schritt wird der Hash authentisiert, indem er mit dem privaten Schlüssel des Autors chiffriert wird. Dieser Schritt gewährleistet, dass die Signatur eines Dokuments einzigartig ist. Die Signatur wird im Allgemeinen gemeinsam mit dem signierten Dokument übertragen. 3.1.3 Validieren elektronischer Signaturen Bei der Validierung der Unterschrift unter einem Dokument wird ein Vergleich mit einer hinterlegten oder von einer Behörde beglaubigten Unterschrift (z. B. Personalausweis) durchgeführt. Eine Unterschrift ist außerdem untrennbar mit einem Dokument verbunden. Bei der Authentifikation des Dokuments wird auch die Integrität des physischen Mediums (Papier) überprüft, um Manipulationen an Unterschrift oder Dokumententext auszuschließen. Bei elektronischen Dokumenten können Veränderungen jedoch nicht durch Prüfen eines physischen Mediums erkannt werden. Die Integrität wird hier über einen Vergleich des in der Signatur enthaltenen Hashes mit dem Sicheres und effizientes Dokumentenmanagement am Beispiel einer deutsch-französischen Hochschulkooperation Hash des Dokuments nachgewiesen. Zu diesem Zweck wird, wie in Abbildung 6 dargestellt, zunächst der Hash des Dokuments berechnet. Mit Hilfe des öffentlichen Schlüssels des Autors des Dokuments wird der in der Signatur übertragene Hash dechiffriert. Hier ist ein wichtiger Punkt zu erwähnen: Stimmen beide Hashes überein, dann ist bewiesen, dass seit dem Zeitpunkt der Signatur das Dokument nicht verändert wurde, denn sonst hätte der öffentliche Schlüssel nicht den Original-Hash restauriert. Allein, es fehlt der Nachweis, ob der Besitzer des öffentlichen Schlüssels auch wirklich der ist, für den er sich ausgibt. 3.1.4 Beglaubigen öffentlicher Schlüssel Zur Validierung einer Signatur muss daher ein öffentlicher Schlüssel eindeutig einer bestimmten Person zugeordnet werden können. Schließlich lassen sich gemäß bekannter Verfahren für den eigenen Gebrauch beliebig asymmetrische Schlüsselpaare erzeugen. Der öffentliche Schlüssel muss daher noch mit der Identität des Benutzers verbunden werden. Dies kann beispielsweise durch die persönliche Übergabe des Schlüssels erfolgen. Mit dem Konzept der Zertifikate wurde ein formales Verfahren eingeführt, mit dem die Übergabe eines öffentlichen Schlüssels vereinfacht wird. Zertifizierungsdiensteanbieter [BNA06] beglaubigen die Identität des Besitzers eines öffentlichen Schlüssels durch ein von ihnen signiertes elektronisches Dokument, dem Zertifikat. Zur Validierung des Zertifikats wird wie in 3.1.3 beschrieben vorgegangen und dabei der öffentliche Schlüssel des Zertifizierungsdiensteanbieters verwendet. 3.2 Bereitstellen einer prototypischen Infrastruktur Im Rahmen unseres Projekts wurden Verwaltungsprozesse modelliert mit dem Ziel der medienbruchfreien Verarbeitung der involvierten Dokumente. Zur Erprobung und Evaluation eines Vorgehensmodells wurde eine geeignete Infrastruktur gebraucht, deren prototypische Realisierung im Folgenden beschrieben wird. Die benötigten spezifischen Funktionen wurden in einer Masterarbeit [Mon06] identifiziert und als flexibel einsetzbares Java-Framework implementiert. Dieses kann sowohl in bestehende Programmsysteme integriert als auch wie nachfolgend beschrieben, zur Realisierung zentraler Serverdienste eingesetzt werden. 3.2.1 Geeignete Dienste Für eine automatisierte und sichere Verarbeitung von Dokumenten sind bestimmte Funktionalitäten und Dokumenteneigenschaften unabdingbar. Wie in Kapitel 2 bereits dargelegt, bieten XML-basierte Dokumentenformate ideale Voraussetzungen für medienbruchfreie Abläufe. Allein zur Präsentation von Dokumenten am Ende einer Prozesskette sollte zusätzlich das PDF-Format zum Einsatz kommen. Die hier interessierenden Geschäftsprozesse benötigen sowohl Funktionalität zum Signieren als auch zum Validieren von Signaturen. Wie im nachfolgenden Abschnitt erläutert, ist es FACHBEREICH INFORMATIK bei manchen Ausprägungen von Prozessketten notwendig, Dokumente mehrfach zu signieren. Für die prototypische Infrastruktur wurde daher folgende Kernfunktionalität realisiert: • Erstellen elektronischer Signaturen für die genannten Dokumentformate • Validierung der erstellten elektronischen Signaturen • Verbindung von Inhalt und Layout – Wandlung XML → PDF 3.2.2 Spezifische Forderungen aus dem Anwendungskontext Aus der Analyse der für Hochschulen typischen Prozesse ergab sich, dass der ursprünglich intendierte Nutzen von Signaturen sich vorteilhaft erweitern lässt. Signaturen lassen sich neben der Sicherung von Authentizität und Integrität beim Transport und der dauerhaften Speicherung auch verwenden, um den Bearbeitungsfortschritt eines Dokuments zu protokollieren. Auf diese Weise lässt sich nachvollziehen, von wem und in welcher Reihenfolge ein Dokument bearbeitet wurde. Aus diesem Grund wurden die Funktionen zum Generieren und Validieren von Signaturen so gestaltet, dass Dokumente auch mehrfach signiert werden können. Jede Signatur bezieht sich dann auf den Zustand bzw. Inhalt eines Dokuments nach einem bestimmten Bearbeitungsschritt. Sind mehrere Personen in die Erstellung eines Dokuments involviert, so interessieren außer deren Reihenfolge auch die einzelnen Zeitpunkte der Bearbeitung. In diesem Zusammenhang bedeutet Bearbeitung nicht unbedingt Veränderung oder Ergänzung eines Dokuments, sondern kann sich auch auf die Konsistenzprüfung eines Dokuments durch eine bestimmte Person beziehen. Hier wurden Zeitpunkt der Bearbeitung und der Signatur nicht unterschieden. Ein Bearbeitungsschritt wird durch eine Signatur abgeschlossen und durch einen Zeitstempel belegt, der im Dokument abgelegt wird. Um Zeitstempel nahtlos in Geschäftsprozesse integrieren zu können, wurde das hier verwendete XML-Schema so erweitert, dass das Java- Framework den Zeitpunkt der Signatur protokollieren kann. 3.2.3 Konstruktion des Java-Frameworks Die benötigten Funktionalitäten wurden als Java-Framework mit möglichst universellen und leicht erweiterbaren Schnittstellen realisiert [Mon06]. Zum einen lassen sich so bestehende (Java-) Anwendungen unkompliziert erweitern, weil der neu zu integrierende Code überschaubar bleibt. Auf der anderen Seite kann das Java-Framework als Grundlage für eine zentrale Serveranwendung verwendet werden. Open-Source-Projekte wurden daraufhin untersucht, ob bereits existierende Lösungen sich sinnvoll in das geplante Projekt integrieren lassen. Sowohl Zeitgewinne bei der Entwicklung als auch eine Verbesserung der Zuverlässigkeit der Software legen solche Überlegungen nahe. Für die benötigten kryptografischen Funktionen wurden erprobte Open-Source- Komponenten verwendet [JCA04]. Die asymmetrischen Schlüssel werden hier der besseren Handhabung wegen mit Hilfe von Zertifikaten verwaltet. Entsprechende Bibliotheksimplemen- 71
QUERSCHNITT 21 �� Abbildung 7: Schematische Übersicht der wesentlichen Funktionen des Signaturservers tierungen erhält man über den Import der Java Cryptography Architecture (JCA). Unterstützung bei der Verarbeitung von XML-Dokumenten liefern Referenzimplementierungen des Java Specification Requests 105: XML Digital Signature APIs. Die Evaluation verschiedener Implementierungen führte zum Einsatz der Apache Digital Signature API [ADS05]. Zur Implementierung der PDF- Signatur wurde als Basis die iText-Bibliothek [LOS06] genutzt. Diese Java-Bibliothek ermöglicht das Einlesen von PDF-Dokumenten und deren Speicherung als Java-Objekt. Auf diesem Objekt lassen sich dann Operationen anwenden wie das Erzeugen einer digitalen Signatur. 3.2.4 Signaturserver Der Signaturserver ist ein wichtiger Teil der technologischen Basis unseres Projekts. Er dient in erster Linie der Evaluation eines Vorgehensmodells zur schrittweisen Optimierung hochschulspezifischer Geschäftsprozesse. Der hier realisierte Signaturserver ist jedoch in seiner Verwendung nicht auf dieses Szenario beschränkt, sondern kann zur Unterstützung von Geschäftsprozessen herangezogen werden, solange zur Dokumentenmodellierung XML-Schemata verwendet werden. Anwendungen können die Funktionen des Signaturservers über spezifische, beim Benutzer installierte Programme in Anspruch nehmen oder über einen Webbrowser als Frontend. 72 �� Hier wurde eine Client-Server-Struktur realisiert, die Webtechnologien zur Visualisierung verwendet. Dadurch werden Installationen auf Clientseite vermieden. In Abbildung 7 sind die wesentlichen Funktionen des Signaturservers dargestellt. In frühen Phasen von Untersuchungen zur Optimierung von Geschäftsprozessen wird der Signaturserver gemeinsam mit anderen Anwendungen auf demselben Rechner eingesetzt. Komplexere Prozesse, die beispielsweise über mehrere Arbeitsplätze verteilte Anwendungen umfassen, erhalten Zugriff auf einen zentral installierten Signaturserver. Der Signaturserver verbleibt dann geschützt hinter der Firewall des lokalen Netzes. Sind die Anwendungen verteilt über verschiedene Lokationen, so ist jeweils eine lokale Installation eines Signaturservers sinnvoll. Bei der initialen Konfiguration eines Signaturservers wird der benötigte Satz an Zertifikaten dem Server bekannt gegeben. 4 • Zusammenfassung und Ausblick Die in den vorangegangenen Kapiteln beschriebenen Technologien bilden die Basis zur Erprobung der schrittweisen Integration der genannten Konzepte in die bestehende Infrastruktur. Den Partnern der eingangs erwähnten deutsch-französischen Hochschulkooperation wurden diese Konzepte im Frühjahr 2006 vorgestellt und haben ein großes Interesse auch für den Einsatz im nationalen französischen Hochschulbereich Sicheres und effizientes Dokumentenmanagement am Beispiel einer deutsch-französischen Hochschulkooperation Literatur ADS05 • Apache Digital Signature API. http://xml.apache.org/ security/Java/index.html, 28.10.2005, zuletzt besucht am 14.8.2006 BNA06 • Bundesnetzagentur, Verzeichnis der Zertifizierungsdiensteanbieter. http://www.bundesnetzagentur.de, 23.08.2006, zuletzt besucht am 23.8.2006 CDM05 • University of Norwegian: CDM-ECTS Documentation. http://cdm.utdanning.no/doku.php?id=cdm-ects: documentation, 21.09.2005, zuletzt besucht am 15.8.2006 ECTS06 • European Commission: ECTS – European Credit Transfer and Accumulation System. http://ec.europa.eu./ education/programmes/socrates/ects/index_en.html, 05.05.2006, zuletzt besucht am 15.8.2006 FOP06 • apache.org: Apache FOP (Formatting Objects Processor). http://xmlgraphics.apache.org/fop/, 24.07.2006, zuletzt besucht am 15.8.2006 JCA04 • Java Cryptography Architecture. http://java.sun.com/ j2se/1.5.0/docs/guide/security/CryptoSpec.html, 25.07.2004, zuletzt besucht am 14.8.2006 LOS06 • B. Lowagie, P. Soares: Documentation iText. http:// www.lowagie.com/iText/, zuletzt besucht am 14.8.2006 hervorgerufen. Die besprochenen Konzepte können im Rahmen dieser Kooperation bei kurzfristiger Umsetzung eine Beschleunigung der Generierung zweisprachiger Leistungsnachweise zu den einzelnen Kursen eines aktuellen Semesters bewirken. Die hierfür erforderliche dreifache Signatur der Notenlisten am Fachbereich in Darmstadt, im assoziierten regionalen Zentrum Elsass und in der Zentrale in Paris sowie die anschließende Wandlung in ein signiertes PDF-Dokument werden vom aktuellen System bereits unterstützt. Alle bisherigen Postwege sowie die manuelle, mehrfach redundante Erfassung der Daten an den verschiedenen Standorten werden durch den elektronischen Versand der mehrfach signierten Dokumente ersetzt. Alleine der Versand des endgültigen unterschriebenen Ausdrucks der Bescheinigung auf Papier an die Studierenden bleibt auch in den zukünftigen Szenarien erhalten. Für die genannte Konstellation bietet sich die jeweilige lokale Installation des Signaturservers an allen drei Standorten Darmstadt, Strasbourg und Paris, an sowie der Austausch der benötigten Zertifikate der drei Institutionen untereinander. Mit dem Angebot der neuen Bachelor- und Masterstudiengänge parallel zum traditionellen Ingenieursstudiengang, öffnet sich auch die CNAM-Hochschule für die europaweite Durchführung des Bolognaprozesses. Die Transparenz und Durchlässigkeit innerhalb der eigenen Studiengänge sowie im Aus- FACHBEREICH INFORMATIK Mon06 • F. Mondelli: Spezifikation und Realisierung eines Frame- works zum Signieren und Validieren elektronischer Dokumente in verschiedenen standardisierten Formaten. Masterarbeit, Hochschule Darmstadt, Mai 2006 Pin04 • M. Pineda: XSL-FO in der Praxis. XML-Verarbeitung für PDF und Druck. dpunkt Verlag, 2004 Sch96 • B. Schneier: Angewandte Kryptographie. Addison- Wesley, 1996 Uni06 • Unicode, Inc: Unicode 5.0.0. http://www.unicode.org/ versions/Unicode5.0.0, 15.7.2006, zuletzt besucht 15.8.2006 XML04 • W3C: Extensible Markup Language (XML) 1.0 (Third Edition), W3C Recommendation 04 February 2004. http://www.w3.org/TR/REC-xml/ XMLS04 • W3C: XML Schema, W3C Recommendation 28 October 2004. http://www.w3.org/TR/xmlschema-1/ XSL01 • W3C: Extensible Stylesheet Language (XSL) 1.0, W3C Recommendation 15 October 2001, http://www.w3.org/ TR/xsl/ XSLT99 • W3C: XSL Transformations (XSLT) 1.0, W3C Recommendation 16 November 1999, http://www.w3.org/TR/xslt/ tausch mit anderen europäischen Hochschulpartnern erfordert auch in Paris die Einführung eines internationalen Standards zum Austausch der mehrsprachigen Dokumentation von Lehrinhalten mit den zugehörigen Bewertungen nach dem ECTS- Standard. Die gemeinsamen Erfahrungen bei der Entwicklung eines Vorgehensmodells zur Integration des Signaturservers in die bestehenden Geschäftsprozesse international agierender Institutionen können sowohl am Fachbereich Informatik als auch an den anderen Fachbereichen unserer Hochschule angewandt werden. Betroffen sein werden alle IT-gesteuerten Prozesse, die für den Fachbereich wichtig sind im Hinblick auf standardisierte, effiziente Abläufe, die durch die Umsetzung des Bolognaprozesses erforderlich werden. Eine Integration der hochschulinternen HIS-POS-Datenbank bzw. integrierter Systeme, die die jeweiligen Studienordnungen der einzelnen Fachbereiche abbilden, wird hierbei eine besondere Herausforderung mit einem hohen Potential zur Steigerung der Effizienz bestehender Prozesse darstellen. Danksagung Wir danken der Firma media Transfer AG (mtG), Darmstadt für hilfreiche Diskussionen während der Durchführung des Projekts sowie für die Unterstützung bei der Präsentation auf der CeBIT 2006. 73
Seite 1 und 2: AUSGABE 21 | FEBRUAR 2007 UERSCHNIT
Seite 3 und 4: uerschnitt QBeiträ ge aus Forschun
Seite 5 und 6: Querschnitt 21 inhAlt Seiten 2 - 3
Seite 7 und 8: Querschnitt 21 inhAlt Seiten 138 -
Seite 9 und 10: Querschnitt 21 inhAlt 1 Seite 173 m
Seite 11 und 12: Querschnitt 21 • kooperation Am 2
Seite 13 und 14: Querschnitt 21 StoCretec: Betoninst
Seite 15 und 16: QUERSCHNITT 21 Wasser für Gadara -
Seite 17 und 18: Querschnitt 21 Abbildung 3.4 • Tu
Seite 19 und 20: QUERSCHNITT 21 Abbildung 9 • Mit
Seite 21 und 22: QUERSCHNITT 21 WIRKUNGSINDIZES FÜR
Seite 23 und 24: Querschnitt 21 Unfallkategorie (Sch
Seite 25 und 26: Querschnitt 21 4.2 Festlegung des b
Seite 27 und 28: Querschnitt 21 konstruktion eines P
Seite 29 und 30: Querschnitt 21 E S ES E P Abbildung
Seite 31 und 32: QUERSCHNITT 21 VERWENDUNG FLUORESZE
Seite 33 und 34: Querschnitt 21 60000 50000 40000 30
Seite 35 und 36: Querschnitt 21 sicheres und eFFizie
Seite 37: Querschnitt 21 Abbildung 4 • Aus
Seite 41 und 42: Querschnitt 21 The right thing (kno
Seite 43 und 44: QUERSCHNITT 21 Die Entwicklung zune
Seite 45 und 46: Querschnitt 21 Abbildung 12 • Die
Seite 47 und 48: Querschnitt 21 Abbildung 1 • Mech
Seite 49 und 50: Querschnitt 21 ist die Tatsache, da
Seite 51 und 52: Querschnitt 21 3.1 energetische ein
Seite 53 und 54: Querschnitt 21 Abbildung 2 • Sate
Seite 55 und 56: QUERSCHNITT 21 Abbildung 6 • Labo
Seite 57 und 58: QuerSCHNITT 21 Abbildung 15 • Sch
Seite 59 und 60: Querschnitt 21 1 • einleitung und
Seite 61 und 62: Querschnitt 21 11 0,1 0,08 0,06 0,0
Seite 63 und 64: Querschnitt 21 4 • Ausblick Neuer
Seite 65 und 66: QUERSCHNITT 21 ��
Seite 67 und 68: Querschnitt 21 Die drei räumlich-a
Seite 69 und 70: Querschnitt 21 bearbeiten oder zu l
Seite 71 und 72: Querschnitt 21 Projekte 1 Seiten 13
Seite 73 und 74: QUERSCHNITT 21 VOM CHEMIELABORANTEN
Seite 75 und 76: QUERSCHNITT 21 144 ��
Seite 77 und 78: Querschnitt 21 man zudem in der Lag
Seite 79 und 80: Querschnitt 21 AgAto - wir zeigen m
Seite 81 und 82: Querschnitt 21 dAs ende der ellenbo
Seite 83 und 84: Querschnitt 21 1 0 die Fortentwickl
Seite 85 und 86: Querschnitt 21 für Wirtschaft, Ver
Seite 87 und 88: Querschnitt 21 die ProjektgruPPe
Seite 89 und 90:
Querschnitt 21 literatur • Balder
Seite 91 und 92:
Querschnitt 21 eine Betriebswirtsch
Seite 93 und 94:
Querschnitt 21 münster, Anke • S
Seite 95 und 96:
Querschnitt 21 g neubAuer, michAel
Seite 97 und 98:
Querschnitt 21 Netzwerken sowie des
Seite 99 und 100:
Querschnitt 21 huckenbeck, sylViA
Seite 101 und 102:
Querschnitt 21 dAnksAgung Wir danke
Alle anzeigen

Querschnitt 21 / Februar 2007 - h_da: Hochschule Darmstadt

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?