Ein wiederhergestelltes Backup enthält einen verschlüsselten JSON-Datensatz für user-1842; dennoch akzeptiert die Anwendung ihn, nachdem ein Angreifer gespeicherte Bytes verändert hat und die wiederhergestellte role (Rolle) zu admin geworden ist. Der Angreifer benötigte weder den Verschlüsselungsschlüssel noch Zugriff auf die API. Er brauchte lediglich Schreibzugriff auf das Datenbank-Backup oder dessen Metadaten. Unser Beispiel basiert auf einem Python-Modul, das diesen Datensatz – bestehend aus id, email, role und created_at – schützt, während er zwischen Client, API, Datenbank und Backup übertragen wird. Bei der symmetrischen Verschlüsselung wird derselbe geheime Schlüssel verwendet, um Klartext in Geheimtext umzuwandeln und den Klartext später wiederherzustellen. Sie verbirgt den Datensatz, doch allein durch das Verbergen werden manipulierte Bytes nicht vertrauenswürdig.
Die Frage, die sich für die Verteidigung stellt, ist daher spezifischer als die nach dem Verfahren mit dem klangvollsten Namen. Wenn role=admin aus dem Speicher zurückgelesen wird: Wie kann die API nachweisen, dass es sich bei den Bytes und dem Kontext des Datensatzes genau um diejenigen handelt, die ursprünglich geschützt wurden? Die Grenzen für user-1842 zeigen auf, wo der Klartext enden muss, wo der Schlüssel getrennt gehalten werden muss und an welcher Stelle ein Angreifer den Geheimtext verändern kann, ohne dessen Inhalt zu erfahren. Verfolgen wir den Weg des Datensatzes über diese Grenzen hinweg:
Dieses Diagramm zeigt, dass Datenbank und Backup den Geheimtext (Ciphertext), eine Nonce und ausgewählte Metadaten benötigen, jedoch niemals den Verschlüsselungsschlüssel. Eine Nonce ist ein Wert, der mit einem bestimmten Schlüssel nur ein einziges Mal verwendet wird; dies stellt sicher, dass bei wiederholten Schutzvorgängen nicht dieselben kryptografischen Eingabedaten erneut genutzt werden. Die Nonce kann zusammen mit dem Geheimtext gespeichert werden; ihre Aufgabe ist nicht die Geheimhaltung. Der Schlüssel muss geheim bleiben und aus einer geschützten Anwendungskonfiguration stammen, nicht aus dem Datensatz oder dem Backup.
Da ein Angreifer gespeicherte Bytes verändern kann, erfordert der Vertrag für den Datensatz sowohl Vertraulichkeit als auch Integrität. Authentifizierte Verschlüsselung verschlüsselt die JSON-Bytes und überprüft vor der Rückgabe des Klartexts, ob sich weder diese Bytes noch ein ausgewählter Kontext verändert haben. Für user-1842 authentifiziert die API user_id=user-1842 und schema_version=1 als zugehörige Daten (Associated Data); dies sind Metadaten, die zwar durch den kryptografischen Vorgang verifiziert, aber nicht verschlüsselt werden. Ein kopierter Geheimtext kann somit nicht unbemerkt als Datensatz eines anderen Benutzers umdeklariert werden, und ein Schema-Wert lässt sich nicht ändern, ohne dass die Verifizierung fehlschlägt.
Im Klartext liegen E-Mail-Adresse und Rolle offen. AES-CTR und AES-CBC können diese Felder zwar verbergen, erkennen jedoch von sich aus keine Manipulationen. AES-GCM bietet die erforderliche Funktionalität der authentifizierten Verschlüsselung, sofern für jeden Verschlüsselungsvorgang mit demselben Schlüssel eine neue Nonce verwendet wird. Kann ein Modus, der ausschließlich verschlüsselt, erkennen, ob sich ein Byte im Backup geändert hat, bevor die API das Feld role parst? Der folgende Vergleich stellt die Speicheroptionen dieser Anforderung gegenüber:
Dieser Vergleich verdeutlicht die Entwurfsentscheidung. AES-GCM weist einen manipulierten Geheimtext, eine manipulierte Nonce, einen manipulierten Schlüssel oder manipulierte zugehörige Daten (Associated Data) mit einem Authentifizierungsfehler ab, während Verfahren, die lediglich Vertraulichkeit gewährleisten, der Anwendung diesen Nachweis vorenthalten. AES-GCM kann die Wiederverwendung einer Nonce nicht nachträglich korrigieren. Die Wiederverwendung einer Nonce mit demselben Schlüssel gefährdet die Sicherheit; daher sollte die Generierung der Nonce Teil des Schutzmechanismus sein, anstatt als vom Aufrufer bereitgestellte Metadaten zu fungieren.
Regel für Datensätze Speichern Sie die Nonce, den Geheimtext und die zugehörigen Daten gemeinsam mit dem Datensatz. Bewahren Sie den AES-Schlüssel separat auf und stellen Sie sicher, dass jede Nonce für einen bestimmten Schlüssel eindeutig ist.
Nachdem die Schnittstelle festgelegt ist, kann das Modul user-1842 schützen, ohne dem Aufrufer einen nur teilweise verifizierten Datensatz preiszugeben. Der JSON-Serialisierer erzeugt Byte-Daten, da AESGCM.encrypt auf Byte-Ebene arbeitet. Für dieses Beispiel generiert das Modul einen 256-Bit-AES-Schlüssel sowie eine neue 12-Byte-Nonce und speichert ein Paket im Format {Nonce, Geheimtext, zugehörige Daten}. Im produktiven Einsatz werden Schlüsselgenerierung und -verwaltung in den autorisierten Schlüsselverwaltungsbereich der Anwendung verlagert, während das Datensatzpaket sicher in der Datenbank und im Backup gespeichert werden kann.
Hier ist der minimale vollständige Ablauf für Schutz und Wiederherstellung: