On Wed, Mar 13, 2024 at 6:43?PM Peter wrote:
On Wed, Mar 13, 2024 at 2:56?PM Peter wrote:
On 13/03/2024 18:25, Peter wrote:
If the camera was a client, uploading images or a video stream to a server (which has a properly secured user side) ...
It is a non-trivial task to secure a server. If it was easy there wouldn't be news articles like https://www.cnn.com/2024/03/08/tech/microsoft-russia-hack/index.html Russian state-backed hackers gained access to some of Microsofts core software systems in a hack first disclosed in January,
Sure, but how relevant is this to MbedTLS?
I was taking issue with your "... server (which has a properly secured user side)" which makes it sound trivially easy to secure a server.
Well, you have to start somewhere. If you assume that every bit of kit is compromised then you might as well commit suicide :)
There should be no debate that it is easier to secure an industry-standar server (running on an open port) then to secure an IOT box (running on an open port, which I assert is simply dumb, for many reasons).
... how could the camera be attacked? It will be behind NAT, for a start.
Ages ago I ran a TOR middle node on my home network. I noticed some strange traffic on my internal, **behind a NAT device**, network and found out that NAT wasn't the magical network protection device you seem to think it is. It turns out that loose source routing defeated NAT - see https://en.wikipedia.org/wiki/Loose_Source_Routing
Clearly some attack on NAT is possible if you control the server which the client is connecting to, by sending malformed packets to the client during the time the NAT channel is open (it closes 180 secs after cessation of data, normally).
Take another look at loose source routing - it's not an "attack on NAT" but a bypass of NAT: Loose source routing uses a source routing option in IP to record the set of routers a packet must visit.
Sure, but those links also say that most routing kit chucks out those packets.
If this was a real "volume" issue on the internet, every PC, phone, etc, would be on a botnet by now :) They all rely on NAT working - either NAT on your home router, or the equivalent method at the mobile telco.
Anyone can send traffic with that option and the 'set of routers a packet must visit' being a single IP address - the "outside" IP address of your NAT device and the destination address being something on your internal network.
- Attack server.
The MbedTLS version is not connected with that, however.
This showed up in my inbox today: [SECURITY] [DSA 5639-1] chromium security update ... Security issues were discovered in Chromium, which could result in the execution of arbitrary code
Do you use a browser on the same machine that you upload photos to from your camera?
I transfer photos from my phone to my PC via the home wifi. The phone is behind "NAT" of the telco if on 4G. But maybe I am not understanding you. If you built a camera with MbedTLS, it should still be a client. Do you mean the PC should be considered compromised, and then it could penetrate the camera (the phone) and run arbitrary code on the phone?
Yes. You've been using the browser on your PC. How do you know your PC hasn't been compromised? When the camera is talking to the PC there is nothing protecting the camera from the PC .. or anything else on the "internal" network behind the NAT device.
By the same token, you've probably been browsing the Internet on your phone. How do you know your phone hasn't been compromised? What's protecting all the devices on your home network when your phone is connected to your home wifi?
If you assume that everything is compromised then I agree you have lost the battle...
- Use the server as a relay to attack clients that connect to it.
The MbedTLS version is not connected with that, either. Plus the clients will be behind NAT so how can that server attack them? It can do no more than a 3rd party attacking random IPs.
Your browser PC is behind the same NAT - right? And there's no firewall or NAT device between your PC and whatever it is that's using the MbedTLS code - right?
I don't understand the config in this case.
Take the situation you must mentioned - I transfer photos from my phone to my PC via the home wifi. What's protecting the phone from your PC? Or what's protecting your PC from the phone since I'm betting you use a browser on both phone & PC. There's no NAT involved on your home wifi is there?
Again, same comment about having lost the battle.
Or:
- Attack some network equipment.
The MbedTLS version is not connected with that, either.
"some network equipment" being the ISP supplied router/modem that connects your network to the Internet.
Sure; NAT could be buggy, especially in no-name chinese consumer kit.
Wow, you sure have nat on the brain. I took "attack some network equipment" as total ownage of your Internet router. If I control your Internet router and can run whatever code on it I feel like, what could I do?
If you're having trouble answering that take a look at https://m.xkcd.com/341/ which is probably based on https://pete.ex-parrot.com/upside-down-ternet.html
- Spoof the server.
The MbedTLS version is not connected with that, either.
I'd like to see your definition of "connected to." If the MbedTLS software doesn't connect to a server then why do you need TLS?
It is true that a lot of applications can be done with a fixed key and just using AES for session crypto. But TLS is a standard way to do this stuff nowadays. People feel happy :) The fact that 99.99999% of data in IOT applications is of no value whatsoever is not relevant.
You kept repeating the MbedTLS version is not connected to that; it seems like the MbedTLS version isn't connecting to anything, so why run the MbedTLS software?
A case can be legitimately made that an IOT client (behind NAT) should use TLS to access the server. This authenticates the server (the certificates can have a 100 year life, so you don't get the whole installed base exploding years after the last admin has left the company) and sets up encryption for the data.
A lot of people have done this by not using TLS and just encrypting the data using a shared key. That isn't much different from TLS with certs which are never updated, but that is just another discussion leading to shared keys requiring a similar level of long-term admin to certificates.
- Use the spoofed server to attack clients that connect to it.
The MbedTLS version is not connected with that, either.
So I still don't see where tightening MbedTLS security helps.
If nothing else, it helps sales. Tell me what product you sell -- I'll make sure that I never buy it.
Rather more constructively, can you suggest how to do OTA on a typical IOT box, in a way which runs no risk of blowing up my company? :)
I thought me avoiding insecure products was very constructive :)
My box does have means of uploading new firmware but obviously it is not possible to just do it remotely.
I have a ROKU box that manages to update itself without any interaction on my part, so clearly it _is_ possible. Maybe it's not possible for what you're selling, but that's why I would like to know what it is you're selling so I can avoid it.
What happens if/when ROKU publish a firmware update which bricks everything they have ever sold?
Obviously they do testing. They probably also do what phone mfgs do: deploy updates slowly, starting with poor countries ;)
Yes one needs a means of updating IOT boxes remotely. My box can do that but the RTOS task to do it is not enabled by default. But compared to your ROKU streaming device, mine can be used in lots of varying applications (I won't go into detail, especially as you have said you will not buy it ;)) so an update could trash one customer's application, and he won't be happy especially since with most of this stuff there is simply no way to track down problems (stuff simply stops working).
This (managing updates and patches and certificates etc) is actually a huge problem in IT, with some of the biggest IT disasters having been caused by certificate expiry. So an IOT box which, via being a *client*, needs no updates, potentially for decades, is hugely beneficial.
The thing I don't know the answer to is how would you design e.g. a heating controller which is remotely accessible. This has been done for decades (I used to do one in the 1980s which was accessed over a phone line modem, so the security was a) knowing the phone # and b) knowing the password) but how do people do it nowadays if the controller is a client, so there is no way to connect *to it* freely. I suspect it is either a server on an open port (with all the vulnerability issues) or the thing which the user's app connects to is not the IOT box but a copy of its config residing on the public server, which the IOT box retrieves periodically, say every 15 mins.
Another way would be to implement something like port knocking on it.
The wider issue is that this stuff is now so complex that only people who have spent years working with MbedTLS know how to do it, and know how to incorporate the MbedTLS updates.
So hire a contractor that knows how to do it. It can't be all that hard to find somebody competent.
It *is* very hard to get someone who can dive into a box which took man-years to develop.
Peter