<?xml version="1.0"?>
<!-- name="generator" content="pyblosxom/0.8.1" -->
<!DOCTYPE rss PUBLIC "-//Netscape Communications//DTD RSS 0.91//EN" "http://my.netscape.com/publish/formats/rss-0.91.dtd">

<rss version="0.91">
  <channel>
    <title>Tollef Fog Heen</title>
    <link>http://err.no/personal/blog/</link>
    <description>tfheen's blog</description>
    <webMaster>tfheen@err.no</webMaster>
    <managingEditor>tfheen@err.no</managingEditor>
    <language>en</language>
    <image>
        <url>http://err.no/tfheen.jpg</url>
        <title>Tollef Fog Heen</title>
        <description>Image of Tollef Fog Heen</description>
        <link>http://err.no/personal/blog</link>
        <width>66</width>
        <height>100</height>
    </image>
  <item>
    <title>A small explanation about the yubikey</title>
    <link>http://err.no/personal/blog/tech/2010-03-16-08-41_Yubikey_a_small_explanation.html</link>
    <pubDate>Tue, 16 Mar 2010 08:41 +0100</pubDate>
    <description>&lt;p&gt;&lt;a href=&quot;http://etbe.coker.com.au/2010/03/15/yubikey/&quot;&gt;Russell Coker&lt;/a&gt; recently reviewed the Yubikey.  The article
mentions me, so I figured I&apos;d correct a minor thing and respond to one
of the comments.&lt;/p&gt;

&lt;p&gt;First, the &lt;code&gt;yubikey-server-c&lt;/code&gt; is my reimplementation of the
Yubikey authentication protocol.  Yubico provides two implementations,
one in PHP and one in Java, neither which I&apos;m particuarly interesting
on building my system security on. Any bugs, misfeatures, etc in the C
implementation are mine and mine alone.&lt;/p&gt;

&lt;p&gt;Barak A. Pearlmutter, one of the commenters on Russell&apos;s blog writes:&lt;/p&gt;

&lt;p&gt;i don’t understand. isn’t this thing vulnerable to eavesdropping and
  replaying? even if &lt;em&gt;it&lt;/em&gt; has a counter which changes etc, the things
  it is talking to (web sites) can’t know that some generated string
  is being reused. and it doesn’t even have a clock, so these things
  can be old.&lt;/p&gt;

&lt;p&gt;The way the Yubikey works is you have a central authentication server.
This has a secret shared with the key.  Setting this secret is the
primary function of the personalisation tool.  When you press the
button, the key takes its internal state (various counters, uid field,
etc) and encrypts this using AES-128.  This is then sent to the
application you are trying to access, be it Wordpress, SSH or
something else.  Said application then contacts the authentication
server which decrypts the ticket, checks the values of the counters to
make sure it&apos;s not a replay and responds with OK, bad ticket, replay
and various other status codes.  Based on this, the application grants
or denies access.&lt;/p&gt;

&lt;p&gt;There are really two places you could attack this: in the
communication between the web browser and application or between
application and authentication server.  Both of those can be secured
using SSL.&lt;/p&gt;

&lt;p&gt;There is no way to use a single yubikey in multiple authentication
realms without extra software.  To do this, you would have a OpenID
provider that uses the Yubikey for authentication, or you could have a
Kerberos server with cross-realm trust.&lt;/p&gt;

&lt;p&gt;As for the PAM modules and other tools so far not being packaged, yes,
I know, I might fix it, but the current setup has the bits I use, as I
use RADIUS authentication to get services to support both Yubikey and
passwords.&lt;/p&gt;
</description>
  </item>
  </channel>
</rss>
