-
Das Problem ist nun mal das UEFI/TPM gegen den Benutzer entwickelt wurden
Autor: OwenBurnett 29.07.22 - 15:09
Das Problem ist nun mal das UEFI/TPM und SecureBoot gegen den Benutzer entwickelt wurden und nicht für ihn.
In einem anständigem System könnte der Benutzer das TPM so einrichten das es seine grub Boot Reihenfolge akzeptiert und den Schlüssel ausrückt, so wie es so absichern das Windows daran nichts ändern kann.
Aber das SecureBoot und TPM dafür entwickelt wurden den PC vor dem Benutzer abzusichern geht so was dann eben vorsätzlich nicht. -
Re: Das Problem ist nun mal das UEFI/TPM gegen den Benutzer entwickelt wurden
Autor: PeterAnon 29.07.22 - 15:14
Es ist ja nicht SecureBoot und TPM, die so entwickelt sind, sondern Windows bzw. Bitlocker.
Auch wenn ersteres aus dem selben Hause kommt.
Bei Windows wird halt immer vom DAU ausgegangen und die Experten damit ausgesperrt. -
Re: Das Problem ist nun mal das UEFI/TPM gegen den Benutzer entwickelt wurden
Autor: OwenBurnett 29.07.22 - 16:02
Nein da irrst du dich, es ist ja das TPM welches die boot chain bemängelt nicht bitlocker,
Ja es ist Windows was das TPM so konfiguriert, aber das Problem ist das der Benutzer dann nicht die Möglichkeit hat das TPM um zu konfigurierenund bei bedarf windows aus zu sperren. -
Re: Das Problem ist nun mal das UEFI/TPM gegen den Benutzer entwickelt wurden
Autor: PeterAnon 29.07.22 - 17:31
Selbstverständlich hat der Benutzer die Möglichkeit.
Du kannst aus Linux heraus ja das TPM clearen und dann bootet Windows eben nicht mehr.
Genauso kannst du zB den Key zur LUKS-Verschlüsselung im TPM ablegen und gegen die PCR sealen. Macht zB das Tool clevis für dich.
Und schon bootet eben Linux mit SecureBoot und verschlüsselter HDD ohne, dass der User einen Key eingeben muss.
Das funktioniert theoretisch auch parallel zu Windows.
1 mal bearbeitet, zuletzt am 29.07.22 17:32 durch PeterAnon. -
Re: Das Problem ist nun mal das UEFI/TPM gegen den Benutzer entwickelt wurden
Autor: My1 29.07.22 - 18:18
PeterAnon schrieb:
--------------------------------------------------------------------------------
> Selbstverständlich hat der Benutzer die Möglichkeit.
> Du kannst aus Linux heraus ja das TPM clearen und dann bootet Windows eben
> nicht mehr.
> Genauso kannst du zB den Key zur LUKS-Verschlüsselung im TPM ablegen und
> gegen die PCR sealen. Macht zB das Tool clevis für dich.
> Und schon bootet eben Linux mit SecureBoot und verschlüsselter HDD ohne,
> dass der User einen Key eingeben muss.
> Das funktioniert theoretisch auch parallel zu Windows.
kann man auch i-wie den TPM so sinnvoll konfigurieren dass ich nen LUKS und Bitlocker Keys reinbekomme?
würde ich jedenfalls feiern.
Asperger inside(tm) -
Re: Das Problem ist nun mal das UEFI/TPM gegen den Benutzer entwickelt wurden
Autor: gan 29.07.22 - 19:39
OwenBurnett schrieb:
--------------------------------------------------------------------------------
> In einem anständigem System könnte der Benutzer das TPM so einrichten das
> es seine grub Boot Reihenfolge akzeptiert und den Schlüssel ausrückt, so
> wie es so absichern das Windows daran nichts ändern kann.
Nein, das geht eben nicht. Einfach deshalb, weil grub selbst das Problem ist, nicht das TPM. -
Re: Das Problem ist nun mal das UEFI/TPM gegen den Benutzer entwickelt wurden
Autor: Prof.Dau 29.07.22 - 21:39
PeterAnon schrieb:
--------------------------------------------------------------------------------
> Selbstverständlich hat der Benutzer die Möglichkeit.
> Du kannst aus Linux heraus ja das TPM clearen und dann bootet Windows eben
> nicht mehr.
> Genauso kannst du zB den Key zur LUKS-Verschlüsselung im TPM ablegen und
> gegen die PCR sealen. Macht zB das Tool clevis für dich.
> Und schon bootet eben Linux mit SecureBoot und verschlüsselter HDD ohne,
> dass der User einen Key eingeben muss.
> Das funktioniert theoretisch auch parallel zu Windows.
Was bringt eine Festplattenverschlüsselung wenn man nur den PowerButton zur entschlüsselung drücken muss, oder habe ich was übersehen? -
Re: Das Problem ist nun mal das UEFI/TPM gegen den Benutzer entwickelt wurden
Autor: My1 29.07.22 - 21:45
Prof.Dau schrieb:
--------------------------------------------------------------------------------
> PeterAnon schrieb:
> ---------------------------------------------------------------------------
> -----
> > Selbstverständlich hat der Benutzer die Möglichkeit.
> > Du kannst aus Linux heraus ja das TPM clearen und dann bootet Windows
> eben
> > nicht mehr.
> > Genauso kannst du zB den Key zur LUKS-Verschlüsselung im TPM ablegen und
> > gegen die PCR sealen. Macht zB das Tool clevis für dich.
> > Und schon bootet eben Linux mit SecureBoot und verschlüsselter HDD ohne,
> > dass der User einen Key eingeben muss.
> > Das funktioniert theoretisch auch parallel zu Windows.
>
> Was bringt eine Festplattenverschlüsselung wenn man nur den PowerButton zur
> entschlüsselung drücken muss, oder habe ich was übersehen?
Die plattencrypto sorgt dafür dass der login vom OS tatsächlich erzwungen wird. Normal kann man bei nem unverschlüsseltem Windows ja einfach das PW resetten, bei nem verschlüsselten Windows geht das aber nicht da das tpm nur dem Windows den key raus gibt wenn alles passt.
Ebenso hast du idr immer nur ein passwort bei plattencrypto was ne pain bei multiuser Systemen ist.
Asperger inside(tm)
1 mal bearbeitet, zuletzt am 29.07.22 21:46 durch My1. -
Re: Das Problem ist nun mal das UEFI/TPM gegen den Benutzer entwickelt wurden
Autor: PeterAnon 30.07.22 - 02:05
Ich weiß nicht wie Bitlocker das mit der ownership des TPM hält, aber unter Linux kannst du grundsätzlich mehrere "Zustände" des TPM (Hashes in den Registern) für eben verschiedene Kernel usw ablegen, die den Key freigeben.
Grundsätzlich wäre das in meinen Augen also auch parallel zu Windows möglich. -
Re: Das Problem ist nun mal das UEFI/TPM gegen den Benutzer entwickelt wurden
Autor: PeterAnon 30.07.22 - 02:09
In der Regel sollte die Firmware den hash des Bootloader Binaries und der Bootloader dann den Hash des Kernels und der Initrd im das TPM schreiben.
Wenn die Initrd dann versucht den Key für die HDD auszulesen, ist das nur erlaubt, wenn all diese Hashes (Chain of Trust) stimmen und somit das "vertraute" Linux bootet.
Darin sollte auch die cmdline der Kernels enthalten sein.
Dann kannst du relativ sicher sein, dass nur das "vertraute" OS startet und keine Live Distribution mit der du das root Passwort ändern kannst oder eine manipulierte Commandline, die selbiges erlaubt.



