mikrocontroller.net

Forum: PC Hard- und Software Laptop mit Linux komplett verschlüsseln


Autor: Larry (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Guten Abend,

ich richte mir gerade einen Arbeits-Laptop ein - es wird vermutlich das 
aktuelle Ubuntu LTS werden. Die darauf befindlichen Daten würde ich 
gerne vollständig verschlüsseln, also inklusive Betriebssystem und z.B. 
externen Festplatten und USB-Sticks. Früher habe ich unter Windows mal 
eine Zeit lang TrueCrypt benutzt und fand das sehr komfortabel, auch 
weil man damit mühelos verschlüsselte externe Datenträger einrichten und 
einbinden konnte. Den Nachfolger Veracrypt habe ich nie ausprobiert, ich 
gehe aber davon aus, dass der Fork ähnliche Funktionen hat.

Sehe ich das richtig, dass Veracrypt nur unter Windows eine vollständige 
Datenträger-Verschlüsselung unterstützt?

Ist dm-crypt unter Linux einem Veracrypt unter Windows ebenbürtig und 
ist somit Veracrypt nur dann nötig, wenn ich Betriebssystem-Übergreifend 
verschlüsselte Datenträger nutzen würde? Ich habe z.B. gelesen, dass 
LUKS von der Boot-Partition startet und diese daher unverschlüsselt ist. 
Wäre das im Falle einer nachträglichen Verschlüsselung nicht eventuell 
problematisch, weil sich an der Stelle der Boot-Partition früher 
möglicherweise sensible Daten befunden haben? Bei Truecrypt wurde ja 
glaube ich der Bootloader in den normalerweise ungenutzten Bereich 
hinter den MBR geschrieben, so dass sämtliche Partitionen verschlüsselt 
werden konnten. Wobei ich mich da frage, wie das dann bei Veracrypt und 
UEFI aussieht?

Bietet Veracrypt noch andere Vorteile, z.B. Audit, Komfort, etc.?

Viele Grüße
Larry

Autor: sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ubuntu bietet von haus aus schon eine Partitionsverschlüsselung. Das 
kann man bei der Installation auswählen. Dazu kann man auch Externe 
Datenträger mit diesen Partitionstyp verschlüsseln.
Beim Boot bekommt man dann eine abfrage nach Password welche alle 
eingetragenen Partitionen freigibt.

Ich hatte das Bei Ubuntu 16 mal gemacht ist aber schon wieder so lange 
her das ich mich an Details kaum mehr errinner

Autor: Reinhard S. (rezz)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Larry schrieb:
> Ich habe z.B. gelesen, dass
> LUKS von der Boot-Partition startet und diese daher unverschlüsselt ist.
> Wäre das im Falle einer nachträglichen Verschlüsselung nicht eventuell
> problematisch, weil sich an der Stelle der Boot-Partition früher
> möglicherweise sensible Daten befunden haben?

Warum? Wenn da jetzt eine Boot-Partition liegt sind die Daten ja eh 
überschrieben.

Ich hab das vor Jahren (Ubuntu 12 oder 14 glaube ich) mal mit LUKS 
gemacht. Funktionierte, war aber beim Booten/Passwort eingeben natürlich 
Linuxtypisch eher Konsolencharme.

Obs wirklich sicher/sonstwas war hab ich natürlich nicht überprüft.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Larry schrieb:
> Guten Abend,
>
> ich richte mir gerade einen Arbeits-Laptop ein - es wird vermutlich das
> aktuelle Ubuntu LTS werden.

Nimm lieber Debian stable.
Alle Pakete im Ubuntu Paketrepository universe und multiverse werden von 
Canonical ab dem Zeitpunkt des Releases nicht mehr supported.
Das überlässt man allein der Community und da es keine für die Pakete 
zuständigen Maintainer gibt, fühlt sich dort auch niemand verantwortlich 
da etwas zu machen. Viele dürften auch gar nicht wissen wie es geht.

Bei Debian stable wird jedes Paket im Paketrepository mit Patches für 
sorgt. Für jedes Paket gibt es einen Maintainer, der für die Pflege 
dieses Pakets zuständig ist.
Ist das nicht der Fall, dann fliegt das Paket aus dem repo oder es wird 
deutlich darauf hingewiesen, dass es momentan keinen Maintainer hat.



> Die darauf befindlichen Daten würde ich
> gerne vollständig verschlüsseln, also inklusive Betriebssystem und z.B.
> externen Festplatten und USB-Sticks.

Die Verschlüsselung erfolgt mit LUKS.
Der Kernel wird, wenn ich mich nicht irre, allerdings für gewöhnlich 
nicht verschlüsselt und in die /boot Partition installiert, denn er muss 
ja erst einmal vom BIOS/UEFI oder Bootloader geladen werden, damit 
dieser die Platte entschlüsseln kann.
Wäre er verschlüsselt, dann gäbe es keinen Zugriff auf den Kernel.


> Früher habe ich unter Windows mal
> eine Zeit lang TrueCrypt benutzt und fand das sehr komfortabel, auch
> weil man damit mühelos verschlüsselte externe Datenträger einrichten und
> einbinden konnte. Den Nachfolger Veracrypt habe ich nie ausprobiert, ich
> gehe aber davon aus, dass der Fork ähnliche Funktionen hat.

Truecrypt gibt es auch für Linux.
Für die Systemppartitionen ist zwar LUKS der sinnvollere Weg,aber für 
die USB Sticks und externe Platten kannst du Truecrypt durchaus 
weiterverwenden.


>Ich habe z.B. gelesen, dass
> LUKS von der Boot-Partition startet und diese daher unverschlüsselt ist.

Das ist richtig. Sie muss auch unverschlüsselt sein, damit man den 
Kernel laden kann und eine Entschlüsselung möglich wird.


> Wäre das im Falle einer nachträglichen Verschlüsselung nicht eventuell
> problematisch, weil sich an der Stelle der Boot-Partition früher
> möglicherweise sensible Daten befunden haben?
Wenn du bei dieser Partition früher mal sensible Daten hattest, dann 
kannst du die Partition mit unnützen Zufallsdaten einmal vollschreiben 
und dann wieder löschen. Danach sind die Daten weg.

Bei SSDs sollte wegen Wear Leveling der gesamte Datenträger einmal neu 
beschrieben werden oder die eingebaute Verschlüsselung verwendet werden.
Gegen Geheimdienste besteht die Möglichkeit, das letztere Methode 
unsicher ist.

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei grub2 gibt es mittlerweile auch ein Modul, welches LUKS 
entschlüsseln kann. Dieses Modul kann zusammen mit den restlichen 
Grub-Modulen in den Bereich zwischen Partitionstabelle und Start der 
ersten Partition eingebettet werden. Damit kann dann auch die Partition 
mit Kernel und Initramfs verschlüsselt werden.

Nachteil ist daß beim Booten das Passwort 2x eingegeben werden muss: als 
erstes im Grub um den Kernel zu starten und danach dann nochmal wenn das 
Initramfs die Partitionen öffnen möchte.

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Bei grub2 gibt es mittlerweile auch ein Modul, welches LUKS
> entschlüsseln kann. Dieses Modul kann zusammen mit den restlichen
> Grub-Modulen in den Bereich zwischen Partitionstabelle und Start der
> ersten Partition eingebettet werden. Damit kann dann auch die Partition
> mit Kernel und Initramfs verschlüsselt werden.
>
> Nachteil ist daß beim Booten das Passwort 2x eingegeben werden muss: als
> erstes im Grub um den Kernel zu starten und danach dann nochmal wenn das
> Initramfs die Partitionen öffnen möchte.

Es bringt halt vor allem auch relativ wenig, außer du betrachtest es als 
sensible Daten welche Kernel-Version du verwendest. Selbst die 
Root-Partition zu verschlüsseln ist m.E. in jedem normalen Fall 
unsinnig, weil die auch nichts enthält außer einer Liste installierter 
Standard-Pakete.

Autor: Nano (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Sinnvoll ist eigentlich höchstens nur das unter
/etc
/home
/tmp
/var

zu verschlüsseln, sowie das, was man unter
/media
einbindet.

In etc.ssh könnten bspw. PW für ssh liegen.
In /tmp werden oft PDF Dateien Zwischengespeichert, die könnten auch per 
E-Mail reinkommen wenn man WebMail verwendet.
In /var/srv könnte ein Webseite laufen oder in /var/spool die ganzen 
Druckaufträge zwischengespeichert sein.
Und /home ist klar.

Ach und /root könnte auch noch wichtig sein, da dort die bash für root 
die history speichert.


Wenn man es aber bequem haben will, dann könnte man auch die 
Verschlüsselung bei /boot, /usr und /opt weglassen und den Rest 
verschlüsseln, ob die Programme dann dadurch aber schneller starten, 
weiß ich nicht.


Der Einfachheit halber verschlüsselt man einfach alles außer /boot.
Außerdem ist das auch praktischer, da man so bspw. für die verschiedenen 
Partitionen bei Verwendung von LVM später die Größen ändern kann.

Autor: Frank K. (frank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Bei grub2 gibt es mittlerweile auch ein Modul, welches LUKS
> entschlüsseln kann. Dieses Modul kann zusammen mit den restlichen
> Grub-Modulen in den Bereich zwischen Partitionstabelle und Start der
> ersten Partition eingebettet werden. Damit kann dann auch die Partition
> mit Kernel und Initramfs verschlüsselt werden.
>
> Nachteil ist daß beim Booten das Passwort 2x eingegeben werden muss: als
> erstes im Grub um den Kernel zu starten und danach dann nochmal wenn das
> Initramfs die Partitionen öffnen möchte.

Nicht unbedingt. Wenn eine initrd Ramdisk verwendet wird, kann eine 
Datei mit einer Passphrase in diese eingetragen werden. Diese wird dann 
vom Kernel verwendet. Somit ist die Passphrase Eingabe nur im uboot 
nötig und die komplette Disk ist verschlüsselt.

Autor: JJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Sinnvoll ist eigentlich höchstens nur das unter
> ...

Auf gar keinen Fall. Sinnvoll ist es nur die Platte ganz zu 
Verschlüsseln.
Wenn zu z.B. /usr nicht verschlüsselst, ist es ohne weiteres möglich das 
System zu von CD zu booten (oder die Platte an einen anderen Rechner zu 
hängen) und Malware zu installieren.
Darüber hinaus ist es auch einfacher die ganze Platte zu verschlüsseln 
als einzelne Partitionen anders zu behandeln.

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven B. schrieb:
> Gerd E. schrieb:
>> Bei grub2 gibt es mittlerweile auch ein Modul, welches LUKS
>> entschlüsseln kann. Dieses Modul kann zusammen mit den restlichen
>> Grub-Modulen in den Bereich zwischen Partitionstabelle und Start der
>> ersten Partition eingebettet werden. Damit kann dann auch die Partition
>> mit Kernel und Initramfs verschlüsselt werden.
>
> Es bringt halt vor allem auch relativ wenig, außer du betrachtest es als
> sensible Daten welche Kernel-Version du verwendest. Selbst die
> Root-Partition zu verschlüsseln ist m.E. in jedem normalen Fall
> unsinnig, weil die auch nichts enthält außer einer Liste installierter
> Standard-Pakete.

Das Verschlüsseln ist beim Kernel und den Programmen in der Tat nicht so 
spannend. Was aber spannend sein kann, ist Manipulationen zu verhindern 
oder deutlich zu erschweren. So könnte jemand z.B. ein Rootkit im Kernel 
verstecken, welches die Passwörter ausliest und an den Angreifer 
weitergibt.

Wenn auch Kernel und Initramfs verschlüsselt sind, ist es für einen 
Angreifer deutlich schwieriger ein passendes Rootkit zu bauen, da man es 
dann nicht direkt an den konkret verwendeten Kernel anpassen kann, 
sondern generisch für eine breite Palette von Kerneln passend machen 
muss.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JJ schrieb:
> Nano schrieb:
>> Sinnvoll ist eigentlich höchstens nur das unter
>> ...
>
> Auf gar keinen Fall.

Doch, es ist abhängig vom Fall.

>Sinnvoll ist es nur die Platte ganz zu
> Verschlüsseln.
> Wenn zu z.B. /usr nicht verschlüsselst, ist es ohne weiteres möglich das
> System zu von CD zu booten (oder die Platte an einen anderen Rechner zu
> hängen) und Malware zu installieren.

Wenn du natürlich Angst hast, dass der Geheimdienst bei dir die 
Programme austauscht, dann ist die Verschlüsselung von allem natürlich 
sinnvoll, wobei dir der dann ohnehin einen HW Keylogger in die Tastatur 
einbauen wird.
Der normale Benutzer muss nur verschlüsseln, damit seine privaten Daten 
im Falle eines Diebstahls nicht missbraucht werden oder wenn er den 
Datenträger beim Hersteller austauschen muss.
In beiden Fällen ist es nicht relevant, wenn der Dieb oder der 
Hersteller Klartext Zugriff auf bspw. /usr hat.

> Darüber hinaus ist es auch einfacher die ganze Platte zu verschlüsseln
> als einzelne Partitionen anders zu behandeln.

Das sagte ich bereits.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> So könnte jemand z.B. ein Rootkit im Kernel
> verstecken, welches die Passwörter ausliest und an den Angreifer
> weitergibt.

Wer das schafft, der hat ohnehin lokalen Zugriff auf deinen Rechner und 
somit ganz andere Methoden.
Und wenn er remote eindringen kann, dann ist die Verschlüsselung sowieso 
ausgehebelt, da das Dateisystem in dem Moment gerade entschlüsselt 
zugänglich ist.

Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Larry schrieb:
> ich richte mir gerade einen Arbeits-Laptop ein
> Die darauf befindlichen Daten würde ich
> gerne vollständig verschlüsseln

Machen. Alle ernstzunehmenden Distributionen bieten das mittlerweile 
direkt aus dem Installationsassistenten an.

>  Früher habe ich unter Windows mal
> eine Zeit lang TrueCrypt benutzt und fand das sehr komfortabel

Truecrypt ist potentiell kompromittiert und folglich tot.

> Ist dm-crypt unter Linux einem Veracrypt unter Windows ebenbürtig

Ich kenne Veracrypt nicht. Aber dm-crypt unterstützt praktisch alle 
Hash- und Verschlüsselungsalgorithmen. Im Zweifel halte ich das für die 
leistungsfähigere Infrastruktur.

> ist somit Veracrypt nur dann nötig, wenn ich Betriebssystem-Übergreifend
> verschlüsselte Datenträger nutzen würde?

Da von Windows-Seite anscheinend keinerlei Kooperationsbereitschaft für 
die Unterstützung von z.B. LUKS besteht, bist du für 
Betriebssystem-übergreifende Verschlüsselung auf das angewiesen, was 
Windows von Haus aus und Linux (vulgo: dm-crypt) aus Gefälligkeit 
unterstützt.

> Ich habe z.B. gelesen, dass LUKS von der Boot-Partition startet
> und diese daher unverschlüsselt ist.

Das ist prinzipbedingt nicht anders möglich. Der Entschlüsselungscode 
muß ja irgendwoher geladen werden. Und wenn er wie bei Linux Teil des 
Kernels ist, dann muß der Kernel unverschlüsselt geladen werden.

Allerdings müssen Kernel und Co. nicht auf der Platte liegen. Du kannst 
auch z.B. von einem USB-Stick booten. Dann ist alles andere 
verschlüsselt.

> Wäre das im Falle einer nachträglichen Verschlüsselung nicht eventuell
> problematisch, weil sich an der Stelle der Boot-Partition früher
> möglicherweise sensible Daten befunden haben?

Das hat mit dem Verschlüsselungssystem erstmal gar nichts zu tun. Wenn 
auf irgendeinem Speichermedium mal unverschlüsselte sensible Daten 
gelegen haben, dann muß man die mindestens einmal überschreiben. Auf 
welchem Weg auch immer. Einfach nur einen verschlüsselten Container 
anlegen reicht im Zweifelsfall nicht aus, weil das eben nicht den 
kompletten Datenträger überschreibt. Ich hingegen habe es mir zur 
Angewohnheit gemacht, neu angelegte Cryptocontainer einmal mit 
Zufallszahlen zu beschreiben (noch bevor ein Filesystem drauf kommt). 
Dadurch kann jemand ohne den Schlüssel weder sagen, ob oder welches 
Filesystem da drauf ist noch wie voll das ist.


Reinhard S. schrieb:
> Ich hab das vor Jahren (Ubuntu 12 oder 14 glaube ich) mal mit LUKS
> gemacht. Funktionierte, war aber beim Booten/Passwort eingeben natürlich
> Linuxtypisch eher Konsolencharme.

Die Schlüsselverwaltung der meisten Distributionen kann mittlerweile 
auch Crypto-Schlüssel von z.B. USB-Sticks lesen. Mein Ubuntu-Server z.B. 
liest die Crypto-Keys wahlweise von einem USB-Stick oder fragt auf der 
Konsole. Dank LUKS können das auch verschiedene Schlüssel sein. Ein 
memorierbarer für die Konsole und ein Zufallsstring für den USB-Stick. 
So kann man letzteren auch leicht entwerten, falls der USB-Stick 
abhanden kommen sollte. Und man kann auch einen weiteren Schlüssel 
ausgedruckt beim Anwalt im Safe liegen haben (LUKS erlaubt bis zu 8 
Schlüssel pro Container).


Gerd E. schrieb:
> Das Verschlüsseln ist beim Kernel und den Programmen in der Tat nicht so
> spannend. Was aber spannend sein kann, ist Manipulationen zu verhindern
> oder deutlich zu erschweren. So könnte jemand z.B. ein Rootkit im Kernel
> verstecken, welches die Passwörter ausliest und an den Angreifer
> weitergibt.

Korrekt. Deswegen ist eine Prüfung der /boot Partition (intrusion 
detection) auch unerläßlich. Natürlich erst aus dem entschlüsselten 
Root-Filesystem heraus und mit den Prüfsummen aus eben diesem. Ich 
verwende dafür fcheck.

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
>> Es bringt halt vor allem auch relativ wenig, außer du betrachtest es als
>> sensible Daten welche Kernel-Version du verwendest. Selbst die
>> Root-Partition zu verschlüsseln ist m.E. in jedem normalen Fall
>> unsinnig, weil die auch nichts enthält außer einer Liste installierter
>> Standard-Pakete.
>
> Das Verschlüsseln ist beim Kernel und den Programmen in der Tat nicht so
> spannend. Was aber spannend sein kann, ist Manipulationen zu verhindern
> oder deutlich zu erschweren.
>
> [...]
>
> Wenn auch Kernel und Initramfs verschlüsselt sind, ist es für einen
> Angreifer deutlich schwieriger ein passendes Rootkit zu bauen, da man es
> dann nicht direkt an den konkret verwendeten Kernel anpassen kann,
> sondern generisch für eine breite Palette von Kerneln passend machen
> muss.

Ich bin mir tatsächlich ein bisschen unschlüssig, wie ich das sehe. 
Formal gesehen bringt es in meiner Sicht ohne TPM-Hardware o.ä. nichts. 
Der Angreifer kann das komplette Betriebssystem ersetzen, und der Ersatz 
kann sich völlig beliebig verhalten. Hier darauf zu bauen, dass man eine 
Manipulation bemerkt, weil beim Booten eine andere Kernel-Version da 
steht ist bestenfalls Security by Obscurity und aus der 
Theorie-Perspektive nutzlos.

Pragmatisch betrachtet hingegen halte ich beide Angriffsszenarien für 
äußerst unplausibel. Das reale Szenario ist, dass jemand deinen Laptop 
klaut und deine ganzen persönlichen Daten hat. Dass der Angreifer per 
Boot-Medium ein Rootkit installiert, dir den Rechner dann zurückgibt und 
dir dann deine Daten klaut ... denkbar, aber dieser Art von Angreifer 
wird sich auch vom Eintippen der richtigen Kernel-Version nicht 
zuverlässig aufhalten lassen. Wenn ich davor Angst hätte, würde ich mir 
irgendeinen Verified Boot-Kram suchen.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:

> Truecrypt ist potentiell kompromittiert und folglich tot.

Es wird zwar nicht mehr in Form von Truecrypt weiterentwickelt, aber es 
ist nicht kompromittiert.
Es wurde, nach dem die offiziellen Entwickler daran die Arbeit 
eingestellt haben, einen Code Audit durchgeführt, dessen Ergebnis keine 
Kompromittierung ergab.
Siehe dazu:
https://opencryptoaudit.org/
https://opencryptoaudit.org/reports/TrueCrypt_Phase_II_NCC_OCAP_final.pdf

Die verschlüsselten TC Archive und Partitionen sind also sicher 
verschlüsselt und man kann TC auf dem lokalen Rechner durchaus bis auf 
einen kleinen Haken einsetzen.

Denn das einzige was man gefunden hat, war eine Sicherheitslücke, die 
eine Privileg Escalation erlaubte, das hat aber nichts mit der 
Verschlüsselung an sich zu tun.
Siehe dazu auch folgender Artikel:
https://www.golem.de/news/truecrypt-sicherheitsluecken-in-open-source-verschluesselung-1509-116596.html

Die ist der einzige Grund TC nicht zu verwenden, aber auch nur relevant, 
wenn der Rechner läuft und man TC ausgeführt hat.
Ist der Rechner offline, dann kommt ohne Schlüssel niemand an die mit TC 
verschlüsselten Dateien heran.

TC ist hier nicht kompromittiert und hat auch keine Hintertür, die hätte 
man ansonsten bei den Code Audits gefunden.
Und das war nicht nur einer, das Frauenhofer Institut hat auch noch 
einen durchgeführt.



>> Ist dm-crypt unter Linux einem Veracrypt unter Windows ebenbürtig
>
> Ich kenne Veracrypt nicht.

Im Prinzip ist es ein Fork von Truecrpypt, bei dem man ein paar weitere 
Features einbaute, die sich dann im Nachhinein als unsichere 
Verschlüsselungsverfahren und veralteter unsicherer Code aus alten 
Bibliotheken herausstellten.
Die Probleme wurden inzwischen behoben. Ob das aber besser ist, wenn 
immer neues eingebaut wird, ist nicht unbedingt besser.

Autor: Jiri D. (ucbastler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Larry schrieb:
> Die darauf befindlichen Daten würde ich
> gerne vollständig verschlüsseln, also inklusive Betriebssystem und z.B.
> externen Festplatten und USB-Sticks.

Das ist eine gute Idee. Komplettverschlüsselung (Daten+OS) hat bei 
Festplatten den Vorteil, dass ein Angreifer den unverschlüsselten MBR, 
eine kleine Partition mit /boot (verschlüsselt oder unverschl.) und eine 
riesige Partition über den ganzen Rest sieht. Der Angreifer kann jetzt 
nicht herausfinden, ob/wie viel das alles wichtige Daten sind, oder nur 
(bekannte) OS Dateien (15 GB FlightGear Flugimulator oder so...), oder 
ob eh nahezu alles leer ist.

Bei SSDs (mit TRIM) kann ein Angreifer dennoch Metadaten wie Dateigrößen 
abschätzen, weil die ungenutzten Blöcke markiert sind. Ich nutze hierbei 
den gleichen Setup wie bei HDDs und nehme das in kauf (TRIM ist mir das 
in diesem Fall Wert).

> Ich habe z.B. gelesen, dass
> LUKS von der Boot-Partition startet und diese daher unverschlüsselt ist.

/boot kann verschlüsselt werden. Grub2 fragt dann nach der Passphrase 
zum Entsperren von /boot.

https://wiki.debian.org/Grub2#Configure_encrypted_.2Fboot

Damit das initramfs nicht nochmal nach einer Passphrase fragt, kann man 
ein keyfile einrichten und mit in die initrd packen. Zusätzlich kann man 
aber auch eine Passphrase eingestellt haben (LUKS unterstützt mehrere 
key slots), falls man mal ohne direkten Zugriff auf das keyfile die 
LUKS-Partition öffnen möchte (z.B backup, Live-CD).

Persönlich habe ich meine Festplatte komplett verschlüsselt und boote 
vom USB-Stick (grub2 + encrypted /boot mit keyfile und detached LUKS 
header der Platte) von Schlüsselbund in der Hosentasche. Die Festplatte 
sieht äußerlich komplett random aus und hat keinen LUKS header. Man 
könnte dadurch sagen, dass die Platte halt ungenutzt/leer ist (plausible 
deniability), allerdings ist das zugegebenermaßen eher ein 
hypothetisches Szenario. Vom USB-Stick und von der Platte mache ich 
natürlich regelmäßig Backups.

> Wäre das im Falle einer nachträglichen Verschlüsselung nicht eventuell
> problematisch, weil sich an der Stelle der Boot-Partition früher
> möglicherweise sensible Daten befunden haben?

Jeden Datenträger mit unverschlüsselten Daten (bei verschlüsselten 
genügt eigentlich der LUKS header/dort wo die Schlüssel zum Entsperren 
stehen) sollte man vor der Weiterverwendung (Neuinstallation) 
grundsätzlich einmal komplett mit Zufallsdaten überschreiben. Der 
Debian-Installer macht das automatisch, wenn man bei der Installation 
LUKS Partitionen anlegt. Persönlich erstelle ich ein LUKS volume mit 
irgendeiner temporären Passphrase, entsperre es und überschreibe es mit 
dd von /dev/zero. Das ist schneller als z.B. von /dev/urandom zu 
schreiben und genauso gut. Anschließend den LUKS header mit /dev/urandom 
überschreiben.

> Bei Truecrypt wurde ja
> glaube ich der Bootloader in den normalerweise ungenutzten Bereich
> hinter den MBR geschrieben, so dass sämtliche Partitionen verschlüsselt
> werden konnten. Wobei ich mich da frage, wie das dann bei Veracrypt und
> UEFI aussieht?

Je nach Paranoia-Level und Hardware kannst du dir natürlich auch 
coreboot/libreboot anschauen. Das unterstützt grub2 als Payload und kann 
verschlüsselte und signierte kernel laden usw.

https://www.coreboot.org/Security
https://www.coreboot.org/GRUB2#Advanced_Features

Verschiebt den Angriffspunkt natürlich zum BIOS/EFI. Ich habe einen 
Rechner hier, bei dem ich das so eingerichtet habe und das BIOS steckbar 
gemacht habe (original SO8 auslöten, Kupferlackdraht, Steckerleiste). 
Wenn Laptop abgeschaltet: Tastatur hoch klappen und BIOS-Flash 
entnehmen.
Doch auch das verschiebt den Angriffsvektor nur: man könnte ja auch den 
EC neu flaschen oder z.B. das TPM mit einem rogue IC am LPC-Bus 
austauschen...

> Bietet Veracrypt noch andere Vorteile, z.B. Audit, Komfort, etc.?

Unter Linux ist LUKS der akzeptierte Standard, wird beispielsweise auch 
von Tails (https://tails.boum.org) verwendet. Auch: 
https://guardianproject.info/code/luks/

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zur eigentlichen Frage, wie eine Verschlüsselung unter Linux 
durchgeführt wird, existieren im Netz eine Vielzahl an Anleitungen.

Was ich ganz witzig finde: 
https://github.com/stupidpupil/https-keyscript

Beim Hochfahren kontaktiert Dein Server eine von Dir vorgegebene URL und 
lädt  eine dort vorhandene verschlüsselte Datei herunter, die den Key 
zum Entschlüsseln des Systems enthält.

Vorteil: Das Passwort muß nicht mit jedem Systemstart eingegeben werden.
Wenn Dein Rechner gestohlen wird, löscht Du die Key-Datei auf dem 
externen Server und die Daten auf Deinem Rechner sind für alle Welt 
nutzlos.

Autor: JJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
>> Auf gar keinen Fall.
>
> Doch, es ist abhängig vom Fall.
> ...

Das stimmt so leider nicht.

Die Gefahr das jemand Programme austauscht ist absolut nicht abstrakt 
sondern sehr real und dazu noch sehr einfach umzusetzen. Der Angreifer 
muss lediglich irgendeinen Dienst der üblicherweise im Hintergrund 
ausgeführt wird durch ein Script austauschen welches nach deinem 
nächsten boot die Inhalte der Home Partition im Hintergrund sonstwohin 
streamt. Der Anwender könnte die Aktivität sehen wenn er danach sucht 
oder die Softwareintegrität prüft, aber das war es auch schon. Die 
notwendige Voraussetzung für das Einschleusen von Malware ist lediglich, 
dass das Notebook an der passenden Stelle für eine gewisse Zeit mit dem 
Angreifer allein ist. Ich gehe nicht davon aus, dass der OP ein Notebook 
das für eine gewisse Zeit abkömmlich wird grundsätzlich als 
kompromittiert ansehen möchte.
Einen Hardware Keylogger oder andere Hardware "Lösungen" sehe ich da 
schon ehr im Bereich der Geheimdienste da hier allein die Beschaffung 
(vermutlich) schon nicht so einfach ist.

Meine Empfehlung ist also eine Full-Disk Encryption über alles entweder 
mit der nativen Linux Lösung (LUKS und Co.) oder die Verschlüsselung des 
HDD Herstellers unter Berücksichtigung von [1]. Mit Veracrypt habe ich 
soweit keine Erfahrung.

Dazu noch einmal der Hinweis von oben: Es ist deutlich einfacher die 
Platte einmal zu verschlüsseln und beim Boot aufzusperren als zwischen 
Daten- und Programmpartitionen zu unterscheiden. Des Weiteren sehe ich 
auch keinen Vorteil darin Teile nicht zu verschlüsseln. Performance ist 
bei modernen Verschlüsselungsverfahren kein nennenswertes Problem mehr 
und auch ehr bei den (ohnehin verschlüsselten) Datenbereichen relevant.



[1] https://www.ru.nl/publish/pages/909282/draft-paper.pdf

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JJ schrieb:
> Nano schrieb:
>>> Auf gar keinen Fall.
>>
>> Doch, es ist abhängig vom Fall.
>> ...
>
> Das stimmt so leider nicht.
>
> Die Gefahr das jemand Programme austauscht ist absolut nicht abstrakt
> sondern sehr real und dazu noch sehr einfach umzusetzen. Der Angreifer
> muss lediglich irgendeinen Dienst der üblicherweise im Hintergrund
> ausgeführt wird durch ein Script austauschen welches nach deinem
> nächsten boot die Inhalte der Home Partition im Hintergrund sonstwohin
> streamt.

Der Angreifer kann auch die komplette verschlüsselte Partition 
austauschen und durch ein neues System ersetzen, was dasselbe tut. Wo 
ist der Punkt?

Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven B. schrieb:
> Der Angreifer kann auch die komplette verschlüsselte Partition
> austauschen und durch ein neues System ersetzen, was dasselbe tut.

Nein, kann er nicht. Nicht ohne daß es auffällt, weil er ja eine andere 
Passphrase benutzen muß. Wenn er meine Passphrase (oder Keyfile) hätte, 
dann bräuchte er diesen Umweg gar nicht erst zu gehen.

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
> Sven B. schrieb:
>> Der Angreifer kann auch die komplette verschlüsselte Partition
>> austauschen und durch ein neues System ersetzen, was dasselbe tut.
>
> Nein, kann er nicht. Nicht ohne daß es auffällt, weil er ja eine andere
> Passphrase benutzen muß. Wenn er meine Passphrase (oder Keyfile) hätte,
> dann bräuchte er diesen Umweg gar nicht erst zu gehen.

Öh, ich kann einfach ein System ersetzen, was jede Passphrase 
akzeptiert. Oder einmal "falsches Passwort" sagt, sich die Eingabe merkt 
und ab dann immer genau das akzeptiert. Jeder Benutzer wird denken er 
habe sich vertippt ...

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JJ schrieb:
> Nano schrieb:
>>> Auf gar keinen Fall.
>>
>> Doch, es ist abhängig vom Fall.
>> ...
>
> Das stimmt so leider nicht.
>
> Die Gefahr das jemand Programme austauscht ist absolut nicht abstrakt
> sondern sehr real und dazu noch sehr einfach umzusetzen.

Die Fallbetrachtung ist das, wogegen du dich absichern möchtest.

Ich bestreite ja nicht, dass jemand Programme austauschen könnte, 
sondern ich sage dir nur, dass du vielleicht nur, wie ich bereits oben 
bereits erwähnt habe, deine Daten nur gegen Diebstahl und im Falle eines 
Datenträgeraustausches beim Hersteller schützen möchtest.

In beiden Fällen hast du Fälle, in denen das Verschlüsseln von /usr 
NICHT notwendig ist.

Es ist also abhängig vom Fall, genau wie ich sagte.
Aber das hatte ich alles schon oben geschrieben, du scheint es nur nicht 
verstanden zu haben.



> Meine Empfehlung ist also eine Full-Disk Encryption über alles entweder
> mit der nativen Linux Lösung (LUKS und Co.) oder die Verschlüsselung des
> HDD Herstellers unter Berücksichtigung von [1]. Mit Veracrypt habe ich
> soweit keine Erfahrung.

Du hast einen anderen Fall und der erfordert andere Maßnahmen.
Es spielt immer eine Rolle wogegen man sich absichern möchte.

Ich verschlüssele der Einfachheit halber zwar alles außer /boot.
Würde es leistungsmäßig aber einen nennenswerten Unterschied machen ob 
/usr verschlüsselt ist oder nicht und hätte ich dort Programme 
installiert, die von schnelleren Ladezeiten durch eine fehlende 
Verschlüsselung profitieren würden, dann hätte ich aber damit kein 
Problem /usr nicht zu verschlüsseln, denn ich will meine Daten nur gegen 
Diebstahl und einen möglichen Hardwareaustausch absichern.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ergänzung:

Und oben habe ich ja geschrieben, was man mindestens Verschlüsseln muss, 
wenn der Fall aus Diebstahlschutz und Hardwaretausch besteht.
Diese Aussage ist somit für die beiden Fälle vollkommen richtig.

Autor: JJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Ich bestreite ja nicht, dass jemand Programme austauschen könnte,
> sondern ich sage dir nur, dass du vielleicht nur, wie ich bereits oben
> bereits erwähnt habe, deine Daten nur gegen Diebstahl und im Falle eines
> Datenträgeraustausches beim Hersteller schützen möchtest.
>
> In beiden Fällen hast du Fälle, in denen das Verschlüsseln von /usr
> NICHT notwendig ist.
>
> Es ist also abhängig vom Fall, genau wie ich sagte.
> Aber das hatte ich alles schon oben geschrieben, du scheint es nur nicht
> verstanden zu haben.

Es gibt hier tatsächlich etwas, was ich nicht verstehe:
Wieso sollte ich meine Daten nur für Fall des endgültigen 
Abhandenkommens des Datenträgers schützen und für den Fall 
Kompromitierung eine Flanke bewusst offen lassen?

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JJ schrieb:
> Nano schrieb:
>> Ich bestreite ja nicht, dass jemand Programme austauschen könnte,
>> sondern ich sage dir nur, dass du vielleicht nur, wie ich bereits oben
>> bereits erwähnt habe, deine Daten nur gegen Diebstahl und im Falle eines
>> Datenträgeraustausches beim Hersteller schützen möchtest.
>>
>> In beiden Fällen hast du Fälle, in denen das Verschlüsseln von /usr
>> NICHT notwendig ist.
>>
>> Es ist also abhängig vom Fall, genau wie ich sagte.
>> Aber das hatte ich alles schon oben geschrieben, du scheint es nur nicht
>> verstanden zu haben.
>
> Es gibt hier tatsächlich etwas, was ich nicht verstehe:
> Wieso sollte ich meine Daten nur für Fall des endgültigen
> Abhandenkommens des Datenträgers schützen und für den Fall
> Kompromitierung eine Flanke bewusst offen lassen?

Ich werfe mal das Stichwort unterschiedlicher Paranoialevel in den Raum.

Wie wahrscheinlich hältst du es denn, dass bei dir jemand ins Haus 
einbricht und anstatt die Datenträger zu klauen, stattdessen dir 
Schadsoftware unterschiebt?

Klar, wenn du Terrorist sein solltest, für einen ausländischen 
Geheimdienst arbeitest, eventuell Paparzzis befürchtest, weil du 
irgendein Star bist, mit Waffen oder Drogen dealst und die Polizei auf 
dich aufmerksam werden könnte, ja, dann wäre auch mit einer 
Kompromittierung des Rechners auf diese Weise zu rechnen.

Aber als typischer 08/15 User ist das ein Szenario, das so einen eher 
nicht betreffen wird.

Autor: Laptop mit L (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JJ schrieb:


> HDD Herstellers unter Berücksichtigung von [1]. Mit Veracrypt habe ic

>
> [1] https://www.ru.nl/publish/pages/909282/draft-paper.pdf


 Das PDF habe ich jetzt nicht gelesen aber im wesentlichen wird dort 
wohl drin stehen das Gerät besser auszuschalten.
Wenn einem das im Betrieb oder im Standby aus den Händen genommen wird 
hilft ein sed selfencrypting device auch nicht weiter.
Vlt. wird das für Spezis die sich damit beschäftigen Knackbar sein 
bietet aber den Vorteil das man sich nicht versehentlich selbst für 
seine Datenverlust an die Nases fassen muss.

Reine Nutzdaten oder alles aber dann in Hardware.
Alles andere ist doch unnötige Zeitverschwendung.

https://www.pcworld.com/article/3004670/business-security/self-encrypting-drives-are-hardly-any-better-than-software-based-encryption.html


Ansonsten eben wie gehabt system sauber halten.


---
Dazu gehört aber auch das man nicht in und mit Daten des /tmp Verz. 
arbeitet. Dessen Zweck ist Platz für temporäre Daten von Anwendungen 
bereitzustellen und wenn diese es nicht schaffen hinter sich aufzuräumen 
macht man das beim shutdown platt. Dinge die einen reboot überstehen 
sollen gehören nach /var/tmp aber auch nur wenn sie nichts wert sind und 
mit anderen Nutzern geteilt werden sollen ansonsten geht das ins 
Heimatsverzeichnis und das kann sich ja physikalisch an jeder beliebigen 
Stelle befinden z.B. auf einem stick oder auch auf dem Server zuhause. 
Jdf. wenn man das sauber handhaben will.

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html

Autor: Torsten C. (torsten_c) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Wie wahrscheinlich hältst du es denn, dass bei dir jemand ins Haus
> einbricht und anstatt die Datenträger zu klauen, stattdessen dir
> Schadsoftware unterschiebt?

Einem Bekannten von einem Bekannten ist folgendes passiert: Aufgrund von 
fadenscheinigen Ermittlungsmethoden wurde eine Hausdurchsuchung gemacht. 
Ein "Experte" hat dann KiPos entdeckt, die wohl plötzlich irgendwie auf 
der Festplatte waren. Ein Gegenbeweis war nicht möglich und das Gesicht 
der "Exekutive" (Polizei) war gewahrt.

KiPos = sonropredniK rückwärts.

: Bearbeitet durch User
Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> Nano schrieb:
>> Wie wahrscheinlich hältst du es denn, dass bei dir jemand ins Haus
>> einbricht und anstatt die Datenträger zu klauen, stattdessen dir
>> Schadsoftware unterschiebt?
>
> Einem Bekannten von einem Bekannten ist folgendes passiert: Aufgrund von
> fadenscheinigen Ermittlungsmethoden wurde eine Hausdurchsuchung gemacht.
> Ein "Experte" hat dann KiPos entdeckt, die wohl plötzlich irgendwie auf
> der Festplatte waren. Ein Gegenbeweis war nicht möglich und das Gesicht
> der "Exekutive" (Polizei) war gewahrt.
>

Das halte ich für ein Gerücht.
Außerdem geht das auch mit Verschlüsselung.

Festplatte löschen, System neu installieren, Kipos drauf und behaupten, 
das wäre deine System wie es die Polizei vorgefunden hat.
Führe mal hier einen Gegenbeweis.

Wenn er dir gelingen sollte, dann gelingt dir das auch im anderen Fall.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Außerdem als Gegenbeweis hätte man in diesem fiktiven Fall auch anführen 
können, dass die Kipos ja in /usr deponiert wurden und nicht im 
verschlüsselten /home, wo man es erwarten würde.
Und da es nach FHS üblich ist, dass auf /usr nur Programme und keine 
Daten kommen und der gewöhnliche Nutzer auf /usr auch keine 
Schreibrechte hat und Firefox & Co erstmal alles in ~/Download ablegen 
will, wäre das auch durchaus glaubhaft bzw. recht ungewöhnlich, wenn das 
jemand tatsächlich nach /usr packen würde.
Vor allem wenn er /home verschlüsselt hat.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> wäre das auch durchaus glaubhaft bzw. recht ungewöhnlich,

Sry, habe hier ein Wort vergessen.
Ich meinte:
wäre das auch durchaus wenig glaubhaft bzw. recht ungewöhnlich,

Autor: michael_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Larry schrieb:
> Guten Abend,
>
> ich richte mir gerade einen Arbeits-Laptop ein

Erklär erst mal, ist das einer in einer Firma oder für dich privat.
Privat ist aber keine Arbeit.

Autor: Widerstand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus schrieb:
> Was ich ganz witzig finde:
> https://github.com/stupidpupil/https-keyscript
>
> Beim Hochfahren kontaktiert Dein Server eine von Dir vorgegebene URL und
> lädt  eine dort vorhandene verschlüsselte Datei herunter, die den Key
> zum Entschlüsseln des Systems enthält.
>
> Vorteil: Das Passwort muß nicht mit jedem Systemstart eingegeben werden.
> Wenn Dein Rechner gestohlen wird, löscht Du die Key-Datei auf dem
> externen Server und die Daten auf Deinem Rechner sind für alle Welt
> nutzlos.

Interessant. Gibts das auch mit Bluetooth o.ä.?
Dann würde ich das beim stationären Rechner unter die Tischplatte kleben 
bzw. für den Laptop unterwegs in den Schuhabsatz.

Da eine Verschlüsselung nur so gut ist wie das Paßwort, halte ich einen 
technischen Trick für unumgänglich, um ein uneintippbar langes Paßwort 
verfügbar zu machen.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JJ schrieb:
> Ich gehe nicht davon aus, dass der OP ein Notebook
> das für eine gewisse Zeit abkömmlich wird grundsätzlich als
> kompromittiert ansehen möchte.

Du meinst, wenn dein Rechner entwendet wurde und dann plötzlich auf 
magische Weise wieder auftaucht, gehst du davon aus, dass alles ok ist?

> Einen Hardware Keylogger oder andere Hardware "Lösungen" sehe ich da
> schon ehr im Bereich der Geheimdienste da hier allein die Beschaffung
> (vermutlich) schon nicht so einfach ist.

lol... der war gut.
https://www.google.com/search?q=keylogger&tbm=shop

Autor: JJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Du meinst, wenn dein Rechner entwendet wurde und dann plötzlich auf
> magische Weise wieder auftaucht, gehst du davon aus, dass alles ok ist?

Es geht ehr darum, jemand anderes mal für eine halbe Stunde Zugriff hat 
und ich es nicht bemerke

>> Einen Hardware Keylogger oder andere Hardware "Lösungen" sehe ich da
>> schon ehr im Bereich der Geheimdienste da hier allein die Beschaffung
>> (vermutlich) schon nicht so einfach ist.
>
> lol... der war gut.
> https://www.google.com/search?q=keylogger&tbm=shop

USB Zwischenstecker sind jetzt nicht die Art von unauffälliger 
Überwachung um die es hier ging.

Autor: JJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Laptop mit L schrieb:
> Das PDF habe ich jetzt nicht gelesen aber im wesentlichen wird dort
> wohl drin stehen das Gerät besser auszuschalten.
> Wenn einem das im Betrieb oder im Standby aus den Händen genommen wird
> hilft ein sed selfencrypting device auch nicht weiter.

Da steht drin, dass die Verschlüsselung von SEDs letztlich auch nur in 
Software auf dem Controller abgebildet ist, die Implementierung derer 
gar nicht so einfach ist und zumindest in einigen Fällen der Hersteller 
großen Mist gebaut hat und die Verschlüsselung in den Fällen nutzlos 
ist.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.