Die Owncloud 5 Encryption App

Die Ankündigung von Frank Karlitscheck auf der Owncloud Announcement Maillinglist, dass die neue Encryption App in Owncloud 5 fertig für den produktiven Einsatz ist, habe ich zum Anlass genommen die App auszuprobieren.
Wie gewohnt kann Encryption App (0.4) von Administrator_innen unter Apps aktiviert werden. Danach werden die Daten der Nutzer_innen beim nächsten Einloggen mit deren Log-in Passwort (AES-128) verschlüsselt (werden die Daten mit anderen Nutzer_innen oder über einen Link geteilt haben diese selbstverständlich auch Zugriff, das funktioniert mit entsprechend verschlüsselten file-keys, welche für jede Datei erstellt werden) , d.h. es sollte Wert auf vernünftige Passwörter gelegt werden.
Die Dateien sind dann einzeln verschlüsselt, die Dateinamen bleiben unverschlüsselt. Der Zugriff mit SyncClient und Android App waren kein Problem.
Wichtig zu wissen ist, dass es sich (wie in diesem Artikel beschrieben) um eine serverseitige Verschlüsselung handelt, d.h. die Serveradministrator_innen bzw. Personen die die Kontrolle über den Server haben, können potenziell auf die unverschlüsselten Daten zugreifen, was den Nutzen der Encryption App doch etwas fragwürdig erscheinen lässt. Zumindest scheint die Verschlüsselung des private Key mit den Passwörtern der Nutzer_innen einen gewissen Schutz im Falle von Datendiebstahl zu bieten, allerdings bin ich auch kein_e Verschlüssselungsexpert_in. Ansonsten wird im oben genannten Artikel darauf verwiesen, dass die Verschlüsselung bei der Nutzung der ‚external storage app‘ einen Schutz für die Daten bietet, welche damit beispielsweise bei Dropbox hochgeladen werden. Außerdem wird auf die Möglichkeit verwiesen in die Verschlüsselungsarchitektur zu einem späteren Zeitpunkt auch clientseitige Verschlüsselung zu integrieren, bleibt zu hoffen, dass dies tatsächlich irgendwann passiert.
Auf jeden Fall ist es gut zu sehen, das die Verschlüsselung in Owncloud 5 Fortschritte macht!

12 Gedanken zu “Die Owncloud 5 Encryption App

  1. Danke für diesen Test, werde in einem entsprechenden Artikel in meinem Blog auf dich verweisen …
    Eine Bitte: würdest du bitte dieses „_innen“ weglassen? Wenn es deinen Überzeugungen entspricht solltest du stattdessen vielleicht das generische Femininum verwenden. Mit diesen „_innen“ werden Texte schwer lesbar …
    Gruss
    Karsten

      • In der deutschen Sprache nutzt man für gewöhnlich einheitliche Wörter. So spricht man im allgemeinen immer von dem Autofahrer, gleichgültig welches Geschlecht der Fahrer hat. Das ist weder falsch noch diskriminierend. Es ist eine allgemein gültige und von jedermann ;) bekannte Form.

        Wenn man denn unbedingt geschlechtsspezifische Texte verfassen möchte, dann sind schon rein aus Gründen der Optik längere Sätze sinnvoll. Also Sätze in denen doppelt gemoppelt beide separat erwähnt werden.

      • Danke für den Test, auch wenn sich das Ganze ja kaum vielversprechend anhört.

        Ich finde es super, dass du genderst. Mir ist das auch erst durch die Kommentare wirklich aufgefallen – dein Text ist also sehr wohl gut lesbar.

        @shadow: Sprache entsteht nicht einfach urknall-ähnlich aus dem Nichts. Sie beschreibt auf einer Meta-Ebene komplexe kulturelle und gesellschaftliche Zusammenhänge. Sprache ist also ein historisch gewachsener Spiegel unseres Miteinanders. „Der Autofahrer“ ist ein gutes Beispiel hierfür, da es für Frauen lange verpönt war am Steuer eines Autos zu sitzen. Ein noch viel besseres Beispiel jedoch ist (die Debatte über) das Gendern selbst – metameta.

  2. Dem letzten Satz kann ich voll zustimmen.

    Die Bedenken teile ich, und man muss anmerken, dass 128-Bit-Veschlüsselung schon lange nicht mehr als Stand der Technik und unsicher gilt. Selbst vor 256 Bit muss man schon warnen (Stichwort PRISM). Truecrypt, das als unknackbar gilt, arbeitet mit 1024 Bit, und das je nach Konfiguration sogar mehrfach hintereinander.

    Clientseitige Verschlüsselung lässt sich problemlos durch gängige Verfahren, wie GnuPGP, encfs, ecryptfs etc. erreichen. Einfach lokal anwenden und verschlüsselte Datei in die Cloud „werfen“. Mach ich z.B. mit UbuntuOne so; der „Ubuntu One“-Ordner enthält einfach einen verschlüsselten Unterordner, in dessen entschlüsseltem Spiegel (natürlich außerhalb) die Daten liegen, auf die vom home-Verzeichnis aus Softlinks zeigen. Einmal eingerichtet, kann Beliebiges synchronisiert werden, ohne dass sich der Benutzer Gedanken über Verschlüsselung in der Cloud machen muss. (Jedoch arbeitet encfs bzw. ecryptfs nur mit 256 Bit, ist also für brisante Daten nicht geeignet.)

    (P.S.: Die „Gendergerechtigkeit“ macht den Blogeintrag fast unlesbar…)

    • Bitte führen Sie einen Beleg für Ihre Behauptung, symmetrische Chiffren mit einer Schlüssellänge von 128-Bit seien „schon lange“ nicht mehr Stand der Technik oder gar „unsicher“. Bei AES liegt die Sicherheit nicht in der Schlüssellänge, sondern vor allem in der Rundenzahl des Verschlüsselungsalgorithmus. So waren dann auch alle bisher bekannten Angriffe auf AES darauf aus, die Rundenzahl des Algorithmus zu reduzieren. Sollte in der Zukunft ein Verfahren veröffentlicht werden, welches AES bricht, dann darf man getrost davon ausgehen, dass damit AES-128 und AES-192 und AES-256 gleichzeitig zumindest so weit gebrochen werden, dass der gesamte AES-Algorithmus als unbrauchbar gelten müsste – egal welche Schlüssellänge.

      Eine mittlerweile schon etwas ältere Empfehlung (weil aus Juli 2009) vom bekannten Kryptographieexperten Bruce Schneier argumentiert vor dem Hintergrund eines seinerzeit veröffentlichten Angriffs auf AES ähnlich und schließt mit den Worten: „Und für neue Anwendungen empfehle ich, dass die Leute nicht AES-256 nutzen. AES-128 bietet mehr als genug Sicherheitsmarge für die übersehbare Zukunft.“

      https://www.schneier.com/blog/archives/2009/07/another_new_aes.html

      Im selben Artikel empfiehlt Bruce Schneier lediglich, die Rundenzahl des AES-Algorithmus zu erhöhen. Das ist dann zwar nicht mehr Standardkonform, schlägt aber allen bisher bekannten Angriffen auf AES ein Schnippchen. Ihre Aussage, 128-Bit lange symmetrische Schlüssel seien nicht Stand der Technik oder veraltet, ist falsch, um nicht zu sagen von Halbwissen geprägter Unsinn.

      Die Wahl von AES-128 für OwnCloud ist daher durchaus wohl begründet und sinnvoll. Schwächen oder Gefahren ergeben sich hier wohl eher aus der Schlüsselverwaltung. Hierauf sollte man mehr Augenmerk legen, als auf die Schlüssellänge.

  3. Kann es sein, dass die bereits vorhandenen Dateien nicht verschlüsselt werden? Habe es gerade eingerichtet und mich neu eingeloggt. Er hat auch Dateien und Verzeichnisse angelegt, die auf Verschlüsselung hindeuten. Aber vorhandene Dateien sind nicht verschlüsselt (sehe ich via FTP). Wenn ich aber neue Dateien hochladen (via Webfrontend), dann werden diese verschlüsselt.

  4. hi, hier sollte nicht vergessen werden, wofür owncloud gemacht ist: ein/e jede/r soll die möglichkeit haben, sich einen online-speicher mit einfach funktionierender sync’n’share-funktion auf eigener hardware bzw. eigenem webspace zu installieren, um nicht von amerikanischen anbietern und undurchsichtigen datenschutz- und nutzungsbedingungen abhängig zu sein. bei der server-seitigen verschlüsselung kennt der admin immer den schlüssel, was aber in dem fall, daß man selbst oder eine persönlich bekannte und vertrauenswürdige person (ein familien- oder teammitglied, der/die vereinsvorsitzende etc.) admin ist, nicht weiter schlimm ist. sie dient vor allem dem schutz vor datendiebstahl und ist nicht geeignet, 100-prozentige vertraulichkeit zu garantieren. dafür reicht die 128 bit-verschlüsselung aus, denn mit einem klug gewählten paßwort wird es schon ziemlich aufwendig, das zu knacken. außerdem muß der schlüssel bekannt sein, damit freigaben funktionieren. wer wichtige daten auf einen cloud-speicher schiebt, sollte sie zuvor client-seitig verschlüsseln. es wäre also schön, wenn der owncloud-client zukünftig die option bieten würde, automatisch einen verschlüsselten container im owncloud-ordner auf der lokalen festplatte anzulegen. diese option sollte es für jeden einzelnen share geben, den man einrichten möchte, weil ja nicht alles client-seitig verschlüsselt werden soll, schließlich will man auf manche dateien von unterwegs per web-interface zugreifen oder sie freigeben (und dafür ist dann die server-seitige verschlüsselung gedacht).

  5. Diese durchgegenderten Texte sind fürchterlich.

    Vor allem

    „allerdings bin ich auch kein_e Verschlüssselungsexpert_in“

    ist an Lächerlichkeit nicht zu überbieten. Oder kennst du dein eigenes Geschlecht nicht?!

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s