-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MQTT with certificates #210
Comments
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. |
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. 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. |
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/ |
I think using a Secure Element, the secure bootloader is quite unecessary. 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. Edit: |
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, ... |
Indeed, @fietser28 does propose a very reasonable approach. Here are the 4 "entry" vectors, their associated access type and the estimated difficulty:
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. 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:
Here is a simple proposal on a basic strategy. It is not perfect by all means, but should not be too complicated.
Using this approach, I feel like most of the attack vectors have risen in difficulty. Feel free to comment on my proposal :) |
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 :)
The text was updated successfully, but these errors were encountered: