ATECC108 [SUMMARY DATASHEET]
Atmel-8873BS-CryptoAuth-ATECC108-Datasheet-Summary_102013
4
1.3 Cryptographic Operation
ATECC108 implements a complete asymmetric (public/private) key cryptographic signature solution based on
Elliptic Curve Cryptography and the ECDSA signature protocol. The device features hardware acceleration for the
NIST standard P256, B283, and K283 binary curves and supports the complete key life cycle from high quality
private key generation, ECDSA signature generation and public key signature verification. The hardware
accelerator can implement these asymmetric cryptographic operations 10 to 1,000 times faster than software
running on standard microprocessors without the usual high risk of key exposure.
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. Public keys stored within the device can be configured to require validation via a
certificate chain to speed up future device authentication.
Random private key generation is supported internally within the device to ensure that 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.
ATECC108 also supports a standard hash-based challenge response protocol to simplify programming. At its most
basic, the system sends a challenge to the device which combines that challenge with a secret key via the MAC
command from the system, and sends the response back to the system. The device uses a
SHA-256 cryptographic hash algorithm for the combination such that an observer on the bus cannot derive the
value of the secret key, but the recipient can verify that the response is correct by performing the same calculation
with a stored copy of the secret.
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. 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 come 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.
The DeriveKey command implements a key rolling scheme. Depending on the command mode parameter, the
resulting operation can be similar to that implemented in a remote-controlled garage door opener. 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. Even if an attacker gets the value of one key, with the
next use, that key will be gone forever.
The DeriveKey command can also be used to generate new random keys that might be valid only for a particular
Host ID, for a particular time period, or for some other restricted environment. 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) needs 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
CheckMac command allows the device to securely store the secret in the Host system and hides the correct
response value from the pins, 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
that can have a much higher entropy.
Finally, 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.
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. If desired, the SHA-256 algorithm can also be included in a HMAC sequence. ATECC108
employs full-sized 256 bit secret keys to prevent any kind of exhaustive attack.
