Personal Review of the ATECC608A CryptoAuthentication on the Nano 33 IOT
I was extremely excited to see that Arduino was offering a relatively inexpensive board that offered hardware encryption and key storage. The Nano 33 IOT and related boards recently released from Arduino advertise many features including an integrated ATECC608A CryptoAuthentication chip.
However once I received them my frustration began immediately. Neither Arduino nor Microtel offer much in the way of useful documentation on these chips. Microtel offers a proliferous amount of not very useful documentation here:
https://www.microchip.com/wwwproducts/en/ATECC608A#additional-features
They also offer a library https://github.com/MicrochipTech/cryptoauthlib.
The Nano 33 Sports a SAMD21 Cortex - MO Low Power Processor (data sheet).
The ATECC608A supports a single wire interface and an I2C interface. The Nano 33 uses hardware serial for their default I2C bus which is wired to the ATECC608A. So they are leveraging I2C. But the only support the Microtel library offers for the SAMD21 processor is in the form of a bit bang hardware abstraction layer which fails to leverage the hardware serial provided by the SAMD21 processor. So you are immediately forced to try to develop a convoluted HAL interface to the Microtel library, or throw out the garbage (which comprises 90%) of the library and start over. Like I did here nano33crypto library
The Microtel library tries to be a one size fits all library so that it can be used with any platform, but it fails miserably. Furthermore in spite of literally dozens of PDF files provided by Microtel, on their cryptochip, the only reliable documentation is this source code, and it is completely inadequate to the task.
It is not unreasonable to expect that a chip vendor would provide a document that documents their I2C address space, the I2C op codes with expected parameters and semantics in a single document. Such a document would only be around 60 to 80 pages for this chip at most. But they are too lazy to document their hardware, and Arduino perpetuates this laziness by selling these chips with no support.
Worse yet, it is evident that the chips delivered on the Nano 33 have already had their Configuration Zone locked since the I2C slave address on the Nano is 0x6A. But the default address per the Microtel documentation is 0xC0. Per the Microtel documentation before the default address can be changed the Configuration zone must be locked, and then the I2C address can only be changed once. This is a documentation fail on the part of Arduino.
The return values are not well guarded on the I2C interface either. Microtel fails to disclose simple facts such as how many blocks of information are in the Configuration zone, but if you send I2C requests to the chip to read configuration from non existent blocks, rather than getting back NACK error from the chip, you get back data that is inconsistent with their documentation. This lack of boundary checking on the interface indicates slipshod design. Of course it is entirely possible that since the chip is not documented except via source code, the testing I conducted could be incorrect, but we won't ever know since this is a nearly black box chip. I would be happy to share the results of my testing with any interested party. Test code
While the idea of integrating this roughly 45 cent crypto chip on an Arduino board is very promising, the sloppy engineering practices apparent in the implementation of the ATECC608A on the Nano 33 leads me to question whether these two companies are the right companies to lead the way and their opaqueness leaves me to question whether they are confident in the security of their implementation.
However once I received them my frustration began immediately. Neither Arduino nor Microtel offer much in the way of useful documentation on these chips. Microtel offers a proliferous amount of not very useful documentation here:
https://www.microchip.com/wwwproducts/en/ATECC608A#additional-features
They also offer a library https://github.com/MicrochipTech/cryptoauthlib.
The Nano 33 Sports a SAMD21 Cortex - MO Low Power Processor (data sheet).
The ATECC608A supports a single wire interface and an I2C interface. The Nano 33 uses hardware serial for their default I2C bus which is wired to the ATECC608A. So they are leveraging I2C. But the only support the Microtel library offers for the SAMD21 processor is in the form of a bit bang hardware abstraction layer which fails to leverage the hardware serial provided by the SAMD21 processor. So you are immediately forced to try to develop a convoluted HAL interface to the Microtel library, or throw out the garbage (which comprises 90%) of the library and start over. Like I did here nano33crypto library
The Microtel library tries to be a one size fits all library so that it can be used with any platform, but it fails miserably. Furthermore in spite of literally dozens of PDF files provided by Microtel, on their cryptochip, the only reliable documentation is this source code, and it is completely inadequate to the task.
It is not unreasonable to expect that a chip vendor would provide a document that documents their I2C address space, the I2C op codes with expected parameters and semantics in a single document. Such a document would only be around 60 to 80 pages for this chip at most. But they are too lazy to document their hardware, and Arduino perpetuates this laziness by selling these chips with no support.
Worse yet, it is evident that the chips delivered on the Nano 33 have already had their Configuration Zone locked since the I2C slave address on the Nano is 0x6A. But the default address per the Microtel documentation is 0xC0. Per the Microtel documentation before the default address can be changed the Configuration zone must be locked, and then the I2C address can only be changed once. This is a documentation fail on the part of Arduino.
The return values are not well guarded on the I2C interface either. Microtel fails to disclose simple facts such as how many blocks of information are in the Configuration zone, but if you send I2C requests to the chip to read configuration from non existent blocks, rather than getting back NACK error from the chip, you get back data that is inconsistent with their documentation. This lack of boundary checking on the interface indicates slipshod design. Of course it is entirely possible that since the chip is not documented except via source code, the testing I conducted could be incorrect, but we won't ever know since this is a nearly black box chip. I would be happy to share the results of my testing with any interested party. Test code
While the idea of integrating this roughly 45 cent crypto chip on an Arduino board is very promising, the sloppy engineering practices apparent in the implementation of the ATECC608A on the Nano 33 leads me to question whether these two companies are the right companies to lead the way and their opaqueness leaves me to question whether they are confident in the security of their implementation.
Comments
Post a Comment