IoT SIG - 2020-09-09


  1. SouL has left
  2. SouL has joined
  3. Tobi has joined
  4. Vaulor has joined
  5. COM8 has joined
  6. COM8 has left
  7. COM8 has joined
  8. COM8 debacle, have fun 😁.
  9. COM8 has left
  10. debacle has joined
  11. debacle 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.
  12. flow debacle, would you consider bloging about that once it is "ready/deployed"?
  13. flow debacle, btw you may want to talk to daryl from igniterealtime, he does meteorological monitoring via xmpp too
  14. flow (and a very large scale as far as I understand)
  15. flow but he is using MUCs IIRC
  16. flow https://mesonet.agron.iastate.edu/
  17. flow https://www.extension.iastate.edu/news/iowa-environmental-mesonet-data-used-thousands-every-day
  18. debacle flow, yes, as soon as it's ready, there will be an article/blog post/paper/whatever. Thanks for the links!
  19. flow i'd fancy a paper
  20. debacle My chance to use LaTeX for other things than complaint letters, again!
  21. debacle 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.
  22. debacle Btw It seems the weather XMPP stuff is at https://weather.im/ Pretty cool!
  23. flow 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
  24. flow 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
  25. flow in the latter case you don't have to worry about leaking stuff to the previous owner
  26. flow not sure if that's helpful for you…
  27. flow 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
  28. flow and if the device is factory reseted, it gets back to using the vendor account
  29. flow which of course means that you will run potentially into issues in case the vendor cases to exist
  30. flow which of course means that you will run potentially into issues in case the vendor ceases to exist
  31. flow 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
  32. debacle 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.
  33. debacle 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.
  34. debacle Never tried it, maybe it is not a problem at all.
  35. flow debacle, I don't know your device, but I doubt that missing entropy will be a problem
  36. debacle 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.
  37. debacle Probably more software to install on the device, some openssl stuff. But hopefully not too much.
  38. flow debacle, just retriving the public key is not enough, no, you also have to point the device to your xmpp server
  39. flow aren't there some *ssl libs for embedded stuff
  40. flow not sure how good they are
  41. flow wolfssl and the like
  42. flow but yeah, if the device is somehow physically accessible, then you can reconfigure it, even if the vendor is gone
  43. flow as long as you don't restort to the flashlight smart meter approach
  44. flow as long as you don't restort to the flashlight smart meter approach ;)
  45. flow 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)
  46. debacle yes, pointing the device to the right server is something we allow anyway
  47. debacle we have a stripped down Debian on the device - we just need to make sure, that we have enough flash left ;-)
  48. COM8 has joined
  49. COM8 has left
  50. debacle has left
  51. debacle has joined
  52. Tobi has left
  53. Vaulor has left
  54. SouL has left
  55. debacle has left