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/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/
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.
:
Bearbeitet durch User
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.