none
What would be the 'RandomSessionKey' to calculate SIGNKEY() ? RRS feed

  • Question

  • In the documentation of ‘GSS_WrapEx Examples’, the SIGNKEY is calculated using function SIGNKEY() (Please See the Link: http://msdn.microsoft.com/en-us/library/dd644733%28v=prot.20%29.aspx)


    MD5(ConcatenationOf(RandomSessionKey, "session key to client-to-server signing key magic constant")):  

     

    And the Output is:

    47 88 dc 86 1b 47 82 f3 5d 43 fd 98 fe 1a 2d 39

     

    Can anybody give an example of RandomSessionKey? and How to generate it ? I tried with -

    RandomSessionKey:

    55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55   UUUUUUUUUUUUUUUU

     

    But failed to generate the output: 47 88 dc 86 1b 47 82 f3 5d 43 fd 98 fe 1a 2d 39



    Monday, November 26, 2012 4:48 PM

Answers

  • Hi Shishir:

    I verified and the document is correct. Here is how I did it.

    RandomSessionKey = 0x55555555555555555555555555555555

    Null terminated string "session key to client-to-server signing key magic constant" = 0x73657373696F6E206B657920746F20636C69656E742D746F2D736572766572207369676E696E67206B6579206D6167696320636F6E7374616E7400

    Concatenated String= 0x5555555555555555555555555555555573657373696F6E206B657920746F20636C69656E742D746F2D736572766572207369676E696E67206B6579206D6167696320636F6E7374616E7400

    And when I calculate MD5 hash of the above, I get

    0x4788DC861B4782F35D43FD98FE1A2D39

    Same as in the document MS-NLMP.

    Please let me know if this does not answer your question.


    Regards, Obaid Farooqi

    Wednesday, November 28, 2012 9:26 PM
    Owner
  • Hi Shishir:

    The document MS-NLMP actually mentions that it is a null terminated sting. In section "3.4.5.2 SIGNKEY" it is stated that:

    "

    ....

    If extended session security is negotiated, the signing key is a 128-bit value that is calculated as
    follows from the random session key and the null-terminated ASCII constants shown.

    ...

    "


    Regards, Obaid Farooqi

    Thursday, November 29, 2012 8:41 PM
    Owner
  • Hi Shishir:

    I was able to generate the same value as the document shows.

    Are you using the same handle that you use to encrypt the data (Pliantext)? As mentioned in section 3.4.4.2, the handle is "... to key state structure corresponding to the current state of the SealingKey".

    Please let me know if this does not resolve your problem.


    Regards, Obaid Farooqi

    Monday, December 3, 2012 4:51 PM
    Owner
  • Hi Shishir:

    Please find the answers to your questions in Q&A format as follows:

    Q1. Whether the ‘message’ would be “P.l.a.i.n.t.e.x.t.” to generate the mechListMIC of “SessionSetup Response, Unknown message type” or else? If else, please give me an example.

    A. mechListMIC stands for “Mechanism List Message integrity code”. It is used to verify the mechanisms that client sent in the first SPNEGO message. If you look at your message trace, mechanisms (MechTypes) are in the securityBlob of first session setup request. I am pasting an example from a netmon network trace:

      Frame: Number = 3, Captured Frame Length = 220, MediaType = ETHERNET

    + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-4B-30-04],SourceAddress:[00-15-5D-4B-30-23]

    + Ipv4: Src = 10.1.1.205, Dest = 10.1.1.201, Next Protocol = TCP, Packet ID = 259, Total IP Length = 206

    + Tcp: Flags=...AP..., SrcPort=49169, DstPort=Microsoft-DS(445), PayloadLen=166, Seq=3047701357 - 3047701523, Ack=2750414017, Win=511

    + SMBOverTCP: Length = 162

    - SMB2: C   SESSION SETUP (0x1)

        SMBIdentifier: SMB

      + SMB2Header: C SESSION SETUP (0x1),TID=0x0000, MID=0x0002, PID=0xFEFF, SID=0x0000

      - CSessionSetup:

         StructureSize: 25 (0x19)

         VcNumber: 0 (0x0)

       + SecurityMode: 2 (0x2)

       + Capabilities: 0x1

         Channel: 0 (0x0)

         SecurityBufferOffset: 88 (0x58)

         SecurityBufferLength: 74 (0x4A)

         PreviousSessionId: 0 (0x0)

       - securityBlob:

        - GSSAPI:

         - InitialContextToken:

          + ApplicationHeader:

          + ThisMech: SpnegoToken (1.3.6.1.5.5.2)

          - InnerContextToken: 0x1

           - SpnegoToken: 0x1

            + ChoiceTag:

            - NegTokenInit:

             + SequenceHeader:

             + Tag0:

             + MechTypes: Prefer NLMP (1.3.6.1.4.1.311.2.2.10)

             + Tag2:

             + OctetStringHeader:

             + MechToken: NTLM NEGOTIATE MESSAGE

    The little endian representation that you would see in the hex detail window in netmon is 30 0c 06 0a 2b 06 01 04-01 82 37 02 02 0a. This value is used as the message to generate mechListMIC by the client. Client sends this with Authenticate message.

    On receipt of this, server verifies it against what server received as the list of mechanism from client. If the verification passes, server generates its own mechListMIC and sends it to client in the final session setup response. The server also uses the same message (30 0c 06 0a 2b 06 01 04-01 82 37 02 02 0a). The client verifies it on the receipt.

    More information about MechListMIC can be had from RFC4178 (http://www.ietf.org/rfc/rfc4178.txt ) and MS-SPNG (http://msdn.microsoft.com/en-us/library/cc247021(v=prot.20).aspx )

    Q2. In SMB2 header [in section 2.2.6 & 2.2.1.2], the Signature (16 bytes) for “Session Setup Response” if SMB2_FLAGS_SIGNED. To generate the signature [in section 3.1.4.1], what would be the message inside HMAC-SHA256 (sessionKey, message)? An example of 'message' would be helpful.

    A. The input message is the whole SMB2 message. I am pasting an example below. The message is final session setup response. The session key is 4f a0 2b ee bb cd ec 62 a6 eb 90 77 ad fc 9b 35. You can zero out the signature in the message below and calculate the signature. The key, in case of NTLM is exported session key as described in MS-NLMP and MS-SMB2 section “3.3.5.5.3 Handling GSS-API Authentication”

    FE 53 4D 42 40 00 01 00 00 00 00 00 01 00 01 00

    09 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00

    FF FE 00 00 00 00 00 00 31 00 00 80 07 04 00 00

    45 5C C0 52 51 2A 77 48 50 87 28 32 3A CC DF 21 ß--------- Signature

    09 00 00 00 48 00 1D 00 A1 1B 30 19 A0 03 0A 01

    00 A3 12 04 10 01 00 00 00 30 AA 07 17 53 EB 17

    CB 00 00 00 00

    If you need the network trace from which I got the above message, please send an email to dochelp at Microsoft dot com to my attention.


    Regards, Obaid Farooqi

    Tuesday, December 11, 2012 7:26 PM
    Owner

All replies

  • Hi Shishir.Saha,

    Thank you for your question.  A colleague will contact you soon to investigate this issue.

    Regards,

    Mark Miller | Escalation Engineer | Open Specifications Team

    Monday, November 26, 2012 9:09 PM
  • Hi Mark Miller,

    Thanks for your reply.

    Look forward to hear the investigation result from your colleague.

    Regards,

    Shishir

    Wednesday, November 28, 2012 7:45 AM
  • Hi Shishir:

    I verified and the document is correct. Here is how I did it.

    RandomSessionKey = 0x55555555555555555555555555555555

    Null terminated string "session key to client-to-server signing key magic constant" = 0x73657373696F6E206B657920746F20636C69656E742D746F2D736572766572207369676E696E67206B6579206D6167696320636F6E7374616E7400

    Concatenated String= 0x5555555555555555555555555555555573657373696F6E206B657920746F20636C69656E742D746F2D736572766572207369676E696E67206B6579206D6167696320636F6E7374616E7400

    And when I calculate MD5 hash of the above, I get

    0x4788DC861B4782F35D43FD98FE1A2D39

    Same as in the document MS-NLMP.

    Please let me know if this does not answer your question.


    Regards, Obaid Farooqi

    Wednesday, November 28, 2012 9:26 PM
    Owner
  • Hi Obaid Farooqi,

    Thanks for your reply. I was wrong with "null terminated string". It might be more understandable to reader as “session key to client-to-server signing key magic constant\0” instead of “session key to client-to-server signing key magic constant”OR indicate that in document page as null terminated string. However, Thanks a lot for your answer.

    Regards,

    Shishir


    shishir

    Thursday, November 29, 2012 7:58 AM
  • Hi Shishir:

    The document MS-NLMP actually mentions that it is a null terminated sting. In section "3.4.5.2 SIGNKEY" it is stated that:

    "

    ....

    If extended session security is negotiated, the signing key is a 128-bit value that is calculated as
    follows from the random session key and the null-terminated ASCII constants shown.

    ...

    "


    Regards, Obaid Farooqi

    Thursday, November 29, 2012 8:41 PM
    Owner
  • Hi Obaid Farooqi,

    Nice to see that! Thanks for your indication.

    One more thing, in Section 4.2.4.4, the Checksum is calculated as -

    Checksum: RC4(Checksum above):        output: 0x7fb38ec5c55d4976

     

    I try to generate it by the following way -

    Set NTLMSSP_MESSAGE_SIGNATURE.Checksum to RC4(Handle, HMAC_MD5(SigningKey, ConcatenationOf(SeqNum, Message))[0..7]) [Section 3.4.4.2]

     

    Setp1:

    RC4Init(H, K) [Section 6] Initiate State with SealKey()

    K = SEALKEY(); i.e., 0x59f600973cc4960a25480a7c196e4c58

     

    Step2:

    RC4(H, D)

    D = 0x50006c00610069006e007400650078007400; (P.l.a.i.n.t.e.x.t.)

    Get result: 0x54e50165bf1936dc996020c1811b0f06fb5f

     

    Step3:

    RC4(H, D) [Without changing the RC4Init State]

    D = Checksum: HMAC_MD5(SigningKey, ConcatenationOf(SeqNum, Message))[0..7]; i.e., 0x70352851f2564309

     

    But I get the result: 0x1E188257B487BFA0 instead of 0x7fb38ec5c55d4976

     

    Can you please help me and tell where am I doing wrong?

     

    Regards,

    Shishir

    shishir

    Friday, November 30, 2012 3:07 PM
  • Hi Shishir:

    I will look into that and update you as soon as I have an answer.


    Regards, Obaid Farooqi

    Friday, November 30, 2012 4:11 PM
    Owner
  • Hi Shishir:

    I was able to generate the same value as the document shows.

    Are you using the same handle that you use to encrypt the data (Pliantext)? As mentioned in section 3.4.4.2, the handle is "... to key state structure corresponding to the current state of the SealingKey".

    Please let me know if this does not resolve your problem.


    Regards, Obaid Farooqi

    Monday, December 3, 2012 4:51 PM
    Owner

  • Hi Obaid Farooqi,

    Thanks a lot for your help. It’s now working great with me too :)

    Actually, I am trying to learn and implement SMB2 Server. I try to send the response “SessionSetup Response, Unknown message type” to receive request “TreeConnect Request Tree: \\X.X.X.X\IPC$” from client side. I get the sessionKey: bbb63fa9a6d6ad200190381e28542fc1 (RandomSessionKey) & flags: 0xe2888215 (ntlmv2, ssp response) from client request “SessionSetup Request, NTLMSSP_AUTH, User: domain\shishir, Unknown message type”.

     

    I try to generate the mechListMIC for “SessionSetup Response, Unknown message type” by sealKey(MD5(ConcatenationOf(RandomSessionKey, "session key to server-to-client sealing key magic constant")) e.g., 0x4F0C4D3A2983A1B13CAF5320617563B7) & signKey(MD5(ConcatenationOf(RandomSessionKey, "session key to server-to-client signing key magic constant")) e.g., 0x68B11D04CE22C88316B5746A72663A23). I use version = 1 & sequence = 0. I also use ‘message’ as unicoded bytes of “P.l.a.i.n.t.e.x.t.” to generate the mechListMIC. But I am not able to receive the TreeConnect request from client, as response of SessionSetup that I generate. My question is -

    1. Whether the ‘message’ would be “P.l.a.i.n.t.e.x.t.” to generate the mechListMIC of “SessionSetup Response, Unknown message type” or else? If else, please give me an example.
    2. In SMB2 header [in section 2.2.6 & 2.2.1.2], the Signature (16 bytes) for “Session Setup Response” if SMB2_FLAGS_SIGNED. To generate the signature [in section 3.1.4.1], what would be the message inside HMAC-SHA256 (sessionKey, message)? An example of 'message' would be helpful.

     

    Please let me know if you need to know further details.

     

      

    Regards,

    Shishir

    shishir

    Wednesday, December 5, 2012 10:07 AM
  • Hi Shishir:

    I'll look into this and get back to you as soon as I have an answer.


    Regards, Obaid Farooqi

    Thursday, December 6, 2012 8:29 PM
    Owner
  • Hi Shishir:

    Please find the answers to your questions in Q&A format as follows:

    Q1. Whether the ‘message’ would be “P.l.a.i.n.t.e.x.t.” to generate the mechListMIC of “SessionSetup Response, Unknown message type” or else? If else, please give me an example.

    A. mechListMIC stands for “Mechanism List Message integrity code”. It is used to verify the mechanisms that client sent in the first SPNEGO message. If you look at your message trace, mechanisms (MechTypes) are in the securityBlob of first session setup request. I am pasting an example from a netmon network trace:

      Frame: Number = 3, Captured Frame Length = 220, MediaType = ETHERNET

    + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-4B-30-04],SourceAddress:[00-15-5D-4B-30-23]

    + Ipv4: Src = 10.1.1.205, Dest = 10.1.1.201, Next Protocol = TCP, Packet ID = 259, Total IP Length = 206

    + Tcp: Flags=...AP..., SrcPort=49169, DstPort=Microsoft-DS(445), PayloadLen=166, Seq=3047701357 - 3047701523, Ack=2750414017, Win=511

    + SMBOverTCP: Length = 162

    - SMB2: C   SESSION SETUP (0x1)

        SMBIdentifier: SMB

      + SMB2Header: C SESSION SETUP (0x1),TID=0x0000, MID=0x0002, PID=0xFEFF, SID=0x0000

      - CSessionSetup:

         StructureSize: 25 (0x19)

         VcNumber: 0 (0x0)

       + SecurityMode: 2 (0x2)

       + Capabilities: 0x1

         Channel: 0 (0x0)

         SecurityBufferOffset: 88 (0x58)

         SecurityBufferLength: 74 (0x4A)

         PreviousSessionId: 0 (0x0)

       - securityBlob:

        - GSSAPI:

         - InitialContextToken:

          + ApplicationHeader:

          + ThisMech: SpnegoToken (1.3.6.1.5.5.2)

          - InnerContextToken: 0x1

           - SpnegoToken: 0x1

            + ChoiceTag:

            - NegTokenInit:

             + SequenceHeader:

             + Tag0:

             + MechTypes: Prefer NLMP (1.3.6.1.4.1.311.2.2.10)

             + Tag2:

             + OctetStringHeader:

             + MechToken: NTLM NEGOTIATE MESSAGE

    The little endian representation that you would see in the hex detail window in netmon is 30 0c 06 0a 2b 06 01 04-01 82 37 02 02 0a. This value is used as the message to generate mechListMIC by the client. Client sends this with Authenticate message.

    On receipt of this, server verifies it against what server received as the list of mechanism from client. If the verification passes, server generates its own mechListMIC and sends it to client in the final session setup response. The server also uses the same message (30 0c 06 0a 2b 06 01 04-01 82 37 02 02 0a). The client verifies it on the receipt.

    More information about MechListMIC can be had from RFC4178 (http://www.ietf.org/rfc/rfc4178.txt ) and MS-SPNG (http://msdn.microsoft.com/en-us/library/cc247021(v=prot.20).aspx )

    Q2. In SMB2 header [in section 2.2.6 & 2.2.1.2], the Signature (16 bytes) for “Session Setup Response” if SMB2_FLAGS_SIGNED. To generate the signature [in section 3.1.4.1], what would be the message inside HMAC-SHA256 (sessionKey, message)? An example of 'message' would be helpful.

    A. The input message is the whole SMB2 message. I am pasting an example below. The message is final session setup response. The session key is 4f a0 2b ee bb cd ec 62 a6 eb 90 77 ad fc 9b 35. You can zero out the signature in the message below and calculate the signature. The key, in case of NTLM is exported session key as described in MS-NLMP and MS-SMB2 section “3.3.5.5.3 Handling GSS-API Authentication”

    FE 53 4D 42 40 00 01 00 00 00 00 00 01 00 01 00

    09 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00

    FF FE 00 00 00 00 00 00 31 00 00 80 07 04 00 00

    45 5C C0 52 51 2A 77 48 50 87 28 32 3A CC DF 21 ß--------- Signature

    09 00 00 00 48 00 1D 00 A1 1B 30 19 A0 03 0A 01

    00 A3 12 04 10 01 00 00 00 30 AA 07 17 53 EB 17

    CB 00 00 00 00

    If you need the network trace from which I got the above message, please send an email to dochelp at Microsoft dot com to my attention.


    Regards, Obaid Farooqi

    Tuesday, December 11, 2012 7:26 PM
    Owner
  • Hi Obaid Farooqi,

    Thanks a lot for your insightful and meaningful answers.

    Now everything is looking very good and understandable to me.

     

    Thanks for your co-operation.

     

     

    Regards,

    Shishir

    shishir

    Wednesday, December 19, 2012 7:44 AM