Ich bin mir nicht sicher ob es in Deutschland überhaupt erlaubt ist so etwas zu realisieren, dennoch würde mich interessieren ob mein erdachtes System zur sicheren Botschaftsübermittlung sicher ist. Ein AtXmega Controller schreibt auf 2 speicherkarten mittels seines "Echten" Zufallszahlengenerators etwa 1000 1MByte große One Time Pads mit Zufallswerten. Eine Karte gebe ich Allice mit. An ihm hängen ausserdem eine Tastatur und ein Display nun gebe ich meine Botschaft ein, diese wird mit einem OTP verschlüsselt. Der Controller schickt die Daten über die serielle Schnittstelle an den PC, nun kann ich Allice eine E-Mail mit der Datei schicken, dabei gebe ich (im Klartext) an welches OTP ich verwendet habe. Sie holt sich die Datei und schickt sie ihr AtXmega-Board, nun gibt sie ein welches OTP für die Decodierung verwendet werden soll. Sie list meine Botschaft... Natürlich wird nach gebrauch eines OTP dieses vielfach mit Zufallswerten überschrieben. Der Empfänge bekommt z.b. 5Min Zeit die Nachricht zu lesen bevor der Schlüssel gelöscht wird. So lohnt es sich für Eve auch nicht, danach den Schlüssel klauen zu wollen. Das System arbeitet mit uC, da der PC von Sender/Empfänger bereits gehackt sein könnte.
Bob schrieb: > Ich bin mir nicht sicher ob es in Deutschland überhaupt erlaubt > ist so etwas zu realisieren, Wer sollte Dir das verbieten können? Da müsste man schon Verschlüsseln generell verbieten...
OTP's sind generell sicherer als mathematische verschlüsselungsverfahren, soweit richtig. die frage ist gegen wen du dich schützen willst, und wie viel interesse derjenige hat an deine kommunikation zu kommen. falls das z.b. die staatsorgane sein sollten nutzen auch OTP's wenig, denn die holen sich mit ihren bewaffneten truppen einfach das was sie haben wollen, und wenn das nicht reicht fragen sie einfach dich und/oder alice was in den nachrichten stand… nach einem halben jahr in einzel-beuge(folter)-haft. so, was soll dein system also leisten was gpg nicht bereits kann?
c.m. schrieb: > OTP's sind generell sicherer als mathematische > verschlüsselungsverfahren, soweit richtig. OTP ist ein (oder das einzige?) praktisch und theoretisch 'unknackbares' Verschlüsselungsverfahren. Bob schrieb: > Der Empfänge bekommt z.b. 5Min Zeit die Nachricht zu lesen bevor der > Schlüssel gelöscht wird. > So lohnt es sich für Eve auch nicht, danach den Schlüssel klauen zu > wollen. Man kann diese Karte aber kopieren für den Fall, dass man die Nachricht später nochmal lesen möchte.
Bob schrieb: > Natürlich wird nach gebrauch eines OTP dieses vielfach mit Zufallswerten > überschrieben. > Der Empfänge bekommt z.b. 5Min Zeit die Nachricht zu lesen bevor der > Schlüssel gelöscht wird. > So lohnt es sich für Eve auch nicht, danach den Schlüssel klauen zu > wollen. Und wenn Eve im Voraus unbemerkt an den Satz der OTPs kommt?
Bob schrieb: > Ich bin mir nicht sicher ob es in Deutschland überhaupt erlaubt ist so > etwas zu realisieren, dennoch würde mich interessieren ob mein erdachtes > System zur sicheren Botschaftsübermittlung sicher ist. Ein Klassiker im neuen Gewande. Ob man Zufallszahlen ausdruckt und nach Gebrauch verbrennt oder auf elektronisches Medium schreibt und danach überschreibt ist prinzipiell gleich. Nur dass deine Speicherkarte wahrscheinlich ein Flash-Medium ist, das beim scheinbaren Überschreiben die Daten nicht wirklich überschreibt, sondern an eine andere Stelle des Flash-Chips neu schreibt und die alten da lässt wo sie waren. Da kommst dann zwar Du nicht mehr ran, aber Andere mit entsprechender Kenntnis evtl. schon. Da bist Du mit einer 1,8er HDD besser dran als mit einer SD-Karte oder einem USB-Stick. Das Problem bei symmetrischer Verschlüsselung ist seit jeher die sichere Übermittlung des Schlüssels, nicht das unknackbare Prinzip. Das Schöne an asymmetrischer Verschlüsselung ist nicht die prinzipiell knackbare Verschlüsselung, sondern dass man keinen sicheren Weg zur Übertragung eines geheimen Schlüssels benötigt.
A. K. schrieb: > Das Problem bei symmetrischer Verschlüsselung ist seit jeher die sichere > Übermittlung des Schlüssels, nicht das unknackbare Prinzip. Das Schöne > an asymmetrischer Verschlüsselung ist nicht die prinzipiell knackbare > Verschlüsselung, sondern dass man keinen sicheren Weg zur Übertragung > eines geheimen Schlüssels benötigt. Es kommt halt auf die Anwendung an. Nur als Beispiel, es würde für Heimarbeit in sicherheitskritischen Bereichen ausreichen, einmal im Monat einen GB-Stick mit einem OTP zu beschreiben und dafür eine perfekt sichere Verschlüsselung zu haben. Dass man weitere Maßnahmen treffen müsste, um Angriffe außerhalb der Verschlüsselung zu verhindern, ist natürlich klar. In wie weit das sinnvoll ist, ist eine andere Frage.
Mac Gyver schrieb: > Wer sollte Dir das verbieten können? > Da müsste man schon Verschlüsseln generell verbieten... Tja, ihr Jungspunde. Das wäre vor ca. 20 Jahren fast passiert. Das war politische Alltag. Crypto-Software wurde z.B. in den USA als Buchform publiziert um Gesetze zum Export zu umgehen. Frankreich hatte/wollte strenge Gesetze gegen Crypto. Und heute: Siehe die aktuelle Debatte diese Wochen in den USA: Da möchte die Regierung verhindern dass Smartphone-Hersteller echte Verschlüsselung auf ihren Geräten anbieten. Nicht alles auf dieser Welt ist so selbstverständlich wie es manchmal scheint. Da wurden schon einige Schlachten geschlagen und es werden im Bereich Crypto auch wieder neue Schlachten zu schlagen sein!
A. K. schrieb: > Nur dass deine Speicherkarte wahrscheinlich ein Flash-Medium ist, das > beim scheinbaren Überschreiben die Daten nicht wirklich überschreibt, > sondern an eine andere Stelle des Flash-Chips neu schreibt und die alten > da lässt wo sie waren. Wohl kaum. Speicherkarten machen das genauso wenig wie die Floppys oder irgendein anderer Speichermedium. DOS ist dafür zuständig. Bob schrieb: > Natürlich wird nach gebrauch eines OTP dieses vielfach mit Zufallswerten > überschrieben. Und damit ist OTP, zumindest bei Speicherkarten, 100% weg.
OTP ist tot bevor's begonnen hat. Man muesste das OTP naemlich sicher uebermitteln. Mach das mal.
Dussel schrieb: > c.m. schrieb: >> OTP's sind generell sicherer als mathematische >> verschlüsselungsverfahren, soweit richtig. > OTP ist ein (oder das einzige?) praktisch und theoretisch 'unknackbares' > Verschlüsselungsverfahren. nah. theoretisch nur, wenn man in seinem modell die praktischen angirffsvektoren weglässt. praktisch bedeutet in dem fall das man nicht versucht mathematisch zu entschlüsseln (wie auch?), sondern versucht durch gewalt oder finesse an entweder die pads, oder die nachricht zu kommen. wenn du gesetze, die dir bestimmte methoden verbieten weglässt, wie würdest du denn versuchen an die nachricht zu kommen?
Marc Vesely schrieb: > Und damit ist OTP, zumindest bei Speicherkarten, 100% weg. Eben nicht. Informier dich mal über das sog. Wear-Leveling bei Flash-Speichern.
Ihr denkt zu technisch. Es genuegt wenn man den Ueberbringer des OTP wegen einer Affaire, Schulden, usw. kompromitieren kann. Das ist viel einfacher. Das waer dann der Langzeitnutzen der Social Media. Wenn man weiss wer mit wem aufgewachsen ist, ...
Lars schrieb: > Eben nicht. Informier dich mal über das sog. Wear-Leveling bei > Flash-Speichern. Eben doch. Erstens haben das nicht alle SD. Zweitens überschreibt man solche Daten mit SectorWrite. Oder glaubst du im Ernst, dass jemand, der sich soviel Mühe mit Verschlüsselung gibt, so nachlässig beim überschreiben wird ?
:
Bearbeitet durch User
Marc Vesely schrieb: > Lars schrieb: >> Eben nicht. Informier dich mal über das sog. Wear-Leveling bei >> Flash-Speichern. > > Eben doch. > Erstens haben das nicht alle SD. > Zweitens überschreibt man solche Daten mit SectorWrite. > Oder glaubst du im Ernst, dass jemand, der sich soviel Mühe mit > Verschlüsselung gibt, so nachlässig beim überschreiben wird ? was soll denn "sectorwrite" sein? glaubst du wirklich das du durch all die abstraktiosschichten, fs-ioctl, fs-journal, schnittstellencontroller, flash-onchip µc, wirklich die kontrolle darüber hast wo was auf deinem blockdevice überschrieben wird? schau dir mal an was die LUKS-entwickler gemacht haben um die keyslots verschlüsselter devices nicht restaurierbar zu machen. "sectorwrite"… in einer idealisierten welt vielleicht.
Wenn er einen XMega verwendet kann er das OPT aber mit AES vom AVR verschlüsseln lassen. Der Key muss er halt ins Programm schreiben und die Lesefuse am AVR setzen. Endschlüsselt wird umgekehrt. So sind die OTPs wenigstens "etwas" geschützt!
Siebzehn Zu Fuenfzehn schrieb: > OTP ist tot bevor's begonnen hat. Man muesste das OTP naemlich sicher > uebermitteln. Mach das mal. Das Problem hast du aber im Prinzip mit jedem anderen Kryptoverfahren auch. Die andere Seite kann sich nicht wirklich sicher authentifizieren, außer man schüttelt ihr die Hand, im wörtlichen Sinne.
:
Bearbeitet durch User
c.m. schrieb: > was soll denn "sectorwrite" sein? glaubst du wirklich das du durch all > die abstraktiosschichten, fs-ioctl, fs-journal, > schnittstellencontroller, flash-onchip µc, wirklich die kontrolle > darüber hast wo was auf deinem blockdevice überschrieben wird? Nein, so natürlich nicht. Aber selbst mit LBA und onchip uC, nn Sectors sind vorhanden und da werden eben nn Sectors geschrieben - da hilft kein uC und auch Blocks können beliebig versetzt werden - irgendwann kommen die dran, ob als Sector 1 oder als Sector nn-1 ist eigentlich egal.
Ein OTP ist kein Verschlüsselungsverfahren. Genauso wie Schrödingers Katze kein physikalisches Experiment ist. Die Überlegung, wie man ein OTP richtig implementiert ist etwa so sinnvoll wie die Frage welches Katzenfutter man Schrödingers Katze geben soll ;) Der OTP ist ein Gedankenexperiment, das Eigenschaften eines perfekten Kryptosystems ausloten soll. Eine Eigenschaft (unter anderen) eines perfekten Kryptosystems besteht darin, daß wenn man dem Angreifer zusätzlich zum Geheimtext noch den echten Klartext und einen falschen Klartext (der natürlich die gleiche Länge haben muß) gibt, er dann nicht feststellen kann, welcher der Klartexte der richtige ist. Es müssen einfach alle zu einem Geheimtext längenmäßig passenden Klartexte gleich wahrscheinlich sein. Ein offensichtlicher Weg, deses Ziel zu erreichen, besteht darin daß man einen Schlüssel verwendet, der a) wahrhaftig zufällig ist b) mindestens so lang wie die Nachricht ist (er wird also nicht innerhalb einer Nachricht wiederholt) c) nach dem Gebrauch vernichtet wird (er wird also auch nicht für verschiedene Nachrichten wiederholt) Die Probleme des OTP sind ebenso offensichtlich. Man braucht nicht nur eine gute Zufallszahlenquelle (allein das ist ein hartes Problem). Man muß auch die generierten Schlüssel zuverlässig von Alice zu Bob übertragen und sie dann bis zum Gebrauch geheim halten. Es gibt Gerüchte, daß während des kalten krieges Geheimdienste mit ihren Agenten via OTP kommuniziert haben. Halte ich für Blödsinn. XL
Marc Vesely schrieb: > Speicherkarten machen das genauso wenig wie die Floppys oder irgendein > anderer Speichermedium. DOS ist dafür zuständig. Flash-Speicher läässt sich prinzipbedingt nicht sektorweise überschreiben. Weshalb es unterhalb der Filesystemebene eine weitere Verwaltungsebene gibt und ein Sektor nach jedem Schreibvorgang an anderer Stelle im Flash zu liegen kommt. Der alte Inhalt bleibt danach noch eine unbekannte Zeit erhalten, ohne dass man jedoch vom Betriebssystem aus ohne weiteres aus darauf zugreifen könnte. Filesysteme wie FAT oder NTFS schreiben immer und immer wieder an die selbe Stelle. Dafür geeignete Flash-Medien müssen wear levelling benutzen, sonst sind sie im Handumdrehen in Eimer. Flash-Medien haben oft mehr physikalische Sektoren, als sichtbar sind. Wann genau alle Daten in den Flash-Chips überschrieben sind ist folglich von aussen nicht sicher erkennbar, es sei denn man kennt das Verfahren der Flash-Controllers.
:
Bearbeitet durch User
Axel Schwenke schrieb: > Es gibt Gerüchte, daß während des kalten krieges Geheimdienste mit ihren > Agenten via OTP kommuniziert haben. Halte ich für Blödsinn. http://en.wikipedia.org/wiki/One-time_pad#Historical_uses
Axel Schwenke schrieb: > Es gibt Gerüchte, daß während des kalten krieges Geheimdienste mit ihren > Agenten via OTP kommuniziert haben. Halte ich für Blödsinn. Wieso Gerüchte? https://www.youtube.com/watch?v=egzVftWCCao Die Brieftaube ist mumifiziert, der Code bis heute ungeknackt.
A. K. schrieb: > http://en.wikipedia.org/wiki/One-time_pad#Historical_uses Marek N. schrieb: > Youtube-Video "The curious case of the WWII carrier pigeon and the > unbreakable code" > Die Brieftaube ist mumifiziert, der Code bis heute ungeknackt. Genau so etwas meinte ich mit "Gerüchte". Mal ganz davon abgesehen, daß man aus Geheimdienstkreisen sowieso notorisch angelogen wird. Aus verschiedenen Gründen natürlich. Aber trotzdem gelogen. XL
Jedes Crypto verfahren kann geknackt werden. Es gibt kein 100% sicheres Verfahren. Der Unterschied ist nur wie viel Aufwand muss investiert werden. Da kommt es dann darauf an Wer mit Wem über Was kommuniziert. Und ob es dann jemanden gibt der ausreichend Interesse an dieser Kommunikation und die notwendigen Rechenkapazität hat um an diese Arbeit zu gehen.
Ralph schrieb: > Jedes Crypto verfahren kann geknackt werden. OTP kann aber nicht im eigentlichen Cryptoverfahren selbst geknackt werden. Egal wieviel Rechenleistung dir zur Verfügung steht. Sondern nur im Drumherum, wie dem Umgang mit dem Schlüsselbuch oder durch intensive Behandlung der beteiligten Personen. > Es gibt kein 100% sicheres Verfahren. Richtig.
:
Bearbeitet durch User
A. K. schrieb: > Flash-Speicher läässt sich prinzipbedingt nicht sektorweise > überschreiben. Weshalb es unterhalb der Filesystemebene eine weitere > Verwaltungsebene gibt und ein Sektor nach jedem Schreibvorgang an > anderer Stelle im Flash zu liegen kommt. Der alte Inhalt bleibt danach Soll ich es dir nochmals erklären oder liest du es selber ? Abgesehen davon, dass jeder normale Mensch (Spion ?) wohl kaum den selben Flash zweimal benutzen oder aufbewahren würde. A. K. schrieb: > Flash-Medien haben oft mehr physikalische Sektoren, als sichtbar sind. > Wann genau alle Daten in den Flash-Chips überschrieben sind ist folglich > von aussen nicht sicher erkennbar, es sei denn man kennt das Verfahren > der Flash-Controllers. Das ist mir neu. Es sei denn, du redest vom Speicher der für Fehlererkennung zuständig ist. Nur auf diesen Teil kannst du von aussen nicht zugreifen.
:
Bearbeitet durch User
Marc Vesely schrieb: > Soll ich es dir nochmals erklären oder liest du es selber ? > Abgesehen davon, dass jeder normale Mensch (Spion ?) wohl kaum den > selben Flash zweimal benutzen oder aufbewahren würde. Deine Arroganz gespickt von Unkenntnis ist unerträglich. > Das ist mir neu. > Es sei denn, du redest vom Speicher der für Fehlererkennung zuständig > ist. Nur auf diesen Teil kannst du von aussen nicht zugreifen. Blödsinn. Flash-Speicher hat jede Menge Sektoren, auf die der interne Flash-Controller ersatzweise zugreift - gerade wenn Du mehrfach immer dieselbe Stelle beschreibst. Der Grund ist: Die Anzahl von Schreibzugriffen gleichmäßig über das Medium verteilen. Wenn Du versuchst, mehrfach auf immer wieder denselben Sektor zu schreiben, kannst Du stark davon ausgehen, dass genau das nicht passiert. Das Stichwort dazu wurde Dir bereits genannt, ich werde es nicht wiederholen. Natürlich kannst Du nicht "von außen" auf so einen Sektor zugreifen, weil der Flash-Controller diesen auf die neue Stelle mappt. Aber wenn Du das Flash auslötest, kannst Du dies mit einem eigenen Controller schon. Auszug aus http://de.wikipedia.org/wiki/Solid-State-Drive : "Methoden der Nutzungsverteilung [...] Bei jeder Änderung in einem seiner Blöcke wird dieser zunächst nicht gelöscht, sondern vorerst als nicht mehr aktuell markiert. Geschrieben wird in den nächsten freien Block desselben Erasable Block. Erst wenn alle Blöcke eines Erasable Block nicht mehr aktuell sind, wird dieser einmal ganz gelöscht. Dynamic Wear Levelling Soll ein Erasable Block beschrieben werden, wird hier von den noch nicht belegten der am wenigsten abgenutzte ausgewählt. Das ist vergleichsweise einfach im Controller umzusetzen, hat aber den Nachteil, dass bei gut gefülltem Laufwerk der wenige freie Platz schneller abgenutzt wird. Die Schreibzyklen steigen um den Faktor 25 gegenüber fehlendem Wear-Levelling. Static Wear Levelling Soll ein Block beschrieben werden, wird hier der am wenigsten abgenutzte ausgewählt. Ist dieser schon belegt, werden dessen Daten auf einen anderen umverlagert, dann die neuen Daten geschrieben. Das erfordert einen etwas komplexeren Controller, führt aber zu sehr gleichmäßiger Abnutzung. Die Schreibzyklen steigen um den Faktor 100 gegenüber fehlendem Wear-Levelling."
:
Bearbeitet durch Moderator
Frank M. schrieb: > Blödsinn. Flash-Speicher hat jede Menge Sektoren, auf die der interne > Flash-Controller ersatzweise zugreift - gerade wenn Du mehrfach immer > dieselbe Stelle beschreibst. Der Grund ist: Die Anzahl von > Schreibzugriffen gleichmäßig über das Medium verteilen. Blödsinn. Deine Dummheit gespickt von Arroganz und Unkenntnis ist unerträglich. Ich versuche es nochmals, ganz langsam, da du offenbar Schwierigkeiten beim Lesen hast. Es sind genau nn Sektoren vorhanden, die nutzbar sind. Wie diese Sektoren verteilt sind und ob Sektor 0 immer auf derselben Stelle im Flash liegt, interessiert keine Sau. Marc Vesely schrieb: > Aber selbst mit LBA und onchip uC, nn Sectors sind vorhanden und da > werden eben nn Sectors geschrieben - da hilft kein uC und auch Blocks > können beliebig versetzt werden - irgendwann kommen die dran, ob als > Sector 1 oder als Sector nn-1 ist eigentlich egal. Wenn ich also Sectors von 0 bis nn-1 mit Nullen vollschreibe, werden eben alle Sectors mit Nullen aufgefüllt, egal wie die gemappt sind. Hoffentlich konnte ich dir in deiner Unkenntnis helfen, was deine Arroganz betrifft, da kommt jede Hilfe zu spat. Selbst dein Googlewissen hilft da wenig.
:
Bearbeitet durch User
Marc Vesely schrieb: > Blödsinn. > Deine Dummheit gespickt von Arroganz und Unkenntnis ist unerträglich. Schön, dass Du es genauso siehst. Ich hatte mich nämlich eben bemüht, Deine Umgangsformen, die Du hier im Forum in diversen Thread pflegst, zu übernehmen, als ich Dir antwortete. Hat ja geklappt. Jetzt brauchst Du nur noch in den Spiegel zu sehen.... ;-) > Wenn ich also Sectors von 0 bis nn-1 mit Nullen vollschreibe, werden > eben alle Sectors mit Nullen aufgefüllt, egal wie die gemappt sind. Im Ursprungsbeitrag war davon die Rede, dass gezielt ein OTP auf dem Medium überschrieben wird. Genau darauf hat A.K. reagiert. Jetzt willst Du plötzlich das ganze Medium plattmachen und den ganzen Stick zu einem OTP erklären. Das war aber nicht die Ursprungsidee. > Hoffentlich konnte ich dir in deiner Unkenntnis helfen, was deine > Arroganz betrifft, da kommt jede Hilfe zu spat. Gut, dass Du Dich nun selbst erkennen konntest. Glückwunsch! :-)
Frank M. schrieb: > Im Ursprungsbeitrag war davon die Rede, dass gezielt ein OTP auf dem > Medium überschrieben wird. Genau darauf hat A.K. reagiert. Und wie immer hast du konstruktiv darauf reagiert und etwas sehr sinnvolles und hilfreiches geschrieben. Höfflich war es natürlich auch. Deine Umgangsformen werden nur noch von deinem IQ unterboten. EOD
:
Bearbeitet durch User
Marc Vesely schrieb: > Deine Umgangsformen werden nur noch von deinem IQ unterboten. Du hast es immer noch nicht verstanden: Ich habe oben Deine Umgangsformen einmalig kopiert, um sie Dir vor Augen zu führen, mein Lieber. Mehr nicht. Denn so wie Du möchte ich bestimmt nicht sein.
:
Bearbeitet durch Moderator
Heutzutage sind sogar die strippen zum Steckernetzteil verwanzt. Und zwar so dass man es nicht merkt. Reichweite 40 Meter. Überprüfe die Nachbarn mit Mondgesicht.
Mal ab von "Wandwanzen" (Wandwarze + Waze), "Umgangsformen" und "Blödsinn" und zurück in Richtung Topic : Wie sieht das eigentlich aus, wenn ich meinen Schlüssel nun auf einem Flash -Speicher habe und ihn "lösche". Dann sind ja die Informationen, wo der Schlüssel nun genau liegt, weg. Das heißt, ich habe zwar die Information in Stücken, weiß aber nicht, wie sie zusammen gehört und was "zufälliger" Müll dazwischen ist. Das heißt doch: Auf dem Flash gelöscht, heißt unwiederbringlich. Auch bei Zugriff auf den Chip. Primitive_ _Verbildlichung_ _aus_ _meinem_ _rosa_ _Gummibärchenland : Ich sage der SD "schreibe":
1 | Ganz geheimer schlüssel. Nicht weitergeben. |
Der Controller schreibt gemapped :
1 | MüLlDaTe N.Nicht weiterge asfdben .MüLGanz geheimer schlüsse llDaTeN |
Da sind nun MüLlDaTeN und asdf als zufälliger Dreck drin. Aber der Controller hat irgendwo die Information gespeichert, wie das zu "Ganz geheimer schlüssel. Nicht weitergeben." werden kann. "lösche" ich diese Information nun und schreibe noch ein paar mal "bla", dann habe ich sowas wie
1 | MüLBlaTe N.Nicht blaterge asfdben .Müblanz blablar scblabla llDabla |
Ich wüsste nicht, wie man daraus wieder Klartext machen sollte, zumal es sich nicht um vernünftig zu rekonstruierenden Text handelt, sondern um möglichst echte Zufallszahlen des OTP.
Lukas T. schrieb: > Ich sage der SD "schreibe": >
1 | Ganz geheimer schlüssel. Nicht weitergeben. |
> > Der Controller schreibt gemapped : >
1 | MüLlDaTe N.Nicht weiterge asfdben .MüLGanz geheimer schlüsse |
2 | > llDaTeN |
> Da sind nun MüLlDaTeN und asdf als zufälliger Dreck drin. Aber der > Controller hat irgendwo die Information gespeichert, wie das zu > "Ganz geheimer schlüssel. Nicht weitergeben." > werden kann. Okay, so weit habe ich das verstanden. > "lösche" ich diese Information [...] Du meinst, Du löschst die interne Controller-Info, wie welcher Block zu mappen ist? Wie machst Du das? Das geht nur unter Umgehung des Controllers. Ergo: Du brauchst einen eigenen Controller. Und wenn Du den schon einsetzt, dann lass ihn einfach dran und implementiere ein eigenes Speicherverfahren ohne Wear Levelling. ;-) > nun und schreibe noch ein paar mal "bla", Ja, dann hast Du tatsächlich Salat. Aber: Ist die Verschlüsselung ein einfaches XOR mit dem OTP, könnte man durchaus Bruchstücke der Nachricht rekonstruieren, da das OTP ja teilweise noch erhalten ist. Das gleiche gilt für kompliziertere Anwendung der OTP. Dann dauerts einfach länger.
Lukas T. schrieb: > MüLBlaTe N.Nicht blaterge asfdben .Müblanz blablar scblabla llDablaIch > wüsste nicht, wie man daraus wieder Klartext machen sollte, zumal es > sich nicht um vernünftig zu rekonstruierenden Text handelt, sondern um > möglichst echte Zufallszahlen des OTP. Immer vorausgesetzt, Controller schreibt das auf genau denselben Sector. Macht der aber normalerweise nicht, da ist eine Tabelle mit Anzahl der Schreibvorgängen pro Sector und eine andere wo die Sectors gemappt werden. Sector mit der niedrigsten Zahl wird als nächster genommen und entsprechend gemappt. Alter Sector wird nicht gelöscht. Also, einzelne Sectors können nicht gelöscht werden, das wird erst gemacht wenn sie tatsächlich gebraucht werden. EDIT: Man nimmt einen Arduino mit 328P, da billiger als Flash, programmiert 30KB Schlüssel, und 2KB Programm. Da wird dem Arduino ganz einfach gesagt - Warte auf Word, dann Nachricht entschlüsseln, Schlüssel beginnt bei der angegebenen Adresse, empfangenes Byte mit Schlüssel+n XOR, Byte zurücksenden. Wenn 10Sec kein Zeichen empfangen wird, lösche deinen Flash.
:
Bearbeitet durch User
Ich wuerde dafuer ein Batteriegepuffertes RAM nehmen. Aussen an dem Kistchen einen Schalter ON/OFF. Und schwupp sind die Daten weg.
Es gibt Flash Speicher in SO8 bis zu 16 Mbyte, wobei 4 Mbyte sehr guenstig ist. Das sind reine Flash Speicher gleich wie kleinere i2c oder spi eeproms. Damit funktioniert es gut. Ich wuerde jedoch nicht den Flash loeschen, sondern ein Bit im Controller, sei es Flash als eeprom flaggen, dass der Code schon benutzt wurde. Code welcher mittels uC crypto key sowie crypto lfsr und crypto autokey geschuetzt ist. crypto lfsr heisst, dass teile des Codes inkl. eventuelle Positionsdaten des Codes benutzt werden die 9x lfsr Register zu laden.. Autokey heisst dass teile des Codes/Plaintext dazu benutzt werden den key zu verschluesseln. Damit kann man die RNG Daten relativ gut verstecken. Verschluesselte Checksum, Authid sowie timestamp sollten auch vorhanden sein. Wenn man wirklich grosse Datenmengen braucht, kann man mittels so eines Systems die Daten fuer eine SD Karte verschluesseln. Angenommen man hat ein 4Mbyte spi sowie 4Gbytep Datei. Von 4Gb wenn man chunks von 64*5bit=320bit verwendet dann kann man ca 100 Millionen indexieren. Je 1000 Werte existiert dann im SPI Flash ein dedizierter Key. Weiters wird der Index zusammen mit einem uC Key oder Timestamp mittels einer kryptographischen funktion auch verodert. So kann auch ev. eine HDD verwendet werden, und jedes <4gb File ist separat verschluesselt, oder eben kleinere SD Karte egal wie gross. 320 bit = 64 Zeichen im Murray code. Auch die 4Mbyte Code kann von der SD Karte runtergeladen werden. Dazu wird z.B. die SPI 4Mbyte mittels eines speziellen Key codes verschluesselt, sowie mittels lfsr xored and shuffled bervor die 4M aufsummiert werden. Auch Kreditkartennummern, OTP von der vorherigen SD Karte, EAN Code usw kann verwendet werden, um den OTP Code zu summieren. Normalerweise als Transport Key bezeichnet. Dann wird vom zentralen Server ein RNG gesendet, welches vom Hash des SPI Flash signiert wird und zusaetzlich durch zwei weiteres otp token addiert wird. Dies wird dann zurueckgesendet. Der zentrale PC welcher die OTP generiert speicher die 4Mbyte flash als Bild ab. Nachdem die alte SD deaktiviert wurde, und der Transport key initialisiert wurde, wird sie mittels Stress Test genullt. Solche OTP keys werden auch gerne verwendet um ein session key fuer eine Dateiuebertragung zu haben, basierend auf einer symmetrischen verschluesselung.
Marc Vesely schrieb: > Wenn ich also Sectors von 0 bis nn-1 mit Nullen vollschreibe, werden > eben alle Sectors mit Nullen aufgefüllt, egal wie die gemappt sind. Nicht notwendigerweise. Da NAND-Flash ja immer eine gewisse Fehlerquote aufweist, sind immer mehr Sektoren physikalisch vorhanden als nach außen hin dargestellt werden. Auch die Wear-Levelling-Verfahren funktionieren besser, wenn sie mehr Blöcke als notwendig und damit etwas Spielraum haben. Heißt also: wenn Du vertrauliche Daten hast, und die überschreibst, ist es nicht gesagt, dass nicht doch ein Teil der Daten in irgendwelchen Reservesektoren oder auch in als Defekt markierten Sektoren überlebt. Das macht das ganze so kritisch. Viele SSDs haben daher einen "Secure Erase" Befehl, der tatsächlich alles löschen soll, SD-Karte haben das nicht. fchk
Frank M. schrieb: >Lukas T. schrieb: >> "lösche" ich diese Information [...] > > Du meinst, Du löschst die interne Controller-Info, wie welcher Block zu > mappen ist? Ich denke er meint daß er die Datei auf Dateisystemebene löscht. Und natürlich ist das Kokolores. Daß das nicht funktioniert, zeigen die diversen Tools zum "Entlöschen" von Speicherkarten. Wie man geheime Daten so speichert, daß man sie anti-forensisch löschen kann, zeigt LUKS bzw. das TKS1 Verfahren, das LUKS implementiert (Details z.B. hier: http://clemens.endorphin.org/cryptography) Die zu sichernde Information wird nicht direkt auf das Speichermedium geschrieben, sondern über die z.B. 1000-fache Menge an Blöcken verteilt. Dazu beschreibt man die ersten 999 Blöcke mit Zufallszahlen (ein guter PRNG reicht) und den 1000. Block mit B1(+)B2(+)...(+)B999(+)Daten (das (+) steht für XOR). Zur Rekonstruktion des Datenblocks muß man dann B1 bis B1000 lesen und XOR-verknüpfen. Sobald nur ein Block fehlt, sind die Daten nicht mehr rekonstruierbar. Beim Löschen überschreibt man natürlich alle Blöcke B1..B1000 (mindestens) einmal. Selbst wenn das Speichermedium jetzt noch Kopien einzelner Blöcke haben sollte, wird es am Ende wenigstens einen Block ohne Kopie geben. Auf je mehr Blöcke man dabei die Daten verteilt, desto größer wird die Wahrscheinlichkeit dafür. XL
Frank K. schrieb: > Nicht notwendigerweise. Da NAND-Flash ja immer eine gewisse Fehlerquote > aufweist, sind immer mehr Sektoren physikalisch vorhanden als nach außen > hin dargestellt werden. Wie gesagt, das ist mir neu, aber es mag sein. Im Grunde genommen ist es auch unwichtig, Schlüssel auf USB-Stick (oder SD) ist auf jeden Fall unsicher. Da bestimmt keine Romane versendet werden, sind M328 und 30KB Schlüssel mit Sicherheit nicht zu knacken. Und alles was länger als 30KB ist, vielleicht, aber mit heutigen Computern nur in Jahrhunderten.
Schlüssel werden bei mir nicht gelöscht sondern geschreddert - ist zwar kein großer Unterschied, gerade nicht bei flash-medien. xor-verwürfelung ist performant aber nicht so gut wie stromschiffren (z.B. rc4). Alles machbar und schon vorgefertigt. Also: Sicherheit ist ein Kopf an Kopf Rennen zwischen dem der Daten schützt und dem der sie knackt. Die Luft wird zunehmend dünner. wichtig finde ich ein journal. auch das kann man künstlich erzeugen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.