Abgeleitete Identitäten per eID
Martin Schröder und Frank Morgner haben einen interessanten Aufsatz zum Thema „abgeleitete Identitäten per eID“ verfasst. In diesem Aufsatz wird z. B. die aktuelle Passort-Problematik bei der Umsetzung von Authentifizierungsmechanismen sehr gut erläutert. Weiterhin wird die Grundherausforderung (Sicherheit gegenüber Usability) die bei der Umsetzung von Authentifizierungslösungen beschrieben. Darauf basierend werden mögliche Anforderungen bzw. aktuell bestehende Rahmenbedingungen für denkbare Authentifizierungslösungen beschrieben. Hierzu zählen:
- unterschiedliche Vertrauenslevels – bei einem Onlineshop-Account muss die Sicherheit nicht zwingen so hoch sein, wie bei einem Online-Banking-Account
- verschiedene Nutzungssettings – Rechner, mobiles Device, stationäre Nutzung, Touch-Screens, Tastatur, Maus, NFC, kontaktlos, kontaktbehaftet usw.
- verschiedenartige Umsetzungen bzw. Ausprägungen – der Punkte a) und b) mit diversen Authentifizierungsformen, Datenformaten usw.
Lösungsvorschlag „abgeleitete Identität“ – Sicheres Übertragen eines Attributes auf eine mobiles Device
Als Lösungsvorschlag wird angedachte eine „abgeleitete Identität“ auf ein mobiles Device, wie beispielsweise eine Smartphone zu etablieren. Wobei eigentlich nicht eine Identität abgeleitet wird. Vielmehr wird ein Attribut (z. B. aus dem Personalausweis) an bzw. in ein mobiles Gerät mit Secure Element übertragen. Dabei wird die Attributquelle nur für das Übertragen des Attributes aus der Attributquelle in das mobile Device benötigt. Die spätere Nutzung des Attributes kann direkt aus dem mobilen Device geschehen z. B. unter Nutzung einer PIN zur Freigabe des Attributes. Das genaue Vorgehen in Bezug auf die Attributquelle Personalausweis wird in dem besagten Artikel beschrieben.
Kritik am Lösungsansatzes des Aufsatz „Abgeleitete Identitäten per eID“
Diese Umsetzung stellt sicher aktuelle eine sehr interessante Variante dar, die Herausforderung Sicherheit vs. Usability zu lösen. Auf längere Frist gesehen, könnte sich dieses Umsetzungskonzept (Hinterlegen eines Attributes aus einer Attributquelle in ein anderes Gerät) allerdings nicht durchsetzen. Hintergrund dieser Überlegung ist der Fakt, das Nutzer immer weniger über ihre „Geräte“ wie Rechner, Smartphone, Tablet-PC usw. sowie deren Betriebssysteme bzw. lokalen Anwendungen wissen. Nutzer wissen nicht, was das Gerät bzw. die Software macht. Sie wissen somit auch nicht, was mit den Daten (Attributen) auf diesen Geräten geschieht. Sie können es nicht sehen, anfassen bzw. allg. nachvollziehen, die meisten Nutzer werden blind vertrauen müssen.
Folgend wird der Otto-Normalnutzer dazu geneigt sein, sich erst dann sicher zu füllen, wenn das entsprechende Gerät ausgeschalten ist (idealerweise wurde auch die Batterie entnommen). Ähnlich dem Prinzip seinen Rechner vor Angriffen aus dem Internet zu schützen, in dem der Rechner nicht ans Netz angeschlossen wird.
Attributquelle müssen für den Nutzer selbstbestimmt und aktiv handelbar sein
Das bedeutet Nutzer werden sich nur sicher füllen, wenn sie die Attributquelle selbstbestimmt und aktiv entnehmen können, um damit zu verhindern, dass das Gerät bzw. Software von einem Dritten gesteuert und das hinterlegte Attributquelle ausgelesen wird. Damit ist es leider notwendig immer die Attributquelle für die Nutzung bereitzuhalten aber es besteht dadurch auch die Möglichkeit die Attributquelle zu entnehmen, wodurch der Nutzer das Gefühl hat, sich aktiv zu schützen. So ist das auch aktuell bei der Nutzung von Schlüsseln. Nutzer sind nur sicher wenn die Tür mit einem Schlüssel verschlossen haben, der dann den ganzen Tag bei ihnen ist, allerdings für den Preis das der Schlüssel immer zum Aufschließen der Tür vorgehalten werden muss.
