Newtons Datenschutzebene macht eine präzise Sicherheitszusage: Wenn private Daten verschlüsselt und hochgeladen werden, ist der Chiffretext kryptografisch an eine bestimmte Richtlinie und eine bestimmte Kette gebunden.
Versuche, diese verschlüsselte Hülle an anderer Stelle erneut abzuspielen — mit einer anderen Richtlinie, einer anderen Kette — und die Authentifizierungsprüfung schlägt sofort fehl.
Die Entschlüsselung wird verweigert. Ich wollte genau sehen, was „gebunden an“ umfasst, und ebenso wichtig, was es nicht umfasst.
Hier ist die tatsächliche Formel.
Die zusätzlichen, authentifizierten Daten, die der Verschlüsselung beigefügt sind, werden aus genau zwei Eingaben berechnet: dem Policy-Client und der Chain-ID, die zusammengehasht werden.
Dieser Hash wird Teil dessen, was der Verschlüsselungsalgorithmus gemeinsam mit dem Ciphertext authentifiziert.
Wenn sich eine der beiden Eingaben ändert — eine andere Policy, eine andere Chain — zerbricht der gesamte Authentifizierungs-Tag, und der Algorithmus verweigert die Entschlüsselung.
Das ist eine starke, klar abgegrenzte Zusicherung — und genau eine Art Schutz, die man sich wünscht, wenn jemand versucht, eine gültige verschlüsselte Nutzlast zu kopieren und in einem Kontext wiederzuverwenden, für den sie nie vorgesehen war.
Aber der Upload-Aufruf, der diesen Ciphertext überträgt, trägt nicht nur den Ciphertext und diese beiden gebundenen Werte.
Außerdem enthält es eine Time-to-Live — einen Wert, der bestimmt, wie lange dieser Datenabschnitt als gültig bzw. abrufbar bleiben soll, bevor er abläuft.
Und als ich geprüft habe, was tatsächlich in die Formel der authentifizierten Daten eingeht, ist die TTL nicht darin.
Die Formel deckt genau zwei Dinge ab: Policy-Client und Chain-ID. Nichts anderes.
Das ist eine echte Unterscheidung, keine Formalität. Ein authentifiziertes Feld ist eines, bei dem Manipulation den kryptografischen Nachweis zerstört und automatisch auffällt.
Ein unauthetisiertes Feld ist eines, das das System einfach so vertraut, wie es angegeben wird, weil nichts in der Verschlüsselung selbst darauf „wacht“.
Der Policy-Client und die Chain-ID befinden sich in der ersten Kategorie.
Der TTL-Wert liegt, basierend auf dem, was dokumentiert ist, im zweiten Bereich.
Das wirft eine konkrete, testbare Frage auf: Wenn jemand, der die Fähigkeit hat, diese Upload-Anfrage abzufangen oder erneut zu senden, nur die TTL ändert — wobei der Ciphertext, der Policy-Client und die Chain-ID vollständig unangetastet bleiben — würde die Authentifizierungsprüfung das überhaupt bemerken?
Basierend auf der so formulierten Formel dürfte das nicht passieren.
Der Ciphertext würde sich weiterhin sauber entschlüsseln lassen, weil nichts an einer TTL-Manipulation die beiden Werte berührt, die der Algorithmus tatsächlich prüft.
Die Daten wären immer noch exakt das, was der ursprüngliche Absender verschlüsselt hat. Nur ihre „Haltbarkeit“ würde sich still und leise geändert haben.
Das ist wichtiger, als es zunächst erscheinen mag, denn TTL ist keine bloße Zusatzmetadaten — sie ist für sich genommen eine Sicherheitskontrolle.
Vermutlich begrenzt es, wie lange ein Stück sensibler, verschlüsselter Daten etwas bleibt, mit dem das System weiterhin arbeitet, es weiterhin abruft und weiterhin als aktuell behandelt.
Eine verkürzte TTL könnte dazu führen, dass legitime Daten zu früh ablaufen und Workflows, die darauf angewiesen sind, still und leise scheitern.
Eine verlängerte Version könnte sensible Daten am Leben halten und noch lange nach dem Zeitpunkt, an dem die ursprüngliche Partei wollte, dass es relevant wird, zuverlässig abrufbar machen.
Keines davon erfordert das Brechen der Verschlüsselung.
Keines von beidem löst die einzige Integritätsprüfung aus, für die das System dokumentiert ist.
Ich möchte präzise sein, was ich nicht behaupte.
Ich weiß nicht, ob diese Lücke Ende-zu-Ende tatsächlich ausnutzbar ist — das hängt von Dingen ab, die die Dokumentation nicht abdeckt, etwa davon, ob das Gateway die TTL unabhängig auf der Chain im Moment des Uploads in einer Weise verbindlich festschreibt, die danach nicht mehr verändert werden kann, ob die Upload-Anfrage selbst über einen Kanal läuft, der durch einen eigenen Schutz auf Transportebene gegen Manipulation abgesichert ist und Manipulation abfängt, bevor sie diese Ebene überhaupt erreicht, oder ob die TTL von vornherein eher als Empfehlung und nicht als sicherheitskritischer Wert behandelt wird.
All das könnte die Lücke vollständig schließen, und nichts davon würde in der AAD-Formel selbst auftauchen, weil es sich um Schutzschichten darüber handelt und nicht darum, was in sie hineingehört.
Also ist die offene Frage exakt: Wird der TTL-Wert irgendwo zu einem Zeitpunkt des Uploads unveränderlich und nachprüfbar festgeschrieben — on-chain oder in irgendeiner anderen authentifizierten Struktur — oder wird er als Parameter des RPC-Aufrufs im Grunde genommen so akzeptiert, wie jedes andere unauthetisierte Feld als vertrauenswürdig behandelt wird?
Die Dokumentation ist präzise darüber, was die Verschlüsselung selbst schützt.
Es sagt nichts darüber aus, was den einen zeitgebundenen Wert schützt, der bestimmt, wie lange dieser Schutz überhaupt halten soll.