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?
Der uboot hat doch in der config die Terminalschnittstelle, und ausserdem kan Linux von USB booten.
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.
:
Bearbeitet durch User
Ich mach sowas über SSH: https://www.thomas-krenn.com/de/wiki/Voll-verschl%C3%BCsseltes-System_via_SSH_freischalten Deine Lösung ist aber auch möglich: https://www.coreboot.org/GRUB2#On_a_USB_serial_or_USB_debug_adapter 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. Eine weitere Option/Ergänzung wäre übrigens ein Dongle wie der Yubikey/Nitrokey/solokey. Kommt halt auch darauf an vor was du dich absichern möchtest.
Evtl. kannst du auf folgendem aufbauen also ein unverschlüsseltes OS "vorbooten" um sich dann per ssh einloggen und dann per kexec das verschlüsselte System zu booten: https://github.com/flowztul/keyexec Was ist kexec: https://wiki.archlinux.org/title/kexec
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.
(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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
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/
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.