How do i use a guessable ID for authentication

Question

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.

Thoughts?

Answer 1

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.

Answer 2

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.