Es gibt in Nds. einen neuen Erlass zur Verarbeitung schulischer Daten auf Privatgeräten der Lehrkräfte …

… der im Netz momen­tan für sehr viel Furo­re sorgt, denn es gibt eine Schlüs­sel­stel­le:

Die Spei­che­rung per­so­nen­be­zo­ge­ner Daten auf dem Fest­spei­cher pri­va­ter mobi­ler End­ge­rä­te (Smart­phones und Tablets) ist nicht zulässig.

Damit sind auf den ers­ten Blick Noten­ver­wal­tungs­pro­gram­me wie Tea­cher­Tool auf pri­va­ten Gerä­ten von Lehr­kräf­ten unzu­läs­sig, weil Tei­le der Daten­hal­tung dabei auf dem End­ge­rät selbst gesche­hen. Auf den zwei­ten Blick gibt es dann die­ser Les­art Unsi­cher­hei­ten, da nicht immer klar gere­gelt ist, ob es sich bei ver­schlüs­sel­ten Daten wirk­lich um per­so­nen­be­zo­ge­ne Daten han­delt. Lei­der ist das immer eine Ein­zel­fall­ent­schei­dung. Tea­cher­Tool ist hier von Hau­se aus auf einem guten Weg: Back­ups las­sen sich schon heu­te extern erstel­len.

Die Ziel­rich­tung des eigent­li­chen Sat­zes scheint mir klar zu sein: Man möch­te pri­va­te Gerä­te als Zugangs­ge­rä­te für die Ver­ar­bei­tung schu­li­scher Daten auf exter­nen Ser­vern (etwa denen der Schu­le) ermög­li­chen. Auch die Ver­ar­bei­tung auf Ange­bo­ten von Dritt­an­bie­tern, z.B. Schul­ma­na­ger Online, ist mög­lich, wenn die Schu­le sich dabei qua­si stell­ver­tre­tend für alle Lehr­käf­te um die Ein­hal­tung der Regu­la­ri­en küm­mert (z.B. um eine Ver­ein­ba­rung zur Auf­trags­da­ten­ver­ar­bei­tung – ADV). Außer­dem ist eine ver­schlüs­sel­te Daten­über­tra­gung Pflicht, wie sie heu­te aber i.d.R. zumin­dest bei Nut­zung von Brow­sern selbst­ver­ständ­lich ist.

Dis­ku­tiert wird auch die­ser Satz (4.1.1), der schein­bar in einem Wider­spruch zum ers­ten steht:

Wer­den für die Spei­che­rung der Daten exter­ne Spei­cher­me­di­en ver­wen­det, sind die­se zu ver­schlüs­seln und so auf­zu­be­wah­ren, dass sie nur der Lehr­kraft selbst zugäng­lich sind.

Man darf ver­schlüs­sel­te Back­ups auf exter­nen Spei­cher­me­di­en able­gen, nicht aber auf dem End­ge­rät selbst.

Auch hier scheint mir die Ziel­rich­tung klar: Man möch­te auf jeden Fall ver­hin­dern, dass auch ver­schlüs­sel­te Datei­en über Clouds gro­ßer Anbie­ter wie Goog­le oder Apple syn­chro­ni­siert wer­den. Man traut dem durch­schnitt­li­chen Nut­zer nicht zu, die­se beque­men Funk­tio­na­li­tä­ten, die im pri­va­ten Bereich viel Sinn machen, für schu­li­sche Daten zu deak­ti­vie­ren. Das deckt sich mit mei­nen Erfah­run­gen auf Schulungen.

Erheb­lich und aus mei­ner Sicht erfreu­lich aus­ge­wei­tet wur­de der maxi­mal mög­li­che Daten­rah­men: Man darf auch Daten wie Tele­fon­num­mern und E‑Mailadressen der Erzie­hungs­be­rech­tig­ten ver­ar­bei­ten – das ging vor­her nicht. Bei Schüler*innen ist das aber nach wie vor nicht zuläs­sig und auch kon­sis­tent zur bis­he­ri­gen Argu­men­ta­ti­ons­li­nie unse­res Lan­des­in­sti­tuts für Daten­schutz. Für mich ste­hen hier bei der Beur­tei­lung eher päd­ago­gi­sche Über­le­gun­gen im Vordergrund.

Fazit

  1. Der Erlass macht die Hal­tung dienst­li­cher Daten auf einem pri­va­ten Gerät nahe­zu unmög­lich – nicht aber auf einem dienstlichen.
  2. Der Erlass wirkt steu­ernd dar­auf hin, dass Online­sys­te­me für die Schul­ver­wal­tung genutzt wer­den. Das ist auch sinn­voll, weil die Zugangs­vor­aus­set­zung „Brow­ser“ eine gerin­ge ist.
  3. Der Erlass wirkt indi­rekt dar­auf hin, dass schu­li­sche Daten (auch nicht zeit­ge­mäß ver­schlüs­selt) in Clouds gro­ßer Anbie­ter lan­den, es sei denn, die­se stel­len rechts­kon­for­me und inter­ve­nier­ba­re ADVs zur Ver­fü­gung. Das wird noch spannend.
  4. Ich rech­ne nicht damit, dass eine ver­schlüs­sel­te Daten­hal­tung auf dem Gerät durch z.B. Tea­cher­Tool eine Ver­ar­bei­tung per­so­nen­be­zo­ge­ner Daten dar­stellt. Aber das ist lei­der immer laut Rechts­spre­chung des EuGH zu prü­fen. Das Damo­kles­schwert, dass Tea­cher­Tool theo­re­tisch einen grö­ße­ren Daten­rah­men als den vor­ge­be­nen zur Ver­fü­gung stellt, bleibt unver­än­dert bestehen.

Edit, 9.2.2020

Satz 1 stand für mich bis­her in einem Wider­spruch zu Satz 4. Sprach­lich tut er das immer noch. For­mal wird der Erlass noch­mal hier kon­kre­ti­siert: Auf Note­books, PCs oder Tablets mit voll­wer­ti­gem Win­dows- oder Linux-Betrieb­sys­tem dür­fen nach Ein­hal­tung aller Regu­la­ri­en wei­ter­hin Schü­ler­da­ten mit dem jetzt gül­ti­gen, erwei­ter­ten Daten­rah­men ver­ar­bei­tet wer­den. Kon­kre­te Hin­wei­se, wie eine Ver­schlüs­se­lung vor­zu­neh­men ist, wer­den eben­falls gege­ben (hier exem­pla­risch für Linux und als Linux­er hät­te ich dazu Fra­gen. z.B. war­um nicht die mitt­ler­wei­le stan­dard­mä­ßig bei der Instal­la­ti­on ange­bo­te­ne Ver­schlüs­se­lung der Home­ver­zeich­nis­se genutzt wird …).

Nur: Es hat ja Grün­de, war­um vie­le Lehr­kräf­te iOS, iPa­dOS, Android oder Chro­me­OS nut­zen. Vie­le dürf­ten mit den zu Ver­fü­gung gestell­ten Anlei­tun­gen über­for­dert sein. Der Erlass wird m.E. web­ba­sier­ten Schul­ver­wal­tungs­sys­te­men hier in Nie­der­sach­sen erheb­li­chen Auf­wind geben und für erheb­li­che Ver­un­si­che­rung bei Lehr­kräf­ten und Schul­lei­tun­gen sorgen …

 

 

 

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

Ich habe als Linux­er, Apple- und Goo­gle­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ährdet.

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 Nachteile:

  • 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 Quellverzeichnis.
  • 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 werden.

(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 offenbaren.

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 Nicht­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 Verschlüsselungsverfahren.

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 wiederherstellbar
  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 Betriebssystems.

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­upemp­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 Back­up­pro­ze­dur vorschreiben.

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 Datenträ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 Datensicherheit.

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 fordern.

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) entwickelt:

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

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) => Passwort

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 folgendes: 

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 setzen.

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