Microcontroller Cryptography Investigation

[technix]

We all know that IoT hacking is a thing and IoT traffic should be secured. I want to start a thread benchmarking crypto performance on various microcontrollers.

Methodology: For each algorithm, a maximum optimized implementation is used, which takes advantages if any and all available hardware accelerators. Then 512MB of white noise is being encrypted and decrypted to gauge its speed.

Algorithms: AES256-CTR-SHA256-HMAC (AES, 256-bit key, counter mode, separate HMAC based on SHA256), AES256-CCM (AES, 256-bit key, counter mode with CBC-MAC), AES256-GCM (AES, 256-bit key, Galois-Counter mode), Chacha20-Poly1305. All four cipher suites are TLS 1.2/1.3 AEAD ciphers

[westfw]

Isn't most "IoT hacking" more of an authentication problem than an encryption problem?
Who cares how long it takes to decrypt 512MB of data - that's more than I expect by IoT device to receive over its entire lifetime.

(OTOH, since most of the widely publicized attacks are on things like IP cameras and printers...)

[technix]

Isn't most "IoT hacking" more of an authentication problem than an encryption problem?
Who cares how long it takes to decrypt 512MB of data - that's more than I expect by IoT device to receive over its entire lifetime.

(OTOH, since most of the widely publicized attacks are on things like IP cameras and printers...)

This is the slowest of all security primitives. With efficient AEAD symmetric cipher efficient implementation of TLS can be constructed. Then you can start talking about IoT security.

[westfw]

Meh.  IoT security is more of a Systems Administration problem than an encryption problem.  If you can't even get people to enter a non-default password...

My security-involved friends are making favorable mumblings about things like the Atmel "CryptoAuthentication" chips ( http://www.atmel.com/products/security-ics/cryptoauthentication/default.aspx ), which are chip, small, things with relatively low-speed (1Mbps I2C) interfaces...

[rs20]

I'm not sure the results of this experiment would sway me; unless a chip that I was planning to use proved to be spectacularly underperforming. So I guess it sounds valuable from that point of view alone, although I'd be most interested in this from a position of pure curiosity alone.

Meh.  IoT security is more of a Systems Administration problem than an encryption problem.  If you can't even get people to enter a non-default password...

Security, or at least one-way security, doesn't require a password. For example Diffie-Hellman Key Exchange enables TLS (and therefore HTTPS) sessions to be immune to interception, all before any passwords even change hands. Highly secure private keys can be handed out from a central server when a device is first activated, once again making the question of passwords irrelevant.

If someone installs an internet-accessible webcam in their bedroom and leaves the default password on it, well then (arguably) that's just their fault. That doesn't mean that people who know about the value of good passwords should be denied good security, and we (as designers of webcams and IoT thingos) have a responsibility to make this level of security available.

Thus, dismissing security as a problem not worth considering because there are human factors at play is the height of laziness and unacceptable. I mean, if the majority of stolen bank accounts are due to people choosing bad passwords, does that mean that you'd be OK with your bank just giving up and disabling all security on your connection? What on earth are you even saying?

My security-involved friends are making favorable mumblings about things like the Atmel "CryptoAuthentication" chips ( http://www.atmel.com/products/security-ics/cryptoauthentication/default.aspx ), which are chip, small, things with relatively low-speed (1Mbps I2C) interfaces...

So you do realize that the I2C interface being limited to 1Mbps does not make a data encryption rate of 50 MBps infeasible, right? If this seems like a novel concept to you, you really do need to read up on Diffie-Hellman as a very first introduction.

[westfw]

So you do realize that the I2C interface being limited to 1Mbps does not make a data encryption rate of 50 MBps infeasible, right?

No, I didn't.  It's pretty dependent on how the chip actually works, isn't it?  It COULD be set up so that you have to pump all your data through it, or I guess it could be set up to share processing with whatever is accessing it.   I didn't look into the details of how the chip works, and my DH is knowledge is rusty and slim (took and passed the first Stanford MOOC; went "whoa; everything is more complicated than I thought, and almost everything is broken!", haven't encrypted anything since...)

Highly secure private keys can be handed out from a central server

central servers have their own sets of problems.  One of the big ones is that the people who operate the central servers seem to want to be paid rather continuously, by somebody.  So "security by server" seems to happen mostly on subscription-based things.

dismissing security as a problem not worth considering because there are human factors at play is the height of laziness and unacceptable.

I'm more along the lines of thinking that "fancy and computationally expensive encryption is necessary or sufficient to make IoT devices "secure" is the height of ivory-tower blindness to the real world."

I do agree that IoT needs to do better than it is now.  But doing that without willful cooperation of the users is a REALLY HARD PROBLEM, entirely independent of encryption algorithms.  And the truth is that no one really wants to be a sysadmin for their light bulbs, thermostats, irrigation systems, and so on.

[technix]

I'm more along the lines of thinking that "fancy and computationally expensive encryption is necessary or sufficient to make IoT devices "secure" is the height of ivory-tower blindness to the real world."

I do agree that IoT needs to do better than it is now.  But doing that without willful cooperation of the users is a REALLY HARD PROBLEM, entirely independent of encryption algorithms.  And the truth is that no one really wants to be a sysadmin for their light bulbs, thermostats, irrigation systems, and so on.

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...

Speaking of Raspberry Pi, it comes with a built-in true random number generator, good for generating very high quality cryptographic keys to be injected into the devices. A BJT reverse biased can be used to generate shot noise - a quantum-backed true random number generator - for any MCU with a spare ADC channel. This way your devices can generate its own cryptographically strong private keys and send the public key off for signing and authenticating.

[nctnico]

I'm more along the lines of thinking that "fancy and computationally expensive encryption is necessary or sufficient to make IoT devices "secure" is the height of ivory-tower blindness to the real world."

I do agree that IoT needs to do better than it is now.  But doing that without willful cooperation of the users is a REALLY HARD PROBLEM, entirely independent of encryption algorithms.  And the truth is that no one really wants to be a sysadmin for their light bulbs, thermostats, irrigation systems, and so on.

If you read about security then one of the basics is that security is based on Authorisation, Authentification and Accounting (keeping track of what happens). It doesn't even say a thing about encryption! IMHO encryption is way too often used as some magic sauce to try and make a system secure.

[technix]

I'm more along the lines of thinking that "fancy and computationally expensive encryption is necessary or sufficient to make IoT devices "secure" is the height of ivory-tower blindness to the real world."

I do agree that IoT needs to do better than it is now.  But doing that without willful cooperation of the users is a REALLY HARD PROBLEM, entirely independent of encryption algorithms.  And the truth is that no one really wants to be a sysadmin for their light bulbs, thermostats, irrigation systems, and so on.

If you read about security then one of the basics is that security is based on Authorisation, Authentification and Accounting (keeping track of what happens). It doesn't even say a thing about encryption! IMHO encryption is way too often used as some magic sauce to try and make a system secure.

There will be Confidenciality, Integrity and Availability assumptions in most Authorization, Authentication and Accounting schemes which have to be fulfilled by using cryptographic primitives appropriately. (Not so much about Availability, but the remaining two...)

The cryptographic primitives employed by TLS, in effective TLS itself, can be used to construct a secured channel on which the CIA assumptions of AAA are fulfilled. Among those primitives the symmetric (bulk) cipher is the heaviest used and hence benchmarked here. All four cipher suites here offers some AEAD (that includes ARS256-CTR-SHA256-HMAC although it is prohibited in TLS 1.3 while allowed and considered strong in TLS 1.2,) with three of them available in the latest TLS 1.3 draft which mandated strong AEAD cipher (AES256-CCM, AES256-GCM and ChaCha20-Poly1305)

[Kjelt]

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.
uCs benchmarking is dependent on your application, if you want internet connectivity the weakest link is the huge amount of codesize neccesary to implement a secure ethernet stack that can handle multiple protocols. The micro itself like a m3 or m4 is fast enough, the tls handshake with the asymetric (pk) crypto takes the most time 100s of ms) The AES symmetric data encryption took 10% overhead on my projects (ms,s)

[nctnico]

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.

That is a contradiction. If a memory like that can be accessed somehow it can be read (or written if possible).

[Bruce Abbott]

Now let's hope he don't walk by your home with his backpack...

Your 'friend' better not walk by my home with that stuff turned on - for his sake.
 

[jnz]

. Highly secure private keys can be handed out from a central server when a device is first activated, once again making the question of passwords irrelevant.

I feel like everyone else missed this - I hope you mean central server giving the device a private key AT PRODUCTION and not when in use in the customers hands!

Asymmetric encryption:

• Data encryption, this is using (for example) an ECC PUBLIC Key to encryption something that only the PRIVATE key can decrypt. You do NOT hand out PRIVATE keys, you hand out PUBLIC. The issue with this is that you hand out the public key to someone, you don't actually know it was them that encrypted something. This gets into ECDH transfers and certs.
• Data Signature, where again using ECC as an example, the PRIVATE key adds a signature to some block of data, then anyone with the PUBLIC key can verify that this is legit. It's slightly confusing because in this case the public key is used to "decrypt" (but not really) which is backwards from using the public to encrypt (actually). In this case you still do NOT hand out PRIVATE keys. You use your private key to sign data, public key to verify it, anyone can verify only one can sign. The issue here is that your data is not encrypted, anyone can read it - but no one can change it.

Seeing you guys of all people write "hand out private keys" and no one correct it. Tisk Tisk!


In terms of the topic at hand. No. This is pointless. I can tell you an ARM Cryptocell or any hardware AES or ECC function is going to outperform any software out to a micro being 7-10x faster.

As to Atmel's Cryptochips... I looked into them. They're nice if you trust the I2C connection where you can pass a block of data in and get it encrypted, but if someone is trying to hack your device, you better have a better plan than one that can be easily thwarted with a logic analyzer. Most of the time these cryptochips are for storing a known OTP cert on, or they're programmed with the private key in an "unhackable" device and it sends the module the public key to use for encrypting or verifying the signing.  Using one to encrypt your data means you must trust the I2C physical connection, and IMO, that's dumb.

For those cryptochips, don't think ECC encrypting data device to secure all IoT traffic. Think printer cartridge loaded with a unique and validatable cert to prevent knockoffs.

[Kjelt]

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.

That is a contradiction. If a memory like that can be accessed somehow it can be read (or written if possible).

The result can be read and the input written but all operations inbetween are for the microcontroller itself a blackbox operation. Think small cheap tpm like functionality.

[Kjelt]

For those cryptochips, don't think ECC encrypting data device to secure all IoT traffic. Think printer cartridge loaded with a unique and validatable cert to prevent knockoffs.

Yes those are authenticators. There are chips from Infineon that on their own can handle the entire tls protocol, where the uC is only the ethernet interface and shuffles the data throughput. However as you mention in the end the cleartext data has to be sent to the uC in order to do something usefull and any outside device is vulnerable in its communication. Besides those chips cost a bloody fortune well more than the uC itself.

[jnz]

There are chips from Infineon that on their own can handle the entire tls protocol, where the uC is only the ethernet interface and shuffles the data throughput. However as you mention in the end the cleartext data has to be sent to the uC in order to do something usefull and any outside device is vulnerable in its communication. Besides those chips cost a bloody fortune well more than the uC itself.

It took me awhile to understand how these chips were useful, and I pretty much decided they kind of aren't. I mean, for me. If you need fast encryption access and your micro doesn't have it, fine. But I just would feel like I was giving up too much by allowing anyone with a logic analyzer to see the unencrypted data.

Its been my prerogative the pre-shared key/cert outside of the user's hands is probably safer but I'm not doing web TLS.

[westfw]

anyone with a logic analyzer

The current set of IoT "security problems" are not the sort where logic analyzers are an "expected attack vector"...
The expected set of IoT "security problems" are not the sort where logic analyzers are an "expected attack vector"...

Now, if the logic analyzer can figure out an attack that breaks ALL of the IoT devices of that type, THAT'S a problem.
It really bugs me when "security folk" go off on "if a device can be broken with $100k worth of equipment and some liquid nitrogen, doing side-channel attacks based on power consumption, you might as well have done nothing at all" tangents...

[nctnico]

I don't think that anyone is claiming that no encryption needs to be applied because it will be broken anyway. It is just that allowing (simple) access to unencrypted data makes it easier to do a brute force attack on the encryption key.

[technix]

Now let's hope he don't walk by your home with his backpack...

Your 'friend' better not walk by my home with that stuff turned on - for his sake.

I doubt whether he would still be close to your home when the payload finally goes off. Or if you can pinpoint him among the crowds of pedestrian walking by.

[Kjelt]

It really bugs me when "security folk" go off on "if a device can be broken with $100k worth of equipment and some liquid nitrogen, doing side-channel attacks based on power consumption, you might as well have done nothing at all" tangents...

Then you have not spoken to a true security person since such a person would state that security is like an onion, you need multiple layers (as many as possible/affordable) of security.
If one fails another one should be in place.
One of those layers is physical access to the device, the ballgame gets much harder when you have to account for an attacker to have physical access to the IoT device itself.
If you sell products where everyone could have access you better have your stuff in order, so not one big secret somewhere in the code for all devices, because if you do than yes if someone can easily find it or sniff it (even with $10k of equipment) you are toast.

[Kjelt]

I don't think that anyone is claiming that no encryption needs to be applied because it will be broken anyway. It is just that allowing (simple) access to unencrypted data makes it easier to do a brute force attack on the encryption key.

It is worse, the transport is secure (TLS) but the decrypted plaintext data is sent back to the uC over a non encrypted channel (SPI or I2C), you need nothing to brute force just sniff the data back with an analyzer.
The whole issue is that using an external security chip provides some level of defense but not againtst physical access to the device.
There is only one way to do that properly and that is integrate the security on the endpoint chip itself (the uC).

Now the semicon companies I talked to that have this technology are not able to integrate the two, because they say that the secure part has to be in a high nm process with all kinds of technical challenging stuff like multilayer, intrusion detection grids etc. etc. and that the uC has to be in a low nm process in order to be small enough and affordable enough. So the two do not mix well
Broadcom could do it and they are doing it for expensive controllers like you find in the $160 routers etc. those chips are probably costing > $5 below 1Mpcs
So this is not your ordinary IoT gadget device pricepoint, and that should be the lesson to all: do not think you can make an affordable IoT device without proper security.
If you do want to have cheap IoT devices do NOT let them have a public facing ethernet interface, let them talk on their own subnet (or wireless) to a gateway which can be more expensive and let that device be the only thing visible to the outside.

[Jeroen3]

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.

https://twitter.com/terrajobst/status/850766832390750209/photo/1

You can't use encryption to fix bugs.

[technix]

I don't think that anyone is claiming that no encryption needs to be applied because it will be broken anyway. It is just that allowing (simple) access to unencrypted data makes it easier to do a brute force attack on the encryption key.

It is worse, the transport is secure (TLS) but the decrypted plaintext data is sent back to the uC over a non encrypted channel (SPI or I2C), you need nothing to brute force just sniff the data back with an analyzer.
The whole issue is that using an external security chip provides some level of defense but not againtst physical access to the device.
There is only one way to do that properly and that is integrate the security on the endpoint chip itself (the uC).

Now the semicon companies I talked to that have this technology are not able to integrate the two, because they say that the secure part has to be in a high nm process with all kinds of technical challenging stuff like multilayer, intrusion detection grids etc. etc. and that the uC has to be in a low nm process in order to be small enough and affordable enough. So the two do not mix well
Broadcom could do it and they are doing it for expensive controllers like you find in the $160 routers etc. those chips are probably costing > $5 below 1Mpcs
So this is not your ordinary IoT gadget device pricepoint, and that should be the lesson to all: do not think you can make an affordable IoT device without proper security.
If you do want to have cheap IoT devices do NOT let them have a public facing ethernet interface, let them talk on their own subnet (or wireless) to a gateway which can be more expensive and let that device be the only thing visible to the outside.

This is why I am investigating crypto on micro. If I can run a full TLS stack with elliptic curve public key cryptography, SHA256 hash and ChaCha20-Poly1305 AEAD cipher, I get a complete, strong TLS 1.2/1.3 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. 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 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.

[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. 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 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.

If you find TLS too cumbersome, you can use something like PGP-over-HTTP. Although this does sacrifice perfect forward secrecy which TLS 1.3 offers.

I have a project coming up soon, implementing a NeoPixel LED strip controller with wired Ethernet. It controls the LED lighting in my multi-computer rack so control must be shared. I don't have a second managed Ethernet switch so it have to work in my Internet-facing main network. This will involve STM32F107RCT6 or STM32F407RGT6 implementing a full TLS 1.2 stack (and IPv6 as my home network has it.) The cipher suite I would support is ECDHE-ECDSA-ChaCha20-Poly1305 (a TLS 1.2/1.3 AEAD cipher suite with perfect forward secrecy) and also a TLS certificate using elliptic curve cryptography.

[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.