Grossangelegte Cyberangriffe sind immer dort eine besondere Gefahr, wo Identitäten und Daten zentral ablegt sind; ein erfolgreicher Hack in ein System legt potenziell die persönlichen Daten aller registrierten Nutzer offen –
Bildungseinrichtungen sind hiervon nicht ausgenommen. Andererseits ist Datenschutz nur schwer umzusetzen, wenn Daten über den Planeten verstreut sind; zunehmend werden in der Hochschullehre Cloud-Dienste eingesetzt, die persönlich identifizierbare Daten von Lernenden speichern. Vor dem Hintergrund des lebenslangen Lernens ist es wohl weniger eine Frage
ob, sondern
wann über die 60 Jahre von Grundschule bis Ruhestand Daten eines Nutzers gestohlen, missbraucht oder zerstört werden. Nutzerselbstsouveränität könnte hier Abhilfe schaffen, aber dies erfordert eine grundsätzlich neue Denkweise, wie Identitäten und Datenhaltung funktionieren.
Ausbildung muss auch Jahre später noch beweisbar sein
Traditionelle Dienste basieren auf einem Client-Server-Model: Nutzer eröffnen eine Session auf einem Server unter Nutzung eines Authentifizierungsmechanismus, entweder über dienstspezifische Username-Passwort-Kombinationen (wovon wir alle mehr als genug haben!) oder über einen zentralen Identity-Provider, Stichwort: Single-Sign-on (SSO); ein Beispiel für SSO im Bildungssektor in der Schweiz ist die
Switch Edu-ID. Im Wesentlichen reden hier aber Maschinen miteinander, identifiziert über IP-Adressen. Alle Daten des Nutzers sind dabei typischerweise auf den Servern des Dienstleisters gespeichert. Zum Beispiel speichert eine Hochschule in ihrem eigenen Datenzentrum, dass ein Nutzer einen Abschluss erlangt hat. Möchte ein potenzieller Arbeitgeber oder eine andere Institution, vielleicht Jahrzehnte später, bestätigt wissen, dass ein Bewerber nicht mit gefälschten Dokumenten aufwartet, so muss bei der Hochschule nachgefragt werden – in der Hoffnung, dass diese noch existierent und ihr Datenbestand nicht kompromittiert ist. Cloud-Dienste nehmen häufig hinter den Kulissen Identitäten entgegen und schicken allfällige Ergebnisse an die Systeme der Hochschule zurück – bequem, aber gefährlich.
Anstatt mit Sessions zwischen IP-Adressen arbeitet Selbstsouveränität mit Connections zwischen selbsterzeugten
Decentralized Identifiers (DIDs). Sowohl der Nutzer als auch der Dienst erzeugen diese DIDs für sich, um sich für die Dauer der Connection auf Peer-to-Peer-Basis gegenseitig zu identifizieren, Stichwort: Self-Sovereign Identity (SSI). Das Ganze ist ähnlich wie in einem Kaffeeladen, wo man an der Theke gefragt wird, was der Name für die Bestellung ist – die meisten Kunden geben ihren Vor- oder Spitznamen an, aber man kann sich genauso gut "Mickey Mouse" nennen, solange man sich nur beim Aufruf "Venti Latte für Mickey Mouse!" daran erinnert. Eigentlich braucht man im Alltag nur in den wenigsten Fällen seinen wirklichen Namen – in SSI-Lingo wäre das eine Identity Assertion, wofür man zumeist einen Ausweis von einem Staat oder einer anderen Trusted Authority braucht; genauso in SSI. Ein Einloggen gibt es nicht mehr.
Eine Venti-Latte für Mickey Mouse
Das Datenmodel verlangt auch ein Umdenken. So würde eine Hochschule einen Abschluss nicht mehr bei sich speichern, sondern dieser würde in Form eines
Verifiable Credentials (VCs) im Daten-Wallet des Nutzers gespeichert werden. Gleichzeitig würde ein kryptografischer Fingerabdruck des VCs in einem verteilten Ledger abgelegt – dieser Ledger könnte zum Beispiel eine
Federated Blockchain sein (nicht unbedingt der energiehungrige Typ von Blockchain einer Cryptocurrency). Bestandene Prüfungen, Kurs-Credits, Zertifikate oder Hausübungspunkte würden auch
in der Form von VCs kommen, welche der Nutzer bei sich sammelt. Wenn der Nutzer dann seinen Abschluss haben will, reicht er die VCs bei seiner Hochschule im Tausch für ein Abschluss-VC ein, so wie man früher Übungsscheine gesammelt und beim Studiensekretariat eingereicht hat. Bei einer Bewerbung würde der Kandidat das Abschluss-VC einreichen. Empfänger von VCs können diese jederzeit verifizieren, in dem sie den Fingerabdruck berechnen und gegen den Ledger prüfen. Insgesamt entsteht ein
verteiltes Ökosystem mit dem Nutzer im Zentrum.
Warum ist das sicherer? Es gibt keinen zentralen Punkt, der angreifbar wäre; Nutzer haben ihre eigenen Identitäten und Daten bei sich. Komplette Kopien des Ledgers sind typischerweise weit verteilt, nicht unerkannt manipulierbar, und die Information darin ist nutzlos ausserhalb der Verifizierung von VCs. Auch DIDs sind ausserhalb einer Connection nutzlos – wer im Kaffeeladen weiss, wer "Mickey Mouse" war?
Zur Person
Gerd Kortemeyer studierte Physik an der Uni Hannover und Michigan State University. Er ist Associate Professor of Physics an der Michigan State University und Direktor der Abteilung
Lehrentwicklung und -technologie an der ETH Zürich. Sein Interessengebiet ist Technologieeinsatz in der Hochschullehre.