Live data from Hacker News

Learn how to design and defend an embedded Linux device

embeddedbits.org

31–36 of 36 posts

Re: Learn how to design and defend an embedded Linux device

#31
post #11
post #5

Earlier quoted context omitted.

I had a similar reaction to this. I don't see what the use is in ensuring the hardware is running software from "trustworthy" persons, especially when the device's owner is not usually considered to be part of that group. This feels like something we aught to question, why is it acceptable that even after buying some electronic device there's a part of it that the owner isn't allowed to touch? Embedded devices are ju…

I agree with you for devices where the user should be considered 'trusted' - I like to tinker too. But I think there are use-cases where this is legitimate, for example, ticket readers mounted on public transport where anyone could tamper with them out-of-hours, or a utility meter installed in my house where I might want to change the way it records consumption to get out of paying. Likewise, a payment terminal takin…

>ticket readers mounted on public transport where anyone could tamper with them out-of-hours

The owner of the ticket reader is the public transport authority.

>a utility meter installed in my house where I might want to change the way it records consumption to get out of paying

The owner of the utility meter is typically the company providing the utility.

In both of these cases, I would expect the owner of the device to have full control over it and not, say, only the manufacturer. If my city's government installs ticket readers in every subway station and is then perpetually beholden to a single private company to upgrade/maintain/improve them, that feels like a problem.

Note that this doesn't have to mean that someone with temporary access to the device should have full control over it! There's still a place for secure boot-style systems; it's all about who controls the keys.

>a payment terminal taking card payments in a restaurant - as a diner I'd quite like some assurance that someone couldn't tamper with it to record card details for example

This one is maybe a bit more concerning since it's a card issued by a separate authority, you don't have the ability to confirm transaction amounts on a device you trust, etc... but sure, in this case, I'd be fine with the hardware vendor or payment processor controlling the hardware.

(Though long-term I think this is a bit silly in the first place considering approximately everyone is walking around with computers in their pockets that would be perfectly capable of letting you confirm transaction amounts on a display you trust. Card payments currently are effectively handing someone your account details and saying "pretty please only take as much as you say you will.")

Re: Learn how to design and defend an embedded Linux device

#32
post #11

Earlier quoted context omitted.

I agree with you for devices where the user should be considered 'trusted' - I like to tinker too. But I think there are use-cases where this is legitimate, for example, ticket readers mounted on public transport where anyone could tamper with them out-of-hours, or a utility meter installed in my house where I might want to change the way it records consumption to get out of paying. Likewise, a payment terminal takin…

>ticket readers mounted on public transport where anyone could tamper with them out-of-hours The owner of the ticket reader is the public transport authority. >a utility meter installed in my house where I might want to change the way it records consumption to get out of paying The owner of the utility meter is typically the company providing the utility. In both of these cases, I would expect the owner of the device…

> Though long-term I think this is a bit silly in the first place considering approximately everyone is walking around with computers in their pockets that would be perfectly capable of letting you confirm transaction amounts on a display you trust.

This is how China's new-generation payment systems work.

Re: Learn how to design and defend an embedded Linux device

#33
post #6

This article is not about security. It's about device lock in, so the user will need to jailbreak the device to have control. IMHO, tiviozation of devices should be banned by law. Currently, GPL3 forbids it only, so, please, use GPL3 for your new open source project.

Frankly, I think open source needs to embrace the idea of 'no commercial use' as a viable license choice.

I'm not keen on the idea of a million/billion/billion+ dollar company taking code I've written for my own enjoyment and using it to disproportionately enrich the company's shareholders or abuse its customers by denying them control over their devices.

Code that can be used in closed devices shouldn't be available for the manufacturers of closed devices to use.

Re: Learn how to design and defend an embedded Linux device

#34
post #27
post #23

Earlier quoted context omitted.

>That integrity might be checked It might also be broken and they don't care for you and you're screwed. Also, as was shown many a time, the manufacturer will prevent you from doing whatever you please with your own hardware, if you chose to do so. In that case, their integrity is broken by design.

That's all true, but the context here is things like payment terminals, ticket machines and energy charging meters, and whether it makes sense for third parties to easily modify the software running on them. That hardware is not "your own". It is deployed to facilitate and protect a transaction between you and someone else. The certainly exists a possibility that the manufacturer of those devices doesn't care about p…

I see there was a misunderstanding. The owner of the payment terminal has to be the trusted root, not the manufacturer.

Re: Learn how to design and defend an embedded Linux device

#35
post #29
post #5

Earlier quoted context omitted.

I had a similar reaction to this. I don't see what the use is in ensuring the hardware is running software from "trustworthy" persons, especially when the device's owner is not usually considered to be part of that group. This feels like something we aught to question, why is it acceptable that even after buying some electronic device there's a part of it that the owner isn't allowed to touch? Embedded devices are ju…

There is a parallel in non-electronic hardware. Certain safes irreparably break after several attempts to incorrectly or violently unlock them. Nobody — neither a thief, nor a legitimate owner, nor the manufacturer can open them. The only option to reclaim the contents is to very slowly and with a great effort to cut them using serious industrial machines. This is a feature that customers ask for. They want to be sur…

> Nobody — neither a thief, nor a legitimate owner, nor the manufacturer can open them. The only option to reclaim the contents is to very slowly and with a great effort to cut them using serious industrial machines.

The analogy fails if there's no way of "cutting open" a gadget/cellphone/PC to regain control of it. The bank is perfectly capable of recovering the contents of the safe, even after a destructive failsafe, they just pay someone and wait a day.

Re: Learn how to design and defend an embedded Linux device

#36
post #6

This article is not about security. It's about device lock in, so the user will need to jailbreak the device to have control. IMHO, tiviozation of devices should be banned by law. Currently, GPL3 forbids it only, so, please, use GPL3 for your new open source project.

Frankly, I think open source needs to embrace the idea of 'no commercial use' as a viable license choice. I'm not keen on the idea of a million/billion/billion+ dollar company taking code I've written for my own enjoyment and using it to disproportionately enrich the company's shareholders or abuse its customers by denying them control over their devices. Code that can be used in closed devices shouldn't be available…

> abuse its customers by denying them control over their devices

That's exactly what tivoization is, so the GPLv3 already prevents that.

Post reply on HN