Archiv verlassen und diese Seite im Standarddesign anzeigen : Vollverschlüsselung
Magnificent
10.09.13, 12:39
Hi,
Windows-PCs kann man mit TrueCrypt komplett verschlüsseln. Unter Linux geht das IMHO nicht. Da ich gerade den Umstieg auf Ubuntu 12.04.3 überlege, würde ich gerne wissen, wie ich unter Linux die komplette Festplatte (nicht nur das Datenverzeichnis) verschlüsseln kann. :confused:
Da ich hier Anfänger bin, wäre ich für eine idiotensicher Anleitung sehr dankbar. :D
DANKE!
http://wiki.ubuntuusers.de/System_verschl%C3%BCsseln
Die von marce verlinkte Anleitung ist hervorragend, das nur als Anmerkung. Ich hatte mein Ubuntu-System nach dieser Anleitung verschlüsselt, klappte problemlos.
Bei der Gelegenheit: (Verschlüsselte) Backups sind natürlich absolute Pflicht für den Fall eines Festplattencrashs, aber ich denke das dürfte bekannt sein. :)
-hanky-
nunja, Magnificent, darf man wissen was der Sinn oder Zweck dieser Übung sein soll?
Das schützt in Deutschland gegen solche Angriffe: http://www.spiegel.de/spiegel/a-748110.html
In den USA oder GB übrigens nicht, dort dürfen sie dich so lange einlochen bis du jegliche Passwörter rausrückst.
Das schützt in Deutschland gegen solche Angriffe: http://www.spiegel.de/spiegel/a-748110.html
In den USA oder GB übrigens nicht, dort dürfen sie dich so lange einlochen bis du jegliche Passwörter rausrückst.
Gegen das von dir beschriebene Szenario hilft die Vollverschlüsselung leider nicht. Auch bei einer Vollverschlüsselung hat man nach wie vor eine unverschlüsselte Boot-Partition, von der aus dann das Betriebssystem geladen wird. Die Entschlüsselung / Passworteingabe findet dann über die Programme in der Init-Ramdisk statt. Ein Angreifer müsste also lediglich die Initramdisk manipulieren. Dann kann er wahlweise das Passwort mitschneiden oder einen Dropper hinterlegen der nach dem Bootvorgang den Trojaner nachlädt.
Klar, das ist im Zweifel ziemlich aufwendig, aber machbar. Man sollte und darf sich mit einer Vollverschlüsselung also nicht in falscher Sicherheit wiegen.
Eine Vollverschlüsselung macht natürlich trotzdem Sinn - man erhöht den Aufwand für den Angreifer und auf dem Laptop eingesetzt verhindert man dass, sollte dieser gestohlen werden oder verloren gehen, persönliche Daten in falsche Hände gelangen. Die liegen ja nicht nur im Home-Verzeichnis, auch /etc ist da durchaus eine Fundgrube.
-hanky-
P.S.: Die Problematik existiert natürlich auch unter Windows. In dem Fall ist es der Truecrypt-Bootloader. Irgendwo hast du immer einen Einstiegspunkt für Manipulationen (und wenn es die Holzhammermethode mit dem Hardwarekeylogger ist).
Naja, man kann das schon noch in den "Excess" treiben - z.B. über http://www.kroah.com/log/blog/2013/09/02/booting-a-self-signed-linux-kernel/, dann noch Boot nur von USB oder CD-Rom, Passphrase über USB-Stick oder amderes, ... - dann wäre auf dem System selbst nichts mehr, was nicht verschlüsselt wäre...
Naja, man kann das schon noch in den "Excess" treiben - z.B. über http://www.kroah.com/log/blog/2013/09/02/booting-a-self-signed-linux-kernel/, dann noch Boot nur von USB oder CD-Rom, Passphrase über USB-Stick oder amderes, ... - dann wäre auf dem System selbst nichts mehr, was nicht verschlüsselt wäre...
Hi,
danke für den Link, sehr interessant. Momentan schrecke ich vor dieser Herangehensweise noch zurück, einfach weil es ein immenser Aufwand ist. Aber wer weiß was die Zukunft bringt!
Ansonsten hast du natürlich Recht, ein Boot von USB-Stick oder CD-ROM wäre eine Lösung um eine Manipulation zu verhindern. Alternativ haben viele Laptops ja mittlerweile einen SD-Karten-Slot - den könnte man sicherlich zweckentfremden. Mein Problem damit ist aber: Ich kenne mich und ich weiß jetzt schon dass mich das nerven wird. Spätestens wenn ich unterwegs bin und $DATENTRÄGER daheim vergessen habe (oder ihn verliere) wird mich der Aufwand nerven ein neues Bootmedium zu erstellen.
Ich hatte mir einen anderen, mehr pragmatischen Ansatz überlegt: Man ändert die distributionsspezifischen Skripte zur Installation der Initramdisk so ab, dass zum Abschluss z.B. eine SHA1-Prüfsumme erstellt wird. Diese Prüfsumme wird auf der verschlüsselten Partition hinterlegt. Bei jedem Bootvorgang, nach dem Entschlüsseln der Festplatte, wird eine Prüfsumme der Initramdisk von der gebootet wurde gebildet und mit der Prüfsumme auf der Festplatte verglichen. Das Skript, welches die Aufgabe übernimmt, befindet sich auf der verschlüsselten Partition und ist daher gegen eine Manipulation durch ein Ersetzen der Initramdisk geschützt.
Wenn nun festgestellt wird, dass die Prüfsummen nicht übereinstimmen, weiß man dass die Initramdisk manipuliert wurde. Dann muss man natürlich handeln und die Passwörter der verschlüsselten Partitionen ändern (ist mit LUKS ja relativ problemlos möglich). Je nachdem wer für die Manipulation zuständig ist sollte man jetzt vielleicht auch darüber nachdenken für einige Zeit zu verreisen, ggf. an einen fernen Ort. :ugly:
Der Ansatz ist natürlich nicht perfekt, mir fällt da spontan direkt ein dass ein Angreifer ja versuchen könnte mit einer manipulierten Initramdisk den Start des Skripts auf der Festplatte zu unterbinden. Dafür muss er allerdings von der Existenz des Skripts wissen.
Ist wie gesagt auch nur ein Gedankenexperiment. Mal schauen, wenn ich etwas mehr Zeit habe versuche ich das vielleicht mal zum Test umzusetzen.
Für mich persönlich ist das auch eher eine abstrakte Gefahr. So paranoid bin ich (noch) nicht dass ich glaube jemand würde sich die Mühe machen auf diese Art und Weise an meine Daten zu kommen. Aber wenn es einen halbwegs komfortablen Ansatz geben sollte um diese Gefahr auszuschließen oder wenigstens zu minimieren, warum nicht?
-hanky-
Das Prüfsummenskript kommt auf eine Live Boot CD. Vorteil: keine forensische Analyse des zu schützenden Systems findet je heraus dass es so eine Prüfsumme gibt...
Aber ich glaube dass zur Zeit das Problem eher ist "sichere " Passwörter zu wählen die nicht mit den gängigen Methoden "brute forced" werden können und die man sich trotzdem merken kann. In der C't Security steht dazu einiges.
Hi,
Das Prüfsummenskript kommt auf eine Live Boot CD. Vorteil: keine forensische Analyse des zu schützenden Systems findet je heraus dass es so eine Prüfsumme gibt...
Dann habe ich aber das gleiche Problem wie bei einem Booten von CD: Bei Verlust/Zerstörung des Datenträgers habe ich den Aufwand einen neuen erstellen zu müssen. Ganz zu schweigen davon dass ich jedes Mal eine CD (oder einen anderen Datenträger) extra mitführen muss.
Bei der von mir vorgeschlagenen Variante findest du auch nicht heraus, dass es eine Prüfsumme gibt, denn die liegt ja auf dem verschlüsselten System. Der Angreifer müsste also im Vorfeld wissen dass eine Prüfsumme existiert. Dann müsste er ein Image erstellen mit der gleichen Prüfsumme (was zumindest bei SHA1 nicht so einfach möglich sein dürfte) oder aber das Ausführen des Skripts verhindern (was man relativ leicht erkennen kann) oder durch ein eigenes ersetzen, welches das alte 1:1 zu simuliert. Wie gesagt, alles in der Theorie denkbar, aber die Hürde ist doch schon relativ hoch.
Aber ich glaube dass zur Zeit das Problem eher ist "sichere " Passwörter zu wählen die nicht mit den gängigen Methoden "brute forced" werden können und die man sich trotzdem merken kann. In der C't Security steht dazu einiges.
Ich kenne die aktuelle Ausgabe der c't Security nicht, aber mein Passwort hat > 20 Stellen und ist eine wirre Abfolge von Zeichen/Ziffern ohne erkennbares Muster (ich musste es in der Tat auch zunächst einmal auswendig lernen). Viel Spaß beim Bruteforcen wünsche ich. :ugly:
-hanky-
P.S.: Die generelle Problematik bei solchen Geschichten ist das altbekannte Dilemma Sicherheit vs Komfort. Aus dem Grund wird ja leider auch bei Mails so wenig verschlüsselt. Der 08/15-Anwender ist wenn überhaupt nur dazu bereit minimale Abstriche beim Komfort hinzunehmen. Deswegen sind auch die ganzen gutgemeinten Aktionen/Tipps der c't, z.B. c't Bankix, letztendlich für die Katz. In der Theorie spitze, in der Praxis dürfte die Anzahl derjenigen die jedes Mal fürs Online-Banking einen Neustart durchführen gegen Null gehen. Und das ist irgendwo auch verständlich. Leider.
Ich würde Bankix nur im Notfall nutzen (Notfall: habe nur einen Rechner zur Verfügung der wahrscheinlcih infiziert ist, kann diesen aus irgendwelchen Gründen nicht bereinigen und kann meine Bankgeschäfte nicht aufschieben).
Meine Lösung: HBCI Programm unter Linux. Ist zur Zeit mehr als ausreichend sicher, da selbst unter Windows die Trojaner nock keine HBCI Programme angreifen.
Für sichere Kommunikation und wie man verhindert dass das eigene Telefon zu viel ausplaudert: das ist schon viel schwieriger.
Das mit dem Hash ist schon mal ein Anfang.. ich sehe aber folgendes Problem:
Wenn jemand an deinem /boot bereits rumgefummelt hat, hatte er wahrscheinlich auch die Möglichkeit einen Dump deiner Platte zu ziehen.
Nun gibst du nichtsahnend dein PW ein.. Das System startet und im Hintergrund ist bereits das Passwort verschickt worden. Dank des Dumps kann die Platte nun extern entschlüsselt werden
Und was ist, wenn dein /boot nicht angefasst wurde, sondern jemand bereits im BIOS oder im Bootsektor was hinterlegt hat?
Du könntest natürlich noch ne Checksumme über das BIOS/den Bootsektor machen.. aber das Passwort ist dann evtl. bereits bekannt.
Also sollten die wichtigen Daten dann nochmal extra Verschluesselt sein und nicht direkt zum Dumpen vorhanden sein.
Anschließend wenn das System deine Checks erfolgreich durchgeführt hat, kannst du deine wichtigen Daten von einer externen Quelle per Hand mounten und entschlüsseln.
Evtl. interessant:
Hier noch nen älteres Paper zum Anonymisieren eines Linux Systems
http://www.thc.org/papers/anonymous-unix.html
Hi,
Ich würde Bankix nur im Notfall nutzen (Notfall: habe nur einen Rechner zur Verfügung der wahrscheinlcih infiziert ist, kann diesen aus irgendwelchen Gründen nicht bereinigen und kann meine Bankgeschäfte nicht aufschieben).
Meine Lösung: HBCI Programm unter Linux. Ist zur Zeit mehr als ausreichend sicher, da selbst unter Windows die Trojaner nock keine HBCI Programme angreifen.
In dem Fall müsste man sich halt ein Linux installieren. Für dich und mich ist das kein Problem, da wir beide sowieso Linux nutzen, aber ein einfacher Anwender der nur Windows gewohnt ist wird das wohl nicht tun.
Ich hatte eine Zeitlang mit dem Gedanken gespielt, das sich so etwas doch durch Xen in Verbindung mit VGA-Passthrough lösen lassen müsste. Als Basis ein Lightweight-Linux mit dem Xen-Kernel und als Gäste dann einmal Windows und einmal ein sicheres Linux-System. Der Nutzer müsste dann über ein Menü zwischen den Systemen wechseln können. Setzt man voraus dass das Xen-Hostsystem sicher ist sollte man so die beiden Systeme sauber trennen können ohne großen Komfortverlust für den Nutzer.
Ich habe das jedoch bislang nicht weiter verfolgt, mir fehlt leider auch hierzu schlicht die Zeit.
Für sichere Kommunikation und wie man verhindert dass das eigene Telefon zu viel ausplaudert: das ist schon viel schwieriger.
Klar, ist ja aber auch eine andere Baustelle. ;)
Das mit dem Hash ist schon mal ein Anfang.. ich sehe aber folgendes Problem:
Wenn jemand an deinem /boot bereits rumgefummelt hat, hatte er wahrscheinlich auch die Möglichkeit einen Dump deiner Platte zu ziehen.
Nun gibst du nichtsahnend dein PW ein.. Das System startet und im Hintergrund ist bereits das Passwort verschickt worden. Dank des Dumps kann die Platte nun extern entschlüsselt werden
Das ist ein sehr guter Einwand, an dieses Szenario hatte ich so noch nicht gedacht. Ich sehe da spontan als Abhilfe ebenfalls nur die Möglichkeit, die Skripte auszulagern auf eine mit einem anderen Passwort verschlüsselte Partition. Erst wenn die Skripte erfolgreich durchlaufen wurden kommt die Abfrage zur Passworteingabe für das eigentliche System.
Und was ist, wenn dein /boot nicht angefasst wurde, sondern jemand bereits im BIOS oder im Bootsektor was hinterlegt hat?
Du könntest natürlich noch ne Checksumme über das BIOS/den Bootsektor machen.. aber das Passwort ist dann evtl. bereits bekannt.
Also sollten die wichtigen Daten dann nochmal extra Verschluesselt sein und nicht direkt zum Dumpen vorhanden sein.
Anschließend wenn das System deine Checks erfolgreich durchgeführt hat, kannst du deine wichtigen Daten von einer externen Quelle per Hand mounten und entschlüsseln.
Evtl. interessant:
Hier noch nen älteres Paper zum Anonymisieren eines Linux Systems
http://www.thc.org/papers/anonymous-unix.html
Ich muss gestehen, in Sachen MBR/BIOS bzw. bei neueren Systemen wie UEFI bin ich nicht auf dem Laufenden was die Möglichkeiten angeht hier zu manipulieren. Wobei man Manipulationen ja entdecken müsste wenn man eine Prüfsumme nutzt (analog zur Initrd). In jedem Fall aber eine interessante Diskussion. :)
Ich hoffe der Threadersteller vergibt mir das Hijacken des Threads... :ugly:
-hanky-
Beziehungsweise er weiß jetzt warum man nur mit komplett und richtig "leerem" Laptop in Länder wie GB, USA oder China reisen sollte....
nunja, ich finde die Vorschläge und Lösungsansätze hier sehr interessant. Allerdings sind diese wahrscheinlich für die Eingangsfrage eher Theorie da Magnificent die Frage in #4 nicht beantwortet hat.
@Newbie314
Deine Annahme in #14 mag richtig sein, nur erkläre das einmal den Geschäftsleuten die diese Länder besuchen ;)
Abgesehen davon das diese wohl hauptsächlich mit unverschlüsselten Rechnern reisen.
@marce
Der Inhalt des in Deiner Nachricht #7 gesetzten Verweises geht wohl am Thema vorbei da es hier um UEFI und das Starten eines selbst erstellten Linuxkernes geht.
@-hanky-
Teile Deiner Lösungsansätze klingen interessant. Allerdings setze ich diese schon seit Redhat 9 um und seit Fedora 2 auch mit USB Steckern.
Falls Du zu Studienzwecken an solchen Modifikationen interessiert sein solltest bitte PM an mich.
Diese Anpassungen werden auf Geschäftsrechnern von Betrieben eingesetzt um bei Diebstahl deren Inhalt zu schützen.
Vorbei? Nicht direkt... Es geht ja auch um das starten eines "signierten" OS.
Ich habe ja auch nicht behauptet, daß es das Allheilmittel ist, aber es ist ein Weg, den man auch (mit) gehen kann.
Das Lubuntu ist eine Debian-basierte Distribution, die noch eine aktuelle Alternate-CD anbietet und die bietet auch die bewährte Installation im Experten-Modus, mit der man das System komplett verschlüsselt installieren kann. Ich habe das erst letzten Monat wieder gemacht, neben einem Windows8.
Das in dem Ubuntu-Wiki beschriebene Rumpartitionieren, Editieren von etlichen Dateien usw. ist damit überflüssig.
Man muss nur darauf achten eine unverschlüsselte Boot-Partiton zu verwenden und auch Swap zu verschlüsseln. Die Installation dauert kaum länger als die von einem unverschlüsselten System.
Und hier gibt es ein paar andere Tipps zum Encrypted Root Filesystem:
http://true-random.com/homepage/projects/liberal/erfh.html
Hi,
[...]
@-hanky-
Teile Deiner Lösungsansätze klingen interessant. Allerdings setze ich diese schon seit Redhat 9 um und seit Fedora 2 auch mit USB Steckern.
Falls Du zu Studienzwecken an solchen Modifikationen interessiert sein solltest bitte PM an mich.
Diese Anpassungen werden auf Geschäftsrechnern von Betrieben eingesetzt um bei Diebstahl deren Inhalt zu schützen.
hört sich sehr interessant an. Ich habe momentan aufgrund diverser anderweitiger Verpflichtungen wenig bis keine Zeit mich mit dem Thema zu beschäftigen, auf dein Angebot komme ich aber, wenn das ok ist, bei Gelegenheit sehr gerne zurück. :)
Das Lubuntu ist eine Debian-basierte Distribution, die noch eine aktuelle Alternate-CD anbietet und die bietet auch die bewährte Installation im Experten-Modus, mit der man das System komplett verschlüsselt installieren kann. Ich habe das erst letzten Monat wieder gemacht, neben einem Windows8.
Das in dem Ubuntu-Wiki beschriebene Rumpartitionieren, Editieren von etlichen Dateien usw. ist damit überflüssig.
Man muss nur darauf achten eine unverschlüsselte Boot-Partiton zu verwenden und auch Swap zu verschlüsseln. Die Installation dauert kaum länger als die von einem unverschlüsselten System.
Und hier gibt es ein paar andere Tipps zum Encrypted Root Filesystem:
http://true-random.com/homepage/projects/liberal/erfh.html
Kann man bei der Alternate-CD mittlerweile angeben welchen Algorithmus man nutzen möchte? Das ging meines Wissens eine ganze Zeitlang nicht, weshalb ich die Platten damals manuell verschlüsselt habe.
-hanky-
Kann man bei der Alternate-CD mittlerweile angeben welchen Algorithmus man nutzen möchte?
Ja, aber der Container ist seit Jahren nur noch LUKS, also mit einem leicht identifizierbaren Header.
Allerdings kann man den vor einer Reise ja rausnehmen und z. B. in eine ZIP-Datei packen.
Für sichere Kommunikation und wie man verhindert dass das eigene Telefon zu viel ausplaudert: das ist schon viel schwieriger.
Just for information: Es werden sogenannte Kryptophones angeboten, basierend auf Samsung-Modellen. Sind vollverschlüsselt, verweigern Whatsapp & Co und können sogar verschlüsselt telefonieren und SMS verschicken, allerdings braucht die Gegenstelle dann auch ein Kryptophone. Kostenpunkt sind schlappe 2.000€, wobei es da inzwischen einen ganz schönen Preisverfall gibt. Aber der Funktionsumfang ist halt auch entsprechend geringer.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.