Wir freuen uns, Ihnen die neue Reihe programmierbarer Hardware-TOTP-Schlüssel von TOKEN2 vorstellen zu können. Die Hauptinnovation ist die Möglichkeit, die Systemuhr von Hardwareschlüsseln über die NFC-API mithilfe spezieller Anwendungen zu synchronisieren. Derzeit wird eine Version für Android und Windows 10 vorbereitet.
Es gibt noch keine Anwendungen für iOS: Trotz der Tatsache, dass NFC-Chips auf den neuesten iPhone-Modellen physisch vorhanden sind, bietet Apple noch keine öffentliche API für deren Verwendung an.
Wofür ist das?
Im Gegensatz zu mobilen TOTP-Anwendungen gibt es bei Hardwareschlüsseln keine Möglichkeit, die Zeit über NTP, über ein Mobilfunknetz oder ein Funksignal zu synchronisieren: Die Hardwareschlüssel des Geräts sind vollständig isoliert und eigenständig und verwenden die Uhr auf ihrer Karte als Quelle für die genaue Zeit. In den Jahren 1933-1934. Die Physiker Scheibe und Adelsberger vom Kaiserlichen Institut für Physik und Technologie in Berlin nutzten die Möglichkeiten, den piezoelektrischen Effekt zur Zeitmessung zu nutzen. Dieser Effekt liegt der Systemuhr der Hardwareschlüssel zugrunde. Die Genauigkeit solcher Uhren liegt je nach Qualität zwischen ± 0,3 und ± 1,1 s / Tag. Wenn diese Genauigkeit für eine herkömmliche Armbanduhr ausreicht, kann bei Hardware-Schlüsseln ein Zeitunterschied von mehr als einem bestimmten Grenzwert dazu führen, dass die Aktivierung und / oder Authentifizierung abgelehnt wird. Diese Grenze hängt vom jeweiligen System ab (Microsoft Azure MFA lässt beispielsweise eine Vorspannung von bis zu 600 Sekunden in beide Richtungen zu), wenn ein Hardwareschlüssel zum ersten Mal registriert wird. Ferner ist der Offset-Synchronisationsprozess während der Verwendung des Schlüssels zur Eingabe bereits in
RFC 6238 klar beschrieben
RFC 6238 / 6. ResynchronisationWegen möglicher Zeitverschiebungen zwischen einem Client und einer Validierung
Server empfehlen wir, dass der Validator mit einem bestimmten Limit gesetzt wird
auf die Anzahl der Zeitschritte, die ein Prüfer zuvor "nicht synchron" sein kann
abgelehnt wird.
Diese Grenze kann sowohl vorwärts als auch rückwärts von der berechneten Grenze eingestellt werden
Zeitschritt beim Empfang des OTP-Wertes. Wenn der Zeitschritt ist
30 Sekunden wie empfohlen, und der Validator ist so eingestellt, dass er nur akzeptiert
zwei Zeitschritte zurück, dann wäre die maximal verstrichene Zeitdrift
etwa 89 Sekunden, dh 29 Sekunden im berechneten Zeitschritt und
60 Sekunden für zwei Rückwärtszeitschritte.
Dies würde bedeuten, dass der Validator eine Validierung gegen das durchführen könnte
aktuelle Zeit und dann zwei weitere Validierungen für jeden Rückschritt
(für insgesamt 3 Validierungen). Nach erfolgreicher Validierung wird die
Der Validierungsserver kann die erkannte Taktdrift für das Token aufzeichnen
in Bezug auf die Anzahl der Zeitschritte. Wenn ein neues OTP empfangen wird
Nach diesem Schritt kann der Validator das OTP mit dem aktuellen validieren
Zeitstempel angepasst an die aufgezeichnete Anzahl von Zeitschritt-Zeitverschiebungen
für den Token.
Es ist auch wichtig zu beachten, dass je länger ein Prüfer nicht gesendet hat
ein OTP zu einem Validierungssystem, je länger (möglicherweise) die
akkumulierte Taktdrift zwischen dem Prüfer und dem Prüfer. In solchen
In diesen Fällen funktioniert die oben beschriebene automatische Neusynchronisierung möglicherweise nicht
wenn die Drift den zulässigen Schwellenwert überschreitet. Zusätzlich
Authentifizierungsmaßnahmen sollten verwendet werden, um die sicher zu authentifizieren
Prüfen und synchronisieren Sie die Taktdrift zwischen dem
Prüfer und der Prüfer.
Das heißt, wenn der Authentifizierungsserver alle Anforderungen des RFC erfüllt und der Schlüssel nicht sehr selten für die Authentifizierung verwendet wird, beispielsweise mindestens ein paar Mal im Jahr (die genaue Anzahl kann unter Berücksichtigung der Genauigkeit des Oszillators und des vom Server zugelassenen Zeitversatzes berechnet werden), werden die Zeitversätze berücksichtigt Auf der Serverseite sollten keine Probleme auftreten. Bei Verwendung von Schlüsseln unter solchen Bedingungen ist die Zeitsynchronisationsfunktion grundsätzlich nicht erforderlich.
Die Zeitsynchronisationsfunktion kann jedoch in den folgenden Fällen nützlich sein:
- Wenn die Serverimplementierung von TOTP nicht der RFC6238-Empfehlung Nr. 6 entspricht. Ein Beispiel für eine solche Implementierung ist DUO :
TOTP-Token-Drift und Resynchronisation werden nicht unterstützt. Infolgedessen funktionieren importierte TOTP-Token möglicherweise nicht für die Authentifizierung mit Duo Security oder können nach einem variablen Zeitraum nicht für die Authentifizierung verwendet werden ...
- Wenn ein Stapel von Hardwareschlüsseln für eine lange Zeit gekauft wurde, diese aber erst nach einiger Zeit aktiviert werden mussten - in diesem Fall gibt es in vielen Systemen einfach keinen Synchronisationsmechanismus.
- Wenn der Dongle seltener als für die Synchronisierung erforderlich zum Anmelden verwendet wird. Wenn ein Benutzer beispielsweise dasselbe TOTP-Profil (genauer gesagt ein gemeinsames Geheimnis) auf zwei Geräte „kopieren“ möchte: a) in einer mobilen Anwendung auf dem Telefon für den täglichen Gebrauch und b) auf einem programmierbaren Hardwareschlüssel als Backup für einen regnerischen Tag . Wenn dieser regnerische Tag in 3-4 Jahren kommt, kann das Hardware-Token aufgrund des Zeitunterschieds nicht mehr genau verwendet werden. Darüber hinaus verliert der Akku auf dem Token, der sich lange Zeit nicht eingeschaltet hat, fast nicht an Kapazität. In diesem Fall ist es daher recht einfach, die Uhr auf sie zu bringen, um sie wieder in Betrieb zu nehmen.
SicherheitsanalyseWie immer basiert diese Art von Innovation immer auf einem Gleichgewicht zwischen Komfort und Sicherheit. Programmierbare Schlüssel mit der Fähigkeit, die Zeit vor Netzwerkangriffen (Phishing, Personen in der Mitte usw.) zu synchronisieren, sind keine Ausnahme. In den meisten Fällen verwenden unsere Kunden TOTP-Token genau zum Schutz vor diesen Arten von Angriffen. Sie werden sie jedoch vollständig schützen, aber Diese Möglichkeit impliziert eine vernachlässigbare und rein
theoretische Wahrscheinlichkeit eines Angriffs durch einen Wiederholungsangriff (Wiederholungsangriff) unter der Bedingung, dass Angreifer:
- Holen Sie sich den ersten Faktor (Passwort).
- Haben Sie ausreichend lange ohne Wissen des Besitzers physischen Zugriff auf den Hardwareschlüssel (siehe Schritt 3).
- Übersetzen Sie mithilfe der Anwendung über NFC die Uhrzeit auf dem Schlüssel auf ein bestimmtes Datum und zeichnen Sie eine ausreichende Anzahl generierter Codes auf. Dies funktioniert mit einem Skript nicht, da Sie zum Generieren von Codes auf die physische Schaltfläche klicken müssen und der aktuelle Code nur auf dem Bildschirm angezeigt wird (er wird nicht über NFC übertragen).
- Geben Sie die Zeit zurück ( damit der Eigentümer nichts errät ).
- Melden Sie sich abschließend mit dem Kennwort (Schritt 1) und einem der in Schritt 3 erhaltenen Codes an.
Wie wir sehen, kann dieses Risiko nur unter der Bedingung des physischen Zugriffs auf das Gerät auftreten. Beispielsweise kann ein Angriff von einem Kollegen in der Nähe ausgeführt werden, der aus irgendeinem Grund auch das Kennwort kennt. Unter solchen Bedingungen führt die Verwendung klassischer TOTP-Token jedoch zu demselben Risiko. Übrigens ist das Risiko, Token mit der Zeitsynchronisationsfunktion zu kompromittieren, vergleichbar mit dem Risiko von Fido-U2F-Geräten. Wenn ein Angreifer vorübergehend und unmerklich Zugriff auf einen U2F-Schlüssel hat, während er über ein Kennwort verfügt, kann er sich mit diesem Schlüssel beim System anmelden und einen weiteren (seinen) Schlüssel und hinzufügen Geben Sie dann den Originalschlüssel genauso leise an den Eigentümer zurück. Gemäß der Spezifikation kann ein Konto mehr als einen u2f-Schlüssel haben und jeder kann für die parallele Anmeldung verwendet werden. Faktoren wie
perfekte Papierkennwörter sind dem gleichen Risiko ausgesetzt.
Wie Sie sehen, ist der Angriff recht komplex und unwahrscheinlich. Im Allgemeinen kann das Risiko der Verwendung solcher Token mit der Verwendung einer Anwendung wie Google Authenticator auf einem Smartphone ohne PIN-Code, ohne Zugriff auf das Netzwerk und mit dem Benutzer immer bei sich verglichen werden.
Für Kunden, die selbst dieses Risiko immer noch als recht groß betrachten, lauten unsere Empfehlungen zu diesem Thema wie folgt:
- Die Beschränkung des physischen Zugriffs auf diese Art von Schlüsseln entspricht in etwa der von Bankkarten (unsere Schlüssel haben übrigens das Format von Bankkarten).
- Verwenden Sie programmierbare Tasten ohne Zeitsynchronisationsfunktion ( miniOTP-1 )
- Verwenden Sie programmierbare Tasten mit einer Zeitsynchronisationsfunktion, kombiniert mit dem Entfernen des geheimen Schlüssels. Das heißt, wenn sich die Token-Zeit ändert, wird der Startwert zurückgesetzt und muss erneut eingegeben werden (miniOTP-3, das Veröffentlichungsdatum des Modells wird zusätzlich bekannt gegeben).
Wo kaufen?Die Vorbestellung ist auf unserer Website geöffnet. Verwenden Sie den
HABR2019-Aktionscode für einen Rabatt von 10% (begrenzte Anzahl von Gutscheinen). Lieferung per Post (SwissPost oder La Poste France). Mit der Lieferung in die GUS-Länder gibt es noch keine Probleme.