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
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.
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
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.
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, ...)
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
Ε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
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.
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/
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
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.
Wenn Alice die VM startet, muss sie ja das LUKS Kennwort eingeben, sonst startet die Maschine ja nicht.
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
Ε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
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.
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
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.
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.
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
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ß
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.
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ß
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.
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.
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.
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.
Dennis S. schrieb: > Was kann LUKS und was nicht. Es kann deine Daten schützen, wenn deine Platte/Laptop gekaut worden ist.
Ε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
Ε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.
Ε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ß
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.
Ε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ß
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.
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.