IoT SIG - 2019-12-16

  1. debacle has left

  2. Alacer has joined

  3. Alacer has left

  4. Tobi has joined

  5. Alacer has joined

  6. Alacer has left

  7. Alacer has joined

  8. Alacer has left

  9. Alacer has joined

  10. Tobi has left

  11. Tobi has joined

  12. Alacer has left

  13. debacle has joined

  14. Alacer has joined

  15. Alacer has left

  16. Alacer has joined

  17. debacle has left

  18. Alacer has left

  19. Alacer has joined

  20. debacle has joined

  21. Alacer has left

  22. debacle

    I want, that a server can be sure, that an IoT device is really the genuine IoT device, and not an imposter, when starting a session. The IoT device allows to select any server. Therefore, username/password cannot be secret. If they are not secret, they cannot guarantee authenticity. What other options are there? I came across: 1. Client side certificate (has a secret part, that is only on the IoT device) 2. PGP (has a secret key, that is only on the IoT device) PGP seems to very heavy, and there is no need to sign every stanza. Therefore I lean towards client side certs. Any drawbacks? Better ideas? Esp. from the IoT gurus (flow, MattJ), but of course every help is welcome :-)

  23. MattJ

    debacle, taking XMPP out of the equation, this is a hard/impossible problem to solve (depending on the requirements)

  24. debacle

    MattJ, wouldn't TLS client certs do that?

  25. MattJ

    Only if the device connects directly to you, but you said it can use any server

  26. MattJ

    And even if the TLS is directly to you, the "secret" part on the device is not secret if you're handing it over to users

  27. MattJ

    See: every attempt at DRM ever

  28. debacle

    MattJ, the authenticity must be guaranteed only in respect to the server, that is directly connected, btw.

  29. MattJ

    Client certificates are the best way to do this, then, probably

  30. MattJ

    Just don't count on the private certificate(s) not being extracted

  31. debacle

    MattJ, I'm fine with the limitation that physical access brings.

  32. MattJ

    and the server is a standard server? or what?

  33. debacle

    MattJ, of course PGP etc. have the same problem. And we don't have any crypto chips on the device.

  34. MattJ

    Yes, that's why I started with a "taking XMPP out of the equation" - this applies to any method

  35. debacle

    It's an embedded device, which you and I can "root" in seconds.

  36. MattJ

    Then there is no way to keep a secret secret

  37. MattJ

    so someone can copy the private key to their laptop and do TLS pretending to be the device

  38. debacle

    Just to be sure not to forget any option: Any other idea than PGP and TLS client certs? (With the same limitations accepted, of course.)

  39. MattJ

    If you're fine with that, I'm fine with that - I still think TLS is the best you can do here

  40. MattJ

    TLS is designed for this (verifying identity), and it's already fairly well supported in XMPP software

  41. debacle

    Good! Maybe a later hardware revision will have a crypto something included, which does TLS etc. without allowing key copying. Not 100 % safe, but better than now. Let's see, who wants to pay for that :-)

  42. debacle

    MattJ, your answer was very helpful! Many thanks!

  43. MattJ


  44. Alacer has joined

  45. debacle

    MattJ, now I need a way to distinguish IoT devices (need TLS cert) and "normal" clients (= username/password). But I hope/assume, that common servers do support selection of method per JID?

  46. MattJ

    I don't think Prosody does (currently), but other servers probably do

  47. debacle

    with this project, we are on ejabberd atm.

  48. debacle

    I'll look there.

  49. MattJ

    Generally with TLS auth, the username/JID is taken from the certificate, which would require a different certificate per unique device... is that what you want?

  50. debacle

    yes, exactly

  51. MattJ

    Then you should be good

  52. MattJ

    For the record, the limitation with Prosody is that it generally only does a single auth provider per host

  53. MattJ

    So to support both you would need two hosts, something like: and

  54. MattJ

    or you could hack the client cert provider to also support password auth

  55. MattJ

    but usually that's a weird thing to do

  56. debacle

    Maybe having two hostnames is not a bad idea anyway. It would allow wild hacks, such as requiring less secure ciphers from IoT devices than from other clients.

  57. debacle

    The S in IoT is for... etc.

  58. MattJ


  59. Alacer has left

  60. debacle has left

  61. Alacer has joined

  62. debacle has joined

  63. debacle has left