Datenbank in der Cloud

Private Nutzer verwenden oft mehrere Geräte unter Einschluss mobiler Geräte. Für eine einheitliche konsistente Behandlung aller Verbindungen ist daher eine zentrale Datenbank notwendig, die von allen Geräten angesprochen werden kann.

Diese Funktion kann ein EI-Manager übernehmen, der im Besitz des Nutzers ist und von ihm kontrolliert wird, beispielsweise ein Raspberry-Pi oder ein anderer Einplatinenrechner, der im 24/7-Betrieb kostengünstig arbeiten kann. Die Nutzerbarkeit setzt aber voraus, dass das LAN des Nutzers einen Serverport ins WAN aufweist.

Ist das nicht gegeben, bleibt ein Umweg über einen Server im Internet, der von den Geräten außerhalb des LAN angesprochen werden kann und vom EI-Manager in kurzen Abständen gepflegt wird. Wir entwickeln hier ein Modell, wie die Manager-Daten in der Cloud abgelegt werden können.

Was liegt offen?

Bei einem von einem Provider angemieteten Server oder bei einem gehosteten Server mit einer eigenen URL kann jeder über den DNS-Eintrag die Identität des Inhabers feststellen. Bei Cloud-Servern ohne persönliche URL können sich Behörden in der Regel diese Daten ebenfalls über den Cloudbetreiber beschaffen. Der Inhaber einer Datenbanktabellen ist somit i.d.R. ermittelbar.

Verbindungsdaten zum Server sind ebenfalls ermittelbar, d.h. man kann ein Nutzerprofil des Datenbankinhabers erstellen. Der Datenaustausch mit dem Server kann verschlüsselt werden, so dass die mit dem Server ausgetauschten Daten nicht sichtbar sind.

Sichtbar sind aber die Daten auf dem Server. Zwar zunächst nur für den Provider, aber nachfolgend möglicherweise auch für Dritte.

Applikationsrahmen

Im Minimalfall betreibt der Nutzer einen HTTP-Server bei einem Provider. Die Cloud-Datenbank kann als Unterseite eingerichtet werden. Der Datenverkehr wird von den Applikationen direkt abgesichert.

Private Schlüssel werden in der Cloud nicht gespeichert. Auch bei Kompromittierung des Servers ist ein Einbruch in die Zertifikate nicht möglich.

Die Schlüssel für verschlüsselt auf dem Server gespeicherte Daten sind dem Server nicht zugänglich. Daten werden vom EI-Manager verschlüsselt und erst auf den Geräten entschlüsselt und umgekehrt. Hierzu ist ein Schlüsselaustauschsystem notwendig.

Die Datensätze in der Datenbank werden durch einen Hash-MAC gegen Verfälschung gesichert. Veränderte Datensätze können sicher erkannt werden.

Die Daten in der Datenbank werden so weit wie möglich verschlüsselt. Da gezielt zugegriffen werden muss, ist in vielen Fällen allerdings nur ein ECB-Modus möglich, d.h. ein Angreifer mit großen Ressourcen kann trotzdem in Informationen gelangen.

Software

Eingesetzt wird PHP(7) in Verbindung mit MySQL als Datenbank. Als MVC-Framework wird CodeIgniter eingesetzt.

Der Source-Code kann hier herunter geladen werden.

Nutzer- und Zugriffskontrolle

Die Zugriffskontrolle erfolgt über die Zertifikate der Geräte des Nutzers. Der Fingerprint des EI-Managerzeritikats wird in den Konfigurationsdaten des MVC-Frameworks eingetragen, das Zertifikat in der PEM-Form in einer Datei abgespeichert, kann also immer sicher identifiziert werden. Die anderen Zertifikate werden in der Tabelle “devices” gespeichert:

CREATE TABLE IF NOT EXISTS `devices` (
    `fingerprint` text NOT NULL,
    `certificate` text NOT NULL,
    `encrypted_key` text NOT NULL,
    `hmac` text NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Login: zum Login sendet das Gerät ein einfaches “HTTP GET” an den Server und erhält als Antwort eine Zufallszahl. Die Zufallszahl wird mit dem Gerätezertifikat signiert und zusammen mit dem Zertifikatfingerprint an den Cloud-Server gesandt.

Mit dem Fingerprint kann der Cloud-Server das Zertifikat in der Datenbank identifizieren und auslesen und die Signatur überprüfen. Die richtige Antwort kann nur vom Inhabergerät kommen, ein Replay ist ausgeschlossen, da bei jeder Verbindung eine neue Zufallszahl erzeugt wird.

Als Antwort wird eine weitere Zufallszahl - die interne Sessionkennung “sess_key” [1] - erzeugt und mit dem kompletten Datensatz an das Gerät zurückgesandt. Dieses entschlüsselt zunächst mittels des privaten Schlüssels des eigenen Zertifikats den in “encrypted_key” enthaltenen symmetrischen Schlüssel “sym_key”, mit dem die weiteren Daten verschlüsselt sind. Im zweiten Schritt wird:

hmac == Hash-MAC(symKey , fingerprint + certificate + encrypted_key)

überprüft. Der “hmac” ist vom EI-Manager erstellt, “sym_key” ist dem Cloudserver nicht bekannt. Der Datensatz ist somit als unverfälscht identifiziert und das Login abgeschlossen.

Fortlaufende Authentifizierung: jede weitere Nachricht des Gerätes an den Server wird mit:

auth=SHA_256( sess_key + {C/S} + ldf_nr )

versehen, wobei “C” vom Geräte im GET/POST, “S” vom Cloud-Server in der Antwort verwendet wird. “lfd_nr” wird beim Login mit 1 initialisierung und mit jeder Nachricht inkrementiert. Beide Einheiten können so sicher sein, keine Fake-Nachrichten zu erhalten.

Konfiguration. Bei Inbetriebnahme des Systems oder bei einem neuen eigenen Zertifikat wird die komplette Datenbank vom EI-Manager neu aufgebaut. Das Löschen der Tabellen auf dem Cloud-Server ist nur dem Manager erlaubt; der Cloud-Server kann den Manager durch die Konfiguration sicher identitizieren. Anschließend wird ein neuer “sym_key” generiert und für jedes eigene Zertifikat verschlüsselt. Da die Geräte beim Login die aktuellen Daten bekommen, stellt ein Wechsel des “sym_key” kein zusätzliches Synchronisationsproblem dar. Wechseln Geräte des Nutzers, werden automatisch neue Daten vergeben, d.h. ein Zugriff auf die Daten ist auch bei Unachtsamkeit nicht möglich. [2]

Zertifikatstatus. Bei der Kommunikation sind die eingehenden Zertifikate zu prüfen. In der Cloud-Datenbank werden die Zertifikate in der Form:

CREATE TABLE IF NOT EXISTS `certificates` (
    `cert` text NOT NULL,
    `subject_dn` text NOT NULL,
    `usable` int(11) NOT NULL DEFAULT '1',
    `hmac` text NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

gespeichert. Über “subject_dn” oder “cert” kann auf ein Zertifikat zugegriffen werden.[#f3]_ “subject_dn” erlaubt den Zugriff auf Zertifikatketten, “usable” gibt an, ob das Zertifikat genutzt werden darf. Die Integrität wird über “hmac” abgesichert (s.o.).

Neue Zertifikate werden in der Datenbank “new_certs” abgespeichert. Eine Kontrolle durch den Manager kann erst zeitverzögert erfolgen. Anwendungsabhängig ist in den Anwendungen festzulegen, ob solche Zertifikate genutzt werden dürfen, da nicht alle Manager-Daten zur Verfügung stehen. Diese kann das betreffende Zertifikat bei einem Update auch mit “usable==0” kennzeichnen.

Emails und andere vom Manager bearbeitete Daten werden in der Tabelle “messages” abgelegt:

CREATE TABLE IF NOT EXISTS `messages` (
    `channel` varchar(20) NOT NULL,
    `send` int(11) NOT NULL,
    `data` text NOT NULL,
    `datum` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
    `hmac` text NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Die Daten werden mit dem “sym_key” verschlüsselt gespeichert. Der Versand erfolgt vom Manager über die Verschlüsselungs-API. Erhaltene Nachrichten werden vom Manager auf dem Cloud-Server bereit gestellt und können von allen Geräten aus abgerufen werden.

[1]Nicht zu verwechseln mit der HTTP-Session, die darüber operiert!
[2]Ein Angreifer muss die komplette alte Datenbank auslesen, um durch einen verratenen privaten Schlüssel an Betriebsdaten kommen zu können. Diese enthalten jedoch keine geheimen Daten und keine für den laufenden Betrieb nutzbaren Schlüssel.
[3]Hier ist noch nicht abschließend geklärt, ob eine Verschlüsselung erfolgen soll.