Security token with .NETMF

I have tried numerous methods to create some kind of security token that I can send from my IoT device to an ASP.NET Web Api so that I can authorize the request before allowing the server side process to be executed.

Are there any models for this using .NETMF?

The problem I have is getting something unique and random that both the device and server side can understand. I already tried a MD5 hash (see the end of the below example URL), but if that URL is captured, simply executing if from the browser or re-running it, the token gets validated.

http://*****.azurewebsites.net/api/TCdV2/0001/2/4D0055A5E5/34-11-82161242827b703e6acf9c726942a1e4

I have also tried some algorithms with time, but this is too dependent on the device having a good clock and being synchronized with the server, even if that happens, what if the time changes at exactly the time the web request is made to the server…or there is no time on the device at all…

Any tips or examples would be appreciated, thanks.

I have tended toward using a challenge-response pattern to mitigate replay attacks (which is what you are describing in your browser replay).

To do a challenge-response, the dialog goes like this: (C is client, S is server in the cloud; resource is the url you want to access, and “shared secret” is a bit string known only to the server and the client and never sent over the wire.

C -> S : Send me the challenge please
S -> C : The challenge is : (some random bit stream - say a 16-byte character string of random chars)
C: Computes a hash of challenge + resource + deviceid + shared secret
C -> S : sends the hash, resource and device id to the server as a request (GET request for instance)
S : computes H(challenge + resource + deviceid + shared secret)
S -> C : if the hash matches the hash sent by the client, grant access, else 403 response

[Edit : you only need to get the challenge once - re-use it for the rest of the conversation. It’s best if it has some sort of expiry though (see next post for solution to time windowing problem). You can also include an integer that goes up by one for each interaction with each interaction C->S or S->C, which hardens the conversation integrity a bit more.]

There are lots of variations on this, most commonly including a timestamp, but you said you wanted to avoid that.

The idea is to validate against something known only to valid participants in the discussion. That’s the shared secret. There are lots of ways to ratchet up the security on this, but this is a good starting point for simple mutual authentication.

By the way, you can mitigate the time accuracy problem by rounding the time to the nearest minute and trying hashes for values +/- five minutes of the current GMT time. That means that the time window can be 10 minutes wide, but replay attacks outside that window will not work.

Do note that many challenge-response systems require both the client and the server to have access to the unencrypted shared secret (i.e. the “password”). This could present a problem. If it does, make sure you choose a system that does not have this property. SCRAM ([url]https://tools.ietf.org/html/rfc5802[/url]) is one such system.

1 Like

Excellent point, and a search even turned up a C# implementation : Salted Challenge Response Authentication Mechanism (SCRAM) SHA-1 - CodeProject

I am sure there are others out there. As long as you have SHA-1 available, this looks NETMF-friendly.