MQTT with certificates

[fusedFET]

Hello,

I would like to connect to MQTT brokers that require certificate based auth (AWS for example) to the PSU.

Is it possible to put the certificates (Private key, Device Certificate and Certificate Authority) on the SD card and tell MQTT to use TLS with these?

PS: Thank you for the great Power Supply :)

[goran-mahovlic]

It should be possible

There are some explanations here on how they do it

https://iot-freertos.workshop.aws/lab_0.html

For the start it is maybe faster to have some local broker on local machine or server that will pass data to AWS.

[goran-mahovlic]

I did some more checking - it is possible - but AWS sample is quite complex - so from current understanding we would need significant effort to rework it and use certificates from SD card.

Quick guide how to use MQTT with AWS is here.

https://www.st.com/resource/en/user_manual/dm00367435-getting-started-with-xcubeaws-stm32cube-expansion-package-for-amazon-web-services-iot-core-stmicroelectronics.pdf

From reading - for this example secure element is needed (to store certificate) - and also 2 additional boot loaders.

So we would need to rewrite everything to place all in out app - as if key is in boot loader - then for each user we would need custom boot loader.
I will check for some other samples - as I did notice that there are some python implementations - but then python would probably need direct access to Ethernet - and I do not think that is also easy to do.

[goran-mahovlic]

Here is possible workaround that could be used until we figure out how to implement this

https://aws.amazon.com/blogs/iot/how-to-bridge-mosquitto-mqtt-broker-to-aws-iot/

[fusedFET]

I think using a Secure Element, the secure bootloader is quite unecessary.
This makes sense when the end device is running in an untrusted environnement. A BB3 will most likely sit on a bench next to the user. At least for a first step, implementing those security measures might be uncessary.

I did see in the documentation that it is possible to use "runtime-imported" certificates, which seems to be simply a variable string containing the certificate.

https://stackoverflow.com/questions/61096520/hw-to-use-stm32-lwip-mqtt-api-with-tls

I did mention AWS, but at a fundamental level, it is the same for any HTTPS request or any other broker that uses X509 authentication.
Anyway, I would maybe avoid using XCubeAWS extension and go for the generic TLS libs.
This way, you also support Azure, Mosquitto with TLS and probably any other provider.

Edit:
A simple workaround would be to use EEZ studio which could using SCPI or something lower level, to forward data from the BB3 to the endpoint using certificates on the computer.
This would even avoid the necessity to have a Mosquitto setup locally.

[fietser28]

I also recommend generic TLS for MQTT. TLS is also not MQTT specific. TLS has an enough library implementations. The challenge is key management, especially protecting and enrolling (and replacing) a private keys. This is something generic (see #216) including the secure management of keys (and certificates).

It is not possible to just 'slap TLS on' because that will always be insecure. Example: storing the key in a file right now is very insecure because I can retrieve the file via a SCPI command without a password....

You have to make design assumptions regarding what you want to protect against which kind of threat: physical access, network access, MITM, USB, ...

[fusedFET]

Indeed, @fietser28 does propose a very reasonable approach.
We should define a simple thread model, let me make a first step and feel free to comment.

Here are the 4 "entry" vectors, their associated access type and the estimated difficulty:

• GUI/UART/USB: In-person, Trivial
• Physical "light" (using SD card): In-person, Trivial
• Physical "hard" (SWD/JTAG/Side-channel/ScanningElectronMicroscope): In-person, Difficult
• Ethernet: Remote, Medium

I propose to exclude the "Physical hard" from the list at this point, due to the fact that used CPUs do not have any advanced protection. (Well you could disable JTAG, but this would go against the goal of the BB3). A Trustzone enabled MCU like Cortex M33 would be necessary. Or at least a Secure Element which makes it slightly more difficult than flashed in the MCU ROM.

A BB3 will run in a Trusted Environment: It is unlikely accessible by the public. It will in 90% of the cases be sitting on a bench nearby the operator which put the very same certificate on the device.
However, it would be easy to dump the SD card for a malicious person when the operator is absent, or using SCPI.

Using SCPI over Ethernet, anyone in the local network can actually read the same data a X509 certificate would protect, or manipulate the BB3. I am currently not aware of any protection mechanism against this.

I would consider only following 3 goals in the security model to have a basic security approach:

• A certificate on the SD card should not be accessible from SCPI.
• A certificate should once used be deleted from the SD card.
• A certificate should only be accepted by the BB3 if a user, using the GUI, selects it.

Here is a simple proposal on a basic strategy. It is not perfect by all means, but should not be too complicated.

• A certificate + CA + Private key pair is copied on the SD card by the operator in a folder called "keys".
• The folder is not accessible (Read/Write) through SCPI.
• A sub-menu in the GUI allows to "load" the certificates into the MCU Flash. They are loaded in a reserved MCU Flash region and are encrypted using a password. Once "flashed" the files on the SD card are deleted.
• The password is kept in RAM. After a reboot, the user has to reenter the password to decrypt the certificates+private-key then in clear-text in ram.

Using this approach, I feel like most of the attack vectors have risen in difficulty.
You either need a software bug in the BB3 to access it when the certificate is provisioned or dump using the JTAG when the system is on and the system has been enabled by a trusted user before.
If someone is willing to access those ressources anyway, it is no longer to the BB3 to mitigate this attempt, but to other systems.
This can be done through stringent permissions on the MQTT side, or locking the door to the place where the BB3 is located.

Feel free to comment on my proposal :)