XSF logo 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 np
  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: tlsdevices.example.org and pwdevices.example.org
  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