US Senators To Introduce Bill To Secure 'Internet of Things' (reuters.com)

Dustin Volz, reporting for Reuters: A bipartisan group of U.S. senators on Tuesday plans to introduce legislation seeking to address vulnerabilities in computing devices embedded in everyday objects -- known in the tech industry as the "internet of things" -- which experts have long warned poses a threat to global cyber security. The new bill would require vendors that provide internet-connected equipment to the U.S. government to ensure their products are patchable and conform to industry security standards. It would also prohibit vendors from supplying devices that have unchangeable passwords or possess known security vulnerabilities. Republicans Cory Gardner and Steve Daines and Democrats Mark Warner and Ron Wyden are sponsoring the legislation, which was drafted with input from technology experts at the Atlantic Council and Harvard University. A Senate aide who helped write the bill said that companion legislation in the House was expected soon.

Comments

Re:Instead of Perimeter Security

[bluefoxlucid]

I've actually thought a lot about IoT security, as well as independence from service providers.

I had at some point started this but uh. Was ... diverted.

The idea was to have an IoT hub that acts as the gateway to your IoT device. An IoT device or client would connect to an IoT hub via some system (e.g. Bluetooth) that's not flat-out open (e.g. you have to push a button and confirm pairing). The IoT hub uses a self-signed TLS certificate and exchanges it with a newly-generated certificate on the device or client. Viola: identity.

It works with self-signed certificates because you have to be physically present to exchange them: you've verified face-to-face with the issuer, so the certificate is valid. Because of this trust, the IoT hub can sign extra certificates, acting as a CA.

The IoT hub can get itself an IPv6 Internet address. If so, it can exchange that address to your client (e.g. phone, Yubikey) or IoT device (which might now be in another building, communicating over the Internet to your hub!). Now your devices know how to talk to the hub, and can tell it their address if they so desire when they're somewhere off in another network or on the local LAN.

When your phone, computer, or anything else tries to talk to the IoT Hub, the HTTPS connection initiates over TLS using the exchanged keys: each device authenticates the other by validating certificates first. Your entire attack surface is the Kernel's network stack and facilities it uses; the code paths in the Web server that handle the request; and the code paths in your encryption library that validate e.g. Curve 25519 ECC (TLS 1.3 required). If you have an exploitable vulnerability and it's not in that set of code, then your IoT Hub and your IoT devices are patently unhackable, period.

Let's face it: You can't hack what you can't access. The surface I describe above is equivalent to the air gap when you unplug a network cable, except this air gap might be hackable. If you can't hack that air gap, you can't hack what's behind it.

That leaves you one big, important piece of security: key management. You have to keep those private keys on the client devices away from malicious actors (hackers, worms, trojans). Pass-through to a Yubikey U2F would be great, but ...tricky. The only way to use a hardware security key is to validate the certificate, then do a U2F validation, enlarging the attack surface. In theory, the client software could send a challenge to the Yubikey, get a response, and send a signed session key down the pipe encrypted with the IoT Hub's public key; but you can't use the Yubikey to decrypt something sent encrypted by the certificate, so it's a no-go.

This is actually app-to-app 2-factor if you're doing it by TLS exchange, then U2F: the app "knows" (permanently stores) its TLS key, and it "has" (is running on a machine physically capable of accessing) the Yubikey.

So, yeah. Unhackable IoT proxy, for some reasonable definition of "unhackable" (that being the reduction of probability of hackability by restricting the portion of running code in which vulnerabilities will enable a successful exploit).

The other part was to provide service, either in proxy or right on the IoT hub, packaged as Docker containers. You'd have to provide authentication per-app, validated by IoT device identity (i.e. your Nest Cams each have a separate key, and those keys identify them, and those devices are given access only to the Nest Cam service) or by Client identity (each client application would have a separate key) both at the front-end Web server and by the service itself. Services may be clients of each other.

So what have we got?

You can access your IoT devices through your own public IP, rather than bouncing through a cloud service.

You may be able to disconnect your IoT from the cloud. Google has a lot of stuff with the Ne