💬 Security & Signing

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

[Anticimex]

@t3chie also that you also defined the signing enabled flag on all participants (but I think you get a preprocessor error if you don't)

[skywatch]

Is it possible to use the ATSHA204A along with the Rpi directly attached NRF24L01+ gateway? I can see how to attach the ATSHA to the nodes, but how to attach it to the pi?
Thank you.

[Anticimex]

@skywatch no, not to my knowledge. The atsha driver is Arduino specific. I would happily review a pull request that ports the bit banged driver for Linux though :)

[Anticimex]

@skywatch the use case for atsha204a backed signing on rPi is limited though. As it is used as I gw (I presume) it is considered "protected" and is less sensitive for key dumping.

[skywatch]

Thank you for the quick response. Maybe i mis-understand this?
I have got 10 ATSHA chips that I would like to attach to arsuino nodes to use with a raspberry pi based gateway/controller combo. Do I therefore need to attach the ATSHA to the rpi, or could I still use the ATSHA hardware on the arduinos without an ATSHA attached to the rpi?
I had assumed that the atsha chip would be needed at both ends for signing to work. Maybe that's not how it works?

[Anticimex]

@skywatch no, the software port is fully compatible with the atsha204a. So you can use Arduino nodes with atsha204a and they will work just fine with your rPi with software signing. Just as long as they all use the same hmac key.