Minimal design thoughts

[boozz]

@tbowmo
Ok, I misinterpreted your question. Can't help you on that one, sorry :-)

[RJ_Make]

@tbowmo said:

I am almost ready for a second prototype spin of the PCB, but before doing that I could use some input from the community,

If this board was going into "mass production", is there any features that I should consider adding? Any missing parts? Anything that you think that I have forgotten?

The schematics for revision 2 is a couple of posts back in the thread.

I have considered adding a ATSHA204 for future security purposes, but can't seem to find a suitable spot for it (maybe I'm just too tired to see things clearly at the moment :)).

I would work on trying to get the ATSHA204 included, even if it means the dims get a little larger. The one thing that I really don't like about MySensors is the lack of any wireless security.. Would love to see this implemented.

[rdevine]

@tbowmo Maybe i missed it but do you have an image with the si7021 attached to the radio and pcb?

[tbowmo]

@rdevine said:

@tbowmo Maybe i missed it but do you have an image with the si7021 attached to the radio and pcb?

Look in post #93 the small white dot on the pcb is the si7021 :)

[tbowmo]

@ServiceXp said:

I would work on trying to get the ATSHA204 included, even if it means the dims get a little larger. The one thing that I really don't like about MySensors is the lack of any wireless security.. Would love to see this implemented.

For one second, I thought you where danish :), as the word "dims" usually refers to a small gadget like device, that you don't have a name for at the moment (or even components, screws, bolts, anything small could be a "dims") :)

[Tibus]

@tbowmo said:

ATSHA204

This module is verry interesting but how it work? What you have to do in code to make it work, crypting messages,...?

[Dirk_H]

@tbowmo I don't see a Load Capacitor on the crystal. Especially if you need a precise clock you should use some. Have a look at https://www.adafruit.com/blog/2012/01/24/choosing-the-right-crystal-and-caps-for-your-design/ for example about Load Capacitors.

[tbowmo]

@Dirk_H said:

@tbowmo I don't see a Load Capacitor on the crystal. Especially if you need a precise clock you should use some. Have a look at https://www.adafruit.com/blog/2012/01/24/choosing-the-right-crystal-and-caps-for-your-design/ for example about Load Capacitors.

I know that normally the crystal require load capacitors, but for the low freq. oscilator (32Khz) its not necessary (as far as I have read), that's why I omitted them from the design. I'll try and dig out the datasheets when I'm at home and double check things.

[tbowmo]

@Tibus said:

@tbowmo said:

ATSHA204

This module is verry interesting but how it work? What you have to do in code to make it work, crypting messages,...?

There are other threads about the ATSHA204 around in the forum. It's basically just a method for signing messages between units, not encryption. I haven't made any code for it myself, just thinking about implementing it for future plans (and for others to pick up on)

[RJ_Make]

@tbowmo said:

@Tibus said:

@tbowmo said:

ATSHA204

This module is verry interesting but how it work? What you have to do in code to make it work, crypting messages,...?

There are other threads about the ATSHA204 around in the forum. It's basically just a method for signing messages between units, not encryption. I haven't made any code for it myself, just thinking about implementing it for future plans (and for others to pick up on)

Ah but from what I've read it can indeed encrypt the data stream. Did I completely get it wrong?

[tbowmo]

@ServiceXp said:

@tbowmo said:

@Tibus said:

@tbowmo said:

ATSHA204

This module is verry interesting but how it work? What you have to do in code to make it work, crypting messages,...?

There are other threads about the ATSHA204 around in the forum. It's basically just a method for signing messages between units, not encryption. I haven't made any code for it myself, just thinking about implementing it for future plans (and for others to pick up on)

Ah but from what I've read it can indeed encrypt the data stream. Did I completely get it wrong?

It's a crypto authentication device, datasheet is at
http://www.atmel.com/devices/ATSHA204A.aspx

For sensor data it should be enough, it help to prevent replay attacks, so an intruder can't switch of the lights for example, because the attacker don't have the presharred keys available

[daulagari]

It's a crypto authentication device

As discussed in the security thread I think authentication alone can be useful but encryption is providing both security and a reasonable form of authentication so why not go for an encryption IC instead of the ATSHA204A.

Atmel has a nice IC doing AES:

http://www.atmel.com/devices/ATAES132.aspx

A bit larger (8 pins SOIC), but reasonable cheap € 0,782 (@10)

It is also part of CryptoCape, so there should be some software support for it.

[tbowmo]

@daulagari

That chip is still only for authentication, only it's with aes-128 message auth instead of sha 256

Also another thing i noted, is that the supported supply range is from 2.5 to 5v, whereas the atsha204 could operate down to 2.0v.

[daulagari]

That chip is still only for authentication, only it's with aes-128 message auth instead of sha 256

If I have a look at the datasheet I see:

Opcode Name        Description
0x06   Encrypt     Encrypts 16 or 32 bytes of plaintext data provided by the Host.
0x07   Decrypt     Decrypts 16 or 32 bytes of data provided by the Host after verifying the integrity MAC.

So it does encrypt/decrypt.

The CryptoCape board has both ATSHA204A and ATAES132 where the ATAES132 can "Encrypt up to a 32 byte packet at a time with AES-128-CCM"

Not sure if it is handy to have the integrity MAC combined as that does require 16 additional bytes, but that is the same story for SHA-256.

[tbowmo]

Hmm I was tricked by the "crypto-authentication" note on atmel site, so thought it only did auth.

Still, lowest vcc is 2.5v. If they could make a device that could operate down to 1.8v instead instead, it would be more interesting.

[RJ_Make]

@tbowmo Yeah the 2.5v would be a problem, unless we can build an extremely efficient boost...

[tbowmo]

@ServiceXp

Yes, but I am trying to avoid booster circuits at all costs in this design. Also the main function is to collect temperature and humidity values from around the house. So for my part encryption is not a must have for this device.

btw I'm almost there with rerouting rev 2 to make room for the atsha204 (in sot23 housing)

[tbowmo]

Just reading through the datasheet of ATAES132, and realise that I already have support for it on the board. It uses a standard I2C / SPI eeprom footprint, and that is already on the board. So if anyone would like to use it, they only need to replace the flash.

Anyway, I have finished re-routing things.. and the ATSHA204 is now incorporated in the design, so challenge/response authentication could be implemented.

Just need to do the last couple of reviews, before I press the order button for a new set of pcb's

[RJ_Make]

Is it not possible to just encrypt the entire packet with an AES library on both ends?

[Anticimex]

@tbowmo Does your design support both I2C and single-write ATSHA204?