💬 Security & Signing
-
-
@Anticimex I read all text and I understand that I have add forth line to all my sensors.:
#define MY_SIGNING_SOFT
#define MY_SIGNING_SOFT_RANDOMSEED_PIN 7
#define MY_SIGNING_REQUEST_SIGNATURES
#define MY_SIGNING_NODE_WHITELISTING {{.nodeId = MOTION_SENSOR_ID,.serial = {0x12,0x34,0x56,0x78,0x90,0x12,0x34,0x56,0x78}}}In my gateway i must use this comand:
./configure --my-gateway=mqtt --my-controller-ip-address=127.0.0.1 --my-mqtt-publish-topic-prefix=mysensors-out --my-mqtt-subscribe-topic-prefix=mysensors-in --my-mqtt-client-id=mygateway1 --my-signing=software --my-signing-debug --my-signing-request-gw-signatures-from-all --my-mqtt-password=PASSWORD --my-mqtt-user=USER- but I do not understand wher I create white list in gateway?
- how create serial for my mensors (eg. {0x12,0x34,0x56,0x78,0x90,0x12,0x34,0x56,0x78})?
- how to check if everything is working?
- how to use HMAC (how to create in my sensor, where save)?
-
@macvictor the raspberry specific things you need to check with @marceloaqno about, the other questions really are all answered in the link I sent.
-
@Anticimex Ok. I read again this text. I have next question..
- I generated SOFT_HMAC_KEY, SOFT_SERIAL, AES_KEY in my gateway, so when I run SecurityPersonalizer.ino i must save this value from gw in MY_SOFT_HMAC_KEY, MY_SOFT_SERIAL, MY_AES_KEY or generate other value and save? Probably AES must by the same.. MY_SOFT_SERIAL is 'serial' in WHITELISTING so i think this must by different in node and gateway, and what with HMAC? I think that the HMAC must be the same..
- I looked for information where save whitelist in gw but i didn't found.. can you help my find solution?
- If I use for example 2 nodes-relays, 2 nodes-temperature and gateway. All relays communicate only with gateway but all are repeater. All node-temperature sensor connect with relay, so in nodes-relay in white list i must add temperature serial and gw serial. In temperature I does't add white list, in gateway I add relay and temperature nodes serial. That is all?
PS. Thank you for you help
-
- Quotes from the documentation (link I sent):
"In case you want to be able to "whitelist" trusted nodes (in order to be able to revoke them in case they are lost) you also need to take note of the serial number of the ATSHA device or the software value stored in EEPROM. This is unique for each device."
"That mean that all nodes in your network share the same PSK" (this goes for both HMAC and AES (if you use encryption)). - There is no difference. You specify your whitelists the same way in both gateway and nodes. Of course you have to have different whitelists but the format and way of storage is identical.
- All signing is end to end. Your nodes communicate with your gateway. It does not matter if they are relayed 50 times on the way to the gateway. Therefore, whitelists in gateway and node use the serial from the other part (gateway or node).
Your relays are also nodes. If you send data explicitly to these nodes, you also need the serial for those (if you want signed communication with them) but your temp sensors and your gateway talk to each other. Signing does not care about relays.
So you do NOT need to add gw and temperature serials to your node-relays just to have your gw and temperature sensors communicate with each other. You do not even have to enable signing in your relays. They are (possibly) just that; relays.
Of course, this mean that you have to have your gw serial in your temperature node whitelist, and vice versa (if you use two way signing).
- Quotes from the documentation (link I sent):
-
Hi Guys,
Long time reader and first time poster.
Now a general disclaimer, I'm only fairly new to the IoT world of home automation sensors and am looking at the crypto side of signing devices as I thought if I'm going to do it, I'm going to do it right from the start with signing and utilizing OTA abilities.I have a quick question regarding the ATSHA204 component. I know that the SenseBender uses a ATSHA204-STUCZ (the Single-Wire interface config) but I can't get these sourced through my normal supplier.
I am able to source ATSHA204A-SSHDA-B though, and was wondering if this would work instead, even though it's an I2C interface config instead. If not, how much work is involved to get it to work?
Thanks Heaps
-
@egadgetjnr hi and welcome to the forum! It will require some work as the current driver only handles single wire interface and the I2C support in the chip has special requirements in the bus for sleep/wake states. I don't know how much work exactly is needed but it will not be insignificant.
Also, what sources have you checked? It should be possible to source the single write variant online without problem.
-
@Anticimex said in
Security & Signing:Also, what sources have you checked? It should be possible to source the single write variant online without problem.
Thanks heaps for your prompt reply!
I've looked at Mouser and Digi-Key and they have a $60 minimum for free postage (I don't want to order 100 for free shipping at this stage obviously as I'm only prototyping) and I can't bring myself to spending $25 on shipping for around $5.00 of modules
.
Which leaves me with my normal supplier of Element14 (formally Farnell) where I get free shipping regardless of order quantity.
but they don't source the Single-Wire ones at all.I was going to put a post over on the OTA Flash forum as well as I'm having issues sourcing the AT25DF512C (it's been discontinued) and was looking at an ATAES132A (Datasheet <here> using an SPI interface) as I accidentally ordered some of them for another project and thought maybe it would be possible to combine both the security signing and OTA flash in the one component (Which is a HUGE assumption as to its use). As mentioned earlier, I'm still fairly new to the engineering side of hardware so I may be way off the mark.
-
@egadgetjnr where dit u come from?
-
@egadgetjnr Ok, well, if you are up to it, feel free to make a PR with I2C support. I do not have the bandwidth to implement that myself I am afraid, and I don't feel the gains are worth the efforts. I2C will put constraints on which pins to use, and of course it would also require two pins and not one.
But I happily review any pull requests on the topic. If we get the support, it is just a bonusRegarding flash, it is not crucial that you get the exact same part (or even the same supplier). The important thing is that the interface is the same and that they share the same JEDEC identifier.
-
I had exactly the same issue. This UK eBay store sells them per 5. Not sure what they'll ask for sending them across the ocean.
I got them from here (4 days from UK to NL). Got one up in my gateway and that works with a soft signing node. Should be good.
-
Just to be sure: SOFT_HMAC_KEY, SOFT_SERIAL is used for signing, AES_KEY is used for encryption. SOFT_HMAC_KEY, AES_KEY should be the same across all network nodes, SOFT_SERIAL should be different for every node?
-
@bilbolodz this is quite clearly stated in the documentation, but in short yes. But AES and HMAC key should not be the same, as the encryption is not using initialization vectors so the key can be derived from analyzing the encrypted messages by someone with the adequate knowledge.
-
I'm trying to start play with ATSHA204A signing. I've ATSHA204A-SSHCZ-T chip (8-lead SOIC single wire). I've connected chip pins: 4 - GND, 8 - VCC (5v), 5 - A3, I've added 100nF between 4 and 8 and 4K7 resistor between 5 and 8. I've loaded "near clear" SecurityPersonalizer sketch (only added #define MY_SIGNING_ATSHA204_PIN A3 #define MY_SIGNING_ATSHA204) but I've got:
Personalization sketch for MySensors usage.
Failed to wake device. Response: E7
Halting!any ideas?
-
@bilbolodz hm, no. I have not tested on a 8-lead device. Should not be a difference but I can neither deny nor confirm. My best suggestion would be to have a look with an oscilloscope on the wire to confirm that the signal quality is good.
-
Is SIGNING a RFM69_ENABLE_ENCRYPTION replacement? If so is it a better or worse solution? Maybe RFM69_ENABLE_ENCRYPTION is enough?
-
@melwinek encryption and signing have very different purpose.
Signing prevents other people from sending messages to control your nodes. Without signing, anyone with the right skill or software can take control of your nodes.
Encryption tries to hide the contents of the messages between your nodes. That does not prevent people from taking control of your nodes.
-
@melwinek signing and encryption are two completely different things. And they can be enabled at the same time if so desired. Signing provides authentication and encryption provides obscurity.
-
@Anticimex, @mfalkvidd But with the use of encryption so easily no one will take control, must break the code.
So it is best to simultaneously encrypt (eg RFID tag serial number when opening the gate) and sign (eg gate open message)?
-
@melwinek what prevents anyone from copying your encrypted message and record it. And then later send the same thing?
Encryption provides obscurity. You need signing for authentication. Signed messages cannot be repeated because they are always unique. Encryption does not necessarily guarantee that.
-
@bilbolodz I am getting the same message with a Sensebender Micro. I configured it for soft-signing with LOCK_CONFIGURATION enabled. Now I wanted to switch to hardware based signing.
Any way to unlock a locked configuration?
-
@t3chie there is no configuration to lock for soft signing. Configuration locking only applies to atsha204a. And if locked it cannot be unlocked. And normally you shouldn't need to either as the default settings set are the one to use, and unless you have been very creative in hacking the personalizer that configured should work just fine.
-
@Anticimex I tested first with softsigning but shortly after this realized that with soft signing the Sensebender has not enough space for debug messages.
I rerun the personalizer to switch to hardware based signing and hit the "Failed to wake device. Response: E7" message.
Played around and found that#define MY_SIGNING_ATSHA204_PIN 17
instead of
#define MY_SIGNING_ATSHA204_PIN 4made the personalizer happy again. I am still fighting with getting signing to work. Setting #define MY_SIGNING_REQUEST_SIGNATURES and MY_SIGNING_GW_REQUEST_SIGNATURES_FROM_ALL did not get me going.
-
@t3chie I assume you have personalized nodes and gw with the same hmac key?
-
@t3chie also that you also defined the signing enabled flag on all participants (but I think you get a preprocessor error if you don't)
-
Is it possible to use the ATSHA204A along with the Rpi directly attached NRF24L01+ gateway? I can see how to attach the ATSHA to the nodes, but how to attach it to the pi?
Thank you.
-
@skywatch no, not to my knowledge. The atsha driver is Arduino specific. I would happily review a pull request that ports the bit banged driver for Linux though
-
@skywatch the use case for atsha204a backed signing on rPi is limited though. As it is used as I gw (I presume) it is considered "protected" and is less sensitive for key dumping.
-
Thank you for the quick response. Maybe i mis-understand this?
I have got 10 ATSHA chips that I would like to attach to arsuino nodes to use with a raspberry pi based gateway/controller combo. Do I therefore need to attach the ATSHA to the rpi, or could I still use the ATSHA hardware on the arduinos without an ATSHA attached to the rpi?
I had assumed that the atsha chip would be needed at both ends for signing to work. Maybe that's not how it works?
-
@skywatch no, the software port is fully compatible with the atsha204a. So you can use Arduino nodes with atsha204a and they will work just fine with your rPi with software signing. Just as long as they all use the same hmac key.
-
I'm hoping that I did done all ok.
I've personalized the Arduino that acts as Gateway (connected via USB to a Raspberry PI) and I've personalized first node (a DHT22).
Both with software signature.This is the cat from Raspberry / Gateway Arduino:
0;255;3;0;9;TSF:MSG:READ,3-3-0,s=0,c=3,t=16,pt=0,l=0,sg=1: 0;255;3;0;9;Skipping security for command 3 type 16 0;255;3;0;9;SHA256: 37FA7FD8F19D55E99C952F467E45D9A7439AAAAAAAAAA AAAA 0;255;3;0;9;Skipping security for command 3 type 17 0;255;3;0;9;TSF:MSG:SEND,0-0-3-3,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:37FA7F D8F19D5CE9A07E95992C45D9A7439 0;255;3;0;9;Transmitted nonce 0;255;3;0;9;TSF:MSG:READ,3-3-0,s=0,c=1,t=1,pt=7,l=5,sg=1:59.3 0;255;3;0;9;Signature in message: 010F55F31D04DBFCA0AFC7E139475 0;255;3;0;9;Message to process: 03033336D4201 0;255;3;0;9;Current nonce: 37FA7FD8F19D55E99C955992C45D9A7439AAA AAAAAAAAAAA 0;255;3;0;9;HMAC: B50F55F31D04DBFFC7E139475D91093F0A1EABB174B86E9 E9 3;0;1;0;1;59.3 0;255;3;0;9;TSF:MSG:READ,3-3-0,s=2,c=3,t=16,pt=0,l=0,sg=1: 0;255;3;0;9;Skipping security for command 3 type 16 0;255;3;0;9;SHA256: 803B7127EB3B049768C59D328C89862FF731AAAAAAAAAA AAAA 0;255;3;0;9;Skipping security for command 3 type 17 0;255;3;0;9;TSF:MSG:SEND,0-0-3-3,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:803B71 27EB3D0DED839579D328C89862FF731 0;255;3;0;9;Transmitted nonce 0;255;3;0;9;TSF:MSG:READ,3-3-0,s=2,c=1,t=38,pt=7,l=5,sg=1:3.42 0;255;3;0;9;Signature in message: 010E8B790708A39930F73D511F48DAECA 0;255;3;0;9;Message to process: 03002E23BAE5A4002 0;255;3;0;9;Current nonce: 803B7127EB3D0DED83957BB5C59D328C89862FF731AAA AAAAAAAAAAA 0;255;3;0;9;HMAC: D10E8B79D511F48DAECAFB4A3D89F553A2DDB26F1614 3;2;1;0;38;3.42and so on...
This is the Pro MIni serial console:
T: 28.00 1023 Battery Voltage: 3.44 V Battery percent: 102 % 40413 Skipping security for command 3 type 16 40421 TSF:MSG:SEND,3-3-0-0,s=2,c=3,t=16,pt=0,l=0,sg=1,ft=0,st=OK: 40429 Nonce requested from 0. Waiting... 40546 TSF:MSG:READ,0-0-3,s=255,c=3,t=17,pt=6,l=25,sg=1:9CC096EF18295BEFAC43638CA2673A1D759B0CEC6E49C3E060 40558 Skipping security for command 3 type 17 40562 Nonce received from 0. 40564 Proceeding with signing... Message to process: 03002EF24002 Current nonce: 9CC096EF18295BEFA59B0CEC3E060AAAAAAAAAAAAAA HMAC: 5D8E8A59EF1420406004E1318A650686E19E3A8 Signature in message: 018E8A5BD166D106004E 40740 Message signed 40749 Message to send has been signed 40755 TSF:MSG:SEND,3-3-0-0,s=2,c=1,t=38,pt=7,l=5,sg=1,ft=0,st=OK:3.44 40763 Skipping security for command 3 type 16 40769 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=16,pt=0,l=0,sg=1,ft=0,st=OK: 40777 Nonce requested from 0. Waiting... 40900 TSF:MSG:READ,0-0-3,s=255,c=3,t=17,pt=6,l=25,sg=1:1C17F1A31D500CB0E840B7214BE961E 40910 Skipping security for command 3 type 17 40916 Nonce received from 0. 40919 Proceeding with signing... Message to process: 03000E66 Current nonce: 1C17FE25D7B26441A31D961EAAAAAAAAAAAAAA HMAC: D5992FF4CFB6238CD4062397EEE986F47E0BD65020F39C18662 Signature in message: 01992FF4CFB6238C0FDA62397EEE986F47E0 41095 Message signed 41101 Message to send has been signed 41109 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=0,pt=1,l=1,sg=1,ft=0,st=OK:102 41115 MCO:SLP:MS=5000,SMS=0,I1=255,M1=255,I2=255,M2=255 41121 MCO:SLP:TPDAre they secure communicating?
PS I did delete some chars from the HMAC, nonces, etc etc
-
@sineverba the best way to determine that is to see if the messages you send arrive
if you enable signing and require signatures, unsigned or incorrectly signed messages will be rejected.
I see no errors in the log so it seems it works. The logs however don't match up. The hmac:s in one log does not match the hmac:s in the other.
-
@Anticimex
I can assure you that messages, nonces, hmacs and signatures are exactly the same in console gateway and in console of arduino mini.
I did delete some chars before posting for.... security (?)
Thank you for your answer!
-
@sineverba why did you delete them? There is nothing secret about them. They are sent over your radio link so they are to be considered very public, or signing wouldn't be useful, would it?
-
@Anticimex
I understand
The last thing: what's the sense of this message:Skipping security for command 3 type 17?
Thank you!
-
@sineverba it means that message is not signed. Because it is of a type not suitable for signing. Typically an ack or a handshake message. You can look the type up in the api specification. In this case it is a handshake message (a nonce reply to be precise).
-
Hello!! I'm also trying to implement SOFT Signature, but because of my poor English I have many problems !!
Someone could post the socket of a node + a working MQTT gateway.So you can study the code and understand how it works !!!
Thanks 1000 in advance to who can help me
-
@sindrome73 There is no difference for a MQTT gw than from other GW:s. There are code examples in the documentation. See this post and follow the Doxygen links.
-
As I said, my English is not good and therefore it is difficult for me to follow the discussions.
That's why I was asking for a snapshot already done, in order to study the code and understand how to solve ....
 If anyone can help me ????
-
@sindrome73 I am afraid it will be difficult to help if you can't read the code. There is code in the documentation, and you ask for code? There is also a sequence of steps required to do personalization, so you have to be able to understand english to some extent, or find someone who can translate for you.
If it helps, I have pasted the code here in case you for some reason can't find it (I assume you use a official 2.0 release):
How to use this
Before we begin with the details, I just want to emphasize that signing is completely optional and not enabled by default. If you do want the additional security layer signing provides, you pick the backend of your choise in your sketch. Currently, two compatible backends are supported; MY_SIGNING_ATSHA204 (hardware backed) and MY_SIGNING_SOFT (software backed). You can either enable these globally in MyConfig.h or in your sketch for sketch specific/local use.
Firstly, you need to make sure to pick a backend to use as described above.
//#define MY_SIGNING_SOFT #define MY_SIGNING_ATSHA204 #include <MySensors.h> ...Make sure to set the define before the inclusion of MySensors.h. It is legal to mix hardware- and software-based backends in a network. They work together.
You also need to decide if the node (or gateway) in question require and verify signatures in addition to calculating them. This has to be set by at least one of the node in a "pair" or nobody will actually start calculating a signature for a message. Just set the flag MY_SIGNING_REQUEST_SIGNATURES and the node will inform the gateway that it expects the gateway to sign all messages sent to the node. If this is set in a gateway, it will NOT force all nodes to sign messages to it. It will only require signatures from nodes that in turn require signatures. If it is desired that the gateway should require signatures from all nodes, MY_SIGNING_GW_REQUEST_SIGNATURES_FROM_ALL can be set in the gateway sketch.
If you want to have two nodes communicate securely directly with each other, the nodes that require signatures must send a presentation message to all nodes it expect signed messages from (only the gateway is informed automatically). See signerPresentation().
A node can have three "states" with respect to signing:Node does not support signing in any way (neither MY_SIGNING_ATSHA204 nor MY_SIGNING_SOFT is set)
Node does support signing but don't require messages sent to it to be signed (MY_SIGNING_REQUEST_SIGNATURES is not set)
Node does support signing and require messages sent to it to be signed (MY_SIGNING_REQUEST_SIGNATURES is set)Secondly, you need to verify the configuration for the backend.
For hardware backed signing it is the pin the device is connected to. In MyConfig.h there are defaults which you might need to adjust to match your personal build. The setting is defined using MY_SIGNING_ATSHA204_PIN and the default is to use pin A3.
Similar to picking your backend, this can also be set in your sketch:#define MY_SIGNING_ATSHA204 #define MY_SIGNING_ATSHA204_PIN 4 #define MY_SIGNING_REQUEST_SIGNATURES #include <MySensors.h> ...For the software backed signingbackend, an unconnected analog pin is required to set a random seed for the pseudo-random generator. It is important that the pin is floating, or the output of the pseudo-random generator will be predictable, and thus compromise the signatures. The setting is defined using MY_SIGNING_SOFT_RANDOMSEED_PIN and the default is to use pin A7. The same configuration possibilities exist as with the other configuration options.
Thirdly, if you use the software backend, you need to personalize the node (see personalization).
#define MY_SIGNING_SOFT #define MY_SIGNING_SOFT_RANDOMSEED_PIN 7 #define MY_SIGNING_REQUEST_SIGNATURES #include <MySensors.h> ...An example of a node that require signatures is available in SecureActuator.ino.
-
#define MY_SIGNING_SOFT_RANDOMSEED_PIN 7I image not, but... the pin need to be to same in every node?
And.. will the library auto manage the PIN (in this case the #7) rendering it floating or need to explicity set it as INPUT on sketch?
Thank you!
-
@sineverba It is assumed that you do any configurations in your sketch, before including MySensors.h so no, it does not need to be the same on every node. It just need to be left unconnected. And yes, the library takes care of the rest.
-
The pin does not need to be the same.
The library will set it to the required mode, there is no need to do anything in the sketch.
-
Hi
I have a gateway mysensors on my RPI3 with radio RFM69HW. Is any chance to build gateway on RPI3 but also with chip ATSHA204A ? And how build it...
-
@pepson the driver has not been designed with rPi in mind. And you'd probably be better off with an I2C variant for rPi. But we currently don't offer a driver for that so you'd have to write it yourself.
But, for a gw, you typically keep those secured physically, so using a atsha device is less important, compared to "roaming" nodes.
-
@anticimex
I don't understand. I want secure my nodes... By Atsha204a. How I can secure it by other solution.
-
@pepson I have implemented a sw emulator for the atsha which offers compatible security infrastructure but without readout protection. Readout protection is needed if someone steals your node and extracts your hmac key. Your gw won't typically be stolen, so it don't need readout protection and can rely on the soft signing option which is compatible with nodes using atsha204a personalized with the same hmac key. The rPi port support the atsha204a emulator so you can use that to secure nodes that has a real atsha204a device.
-
Can you show me full manual how implement it on Gateway on RPI and how add this to sketch on nodes ? Please...
If you can describe me very good. I am begginer...
-
@pepson you have the links to the documentation in the article this thread is commenting on. At the very top.
-
@anticimex
But please show me as you have to have example...
-
@pepson I don't run on raspberry pi so I don't. But the documentation does have specific configuration examples for raspberry pi, so you have all information needed listed there in "how to use this" section.
-
@pepson see here for 2.2.0 and on left menu for 2.3.0
https://github.com/sineverba/domapi/wiki/MySensors-2.2.0-Security-and-signin
-
@sineverba
Very very good manuals...
But i dont understand what i must type number in this placeand how get it ? It is MAC number network from RPI ?:#define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0Xaa,0Xbb,0Xcc,0XF9,0X82,0XB2,0X50,0XF2,0XAB}}} // got from gateway setup
And what is diffrent with MySensors 2.3.0 ?
I must do all point from MySensors 2.2.0 and additional point for 2.3.0 ?After got your ./configure instruction, type
sudo nano /etc/mysensors.conf
And add your KEYs to the specific section on bottom of the file.
To get your first KEYs follow guide for 2.2.0And in version 2.3.0 i must do this under building gateway ?
And add serial,HMAC,AES in this place in mysensors.conf
Software signing settings
Note: The gateway must have been built with signing
support to use the options below.
To generate a HMAC key run mysgw with: --gen-soft-hmac-key
copy the new key in the line below and uncomment it.
#soft_hmac_key=
To generate a serial key run mysgw with: --gen-soft-serial-key
copy the new key in the line below and uncomment it.
#soft_serial_key=
Encryption settings
Note: The gateway must have been built with encryption
support to use the options below.
To generate a AES key run mysgw with: --gen-aes-key
copy the new key in the line below and uncomment it.
#aes_key=
and then build gateway ?
-
@pepson You use RFM69(H/W/HW). So I. My hint is remain with 2.2.0. I got so many issues with 2.3.0 and RFM that I reverted to 2.2.0 in 1 minute.
HMAC is not LAN MAC, is HMAC got from MYsensors gateway. Same for other 2 keyes.
I think that in long explain on my guide you have all info to get your keyes. I follow my same guide everytime I need to reinstall mysensors / domoticz / an entire PI. It is fully tested
-
@sineverba
Hi
Yes i use radio RFM69HW. I also on 2.3.0 have big problem... and back to 2.2.0. What you have problem on 2.3.0 with radio RFM69 ?I read all your guide and it is ok. But i dont know what i must put in place:
#define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0Xaa,0Xbb,0Xcc,0XF9,0X82,0XB2,0X50,0XF2,0XAB}}} // got from gateway setupPut serial from this:
sudo mysgw --gen-soft-serial-keyWe will get:
SOFT_SERIAL | 7850987FA6601F6538
The next line is intended to be used in SecurityPersonalizer.ino:
#define MY_SOFT_SERIAL 0X78,0X50,0X98,0X7F,0XA6,0X60,0X1F,0X65,0X38To use this key, run mysgw with:
--set-soft-serial-key=7850987FA6601F6538And i must put my keys to mysensors.conf when i use version 2.2.0 ? Or only when use 2.3.0 ?
Software signing settings
Note: The gateway must have been built with signing
support to use the options below.
To generate a HMAC key run mysgw with: --gen-soft-hmac-key
copy the new key in the line below and uncomment it.
#soft_hmac_key=To generate a serial key run mysgw with: --gen-soft-serial-key
copy the new key in the line below and uncomment it.
#soft_serial_key=Encryption settings
Note: The gateway must have been built with encryption
support to use the options below.
To generate a AES key run mysgw with: --gen-aes-key
copy the new key in the line below and uncomment it.
#aes_key=or only send command
sudo mysgw --set-soft-serial-key=7850987FA6601F6538 && sudo mysgw --set-aes-key=768859210B4A75FACC78B757ADAFE75B && sudo mysgw --set-soft-hmac-key=0298FF121DD3194BCC33DC8185055B9D981EBE0A90D847A4777A9E65CCE4F524 ?
-
Too many ack lost and slow communication. And other that I don't remember.
That line on the sketches means that you need add on the node that you want whitelist the serial of gateway.
You got serial gateway on the steps for 2.2.0.
You have it.
You don't need to put anything in no file with 2.2.0. In my guide is NOT mentioned. In my guide, at the bottom, there is the final "set keyes" with only a line OR you can set them everytime you get them.
Please, take your time to read 1, 2, 3 times before type anything. I think it is very clear, and every step is write down for you.
Enjoy PS Don't offend, I want help you, 'cause I used a bit of times before getting security working. And I used so many time write down a guide. But you need to read and follow carefully
-
@sineverba I also have the same problem with communication. But tell me you send issue to developer ? I send but nothing done.
Ok in point 4 in your guide in sketch for node i must put serial key from gateway ? Yes ?
And tell me how remove setup serial, HMAC and AES when i dont want to use it ? How remove it from gateway ?
Thanks
-
Any help ?
-
@pepson no need to remove. Simply, in your sketches, don't use signing at all.
-
@sineverba said in
Security & Signing:no need to remove. Simply, in your sketches, don't use signing at all.
ok but if on gateway it was generate and setup keys and when in skethces i dont use keys will nody connect? and what the purpose of the signature is then ?
I thought that if the gate has a set of keys and will try to connect noda without a key that it will not connect ....
-
@pepson you can use a special flag define to "downgrade/reduce" security MY_WEAK_SECURITY
-
Ok summary
When i have setup on Raspberry Gateway , generate keys.When i write in node all keys with sketches.... Node connect ok.
But when write to node only sketches without keys.,... node connect to gateway or not connect to gateway ?
-
@pepson you need to setup gateway with weak security.
You need generate keyes and set in gateway.
You need to personalize nodes with the sketch and set keyes on Arduino EEPROM.
From now, you have two ways: Your node need security? Set use security bla-bla on top with other define(s).
Don't Need security? Don't define use security.
Simpler than ever.
-
@pepson if you find the security setup to be too complicated, I highly recommend sticking with the simple password flags. The documentation has it all.
-
@sineverba said in
Security & Signing:setup gateway with weak security.
But when configure my gateway without flag setup gateway with weak security i can only use nodes with setup in sketches keys. yes ?
-
Can you share me this document when is describe how define only pass ? I want also read this.
-
Let's summarize. Last time.
- compile gateway with weak security (make your research, also in my github guide, there is )
- create the 3 keyes for gateway
- set the 3 keyes for gateway.
- clean your EEPROM arduinos with the sketch present in my guide and in examples of library
- set the keyes in EEPROM arduinos.
Stop. End. Fin. Fine. These steps are MANDATARY. You NEED to do.
You will have in EEPROM the keyes (arduino) and in gateway.
From now, you select:
a) Do I need security? Perfect, in sketch arduino add #define bla bla bla on top with security and other stuff.
b) Do I NOT need security? Perfect, in sketch arduino DON'T ADD #define bla bla related to security.
- compile gateway with weak security (make your research, also in my github guide, there is
-
@pepson And, last all, you can use the mysensors debug options. Try. Try. Try! This is the best option offered to you to learn. Try!
At max, nothing works
-
@sineverba
ok all is very good.But what give me this if i can connect nodes also with defines bla bla bla in skethc and also without define bla bla bla in sketch?
But Do I think right ? In each of these accidents in the eeprom I need to have the keys loaded?
-
@pepson only one word. Try. Really, you are lost in 1 cm of water. Try. And if it doesn't work, open your topic, showing exactly your sketches and what have you done.
-
ok thanks
-
Ok i build my gateway on RPI on MySensors 2.2.0 with this configuration:
./configure --my-transport=rfm69 --my-rfm69-frequency=868 --my-is-rfm69hw --my-gateway=ethernet --my-port=5003 --my-signing=software --my-signing-request-signatures
Then generate 3 key and setup it on gateway.
Then clear_epprom on Arduino MIni Pro, and then send sketch security with add serial, HMAC, and AES. Then put sketch with add this on top sketch with my SERIAL generated on gateway RPI.
#define MY_SIGNING_SOFT
#define MY_SIGNING_SOFT_RANDOMSEED_PIN 7
#define MY_SIGNING_REQUEST_SIGNATURES
#define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0X2C,0X61,0X17,0X2E,0XEE,0XDD,0XCC,0XBB,0XAA}}} // got from gateway setupAfter that i run HA and he not found my nodes...
WHat is wrondg ?
-
@pepson well for starters, don't start out with whitelisting unless you know exactly what you are doing. First you have to verify that your network is stable enough to handle the security protocol. The simplest option is to only enable encryption, or use the simple password flag options. Once you have established that your gw and nodes are capable of communicating securely you can move on to personalization and whitelisting.
-
@anticimex
What you mean white list?Before adding all security my nodes and gateway works perfect.
-
@pepson you define whitelisting so I presume you use it. But I don't see your gw flags specifying it so of course it does not work. So get rid of that flag from your config unless you know what it mean so that you set it up properly.
-
What flag i must remove ?
This :
#define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0X2C,0X61,0X17,0X2E,0XEE,0XDD,0XCC,0XBB,0XAA}}} // got from gateway setupBut on GW i setup this:
sudo mysgw --set-soft-serial-key=2C61172EEEDDCCBBAA && sudo mysgw --set-aes-key=9D2AD43CF909875C4C77111111111111 && sudo mysgw --set-soft-hmac-key=A2A64C48EA6765C5DAEFA12A1E41E2F038515A9CAED9FED73D11111111111111
-
@pepson please just read the documentation. And more importantly, follow it.
Isn't it obvious that it is the flag that mention whitelisting that is supposed to be removed unless you intend to use whitelisting, in which case you ought to know how to set it up properly at both ends?
-
Sorry i dont undestand
-
@pepson https://www.mysensors.org/apidocs/group__MySigninggrpPub.html
Note that it is the documentation for the latest release (simple password flags work differently compared to previous releases, see release notes for the latest release).
-
HI
i don as describe...- install gateway on raspberry with this configuration:
./configure --my-transport=rfm69 --my-rfm69-frequency=868 --my-is-rfm69hw --my-gateway=ethernet --my-port=5003 --my-leds-err-pin=12 --my-leds-rx-pin=16 --my-leds-tx-pin=18 --my-signing=software --my-signing-request-signatures --my-signing-weak_security --my-signing-debug
and then generate serial, aes and hmac
pi@raspberrypi:~/MySensors $ sudo mysgw --gen-soft-serial-key
SOFT_SERIAL | 8FC828503E6EB14C5DThe next line is intended to be used in SecurityPersonalizer.ino:
#define MY_SOFT_SERIAL 0X8F,0XC8,0X28,0X50,0X3E,0X6E,0XB1,0X4C,0X5DTo use this key, run mysgw with:
--set-soft-serial-key=8FC828503E6EB14C5D
pi@raspberrypi:~/MySensors $ sudo mysgw --gen-soft-hmac-key
SOFT_HMAC_KEY | 0D682ED05106E5F361C64288D68AAE1B34F5FFB62B4E39773C9D92DED04B6514The next line is intended to be used in SecurityPersonalizer.ino:
#define MY_SOFT_HMAC_KEY 0XD,0X68,0X2E,0XD0,0X51,0X6,0XE5,0XF3,0X61,0XC6,0X42,0X88,0XD6,0X8A,0XAE,0X1B,0X34,0XF5,0XFF,0XB6,0X2B,0X4E,0X39,0X77,0X3C,0X9D,0X92,0XDE,0XD0,0X4B,0X65,0X14To use this key, run mysgw with:
--set-soft-hmac-key=0D682ED05106E5F361C64288D68AAE1B34F5FFB62B4E39773C9D92DED04B6514
pi@raspberrypi:~/MySensors $ sudo mysgw --gen-aes-key
AES_KEY | 8FDB1EE8D0351CFF874D337731BF37AEThe next line is intended to be used in SecurityPersonalizer.ino:
#define MY_AES_KEY 0X8F,0XDB,0X1E,0XE8,0XD0,0X35,0X1C,0XFF,0X87,0X4D,0X33,0X77,0X31,0XBF,0X37,0XAETo use this key, run mysgw with:
--set-aes-key=8FDB1EE8D0351CFF874D337731BF37AE
pi@raspberrypi:~/MySensors $and setup it on my gateway
sudo mysgw --set-soft-serial-key=8FC828503E6EB14C5D && sudo mysgw --set-aes-key=8FDB1EE8D0351CFF874D337731BF37AE && sudo mysgw --set-soft-hmac-key=0D682ED05106E5F361C64288D68AAE1B34F5FFB62B4E39773C9D92DED04B6514
all is ok to this moment
Then
- clear eeprom in node Arduino pro mini with this sketch:
https://github.com/sineverba/domoraspi/tree/master/utils/sketches - write sketch security with setup my serial, aes and hmac
https://github.com/sineverba/domoraspi/tree/master/utils/sketches
at the top setup...
/************************************ User defined key data ***************************************//** @brief The user-defined HMAC key to use unless @ref GENERATE_HMAC_KEY is set */
//#define MY_HMAC_KEY 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
#define MY_HMAC_KEY 0XD,0X68,0X2E,0XD0,0X51,0X6,0XE5,0XF3,0X61,0XC6,0X42,0X88,0XD6,0X8A,0XAE,0X1B,0X34,0XF5,0XFF,0XB6,0X2B,0X4E,0X39,0X77,0X3C,0X9D,0X92,0XDE,0XD0,0X4B,0X65,0X14/** @brief The user-defined AES key to store in EEPROM unless @ref GENERATE_AES_KEY is set */
//#define MY_AES_KEY 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
#define MY_AES_KEY 0X8F,0XDB,0X1E,0XE8,0XD0,0X35,0X1C,0XFF,0X87,0X4D,0X33,0X77,0X31,0XBF,0X37,0XAE/** @brief The user-defined soft serial to use for soft signing unless @ref GENERATE_SOFT_SERIAL is set */
#define MY_SOFT_SERIAL 0X8F,0XC8,0X28,0X50,0X3E,0X6E,0XB1,0X4C,0X5D/***************************** Flags for guided personalization flow ******************************/
- then write my sketch relay with added at the top this info:
#define MY_SIGNING_SOFT
#define MY_SIGNING_SOFT_RANDOMSEED_PIN 7
#define MY_SIGNING_REQUEST_SIGNATURES
#define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0X8F,0XC8,0X28,0X50,0X3E,0X6E,0XB1,0X4C,0X5D}}} // got from gateway setupand now on my Home assistant in file
/home/homeassistant/.homeassistant/mysensors.jsonfound my node but wthout full information like name....
{
"0": {
"battery_level": 0,
"sketch_name": null,
"sketch_version": null,
"children": {},
"type": 18,
"protocol_version": "2.2.0",
"sensor_id": 0
},
"33": {
"battery_level": 0,
"sketch_name": null,
"sketch_version": "1.0",
"children": {
"1": {
"type": 3,
"id": 1,
"values": {
"2": "1"
},
"description": ""
}
},
"type": 17,
"protocol_version": "2.2.0",
"sensor_id": 33
}
}and in Home Assistant is not show in devices this node. Not found it.
What i done wrong ?
- install gateway on raspberry with this configuration:
-
@pepson said in
Security & Signing:MY_SIGNING_NODE_WHITELISTING
How many times do I need to tell you to get rid of the whitelisting flag?
-
@anticimex
Ok read... but...
when i use MY_SIGNING_NODE_WHITELISTING i must on node in sketch add serial number my gateway and also serial number for node. But from where i can get serial number for my arduino pro mini ? I dont know...becasue i don use ATSHA204 but i use only soft signing....
-
@pepson This is the serial OF GATEWAY. Not your Arduino. You need to put serial of GATEWAY.
Please, first of all, DONT' USE WHITELISTING. And pay attention: if you enabled it, remove it and:
1 - clear eeprom
2 - flash eeprom with keyes
3 - reload sketch (without whitelisting)
-
@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 -dOf 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
-
In my first time I use only serial number gateway in flag whitelistening and also not working.
-
@pepson Last time. Please.
REMOVE
WHITELISTING
FROM
YOUR
SKETCHClear EEPROM and paste here output of debug. No other.
-
@sineverba
OK wait for info
-
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
-
@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.
-
But still I don't know how use white listening...?
-
@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.
-
@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?
-
@pepson Please. Read. The. Documentation.
And no, atsha204a is not supported on rPi. Nor does it need to be.
-
@anticimex
But still I don't know how read serial number from Node on Arduino Mini Pro when I want use White Listening...
-
@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!
-
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?
-
@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.
-
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.
-
@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
-
-
@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.
- 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.
