Hashed Token

Nuki APIs Bridge HTTP-API
1

I am currently trying to change the connection to the NUKI Bridge API from token to hashed token.

All calls with TOKEN work.

Unfortunately when I use the hashed token I always get a response with the status code: 401.

I have a function to generate the sha key which generates the same key with the parameters from the API description.

sha256(“2019-03-05T01:06:53Z,4711,123456”) = f52eb5ce382e356c4239f8fb4d0a87402bb95b7b3124f0762b806ad7d0d01cb6

Therefore I exclude an error in the function to generate the SHA key.

I have the assumption that it can be the TimeStamp.

I tried the following values, but no success.

timeStamp “2022-03-14T17:11:21Z” the local time is UTC: Mon, 14 Mar 2022 18:11:21 GMT".

timeStamp “2022-03-14T18:11:21Z” the local time is UTC: Mon, 14 Mar 2022 18:11:21 GMT"

The second try doesn’t make sense from my point of view either, it’s not ZULU time (UTC +0).

This is how the URL for hashed tokens looks like:
http://192.168.178.107:8080/unlock?nukiid=xxxx&deviceType=4&ts=2022-03-14T17:11:21Z&rnr=16&hash=xyz………

And this is the URL for tokens:
http://192.168.178.107:8080/unlock?nukiid=xxxx&deviceType=4&token=xyz

Maybe it is something else.

Who can help me here?

Ralf

My hardware
Nuki Smart Lock 3 Firmware Version 3.1.10
Nuki BridgeFirmware Version 2.12.0

2

The used time format is mentioned in the ISO 8601 standard.

You can check the current time of your bridge by using the /info command:

…“currentTime”: “2022-03-14T20:43:24+00:00” …

Which is

2022-03-14T20:43:24Z

4

Shared token still does not work.

Something else is not clear to me with the TimeStamp.

In the API documentation, regarding the problems with out-of-sync times, it is recommended to check the current time of the bridge.

The property dateUpdate deviates significantly from UTC +0 time for me as in the example below.

If the TimeStamp from the URL is compared to the dateUpdate value for equality, the result will never be correct.

A hashed token will only be valid with a sufficiently current timestamp and can not be reused, to prevent replay attacks. So making two calls with the exact same timestamp will only work with different random numbers.
To debug problems with non synchronous times you can check the current time on the bridge via bridge discovery

The result from https://api.nuki.io/discover/bridges call at 11:52 UTC +1

{"bridges":[{"bridgeId":xxx,"ip":"xxx","port":8080,"dateUpdated":"2022-03-15T09:42:28Z"}],"errorCode":0}

I would be interested to know who is successfully using the shared token and how this was implemented. Maybe the error is sitting in front of the screen.

5

Ok the error is sitting in front of the screen.

I entered the parameters for the hash value in the wrong order.

Dear NUKI team, please enter the parameters in the correct order in the Bridge API documentation in chapter 3.21. Parameters.

The sequence TimeStamp, Random number and Plain Token would be correct.

sha256=(timeStamp, random, token)

Das Problem ist somit gelöst.

6

You mean in the table? Because in the example there the order is correct.

7

Guten Tag Herr Lendl,

ich hoffe das es OK ist, wenn ich Ihnen auf Deutsch schreibe.

Im Kapitel 3.2.1 Parameters finde ich die Darstellung verwirrend.

In der Tabelle werden 4 Parameter aufgelistet, die jedoch für zwei verschiedene Authentifizierungen sind.

Der erste und einzige Parameter Plain Token gehört zum http request bei Authentifizierung mit unverschlüsseltem Token. Die letzten drei Parameter gehören zum http request bei Authentifizierung mit Hash Wert.

Der Hash wird aus den Parametern Tiimestamp, Random number und Plain Token gebildet. Genau das ist der Punkt, der hinsichtlich der vier Parameter in der Tabelle schnell übersehen wird. Der kleine Hinweis in der Spalte Value mit:

sha256(“ts,mr,token”)

fällt nicht gut auf. Daher kann es schnell passieren, dass man die Reihenfolge für den Hash Wert mit sha256("token,ts,mr) angibt was zu einem http response 401 führt.

Für mich wäre es leichter gewesen, wenn die zwei Authentifizierungsarten getrennt dokumentiert wären und vielleicht auch für andere Anwender.

Mit den besten Wünschen