This is an old revision of the document!


uPay: Bargeldloses Bezahlen im Club

Das System basiert auf einzelnen Tokens, die einen bestimmten Wert haben. Dem Schatzmeister wird ein System an die Hand gegeben um neue Tokens zu erstellen und dem Empfaenger zu uebermitteln.

Werden die Tokens an den dafuer vorgesehenen Stellen (Matemat, RepRap, …) verwendet werden sie in der (zentralen) Datenbank als benutzt markiert und nichtmehr akzeptiert. Ferner wird geloggt was wann verkauft wurde um bedarfsgerecht einkaufen zu koennen.

  • System befindet sich im Testbetrieb
    • Tokens koennen von bsx durch Bezahlung in bar erworben werden
    • Bezahlung nur mit USB-Stick
    • Getraenketaste so lange druecken bis die Motoren im Matematen anlaufen!
      • wird mittelfristig durch Zusatzhardware fuer Matematen behoben

tech_status Momentan befindet sich auf dem Embeddedrechner im Matemat ein Prototyp des Systems: https://brezn.muc.ccc.de/svn/upay/trunk

In einer Datenbank werden die Hashes der ausgegeben Tokens (Form: 256 Zeichen Zufallsdaten + Timesteamp der Ausgabe) gespeichert und bei Verwendung als benutzt markiert. Die Datenbank enthaelt so keine Informationen, die zu einen Diebstahl von Tokens ausreichen und oeffentlich einsehbar gehalten werden.

Die Tokens werden per USB-Stick vom Matesuechtigen an das System herangetragen. Das System sucht dann per udev-rule nach einer “purse” Datei auf den Partitionen. Die erste gefundene Datei wird verwendet und die darin enthaltenen Tokens an einen auf dem System laufenden Daemon (checkout) uebermittelt. Dieser hasht die Tokens und vergleicht sie mit der in der Postgresql Datenbank gespeicherten Hashs. Waehlt der Suechtige ein Getraenk werden entsprechend viele Tokens in der Datenbank invalidiert.

Ausserdem befindet sich auf <fill me in> ein HTTP-Server, der eine API bereitstellt. Siehe den Punkt API weiter unten.

Das Datenbanklayout ist zur Zeit noch stark an den Matematen (pricelines) gekoppelt. Logging findet statt (Invalidation der Tokens sowie separat die Priceline-Ausgabe).

api

Grundsaetzliches:

  • Token-Listen sind immer \n-delimited!
  • Bei allen intern Token-Checks (z.B. auch bei /token/deposit) wid ein globales (jedoch sehr lasches) Rate-Limiting angewendet um Brute-Force-Attacken zu unterbinden. Im diesem Fall wird die Anfrage fuer eine Zeit ⇐ 1min blockiert.
  • Nur 1 Connection pro IP!

Bezahlen

Die Bezahl-API funktioniert grundsaetzlich in 3 Schritten: Sessionerstellung, Tokenuebertragung, Sessionabschluss und dazwischen bei Bedarf Abbruch.

Schritt URL Parameter (POST) Response (JSON) Bemerkung
(1) Sessionerstellung /pay/create sessionid
(2) Tokenuebertragung /pay/feed sessionid, tokens valid-tokens tokens sind \n-delimited
(3) Sessionabschluss /pay/close sessionid used-tokens Request blockiert bis Bezahlung erfolgt, kann mit der letzten sessionid beliebig oft aufgerufen werden
Abbruch /pay/abort sessionid

Token-Management

Aktion URL Parameter (POST) Response (JSON) Bemerkungen
Tokens auf Gueltigkeit ueberpruefen /token/check tokens valid-tokens
Neue Tokens generieren /token/exchange tokens new-tokens
Tokens auf Server ablegen (neu generierte mit PIN) /token/deposit tokens pin PIN nur 10 Min. gueltig!
Neue Tokens holen (mit PIN) /token/withdraw pin tokens Falls PIN schon gesperrt, zu einem Admin der manuell freischaltet

Fehlercodes

Falls ein HTTP Code != 200 (OK) zurueckgeliefert wird, ist ein Fehler aufgetreten. Die Fehler koennen wie folgt interpretiert werden:

HTTP Error Code Fehler
400 Bad Request Fehler beim Parsen des Requests
401 Unauthorized Session-ID nicht korrekt
402 Payment Required Bei /pay/close falls nicht genug Credit geladen wurde; Session wird trotzdem geloescht!
404 Not Found Bei /token/get falls die PIN nicht gefunden wurde
503 Service Unavailable Bei /pay/create oder allen Token-Mgmt falls zur Zeit nicht elektronisch bezahlt werden kann

zukunft

brezn.muc.ccc.de_schneider_bezahlen1.jpeg

Es sollen mehrere Postgresql-Datenbanken aufgesetzt werden, die sich untereinander syncen. Ein Datenbank soll auf Zonk liegen. Diese dient der Synchronisation und zur Erstellung von Backups.

In den Clubraeumen befindet sich auf auf zwei Rechnen ebenfalls jeweils eine Datenbank mit Frontend auf die ein dort lokal laufender Checkoutserver zugreift.

Dieser Server bietet den verschiedenen Geraeten im Club die Moeglichkeit Tokens einzureichen und zu nutzen.

Die Kommunikation zwischen dem Client (Cashier) und Server (Checkout) soll durch gegenseitige Autentifizierung sowie Verschluesselung abgesichert werden. Diese soll allerding auch von einem einfachen 8 oder 32Bit Mikrocontroller handlebar sein, um nicht unbedingt einen kompletten Rechner fuer den Client verwenden zu muessen.

  • Tokens mit festen Wert von 50 Cent?
    • Dies mag fuer Getraenke funktionieren, ist aber z.B. fuer eine Bezahlung von per RepRap hergestellten Objekten nicht geeignet.
  • Tokens sollte optional mit Verfallsdatum
  • Tokens sollten bei Verlust revokbar sein
  • Schatzmeister benoetigt eine Verwaltung fuer das System
  • Datenbank soll ueber mehrere Rechner innerhalb und auserhalb der Clubraeume verteilt sein
  • API ueber Tor Hidden Service zugaenglich
    • Anonymitaet, yeah!
    • sonst: Zuordnung ueber MAC-Adresse bzw. Korrelation mit DHCP-Hostname moeglich
  • Mehr Auflademöglichkeiten wagen:
    • Geldscheinleser? (wird aktuell von Martin untersucht)
    • PayPal? (wurde von einigen Members gewünscht, bsx ist noch skeptisch ob der potentiellen Nebenwirkungen)
    • Überweisung? (eigentlich wollen wir nix, was automatisiert auf unser Konto zugreift)
  • Mobile-App
  • Token-Transfer-Möglichkeit (Member2Member-Payment)
  • upay/start.1279358254.txt.gz
  • Last modified: 2021/04/18 12:33
  • (external edit)