stream, der nur im RAM bleibt?

[quirks]

Hi.
Ich habe ein Programm, bei dem aus sicherheitstechnischen Gründen ein Stream gebraucht wird, der nicht in die Auslagerungsdatei gelangt. Also nur im RAM "resident" bleibt. Gibt es da eine Möglichkeit?

[mytar]

Schau dir TMemoryStream in der OH an.
Das ist genau das was du suchst! :mrgreen:

[quirks]

Hm, hätt ich selber drauf kommen können :oops:

Wenn das so stimmt, dann hab ich bis jetzt immer instinktiv den richtigen Stream benutzt...

Aber noch ne Frage dazu: Bleibt der wirklich NUR im RAM oder wird der bei vollem RAM doch (zumindest teilweise) in die SWAP-Datei ausgelagert?

[OregonGhost]

Kann eine Windows-Anwendung überhaupt kontrollieren, ob Teile ihres Speichers ausgelagert werden? Das geschieht doch alles im Hintergrund, oder nicht? Meiner Meinung nach lautet die Antwort auf deine Frage also: Nein, der verbleibt nicht notwendigerweise im RAM.

Wenn es dir darum geht, dass der Stream nicht nach der Verwendung in der Auslagerung verbleibt, kannst du 1. ihn komplett überschreiben und 2. gibt es eine Option, dass Windows beim Herunterfahren die Auslagerungsdatei löscht (frag' mich jetzt aber bitte nicht wo und ob du das innerhalb deines Programms einstellen kannst).

[quirks]

Hm, ich weiß zwar nicht, wie performant das ist, aber ich hab da ne Idee:
Ich verschlüssel den Stream dynamisch und entschlüssel dann nur jeweils den gebrauchten Teil in einen kurzen String/Array mit max. 100-Byte Größe.
Hat jemand eine Ahnung, wo ich einen Vergleich von der Geschwindigkeit von Crypto-Verfahren bekomme, bzw. welches der schnellste ist?

[Sprint]

Zitat:

Zitat von quirks

Bleibt der wirklich NUR im RAM oder wird der bei vollem RAM doch (zumindest teilweise) in die SWAP-Datei ausgelagert?

Da hast du mit TMemoryStream keinen Einfluss drauf. Hier kommt es drauf an, wie Windows konfiguriert ist.
Ein kleines Beispiel, mit einem 100 MB großen TMemoryStream. Da kannst du dann sofort sehen, wieviel ausgelagert wird.

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
const
  MEMINFOTEXT = 'Auslagerungsdatei ist ca. %d MB groß.';
var
  MemStat: TMemoryStatus;
  PageFileSize: Integer;
  MemStream: TMemoryStream;
begin

  // Größe der Auslagerungsdatei berechnen

  MemStat.dwLength := SizeOf(TMemoryStatus);
  GlobalMemoryStatus(MemStat);
  PageFileSize := (MemStat.dwTotalPageFile - MemStat.dwAvailPageFile) div 1024 div 1024;
  ShowMessage(Format(MEMINFOTEXT, [PageFileSize]));



  // MemoryStream erstellen (100 MB)

  MemStream := TMemoryStream.Create;
  MemStream.Size := 104857600;



  // Größe der Auslagerungsdatei neu berechnen

  MemStat.dwLength := SizeOf(TMemoryStatus);
  GlobalMemoryStatus(MemStat);
  PageFileSize := (MemStat.dwTotalPageFile - MemStat.dwAvailPageFile) div 1024 div 1024;
  ShowMessage(Format(MEMINFOTEXT, [PageFileSize]));



  // MemoryStream wieder freigeben

  MemStream.Free;



  // Größe der Auslagerungsdatei neu berechnen

  MemStat.dwLength := SizeOf(TMemoryStatus);
  GlobalMemoryStatus(MemStat);
  PageFileSize := (MemStat.dwTotalPageFile - MemStat.dwAvailPageFile) div 1024 div 1024;
  ShowMessage(Format(MEMINFOTEXT, [PageFileSize]));

end;

[quirks]

Danke, werds gleich mal ausprobieren

[Chewie]

Da für das Auslagern ein LRU-Verfahren verwendet wird (LRU = Least Recently Used, d.h. es werden die Seiten ausgelagert, die am längsten nicht mehr benutzt worden sind), könntest du das Auslagern erschweren, indem du häufig auf die Daten zugreifen.

[Brüggendiek]

Hallo quirks!

Es gibt nur eine sichere Methode, die Auslagerung des RAM zu verhindern:
Schreibe ein eigenes Betriebssystem, das dieses Feature bietet. Ggf. wäre ja Linux eine gute Grundlage dafür :mrgreen:

Im Ernst: Letztendlich wirst Du niemals verhindern können, daß es zur Auslagerung kommt. Da gibt es z.B. Programme zum RAM-Freigeben. Die arbeiten so:
Es wird Speicher bis zum Anschlag angefordert und mit Müll gefüllt. Folge: Alle anderen Programme fliegen raus in die Auslagerungsdatei.
Dann wird der Speicher wieder freigegeben. Der RAM ist jetzt vollkommen leer und die noch aktiven Programme belegen ihn dann aus der Auslagerung wieder neu.

Als Ergebnis stehen inaktive Daten in der Auslagerungsdatei und die aktiven Daten haben wieder Platz.

Also hilft wirklich nur ein massive Eingriff ins System - was bei Linux wegen OpenSource natürlich "leichter" durchzuführen ist als bei Windows.

Alternative: Rechner in einen Panzerschrank stellen.

Gruß

Dietmar Brüggendiek

[negaH]

Naja, ganz stimmt das natürlich nicht. In jedem Betriebsystem muß es auch Mechanismen geben die explizit bestimmte Speicherbereiche vor der Auslagerung schützen. Denn eine Interrupt-Service-Routine darf in keinem Falle ausgelagert werden, sonst funktioniert garnichts mehr. Demzufolge gibt es sehr wohl solche Mechanismen auch in Windows. Schaue dir zb. mal die API Funktionen VirtualProtect(), VirtualLock() oder die MMF's an. Über diese sollte man auf Ring3, sprich Applicationlevel Einfluß nehmen könne. Verbliebe dann noch das MS CryptoAPI das die Protected Storage umsetzt, d.h. geschützer Speicher der neben der Lifeverschlüssung auch das Auslagern verhindert. Ansonst müsste man schon auf Treiberebene -> Ring0 in Windows arbeiten um das Gleiche zu erreichen.
Und soviel ich weis lagert Windows auch niemals den Stack von Prozessen oder Threads aus.

Gruß Hagen

[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