UBAuth

Benutzerfreundlich und dennoch sicher

Patrick Amrein Patrick Amrein    Datum 15.03.2021
UBAuth

Ausgangslage

Mittlerweile sind Online-Dienste kaum noch wegzudenken. Wer keine Webpräsenz hat, unterliegt der Gefahr, nicht wahrgenommen zu werden. Doch Präsenz allein ist nicht alles. Den BenutzernInnen möglichst viel und für sie Wertvolles bieten zu können, steht auch ganz oben auf der Liste. Entsprechend umfangreich sind z.B. die Angebote der Stadt Zürich. Zudem soll das Angebot auch benutzerfreundlich sein, damit das grösstmögliche Publikum erreicht werden kann. Früher war das Bestellen einer Tagesparkkarte relativ aufwändig: Entweder musste man diese brieflich bestellen oder persönlich beim Einwohneramt vorbeigehen. Heutzutage können viele derartige Tätigkeiten ganz einfach online erledigt werden. Dies kommt nicht nur den BenutzernInnen, sondern auch den DienstleisterInnen zugute. Sie gewinnen Zeit und Arbeitskraft, die in die Abwicklung ihrer Kernprozesse gesteckt werden können. Der Schutz und die Sicherheit dieser Art von Diensten ist jedoch von höchster Wichtigkeit - wichtiger als ihre Benutzerfreundlichkeit. Es wäre fatal, wenn mich beispielsweise jemand anderes per "e-Umzug" in einen anderen Stadtteil Zürichs umziehen lassen könnte.
Entsprechend gross ist der Widerstand, sämtliche staatlichen Dienste online verfügbar zu machen. Dies zeigt auch die Debatte zum Online-Voting. Hier dreht sich alles um den "User-Trust" - und um die Sicherheit der Verbindung. Kann sichergestellt werden, dass die Stimme tatsächlich von der Person stammt, die sich dem System präsentiert?

Anmeldung

Dieses Problem beginnt bereits bei der Registrierung. Wie kann man eine vertrauliche, beglaubigte Verbindung via Internet aufbauen, ohne dass man weiss, wer diese aufbauen will? Beim Online-Banking wird oft der postale Weg als vertraulich-beglaubigte Verbindung angesehen. Das ist aber nur die erste Hürde. Benötigt das Login nur E-Mail-Adresse und Passwort - bei vielen Diensten immer noch der Standard - ist die Identität der Person noch nicht zweifelsfrei sichergestellt. Eine E-Mail-Adresse ist öffentlich und lässt sich unter Umständen einfach herausfinden. Verwendet die Person keinen Passwortmanager, wählt sie meist merkbare und somit leicht erratbare Passwörter. Viele NutzerInnen wählen dasselbe oder leicht abgewandelte Passwörter für alle möglichen, mehr oder weniger vertrauenswürdigen Dienste. Dies erhöht die Gefahr, dass das Passwort nicht nur erraten, sondern sogar im Internet auf sogenannten Passwortlisten auftaucht haveibeenpwned.com. Sobald ein AngreiferIn die E-Mail-Adresse und das Passwort einer Person kennt, kann er oder sie sich gegenüber dem entsprechenden Dienst als diese Person ausgeben. Selbst zuvor beglaubigte Zugangsdaten können hier nur wenig helfen. Via SMS übertragene Einmalpasswörter ("SMS-TAN") sind nur geringfügig sicherer. Mit etwas Geschick gelingt es einem/einer AngreiferIn, beim/bei der TelefonanbieterIn des Opfers einen Klon seiner SIM-Karte zu beantragen, mit dem er diese Codes auch empfängt. Ist es überhaupt möglich, einen sicheren Zugang zu Online-Diensten anzubieten? Ist die einzige Lösung, solche kritischen Systeme einfach nicht via Internet anzubieten? Doch, es ist machbar! Wir stellen hier UB-Auth als mögliche Lösung für zumindest einen Teil dieser Probleme vor. Bevor wir UB-Auth genauer betrachten, liefern wir einige technische Hintergrundinformationen.

Mehr Informationen zum World Wide Web Consortium

Übersicht verschiedener Lösungsmöglichkeiten

Es gibt eine Reihe von sicheren, hardware-basierten Alternativen zum Passwort. Sie alle beruhen auf dem Prinzip der Multi-Faktor-Authentisierung. Ein Login und damit eine Identifikation erfolgt also nur bei erfolgreicher Überprüfung mehrerer Faktoren. Meistens handelt es sich um zwei Faktoren, von denen einer hardware-basiert ist. In diesem Fall sprechen wir von Zwei-Faktor-Authentisierung (kurz: “2FA“).

Üblich sind folgende Faktoren:

  • Wissen - etwas, das (nur) der Benutzer weiss, wie ein Passwort
  • Besitz - etwas, das der Benutzer besitzt, sprich Hardware
  • Biometrisch - ein körperliches Merkmal des Benutzers
  • Standort - ein wahrscheinlicher Standort des Benutzers, wie bei der Überprüfung einer Kreditkarten-Transaktion Diese Teile einer Multi-Faktor-Lösung unterscheiden sich in ihrer Sicherheit, Benutzerfreundlichkeit und Anschaffungskosten. Jeder dieser Aspekte ist für den Benutzer und den Anbieter wichtig. Eine optimale Lösung bietet hohe Sicherheit, ist einfach zu bedienen und kostengünstig. Im Folgenden gehen wir auf einige Besitz-Faktoren ein.

SmartCards

Schon länger auf dem Markt sind sogenannte SmartCards. Diese Karten besitzen wie SIM-Karten einen eigenen Mikroprozessor, der abgekoppelt von anderen Systemen bestimmte Funktionen anbietet. Dies kann beispielsweise eine digitale Signatur oder ein Baustein eines sicheren Login-Prozesses sein. Ein möglicher Angreifer muss also physischen Zugriff auf diese SmartCard erhalten. Als zusätzliche Sicherheitsmassnahme können die Karten mit PIN-Codes geschützt werden Oftmals sind diese Karten auch vor Bruteforce-Angriffen, also solchen, bei denen alle möglichen Eingaben des Benutzers durchprobiert werden, geschützt. SIM-Karten sperren sich beispielsweise selbst nach mehreren falsch eingegebenen PIN-Codes.

Security Hardware-Token

Eine modernere Art der SmartCard sind sogenannte (Security) Hardware-Token. Während SmartCards ein spezielles Lesegerät brauchen (was die Sicherheit erhöhen kann, aber die Nutzerfreundlichkeit verringert), können Hardware-Token in der Regel via USB an ein Computer-System angeschlossen werden. Das Prinzip ist dasselbe: es werden Funktionen angeboten, die z.B. Signaturen erstellen. Dedizierte Besitz-Faktoren wie Smartcards und Hardware-Token müssen vom Benutzer mitgeführt werden. Das ist aus Sicherheitsperspektive ein Vorteil, für Benutzerfreundlichkeit aber ein Nachteil. Ist der Transport des Faktors aufwändig oder wird er selten genutzt, besteht das Risiko, dass der Faktor verloren geht oder vergessen wird.

Smartphone

Das Smartphone ist bezüglich Kosten und Wahrscheinlichkeit des Verlustes ein Sonderfall: Fast jeder Mensch trägt es mit sich herum und bemerkt den Verlust entsprechend schnell. Im Gegensatz zu dedizierten Faktoren wie Hardware-Tokens, gibt es beim Smartphone keine Trennung von Authentisierung und Applikation/Service. Gleichzeitig läuft auf einem Mobiltelefon Programmcode von Drittanbietern mit unklarer Vertrauenswürdigkeit. Das Betriebssystem versucht natürlich, diese Prozesse stets voneinander getrennt und abgekapselt laufen zu lassen. Darum laufen Apps auf nicht modifizierten Systemen stets in sogenannten Sandboxes. Eine Sandbox umfasst in der Regel eine Sammlung von Regeln, die das System durchzusetzen versucht. Dies gelingt mehr oder weniger, wie verschiedenste sogenannte Zero-Day-Exploits in der Vergangenheit gezeigt haben (https://www.kaspersky.de/resource-center/definitions/zero-day-exploit, https://www.zdnet.com/article/apple-fixes-three-ios-zero-days-exploited-in-the-wild/, https://www.zdnet.com/article/after-two-zero-days-in-chrome-desktop-google-patches-a-third-zero-day-in-the-android-version/). Dazu kommt, dass Applikationen oftmals auch externe Eingaben erlauben. Diese Daten stammen in der Regel von Quellen, die nicht unbedingt vertrauenswürdig sind. Typisch ist hier der Phishing-Versuch via E-Mail. Dies erschwert die automatische Verarbeitung solcher Eingaben. Die Hersteller kennen dieses Problem. Sie lösen es meistens nach dem Multi-Faktor-Prinzip: ein zusätzliches Hardware-Element schützt vor unbefugtem Zugriff, indem es nur bestimmte Aktionen zulässt. Oft handelt es sich um einen zusätzlichen Mikroprozessor, der getrennt vom Rest der Hardware operiert. Auf der Apple-Plattform nennt sich dies Secure-Enclave und ist in Form eines zusätzlichen, sicheren Prozessors bei allen Geräten eingebaut, die biometrische Authentisierung anbieten. Auf der Android-Plattform wird dies durch Trusted Execution Environments (TEE) auf Basis von TrustZone oder dedizierten Security-Chips (Titan) zur Verfügung gestellt. Solche Sicherheits-Hardware bietet eine deutlich höhere Sicherheit als sie das Betriebssystem anbieten kann, sind jedoch nicht über jeden Zweifel erhaben. Bekannte Sicherheitslücken sind beispielsweise Meltdown oder "Spectre", welche vor drei Jahren entdeckt und publiziert wurden. Dennoch bieten die "Trustzones" grosser Anbieter eine gute Sicherheit.

Biometrische Faktoren als Standard

Somit bieten moderne Mobiltelefone ein Mass an Sicherheit auf dem Niveau einer SmartCard. Insbesondere unterstützt solche Hardware, im Gegensatz zu vielen SmartCards, in der Regel auch die biometrische Authentisierung, was die Sicherheit erhöht. Verbreitete biometrische Faktoren sind Fingerabdruck-Scanner oder Gesichtserkennung. Ein praktischer Vorteil eines biometrischen Faktors ist, dass er in der Regel schnell und zuverlässig funktioniert. Der Benutzer muss keinen Geheimcode eingegeben, den er vergessen könnte. Zudem ist es für einen Angreifer schwierig, einen biometrischer Faktor kopieren oder stehlen. Gegenüber SmartCards bietet ein Smartphone nicht nur hohe Sicherheit, sondern durch seine Allgegenwärtigkeit eine hohe Benutzerfreundlichkeit. Deshalb verwenden wir es als Teil der UB-Auth-Plattform. Eine Lösung, die verschiedene Standards miteinander verknüpft, um eine möglichst einfache und sichere Lösung für Login-Verfahren anzubieten, die auch mit Apps funktioniert.

Architektur von UB-Auth

Einleitung

Wir haben entschieden, das UB-Auth-System in verschiedene einzelne Bauteile zu spalten. Jeder dieser Bauteile erfüllt einzeln einen Auftrag und implementiert den Standard, der für die jeweillige Aufgabe am besten geeignet ist. Eine wesentliche Unterteilung ist zum Beispiel in Authentifizierung und Authentisierung.

Authentifizierung: Bestätigen einer vorgelegten (authentisierten) Information (Server → Server)

Authentisierung: Beweisen der Information z.B. Identität (Person → Server)

OpenID-Connect

Für die Authentifizierung wird das OpenID Connect Protokoll verwendet. Die authentifizierende OpenID Connect Komponente liegt separiert von der authentisierenden Komponente vor. Das OpenID Connect-Protokoll ist ein vom W3C finalisiertes Authentifizierungs-Protokoll. Es definiert, wie eine fremde Instanz, z.B. ein Webshop, die Authentisierung eines Benutzer anfordern kann. Trotz der relativen kurzen Existenz dieses Standards hat er sich im Consumer Market bereits klar durchgesetzt und immer mehr Firmen steigen ebenfalls um. Dadurch wird das einfache Anbinden der UB-Auth-Komponente an nahezu sämtliche Login-Systeme ermöglicht. Das Protokoll beschreibt, wie ein externer Client bei einem sogenannten “Identity-Provider (IdP)” die Identität von einem Benutzer authentifizieren lassen kann. Das Protokoll gibt dabei bewusst nicht vor, wie die entsprechende Authentisierung stattfinden soll. Dadurch ist es einfach, eine neue Authentisierungsmethode in bestehende OpenID-Connect Flows zu integrieren. Es können dabei auch mehrere Authentisierungsschritte hintereinander geschaltet werden – z.B. Passwort + mTAN. Es ist sogar möglich, verschiedene solche OpenID Connect Server hintereinander zu schalten, um die Authentifizierung weiter zu delegieren. Da das Protokoll ausschliesslich die Kommunikation zwischen Client und Server beschreibt, die Hintergründe auf Seiten des IdP jedoch als Blackbox behandelt, kann ein neuer OpenID Connect Provider in der Regel einfach in bestehende Login-Systeme integriert werden. Der grosse Vorteil dieser Abstraktion liegt darin, dass ein Dienst, dessen Hauptaugenmerk nicht auf einer Benutzerverwaltung liegt, fehlerhafte Implementierungen eines Login-Systems vermeiden kann, da diese extern zur Verfügung gestellt werden. Insbesondere trägt dieser Dienst keine Verantwortung für eine User/Passwort-Datenbank, die potenziell gehacked werden kann. Ein Vorteil von OpenID Connect gegenüber SAML – dem bis anhin Industriestandard – ist, dass OpenID Connect im Hinblick auf die Nutzung mit mobilen Plattformen konzipiert wurde. Die Integration von Login-Systemen auf mobilen Endgeräten wird durch entsprechende Flows vereinfacht (Saml vs OpenID Connect). Ein weiterer Vorteil ist, dass OpenID Connect in der Regel JSON als Format benutzt und zugehörige JSON WebTokens (JWT) resp. JSON WebSignatures (JWS) verwendet. JSON als Format ist einfacher zu verarbeiten, als das von SAML verwendete XML-Format. Trotz gewissen Pitfalls im Standard (der berühmte “alg = none” Fehler), sind diese einfacher zu finden als Fehler in XML-Parsern, da das XMLDSIG Format deutlich komplexer ist (Golang XML Parser and its impact on SAML).

FIDO2

Die Authentisierungs-Komponente benutzt FIDO2 um den Benutzer zu authentisieren. Sie baut auf dem WebAuthn-Server von Yubico auf (Yubico/java-webauthn-server). Der WebAuthn-Server wurde für UB-Auth in eine Spring-Boot-Applikation integriert und stellt den mobilen Applikationen eine REST-API zur Verfügung. FIDO2 ist ein Standard zur sicheren Authentisierung im Browser. Der Standard wurde durch Yubico und dem W3C entwickelt und ist mittlerweile auf vielen Browsern verfügbar. Dank der Nutzung von asymmetrischen Kryptografieverfahren wird während eines Login-Prozesses kein Passwort versendet. Durch den Einsatz von sich ändernden Daten sind Password-Phishing-Versuche erfolglos. Dies bedeutet, dass selbst wenn ein/eine AngreiferIn die Verbindung abhören kann, er oder sie nicht an den Schlüssel für diesen/diese BenutzerIn kommt. Theoretisch kann der/die AngreiferIn immer noch die Antwort abfangen und diese benutzen um Zugriff zu bekommen. Dies ist allerdings nur einmalig möglich, denn sobald die dazugehörige Sitzung terminiert wird, kann ein/eine AngreiferIn die abgefangene Antwort nicht mehr benutzen. Hinweise über verdächtige Aktivitäten sind deshalb mittlerweile auch der Standard bei grossen Anbietern, und versuchen z.B. anhand des Standortes der Internet-Adresse (IP) solche zu erkennen. Allerdings kann auch mit FIDO2 das Problem der beglaubigten Registrierung nicht gelöst werden. Der initiale Austausch muss in jedem Fall über eine alternative, vertrauenswürdige Verbindung statt finden. Denn obwohl der Schlüssel nie das Gerät verlässt, ist initial nicht bekannt, ob das Gerät tatsächlich von der erwarteten Person benutzt wird. Sobald die Registrierung beglaubigt werden kann gilt die Verbindung als vertrauenswürdig. Das oben erwähnte Problem des Abfangens des Netzwerkverkehrs kann mittlerweile relativ gut kontrolliert werden. Durch Technologien wie HTTPS und zusätzlichem Zertifikat-Pinning ist es für einen Angreifer ohne physischen Zugriff auf die Infrastruktur der Zielperson nahezu unmöglich, ihren Internet-Verkehr abzufangen.

Wir blenden das Registrierungsverfahren erstmal aus, und betrachten den Login-Ablauf etwas genauer:
Login-Ablauf

Will sich ein Benutzer bei einer Seite einloggen, so schickt er eine Anfrage an den Server, dass er sich gerne einloggen würde: Er geht beispielsweise auf die Login-Seite. Die Antwort des Servers beinhaltet Informationen über sich, sowie kryptografisch sichere, zufällige Daten. Diese Antwort wird auf dem Client des Nutzers verarbeitet, mit dem Private-Key signiert und wieder zurück an den Server geschickt. Der benutzte Private-Key ist teil eines Paares, welches von dem Server beglaubigt wurde. Der Server kann nun mit dem bei der Registrierung erhaltenen Public-Key die Signatur überprüfen. Falls User-Id und Public-Key stimmen, antwortet er mit der Bestätigung und kann gegebenenfalls eine authentisierte Sitzung starten. Im Falle von UB-Auth wird der Login-Versuch gestartet, sobald ein Benutzer auf die Login-Seite kommt. Der Server (IdP) schickt dabei die Daten nicht direkt an den Browser, sondern bewahrt sie auf und vergleicht sie mit allen registrierten Mobilen-Geräten des entsprechenden Benutzers. Auf dem mobilen Gerät werden nun die relevanten Daten abgeholt und signiert. Wenn das das Resultat positiv ausfällt, so wird dies der Login-Seite gemeldet und diese kann gemäss dem OpenID-Connect-Protokoll den Nutzer wieder zurück zum ursprünglichen Dienst leiten, wo dann eine Sitzung erstellt wird.

Verschlüsselungsverfahren

Um die Vorteile des FIDO2-Ansatzes zu verstehen, erläutern wir kurz verschiedene Begriffe aus der Kryptografie.

Hashing

Eine Hashing-Funktion bildet eine Domäne auf ein Bild ab. Die Operation nimmt beliebige Werte aus der Domäne und bildet sie auf fixe Grössen ab. Eine Hashing-Funktion sollte jeden Hash mit einer ungefähr gleichen Wahrscheinlichkeit generieren. Ebenfalls ist es für die Kryptografie von Interesse, dass ähnliche Elemente aus der Domäne nicht (zwingend) auf ähnliche Hashes abgebildet werden. Eine Hashing-Funktion muss immer deterministisch sein, was bedeutet, dass die gleiche Eingabe stets das gleiche Resultat zur Folge hat. Diese Eigenschaften machen Hashes interessant für die Speicherung von Passwörtern. Da nicht das eigentliche Passwort gespeichert wird, werden bei einem möglichen Diebstahl der Daten nicht direkt die Passwörter sondern nur deren Hashes preisgegeben. Ebenso kann eine mögliche Drittperson keine Aussagen über Passwörter in der Datenbank machen.

Symmetrische Verschlüsselung

Eine symmetrische Verschlüsselung ist die am einfachsten zu verstehende Art der Verschlüsselung. Es wird ein vereinbarter Schlüssel genutzt, um mit einem bestimmten Verfahren einen Klartext in einen Ciphertext zu verwandeln. In der Regel sollten die entstehenden Ciphertexte eine möglichst hohe Entropie haben, also möglichst wie eine Ansammlung von zufälligen Daten aussehen. Ist dies nicht der Fall, kann recht einfach auf den Klartext geschlossen werden, z.b. basierend auf der bekannten Frequenz von bestimmten Buchstaben in einer Sprache – z.B. ist im Deutschen ein “e” viel wahrscheinlicher als ein “x”. Ist der Schlüssel, der zwingend zwischen Client und Server ausgetauscht werden muss, einmal bekannt, hindert einen Angreifer nichts mehr daran, die Verbindung zweier Nutzern mitzulesen. Eine symmetrische Verschlüsselung kann also nur so gut sein, wie der schlechteste Kommunikationsweg auf welchem der vereinbarte Schlüssel ausgetauscht wird.

Asymmetrische Verschlüsselung

Das Dilemma des Austauschs eines Schlüssels über einen unsicheren Kanal hat zur Entwicklung von sogenannten asymmetrischen Verfahren geführt. Dies sind kryptografische Verfahren, in denen zwei Parteien jeweils einen zweiteiligen Schlüssel erstellen. Diese Schlüsselpaare nennt man den Privaten Schlüssel (Private Key), der stets geheim gehalten werden soll, und den öffentlichen Schlüssel (Public Key), den man mit der Person teilen kann, mit welcher kommuniziert werden soll. Das Clevere an den asymmetrischen Schlüsseln ist, dass ich etwas mit meiner Hälfte des Schlüssels entschlüsseln kann, was mit der anderen Hälfte verschlüsselt wurde. Dies bedeutet, dass jede Nachricht, die mit dem öffentlichen Schlüssel verschlüsselt wurde, nur von derjenigen Person entschlüsselt werden kann, die den zum öffentlichen Schlüssel komplementären privaten Schlüssel hat. Allgemein bekannt sind zwei verschiedene Verfahren, um solche komplementäre Schlüssel zu erstellen. Beim sogenannten RSA-Algorithmus basiert die Funktionsweise auf Eigenschaften von Primzahlen resp. einer algebraischen Struktur, die man Gruppe nennt. Die Sicherheit des RSA-Algorithmus beruht darauf, dass es für einen Computer unmöglich ist, eine Primfaktorenzerlegung einer grossen Zahlen in nützlicher Frist zu vollziehen. Interessanterweise wurde von Peter Shor bereits Ende des 20. Jahrhunderts gezeigt, dass ein Quanten-Computer eine solche Primfaktorenzerlegung sehr wohl in nützlicher Frist durchführen könnte. Der Algorithmus, um eine solche Zerlegung durchzuführen, wird deshalb nun Shor’s Algorithm genannt. Es muss allerdings angemerkt werden, dass es bis heute keinen Quantencomputer gibt, der “gross” genug ist, um ein ernsthaftes Risiko darzustellen. Andere Verfahren benutzen sogenannte elliptische Kurven resp. die entsprechenden X und Y Koordinaten von Punkten auf der Kurve. Die elliptischen Kurven bilden ebenfalls eine Gruppe. Anders als beim RSA-Algorithmus basiert hier die Sicherheit nicht auf der “Unmöglichkeit” der Primfaktorenzerlegung, sondern auf der “Unmöglichkeit” der Berechnung des sogenannten diskreten Logarithmus. Für das Fido-Protokoll ist jedoch das Umgekehrte von Interesse und wird in der Kryptografie auch Digitaler-Signatur-Algorithmus genannt. Solche Verfahren funktionieren in der Regel so, dass die private Hälfte des Schlüssels benutzt wird, um etwas zu verschlüsseln (eine Signatur zu erstellen), so dass jeder, der die öffentliche Hälfte besitzt, die Authentizität verifizieren kann. Damit diese Signatur nicht gefälscht werden kann, muss der private Schlüssel entsprechend gut geschützt werden. In UB-Auth erfolgt dies mit Hilfe den vom System zur Verfügung gestellten APIs: Die Keychain (iOS) und der KeyStore (Android). Beide Schnittstellen erlauben es, ein Schlüsselpaar zu erstellen und dieses an die biometrische Authentisierung des Benutzers zu knüpfen. Damit der private Schlüssel nicht versehentlich preisgegeben werden kann, stellt das System mit Hilfe von bestimmten Hardware-Lösungen sicher, dass der private Schlüssel diesen sicheren Bereich nie verlässt. Nun kann der Auftrag zur Erstellung einer Signatur an diese Schnittstelle übertragen werden. Wenn der Auftrag von UB-Auth kommt und vom richtigen Benutzer authentisiert wird, verschlüsselt die Schnittstelle die im Auftrag enthaltenen Daten mit dem entsprechenden privaten Schlüssel und liefert das Resultat der App. Somit hat sich der private Schlüssel nie im “frei zugänglichen” Arbeitsspeicher befunden.

App

Da die Applikation sowohl auf iOS und Android funktionieren soll, wurde das UB-Auth-Framework mit einer geteilten Code-Base entwickelt. Normalerweise würden wir hier eine C++-Code-Basis aufbauen, um wichtige Teile direkt auf beiden Plattformen zu haben. Für UB-Auth entschieden wir uns für einen anderen Weg und haben einen Teil des Frameworks in Rust (https://www.rust-lang.org/) geschrieben. Rust ist eine ursprünglich von Mozilla entwickelten Programmiersprache. Der Vorteil an Rust ist, dass durch den Aufbau der Sprache bestimmte Überprüfungen des Programm-Codes während der Kompilierung gemacht werden können. So kann der Compiler für Rust-Code eine “Garantie” geben, dass keine Memory-Bugs vorhanden sind.

Memory-Bugs sind Bugs, mehrheitlich in C/C++-Programmen, die auftreten, wenn der Programmcode nicht sorgfältig mit Lese- und Schreibzugriffen auf Speicheradressen umgeht oder Benutzer-Eingaben nicht sorgfältig validiert. Zu den Memory-Bugs gehören u.a. Stack-Overflows, Heap-Overflows, Out-of-Bounds read, Double Free, Use-After-Free und sie gehören zu den sicherheitskritischsten Bugs, wie jüngst wieder einmal mehr gezeigt (https://www.helpnetsecurity.com/2021/01/27/cve-2021-3156/)

Für die kryptografischen Operationen wird jedoch die von den Systemen zur Verfügung gestellte sichere Hardware verwendet. Entsprechend wurden diese Teile in Swift resp. Kotlin entwickelt. Diese fundamentalen und für alle Apps gleichen, wiederverwendbaren Teile bilden das sogenannte UB-Auth-Framework. Applikationen können nun ganz einfach dieses Framework einbinden und damit sichere Authentisierung und Authentifizierung anbieten.

Fazit

Wir haben nun moderne, sichere Wege angeschaut wie die Authentifizierung zwischen Service – z.B. einer Login-Seite – und Server funktioniert (OpenID Connect); wie die Daten, welche authentifiziert werden, von einem Gerät gegenüber dem Server authentisiert werden; und schlussendlich, wie das Gerät eine biometrische Authentisierung vom/von der BenutzerIn erhält. Alle diese Teile werden im UB-Auth-Framework kombiniert, und ermöglichen so die einfache Anbindung an bestehende Dienste – dank OpenID Connect – und die bequeme Authentisierung – dank Sicherheits-Hardware und FIDO2. Zusammen entspricht dies genau den Ansprüchen, welche die Zürich Access App fordert. Dadurch, dass das UB-Auth-Framework alle Komponenten von Server-Systemen bis zur App auf dem Smartphone zur Verfügung stellt, lässt sich die Integration genau so einfach realisieren, wie z.B. ein Facebook-Login. Dank der einfachen Integration und der vielen anderen Vorteile wird in der neuen Login-Lösung der Stadt Zürich unser UB-Auth-Framework verwendet. UB-Auth Informationen: https://ub-auth.ubique.ch