"Fälschungssicherer" USB-Stick
-
SeppJ schrieb:
Das klingt nicht nach einem Fall, wo man sich auf das Wohlwollen des Hostcomputers verlassen sollte.
Eher nicht, denn bestehende Dateien auf dem Stick dürfen auch nicht von anderen Computern aus manipulierbar sein. Außer man hängt etwas an.
SeppJ schrieb:
Das muss dein Controller alles selber regeln...
Ja, er muß entscheiden, ob Schreibzugriffe auf einen Sektor zulässig sind oder nicht.
SeppJ schrieb:
Das dumme ist natürlich, dass dafür vermutlich ein eigener Treiber (oder ein Anwendungsprogramm zur Kommunikation) her muss.
Der Stick sollte sich nach Möglichkeit einem beliebigen Computer gegenüber wie ein gewöhnlicher, FAT-formatierter USB-Stick verhalten. Nur mit der Ausnahme, dass bestehende Dateiinhalte wie "eingebrannt" sind.
-
Z schrieb:
SeppJ schrieb:
Das klingt nicht nach einem Fall, wo man sich auf das Wohlwollen des Hostcomputers verlassen sollte.
Eher nicht, denn bestehende Dateien auf dem Stick dürfen auch nicht von anderen Computern aus manipulierbar sein. Außer man hängt etwas an.
Das meine ich doch. Du darfst keine Vermutungen machen, dass dein Stick auf eine bestimmte Weise angesprochen wird (z.B. wie ein FAT-Dateisystem). Alles was auf den Stick geschrieben wird sollte, deiner Beschreibung nach, vorher vom Controller ein grünes Licht erhalten. Dafür muss der aber auf der gleichen Abstraktionsebene wie die Daten (hier: Dateien) stehen, muss also selber das Dateisystem implementieren.
Wenn du nämlich einfach sagst, dass du die belegten Sektoren schützt, aber in den Sektoren der Dsteisystemtabelle Schreibzugriffe zulässt (das müsstest du nämlich, damit man neue Dateien schreiben kann), dann schicke ich dem Stick irgendwelche manipulierten Dateisystemeinträge, die alles kaputt machen.Es sollte sich doch auch machen lassen, dass der Stick sich zum Lesen wie ein normaler Massenspeicher verhält, aber wenn du das Schreiben auf Dateiebene machst, dürfte ein eigenes Programm dafür nötig sein. Oder vielleicht gibt es dafür auch schon ein Standardprotokoll, es gab früher ja durchaus Speichermedien, die ein eigenes Programm brauchten.
-
Ich glaube, du hast mich nicht richtig verstanden.
SeppJ schrieb:
Das meine ich doch. Du darfst keine Vermutungen machen, dass dein Stick auf eine bestimmte Weise angesprochen wird (z.B. wie ein FAT-Dateisystem).
Ich muß ein Dateisystem vorgeben, wie soll ich sonst sicherstellen, dass manche Schreibzugriffe erlaubt sind und andere nicht?
SeppJ schrieb:
Alles was auf den Stick geschrieben wird sollte, deiner Beschreibung nach, vorher vom Controller ein grünes Licht erhalten.
Nein, aus Sicht eines Anwendungsprogramms darf alles geschrieben werden, es dürfen nur keine Dateien gelöscht bzw. vorhandene Daten einer Datei verändert werden.
SeppJ schrieb:
Wenn du nämlich einfach sagst, dass du die belegten Sektoren schützt, aber in den Sektoren der Dsteisystemtabelle Schreibzugriffe zulässt (das müsstest du nämlich, damit man neue Dateien schreiben kann), dann schicke ich dem Stick irgendwelche manipulierten Dateisystemeinträge, die alles kaputt machen.
Willkürliche Schreibzugriffe auf die FAT müssen natürlich vom Stick abgefangen werden. Das muß auch funktionieren, wenn jemand mit einem Low-Level-Tool am PC die FAT manipulieren will. Der Stick darf nur erlaubte Operationen, wie Anlegen neuer Dateien und Beschreiben dieser, sowie Anhängen von Daten an bestehende Dateien akzeptieren. Lesezugriffe unterliegen natürlich keinerlei Einschränkung.
Es soll an jedem beliebigen Gerät (PC, ebook-Reader, HiFi-Anlage, whatever) funktionieren, das mit FAT-formatierten Sticks umgehen kann, ohne dass etwas zusätzlich installiert werden muß. Sämtliche Funktionalität soll in der Firmware des Sticks sein. Ich muß anhand der Schreiboperationen, die vom Host kommen, und dem Zustand des Sticks erkennen, was erlaubt ist und was nicht.
Dass sowas nicht trivial ist, habe ich mir schon gedacht.
-
@Z: Ich glaube du verstehst uns, bzw. die Computer und das mit dem Programmieren nicht richtig.
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.Du könntest aber was anderes machen: formatier den Stick ab Werk mit einem "Write-Only" Filesystem ala UDF/VAT. Dann erwartet das OS auch nicht, dass es bereits geschriebene Sektoren nochmal überschreiben kann. Gleichzeitig wird es ultra-trivial den Überschreibschutz im USB Stick selbst zu implementieren.
Dann müsstest du "nur noch" Windows/... beibringen dass es OK ist wenn ein USB Stick mit UDF/VAT ist.
Oder du bringst dem Stick bei sich als DVD-Writer zu melden. Das löst das Problem dass Windows/... sich darüber wundern dass das Ding mit UDF/VAT formatiert ist, denn für DVD ist das schliesslich was ganz normales.
Hm.
Ich denke das wäre wirklich praktikable Möglichkeit.
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.
-
hustbaer schrieb:
Das OS rechnet nicht damit dass ein Massenspeicher Zugriffe "verweigert", weil sie nicht "erlaubt" sind.
natuerlich rechnet ein OS damit, du kannst eine datei zum schreiben auf einem netzlaufwerk oeffnen und zwischendurch werden dir schreibrechte entzogen und dann meldet dir der schreibbefehl einen fehler. ganz normale funktionalitaet, zumal das manche programme benutzen um auf dateisystemebene atomics zu implementieren. (manche build systeme machen das, da man nicht drumherum kommt, dass die buildsysteme aus zusammengewuerfelter software bestehen und diese software natuerlich kein einheitliches netzwerkprotokoll spricht, aber dateien lesen/schreiben ist das kleinste gemeinsame).
Es würde also bald entscheiden, dass der Stick kaputt ist, und das dem User melden. Sicher nicht das was du willst.
das OS entscheidet sowas nicht, das macht bestenfalls der treiber fuers jeweilige device.
Du könntest aber was anderes machen: formatier den Stick ab Werk mit einem "Write-Only" Filesystem ala UDF/VAT. Dann erwartet das OS auch nicht, dass es bereits geschriebene Sektoren nochmal überschreiben kann. Gleichzeitig wird es ultra-trivial den Überschreibschutz im USB Stick selbst zu implementieren.
waere da nicht das problem, das jemand den stick raw ausliest (also alle daten hat) und dann FAT formatiert und alle daten draufschreiben koennte? oder kann man UDF/VAT formatierte sticks nicht mehr neuformatieren? (ich kenn mich mit UDF/VAT nicht aus!)
Dann müsstest du "nur noch" Windows/... beibringen dass es OK ist wenn ein USB Stick mit UDF/VAT ist.
waere das kompatibel zu den ganzen dingen wo er es nutzen will? z.b. HIFI anlage? ich dachte FAT waere das einzige worauf man sich verlassen koennte bei USB Sticks.
Oder du bringst dem Stick bei sich als DVD-Writer zu melden. Das löst das Problem dass Windows/... sich darüber wundern dass das Ding mit UDF/VAT formatiert ist, denn für DVD ist das schliesslich was ganz normales.
weshalb nicht gleich eine DVD? 9GB bekommt man drauf, kostet einen bruchteil vom stick und hat, wie du sagst, alle gewollten eigenschaften.
-
Der USB-Stick soll eine eigene Intelligenz mit eigenem Betriebssystem haben, also wie ein unabhängiger Computer im Netzwerk einsetzbar sein?
-
berniebutt schrieb:
Der USB-Stick soll eine eigene Intelligenz mit eigenem Betriebssystem haben...
also eigentlich hat doch jedes laufwerk einen controller chip mit firmware. gerade flash laufwerke haben leistungsfaehige, damit die haltbarkeit und geschwindigkeit gut ist.
-
@rapso
Das was du über Zugriffsrechte und Locking schreibst spielt sich alles eine Ebene höher ab.
Der File-System-Treiber ist Teil des OS. Zumindest habe ich meinen Beitrag mit dieser Definition von "OS" geschrieben.Der OP möchte das aber im USB-Stick implementieren.
Und der USB-Stick ist aus Sicht des Hosts (auf dem das OS mitsamt Treiber etc. läuft) nunmal ein Block-Storage-Device. Da gibt's keine Files und keine Rechte und kein garnix. Da gibt's nur Blocks, und die sind entweder immer read-only (bei nicht beschreibbaren Datenträgern wie CDs oder auch USB-Sticks mit Schreibschutzschalter), oder eben immer beschreibbar. Bzw. manchmal Write-Once, aber eben nur bei einigen wenigen Medien ala WORM/DVD-R/...
Jede "kann nicht Schreiben" Meldung des Block-Storage-Device wird vom OS als Hardwarefehler interpretiert. Manche OS' werden hergehen und versuchen über das File-System die betroffenen Blocks zu remappen, andere werden den Fehler einfach an die Applikation weiterleiten, andere werden den Datenträger vielleicht gar als Defekt markieren und alle Volumes auf read-only setzen, unmounten, oder andere unrewünschte Dinge machen.
Windows z.B. zeigt in so einem Fall gerne einen "Delay-Write Fehler, WWTF?!?!, ihre Daten sind u.U. kaputt, tut leid!" Dialog bei sowas an. Vermutlich nicht das was der OP will.
das OS entscheidet sowas nicht, das macht bestenfalls der treiber fuers jeweilige device.
Ja Kaisers Bart und so. Je nachdem wie man den Begriff OS interpretiert gehören die Treiber mit dazu oder auch nicht. Ist aber egal, da der OP es ja "in Hardware" lösen will wenn ich ihn richtig verstehe. Ob also ein Treiber oder das OS irgendwas komisch finden und in unerwünschter Art & Weise reagieren, ist vollkommen egal.
Du könntest aber was anderes machen: formatier den Stick ab Werk mit einem "Write-Only" Filesystem ala UDF/VAT. Dann erwartet das OS auch nicht, dass es bereits geschriebene Sektoren nochmal überschreiben kann. Gleichzeitig wird es ultra-trivial den Überschreibschutz im USB Stick selbst zu implementieren.
waere da nicht das problem, das jemand den stick raw ausliest (also alle daten hat) und dann FAT formatiert und alle daten draufschreiben koennte? oder kann man UDF/VAT formatierte sticks nicht mehr neuformatieren? (ich kenn mich mit UDF/VAT nicht aus!)
Bei UDF/VAT müssen nie Sektoren überschrieben werden. Ist im Prinzip vergleichbar mit ISO9660+Multisession.
Damit man die Daten nicht überschreiben kann, müsste der Stick Schreibzugriffe auf Sektoren die schonmal geschrieben wurden mit dem passenden Fehlercode verweigern. Den selben Code den auch ein Write-Once Medium ala DVD-R liefern würde wenn man es da versucht.Dann müsstest du "nur noch" Windows/... beibringen dass es OK ist wenn ein USB Stick mit UDF/VAT ist.
waere das kompatibel zu den ganzen dingen wo er es nutzen will? z.b. HIFI anlage? ich dachte FAT waere das einzige worauf man sich verlassen koennte bei USB Sticks.
Nö, wäre es nicht.
Aber exakt das, was der OP will, geht nach meiner Einschätzung nicht. Weil halt FAT/FAT32 nicht dafür geeignet ist. Weil die Geräte nicht damit rechnen dass da Schreibzugriffe verweigert werden. Und weil die Geräte auch ganz unterschiedliche Vorstellungen davon haben werden was in welcher Reihenfolge geschrieben wird.Oder du bringst dem Stick bei sich als DVD-Writer zu melden. Das löst das Problem dass Windows/... sich darüber wundern dass das Ding mit UDF/VAT formatiert ist, denn für DVD ist das schliesslich was ganz normales.
weshalb nicht gleich eine DVD? 9GB bekommt man drauf, kostet einen bruchteil vom stick und hat, wie du sagst, alle gewollten eigenschaften.
Weiss nicht, das musst du schon den OP fragen. Aber vermutlich wegen der Kompatibilität zu diversen nicht-PC Geräten.
Was natürlich wieder das KO für die DVD-Brenner Idee ist, aber wie gesagt: ich sehe keine Möglichkeit die Vorstellung des OP sinnvoll und vollständig umzusetzen.
-
Auf dem USB-Stick ist doch ein Microcontroller, der das USB-Mass-Storage Protokoll implementiert und entsprechend den Flash-Speicher ansteuert. Entsprechend kannst du dort doch einfach die Schreiboperationen verbieten.
-
@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.
