Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

More awful IoT stuff

mjg59.dreamwidth.org

Post reply on HN
Print view View original

231–240 of 245 posts

Re: More awful IoT stuff

#231

Post by tdkl »

jsondata wrote: post #86
daveguy wrote: post #82

Earlier quoted context omitted.

>What we need is a push for openness and interoperability in the cloud Personally I think that is the opposite of what we need. Most IoT devices should be local-network-only. So if by cloud you mean a personal cloud (local network or VPN), then yes, I agree. Otherwise keep the interwebs away from my thermostat.

That's a fair point, and I agree. However, the reality is that a major selling point for these things is along the lines of "control it from anywhere", and whether people actually need remote access or not, it seems that a lot of consumers still see it as a major upside. Maybe what we really need are more consumer-friendly, self-hosted (and secure) home VPN options. That way you can just run your services on the loca…

Or change the marketing from cloud connected to owning the cloud. I mean, for someone who would depend on stable Internet connection to be able to control all this shit, he'd be off hosting a personal cloud on the same connection as well. Even better, because if there are operations happening in a local network and WAN goes out, the devices will still operate inside the LAN.

Re: More awful IoT stuff

#233

Post by Finnucane »

mschuster91 wrote: post #131

I'd like regulation agencies to mandate, as a condition of market entry, for each and every electronic product: 1) Full firmware source code and required toolchains/sign keys/... be submitted to the national libraries, to be kept for secure archival until the device is officially unsupported by the manufacturer. 2) For networked products, the full source code must be either published, or licensed institutes must perf…

Interestingly, Underwriters Laboratory is starting to get into this game:

http://www.ul.com/cybersecurity/

How good or useful this will be I don't know. But clearly they see this as an area where people will be looking for some expert help; not everyone has the skill of a Linux kernel hacker to check these things for themselves.

Re: More awful IoT stuff

#234

Post by throwaway7767 »

anilgulecha wrote: post #39
almostarockstar wrote: post #36

Sounds like there is a strong need for a standard OS build for IoT devices. I'm not expert in the area, but I would imagine a standard API could be implemented to handle the vast majority of use cases. Connecting to an app securely, turning things on and off, basic scheduling.

I think openwrt on the main unit (a good router) + nodemcu based sensor units would work well. Openwrt is powerful enough to take care of logging, connecting to the internet etc, and the sensor units can form a pseudo mesh using their wifi capabilities.

Ideally the base should be from a project that handles base system upgrades, so that consumers don't have to trust that the vendor is building security updates in a timely manner.

Last I checked, OpenWRT did not do security updates, and it's up to the user to recompile everything if they want newer versions.

Re: More awful IoT stuff

#235

Post by wepple »

voltagex_ wrote: post #209
wepple wrote: post #130

Earlier quoted context omitted.

I think you nailed it: hackers don't want to write blog posts saying "damn, this thing was pretty well made". Perhaps an open-source effort to document & track what work has been done, even if it's just pulling firmware images and taking a look around. Maybe some kind of gamification to motivate researchers to pull things apart and report what they see.

I'll write one when I find something worthy of it. I've got stupidly high standards though. I've bought everything from wireless hard drives to $250 Wifi routers to $20 ethernet/3G bridges and the quality of the firmware is pretty garbage on all of them. I see brand new devices on kernel 2.4 and 2.6 with no upgrade plans in sight, and hacked up kernel trees that have no chance of building except on the developers' Re…

yeah, I love ttys0 blog, it's great.

Perhaps a good strategy would be to still offer an interesting read despite a lack of "hey i found epic 0days and hacked everything":

- here's my methodology

- here are some cool ways they made this thing robust

- here is how I tried/successfully defeated the defenses

- some tooling I created to break this thing

Re: More awful IoT stuff

#236

Post by antoniuschan99 »

CaptSpify wrote: post #223
antoniuschan99 wrote: post #205

Earlier quoted context omitted.

What would you use this device for? I haven't released the code for it yet, but there are plenty of tutorials online. It's using NodeMCU and a DHT11. If there's more interest in hacking the device, I can provide some blogposts or tutorial videos. There are 5 available and 15-25 more are on the way. Please contact me if you're interested. I'm planning on selling it for around $35 and for the first few batches at $30 (…

A few things: Monitor the temperature in my office (I run a few servers) Check the temperature outside. I'm close enough to a major city that everything uses that location, but often it's different from where I'm actually at. My garage. Sometimes I have paints/stains/beer/etc that shouldn't be above/below a certain temperature. I'll look at it more then email you

Cool, thanks!

Re: More awful IoT stuff

#237

Post by DougN7 »

nbadg wrote: post #211
DougN7 wrote: post #193

Earlier quoted context omitted.

I've been debating about hooking my garage door opener up using a built-in feature so I could open the door from my iPhone. I don't trust that whatever central site I'll be connected to is safe. If I _knew_ the vendor had implemented your protocol/software well, and I _knew_ your software was safe, yeah, I'd use it. But I don't know those two things, so no way am I hooking my home's door up to the Internet...

In my case you actually do know that the vendor is using the protocol. You would have to be running the protocol on (in this example) your iPhone in order to talk to it. Everything is client-side verified and enforced by encryption. You wouldn't have any guarantee that the garage door opener isn't also running a separate web connection in the background, but arguably unless you're actively monitoring your LAN (or jus…

When you say I'd have to be running the protocol, wouldn't I really be running their garage door opener app? In other words, how do I know your protocol is being used?

Re: More awful IoT stuff

#238

Post by nbadg »

DougN7 wrote: post #237
nbadg wrote: post #211

Earlier quoted context omitted.

In my case you actually do know that the vendor is using the protocol. You would have to be running the protocol on (in this example) your iPhone in order to talk to it. Everything is client-side verified and enforced by encryption. You wouldn't have any guarantee that the garage door opener isn't also running a separate web connection in the background, but arguably unless you're actively monitoring your LAN (or jus…

When you say I'd have to be running the protocol, wouldn't I really be running their garage door opener app? In other words, how do I know your protocol is being used?

If they were using the protocol, they have two options:

1. Roll their own implementation (highly discouraged). Increase their development burden. Introduce higher maintenance burden. Slightly more flexibility for app deployment. And run the risk of my company disallowing interoperable embedded commercial implementations out of security concerns for the users. Basically, at this point the company is better off not using the protocol.

2. Use our implementation (Hypergolix). Massively decrease development and maintenance burden. They now have an install dependency, though, so distribution is a bit more complicated. Significant reduction in time and money invested in the app.

The critical point is this: with option 1, you're correct in that you don't know the protocol is in use, but it's extremely likely that they wouldn't be using it here, nor advertise that they were. With option two, you know that they are using it, because you have to manually install the application to run the protocol.

Re: More awful IoT stuff

#239

Post by DougN7 »

nbadg wrote: post #238
DougN7 wrote: post #237

Earlier quoted context omitted.

When you say I'd have to be running the protocol, wouldn't I really be running their garage door opener app? In other words, how do I know your protocol is being used?

If they were using the protocol, they have two options: 1. Roll their own implementation (highly discouraged). Increase their development burden. Introduce higher maintenance burden. Slightly more flexibility for app deployment. And run the risk of my company disallowing interoperable embedded commercial implementations out of security concerns for the users. Basically, at this point the company is better off not usi…

With #2 do I know they are using your additional install? Would your app indicate their app was a registered client and was sending commands through it?

Re: More awful IoT stuff

#240

Post by nbadg »

DougN7 wrote: post #239
nbadg wrote: post #238

Earlier quoted context omitted.

If they were using the protocol, they have two options: 1. Roll their own implementation (highly discouraged). Increase their development burden. Introduce higher maintenance burden. Slightly more flexibility for app deployment. And run the risk of my company disallowing interoperable embedded commercial implementations out of security concerns for the users. Basically, at this point the company is better off not usi…

With #2 do I know they are using your additional install? Would your app indicate their app was a registered client and was sending commands through it?

It certainly could, as it has full knowledge of what's connected. That's quite a ways down the road though; for now we're focusing on Razpi computer. Mobile deployment is much more complicated (also a much larger market though).
Post reply on HN