Minimal design thoughts

[tbowmo]

@Anticimex

It's wit a separate sketch, right? Can we do anything in the protocol for key initialization? So when a device asks for a node Id it could also get the shared key supplied via radio?

I am thinking about creating a plug and play ready unit, with a preloaded sensor sketch from the factory in China, would be nice if people had an easy method of initializing things without reloading other sketches

[Anticimex]

@tbowmo short answer: no. Sending the key in clear text is out of the question. That is totally not secure. The whole idea with that circuit is that the key is prestored and hidden. Technically it is possible but then one also has to work around the payload size limitation in the rf protocol.

[tbowmo]

@Anticimex

I know that there are some gotcha's with cleartext key transfer.. But I thought thata if output power is set to lowest value in the GW, and key transfers only could be done while in discovery mode. Then the risk of anyone snooping it, is lower..

Going into "easy initialize thinking mode" :d

[Anticimex]

@tbowmo I do understand what you seek. However.

1. If we do accept the added cost in memory use and component cost (and development effort) of using a strong authentication hardware, it makes no sense throwing it all away by implementing its use in an insecure way (although the common man probably won't be able to compromise it).
2. I have already made one big sacrifice in allowing truncated signatures (or we would have to implement a framing protocol for sending >32 byte messages).
3. I am not going to implement a signing scheme which I would be able to hack myself.

Basically, my ambition with the signing is not a "low risk" of hacking. it is a "no" risk of hacking. (with the reservation of the truncated signature as mentioned above). Signatures will be inversely proportional to the complexity of the message. Signature size = 32-7-<payload size>-1 byte. In other words, the maximum possible signature size for a 1-byte message is 23 bytes. But I do think HMAC-256 is still a bitch to hack even if a portion of it is sliced off.

Also, how do you prevent an attacker from issuing its own keys by resetting the HW in some way? And besides, all users have to program their devices for them to do anything at all. Doing the ATSHA204 personalization is a one-time effort, and adds quite little work and I see no reason why it would not be possible to do this by OTA either if one preferred to do that. The configurations and keys are permanently stored on the devie in EEPROM. So the personalization is only executed once on every security-enabled device.
I think we need to save as much space as possible so having all nodes drag around the logic to do key replacement will add a memory cost in itself. And if you take security really seriously, you do want to lock down the fused key as well. Atmel is quite fuzzy about what security can be guaranteed if the data section is not locked so I am not sure if key readout is prevented with data unlocked even if configuration forbids it. The datasheet is not clear on that.

The idea is:
You deploy a gateway that has the ability to sign (and verify) messages. You personalize the ATSHA device on your gateway with some personal secret key. The personalization sketch allows you to randomize that key if desired.
You take the sketch and store the generated key in it and tucks it away. For every node you want to add, you download and execute the personalization once. And then your done with that. It will from there on be able to exchange signed messages with your gateway until you either revoke the key in the gateway (reprogram it if data is unlocked or replace it and change the key in the new device).
In my opinion, a one-time initialization is not that difficult. But perhaps my sketch is complex, I welcome feedback on that topic. I have tried to explain the expected usage in the comments in the sketch header.

My personal opinion on the security matter: We do it properly or we skip it. Every user ultimately decides by them self if they want security in their sensor network. And if they do go for it, it should be trustworthy.

[hek]

Let's continue the discussion in the security thread.

[tbowmo]

@hek
Yes.. forgot about that.. :)

[tbowmo]

sample order is sent for the atsha204 chips.. Hope it will go through at atmel..

I could only order 3 samples in total.. But that should be enough for checking that everything is working, and for sending one off to manufacturer in China.

[Anticimex]

Figners crossed that the chinese dont muck it up :)
Let me know if you need assistance in verifying the ATSHA on the prototype. I have one hooked up to my PC for debugging purposes, prepared and confguration locked for MySensors usage.

[tbowmo]

@Anticimex

My plan is to just run your test code, to verify that i can talk to the device. Just like i did with the external Flash chip.

[Anticimex]

@tbowmo
Alright. Just so you know, I have not adapted it for your board pinout yet. I will change my breadboard prototype accordingly and retest when I implement the non-UART support in the personalizer. I hope to be finished with that before you get your samples.

[tbowmo]

Hmm.. I like dirtypcbs "honest" approach to things:

---

Hey Thomas Mørch,

Your PCB order number xxxxx has been shipped.

If you used DHL/FEDEX/UPS a tracking number will be sent later. We hope it is provided within 48hours, but our logistics company is being painfully slow with updates and provides incorrect numbers. We fired them, and will start working directly with DHL October 1st, 2014.

[Anticimex]

I'm going to enjoy this ^^

[tbowmo]

@Anticimex

:) The whole site of dirtypcbs are made up like that, trash talking their own product.. But so far the service has been ok from them. This is first time I ordered with express shipment, hopefully they'll arive later this week..

[Anticimex]

@tbowmo said:

dirtypcbs

Well, for a site that in their website footer prints
"No bull, just crappy PCBs"
what can possibly go wrong :D

[RJ_Make]

@Anticimex said:

@tbowmo said:

dirtypcbs

Well, for a site that in their website footer prints
"No bull, just crappy PCBs"
what can possibly go wrong :D

LOL

[tbowmo]

@Anticimex

Just received the tracking number.. (so it took them 2 days to go from the factory to the shipping company :))

Anyway, now I have a tracking number, so I can keep an eye on things :)

[CodeIt]

@tbowmo Since Domoticz (home automation software) got support for MySensors i have been looking for cool sensors. I want to place a MySensor node in every room in my house with temp/humidity motion and reed contact, run directly from battery. Your board looks very promising. I only have one question. Is it possible to have two interrupts (for the motion sensor and reed contact)?

[hek]

@CodeIt

D2 is connected to radio socket IRQ pin.
But as it currently not used by the library you could just cut the leg on radio and connect it to whatever you want.

[axillent]

it is also possible to use PCINT interrupt on mostly any digital or even analog pin

[tbowmo]

What bootloader should I go for, for the prodcution run? (that is preload a bootloader into the atmega) ?

I am also thinking about preloading a default sketch as well, so it's almost plug'n'play.

(@hek, this default sketch should probably be included in the mysensors git repo, right ?)

/ Thomas