"Foltersicherere" Krypto Architektur für ein Client/Server System

Hallo zusammen,

ich bastele gerade an einem Archtitekturmodel bei dem ich als
Serverbetreiber zu keiner Zeit "weiß" welche Art von Daten
auf meinem Server gespeichert sind.

Mir geht es darum, das ich mit Mathematik erklären kann, dass ich
weder im Besitz des Passwortes bin, noch Daten rekonstruieren kann,
noch irgendwas an meiner Archtitetkur frickeln kann, damit ich es könnte.

Ziel ist es _nicht_ die Daten vom Client Benutzer zu schützen (auch
wenn das ein netter Nebeneffekt ist).

Mir schwebt ein Konzept vor, wie es der Onlinedienst "Mega" anbietet:

Hier wird vor dem Upload der Content AES-128 verschlüsselt. Das Passwort
wird niemals auf den Server geschickt. Beim Herunterladen wird wieder
vom Client auf dem Gerät lokal entschlüsselt.

Mir sind folgende Probleme bewusst:

- Der Verlust vom Passwort führt zum Verlust der Daten.

- Das Handy/Tablet kann kompromitiert werden und jemand fängt "On Device"
das Passwort ab.

Der Serverbetreiber kann - auch unter Androhung von Folter - nicht auf die
inhaltlichen Daten vom Endkunden zugreifen. Es gibt davon nur eine nutzlose
Cryptoversion im Zugriffsbereich des Serverbretreibers.


Was gibt's denn noch für Alternativen zu diesem Model?

P.S. Bitte keine juristische Beratung! Das ist hier nicht gefragt!

Eine Alternative ist mir nicht bekannt. Wenn die Daten nicht auf dem Client verschlüsselt werden, muss das an einem anderen Ort geschehen. Dieser andere Ort hat dann natürlich automatisch Zugriff auf die Daten, bevor sie verschlüsselt sind. Deshalb macht es aus meiner Sicht am meisten Sinn, die Daten auf dem Client zu verschlüsseln und den Schlüssel nie weiterzugeben.

Wie man das jetzt mathematisch beschreibt: keine Ahnung Ein bisschen Vertrauen ist schlussendlich immer nötig. Unabhängig von deiner Architektur könnte die App trotzdem Code enthalten, die den Schlüssel an den Server weitergibt. Insofern kannst du immer etwas an deiner Architektur "frickeln", wenn du die Client-App entwickelst.

Aus Sicht des Servers reicht es, wenn die Daten bereits verschlüsselt ankommen. Wenn gängige Methoden (sicherer Verschlüsselungsalgorithmus, korrekter Cipher Mode, einmaliger und zufälliger Initialisierungsvektor, Key Stretching, ...) korrekt und sauber eingesetzt werden, sollte sich das (abgesehen von Brute Force) nicht knacken lassen. Allenfalls kann man aber gewisse Rückschlüsse auf die Datentypen ziehen. Wenn z.B. 500 MB verschlüsselte Daten übermittelt werden, ist das vermutlich eher ein Video statt Text. In einigen Situationen kann das komplett irrelevant sein, in anderen Situationen könnte das aber vielleicht indirekte Infos preisgeben.

(Alle Angaben ohne Gewähr )

Mein Fokus liegt erstmal auf der Serverseite und die Brille liegt auf dem Server Betreiber.

Deiner Meinung nach ist es auch nicht - mit technisch vertretbarem Aufwand - möglich Serverseitig aus "Bytesalat" ein Klartext Resultat zu liefern. Darum geht es mir primär. Vermutlich ging es "Mega" auch genau um diesen Aspekt bei der Wahl der Architektur.

Der Serverbetreiber sollte "plausible deniability" by desing haben, was es niemals gestattet dem Betreiber Klartext direkt auf die Daten zuzugreifen.

Was auf dem Client passiert hab ich nicht 100% ig im Griff. Das Passwort kann immer abgefangen werden (Physikalischer Zugriff auf das Gerät, Zugriff auf die Datenbank, Fake Tastatur, Folter, ...).

Ich sollte vielleicht noch ein bisschen was zum Projekt erzählen:

- Es gibt ein PC System.
- Dieses schickt Daten zu dem hier angesprochenen Server.
- Ein Handy/Tablet holt diese Daten ab.
- Auf dem Handy/Tablet erfolgt jetzt eine Bearbeitung (es kommen Dokumente dazu, es werden Datensätze verändert).
- Das Handy/Tablet schickt die Daten wieder auf dem Server. (ggf. auch mehrfach oder in Teilpaketen)
- Das PC System holt die Daten ab.

Ich identifiziere hier eine Schwachstelle:

Luxusproblem: Wenn alles nur mit einem AES Passwort verschlüsselt ist und dieser
"geheime" Schlüssel bekannt wird, dann kann der Angreifer alle Daten
aus der Vergangenheit auch entschlüsseln.

-> Wie kann ich das Problem umgehen?

monsti schrieb:

Luxusproblem: Wenn alles nur mit einem AES Passwort verschlüsselt ist und dieser
"geheime" Schlüssel bekannt wird, dann kann der Angreifer alle Daten
aus der Vergangenheit auch entschlüsseln.

-> Wie kann ich das Problem umgehen?

Zum Vergrößern anklicken....

Das nennt man "Perfect Forward Secrecy" und läuft letztendlich darauf hinaus, dass die Datei jedes Mal mit einem anderen Schlüssel verschlüsselt gespeichert wird. Wie man diesen Schlüssel nun zwischen seinen Rechnern hin- und her schafft, ist dann natürlich ein Problem.