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
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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/Securityhttps://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/
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.
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
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?
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.
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 ...
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.
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.
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?
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.
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
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.
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.
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.
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,
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.
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.
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
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.
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.
Das ist wieder mal typisch
keiner antwortet den OP auf seine Frage - nur viel BlaBla das man aus
sehr schlechten Agentenfilmchen kennt(Mission impossible)
Ja das VerarCrypt bietet nicht direkt an die GANZE Platte zu
verschlüsseln unter Linux. Unter Windows schon.
Es gibt einen Trick wenn man DUALBoot hat.
Der Grub darf dann nicht im MBR sein sondern muss auf die Partition.
Z.B. auf /dev/sda5 statt auf /dev/sda.
Veracrypt installiert seinen eigenen Bootloader im MBR und kann dann
andere BootLoader (auch den von Windows) nachladen und als Startoption
anbieten.
Ist aber ein Prozedere von mehreren Schritten bei dem die Reihenfolge
genau passen muss.
Ja man kann ein Dualbootsystem mit Windows und Linux erhalten welches
gleich beim MBR-Start das PW / Stick abfrägt, ist aber aufgrund des
Aufwandes nur etwas für Profis. Eine einfache "Schritt für Schritt"
Anleitung die brauchbar ist habe ich bisher noch nicht gefunden.
Linuxonly kann man dann machen wenn man nach dem Ganzen das Windows
(also dessen Partition) wieder löscht und den freien Platz wieder für
Linux verwendet dazu braucht man aber wiederum ein Notsystem(Gparted)
mit vorheriger Öffnung der Festplatte durch den VeraCrypt-MBR
Gruß
Andreas schrieb:> Das ist wieder mal typisch> keiner antwortet den OP auf seine Frage - nur viel BlaBla das man aus> sehr schlechten Agentenfilmchen kennt(Mission impossible)
Das ist ja mal wieder typisch, da kommt einer und motzt.
Allerdings viele Monate zu spaet.
wendelsberg
