/** \page docPayment Momentane Implementierung des Bezahlsystems für AN.ON
@manonly
\documentclass{article}
\usepackage[ngerman]{babel}
\usepackage[latin1]{inputenc}
\usepackage{graphics}
\usepackage[dvips]{graphicx}
%\usepackage{pstcol}
\usepackage{amsmath}
\usepackage{ifthen}
\newcommand{\todo}[1]{{\marginpar{\textbf{#1}}}}
\newcommand{\zb}{z.\thinspace B.\ }
\newcommand{\Dh}{d.\thinspace h.\ }
\newcommand{\KBN}{\textit{KBN}\ }
\newboolean{pdf}
\setboolean{pdf}{false}
@endmanonly
@latexonly
\author{Stefan Köpsell, Andreas Müller, Bastian Voigt\\sk13@inf.tu-dresden.de, am12@inf.tu-dresden.de, bastian.voigt@inf.fu-berlin.de}
\title{Momentane Implementierung des Bezahlsystems für AN.ON}
\maketitle
\begin{abstract} Vorgestellt wird ein Bezahlsystem für einen
Mix\-kas\-kaden-basierten Anonymisierungsdienst. Es ermöglicht
eine Datenvolumen-abhängige Bezahlung. Das Bezahlsystem wurde unter dem
Gesichtspunkt der praktikablen Anwendbarkeit entworfen, \Dh es werden existierende Zahlungsmethoden genutzt
und die Qualität des Anonymisierungsdienstes wird nicht beeinträchtigt.
Ein eventueller Betrug einer Partei wird erkannt und kann mit Hilfe von
Nachweisen geahndet werden.
\end{abstract}
@endlatexonly
\section secEinfuehrung Einführung
"JAP" ist ein Mixkaskaden-basierter Dienst zur Anonymisierung von
HTTP-Verbindungen für den anonymen Zugriff auf das World Wide Web
[BeFK01]. Jeder Nutzer muss sich dazu ein gleichnamiges Programm als lokalen Proxy für
seinen Browser installieren. JAP dient als Schnittstelle zu sogenannten
Mixkaskaden, über die die Kommunikation zu den Zielservern im Internet (um-)geleitet wird.
Ein Mix ist im wesentlichen ein Server, der mehrfach
verschlüsselte Datenpakete empfängt, zwischenpuffert, umkodiert (durch
Entschlüsselung eine "Verschlüsselungsschale" entfernt) und
umsortiert wieder ausgibt [Chau81]. Werden mehrere Mixe in Form einer
statischen Kette hintereinandergeschaltet, so spricht man von
einer Kaskade.
Die Anonymität ist gewährleistet, solange wenigstens ein
Mix der Kaskade vertrauenswürdig ist. Dies gilt selbst unter der Annahme, dass
ein Angreifer alle anderen Mixe kontrolliert und sämtliche
Netzwerkverbindungen überwachen bzw. aktiv manipulieren kann (d. h.
Pakete löscht, verändert, hinzufügt etc.)
Betrachtet man eine Kaskade als "Black Box", so ist das Ziel, die Zuordnung von
eingehenden zu ausgehenden Nachrichten zu verbergen. Es bleibt jedoch beobachtbar,
wer den Dienst verwendet und an welche Empfänger Nachrichten gesendet werden.
Beispielsweise "sieht" ein Angreifer, wer welches "Bitmuster"
an den ersten Mix gesendet hat.
Jedem Mixbetreiber entstehen Kosten, die hauptsächlich durch das
Datenvolumen der zu bearbeitenden Mixpakete verursacht werden [BFRW02].
Eine faire Möglichkeit zur Deckung der anfallenden Kosten besteht darin, diese
auf die Nutzer umzulegen.
Bisherige Ansätze [FrJe98], [FrJW98],[BaNe99] nutzen zur Bezahlung der Mixpakete anonyme digitale
Münzen. Diese werden vom Nutzer bei einer Bank erworben und den Mixpaketen
mitgegeben. Da momentan keine Bank digitale Münzen anbietet, sind diese
Verfahren nicht praktikabel. Zudem hat eine Bezahlung mit digitalen Münzen
generell den Nachteil, dass die Verhinderung von Betrug durch mehrfaches
Ausgeben (engl. Doublespending) der selben Münze zum Teil erheblichen
zusätzlichen Kommunikationsaufwand verursacht.
Daher wird ein kontobasiertes Bezahlsystem vorgeschlagen, welches auf
vorhandene Zahlungsmethoden aufbaut und die Kommunikationsqualität der zu
anonymisierenden Verbindung nicht verschlechtert. Es berücksichtigt die
mehrseitigen Sicherheitsanforderungen aller involvierten Parteien (Nutzer,
Mixbetreiber, Banken). Dies wird durch digital signierte Nachweise erzielt.
\section secPayArchitecture Architektur des Bezahlsystems
Beim Anonymisierungsdienst JAP kann der Nutzer zwischen verschiedenen
Mixkaskaden frei wählen. Generell werden die Mixe einer Kaskade nicht
einzeln bezahlt, sondern eine Kaskaden-zentrale Abrechnungsinstanz (AI).
Auf Grund der statischen Struktur einer Kaskade (insbesondere gleiches Datenvolumen für alle Mixe)
kann diese Instanz das Geld auf die beteiligten Mixe verteilen.
Als Vorteil ergeben sich geringerer Aufwand und Komplexität des gesamten Bezahlsystems.
Die AI befindet sich vor dem ersten Mix und kennt daher gemäß Angreifermodell die Zuordnung
von abzurechnenden Datenpaketen zu Nutzern.
Der hohe Aufwand für ein anonymes (kontobasiertes) Bezahlsystem ist daher nicht notwendig,
zumal diese Verfahren (z. B. [LoMP94], [BüPf89]) selbst wieder
auf einen Anonymisierungsdienst zurückgreifen.
Der Nutzer besitzt unter einem Pseudonym ein
Guthabenkonto, von dem die Kosten abgebucht werden. Dieses muss er
zuvor mit Hilfe verfügbarer Zahlungsmethoden aufladen. Abhängig von der
gewählten Zahlungsmethode braucht der Nutzer seine Identität jedoch gegenüber dem
Geldinstitut und der Konto-verwaltenden Stelle nicht offenzulegen.
Damit er nicht bei jeder Mixkaskade ein separates
aufzuladendes Konto benötigt, verwaltet eine Anonymisierungsdienst-zentrale Bezahlinstanz (BI)
die Nutzerkonten. Der Nutzer bezahlt bei
ihr für den Dienst und erhält die Möglichkeit, ihn unter freier
Auswahl der Kaskaden zu nutzen. Von der BI erhalten die
Abrechnungsinstanzen der Mixkaskaden die Kontoinformationen und rechnen die
Kosten der Nutzer ab. Die Abrechnungsinstanzen haben eine (temporäre) Verbindung zur Bezahlinstanz.
@manonly
\begin{figure}[ht]
\begin{center}
\scalebox{0.5}{
\includegraphics{figs/bezahlarchitektur_paper.eps}
}
\caption{\it Architektur des Bezahlsystems }
\label{architektur}
\end{center}
\end{figure}
@endmanonly
\image html bezahlarchitektur_paper.png "Abbildung 1: Architektur des Bezahlsystems"
\image latex bezahlarchitektur_paper.png "Abbildung 1: Architektur des Bezahlsystems"
Das Bezahlsystem besteht somit aus den Komponenten:
Bezahlinstanz, Abrechnungsinstanzen und lokale Proxies der Nutzer (Abbildung @latexonly~\ref{architektur}@endlatexonly @htmlonly 1@endhtmlonly).
Um den Dienst einer Mixkaskade zu nutzen, muss sich der Nutzer mit seinem
Pseudonym gegenüber der AI authentisieren. Diese rechnet die Kosten seiner
gesendeten und empfangenen Mixpakete über sein Pseudonymkonto ab. Dazu
müssen die von der BI verwalteten Pseudonym- und Kontodaten des Nutzers bei
der AI vorliegen. Um Robustheit gegen Ausfälle der BI oder deren
Nichterreichbarkeit zu gewährleisten, sind die Authentisierung des Nutzers
und die Abrechnung seiner Mixpakete nicht von einer ständigen Erreichbarkeit
der BI abhängig. Bei einem Ausfall der Bezahlinstanz wäre andernfalls
der ganze Dienst bzw. die Abrechnung des Dienstes blockiert.
Die Abrechnung bzw. Zusammenführung der von den AIs übermittelten Kontostände
bei der BI stellt sicher, dass die AIs das Geld
für die geleisteten Dienste der Mixkaskaden erhalten. Gleichzeitig wird
verhindert, dass die AIs die Möglichkeit des Betruges haben, indem sie
Kosten eines Nutzers bei der BI abrechnen, die er nicht verursacht hat. Digitale Nachweise verhindern außerdem,
dass die BI betrügt und dienen zur Kostenkontrolle durch den Nutzer.
\section secPayProtocols Protokolle zwischen den Parteien
Generell erfolgt die Kommunikation zwischen den Beteiligten über konzelierte und integritätssichernde Verbindungen.
Alle Protokollschritte sind durch ein Authentifizierungsprotokoll abgesichert, so dass z. b.
man-in-the-middle- oder replay-Angriffe nicht möglich sind. Nachfolgend wird darauf nicht mehr explizit hingewiesen.
\subsection paraPayImpl1 Implemetierungsanmerkungen
Die Authentifizierung der BI erfolgt über die SSL gesicherte Verbindung. Der JAP überprüft dabei ob die Kommunikation
tatsächlich mit der BI erfolgt, dessen öffentliches Zertifikat der JAP besitzt.
Die Authentifizierung des JAP gegenüber der BI erfolgt mittels Challenge-Response Verfahren. Die BI sendet dazu die
nachfolgende Challenge:
@verbatim
Base64 koderierte Zufallszahlenfolge
@endverbatim
Beim Beginn einer Sitzung kann der JAP mittels HTTP POST Request an die URL /authenticate eine Challenge
anfordern. Dazu sendet er
im HTTP Body sein Kontozertifikat mit.
Als Response erwartet die BI eine Signatur über das Element \ (inklusive der Tags) vom JAP.
Die Signatur leistet der JAP
mittels des zu seinem Konto gehörenden privaten Schlüssels. Er sendet folgende XML Struktur an die BI:
@verbatim
Base64 koderierte Signature bzgl. der Challenge
@endverbatim
\subsection secPayJAPBIProto JAP-Bezahlinstanz-Protokoll
\subsubsection secPayJAPBIProtoAccountOpen Kontoanmeldung
Zur Kontoanmeldung generiert der JAP zuerst ein Schlüsselpaar
eines Signatursystems. Der private Schlüssel
bleibt dabei im Vertrauensbereich des Nutzers. Mit ihm authentisiert sich der
Nutzer gegenüber den Abrechnungsinstanzen und der Bezahlinstanz und
signiert unten näher erläuterte Kostenbestätigungen. Der öffentliche
Schlüssel wird als Nutzerpseudonym P an ein Konto bei der BI gebunden (Abbildung@latexonly~\ref{kontoanmeldung}@endlatexonly@htmlonly 2 @endhtmlonly).
@latexonly
\begin{figure}[ht]
\begin{center}
%\fboxsep7mm
\scalebox{0.485}{
\includegraphics{figs/kontoanmeldung.eps}}
\caption{\it Kommunikation bei der Kontoanmeldung}
\label{kontoanmeldung}
\end{center}
\end{figure}
@endlatexonly
\image html kontoanmeldung.png "Abbildung 2: Kommunikation bei der Kontoanmeldung"
Der JAP übermittelt zunächst den generierten öffentlichen Schlüssel.
Die BI erzeugt eine für sie eindeutige
Kontonummer KN und legt unter dieser ein Konto für den Nutzer an.
Der öffentliche Schlüssel und die Kontonummer werden zusammen von der BI
signiert und das resultierende Kontozertifikat
\f[
Z=\left(\textit{BI},P,\textit{KN},t_{creation},S_{BI}\right)
\f]
an den JAP
zurückgesendet. BI ist dabei ein eindeutiger Identifikator der Bezahlinstanz, SBI ist die
digitale Signatur
der BI über
BI, P, KN und tcreation. Der Zeitpunkt tcreation
gibt an, wann das Konto eröffnet wurde. Um ein "Fluten" der Datenbank mit unbenutzten Konten zu verhindern, werden
nicht aufgeladene Konten nach einer gewissen Zeit aus der Datenbank gelöscht.
\paragraph paraPayRegisterAccountImpl Implementierungsanmerkungen
Zu Kontoanmeldung ruft der JAP bei der BI die URL /register mittels POST Request auf. Im Body wird mittels
einer XML-Struktur der
öffentliche Schlüssel mitgeschickt, den der JAP mit dem Konto verküpfen möchte.
@verbatim
Base64 encoded Modulus Base 64 enocded Exponent
@endverbatim
Es folgt das oben beschriebene Challenge-Response Verfahren. Dazu sendet die BI im HTTP Reply-Body die XML \ Struktur.
Der JAP antwortet mittels POST Request an die URL /response. Im HTTP Request-Body befindet sich dabei die XML \ Struktur.
War die Authentifizierung erfolgreich, so wird ein neues Konto angelegt. Dazu wird eine zufällige 12stellige Kontonummer generiert.
Anschliessend wird ein Kontozertifikat generiert:
@verbatim
123456789012
... public key xml data (siehe oben)
YYYY-MM-DD HH:MM:SS eindeutige ID der BI
... signature der BI unter die Daten
@endverbatim
In der Datenbanktabelle ACCOUNTS wird ein neuer Eintrag mit der erzeugten Kontonummer,
dem Zeitstempel der Erzeugung, sowie dem zugehörigen öffentlichen Schlüssel angelegt. Die Werte DEPOSIT und SPENT
werden auf Null gesetzt.
Der Wert DEPOSITVALIDTIME wird auf den Wert von CREATIONTIME gesetzt.
Das Kontozertifikat wird an den JAP gesendet. Dieser speichert es zusammen mit dem zugehörigen geheimen Schlüssel als
Zugangsvorraussetzung zu dem Konto.
\subsubsection secPayOptions Bezahlmöglichkeiten
Will der JAP von der Bezahlinstanz erfahren, welche Zahlungsverfahren diese zur Aufladung eines Kontos akzeptiert, so sendet er einen GET-Request
mit dem URL /paymentoptions an die Bezahlinstanz. Diese antwortet mit einer XML-Struktur der folgenden Form:
@verbatim
...akzeptierte Bezahlwährung...Überschrift...Genaue Information über das Zahlungsverfahren...Zusatzinformationen wie z.B. Bankverbindung oder PayPal-Link......
@endverbatim
Dabei können die Tags Currency, Heading, DetailedInfo, ExtraInfo und input mehrfach vorkommen. Außer für den Tag Currency müssen dabei unterschiedliche Sprachkürzel im Attribut lang angegeben werden.
Der JAP kann anhand der übermittelten Informationen beim Aufladevorgang einen Dialog mit den entsprechenden Informationen anzeigen. Enthält die von der Bezahlinstanz übermittelte XML-Strukur input-Tags (nur bei passiven Verfahren), so muss der JAP die geforderten Informationen vom Benutzer abfragen und an die Bezahlinstanz übermitteln (Anmerkung: Die Art der Übermittlung muss noch spezifiziert werden).
\subsubsection secPayChargeAccount Kontoaufladung
Zur Dienstnutzung muss das angemeldete Pseudonymkonto aufgeladen werden. Der
JAP erfragt dafür bei der BI eine Überweisungsnummer ÜN als einmal gültiges
Transaktionspseudonym. Die Überweisungsnummer wird durch die BI generiert,
dort vermerkt und dem JAP zusammen mit der Pseudonymkontonummer und dem aktuellen Gmax von ihr
signiert übermittelt. Pro Konto können dabei nicht mehrere Aufladetransaktionen parallel durchgeführt werden.
Der Nutzer muss nun die Zahlung unter Angabe der Überweisungsnummer mit
existierenden Zahlungsmethoden durchführen. Nach Eingang der Zahlung bei der
Bezahlinstanz lädt diese das zugehörige Pseudonymkonto auf (Abbildung@latexonly~\ref{auflad_aktiv}@endlatexonly @htmlonly 3 @endhtmlonly).
@latexonly
\begin{figure}[ht]
\begin{center}
\scalebox{0.47}{
\includegraphics{figs/kontoauflad_extern.eps}
}
\caption{\it Kommunikation bei der Kontoaufladung}
\label{auflad_aktiv}
\end{center}
\end{figure}
@endlatexonly
\image html kontoaufladextern.png "Abbildung 3: Kommunikation bei der Kontoaufladung"
Als Nachweis der Kontoaufladung, kann der Nutzer nach Eingang des Geldes eine Kontostandsinformation erfragen.
\paragraph paraChargeAccountImpl Implementierungsanmerkungen
Der JAP fordert eine Transaktionsnummer mittes HTTP GET-Request an die URL /charge an.
Dazu erfolgt zunächst das oben beschriebenen Challenge Response Verfahren. War die Authentifizierung erfolgreich, so generiert die BI
eine neue zufällige 12stellige Transaktionsnummer.
Diese wird gemäß dem in im c't-Magazin 4/97 ("Blütenrein") beschriebenen Diedergruppen-Prüfsummen-Verfahren erzeugt.
Die BI generiert nachfolgendes Transaktionszertifikat:
@verbatim
... ... ... Gültigkeitsende der Transaktionsnummer Datum, an dem das Zertifikat vom JAP empfangen wurde
... Signature der BI
@endverbatim
Die BI erzeugt ausserdem einen Eintrag in der Datenbanktabelle TRANSFERS. Der Wert USED wird
dabei auf false gesetzt.
Die BI überträgt nun das oben erstellte Transaktionszertifikat an den Nutzer.
\subsubsection secBalance Kontostandsabfrage
Wünscht der Nutzer eine aktuelle Kontostandsinformation, so sendet er eine entsprechende Anfrage an die BI.
Er erhält von ihr eine signierte Bestätigung KBN seines
aktuellen Kontostandes:
\f[
\textit{KBN}=\left(\textit{KN},G_{max},K_{Gesamt},t,S_{BI}\right)
\f]
KN ist die Kontonummer des Kontos, Gmax entspricht der Gesamtsumme des
auf das Konto eingezahlten Geldes, KGesamt ist die Gesamtsumme der verursachten Kosten,
t ist ein Zeitstempel und SBI ist die
digitale Signatur der BI über KN, Gmax, KGesamt und t.
Damit ergibt sich das Guthaben G=Gmax-KGesamt, welches dem
Nutzer noch zur Verfügung steht.
Die BI muss gleichzeitig die angefallenen Kosten KGesamt mit Kostenbestätigungen
nachweisen. Dazu werden neben der Kontobestätigung KBN auch die
entsprechenden Kostenbestätigungen B übermittelt. Die Kostenbestätigungen
sind vom Nutzerpseudonym unterschriebene Erklärungen, mit denen es den
Abrechnungsinstanzen bestätigt, den Dienst der jeweiligen Mixkaskade im
angegebenen Umfang genutzt zu haben. Diese Erklärungen werden in Abschnitt
\ref secAIBI ausführlich erläutert.
Die signierte Kontobestätigung KBN gibt dem Nutzer unter der
angegebenen Kontonummer das Recht, den Anonymisierungsdienst bis zur mit
Gmax angegebenen Kostenhöhe zu nutzen. Diese von der BI signierte
Bestätigung muss lokal beim Nutzer bzw. dessen JAP gespeichert werden. Sie
dient als Nachweis der Kontoaufladung. Bis zum Erhalt der Kontobestätigung
nach einer Kontoaufladung muss sich der Nutzer den Nachweis der
Zahlung (Kontoauszug o. ä.) und das Zertifikat, welches die
Überweisungsnummer mit der Kontonummer verbindet, aufbewahren. Enthält die BI
die Kontobestätigung KBN dem Nutzer vor, kann der Nutzer damit die
Kontoaufladung und somit sein Dienstnutzungsrecht gegenüber Dritten
nachweisen.
Um ein mehrmaliges Aufladen eines Pseudonymkontos zu ermöglichen, gilt für die
Kontobestätigungen neben der oben genannten Nachweispflicht der Kosten KGesamt folgende Regel:
\remark Die Kontobestätigung mit einem größeren Wert Gmax ist die aktuell
gültige Bestätigung und entwertet eine mit einem
kleineren Wert Gmax.
Speichert der Nutzer diesen Nachweis nicht, kann die Bezahlinstanz beim
Nachweis der Dienstnutzung eine Kontobestätigung mit kleinerem Gmax
generieren und als aktuell präsentieren.
\paragraph paraBalanceImpl Implementierungsanmerkungen
Der JAP führt zunächst die Challenge-Response Authentikation durch. Anschliessend sendet er einen HTTP GET-Request
an die URL /balance. Daraufhin antwortet die BI mit einem aktuellen Kontoauszug,
der das auf dem Konto befindlich Gesamtguthaben und die Gesamtkosten umfasst und die
letzen vom JAP unterschriebenen Kostenbestätigungen, die von den AIs bereits abgerechnet wurden.
Dazu wird folgende XML Struktur versendet:
@verbatim
............... //Unterschrift der BI
...
//Kostenbestätigungen, die
von den einzelnen AI's
abgerechnet wurden
......
@endverbatim
\paragraph paraJAPBISec Sicherheitsbetrachtungen
Behauptet der Nutzer ein höheres Guthaben Gmax zu besitzen, als die BI zugibt,
so muss er dies beweisen, indem er entweder folgendes vorlegt:
1. ein gültiges Kontozertifikat, für das er den privaten Schlüssel besitzt
und eine zu dem Konto passende, gültige Kontobestätigung mit dem behaupteten Gmax
oder
2. ein gültiges Kontozertifikat, für das er den privaten Schlüssel besitzt, eine zu dem Konto passende,
gültige Kontobestätigung mit einem G'max, ein passendes, gültiges Zertifikat,
das die Zuordnung von einer Überweisungsnummer zu seinem Konto bestätigt und Beweise des Zahlungssystems,
dass er eine Überweisung in Höhe von G'=Gmax-G'max
unter Angabe der Überweisungsnummer auf das Konto der BI getätigt hat.
Der erste Fall ist trivial. Im zweiten Fall kann die BI nicht betrügen, da auf Grund der vorgelegten
Beweise klar ist, dass
der Nutzer mindestens ein Guthaben von Gmax besitzt.
Gleichzeitig kann auch der Benutzer nicht betrügen, da der Versuch eines mehrmaligen Vorlegens desselben
Überweisungsnummernzertifikats (inkl. Beweis des Zahlungseingangs) durch die Verkettung von altem Kontostand
und Überweisungsnummer erkannt wird.
\subsection secJAPAI JAP-Abrechnungsinstanz-Protokoll
Will der Nutzer eine Mixkaskade nutzen,
authentisiert sich sein JAP gegenüber der AI mit dem Kontozertifikat Z seines
Nutzerpseudonyms und übermittelt eine Kontobestätigung KBN.
Mit Hilfe der
Kontobestätigung kann die AI die Liquidität des Nutzers
einschätzen. Enthält die Kontobestätigung einen älteren Zeitstempel,
kann die AI von der BI einen aktuellen Kontostand anfordern
(vgl. Abschnitt \ref secAIBI).
Ist auf dem Pseudonymkonto Guthaben vorhanden, antwortet die AI mit dem
"Kostenanschlag" der Mixkaskade. Dieser enthält
Informationen über den Mixkaskadennutzungspreis (z. B. Preis pro Mixpaket)
und die Länge des Bestätigungsintervalls. Dies gibt an,
nach wieviel nicht bestätigten verursachten Kosten die AI eine Bestätigung des aktuellen Kostenstandes spätestens
erwartet.
Wurde die Mixkaskade schon einmal genutzt, übermittelt die
AI zusätzlich die vom Nutzerpseudonym zuletzt gesendete Kostenbestätigung
\f[
B=(\textit{ID},\textit{KN},K,S_{P})
\f]
die aus der eindeutigen Kennung ID der
Abrechnungsinstanz, der Kontonummer KN des Pseudonymkontos und dem
bestätigten Kostenkontostand K des Pseudonyms bei der AI besteht. SP ist die
digitale Signatur des Nutzerpseudonyms P über ID, KN und K. Mit der
Signatur bestätigt das Nutzerpseudonym P, die
Kosten K bei der AI bzw. deren Mixkaskade verursacht zu haben. Die AI kann
mit der Kostenbestätigung B die Kosten K bei der BI vom Guthaben des
Pseudonymkontos KN abrechnen. (siehe Abschnitt \ref secAIBI ).
\remarks Der Kostenstand K ist kumulativ und gibt stets die Gesamtsumme der bei der
Mixkaskade durch das Pseudonym verursachten Kosten an.
Auf Grund der
Bestätigung von Gesamtkosten, ist ein Betrug durch Doublespending von
Kostenbestätigungen durch die AI nicht möglich.
Während der Dienstnutzung sendet und empfängt der Nutzer Mixpakete. Durch den
übermittelten Kostenanschlag und die letzte Kostenbestätigung weiß der Nutzer,
wann er welche Kostenbestätigung der AI übermitteln muss (Abbildung@latexonly~\ref{japaiprotpic}@endlatexonly @htmlonly 4 @endhtmlonly).
@latexonly
\begin{figure}[ht]
\begin{center}
\scalebox{0.484}{
\includegraphics{figs/jap-ai-prot.eps}
}
\caption{\it Kommunikation zwischen JAP und Abrechnungsinstanz}
\label{japaiprotpic}
\end{center}
\end{figure}
@endlatexonly
\image html japaiproto.png "Abbidlung 4: Kommunikation zwischen JAP und Abrechnungsinstanz"
Zur Minimierung von Übertragungs-
und Rechenaufwand wird nicht jedes
Bestätigungsintervall durch eine signierte Erklärung bestätigt, sondern
das in [Ped97] beschriebene Tickpayment-Verfahren genutzt.
In jeder signierten Bestätigung BS ist zusätzlich der Endwert einer
Tickfolge enthalten. Eine Tickfolge ist eine Folge von Werten, die der Nutzer
ausgehend von einem zufälligen Wert mit einer Einwegfunktion generiert und
gespeichert hat. Der Nutzer übermittelt die
Werte der Folge in umgekehrter Reihenfolge als Bestätigungen BH=(h) an die AI.
Die AI kann die Werte prüfen, indem sie die Einwegfunktion auf den neu
erhaltenen Wert anwendet und das Ergebnis mit dem davor erhaltenen vergleicht.
Die signierte Bestätigung BS wird um den Endwert hend der
Tickfolge, die Länge l der Folge und den Tickkostenwert w erweitert, der den Wert angibt, der durch
einen Tickwert der Tickfolge bestätigt wird:
\f[
B_{S}=(\textit{ID},\textit{KN},K,h_{end},l,w,S_{P})
\f]
Durch diese signierte
Bestätigung BS und einen Tickwert h wird ein Kostenstand
Kresult bestätigt. Dieser ergibt sich aus dem in der signierten
Bestätigung BS enthaltenen Kostenstand K, dem Kostenwert w
und dem Wert
k\<=l, der für die Anzahl der Einwegfunktionsaufrufe steht, um von h zu dem
Ergebnis hend zu kommen:
\f[
K_{result}=K+k\cdot w
\f]
\note Ist f(x) die Einwegfunktion, so
gilt fk(h)=hend.
Sind die
generierten Werte einer Tickfolge im JAP aufgebraucht, sendet er eine neue
signierte Bestätigung, die den aktuellen Kostenkontostand und den
Tickfolgenendwert einer neu generierten Tickfolge enthält. Die alte
Bestätigung und den zugehörigen letzten Tickwert kann die AI löschen.
\subsubsection paraJAPAIImpl Implementierungsanmerkungen
Momentan werden zur Bestätigung der Inanspruchnahme des Dienstes lediglich vereinfachte Kostenbestätigungen
ohne Tickfolge verwendet.
Dies bedeutet das jede dieser vereinfachten Kostenbestätigungen durch den Kontoinhaber unterschrieben ist.
Die zugehörige XML Struktur ist wie folgend:
@verbatim
... ... ... eindeutige ID der BI
... Signature des Kontoinhabers
@endverbatim
Bei der Anmeldung an die Kaskade erfährt der JAP, ob die Dienstleistung der Kaskade bezahlt werden muss.
Ist dies der Fall, so
läuft anschliessend foglendes Protokoll zwischen JAP und AI ab (der Aufbau einer gesicherten Verbindung zwischen
JAP und AI wird dabei nicht betrachtet):
-# Der JAP sendet sein Kontozertifikat (siehe oben)
-# Die AI sendet ein Challenge (siehe oben)
-# Der JAP sendet ein Response (siehe oben)
-# Die AI sendet die letzte vom JAP erhaltene Kostenbestätigung. Sollte der JAP sich zumn ersten mal
bei der Kaskade anmelden, so wird eine leere Kostenbestätigung \ gesendet.
Während der Benutzung des Dienstes durch den JAP sendet der Mix an diesen Aufforderungen zur Quittierung
der erbrachten Dienstleistung:
@verbatim
optional; //Anforderung eines
aktuellen Kontoauszuges
Zeitstempel // der Kontoauszug
muss neuer als
das angegeben
Datum sein
optional //Kostenbestätigung die
unterschrieben werden soll
(siehe oben)
... // eindeutiger ID der AI
... ...
@endverbatim
Das Element \ signalisiert dem JAP, daß die AI einen aktuellen Kontoauszug erwartet.
Auf eine solche Quittierungsaufforderung hin sendet der JAP die Kostenbestätigung unterschrieben an die AI zurück.
Die AI speichert
die jeweils aktuellste Kostenbestätigung pro Konto in der Tabelle COSTCONFIRMATIONS.
\paragraph paraJAPAISec Sicherheitsbetrachtungen
Versucht der Nutzer zu betrügen, indem er keine oder ungültige Bestätigungen schickt, blockiert die AI
die Paketweiterleitung solange, bis der Nutzer die gewünschten Bestätigungen
übermittelt. Dies bedeutet, dass eine Mixkaskade in Vorleistung tritt. Der Nutzer
erreicht im Betrugsfall damit einen Vorteil gegenüber der AI, der jedoch den
Umfang des durch die AI gewählten Bestätigungsintervalls nicht übersteigt.
Die AI kann versuchen zu betrügen, indem sie zu Beginn eine Kostenbestätigung B sendet,
die höhere Kosten enthält, als durch den Nutzer bisher verursacht. Die Manipulation erkennt
der Nutzer jedoch, da diese Bestätigung durch ihn selbst signiert sein muss.
Da neben der AI auch der JAP des Nutzers das gesendete bzw. empfangene Datenvolumen messen kann,
ist es auch nicht möglich, dass die AI Bestätigungen anfordert, obwohl das Bestätigungsintervall
noch gar nicht vorüber ist.
\subsection secAIBI Abrechnungsinstanz-Bezahlinstanz-Protokoll
Die Abrechnungsinstanzen kontaktieren in kurzfristigen Abständen die
Bezahlinstanz zur Kostenbestätigungsabrechnung. In längerfristigen
Intervallen, z. b. einmal im Monat, wird die BI von den AIs zur Geldabrechnung
kontaktiert.
\subsubsection secSettle Abrechnung der Kostenbestätigungen
Die AI kontaktiert in regelmäßigen Abständen die BI und rechnet die von den
Nutzern erhaltenen Kostenbestätigungen B ab. Dazu übermittelt die AI die
vom Nutzerpseudonym signierte Bestätigung
\f[
B_S=(\textit{ID},\textit{KN},K,h_{end},l,w,S_{P})
\f]
zuzüglich des zugehörigen zuletzt erhaltenen Tickwertes h an die BI.
Entsprechend dieser Bestätigung wird die neue Gesamtsumme der angefallenen Kosten KGesamt
des zugehörigen
Pseudonymkontos berechnet. Dazu wird das neue KGesamt aus den
von den anderen AIs abgerechneten Kostenkontoständen K und dem neuen durch
die Bestätigung B und dem Tickwert h bestätigten Kostenkontostand K der
abrechnenden AI berechnet:
\f[
K_{Gesamt}=\sum_{i}K_{i}
\f]
Anschließend sendet die BI einen neuen
Kontoschnappschuss
\f[
\textit{KSA}=(\textit{ID},\textit{KN},G_{max},K_{Gesamt},K,t,S_{{BI}})
\f]
des Pseudonymkontos
KN signiert an die abrechnende AI zurück (siehe Abbildung@latexonly~\ref{abrech}@endlatexonly @htmlonly 5 @endhtmlonly).
@latexonly
\begin{figure}[ht]
\begin{center}
\scalebox{0.465}{
\includegraphics{figs/kostenabrechnen-prot.eps}
}
\caption{\it Kommunikation beim Abrechnen der Kostenbestätigungen}
\label{abrech}
\end{center}
\end{figure}
@endlatexonly
\image html kostenabrechnen-prot.png "Abbildung 5: Kommunikation beim Abrechnen der Kostenbestätigungen"
Mit diesem unterschriebenen Kontoschnappschuss erkennt die BI den
Kostenkontostand K des Pseudonymkontos KN bei der AI ID
zum Zeitpunkt t an. Der von der BI unterzeichnete Schnappschuss dient der
AI als Nachweis der Dienstabrechnung.
Die BI speichert sich für jedes Pseudonymkonto und für jede AI den
zuletzt bestätigten Kostenkontostand K und die dafür von der AI
präsentierten Bestätigungen B. Mit diesen Bestätigungen muss die BI den
Dienstnutzungsnachweis gemäß Abschnitt \ref secPayJAPBIProto führen.
Bei der Abrechnung besteht die Gefahr, dass das Guthaben des
Pseudonymkontos nicht mehr die erforderliche Höhe hat, um der AI die
Abrechnung zu bestätigen. Der AI gehen die Ausgaben verloren, die nicht durch
das verbliebene Guthaben gedeckt sind. In diesem Fall hat der Nutzer
zwar nachweisbar betrogen, eine Schadensregulierung kann jedoch nicht
garantiert werden, da der Nutzer bei Verwendung einer anonymen Zahlungsmethode (z. b. Prepaid-Karte)
gegenüber der Bezahlinstanz anonym bleiben kann.
Um die Gefahr eines Schadens zu verringern, sind die Kostenbestätigungen der
Nutzerpseudonyme rechtzeitig bei der BI abzurechnen. Dabei gilt folgende
Strategie:
Je geringer das Guthaben des Nutzers ist,
bzw. je älter die Abrechnungsbestätigung der Bank ist, desto kürzer ist das
Abrechnungsintervall für die Kostenbestätigungen durch die AI zu wählen.
\paragraph paraSettleImpl Implementierungsanmerkungen
Momentan wird nur die Abrechnung der durch den Nutzer verursachten Kosten implementiert.
Das Auszahlen von Geld hingegen nicht.
Zur Abrechnung der Kosten sendet die AI an die BI einen HTTP POST-Request mit der URL /settle.
Dabei wird im Request-Body folgende XML Struktur mitgesendet:
@verbatim
....
@endverbatim
Die BI aktuallisert die Einträge in der Tabelle COSTCONFIRMATIONS entsprechend
der aktuell erhaltenen Kostenbestätigungen.
\paragraph paraNewBalance Kontostandsaktualisierung
Wünscht die AI einen aktuellen Kontoschnappschuss KSA eines
Nutzerpseudonymkontos, kann sie diesen von der BI anfordern --- auch ohne eine
Kostenbestätigung B des Nutzerpseudonyms abrechnen zu müssen.
Die Kommunikation verläuft analog zur Kostenabrechnung mit dem Unterschied,
dass anstelle der Kostenbestätigung B die Kontobestätigung KBN
an die BI übermittelt wird. Die BI antwortet wie bei der Kostenabrechnung
mit einem aktuellen Kontoschnappschuss KSA des Pseudonymkontos.
\paragraph paraGetMoney Geldauszahlung an die Abrechnungsinstanzen
Die Auszahlung von Geld durch die BI an die AI ID beginnt letztere durch
Übermittelung einer Liste (KN1,...,KNn)
mit Kontonummern,
für deren Kostenkontostände (KKN1,...,KKNn)
sie Geld ausgezahlt bekommen möchte. Die BI
übermittelt eine Überweisungsnummer, unter der sie die Geldüberweisung
durchführen wird sowie die Höhe des auszuzahlenden Geldbetrages.
Das Geld kann die BI den AIs mit klassischen Zahlungsmethoden überweisen. Als
Bestätigung des Geldempfangs übermitteln die AIs eine signierte
Kostenauszahlungsbestätigung
KAB an die BI (Abbildung@latexonly~\ref{geldabrech}@endlatexonly @htmlonly 6 @endhtmlonly).
@latexonly
\begin{figure}[ht]
\begin{center}
\scalebox{0.473}{
\includegraphics{figs/geldabrechnen-prot.eps}
}
\caption{\it Kommunikation bei der Geldabrechnung}
\label{geldabrech}
\end{center}
\end{figure}
@endlatexonly
\image html geldabrechnen-prot.png "Abbildung 6: "Kommunikation bei der Geldabrechnung"
Die Kostenauszahlungsbestätigung KAB ist die von der AI signierte Liste der ausgezahlten
Kostenkontostände der Pseudonymkonten. Leere Kostenkontostände sind
in dieser Bestätigung nicht enthalten.
\f[
KAB=(\textit{ID},\{\textit{KN}_{1},K_{\textit{KN}_{1}}\},...,\{\textit{KN}_{n},K_{\textit{KN}_{n}}\},S_{\textit{ID}})
\f]
ID ist die
Kennung der AI, KNi ist die Kontonummer und
KKNi der
Kostenkontostand K des Pseudonymkontos KNi bei der AI ID.
SID ist die digitale
Signature der Abrechnungsinstanz ID über ID und alle übertragenen
KNi
und KKNi. Damit bestätigt die AI von der BI für
die angegebenen
Kostenstände der Pseudonymkonten Geld empfangen zu haben.
Diese signierte Bestätigung speichert sich die BI, bis sie eine
Kostenauszahlungsbestätigung mit höheren oder gleichen Kostenständen der
Pseudonymkonten von der AI erhält.
Die AI übermittelt bei der nächsten Geldauszahlung der BI eine neue
Bestätigung der verrechneten Kontostände. In der neuen Bestätigung müssen alle
Konten der Vorgängerbestätigung enthalten sein, damit die BI die vorherige
Bestätigung löschen kann.
\paragraph paraSecAI Sicherheitsbetrachtungen
Betrügt eine AI, indem sie Geld von der BI für nicht erbrachte Leistungen erhalten will,
so hat die AI zwei Möglichkeiten, dies zu versuchen:
1. Sie versucht, Kostenbestätigungen für nicht erbrachte Leistungen abzurechnen.
Dabei kann sie jedoch nicht die Bestätigungen BS fälschen,
da diese durch den Nutzer signiert sind. Eine AI kann auch keinen Tickwert h berechnen,
so dass fl(h)=hend gilt.
Dies beruht auf den Eigenschaften der zugrundeliegenden Hashfunktion f.
Versucht die AI mehrmals die selbe Kostenbestätigung B abzurechnen (Doublespending),
so wird dies durch die BI erkannt, da die Kosten K kumulativ geführt werden und nach der ersten
Abrechnung
von B somit bei der BI ein größeres K gespeichert ist, als in der Bestätigung B
angegeben.
2. Die AI versucht, bei der Geldauszahlung zu betrügen. Dabei kann sie nicht einfach beliebige
Kosten K angeben, da die BI nur Kontoschnappschüsse KSA akzeptiert,
die von ihr zuvor digital signiert wurden. Auch das mehrmalige Abrechnen wird erkannt,
da die AI der BI bestätigen muss, für welche Kosten sie bereits Geld erhalten hat.
Diese Bestätigung speichert sich die BI. Verweigert die AI das Senden der Bestätigung,
so kann die BI mit Hilfe von durch das Zahlungssystem generierten Beweisen gegenüber Dritten belegen,
dass sie für die abgerechneten Kosten bezahlt hat. Damit hat die AI betrogen.
Versucht die BI zu betrügen, indem sie der AI die Bezahlung angefallener Kosten bzw.
das Senden von Kostenbestätigungen verweigert, so kann die AI mit den von der BI bzw.
den Nutzer in der Vergangenheit zugesandten Bestätigungen gegenüber Dritten die ihr
zustehende Bezahlung nachweisen.
\section secConclusion Zusammenfassung und Ausblick
Es wurde ein Abrechnungssystem für einen Anonymisierungsdienst vorgestellt, das sich im Gegensatz zu den
bekannten Verfahren mit heute verfügbaren Bezahlmöglichkeiten umsetzen lässt.
Durch die Verwendung von digital signierten Belegen wird Schutz vor Betrug für
jede beteiligte Partei erreicht. Da die Guthaben und angefallenen Kosten
jeweils nur kumulativ geführt werden, werden Probleme mit Doublespending bzw.
einer umfangreichen Speicherung von bereits abgerechneten Quittungen
vermieden.
Das vorgeschlagene System wird momentan implementiert und in den vorhandenen
Anonymisierungsdienst JAP integriert. Anschließend soll eine Evaluierung
(ein "Proof of Concept" durchgeführt werden. Dies wird unter
Beteiligung der "echten" Nutzer des Dienstes geschehen (allerdings
zunächst unter Verwendung von "Spielgeld").
@manonly
\begin{thebibliography}{9999999}
\bibitem[BaNe99]{bezahl3} Matthias Baumgart, Heike Neumann. \textit{Bezahlen von Mix-Netz-Diensten}. Verläßliche IT-Systeme -- VIS 1999, Vieweg-Verlag, 1999
\bibitem[BeFK01]{webmix}
Oliver Berthold, Hannes Federrath, Stefan Köpsell. \textit{Web MIXes: A system for anonymous and unobservable Internet access}.
in: Hannes Federrath (Ed.): Designing Privacy Enhancing Technologies. Proc. Workshop on Design Issues in Anonymity and Unobservability,
LNCS 2009, Springer-Verlag, Heidelberg 2001, 115--129.
\bibitem[BFRW02]{leipzig} Thomas Butzlaff, Florian Jäger, Björn Rober, David Weber, Andreas Wilm. \textit{Praxisprojekt: JAP -- Anonymität im Internet}. Handelshochschule Leipzig, Dezember 2002.
\bibitem[B"uPf89]{anonNummernkonto} Holger B"urk, Andreas Pfitzmann. \textit{Digital Payment Systems Enabling Security and Unobservability}. Computers \& Security 8/5, 1989, 399--416.
\bibitem[Chau81]{Chaum81}
David Chaum. \textit{Untraceable Electronic Mail, Return Addresses, and Digital
Pseudonyms}. Communications of the ACM 24/2, 1981, 84--88.
\bibitem[FrJe98]{bezahl1} Elke Franz, Anja Jerichow. \textit{A Mix-Mediated Anonymity Service and Its Payment}. ESORICS '98 (5th European Symposium on Research in Computer Security), Louvain-la-Neuve, LNCS 1485, Springer, Berlin, 1998, 313--327.
\bibitem[FrJW98]{bezahl2} Elke Franz, Anja Jerichow, Guntram Wicke. \textit{Payment Scheme for Mixes Providing Anonymity}. IFIP Working Conference on Electronic Commerce 98, LNCS 1402, Springer, Berlin 1998, 94--108.
\bibitem[LoMP94]{anonKredit} S. Low, N. Maxemchuk, and Sanjoy Paul. \textit{Anonymous credit cards}. 2nd ACM Conference on Computer and Communications Security, Fairfax, Virginia, ACM Press, 1994, 108--117.
\bibitem[Ped97]{pedersen} Torben P. Pedersen. \textit{Electronic Payments of Small Amounts}. Security Protocols 96, LNCS 1189, Springer, Berlin, 1997, 59--68.
\end{thebibliography}
\appendix
@endmanonly
\subsection secLiteratur Literatur
[BaNe99] Matthias Baumgart, Heike Neumann. Bezahlen von Mix-Netz-Diensten. Verläßliche IT-Systeme -- VIS 1999, Vieweg-Verlag, 1999
[BeFK01] Oliver Berthold, Hannes Federrath, Stefan Köpsell. Web MIXes: A system for anonymous and unobservable Internet access.
in: Hannes Federrath (Ed.): Designing Privacy Enhancing Technologies. Proc. Workshop on Design Issues in Anonymity and Unobservability,
LNCS 2009, Springer-Verlag, Heidelberg 2001, 115--129.
[BFRW02] Thomas Butzlaff, Florian Jäger, Björn Rober, David Weber, Andreas Wilm. Praxisprojekt: JAP -- Anonymität im Internet. Handelshochschule Leipzig, Dezember 2002.
[BüPf89] Holger Bürk, Andreas Pfitzmann. Digital Payment Systems Enabling Security and Unobservability. Computers \& Security 8/5, 1989, 399--416.
[Chau81] David Chaum. Untraceable Electronic Mail, Return Addresses, and Digital
Pseudonyms. Communications of the ACM 24/2, 1981, 84--88.
[FrJe98] Elke Franz, Anja Jerichow. A Mix-Mediated Anonymity Service and Its Payment. ESORICS '98 (5th European Symposium on Research in Computer Security), Louvain-la-Neuve, LNCS 1485, Springer, Berlin, 1998, 313--327.
[FrJW98] Elke Franz, Anja Jerichow, Guntram Wicke. Payment Scheme for Mixes Providing Anonymity. IFIP Working Conference on Electronic Commerce 98, LNCS 1402, Springer, Berlin 1998, 94--108.
[LoMP94] S. Low, N. Maxemchuk, and Sanjoy Paul. Anonymous credit cards. 2nd ACM Conference on Computer and Communications Security, Fairfax, Virginia, ACM Press, 1994, 108--117.
[Ped97] Torben P. Pedersen. Electronic Payments of Small Amounts. Security Protocols 96, LNCS 1189, Springer, Berlin, 1997, 59--68.
\section secAnhnag Anhang
\subsection secTables A. Datenbanktabellen
\subsubsection secKontoTable Kontotabelle
@verbatim
Name: ACCOUNTS
Felder:
ACCOUNTNUMBER (64 Bit Integer; BIGINTEGER) - Kontonummer
CREATIONTIME (Zeitstempel; TIMESTAMP) - Zeitpunkt der Kontoeröffnung
XMLPUBLICKEY (Zeichenfolge; VARCHAR) - XML-codierter öffentlicher Kontoschlüssel
DEPOSIT (64 Bit Integer; BIGINTEGER) - Gesamtguthaben aller Einzahlungen
SPENT (64 Bit Integer; BIGINTEGER) - Kummulierte Kosten bei allen Kaskaden
DEPOSITVALIDTIME (Zeitpunkt; TIMESTAMP) - Gültigkeitsende des Guthabens
@endverbatim
\subsection secTransTable Transaktionsnummern
@verbatim
Name: TRANSFERS
Felder:
ACCOUNTNUMBER (64 Bit Integer; BIGINTEGER) - Kontonummer
TRANSFERNUMBER (64 Bit Integer; BIGINTEGER) - Transaktionsnummer
DEPOSIT (64 Bit Integer; BIGINTEGER) - Gesamtguthaben aller Einzahlungen
VALIDTIME (Zeitpunkt; TIMESTAMP) - Gültigkeitsende der Transaktionsnummer
USED (Boolean; BOOLEAN) - gibt an ob die Transkationsnummer bereits
für Zahlungen verwendet wurde
USEDTIME (64 Bit Integer; BIGINTEGER) - Gibt das Datum an, an dem die Transaktionsnummer
zur Zahlung benutzt wurde
@endverbatim
\subsection secBITable BI Kostenbestätigungen pro Konto und Kaskade
@verbatim
Name: COSTCONFIRMATIONS
Felder:
AiID (Zeichenfolge; VARCHAR) - Eindeutige Bezeichnung der AI
ACCOUNTNUMBER (64 Bit Integer; BIGINTEGER) - Kontonummer
TRANSFERREDBYTE (64 Bit Integer; BIGINTEGER) - bestätigte transferrierte Bytes durch die
Inanspruchnahme des Dienstes
XMLCC (Zeichenkette;VARCHAR(2000)) - letzte unterschriebene Kostenbestätigung
@endverbatim
\subsection secAITAble AI Kostenbestätigungen
@verbatim
Name: COSTCONFIRMATIONS
Felder:
ACCOUNTNUMBER (64 Bit Integer; BIGINTEGER) - Kontonummer
TRANSFERREDBYTE (64 Bit Integer; BIGINTEGER) - bestätigte transferrierte Bytes durch die
Inanspruchnahme des Dienstes
XMLCC (Zeichenkette;VARCHAR(2000)) - letzte unterschriebene Kostenbestätigung
@endverbatim
*/