Recently, Microchip announced a new part, the ATECC608A, which is the latest in their CryptoAuthentication Line. It is a crypto co-processor and a nice improvement over the ATECC508A, as long as you understand its limitations.
Overview of CryptoAuthentication Products
– They are small (UDFN packages)
– They are cheap (608s are $.84 in 5,000pcs)
– They draw little power (150 nA sleep, 14mA in most intense command for 608A).
– Unlike other similar parts, the Microchip ones are available on DigiKey and common distributors.
But most importantly they provide secure key storage and secure execution for NIST P256 Elliptic-Curve Cryptography keys. The current ATECC508A, which is the predecessor to the 608A, is a neat chip because it not only supports the Elliptic Curve Digital Signature Algorithm for NIST P256 keys, but it can also perform Elliptic Curve Diffie Hellman Key Exchange. Which means that the part can hold the asymmetric keys for a TLS exchange and deliver the master secret to the microcontroller for the symmetric portions of the protocol. The ATECC508A is still a useful part but the ATECC608A adds some additional features.
New Features of the the ATECC608A
Section 3.1.1 of the summary datasheet lists 17 new features on this part from the ATECC508A but the three that stand out to me are: AES encrypt/decrypt, Galois Field Multiplication calculations to support AES Galois Counter Mode, and Key Derivation Functions. One limitations of previous parts is the lack of an encryption engine. The ATAES132A does have encryption, but I’ve found it a bit harder to use then the ATECC parts. So with the encryption engine built in, the ATECC608A is a single-chip solution if you need a secure symmetric key storage.
But, the mode of encryption is critical which is why I’m excited to see GFM support. It appears that to fully implement AES GCM in your product, the host side software may have to coordinate with the ATECC608A, so I’m curious on how exactly AES-GCM works with this part. Authenticated encryption schemes, like AES-GCM provide both confidentiality and authentication and should generally be used over non-authenticated ciphers. Lastly, having KDFs built-in, especially HMAC-based Extract-and-Expand Key Derivation Function (HKDF) for TLS 1.3 support is handy. Besides TLS support, HKDF can be used to generate sub keys for different uses in your design so that you can keep each key isolated to a single key purpose (which is a UL 2900-1 requirement and best practice).
The TLS support is useful because Azure, AWS, and Google cloud platforms all offer an IoT product of sorts that is MQTT based. MQTT is a popular publish-subscribe protocol that offers zero security by-design. The security all comes from TLS and only if you use TLS with client-certificates, which all platforms do. So your device (the client) needs a certificate, which means it needs a private key and a secure storage for that key, which is where the ATECC608A helps. It will keep the private key and use it for the TLS handshake to establish a secure channel and authenticate itself to your cloud provider. This also provides an unique cryptographic identity, assuming you create unique keys in each device.
So it looks like the ATECC608A is forward-looking to TLS 1.3 support–this is great future-proofing on the cryptographic hardware side. The CryptoAuthentication parts are an easy hardware design add-on if your microcontroller doesn’t already support secure key storage or have a secure boot option. I’m excited for the new ARM Cortex M23 and M33 designs which will have ARM TrustZone v8, a redesigned TrustZone for Cortex M, but until they are on the market the current Cortex M series at best has on-die crypto accelerators and “secure storage” if only you treat internal NVM as secure and disable CPU debug capabilities.
Limitations of the ATECC608A
Which brings me to the limitations of this part. Realize that this part is not “bolt-on” security. You still need to do proper threat modeling for your design. If you add this part but leave JTAG enabled on your microcontroller, you might not receive the security benefits you think. It depends on your application, market, and perceived threats. As nice as this part is, you also need to consider the effect of a silicon bug that compromises your security. We’ve seen it for the IMx product line and Intel Management Engine. It’s not a particularly fun table-top exercise to think through, but if ATECC608A has a bug (and bugs for security products are known as vulnerabilities), what is your backup plan? Not to pick on the ATECC608A, but security is best done defense-in-depth. This concern also depends greatly on your product lifecycle. If you are making a consumable, you will be able to change out the part in the next batch but for a 10 year battery-powered industrial device, you may care a bit more.
On the AES engine, its not clear if this part has any Differential Power Analysis protection. It’s not mentioned in the summary data sheet. Power analysis attacks are very powerful semi-invasive attacks that can be performed with tools like the ChipWhisperer. Some parts, that have EAL or FIPS 140-2 certification include DPA countermeasures for the defense or financial industries. If power analysis attacks are a concern for your threat model, you should try to limit the use of an AES key and rotate it more frequently. The ATECC608A does claim a glitch filter that will screen off pulses less then 45ns, but it be nice to see some testing of this part against the ChipWhisperer like we did the TREZOR hardware wallet.
Also while Microchip does release host-side software which will do most of what you want, the full datasheet is under NDA. Microchip is really ahead of the group here with their parts in open distributors and with software that’s accessible, but if you are going to use this in a product you probably want to get the NDA signed.
Lastly, the big impact for an OEM is how to securely provision the unique certificates in the manufacturing process. We’ve helped a few clients here and the process largely depends on your business practices and again, your threat model. Microchip has a provisioning service, but you will have to source the part through them or you can have firmware that runs on the device. If manufacturing security is a big concern you can incorporate a hardware security module in the provisioning process as well.
The ATECC608A like any security technology is not magic, but I think it does have a sweet spot for low power, Internet connected devices that want a relatively easy way to add hardware protection for cryptographic keying material. Also, it is much easier to add this UDFN part to an existing design then to refactor your existing product with a new microcontroller.
I’m still waiting for parts like this one that support DJB cryptography and secp256k1 (Bitcoin curve) but I haven’t found them yet. Maybe with new ARM TrustZone for Cortex M there can be software implementations of those ciphers in the new TrustZone for low power devices.
Development with the CryptoAuthentication Family
Now, to be honest, if you work have to develop software for these chips (or any security chips really) it’s kind of a pain. It’s a pain because inevitably you will have to perform some one-way state-alerting function. You really don’t want to test your firmware on your production, form-factor PCB. Otherwise you will realize you misconfigured the chip and they can now become cufflinks.
What you want is to use a socket so you can pop chips in-and-out as you test your design. The Microchip AT88CK101SK kit is quite nice for this and there is stand alone Windows software (ACES) that’s nice and all, but sometimes you want to use open source Linux tools.
So, we’ve been working on a Crypto Programmer tool designed for the CryptoAuthentication line that we are beginning to release as Open Source Hardware (it’s not quite Open Source Hardware yet, we’ve some more work to do). Basically, it’s a USB to I2C bridge using a Microchip L21 that will eventually let you send I2C commands to the part via host-side scripting. The benefit is that you can test device configuration using host-side scripting languages without having to futz around with embedded firmware and hardware. This is useful for development but also research. What if you wanted to fuzz test the part? Or perhaps dump the memory configuration? We are releasing revision A of the hardware on GitHub today, with the software soon-ish to follow.
Sales pitch part of the blog post
We’ve ported the CryptoAuthentication library to a few microcontrollers, ARM Cortex Ms with no-OS up to and including embedded Linux. I had even started a Linux Kernel Driver that needs some love, but otherwise works with the CryptoAuthentication line. [Update: CryptoAuthLib v.3 includes a Linux HAL so you can run a userspace app using the kernel’s native I2C interface]. We’ve setup rather complex memory layouts using the part besides just the basic “store a key and use it” solutions, including a design that went through a rather intensive hardware penetration test without issue. So, if you want to add a CryptoAuthentication part to your design and like help with the surrounding hardware and firmware security, contact us.