[Crosspost] Neulich, im Krypto-Sumpf... verschlüsseln und signieren mit OpenSSL

[daemotron]

Na ja, wir reden hier über Backups. Wenn ich einen Angreifer auf dem System habe, der eine Datei mit Owner root:wheel und 0400 auslesen kann, dann kann er auch die Daten lesen, die ich in das Backup packe. Vulgo: You lost, Game Over.

Mein Ziel ist aber, genau in einem solchen Szenario wenigstens zu verhindern, dass der Angreifer (der dann auch Zugriff auf den Backup-Server erlangt hat, da die Credentials ebenfalls auf dem Rootie liegen müssen) meine Backups sabotiert. Ich kann ihn zwar nicht davon abhalten, sie zu löschen - aber wenigstens will ich ihn davon abhalten, sie durch verseuchte Dateien zu ersetzen, die mir beim Restore sofort wieder eine Laus in den Pelz setzen.

Allerdings ist mir noch kein praktikabler Weg eingefallen, wie ich verhindern kann, dass ein Angreifer, der Zugang zu exakt denselben Mitteln hat wie ich selbst bei der Backup Erstellung damit ein verseuchtes Backup erstellt und mir unterschiebt. Das ist übrigens ein grundsätzliches Problem und völlig unabhängig vom konkret eingesetzten Verschlüsselungsverfahren - mit GnuPG hätte ich genau dasselbe Problem.

Die einzige Möglichkeit wäre IMO, die Signaturdaten (egal ob RSA Signatur oder HMAC) getrennt von den Backups aufzubewahren, sie sozusagen an eine Art elektronischen Briefkasten zu senden, wo der Angreifer sie nicht rausbekommt, weil man für's Einwerfen zwar keine Credentials benötigt, wohl aber für's rausholen. Theoretisch ginge dafür so etwas wie ein Freemail-Account - die Signaturen brauchen ja keine Confidentiality, sondern lediglich Integrity.

Die Frage ist also: gibt es ggf. ein Verfahren, dass einen solchen elektronischen Briefkasten nachbildet, dabei aber etwas zuverlässiger ist als die üblichen Freemail-Verdächtigen? Ein eigener Mailserver müsste ja wieder auf einem Rootie laufen, und dann hätten wir ein Henne-Ei-Problem...

[Joe User]

Im Zweifel könnte man dafür Google Drive, Dropbox oder ähnliche Dienste nutzen, wobei man deren Zugangsdaten dann ebenfalls vorhalten müsste, ergo erneut Henne-Ei.
Bei Mail besteht aber das gleiche Problem, denn zum automatisierten Abholen der Keys/Sig benötigt man ebenso Zugangsdaten.

Um es "sicher" zu machen, müsste man das Backup manuell starten und Keys/Sig @Home auf einem USB-Stick lagern.

[daemotron]

Bei Mail besteht aber das gleiche Problem, denn zum automatisierten Abholen der Keys/Sig benötigt man ebenso Zugangsdaten.

Nicht ganz - das Abholen würde ja nicht vom Server aus geschehen, sondern von einem "sicheren" Rechner von zu Hause aus. Wichtig ist bei dem Verfahren nur, dass das "einwerfen" der Signaturen eine Einbahnstraße ist. SMTP wäre sicherlich Overkill, ein einfacher TCP Listener (à la netcat o. ä.) auf einem Cloud Storage oder VPS würde es ja auch schon tun. Der Angreifer kann zwar auch forged Signaturen einwerfen, aber wenn ein Zeitstempel mit erfasst wird, ist eigentlich schon gut ersichtlich, welchen Signaturen man noch trauen kann.