OS X Vorschlag Countermeasure Frozen RAM-Attacke

[SilentCry]

Wer meine Paranoia thematisieren will, soll hier her gehen. In diesem Thread hätte ich gerne Meinungen zu meinem Lösungsvorschlag und falls als gut empfunden, Wege, diesen Vorschlag an Apple zu bringen.

Kurz: Es geht um das Frozen RAM-Problem, also (http://citp.princeton.edu.nyud.net/pub/coldboot.pdf)

Zusammengefasst: Ein Computer, der läuft oder der im S3-Modus (Standby) ist und eine transparente Verschlüsselung verwendet (wie FileVault) kann dem Anwender entzogen werden, der Speicher mit handelsüblichem Spray auf bis zu -50 Grad abgekühlt werden und danach kann ein Speichabbild gezogen werden auch wenn der Speicher vom Strom getrennt wurde. Minutenlang hält der gekühlte Speicher seine Daten praktisch fehlerfrei. Mit flüssigem Stickstoff lässt sich die Zeit erheblich dehnen.
Aus dem Speicherabbild kann dann in Ruhe jedweger Encryption-Key extrahiert werden.
Wichtig: Es ist irrelevant ob man den Zielrechner benutzen kann oder nicht, der Speicher kann ausgebaut und in einem Rechner, der schon unter der Kontrolle des Angreifers steht ausgelesen werden.
Mit diesem Passwort lassen sich nun verschlüsselte Laufwerke bzw. Containerfiles einfach öffnen.​

Mein Ansatz:
Man setzt am Mac das OpenFirmware-Passwort. Dieses Passwort wird dazu benutzt, im Betrieb sämtliche Nutzerpasswörter im Speicher zu verschlüsseln. Dazu muss natürlich das OF-PWD im Speicher gehalten werden (noch besser wäre ein anderer Ort wie zB. Prozessorcache oder dgl. aber wir wollen nicht zu weit gehen).
Wenn der Rechner in S3 (sleep) geschickt wird, wird das OF-PWD aus dem Speicher gelöscht. Das geht, denn im S3 muss der Rechner ja keine Aufgaben mehr wahrnehmen (im Gegensatz zum Screensaver-Mode, zu dessem Schutz ich keine Idee habe).
Wird der Rechner wieder aufgeweckt, muss der Anwender das OF-PWD wieder eingeben, vorher kann der S3-Mode nicht beendet werden.

Der Aufwand:
Apple muss kleine Teile des OS X reprogrammieren.
Apple muss vermutlich ein EFI-Firmwareupdate ausgeben für alle Rechner.

Vorteil:
Wenige Änderungen, läuft auf bestehender Hardware (ggf. Firmware Update) und kann über ein normales Servicepack eingespielt werden. Der S3-Mode wäre dann wieder sicher. Das OF-PWD ist wegen "Attack with fire(wire)" sowieso Pflicht und die Lösung ist mehrbenutzerfähig.

Nachteil:
Apple muss das machen.

Ich habe alternativ den Autor von "sleep watcher" angeschrieben, ob er dieses Tool erweitern kann um das PWD eines bestimmten User aus dem Speicher zu werfen und vor dem Beenden von S3 vom Anwender abzufragen. Der Vorteil wäre, dass man nicht auf Apple warten müsste. Nachteil: Vielleicht geht es nicht und wenn doch dann nur für einen User.

Was haltet Ihr davon, bzgl. Machbarkeit und Usability? M.E. würde das das Frozen RAM-Problem für S3 beseitigen, wie seht Ihr das?
Und: Wie würde man das an Apple kommunizieren, ist vielleicht jemand hier, der einen guten Zugang zu Apple hat (Developer oder diese zertifizierten Apple-Trainer oder dgl.)?

 

[Macbeatnik]

ohne jetzt direkt auf das Thema einzugehen, aber das OpenFirmwarePasswort als Pflicht anzusehen ist angesichts des leichten umgehens des Firmwarepasswortes(das leichte Umgehen ist auch sinnvoll) doch etwas blauäugig oder?

 

[SilentCry]

ohne jetzt direkt auf das Thema einzugehen, aber das OpenFirmwarePasswort als Pflicht anzusehen ist angesichts des leichten umgehens des Firmwarepasswortes(das leichte Umgehen ist auch sinnvoll) doch etwas blauäugig oder?

Es geht um das Verhindern der Firewire-Attacke (zB: http://www.ccc.de/congress/2004/fahrplan/files/95-macosx-insecurity-paper.pdf). (Also Abziehen eines MemoryDump via Firewire DMA-Mode). Wenn jemand das OF-PWD ausknipsen will, hat er keinen Memoryinhalt mehr, den er damit abziehen würde wollen. OF-PWD ist m.E. auf jeden Fall Pflicht. (Siehe Seite 18 der CCC-Präsentation hier: http://events.ccc.de/congress/2006/Fahrplan/attachments/1244-23C3VileFault.pdf)

Und nun bitte, zum Thema zurück. _Bitte_

 

[ImperatoR]

Eine wirklich gute Überlegung, man sollte es wirklich versuchen Apple vorzuschlagen!

 

[SilentCry]

So. Also der Macher von sleep watcher hat kein Interesse daran, sein Programm dahingehend zu modifizieren. Die Schiene kann ich also vergessen.

Hat hier jemand einen Zugang zu Apple, um meine Idee einzukippen?

 

[MacMark]

Bugreporter auf Apples Seite

 

[Bier]

Zugang ja, aber ich halte die Idee für blöd. Ich kann ja mal nachfragen, ob Apple Deutschland Dich einläd bei der nächsten Konferenz in München

Leg Dir dazu am ehesten Mal ne Website zu, dann beschreib das Ganze technisch ernstzunehmend: Implementation, Code... und konkret. Der Rest ist dann eine Frage der Überzeugungsenergie. So in nem Forum daherschreiben kann jeder.

 

[SilentCry]

Zugang ja, aber ich halte die Idee für blöd. Ich kann ja mal nachfragen, ob Apple Deutschland Dich einläd bei der nächsten Konferenz in München

Warum hältst Du die Idee für blöd?

Leg Dir dazu am ehesten Mal ne Website zu, dann beschreib das Ganze technisch ernstzunehmend: Implementation, Code... und konkret. Der Rest ist dann eine Frage der Überzeugungsenergie. So in nem Forum daherschreiben kann jeder.

Interessanter Ansatz. An sich allerdings nur dazu geeignet, jemanden mundtot zu machen, frei nach dem Motto: Wenn Du es nicht coden kannst, darfst Du es Dir auch nicht ausdenken. Oder wie soll ich das sonst verstehen? Und warum soll ich mir erst einen Webseite machen? Wen soll ich damit beeindrucken? Apple?

Natürlich bin ich unendlich weit weg davon, das selbst kodieren zu können. Unerfreulicherweise muss ich meine Lebenszeit nämlich mit einem Job vergeuden, der mir Geld bringt, ich kann nicht die Entwicklungsarbeit Apples in meiner Freizeit übernehmen.
Ich kann nur beschreiben, wie es funktionieren soll. Das halte ich auch für völlig zulässig. Ich war vor einiger Zeit zuständig für die Entwicklung eines Gatewayprogrammes, das "meine" Firma von einem Drittanbieter coden ließ. Von uns ist das BackEnd-System gekommen und die Turnkey-Applikation, die Middleware vom Drittanbieter. Denen habe ich auch gesagt, _was_ funktionieren soll und _die_ haben es codiert. Dafür waren sie da.

 

[Bier]

Kodieren = Verschlüsseln
Coden = slang Programmieren
slang Code = Source

Die Masse der Informatik Studenten kann nicht Programmieren. Dann mach Pseudocode, oder zeichne Diagramme, Konzepte, schreib einen Algorithmus, oder weise die Turing Vollständigkeit Deines Problems nach. Wenn Du das kannst... ich halte die Idee für technisch sinnlos.

Hat drei Gründe:

1. bringt wenig - der RAM ist aus dem laufenden System entfernbar - ohne, dass die beschriebenen Prozesse benutzt werden.
2. RAM Verschlüsselung ist eine sehr schlechte Idee, da Du den Key irgendwo lagern musst. So, wie Du es beschreibst, im CPU Cache: absoluter Humbug. Aber he... Einstein hat man auch nachgesagt, er seie nicht der Hellste.
3. So unkonkret interessieren diese Ideen... niemanden. entweder Du hast ein Konzept aus der Wirklichkeit, oder einfach zu viel Phantasie. Letzteres hat die Masse der Leute, ersteres nur wenige.

 

[SilentCry]

Die Masse der Informatik Studenten kann nicht Programmieren. Dann mach Pseudocode, oder zeichne Diagramme, Konzepte, schreib einen Algorithmus, oder weise die Turing Vollständigkeit Deines Problems nach. Wenn Du das kannst... ich halte die Idee für technisch sinnlos.

Ich habe schon eine ganze Menge programmiert. Nur halt nicht die letzten 10 Jahre, Konzernschaden halt. Egal. Auch wenn ich ein hervorragendes aktives Programmierschweinchen wäre, das wäre auf jeden Fall ein unmachbares Projekt für mich als Individuum - nichtmal ein bei Apple arbeitendes welches.

1. bringt wenig - der RAM ist aus dem laufenden System entfernbar - ohne, dass die beschriebenen Prozesse benutzt werden.

Deckel zu. OF-PWD ist aus dem Speicher raus. Du hast natürlich Recht dass es gegen eine laufende Maschine (zB. mit Screensaver) nichts nutzt. Aber den S3 (sleep) kann man so komplett absichern.

2. RAM Verschlüsselung ist eine sehr schlechte Idee, da Du den Key irgendwo lagern musst. So, wie Du es beschreibst, im CPU Cache: absoluter Humbug. Aber he... Einstein hat man auch nachgesagt, er seie nicht der Hellste.

Das mit dem CPU-Cache vergiss. Warum müssen sich Menschen auf Nebensätzen festbeissen, wenn es um eine wesentlich andere Idee geht?
Das OF-PWD muss natürlich während des Betriebes im Speicher sein. (Über das Problem kommen wir kaum herum.) Aber das OF-PWD kann (und soll) aus dem Speicher gelöscht werden, wenn der Rechner in S3 geht. Ganz einfach. Dann liegen nur noch die OF-PWD-verschlüsselten Userpasswörter im Speicher und ein Angreifer, der das Book im S3 klaut kann es sich das RAM wohin schieben, mit den OF-kodierten Passwörtern fängt er ohne OF-PWD nichts an und das OF-PWD ist ja nicht mehr im Speicher, weil es mit Wechsel in S3 rausgelöscht wurde.

Wenn der S3 beendet wird muss als erstes eben das OF-PWD abgefragt werden, vom Anwender.

Danke übrigens für den Vergleich mit Einstein.

3. So unkonkret interessieren diese Ideen... niemanden. entweder Du hast ein Konzept aus der Wirklichkeit, oder einfach zu viel Phantasie. Letzteres hat die Masse der Leute, ersteres nur wenige.

Die Idee ist absolut konkret. Apple muss OS X und wahrscheinlich das EFI so abändern, dass sich der S3-Mode so verhält wie ich beschrieb. Weiters muss es im Betriebssystem die Funktion des Verschlüsselns der Userpwds mit dem OF-PWD einbauen. Konkreter geht es nicht, alles weitere ist Apples Aufgabe.
Eigentlich wäre auch diesen Lösungsansatz zu erdenken Apples Aufgabe, aber da kann ich noch helfen, ohne mich für einen Job als Chief Software Development Architect bei Apple zu bewerben (der Titel ist frei ersonnen).

Du wirfst mir nur vor, meine Idee sei nicht konkret. Dagegen kann ich nur halten: Meine Idee _ist_ konkret. Dass die Umsetzung bei Apple liegt, habe ich von Anfang an geschrieben.

 

[Bier]

http://developer.apple.com/contact/

- dies wäre die erste Anlaufstelle.

Weiterhin: http://developer.apple.com/mac/
Es wäre empfehlenswert das Material vorher zu lesen.

Und wenn Du meinst: http://developer.apple.com/students/mail.html oder eben http://lists.apple.com/; es gibt auch interne Listen.

Da werden sie geholfen... denk ich Viel Spaß! Und lass Dich von mir nicht bremsen. Ich hab nur eine Meinung...

The mailing lists hosted on lists.apple.com are for users and developers to communicate with each other. By joining these lists, you can share experiences, questions, and comments with others. While Apple employees monitor the lists, Apple doesn't guarantee that questions will be answered. The mailing lists are not a replacement for formal support or bug reporting procedures. The lists are used for informal communication and Apple cannot commit to fixes or responses to postings on any of the mailing lists.

http://lists.apple.com/archives/boot-dev - das wäre die Liste für Dein konkretes Problem.

 

[MacMark]

http://bugreporter.apple.com

 

[Bier]

Stimmt, das besser. Dann brauch er nich konkret was zu wissen *duck*

 

[SilentCry]

Danke Euch beiden!

 

[SilentCry]

[...]ich halte die Idee für technisch sinnlos.
[...] 2. RAM Verschlüsselung ist eine sehr schlechte Idee, da Du den Key irgendwo lagern musst. So, wie Du es beschreibst, im CPU Cache: absoluter Humbug. Aber he... Einstein hat man auch nachgesagt, er seie nicht der Hellste.

Ich wollte, mit etwas Selbstgefälligkeit, ja, darauf hinweisen dass meine Idee ach so sinnlos nicht war:
http://www.heise.de/security/Abhilf...rch-gekuehlten-Speicher--/news/meldung/122003

Apple bzw. Hersteller von Fulldisk-Encryption für OS X (PGP Desktop und Checkpoint) müssten das "nur" noch implementieren.

 

[ImperatoR]

Gab es seitens Apple eine Rückmeldung oder wurde es gar schon implementiert?