-
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 :-)
-
MattJ
debacle, taking XMPP out of the equation, this is a hard/impossible problem to solve (depending on the requirements)
-
debacle
MattJ, wouldn't TLS client certs do that?
-
MattJ
Only if the device connects directly to you, but you said it can use any server
-
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
-
MattJ
See: every attempt at DRM ever
-
debacle
MattJ, the authenticity must be guaranteed only in respect to the server, that is directly connected, btw.
-
MattJ
Client certificates are the best way to do this, then, probably
-
MattJ
Just don't count on the private certificate(s) not being extracted
-
debacle
MattJ, I'm fine with the limitation that physical access brings.
-
MattJ
and the server is a standard server? or what?
-
debacle
MattJ, of course PGP etc. have the same problem. And we don't have any crypto chips on the device.
-
MattJ
Yes, that's why I started with a "taking XMPP out of the equation" - this applies to any method
-
debacle
It's an embedded device, which you and I can "root" in seconds.
-
MattJ
Then there is no way to keep a secret secret
-
MattJ
so someone can copy the private key to their laptop and do TLS pretending to be the device
-
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.)
-
MattJ
If you're fine with that, I'm fine with that - I still think TLS is the best you can do here
-
MattJ
TLS is designed for this (verifying identity), and it's already fairly well supported in XMPP software
-
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 :-)
-
debacle
MattJ, your answer was very helpful! Many thanks!
-
MattJ
np
-
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?
-
MattJ
I don't think Prosody does (currently), but other servers probably do
-
debacle
with this project, we are on ejabberd atm.
-
debacle
I'll look there.
-
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?
-
debacle
yes, exactly
-
MattJ
Then you should be good
-
MattJ
For the record, the limitation with Prosody is that it generally only does a single auth provider per host
-
MattJ
So to support both you would need two hosts, something like: tlsdevices.example.org and pwdevices.example.org
-
MattJ
or you could hack the client cert provider to also support password auth
-
MattJ
but usually that's a weird thing to do
-
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.
-
debacle
The S in IoT is for... etc.
-
MattJ
:)