open-source cryptocard libraries

Ken Hornstein kenh at
Tue Jan 23 10:14:32 EST 2007

>> And how would the attacker know what the old cryptocard response is?
>By brute forcing the AS_REQ.  If use-sad-as-key is set, game over.
>If send-encrypted-sad is set, it's probably better, but presumably
>you use hardware preauth to prevent against weak passwords.  But
>in the case where a weak password can be guessed, send-encrypted-sad
>makes the hardware auth superfluous if it can be replayed.  Both
>of these cases are actually noted (to some degree) in the SAM draft.

I know these are all issues with SAM ... but we were specifically
talking about CRYPTOCard, and of course in that case neither
use-sad-as-key nor send-encrypted-sad is used (well, you _could_ use
send-encrypted-sad, I suppose, but there is no need ... and it's not
clear to me if the MIT codebase supports use-sad-as-key).  So, I still
stand by my original statement ... if you're using SAM with CRYPTOCard
_properly_ then there is no issue with replaying an exchange against
another KDC.  If you are really paranoid, I can think of a simple fix:
place inside the sam-track-id the hostname or some other KDC-specific
identifier, and have the KDC check that when it processes the preauth

>In any case, my company, TRI-D Systems ( solves
>this problem with a kdc plugin to talk to our server (otpd) which
>then handles all the OTP stuff including global token state mgmt
>and safe to use in use-sad-as-key mode.  Thus giving the possibility
>to eliminate user passwords altogether but without the difficulty
>of a smartcard/PKI deployment.

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.

>*AND* probably more usefully, it allows you to use the same OTP
>device across multiple authentication technologies.

I agree, that does sound nice.


More information about the krbdev mailing list