Ein Influenzer würde einen solchen Artikel beginnen mit "Ich werde immer wieder gefragt, warum..." Da ich keiner bin kann ich so etwas nicht tun – statt dessen erläutere ich einfach das Szenario: Ich pflege diverse Open Source Projekte, die sich mit PKI und kryptographischen Timestamps. Jedoch benutzt die sQLshell elektronische Signaturen nur für die Verteilung der diversen Plugins.

Und da kam mir der Gedanke, die sQLshell als Fallbeispiel zu nutzen, um die Projektierung einer Lösung für digitale Signaturen und Timestamps zu illustrieren.

Ausgangspunkt der Überlegungen war, die Modifikation von Inhalten einer Datenbank mittels elektronischer Signaturen zu erkennen. Eine einfache Lösung dafür wäre natürlich, eine in die Datenbank eingebaute Lösung zu nutzen. Eine weitere wäre, die Datenbank selbst - also die Dateien, die den Datenbestand darstellen in ihrer Gesamtheit zu signieren. Abgesehen vom Aufwand und der dafür benötigten Rechenzeit ist das kontraproduktiv, da in der Datenebank ja diverse Daten enthalten sind, die eher volatil und transient sind - wenn solche Daten in die Signatur inkludiert werden, wird die Signatur ja beinahe sofort ungültig.

Man muss also zunächst einmal definieren, welche Daten lange genug konstant bleiben und schützenswert sind, so dass eine elektronische Signatur sinnvoll erscheint. Wenn man also in der Datenbank einen Menge von Views definiert, die über elektronische Signaturen geschützt werden sollen, muss man deren Inhalte signieren. Das könnte man über entsprechende Erweiterungen mittels Triggern und PL/SQL (oder die Entsprechung in der jeweiligen Datenbank) erledigen.

Eine andere Möglichkeit - und hier kommt der Zusammenhamg mit der sQLshell endlich zum Vorschein - besteht darin, eine entsprechende Abfrage an die Datenbank zu richten und die Ergebnisse zu signieren/mit einem Zeitstempel zu versehen. Hier stellt sich zunächst die Frage, wie man die Ergebnisse der Abfrage aufbereitet, um sie signieren zu können. Eine Möglichkeit wäre die Umwandlung / der Export als XML. Dann könnte eine entsprechende Kanonisierung stattfinden und das Ergebnis würde als Input der kryptographischen Funktionen dienen.

Rein technisch ist die Anforderung, bestimmte Daten mittels kryptographischer Operationen so zu sichern, dass man nachweisen kann, dass sie exakt so zu einem bestimmten früheren Zeitpunkt in der Datenbank enthalten waren umgesetzt.

Jetzt muss man sich aber Gedanken machen, wie man die Verifikation löst: Wenn man die Authentizität der aktuell in der Datenbank enthaltenen Daten nachweisen möchte, muss man eine Abfrage an die Datenbank stellen und deren Ergebnis, bzw das Digest daraus mit dem vergleichen, das in der Signatur vorliegt. Stimmen beide überein ist das der Nachweis, dass die Daten nicht verändert wurden. Allerdings kann man - wenn man die Daten verändert hat und nicht möchte, dass das auffällt - die Abfrage genau so schreiben, dass das Ergebnis der Abfrage mit den Daten übereinstimmt, die der Signatur zugrunde lagen. Also muss man die Abfrage selbst mit in die signierten Daten aufnehmen.

Jetzt ist es natürlich möglich, dass ein Angreifer es schafft, die Abfrage zur Verifikation der Signatur auf eine andere Datenbank-Instanz umzuleiten, die noch die Originaldaten enthält. In diesem Falle würde dieselbe Abfrage, die zur Erstellung der Signatur benutzt wurde dieselben Daten liefern und die Prüfung der Signatur wäre erfolgreich. Das bedeutet, dass man noch die Information über die benutzten Datenbankverbindung mit in die zu signierenden Daten aufnehmen muss. Diese Informationen müssen in geeigneter Form integriert werden - ein einfaches Paar aus Hostname und Port reicht hier nicht aus. Idealerweise könnte man die Identität des kontaktierten Datenbankdienstes über sein für die Etablierung einer TLS-Verbindung benutztes elektronisches Zertifikat feststellen.

Jetzt haben wir aber bereits eine elektronische Signatur, die eine andere elektronische Signatur beglaubigt - das kommt uns seltsam vertraut vor: Dafür könnte man die Datenstrukturen aus dem Standard für die gerichtsfeste Langzeitarchivierung verwenden.