IoT is all about unsecured devices generally?
If this thing is capable of running OpenWRT, it can run some sort of SSL for what it needs. Might be tight and might have to not be OpenSSL, but it can be done.
Lesser-capable devices may have issues. But note that one way or another, the devices must speak some decent encryption to get on to WPA2 networks. Of course that's probably done in the Wifi hardware, but it still shows that it's not like we're living in the 1980s where we literally wouldn't have been able to afford the silicon in a consumer device. Hardware acceleration of SSL shouldn't be that hard to get a hold of, for instance: https://en.wikipedia.org/wiki/SSL_acceleration#Central_proce...
I say only "reasonably" because defending against the "I cracked into the device and stole its cert" is pretty hard, but I'd submit, also not all that realistic a threat in this case. I'm really looking to defend more against "I bashed together some encryption so crappy I can hack this by making you visit a hostile web page" than "I want to use this lightbulb without the NSA knowing". (On that note, an SSL cert only valid to a custom app that your browser won't accept isn't all bad, it prevents that sort of thing.)
I mean, this it total pie-in-the-sky in terms of the ask I'm making here for security knowledge and willingness to do something correctly instead of bashing out some terrible, incorrect crypto with direct and incorrect use of the primitives. But it's possible.
Actually... I won't call myself an SSL expert per se, but one of the things that I find personally frustrating in dealing with some people is that once you do know what's going on, using SSL is often much much simpler than bashing together your own crap crypto. Any sensible SSL library has places to stick the CA certs. Generating them isn't that hard, more just tedious. Generating a big pile of certs at the factory and siging them isn't that hard. Even if you're very sloppy with your SSL usage, where you don't do a great job of protecting your core cert, where you use the root of the CA instead of an intermediate so the private key of the root is "live" in the factory, you don't set up a good revocation solution and you just set the expiration as far into the future as you can, because you probably haven't got a mechanism for updating them... even if you make all those errors, it's still better than just bashing crap crypto together, because it'll still resist more attacks than your crap crypto and it's not really all that hard.
But I have abundant experience that shows people would way rather futz around directly with RSA keys and HMAC and spend days and weeks scraping something together rather than even entertain the suggestion of doing it even half correctly. I don't fully understand it. Do other people find futzing with crypto that fun? I play defense a lot in security, but I honestly find correct crypto a royal pain in the ass and do everything I can to outsource it via SSL (which may not be perfect but isn't necessarily bad and has the advantage of being very defensible when people ask "what do you do to secure things") or NaCL or something. Is it just the psychological difficulty of admitting that you don't really know what you're doing with this crypto stuff? I dunno.
If the user really cares about security enough, they can buy their own real TLS cert and install the cert on the brick.
Of course, one person steals that cert and they've cracked the system wide open. But that's the default case for crap crypto anyhow, so what's the difference, except you spent about 10 minutes in the shell and passed some parameters to your library instead of spending.... well... anything more than 10 minutes futzing around with AES and RSA and so on?
Also, while I understand your use of "nobody" in the slangy English sense rather than the strict mathematical sense, I would point out that as these devices get more sophisticated, eventually they tend towards a manufacturing process that will do something to each one in the factory anyhow. For instance, if you're doing any sort of burn-in testing you've already done the vast bulk of the hard work it would take to also use that time to stick a cert on there. Yeah, your cheap knock-off Wifi light won't do that, but as the industry matures I think you'll see practices that would permit certs without much additional work.
That's not to say that you can't do encryption though, just that you need to rethink how to do it, where the solution is not just unencrypted JSON APIs.
(fast enough for streams in 'real-time' - I don't know)