Wie sicher ist das RAM?

  • Wie sicher ist das RAM?

    Tach,

    das ist quasi eine Folgefrage zu Klaus' Vortrag auf der Macoun (iOS Sicherheit).

    Es geht mir um die Frage, wie man Benutzergeheimnisse vernünftig (also am besten sicher und komfortabel) handhabt. Wie sieht es da eigentlich mit dem RAM aus?

    Es gab (in dem Vortrag) z.B. das (negative) Beispiel von der Banking-App, die eine TAN-Liste auf dem Dateisystem entschlüsselt, wenn sie gestartet wird und wieder verschlüsselt beim Beenden. Mit iOS4 kam der Hintergrundbetrieb und die Ungewissheit des tatsächlichen Beendens und damit die Gefahr, dass die TAN-Liste unverschlüsselt in einem iTunes Backup landet. Ich verstehe irgendwie nicht, warum diese TAN-Liste überhaupt je unverschlüsselt im Dateisystem existieren muss. Warum werden die unverschlüsselten Daten nicht einfach im RAM gehalten? Dann sind sie automatisch weg, wenn die App beendet wird. Falls man dann noch Bedenken hat, dass der Speicher unverändert einer anderen App zufällt, kann man ja immer noch beim Beenden die Strings komplett nullen oder so, aber wer um alles in der Welt kommt denn auf die Idee, unverschlüsselte Daten ins Dateisystem zu schreiben? Der RAM-Inhalt interessiert doch bei einem iTunes Backup nicht, oder?

    Andere Stelle, gleiches Thema: Keychain. Allerdings mit einer Einschränkung: ich denke hier an eine permanent laufende App (Musikabspieler, Routenplaner, VoIP, ...). Wenn die ihre Geheimnisse anfangs aus der Keychain holt und im RAM in ein Dictionary einlagert, ist sie hinterher unabhängig von den lustigen Schutzklassen der Keychain (always, when unlocked, when einmal unlocked, ...). Sie hat die Geheimnisse ja sowieso in ihrem lokalen Cache (im RAM), also kann sie grundsätzlich die stärkste Klasse "when unlocked" in der Keychain nutzen, am Anfang von dort laden und ab dann immer den lokalen Cache nutzen und so trotzdem im gelockten Zustand darauf zugreifen.

    Die Frage ist: wie sicher sind die Daten im RAM wirklich? Gibt es unter iOS sowas wie eine Swap-Partition? Eine Auslagerungsdatei?

    Ich frage, weil ich es einfach nicht weiß.

    Danke!

    PS: Jailbreaks lassen wir mal beiseite. Da ist dann eh kein Kraut gewachsen.

  • iOS unterstützt virtuellen Speicher, swappt aber keinen veränderten Arbeitsspeicher raus. Es werden höchstens Read-Only-Pages rausgeworfen und bei Bedarf wieder geladen (Doku: hier).

    Auch RAM ist nicht hundertprozentig sicher - Computerforensiker können RAM selbst kurze Zeit nach dem Ausschalten noch rekonstruieren. Es geht eher darum, möglichen Angreifern die Arbeit nicht unnötig zu erleichtern. Geheimnisse im Klartext in ein Dateisystem zu schreiben oder unnötig viel oder unnötig lange zu halten gehört zu da zu den schlechteren Ideen.
    Multigrad - 360°-Produktfotografie für den Mac

  • Amin Negm-Awad schrieb:

    Wenn du Jailbreaks beiseite lässt, dann existiert auch kein Problem auf Dateiebene.
    Öhm. Doch. Siehe oben unter Stichwort: iTunesBackup. Außerdem geht es dann ja noch um den Fall, dass man das Gerät verliert und ein Bösewicht sich dann an dem Gerät zu schaffen macht. Was im Flash ist, bleibt da, was im RAM ist, ist theoretisch weg. Für die Bootloader-Geschichte muss der Bösewicht das Gerät ja auch mindestens einmal booten, oder? Oder gibt es eine Möglichkeit das Gerät ohne Reboot zu rooten? Ich hab von Jailbreaks absolut keinen Schimmer, sorry.

    mattik schrieb:

    Auch RAM ist nicht hundertprozentig sicher - Computerforensiker können RAM selbst kurze Zeit nach dem Ausschalten noch rekonstruieren.
    Das ist natürlich ein Argument. Allerdings ist dieser Angriffsvektor ziemlich kurz und dünn, wenn ich das mal so sagen darf. ;)

    mattik schrieb:

    Es geht eher darum, möglichen Angreifern die Arbeit nicht unnötig zu erleichtern.
    Exakt! Und da ist jetzt also meine Frage, ob das (super-einfache) Cachen der Geheimnisse im RAM (was weiß ich, ein NSMutableDictionary im AppDelegate oder so) nicht sogar sicherer ist, als die Daten in der Keychain zu belassen und sie bei Bedarf auszulesen, weil man aber auch im gelockten Zustand da ran will (App im Hintergrund aktiv) dann das kSecAttrAccessibleAfterFirstUnlock Attribut zu nutzen.


    Also:
    kSecAttrAccessibleWhenUnlocked > RAM > kSecAttrAccessibleAfterFirstUnlock
    oder
    kSecAttrAccessibleWhenUnlocked > kSecAttrAccessibleAfterFirstUnlock > RAM
    ???

    Man könnte die Daten im Dictionary ja ordentlich zufällig gesalzen auch mit CCCrpyt() verschlüsselt halten?

  • Was im RAM ist, ist nur theoretisch weg und praktisch nach dem Start der Applikation wieder da.

    Und nach einem physischen Zugriff dürfte es ziemlich gleichgültig sein, ob das unverschlüsselt im RAM oder in einer Datei liegt. Gut, Datei ist vielleicht etwas einfacher. Keine Ahnung, wie es auf dem iPhone ist, aber auf dem Mac war es nach einem physischen Zugriff grandios einach, alle Passwörter zu loggen. Dieser Zutritt funktioniert zwar nicht bei einem iPhone, aber die Einfallstore swaren extrem einfach. Müsste ich eigentlich mal probieren, ob es unter 10.7 immer noch geht.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Amin Negm-Awad ()

  • Ok. Wenn man also als im Hintergrund laufende App unter iOS an ein Geheimnis muss, selbst wenn das Gerät gelockt ist, ist es also sicherer die Geheimnisse in der Keychain zu belassen und mit kSecAttrAccessibleAfterFirstUnlock zu kennzeichnen und dann bei Bedarf direkt aus der Keychain auszulesen, als sie mit kSecAttrAccessibleWhenUnlocked in der Keychain zu halten und beim Start der App komplett ins RAM vorzuladen?

    Ich erinnere mich in Klaus' Vortrag an eine Folie, in der rot (=böse?) dargestellt wird, dass iOS z.B. die WLAN-Schlüssel mit kSecAttrAccessibleAfterFirstUnlock speichert. Wie soll das denn sonst funktionieren, wenn ein gelocktes Gerät sich im Hintergrund in ein bekanntes WLAN einbuchen soll (klassicher Fall: ich komme von der Arbeit nach Hause und das iPhone schlummert gelockt in der Tasche)?

    Ich will es ja nur richtig verstehen (und dann richtig machen). ;)

    Danke für die Ideen!

  • zerm schrieb:

    smk schrieb:

    Oder gibt es eine Möglichkeit das Gerät ohne Reboot zu rooten?

    Gab es, wenn ich mich recht erinnere - und man wird es kaum ausschliessen können, dass es das nicht wieder geben wird.
    Korrekt. jailbreakme.com hat den Jailbreak ohne Reboot installiert. Ist in der Regel nicht notwendig. Reboot ist beim physischen Angriff über den BootROM-Bug notwendig, da der Angreifer einen Kernel mit SSHD booten muss.

  • smk schrieb:

    Ok. Wenn man also als im Hintergrund laufende App unter iOS an ein Geheimnis muss, selbst wenn das Gerät gelockt ist, ist es also sicherer die Geheimnisse in der Keychain zu belassen und mit kSecAttrAccessibleAfterFirstUnlock zu kennzeichnen und dann bei Bedarf direkt aus der Keychain auszulesen, als sie mit kSecAttrAccessibleWhenUnlocked in der Keychain zu halten und beim Start der App komplett ins RAM vorzuladen?

    Ich erinnere mich in Klaus' Vortrag an eine Folie, in der rot (=böse?) dargestellt wird, dass iOS z.B. die WLAN-Schlüssel mit kSecAttrAccessibleAfterFirstUnlock speichert. Wie soll das denn sonst funktionieren, wenn ein gelocktes Gerät sich im Hintergrund in ein bekanntes WLAN einbuchen soll (klassicher Fall: ich komme von der Arbeit nach Hause und das iPhone schlummert gelockt in der Tasche)?

    Ich will es ja nur richtig verstehen (und dann richtig machen). ;)

    Danke für die Ideen!
    Beide Vorgehensweisen decken unterschiedliche Angriffsvektoren ab. Das Verschlüsseln der Keychain-Einträge dient zum Schutz vor unbefugtem Zugriff auf die Keychain. Der unbefugte Zugriff auf den Speicher ist ein anderer Angriffsvektor. Und er setzt voraus, dass ein Angreifer Zugriff auf den Speicher hat. Das kann entweder über einen Jailbreak passieren (daher Jailbreak-Detection implementieren) oder - wie Mattik schon schrieb - durch physischen Zugriff. Diese Möglichkeit mag akademisch erscheinen, aber man braucht ja zurzeit nur $ZEITUNG aufzuschlagen, um zu lernen, wie das mit dem Infizieren von IT-Systemen über physischen Zugriff ("Staatstrojaner") funktioniert. Das ist nicht nur ein theoretischer Angriff. Auch ist das Auslesen von RAM ausgeschalteter oder im Standby befindlicher Systeme erfolgreich möglich.

    Interessanter Link zum Thema Datenschnorcheln auf Smartphones durch phyischen Zugriff.

    ABER: Alle Schutzmaßnahmen müssen in angemessenem Rahmen zum Schutzbedarf der Daten und der Wahrscheinlichkeit eines Angriffs stehen. Wenn Du die iOS-eigenen Schutzmechanismen korrekt verwendest, bist Du in 98% der Fälle auf der sicheren Seite. Ob Deine App noch 1% mehr braucht, ist in der Regel unwahrscheinlich. Das letzte 1% kriegst Du eh nicht dicht. Natürlich kannst Du mit RAM-Encryption arbeiten, aber erstens ist die Wahrscheinlichkeit, dass Du Dir dabei selber in den Fuß schießt, ziemlich groß, zum anderen musst Du Dir die Frage stellen, gegen welche Bedrohung das wirken soll.

    Bei solchen Anwendungsfällen kann der Aufwand zur Sicherung hingegen nicht groß genug sein. Aber das dürfte eher die Ausnahme sein.



    Zu den Folien: rot != böse. Das stellt nur die am wenigsten restriktive Lösung dar, und da sollte man sich die meisten Gedanken machen, ob man sie braucht.

  • Amin Negm-Awad schrieb:

    Wenn du Jailbreaks beiseite lässt, dann existiert auch kein Problem auf Dateiebene.
    Richtiger formuliert: Wenn alle von Apple vorgesehenen Schutzmechanismen funktionieren, existiert kein Problem auf Dateiebene.

    Und was wir heute als Jailbreak bezeichnen, werden wir morgen als Schadsoftware sehen. Das ist keine Frage des "ob", sondern des "wann".

  • Ok. Dankeschön!

    Wenn ich die Geheimnisse also immer nur bei Bedarf aus der Keychain hole und sonst gar nicht im RAM halte, dann fällt der RAM-Auslese-Angriffsvektor ja schonmal weg. Aber wegen der Notwendigkeit auch im gesperrten Zustand die Geheimnisse auslesen zu können, muss man ja dann zu kSecAttrAccessibleAfterFirstUnlock greifen. Obwohl man dann auf der nächsten Folie zu den roten (!(rot->böse)) gehört ... ;)

  • smk schrieb:

    Ok. Dankeschön!

    Wenn ich die Geheimnisse also immer nur bei Bedarf aus der Keychain hole und sonst gar nicht im RAM halte, dann fällt der RAM-Auslese-Angriffsvektor ja schonmal weg. Aber wegen der Notwendigkeit auch im gesperrten Zustand die Geheimnisse auslesen zu können, muss man ja dann zu kSecAttrAccessibleAfterFirstUnlock greifen. Obwohl man dann auf der nächsten Folie zu den roten (!(rot->böse)) gehört ... ;)
    Ja. Wobei sich bei "normalen" Apps ja durchaus die Frage stellen darf, warum die im gesperrten Zustand auf die Daten zugreifen sollen - das dürfte eher die Ausnahme sein. Vielmehr Augenmerk würde ich da auf die thisDeviceOnly-Direktiven legen. Die Frage, welche Daten einen Gerätewechsel überdauern müssen, ist nicht nur aus Sicherheitsgründen interessant, sondern ggf. auch aus Lizensierungsgründen.