/** \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 */