Verschlüsselung von Schülerdaten auf dem eigenem Rechner mit EncFs

Ich habe als Linu­xer, Apple- und Goog­le­miss­trau­en­der end­lich mit EncFs einen Weg gefun­den, Daten von Schü­le­rin­nen und Schü­lern auf mei­nem Sys­tem so zu ver­schlüs­seln, dass auch Aspek­te des tech­ni­schen Daten­schut­zes gewahrt sind. EncFs arbei­tet datei­ba­siert, d.h. die ein­zel­ne Datei wird ver­schlüs­selt, sodass auch übli­che Linux-Back­up­kon­zep­te (etwa rsync) hier grei­fen. Das ist zwar nicht ganz so per­for­mant, wie eine con­tai­ner- oder volu­men­ba­sier­te Lösung, jedoch ist bei Bit­feh­lern nicht gleich das gan­ze Volu­me gefähr­det.

Wiki­pe­dia nennt fol­gen­de Vor- und Nach­tei­le von EncFs:

Auf­grund sei­ner datei­wei­sen Ver­schlüs­se­lung weist EncFS eini­ge Vor­tei­le gegen­über ande­ren Kryp­to­da­tei­sys­te­men auf:

  • Es belegt kei­ne fes­te Grö­ße auf dem Daten­trä­ger. Es wird nur der Platz belegt, der tat­säch­lich für die ver­schlüs­sel­ten Datei­en benö­tigt wird. Daten kön­nen in EncFS gespei­chert wer­den, bis das Datei­sys­tem, in dem es sich befin­det, voll ist.
  • Tei­le des über EncFS-ver­schlüs­sel­ten Datei­sys­tems kön­nen auf ver­schie­de­nen Daten­trä­gern abge­legt sein. Zum Bei­spiel kann ein Ord­ner im (ver­schlüs­sel­ten) Quell­ver­zeich­nis per NFS ein­ge­hängt und ein wei­te­rer lokal vor­han­den sein.
  • Daten­si­che­rungs­pro­gram­me kön­nen gezielt die ein­zel­nen ver­än­der­ten ver­schlüs­sel­ten Datei­en sichern, die sich in der Zwi­schen­zeit geän­dert haben. Es muss nicht jedes Mal die gesam­te Par­ti­ti­on gesi­chert wer­den, wie es bei ver­schlüs­sel­ten Par­ti­tio­nen der Fall ist.

Auf­grund die­ses Ansat­zes erge­ben sich jedoch auch eini­ge Nach­tei­le:

  • Per EncFS abge­spei­cher­te Daten wei­sen die­sel­ben Beschrän­kun­gen auf, wie das Datei­sys­tem, in dem der Quell­ord­ner liegt.
  • Eine Frag­men­tie­rung der ver­schlüs­sel­ten Daten führt zu einer Daten­frag­men­tie­rung im Quell­ver­zeich­nis.
  • Die Rech­te­ver­wal­tung wird nicht neu imple­men­tiert, somit kann jeder die Anzahl der Datei­en, ihre Zugriffs­rech­te, Grö­ße und Län­ge des Datei­na­mens (der Datei­na­me sel­ber wird jedoch mit­ver­schlüs­selt) und das Datum der letz­ten Ände­rung sehen.

Quel­le: http://de.wikipedia.org/wiki/EncFS#Vor-_und_Nachteile

Ich ver­lie­re etwas Kom­fort, was ich aber gar nicht ein­mal so schlecht fin­de: Will ich auf mei­ne ver­schlüs­sel­ten Datei­en zugrei­fen, muss ich zuvor noch ein klei­nes Script aus­füh­ren, nähe­res im Ubun­tu-Wiki.

So blei­ben die Datei­en auch im Betrieb ver­schlüs­selt, wenn ich sie nicht benö­ti­ge. Sind die Datei­en entschlüs­selt, so habe ich ein­fach ein Ver­zeich­nis im Datei­baum, in das ich ganz nor­mal spei­chern kann. Sind die Datei­en verschlüs­selt, ist die­ses Ver­zeich­nis schlicht leer. Sie lie­gen eigent­lich in einem ver­steck­ten Ver­zeich­nis – es beginnt mit einem Punkt und wird so in Linux­fi­le­ma­na­gern meist nicht ange­zeigt. Es lässt sich aber zugäng­lich machen – nur lie­gen dar­in eben nur ver­schlüs­sel­te Datei­en, die frei­lich über Meta­da­ten wie Name, letz­tes Zugriff­da­tum, Besit­zer etc. etwas von sich preis­ge­ben – nur an die Inhal­te der Datei­en kommt man halt nicht. EncFs gibt es auch für Win­dows – es kann dort aber nur unter Schmer­zen instal­liert wer­den.

(nicht nur) Truecrypt und Datenintegrität

True­crypt ver­schlüs­selt Daten zuver­läs­sig und stellt durch geeig­ne­te Maß­nah­men (z.B. Zufalls­schlüs­sel­er­zeu­gung durch Maus­be­we­gun­gen) sicher, dass im Ver­lust­fall des Geräts sen­si­ble Infor­ma­tio­nen nicht an Drit­te wei­ter­ge­ge­ben wer­den. Im Prin­zip gilt das für vie­le wei­te­re Ver­schlüs­se­lungs­sys­te­me auch.

Ein beson­de­res Sicher­heits­merk­mal von True­Crypt ist das Kon­zept der glaub­haf­ten Abstreit­bar­keit (eng­lisch plau­si­ble denia­bi­li­ty), also die Mög­lich­keit, bewusst Spu­ren ver­steck­ter Daten zu ver­mei­den. Dadurch soll es unmög­lich sein, die Exis­tenz ver­schlüs­sel­ter Daten nach­zu­wei­sen. True­Crypt bie­tet hier­für eine beson­de­re Funk­ti­on: Ver­steck­te Con­tai­ner (Hid­den Volu­mes) kön­nen inner­halb des frei­en Spei­cher­plat­zes eines ande­ren ver­schlüs­sel­ten Volu­mes ver­steckt wer­den. Wird man z. B. gezwun­gen, das Pass­wort für das Volu­me her­aus­zu­ge­ben, gibt man nur das Pass­wort für das äuße­re Volu­me her­aus; das ver­steck­te und mit einem ande­ren Pass­wort ver­schlüs­sel­te Volu­me bleibt unent­deckt. So sieht ein Angrei­fer nur unwich­ti­ge Ali­bi-Daten, die ver­trau­li­chen Daten sind ver­schlüs­selt im frei­en Spei­cher­platz des ver­schlüs­sel­ten Volu­mes verborgen.Allerdings ist zu beach­ten, dass auf dem phy­si­schen Daten­trä­ger, im Betriebs­sys­tem oder inner­halb der ver­wen­de­ten Pro­gram­me Spu­ren zurück­blei­ben kön­nen, die die Exis­tenz des ver­steck­ten Volu­mes für einen Angrei­fer offen­ba­ren.

Quel­le: http://de.wikipedia.org/wiki/Truecrypt#Konzept_der_glaubhaften_Abstreitbarkeit

In einem Staat ohne Fol­ter sind der­ar­ti­ge Maß­nah­men natür­lich hof­fent­lich über­flüs­sig – obwohl schon über­legt wird, die Nich­t­her­aus­ga­be von Pass­wor­ten im Ermitt­lungs­fall unter Stra­fe zu stel­len. True­crypt gilt zumin­dest dabei als so sicher, dass es auch bei der Ver­ar­bei­tung per­so­nen­be­zo­ge­ner Daten auf pri­va­ten IT-Gerä­ten von Leh­rer­rin­nen und Leh­rern emp­foh­len wird. Zudem treibt es Regie­run­gen offen­bar auch dazu, Geset­ze wie RIPA zu erlas­sen – ein wei­te­res, star­kes Indiz für die Effi­zi­enz von Ver­schlüs­se­lungs­ver­fah­ren.

In True­crypt-Con­tai­nern lie­gen nach heu­ti­gen Maß­stä­ben Daten sicher vor dem Zugriff drit­ter Per­so­nen. Man soll­te dabei aber nicht ver­ges­sen, dass True­crypt­con­tai­ner nach bestimm­ten Prin­zi­pi­en gebaut sind:

  1. Ohne zuge­hö­ri­gen Schlüs­sel sind ihre Inhal­te nicht wie­der­her­stell­bar
  2. Sie müs­sen sich gän­gi­gen foren­si­schen Ana­ly­se­me­tho­den ent­zie­hen, um das Kon­zept der glaub­haf­ten Abstreit­bar­keit zu rea­li­sie­ren, d.h. ins­be­son­de­re auch vor Daten­wie­der­her­stel­lungs­funk­to­nen des Betriebs­sys­tems.

In der Tat las­sen sich z.B. unter Linux mit True­crypt ver­schlüs­sel­te Datei­sys­te­me nur im geöff­ne­ten Zustand auf Kon­sis­tenz prü­fen – und das muss dann auch noch manu­ell gesche­hen. Daten­ret­ter selbst kapi­tu­lie­ren vor den Risi­ken bezüg­lich der Daten­in­te­gri­tät bei ver­schlüs­sel­ten Volu­mes und geben ver­hält­nis­mä­ßig kom­ple­xe Back­u­p­emp­feh­lun­gen. Ich bin ja „Nerd“, muss aber ein­ge­ste­hen, dass ich nur Daten­si­che­run­gen mache, die ich auch auto­ma­ti­sie­ren kann, weil ich sie sonst schlicht gar nicht mache.

Wenn man also Leh­rern aus Grün­den der Daten­si­cher­heit die Ver­schlüs­se­lung vor­schreibt, muss man ihnen kon­se­quen­ter­wei­se aus Grün­den der Daten­in­te­gri­tät auch die im Ver­gleich zu unver­schlüs­sel­ter Daten­hal­tung kom­ple­xe­re Backup­pro­ze­dur vor­schrei­ben.

Das könn­te ein Akzep­tanz­pro­blem geben und zusätz­lich vie­le tech­nisch voll­kom­men über­for­dern. Selbst die „Nerds“ unter den Lehr­kräf­ten hal­ten ein RAID1 oder 10 für eine aus­rei­chen­de Daten­si­che­rung (das ist natür­lich schon deut­lich mehr an Sicher­heit als ein ein­zel­ner Daten­trä­ger).

Fazit

True­crypt ist damit wohl sicher. Ins­be­son­de­re für kurz­fris­ti­gen Trans­port von Daten durch nicht ver­trau­ens­wür­di­ge Net­ze. Um Daten damit län­ger und ver­läss­lich auf­zu­be­wah­ren, ist mein per­sön­li­cher Schwei­ne­hund zu groß.

Was tun?

Ich bin gera­de dabei ein voll­schlüs­sel­tes Ubun­tu mit LUKS auf mei­nem Net­book auf­zu­set­zen, auf wel­chem ich Schü­ler­da­ten ver­wal­te – das basiert auf dm-crypt und der Quell­code dazu liegt im Gegen­satz zu dem von True­crypt offen. Das geht bei Ubun­tu völ­lig trans­pa­rent (= ein Haken mehr) wäh­rend der Instal­la­ti­on. Das Ding bekommt zusätz­lich einen pass­wort­ge­schütz­ten Bild­schirm­scho­ner (auch üblich bei Ubun­tu). Im Ergeb­nis hat man einen Linux­desk­top, der sich in nichts von einem nor­ma­len Linux­desk­top unter­schei­det – sehr bequem. Soviel zur Daten­si­cher­heit.

Die Daten­in­te­gri­tät wer­de ich wohl durch Aus­dru­cke her­stel­len, zu denen ich mich wohl jeden Monat zwin­gen muss – unser Lan­des­da­ten­schutz­be­auf­trag­te wird das im Prüf­fall auch tun und von mir for­dern.

Verschlüsselung in Webapplikationen (MD5)

Pass­wör­ter gehö­ren nicht in die Hän­de von Drit­ten, auch nicht in die von Admi­nis­tra­to­ren. Daher wur­den für die Spei­che­rung von Pass­wör­tern soge­nann­te Fall­tür­me­cha­nis­men (trap­door mecha­nisms) ent­wi­ckelt:

Es ist zwar mög­lich, ein Pass­wort zu ver­schlüs­seln, nicht jedoch es wie­der zu ent­schlüs­seln.

Der Ver­schlüs­se­lungs­al­go­rith­mus funk­tio­niert also genau wie eine Fall­tür nur in eine Rich­tung. Das mag auf den ers­ten Blick sinn­los erschei­nen, ist aber eigent­lich sehr pfif­fig. Neh­men wir als Bei­spiel den weit ver­brei­te­ten MD5-Algo­rith­mus. Mit die­sem sichert fast jede Web­an­wen­dung in PHP ihre Pass­wör­ter ab. Dabei wird aus

123456=> MD5-Ver­schlüs­se­ler => e10adc3949ba59abbe56e057f20f883e

Die­se lan­ge Zei­chen­ket­te sieht der Admin. Er weiß aber des­we­gen das Pass­wort im Klar­text noch nicht, da der Weg

e10adc3949ba59abbe56e057f20f883e => MD5-Ent­schlüs­se­ler (Gibt es nicht) => Pass­wort

prin­zip­be­dingt ver­sperrt ist. Die dabei ent­ste­hen­de, lan­ge Zei­chen­ket­te wird „Hash“ genannt.

Wenn man sich nun an einer Web­an­wen­dung (Mood­le, Joom­la, egroup­ware …) anmel­det, macht die Web­an­wen­dung fol­gen­des:

Benut­zer gibt Pass­wort im Klar­text ein => MD5-Ver­schlüss­ler => Hash1

Die­ser Hash1 wird nun mit dem Hash – nen­nen wir ihn Hash2 – ver­gli­chen, der in der Daten­bank für den User gespei­chert ist (er könn­te etwa bei der Regis­trie­rung erzeugt wor­den sein).

Stim­men bei­den Hash­es über­ein, hat der User das kor­rek­te Pass­wort ein­ge­ge­ben, weil der Ver­schlüs­se­lungs­me­cha­nis­mus ja immer gleich ist. Stim­men die Hash­es nicht über­ein, muss der Benut­zer ein fal­sches Pass­wort ein­ge­ge­ben haben.

Soweit so gut. Das ist auch die Erklä­rung dafür, dass einen – so man sein Pass­wort ver­ges­sen hat – stets ein neu­es Pass­wort zuge­wie­sen wird, denn der Admin kann das alte Pass­wort ja nicht wis­sen, son­dern ledig­lich ein neu­es set­zen.

Eigent­lich hört sich das Gan­ze recht sicher an – ist es bloß nicht, denn es gibt Angrif­fe gegen die­ses Ver­fah­ren, die aber alle­samt vor­aus­set­zen, dass der Angrei­fer an den Hash kommt.

Wei­ter­le­sen