Session key extraction
jhutz at cmu.edu
Mon Dec 22 18:33:49 EST 2008
--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
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
> 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.
More information about the krbdev