ATSHA204 ATMEL [ATMEL Corporation], ATSHA204 Datasheet - Page 3

no-image

ATSHA204

Manufacturer Part Number
ATSHA204
Description
Atmel CryptoAuthentication
Manufacturer
ATMEL [ATMEL Corporation]
Datasheet

Available stocks

Company
Part Number
Manufacturer
Quantity
Price
Part Number:
ATSHA204-MAH-DA-T
Manufacturer:
NVIDIA
Quantity:
340
Part Number:
ATSHA204-SH-DA-B
Manufacturer:
ATMEL/爱特梅尔
Quantity:
20 000
Part Number:
ATSHA204-SH-DA-T
Manufacturer:
ATMEL/爱特梅尔
Quantity:
20 000
Part Number:
ATSHA204-TSU-T
Manufacturer:
EPSON
Quantity:
418
Part Number:
ATSHA204-TSU-T
Manufacturer:
ATMEL/爱特梅尔
Quantity:
20 000
Part Number:
ATSHA204A
Manufacturer:
ATMEL/爱特梅尔
Quantity:
20 000
Part Number:
ATSHA204A-MAHDA-T
Manufacturer:
AT
Quantity:
20 000
Company:
Part Number:
ATSHA204A-MAHFD-T
Quantity:
14 270
Company:
Part Number:
ATSHA204A-MAHMF-S
Quantity:
2 973
Part Number:
ATSHA204A-SSHDA-B
Manufacturer:
ATMEL
Quantity:
3 450
Part Number:
ATSHA204A-SSHDA-B
Manufacturer:
AT
Quantity:
21 810
Company:
Part Number:
ATSHA204A-SSHDA-B
Quantity:
50 000
Part Number:
ATSHA204A-SSHDA-T
Manufacturer:
ATMEL
Quantity:
3 450
Part Number:
ATSHA204A-STUCZ-T
Manufacturer:
ATMEL
Quantity:
12 000
Company:
Part Number:
ATSHA204A-TSU-T
Quantity:
569
Company:
Part Number:
ATSHA204A-XHDA-T
Quantity:
3 360
previously successful transaction) always fail. Further information is found in Section 3.4.2, “Random Number Generator,” and
Section 8.11, “Random Command.”
System integration is eased with a wide supply voltage range (2.0V through 5.5V) and an ultra-low sleep current of <100nA.
Complete DC parameters are found in Section 7, 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 ordering codes.
See Section 9, “Compatibility,” for information regarding compatibility with the Atmel AT88SA102S and 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 MAC command from the
system, described in Section 8.8, “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.
Due to the flexible command set of the ATSHA204, however, this basic operation can be expanded in many ways. Using the
GenDig command (Section 8.5, “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.3, “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 (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 (Section 8.2, “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 3.3.6 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.12, “Read Command”) , or it can be XORed with encrypted input data to implement
an encrypted write (Section 8.14, “Write Command”).
Each of these operations can be protected against replay attacks by including a random nonce (Section 8.9, “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 3.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 3.2, “HMAC/SHA-256,” and Section 8.6, “HMAC Command”). The ATSHA204 employs full-sized,
256-bit secret keys to prevent any kind of exhaustive attack.
Atmel ATSHA204 [DATASHEET]
3
8740D−CRYPTO−3/12

Related parts for ATSHA204