Tag Archives: B283 and K283 binary curves

ATECC108 deep dive: Part 2

Yesterday we took our first ATECC108 deep dive, exploring various features and capabilities of the device, including firmware protection, anti-counterfeiting and secure data storage. Today, we will take a closer look at the ATECC108’s advanced cryptographic operation.

As previously discussed on Bits & Pieces, Atmel’s ATECC108 implements a complete asymmetric (public/private) key cryptographic signature solution based on Elliptic Curve Cryptography and the ECDSA signature protocol. The device also features hardware acceleration for the NIST standard P256, B283 and K283 binary curves – while supporting the complete key life cycle from high quality private key generation, ECDSA signature generation and public key signature verification.

It should be noted that the hardware accelerator is capable of implementing asymmetric cryptographic operations 10 to 1,000 times faster than software running on standard microprocessors – without the usual high risk of key exposure.

“In addition, the device is designed to be able to securely store multiple private keys along with their public keys and the signature components of the corresponding certificates. The signature verification command can use any stored or external ECC public key,” an Atmel engineering rep told Bits & Pieces.

“Public keys stored within the device can be configured to require validation via a certificate chain to speed up future device authentication, while random private key generation is supported internally within the device to ensure the private key can never be known outside the device. The public key corresponding to a stored private key is always returned when the key is generated and may optionally be computed at a later time.”

Atmel’s ATECC108 also supports a standard hash-based challenge response protocol to simplify programming for developers and engineers. At its most basic, the system sends a challenge to the device, combining it with a secret key via the MAC command and subsequently returning a response. More specifically, the device employs a SHA-256 cryptographic hash algorithm for the combination such that an observer on the bus cannot derive the value of the secret key – although the recipient can verify that the response is correct by performing the same calculation with a stored copy of the key.

“Due to the flexible command set of the ATECC108, these two basic operation sets (ECDSA signatures and SHA-256 challenge-response) can be expanded in many ways,” the engineering rep continued.

“Using the GenDig command, the values in other slots can be included in the response digest or signature, which provides an effective way of proving that a data read really did originate from the device, as opposed to being inserted by a man-in-the-middle attacker. This same command can be used to combine two keys with the challenge, which is useful when there are multiple layers of authentication to be performed.”

Meanwhile, the DeriveKey command implements a key rolling scheme. Depending on the command mode parameter, the resulting operation can be similar to one implemented in a remote-controlled garage door opener. Meaning, each time the key is used, the current value of the key is cryptographically combined with a value specific to that system, and the result forms the key for the next cryptographic operation. So even if an attacker obtains the value of one key, that key will actually be gone forever with the next use.

As expected, the DeriveKey command can also be used to generate new random keys that may be valid only for a particular Host ID, for a specific time period, or for some other restricted environment. Of course, each generated key is different than any other key ever generated on any device. By activating a Host-Client pair in the field in this manner, a clone of a single client will not work on any other Host.

In a Host-Client configuration, where the Host (for instance a mobile phone) is required to verify a client (for instance an OEM battery), there is a need to store the secret in the Host in order to validate the response from the Client. The ATECC108‘s CheckMac command allows the device to securely store the secret in the Host system, concealing the correct response value from the pins by returning only a yes or no answer to the system. Where a user-entered password is required, the CheckMac command also provides a way to both verify the password without exposing it on the communications bus, as well as mapping the password into a stored value with a much higher entropy.

“The hash combination of a challenge and secret key can be kept on the device and XOR’d with the contents of a slot to implement an encrypted Read command, or it can be XOR’d with encrypted input data to implement an encrypted Write command,” the engineering rep added.

“All hashing functions are implemented using the industry-standard SHA-256 secure hash algorithm, which is part of the latest set of high-security cryptographic algorithms recommended by various governments and cryptographic experts. And yes, the SHA-256 algorithm can also be included in a HMAC sequence, with the ATECC108 employing full-sized 256 bit secret keys to prevent any kind of exhaustive attack.”

Want to learn more about Atmel’s ATECC108? Check out our official product page here.