Ich habe mehrere verschlüsselte Linux Systeme, die ich ohne einen
Bildschirm betreibe. Beim booten muss ich aber natürlich das Passwort
eingeben. Dazu nutze ich in vielen Fällen die Ausgabe auf der seriellen
Schnittstelle und gebe das Passwort über ein Laptop in der seriellen
Konsoe ein. Ein Teil der Rechner hat aber keinen seriellen Port mehr.
Daher scheidet ein USB RS232 Adapter hier aus.
Meine Überlegung war nun einen USB<->USB Wandler aus zwei FTDI UART
Adaptern zu bauen. Ich fürchte aber, dass die USB Schnittstelle zum Boot
Zeitpunkt noch gar nicht funktioniert. Hat das mal jemand ausprobiert?
Wenn die Schlüsselabfrage noch vor der Aktivierung des Kernels erfolgt,
werden USB- und PS/2-Tastaturen zu diesem Zeitpunkt vom BIOS/UEFI mit
Sicherheit bedient. Es geht dann also ggf darum, nicht das Protokoll für
USB-Seriell zu implementieren, sondern das für Tastaturen, USB oder
PS/2.
Wenn die Schlüsselabfrage aber bereits im startenden Kernel erfolgt,
sollte es bei einem Linux, das grundsätzlich mit einer seriellen Konsole
arbeiten kann, möglich sein, den dafür nötigen FTDI-Treiber bereits in
dieser Phase zu aktivieren.
(prx) A. K. schrieb:> Wenn die Schlüsselabfrage aber bereits im startenden Kernel erfolgt,> sollte es bei einem Linux, das grundsätzlich mit einer seriellen Konsole> arbeiten kann, möglich sein, den dafür nötigen FTDI-Treiber bereits in> dieser Phase zu aktivieren.
Kann man auf der Linuxkernel cmdline (/proc/cmdline bzw
https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html)
eine Konsole übergeben die erst später existiert?
Timo schrieb:> Onkel Ted schrieb:>> Deine Lösung ist aber auch möglich:>>>> https://www.coreboot.org/GRUB2#On_a_USB_serial_or_USB_debug_adapter>> Dann hätte aber nur Grub eine serielle Konsole, nicht aber der Kernel> während des Boot-Vorgangs.
Jetzt kommt es darauf an was ihm reicht. Benutzt er LUKS1 kann er von
grub aus die Partition bereits entsperren:
https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html
Ansonsten muss er schauen ob seine Distribution
CONFIG_USB_SERIAL_CONSOLE usw. gesetzt hat:
https://cateee.net/lkddb/web-lkddb/USB_SERIAL_CONSOLE.html
Für Ubuntu dürfte er vermutlich selbst einen Kernel compilieren (siehe
Howto), müsste da aber nochmal in die config schauen, meine aber dass
das standardmäßig nicht gesetzt war.
https://wiki.ubuntu.com/Kernel/KernelDebuggingTricks
Ansonsten würde ich wirklich dazu raten SSH Preboot Auth zu verwenden,
das ist die einfachste Lösung. Wenn es bei der Verschlüsselung nur um
potentielle Defekte der Festplatten geht kann man auch einfach einen Key
in einen Hardware Dongle ablegen und davon automatisch booten lassen.
Huch schrieb:> Ich habe mehrere verschlüsselte Linux Systeme, die ich ohne einen> Bildschirm betreibe. Beim booten muss ich aber natürlich das Passwort> eingeben. Dazu nutze ich in vielen Fällen die Ausgabe auf der seriellen> Schnittstelle und gebe das Passwort über ein Laptop in der seriellen> Konsoe ein. Ein Teil der Rechner hat aber keinen seriellen Port mehr.> Daher scheidet ein USB RS232 Adapter hier aus.
Würdest Du vernünftige Serverhardware einsetzen, dann hättest Du
entweder einen ASpeed IPMI/KVM Chip oder eine Console Redirection auf
RS232, die oftmals noch als Header auf dem Mainboard vorhanden ist.
Alternativ bei Intel vPro AMT und iKVM über Webinterface oder
MeshCommander.
Andere Möglichkeit: sowas wie pikvm.org oder eine der zahlreichen
kommerziellen Produkte, die zuhauf in Rechenzentren eingesetzt werden.
Das ist dann auch im Wartungsfall immer ganz nützlich.
fchk
(prx) A. K. schrieb:> Wenn die Schlüsselabfrage noch vor der Aktivierung des Kernels> erfolgt,> werden USB- und PS/2-Tastaturen zu diesem Zeitpunkt vom BIOS/UEFI mit> Sicherheit bedient. Es geht dann also ggf darum, nicht das Protokoll für> USB-Seriell zu implementieren, sondern das für Tastaturen, USB oder> PS/2.
Das wäre eine einfache Alternative. Praktischer wäre aber natürlich die
serielle Konsole, um auch zu sehen, ob die Eingabe korrekt war.
Onkel Ted schrieb:> Schau einmal ob du einen RS232 Header findest, den haben moderne Rechner> nämlich oft noch. Da brauchst du dann einfach nur eine passende PCI> Blende.
Bei einem Teil der Rechner leider nicht. Es handelt sich dabei um kleine
Barebones ohne RS232. Bei "echten" Rechnern habe ich die serielle
Schnittstelle bereits auf diese Weise nachgerüstet.
Onkel Ted schrieb:> Ich mach sowas über SSH:>> https://www.thomas-krenn.com/de/wiki/Voll-verschl%C3%BCsseltes-System_via_SSH_freischalten
Ja, den kannte ich schon. Ist nicht unmöglich, Problem ist aber, dass
teilweise kein Netzwerk zur Verfügung steht, da es sich um mobile
Systeme handelt. Wäre aber vielleicht mit separaten Netz während des
Boots möglich und braucht keine Hardware außer einem Netzwerkkabel.
Onkel Ted schrieb:> Wenn es bei der Verschlüsselung nur um> potentielle Defekte der Festplatten geht kann man auch einfach einen Key> in einen Hardware Dongle ablegen und davon automatisch booten lassen.
Mitarbeiter, die den Rechner verloren, verloren auch den Hardware Key.
Das kommt nicht in Frage.
Frank K. schrieb:> Würdest Du vernünftige Serverhardware einsetzen, dann hättest Du> entweder einen ASpeed IPMI/KVM Chip oder eine Console Redirection auf> RS232, die oftmals noch als Header auf dem Mainboard vorhanden ist.> Alternativ bei Intel vPro AMT und iKVM über Webinterface oder> MeshCommander.
Und das hilft mir bei den bestehenden Systemen wie genau? Gibt es
Barebones mit IPMI?
Huch schrieb:> Gibt es Barebones mit IPMI?
Stichwort: Supermicro. Der Begriff "Barebone" umfasst aber nicht nur
Zwergsysteme und ob Supermicro auch was in deiner Grösse hat, weiss ich
nicht.
Huch schrieb:> Das wäre eine einfache Alternative. Praktischer wäre aber natürlich die> serielle Konsole, um auch zu sehen, ob die Eingabe korrekt war.
Wenn du vor dem Rechner bist, sollte die LED zur Disk-Aktivität eine
positive Rückkopplung ergeben. Ansonsten gibt es billige 7"-Monitore.
Huch schrieb:> Mitarbeiter, die den Rechner verloren, verloren auch den Hardware Key.> Das kommt nicht in Frage.
Bei den Kabeln musst ja genauso vor Ort sein.
Mit Hardware Dongle booten und dann einfach abziehen wenn durch wäre
denke ich die einfachste Lösung.
Du kannst ja eine Abfrage einbauen die sicherstellt dass der Dongle
abgezogen wird, z.B. ein Service der beim Booten so lange wartet und die
Dongle LED blinken lässt bis dieser entfernt wurde.
Ansonsten musst du die Kernel Config prüfen und bei Bedarf deinen
eigenen Kernel kompilieren. Dann dürfte die Lösung mit dem USB TTY
Adapter genauso funktionieren.
Und was spricht gegen die Nutzung des TPM?
https://github.com/fox-it/linux-luks-tpm-boot
Huch schrieb:> Frank K. schrieb:>> Würdest Du vernünftige Serverhardware einsetzen, dann hättest Du>> entweder einen ASpeed IPMI/KVM Chip oder eine Console Redirection auf>> RS232, die oftmals noch als Header auf dem Mainboard vorhanden ist.>> Alternativ bei Intel vPro AMT und iKVM über Webinterface oder>> MeshCommander.>> Und das hilft mir bei den bestehenden Systemen wie genau? Gibt es> Barebones mit IPMI?
Ja. Und mit vPro AMT auch. Was ich sagen will, ist, dass der
Verantwortliche bei der Anschaffung der Maschinen entweder zu knauserig
oder zu kurzsichtig gewesen ist und ihm bzw seinem Mitarbeiter das jetzt
auf die Füße fällt. Wenn die Maschinen so wichtig und so sensibel sind,
dass die vollverschlüsselt betrieben werden müssen, dann empfiehlt sich
eigentlich auch ein geeigneter Unterbau.
Ansonsten sind mobile 7...15" Monitore und All-in-1 USB-Tastaturen mit
Trackball/Mauspad (z.B. Cherry G84-4400) durchaus erhältlich und lösen
das Problem bei jeder Hardware.
fchk
Onkel Ted schrieb:> Bei den Kabeln musst ja genauso vor Ort sein.>> Mit Hardware Dongle booten und dann einfach abziehen wenn durch wäre> denke ich die einfachste Lösung.
Worauf ich eigentlich hinaus wollte: Ein verschlüsselter Rechner, der
zusammen mit dem Schlüssel verloren geht, kann nicht mehr als
verschlüsselt angesehen werden.
Frank K. schrieb:> Ja. Und mit vPro AMT auch. Was ich sagen will, ist, dass der> Verantwortliche bei der Anschaffung der Maschinen entweder zu knauserig> oder zu kurzsichtig gewesen ist und ihm bzw seinem Mitarbeiter das jetzt> auf die Füße fällt. Wenn die Maschinen so wichtig und so sensibel sind,> dass die vollverschlüsselt betrieben werden müssen, dann empfiehlt sich> eigentlich auch ein geeigneter Unterbau.
Meine Fresse. In erster Linie geht es hier um meine Privatsysteme, und
ja, ich habe gute Gründe die zu verschlüsseln. Keine Ahnung, aber
rumbrüllen.
Huch schrieb:> Onkel Ted schrieb:>>> Und was spricht gegen die Nutzung des TPM?>> https://github.com/fox-it/linux-luks-tpm-boot>> https://en.wikipedia.org/wiki/Cold_boot_attack> https://arstechnica.com/gadgets/2021/08/how-to-go-from-stolen-pc-to-network-intrusion-in-30-minutes/
Ein Angreifer kann unmöglich am bestehenden UART/RS232 einen Sniffer
Anbringen welcher das Getippsel mitschneidet. Oh nein, das geht ja.
Du musst auch nicht zwingend ein über I2C/SPI angebundenes TPM benutzen,
du kannst auch das in der CPU wie fTPM benutzen. Diese TPM kann man auch
mit Pin nutzen, dadurch sind nahezu alle diese Attacken nicht mehr
möglich. Den zweiten Faktor kannst du von deinem USB Stick einlesen oder
über eine Tastatur eintippen - Linux braucht dafür keinen Monitor. Und
gerade bei einer kurzen Pin für einen TPM reicht dir eine
Tastatur/Numpad welche zum richtigen Zeitpunkt blinkt.
Onkel Ted schrieb:> Ein Angreifer kann unmöglich am bestehenden UART/RS232 einen Sniffer> Anbringen welcher das Getippsel mitschneidet. Oh nein, das geht ja.
Dann muss er mir die Hardware aber erstmal entwenden, um sie mir
anschließend wieder unbemerkt unterzuschieben. Das ist schon etwas
anderes, als das ein Gerät verloren geht.
Onkel Ted schrieb:> Du musst auch nicht zwingend ein über I2C/SPI angebundenes TPM benutzen,> du kannst auch das in der CPU wie fTPM benutzen.
Cold Boot ist dir bekannt?
Onkel Ted schrieb:> Den zweiten Faktor kannst du von deinem USB Stick einlesen
Eben immer noch nicht.
Onkel Ted schrieb:> über eine Tastatur eintippen
Die Tastatur würde ich eben gerne weglassen, da es sich teilweise um
mobile Systeme handelt.
Huch schrieb:> Die Tastatur würde ich eben gerne weglassen, da es sich teilweise um> mobile Systeme handelt.
Dann kompiliere dir einen Kernel mit Unterstützung für UART über USB wie
ich weiter oben geschrieben habe und mach das.
Du kannst auch eine Anfrage bei Canonical/etc stellen die Option im
Kernel zu aktivieren, ggf. machen sie es, zumindest ggf. für einen
alternativen Kernel.
Irgendeinen Tod musst du sterben.
Aber Sicherheit ohne jegliche Einschränkungen gibt es eben nicht, wobei
man mit optee viel erreichen könnte.
