In einer perfekten Welt haben Sie Recht: Es sollte keinen Sinn machen, Daten im RAM verschlüsselt zu halten. Das Betriebssystem sollte eine starke Trennung zwischen den Prozessen beibehalten, den Arbeitsspeicher löschen, wenn es einem anderen Prozess zugewiesen wird. Wenn das Angriffsmodell zulässt, dass ein Angreifer das Gerät anschließend stiehlt und eine Festplattenanalyse durchführt, verschlüsseln Sie den Swap (oder verwenden Sie überhaupt keinen Swap). Dies kann für ein Gerät mit Flash-basiertem Speicher sinnvoller sein.

In einer realistischen Welt, in der Betriebssysteme und Systemadministration menschliche Anstrengungen sind und daher von Natur aus nicht perfekt sind, möchten Sie möglicherweise einige Sicherheitsvorkehrungen hinzufügen Dazu gehört, dass die Daten im RAM verschlüsselt bleiben und das Betriebssystem nicht angewiesen wird, Daten in den Swap-Bereich zu schreiben (auf Unix-ähnlichen Systemen erfolgt dies mit mlock () ). Dennoch ist diese Verschlüsselung im RAM eher ein psychologisches Ritual als eine echte Verteidigung. Die Haupttugend besteht darin, dass sich der Entwickler besser fühlt.

Machen Sie sich das sowieso nicht in Java. Der Garbage Collector kopiert Objekte transparent in den RAM (dies ist Teil der effizientesten GC-Algorithmen und kann nicht verhindert werden), sodass keine Verschlüsselungsstufe Ihrer Anwendung garantiert, dass keine eindeutige Version der Schlüssel vorhanden ist jederzeit im RAM.

Moderne Betriebssysteme arbeiten mit der Verwaltung des virtuellen Speichers, sodass Benutzerbereichs- / Benutzermodusprozesse standardmäßig nicht direkt auf den Speicher anderer Prozesse zugreifen können.

Aber unter Windows (ich weiß nicht, ob dies auch für Linux gilt) gibt es Schnittstellen, über die Standardbenutzer auf den Prozessspeicher anderer Prozesse zugreifen können, die mit denselben Anmeldeinformationen ausgeführt werden.

Es gibt viele Programme, die diese Schnittstelle verwenden. Ein sehr einfaches Beispiel ist HxD - ein Freeware-Hex-Editor, mit dem der Prozessspeicher anderer Prozesse angezeigt und sogar bearbeitet werden kann.

Speicher kann für andere Prozesse sichtbar werden, indem:

1. verfügbar ist, sobald der ursprüngliche Prozess, der ihn verwendet, ihn an das Betriebssystem zurückgegeben hat. Der Speicher wird nicht gelöscht, und ein aufeinanderfolgender Prozess kann ein malloc () ausführen und Informationen abrufen, die zu einem zuvor ausgeführten Prozess gehören (Hinweis Kapitel 8 der Linux-Gerätetreiber - insbesondere die Fußnote auf der ersten Seite)
2. Seiten, die vom Betriebssystem auf die Festplatte ausgelagert werden. Diese können dann für einen Prozess verfügbar werden, der die Festplatte / den Speicher überwacht.
ol>

Folglich kann unverschlüsselter Speicher für andere Prozesse sichtbar werden.

Dies ist ein sehr interessanter Link, und beachten Sie dieses Zitat:

Diese Volatilität hängt jedoch stark vom jeweiligen Computer ab - wenn ein Computer nichts tut, kann anonymer Speicher für lange Zeiträume bestehen bleiben Zeit. Beispielsweise konnten auf einigen Computern Kennwörter und andere vorberechnete Daten viele Tage nach der Eingabe oder dem Laden in den Speicher

leicht wiederhergestellt werden

Es gibt einige Probleme, die für die Java-Welt spezifisch sind und die Sie berücksichtigen müssen. Es ist eine normale Praxis, dass man Heap-Dumps der JVM erstellt, wenn ein technisches Problem auftritt. Ich habe es mit einer App zu tun, die sogar eine eigene Benutzeroberfläche dafür hat. Dies könnte unglaublich wertvoll sein, z. zum Auffinden von Speicherlecks. Und sicher - ja - die vertraulichen Informationen gehen in den Müll. Wenn also jemand die App unterbricht (z. B. die Anmeldung mit einer SQL-Injection umgeht :)) ...: X. Oder wenn der Administrator eine neugierige Person ist ...: X

Ich weiß, dass dies in der "idealen Welt" nicht passieren sollte.

Sie können auch die JVM so konfigurieren, dass sie erstellt wird ein Speicherauszug für Ausnahmen aufgrund von Speichermangel. Seit Java 1.4 könnte dies folgendermaßen aussehen:

  -XX: -HeapDumpOnOutOfMemoryError -XX: HeapDumpPath = <path zum Speichern der Datei>  

Ein Angreifer findet möglicherweise einen Exploit Dadurch stürzt die App mit zu wenig Speicher ab und es kann ein anderer Exploit (z. B. Fehler beim Durchlaufen des Dateipfads) gefunden werden, um Ihren Speicherauszug zu stehlen!

Das andere, woran Sie denken sollten, ist, dass einige vertrauliche Daten irgendwie in Ihre App gelangen müssen. In bestimmten Momenten haben Sie es also im Gedächtnis. Sie können wenig oder gar nichts dagegen tun. Sie können es jedoch schneller reinigen. Nehmen Sie zum Beispiel ein Benutzerkennwort. Wenn Sie es in einer String-Instanz speichern, haben Sie nicht viel Kontrolle darüber, wann der Müll gesammelt wird. Daher verarbeiten normalerweise nette APIs solche Daten in Zeichenarrays (char []), die nach der Verwendung auf Null gesetzt werden können.

Google hat einen Exploit namens RowHammer, mit dem ein Nutzer den Inhalt des Arbeitsspeichers lesen kann, der sich neben den Daten befindet, in die geschrieben wird. Das Verschlüsseln des RAM würde diesen Exploit viel schwieriger machen.

"Rowhammer" ist ein Problem bei einigen neueren DRAM-Geräten, bei denen der wiederholte Zugriff auf eine Speicherzeile Bitflips in benachbarten Zeilen verursachen kann. Wir haben eine Auswahl von Laptops getestet und festgestellt, dass eine Untergruppe von ihnen das Problem aufwies. Wir haben zwei Exploits zur Eskalation von Arbeitsrechten erstellt, die diesen Effekt nutzen. Ein Exploit verwendet Rowhammer-induzierte Bit-Flips, um Kernel-Berechtigungen unter x86-64 Linux zu erhalten, wenn er als nicht privilegierter Userland-Prozess ausgeführt wird. Bei der Ausführung auf einem Computer, der für das Rowhammer-Problem anfällig ist, konnte der Prozess Bit-Flips in Seitentabelleneinträgen (PTEs) auslösen. Damit konnte es Schreibzugriff auf seine eigene Seitentabelle und damit Lese- / Schreibzugriff auf den gesamten physischen Speicher erhalten.

Wir wissen nicht genau, wie viele Computer dafür anfällig sind Angriff oder wie viele vorhandene anfällige Computer repariert werden können. Unser Exploit verwendet den x86-CLFLUSH-Befehl, um viele Zugriffe auf den zugrunde liegenden DRAM zu generieren. Andere Techniken funktionieren jedoch möglicherweise auch auf Nicht-x86-Systemen.

Wir gehen davon aus, dass unser PTE-basierter Exploit auch für andere Vorgänge geeignet ist Systeme; Es ist nicht von Natur aus Linux-spezifisch. Das Verursachen von Bitflips in PTEs ist nur eine Möglichkeit der Ausnutzung. Andere Möglichkeiten zum Ausnutzen von Bitflips können ebenfalls praktisch sein. Unser anderer Exploit demonstriert dies, indem er aus der Native Client-Sandbox entkommt.

KeePass verfügt speziell über eine Chrome-Erweiterung, sodass andere Chrome-Erweiterungen denselben Speicher lesen können, den KeePass verwendet. Der Speicherschutz des Betriebssystems wird in diesem Fall nicht helfen. Daher die Verschlüsselung.

Eine weitere Familie von Gründen für die Speicherverschlüsselung besteht im Allgemeinen darin, dass es Hardwareangriffe gibt, bei denen jemand auf den Speicher zugreifen kann:

• Kaltstartangriffe Ermöglichen Sie einem Angreifer, den Computer neu zu starten, während der Speicher intakt bleibt. Anschließend starten sie ein alternatives Betriebssystem ohne Speicherschutz und führen einen Scan durch.
• Durch Einfrieren der RAM-Chips behalten sie ihren Inhalt auch nach einem Stromausfall bei. Ein Hacker mit physischem Zugriff könnte also den RAM entfernen und in einen Vorratsbehälter für flüssigen Stickstoff legen und den RAM an einen anderen Ort verschieben, neu installieren und scannen.
• Verschiedene Hardware-Busse wie PCI und Firewire unterstützt DMA, wodurch das Gerät direkt auf den Speicher zugreifen kann. Ein Hacker könnte also ein Gerät in den Computer einfügen, das RAM liest.

Randnotiz: Intel und AMD bieten jetzt RAM-Verschlüsselung als Funktion an. P. >

Der Grund, warum es sich nach einer guten Idee anhört, ist, dass Sie die Daten vor Diebstahl schützen möchten, während Sie sich im Speicher befinden. Dies setzt voraus, dass die Daten in der eigentlichen Datenbank verschlüsselt sind (wie alle PII sein sollten), sich jedoch während der Verarbeitung unverschlüsselt im Speicher befinden. Dies wäre aus einer Vielzahl von Gründen, die von anderen Kommentatoren dargelegt wurden, ziemlich schwierig und würde eine große Komplexität in Bezug auf die Funktionsweise der Anwendungen mit den verschlüsselten Daten im Speicher mit sich bringen.

Was ist besser? Eine praktikablere Lösung besteht darin, eine ordnungsgemäße Zugriffskontrolle auf die Datenbank / das System sicherzustellen und sicherzustellen, dass das DBMS unter einem "normalen" Benutzerkonto und nicht unter einem erhöhten Konto wie SYSTEM usw. ausgeführt wird. Außerdem können Sie zusätzliche Detektivkontrollen einrichten B. ein DBMS-Überwachungstool, das Sie so konfigurieren können, dass große Auswahlen in vertraulichen Tabellen usw. angezeigt werden und über ungewöhnliche Ereignisse berichtet wird. Auf diese Weise können Sie sehen, ob eine Auswahl oder ein Prozess versucht, große Datenmengen herauszuholen.