AT88SA102S

Features • Secure authentication & key exchange • Superior SHA-256 Hash Algorithm • Best in class 256 bit key length • Guaranteed Unique 48 bit Serial Number • High speed single wire interface • Supply Voltage: 2.5 – 5.5V • 1.8 – 5.5 V Communications • 4.5V. See Section 4.3 for more details. Max delay to execute BurnSecure command at Vcc > 4.5V. See Section 4.5 for more details. Delay to execute GenPersonalizationKey is used as shorthand for the delay corresponding to whatever command has been sent to the 10 AT88SA102S [Preliminary] 8584B–SMEM–09/09 AT88SA102S [Preliminary] 3.1.2. Transmit Flag The transmit flag is used to turn around the signal so that CryptoAuthentication can send data back to the system, depending on its current state. The bytes that CryptoAuthentication returns to the system depend on its current state as follows: Table 6. Return Codes Error/Status 0x11 – Description Indication that a proper wake token has been received by CryptoAuthentication. Return bytes per “Output Parameters” in Command section of this document. In some cases this is a single byte with a value of 0x00 indicating success. The transmit flag can be resent to CryptoAuthentication repeatedly if a re-read of the output is necessary. Command was properly received but could not be executed by CryptoAuthentication. Changes in CryptoAuthentication state or the value of the command bits must happen before it is re-attempted. Command was NOT properly received by CryptoAuthentication and should be re-issued by the system. No attempt was made to execute the command. State Description After wake, but prior to first command After successful command execution Execution error 0x0F After CRC or other communications error 0xFF CryptoAuthentication always transmits complete blocks to the system, so in the above table the status/error bytes result in 4 bytes going to the system – count, status/error, CRC x 2. After receipt of a command block, CryptoAuthentication will parse the command for errors, a process which takes tPARSE (Refer to Section 3.1.1). After this interval the system can send a transmit token to CryptoAuthentication – if there was an error then CryptoAuthentication will respond with an error code. If there is no error then CryptoAuthentication internally transitions automatically from t PARSE to t EXEC and will not respond to any transmit tokens until both delays are complete. 3.1.3. Sleep Flag The sleep flag is used to transition CryptoAuthentication to the low power state, which causes a complete reset of CryptoAuthentication’s internal command engine and input/output buffer. It can be sent to CryptoAuthentication at any time when CryptoAuthentication will accept a flag. To achieve the specified ISLEEP, Atmel recommends that the input signal be brought below VIL when the chip is asleep. To achieve ISLEEP if the sleep state of the input pin is high, the voltage on the input signal should be within 0.5V of VCC to avoid additional leakage on the input circuit of the chip. The system must calculate the total time required for all commands to be sent to CryptoAuthentication during a single session, including any inter-bit/byte delays. If this total time exceeds tWATCHDOG then the system must issue a partial set of commands, then a Sleep flag, then a Wake token, and finally after the wake delay the remaining commands. 3.1.4. Pause State The pause state is entered via the PauseLong command and can be exited only when the watchdog timer has expired and the chip transitions to a sleep state. When in the pause state, the chip ignores all transitions on the signal pin but does not enter a low power consumption mode. 11 8584B–SMEM–09/09 The pause state provides a mechanism for multiple AT88SA102S chips on the same wire to be selected and to exchange data with the host microprocessor. The PauseLong command includes an optional address field which is compared to the values in Fuses 84-87. If the two match, then the chip enters the pause state, otherwise it continues to monitor the bus for subsequent commands. The host would selectively put all but one AT88SA102S’s in the pause state before executing the MAC command on the active chip. After the end of the watchdog interval all the chips will have entered the sleep state and the selection process can be started with a wake token (which will then be honored by all chips) and selection of a subsequent chip. 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 0 Name Count Meaning 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. Command, parameters and data, or response. Refer to Section 3.1.2 & Section 4 for more details. 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. 1 to (N-2) Packet N-1, N Checksum 3.3. IO Flow The general IO flow for the MAC command is as follows: 1. 2. 3. 4. 5. 6. 7. System sends Wake token. System sends Transmit flag. Receive 0x11 value from the AT88SA102S to verify proper wakeup synchronization. System sends Command flag. System sends complete command block. System waits t PARSE for the AT88SA102S to check for command formation errors. System sends Transmit flag. If command format is OK, the AT88SA102S ignores this flag because the computation engine is busy. If there was an error, the AT88SA102S 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 AT88SA102S, system checks CRC. 11. If CRC from the AT88SA102S is incorrect, indication transmission error, system resends Transmit flag. 12. System sends sleep flag to the AT88SA102S. All commands other than MAC have a short execution delay. In these cases, 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 CryptoAuthentication will fall out of synchronization with each other. In order to speed recovery, CryptoAuthentication implements a timeout that forces the chip to sleep. 12 AT88SA102S [Preliminary] 8584B–SMEM–09/09 AT88SA102S [Preliminary] 3.4.1. IO Timeout After a leading transition for any data token has been received, CryptoAuthentication 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, CryptoAuthentication assumes that the synchronization with the host is lost and transitions to a sleep state. After CryptoAuthentication receives the last bit of a command block, 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 + t EXEC. If there is an error in the command, then it is re-enabled with the first transmit token that occurs after t PARSE. In order to limit the active current if CryptoAuthentication is inadvertently awakened, the IO timeout is also enabled when CryptoAuthentication wakes up. If the first token does not come within the tTIMEOUT interval, then CryptoAuthentication will go back to sleep without performing any operations. 3.4.2. Synchronization Procedures When the system and CryptoAuthentication fall out of synchronization, the system will ultimately end up sending a transmit flag which will not generate a response from CryptoAuthentication. The system should implement its own timeout which waits for tTIMEOUT during which time CryptoAuthentication should go to sleep automatically. At this point, the system should send a Wake token and after tWLO + 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 CryptoAuthentication for one of the following reasons: 1. 2. The system did not wait a full tTIMEOUT delay with the IO signal idle in which case CryptoAuthentication may have interpreted the Wake token and Transmit flag as data bits. Recommended resolution is to wait twice the tTIMEOUT delay and re-issue the Wake token. CryptoAuthentication went into the sleep mode for some reason while the system was transmitting data. In this case, CryptoAuthentication 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. There is some internal error condition within CryptoAuthentication which will be automatically reset after a tWATCHDOG interval, see below. There is no way to externally reset CryptoAuthentication – the system should leave the IO pin idle for this interval and issue the Wake token. 3. 3.5. Watchdog Failsafe After the Wake token has been received by CryptoAuthentication, a watchdog counter is started within the chip. After tWATCHDOG, 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 side or inside the various state machines of CryptoAuthentication including any IO synchronization issue, power consumption will fall to the low sleep level automatically. 3.6. Byte & Bit Ordering CryptoAuthentication is a little-endian chip: • All multi-byte aggregate elements within this spec are treated as arrays of bytes and are processed in the order received. • Data is transferred to/from CryptoAuthentication 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. 13 8584B–SMEM–09/09 4. Commands The command packet is broken down in the following way: Byte 0 1 2-3 4+ Name Opcode Param1 Param2 Data Meaning The Command code The first parameter – always present The second parameter – always present 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 CryptoAuthentication 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 CryptoAuthentication. If a command is received successfully then after the appropriate execution delay the system will be able to retrieve the output block as described in the individual command descriptions below. In the individual command description tables below, 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 the 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 return an error. 14 AT88SA102S [Preliminary] 8584B–SMEM–09/09 AT88SA102S [Preliminary] 4.1. MAC Computes a SHA-256 digest of a key stored inside the chip, an input challenge and other information on the chip. The output of this command is the digest of this message. If the message includes the serial number of the chip, then the response is said to be diversified. Protocols that utilize diversified responses may be more secure because two CryptoAuthentication chips with same key will return different responses to an identical challenge based on their unique serial number. Table 7. Input Parameters Name Opcode Param1 Param2 Data Table 8. Name Response MAC Mode KeyID Challenge Output Parameters Size 32 SHA-256 digest. Notes Size 1 1 2 32 0x08 Controls which fields within the chip are used in the message. Which internal key is to be used in the message. Input portion of message to be digested. Notes Regardless of the value of the first 512 bit block of the message that will be hashed with the SHA-256 algorithm will consist of: 256 bits 256 bits key[KeyID] challenge The second block consists of the following information: 8 bits 8 bits 16 bits 64 bits 24 bits 8 bits 32 bits 16 bits 16 bits 1 bit 255 bit 64 bit Opcode (always 0x08) Mode KeyID Secret Fuses including BurnFuse and BurnSecure enable (or 0’s, see below) Status Fuses including FuseDisable (or 0’s, see below) Fuse MfrID fuses, (Fuse[88:95]) (never zero’d out) Fuse SN, (Fuse[96:127]) (or 0’s, see below) ROM MfrID (never zero’d out) ROM SN (or 0’s, see below) ‘1’ pad ‘0’ pad total length of message in bits (512+192=704), excluding pad and length Mode is encoded as follows: 15 8584B–SMEM–09/09 Table 9. Bits 7 6 5 Mode Encoding Meaning Should be 0 If set and Fuse[87] is burned, include the 48 bit serial number (combination of fuses and ROM values) in the message. Otherwise, the corresponding message bits are set to 0. If set and Fuse[87] is burned, include the 64 secret fuses (Fuse[0] through Fuse[63]) in the message. Otherwise, the corresponding message bits are set to 0. If Mode[4] is set, then the value of this mode bit is ignored. If set and Fuse[87] is burned, include the 64 secret fuses and 24 status fuses (Fuse[0] through Fuse[87]) in the message. Otherwise, the corresponding message bits are set to 0. Should be 0 4 3-0 If Fuse[87] is unburned, then the secret and status fuses are NOT included in the message and they are replaced with 0’s. 16 AT88SA102S [Preliminary] 8584B–SMEM–09/09 AT88SA102S [Preliminary] 4.2. Read Reads 4 bytes from Fuse or ROM. Returns an error if an attempt is made to read any fuse address that is illegal. Table 10. Input Parameters Name Opcode Param1 Param2 Data Table 11. Name Contents Table 12. Name ROM Fuse READ Mode Address Ignored Output Parameters Size 4 Notes The contents of the specified memory location. Size 1 1 2 0 0x02 Fuse or ROM Which 4 bytes within array. Bits 2-15 should be 0. Notes Mode Encoding Value 0x00 0x01 Notes Reads four bytes from the ROM. Bit 1 of the address parameter must be 0. Reads the value of 32 fuses. Bit 1 of the address parameter must be 1. The input address parameter 4.5V, must be 0x80 00 otherwise. Notes 18 AT88SA102S [Preliminary] 8584B–SMEM–09/09 AT88SA102S [Preliminary] 4.4. GenPersonalizationKey Loads a personalization key into internal memory and then uses that key along with an input seed to generate a decryption digest using SHA-256. Neither the key nor the decryption digest can be read from the chip. Upon completion, an internal bit is set indicating that a secure personalization digest has been loaded and is ready for use by BurnSecure. This bit is cleared (and the digest lost) when the watchdog timer expires or the power is cycled. This command will fail if Fuse[87] has been burned. Table 15. Input Parameters Name Opcode Param1 Param2 Data GenPers Zero KeyID Seed Size 1 1 2 16 0x20 Must be 0x00 Identification number of the personalization key to be loaded. Seed for digest generation. The least significant bit of the last byte is ignored by the AT88SA102S. Notes Table 16. Name Success Output Parameters Size 1 Notes Upon successful execution of HOST0, a value of 0 will be returned by the AT88SA102S. The SHA-256 message body used to create the resulting digest internally stored in the chip consists of the following 512 bits: 256 bits 64 bits 127 bits 1 bits 64 bits PersonalizeKey[KeyID] Fixed value of all 1’s Seed from input stream ‘1’ pad Length of message in bits, fixed at 512 19 8584B–SMEM–09/09 4.5. BurnSecure Burns any combination of the first 88 fuse bits. Verification that the proper secret fuse bits have been burned must occur using the MAC command – there is no way to read the values in the first 64 fuses to verify their state. The 24 status fuses can be verified with the Read command. The fuses to be burned are specified by the 88 bit input map parameter. If a bit in the map is set to a ‘1’, then the corresponding fuse is burned. If a bit in the map parameter is 0, then the corresponding fuse is left in its current state. The first bit sent to the AT88SA102S corresponds to Fuse[0] and so on up to Fuse[87]. Note that since a ‘1’ bit in the Map parameter results in a ‘0’ data value in the actual fuse array, the value in the Map parameter should generally be the inverse of the desired secret or status value. See Section 1.3 for more details. To facilitate secure personalization of the AT88SA102S, this map may be encrypted before being sent to the chip. If this mode is desired, then the Decrypt parameter should be set to 1 in the input parameter list. The decryption (transport) key is computed by the GenPersonalizationKey command, which must have been run immediately prior to the execution of BurnSecure. In this case, prior to burning any fuses, the input Map parameter is XOR’d with the first 88 bits of that digest from the GenPersonalizationKey command. The GenPersonalizationKey and BurnSecure commands must be run within a single wake cycle prior to the expiration of the watchdog timer. The power supply pin must meet the VBURN specification during the entire BurnSecure command in order to burn fuses reliably. If Vcc is greater than 4.5V, then the BurnTime parameter should be set to 0x00 and the internal burn time will be 250μs. If Vcc is less than 4.5V but greater than VBURN then the BurnTime parameter should be set to 0x8000 and the internal burn time will be 190ms per fuse bit burned. The chip does NOT internally check the supply voltage level. The total BurnSecure execution delay is directly proportional to the total number of fuses being burned. If Vcc is less than 4.5V, then the total BurnSecure execution time may exceed the interval remaining before the expiration of the watchdog timer. In this case, the BurnSecure command should be run repeatedly, with each repetition burning only as many fuses as there is time available. The system software is responsible for counting the number of ‘1’ bits in the clear-text version of the map parameter sent to the chip – no error is returned if the fuse burn count is too high. Other than Fuse[87] (see below), the fuses may be burned in any order. Prior to execution of BurnSecure, the AT88SA102S verifies that Fuse[87] is un-burned. If it has been burned, then the BurnSecure command will return an error. Fuse[87] can either be burned during the last repetition of BurnSecure or it can be individually burned with BurnFuse. There are a series of very small intervals during tEXEC_SECURE when the fuse element is actually being burned. The power supply must not be removed during this interval and the watchdog timer must not be allowed to expire during this interval, or the fuse may end up in a state where it reads as un-burned but cannot be burned. Table 17. Input Parameters Name Size 1 1 2 11 0x10 If 1, decrypt Map data before usage. If 0, the map is transmitted in plain text. Must be 0x00 00 if Vcc > 4.5V, must be 0x80 00 otherwise. Which fuses to burn, may be encrypted. Notes Opcode Param1 Param2 Data Table 18. Name Success BURNSECURE Decrypt BurnTime Map Output Parameters Size 1 Notes Upon successful execution, a value of 0 will be returned by the AT88SA102S. 20 AT88SA102S [Preliminary] 8584B–SMEM–09/09 AT88SA102S [Preliminary] 4.6. PauseLong Forces the chip into a busy mode until the watchdog timer expires, after which it will automatically enter into the pause state. During execution of this command and while in the pause state the chip will ignore all activity on the IO signal. This command is used to prevent bus conflicts in a system that also includes other AT88SA102S chips or a CryptoAuthentication host chip sharing the same signal wire. Table 19. Input Parameters Name Opcode Param1 Param2 Data Table 20. Name Success PAUSELONG Selector Zero Ignored Output Parameters Size 1 Notes If the command indicates that some other chip should go into the pause state, a value of 0x0F will be returned by the AT88SA102S. If this chip goes into the pause state no value will be returned. Size 1 1 2 0 0x01 Which chip to put into the pause state, 0x00 for all AT88SA102S chips Must be 0x00 00 Notes The Selector parameter provides a mechanism to select which device will pause if there are multiple devices on the bus: If the Selector parameter is 0x00, then every AT88SA102S chip receiving this command will go into the pause state and no chip will return a success code. If any of the bits of the Selector parameter are set, then the chip will read the values of Fuse[84-87] and go into the pause state only if those fuse values match the least significant 4 bits of the Selector parameter. If the chip does NOT go into the pause state, it returns an error code of 0x0F. Otherwise it goes into the pause state and never returns any code. 5. Pinout There are three pins on the chip. Table 21. Pin # 1 Chip Pins Name Signal Description IO channel to the system, open drain output. It is expected that an external pull-up resistor will be provided to pull this signal up to VCC for proper communications. When the chip is not in use this pin can be pulled to either VCC or VSS. Power supply, 2.5 – 5.5V. This pin should be bypassed with a high quality 0.1μF capacitor close to this pin with a short trace to VSS. Additional applications information at www.atmel.com. Connect to system ground. 2 VCC 3 VSS 21 8584B–SMEM–09/09 6. Package Drawing 3TS1 - Shrink SOT 3 E1 E C L 1 e1 2 Top View End View b A2 SEATING PLANE A e D A1 Side View L1 Notes: 1. Dimension D does not include mold flash, protrusions or gate burrs. Mold flash, protrusions or gate burrs shall not exceed 0.25 mm per end. Dimension E1 does not include interlead flash or protrusion. Interlead flash or protrusion shall not exceed 0.25 mm per side. 2. The package top may be smaller than the package bottom. Dimensions D and E1 are determined at the outermost extremes of the plastic body exclusive of mold flash, tie bar burrs, gate burrs and interlead flash, but including any mismatch between the top and bottom of the plastic body. 3. These dimensions apply to the flat section of the lead bet een 0.08 w mm and 0.15 mm from the lead tip. COMMON DIMENSIONS (Unit of Measure = mm) SYMBOL MIN NOM MAX NOTE This drawing is for general information only. Refer to JEDEC Drawing TO-236, Variation AB for additional information. A A1 A2 D E E1 L1 e1 b 0.89 0.01 0.88 2.80 2.10 1.20 2.90 1.30 0.54 REF 1.90 BSC 0.30 - 1.12 0.10 1.02 3.04 2.64 1.40 1,2 1,2 0.50 3 11/5/08 TITLE R Package Drawing Contact: packagedrawings@atmel.com GPC DRAWING NO. REV. 3TS1, 3-lead, 1.30 mm Bo PlasticThin dy, Shrink Small OutlinePackage (Sh rink SOT) TBG 3TS1 A 22 AT88SA102S [Preliminary] 8584B–SMEM–09/09 AT88SA102S [Preliminary] 7. Revision History Table 22. 8584A Revision History Date 03/2009 Initial document release. Comments Doc. Rev. 23 8584B–SMEM–09/09 Headquarters Atmel Corporation 2325 Orchard Parkway San Jose, CA 95131 USA Tel: 1(408) 441-0311 Fax: 1(408) 487-2600 International 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-enYvelines Cedex France Tel: (33) 1-30-60-70-00 Fax: (33) 1-30-60-71-11 Atmel Japan 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 license, 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 WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, 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 completeness of the contents of this document and reserves the right to make changes to specifications and product descriptions at any time without notice. Atmel does not make any commitment to update the information contained herein. Unless specifically provided otherwise, Atmel products 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 logo and combinations thereof, and others are registered trademarks, CryptoAuthentication™, and others, are trademarks of Atmel Corporation or its subsidiaries. Other terms and product names may be trademarks of others. 8584B–SMEM–09/09