4 ms·

Possibly weird idea: federal firmware escrow. The OEM gets to put a stamp on their product after submitting firmware source/keys to the FCC. When the OEM either

by ics 3y ago

Possibly weird idea: federal firmware escrow. The OEM gets to put a stamp on their product after submitting firmware source/keys to the FCC. When the OEM either declares the product not supported or provides no updates for X length of time, the files are automatically published to a public repository. Perhaps there is an appropriate license which says essentially that it is almost public domain, with an exception (or fee?) to use it for any purpose other than supporting the lifetime of an existing product. As others have stated, free software is one way of giving the public ability to keep things up to date but that's almost like the government saying people are allowed to clean up pollution. It doesn't put any pressure on companies to behave better. Another issue is build-ability of open source code. If an OEM submits firmware source and keys to a third party, even regularly, who really knows whether it is actually functional and complete. Automated tests or sample hardware are possible ideas but have their own failure modes and could be difficult for to implement solely for this purpose. Another weird idea for the above. If one requirement was deterministic builds, then in addition to source/keys, a suitable toolchain to build could also be required such that the repository stewards would only need to run exactly what the OEM provides, and if the checksums don't match then it means they are not in compliance.

unintendedcons 3y ago
I like this idea! A code&keys escrow org, yes please
bick_nyers 3y ago
This is an amazing idea and I would only buy a product that has this stamp on them. I would put some additional triggers into the publication of source code as well, notably if the company goes out of business. I would also put some kind of timer and renewal process on it, like a company needs to recertify every 1-5 years (pros and cons to different time lengths) and that they have indeed been providing actual updates (and not just fake ones) and actual support.
- ics 3y ago
  The OEM could be allowed to choose their recertification period, perhaps with slight differences in requirements. Perhaps even different options offered by company size. For example 1-5 employee companies might get a "no recertification, provided as-is" option which releases automatically 3 years after filing. Vendors who re-certify every 6 months could get an extra mark on their stamp or whatever. There are tons of possibilities honestly, and though I've been thinking about it for a long time writing it is much easier to come up with more.
  - monch1962 3y ago
    Agree this approach seems to be worth investigating further, but as a citizen of a non-US country, I'd like to see a solution that wasn't based on a US-centric set of controls and governance bodies. These days, with nationalism and populism rampant across the world, I think we need a solution where no one country (or country's leader) can simply decide to turn off critical infrastructure for the rest of the world and/or hold the rest of the world to ransom. Then you run into questions of "do we really want (insert bad country) to be able to expose IOT source code to their evil hackers?". This is a really difficult problem to solve, but ultimately I think ownership of the "keys" to unlock escrowed code needs to reside with (winging it here...) a body such as IEEE or ISO. Or possibly something like a global council where e.g. any 5 countries out of 7 can collaborate via a sharing of keys to release source code, but no one country is able to do so.
    - ics 3y ago
      I completely agree that such a thing should not be US-only. There would need to be a clear distinction between one-gov't backdoor and voluntary regulatory certification, because ultimately the goal would be for other countries to follow suit and provide similar/identical certifications. You could look to standards bodies to provide standard implementation details on what "firmware escrow" is, what exact formats and files must be included, etc. IEEE, ISO, JIS, DIN, and all of them could write or adopt the document. But actually running the service and providing the certification is a little closer to a patent office than organizing standards which is why I propose doing it federally. Think Energy Star (which is a US gov't program based on EPA standards) which has been implemented successfully outside of the US.
- punnerud 3y ago
  Classic tech to think of technical solutions to a regulatory problem, but I like it. Could have the code run in a sandbox where people can apply “external” network traffic trying to hack it (or apply vulnerabilities), inspired by how you can run ML models on kaggle.org on Kaggle servers to validate models. Have end-points as honney-pots, so if you can access these endpoint you prove you have compromised the code. If there is no new code with patches the keys are released. This way FCC/gov don’t need to maintain a technical system. Just build this once.
agloe_dreams 3y ago
So this feels like an amazing idea...but do we really want to give the federal government the keys to update your equipment remotely and to be able to pinpoint weaknesses of the source? This feels like Edward Snowden's grimmest nightmare.
- Xelynega 3y ago
  As I understand that's not what's being proposed. The "keys" in this case would decrypt the encrypted source code that's available in a public repository, and there's some logical mechanism(and actual use for smart contracts) that would key the key in escrow until certain conditions are met(company doesn't renew, goes out of business, etc.) After which it will be publicly released so anyone can decrypt the already available encrypted source code
  - kristianbrigman 3y ago
    And what happens if the server holding the keys gets compromised? I guess most manufacturers won’t care, but the more reputable ones would have things in their source they consider proprietary and would definitely not want to have to submit it. Verification that it is, in fact, the actual shipped source might not be trivial either.
    - bick_nyers 3y ago
      What happens when someone hacks GitHub and gains access to private repositories? That slim possibility doesn't stop the vast majority of companies from hosting their source in a private repo.
- ics 3y ago
  Framed like that, it sounds terrible. However, consider this: [1] This discussion is about a federal agency providing certification of products essentially in the form of a stamp (on a device, website, etc.). Nothing is stopping a vendor from committing to and offering the same thing but without government involvement. This could easily be a selling point for the paranoid. Something something blockchain and smart contracts... [2] Even though we're discussing IoT devices, it's not necessary that they be capable of updating over the air 24/7. Creative engineers could probably devise a method to prevent complete remote takeover by anyone holding the keys– physical switches, additional authentication required during the support period, etc. [3] Personally, I think the federal government getting access to keys for any IoT device made/sold in the US is the only part of this idea that could already be happening. They can knock on doors or mail subpoenas, plant moles, etc. I would be much more comfortable with a technical solution on the physical device than any presumption of privacy in the current state.
dredmorbius 3y ago
A challenge to this sort of suggestion is that the device OEM rarely controls all the software which goes into a device. There are third-party modules, hardware drivers, and more, which are also components. Then there are patents. Either the escrow would have to apply to all software on the device, regardless of whether owned by the OEM or third parties, or OEMs would be required to vouch for all the included software. I'd prefer the former myself: multiple software and patent assets can be combined, but on support EOL, all those become public domain. Build / release / update toolchains must also be included.
MayeulC 3y ago
I have been thinking that something along these lines should apply to most embedded systems, from mobile phones to game consoles to IoT devices. And more, for cases when companies go under: industrial control automation, etc. However, it's very hard to police: what if the company only provides a header file or so? Or the basic OS but not the UI? Moreover, what counts as "support"? There have been cases where companies refuse to consider remote code execution a "security issue". What's to prevent token updates that let the company claim a product is supported while it's riddled with holes? I could also see companies fighting teeth and nails against this if their devices share a common software base. But hey, you have your support incentive right there!
fidotron 3y ago
The problem here is the government can’t be trusted with the signing keys. They will simply use them to deploy their botnets.
deleted 3y ago
[deleted]

by ics 3y ago

unintendedcons 3y ago

I like this idea! A code&keys escrow org, yes please

bick_nyers 3y ago

This is an amazing idea and I would only buy a product that has this stamp on them. I would put some additional triggers into the publication of source code as well, notably if the company goes out of business. I would also put some kind of timer and renewal process on it, like a company needs to recertify every 1-5 years (pros and cons to different time lengths) and that they have indeed been providing actual updates (and not just fake ones) and actual support.

ics 3y ago
The OEM could be allowed to choose their recertification period, perhaps with slight differences in requirements. Perhaps even different options offered by company size. For example 1-5 employee companies might get a "no recertification, provided as-is" option which releases automatically 3 years after filing. Vendors who re-certify every 6 months could get an extra mark on their stamp or whatever. There are tons of possibilities honestly, and though I've been thinking about it for a long time writing it is much easier to come up with more.
- monch1962 3y ago
  Agree this approach seems to be worth investigating further, but as a citizen of a non-US country, I'd like to see a solution that wasn't based on a US-centric set of controls and governance bodies. These days, with nationalism and populism rampant across the world, I think we need a solution where no one country (or country's leader) can simply decide to turn off critical infrastructure for the rest of the world and/or hold the rest of the world to ransom. Then you run into questions of "do we really want (insert bad country) to be able to expose IOT source code to their evil hackers?". This is a really difficult problem to solve, but ultimately I think ownership of the "keys" to unlock escrowed code needs to reside with (winging it here...) a body such as IEEE or ISO. Or possibly something like a global council where e.g. any 5 countries out of 7 can collaborate via a sharing of keys to release source code, but no one country is able to do so.
  - ics 3y ago
    I completely agree that such a thing should not be US-only. There would need to be a clear distinction between one-gov't backdoor and voluntary regulatory certification, because ultimately the goal would be for other countries to follow suit and provide similar/identical certifications. You could look to standards bodies to provide standard implementation details on what "firmware escrow" is, what exact formats and files must be included, etc. IEEE, ISO, JIS, DIN, and all of them could write or adopt the document. But actually running the service and providing the certification is a little closer to a patent office than organizing standards which is why I propose doing it federally. Think Energy Star (which is a US gov't program based on EPA standards) which has been implemented successfully outside of the US.
punnerud 3y ago
Classic tech to think of technical solutions to a regulatory problem, but I like it. Could have the code run in a sandbox where people can apply “external” network traffic trying to hack it (or apply vulnerabilities), inspired by how you can run ML models on kaggle.org on Kaggle servers to validate models. Have end-points as honney-pots, so if you can access these endpoint you prove you have compromised the code. If there is no new code with patches the keys are released. This way FCC/gov don’t need to maintain a technical system. Just build this once.

agloe_dreams 3y ago

So this feels like an amazing idea...but do we really want to give the federal government the keys to update your equipment remotely and to be able to pinpoint weaknesses of the source? This feels like Edward Snowden's grimmest nightmare.

Xelynega 3y ago
As I understand that's not what's being proposed. The "keys" in this case would decrypt the encrypted source code that's available in a public repository, and there's some logical mechanism(and actual use for smart contracts) that would key the key in escrow until certain conditions are met(company doesn't renew, goes out of business, etc.) After which it will be publicly released so anyone can decrypt the already available encrypted source code
- kristianbrigman 3y ago
  And what happens if the server holding the keys gets compromised? I guess most manufacturers won’t care, but the more reputable ones would have things in their source they consider proprietary and would definitely not want to have to submit it. Verification that it is, in fact, the actual shipped source might not be trivial either.
  - bick_nyers 3y ago
    What happens when someone hacks GitHub and gains access to private repositories? That slim possibility doesn't stop the vast majority of companies from hosting their source in a private repo.
ics 3y ago
Framed like that, it sounds terrible. However, consider this: [1] This discussion is about a federal agency providing certification of products essentially in the form of a stamp (on a device, website, etc.). Nothing is stopping a vendor from committing to and offering the same thing but without government involvement. This could easily be a selling point for the paranoid. Something something blockchain and smart contracts... [2] Even though we're discussing IoT devices, it's not necessary that they be capable of updating over the air 24/7. Creative engineers could probably devise a method to prevent complete remote takeover by anyone holding the keys– physical switches, additional authentication required during the support period, etc. [3] Personally, I think the federal government getting access to keys for any IoT device made/sold in the US is the only part of this idea that could already be happening. They can knock on doors or mail subpoenas, plant moles, etc. I would be much more comfortable with a technical solution on the physical device than any presumption of privacy in the current state.

dredmorbius 3y ago

A challenge to this sort of suggestion is that the device OEM rarely controls all the software which goes into a device. There are third-party modules, hardware drivers, and more, which are also components. Then there are patents. Either the escrow would have to apply to all software on the device, regardless of whether owned by the OEM or third parties, or OEMs would be required to vouch for all the included software. I'd prefer the former myself: multiple software and patent assets can be combined, but on support EOL, all those become public domain. Build / release / update toolchains must also be included.

MayeulC 3y ago

I have been thinking that something along these lines should apply to most embedded systems, from mobile phones to game consoles to IoT devices. And more, for cases when companies go under: industrial control automation, etc. However, it's very hard to police: what if the company only provides a header file or so? Or the basic OS but not the UI? Moreover, what counts as "support"? There have been cases where companies refuse to consider remote code execution a "security issue". What's to prevent token updates that let the company claim a product is supported while it's riddled with holes? I could also see companies fighting teeth and nails against this if their devices share a common software base. But hey, you have your support incentive right there!

fidotron 3y ago

The problem here is the government can’t be trusted with the signing keys. They will simply use them to deploy their botnets.

deleted 3y ago

[deleted]