bsdagent
Auch im #bsdforen.de Chat
Hi
Ohne geli_swap_flags in /etc/rc.conf, wird per default AES 128-Bit verwendet
.
Gruss
bsdagent
Ohne geli_swap_flags in /etc/rc.conf, wird per default AES 128-Bit verwendet
.Gruss
bsdagent
Verschlüsselt Ihr Eure Festplatte?
- Ersteller bsdagent
- Erstellt am
Ohne geli_swap_flags in /etc/rc.conf, wird per default AES 128-Bit verwendet
Ist das schlimm?
Ich weiß. Leider nicht bei den Anderen.
Endorphine
Well-Known Member
Äh ja, und genau das ist auch sinnvoll bei den Optionen, die geli momentan anbietet. Alles andere ist ziemlicher Humbug und im besten Fall eine künstliche Bremse.Ohne geli_swap_flags in /etc/rc.conf, wird per default AES 128-Bit verwendet
Sinnvoller wäre mal ein Audit der Implementierung von geli und der Umstieg von CBC auf XTS oder wenigstens LRW. AES-128 mit generiertem Einmalschlüssel (der diesen Key auch ausnutzt) ist schon mehr als ausreichend.
Vincent Vega
phisch
Re: Verschlüsseln der Swap Partitionen
Ich behaupte, dass es unnötig ist, den Swap-Bereich zu verschlüsseln.
Um an Swap heran zu kommen, muss man entweder a) physischen Zugang zu einem Rechner haben oder b) root sein. In letzterem Fall ist eh alles zu spät.
Hat man physischen Zugriff auf einen Rechner, so kann man ihn leicht kontrollieren - das wird ja immer so behauptet. Behaupte ich auch, denn: Es ist trivial einfach, einen Rechner neu zu starten und in den Single-User Modus zu booten. Ebenso einfach ist es, eine Festplatte in einen anderen Rechner einzubauen und sie dort auszulesen.
Naja, hier sollte ja eigentlich die Festplatten-Verschlüsselung greifen: Wenn der Rechner neu gestartet wird, ist der RAM gelöscht, damit sind die Schlüssel erstmal weg und müssen neu eingegeben werden. Allerdings stimmt das nur bedingt: DRAM Zellen haben die Eigenschaft ihren Wert einige Zeit (im Sekunden-Bereich) halten zu können, auch ohne anliegende Clock. Die Zeit lässt sich vergrößern (auf den Bereich von Minuten), wenn die Zelle gekühlt wird. Das bedeutet: Wer physisch an den Speicher kommt, kann den Riegel ausbauen und einfach in einem anderen Rechner auslesen. Forscher an der Uni Princeton haben gezeigt, dass dies nicht nur Theorie ist: http://citp.princeton.edu/memory/
Das bedeutet, das Verschlüsseln von Festplatten ist nur dann sicher, wenn der Rechner einige Zeit ausgeschalten war, bevor der Angreifer darauf zugreifen kann. Ein Laptop, der ausgeschalten war als er geklaut wurde, dürfte daher sicher sein. Ein Server, der im Betrieb abgegriffen werden kann ist mit Sicherheit anfällig für die o.g. Attacke.
Damit zurück zur verschlüsselten Swap-Partition. Wenn der Rechner im Betrieb abgegriffen wird, dann hilft nichts mehr -- denn der Schlüssel für den Swap-Bereich muss ja auch irgendwo im Hauptspeicher liegen.
Wenn der Rechner abgeschalten ist, dann könnte man ein unverschlüsseltes Swap-Device natürlich sehr einfach auslesen. Allerdings: Was will man da finden? Kernel-Speicher kann nicht ausgelagert werden. Und User-Speicher kann mit mlockall(2) vor dem Auslagern geschützt werden. Ein Programm mit schützenswerten Daten (Schlüssel und Passwörter) sollte dieser meiner Meinung nach eh nur so kurz wie möglich im Speicher halten. Und wenn das nicht geht, dann sollte es sich schützen. Kurz: Ich glaube, verschlüsselter Swap-Speicher hat, wenn überhaupt, nur einen sehr begrenzten nutzen.
Umgekehrt ist es aber so, dass Swap Speicher zum einen sehr langsam ist, und zum andern ist RAM Mangelware wenn Swap erstmal gebraucht wird. Die Ressourcen (Rechenzeit und Speicherverbrauch) für die Verschlüsselung könnten also besser eingesetzt werden.
Meiner Meinung nach sollte man der harten Realität ins Auge sehen: Computer sind nicht sicher. Dafür sind sie nicht gebaut. Das letze Mal, als jemand einen ernstzunehmenden Vorschlag für eine sichere Architektur gemacht hat, wurde der Entwurf gnadenlos niedergemacht, aus Angst vor DRM (eine Anwendung einer sicheren Architektur): Die Rede ist von Microsofts Trusted Computing Projekt (Palladium, Nexus, oder wie das auch hieß).
Ich weiß. Leider nicht bei den Anderen.
Ich behaupte, dass es unnötig ist, den Swap-Bereich zu verschlüsseln.
Um an Swap heran zu kommen, muss man entweder a) physischen Zugang zu einem Rechner haben oder b) root sein. In letzterem Fall ist eh alles zu spät.
Hat man physischen Zugriff auf einen Rechner, so kann man ihn leicht kontrollieren - das wird ja immer so behauptet. Behaupte ich auch, denn: Es ist trivial einfach, einen Rechner neu zu starten und in den Single-User Modus zu booten. Ebenso einfach ist es, eine Festplatte in einen anderen Rechner einzubauen und sie dort auszulesen.
Naja, hier sollte ja eigentlich die Festplatten-Verschlüsselung greifen: Wenn der Rechner neu gestartet wird, ist der RAM gelöscht, damit sind die Schlüssel erstmal weg und müssen neu eingegeben werden. Allerdings stimmt das nur bedingt: DRAM Zellen haben die Eigenschaft ihren Wert einige Zeit (im Sekunden-Bereich) halten zu können, auch ohne anliegende Clock. Die Zeit lässt sich vergrößern (auf den Bereich von Minuten), wenn die Zelle gekühlt wird. Das bedeutet: Wer physisch an den Speicher kommt, kann den Riegel ausbauen und einfach in einem anderen Rechner auslesen. Forscher an der Uni Princeton haben gezeigt, dass dies nicht nur Theorie ist: http://citp.princeton.edu/memory/
Das bedeutet, das Verschlüsseln von Festplatten ist nur dann sicher, wenn der Rechner einige Zeit ausgeschalten war, bevor der Angreifer darauf zugreifen kann. Ein Laptop, der ausgeschalten war als er geklaut wurde, dürfte daher sicher sein. Ein Server, der im Betrieb abgegriffen werden kann ist mit Sicherheit anfällig für die o.g. Attacke.
Damit zurück zur verschlüsselten Swap-Partition. Wenn der Rechner im Betrieb abgegriffen wird, dann hilft nichts mehr -- denn der Schlüssel für den Swap-Bereich muss ja auch irgendwo im Hauptspeicher liegen.
Wenn der Rechner abgeschalten ist, dann könnte man ein unverschlüsseltes Swap-Device natürlich sehr einfach auslesen. Allerdings: Was will man da finden? Kernel-Speicher kann nicht ausgelagert werden. Und User-Speicher kann mit mlockall(2) vor dem Auslagern geschützt werden. Ein Programm mit schützenswerten Daten (Schlüssel und Passwörter) sollte dieser meiner Meinung nach eh nur so kurz wie möglich im Speicher halten. Und wenn das nicht geht, dann sollte es sich schützen. Kurz: Ich glaube, verschlüsselter Swap-Speicher hat, wenn überhaupt, nur einen sehr begrenzten nutzen.
Umgekehrt ist es aber so, dass Swap Speicher zum einen sehr langsam ist, und zum andern ist RAM Mangelware wenn Swap erstmal gebraucht wird. Die Ressourcen (Rechenzeit und Speicherverbrauch) für die Verschlüsselung könnten also besser eingesetzt werden.
Meiner Meinung nach sollte man der harten Realität ins Auge sehen: Computer sind nicht sicher. Dafür sind sie nicht gebaut. Das letze Mal, als jemand einen ernstzunehmenden Vorschlag für eine sichere Architektur gemacht hat, wurde der Entwurf gnadenlos niedergemacht, aus Angst vor DRM (eine Anwendung einer sicheren Architektur): Die Rede ist von Microsofts Trusted Computing Projekt (Palladium, Nexus, oder wie das auch hieß).
FreeBSDuser
Well-Known Member
Ich hab keine Swap Partition.
Ich will auch keine.
Kann der Ram nicht bein Herunterfahren überschrieben werden, geht doch blitz-schnell.
Ich will auch keine.
Kann der Ram nicht bein Herunterfahren überschrieben werden, geht doch blitz-schnell.
Vincent Vega
phisch
Klar, geht schon schnell, wenn Du mal einen Multi-GByte Burst voller Nullen (oder Garbage) erzeugen kannst...
Die ernsthafte Antwort ist: Es ist sinnlos. Was passiert z.B. wenn ich den Rechner einfach ausschalte? Oder wenn ich den RAM im laufenden Betrieb ausbaue?
Die ernsthafte Antwort ist: Es ist sinnlos. Was passiert z.B. wenn ich den Rechner einfach ausschalte? Oder wenn ich den RAM im laufenden Betrieb ausbaue?
bsdagent
Auch im #bsdforen.de Chat
Abend
Du kannst die Password abfrage bei FreeBSD im Single-User-Modus aktivieren
.
Gruss
bsdagent
Du kannst die Password abfrage bei FreeBSD im Single-User-Modus aktivieren
.Gruss
bsdagent
Ist kompliziert
Da muss man ja alle Filesystems neu machen
Kann man sowas nicht während der Installation
Endorphine
Well-Known Member
Völlig übertrieben. Aber eben eine Populärmeinung.
Zuletzt bearbeitet:
Vincent Vega
phisch
Hast Du Dir das Video angeschaut? Es sind zwar ca. 5 Minuten, aber es lohnt. Schau's Dir an. Es ist keine Theorie. Und viel Geld ist auch nicht im Spiel, keine Ahnung was eine Dose Kältespray kostet, aber die meisten hier haben vermutlich mehr als einen Rechner...
Du brauchst keinen Firewire-Controller einstecken - wenn er schon drin ist
Aber Du hast völlig Recht. Es gibt genügend Möglichkeiten im laufenden Betrieb an einen Rechner ranzukommen und die Verschlüsselung zu umgehen. In die Richtung geht auch mein Argument: Die Verschlüsselung von Festplatten u . Swap bringt nur dann was, wenn man davon ausgeht, dass der "Gegner" kommt, denn Rechner ausschaltet, mitnimmt und irgendwann einmal genauers betrachtet.Nochmal: Computer sind nicht sicher, dafür sind sie nicht gebaut. Ich glaube daher, die einfachste und zuverlässigste Methode ist, den Rechner unter Verschluss zu halten. Mir ist jedenfalls das Risiko von Datenverlust zu groß, deshalb verschlüssele ich weder Festplatte (noch Swap).
Endorphine
Well-Known Member
Ja, habe ich. Danke für den Link. Nette Visualisierung. Ich finde trotzdem, dass das nichts neues ist und man jetzt nur erst recht verschlüsselte Partitionen bei Verlassen des Notebooks konsequent entmounten muss, um etwas von der Verschlüsselung zu haben. Mein theoretischer worst case ist immer noch der Fall eines Notebooks im Suspend to Disk, wo dann in aller Ruhe der Schlüssel für die gemounteten verschlüsselten Partitionen extrahiert werden kann.
Partitions-Verschlüsselung soll ja nur noch die letzte Verteidigungslinie sein, wenn Angreifer schon physischen Zugriff auf den Rechner haben. Dass das Prinzip nicht wirkt, wenn die Partition gemounted ist, ist imho nichts neues. Man hat jetzt nur eine Software geschrieben, um auf einen weiteren Weg bei physikalischem Zugriff auf den Rechner an den Schlüssel ranzukommen.
Meiner Meinung nach sollten gängige Partitions-Verschlüsseler eine aktivierbare Timeout-Funktion haben, wenn keine Benutzereingaben mehr erfolgen wird dann unmounted. Und bei jeglichem Wechsel in Standby/Suspend etc. sollte auch automatisch unmounted werden, wie bei TrueCrypt auch üblich...
Ich finde den Wirbel um diese RAM-Auslese-Untersuchung immer noch sehr übertrieben. Ist nur gut, dass sich mal jemand die Zeit genommen hat, das praktisch umzusetzen und jetzt hoffentlich öfter verschlüsselte Partitionen auf Notebooks entmounted werden. Unsicherer als vorher sind verschlüsselte Partitionen aber nicht, wenn man sich bewusst ist, was ein Angreifer so alles über die Hardware anstellen kann, wenn das Laufwerk gemounted ist, und ohne Timeout viel Zeit und physikalischer Zugriff auf den Rechner möglich ist.
für sowas gibt es doch rc.suspend und rc.resume unter FreeBSD und ich denke, das bei den anderen BSDs was ähnliches eingeführt werden wird, wenn denn die ACPI-unterstützung vollständig ist (aber BSD ist ja meistens schnell gebootet
). wie ist das mit linux? gibts da keine skripte, die noch schnell beim suspend "aufräumen"?kommandofrosch
Member
[X] Nein
Habe zwar fuer Nein gestimmt, dass betrifft nur die komplette Hdd, welche eine unverschluesselte Oberflaeche hat.
Es werden nur gezielt Dateien gecryptet und diese Daten sind nur kurzweilig auf Hdd. Generell fallen kaum Daten an, wo es sich nich lohnt alles zu verschluesseln.
Habe zwar fuer Nein gestimmt, dass betrifft nur die komplette Hdd, welche eine unverschluesselte Oberflaeche hat.
Es werden nur gezielt Dateien gecryptet und diese Daten sind nur kurzweilig auf Hdd. Generell fallen kaum Daten an, wo es sich nich lohnt alles zu verschluesseln.
Zuletzt bearbeitet:
Daemotron
Well-Known Member
[x] nicht sinnvoll.
Warum? Der Schlüssel dafür muss ja auch irgendwo liegen, und wenn nicht im RAM, wo dann? Wer also an den (verschlüsselten) RAM-Inhalt gelangt, hat auch automatisch den Schlüssel.
Einzige Möglichkeit, das zu umgehen, wäre, für den Schlüssel einen separaten, schnell flüchtigen Speicher einzusetzen (ein paar KB reichen ja). Geladen wird der von einem externen Device (Chipkarte o. ä.) und die Ver- und Entschlüsselung müssten von einem separaten Prozessor erledigt werden (hier könnte der Speicher als On-Chip-Cache realisiert werden), der im Speicherbus eingeklinkt ist. Dann wäre das Verfahren für die CPU transparent und wenigstens einigermaßen sicher. Von der Performance her aber wahrscheinlich trotzdem problematisch, und auch dieser Chip kann auf irgendeine Weise ausgelesen werden, wenn phyischer Zugriff zum Rechner besteht (ansonsten kommt man ja eh nicht an den RAM-Inhalt, es sei denn, man ist root).
Dieses Thema ist leider aktueller den je:
http://www.heise.de/newsticker/Hearing-zu-Laptop-Durchsuchungen-an-der-US-Grenze--/meldung/110060
Da fällt mir ein:
Angenommen meine /home - Partition ist mit Geli verschlüsselt,
beim Systemstart wird das Passwort abgefragt.
Wäre es möglich diese Abfrage so zu modifizieren,
dass zwei Passwörter akzeptiert werden.
Das eine schaltet die normale Partition frei und mountet diese,
das andere schaltet eine bogus-Partition frei, auf der z.B nur ein User Acount
mit ein paar irrelevanten Daten liegen.
So könnte man bei Zwang zur Herausabe des PWs einfach das andere angeben.
http://www.heise.de/newsticker/Hearing-zu-Laptop-Durchsuchungen-an-der-US-Grenze--/meldung/110060
Da fällt mir ein:
Angenommen meine /home - Partition ist mit Geli verschlüsselt,
beim Systemstart wird das Passwort abgefragt.
Wäre es möglich diese Abfrage so zu modifizieren,
dass zwei Passwörter akzeptiert werden.
Das eine schaltet die normale Partition frei und mountet diese,
das andere schaltet eine bogus-Partition frei, auf der z.B nur ein User Acount
mit ein paar irrelevanten Daten liegen.
So könnte man bei Zwang zur Herausabe des PWs einfach das andere angeben.
FreeBSDuser
Well-Known Member
Das ist ja genau der Ansatz den TrueCrypt implimentiert, ausser beides auf der selben Partition.
Wenn es die Gesetzeslage fordert, ist das wirklich hilfreich.
Wenn es die Gesetzeslage fordert, ist das wirklich hilfreich.
oenone
OpenBSD veteran
Du denkst viel zu kompliziert... Warum sollte das Betriebssystem überhaupt merken, dass der RAM verschlüsselt ist oder den Key dafür kennen?
Einfachste Lösung wäre wohl, das vom RAM-Controller übernehmen zu lassen, also eine Hardwareseitige Lösung. Am Besten bei jedem einschalten einen neuen random-Key dafür erzeugen. So könnte nicht mal das Betriebssystem vorherige Werte aus dem RAM gewinnen, da es ja nicht mehr mit dem selben Schlüssel verschlüsselt wurde.
Was bringt das? Eigentlich nur, dass den RAM auszulesen sinnlos wird, da es unverständlich ist und auch auf keine Weise rekonstruierbar ist. Aber sonst viel einfacher als deine vorgeschlagene Lösung und von Seiten der Performance sehe ich auch keine Probleme.
Gruß
oenone
PS: Obenstehendes ist nur eine ganz spontane Idee, die ich gerade hatte... Stützt sich also auf keinerlei tatsächlich vorhandene Technologie, etc.
bsdagent
Auch im #bsdforen.de Chat
Morgen
Es gibt keine absolute sicherheit!
Bei mir wurde mal eingebrochen
, zum glück habens den PC nicht mitgenommen.
Der Fall Verdi zeigt, was passieren könnte
.
Hätten die von anfang an die Festplatten verschlüsselt, währe das vertrauen an die Datenlöscher nicht nötig bzw. zweitrangig gewesen.
Gruss
bsdagent
Es gibt keine absolute sicherheit
!Bei mir wurde mal eingebrochen
, zum glück habens den PC nicht mitgenommen.Der Fall Verdi zeigt, was passieren könnte
.Hätten die von anfang an die Festplatten verschlüsselt, währe das vertrauen an die Datenlöscher nicht nötig bzw. zweitrangig gewesen.
Gruss
bsdagent
Zuletzt bearbeitet:
Daemotron
Well-Known Member
Habe ich mich wirklich so kompliziert ausgedrückt? Natürlich meinte ich eine transparente Hardware-Lösung; ich konnte mich halt bloß nicht entscheiden, ob das ganzeOgion schrieb:
a) auf der CPU
b) auf der North Bridge oder
c) auf dem RAM-Baustein (z. B. hinter dem Buffer)
passieren soll...
Mittlerweile fände ich aber den RAM-Baustein selbst am interessantesten. Da könnte sogar pro Bank ein eigener Key verwendet werden, und der RAM-Inhalt wird über den ECC-Buffer unverschlüsselt bereit gestellt. So müsste nicht die gesamte Architektur über den Haufen geworfen werden, und die Technik wäre sogar relativ leicht nachrüstbar (durch einfachen Austausch der DIMMs).Ein Random-Key wäre in der Tat eine sehr interessante Lösung. Aber abgesehen von der Schwierigkeit, im Kaltzustand vor dem Boot einen Zufallsschlüssel zu erzeugen, müsste der aber auch im Warmzustand irgendwo aufbewahrt werden. Die herkömmliche Speichertechnik käme dafür aber wohl eher nicht in Frage, denn wer die Möglichkeit hat, durch phyischen Zugriff an den RAM-Inhalt zu gelangen, könnte genauso einen separaten Speicherbaustein auslesen. Vor allem, wenn die Verschlüsselungstechnik (Key-Speicher und Scrambler-Chip) mit auf dem RAM-Riegel sitzen. Wird aber einfach nur der Schlüssel beim herunterfahren (oder auch beim Reset, Ausschalten oder herausnehmen der DIMMs - so viel Restspannung kriegt der Riegel durchaus noch) überschrieben, ist der RAM-Inhalt auf jeden Fall unwiederbringlich futsch, und der Angreifer hat nix gekonnt.
Bei RAM-Riegeln mit "Onboard"-Verschlüsselung gäbe es aber ein entscheidendes Problem: Da gegenüber dem übrigen System (also Bus, Northbridge, CPU) die Verschlüsselung transparent ist, würde bei einem Suspend-to-Disk der unverschlüsselte Speicherinhalt auf der Platte landen. Die Technik eignet sich also nicht unbedingt, um Notebooks abzusichern, wobei gerade die einen solchen Schutz wohl am nötigsten hätten (wg. Diebstahlgefahr).
[x] Würde gerne, weiss aber nicht wie und habe auch keine Erfahrung.
Prinzipiell weiß ich schon, wie man unter OpenBSD eine Partition verschlüsselt - mit den mir bekannten Möglichkeiten (Basissystem, keine Ports/Packages) ist es nur schlicht ein Krampf bei mehr als einer Partition.
Einmal Passwort eingeben für die Festplattenverschlüsselung und dann nochmal für den Login ist ja noch erträglich. Aber für jede einzelne Partition und dann noch Login und ...? Irgendwann muss auch mal gut sein!
Und da vnconfig(8) mit getpass(3) arbeitet, kann man das Problem nicht mal per Skript umgehen. Es sei denn man blockiert mit systrace(1) den Zugriff auf /dev/tty oder patcht sich vnconfig(8).
Prinzipiell weiß ich schon, wie man unter OpenBSD eine Partition verschlüsselt - mit den mir bekannten Möglichkeiten (Basissystem, keine Ports/Packages) ist es nur schlicht ein Krampf bei mehr als einer Partition.
Einmal Passwort eingeben für die Festplattenverschlüsselung und dann nochmal für den Login ist ja noch erträglich. Aber für jede einzelne Partition und dann noch Login und ...? Irgendwann muss auch mal gut sein!
Und da vnconfig(8) mit getpass(3) arbeitet, kann man das Problem nicht mal per Skript umgehen. Es sei denn man blockiert mit systrace(1) den Zugriff auf /dev/tty oder patcht sich vnconfig(8).
Wenn man pro Datenträger nur eine (große) Partition reserviert, um diese zu verschlüsseln und dann erst so zu partitionieren, wie man's gern hätte, kann man sich einen großen Teil der Passwort-Tipperei sparen.
Alt:
/dev/wd0d -> /dev/svnd0d
/dev/wd0e -> /dev/svnd1d
Neu:
/dev/wd0d -> /dev/svnd0d, /dev/svnd0e
Und mit einer kleinen Überarbeitung von /etc/rc (Anhang anzeigen etc_rc-4.3-vnd.patch.txt) kann man die Partitionen sogar über einen Eintrag in /etc/fstab automatisch beim Booten mounten lassen.
Zuletzt bearbeitet:
Endorphine
Well-Known Member
Die TrueCrypt-"hidden volumes sind nichts weiter als eine denkbar primitive Implementierung von Steganografie, und auch besonders leicht auszuhebeln. Wenn dem Angreifer eh schon bekannt ist, dass TrueCrypt verwendet wird, dann weiß er auch automatisch, dass hidden volumes damit möglich sind. Hidden Volumes hinterlassen einen großen Block ohne Fragmente von üblicher Filesystem-Nutzung (Reste gelöschter Dateien/Verzeichnisse, FS-Verwaltungsstrukturen). Ich kann mir kaum einen härteren Verdacht auf versteckte Informationen vorstellen als die Kombination von Truecrypt-Volumes mit ausreichend zusammenhängendem völlig (!) unbenutztem Platz für hidden volumes.
Ich hoffe, dass diese "Technik" nicht irgendwann in geli implementiert wird und lieber ernsthafte Steganographie-Techniken Einzug halten.