Friday Hack Chat: Security For IoT

securityforiot-01Over the last few weeks, our weekly Hack Chats on hackaday.io have gathered a crowd. This week, we’re talking about the greatest threat humanity has ever faced: toasters with web browsers.

The topic of this week’s Hack Chat is Security for IoT, because someone shut down the Internet with improperly configured webcams.

This chat is hosted by the Big Crypto Team at the University of Pittsburgh. [Wenchen Wang], [Ziyue Sun], [Brandon Contino], and [Nick Albanese] will be taking questions about lightweight devices connected to the Internet. Discussion will include building things that connect to larger networks securely.

The Big Crypto team at UP are thinking about the roadblocks people have to implement security in their projects, and if apathy or ignorance is the main reason security isn’t even considered in the worst IoT offenders.

The Hack Chat is scheduled for Friday, February 24th at noon PST (20:00 GMT).

Here’s How To Take Part:

join-hack-chatOur Hack Chats are live community events on the Hackaday.io Hack Chat group messaging.

Log into Hackaday.io, visit that page, and look for the ‘Join this Project’ Button. Once you’re part of the project, the button will change to ‘Team Messaging’, which takes you directly to the Hack Chat.

You don’t have to wait until Friday; join whenever you want and you can see what the community is talking about.

Upcoming Hack Chats

These Hack Chats are becoming very popular, and that’s due in no small part to the excellent lineup of speakers we’ve hosted. Already, we’ve had [Lady Ada], [Sprite_tm], and [bunnie] — engineers, hackers, and developers who are at the apex of their field. We’re not resting on our laurels, though: in a few weeks we’ll be hosting Hack Chats with [Roger Thornton], an engineer with Raspberry Pi, and Fictiv, masters of mechanical manufacturing.

28 thoughts on “Friday Hack Chat: Security For IoT

  1. The design goals are a contradiction:
    * Make cheap networked consumer products
    * Add IT security systems like firewalls, IDS, and full crypto hardened protocols
    * The guys who work in sweat shops don’t worry about your problems

    This entire “IoT” political initiative is a joke on ignorant people too greedy to understand their own impractical expectations.

    Fast, cheap, or good — choose any two.

  2. I don’t understand why IoT devices have to connect direct to the internet anyway. I’m working on a lighting controller for home automation and I wouldn’t want to be exposing it to connection from the internet directly. It has potential buffer overflows, no https implementation because of limited power so cleartext passwords etc, and lots of other things that come with the territory.
    What I am happy to do is have a buffer device which I know is much more competent to deal with the wider net based on well tested daemons and protocols with security updates to act as a buffer/shield to act as a band aid for my device’s security, and its methods of communicating with my device are whitelisted in advance and known. Sure none of this is a excuse for the code being poor on the device itself, but the more layers we can add the onion the better. Defense in depth and all that.
    We should all have buffer devices, then we could avoid exposing the ip stack on our lightbulb or thermostats to the net at large yet still have them participate usefully in remote access and management in pre-defined ways.

    The issue is that doesn’t fit the revenue stream of quick device, no extra work on setup, and spaffing as much data as possible to remote servers to be resold to marketeers as a side revenue stream for manufacturers.

    1. If you have another device between your IoT stuff and the ‘net it may open the possibility of attacking at the communication between the small IoT things and your device. This communication is probably less secure because the nodes are probably low power and low resources to make them cheap.

      1. Yes, but what I’m talking about here is not a flat subnet with everything on it including the route-able device, and sitting it all out there warts and all and allowing stray packets to wander round it unhindered.
        I’m suggesting only the device hub itself is routeable from the internet and is multi homed. To compromise the conversation between that and my devices that implies they have breached my local private subnet, by firewall bypass or other methods to get the control packets onto the local private lan let alone working out the topography to bypass the IoT device’s basic acls. At which point all bets are off anyway. “Device” in my case is a multihomed *nix server that has the routing already because it can throw alerts out to pushbullet etc.
        Most people have a router that if it were made securely could act as a gateway buffer device to keep the local private nat’d subnet er… private if we could develop a lightweight enough interface that could do this and just one device to maintain patching on.
        In my case if your on the local subnet, you can control the devices directly too, but outside the subnet and you HAVE to use the buffer device gui to control things/see readings etc.

          1. Thats why my internet enabled TV and bluray player don’t get physically connected to any network…

            What I really don’t get is if some pervert starts tracking the whereabouts and conversations of your children 24/7 we’d all be jumping up and down and getting ready to pour gasoline on the perverts crucifix…yet parents think nothing about allowing kids to have iPhones and Facebook.

      2. But the communications between that buffer and the device should be made limited and specific to the device, therefore the best someone should be able to do is burn your toast, not access the data server in the same net.

    2. I’m curious, I’ve thought of this some before. Do you think there is a market for an IoT/intranet specific security specific firewall or subnet device to act as a proxy between the router and local devices? In a perfect world, this would offload the security aspect of these devices (that have no security) and prevent manufacturers from having to account for wild implementations and updates to their router firmware.

      Maybe this isn’t something that’s applicable and routers can solve this issue through better configurations. General consumers usually don’t configure their routers though, and often are limited by rented device customization capabilities (i.e. router/modem combo through a cable provider).

      1. Quite a few systems use gateways and low power radio for the nodes. But this is more and more falling out of fashion since the ESP came out, because it is simpler to ditch the gateway. Even if this passes on the user the burden or replacing more batteries where necessary.

      2. I think there’s a need for some cheap silicon designed to fill this niche that security can be automated and patched for automatically (very very important, or it’d just be another unpatched device to search for on shogan adding to the problem within a few months of design), and having it as a device between router and lan is actually really useful because it would cover those people stuck on brand xyz of router hardware as you say. Put it in the dmz config or port forward only certain ports to it in your router config and trust it to cope with the same level of trust we put in firewall boxes and stuff. Only allow config changes to it from the lan side interface not the router facing one. Basic concepts.
        However I’m not sure there’s a big commercial market to fund development though :(
        I believe the proprietary hardware IoT makers want you to use their products due to obvious commercial drivers and (s)he who controls the border device firmware controls the products behind it, and controls how the competition’s devices are perceived to inter-operate and behave reliably. I’ve seen big names round conference tables blaming each others kit for interoperability issues in stuff with budgets of millions let alone what we might end up with as home isolation devices, that game goes on at all levels of the tree.
        Plus having the ability to tell the isolation device what it should and shouldn’t be allowing out might let you block things that are not in your interest but are in the companies to get data out of your lan. Gives us back a bit too much control…
        Also there are now companies selling remote access to IoT devices as a subscription service. You can control a HIVE connected thermostat in the UK via your smartphone if your a British Gas customer for example, I think they charge about $10 a month for this service. They’ve developed a new income stream and having hardware devices out there that record their location etc via some kind of ddns service that can be controlled by a app but doesn’t expose your lan to masses of extra risk bypasses this. Maybe they’re the forerunners of this idea commercially, and will flesh that out to cover all the devices in that home, provided you bump your subscription level up.

        1. Thanks for the insight. I work in infosec, but my background is generally in the industrial or healthcare sectors and they’re light years behind even thinking about a consumer facing IoT (with the exception of smart meters). I suppose part of my interest is how much the average individual values their data compared to how much of it is being consumed by corporate industries.

  3. One thing I’m interested in is implementing lightweight security between the IoT nodes and a local server. For example, for some home sensors (temperature, door/window open sensors, power switches, etc), I might not care about putting them on the Internet directly (or maybe even indirectly) — some devices might not even be using TCP/IP, but maybe something like a nRF24L01, or some low speed ASK/OOK modules. But I want to gather data and control these things from a local server. I’m not necessarily worried about the security of the data itself, but I’m concerned about the security of control signals. I don’t want a mischievous neighborhood kid turning my lights on and off, or injecting false temperature readings that might cause my heater to kick on in the summer.

    So I’m looking for a decent kind of shared-secret token generation and handshake that can authenticate a comm session between server and node. I have a general idea for one, but I’d be more than happy to build upon prior art if anyone can point me to something.

          1. The best way forward is to perform the ECDH with ephemeral keys. You authenticate the ephemeral keys by signing them with the authentication keys (that is, the private keys associated with the certificate that identifies the party). This gives you more entropy for the session keys and gives you forward secrecy as a bonus (presuming you’re careful with the ephemeral private key and the session keys).

          2. @nsayer in the case of curve25519 that means you have to implement Ed25519 too, since curve25519 only allows key agreement. And that more than doubles the time needed for the key exchange, triples the message size and nearly doubles the code size. Depending on the attack scenario that could be acceptable or not. That’s why you can’t have one-size-fits-all security.

  4. Anyone who believes a fridge, a toaster, lighting, or, at worst, a child monitor/camera should be interconnected to any semi-public (extra-private) network needs their head either lopping off or investigated for stupidity. These may be the same people who post pictures of their kids online then complain that kiddie-fiddlers are subverting their children’s images. I can see no practical benefit for having interconnection with these kinds of objects. Lazy people who cannot go buy a pint of milk, turn on a light, or open a door should be fed to lions as they are more most likely the same people who would have been naturally consumed in the course of evolution.

    The entire ‘internet of things’ was probably thought up by a failed marketing executive and written on a napkin moments before his boss threw him out of a window.

    1. Sometimes I’m tempted to agree, but a grain of salt (by the user) “fixes” a lot of those defects.
      I think it’s plain stupid having domotic systems depend on external resources availability (Internet connection, cloud services, …): they should be able to work normally in the unconnected case, and offer augmented functionality when connected to online services.
      Another point to consider is user’s privacy: the user should be able to choose what to share with online services and what to keep private.
      IoT can be very useful: some good examples can be found in FutureLearn IoT course: https://www.futurelearn.com/courses/internet-of-things

      1. “they should be able to work normally in the unconnected case, and offer augmented functionality when connected to online services.”

        Agree! I purchased a couple of Belkin Netcam HDs last year (they were heavily discounted). I found out too late that you can’t locally, directly stream video from them. You *have* to do it through Belkin’s servers. I’ve been trying to locate any information on hacks that would allow me to get images/video locally, or write the firmware, but haven’t really found anything yet.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.