IoT SIG - 2019-12-16

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

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

MattJ, wouldn't TLS client certs do that?

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

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

See: every attempt at DRM ever

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

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

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

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

and the server is a standard server? or what?

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

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

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

Then there is no way to keep a secret secret

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

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

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

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

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

MattJ, your answer was very helpful! Many thanks!

np

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?

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

with this project, we are on ejabberd atm.

I'll look there.

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?

yes, exactly

Then you should be good

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

So to support both you would need two hosts, something like: tlsdevices.example.org and pwdevices.example.org

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

but usually that's a weird thing to do

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.

The S in IoT is for... etc.

:)