Authentifizierung, Nachweisführung und Vertragsschluß im Askemos®

Wollen zwei Parteien einen Vertrag nach dem Askemos-Verfahren schließen, so müssen sie sich zunächst darauf verständigen, an welchen Stellen (Dienstleister, im folgenden "Provider" mindestens vier, technisch und rechtlich unabhängig) der Vertragstext hinterlegt werden soll. Anschließend hinterlegt (speichert) eine Partei den Vertragstext (Angebot) an den vereinbarten Orten. In der Praxis werden alle Beteiligten Benutzer eines Askemos-Netzwerkes wie z.B. www.softeyes.net/fiXml sein.

Authentifizierung

Weder das Verfahren noch die technischen Details der Identifikation werden durch das Askemos-System definiert. Wichtig ist jedoch, daß alle Provider die Authentifikation getrennt und unabhängig voneinander durchführen, möglicherweise sogar nach unterschiedlichen Verfahren. Durch dieses 4-Augen-Prinzip wird sichergestellt, daß nur der Eigentümer über den Account verfügen (d.h. Änderungen vornehmen oder Dokumente anlegen) kann.

Die Authentifikation über Nutzername/Passwort kann dabei nur im Spezialfall der Anmeldung an der lokalen Maschine verwendet werden. Für die Authentifizierung über Internet muß sichergestellt werden, daß kein Provider Zugangsinformationen aus einem früheren Vorgang verwenden kann um gefälschte Nachrichten im Namen des Account-Eigentümers zu erzeugen. Das kann z.B. durch TAN, Challenge/Reponse-Verfahren oder SSL-Zertifikate ("klassische" elektronische Unterschrift) erfolgen. Ggf. wird die SSL-Signatur auch in besonders geschützte Hardware (sichere Signatureinheiten) verlagert.

Ein (ökonomischer) Vorteil des Askemos-Systems ist jedoch, im Vergleich zur "klassischen" ditigalen Signatur nur kurzzeitig gültige Zertifikate zu benötigen, so daß spezielle Signaturhardware oft überflüssig ist.

Für die korrekte Identifikation sind die Provider verantwortlich. Diese sind in Zukunft verpflichtet, über das Prüfergebnis auf Anforderung Zeugnis abzulegen.

Provider sind nicht (notwendigerweise) verpflichtet, den Prüfvorgang wiederholen zu können, wie das im SigG vorgesehen ist. Diese Prüfung problematisch: sie ist etwa so zuverlässig wie ein kompliziertes Zahlenschloß. Durch massiven Einsatz von Rechenleistung oder Fortschritte in der Mathematik können kryptographische Signaturen gefälscht werden. Die Prüfung muß daher zeitnah erfolgen.

Verifikation und Audit

Das Dokument wird vom Provider mit seinem Umgebungs- und Benutzerkontext (Metadaten) gespeichert. Am Dokument steht dran, wo (Provider) es zu welcher Zeit gespeichert wurde und wer der Autor ist. Daß dieser Kontext richtig ist und insbesondere die Identität des Autors stimmt, wird also bereits zum Speicherzeitpunkt sichergestellt. (Vgl. Zeitstempeldienst im SigG.)

Um Prozesse ebenso dokumentieren zu können, wird mit dem Dokument, welches aktuellen Prozesszustand beschreibt, ein weiteres Dokument mit Regel über den Ablauf des Prozesses gespeichert. (Im Datensatz unten "action-document".) Unveränderliche Dokumente bilden einen Spezialfall, in dem die so dokumentierte Vorschrift Änderungen am Objekt verbietet.

Als zusätzliche, im Askemos-System aber ebenso nicht zwingend erforderliche Sicherheit erhalten die Dokumente beim Speichern einen eindeutigen, selbstverifizierenden Identifikator ("OID"). Selbstverifizierend heißt dabei, daß der Identifikator als Prüfsumme aus (Teilen) der zu dem Dokument gespeicherten Daten berechnet wird. Verfälschungen der gesicherten Informationen fallen daher auf.

Zur Illustration ein Beispiel eines Satzes Metadaten (Datensatz: grau, Erläuterung: gelb):

<rdf:RDF
 xmlns:a="http://www.askemos.org/2000/CoreAPI#" xmlns:dav="DAV:"
 xmlns:dc="http://dublincore.org/documents/2004/12/20/dces/"
 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
 xmlns:s="http://www.askemos.org/2004/Synchrony/" xml:space="default">
 <rdf:Description rdf:about="A79ccfe49057146631a66413245fab3c0">

Durch rdf:about, hier A79ccfe49057146631a66413245fab3c0, wird das Dokument (OID) bezeichnet.

  <dc:creator>Adc5dd0c30f6e63932811ed60e019bb2d</dc:creator>
  <dc:date>Fri, 28 Jan 2005 19:58:24 +0100</dc:date>
  <a:action-document>Af051fe01ba259f25aae185d500b3d6a2</a:action-document>

dc:creator: Autor/Absender
dc:date: Erzeugungsdatum
d:action-document: Typdefinition; zu Grunde liegende Ablaufvorschrift/Vertrag

Diese drei Angaben zuzüglich die SHA256-Prüfsumme (unten) gehen in die Bestimmung des OID ein.

  <a:version rdf:parseType="Literal">
   <a:serial>0</a:serial>
   <a:checksum>A00000000000000000000000000000000</a:checksum>
  </a:version>

Die Anzahl der Aktionen (hier null) die der Prozeß bereits ausgeführt hat und Prüfsumme über die letzte Transaktion.

 <s:replicates>
  <rdf:Bag>
   <rdf:li rdf:resource="Af051fe01ba259f25aae185d500b3d6a2"></rdf:li>
   <rdf:li rdf:resource="A00000000000000000000000000000001"></rdf:li>
   <rdf:li rdf:resource="https://askemos2.tc-mw.de"></rdf:li>
  </rdf:Bag>
 </s:replicates>

Bezeichnet die (hier drei) Provider, von denen das Dokument verifiziert werden kann.

 <a:protection>Adc5dd0c30f6e63932811ed60e019bb2d/A8334f0c029a3088e3b04e90abb1ac3a3/public</a:protection>

Die Schutzklasse. Hier ein dreistufiger Schlüssel.

 <content-type>text/xml</content-type>
 <a:body>
  <a:blob>
   <a:sha256>f37b47ea0345e7f15d36224c1370ca7b12633c173c59d1b1d545ab50da3b9089</a:sha256>
  </a:blob>
 </a:body>

Die Art der Daten und die SHA256-Prüfsumme über den Inhalt.

 </rdf:Description>
</rdf:RDF>

Die Richtigkeit der zum Dokument gemachten Angaben wird geprüft, indem sie von den Providern abgerufen und verglichen werden. Sie gelten als integer und authentisch, wenn von mehr als zwei Drittel der Provider darin übereinstimmen. (Der Prüfvorgang erfolgt automatisch.)

Frage: ist dieser Abschnitt hilfreich/verständlich?
In Systemen mit technisch-physikalisch lokalisierbaren Daten (einzelne Computer oder Client-Server-Netzwerke) müßten für kritische Anwendungen alle zu Grunde liegende Komponenten verifiziert werden. Eine solche Verifikation ist praktisch nicht vollständig möglich, zumindest jedoch unwirtschaftlich. Trotz enormen Aufwands treten in umfangreichen Systemen immer wieder Fehler auf. Askemos bietet eine Alternative. Das Verfahren der Standardisierung mit wechselseitigem Audit trennt die Askemos-Ebene von unteren Komponenten. Fehler in Teilsystemen unter der Schnittstelle (Askemos-API) gleichen heterogene Netze wie Teilausfälle automatisch aus. So wird die vollständige Verifikation wirtschaftlich ersetzbar. Mit anderen Worten: Askemos führt Fehlertoleranz ein.
Oberhalb der Schnittstelle bleibt die Möglichkeit gewahrt, zu verifizieren ob und wie Anwendungscode die jeweiligen Spezifikationen (z. B. zugrunde liegende Verträge) erfüllt, da Anwendungscode fest mit der jeweiligen Anwendung verbunden ist. Dieser Nachweis kann ggf. wiederum bis zum Eintritt einer Fehlfunktion verzögert – und oft eingespart – werden.

Vertragsschluß

Eine Partei bietet den Vertrag an, indem sie ein unveränderliches Dokument mit dem Vertragstext bei den vereinbarten Providern (mindestens) der anderen Partei zugänglich macht.

Zugänglich machen bedeutet dabei zunächst das Dokument abzulegen. Dabei wird dem Dokument in Abhängigkeit vom Kontext eine Schutzklasse zugeordnet. Die anbietende Partei muß sicherstellen, daß die andere Partei Zugriffsrechte für diese Schutzklasse entweder schon hat oder erhält. Schutzklassen in diesem Sinn sind Räumen und Zugriffsrechte zu Schlüsseln vergleichbar.

Die andere Partei nimmt den Vertrag an, indem sie einen Prozeß mit einer entsprechenden Erklärung einleitet und dabei als zugrunde liegende Vorschrift das Dokument mit dem Angebot referenziert.

Soll nun über den Vertragsschluss Beweis - etwa bei Gericht - geführt werden, erhält der Richter Zugang zu den Dokumenten, indem ihm als Beweisantrag die Identifikatoren (OID) der Dokumente mitgeteilt und Zugriffsrechte darauf eingeräumt werden. (Ggf. ist erst ein Askemos-Account für das Gericht einzurichten). Mittels eines geeigneten Zugangeswerkzeugs (derzeit typischerweise ein Internet-Computer) kann der Richter auf die Dokumente und Inhalt sowie Metadaten analysieren.

Fazit

Unilateral von einer Partei angebrachte Signaturen, können - unabhängig von der Verwendung elektronischer Verfahren - mit technisch-physikalischen Mitteln räumlich eindeutig lokalisiert werden. Die Fälschungssicherheit solcher Signaturen ist durch das schwächste Glied im Verfahren bestimmt. Dies ist entweder die physikalische Änderung der Signatur selbst, oder Angriffe auf das Verifikationsverfahren.

Die Sicherheit kryptographischer Verfahren basiert auf extrem rechenaufwändigen, aber lösbaren mathematischen Problemen. Sofern Fälschern hinreichend Rechenleistung und Zeit zur Verfügung steht, beweisen solche Signaturen gar nichts. Im Kontext elektronischer Datenverarbeitung kommt erschwerend hinzu, daß die Fälschung mangels Spuren nicht nachweisbar ist.

Im Askemos wird die unilaterale, statische ("klassische" elektronische) Signatur durch die multilateral abgestimmte, dynamische Signatur ersetzt. Dieses Verfahren modelliert (nach Kräften und ich hoffe im Ergebnis der Untersuchung exakt) den üblichen Weg, sich gegen die Schwächen manueller Signaturen auf papierbasierten Dokumenten abzusichern, indem Notare den Sigiervorgang begleiten und im Bedarfsfall bezeugen.

M.E. sollten multilateral abgestimmte Signaturen als Minimalanforderung gelten um Rechtsfolgen aus elktronischen Signaturen ableiten zu dürfen.

Die Sicherheit des Verfahrens ist durch die Wahrscheinlichkeit bestimmt, daß die Mehrheit der Provider in ihrer notarartigen Rolle koordiniert korrumpiert werden könnte. Daher ist es am Anfang des Verfahrens notwendig, die Speicherorte (Provider) dem Vertragsinhalt angemessen zu wählen. Zwei Methoden sind dabei besonders interessant: