Hi,
I noticed that I’m sometimes not receiving status updates from e.g. my dimmer (qubino mini dimmer, included with security).
I was looking at the logs and noticed, that there is this message “NONCE ID invalid!” at the same time.
What does this message mean and what can I do against this from being happening (using OH 2.5 stable)?
It means that the Nonce that the binding holds is not valid compared to the Nonce with which the remote device sent the encrypted frame. I don’t think there’s a lot that can be done, but without a log it’s hard to know exactly what’s happening. My guess is potentially the Nonce message is corrupted, or possibly the updated Nonce in this secure transaction was not received so the Nonces are out of sync. It’s hard to say much more without the logs, but the logs won’t really answer the question of how to solve it.
Nonce? uhh in Britain this is a colloquial term for a particular kind of sex offender.
Now I’ve learnt it has a ‘proper’ meaning too, as a one-time word or key. Things you pick up through openHAB, part 209 
1 Like
And Chris is in the UK too. 
I’ve only ever knew the “proper” meaning. It comes up a lot in crypto (e.g. Diffie-Hellman key exchange). It’s useful to avoid playback attacks. I’ve used something new today. 
And the rest of us learned the improper meaning. 
1 Like
@chris: Did you have a change to look at the logs?
Today I had this issue also multiple times. It looks like the old nonce is used multiple times. However, in the last invalid message the nonce (94) is not even in the logs.
Maybe I got a clue, why this is happening.
I believe, that we have some kind of race condition here.
08:31:39.392 Device is asking for new nonce.
08:31:39.404 Controller is sending nonce 18.
08:31:39.705 Device uses nonce 18.
08:31:40.392 Device is asking for new nonce.
08:31:40.402 Controller is sending nonce 37
08:31:40.481 I believe that the new nonce (37) is not being received by the device, so it’s still using the old one (18)
Problem: Controller doesn’t accept the old nonce anymore. -> Data lost.
Could somebody confirm this? What can be done against this issue (besides not using encryption)?
Hi there,
another issue I found today (does happen only sometimes).
The invalid nonce message contains unknown nonces - where are they from?
Logfile:
nonce_invalid_20200204.txt (20.5 KB)
What version of the binding are you using? Is it recent?
I’m using Version: 2.5.2.202002010518
The issue here is duplicate frames. The same frame is received twice and that consumes the nonce. When the second packet is received, you get the error. Probably I should add more duplicate packet checks to resolve this.
I’ll try and find some time to look at this over the next week or so.
Thanks for looking at the issue.
Could you tell me, where in the logs you found the duplicate frame? I’m still trying to fully understand all the log entries. Thank you.
Yes, looking further it’s not a duplicate frame - it just looks like the device sends two frames using the same nonce. I’m not sure why that is, but it seems to be a device problem as far as I can see. The binding sends a second nonce (0x8A) byte the device sends another frame using the same 202 nonce.
Just to note that some of your confusion here might be due to the fact that the logging is confusing - it says the nonce is -118, which is correct, but it’s printed as a signed number since the binding uses bytes internally. -118 is really 138 in unsigned which is how the logger presents it.
defective device?
It’s unlikely it’s defective as such, but it depends on your definition of defective. It looks to me like a software bug as the device should not use the nonce twice, and that seems to be what it’s doing unless I’m missing something.
signed and unsigned. That was the point I missed. Thanks.
Could it be also some kind of race condition (see my post 8 days ago) or has a new message always has to use a new nonce?
It doesn’t look like it to me. Firstly, if it’s a race condition, why is the device clearly using the same nonce for two commands? That should never happen. If the device has used the nonce, it should not send another request until it receives a new nonce.
It then receives the new nonce - the command is acked by the device, and then 80ms later the binding receives the new command using the original nonce.
Yes - it should not use a one time number twice (otherwise it would not be a nonce - right?)
A nonce stands for Number-Once. If the number could be used twice, then it would be a NTwice (which doesn’t have the same ring to it .