The cost of "security"

[peter-h]

I am working on what would today be fashionably called an "IOT" product.

After probably a man-year, plus loads of libs like ST ETH, LWIP, USB, etc (most of which were buggy as hell) the code size is 170k. Not bad for a 1MB FLASH CPU. The 128k RAM has 60k spare.

Now we add MbedTLS, so one can do HTTPS. Code goes up by another 150k and the 60k spare RAM is now 10k. The "Mbed" is a bit of a joke really

And what does it achieve? Very little, it seems. IOT boxes can't be on open ports, because these are discovered by sniffers almost immediately, due to back doors and vulnerabilities which cannot be fixed (a 100BN $ company like M$ is still patching back doors in Windoze after 30 years, so an embedded coder has absolutely zero chance, and then new ones will be discovered after the product is sold and installed somewhere) so their "internet access" can only be as a client, calling up some server, and hidden behind a NAT router.

But if you are calling up a server which you control, you don't need the whole TLS crap, with PK, session key negotiation, x509 authentication. You can just use a shared key, with AES256 or whatever. You have the key dist issue but with PK you still need 100% secure "access control" on each box because the private key has to be secure. You don't need auth because a fake server won't be able to read the data anyway.

And if the IOT box is to call up some "public service" server, the certificate for that will expire regularly, so you need the whole root certificate store, currently about 200k, and a means of periodically updating that, too In the context of embedded systems, it mostly can't be done practically, and even if it can be done, it will sooner or later break or be forgotten (even the biggest firms have had their website certificates expire because the person whose job that was has left, etc).

It seems to me that a whole industry has grown up around this "security, privacy, etc" stuff and most of it is wasted.

The other thing is that "IOT" is going to end up with a really dirty reputation, as companies go bust, or just stop maintaining the servers. So the remotely controlled irrigation system, where you have a nice app connecting to that server, or even just a website served by that server, goes dead one day and there is no way to fix it. You have to rip the whole lot out.

[tepalia02]

The last paragraph is really something to consider seriously. This is why all IoT devices should have the option of manual control also. Just like the sonoff IOT switches have manual on-off push buttons.

[peter-h]

Anyway one could also look at MQTT or COAP or YAML configuration files or RPC or TCP APIs or any number of other things.
Most test equipment speaks, say, SCPI, simple, usually works, does not require the cloud.

The thing is that no matter how you shake this, you cannot have IOT boxes on open ports.

Access has to be via a "cloud".

It has to be thus for vulnerability reasons (experience shows that one can keep a reasonably secure unix server running for years without any maintenance).

And it has to be thus for commercial reasons: selling boxes, you make money only once, so your market will saturate, and getting say $2/month for the "cloud" keeps the money coming in.

There already is a big business around the second bit, with e.g. AWS doing MQTT servers.

Which is actually beyond wrong

Not really; I was referring to the security overhead of the comms between IOT and the "cloud", where the security requirement isn't specially difficult.

[madires]

And what does it achieve? Very little, it seems. IOT boxes can't be on open ports, because these are discovered by sniffers almost immediately, due to back doors and vulnerabilities which cannot be fixed (a 100BN $ company like M$ is still patching back doors in Windoze after 30 years, so an embedded coder has absolutely zero chance, and then new ones will be discovered after the product is sold and installed somewhere) so their "internet access" can only be as a client, calling up some server, and hidden behind a NAT router.

Yep, exposing IoT devices directly to the public internet is a bad idea because of the many security issues they have. However, access within a separated local network is usually fine and often necessary for management reasons. If remote access via internet is needed a VPN connection to your router can help. I'd also like to add that NAT isn't a security feature - the stateful firefall is. It's a common misconception.

PS: I consider any IoT device which requires the cloud as e-junk.

[peter-h]

If remote access via internet is needed a VPN connection to your router can help

True, and then you can use plain old http, but in a commercial context expecting people to set up VPNs is a total loser. I have set up so many of these... it would be a customer support nightmare.

I'd also like to add that NAT isn't a security feature - the stateful firefall is. It's a common misconception.

Sure, but NAT is still very very good. The router normally closes the hole after 180 seconds.

I consider any IoT device which requires the cloud as e-junk.

How would you solve the hacking issue?

[madires]

5: If the IoT thingy is supposed to be a "client" that talks to a server, ok, well in that case I better see the open source "server" implementation, client-server API documentation, et. al. on the vendor's git hub or similar distribution so I can run a locally hosted and controlled server on whatever host I may want on whatever LAN I may want without any "internet" connectivity needed.

Absolutely! Or the device supports a well documented protocol.

[Kjelt]

If you have a small IOT device you should tweak the security library to your demands, which means deleting 75% of the library. Only keep what you need to support and yes you're task is to keep it safe, read all the new security vulnerabilities, update , etc. And indeed you might not want your device directly to the internet just as you probably also don't want your linux server there, unless you're a linux admin and love to keep that thing up to date etc.

[madires]

True, and then you can use plain old http, but in a commercial context expecting people to set up VPNs is a total loser. I have set up so many of these... it would be a customer support nightmare.

It has become easier with WireGuard, IMHO.

Sure, but NAT is still very very good. The router normally closes the hole after 180 seconds.

It's the connection timeout of the stateful firewall. Think IPv6!

I consider any IoT device which requires the cloud as e-junk.

How would you solve the hacking issue?

Could you please elaborate which hacking issue(s) you mean? When I run a device locally with local access only I don't have to fear any internet scanners. If the device connects to some cloud server additionally it's an outgoing connection (I'd assume the connection is protected, e.g. by TLS).

[madires]

It has to be thus for vulnerability reasons (experience shows that one can keep a reasonably secure unix server running for years without any maintenance).

This sounds more like wishful thinking. No matter what, as long as you have a server connected to the internet you have to spend some effort to keep it up-to-date (following security related mailing lists, updating ASAP and so on). You can automate some tasks, but it won't be auto-magical.

And it has to be thus for commercial reasons: selling boxes, you make money only once, so your market will saturate, and getting say $2/month for the "cloud" keeps the money coming in.

Exactly! This is the real motivation for the current state of our lovely cloud-based IoT devices. You'll own nothing and be happy.

[MadTux]

Microcontrollers are there to "control" things, not to connect every toaster to the internet!!!

Have fun patching all that unnecessary garbage and with having a hacked fridge that phones with FBI, NSA, CIA, FSB, Mosad, the Nigerian prince and god knows whom, I'll never buy such crap.

The only good thing that comes from that, that you can get quite fast microcontrollers with about endless memory/flash for very little cash nowadays. But all those resources are soon consumed with IOT garbage code.

[peter-h]

as long as you have a server connected to the internet you have to spend some effort to keep it up-to-date (following security related mailing lists, updating ASAP and so on). You can automate some tasks, but it won't be auto-magical.

Sure, but people do this all day long. The standard unix OS + server packages are way more robust than the stuff people use for embedded systems. This has to work otherwise the WWW would vanish

[janoc]

It has become easier with WireGuard, IMHO.

Completely missing the point, IMO. Try to get your Wireguard (or any other VPN solution) through some corporate IT. Good luck with that one.

Heck, even getting a single outgoing port authorized/opened on a corporate firewall can be a month-long fight of paperwork, meetings, more paperwork - and then the port will be randomly closed again whenever some IT grunt decides to restore/reload router configuration from a backup that has not been updated ... Been there, done that ...

And if the customer doesn't have obtuse/obstructing IT dept. they likely don't have the knowledge/skills in house to maintain a VPN neither. So it will be on your back to support them because it was you who has sold them the internet connected gizmo.

If the device is something intended for consumers then expecting someone who buys that proverbial internet-connected light bulb to know how to set up a VPN is just a complete non-starter.

It's the connection timeout of the stateful firewall. Think IPv6!

Not sure what IPv6 has with it at all  Also, IPv6 still doesn't work everywhere (or if it does then there is no guarantee of performance, throttling and random issues). In addition all sorts of networks are connected/tunneled in all sorts of weird and wonderful ways (such as carrier-grade NATs common on cell networks).

[peter-h]

Not my quote

[tellurium]

If my IoT refrigerator is talking to your "cloud" server (and whatever legion of absolutely unnecessary and undesired analytics, metrics, tracking, adware

For the big business, it is actually very necessary. It is actually a key. Many products got IoT capability just because of that, whilst user experience is not really important. Why? Because IoT gives a way to "spy" on the customer behavior after the sale. Collecting stats gives an ability to tune the functionality of the product to be most profitable. And that's what big businesses care about, and they can get creative with marketing convincing people that they need that shiny IoT stuff.

Big business drives big money, and the whole industry in the end. So whether we like it or not, that's what is going on.

[Doctorandus_P]

I don't understand what particular brand of crazy these people are that think it is remotely ethically or logically reasonable to sell people devices and yet give the OWNERs anything less than full control of them.

There are companies with an ethical conscience, but most don't, especially when they think about profits, the ethical section gets shoved under the carpet. This will only change when their customers demand it, but all too often those customers think about short time convenience and are not even interested in technical details. Back in the '80-ies computers were simple enough to be understood by a single person, but some 20+ years ago they became so complicated that there is simply nobody in this world who can understand how they work anymore. You can only know some parts in detail, the rest superficially, and then hope the parts work together properly.

1984 was supposed to be a warning, not an instruction manual.

Indeed.
I just do not have any of that iot stuff, and It won't enter my home either.

[tellurium]

But if you are calling up a server which you control, you don't need the whole TLS crap, with PK, session key negotiation, x509 authentication. You can just use a shared key, with AES256 or whatever. You have the key dist issue but with PK you still need 100% secure "access control" on each box because the private key has to be secure. You don't need auth because a fake server won't be able to read the data anyway.

Actually you do need the whole TLS crap.
Inventing your own security rather than using an industry standard (TLS) - is asking for trouble.
Running a server on a device, other than temporarily for setup - is asking for trouble.
Not using TLS for outgoing connection can be viable - depends on the use case. If that's for the firmware self-update, then it is asking for trouble. If that's for some sort of non-essential stats tracking - might be OK.

[Kjelt]

Actually you do need the whole TLS crap.

Not all, you can remove all the cipher suites you don't support, not only the broken old ones also the very heavy resource occupying ones.
You can even only support one light weight cipher suite, as long as it is safe.
That will safe you more than 50% of the TLS code, perhaps 80% if you play it right.

[nctnico]

But if you are calling up a server which you control, you don't need the whole TLS crap, with PK, session key negotiation, x509 authentication. You can just use a shared key, with AES256 or whatever. You have the key dist issue but with PK you still need 100% secure "access control" on each box because the private key has to be secure. You don't need auth because a fake server won't be able to read the data anyway.

Actually you do need the whole TLS crap.
Inventing your own security rather than using an industry standard (TLS) - is asking for trouble.

Yes and no. For a secure connection with pre-shared keys and using 1 encryption algorithm (some form of AES) you only need about 1% of the entire TLS stack. Been there, done that. Nobody is suggesting to come up with a new encryption method!

[james_s]

Some time back a colleague of mine quipped that "The S in IoT stands for Security"

[peter-h]

I would actually be quite interested in opinions on which cipher suites are worth supporting in a product launched say today but which has to be compatible, as an HTTPS client, with other old stuff.

As a client, probably old stuff doesn't matter much.

Much of the size of MbedTLS is cipher suites.

[madires]

It has become easier with WireGuard, IMHO.

Completely missing the point, IMO. Try to get your Wireguard (or any other VPN solution) through some corporate IT. Good luck with that one.

Do companies large enough to have an IT department deploy IoT devices which are controlled remotely via the internet? And how did they manage to deploy VPNs at large scale for employees working at home (COVID 19)? BTW, I didn't say that VPNs are easy, just that WireGuard makes things easier (vs. IPsec for example).

It's the connection timeout of the stateful firewall. Think IPv6!

Not sure what IPv6 has with it at all  Also, IPv6 still doesn't work everywhere (or if it does then there is no guarantee of performance, throttling and random issues). In addition all sorts of networks are connected/tunneled in all sorts of weird and wonderful ways (such as carrier-grade NATs common on cell networks).

IPv6 is meant to be used without NAT (It's available, and there's NAT64 as a transition method). This is what I was hinting at. I know, some telcos and companies are still living in the IP past. However, we have IPv6 for 20 years now and they all have to migrate to IPv6 sooner or later because of the lack of IPv4 address space.

[peter-h]

And how did they manage to deploy VPNs at large scale for employees working at home (COVID 19)? BTW, I didn't say that VPNs are easy, just that WireGuard makes things easier (vs. IPsec for example).

They did it by enforcing known and uniform hardware at both ends. Then you can deploy the same config to all. Same with OpenVPN - if you force everyone to use an Ipad then you can use the same config file for all.

because of the lack of IPv4 address space.

That was supposed to happen 20 years ago but since a way was found to have multiple domains on the same IP, the issue has gone away.

IPV6 also does not solve vulnerabilities because the same hacking can be done. For example every instance of win10 has its predefined IPV6 address but that just means hackers who know the ranges can target them, in the hope of discovering win10+ installations which are not behind NAT.

[SiliconWizard]

Anything connected to a non-local network is a huge mess to deal with. Stay away from that for as long as you can.

[capt bullshot]

Didn't read the other replies, so sorry if I repeat something:

IMNSHO, TLS on an embedded device is just pure humbug. It adds a lot of CPU load, and code / memory hogging to an otherwise rather simple device, just because "HTTPS everywhere" is kind of a hype pushed by "Internet security experts". They are right in many aspects, I have to admit, but not for a simple embedded device that isn't supposed to be exposed to the internet anyway. And if done so in spite of good advice, as long as there's no secret login credentials to protect, HTTPS is of no use here. If you need to protect your client from all these "man in the middle" and whatnot attacks that TLS / HTTPS is supposed to do, you need a lot more infrastructure than just a TLS lib on your device.
Remember, the original purpose of HTTPS was to protect the traffic from eavesdropping, not to securely identify and authenticate the server / client.
So my not so humble advice is: Drop TLS on that embedded device and put a proper reverse proxy in front of it that does all the TLS infrastructure stuff.

[peter-h]

If you need to protect your client from all these "man in the middle" and whatnot attacks that TLS / HTTPS is supposed to do, you need a lot more infrastructure than just a TLS lib on your device.

Ultimately, to authenticate, you need to have a physically secure device, because if somebody can install a fake DNS server on your LAN and get inside your box and change the certificates, everything will be just fine

Drop TLS on that embedded device and put a proper reverse proxy in front of it that does all the TLS infrastructure stuff.

What is a reverse proxy? Isn't that another server which somebody has to set up and admin, for ever?