NACH OBEN
RUB » IT.SERVICES » Über Uns » Projekte » Projekt I: Der Prototyp

Projekt I: Der Prototyp

Konzeptphase

Ausgangslage und zentraler Use Case "Authentifizierung"

Derzeit befinden sich auf der RUBCard zwei unterschiedliche Chips: ein kontaktbehafteter Chip mit Siemens CardOS und der kontaktlose MIFARE DESFire EV1. Letzterer wird derzeit lediglich vom Akafö für das Bezahlen in der Mensa und den Cafeterien genutzt. Langfristiges Ziel ist, den kontaktlosen NFC-Chip in Zukunft für weitere Anwendungsfälle einzusetzen und somit den kontaktbehafteten Chip auf Dauer abzulösen. Zentraler Use Case im ersten Projekt ist die Nutzerauthentifizierung, also die persönliche Anmeldung im eCampus-Portal.

Die erste Phase umfasst die Erarbeitung eines Konzepts, das sich mit den verschiedenen Use Cases, den Anwendungsfällen, auseinandersetzt. Jeder Use Case, beispielsweise die Bibliotheksausleihe, soll möglichst als eigenständige Applikation bestehen, damit es nicht zu Abhängigkeiten zwischen den Anwendungsfällen kommt. Das Projekt hat zum Ziel, die Authentifizierung eines Nutzers mit Hilfe der DESFire-Karte am System zu realisieren. Konkret wird dies für ein Android-basiertes Smartphone mit integriertem, RFID-basiertem Kartenleser umgesetzt.


Formen der Authentifizierung

Das Proof-of-Concept umfasst folgende Authentifizierungsverfahren mit den Sicherheitsstufen von 0 bis 2:

  • Level 0: Login-ID und Passwort
  • Level 1: Clientzertifikat in Verbindung mit einem Passwort
  • Level 2: NFC-Ausweis (Card-ID) und PIN

Level 1 ist speziell für Endgeräte angedacht, die nicht über ein RFID-Lesegerät verfügen oder wenn der Nutzer diese Anmeldeoption ablehnt. Das im Hintergrund agierende Single-Sign-on-System (https://de.wikipedia.org/wiki/Single_Sign-on) unterstützt unterschiedliche Authentifizierungslevel. Der Nutzer kann dabei generell für jede Anwendung selbst entscheiden, welchen Mechanismus und damit welches Sicherheitsniveau er verwenden möchte.

Kryptographische Verschlüsselung

Neben der standardisierten verschlüsselten Datenübertragung kommen weitere kryptographische Verfahren zum Einsatz. Die Verfahren zur Authentifizierung mit der NFC-Karte werden durch den Algorithmus AES, Advanced Encryption Standard (https://de.wikipedia.org/wiki/Advanced_Encryption_Standard) geschützt. Jeder Use Case erhält eigene kryptographische Schlüssel für eine erhöhte Sicherheit.

Backend-Authentifizierung

Für erhöhte Sicherheit sorgt die Backend-Authentifizierung: Das Handy leitet nach Eingabe der PIN diese Information an einen Server, der mit diesem Wert kartenspezifische, kryptographische Schlüssel erzeugt. Mit dem Schlüsselmaterial können dann die Informationen von der Karte ausgelesen werden, woraufhin der Server den User authentifiziert. Die Authentifizierung läuft über das Backend, also über Server, welche die Identität prüfen. Auf den Servern befinden sich die kryptographischen Schlüssel, mit deren Hilfe sich jeder kartenspezifische Schlüssel berechnen lässt und die zur Prüfung der Authentifizierung nötig sind.

Verwaltung der kryptographischen Schlüssel

Neben der Sicherheit der verwendeten Karten und kryptographischen Funktionen ist zudem die sichere Verwaltung der kryptographischen Schlüssel ein wesentlicher Punkt im Sicherheitskonzept. Damit die Vertraulichkeit der Daten gewährleistet werden kann, muss sichergestellt werden, dass kein Unbefugter Zugriff auf die verwendeten Schlüssel erlangen kann. Daher wurde ein Konzept entwickelt, das vorsieht, die Schlüssel, auch auf den Servern, zu schützen. Dazu gehört unter anderem der Einsatz einer separaten Hardware, die ausschließlich die Schlüssel verwaltet sowie ein Backup der Schlüssel, das nur unter Anwendung des Mehraugenprinzips wiederherstellt werden kann.

Technisches Layout der NFC-Karte

MIFARE DESFire-Chip

Statt des kontaktbehafteten Krypotchips wird ein RFID-Chip vom Typ MIFARE DESFire EV1 (https://de.wikipedia.org/wiki/Mifare) eingesetzt, wie er bereits auf der aktuellen RUBCard für die bargeldlose Bezahlung in Mensa und Cafeteria Verwendung findet. Das NFC-fähige Gerät und der Prozessorchip in kontaktloser Ausführung kommunizieren per Funk. Die Stromversorgung übernimmt der Chipkartenleser, also das Smartphone/Tablet. Sobald die Karte mit dem Chip in das Funkfeld des Geräts gehalten wird, erhält der Chip ausreichend Strom zur Verarbeitung.

Einsatz der Random-UID

Der DESFire-Chip basiert auf dem ISO 14443 RFID-Protokoll, bei dem jede RFID-Karte eine eindeutige Adresse (Unique Identifier = UID) besitzen muss, ohne die eine Kommunikation zwischen Karte und Leser nicht möglich ist. Diese UID könnte prinzipiell mit einfachen Mitteln von Jedermann ausgelesen werden. Auf diese Weise könnten nicht-gewollte Bewegungsprofile erstellt werden. Da DESFire die Funktionalität „Random UID“, also eine zufällige Erzeugung der UID bei jeder Kommunikation, anbietet, ist es empfehlenswert, diese zu aktivieren. Somit können nur berechtigte Personen die UID einer Karte auslesen.

Implementierung der Authentifizierungs-App

Schnell und sicher ins persönliche Portal: App starten, PIN eingeben und den NFC-Ausweis an das Smartphone oder Tablet halten. Die Authentifizierung geschieht dann mittels des kryptographischen Verfahrens zwischen Karte und dem Backend System: War die Authentifizierung erfolgreich, öffnet sich der Browser auf dem NFC-fähigen Gerät und der Studierende ist angemeldet.

Prototyp für Android

Im Rahmen des Projekts wird ein Applikation-Prototyp für Android (ab Version 4) erstellt. Die für Android-Smartphones optimierte Anwendung dient zunächst als Proof-of-Concept und wird nicht im Play-Store veröffentlicht. Der Quelltext wird der Hochschule zur Verfügung gestellt, sodass nach Ablauf des Projekts Weiterentwicklungen im Haus oder durch andere Hochschulen sowie Dienstleister möglich sind.
Neben diesem Prototyp wird zudem ein Konzept für iOS (ab Version 6), Windows 8 und Android-Geräte ohne NFC mit alternativen Authentifizierungs-Mechanismen, wie in der Konzeptphase beschrieben, auf den jeweiligen Plattformen erarbeitet, sodass eine spätere Erweiterung möglich ist.

Implementierung des Access Managements

Der Prozess des Access Managements (AM) ist dafür zuständig, autorisierten Anwendern den Zugriff auf Services, in diesem Fall die eCampus-Dienste, zu gewähren beziehungsweise nicht autorisierten Anwendern den Zugriff zu verweigern. Daher wird auch von Rechtemanagement gesprochen. Es prüft anhand der hinterlegten Daten, ob der Benutzer berechtigt ist, die Services zu nutzen oder nicht.

Zentrale Verwaltung der Dienste

Bislang macht jede Applikation rund um den eCampus ihr eigenes Identitäts- und Rechtemanagement. Der Vorteil eines Access Managements: Es übernimmt die Aufgabe einer zentralen Schnittstelle für das Identitätsmanagement und das technische Authentifizierungsverfahren, sodass dies nicht jede Webanwendung selbst übernehmen muss. Darüber hinaus können beliebig viele Authentifizierungsverfahren eingebunden und bestimmt werden, ob die verschiedenen Anwendungen auch unterschiedliche Authentifizierungsverfahren erhalten sollen.
Die Ruhr-Universität hat zu diesem Zweck das Open Source-Produkt OpenAM als Access Management evaluiert und eingeführt. Im Rahmen dieses Projekts wird ein Modul entwickelt und eingebunden, das die Kommunikation mit der Karte beziehungsweise mit der Anwendung realisiert.