This question doesn't fit well in many categories but hopefully someone's run into it before.

I'm developing a web api that will interact with a physical device. Each new physical device has it's own unique ID, but those IDs are guessable (essentially they are sequential as they come off the assembly line.)

When the device is plugged into a computer via USB we will launch a client app which the user will have installed and sync data from the device to the API. We can't rely on a 1:1 relationship of computers to devices, a user might sync on multiple machines or multiple users might sync on the same machine.

We want to authenticate to the API using nothing more than the device ID, but i don't want someone to be able to spoof another users ID by calling my API directly with a different device ID.

I'm wondering what I could do to the device ID that could enable me to securely use it for authentication.

My first thought was to encrypt the ID with a private key and then share the private key with the client software. The client software could then encrypt the device id before calling the API and transmit that encrypted value. The api compares it against a stored value and your good, but I'm worried that it will be difficult to secure the private key when it has to be stored on the client computer.


  • 1
    What specifically are you trying to authenticate? The device its self? That the user has physical access to the device? – David Wolever Jun 7 '12 at 3:00
  • I'm pulling down data about the user's use of that device and only want to allow someone who has the physical device to pull down the owner's information. It's possible someone could get access to the device who isn't the owner but the use case isn't THAT private that I'm worried about that. – JoshReedSchramm Jun 8 '12 at 1:01

Given your premises, the problem cannot be solved in the form you want it to. You have said that (1) the device ID is guessable, (2) the device ID is the only secret that you want to allow us to use, (3) you want to authenticate using the device ID. Well, that's not solvable. If I can guess Alice's device ID, then I know all of the secrets necessary to masquerade as Alice, and your system won't be able to distinguish me from Alice.

You mention something about encrypting with a cryptographic key, but if you had a secure way to share the cryptographic key with just Alice (in a way that prevents me from learning it), you could simply use that key for authentication -- you wouldn't need to use the device ID. However, this is ruled out by your rules that no other secret is permitted. So I don't really understand what you are asking or what are the real constraints here.

Why don't you tell us about the application domain and what you're trying to achieve and why you think the device ID is the only thing you can use for authentication. We may be able to come up with some approaches or solutions that haven't occurred to you.

For instance, here is an approach you could consider. When the device first registers itself with your service, it generates a new, unique public/private keypair, store the private key on the device, and send the public key to your central server. There might be some secure registration procedure where the public key is sent to the central server and registered and associated with Alice's account. In the future, when the user wants to sync on a machine and invoke your central API, the device can set up a secure connection to your central server and authenticate itself using its private key (think client certs and SSL), then send those API calls. The encrypted communication can be routed through the machine/desktop, so that it does not require trust in the machine/desktop. The private key would never leave the device. Please note that this is just an example of a possible approach -- depending upon your requirements, it might or might not meet your requirements. Please don't get too caught up in the details of this particular example. Rather, the point I'm making is that if we are clear on your requirements and constraints, we may be able to come up with some suggestions about the best way to solve your problem, within the constraints you face.

  • "There is no true solution" is kind of what I was expecting actually. Because of an NDA I can't specifically say what the device does but it's a dead simple wearable device that monitors some aspect of the owner's daily activity. The device API itself is readonly unfortunately, so writing the key to the device wouldn't really work, I actually considered that and contacted the manufacturers about it. What we're trying to do is allow the user to plug in the device and have it auto-sync and allow them to update their information, using the device to verify their identity. No un/password prompt. – JoshReedSchramm Jun 8 '12 at 1:04
  • The record of past activity might be able to serve as a secret. Is there a period of time where both (a) the activity over that period is stored on the device (and readable by the user's computer), and (b) the activity over that period is known to the central server? If so, you could have the user's machine prove that it is connected to the device by having it send up the daily activity information for that period (over SSL, sent to your server). – D.W. Jun 8 '12 at 6:03
  • @JoshReedSchramm - The best you can do is hide the fact the only authentication is the device id. Of course this does not change the fact somebody could trick the system if they found out. I suggest you require the device id and perhaps a pass phrase. – Ramhound Jun 8 '12 at 16:16

If your software runs on a computer, on which the user can execute untrusted software (e. g. a standard PC, a rooted smartphone), he will be able to manipulate your software.

You may use anti-debugging techniques, but that just makes it a little bit more difficult for the attacker. There was a very interesting talk called Silver needle in the Skype, which explained how Skype was analyzed, despite its use of anti-debugging techniques.

Signing your software to prevent modifications does not work either: The code that verifies the signature can be modified by replacing the conditional jump. This is a technique that is well understood for decades because cracking copied software works the same way.

You proposed to sign the device-id with a private key inside your software. There are several attack vectors here:

  • An attacker can extract the private key from the software and sign his own value
  • An attacker can use a debugger to change the variable, that stores the device-id after it was read from the device and before it is handed to the subroutine, which does the signing.
  • An attacker can manipulate the device driver or kernel, so that the system call to read the device-id returns another number.
  • ...

TL;DR: Do not trust the client.

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.