WEBVTT 00:00.000 --> 00:01.320 Die Corona-App kommt. 00:01.840 --> 00:05.440 Wenn man Kontakt zu einer infizierten Person hatte, wird das Handy 00:05.440 --> 00:07.080 künftig Alarm schlagen. 00:07.580 --> 00:11.220 Dann kann man sich testen lassen und in Quarantäne gehen, um weitere 00:11.220 --> 00:12.900 Ansteckungen zu verhindern. 00:13.540 --> 00:17.520 Nach massivem Protest von Datenschützern werden die von der App 00:17.520 --> 00:21.940 gesammelten Kontaktdaten jetzt nicht wie ursprünglich geplant an einen 00:21.940 --> 00:27.060 zentralen Server weitergeleitet, sondern dezentral, jeweils auf dem 00:27.060 --> 00:28.820 eigenen Handy gespeichert. 00:29.280 --> 00:34.220 Für den IT-Sicherheitsexperten Torsten Strufe vom Kassur-Institut für 00:34.220 --> 00:38.100 Technologie nicht wirklich ein Sieg für die Privatsphäre. 00:38.580 --> 00:42.180 Im Unterschied zu China oder Südkorea wird die Corona-App in 00:42.180 --> 00:46.460 Deutschland ganz bewusst auf die Speicherung des Aufenthaltsortes per 00:46.460 --> 00:47.960 GPS verzichten. 00:48.240 --> 00:50.440 Wenn wir jetzt beide ein Smartphone haben und wir sind jetzt schon 00:50.440 --> 00:52.960 unter zwei Meter Entfernung, dann könnten unsere beiden Telefone das 00:52.960 --> 00:55.480 registrieren und sagen, aha, hier ist also ein anderes Telefon in 00:55.480 --> 00:57.880 einer sehr geringen Distanz und sich das lokal speichern, ohne jetzt 00:57.880 --> 00:59.560 wissen zu müssen, dass wir in Karlsruhe sind oder sowas. 00:59.700 --> 01:03.460 Nur zu dem Zeitpunkt, wenn jemand positiv getestet würde, also sagen 01:03.460 --> 01:06.220 wir mal jetzt beispielsweise, ich würde jetzt krank werden und ich 01:06.220 --> 01:08.940 würde zum Gesundheitsamt gehen und positiv getestet werden, dass zu 01:08.940 --> 01:12.220 dem Zeitpunkt die Informationen, die mein Telefon gespeichert hat, 01:12.320 --> 01:13.980 dann tatsächlich irgendwo hin übermittelt werden. 01:14.160 --> 01:18.700 Torsten Strufe ist Professor für praktische IT-Sicherheit am KIT. 01:19.560 --> 01:22.760 Überrascht hat er die erbitterten Auseinandersetzungen der letzten 01:22.760 --> 01:23.920 Wochen verfolgt. 01:24.360 --> 01:27.500 Dabei ging es ausschließlich um die Frage, wie bei einem 01:27.500 --> 01:31.520 Infektionsfall die Warnmeldung die Besitzer der als Kontakte 01:31.520 --> 01:33.380 gespeicherten Handys erreicht. 01:33.600 --> 01:36.580 Da ist der zentrale Ansatz, der jetzt immer so allgemein als großer 01:36.580 --> 01:39.280 zentraler Ansatz diskutiert wurde, ist davon ausgegangen, dass im 01:39.280 --> 01:43.300 Prinzip der Server guckt, welche Telefone waren nah beieinander und 01:43.300 --> 01:46.080 dementsprechend welchen Telefonen, wenn sie jetzt nachfragen, muss ich 01:46.080 --> 01:46.840 die Informationen geben. 01:46.840 --> 01:48.920 Ja, da gibt es unter Umständen eine Infektionsgefahr. 01:49.080 --> 01:51.340 Und bei dem sogenannten dezentralen Ansatz wäre es nicht so, sondern 01:51.340 --> 01:53.680 da würde der Server einfach die gesamten Informationen, die die 01:53.680 --> 01:56.380 Telefone aufgenommen haben, online stellen und dann würden die 01:56.380 --> 01:59.260 Telefone selber sich diese gesamten Daten runterladen und dann lokal 01:59.260 --> 01:59.700 entscheiden. 01:59.760 --> 02:02.400 War ich persönlich in einer gewissen Nähe zu jemandem anderes, der 02:02.400 --> 02:03.920 jetzt gerade positiv getestet wurde oder nicht. 02:03.960 --> 02:05.060 Das ist eigentlich schon der ganze Unterschied. 02:05.160 --> 02:09.140 Für den Experten gibt es auch beim jetzt favorisierten dezentralen 02:09.140 --> 02:12.220 Ansatz einen Verlust an Privatsphäre. 02:12.220 --> 02:15.220 Bei dem dezentralen Ansatz, da sieht man ganz gut, dass die Entwickler 02:15.220 --> 02:17.620 vor allem dem Betreiber misstrauen. 02:17.880 --> 02:20.460 Stattdessen aber sagen, okay, wenn ich jetzt beispielsweise positiv 02:20.460 --> 02:22.760 getestet wurde, dann ist es für mich keine schützenswerte Information, 02:22.960 --> 02:24.780 dass jetzt meine Bekannten wissen, dass ich es gewesen bin. 02:24.840 --> 02:27.080 Und dementsprechend schützen sie also gerade diese Informationen 02:27.080 --> 02:27.960 praktisch gar nicht. 02:28.100 --> 02:30.760 Also ich kann bei dem, in Anführungszeichen, dezentralen System leicht 02:30.760 --> 02:34.260 rausbekommen, wenn ich informiert werde, dass ich ein Risiko habe, wer 02:34.260 --> 02:35.760 es gewesen ist, den ich getroffen habe. 02:35.900 --> 02:40.740 Weder der zentrale noch der dezentrale Ansatz schütze die Privatsphäre 02:40.740 --> 02:41.340 optimal. 02:41.340 --> 02:44.840 Im einen Fall ist die Privatsphäre vor dem zentralen Betreiber nicht 02:44.840 --> 02:45.740 besonders gut geschützt. 02:45.840 --> 02:48.160 Und im anderen Fall ist die Privatsphäre vor den Leuten, die ich jeden 02:48.160 --> 02:49.560 Tag treffe, nicht besonders gut geschützt. 02:49.620 --> 02:52.380 Das ist der Grund, warum wir jetzt gesagt haben, diese Diskussion ist 02:52.380 --> 02:53.040 ein bisschen müßig. 02:53.140 --> 02:54.800 Man hat so ein bisschen den Eindruck, dass es so eine Lagerbildung 02:54.800 --> 02:55.040 gibt. 02:55.120 --> 02:56.960 Die einen sagen, das ist richtig und die anderen sagen, das ist 02:56.960 --> 02:57.200 richtig. 02:57.320 --> 02:59.560 Aus unserer Sicht sind eigentlich beide Ansätze nicht ganz richtig. 02:59.680 --> 03:02.360 Und man sollte eigentlich einen gemeinsamen, sinnvollen Ansatz 03:02.360 --> 03:06.780 entwickeln, der dann sowohl die Benutzer vor potenziellen Angreifern 03:06.780 --> 03:10.080 seitens der Gesundheitsbehörden schützt, aber auch die Benutzer 03:10.080 --> 03:12.480 schützt davor, dass jetzt jeder herausbekommen kann, ob sie sich 03:12.480 --> 03:13.440 infiziert haben oder nicht. 03:13.500 --> 03:16.860 Auch eine allzu enge Zusammenarbeit mit den Herstellern der Handy 03:16.860 --> 03:21.860 -Betriebssysteme Apple und Google ist für den Experten ein Problem. 03:22.220 --> 03:25.120 Wenn ich jetzt so einen dezentralen Ansatz sehr eng integriert mit 03:25.120 --> 03:27.960 Mobiltelefonherstellern implementiere, dann hast du natürlich die 03:27.960 --> 03:29.080 ganze Dezentralität verloren. 03:29.300 --> 03:31.640 Also dann habe ich natürlich da am Ende gar nichts gewonnen, weil 03:31.640 --> 03:34.100 absehbar ist, dass Apple und Google den Benutzern dann anbieten, die 03:34.100 --> 03:35.780 ganzen Daten auch im Backup zu speichern. 03:35.780 --> 03:38.520 Und dann sammeln natürlich Apple und Google die ganzen Daten und dann 03:38.520 --> 03:40.280 haben wir also gar keine Sicherheit mehr.