Extracting decrypt key for AES from openssl on client side

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Extracting decrypt key for AES from openssl on client side

UserSSL

I have implemented AES 128 encrypt and decrypt functions and tested it with sample data and it checks out perfectly. I used the following reference:https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.197.pdf

Next I implemented a dummy SSL client and SSL server which uses openssl to send and receive data. It is working without any error and the messages are exchanged seamlessly.

My main goal here is to use openssl for initial handshake sequence. Once the connection is established between server and client, decrypt the incoming message (this time not using the openssl api but rather by using the decrypt AES function implemented earlier) and print and similarly for outgoing message. We will focus on incoming messages.

For this of course I will need the decrypt key and IV. I got the decrypt key(read key) on client side like following: (ssl is the SSL* structure of openssl for the established connection, I am accessing the source code structures of openssl directly)

//following struct copied from crypto/evp/e_aes.c
typedef struct {
    union {
        double align;
        AES_KEY ks;
    } ks;
    block128_f block;
    union {
        cbc128_f cbc;
        ctr128_f ctr;
    } stream;
} EVP_AES_KEY;

[Client Side]
EVP_AES_KEY *cipher_data;
cipher_data = EVP_CIPHER_CTX_get_cipher_data(ssl->enc_read_ctx);
cipher_data->ks.ks.rd_key  --> this is the decrypt key

I used this key to decrypt the incoming message with the AES decrypt function but in vain.

Now AES is symmetric encryption so I thought let me check the encrypt(write) key on the server side. The encrypt key on server should be equal to decrypt key on client side. I got the encrypt key on server like following:

[Server Side]
EVP_AES_KEY *cipher_data;
cipher_data = EVP_CIPHER_CTX_get_cipher_data(ssl->enc_write_ctx);
cipher_data->ks.ks.rd_key  --> this is the encrypt key

To my surprise they are different. Now if I use the above encrypt key of server to decrypt the message on the client side. The message is decrypted successfully.(as expected, the key used for encrypting the message is used to decrypt the message in AES standard).

So I reach the following inferences:

  1. The decrypt key which is acquired on the client side is encrypted in some way in openssl?
  2. My method for getting the decrypt key on client side is wrong.

How can I get the decrypt key on the client side which I can use in the AES decryption routine?


--
Best Regards,
Hemant Ranvir

"To live a creative life, we must lose our fear of being wrong." - J.C.Pearce

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Extracting decrypt key for AES from openssl on client side

Viktor Dukhovni


> On Nov 14, 2018, at 6:54 AM, Hemant Ranvir <[hidden email]> wrote:
>
> My main goal here is to use openssl for initial handshake sequence. Once the connection is established between server and client, decrypt the incoming message (this time not using the openssl api but rather by using the decrypt AES function implemented earlier)

This makes no sense, because TLS does not just emit a simple CBC encrypted stream
after performing the handshake.  So you can't do that.  Use SSL_read()/SSL_write,
and let the library do the message decryption/encryption for you.  When done use
SSL_shutdown() to cleanly terminate the stream, and depending on the application
protocol, make wait for the peer's SSL_shutdown() in turn to avoid truncation
attacks where completion of the stream is not implied by the higher level protocol.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Extracting decrypt key for AES from openssl on client side

OpenSSL - User mailing list
I have seen this done for hardware acceleration; where the crypto chip can do everything except the handshake.
(In fact, this mechanism protected at least one device that I know of from the Heartbleed debacle, since the hardware crypto did not understand the record type.)

Look at how the kernel handles TLS, and how the keys are extracted from OpenSSL:


--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."

On Nov 14, 2018, at 11:28 AM, Viktor Dukhovni <[hidden email]> wrote:



On Nov 14, 2018, at 6:54 AM, Hemant Ranvir <[hidden email]> wrote:

My main goal here is to use openssl for initial handshake sequence. Once the connection is established between server and client, decrypt the incoming message (this time not using the openssl api but rather by using the decrypt AES function implemented earlier)

This makes no sense, because TLS does not just emit a simple CBC encrypted stream
after performing the handshake.  So you can't do that.  Use SSL_read()/SSL_write,
and let the library do the message decryption/encryption for you.  When done use
SSL_shutdown() to cleanly terminate the stream, and depending on the application
protocol, make wait for the peer's SSL_shutdown() in turn to avoid truncation
attacks where completion of the stream is not implied by the higher level protocol.

--
Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Extracting decrypt key for AES from openssl on client side

Viktor Dukhovni
> On Nov 15, 2018, at 9:30 AM, Short, Todd via openssl-users <[hidden email]> wrote:
>
> I have seen this done for hardware acceleration; where the crypto chip can do everything except the handshake.
> (In fact, this mechanism protected at least one device that I know of from the Heartbleed debacle, since the hardware crypto did not understand the record type.)
>
> Look at how the kernel handles TLS, and how the keys are extracted from OpenSSL:
>
> https://github.com/torvalds/linux/blob/master/Documentation/networking/tls.txt
> https://github.com/openssl/openssl/pull/5253

Well, it takes more than just extracting a key.  One also needs to know
the cipher mode, and if not AEAD then the MAC algorithm and whether the
EtM extension has been negotiated, and with TLS 1.3 be prepared to
process keyUpdate messages, post handshake session tickets, ...

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Extracting decrypt key for AES from openssl on client side

UserSSL
Hi Todd,
     That is exactly what I am trying to do. The final goal is to implement this in hardware. Anyways I figured out that the key expansion routine is slightly different, more specifically the equivalent inverse cipher routine defined in: https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.197.pdf
     As per this the last 128 bits of the expanded key will be the key that I am looking for. I extracted that and was able to decrypt the message successfully.
     Thanks all the same.

On Fri, Nov 16, 2018 at 12:19 AM Viktor Dukhovni <[hidden email]> wrote:
> On Nov 15, 2018, at 9:30 AM, Short, Todd via openssl-users <[hidden email]> wrote:
>
> I have seen this done for hardware acceleration; where the crypto chip can do everything except the handshake.
> (In fact, this mechanism protected at least one device that I know of from the Heartbleed debacle, since the hardware crypto did not understand the record type.)
>
> Look at how the kernel handles TLS, and how the keys are extracted from OpenSSL:
>
> https://github.com/torvalds/linux/blob/master/Documentation/networking/tls.txt
> https://github.com/openssl/openssl/pull/5253

Well, it takes more than just extracting a key.  One also needs to know
the cipher mode, and if not AEAD then the MAC algorithm and whether the
EtM extension has been negotiated, and with TLS 1.3 be prepared to
process keyUpdate messages, post handshake session tickets, ...

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


--
Best Regards,
Hemant Ranvir

"To live a creative life, we must lose our fear of being wrong." - J.C.Pearce

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users