open-source cryptocard libraries

[Frank Cusack]

On January 23, 2007 2:21:27 PM -0500 Ken Hornstein <kenh at cmf.nrl.navy.mil> 
wrote:
>>> Hm.  My big issue with use-sad-as-key is that none of the tokens I have
>>> seen have enough entropy where I would be comfortable using them as the
>>> only source of keying material (e.g., the CRYPTOCard only gets you 32
>>> bits best-case).  Do you guys have a solution to that?  If so, that
>>> would be pretty cool.
>>
>> We use HOTP which gives the full range (ie 5 digits = 40 bits), I think.
>> Please correct me if my thinking is flawed here.
>>
>> Please educate me why this is important?  use-sad-as-key doesn't
>> establish the session key does it?  Or are you worried about online
>> guessing attack.
>
> Well, use-sad-as-key doesn't establish the session key _directly_.  But
> it means that only the SAD is used to encrypt the AS_REP which contains
> the TGT session key.  That means that no matter what keytype you have
> for a session key, it's encrypted by a key that has only (in your case)
> 40 bits of entropy.  That's a bit low for my tastes, but it all depends
> on your environment and comfort level.  If, for example, snooping the
> AS isn't a huge concern for you, then it's not a big deal.

I see.  So in our implementation the length of the OTP part when using
HOTP can be 5-9 decimal digits, then there's an alphanumeric+symbolic
PIN that you enter as part of the complete passcode (PIN+OTP).  With our
variant on HOTP you can get as many digits as you want, not limited to
9.  Our cards will only display 8 digits though.  I guess we could make
it so you press the button and can see 8 additional digits, like secure
computing does.  I'm also working on a smartcard interface to the card
that enables you to have "very long" OTPs and the user doesn't have to
enter them directly, but this will require client side software and
hardware.  It's more smartcard-like but without the PKI.

Back to what works today, assuming the PIN isn't compromised, 6-7 digits
plus a 5-6 character PIN is probably good enough for most folks. (?)
I guess at this point it's really like having a password and an OTP
anyway.

Which makes me think of something else.  If you use hardware tokens
because you are worried about a password compromise, then if you have
a short OTP, ie one where use-sad-as-key is a problem, even the default
(good) mode of SAM does not protect you from either a replay attack (if
OTP is not synced to backup KDC) or from an online guessing attack or
from a snooping attack.  I am talking about the case where a password
might be known or LEARNED, not the case where a weak password might be
GUESSED.  In the password-is-guessable case, the OTP does protect the
password to some degree.

Do you agree?

> Hrm, are you sure about that entropy number?  I took a look at RFC
> 4226, and it's talking about decimal digits.  My math shows around 13.3
> bits of entropy for 5 decimal digits.  5 hex digits would be 20 bits of
> entropy (4 bits for each hex digit).

Right, I realized that right away but couldn't follow up fast enough
as mail through the list is delayed for me for some reason.  Thanks for
the correction.

-frank