Encryption, Signing and OTA is there any how-to?
-
@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 -
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@Anticimex I already download the pr... the new sketch looks very nice! I'll try it out tomorrow.
-
Seems to work just fine. The output is way cleaner and the options are easy to use imo (tried the PERSONALIZE_SOFT_RANDOM_SERIAL). One questions though:
The output gives me EEPROM and Key Storage. With different values for the Serial number. What's the difference here? -
Seems to work just fine. The output is way cleaner and the options are easy to use imo (tried the PERSONALIZE_SOFT_RANDOM_SERIAL). One questions though:
The output gives me EEPROM and Key Storage. With different values for the Serial number. What's the difference here?@LastSamurai Can you please provide the output?
The sketch will output EEPROM value first, and (in the case of PERSONALIZE_SOFT_RANDOM_SERIAL) generate a new serial which will replace the value in EEPROM. If you run the sketch without any flags set, it will just show the currently stored states. -
Haven't saved it. Will rerun it later ;) There were just different categories and one was EEPROM another was Key Storage. Inbetween was the gererated key (which was the same as in the key storage). So I guess it read the values, wrote the new ones and displayed the new ones. Might be a little confusing though. I'll try to post it later
Everything seems to be working now though with the signing enabled.
-
Haven't saved it. Will rerun it later ;) There were just different categories and one was EEPROM another was Key Storage. Inbetween was the gererated key (which was the same as in the key storage). So I guess it read the values, wrote the new ones and displayed the new ones. Might be a little confusing though. I'll try to post it later
Everything seems to be working now though with the signing enabled.
@LastSamurai EEPROM is exactly what it says; the data in EEPROM.
Key storage is the keys being stored "somewhere", it could be EEPROM (if you use soft signing) or ATSHA204A if you use that. If you execute the key generation stage, you will see "Key generation" instead of "Key storage".
The special case is the PERSONALIZE_SOFT_RANDOM_SERIAL in which you will do both key generation and key storage (but only generation for the serial). -
This is what I get:
+------------------------------------------------------------------------------------+ | MySensors security personalizer | +------------------------------------------------------------------------------------+ +------------------------------------------------------------------------------------+ | Configuration settings | +------------------------------------------------------------------------------------+ | * Guided personalization/storage of keys in EEPROM | | * Guided storage and generation of random serial in EEPROM | | * Software based personalization (no ATSHA204A usage whatsoever) | | * Will not require UART confirmation before locking ATSHA204A configuration | | * Will store HMAC key to EEPROM | | * Will store AES key to EEPROM | | * Will generate soft serial using software | | * Will store soft serial to EEPROM | +------------------------------------------------------------------------------------+ +------------------------------------------------------------------------------------+ | Hardware security peripherals | +--------------+--------------+--------------+------------------------------+--------+ | Device | Status | Revision | Serial number | Locked | +--------------+--------------+--------------+------------------------------+--------+ | AVR | DETECTED | N/A | N/A (generation required) | N/A | +--------------+--------------+--------------+------------------------------+--------+ +------------------------------------------------------------------------------------+ | EEPROM | +--------+--------+------------------------------------------------------------------+ | Key ID | Status | Key | +--------+--------+------------------------------------------------------------------+ | HMAC | OK | ... | | AES | OK | 00000000000000000000000000000000 | | SERIAL | OK | 0E0103FA44D749F163 | +--------+--------+------------------------------------------------------------------+ +------------------------------------------------------------------------------------+ | Key generation | +--------+--------+------------------------------------------------------------------+ | Key ID | Status | Key | +--------+--------+------------------------------------------------------------------+ | SERIAL | OK | 0F5B932A87D43AD318 | +--------+--------+------------------------------------------------------------------+ +------------------------------------------------------------------------------------+ | Key storage | +--------+--------+------------------------------------------------------------------+ | Key ID | Status | Key | +--------+--------+------------------------------------------------------------------+ | HMAC | OK | ... | | AES | OK | 00000000000000000000000000000000 | | SERIAL | OK | 0F5B932A87D43AD318 | +--------+--------+------------------------------------------------------------------+ +------------------------------------------------------------------------------------+ | WHAT TO DO NEXT? | +------------------------------------------------------------------------------------+ | This device has now been personalized. Run this sketch with its current settings | | on all the devices in your network that have security enabled. | +------------------------------------------------------------------------------------+ +------------------------------------------------------------------------------------+ | Execution result | +------------------------------------------------------------------------------------+ | SUCCESS | +------------------------------------------------------------------------------------+Ah ok. Still a little confusing in my opinion. Why show the key storage at all with Soft_serial? In this case the key always gets saved in the eeprom (right?). Just the "key generation" and one eeprom afterwards or one before and one after (with different names) would be clearer imo.
Just some (hopefully constructive) critisism. I still like it way more than the old system! -
This is what I get:
+------------------------------------------------------------------------------------+ | MySensors security personalizer | +------------------------------------------------------------------------------------+ +------------------------------------------------------------------------------------+ | Configuration settings | +------------------------------------------------------------------------------------+ | * Guided personalization/storage of keys in EEPROM | | * Guided storage and generation of random serial in EEPROM | | * Software based personalization (no ATSHA204A usage whatsoever) | | * Will not require UART confirmation before locking ATSHA204A configuration | | * Will store HMAC key to EEPROM | | * Will store AES key to EEPROM | | * Will generate soft serial using software | | * Will store soft serial to EEPROM | +------------------------------------------------------------------------------------+ +------------------------------------------------------------------------------------+ | Hardware security peripherals | +--------------+--------------+--------------+------------------------------+--------+ | Device | Status | Revision | Serial number | Locked | +--------------+--------------+--------------+------------------------------+--------+ | AVR | DETECTED | N/A | N/A (generation required) | N/A | +--------------+--------------+--------------+------------------------------+--------+ +------------------------------------------------------------------------------------+ | EEPROM | +--------+--------+------------------------------------------------------------------+ | Key ID | Status | Key | +--------+--------+------------------------------------------------------------------+ | HMAC | OK | ... | | AES | OK | 00000000000000000000000000000000 | | SERIAL | OK | 0E0103FA44D749F163 | +--------+--------+------------------------------------------------------------------+ +------------------------------------------------------------------------------------+ | Key generation | +--------+--------+------------------------------------------------------------------+ | Key ID | Status | Key | +--------+--------+------------------------------------------------------------------+ | SERIAL | OK | 0F5B932A87D43AD318 | +--------+--------+------------------------------------------------------------------+ +------------------------------------------------------------------------------------+ | Key storage | +--------+--------+------------------------------------------------------------------+ | Key ID | Status | Key | +--------+--------+------------------------------------------------------------------+ | HMAC | OK | ... | | AES | OK | 00000000000000000000000000000000 | | SERIAL | OK | 0F5B932A87D43AD318 | +--------+--------+------------------------------------------------------------------+ +------------------------------------------------------------------------------------+ | WHAT TO DO NEXT? | +------------------------------------------------------------------------------------+ | This device has now been personalized. Run this sketch with its current settings | | on all the devices in your network that have security enabled. | +------------------------------------------------------------------------------------+ +------------------------------------------------------------------------------------+ | Execution result | +------------------------------------------------------------------------------------+ | SUCCESS | +------------------------------------------------------------------------------------+Ah ok. Still a little confusing in my opinion. Why show the key storage at all with Soft_serial? In this case the key always gets saved in the eeprom (right?). Just the "key generation" and one eeprom afterwards or one before and one after (with different names) would be clearer imo.
Just some (hopefully constructive) critisism. I still like it way more than the old system!@LastSamurai Well, I designed it like this intentionally because I want the "experience" to be uniform.
You have selected a mode which generates a key and stores a key. So it will shows the key(s) it generates and also the key(s) it store. Key generation and key storage is normally two separate things.
You can if you so like completely customize what keys you generate and store using the "advanced" config flags.
The log is designed to show exactly what is happening.
You could if you wanted to tell it to generate a serial but not store it. Or tell it to not generate a serial but store one you have configured yourself. Hence the tables are separated. -
@LastSamurai Well, I designed it like this intentionally because I want the "experience" to be uniform.
You have selected a mode which generates a key and stores a key. So it will shows the key(s) it generates and also the key(s) it store. Key generation and key storage is normally two separate things.
You can if you so like completely customize what keys you generate and store using the "advanced" config flags.
The log is designed to show exactly what is happening.
You could if you wanted to tell it to generate a serial but not store it. Or tell it to not generate a serial but store one you have configured yourself. Hence the tables are separated.@Anticimex Well that makes sense too. I was just a little confused seeing 2 serial keys the first time. I figured it out though, so other will too ;)
Nice work though, much easier to use than the old version!When I have the time I'll try it with some other nodes in the next days.
-
@Anticimex Well that makes sense too. I was just a little confused seeing 2 serial keys the first time. I figured it out though, so other will too ;)
Nice work though, much easier to use than the old version!When I have the time I'll try it with some other nodes in the next days.
@LastSamurai thanks. Appreciate the feedback. I am going to test it on a samd device as well and if it looks OK, I'll have the core team review and approve it. Then I'll start looking at the simplified security option.
-
@LastSamurai thanks. Appreciate the feedback. I am going to test it on a samd device as well and if it looks OK, I'll have the core team review and approve it. Then I'll start looking at the simplified security option.
@Anticimex I just tested the "#define PERSONALIZE_SOFT" option with my new gateway to set serial number and HMAC key and everything seems to work just fine. I have no devices with hardware encryption (yet) so I can't test that one.
-
@Anticimex I just tested the "#define PERSONALIZE_SOFT" option with my new gateway to set serial number and HMAC key and everything seems to work just fine. I have no devices with hardware encryption (yet) so I can't test that one.
@LastSamurai hardware encryption? Well, from a personalization perspective, encryption is handled the same. AES key is always stored in eeprom so you can use encryption for nrf24 (as rfm69 is the only radio currently with a hw AES accelerator). Rfm69 still gets the key from eeprom though.
-
@LastSamurai hardware encryption? Well, from a personalization perspective, encryption is handled the same. AES key is always stored in eeprom so you can use encryption for nrf24 (as rfm69 is the only radio currently with a hw AES accelerator). Rfm69 still gets the key from eeprom though.
@Anticimex Badly formulated from me ;) What I meant is signing (+ perhaps encryption too) using the ATSHA204A instead of the software backend. All tests I have done are with the software one.
-
@Anticimex Badly formulated from me ;) What I meant is signing (+ perhaps encryption too) using the ATSHA204A instead of the software backend. All tests I have done are with the software one.
@LastSamurai Ah, no, the ATSHA204A is only for signing. You can however go "advanced" and configure the personalizer to use the ATSHA204A to generate a random AES key for encryption use. But the ATSHA204A is not involved in encryption or decryption operations.
-
The updated personalizer has now been merged to the development branch (BETA channel).
