eblocker Labs: SmartTV Studie Teil 1 (Samsung)

Transkript

1 eblocker Labs: SmartTV Studie Teil 1 () 1 Einleitung Smarte Geräte sind im Trend und halten immer mehr Einzug in die Haushalte. Leider bergen sie häufig ein Risiko für die Privatsphäre, da sie unbemerkt Daten über das Nutzungsverhalten des Anwenders aufzeichnen und an Dritte weitergeben. Diese Studie in der Version v1 beschäftigt sich mit der Analyse der von SmartTVs erfassten und weitergegebenen Nutzungsdaten. In der ersten Version haben wir uns auf ein aktuelles Gerät von beschränkt. In weiteren Updates werden in den nächsten Monaten weitere Geräte hinzugenommen und die Untersuchung fortgeschrieben. 2 Zusammenfassung Bereits diese erste Untersuchung hat gezeigt, dass ein SmartTV direkt nach Inbetriebnahme und dauerhaft während des Betriebs zahlreiche Internet-Anfragen (sog. Requests = Senden an und Abrufen von Daten eines Servers) an unterschiedliche Anbieter sendet. Diese Requests senden dabei in der Regel Daten über das Verhalten des Nutzers. Einige dieser Requests sind geeignet genaue Nutzungs- und Persönlichkeitsprofile zu erstellen. Viele Requests gehen an diverse Server von selbst. Aber darüber hinaus werden auch sehr viele Requests an kommerzielle Anbieter wie Netflix, Maxdome, TV-Digital, Ampya und andere gesendet. Dabei ist es ganz unerheblich, ob der Nutzer entsprechende Apps auf dem Gerät verwendet oder überhaupt einen Account bei einem dieser Anbieter besitzt. Requests im Kontext von HbbTV beziehen sich auf den gerade eingeschalten Sender. Entsprechende Requests an Serveradressen von ARD, ProSieben und anderen wurden beobachtet. Hierbei ist es wiederum unerheblich, ob der Nutzer HbbTV explizit aktiviert hat ( Red Button ) oder nur das laufende verfolgt. Requests an die Sender werden bereits abgesendet, sobald auf das umgeschaltet wird. Bemerkenswert ist, dass einige dieser Requests sogar im StandBy-Modus abgesendet werden. Also wenn der normale Nutzer eigentlich davon ausgeht, dass das Gerät ausgeschaltet ist. Einige Requests enthalten Identifizierungs-Cookies oder andere eindeutige Gerätekennungen, die sich auch nach Aus- und Wiedereinschalten des Gerätes nicht ändern. Diese sind daher geeignet, den Nutzer während der gesamten Lebensdauer des SmartTV immer wieder zu erkennen. 3 Versuchsaufbau Untersucht wurde ein aktuelles Serie5 SmartTV aus dem Jahr 2016 (UE40K5579). Das SmartTV wurde in der Standardkonfiguration belassen, so wie es wohl die meisten Kunden verwenden würden. Das Gerät wurde bei keinem Inhalte Anbieter aktiv registriert oder angemeldet und es wurde kein Abonnement für einen Pay-TV-Sender oder für andere Dienste abgeschlossen. Das SmartTV wurde per Antennen-Kabel an das Netz von Kabel Deutschland angeschlossen. Im Sendersuchlauf wurden nur freie Kanäle verwendet. Das Gerät wurde per WLAN in ein abgeschlossenes lokales Netz integriert. In diesem lokalen Netz wurden außer dem SmartTV und dem WLAN-Router nur ein eblocker sowie ein Laptop zur Auswertung der Daten betrieben. Das lokale Netz war per Kabel-Modem mit dem Internet verbunden. 4 Durchführung Das SmartTV-Gerät wurde wie ein normales Fernsehgerät in verschiedenen Anwendungsfällen getestet. Der eblocker wurde dazu verwendet, die vom SmartTV jeweils abgesendeten http/https- Requests zu protokollieren und zu analysieren. Mit dieser Analyse ist der eblocker anschließend in der Lage, die Requests zu Datensammlern und damit die Profilbildung aktiv zu unterbinden. Hierbei ist zu beachten, dass bei es sich bei den meisten untersuchten Anwendungsfällen nicht um spezifische SmartTV-Anwendungen handelt, sondern um ganz normales Fernsehen, wie es auch Seite 1 von 9

2 schon vor 50 Jahren mit einem Röhrengerät möglich gewesen wäre. Folgende Fernseher -Anwendungsfälle wurden im Einzelnen untersucht: Gerät im Standby-Modus Einschalten des Geräts nach Trennung von Stromversorgung Einschalten des Geräts aus dem StandBy Längere Zeit im gleichen verweilen Kanalwechsel (verschiedene Wechsel zwischen ÖR und kommerziellen Sendern) Es wurde jeweils untersucht, ob und welche https- oder http-requests an Server im Internet geschickt wurden und was ggf. deren Inhalt ist. Insbesondere ob der RequestDaten enthält, die geeignet sind, das Gerät bzw. den Nutzer dauerhaft wieder zu erkennen und damit ein Persönlichkeitsprofil zu bilden. 4.1 https-verbindungen (SSL-Verschlüsselung) Auf Grund der Ende-zu-Ende-Verschlüsselung von https-verbindungen, kann der eblocker bei solchen Requests nur feststellen, zu welcher bzw. zu welcher IP-Adresse die Verbindung aufgebaut wird. Er kann jedoch nicht den Inhalt der Anfrage analysieren. 4.2 http-verbindungen Bei unverschlüsselten http-requests kann der eblocker die genaue sowie etwaige Meta-Daten der Anfrage analysieren und protokollieren. Hier ist insbesondere interessant, ob der Request Identifizierungs-Cookies oder ähnliche, eindeutige IDs enthält, über die das Gerät und damit der Nutzer dauerhaft erkannt werden kann und somit ein Profil der Gerätenutzung erstellt werden kann. 5 Ergebnisse In den folgenden Abschnitten sind die Untersuchungsergebnisse zu den unterschiedlichen Anwendungsfällen dokumentiert. Hierbei ist festzuhalten, dass Zeitpunkt, Reihenfolge und genaue s der Requests nicht konstant sind, so dass eine erneute Messung nicht immer exakt dieselben Ergebnisse liefert. Einige Requests werden regelmäßig abgesendet - selbst wenn sich das Gerät im StandBy-Modus befindet. Diese Requests sind also grundsätzlich unabhängig vom konkreten Anwendungsfall und werden nicht in jedem Abschnitt erneut aufgelistet, auch wenn sie immer wieder protokolliert wurden. Andere Requests werden dagegen nur abgesendet, wenn das Gerät sichtbar eingeschaltet ist, wenn ein bestimmter Sender ausgewählt ist, oder wenn zusätzliche Funktionen (wie HbbTV oder Apps) aktiviert wurden. Die Protokolle sind in diesem Sinne als Momentaufnahmen zu verstehen. Es wurde versucht, die Systematik zu ermitteln und entsprechend zu dokumentieren. Eine gewisse Unschärfe ist beim aktuellen Stand der Untersuchung jedoch unvermeidbar. 5.1 Gerät im StandBy-Modus Selbst im StandBy-Modus werden regelmäßig https- und http-requests abgesendet. Bei https- Requests wird der Datenstrom zwischen dem Gerät und dem Server verschlüsselt. Bei http erfolgt die Datenübermittlung ohne Verschlüsselung und kann so von Dritten mitgelesen werden https-requests Im StandBy-Modus wurden https-requests zu folgenden Serveradressen beobachtet: ( ) YouTube Seite 2 von 9

3 i.ytimg.com ( ) YouTube ( ) Google tvdstv.api.watchmi.tv ( ) TV Digital api-global.netflix.com ( ) Netflix ichnaea.netflix.com ( ) Netflix Amazon AWS multiscreen.samsung.com ( ) fkp.samsungcloudsolution.com ( ) noticecdn.samsungcloudsolution.com ( ) osb-eusvc.samsungqbe.com ( ) osb.samsungqbe.com ( ) http-requests Im StandBy-Modus wurden folgende http-requests aufgezeichnet. Da alle Daten bei http unverschlüsselt übertragen werden, konnte hier der Inhalt und der damit verbundene Zweck der Daten betrachtet werden. samsung.images.dvbdata.com Axel Springer SE / dvbdata / TV DIGITAL Online Standbilder (viele Requests) tv.ampya.com Ampya Seite 3 von 9

4 Musik-Empfehlungen X-SAMSUNG-PSID: KA2JJ5WILFFA7DCMP6W3KK cdn.samsungcloudsolution.com Verbindungstest CloudFlare unbekannt youtube.com YouTube unbekannt Cookie: VISITOR_INFO1_LIVE=GZyhzXaABCD; PREF=f1= ; yt-dev.persistent-cookie=1; GPS=1; YSC=KGlckI6XYZ0 s.ytimg.com YouTube Unbekannt / Bilder 5.2 Einschalten nach Trennung von Stromversorgung Das Gerät wurde auf den Sender ARD HD eingestellt, ausgeschaltet, ca. 30 Sekunden vom Stromnetz getrennt und wieder eingeschaltet. In den ersten zwei Minuten nach dem Einschalten wurden die folgenden Requests protokolliert: https-requests lcprd2.samsungcloudsolution.net ( ) osb.samsungqbe.com ( ) script.ioam.de ( ) InfoOnline (Datensammler zur Reichweitenanalyse) Amazon AWS Seite 4 von 9

5 configprd.samsungcloudsolution.net ( ) ( ) otnprd9.samsungcloudsolution.net ( ) http-requests itv.ard.de ARD Website mit Bildern etc. (Overlay für Fernsehbild), viele Aufrufe Cookie: ardstart=rbp*1*rangeid*201608*ra* *u* e27c8708ca54d9e4*v*3*ts* cdn.samsungcloudsolution.com unbekannt az43064.vo.msecnd.net unbekannt unbekannt vermutlich Firmware Updates 5.3 Andere Server und Kanalwechsel Grundsätzlich wurde festgestellt, dass das SmartTV-Gerät direkt nach einem Kanalwechsel Requests an eine Website des jeweiligen Senders schickt. Diese Requests enthalten in der Regel Identifizierungs-Cookies oder andere, eindeutige IDs, über die das Gerät und damit der Nutzer identifiziert werden kann. Einige Beispiele sind hier aufgeführt. Dabei ist zu beachten, dass je nach Sender in der Regel eine Vielzahl weiterer Requests abgeschickt wird. prosieben.de c=pro7&timeout=60000&callback=rbcb Pro 7 Cookie: wt3_eid=%3b %7c ; wrapped_proxy_v2=n4igzglg9gtgpiaxkalge...prvqxpnvvx8/yga; wt3_sid=%3b sat1.de Seite 5 von 9

6 Sat.1 Cookie: wt3_eid=%3b %7c ; wrapped_proxy_v2=n4igzglg9gtgpiaxkalge...iesrykqipev5qa=; wt3_sid=%3b rtl.de RTL Cookie: smartns_uuid=91fc662f-xxxx-xxxx-xxxx-5eb0e152427c rtl2.de RTL2 Cookie: smartns_uuid=3b3edb4b-yyyy-yyyy-yyyy-6ef04c62b81c Diese oder ähnliche Requests werden regelmäßig (z.b. minütlich) wiederholt, so dass der Sender im Prinzip recht genau verfolgen kann, ob und wie lange eine Sendung gesehen wird. Die Requests von Sendern aus der gleichen Sendefamilie gehen zwar an unterschiedliche s (z.b. prosieben.de und sat1.de ). Sie sind aber sehr ähnlich aufgebaut und verwenden teilweise die gleichen IDs in den Cookies, so dass es technisch kein Problem ist, diese Daten und damit das Fernsehverhalten auch senderübergreifend auszuwerten. Dazwischen sind immer wieder direkte Requests an bekannte Dienste zu finden, die offenbar im Kontext des jeweils gewählten s aktiv sind. Hier zwei Beispiele von RTL bzw. RTL2: de.ioam.de co=%2frtl_hbbtv_red_button&pt=cp&rf=&r2=& ur=cdn.digitaltext.rtl.de&xy=1920x1080x24& lo=de%2fnordrhein-westfalen&cb=000d&vr=308& id=ap8m7o&lt= &ev=& cs=jdnp5o&mo=0 RTL Cookie: i00=002e7cf c5957a9f3ca0001%3b57a9f3ca%3b58f4c12d Seite 6 von 9

7 etracker.de amp;java=n&et_easy=0& et_pagename=button_16&et_areas=hbb-tv& et_ilevel=0&et_target=,0,0,0&et_lpage=0& amp;et_trig=0&et_se=0&et_cust=0& et_basket=&et_url=&et_tag=& et_sub=&et_organisation=&et_demographic= RTL2 6 Fazit Das untersuchte Gerät ist unter Datenschutz- und Privatsphäreaspekten eine Katastrophe. Es sendet permanent personenbezogenen Daten (wie die IP-Adresse des Nutzer) ohne Nutzerinteraktion und ohne dessen Einwilligung. Zudem werden eindeutige IDs und Cookies verwendet, die auch bei dynamischen, wechselnden IP-Adressen eine eindeutige Zuordnung ermöglichen. Diese Daten sind geeignet sehr genaue Persönlichkeitsprofile über den Nutzer, seine Interesse und seine häuslichen Gewohnheiten wie z.b. Anwesenheitszeiten aufzuzeichnen. Der Datenversand ist durch Konfigurationseinstellungen nicht ohne weiteres abstellbar. Der Einsatz des Gerätes ohne weitere Schutzfunktion birgt daher große Risiken für die Privatsphäre des Anwenders. 7 Wie der eblocker schützt Der eblocker schützt in der aktuellen Version bereits vor dem unbemerkten Datenabgriff bei der Verwendung von hbbtv, da dort in der Regel normale Datensammler verwendet, die dem eblocker bereits bekannt sind. Dank der integrierten eblocker Analysefunktion, die auch für diese Studie verwendet wurde, kann der über hbbtv hinaus gehende Datenversand an Hersteller und Drittanbieter leicht erkannt und mit einfacher Definition von Blockierregeln unterbunden werden. Aktuell arbeiten wir an dem Aufbau einer Datenbank mit Regeldefinitionen für häufig verwendete smarte Geräte, die dann ganz einfach durch Nutzer dieser Geräte aktiviert werden können. Es ist geplant, das eblocker Anwender, die Geräte-spezifischen Regeln mit eblocker und anderen Nutzern teilen können, so dass durch den Community-Effekt in kurzer Zeit viele smarte Geräte in der eblocker Datenbank erfasst und abgesichert werden können Seite 7 von 9

8 8 Anhang Beispiele für Protokoll-Daten des eblockers (Screenshots): 8.1 Verschlüsselte https-verbindungen 8.2 Protokollierte http-requests Beispielhafte Darstellung von protokollierten Requests beim Einschalten des Gerätes: Seite 8 von 9

9 8.3 Requestdetails mit Cookie Beispielhafte Daten eines Requests bei dem ein Cookie gesetzt wird: Seite 9 von 9