OSCI: Die informelle Beschreibung Eine Ergänzung zur OSCI Spezifikation DIE OSCI–LEITSTELLE November 2001 Vers. 0.81

17.10

fst

Vers. 0.85

27.11.01fst

Darstellung Nachrichtenstruktur

Dieses Papier beschreibt informell das OSCI Nachrichtenformat sowie die Anforderungen an eine technische Infrastruktur, in denen OSCI Nachrichten ausgetauscht werden sollten. Es dient der Veranschaulichung und Erläuterung der Sachverhalte, die detailliert in der [OSCI 1.0] Spezifikation beschrieben sind. Bei Abweichungen gilt die Spezifikation in der jeweils aktuellen Fassung. Ausgenommen davon sind nur solche Passagen, in denen aufgrund neuer Erkenntnisse geplante oder bereits implementierte Abweichungen ausdrücklich genannt und beschrieben werden. Wir möchten mit diesen Ausführungen die potenziellen Anwender über OSCI informieren. Alle Leser sind ausdrücklich gebeten, sich mit Kommentaren und Kritik an die OSCI Leitstelle in Bremen zu wenden. Dort wird auch die Weiterentwicklung von OSCI koordiniert.

summary.fm / 27.11.01

Seite 2

OSCI: Die informelle Beschreibung

1 Zur Entwicklung von OSCI Unter dem Schlagwort E – Government werden Aktivitäten zusammengefasst, die durch die Nutzung "neuer Medien" versuchen, die Dienstleistungen der öffentlichen Verwaltungen effizienter, produktiver und für die Kunden attraktiver zu machen. Ein Teilbereich dieser Aktivitäten basiert auf einem elektronischen Nachrichtenaustausch über den neuen Vertriebsweg Internet. Dieser Teilbereich wird häufig unter dem Begriff "E - Bürgerdienste" zusammengefasst. Aufgrund der strengen rechtlichen Reglementierungen sowie hoher Anforderungen an den Datenschutz war es bis vor kurzem nicht möglich, über diesen Vertriebsweg mehr als nur Informationen oder die Vorbereitung einer Transaktion anzubieten. Erst die elektronische Signatur eröffnete die theoretische Möglichkeit, rechtsverbindliche Transaktionen nicht nur vorzubereiten, sondern über das Internet vollständig abzuwickeln. Ausschlaggebend dafür sind die einschlägigen Normen für die elektronische Signatur, sowie technische Implementierungen, insbesondere Chipkarten mit evaluierten Signatuerstellungskomponenten. Im Jahr 1998 initiierte die Bundesregierung den Städtewettbewerb MEDIA@komm, in dem Konzepte gesucht wurden, in denen "neue Medien" und die elektronische Signatur sinnvoll im E – Government zusammenwirken. Der prämierte Beitrag Bremens stellt die E - Bürgerdienste mit vollständiger Abwicklung von Transaktionen zwischen Bürger und Verwaltung in den Mittelpunkt und schlägt vor, hierfür ein Nachrichtenformat namens OSCI zu entwickeln. Das Konzept Bremens wird — neben denen aus Nürnberg und Esslingen — im Jahr 1999 prämiert. Der Projektträger beauftragt Bremen, dem Konzept entsprechend OSCI für die öffentliche Verwaltung zu entwickeln. Er verbindet dies mit dem Auftrag, dieses Nachrichtenformat — ausgehend von prototypischen "Bremer Lösungen" — einer bundesweiten Abstimmung bei den potenziellen Anwendern in der öffentlichen Verwaltung zu unterziehen. Ziele des E – Government (mehr Bürgerfreundlichkeit, höhere Effizienz und Transparenz der Verwaltung) lassen sich nur erreichen, wenn es eine stärkere DV - Vernetzung innerhalb der Verwaltung gibt, die aber nicht zu Hersteller- oder Produktabhängigkeiten führen darf. Daraus resultiert der Bedarf an einem Standard, welcher von der öffentlichen Verwaltung — und nicht den Herstellern — definiert und weiterentwickelt wird. Die OSCI–Leitstelle ist im Auftrag der öffentlichen Verwaltung, repräsentiert durch den KOOPA – ADV, tätig, um die geforderten interoperablen Austauschformate zu entwickeln und abzustimmen. Die Arbeitsergebnisse stehen der öffentlichen Verwaltung zur Verfügung. Sie können als Vorgabe für die Entwickler kommunaler Software dienen. Die Aufgaben der OSCI–Leitstelle werden im Abschnitt 7 auf Seite 15 beschrieben.

summary.fm / 27.11.01

3

2 Einsatzszenarien und funktionale Anforderungen Die Entwurfentscheidungen für OSCI basieren auf der Anforderung, im Rahmen des E – Government Transaktionen zwischen der öffentlichen Verwaltung und ihren Kunden über den Vertriebsweg "Internet" vollständig abwickeln zu können. Zudem haben wir uns an vorhandenen Gegebenheiten der DV - Ausstattung der öffentlichen Verwaltung zu orientieren. Es kann nicht vorausgesetzt werden, dass benötigte Fachverfahren eine 24–Stunden Verfügbarkeit aufweisen. OSCI weist eine skalierbare Sicherheitsarchitektur auf. Bei der Gestaltung der Sicherheitsmechanismen orientieren wir uns an Maximalforderungen. Wir gehen davon aus, dass es im Interesse der öffentlichen Verwaltung sein muss, auf gestiegene Sicherheitsbedürfnisse reagieren zu können, ohne die Sicherheitsarchitektur grundsätzlich neu konzipieren zu müssen. Maximalforderungen bezüglich der Vertraulichkeit ergeben sich insbesondere in der Umsetzung von Prozessen des Finanzwesens. Maximalforderungen bezüglich der Integrität, Authentizität und der Vertraulichkeit sowie des Nachweises der Fristwahrung sehen wir beispielsweise im Rahmen der elektronischen Angebotsabgabe. Betrachtet wird der vermittelte Austausch von Daten mit hohen und höchsten Anforderungen an die Integrität, Authentizität und Vertraulichkeit der Inhalte. Die Inhalte sind zumindest mit einer qualifizierten Signatur versehen. Sie sind zwischen Sender und Empfänger vertraulich. Während der Übermittlung kann eine vermittelnde Stelle (Intermediär, Portal) Mehrwertdienste erbringen, ohne die Vertraulichkeit zu verletzen. Zu diesen Mehrwertdiensten kann beispielsweise die Prüfung der Zertifikate der an der Kommunikation beteiligten gehören. Ebenso ist es möglich, die Zustellung der Nachrichten an Regeln zu knüpfen. Um diese Vermittlung und Erbringung von Mehrwerten ohne Vertraulichkeitsverlust zu erreichen, wird zwischen den Inhalts- und den Nutzungsdaten unterschieden, und diese werden kryptografisch unterschiedlich behandelt (siehe [OSCI Spec] II.1.3). Die Kommunikation ist symmetrisch: jeder der Kommunikationspartner kann prinzipiell sowohl Sender wie auch Empfänger sein. Insbesondere kann ein Sender aus dem Bereich der öffentlichen Verwaltung mittels einer OSCI Nachrichtenübermittlung einem Bürger Verwaltungsakte mit akkreditierter elektronischer Signatur übermitteln. Die Kommunikation kann sowohl synchron als auch asynchron verlaufen, OSCI unterstützt beide Varianten (dies ist in der OSCI 1.0 Spezifikation noch nicht dargestellt, dort wird nur die asynchrone Nachrichtenübermittlung beschrieben). Die genaue Analyse der Umsetzung von E – Government Prozessen hat gezeigt, dass sich die Ziele der Bürgerfreundlichkeit und der höheren Effizienz in der Regel nur erreichen lassen, wenn eine synchrone Kommunikationsphase einen "Dialog" zwischen der Clientkomponente beim Bürger und der Serverkomponente auf Seiten der öffentlichen Verwaltung erlaubt. Durch den Zugriff auf vorhandene Datenbestände in den Fachverfahren der öffentlichen Verwaltung wird die Fehlerrate der Kundennachrichten verringert, die Qualität erhöht und die Attraktivität der angebotenen Dienstleistungen der Verwaltung gesteigert. Andererseits sind viele Prozesse des E – Government so beschaffen, dass sie durch eine elektronisch signierte Nachricht des Kunden zwar angestoßen werden, aber nicht vollständig maschinell bearbeitbar sind. Häufig sind manuelle Tätigkeiten von Sachbearbeitern auf Seiten der öffentlichen Verwaltung erforderlich. Daraus ergibt sich der Bedarf nach einem asynchronen Austausch von OSCI Nachrichten. Durch OSCI Zustell- und Abholaufträge ist sichergestellt, dass Nachrichten nur von den berechtigten Empfängern abgeholt werden können. Die für eine Nachrichtenabholung notwendige Authentisierung des Kommunikationsteilnehmers basiert im Falle natürlicher Personen auf der vom deutschen SigG vorgegebenen PKI. Ebenso ist sichergestellt, dass die Identität des Nachrichtenabsenders verifiziert werden kann. Dieser muss nicht notwendigerweise mit demjenigen identisch sein, der die Inhaltsdaten signiert hat. Siehe [OSCI Spec] Abschnitt III. Die Kommunikation muss für den Sender wie auch für den Empfänger einer OSCI–Nachricht nachvollziehbar sein. Ein "Laufzettel" ist daher als wesentlicher Bestandteil der Nutzungsdaten auf Auftragsebene eingeführt worden. Siehe [OSCI Spec], Abschnitt III.2.1.1: Ein sogenannter Laufzettel steuert die Verarbeitung der Zustellung beim Intermediär. Die Geschäftsvorfallsdaten sind diesem aber nicht zugänglich. Vielmehr verarbeitet er den entsprechenden Datencontainer vollkommen transparent. Der Laufzettel konzentriert alle für die Zustellung durch den Intermediär erforderlichen Informationen. Er ist während der gesamten Verarbeitung durch den Intermediär die zentrale Datenstruktur. Er präzisiert die Zustellmodalitäten und die Inanspruchnahme seiner Mehr-

Seite 4

OSCI: Die informelle Beschreibung

wertdienste. Ausschließlich der Benutzer erzeugt einen Laufzettel, den er zusammen mit den übrigen Daten seines Zustellungsauftrags beim Intermediär einreicht. Der Intermediär aktualisiert diesen aber während der Verarbeitung der Zustellung. Auf Abholaufträge antwortet der Intermediär mit den jeweils aktuellen Laufzetteln. In der Realisierung von E – Government Prozessen wird häufig der Nachweis der Fristwahrung zu führen sein. Signaturen nach SigG müssen jedoch den Zeitpunkt der Signaturerstellung nicht ausweisen. OSCI sieht daher im Laufzettel Datenstrukturen für Zeitstempel vor. Siehe [OSCI Spec], Abschnitt III.2.1.1.4 Die notwendigen Sicherheitsmechanismen werden vollständig durch OSCI sichergestellt. Es werden keine Anforderungen bezüglich weiterer Schutzmechanismen an das unterliegende Transportprotokoll gestellt. Dies ermöglicht den Einsatz von OSCI auf verbreiteten Standardprotokollen, wie sie auch für technische Infrastrukturen in der öffentlichen Verwaltung typisch sind bzw. sein sollten (etwa SOAP / http). Eine OSCI–Nachricht weist aus diesem Grunde eine dreistufige Sicherheitsarchitektur mit Administrations-, Auftrags- und Geschäftsvorfallsebene auf, siehe [OSCI Spec] Abbildung 3 auf Seite II-4, sowie Abschnitt 5 auf Seite 10 in diesem Dokument. Das Ziel der höheren Effizienz durch E – Government Prozesse setzt in der Regel die medienbruchfreie Weiterverarbeitung der Geschäftsvorfallsdaten voraus. OSCI sieht daher den Transport von XML strukturierten Geschäftsvorfallsdaten als Regelfall vor. Bestandteile der Geschäftsvorfallsdaten können auch Anhänge (Attachments) mit beliebigen Inhalten sein.

summary.fm / 27.11.01

Globale Sicherheitsziele

5

3 Sicherheitsziele 3.1 Globale Sicherheitsziele Die funktionalen Anforderungen an OSCI lassen sich bezüglich der Sicherheitsziele wir folgt beschreiben.

3.1.1 Vertraulichkeit OSCI stellt eine Ende–zu–Verschlüsselung sicher und garantiert somit sowohl die vertrauliche Übertragung der Nachrichten als auch deren vertrauliche Aufbewahrung beim Intermediär. Auch der Intermediär erhält keine Kenntnis von den Inhalten der transportierten OSCI–Nachrichten — in der Regel Daten des jeweiligen Geschäftsvorfalls.

3.1.2 Integrität und Authentizität Mit Hilfe der elektronischen Signatur werden die Integrität und Authentizität der transportierten OSCI– Nachrichten sichergestellt.

3.1.3 Verbindlichkeit Der Intermediär quittiert mit Hilfe des Laufzettels dem Absender bzw. dem Empfänger das Versenden bzw. den Erhalt einer OSCI–Nachricht einschließlich des Zustelldatums.

3.2 Sicherheitsspezifische Funktionen Die oben formulierten globalen Sicherheitsziele werden auf der Ebene der OSCI–Basisfunktionen durch folgende sicherheitsspezifischen Funktionen abgedeckt, die sich an den ITSEC-Kriterien bzw. Common Criteria orientieren:

3.2.1 Benutzerauthentisierung Die Authentisierung ermöglicht es, die behauptete Identität des Benutzers zu verifizieren. Zur Benutzerauthentisierung dienen folgende OSCI Mechanismen: Signatur bzw. Signaturprüfung des Laufzettels, Authentisierung des Absenders mit Hilfe von zusätzlichen Attributzertifikaten.

3.2.2 Zugriffskontrolle Die Zugriffskontrolle hindert Benutzer und Prozesse, die für diese Benutzer tätig sind, lesenden oder schreibenden Zugriff auf Informationen oder Betriebsmittel zu erhalten, für die sie kein Zugriffsrecht haben. Die folgenden OSCI Basisfunktionen sichern die Zugriffskontrolle: Die Verschlüsselung bzw. Entschlüsselung der Geschäftsvorfallsdaten, der OSCI Zustellauftrag und die Authentisierung des Absenders.

3.2.3 Datenauthentisierung Die Datenauthentisierung erlaubt es, die Verantwortung für die Authentizität und Integrität von Daten zu übernehmen. Die Signatur der Geschäftsvorfallsdaten bzw. die Prüfung dieser Signatur sind die zugehörigen OSCI Basisfunktionen.

3.2.4 Nichtabstreitbarkeit der Kommunikation Diese unterteilt sich in zwei Unterziele: a Nichtabstreitbarkeit der Urheberschaft Die Nichtabstreitbarkeit der Urheberschaft stellt sicher, dass der Urheber nicht erfolgreich bestreiten kann, eine bestimmte Nachricht verschickt zu haben. b Nichtabstreitbarkeit des Empfangs Die Nichtabstreitbarkeit des Empfangs stellt sicher, dass der Empfänger den Erhalt einer Nachricht nicht erfolgreich abstreiten kann. Zur Sicherstellung dieser Ziele dienen die folgenden Basisfunktionen: Signatur bzw. Signaturprüfung

Seite 6

OSCI: Die informelle Beschreibung

der Geschäftsvorfallsdaten, Signatur bzw. Signaturprüfung des Laufzettels, die Zeitstempel innerhalb des Laufzettels sowie das Ausstellen von Quittungen.

3.2.5 Übertragungssicherheit Die Übertragungssicherheit garantiert, dass Daten während ihrer Übertragung über Kommunikationskanäle vor unbefugtem Zugriff geschützt sind. Diese Ziele werden mit Hilfe folgender OSCI Basisfunktionen erreicht: Verschlüsselung bzw. Entschlüsselung der Geschäftsvorfallsdaten, Verschlüsselung bzw. Entschlüsselung des Laufzettels.

3.2.6 Schutz vor Intermediär Die GVO-Nutzdaten sind gegenüber dem Intermediär geschützt, d.h. sie können von diesem weder gelesen noch verändert werden. Der Intermediär hat lediglich Zugriff auf die Auftragsdaten, die den Transport der Geschäftsvorfallsdaten regeln. Hierzu dienen die Ver- und Entschlüsselung der Geschäftsvorfallsdaten.

summary.fm / 27.11.01

Nachrichten werden sicher zwischengespeichert und nur Berechtigten übermittelt

7

4 Die Rolle des Intermediärs in den OSCI Kommunikationsszenarien Die Existenz einer zentralen Vermittlungsstelle, dem so genannten Intermediär, der Mehrwertdienstleistungen erbringen kann, ohne die Vertraulichkeit auf der Ebene der Geschäftsvorfallsdaten zu gefährden, ist für die sichere Umsetzung von Prozessen des E – Government mittels OSCI charakteristisch (siehe [OSCI Spec], Seite I-1). Bild 1: Die Stellung des Intermediärs

Die Notwendigkeit eines Intermediärs begründen wir wie folgt.

4.1 Nachrichten werden sicher zwischengespeichert und nur Berechtigten übermittelt Die Notwendigkeit der asynchronen Nachrichtenzustellung wurde oben bereits begründet, siehe Abschnitt auf Seite 3. Es besteht die Notwendigkeit, dem Kommunikationspartner eine OSCI–Nachricht zukommen zu lassen, ohne dass man voraussetzen kann, dass Sender und Empfänger zeitgleich online sind. Die Nachrichten sind zwischenzuspeichern. Eine Übermittlung der signierten und verschlüsselten Geschäftsvorfallsdaten mittels E–Mail (Protokoll SMTP) verbietet sich. Zwar wäre durch die Verschlüsselung sichergestellt, dass nur der berechtigte Empfänger die Daten dechiffrieren kann, aber durch das Vorspiegeln einer falschen Identität kann ein Unberechtigter sich in den Besitz der Nachricht bringen und dadurch wirtschaftlichen Schaden auslösen. Der Intermediär hat daher in der Rolle der OSCI Infrastruktur die Aufgabe des sicheren Mailservers. Er führt pro berechtigtem Empfänger Postkörbe. Ein Zugriff auf einen Postkorb zwecks Abholung von Nachrichten bedarf der vorherigen Authentisierung im Rahmen eines Abholauftrags, diese löst im Falle der positiven Authentisierung einen Zustellauftrag im Rahmen einer synchronen Kommunikation zwischen Intermediär und berechtigten Empfänger aus (siehe [OSCI Spec], Seite III-29). Der Besitz eines Postfaches und die Identität der Kommunikationspartner ist an deren X.509 Zertifikate geknüpft. Im Falle natürlicher Personen und der Signaturerstellung mittels Signaturkarte handelt es sich dabei um Zertifikate der CAs entsprechend der PKI nach dem deutschen SigG. Durch die Einführung zusätzlicher Attributtypen mit der Intention des Identifikationsattributzertifikat in [ISIS MTT] kann zukünftig die Identität einer natürlichen Person auch nach dem Verlust oder dem Ablauf seiner Signaturkarte sichergestellt werden. (Siehe dazu Tabelle 7: "Supported X.501 attrubute types and their maximal lengths" des Part 1: "Certificate and CRL Profiles)").

4.2 Aufwändige und teure kryptografische Funktionen können zentralisiert werden Die Datenstrukturen der OSCI Auftragsebene enthalten mehrere Zertifikate. Diese sind teilweise für die Verschlüsselungsmechanismen mittels asymmetrischer Verschlüsselung erforderlich, im Falle der Signaturzertifikate sind sie unabdingbar für die Prüfung der Integrität und Authentizität der signierten Daten. Die Gültigkeit dieser Zertifikate muss verifiziert werden, um Aussagen über Authentizität treffen zu

Seite 8

OSCI: Die informelle Beschreibung

können; siehe dazu [OSCI Spec] Abschnitt V.3.2.2.3. Die PKI nach SigG ermöglicht dem Empfänger einer signierten Nachricht diese Prüfung. Aufgrund der Tatsache, dass die erforderlichen Techniken noch relativ neu sind, wenig Erfahrung vorliegt und die einschlägigen Standards wie [ISIS MTT] noch nicht flächendeckend implementiert sind, sind die hierfür erforderlichen Techniken aufwändig, wartungsintensiv und teuer. Diese Problematik kann bei der technischen Umsetzung der E-Bürgerdienste im Rahmen einer E – Government – Umsetzungsstrategie innovationshemmend wirken. Der OSCI Intermediär ist die ideale Stelle, um solche Mechanismen im Rahmen eines Intranet einer öffentlichen Verwaltung zu zentralisieren. Die [OSCI Spec] schlägt entsprechende Mechanismen vor, die im Rahmen der OSCI Infrastruktur zu konkretisieren und durch den Intermediär implementierende Produkte zu realisieren sind. Der OSCI Laufzettel ist die geeignete Datenstruktur, um solche Prüfungen zu dokumentieren. Abweichend von der Vorgabe in der [OSCI Spec] auf Seite V.3 soll der Intermediär grundsätzlich jede zustellbare Nachricht an den Empfänger übermitteln — auch wenn die Nachricht unverschlüsselt, falsch verschlüsselt, nicht signiert oder falsch signiert ist. Eine "falsche Signatur" kann zum Beispiel auf ein Zertifikat zurückzuführen sein, welches zum Zeitpunkt der Zertifikatsprüfung durch den Intermediär nicht mehr gültig ist, weil der angegebene Gültigkeitszeitraum überschritten wurde. In den betrachteten Szenarien des E – Government nehmen wir aber den Standpunkt ein, dass der Empfänger einer OSCI–Nachricht selbst über die Relevanz solcher Mängel entscheiden muss. Betrachten wir als Beispiel eine elektronische Angebotsabgabe, so hat nach den Bestimmungen der einschlägigen Vergabeordnung die Beschaffungsstelle innerhalb der öffentlichen Verwaltung darüber zu entscheiden, ob ein "falsch signiertes" Angebot im Vergabeverfahren weiterhin zu berücksichtigen ist, oder nicht. Abweichend von der [OSCI Spec] sehen wir für eine Version 1.1 eine Erweiterung der Datenstruktur "Laufzettel" (siehe Abschnitt III.2.1.1 der [OSCI Spec]) um ein "Prüfprotokoll" vor. Die Ergebnisse aller vom Intermediär vorgenommenen Prüfungen der Zertifikate und Signaturen werden zum Bestandteil des Laufzettels. Es ist Aufgabe des Nachrichtenempfängers, anhand der Prüfergebnisse über den Umgang mit der Nachricht zu entscheiden. Grundsätzlich muss jeder potenzielle Empfänger von OSCI Nachrichten in der Lage sein, Zertifikatsund Signaturprüfungen auch selbst vorzunehmen. Die Nutzung einer OSCI Infrastruktur darf nicht dazu führen, dass Empfänger der OSCI–Nachrichten sich auf die Prüfprotokolls des Intermediärs verlassen müssen. Wir halten es aber für einen pragmatischen Ansatz in der OSCI Infrastruktur eine Stelle vorzusehen, an die man solche Prüfaufgaben delegieren kann.

4.3 Der Intermediär kann Zustellregeln prüfen OSCI–Nachrichten können regelbehaftet sein. Durch die Regeln kann die Übermittlung der Nachrichten an den Empfänger vom Intermediär gesteuert werden. Regeln sind Bestandteil der Datenstruktur "Laufzettel" (siehe [OSCI Spec], Absatz III.2.1.1.1. Durch eine Zustellregel kann zum Beispiel erreicht werden, dass ein elektronisch abgegebenes Angebot frühestens zum Submissionstermin von der Beschaffungsstelle abgeholt werden kann. Andere Beispiele für Zustellregeln ergeben sich aus der Verknüpfung der Nachrichtenübermittlung und Zahlfunktionen (Payment).

4.4 Der Intermediär ist das sichere Portal der Verwaltung Nach unserer Auffassung ist es wichtig für eine öffentlichen Verwaltung, die E – Government umsetzt, dass den Kunden ein einheitliches Portal mit einheitlichen Sicherheitsmechanismen und Zugangstechniken geboten wird. Dieses Angebot an die Kunden darf aber nicht zu einer Aufhebung der gebotenen datenschutztechnischen Trennung zwischen unterschiedlichen Verwaltungseinheiten führen. Durch die Ende–zu–Verschlüsselung zwischen Sender und Empfänger kann der Intermediär die Rolle eines Portals einnehmen, ohne dass es zu einem Verlust der Vertraulichkeit führt. In der Laufzettelstruktur sind die drei Elemente "Kurzbeschreibung", "Referenzmerkmal" und "Zustellbedingungen" vorgesehen. Diese ermöglichen dem Intermediär ein content - based Routing, ohne dass die Vertraulichkeit der Geschäftsvorfallsdaten darunter leidet. Siehe dazu [OSCI Spec], Abschnitt III.12ff. Aufgrund der unterschiedlichen kryptografischen Aufbereitung von Nutzungs- und Inhaltsdaten und der Konzentration der Zertifikate der an einer Kommunikation Beteiligten kann ein Intermediär ale eine zen-

summary.fm / 27.11.01

Der Intermediär ist das sichere Portal der Verwaltung

9

trale Dienstleistung die Prüfung der Zertifikate vornehmen. Hierfür sind in der Regel Online - Dienste der Zertifikatsherausgeber zu adressieren. Zum jetzigen Zeitpunkt sind diese Dienste für die wichtigen Zertifikatsherausgeber in der PKI nach SigG noch nicht hinreichend standardisiert, so dass eine Zentralisierung durchaus Sinn macht. Eine Prüfung der Signatur der Inhaltsdaten kann hingegen nicht zentralisiert werden. Diese Prüfung kann erst erfolgen, nachdem die Inhaltsdaten vom Empfänger (nicht vom Intermediär) dechifffriert worden sind.

Seite 10

OSCI: Die informelle Beschreibung

5 Die OSCI Nachrichtenstruktur In jeder OSCI Nachricht werden drei Sicherheitsebenen unterschieden: 1 Auf der äußersten Schicht, der Administrationsebene, befinden sich unverschlüsselte Daten. Dier hier befindlichen Datenelemente steuern unmittelbar den Datenaustausch zwischen zwei direkt kommunizierenden OSCI Teilnehmern. Das Chiffrierzertifikat des Empfängers dient als Adresse des empfangenden Kommunikationspartners. Der Verschlüsselungskopf erlaubt dem Empfänger das dechiffrieren der verschlüsselten Nutzungsdaten. 2 Die Daten der Auftragsebene bilden eine innere Schicht. Sie sind durch den jeweils sendenden Kommunikationspartner signiert und verschlüsselt. Im Sinne des Telekommunikationsdienstegesetzes (TKDG) handelt es sich bei den Daten dieser Ebene um die Nutzungsdaten. Sie werden benötigt, um die Nachricht technisch an den Empfänger übermitteln zu können. Die Nutzungsdaten erlauben den Nachvollzug der Übermittlung, sowohl aus rechtlichen Aspekten (Nachweis der Fristwahrung etc.), als auch für die Zwecke der Abrechnung. Außerdem findet man hier das Prüfprotokoll, in dem die Ergebbnisse von Zertifikatsprüfungen protokolliert sind. Diese Daten können vom jeweils nächsten Kommunikationspartner in der OSCI Infrastruktur dechiffriert werden. Insbesondere sind also diese Daten für den Intermediär lesbar und auch von ihm zu modifizieren. Zur Sicherstellung der Interoperabilität der Verschlüsselungsmechanismen macht die Spezifikation im Abschnitt V.2.4 genaue Vorgaben. Es handelt sich um ein Hybridverfahren. Ein Sitzungsschlüssel mit 128bit Länge wird erzeugt und dient der symmetrischen Verschlüsselung im 2-Key Triple DES Verfahren zu chiffrieren. Der Sitzungsschlüssel wird mit dem öffentlichen Schlüssel aus dem Chiffrierzertifikat des Empfängers nach dem RSA-Verfahren chiffriert. 3 Die innerste Schicht bilden die Inhaltsdaten. Sie befinden sich auf der Geschäftsvorfallsebene. Diese Daten sind Ende - zu - Ende verschlüsselt. Auch der Intermediär hat keine Möglichkeit, auf die Inhaltsdaten zuzugreifen. Bestandteil der Inhaltsdaten ist deren Signatur nach den Vorgaben von [w3c digital signature]. Die zur Signatur gehörenden Zertifikate sind allerdings auf die Auftragsebene herausgezogen. Bei dem Entwurf der Nachrichtenstruktur wurde diesen drei ineinander geschachtelten Ebenen besondere Sorgfalt gewidmet. Durch das Prinzip des doppelten Umschlags wird eine Infrastruktur ermöglicht, die eine Erbringung von Mehrwertdiensten durch den Intermediär erlaubt, ohne dass dieser Intermediär Kenntnis von den Inhaltsdaten erlangen kann. Durch diese unterschiedliche kryptografische behandlung wird auch den unterschiedlichen Qualitäten datenschutzrechtlicher Anforderungen an Nuzungs- und Inhaltsdaten Rechnung getragen. Die Signatur und Verschlüsselung der Auftragsebene dient in erster Linie der Sicherstellung der Integrität und Authentizität, und somit dem Schutz vor Manipulationen der Nutzungsdaten durch Angreifer während des Transports. Nur die Daten auf der Administrationsebene sind nicht durch besondere kryptografische Datenstrukturen der OSCI Nachricht selbst geschützt. Dem möglichen Angriffsszenario der Manipulation dieser Daten wird durch den OSCI Session - Mechanismus entgegengewirkt, dieser ist im Kapitel IV der Spezifikation beschrieben. Die Konzentration der erforderlichen Zertifikate der Kommunikationspartner in den Nutzungsdaten, also auf der Ebene der Auftragsdaten, erlaubt dem Intemediär die Prüfung dieser Zertifikate. Dadurch kann diese Aufgabe der Zertifikatsprüfung aus Verwaltungssicht zentralisiert werden. Jeder Empfänger kann für sich entscheiden, ob er den Angaben des Intermediärs über diese Prüfungen und ihre Ergebnisse vertraut. Eine Prüfung der Signatur der Inhaltsdaten kann hingegen durch den Intermediär nicht als zentrale Dienstleistung angeboten werden. Hierfür ist die Kenntnis der unverschlüsselten Inhaltsdaten erforderlich, der Intermediär hat diese Kenntnis nicht. Für die Datenstrukturen auf den drei Sicherheitsebenen gilt jeweils: •

Die Datenstruktur ist ein wohlgeformtes XML Dokument;

summary.fm / 27.11.01

Der Intermediär ist das sichere Portal der Verwaltung

•

es ist valide bezüglich der in der [OSCI Spec] angegebenen XML-Schemata.

Im Bild 2 auf Seite 11 ist die Struktur einer OSCI nachricht dargestellt. Bild 2: OSCI Nachrichtenstruktur

11

Seite 12

OSCI: Die informelle Beschreibung

6 Basisfunktionen und Infrastruktur Bei der Umsetzung von E – Government mittels OSCI müssen vier verschiedene Ebenen unterschieden werden, die im folgenden erläutert werden.

6.1 Die Geschäftsvorfälle Auf der Geschäftsvorfallsebene werden die Inhalte der E – Government Transaktionen transportiert, also zum Beispiel die Inhalte einer elektronischen Ummeldung oder eines elektronisch abegegebenen Angebotes. Die Kommunikationspartner müssen sich über eine semantische und strukturelle Standardisierung der Inhaltsdaten verständigt haben, um eine medienbruchfreie Weiterverarbeitung empfangener Daten in angeschlossenen DV–Verfahren zu ermöglichen. Die inhaltlichen Vorgaben für die Normierung der Geschäftsvorfallsdaten muss durch die öffentlichen Verwaltung erfolgen, sie ergeben sich in der Regel aus gesetzlichen Vorgaben sowie — pragmatisch — bereits etablierten Austauschformaten. In der Regel werden die Daten auf Geschäftsvorfallsebene als XML–Datenstrukturen realisiert werden. Die Definition der XML–Schemata für die verschiedenen Bereiche erfolgt durch die öffentlichen Verwaltung und wird durch die OSCI–Leitstelle koordiniert. Es können aber auch beliebige Datenströme (zum Beispiel Zeichnungen, Word-Dokumente) als Geschäftsvorfallsdaten zum Bestandteil einer OSCI– Nachricht werden, hierfür muss eine base64-Transformation angewandt werden. Die Geschäftsvorfallsdaten sind in aller Regel vom Sender elektronisch signiert, um Integrität und Authentizität sicherzustellen. Darüber hinaus werden die Geschäftsvorfallsdaten im Allgemeinen vertrauliche Daten enthalten; sie sind daher zwischen Sender und Empfänger Ende–zu–verschlüsselt. Zur Sicherstellung der geforderten Sicherheitsmechanismen wird auf die OSCI–Basisfunktionen zurückgegriffen.

6.2 Die OSCI Basisfunktionen Die Basisfunktionen stellen unabhängig vom transportierten Inhalt Mechanismen zur Verfügung, um diesen gegen Manipulationen und unbefugte Einsichtnahme zu schützen. Auf diese Mechanismen wird in folgenden Abschnitten im Detail eingegangen. Zur Sicherung der Geschäftsvorfallsdaten werden in OSCI kryptografische Mechanismen angewandt, insbesondere die elektronische Signatur und die Verschlüsselung nach dem public key Verfahren. Aus Sicht der Nutzer von OSCI besteht hier ein besonders hoher Anspruch an die Interoperabilität. Es gibt wenig praktische Erfahrung mit elektronischen Signaturen. Smartcards als Signaturerstellungskomponenten sind bei den Bürgern (den Kunden der Verwaltung) noch wenig verbreitet. Die Verwaltung muss mit ihren technischen Mitteln in der Lage sein, elektronisch signierte Nachrichten der Bürger entgegenzunehmen, sie zu dechiffrieren und die Signatur zu prüfen, und dies unabhängig von der beim Bürger vorhandenen Hard- und Software für das Signieren und Verschlüsseln. OSCI orientiert sich daher an einschlägigen Standards (zum Beispiel W3C digital signature sowie [ISIS MTT]) und Empfehlungen des BSI. Das deutsche Signaturgesetz [SigG] bildete die Grundlage beim Design der OSCI Basisfunktionen. Zu den OSCI Basisfunktionen gehören — neben den Nachrichtenstrukturen für die inhaltsunabhängigen Sicherheitsmechanismen — auch die exakt definierten OSCI Auftragsarten. Diese sichern zum Beispiel die Zustellung und die Abholung einer Nachricht mit den entsprechenden Authentisierungsmechanismen.

6.3 Die OSCI Infrastruktur Mit den beiden genannten Ebenen ist ein Nachrichtenformat vollständig beschrieben, welches die interoperablen Strukturen und Mechanismen in OSCI sind, um elektronisch signierte Nachrichten zwischen Sender und Empfänger auszutauschen. Für eine sichere Umsetzung von E – Government Prozessen sind jedoch weitere Aspekte zu bedenken. Dies sind vor allem: •

Die Verteilung der Zertifikate der Kommunikationspartner auf Seiten der öffentlichen Verwaltung. In der Regel wird es sich dabei nicht um natürliche Personen (einzelne Sachbearbeiter), sondern um Institutionen, Fachabteilungen oder sonstige Verwaltungseinheiten handeln. Diesen Kommunikationspartnern ist kein Signaturzertifikat nach dem SigG zugeordnet, so dass auch nicht auf die PKI des SigG zur Verteilung und Prüfung dieser Zertifikate zurückgegriffen werden kann.

summary.fm / 27.11.01

Implementierende Produkte

•

13

Die sichere Generierung der OSCI Geschäftsvorfallsdaten durch vertrauenswürdige Anwendungen. Es muss sichergestellt sein, dass die Anwendung auf Bürgerseite die Eingaben des Benutzers in der vom Nutzer intendierten Weise in OSCI–Nachrichten umsetzt und an den vom Kunden gewünschten Adressaten sendet. Bei den von OSCI adressierten Szenarien ist auch der "Diebstahl" einer Nachricht (also das Verhindern der Übermittlung an den intendierten Empfänger) ein Angriffsszenario mit hohem Risiko, selbst wenn der "Dieb" die Nachrichteninhalte nicht dechiffrieren und somit auch nicht interpretieren kann. Für den Sender der Nachricht kann dieser Angriff zum Beispiel dazu führen, dass Zustellfristen nicht gewahrt werden und somit ein hoher wirtschaftlicher Schaden entsteht.

Diese Mechanismen sind (zumindest zum jetzigen Zeitpunkt) kein Bestandteil der OSCI Spezifikation. Die sichere Ausgestaltung und Umsetzung von E – Government Prozessen ist vermutlich kein Gegenstand, der standardisierbar ist. Es können aber Empfehlungen für eine entsprechende OSCI Infrastruktur gegeben werden. Solche Empfehlungen sind: •

Anwendungen, welche aufgrund von Benutzerinteraktionen OSCI–Nachrichten generieren, sollten als signierte Java - Anwendungen realisiert und verteilt werden. Von den am Markt verbreiteten Methoden zur Verteilung vertrauenswürdiger Anwendungen an einen großen Kundenkreis ist dies nach unserer Auffassung die beste und sicherste.

•

Die Zertifikate der Kommunikationspartner, die nicht durch die PKI nach SigG abgedeckt sind, werden als Bestandteil der signierten Java Anwendungen mit verteilt. Eine solcherart gestaltete OSCI Anwendung "kennt" die Zertifikate der potenziellen Empfänger der Nachrichten, die sie generiert. (Beispielsweise kann eine OSCI Anwendung für den Zugriff auf ein Steuerkonto ihre Nachrichten ausschließlich an eines der dafür zugelassenen Rechenzentren der Finanzverwaltungen senden.)

6.4 Implementierende Produkte Die in den drei vorangegangenen Ebenen beschriebenen Mechanismen müssen durch konkrete Produkte implementiert werden. Im Gegensatz zu den drei anderen Ebenen ist hier ein Wettbewerb verschiedener Produkte durchaus im Sinne der Anwender. Aus diesem Grunde ist OSCI als Standard offengelegt. Die öffentlichen Verwaltung kann die OSCI Kompatibilität zur Vorgabe für Anwendungen und Produkte des E – Government machen. Im Einzelnen müssen folgende Hauptkomponenten unterschieden werden: 1 OSCI Kernel: sie kapseln anwendungsunabhängige Basisfunktionen, insbesondere in den Bereichen Kryptografie und Transport. 2 OSCI Anwendungen: sie realisieren einzelne Anwendungen und generieren OSCI–Nachrichten. Sie implementieren zum Beispiel die Online Ummeldung aus Bürgersicht. Aufgrund von Benutzerinteraktionen und Datenbankabfragen erstellen sie eine OSCI–Nachricht. Diese wird an den Kernel zwecks Visualisierung, Signatur, Verschlüsselung und Versand an das Einwohneramt übergeben. 3 Der OSCI Intermediär. Seine Aufgabe besteht in der Erbringung von Mehrwertdiensten ohne den Verlust der Vertraulichkeit sowie der Verwaltung von Nutzerpostfächern. 4 Backend – Adapter. Sie binden die auf Seiten der öffentlichen Verwaltung in der Regel vorhandenen Fachverfahren in die OSCI Infrastruktur ein und ermöglichen somit die Weiterverarbeitung ohne Medienbruch. Die vier genannten Ebenen werden im Bild 3 auf Seite 14 illustriert.

Seite 14

Bild 3: Unterschiedliche Ebenen beim Einsatz von OSCI

summary.fm / 27.11.01

OSCI: Die informelle Beschreibung

Implementierende Produkte

15

7 Die OSCI - Leitstelle Die OSCI–Leitstelle nimmt die folgenden Aufgaben wahr: 1 Die OSCI–Leitstelle erarbeitet im Auftrag der öffentlichen Verwaltungen einen Standard für die Abwicklung rechtsverbindlicher Transaktionen (OSCI). Der Standard wird mit dem Schwerpunkt des E – Government entworfen. Er unterstützt sowohl die E - Bürgerdienste ("Das Internet als Vertriebskanal für Dienstleistungen der öffentlichen Verwaltung"), als auch den Datenaustausch zwischen Behörden. 2 Die OSCI–Leitstelle koordiniert Entwicklungen für interoperable Datenaustauschformate auf der Geschäftsvorfallsebene. Entsprechend der Beschlusslage des KOOPA – ADV wird schrittweise vorgegangen. Zunächst werden solche Prozesse betrachtet, in denen es bereits bundesweite Regelungen gibt, die "nur noch" technisch zu realisieren sind. Beispiele dafür sind Meldewesen, KFZ - Wesen, Steuern. Die fachliche Erarbeitung der Inhalte muss dabei von Fachleuten der öffentlichen Verwaltung geleistet werden. Die OSCI–Leitstelle kann diesen Prozess durch Methodenwissen unterstützen und Ergebnisse dokumentieren. Die OSCI–Leitstelle sorgt dafür, dass übergreifende Objekte und Prozesse als solche identifiziert werden. Diese sind dann in eine übergreifendes Repository für E – Government einzubringen und zu pflegen. Es ist nicht die Intention der OSCI–Leitstelle, die Dienstleistungen der öffentlichen Verwaltungen (insbesondere des internen Workflow) zu standardisieren. Dies wäre nach unserer Auffassung kontraproduktiv für die Optimierung der internen Geschäftsprozesse, was ein ureigenes Anliegen der öffentlichen Verwaltung bleiben muss. Für sinnvoll halten wir hingegen Standardisierungen der angebotenen Services zur Kundenseite. Sofern diese Services über den Vertriebskanal Internet abgeboten werden, ist eine Standardisierung der Datenaustauschformate unabdingbar. 3 Die OSCI–Leitstelle koordiniert die Entwicklung von OSCI mit anderen, einschlägigen Standards durch zielgerichtete (Weiter-)entwicklung von OSCI, so dass Kompatibilität zu wichtigen anderen Normen (zum Beispiel [ETSI XAdES], [ISIS MTT]) sichergestellt wird. 4 Die OSCI–Leitstelle stimmt entwickelte Lösungen bundesweit ab. Bisher hat es sich als erfolgreich erwiesen, wenn Lösungen zunächst prototypisch vorgearbeitet werden, um sie dann der Abstimmung zuzuführen. Der Abstimmungsprozess soll in einer formalen Normung oder der Erstellung einer "public available specification" (PAS) münden. Hierzu kooperiert die OSCI–Leitstelle mit dem DIN. Die Gremien, mit denen eine Abstimmung vorzunehmen ist, ergeben sich aus dem jeweiligen konkreten Kontext. Neben dem KOOPA – ADV kann z. B. der deutsche Städtetag ein geeignetes Gremium sein. Auf Seiten der öffentlichen Verwaltung wird die Rolle des Auftraggebers durch zwei Institutionen wahrgenommen: •

Der Projektträger MEDIA@komm finanziert (während der Projektlaufzeit) die OSCI–Leitstelle. Er wird durch die regelmäßigen Projektberichte der Firma bos auch über die Aktivitäten der OSCI–Leitstelle informiert.

•

Inhaltliche Vorgaben werden vom KOOPA – ADV formuliert. Der KOOPA – ADV ist auch die Stelle, in denen die Aktivitäten im Rahmen OSCI mit den anderen Standardisierungs- und Umsetzungsvorhaben unter dem Stichwort E – Government abgeglichen werden.

OSCI ist die Umsetzung der inhaltlichen Vorgaben dieser Auftraggeber.