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.
Online Training with Josh
Learn how to secure your design with the ATECC608A with Josh’s online training at Advanced Security.
2020 Update: Microchip Security Design Partner
Cryptotronix is now an official Microchip Security Design Partner! If you’d like assistance incorporating CryptoAuthentication into your design or using the Microchip Trust Platform, reach out to hello@cryptotronix.com!
Overview of CryptoAuthentication Products
At Cryptotronix, we’ve been using the CryptoAuthentication parts starting with the original ATSHA204s and ATECC108s on the CryptoCape and the CryptoShield. What I like about these parts is that:
– They are small (UDFN packages)
– They are cheap (608s are $.58-ish 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.
Wishlist
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.
Updates:
16 February 2018 – Price of ATECC608A @ 5,000 pcs. updated to .58c based on Microchip’s site.
Hi Josh, really nice work. In https://vitrotv.com/ we were able to implement ECC508A quite some time ago and there was no indication of support for embedded Linux. Device should work with default i2c driver + HAL for CryptoAuthlib, but there are some additional problems that developer have to solve. I’m not saying about enabling higher layer, setting up certificates supply chain, cloud configuration and prepare correct, automated environment for manufacturing. In vitroTV/vitroIO We went through all those problems getting through lack of support from community and vendors. On the other hand what is the purpose of Linux kernel driver ? We cannot treat this engine as accelerator, but more like secure storage other chips for which drivers are mainlined seem to be used as smart card or usb key, do you think about those use cases ?
When I first did that driver: Atmel’s CryptoAuthLib wasn’t all that great and on PCB hardware that supported ECC, like TPM 2.0 weren’t quite around. So nowadays, using Microchip’s cryptoauth lib would be fine as would be uisng the normal /dev/i2c interface. My kernel module tried to add hwrng support and to give a basic sysfs. It also implemented the CRC in kernel space so that you could use python or something to talk to /dev/atshaX instead of using C. It has bitrotted perhaps but there once at least one group who used it for something.
Compared to a Cortex A though, this chip is not so fast but if you use it for ECDSA signing in TLS, (and WolfSSL did a port of this I think), then you still get the key isolation in the device and can use the main processor for the rest of the handshake. You could also perhaps use the ATECC508/608 for encrypted firmware delivery by storing keys in the part burned in during manufacturing. Especially now that the 608 has AES.
Agree on use cases. We using it to have full stack connection with cloud providers requiring TLSv1.2 handashake as ground for MQTT. We also leverage that infrastrucutre to provide secure updates. Problem with WolfSSL is that IMO is extremly expensive for value they give. We enabled OpenSSL engine with whole stack on top of /dev/i2c for Cortex-A level device.
ECC508/608 are great parts from manufacturer who doesn’t have good history in open source community. Microchip as well as others do incredibly good hardware for its use case, but fail to provide reasonable path for real enablement of product for industrial market. What is even worse they spin hype around new parts that they have everything, what in reality mean that they give you components which are enabled for one small use case in narrow area of prototype. If you want to go to the market you need decent team of engineers who know what they do and can play from embedded i2c timing problems to CA REST API integration in the cloud. Anyonw who read about ECC608 should try look at marketing notes from vendor with grain of salt.
Going little bit offtopic I’m not huge fan of consumer market where there is assumption that Cortex-M level devices talk directly over IP through public Internet. This is what those chipse seems to target and this is what big cloud providers talk about. IMO reality is little bit different. My view is that we typically go through some kind of gateway to reach outside world just because number of non-IP protocols in the market is so huge and IoT largely is created by devices behind those protocols.
I’m glad you posting about this parts and engaged in community since this areas seems to be neglected by vendors, support is terrible, code and sample applications don’t work. I believe there is need for more people trying ot make this ground free to lower entry barier.
after provisioning the 608A if someone was to remove it from a workign device, and attempt to use it in something else, to ‘spoof’ the identity of it, how woudl you be able to detect that?
If I understand the question, you are asking how to prevent the use of the 608A on other hardware if it’s been lifted from the original device? If so there are a few ways. One which I’ve done before is to use the check mac feature of the chips which prevents uses of the signing (or exchange) keys unless a valid challenge-response like MAC has been performed. You’ll need to store the MAC key in your main MCU though and keep that secure.
But if you can do that, it prevents this attack as an attacker will not be able to impersonate your device (unless they also get the MAC key).
More to that, MAC can be enabled in per slot basis so each key can be protected separately. There are also other features like anit-tampering which can lead to disable key access when unauthorized access to hardware were detected. Also to strength initial authentication input digest can be encrypted with nonce generated by 608A and secret known by both sides.
Of course if someone will get access to MCU and there is no use of strong security then secret can be revealed, that’s why secret should be generated in trusted manufacturing environment and different for each MCU and 608A pair.
Thanks thats been really helpful.
you can find the kernel driver for ecc508 mainlined in kernel starting with version 4.14:
https://elixir.free-electrons.com/linux/latest/source/drivers/crypto/atmel-ecc.c
Oh nice, this is exciting, thanks for posting! On a quick glance it’s nice they perform the ECDH commands kernel-side. Now the fun begins to backport this to all the vendor SoCs I work with 😉