Hallo, Ich habe eine verschlüsselte Home-Partition und eine verschlüsselte Partition, die ich für /tmp nutzen möchte. Hibernate(bzw. suspend-to-disk) benutze ich sowieso nicht. Suspend(-to-RAM) benutze ich aber. Wenn der Laptop in den Suspendmodus geht, wird die Home ja nicht wieder verschlüsselt. Ist das sicher? Oder kann ein Angreifer Daten aus dem RAM lesen? Kann man die Sicherheit verbessern? Danke
Verschlüsselung + Suspend. Sicher?
Antworten |
Anmeldungsdatum: Beiträge: 94 |
|
Supporter
Anmeldungsdatum: Beiträge: 53627 Wohnort: Berlin |
Kommt darauf an, wie sicher dein Passwort ist.
Unter Laborbedingungen unter Umständen, wenn er dein RAM einfriert. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 94 |
Ok. Ich benutze das gleiche Passwort zum Einloggen und zum Verschlüsseln. Das heißt also, dass es für einen Angreifer im Suspend genauso schwer/leicht ist, wie beim einloggen? |
Anmeldungsdatum: Beiträge: 12085 Wohnort: Berlin |
Was meinst Du damit genau? Der Login und Verschlüsselung sind zwei völlig verschiedene Sicherheitssysteme. Der Login schützt Dich nur kurzfristig gegen Zugriff aufs System, wenn der Angreifer wenig Zeit hat oder sich übers Netz einloggen will. Sobald er (oder sie) direkten Zugriff auf Deine Hardware hat, baut er die Festplatte aus und schließt sie an einen anderen Rechner an, bootet Deinen Rechner von einem USB-Stick, fährt im Rettungsmodus hoch, baut Dir einen Hardware-Keylogger ein etc. – Vor alledem schützt Dich ein Loginpasswort nicht. Verschlüsselung hingegen schützt Deine Daten vor den meisten o.g. Zugriffen (außer dem Keylogger), da die Daten selbst verschlüsselt auf der Platte liegen, egal wie auf diese zugegriffen wird. Verschlüsselung schützt nicht bei laufendem System vor Zugriff durch dieses, da währenddessen die Daten im System (und RAM) entschlüsselt vorliegen. Wenn also Dein Login-Passwort schwach ist und jemand sich dadurch in Dein laufendes System mit „geöffneter“ Verschlüsselung hackt, hat er freien Zugriff auf die im System unverschlüsselt vorliegenden Daten. |
Anmeldungsdatum: Beiträge: 7658 |
Wenn du Suspend-to-RAM nutzt, ohne gleichzeitig auch sowas wie luksSuspend zu nutzen, dann ist der Key im RAM. Kann theoretisch ausgelesen werden. Oder auch ohne Auslesen Zugriff auf die Daten ermöglichen, je nachdem wie abgeschottet das System nach dem Resume ist. luksSuspend erfordert die erneute Eingabe der Passphrase beim Resume, da ist der Key dann - idealerweise - weg (Dateisystemcaches jedoch nicht), solange die Kiste im Suspend sitzt. Es ist allerdings relativ kompliziert das zu konfigurieren, da man zum luksResume ja eine funktionierende cryptsetup-Binary braucht, die nicht auf dem suspendierten LUKS liegen darf. Gleiches Problem wie beim /boot das unverschlüsselt sein muß. Wird daher nur selten wirklich genutzt (ich selbst verzichte aus Usability-Gründen auch darauf). |
(Themenstarter)
Anmeldungsdatum: Beiträge: 94 |
Ich muss da noch mal nachharken; Wir haben folgendes Szenario: Ich logge mich ein und entschlüssel meine Home. Dann fährt mein Rechner in den Suspend-to-RAM. Jetzt bin ich ja quasi ausgeloggt. Jetzt ist mir nciht ganz klar: Der Key ist im RAM. Warum? Ist die Homepartition noch unverschlüsselt? Welche Möglichkeiten hat jetzt der Angreifer? Ich gehe natürlich davon aus, dass der Angreifer mein Passwort nicht kennt(wäre ja sonst n bisschen simpel). Im RAM gibts den Key. Den RAM kann er also ausbauen und dann(mit ein wenig Glück) sofort bei sich auslesen und dann hat er den Key. So? Kann man sich gegen einen solchen Angriff wehren(außer Suspend nicht zu verwenden)? Und dann wurde angedeutet, dass theoretisch auch ohne den Key zugegriffen werden kann. Wie läuft das? Der Angreifer kommt ja nicht in mein System, also müsste er ja sein eigenes starten. Aber ist dann nicht die Partition wieder abgeschlossen? Bzw.: Wie kann ich sichergehen, dass sich die Festplatte wieder verschließt, wenn Jemand sein System startet? Danke für eure Hilfe und Geduld! |
Anmeldungsdatum: Beiträge: 7658 |
Bist du das? Also ich bin nicht ausgeloggt, bei mir kommt nach dem Resume nur der Bildschirmschoner mit Passwortabfrage. Bei ecryptfs könnte man das nun für suspend-resume nutzen (wenn man das Passwort ja eh eingeben muß) aber ob das tatsächlich der Fall ist? Du könntest es mal testen mit einem Terminal wo du das reinhaust: while sleep 1 do date >> ~/date.log done Das schreibt jede Sekunde Datum/Uhrzeit in die Datei date.log in deinem Home. Wenn du die Kiste dann für eine volle Minute in den Suspend schickst, müsste ein Zeitloch von einer Minute in dieser Logdatei sein. Wenn du dann nach dem Resume erstmal keine Passwörter eintippst sondern nochmal ein paar Minuten wartest - dann müsste, wenn die Verschlüsselung erst mit Passworteingabe wieder aktiv wird, das Zeitloch entsprechend größer sein. Wenn das Logfile dann direkt nach der Minute weitergeht, dann war die Verschlüsselung nicht suspendiert, ergo der Key im RAM. ( Das geht jetzt naiv davon aus, daß bei suspendierter Verschlüsselung das date >> ~/date.log hängen bleiben würde da Lese/Schreibzugriffe solange eingefroren sind. Kann aber genausogut im Dateisystembuffer landen. Hm. Muss ich selbst mal ausprobieren. ) Zumindest bei luksSuspend/Resume mit ext2 klappt das, sieht dann so aus: Mon Sep 23 18:40:33 CEST 2013 Mon Sep 23 18:40:34 CEST 2013 Mon Sep 23 18:40:35 CEST 2013 Mon Sep 23 18:41:53 CEST 2013 Mon Sep 23 18:41:54 CEST 2013 Mon Sep 23 18:41:55 CEST 2013 Von 18:40:35 bis 18:41:53 war der Container suspended, ergo Zeitloch im Logfile. Wenn du (in dem Beispiel) dein Passwort erst wieder um 18:43 eingibst, aber ab 18:41 schon im Logfile ist, dann war die Verschlüsselung nie inaktiv. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 94 |
Ist bei mir genauso. Also keine erneute Verschlüsselung. Aber kann der Angreifer daraus einen Vorteil ziehen? |