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.
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 ?
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.
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ödingersKatze 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.
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_usesMarek 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.
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.
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."
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.
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
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.
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":
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
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.
> 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.
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.
