0
$\begingroup$

I'm working on a very simple and small embedded device. I don't have access to any signing hardware. I would like to have some basic authentication in place to be able to identify a user when a BLE connection is made. My device does have access to a true random number generator as well as a globally unique 32bit value that we can consider "secret". Where only the embedded device and a trusted actor have access to it.

My proposed solution is to have authentication be a two step process.

The first step is for the device wishing to authenticate to ask the embedded device for a random 32bit value. The embedded device will then store this value in RAM.

The second step is for the device wishing to authenticate to hash the random value with the 32bit globally unique value and present that to the embedded device.

The embedded device will then do the same hash of its globally unique value combined with the random number it generated. If it matches, the device can consider this connection authenticated. If it doesn't, it will throw out the random value stored in ram, and disallow any further authentication attempts during this BLE connection.

While I know this isn't ideal, what are the weaknesses with an approach like this?

Improve this question
$\endgroup$

1 Answer 1

Reset to default
1
$\begingroup$

While I know this isn't ideal, what are the weaknesses with an approach like this?

The most obvious issue is that the 'globally unique' secret is too small.

If the adversary listens into a single valid exchange, and get the random value and the hash, he can then do an off-line brute force on the globally unique secret, hashing both the random value (which he knows) and the candidate globally unique secret, and if he gets the known hash, he gets a likely candidate.

If his PC can perform 1 million hashes per second (which would depend on the hash function and the PC being used - it's likely will be a bit faster), then he can check all possible values (and thus recover the globally unique secret) in less than an hour.

Hence, it would appear to be important to increase the length of this globally unique secret (or switch to some sort of PAKE protocol, which would be far more expensive).

And, while we're here, you'd likely also want to increase the length of the random value in the first step. While this isn't as critical, with 32 bits, it is still possible that an adversary might happen to see a random value that he's seen before (and if so, he can get it, at least at that attempt)

Improve this answer
$\endgroup$
1
  • $\begingroup$ Ohh, the offline brute force is a great point I hadn't thought of. We do have some other data that we can include that would bring this up to 64bits. That seems like it could render the bruteforce method much less effective? $\endgroup$ Commented Mar 5 at 15:43

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.