3 ms·

I don't understand all the worry about being able to modify the firmware of a computing device if one has physical access to it. If you have physical access the

I don't understand all the worry about being able to modify the firmware of a computing device if one has physical access to it. If you have physical access then you can completely replace the computing device with one under the attacker's control. Raspberry pi's might not look professional but they are easy to procure and develop with whilst only adding a small amount to a BOM. Even when using a different SoC very few will be setup to use a fully secure boot process. The original vulnerabilities found were mostly in the web apis of the servers that these chargers connect to which makes vulnerabilities in the hardware irrelevant.

zibzab 5y ago
Actually that is not 100% correct. We now have things like platform attestation that - unless your adversary is a state actor - stops some physical attacks. (Not available rpi right now, but maybe in 4-6 years?)
Sprite_tm 5y ago
I agree that the 'o noez, raspberry pi!' is high here, but one of the things you can do on other devices is something like secure boot, where the OS image on disk is signed and the device will boot to a 'rescue' firmware if it is compromised. Aside from physical access deterioration it also has the effect that an attack over the Internet generally cannot get permanence, that is, you can get rid of it by rebooting the device.
xyzzy21 5y ago
In theory, sure. But most "real world IoT" devices are appliance-like and seldom designed for the real world nor for non-technical owners. I'd estimate the number of IoT devices with "good and wise security in the design" at being far smaller than 0.1%. Most people designing IoT are NOT CompSci people who remember Therac-200 in class. Most are EEs who often have never had more than one or two programming classes and often often have had no formal training at all. Never mind "security theory" courses. Never mind case studies around that. It's like expecting the average man on the street to be able to perform brain surgery. Worse: no employer is willing to pay for the talent to do the job right. They want it to "work well enough" and "on the cheap" at the same time. Once it's sold, any security issue is someone else's problem (even if it's someone in the same company). And I'm saying this as a degreed EE (I just happened to get into software long before I went to engineering school so I know what I don't know).

zibzab 5y ago

Actually that is not 100% correct. We now have things like platform attestation that - unless your adversary is a state actor - stops some physical attacks. (Not available rpi right now, but maybe in 4-6 years?)

Sprite_tm 5y ago

I agree that the 'o noez, raspberry pi!' is high here, but one of the things you can do on other devices is something like secure boot, where the OS image on disk is signed and the device will boot to a 'rescue' firmware if it is compromised. Aside from physical access deterioration it also has the effect that an attack over the Internet generally cannot get permanence, that is, you can get rid of it by rebooting the device.

xyzzy21 5y ago

In theory, sure. But most "real world IoT" devices are appliance-like and seldom designed for the real world nor for non-technical owners. I'd estimate the number of IoT devices with "good and wise security in the design" at being far smaller than 0.1%. Most people designing IoT are NOT CompSci people who remember Therac-200 in class. Most are EEs who often have never had more than one or two programming classes and often often have had no formal training at all. Never mind "security theory" courses. Never mind case studies around that. It's like expecting the average man on the street to be able to perform brain surgery. Worse: no employer is willing to pay for the talent to do the job right. They want it to "work well enough" and "on the cheap" at the same time. Once it's sold, any security issue is someone else's problem (even if it's someone in the same company). And I'm saying this as a degreed EE (I just happened to get into software long before I went to engineering school so I know what I don't know).