Security-Token

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von SmartCard-Token)
Zur Navigation springen Zur Suche springen
USB-Token zum sicheren Verwahren eines geheimen Schlüssels
Matrix-Token, verschiedene Baugrößen

Ein Security-Token (einfach: Token) ist eine Hardwarekomponente zur Identifizierung und Authentifizierung von Benutzern. Gelegentlich werden damit auch Softwaretoken bezeichnet. Sie sind meist Bestandteil eines Systems der Zugriffskontrolle mit Zwei-Faktor-Authentisierung.

Mit den Begriffen elektronischer Schlüssel oder Chipschlüssel wird ein Token ebenfalls bezeichnet.

Gegebenenfalls sind gegen Missbrauch weitere Merkmale zur Authentifizierung heranzuziehen, möglich sind u. a. die Kenntnis eines Passworts bzw. einer PIN oder biometrische Merkmale des Benutzers. Security-Token können personalisiert sein, sie sind dann eindeutig einem bestimmten Benutzer zugeordnet.

Bauformen und Technologien

[Bearbeiten | Quelltext bearbeiten]

Der technische Überbegriff Token bezeichnet alle eingesetzten Technologien gleichermaßen und hängt nicht von einer bestimmten Erscheinungsform der Hardware ab. Dazu gehören alle Gegenstände, die Informationen zum Zweck der Identifikation und Authentifizierung speichern und übertragen können.

Bei Smartcards handelt es sich ebenfalls um Token. USB-Token, welche an einem USB-Port angeschlossen werden, weisen die Vorteile einer Smartcard auf, ohne dabei ein Kartenlesegerät zu benötigen.

Es kommen auch kontaktlose Token zum Einsatz, siehe RFID. Diese sogenannten Transponder können in Schlüsselanhänger (so genannte Fobs), Chipkarten und jedes andere Produkt integriert sein, solange dessen Eigenschaften die Funktion nicht stören. Somit wird das jeweilige Produkt selbst zum Token. Die Gegenstation muss den Token aktivieren und auch lesen können.

Übliche Verwendungen:

  • Fahrzeug- und Gebäudeschlüssel
  • Kleidung, Armbanduhren und Schmuck
  • Implantate in Tieren (Chipping)
SecurID-Tokengenerator von RSA Security als Schlüsselanhänger

Es gibt auch Tokengeneratoren, welche eine stetig wechselnde und zeitlich begrenzt gültige Zahlenkombination als Sicherheitstoken nach dem Einmal-Passwort-Verfahren (One-Time Password-(OTP-)) anzeigen. Generator und Server errechnen diese pseudozufällige Zahl gleichzeitig. Somit ist eine eindeutige Authentifizierung möglich. Diese Zahl wird gegebenenfalls auch mit einer Smartcard in einem tragbaren Lesegerät erzeugt. Als zusätzliche Sicherheitsmerkmale muss häufig eine PIN und/oder ein Anforderungscode in das Gerät eingegeben werden. Beispiel hierfür ist das Sm@rt-TAN-Verfahren.

Trusted Platform Modules (TPM) sind Chips, die ähnlich einer Smartcard geheime Schlüssel speichern. Der Chip ist in diesem Fall aber fest in ein Gerät eingebaut, z. B. auf ein Computermainboard aufgelötet. Das ganze Gerät wird zum Token. Es besteht nun die Möglichkeit, ein über das TPM eindeutig identifizierbares Gerät einem Benutzer zuzuordnen. Das TPM bietet gleichzeitig die Möglichkeit der Zugangssicherung zum Gerät (Pre-Boot Authentication). Somit kann (indirekt) eine Authentifikation des Benutzers vorgenommen werden.

USB-Security-Token YubiKey

Es gibt auch handelsübliche Geräte, welche als Token arbeiten und einen Authentifikationsfaktor übertragen. Dazu muss die Kommunikation zwischen dem Gerät und dem Prüfgerät oder Arbeitsplatz möglich sein. Weiter muss für eine sichere Authentisierung beispielsweise eine bidirektionale Übertragung möglich sein.

Bekannte Beispiele sind:

  • Mobiltelefone oder Smartphones etc. mit Pin-Card nach 3GPP-Standards
  • USB-, NFC- und Bluetooth-Token nach dem offenen U2F-Standard der FIDO-Allianz
  • aktive UHF Transponder (RFID UHF aktiv 868 MHz, alle proprietär, kein internationaler Standard) oder (RFID UHF aktiv 433 MHz ISO/IEC 18000-7 oder proprietär, RFID Mikrowelle aktiv 2,45 GHz ISO/IEC 18000-4 oder proprietär)
  • aktive LF Transponder (RFID LF aktiv 128 kHz, 134 kHz, alle proprietär, kein internationaler Standard)
  • aktive HF Transponder (RFID HF aktiv 13,56 MHz, alle proprietär, kein internationaler Standard)
  • galvanisch gekoppelte Token (1-Wire, Chips werden für Neuentwicklungen nicht mehr empfohlen)
  • herkömmliche Chip-Karten nach ISO-Standards ISO/IEC 10536, ISO/IEC 14443 (proximity card), ISO/IEC 15693 (vicinity card),
  • RFID NFC (Near Field Communication nach ISO 18092, ISO 21481 etc.)

An jeden einzelnen Arbeitsplatz muss dazu ein spezielles Prüfgerät (RFID-Norm oder proprietäre Lösung) oder ein Interface (1-Wire) angeschlossen sein.

Hingegen ist bei Verwendung von Bluetooth V4.0 die erforderliche Infrastruktur in allen modernen PCs, PDAs und Smartphones enthalten (voraussichtlich ab 2011Q2). Das Smartphone arbeitet dann als smart agent einen autonomen Prüfprozess ab, der für die einfache Authentifizierung keine Bedienhandlung erfordert.

Bekannte Beispiele sind:

  • Mobiltelefone oder Smartphones etc. mit Bluetooth-Interface IEEE 802.15.1 (Funktion Bluetooth-V4.0-Standard-Protokolle 2,45 GHz mit verschiedenen Standard-Profilen)
  • spezielle Bluetooth-Token (Funktion Bluetooth-V4.0-Protokoll „Stapel Low Energy“ 2,45 GHz)

Security-Token kommen meist als (Benutzer-)Ausweise zur Absicherung von Transaktionen zum Einsatz:

Allgemein werden dezentrale Systeme, in denen Daten auf dem Token selbst gespeichert waren, immer häufiger durch vernetzte Systeme ersetzt, in denen der Token nur noch als Ausweis dient.

Durch die Herausgeber der Token werden bevorzugt mehrere Funktionen in einen Token integriert, um einen „Mehrwert“ durch die Benutzung des Tokens zu erreichen und umfassende Nutzungs- und Bewegungsprofile zu erstellen.

Authentifizierungsprozess (schematisch)

[Bearbeiten | Quelltext bearbeiten]
  1. Der Nutzer leitet den Datenaustausch zwischen Token und Prüfsystem ein, indem er z. B. das Token vor ein Lesegerät hält.
  2. Das Lesegerät identifiziert das Token über dessen eindeutige Identifikationsnummer(n), wie dessen Typennummer, eine Medien-Seriennummer, eine Träger-Registriernummer und/oder eine Benutzer-Klassennummer.
  3. Der vom Token gelesene Datensatz wird vom Prüfsystem mit entsprechenden lokalen Referenzdaten nach einem wohl definierten Prüfverfahren verglichen: Die Authentifizierung des Tokens erfolgt mittels Challenge-Response-Authentifizierung, eventuell werden hierfür weitere Prüfdaten als zusätzliche Sicherheitsmerkmale, etwa eine PIN vom Träger des Tokens abgefragt.
  4. Zur Sicherheit werden die lokalen Referenzdaten mit weiteren Referenzdaten aus einer Datenbank von einem entfernten Server (z. B. über eine Standleitung oder eine geschützte Wählleitung) verglichen.
  5. Bei ungültigem Token oder ungültigen weiteren Referenzdaten weist das Prüfsystem weitere Zugriffe ab.
  6. Zur Rückverfolgung der Authentifizierung werden Ereignisdaten des Prüfvorgangs an den Server zurück übermittelt.
  7. Das Prüfsystem gibt die für den Träger des Tokens zulässige Benutzung, wie Funktionen und/oder Daten frei.

Sicherheit, Fälschung, Manipulation

[Bearbeiten | Quelltext bearbeiten]

Für sicherheitskritische Anwendungen muss ein Security-Token ein einmaliger Gegenstand sein, der gegen Manipulation und Vervielfältigung bzw. Fälschung besonders gesichert ist.

Hohe Sicherheit

[Bearbeiten | Quelltext bearbeiten]

Das Security-Token muss einmal zu verwendende Sitzungsschlüssel aus einem fixen und im Token gespeicherten Geheimnis, dem sogenannten Primärschlüssel, generieren. Zu diesem Zweck wird ein Kryptoprozessor eingesetzt, das sind spezielle ausgestattete Mikrocontroller, welche mit zusätzlichen Sicherheitsfunktionen ausgestattet sind. Diese Sicherheitsfunktionen sichern primär gegen das ungewollte Auslesen und gegen Reverse Engineering, beispielsweise indem am Schaltkreis sonst übliche Entwicklungsschnittstellen wie JTAG gänzlich fehlen. Dazu kommen kryptografische Verfahren zum Einsatz. Die kryptografischen Vorgänge laufen dann innerhalb des Chips ab.

Geringe Sicherheit

[Bearbeiten | Quelltext bearbeiten]

Auch Verfahren, die lediglich eine Identifikation aber keine Authentifikation erlauben, werden in der Praxis für die Authentisierung eingesetzt. Ein Code solcher Token ist nicht fälschungssicher, da das Identifikationsmerkmal frei ausgelesen und nachgebildet werden kann. Zu diesen Verfahren zählen u. a. Lösungen mit passiven RFID-Chips, die über eine einmalige Seriennummer verfügen und gemäß verschiedenen ISO-Standards für den Einsatz in elektronischen Etiketten (Tags) entwickelt wurden.

Unsicher im Sinne von kopierbar sind reine Speicher-Lösungen mit Chipkarten, Magnetstreifenkarten, Barcodes, Schlüsseldateien auf Datenträgern wie USB-Sticks sowie der klassische Schlüssel.

Ein Angriff kann auch auf die Kommunikation zwischen einem (ansonsten sicheren) Token und dem Lesegerät erfolgen, im einfachsten Fall über einen Replay-Angriff. Frei zugängliche (USB-)Verbindungsleitungen ermöglichen das einfache Zwischenschalten von Datenloggern. Insbesondere dann, wenn keine mechanische und/oder optische Kontrolle des Tokens durch das Lesegerät oder Bedienpersonal erfolgt, können zur Überwindung des Systems auch Geräte eingesetzt werden, die dem Original-Token in Art und Größe nicht zu ähneln brauchen. Funkübertragungen können häufig noch in großer Entfernung aufgezeichnet werden und bieten so eine große Angriffsfläche für Manipulation.

Behinderung von Manipulation

[Bearbeiten | Quelltext bearbeiten]

Eine absolut sichere Lösung wird es mit einem einzelnen Authentisierungsfaktor nie geben, jedes Sicherungsverfahren kann überwunden werden. Die Bauform des Tokens und die Art der (mechanischen, elektrischen, magnetischen, optischen, …) Datenübertragung hat großen Einfluss auf den Schutz gegen Manipulation. Eine Chipkarte kann beispielsweise vollständig von einem Lesegerät eingezogen und abgeschirmt werden. Ebenso trägt die Ausführung eines Lesegeräts oder Kundenterminals als kompakte, gegen Diebstahl, Austausch und sonstige Manipulation geschützte Einheit erheblich zur Sicherheit bei.

Diskussion über Lösungen

[Bearbeiten | Quelltext bearbeiten]

Die Unterscheidung der Anwendungsfälle ist Voraussetzung für eine sinnfällige Bewertung der Sicherheit, beispielsweise für:

  • Zugangskontrolle aus dem öffentlichen Raum
  • Zugriffskontrolle im öffentlichen Raum
  • Zugangskontrolle in einem gut gesicherten Raum
  • Zugriffskontrolle bei guter Trennung von der Umgebung

Alle Anwendungen im öffentlichen Raum sind unvermeidlich gefährdet durch unbefugte Dritte. Gegenteilige Behauptungen setzen auf Einschränkungen, die meist nicht explizit genannt werden, beispielsweise der maximal nutzbare Leseabstand[1]. Die Bequemlichkeit der Handhabung geht immer einher mit Gefährdungen[2]. Verallgemeinerungen sind nicht hilfreich.

Vorteile und Nachteile

[Bearbeiten | Quelltext bearbeiten]
Vorteile
Der Einsatz von Token bietet eine maximale Sicherheit gegen unberechtigte Nutzung unter folgenden Bedingungen:
  • mindestens ein weiteres Authentifizierungsmerkmal wird eingesetzt, z. B. PIN.
  • das Token ist tatsächlich einmalig und kann nicht vervielfältigt oder manipuliert werden, siehe Skimming bei EC-Karten und Kreditkarten
  • das Token kann im Falle eines Diebstahls oder Verlustes im System gesperrt werden, um unberechtigte Benutzung auszuschließen
  • Token können mit Funkverfahren verdeckt eingesetzt werden
Nachteile
  • Ein Token als alleiniges Authentifizierungsmerkmal ohne zweites unabhängiges Authentifizierungsmerkmal bietet keinen zuverlässigen Schutz gegen Manipulation, Verlust oder Attacken;
  • der Einsatz von Token verursacht wie jede technische Lösung Kosten für die Herstellung, die Registrierung und/oder Personalisierung, die Verteilung und die Bereitstellung von Infrastruktur in Form von Prüf- oder Lesegeräten und Software;
  • das Token kann zerstört oder verloren werden und den Benutzer dann zeitweise von wichtigen Funktionen des täglichen Lebens oder beruflicher Tätigkeit ausschließen;
  • das Token, und damit dessen Nutzer, ist immer eindeutig identifizierbar: eine Freigabe von Zugriffen für anonyme Nutzer ist wegen mangelnder Sicherheit nicht vorgesehen.

Software-Token (auch Soft-Token genannt) sind auf einem elektronischen Gerät wie einem Desktop-Computer, Laptop, PDA oder Mobiltelefon gespeichert und können dupliziert werden (im Gegensatz zu Hardware Tokens, bei denen die Berechtigungsnachweise nicht dupliziert werden können, es sei denn, man dringt physisch in das Gerät ein).

Da es sich bei Software-Tokens um etwas handelt, das man nicht physisch besitzt, sind sie besonderen Bedrohungen ausgesetzt, die auf der Vervielfältigung des zugrunde liegenden kryptografischen Materials beruhen – zum Beispiel Computerviren und Softwareangriffe. Sowohl Hardware- als auch Software-Tokens sind anfällig für Bot-basierte Man-in-the-Middle-Angriffe oder für einfache Phishing-Angriffe, bei denen das vom Token bereitgestellte Einmalpasswort erfragt und dann rechtzeitig an die echte Website übermittelt wird. Software-Token haben Vorteile: Man muss keinen physischen Token mit sich führen, sie enthalten keine Batterien, die irgendwann leer werden, und sie sind billiger als Hardware-Token.

Es gibt zwei primäre Architekturen für Software-Tokens: Shared Secret und Public-Key-Authentifizierung.

Bei einem gemeinsam Shared Secret (gemeinsamen Geheimnis) erstellt ein Administrator in der Regel eine Konfigurationsdatei für jeden Endbenutzer. Die Datei enthält einen Benutzernamen, eine persönliche Identifikationsnummer und das Geheimnis. Diese Konfigurationsdatei wird an den Benutzer weitergegeben.

Die Shared-Secret-Architektur ist in einer Reihe von Bereichen potenziell angreifbar. Die Konfigurationsdatei kann kompromittiert werden, wenn sie gestohlen wird und der Token kopiert wird. Bei zeitbasierten Software-Tokens ist es möglich, sich den PDA oder Laptop einer Person zu leihen, die Uhr vorzustellen und Codes zu generieren, die in der Zukunft gültig sein werden. Jeder Software-Token, der Shared Secrets verwendet und die PIN zusammen mit dem gemeinsamen Geheimnis in einem Software-Client speichert, kann gestohlen werden und Offline-Angriffen ausgesetzt sein. Token mit gemeinsamen Geheimnissen können schwierig zu verteilen sein, da jeder Token im Grunde ein anderes Stück Software ist. Jeder Benutzer muss eine Kopie des Geheimnisses erhalten, was zu zeitlichen Beschränkungen führen kann.

Einige neuere Software-Tokens basieren auf Public-Key-Kryptographie oder asymmetrischer Kryptographie. Diese Architektur beseitigt einige der traditionellen Schwächen von Software-Tokens, aber nicht ihre Hauptschwäche (die Möglichkeit der Duplizierung). Eine PIN kann auf einem entfernten Authentifizierungsserver statt auf dem Token-Client gespeichert werden, so dass ein gestohlener Software-Token nur dann verwendet werden kann, wenn auch die PIN bekannt ist. Im Falle einer Virusinfektion kann das kryptografische Material jedoch dupliziert und die PIN bei der nächsten Authentifizierung des Benutzers (über Keylogging o. ä.) abgefangen werden. Wenn Versuche unternommen werden, die PIN zu erraten, kann dies erkannt und auf dem Authentifizierungsserver protokolliert werden, wodurch das Token deaktiviert werden kann. Die Verwendung asymmetrischer Kryptographie vereinfacht auch die Implementierung, da der Token-Client sein eigenes Schlüsselpaar erzeugen und öffentliche Schlüssel mit dem Server austauschen kann.

Commons: Smart card tokens – Sammlung von Bildern, Videos und Audiodateien

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. NFC-Bezahlsystem
  2. Kreditkartendaten nicht sicher