Leserartikel Ubuntu 23.10 - bringt TPM-unterstützte Festplattenverschlüsselung

[Merkmal]

@kim88 Weißt du ob und wann Intel fTPM unterstützt wird.

 

[kim88]

@Merkmal fTPM sollte direkt unterstützt werden. Dem installer ist es egal ob es ein richtiges TPM Modul oder fTPM ist. Solange es den TPM 2.0 Standard beherrscht.

 

[Merkmal]

Ich hatte es per Installer versucht, aber die Option kann ich nicht auswählen.

TPM2 PCR Machine ID Measurement was skipped because of an unmet condition check

systemctl status systemd-pcrmachine.service
○ systemd-pcrmachine.service - TPM2 PCR Machine ID Measurement
     Loaded: loaded (/lib/systemd/system/systemd-pcrmachine.service; static)
     Active: inactive (dead)
  Condition: start condition failed at Sat 2023-10-07 15:47:43 CEST; 14min ago
       Docs: man:systemd-pcrmachine.service(8)

Okt 07 15:47:43 xyz systemd[1]: systemd-pcrmachine.service - TPM2 PCR Machine ID Measurement was skipped because of an unmet condition check (ConditionPathExists=/sys/firmware/efi/ef

Vielleicht wäre das hier die Lösung? SOLVED - Failed to start TPM2 PCR Machine ID Measurement

 

[kim88]

Nur um sicherzustellen du nutzt die Beta oder Daily Live ISO von Ubuntu 23.10 in der AMD64 Variante?

 

[Merkmal]

Das Image Daily-Live AMD64
Das habe ich auch ausprobiert ubuntu-23.10-beta-desktop-amd64

Komisch ist, dass "fwupdmgr security" bei der Live-Version kein TPM findet, ich habe aber eine aktuelle Ubuntu Installation, dort wird mir TPM2 als "valid" angezeigt.

 

[Piktogramm]

Die nahtlose Kombination von bewährten Sicherheitsstandards mit den fortschrittlichen Funktionen von TPM verspricht eine robustere und zuverlässigere Datenverschlüsselung. Durch das Wegfallen der Notwendigkeit, eine eigene Passphrase festzulegen, und das Vertrauen in die hardwaregestützte Schlüsselgenerierung des TPM, wird nicht nur die Sicherheit erhöht, sondern auch der Prozess der Datenverschlüsselung vereinfacht.

Ähhhh..
So richtig leuchtet mir das Fazit nicht ein. Das was du bzw. Canonical beschreibt schützt doch nur jene Fälle, wo Laufwerke und das Gerät voneinander getrennt werden. Wird der Computer samt Laufwerk entwendet ist, ist keinerlei Schutzwirkung vorhanden.

Im Vergleich zu einem klassischem Gespann aus SecureBoot und dm-crypt wo die Passworteingabe beim Booten notwendig ist, verringert sich damit die Schutzwirkung eher.

Im Vergleich mit TPM + Hardwareverschlüsselung mit einem Opal fähigem Laufwerk + Secure Boot und Passworteingabe beim Booten ist die Schutzwirkung auch eher geringer.

Es ist ja schön, dass Verschlüsselung genutzt wird, Verschlüsselung ist aber irgendwie immer recht sinnig, wenn die Kontrolle über dem Schlüssel nicht bei den Nutzerinnen bleibt. Bei dem was hier beschrieben ist, liegt die Kontrolle der Schlüssel nur bei der Verfügungsgewalt über dem Gerät, welches das TPM stellt.

##########
Abgesehen davon, hier baut Canonical etwas, was dm-crypt mit LUKS schon kann[1], vermischt es aber mit ihrem snapd, dabei sehe ich bisher nichts, was die neue Lösung besser umsetzt. Einzig, dass es mit dem angepasstem Installer deutlich einfacher wird.

https://wiki.archlinux.org/title/Dm...mple_encrypted_root_with_TPM2_and_Secure_Boot

 

[kim88]

@Piktogramm

Es ist ja nicht TPM oder Passphrase man kann auch beides nutzen.

durch TPM hat man aber eine Hardware basierte Sicherheit. Ein Chip zu manipulieren ist komplexer und schwieriger als eine reine Softwarelösung zu manipulieren.

Durch Secure Boot bzw Trusted Boot, wird geprüft ob der Bootloader oder das OS manipuliert wurde und so im Zweifel den Zugriff auf das TPM verweigern.

LUKS Verschlüsselung hat hier viele Nachteile: einerseits ist sie nur so stark wie die Passphrase und die wird wohl in 99.9% schwächer sein als bei einem zufällig generiertem Key im TPM.

LUKS kann man Brute Forcen.

Über Cold Boot Angriffe kann man zumindest in sehr komplexen Angriffszenarien versuchen das LUKS Passwort im RAM auszulesen.

Ka was der Hinweis von Snap soll. Canonical nutzt Snap ist keine Neuheit. Das mittel- und langsfristig alle Pakete gesnapt werden sollen ist ebenfalls ein klares Ziel 🤷‍♂️

 

[frabron]

Das Thema TPM wurde auch neulich im Podcast Linux Matters in den Folgen Using Two GPUs at Once und Um, Actually besprochen, wenn man da sich akustisch informieren möchte 😁
Den einen oder anderen Host kennt man sicherlich auch aus dem Ubuntu-Umfeld 👍

 

[Piktogramm]

Es ist ja nicht TPM oder Passphrase man kann auch beides nutzen.

Und wenn man ein via TPM geschütztes Passwort für die Firmware setzt, kann man auch gleich zusammen mit Opal fähigen Laufwerken Hardwarecrypto nutzen.
Zudem weder du, noch Canonical das setzen eines PWs in Firmware beschreibt und sich großzügig darüber ausgeschwiegen wird, welche Lücken sich da auftun.

durch TPM hat man aber eine Hardware basierte Sicherheit. Ein Chip zu manipulieren ist komplexer und schwieriger als eine reine Softwarelösung zu manipulieren.

Durch Secure Boot bzw Trusted Boot, wird geprüft ob der Bootloader oder das OS manipuliert wurde und so im Zweifel den Zugriff auf das TPM verweigern.

Lied nochmal, alle anderen, aktuell üblichen Wege sind mindestens von SecureBoot abhängig. Eben weil sonst Binaries auf dem Datenträger verfälscht werden können.
Können sie wahrscheinlich auch immer noch, wenn man z.B. via USB ein entsprechend signiertes Image lädt.

LUKS Verschlüsselung hat hier viele Nachteile: einerseits ist sie nur so stark wie die Passphrase und die wird wohl in 99.9% schwächer sein als bei einem zufällig generiertem Key im TPM.

LUKS kann man Brute Forcen.

Sehr schlechte Passwörter helfen nicht. Da hast du recht. Aber bereits mittelprächtige Passwörter sind nahezu nicht knackbar, da muss der Zufall den Angreifenden schon helfen.
Und "BruteForce"
Bei LUKS kommt PBKDF2 über zehn Runden zum Einsatz. Da kommt man auch mir enormen Ressourcen nicht all zu weit, LUKS2 nutzt Argon2.

Über Cold Boot Angriffe kann man zumindest in sehr komplexen Angriffszenarien versuchen das LUKS Passwort im RAM auszulesen.

Bei dem was Canonical macht, liegen die Schlüssel im Betrieb zwangsweise auch im Ram. Das ist ja ebenfalls Crypto, die über die CPU läuft. An dem Angriffsvektor ändert die neue Lösung halt auch nichts.

Und Fairerweise, auch wenn ich Passwortgeschütztes TPM + Opal Laufwerk mit HW-Crypto bevorzuge. Da muss ich auch dazu sagen, dass diese Implementierungen auch schon damit aufgefallen sind, schlampig implementiert zu sein. Also sowohl TPMs, Secure Enclaves der CPU als auch Opal bei den Laufwerken..

Ka was der Hinweis von Snap soll. Canonical nutzt Snap ist keine Neuheit. Das mittel- und langsfristig alle Pakete gesnapt werden sollen ist ebenfalls ein klares Ziel 🤷‍♂️

Naja, Canonical hat alleinig die Hand auf dem SnapStore, was kritikwürdig ist. Canonical führt ein Sicherheitskonzept ein, was eigentlich nichts besser macht als vorhandene Lösungen, dafür aber von ihrem SnapStore abhängt. Die Entwicklung stinkt mir halt ganz gewaltig.

 

[Merkmal]

Ich habe eine Meldung gefunden, allerdings weiß ich nicht, wie ich bei einem Live-USB-Stick den Neustart machen soll.

TPM is in DA Lockout Mode

This error typically means the TPM has been locked to protect the system against potential dictionary attacks (DA) and the TPM needs to be cleared before the Ubuntu Core installation will proceed.

To clear the TPM on hardware, boot a classic Ubuntu system (such as a live version of Ubuntu 20.04 LTS from USB storage) and run the following command from a terminal:

echo 5 | sudo tee /sys/class/tpm/tpm0/ppi/request

To clear a software TPM, such as the test-snapd-swtpm snap, remove it and re-install it again:

snap remove test-snapd-swtpm --purge; snap install test-snapd-swtpm

Now reboot the problematic system and re-attempt the Ubuntu Core installation, which should continue without error.

Quelle

Und test-snapd-swtpm gibt es nur als beta oder edge, also geht nur "snap install --beta test-snapd-swtpm".

 

[Merkmal]

Ich habe es geschafft. Es scheint wirklich "snap remove test-snapd-swtpm --purge; snap install --beta test-snapd-swtpm" und erneutes laden des Live-Mediums ausgereicht zu haben. Die Installation klappte.

Nur ein paar Fragen habe ich noch.

Welche Passphrase verwendet Ubuntu?
Wie kann man grub boot Parameter einstellen? Sonst habe ich das unter /etc/default/grub gemacht.

 

[norKoeri]

[…] Linux-Distributionen die Möglichkeiten von TPM nicht nutzen.

Mindestens sollte in Kombination [mit TPM] noch eine PIN verwendet werden.

Habe mir TPM-FDE eben auch mal gegönnt. Vorher noch über Windows die Firmware von BIOS und TPM und SSD aktualisiert. Am Ende musste ich über das BIOS das TPM bereinigen, weil es Windows 11 automatisch in Beschlag nimmt. Dann durfte ich im Ubuntu-Installer endlich TPM-FDE auswählen. Drei Fragen:

1. Das mit der „enhanced PIN“ ist Microsoft BitLocker und Dank vieler Anleitungen im Netz einigermaßen klar. Aber auch Canonicals Blog-Artikel schreibt „users who will choose to use a passphrase (in addition to TPM) […]“. Nur wo/wie setze ich das? Das „TPM Owner Password“ dürfte es nicht sein. Oder meint Canonical etwa einfach ein BIOS-Passwort?

2. Wenn ich zwei Festplatten im Computer hätte, eine mit Windows BitLocker und eine mit Ubuntu FDE, wie kann ich beide im TPM ablegen oder muss dann Ubuntu weiterhin LUKS-FDE bleiben?

3. Was bringt mir TPM-FDE eigentlich außer einem Anti-Hammering-Schutz (wenn ich zusätzlich eine PIN nutze); habe ich dadurch irgendeinen Geschwindigkeitsvorteil? BitLocker kann ja anstatt Software-Encryption auch optional Hardware-Beschleunigung über TCG-OPAL nutzen. Soweit ich Canonicals Blog-Post verstehe, scheint der Nutzen bisher allein „[TPM-FDE] provides a lower barrier to enabling encryption“ zu sein.

Wenn irgendwer eine der Fragen beantworten kann … irgendwie habe ich mich verlaufen, denn ich suche mich gerade zu Tode.

 

[netzgestaltung]

dann feiert eben die Snap Phobie fröhliche Urständ.

und womit? mit Recht!

 

[@mo]

Nöö!

 

[foofoobar]

TPM Paranoia ist eh irgendwie schräg. Ironischerweise höre ich diese Paranoia bei mobilen Systemen wie Android (TEE - Trusted Execution Environment und Hardware-Backed Keystore) oder iPhones (Secure Enclave seit A7-Prozessor) so gut wie nie.
Aber wahrscheinlich setzen Sie sich die Kritiker damit einfach weniger auseinander.

Wer diese Telefone als trusted Device annimmt dem ist sowieso nicht mehr zu helfen.
An eine gewöhnliche Linux-Büchse kann und sollte man andere Ansprüche stellen.

Ergänzung (21. Januar 2024)

Durch Secure Boot bzw Trusted Boot, wird geprüft ob der Bootloader oder das OS manipuliert wurde und so im Zweifel den Zugriff auf das TPM verweigern.

Da Secure Boot per Design sowieso ein OS mit Lücken bootet konvergiert der Nutzen gegen Null.

Ergänzung (21. Januar 2024)

durch TPM hat man aber eine Hardware basierte Sicherheit. Ein Chip zu manipulieren ist komplexer und schwieriger als eine reine Softwarelösung zu manipulieren.

Was kann diese HW im Fall von LUKS konkret besser?
Bitte kein Blabla ala Magic Box.

LUKS Verschlüsselung hat hier viele Nachteile: einerseits ist sie nur so stark wie die Passphrase und die wird wohl in 99.9% schwächer sein als bei einem zufällig generiertem Key im TPM.

Du hast das Konzept der Passphrase (insbesondere bei LUKS) nicht verstanden, der konkrete Key für den symmetrischen Cipher welcher auf die Daten in den Blöcken der Platte wirkt wird (korrekte Anwendung vorausgesetzt) wird zufällig generiert und durch die Passphrase symmetrisch verschlüsselt im LUKS-Header abgelegt.

LUKS kann man Brute Forcen.

Über Cold Boot Angriffe kann man zumindest in sehr komplexen Angriffszenarien versuchen das LUKS Passwort im RAM auszulesen.

Dafür schützt das TPM im Fall von LUKS auch nicht!
Wahrscheinlich kann man sich den Key "einfach" aus /dev/mem abholen.

BTW: Wie sorgt man dafür das ein Feature nicht hinterfragt wird? Man baut eine Box und schreibt ganz fett Security drauf!

Ergänzung (21. Januar 2024)

• Hardware-Speicher für Schlüssel: Schlüssel, die im TPM gespeichert sind, können so konfiguriert werden, dass sie nicht exportiert werden können. Das erhöht die Sicherheit gegen Schlüsseldiebstahl.

Welchen konkreten Anwendungsfall gibt es den im Fall von LUKS dafür?

 

[Wochenende]

Da Secure Boot per Design sowieso ein OS mit Lücken bootet konvergiert der Nutzen gegen Null.

Secure Boot ist beim PC der einzige Schutz gegen einen manipulierten Bootloader. Man kann es kritisieren, aber nutzlos ist es nicht.

 

[AGB-Leser]

Da grub ja mittlerweile auch mit secureboot funktioniert, ist ein manipulierter bootloader (grub) doch schon vorhanden

 

[foofoobar]

Secure Boot ist beim PC der einzige Schutz gegen einen manipulierten Bootloader. Man kann es kritisieren, aber nutzlos ist es nicht.

Glitzernagellack auf den Schrauben hilft besser dagegen.
Wo kommt eigentlich die Signatur bei Anpassungen der initrd her?

 

[Wochenende]

Da grub ja mittlerweile auch mit secureboot funktioniert, ist ein manipulierter bootloader (grub) doch schon vorhanden

Wenn Grub manipuliert wurde, startet der Rechner nicht.

Wo kommt eigentlich die Signatur bei Anpassungen der initrd her?

Welche Signatur? Die initrd hat keine Signatur, das ist ein bekanntes Problem. Ja, jeder kann ein Shellscript reinpacken dass das Passwort abgreift. Da kommt dann TPM ins Spiel. TPM gibt den Schlüssel nur an erlaubte Programme. Das steht auch im Canonical-Artikel auf den sich der OP bezieht. Hat schon alles seinen Sinn.

https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html

 

[AGB-Leser]

Wenn Grub manipuliert wurde, startet der Rechner nicht.

Wollte damit andeuten, dass man mit grub alles starten kann, was man will