Minimal design thoughts
-
@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,...?
@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)
-
@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)
@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?
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?
@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.aspxFor 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
-
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.
-
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.
-
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.
-
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.
-
@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)
-
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
-
Is it not possible to just encrypt the entire packet with an AES library on both ends?
-
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
-
It's single wire atsha204, it's connected to A3. I couldn't fit in the 8 pin variants of the atsha204, so that ruled out the full I2C bus version. It even took me a couple of hours of re-routing to make enough room for the sot23 housing of the ATSHA204.
Anyway, schematic / pcb layouts are as follows
-
It's single wire atsha204, it's connected to A3. I couldn't fit in the 8 pin variants of the atsha204, so that ruled out the full I2C bus version. It even took me a couple of hours of re-routing to make enough room for the sot23 housing of the ATSHA204.
Anyway, schematic / pcb layouts are as follows
-
It's single wire atsha204, it's connected to A3. I couldn't fit in the 8 pin variants of the atsha204, so that ruled out the full I2C bus version. It even took me a couple of hours of re-routing to make enough room for the sot23 housing of the ATSHA204.
Anyway, schematic / pcb layouts are as follows
-
I wonder what kind of "hit" on battery life authentication/encryption will have?
-
I do not think it is a big issue. Authentication is normally only needed on nodes that have actuators. And this implies that they always have to listen for incoming data and are therefore inherently non-battery friendly The ATSHA has a very low power consumption, so the added cost for message signing procedures is probably negligible compared to the cost of running the radio continuously.
-
Hmm thinking about it, authentication could be valuable on sensors as well.
If you use the sensor readings to control another actuator, then an attacker could send in his own bogus sensor values in order to trigger system events. He does need to know the specifics about your setup though, so the question is if it's affordable to the mischief to do anything like that :)
-
Yep. This is true, and something I eventually have to add support for.
