yubikey (Re: OpenPGP, Kryptokampagne)

[Paul Hänsch]

Bernhard Reiter <reiter at 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.

-- 
Paul Hänsch                        █▉     Jabber: paul at jabber.fsfe.org
Webmaster                        █▉█▉█▉               Support the FSFE
Free Software Foundation Europe    ▉▉    http://fsfe.org/support/?paul
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 836 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.fsfe.org/pipermail/fsfe-de/attachments/20131202/5c7cfd0a/attachment.sig>