SparkleShare: Verschlüsselung der Daten mit GPG

Veröffentlicht am


Ein weiterer Artikel in meiner SparkleShare-Serie. Hier noch einmal eine Übersicht über die (geplanten) Themen der Serie:

Nachdem es im vorigen Artikel um die Konfiguration eines eigenen SparkleShare-Servers ging, möchte ich also nun zeigen, wie die Daten mit Hilfe von GnuPG vor dem Upload verschlüsselt und natürlich beim Herunterladen entschlüsselt werden können.

Dabei möchte ich zunächst erwähnen, dass für die Verschlüsselung nicht zwingend ein eigener Server betrieben werden muss. Das wird klar, wenn man erkennt, dass der Server mit der Verschlüsselung überhaupt nichts zu tun hat – ja noch nicht einmal etwas davon mitbekommt.

Nebenbei bemerkt hat auch der SparkleShare-Client nichts mit der Verschlüsselung zu tun. Die Ver- und Entschlüsselung wird rein innerhalb von GIT verwaltet.

GnuPG

Für die Verschlüsselung wird GnuPG zuständig sein. Außerdem werden wir den GPG-Agent benutzen, der zumindest dann wichtig ist, wenn man einen GPG-Schlüssel mit Passphrase benutzt. Dann muss man nämlich nicht immer wieder sein Kennwort eingeben, um den Schlüssel verwenden zu können.

Installation

Mit folgendem Kommando wird also zunächst einmal sichergestellt, dass die benötigten Pakete installiert sind. GnuPG sollte bei Ubuntu normalerweise vorinstalliert sein, der Agent aber nicht.

sudo apt-get install gnupg gnupg-agent

GPG-Key erstellen

Um ein Schlüsselpaar zu erzeugen, wird das folgende Kommando verwendet:

gpg --gen-key

Dabei werden einige Fragen gestellt, bei denen man normalerweise größtenteils die vorbelegte Auswahlmöglichkeit übernehmen kann. Alle wissenswerte Informationen findet ihr aber im ubuntuusers.de-Wiki. Deshalb macht es wohl keinen Sinn, hier alles noch einmal zu wiederholen…

Verschlüsselung aktivieren

Um die Verschlüsselung für ein Repository zu aktivieren, wechselt man zunächst in das lokale Repository-Verzeichnis, also beispielsweise:

cd ~/SparkleShare/meinrep

Von dort aus gesehen öffnet man dann die Datei .git/config im Editor und fügt die folgenden Zeilen an den bereits bestehenden Inhalt an:

[filter „crypto“]
    smudge = gpg -d -q –batch –no-tty -r MEINEKEYID
    clean = gpg -ea -q –batch -no-tty -r MEINEKEYID

So konfigurieren wir einen Filter namens crypto: Die clean-Zeile gibt den Befehl an, der vor dem Einchecken von Dateien in das Server-Repository auf die Dateien angewendet werden soll, die smudge-Zeile den Befehl, der beim Auschecken aus dem Server-Repository greifen soll.

Anstelle von MEINEKEYID muss die ID des GPG-Keys gesetzt werden, der für die Ver- und Entschlüsselung verwendet werden soll. Um die Key-ID zu ermitteln, listet man sich zunächst mit folgendem Kommando die vorhandenen Keys auf:

gpg --list-keys

Die Ausgabe sieht dann z.B. so aus:

/home/meinuser/.gnupg/pubring.gpg
-------------------------------
pub   2048R/18916A46 2011-09-16
uid                  Vorname Nachname <meine@email.com>
sub   2048R/6C395CF1 2011-09-16

In der mit pub beginnenden Zeile findet man nun die ID des gesuchten Keys – in diesem Fall ist die ID 18916A46.

Nun haben wir zwar einen crypto-Filter, der aber noch nicht eingesetzt wird. Wir müssen noch definieren, für welche Dateien dieser Filter gelten soll. Dazu öffnen bzw. erzeugen wir die Datei .git/info/attributes (ebenfalls relativ vom Repository-Verzeichnis aus gesehen) im Editor und fügen die folgenden Zeilen ein. Die Datei sollte normalerweise noch nicht existieren.

* filter=crypto

Damit legen wir fest, dass der Filter crypto für alle Dateien (Wildcard *) angewendet werden soll.

Fertig! Dateien, die ab jetzt in das Repository gelegt und hochgeladen werden, werden nun mit GPG verschlüsselt auf dem Server abgelegt.

Da nur für neue Dateien die Verschlüsselung greift, sollte natürlich nur für eine neues, leeres Repository die Verschlüsselung aktiviert werden. Sonst ergibt sich ein Server-Repository, in dem verschlüsselte und nicht verschlüsselte Dateien gemeinsam finden.

Neuen Client an verschlüsseltes Repository anbinden…

In eine etwas verzwickte Situation kommt man, wenn man die Synchronisation mit einem bereits bestehenden, verschlüsselten GIT-Repository auf einem neuen Client einrichten möchte. Beispielsweise, weil man den Server mit mehreren Clients synchronisieren möchte, oder weil man einen Client komplett neu installiert und daher auch SparkleShare frisch installiert hat.

Verzwickt wird die Situation, weil durch das Konfigurieren des Repository im SparkleShare-Client auch gleich die Synchronisation gestartet wird – noch bevor die Konfiguration der Verschlüsselung vorgenommen wurde. Die Folge: die Daten landen zunächst einmal verschlüsselt auf dem Client.

Die Frage ist nun also: wie kann dafür gesorgt werden, dass die Daten entschlüsselt werden?

Die einzige Antwort, die ich darauf gefunden habe, ist, das lokale GIT-Verzeichnis nach Einrichtung der Verschlüsselung zurückzusetzen, so dass also noch einmal alle Daten frisch vom Server abholt werden. Es wird hier als Beispiel in das Verzeichnis meinrep gewechselt, um dieses zurückzusetzen – ihr müsst das natürlich auf eure Gegebenheiten anpassen. Der SparkleShare-Client sollte währenddessen besser nicht laufen.

cd ~/SparkleShare/meinrep
git reset --hard HEAD

Im Normalfall wird also dann die komplette Datenmenge ein zweites Mal heruntergeladen. Bei wirklich großen Datenmengen natürlich eher nicht optimal. Besser wäre also, dass SparkleShare die Erstsynchronisation nicht automatisch und zwingend durchführen würde. Vielleicht bekommt man das mit irgendeinem Trick hin? Falls ihr eine Idee habt, dann gerne her damit!

Mehr…

An dieser Stelle möchte ich noch einmal auf die Serie hinweisen. Lest also auch die ersten beiden Artikel und seid gespannt auf den noch folgenden. Eine Übersicht über die bereits erschienenen und noch geplanten Artikel findet ihr ganz oben.


Dieser Artikel wurde in der/den Kategorie(n) _Anwendungen, Planet-U, Praxis veröffentlicht und mit den Tags , , , , , , versehen.

7 Kommentare zu SparkleShare: Verschlüsselung der Daten mit GPG

  1. Pingback: SparkleShare: Einrichtung und Betrieb eines eigenen Servers | ME and my U

  2. Pingback: SparkleShare: freie Alternative zu Dropbox / Ubuntu One ? | ME and my U

  3. Kommentar von Georg
    19. Oktober 2011, 08:29 Uhr.

    Hi,
    super Ding, habe es jetzt auch installiert, kannte es schon vorher, war aber noch nicht wirklich überzeugt. Doch als mit Ubuntu One nur Probleme gemacht hat, habe ich es jetzt installiert, in Kooperation mit meinem VServer läuft es prächtig. Ich wollte nur kurz einen weiteren, etwas einfacheren Weg der verschlüsselung aufzeigen: http://bit.ly/nIoqIP Benutze das schon ewig mit Dropbox und zuletzt Ubuntu One. Doch Sparkleshare hat für mich den Knoten platzen lassen, ich besitze auf dem Vserver ca. 100GB freien Speicherplatz, der jetzt wunderbar für die Cloud genutzt wird, per ssh & Verschlüsselung ist für SIcherheit gesorgt und es ist schnell 😉 Grüße

    • Kommentar von Gerald
      19. Oktober 2011, 09:51 Uhr.

      Danke dir für dein Feedback und natürlich auch für den Tipp bzgl. Verschlüsselung. Das muss ich mir demnächst mal genauer anschauen… :)
      Gruß, Gerald

  4. Kommentar von Georg
    20. Oktober 2011, 16:08 Uhr.

    Nicht zu lange 😉 Ich warte schon auf das Webinterface 😛

    • Kommentar von Gerald
      20. Oktober 2011, 16:12 Uhr.

      Sorry, ja, der vierte Teil verspätet sich etwas. Nicht zuletzt weil das Oneiric-Release dazwischenkam… :) Aber kommt bald…

  5. Pingback: SparkleShare als OpenSource-Alternative zu Dropbox « Linux NetMagLinux NetMag

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>