Sensebender Gateway and ATSHA204

[MLs]

Hey now Sense Bender Gateway arrived and I was going to start using ATSHA204- But am a bit worried to lock something in the circuit so that I destroy it. So a few questions I have after I read https://forum.mysensors.org/topic/1021/security-introducing-signing-support-to-mysensors/2

What locks must be locked to make it work with ATSHA204. I also resolve ATSHA204 I played a little bit with. And I have run SecurityPersonalizer.ino then after that I locked configuration. Then, I generated a key without a lock to replace the key if I want to. And if I have understood everything correctly so it will be good so? Then you come to put the key in other ATSHA204 should then edit the file SecurityPersonalizer.ino and paste the key you got from the first ATSHA204?

PF8F
UseFlag00 | UpdateCount00 | UseFlag01 | UpdateCount01 | FF | 00 | FF | 00
UseFlag02 | UpdateCounC2 42 | AF 8F
UseFlag00 | UpdateCount00 | UseFlag01 | UpdateCount01 | FF | 00 | FF | 00
UseFlag02 | UpdateCount02 | UseFlag03 | Upd
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 | ‘…Ñ•
½Õ¹ÑÁ7 | FF | 00 | FF | 00
LastKPersonalization sketch for MySensors usage.
-------------------------------------------
Device revision: 00000004
Device serial: {0x01,0x23,0x3F,0x99,0xAA,0x5B,0xA5,0xCE,0xEE}
01233F99AA5BA5CEEE
Skipping configuration write and lock (configuration already locked).
Chip configuration:
EEPROM DATA:
SOFT_HMAC_KEY | FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
SOFT_SERIAL | FFFFFFFFFFFFFFFFFF
AES_KEY | FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
ATSHA204A DATA:
SN[0:1] | SN[2:3] | 01 23 | 3F 99
Revnum | 00 04 05 00
SN[4:7] | AA 5B A5 CE
SN[8] | Reserved13 | I2CEnable | Reserved15 | EE | 55 | 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
Take note of this key, it will never be the shown again:
#define MY_HMAC_KEY
0x25,0x8B,0x49,0xD7,0x2E,0x43,0x2F,0x3A,0x61,0xF5,0x4A,0xB9,0x9F,0x93,0x05,0x32,\
0x55,0xB9,0xF6,0xF2,0x9A,0x4C,0xD7,0x4E,0x52,0x12,0xAC,0x58,0x03,0xAE,0xCD,0x6F
Writing key to slot 0...
Data not locked. Define LOCK_DATA to lock for real.
--------------------------------
Personalization is now complete.
Configuration is LOCKED
Data is UNLOCKED```

My goal with my network are able to both have ATSHA204 nodes and ordinary nodes without ATSHA204. As the temperature and the like nodes.

Or is it better to use ATSHA204 on all nodes?

//Mattias

[Anticimex]

@MLs
Signing is supported using both atsha204a and pure software. They are perfectly compatible so you can mix all you want.
What is important to understand is that if you use software based signing, if someone gets physical access to your node, they can dump eeprom and obtain your secret hmac key (PSK) and using that they can potentially compromise your node network.
The benefit of a atsha is that the key is securely stored and cannot be extracted from the chip. At least it is according to Atmel. So if you plan to put your node "outside" it is recommended to use atsha. On your gateway it is less important as you would typically have your gateway placed "securely". If you do not, then your network would be compromised as an attacker could tap in to the communication between gateway and controller, which is not secured.
This limitation is not accidental. Supporting security between gateway and controller mean a dependency which would limit the ability to support a wide range of controllers and is therefore undesirable. And personally I don't really see a usecase for it anyway as gateways generally are placed indoors and are hooked up to a LAN in one way or another.