Forum: PC Hard- und Software Funktionsweise von LUKS


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Dennis S. (eltio)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich habe eine Frage zu der Festplattenverschlüsselung LUKS. Prinzipiell 
ist es ja so, dass sich das System als Block-Device zwischen Rohdaten 
und Dateisystem "legt". Es werden lediglich die Blöcke entschlüsselt die 
gerade gebraucht werden.

Dies betrifft meine Frage: wie genau ist ein Block definiert? Ich würde 
es erstmal so verstehen, dass nie eine komplette Datei (z.B. ein 
Python-Skript) entschlüsselt vorliegt. Ist das korrekt?

Gruß
Dennis

von c.m. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
512b sektor größe: https://gitlab.com/cryptsetup/cryptsetup

eine datei liegt im übrigen nie entschlüsselt "vor", die dateiblöcke 
werden entschlüsselt während ein read ausgeführt, und die datei in den 
speicher geladen wird.

von Dennis S. (eltio)


Bewertung
0 lesenswert
nicht lesenswert
c.m. schrieb:
> 512b sektor größe: https://gitlab.com/cryptsetup/cryptsetup
>
> eine datei liegt im übrigen nie entschlüsselt "vor", die dateiblöcke
> werden entschlüsselt während ein read ausgeführt, und die datei in den
> speicher geladen wird.

Okay, danke. Dann liege ich mit meiner Vermutung richtig. Um das 
weiterzuspinnen: Wenn ein Angreifer meine (bleiben wir bei dem Beispiel) 
Python-Datei haben will, müsste er über den RAM gehen?

Der von dir beinhaltet keinen Hinweis auf 512 Byte..

Gruß
Dennis

von Guest (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dennis S. schrieb:
> Wenn ein Angreifer meine (bleiben wir bei dem Beispiel) Python-Datei
> haben will, müsste er über den RAM gehen?

Oder er greift einfach auf das eingehängte LUKS Blockdevice zu und lässt 
sich das Skript gemütlich entschlüsseln.

von Εrnst B. (ernst)


Bewertung
0 lesenswert
nicht lesenswert
Dennis S. schrieb:
> Es werden lediglich die Blöcke entschlüsselt die
> gerade gebraucht werden.

Darauf kannst du dich nicht verlassen. Disk-Cache, Read-Ahead usw. 
gelten im Prinzip für jedes Blockdevice, also auch für das 
entschlüsselnde dm_crypt-Device.

Dein python-Script wird also nicht sicherer, nur weil es länger als 512 
bytes ist.

Wenn der Angreifer mit Root-Rechten auf deinen Server kommt, dann kann 
er sich das Script auch runterkopieren, egal ob cryptsetup oder nicht.

Die Verschlüsselung hilft nur gegen "offline"-Angriffe, also wenn sich 
jemand  den Server unter den Arm klemmt und mitnimmt.
(Auch hier gäbe es Möglichkeiten, die Ram-Riegel stark runterzukühlen, 
und dann später auszulesen, ...)

von Dennis S. (eltio)


Bewertung
0 lesenswert
nicht lesenswert
Guest schrieb:
> Oder er greift einfach auf das eingehängte LUKS Blockdevice zu und lässt
> sich das Skript gemütlich entschlüsseln.

Nagut, per BruteForce oder vielleicht noch zu entdeckende Schwachstellen 
in den Algorithmen, das ist klar.

Mir ging es jetzt erst mal um die Bestätigung, dass auch wenn das Skript 
ausgeführt wird, dieses sich nur im RAM unverschlüsselt befindet.

Gruß
Dennis

von Dennis S. (eltio)


Bewertung
0 lesenswert
nicht lesenswert
Εrnst B. schrieb:
> Wenn der Angreifer mit Root-Rechten auf deinen Server kommt, dann kann
> er sich das Script auch runterkopieren, egal ob cryptsetup oder nicht.

Ist das wirklich so? Ich müsste doch um das Device zu mounten das 
"LUKS"-Passwort eingeben oder nicht?

Edit: Okay, das meintest du mit Offline.

Was ist mit folgendem Szenario: Das System läuft, das Skript wird gerade 
ausgeführt. Der normale Anwender hat keinerlei Zugriff. Kann sich ein 
Angreifer, der keine Root-Rechte hat an das laufende System "anhängen"? 
Meinetwegen mit einer anderen Installation die er unter Kontrolle hat? 
Die Schnittstellen würde ich so weit wie möglich eingrenzen.

: Bearbeitet durch User
von Kaj (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hashcat: jetzt auch mit LUKS Support
https://hashcat.net/forum/thread-6225.html

von Axel S. (a-za-z0-9)


Bewertung
1 lesenswert
nicht lesenswert
Dennis S. schrieb:
> Εrnst B. schrieb:
>> Wenn der Angreifer mit Root-Rechten auf deinen Server kommt, dann kann
>> er sich das Script auch runterkopieren, egal ob cryptsetup oder nicht.

Im Zweifelsfall reichen auch weniger Rechte. Sobald das LUKS-Volume 
geöffnet ist (cryptsetup luksOpen ...), kann root darauf zugreifen. 
Sobald das enthaltene Filesystem gemounted ist, schützen nur noch die 
File/Directory-Permissions das Skript vor dem Zugriff eines beliebigen 
eingeloggten Benutzers.

> Was ist mit folgendem Szenario: Das System läuft, das Skript wird gerade
> ausgeführt. Der normale Anwender hat keinerlei Zugriff.

Was nennst du hier "normaler Anwender"? Und inwiefern hat der "keinen 
Zugriff"?

> Kann sich ein
> Angreifer, der keine Root-Rechte hat an das laufende System "anhängen"?

Was meist du mit "anhängen"? Bei einem erfolgreichen Angriff kann der 
Angreifer i.d.R. beliebige Kommandos auf dem System ausführen. Mit 
welcher User-ID er das kann, hängt davon ab, über welchen Prozeß er das 
System kompromittiert hat. Wenn das beispielsweise ein Angriff auf ein 
PHP-Skript war, das vom Apache Webserver ausgeführt wird, dann kann er 
Kommandos als User "www-data" ausführen. Und wenn dieser User dein 
Skript lesen konnte, dann kann es der Angreifer auch.

Beachte auch, daß es immer wieder "privilege escalation" Bugs gibt. 
Gerade kürzlich erst in Linux in Verbindung mit DCCP. Jeder Nutzer kann 
unter Ausnutzung eines solchen Bugs Root-Rechte erlangen, sobald er 
überhaupt erst mal Zugriff hat.

> Meinetwegen mit einer anderen Installation die er unter Kontrolle hat?
> Die Schnittstellen würde ich so weit wie möglich eingrenzen.

Dunkel der Sinn deiner Worte ist.

von LOL (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dennis S. schrieb:
> Der von dir beinhaltet keinen Hinweis auf 512 Byte..

Doch, in der Doku, da wo man es erwarten würde:

https://gitlab.com/cryptsetup/cryptsetup/wikis/LUKS-standard/on-disk-format.pdf

Seite 12.

Da fragt man sich aber, wie lange das noch gelten wird, denn 4k native 
Sektoren sollten ja so langsam kommen.

Was mich eher mehr stört, ist das die SHA-1 als 
Standard-Pseudorandom-Funktion verwenden.
Kennt sich da jemand mit aus und kann sagen, ob es empfehlenswert ist, 
die per Parameter zu ändern?

Die eigentliche Frage betreffend: LUKS selber kennt keine Dateien, da es 
in der Blockschicht arbeitet. Insofern bestimmen darüber liegende 
OS-Schichten, ob irgendwo eine Datei komplett vorliegt oder nicht.

Welche das sind, wurde bereits erwähnt - u.a. diverse Caches, sämtliche 
Dateisysteme, deren Mountpunkte etc. pp.

Die ganze Festplattenverschlüsselung hat ausschließlich 2 
Vorteile/Ziele:
A) Zugriffsschutz bei abgeschaltetem PC (Festplatte extern auslesen)
B) Zugriffsschutz bei eingeschaltetem PC vor dem Mount/Entschlüsseln

Nachdem das LUKS-Blockgerät geöffnet wurde, greift nur noch der 
Standard-Zugriffsschutz des Betriebssystems, wie auch immer der 
aussieht.

Das Einsatzszenario der Festplattenverschlüsselung ist also in der Regel 
"mein Gerät wird geklaut" oder "ich hab einen Killswitch".

Wobei...
https://www.xkcd.com/538/

von Dennis S. (eltio)


Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
> Dunkel der Sinn deiner Worte ist.

Okay, einmal ein konkretes Beispiel.

Ich möchte eine VirtualBox VM an Alice weitergeben auf der ein Skript 
ist, welches nicht eingesehen werden soll. Alles was Alice machen soll 
ist die VM zu starten und über einen Webserver einige Statistiken 
anzusehen. Ansonsten soll Alice keinerlei Zugriff haben ("Schnittstellen 
würde ich so weit wie möglich eingrenzen").

Alice wird keinen User-Account und insbesondere keine root-Rechte 
bekommen. Damit nicht einfach jemand die VM kopiert und in Ruhe die 
Inhalte ansieht möchte ich die Installation verschlüsseln.

Angenommen jedoch, die Maschine läuft: Welche Möglichkeiten hat ein 
Angreifer die Inhalte der VM auszulesen?

Gruß
Dennis

von Planlos (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dennis S. schrieb:
> Angenommen jedoch, die Maschine läuft: Welche Möglichkeiten hat ein
> Angreifer die Inhalte der VM auszulesen?

Alle.

Am einfachsten: Virtual-Box "Beenden und Zustand speichern", dann in 
aller Ruhe aus dem Memory-Dump dein Programm oder den 
Festplatten-Schlüssel auslesen.

von Fritz G. (fritzg)


Bewertung
0 lesenswert
nicht lesenswert
Wenn Alice die VM startet, muss sie ja das LUKS Kennwort eingeben, sonst 
startet die Maschine ja nicht.

von Εrnst B. (ernst)


Bewertung
0 lesenswert
nicht lesenswert
Um dein Problem zusammenzufassen:

Du hast ein Programm in gleichzeitig Menschen- als auch 
Maschinenlesbarer Form (Python-Script).

Du möchtest, dass das Programm Maschinenlesbar (=ausführbar) bleibt, 
aber sich Menschen möglichst schwer tun, das Programm zu verstehen, 
Algorithmen auszulesen, es zu verändern etc.

Dafür gibt's Compiler, die lösen dein Problem ganz ohne Verschlüsselte 
Festplatten-Images, geheime Alice&Bob Keyübergaben und anderen 
Firlefanz.

Wie gut aktuelle Python->EXE Compiler (und ggfs. decompiler) sind, wäre 
natürlich noch anzuschauen.

Ggfs. die "besonders geheimen" Programmteile in C nachimplementieren und 
dazulinken.

: Bearbeitet durch User
von Dennis S. (eltio)


Bewertung
0 lesenswert
nicht lesenswert
Εrnst B. schrieb:
> Um dein Problem zusammenzufassen:
In erster Linie geht es mir darum das Prinzip von LUKS zu verstehen, 
sowie die damit verbundenen Auswirkungen.

> Du hast ein Programm in gleichzeitig Menschen- als auch
> Maschinenlesbarer Form (Python-Script).
Das ist mein erdachter Worst-Case.

> Wie gut aktuelle Python->EXE Compiler (und ggfs. decompiler) sind, wäre
> natürlich noch anzuschauen.
Die sind unbrauchbar, weil Kompilieren nicht Verschlüsseln bedeutet. 
Genauso wie die "Obfuscator", da das einfach keine "Security" ist.. 
steckt ja im Namen. ;-)

> Ggfs. die "besonders geheimen" Programmteile in C nachimplementieren und
> dazulinken.
Bei sehr großen Projekten ist das kaum machbar. Und Disassemblieren kann 
man das ja auch jederzeit.

Ich bin was Security-Themen angeht nicht ganz unwissend. Deswegen weiß 
ich auch, dass es keine Lösung für alle Angriffsvektoren gleichzeitig 
gibt. Hier ging es mir erstmal darum zu erfahren, gegen welche Angriffe 
mich die Festplattenverschlüsselung (in gewissen Grenzen) schützt.

Dazu schon mal vielen Dank für eure Antworten.

Gruß
Dennis

von c.m. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dennis S. schrieb:
> Εrnst B. schrieb:
>> Um dein Problem zusammenzufassen:
> In erster Linie geht es mir darum das Prinzip von LUKS zu verstehen,
> sowie die damit verbundenen Auswirkungen.

kurz und vereinfacht: LUKS ist sicher solange der container nicht offen 
ist.

du kannst ganz schlecht jemandem code zum ausführen geben (vor allem 
scripte) ohne gefahr zu laufen das er gelesen wird.
was du eventuell machen könntest ist einen service aufzusetzen, so das 
anwender dir daten schicken, du sie bearbeitest und dann das ergebnis an 
den anwender zurück schickst - kommt auf die anwendung an.

von Dennis S. (eltio)


Bewertung
0 lesenswert
nicht lesenswert
c.m. schrieb:
> was du eventuell machen könntest ist einen service aufzusetzen, so das
> anwender dir daten schicken, du sie bearbeitest und dann das ergebnis an
> den anwender zurück schickst - kommt auf die anwendung an.

So habe ich mir das auch gedacht. Der "Service" für Alice wäre ja das 
Skript innerhalb der VM. Meinetwegen mit einem kleinen HTTP-Server mit 
dem diverse Statistiken ausgelesen werden können. Die Frage ist eben: 
welche Möglichkeiten hat ein Angreifer dann in die VM "einzubrechen"
1. Solange die VM nicht gestartet ist, kann sie auch nicht woanders 
eingehängt und untersucht werden, wegen LUKS.
2. Wenn die VM gestartet ist kann ein Memory-Dump gemacht werden 
(VirtualBox kann eine ELF-Datei erstellen) und dieser untersucht werden. 
Meines Erachtens ist das aber schon wieder keine Aufgabe für 
"Otto-Normalverbraucher".

Dass man mit mehr Aufwand sicherere Implementierungen, aber auch 
ausgeeilterere Angriffe realisieren kann ist auch klar.

Gruß
Dennis

von Sven B. (scummos)


Bewertung
0 lesenswert
nicht lesenswert
Dennis S. schrieb:
> Ich möchte eine VirtualBox VM an Alice weitergeben auf der ein Skript
> ist, welches nicht eingesehen werden soll. Alles was Alice machen soll
> ist die VM zu starten und über einen Webserver einige Statistiken
> anzusehen. Ansonsten soll Alice keinerlei Zugriff haben ("Schnittstellen
> würde ich so weit wie möglich eingrenzen").

Das ist prinzipiell rein logisch nicht möglich. Wenn der Computer von 
Alice das Skript ausführen kann, kann Alice es auch lesen.

von c.m. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
du kannst eine VM mit LUKS nicht einfach starten, weil beim start das 
passwort für die verschlüsselung ein/angegeben werden muss.

und wenn die schwarzer das passwort kennt, kann sie auch auf das 
diskimage der vm lesend zugreifen.
auch hier wieder kurz: der host hat vollständige kontrolle über die VM.

das ist natürlich mit etwas aufwand verbunden, aber wer sich für den 
inhalt eines python-scriptes interessiert wird mit einiger 
wahrscheinlichkeit auch das hirnschmalz haben an das script selbst heran 
zu kommen.

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
Dennis S. schrieb:
> Axel S. schrieb:
>> Dunkel der Sinn deiner Worte ist.
>
> Okay, einmal ein konkretes Beispiel.
>
> Ich möchte eine VirtualBox VM an Alice weitergeben auf der ein Skript
> ist, welches nicht eingesehen werden soll. Alles was Alice machen soll
> ist die VM zu starten und über einen Webserver einige Statistiken
> anzusehen. Ansonsten soll Alice keinerlei Zugriff haben ("Schnittstellen
> würde ich so weit wie möglich eingrenzen").

Das geht nicht.

Eine VM weitergeben ist gleichbedeutend mit "ein disk-image weitergeben" 
und du hast keinerlei Kontrolle darüber, was Alice mit dem disk-image 
macht. Natürlich kann Alice die VM einfach von dem Image starten und 
dann daran "scheitern", das root-Paßwort (oder irgendein anderes User- 
Paßwort) nicht zu kennen. Aber genauso gut kann Alice auch das 
/-Filesystem aus dem Image direkt mounten und hat dann Zugriff auf 
alles. FAIL!

Auch LUKS (oder jegliche andere Plattenverschlüsselung) hilft dir hier 
nicht. Denn entweder muß das Paßwort manuell eingegeben werden - dann 
ist die VM als solche für Alice nicht nutzbar. Oder das Paßwort ist 
irgendwo versteckt in der initrd oder in der Kernel-Kommandozeile - dann 
kann Alice es eben da auslesen. FAIL!

> Alice wird keinen User-Account und insbesondere keine root-Rechte
> bekommen. Damit nicht einfach jemand die VM kopiert und in Ruhe die
> Inhalte ansieht möchte ich die Installation verschlüsseln.

Wie bereits gesagt: Verschlüsselung ist keine Einbahnstraße. Ohne den 
Schlüssel sind die Daten für gar nichts zu gebrauchen. Aber sobald du 
den Schlüssel aus der Hand gibst, hast du keine Kontrolle mehr, was mit 
den entschlüsselten Daten passieren wird.

Das ist das klassische DRM-Dilemma. DRM beruht nicht auf der Kontrolle 
über die verschlüsselten Daten. DRM braucht Kontrolle über die Geräte 
(hier: Software) die die Daten entschlüsselt. Traditionell werden hier 
die Schlüssel in die Geräte eingebettet, auf eine Weise die die 
Extraktion der Schlüssel erschwert (beabsichtigt: unmöglich macht).
In der Praxis leaken immer irgendwo Schlüssel, weswegen auch kein DRM- 
System wirklich wasserdicht ist. Erlieg nicht der gleichen Illusion!

: Bearbeitet durch User
von Dennis S. (eltio)


Bewertung
0 lesenswert
nicht lesenswert
Sven B. schrieb:
> Das ist prinzipiell rein logisch nicht möglich. Wenn der Computer von
> Alice das Skript ausführen kann, kann Alice es auch lesen.
Naja schon: Alice startet die VM und gibt das LUKS-Kennwort ein. Das OS 
startet mit den entsprechenden Skripten im Hintergrund. Alice muss und 
kann sich nicht einloggen und hat daher auch keinen Zugriff auf das 
Dateisystem.

c.m. schrieb:
> das ist natürlich mit etwas aufwand verbunden, aber wer sich für den
> inhalt eines python-scriptes interessiert wird mit einiger
> wahrscheinlichkeit auch das hirnschmalz haben an das script selbst heran
> zu kommen.
Das ist ein wichtiger Punkt: wieviel Aufwand will ich betreiben um 
diverse Angriffsfaktoren auszuschalten. Wenn wir mal davon ausgehen, 
dass ja nicht Alice die Böse ist sondern Oscar verhindere ich doch mit 
der Verschlüsselung wenigstens, dass letzterer die VM kopiert und 
einfach in sein System einhängt (Vorausgesetzt das Passwort ist 
unbekannt).

Axel S. schrieb:
> [...] Erlieg nicht der gleichen Illusion!
Danke für den ausführlichen Beitrag. Du hast natürlich in allen Punkten 
Recht. Ich werde da noch etwas drüber nachdenken, zumal der Aufwand die 
Verschlüsselung zu aktivieren fast 0 ist.

Gruß

von Jan H. (j_hansen)


Bewertung
0 lesenswert
nicht lesenswert
Dennis S. schrieb:
> Ich bin was Security-Themen angeht nicht ganz unwissend.

Naja...

Dennis S. schrieb:
> Naja schon: Alice startet die VM und gibt das LUKS-Kennwort ein. Das OS
> startet mit den entsprechenden Skripten im Hintergrund. Alice muss und
> kann sich nicht einloggen und hat daher auch keinen Zugriff auf das
> Dateisystem.

Das ist dir doch jetzt eh schon mehrmals erklärt worden: Alice hängt 
sich das Festplattenimage der VM einfach auf ihrem lokalen PC ein - 
LUKS-Kennwort muss sie ja kennen - und schon kann sie schalten, walten 
und "herumrooten" wie sie will.

von Dennis S. (eltio)


Bewertung
0 lesenswert
nicht lesenswert
Jan H. schrieb:
> Das ist dir doch jetzt eh schon mehrmals erklärt worden: Alice hängt
> sich das Festplattenimage der VM einfach auf ihrem lokalen PC ein -
> LUKS-Kennwort muss sie ja kennen - und schon kann sie schalten, walten
> und "herumrooten" wie sie will.
Ja das steht da schon mehrfach. Aber du scheinst die Grundlage nicht zu 
sehen, dass es verschiedene Angriffsszenarien gibt die unterschiedliche 
Gegenmaßnahmen erfordern. Du solltest auch nicht von der irrtümlichen 
Annahme ausgehen, dass es eine All-in-one-Lösung gibt! Auch 
Aufwand/Nutzen muss auf Anbieter und Angreifer-Seite abgewogen werden.

Vieles dazu wird auch in den einschlägigen Normen beschrieben, die es 
sich zu lesen lohnt.

Schönen Gruß

von c.m. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jan H. schrieb:
> Das ist dir doch jetzt eh schon mehrmals erklärt worden: Alice hängt
> sich das Festplattenimage der VM einfach auf ihrem lokalen PC ein -
> LUKS-Kennwort muss sie ja kennen - und schon kann sie schalten, walten
> und "herumrooten" wie sie will.

siehe https://www.google.de/search?q=vm+image+mounten
oder auch: zweite vm anlegen, und das verschüsselte root-disk-image 
einfach als weitere festplatte dran hängen.

gibt viele (und nicht allzu komplizierte) wege an den inhalt zu kommen, 
vor allem wenn man den LUKS schlüssel kennt.

von Sven B. (scummos)


Bewertung
0 lesenswert
nicht lesenswert
Dennis S. schrieb:
> Vieles dazu wird auch in den einschlägigen Normen beschrieben, die es
> sich zu lesen lohnt.

Naja. Es gibt halt einfach Dinge die prinzipiell sicher sind, d.h. das 
verwendete kryptographische Verfahren muss gebrochen werden oder die 
Software muss fehlerhaft sein, um den Schutz auszuhebeln, und es gibt 
Dinge die prinzipiell nicht sicher sind und bei denen man mit ein 
bisschen technischem Sachverstand an dem kryptographischen Verfahren 
einfach vorbei laufen kann. Jede Lösung für das hier beschriebene 
Problem fällt in letztere Kategorie, egal was in den Normen steht.

von Dennis S. (eltio)


Bewertung
0 lesenswert
nicht lesenswert
Sven B. schrieb:
> Jede Lösung für das hier beschriebene Problem fällt in letztere
> Kategorie, egal was in den Normen steht.
Das kann man so nicht stehenlassen, weil du davon ausgehst, dass deine 
Definition von "sicher" allgemeingültig ist und insbesondere mit 
"unknackbar" gleichzusetzen (was bitte heißt das schon wieder...) Und 
das wiederum ist in den Normen sehr wohl beschrieben (Stichwort 
Security Level nach IEC62443).

Wie ich bereits sagte: Security bedeutet nicht, dass eine Technologie 
alle Probleme löst. Verschiedene Angriffsvektoren erfordern 
unterschiedliche Vorgehensweisen. Insbesondere müssen diese 
Vorgehensweisen nicht von technischer sondern könnten auch 
organisatorischer Natur sein.

Wer sich einmal mit dem Thema auseinandergesetzt hat, weiß auch wie 
wichtig es ist zu wissen
1) Welche Möglichkeiten es gibt
2) Welche Angriffsvektoren adressiert werden
und
3) Wo die Grenzen der eingesetzten Schutzfunktion sind.

Genau dieser Punkt war Intention meiner Frage: Was kann LUKS und was 
nicht.

Viele Grüße.

von Εrnst B. (ernst)


Bewertung
0 lesenswert
nicht lesenswert
Dennis S. schrieb:
> Was kann LUKS und was
> nicht.

Dann, einfache Antwort:

Das was du erwartest, kann es nicht, soll es nicht können, wird es nie 
können.

Du verfolgst einen völlig falschen Ansatz.

Da macht es keinen Sinn über "Angriffsvektoren" ö.Ä. zu diskutieren.
Alles was du als "Angriff" ansiehst, ist keiner, sondern reguläre 
Nutzung von dm_crypt/Luks mit bekanntem Passwort.

Genausowenig macht es Sinn über die Sicherheit von Fahrrad-Schlössern zu 
diskutieren, wenn du aus Prinzip immer den Schlüssel stecken lässt.

von Der Andere (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Dennis S. schrieb:
> Was kann LUKS und was nicht.

Es kann deine Daten schützen, wenn deine Platte/Laptop gekaut worden 
ist.

von Sven B. (scummos)


Bewertung
0 lesenswert
nicht lesenswert
Εrnst B. schrieb:
> Genausowenig macht es Sinn über die Sicherheit von Fahrrad-Schlössern zu
> diskutieren, wenn du aus Prinzip immer den Schlüssel stecken lässt.

So ist es, und aus meiner Sicht ist es auch egal was die Norm da für 
Sicherheitsklassen festlegt oder welche Angriffsvektoren du diskutierst. 
Du kannst Code der auf dem Rechner des Anwenders ausgeführt wird nicht 
vor dem Anwender verstecken, das ist "security by obscurity", end of 
story. Wenn du den Code nicht zugänglich haben willst, bau einen 
Web-Service.

Das einzige was in die Richtung geht dass es den Zugriff zumindest mal 
erheblich erschwert ist so TPM-Zeug.

: Bearbeitet durch User
von Dennis S. (eltio)


Bewertung
-1 lesenswert
nicht lesenswert
Εrnst B. schrieb:
> Das was du erwartest, kann es nicht, soll es nicht können, wird es nie
> können.
Meine "Erwartung" war im Wesentlichen die Antwort auf die Frage die ich 
gestellt habe: 512 Byte (zweite Post). Bis auf wenige interessante 
Ergänzungen war der Rest "Nebenschaukampf" von Leuten die wilde 
Mutmaßungen anstellen.

Sven B. schrieb:
> Du kannst Code der auf dem Rechner des Anwenders ausgeführt wird nicht
> vor dem Anwender verstecken, das ist "security by obscurity", end of
> story.
Wir brauchen wirklich nicht über das kleine 1x1 der Security 
diskutieren. Eher über Implementierungsdetails von LUKS (siehe Frage). 
Ich habe ja auch nie behauptet, dass der Alice alles ausführen aber 
nichts sehen darf.

Vielen Dank für die hilfreichen Antworten.

von Dennis S. (eltio)


Bewertung
0 lesenswert
nicht lesenswert
Εrnst B. schrieb:
> Du verfolgst einen völlig falschen Ansatz.
Gedankenexperimente haben nie einen falschen Ansatz.

> Alles was du als "Angriff" ansiehst, ist keiner, sondern reguläre
> Nutzung von dm_crypt/Luks mit bekanntem Passwort.
Wie zum Beispiel Reverse Engineerung ohne Kentniss des Passworts? 
Inwiefern ist das in dm_crypt vorgesehen?

> Genausowenig macht es Sinn über die Sicherheit von Fahrrad-Schlössern zu
> diskutieren, wenn du aus Prinzip immer den Schlüssel stecken lässt.
Der Vergleich hinkt, weil der Schlüssel gar nicht steckt.

Gruß

von Εrnst B. (ernst)


Bewertung
0 lesenswert
nicht lesenswert
Dennis S. schrieb:
>> Alles was du als "Angriff" ansiehst, ist keiner, sondern reguläre
>> Nutzung von dm_crypt/Luks mit bekanntem Passwort.
> Wie zum Beispiel Reverse Engineerung ohne Kentniss des Passworts?
> Inwiefern ist das in dm_crypt vorgesehen?#


Wie jetzt? Soll jetzt das Programm/die VM doch nicht startbar sein?

Da brauchst du auch kein dm_crypt, da kannst du Alice auch einfach ein 
paar Megabyte aus /dev/random kopieren und behaupten, da wäre deine 
Software drinnen.
Ist gleich nochmal sichererer.

>
>> Genausowenig macht es Sinn über die Sicherheit von Fahrrad-Schlössern zu
>> diskutieren, wenn du aus Prinzip immer den Schlüssel stecken lässt.
> Der Vergleich hinkt, weil der Schlüssel gar nicht steckt.

Wenn du in jedem zweiten Post deine Anforderungen änderst, dann ist das 
auch kein Wunder.

Deine aktuelle Anforderung ist jetzt:

"Wie gebe ich Alice Software, die sie niemals nicht anschauen & 
ausführen können soll"?

Oder wie?

Dennis S. schrieb:
> Gedankenexperimente haben nie einen falschen Ansatz.

Na dann. Sieh den Vorschlag mit "/dev/random" als Gedankenexperiment.

von Dennis S. (eltio)


Bewertung
0 lesenswert
nicht lesenswert
Εrnst B. schrieb:
> Wie jetzt? Soll jetzt das Programm/die VM doch nicht startbar sein?
Doch natürlich. Aber ein "Angriff" ist für mich zum Beispiel, dass Oskar 
ohne Kenntnis des Verschlüsselungspassworts versucht das Skript 
auszulesen. Meine Frage an dich: wo finde ich in der Dokumentation von 
dm_crypt die entsprechende Passage wie man das macht? Du hast ja 
behauptet das wäre (eine) reguläre Nutzung von dm_crypt.

> Da brauchst du auch kein dm_crypt, da kannst du Alice auch einfach ein
> paar Megabyte aus /dev/random kopieren und behaupten, da wäre deine
> Software drinnen.
> Ist gleich nochmal sichererer.
Nein, das ist falsch. Leider hast du das komplette Prinzip von Software 
nicht verstanden.

> Wenn du in jedem zweiten Post deine Anforderungen änderst, dann ist das
> auch kein Wunder.
Du hast ein Problem mit abstaktem Denken. Person A ist nicht gleich mit 
Person B. A ist hier Alice, die hat den Zugang. B ist ein Angreifer 
("Oskar") der hat keinen Zugang. Sorry aber das sind echt Grundlagen...

> Deine aktuelle Anforderung ist jetzt:
> "Wie gebe ich Alice Software, die sie niemals nicht anschauen &
> ausführen können soll"?
Nein das ist wieder falsch, siehe oben. Frage an dich: warum sollte man 
das wollen?

> Na dann. Sieh den Vorschlag mit "/dev/random" als Gedankenexperiment.
Danke, das ist ein interessanter Ansatz aber ich denke das führt mich 
nicht weiter. Am besten suchst du mal bei Google nach "/dev/random" dann 
verstehst du wieso.

Gruß

von Gummibärchen (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Der Andere schrieb:

> Es kann deine Daten schützen, wenn deine Platte/Laptop gekaut worden
> ist.

Das wird dem Dieb aber schwer im Magen liegen.

von Dennis S. (eltio)


Bewertung
0 lesenswert
nicht lesenswert
Gummibärchen schrieb:
> Das wird dem Dieb aber schwer im Magen liegen.
:-)

von Sven B. (scummos)


Bewertung
0 lesenswert
nicht lesenswert
Dennis S. schrieb:
>> Wenn du in jedem zweiten Post deine Anforderungen änderst, dann ist das
>> auch kein Wunder.
> Du hast ein Problem mit abstaktem Denken. Person A ist nicht gleich mit
> Person B. A ist hier Alice, die hat den Zugang. B ist ein Angreifer
> ("Oskar") der hat keinen Zugang. Sorry aber das sind echt Grundlagen...

Ich zitiere mal deinen Post von weiter oben:
> Ich möchte eine VirtualBox VM an Alice weitergeben auf der ein Skript
> ist, welches nicht eingesehen werden soll. Alles was Alice machen soll
> ist die VM zu starten und über einen Webserver einige Statistiken
> anzusehen. Ansonsten soll Alice keinerlei Zugriff haben

Was denn nun.

von Dennis S. (eltio)


Bewertung
0 lesenswert
nicht lesenswert
Sven B. schrieb:
> Was denn nun.

Touché.
Das passiert wenn plötzlich Diskussionen auftauchen die gar nicht 
Gegenstand des Threads sind. Also: unabhängig von eventuellen 
Wiedersprüchen sind natürlich realistische Annahmen zu treffen.

Abschließend: 512 Byte. Danke.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.