2

I want to develop a server for a sensor on the Internet of things (IoT). Everybody can buy the App for that specific sensor. The App will exchange data with the server. How can the server validate that data is really stemming from a legitimate App?

Since everybody can buy the App and a compatible sensor, 'everybody' can also disassemble/hack and copy the authentication into a non-legit app, also if the server would provide a one time license code, or a pre-shared key, or a certificate.

Looking at DTLS-based Security with two-way Authentication for IoT, it seems that a trusted platform module (TPM) is the way to go. But that would not be a viable solution for an App in an App store, wouldn't it?

Is there any other way for the server to validate that a message is really from a legitimate App? Perhaps a way that is not as strong as a TPM, but still acceptable depending on the value of the data to protect?

| improve this question | |
  • Youre now talking about burglar alarms, when in my mind (a shortcoming on my part admittedly) IoT is about fun and convenience. How about a certificate obtained through other means such as direct connection/bluetooth (that is only enabled until the cert is downloaded or enabled by the original cert). IoT is (generally speaking) so horribly hacked together, its nice to see someone taking some consideration to it - but security is often very case specific which is a disadvantage for general purpose sensors... – user2867314 Jan 15 '15 at 14:04
1

Software is inherently copyable, as all those who have tried to prevent copies of their software from getting out have found. Crackers have more time to spend than you do, and they only have to find one exploit.

If you're talking about app stores, then you've got five major choices:

  • Trust your users, and keep your software simple and robust.
    • I recommend this one.
  • Choose app stores whose validation mechanisms you trust to be "good enough", and use those.
    • Second best
  • Sell a piece of hardware that's an authenticator (a dongle) and then give the app away for free, since without the dongle/authenticator it's worthless.
    • For instance, a Yubico FIDO, or try to find a Bluetooth smart card reader.
    • Or use one already available, like the TPM you mentioned.
      • If you do, be explicit and obvious in your requirements; many customers, myself included, disable TPM.
  • Spend large amounts of time and effort on so-so solutions that won't do much in the end
    • And then even more dealing with customers who travel a lot, switch devices often, and so on and so forth who still want your app to work.
  • Make your own app store, tie each card to an account, and do a per-service or per-time charge that runs out.
    • And, again, deal with angry customers whose accounts were stolen (perhaps because they use a lousy password) and thus paid for services they aren't receiving.
      • And the credit card companies who did a chargeback on you.
| improve this answer | |
  • Thanks. In short you confirm the way promoted in the draft standard I mentioned: a TPM. The best and second best do not apply: Trusting the users is OK, but for example I would not like that a burglar can trick my sensor readings, though that comparison does somewhat fail. – Dick99999 Jan 15 '15 at 9:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.