Neues Thema starten

LAN-TSE an Linux-Server

Hallo in die Runde,


wir planen, einen LAN-TSE-Server für Linux zu entwickeln. Die Idee ist folgende:

  • die TSE (oder auch mehrere) wird an den Linux-Server angesteckt
  • ein Prozess läuft im Hintergrund als Deamon und erledigt alle physischen Zugriffe auf die TSE (Semaphore)
  • zusätzlich wird für die administrativen Aufgaben (Zeit, Selbsttest) und für jede Kasse (Client-Id) ein Hilfsprozess gestartet (Fork)
  • der administrative Hilfsprozess erledigt selbständig die zyklischen Aufgaben, wie Aktualisierung der Uhrzeit und Auslösen des Selbsttests, er prüft beim Start auch, ob die TSE initialisiert ist (Pin, Puk etc.)
  • die Kassenprozesse kommunizieren mit der Kasse einerseits und mit dem TSE-Prozess andererseits
  • damit wären die Aufgaben entkoppelt, die TSE kümmert sich selbständig um alle Aufgaben, ist synchronisiert und vor Fremdzugriff geschützt
  • da der TSE-Prozess durchgehend läuft, gibt es keine "Zeitsprünge" o.ä.
  • es können mehrere Kassen pro TSE angeschlossen werden, auch ein Zugriff via OpenVPN wäre denkbar
  • die Kassen könnten dann z.B. via (HTTPS (z.B. REST) oder auch über ein eigenes Protokoll an den Server angebunden werden


Was meint Ihr dazu?

Wir benötigen das primär für einen Kunden mit ca. 7 Standorten und jeweils mehreren Kassen pro Standort. Ein Linux-Server läuft dort ohnehin schon, eine TSE pro Kasse wäre aber m.E. zu viel des Guten, zumal diese dann unter Windows laufen und die Kassen ja auch immer abgeschalten werden.

Vielleicht löst man damit auch das Problem "Ausfall der technischen Sicherheitseinrichtung"?
Ich würde das Ganze gern auch für andere Kassensysteme und/oder Nutzer anbieten, da es einfach nur ins Netzwerk eingebunden wird.
Da es ja ein etwas höherer Entwicklungsaufwand ist, wäre es wichtig zu wissen, ob es für solch eine Lösung Interessenten gäbe.

Viele Grüße
U. Kleinert


Hallo zusammen,


auch wenn es bisher hier keine Resonanz gab, möchte ich dennoch mal meinen aktuellen Zwischenstand posten.

Folgendes ist bis jetzt realisiert:

  • die TSE steckt am Server und ist gemountet, hier der Befehl:
    mount -o fmask=0177,dmask=0077,uid=<user> /dev/<Device> /<mountpoint>
  • über eine Konfigdatei wird folgendes eingestellt:
    - der Mountpoint der TSE
    - die "uid" und die "gid" des Daemonprozesses
      wichtig: aus Sicherheitsgründen kein root für den Daemon verwenden
    - Port auf dem der Daemon lauscht
    - Logfile und Loglevel
    - die ID's der Kassen, die sich verbinden dürfen, sowie ein Token (GUID) pro Kasse
  • ein in C++ geschriebener Daemon läuft quasi dauerhaft im Hintergrund erledigt alle Aufgaben, wie AdminLogin, SelfTest, UpdateTime
  • er sorgt dafür, daß alle Zugriffe auf die TSE synchronisiert sind
  • er lauscht auf dem o.g. Port auf Zugriffe von Clients (beleibig viele, max. fünf zur exakt gleichen Zeit)
  • sobald sich eine Kasse (Client) verbindet, wertet der Server das Token aus, registriert bei Erfolg die Kasse und startet die angeforderte Aktion
  • aus Sicherheitsgründen können hierüber keine administrativen Aufgaben (Tar-Export!) erledigt werden, folgende Befehle sind z.Zt. im Daemon implementiert:
    - Transaktionen starten, updaten, beenden (mit Rückgabe)
    - offene Transaktionen auslesen
    - Clients registrieren/deregistrieren, aktive Clients lesen
  • es gibt ein zweites, ebenfalls in C++ geschriebenes Admin-Programm, welches über die Konsole gestartet wird (Authentifizierung!) und die sensiblen Dinge erledigt, u.a.
    - TarExport und Daten löschen
    - UnblockUser und ChangePin/Puk
    - Health-Info und TSE-Info
    - selektiver Export von "WormEntries"
Da der Prozess dauerhaft läuft, gibt es keine Zeitsprünge mehr, der Selbsttest wird zuverlässig nachts ausgeführt und die Uhrzeit aller halben Stunde gestellt. Aufgrund der restriktiven Rechte des Daemon kann kein Schadcode ausgeführt und die TSE nicht kompromittiert oder fremd ausgelesen/angesteuert werden. Außerdem kann festgelegt werden, welche Kassen sich verbinden dürfen.

Aufgrund der Architektur ist die Anzahl der Kassen pro TSE und die Anzahl TSE's pro Server nicht begrenzt.


Im Moment erfolgt die Kommunikation zwischen Kasse und TSE-Server per proprietärem TCP-Socket, eine zusätzliche Anbindung über HTTP(S) und ggf. REST ist in Vorbereitung.


Bisher ist es mir noch nicht gelungen, die von der TSE ausgeführten Audit- und Systemlogs nachzustellen, um hier die Signaturen (z.B. per openssl) zu verifizieren. Ebenso gestaltet sich die Programmierung eines dafür benötigten TLV-Viewers (um die Log-Dateien zu visualisieren) noch schwierig. Beides hat aber mit dem "normalen" Betrieb der TSE nichts zu tun.


Viele Grüße
U. Kleinert

Hallo zusammen,


hier nochmal ein aktueller Stand. Inzwischen ist das Admin-Programm auch in der Lage:
  • die Daten der TSE als Tar-File zu exportieren
  • exportierte (oder fremde) Tar-Files zu analysieren
  • deren Logdateien und die Log-Messages der TSE (WormEntries) zu visualisieren
  • den PublicKey der TSE zu ermitteln und die S/N der TSE zu prüfen
  • die von der TSE erzeugten Signaturen zu verifizieren
  • aus den Logdateien die Daten für den QR-Code zu erstellen
Somit gibt es jetzt eine vollständig funktionsfähige Implementierung, die zusätzlich noch die Daten visualisieren und verifizieren kann.

Viele Grüße
U. Kleinert

Hallo Herr Kleinert,

Klasse Idee mit dem LAN-TSE.   In dem SDK Paket ist dies aber nicht enthalten, oder?
Wo kann man dieses denn beziehen?
Genau diesen beschriebenen Fall möchten wir umsetzen.  Kleine Linux Box wo die TSE angeschlossen ist.
Schönen Gruss
M.Schlimgen



Hallo Markus Schlimgen,


nein, natürlich nicht.
Mit der TSE bekommt man eine Firmware, die leider mit Bugs behaftet ist  (s. z.B.

https://support.gastro-mis.de/support/tickets/18937).
Dazu dann (wohl notgedrungen) ein SDK, mit welchem man das Teil zum Funktionieren bringen soll/kann, während bereits jeder billige WLAN-AccessPoint einen HTTP-Server integriert hat...

Damit sich die TSE dann eben für den ERP-Entwickler besser anfühlt und man nicht mehr alles "zu Fuß" programmieren muß, habe ich die LAN-TSE unter Linux in C++ programmiert.


Da die Lösung im Moment noch im Beta-Status ist, gibt es hier auch noch keine fertige Idee, was den Preis (Kauf oder Miete pro Zeit / pro Volumen) und die Lizenzierung (pro TSE oder pro Firma) angeht.

Ich könnte Ihnen aber eine zeitlich begrenzte Version (z.B. für sechs Monate) zum Testen zur Verfügung stellen. So könnten Sie probieren, ob Sie damit klar kommen und außerdem könnten wir so Erfahrungen sammeln, was bis zur finalen Version alles noch verbessert werden muß.

Viele Grüße
U. Kleinert


Hallo Herr Kleinert,
klar, gerne.   Bin über markus.schlimgen(at)moonlightsoft.de  erreichbar für den weiteren Austausch. 

Schönen Gruss
M.Schlimgen


Anmelden oder Registrieren um einen Kommentar zu veröffentlichen