1 Topic by nvbolhuis

(1 replies, posted in General Inquiries)

We're using WolfSsl 5.8.0 as TLS client on a simple 32bit MCU which is pretty slow.
The MCU has no HW crypto accelerator whatsoever.
I'm talking about a system with ~ 60 Dhrystone MIPS.

TLS1.3 (and ECC) is a mandatory requirement.

We found our TLS connection fails because the MCU resets due to a watchdog reset.
It happens when WolfSsl verifies the (server) ECC certificate, this is part of the TLS
handshake which is part of the TLS connection setup which is triggered by
our application exchanging data (with wolfSSL_write).
What happens in detail is that, in our case:

DoProcessReplyEx -> DoTls13HandShakeMsg -> DoTls13HandShakeMsgType -> DoTls13CertificateVerify -> EccVerify

takes quite a long time (~ 10 seconds).

Maybe this is because we're letting WolfSsl alloc memory dynamically. Also, we've noticed the
wolfcrypt ECC crypto logic/functions (e.g. ecc_verify_hash) are quite "heavy".

Of course the watchdog reset is our problem, and so we fixed it for our system/platform.
But since our HW/board and bootloader is final we could not adapt the watchdog timer. So, we
had to add some "watchdog resets" in the WolfSsl/Wolfcrypt code.

I can imagine we're not the only ones having this issue, and afaik. there is no way for a user
to make WolfSsl/WolfCrypt call some user provided watchdog reset function.

I guess it'd be good to add it to WolfSsl, afterall, you guys know where "heavy" and possible slow
processing might occur.

Go to forum: General Inquiries

2 Topic by nvbolhuis

(1 replies, posted in General Inquiries)

Hello WolfSsl community,

We're using WolfSsl 5.8.0 as TLS client on a simply MCU which is very limited on
memory space and less limited on program/flash space.

Because of this, and for several other reasons as well, I do not want to use
wolfSSL_CTX_load_verify_buffer_ex(... format=SSL_FILETYPE_ASN1, userChain=1 ...)
to load all root CA certificates to be able to verify the server certificate chain (SSL_VERIFY_PEER).

Btw. https://curl.se/docs/caextract.html shows there are >100 root CA certificates to have
in the system "local trust store". Some of them aren't relevant, but I guess maybe 50-80 ones
are (the system is quite generic and used internationally).

So, I thought about and implemented "on-demand root CA certificate loading".
It works as follows:

1. create an SKI-indexed list of (the most important) root CA certificates in DER format
2. the list will be part of the FW-image which resides on flash (and on MCU program flash during execution)
3. GetCA will be changed to search the list, add a certificate with wolfSSL_CTX_load_verify_buffer and try again (=2nd attempt) if the cert. can not be found the 1st attempt.

Since it is an SKI (Subject Key Identifier) indexed list and an SKI is assumed to be 20 bytes
the limitations are obvious. There is no support for certificates without SKI and/or truncated SKI.
I believe this is acceptable.

I'd like to ask: is there anything fundamentally wrong with the above concept?

Thanks for your thoughts!

Go to forum: General Inquiries