Electronics > Microcontrollers

The cost of "security"

(1/31) > >>

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.

evb149:
Maybe they should *also* have manual control, but that's not enough.
"cloud" means "someone else's computer".
The OP said literally:
"a whole industry has grown up around this "security, privacy, etc" stuff and most of it is wasted. "

Which is actually beyond wrong -- doing this "cloud uber alles IoT" stuff is actually diametrically
OPPOSITE of security & privacy.

If I as a consumer buy a piece of IT gear I expect and require nothing less than:
1: Who owns it?  Me.  Not the vendor / manufacturer, me, full stop.
2: Who's the "root" and only sysadmin?  Me, exclusively.
3: Who's in control of its settings / configuration / preferences / policies, et. al.?  Me, exclusively.
4: Does it go out and talk to any other network / host?  Only if I explicitly configure it to in full detail / scope.

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.

6: If you want to impress me with your "cloud" offerings on how it can optionally talk to IFTTT or SMTP or whatever, ok, well, set up some nice cloud servers and offer me an optional free account or something, but I better damn well be able to either do without that or do it under local control of my own equivalent privately run server  / proxy / whatever I choose so your "free" server's insecurity / failure / winking out of existence when your company goes under doesn't deprive ME of the use of MY IT gear I OWN.

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.

If my IoT refrigerator is talking to your "cloud" server (and whatever legion of absolutely unnecessary and undesired analytics, metrics, tracking, adware, ... server connections infest its firmware, software, app, web pages) that's a direct threat to MY
security and MY privacy.   

So how dare anyone even posit the concept that "it's for your own good", "we protect your privacy", "we protect your security" and yet flagrantly violate every ethical and logical sense of security, privacy, ownership, and property rights by trying to do anything other than let me worry about my business in private.

So I've seen things like IoT controlled light bulbs that you LITERALLY cannot turn on and off without using some APP that unavoidably sends the "request" to a bloody SERVER IN CHINA so I can, maybe, (if the IOT parasite, the ISP, the internet, and six servers in CHINA feel like working at the moment) sit in East Dakota and turn on the light in my bathroom or whatever.

You can't make this stuff up.  What it speaks especially poorly of is any shred of sensibility or integrity in the engineers (and the list does not stop there) that sit in conference rooms and assent to creating piles of crud like this to begin with.

Let's see most of a typical lot of IT networking gear has something like a SNMP MIB and you have a bunch of feature control settings you can read or write to change settings or monitor status and all you need is the right login / password on your local admisistrative network / client.   I'm not the biggest fan of the protocol but hey it has worked for decades and typically controls things a lot more important than light bulbs and IoT coffee makers.  And it's quite easily done under purely local control via a client or app or whatever.

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.

Seriously if you're going to use your "genius" inventing things how about IoT freaking light switches that I can actually turn on and off and change the color without asking six chinese servers on the other side of the planet?!  It isn't hard, really.

So now we live in a world where there is 62 kinds of spyware / adware / trackers etc. on just about every web site, embedded in all of our phones, tablets, embedded right in our PC operating systems (I'm looking at you Apple, Microsoft) and to add icing on the cake we can get analyzed / tracked / remote controlled by our IoT gadgets, too.

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

Why do people have to HATE their customers and fellow earthlings so much that they don't even "let" them (by design) run their own gear / software and use the internet with some ACTUAL security, privacy, autonomy, and independence?




--- Quote from: tepalia02 on June 20, 2022, 10:07:55 am ---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.

--- End quote ---

peter-h:

--- Quote ---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.
--- End quote ---

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.


--- Quote ---Which is actually beyond wrong
--- End quote ---

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:

--- Quote from: peter-h on June 20, 2022, 09:14:16 am ---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.

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version