4 ms·

The "S" in IoT stands for security. :-/

gjsman-1000 3y ago
Reminder for everyone here who ever feels "Imposter Syndrome": If you built an IoT Device, would you ever: - Not consider changing the root username and password? - Not consider shutting off the SSH server? - Not consider writing the most delicate parts in a memory-safe language? - Not consider enabling Secure Boot or tamper detection? - Not consider building a system for easy and automatic security updates, perhaps with an opt-out for those interested? Almost all of us here would consider the above. Yet most IoT manufacturers never thought of any of them. You're competent.
- networkchad 3y ago
  [dead]
- giantg2 3y ago
  "Yet most IoT manufacturers never thought of any of them." It's possible they did think of these and just didn't do them for various reasons. Like it wasn't worth the cost (not necessarily due to changing the setting, but more from a support side), or they might have an incentive to leave it unsecured (Chinese tech), or something else. The sad part is, the people making the decisions don't have imposter syndrome because they're making money with a success product and any shortcomings must be from the people under them.
  - sumtechguy 3y ago
    Hey boss lets secure this system. We need to do these 10 things. Sure thing... How long will it take and will it get in the way of these 4 features we promised to the customer that they wanted last week? Probably like about a month of work. Well add it to the backlog and we will get to it eventually.
- dilippkumar 3y ago
  Firmware engineer here with an opinion from down in the trenches: The reality is that it takes a ton of work to get a microcontroller to blink an LED. Various clocks need to be configured, various peripheral devices (I2C controllers, GPIO controllers etc) need to be configured, interrupt vector tables need to be set up and so on. Who is expected to do this work? Today, it is done by the semiconductor vendor. When you buy a microcontroller, you’ll use an SDK and a toolchain that the vendor offers. The vendor is incentivized to keep their SDK and tool chain as general as possible to sell into as many different designs as possible. The OEM wants to ship a product as quickly as possible to make their cashflow model work. There’s a huge gap between these two ends where a ton of important stuff goes unaddressed. At no point are the OEM and semiconductor vendor incentivized to sit together and addresses all the issues that fall through the cracks. The current school of thought dominating MBA courses would see addressing these issues as a cost with no tangible benefits to the business. I can see their rationale: if consumers don’t signal that they care about security, then it is actually hard to argue that addressing security is a benefit to the business. Most consumers today don’t know how bad the situation is to care about this stuff. It sucks because we firmware engineers want to do the right thing but we can’t justify it.
  - brightlancer 3y ago
    > The current school of thought dominating MBA courses would see addressing these issues as a cost with no tangible benefits to the business. I can see their rationale: if consumers don’t signal that they care about security, then it is actually hard to argue that addressing security is a benefit to the business. At least in the US, customers are very price conscious and will sacrifice a lot to save a dollar. To frame this from their standpoint, "Why do I have to pay more for ¨features¨ that I don't want?" I think folks _should_ demand more secure devices, but they also must be willing to pay for it. (Many folks will immediately respond, "We'll use the government to force companies to do this!" but that can cost even more, as the company provides the extra features and also pays for the bureaucracy.)
  - ilyt 3y ago
    > The reality is that it takes a ton of work to get a microcontroller to blink an LED. Various clocks need to be configured, various peripheral devices (I2C controllers, GPIO controllers etc) need to be configured, interrupt vector tables need to be set up and so on. No, that's the easy part (even if done manually). The hard part starts with networking > There’s a huge gap between these two ends where a ton of important stuff goes unaddressed. At no point are the OEM and semiconductor vendor incentivized to sit together and addresses all the issues that fall through the cracks. Most SDKs I've seen end up somewhere at level of TCP stack, sometimes at level of simple web server. Because everything above will be very application specific. It's near-entirely on the app vendor to fuck stuff above that. Don't try to push blame on manufacturer of the chip here, they didn't force your password to be 12345678
- jprete 3y ago
  I think I'd start by removing, at the hardware level, the ability of the IoT devices to do general computing and networking. They accept authenticated external control instructions, they execute the instructions, they physically cannot do more. Most likely there would be no updates at all. There would also be a physical off switch. My idea is that, if you limit the IoT device - say, a thermostat or a smart bulb - to only have the exact capabilities it is supposed to have, then the damage from any external hack is limited to messing with the user's house. And, if the user has the ability to turn it off, the damage of the hack is limited to "the device doesn't do anything anymore". I figure this is much better than the possibility that breaking the security enables the IoT device to spy on the user's network traffic, or their house, or be part of a botnet, or a bounce point for hacking attempts. EDIT: I recognize there are good real-world reasons why IoT companies don't do it this way. If we actually valued security, then there would be an incentive for someone to build up the systems to facilitate this kind of limited-attack-value design.
  - AlotOfReading 3y ago
    Given how utterly trivial it is to accidentally achieve turing completeness, I suspect any reasonable subset you could come up with would also be capable of general computation. Moreover, such a design would be inherently expensive and inefficient, because it can't achieve the economies of scale modern uCs do, nor can it do anything without an external (presumably networked) command for every single operation.
  - Mister_Snuggles 3y ago
    The challenge is that even a minimal implementation requires quite a lot of functionality. Take a Wifi-based smart outlet, for example. The functionality is literally a single output that drives a relay. But in order for that to work, it needs to join a Wifi network - that means that you need some way to get an SSID and password onto the device and it needs a DHCP client to get an IP address. There also needs to be a way for the controller to discover the device's IP address, which means there's now likely an mDNS implementation on the device. Then there needs to be a way for the device to receive commands, so now we've got an HTTP server. If you want out-of-home access, which I suspect most people do, there's even more work required. Usually this means a central server that the device connects to since most regular people don't have a VPN connection back home. Another option is HomeKit, which is explicitly about local control with all of the remote access magic handled by Apple. But HomeKit is yet more stuff to run on the device, and only works if you've bought into the Apple ecosystem. This is a ton of scope creep for a pretty minimal device. A Zigbee or Z-Wave based outlet would be better, but that really just moves all of that scope creep from the individual device to the hub.
- pierat 3y ago
  - Not consider changing the root username and password? I would bake it in the bios or similar, and print it on the bottom of the device. - Not consider shutting off the SSH server? I would keep sshd running, precisely for the fact that the person who bought this could modify it I'm a reasonable and sane manner, like any Linux peripheral. It also allows for more extensibility past what I thought of. - Not consider writing the most delicate parts in a memory-safe language? I wouldn't reinvent the wheel. Use Linux, QNX, or Tron. Probably not Tron, but it IS open source. - Not consider enabling Secure Boot or tamper detection? Are we assuming the person who buys this as the enemy, or are we trying to evade Mission Impossible level national spies from looking how some IoT shit works? - Not consider building a system for easy and automatic security updates, perhaps with an opt-out for those interested? Most "security" updates are just malware in disguise. I've seen enough de-featurization and others in the name of security.

Reminder for everyone here who ever feels "Imposter Syndrome": If you built an IoT Device, would you ever: - Not consider changing the root username and password? - Not consider shutting off the SSH server? - Not consider writing the most delicate parts in a memory-safe language? - Not consider enabling Secure Boot or tamper detection? - Not consider building a system for easy and automatic security updates, perhaps with an opt-out for those interested? Almost all of us here would consider the above. Yet most IoT manufacturers never thought of any of them. You're competent.

networkchad 3y ago
[dead]
giantg2 3y ago
"Yet most IoT manufacturers never thought of any of them." It's possible they did think of these and just didn't do them for various reasons. Like it wasn't worth the cost (not necessarily due to changing the setting, but more from a support side), or they might have an incentive to leave it unsecured (Chinese tech), or something else. The sad part is, the people making the decisions don't have imposter syndrome because they're making money with a success product and any shortcomings must be from the people under them.
- sumtechguy 3y ago
  Hey boss lets secure this system. We need to do these 10 things. Sure thing... How long will it take and will it get in the way of these 4 features we promised to the customer that they wanted last week? Probably like about a month of work. Well add it to the backlog and we will get to it eventually.
dilippkumar 3y ago
Firmware engineer here with an opinion from down in the trenches: The reality is that it takes a ton of work to get a microcontroller to blink an LED. Various clocks need to be configured, various peripheral devices (I2C controllers, GPIO controllers etc) need to be configured, interrupt vector tables need to be set up and so on. Who is expected to do this work? Today, it is done by the semiconductor vendor. When you buy a microcontroller, you’ll use an SDK and a toolchain that the vendor offers. The vendor is incentivized to keep their SDK and tool chain as general as possible to sell into as many different designs as possible. The OEM wants to ship a product as quickly as possible to make their cashflow model work. There’s a huge gap between these two ends where a ton of important stuff goes unaddressed. At no point are the OEM and semiconductor vendor incentivized to sit together and addresses all the issues that fall through the cracks. The current school of thought dominating MBA courses would see addressing these issues as a cost with no tangible benefits to the business. I can see their rationale: if consumers don’t signal that they care about security, then it is actually hard to argue that addressing security is a benefit to the business. Most consumers today don’t know how bad the situation is to care about this stuff. It sucks because we firmware engineers want to do the right thing but we can’t justify it.
- brightlancer 3y ago
  > The current school of thought dominating MBA courses would see addressing these issues as a cost with no tangible benefits to the business. I can see their rationale: if consumers don’t signal that they care about security, then it is actually hard to argue that addressing security is a benefit to the business. At least in the US, customers are very price conscious and will sacrifice a lot to save a dollar. To frame this from their standpoint, "Why do I have to pay more for ¨features¨ that I don't want?" I think folks _should_ demand more secure devices, but they also must be willing to pay for it. (Many folks will immediately respond, "We'll use the government to force companies to do this!" but that can cost even more, as the company provides the extra features and also pays for the bureaucracy.)
- ilyt 3y ago
  > The reality is that it takes a ton of work to get a microcontroller to blink an LED. Various clocks need to be configured, various peripheral devices (I2C controllers, GPIO controllers etc) need to be configured, interrupt vector tables need to be set up and so on. No, that's the easy part (even if done manually). The hard part starts with networking > There’s a huge gap between these two ends where a ton of important stuff goes unaddressed. At no point are the OEM and semiconductor vendor incentivized to sit together and addresses all the issues that fall through the cracks. Most SDKs I've seen end up somewhere at level of TCP stack, sometimes at level of simple web server. Because everything above will be very application specific. It's near-entirely on the app vendor to fuck stuff above that. Don't try to push blame on manufacturer of the chip here, they didn't force your password to be 12345678
jprete 3y ago
I think I'd start by removing, at the hardware level, the ability of the IoT devices to do general computing and networking. They accept authenticated external control instructions, they execute the instructions, they physically cannot do more. Most likely there would be no updates at all. There would also be a physical off switch. My idea is that, if you limit the IoT device - say, a thermostat or a smart bulb - to only have the exact capabilities it is supposed to have, then the damage from any external hack is limited to messing with the user's house. And, if the user has the ability to turn it off, the damage of the hack is limited to "the device doesn't do anything anymore". I figure this is much better than the possibility that breaking the security enables the IoT device to spy on the user's network traffic, or their house, or be part of a botnet, or a bounce point for hacking attempts. EDIT: I recognize there are good real-world reasons why IoT companies don't do it this way. If we actually valued security, then there would be an incentive for someone to build up the systems to facilitate this kind of limited-attack-value design.
- AlotOfReading 3y ago
  Given how utterly trivial it is to accidentally achieve turing completeness, I suspect any reasonable subset you could come up with would also be capable of general computation. Moreover, such a design would be inherently expensive and inefficient, because it can't achieve the economies of scale modern uCs do, nor can it do anything without an external (presumably networked) command for every single operation.
- Mister_Snuggles 3y ago
  The challenge is that even a minimal implementation requires quite a lot of functionality. Take a Wifi-based smart outlet, for example. The functionality is literally a single output that drives a relay. But in order for that to work, it needs to join a Wifi network - that means that you need some way to get an SSID and password onto the device and it needs a DHCP client to get an IP address. There also needs to be a way for the controller to discover the device's IP address, which means there's now likely an mDNS implementation on the device. Then there needs to be a way for the device to receive commands, so now we've got an HTTP server. If you want out-of-home access, which I suspect most people do, there's even more work required. Usually this means a central server that the device connects to since most regular people don't have a VPN connection back home. Another option is HomeKit, which is explicitly about local control with all of the remote access magic handled by Apple. But HomeKit is yet more stuff to run on the device, and only works if you've bought into the Apple ecosystem. This is a ton of scope creep for a pretty minimal device. A Zigbee or Z-Wave based outlet would be better, but that really just moves all of that scope creep from the individual device to the hub.
pierat 3y ago
- Not consider changing the root username and password? I would bake it in the bios or similar, and print it on the bottom of the device. - Not consider shutting off the SSH server? I would keep sshd running, precisely for the fact that the person who bought this could modify it I'm a reasonable and sane manner, like any Linux peripheral. It also allows for more extensibility past what I thought of. - Not consider writing the most delicate parts in a memory-safe language? I wouldn't reinvent the wheel. Use Linux, QNX, or Tron. Probably not Tron, but it IS open source. - Not consider enabling Secure Boot or tamper detection? Are we assuming the person who buys this as the enemy, or are we trying to evade Mission Impossible level national spies from looking how some IoT shit works? - Not consider building a system for easy and automatic security updates, perhaps with an opt-out for those interested? Most "security" updates are just malware in disguise. I've seen enough de-featurization and others in the name of security.