Hacker News Reader

> You probably shouldn't leave a sensitive device unattended anyway

I find this area fascinating in terms of how you protect devices that are both sensitive, and need to be left unattended in someone else's possession. One of the best explorations I've seen of this is Big Clive's tear down of a smart meter. The thing is absolutely full of anti-tampering measures, including several switches that will cut off the power supply if the casing is removed, but most interestingly to me the cellular modem being connected to a big capacitor designed to give it just enough power to send out a last cry for help even if the entire radio module is pulled off the meter.

https://www.youtube.com/watch?v=G32NYQpvy8Q

The capacitors may just be part of the standard power supply circuit for the mobile telephone modem.

I looked at the SIM800 module a few months ago - people use them to add mobile connectivity to embedded hardware like Arduino. The module is designed with a 4v LiPo battery in mind as it can draw 2 amps for a few milliseconds when transmitting, so needs a buck converter and hefty capacitors rather than the usual linear voltage regulator.

NB: Not a hardware engineer - was just interested in adding SMS notification to my home alarm.

The modem actively broadcasts the removal, it's a very intentional design choice

The big capacitors are mostly for outage detection, not doofus detection. However, the number of doofuses they help detect is not 0.

> Giving your HW for somebody else to operate, while hoping that this person won't recover secrets from the inside. [...] is a trust issue, and I would avoid those situations anyway.

I hate DRM with a passion, but the same problem is always my concern. If I lost my smartcard (or USB dongle) that stores an OpenPGP private key in a hotel - yes, everything is possible with physical attack, and I should use an extra PIN to symmetrically encrypt the key material on the card anyway - But still, if the attacker decides to extract anything from the card, I'd like to find a way that forces the attacker to pay the maximum price.

An inexpensive security chip can bill the attacker an extra $1000. If the attacker must decap the chip and use some semiconductor test equipment, it's even better.

However, there's a small problem - while forcing the attacker to pay, say $1000, to develop the attack is easy, but it's difficult to guarantee the cost per attack will remain the same - if a noninvasive attack has ever been found (e.g. fault injection), the marginal cost of new attacks becomes essentially zero. And unlike software, the smartcard is useless at this point, and it cannot be patched. If it's a FOSS hardware design, everyone is now vulnerable. Worse, it doesn't help that these attacks are rarely published - before you start using it, you have no idea how secure it really is, and after you start using it, you have no idea how vulnerable it has become. Solution? Use the latest security chip and upgrade your smartcard to a new design frequently. Unfortunately, the secure chip industry is basically owned by the DRM/financial companies, and the best chips are behind layers and layers of NDA, and even then, they're often only sold to a restricted list of consumers. It protects them, not us...

Ah, yes, this is true. One option is to use that as just one authentication factor, and revoke it if it is lost.

One could use it with a password, as is commonly done, but you could imagine combining it with a key stored on a server, making it a two-layer key system.

That way, extracting the key would likely be of no use to someone who stole it, provided you can revoke access quickly enough. So yeah, hardware security measures can be useful, but do not necessarily need to be 100% foolproof.

> you probably shouldn't leave a sensitive device unattended anyway

Almost every ESP32 device is left unattended while storing the owner's wifi credentials.

You can't exactly make a wifi doorbell, or wifi thermostat, or wifi lightbulb, or wifi security camera, without storing a wifi password.

Of course, a cynic would say product manufacturers deploy these features hoping to protect their source code, rather than to keep the customer's wifi passwords safe.

IMO that's more an issue with (customer) WiFi, than the device itself. WiFi is the very last place where people living together have to share one common secret for their security, and that's pretty ridiculous. At least with WPA3 we get perfect forward secrecy even with shared password...

Do you also get PFS with Opportunistic Wireless Encryption?

> You can't exactly make a wifi doorbell, or wifi thermostat, or wifi lightbulb, or wifi security camera, without storing a wifi password.

Sure you could. It would just require the access point to provide a passwordless guest network for such devices to use, and then encrypt the traffic end to end for the actual security.

You would have to store some kind of key material though.

Nope, the client device only needs the server's public key, which isn't a secret. The session keys are a secret but they're also different for every device, transient and never written to permanent storage.

Then any device can connect to that server, not just authorized devices.

Maybe you assume that's okay, but it's an attack vector on the server, and it means someone can emulate a device that isn't really one.

The device can identify itself with a UUID, which isn't key material and doesn't allow anyone to break the channel between the actual device and the server, which is still authenticated by the client using the server's public key. The attacker could generate a random UUID and connect to the server, but then it just shows up as an unconfigured device and gets ignored.

The attacker would have to extract the UUID from the device it wanted to impersonate, which still wouldn't allow it to impersonate any other device the same way a WiFi password does, and would then be detectable because there would be two devices claiming to have the same UUID, at which point you generate a new one for the real device after addressing whatever allowed the attacker to extract it to begin with.

So now:

A) routers must support network isolated guest network

B) anyome can connect to my internet to download stuff

C) if my compuer and IoT hub is on my main network, and the lightbulb is on the guest one, how do they talk? Through the third party server? What if there is no internet, I can't control my lights?

The actual solution is to have individualised passwords for each device that can be revoked, isolated, etc. Those features are not found in 'normal' wifi routers

Why would that network need to provide internet connectivity? Have the Wi-Fi gateway perform the authentication and provide an interface, or use a vlan connected to a server that handles that.

> Those features are not found in 'normal' wifi routers

Then deplore the state of current consumer wi-fi routers and protocols. We can do better than this.

More to the point, Wi-Fi wasn't really designed for this, so maybe a new kind of extension is warranted (like NAN, P2P, mesh, etc). Or use another protocol: Zigbee, Lora, z-wave, etc. These generally have the guarantees you want, sometimes do mesh networking, etc.

In the past, I've used a raspberrypi3 as a "IoT hub", using its wi-fi network to connect "smart" devices. The third-party server was my hub. Everything works without internet. The dedicated wi-fi network doesn't have internet. You can even lower the bandwidth to 20 MHz, and 1Mbps to achieve greater ranges on that channel.

> if my compuer and IoT hub is on my main network, and the lightbulb is on the guest one, how do they talk?

If your IoT devices aren't on the same subnet as your smartphone or computer, the vast majority of their "frontend apps" are already DOA. If you're lucky, those apps might let you explicitly specify the device's IP address (in a half-baked fashion that still doesn't work very well).

A smart doorbell, light bulb, nanny cam, etc require methods to connect and identify with cloud resources.

Obviously you wouldn't want to have to type in a password or use a secure card to turn your lights on.

I agree with sibling phh.

Not sure if supported by the ESP32, and it's kind of complex to setup, but I think you could set up a per-device password, with WPA enterprise (PEAP/MSCHAPv2), and a RADIUS authentication server.

What you want to do with that is another question. You can't really do anything against someone who decides to fake your thermostat reading, but having access to the hardware already defeats that.

At least you limit the impact to the one device that was stolen. Having someone check that the device is still there could be helpful. And since that attack still takes some time to perform, some monitoring could detect that the thermostat/etc hasn't been connected in a while.

I am not sure how useful extracting a Wi-Fi password that's only used by the doorbell would be?

They also deploy these features to prevent unsigned code from running and creating botnets.

There is a tradeoff for letting users run their own code on these devices: people other than the device owner may be able to run code on them too.

> You can't exactly make a wifi doorbell, or wifi thermostat, or wifi lightbulb, or wifi security camera, without storing a wifi password

What I am thinking of doing for the outdoor weather station I will someday get around to finishing is to have it be on a separate WiFi network. To get data from it you will have to connect to that WiFi network.

Inside the house, I'll have an RPi or something like that which has WiFi and Ethernet that will use its WiFi to connect to the weather station's network and Ethernet to connect to my home LAN.

If someone steals the weather station, the only password they get is the password to the weather station network, assuming that it has one (not sure yet...may make it open so that anyone in WiFi range can connect and read the data).

Same thing for the automatic wildlife camera I'm contemplating. Probably that will go on the same WiFi network as the weather station.

VLANs and a decent firewall/router are your friend.

Depending on the capabilities of your WiFi gear, you can just run these devices off of a second wireless network which backends onto a separate VLAN. You can then use firewall rules to determine what traffic is allowed to pass between VLANs.

I do this for my cameras (no traffic out from the VLAN, but allow connections in from the NVR machine) and IoT devices (traffic to the internet is allowed, only some traffic to my other networks is allowed). It works very well.

I use Unifi for my networking gear, but I've done the same thing with DD-WRT on an Asus router/AP device.

> What is desperately needed is the hardware equivalent of a software checksum, to verify that the device conforms to specs.

The problem is, how can you know the OS hasn't been replaced with a fake that bypasses the checksum and keylogs your password?

Without Secure Boot, a TPM already accomplishes what you're asking -- it won't release the disk encryption key to the OS unless the "hardware checksum" is correct.

A TPM usually only checks the software (firmware), you could theoretically plant something in the hardware and have it undetected by the TPM.

I am pretty sure there is no way to achieve that currently, but with such a concept, the device performing the checksum would be trusted (like a USB stick with verified HW+SW).

An example of such a hardware checksum might be a turntable, used to compute the inertia matrix of your hardware. Most tampering (like the bloomberg story plant) should be detectable, up to a certain scale. Unfortunately, it can be compensated, and is not effective against some classes of attacks (frying components, microscopic circuit tampering, etc). It depends on your threat model, anyway.

There was a great write up by someone about designing a Trusted computing type of authentication device and how it should operate. I believe the requirements were write-only flash for the program code and an interface to reflash it. That way you can create whatever program you want and embed whatever secrets you want in it yourself and if you lose it, nobody should be able to retrieve them. I think that would be a use case of hardened hardware. Same with a lost cell phone type of thing.

Would you please share the URL of that article?

I wish I had bookmarked it. I tried to find it and couldn’t. I’m sorry.

> I generally tend to think that an attacker with hardware access will compromise that hardware sooner or later, and you should design your security measures around that assumption.

There are two types of hardware attackers. Those who have home tools and those who have access to lab equipment. Unless you're designing a smartcard, you're only going to have the budget to protect against the former.

But you can't guarantee that the security won't be broken in 30 years, when we have another infineon-class fiasco (https://nvd.nist.gov/vuln/detail/CVE-2017-15361 I think), or in 300 years when you'll be able to buy nanites by the kilogram at the convenience store.

It seems obvious (I hope) that you can't protect that kind of technology against secret leakage on these timescales. I think it's wishful thinking that the technology you are relying on won't be broken in a one-year timeframe. Unlikely, I agree, but that happens, and you just hope that it will be someone else's tech, not the one you rely on to keep your secrets. The only practical measure you can take at that point is buying insurance :)

So, in any case, you have to make sure the secrets you are storing in HW aren't too important, and can be rotated easily.

I would add a third kind of hardware attacks class to your list, which is the one I think justifies these developments: the kind that can be performed by an evil maid. No shutdown, 30s to 2 hours to perform the attack, on-site. Luckily, it's rather easy to protect against that (a solid case would).

You can't guarantee security of anything, ever. But that doesn't mean you shouldn't try to prevent attacks.

Of course timescales and assets are important. For the movie streaming industry, it's a certain number of months before and after a stream is publicly released. After sales have been made, there are diminishing returns when trying to protect the content.

> I think it's wishful thinking that the technology you are relying on won't be broken in a one-year timeframe

It depends on what your assets are, your threat coverage and who you are trying to protect against. Some people are successful at doing this for more than a year's timeframe, which is enough to be overall successful. If you're developing something as popular and precious as an iPhone, it's far more challenging.

Nothing lasts years. The economical side of security is always to reduce the likelihood and impact of threats until they aren't worth worrying about.

> But you can't guarantee that the security won't be broken in 30 years

Yes, you can. Easily, relative to what you already need to protect against physical tampering today. Include a real time clock, and a comparator that, after 29 years, sets off the anti-tampering magnesium/thermite/whatever charge to destroy your data storage. In fact, you probably don't even need the comparator as such; just use a carry bit from the RTC. Guaranteeing that the security won't be broken in less than 30 years (really, less than X years for whatever X you set the self-destruct to) is the hard part.

I know you can't infer it from my post, but I'm totally on the side that pretty much no device should have secrets to protect, and the vast majority of secure boot features are anti-consumer.

However I still think it's interesting to understand how to make things secure if you need t.

Using your devices how you want is reasonable I believe. It's reasonable if someone wants to turn their IoT hub or device into something else. However, an important issue is protecting access to cloud resources. Making sure a stolen hub doesn't give you access to someone's home and appliances remotely.