💬 Security & Signing

sineverba

@pepson Don't need all copy and paste, enough link :).

Btw, before move to Home Assistant, where is the output of debug of MySensors?

sudo mysgw -d

Of course, you need before stop service.

Resetting the node, what you get in debug?

When ALL ok, move to HomeAssistant.

And remember, after check that debug is ok...

sudo make install && sudo systemctl enable mysgw.service && sudo systemctl start mysgw.service

pepson

In my first time I use only serial number gateway in flag whitelistening and also not working.

sineverba

@pepson Last time. Please.
REMOVE
WHITELISTING
FROM
YOUR
SKETCH

Clear EEPROM and paste here output of debug. No other.

pepson

@sineverba
OK wait for info

pepson

@pepson

Ok i removed Whitelisting and switch is show in Hoem Assistant and works.

pi@raspberrypi:~/MySensors $ sudo ./bin/mysgw -d
mysgw: Starting gateway...
mysgw: Protocol version - 2.2.0
mysgw: MCO:BGN:INIT GW,CP=RPNGLS--,VER=2.2.0
mysgw: SGN:PER:OK
mysgw: SGN:INI:BND OK
mysgw: TSF:LRT:OK
mysgw: TSM:INIT
mysgw: TSF:WUR:MS=0
mysgw: TSM:INIT:TSP OK
mysgw: TSM:INIT:GW MODE
mysgw: TSM:READY:ID=0,PAR=0,DIS=0
mysgw: MCO:REG:NOT NEEDED
mysgw: Listening for connections on 0.0.0.0:5003
mysgw: MCO:BGN:STP
mysgw: MCO:BGN:INIT OK,TSP=1
mysgw: TSF:MSG:READ,3-3-0,s=255,c=3,t=1,pt=0,l=0,sg=0:
mysgw: !SGN:VER:NSG
mysgw: !TSF:MSG:SIGN VERIFY FAIL
mysgw: TSF:MSG:READ,33-33-0,s=255,c=3,t=16,pt=0,l=0,sg=1:
mysgw: SGN:SKP:MSG CMD=3,TYPE=16
mysgw: SGN:SKP:MSG CMD=3,TYPE=17
mysgw: TSF:MSG:SEND,0-0-33-33,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
mysgw: SGN:NCE:XMT,TO=0
mysgw: TSF:MSG:READ,33-33-0,s=255,c=3,t=1,pt=0,l=0,sg=1:
mysgw: SGN:BND:NONCE=44E4127024F4EB1003DCBF3701D8469E4664CC454E2A20A257AAAAAAAAAAAAAA
mysgw: SGN:BND:HMAC=E1EE2D4046FEF0AEC323AA737A8367A2F290CCEFB7A4663448AD0B155FFD5A74
mysgw: SGN:VER:OK
mysgw: TSF:MSG:READ,33-33-0,s=1,c=3,t=16,pt=0,l=0,sg=1:
mysgw: SGN:SKP:MSG CMD=3,TYPE=16
mysgw: SGN:SKP:MSG CMD=3,TYPE=17
mysgw: TSF:MSG:SEND,0-0-33-33,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
mysgw: SGN:NCE:XMT,TO=0
mysgw: TSF:MSG:READ,33-33-0,s=1,c=1,t=2,pt=1,l=1,sg=1:0
mysgw: SGN:BND:NONCE=4AD7D9430FA96BBD0B18D4F57480F009BE31C6F3821F182766AAAAAAAAAAAAAA
mysgw: SGN:BND:HMAC=3AADB41A42B91C0B2137BE2C2C76F57E3ADB7082F3669DECCA85B993C955D36E
mysgw: SGN:VER:OK
mysgw: TSF:MSG:READ,33-33-0,s=1,c=3,t=16,pt=0,l=0,sg=1:
mysgw: SGN:SKP:MSG CMD=3,TYPE=16
mysgw: SGN:SKP:MSG CMD=3,TYPE=17
mysgw: TSF:MSG:SEND,0-0-33-33,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
mysgw: SGN:NCE:XMT,TO=0
mysgw: TSF:MSG:READ,33-33-0,s=1,c=1,t=2,pt=1,l=1,sg=1:1
mysgw: SGN:BND:NONCE=B272E537F5C6DAF21A0C5042078EFCFD3A02B5C61F698792AAAAAAAAAAAAAAAA
mysgw: SGN:BND:HMAC=5AF82BD16724069A436E0735229D32F532108A45407EF0DE7CABDADA1F7E39A0
mysgw: SGN:VER:OK
mysgw: TSF:MSG:READ,3-3-0,s=255,c=3,t=1,pt=0,l=0,sg=0:
mysgw: !SGN:VER:NSG
mysgw: !TSF:MSG:SIGN VERIFY FAIL
mysgw: TSF:MSG:READ,33-33-0,s=1,c=3,t=16,pt=0,l=0,sg=1:
mysgw: SGN:SKP:MSG CMD=3,TYPE=16
mysgw: SGN:SKP:MSG CMD=3,TYPE=17
mysgw: TSF:MSG:SEND,0-0-33-33,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
mysgw: SGN:NCE:XMT,TO=0
mysgw: TSF:MSG:READ,33-33-0,s=1,c=1,t=2,pt=1,l=1,sg=1:0
mysgw: SGN:BND:NONCE=61F78D66E675349B8A63B1370E81D2D1AB44BC1D0BB1F988D6AAAAAAAAAAAAAA
mysgw: SGN:BND:HMAC=04EEE2B60E0C71CC092E13C68C07F3088D66F264A826C23426053C17C2353DED
mysgw: SGN:VER:OK
mysgw: TSF:MSG:READ,33-33-0,s=1,c=3,t=16,pt=0,l=0,sg=1:
mysgw: SGN:SKP:MSG CMD=3,TYPE=16
mysgw: SGN:SKP:MSG CMD=3,TYPE=17
mysgw: TSF:MSG:SEND,0-0-33-33,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
mysgw: SGN:NCE:XMT,TO=0
mysgw: TSF:MSG:READ,33-33-0,s=1,c=1,t=2,pt=1,l=1,sg=1:1
mysgw: SGN:BND:NONCE=627FAEEEFFFD6E55F371C07A54F785FDA3EE52EBD4092E0CE9AAAAAAAAAAAAAA
mysgw: SGN:BND:HMAC=65503227CDB04C1A2DCB03D0E5BAFD35A4EBA956E8EBA917B2DF40FB09520092
mysgw: SGN:VER:OK
mysgw: TSF:MSG:READ,33-33-0,s=1,c=1,t=2,pt=1,l=1,sg=1:1
mysgw: !SGN:BND:VER ONGOING
mysgw: !SGN:VER:FAIL
mysgw: !TSF:MSG:SIGN VERIFY FAIL
mysgw: TSF:MSG:READ,33-33-0,s=255,c=3,t=16,pt=0,l=0,sg=1:
mysgw: SGN:SKP:MSG CMD=3,TYPE=16
mysgw: SGN:SKP:MSG CMD=3,TYPE=17
mysgw: TSF:MSG:SEND,0-0-33-33,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
mysgw: SGN:NCE:XMT,TO=0
mysgw: TSF:MSG:READ,33-33-0,s=255,c=3,t=1,pt=0,l=0,sg=1:
mysgw: SGN:BND:NONCE=32CE07784E14ED2B6D455C2C5C4D83E025185970838C0B743AAAAAAAAAAAAAAA
mysgw: SGN:BND:HMAC=F04885315D93DB7FC95F3B190D68009055495ECEE698E0ADF6F50292157A8927
mysgw: SGN:VER:OK
mysgw: TSF:MSG:READ,33-33-0,s=1,c=3,t=16,pt=0,l=0,sg=1:
mysgw: SGN:SKP:MSG CMD=3,TYPE=16
mysgw: SGN:SKP:MSG CMD=3,TYPE=17
mysgw: TSF:MSG:SEND,0-0-33-33,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
mysgw: SGN:NCE:XMT,TO=0
mysgw: TSF:MSG:READ,33-33-0,s=1,c=1,t=2,pt=1,l=1,sg=1:0
mysgw: SGN:BND:NONCE=3DAAB19C10BB3CB8A08CDAACED4BFB385F1EB22AA9F926F940AAAAAAAAAAAAAA
mysgw: SGN:BND:HMAC=392AB4EAFDE59AC0CC9BE6EE667FC33A69A33E86AD5CB3EC49C6C114722941F5
mysgw: SGN:VER:OK
mysgw: TSF:MSG:READ,33-33-0,s=1,c=3,t=16,pt=0,l=0,sg=1:
mysgw: SGN:SKP:MSG CMD=3,TYPE=16
mysgw: SGN:SKP:MSG CMD=3,TYPE=17
mysgw: TSF:MSG:SEND,0-0-33-33,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
mysgw: SGN:NCE:XMT,TO=0
mysgw: TSF:MSG:READ,33-33-0,s=1,c=1,t=2,pt=1,l=1,sg=1:1
mysgw: SGN:BND:NONCE=CF101801DA5324E2F66C3B9350E8FC2BCCBD337E3F588EBE2FAAAAAAAAAAAAAA
mysgw: SGN:BND:HMAC=53795E79C8FE9D599D1A88363F7E2BA607ADBB265E4E99356886B65C3D0A06D0
mysgw: SGN:VER:OK
mysgw: TSF:MSG:READ,3-3-0,s=255,c=3,t=1,pt=0,l=0,sg=0:
mysgw: !SGN:VER:NSG
mysgw: !TSF:MSG:SIGN VERIFY FAIL

Anticimex

@pepson your gw is configured to require signing from all nodes.
Your node 33 is set up to use signing. Your node 3 is not. Hence messages from node 3 will be rejected by the GW.
Either set up all nodes to use signing or set up weak security on the GW to only require signing from nodes that require it in turn.
This is documented behaviour. Please read the documentation. That is what it is for.

pepson

But still I don't know how use white listening...?

Anticimex

@pepson I suggest you avoid it. It require good tracking of all serials in your network and is part of the more advanced security mechanisms. And I suspect you will get issues when you add new nodes to your network as you cannot get it to work with just two nodes (you still have not enabled it on your gw). So just avoid whitelisting all together.

pepson

@anticimex
OK but how I can get serial from my Node on Arduino Pro Mini?

And when I want use chip AtSHA204A what I must change on my GW and on Node?
Can I build GW on Rpi with this chip AtSHA204A?

Anticimex

@pepson Please. Read. The. Documentation.
And no, atsha204a is not supported on rPi. Nor does it need to be.

pepson

@anticimex
But still I don't know how read serial number from Node on Arduino Mini Pro when I want use White Listening...

Anticimex

@pepson have you read the documentation? Do you understand the concept of personalization? Where have you found information on from where the serial number is obtained?
I will only say this once more: don't use whitelisting unless you know these things. Serial is only used for whitelisting. Don't use something you do not understand.
All your questions so far can be answered by citing the documentation so please read it!

joaoabs

I have my network with NRF24+'s with HW signing. Now, due to performance limitations of the NRF's I'll move to RFM69's which supports encryption.
How can I set encryption in Mysensors? Is it already available? Can I have both signing and Encryption?

Anticimex

@joaoabs yes, it's all in the documentation ;)
Let me know if you can't find it. Links are in the readme.md in git and in github.

Damian

Hi,
I've been a while on MySensors forum, most time as a reader. Read the docs about signing and have a couple of questions - possibly stupid as I might not understand well the docs.

I'd like to ask if the flags --my-signing-weak_security and --my-signing-request-signatures (yes I have RPi gw) are complementary or separate: if I define both, do I get a "weak security" feature or the "request security" is on top of that and only signed messages would be accepted? Or maybe I need to define one of them only depending on security level I want to achieve?
Whitelisting - many things were said here, I am not planning to use it for now nor anytime for gateway on nodes as I do not find it necessary as gw is not supposed to be compromised, but did a quick test following the @sineverba tutorial and it failed indeed as pepson said. The serial which I provided in sketch in #define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {myserial}}} was the one generated by mysgq --gen-soft-serial-key (and then applied by --set-soft-serial-key ofc) - is that correct? I also tried to replace GATEWAY_ADDRESS with 0 and no success. Maybe there are some other steps that I should take (@Anticimex said something like "But I don't see your gw flags specifying it" which I dont understand in this context)
Is the encryption possible to be enabled only by compiling the gw with --my-rf24-encryption-enabled (for my nrf24) and personalizing gw and node with the same AES key obtained in this docs and by defining the proper flags in sketches on all nodes or is this procedure is more complicated? If this is not the subject for the scope of this thread please tell me I will search more.

Thank you for understanding my possibly dumb questions :) I try my best but I am a beginner iot, but work in IT so not a total newbe in programming or technologies.

Anticimex

@damian There are no stupid questions on complex matters. Security is a complex matter (unfortunately).

The weak security flag allows a node to inform a GW that it no longer require signing. Thus, an attacker might "take over" a node and replace it with a non-secure one possibly without you noticing.
The request signature flag lets a node (or GW) informe a GW (or node) that it require signatures. That allows the other side to understand that it has to sign messages sent to the destination. It is therefore not to be confused with "weak security". It is more a "enable security".
Writing #define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {myserial}}} in a node, tells the node to requrie the GW to salt the signatures with it's serial (that should match the serial you entered in the node).
If the messages fail to verify, it suggests that the GW either has not realized it is expected to salt the signatures, or it uses the wrong serial to do it. Unfortunately I do not have a rPi setup to check this, so any help in troubleshooting that would be appreciated.
Yes, just make sure to also enable encryption on the node. Also, do notice that ALL nodes on the same network needs to use encryption with the same key.

I hope this clarifies the things a bit :)

Damian

@anticimex thanks for the answer.

I understand the idea. However, I think I might asked not clear enough. I would like to know how the mysgw daemon would work after the compilation depending on the flags I provide.
I understand that when I compile my gw with only --my-signing-request-signatures it will require all nodes in the network to sign messages. But if I want only some of them to sign messages and some not, do I have to compile the gw with both flags: --my-signing-request-signatures AND --my-signing-weak_security or only: --my-signing-weak_security ?
I think it might be an RPi issue, because the idea and setup seems to be correct. I'll try one day to test it in node-to-node communication or some test serial gw on Arduino. This is not so important to me as the signing itself works fine, just was curious.
clear, hope it work. In the meantime I found: https://forum.mysensors.org/topic/2005/software-aes-encryption-for-nrf24 which looks worth testing as well. TL;DR carefully yet.

Anticimex

@damian

You need to compile with --my-signing-request-signatures AND --my-signing-weak_security. See https://www.mysensors.org/apidocs/group__SigningSettingGrpPub.html#gaf44407e0f498eca7069adf5e59ffe052
RF24 encryption is implemented in SW and currently available (with static IV). See https://www.mysensors.org/apidocs/group__EncryptionSettingGrpPub.html

Damian

@anticimex Thank you so much for clarification I owe you a beer ;)

So another question for future considerations - is it possible to read eeprom to get the keys? I suppose the answer is yes as the whitelisting feature is introduced, but is it a hard task or keys could be fetched by a simple script reading eeprom?

Anticimex

@damian Reading EEPROM is quite trivial for a determined attacker, hence I discourage SW based security as it does not have the means of storing secrets securely on devices as the atmega328p.
HW based signing is available using the atsha204a in which case signing keys are protected. Encryption keys are not unfortunately as all encryption is currently SW based (or HW accelerated but still SW dependent).
"Security V3" will resolve this, but I unfortunately have no ETA.

You are welcome! :beers:

💬 Security & Signing

20

11.7k

11.2k

113.1k