Das Ausmaß einer Offenlegung hängt vom Schlüsseltyp und der Dauer des Angreiferzugriffs ab; ein Ratchet garantiert nicht, dass nur eine Nachricht gefährdet ist.
Starke Verschlüsselung erfordert auch eine korrekte Ausführung auf dem Gerät. Eine Schwachstelle im Betriebssystem, in der kryptografischen Implementierung oder in der Hardware kann den Zugang zu sensiblen Daten eröffnen. Aus Forschung zu Prozessorangriffen folgt jedoch nicht, dass sich jedes Smartphone oder jeder Messenger auf dieselbe Weise kompromittieren lässt.
Die hilfreichen Fragen lauten: Welchen Zugriff hat der Angreifer, welchen Schlüssel oder Klartext kann er sehen, und ist sein Zugriff vorübergehend oder dauerhaft? Die Antworten sind wichtiger als der Name des Algorithmus.
Was unterscheidet Seitenkanäle vom Auslesen des Speichers?
Beim direkten Auslesen des Speichers kann ein Angreifer möglicherweise Teile des Prozess- oder Gerätespeichers lesen. Bei einem Seitenkanalangriff werden Hinweise wie Ausführungszeiten oder das Cache-Verhalten genutzt, um Informationen abzuleiten. Beide haben nicht zwangsläufig dieselben Voraussetzungen oder Ergebnisse.
Die ursprüngliche Forschung zu FLUSH+RELOAD untersuchte Cache-Verhalten und gemeinsam genutzte Speicherseiten in einer bestimmten Versuchsumgebung und demonstrierte die Schlüsselextraktion aus einer GnuPG-Version. Dieses Ergebnis ist weder ein Sicherheitstest von Livara noch ein Beleg für die Verwundbarkeit sämtlicher Smartphone-Prozessoren.
| Art des Zugriffs | Erforderliche Bewertungsfrage |
|---|---|
| Ausführen einer gewöhnlichen App auf demselben Gerät | Lassen Prozessisolation und Angriffsvoraussetzungen eine Beobachtung zu? |
| Privilegierter Zugriff auf das Betriebssystem | Welche Daten oder Schlüsseloperationen stehen dem Angreifer zur Verfügung? |
| Physischer Zugriff oder Laborzugriff | Wie sind Sperrzustand, Hardwaremodell und Schlüsselschutz beschaffen? |
| Fortlaufender Zugriff auf die App | Kann der Angreifer erneut neue Klartexte oder Schlüssel sammeln? |
Die allgemeine Formulierung „RAM-Hacking“ ist ohne diese Einzelheiten keine ausreichende technische Erklärung.
Wie helfen Keystore und sichere Hardware?
Android Keystore kann die Schlüsselnutzung einschränken und auf geeigneten Geräten Operationen hardwaregestützt ausführen. In diesem Konzept bedeutet „nicht extrahierbar“ nicht „vom Angreifer nicht nutzbar“: Eine kompromittierte App kann unter bestimmten Umständen zulässige Schlüsseloperationen missbrauchen, auch wenn sie die Schlüsselbytes nicht auslesen kann. Anleitung zu Android Keystore.
Auch landen nicht alle Schlüssel und Algorithmen automatisch in sicherer Hardware. Schlüsseltyp, Geräteunterstützung und Nutzung durch die App müssen bekannt sein. Die Aussage „Der Schlüssel befindet sich auf dem Gerät“ belegt allein weder seinen Speicherort noch sein Schutzniveau.
Legt ein offengelegter Schlüssel nur eine Nachricht offen?
Manchmal hat die Offenlegung eines unabhängigen Nachrichtenschlüssels einen begrenzten Umfang. Erlangt der Angreifer jedoch einen Kettenschlüssel, den Sitzungszustand, einen Identitätsschlüssel, einen lesbaren Verlauf oder mehrere Puffer, fällt das Ergebnis anders aus. Ohne die offengelegten Daten zu bestimmen, lässt sich daher nicht sagen, dass „höchstens eine Nachricht“ gefährdet ist.
Auch ein Schlüsselwechsel für jede Nachricht unterbricht den Angreiferzugriff nicht zwangsläufig. Werden spätere Schlüssel aus einem Zustand abgeleitet, den der Angreifer kennt, oder bleibt er auf dem Gerät präsent, kann er möglicherweise auch spätere Nachrichten erreichen. Der Schutz der Vergangenheit und die Wiederherstellung künftiger Sicherheit sind getrennte Eigenschaften mit jeweils bestimmten Annahmen.
Welche Grenzen haben Ratchets und Speicherbereinigung?
Ein Ratchet kann Schlüssel im Verlauf eines Gesprächs weiterentwickeln. Die Wiederherstellung nach einer Offenlegung benötigt neue Informationen, auf die der Angreifer keinen Zugriff hat; allein das Senden einer Nachricht belegt diese Voraussetzung nicht. Die Double-Ratchet-Spezifikation erläutert neben der Wiederherstellung auch die Risiken eines dauerhaften Zugriffs und der Wiedergewinnung gelöschter Daten.
Eine kürzere Lebensdauer sensibler Daten und das Leeren von Puffern sind nützlich. Daraus folgt jedoch keine allgemeine Aussage, dass sämtliche Kopien im RAM gelöscht wurden. Bibliotheken, Programmiersprache und Anzeigepfade müssen untersucht werden.
Was lässt sich über Livara sagen?
Livaras Sicherheitsseite beschreibt den hybriden Aufbau und die Schlüsselentwicklung in LVR1. Dieser Artikel ist kein Seitenkanaltest, kein Speicheraudit und keine Bestätigung, dass alle Schlüssel Keystore verwenden. Insbesondere garantiert das öffentliche Bedrohungsmodell keinen Schutz eines kompromittierten Geräts.
Versprechen wie „Die nächste Nachricht neutralisiert einen Hardwareeinbruch“ oder „Höchstens eine Nachricht wird offengelegt“ sollten dem Produkt daher nur zugeschrieben werden, wenn konkrete Belege für genau diese Version und dieses Szenario vorliegen.
Praktische Entscheidungen für Nutzer
Halten Sie Betriebssystem und App aktuell, wählen Sie ein Gerät mit laufender Sicherheitsunterstützung, vermeiden Sie nicht vertrauenswürdige Installationen und unnötige Berechtigungen, und verwenden Sie eine geeignete Gerätesperre. Bei Verdacht auf eine schwerwiegende Kompromittierung ersetzen weder ein Messengerwechsel noch eine neue Nachricht die Untersuchung und Bereinigung des Geräts.
Verlangen Sie bei einer Sicherheitsbehauptung vier Angaben: die getestete Version, den Zugriff des Angreifers, die offengelegten Daten und die Grenzen des Ergebnisses. Der Name eines Prozessors oder eines Verschlüsselungsstandards allein beantwortet diese vier Fragen nicht.
