ATSHA204-RBH-T Ver la hoja de datos (PDF) - Atmel Corporation
Número de pieza
componentes Descripción
Fabricante
ATSHA204-RBH-T Datasheet PDF : 81 Pages
| |||
(re-transmitting a previously successful transaction) always fail. See Section 3.2, “Random Number Generator (RNG)”
and Section 8.6.14, “Random Command”.
System integration is eased with a wide supply voltage range (2.0V through 5.5V) and an ultra-low sleep current of
<150nA. Complete DC parameters are found in Section 7., “Electrical Characteristics”, which describes multiple package
options, including a tiny SOT23 package with a footprint of only 2.5mm x 3mm. See Section 11., “Package Drawings” for
more details and for ordering codes.
See Section 9., “Compatibility” for information regarding compatibility with the Atmel AT88SA102S and the Atmel
AT88SA10HS (previous members of the Atmel CryptoAuthentication family).
1.3 Cryptographic Operation
The ATSHA204 supports a standard challenge-response protocol to simplify programming. At its most basic, the Host
system sends a challenge to the device in the Client, which combines that challenge with a secret key via the Message
Authentication Code (MAC) command from the system, described in Section 8.6.11, “MAC Command” and sends the
response back to the system. The device uses a cryptographic hash algorithm for the combination, which prevents an
observer on the bus from deriving the value of the secret key, but allows the recipient to verify that the response is correct
by performing the same calculation (combining the challenge with the secret) with a stored copy of the secret.
This basic operation can be expanded in many ways with the flexible command set of the ATSHA204. Using the GenDig
command (Section 8.6.8, “GenDig Command”), the values in other slots can be included in the response digest 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 (Section 8.6.6, “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, that key will be gone forever with the next use.
DeriveKey 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 from 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 would not work on
any other Host.
In a Host-Client configuration where the Host (e.g. a mobile phone) needs to verify a Client (e.g. 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
(Section 8.6.5, “CheckMac Command”) allows the Host device to securely store the Client secret and hide the correct
response value from the pins, returning only a yes/no answer to the system.
Where a user-entered password is a requirement, the CheckMac command also provides a way to both verify the
password without exposing it on the communications bus as well as map the password to a stored value that can have
much higher entropy. See Section 14.3.6, “Password Checking” for more details.
Finally, the hash combination of a challenge and secret key can be kept on the device and XORed with the contents of a
slot to implement an encrypted read (Section 8.6.15, “Read Command”), or it can be XORed with encrypted input data to
implement an encrypted write (Section 8.6.17, “Write Command”).
Each of these operations can be protected against replay attacks by including a random nonce (Section 8.6.12, “Nonce
Command”) in the calculation.
All security 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.
Section 14.1, “SHA-256” includes a reference to the algorithm details. If desired, the SHA-256 algorithm can also be
included in an HMAC sequence (See Section 8.6.9, “HMAC Command”). The ATSHA204 employs full-sized, 256-bit
secret keys to prevent any kind of exhaustive attack.
ATSHA204 [DATASHEET]
7
Atmel-8740H-CryptoAuth-ATSHA204-Datasheet_072014
Share Link: 