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.

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!

I am working on a project trying to port wolfSSL 4.4 to ch32v307, one RISC-V MCU designed by WCH company. This embed board will work as one ssl client. The mcu has its own protocol library for tcp/udp communication task. I copied wolfssl/wolfcrypt source and header files to mcu project, using user-defined setting file for wolfSSL. Now the compilation is successful and firmware can run in embed board. But from the debug message it is failed during SSL handshake. By wireshark tool, I can observe that ssl client send Client Hello to ssl server and server returns Server Hello, but it has problem when paring the Server Hello packet. I debugged the wolfSSL program, its call stack is like this:

ssl.c wolfSSL_connect()
internal.c ProcessReply()
internal.c GetInputData()
internal.c wolfSSLReceive()
wolfio.c EmbedReceive()
wolfio.c wolfIO_Recv()

From the log the function wolfIO_Recv() reads the whole Server Hello packet which is 1427 bytes, but the wolfSSL expects 5 bytes at first time, then parse the remaining contents of Server Hello. I mean it seems that wolfSSL is trying to parse Server Hello packet by two parts, but wolfIO_Recv() read the packet by one calling.

Here is the log information (some are wolfSSL messages, some are from my mcu project.)

wolfSSL Entering wolfSSL_Init
wolfSSL Entering wolfCrypt_Init
wolfSSL Entering TLSv1_2_client_method_ex
wolfSSL Entering wolfSSL_CTX_new_ex
wolfSSL Entering wolfSSL_CertManagerNew
wolfSSL Leaving WOLFSSL_CTX_new, return 0
wolfSSL Entering wolfSSL_CTX_set_verify
WCHNET_SocketCreat 0
wolfSSL Entering SSL_new
wolfSSL Leaving SSL_new, return 0
wolfSSL Entering SSL_set_fd
wolfSSL Entering SSL_set_read_fd
wolfSSL Leaving SSL_set_read_fd, return 1
wolfSSL Entering SSL_set_write_fd
wolfSSL Leaving SSL_set_write_fd, return 1
ssl:20000404
MACAddr:200003f8
maclen:20017fcc
PHY Link Success
TCP Connect Success
wolfSSL Entering SSL_connect()
wolfSSL Entering SendClientHello
Adding signature algorithms extension
growing output buffer

Signature Algorithms extension to write
Point Formats extension to write
Supported Groups extension to write
Encrypt-Then-Mac extension to write
EMS extension to write
sz:142
@sz:142 sent:142
Shrinking output buffer

wolfSSL Leaving SendClientHello, return 0
enter solfSSL_ETHRx
recv data len:1427

connect state: CLIENT_HELLO_SENT
ProcessReply
AA
GetInputData, size:5

EmbedReceive: 5
wolfIO_Recv: 1427 flag:0
@sz:1427 recvd:1427
buf:16 03 03 05 FFFFFF8E
wolfSSL error occurred, error = -376

Could anyone give me some suggestions for this problem?

Does wolfSSL really need to parse Server Hello packet by two parts/calling wolfIO_Recv() twice?
Or my user-defined setting header file for wolfSSL has something wrong?

Thanks,
Rick

We are switching from TLS_AES_128_CCM_SHA256 to TLS_AES_128_CCM_8_SHA256 for a little better performance.
We are using wolfssl 5.7.6, and not really using the whole code but cut down as required. and we are not building the library as such but using it directly by attaching it to a package.

I have done  2 things until now in my user_settings.h file, added the second line as I believe the first line was responsible for TLS_AES_128_CCM_8_SHA256 implementation 
#define HAVE_AESCCM
#define HAVE_AESCCM_8 //(newly added by me, Not sure if this is a correct define for CCM_8 for this cipher).

and in my code I have Changed,
   //ret = wolfSSL_CTX_set_cipher_list(ctx, "TLS_AES_128_CCM_SHA256");
   
   ret = wolfSSL_CTX_set_cipher_list(ctx, "TLS_AES_128_CCM_8_SHA256");
I have turned the debugger of the wolfssl and its giving me that handshake is complete but my comms is restarting again after few seconds without throwing any errors.

Questions:-
1.What changes do I have to do for maybe auth, keyexchange and for cipher suite to get this worked.
2.In general Requirements for TLS_AES_128_CCM_8_SHA256

Again the current impl is working fine with TLS_AES_128_CCM_SHA256 need to do some tweaks for TLS_AES_128_CCM_8_SHA256
Please ask me as much questions as you want because I may not have added enough information to overview.

Code:-

   int ret = 0;
   int sz = 0;

   int MAX_CONCURRENT_IO = 0;

   ctx = NULL;

   initializeSSL();

   short unsigned int minDhKey = 128;
   wolfSSL_CTX_SetMinDhKey_Sz(ctx, minDhKey);

   WOLFSSL_METHOD* method;

   /* Get encryption method based on TLS version */

   method = wolfTLSv1_3_server_method();

   /* Allocate wolfSSL_CTX, cipher list, cert and key */

   if ( (ctx = wolfSSL_CTX_new(method)) == NULL)
      {
      // error loading ctx
      PARA_LOG(LOG_ID_SC, "WolfSSL_CTX_new error\n");
      }

   //ret = wolfSSL_CTX_set_cipher_list(ctx, "TLS_AES_128_CCM_SHA256");
   
   ret = wolfSSL_CTX_set_cipher_list(ctx, "TLS_AES_128_CCM_8_SHA256");
   printf("-------------------------Loading Cipher onto ret---------------------------------------------");
   if (ret != SSL_SUCCESS)
      {
      // error loading private key from buffer
       printf("-------------------------1Error Loading Cipher onto ret---------------------------------------------");
       PARA_LOG(LOG_ID_SC, "Error Cipher List: %i\n", ret);
      }

   wolfSSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, 0);

   ret = wolfSSL_CTX_load_verify_buffer(ctx, serv_ecc_der_256,
            sizeof_serv_ecc_der_256, SSL_FILETYPE_ASN1);
   //printf(ret);
   if (ret != SSL_SUCCESS)   
      {
      // error loading certificate from buffer.

       printf("-------------------------2 Error Loading Certificate onto ret---------------------------------------------");
      PARA_LOG(LOG_ID_SC, "Error Loading client buffer.\n");
      }

   ret = wolfSSL_CTX_use_certificate_buffer(ctx, serv_ecc_der_256,
                    sizeof_serv_ecc_der_256, WOLFSSL_FILETYPE_ASN1);

   if (ret != SSL_SUCCESS)
      {
      // error loading certificate from buffer

       printf("-------------------------3 Error use Certificate onto ret---------------------------------------------");
      PARA_LOG(LOG_ID_SC, "Error Loading Certificate buffer.\n");
      }

   ret = wolfSSL_CTX_use_PrivateKey_buffer(ctx, ecc_key_der_256,
            sizeof_ecc_key_der_256, WOLFSSL_FILETYPE_ASN1);

   if (ret != SSL_SUCCESS)
      {
      // error loading private key from buffer
       
       printf("-------------------------3 Error use private key onto ret---------------------------------------------");
       PARA_LOG(LOG_ID_SC, "Error Loading Private Key buffer: %i\n", ret);
      }

   createNewSession();
   }

Thank you in advance!!

I understand that "mutual authentication" involves both sides of an SSL/TLS connection sending the certificate chain during the handshake and verifying the counterparty's chain.
So when does that happen?

It is important for our application that no call to the WolfSSL library blocks for too long. We therefore want to use as much as possible of the asynchronous features. Another restriction of our setup is that we use static memory allocation.

First we perform the following initialization steps:
- call wolfSSL_init();
- call wolfSSL_CTX_load_static_memory() to configure memory and initialize a WolfSSL context.
- call wolfSSL_CTX_load_verify_buffer_ex() to load a self-signed CA certificate (filetype ASN1)

Then we want to verify a certificate against the CA that has just been loaded. Ideally this could be done by using wolfSSL_CertManagerVerifyBuffer, but that doesn't work since it does not internally handle the WC_PENDING_E return value as a special case. Therefore, we do the following steps instead:

- call wc_InitDecodedCert to initialize a DecodedCert instance "decoded_certificate" containing our certificate.
- set "decoded_certificate.sigCtx.devId" to the value 0.
- call wc_ParseCert, expect return value WC_PENDING_E
- call wolfAsync_EventInit to initialize "decoded_certificate.sigCtx.asyncDev->event"

Then repeatedly call wolfAsync_EventPoll on "decoded_certificate.sigCtx.asyncDev->event".

(1) Is this the intended usage of the API? It appears unlogical that we need to access the fields of "decoded_certificate.sigCtx" directly, but I can not find a way to use asynchronous ECC computations without doing this.

Despite making the ECC computations asynchronous the call to wc_ParseCert is still too slow for us. This is potentially caused by the repeated computation of SHA256 hashes. We can install a callback handler using option WOLF_CRYPTO_CB, but as far as we can see it is not allowed for the hash function callback to return WC_PENDING_E.

(2) Is it correct that any hash function callback provided through "wc_CryptoCb_RegisterDevice" must be blocking?

(3) It appears like we could improve the performance a lot by using the WOLFSSL_SP_ARM_CORTEX_M_ASM option. However, the non-blocking implementation is not available. Concretely, we are missing the definition of struct sp_256_ecc_mulmod_8_ctx and the function sp_256_ecc_mulmod_8_nb (wolfcrypt + wolfasynccrypt v5.6.6).

I want to have the public and private keys of less than 72 bytes in size.

Is there any option that i can generate the keys(less than 72 bytes) using the PFX file. if this is not possible, please provide any alternate ways to achieve this objective.

is there a way to generate keys from PFX file using ECC instead of RSA?

I have integrated the wolfssl library version "4_8_0_stable" into my application and configured the wolfssl with the option as "./configure --enable-aesgcm-stream". After configuring, i could notice that the macro "WOLFSSL_AESGCM_STREAM" is defined in  "wolfssl\options.h" file. I'm trying to build the wolfssl into my application using the "CMakeLists.txt". As part of the build, "wolfcrypt/test/test.c" file is getting compiled and ends with the below linker error.

wolfssl_4_8_0_stable/wolfcrypt/test/test.c:10130: undefined reference to `wc_AesGcmEncryptInit'
external/wolfssl_4_8_0_stable/wolfcrypt/test/test.c:10133: undefined reference to `wc_AesGcmEncryptUpdate'
external/wolfssl_4_8_0_stable/wolfcrypt/test/test.c:10136: undefined reference to `wc_AesGcmEncryptFinal'
external/wolfssl_4_8_0_stable/wolfcrypt/test/test.c:10145: undefined reference to `wc_AesGcmDecryptInit'
external/wolfssl_4_8_0_stable/wolfcrypt/test/test.c:10148: undefined reference to `wc_AesGcmDecryptUpdate'
external/wolfssl_4_8_0_stable/wolfcrypt/test/test.c:10151: undefined reference to `wc_AesGcmDecryptFinal'
external/wolfssl_4_8_0_stable/wolfcrypt/test/test.c:10160: undefined reference to `wc_AesGcmEncryptInit'
external/wolfssl_4_8_0_stable/wolfcrypt/test/test.c:10168: undefined reference to `wc_AesGcmEncryptUpdate'
external/wolfssl_4_8_0_stable/wolfcrypt/test/test.c:10176: undefined reference to `wc_AesGcmEncryptUpdate'
external/wolfssl_4_8_0_stable/wolfcrypt/test/test.c:10181: undefined reference to `wc_AesGcmEncryptFinal'
external/wolfssl_4_8_0_stable/wolfcrypt/test/test.c:10192: undefined reference to `wc_AesGcmDecryptInit'
external/wolfssl_4_8_0_stable/wolfcrypt/test/test.c:10200: undefined reference to `wc_AesGcmDecryptUpdate'
external/wolfssl_4_8_0_stable/wolfcrypt/test/test.c:10208: undefined reference to `wc_AesGcmDecryptUpdate'
external/wolfssl_4_8_0_stable/wolfcrypt/test/test.c:10213: undefined reference to `wc_AesGcmDecryptFinal'

Have attached the file "wolfssl\options.h" for reference. Someone could please help me in resolving this error.

Thanks!

We are using wolfssl in our project which is based on Silabs BLE mcu (BGM210PA32).

Initially we were using the wc_ecc_export_x963 and wc_ecc_import_x963, and the export and import was working fine.

Now when I use the export with compression wc_ecc_export_x963_ex ( it is successfully compressing to 33bytes) and then during the import the program is getting hanged indefinitely. Also sometimes I observed the error,
WC_HW_E  = -248,  /* Error with hardware crypto use */

I am quite sure the controller we use has Wolfssl Hardware acceleration support, but still couldn't understand why we get the -248 err.

Could you please comment on the hanging issue we observe while using the enabling the compression api.

For your info, these api's we use in our project to import and export:
wc_ecc_init()
wc_ecc_make_key_ex()
wc_ecc_export_x963_ex()
wc_ecc_import_x963

Thanks in advance.

Is there any module in which we can make use of ECDSA with SHA256 for signature generation, which is required for the project which I'm working presently.

Note: I've gone through ECC algorithm, but specifically I'm asking about ECDSA now.

Thanks in advance.

In my use case, I need to pass a particular number as the Random-number to the signature generation function, which is wc_SignatureGenerate( )
Function parameters are : -
hash_type: WC_HASH_TYPE_SHA256
signature_type: WC_SIGNATURE_TYPE_ECC
Signature length used: 60 bytes

For example Random Number = 0x1111111111111111111111111111111111111111111111111111111111111111.

Can someone please guide me in achieving this! That would be helpful.

Thanks in advance,
Thippeswamy D R

I am attempting to build wolfSSL and the associated tests for a platform running a minimalistic kernel (implements some system calls and sets up virtual memory) with a RISC-V arch and newlib toolchain. The library needs to be compiled statically. I am cross-compiling this on an x86 machine.

I'm encountering some build errors for the wolfcrypt/test/testwolfcrypt binary:

tls13.c:(.text+0x2f96): undefined reference to `__errno_location'
integer.c:(.text+0x3912): undefined reference to `__ctype_toupper_loc'
.... and these same errors but for other files as well.

Here's the configuration options used:

./configure --enable-static CFLAGS="-I$RISCV/sysroot/usr/include -I$RISCV/riscv64-unknown-elf/include -DWOLFSSL_USER_IO -Os" CPPFLAGS="-I./" --host=riscv64 CC=riscv64-unknown-elf-gcc AR=riscv64-unknown-elf-ar RANLIB=riscv64-unknown-elf-ranlib LD=riscv64-unknown-elf-gcc --prefix=$HOME/tools/wolfssl LDFLAGS="-L$RISCV/riscv64-unknown-elf/lib -lc -lgloss -lstdc++" --enable-filesystem=no --enable-singlethreaded --enable-oldtls=no --enable-tlsv12=no --enable-asyncthreads=no --enable-asm=no

Are these errors related to libc? I'm configuring with newlib's c library, and not sure what the problem might be.

Is there an additional configuration option needed, or is there somehow a library inconsistency problem?

Thanks.