FreeOTFE und unsignierte Treiber...

Hallo,

ich würde gerne FreeOTFE unter Windows 7 64-bit benutzen.

Das Problem ist aber, dass FreeOTFE zur Verschlüsselung, bzw. zum Hashen eigene Treiber benutzt, die im Installations-Bundle mit dabei sind.

Aber: diese Treiber sind von Microsoft nicht zertifiziert.

Deshalb lässt sich der Haupttreiber, selbst wenn man FreeOTFE mit Administratorrechten startet, nicht laden.

Ich habe im Handbuch von FreeOTFE eine Anleitung gefunden, mit der man es anscheinend dennoch schafft, die Treiber irgendwie zu starten:
http://freeotfe.org/docs/Main/impact_of_kernel_driver_signing.htm

Im Handbuch heißt es, dass für die meisten Benutzer wohl der dritte Vorschlag ("TESTSIGNING ON") empfohlen werde.
Es wird auch eine Anleitung gegeben, aber ich frage mich: Was genau bedeutet es, wenn ich in der cmd
bcdedit.exe /set TESTSIGNING ON
eingebe? Können dann absofort ALLE unsignierten Treiber ohne Rückmeldung gestartet werden?
Wenn ja, dann wäre das wohl ein fettes Sicherheitsloch. Und wie kann ich das wieder abschalten, wenn ich es mal eingeschaltet habe?

Was haltet ihr von der ganzen Geschichte?

P.S.: Bitte keine Kommentare wie "Benutz doch lieber TrueCrypt" oder so. Ich benutze TrueCrypt eigentlich lieber als FreeOTFE, das Problem ist aber, dass nur FreeOTFE auf luks-Partitionen (die unter Linux erstellt wurden) zugreifen kann.

Weiß denn keiner was?

Es geht hier um den Kommandozeilenaufruf bcdedit.exe /set TESTSIGNING ON

hustbaer

Damit setzt du einen Switch in der Boot-Config der den Kernel in den "Driver Test Mode" schaltet.

In diesem Mode akzeptiert der Kernel Treiber die keine "gültige" Signatur mit einem "trusted" Zertifikat haben.
Im normalen Mode verweigert der Kernel Treiber zu laden die nicht mit einem Zertifikat signiert wurden, das wiederum mit dem Microsoft-Certificate cross-signiert ist.

[WennIchMichRichtigErinnere]
Beim normalen Installieren von Gerätetreibern über den Device-Manager wirst du trotzdem gefragt ob du den Treiber auch wirklich installieren willst. Wenn aber ein Programm mit einem unbeschränkten Admin-Account läuft (siehe UAC), dann kann dieses soweit ich weiss ohne Rückfrage Treiber "installieren". Und zwar unabhängig vom "Driver Test Mode". Der einzige Unterschied ohne "Driver Test Mode" ist dass der Kernel sich dann weigert den "installierten" Treiber auch wirklich zu laden.
[/WennIchMichRichtigErinnere]

Natürlich kann man den "Driver Test Mode" auch wieder abschalten, und zwar mit (was für ne Überraschung) bcdedit.exe /set TESTSIGNING OFF . Sobald du den "Driver Test Mode" ausschaltest funktionieren aber auch Treiber die du im "Driver Test Mode" installiert hast nicht mehr. Die Überprüfung findet eben beim Laden des Treibers statt, und da du nach bcdedit.exe /set TESTSIGNING xxx rebooten musst, und beim Neustart der Treiber neu geladen werden muss...

Möglichkeiten:

Anderes OS verwenden (z.B. 32 Bit Windows)
Anderes Tool verwenden
Zertifikat für den Treiber besorgen
"Driver Test Mode" permanent aktiv lassen
"Driver Test Mode" immer einschalten wenn man das Tool braucht und danach wieder ausschalten - was natürlich immer mit einem Reboot verbunden ist

Zu (3): du kannst den Treiber auch selbst signieren. Du brauchst dazu nur ein Zertifikat das für Kernel-Mode-Code-Signing geeignet ist und das dazupassende Cross-Certificate. Einer der billigeren Anbieter (aber vermutlich nicht der billigste) ist DigiCert:
http://www.digicert.com/code-signing/kernel-mode-certificates.htm
Ein so signierter Treiber bleibt auf ewig verwendbar, unabhängig von der Gültigkeitsdauer des Zertifikats. Nur muss das Zertifikat zu dem Zeitpunkt wo du den Treiber signierst gültig sein, und der Treiber darf sich danach natürlich auch nicht mehr ändern.

Das FreeOTFE Projekt wäre auch sicher glücklich wenn ihnen jmd. so ein Zertifikat spendieren würde. Wenn sich jemand findet der Geld dafür sammelt und es ein paar User gibt die das Ding unter x64 verwenden könnte da was draus werden. Wobei ich keine Plattform kenne über die man sowas organisieren könnte. Crowdfundingseiten ala Kickstarter hätten die nötige Infrastruktor dafür (Geld wird nur abgebucht wenn das Funding-Goal erreicht wurde etc.), aber ich bin nicht sicher ob die sowas als "Projekt" annehmen.

hustbaer schrieb:

Möglichkeiten:

Anderes OS verwenden (z.B. 32 Bit Windows)

Anderes Tool verwenden

Zertifikat für den Treiber besorgen

"Driver Test Mode" permanent aktiv lassen

"Driver Test Mode" immer einschalten wenn man das Tool braucht und danach wieder ausschalten - was natürlich immer mit einem Reboot verbunden ist

Danke für deine Antwort!

Zu "2) Anderes Tool verwenden": Kennst du ein solches Tool? Es muss für Windows sein, und es muss (unter Linux erstellte) luks-, bzw. cryptsetup-volumes mounten können.

TrueCrypt kann das leider nicht...

P.S.: Irgendwie ist das auch eine dumme Idee, die ganze Verschlüsselung über Treiber zu machen, das kann man auch ganz normal ohne Treiber machen (siehe TrueCrypt).

hustbaer

Alles was unter Windows ein Block-Device oder ein Volume bereitstellt braucht nen Treiber.
D.h. TrueCrypt verwendet auch einen. Nur dass die vermutlich Sponsoren haben die ihnen ein Zertifikat bezahlt haben.

hustbaer schrieb:

Alles was unter Windows ein Block-Device oder ein Volume bereitstellt braucht nen Treiber.
D.h. TrueCrypt verwendet auch einen. Nur dass die vermutlich Sponsoren haben die ihnen ein Zertifikat bezahlt haben.

ok, wie ist das eigentlich unter Linux?

hustbaer

Unter Linux braucht man soweit ich weiss auch ein Kernel-Modul für File-System Sachen. Nur dass es dort FUSE gibt, d.h. man kann das fertige FUSE Modul verwenden und den eigentlichen FS-Treiber dann im Usermode ~~schreiben~~ laufen lassen.

Wie es unter Linux mit Block-Devices ist weiss ich nicht.
Bin kein Linux-Experte.

Auf jeden Fall braucht man unter Linux nichts signieren, wodurch es dann auch nicht so schlimm ist wenn irgendwas im Kernel laufen muss. Behaupte ich mal. Als Nicht-Linux-Experte.