"Fälschungssicherer" USB-Stick
-
@rüdiger:
Klar kann man die Schreibzugriffe dort "verbieten".
Man kann dem OS aber nicht kommunizieren dass es ein "verboten" Fehler ist, im Gegensatz zu einem "bin kaputt" Fehler.Ich verstehe echt nicht was daran so schwer zu verstehen ist.
Es ist sicherlich möglich, den Schutz in einem USB Mass-Storage-Device zu implementieren. Das bestreite ich nicht. Nur dass ich glaube, dass dieses USB Mass-Storage-Device dann vermutlich nicht mehr sinnvoll anwendbar ist, weil einem das OS dauernd Fehler-Dialoge um die Ohren schmeisst sobald ein Zugriff "verboten" wurde.
Und zwar "kaputt" Fehler, nicht "verboten" Fehler.Davon abgesehen könnte es vermutlich passieren, dass das OS etwas machen möchte was eigentlich erlaubt sein sollte, es aber auf eine Art und Weise macht, so dass der Stick den Zugriff trotzdem verweigern muss.
-
hustbaer schrieb:
@Z: Ich glaube du verstehst uns, bzw. die Computer und das mit dem Programmieren nicht richtig.
Nein, ihr versteht mich nicht. Und ich weiß nicht wieso.
hustbaer schrieb:
Das OS rechnet nicht damit dass ein Massenspeicher Zugriffe "verweigert", weil sie nicht "erlaubt" sind.
Es würde also bald entscheiden, dass der Stick kaputt ist, und das dem User melden. Sicher nicht das was du willst.Aus Sicht des OS bzw. dessen Filesystem-Treiber können "verbotene" Schreibzugriffe erfolgreich sein, sie dürfen nur physikalisch nichts verändern, respektive bereits bestehende Dateinhalte überschreiben. Dateien und ihr Inhalt sollen wie "eingebrannt" sein.
hustbaer schrieb:
Dann müsstest du "nur noch" Windows/... beibringen dass es OK ist wenn ein USB Stick mit UDF/VAT ist.
Danke, aber daran scheitert dein Vorschlag. Windows, oder welcher Host auch immer den Speicherstick benutzt, soll einen "normalen" FAT-formatierten Stick vorfinden, ohne dass dem Host auf irgendeine Weise irgendetwas untergeschoben wird.
hustbaer schrieb:
EDIT: mann bin ich blöd. Es reicht überhaupt wenn du dem Stick beibringst sich als DVD-Writer zu melden, der eine DVD-R eingelegt hat. Formatiert braucht der im Prinzip gar nicht sein. Der Stick müsste sich dann bloss noch merken welche Sektoren bereits geschrieben wurden, und das Überschreiben solcher einfach mit einem Fehler quittieren.
Easy.
Das hört sich in der Tat nach einer brauchbaren Idee (als "Plan B" an), sollte sich das Abfangen von FAT-Aktionen als zu schwierig erweisen. Diese Variante hat aber leider den Nachteil, dass nicht jeder USB-Host mit DVDs umgehen kann, wie beispielsweise ein Datenlogger der auf FAT-formatierte Sticks angewiesen ist.
Btw, eine Idee ging mir vorhin noch durch den Kopf: ein mit 4GB Flash ausgestatteter Stick, könnte sich als 2GB-Stick ausgeben, so dass eine "Partition" die Arbeitspartition ist, während die andere eine Kopie der vorherigen Session enthält. Nach Beendigung einer Session würde dann ein Abgleich der FAT und aller Dateien stattfinden, wobei überschriebene Sektoren und gelöschte Dateien auf den vorherigen Stand gebracht werden, während alles neu Hinzugekommene beibehalten wird.
Das Problem dabei ist aber, dass diese "Sessions" irgendwie definiert werden müssten, d.h. wann der Abgleich stattfindet. Ein geeigneter Zeitpunkt hierfür, scheint mir jedes Einstecken des Sticks zu sein. Zu Beginn einer Session, würde der Stick mitloggen welcher Sektor beschrieben wurde, d.h. Sektornummer und Hash-Wert des Inhalts speichern.
Ich hoffe, meine Erklärung war nicht wieder zu kompliziert. Und ja, ich gebe zu, dass mein Vorhaben ziemlich ungewöhnlich ist.
-
hustbaer schrieb:
Und weil die Geräte auch ganz unterschiedliche Vorstellungen davon haben werden was in welcher Reihenfolge geschrieben wird.
Gut erkannt. Das halte ich für ein Riesenproblem, das gegen eine Echtzeit-FAT-Analyse spricht.
Übrigens: ich kann den Stick auch mit ein paar MB RAM ausstatten. Er darf auch ruhig etwas größer sein, als ein handelsüblicher USB Stick.
-
Ich glaube ich verstehe worauf du hinaus willst.
Ich glaube aber immer noch, dass es nicht ordentlich funktionieren wird.Angenommen der Host macht genau das, was der Stick verhindern will.
Er schreibt z.B. in ein File
<data />Und später überschreibt er es mit
<data foo="1" bar="2" />In deinem Magick-Stick steht dann nach dem "Abgleich"
<data />o="1" bar="2" />
also blanker Unsinn.Oder willst du auch das Anhängen von neuen Daten an bestehende Dateien verbieten?
Nach Beendigung einer Session würde dann ein Abgleich der FAT und aller Dateien stattfinden, wobei überschriebene Sektoren und gelöschte Dateien auf den vorherigen Stand gebracht werden, während alles neu Hinzugekommene beibehalten wird.
Was machst du mit neu hinzugekommen Daten die keinen Platz mehr haben? Wie entscheidest du wenn der Speicher ausgeht welche Änderungen noch übernommen werden, und welche verworfen?
-
hustbaer schrieb:
@rüdiger:
Klar kann man die Schreibzugriffe dort "verbieten".
Man kann dem OS aber nicht kommunizieren dass es ein "verboten" Fehler ist, im Gegensatz zu einem "bin kaputt" Fehler.Ich verstehe echt nicht was daran so schwer zu verstehen ist.
Es ist sicherlich möglich, den Schutz in einem USB Mass-Storage-Device zu implementieren. Das bestreite ich nicht. Nur dass ich glaube, dass dieses USB Mass-Storage-Device dann vermutlich nicht mehr sinnvoll anwendbar ist, weil einem das OS dauernd Fehler-Dialoge um die Ohren schmeisst sobald ein Zugriff "verboten" wurde.
Und zwar "kaputt" Fehler, nicht "verboten" Fehler.Davon abgesehen könnte es vermutlich passieren, dass das OS etwas machen möchte was eigentlich erlaubt sein sollte, es aber auf eine Art und Weise macht, so dass der Stick den Zugriff trotzdem verweigern muss.
Es gibt doch "Lockable Mass Storage" als Subklasse. Das dürfte also irgend wie vom Protokoll unterstützt werden. Im Notfall gibt es in den SCSI-Instruktionen sicher einen Weg, in dem man mitteilen kann, dass das Device nicht beschreibbar aber lesbar ist (ansonsten wären SCSI-CD-Laufwerke ja nicht möglich).
-
hustbaer schrieb:
Ich glaube ich verstehe worauf du hinaus willst.
Das freut mich.
hustbaer schrieb:
Ich glaube aber immer noch, dass es nicht ordentlich funktionieren wird.
Angenommen der Host macht genau das, was der Stick verhindern will.
Er schreibt z.B. in ein File
<data />Und später überschreibt er es mit
<data foo="1" bar="2" />In deinem Magick-Stick steht dann nach dem "Abgleich"
<data />o="1" bar="2" />
also blanker Unsinn.Ja, natürlich. Für ein Programm das den Filepointer rückwärts bewegt und davon ausgeht, bestehende Daten überschreiben zu können, wird der Stick ungeeignet sein. Einsatzgebiete dieses "Special"-Sticks sollen Fälle sein, in denen Daten fälschungssicher gespeichert werden müssen. Nimm an, wir haben einen Datenlogger der irgendetwas auf USB-Sticks speichert. In der Regel wird hierbei der Filepointer nicht zurückversetzt, sondern es wird stumpf fortlaufend geschrieben. Um zu verhindern, dass jemand den Stick in seinen PC steckt um die gespeicherten Daten zu manipulieren, sollen bestehende Dateiinhalte "read-only" sein.
hustbaer schrieb:
Oder willst du auch das Anhängen von neuen Daten an bestehende Dateien verbieten?
Nein, das ist explizit erlaubt.
hustbaer schrieb:
Nach Beendigung einer Session würde dann ein Abgleich der FAT und aller Dateien stattfinden, wobei überschriebene Sektoren und gelöschte Dateien auf den vorherigen Stand gebracht werden, während alles neu Hinzugekommene beibehalten wird.
Was machst du mit neu hinzugekommen Daten die keinen Platz mehr haben? Wie entscheidest du wenn der Speicher ausgeht welche Änderungen noch übernommen werden, und welche verworfen?
Zu Beginn jeder Session (Einstecken des Sticks, Einschalten der Stromversorgung bei gestecktem Stick, etc.) findet ein Abgleich statt. Da die Arbeitspartition gleich groß ist wie die Backup-Partition, sollte es kein Platzproblem geben, da sich der Stick auch erst nach erfolgtem Abgleich als "bereit" melden wird.
-
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?
