Bernhard Reiter reiter@fsfeurope.org, Mon, 2 Dec 2013 11:37:18 +0100:
Am Freitag, 29. November 2013 23:01:56 schrieb Paul Hänsch:
Ich meinte natürlich, warum die kein _a_symmetrisches Verfahren einsetzen war unklar. So besteht die Möglichkeit, wenn der Server die registrierten Infos verliert, dass der yubikey kompromittiert ist (wenn ich mich richtig erinnere).
Jain, bei den CRAM-Verfahren werden die Serverpasswörter mit einem serverspezifischen Salt abgelegt, der vom Client mit verhasht wird. So kann der Server niemals in Besitz des eigentlichen Secrets kommen und die Passwortdatenbank des einen Servers ist auf dem anderen wertlos. Das ist die Sache mit dem Inneren und äußeren Hash, die du auf Wikipedia liest. Aber... das funktioniert, weil bei Browser/Mailclientbasierten CRAM-Lösungen der Serversalt vom Client erzwungen wird. IdR. ein Salt der dem Domainnamen entspricht. Der Yubikey hat in genau dem Fall in dem du das CRAM-Verfahren zur lokalen Authentifizierung nutzt keine Möglichkeit einen Serverhash zu erzwingen oder eine Uhrzeit zu ermitteln, so dass eine böswillige Authentifizierungsstelle schon beim ursprünglichen Verzeichnen des Serversecrets den den Serverhash einer anderen Authentifizierungsstelle kopieren kann (der ist ja nicht geheim). Das hat mit einem Verlust der Tokendatenbank auf dem Server nichts zu tun und das Szenario fordert vor Allem aufmerksamkeit beim Ausrollen der Serversecrets - das ist die Sache mit dem Keymanagement von dem ich erwähnt habe, dass es bei RSA einfacher ist.
Kompromittiert ist der Yubikey wenn der Server die HOTP-Secrets verliert. *Das* allerdings lässt sich schwer vermeiden, für das Anwendungsszenario in denen der Key zum Einsatz kommt. Wie schon erwähnt ist Challenge-Response nicht bei allen Szenarion praktikabel. HOTP ist da unter Umständen ein praktikableres Szenario das eben leider diese Eigenschaft hat.
Symmetrische Kryptografie findet in beiden Funktionen des Yubikey keinen Platz. Auf asymmetrische Funktionen wurde schlicht und ergreifend aus Kostengründen verzichtet - die Primäre Funktion des Sticks ist ohnehin das "One-Time-Pad", die zweitklassige Challenge-Response Funktion nur eine zusätzliche Dreingabe.
Naja die Kostengründe sind die "offizelle" Aussage von yubikey, angesicht der Preise im Vergleich im OpenPGP Karten, scheint mir das aber noch nicht einsichtig. Und wenn die Challenge-Response Funktion zweiklassig ist, warum dann überhaupt anbieten?
Sicher wäre es auch furchtbar praktische einen Kaffeewärmer und eine Kreditkartenfunktion im Key zu haben. Aber irgendwo musst du die Grenze ziehen und bei derzeitigem µC-Design ist die eben sehr niedrig angelegt. Während das "Dinger" einer PGP-Card eben RSA/DSA ist, ist Sha1 das "Ding" was der Yubikey fährt (macht die Smartcard eigentlich Sha1?) - One Tool, One Job. Den Yubikey jetzt dafür zu kritisieren, *dass* er das Feature implementiert statt wegzulassen wäre natürlich Quark. Dazu kommt, dass "zweitklassig" wahrscheinlich immernoch die zweitbeste Authentifizierungsmethode seit Pythagoras ist.
Ich will hier nicht grundsätzlich für den Yubikey argumentieren. Die Intention meiner Mails war die Klärung des technischen Sachverhalts, nicht eine Beteiligung an der Diskussion um den Wechsel. Ich kann mir jedenfalls schon vorstellen, dass die Funktionen eines Yubikeys häufiger genutzt werden würde, als die Funktionen der Fellowship-Karte im Moment genutzt werden.