💬 Security & Signing


  • Admin

    This thread contains comments for the article "Security & Signing" posted on MySensors.org.


  • Hardware Contributor

    Hi,

    i have a little bit problem to understand the Signing System. May Be an language Problem.

    If i want to use HW-Signing it is nessesary to use a ATSHA Chip on booth Systems (Gateway and Nodes)? Or is it possible to use ATSHA on the Node side (with REQUEST SIGNING) and set "MY_SINGING_SOFT" on the Gateway?

    In the last case it does not work. . . may be somthink wrong in my sketch.

    My Test-Sketch (Node)

    /**
     * The MySensors Arduino library handles the wireless radio link and protocol
     * between your home built sensors/actuators and HA controller of choice.
     * The sensors forms a self healing radio network with optional repeaters. Each
     * repeater and gateway builds a routing tables in EEPROM which keeps track of the
     * network topology allowing messages to be routed to nodes.
     *
     * Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
     * Copyright (C) 2013-2015 Sensnology AB
     * Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors
     *
     * Documentation: http://www.mysensors.org
     * Support Forum: http://forum.mysensors.org
     *
     * This program is free software; you can redistribute it and/or
     * modify it under the terms of the GNU General Public License
     * version 2 as published by the Free Software Foundation.
     *
     *******************************
     *
     * DESCRIPTION
     *
     * Example sketch showing how to send in DS1820B OneWire temperature readings back to the controller
     * http://www.mysensors.org/build/temp
     */
    
    
    // Enable debug prints to serial monitor
    #define MY_DEBUG 
    #define MY_DEBUG_VERBOSE_SIGNING
    
    // Enable and select radio type attached
    #define MY_RADIO_NRF24
    #define MY_RF24_PA_LEVEL RF24_PA_MAX
    #define MY_BAUD_RATE 115200
    #define MY_NODE_ID 50
    #define MY_RF24_CHANNEL 105
    //#define MY_SIGNING_SOFT
    #define MY_SIGNING_ATSHA204
    #define MY_SIGNING_ATSHA204_PIN 17
    #define MY_SIGNING_REQUEST_SIGNATURES
    
    
    #include <SPI.h>
    #include <MySensors.h>  
    #include <DallasTemperature.h>
    #include <OneWire.h>
    
    #define COMPARE_TEMP 1 // Send temperature only if changed? 1 = Yes 0 = No
    
    #define ONE_WIRE_BUS 4 // Pin where dallase sensor is connected 
    #define MAX_ATTACHED_DS18B20 16
    unsigned long SLEEP_TIME = 30000; // Sleep time between reads (in milliseconds)
    OneWire oneWire(ONE_WIRE_BUS); // Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs)
    DallasTemperature sensors(&oneWire); // Pass the oneWire reference to Dallas Temperature. 
    float lastTemperature[MAX_ATTACHED_DS18B20];
    int numSensors=0;
    bool receivedConfig = false;
    bool metric = true;
    // Initialize temperature message
    MyMessage msg(0,V_TEMP);
    
    void before()
    {
      // Startup up the OneWire library
      sensors.begin();
    }
    
    void setup()  
    { 
      // requestTemperatures() will not block current thread
      sensors.setWaitForConversion(false);
    }
    
    void presentation() {
      // Send the sketch version information to the gateway and Controller
      sendSketchInfo("Gartenhaus", "1.0");
    
      // Fetch the number of attached temperature sensors  
      numSensors = sensors.getDeviceCount();
    
      // Present all sensors to controller
      for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {   
         present(i, S_TEMP);
      }
    }
    
    void loop()     
    {     
      // Fetch temperatures from Dallas sensors
      sensors.requestTemperatures();
    
      // query conversion time and sleep until conversion completed
      int16_t conversionTime = sensors.millisToWaitForConversion(sensors.getResolution());
      // sleep() call can be replaced by wait() call if node need to process incoming messages (or if node is repeater)
      //sleep(conversionTime);
    
      // Read temperatures and send them to controller 
      for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {
    
        // Fetch and round temperature to one decimal
        float temperature = static_cast<float>(static_cast<int>((getConfig().isMetric?sensors.getTempCByIndex(i):sensors.getTempFByIndex(i)) * 10.)) / 10.;
    
        // Only send data if temperature has changed and no error
        #if COMPARE_TEMP == 1
        if (lastTemperature[i] != temperature && temperature != -127.00 && temperature != 85.00) {
        #else
        if (temperature != -127.00 && temperature != 85.00) {
        #endif
    
          // Send in the new temperature
          send(msg.setSensor(i).set(temperature,1));
          // Save new temperatures for next compare
          lastTemperature[i]=temperature;
        }
      }
      //sleep(SLEEP_TIME);
    }
    

    My Test-Sketch Gateway:

     /**
     * The MySensors Arduino library handles the wireless radio link and protocol
     * between your home built sensors/actuators and HA controller of choice.
     * The sensors forms a self healing radio network with optional repeaters. Each
     * repeater and gateway builds a routing tables in EEPROM which keeps track of the
     * network topology allowing messages to be routed to nodes.
     *
     * Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
     * Copyright (C) 2013-2015 Sensnology AB
     * Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors
     *
     * Documentation: http://www.mysensors.org
     * Support Forum: http://forum.mysensors.org
     *
     * This program is free software; you can redistribute it and/or
     * modify it under the terms of the GNU General Public License
     * version 2 as published by the Free Software Foundation.
     *
     *******************************
     *
     * DESCRIPTION
     * The ArduinoGateway prints data received from sensors on the serial link.
     * The gateway accepts input on seral which will be sent out on radio network.
     *
     * The GW code is designed for Arduino Nano 328p / 16MHz
     *
     * Wire connections (OPTIONAL):
     * - Inclusion button should be connected between digital pin 3 and GND
     * - RX/TX/ERR leds need to be connected between +5V (anode) and digital pin 6/5/4 with resistor 270-330R in a series
     *
     * LEDs (OPTIONAL):
     * - To use the feature, uncomment any of the MY_DEFAULT_xx_LED_PINs
     * - RX (green) - blink fast on radio message recieved. In inclusion mode will blink fast only on presentation recieved
     * - TX (yellow) - blink fast on radio message transmitted. In inclusion mode will blink slowly
     * - ERR (red) - fast blink on error during transmission error or recieve crc error
     *
     */
    
    // Enable debug prints to serial monitor
    #define MY_DEBUG
    
    
    // Enable and select radio type attached
    #define MY_RADIO_NRF24
    
    // Set LOW transmit power level as default, if you have an amplified NRF-module and
    // power your radio separately with a good regulator you can turn up PA level.
    #define MY_RF24_PA_LEVEL RF24_PA_MAX
    
    // Enable serial gateway
    #define MY_GATEWAY_SERIAL
    
    // Define a lower baud rate for Arduino's running on 8 MHz (Arduino Pro Mini 3.3V & SenseBender)
    #define MY_BAUD_RATE 115200
    #define MY_NODE_ID 200
    #define MY_RF24_CHANNEL 105
    #define MY_SIGNING_SOFT
    
    // Enable inclusion mode
    #define MY_INCLUSION_MODE_FEATURE
    #define MY_INCLUSION_MODE_DURATION 60
    
    #include <MySensors.h>
    
    void setup() {
      // Setup locally attached sensors
    }
    
    void presentation() {
     // Present locally attached sensors
    }
    
    void loop() {
      // Send locally attached sensor data here
    }
    

    Log File from my Node:

    Starting sensor (RNNNAA, 2.0.0)
    TSM:INIT
    TSM:RADIO:OK
    TSP:ASSIGNID:OK (ID=50)
    TSM:FPAR
    TSP:MSG:SEND 50-50-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
    TSP:MSG:READ 0-0-50 s=255,c=3,t=8,pt=1,l=1,sg=1:0
    Skipping security for command 3 type 8
    TSP:MSG:FPAR RES (ID=0, dist=0)
    TSP:MSG:PAR OK (ID=0, dist=1)
    TSM:FPAR:OK
    TSM:ID
    TSM:CHKID:OK (ID=50)
    TSM:UPL
    TSP:PING:SEND (dest=0)
    TSP:MSG:SEND 50-50-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=ok:1
    TSP:MSG:READ 0-0-50 s=255,c=3,t=25,pt=1,l=1,sg=1:1
    Skipping security for command 3 type 25
    TSP:MSG:PONG RECV (hops=1)
    TSP:CHKUPL:OK
    TSM:UPL:OK
    TSM:READY
    Signing required
    TSP:MSG:SEND 50-50-0-0 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=ok:0101
    Waiting for GW to send signing preferences...
    TSP:MSG:READ 0-0-50 s=255,c=3,t=15,pt=6,l=2,sg=0:0100
    Skipping security for command 3 type 15
    Mark node 0 as one that do not require signed messages
    Mark node 0 as one that do not require whitelisting
    TSP:MSG:SEND 50-50-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=ok:2.0.0
    TSP:MSG:SEND 50-50-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=ok:0
    TSP:MSG:SEND 50-50-0-0 s=255,c=3,t=11,pt=0,l=10,sg=0,ft=0,st=ok:Gartenhaus
    TSP:MSG:SEND 50-50-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=ok:1.0
    TSP:MSG:SEND 50-50-0-0 s=0,c=0,t=6,pt=0,l=0,sg=0,ft=0,st=ok:
    Request registration...
    TSP:MSG:SEND 50-50-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=ok:2
    TSP:MSG:READ 0-0-50 s=255,c=3,t=16,pt=0,l=0,sg=1:
    Skipping security for command 3 type 16
    Signing backend: ATSHA204
    SHA256: C218FD3906EE8FB300A7E3537C21E2F28655A522DEC5AAAD30810E7AADB3285F
    TSP:MSG:SEND 50-50-0-0 s=255,c=3,t=17,pt=6,l=25,sg=0,ft=0,st=ok:C218FD3906EE8FB300A7E3537C21E2F28655A522DEC5AAAD30
    Transmitted nonce
    TSP:MSG:READ 0-0-50 s=255,c=3,t=27,pt=1,l=1,sg=1:1
    Signature in message: 01BA5BD0193F0E5B474833E395DFA6C08715EA4E462A9EA2
    Message to process: 00320E231BFF01
    Current nonce: C218FD3906EE8FB300A7E3537C21E2F28655A522DEC5AAAD30AAAAAAAAAAAAAA
    HMAC: 737DE7BFBB721A51D231D02D2606DA19CB0F4E7EE04634DC21D19C3F90F791FD
    Signature bad: 017DE7BFBB721A51D231D02D2606DA19CB0F4E7EE04634DC
    Signature verification failed!
    !TSP:MSG:SIGN verify fail
    Init complete, id=50, parent=0, distance=1, registration=1
    

  • Hardware Contributor

    Hi,

    Did you check the SOFT_HMAC_KEY in your gateway with the skecth SecurityPersonalizer.ino ?
    He must be the same at the HMAC node.


  • Hardware Contributor

    @tonnerre33 Thanks, i solved it already, but you are right that was my Problem :-)



  • I have ordered 10 HTSHA chips for my system and have a question about using them with the pi.....Do I need to add the ATSHA chip to the raspberry pi gateway (with nrf24l01+ directly attached)? If so how to wire it up? If not, how does it work?

    Thanks! ;)



  • Hi everybody :)
    Where I find information step by step how to run signing/security with one sensor and raspbery pi gateway and use mqtt (software signing without chip ATSHA)? I try understand this post, but I have problem.. I test example code but always my gw get normal information..


  • Contest Winner



  • @Anticimex I read all text and I understand that I have add forth line to all my sensors.:
    #define MY_SIGNING_SOFT
    #define MY_SIGNING_SOFT_RANDOMSEED_PIN 7
    #define MY_SIGNING_REQUEST_SIGNATURES
    #define MY_SIGNING_NODE_WHITELISTING {{.nodeId = MOTION_SENSOR_ID,.serial = {0x12,0x34,0x56,0x78,0x90,0x12,0x34,0x56,0x78}}}

    In my gateway i must use this comand:
    ./configure --my-gateway=mqtt --my-controller-ip-address=127.0.0.1 --my-mqtt-publish-topic-prefix=mysensors-out --my-mqtt-subscribe-topic-prefix=mysensors-in --my-mqtt-client-id=mygateway1 --my-signing=software --my-signing-debug --my-signing-request-gw-signatures-from-all --my-mqtt-password=PASSWORD --my-mqtt-user=USER

    1. but I do not understand wher I create white list in gateway?
    2. how create serial for my mensors (eg. {0x12,0x34,0x56,0x78,0x90,0x12,0x34,0x56,0x78})?
    3. how to check if everything is working?
    4. how to use HMAC (how to create in my sensor, where save)?

  • Contest Winner

    @macvictor the raspberry specific things you need to check with @marceloaqno about, the other questions really are all answered in the link I sent.



  • @Anticimex Ok. I read again this text. I have next question..

    1. I generated SOFT_HMAC_KEY, SOFT_SERIAL, AES_KEY in my gateway, so when I run SecurityPersonalizer.ino i must save this value from gw in MY_SOFT_HMAC_KEY, MY_SOFT_SERIAL, MY_AES_KEY or generate other value and save? Probably AES must by the same.. MY_SOFT_SERIAL is 'serial' in WHITELISTING so i think this must by different in node and gateway, and what with HMAC? I think that the HMAC must be the same..
    2. I looked for information where save whitelist in gw but i didn't found.. can you help my find solution?
    3. If I use for example 2 nodes-relays, 2 nodes-temperature and gateway. All relays communicate only with gateway but all are repeater. All node-temperature sensor connect with relay, so in nodes-relay in white list i must add temperature serial and gw serial. In temperature I does't add white list, in gateway I add relay and temperature nodes serial. That is all?

    PS. Thank you for you help :)


  • Contest Winner

    @macvictor

    1. Quotes from the documentation (link I sent):
      "In case you want to be able to "whitelist" trusted nodes (in order to be able to revoke them in case they are lost) you also need to take note of the serial number of the ATSHA device or the software value stored in EEPROM. This is unique for each device."
      "That mean that all nodes in your network share the same PSK" (this goes for both HMAC and AES (if you use encryption)).
    2. There is no difference. You specify your whitelists the same way in both gateway and nodes. Of course you have to have different whitelists but the format and way of storage is identical.
    3. All signing is end to end. Your nodes communicate with your gateway. It does not matter if they are relayed 50 times on the way to the gateway. Therefore, whitelists in gateway and node use the serial from the other part (gateway or node).
      Your relays are also nodes. If you send data explicitly to these nodes, you also need the serial for those (if you want signed communication with them) but your temp sensors and your gateway talk to each other. Signing does not care about relays.
      So you do NOT need to add gw and temperature serials to your node-relays just to have your gw and temperature sensors communicate with each other. You do not even have to enable signing in your relays. They are (possibly) just that; relays.
      Of course, this mean that you have to have your gw serial in your temperature node whitelist, and vice versa (if you use two way signing).


  • Hi Guys,
    Long time reader and first time poster.
    Now a general disclaimer, I'm only fairly new to the IoT world of home automation sensors and am looking at the crypto side of signing devices as I thought if I'm going to do it, I'm going to do it right from the start with signing and utilizing OTA abilities.

    I have a quick question regarding the ATSHA204 component. I know that the SenseBender uses a ATSHA204-STUCZ (the Single-Wire interface config) but I can't get these sourced through my normal supplier.

    I am able to source ATSHA204A-SSHDA-B though, and was wondering if this would work instead, even though it's an I2C interface config instead. If not, how much work is involved to get it to work?

    Thanks Heaps


  • Contest Winner

    @egadgetjnr hi and welcome to the forum! It will require some work as the current driver only handles single wire interface and the I2C support in the chip has special requirements in the bus for sleep/wake states. I don't know how much work exactly is needed but it will not be insignificant.
    Also, what sources have you checked? It should be possible to source the single write variant online without problem.



  • @Anticimex said in 💬 Security & Signing:

    Also, what sources have you checked? It should be possible to source the single write variant online without problem.

    Thanks heaps for your prompt reply!

    I've looked at Mouser and Digi-Key and they have a $60 minimum for free postage (I don't want to order 100 for free shipping at this stage obviously as I'm only prototyping) and I can't bring myself to spending $25 on shipping for around $5.00 of modules :frowning:.
    Which leaves me with my normal supplier of Element14 (formally Farnell) where I get free shipping regardless of order quantity. :wink: but they don't source the Single-Wire ones at all.

    I was going to put a post over on the OTA Flash forum as well as I'm having issues sourcing the AT25DF512C (it's been discontinued) and was looking at an ATAES132A (Datasheet <here> using an SPI interface) as I accidentally ordered some of them for another project and thought maybe it would be possible to combine both the security signing and OTA flash in the one component (Which is a HUGE assumption as to its use). As mentioned earlier, I'm still fairly new to the engineering side of hardware so I may be way off the mark.


  • Hardware Contributor

    @egadgetjnr where dit u come from?


  • Contest Winner

    @egadgetjnr Ok, well, if you are up to it, feel free to make a PR with I2C support. I do not have the bandwidth to implement that myself I am afraid, and I don't feel the gains are worth the efforts. I2C will put constraints on which pins to use, and of course it would also require two pins and not one.
    But I happily review any pull requests on the topic. If we get the support, it is just a bonus :)

    Regarding flash, it is not crucial that you get the exact same part (or even the same supplier). The important thing is that the interface is the same and that they share the same JEDEC identifier.



  • I had exactly the same issue. This UK eBay store sells them per 5. Not sure what they'll ask for sending them across the ocean.
    I got them from here (4 days from UK to NL). Got one up in my gateway and that works with a soft signing node. Should be good.



  • Just to be sure: SOFT_HMAC_KEY, SOFT_SERIAL is used for signing, AES_KEY is used for encryption. SOFT_HMAC_KEY, AES_KEY should be the same across all network nodes, SOFT_SERIAL should be different for every node?


  • Contest Winner

    @bilbolodz this is quite clearly stated in the documentation, but in short yes. But AES and HMAC key should not be the same, as the encryption is not using initialization vectors so the key can be derived from analyzing the encrypted messages by someone with the adequate knowledge.



  • I'm trying to start play with ATSHA204A signing. I've ATSHA204A-SSHCZ-T chip (8-lead SOIC single wire). I've connected chip pins: 4 - GND, 8 - VCC (5v), 5 - A3, I've added 100nF between 4 and 8 and 4K7 resistor between 5 and 8. I've loaded "near clear" SecurityPersonalizer sketch (only added #define MY_SIGNING_ATSHA204_PIN A3 #define MY_SIGNING_ATSHA204) but I've got:

    Personalization sketch for MySensors usage.

    Failed to wake device. Response: E7
    Halting!

    any ideas?


Log in to reply
 

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