Encryption, Signing and OTA is there any how-to?



  • Hi,

    i would like to place any sensors at my home, but it should be signed and encrypted. On the website are a lot of builds but noone describes how to setup the encryption and signing.
    OTA too.

    is there something like a how-to or a description how to setup?
    Thanks a lot!


  • Admin

    Check out "The Next Step" here:
    https://www.mysensors.org/about



  • ok, i did read this three times but i dont understand.



  • if i understood it correctly, i have to use the securitypersonalization.ino on the gw. For the first time i upload this code

    /**
     * @def LOCK_CONFIGURATION
     * @brief Uncomment this to enable locking the configuration zone.
     *
     * It is still possible to change the key, and this also enable random key generation.
     * @warning BE AWARE THAT THIS PREVENTS ANY FUTURE CONFIGURATION CHANGE TO THE CHIP
     */
    #define LOCK_CONFIGURATION
    
    /**
     * @def LOCK_DATA
     * @brief Uncomment this to enable locking the data zone.
     *
     * It is not required to lock data, key cannot be retrieved anyway, but by locking
     * data, it can be guaranteed that nobody even with physical access to the chip,
     * will be able to change the key.
     * @warning BE AWARE THAT THIS PREVENTS THE KEY TO BE CHANGED
     */
    //#define LOCK_DATA
    
    /**
     * @def SKIP_KEY_STORAGE
     * @brief Uncomment this to skip key storage (typically once key has been written once)
     */
    #define SKIP_KEY_STORAGE
    
    /**
     * @def USER_KEY
     * @brief Uncomment this to skip key generation and use @ref user_key_data as key instead.
     */
    //#define USER_KEY
    
    /**
     * @def SKIP_UART_CONFIRMATION
     * @brief Uncomment this for boards that lack UART
     *
     * @b Important<br> No confirmation will be required for locking any zones with this configuration!
     * Also, key generation is not permitted in this mode as there is no way of presenting the generated key.
     */
    //#define SKIP_UART_CONFIRMATION
    
    /**
     * @def USE_SOFT_SIGNING
     * @brief Uncomment this to store data to EEPROM instead of ATSHA204A
     */
    //#define USE_SOFT_SIGNING
    
    /**
     * @def STORE_SOFT_KEY
     * @brief Uncomment this to store soft HMAC key to EEPROM
     */
    //#define STORE_SOFT_KEY
    
    /**
     * @def USER_SOFT_KEY
     * @brief Uncomment this to skip soft HMAC key generation and use @ref user_soft_key_data as HMAC key instead.
     */
    //#define USER_SOFT_KEY
    
    /**
     * @def STORE_SOFT_SERIAL
     * @brief Uncomment this to store soft serial to EEPROM
     */
    //#define STORE_SOFT_SERIAL
    
    /**
     * @def USER_SOFT_SERIAL
     * @brief Uncomment this to skip soft serial generation and use @ref user_soft_serial as serial instead.
     */
    //#define USER_SOFT_SERIAL
    
    /**
     * @def STORE_AES_KEY
     * @brief Uncomment this to store AES key to EEPROM
     */
    //#define STORE_AES_KEY
    
    /**
     * @def USER_AES_KEY
     * @brief Uncomment this to skip AES key generation and use @ref user_aes_key as key instead.
     */
    //#define USER_AES_KEY
    
    

    When its uploaded on first run i will get the AES and HMAC Key, which i have to notice and safe securely.

    Then i have to upload the sketch again with this code:

    /**
     * @def LOCK_CONFIGURATION
     * @brief Uncomment this to enable locking the configuration zone.
     *
     * It is still possible to change the key, and this also enable random key generation.
     * @warning BE AWARE THAT THIS PREVENTS ANY FUTURE CONFIGURATION CHANGE TO THE CHIP
     */
    #define LOCK_CONFIGURATION
    
    /**
     * @def LOCK_DATA
     * @brief Uncomment this to enable locking the data zone.
     *
     * It is not required to lock data, key cannot be retrieved anyway, but by locking
     * data, it can be guaranteed that nobody even with physical access to the chip,
     * will be able to change the key.
     * @warning BE AWARE THAT THIS PREVENTS THE KEY TO BE CHANGED
     */
    //#define LOCK_DATA
    
    /**
     * @def SKIP_KEY_STORAGE
     * @brief Uncomment this to skip key storage (typically once key has been written once)
     */
    //#define SKIP_KEY_STORAGE
    
    /**
     * @def USER_KEY
     * @brief Uncomment this to skip key generation and use @ref user_key_data as key instead.
     */
    #define USER_KEY
    
    /**
     * @def SKIP_UART_CONFIRMATION
     * @brief Uncomment this for boards that lack UART
     *
     * @b Important<br> No confirmation will be required for locking any zones with this configuration!
     * Also, key generation is not permitted in this mode as there is no way of presenting the generated key.
     */
    #define SKIP_UART_CONFIRMATION
    
    /**
     * @def USE_SOFT_SIGNING
     * @brief Uncomment this to store data to EEPROM instead of ATSHA204A
     */
    //#define USE_SOFT_SIGNING
    
    /**
     * @def STORE_SOFT_KEY
     * @brief Uncomment this to store soft HMAC key to EEPROM
     */
    //#define STORE_SOFT_KEY
    
    /**
     * @def USER_SOFT_KEY
     * @brief Uncomment this to skip soft HMAC key generation and use @ref user_soft_key_data as HMAC key instead.
     */
    //#define USER_SOFT_KEY
    
    /**
     * @def STORE_SOFT_SERIAL
     * @brief Uncomment this to store soft serial to EEPROM
     */
    //#define STORE_SOFT_SERIAL
    
    /**
     * @def USER_SOFT_SERIAL
     * @brief Uncomment this to skip soft serial generation and use @ref user_soft_serial as serial instead.
     */
    //#define USER_SOFT_SERIAL
    
    /**
     * @def STORE_AES_KEY
     * @brief Uncomment this to store AES key to EEPROM
     */
    #define STORE_AES_KEY
    
    /**
     * @def USER_AES_KEY
     * @brief Uncomment this to skip AES key generation and use @ref user_aes_key as key instead.
     */
    //#define USER_AES_KEY
    
    #if defined(SKIP_UART_CONFIRMATION) && !defined(USER_KEY)
    #error You have to define USER_KEY for boards that does not have UART
    #endif
    
    #ifdef USER_KEY
    /** @brief The user-defined HMAC key to use for personalization */
    #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
    /** @brief The data to store in key slot 0 */
    const uint8_t user_key_data[32] = {MY_HMAC_KEY};
    #endif
    
    #ifdef USER_SOFT_KEY
    /** @brief The user-defined soft HMAC key to use for EEPROM personalization */
    #define MY_SOFT_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
    /** @brief The data to store as soft HMAC key in EEPROM */
    const uint8_t user_soft_key_data[32] = {MY_SOFT_HMAC_KEY};
    #endif
    
    #ifdef USER_SOFT_SERIAL
    /** @brief The user-defined soft serial to use for EEPROM personalization */
    #define MY_SOFT_SERIAL 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
    /** @brief The data to store as soft serial in EEPROM */
    const uint8_t user_soft_serial[9] = {MY_SOFT_SERIAL};
    #endif
    
    #ifdef USER_AES_KEY
    /** @brief The user-defined AES key to use for EEPROM personalization */
    #define MY_AES_KEY 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
    /** @brief The data to store as AES key in EEPROM */
    const uint8_t user_aes_key[16] = {MY_AES_KEY};
    #endif
    
    

    in the second code i have to place the Keys which i got on first run.

    after this i can upload the normally gateway sketch

    is that correct?
    thank you very much


  • Hardware Contributor

    @meddie said in Encryption, Signing and OTA is there any how-to?:

    if i understood it correctly, i have to use the securitypersonalization.ino on the gw. For the first time i upload this code
    When its uploaded on first run i will get the AES and HMAC Key, which i have to notice and safe securely.

    Then i have to upload the sketch again with this code:
    in the second code i have to place the Keys which i got on first run.
    after this i can upload the normally gateway sketch

    is that correct?
    thank you very much

    As far as I understand it you can generate and safe the keys in one run (not 100% sure about that) on the gateway. Afterwards you install the normal gateway sketch.
    And you also have to use the personalizer sketch on every node to add the HMAC/AES keys.

    This is really a topic where we need an easier step-by-step tutorial imho. Perhaps once I find the time for it I'll experiment some more and write such a guide myself (will take some time though).



  • @meddie

    Hello, I have also begun to look at the hardware lock with ATSHA204.

    When you generate the key, you do so with SecurityPersonalizer.ino

    https://forum.mysensors.org/topic/6019/sensebender-gateway-and-atsha204

    //Mattias


  • Contest Winner

    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

    Personally, I think it is I who do not understand really. and then is afraid to start by destroying the hardware

    //Mattias


  • Hardware Contributor

    @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.


  • Contest Winner

    @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.


  • Hardware Contributor

    @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)!


  • Contest Winner

    @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?


  • Contest Winner

    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.


  • Hardware Contributor

    @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.


  • Contest Winner

    @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.


  • Hardware Contributor

    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.


  • Contest Winner

    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



  • @Anticimex

    Ofcourse

    //Mattias


  • Contest Winner

    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 ?


  • Hardware Contributor

    @Anticimex Oh, right that looks very helpful! Some shortcuts for these would be great anyways :)


Log in to reply
 

Looks like your connection to MySensors Forum was lost, please wait while we try to reconnect.