ATSHA204A データシートの表示（PDF） - Atmel Corporation
部品番号
コンポーネント説明
メーカー
ATSHA204A Datasheet PDF : 82 Pages
| |||
Each ATSHA204A ships with a guaranteed unique 9-byte (72-bit) serial number. Using the cryptographic
protocols supported by the device, a Host system or remote server can prove that the serial number is authentic
and is not a copy. Serial numbers are often stored in a standard Serial EEPROM, which can be easily copied
with no way for the Host to know if the serial number is authentic or if it is a clone. The entire serial number must
be utilized to guarantee uniqueness.
The ATSHA204A can generate high-quality random numbers and employ them for any purpose, including as
part of the crypto protocols of this device. Because each 32-byte (256-bit) random number is not dependent on
past numbers generated on this or any other device, their inclusion in the protocol calculation ensures that
replay attacks (i.e. re-transmitting a previously successful transaction) always fail. See Section 3.2, “Random
Number Generator (RNG)” and Section 8.5.14, “Random Command”.
System integration is made easy by a wide supply voltage range (of 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 UDFN package with a footprint of only 2.0mm x 3.0mm.
See Section 11., “Package Drawings” for more details and ordering codes.
See Section 9., “Compatibility” for information regarding compatibility with the Atmel ATSHA204.
1.3 Cryptographic Operation
The ATSHA204A supports a standard challenge-response protocol to simplify programming. In its most basic
installation, the Host system sends a challenge (i.e. a number) to the device in the Client, which combines that
challenge with a secret key by using the Message Authentication Code (MAC) command from the system, as
described in Section 8.5.11, “MAC Command”, and sends that response back to the system. The device uses a
cryptographic hash algorithm to make that combination (which is also known as a digest). The use of a hash
algorithm prevents an observer on the bus from deriving the value of the secret key, while allowing the recipient
to verify that the response is correct by performing the same calculation combining the challenge with the secret
to create a digest using a stored copy of the secret.
This basic operation can be expanded in many ways because of the flexible command set of the ATSHA204A.
By using the GenDig command (Section 8.5.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.5.6, “DeriveKey Command”) implements a key rolling scheme.
Depending upon the command mode parameter, the resulting operation can be similar to that implemented in a
remote-controlled garage door opener, for example. Each time the key is used, the current value of the key is
cryptographically combined with a value specific to that system, and that result then forms the key for the next
cryptographic operation. Even if an attacker obtains the value of one key, that key will disappear 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 condition. 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 will 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.5.5, “CheckMac Command”) allows the Host device to securely store the
Client’s 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 required, the CheckMac command also provides a way to both verify the
password without exposing it on the communications bus and map the password to a stored value that can have
much higher entropy. See Section 13.3.6, “Password Checking” for details.
ATSHA204A [DATASHEET]
7
Atmel-8885H-CryptoAuth-ATSHA204A-Datasheet_112015
Share Link: 