ESP32 vs RaspberryPI Zero

Mal etwas aus der Welt der Hardware. Bei der Entwicklung einer kleinen IoT-Anwendung stand ich vor der Herausforderung festzustellen, ob der ESP32 genügend Leistung bieten würde. Es war jedoch keine einfache Aufgabe, eine leistungsstärkere WLAN-fähige Alternative zu finden. Obwohl ich Teensy-Boards für andere Anwendungszwecke äußerst interessant und leistungsstark finde, musste ich feststellen, dass sie keine Unterstützung für Wi-Fi bieten.

Allerdings gibt es da noch ein Bauteil, dass in den letzten Monaten etwas schwierig zu erhalten war, aber mittlerweile (Stand Oktober 23) wieder günstig zu erwerben ist: der Raspberry Pi Zero 2W. Dieser verfügt über 1 Ghz und Vier-Kern-Prozessor.

ESP32 (links) und Raspberry Pi Zero 2W (rechts)

Neben der Plattform stellt sich jedoch auch die Frage nach der Programmiersprache. Grundsätzlich lässt sich natürlich alles in C implementieren, aber bei komplexeren Anwendungen ist dies nicht unbedingt komfortabel. Und wenn man in der Implementierung was vergessen hat, zeigt sich sowas gerne erst einige Wochen bis Monate später.

Ein komfortablerer Ansatz wäre die Verwendung von Python im Sinne von MicroPython oder CircuitPython. Dies wirft jedoch die Frage auf, ob diese Lösungen zu viele Ressourcen beanspruchen. Aus diesem Grund führte ich einfaches Benchmarking durch. Dabei handelte es sich lediglich um das Inkrementieren einer Variablen, was natürlich nicht unbedingt repräsentativ ist. Dennoch reichte es aus, um ein Gespür für die Leistungsfähigkeit und den Ressourcenverbrauch der Plattformen zu erhalten.

Demzufolge verglich ich die Leistung von C auf dem ESP mit CircuitPython auf dem ESP und dem Raspberry Pi Zero. Darüber hinaus untersuchte ich, wie sich MicroPython auf einem Raspberry Pi Zero mit Betriebssystem verhält. Einige Tests führte ich auch mit mehreren Threads durch.

Benchmarkergebnisse Teil 1

Die aus diesen Ergebnissen abgeleitete Schlussfolgerung deutet darauf hin, dass CircuitPython im Vergleich zu anderen Optionen vergleichsweise langsam sein könnte. Es ist jedoch wichtig zu betonen, dass diese Schlussfolgerung ausschließlich auf den Ergebnissen dieses Tests basiert. Andere potenzielle Vorteile werden dabei nicht berücksichtigt.

Für mich persönlich war es überraschend, dass MicroPython auf einem Raspberry Pi Zero mit einer Raspbian Lite Installation äußerst gute Ergebnisse liefert. Ich hätte erwartet, dass das Betriebssystem zu viele Ressourcen verbraucht und somit den „Bare Metal“-Installationen unterlegen ist. Dies scheint jedoch nicht der Fall zu sein.

Auf Nachfrage eines Freundes hin habe ich noch eine C-Implementierung auf dem Pi mit (Raspbian Lite) OS getestet. Dies hätte ich besser nicht ausprobiert; der Vergleich von oben ergänzt um die Ausführung der C-Implementierung mit einem und vier Threads:

Benchmarkergebnisse Teil 2

Der Vollständigkeit halber sollte jedoch angemerkt werden, dass die vier Threads ohne Synchronisation (ohne Verwendung von Locks oder Mutex) ausgeführt wurden. Bei einer einfachen Inkrementierung schien dies nicht erforderlich zu sein.

Fazit: C(++) ist (leider) immer besser. Ursprünglich dachte ich die Differenz wäre viel geringer — die Ergebnisse vermitteln jedoch ein anderes Bild. Daher drängt sich die Frage auf, ob der Komfort einer Python-Implementierung bei so viel Leistungsverlust noch gerechtfertigt ist. Wenn man jedoch auf Python setzen möchte wäre die Wahl von MicroPython auf einem RaspberryPi Zero mit Betriebssystem die Beste.

Weniger ist mehr

Wir kennen es doch alle: Hin und wieder wird aus irgendeinem lästigen Grund ein neues Passwort oder eine neue PIN benötigt. Dabei soll es auch noch etwas sein, das sich leicht merken lässt und von den bisher verwendeten unterscheidet.

Insbesondere bei Multi-Faktor-Authentifizierung genügt auch schonmal eine vier-, sechs- oder achtstellige PIN: Wenn wir eine neue EC-Karte, einen neuen Personalausweis erhalten oder zur Entsperrung unseres Smartphones. Aber wie sieht es eigentlich mit der Sicherheit von solchen PINs aus?

Grundsätzlich lehrt uns die Kombinatorik, dass bei 10 unterschiedlichen Ziffern (0-9) zur Auswahl und bei einer vierstelligen PIN genau 10 hoch 4 also 10.000 verschiedene Kombinationen existieren. Im schlechtesten Fall müssten diese alle ausprobiert werden — im Mittel würde ein Angreifer nach der Hälfte, also nach 5000 Versuchen, die korrekte PIN durch systematisches Ausprobieren ermitteln können.

Üblicherweise sperren sich aber Geräte nach mehrmaligen Fehleingabe: Dies ist häufig schon bei drei Fehlversuchen der Fall. So betrachtet sind die vierstelligen PINs also nicht so übel: Die Wahrscheinlichkeit bei drei Versuchen die korrekte PIN in einem dieser Versuche zu wählen liegt bei 0,03 %.

1-(\frac{9999}{10000}*\frac{9998}{9999}*\frac{9997}{9998})=0.0003

Aber dabei darf auch die Realität nicht vergessen werden: Auf den Tasten des Gerätes hinterlassen wir stets einen Fingerabdruck der häufig auch ohne Hilfsmittel erkennbar ist. Insbesondere bei der Glasscheibe eines Smartphones ist dies vermutlich jedem schon selbst aufgefallen. Probleme dieser Art wurden auch schon im Beitrag Neulich im Supermarkt angedeutet. Wenn wir nun vor der Auswahl einer PIN stehen, möchten wir es dem potenziellen Angreifer möglichst schwer machen. Intuitiv würde man also vermutlich eine PIN wählen die aus vier verschiedenen Ziffern besteht um eine möglichst hohe Sicherheit zu erzielen. Aber ist das wirklich besser?

In der Schule lernt man (häufig), dass sich die Anzahl der möglichen Permutationen (Anordnungen) von n-vielen Elementen über die Fakultätsfunktion n! berechnen lässt. So lassen sich vier verschiedene Ziffern auf 4!=24 unterschiedliche Arten anordnen. Aber es könnte auch sein, dass nur zwei verschiedene Ziffern verwendet wurden oder nur drei oder sogar nur eine Ziffer. Wie berechnet man in so einem Fall die Anzahl der Möglichkeiten?

Hierzu betrachten die Anzahl der Permutationen mit nicht unterscheidbaren Elementen. Sind m von insgesamt n Objekten nicht unterscheidbar, können diese auf m! verschiedene Positionen verteilt werden. Die Anzahl der Permutationen insgesamt (n!) werden um diese Kombinationen reduziert.

\frac{n!}{m_1! \cdot m_2! \cdot \ldots}

Die m1, m2, etc. stellen dabei die Gruppen von mehrfach vorkommenden Elementen dar. Als Beispiel: Hinterlassen wir nach Eingabe der PIN nur einen Fingerabdruck auf der Taste 4 so gibt es vier nicht unterscheidbare Elemente (m1=4) und somit ergibt sich:

\frac{4!}{4!}=1

Wenn wir hingegen auf zwei Tasten, z. B. der 3 und der 5 einen Fingerabdruck hinterlassen wissen wir nicht, ob die Zahl 3 einmal, zweimal oder dreimal in der PIN genutzt wird. In Frage kommen daher Kombinationen wie (3,3,3,4) aber auch (4,4,3,3) oder (4,4,4,3). Somit missen wir zweimal eine Gruppe von 3 identischen Ziffern berücksichtigen (die Ziffer 3 dreifach oder die Ziffer 4 dreifach) und zusätzlich die Permutationen, wenn die Ziffer 3 und die Ziffer 4 beide doppelt verwendet wurden. In diesem Fall erhalten wir 14 Möglichkeiten diese anzuordnen.

\frac{4!}{3!}+\frac{4!}{2!*2!}+\frac{4!}{3!}=14

Wie sieht das Ganze bei drei verschiedenen Ziffern aus? Sehen wir beispielsweise bei der 1, der 2 und der 3 einen Fingerabdruck, muss eine Ziffer doppelt genutzt worden sein. Wir berechnen die möglichen Permutationen bei (1,1,2,3). Wir wissen aber nicht welche der drei Ziffern doppelt verwendet wurde. So könnten auch Permutationen von (2,2,1,3) oder (3,3,1,2) in Frage kommen. Daher müssen wir diese drei Mal addieren.

\frac{4!}{2!}+\frac{4!}{2!}+\frac{4!}{2!}=3*(\frac{4!}{2!})=36
\frac{4!}{1!}=24

Bei vier unterschiedlichen Ziffern hingegen, erhalten wir ganz klassisch (Permutationen ohne Wiederholung) die bereits oben beschriebenen 24 verschiedene Kombinationen. Wir können uns diese zwei Fälle auch in Python generieren und anzeigen lassen. Hierzu kann die Methode permutations aus itertools hilfreich sein.

from itertools import permutations 
  
kombinations = [[1,1,2,3],[2,2,1,3],[3,3,1,2]]
#kombinations = [[1,2,3,4]]

all = []
for k in kombinations:
    perm = permutations(k) 
    for i in list(perm): 
        if i not in all:
            all.append(i)

print(all)

Erzeugt die Ausgabe dieser 36 Kombinationen:

[(1, 1, 2, 3), (1, 1, 3, 2), (1, 2, 1, 3), (1, 2, 3, 1), (1, 3, 1, 2), (1, 3, 2, 1), (2, 1, 1, 3), (2, 1, 3, 1), (2, 3, 1, 1), (3, 1, 1, 2), (3, 1, 2, 1), (3, 2, 1, 1), (2, 2, 1, 3), (2, 2, 3, 1), (2, 1, 2, 3), (2, 1, 3, 2), (2, 3, 2, 1), (2, 3, 1, 2), (1, 2, 2, 3), (1, 2, 3, 2), (1, 3, 2, 2), (3, 2, 2, 1), (3, 2, 1, 2), (3, 1, 2, 2), (3, 3, 1, 2), (3, 3, 2, 1), (3, 1, 3, 2), (3, 1, 2, 3), (3, 2, 3, 1), (3, 2, 1, 3), (1, 3, 3, 2), (1, 3, 2, 3), (1, 2, 3, 3), (2, 3, 3, 1), (2, 3, 1, 3), (2, 1, 3, 3)]

Betrachten wir die Ergebnisse in der Tabelle sehen wir, dass die meisten Permutationen bei 3 Ziffern zustande kommen. Dies natürlich unter der Prämisse, dass wir nicht wissen welche der drei Ziffern doppelt verwendet wurden.

1 Ziffer2 Ziffern3 Ziffern4 Ziffern
1 Permutationen14 Permutationen36 Permutationen24 Permutationen

Zusammenfassend ist zu sagen, dass sofern nur diese Art des Angriffs, dass ein Angreifer auf Basis der Fingerabdrücke oder anderen Spuren die Ziffern der PIN ermitteln kann berücksichtigt wird, eine PIN aus drei verschiedenen Ziffern am sichersten ist. Unnötig zu sagen, dass sich dieses Muster auch bei fünf- oder sechsstelligen PINs fortsetzt: Es ist stets besser eine Ziffer doppelt zu verwenden. Insbesondere sollte von einer PIN mit zwei Ziffern abgesehen werden, da ein Angreifer bei drei Versuchen diese mit einer Wahrscheinlichkeit von 21 % erraten würde; bei 3 Ziffern sinkt die Wahrscheinlichkeit hingegen auf 8,3 %.

v3 Technologie

Ich bin kürzlich über eine Datenschutzerklärung gestolpert, die einen interessanten Absatz zum Thema Datensicherheit enthielt:

Wir verwenden innerhalb des Website-Besuchs das verbreitete SSL-Verfahren (Secure Socket Layer) in Verbindung mit der jeweils höchsten Verschlüsselungsstufe, die von Ihrem Browser unterstützt wird. In der Regel handelt es sich dabei um eine 256 Bit Verschlüsselung. Falls Ihr Browser keine 256-Bit Verschlüsselung unterstützt, greifen wir stattdessen auf 128-Bit v3 Technologie zurück.

Eine schnelle Googlesuche zeigte, dass dieser Textbaustein in vielen Datenschutzerklärungen zu finden ist. Interessanterweise auch in Webauftritten von Kanzleien und Datenschutzberatern. Meine Vermutung ist, dass diese Textpassage aus einem nicht ganz sauberen Datenschutzgenerator stammt, denn die von mir betrachteten Webseiten hatten mehrheitlich ihre Datenschutzerklärungen im Zuge der DS-GVO im Jahr 2018 angepasst.

Wollen wir uns jedoch den Inhalt mal etwas genauer ansehen. Mit den 256-Bit ist wohl die Schlüssellänge der symmetrischen Chiffre gemeint. Wie jedoch schon unlängst bekannt ist, stellt diese Angabe nur einen kleinen Teil der Sicherheit dar. Die gesamte SSL/TLS Ciphersuite entscheidet über die Sicherheit. Mit Verabschiedung von TLS 1.3 wurden beispielsweise alle CBC-Modi in den symmetrischen Chiffren entfernt – zu oft waren diese für Verwundbarkeiten mitverantwortlich. Dies gilt gleichermaßen für beide Schlüssellängen, weshalb die Angabe ob Chiffren mit 256 Bit oder 128 Bit zum Einsatz kommen kein Qualitätsmerkmal darstellt.

Etwas mehr musste ich über die v3-Technologie grübeln. In Verbindung mit der Schlüssellänge der symmetrischen Chiffre ergibt dies keinen Sinn. Mir ist keine Versionierung bekannt, die in gleicher Weise auf alle symmetrischen Chiffren zutreffen würde. Die Angabe bezieht sich also vermutlich auf die SSL-Version. Es soll, meiner Vermutung nach, dies zum Ausdruck bringen, dass sofern SSL 3.1 (=TLS 1.0) nicht vom Browser unterstützt wird, SSL 3.0 verwendet wird. Würde dies in der Anwendung tatsächlich zutreffen, wäre die Webseite hochgradig angreifbar, da SSL 3.0 schon seit 2015 als unsicher eingestuft und in modernen Browser nicht länger nutzbar ist. Auch SSL 3.1 und TLS 1.1 werden im Laufe des Jahres 2020 in den Ruhestand gehen.

Es entbehrt nicht einer gewissen Ironie, dass SSL 3.1 im Jahr 1999 veröffentlicht wurde und auch von älteren Betriebssystemen wie Windows XP und Windows Server 2003 Unterstützung fand. Der Satz stellte jedenfalls schon damals keinen Mehrwert dar, da eine symmetrische 256 Bit Verschlüsselung nicht zwangsweise über eine mit 128 Bit zu stellen ist. So würde ich damals wie heute ein AES128 über ein RC4 mit 256 Bit Schlüssellänge stellen. Es ist sogar schon in einer gewissen Weise bedenklich, wie lange sich dieser sinnbefreite Textbaustein im Netz gehalten hat.

Bingo mit Whitepapern

Hallo zusammen,

bei der Betrachtung von Whitepapern zu Produkten wird man häufig mit diversen Bingo-Begriffen überflutet. Auf diese Weise soll dem uninformierten Interessenten, das ist zumindest meine Vermutung, ein Gefühl von Expertise vermittelt werden. Ein Beispiel ist das Whitepaper von schul.cloud der heinekingmedia GmbH in Hannover. In ihrer Stellungnahme zum Datenschutz und den detaillierten Informationen zur Verschlüsselung werden mit diversen Begriffen hantiert, deren nähere Betrachtung lohnenswert ist.

Bildzitat aus dem Whitepaper (Quelle: schul.cloud).

TLS Transport Verschlüsselung: 4096 Bit RSA Schlüssel

Grundsätzlich ist natürlich nichts einzuwenden, wenn mit einer größeren Schlüssellänge (4096 Bit) als üblich (2048 Bit) wirbt. Wenn man sich allerdings das Zertifikat des Webauftritts anschaut findet sich hier nur einen 2048 Bit Schlüssel. Natürlich ist es möglich, dass es sich bei diesem Dienst um einen anderen Endpunkt handelt, allerdings ist es fraglich, weshalb hier nicht konsequent alle Endpunkte den gleichen Schutz aufweisen. Dies würde mein Vertrauen zumindest erhöhen, auch wenn es nicht unbedingt erforderlich ist. Die sonst übliche Argumentation, dass dies ggf. Mobilgeräte überfordern könnte, kann an dieser Stelle jedenfalls nicht herhalten.

Signierungsalgorithmus: SHA256withRSA

Mir ist unklar, welche Information daraus entnommen werden soll. Natürlich sollte kein MD5 oder SHA1 Hashverfahren zur Signaturerzeugung angewendet werden, aber es ist kaum ein Qualitätsmerkmal das speziell beworben werden muss. Klingt aber kryptisch, technisch und aus diesem Grund möglicherweise überzeugend.

Downgrade Attack Prevention

Ich finde es etwas befremdlich, dass mit Absicherungen nach dem Stand der Technik Werbung betrieben wird. Das SSLv3 abgeschaltet sein muss sollte mittlerweile allen Verantwortlichen bekannt sein. Die meisten Client-Bibliotheken würden dies ohnehin nicht länger unterstützen. Auch der Wechsel von HTTPS auf HTTP kann leicht in dieser kontrollierten Client/Server-Umgebung ausgeschlossen werden. Aber Attack Prevention klingt, als ob extreme Schutzmaßnahmen getroffen wurden – was tatsächlich passiert ist: eine Zeile in der Konfigurationsdatei des Servers.

Secure Renegotiation

Wer mehr darüber erfahren möchte, muss sich einfach den CVE-Eintrag aus dem Jahr 2009 durchlesen. Ich finde es einfach ärgerlich, schon fast etwas sträflich, mit Standards werben, die bald ihr 10 Jähriges Jubiläum feiern.

Wichtige Fragen bleiben hingegen offen: Woher stammt das Schlüsselmaterial? Welche Kontrolle hat der Nutzer über das Schlüsselmaterial? Wie wird der Gesprächspartner authentisiert?

Insbesondere der letzte Punkt wird in vielen Messengern vernachlässigt. Threema hat dies durch eine manuelle Prüfung und Ampel-Symbolik gelöst. Whatsapp verheimlicht den Wechsel öffentlicher Schlüssel bzw. blendet diesen nur auf Verlangen ein. Damit gibt es bei Whatspp keine wirksame Authentifizierung. Möglicherweise ist das je nach Anwendungskontext auch nicht notwendig, aber es sollte dem Nutzer zumindest klar sein.

Kein Schutz beim Offline-Tracking

Hallo zusammen,

in der Informationssicherheit lassen sich viele Probleme durch einfache Lösungsmuster erschlagen. Beispiele sind z.B. der Einsatz SSL/TLS zur Gewährleistung der Vertraulichkeit der Informationen auf dem Transportweg oder der Einsatz von Hash-Verfahren, um der Klartextspeicherung eines Passwortes zu entgehen. Diese Denkmuster wird man sowohl in der Hochschullehre, als auch (in abgeschwächter Form) bei beruflichen Weiterbildungen finden. Kritisch wird es jedoch dann, wenn diese Denkmuster nicht mehr länger für den jeweiligen Anwendungsfall durchdacht und blind angewendet werden.

Das passiert leider häufiger als man denkt und an dieser Stelle muss ich mich schonmal bei Tom Lukaß, Autor des wirklich tollen Artikels Offline-Tracking: Kundenfrequenzmessung in Ladengeschäften (vom 06.07.2016) entschuldigen, allerdings liefert mir dieser ein gutes Beispiel. Der Beitrag behandelt das WLAN-Tracking: Dabei werden die Mobilgeräte zur Besucherverfolgung (z.B. in einem Supermarkt) verwendet und durch spezielle Hardware kann ebenfalls eine Positionsbestimmung durchgeführt werden. Der Autor empfiehlt die Anwendung eines Hashverfahrens, damit die genauere Identifikation des Besuchers ausgeschlossen bzw. die MAC-Adresse anonymisiert wird:

Das WLAN-Tracking sollte aufgrund von anonymisierten MAC-Adressen durchgeführt werden. Die MAC Adresse lässt sich anonymisieren, in dem man sie gleich nach dem Eingang auf dem Router mit einer zufälligen Zahlenreihe ergänzt (sog. SALT) und aus der erweiterten Adresse einen Hashwert bildet. Das kann man sich wie einen einmaligen digitalen Fingerabdruck vorstellen.

Um dieser Identifizierung zu entgehen, soll also die MAC-Adresse verändert bzw. anonymisiert verarbeitet werden. Den hier geschilderten Anonymisierungsvorgang, also die Erweiterung um einen SALT-Wert mit anschließender Hashwertbestimmung, kennt man bereits von der Passwortspeicherung.

Dies findet auch so Anwendung, wie aus einer FAQ eines Geräteherstellers für solche Trackingsysteme ersichtlich wird:

Datenschutz ist eines der Kernthemen der infsoft Plattform. So bieten unsere Systeme zahlreiche Methoden wie Hash-Algorithmen (SHA-1) zur Anonymisierung von MAC Adressen bei Analyse- und Trackingverfahren. […]

Die Vermutung dabei ist, dass MAC-Adressen sich in in gleicher Weise durch einen Hashwert „verdecken“ lassen, wie dies bei Passwörtern der Fall ist. Das ist auch prinzipiell nicht falsch, aber nicht ganz zu Ende gedacht. Das Problem ist hier die geringe Diversität an MAC-Adressen: Eine MAC-Adresse ist eine 48 Bit langer Identifikator einer Netzwerkschnittstelle, welcher üblicherweise in hexadezimaler Darstellung in Erscheinung tritt (z.B. 50-7B-9D-CB-C0-22). Durch die 48 Bit ist die maximale Anzahl existierender MAC-Adressen schon gleich auf 281.474.976.710.656 (281 Billionen) festgesetzt. Wenn ich also alle denkbaren MAC-Adressen durchrechne, ist die getrackte MAC-Adresse natürlich ebenfalls dabei.

Noch vor 10 Jahren wäre dies auch hinreichend „schwierig“ gewesen. Seit jedoch die Kryptowährungen (z.B. Bitcoin) so einen Hype erlebt haben, sind genau für diese Probleme extrem starke Berechnungslösungen verfügbar. Der Antminer R4 kostet derzeit ca. 1000 USD und erbringt eine Leistung von 8,6 TH/s. Das sind 8.600.000.000.000 (8,6 Billionen) Hashes pro Sekunde. Das macht offensichtlich: Im worst case werden 32 Sekunden benötigt, um die MAC-Adresse, mit beliebigem SALT, aus dem Hashwert herauszurechnen. Ein einfaches Hashen einer MAC-Adresse erbringt weder eine Pseudonymisierung, noch eine Anonymisierung. Ist der SALT-Wert fest, können die Berechnungen gespeichert und erneut verwendet werden (Rainbowtable), womit die Deanonymisierung in Echtzeit erzielt wird. In diesem Fall können auch günstigere 1 TH/s Lösungen für ca. 100 USD verwendet werden.

Somit wird klar, dass ein einfaches Hashen hier keinen Mehrwert bietet. Es ist stellt sogar eine Gefahr dar, da das Datum aus juristischer Perspektive fälschlicherweise als anonymisiert betrachtet werden könnte und damit seinen datenschutzrechtlichen Schutz verliert.

Okay Google, wer gewinnt die Bundestagswahl?

Hallo zusammen,

Für einen Vortrag habe ich mir mal den Spaß gemacht zu schauen, wie viel Webtracking auf den Webseiten der „großen“ politischen Parteien zu finden ist… ich war erschrocken. Daher habe ich heute die Daten nochmal aktualisiert und mich zu diesem Blogeintrag entschlossen.

8 Parteien, basierend auf „etablierte Parteien“ nach http://bundestagswahl-2017.com/parteien/, Sortierung (dort) nach Zweitstimmen bei letzter Wahl. (CC BY-SA 3.0 DE)

Nur 2/8 Parteien gelingt es, ihre Webseite halbwegs sauber zu gestalten. Platz 3 geht an die CDU, die immerhin nur durch Google Analytics (GA) auffällt. Beim Rest war stets Google und häufig Facebook dabei. Das bedeutet, dass bei 6/8 Parteiwebseiten mindestens ein Google Service zu finden ist.

Hier nun eine Einzelwürdigung der Ergebnisse:

  • cdu.de: Meiner Meinung nach hat google-analytics dort nicht verloren. Sonst soweit in Ordnung.
  • spd.de: Muss nochmal lobend erwähnt werden.
  • die-linke.de: Der Youtube Content erzeugt auch das Doubleclick Cookie. Altruja.de, wohl zum Sammeln von Spenden, bekommt man sicher auch ohne Einbettung gelöst.
  • gruene.de: Das YT Problem, darüber hinaus eine Verbindung zu Facebook. Interessanterweise hervorgerufen durch die FB SDK und nicht durch einen Like-Button.
  • csu.de: Drittparteien wie adform und intelliad klingen nicht nach funktionalen Bestandteilen der Webseite. Neben recht viel Inhalt von Facebook findet man natürlich auch GA.
  • fdp.de: Der Beitrag von „cloudflare.com“ auf der Webseite beschränkt sich auf eine Ressource. Cloudinary wird zum Hosting der Bilder verwendet. Doubleclick, so alleine für sich, war recht überraschend und ist ein Indikator für Tracking zu Werbezwecken.
  • afd.de: Ähnlich wie bei den anderen Parteien.
  • piratenpartei.de: Die Seite ist wie erwartet sauber.

Und auch wenn ich verstehen kann, dass für Parteien das „Wer ist auf meiner Seite?“ relativ wichtig ist, finde ich diese massive Einbindung von Google Services sehr befremdlich. Natürlich lässt sich darüber streiten, welchen Wert die Parteiwebseite bei einer Wahl wirklich hat. Als normaler Bürger wäre ich jedoch der naiven Vorstellung erlegen, dass ich mich auf diesen Seiten bewegen kann, ohne von Google oder Facebook getrackt zu werden. Dies ist nachweislich überwiegend nicht der Fall.

Ob diese Einbettungen rechtlich in Ordnung sind, möchte ich als Informatiker nicht entscheiden und lasse dies daher offen. So oder so hoffe ich, dass mit der Privacy Verordnung dies in Zukunft klarer entschieden werden kann, auch wenn ich diesbezüglich eher pessimistisch bin und eine rechtliche Legitimation des Status quo erwarte.

Abschließend noch kurz ein paar Worte zur Technik der Erhebung. Während ich in diesem Blogeintrag eher meine persönliche und fachliche Meinung zum Ausdruck bringe, ist es mir sehr wichtig, die Ergebnisse der Erhebung auch transparent und nachvollziehbar offenzulegen. Aus diesem Grund finden sich die HAR-Dateien (HTTP Archive) zum Download bereit. Durchgeführt wurde die Analyse mit einem Firefox 55.0.3 ohne weitere Addons gesteuert durch Selenium (Python) 3.5.0 wobei nur die Landingpage geöffnet wurde.

However, in Anbetracht der massiven Einbettung von Google ist die Frage im Titel vielleicht doch nicht so weit hergeholt.

Neulich im Supermarkt…

Hallo zusammen,

kürzlich (nagut, ist schon etwas länger her) bin ich in einem Supermarkt über dieses hochinteressante Zutrittskontrollsystem gestolpert:

Das Problem erkennt man ja schon aus der Ferne; trotzdem noch etwas näher:

Also die 4, 6 und 7 ist ja schonmal sicher; über die 5 lässt sich streiten.

Schon aus frühen MacGyver Episoden und öffentlich-rechtlichen Krimiproduktionen kennen wir das Problem des hinterlassenen Fettfilms auf den Tasten. Wenn man so ein System etabliert ist es daher empfehlenswert mehrere Kombinationen festzulegen und diese halbwegs gleichmäßig unter den berechtigten Personen zu verteilen. Noch besser hat jeder Nutzer seinen eigenen Code — auch wenn dies ggf. zu einem hohen administrativen Aufwand führt.

So oder so: Selbst wenn für diesen Raum kein hoher Schutzbedarf besteht ist es so schon etwas peinlich… und amüsant.

Privacy Badger im Vergleich

Hallo zusammen,

im Vortrag zu Web-Tracking auf Klinikwebseiten, den ich schon im vorherigen Beitrag kurz angesprochen hatte, zeigte ich einen Vergleich der Restriktivität zwischen Ghostery, NoScript, Disconnect und natürlich Addon-freies surfen.

UPDATE: Der Inhalt bzw. die Ergebnisse des Vortrags wurden auf Netzpolitik.org nochmal zusammengefasst, was mich sehr gefreut hat!

Blocker_Vergleich_v01

Abbildung 1: Netzwerkverbindungen zwischen Erstparteien (schwarz) und Drittparteien (rot) bei Abruf von 839 Webseiten (jeweils die Hauptseite) von Krankenhäusern und Kliniken.

In Abbildung 1 ist das Trackingnetzwerk als Graph zu sehen und zeigt wie ungewollte Verbindungen zu Drittanbietern durch die entsprechenden Addons blockiert werden. Dies erkennt man insbesondere daran, dass der äußere Rand breiter wird (mehr unverbundene Erstparteien) und der innere Kern schwacher ausgeprägt ist (weniger Konnektivität). Es ist wichtig einzusehen, dass hierbei nur die Restriktivität gemessen wurde, was alleine noch kein Qualitätsmerkmal darstellt. So würde NoScript den „normalen Benutzer“ möglicherweise überfordern. Ghostery und Disconnect bedürfen, abgesehen von einer ersten Konfiguration, sonst keiner weiteren Benutzerinteraktion.

Nach dem Vortrag kam die Frage auf, wie es sich mit dem Privacy Badger verhält. Dies hatte ich leider nicht vorbereitet, ist aber durchaus berechtigt. Aus diesem Grund habe ich heute die Analyse auch mal mit diesem Addon durchgeführt. Aufgrund der Tatsache, dass der Privacy Badger erst noch „Erfahrungen“ sammeln muss, habe ich vor dem Test 200 deutsche Webseiten (.de-Adressen aus der Alexa Top 1M) besucht die dabei entstandene Konfigurationsdatei für die weitere Analyse verwendet. Darüber hinaus wurden keine weiteren (manuellen) Konfigurationen vorgenommen.

In Abbildung 2 ist das entstandene Trackingnetzwerk abgebildet. Dieses unterscheidet sich äußerlich zunächst nur wenig vom Surfen ohne Addon.

Blocker_PrivacyBadger_v01

Abbildung 2: Trackingnetzwerk mit und ohne Privacy Badger.

Ähnliches zeigt sich auch in der Top 20 der am häufigsten eingebetteten Drittparteien und Vergleichswert ohne Privacy Badger (Messung vom 12.08.2016). Es wird gezeigt, wie viele Erstpartien (First Parties) eine entsprechende Drittpartei einbetten (absteigend sortiert).

# Hosts Mit Privacy Badger Ohne Privacy Badger
1 www.google-analytics.com 285 (34.0%) 287 (34.2%)
2 fonts.gstatic.com 209 (24.9%) 210 (25.0%)
3 fonts.googleapis.com 202 (24.1%) 204 (24.3%)
4 ajax.googleapis.com 134 (16.0%) 134 (16.0%)
5 www.google.com 74 (8.8%) 78 (9.3%)
6 ssl.google-analytics.com 47 (5.6%) 49 (5.8%)
7 s.ytimg.com 45 (5.4%) 48 (5.7%)
8 maps.google.com 42 (5.0%) 43 (5.1%)
9 www.youtube.com 41 (4.9%) 45 (5.4%)
10 i.ytimg.com 40 (4.8%) 38 (4.5%)
11 maps.googleapis.com 39 (4.7%) 40 (4.8%)
12 stats.g.doubleclick.net 38 (4.5%) 43 (5.1%)
13 csi.gstatic.com 35 (4.2%) 36 (4.3%)
14 maps.gstatic.com 31 (3.7%) 32 (3.8%)
15 code.jquery.com 29 (3.5%) 30 (3.6%)
16 piwik.sana.aspr.de 29 (3.5%) 29 (3.5%)
17 www.facebook.com 29 (3.5%) 28 (3.3%)
18 code.etracker.com 25 (3.0%) 26 (3.1%)
19 connect.facebook.net 24 (2.9%) 23 (2.7%)
20 cdnjs.cloudflare.com 22 (2.6%) 21 (2.5%)
googleads.g.doubleclick.net 39 (4.6%)
static.doubleclick.net 38 (4.5%)

In der Tabelle ist zu sehen, dass nur sehr wenige Hosts kategorisch ausgeschlossen worden sind. Hier muss man allerdings aufpassen, denn (anders als Ghostery) bietet der Privacy Badger drei Optionen mit Drittparteien umzugehen: Neben An und Aus gibt es noch eine „Mittel“-Einstellung, die das Tracking durch unterdrücken von Referer und Cookies minimieren soll. Diese „Mittel“-Einstellung findet sich häufig, sind jedoch in den oben gezeigten Statistiken nicht sichtbar. Ich halte jedoch die Wirksamkeit dieser Maßnahme für sehr fragwürdig, was allerdings nochmal intensiverer Analyse bedürfte.

Auch wenn ich den Privacy Badger als ein sympathisches Tool empfinde, sehe ich die getroffenen Grundeinstellungen als zu schwach an. Sehr viel wird zunächst akzeptiert und die Entscheidung auf den Benutzer geschoben. Diese können auch nicht pauschal getroffen, sondern müssen für jeden Tracker einzeln eingestellt werden. So ist es hier, anders als bei Ghostery, mir (über die Oberfläche) nicht möglich, vor dem Test eine restriktive Konfiguration festzulegen bzw. möglichst viel zu blockieren. Und so sehr ich es begrüße, dass der Algorithmus zur Identifizierung von Trackern so offen einsehbar ist, kann ich mir durchaus vorstellen, dass Web-Tracking Firmen dieses Wissen ausnutzen. Letzteres soll jedoch nicht als Kritik verstanden werden.

Alles in allem ist es sicher eine gute Ergänzung und hilft bei der Entscheidungsfindung deutlich besser als RequestPolicy (was zunächst alles blockiert), stellt jedoch leider kein Wundermittel dar. Ohne aktives Handeln durch den Benutzer ist dieses Tool, in meinen Augen, keine wirkliche Verbesserung zu vorher. Man muss jedoch erwähnen, dass der Benutzer nach der Installation auch darauf hingewiesen wird, dass er tätig werden muss.

Die Ergebnisse der anderen Addons sollten jedoch nicht als Produktwerbung missinterpretiert werden. Andere denkbare Gefährdungen, z.B. die interne Datenweitergabe, können nicht ausgeschlossen werden.

Caching Vorteile bei CDNs

Hallo zusammen,

am kommenden Freitag werde ich auf dem mrmcd 2016 in Darmstadt einen Vortrag über Web-Tracking auf Webseiten von Krankenhäusern und Kliniken halten. Dabei werde ich die Ergebnisse meiner letzten DuD-Publikation vortragen sowie noch einige dafür neu erarbeitete Inhalte.

In Vorbereitung dessen habe ich gestern noch einen Test durchgeführt, was Content Delivery Networks (CDN, auch: Content Distribution Network) eigentlich bringen. Solche Dienste sind darauf spezialisiert, Daten (die in Webseiten integriert werden) mit hoher Geschwindigkeit und geringen Antwortzeiten den Besuchern bereitzustellen. Nicht selten wird jedoch auch hervorgebracht, dass der User die verlinkten Bibliotheken und Schriftarten selbst auf seinem Rechner cachen, über mehrere verschiedene Webseiten hinweg „konservieren“ und die Netzwerklast darüber minimieren kann. So z.B. hier (Nummer 2).

Diesen zuletzt genannten Vorteil wollte ich mir mal genauer ansehen. Es ist weniger eine repräsentative Studie, sondern dient mehr dazu einen Eindruck zu bekommen. So habe ich 150 Webseiten auf zwei verschiedene Wege betreten: mit einem jeweils neuen (unbenutzten) Firefox Profil und mit einem persistenten Profil. Da Selenium persistente Profile eigentlich nicht unterstützt, musste hier noch ein Workaround geschaffen werden.

Die Ergebnisse sind für mich doch sehr überraschend. Die Anzahl der Verbindungen zu den Erstparteien (Webseiten) und darin verlinkten Drittparteien blieb konstant (nur 2 Verbindungen weniger bei ca. 7200 Verbindungen). D.h. die Anzahl der geladenen Ressourcen hat sich nicht (signifikant) verändert. Wenn man sich die HTTP Header der Responses anschaut sieht man, dass nur 16 Ressourcen mehrfach verwendet wurden (304 Not Modified). Dabei überwiegend JavaScript-Dateien von Trackern und ein paar Schriftarten. Die Top 10 der am häufigsten eingebetteten Drittparteien sowie die Anzahl der Verbindungen blieb konstant. Verbindungen spare ich also nicht, maximal etwas Traffic.

Nun könnte man argumentieren, dass 150 Webseiten zu wenig sind um vom Caching-Vorteil zu profitieren. Während jedoch das normale Standardprofil nur 24 MB groß ist, ist das persistente nach den 150 Webseiten auf 222 MB gewachsen. Auch wenn Speicherplatz heute kein so großes Thema mehr ist: beliebig Luft nach oben ist hier auch nicht. Zu prüfen wäre noch, wie die Cache-Strategie von Firefox im Detail aussieht.

Es ist, wie gesagt, nicht repräsentativ. Es erwächst jedoch der Eindruck, dass der Cache Vorteil eines CDN geringer ist als erwartet. Dies ist auch der überwältigenden Vielfalt verschiedener Bibliotheken und Schriftarten geschuldet. Die verbleibenden Vorteile von CDNs bleiben natürlich unberührt.

Mit unsicherem Code ins Weltall

Hallo zusammen,

zur Abwechslung mal was über Krypto. Ein Bekannter hat mir einen Hinweis gegeben, dass in einer Stargate SG1 Folge (S7E09 „Avenger 2.0“) auf einer Tafel etwas geschrieben stand, was recht „kryptisch“ aussieht. Hier ein Bild der Szene (ca. Minute 12):

Bildzitat aus Stargate SG1 Episode Staffel 7 Folge 9 "Avenger 2.0"

Bildzitat aus Stargate SG1 Episode Staffel 7 Folge 9 „Avenger 2.0“

Auf den ersten Blick vermutet man Java, was natürlich recht amüsant wäre: Ob (damals Sun) Oracle wohl eine JVM für Stargates (bzw. Wahlgeräte) anbietet? Tatsächlich ist es jedoch C#, was es nicht weniger amüsant macht. Da es eine über 10 Jahre alte Episode ist, ist dies natürlich auch anderen schon aufgefallen. Es handelt sich bei diesem Quelltext um eine etwas intensiver kommentierte Version einer Klasse zur Entschlüsselung von Dateien auf dem Dateisystem, die man hier finden kann. Analog gibt es natürlich auch eine Version zur Verschlüsselung.

Es ist natürlich so, dass die „Macher“ der Serie nur etwas kryptisch aussehenden Programmtext präsentieren wollten und sind dabei über diese Zeilen gestolpert. Aber aus Neugier habe ich mir das Programm etwas näher angesehen. Es besteht aus einer Hilfsklasse StoreCryptoStream, aus einer Klassenmethode zur Generierung des Schlüsselmaterials (GenerateKey) und einer weiteren Klassenmethode zur Vorbereitung und Durchführung der Entschlüsselung (DecryptData).

In der DecryptData-Methode werden Streams eingerichtet und die Entschlüsselung durchgeführt. Aufmerksam wurde ich, als ich mir die GenerateKey-Methode genauer angesehen habe, welche aus einer Passphrase (String) das zur Verschlüsselung (DES) passende Schlüsselmaterial generiert:

          symKey = new byte[8];
          symIV = new byte[8];

          SHA1_CSP sha = new SHA1_CSP();
          sha.Write(bt)
          sha.CloseStream();
          for (int i = 0; i < 8; i++) {
              symKey[i] = sha.Hash[i];
          }
          for (int i = 8; i < 16; i++) {
              symIV[i - 8] = sha.Hash[i];
          }

Das fand ich recht interessant: Hier werden, aus dem Hashwert (SHA1) der Passphrase (String), Schlüssel und Initialisierungsvektor abgeleitet. Da wir bei DES (DecryptData-Methode) eine 64 Bit Schlüssellänge (wovon 56 effektiv sind) und 64 Bit Blocklänge haben, brauchen wir also 128 Bit die uns durch den 160 Bit SHA1 zur Verfügung stehen. Ein Hashverfahren zu verwenden um aus einer Passphrase Schlüsselmaterial zu gewinnen ist ja nicht neu: Dies findet auch bei PBKDF2 statt. Es wird zur Erhöhung der Brute-Force-Resistenz eingesetzt, da die Berechnung eine gewisse Zeit in Anspruch nimmt und nicht abgekürzt werden kann. Dabei werden jedoch sehr viel mehr Iterationen durchgeführt (z.B. 100 000) und nicht nur eine.

Die meisten symmetrischen Blockchiffren benötigen keinen Initialisierungsvektor (IV): so auch der DES nicht. Da allerdings regelmäßig keine blockweise Verschlüsselung sondern ein Betriebsmodus zum Einsatz kommt, hat er einen festen Platz in den Programmbibliotheken. Normalerweise wird der IV vor der Verschlüsselung zufällig generiert und vor/nach der Übermittlung als Klartext mitgesendet. Der Empfänger kann mittels geheimen Schlüssels und mitgesendeten IVs das Chiffrat entschlüsseln. Die Generierung eines IVs aus der Passphrase hat den enormen praktischen Vorteil, dass diese dem verschlüsselten Ciphertext nicht beigefügt sein muss. Der Nachteil ist, dass der IV dann nicht mehr zufällig generiert wird sondern deterministisch vom Schlüssel bzw. der Passphrase abhängt.

So was Ähnliches wird zwar auch im SSH Protokoll durchgeführt. So wird dort unter Einsatz einer Hashfunktion und unterschiedlichen Salt-Werten mehrere Schlüssel und IVs generiert. Allerdings wird hierbei schon zu einem frühen Zeitpunkt der „Zufall“ eingebracht und genau diese Zufälligkeit fehlt beim gezeigten Programm vollständig.

Ist das jetzt gut oder schlecht? Ich habe dazu recherchiert und mir meine eigenen Gedanken gemacht und die Antwort ist: Es kommt darauf an, ist aber fast immer schlecht.

Nehmen wir z.B. Stromchiffren (wie, mittlerweile unsicher, RC4). Hier würde, bei gleichem Passwort, immer der gleiche IV und damit der gleiche Schlüsselstrom generiert werden. Sofern zwei verschlüsselte Texte mit dem gleichen Schlüsselstrom verschlüsselt sind, könnten diese gegenseitig ge-xor-t und damit der Schlüsselstrom herausgerechnet werden. Ebenso bei bei Blockchiffren mit dem entsprechenden Betriebsmodus wie dem Cipher Feedback Mode (CFB) oder dem Output Feedback Mode (OFB): Da hier aus einer Blockchiffre eine Stromchiffre konstruiert wird, haben wir exakt das gleiche Problem. Bei diesen Verfahren hängt die Sicherheit sehr stark an der Zufälligkeit des IVs, welcher so jedoch nicht mehr zufällig ist.

Wie ist es bei einer Blockchiffre im ECB und CBC Modus? Beim ECB-Modus sind wir schmerzfrei, denn dort wird der IV nicht verwendet. Müssen dabei jedoch die allgemeine Unsicherheit des ECBs hinnehmen. Beim CBC-Modus (den ich schonmal erklärt habe) haben wir zunächst auch kein Problem. Allerdings muss man hierbei gut aufpassen: Verschlüsselungsbibliotheken werden beim CBC-Modus den IV ans Ende des Chiffretextes setzen, da dieser üblicherweise zufällig generiert und zur Entschlüsselung gebraucht wird. Das bedeutet aber, dass wir dem verschlüsselten Text ein (Teil)Hash des Passwortes mitsenden! Möglicherweise kann genau dieser Teilhash dann in einer Rainbowtable für SHA1 gefunden und entschlüsselt werden. Ebenso erleichtern wir dem Angreifer die vollständige Schlüsselsuche beträchtlich. Allgemein wird der IV als „öffentlich“ angesehen und wird dementsprechend ungeschützt sein. Eine Klassifizierung, welcher ein einfacher SHA1 Hash der Passphrase nicht haben sollte.

Zusammenfassend sollte man den IV zufällig generieren und auch genau so verwenden. Nur wenn man ganz genau weiß was man tut, kann man von dieser Regel abweichen.

Wie ist es nun bei diesem Programm? Das ist leider nicht ganz klar, denn der Programmtext lässt sich (zumindest unter Visual Studio) nicht mehr übersetzen: in über 10 Jahren hat sich C# diesbezüglich weiterentwickelt. Man könnte das Programm zwar durch Anpassungen wieder lauffähig bekommen, würde jedoch damit ggf. auch die Funktionsweise beeinflussen. Es ist zu vermuten, dass hier der ECB-Modus zum Einsatz kam und so der IV keine Rolle spielt. Wenn der CBC eingesetzt wurde, müsste man prüfen, ob dem Ciphertext der IV beigelegt war. So oder so war jedoch schon damals (und ist heute weiterhin) von der Nutzung dieses Quelltextes (bzw. einer lauffähigen Variante) grundsätzlich abzuraten.

Dies könnte auch der Grund sein, weshalb der in dieser Episode programmierte „Avenger“ (Computervirus) so unsicher war ;-).