SecureString für Delphi W32?

[mquadrat]

Hallo zusammen,

ich suche nach einer simplen Möglichkeit Strings nur verschlüsselt im Speicher abzulegen. Unter .NET gibt's dafür die SecureString Klasse. Gibt's sowas auch in Delphi?

Ich hätte wetten können, dass das hier garantiert schon mal besprochen wurde, aber scheinbar füttere ich die Suche mit den falschen Begriffen :(

[himitsu]

besprochen wurde es schon mehrmals, aber ich kann mich grad an keine Lösung erinnern.

PS: du weißt aber, daß dennoch der String zeitweise (und unter Umständen auch noch für länger) unverschlüsselt im RAM, oder gar (manchma für sehr viel länger) auf der Platte (Pagefile) rumliegt?


nja, im Notfall sieht sowas doch garnicht soooo schlecht aus: :angel:

Delphi-Quellcode:

Type
  TSecureString = Record
    Data: String;
    Class Operator Implicit(Const Value: String): TSecureString;
    Class Operator Implicit(Const Rec:   TSecureString): String;
  End;

Class Operator TSecureString.Implicit(Const Value: String): TSecureString;
  Begin
    Result.Data := Verschüsseln(Value);
  End;

Class Operator TSecureString.Implicit(Const Rec: TSecureString): String;
  Begin
    Result := Enschüsseln(Rec.Data);
  End;

PSS: der Dienst lsass.exe (Geschützter Speicher) klingt aber auch recht nett :gruebel: ... aber k.A. ob der was bringt, bzw. was der macht ... hatte irgendwie noch keine Seit zum nachgucken gefunden :oops:

[mquadrat]

Jep, mir ist bewusst, dass zumindest kurz eine unverschlüsselte Represäntation des Strings im Speicher liegt. Schließlich muss der String ja irgendwie ins Programm und auch irgendwie wieder raus.

Der String müsste also "sofort" wieder im Speicher genullt werden. Je kürzer die Zeitspanne, desto weniger wahrscheinlich ist das pagen des unverschlüsselten Strings. Kann man denn davon ausgehen, dass wenn man den unverschlüsselten String mit beliebigen Zeichen überschreibt, dass es dann auch tatsächlich keine Kopie mehr vom alten Inhalt im Speicher gibt?

Angenommen das würde so klappen, müsste man sich noch was einfallen lassen, wie man den Schlüssel schützt.

[himitsu]

Zitat:

Zitat von mquadrat

Kann man denn davon ausgehen, dass wenn man den unverschlüsselten String mit beliebigen Zeichen überschreibt, dass es dann auch tatsächlich keine Kopie mehr vom alten Inhalt im Speicher gibt?

Leider ist dieses nicht möglich, da du "keine" Möglichkeit hast, um festzustellen, ob es Kopieen gib, da Windows ja den Speicher verwaltet.
Innerhalb deines Adressraumes, kannst du zwar durch Überschreiben sicherstellen, daß die unverschlüsselten Daten verschwinden, aber wenn z.B. Windows zwischendurch den speicher ausgelagert hat, dann bleibt der auch (bis er überschrieben wird) in der Pagefile :wall:

Wenn du die Speicherverwaltung deiner Stringdaten selber übernimmst und nicht über die delphieigenen String-Typen gehst, welche den MemoryManager mit einer "normalen" Speicherverwaltung nutzt, und dir z.B. mit PhysicalPages ( AllocateUserPhysicalPages ) Speicher resservierst, welcher nicht ausgelagert werden kann (angeblich sollte), dann würde da zumundestens die Chance größer sein, daß eventuell nichts mehr vorhanden bleibt, nach dem Überschreiben.

Nur müssen PhysicalPages erstmal aktivert sein/werden ... und unter XP sind sie es standardmäßig nicht (in Vista ist es aber anscheinden per Standard aktiv :gruebel: ).
Und wenn, dann kann man ja die Stringdaten gleich an Ort und Stelle ver-/entschlüsseln ... wenn man selber nicht kopiert, kann man da zumindestens schonmal keine eigenen Kopieen vergessen.


PS: auch wenn ich und auch fast alle es bestimmt nicht gern sehn ... wärend der kritischen Phase die Prozesspriorität auf CriticalTime setzen ... da sollte es wohl doch nahezu unmöglich sein, daß da noch ein anderer Prozes läuft, welcher auslesen könnte :angel2:

[Dezipaitor]

JWSCL bietet Verschlüsselungen von Windows an. Entweder die LSA Properties (TJwSecurityLSA) oder die Klassen aus JwsclCryptProvider.pas
Damit kann man persistente oder sogar prozess- und benutzerbezogen Verschlüsseln.

Passwörter halte ich immer so im Speicher.

[mquadrat]

@himitsu

Wenn es standardmäßig nicht aktiviert ist, nutzt es mir in meinem konkreten Fall leider nichts, da das Programm per XCopy Installation ohne Adminrechte verteilt werden soll. Der Vorschlag mit Critical Time hört sich schon mal gut an. Wäre ja tatsächlich nur für die paar Millisekunden bis der String wieder genullt wird. Das senkt zumindest die Wahrscheinlichkeit von Kopien.


@Dezipaitor

Und was machst du mit den String-Kopien, die vor dem Verschlüsseln in den Speicher gelegt wurden?

[Dezipaitor]

Str := 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX';

wenn du so willst :D
Aber ich lasse es immer mit Zufallszahlen beschreiben. Zudem dürfen Passwortvariablen nur per ByRef übergeben werden.

[mquadrat]

Deine Zufallszahlen müssen dann aber die gleiche Länge wie der Ursprungstext haben, oder? Sonst legt Windows deine schönen neuen Zeichen an anderer Stelle ab (wenn ich mich jetzt nicht irre)

[Dezipaitor]

Deshalb wäre es am besten mit festen Speichergrößen Passwörter zu verwenden. Aber ein Memorydump meiner Anwendungen hat noch kein Passwort geliefert. Das sollte man sowieso immer mal wieder machen.