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

  17. flow

  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 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