Moin zusammen...
Ich habe eine Frage zur Verschlüsselung von USB Sticks.
Ich habe noch einen Stick aus Windows Zeiten, der mit Bitlocker verschlüsselt ist und sich ohne weiteres auf Linux entschlüsseln lässt, sofern das Passwort bekannt ist 
Aber jetzt umgekehrt...kann ich irgendwie einen Stick mit Linux verschlüsseln und eine Passwortabfrage nötig ist um diesen zu lesen? Und im Idealfall kann es auch an einem Windowsrechner entschlüsselt werden?
Moin,
wenn ich es richtig verstanden habe müsste es ja die gleiche Anfrage sein wie hier:
EDIT: Sehe gerade, dass du da damals auch schon rein geschrieben hast 
EDIT: Sehe gerade, dass du da damals auch schon rein geschrieben hast
Das Alter, das Alter...es hat mich in den Fängen...
Ich danke Dir für den Tipp und den Hinweis...
Das dürfte der Knackpunkt sein:
Ein eingebundenes Volume hingegen ermögliche Angriffsvektoren auf das Betriebssystem.
Das gilt dann aber wohl für alle eingebundenen, ggfs. verschlüsselten Volumes, nicht nur solche von Veracrypt. Ich würde mir daher nicht wirklich Sorgen machen.
Die Verschlüsselung selbst wird ja nicht kritisiert.
Das dürfte der Knackpunkt sein:
Das gilt dann aber wohl für alle eingebundenen, ggfs. verschlüsselten Volumes, nicht nur solche von Veracrypt. Ich würde mir daher nicht wirklich Sorgen machen.
Die Verschlüsselung selbst wird ja nicht kritisiert.
Mit entsprechenden Tools, auf die ich nicht weiter eingehen möchte, ist es sehr wohl möglich, sensible Daten wiederherzustellen. Du hast aber recht, dass es nicht nur eine Eigenart von veracrypt ist.
Lextor
Wie
@Tumble schon sagte, ist das nicht nur eine Eigenart von veracrypt. Veracrypt sagt dazu, ""To summarize, VeraCrypt cannot and does not ensure that RAM contains no sensitive data (e.g. passwords, master keys, or decrypted data). Therefore, after each session in which you work with a VeraCrypt volume or in which an encrypted operating system is running, you must shut down (or, if the hibernation file is encrypted, hibernate) the computer and then leave it powered off for at least several minutes (the longer, the better) before turning it on again. This is required to clear the RAM (also see the section Hibernation File).""
VeraCrypt - Free Open source disk encryption with strong security for the Paranoid
Ob wirklich alles gelöscht wurde, kann veracrypt nicht garantieren. Wie denn auch? veracrypt weiß doch nicht, wie der Kernel konfiguriert wurde. Mit der Kernel Option "CONFIG_RESET_ATTACK_MITIGATION" sollte der Kernel den RAM beim Herunterfahren sauber löschen können.
Veracrypt hat noch eine super wichtige Option, um den RAM zu schützen, die /protectMemory Option. Die sorgt dafür, dass sensible Daten wie Passwörter und Schlüssel die im RAm gespeichert sind, besser vor unbefugtem Zugriff und "memory dumping" geschützt sind, u.a. indem sie verschlüsselt werden.
VeraCrypt - Free Open source disk encryption with strong security for the Paranoid
luks wäre ah möglichkeit
Aber zusammenfassend kann man schon sagen, das Veracrypt durchaus gut funktioniert und hier auch anscheinend viele User sind die Veracrypt nutzen und das mit Erfolg und Zufriedenheit. So würde ich das mal einschätzen...
Veracrypt ist eine feine Anwendung um Container/Laufwerke zu verschlüsseln, einschl. der Möglichkeit versteckte volumes zu erstellen, und läuft auf vielen OS. Ich nutze Tcplay, ebenfalls ein feines Tool um veracrypt/truecrypt volumes zu erstellen, zu verschlüsseln- und zu entschlüsseln. Bietet mehr Automatisierungsmöglichkeiten an wenn man das will oder braucht. Tcplay kennt zwar keinen "/protectMemory", aber ab > DDR3 RAM sollte das im Normalfall (abgesehen von Cold Boot Attacks) kein Problem sein, da dieser RAM in nur wenigen Sekunden ihre Daten verlieren.
Die meisten hier werden wohl damit nichts anfangen können, aber ...für diejenigen, die es vielleicht interessiert und genauso paranoid sind wie ich.. 
Das Problem der "Cold-Boot-Attacke" hat mich nicht in Ruhe gelassen. In den letzten ~10 Wochen habe ich manpages gelesen, geschrieben, getestet/ausprobiert. Ich kann nun ein mit Veracrypt/Truecrypt verschlüsseltes Laufwerk, Container usw. verschlüsselt in den Standby (Suspend-to-ram (S3)) schicken und dank cryptsetup/dmsetup die Gefahr einer "Cold-Boot-Attacke" eliminieren. Außerdem sind noch weitere manuelle Eingriffe für ACPI nötig. Es ist noch eine lose Sammlung von Skripten und Konfigurationsdateien. Später würde ich daraus ein Slackware-Paket erstellen, vielleicht. 
Wie funktioniert es ?:
Ich habe es mit dem Notebook-Deckel verknüpft. Schließt man den Deckel, wird das entschlüsselte Veracrypt-Laufwerk beispielsweise vor dem Schlafmodus verschlüsselt und der Schlüssel aus dem Speicher gelöscht. Dadurch verhindert man u.a. eine "Cold-Boot-Attacke". Beim Öffnen des Deckels startet der Entschlüsselungsprozess, und die Zenity-Passwortabfrage poppt auf und nach Eingabe wird das Laufwerk entschlusselt.
Wieso der Aufwand ?:
Die Sicherheit sollte höchste Priorität haben. Es bietet:
1. Schutz vor Cold-Boot-Angriffen
2. SIchere Datenspeicherung während des Schlafmodus
3. Automatisierter Schutzprozess, keine Metadaten
4. Minimierung des Risikos durch physische Angriffe
5. Verhindern von Datenlecks während des Schlafmodus
6. Schutz in öffentlichen und unsicheren Umgebungen
Bugs ?:
Leider ja. Es gibt ein Problem mit Firejail. Wenn Firejail in Benutzung ist, auch wenn es nur für den Browser verwendet wird, friert das System ein, wenn man mit fuser versucht, das Laufwerk zu schließen. Den Grund kenne ich noch nicht. Ich habe den Entwickler angeschrieben um herauszufinden, woran es liegen könnte, aber ich habe noch keine Antwort erhalten. Könnte eventuell auch eine ACPI Problem sein. Wenn es so ist, könnte ich die Prozedur entsprechend anpassen und das Problem lösen.
Bug Lösung ?:
Ja, die gibt es. Temporär kann Firejail vor dem Schlafenlegen des Notebooks mit pkill beendet werden. Allerdings ist es keine elegante Lösung, es auf diese Weise zu beenden.
Sollte jemand etwas kennen, das eine ähnliche Funktion bietet, dann bitte her damit, gerne mit Link. 
Die meisten hier werden wohl damit nichts anfangen können, aber ...für diejenigen, die es vielleicht interessiert und genauso paranoid sind wie ich..
Hast Du auch Sprengfallen an der Haustür? 
Hast Du auch Sprengfallen an der Haustür?
Nee, das nicht, damit kenne ich mich nicht aus.
Was mich beim Schließen des Notebook-Deckels immer gestört hat war, dass die zuvor entschlüsselte Partition oder das Laufwerk unverschlüsselt blieb,, ein Sicherheitsrisiko wie ich finde. Da ich den Deckel oft einfach nur schließe und das Notebook dann immer in der Tasche mit habe, wären im Falle eines Diebstahls meine Daten für jeden sichtbar.
Jetzt aber nicht mehr. Beim Schließen des Deckels wird die Partition oder das Laufwerk verschlüsselt. Das Problem mit Firejail konnte ich inzwischen auch lösen. Es lag tatsächlich an ACPI/DISPLAY. Darauf greife ich jetzt anders zu.
@gf-s15
hm soweit ich das mit LUKS verstehe, sollte dein Notebook doch mit Passwert gesperrt sein.
Also die einzige Möglichkeit physisch da dranzukommen wäre doch den Datenträger auszubauen, dann wäre der aber wieder verschlüsselt meine ich.
Wenn du anstelle eines Kaltstart im Sinne von "Neu Starten" des OS, das Gerät "hart" abschaltest, also Power lange genug drücken das es einfach ausgeht, danach sollte doch kein Weg drumherumführen das du ohne Passworteingabe nicht an die Verschlüsselten Partitionen herankommst ?
mfG
@gf-s15
hm soweit ich das mit LUKS verstehe, sollte dein Notebook doch mit Passwert gesperrt sein.
Also die einzige Möglichkeit physisch da dranzukommen wäre doch den Datenträger auszubauen, dann wäre der aber wieder verschlüsselt meine ich.
Wenn du anstelle eines Kaltstart im Sinne von "Neu Starten" des OS, das Gerät "hart" abschaltest, also Power lange genug drücken das es einfach ausgeht, danach sollte doch kein Weg drumherumführen das du ohne Passworteingabe nicht an die Verschlüsselten Partitionen herankommst ?
mfG
Abgesehen davon, dass ein Hacker sicherlich kein großes Problem hätte, das Passwort einer Bildschirmsperre zu umgehen, gab es in der Vergangenheit einige Bugs. Besonders GDM hatte oft Sicherheitsprobleme im Zusammenhang mit der Bildschirmsperre. Hier ein paar Beispiele:
Richtig, ein Hardreset würde dazu führen, dass die Partition neu entschlüsselt werden müsste. Allerdings bleibt ein Restrisiko bestehen, da das Laufwerk für kurze Zeit unverschlüsselt bleibt. In dieser Zeit könnte je nach Konfiguration, eine Cold-Boot-Attacke durchgeführt werden.
ps.. Denk bitte daran, dass ich keine Vollverschlüsselung mit LUKS meinte. In so einem Fall wäre im Standby keine Verschlüsselung des Laufwerks möglich. Mit Hibernate würde das Laufwerk hingegen ordnungsgemäß verschlüsseln.
Ich meinte ein verschlüsseltes Laufwerk/Partition (z.B. eine zusätzlich eingebaute SSD), in meinem Fall VeraCrypt.
Don’t have an account yet? Register yourself now and be a part of our community!
