Minimal design thoughts

[hek]

Ok, pushed a product page to the main site just now. Hope the page is selling enough. ;)

http://www.mysensors.org/hardware/micro

[RJ_Make]

"ATSHA204A sot23 footprint on board"

So does that mean this run will not have the ATSHA204A populated?

[tbowmo]

@ServiceXp

We haven't started production yet, I'm still waiting for the latest prototype pcb to arrive from China, before I can make the (hopefully) last prototype before "mass production". Which also means I have to find the atsha204 somewhere, so I can test it.

And yes I know mouser has it, but I don't need that much more from them, so will have to pay a big handling/shipping fee to them

[hek]

@Anticimex , did you have any spare atsha204 left?

[bjornhallberg]

@tbowmo Have you looked on AliExpress. A quick search seems to suggest that could be a viable alternative. Try some different search combinations though ... their search engine sucks. "ATSHA204" wont find "ATSHA204A" for instance when I try.

Wont be quick though, and the Chinese New Year is coming up ...

[Anticimex]

I can part with a SOT23 ATSHA204A if necessary. They can also be sampled from Atmel in small quantities for free (that's what I did).

[hek]

@Anticimex said:

sampled

Do you remember the deliver time on samples?

[Anticimex]

@hek It took three days from order confirmation to shipment notification. I don't recall the transit times but it went out with DHL WW Express so it should be pretty fast. Say 5-10 working days tops.

[tbowmo]

@Anticimex said:

@hek It took three days from order confirmation to shipment notification. I don't recall the transit times but it went out with DHL WW Express so it should be pretty fast. Say 5-10 working days

hmm what is the sample quantity limit?

[Anticimex]

@tbowmo I don't remember. But I got at least three (don't think I requested more since at the time I was not sure it would meet my personal demands, nor if the MySensors community would accept it). Since it is now kind of "official" I guess it has :)

[tbowmo]

@Anticimex said:

@tbowmo I don't remember. But I got at least three (don't think I requested more since at the time I was not sure it would meet my personal demands, nor if the MySensors community would accept it). Since it is now kind of "official" I guess it has :)

ok, I'll try and get some samples then.

Has there been any work done to support easy initialization of the keys on new devices?

[Anticimex]

@tbowmo That's already done. Available in development branch. I will update it to support devices without UART in the near future. Check libraries/sha204/examples/sha204_personalizer
Auto-generation of keys is supported as well as manually contributed ones (all devices in the same environment needs to share a key). All necessary personalization for MySensors usage is done (default settings are fine) and locking of both configuration and data sections are suppored (only configuration section is mandatory to lock).

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