[security] Introducing signing support to MySensors

[Anticimex]

@Zeph yes, backdoors in crypto HW will always be a concern for non open designs. However, these are probably not generally known and besides, they still require physical access to the device in question. And since my recommendation is (also after whitelisting feature is implemented) that PSK is revoked if a secure node is lost, a backdoor will get you nowhere as the security protocol as such is based on an open and widely regarded secure standard. If you are really paranoid, you simply need to weigh the hard option against the soft. The hard at least in theory protects you from revealing tour secrets, but the soft does not. But the soft option gives you more insight in the mechanisms used to generate the signatures.

[Anticimex]

@Zeph Regarding the whitening, yes, that is probably a good idea. Currently the slimmed down ATSHA driver does not implement the SHA command, but I need it anyway since it will be used for the whitelist-feature. So I can add the random improvement to both the hard and soft backend together with the whitelist stuff. I just hope I can squeeze everything down enough. The limiting device is an Ethernet GW which I believe is the "largest" (have not evaluated MQTT though).

[rvendrame]

@Anticimex

Believe it or not I discussed the topic with my wife this weekend, and she asked me if each ATSHA doesn't have a unique serial... :-S

Very good - I assume this will requires more RAM in GW (only), completely acceptable in my opinion.

I more like your option "A"

Cheers

[Anticimex]

@rvendrame Your wife is perfectly right, and I have indeed starting looking into option A. It will unfortunately break compatibility with ATSHA204, but I do believe everyone will use ATSHA204A so that should be fine. I hope to be able to fit everything into flash. The signing backend constructors will be updated to take a whitelist that the "verifying" end of a node network will provide. The whitelist feature overall will be an optional #define controlled feature since it will change the message signature, so if one half of Alice and Bob use it, the other has to as well. But since it will "cost" a bit both RAM and ROM, I prefer to have that feature optional since it is not really required for a "locked" network where all nodes are inaccessible.
And still, revoking the PSK if the network is compromised is my strong recommendation. But a "blacked-out" node will require even more effort to hack for the network to accept it.

This feature does require you to know the serial of the transmitter and it's NodeID. The serial will never be sent OTA in clear text so it is easiest obtained during personalization (it is printed on UART then). The "soft" backend will have a "fake" serial set by the "user" who hopefully makes it unique for every node. Set either through constructor or as a #define. I have not decided yet.

In any case, once I am done, the top post will be updated to include the whitelist option and how to use it.

[rvendrame]

@Anticimex , amazing. I understood your concerns with transmitting the serial number over the air --- But assuming the GW only enters in '"Inclusion mode" by pressing a physical button (or via its controller request), and it lasts only 1 minute typically --- Do you still see a big risk?

Otherwise --- On everyone new node it would require a re-flash of GW, adding the new node serial to it ? Perhaps I didn't get it in the right way...

[Anticimex]

@rvendrame
Serials are static so those are a one-shot config. The node ID is not that static, but once assigned, it is persisted in the EEPROM on the node so it is static enough I believe.
I prefer not to have any useful information sent in clear text at any point sine it is difficult to ensure that a node cannot be "enticed" to reset and retransmit data at will.
We have to remember that secure exchange does not necessarily go through a GW. In the case of keyfob -> garage door, there is no reason to relay through a GW. The keyfob could transmit to the garage-door motor directly. So relying on "inclusion" to set up secure communications is not a dependency I want to have. Any node should be able to establish signed communication with any other node. It is just a matter of the sketch used transmit the signing requrement message itself. In the GW case, the library takes care of this, but nothing prevents a node to transmit it's signing preference directly to another node in the network (such as a garage door to an associated keyfob).
So if we assume the garage door require signed messages, the keyfob then have to transmit it's serial at some point so the garage door can "learn it" (per your suggestion). So if the keyfob is stolen, that feature can be exploited to reset the garage door nodes whitelist. Therefore I do believe the garage door has to have a hard-coded whitelist which cannot possibly be changed without physical access to it.
Call me anal, but better safe than sorry
And yes, this is probably all overkill...but if we go overkill..let's do it with a vengeance. After all, anyone who thinks this is unnecessary can simply choose to not use it.

EDIT: On the topic of reflash, yes. If a receiver is to be made aware of new nodes it is expected to verify messages from, it has to be updated. But to me, that both makes sense and is desired. You never want a node to automagically start accepting messages from "unknown" nodes for whatever reason. I think a bit of convenience has to be sacrificed on that topic.

[sharath krishna]

@Anticimex really a cool thing i just wanted to know if the rasp pi version of the mysensors will also get this ? it will be very useful when we use the raspberry pi as the gateway using pigateway serial.

[Anticimex]

@sharath-krishna Thanks! The software driver has no real hardware dependency so yes, that should work. You will need to patch to patch the random number generation though.
I do not think the hardware driver really needs to be ported since a raspberry will likely not be used in an environment where it can be stolen/tampered with so extra protection of PSK and such will not really be needed.
Sorry to say, I do not have the bandwidth to support this on all hardware. I will however encourage the community to port it anyway it likes and will support as much as I can. I will try to maintain it for Arduino and am still working with strengthening it and there are a few bugs left to iron out before it can me submitted to master.

[daulagari]

@rvendrame:

• The ZWave paper you point to describes a problem implementation, not the protocol itself it seems to me:

The root cause of this issue was lack of state validation
in the key exchange protocol handler programmed in the Z-
Wave door lock firmware.

• Yes, if you lose your normal key anybody that knows to which lock it belongs can break in.
• But, if your key has no information on to which lock it belongs to the risk is small, the same is true for a remote.

[jkandasa]

@Anticimex Thanks a lot! Its a great work.
Does signature feature supports for node to node communication (I mean without gateway)?

[Anticimex]

@jkandasa thanks. Yes it does. But then you (as sketch developer) is responsible for sending the internal I_REQUEST_SIGNING message to inform the other node of your nodes signing requirements. The library manages this automatically for the node2gateway (and gateway2node) but not for node2node messages since the library "does not know" anything about that.

[C.r.a.z.y.]

@hek do you have any plan to use this logic in new version api?
@Anticimex awesome work!

[hek]

@C.r.a.z.y.

Yes, this will be part of 1.5 release.

[Anticimex]

Thanks guys! Glad to see that it's appreciated
I am now working on strengthening the nonces and implementing whitelisting. I hope to be able to finish it in time for the 1.5 release.
Voluntary testers are desired!
I will update the first post also with more instructions on how to handle whitelisting and also update it so it reflects the more recent changes on the development branch with respect to configuration as soon has I have finished the hacking.

[Anticimex]

UPDATE: Thread topic post updated with a lot of stuff. Whitelisting is now "in" and explained. Various updates to the text to make a few things more clear and some code examples added to show how this ties into the updates on development branch when it comes to construction of the library class and how signing comes into play.

[phil83]

@Anticimex This really is great work!
I have one question regarding ATSHA204A: do you know where to buy ATSHA204A-STUCZ-T? I couldn't find any supplier in Europe and even on Aliexpress, I could onlyfind the ATSHA204 in SOT23-3.

[tbowmo]

@phil83

mouser.com got it in stock, they will deliver to europe as well

[phil83]

@tbowmo Thanks for the info. I found mouser this morning as well but they charge me 20€ for shipping :-(.

[tbowmo]

@phil83

You just need to make an order big enough, then they drop the handling charge

[phil83]

Any other Europeans interested in getting some chips from mouser? I could redistribute from Germany via letter.

[Tibus]

hello, i'm making some mysensors board that I'll present you a bit later and I've add a place for the Atsha204 sot23-3.

I can't find it in Europe still and I would like to know if is it possible ton connect it on pin A6 instead of pin A3. I would like to keep the A0 to A5 for the user and use A6 for Atsha204 and A7 for Atcha204 floating point. Can anyone test it for me please?

Thank's verry much!

[Anticimex]

@Tibus No, you cant. A6 and A7 are analog-only pins. Also, make sure you order ATSHA204A. Not ATSHA204. ATSHA uses no "floating point". Just single wire digital interface.

[Tibus]

Ok, So I've to connect it on A3 (default value in mysensor?) and let the A7 floating? The A6 is not used so? (other question : I can't use digitalWrite on A6 pin?)

Thank's verry much for the details on ATSHA204A instead of ATSHA204. The ATSHA204A is in SOT23-3 too? so the A7 is only use inside the Atmega library?

[Anticimex]

@Tibus A6 and A7 are analog input pins. You can use them as such but not as digital I/O.
ATSHA204A is identical but more feature-rich compared to ATSHA204. One added feature is a SHA256 which is required for MySensors use. ATSHA204 is discontinued by Atmel. You can connect the ATSHA to any digital I/O pin you like but you will have to patch the config if you pick anything not called "A3".

[Tibus]

Ok, thank's! I've already change every A6 pin connection to A3. Can the user use A3 for analogic even if ATSHA204 is connected on it? or do I have to remove the A3 pin available for the user?

[Anticimex]

@Tibus You have to check the datasheet of ATSHA204A to see how it handles the datapin when not in use. I would recommend you have any analog cirquitry on dedicated pins though and keep one reserved for the ATSHA.

[hek]

@Anticimex

The "analog" pins can actually be used as digital IO pins.

[Anticimex]

@hek Not A6 and A7. They are pure analog.

[hek]

Ok! That's new to me

[Anticimex]

@hek @tbowmo also found this the "hard" way. There are also some other forum discussions on the topic. It is basically how the AVR is designed.

[tbowmo]

@hek @Anticimex

Yeah. I put the led on A6 in the first revision of the micro board, and used 2 hours figuring out why the led wouldn't blink it's buried somewhere in the posts in my design thread.

[mainali]

I had this concerned from beginning. I will sound like a noon, but I am working on building a custom controller with loads of user configurable interface. For sake of my understanding is there any diagram or video or any resource regarding how to interface the ATSHA204A with arduino @Anticimex .
If there is something like that it will be of a great help. I am going to post a video soon of my work in progress app which controls the devices. I am also working on a scenario where someone can use the normal switches(existing ones) to operate the device and app will update accordingly. Still making way through the ACK part and the hops as I am using Ruby to do all the work

[Anticimex]

@mainali What do you mean? It is the simplest possible interface; one IO pin. You can see schematics in @tbowmo s "Minimal design thoughts" thread or my own GW design.

[sj44k]

@mainali
Does this help you? Sometimes a few pics say more than a 1000 words

I made this pic from the Datasheet giving you the pinouts of the ATSHA204A in all known housings.

And the way how to connect is (shamelessly stolen from the GW design of @Anticimex )

[Anticimex]

@sj44k @mainali Please note that that picture is incorrect. I have it connected to A3, not A7 (it is mentioned in the thread). Also note that in my design, I use a breakout board for ATSHA so the pin numbering on my breakout does NOT correspond to the SOT23-package.

[mainali]

Thanks a lot for all the Information

[sj44k]

@Anticimex
Thanks for that info, to me it is clear that depending on the used pin in the software one should connect the ATSHA204A corresponding with the software.
Picture does show you being correct how simple it really is to embed the ATSHA204A hardware in the total setup.

[Dirk_H]

@phil83
I fear you've already ordered the ATSHA204A ? I'm also in Germany so that would be easy.
If not - I'd take 10 pcs. They cost close to nothing -> nice

@Anticimex
I don't agree with "This is an unlikely usecase because it is really no reason to sign sensor values. If you for some reason want to obfuscate sensor data, encryption is a better alternative."

I think of Sensors used for Alarm-Systems. You need to trust the sensor reading because otherwise the attacker might jam the original Sensor and send his own Sensor data to let the alarm-system think the window is still closed (e.g.).

One more question: Are the Serials in the ATSHA in ascending order (i.e. when you have a reel of ICs is each S/N old S/N+1 ?) If this is the case, would it be possible to steal a keyfob to get a valid signing device, read the serial, use that S/N +1, sign the message and get still access to the garage door? I.e. do something one could call "S/N spoofing"? (I know that it is much easier to just break the garage door with a crowbar, but I'm intrested in this - at least hypotheticaly :))

Unfourtunately I don't have much time at the moment to try it out by myself, but I'm still really excited about your work and effort!

[Anticimex]

@Dirk_H The signing solution can be applied to both sensors and gateways. If you feel the need to have the gateway require signed messages from nodes, there is nothing to prevent it. I have already thought of that scenario and implemented support for it.

Regarding jamming, no security system can prevent that.

Regarding the generation of serials, you have to contact Atmel about that. And you still need to obtain the preshared key in order to generate properly signed messages. Neither the key nor the serial is ever sent over the air in clear text.

[FotoFieber]

@Anticimex
Thank you very much for this solution.

I think your solution is the best compromise, if you don't want to transmit more data.

The drawback is, that it isn't really as secure as AES 256 or above. It is a compromise.

What about a solution

• where the original message is untouched without a signature
• a consumer requests an AES 256 signature of this message, if he really needs it
• a second/third signature message is sent to the consumer with full AES 256 signature

In this solution, you could use different keys for different nodes and the risk of stolen keys would be minimized.

[Anticimex]

@FotoFieber
I think sha256 is pretty secure enough
Regarding splitting signature and message, I am not too fond of that, because it opens up a lot of attack vectors and it also put requirements on the sender to be able to retain a sent message. Potentially a lot of nodes sends data back and forth, so what happens if, for instance, the gateway sends a message to one node, then sends another message to another node, and then the first node sends a message requesting a signature on a message the gateway no longer has. We have to remember that ram memory is very limited so there are limits in what we can do with message management, unfortunately.
But all feedback is appreciated! Thanks!

[FotoFieber]

@Anticimex
sha256 is secure enough. But if I understand the implementation correctly, you use the space at the end of the payload for the signature and not the full signature.

Another thing to consider is that the strength of the signature is inversely proportional to the payload size.

If I calculate it right, the length of the signature is less or equal (23 bytes) 184 bit.

With a payload of 4 bytes, which would probably be the usual payload I have here, there would be left only 160 bit (20 bytes).

In comparison a HMAC_SHA256 uses 256 bit,

Or did I miss something?

It could be implemented quite simple:

1. Node sends data to gateway which in my case is published to MQTT
2. some consumer likes to have this signed and sends the node the message back with a sign request
3. the node looks at the message and checks, if the value inside the message is still valid. When ok, it sends a HMAC splitted in two messages. If not, it ignores the message or sends NOK.

The problem with this implementation would be, that the node hast to be active to get the singing request.

Maybe it would be better to just send two other messages with the HMAC after the data.

I would suggest to implement the check of the HMAC where it is needed, not in the gateway, In my case, this would be node-red.

[Anticimex]

@FotoFieber
Regarding the weakened security based on the message size, you are correct.
But I still disagree on splitting the messages because it will mean that some messages will fail to be signed (depending on network load) and it is no good to have a solution that adds uncertainty in that respect. And I definitely do not want to add restrictions on which types of nodes are capable on signing and which are not. Having the gateway signing messages is a very real application in use cases like locks and such.
The opposite is also equally valid, some nodes might send "important" data. The gateway needs to be able to authenticate such nodes (keyfobs etc).
We have to weigh complexity vs resources, and currently we are pretty much at the limit of our capabilities. An ethernet or mqtt gateway running on an Arduino nano can today barely fit HW support for signing. SW signing does not fit. So we can't really get more complex with the solution without also stepping up the HW platform we execute on.

[Anticimex]

I should add that even if signature was separated in its own message, it still would not be full since the rf solution is only capable of sending 32 byte messages and some bytes are needed for routing info. So if "full" signature is required, some framing protocol will also be needed, and then things really get out of hand on a poor Arduino nano or pro mini.
I would suggest using RF69 with AES encryption if the signing scheme in place is inadequate.

[scalz]

Hi.

I am trying to design some boards. And I would like to have a little precision.
If I understand right, as signing is included in rfm69 radiohead library with mysensors, I don't need atsha? Atsha recommanded with nrf?

[Anticimex]

@scalz
Well, it depends on what you want. In the first post I have outline my stance on the matter. I prefer signing before anything. RF69 offer optional encryption, not signing. If you are happy with just encryption, then you don't need ATSHA but have to use RF69 (or another circuit).

[scalz]

@Anticimex : you are right. I confused two different things!! So I think the best is combination of both.
Thank you for your precision and for sharing your work.

[Anticimex]

@scalz
Thanks and you are welcome

[Anticimex]

@scalz
For the record, I share your opinion on using a combination. I will probably go for that myself when I fully deploy my sensornetwork. RF69 with AES encryption on RF level, and ATSHA authentication on protocol level should be enough to protect against most deliberate non-physical mischief.

[scalz]

@Anticimex : I totally agree with you. I am still defining my needs too. I have only some nrf nodes but I think Mysensors + RFM + Atsha + ota=Zwave killer! it might eliminate repeater needs.
On my designs I put nrf and rfm footprints but I think I will move to rfm as soon as I can. I will share my designs when it will be tested. Hope there will be lots of boards for mysensors in the future.
Have a good day!

[Anticimex]

@scalz
I have actually designed a board that supports both radios. I have just received them but have not mounted them with components yet so I have not been able to verify the design. But I will post it on the forum as soon as I have. It will be pin-compatible with Sensbender Micro but also support RF69. It is not intended to be replacing that board nor is it an "official" MySensor board. I have just designed it to fit my personal preferences and to serve as a generic multi-purpose sensor backend (it relies on modules and has a lot of headers to support many sensors in parallel on both 3.3 and 5V rails).

[scalz]

wow. can't wait to see your creations! Seems interesting. Your board could be very helpful.
I love Sensebender. But 0402, it was difficult to solder for me! So I am trying to use 0805 in my designs, easier for me.
I am finishing to modify a moteino (0805 so a little bigger) to add nrf and atsha. I am waiting for others boards (not received yet) : uCurrent module, one power management optimization board (based on ulpnode idea), esp8266-07 with nrf, rfm and atsha (I will try to make sort of mqtt gateway), and a mysensors relay board. I have others idea too: dimmer for one main, hb100 (for barrier security), mgc3030 (for gesture. lot of stuff on this one I think). But before I must finish what I started. Hihi, mysensors and automation is addictive!

I read in previous post that you advised not to use A6,A7 for atsha. But I imagine that I can use others pin (if i take care of datasheet of course)? I think it is doable, just have to modify pin ref in code next, isn't it? Anyway, I always try to keep mysensors reference design (A3), it is just for personal info.

[Anticimex]

@scalz
Then you'll be happy to hear that my board uses 0805 and 1206 and also has enlarged pads for hand soldering on all SMD footprints
It also features a jumper for current measurement, three power connection options, switchable regulators for super low standby currents and some other features. But I will give the details in a separate post.

[Anticimex]

@scalz
Regarding pin, yes. You can freely choose any digital IO for ATSHA. A6 and A7 are not digital IO so they cannot be used. They are pure analog.

[scalz]

Very interesting. So your board will be a great addition. I will follow your work for sure!
Thank you very much for your help.

[otto001]

Hi @all!

First off all: thanks for your great work
I am about to compile the ethernet gw with software signing, but unfortunately I am getting some compile errors.
Does anyone maybe have a sketch handy and would up it here?

Thanks in advance and best regards,

Otto

[Anticimex]

@otto001
Sorry, but that is not possible on Arduino Nano. There is not enough flash available to support both ethernet and software signing. You have to use ATSHA for an ethernet gw.

[otto001]

@Anticimex:
Thanks, but I am trying to compile it for an UNO R3?! That should do it. Nevertheless: Using nanos only for nodes should work with sw signing, shouldnt it?

[Anticimex]

@otto001
Yep. It is the ethernet stack that costs the most.
I need you to post the compiler error you get though in order to help you.

[otto001]

I used the latest devel-branch from github.

This is the error:

In file included from /home/otto/sketchbook/libraries/MySensors/MyTransportNRF24.h:26:0,
                 from /home/otto/sketchbook/libraries/MySensors/MySensor.h:28,
                 from ms_gw_neu.ino:42:
/home/otto/sketchbook/libraries/MySensors/utility/RF24.h:51:11: error: 'SOFT_SPI_MISO_PIN' was not declared in this scope
   SoftSPI<SOFT_SPI_MISO_PIN, SOFT_SPI_MOSI_PIN, SOFT_SPI_SCK_PIN, SPI_MODE> spi;
           ^
/home/otto/sketchbook/libraries/MySensors/utility/RF24.h:51:30: error: 'SOFT_SPI_MOSI_PIN' was not declared in this scope
   SoftSPI<SOFT_SPI_MISO_PIN, SOFT_SPI_MOSI_PIN, SOFT_SPI_SCK_PIN, SPI_MODE> spi;
                              ^
/home/otto/sketchbook/libraries/MySensors/utility/RF24.h:51:49: error: 'SOFT_SPI_SCK_PIN' was not declared in this scope
   SoftSPI<SOFT_SPI_MISO_PIN, SOFT_SPI_MOSI_PIN, SOFT_SPI_SCK_PIN, SPI_MODE> spi;
                                                 ^
/home/otto/sketchbook/libraries/MySensors/utility/RF24.h:51:75: error: template argument 1 is invalid
   SoftSPI<SOFT_SPI_MISO_PIN, SOFT_SPI_MOSI_PIN, SOFT_SPI_SCK_PIN, SPI_MODE> spi;
                                                                           ^
/home/otto/sketchbook/libraries/MySensors/utility/RF24.h:51:75: error: template argument 2 is invalid
/home/otto/sketchbook/libraries/MySensors/utility/RF24.h:51:75: error: template argument 3 is invalid
In file included from ms_gw_neu.ino:43:0:
/home/otto/sketchbook/libraries/MySensors/MyGateway.h:39:28: error: 'DEFAULT_CE_PIN' was not declared in this scope
   MyGateway(uint8_t _cepin=DEFAULT_CE_PIN, uint8_t _cspin=DEFAULT_CS_PIN, uint8_t _inclusion_time = 1, uint8_t _inclusion_pin = 3, uint8_t _rx=6, uint8_t _tx=5, uint8_t _er=4);
                            ^
/home/otto/sketchbook/libraries/MySensors/MyGateway.h:39:59: error: 'DEFAULT_CS_PIN' was not declared in this scope
   MyGateway(uint8_t _cepin=DEFAULT_CE_PIN, uint8_t _cspin=DEFAULT_CS_PIN, uint8_t _inclusion_time = 1, uint8_t _inclusion_pin = 3, uint8_t _rx=6, uint8_t _tx=5, uint8_t _er=4);
                                                           ^
ms_gw_neu.ino:80:31: error: no matching function for call to 'MyGateway::MyGateway(MyTransportNRF24&, MyHwATMega328&, MySigningAtsha204Soft&)'
ms_gw_neu.ino:80:31: note: candidates are:
In file included from ms_gw_neu.ino:43:0:
/home/otto/sketchbook/libraries/MySensors/MyGateway.h:39:3: note: MyGateway::MyGateway(uint8_t, uint8_t, uint8_t, uint8_t, uint8_t, uint8_t, uint8_t)
   MyGateway(uint8_t _cepin=DEFAULT_CE_PIN, uint8_t _cspin=DEFAULT_CS_PIN, uint8_t _inclusion_time = 1, uint8_t _inclusion_pin = 3, uint8_t _rx=6, uint8_t _tx=5, uint8_t _er=4);
   ^
/home/otto/sketchbook/libraries/MySensors/MyGateway.h:39:3: note:   no known conversion for argument 1 from 'MyTransportNRF24' to 'uint8_t {aka unsigned char}'
/home/otto/sketchbook/libraries/MySensors/MyGateway.h:20:7: note: MyGateway::MyGateway(const MyGateway&)
 class MyGateway : public MySensor
       ^
/home/otto/sketchbook/libraries/MySensors/MyGateway.h:20:7: note:   candidate expects 1 argument, 3 provided

and this is the sketch - I am not sure, if everything is right (I am not deep into mysensors yet):

/*
 * Copyright (C) 2013 Henrik Ekblad <henrik.ekblad@gmail.com>
 * 
 * Contribution by a-lurker
 *
 * 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 EthernetGateway sends data received from sensors to the ethernet link. 
 * The gateway also accepts input on ethernet interface, which is then sent out to the radio network.
 *
 * The GW code is designed for Arduino 328p / 16MHz.  ATmega168 does not have enough memory to run this program.
 * 
 *
 * COMPILING WIZNET (W5100) ETHERNET MODULE
 * > Edit RF24_config.h in (libraries\MySensors\utility) to enable softspi (remove // before "#define SOFTSPI").
 *
 * COMPILING ENC28J60 ETHERNET MODULE
 * > Use Arduino IDE 1.5.7 (or later) 
 * > Disable DEBUG in Sensor.h before compiling this sketch. Othervise the sketch will probably not fit in program space when downloading. 
 * > Remove Ethernet.h include below and include UIPEthernet.h 
 * > Remove DigitalIO include 
 * Note that I had to disable UDP and DHCP support in uipethernet-conf.h to reduce space. (which means you have to choose a static IP for that module)
 *
 * VERA CONFIGURATION:
 * Enter "ip-number:port" in the ip-field of the Arduino GW device. This will temporarily override any serial configuration for the Vera plugin. 
 * E.g. If you want to use the defualt values in this sketch enter: 192.168.178.66:5003
 *
 * LED purposes:
 * - 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  
 * 
 * See http://www.mysensors.org/build/ethernet_gateway for wiring instructions.
 *
 */

#include <DigitalIO.h>     // This include can be removed when using UIPEthernet module  
#include <SPI.h>  
#include <MySensor.h>
#include <MyGateway.h>  
#include <stdarg.h>
#include <MyConfig.h>
#include <MySigningAtsha204Soft.h>

// Use this if you have attached a Ethernet ENC28J60 shields  
//#include <UIPEthernet.h>  

// Use this fo WizNET W5100 module and Arduino Ethernet Shield 
#include <Ethernet.h>   


#define INCLUSION_MODE_TIME 1 // Number of minutes inclusion mode is enabled
#define INCLUSION_MODE_PIN  3 // Digital pin used for inclusion mode button

#define RADIO_CE_PIN        5  // radio chip enable
#define RADIO_SPI_SS_PIN    6  // radio SPI serial select
#define RADIO_ERROR_LED_PIN 7  // Error led pin
#define RADIO_RX_LED_PIN    8  // Receive led pin
#define RADIO_TX_LED_PIN    9  // the PCB, on board LED

#define IP_PORT 5003        // The port you want to open 
IPAddress myIp (192, 168, 1, 66);  // Configure your static ip-address here    COMPILE ERROR HERE? Use Arduino IDE 1.5.7 or later!

// The MAC address can be anything you want but should be unique on your network.
// Newer boards have a MAC address printed on the underside of the PCB, which you can (optionally) use.
// Note that most of the Ardunio examples use  "DEAD BEEF FEED" for the MAC address.
byte mac[] = { 0xCE, 0x0D, 0xBE, 0xEF, 0xFE, 0xED };  // DEAD BEEF FEED


// a R/W server on the port
EthernetServer server = EthernetServer(IP_PORT);


MyTransportNRF24 radio;  // NRFRF24L01 radio driver
MyHwATMega328 hw; // Select AtMega328 hardware profile
MySigningAtsha204Soft signer(false); // Select ATSHA204A software signing backend
MyGateway gw(radio, hw, signer);

// No blink or button functionality. Use the vanilla constructor.
// old MyGateway gw(RADIO_CE_PIN, RADIO_SPI_SS_PIN, INCLUSION_MODE_TIME);

// Uncomment this constructor if you have leds and include button attached to your gateway 
//MyGateway gw(RADIO_CE_PIN, RADIO_SPI_SS_PIN, INCLUSION_MODE_TIME, INCLUSION_MODE_PIN, RADIO_RX_LED_PIN, RADIO_TX_LED_PIN, RADIO_ERROR_LED_PIN);


char inputString[MAX_RECEIVE_LENGTH] = "";    // A string to hold incoming commands from serial/ethernet interface
int inputPos = 0;

void setup()  
{ 
  Ethernet.begin(mac, myIp);

  // give the Ethernet interface a second to initialize
  delay(1000);

  // Initialize gateway at maximum PA level, channel 70 and callback for write operations 
  gw.begin(RF24_PA_LEVEL_GW, RF24_CHANNEL, RF24_DATARATE, writeEthernet);

  // start listening for clients
  server.begin();
}

// This will be called when data should be written to ethernet 
void writeEthernet(char *writeBuffer) {
  server.write(writeBuffer);
}


void loop()
{
  // if an incoming client connects, there will be
  // bytes available to read via the client object
  EthernetClient client = server.available();

  if (client) {
      Serial.print("bytes");
      // if got 1 or more bytes
      if (client.available()) {
         // read the bytes incoming from the client
         char inChar = client.read();

         if (inputPos<MAX_RECEIVE_LENGTH-1) { 
           // if newline then command is complete
           if (inChar == '\n') {  
              // a command was issued by the client
              // we will now try to send it to the actuator
              inputString[inputPos] = 0;

              // echo the string to the serial port
              Serial.print(inputString);

              gw.parseAndSend(inputString);

              // clear the string:
              inputPos = 0;
           } else {  
             // add it to the inputString:
             inputString[inputPos] = inChar;
             inputPos++;
           }
        } else {
           // Incoming message too long. Throw away 
           inputPos = 0;
        }
      }
   }  
   gw.processRadioMessage();    
}

Thanks for your help in advance!

Otto

[Anticimex]

@otto001
Hm. Looks like you have a problem with your settings for soft SPI. The errors are not related to the signing backend.
I suspect a problem in MyConfig.h but I have not been up to speed with the changes on development nor have I dabbled with soft SPI. I run "hardware" SPI. @hek maybe knows what setting is wrong for your problem to occur. Could be that the soft SPI driver does not take UNO boards into account?

[otto001]

@Anticimex:

Thanks anyway! I will try again without signing. Maybe there is a problem in the recent devel-branch. With stable 1.4 it compiled without any issues...
/update: does not compile with the "standard" ethernet-gw sketch too.... not related to signing...

[Anticimex]

@otto001
Alright. Thanks for confirming. I had a rough period on development with the signing support when I was developing it. Other commits kept breaking it (not intentionally but because there was other changes to the init sequences and such which did not take signing into account). And I have been busy doing other things so I have not refreshed my own sketches to HEAD on development for a couple of months so I am uncertain on the working state at the moment, but I trust @hek to let me know if something breaks again
I will get back on track soon I hope but project is coming up and is sure to mess quite a bit with my schedule so I trust others to keep me informed if signing support should fail.

[franklin216]

I do not understand how to set the Backend in the myconfig.h.

"you need to decide what signing backend to use. This is done in MyConfig.h"

But how? Just by commenting out the Pin Define?

[Anticimex]

My post is not really up2date with the code at the moment (at least on development branch). You now pick you backend by argument to the MySensor constructor. I will check with @hek how we should handle this post when master and development are diverging.

[franklin216]

Thank you for your quick reply Now it is clearer to me.

[Anticimex]

Good! I will look into how the post can be clearer and handle the code specifics better with respect to both "master" and "development" where applicable. Sorry for the discrepancy

[Anticimex]

First post updated to better reflect the state of the 'development' branch. Signing is currently not available on 'master'.

[scalz]

Hi @Anticimex,

I read your first post and followed it, it was very interesting and comprehensible. So I am trying autentication to see how it looks. I entered the key in a Gateway (nano) and a mini pro node. The mini is running DHT Humidity sketch (I know it is not very interesting node for autentication but it's easy on breadboard). I am using latest dev branch. Communication seems to work but i am a little confused with serial output on GW as I see some no sign. It seems that humidity is ok, but not the temperature child.. but I am not sure.

What do you think I am doing wrong?

Edit: I am getting others nosign... Does presentation and version messages uses autentication too? because they seem to be ok but not the child sensors value..

Here is GW logs:

0;0;3;0;9;read: 10-10-0 s=255,c=3,t=15,pt=2,l=2,sg=0:1
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=15,pt=2,l=2,sg=0,st=ok:1
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:01F989B
0;0;3;0;9;read: 10-10-0 s=255,c=0,t=17,pt=0,l=6,sg=1:1.5 b1
10;255;0;0;17;1.5 b1
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:017DA4B
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=6,pt=1,l=1,sg=1:0
10;255;3;0;6;0
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:01C7E11
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=11,pt=0,l=8,sg=1:Humidity
10;255;3;0;11;Humidity
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:017B669
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=12,pt=0,l=3,sg=1:1.0
10;255;3;0;12;1.0
0;0;3;0;9;read: 10-10-0 s=0,c=0,t=7,pt=0,l=0,sg=0:
10;0;0;0;7;
0;0;3;0;9;read: 10-10-0 s=1,c=0,t=6,pt=0,l=0,sg=0:
10;1;0;0;6;
0;0;3;0;9;no sign
0;0;3;0;9;no sign

[Anticimex]

@scalz Thanks.
Could you please also post the construction code of your MySensor object.
And also your MyConfig.h changes (where you enable the signing functionality). Don't post your private key though
The initial setup is all signed and well but then your node seem to not even attempt to sign the data it sends (because it should have sent a c=3,t=16 and waited for a c=3,t=17 prior to any sensor data).
I see from the first two messages that the gateway has been informed that your sensor require signatures (of messages from the gateway). And the gateway do respond that it also require signautres but for some reason your sensor do not sign the sensor values (the presentation handshaking is transmitted in signed form as expected).
I don't have a quick answer to why your node does not sign it's sensor data. Could you also share your code that transmits (in your sketch that is). Perhaps the easiest is to post the entire sketch (WITHOUT your private key).

I am afraid I have to prioritize my newborn son, so I hope for understanding if my replies will be delayed. @hek might know if something has happened on dev branch that could affect signing. I did thoroughly test it when it was submitted but I have not been keeping track on activities on dev for a while now.

[scalz]

@Anticimex: Congratulation for your son! it is not hurry, no problem. and thank you for taking time.
So maybe I am missing something, because I have no key in the sketch??? I am using ATSHA hardware chip.. The key is stored by using SHAPersonalizer, isn't it??

I have not made any changes in Myconfig.h as it is default enabled. So it is like this:

// Disable to completly disable signing functionality in library
#define MY_SIGNING_FEATURE

And the node sketch:

#include <SPI.h>
#include <MyTransportNRF24.h>
#include <MyHwATMega328.h>
#include <MySensor.h> 
#include <DHT.h>  
#include <MySigningAtsha204.h>

#define CHILD_ID_HUM 0
#define CHILD_ID_TEMP 1
#define HUMIDITY_SENSOR_DIGITAL_PIN 5
unsigned long SLEEP_TIME = 30000; // Sleep time between reads (in milliseconds)

MyTransportNRF24 radio;  // NRFRF24L01 radio driver
MyHwATMega328 hw; // Select AtMega328 hardware profile
MySigningAtsha204 signer; // Select HW ATSHA signing backend
MySensor gw(radio, hw, signer);

DHT dht;
float lastTemp;
float lastHum;
boolean metric = true; 
MyMessage msgHum(CHILD_ID_HUM, V_HUM);
MyMessage msgTemp(CHILD_ID_TEMP, V_TEMP);


void setup()  
{ 
  gw.begin(NULL, 10);
  dht.setup(HUMIDITY_SENSOR_DIGITAL_PIN); 

  // Send the Sketch Version Information to the Gateway
  gw.sendSketchInfo("Humidity", "1.0");

  // Register all sensors to gw (they will be created as child devices)
  gw.present(CHILD_ID_HUM, S_HUM);
  gw.present(CHILD_ID_TEMP, S_TEMP);
  
  metric = gw.getConfig().isMetric;
}

void loop()      
{  
  delay(dht.getMinimumSamplingPeriod());

  float temperature = dht.getTemperature();
  if (isnan(temperature)) {
      Serial.println("Failed reading temperature from DHT");
  } else if (temperature != lastTemp) {
    lastTemp = temperature;
    if (!metric) {
      temperature = dht.toFahrenheit(temperature);
    }
    gw.send(msgTemp.set(temperature, 1));
    Serial.print("T: ");
    Serial.println(temperature);
  }
  
  float humidity = dht.getHumidity();
  if (isnan(humidity)) {
      Serial.println("Failed reading humidity from DHT");
  } else if (humidity != lastHum) {
      lastHum = humidity;
      gw.send(msgHum.set(humidity, 1));
      Serial.print("H: ");
      Serial.println(humidity);
  }

  gw.sleep(SLEEP_TIME); //sleep a bit
}

and in Serial Gateway, I have only changed this:

// Message signing driver (signer needed if MY_SIGNING_FEATURE is turned on in MyConfig.h)
//MySigningNone signer;
//MySigningAtsha204Soft signer;
MySigningAtsha204 signer;

// Hardware profile 
MyHwATMega328 hw;

// Construct MySensors library (signer needed if MY_SIGNING_FEATURE is turned on in MyConfig.h)
// To use LEDs blinking, uncomment WITH_LEDS_BLINKING in MyConfig.h
#ifdef WITH_LEDS_BLINKING
MySensor gw(transport, hw , signer, RADIO_RX_LED_PIN, RADIO_TX_LED_PIN, RADIO_ERROR_LED_PIN);
#else
MySensor gw(transport, hw , signer);
#endif

[Anticimex]

@scalz Thanks
Correct. With HW ATSHA204A no key in the sketch is necessary.
And your setup seem ok since there are signed messages being passed successfully so the HW seem ok.

Perhaps you could add a debug print that dumps your messages in the gateway before they are checked for signatures in MySensor::process?
Just put debug(PSTR("read: %d-%d-%d s=%d,c=%d,t=%d,pt=%d,l=%d,sg=%d\n"), msg.sender, msg.last, msg.destination, msg.sensor, mGetCommand(msg), msg.type, mGetPayloadType(msg), mGetLength(msg), mGetSigned(msg)); before #ifdef MY_SIGNING_FEATURE.
You could also do the corresponding thing in your nodes MySensor::sendRoute function so we can see what data you send in order to determine why your node has decided it should not be signed.

It could be you stumbled over a library bug because I see in the code that in sendRoute the if case looks funky.
It says:
if (DO_SIGN(message.destination) && message.sender == nc.nodeId && !mGetAck(message) && mGetLength(msg) &&
but I think it should say
if (DO_SIGN(message.destination) && message.sender == nc.nodeId && !mGetAck(message) && mGetLength(message) &&
Try to change this and see what happens. I have a strong suspicion that your node's msg buffer is empty, and sendRoute therefore don't sign the message because it gets the length from the wrong buffer.

@hek if @scalz tests this successfully, could you patch it? I think it is a bug that it checks mGetLength(msg) and not mGetLength(message) in MySensor::sendRoute.

[hek]

@Anticimex
I could probably fix it tonight if it turns out wrong.

[scalz]

@Anticimex @Hek
Thank you very much for debugging!
First, I tried to add the debug watch. And like you said it seems there was no value.
Then, I looked at sendRoute like you advised, and oh!, it makes sense. A tiny small bug is living there !
So I changed mGetLength(msg) with mGetLength(message)
And now... it seems to work well! yeah! I am so happy

If you want below is my GW logs (with the debug watch too), but I think it's ok now. there is no unwanted "nosign" anymore.

0;0;3;0;9;gateway started, id=0, parent=0, distance=0
0;0;3;0;14;Gateway startup complete.
0;0;3;0;9;read: 0-0-0 s=0,c=0,t=0,pt=0,l=0,sg=0
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=15,pt=2,l=2,sg=0:1
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=15,pt=2,l=2,sg=0,st=ok:1
0;0;3;0;9;read: 0-0-10 s=255,c=3,t=15,pt=2,l=2,sg=0
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:01F428B
0;0;3;0;9;read: 0-0-10 s=255,c=3,t=17,pt=6,l=25,sg=0
0;0;3;0;9;read: 10-10-0 s=255,c=0,t=17,pt=0,l=6,sg=1:1.5 b1
10;255;0;0;17;1.5 b1
0;0;3;0;9;read: 10-10-0 s=255,c=0,t=17,pt=0,l=6,sg=0
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:013E014
0;0;3;0;9;read: 0-0-10 s=255,c=3,t=17,pt=6,l=25,sg=0
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=6,pt=1,l=1,sg=1:0
10;255;3;0;6;0
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=6,pt=1,l=1,sg=0
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:0174D82
0;0;3;0;9;read: 0-0-10 s=255,c=3,t=17,pt=6,l=25,sg=0
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=11,pt=0,l=8,sg=1:Humidity
10;255;3;0;11;Humidity
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=11,pt=0,l=8,sg=0
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:01827E7
0;0;3;0;9;read: 0-0-10 s=255,c=3,t=17,pt=6,l=25,sg=0
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=12,pt=0,l=3,sg=1:1.0
10;255;3;0;12;1.0
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=12,pt=0,l=3,sg=0
0;0;3;0;9;read: 10-10-0 s=0,c=0,t=7,pt=0,l=0,sg=0:
10;0;0;0;7;
0;0;3;0;9;read: 10-10-0 s=0,c=0,t=7,pt=0,l=0,sg=0
0;0;3;0;9;read: 10-10-0 s=1,c=0,t=6,pt=0,l=0,sg=0:
10;1;0;0;6;
0;0;3;0;9;read: 10-10-0 s=1,c=0,t=6,pt=0,l=0,sg=0
0;0;3;0;9;read: 10-10-0 s=1,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:01E4D70
0;0;3;0;9;read: 0-0-10 s=255,c=3,t=17,pt=6,l=25,sg=0
0;0;3;0;9;read: 10-10-0 s=1,c=1,t=0,pt=7,l=5,sg=1:23.0
10;1;1;0;0;23.0
0;0;3;0;9;read: 10-10-0 s=1,c=1,t=0,pt=7,l=5,sg=0
0;0;3;0;9;read: 10-10-0 s=0,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:0148CE9
0;0;3;0;9;read: 0-0-10 s=255,c=3,t=17,pt=6,l=25,sg=0
0;0;3;0;9;read: 10-10-0 s=0,c=1,t=1,pt=7,l=5,sg=1:36.0
10;0;1;0;1;36.0

I have just a last question regarding signature :

• in the future, when Mysensors new version will be released, does the controller will have to check the signature and to store the PSK? I think so, as the logs shows it is crypted. For doing this we should inspire ourselves
  with your atsha_soft, isn't it? It is just curiosity of mine, as I am looking at your libs, and I am thinking about what changes will be involved on controller side when the moment will come for plugin update...

Now, I have to check the atsha soft version too, then ota with the recently great improvement of tekka..., and understand all new changes in the message format...lots of things.
I like this lib! 1.4 is smart, but dev branch looks very well done and much more optimized.

See you soon!

[Anticimex]

@scalz Great! Thanks for finding and testing this.
I am not sure I understand your question. You mean to store the PSK of atsha_soft in encrypted form in the sketch? That is difficult since the encryption secret then needs to be stored somewhere as well.
I would recommend (if you do use atsha_soft) to burn the fuses to prevent memory readout to protect the PSK.
Normally, this implementation is stored in the gateway which should be physically protected in any case, so the need to protekt PSK in the gateway is less critical than in a node which may be located "outside".

Secure OTA is currently unsupported. It might be supported in the future.

[scalz]

Oh, sorry for my bad english!
Is signing just between a Node and a Gateway. or is the controller involved too? Maybe it's a dumb question, I have not checked yet the changes in message.
For OTA, I understand it is not suppported by signature as you explained in your tuto. But, in the other hand, I think that for initiating an ota, it should need a signed message, so I think it is good.

[Anticimex]

@scalz You decide if your component will require signatures when you create your signer. That is, if you want your gateway to be able to sign messages sent to an actuator (like a lock) but you don't want your gateway to require signed messages from your nodes, you pass a argument to the constructor like this:
MySigningAtsha204 signer(false);
That will

• Configure that node/gw to support signed message processing using HW ATSHA
• Have that node/gw inform others that it does not require signed messages
• Still permit that node/gw to sign messages sent to other nodes/gw who do requre signing

If you stick to default constructor arguments or pass true, the difference is that the node/gw will also inform others that it requires signed messages, and will ignore/discard any message that is not signed which it receive (and is targeted to that particular node/gw). It will not affect messages which are to be relayed, so the node will still work as a relay for unsigned messages.

[scalz]

@Anticimex:
ok, it is good to know. You have thought about everything!
If signer(true) for gateway, Will the controller (Jeedom, Domoticz..) see a crypted payload in serial transmission or will it work like before (I understand there are some changes in message structure, but what about crypted payload, does the controller need to decrypt?)

[Anticimex]

@scalz We only sign messages. There is no encryption involved. And the signature is stored without affecting the message contents so it is perfectly compatible with all controllers. The only thing that could affect a controller is the new sign bit in the message header but I don't think that will make any difference as it is not relevant to the controller. It is the gateway that manages this for it.

[scalz]

ok, it is new for me, so I am mixing vocabulary, but I understand the concept. Thank you, and now I have my answer. no big changes for controller side, great! It makes sense, but I was not sure.

[hek]

Fix pushed to development.

[Anticimex]

Thanks for that!

[jsondag]

I put together a garage door opening using code from korttoma. I used soft signing, and it works great. I was wanting to use a real atsha though.

I bought some atsha204a chips from amazon, and the chips are marked with only "3eas", and a "Y" in one corners. They are soic-8. Is that how this should be marked? I wired one up according to the data sheet. Gnd to Gnd, VCC to 5V, and SDA to A3. I ran the personalizer to generate a key and it said "Failed to wake device." in the serial console. Am I doing something wrong? or did I just get the wrong chip from the seller?

[Anticimex]

@jsondag I don't have a good explanation on the software signing not working. Maybe inadequate decoupling leads to a too noisy power rail?
About the HW issue, it is important that you use the single wire version of atsha204. NOT the i2c version. The i2c version also has an scl line while the single wire only has sda (and power and ground). That means your soic8 should have 5 unused pads. Atmel ordering code for that variant is ATSHA204A-SSHCZ-T but unfortunately it is not printed on the case. So unless you find that information from Amazon, I am afraid it is very difficult to determine the type of the chips you've got.

[jsondag]

@Anticimex. Software signing is working fine.

Thanks for the information though. I didn't realize the soic 8 couldn't do one wire. It's a ATSHA204-SH-DA-B according to the listing.

EDIT:
Looking at the datasheet, it says that the SCL pin can be ignored for single wire interface. perhaps I'll wire another one up and give it a go.

Just connect, SDA to A3, correct?

[Anticimex]

@jsondag ok. From what I could read there are two different order codes for i2c and one-wire so I don't think you can take an i2c variant board and treat it as a one-wire board by just ignoring the scl pin. But if the board really is single-wire, the pinout will be the same as the i2c version, you can just ignore the scl pin as it is NC for the one-wire variant. And from the data sheet, SHDAB is i2c not "single-wire" so I am afraid you cannot use my libs for those. I only have drivers for single-wire chips i am afraid.

[TD22057]

I just received my chips today from digikey (part num ATSHA204A-STUCZ-TCT-ND) which are the small 3 pin versions. Holy cow these are things are tiny. These are going to be a lot more difficult than I expected to hand solder.

[Anticimex]

@TD22057 If you don't have a "inverse" tweezer to fixate the chip to the board, just glue it in place. With proper iron temp (at least 300 deg C, I use 330) it's very doable. Much easier than smd resistors/caps if you ask me (just don't forget to solder after you glue if you do that)

[TD22057]

@Anticimex said:

@TD22057 If you don't have a "inverse" tweezer to fixate the chip to the board, just glue it in place. With proper iron temp (at least 300 deg C, I use 330) it's very doable. Much easier than smd resistors/caps if you ask me (just don't forget to solder after you glue if you do that)

Thanks - I'll try that as soon as everything arrives. Watching parts trickle in from aliexpress shippers is killing me (I think I've become spoiled on Amazon prime shipping).

[tomkxy]

First of all I would like to thank Anticimex for this great piece of work!

I am playing around with signing right now. I set up a temp & humid sensor with soft signing support as well as a MQTT gateway with soft signing.

In principle it seems to work. At least sensor values are published to the MQTT broker. However, in the gateway output I see nonce tr errors and sign failures.

Started!
0;0;3;0;9;read: 21-21-0 s=1,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-21-21 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:0107FD8
0;0;3;0;9;read: 21-21-0 s=1,c=1,t=0,pt=7,l=5,sg=1:25.1
publish: MyMQTT/21/1/V_TEMP 25.1
0;0;3;0;9;read: 21-21-0 s=2,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-21-21 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:012B06D
0;0;3;0;9;send: 0-0-21-21 s=1,c=3,t=16,pt=0,l=0,sg=0,st=ok:
0;0;3;0;9;read: 21-21-0 s=2,c=1,t=1,pt=7,l=5,sg=1:59.0
publish: MyMQTT/21/2/V_HUM 59.0
0;0;3;0;9;sign fail
0;0;3;0;9;send: 0-0-21-21 s=2,c=3,t=16,pt=0,l=0,sg=0,st=fail:
0;0;3;0;9;nonce tr err
0;0;3;0;9;read: 21-21-0 s=255,c=3,t=17,pt=6,l=25,sg=0:01D5F523C2778AA
0;0;3;0;9;read: 21-21-0 s=1,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-21-21 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:0104881
0;0;3;0;9;read: 21-21-0 s=1,c=1,t=0,pt=7,l=5,sg=1:25.1
publish: MyMQTT/21/1/V_TEMP 25.1
0;0;3;0;9;read: 21-21-0 s=2,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-21-21 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:019A79B
0;0;3;0;9;send: 0-0-21-21 s=1,c=3,t=16,pt=0,l=0,sg=0,st=ok:
0;0;3;0;9;read: 21-21-0 s=2,c=1,t=1,pt=7,l=5,sg=1:59.2
publish: MyMQTT/21/2/V_HUM 59.2
0;0;3;0;9;sign fail
0;0;3;0;9;send: 0-0-21-21 s=2,c=3,t=16,pt=0,l=0,sg=0,st=fail:
0;0;3;0;9;nonce tr err
0;0;3;0;9;read: 21-21-0 s=255,c=3,t=17,pt=6,l=25,sg=0:0120D83204D1A06
0;0;3;0;9;read: 21-21-0 s=1,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-21-21 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:01AB761
0;0;3;0;9;read: 21-21-0 s=1,c=1,t=0,pt=7,l=5,sg=1:25.1
publish: MyMQTT/21/1/V_TEMP 25.1
0;0;3;0;9;read: 21-21-0 s=2,c=3,t=16,pt=0,l=0,sg=0:
0;0;3;0;9;send: 0-0-21-21 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:013CD41
0;0;3;0;9;read: 21-21-0 s=2,c=1,t=1,pt=7,l=5,sg=1:59.3
publish: MyMQTT/21/2/V_HUM 59.3
0;0;3;0;9;send: 0-0-21-21 s=1,c=3,t=16,pt=0,l=0,sg=0,st=fail:
0;0;3;0;9;nonce tr err
0;0;3;0;9;send: 0-0-21-21 s=2,c=3,t=16,pt=0,l=0,sg=0,st=fail:
0;0;3;0;9;nonce tr err

I am somehow irritated concerning those failures logged after the publish logs. They seem not to be related to receiving and publishing the sensor data. What can be source of that? Why might the gateway trying to transmit?

A second question is related to personalization of the ATSHA204. Am I right that the key is displayed in the SlotConfig00 - SlotConfig0F?

The second personalization step fails with the message "Data lock failed". What could be the reason for that?

[Anticimex]

@tomkxy Thanks.
"nonce tr err" is sent if sendRoute() fails to send a nonce request. So it suggests the radio link is somewhat unreliable and that in turn causes signing to fail. From what I can see you want to sign messages in both directions, so maybe traimsission from the MQTT gateway is not as reliable as reception? message type 16 (command 3) is a nonce request and sometimes it succeeds

0;0;3;0;9;send: 0-0-21-21 s=1,c=3,t=16,pt=0,l=0,sg=0,st=ok:

and sometimes it fail (with that message as consequence):

0;0;3;0;9;send: 0-0-21-21 s=2,c=3,t=16,pt=0,l=0,sg=0,st=fail:
0;0;3;0;9;nonce tr err

But the failing one is to a different sensor (2) than the first one (1), so perhaps that node is down or at a long range? But last in your log you also fail a transmission to sensor 1. In any case, the nonce tr err is because of failing radio transmissions and as such not a signing issue as such. Sometimes it works (when there are no radio issues:

0;0;3;0;9;read: 21-21-0 s=1,c=3,t=16,pt=0,l=0,sg=0: (request for nonce to GW)
0;0;3;0;9;send: 0-0-21-21 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:01AB761 (GW sends nonce back)
0;0;3;0;9;read: 21-21-0 s=1,c=1,t=0,pt=7,l=5,sg=1:25.1 (signed message with that nonce is received)
publish: MyMQTT/21/1/V_TEMP 25.1 (message/signature is accepted and forwarded)

"sign fail" is typically reported if nonce exchange times out. You can adjust the timeout using MY_VERIFICATION_TIMEOUT_MS if you have many hops or for other reasons cannot process messages fast enough.
I have not tested MQTT gateway myself, and perhaps it uses the MySensors library differently but I have tested both serial and ethernet gateway. But in this case, it probably fails because you never got the request for the nonce out so your sender never got a chance to send a nonce back, and therefore signing cannot succeed.
So the key is to determine why the transmission of the nonce request fail (a radio problem since you get st=fail). Or implement a retransmission at a higher level in your sketch if the radio link is "lossy". The signing backend assumes a working channel and do not handle retransmission for you on failures.

Regarding personalization, key is never displayed. It is stored in slot 0. Slotconfigs are used to set the permissions of the slots. They don't store keys themselves.
You should get the reason for the data lock failure in the code that is sent together with the message. It is the ATSHA circuit itself that provide this value (or the library communicating with it in case of communication problem).

[tomkxy]

Thanks for your fast reply. Regarding the communication failures: I was testing this with both transmitters lying side by side. Do you have any idea why the gateway might want to have a nonce. Is it part of the sensor protocol?
The two sensors displayed in the log are basically the same sensor (DHT22 providing temp and humidity).

With respect to the key topic: The first personalization step provides the following output:

Device revision: 00020009
Device serial:   {0x01,0x23,0x48,0xC9,0x51,0x6A,0x1A,0x06,0xEE}
012348C9516A1A06EE
Chip configuration:
           SN[0:1]           |         SN[2:3]           | 01   23 | 48   C9   
                          Revnum                         | 00   09   04   00   
                          SN[4:7]                        | 51   6A   1A   06   
    SN[8]    |  Reserved13   | I2CEnable | Reserved15    | EE | 13 | 00 | 00   
  I2CAddress |  TempOffset   |  OTPmode  | SelectorMode  | C8 | 00 | 55 | 00   
         SlotConfig00        |       SlotConfig01        | 8F   80 | 80   A1   
         SlotConfig02        |       SlotConfig03        | 82   E0 | A3   60   
         SlotConfig04        |       SlotConfig05        | 94   40 | A0   85   
         SlotConfig06        |       SlotConfig07        | 86   40 | 87   07   
         SlotConfig08        |       SlotConfig09        | 0F   00 | 89   F2   
         SlotConfig0A        |       SlotConfig0B        | 8A   7A | 0B   8B   
         SlotConfig0C        |       SlotConfig0D        | 0C   4C | DD   4D   
         SlotConfig0E        |       SlotConfig0F        | C2   42 | AF   8F   
  UseFlag00  | UpdateCount00 | UseFlag01 | UpdateCount01 | FF | 00 | FF | 00   
  UseFlag02  | UpdateCount02 | UseFlag03 | UpdateCount03 | FF | 00 | FF | 00   
  UseFlag04  | UpdateCount04 | UseFlag05 | UpdateCount05 | FF | 00 | FF | 00   
  UseFlag06  | UpdateCount06 | UseFlag07 | UpdateCount07 | FF | 00 | FF | 00   
                      LastKeyUse[0:3]                    | FF   FF   FF   FF   
                      LastKeyUse[4:7]                    | FF   FF   FF   FF   
                      LastKeyUse[8:B]                    | FF   FF   FF   FF   
                      LastKeyUse[C:F]                    | FF   FF   FF   FF   
  UserExtra  |    Selector   | LockValue |  LockConfig   | 00 | 00 | 55 | 55  

Can I provide any key in the second personalization step or does it have to be same than in the first step being generated?

[Anticimex]

@tomkxy The protocol is described in the first post. Any node that is sending a signed message to another node (that has requested to get signed messages) will ask for a nonce. So you have configured your gateway to require signed messages as well as your node.
Regarding the personalization, I do t understand your question. The output is the chip configuration. It does not list any keys. I am not sure I understand what you mean by second step. You can generate a random key and that key you store and after you store it you have an option to also lock it, but then you have no way of ever changing it. I have documented the personalization flow also in the sketch itself.

[Anticimex]

I should emphasise that if you personalize multiple atsha:s you have to have the same key stored in all of them. But the sketch offer to generate a random key (but you can skip that and use any key or password you like). But the key must be the same for all members of a secure network that want to talk to each other.

[tomkxy]

@Anticimex: The output shown is related to the sketch configuration you described in your description:

Set the following sketch configuration of the personalizer:
Enable LOCK_CONFIGURATION
Disable LOCK_DATA
Enable SKIP_KEY_STORAGE
Disable SKIP_UART_CONFIGURATION
Disable USER_KEY_DATA

Execute the sketch on the “master” device to obtain a randomized key. Save this key to >a secure location and keep it confidential so that you can retrieve it if you need to
personalize more devices later on.

I was wondering that I did not see any explicit reference to a key. So may be I just have to retry.

I should emphasise that if you personalize multiple atsha:s you have to have the same >key stored in all of them. But the sketch offer to generate a random key (but you can >skip that and use any key or password you like). But the key must be the same for all >members of a secure network that want to talk to each other.
Thanks for that clarification. I was aware of that.

[Anticimex]

@tomkxy are you sure you have enabled all those options? According to the dump, your configuration is still not locked and therefore no randomized key can be generated. Are there no more output from the sketch than that? You mentioned failure to lock data zone but I cannot see that message. And you cannot lock datazone without locking configuration.
After the sketch locks configuration it will print a randomized key in the log.

[tomkxy]

@Anticimex: Thanks for your patience and your support.
I rerun it with the output and sketch configuration listed below. May be the reason that it is not working that my poor soldering skills bricked the device.

Extract from sketch (1st run):

#include <sha204_library.h>
#include <sha204_lib_return_codes.h>

// The pin the ATSHA204 is connected on
#define ATSHA204_PIN 17 // A3

// Uncomment this to enable locking the configuration zone.
// *** BE AWARE THAT THIS PREVENTS ANY FUTURE CONFIGURATION CHANGE TO THE CHIP ***
// It is still possible to change the key, and this also enable random key generation
#define LOCK_CONFIGURATION

// Uncomment this to enable locking the data zone.
// *** BE AWARE THAT THIS PREVENTS THE KEY TO BE CHANGED ***
// 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.
//#define LOCK_DATA

// Uncomment this to skip key storage (typically once key has been written once)
#define SKIP_KEY_STORAGE

// Uncomment this to skip key data storage (once configuration is locked, key
// will aways randomize)
// Uncomment this to skip key generation and use 'user_key_data' as key instead.
//#define USER_KEY_DATA

// Uncomment this for boards that lack UART
// IMPORTANT: 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

#if defined(SKIP_UART_CONFIRMATION) && !defined(USER_KEY_DATA)
#error You have to define USER_KEY_DATA for boards that does not have UART
#endif
…

Output:

ATSHA204 personalization sketch for MySensors usage.
----------------------------------------------------
Device revision: 00020009
Device serial:   {0x01,0x23,0x48,0xC9,0x51,0x6A,0x1A,0x06,0xEE}
012348C9516A1A06EE
Skipping configuration write and lock (configuration already locked).
Chip configuration:
           SN[0:1]           |         SN[2:3]           | 01   23 | 48   C9   
                          Revnum                         | 00   09   04   00   
                          SN[4:7]                        | 51   6A   1A   06   
    SN[8]    |  Reserved13   | I2CEnable | Reserved15    | EE | 13 | 00 | 00   
  I2CAddress |  TempOffset   |  OTPmode  | SelectorMode  | C8 | 00 | 55 | 00   
         SlotConfig00        |       SlotConfig01        | 8F   80 | 80   A1   
         SlotConfig02        |       SlotConfig03        | 82   E0 | A3   60   
         SlotConfig04        |       SlotConfig05        | 94   40 | A0   85   
         SlotConfig06        |       SlotConfig07        | 86   40 | 87   07   
         SlotConfig08        |       SlotConfig09        | 0F   00 | 89   F2   
         SlotConfig0A        |       SlotConfig0B        | 8A   7A | 0B   8B   
         SlotConfig0C        |       SlotConfig0D        | 0C   4C | DD   4D   
         SlotConfig0E        |       SlotConfig0F        | C2   42 | AF   8F   
  UseFlag00  | UpdateCount00 | UseFlag01 | UpdateCount01 | FF | 00 | FF | 00   
  UseFlag02  | UpdateCount02 | UseFlag03 | UpdateCount03 | FF | 00 | FF | 00   
  UseFlag04  | UpdateCount04 | UseFlag05 | UpdateCount05 | FF | 00 | FF | 00   
  UseFlag06  | UpdateCount06 | UseFlag07 | UpdateCount07 | FF | 00 | FF | 00   
                      LastKeyUse[0:3]                    | FF   FF   FF   FF   
                      LastKeyUse[4:7]                    | FF   FF   FF   FF   
                      LastKeyUse[8:B]                    | FF   FF   FF   FF   
                      LastKeyUse[C:F]                    | FF   FF   FF   FF   
  UserExtra  |    Selector   | LockValue |  LockConfig   | 00 | 00 | 55 | 00   
Disable SKIP_KEY_STORAGE to store key.
Data not locked. Define LOCK_DATA to lock for real.
--------------------------------
Personalization is now complete.
Configuration is LOCKED
Data is UNLOCKED

Second run with the following sketch settings (key used removed):

#include <sha204_library.h>
#include <sha204_lib_return_codes.h>

// The pin the ATSHA204 is connected on
#define ATSHA204_PIN 17 // A3

// Uncomment this to enable locking the configuration zone.
// *** BE AWARE THAT THIS PREVENTS ANY FUTURE CONFIGURATION CHANGE TO THE CHIP ***
// It is still possible to change the key, and this also enable random key generation
#define LOCK_CONFIGURATION

// Uncomment this to enable locking the data zone.
// *** BE AWARE THAT THIS PREVENTS THE KEY TO BE CHANGED ***
// 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.
#define LOCK_DATA

// Uncomment this to skip key storage (typically once key has been written once)
//#define SKIP_KEY_STORAGE

// Uncomment this to skip key data storage (once configuration is locked, key
// will aways randomize)
// Uncomment this to skip key generation and use 'user_key_data' as key instead.
#define USER_KEY_DATA

// Uncomment this for boards that lack UART
// IMPORTANT: 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

#if defined(SKIP_UART_CONFIRMATION) && !defined(USER_KEY_DATA)
#error You have to define USER_KEY_DATA for boards that does not have UART
#endif

#ifdef USER_KEY_DATA
#define MY_HMAC_KEY 0x…

const uint8_t user_key_data[32] = {MY_HMAC_KEY};
#endif
const int sha204Pin = ATSHA204_PIN;
atsha204Class sha204(sha204Pin);

Device revision: 00020009
Device serial:   {0x01,0x23,0x48,0xC9,0x51,0x6A,0x1A,0x06,0xEE}
012348C9516A1A06EE
Skipping configuration write and lock (configuration already locked).
Chip configuration:
           SN[0:1]           |         SN[2:3]           | 01   23 | 48   C9   
                          Revnum                         | 00   09   04   00   
                          SN[4:7]                        | 51   6A   1A   06   
    SN[8]    |  Reserved13   | I2CEnable | Reserved15    | EE | 13 | 00 | 00   
  I2CAddress |  TempOffset   |  OTPmode  | SelectorMode  | C8 | 00 | 55 | 00   
         SlotConfig00        |       SlotConfig01        | 8F   80 | 80   A1   
         SlotConfig02        |       SlotConfig03        | 82   E0 | A3   60   
         SlotConfig04        |       SlotConfig05        | 94   40 | A0   85   
         SlotConfig06        |       SlotConfig07        | 86   40 | 87   07   
         SlotConfig08        |       SlotConfig09        | 0F   00 | 89   F2   
         SlotConfig0A        |       SlotConfig0B        | 8A   7A | 0B   8B   
         SlotConfig0C        |       SlotConfig0D        | 0C   4C | DD   4D   
         SlotConfig0E        |       SlotConfig0F        | C2   42 | AF   8F   
  UseFlag00  | UpdateCount00 | UseFlag01 | UpdateCount01 | FF | 00 | FF | 00   
  UseFlag02  | UpdateCount02 | UseFlag03 | UpdateCount03 | FF | 00 | FF | 00   
  UseFlag04  | UpdateCount04 | UseFlag05 | UpdateCount05 | FF | 00 | FF | 00   
  UseFlag06  | UpdateCount06 | UseFlag07 | UpdateCount07 | FF | 00 | FF | 00   
                      LastKeyUse[0:3]                    | FF   FF   FF   FF   
                      LastKeyUse[4:7]                    | FF   FF   FF   FF   
                      LastKeyUse[8:B]                    | FF   FF   FF   FF   
                      LastKeyUse[C:F]                    | FF   FF   FF   FF   
  UserExtra  |    Selector   | LockValue |  LockConfig   | 00 | 00 | 55 | 00   
Using this user supplied key:
#define MY_HMAC_KEY 0x…..
Writing key to slot 0...
Data lock failed. Response: D3
Halting!

[Anticimex]

@tomkxy I'm on phone so I cannot check the response code right now but you could look it up in the atsha datasheet or in the software. I have not tried to lock data myself and I do not recommend it because it makes it impossible to change the key later on if it is comprised. From what I can see, everything looks good except the locking of the datazone (your key)

[Anticimex]

@tomkxy I should add that from the logs I see that you do have successfully stored your key, so unless you really want to lock down the key, personalization is done and successful.

[tomkxy]

@Anticimex: Thanks a lot. I didn't intend to lock the data zone.

Btw, I did some tests regarding the nonce failure the gateway showed. I think the reason is rather simple. The gateway tried - for reasons I still don't understand - send data to the sensor for which it tried to get a nonce. The sensor however was powered down which is probably the reason why no nonce was sent. At least this error didn't show up when I removed the power down and replaced it by a simple call to delay.