Just some across this thread. WOW!
Siwastaja is way more clever than I am; I barely understand most of the details.
I am finishing the development of a C user-programmable product which can do basically the same stuff, also with MbedTLS. But it is non application specific. It doesn't have MQTT up and running but there is some code out there. It was done in ST Cube IDE and the ST port of LWIP comes with a sample MQTT module. So if somebody wants MQTT I can pay someone to tidy this up.
As Siwastaja correctly identifies, you should never run a server on an IOT box, because you can never achieve the level of security needed to withstand the 1Hz-10Hz china/russia hacking frequency. I run a number of little websites and this is the typical attack rate. Unsuccessful so far, afaik, because it uses robust code (Linux/Centos, Apache/nginx, etc) which an IOT box isn't going to have the benefit of.
I have TLS 1.2 in there. 1.3 removes a lot of crypto which is still widely used, so it would be dumb to use 1.3 unless you also support 1.2 but then the old crypto suites have to be left in there
It is also very new.
I think 5U4GB has hit the nail on the head in so many ways. Most internet security stuff is BS. Everybody is an expert. Perfectly good stuff is obsolete, deprecated, insecure. DES is crap (does anyone really know how much known plaintext you need for any remotely viable (non NSA) attack on DES?), PPTP is crap (likewise). Almost nobody (more like literally nobody) attacks the crypto. They hack other stuff. 99.9% of users won't have physical (access) security, so they have no security at all. Somebody can walk in (if applicable, with a yellow jacket) and install a wifi AP and a DNS spoofer; then they can carry on in a car in the car park outside.
Many years ago I used to make DES line encryptors. No key management; just plain DES, shared key. Banks used them. Later they went to RSA, to generate a new key every so often. Anything stronger, they could not get an export license for it. All kinds of solutions evolved for tamper-proofing; some really esoteric like storing the key in a module, glass envelope with a fine wire in the glass, breaking the glass wiped the key. This is still used today for serious stuff. Nobody quite trusts "hardened" smartcard chips.
In testing, it was found some big-name websites use "deprecated" hashes on their certificates. Some certs in the cacert.pem file are really old, so you have to keep those ancient hashes.
But if you run your own server (the "mqtt broker") you have far more latitude on the details. Actually, who will care how you do it? You could use aes256 and a shared key
Cisco uses aes128 in their https session crypto!
Good going to do PK in 2 secs on a 64MHz Cortex 4. Mine (also C4), 168MHz, takes about 3 secs to do RSA. But that's irrelevant for most IOT data acquisition applications. MbedTLS is a big collection of crypto and probably not optimised. And I have hardware aes which is far faster than the rest of the code...
To authenticate the peer (the mqtt server) you need to store secret stuff in the IOT box, obviously, and that will remain a vulnerability for ever. The C4 is not really secure even at L2 security. And if you set L2, this is not reversible, so you get huge political risks with big customers finding a problem. Although a remote firmware update should still work, from a boot loader.
MbedTLS uses about 200k of code and 50k of RAM. This RAM usage is non-deterministic because you can never get the upper bound on the worst-case crypto suite usage. I have a win32 build of the same tls 1.2 code so if there is a problem out there, we can simulate with that. Currently it seems a 48k block (for the MbedTLS private heap) is enough, and this is chucked away reliably after each TLS session ends, so no possibility of TLS heap fragmentation getting out of hand. In theory...
If your product / application is valuable, it will be attacked and it will be hacked, because you can't stop somebody getting one and disassembling it.
Remote firmware upgrades are another interesting area. Obviously they can't be automatic (windoze-style) because
- your company won't likely have the resources for the rigorous testing
- if you sell 10k of these at $100 each to one customer, and they all get bricked, your company will be fcukd
I have an remote firmware update path but it uses an http server, with the LAN the box is on being accessed via a VPN (obviously). This is easy, safe customer-politically, safe security-wise, and costs nothing. More clever ways, used with e.g. phones, is to distribute updates so problems first appear in geographical areas where the users are mostly poor and won't shout much. I have a plan for something like that, with firmware uploaded to the peer server, but the clients getting new firmware only by box S/N [range], whereby large users can be excluded. This is reasonable since large users tend to run the same feature set and if it works it will run for ever. Updates would be needed only if the user finds a bug. And a client, behind NAT, will never get hacked, so no need for "security updates". Anyway, one must assume LWIP and MbedTLS are insecure
- the code is written by amateurs
- the code is tiny compared to the "heavy duty" server solutions
- most IOT is not on open ports so gets little or no attack exposure
- it is open source so any back doors are wide open
I am on the LWIP and MbedTLS mailing lists and I see real BS stuff on the latter (the former is almost dead now; the coders have got girlfriends long ago and moved on) where they are doing stuff like zero-filling buffers between sessions... Who is going to exploit that? In IOT, non open source, the chances of an attacker successfully running code of their choice is nil. I mean, you don't have a web page on it with a memory hex dump feature
These people are running out of ideas, but in reality a client will be unhackable, and if it was a server it would be mega vulnerable to DOS (there is no firewall, and if you implement one it will still flood from any gigabit LAN, been around this block due to the vulnerability to broadcasts but you can't block them all because you need ARP and possibly PnP / auto detect.
Your server will obviously get attacked and that will be a weak point. And if you use e.g. some AWS MQTT "cloud service" and AWS one day send you an email saying "we have detected fraud on your account; we have closed it" and you discover you can't phone them, can't email them, can't write to them, can't visit them, and your business model is now totally sunk (this happened to someone I know and got sorted only because his brother knew a director of Amazon).
Good luck
Yes, when it comes to crypto, everybody is an expert