711–720 of 944 posts
Earlier quoted context omitted.
Have you ever used contract law in that manner? Did you call up Apple and negotiate a contract for your new iPhone, imposing requirements on them? Give it a try and report back.
Have a look at https://www.apple.com/sg/support/professional/enterprise/
Ridiculous that a company can brick your devices by shutting down their servers and/or going out of business. Some people have suggested forcing companies to open source their software on death so that someone, somewhere might be able to keep the smart devices alive but this is difficult implications for capitalizing hardware companies and probably causes more problems than it’s worth.
That’s why, instead I think we should make hardware companies which produce “smart” devices dependent on their software to function should be required to do what we make banks do: pay for the risk of their own failure.
The problem is that consumers simply aren't equipped to make security-informed decisions even with perfect information. How many years of updates matters little if the software has vulnerabilities to begin with. And there's no guarantee manufacturers will fully honor the length they claim.
Rather than disclosure rules, I believe we need minimum security standards that all IoT devices must meet before sale, eg:
No hard-coded credentials/keys Encryption of sensitive data Ability to patch known vulnerabilities Use of secure boot to prevent unauthorized firmware Standards could be tiered by device type and risk level. Compliance could be self-certified with spot audits, like PCI DSS.
This puts the burden on manufacturers to build more secure devices upfront, not just promise to patch them later. Consumers benefit from safer defaults without needing to become security experts themselves.
Standards also allow security to improve over time as threats evolve. Disclosure rules would quickly become static and outdated.
I'm sympathetic to manufacturer concerns about costs, but I think basic security is a reasonable consumer expectation by now. If we act soon, we can prevent IoT disasters before the market grows even further. I hope you'll consider proposing minimum standards within the FCC or partnering with other agencies like NIST who could.
This is not really relevant to the proposed rulemaking but it is something that bugs me deeply, and would like to get off my chest. I would like to see a mandate that red LED be wired inband to every camera and microphone, on every device, so if it is powered up, the LED is also. This is what John Gilmore proposed in 2004, and we adopted in the OLPC project, as the first step towards not being ubiquitously surveilled…
Often the camera/mic is dumb, oblivious to the status of downstream recording. Passive mics aren't even powered.
I understand the concern about signalling recording status, but it's too late for people to adjust their expectations of recording status from the presence of a red light.
Earlier quoted context omitted.
> Remote update mechanisms can themselves present security problems in some domains. I've proposed many times that the device have a physical write-enable switch on it, not a software switch. That way, a malware infestation won't survive a reboot, and your backup hard drives won't get compromised. I'm amazed that nobody does this. (Hard drives used to have a write-enable switch on them.)
Why doesn't MS do similar on all of their OS code by placing it on a read-only filesystem? Only allow updates when reboot into an update mode.
Earlier quoted context omitted.
> It is hard for manufacturers to do this with small teams. Mostly because they do not always have good CI/CD or platforms available to keep being on top of vulnerabilities and so on and so forth. "It is hard for hospitals to keep their ORs clean with small teams. Mostly because they do not always have good cleaning products or procedures available to keep being on top of contaminations and so forth". I do not believ…
Liability chain in many industries is a fantastic way to build a large legal moat to prevent competition from small players. The goal of any regulatory agency must be to ensure as much safety as can be done while preserving the ability of small players to enter the field and compete & while keeping the costs low for consumers. Otherwise, safety becomes a rationale that larger corporations are excellent at spinning to…
Earlier quoted context omitted.
I'd sure hate to have my system ransomware compromised, and when I try to restore from a backup drive, the ransomware encrypts it, too, as soon as I plug it in. I also have, on occasion, flipped the from and to parts of the command to restore from a backup. I'd really like to have a hardware switch to make the drive read-only.
They exist, but only as very expensive specialty gear for digital forensic investigators. https://digitalintelligence.com/store
Indeed, for a 2 cent switch.
Earlier quoted context omitted.
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 av…
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.
Earlier quoted context omitted.
Also, security researchers should have strong legal protections; they should be given the benefit of the doubt at every turn. Currently, researchers are sometimes threatened with decades in prison for testing the security of websites or devices. If they act in good faith as researchers, this should never happen. This is literally a national security issue. We currently stifle security research on essential IoT device…
This might be an unpopular opinion but I respectfully do not see it that way. I agree with promoting security for IoT devices, but there needs to be consent from the company being probed for vulnerabilities or else I find it hard to consider it legitimate research, regardless of intent. I dont think anyone would like it very much if someone came to their house and documented all the ways to rob it they could find, ev…
Conversely, with vulnerable IoT devices, we're talking about internet-connected devices. The potential harm is to everyone on the Internet, not just one household, when they're taken over and made part of a botnet. An attacker can exploit them from anywhere in the world, including residents of hostile jurisdictions that are tolerant (or actively supportive) of such activity. Russia, North Korea, Iran, etc. The protections people have relied on for centuries to defend their residences from bad guys don't apply anymore.
These IoT devices can also be used to gain a foothold in your home network, which are usually flat networks. It's surprisingly difficult to find a "router" for home use at a reasonable price point that can setup VLANs, by the way. Even as a technical person.
The better analogy IMO is to building codes, where your property rights are limited by society's interest to keep your family safe, but more importantly, your neighbors safe too, because fires spread. It's still an imperfect analogy for a number of reasons. Cyberattacks are a relatively novel kind of threat. All analogies are going to be imperfect.
Earlier quoted context omitted.
Releasing Signing keys seems a potentially dangerous one. Someone could produce malicious firmware, sign it, and convince your device to auto-update with it. I think (and I'm a security know-nothing, so could very well be off in the weeds), the firmware should accept updates signed with two keys. The manufacturer key, which can allow automatic updates, and a post-service key that cannot be automatic. Either a user ha…
Presumably they'd remove the auto-update functionality before releasing signing keys and require that it be physically loaded by a user at that point.
Ideally, the key would also be pre-registered somewhere to ensure they can't skip out on releasing it, but I'm not sure how you do that without it potentially leaking before the device reaches end of support. I guess a code sitting in a lawyer's vault somewhere. Again, nobody is paying the lawyer to refresh his vault's firmware image after each patch, so 2nd key wins over unlock firmware again.
Why a lawyer's vault? I know lots of people would love to take ownership of the device immediately, but from the device creator's perspective, they tend not to like that... especially if a device is a source of subscription revenue. So I'm not sure how you'd get vendor buy in to early release unless it becomes mandatory... which I can't see.