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.
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.
These devices are generally targeted at applications where integrity of the host microcontroller isn't taken for granted. Where you describe the "host microcontroller encrypts data", most likely the envisioned application is some remote server doing that encryption and the μC is just passing encrypted blobs between the two. The keys are indeed generated/shared at manufacture time, since the primary goal is "protecting" against the device's user.
It's odd to see these chips get attention, as I just ordered some of them to play around with no particular goal in mind. It did make it easier to find out what public information is available on the ECC and TPM chips (the actual datasheets are NDA-only - a sure sign we're dealing with people who have a much different view of "crypto" ! )
I have a question about your first point. What other options are there other than sharing a secret key at manufacturing? I'd like to learn more about these other options. Thanks.
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
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!!
Yeah, but this doesn't teach you about cryptography except for using it (which you could do on the Pi) because it's a black box, so doesn't teach you any more about embedded systems than a normal Arduino and a few cheap extensions. I'm not knocking the Arduino - it's a fantastic bit of kit and I've had great fun with mine, but this is a very expensive learning experience for the amount that you can learn.
For rapid prototyping - the rapid prototyper shouldn't be dealing with cryptographic primitives full stop.
It's $60, but consider that as a cost not for a production device, but instead as a commercial development board, letting you get hands-on experience working with each of the chips on the board before you design them into a mass-production product.
While that's true, the chips aren't themselves cheap; together they cost £6.90 (if I read the pages right) if you're buying from digikey by the 500.
The bigger concern is what you're actually doing with the crypto. Almost every use for crypto is intrinsically linked to transmitting the encrypted data; the amount of work to do something nontrivial would be pretty mental.
Any commercial project would probably approach the problem at a higher level; i.e. you'd buy an ARM microcontroller and a TLS stack.
I think you are entirely missing the point of these Atmel chips.
More generally (and this is not necessarily addressed to you specifically), I find the knee-jerk response of "just use a Raspberry Pi" amusing. I design embedded systems. Raspberry Pi is, at a first approximation, completely useless, for any task you might want to throw at it.
There are many reasons. Power consumption, complexity, failure rate, poor reliability, reliance on SD cards, poor SD card reliability, poor peripherals, poor documentation, I could go on. RPI has two things going for it: 1) the video processing peripherals, 2) publicity/popularity.
Now, when thinking about embedded systems, most of the time I won't even consider things the size of a Pi (or the much, much better BeagleBone Black). They are monsters, enormously complex and power-hungry beasts. What I will consider are MSP430s, STM32s, Kinetis K and L, and similar — so ARM Cortex M0, M0+ and M4 cores, running at about 50MHz, consuming around 60mW of power (about as much as an LED), and taking up about, say, 8mm2 of board space (that includes all necessary passives). These are well documented, have reasonable complexity, and can be programmed carefully to achieve excellent reliability.
These systems also need crypto, and by crypto I don't just mean "accelerated AES". The Atmel security line is not just "accelerators".
In other words, this board is a very interesting prototyping tool, and no, the answer to any problem is not "just use a Raspberry Pi".
Well, the point of using special-purpose chips like the ATAES132, which has a hardware implementation of AES, is so you wouldn't have to implement the algorithm in AVR.
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.