none
[MS-RDPBCGR] Page 349, current session key? RRS feed

  • Question

  • On section 5.3.7.1 Session Key Updates / Non-FIPS, how is the current session key calculated?
    When the session key is updated , how is this information conveyed to the server?
    Shouldn't there be a key exchange between the client and the server?

    Thank You,
    Amancio Hasty
    Tuesday, October 14, 2008 11:28 PM

Answers

  •  

       Hello Bill,
         The [MS-RDPBCGR]  document is having some significant changes made to it that will be available in a future public release of the document. Some of these changes are being made to the section that you have questions about, 5.3.7.1 Session Key Updates / Non-Fips.  This section will read something very similar to if not exactly as the following:

    5.3.7   Session Key Updates
    During the course of a session, the symmetric encryption and decryption keys may need to be refreshed.

    5.3.7.1   Non-FIPS
    The encryption and the decryption keys are updated after 4096 packets have been sent or received. The input and output streams are considered separate for the purposes of counting packets.

    Generating an updated  session key requires:

    1. The initial session keys (generated as described in section 5.3.5).
    2. The current session keys (if no update has been performed, the current and initial session keys will be identical).
    3. Knowledge of the RC4 key length (computed using  Table 1  and  the negotiated key length).

    The following sequence of steps shows how  updated client and server encryption keys are generated (the same steps are used to update the client and server decryption keys). The following padding constants are used.
                   
    Pad1 = 0x36 repeated 40 times to give 320 bits
    Pad2 = 0x5C repeated 48 times to give 384 bits

    If the negotiated key strength is 128-bit, then the full 128 bits of the initial and current encryption keys will be used.

                 InitialEncryptKey = InitialEncryptKey128

                CurrentEncryptKey = CurrentEncryptKey128

    If the negotiated key strength is 40-bit or 56-bit, then the first 64 bits of the initial  and  current encryption keys will be used.

                   InitialEncryptKey = First64Bits(InitialEncryptKeyN)
                  CurrentEncryptKey = First64Bits(CurrentEncryptKeyN)

                 InitialEncryptKeyN is either InitialEncryptKey40 or InitialEncryptKey56, depending
                on the negotiated key strength, while CurrentEncryptKeyN is either CurrentEncryptKey40
                or CurrentEncryptKey56, depending on the negotiated key strength.

    The initial and current keys are concatenated and hashed together with padding to form a temporary  key as follows.

                 SHAComponent = SHA(InitialEncryptKey + Pad1 + CurrentEncryptKey)
                TempKey128 = MD5(InitialEncryptKey + Pad2 + SHAComponent)

    If the key strength is 128 bits, then the temporary  key (TempKey128) is used to reinitialize the associated RC4 substitution table (for more information on RC4 substitution table initialization, see [APPLIED-CRYPTO] section 17.1)
    .
             S-TableEncrypt = InitRC4(TempKey128)

     RC4 is then used to encrypt TempKey128 to obtain the new 128-bit encryption key.

           NewEncryptKey128 = RC4(TempKey128, S-TableEncrypt)

    Finally, the associated RC4 substitution table is reinitialized with the new encryption key (NewEncryptKey128) which can then be used to encrypt a further 4096 packets.

            S-Table = InitRC4(NewEncryptKey128)

    If 40-bit or 56-bit keys are being used, then the first 64 bits of the temporary  key (TempKey128) are used to reinitialize the associated RC4 substitution table.

          TempKey64 = First64Bits(TempKey128)
          S-TableEncrypt = InitRC4(TempKey64)

    RC4 is then used to encrypt these 64 bits and the first few bytes are salted according to the key strength to derive a new 40 or 56-bit  encryption key (see section 5.3.5.1 for details on how to perform the salting operation).

          PreSaltKey = RC4(TempKey64, S-TableEncrypt)

         NewEncryptKey40 = 0xD1269E + Last40Bits(PreSaltKey)
         NewEncryptKey56 = 0xD1 + Last56Bits(PreSaltKey)


    Finally, the new 40-bit or 56-bit  encryption key (NewEncryptKey40 or NewEncryptKey56) is used to reinitialize the associated RC4 substitution table.

    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

    There are also changes being made to section section 5.3.5.1 which is referenced above and also includes Table 1.
    This section will read something very similar to if not exactly as the following:

    5.3.5.1   Non-FIPS
    The client and server random values are used to create a 384-bit Pre-Master Secret by concatenating the first 192 bits of the Client Random with the first 192 bits of the Server Random
    .
    PreMasterSecret = First192Bits(ClientRandom) + First192Bits(ServerRandom)

    A 384-bit Master Secret is generated using the Pre-Master Secret, the client and server random values, and the MD5 and SHA-1 hash functions.

    SaltedHash(S, I) = MD5(S + SHA(I + S + ClientRandom + ServerRandom))
    PreMasterHash(I) = SaltedHash(PremasterSecret, I)

    MasterSecret = PreMasterHash('A') + PreMasterHash('BB') + PreMasterHash('CCC')
    A 384-bit session key BLOB is generated as follows.

    MasterHash(I) = SaltedHash(MasterSecret, I)
    SessionKeyBlob = MasterHash('X') + MasterHash('YY') + MasterHash('ZZZ')

    From the session key BLOB the actual session keys which will be used are derived. Both client and server extract the same key data for generating MAC signatures.

    MACKey128 = First128Bits(SessionKeyBlob)

    The initial encryption and decryption keys are generated next (these keys are updated at a later point in the protocol, per section 5.3.6.1). The server generates its encryption and decryption keys as follows.

    FinalHash(K) = MD5(K + ClientRandom + ServerRandom)

    InitialServerEncryptKey128 = FinalHash(Second128Bits(SessionKeyBlob))
    InitialServerDecryptKey128 = FinalHash(Third128Bits(SessionKeyBlob))

    The client constructs its initial decryption key with the bytes that the server uses to construct its initial encryption key. Similarly, the client forms its initial encryption key with the bytes that the server uses to form its initial decryption key.

    InitialClientDecryptKey128 = FinalHash(Second128Bits(SessionKeyBlob))
    InitialClientEncryptKey128 = FinalHash(Third128Bits(SessionKeyBlob))

    This means that the client will use its encryption key to encrypt data and the server will use its decryption key to decrypt the same data. Similarly, the server will use its encryption key to encrypt data and the client will use its decryption key to decrypt the same data. In effect, there are two streams of data (client-to-server and server-to-client) encrypted with different session keys which are updated at different intervals.

    To reduce the entropy of the keys to either 40 or 56 bits, the 128-bit client and server keys are salted appropriately to produce 64-bit versions with the required strength. The salt values to reduce key entropy are a shown in the following table (Table 1):.

    Negotiated key length                   Salt length              Salt values                RC4 key length
            40 bits                                      3 bytes              0xD1, 0x26, 0x9E               8 bytes
            56 bits                                      1 byte                       0xD1                            8 bytes
          128 bits                                       0 bytes                     N/A                             16 bytes

    Table 1: Salt values to reduce key entropy


    Using the salt values, the 40-bit keys are generated as follows.

    MACKey40 = 0xD1269E + Last40Bits(First64Bits(MACKey128))

    InitialServerEncryptKey40 = 0xD1269E + Last40Bits(First64Bits(InitialServerEncryptKey128))
    InitialServerDecryptKey40 = 0xD1269E + Last40Bits(First64Bits(InitialServerDecryptKey128))

    InitialClientEncryptKey40 = 0xD1269E + Last40Bits(First64Bits(InitialClientEncryptKey128))
    InitialClientDecryptKey40 = 0xD1269E + Last40Bits(First64Bits(InitialClientDecryptKey128))

    The 56-bit keys are generated as follows:

    MACKey56 = 0xD1 + Last56Bits(First64Bits(MACKey128))

    InitialServerEncryptKey56 = 0xD1 + Last56Bits(First64Bits(InitialServerEncryptKey128))
    InitialServerDecryptKey56 = 0xD1 + Last56Bits(First64Bits(InitialServerDecryptKey128))

    InitialClientEncryptKey56 = 0xD1 + Last56Bits(First64Bits(InitialClientEncryptKey128))
    InitialClientDecryptKey56 = 0xD1 + Last56Bits(First64Bits(InitialClientDecryptKey128))

    After any necessary salting has been applied, the generated encryption and decryption keys are used to initialize RC-4 substitution tables which can then be used to encrypt and decrypt data.

    At the end of this process the client and server will each possess three symmetric keys to use with the RC4 stream cipher: a MAC key, an encryption key, and a decryption key. The MAC key is used to initialize the RC4 substitution table that is used table to generate message authentication codes, the encryption key is used to initialize the RC4 substitution table that is used to performing encryption, and the decryption key is used to initialize the RC4 substitution table that is used to for perform decryption (for more information on RC4 substitution table initialization, see [APPLIED-CRYPTO] section 17.1).

    ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

    The reference which is found in both sections 5.3.7.1 and 5.3.5.1, [APPLIED-CRYPTO] section 17.1), is included in section 1.2.1 Normative References as follows.

    [APPLIED-CRYPTO] Schneier, B., "Applied Cryptography" Wiley, 1996, ISBN-10: 0471117099, ISBN-13: 978-0471117094

    Thanks
    John Dunning
    Senior Escalation Engineer Microsoft Corporation
    US-CSS DSC PROTOCOL TEAM

    Friday, December 12, 2008 4:45 PM

All replies

  • Good morning Amancio. I have alerted our Protocols Support team concerning your questions about [MS-RDPBCGR]. One of our team members will be in contact with you soon.

    Thanks for your questions!

    Regards,
    Bill Wesse


    Escalation Engineer
    Wednesday, October 15, 2008 12:37 PM
  •  Hello Amancio,
       I wanted to let you know that I will be assisting you with your post. I will review your question and update the forum once that investigation is complete.

    Thanks
    John Dunning
    Escalation Engineer Microsoft Corporation
    US-CSS DSC PROTOCOL TEAM

    Wednesday, October 15, 2008 3:35 PM
  •  Hello Amancio,
       I have concluded my research and have answers to your questions regarding the {RDPBGCR] document.

    1) On section 5.3.7.1 Session Key Updates / Non-FIPS, how is the current session key calculated?

    Answer: The current session key is the session key currently being used. The initial session key is the first (or initial) session key generated. There is no distinction in how these keys are generated. Key generation is described in [RDBGCR] Section 5.3.5 Session Key Generation.

    2) When the session key is updated , how is this information conveyed to the server?

    Answer: The server also updates it's key after 4096 packets, so there is no need for a notification as both client and server use the same protocol.

    3) Shouldn't there be a key exchange between the client and the server?

    Answer: No, based on the same reasons for the answer to question #2.


       Please let me know if this doesn't completely answer these questions to your satisfaction.


    Thanks
    John Dunning
    Senior Escalation Engineer Microsoft Corporation
    US-CSS DSC PROTOCOL TEAM

    Monday, November 3, 2008 8:31 PM
  • Thanks a lot.

    It helps. But I have furture question.

    After I got the temporary session key (EncrypotKey128T), then RC4 is used to encrypt the temporary key to obtain the new encrypt key(according to section 5.3.7 Session Key Updates of Spec MS-RDPBCGR). How to do that?

    If the key strength is 128 bits, is the temporary key (EncrypotKey128T) the new encrypt key? If they are different, what is the calculation?

    If the key strength is 40-bit or 56-bit, what is the calculation?

    Thanks,
    Bill
    Thursday, November 13, 2008 3:28 AM
  • Hello Bill,
       I will be looking into this question for you. I will let you know as soon as I have an answer.

    Thanks
    John Dunning
    Senior Escalation Engineer Microsoft Corporation
    US-CSS DSC PROTOCOL TEAM
    Thursday, November 13, 2008 4:43 PM
  •  

       Hello Bill,
         The [MS-RDPBCGR]  document is having some significant changes made to it that will be available in a future public release of the document. Some of these changes are being made to the section that you have questions about, 5.3.7.1 Session Key Updates / Non-Fips.  This section will read something very similar to if not exactly as the following:

    5.3.7   Session Key Updates
    During the course of a session, the symmetric encryption and decryption keys may need to be refreshed.

    5.3.7.1   Non-FIPS
    The encryption and the decryption keys are updated after 4096 packets have been sent or received. The input and output streams are considered separate for the purposes of counting packets.

    Generating an updated  session key requires:

    1. The initial session keys (generated as described in section 5.3.5).
    2. The current session keys (if no update has been performed, the current and initial session keys will be identical).
    3. Knowledge of the RC4 key length (computed using  Table 1  and  the negotiated key length).

    The following sequence of steps shows how  updated client and server encryption keys are generated (the same steps are used to update the client and server decryption keys). The following padding constants are used.
                   
    Pad1 = 0x36 repeated 40 times to give 320 bits
    Pad2 = 0x5C repeated 48 times to give 384 bits

    If the negotiated key strength is 128-bit, then the full 128 bits of the initial and current encryption keys will be used.

                 InitialEncryptKey = InitialEncryptKey128

                CurrentEncryptKey = CurrentEncryptKey128

    If the negotiated key strength is 40-bit or 56-bit, then the first 64 bits of the initial  and  current encryption keys will be used.

                   InitialEncryptKey = First64Bits(InitialEncryptKeyN)
                  CurrentEncryptKey = First64Bits(CurrentEncryptKeyN)

                 InitialEncryptKeyN is either InitialEncryptKey40 or InitialEncryptKey56, depending
                on the negotiated key strength, while CurrentEncryptKeyN is either CurrentEncryptKey40
                or CurrentEncryptKey56, depending on the negotiated key strength.

    The initial and current keys are concatenated and hashed together with padding to form a temporary  key as follows.

                 SHAComponent = SHA(InitialEncryptKey + Pad1 + CurrentEncryptKey)
                TempKey128 = MD5(InitialEncryptKey + Pad2 + SHAComponent)

    If the key strength is 128 bits, then the temporary  key (TempKey128) is used to reinitialize the associated RC4 substitution table (for more information on RC4 substitution table initialization, see [APPLIED-CRYPTO] section 17.1)
    .
             S-TableEncrypt = InitRC4(TempKey128)

     RC4 is then used to encrypt TempKey128 to obtain the new 128-bit encryption key.

           NewEncryptKey128 = RC4(TempKey128, S-TableEncrypt)

    Finally, the associated RC4 substitution table is reinitialized with the new encryption key (NewEncryptKey128) which can then be used to encrypt a further 4096 packets.

            S-Table = InitRC4(NewEncryptKey128)

    If 40-bit or 56-bit keys are being used, then the first 64 bits of the temporary  key (TempKey128) are used to reinitialize the associated RC4 substitution table.

          TempKey64 = First64Bits(TempKey128)
          S-TableEncrypt = InitRC4(TempKey64)

    RC4 is then used to encrypt these 64 bits and the first few bytes are salted according to the key strength to derive a new 40 or 56-bit  encryption key (see section 5.3.5.1 for details on how to perform the salting operation).

          PreSaltKey = RC4(TempKey64, S-TableEncrypt)

         NewEncryptKey40 = 0xD1269E + Last40Bits(PreSaltKey)
         NewEncryptKey56 = 0xD1 + Last56Bits(PreSaltKey)


    Finally, the new 40-bit or 56-bit  encryption key (NewEncryptKey40 or NewEncryptKey56) is used to reinitialize the associated RC4 substitution table.

    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

    There are also changes being made to section section 5.3.5.1 which is referenced above and also includes Table 1.
    This section will read something very similar to if not exactly as the following:

    5.3.5.1   Non-FIPS
    The client and server random values are used to create a 384-bit Pre-Master Secret by concatenating the first 192 bits of the Client Random with the first 192 bits of the Server Random
    .
    PreMasterSecret = First192Bits(ClientRandom) + First192Bits(ServerRandom)

    A 384-bit Master Secret is generated using the Pre-Master Secret, the client and server random values, and the MD5 and SHA-1 hash functions.

    SaltedHash(S, I) = MD5(S + SHA(I + S + ClientRandom + ServerRandom))
    PreMasterHash(I) = SaltedHash(PremasterSecret, I)

    MasterSecret = PreMasterHash('A') + PreMasterHash('BB') + PreMasterHash('CCC')
    A 384-bit session key BLOB is generated as follows.

    MasterHash(I) = SaltedHash(MasterSecret, I)
    SessionKeyBlob = MasterHash('X') + MasterHash('YY') + MasterHash('ZZZ')

    From the session key BLOB the actual session keys which will be used are derived. Both client and server extract the same key data for generating MAC signatures.

    MACKey128 = First128Bits(SessionKeyBlob)

    The initial encryption and decryption keys are generated next (these keys are updated at a later point in the protocol, per section 5.3.6.1). The server generates its encryption and decryption keys as follows.

    FinalHash(K) = MD5(K + ClientRandom + ServerRandom)

    InitialServerEncryptKey128 = FinalHash(Second128Bits(SessionKeyBlob))
    InitialServerDecryptKey128 = FinalHash(Third128Bits(SessionKeyBlob))

    The client constructs its initial decryption key with the bytes that the server uses to construct its initial encryption key. Similarly, the client forms its initial encryption key with the bytes that the server uses to form its initial decryption key.

    InitialClientDecryptKey128 = FinalHash(Second128Bits(SessionKeyBlob))
    InitialClientEncryptKey128 = FinalHash(Third128Bits(SessionKeyBlob))

    This means that the client will use its encryption key to encrypt data and the server will use its decryption key to decrypt the same data. Similarly, the server will use its encryption key to encrypt data and the client will use its decryption key to decrypt the same data. In effect, there are two streams of data (client-to-server and server-to-client) encrypted with different session keys which are updated at different intervals.

    To reduce the entropy of the keys to either 40 or 56 bits, the 128-bit client and server keys are salted appropriately to produce 64-bit versions with the required strength. The salt values to reduce key entropy are a shown in the following table (Table 1):.

    Negotiated key length                   Salt length              Salt values                RC4 key length
            40 bits                                      3 bytes              0xD1, 0x26, 0x9E               8 bytes
            56 bits                                      1 byte                       0xD1                            8 bytes
          128 bits                                       0 bytes                     N/A                             16 bytes

    Table 1: Salt values to reduce key entropy


    Using the salt values, the 40-bit keys are generated as follows.

    MACKey40 = 0xD1269E + Last40Bits(First64Bits(MACKey128))

    InitialServerEncryptKey40 = 0xD1269E + Last40Bits(First64Bits(InitialServerEncryptKey128))
    InitialServerDecryptKey40 = 0xD1269E + Last40Bits(First64Bits(InitialServerDecryptKey128))

    InitialClientEncryptKey40 = 0xD1269E + Last40Bits(First64Bits(InitialClientEncryptKey128))
    InitialClientDecryptKey40 = 0xD1269E + Last40Bits(First64Bits(InitialClientDecryptKey128))

    The 56-bit keys are generated as follows:

    MACKey56 = 0xD1 + Last56Bits(First64Bits(MACKey128))

    InitialServerEncryptKey56 = 0xD1 + Last56Bits(First64Bits(InitialServerEncryptKey128))
    InitialServerDecryptKey56 = 0xD1 + Last56Bits(First64Bits(InitialServerDecryptKey128))

    InitialClientEncryptKey56 = 0xD1 + Last56Bits(First64Bits(InitialClientEncryptKey128))
    InitialClientDecryptKey56 = 0xD1 + Last56Bits(First64Bits(InitialClientDecryptKey128))

    After any necessary salting has been applied, the generated encryption and decryption keys are used to initialize RC-4 substitution tables which can then be used to encrypt and decrypt data.

    At the end of this process the client and server will each possess three symmetric keys to use with the RC4 stream cipher: a MAC key, an encryption key, and a decryption key. The MAC key is used to initialize the RC4 substitution table that is used table to generate message authentication codes, the encryption key is used to initialize the RC4 substitution table that is used to performing encryption, and the decryption key is used to initialize the RC4 substitution table that is used to for perform decryption (for more information on RC4 substitution table initialization, see [APPLIED-CRYPTO] section 17.1).

    ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

    The reference which is found in both sections 5.3.7.1 and 5.3.5.1, [APPLIED-CRYPTO] section 17.1), is included in section 1.2.1 Normative References as follows.

    [APPLIED-CRYPTO] Schneier, B., "Applied Cryptography" Wiley, 1996, ISBN-10: 0471117099, ISBN-13: 978-0471117094

    Thanks
    John Dunning
    Senior Escalation Engineer Microsoft Corporation
    US-CSS DSC PROTOCOL TEAM

    Friday, December 12, 2008 4:45 PM