Dear All,
I am having multiple queries regarding session resumption and renegotiation.
I understand that normally session resumption is used at every new
connection and session renegotiation is used on live connection.
Our domain standards recommends to use session resumption to change session
key ( or keyblock
key_block = PRF(SecurityParameters.master_secret,
"key expansion",
SecurityParameters.server_random +
SecurityParameters.client_random);
) at regular intervals without closing connection and session renegotiation
to change master key at regular interval using session renegotiation. This
is due to the fact that the connection will be long lasting.
Query 1:
I understand that mbedtls currently does not support session resumption on
live connection. Is there any plan to include it in the near future? ( may
be similar to openssl SSL_renegotiate_abbreviated api)
Query 3:
If the application wants to know if session renegotiation has happened as
part of mbedtls_tls_read and mbedtls_tls_write, is there any callback/API
for that?
--> I am only thinking of using session->start comparison in application to
know if session is renegotiated. Is there any better method?
Query 4:
Our requirement is to understand and log security event in case failure due
to certificate verification fail (revoked/expired etc..) currently we use
mbedtls_ssl_get_verify_result api for same
There is a case when certificate becomes expired/revoked while doing
session renegotiation, mbedtls_ssl_get_verify_result api returns value 0 in
above case
I am thinking in case of session renegotiation, a valid session will always
be available (it will not be NULL in the method below) and session
renegotiation failure information will be available with session_negotiate
pointer instead of session pointer in the below function.
uint32_t mbedtls_ssl_get_verify_result( const mbedtls_ssl_context *ssl )
{
if( ssl->session != NULL )
return( ssl->session->verify_result );
if( ssl->session_negotiate != NULL )
return( ssl->session_negotiate->verify_result );
return( 0xFFFFFFFF );
}
Am I using the right API to get certificate verify_result?
should mbedtls_ssl_get_verify_result api checks give priority to
session_negotiate then session? I think when there is a failure, the result
will always be with session_negotiate, when success session_negotiate
becomes NULL and session_negotiate pointers will be assigned to session
pointers.
uint32_t mbedtls_ssl_get_verify_result( const mbedtls_ssl_context *ssl )
{
if( ssl->session_negotiate != NULL )
return( ssl->session_negotiate->verify_result );
if( ssl->session != NULL )
return( ssl->session->verify_result );
return( 0xFFFFFFFF );
}
Kind request to guide me
Thanks in advance
Regards
Hardik Dave
Yes, there's some kind of "memory magic" going on here:
The task got terminated due to "Load from invalid memory"
and I see:
|Instruction at 0x6310604d is trying to load data at 0x4, which is an
invalid memory area. You are probably dereferencing a NULL pointer.|
|and i got some trace back addresses that point to:|
*
mbedtls_aes_crypt_ecb
*
mbedtls_ctr_drbg_random_with_add
*
mbedtls_ssl_handshake_step
*
mbedtls_ssl_handshake
||
On 2021-06-08 11:43 a.m., Gilles Peskine via mbed-tls wrote:
> Hi Ron,
>
> This behavior can't be explained by the library code and the code you
> posted alone. There has to be something wrong elsewhere.
>
> Check that you aren't exceeding a limitation such as the stack size or
> the size of executable and data sections. If it can be an issue on your
> platform, check that load addresses are correct and sections don't
> overlap. Make sure there's no overlap with any device memory mapping either.
>
> Make sure that the whole binary is compiled with consistent settings.
> The layout of mbedtls_ssl_context can be influenced by the Mbed TLS
> configuration, so make sure that there's a single copy of
> mbedtls/config.h and both Mbed TLS itself and your application were
> built against that copy. The layout of mbedtls_ssl_context can also be
> influenced by compiler settings on some platforms (e.g. structure
> packing options), so make sure those are consistent across your build.
>
> That's all I can think of for now. It may help to add a lot of printf
> debugging with %p on various addresses, and compare these addresses with
> what you know about memory mappings on that platform. Good luck!
>
Hi Ron,
This behavior can't be explained by the library code and the code you
posted alone. There has to be something wrong elsewhere.
Check that you aren't exceeding a limitation such as the stack size or
the size of executable and data sections. If it can be an issue on your
platform, check that load addresses are correct and sections don't
overlap. Make sure there's no overlap with any device memory mapping either.
Make sure that the whole binary is compiled with consistent settings.
The layout of mbedtls_ssl_context can be influenced by the Mbed TLS
configuration, so make sure that there's a single copy of
mbedtls/config.h and both Mbed TLS itself and your application were
built against that copy. The layout of mbedtls_ssl_context can also be
influenced by compiler settings on some platforms (e.g. structure
packing options), so make sure those are consistent across your build.
That's all I can think of for now. It may help to add a lot of printf
debugging with %p on various addresses, and compare these addresses with
what you know about memory mappings on that platform. Good luck!
--
Gilles Peskine
Mbed TLS developer
On 08/06/2021 19:16, Ron Eggler via mbed-tls wrote:
>
> On 2021-06-08 7:40 a.m., Ron Eggler via mbed-tls wrote:
>> On 2021-06-08 12:28 a.m., Gilles Peskine via mbed-tls wrote:
>>> Hi Ron,
>>>
>>> The code you've shown so far only consists of setup functions that
>>> populate fields in the configuration structure, then in the context
>>> structure. Communication has not started yet. mbedtls_ssl_set_bio in
>>> particular is a very simple setter function.
>>>
>>> Where does the code actually hang? Have some messages already been
>>> exchanged on the network at that point? Can you get a stack trace?
>>>
>>> Best regards,
>>>
>> Hi Gilles,
>>
>> Thank you for the response!
>>
>> I've inserted print statements after each of the setup functions and
>> can see that it never gets past mbedtls_ssl_set_bio. The messages
>> that have been exchanged, include the complete bring up and login of
>> the control channel, on the data channel, I call
>> mbedtls_x509_crt_init
>> mbedtls_pk_init
>> mbedtls_entropy_init
>> mbedtls_ctr_drbg_init
>> mbedtls_ssl_init
>> mbedtls_ssl_config_init
>> followed by the certificate and key file got parsing, seeding of the
>> RNG and that's where the previously mentioned procedure with
>> mbedtls_ssl_config_defaults() starts.
>> I unfortunately do not have a debugger available on that platform and
>> hence getting a stack trace won't be so straight forward. Do you have
>> any pointers as to what could be the issue potentially?
>>
>> Thank you,
>>
>> Ron
>
> Okay, I've made some further findings:
>
> I changed the mbedtls_ssl_set_bio funmction so that I inserted a print
> statement on entry and after every set line, like so:
>
> void mbedtls_ssl_set_bio( mbedtls_ssl_context *ssl,
> void *p_bio,
> mbedtls_ssl_send_t *f_send,
> mbedtls_ssl_recv_t *f_recv,
> mbedtls_ssl_recv_timeout_t *f_recv_timeout )
> {
> iprintf("mbedtls_ssl_set_bio::entry\n");
> ssl->p_bio = p_bio;
> iprintf("mbedtls_ssl_set_bio::p_bio set\n");
> ssl->f_send = f_send;
> iprintf("mbedtls_ssl_set_bio::f_send set\n");
> ssl->f_recv = f_recv;
> iprintf("mbedtls_ssl_set_bio::f_recv set\n");
> ssl->f_recv_timeout = f_recv_timeout;
> iprintf("mbedtls_ssl_set_bio::f_recv_timeout set\n");
> }
>
> and turns out, that I only see the very first print on
> "mbedtls_ssl_set_bio::entry\n" and nothing there after, which leads me
> to the believe that my *ssl is invalid which is odd as that variable
> is also used for ret = mbedtls_ssl_setup( &ssl_d, &conf_d ); and it is
> initialized at the beginning of the function with mbedtls_ssl_init(
> &ssl_d );
>
>
On 2021-06-08 7:40 a.m., Ron Eggler via mbed-tls wrote:
> On 2021-06-08 12:28 a.m., Gilles Peskine via mbed-tls wrote:
>> Hi Ron,
>>
>> The code you've shown so far only consists of setup functions that
>> populate fields in the configuration structure, then in the context
>> structure. Communication has not started yet. mbedtls_ssl_set_bio in
>> particular is a very simple setter function.
>>
>> Where does the code actually hang? Have some messages already been
>> exchanged on the network at that point? Can you get a stack trace?
>>
>> Best regards,
>>
> Hi Gilles,
>
> Thank you for the response!
>
> I've inserted print statements after each of the setup functions and
> can see that it never gets past mbedtls_ssl_set_bio. The messages that
> have been exchanged, include the complete bring up and login of the
> control channel, on the data channel, I call
> mbedtls_x509_crt_init
> mbedtls_pk_init
> mbedtls_entropy_init
> mbedtls_ctr_drbg_init
> mbedtls_ssl_init
> mbedtls_ssl_config_init
> followed by the certificate and key file got parsing, seeding of the
> RNG and that's where the previously mentioned procedure with
> mbedtls_ssl_config_defaults() starts.
> I unfortunately do not have a debugger available on that platform and
> hence getting a stack trace won't be so straight forward. Do you have
> any pointers as to what could be the issue potentially?
>
> Thank you,
>
> Ron
Okay, I've made some further findings:
I changed the mbedtls_ssl_set_bio funmction so that I inserted a print
statement on entry and after every set line, like so:
void mbedtls_ssl_set_bio( mbedtls_ssl_context *ssl,
void *p_bio,
mbedtls_ssl_send_t *f_send,
mbedtls_ssl_recv_t *f_recv,
mbedtls_ssl_recv_timeout_t *f_recv_timeout )
{
iprintf("mbedtls_ssl_set_bio::entry\n");
ssl->p_bio = p_bio;
iprintf("mbedtls_ssl_set_bio::p_bio set\n");
ssl->f_send = f_send;
iprintf("mbedtls_ssl_set_bio::f_send set\n");
ssl->f_recv = f_recv;
iprintf("mbedtls_ssl_set_bio::f_recv set\n");
ssl->f_recv_timeout = f_recv_timeout;
iprintf("mbedtls_ssl_set_bio::f_recv_timeout set\n");
}
and turns out, that I only see the very first print on
"mbedtls_ssl_set_bio::entry\n" and nothing there after, which leads me
to the believe that my *ssl is invalid which is odd as that variable is
also used for ret = mbedtls_ssl_setup( &ssl_d, &conf_d ); and it is
initialized at the beginning of the function with mbedtls_ssl_init(
&ssl_d );
On 2021-06-08 12:28 a.m., Gilles Peskine via mbed-tls wrote:
> Hi Ron,
>
> The code you've shown so far only consists of setup functions that
> populate fields in the configuration structure, then in the context
> structure. Communication has not started yet. mbedtls_ssl_set_bio in
> particular is a very simple setter function.
>
> Where does the code actually hang? Have some messages already been
> exchanged on the network at that point? Can you get a stack trace?
>
> Best regards,
>
Hi Gilles,
Thank you for the response!
I've inserted print statements after each of the setup functions and can
see that it never gets past mbedtls_ssl_set_bio. The messages that have
been exchanged, include the complete bring up and login of the control
channel, on the data channel, I call
mbedtls_x509_crt_init
mbedtls_pk_init
mbedtls_entropy_init
mbedtls_ctr_drbg_init
mbedtls_ssl_init
mbedtls_ssl_config_init
followed by the certificate and key file got parsing, seeding of the RNG
and that's where the previously mentioned procedure with
mbedtls_ssl_config_defaults() starts.
I unfortunately do not have a debugger available on that platform and
hence getting a stack trace won't be so straight forward. Do you have
any pointers as to what could be the issue potentially?
Thank you,
Ron
Hi,
Can you please help Jun to find an answer to is question? (See below.)
/George
---------- Forwarded message ---------
发件人： Jun Nie <jun.nie(a)linaro.org>
Date: 2021年6月7日周一 下午2:31
Subject: How to map PSA method to openssl method
To: <mbed-tls(a)lists.trustedfirmware.org>
Hi,
I want to sign a data on PC with openssl, and verifiy it with PSA-RoT on board. Does anybody know how to map PSA method to openssl method?
Such as:
psa_sign_hash(key_handle,
PSA_ALG_DETERMINISTIC_ECDSA(PSA_ALG_SHA_256), hash, hash_len, sig, sizeof(sig), sig_len);
Regards,
Jun
Hi Ron,
The code you've shown so far only consists of setup functions that
populate fields in the configuration structure, then in the context
structure. Communication has not started yet. mbedtls_ssl_set_bio in
particular is a very simple setter function.
Where does the code actually hang? Have some messages already been
exchanged on the network at that point? Can you get a stack trace?
Best regards,
--
Gilles Peskine
Mbed TLS developer
On 08/06/2021 02:30, Ron Eggler via mbed-tls wrote:
>
> On 2021-06-07 5:00 p.m., Ron Eggler via mbed-tls wrote:
>> Hi,
>>
>>
>> i'm in the process of wrioting an FTPS client for a system running on
>> uCOS.
>>
>> I've been able to setup the control channel fine and working on
>> setting up the data channel for a simple list command execution.
>>
>> It seems like I seem able to setup everything fine but the call to
>> mbedtls_ssl_set_bio() hangs even though I set it to execute the
>> timeout function like:
>>
>> mbedtls_ssl_set_bio( &ssl_d,
>> &data_fd,
>> mbedtls_tls_send,
>> NULL,
>> mbedtls_tls_recv_timeout);
>>
>> Where the mbed_tls_recv_timeout looks like:
>>
>> https://pastebin.com/Jw3iLc0x
>>
>> The current connection uses ipv4, i.e. the select () branch is
>> active. I never see the timed out message. Any idea what may be going
>> on here?
>>
>> Thank you,
>>
>> Ron
>>
> A bit more detail: as for what comes before the mbedtls_ssl_set_bio()
> call:
>
> ret = mbedtls_ssl_config_defaults(&conf_d,
> MBEDTLS_SSL_IS_CLIENT,
> MBEDTLS_SSL_TRANSPORT_STREAM,
> MBEDTLS_SSL_PRESET_DEFAULT);
>
> mbedtls_ssl_conf_authmode( &conf_d, MBEDTLS_SSL_VERIFY_OPTIONAL);
> mbedtls_ssl_conf_ca_chain( &conf_d, &cacert_d, NULL );
> mbedtls_ssl_conf_rng(&conf_d, mbedtls_ctr_drbg_random, &ctr_drbg_d );
> mbedtls_ssl_conf_dbg(&conf_d, mydebug, stdout);
> ret = mbedtls_ssl_conf_own_cert( &conf_d, &clicert_d, &pkey_d);
>
> ret = mbedtls_ssl_setup( &ssl_d, &conf_d );
>
> mbedtls_ssl_set_bio( &ssl_d,
> &data_fd,
> mbedtls_tls_send,
> NULL,
> mbedtls_tls_recv_timeout);
>
On 2021-06-07 5:00 p.m., Ron Eggler via mbed-tls wrote:
> Hi,
>
>
> i'm in the process of wrioting an FTPS client for a system running on
> uCOS.
>
> I've been able to setup the control channel fine and working on
> setting up the data channel for a simple list command execution.
>
> It seems like I seem able to setup everything fine but the call to
> mbedtls_ssl_set_bio() hangs even though I set it to execute the
> timeout function like:
>
> mbedtls_ssl_set_bio( &ssl_d,
> &data_fd,
> mbedtls_tls_send,
> NULL,
> mbedtls_tls_recv_timeout);
>
> Where the mbed_tls_recv_timeout looks like:
>
> https://pastebin.com/Jw3iLc0x
>
> The current connection uses ipv4, i.e. the select () branch is active.
> I never see the timed out message. Any idea what may be going on here?
>
> Thank you,
>
> Ron
>
A bit more detail: as for what comes before the mbedtls_ssl_set_bio() call:
ret = mbedtls_ssl_config_defaults(&conf_d,
MBEDTLS_SSL_IS_CLIENT,
MBEDTLS_SSL_TRANSPORT_STREAM,
MBEDTLS_SSL_PRESET_DEFAULT);
mbedtls_ssl_conf_authmode( &conf_d, MBEDTLS_SSL_VERIFY_OPTIONAL);
mbedtls_ssl_conf_ca_chain( &conf_d, &cacert_d, NULL );
mbedtls_ssl_conf_rng(&conf_d, mbedtls_ctr_drbg_random, &ctr_drbg_d );
mbedtls_ssl_conf_dbg(&conf_d, mydebug, stdout);
ret = mbedtls_ssl_conf_own_cert( &conf_d, &clicert_d, &pkey_d);
ret = mbedtls_ssl_setup( &ssl_d, &conf_d );
mbedtls_ssl_set_bio( &ssl_d,
&data_fd,
mbedtls_tls_send,
NULL,
mbedtls_tls_recv_timeout);
Hi,
i'm in the process of wrioting an FTPS client for a system running on uCOS.
I've been able to setup the control channel fine and working on setting
up the data channel for a simple list command execution.
It seems like I seem able to setup everything fine but the call to
mbedtls_ssl_set_bio() hangs even though I set it to execute the timeout
function like:
mbedtls_ssl_set_bio( &ssl_d,
&data_fd,
mbedtls_tls_send,
NULL,
mbedtls_tls_recv_timeout);
Where the mbed_tls_recv_timeout looks like:
https://pastebin.com/Jw3iLc0x
The current connection uses ipv4, i.e. the select () branch is active. I
never see the timed out message. Any idea what may be going on here?
Thank you,
Ron
Hi Stefano,
The pk module has limited support for opaque RSA keys, by using the
RSA_ALT functionality
(https://tls.mbed.org/kb/cryptography/use-external-rsa-private-key
<https://tls.mbed.org/kb/cryptography/use-external-rsa-private-key>).
There's no support for opaque EC keys.
For a TLS server, you can use the asynchronous callback feature to use
an opaque key. See https://tls.mbed.org/kb/how-to/ssl_async
<https://tls.mbed.org/kb/how-to/ssl_async>
The PSA crypto API supports opaque keys. On the application side, you
need to use functions like psa_asymmetric_sign instead of
mbedtls_pk_sign. On the hardware side, you need to implement a secure
element driver for your crypto chip. Driver support is work in progress,
and documentation and tooling are still sparse. The driver
specifications are in
https://github.com/ARMmbed/mbedtls/tree/development/docs/proposed
<https://github.com/ARMmbed/mbedtls/tree/development/docs/proposed> . To
add driver support, you currently need to edit
library/psa_crypto_driver_wrappers.c and replace calls to the test
driver by calls to your real driver.
Best regards,
--
Gilles Peskine
Mbed TLS developer and PSA Crypto architect
On 03/06/2021 17:20, stefano664 via mbed-tls wrote:
> Hi all,
> I'm using mbedTLS libraries with an OPTIGA cryptochip. At the
> moment, when I call the sign function:
>
> err = mbedtls_pk_sign(&priv_key, MBEDTLS_MD_SHA384, hash, 0, sign,
> &olen, mbedtls_ctr_drbg_random, &ctr_drbg);
>
> I need to pass it a valid private key else if it isn't used, because
> alternative sign routine use the one into cryptochip.
>
> It is possible to avoid passing this key?
>
> Best regards,
> Stefano Mologni
>
