IoT SIG - 2020-09-09

debacle, have fun 😁.

COM8 I read it completely yesterday. Very interesting to me, because we are developing a product in my company based on XEP-0163 (PEP), XEP-0178 (client certs), and XEP-0335 (JSON containers). It is not related to smart home, but to meteorological measurements.

debacle, would you consider bloging about that once it is "ready/deployed"?

debacle, btw you may want to talk to daryl from igniterealtime, he does meteorological monitoring via xmpp too

(and a very large scale as far as I understand)

but he is using MUCs IIRC

https://mesonet.agron.iastate.edu/

https://www.extension.iastate.edu/news/iowa-environmental-mesonet-data-used-thousands-every-day

flow, yes, as soon as it's ready, there will be an article/blog post/paper/whatever. Thanks for the links!

i'd fancy a paper

My chance to use LaTeX for other things than complaint letters, again!

One design problem, we had to solve was that: Transmitting measurement data via PubSub is the obvious way to transmit measurement data. Better than direct messages or MUC. But who shall own the PubSub node? If the device owns it (e.g. using PEP with whitelist access), every subscription must be allowed by the device itself, which might be cumbersome, but gives a good security: Only the device owner can change the node settings. If somebody else owns the node, it might be easier for the device, but opens a lot of other questions about permissions. So far, we decided to use PEP (= device owns the nodes), because it feels "XMPPish", but we are concerned, that an owner of a device configures a whitelist, sells the device, and later data is leaked to the previous owners whitelist. I'm not sure, how to solve this.

Btw It seems the weather XMPP stuff is at https://weather.im/ Pretty cool!

debacle, I guess it is often a triangular relationship, where you have the owner, the producing or to be controlled device, and the consumer/controller

and a design decission when it comes to iot with xmpp is whether or not the device uses its own (proably vendor provided) account for its entire lifetime, or if the owner assigns (somehow) an account to the device

in the latter case you don't have to worry about leaking stuff to the previous owner

not sure if that's helpful for you…

I also considered a hybrid model where the device uses the vendor account for bootstraping, and then, after the owner has somehow presented evidence that he/she owns the device, he/she can assign a new account to the device

and if the device is factory reseted, it gets back to using the vendor account

which of course means that you will run potentially into issues in case the vendor ceases to exist ✏

but I gess you can have a fallback for that, e.g. where you can assign a device account if you have physical access to the device

flow I think the idea of bootstrapping an account is interesting. I need to think how this would fit into our concept and our requirements.

One thing we like to do in the final product is to use client certificates, not username/password. Background is, that we like to make it a little bit harder to present fake data. I'm not sure, whether the device has enough entropy to generate a TLS certificate itself.

Never tried it, maybe it is not a problem at all.

debacle, I don't know your device, but I doubt that missing entropy will be a problem

The bootstrapping is not necessarily impossible, if the vendor does not exist anymore. As long as users can get the public key from the device, they can install it on their XMPP server and it would work. Users would only have a little bit less convenience.

Probably more software to install on the device, some openssl stuff. But hopefully not too much.

debacle, just retriving the public key is not enough, no, you also have to point the device to your xmpp server

aren't there some *ssl libs for embedded stuff

not sure how good they are

wolfssl and the like

but yeah, if the device is somehow physically accessible, then you can reconfigure it, even if the vendor is gone

as long as you don't restort to the flashlight smart meter approach ;) ✏

I note that if you attach to the device e.g. via serial or jtag, then you could as well upload a new key to the device, i.e. you don't have to create the key on the device (although that would probably be preferable)

yes, pointing the device to the right server is something we allow anyway

we have a stripped down Debian on the device - we just need to make sure, that we have enough flash left ;-)