[HN Gopher] Editorial Response to BBC Click Article on IoT Devic...
___________________________________________________________________
Editorial Response to BBC Click Article on IoT Device Security
Author : thirstybear
Score : 11 points
Date : 2021-08-10 18:47 UTC (4 hours ago)
(HTM) web link (mender.io)
(TXT) w3m dump (mender.io)
| LeifCarrotson wrote:
| > _Selling EV charging products based on Raspberry Pi, which is a
| prototyping board, is unwise._
|
| What's the difference between a prototyping board and a product
| built using the lessons learned while integrating the prototyping
| board? The compute module is intended for use as an embedded
| board that simplifies development by mass producing the more
| difficult, expensive parts of embedded computers and letting the
| end user install it in a product. It's intended for exactly this
| sort of use case.
|
| > _When both device manufacturers were contacted by the white hat
| penetration testers who conducted the penetration testing, the
| response was typically reactive seeing the device makers put in
| place a new server, app updates and firmware updates to the
| chargers. This is symptomatic of the general lack of strategic
| security thinking that goes into the manufacture of many embedded
| devices today. For example, one of the chargers had a Raspberry
| Compute Module 3 (CM 3) which lacked the necessary security
| features for such a use case._
|
| They updated with patches for the vulnerabilities. What more do
| you want?
|
| It's not like there are two kinds of computers, on one side
| insecure prototyping computers like Raspberry Pis that can be
| made to do unintended things, and on the other side secure IoT EV
| charger computers that only do what they are intended to do.
| There are only EV chargers that are controlled by general-purpose
| computers.
| trangus_1985 wrote:
| If you want a material example, the raspberry pi's SOC is
| designed to be mounted in read only mode with industrial on-
| board flash. It is meant to be used with the broadcom toolkit
| that includes multiple boot partitions for safe and validated
| updates.
|
| In addition, (afaik) that SDK includes a hardened and stripped
| down linux kernel with watchdog, chain of trust and binary
| signature verification - a far cry from the raspberry pi's
| kinda "open like whatever" standard desktop and server grade
| distro.
|
| A material consequence of this is that raspberry pis (pre 4, at
| least) that lose power during a SD write have had a common
| tendency to leave the flash in a really bad state, rendering
| the device unusable until a reflash happens.
|
| The compute model suffers from all of this. I use the compute
| modules for lighting and other fun such activities, at art and
| music festivals. I have gotten used to carrying spare SD cards
| (for non compute) and a laptop with flash snapshots (for CMs).
| More than once, a breaker has blown and the compute module
| wouldn't come up after due to a trashed filesystem.
|
| I will admit, the CMs are wayyy more robust than the normal
| ones, due to whatever emmc they're using. I could probably
| mount the flash as RO also but that tends to cause "weird
| things" to happen. If I have to flash a CM once in a weekend,
| that's a small price to play
|
| > What's the difference between a prototyping board and a
| product built using the lessons learned while integrating the
| prototyping board?
|
| The difference is that the lessons learned likely won't cover
| the large amount of pitfalls you'd encounter in the field, but
| those pitfalls still exist.
|
| TLDR: Raspberry pi doesn't include a hardened sdk and distro
| intended for robust, embedded applications.
| hughrr wrote:
| The issue is likely the general purpose potentially network
| attached computer should not be trusted for the safety critical
| portion of the system such as power control and monitoring.
| That should be a fully isolated computer with a light weight
| communications protocol with the host over SPI/I2C etc. The
| isolated processor can run an RTOS with some deadline
| guarantees as well then. If the host is compromised, the
| physical hardware cannot be controlled past trivial (audited)
| requests issued to the isolated processor.
|
| Also on top of that, not joking but the Pi hardware, even the
| compute model, is not very good quality compared to typical
| industrial computers assigned to or designed for these tasks.
|
| The only reason people do this with the pi is to trade safety
| for cost savings which is a stupid idea when you're playing
| with hundreds of amps.
| barbegal wrote:
| 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 wrote:
| 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?)
___________________________________________________________________
(page generated 2021-08-10 23:02 UTC)