On 3/13/2024 10:25 AM, Peter via mbed-tls wrote:
Surely IP cameras (those I have known) contain a server, which many users install on an open port. This was the principal usage model for the original AXIS cameras. You could even find them with a suitably formed google search!
If the camera was a client, uploading images or a video stream to a server (which has a properly secured user side) how could the camera be attacked? It will be behind NAT, for a start.
There is a classic saying in encryption: it is very easy for someone to design a new encryption algorithm that *they, themselves* don't see how to break.
Device security is a bit like that too. Just because you don't see how an attacker is going to break into your network does not mean nobody will. Lee and others already explained the multiple ways through which attackers could first penetrate a network, and then access devices. And attackers have absolutely done that in the past.
I very much like that the MbedTLS code is following best practice, such as zeroing fields that contained secrets before freeing them. Or the option to refer to keys by handles instead of having them stored in plain text in the applications' memory. Or chasing for side channels and closing them. That's hard, but it should be done.
Of course, most of the actual attacks on devices come down to simpler tricks, such as inserting an MITM and finding the secrets send by client to server, or phishing for credentials, or maybe finding the credentials in the user manual. Which means that we have to pay a lot of attention to configuration issues, certificate verification, key rotation, etc.
We need more attention, not less. Even if the devices are being a firewall -- and certainly if that "firewall" is the ISP-provided WiFi Router + NAT.
-- Christian Huitema