4 ms·

> Guy Fedorkow is a Connection Science Fellow at MIT, a Distinguished Engineer at Juniper Networks, and a contributor to the Trusted Computing Group. Talk abou

> Guy Fedorkow is a Connection Science Fellow at MIT, a Distinguished Engineer at Juniper Networks, and a contributor to the Trusted Computing Group. Talk about the worst corporate doublespeak - 'trusted computing'. It also goes by DRM, or rental hardware, or you never actually own it cause someone else retains permanent digital control. There is NO trust here, only control and power in never actually selling anything. And since we're talking of IoT, this goes hand in hand with proprietary corporate clouds, anti-FLOSS like Home Assistant, rental in the form of sales, forced firmware upgrades that remove previous features to gatekeep and resell what you promised. I don't even need to read further. Anybody, and I do mean anybody, who uses the moniker 'Trusted Computing', should be ignored, blackballed, and relegated to the bin of computing.

kwk1 1y ago
> anti-FLOSS like Home Assistant Could you expand on this?
- mystraline 1y ago
  Not hard to. Go look at the wide variety of hardware that does NOT work with Home Assistant, or works tenuously through some heavily rate limited public web api. There is a reason why for my IoT setup so far, its been primarily OpenGarage, IKEA IoT (ZigBee), and existing compute services I locally host. Remote servers come and go. Companies come and go. If I am at the forced behest of some company to 'bless' my hardware, its not mine. And I think its fraud to even claim it a sale. Its a 'rental as long as the company wishes'.
  - kwk1 1y ago
    Ah ok, what I thought you meant was pretty much the opposite of that, e.g. that they were doing some kind of "openwashing" I hadn't heard of yet. Thanks for clearing that up
Stefan-H 1y ago
Are you familiar with the academic field of security and the notion of trust in trusted computing? The IoT devices that is being discussed in the article are for industrial control systems, not necessarily your home lightbulb. The threat model is different. Do you want every municipal power company to be trusted to properly vet the code they are putting on these devices, or do you want to trust the device manufacturer to be the one who can put code on the devices?
- mystraline 1y ago
  Owner is still owner, be it someone who lives in a single family residence, or that of a municipality. In my area, tornado sirens are unencrypted aand a simple recordable and replayable frequency. The cost to add an encrypted radio connection is $100k for the base station, and $25k per siren. There are 80+ sirens. If this were open source, then a simple computer could he retrofitted to do this. But because they are highly proprietary, the county would be on the hook for $2.1M just to defend against an asshole with a HackRF. FLOSS and open principles should matter to governments as well as individuals. Trading temporary easiness for no long term usability is utterly ridiculous. And you end up with a doorstop in the end either way.
- 0x000xca0xfe 1y ago
  And who can push new code after the manufacturer's bankruptcy? I've worked in IoT and I'd say the biggest security problems are in this order: - Devices requiring Internet access for functionality that could have been done locally - Hardware SDKs which are basically abandoned forks by manufacturers so IoT companies ship stone-age kernels and device drivers - The usual stuff: too much complexity, lack of tests, bad documentation, meaning old parts of the software get forgotten (but remain exploitable) Theoretical waxing about trusted computing and remote attestation does seem disingenuous when problems with non-certified firmware is probably not even in the top 10 in the real world. Notice how the article author mentions some scary attacks but conveniently omits how the attackers actually gained access?
deleted 1y ago
[deleted]

kwk1 1y ago

> anti-FLOSS like Home Assistant Could you expand on this?

mystraline 1y ago
Not hard to. Go look at the wide variety of hardware that does NOT work with Home Assistant, or works tenuously through some heavily rate limited public web api. There is a reason why for my IoT setup so far, its been primarily OpenGarage, IKEA IoT (ZigBee), and existing compute services I locally host. Remote servers come and go. Companies come and go. If I am at the forced behest of some company to 'bless' my hardware, its not mine. And I think its fraud to even claim it a sale. Its a 'rental as long as the company wishes'.
- kwk1 1y ago
  Ah ok, what I thought you meant was pretty much the opposite of that, e.g. that they were doing some kind of "openwashing" I hadn't heard of yet. Thanks for clearing that up

Stefan-H 1y ago

Are you familiar with the academic field of security and the notion of trust in trusted computing? The IoT devices that is being discussed in the article are for industrial control systems, not necessarily your home lightbulb. The threat model is different. Do you want every municipal power company to be trusted to properly vet the code they are putting on these devices, or do you want to trust the device manufacturer to be the one who can put code on the devices?

mystraline 1y ago
Owner is still owner, be it someone who lives in a single family residence, or that of a municipality. In my area, tornado sirens are unencrypted aand a simple recordable and replayable frequency. The cost to add an encrypted radio connection is $100k for the base station, and $25k per siren. There are 80+ sirens. If this were open source, then a simple computer could he retrofitted to do this. But because they are highly proprietary, the county would be on the hook for $2.1M just to defend against an asshole with a HackRF. FLOSS and open principles should matter to governments as well as individuals. Trading temporary easiness for no long term usability is utterly ridiculous. And you end up with a doorstop in the end either way.
0x000xca0xfe 1y ago
And who can push new code after the manufacturer's bankruptcy? I've worked in IoT and I'd say the biggest security problems are in this order: - Devices requiring Internet access for functionality that could have been done locally - Hardware SDKs which are basically abandoned forks by manufacturers so IoT companies ship stone-age kernels and device drivers - The usual stuff: too much complexity, lack of tests, bad documentation, meaning old parts of the software get forgotten (but remain exploitable) Theoretical waxing about trusted computing and remote attestation does seem disingenuous when problems with non-certified firmware is probably not even in the top 10 in the real world. Notice how the article author mentions some scary attacks but conveniently omits how the attackers actually gained access?

deleted 1y ago

[deleted]