Hi mariocaptain,

Thank you for your interest in our wolfMQTT/wolfSSL solution.

You can find our Arduino examples for wolfMQTT and wolfSSL here:
https://github.com/wolfSSL/wolfMQTT/tre … DE/ARDUINO
https://github.com/wolfSSL/wolfssl/tree … DE/ARDUINO

Our AWS IoT Hub MQTT example is here:
https://github.com/wolfssl/wolfmqtt#aws-iot-example
https://github.com/wolfSSL/wolfMQTT/blo … s/awsiot.c

To utilize a non-BSD socket network interface we have a template for using a different transport here:
https://github.com/wolfSSL/wolfMQTT/blo … mqttuart.c

Let me know if you have any other questions or issues.

Thanks,
David Garske, wolfSSL

352

(9 replies, posted in wolfMQTT)

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 Sanjay,

The call to set cipher list is failing, but you are not checking the return code. The correct syntax for the cipher suite is: `ECDHE-RSA-AES128-GCM-SHA256`. You can use this command to see a list of supported cipher suites: `./examples/client/client -e`.

`./examples/client/client -h 66.83.75.170 -p 443 -c ./certtest/Demo_Cert.pem -A ./certtest/CA_Root.pem -d -l ECDHE-RSA-AES128-GCM-SHA256`

Also we have some simple TLS client examples here:
https://github.com/wolfSSL/wolfssl-exam … master/tls

Let me know if that resolves the issue.

Thanks,
David Garske, wolfSSL

354

(9 replies, posted in wolfMQTT)

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

355

(4 replies, posted in wolfSSL)

Hi Nimesh,

I see you are using the tirtos package build. You'll need to add `gnuOpts += "-DUSE_WOLF_STRTOK";` to `tirtos/wolfssl.bld`.

Let me know if that helps.

Thanks, David G.

356

(4 replies, posted in 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

357

(6 replies, posted in wolfSSL)

Hi Andrey,

I pushed a few changes to a branch for you to try. I am working on integrating this with another PR to add STM32 CubeMX hashing support. That should be pushed later today.

For now you can find the commit with this fix here:
https://github.com/dgarske/wolfssl/comm … 57d1b36491

The patch is attached. Let me know your results.

Thanks,
David Garske, wolfSSL

358

(6 replies, posted in 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

359

(2 replies, posted in wolfMQTT)

Hi kackle123,

The `struct timeval` is used in wolfMQTT for socket timeout handling. If you do define `struct timeval` you don't need to increment it. The structure is used for `select()` to define the time to wait before timing out. Since the build works it means your socket layer handles `select()`, so you are good to go.

If you want to bypass setting a socket timeout in the mqttnet.c example code you can define `WOLFMQTT_NO_TIMEOUT`.

Thanks,
David Garske, wolfSSL

Hi Nathan,

I assume you have downloaded the Atmel demo `Atmel_ATECC508_Demos.zip` from the web page and are using Atmel Studio to build and debug. Are you using the SAMD21 or some other board?

Would you mind enabling our logging and sending the log output? Add the define `#define DEBUG_WOLFSSL` and call to `wolfSSL_Debugging_ON()` somewhere early in the boot process, like before wolfSSL_init().

A common reason for a fault like that is not setting the stack size high enough.

I created our ATECC508A demo and have the hardware to try and reproduce any issues, so we should be able to resolve this quickly.

Thanks,
David Garske, wolfSSL

361

(8 replies, posted in wolfMQTT)

Hi embedded,

I've done some testing and found a bug and also pushed some cleanup to this PR:
https://github.com/wolfSSL/wolfMQTT/pull/24

Let me know your results with this.

This should get merged into master this week (its in peer review). Then we have a v0.13 release planned early next week.

Thanks,
David Garske, wolfSSL

362

(8 replies, posted in wolfMQTT)

Hi embedded,

I recognize the gap in getting return codes from the NetRead back to the caller via the wolfSSL layer. There is a fix I have in mind to pass that through the callback context. I'll push a branch/pull request to GitHub shortly to better demonstrate this. I'll let you know when its available.

Thanks,
David Garske, wolfSSL

363

(8 replies, posted in wolfMQTT)

Hi,

Is there a reason you haven't updated to the latest v0.12 wolfMQTT?
https://github.com/wolfSSL/wolfMQTT/releases/tag/v0.12

I believe the issue you are seeing has been addressed in one of these commits:
https://github.com/wolfSSL/wolfMQTT/com … b726821896
https://github.com/wolfSSL/wolfMQTT/com … 86ccb31caa

Also a MQTT_CODE_ERROR_TIMEOUT is considered a failure, is there a reason you aren't returning the MQTT_CODE_CONTINUE return code in non-blocking mode from your NetRead function?

Thanks,
David Garske, wolfSSL

Hi n7ekg,

The API for performing a full hash on SHA-256 data is "wc_Sha256Hash". This wraps our internal calls and allows you to provide an input/size and get a hash output (32-bytes for SHA-256).

int wc_Sha256Hash(const byte* data, word32 len, byte* hash);

Also you can call the wolfCrypt API's directly using something like:

#include "wolfssl/wolfcrypt/sha256.h"

Sha256 sha256;
unsigned char hash[SHA256_DIGEST_SIZE];
wc_InitSha256(&sha256);
wc_Sha256Update(&sha256, data, len);
wc_Sha256Final(&sha256, hash);

Of course make sure and check the return code from these, which should be 0 on success.

Here is another example for our wolfCrypt test:
https://github.com/wolfSSL/wolfssl/blob … st.c#L1234

Let me know if that helps.
David Garske, wolfSSL

365

(12 replies, posted in wolfSSL)

Hi n7ekg,

That pull request is going through internal automated testing and peer review. Should get merged in shortly. You can pull those changes in locally until then.

To checkout a pull request you can use:
git fetch origin pull/747/head:int_min_max
git checkout int_min_max

Thanks, David Garske, wolfSSL

366

(12 replies, posted in wolfSSL)

Hi n7ekg,

You are having a conflict between the min() function and the local variable called min inside integer.c.

I've submitted a patch for this, since min/max as a local variable name isn't ideal.
PR #747: https://github.com/wolfSSL/wolfssl/pull/747

However you could also try defining "WOLFSSSL_HAVE_MIN".
./configure CFLAGS="-DWOLFSSSL_HAVE_MIN"

Thanks, David Garske, wolfSSL

Hi Zhouhaohua,

Is there are reason you aren't using Visual Studio to build the Windows wolfSSL simulator with the FreeRTOS_Plus_WolfSSL.sln file? I wouldn't expect the Windows Simulator to build correctly with the ARM GCC compiler (cross-compiling).

See the following page for details with using the FreeRTOS wolfSSL example:
http://www.freertos.org/FreeRTOS-Plus/W … mple.shtml

We do support FreeRTOS with ARM and have many customers using this configuration. However this example is for Windows. We make it very easy to build with FreeRTOS as the OS using the define "FREERTOS". Next step is to setup the socket handling. If you are using FreeRTOS TCP then you'd want to define "FREERTOS_TCP" or if using LWIP define "WOLFSSL_LWIP".

It looks like you are building for an LPC part. Have you seen our LPC example here located here?
https://github.com/wolfSSL/wolfssl/tree … LPCXPRESSO

Thanks, David Garske, wolfSSL

Hi Sachin,

Yes we have many customers using wolfSSL and wolfMQTT on a bare-metal implementation with no RTOS. I recommend defining SINGLE_THREADED, which disables the RTOS (mutex/threading) support.

Thanks,
David Garske, wolfSSL

369

(6 replies, posted in wolfCrypt)

Hi Carlos,

I was able to reproduce the UnPadding error if the server didn't have the right private key loaded for the certificate. In the example you provided above the private key is in DER (ASN1) format and the loading of the private key buffer should be done as follows:

ret = wolfSSL_CTX_use_PrivateKey_buffer(ctx, privkey_der_2048, sizeof(privkey_der_2048), SSL_FILETYPE_ASN1);

Make sure and check the return code for this call and the wolfSSL_CTX_use_certificate_buffer function. Its possible your call was using SSL_FILETYPE_PEM and failing.

As for the example you sent for rsa_test I was able to get it working, but I had to add an include for wolfssl/options.h prior to settings.h to make sure the compiled library settings matched the application.

Here is the working rsa_test example:

#ifdef HAVE_CONFIG_H
    #include <config.h>
#endif

#include <wolfssl/options.h>

#include <wolfssl/wolfcrypt/settings.h>

#include <wolfssl/ssl.h>
#include <wolfssl/wolfcrypt/rsa.h>
#include <wolfssl/wolfcrypt/memory.h>
#include <wolfssl/wolfcrypt/error-crypt.h>
#include <wolfssl/wolfcrypt/tfm.h>
#include <wolfssl/wolfcrypt/logging.h>

volatile unsigned int pico_ms_tick = 0;

int close(int __fildes){
    return 0;
}

#define HEAP_HINT 0
#define FOURK_BUF 4096

/* privkey.der, 2048-bit */
const unsigned char privkey_der_2048[] =
{
    ...
};

int rsa_test(void)
{
    byte*   tmp = NULL;
    size_t bytes;
    RsaKey key;
    WC_RNG rng;
    word32 idx = 0;
    int    ret;
    byte   in[] = "Everyone gets Friday off.";
    word32 inLen = (word32)XSTRLEN((char*)in);
    byte   out[256];
    byte   plain[256];
    byte*  outPtr = NULL;

    tmp = (byte*)XMALLOC(FOURK_BUF, HEAP_HINT, DYNAMIC_TYPE_TMP_BUFFER);
    if (tmp == NULL) {
        ret = MEMORY_E;
        goto exit;
    }

    XMEMCPY(tmp, privkey_der_2048, sizeof(privkey_der_2048));
    bytes = sizeof(privkey_der_2048);

    ret = wc_InitRsaKey_ex(&key, HEAP_HINT, INVALID_DEVID);
    if (ret < 0) {
        goto exit;
    }
    ret = wc_RsaPrivateKeyDecode(tmp, &idx, &key, (word32)bytes);
    if (ret < 0) {
        goto exit;
    }

    printf("Key Size: %d\n", wc_RsaEncryptSize(&key));

    ret = wc_InitRng(&rng);
    if (ret < 0) {
        goto exit;
    }

#ifdef WC_RSA_BLINDING
    ret = wc_RsaSetRNG(&key, &rng);
    if (ret < 0) {
        goto exit;
    }
#endif

    ret = wc_RsaPublicEncrypt(in, inLen, out, sizeof(out), &key, &rng);
    printf("wc_RsaPublicEncrypt: %d\n", ret);
    if (ret < 0) {
        goto exit;
    }

    idx = ret; /* save off encrypted length */
    ret = wc_RsaPrivateDecrypt(out, idx, plain, sizeof(plain), &key);
    printf("wc_RsaPrivateDecrypt: %d\n", ret);
    printf("\n%d", ret);
    if (ret < 0) {
        goto exit;
    }

    if (XMEMCMP(plain, in, ret)) {
        printf("Compare failed!\n");
        goto exit;
    }

    ret = wc_RsaSSL_Sign(in, inLen, out, sizeof(out), &key, &rng);
    printf("wc_RsaSSL_Sign: %d\n", ret);
    if (ret < 0) {
        goto exit;
    }

    idx = ret;
    XMEMSET(plain, 0, sizeof(plain));

    ret = wc_RsaSSL_VerifyInline(out, idx, &outPtr, &key);
    printf("wc_RsaSSL_Verify: %d\n", ret);
    if (ret < 0) {
        goto exit;
    }

    if (XMEMCMP(in, outPtr, ret)) {
        printf("Compare failed!\n");
        goto exit;
    }

    ret = 0; /* success */

exit:

    wc_FreeRsaKey(&key);
    XFREE(tmp, HEAP_HINT, DYNAMIC_TYPE_TMP_BUFFER);
    wc_FreeRng(&rng);

    return ret;
}


int main()
{
    int32_t ret;

#if defined(DEBUG_WOLFSSL)
    wolfSSL_Debugging_ON();
#endif

    wolfCrypt_Init();

#if !defined(NO_BIG_INT)
    if (CheckCtcSettings() != 1)
        printf("\nBuild vs runtime math mismatch\n");

#ifdef USE_FAST_MATH
    if (CheckFastMathSettings() != 1)
        printf("\nBuild vs runtime fastmath FP_MAX_BITS mismatch\n");
#endif /* USE_FAST_MATH */
#endif /* !NO_BIG_INT */

    ret = rsa_test();

    printf("\nret %d", ret);

    return 0;
}

Please let me know your results.

Thanks,
David Garske, wolfSSL

Hi Sachin,

Thanks for the report about the wolfmqtt-0.12.zip archive on the website. Its been fixed.

You only need wolfSSL if you are using TLS with MQTT to secure the pipe (socket). By default wolfMQTT "./configure" enables TLS, so if you aren't using TLS then use "./configure --disable-tls". If not using ./configure the define to enable/disable TLS support is "ENABLE_MQTT_TLS".

The wolfMQTT download has several examples including an AWS IoT, Azure IoT Hub, Firmware Update and basic MQTT client.

The latest user manual is here:
https://www.wolfssl.com/documentation/w … Manual.pdf

Let me know if you had any other questions.

Thanks,
David Garske, wolfSSL

371

(6 replies, posted in wolfCrypt)

Hi Carlos,

Try using wc_InitRsaKey(&key) and not the _ex version. If you use _ex make sure your HEAP_HINT is NULL and devId is INVALID_DEVID.

What key size are you trying to use with your RSA server certificate? Our library enables RSA 2048-bit by default and you would need to define a higher FP_MAX_BITS (key size * 2). Can send me the public self-signed server certificate that you are using?

Also make sure you have HAVE_TLS_EXTENSIONS and HAVE_SUPPORTED_CURVES defined if using ECDHE and TLS.

If you are able to make the server external that would help us be able to test against it. Feel free to reach out to us at support@wolfssl.com if you don't want any of your server information public on the forum.

You have a great holiday as well!

Thanks,
David Garske, wolfSSL

372

(6 replies, posted in wolfCrypt)

Hi crmoratelli,

Which version of wolfSSL are you using? You can find it noted in wolfssl/version.h.

Can you try connecting to your https server using the following and send back the results?
openssl s_client -host [your host] -port [your port] -showcerts

For the wolfCrypt test I was not able to reproduce with the latest in master. But curious if changing your test so out and plain are sized as 128 and let me know your results:
byte   out[128];
byte   plain[128];

Also in the test try changing "ret = wc_InitRsaKey_ex(&key, HEAP_HINT, devId);" to use "ret = wc_InitRsaKey(&key);".

If you want to send an email to support@wolfssl.com with your https server host/port so we can test against it that would be wonderful.

Thanks,
David Garske, wolfSSL

Hi Thomas,

Please try using the "WC_SIGNATURE_TYPE_RSA_W_ENC" sig_type. This adds a DER encoded header to the hash prior to the verify. This type typically required when using RSA signatures generated from openssl.

Thanks,
David Garske, wolfSSL

374

(2 replies, posted in wolfSSL)

Hi Zine314,

It looks like the AES CCM* (star) spec adds variable length auth tags plus some encoding info. We do support the normal AES CCM block cipher, which AES CCM* is backwards compatibility with, but we do not support CCM*.

I put this on our feature request list. We do offer consulting services to help expedite features. If you would like more info on this option please email us at info@wolfssl.com.

Thanks,
David Garske, wolfSSL

375

(7 replies, posted in wolfSSL)

Hi Andrey,

Assuming you can get a server certificate with SHA384 digest and signed by a CA with a SHA384 digest and have a real HW RNG source (which you do) then you can disable SHA256. The commit that has this support is here:
https://github.com/wolfSSL/wolfssl/comm … df9e89bab0

With the way the random.c code is structured the wc_GenerateSeed function for STM32F2_RNG will not be available with CUSTOM_RAND_GENERATE_BLOCK defined. So best solution is to copy/paste the wc_GenerateSeed function at line 1414 into your own .c file and then you can do something like what you suggested. The code would look like:

/* Put this in your own .c file */
#undef RNG
#include "stm32f2xx_rng.h"
#include "stm32f2xx_rcc.h"
/*
 * wc_Generate a RNG seed using the hardware random number generator
 * on the STM32F2. Documentation located in STM32F2xx Standard Peripheral
 * Library document (See note in README).
 */
int custom_rand_generate_block(byte* output, word32 sz)
{
    int i;

    /* enable RNG clock source */
    RCC_AHB2PeriphClockCmd(RCC_AHB2Periph_RNG, ENABLE);

    /* enable RNG peripheral */
    RNG_Cmd(ENABLE);

    for (i = 0; i < sz; i++) {
        /* wait until RNG number is ready */
        while(RNG_GetFlagStatus(RNG_FLAG_DRDY)== RESET) { }

        /* get value */
        output[i] = RNG_GetRandomNumber();
    }

    return 0;
}

/* Put this into user_settings.h */
/* Bypass P-RNG and use only HW RNG */
extern int custom_rand_generate_block(unsigned char* output, unsigned int sz);
#undef  CUSTOM_RAND_GENERATE_BLOCK
#define CUSTOM_RAND_GENERATE_BLOCK  custom_rand_generate_block

Thanks,
David Garske, wolfSSL