Menü
Avatar von Bitschnipser
  • Bitschnipser

mehr als 1000 Beiträge seit 14.01.2016

Re: Sehr viele verschlüsselte Daten scheint es in der Azure Cloud nicht zu geben

die kleine Himbeere schrieb am 15.03.2019 20:43:

Bitschnipser schrieb am 15.03.2019 14:06:

Einen Timestamp in die verschlüsselten Daten einbinden.
Der Betreiber kann dann zwar immer noch auf einen alten Stand zurücksetzen, aber die Software kann feststellen, dass die Daten älter als erwartet sind.

Meinst du jetzt nur für die Baumwurzel, oder für die einzelnen verschlüsselten Sektoren?

Sektoren für alle unabhängig voneinander.
Eine Baumstruktur quer über die Platte ist ein Alptraum: Wenn ein Sektor ausfällt, sind alle dahinter liegenden Sektoren unbrauchbar. Und ausfallende Plattensektoren sind immer noch ein Thema, deshalb haben Dateisysteme für richtig große Platten ja auch so (scheinbar) absurd gründliche Prüfsummen.

Im letzteren Fall ist das Problem, dass der Timestamp nur das Datum der Verschlüsselung angibt.

Woher soll man aber wissen dass dieses älter "als erwartet" ist? Und zwar ohne dass man lokal eine Liste *aller* Timestamps aller Sektoren des Cloud-Datenträgers speichern muss?

Steht im zweiten Teil.

Die nächststärkere Variante wäre ein Zeitstempel-Service, den man selber betreibt.

Ja, aber damit hat man eine zentrale Instanz der man trauen kann. Normalerweise mangelt es einem aber genau an der, weil sonst könnte man den Cloud-Datenträger ja genau so selber betreiben und könnte sich die ganzen Probleme sparen.

Ein einzelner Zeitserver ist viel unaufwändiger zu betreiben als eine ganze Serverfarm.
Das geht notfalls auch über die DSL-Leitung aus dem Kleinbüro.

Was ich gerne hätte, wäre eine Möglichkeit auf Dropbox (oder Onedrive und anderen nicht vertrauenswürdigen Diensten) abgelegte Dateien so "cloud-sicher" zu verschlüsseln, dass man ihnen vertrauen kann.

Datenablage ist mit AES nun wirklich sicher zu verschlüsseln.
Mit einem guten Schlüsselmanagement-Server kommen auch alle Server, die diese Daten verwenden, an den Klartext. Solche Keyserver sollte man nicht selber programmieren, aber betreiben kann man sie auch wieder lokal.

Spannend wird es, wenn beim Dienstleister auch Verarbeitung stattfindet.

Und alle diese Massnahmen laufen ins Leere, wenn der Betreiber den CPU-Bus abschnorchelt, dort sieht er nämlich ohnehin unverschlüsselte Daten auf dem Weg von RAM zu CPU und zurück. Oder er lötet auf den Platinen einen Chip auf, der die Daten zwischen TPM und CPU abschnorchelt.
D.h. man muss dem Betreiber ohnehin vertrauen.

Aber es ist für einen Cloud-Priovider schon noch um mehrere Größenordnungen einfacher Daten abzuschnorcheln als lokal auf den eigenen Rechnern des Benutzers.

Ich ging von Verarbeitung beim Provider aus.
Also sowas wie AWS.

Festplattenverschlüsselung dient eher als Stolperschwelle [...] Man sichert also weniger gegen den Betreiber an sich, sondern gegen Fehler und absichtliche Verstösse der Mitarbeiter.

Gut, schon, aber das ist dann auch etwas gänzlich anderes als ich es im Sinn habe: Nämlich verschlüsselten Cloud-Storage lokal sicher mounten zu können, und dem Betreiber dabei *überhaupt nicht* vertrauen zu müssen!

Wenn du der mountenden Maschine vertrauen kannst, ist das mit einer einfachen Festplattenverschlüsselung schon perfekt abgedeckt.

Bezüglich der Timestamps bzw. Seriennummern kam mir inzwischen übrigens noch eine Idee: Man könnte diese ja genau so in einem - unabhängigen zweiten - Merkle-Tree speichern, wie man es ohnehin bereits für die MACs tut!

So wäre sicher gestellt dass niemand einfach alte Timestamps samt Blockinhalten unbemerkt zurück schreiben kann, solange man nur die Baumwurzel irgendwie sichern kann.

Der Unterschied zum MAC-Tree wäre nur, dass man beim Nonce-Tree tatsächlich die Nonces in den Datenblocks mitspeichern muss, während die MACs ja nur errechnete Werte sind.

Keine blockübergreifenden Trees.
Echt nicht.
Du verlierst irgendwann einen Teil deiner Daten. Wenn es einen Block relativ weit oben im Baum trifft, sogar einen Großteil deiner Daten.

Das ist ja das, was Dateisysteme zu so einer schwierigen Angelegenheit macht: Man hat dort immer eine Baumstruktur. Und schau dir an, wie viele Leute schon Daten aufgrund von Bugs im Dateisystem haben, und warum die Betaphase für Dateisysteme so irrsinnig lang ist: Genau deshalb. Weil man die Baumstruktur gegen Ausfälle aller Art sichern muss: Bugs, Hardwareausfälle, Fehlbedienung.

Bewerten
- +
Anzeige