With the recent announcement of Arduino’s Uno WiFi Rev2 at Bay Area Maker Faire the USA store’s product page launched with this opening description:
Using a brand new 8-bit microprocessor from Microchip for the first time on an Arduino board. Explore the possibilities with the onboard IMU (Inertial Measurement Unit). Connect the board to your Wi-Fi network in a secure manner using the new ECC608 crypto chip accelerator.
“Crypto chip” may sound spooky or at least novel to some but the chip, from Microchip, available in 8-lead SOIC or 8-pad UDFN packages, boasts the following core features:
- Cryptographic co-processor with secure hardware-based key storage
- Protected storage for up to 16 Keys, certificates or data
- ECDH: FIPS SP800-56A Elliptic Curve Diffie-Hellman
- NIST standard P256 elliptic curve support
- SHA-256 & HMAC hash including off-chip context save/restore
- AES-128: encrypt/decrypt, galois field multiply for GCM
Expect to hear more about “crypto chips” (not those kind, silly) in the months and years ahead as devices like the ECC608 make their way into more-mainstream boards. But what does it mean practically for makers and their projects? Thankfully Josh Datko from Cryptotronix has a write-up from late last year about the ECC608 and both its limitations and improvements over its 508 predecessor:
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.
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).