Hi Eyal,

If you are only using the wolfCrypt portion of the library you can:
1. define `WOLFCRYPT_ONLY`.
2. Include relevant source files in /wolfcrypt/src/*.c
3. Include relevant headers in /wolfssl/wolfcrypt/*.h

For the build options you are using the only files you would to include are: asn.c, ecc.c, sha256.c and random.c. However I would recommend pulling in all the files/headers and letting the linker optimize out any used functions. This should the same code size, but allow you to expand your use.

If you do not have a hardware RNG, then you should use the pseudo DBRG based on SHA256. To seed the DRBG you'll need to find some random source such as a microsecond counter or ADC noise.

Here are the defines and code example for doing this:

#define HAVE_HASHDRBG

#define CUSTOM_RAND_TYPE      unsigned int
extern unsigned int custom_rand_generate(void);
#define CUSTOM_RAND_GENERATE  custom_rand_generate

unsigned int custom_rand_generate(void)
{
    /* TODO: build 32-bits of RNG and return */
    return myRng;
}

Thanks,
David Garske, wolfSSL

Hi tdoering,

Thanks for the excellent question and details.

Yes having an intermediate CA for each device, which generated and signed by a root during manufacturing is a very good solution.

The server certificate for the TLS server should present a cert chain with the server peer certificate first, then the intermediate cert. If the public root CA is loaded on the key store/browser then this will be a valid certificate chain.

We have an example for creating a server certificate at runtime here:
https://github.com/wolfSSL/wolfssl-examples/pull/70

You can find examples for creating a cert request and having it signed here:
https://github.com/wolfSSL/wolfssl/blob … st.c#L8900

Let me know if you have any issues or questions.

Thanks,
David Garske, wolfSSL

Hi Nimesh,

To include wolfMQTT into your project you can either include the sources directly or compile them as a static library. I would recommend doing it the same as you are doing with wolfSSL. Either way is supported.

The wolfMQTT library itself is very compact (only about 4 KB). The only RAM allocated is for the TX/RX buffer, which defaults to 1024 bytes, but can be reduced.

I don't have any documentation for using wolfMQTT with TI_RTOS, but if you've got it working with wolfSSL then it should be easy to add wolfMQTT. The wolfMQTT library has no RTOS dependencies besides the network callbacks in examples/mqttnet.c. You can use that file as a template for implementing the TI_RTOS network calls.

The best reference for TI_RTOS can be found here:
https://github.com/wolfSSL/wolfssl/tree/master/tirtos

Thanks,
David Garske, wolfSSL

Hi Gussabina,

The IO read callback will ask for X bytes. If your network return X+10 bytes (for example) you will need to cache the extra 10 bytes until the next callback. Typically when you ask a network stack for X bytes it only returns X bytes. However if you are using something besides a network stack and asking the hardware for a buffer, you may receive more than X bytes. Its up to you to cache those extra bytes until the next IO read callback.

Let me know if that helps or not.

Thanks,
David Garske, wolfSSL

Hi Gussabina,

If you are using FreeRTOS you can define `FREERTOS` instead of `SINGLE_THREADED` to enable mutex protection in the wolfSSL library.

The wolfMQTT library on the other-hand does not support multi-threads. To solve that you have a couple options:
1. Have one thread dedicated to handling the RX and TX of publish messages. Define `WOLFMQTT_NONBLOCK` and if you get back the `MQTT_CODE_CONTINUE` response code then it means no RX data is available. You can then use/check a FreeRTOS queue for any messages to TX.
2. Use a mutex to protect access to the socket between two threads. You'll also need to use non-blocking mode so you aren't blocked on the socket read.

It sounds like the eventual failure might be due to multiple threads trying to rx/tx publish messages at the same time. This would get the data in the socket out of sync and probably cause the decrypt error.

Thanks,
David Garske, wolfSSL

Hi Csaba,

The wolfCrypt test results up to the point of failure look normal. Typically when we see a failure in RSA its because of a memory or configuration issue.

Please check the following:
1. Make sure your stack enough reserved space. For my wolfCrypt test on a PIC32MZ here I set it to 20480 bytes.
2. If you are setting the FP_MAX_BITS make sure and use the max key size times 2 (so 2048-bit RSA will require `#define FP_MAX_BITS 4096`).
3. For the wolfCrypt self test it requires certificates. Typically these come from the file system in ./certs. If NO_FILESYSTEM is defined then you'll need to set either USE_CERT_BUFFERS_2048 or USE_CERT_BUFFERS_1024 depending on your FP_MAX_BITS.

For setting up the library to just enable SHA1 and RSA you can define `WOLFSSL_USER_SETTINGS` and the `user_settings.h`file somewhere in your include path. You can find examples for this here:

https://github.com/wolfSSL/wolfssl/blob … settings.h

If this doesn't help please let me know the error code from the failed wc_Rsa function and the test which is failing.

Thanks,
David Garske, wolfSSL

Hi kackle123,

Your description of the issue sounds like an MQX networking problem. Perhaps take a step back and setup a simple TCP socket client example to validate your networking functionality would be good.

The wolfSSL library does not handle socket connect or disconnect. With a typical TLS implementation the socket is created and host connected, then `wolfSSL_set_fd()` is called so the wolf IO layer knows the socket descriptor handle to read()/write(). The wolfMQTT library uses the `WOLFSSL_USER_IO` define to enable setting IO callbacks using wolfSSL_SetIORecv() and wolfSSL_SetIOSend(), which handle the read/write inside the wolfMQTT application.

See this code sections for details:
https://github.com/wolfSSL/wolfMQTT/blo … ket.c#L302

The `MqttSocket_Connect()` function first opens the socket using the defined net->connect callback function, then sets up the WOLFSSL object and calls `wolfSSL_connect()`.

If you can send over any logs, code changes or wireshark trace, those will help in understanding the problem.

Thanks,
David Garske, wolfSSL

Hi Kackle123,

If your AWS log shows access denied, then your socket connect() has already occurred and you've entered into the TLS handshake. AWS uses TLS mutual authentication, which requires the device (client) also present a certificate for authentication. Those client certificates are generated by AWS or you can load your own CA and sign them yourself.

See our example here:
https://github.com/wolfSSL/wolfMQTT/blo … iot.c#L193

http://docs.aws.amazon.com/iot/latest/d … ntity.html

To better support this it would be helpful to turn on wolfSSL debugging logs and capture a wireshark trace and send that over. You can email support@wolfssl.com and reference this forum case if you want to keep it confidential.

For logs you need to define `DEBUG_WOLFSSL` and call `wolfSSL_Debugging_ON();` prior to `wolfSSL_Init();`.

Thanks,
David Garske, wolfSSL

Hi Kackle123,

For TLS the socket must be open first then the call to wolfSSL_connect(). If you are having trouble getting past the socket `connect()` that indicates a network level problem. Have you verified you can reach the host? Can you provide some additional information on the platform you are using and how you are building it?

If you are building wolfMQTT for AWS you'll need to make sure TLS support is enabled either using `./configure --enable-tls` or `#define ENABLE_MQTT_TLS`.

Thanks,
David Garske, wolfSSL

Hi Nimesh,

We recently implemented a custom strtok replacement to resolve build environments that do not have an implementation. We found MINGW and a few other build environments are missing this, so we wrote our own.

This change was merged into master on Aug 17, 2017. You can find the pull request here:
https://github.com/wolfSSL/wolfssl/pull/1105

To force use of this define `USE_WOLF_STRTOK`. With configure this would be `./configure CFLAGS="-D USE_WOLF_STRTOK"`.

Let me know if this helps.

Thanks,
David Garske, wolfSSL

Hi Andrey,

My name is David Garske and I'm one of the wolfSSL engineers. I'm working on resolving this issue now. I agree the STM32F2 doesn't support hardware accelerated AES GCM. I'll post an updated with a pull request link shortly.

Thanks,
David Garske, wolfSSL