💬 Security & Signing

[Anticimex]

@macvictor

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

[egadgetjnr]

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

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

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

Thanks Heaps

[Anticimex]

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

[egadgetjnr]

@Anticimex said in 💬 Security & Signing:

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

Thanks heaps for your prompt reply!

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

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

[Takero]

@egadgetjnr where dit u come from?

[Anticimex]

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

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

[DavidZH]

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

[bilbolodz]

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

[Anticimex]

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

[bilbolodz]

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

Personalization sketch for MySensors usage.

Failed to wake device. Response: E7
Halting!

any ideas?

[Anticimex]

@bilbolodz hm, no. I have not tested on a 8-lead device. Should not be a difference but I can neither deny nor confirm. My best suggestion would be to have a look with an oscilloscope on the wire to confirm that the signal quality is good.

[melwinek]

Is SIGNING a RFM69_ENABLE_ENCRYPTION replacement? If so is it a better or worse solution? Maybe RFM69_ENABLE_ENCRYPTION is enough?

[mfalkvidd]

@melwinek encryption and signing have very different purpose.

Signing prevents other people from sending messages to control your nodes. Without signing, anyone with the right skill or software can take control of your nodes.

Encryption tries to hide the contents of the messages between your nodes. That does not prevent people from taking control of your nodes.

[Anticimex]

@melwinek signing and encryption are two completely different things. And they can be enabled at the same time if so desired. Signing provides authentication and encryption provides obscurity.

[melwinek]

@Anticimex, @mfalkvidd But with the use of encryption so easily no one will take control, must break the code.
So it is best to simultaneously encrypt (eg RFID tag serial number when opening the gate) and sign (eg gate open message)?

[Anticimex]

@melwinek what prevents anyone from copying your encrypted message and record it. And then later send the same thing?
Encryption provides obscurity. You need signing for authentication. Signed messages cannot be repeated because they are always unique. Encryption does not necessarily guarantee that.

[t3chie]

@bilbolodz I am getting the same message with a Sensebender Micro. I configured it for soft-signing with LOCK_CONFIGURATION enabled. Now I wanted to switch to hardware based signing.

Any way to unlock a locked configuration?

[Anticimex]

@t3chie there is no configuration to lock for soft signing. Configuration locking only applies to atsha204a. And if locked it cannot be unlocked. And normally you shouldn't need to either as the default settings set are the one to use, and unless you have been very creative in hacking the personalizer that configured should work just fine.

[t3chie]

@Anticimex I tested first with softsigning but shortly after this realized that with soft signing the Sensebender has not enough space for debug messages.
I rerun the personalizer to switch to hardware based signing and hit the "Failed to wake device. Response: E7" message.
Played around and found that

#define MY_SIGNING_ATSHA204_PIN 17
instead of
#define MY_SIGNING_ATSHA204_PIN 4

made the personalizer happy again. I am still fighting with getting signing to work. Setting #define MY_SIGNING_REQUEST_SIGNATURES and MY_SIGNING_GW_REQUEST_SIGNATURES_FROM_ALL did not get me going.

[Anticimex]

@t3chie I assume you have personalized nodes and gw with the same hmac key?