FileVault ist unsicher

alle reden davon das der ram verschlüsselt werden müsste, was ich für quatsch halte, denn der ist flüchtig, schaltest du den Compi aus ist der Inhalt weg, den Computer sollte man sowieso nicht unbeaufsichtigt lassen wen sensible daten drauf sind und er läuft. Mich stört ehr das die login daten dauerhaft ins swapfile geschrieben werden, das heisst, jemand kommt in meine Bude, nimmt die platte, schliesst sie an seinen Rechner und kann dann ganz gemütlich von seinem System mit einer simplen Eingabe mein Passwort erfragen, dann von meiner Platte booten und das Passwort eingeben, und dabei wird nebenbei auch gleich mein Filevault image, entschlüsselt, super praktisch! leichter als ein Sparschwein aufzubrechen. Und das auch wenn der Computer aus war. man sollte ja auch bedenken das nur ein admin den inhalt auf den laufenden System erfragen kann also ist die Gefahr beim laufendem system eher gering zudem wenn man vor sitzt.
 
-Nuke- schrieb:
Achja. Warum ein Passwort im RAM bleiben muss?

Weil es mit der Anmeldung nicht getan ist. Sonst könntest du gar nicht auf deine Daten, bzw. deine gespeicherten Kennwörter zugreifen. Außer du gibst alle 5 Sekunden dein Kennwort ein.

Das ist imho falsch.
Das (Klartext) Passwort brauchst du nur, wenn du es direkt mit einem anderen String (z.B. Klartext PW, gespeichert auf der Festplatte) vergleichen willst, was an sich schon ein Kardinalfehler ist.

Grundsätzlich sollten Passwörter immer unmittelbar nach der Eingabe einem Kryptografischen Hash-Verfahren unterzogen werden, sodass anschließend für alle weiteren Zwecke nur noch mit dem Has-Wert gearbeitet werden muss.
Diese Kryptografischen Hash-Werte haben die Eigenschaft, dass man von ihnen nicht auf die Eingabe (Klartext Passwort) zurückschließen kann.
=> D.h., wenn ich den Hash-Wert kenne nützt mir das erstmal garnix, da ich ihn nicht in das System hereinbekomme, weil die Login-Routine das Klartext-Passwort und nicht einen Hash-Wert einliest.

Dieses System lässt sich dann nur durchbrechen, wenn die Login-Routine, die normalerweise das Passwort einliest und die Umwandlung in den Hash-Wert vornimmt, ausgetauscht wird durch eine, die man mit einem zuvor erbeuteten Hash-Wert füttern kann.

Auch wenn es keine absolute Sicherheit gibt und das persönliche Sicherheitsbedürfnis des Einzelnen durch ein Abwägen aus Bedrohungsgefühl, akzeptablen Unbequemlichkeiten und weiteren Faktoren ist, so sollte man doch seit langem bekannte Standardfettnäpfchen (s.u.) vermeiden.
Insbesondere, wenn die Sicherheit der betroffenen Systemkomponente werblich besonders heraus gestellt wird.

[edit] Im übrigen betrifft dieses Problem nicht nur das FileVault Passwort.
Auch komplett verschlüsselte USB Disks könnten sich (auszugsweise) im Klartext im Swap-File finden, wenn man dies nicht explizit verhindert. [/edit]


Gruß,

?=?


PS.: "Login-Routine" ist bewusst undifferenziert ausgedrückt. Mir ist klar, dass es in "Wirklichkeit" um eine komplexe Kombination von (PAM-) Modulen innerhalb eines Login-Prozesses geht, was aber für die Betrachtung der Hash-Werte nebensächlich ist.

PPS.:
Auszug aus Phil Zimmermanns "Introduction to Cryptography" 1990-2000; eins von elf erwähnten "Standardfettnäpfchen".

Swap files or virtual memory

PGP was originally developed for MS-DOS, a primitive operating system by
today’s standards. But as it was ported to other more complex operating
systems, such as Microsoft Windows and the Macintosh OS, a new
vulnerability emerged. This vulnerability stems fromthe fact that these fancier
operating systems use a technique called virtual memory.
Virtual memory allows you to run huge programs on your computer that are
bigger than the space available in your computer’s semiconductor memory
chips. This is handy because software has become more and more bloated
since graphical user interfaces became the norm and users started running
several large applications at the same time. The operating system uses the hard
disk to store portions of your software that aren't being used at the moment.
This means that the operating system might, without your knowledge, write
out to disk some things that you thought were kept only in main
memory—things like keys, passphrases, and decrypted plaintext. PGP does
not keep that kind of sensitive data lying around in memory for longer than
necessary, but there is some chance that the operating system could write it
out to disk anyway.
The data is written out to some scratchpad area of the disk, known as a swap
file. Data is read back in fromthe swap file as needed, so that only part of your
program or data is in physical memory at any one time. All this activity is
invisible to the user, who just sees the disk chattering away. Microsoft
Windows swaps chunks of memory, called pages, using a Least RecentlyUsed
(LRU) page-replacement algorithm. This means pages that have not been
accessed for the longest period of time are the first ones to be swapped to the
disk. This approach suggests that in most cases the risk is fairly low that
sensitive data will be swapped out to disk, because PGP doesn’t leave it in
memory for very long. Also, where possible, we try to ask the operating
system to lock that data in memory and not allow it to be swapped. But we
don’t make any guarantees.
This swap file can be accessed by anyone who can get physical access to your
computer. If you are concerned about this problem, you may be able to solve
it by obtaining special software that overwrites your swap file. Another
possible cure is to turn off your operating system’s virtual memory feature.
Microsoft Windows allows this, and so does the Mac OS. Turning off virtual
memory may mean that you need to have more physical RAM chips installed
in order to fit everything in RAM.
 
Zuletzt bearbeitet:
Lustiger Thread...

... ich hatte viel Spaß beim lesen. Aber der Titel ist definitiv falsch, da es auch ohne aktiviertes FileVault funktioniert.

Aber mal ein paar Anmerkungen auf das hier geschriebene:

1) Mal soeben einen Patch schreiben, daß die Swap-Files verschlüsselt abgelegt werden, kann man eigentlich vergessen. Swapping greift recht tief ins System ein, und ohne Performance-Verlust läßt sich da nichts mal aus die schnelle machen.

2) Definitiv ein Sicherheitsrisiko liegt vor, wenn man seinen Mac nicht richtig vor dem Zugriff von aussen schützt, während das gute Stück läuft. Denn dann kann der Fehler unter umständen wirklich ausgenutzt werden.

3) Wird der Rechner wirklich geklaut, kann man so und so nichts mehr machen. Es gibt so viele Wege dann an die Daten ranzukommen, mit gar nicht mal so großem Aufwand.

Ich habe solch eine Erfahrung in der Hochschule machen dürfen. Aufgabenstellung war, einen Password-Knacker zu schreiben, der auf Basis einer Wörterbuch-Attacke operiert. Getestet haben wir das Programm im Linux-Cluster anhand der Login-Passwörter in den yellow pages. Innerhalb einer Stunde hatte ich Zugriff auf 20 von ca. 800 Accounts, und das mit einfachen Wörtbuchdateien. Durch den zusätzlichen Einsatz von genetischen Algorithmen lassen sich so auch die berühmten Passwörter, die angeblich nicht in Wörterbüchern zu finden sind und Ziffern und Sonderzeichen enthalten, relativ leicht knacken.

Unter Windows ist es ebenso leicht: das Administrator-Passwort, das bei der Installation angegeben wird und zu 99,5% nicht mehr geändert wird, wird in einer Datei im System32-Verzeichnis abgelegt. Mit dem richtigen Tool ist es eine Sache von zwei bis drei tagen und man hat administrativen Zugriff auf die Machine. :(

Diese Liste läßt sich unendlich weiterführen. Wer glaubt, daß es ein System gibt, daß ihm selbst bei Diebstahl 100% Schutz liefert ist wirklich naiv. Selbst das zur Zeit sicherste BS OpenBSD schafft das nicht.

Nicht desto trotz muß Apple wegen dem Klartextpasswort was machen. Aber es ist kein Grund in Panik zu verfallen oder Apple zu verteufeln. Wenn ich mir die letzten Sicherheits-Audits für M$-Produkte ansehe, ist das Passwort Problem in Mac OS echt Kinderkram.
 
Ich habe nicht dagegen wenn findige Programmierer sich den zugriff auf meine daten verschaffen konnten, z.B. durch Brutforce Attacken, es sollte aber nicht sein das jeder "****-User" der gerade mal eine Tastatur bedienen kann ein 128Bit verschlüsseltes Verzeichnis einsehen kann weil die die Passworte im Klartext auf der Platte rumfliegen.
 
Agmemon schrieb:
Unter Windows ist es ebenso leicht: das Administrator-Passwort, das bei der Installation angegeben wird und zu 99,5% nicht mehr geändert wird, wird in einer Datei im System32-Verzeichnis abgelegt. Mit dem richtigen Tool ist es eine Sache von zwei bis drei tagen und man hat administrativen Zugriff auf die Machine. :(
Zwei bis drei Tage? Was machst du so lange, Kaffee kochen? Nee mal ganz im Ernst, das dauert sagen wir nicht mal 2 Minuten. Du bootest einfach ein Linux von CD und schon überschreibst du das Adminpasswort... Wenn du genaueres wissen möchtest dann PN an mich, das führt sonst hier zu weit.

xtian
 
Tzunami schrieb:
Ich habe nicht dagegen wenn findige Programmierer sich den zugriff auf meine daten verschaffen konnten, z.B. durch Brutforce Attacken, es sollte aber nicht sein das jeder "****-User" der gerade mal eine Tastatur bedienen kann ein 128Bit verschlüsseltes Verzeichnis einsehen kann weil die die Passworte im Klartext auf der Platte rumfliegen.

Und nochmal. Dieser "****-User" braucht trotzdem noch dein Admin-Kennwort.
 
moin!

Agmemon schrieb:
... ich hatte viel Spaß beim lesen. Aber der Titel ist definitiv falsch, da es auch ohne aktiviertes FileVault funktioniert.

was ist falsch mit dem titel? super auch, dass du spass hattest. darf ich fragen warum? bin mal gespannt auf dein fachwissen...

Agmemon schrieb:
1) Mal soeben einen Patch schreiben, daß die Swap-Files verschlüsselt abgelegt werden, kann man eigentlich vergessen. Swapping greift recht tief ins System ein, und ohne Performance-Verlust läßt sich da nichts mal aus die schnelle machen.

hast du mein weiter vorn verlinktes dokument gelesen? dort ist die implementierung unter openbsd beschrieben inkl. performancebetrachtung. was liegt näher, als die unter osx zu bringen?

Agmemon schrieb:
2) Definitiv ein Sicherheitsrisiko liegt vor, wenn man seinen Mac nicht richtig vor dem Zugriff von aussen schützt, während das gute Stück läuft. Denn dann kann der Fehler unter umständen wirklich ausgenutzt werden.

das sagt einem schon der gesunde menschenverstand. wer auf sein notebook nicht aufpaßt, hat pech. natürlich nur unter umständen :rolleyes:

Agmemon schrieb:
3) Wird der Rechner wirklich geklaut, kann man so und so nichts mehr machen. Es gibt so viele Wege dann an die Daten ranzukommen, mit gar nicht mal so großem Aufwand.

...beschreibung deiner erfahrungen folgen...

mir ist nicht ganz klar warum du äpfel mit birnen vergleichst. ich habe ein aes verschlüsseltes hd-images, optimalerweise mit einem guten passwort verschlüsselt, was noch nicht anderweitig benutzt wurde. welche chance hättest du ohne die lücke in fv, das ding anzugreifen? genetische algorithmen? klingt spannend, zeig mal her...
 
-Nuke- schrieb:
Und nochmal. Dieser "****-User" braucht trotzdem noch dein Admin-Kennwort.

Und nochmal. Der physikalische Zugriff auf die Platte reicht.
 
vuuduu schrieb:
Und nochmal. Der physikalische Zugriff auf die Platte reicht.

Der reicht sowieso IMMER. Das vom ihm genannte klingt aber so, als wenn jemand mal so la la den Befehl eingibt und fertig.

Da reicht meist auch ein simpler Passwort Sniffer, wie schon gesagt wurde. Heutige Rechner sind schon so Leistungsfähig, da macht ein Passwort von ein paar Stellen auch nix aus. Man tauscht das Login-System aus und nach ein paar Stunden, oder vielleicht ner Woche ist man drinnen.

Gerade bei einem G4/G5 mit Altivec geht das ratz fatz bei entsprechender Programmierung.

Wie viel Zeichen stehen zur Verfügung? 256 rein theoretisch. Praktisch sind es weniger. Mit etwas Zeichen-Optimierung (z.B. wenn man von ausgeht das du kein /\› oder sonst was drinnen hast), dann reduziert sich das immer weiter.
 
ach der direkte zugriff reicht also immer um ein verschlüsseltes Benutzerimage innerhab von 1 sekunde zu knacken? Na du musst ja ein echter Hecht sein.

Dann haben sich ja scheinbar alle Verschlüsslungsalgorithmusentwickler nicht bei ihrer entwicklung gedacht.

ach ja 256 (nicht ganz da die steuerzeichen wegfallen)Zeichen, bei 8 Zeichen sind das schon ca. 180000000000000000000 verschiedene Kombinationen und bei jedem neuen zeichen wird der vorherige wert MAL 256 genommen! >Ironie< da machen ja 1 oder 2 Zeichen mehr nichts, lol
 
Zuletzt bearbeitet:
vuuduu schrieb:
was ist falsch mit dem titel?

Sorry, nennen wir den Titel einfach ungenau. Bei dem Problem handelt es sich nicht um ein Problem mit FileVault, sondern mit dem Swapping. Aber unter dem Aspekt Fehler im Swapping => FileVault unsicher hast Du natürlich recht.

vuuduu schrieb:
hast du mein weiter vorn verlinktes dokument gelesen? dort ist die implementierung unter openbsd beschrieben inkl. performancebetrachtung. was liegt näher, als die unter osx zu bringen?

Den Artikel brauchte ich gar nicht lesen, da ich schon seid Jahren mit OpenBSD arbeite. Ich wollte mit meiner Aussage nur darauf hinaus, daß man nicht gerade mal auf die schnelle einen Patch schreiben kann, um verschlüsseltes Swapping zu bekommen, wenn man weiterhin Wert auf Performance legt. Für sowas muß man tief in den Darwin bsw. Mach Kern eingreifen. Und das kann Auswirkungen auf andere Komponenten haben, und weitere Arbeit mit sich bringen.

vuuduu schrieb:
das sagt einem schon der gesunde menschenverstand. wer auf sein notebook nicht aufpaßt, hat pech. natürlich nur unter umständen :rolleyes:

In der Sache verstehen wir uns ja :)

vuuduu schrieb:
mir ist nicht ganz klar warum du äpfel mit birnen vergleichst. ich habe ein aes verschlüsseltes hd-images, optimalerweise mit einem guten passwort verschlüsselt, was noch nicht anderweitig benutzt wurde. welche chance hättest du ohne die lücke in fv, das ding anzugreifen? genetische algorithmen? klingt spannend, zeig mal her...

Wenn ich in Besitz des Images komme, kann ich es auch angreifen. Je nach Angriffsart natürlich mit sehr hohem Zeit- und Ressourcenaufwand. Ob sich das lohnt, ist natürlich eine andere Frage. :)

Die genetischen Algorithmen, die ich ansprach, dienen zur leichten Mutation von normalen Wörterbüchern in andere oft vorkommende Schreibweisen. Steht z.B. in einem Wörterbuch das Wort Einstellungen, kann man dies mit genetischen Algorithmen sehr schön und einfach mutieren lassen, z.B. zu 31nst3llung3n, e1nstellungen, 31nst3llung3n, usw.

Das ist nur ein einfaches Beispiel, aber man kann mit genetischen Algorithmen noch viele andere schöne Sachen im Bereich Bruteforce machen, aber ich habe nicht vor hier eine Einührung in diese Algorithmen Art zu geben.

Wie dem auch sei, es steht einfach fest, daß es keine 100% Sicherheit in diesem Bereich gibt. Dennoch muß Apple sich was einfallen lassen, um den Fehler zu beheben.
 
Tzunami schrieb:
ach der direkte zugriff reicht also immer um ein verschlüsseltes Benutzerimage innerhab von 1 sekunde zu knacken? Na du musst ja ein echter Hecht sein.
Dann haben sich ja scheinbar alle Verschlüsslungsalgorithmusentwickler nicht bei ihrer entwicklung gedacht.
ach ja 256 (nicht ganz da die steuerzeichen wegfallen)Zeichen, bei 8 Zeichen sind das schon ca. 180000000000000000000 verschiedene Kombinationen und bei jedem neuen zeichen wird der vorherige wert MAL 256 genommen! >Ironie< da machen ja 1 oder 2 Zeichen mehr nichts, lol

Du verstehst das jetzt falsch. Dabei wird nicht versucht den Key zu knacken, sondern versucht das Passwort ZUM Key zu bekommen. Von einer Sekunde sagte ich nix.

Die Zahl die du da sagst klingt zwar groß, aber für einen Computer ist das doch nicht viel. Besonders bei den Takten von heute.

Die Methode die wegfällt ist den Key zu bekommen. D.h. die Verschlüsselung zu knacken. Aber wozu, wenn der Key auf der Platte liegt?
 
ach der direkte zugriff reicht also immer um ein verschlüsseltes Benutzerimage innerhab von 1 sekunde zu knacken? Na du musst ja ein echter Hecht sein.

Man braucht es doch gar nicht vor Ort knacken. Davon spricht ja keiner. Wenn ich aber an die Maschine rankomme und mir dann die nötigen Files irgenwo hin kopiere (zum Beispiel auf meinen iPod), kann ich das zu Hause in aller Ruhe knacken. Wenn in dem Image dann nur Nullbytes waren ist das natürlich Pech, aber wenn nicht, dann freue ich mich unter Umständen.
 
-Nuke- schrieb:
Gerade bei einem G4/G5 mit Altivec geht das ratz fatz bei entsprechender Programmierung.

. . . ähem: Symmetrische Krypto-Algorithmen im allgemeinen und AES (aka Rijndael) im besonderen sind mathematisch zu 100% aus Integer (oder gar reinen Bit-Operationen) zusammengesetzt, schon allein damit sie auch auf einfachen Smart-Cards in erträglicher Geschwindigkeit laufen können.

Altivec (aka VMX) beschleunigt aber nur FloatingPoint Operationen.
Weitere Infos hier.
Diesmal gibts keinen weiteren Vortrag ;)


Gruß,

?=?
 
Agmemon schrieb:
... ich hatte viel Spaß beim lesen. Aber der Titel ist definitiv falsch, da es auch ohne aktiviertes FileVault funktioniert.

Das ändert nichts daran dass die Aussage im Titel korrekt ist.

1) Mal soeben einen Patch schreiben, daß die Swap-Files verschlüsselt abgelegt werden, kann man eigentlich vergessen.

OS X enthält bereits Unterstützung für verschlüsselte Images, die Verschlüsselung auch für das Swapfile nutzbar zu machen ist keine allzu große Sache.

2) Definitiv ein Sicherheitsrisiko liegt vor, wenn man seinen Mac nicht richtig vor dem Zugriff von aussen schützt, während das gute Stück läuft. Denn dann kann der Fehler unter umständen wirklich ausgenutzt werden.

Der Fehler kann auch bei ausgeschaltetem Gerät ausgenutzt werden, da OS X die Swapfiles beim Runterfahren nicht überschreibt.

3) Wird der Rechner wirklich geklaut, kann man so und so nichts mehr machen. Es gibt so viele Wege dann an die Daten ranzukommen, mit gar nicht mal so großem Aufwand.

Falsch. Wenn alle Daten mit einem einem bauchbaren Algorithmus und einem ausreichend langen Schlüssel verschlüsselt sind kommt niemand ran.

Ich habe solch eine Erfahrung in der Hochschule machen dürfen. Aufgabenstellung war, einen Password-Knacker zu schreiben, der auf Basis einer Wörterbuch-Attacke operiert.

Äh... deine Hochschulerfahrungen in Ehren, aber AES mit vernünftig langem Schlüssel lässt sich nicht in ein paar Jahren knacken.
 
?=? schrieb:
. . . ähem: Symmetrische Krypto-Algorithmen im allgemeinen und AES (aka Rijndael) im besonderen sind mathematisch zu 100% aus Integer (oder gar reinen Bit-Operationen) zusammengesetzt, schon allein damit sie auch auf einfachen Smart-Cards in erträglicher Geschwindigkeit laufen können.

Altivec (aka VMX) beschleunigt aber nur FloatingPoint Operationen.
Weitere Infos hier.
Diesmal gibts keinen weiteren Vortrag ;)


Gruß,

?=?

Ich rede ja auch nicht von Key-Knacken, sondern von Passwort sniffen.

Lesen, dann meckern. ;)

Übrigens beschleunigt Altivec nicht nur Floating-Point. Für reines Floating-Point ist es sogar denkbar unangebracht, da eine Vector-Variable nur 32bit zur Verfügung steht statt 64bit.

Trotzdem noch mal zum Key-Knacken:
http://www.distributed.net/rc5/

Macs rasen dort allen Rechnern weg, dank Altivec.

Zum Altivec:

AltiVec technology operations are performed on multiple data elements by a single instruction. This is often referred to as SIMD (single instructions, multiple data) parallel processing. AltiVec technology offers support for:

16-way parallelism for 8-bit signed and unsigned integers and characters
8-way parallelism for 16-bit signed and unsigned integers
4-way parallelism for 32-bit signed and unsigned integers and IEEE floating-point numbers

http://www.freescale.com/webapp/sps/site/overview.jsp?nodeId=018rH3bTdGmKqW5Nf2hG12

http://developer.apple.com/hardware/ve/

In den Apple-Librarays gibt es dann noch Methoden um 1024bit-Operationen durchzuführen. Dort werden dann Register zusammengeschaltet.
 
Zuletzt bearbeitet:
langen Schlüssel verschlüsselt sind kommt niemand ran.
Innerhalb eines vernünftigen Aufwandes. Wo ein Wille ist, ist auch ein Gebüsch, ähh, Weg...

Aber wie wir bereits bemerkt haben müssen wir das Swapfile doch gar nicht verschlüsseln. Den Bereich vom Swapping auszunehmen reicht doch vollkommen. Ein anderer Ansatz wäre auch das Swapfile beim runterfahren zu löschen und beim hochfahren den Bereich in aller Ruhe mit sinnfreien Werten (wie beispielsweise Teile diesen Threads) zu überschreiben. Vielleicht kann man ja anstatt des Löschvorgangs ein Fakefile erstellen, welches den Anschein erweckt das ursprüngliche Swapfile zu sein. Das kann man ja auch locker miteinander kombinieren.
 
Agmemon schrieb:
Unter Windows ist es ebenso leicht: das Administrator-Passwort, das bei der Installation angegeben wird und zu 99,5% nicht mehr geändert wird, wird in einer Datei im System32-Verzeichnis abgelegt. Mit dem richtigen Tool ist es eine Sache von zwei bis drei tagen und man hat administrativen Zugriff auf die Machine. :(
Wenn du davor stehst ist es eine Sache von 2 Minuten. Ich musste das leidvoll erfahren, denn ich hab bei nem win2k mal den Administartor umbenannt und da hatte sich ein Tippfehler eingschlichen. Durch die Doppeleingabe des Passoworts war ich relativ sicher, dass der Nutzername falsch war, doch sämtliche möglichen Flüchtigkeitsschreibfehler austesten? ...rechne, rechne, NEIN, zu viele Möglichkeiten! ;)
Es bedurfte nur zwei Minuten, um ein Tool zu finden welches das einsehen/ändern aller Zugangsdaten für Win2k/Xp von Linux-Disk ermöglicht, die Disk zu erstellen, zu booten und gut ist... Der Benztzer war übrigens 'Werkszatt' statt 'Werkstatt' :D
 
-Nuke- schrieb:
Ich rede ja auch nicht von Key-Knacken, sondern von Passwort sniffen.
Wozu brauch ich beim sniffen Altivec (=Rechenleistung), bzw. was verstehst du darunter?
Ich bin von einer Dictionary-Attack ausgegangen, bei der die primäre Aufgabenstellung darin liegt, möglichst schnell möglichst viele (wahrscheinliche) Schlüssel zum entschlüsseln auszuprobieren (und festzustellen, ob der gerade benutzte Schlüssel der richtige war).

-Nuke- schrieb:
Übrigens beschleunigt Altivec nicht nur Floating-Point . . .
Korrekt. Hab wirklich zu schnell gepostet (Hatte primär das Fazit eines anderen Artikels im Kopf als ich es geschrieben habe) ;)


Gruß,

?=?
 
Zuletzt bearbeitet:
andreas-s schrieb:
OS X enthält bereits Unterstützung für verschlüsselte Images, die Verschlüsselung auch für das Swapfile nutzbar zu machen ist keine allzu große Sache.

Das ist schön, dass OS X verschlüsselte Images unterstützt. Und weiter :confused:

OS X legt bei der Installation ein 1 GB großes verschluesseltes Image auf der Platte an, mit festem Password, das irgendwie auf Basis einer Information des Rechners (z.B. SN) generiert wird? Beim Start wird das Image dann gemountet und beim Herunterfahren wieder beendet?

Dann haben wir das gleiche Problem wie vorher.

Es gibt nur zwei Möglichkeiten: Entweder die entsprechenden Speicherinhalte, um die es hier geht, dürfen nicht geswappt werden, oder das Swapping muß ansich verschlüsselt ablaufen. Beide Vorgehensweisen greifen tief in das System ein.

Um zu verhindern, daß sicherheitsrelevenate Daten nicht auf die Platte ausgelagert werden dürfen, muß man beim Paging ansetzen, sprich es müßte ein weiteres Kennzeichen in den Seitentabellen eingefügt werden, was eine tiefgreifende Änderung im Speichermanagment darstellen würde.

Wenn das Swapping ansich verschlüsselt vor sich gehen soll, muß zwischen Paging und Swapping Mechanismus (ich habe vergessen, wie die zugehörige Instanz heißt) ansetzen und hier die Daten ent- bzw. verschlüsseln, am besten mit zufälligem Session-Key.
 
Zurück
Oben Unten