3 ms·

The CryptoShield contains an ATAES132 (https://cdn.sparkfun.com/datasheets/Dev/Beagle/Atmel-8760-CryptoAuth-ATAES132-Datasheet.pdf https://cdn.sparkfun.com/data

by mrb 12y ago

The CryptoShield contains an ATAES132 (https://cdn.sparkfun.com/datasheets/Dev/Beagle/Atmel-8760-CryptoAuth-ATAES132-Datasheet.pdf https://cdn.sparkfun.com/datasheets/Dev/Beagle/Atmel-8760-Cr...). 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 12y ago
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.
mindslight 12y ago
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" ! ) IMHO there isn't a specific purpose for each of the chips included (like most dev boards). It's just one each of http://www.atmel.com/products/security-ics/cryptoauthentication/default.aspx http://www.atmel.com/products/security-ics/cryptoauthenticat... and their TPM. The individual chips are only $1 for singles.
locacorten 12y ago
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.

by mrb 12y ago

unwiredben 12y ago

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.

mindslight 12y ago

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" ! ) IMHO there isn't a specific purpose for each of the chips included (like most dev boards). It's just one each of http://www.atmel.com/products/security-ics/cryptoauthentication/default.aspx http://www.atmel.com/products/security-ics/cryptoauthenticat... and their TPM. The individual chips are only $1 for singles.

locacorten 12y ago

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.