"Fälschungssicherer" USB-Stick
-
Wenn das Programm immer nur neue Daten auf den Stick schreibt, und nie was löscht, hast du kein allzu grosses Problem.
Wenn das Programm aber z.B. Logfiles rotiert, dann geht irgendwann der Speicher aus.Da der Stick aber immer "OK" meldet, bekommt das Programm davon nix mit.
Auch kenne ich zumindest ein Programm, das an Logfiles immer grössere Blöcke anhängt - vermutlich um übelste Fragmentierung zu vermeiden. Die noch unbenutzten Teile werden dabei einfach mit Zeilen vollgemacht die aus lauter Leerzeichen bestehen. Die genauen Daten weiss ich nimmer, aber sagen wir es werden 64K Stücke angehängt die aus Zeilen zu je 254 Leerzeichen + \r\n bestehen.
Ich sehe da also immer noch ziemlich dunkegrau.
Auch frage ich mich, was der Einsatzzweck von sowas sein soll. In den meisten Fällen reicht es wenn man den Zugriff auf die Server einschränkt. Und wenn man vor Gericht was beweisen will, wird man es mit einem selbstgebastelten Stick der angeblich "fälschungssicher" ist nicht leicht haben. Immerhin gibt es sowas wie Timestamping-Server.
Auch stelle ich mir die Sache mit dem Abgleich schwierig vor. Gerade Anwendungen wo geloggt wird, laufen oft 24/7, d.h. da würde der Stick niemals abgesteckt.
-
hustbaer schrieb:
Wenn das Programm aber z.B. Logfiles rotiert, dann geht irgendwann der Speicher aus.
Da der Stick aber immer "OK" meldet, bekommt das Programm davon nix mit.Denkbar wäre auch eine Variante des Sticks, die während einer "Session" überschreiben erlaubt, so dass erst bei der nächsten Reaktivierung des Sticks die Daten "festgenagelt" werden. Dann wäre es auch für ringspeicheränliches Logging geeignet. Allerdings bräuchte man dann für jede "Session" einen neuen Stick.
hustbaer schrieb:
Auch frage ich mich, was der Einsatzzweck von sowas sein soll.
Ich kenne wenigstens einen Anwender, der so etwas brauchen könnte.
hustbaer schrieb:
Auch stelle ich mir die Sache mit dem Abgleich schwierig vor. Gerade Anwendungen wo geloggt wird, laufen oft 24/7, d.h. da würde der Stick niemals abgesteckt.
In diesem Fall gibt es nur eine "Session", d.h. die Daten sind erst "fest" und fälschungssicher, wenn der Stick abgezogen wird (um die Daten auszuwerten).
-
Z schrieb:
Denkbar wäre auch eine Variante des Sticks, die während einer "Session" überschreiben erlaubt, so dass erst bei der nächsten Reaktivierung des Sticks die Daten "festgenagelt" werden. Dann wäre es auch für ringspeicheränliches Logging geeignet. Allerdings bräuchte man dann für jede "Session" einen neuen Stick.
Nicht unbedingt.
Der Stick könnte jede Session nur als Diff gegenüber der letzten speichern.
Und er könnte sich neben dem beschreibbaren FAT-Stick, auch als irgendwas, z.B. CDROM (wie U3) zeigen, so pro Session ein Verzeichnis liegt. Dann wäre wnigstens jede alte Session sicher.Aber ich denke, der Threadersteller will jede einzelne Schreibzeile absichern, damit man da zum Beispiel die Logdatei der Loginversuche hinlegen kann.
-
volkard schrieb:
Z schrieb:
(...)
(...)
Aber ich denke, der Threadersteller will (...)Z *ist* der Threadersteller
-
Z schrieb:
Einsatzgebiete dieses "Special"-Sticks sollen Fälle sein, in denen Daten fälschungssicher gespeichert werden müssen.
Stopp! Auszeit!
Das ist deine Anwendung? Und dafür willst du neue Hardware entwickeln?
Das ist doch ein ganz einfaches und tausendfach gelöstes Problem. Signier die Daten und fertig. Du kannst dann zwar nicht wirklich verhindern, dass die Daten verändert werden, aber du kannst Fälschungen sicher aufdecken und ebenso sicher die Echtheit von Daten bestätigen.
-
SeppJ schrieb:
Z schrieb:
Einsatzgebiete dieses "Special"-Sticks sollen Fälle sein, in denen Daten fälschungssicher gespeichert werden müssen.
Stopp! Auszeit!
Das ist deine Anwendung? Und dafür willst du neue Hardware entwickeln?
Das ist doch ein ganz einfaches und tausendfach gelöstes Problem. Signier die Daten und fertig. Du kannst dann zwar nicht wirklich verhindern, dass die Daten verändert werden, aber du kannst Fälschungen sicher aufdecken und ebenso sicher die Echtheit von Daten bestätigen.Daran habe ich auch schon gedacht, jedoch erfordert das eventuell ein ausgeklügeltes Schlüsselmanagement bzw. externe Software. Zudem könnte es die Rechenkapazität des Controllers auf dem Stick übersteigen, denn er muß dazu kryptographisch starke Hashfunktionen in vertretbarer Zeit berechnen können. Und mit der Anforderung des Anhängens an bestehende Dateien wäre es wohl auch nicht wirklich kompatibel.
Den Beitrag von Volkard "Der Stick könnte jede Session nur als Diff gegenüber der letzten speichern", das Ganze als eine Art Versionskontrollsystem zu implementieren, finde ich sehr reizvoll. Nur wäre hierbei leider die Größe des Backup-Speichers abhängig von der Anzahl der Sessions und das "Restaurieren" einer beliebigen Session ist auch gar nicht gefordert.
-
Z schrieb:
Nur wäre hierbei leider die Größe des Backup-Speichers abhängig von der Anzahl der Sessions und das "Restaurieren" einer beliebigen Session ist auch gar nicht gefordert.
Oder es wäre die Anzahl der Sessions abhängig von der Größe des Speichers. Das ist zwar ein wenig schwieriger zu proggern, aber sollte auch gehen.
Achnee, dann könnte der Angreifer den Stick vollmüllen und erzwingen, daß alle alten Sessions zusammengeführt werden.
Und wenn sagen wir mal 30 Sessions garantiert leben, sodaß der Angreifer im Angriffsfall ein "Platte ist Voll" oder so kriegt, ist und auch nicht gehelft. 30 Sessions sind ja nicht die (geraten) gerichtsnotwenigen 30 Tage, sondern er kann als Putzfrau verkleidet nach Büroschluß bis Torschluß 31 Sessions fahren und die böse Session verdrängen.
-
Z schrieb:
Daran habe ich auch schon gedacht, jedoch erfordert das eventuell ein ausgeklügeltes Schlüsselmanagement bzw. externe Software. Zudem könnte es die Rechenkapazität des Controllers auf dem Stick übersteigen, denn er muß dazu kryptographisch starke Hashfunktionen in vertretbarer Zeit berechnen können. Und mit der Anforderung des Anhängens an bestehende Dateien wäre es wohl auch nicht wirklich kompatibel.
Irgendwie sehe ich gerade nicht, wieso das Probleme sind. Wieso muss der Stick die Rechnung übernehmen? Kann doch der Host machen. Und ausgekügeltes Schlüsselmanagement? Jeder Anwender bekommt einen eigenen privaten Schlüssel und die öffentlichen Schlüssel dazu werden, nun ja, veröffentlicht. Da sowieso physikalischer Kontakt zwischen den Anwender bestehen muss, hat man noch nicht einmal das Problem, dass bei der Übertragung der öffentlichen Schlüssel ein Man-in-the-middle sein kann.
Und externe Software wäre so etwas wie PGP. An Dateien anhängen, ginge wohl auch irgendwie. Man kann den Anhang ja als solchen kennzeichnen und als Extra-Datei anfügen. Oder ein Versionskontrollsystem aufsetzen. Das wäre dann jedoch schon etwas komplexer
.
-
SeppJ schrieb:
Das ist doch ein ganz einfaches und tausendfach gelöstes Problem. Signier die Daten und fertig. Du kannst dann zwar nicht wirklich verhindern, dass die Daten verändert werden, aber du kannst Fälschungen sicher aufdecken und ebenso sicher die Echtheit von Daten bestätigen.
Wenn der Anwender den privaten Schlüssel auf dem PC hat, kann er Daten sehr wohl fälschen. Er kann sie einfach neu signieren mit falschem Timestamp.
Signieren ist vermutlich nicht verkehrt, aber das müsste dann schon eine manipulationssichere externe Hardware übernehmen, damit die Timestamps nicht gefälscht werden können.
Aber mal ein ganz anderer Vorschlag: Braucht man unbedingt USB-Sticks? Haben die PCs keinen Internet- oder wenigstens Intranet-Zugang? Ich würde sowas übers Internet machen. Eine authentifizierte, verschlüsselte Verbindung aufbauen zu einem externen Rechner und dem die Logdaten regelmäßig schicken. Der externe Rechner kann die dann signieren, fälschungssicher abspeichern und so weiter.
-
Christoph schrieb:
Aber mal ein ganz anderer Vorschlag: Braucht man unbedingt USB-Sticks? Haben die PCs keinen Internet- oder wenigstens Intranet-Zugang? Ich würde sowas übers Internet machen. Eine authentifizierte, verschlüsselte Verbindung aufbauen zu einem externen Rechner und dem die Logdaten regelmäßig schicken. Der externe Rechner kann die dann signieren, fälschungssicher abspeichern und so weiter.
Sprich: Git?
-
SeppJ schrieb:
Christoph schrieb:
Aber mal ein ganz anderer Vorschlag: Braucht man unbedingt USB-Sticks? Haben die PCs keinen Internet- oder wenigstens Intranet-Zugang? Ich würde sowas übers Internet machen. Eine authentifizierte, verschlüsselte Verbindung aufbauen zu einem externen Rechner und dem die Logdaten regelmäßig schicken. Der externe Rechner kann die dann signieren, fälschungssicher abspeichern und so weiter.
Sprich: Git?
Wär vielleicht gar nicht schlecht, aber man müsste gut analysieren, ob das den Anforderungen an Fälschungssicherheit genügt. Vielleicht hat der Client damit auch schon zu viel Arbeit, denn er muss dann auch immer die komplette history vorliegen haben, um committen zu können. Ich hätte eher an ein System gedacht, das nur in eine Richtung kommunizieren kann: Der Client kann Logs zum Server schicken, aber in die Gegenrichtung findet praktisch keine Kommunikation statt abgesehen vom notwendigen SSL-Handshake oder ähnlichem.
-
Sobald der Client per TCP senden kann, kann er einen beliebigen Upload-Space mieten. Wenn ich mich recht erinnere, sollten auch Nicht-PCs klappen. Insbesondere Geräte, die zwar Fat16 oder Fat32 können, aber nicht mehr an Treibern installieren lassen.
-
Christoph schrieb:
Aber mal ein ganz anderer Vorschlag: Braucht man unbedingt USB-Sticks?
Jein; es könnte auch in Form einer SD-Karte daherkommen. Bedingung ist, dass der Host nichts weiter können muß, als Daten zu speichern. Und dass bereits gespeicherte Inhalte nicht manipuliert werden können, indem man das Speichermedium z.B. in einen PC steckt, um es mit einem Low-Level-Tool zu bearbeiten.
-
Wilde Idee: WLAN-Stick, der die Daten extern speichert und lokal die Daten spiegelt und sich dabei als ein USB-Massenspeicher ausgibt? Würde, wenn ich das richtig sehe, alle Anforderungen erfüllen. Die ganze Logik die du möchtest, würde dann ein Programm auf dem Server machen. Wäre wohl nur nicht ganz trivial zu bauen. Oder muss das Ding weit reisen, so dass du kein lokales WLAN hast?
-
SeppJ schrieb:
Oder muss das Ding weit reisen, so dass du kein lokales WLAN hast?
Ja, es muß auch funktionieren, wenn der Stick sich an einem Datenlogger befindet, an einer Maschine die irgendwo draußen in der Pampa steht, wo selbst per GSM/GPRS kein Netzwerkverkehr möglich ist.
