Hallo,

bei dem Ablauf meines Skriptes müssen zwischendurch immer wieder Daten/Ergebnisse gesichert werden. Mein Problem ist, dass ich später nachweisen möchte/muss, dass diese Daten vollständig sind (d.h. keine Datenreihe/-Zeile gelöscht wurde) und dass diese auch nicht verändert wurden. Da das Script auf meinem/ dem eigenen Rechner läuft, hätte ich im Prinzip alle (System-) Recht um entsprechende Manipulationen durchzuführen, d.h. eine Sicherung über System-Rechte ist nicht möglich. Eine Netzwerkverbindung ist auch nicht gewährleistet.

Bildlich gesprochen bräuchte ich einen (Software-) Briefkasten, in den man jederzeit Daten 'einwerfen' kann, diese danach aber nicht mehr ändern kann.

In meiner momentanen Lösungsidee wird pro Datenreihe eine Datei angelegt, welche direkt danach mittels pgp/öffentlichem Schlüssel verschlüsselt wird. Gibt es vielleicht noch bessere/einfachere Lösungen?

Wahrscheinlich wird es sehr schwer/unmöglich sich gegen eine Manipulation zu sichern, aber ich möchte/muss zumindest feststellen können, ob die Daten verändert wurde.

Gruß

Hagen

Hagen+2008-03-27 10:35:14--

[...]
Bildlich gesprochen bräuchte ich einen (Software-) Briefkasten, in den man jederzeit Daten 'einwerfen' kann, diese danach aber nicht mehr ändern kann.

In meiner momentanen Lösungsidee wird pro Datenreihe eine Datei angelegt, welche direkt danach mittels pgp/öffentlichem Schlüssel verschlüsselt wird. Gibt es vielleicht noch bessere/einfachere Lösungen?

(1) Eigentlich bringt es nichts, die Daten zu verschlüsseln. Was man braucht ist vielmehr eine digitale Unterschrift, also eine verschlüsselte Prüfsumme, die bestätigt, dass niemand die Daten verändert hat.

(2) Es ist auf einem Mehrbenutzersystem nicht sicher, die Daten jemals in Rohform auf die Platte zu schreiben, denn irgendjemand könnte sie verändern bevor der Integritätsschutz erfolgt. Das gilt auch, wenn man die Daten nur ganz normal in einer Perlvariablen abgelegt hat, denn jemand könnte den Rechner dazu bringen, die betreffenden Speicherseiten auszulagern, sie auf der Platte verändern und dann wieder in den Speicher laden lassen. Man muss also schon den Systemkern anweisen, die betreffenden Speicherseiten nie zu swappen und auf keinen Fall in den Suspend to Disk Modus zu gehen. Mit einer passenden Schnittstelle zu GnuPG müsste das aber machbar sein.

(3) Es ist ein wenig problematisch, den privaten Schlüssel zum Integritätsschutz der Daten so zu lagern, dass zwar das Skript, welches die Daten sammelt, leicht an ihn herankommt, andere Programme das aber nicht können. Wer den privaten Schlüssel hat kann alle damit signierten Daten fälschen.

(4) Wahrscheinlich wäre es sinnvoll, irgendein Konzept zur Transaktionssicherheit zu implementieren, falls mal mitten in der Arbeit der Strom ausfällt.

(5) Wenn man mehrere Datensätze in mehreren Dateien speichert, muss man auch noch eine signierte Liste von Dateien ablegen, sonst könnte jemand unbemerkt Datensätze löschen. Die Liste sollte ebenfalls geeignet transaktionssicher verwaltet werden.

(6) Je nach Grad der Paranoia sollte man über ein vernünftiges Selbstzerstörungssystem für den Schlüsselspeicher nachdenken ;-)

Was du suchst ließe sich zumTeil mit RSA Lösen. Aber nicht vollständig.
RSA Ist ein Verschlüsselungssystem mit asymmetrischem Schlüssel. PGP / GPG arbeitet damit.
Der Überprüfende erzeugt ein Schlüsselpaar und gibt dir den öffentlichen Schlüssel, damit lässt sich nur verschlüsseln. Den privaten Schlüssel behält er, damit kann man nur entschlüsseln. Du Verschlüsselst die Dateien mit dem Öffentlichen Schüssel und er kann sie entschlüsseln und auf Korrektheit prüfen.
Du könntest nun aber schon mal gespeicherte Dateien gegen andere austauschen, Wenn du diese aber auf CD-Rs (UDF oder ISO mit Sessions), dann sind sie gegen nachträgliche Manipulation gesichert. (immer vorausgesetzt du lässt die CDs nicht verschwinden, dem kann entgegen gewirkt werden, wenn der Prüfer dir Signierte CD-Rs gibt.)

murphy+2008-03-27 11:45:06--

(1) Eigentlich bringt es nichts, die Daten zu verschlüsseln. Was man braucht ist vielmehr eine digitale Unterschrift, also eine verschlüsselte Prüfsumme, die bestätigt, dass niemand die Daten verändert hat.

Jein. Hat topeg auch beschrieben. Ich will ja meine eigenen Daten so sichern, dass ich sie selber nicht mehr bearbeiten kann, ohne dass es auffällt. Beim signieren wäre das aber möglich. Dabei unterschreibe ich ja meine eigene Aussage und kann das jederzeit wieder tun (Daten nachträglich ändern und einfügen). Außerdem müsste ich jedes mal ein Kennwort eingeben. Dies ist beim Verschlüsseln mit PGP nicht der Fall.

Im Moment (Idee) werden sämtlich Einträge/Daten verschlüsselt und bekommen eine fortlaufende Nummer. Außerdem wird ein Datensatz beim Programmstart und -Ende angelegt. Zusätzlich wird ein Hash-Wert des Scriptes gespeichert, so dass Änderungen am Script bemerkt werden. Dadurch müssten Manipulationen an Datensätzen, Löschungen (außer am Ende) und Einfügen erkennbar sein.

Die Idee von topeg mit der CDr ist natürlich auch ein interessanter Ansatz, aber leider bei mir nicht praktikabel (z.B. wg. nicht vorhandener Hardware).

Was mich ein bisschen wundert, dass ich im Internet dazu kaum etwas gefunden habe. Ist das Anliegen denn so exotisch?

Hagen+2008-03-28 22:07:12--

[...] Ich will ja meine eigenen Daten so sichern, dass ich sie selber nicht mehr bearbeiten kann, ohne dass es auffällt. Beim signieren wäre das aber möglich. Dabei unterschreibe ich ja meine eigene Aussage und kann das jederzeit wieder tun (Daten nachträglich ändern und einfügen). Außerdem müsste ich jedes mal ein Kennwort eingeben. Dies ist beim Verschlüsseln mit PGP nicht der Fall. [...]

Und was hindert Dich daran, neue Daten zu verschlüsseln und über die alten zu schreiben? Die Tatsache, dass außerdem der zum verschlüsseln notwendige öffentliche Schlüssel des Empfängers in der Regel leicht zugänglich ist, macht das ganze noch unsicherer...

Quote

Was mich ein bisschen wundert, dass ich im Internet dazu kaum etwas gefunden habe. Ist das Anliegen denn so exotisch?

Leute, die so etwas wirklich brauchen, verwenden dazu normalerweise dedizierte Server. Jeden vernünftigen Datenbankserver kann man so konfigurieren, dass er von außen nur das Einfügen neuer Daten erlaubt, Checksummen darüber bildet und diese Aktivitäten an einem Ort logt, auf den man über die Datenbankschnittstelle überhaupt nicht zugreifen kann. Der Schlüssel zur Sicherheit liegt dabei darin, dass die Schnittstelle für den Zugriff auf die Daten eingeschränkt ist und das Speichersystem physisch ordentlich abgesichert ist (Rechner im Panzerschrank mit Wache vor der Tür ;-)

Wenn ein potentieller Angreifer prinzipiell Daten einspeisen darf und irgendwie physischen Zugang zum Speichermedium mit den Daten erhalten kann, dann ist es meiner Meinung nach völlig unmöglich, ihn daran zu hindern auch Daten beliebig zu verändern.