NTLMSSP signing stuff

[eric.glass at comcast.net]

Hello,

I've been looking at NTLMSSP signing, specifically as used by the SSPI
MakeSignature function (I *think* these are the same keys used in
CIFS signing, but I'm not sure; someone could probably verify/refute).  In case
some of this is new knowledge, I figured I'd put it up here; I'm also going to
be adding a section on signing and sealing to my NTLM documentation at:

http://davenport.sourceforge.net/ntlm.html

but I'm going to try and tie up some loose research ends first.  Anyways,
enjoy.


"Dummy" signing:

    Not really a scheme as such.  Used if the SSPI context is initialized
    without specifying integrity support.  If the "Negotiate Always Sign" NTLM
    flag is negotiated, then a call to MakeSignature will result in the
    constant "signature":

        '0x01000000000000000000000000000000'

    If Negotiate Always Sign is not specified, you will get an error indicating
    that signatures are not supported by the provider.


NTLMv1:

    The basic signature scheme is (roughly):
        version + RC4(signingKey, '????' + CRC32(message) + SeqNum)

    Version number is 32-bit little endian ('01000000').

    SeqNum is a 32-bit LE sequence number, incremented after every signing,
    starting at zero with the first signature.

    The RC4 ciphertext is appended to the version number, and bytes 4-7 are
    overwritten by a pseudorandom counter; after a couple hundred signatures,
    it degenerates into a repeating sequence.  The signature verifies
    successfully with *any* value there, so it appears to be purely for
    obfuscation (possibly to confound cryptanalysis).

    The '????' is 4 bytes passed into the cipher along with the CRC and
    the sequence number; I don't know what they are, and it doesn't matter
    since the resultant ciphertext is overwritten by the counter value anyways.

    An example is:

        01000000f8930c00f1ee2b3d25fa1af3

    Which breaks out as:
    
        01000000            Version
        f8930c00            Counter value
        f1ee2b3d25fa1af3    RC4(signingKey, '????' + CRC32(message) + SeqNum)

    Under this scheme, I have identified the following signing key variants
    (I believe some/most/all of these are previously known):

    User Session Key
        Signing key is MD4(ntlmHash); or, if no NTLM response was provided
        (i.e., Win9x clients), first 8 bytes of lmHash padded with 8 null bytes.
        This is used when the "Negotiate Lan Manager Key" NTLM flag is *not*
        set, most notably in LMCompatibilityLevel = 2 (where the LM response
        is not sent).  Note that since this is based solely on the hashes
        (rather than the responses) the only entropy comes from the passwords;
        the resulting signatures are the same for all challenges.

    User Session Key w/Key Exchange
        Same as above, but the "Negotiate Key Exchange" NTLM flag is
        negotiated.  A "session key" is sent in the Type 3 message.
        The signing key is RC4(userSessionKey, sessionKey); that is, the
        session key sent in the Type 3 message is RC4-encrypted using the
        user session key from above; the resulting value is used as the
        signing key.

    Lan Manager Key (40-bit)
        Used when the "Negotiate Lan Manager Key" NTLM flag is negotiated,
        and "Negotiate 56" is *not* set.
        The signing key is DES(lmHash[0-6], lmResponse[0-7])[0-4] + '0xe538b0';
        that is, the first 8 bytes of the LM response are DES-encrypted using
        the first 7 bytes of the LM hash as a key; the first 5 bytes of this
        are taken and padded with the 3-byte constant '0xe538b0'.  This value is
        used as the signing key.

    Lan Manager Key 56-bit
        Same as 40-bit, but instead of 5 bytes padded with '0xe538b0', it is
        7 bytes padded with the single byte '0xa0'.  This is used when both
        "Negotiate Lan Manager Key" and "Negotiate 56" are set.

    Lan Manager Key w/Key Exchange
        This is used when "Negotiate Lan Manager Key" and
        "Negotiate Key Exchange" are set.  The Type 3 session key is used
        to mutate the signing key, but I haven't yet been able to determine
        how (it's not simply RC4(lanManagerKey, sessionKey) as in the
        user session key case).


There are additional variants employed when NTLMv2 authentication is used;
I'm still looking at those, as well as NTLM2 signing, but currently not really
getting anywhere.


Eric