dcsimg
Results 1 to 5 of 5

Thread: Vb6 - hkdf

  1. #1

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    595

    Vb6 - hkdf

    The PRF (Pseudo Random Function) for TLS 1.2 was different from the PRF for TLS 1.0, and yet again it is different for TLS 1.3. As a matter of fact, it is no longer called a PRF; it is called an HKDF (HMAC-based Extract-and-Expand Key Derivation Function). Although similar to the previous Pseudo Random Functions, it is simpler and more general purpose. Being simpler means that one should be somewhat more careful in it's usage, and potential users would be well advised to read the following:
    https://tools.ietf.org/html/rfc5869
    Unlike most RFC documents it is relatively easy to follow in general terms, but I experienced a number of gotchas that were difficult to troubleshoot in implementing it.

    There are 2 main functions; Extract and Expand. Extract produces a key(secret) from the Input Key Material (IKM) and a salt. In TLS 1.3, the key material is the ECDHE (Elliptical Curve Diffie-Hellman Ephemeral) key, and the salt is optional though highly recommended. It produces a key called the PRK (Pseudo Random Key), which is the length of the Hash algorithm used (32 for SHA256). The PRK is then used to create the necessary keying material needed for the encryption process by calling the Expand function.

    The HMAC process I used for the TLS 1.2 PRF was very specific to that function, so the first step was to produce a more general purpose HMAC (Hash-based Message Authentication Code) routine. This is all that is necessary to produce the PRK. The PRK along with an optional Info byte string are then used cyclically as many times as is necessary to produce the Output Keying Material (OKM) needed.

    RFC5869 contains 7 sample Test Vectors, of which I have implemented 6 (number 7 had already been tested in 2). There wasn't a lot of information available for SHA384/SHA512, and Test 7 uses SHA512. To get the expected value for the PRK, I used the following page:
    https://www.liavaag.org/English/SHA-Generator/HMAC/

    J.A. Coutts
    Attached Images Attached Images  
    Attached Files Attached Files

  2. #2

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    595

    Re: Vb6 - hkdf

    Attached is an updated version of the HKDF Demo. Two more tests have been added that demonstrate the key generation process used by TLS 1.3 according to the examples given by:
    https://tlswg.github.io/draft-ietf-t...3-vectors.html

    Although TLS 1.3 has simplified the general process and eliminated many needless functions, the same cannot be said for key generation. It is very convoluted and difficult to work with. TLS 1.3 does away with the MAC key, but adds a Handshake key and Handshake IV (Initialization Vector). Unlike the previous TLS versions which created a Master Key from a Pre-Master Key, and then expanded it to create a key block from which the various keys could be extracted, TLS 1.3 creates the keys using separate "Expand" functions. The general principle is that a secret is "Extracted" using a key and a Salt. That secret is then used along with context to derive another secret. That derived secret is then combined with a key (such as the ECDHE key) to produce a PRK (Pseudo Random Key), which is then expanded to the individual encryption keys and IV's.

    The Client and Server Randoms are still there, but do not appear to be used for their original purpose. I believe they are only there to be compatible with previous versions. The extensions are used to a much greater extent, including the transmission of the Public ECDHE key.

    As I mentioned earlier, there is no MAC key. That is because the ciphers used are all AEAD (Authenticated Encryption with Associated Data). AES-128-GCM combines the Write IV with the Sequence Number into the Nonce, and the Nonce is used in the production of the encrypted value. This process ensures that the Nonce is never duplicated, which is a requirement of AES-GCM. Doing this allows the AES block cipher to be used much like a Stream cipher, which produces an encrypted value that is the same length as the input value.

    The "Finished" value shown in the TLS tests are not the same as the ones sent to the other end. I believe that the "tls13 finished" value is encrypted with the Handshake keys, but after spending a lot of effort to duplicate the "AES_128_GCM" process, I have not been able to duplicate the final "Finished" value. The same goes for the hash used in the creation of the Application keys.

    Also added to the program was an AES-128-CGM encryption test of the Finished value. From all the information I could gather, I assumed that the Finished record was encrypted with the Handshake keys. Unfortunately, I was not able to duplicate the example results. Repeating the test causes a different answer each time because of the incrementing of the Send Sequence Number.

    Because of the requirement to Xor the Handshake IV with the Sequence Number, the Sequence Numbers were changed from 3 long values to byte arrays the same length as the IV (12). This necessitated upgrading of the Increment routines.

    J.A. Coutts
    Attached Files Attached Files
    Last edited by couttsj; Sep 10th, 2018 at 10:20 AM.

  3. #3

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    595

    Re: Vb6 - hkdf

    The unknown third hash has been resolved. It is the Session Hash including the Client Hello, the Server Hello, and the Certificate Data combined with the Server Finished record (unencrypted). The HKDF2 attachment has been updated to reflect this information.

    Now there is only one mystery left to solve. What did they do to the Server Finished record?

    J.A. Coutts

  4. #4

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    595

    Re: Vb6 - hkdf

    The HKDF2.zip file has been modified again, adding an AES-128-CGM encryption/decryption test of the Client Finished message. However many times the Encrypt button is clicked, the same number of clicks on the Decrypt button will restore the original unencrypted value. This is accomplished using a single encryption/decryption routine with a flag to differentiate.

    J.A. Coutts

  5. #5

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    595

    Re: Vb6 - hkdf

    I finally figured out what they did with the "Finished" record. It is "Extracted" (ie. HMAC) using the current Session Hash. Even though the Encrypted Extensions, Certificate, Certificate Verify & Finished records are all sent by the Server at the same time as one record, the Session Hash appears to be updated independently. So the Session Hash used to create the "Finished" message from the "tls13 finished" does not include the Finished record itself.

    I have not updated the HKDF2.zip record as it really doesn't impact the key production in the demo itself.

    J.A. Coutts

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width