Security
-
Could the personalization sketch output the keys in a c-form which can be added directly in MyConfig.h?
So.. If key-code is defined in MyConfig it will be written to ATSHA204A at startup. Hope I'm clear enough?
@hek
Not sure I follow. The key is permanently stored in the device. It is not supposed to change ever once written. If zones are locked, it will also not be possible to change. The personalization is a one-shot operation. Why would you like to write the key on every start?
Sure I could update the personalization sketch to emit the auto-generated key in C-syntax form for easy copy+paste, but there is no requirement that the key is generated by the device. You could use "My secret key" as key if you wanted to. -
Perhaps I should post an update on my signing development here.
I have implemented a unique nonce-based signature mechanism using ATSHA204 in the protocol.
I did have to make a sacrifice due to the size limitation of a RF message so the signatures will be truncated. However, analysis show that even truncated HMAC-SHA256 are extreamly difficult to beat, so we should be pretty well covered.Architecturally, the signing driver will be a "plug in". A dummy signing driver is enabled by default, and signing is only done if requested. I will post detailed descriptions and guides once I manage to optimize the SHA204 library and signing implementation down to fit together with an ethernet GW sketch in a Nano (which I think is the most "crowded" usecase).
The design will allow for other signing backends to be used instead of ATSHA204, but as that is the only HW I got that is the backend I am implementing support for.
-
@marcusvdt I believe the conclusion is here
-
working with security on a daily basis I just wanted to point out.... if they want to get it they will....
I sincerely hope the new additions to the security don't slow down the sensor network.
if someone wanted to make sure no one was listening into a radio broadcast.... I would personally go wired...... I see the security issue for this type of network is at best an authentication problem nothing more.
I love the addition of the authentication as a basic security measure and it just adds to the fine work you are doing. -
working with security on a daily basis I just wanted to point out.... if they want to get it they will....
I sincerely hope the new additions to the security don't slow down the sensor network.
if someone wanted to make sure no one was listening into a radio broadcast.... I would personally go wired...... I see the security issue for this type of network is at best an authentication problem nothing more.
I love the addition of the authentication as a basic security measure and it just adds to the fine work you are doing. -
@Anticimex How far are you with authenticity verification?
@Avamander what do you mean? I consider myself done with security implementation. I don't see a need for more security functionality now when we have both encryption for rf24 and rf69 as well as hmac authentication and white listing.
-
@Avamander what do you mean? I consider myself done with security implementation. I don't see a need for more security functionality now when we have both encryption for rf24 and rf69 as well as hmac authentication and white listing.
-
@Anticimex I am not familiar with MySensors so sorry for the questions, who are the "we" you are speaking of having the features? Is this something MySensors now supports?
@Avamander "MySensors" has had support for this for quite some time yes. As you can read in the topic post of this thread. Encryption is discussed elsewhere on the forum.
