Microcontroller Cryptography Investigation

[nctnico]

Ask yourself: Why would an IoT device need to use HTTP?

[technix]

Ask yourself: Why would an IoT device need to use HTTP?

If I want to control it using Apple devices through their HomeKit, TLS 1.2 with strong cipher and PFS, HTTP and JSON are all mandated.

In fact with Apple iOS, even if you are not using HTTP, connecting to any protocol from within an app mandates TLS now.

[nctnico]

Ask yourself: Why would an IoT device need to use HTTP?

If I want to control it using Apple devices through their HomeKit, TLS 1.2 with strong cipher and PFS, HTTP and JSON are all mandated.

In fact with Apple iOS, even if you are not using HTTP, connecting to any protocol from within an app mandates TLS now.

Well that is a dumb move by Apple because TLS isn't going to be the IoT standard -period-. It can't be due to limited resources and too much bloat in TLS. If someone can come up with a clever way to communicate with IoT / microcontroller devices in a secure way and get it to become a standard it will change the world.

[Jeroen3]

It isn't a dumb move at all. Apple just told the industry to make it happen.
Sometimes they can make good decisions, like not allowing flash on iOS.

The internet rebuild itself due to that. And it improved a lot.

[nctnico]

It isn't a dumb move at all. Apple just told the industry to make it happen.

And how long would that take? Sure at some point we will have microcontroller which can support TLS and run on a 3V coin cell for over a year but as I wrote before that will take at least 5 to 10 years. So all in all Apple did nothing to solve the problem currently at hand.

[Kjelt]

Most "hacks" of IoT products are just bugs in how the web stuff works.
Send some fancy stuff over GET. Directory traversal bugs. Put some weird chars in the username. And they'll barf the output.
That is after you've tried the default password. Or you just ask for it over sms.

Yes those are made by companies that are zero aware of security but as you see how countries like for instance the US is now creating new laws that make companies responsible and liable for damages to private persons this is going to change very soon. That is why companies that want to sell IoT stuff to customers really should get their things in order or end up at the wall of sheep and bankruptcy.

[Kjelt]

The biggest problem with a full TLS stack is that it takes way to much memory because of all the excess baggage which comes with TLS like key exchange during the link initialisation phase.

Well for IoT devices there are ongoing new developments like DTLS icw 6lowpan, but I agree partially that standalone IoT devices probably have more in common with a raspberri pi kind of processing power and a GB ROM/ few MB of RAM than with a Cortex M4 with 1M ROM and 256kB RAM. The latter is just not going to cut it, although you do not have to support all possible ciphersuites, so if you choose the ciphersuite wisely you could get away with it.

On the other hand, I just tested an embedded device running OpenSSL from may 2016 and there were already 30+ vulnerabilities found in the mean time so they had to upgrade to the latest and greatest.
Companies should be aware that they are responsible for upgrading their libraries so actually upgrading the firmware on a regular basis.
Some companies like for instance Synology do a good job, others like for instance Asus brings out an update for their routers once a year, pretty shockingly low for a device that acts as a firewall between the bad outside world and your home network. But still they upgrade there are companies that sell and forget.

In case of IoT devices you should forget about TLS because it is not going to be viable for at least 5 to 10 years.

The problem is in the definition of an IoT device, if you talk sensor <$20 yes I agree. Even DTLS will probably take up too many resources, only thing you can do for that money and the internet is one way direction, so only outside communication, like UDP messages fire and forget to some server in the cloud. You don't have or need an open port for that and you still have information from the cloud to the user.

The only ability an IoT device needs to have is:
1) decrypt incoming messages using a preloaded key
2) encrypt outgoing messages using a preloaded key
3) keep the key a secret
4) allow remote reprogramming of the key
The key is used for both authentification and authorisation. A standard way of doing this isn't complicated.

Part 3 is the major problem in that scenario and also if you do not want all devices to have the same key the upgrade should be unique for each device, which logistically will become a nightmare.

What I do see as a possible development is that people just gonna drop their IoT privacy. The IoT device will just in the clear shout all its data to the users mqtt message broker and don't care if someone can see it. Hell half the world sends their dayly doings on social media anyway who cares about some binary sensor data? 

[Kjelt]

This will involve STM32F107RCT6 or STM32F407RGT6 implementing a full TLS 1.2 stack (and IPv6 as my home network has it.)

Which one, OpenSSL, Polar or WolfSSL or ? And what is the footprint of the IP stack and the TLS stack ?

[nctnico]

The biggest problem with a full TLS stack is that it takes way to much memory because of all the excess baggage which comes with TLS like key exchange during the link initialisation phase.

On the other hand, I just tested an embedded device running OpenSSL from may 2016 and there were already 30+ vulnerabilities found in the mean time so they had to upgrade to the latest and greatest.

IMHO that is another problem with TLS: it can do too much so it has too many ways to go wrong. I'm not saying an IoT protocol will be safe from day one but it needs to have way less functionalities so less can go wrong.

[Kjelt]

TLS is big but hey it was never designed or intended to be used for embedded/IoT devices.
For an embedded device a single 4kB key for each and every server to deal with is huge because to use it and receive it is going to eat their small amount of RAM, but for a PC that is nothing.
But help is underway, small secure protocols are being developed however it is harder to keep it secure if resources are constrained, some things you just should not do or want to do 

[Jeroen3]

You need to keep them secure to their area of operation. Your hue's for example don't all connect to the internet.
There is an hub that connects to the internet with an STM32F217VE with crypto and some extra flash.

Each light does not need to fight the internet, it needs to fight the surrounding 20m of wireless zigbee.
The hub also does not need to the fight the internet, it needs to fight local LAN.
You router has to fight the internet. Which has a much more powerful processor, and lots or ram and crypto acceleration.

There is a reason Google wants to make an OnHub, the center of all your IoT. Either to rule them all, or because the devices can't protect themselves.

[technix]

The biggest problem with a full TLS stack is that it takes way to much memory because of all the excess baggage which comes with TLS like key exchange during the link initialisation phase.

On the other hand, I just tested an embedded device running OpenSSL from may 2016 and there were already 30+ vulnerabilities found in the mean time so they had to upgrade to the latest and greatest.

IMHO that is another problem with TLS: it can do too much so it has too many ways to go wrong. I'm not saying an IoT protocol will be safe from day one but it needs to have way less functionalities so less can go wrong.

A minimal TLS 1.3 implementation don't do that much.

[nctnico]

Yeah but a minimalist TLS implementation is very probably not be compatible with all systems so feature creep will bring it back to a full implementation with all the extra bugs.

[technix]

Yeah but a minimalist TLS implementation is very probably not be compatible with all systems so feature creep will bring it back to a full implementation with all the extra bugs.

The minimalist implementation is itself the minimal implementation of TLS 1.3, or with minimal feature creep, a minimal implementation of TLS 1.2 without compatibility to anything older than two or three years.

And I am okay with throwing off support to anything not running the latest OS and software. Older systems are vulnerable to other problems anyway.

[radar_macgyver]

You need to keep them secure to their area of operation. Your hue's for example don't all connect to the internet.
There is an hub that connects to the internet with an STM32F217VE with crypto and some extra flash.

Don't know about OnHub's implementation, but many others fall flat on other fronts. For example, the Wink hub, which has lots of radios and advertises compatibility with many device families. However, it requires an active internet connection to implement any rules, since they rely on the Wink server to handle it for them.  I can only imagine it's some sort of data-collection driven need to do this, since the CPU used in a Wink hub should easily be able to handle simple rule-based logic. Then there's MiCasaVerde's Vera hub, which started out great, until they released awful software that's super slow. Any change requires click after click. Domoticz (what I currently use) is much faster, but since it's open source, support for hardware lags the market.

[TNorthover]

Well that is a dumb move by Apple because TLS isn't going to be the IoT standard -period-.

Until that standard comes along, requiring TLS is probably better than letting every random idiot come up with something that they swear their cat couldn't break (or not bother with encryption or authentication at all).

[NorthGuy]

Still waiting for the microcontroller manufacturers to integrate a small piece of secure otp or other piece of memory that is outside the uC memorymap (so unreadable by programmers or hackers) that can be used in some sort of keyderivation operation by the security peripheral.

PIC24F256GB412 and family.

[dmills]

One of my friend have an IoT-disrupting backpack. Inside there is a battery bank, a Raspberry Pi and a lot of IoT interface chipsets attached to it - nRF24L01+, LoRa, Bluetooth, WiFi - you name it, he has it. The Pi have code searching for unsecured IoT devices and send them into haywire. Now let's hope he don't walk by your home with his backpack...

All of this stuff tends to run in the ISM band so actually there is no expectation that you will not be interfered with, and running a transmitter that complies with the rules is legal even if it causes interference with other users of the band, that is kind of the point of the ISM bands.

Now deliberately designing something to stuff up other folks use of the band is a dick move, but I cannot really see that anyone has an expectation that RF links using those bands will not be messed with either by accident or with malice (Actually goes for any RF band user).

It is up to the designers of ISM band kit to ensure that it tolerates interference and has a sane fallback option when the RF link is receiving nonsense (Even nonsense that looks like maliciously malformed data).

I would note also that attacks on crypto are somewhat rare, attacks on implementations are where it is at. Much easier to find a buffer overflow, XSS or SQLi attack on some badly written web control interface then it is to be doing the number theory to be going after the crypto directly.

For me the big problem with a lot of the IOT stuff is that updates are not something that seems to be well understood by the manufacturers, consumer goods companies are not really with the idea that they still need to be pushing timely firmware updates to those LED bulbs that they stopped selling 4 years ago....

A big part of this is that for most users the internet is no longer end to end, A lightbulb with an IPV6 address I can firewall, add port knocking, tunnel, whatever makes sense, a lightbulb that makes a badly secured connection to a remote server that then forwards traffic from outside is a much harder problem to deal with because it pushes the problem out of my control.

It is not in the common cases even about attacking the wireless links because that is a strictly local attack, the serious problems are attacks that can be automatically mounted over the internet as that scales far better then a vandal with a SDR does, and creating botnets is a numbers game.

Regards, Dan.