microchip-pic-avr-solutions / avr-iot-cellular-arduino-library

Arduino library for developing Cellular IoT Applications with the AVR-IoT Cellular Mini development board from Microchip
Other
21 stars 4 forks source link

Own certificates? #4

Closed tomy983 closed 2 years ago

tomy983 commented 2 years ago

Is there an example on how to load my own certificates into the secure element? I wold like to use a self hosted mqtt broker with tls.. Thank you

M65649 commented 2 years ago

Hello!

Do I understand you correctly that you already have a certificate consisting of a public and private key pair and want to load that into the ATECC secure element? For security reasons, one cannot overwrite the main private key of the ATECC. The extract_certificates.ino example file prints out the signing and device certificate which can be used.

If you do need to use a predefined set of certificate and private key and can't use the ECC's certificate, there is an alternative by loading the certificate and the private key into the cellular modem and not use the secure element. Do note that this is less secure as you are bypassing the secure element.

More information about this is in the cellular modem's AT command reference (the pdf can be found in the first link here: https://iot.microchip.com/docs/arduino/debugging/atcommands). The commands you are looking for are: : AT+SQNSNVW (used to write certificate and private key) and AT+SQNSPCFG (which configures the security profile). For MQTT without ECC and with TLS, we have dedicated security profile ID 2, so after you've loaded the certificates into the modem you'd have to do something like this AT+SQNSPCFG=2,2,"0xC02F",1,1,5,5,"","",0 if you load the certificate and private key into slot 5 (more information about this in the AT command reference). In order to write these commands, you need to put the board into bridge mode, which is explained here: https://iot.microchip.com/docs/arduino/debugging/overview under UART Bridge.

We could possibly create an example sketch where this is done for you if you'd like that.

Feel free to ask more questions!

tomy983 commented 2 years ago

Hi and thank you for the follow up!

I am trying very hard to make a functioning secure connection, but unfortunately I keep failing. I could use a little help or a suggestion.. Here is my setup:

Remote mqtt broker (withouth a domain name, with a static IP) running mosquitto version 1.6.9 configured as such:

pid_file /var/run/mosquitto.pid
persistence true
persistence_location /var/lib/mosquitto/
log_dest file /var/log/mosquitto/mosquitto.log
include_dir /etc/mosquitto/conf.d

listener 8883
keyfile /home/ubuntu/certs/mosquitto.key
certfile /home/ubuntu/certs/mosquitto.crt
cafile /home/ubuntu/certs/ca.crt
require_certificate true
use_identity_as_username true

I generate and sign my own certificates using https://hohnstaedt.de/xca and test them from a remote client using Mqtt Explorer, and everything works fine, also with the validation option turned on (if I set in the client certificate the common name as the broker IP address or in the SAN altnames).

Loading the same certificates in the cellular modem, however, generates always a -8 SQNSMQTT_ERR_TLS error. This happens without any connection attempt to the server (looking at the log file, server side). I have tried this with both +SQNSMQTTCFG certValidLevel set to 1 or to 0 (to clear internal validation issues but with the same result. Also changing the SSL/TLS protocol version to use does not make any differences, likewise including some of the ciphers or leaving empty to select them all (I did check for compatibility between broker cipher list and cellular module).

Of course, before attempting a tls connection, I ensured everything was working using an 1883 port connection.

Here is a brief extract of my Serial comms: (ca cert in slot 18 and client cert and key in slot 19)

AT

OK
AT+CTZU=1

OK
AT+CTZR=1

OK
AT+CEREG=5

OK
AT+SQNSNVW="certificate",19,0

OK
AT+SQNSNVW="certificate",19,1328

> -----BEGIN CERTIFICATE-----
MIIg==
-----END CERTIFICATE-----

OK
AT+SQNSNVW="privatekey",19,0

ERROR
AT+SQNSNVW="privatekey",19,1706

> -----BEGIN RSA PRIVATE KEY-----
MIA==
-----END RSA PRIVATE KEY-----

OK
AT+SQNSNVW="certificate",18,0

OK
AT+SQNSNVW="certificate",18,1306

> -----BEGIN CERTIFICATE-----
MIA==
-----END CERTIFICATE-----

OK
AT+SQNSPCFG=2,2,"",1,18,19,19

+SQNSPCFG: 2,2,"",1,18,19,19,"","",0,0,0

OK
AT+SQNSMQTTCFG=0,"test_client",,,2

OK
AT+CFUN=1

OK

+CEREG: 2

+CEREG: 5,"32F8","0072BD1F",7

+CTZV: +08

+CEREG: 5,"32F8","006D241F",7
AT+SQNSMQTTCONNECT=0,"xxx.xxx.xxx.xxx",8883

OK

+SQNSMQTTONCONNECT:0,-8

The issue I am facing is most probably due to the cellular module, but reading reading the datasheet, the "At commands reference" and also the "use cases for at commands" documents I cannot understand the requirements for the certificates.

I would like to find a working solution, and yes, using the secure element would be great, but I have no Idea how to set up the server side for the authentication (can I sign other certificates for the server using the secure element? and when i will deploy many clients?)

Another, unfortunate, constrain I have is limited connection capabilities from my SIM card due to my operator requiring an ACL before providing me with the SIM (can add more to the list but for now I only have my own server on 1883 and 8883 ports). And this, is the reason why I am using a EC2 AWS instance rather than following your proposed setup with the automated provisioning, which I actually like!

I am also happy to share with you, if you require, certificates for access and the server IP address in private if you would like.

Thank you

M65649 commented 2 years ago

I can’t see any obvious errors in your setup. Usually, these problems are related to the cipher suite not matching or it could also be the modem clock not having gotten an update, so the verification against the time period in the certificate fails. Since you’ve already tried disabling this, I don’t think this is the issue. But just to eliminated that, could you do AT+CCLK? after you’ve received +CTZV and see if the clock matches the current time?

tomy983 commented 2 years ago

I tried, it is omitted in the extract I posted, but the clock does synchronise to the current local time. The certificates I tried had 100 years expiration date. Just to exclude the possibility of not matching ciphers, I just verified a connection to the broker with Mqtt Exporer after adding the following to the broker config: ciphers AES128-GCM-SHA256:EECDHE-ECDSA-AES128-GCM-SHA256 . This should allow for only this two ciphers being used (I just picked two that also appear on the cellular module datasheet) and the connection is working. But, if using the cellular, checking the logs of the broker, I am not seeing any incoming connection attempts.

Another thing that it is not clear to me is the fact that if I create a security profile without the ca certificate eg. AT+SQNSPCFG=2,2,"",0,,19,19 , the answer is OK , but then doing AT+SQNSMQTTCFG=0,"test_client",,,2 responds with error.

Also this part from the at reference:

Note: The MQTT broker can provide certificates and private keys files with <CR><LF>
(Carriage Return and Line Feed) endings. The parameter <size>, however, must not take
the <CR> characters into account. To remove the <CR>s, use the following command on
UNIX: cat file_with_cr | tr -d \015 > no_cr_file

Doing it like it is noted, results in an error while loading the certificate. After hours of trying, the only way to load the cert or keys is have them with <CR><LF> (I actually have to add the <CR> ) at the end of each line and also include those in the bytes count. Otherwise it just does not work... Am I missing something here?

This is what I can load: Immagine 2022-08-11 160822

M65649 commented 2 years ago

«Another thing that it is not clear to me is the fact that if I create a security profile without the ca certificate eg. AT+SQNSPCFG=2,2,"",0,,19,19 , the answer is OK , but then doing AT+SQNSMQTTCFG=0,"test_client",,,2 responds with error.» The sqnspcfg is quite a general command, so it might not do all the error checking and delegate that to the different modules like mqtt, https etc.

Could you try to do a test with the certificate setup on test.mosquitto.org? It would also be beneficial to see the detailed modem logs. Uart 1 and uart 2 have the modem debug logs and console, respectively (check the cellular mini hardware guide). If you have the equipment available (such as a logic analyzer or just a uart reader), could you report back with those logs? Check the command “AT+SQNHWCFG?” to see if these uarts are enabled in the modem (you might have to be in cfun=4 or cfun=5). The command to enable verbose logs for mqtt is AT!="setlog mqtt finest" and AT!="printlog 1 1" (the logs will then appear on the debug uart).

Could you also verify that the certificates seems correctly loaded with AT+SQNSNVR?

M65649 commented 2 years ago

Hello again,

Sorry for the late follow up, I've been out of office. We've confirmed that the certificate setup with test.mosquitto.org works. Have you found a solution that works for you?

tomy983 commented 2 years ago

Hello @M65649, thank you for your follw up, and so sorry for the extra late reply... Yes, I have good news.. Turns out my ISP, when I had to provide my ACL, forgot ("@#$%&!"...) to add port 8883, but only added 1883. So much time wasted because of this... I only now got around to test again and I finally had a successful connection to my broker using TSL. Yay!

I really think we can close this issue, and I wanted to thank you for your support. It was very appreciated. Let me also compliment you guys for the fantastic work you are doing with software and documentation for this board. Could not have asked for better. It's a pity Sequans does not follow your example, not only with the easily accessible and clear documentation but also with time consuming mistakes in their docs.

M65649 commented 2 years ago

Hello @tomy983. Glad that it worked out for you! Just to let you know, we'll push out a simple command line tool soon to set the certificates in the modem, so that you don't have to do it manually with the AT commands as you had to do in this case. We've also been working more on how to easily allow people to use the ECC with other brokers, so that will come soon as well.