Encryption, Signing and OTA is there any how-to?
-
If you feel this page is inadequate as the description for how to use signing, I am all ears for getting suggestions on how to improve it.
Personally, I think it is I who do not understand really. and then is afraid to start by destroying the hardware
//Mattias
-
If you feel this page is inadequate as the description for how to use signing, I am all ears for getting suggestions on how to improve it.
@Anticimex said in Encryption, Signing and OTA is there any how-to?:
If you feel this page is inadequate as the description for how to use signing, I am all ears for getting suggestions on how to improve it.
Its a great read but a little too much on the theoretical side for me. I think we should add some practical and complete example. Something like:
- get the gw and use this xyz sketch to generate the keys
- copy the keys
- save the keys with this xyz sketch
- flash the normal gateway sketch
then take a node
- burn the keys to it
- add your xyz sketch with these parts to enable whitelisting, ....
Something like that so that you can point any "noob" at this and tell him to do like that.
-
@Anticimex said in Encryption, Signing and OTA is there any how-to?:
If you feel this page is inadequate as the description for how to use signing, I am all ears for getting suggestions on how to improve it.
Its a great read but a little too much on the theoretical side for me. I think we should add some practical and complete example. Something like:
- get the gw and use this xyz sketch to generate the keys
- copy the keys
- save the keys with this xyz sketch
- flash the normal gateway sketch
then take a node
- burn the keys to it
- add your xyz sketch with these parts to enable whitelisting, ....
Something like that so that you can point any "noob" at this and tell him to do like that.
@LastSamurai well, if you read far enough you get exactly that. At least as how I view things, but as I am the designer, I might find things obvious which are not. But I really have tried to add specific use case examples and how to configure them.
-
@LastSamurai well, if you read far enough you get exactly that. At least as how I view things, but as I am the designer, I might find things obvious which are not. But I really have tried to add specific use case examples and how to configure them.
@Anticimex Overall I like your text (and your work!) but I can only tell you what I found to be missing when I read this:
the step by step tutorial (like a short summary of your text) containing versions of the personalizer sketch doing configured to do exactly whats needed in that step. Your examples only cover the the last part of my list (the node configuration)! -
@Anticimex Overall I like your text (and your work!) but I can only tell you what I found to be missing when I read this:
the step by step tutorial (like a short summary of your text) containing versions of the personalizer sketch doing configured to do exactly whats needed in that step. Your examples only cover the the last part of my list (the node configuration)!@LastSamurai I see. Well, I intentionally left the personalizer to be highly customizable since users have varying requirements, but I can add flags to it which preconfigure some typical usecases if that would help?
-
I hope to be able to file a pull request with updates to the personalizer this or next week. @LastSamurai @MLs @meddie i would really appreciate if you tested and reviewed the change so that you (and others) no longer are deterred from using signing due to its complexity. I will update the pull request until you feel confident in the procedure. I will post a link here when I have something to show for.
-
@LastSamurai I see. Well, I intentionally left the personalizer to be highly customizable since users have varying requirements, but I can add flags to it which preconfigure some typical usecases if that would help?
@Anticimex said in Encryption, Signing and OTA is there any how-to?:
@LastSamurai I see. Well, I intentionally left the personalizer to be highly customizable since users have varying requirements, but I can add flags to it which preconfigure some typical usecases if that would help?
That would actually be great! Some flags that automatically set up for:
- create everything at the gw and save it
- node: takes the provided HMAC (and aes) and saves it, generates new node id
and perhaps some others would really help me (and others I hope). I gladly test your new changes, just keep me updated!
PS We could also add a section to your text describing that you need well working radios (+ caps) because of the longer message sizes. Signing doesn't work for all nodes for me due to that and when I started working with it I thought this to be a problem with signing.
-
@Anticimex said in Encryption, Signing and OTA is there any how-to?:
@LastSamurai I see. Well, I intentionally left the personalizer to be highly customizable since users have varying requirements, but I can add flags to it which preconfigure some typical usecases if that would help?
That would actually be great! Some flags that automatically set up for:
- create everything at the gw and save it
- node: takes the provided HMAC (and aes) and saves it, generates new node id
and perhaps some others would really help me (and others I hope). I gladly test your new changes, just keep me updated!
PS We could also add a section to your text describing that you need well working radios (+ caps) because of the longer message sizes. Signing doesn't work for all nodes for me due to that and when I started working with it I thought this to be a problem with signing.
@LastSamurai node IDs is not a signing thing so the personalizer will not touch that.
And regarding working radios, the "real" documentation feature a troubleshooting section where that topic is covered. Doxygen that is. Link is available through the readme on the library on github. I will see if I can incorporate that somehow on the main site. Unfortunately there is no automatic link between the generate docs which are the most recent, and the article on the main site. -
I meant the serial number (forgot that name and it is like a node id, right?). The one thats needed for e.g. whitelisting.
The documentation mentions somewhere that signing might cause errors if the radios aren't working at a 100%? Haven't seen that but that might be important to avoid people being "afraid" of using signing.
-
I meant the serial number (forgot that name and it is like a node id, right?). The one thats needed for e.g. whitelisting.
The documentation mentions somewhere that signing might cause errors if the radios aren't working at a 100%? Haven't seen that but that might be important to avoid people being "afraid" of using signing.
Both serial and node id is used for whitelisting.
However, only serial is generated by the personalizer (and only for software signing, atsha204a has a fixed serial).
This is the full documentation with troubleshooting section: https://ci.mysensors.org/job/Verifiers/job/MySensors/branch/development/Doxygen_HTML/group__MySigninggrp.html -
I hope to be able to file a pull request with updates to the personalizer this or next week. @LastSamurai @MLs @meddie i would really appreciate if you tested and reviewed the change so that you (and others) no longer are deterred from using signing due to its complexity. I will update the pull request until you feel confident in the procedure. I will post a link here when I have something to show for.
-
While I am working on the personalizer simplifications, perhaps you could have a look at https://www.mysensors.org/about/signing#how-to-use-this where there are (and have been all along) an explicit list of flags to enable/disable for "master" and "slave" devices. I believe this is what you were looking for @LastSamurai ?
-
While I am working on the personalizer simplifications, perhaps you could have a look at https://www.mysensors.org/about/signing#how-to-use-this where there are (and have been all along) an explicit list of flags to enable/disable for "master" and "slave" devices. I believe this is what you were looking for @LastSamurai ?
@Anticimex Oh, right that looks very helpful! Some shortcuts for these would be great anyways :)
-
@Anticimex Oh, right that looks very helpful! Some shortcuts for these would be great anyways :)
@LastSamurai I agree, and I will rename a a few concepts as well.
-
I am inclined to stick to the concept as documented instead of having "node" and "gateway" concepts as we discussed. I will still simplify the procedure.
The reason for this is that I believe it is simpler to have this procedure:- Configure personalizer to generate keys
- Reconfigure personalizer to retain and store generated keys
as opposed to
- Configure personalizer for "gateway" (to generate and store keys)
- Configure personalizer for "node" (to store retained keys)
The reason I think the first and original design is simpler is because it allows you to execute the personalizer once with one setting to obtain keys, then reconfigure the personalizer once and execute the same personalizer on ALL devices. That minimizes the risk of having misalignment in the personalized security data between the nodes. What I will do is to provide two "top-level" definitions which takes care of every setting except the setting of the retained autogenerated keys and the use of ATSHA204A or software signing. The personalizer does output the auto generated keys in a very copy+paste friendly manner so it is not difficult to set these.
The only thing which need to be different between nodes/gateways is the serial (if soft signing is used) so that will always be randomly generated (unless one specifically reconfigure the personalizer to use a specific serial).Thoughts on this? I am still open for input as it is you that are the users :)
EDIT: I will have four "top-level" flags, so you select ATSHA or soft variant at the top level. -
I am inclined to stick to the concept as documented instead of having "node" and "gateway" concepts as we discussed. I will still simplify the procedure.
The reason for this is that I believe it is simpler to have this procedure:- Configure personalizer to generate keys
- Reconfigure personalizer to retain and store generated keys
as opposed to
- Configure personalizer for "gateway" (to generate and store keys)
- Configure personalizer for "node" (to store retained keys)
The reason I think the first and original design is simpler is because it allows you to execute the personalizer once with one setting to obtain keys, then reconfigure the personalizer once and execute the same personalizer on ALL devices. That minimizes the risk of having misalignment in the personalized security data between the nodes. What I will do is to provide two "top-level" definitions which takes care of every setting except the setting of the retained autogenerated keys and the use of ATSHA204A or software signing. The personalizer does output the auto generated keys in a very copy+paste friendly manner so it is not difficult to set these.
The only thing which need to be different between nodes/gateways is the serial (if soft signing is used) so that will always be randomly generated (unless one specifically reconfigure the personalizer to use a specific serial).Thoughts on this? I am still open for input as it is you that are the users :)
EDIT: I will have four "top-level" flags, so you select ATSHA or soft variant at the top level.@Anticimex That sounds really nice to me. I would also (if thats possible without breaking something in the code) move these new flags and the settings for the HMAC (and everything else that needs to be inserted) to the top of the sketch, so that if you stay with the "default" settings you don't need to scroll down. Just for easy of use and for beginners.
Great timing from you btw: I am in the process of switching the controller anyways and will redo some of my nodes too. Now I can incorporate signing (and perhaps encryption) too.
-
@Anticimex That sounds really nice to me. I would also (if thats possible without breaking something in the code) move these new flags and the settings for the HMAC (and everything else that needs to be inserted) to the top of the sketch, so that if you stay with the "default" settings you don't need to scroll down. Just for easy of use and for beginners.
Great timing from you btw: I am in the process of switching the controller anyways and will redo some of my nodes too. Now I can incorporate signing (and perhaps encryption) too.
@LastSamurai I am pretty much rewriting the entire personalizer. So I am glad to have a motivated test team at hand ;)
Ease of use is prio1 with flexibility coming in second. -
There is a pull request now for a new personalizer. Please try it. It might still be a few issues, but I need more test coverage.
https://github.com/mysensors/MySensors/pull/794
