diff options
| -rw-r--r-- | updates/2020/contact-tracing-requirements.md | 212 |
1 files changed, 212 insertions, 0 deletions
diff --git a/updates/2020/contact-tracing-requirements.md b/updates/2020/contact-tracing-requirements.md new file mode 100644 index 00000000..3fc6234a --- /dev/null +++ b/updates/2020/contact-tracing-requirements.md | |||
| @@ -0,0 +1,212 @@ | |||
| 1 | title: 10 Prüfsteine für die Beurteilung von "Contact Tracing"-Apps | ||
| 2 | date: 2020-04-06 15:19:28 | ||
| 3 | updated: 2020-04-06 15:19:28 | ||
| 4 | author: linus | ||
| 5 | tags: pressemitteilung, updates | ||
| 6 | |||
| 7 | Als Möglichkeit zur Eindämmung der SARS-CoV-2-Epidemie sind "Corona-Apps" in aller Munde. Der CCC veröffentlicht 10 Prüfsteine zu deren Beurteilung aus technischer und gesellschaftlicher Perspektive. | ||
| 8 | |||
| 9 | <!-- TEASER_END --> | ||
| 10 | |||
| 11 | Politik und Epidemiologie ziehen aktuell gestütztes "Contact Tracing" | ||
| 12 | als Maßnahme in Erwägung, systematisch einer Ausbreitung von | ||
| 13 | SARS-Cov-2-Infektionen entgegen zu wirken. Dies soll der Gesellschaft | ||
| 14 | eine größere Freizügigkeit zurückgeben, indem Infektionsketten schneller | ||
| 15 | zurückverfolgt und unterbrochen werden können. Durch eine solche Lösung | ||
| 16 | sollen Kontakte von Infizierten schneller alarmiert werden und sich | ||
| 17 | dadurch schneller in Quarantäne begeben können. Dadurch wiederum sollen | ||
| 18 | weitere Infektionen ihrerseits verhindert werden. Eine "Corona-App" soll | ||
| 19 | also weder uns selbst, noch unsere Kontakte schützen: Sie soll | ||
| 20 | Infektionsketten unterbrechen, indem die Kontakte unserer Kontakte | ||
| 21 | geschützt werden. | ||
| 22 | |||
| 23 | ## "Contact Tracing" als Risikotechnologie | ||
| 24 | |||
| 25 | Für die technische Implementierung dieses Konzepts gibt es eine Reihe an | ||
| 26 | Vorschlägen. Diese Empfehlungen reichen von dystopischen Vorschlägen für | ||
| 27 | Vollüberwachung bis hin zu zielgenauen, vollständig anonymisierten | ||
| 28 | Methoden der Alarmierung von potentiell Infizierten ohne Kenntnis der | ||
| 29 | konkreten Person. | ||
| 30 | |||
| 31 | Grundsätzlich wohnt dem Konzept einer "Corona App" aufgrund der | ||
| 32 | möglicherweise erfassten Kontakt- und Gesundheitsdaten ein enormes | ||
| 33 | Risiko inne. Gleichzeitig gibt es breite Anwendungsmöglichkeiten für | ||
| 34 | "Privacy-by-Design"-Konzepte und -Technologien, die in den letzten | ||
| 35 | Jahrzehnten von der Crypto- und Privacy-Community entwickelt wurden. Mit | ||
| 36 | Hilfe dieser Technologien ist es möglich, die Potenziale des "Contact | ||
| 37 | Tracing" zu entfalten, ohne eine Privatsphäre-Katastrophe zu schaffen. | ||
| 38 | Allein deshalb sind sämtliche Konzepte strikt abzulehnen, die die | ||
| 39 | Privatsphäre verletzen oder auch nur gefährden. Die auch bei | ||
| 40 | konzeptionell und technisch sinnvollen Konzepten verbleibenden | ||
| 41 | Restrisiken müssen fortlaufend beobachtet, offen debattiert und so weit | ||
| 42 | wie möglich minimiert werden. | ||
| 43 | |||
| 44 | Im Folgenden skizzieren wir gesellschaftliche und technische | ||
| 45 | Minimalanforderungen für die Wahrung der Privatsphäre bei der | ||
| 46 | Implementierung derartiger Technologien. Der CCC sieht sich in dieser | ||
| 47 | Debatte in beratender und kontrollierender Rolle. Wir werden aus | ||
| 48 | grundsätzlichen Erwägungen keine konkreten Apps, Konzepte oder Verfahren | ||
| 49 | *empfehlen*. Wir raten jedoch von Apps *ab*, die diese Anforderungen | ||
| 50 | nicht erfüllen. | ||
| 51 | |||
| 52 | ## I. Gesellschaftliche Anforderungen | ||
| 53 | |||
| 54 | ### 1. Epidemiologischer Sinn & Zweckgebundenheit | ||
| 55 | |||
| 56 | Grundvoraussetzung ist, dass "Contact Tracing" tatsächlich realistisch | ||
| 57 | dabei helfen kann, die Infektionszahlen signifikant und nachweisbar zu | ||
| 58 | senken. Diese Beurteilung obliegt der Epidemiologie. Sollte sich | ||
| 59 | herausstellen, dass "Contact Tracing" per App nicht sinnvoll und | ||
| 60 | zielführend ist, muss das Experiment beendet werden. | ||
| 61 | |||
| 62 | Die App selbst und jegliche gesammelten Daten dürfen ausschließlich zur | ||
| 63 | Bekämpfung von SARS-Cov-2-Infektionsketten genutzt werden. Jede andere | ||
| 64 | Nutzung muss technisch so weit wie möglich verhindert und rechtlich | ||
| 65 | unterbunden werden. | ||
| 66 | |||
| 67 | ### 2. Freiwilligkeit & Diskriminierungsfreiheit | ||
| 68 | |||
| 69 | Für eine epidemiologisch signifikante Wirksamkeit setzt eine "Contact | ||
| 70 | Tracing"-App einen hohen Verbreitungsgrad in der Gesellschaft voraus – | ||
| 71 | also Installationen auf den Smartphones möglichst vieler Menschen. Diese | ||
| 72 | weite Verbreitung darf nicht durch Zwang erreicht werden, sondern kann | ||
| 73 | nur durch ein vertrauenswürdiges, privatsphären-achtendes System erzielt | ||
| 74 | werden. Vor diesem Hintergrund verbietet sich das Erheben von Gebühren | ||
| 75 | für die Nutzung ebenso wie die Inzentivierung durch finanzielle Anreize. | ||
| 76 | |||
| 77 | Menschen, die sich der Nutzung verweigern, dürfen keine negativen | ||
| 78 | Konsequenzen erfahren. Dies sicherzustellen, ist auch eine Aufgabe von | ||
| 79 | Politik und Gesetzgebung. | ||
| 80 | |||
| 81 | Die App muss von sich aus regelmäßig auf ihren Betrieb hinweisen, | ||
| 82 | einfach temporär zu deaktivieren und dauerhaft zu de-installieren sein. | ||
| 83 | Die Implementierung restriktiver Maßnahmen, bspw. die Funktion | ||
| 84 | "elektronischer Fußfesseln" zur Kontrolle von Ausgangs- und | ||
| 85 | Kontaktbeschränkungen, halten wir für inakzeptabel. | ||
| 86 | |||
| 87 | ### 3. Grundlegende Privatsphäre | ||
| 88 | |||
| 89 | Nur mit einem überzeugenden Konzept, das auf dem Grundsatz der Wahrung | ||
| 90 | der Privatsphäre beruht, kann überhaupt eine gesellschaftliche Akzeptanz | ||
| 91 | erreicht werden. | ||
| 92 | |||
| 93 | Dabei sollen belegbare technische Maßnahmen wie Kryptografie und | ||
| 94 | Anonymisierung die Privatsphäre der Nutzer zwingend sicherstellen. Es | ||
| 95 | reicht nicht, sich auf organisatorische Maßnahmen, Versprechen und | ||
| 96 | "Vertrauen" zu verlassen. Organisatorische oder rechtliche Hürden gegen | ||
| 97 | einen Datenabfluss sind im derzeitigen gesellschaftlichen Klima von | ||
| 98 | Notstands-Denken und möglichen weitgehenden Grundrechtsausnahmen durch | ||
| 99 | das Infektionsschutzgesetz nicht hinreichend. | ||
| 100 | |||
| 101 | Die Beteiligung von Unternehmen, die Überwachungstechnologien | ||
| 102 | entwickeln, lehnen wir als "Covid-Washing" grundsätzlich ab. | ||
| 103 | Grundsätzlich gilt: Die Nutzerinnen sollten keiner Person oder | ||
| 104 | Institution mit Ihren Daten "vertrauen" müssen, sondern dokumentierte | ||
| 105 | und geprüfte technische Sicherheit genießen. | ||
| 106 | |||
| 107 | ### 4. Transparenz und Prüfbarkeit | ||
| 108 | |||
| 109 | Der vollständige Quelltext für App und Infrastruktur muss frei und ohne | ||
| 110 | Zugangsbeschränkungen verfügbar sein, um Audits durch alle | ||
| 111 | Interessierten zu ermöglichen. Durch Reproducible-Build-Techniken ist | ||
| 112 | sicherzustellen, dass Nutzer überprüfen können, dass die App, die sie | ||
| 113 | herunterladen aus dem auditierten Quelltext gebaut wurde. | ||
| 114 | |||
| 115 | ## II. Technische Anforderungen | ||
| 116 | |||
| 117 | ### 5. Keine zentrale Entität, der vertraut werden muss | ||
| 118 | |||
| 119 | Ein vollständig anonymes "Contact Tracing" ohne allwissende zentrale | ||
| 120 | Server ist technisch möglich. Es ist technisch nicht notwendig, alleine | ||
| 121 | auf Vertrauenswürdigkeit und Kompetenz des Betreibers von zentraler | ||
| 122 | Infrastruktur zu vertrauen, die Privatsphäre der Nutzer schon | ||
| 123 | ausreichend zu schützen. Darauf beruhende Konzepte lehnen wir daher von | ||
| 124 | vornherein als fragwürdig ab. | ||
| 125 | |||
| 126 | Hinzu kommt, dass die Sicherheit und Vertrauenswürdigkeit | ||
| 127 | zentralisierter Systeme – etwa gegen die Verknüpfung von IP-Adressen mit | ||
| 128 | anonymen Nutzer-IDs – für die Anwender nicht effektiv überprüfbar ist. | ||
| 129 | Die Sicherheit und Vertraulichkeit des Verfahrens muss daher | ||
| 130 | ausschließlich durch das Verschlüsselungs- und Anonymisierungskonzept | ||
| 131 | und die Verifizierbarkeit des Quellcode gewährleistet werden können. | ||
| 132 | |||
| 133 | ### 6. Datensparsamkeit | ||
| 134 | |||
| 135 | Es dürfen nur minimale und für den Anwendungszweck notwendige Daten und | ||
| 136 | Metadaten gespeichert werden. Diese Anforderung verbietet die Erfassung | ||
| 137 | sämtlicher Daten, die über einen Kontakt zwischen Menschen und dessen | ||
| 138 | Dauer hinausgehen, wie zum Beispiel Lokationsdaten. | ||
| 139 | |||
| 140 | Sofern lokal auf den Telefonen Daten wie Aufenthaltsorte erfasst werden, | ||
| 141 | dürfen Nutzerinnen nicht gezwungen oder verleitet werden, diese Daten an | ||
| 142 | Dritte weiterzugeben oder gar zu veröffentlichen. Daten, die nicht mehr | ||
| 143 | benötigt werden, sind zu löschen. Auch lokal auf dem Telefon müssen | ||
| 144 | sensible Daten sicher verschlüsselt werden. | ||
| 145 | |||
| 146 | Für freiwillige, über den eigentlichen Zweck des Contact Tracing | ||
| 147 | hinausgehende Datenerhebungen zum Zweck der epidemiologischen Forschung | ||
| 148 | muss in der Oberfläche der App eine klare, separate Einwilligung | ||
| 149 | explizitit eingeholt und jederzeit widerrufen werden können. Diese | ||
| 150 | Einwilligung darf nicht Voraussetzung für die Nutzung sein. | ||
| 151 | |||
| 152 | ### 7. Anonymität | ||
| 153 | |||
| 154 | Die Daten, die jedes Gerät über andere Geräte sammelt, dürfen zur | ||
| 155 | Deanonymisierung ihrer Nutzer nicht geeignet sein. Die Daten, die jede | ||
| 156 | Person ggf. über sich weitergibt, dürfen nicht zur Deanonymisierung der | ||
| 157 | Person selbst geeignet sein. Daher muss die Nutzung des Systems möglich | ||
| 158 | sein, ohne dass persönliche Daten jedweder Art erfasst werden oder | ||
| 159 | abgeleitet werden können. Diese Anforderung verbietet eindeutige | ||
| 160 | Nutzerkennungen. | ||
| 161 | |||
| 162 | IDs für "Contact Tracing" über Drahtlostechnik (z. B. Bluetooth oder | ||
| 163 | Ultraschall) dürfen nicht auf Personen zurückführbar sein und müssen | ||
| 164 | häufig wechseln. Aus diesem Grund verbietet sich auch eine Verbindung | ||
| 165 | mit oder Ableitung von IDs aus Kommunikationsbegleitdaten wie | ||
| 166 | Push-Tokens, Telefonnummern, verwendeten IP-Adressen, Gerätekennungen | ||
| 167 | etc. | ||
| 168 | |||
| 169 | ### 8. Kein Aufbau von zentralen Bewegungs- und Kontaktprofilen | ||
| 170 | |||
| 171 | Das System muss so beschaffen sein, dass weder absichtlich noch | ||
| 172 | unabsichtlich Bewegungsprofile (Standortverfolgung) oder Kontakt-Profile | ||
| 173 | (auf konkrete Menschen zurückführbare Muster von häufigen Kontakten) | ||
| 174 | aufgebaut werden können. Methoden wie zentrales GPS/Location-Logging | ||
| 175 | oder eine Verknüpfung der Daten mit Telefonnummern, | ||
| 176 | Social-Media-Accounts u. ä. sind daher grundsätzlich abzulehnen. | ||
| 177 | |||
| 178 | ### 9. Unverkettbarkeit | ||
| 179 | |||
| 180 | Das Design der ID-Generierung muss so gestaltet sein, dass diese ohne | ||
| 181 | den Besitz des privaten Schlüssels nicht verkettbar sind. Sie dürfen | ||
| 182 | also nicht aus anderweitigen Daten abgeleitet werden. Egal auf welchem | ||
| 183 | Weg IDs im Infektionsfall kommuniziert werden, muss ausgeschlossen sein, | ||
| 184 | dass die gesammelten "Contact Tracing"-Daten über längere Zeiträume | ||
| 185 | verketten werden können. | ||
| 186 | |||
| 187 | ### 10. Unbeobachtbarkeit der Kommunikation | ||
| 188 | |||
| 189 | Auch wenn die Übermittlung einer Nachricht im System beobachtet wird (z. | ||
| 190 | B. über die Metadaten der Kommunikation), darf daraus nicht geschlossen | ||
| 191 | werden können, dass eine Person selbst infiziert ist oder Kontakt zu | ||
| 192 | Infizierten hatte. Dies ist sowohl gegenüber anderen Nutzern als auch | ||
| 193 | gegenüber Infrastruktur- und Netzbetreibern oder Angreifern, die | ||
| 194 | Einblick in diese Systeme erlangen, sicherzustellen. | ||
| 195 | |||
| 196 | ## Rolle und Selbstverständnis des CCC | ||
| 197 | |||
| 198 | Seit weit über 30 Jahren engagiert sich der CCC ehrenamtlich im | ||
| 199 | Spannungsfeld zwischen Technologie und Gesellschaft. [Unsere ethischen | ||
| 200 | Prinzipien](/de/hackerethik) stehen für Privatsphäre, Dezentralisierung | ||
| 201 | und Datensparsamkeit – und gegen jede Form von Überwachung und Zwang. | ||
| 202 | |||
| 203 | Ohne Anspruch auf Vollständigkeit benennen wir in diesem Beitrag | ||
| 204 | Mindestanforderungen, denen eine "Corona App" entsprechen muss, um | ||
| 205 | gesellschaftlich und technisch überhaupt tolerabel zu sein. Der CCC wird | ||
| 206 | aus grundsätzlichen Erwägungen unter keinen Umständen jemals eine | ||
| 207 | konkrete Implementierung mit Zustimmung, Empfehlung oder gar einem | ||
| 208 | Zertifikat oder Prüfsiegel versehen. | ||
| 209 | |||
| 210 | Es obliegt den Entwicklern von "Contact Tracing"-Systemen, die Erfüllung | ||
| 211 | dieser Anforderungen zu belegen, oder von unabhängigen Dritten belegen | ||
| 212 | zu lassen. | ||
