Alibispeicher im PC

[Captnemo]

Hallo Leute,

von einem Kunden habe ich den Auftrag eine lange überholte Softwareentwicklung neu zu programmieren um neue Technologien zu ermöglichen. Bei diesem Projekt handelt es sich um die Weiterverarbeitung von Wiegedaten verschiedener Waagen, die von den den Kunden meines Kunden selbst bedient werden.
Dazu habe ich schon folgendes Dokument gefunden: http://bundesrecht.juris.de/eo_1988/index.html

Es ist sicherzustellen, dass die Wiegedaten verfälschungssicher für beide Parteien zugänglich abgelegt werden. Die Firma Soehnle hat dafür eine Softwarelösung entwickelt, die eben solches innerhalb eine PC's sicherstellt. Siehe: http://www.digitalwaagen.de/Produkte...ie/2564_de.pdf

Grundsätzlich sie die Waagen per Serieller Schnittstelle direkt mit dem Wiege-PC verbunden und verfügen nicht über einen direkt angeschlossenen Alibidrucker.

Deswegen würde ich gerne in die Neuprogrammierung eben diese verfälschungssichere Datenspeicherung mit einbauen ohne auf noch ein Zusatzprodukt einzusetzten. Ich bin mir aber nicht sicher, ob das ganze dann die Eichprüfung übersteht. Weiß jemand welche Anforderungen an diese Alibispeicherung genau gestellt werden? Reicht es wenn man das ganze in einer Tabelle des Datenhaltungssystem ablegt und über die Software nur lesend zur Verfügung stellt, oder bestehen auch noch Anforderungen an das Datenhaltungssystem? Vorgesehen ist eine SQL-Datenbank.

Aus den oben genannten Informationen werde ich nicht ganz schlau.

Meine Strategie wäre auf dem Wiege-PC (wo die Waage per RS232 direkt angeschlossen sind) eine dateibasierende Datenbank (Paradox) mitlaufen zu lassen um jeden Wiegevorgang mit entsprechenden Daten zu protokollieren. Für die Weiterverarbeitung werden die Daten dann an den SQL-Server im Netzwerk gesendet. Wäre das eichfähig? (Wobei ich mit Paradox nicht unbedingt glücklich bin.)

Wär schön wenn sich jemand finden würde, der damit Erfahrung hat.

Gruß Dieter

[divBy0]

Kann dir da nicht vielleicht das Eichamt selbst weiterhelfen?

[Captnemo]

Zitat:

Zitat von divBy0 (Beitrag 1111450)

Kann dir da nicht vielleicht das Eichamt selbst weiterhelfen?

Sicher. Wollte mich aber schon mal vorinformieren. Der Kunde erwartet von mir jetzt ersteinmal ein Konzept (Das ganze Projekt umfaßt noch weiter Verarbeitungsschritte bis hin zur Rechnungserstellung). Dafür wäre diese Information erst mal hilfreich.

[mkinzler]

Ich würde clientseitig das selbe DBMS einsetzen.

[Neumann]

Das was Söhnlein da schreibt hört sich gut an. Ich würde das Einsetzen, wenn es irgendwie geht. Selber eichfähige Waagenanbindungen zu machen ist Aufwendig und die Prüfung ist teuer.

Leider sieht man nicht direkt was die Software kostet, würde mich auch interessieren.

[Steku]

Alibispeicher... ja Mensch, was es alles gibt...:)

Aus Interesse mal bei Tante Google geschaut, Preise
gibt es hier :

http://waagen-kurz.de/industriewaage...cher_preis.htm

Gruß,
Steku

[Neumann]

Der Preis ist gut. Eichung sollte so 2000 - 3000 kosten, vom Aufwand mal abgesehen.

Das Wort Alibispeicher war mir auch nicht bekannt. Dachte zuerst man kann das gebrauchen wenn die Gesetzeshüter hinter einem her sind.

- Wo waren Sie am 18.9.2010 von 18:00 bis 22:00? Kurz im Alibispeicher nachsehen und Antworten bei ...

[Captnemo]

Bei industiellen Waage (Gewerblicher Einsatz) ist ein Wiegeprotokoll vorgeschrieben. In meinem Fall handelt es sich um Großwagen (wo z.b. ein 40t-LKW gewogen wird). Diese Wagen haben zum einen einen Wiegespeicher, der in der Waage intern das Gewicht, den Zeitpunkt und eine fortlaufende Wiegenummer speichert. Dieser Wiegespeicher ist entweder nur vom Hersteller auslesbar, es kann für jede Wiegung eine Protokollzeile auf einem Zeilendrucker ausgegeben werden oder es kann ein externe Wiegespeicher angeschlossen werden. Diese Wiegespeicher sind aber bei jeder Waage anders realisiert.

Das bisherige Wiegesystem (EDV) läuft unter einer Paradox-DB und für das Eichamt wird lediglich eine Tabelle fortlaufend geschrieben, in der die Daten die von den Waagen kommen mitgeschrieben werden. In wie weit dieses Protokollieren vom Eichamt damals abgenommen und für in Ordnung befunden wurde ist mir nicht bekannt (Wurde vor 10 Jahren entwickelt). Wenn ich aber die Dokumente sehe, die ich bisher darüber gefunden habe, reicht das so wohl nicht. Oder doch? Aber die Software von Soehnle macht ja im Grunde nichts anderes.

Entscheident ist wohl, dass die Daten manipulationssicher in diese DB fließen, und nur lesen darauf zugegriffen werden kann. Nur wie sollte man das auf nicht versiegelten PC realisieren? Laut Soehnle braucht der PC nicht versiegelt zu werden und darf für weiter Software genutzt werden. Und eine manipulationssichere Datenspeicherung ist ja grundsätzlich nicht möglich. Denn mit entspechendem Aufwand kann jede Information manipuliert werden. Zumal dann ja auch der lesende Zugriff für Anbieter, Kunde und Eichamt sichergestellt sein muß. Ich weiß jetzt zwar nicht, welches DB-System Soehnle hier verwendet, aber mit entsprechendem Aufwand stellt das für eine Hacker auch keine Hürde dar.

[DeddyH]

Ich weiß nicht, ob das so abgenommen würde, aber man kann doch auch auf DB-Ebene mit entsprechenden Berechtigungen arbeiten (bei Paradox wohl eher nicht, aber die gängigen Client-/Server-RDBMS sollten das alle beherrschen). Beispielsweise eine SP, die als einzige INSERT-Rechte bekommt, SELECT-Rechte bekommen alle, die zum Auslesen berechtigt sein sollen, DELETE- und UPDATE-Rechte werden komplett entzogen.

[Klaus01]

Zitat:

Zitat von DeddyH (Beitrag 1111525)

Ich weiß nicht, ob das so abgenommen würde, aber man kann doch auch auf DB-Ebene mit entsprechenden Berechtigungen arbeiten (bei Paradox wohl eher nicht, aber die gängigen Client-/Server-RDBMS sollten das alle beherrschen). Beispielsweise eine SP, die als einzige INSERT-Rechte bekommt, SELECT-Rechte bekommen alle, die zum Auslesen berechtigt sein sollen, DELETE- und UPDATE-Rechte werden komplett entzogen.

.. aber wird es nicht immer zumindest einen DB Admin geben, der alle Rechte hat?

Grüße
Klaus

[DeddyH]

Auch der kann sich ja die Rechte entziehen, nur leider kann er sie sich dann wohl auch wiederbeschaffen. Das war ja auch nur ein Vorschlag, wie man das zumindest rudimentär eingrenzen kann.

[Captnemo]

Ich habe jetzt zwei Dokumentationen gefunden:

http://www.ptb.de/de/org/1/11/112/infos/speicher.htm
http://www.ptb.de/de/org/1/11/112/in..._auslegung.htm
(wobei in der Zweiten leider kein Publikationsdatum ausgegeben ist)

laut denen ist es so, dass eben dieser Alibispeicher gegen Manipulation mit einfachen Mitteln (Texteditor) verhindert werden muß. Was meiner Meinung nach bei den heutigen Maßstäben viel zu unsicher ist. Im Falle von Paradox ist doch das einfachste von der Welt mal eben die DB-Oberfläche der BDE nachzuinstallieren und korrekturen vorzunehmen.
Ziel dieses Alibispeichers soll es ja sein, das Verändern der Wiegedaten durch den Betreiber und durch den Kunden zu verhindern und beiden gleichzeitig eine einfache Einsicht in die protokollierten Daten zur Verfügung zu stellen. Der Entwickler kann ja immer Daten verändern.

Am liebsten wäre mir ja ein USB-Stick, der es zuläßt Daten an eine Datendatei anzuhängen, aber danach nicht mehr zu löschen oder zu ändern. Aber sowas gibt's wohl nicht.

Ein SQL-Server soll eigentlich nur auf dem Windows-Server existieren. Auf der Workstation, an die die Waagen angeschlossen sind, wollte ich nicht noch einen zusätzlichen SQL-Server installieren. Der Grund ist eigentlich ganz einfach. Im Falle einen Totalausfalls der Hardware soll die Software möglichst schnell auf eine andere Workstation portiert werden. Geht zwar mit SQL auch, aber mit einer Dateibasierenden DB geht's noch schneller.

Außerdem bietet Paradox ja keine Möglichkeit einen Passwortschutzes oder einer Verschlüsselung. Ich überlege schon ob da nicht evtl. AbsoluteDatabase besser wäre. Diese bietet eine Passwortschutz incl. AES-Verschlüsselung. Wenn das PW in den Softwareteil integriert ist, welcher für die Protokollierung zuständig ist, wäre das ja vielleicht auch in Ordnung. Der der Softwareteil, welcher dem Betreiber/Kunden/EichAmt das auslesen der Daten ermöglichen soll, kann man per ReadOnly ja den Schreibzugriff erfolgreich verwehren.

Überigens: Die Software von Soehnle ist wohl nur für Waagen von Soehnle zu bekommen.

[DeddyH]

Einen SQL-Server brauchst Du ja auch nur einmal an zentraler Stelle. Auf den PCs, an denen die Waagen angeschlossen sind, genügt dann eine Client-Installation (das sind meist je nach DBMS eine Handvoll DLLs). Bei Hardware-Ausfall eines Clients sind die doch ruckzuck neu installiert. Und wenn ich meine Gedanken von eben noch einmal überdenke, sollte doch Folgendes im Groben funktionieren:
- Anlegen div. Rollen (Waage, Auswerter, etc.)
- auf die Wiegedaten-Tabelle werden zunächst alle Rechte für jedermann entzogen
- die Rolle Auswerter bekommt das SELECT-Recht
- die Rolle Waage bekommt das INSERT-Recht

Je nach Anmeldung an der DB dürfen die Daten nun geschrieben und/oder gelesen werden. Wer nun absichtlich Daten in dieser Tabelle ändern möchte, muss zunächst einigen Aufwand betreiben. Unbeabsichtigte Änderungen sollten so gut wie ausgeschlossen sein.

[Captnemo]

Zitat:

Zitat von DeddyH (Beitrag 1111578)

Einen SQL-Server brauchst Du ja auch nur einmal an zentraler Stelle. Auf den PCs, an denen die Waagen angeschlossen sind, genügt dann eine Client-Installation (das sind meist je nach DBMS eine Handvoll DLLs).

Bei dem Datenhaltungssystem werde ich das ja auch so machen. Aber für eine eichfähige Protokollierung wäre das schlecht. Denn dann würde auch der Server mit in die Eichung fallen, denn der sämtliche Komponente von der eigentlichen Waage bis zur Prokollierung unterliegt alles der Eichung. Erst nach der Protokollierung kann das Unternehmen die Weiterverarbeitung nach eigenem Ermessen gestallten. Deswegen möchte ich den Aufwand für die Protokollierung möglichst gering halten, aber so dass er einer Eichprüfung standhält.

[jobo]

Ergänzend zu den Gedanken von DeddyH würde ich pro Wägesatz eine verschlüsselte Variante wegschreiben. Das allerdings in einer separaten Tabelle, bisschen Verschleierung dazu, damit die Referenzen nicht zu sehr ins Auge fallen, aber selbst wenn, wärs auch egal.
Wer nun die Daten manipuliert, erzeugt einen Mismatch zwischen Wägesatz und verschlüsseltem Wägesatz. Dazu gehört natürlich auch ein einfaches Prüftool, sowie Initialisierungs-, BackupRecovery-, Installationsmechanismen für Schlüssel.

[Neumann]

Eigentlich kann man jede Datenbank nehmen, wenn man die Daten verschlüsselt speichert. Wenn dann jemand versucht die Daten zu manipulieren, kann er sie nur kaputtmachen.

Den Schlüssel kann man in einem Dongle speichern; diese haben Write-Only Memory für den Schlüssel und die Ver- und Entschlüsselung passiert in dem Dongle.

[mschaefer]

Also denke, dass eine Datenbanktabelle nicht durch die Eichprüfung kommt. Letztlich sind diese wohl parallel zu einem WriteOnce-Speichermedium erlaubt, aber alleine reichen diese nicht. Intern kann man dieses über EPROMS lösen, oder aber man lässt wie bei den Bankautomaten einen Bondrucker mitlaufen. Da ist dann Papier das WriteOnce-Medium.

[Neumann]

Es gibt auch Bondrucker mit eingebautem Write-One Speicher, sogenannte Fiskaldrucker. Sind in einigen Ländern Pflicht für das Drucken von Kassenbons, z.B. in Italien oder Polen.
Den Speicher kann dann der Prüfer vom Finanzamt auslesen und mit der Buchhaltung vergleichen.

Es kommen immer mal wieder Gerüchte auf dass diese Drucker auch in Deutschland eingeführt werden sollen, aber passiert ist noch nichts.

[blackfin]

Irgendwie verstehe ich da (mal wieder) den deutschen Aufriss nicht...
Wenn die Waage über RS232 an einem PC hängt, ist diese Schnittstelle ja schon das Scheunentor.
Da bastel ich mir in 1-2 Stunden mit einem Mini-Microcontroller (TinyAVR oder PIC12) einen kleinen Kasten, den ich dazwischenhänge (was ja geht, wenn der PC nicht versiegelt ist...), und diese Box schönt mir jegliche Daten, bevor sie überhaupt am PC ankommen...

[mschaefer]

Prüfer kommen in der Regel ohne Anmeldung und lassen Ihr Normgewicht erst wiegen bevor sie den Vergleichswert abfragen. Bei den Bankautomaten sind die Bondrucker im versiegelten Bereich.

[Hudel1965]

Hi :-)

wir mussten auch eine Software entwickeln die als Alibispeicher verwendet werden kann. Wir sind dabei so vorgegangen das wir pro Gewichtswertszeile (Datum, Alibinr., Gewichtswert) eine CRC16 (modifiziert) verwenden und diese mit zum PC übertragen.

Das Anzeigeprogramme berechnet dann aus den Werten auch die CRC16 und wenn diese nicht übereinstimmen wird die Anzeige entsprechend hervorgehoben, damit man erkennen kann ob an den Werten herum manipuliert wurde.

Diese Anwendung wurde von der PTB so abgenommen.

Dies ist natürlich auch kein 100% Schutz.

Mfg

Hudel