Securing an "open" web service without HTTPS or private shared key

Question

I am producing a web service which will allow any third party "device" to communicate with it. Each device has a reasonably unusual string to identify itself and uses the web service to store data against this id. However, this allows someone who wishes to game the service to scan through and guess device ids and store malicious data against them.

The device itself using this web service is relatively "dumb" and doesn't offer a suitable interface for data entry, so a password or any form of entry on the client is not available.

As this web service is open for anyone who wishes to produce a device of this nature to use, I can't increase security with the use a private key as this would be publicly defined in a specification. Also due to the simplistic nature of the device and it's IP/HTTP stack, HTTPS is unsuitable for this implementation.

To the best of my knowledge I can't see a way of using a privately shared key in this operation. To this extent, I believe it be impossible to secure a system of this nature, but I am wondering if some other methods which I've yet to find may help me secure this system somewhat?

Answer 1

You could try some simple challenge-response system, where the server sends a random string of bytes to the device. The device uses some known ID (ideally not the public one) and some hash like algorithm to produce a response.

This will only protect you from people without access to your devices, though.

Answer 2

Is there a reason you can't use a public/private key pair?

You could publish the server's public key with the specification, and require each device to generate a random public/private key pair for itself. The device could encrypt its public key with the server's public key and send it to the server. The server could use its private key to decrypt the device's public key, and then assume that nobody else could decrypt any message that the server encrypts using that public key. The server therefore registers that public key as the device's ID.

If you set up some kind of session, the server can retain the device's public key associated with that session. If not, some defined portion of any message sent from the device to the server must include the device's public key encrypted this way, so that the server can know which device sent the message.

Any message sent to the server will be encrypted with both the client's private key (so the server knows this device sent it) and the server's public key (so only the server can read it). Messages sent to the device will be encrypted with the server's private key (so the client knows the server sent it) and the client's public key (so only the client can read it). Only you know your private key, and only they know their private key, so everything's secure as long as you (and they) use good seeding and encryption algorithms.

Does that make sense?

Answer 3

If "guessing" device IDs is your only concern, make the device IDs unguessable? For instance, use the result of HMAC-SHA256 with a vendor-private key and serial number as the payload. Not even you would need a copy of the vendor's key.

That wouldn't be terribly useful though, as the device's network connection is probably sniffable thus its ID could be trivially captured over the wire. A secret key element must be present on the device, therefore. But this is where I get slightly confused - your concern over using a shared private key seems to be logistical, rather than whether the device can actually support it (implying that it does have some crypto) - yet you can't use HTTPS? What kind of limitations does the device have (memory/CPU/storage)?

Answer 4

Two things come to mind.

First, use a non-guessable device id. Something as simple as a base64 encoded guid would work.

Second you should require that the data being passed to your web service is encrypted using a public key. Your private key would then be required to decrypt the data.

This would ensure that even if they have a listener watching the data come across, they wouldn't be able to grab a different device id. Also, with a non-guessable ID they wouldn't be able to affect other device accounts.