Tablets in der Schule: Bitte (fast) keine Androids mehr!

Vorweg

Ich setze persönlich keine Tablets im Unterricht oder meinen eigenen Workflow ein. Für mich persönlich sind das Spielzeuge und keine Arbeitsgeräte. Meine Finger sind zu dick und unmotorisch.

Ich gestalte meinen digitalen Unterricht aber so, dass das Gerät dafür kaum eine Rolle spielt, wenn es zumindest einen Browser und einigermaßen performante Leistungsdaten zum Rendern von Webinhalten verfügt. Meine Tools stellen standardisierte Schnittstellen bereit, sodass hoffentlich jeder die App und das Gerät dafür nutzen kann, die/das zu ihr/ihm passt.

„App“ ist für mich ein anderes Wort für „Programm, dessen Oberfläche auf Touchbedienung zugeschnitten ist“. Damit sind Tablets natürlich willkommen – es gibt ja andere Menschen als mich mit anderen Vorlieben und Präferenzen.

Was ich gar nicht mag, ist als Admin Sonderlösungen bauen zu müssen, weil ein Hersteller meint, eigene „Standards“ seien kundenfreundlicher. Deswegen hasse ich aus Administratorensicht speziell Apple wie die Pest. So viel zum Rant.

Was man in der Schule von der Software eines Gerätes erwarten können muss

 

  1. Regelmäßige Betriebssystemupdates
  2. Regelmäßige Sicherheitsupdates
  3. Verlässliche Sandboxes für Prüfungssituationen
  4. Verlässliches, leicht zu bedienendes MDM (Lösung zum Managen der Geräte, wenn sie schuleigen sind)

… über einen Zeitraum von mindestens fünf Jahren. Ein Hersteller, der das nicht bieten kann, hat nach meiner Meinung in der Schule bei schuleigenen(!) Geräten nichts verloren.

Damit fallen (fast) alle Androidgeräte heraus.

Warum keine Androids?

Das Lizenzmodell von Android ermöglicht erst die Herstellung extrem günstiger Geräte. Die Quelltexte liegen offen, das System lässt sich recht unaufwändig an fast jede beliebige Hardwareumgebung anpassen, d.h. als Hersteller bin ich in der Wahl meiner CPU, meines Grafikprozessors usw. recht frei. Daraus entsteht eine Vielzahl an Produktlinien. Um das System performant und schlank zu halten, bricht man mit einem Grundprinzip von Linux, auf dem Android basiert: Dem generischen System.

Ein generisches System läuft unverändert auf sehr vielen unterschiedlichen Umgebungen: Ubuntu kann ich auf fast jeden Rechner installieren – Linux bringt die dafür erforderlichen Treiber gleich mit und erkennt z.B. Hardware beim Start vollautomatisch.

Ein generisches System kann darüberhinaus zentral geupdatet werden – im Prinzip läuft ja überall das Gleiche. Leider schleppt natürlich ein generisches System alles nur Denkbare an Treibern mit sich und ist daher recht groß – das passt vor allem nicht zu günstiger Hardware.

Kurz gesagt: Bei Androiden muss der Hersteller jedes Sicherheits- und Funktionsupdates für alle seine Produktlinien manuell einpflegen und seinen Kunden z.B. als Betriebssystemimage bereitstellen. Das lohnt sich bei Geräten wie Tablets und Handys mit ohnehin meist kurzer Verwendungszeit in der Regel nicht, sprich:

Die meisten Androidgeräte sind nach recht kurzer Zeit sicherheitstechnisch ein Debakel

Die einzige echte Ausnahme, die ich diesbezüglich kenne, ist die Nexusserie von Google selbst. Meine Nexustablets der ersten Generation erhalten bis heute zeitnah Updates – schon fast vier Jahre mittlerweile.

Man kann ausweichen auf Communities rund um Cyanogenmod – Techies wie ich könnten das ggf.. – aber für Schulen im Allgemeinen ist das keine Option.

In der Schule brauche ich nach meinem Empfinden Geräte, die mindestens drei, besser fünf zuverlässig laufen. Realistisch finde ich eher einen Gerätewechsel nach drei Jahren, d.h. mindestens(!) drei Geräte pro Schullaufbahn, denn schon heute werden die meisten Menschen (auch und gerade SuS!)  Geräte, die noch älter sind, aufgrund des technologischen Wandels als unzumutbar empfinden – daher noch ein Seitenhieb:

Bei Kalkulationen „Tablet preislich gegen Schulbuch / Taschenrechner / Atlas“ ohne Einbezug des technologischen Wandels (Produktupgrade nach drei Jahren) wäre ich SEHR vorsichtig ob des realen Preisvorteils gegenüber heute – unser Wirtschaftssystem basiert nicht darauf, dass wir ständig weniger ausgeben.

 

iPads und Windowstablets 

Apple ist ein in sich geschlossenes System und Microsoft macht den Herstellern seiner Geräte recht rigide Vorgaben, was die Hardwareausstattung angeht – im Prinzip fahren die die generische Strategie des Linuxkernels. Damit ist die Sicherheitsproblematik in einem wesentlichen Kernpunkt entschärft, weil nicht der Hersteller Updates bereitstellt, sondern eben Apple und Microsoft und diese Updates auch über die betriebssystemeigenen Mechanismen installieren. Die damit verbundene Langfristigkeit macht den Einsatz z.B. einer MDM-Lösung oder Klassenraumsteuerung erst beherrschbar: Wenn ich nicht andauernd verseuchte Geräte wiederherstellen und neu in eine MDM-Lösung integrieren muss, wird die Bewältigung des Arbeitspensums möglich. Und gerade Schulgeräte, die durch viele Hände gehen, sind gegenüber derartigen Drangsalierungen extrem gefährdet. Selbst Apple hat mittlerweile kapiert, dass ein 1:1-Design eben nicht in eine 1:many-Umgebung passt und entwickelt in die richtige Richtung.

Nachtrag:

Etwas ausführlicher hat sich Andreas Hofmann mit der neuen Initiative von Apple beschäftigt.

 

Anfangsgenölewiederaufgriff

Mir ist völlig klar, dass mit der automatischen Updatepolitik von Apple und gerade auch Microsoft auch sehr streitbare Mechanismen Einzug in die mobilen Geräte halten – vor allem vor dem Datenschutzhintergrund. Mir wäre ein Ubuntu-Touch auf freier Hardware ohne UEFI- und TPM-Mist bedeutend lieber.

Da wir aber im „Isnummalsoland“ leben, geht es um pragmatische Ansätze. Und da hat Apple schon aufgrund des Appangebot im Vergleich zu Microsoft zurzeit die Nase für viele Anwender halt vorne. Ich persönlich finde das doof.

Vielleicht fehlt es bei Androids einfach auch nur an Dienstleistern, die das Ganze z.B. mit Cyanogenmod schlicht professionalisieren und Servicebundles für drei bis fünf Jahre anbieten.

Googles Macht (prevalence)

Google hat etwas angekündigt: Die Tatsache, dass eine Seite Inhalte auch verschlüsselt per TLS ereichbar ist, wird sich zukünftig positiv auf das Ranking auswirken. Auch dieses Blog ist durchgängig über https erreichbar. Testen lässt sich das für die eigene Homepage hier. riecken.de bekommt heute, am 31. Dezember 2014 ein „A-„-Rating (vorwiegend, weil keine älteren Referenzbrowser unterstützt werden).

ssllab_2014-12-31

Die Reaktionen auf Googles Vorstoß sind unterschiedlich.

Welche Vorteile ergeben sich dadurch?

  • verschlüsselter Internetverkehr kann nicht ohne Weiteres mitgelesen werden, d.h. ein Admin wie ich hätte – selbst wenn er es wollte – keinen Zugriff auf die Inhalte, die bei einer Internetsitzung übertragen werden – lediglich die aufgerufenen Seiten sehe ich im Log. In Firmen- und Schulnetzwerken kann man aber durchaus tricksen, wenn man die Kontrolle über die Clients hat.
  • Organisationen, die im großen Stil Internetverkehr mitschneiden wollen, bekommen über kurz oder lang das Problem, dass immer mehr Rechenkapazität zur Entschlüsselung notwendig wird. Massenüberwachung wird damit also teurer – wenn die Verbindung durch geeignete Einstellungen entsprechend gesichert ist.
  • Man erzwingt, dass Login- und Anmeldedaten – z.B. wenn ich mich hier einlogge, um einen Artikel zu schreiben – auch verschlüsselt übergeben werden. Das ist ein Sicherheitsgewinn.

Warum macht man das also nicht schon lange?

Das ist eine spannende und gar nicht so leicht zu beantwortende Frage. Es gibt einige Fallstricke dabei.

1. Identität

Durch verschlüsselte Verbindungen kann man lediglich sicherstellen, dass die Verbindung eben verschlüsselt ist. Man weiß bei den allermeisten Verbindungen nicht, ob man wirklich mit der im Zertifikat hinterlegten Stelle kommuniziert. Man bekommt heute problemlos Zertifikate für Domains ohne Whois-Eintrag – meist wird nur rudimentär geprüft, ob Zugriff auf eine bestimmte System-E-Mailadresse besteht. Lediglich bei EV-Zertifikaten (grüne Adresszeile) kann man sich recht sicher sein, z.B. wirklich mit der eigenen Bank zu sprechen.

2. Entschlüsselung

Ich als Geheimdienst würde verschlüsselte Verbindungen aufzeichnen und darauf hoffen, dass irgendwann meine Rechenkapazitäten für eine Entschlüsselung ausreichen. Dem kann man nur entgegenwirken, indem man serverseitig bestimmte Verschlüsselungsverfahren erzwingt, z.B. Diffie-Hellmann. Das geht wiederum oft zu Lasten der Unterstützung älteren Browser und Betriebssysteme. Der Kompromiss bei den Einstellungen – gerade bei Banken – ist eben ein Kompromiss.

3. Eingebettete Inhalte

Mein Browser wird meckern, wenn auch einer verschlüsselten Webseite unverschlüsselte Inhalte nachgeladen werden, also z.B. ein eingebettetes Video von einer unverschlüsselten Quelle. Diese Warnung sieht für den unerfahrenen Nutzer ziemlich bedrohlich aus. Er wird im Zweifel diese Seite nicht besuchen.

Gleichzeitig erschwert es genau dieser Mechanismus z.B. Schadprogrammen unentdeckt zu bleiben – wenn sich der jeweilige Serverbetreiber nicht die Mühe macht, ein Zertifikat zu besorgen. Das Gleiche gilt aber auch für Werbenetzwerke, die sehr oft mit eingebetteten Inhalten arbeiten.

Deswegen wird man heute kaum bekannte Internetportale finden, die über https erreichbar sind.

4. Performance

Verschlüsselung erfordert etwas mehr CPU-Power auf Seiten des Clients und des Servers. Großartige Unterschiede merke ich bei meinen Lastmessungen aber nicht. Die Aussagen zum Cachingverhalten bei verschlüsselten Verbindungen sind widersprüchlich. Alles in allem denke ich, dass dieser Punkt vernachlässigbar ist.

Das sehen Firmen, die Angebote für Bildungsinstitutionen machen, naturgemäß oft anders. Da wird gerne noch die Mär von „überflüssig außer beim Login“ (immerhin) erzählt – weil oft genug ein CDN (Content-Delivery-Network) im Hintergrund werkelt und statische Inhalte cached oder gar Werbebanner nachlädt. Das umzustellen ist dann schon Aufwand, wenn man es nachträglich angehen muss.

5. Aufwand und Kosten

Bei Zertifikaten muss jemand bestätigen, dass meine Identität stimmt. Das machen Zertifizierungsstellen, die das nach bestimmten Kriterien prüfen. Zertifikate, die jährlich erneuert werden müssen, gibt es kostenlos bei StartSSL.

Dieses Geschäftsmodell ist vielen anderen Händlern von Zertifikaten natürlich ein Dorn im Auge – für eine private Webseite reicht ein solches Zertifikat jedoch vollkommen aus. Günstige Einsteigerzertifikate gibt es ab ca. 5,- Euro pro Jahr – und diese Zertifizierungsstellen prüfen dabei nach meinen Erfahrungen auch nicht besser als StartSSL. Als Hostingkunde wird man etwas mehr anlegen müssen. Gesehen habe ich Angebote ab 15,- Euro pro Jahr – dafür hat man nichts mit Serverkonfigurationen zu tun.

Für Onlineshops oder gar öffentliche Lernplattformen sollte man etwas mehr anlegen – unter 300,- Euro pro Jahr ist da kaum etwas zu machen. Wenn mir da ein Anbieter ohne EV-Zertifikat kommt, ist das eigentlich schon ein Ausschlussgrund.

Ein einfaches Zertifikat über StartSSL oder Comodo habe ich nach ca. fünf Minuten in den Händen und auf dem Server installiert. Eine EV-Validierung ist deutlich aufwändiger. Dafür wird man einen Mitarbeiter wohl 1-2 Stunden beschäftigen müssen.

Google

Google nutzt eigene Werbenetzwerke und kann für diese recht problemlos eine vollständige Verschlüsselung einrichten. Google zwingt andere Werbenetzwerke jetzt quasi dazu, es ihnen gleichzutun. Wenn sich zudem höhere Standards bei der Identitätsvalidierung durchsetzen, wird es für Werbetreibende, die im Netz unerkannt bleiben wollen, immer schwieriger, auch prominent in Erscheinung zu treten – z.B. durch eingebettete Bannerwerbung.

Wofür nutzt Google also seine Marktmacht? Warum laufen Vermarkter gerade Sturm gegen diesen Vorstoß Googles? Wie werden Infoportale damit umgehen, dass sie nun Gefahr laufen, im Ranking von Google zu sinken? Handelt Google auch aus Eigeninteresse? Oder setzt sich Google hier für unsere Sicherheit ein?

Es ist sehr interessant, wie Google hier seinen Einfluss einmal mehr nutzt.

In eigener Sache: riecken.de über https verfügbar

Nach einer Übergangszeit von wenigen Wochen wird riecken.de ausschließlich SSL-verschlüsselt abzurufen sein. Damit ist die Datenübertragung zu und von dieser Seite durch einen 2048Bit-RSA-Key gesichert. Der Datenverkehr zwischen Browser riecken.de ist dann nur mit großem Aufwand abzuhören.

Dieses Feature ist primär für mich wichtig, da ich diese Seite auch von öffentlichen Netzwerken aus pflege, über die ansonsten z.B. meine Logindaten im Klartext auslesbar sind (mit völligen legalen und frei verfügbaren Netzwerkanalysetools wie WireShark). Mich haben im letzten Jahr die Analyseergebnisse von Wireshark in verschiedenen öffentlichen Netzwerke geradezu schockiert – viele Anwender sind sich des Risikos ungesicherter Verbindungen offenbar nicht im Ansatz bewusst – dass ein Blog in fremde Hände fällt, mag nicht überaus schlimm sein, aber es wird oft genug das identische Passwort für unterschiedliche Dienste genutzt.

Für die allermeisten Feedreader und Browser dürfte das keine Anpassungen erfordern. Trotzdem empfehle ich, ggf, schon jetzt das Abonnement der Feed-URL von http auf https umzustellen. Ich nutze ein kostenloses Serverzertifikat von StartSSL, welches von den meisten neueren Browsern und Endgeräten ohne Zertifikatswarnung akzeptiert wird. IE6.0&7.0 und sehr frühe Androidversionen werden nicht unterstützt und geben Fehlermeldungen aus, welche die Funktion der Seite aber nicht beeinflussen.

Die Installation eines StartSSL-Zertifikats erfordert Rootrechte oder ein entsprechend vorkonfiguriertes Webpaket und ist nicht per Plugin zu bewerkstelligen.

Für dumm verkauft – EC-Karten

Hier einmal eine für mich zentrale Aussage in dem ganzen Desaster:

„Der derzeitige Workaround, damit die Händler-Terminals die betroffenen Karten wieder akzeptieren, ist nur ein Downgrade vom sicheren EMV-Verfahren auf die alten, unsicheren Verfahren. Dazu werden alle „TA-7.0“-Terminals von den jeweiligen Netzbetreibern umkonfiguriert, damit diese die Karten nicht mehr per EMV-Anwendung ansprechen, sondern über die Anwendungen „electronic cash ecc“ oder die magnetstreifenbasierten Anwendung „electronic cash Spur 2“ authentisieren. Gerade den Magnetstreifen wollte man aber mittelfristig ablösen, um beispielsweise Skimming-Angriffe abzuwehren.(http://www.heise.de/security/meldung/Desaster-mit-EC-Karten-kann-teuer-werden-896988.html)

Eine große deutsche Bank schreibt dazu in ihrer Kundeninformation:

„Es besteht keinerlei Sicherheitsproblem für Ihr Konto und Ihre Karte.“

So so.Vielleicht bin ich ja doof – Ich lese aus der ersten Pressemitteilung übersetzt etwa folgendes heraus: Ihre Karte hat ein Schloss mit einem Sicherheitsschlüssel und eines mit einem Schlüsselbart. Das Schloss mit dem Sicherheitsschlüssel passt nicht mehr zu gängigen Schlüsseln, die es öffnen sollen, deswegen wird nur noch das Schloss für die Bartschlüssel verwendet.

Das ist für die zitierte Bank kein Sicherheitsproblem. Spannend.

Fehler können überall vorkommen – wobei man sich schon darüber streiten kann, wie ein derartiger Programmierlapsus sämtliche Kontrollgremien und Prüfverfahren der deutschen Kreditwirtschaft passieren konnte. Wenn ich im Unterricht oder bei einer Klausurkorrektur einen solchen Fehler mache, rudere ich zurück und biege das u.U. auf Kosten meiner Autorität wieder hin. Auf jeden Fall kläre ich die Lerngruppe aber über die Folgen des Fehlers auf. Sich hinzustellen und quasi zu behaupten, alles sei wieder absolut in Ordnung empfinde ich als einen Angriff auf meine Intelligenz.

Wir brauchen kein Wissen mehr. Das stört nur beim Programmieren. Es ist vielleicht wirklich besser, wenn wir SuS mit den Kompetenzen ausstatten, sich die Lösungen für künftige Probleme zusammenzugooglen und zusammenzunetzwerken. Das hilft vor allen Dingen immer dann, wenn man etwas Neues entwickelt. Unglaublich.

Verschlüsselung in Webapplikationen (MD5)

Passwörter gehören nicht in die Hände von Dritten, auch nicht in die von Administratoren. Daher wurden für die Speicherung von Passwörtern sogenannte Falltürmechanismen (trapdoor mechanisms) entwickelt:

Es ist zwar möglich, ein Passwort zu verschlüsseln, nicht jedoch es wieder zu entschlüsseln.

Der Verschlüsselungsalgorithmus funktioniert also genau wie eine Falltür nur in eine Richtung. Das mag auf den ersten Blick sinnlos erscheinen, ist aber eigentlich sehr pfiffig. Nehmen wir als Beispiel den weit verbreiteten MD5-Algorithmus. Mit diesem sichert fast jede Webanwendung in PHP ihre Passwörter ab. Dabei wird aus

123456=> MD5-Verschlüsseler => e10adc3949ba59abbe56e057f20f883e

Diese lange Zeichenkette sieht der Admin. Er weiß aber deswegen das Passwort im Klartext noch nicht, da der Weg

e10adc3949ba59abbe56e057f20f883e => MD5-Entschlüsseler (Gibt es nicht) => Passwort

prinzipbedingt versperrt ist. Die dabei entstehende, lange Zeichenkette wird „Hash“ genannt.

Wenn man sich nun an einer Webanwendung (Moodle, Joomla, egroupware …) anmeldet, macht die Webanwendung folgendes:

Benutzer gibt Passwort im Klartext ein => MD5-Verschlüssler => Hash1

Dieser Hash1 wird nun mit dem Hash – nennen wir ihn Hash2 – verglichen, der in der Datenbank für den User gespeichert ist (er könnte etwa bei der Registrierung erzeugt worden sein).

Stimmen beiden Hashes überein, hat der User das korrekte Passwort eingegeben, weil der Verschlüsselungsmechanismus ja immer gleich ist. Stimmen die Hashes nicht überein, muss der Benutzer ein falsches Passwort eingegeben haben.

Soweit so gut. Das ist auch die Erklärung dafür, dass einen – so man sein Passwort vergessen hat – stets ein neues Passwort zugewiesen wird, denn der Admin kann das alte Passwort ja nicht wissen, sondern lediglich ein neues setzen.

Eigentlich hört sich das Ganze recht sicher an – ist es bloß nicht, denn es gibt Angriffe gegen dieses Verfahren, die aber allesamt voraussetzen, dass der Angreifer an den Hash kommt.

Weiterlesen