Re: FIDO-basierte SSH-Schluessel

[Christian Weisgerber <naddy@xxxxxxxxxxxx>]

On 2022-06-09, Marc Haber <mh+uugrn@xxxxxxxxxxxx> wrote:

> Weißt Du wie die Softwareunterstützung für Yubikeys unter Debian aktuell
> aussieht? Die meisten Yubi-Tools sind iirc wegen python 2 aus Debian
> rausgeflogen.

Keine Ahnung. Für die FIDO-Basisfunktionalität braucht man keine
zusätzlichen Werkzeuge. Die Yubi-Tools habe ich noch nie angefasst.

Für die Kommunikation mit dem FIDO-Gerät verwendet OpenSSH die
libfido2 von Yubico. Nur das Ansprechen der USB-Devices ist
betriebsystemabhängig und da die Bibliothek auf Linux entwickelt
wird, sollte man annehmen, dass es dort funktioniert.

Auf OpenBSD funktioniert es.

Auf FreeBSD funktioniert es im Prinzip, aber die USB-Kommunikation
ist unzuverlässig und das Ganze daher nicht alltagstauglich. Scheint
ein Problem mit uhid(4) oder dem USB-Stack zu sein, leider außerhalb
meines Kompetenzbereichs.

>> Bei der Schlüsselerzeugung fallen nach FIDO-Abstraktion drei Teile
>> an:
>> 1. Der private Schlüssel, der das Gerät nie verlässt.
>> 2. Der öffentliche Schlüssel, den die Gegenseite bekommt.
>> 3. Der Keyhandle, dessen Format frei ist, der aber dem Gerät
>>    für jede Authentisierung übermittelt werden muss, damit es den
>>    passenden privaten Schlüssel zuordnen kann.
>>    Bei Webauthn bekommt die Gegenseite den Keyhandle, bei SSH wird
>>    er im privaten SSH-Schlüssel gespeichert.
>
> Das "Gerät" ist z.B. der FIDO2-USB-Schlüssel, also das Stück Hardware
> das man am Hosenbund hat?

Ja. Die Wortwahl ist etwas schwierig, da der Begriffsraum schon
stark besetzt ist. Von "Schlüssel" sollte man absehen, sonst kommen
so Blüten raus wie dein "Dabei ist der Key komplett auf dem Key
gespeichert". :-) "Token" ist bei SSH auch schon was anderes.
"YubiKey" ist griffig, verschweigt aber Konkurrenzprodukte.

Die FIDO-Dokumentation und die OpenSSH-Man-Pages verwenden
"Authenticator", was ich im Folgenden auch tun werde.

> Die "Gegenseite" ist bei Webauthn der Webserver auf dem die
> Applikation läuft?

Ja. Bei SSH die Maschine mit dem sshd(8), wohin man sich verbinden
will.

> Wie lang ist so ein Keyhandle
> üblicherweise, sieht man ihn als Bestandteil des Keys?

Konkret 128 Byte bei meinem YubiKey FIDO.
Im FIDO-Modell ist der Keyhandle separat vom öffentlichen Schlüssel.
Bei SSH bildet der Keyhandle den privaten SSH-Schlüssel.

> Ist ein Bruteforceangriff auf das Keyhandle ein realistischer Angriff?

Nein.

> Wie sperrt man einen Key bei Verlust?

Dazu gibt es keinen Mechanismus. Da der Authenticator allein keinen
Zugang gewährt, ist das erstmal nicht kritisch. Man kann die diesem
Authenticator zugeordneten Schlüssel manuell wegwerfen.

Damit man bei Verlust des Authenticators nicht ausgesperrt ist,
sollte man sinnvollerweise einen Reserve-Authenticator haben, mit
dem man einen Reserve-SSH-Schlüssel erzeugt und auch dessen .pub
in allen .ssh/authorized_keys verteilt.

>> Eine gängige Implementierung ist nun, dass der zufällig erzeugte
>> private FIDO-Schlüssel mit einem gerätespezifischen Schlüssel
>> symmetrisch verschlüsselt ("wrapped") wird und dieses Chiffrat als
>> Keyhandle ausgegeben wird.
>
> "gerätespezifisch" heißt hier, spezifisch für das Stück Hardware am
> Hosenbund?

Ja.

> Kann man diese gerätespezifischen Schlüssel neu generieren
> lassen wenn irgendwas passiert ist?

Das ist nicht spezifiziert. Ich glaube bei YubiKeys kann man alles
Schlüsselmaterial zurücksetzen. Ob damit auch alte FIDO-Schlüssel
ungültig werden, weiß ich nicht.

> Gibt es eine über das "den Key anfassen" hinausgehende Sicherung,
> z.B. eine PIN?

FIDO2 hat ein Flag "User Verification" eingeführt. Damit muss sich
der Benutzer gegenüber dem Authenticator ausweisen, z.B. über
biometrische Merkmale. Als Notbehelf gibt es da auch die Möglichkeit
eine PIN zu setzen, die am Rechner eingegeben und an den Authenticator
übermittelt wird. ssh-keygen(1) kann mit einer Option Schlüssel
erzeugen, die "User Verification" anfordern, und ssh(1) kann die
PIN vermitteln.

> Dieses "den Key anfassen" ist nach meiner Erfahrung ausgesprochen
> lästig.

Diese so genannte "User Presence"-Prüfung verhindert, dass man dem
Authenticator im Hintergrund Authentisierungsanfragen schickt, die
dieser auch beglaubigt, ohne dass der Benutzer etwas davon mitbekommt.

Das ist ein altbekanntes Risiko. Sagen wir, ich habe hier meinen
SSH-Schlüssel im ssh-agent(1) und logge mich mit Agent Forwarding
(ssh -A) auf shell.uugrn.org ein, weil ich von dort noch eine
SSH-Verbindung anderswohin aufbauen möchte. Der fiese Admin von
shell.uugrn.org kann jetzt Authentisierungsanfragen an meinen Agent
schicken, d.h. er kann eine Verbindung zu sonstwohin aufbauen und
sich dann dort als ich mit meinem SSH-Schlüssel einloggen.

Bei meinem FIDO-basierten SSH-Schlüssel blinkt dann der Authenticator
und ich werde stutzig.

Wenn man ernsthaft FIDO-basierte Schlüssel verwendet, sollte man
sich tatsächlich Gedanken über die Anordnung auf dem Schreibtisch
machen, damit man den Authenticator bequem erreichen kann. Werbebilder
zeigen da immer einen Authenticator in einem Laptop-USB-Port, wo
man von oben draufdrücken muss und damit einen Hebel gegen den
USB-Port bildet, was diesen früher oder später zerstören wird.
YubiKeys braucht man nur kraftfrei zu berühren - manche anderen
Modelle haben durchaus mechanische Knöpfe - aber das ist motorisch
anspruchsvoll. Ich empfehle eine Anordnung, mit Verlängerungskabel
oder Hub oder wie auch immer, bei der man den Authenticator bequem
zwischen Daumen und Zeigefinger "zwicken" kann. Das muss jeder
selber herausfinden, was für ihn funktioniert.

> Meine Yubikeys generieren einen OTP-Key wenn man sie zu lange
> anfasst (nicht abschaltbar) und sie fühlen sich schon angefasst wenn

Tja, wenn man ein Gerät mit mehr Funktionen überfrachtet, als die
Benutzerschnittstelle (1 Knopf) sinnvoll abbilden kann.

Für die FIDO-Basisfunktionalität passt ein Knopf zum Bestätigen
(1) der Schlüsselerzeugung und (2) der Authentisierung.

>> FIDO2 hat zusätzlich Resident Keys eingeführt, wo der Keyhandle auf
>> dem Gerät gespeichert wird, worauf sich die Slotzahl bezieht. Kann
>> man mit OpenSSH auch erzeugen und benutzen, ist aber nicht von
>> allgemeinem Interesse.
>
> Warum ist das uninteressant? Das ist doch viel näher an dem was wir
> gewöhnt sind?

Du bist nicht repräsentativ.

Ich gehe von jemandem aus, der bisher eben keinen Smartcard/usw.-
gestützten Schlüssel hatte, sondern einfach einen privaten SSH-Schlüssel
unter seinem Homedirectory liegen hat. Da ändert sich dann nichts,
außer dass der private Schlüssel nur noch im Zusammenspiel mit dem
FIDO-Authenticator funktioniert.

-- 
Christian "naddy" Weisgerber                          naddy@xxxxxxxxxxxx

-- 
Unix User Group Rhein-Neckar e.V.       https://www.uugrn.org
Archiv und An-/Abmeldeinformationen     https://mail2.uugrn.org
Veranstaltungen https://fixme.uugrn.org https://stammtisch.uugrn.org