stream, der nur im RAM bleibt?

[quirks]

Danke für die Antworten. Ich hab jetzt meine Entscheidung getroffen.

Ich verschlüssel den Stream manuell ne Prozedur und entschlüssel nur kleine Teile in einen String(Stream), den ich mit VirtualLock auf das RAM banne. Soweit,so gut. ABER: Was ist mit VirtualUnlock? Kann jeder Prozess einfach meinen tollen String wieder auf die Platte holen (wenn er die Adresse weiß, bei 512 MB dürfte das Suchen lange dauern 8) )? Und was ist mit RAM-Sniff-TOols, kann man die irgendwie aussperren?
Wie machen die das eigentllch bei PGP, die haben doch bestimmt das gleiche Problem?

[Robert Marquardt]

Fuer andere Prozesse hat eine Adresse aus deinenm Programm einfach keine Bedeutung.
Ein wirklich hartes Sniffer-Programm kommt letztlich an alles ran.

Leite dir doch von TMemoryStream einen TCryptedMemoryStream ab.
Ein recht einfacher und wirkungsvoller Crypt-Algorithmus ist das XOR-Verfahren.
Die Schwierigkeit ist nur einen langen XOR-Schluessel zu haben.
Da gibt es aber die Moeglichkeit aus einem kurzen Schluessel einen langen zu errechnen.
Das ist zwar angreifbar, aber schon ziemlich sicher.

[Sprint]

Zitat:

Zitat von quirks

[...]den ich mit VirtualLock auf das RAM banne. Soweit,so gut. ABER: Was ist mit VirtualUnlock? Kann jeder Prozess einfach meinen tollen String wieder auf die Platte holen[...]

Ich habe mir gerade nochmal die Kapitel 7 & 8 von Windows - Programmierung für Experten von Jeffrey Richter durchgelesen.
Wenn deine Anwendung bzw. Threads deiner Anwendung nicht aktiv sind, dann kann es sehr gut sein, das der reservierte Speicher ausgelagert wird.
So wie es aussieht, gibt es wohl keine sichere Methode deine Daten im RAM zu behalten.

[Chewie]

[quote="Sprint"]

Zitat:

Zitat von quirks

[...]So wie es aussieht, gibt es wohl keine sichere Methode deine Daten im RAM zu behalten.

Die gibt es schon, aber eben weniger für Anwendungsprogramme, sondern unter Windows speziell für Kernelmodule (=Treiber). Dort ist es unabdingbar. Wie Hagen schon geschrieben hat, dürfen Interrupt Service Routinen mit hoher Priorität auf gar keinen Fall ausgelagerten Speicher verwenden, denn das Interrupt Level zum Wiedereinlagern des Speichers läuft evtl. auf einem nidrigeren IRQL und würd somit nie stattfinden, da die andere Roitine Vorrang hat und auf das Einlagern bis zum Sankt Nimmerleinstag wartet. Für Anwendungen, die im Benutzerkontext laufen, ist eine solche Kontrolle über den RAM einfach nicht vorgesehen.

[SirThornberry]

stell doch einfach im Windows ein das keine Swapdatei benutzt werden soll. Nachteil ist dann nur das dein System abschmiert wenn der Speicher voll ist.

[supermuckl]

im crypting tool "BestCrypt" ist beschrieben das die das password für die encrypteten laufwerke andauernd im speicher "verschieben" und somit dem auslagern in eine swap datei von windoof einen riegel vorschieben

die sprechen da von 10 minuten
also nach 10 minuten "rumliegen im speicher" wirds wohl in den swap verschoben und das is natürlich unsicher

[negaH]

Zitat:

Wie Hagen schon geschrieben hat, dürfen Interrupt Service Routinen mit hoher Priorität auf gar keinen Fall ausgelagerten Speicher verwenden,..... eine solche Kontrolle über den RAM einfach nicht vorgesehen

Nicht bnur das. Stellen wir uns mal den PCI-Bus oder Speicher-DMA-Interrupt vor. Beide Routinen reagieren per Interrupts auf Speicherbewegungen. Würde man diese Routinen im RAM speichern der auslagerbar ist so würden sich also das Auslagern selber mit dem DMA-Interrupt in die Quere kommen.

Es ist im Grunde so das fast alle Kenerl Treiber sicherstellen das sie niemals ausgelagert werden. Gleiches trifft für Kernel32 also dem System Prozess zu. Windows bietet dafür auch genügend Mechanismen an.

Allerdings, schau dir das Protected Storage Interface des CoptoAPIs an. Dieses ist exakt dafür konzipiert und wird mit hoher Sicherheit auf neuen Windows System auch Hardwaremäßig geschützten Speicher benutzen.

@suprmuckl:

Zitat:

im crypting tool "BestCrypt" ist beschrieben das die das password für die encrypteten laufwerke andauernd im speicher "verschieben" und somit dem auslagern in eine swap datei von windoof einen riegel vorschieben

die sprechen da von 10 minuten
also nach 10 minuten "rumliegen im speicher" wirds wohl in den swap verschoben und das is natürlich unsicher

Sowas glaube ich erst wenn ich den Source gesehen habe und definitiv weis das der Source auch wirklich auf API's zurückgreift die definitiv den RAM nicht auslagern. Nur mal nebenbei bemerkt mit dem Author von BestCrypt hatte ich Kontakt und der damalige Source sah mir nicht sehr danach aus das solche verzwickten API Geschichten möglich wären. Er sah mehr nach dem Source meiner Lehrlinge aus, sorry, aber das ist meine persönliche Einschätzung.

Zudem eine "andauernde Verschiebung im Speicher" das hört sich ja so an das die sicherheitsrelevanten Passwörter im Supermarkt wie die Stille Post von Hand zu Hand wandern. Da kann man auch gleich das Passwort in'er Messagebox sichtbar machen. Im Grunde ist es bei solchen Passwörtern doch irrelevant ob sie ausgelagert werden oder nicht. Wichtig ist nur das sie vor der Auslagerung clever verschlüsselt wurden, mit einem Schlüssel der nicht mehr reproduzierbar ist wenn man das System ausschaltet. Gerade in diesem Punkt kann man seiner Phantasie freien Lauf lassen denn es gibt nun keine Beschränkung mehr wie groß dieses Schutzpasswort maximal sein darf. Man könnte also rein theoretisch aus alle Daten der Festplatten ein riesiges Passwort erzeugen das dann die zu schützenden Daten verschlüsselt. Falls nun diese Daten ausgelagert werden, müsste man schon ganz exakt diesen Prozess wiederholen können.

Übrigens, Stack und die Registerinhalte werden niemals ausgelagert. Beim Task/threadwechsel werden diese Contexte in eigene Speicherbereich des Taskshedulers kopiert die wiederum nicht auslagerbar sind.

Gruß Hagen