In my ongoing attempt to implement ECC (Elliptical Curve Cryptography) in TLS 1.2, I have run into a roadblock that I can't seem to get around.
Background:
To use ECDHE (Elliptical Curve Diffie-Hellman Ephemoral), one uses an internally generated Private Key and a Public Key from the other end to create a 32 byte Agreed (or Shared) Secret. This Secret is then combined with the 32 Byte Client Random and 32 byte Server Random to produce a 48 byte Master Secret from which the various Symmetric keys for the exchange are created.
Problem:
CNG (Cryptography Next Generation) is capable of producing the Agreed Secret, but it appears that the only way of recovering it is as a hashed value using:
The second parameter can also be BCRYPT_KDF_HMAC or BCRYPT_KDF_TLS_PRF. BCRYPT_KDF_HMAC is an HMAC Hash, and I have tried using BCRYPT_KDF_TLS_PRF. In theory, it produces a 48 byte variable that should be the Master Secret, but unfortunately it is different value every time I run it with the identical input parameters. To be of any use to TLS, both ends must be able to generate the same Master Secret.
I started all this trying to figure out why I could not connect to a foreign server. RFC5903 provided sample data to verify the key generation. I hashed the Agreed Secret that RFC5903 said I should get, and that hash compared to the results of the call above. So I know that it is calculating the Agreed Secret correctly, but a hash of it however is useless to me. I found where the raw Agreed Secret is stored in memory, but it looks like it has been encrypted. I also located the Private Key and the Public Key in memory, but they also look like they are encrypted in the same manner.
Does anyone know what the operating system uses to encrypt this information?
J.A. Coutts
Background:
To use ECDHE (Elliptical Curve Diffie-Hellman Ephemoral), one uses an internally generated Private Key and a Public Key from the other end to create a 32 byte Agreed (or Shared) Secret. This Secret is then combined with the 32 Byte Client Random and 32 byte Server Random to produce a 48 byte Master Secret from which the various Symmetric keys for the exchange are created.
Problem:
CNG (Cryptography Next Generation) is capable of producing the Agreed Secret, but it appears that the only way of recovering it is as a hashed value using:
Code:
BCryptDeriveKey(hAgreedSecret, StrPtr(BCRYPT_KDF_HASH), VarPtr(ParameterList), VarPtr(bAgreedSecret(0)), cbAgreedSecret, cbAgreedSecret, 0)I started all this trying to figure out why I could not connect to a foreign server. RFC5903 provided sample data to verify the key generation. I hashed the Agreed Secret that RFC5903 said I should get, and that hash compared to the results of the call above. So I know that it is calculating the Agreed Secret correctly, but a hash of it however is useless to me. I found where the raw Agreed Secret is stored in memory, but it looks like it has been encrypted. I also located the Private Key and the Public Key in memory, but they also look like they are encrypted in the same manner.
Does anyone know what the operating system uses to encrypt this information?
J.A. Coutts