Header von vhd-Dateien verschlüsseln

[neo4a]

Ich möchte die direkte Nutzung von VHD-Dateien dahingehend unterbinden/erschweren, indem ich den Header-Bereich einer VHD verschlüssele und nur in einem kontrolliertem/embedded Umfeld frei gebe.

Einsatzgebiet ist dabei VirtualBox mit Win7x64 sowohl für Host als auch Client.

Eine volle Verschlüsselung der VHD ist nicht erforderlich und auch nicht gewünscht, da Host und Client bereits in einem Full-Disk-Encryption (FDE)-Umfeld auf SSD betrieben werden. Es geht hier wirklich nur darum, "spielende" Anwender von Versuchen abzuhalten, ihr virtuelles System "mal eben" per Datenträgerverwaltung als virtuelle Festplatte zu mounten.

Ich suche einen möglichst effektiven Ansatz, damit das Schreiben eines nur kleinen Teils einer großen Datei (>40GB) so schnell wie möglich realisiert werden kann. Hat vielleicht schon jemand mit solchen Szenarien Erfahrungen sammeln können?

[chaosben]

Mal so ein Schnellschuss aus der Hüfte: Wie wärs, einfach die ersten 8 Byte mit eigenen Daten zu überschreiben (und später wieder das original 'conectix' rein zu schreiben)? Dann dürften doch die wenigsten Programme die Datei als VHD erkennen und dem unbedarften Nutzer ist erstmal ein Hindernis in den Weg gelegt worden.

[himitsu]

Warum verwendet ihr dann eigentlich VHD?

Ich könntet doch auch die VDI nehmen, welche VirtualBox standarmäßig verwendet.
Und dann müssen nur noch die Tools/Programme deinstalliert/geblockt werden, welche zum Mounten benötigt werden.

[neo4a]

@chaosben:
Genau so. Nur wie mache ich das möglichst effektiv?

@himitsu:
Falls ich keine zufriedenstellende Lösung hinbekomme, wird wohl das Pattern "security by obscurity" zum Einsatz kommen

Wie bekommt man es hin, nur einen Teil einer sehr großen Datei auszutauschen bzw. zu schreiben, ohne gleich die gesamte Datei neu schreiben zu müssen?

[JamesTKirk]

Wenn ich das richtig im Kopf habe, dann liest TFileStream die Datei nie* komplett ein (es arbeitet mit WriteFile und ReadFile , welche das selbst nicht machen, zumindest wenn du keinen entsprechend großen Puffer übergibst ). Dann könntest du mit TStream.Write die ersten paar Byte ersetzen.

* ganz kleine Dateien eventuell ausgenommen

Gruß,
Sven

[sx2008]

Zitat von neo4a:

Wie bekommt man es hin, nur einen Teil einer sehr großen Datei auszutauschen bzw. zu schreiben, ohne gleich die gesamte Datei neu schreiben zu müssen?

Das ist total easy:

Delphi-Quellcode:

const
  BLOCKSIZE = 1024
var
  stream : TStream;
  s : AnsiString;
begin
  stream := TFileStream.Create('datei.vhd', fmOpenReadWrite or fmShareDenyWrite);
  try
    SetLength(s, BLOCKSIZE);
    stream.ReadBuffer(s[1], Length(s));  // Block einlesen
    s := XORString(s, 'geheime passphrase zur Verschlüsselung');  // ver- oder entschlüsseln
    stream.Position := 0;   // zurück auf Anfang
    stream.WriteBuffer(s[1], Length(s));  // Block überschreiben
  finally
    stream.Free;
  end;  
end;

Der Code könnte kleine Fehler enthalten da ungetestet
Die Funktion XORString ist eine einfache XOR-Verschlüsselung.

Delphi-Quellcode:

function XORString(const text, key:AnsiString):AnsiString;
var
   i, j, keylen : Integer;
begin
   SetLength(Result, length(text));
   j := 1;
   keylen := Length(key);
   for i := 1 to Length(text) do
   begin
      Result[i] := chr(ord(text[i]) xor ord(key[j]));
      Inc(j);
      if j > keylen then j := 1;
   end;
end;

[himitsu]

Und wann willst du die VHD ver-/entschlüsseln?


Während sie verwendet wird, muß sie ja entschlüsselt sein.
Und wenn man sie sich dabei kopiert, bzw. kurz bevor sie wieder verschlüsselt wird, dann hat man eine entschlüsselte Kopie und kann sie gemütlich mounten.

Und ja, das kopieren dauert bestimmt etwas, aber während sie kopiert wird, kannst du nicht verschlüsseln,
somit knallt dann auch dein Verschlüsselungsversuch, womit dann womöglich sogar das Original unverschlüsselt bliebe.

Also braucht man die auch nur zu mounten, während sie noch entschlüsselt ist.



Es gibt also doch nur wenige Möglichkeiten:
- dem User verbieten auf die Datei zuzugreifen (sie überhaupt zu sehen), was aber schwer wird, wenn die in der VirtualBox geladen werden sollen
- - außer man unterbindet auch noch den Explorer, CMD und alle Open-/Save-Dialoge
- oder man verbietet ihm zumindestens das Mounten

- und zusätzlich natürlich muß man natürlich noch das Kopieren verbieten, also in ein anderes System, wo nichts verboten ist



Warum darf er das eigentlich nicht mounten?
An die Dateien darin kommt er über die laufende VBox-Instanz doch eh rankommen?

[Klaus01]

.. und wenn man keine xor Verschlüssung nutzen möchte,
dann sollte man noch darauf achten das die verschlüsselten Daten
in der Anzahl mehr geworden sein könnten.

Grüße
Klaus

[neo4a]

@sx2008:
Stimmt. So ist es tatsächlich einfach.

@himitsu:
Ich habe hier etwas spezielle und dadurch auch komplexe Einsatzszenarien und möchte gern die Kontrolle behalten, wie ein Benutzer vorgegangen ist.

Deine Fragen haben mich allerdings noch einmal meinen Ansatz überdenken lassen. Ich werde nun testen, inwieweit ich das Windows-eigene EFS dafür hernehmen kann, indem ich VBox per RunAs in einem speziell dafür angelegten Userkontext starte. Die Vhd wird natürlich auch unter diesem Benutzer verschlüsselt angelegt. Wenn es so funktioniert, wie ich es erhoffe, dann kann der VBox-Prozess problemlos auf diese Vhd zugreifen. Jeglicher Versuch, außerhalb des (speziellen) Benutzerkontextes mit diesen Daten zu arbeiten, wird dann scheitern.

Wir setzen EFS ja bereits für die Offline-Daten von Outlook ein und dort gibt es auch keine (Performance-) Probleme damit. Im Gegensatz zu allen Container-Lösungen (ala TrueCrypt) behält man so auch die dynamische Datenträger-Funktionalität bei, was bei den relativ kleinen SSD immer noch ein Muss ist. Die für den Zugriff erforderlichen Zertifikate muss man natürlich verwalten, damit die Vhd portabel bleibt.

Hier steht auch etwas dazu (insbesondere ganz am Ende)