3

I am building a tracking device and am looking for a secure authentication method to use when the device wants to establish a connection to the server.

The server is a TCP server that we open a connection with over TLS. We use TLS to encrypt traffic between the device and the server to rule out the chances of having the data being sniffed by a hacker. The device establishes a connection with the server using mobile network data from the onboard SIM.

If the device is physically compromised, this isn't a problem (we're not bothered about preventing this, as if they've lost the device it's not their location anyway). Also, as we're using TLS, we don't have to worry about someone scanning communications between the device and the mobile network. The main concern is to stop someone from spoofing/emulating one of the tracking devices. We don't want hackers setting the location of another user's tracking device.

Would it be sufficient to provide a device ID and a secure hash password that we send to the TCP server for authentication (obviously unique for each device) when a connection is established? I am unsure of authentication methods here and would appreciate any guidance.

BOUNTY EDIT: Some comments mention the best way to do this is through client certificates. I do not have any knowledge in this area and if this is the best option, would be interested to see an answer explaining this in more detail. Also, on a complete sidenote, would it be a bad idea to stop using TLS in our devices and use another method that doesn't include encryption? We're aware of the extra overhead that we incur when using TLS so if there's another method for securing authentication that doesn't use encryption then I'd love to hear it. After all, what are the chances of somebody actually sniffing traffic between one of our devices and a mobile network, and then using the device's identity to send malicious/fake coordinates?

Improve this question
17
  • TLS has everything you need, simply use preshared and hardcoded keys, so that only your devices with the correct key loaded can communicate with the server. This provides authenticity and confidentiality both ways.
    – Jeff Meden
    Apr 25, 2016 at 15:27
  • 1
    "we're not using HTTP due to overhead....We use TLS" - LOL
    – symcbean
    Apr 25, 2016 at 16:07
  • 1
    @jskidd3: the overhead of TLS is actually with every connection setup (more for new session, less for session resume) and a little bit with each data transfer (SSL frames). But if you have a long running TCP connection the overhead is less then lots of HTTP requests.
    – Steffen Ullrich
    Apr 25, 2016 at 17:45
  • 3
    Where is the hacker? If the hacker can hack the device itself then no TLS or authentication will help. If the hacker is emulating a device you need some authentication credentials which can not be guessed (like a client certificate). If the hacker is between the device and the server than (proper) TLS already helps.
    – Steffen Ullrich
    Apr 25, 2016 at 17:48
  • 1
    While that may work, you are best off using actual client side certificates. This is expressly what they were built for.
    – Daisetsu
    Apr 25, 2016 at 18:43

1 Answer 1

Reset to default
2
+50

Universally Unique ID v 4 with device pre registration sounds about right for this sort of application. When a device is in the factory you flash it's firmware with a UUID in it. Then you register that UUID with the DB. If the UUID exists, you generate and flash a new one.

This should be exactly what you want because now if someone grabs a device, they have NO IDEA what other devices have ever been created or how to impersonate that device without making as many guesses as there are atoms in the universe. Better yet you can encrypt this UUID in some sort of permanent user side cookie(Like JWT) that gets sent over and can only be decoded on the server and never needs to be modified by the client.

Now the best a person who stole one can do is to impersonate that device... and the question then becomes to what end? You've already stated if that happens you no longer care.

Device pre-registration is kind of similar to private client keys and serves almost the same role. They're just easier to implement since you don't have to run an extra check in SSL. You just have to decode the cookie that gets sent and never changed and verify it as the device in a data-store somewhere. Better yet you could even have a way to update the value of this cookie in OTA updates to change it every so often with some sort of garbage data that doesn't change the UUID.

And if you're worried about overhead, this can be done with a script that generates the UUID, check if it's in the database, regenerates if need be or stores, then generates the cookie, and finally modifies the firmware and flashes the value into the permanent cookie space. Then it just becomes a push button operation.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .