eBlocker Labs: SmartTV Studie Teil 1 (Samsung) 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 Samsung 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 Samsung 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 Samsung 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 Programm verfolgt. Requests an die Sender werden bereits abgesendet, sobald auf das Programm 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 Samsung 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/httpsRequests 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 01.09.2016
Seite 1 von 9
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 Programm 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 Domäne 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 URL 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 URLs 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 httpsRequests 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. 5.1.1 https-Requests Im StandBy-Modus wurden https-Requests zu folgenden Serveradressen beobachtet: Domäne Ziel 01.09.2016
www.youtube.com (216.58.213.14) YouTube Seite 2 von 9
Domäne Ziel
i.ytimg.com (216.58.213.46) YouTube
Domäne Ziel
www.google.com (216.58.213.36) Google
Domäne Ziel
tvdstv.api.watchmi.tv (176.28.1.240) TV Digital
Domäne Ziel
api-global.netflix.com (54.246.102.195) Netflix
Domäne Ziel
ichnaea.netflix.com (46.137.159.196) Netflix
Domäne Ziel
50.112.116.33 Amazon AWS
Domäne Ziel
multiscreen.samsung.com (52.25.243.102) Samsung
Domäne Ziel
fkp.samsungcloudsolution.com (175.41.134.166) Samsung
Domäne Ziel
noticecdn.samsungcloudsolution.com (54.192.77.5) Samsung
Domäne Ziel
osb-eusvc.samsungqbe.com (52.28.38.189) Samsung
Domäne Ziel
osb.samsungqbe.com (52.58.18.97) Samsung
5.1.2 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. Domäne Ziel Vermuteter Zweck Tracking-Cookie/ID
samsung.images.dvbdata.com Axel Springer SE / dvbData / TV DIGITAL Online Standbilder (viele Requests) Nein
Domäne Ziel
tv.ampya.com Ampya
01.09.2016
Seite 3 von 9
5.2
Vermuteter Zweck Tracking-Cookie/ID
Musik-Empfehlungen
Domäne Ziel Vermuteter Zweck Tracking-Cookie/ID
cdn.samsungcloudsolution.com Samsung Verbindungstest Nein
Domäne Ziel Vermuteter Zweck Tracking-Cookie/ID
104.25.80.14 CloudFlare unbekannt Nein
Domäne Ziel Vermuteter Zweck
youtube.com YouTube unbekannt
Tracking-Cookie/ID
Cookie: VISITOR_INFO1_LIVE=GZyhzXaABCD; PREF=f1=50000000; yt-dev.persistent-cookie=1; GPS=1; YSC=KGlckI6XYZ0
Domäne Ziel Vermuteter Zweck Tracking-Cookie/ID
s.ytimg.com YouTube Unbekannt / Bilder Nein
X-SAMSUNG-PSID: KA2JJ5WILFFA7DCMP6W3KK3312345678
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: 5.2.1
https-Requests Domäne Ziel
lcprd2.samsungcloudsolution.net (54.246.181.131) Samsung
Domäne Ziel
osb.samsungqbe.com (52.29.248.210) Samsung
Domäne Ziel
script.ioam.de (91.215.103.64) InfoOnline (Datensammler zur Reichweitenanalyse)
Domäne Ziel
54.93.206.68 Amazon AWS
01.09.2016
Seite 4 von 9
Domäne
configprd.samsungcloudsolution.net (54.229.31.255)
Ziel
Samsung
Domäne Ziel
www.samsungotn.net (157.55.184.57) Samsung
Domäne Ziel
otnprd9.samsungcloudsolution.net (54.235.198.13) Samsung
5.2.2
5.3
http-Requests Domäne Ziel Vermuteter Zweck Tracking-Cookie/ID
itv.ard.de ARD Website mit Bildern etc. (Overlay für Fernsehbild), viele Aufrufe
Domäne Ziel Vermuteter Zweck Tracking-Cookie/ID
cdn.samsungcloudsolution.com Samsung unbekannt Nein
Domäne Ziel Vermuteter Zweck Tracking-Cookie/ID
az43064.vo.msecnd.net unbekannt unbekannt – vermutlich Firmware Updates Nein
Cookie: ardstart=rbp*1*rangeid*201608*ra*201608 *u*987654329278e27c8708ca54d9e4*v*3*ts*14719587
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. Domäne URL Programm TrackingCookie/ID
Domäne 01.09.2016
prosieben.de http://redbutton-lb-prod.prosieben.de/subscribe/? c=PRO7&timeout=60000&callback=rbcb1456796710845 Pro 7 Cookie: wt3_eid=%3B349963160860786%7C2147100842300020506; wrapped_proxy_v2=N4IgzgLg9gTgpiAXKAlgE.....PRVqXPNVVX8/ygA; wt3_sid=%3B349963160860786 sat1.de Seite 5 von 9
URL
http://redbutton-lb-prod.sat1.de/subscribe/ ?c=SAT1&timeout=60000&callback=rbcb4204975981265
Programm TrackingCookie/ID
Sat.1 Cookie: wt3_eid=%3B349963160860786%7C2147100841600529408; wrapped_proxy_v2=N4IgzgLg9gTgpiAXKAlgE.....IesrykqipeV5QA=; wt3_sid=%3B349963160860786
Domäne URL
rtl.de http://cdn.digitaltext.rtl.de/launchbar/index.html
Programm TrackingCookie/ID
RTL Cookie: smartns_uuid=91fc662f-xxxx-xxxx-xxxx-5eb0e152427c
Domäne URL
rtl2.de http://hbbtv.rtl2.de/redbutton.php?cc=de
Programm TrackingCookie/ID
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 URLs (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 Tracking-Dienste zu finden, die offenbar im Kontext des jeweils gewählten Programms aktiv sind. Hier zwei Beispiele von RTL bzw. RTL2: Domäne URL
de.ioam.de http://de.ioam.de/tx.io?st=ctvrtldi&cp=dbrscwf_tve_redbutton& 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<=1472652048688&ev=& cs=jdnp5o&mo=0
Programm TrackingCookie/ID
RTL Cookie: i00=002e7cf1011730c5957a9f3ca0001%3B57a9f3ca%3B58f4c12d
01.09.2016
Seite 6 von 9
Domäne
etracker.de
URL
http://www.etracker.de/cnt.php?et=xjVHpm&v=3.0& 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=
Programm TrackingCookie/ID
RTL2 Nein
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.
01.09.2016
Seite 7 von 9
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:
01.09.2016
Seite 8 von 9
8.3
Requestdetails mit Cookie
Beispielhafte Daten eines Requests bei dem ein Cookie gesetzt wird:
01.09.2016
Seite 9 von 9
