So how was sg= calculated ?
What is message to process ?
The nonce is depending on analogue signal + what ? to get this value ?
I have already defined a random HMAC, but this one is different. It is a combination of what ?
Finally what is signature in message ?

On the other side I am trying to sniff the data by a serialgateway which is trying to hack the network. It only read the following data:

It is the sg only which it succeeded to read. Also I do understood form the topic that the attacker can read values sent between nodes unencrypted, but here I can't figure out where is the unencrypted data which can be sniffed by the attacker but we don't bother ourselves with cas we protect our network by using signing.

Lots of questions but I am trying to understand the logic and architecture in details to understand what I am doing

Hi,
I suggest you read the doxygen documentation for signing carefully as it answers the questions you have. Signing does not in any way prevent anyone from reading your messages. As I have described in the documentation, it provides authenticity. That is, you can trust the sender of a signed message to be yours and not someone else's.

@Anticimex Yeah I understand it doesn't prevent anyone from reading my messages, and that's what I am trying to do now. To hack the system depending on the data available. But when I read the post I understood that encryption is not a priority as signing is enough now to prevent an attacker from sending data, but it can read text. I thought I will find clear text describing that I am sending to node X value Y but I found this 2;255;3;0;17;01F470C061A0B9FF3DE248835736E2B85E31C8D6D1844AACAC
so I wanted to ask.

Anyway I'll re read the documents more carefully and return to you back please. Thanks.

Encryption is available for both rf24 and rf69 radios. But encryption and signing are two different things, and I work with signing. And signing is more efficient against hackers than encryption. Encryption is more if you care about privacy.

@noelgeorgi AES encryption is already supported for both NRF24 and RFM69 radios. See MyConfig.h on the development branch for the flag to use. Doyxgen documentation I link to in this thread on the topic post also contain the personalization instructions for encryption on the development branch.

@noelgeorgi AES encryption is already supported for both NRF24 and RFM69 radios. See MyConfig.h on the development branch for the flag to use. Doyxgen documentation I link to in this thread on the topic post also contain the personalization instructions for encryption on the development branch.

Thanks for the info.
I'm getting the following errors when compiling securitypersonalizer:

@noelgeorgi if you have cloned the arduino git you have everything you need. I can build that sketch myself and have used it many times. I suspect you have a problem with your environment if you get compilation errors in it. We continously test the repository and build all examples nightly to make sure it all works as it is supposed to. You can see this at ci.mysensors.org

@Anticimex sorry for the interruption, i was using rsync to get eveything synced and i might have messed something uop, sha204 library was missing from my libraries folder, now everything works, thanks for the prompt and fast support.

@Anticimex - thanks for this. I finally got around to enabling signing on everything while I was testing out my new board design. I followed your schematic from your board design when I built mine and I just went through the instructions to configure the crypto chip and everything went smoothly. Thanks for the work and the good instructions!

Isn't blacklisting cool too to use ?
Like, if we know the "name" of the sensor lost, we push it to the black list and voila ? This way, we don't have to put a long list a agreed sensors if we have only two nodes outside the house.
... I think.

@Pierre-P because if a node is lost, you no longer control that node. So anyone could reprogram it to have it identify itself in any way possible. We have to assume an attacker has full source code access, so they can rewrite the signing algorithm to use a fake serial as salt for the signature to trick the GW to believe it is a new node. A whitelist mean the attacker has to know the ID/serial of one of the nodes you trust. Which they won't know unless they can get access to that node.

@Pierre-P you are welcome. Security is best when it is totally open and the implementation is aware of this. That makes it quite difficult to circumvent, and it also allows to be challenged. That way, with many eyes examining it, it gets stronger and stronger I welcome all attempts to crack it. White or black hat style.

Well, how much space you have depend on your sketch and on the features you enable in the library, so it is impossible to predict how your code will fit. I suggest you just try to enable what you want and compile, and you'll know

ouch, @Anticimex was a bit faster
oh, and the problem in the thread you quoted @Soloam is encryption. At least at that time, encryption used too much space so there wasn't space to include either hardware or software signing.

And you might also have read mine and @mfalkvidd's stand on encryption, so don't be discouraged if you find that you can't fit both. Just skip the encryption in that case. It adds far less in security than signing does.

@carlierd could you specify a bit clearer what you mean by "nonce error"? Signing should work, but the atsha driver is not tested @ 1MHz and might get bad timing. Also, for soft (and hard) signing, if 1MHz is used, performance could degrade to the point that the nonce timeout needs to be increased.

@carlierd you have a lot of st=fail, so your problem is radio related, not signing related. I also see non nonce related messages fail so you need to stabilize your rf connection before signing can work. And since signing uses the maximum payload size, it has the least probability to succeed to be sent, so you could find that unsigned messages work while nonces and signed messages fail, but this is normal of the rf link is not fully working. If you get st=fail, it is a radio problem. See this discussion for details: http://forum.mysensors.org/topic/3386/mqttclientgateway-broken-after-upgrade-signature-failure

@Anticimex Hello. Everything is working at 16 or 8MHz so I am pretty sure it's not an issue with the material.
I will burn the bootloader again and create a new post if it's still not correct. I will also disable signing feature to be sure there is no impact.

@carlierd well, st=fail indicate transmission failure so it is pretty clear that you have a issue with rf, at least on that frequency. st=fail is not signing related. But, like previously discussed, enabling signing can trigger more st=fail because the payload gets bigger and is more sensitive to noise.

@calierd You can have a look here at the discussion I had with a similar problem which I was able to resolve finally. See the last reply in the aforementioned thread where I summarized how I resolved it, eventually.

@Anticimex@tomkxy
Perhaps the arduino and RFM69 can't run at 1MHz. I have capacitors and I tried with two different power sources. Without signing it's better but still a lot of st=fail. No matter, it was just for testing purpose

@Soloam
You can mix nodes with soft signing and ATSHA signing as you like.
You can mix nodes with signing on and off as well. The GW will only sign messages to nodes that require it, and it will also only check signatures from nodes that require signatures. So you can have one node which support/require signing and another which don't. The GW will be able to exchange messages with both nodes.

Slightly silly question, but did anyone manage to get signing working (MySigningAtsha204Soft signer;) on Arduino Uno on MS 1.5.4 on the Ethernet gateway please? I am going out of memory and really hate to upgrade it to Mega

@alexsh1 Hopefully the manual informs about the risks with locking data (that you cannot change the key afterwards). Atmel is somewhat vague on the security implications; they say that you can not read the key anyway but it is "more secure" to lock data. But personally, I have not found a way to read it, and I prefer to be able to change my HMAC key in my devices if it should be compromised.

Strange that you don't get the soft serial. I see nothing obviously wrong with your config. But I do see that you probably sensored your uart log a bit too hard because there are other lines missing there.
You should have seen this

You are sure you have no #undef or some accidental comment or similar. As you see in the personalizer code, it is not that complicated. If the flags are enabled, you should at least get some printouts. But since (if your UART dump is correct) you get nothing, I suspect the flags are not really "on".

Strange that you don't get the soft serial. I see nothing obviously wrong with your config. But I do see that you probably sensored your uart log a bit too hard because there are other lines missing there.
You should have seen this

You are sure you have no #undef or some accidental comment or similar. As you see in the personalizer code, it is not that complicated. If the flags are enabled, you should at least get some printouts. But since (if your UART dump is correct) you get nothing, I suspect the flags are not really "on".

OK, it was Arduino glitch - any changes in the sketch were not reflected on the compilation. Rebooted my PC and restarted Arduino and all works as expected.

A few questions: Mixing ATSHA204 and soft signing - Does HMAC key (one stored in ATSHA204 of say a node and another one in GW's EEPROM) have to be the same? Also I understand one can store HMAC key on both ATSHA204 and EEPROM of one device (say, Sensebender)? I understand that SOFT_KEY has to be unique for every device?

You can mix ATSHA204A and soft signing as much as you like. But for any two nodes to exchange signed data the HMAC keys have to be identical.
Yes, you can store a HMAC key in both ATSHA204A and EEPROM. These can be different if you like (and I recommend they are as the EEPROM can be dumped if the node falls into the wrong hands).
However, if you want that node to communicate signed data to another node, that node must use a matching HMAC key.
SOFT_KEY is the HMAC key stored in EEPROM, it must not be unique for every device. If it is, no device will be able to sign data to any other node and expect that node to accept that data.
SOFT_SERIAL on the other hand, must be unique to serve any useful purpose for whitelisting. If you use the ATSHA204A, the serial fused in the device will be used and that cannot be changed, and is according to Atmel, unique.

@Anticimex Right, this is why I am not able to sign 1.5.4 nodes with 2.0b GW.
In fact when I inserted #define MY_SIGNING_REQUEST_SIGNATURES into the GW code, some nodes stopped working and I think it has to be with signing as GW is throwing a lot of messages that signing failed.

@alexsh1 I'm really glad to hear that. Thank you! Glad that signing is being used and is perceived as something not to complicated to bother with. It sets us apart from many other projects dealing with the same thing

@Anticimex I did not say it was not complicated
Just kidding - speaking just for myself, it did require some time investment to understand the concept and then upgrading my gateway and my nodes (I am still in the process of rolling signing across the rest of my nodes) to MySensors 2.0b. I probably spent more time upgrading MySensors lib and breaking some hardware in the meantime (the SMA connector on the nrf24l01+ PA+LNA) than the actual signing.

@alexsh1 yeah, well if there is room for improvement in the documentation then feel free to help put with suggestions if there is anything unclear about that I use doxygen to document signing features, and a link is available on the GitHub "front-page" (the readme.md)

@alexsh1 hm, yeah, perhaps something for @hek to consider. At least a link to the signing section of the doxygen docs could be placed there. I have tried to make the documentation as step-by-step friendly as I can. That said, as I also did the actual implementation, I may well be blind for certain aspects I take for granted that a "novice" does not.

The next release of the main site will be much more flexible and integrated with openhardware-added projects. The idea is to allow community members to maintain their projects and/or "articles" themselves. The how-to for signing is a good example of an article.

Hi,
I have about 100 ATSHA204 I2C variant to be used in a MySensors project.
Do you think that by modifying the personalizer sketch to disable the I2C bit in the configuration (0x03 word address) the chips can be set to be used as single-wire, or are they hardcoded to use only one protocol, but then why having the config bit?

@executivul The bit is readonly. You cannot change it. It is used to determine the variant of chip, not to select mode of operation.
From the documentation:
But you are welcome to submit a pull request for adding support for I2C variants of ATSHA204a. I have none myself so I have not bothered looking into that and currently I am out of time to spend on it I am afraid.

@Anticimex said:
But you are welcome to submit a pull request for adding support for I2C variants of ATSHA204a. I have none myself so I have not bothered looking into that and currently I am out of time to spend on it I am afraid.

@executivul By forking the MySensors core repository and create a local git branch, do your code, push it back to your fork on GitHub and then create a pull request from that. There are good guides on GitHub for how do do it.

@meddie Sorry, missed that post.
You have SKIP_KEY_STORAGE defined so no keys will be stored. This is the default and intentional, to avoid people just executing the sketch and accidentally overwrite existing keys.
Furthermore, you have selected to personalize a ATSHA device, and have it generate the keys. That means that you have to define LOCK_CONFIGURATION or the ATSHA random number generator will not work.

@Anticimex
sorry sorry for so many questions, i have read the how to use already some times, but maybe its my bad english or the fear to do something wrong or to destroy the chip. I get a little bit unsure.

Now i get both keys. If i understood correctly, the keys are now stored, i have now to put the shown keys to the sketch as HMAC and AES Key, and run this sketch on the sensor nodes.
On the gateway on which i generated the keys i dont need to do anything more as to upload the gateway sketch ?
Thank you very much for your support!

@meddie Sorry, missed that post.
You have SKIP_KEY_STORAGE defined so no keys will be stored. This is the default and intentional, to avoid people just executing the sketch and accidentally overwrite existing keys.
Furthermore, you have selected to personalize a ATSHA device, and have it generate the keys. That means that you have to define LOCK_CONFIGURATION or the ATSHA random number generator will not work.

@Anticimex
sorry i have one more question, because i didnt fully understand this. In the gettings started how to you wrote:

Pick a “master” device with serial debug port.
Set the following sketch configuration of the personalizer:
...
Enable SKIP_KEY_STORAGE
...
Execute the sketch on the “master” device to obtain a randomized key. Save this key to a secure location and keep it confidential so that you can retrieve it if you need to personalize more devices later on.
Now reconfigure the sketch with these settings:
...
Disable SKIP_KEY_STORAGE
...
Put the saved key in the user_key_data variable.
Now execute the sketch on all devices you want to personalize with this secret key.

on the first run i have to enable SKIP_KEY_STORAGE so i removed the comments.
But here in forum you write i have to disable this. After i has disabled it wroked fine for me.

But now i have to run the sketch on my node, and i think i have to disable the SKIP function too, because i need that the keys will be stored in the node.

So if i am right, the on both runs the SKIP function has to be commented out? Or i am wrong?
Thank you.

@meddie If your read the text carefully it says:
Set the following sketch configuration of the personalizer:
...
Execute the sketch on the “master” device to obtain a randomized key. Save this key to a secure location and keep it confidential so that you can retrieve it if you need to personalize more devices later on.
Now reconfigure the sketch with these settings:
...
Now execute the sketch on all devices you want to personalize with this secret key.

So in other words; you first use the settings described in the first setting, execute that once. Follow the instructions carefully. Write down the key you got. Then you reconfigure the sketch and execute it on all devices you want to personalize. That is, you execute it twice on the first device.
I wrote that you need to undefine SKIP_KEY_STORAGE if you want to store a key. But the first set of instructions in the documentation is not saying that you are supposed to store a key. It says "Execute the sketch on the “master” device to obtain a randomized key."

So the documentation is correct, and describe a flow where you personalize nodes and gateways with the minimum amount of changes needed. First you generate a key, and this step can actually be skipped altogether if you just make your own random key or password to use for HMAC/AES.
Then you reconfigure the personalizer to use your generated (or selected) key and write it to all your devices.

@meddie are you sure you ran with the exact settings described for generating the keys? The SKIP_KEY_STORAGE flag does not prevent the keys from being generated. They are still printed in the serial log. It prevents the keys from being stored to the atsha204a device.

0 MCO:BGN:INIT NODE,CP=RNNNAA-,VER=2.1.1
4 TSM:INIT
4 TSF:WUR:MS=0
12 TSM:INIT:TSP OK
14 TSF:SID:OK,ID=100
16 TSM:FPAR
18 Will not sign message for destination 255 as it does not require it
67 TSF:MSG:SEND,100-100-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2076 !TSM:FPAR:NO REPLY
2078 TSM:FPAR
2080 Will not sign message for destination 255 as it does not require it
2127 TSF:MSG:SEND,100-100-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
4139 !TSM:FPAR:NO REPLY
4141 TSM:FPAR
4143 Will not sign message for destination 255 as it does not require it
4190 TSF:MSG:SEND,100-100-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
6199 !TSM:FPAR:NO REPLY
6201 TSM:FPAR
6203 Will not sign message for destination 255 as it does not require it
6250 TSF:MSG:SEND,100-100-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
8259 !TSM:FPAR:FAIL
8261 TSM:FAIL:CNT=1
8263 TSM:FAIL:PDT
18266 TSM:FAIL:RE-INIT
18268 TSM:INIT
18276 TSM:INIT:TSP OK
18278 TSF:SID:OK,ID=100
18280 TSM:FPAR
18282 Will not sign message for destination 255 as it does not require it
18331 TSF:MSG:SEND,100-100-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
20340 !TSM:FPAR:NO REPLY
20342 TSM:FPAR
20344 Will not sign message for destination 255 as it does not require it
20393 TSF:MSG:SEND,100-100-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
22403 !TSM:FPAR:NO REPLY
22405 TSM:FPAR
22407 Will not sign message for destination 255 as it does not require it
22456 TSF:MSG:SEND,100-100-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
24465 !TSM:FPAR:NO REPLY
24467 TSM:FPAR
24469 Will not sign message for destination 255 as it does not require it
24518 TSF:MSG:SEND,100-100-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
26527 !TSM:FPAR:FAIL
26529 TSM:FAIL:CNT=2
26531 TSM:FAIL:PDT
36534 TSM:FAIL:RE-INIT
36536 TSM:INIT
36544 TSM:INIT:TSP OK
36546 TSF:SID:OK,ID=100
36548 TSM:FPAR
36550 Will not sign message for destination 255 as it does not require it
36599 TSF:MSG:SEND,100-100-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
38610 !TSM:FPAR:NO REPLY
38612 TSM:FPAR
38615 Will not sign message for destination 255 as it does not require it
38664 TSF:MSG:SEND,100-100-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
40673 !TSM:FPAR:NO REPLY
40675 TSM:FPAR
40677 Will not sign message for destination 255 as it does not require it
40726 TSF:MSG:SEND,100-100-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
42735 !TSM:FPAR:NO REPLY
42737 TSM:FPAR
42739 Will not sign message for destination 255 as it does not require it
42788 TSF:MSG:SEND,100-100-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
44800 !TSM:FPAR:FAIL
44802 TSM:FAIL:CNT=3
44804 TSM:FAIL:PDT
54808 TSM:FAIL:RE-INIT
54810 TSM:INIT
54818 TSM:INIT:TSP OK
54820 TSF:SID:OK,ID=100
54822 TSM:FPAR
54824 Will not sign message for destination 255 as it does not require it
54874 TSF:MSG:SEND,100-100-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
56883 !TSM:FPAR:NO REPLY
56885 TSM:FPAR
56887 Will not sign message for destination 255 as it does not require it
56936 TSF:MSG:SEND,100-100-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:

@meddie if you want your node to sign messages to the gateway you have to tell the gateway to require it. The log says that it does not require it and it is clear from your gateway sketch that you have disabled the requirement.
Is that your problem?EDIT: I see that the messages are broadcasts, those will never be signed. So the "will not sign messages" are perfectly normal no matter how you configure your gateway in this case.
The problem, at least based on the node log is that your node cannot find a parent to communicate with for some reason.