This is an old revision of the document!
uPay: Bargeldloses Bezahlen im Club
Angepeiltes System
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.
Aktueller Stand
- 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
Aktueller technischer Stand
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 |
Planung
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.
Zukunft/Ideen
- 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)