open-source cryptocard libraries

[g.w@hurderos.org]

On Jan 23, 12:01pm, Frank Cusack wrote:
} Subject: Re: open-source cryptocard libraries

Good afternoon, I hope the week is going well for everyone.

I was planning on writing a note about our One Time Identification
(OTI) work but Sam's note on features for 1.7 and this thread prompted
me to respond here.  Apologies if the issues are somewhat tangential.

A bit more discussion below.

> 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?

I've been mulling over these issues in earnest the last few weeks.

A conversation with Troy at the Kerberos conference in Ann Arbor early
last summer caused me to do a lot of thinking about two-factor
authentication in particular.  Issues since then have provoked a lot
of thinking about one time passwords.

The result of all that has inspired us to work on building out a
prototype for a one-time identification model.  The goal was to take
advantage of the need for stronger than password authentication and
the fact that USB storage has made a lot of things possible which
weren't possible 18 months ago.  Coupled with this we were interested
in a model which required minimal modification's to how a user
executes a login, for some definition of minimal.

Based on all that I'm just finishing up a a prototype implementation
of something we call OTI or One Time Identification.  The prototype
attempts to implement a two-factor/OTP model where the user carries a
USB dongle and a password (the latter preferably in their head).  The
dongle gets stuck in a device and the user logs in with their password
as they normally would.  The AS_REQ goes up to the server encrypted
with a unique key for each request.

Our identity model just happens to provide a convenient LDAP container
for each service which is granted to a user.  The identity of that
service is also a number which is approximately the size of a
symmetric key.  That makes RSA encryption of the token pretty straight
forward.

In our model each user's two factor 'instance identity' also has a
random 32-bit 'epoch time' associated with it.  When the OTI service
is provisioned for a user the management software generates a binary
blob consisting of that epoch time along with a copy of the RSA
encrypted identity (160 bit number).  The KDC holds the private copy
of the RSA key used for the encryption.

The KDC has access to the epoch time of the identity and a hash of the
RSA encrypted identity via the directory.  The user, of course, has
the epoch time and can compute their own hash of the encrypted blob.

I can go into the details of key scheduling if anyone is interested.
The goal was to develop a time unique symmetric key based on the
follow elements:

	1.) User's password.
	2.) Identity epoch time.
	3.) Offset between epoch and authentication time.
	4.) Hash of the RSA encoded identity.

The goal of the key scheduler is to produce a symmetric key which is
unique within a one second granularity interval. The resultant key is
used to encrypt (256-bit/AES/ECB) a payload consisting of:

	1.) Requested authentication time.
	2.) RSA encrypted identity token.

The encrypted payload is sent to the KDC in the authorization payload
field of the AS_REQ.

The KDC has all the components needed to re-generate the symmetric key
used for the wrapper encryption based on the authentication request
time.  If OTI payload decryption is successful the RSA encrypted
identity is decrypted and compared to the identity in the directory.
If they match the AS_REP process can move forward.

In the process of working on all this we spent a fair amount of time
thinking about the opportunities for replays against this system.

For initial correctness we set the use_master flag on any AS_REQ's
which will carry an OTI payload.  This allowed replay attacks against
slaves to be temporarily taken off the table.

Putting the requested authentication time inside the encrypted payload
was done in order to subordinate replay attacks to the permitted clock
skew interval of the KDC.  That leaves the issue of guarding against
replays within that interval.

In this model the KDC has a fair amount of opportunity to know if
things are right or wrong with an AS_REQ.  If an AS_REP is granted the
checksum of the encrypted OTI payload is hung off the user principal
along with the authentication request time.

An unusual amount of disdain is afforded any additional AS_REQ's which
may come in within the clock skew window with the same OTI payload
checksum.  Cache entries, of course, can be expired when their
authentication time offset is larger than the clock skew window.

Before Ken even mentioned it (great minds must think alike... :-) ) I
had started looking at the code paths to pick up the IP address for
the AS_REQ target KDC.  Placing that IP address into the OTI payload
should constrain replay attacks on slave KDC's to the problem of
breaking the OTI payload encryption within the clock skew window of
the KDC's.

Of course a full and complete security model for any of these
strategies would seem to dictate establishing some method for slave
and master KDC's to chat with one another.  All of the relevant RFC's
for SAD/SAM/OTP et.al. all discuss throttling strategies.  It seems
that use of such strategies is limited in current practice.  A system
for such communication may be something to consider for Sam's 1.7
list.

We would certainly be interested in any comments or observations on
this model.  Our goal in all this is to provide an open-source/GPL
architecture/solution for organizations wanting to implement a bit
more security on a budget.

> -frank

Best wishes for a pleasant remainder of the week to everyone.

}-- End of excerpt from Frank Cusack

As always,
Greg

------------------------------------------------------------------------------
			 The Hurderos Project
         Open Identity, Service and Authorization Management
                       http://www.hurderos.org

"Intellectuals solve problems; geniuses prevent them."
                                - Albert Einstein