💬 Security & Signing

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

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