AT88SA10HS ATMEL | Alldatasheet

Document overview

  • Manufacturer or author: Provided By ALLDATASHEET.COM(FREE DATASHEET DOWNLOAD SITE)
  • PDF pages: 23

Technical content

Features

  • Secure key storage to complement AT88SA100S and AT88SA102S Devices
  • Superior SHA-256 Hash Algorithm
  • Guaranteed Unique 48 bit Serial Number
  • High speed single wire interface, optionally shared with client
  • Supply Voltage: 2.5 – 5.5V
  • 1.8V – 5.5V communications voltage
  • <100nA Sleep Current
  • 4KV ESD protection
  • Multi-level hardware security
  • Secure personalization
  • Green compliant (exceeds RoHS) 3 pin SOT-23 package

Applications

  • Consumable device (battery, toner, other supplies) authentication
  • Network & Computer Access control
  • Authenticated communications for control networks
  • Anti-clone authentication for daughter cards
  • Physical access control (electronic lock & key) 1. Introduction The CryptoAuthentication family of chips are the first cost-effective authentication devices to implem ent the SHA-256 hash algorithm, which is part of the latest set of recommended algorithms by the US Government. The 256 bit key space renders any exhaustive attacks impossible. The AT88SA10HS host version of CryptoAuthentication chips is capable of validating the response coming from the SHA-256 engine within an authentic CryptoAuthentication client (SA100S or SA102S), even if that response incl udes within the computation the serial number of the client. For detailed information on the cryptographic protocols, algorithm test values and usage models, refer to “AT88SA100S” and “AT88SA102S” Datasheets, along with the application notes dedicated to this product family. The host CryptoAuthentication performs 3 separate operations (named HOST0, HOST1 & HOST2) to implement this validation. The AT88SA10HS chip takes both the challenge and response as inputs and returns a single Boolean indicating whether or not the response is valid, in order to prevent the host chip from being used to model a valid client. The host system is responsible for generating the random challenge that is sent to both the client and host CryptoAuthentication devices as the AT88SA10HS does not include a random number generator. CryptoAuthentication™ Host Security Chip AT88SA10HS Preliminary 8595B–SMEM–09/09

2 AT88SA10HS Host Authentication Chip [Preliminary]

be unique. See Section 1.3 for more details on the Manufacturing ID and Serial Number. ROM Metal mask programmed memory. Unrestricted reads ar e permitted on the first 64 bits of this array. value is 0xFF FF. ROM MfrID can be read by accessing ROM bytes 0 & 1 of Address 0. personalization and cannot be changed after that time. Table 1. Fuse Map: 87 Fuse Enable The HOST commands ignore the valu es of Fuse[0-63] until this bit is burned. Once this bit is burned, the BurnSecure command is disabled.

AT88SA10HS Host Authentication Chip [Preliminary] 8595B–SMEM–09/09 BurnSecure Enable This fuse is used to prevent repetitive op eration of the two personalization commands: GenPersonalizationKey and BurnSecure. This fuse is always burned by the BurnSecure command. Secret Fuses These 64 fuses are used to augment the mask programmed keys stored in the chip by Atmel. Knowledge of both the mask keys and the va lues of the Secret Fuses is required to calculate the response value expected by HOST2. The BurnSecure command can be used to burn an arbitrary selection of these 64 bits. Status Fuses These 23 fuses should be used to store information which is not secret, as their value can always be determined using the Read command. Typical usage would be model or configuration information. They cannot be automatically included in the messages to be hashed by the HOST commands, but the syst em may read them and pass them back to HOST1 in the input stream if desired. Fuse Enable This fuse is used to prevent access to fuse s on chips in which a partial set of fuses has been burned. This fuse must be burned using the BurnSecure command. 1.3. Chip Identification The chip includes a total of 72 bits of information that can be used to distinguish between individual chips in a reliable manner. The information is distributed between the ROM and fuse blocks in the following manner. Serial Number This 48 bit value is composed of ROM SN (16 bi ts) and Fuse SN (32 bits). Together they form a serial number that is guaranteed to be uniq ue for all devices ever manufactured within the CryptoAuthentication family. This value is optionally included in the MAC calculation. Manufacturing ID This 24 bit value is composed of ROM MfrID (16 bits ) and Fuse MfrID (8 bits). Typically this value is the same for all chips of a given type. It is always included in the cryptographic computations. 1.4. Key Values The values stored in the AT88SA10HS internal key array are hardwired into the masking layers of the chip during wafer manufacture. All chips have the same keys stored internally, though the value of a particular key cannot be determined externally from the chip. For this reason, customers should ensure that they program a unique (and secret) number into the 64 secret fuses and they should store the Atmel provided key values securely. Individual key values are made available to qualified custom ers upon request to Atmel and are always transmitted in a secure manner. When the serial number is included in t he MAC calculation, the response is cons idered to be diversified and the host needs to know the base secret in order to be able to verify t he authenticity of the client. A diversified response can also be obtained by including the serial number in the computati on of the value written to t he secret fuses. The Atmel AT88SA10HS provides a secure hardware mechanism to validate responses to determine if they are authentic. 1.5. SHA-256 Computation The AT88SA10HS performs only one cryptographic calculation – a keyed digest of an input challenge. It optionally includes various other information stored on the chip within the digested message. The AT88SA10HS computes the SHA-256 digest based on the algorithm documented here: http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf As a security measure, the 24 bit MfrI D code (both ROM and Fuse bits) is automatically included in every message digested by the AT88SA10HS. The secret fuses are cond itionally appended, depending on the parameters to the HOST command. For complete sample calculations, refer to”AT88SA100S” and/or “AT88SA102S” Datasheets.

4 AT88SA10HS Host Authentication Chip [Preliminary]

The AT88SA10HS incorporates a number of physical security features designed to protect the keys from release. glitch protection, voltage tamper detection and other physical design features. outside analysis very difficult. Table 2. IO Hierarchy Tokens Implement a single data bit transmitted on the bus, or the wake-up event. ensure proper data transmission. parameters of the AT88SA10HS command or status information from the AT88SA10HS. the signaling necessary to send these values to the chip. its internal clock generator due to normal manufacturing and environmental fluctuations. AT88SA10HS. Refer to Applications Notes on Atmel’s website for more details.

AT88SA10HS Host Authentication Chip [Preliminary] 8595B–SMEM–09/09 2.2. AC Parameters tSTART tZHI tZLO data commWAKE LOGIC Ø tSTART tBIT LOGIC 1 tLIGNORE tHIGNORE NOISE SUPPRESION tWLO tWHI

6 AT88SA10HS Host Authentication Chip [Preliminary]

Table 3. AC Parameters levels during extended sleep intervals. on the bus. See PauseShort command.

Table 4. DC Parameters ESD V ESD 4 KV Human Body Model, Sig & Vcc pins.

8 AT88SA10HS Host Authentication Chip [Preliminary]

block can follow immediately after the last bit of the flag. AT88SA10HS will wake up when communications are sent to the client, it will ignore all such transactions. be used to prevent the AT88SA10HS host chip from looking at the signal wire during any IO transaction to the client. Table 5. Command Timing SecureDelay t EXEC_SECURE 13 26 ms Max delay to execute BurnSecure command at Vcc > 4.5V. See Section 4.6 for more details.

Table 6. Return Codes AT88SA10HS repeatedly if a re-read of the output is necessary. command bits must happen before it is re-attempted. in 4 bytes going to the system – count, error, CRC x 2. automatically from t PARSE to t EXEC and will not respond to any transmit tokens until both delays are complete. the AT88SA10HS will accept a flag. SLEEP, Atmel recommends that the input signal be brought below V IL when the chip is asleep. to avoid additional leakage on the input circuit of the chip.

10 AT88SA10HS Host Authentication Chip [Preliminary]

8595B–SMEM–09/09 3.2. IO Blocks Commands are sent to the chip, and responses received from the chip, within a block that is constructed in the following way: Byte Number Name Meaning

0 Count Number of bytes to be transferred to the chip in the block, including count, packet and

checksum, so this byte should always have a value of (N+1). The maximum size block is 39 and the minimum size block is 4. Values outside this range will cause unpredictable operation. 1 to (N-2) Packet Command, parameters and data, or response. Refer to Section 3.1.2 & Section 4 for more details. N-1, N Checksum CRC-16 verification of the count and packet bytes. The CRC polynomial is 0x8005, the initial register value should be 0 and after the last bit of the count and packet have been transmitted the internal CRC register should have a value that matches that in the block. The first byte transmitted (N-1) is the least significant byte of the CRC value so the last byte of the block is the most significant byte of the CRC. 3.3. IO Flow The general IO flow for the commands is as follows: 1. System sends Wake token. 2. System sends Transmit flag. 3. Receive 0x11 value from the AT88SA10HS to verify proper wakeup synchronization. 4. System sends Command flag. 5. System sends complete command block. 6. System waits t PARSE for the AT88SA10HS to check for command formation errors. 7. System sends Transmit flag. If command format is OK, the AT88SA10HS ignores this flag because the computation engine is busy. If there was an error, the AT88SA10HS responds with an error code. 8. System waits t EXEC, Refer to Section 3.1.1. 9. System sends Transmit flag. 10. Receive output block from the AT88SA10HS, system checks CRC. 11. If CRC from the AT88SA10HS is incorrect, indication transmission error, system resends Transmit flag. 12. System sends sleep flag to the AT88SA10HS. Where the command in question has a short execution delay the system should omit steps 6, 7 & 8 and replace this with a wait of duration t PARSE + t EXEC. 3.4. Synchronization Because the communications protocol is half duplex, there is the possibility that the system and the AT88SA10HS will fall out of synchronization with each other. In order to speed recovery, the AT88SA10HS implements a timeout that forces the AT88SA10HS to sleep.

AT88SA10HS Host Authentication Chip [Preliminary] 8595B–SMEM–09/09 3.4.1. IO Timeout After a leading transition for any data token has been received, the AT88SA10HS will expect another token to be transmitted within a tTIMEOUT interval. If the leading edge of the next token is not received within this period of time, the AT88SA10HS assumes that the synchronization with the host is lost and transitions to a sleep state. After the AT88SA10HS receives the last bit of a command blo ck, this timeout circuitry is disabled. If the command is properly formatted, then it is re-enabled with the first transmit token that occurs after t PARSE + tEXEC. If there is an error in the command, then it is re-enabled with the first transmit token that occurs after tPARSE. In order to limit the active current if the AT88SA10HS is inadvertently awakened, the IO timeout is also enabled when the AT88SA10HS wakes up. If the first token does not come within the t TIMEOUT interval, then the AT88SA10HS will go back to sleep without performing any operations. 3.4.2. Synchronization Procedures When the system and the AT88SA10HS fall out of synchronization, the system will ultimately end up sending a transmit flag which will not generate a response from the AT88SA10H S. The system should implement its own timeout which waits for tTIMEOUT during which time the AT88SA10HS should go to sleep automatically. At this point, the system should send a Wake token and after t WLO + tWHI, a Transmit token. The 0x11 status indicates that the resynchronization was successful. It may be possible that the system does not get the 0x11 code from the AT88SA10HS for one of the following reasons: 1. The system did not wait a full t TIMEOUT delay with the IO signal idle in which case the AT88SA10HS may have interpreted the Wake token and Transmit flag as data bi ts. Recommended resolution is to wait twice the t TIMEOUT delay and re-issue the Wake token. 2. The AT88SA10HS went into the sleep mode for some reas on while the system was transmitting data. In this case, the AT88SA10HS will interpret the next data bit as a wake token, but ignore some of the subsequently transmitted bits during its wake-up delay. If any bytes are transmitted after the wake-up delay, they may be interpreted as a legal flag, though the following bytes would not be interpreted as a legal command due to an incorrect count or the lack of a correct CRC. Recommended resolution is to wait the tTIMEOUT delay and re-issue the Wake token. 3. There are some internal error conditions within the AT88SA10HS which will be automatically reset after a t WATCHDOG interval, see below. There is no way to externally reset the AT88SA10HS – the system should leave the IO pin idle for this interval and issue the Wake token. 3.5. Watchdog Failsafe After the Wake token has been received by the AT88SA10HS, a wa tchdog counter is started within the chip. After t WATCHDOG, the chip will enter sleep mode, regardless of whether it is in the middle of execution of a command and/or whether some IO transmission is in progress. There is no way to reset the counter other than to put the chip to sleep and wake it up again. This is implemented as a fail-safe so that no matter what happens on either the system si de or inside the various state machines of the AT88SA10HS including any IO synchronization issue, power consumption will fall to the low sleep level automatically. 3.6. Byte & Bit Ordering The AT88SA10HS is a little-endian chip:

  • All multi-byte aggregate elements within this spec are tr eated as arrays of bytes and are processed in the order received.
  • Data is transferred to/from the AT88SA10HS least significant bit first on the bus.
  • In this document, the most significant bit and/or byte appears towards the left hand side of the page.

12 AT88SA10HS Host Authentication Chip [Preliminary]

8595B–SMEM–09/09 4. Commands The command packet is broken down in the following way: Byte Name Meaning

0 Opcode The Command code

1 Param1 The first parameter – always present

2-3 Param2 The second parameter – always present 4 + Data Optional remaining input data If a command fails because the CRC within the block is incorrect or there is some other communications error, then immediately after t PARSE the system will be able to retrieve an error response block containing a single byte packet. The value of that byte will be all 1’s. In this situation, the system should re-transmit the command block including the proceeding Transmit flag – providing there is sufficient time before the expiration of the watchdog timeout. If the opcode is invalid, one of the parameters is illegal, or the AT88SA10HS is in an illegal state for the execution of this command, then immediately after t PARSE the system will be able to retrieve an error response block containing a single byte packet. The value of that byte will be 0x0F. In this situation, the condition must be corrected before the (modified) command is sent back to the AT88SA10HS. If a command is received successfully, the system will be able to retrieve the output block as described in the individual command descriptions below after the appropriate execution delay. In the individual command description tables following, the “Size” column describes the number of bytes in the parameter documented in each particular row. The total size of the block for each of t he commands is fixed, though that value is different for each command. If the block size for a particular command is incorrect, the chip will not attempt the command execution and returns an error.

Table 7. Input Parameters Param2 KeyID 2 The internal key to be used to generate the digest. Table 8. Output Parameters All other values of the overwrite parameter are not recommended for use.

14 AT88SA10HS Host Authentication Chip [Preliminary]

response generated by the client with the one generated by the host. Table 9. Input Parameters Param1 Mode 1 Controls composition of message, see below for details. Data OtherInfo 13 Input portion of message to be digested. Table 10. Output Parameters addresses for OtherInfo are listed in the table below. 16 bits ROM MfrID Should match between AT88SA10HS and AT88SA100S/AT88SA102S. These bits are followed by the necessary ‘1’ bit, ‘0’ padding and 64 bit length as specified in the SHA-256 specification.

remaining bits of the mode field are ignored by the AT88SA10HS and should be 0. Table 11. Mode Encoding 1 Insert the values of Fuse[0-63] in the message. generation step as a security measure.

16 AT88SA10HS Host Authentication Chip [Preliminary]

HOST1 has not been previously successfully run within this wake cycle. & HOST2 commands must be re-executed – HOST2 cannot be repeatedly executed. Table 12. Input Parameters Data ClientResponse 32 Response from the client. Table 13. Output Parameters value of 0x0F will be returned after a THOST delay.

Table 14. Input Parameters Table 15. Output Parameters Contents 4 The contents of t he specified memory location. Table 16. Mode Encoding ROM 0x00 Reads four bytes from the ROM. Bi t 1 of the address parameter must be 0. Fuse 0x01 Reads the value of 32 fuses. Bit 1 of the address parameter must be 1.

18 AT88SA10HS Host Authentication Chip [Preliminary]

This command will fail if Fuse[87] has been burned. Table 17. Input Parameters Param2 KeyID 2 Identification num ber of the personalization key to be loaded. Table 18. Output Parameters Success 1 Upon successful execution, a value of 0 will be returned by the AT88SA10HS.

status fuses can be verified with the Read command. corresponding fuse is burned. If a bit in the map parameter is 0, then the corresponding fuse is left in its current state. of the desired secret or status value. See Section 1.2 for more details. must be run within a single wake cycle prior to the expiration of the watchdog timer. the internal burn time will be 190ms per fuse bit burned. The chip does NOT internally check the supply voltage level. than Fuse[87] (see below), the fuses may be burned in any order. in combination with other fuses. this interval, or the fuse may end up in a state where it reads as un-burned but cannot be burned. Table 19. Input Parameters Param1 Decrypt 1 If 1, decrypt Map dat a before usage. If 0, the map is transmitted in plain text. Param2 BurnTime 2 Must be 0x00 00 if Vcc > 4.5V, must be 0x80 00 otherwise. Data Map 11 Which fuses to burn, may be encrypted. Table 20. Output Parameters Success 1 Upon successful execution, a value of 0 will be returned by the AT88SA10HS. This command takes a constant time to execute regardless of the number of fuses being burned.

20 AT88SA10HS Host Authentication Chip [Preliminary]

AT88SA100S or AT88SA102S client chips sharing the same signal wire. Table 21. Input Parameters Table 22. Output Parameters There are three pins on the chip. Table 23. Chip Pins in use this pin can be pulled to either VCC or VSS. 3 VSS Connect to system ground.

AT88SA10HS Host Authentication Chip [Preliminary] 8595B–SMEM–09/09 6. Package Drawing 3TS1 - Shrink SOT

22 AT88SA10HS Host Authentication Chip [Preliminary]

Table 24. Revision History 8595A 04/2009 Initial document release.

8595A–SMEM–04/09 Headquarters International Atmel Corporation

2325 Orchard Parkway

San Jose, CA 95131 USA Tel: 1(408) 441-0311 Fax: 1(408) 487-2600 Atmel Asia Unit 1-5 & 16, 19/F BEA Tower, Millennium City 5

418 Kwun Tong Road

Kwun Tong, Kowloon Hong Kong Tel: (852) 2245-6100 Fax: (852) 2722-1369 Atmel Europe Le Krebs 8, Rue Jean-Pierre Timbaud BP 309

78054 Saint-Quentin-en-

9F, Tonetsu Shinkawa Bldg. 1-24-8 Shinkawa Chuo-ku, Tokyo 104-0033 Japan Tel: (81) 3-3523-3551 Fax: (81) 3-3523-7581 Product Contact Web Site www.atmel.com Technical Support securemem@atmel.com Sales Contact www.atmel.com/contacts Literature Requests www.atmel.com/literature Disclaimer: The information in this document is provided in connection with Atmel products. No lice nse, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of Atmel products. EXCEPT AS SET FORTH IN ATMEL’S TERMS AND CONDITIONS OF SALE LOCATED ON ATMEL’S WEB SITE, ATMEL ASSUMES NO LIABILITY WH ATSOEVER AND DISCLAIM S ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPO SE, OR NON-INFRINGEMENT . IN NO EVENT SHALL ATMEL BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDEN-TAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION, OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF ATMEL HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Atmel makes no representations or warranties with respect to the accuracy or completene ss of the contents of this document and reserves the right to make c hanges to specifications and product description s at any time without notice. Atmel do es not make any commitment to update the information contained herein. Unless specifically provided otherwise, Atmel pr oducts are not suitable for, and shall not be used in, automotive applications. Atmel’s products are not intended, authorized, or warranted for use as components in applications intended to support or sustain life. © 2009 Atmel Corporation. All rights reserved. Atmel®, Atmel l ogo and combinations thereof, and others are registered trademark s, CryptoAuthentication™, and others, are trademarks of Atmel Corporation or its subsidiaries. Other terms and product names may be trademarks of others.