Bibliothek für Kryptoabsicherung von Read/Write-Operationen

Gegeben ist ein System, wo jeder beliebig Dateien lesen und schreiben kann. (Daten-)Sicherheit spielt also keine Rolle. Vertraulichkeit und Authentizität sollen jedoch gewährleistet werden.
Ich möchte per Kryptographie Schreib- und Leserechte durchsetzen.
Bisherige Überlegungen: Jede Datei ist AES-Verschlüsselt, das Passwort pro Teilnehmer per RSA verschlüsselt.
Read-Write kriegt man so abgebildet. Write-Only kriegt man auch hin, indem man per Public-Key verschlüsselt. Bei Read-Only fällt mir nicht so viel ein, man müsste eine Kopie der Datei per RSA verschlüsseln. Wenn diese dann verändert wird müsste auch das AES-Passwort geändert werden, damit der ursprüngliche Ersteller die Datei nicht mehr lesen kann.
Dann müssen überall noch Signaturen dran für die Authentizität.

Insgesamt ist das ziemlich komplex und wahrscheinlich werde ich was übersehen. Das gibt es sicher schon irgendwie fertig. Kennt jemand eine Bibliothek, die per AES/RSA Lese- und Schreibrechte so verwaltet, dass ich high-level-Funktionen habe, bei denen ich nur noch angeben muss, wer wie worauf zugreifen darf und das auch tatsächlich kryptographisch erzwungen wird? Ein vertrauenswürdiger Server soll nicht benutzt werden müssen.

Einfach gpg (bzw. GPGME) benutzen: http://www.gnupg.org/gph/en/manual/x110.html

Was für ein gegebenes System ist das eigentlich? Einfach ein normaler Ordner ohne weiteren Features? Dann geht Read-Only nicht. Read-Only kann durch Datei Löschen + neue Read-Only-Datei erstellen umgangen werden.

gpgpgpgpgpgpgpgpg schrieb:

Einfach ein normaler Ordner ohne weiteren Features?

Ja.

gpgpgpgpgpgpgpgpg schrieb:

Dann geht Read-Only nicht. Read-Only kann durch Datei Löschen + neue Read-Only-Datei erstellen umgangen werden.

Dafür gibt es die Signaturen. Die neu erstellte Datei hätte keine gültige Signatur des ursprünglichen Dateierstellers und würde entsprechend ignoriert oder anders behandelt werden.

AES und RSA laufen dank crypto++ bereits, Signieren kann man damit auch.
Vielleicht sollte ich erwähnen, dass das Ganze auf Gruppenrechten beruht. Das bedeutet, dass man als Mitglied einer Gruppe den Gruppenschlüssel entschlüsseln kann. Daher gibt es viele Dateien mit identischen Zugriffsrechten, die man irgendwie clever zusammenfassen kann. Ich will aber keine Datenbank bauen

nwp3 schrieb:

gpgpgpgpgpgpgpgpg schrieb:

Dann geht Read-Only nicht. Read-Only kann durch Datei Löschen + neue Read-Only-Datei erstellen umgangen werden.

Dafür gibt es die Signaturen. Die neu erstellte Datei hätte keine gültige Signatur des ursprünglichen Dateierstellers und würde entsprechend ignoriert oder anders behandelt werden.

Der ursprüngliche Dateiersteller kann die Datei aber problemlos abändern, ausser die Datei wurde zusätzlich von einer Vertrauensperson signiert.

Gruppen sind am einfachsten zentralisiert zu implementieren. Jede Gruppe besteht aus einem vertrauenswürdigen Gruppenchef, der einen public Gruppenkey veröffentlicht (und selber signiert). Alle Mitglieder erhalten den private Gruppenkey, bei Bedarf (z.B. Ausschluss eines Mitglieds) wird der public-Key erneuert.

Willst du das nicht so machen, musst du die Datei verschlüsseln und den Schlüssel mit den public-Keys jeden Gruppenmitglieds verschlüsseln.

Kann gpg alles schon von Haus aus, aber du kannst das auch gerne mit crypto++ nachimplementieren.

gpgpgpgpgpgpgpgpg schrieb:

Jede Gruppe besteht aus einem vertrauenswürdigen Gruppenchef, der einen public Gruppenkey veröffentlicht (und selber signiert). Alle Mitglieder erhalten den private Gruppenkey, bei Bedarf (z.B. Ausschluss eines Mitglieds) wird der public-Key erneuert.

So hatte ich das auch vor minus den Gruppenchef, bzw Gruppenchef ist ein beliebiger Nutzer der Gruppe "Admin".
Wer erneuert eigentlich den public-Key? Gibt es ein gpg --remove-access [public-key] [Datei], dass die Datei mit allen alten Teilnehmern neu verschlüsselt?
gpg --remove-from-group [personal public key] [group public key] müsste ja den group public key neu generieren, alle Dateien, die mit dem alten group-key verschlüsselt waren, neu verschlüsseln, und für alle Gruppenmitgliedern (die auch den korrekten alten group-key hätten entschlüsseln können) den neuen group-key mit ihren jeweiligen public-keys verschlüsseln. Ganz schön aufwändig, das will ich nicht alles selbst machen.

Dann habe ich noch das Problem, dass die Nutzerkeys auch in dem Ordner liegen, der public key im Klartext, der private key per Login AES-verschlüsselt.
Als Angreifer könnte man einfach einen neuen Gruppenschlüssel generieren und den Nutzern geben und zukünftige Dateien mitlesen. Also müssten die Nutzer den Gruppenkey signieren. Der neue Gruppenkey wäre nur gültig, wenn er mit dem alten Gruppenkey signiert ist.

Bitte sag mir, dass gpg das alles schon kann.

krümelkacker

nwp3 schrieb:

Bisherige Überlegungen: Jede Datei ist AES-Verschlüsselt, das Passwort pro Teilnehmer per RSA verschlüsselt.

Du meinst "Schlüssel" statt "Passwort".

Nochmal neu formuliert:

Guppenkey Variante A:
gen-key + gen-revoke + export, gruppe.gpg wird von einem Admin signiert und hochgeladen, das revokation certificate wird nur für Admins lesbar hochgeladen.
Jedes Mitglied erhält den private Key persönlich verschlüsselt.
Wenn ein Mitglied entfernt wird, gruppe.gpg revoken und erneut erstellen und private Key an alle Mitglieder versenden. Alte Keys werden in altekeys.gpg gespeichert, damit das neue Mitglied auch Zugriff auf Dokumente hat, die mit alten Keys verschüsselt wurden.
Eine Nachricht an Gruppe wird dann mit gruppe.gpg verschüsselt

Gruppenkey Variante B wäre ein vom Admin signierte Liste gruppenmitglieder.txt, Empfänger werden alle mit -r angegeben. Vorteil wäre ein etwas einfacheres Management, dafür können neue Mitglieder alte Dokumente nicht lesen, ausser sie werde neu verschlüsselt.

Die genauen Befehle müsste ich nachschauen, ich verwende gpg zu selten direkt. Aber
Neue Gruppe: gen-key + export mit sign + gen-revoke mit encrypt, beide Dateien hochladen
Mitglied löschen: edit-key revoke + encrypt private-gruppen-key recipient <alle Mitglieder>
Neues Mitglied: private-gruppen-key.gpg: decrypt + encrypt recipient <neues mitglied>
Für Gruppe verschlüsseln: import gruppe.gpg + encrypt recipient gruppe + hochladen
Dabei immer natürlich verify etc. Sind in der Shell jeweils 5-Zeiler.