Daten vom Kernel verschlüsseln lassen - gibt's schon APIs dafür?
-
Die ganze Spectre Sache würde mMn. weit weniger problematisch, wenn Anwendungen vertrauliche Daten grundsätzlich verschlüsselt im Speicher halten würden. Also ausgenommen für die (meist kurze) Zeit wo die Daten unverschlüsselt benötigt werden - und danach sofort wieder überschreiben/verschlüsseln.
Natürlich darf auch der Key nicht ausgelesen werden können.
Wenn wir mal einen Meltdown Fix voraussetzen, und ebenfalls voraussetzen dass der Kernel gegen Spectre "gehärtet" wird, dann könnte man den Key ja einfach im Kernel Speicher vorhalten.
Gibt's dazu auf Windows und/oder Linux bereits passende APIs? Also wo man sich z.B. ein Handle für einen Ver- bzw. Entschlüsseler erstellen kann, wo der nötige Key und IV dann im Kernel-Speicher abgelegt werden. Und wo man per Kernel-Call dann bestimmte Daten im Speicher ver- bzw. entschlüsseln lassen kann. Ideal wäre dabei wenn der Key auch gleich vom Kernel erzeugt wird, dann müsste der nichtmal kurzfristig im Usermode Speicher stehen.
Natürlich müsste dann noch jmd. die Anwendungen die man "härten" möchte anpassen, aber ohne passende API geht das ja gar nicht.
-
Was ist denn vertraulich und was nicht? In einem Web-Browser müsste ja fast alles verschlüsselt sein, damit Werbescripte nicht in privaten Informationen herumschnüffeln können.
-
Das beantwortet meine Frage nicht.
-
Du meinst soetwas wie die DPAPI https://msdn.microsoft.com/en-us/library/ms995355.aspx oder etwas das vollkommen transparent für Prozesse ist?
MfG SideWinder
-
Nene, nicht vollkommen transparent.
Nur halt mit den beschriebenen Eingenschaften, also der Key muss im Kernel-Speicher liegen, sonst kann man den ja mit auslesen. Und die Verschlüsselung darf nicht einfach (nur) auf dem User-Passwort hängen, sonst kann ein 2. Prozess der mit dem selben User-Account läuft die Daten ja einfach wieder entschlüsseln.
-
Woran soll er denn sonst hängen? Alles was ein Prozess A machen kann, kann ein Prozess B mit denselben User-Rechten doch auch machen. Also immer wenn Prozess A in der Lage ist einen Speicherbereich zu entschlüsseln kann das auch ein Prozess B tun. Im Notfall über Umwege, bspw. über die Fernsteuerung von Prozess A von Prozess B aus. Bin aber wahrscheinlich zu wenig kreativ dafür.
MfG SideWinder
-
Ach so, mir ging es hauptsächlich darum sowas wie den JavaScript Spectre Angriff zu verhindern. Dabei kann nur Usermode Speicher des Browser-Prozesses ausgelesen werden.
Wobei es da natürlich reichen würde wenn die Verschlüsselung am User-Passwort hängt, weil der Remote-Angreifer ja nicht einfach so einen Prozess mit meinem Account starten kann. Da hab ich wohl wieder nicht weit genug gedacht.
Wichtig bleibt auf jeden Fall dass der Key mit dem verschlüsselt wird nicht im Usermode Speicher liegt, und auch die Daten nicht aus denen er erzeugt wurde.
SideWinder schrieb:
Woran soll er denn sonst hängen?
Meine Idee wäre gewesen dass der Kernel einfach selbst einen zufälligen Key generiert. Dafür bekommt man dann ein Handle, und das kann man verwenden um die Daten zu ver-/entschlüsseln. Die Kernel-Calls kann man dann so absichern, dass sie nicht "spekuliert" werden können. (Nur für die Lebenszeit des Prozesses, Daten die irgendwo persistiert werden müssen sind ein anderes Problem.)
Das reicht wenn man annimmt dass der Angreifer keinen beliebigen Code in meinem Prozess zur Ausführung bringen kann. Wenn der Angreifer natürlich die Möglichkeit hat z.B. auch in meinen Prozess zu schreiben und dann einen Thread dort zu erzeugen, bzw. sonstwie beliebigen Code in meinem Prozess zur Ausführung bringen kann, dann reicht es nicht mehr. Ich glaube aber dass man in dem Fall sowieso verloren hat.
Ich kenne mich diesbezüglich ehrlich gesagt zu wenig mit den Default-Permissions auf Windows oder Linux aus. Keine Ahnung ob man mit einem Prozess der unter einem normalen User-Account läuft solche Schweinereien (also Speicher schreiben und Threads starten) in anderen Prozessen machen kann die unter dem selben Account laufen. Falls das geht, könnte man aber vermutlich mal darüber nachdenken ob das wirklich so gut ist. Und ob man es nicht ändern könnte ohne dass gleich haufenweise Anwendungen nicht mehr funktionieren. (Ich sehe zumindest keinen Grund warum eine ganz normale Anwendung das können müsste. Und so lange es ein "opt in" gibt wo man es speziellen Anwendungen extra wieder erlauben kann... hm.)
