Key export callback must contain session specific information

[hanno-becker]

Context: The API

void mbedtls_ssl_conf_export_keys_cb( mbedtls_ssl_config *conf,
        mbedtls_ssl_export_keys_t *f_export_keys,
        void *p_export_keys );

allows to bind a key export callback of type

typedef int mbedtls_ssl_export_keys_t( void *p_expkey,
                                const unsigned char *ms,
                                const unsigned char *kb,
                                size_t maclen,
                                size_t keylen,
                                size_t ivlen );

to an SSL configuration. This callback is to be called for every SSL connection using the SSL configuration whenever the key schedule for that connection has been completed.

Issue: Multiple connections may share the same SSL configuration, and the key export callback doesn't get any information about which SSL context the call relates to.

Concretely, this becomes a problem when trying to create key log files for use with Wireshark, as those need an identifier for the session to be inspected, e.g. in the form of random bytes. An awkward way to work around this currently is to pass the SSL context as (part of) the p_expkey parameter, but this only works as long as there is only one SSL context using the SSL configuration.

Suggestion: Create a new key export API (we cannot remove the current one before 3.0) which either

• passes the SSL context as an additional parameter
• passes the random bytes as an additional parameter
• or both.

[mpg]

@hanno-arm is this issue still relevant or did you create another issue that supersedes this one in the meantime?

[toddwong]

Same question.
Any suggestion?

[hanno-becker]

We've introduced the 'extended' callback since the opening of this issue, which adds the ClientRandom and enables e.g. exporting an NSSKeylogFile (which is also demonstrated in the examples, IIRC).

Looking forward to 3.0, the key export API has been changed again in #4552, addressing #4363, but the principle remains the same: Export a key alongside material which identifies its connection, namely the random bytes. We continue not to pass the SSL context to the key export.

@toddwong Please let us know if any issues remain for you.

[toddwong]

@hanno-arm Thanks for the explaination.
But (maybe a silly question) how should the connection be identified by the random bytes?

[hanno-becker]

It really depends on what you want to do. Suppose, for example, that you're developing a tool like Wireshark which has access to all traces of all connections. Then, given a pair of client random + key, you can do the following: (a) Find the ClientHello which uses the given random value in the flood of messages you've buffered. (b) Lookup and remember the TCP/UDP connection this ClientHello belongs to. (c) Use the provided key to decrypt all encrypted post-handshake traffic on that TCP/UDP connection.

[toddwong]

I'm trying to work out the DTLS-SRTP key derivation

[hanno-becker]

@toddwong We have example code for that, see https://github.com/ARMmbed/mbedtls/blob/development/programs/ssl/ssl_client2.c and https://github.com/ARMmbed/mbedtls/blob/development/programs/ssl/ssl_test_common_source.c#L132.

[toddwong]

I have read the code at

https://github.com/ARMmbed/mbedtls/blob/development/programs/ssl/ssl_server2.c

But I'm not sure if it actually works always. It saves the master_secret/random_bytes/tls_prf_type into a globally share variable, and use that to call mbedtls_ssl_tls_prf later to create the DTLS-SRTP key material.

But what if we have more than one connection at the same time using the same mbedtls_ssl_config?

[toddwong]

Any suggestion?

[hanno-becker]

@toddwong @mpg I come to believe that we should make the callback context-specific, ideally directly as part of the ongoing #4363. @mpg WDYT?

[mpg]

I'm sorry, I haven't had time to look into this so far. I'll come back to you next week (feel free to remind me if I don't).

[hanno-becker]

@toddwong Could you confirm that #4552 solves your problems?

[toddwong]

@hanno-arm Sorry, has been busy these days. I'll try it as soon as I can, maybe on monday or tuesday.

Thanks very much for all of these excellent works!

[hanno-becker]

@toddwong Sure, no worries at all - beginning of next week will be fine!

[toddwong]

@hanno-arm
I'm using cmake under windows. There is some missing-file-errors reported.

library/error.c
library/version_features.c
programs/test/query_config.c

I'm compiling code from https://github.com/hanno-arm/mbedtls/tree/mbedtls_3_0_key_export without any modification

[gilles-peskine-arm]

@toddwong You need to run scripts\make_generated_files.bat or tests/scripts/check-generated-files.sh -u before compiling.

[toddwong]

Unresolved external symbol mbedtls_ssl_set_export_keys_cb, which is referenced in function main

ssl_client2.obj : error LNK2019: 无法解析的外部符号 mbedtls_ssl_set_export_keys_cb，函数 main 中引用了该符号 [D:\oss\mbedtls\build\program
s\ssl\ssl_client2.vcxproj]
D:\oss\mbedtls\build\programs\ssl\Release\ssl_client2.exe : fatal error LNK1120: 1 个无法解析的外部命令 [D:\oss\mbedtls\build\pro
grams\ssl\ssl_client2.vcxproj]

ssl_server2.obj : error LNK2019: 无法解析的外部符号 mbedtls_ssl_set_export_keys_cb，函数 main 中引用了该符号 [D:\oss\mbedtls\build\program
s\ssl\ssl_server2.vcxproj]
D:\oss\mbedtls\build\programs\ssl\Release\ssl_server2.exe : fatal error LNK1120: 1 个无法解析的外部命令 [D:\oss\mbedtls\build\pro
grams\ssl\ssl_server2.vcxproj]

@hanno-arm @gilles-peskine-arm

[toddwong]

@gilles-peskine-arm BTW, scripts\make_generated_files.bat doesn't work out of the box because I'm using visual studio with Chinese language. The cl.exe output is not match Microsoft (R) C/C++ Optimizing Compiler but Microsoft (R) C/C++ 优化编译器

[toddwong]

My bad. I'm trying build shared libraries under Windows, which is not supported.
Everything seems OK after change to building static libraries. And I derived the key materials successfully.
Though my whole project is not working correctly yet, mbedtls_ssl_get_dtls_srtp_negotiation_result return MBEDTLS_TLS_SRTP_UNSET

@hanno-arm @gilles-peskine-arm