

SparkFun CryptoShield - MichaelAO
https://www.sparkfun.com/products/13183?utm_source=SparkFun+Customer+Newsletter&utm_campaign=ca1c346c50-April24_newsletter&utm_medium=email&utm_term=0_fa5287abaf-ca1c346c50-61391981

======
mrb
The CryptoShield contains an ATAES132
([https://cdn.sparkfun.com/datasheets/Dev/Beagle/Atmel-8760-Cr...](https://cdn.sparkfun.com/datasheets/Dev/Beagle/Atmel-8760-CryptoAuth-
ATAES132-Datasheet.pdf)). I spent 10min reading the datasheet and this chip
makes zero sense to me.

It supports features like "encrypted writes" where the host microcontroller
encrypts data, sends the ciphertext on the SPI link, ATAES132 decrypts it, and
stores the plaintext in internal EEPROM. Later the host can do "encrypted
reads" where ATAES132 reads the plaintext from internal EEPROM, encrypts it
(possibly with a different key), sends it on the SPI link, and the host
decrypts the ciphertext.

Firstly, there is no mechanism in place for the host to securely share a key
with ATAES132. The key would have to be pre-shared during manufacturing.
Secondly, if the host has to have the key and has to do encryption/decryption
by itself, why not just read/write encrypted data on a standard SPI EEPROM?
Thirdly, if I am misunderstanding things and in fact plaintext or keys are
exchanged on the SPI link, then nothing stops an attacker from sniffing the
SPI link or doing active MitM attacks.

This whole chip smells like it was invented to satisfy PHBs who demand crypto
but who have no understanding how to implement crypto correctly.

~~~
unwiredben
The EncWrite command looks to be a way to write new crypto keys into the
chip's memory. You have to encrypt the key on the host side with the master
key for the device, and it authenticates that data to not allow writes of
random data. The chip has ways to write master keys into it, then blow fuses
preventing those keys from being modified -- I would expect you'd use these in
pairs during your device manufacturing to setup a shared secret that wasn't
available from the host CPU.

------
CHY872
I have no doubt that a few people will buy this device, but it costs $60. Add
to an Arduino for like $20 and you're fast heading towards $100 for a device
that can do very little. If your project is actually so complicated that you
need strong crypto, why not just use a Raspberry Pi?

Power usage approaches Raspberry Pi anyway; the RTC in this device uses
between 0.75 and 1W

~~~
morcheeba
Really? 0.75-1W for an RTC that has a standby mode based on a coin cell? That
sounds crazy! It's an SO8 package - can that even dissipate that much power?!
Sounds double-crazy!!

Oh, wait, datasheet says its 0.0015mW max.
[https://cdn.sparkfun.com/datasheets/Dev/Beagle/DS3231M.pdf](https://cdn.sparkfun.com/datasheets/Dev/Beagle/DS3231M.pdf)
And 1 Watt would make the part run at 120˚C above ambient.

~~~
teraflop
> Oh, wait, datasheet says its 0.0015mW max

I think you mean 1.5mW.

~~~
morcheeba
Whoops, thanks. I actually meant 0.0015 W to keep the units the same.

------
beagle3
For practical uses, it's probably better to get a $50 YubiKey Neo and plug it
into the USB port of a Raspberry Pi ($25 if you get the Model A).

Crypto is easy to get wrong in every corner - and using a Neo+GPG it's more
likely to actually work (plus, it's FIPS-140 certified)

For learning, this seems cool - although I don't see the ways in which it is
more educating than software only crypto.

------
neurotech1
Why wouldn't you just use a small FPGA as crypto-processor, or does that
defeat the purpose of the device using cypto-in-silicon?

~~~
nosuchthing
FPGA for $60..??

------
mrmondo
Why can't this be shipped outside America?

------
nickodell
Interesting. I assume the ECDSA module is to allow people to sign Bitcoin
transactions.

~~~
tptacek
I don't think that Atmel part supports the right curve.

------
orthecreedence
Maybe I missed it, but I don't see ROT13 or base64 anywhere in the features.
How can they call this a crypto chip?

