Google IOT cloud integration mbedtls issue on STM32L946 discovery

[Cheye.1]

..

[Cheye.1]

I have an STM32L494 discovery board with cellular BG96 modem and trying to connect to Google IOT core with the provided project example design. (GCP v1.0.0)

On application launch, first thing it asks is the connection string which I can enter successfully now.

It then asks for the TLS root CA certificate which I have found in comodo_google.pem. I paste the two certificates. Program continues.

I created a private and public key, uploaded the public key in Google Cloud IoT, and the enter the private device key on the terminal. Program continues and starts the SSL/TLS handshake.

However, the handshake fails at Client State 3, where shortly after it prints the following (Attached the entire log)

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4580: serial number   : 77:BD:0D:6C:DB:36:F9:1A:EA:21:0F:C4:F0:58:D3:0D

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4580: issuer name    : C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4580: subject name   : C=US, O=Google Trust Services LLC, CN=GTS Root R1

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4580: issued on    : 2020-06-19 00:00:42

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4580: expires on    : 2028-01-28 00:00:42

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4580: signed using   : RSA with SHA-256

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4580: RSA key size   : 4096 bits

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4580: basic constraints : CA=true

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4580: key usage     : Digital Signature, Key Cert Sign, CRL Sign

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4580: value of 'crt->rsa.N' (4096 bits) is:

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4580: value of 'crt->rsa.E' (17 bits) is:

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4580: 01 00 01

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4643: x509_verify_cert() returned -9984 (-0x2700)

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4180: => send alert message

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4181: send alert level=2 message=48

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2764: => write record

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2907: output record: msgtype = 21, version = [3:3], msglen = 2

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2912: dumping 'output record sent to network' (7 bytes)

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2912: 0000: 15 03 03 00 02 02 30               ......0

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2471: => flush output

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2489: message length: 7, out_left: 7

ERROR: net_sock_send_tcp_c2c L#330 C2C_SendData(): send ERROR: 572,operation not allowed

OK

ERROR: net_sock_send_tcp_c2c L#332 Send failed.

ERROR: mbedtls_net_send L#122 mbedtls_net_send(): error -1 in net_sock_send() - requestedLen=7

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2496: ssl->f_send() returned 0 (-0x0000)

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2922: <= write record

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4193: <= send alert message

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4730: ! Certificate verification flags 208

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:4740: <= parse certificate

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:6764: <= handshake

ERROR: net_sock_open_mbedtls L#279 Server verification:

 ! The certificate is not correctly signed by the trusted CA

 ! The certificate validity starts in the future

ERROR: net_sock_open_mbedtls L#286 failed

 ! mbedtls_ssl_handshake returned -0x2700

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:7542: => free

STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:7607: <= free

ERROR: GcpIoT_connect L#596 Could not open the socket at mqtt.googleapis.com port 8883.

ERROR: gcp_main L#432 Could not open the socket at mqtt.googleapis.com port 8883.

Is this an incorrect mbedtls configuration, in the project settings it seems to use this one:

MBEDTLS_CONFIG_FILE=<googleiot_mbedtls_config.h>

Or still something wrong with certificates/keys?

When I set authmode to optional in the mbedtls wrapper file  mbedtls_ssl_conf_authmode(&tlsData->conf, MBEDTLS_SSL_VERIFY_OPTIONAL);

then the ssl handshake continues to client state 12, then jumps to client state 17, but then can't write either.

[Cheye.1]

OK so I those 2 issues were

1. Related to the RTC not getting the time from the network first, which also requires a SSL handshake as it issues an HTTPS request.
2. I had to change the Google RootCA and take one from pki.google.com/roots.pem as is described in UM2441 version 1.0

It passes server verification now, but I still see the issue where it enters Client State 12 (  MBEDTLS_SSL_SERVER_CHANGE_CIPHER_SPEC), and then jumps to state 17 (MBEDTLS_SSL_SERVER_NEW_SESSION_TICKET) and when in state 17 it just keeps looping there, and still with those occasions C2C_SendData errors 572 : Operation not allowed.

No idea what can still be missing at this point

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2471: => flush output

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2489: message length: 45, out_left: 45

ERROR: net_sock_send_tcp_c2c L#330 C2C_SendData(): send ERROR: 572,operation not allowed

OK

ERROR: net_sock_send_tcp_c2c L#332 Send failed.

ERROR: mbedtls_net_send L#122 mbedtls_net_send(): error -1 in net_sock_send() - requestedLen=45

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2496: ssl->f_send() returned 0 (-0x0000)

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2922: <= write record

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:5398: <= write finished

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_cli.c:3384: client state: 12

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2471: => flush output

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2489: message length: 45, out_left: 45

ERROR: net_sock_send_tcp_c2c L#330 C2C_SendData(): send ERROR: 572,operation not allowed

OK

ERROR: net_sock_send_tcp_c2c L#332 Send failed.

ERROR: mbedtls_net_send L#122 mbedtls_net_send(): error -1 in net_sock_send() - requestedLen=45

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2496: ssl->f_send() returned 0 (-0x0000)

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_cli.c:3277: => parse new session ticket

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:3809: => read record

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2252: => fetch input

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2412: in_left: 0, nb_want: 5

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2436: in_left: 0, nb_want: 5

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:6764: <= handshake

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:6754: => handshake

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_cli.c:3384: client state: 17

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2471: => flush output

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2489: message length: 45, out_left: 45

ERROR: net_sock_send_tcp_c2c L#330 C2C_SendData(): send ERROR: 572,operation not allowed

OK

[Cheye.1]

Reducing the debug threshold in mbedtls again, actually shows that the google ssl handshake appears to have succeeded, though below would suggest something is still not quite right.

The code now fails at the first mqtt_write which also calls net_sock_send and mbed_ssl_write

onfiguring the RTC from Date: Tue, 11 Jan 2022 01:58:25 GMT

Creating socket... done.

Creating jwt... done.

Opening socket... done.

Opening MQTT connection to client projects/My First Project/locations/us-central1/registries/ww-gateway/devices/ww-edge

ERROR: net_sock_send_tcp_c2c L#330 C2C_SendData(): send ERROR: 572,operation not allowed

OK

ERROR: net_sock_send_tcp_c2c L#332 Send failed.

ERROR: mbedtls_net_send L#122 mbedtls_net_send(): error -1 in net_sock_send() - requestedLen=353

MQTT Connection failure... retrying... ERROR: gcp_main L#432 Could not open the socket at mqtt.googleapis.com port 8883.

Network link may be down. Trying to reconnect.

[Guillaume K]

Hello

what kind of private key are you using for the device ? is it ECC ? if yes, could you try with RSA key ?

[Cheye.1]

I created private/public ES256 keys as per page 17/29 of the GCP documentation v1.0 using openSSL

Entered the private .pem key's contents on the console, and configured google cloud back-end with the public key.

[Cheye.1]

OK so now I just did the same thing, but then for RSA256, still exactly the same problem

 

Higher debug threshold mbedtls:

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_cli.c:3384: client state: 15 -> THIS IS GOOD

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2471: => flush output

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2483: <= flush output

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:6764: <= handshake

done.

Opening MQTT connection to client projects/My First Project/locations/us-central1/registries/ww-gateway/devices/ww-edge

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:7330: => write

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2764: => write record

then some write records/read records...

....

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:6940: => read

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:3809: => read record

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2252: => fetch input

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2412: in_left: 0, nb_want: 5

C:/MY_DATA/Port_IoT_Sensor_PROJ/STM32/Cellular/en.x-cube-gcp_v1.0.0/STM32CubeExpansion_Cloud_GCP_V1.0.0/Middlewares/Third_Party/mbedTLS/library/ssl_tls.c:2436: in_left: 0, nb_want: 5

MQTT Connection failure... retrying... ERROR: gcp_main L#432 Could not open the socket at mqtt.googleapis.com port 8883.

Network link may be down. Trying to reconnect.

ERROR: gcp_main L#412 Netif re-initialization failed.

*** Cloud connectivity demonstration ***

Cloud connectivity demonstration completed

[Cheye.1]

OK so I have this up and running on the evaluation board.

It was simply an incorrect string for the google cloud project ID...but some cryptic debug messages for something so easy.

Next step is now to port this onto our board, which has an STM32F103-G device, so 1M of memory.

The entire cellular stack builds (apart from some items below), the modem is up and running on our board and is connected to the AP...

However there is a problem with STM32F1xxx in that it does not include the stm_hal_rng library for random number generators, which is needed during the handshake and creation of the JWT web token.

Right here (jwt.c)

ret = mbedtls_entropy_add_source(&entropy, mbedtls_rng_poll_cb, (void*)&hrng, 1, MBEDTLS_ENTROPY_SOURCE_STRONG)) != 0 )

And also in net_mbedtls_net.c

(ret = mbedtls_entropy_add_source(&tlsData->entropy, mbedtls_hardware_poll, (void*)&hrng, 1, MBEDTLS_ENTROPY_SOURCE_STRONG)) != 0 )

So how do I get around this issue on our STM32f1 device?

[Guillaume K]

Hello

I'm glad you managed to make X-CUBE-GCP 1.0.0 work on STM32L496G-Discovery board with BG96 cellular modem.

I remember there were problems with EC256 certificates but apparently it works for you.

You say you want to switch to STM32F103 with the Quectel BG96 cellular modem.

As you say, STM32F1 doesn't have hardware Random Number Generator IP used in mbedTLS. It is used as an entropy source for mbedTLS software random number generator . It's always more secure to have an hardware entropy source. I'll try to find a way to use software entropy generator if possible and publish it in another post but no guarantee.

Also note that even if STM32F103 can have up to 1 MByte flash memory, it is limited to 96 KB RAM. mbedTLS uses a lot of RAM so it could be tight. In theory, in TLS standard you can receive up to 2 "records" (packets) of 16 KB each. So 32 KB would be used out of 96KB RAM on STM32F103. You can decide to reduce the size of records you are able to receive but there's no guarantee that the server will send you less than 16KB.

As a general remark here are some details about X-CUBE-GCP:

X-CUBE-GCP 1.0.0 :

• old version superseded by v2.0.0
• no SBSFU (secure boot / secure firmware update). So more Flash memory available.
• supports more platforms and network interfaces (B-L475E-IOT01 Wifi, STM32L496G-Discovery with cellular, STM32F413I-Discovery with Wifi, STM32F769I-Discovery with ethernet)
• doesn't use Google Cloud SDK for IoT (it was published after)
• instead it uses open source libraries for MQTT protocol (Eclipse Paho) and TLS (mbedTLS)

X-CUBE-GCP 2.0.0:

• more recent than 1.0.0 but still old
• uses Google cloud C SDK for IoT (old version)
• only supports B-L475E-IOT01 board with WiFi
• SBSFU support
• doesn't use FreeRTOS
• note there were some issues with Google SDK and FreeRTOS memory allocation. GCP SDK sometimes performs 0-sized allocation and it can cause problem.

Note that SBSFU requires more Flash memory. There must be an additional Flash section available for firmware update.

Normaly we only support the latest version.

[Cheye.1]

Thanks for the clarification. So in theory I think it should work in the combo STM32F103 + BG93 using GCP 1.0 open source SW, just need the SW entropy generator.

Memory usage at the moment on the STM32F103 looks likeSo that should be fine.

It was my initial idea to port the GCP2.0 code using Google SDK on our board, or even the STML496 discovery first, but was having issues with it. It was not until later I realized that GCP v1.0 actually had support for the STML496 discovery board, so it obviously made sense to see this working first.

The BG96 modem is already integrated with our STM32F103 and works well, I mean it attaches to the network), but now we just need to see about getting the GCP1.0 code to run on it as well..

As mentions, it compiles etc...just have the issue with the RNG

[Cheye.1]

So Google SDK is ONLY supported on the B-L475E..

So what if customers want to use cellular instead of wifi?

Will you not support integration for this?