Yubikeys are now supported

[Paul Wouters]

On Fri, 8 Oct 2010, Dennis Gilmore wrote:

> Even if you use your yubikey with yubicos servers. and auth against multiple
> different providers your AES key is never exposed to to any of the places that
> you auth to.

That is correct if different service providers auth the OTP against
yubicos servers.  However when setting up your key, two places have to
store the AES key. One is on your key, and one is on some backend auth
server that directly or indirectly authenticates you.

> to actually duplicate someones key you need to not only get the AES key.  you
> also need to know the session counter and keep yours higher than the real
> user.  which would make the real users key no longer work. and trigger warning
> bells.

The server validating your OTP ultimately is a server that knows
everything about everyone configured yubikey. Whether that is an instance
at Fedora, or an instance at yubicos.  Things might be mitigated by
putting openid in the middle, but ultimately the entire secret of
your yubikey has to live at at least two places. This is unlike a
public/private keypair solution where the private key can be only in
your possession.

This introduces an "all eggs in one basket" problem, and yubicos server's
would be a very interesting target to attack. Again, I am not saying it
makes yubikeys unsafe to use. But it is important to realise that the
trust model is very different from a public/private key scheme that is
usually found on token devices. You have to fully trust the endserver
validating your key with all your secrets.

When fedorahosted is compromised, by ssh key is not invalidated. When the
yubikey backend server is compromised, everyone needs to zap their keys.
There would also be a strong commercial incentive not to make such a
compromise public.

I am perfectly willing to trust fedora to have my AES key for purposes
of logging into fedora servers. But I would not want to trust fedora
infrastructure (or yubicos or another ID provider, especially located
in for me questionable legal frameworks that include the US) for logging
into my own infrastructure or servers or laptop. And if you share your
key amonst multiple backend servers, you are reducing your key security
to the least secure backend provider.

> It sounds like you do not fully understand how the yubikeys work. either that
> or i dont understand the attack you are describing?

It all comes down to this being based on symmetric crypto, not on public key
systems. The secret lives at two places, which is unlike modern crypto systems
we've become used to, such as SSL/SSH, RSA/DSA or OTR.

And again, I'd happilly use a yubikey with fedorahosted. I do think it
is strong enough. Anf it will be useful for a lot of people especially
because it is so much more affordable compared to other token based
systems, and because the USB keyboard method allows for easy integration
into most auth systems that deal with user/passwords.

However for our own purposes, this system did not provide the security
features we deemed mandatory (no coercion by third party, no sharing
private key, no relaying trust to third parties, verifiable audit
trail). I just wanted to relay this information so people understand
the concepts, features and risks of yubikeys.

Paul