Ataes132a fails to encrypt/decrypt with mode ECB and CCM mode

[nashif]

Reported by ethan gao:

From the datasheet of ataes132a, it supports h/w AES encryption mode of legacy and CCM, and try to test Zephyr driver implementation of ataes132a using Atmel CAXplainedPro which supports ataes132a/atsha204/atecc508a, but the ecryption/decryption fails with current driver. please check the details from the log attached.

[how to reproduce]

1. clone Zephyr repo and prepare the build environment
2. connect CAXplainedPro to I2C 0 of quark_se_c1000_devboard, then download the test attached and run "make pristine && make BOARD=quark_se_c1000_devboard flash"
3. check the UART output

(Imported from Jira ZEP-1796)

[nashif]

by ethan gao:

• ACES_start.png (size: 35839)

[nashif]

by ethan gao:

• test_ataes132a.log (size: 2204)

[nashif]

by ethan gao:

• test_ataes132a.tar.gz (size: 2558)

[nashif]

by Juan Manuel Cruz Alcaraz:

Can you give more information on the tools you are using to configure and load/generate the crypto key inside the ATAES132A device?

[nashif]

by Juan Manuel Cruz Alcaraz:

Also please comment on the configuration you are using for the Crypto Key index 0.

[nashif]

by ethan gao:

Juan Manuel Cruz Alcaraz Actually, I use the default key configuration of all, but I think the key configuration can be changed with I2C writing to the corresponding key configuration memory if I'm not wrong. Regarding load/generate the crypto key, my understanding is that there're already 16 128-bit key stored in the ATAES132A to be used directly, maybe a "load" operation is necessary to use the key and I see there is "KeyLoad" command in the Spec, but I don't see its implementation in the ATAES132A driver. So... In a nutshell, my current checking changes nothing but to directly employ the driver to run.

[nashif]

by Juan Manuel Cruz Alcaraz:

My device contains all the key configuration space setup to 0xFF out of the box. That configuration is not a good configuration. The device, in production environment, is designed to be configured once, to load key once (except for volatile keys that my driver does not support yet) and to LOCK the configuration and the key storage. After that, the devices can be distributed and an application software can use the device for secure storage or authentication as a PTM. You can use the Atmel Crypto Evaluatio Studio software to access the configuration zones and modify them and to load keys into the key storage zone.

You can get a good overview about the Atmel Studio software in this link:

https://www.youtube.com/watch?v=SFpkqmwoEeg&t=1223s

and get the software from this other link:

http://www.atmel.com/tools/CryptoAuthXplainedPro.aspx

You can also configure the device and load a key with I2C commands, in that case a scripted solution can help you to configure your device as well.

I have not found any reference about a crypto key loaded by default. Do you have the reference to the document that explains this defult key? I might be missing something to be able to support the default key but I'm missing the documentation as well.

Thanks.

[nashif]

by Juan Manuel Cruz Alcaraz:

Additionally you can see that the key configuration is not correct in the following lines of the log:

[general] [ERR] ataes132a_aes_ecb_block: key 0 legacy mode disabled

Legacy Mode Disabled means that the key is not allowed to do ECB encryption.

[general] [DBG] ataes132a_aes_ccm_encrypt: keep in mind key 0 will require previous authentication

This log means the key requires previous key authentication. Key authentication is not supported by the API yet. Please configure your key to not require authentication.

[nashif]

by ethan gao:

Juan Manuel Cruz Alcaraz I see there're default configuration definition at section "Appendix O. Default Configuration". yeah, what's your device and have you successfully encrypted/decrypted with the driver in ECB/CCM mode? I see some other operations like those related to AUTH or KEY etc in the datasheet are not implemented in the current driver, will they be planned to enable in the future ? moreover, I think, the APIs to configure and load key is necessary and it's very basic to use the device, or it seems a little hard to use, do you think so ?

One more question, I see it's 4 bytes of keyconfig for each 16 keys in Spec, but the length in driver is "uint8_t", any special consideration ?

[nashif]

by Juan Manuel Cruz Alcaraz:

Thanks for the pointers to the default configuration. I will test the driver with this specific settings. Nevertheless, my device did not bring the default configuration loaded. It was 0xFF all across the configuration zone. I had to configure it all over.

The related operations like AUTH and KEY are not implemented because they are not part of the standard Crypto Standard API proposed for Zephyr. (https://gerrit.zephyrproject.org/r/#/c/3311/)

Most of this operations should be added in future expansions of the driver and Crypto API. Actually there is the need to define a Crypto API for authorization and maybe for key management (currently it only supports encryption services).

About the load key functionality, this sort of devices are designed to be deployed with crypto keys already pre-loaded and locked inside the device. The process of loading and locking happens during manufacturing time. If you are working with a POC or doing research, the keys can be configured and loaded with an evaluation tool.

For these reasons, the key management is not needed to be supported as part of the Zephyr crypto driver. We could provide a tool to allow the users to configure and load keys, but that would be redundant to the tools already provided by Atmel.

[nashif]

by Juan Manuel Cruz Alcaraz:

Regarding your last question. Indeed this is a very keen observation. In this case I'm just reading the Byte0 of the KeyConfiguration. This is because most of the information I need to validate the key is found in the first byte. In case that I need to access Byte1 to Byte3 I would need to read the Key Config address plus the required offset.

In the section E.2.19 from the ATAES132A spec you can find the definition of every bit in the Byte0 and verify that you can read the LegacyOK field and the AuthKey field as well as the ExternalCrypto field.

[nashif]

by Mark Linkmeyer:

Juan Manuel Cruz Alcaraz , what's the current status of this bug? Kuo-Lang Tseng

[nashif]

by Kuo-Lang Tseng:

ethan gao , Juan Manuel Cruz Alcaraz had some suggestion earlier on how to load a Crypto key before you can use the driver. Were you able to do that yet? I pasted that comment from Juan:

You can use the Atmel Crypto Evaluatio Studio software to access the configuration zones and modify them and to load keys into the key storage zone.

Please let us know if you see any issue of getting the Crypto key loaded as this is required to use the driver currently. Thanks. Mark Linkmeyer

[nashif]

by ethan gao:

Juan Manuel Cruz Alcaraz Kuo-Lang Tseng It seems that it requires to connect CAXPlainedPro to a paired XPRO boards(http://www.atmel.com/products/microcontrollers/avr/xplained.aspx) of Atmel to allow the detection by the Atmel Crypto Evaluatio Studio software, or it indicates the following after start-up: !ACES_start.png|thumbnail!

But I checked the driver using the Intel quark_se_c1000_devboard with I2C wired to the CAXplainedPro add-on board, so it doesn't work for me :(

[nashif]

by Mark Linkmeyer:

Moving to To Do since it's no longer being actively worked on.

[nashif]

by Mark Linkmeyer:

manoj subbarao , please assign to proper owner.

[nashif]

by Leandro Pereira:

This requires hardware I don't currently have. Working on obtaining it.

[nashif]

by Leandro Pereira:

I got the hardware (ATCRYTOAUTH-XPRO evaluation kit from Atmel), and will be able to take a look at this shortly.