14 ms·

I work in the embedded field and this drives me nuts. I personally feel that companies should be required to go one step further and be compelled to release th

I work in the embedded field and this drives me nuts. I personally feel that companies should be required to go one step further and be compelled to release their embedded keys and source code for any product that they no longer provide complete support for. The embedded field is strange because the lock-in is generally on the side of the hardware design and tooling. Nobody is going to try to clone a tractor because they have the source code for it. They also need the CAD drawings, machine paths, tooling, supply chain, etc... Yet just about every company in the space feels that their code is absolutely sacred above all else. Just about everything you own running embedded software that has some update functionality has a bootloader containing cryptographic keys such that the firmware patches/images cannot even be disassembled. For a few devices like routers, some toys, a couple handheld radios and the like, people have been able to modify them through exploits that cause firmware dumps from the uC's memory but otherwise it's typically prohibitively time intensive to rewrite new firmware from scratch without having access to the device schematics (and even then). Worse, just about all these devices have some access to JTAG ports such that you could easily program them yourself if you wanted to and had something useful to flash them with. I've run into so many products I use on a regular basis with bugs or simple but badly needed features that I could have easily fixed/hacked in with access to the source code but alas, I cannot.

deepsun 9y ago
I believe the change should start from consumers, especially big institutions. For example, a big municipality or government agency may impose limits on buying new software/hardware that isn't open to refactor/repair by their competitors, to avoid lock-in to a single supplier, operate on more open market, and consequently drive the costs down.
- pdelbarba 9y ago
  I like the idea. I'm worried that this ship has sailed though as it's becoming harder to even get phones without cryptographically verified bootloaders, and god forbid you want to mess with the baseband/modem source. This is only going to get worse too, as software becomes the part that's actually valuable. AI will mean that everything on the processor will be a trade secret x1000 and everything that can possibly be kept from the local processor will be hidden away in the cloud, forever dependent on continued server access.
rhizome 9y ago
I personally feel that companies should be required to go one step further and be compelled to release their embedded keys and source code for any product that they no longer provide complete support for. Sounds great, but it's something the abandonware[1] scene has been fighting for over the past 20 years, to no avail. 1. https://en.wikipedia.org/wiki/Abandonware https://en.wikipedia.org/wiki/Abandonware
- Slansitartop 9y ago
  It's a good idea, so people should keep fighting for it, even if it takes more than 20 years.
- pdelbarba 9y ago
  I think the difference here is that when it comes to embedded software, very expensive capital can be tied up, as is the case in the above video. Not many commercially available software packages cost >$10k and very few people are exposed to that risk. Meanwhile, there are hundreds of millions of cars in the US.
- archgoon 9y ago
  It'll probably take one generation to raise the issue (and find an example for enough people to care), another to debate, and finally a third to agree about the common sense solution. So give it another 40 years.
aplorbust 9y ago
"Just about everything you own running embedded software that has some update functionality..." "Worse, just about all these devices have some access to JTAG ports such that you could easily program them yourself if you wanted to and had something useful to flash them with. I've run into so many products I use on a regular basis with bugs or simple but badly needed features that I could have easily fixed/hacked in with access to the source code but alas, I cannot." IMO, it is a massive waste. Short-sighted, short-term thinking. There are people who for whatever reason do not want you to have access to the software ("firmware") and to read/fix/improve upon it. Some of these people comment on HN. They become active during debates over whether users would derive any benefit from being able to read and edit source code.
- dpwm 9y ago
  The problem seems to be that software is viewed as a trade secret. Big old companies have CEOs and boards that see embedded software in the same way many legislators and judges see it. Firstly they don't really understand it. But in any case it's part of the product and people have no reason to tinker with it. Now software is being used to enforce what manufacturers could previously have only dreamed of: monopolizing repairs. With hindsight it seems obvious that things converged onto the embedded computers of consumer products: think microwaves and TVs rather than general purpose computers. The problem with tractors is that all the farmers I know have a much better idea of how a tractor works and how to fix it than the average motorist does about their vehicle. I am reminded of the era when windscreen-mounted GPS navigation systems started becoming mainstream. Most of the models had very similar hardware but the software was all that differed. I never looked into it but I suspect almost zero had source code published. To the more typical consumer, the unit is as a whole and the software comes with it. If it routinely takes you the wrong way down a one way street or tries to take you down a set of steps, it's defective and needs to be replaced. To the more technical consumer it's clear that either the software or the data is at fault and either could be fixed with the right resources. I still feel a sadness at this, yet this waste is insignificant compared to a tractor or any other vehicle.
  - carlmr 9y ago
grkvlt 9y ago
> embedded field [...] companies should be [...] compelled to release their embedded keys and source code awesome! my botnet malware that exploits and roots your smart meter or set top box can now install new firmware with a permanent backdoor and nothing will complain because all the malware binaries are signed - by the manufacturer's key, no less - so they must be secure, right?
- M_Bakhtiari 9y ago
  It would be beyond retarded to use the exact same key for every unit. That's not what people are asking for. People are asking for keys to their exact units so they and only they can sign software for them.
  - evancox100 9y ago
    While GP's snark is uncalled for, he is correct as that's exactly how this works. What you're asking for is like saying that a web server would provide a unique HTTPS cert to every distinct visitor.
    - M_Bakhtiari 9y ago
      >What you're asking for is like saying that a web server would provide a unique HTTPS cert to every distinct visitor. It's not similar at all. The equivalent would not be the certificate but the session key, and you do get your own session key in order to prevent what the person above is describing. My HN session key is useless for decrypting your HN password even if I could intercept the traffic. There is no technical reason why the devices can't ship with not only the manufacturer's public key, but also a key pair generated for each unit that comes off the assembly line for the customers to use to sign their own firmware images (and if they wish, delete the manufacturer's public key). But they will never be able to sign images for any device but their own because they simply don't have any signing keys that can produce a signature that will be accepted by any device but their own.
jabl 9y ago
Not to defend Deere et al., but one argument I've seen bandied about is that the manufacturers consider their software to be their "secret sauce" value add. If machined steel were all there is, there's nothing preventing the Chinese (or whoever happens to be the current outsourcing bogeyman) from producing perfectly good equipment at a fraction of the price. Personally I'm not convinced this is a really sustainable "moat"; surely the Chinese (boo!) can do embedded programming as well.
- squarefoot 9y ago
  That's why a lot of people are advocating for a fair law that forces companies to release sources after a reasonable amount of time or when they cease to support the product, so that they can profit for some years from their IP but users aren't screwed when the product becomes obsolete. And of course being repairable and/or upgradeable means that a piece of technology won't be thrown away.
M_Bakhtiari 9y ago
>I personally feel that companies should be required to go one step further and be compelled to release their embedded keys and source code for any product that they no longer provide complete support for. The embedded team where I work struggles with the same thing. Frankly this should be included with the first delivery of any industrial system. Under NDA if they absolutely must, though I don't like it. I also don't like consumer systems being locked up, but at least it's somewhat defensible. But treating farmers as dumb, inbred "hold my beer and watch this firmware hack" hillbillies and not the educated industry professionals that they are is beyond condescending, disrespectful and is completely indefensible. Exactly who is deemed qualified to hack farm equipment firmware is something for the farming trade associations and their insurance companies to work out, but as far as John Deere and the regulators are concerned, we're talking about professional embedded developers writing code to run on their equipment to support an industrial process, something that is completely uncontroversial in many other fields. That you're not supposed to intentionally or inadvertently convert your combine into a man-eating killbot is surely already covered by insurance policy clauses, labour laws and public safety laws.
- mikepurvis 9y ago
  I completely agree with you, but I am a little sympathetic to the "bad PR" angle. It's really, really not that hard to imagine a scenario where a well-meaning farmer (or their contractor) loads something onto the embedded processor that does cause a malfunction, and before you know it there's a splashy news story featuring pictures of a big green tractor not living up to its brand. I work for a robotics company making indoor self-driving vehicles, and we worry about exactly this issue— from an ROI perspective, our product is a slam dunk, so it's safety and reliability are the first and second most significant questions which have to be answered during the sales process. When we invest substantially in associating our brand with those values, we really can't afford the possibility that an unauthorized user modification compromises them in a way that's outside of our control. Hence closed source, FDE, and all the rest of it.
  - squarefoot 9y ago
    That is a very specific scenario, but agreements can be made to release software in exchange of loss of warranty and liability protection: I give you the code and from that moment (either if you use/modify it or not) you lose all warranties and can't sue me even if the product burns your house and kills all your kittens.
gjvc 9y ago
"Nobody is going to try to clone a tractor because they have the source code for it." Thus is the funniest thing I've read in ages. It's also 100% correct and this whole situation shows perhaps clearer than many, how Stallman's warnings were accurate.
- guardian5x 9y ago
  While that is true, i think the manufacturers are more afraid of competitors, which could in some way "clone" at least the software.
  - mrguyorama 9y ago
    I'm doubtful that DRM in any space has ever been about competitors.
_pmf_ 9y ago
> Nobody is going to try to clone a tractor because they have the source code for it. In the automotive industry, people and companies will do this (at the component level). Enabling features via that the OEM has disabled due to its marked segmentation strategy via aftermarket components is done (and would be done to a greater extend if OEMs did not protect the part of their diagnostic stack that handles feature activation). For example, XCP or UDS security access modules are sometimes distributed by the Tier 1 as a DLL so that even the OEM has no source code for the concrete authentication mechanism that is used.

deepsun 9y ago

I believe the change should start from consumers, especially big institutions. For example, a big municipality or government agency may impose limits on buying new software/hardware that isn't open to refactor/repair by their competitors, to avoid lock-in to a single supplier, operate on more open market, and consequently drive the costs down.

pdelbarba 9y ago
I like the idea. I'm worried that this ship has sailed though as it's becoming harder to even get phones without cryptographically verified bootloaders, and god forbid you want to mess with the baseband/modem source. This is only going to get worse too, as software becomes the part that's actually valuable. AI will mean that everything on the processor will be a trade secret x1000 and everything that can possibly be kept from the local processor will be hidden away in the cloud, forever dependent on continued server access.

rhizome 9y ago

I personally feel that companies should be required to go one step further and be compelled to release their embedded keys and source code for any product that they no longer provide complete support for. Sounds great, but it's something the abandonware[1] scene has been fighting for over the past 20 years, to no avail. 1. https://en.wikipedia.org/wiki/Abandonware https://en.wikipedia.org/wiki/Abandonware

Slansitartop 9y ago
It's a good idea, so people should keep fighting for it, even if it takes more than 20 years.
pdelbarba 9y ago
I think the difference here is that when it comes to embedded software, very expensive capital can be tied up, as is the case in the above video. Not many commercially available software packages cost >$10k and very few people are exposed to that risk. Meanwhile, there are hundreds of millions of cars in the US.
archgoon 9y ago
It'll probably take one generation to raise the issue (and find an example for enough people to care), another to debate, and finally a third to agree about the common sense solution. So give it another 40 years.

aplorbust 9y ago

"Just about everything you own running embedded software that has some update functionality..." "Worse, just about all these devices have some access to JTAG ports such that you could easily program them yourself if you wanted to and had something useful to flash them with. I've run into so many products I use on a regular basis with bugs or simple but badly needed features that I could have easily fixed/hacked in with access to the source code but alas, I cannot." IMO, it is a massive waste. Short-sighted, short-term thinking. There are people who for whatever reason do not want you to have access to the software ("firmware") and to read/fix/improve upon it. Some of these people comment on HN. They become active during debates over whether users would derive any benefit from being able to read and edit source code.

dpwm 9y ago
The problem seems to be that software is viewed as a trade secret. Big old companies have CEOs and boards that see embedded software in the same way many legislators and judges see it. Firstly they don't really understand it. But in any case it's part of the product and people have no reason to tinker with it. Now software is being used to enforce what manufacturers could previously have only dreamed of: monopolizing repairs. With hindsight it seems obvious that things converged onto the embedded computers of consumer products: think microwaves and TVs rather than general purpose computers. The problem with tractors is that all the farmers I know have a much better idea of how a tractor works and how to fix it than the average motorist does about their vehicle. I am reminded of the era when windscreen-mounted GPS navigation systems started becoming mainstream. Most of the models had very similar hardware but the software was all that differed. I never looked into it but I suspect almost zero had source code published. To the more typical consumer, the unit is as a whole and the software comes with it. If it routinely takes you the wrong way down a one way street or tries to take you down a set of steps, it's defective and needs to be replaced. To the more technical consumer it's clear that either the software or the data is at fault and either could be fixed with the right resources. I still feel a sadness at this, yet this waste is insignificant compared to a tractor or any other vehicle.
- carlmr 9y ago

grkvlt 9y ago

> embedded field [...] companies should be [...] compelled to release their embedded keys and source code awesome! my botnet malware that exploits and roots your smart meter or set top box can now install new firmware with a permanent backdoor and nothing will complain because all the malware binaries are signed - by the manufacturer's key, no less - so they must be secure, right?

M_Bakhtiari 9y ago
It would be beyond retarded to use the exact same key for every unit. That's not what people are asking for. People are asking for keys to their exact units so they and only they can sign software for them.
- evancox100 9y ago
  While GP's snark is uncalled for, he is correct as that's exactly how this works. What you're asking for is like saying that a web server would provide a unique HTTPS cert to every distinct visitor.
  - M_Bakhtiari 9y ago
    >What you're asking for is like saying that a web server would provide a unique HTTPS cert to every distinct visitor. It's not similar at all. The equivalent would not be the certificate but the session key, and you do get your own session key in order to prevent what the person above is describing. My HN session key is useless for decrypting your HN password even if I could intercept the traffic. There is no technical reason why the devices can't ship with not only the manufacturer's public key, but also a key pair generated for each unit that comes off the assembly line for the customers to use to sign their own firmware images (and if they wish, delete the manufacturer's public key). But they will never be able to sign images for any device but their own because they simply don't have any signing keys that can produce a signature that will be accepted by any device but their own.

jabl 9y ago

Not to defend Deere et al., but one argument I've seen bandied about is that the manufacturers consider their software to be their "secret sauce" value add. If machined steel were all there is, there's nothing preventing the Chinese (or whoever happens to be the current outsourcing bogeyman) from producing perfectly good equipment at a fraction of the price. Personally I'm not convinced this is a really sustainable "moat"; surely the Chinese (boo!) can do embedded programming as well.

squarefoot 9y ago
That's why a lot of people are advocating for a fair law that forces companies to release sources after a reasonable amount of time or when they cease to support the product, so that they can profit for some years from their IP but users aren't screwed when the product becomes obsolete. And of course being repairable and/or upgradeable means that a piece of technology won't be thrown away.

M_Bakhtiari 9y ago

>I personally feel that companies should be required to go one step further and be compelled to release their embedded keys and source code for any product that they no longer provide complete support for. The embedded team where I work struggles with the same thing. Frankly this should be included with the first delivery of any industrial system. Under NDA if they absolutely must, though I don't like it. I also don't like consumer systems being locked up, but at least it's somewhat defensible. But treating farmers as dumb, inbred "hold my beer and watch this firmware hack" hillbillies and not the educated industry professionals that they are is beyond condescending, disrespectful and is completely indefensible. Exactly who is deemed qualified to hack farm equipment firmware is something for the farming trade associations and their insurance companies to work out, but as far as John Deere and the regulators are concerned, we're talking about professional embedded developers writing code to run on their equipment to support an industrial process, something that is completely uncontroversial in many other fields. That you're not supposed to intentionally or inadvertently convert your combine into a man-eating killbot is surely already covered by insurance policy clauses, labour laws and public safety laws.

mikepurvis 9y ago
I completely agree with you, but I am a little sympathetic to the "bad PR" angle. It's really, really not that hard to imagine a scenario where a well-meaning farmer (or their contractor) loads something onto the embedded processor that does cause a malfunction, and before you know it there's a splashy news story featuring pictures of a big green tractor not living up to its brand. I work for a robotics company making indoor self-driving vehicles, and we worry about exactly this issue— from an ROI perspective, our product is a slam dunk, so it's safety and reliability are the first and second most significant questions which have to be answered during the sales process. When we invest substantially in associating our brand with those values, we really can't afford the possibility that an unauthorized user modification compromises them in a way that's outside of our control. Hence closed source, FDE, and all the rest of it.
- squarefoot 9y ago
  That is a very specific scenario, but agreements can be made to release software in exchange of loss of warranty and liability protection: I give you the code and from that moment (either if you use/modify it or not) you lose all warranties and can't sue me even if the product burns your house and kills all your kittens.

gjvc 9y ago

"Nobody is going to try to clone a tractor because they have the source code for it." Thus is the funniest thing I've read in ages. It's also 100% correct and this whole situation shows perhaps clearer than many, how Stallman's warnings were accurate.

guardian5x 9y ago
While that is true, i think the manufacturers are more afraid of competitors, which could in some way "clone" at least the software.
- mrguyorama 9y ago
  I'm doubtful that DRM in any space has ever been about competitors.

_pmf_ 9y ago

> Nobody is going to try to clone a tractor because they have the source code for it. In the automotive industry, people and companies will do this (at the component level). Enabling features via that the OEM has disabled due to its marked segmentation strategy via aftermarket components is done (and would be done to a greater extend if OEMs did not protect the part of their diagnostic stack that handles feature activation). For example, XCP or UDS security access modules are sometimes distributed by the Tier 1 as a DLL so that even the OEM has no source code for the concrete authentication mechanism that is used.