software AES encryption for NRF24



  • Hey there!

    I really wanted my over-the-air data to be encrypted. As I have a powermeter sensor, I basically broadcast detailed energy usage-statistics, which is a bit more privat than temperatures.
    The encryption is done with a copy of the MyTransportNRF24.h library. This copy is named MyTransportNRF24ENC.h All the data that is sent and received is encrypted respectively decrypted.
    Check it out:
    https://github.com/fleinze/MySensors/tree/Encryption/libraries/MySensors
    To use it you need to replace the MyTransportNRF24.h with MyTransportNRF24ENC.h and the MyTransportNRF24-constructor with MyTransportNRF24ENC.
    If you want to try it yourself please download all files, because it is based on a fork I use.
    For encryption the AES-library of spaniakos is used:
    https://github.com/spaniakos/AES

    The encryption uses an additional 3400 bytes of flash, so it could get a bit tight for an ethernet-gateway.

    This encryption is a all-or-nothing thing. You can't mix encrypted and unencrypted nodes. OTA-update is not possible with this, because the bootloader expects unencrypted messages.

    Identical messages create identical encrypted messages. To prevent a replay attack you need to use message signing.


  • Contest Winner

    Interesting stuff! But I suppose the routing would be sketchy if one of the nodes listens in and can't do decryption, right? In any case, it should be possible to take this into the library as a #define:able feature for those who use rf24 and can live with the drawbacks in memory and strict uniformity.


  • Contest Winner

    In any case it is great work! And @hek is getting impressive results with library refactoring so it might be possible to squeeze this in an ethernet gw as well. Possibly with signing added for better entropy. 👍


  • Admin

    Thanks @fleinze .

    I'll add it (but enabling it using defines).


  • Contest Winner

    Since we now have the potential to do AES encryption in SW, will consider adding support for atmels AES crypto chip as well so we get an hw option similar to the atsha204 so we get symmetry. SW AES is vulnerable to memory dumps since the key would be stored in flash (similar to SW signing and also the AES support in rf69). Bugger, I who thought I finally could begin focusing on my own sensor network 🙂
    @fleinze, perhaps you would consider looking into that? I would imagine a lot of similarities in design with atsha204 but since it is symmetrical crypto, personalization and SW would be much less complicated than the signing. I don't know if nonce would be meaningful to bother with since one could just add signature to the messages to get that like you said.


  • Admin

    Ok, added here: https://github.com/mysensors/Arduino/commit/5c39f022c0db5e0280be1c1412f51be7d435cd60

    Let's look at the worst-case gateway

    ENC28J60 gateway without encryption enabled

    Sketch uses 25,648 bytes (79%) of program storage space. Maximum is 32,256 bytes.
    Global variables use 1,169 bytes (57%) of dynamic memory, leaving 879 bytes for local variables. Maximum is 2,048 bytes.

    ENC28J60 gateway with encryption enabled

    Sketch uses 29,078 bytes (90%) of program storage space. Maximum is 32,256 bytes.
    Global variables use 1,502 bytes (73%) of dynamic memory, leaving 546 bytes for local variables. Maximum is 2,048 bytes.

    To use it in sketch, do something like this (note gateway-refactoring-branch):

    // Enable and select radio type attached
    #define MY_RADIO_NRF24
    #define MY_RF24_ENABLE_ENCRYPTION
    #define MY_RF24_ENCRYPTKEY 0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x10,0x11,0x12,0x13,0x14,0x15,0x16
    
    #include <MySensor.h>  
    
    #define CHILD_ID 1  
    MyMessage msg(CHILD_ID, V_TRIPPED);
    
    void setup()  
    { 
      sendSketchInfo("Motion Sensor", "1.0");
      pinMode(DIGITAL_INPUT_SENSOR, INPUT);     
      present(CHILD_ID, S_MOTION);
    }
    
    void loop()  
    { 
      boolean tripped = digitalRead(DIGITAL_INPUT_SENSOR) == HIGH; 
      send(msg.set(tripped?"1":"0"));  // Send tripped value to gw 
      sleep(INTERRUPT,CHANGE, SLEEP_TIME);
    }
    

  • Contest Winner

    Cool. What happens if you also add SW signing. To make it a really "bad" case?


  • Admin

    ENC + encrytion + soft-signing fails 😞

    Sketch uses 34,244 bytes (106%) of program storage space. Maximum is 32,256 bytes.
    Global variables use 1,912 bytes (93%) of dynamic memory, leaving 136 bytes for local variables. Maximum is 2,048 bytes.


  • Contest Winner

    Well, it is the worst possible case. Perhaps hw signing fits.


  • Hardware Contributor

    actually, I prefer usb but it could fit easily in mysensors wifi gateway..
    nice work!



  • Wow, thank you all for your overwhelming feedback!
    @Anticimex: in your first reply you asked about routing. This is not a problem, as all nodes share the same encryption key and the whole packet is decrypted by any relay node, handled and re-encrypted. As the relay node changes the first byte of data, some extra entropy is added as well.
    I decided to encrypt the whole packets because AES has 16byte block size which works good with the 32byte size limit of the NRF-packets. Just encrypting the payload on the other hand would limit the payload-size to 16bytes.

    I also took a look at the ATAES132-chip. The chip offers AES-CCM for encryption and authentification. Using the DECRYPT command on the chip we would need to provide a valid 16-byte MAC-key (which is calculated using the encrypted data and other authenticate-only data bytes). If we don't want to change the protocol to add encrypted MAC-exchange for each packet this is not an option.
    The chip also offers a LEGACY-command which is supposed to be used for encryption and decryption. Normally encryption and decryption are different operations, so I still need to find out what the LEGACY-command does.


  • Contest Winner

    @fleinze yes, exactly. My point was that (like you said) ALL nodes in the network have to support encryption/decryption if it is to work beyond strict ad-hoc communication.
    Regarding the Atmel chip, yes that is something to think about. I don't have the bandwidth to fix that myself within reasonable time right now but as long as the keys are properly protected, I do think legacy support is adequate. But like you I have not looked into that further. The way I see it, the signing system takes care of that part, and encryption can be added to add obfuscation to the process.
    Also, to me it is important that SW and HW alternatives are interchangeable and that mean the encryption MAC stuff has to be ported in SW as well and the things start spiralling out of hand. And ideally, it should be compatible with the rf69 encryption scheme as well which I believe is the same as "Atmel legacy" and your SW approach here.


  • Admin

    Interesting thing that atmel chip. It seems that it's a direct replacement for the onboard flash chip used on the sensebender, pin wise that is. As it's an eeprom, commands might be different than the ones we use for the flash now.


  • Contest Winner

    @tbowmo Yes, I also noticed that. Made me space out thinking about the possibilities to replace the SPI flash we currently use for one of the bootloaders OTA solution. And legacy encryption might be so cheap it will fit the bootloader as well as I believe all IO commands to the chip uses the same basic read/write operations so adding a decryption call of a message would not cost may bytes if the IO functions are there anyway.
    It would also mean it is a drop-in replacement for the memory in your upcoming gw as well as my upcoming sensorboard 🙂 And although I don't have the time to indulge myself too much in implementation for the moment, just knowing that it won't require a new PCB is encouraging. And it might also perhaps encourage someone with the time to spare who happened to have a sensebender to do a little rework and test it out 🙂 And if nothing else, I might do it myself eventually. But don't expect it for 2015, and perhaps not even 2016 😞 I am then leaving the country and will set up shop in your hood 🙂 and after the dust settles I can start MySensoring more seriously hopefully.


  • Hardware Contributor

    Compiling AES with an ESP8266 fails. I had to change AES_config.h (in drivers/AES):

    #include <pgmspace.h>

    instead of

    #include <avr/pgmspace.h>


  • Admin

    @FotoFieber said:

    Compiling AES with an ESP8266 fails. I had to change AES_config.h (in drivers/AES):

    #include <pgmspace.h>

    instead of

    #include <avr/pgmspace.h>

    Thanks, I'll fix.


  • Hardware Contributor

    @hek

    @hek said:

    ENC + encrytion + soft-signing fails 😞

    Sketch uses 34,244 bytes (106%) of program storage space. Maximum is 32,256 bytes.
    Global variables use 1,912 bytes (93%) of dynamic memory, leaving 136 bytes for local variables. Maximum is 2,048 bytes.

    Yesterday I made a setup with a ESP8266 gateway and a mega2560 as a secure relay actuator with encryption and signing. There are quite small mega2560 but a sensbender mega2560 would be desireable. 🙂

    ENC + encryption + soft signing is working! ☺


  • Contest Winner

    @FotoFieber with a SenseBender, there is no reason for soft signing. It should have a ATSHA204A chip. But nice that you have working setup 🙂


  • Hardware Contributor

    @Anticimex said:

    @FotoFieber with a SenseBender, there is no reason for soft signing. It should have a ATSHA204A chip. But nice that you have working setup 🙂

    Yes, but encryption and ATSHA204A is to big for the SenseBender... 😞


  • Contest Winner

    @FotoFieber ah. Bummer 😞



  • @FotoFieber said:

    @Anticimex said:

    @FotoFieber with a SenseBender, there is no reason for soft signing. It should have a ATSHA204A chip. But nice that you have working setup 🙂

    Yes, but encryption and ATSHA204A is to big for the SenseBender... 😞

    Old thread, but... In the dev branch, there's a RF24 refactor that is much smaller. With that, and removing test-mode, there's plenty of space on the sensebender:

    #define MY_RADIO_NRF24
    #define MY_SIGNING_ATSHA204
    #define MY_SIGNING_REQUEST_SIGNATURES
    #define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0xBO,0xGU,0xSK,0xEY,0xZZ,0xFC,0xAD,0x04,0xD1}}}
    #define MY_OTA_FIRMWARE_FEATURE
    #define MY_RF24_ENABLE_ENCRYPTION

    Sketch uses 23,196 bytes (75%) of program storage space. Maximum is 30,720 bytes.
    Global variables use 1,386 bytes (67%) of dynamic memory, leaving 662 bytes for local variables. Maximum is 2,048 bytes.

    Even with debug it's only at 91%.

    My W5100 gateway ends up at 107% with AES though, but it fits (with 592 bytes to spare) if I use a static address instead of DHCP.
    Serial Gateway ends up at only 65%.



  • @ximinez RF24 refactor - do you mean RF24 inside the MySensors folder? I tried it but still out of luck:

    Sketch uses 31,396 bytes (102%) of program storage space. Maximum is 30,720 bytes.
    Global variables use 1,762 bytes (86%) of dynamic memory, leaving 286 bytes for local variables. 
    

  • Contest Winner

    @alexsh1 from development branch, not master. 2.0.0-beta. Rf24 driver on that branch has been significantly optimized (together with other parts of the library).



  • @Anticimex Thanks for heads up - I think I messed up different versions though I remember unpacking "Arduino-development". I deleted the whole folder and unzipped the files again and voila:

    Sketch uses 28,228 bytes (91%) of program storage space. Maximum is 30,720 bytes.
    Global variables use 1,462 bytes (71%) of dynamic memory, leaving 586 bytes for local variables. Maximum is 2,048 bytes.
    

    UPDATE: It turned out DEBUG took a lot of memory (DEBUG AND SIGNING DEBUG)


  • Hardware Contributor

    @alexsh1
    @Anticimex

    Just tried

    #define MY_RADIO_NRF24
    #define MY_SIGNING_SOFT
    #define MY_SIGNING_REQUEST_SIGNATURES
    #define MY_RF24_ENABLE_ENCRYPTION
    

    This was working in the old dev branch but doesn't work for me anymore. Did you have luck with the combination of signing and encryption?

    n׌�Ox>�XܚMZ������t��ֵ���<��
    �=�a�WY=��VP����E�P�pStarting repeater (RNNRAS, 2.0.0)
    TSM:INIT
    TSM:RADIO:OK
    TSP:ASSIGNID:OK (ID=15)
    TSM:FPAR
    TSP:MSG:SEND 15-15-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
    TSP:MSG:READ 0-0-15 s=255,c=3,t=8,pt=1,l=1,sg=0: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=15)
    TSM:UPL
    TSP:PING:SEND (dest=0)
    Skipping security for command 3 type 24
    !TSP:MSG:SEND 15-15-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=fail:1
    TSP:MSG:READ 0-0-15 s=255,c=3,t=25,pt=1,l=1,sg=0:1
    Skipping security for command 3 type 25
    TSP:MSG:PONG RECV (hops=1)
    TSP:CHKUPL:OK
    TSM:UPL:OK
    TSM:READY
    Signing required
    Skipping security for command 3 type 15
    !TSP:MSG:SEND 15-15-0-0 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=1,st=fail:0101
    Failed to transmit signing presentation!Waiting for GW to send signing preferences...
    TSP:MSG:READ 0-0-15 s=255,c=3,t=15,pt=6,l=2,sg=0:0101
    Skipping security for command 3 type 15
    Mark node 0 as one that require signed messages
    Mark node 0 as one that do not require whitelisting
    Skipping security for command 3 type 16
    !TSP:MSG:SEND 15-15-0-0 s=255,c=3,t=16,pt=0,l=0,sg=0,ft=2,st=fail:
    Failed to transmit nonce request!
    !TSP:MSG:SIGN fail
    Skipping security for command 3 type 16
    !TSP:MSG:SEND 15-15-0-0 s=255,c=3,t=16,pt=0,l=0,sg=0,ft=4,st=fail:
    Failed to transmit nonce request!
    !TSP:MSG:SIGN fail
    TSP:MSG:READ 0-0-15 s=255,c=3,t=17,pt=6,l=25,sg=0:972DE10483D0864680CE821987E5823ABAEF8435F971670F04
    Skipping security for command 3 type 17
    Nonce received from 0. Proceeding with signing...
    Signing backend: ATSHA204Soft
    Message to process: 0F00060310FF
    Current nonce: 972DE10483D0864680CE821987E5823ABAEF8435F971670F04AAAAAAAAAAAAAA
    HMAC: 7922F4E571510EC46BD3CAAF37A1C1627BAE2562BA0ADC210173076854649826
    Signature in message: 0122F4E571510EC46BD3CAAF37A1C1627BAE2562BA0ADC2101
    Message signed
    TSP:MSG:READ 0-0-15 s=255,c=3,t=17,pt=6,l=25,sg=0:59321F17D680FFDC461270BD2C22F77FBC6FF6DE90DD9A34E6
    Skipping security for command 3 type 17
    Nonce received from 0. Proceeding with signing...
    Signing backend: ATSHA204Soft
    Message to process: 0F00060310FF
    Current nonce: 59321F17D680FFDC461270BD2C22F77FBC6FF6DE90DD9A34E6AAAAAAAAAAAAAA
    HMAC: 09031876715AD7ADBC81671982D07A46122D564110C59880AB733AACB111289E
    Signature in message: 01031876715AD7ADBC81671982D07A46122D564110C59880AB
    Message signed
    Skipping security for command 3 type 16
    !TSP:MSG:SEND 15-15-0-0 s=255,c=3,t=16,pt=0,l=0,sg=1,ft=6,st=fail:
    Failed to transmit nonce request!
    !TSP:MSG:SIGN fail
    Skipping security for command 3 type 16
    !TSP:MSG:SEND 15-15-0-0 s=255,c=3,t=16,pt=0,l=0,sg=1,ft=8,st=fail:
    Failed to transmit nonce request!
    !TSP:MSG:SIGN fail
    TSP:MSG:READ 0-0-15 s=255,c=3,t=17,pt=6,l=25,sg=1:24AB30408F0D10A7DB4CE357B22C908ED2438638C567DF52AE
    Skipping security for command 3 type 17
    Nonce received from 0. Proceeding with signing...
    Signing backend: ATSHA204Soft
    Message to process: 0F00060310FF
    Current nonce: 24AB30408F0D10A7DB4CE357B22C908ED2438638C567DF52AEAAAAAAAAAAAAAA
    HMAC: C2B0487B88AD8AE2FD7FB63C21E841324ED48975681EB881A7EC556D74637B33
    Signature in message: 01B0487B88AD8AE2FD7FB63C21E841324ED48975681EB881A7
    Message signed
    TSP:MSG:READ 0-0-15 s=255,c=3,t=17,pt=6,l=25,sg=1:4CDF80D7AAF5358B4DA616FBB1556569F68818F331C6C681F3
    Skipping security for command 3 type 17
    Nonce received from 0. Proceeding with signing...
    Signing backend: ATSHA204Soft
    Message to process: 0F00060310FF
    Current nonce: 4CDF80D7AAF5358B4DA616FBB1556569F68818F331C6C681F3AAAAAAAAAAAAAA
    HMAC: C12B5B8BD5EA6DD142908FBB02A06933E3FFBC399876B8B52E30BA9A1A66B4FC
    Signature in message: 012B5B8BD5EA6DD142908FBB02A06933E3FFBC399876B8B52E
    Message signed
    Skipping security for command 3 type 16
    !TSP:MSG:SEND 15-15-0-0 s=1,c=3,t=16,pt=0,l=0,sg=1,ft=10,st=fail:
    Failed to transmit nonce request!
    !TSP:MSG:SIGN fail
    !TSM:UPL FAIL, SNP
    TSM:FPAR
    TSP:MSG:SEND 15-15-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
    TSP:MSG:READ 0-0-15 s=255,c=3,t=17,pt=6,l=25,sg=1:0EEFA88D4FB45539A0B20C586D989BF510FC83F270ABEC3E2A
    Skipping security for command 3 type 17
    Nonce received from 0. Proceeding with signing...
    Signing backend: ATSHA204Soft
    Message to process: 0F0006031001
    Current nonce: 0EEFA88D4FB45539A0B20C586D989BF510FC83F270ABEC3E2AAAAAAAAAAAAAAA
    HMAC: 2AEEC1974BF5ED7DE100A555DD98E420E5CA0C33918F8BEFF3524B1FED047C52
    Signature in message: 01EEC1974BF5ED7DE100A555DD98E420E5CA0C33918F8BEFF3
    Message signed
    TSP:MSG:READ 0-0-15 s=255,c=3,t=8,pt=1,l=1,sg=0:0
    Skipping security for command 3 type 8
    TSP:MSG:FPAR RES (ID=0, dist=0)
    TSP:MSG:PAR OK (ID=0, dist=1)
    !TSP:SEND:TNR
    !TSP:SEND:TNR
    !TSP:SEND:TNR
    !TSP:SEND:TNR
    TSM:FPAR:OK
    TSM:ID
    TSM:CHKID:OK (ID=15)
    TSM:UPL
    TSP:PING:SEND (dest=0)
    Skipping security for command 3 type 24
    !TSP:MSG:SEND 15-15-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=fail:1
    TSP:MSG:READ 0-0-15 s=255,c=3,t=25,pt=1,l=1,sg=0:1
    Skipping security for command 3 type 25
    TSP:MSG:PONG RECV (hops=1)
    TSP:CHKUPL:OK
    TSM:UPL:OK
    TSM:READY
    Request registration...
    Skipping security for command 3 type 26
    !TSP:MSG:SEND 15-15-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=1,st=fail:2
    TSP:MSG:READ 0-0-15 s=255,c=3,t=16,pt=0,l=0,sg=0:
    Skipping security for command 3 type 16
    Signing backend: ATSHA204Soft
    SHA256: 23DD90319EEA644480F44B15B3A95D6B20AD8380A953D40C7600000000000000
    Skipping security for command 3 type 17
    !TSP:MSG:SEND 15-15-0-0 s=255,c=3,t=17,pt=6,l=25,sg=0,ft=2,st=fail:23DD90319EEA644480F44B15B3A95D6B20AD8380A953D40C76
    Failed to transmit nonce!
    TSP:MSG:READ 0-0-15 s=255,c=3,t=27,pt=1,l=1,sg=1:1
    Signature in message: 011EA3852B9E54EF00F415B0A6121E25B32B9C5F976A090B
    Message to process: 000F0E231BFF01
    Current nonce: 23DD90319EEA644480F44B15B3A95D6B20AD8380A953D40C76AAAAAAAAAAAAAA
    HMAC: 611EA3852B9E54EF00F415B0A6121E25B32B9C5F976A090BF2C96E0C02F28D72
    Signature OK
    Node registration=1
    Init complete, id=15, parent=0, distance=1, registration=1
    Skipping security for command 3 type 16
    !TSP:MSG:SEND 15-15-0-0 s=2,c=3,t=16,pt=0,l=0,sg=1,ft=3,st=fail:
    Failed to transmit nonce request!
    !TSP:MSG:SIGN fail
    TSP:MSG:READ 0-0-15 s=255,c=3,t=17,pt=6,l=25,sg=1:AA800D53018F5EAFCD48C21D3F702501539BFE5DF7E008B204
    Skipping security for command 3 type 17
    Nonce received from 0. Proceeding with signing...
    Signing backend: ATSHA204Soft
    Message to process: 0F0006031002
    Current nonce: AA800D53018F5EAFCD48C21D3F702501539BFE5DF7E008B204AAAAAAAAAAAAAA
    HMAC: 2E1247A4A77CA0767BFD16B9A1FCE401EF39B4D76FA6A96EF0978CE322271A6F
    Signature in message: 011247A4A77CA0767BFD16B9A1FCE401EF39B4D76FA6A96EF0
    Message signed
    Skipping security for command 3 type 16
    !TSP:MSG:SEND 15-15-0-0 s=3,c=3,t=16,pt=0,l=0,sg=1,ft=5,st=fail:
    Failed to transmit nonce request!
    !TSP:MSG:SIGN fail
    TSP:MSG:READ 0-0-15 s=255,c=3,t=17,pt=6,l=25,sg=1:358C0D190097ABD8AB64BF680AF252EAC6036B73222A854502
    Skipping security for command 3 type 17
    Nonce received from 0. Proceeding with signing...
    Signing backend: ATSHA204Soft
    Message to process: 0F0006031003
    Current nonce: 358C0D190097ABD8AB64BF680AF252EAC6036B73222A854502AAAAAAAAAAAAAA
    HMAC: 4A209EA1B12FB01659122DD26F2F3FB7EC15439DDEFEA90813AA0E8F87321683
    Signature in message: 01209EA1B12FB01659122DD26F2F3FB7EC15439DDEFEA90813
    Message signed
    Ping: 60 cm
    Skipping security for command 3 type 16
    !TSP:MSG:SEND 15-15-0-0 s=1,c=3,t=16,pt=0,l=0,sg=1,ft=7,st=fail:
    Failed to transmit nonce request!
    !TSP:MSG:SIGN fail
    TSP:MSG:READ 0-0-15 s=255,c=3,t=17,pt=6,l=25,sg=1:0677F380706F11E12CFC0C43FE9559F36D8FDAEB6854836E06
    Skipping security for command 3 type 17
    Nonce received from 0. Proceeding with signing...
    Signing backend: ATSHA204Soft
    Message to process: 0F0006031001
    Current nonce: 0677F380706F11E12CFC0C43FE9559F36D8FDAEB6854836E06AAAAAAAAAAAAAA
    HMAC: 5E895658E4C08BCE1D6B5FC560D1AA608AB2AEDF9385EA80ABA1EDD8EE003EE5
    Signature in message: 01895658E4C08BCE1D6B5FC560D1AA608AB2AEDF9385EA80AB
    Message signed
    Send button 1 pressed
    Skipping security for command 3 type 16
    !TSP:MSG:SEND 15-15-0-0 s=4,c=3,t=16,pt=0,l=0,sg=1,ft=9,st=fail:
    Failed to transmit nonce request!
    !TSP:MSG:SIGN fail
    !TSM:UPL FAIL, SNP
    TSM:FPAR
    TSP:MSG:SEND 15-15-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
    TSP:MSG:READ 0-0-15 s=255,c=3,t=17,pt=6,l=25,sg=1:EE3BFA6BFDD922BB892AC9A1BF2079803D8C3C258B18DFA29B
    Skipping security for command 3 type 17
    Nonce received from 0. Proceeding with signing...
    Signing backend: ATSHA204Soft
    Message to process: 0F0006031004
    Current nonce: EE3BFA6BFDD922BB892AC9A1BF2079803D8C3C258B18DFA29BAAAAAAAAAAAAAA
    HMAC: 7BEF3C478AD984729ED9A2717575A5325E66EF4C0CC9D3D761A1886A4BF4C4FD
    Signature in message: 01EF3C478AD984729ED9A2717575A5325E66EF4C0CC9D3D761
    Message signed
    TSP:MSG:READ 0-0-15 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)
    !TSP:SEND:TNR
    TSM:FPAR:OK
    TSM:ID
    TSM:CHKID:OK (ID=15)
    TSM:UPL
    TSP:PING:SEND (dest=0)
    Skipping security for command 3 type 24
    !TSP:MSG:SEND 15-15-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=fail:1
    TSP:MSG:READ 0-0-15 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
    Send button 1 pressed
    Skipping security for command 3 type 16
    !TSP:MSG:SEND 15-15-0-0 s=4,c=3,t=16,pt=0,l=0,sg=1,ft=1,st=fail:
    Failed to transmit nonce request!
    !TSP:MSG:SIGN fail
    TSP:MSG:READ 0-0-15 s=255,c=3,t=17,pt=6,l=25,sg=1:9069C5ABD4E3E13F19A92D0B708ABB41C809B6D67654357C61
    Skipping security for command 3 type 17
    Nonce received from 0. Proceeding with signing...
    Signing backend: ATSHA204Soft
    Message to process: 0F0006031004
    Current nonce: 9069C5ABD4E3E13F19A92D0B708ABB41C809B6D67654357C61AAAAAAAAAAAAAA
    HMAC: 01CCD77E9CC961B65E896180243DAB5E9174C0B88032D38261ED78BB619A00EF
    Signature in message: 01CCD77E9CC961B65E896180243DAB5E9174C0B88032D38261
    Message signed
    Skipping security for command 3 type 16
    !TSP:MSG:SEND 15-15-0-0 s=2,c=3,t=16,pt=0,l=0,sg=1,ft=3,st=fail:
    Failed to transmit nonce request!
    !TSP:MSG:SIGN fail
    TSP:MSG:READ 0-0-15 s=255,c=3,t=17,pt=6,l=25,sg=1:1B94EC3D5354C0431C3D49CEC8903433984E2DE5D04F2D00DD
    Skipping security for command 3 type 17
    Nonce received from 0. Proceeding with signing...
    Signing backend: ATSHA204Soft
    Message to process: 0F0006031002
    Current nonce: 1B94EC3D5354C0431C3D49CEC8903433984E2DE5D04F2D00DDAAAAAAAAAAAAAA
    HMAC: D46DFC8ACCEE0FA7E6D282E8556F9EC7659804AD3D33163E9522F7769449F809
    Signature in message: 016DFC8ACCEE0FA7E6D282E8556F9EC7659804AD3D33163E95
    Message signed
    Ping: 61 cm
    Ping: 60 cm
    Ping: 60 cm
    TSP:MSG:READ 12-12-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
    TSP:MSG:BC
    TSP:MSG:FPAR REQ (sender=12)
    TSP:PING:SEND (dest=0)
    Skipping security for command 3 type 24
    !TSP:MSG:SEND 15-15-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=5,st=fail:1
    TSP:MSG:READ 0-0-15 s=255,c=3,t=25,pt=1,l=1,sg=0:1
    Skipping security for command 3 type 25
    TSP:MSG:PONG RECV (hops=1)
    TSP:CHKUPL:OK
    TSP:MSG:GWL OK
    TSP:MSG:SEND 15-15-12-12 s=255,c=3,t=8,pt=1,l=1,sg=0,ft=6,st=ok:1
    Ping: 60 cm
    
    

  • Contest Winner

    Not sure if it is a typo or now but you list
    #define MY_SIGNING_ASOFT but it should be #define MY_SIGNING_SOFT

    In any case, you get st=fail which mean your radio setup is basically not working.
    For any security to work, messages has to get through, and from your log, they don't:
    "Failed to transmit signing presentation!"
    "Failed to transmit nonce request!"
    So I think from the log that signing and encryption is working, but occasionally you get messages dropped due to a poor radio link which manifests itself as failed transmissions.



  • If implemented correctly, AES is AES; the output between two different implementations is identical, and therefore no distinction is possible in after-the-fact comparison -- if done correctly, the one is exactly the same as the other.

    But there are a few points where differences can crop in:

    Operation Mode
    Truecrypt implements a modified counter mode called XTS. It's pretty well vetted and has withstood some serious abuse from some powerful attackers (such as the US Government).

    From examining the p7zip source code, it appears that AES encoding for the 7-zip format operates in CBC mode. This is certainly not necessarily insecure; it's the mode most popularly used in protocols such as TLS, but it is potentially vulnerable to padding oracle attacks. See this discussion on operation modes for more information.

    Key Derivation
    Truecrypt uses PBKDF2 to turn your password into an encryption key. It's difficult to come up with a better alternative than that. p7zip uses a salted SHA256 hash repeated over a configurable number of iterations. PBKDF2 is a bit more configurable, but 7-zip's alternative is functionally similar and arguably reaches the same goals.


  • Hardware Contributor

    @Anticimex
    Sorry for the typo.

    Interestingly, the sketch is working perfect without signing.

    I will try to add another power source and try again.

    Do you have a working setup with encryption and signing?


  • Contest Winner

    @FotoFieber When you use signing, the max message size is used, and this strains the rf link the most. Signing is still not your problem. It is clear from the log that messages fail to transmit, and that is a radio problem.



  • @Anticimex @FotoFieber

    We have been through this a few times. Just a suggestion - shall we do an FAQ link explaining what you have just said (st=fail is a problem of radio and not singing). Ingerestingly enough I did not manage to resolve this issue with the Sensebender. I still get several fail to transmit nonce before it starts working fine. Only the Sensebender. All other nodes work flawlessly


  • Contest Winner

    @alexsh1 It is already documented where all signing is documented:
    https://ci.mysensors.org/job/Verifiers/job/MySensorsArduino/branch/master/Doxygen_HTML/group__MySigninggrp.html

    Check the troubleshooting section for details. Link to all documentation is on the github frontpage and on the "head" post of the signing topic on this forum.



  • @Anticimex OK, that's super. I think we all became victims of nrf24l01+ terrible fake copies. Some of these work OK until....
    Then a woodoo dance has to be performed (highly recommended) in order to make them work again.


  • Contest Winner

    @alexsh1 Don't forget the goat sacrifice


  • Hardware Contributor

    I have tried a different setups now

    • Arduino Mega2560, Arduino Uno
    • different NRF modules from different vendors, with and withoud amplifier, with different capacitors
    • different power supplies

    I always end up getting st-fail, even with encryption only. But it is working even with these fails... 😄

    @Anticimex
    You have a working setup with encrpytion and the actual libraries from github without st-fail?

    Next tests:

    • change NRF and power supply on the gateway
    • and if all that doesn't help: make a setup without encryption

  • Contest Winner

    @FotoFieber No, I have no set up at all for the moment. But I have been using both encryption and signing yes. And I can tell you again (and again and again) that st=fails has nothing to do with signing or encryption. Unless you don't use the same AES key for your nodes because if the message is encrypted, it is jibberish to the receiver and NRF does not natively support encryption so I don't thinnk it will be able to ack properly. I trust you are sure you have your keys properly configured per the instructions for version 2.0.0?


  • Hardware Contributor

    @Anticimex
    I have a very reduced sketch now (sending millis() every second) and yes, I have configured the keys as it should be.

    As long, as nobody can prove with a concrete setup, that with the actual git-version (with encryption and NRF24L01) it is working without st-fail, the possibility exists, that it there is a bug. 😄


  • Contest Winner

    @FotoFieber No. At least not for signing. As st=fail is something set by the transport/radio layer and signing has nothing to do with that. Encryption I discourage from using (detailed in the documentation) since it provides little benefit in the form used here.


  • Hardware Contributor

    @Anticimex
    As the bug is there even with encryption only, it can't be in the signing code.

    For privacy concerns, signing is no solution.


  • Contest Winner

    @FotoFieber Neither is encryption for NRF24 as it does not use IV:s. And the data you encrypt is predicable so the key can be derived quite easily, effectively eliminating the "protection" the encryption is supposed to give.


  • Hardware Contributor

    @Anticimex
    No IV? Then the AES Transport implementation is not secure, more ore less an obfuscation...

    Is this a known bug, that will be fixed?


  • Contest Winner

    @FotoFieber it is a known limitation and is currently not in scope for improvement for nrf24 because it require reliable sync which nrf radios are notoriously bad at providing. If you have an idea on how to fix it, a pr is always welcome 🙂


  • Hardware Contributor

    Hm, I am not an encryption expert. What about a Diffie-Hellmann key exchange and then use the key as IV?


  • Contest Winner

    Me neither. I care about security, not obscurity. I see no reason to encrypt a '1' or a '0' and digital streams like audio and video is not supported anyway. But exchange of constant (but random) data is already used and supported since signing is based on nonce exchange. But I believe IV:s "evolve" with the messages encrypted which implies the messages need to be exchanged trustworthy and sender and receiver need to be om sync. But I know to little about that to be sure.
    In any case, I welcome any development that adds to security, and will happily review such code, but I don't have the bandwidth nor motivation to "drive" the development of encryption in the core library as I don't feel it adds enough value to be worth the effort.


 

409
Online

7.9k
Users

8.8k
Topics

93.8k
Posts