Differences

This shows you the differences between two versions of the page.

--- upay:start [2010/06/20 15:36] – Links to intern:upay_evolution changed to upay:upay_evolution bsx
+++ upay:start [2021/04/18 12:35] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
 ====== uPay: Bargeldloses Bezahlen im Club ======
-===== Angepeiltes System =====
+===== Uebersicht =====
-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.
+Das System basiert auf einzelnen Tokens, die einen bestimmten Wert haben. Ein Geraet (fnordload) gibt gegen Bargeld solche Tokens auf USB-Sticks aus.
+Ein Token besteht aus einer Zufallszahl, dem Wert und dem Erzeugungsdatum. Ein Hash jedes Tokens steht in einer zentralen Datenbank. Ein guelltiges Token stellt einen Schuldschein gegenueber dem fnordload dar.
+Werden die Tokens an den dafuer vorgesehenen Stellen (Matemat, RepRap, ...) verwendet werden sie in der (zentralen) Datenbank als benutzt markiert und ein neues Token generiert. Dieses Token wird vom Empfaenger (Matemat) gespeichert und einbehalten.
+===== Entwicklung =====
+  * Mailingliste: [[http://lists.muc.ccc.de/cgi-bin/mailman/listinfo/upay|upay@lists.muc.ccc.de]]
+  * upay Library: https://github.com/muccc/upay
+  * Fnordload: https://github.com/muccc/fnordload
+  * Matemat: https://github.com/muccc/matepay
+  * Laser: https://github.com/schneider42/lazzormanagement
-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
+    * Tokens koennen vom fnordload bezogen werden (vorher an schneider wenden)
     * Bezahlung nur mit USB-Stick
     * Getraenketaste so lange druecken bis die Motoren im Matematen anlaufen!
       * wird mittelfristig durch Zusatzhardware fuer Matematen behoben
+  * API zu erreichen unter https://payment.club.muc.ccc.de (siehe [[api|API]] fuer fingerprints)
+  * Taeglicher Datenbank-Dump unter https://payment.club.muc.ccc.de/dumps/
+  * Matemat-Tokens unter https://github.com/muccc/matemat-tokens (verschluesselt)
-===== Aktueller technischer Stand =====
+===== Aktueller Technischer Stand =====
+In einer Datenbank werden die Hashes der ausgegeben Tokens (SHA-512) sowie das Ausstelldatum gespeichert und bei Verwendung als benutzt markiert. Die Datenbank enthaelt so keine Informationen, die zu einen Diebstahl von Tokens ausreichen. Aus Transparenzgruenden wird sie taeglich veroeffentlicht.
-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 =====
-{{ https://brezn.muc.ccc.de/~schneider/bezahlen1.jpeg?400}}
-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 Tokens werden per USB-Stick vom Matesuechtigen an das System herangetragen. Das System sucht dann nach einer "purse" Datei auf den Partitionen. Die erste gefundene Datei wird verwendet und die darin enthaltenen Tokens per API auf Guelltigkeit geprueft.
-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.
+Die API laeuft auf dem selben Server, der auch die Datenbank betreibt. Die API hasht die Tokens und vergleicht sie mit den in der Postgresql Datenbank gespeicherten Hashs. Waehlt der Suechtige ein Getraenk werden entsprechend viele Tokens in der Datenbank invalidiert und in neue Tokens umgewandelt. Diese Tokens werden dem Matematen von der API zurueckgegeben Siehe den Punkt API weiter unten.
-===== Zukunft/Ideen =====
-  * Tokens mit festen Wert von 50 Cent?
+===== Technische Infos =====
-    * Dies mag fuer Getraenke funktionieren, ist aber z.B. fuer eine Bezahlung von per RepRap hergestellten Objekten nicht geeignet.
+  * [[api|API]]
-  * Tokens sollte optional mit Verfallsdatum
+  * [[zukunft|Planung/Zukunft/Ideen]]
-  * <del>Tokens sollten bei Verlust revokbar sein</del>
-  * 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)
-===== interne Weiterentwicklung =====
-[[upay_evolution]]