Session key extraction

[Jeffrey Hutzelman]

--On Monday, December 22, 2008 04:19:44 PM -0500 Greg Hudson 
<ghudson at MIT.EDU> wrote:

> I could see a protocol having its own (ill-advised) constraints on how
> encryption or checksumming is done such that it would want to pull out
> the key.

I can, too, and so could a number of other people.  To support that, we 
defined an extension to GSS-API (RFC4401) to allow applications to extract 
psuedo-random keying material for application use.

>> I'm very uncomfortable with this concept: using a session key without
>> knowing what kind of key it is or what structure it is seems kind of
>> dangerous.

I am, too.  Additionally, there is the problem that not all mechanisms 
necessarily have such a key, and that no mechanisms I know of (certainly, 
no standards-track mechanisms) specify what key should be used for such a 
purpose.  There are some mechanisms, including Kerberos, for which it is 
possible to make a reasonable guess, but even for these, there may be more 
than one reasonable guess.  For example, for RFC4121, one could imagine 
using the Kerberos ticket session key, whatever subkey is used to derive 
keys for creating GSS tokens, any of the derived keys, or some other thing 
such as a key derived with a different key usage.


> 1. DES keys are not uniformly distributed.  This could be addressed by
> removing the DES key "structure" (the parity bits) to yield a 56-bit
> key.  Are there other conventional cryptosystems which have key
> structures which are not so easy to remove?

Generally, no.  DES keys actually have two classes of problems here which 
do not generally apply to other cryptosystems.  One is the introduction of 
bits (parity bits) which are not actually keying material but rather are 
intended to help verify the correctness of a DES key transported over an 
unreliable medium.  I'm not really an expert, but I am unaware of any other 
cryptosystem in wide use which has this "feature".

The second issue is that DES has a number of weak and semi-weak keys which 
are represented by otherwise valid patterns, and which anyone choosing a 
key, or designing an algorthim for deriving a key, must be careful to 
avoid.  As far as I've been able to tell, more recent practice has been to 
design ciphers so that no such keys exist, and all possible bitstrings of 
the appropriate length are suitable for use as keys.  However, it is best 
not to depend on this, and instead to avoid relying on using as a key 
unknown data not specifically generated for the cipher in question.


> 2. Using one cryptosystem's keys with another cryptosystem might create
> vulnerabilities.  Presumably we're talking about vulnerabilities more
> subtle than "the application's cryptosystem is so weak that it reveals
> the key, compromising the mechanism's cryptosystem."

Right.  The obvious cases I can think of are ones where the applications 
cryptosystem requires some structure in the key that is not present, those 
where the application assumes the key is uniformly distributed when it is 
not (as when it is a DES key with parity bits), and cases where the 
application's cryptosystem requires a longer key than that used by the 
mechanism.


> Thinking about it briefly: in some cases, even using the key with the
> same cryptosystem, but without any associated state, could be a problem.
> For instance, if the cryptosystem uses the key to produce a PRNG stream
> which is XOR'd with the plain text, using the same key to encrypt two
> messages with the same stream position could reveal both plaintexts.

Correct.  This is one reason why using single-session keys and key 
derivation is so important, particularly depending on the mode in use (the 
one you describe turns out to be fairly common nowadays).


> I can also think of exotic cases where a provider might not be able to
> come up with a key.  For instance:
>
>   * A mechanism draws from a large body of previously negotiated
> one-time-pad data to encrypt data.  (Both sides share a secret, but it's
> a very large secret, and it can't be used for any other purpose, so if
> you were to answer the application's query for session key data you
> would have to coordinate that with the other party--something the API
> doesn't really allow for.)
>
>   * A mechanism uses public-key crypto operations for all messages.
> (Ruinously expensive today, but perhaps that won't always be true, or
> perhaps the mechanism is only used for small amounts of message data and
> the users are highly concerned with mathematical provability.)  In this
> case the two parties may not ever negotiate a shared secret.
>
> Such exotic cases might be covered by allowing the mechanism to return a
> 0-byte session key.

You might also have a GSS-API mechanism which provides only integrity 
protection for per-message tokens, or even one which doesn't do GSS_wrap() 
at all.  Such a mechanism may also have no shared key.

Additionally, there is the problem that a "give me the key" operation is 
useful only if it produces the same result when called by both parties to 
the context.  So, if the goal is to support implementations of application 
protocols that use the corresponding SSPI feature, then it is necessary to 
return the same key that SSPI would, or it won't work.

I'd be nervous about a "Get the Windows key" feature, but it may be 
necessary to allow implementation of some Windows protocols.  If this 
happens, I think it should have exactly the semantics Sam described, 
inclulding just failing for mechanisms not used on Windows.  Applications 
other than existing Windows protocols should use the RFC4401 interface, 
which is portable to more implementations, more likely to exist in new 
mechanisms, and safer to use.

-- Jeff