open-source cryptocard libraries
fcusack at fcusack.com
Tue Jan 23 13:00:54 EST 2007
On January 23, 2007 10:14:32 AM -0500 Ken Hornstein <kenh at cmf.nrl.navy.mil>
>>> 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
I just thought it would be useful to talk about it in more general terms.
I should have explicitly said that for your specific case there were no
> 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
great idea! very effective and easy.
>> In any case, my company, TRI-D Systems (www.tri-dsystems.com) 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.
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
More information about the krbdev