ATSHA204A Chip Usage Instructions

From Waveshare Wiki
Jump to: navigation, search
ATSHA204A
CM5

I2C
{{{name2}}}

{{{name3}}}

{{{name4}}}

{{{name5}}}

{{{name6}}}

ATSHA204A Overview

Introduction

ATSHA204A is a CryptoAuthentication hardware security chip launched by Microchip, which integrates a hardware SHA-256 engine and 4.5 Kbit secure EEPROM, can store up to 16 256-bit keys inside, and provides security features such as unique serial numbers and random number generators. The chip supports the I2C interface and can be used with the Raspberry Pi to enable applications such as device and accessory authentication, secure storage of keys and sensitive data, and consumables counting. The configuration area and data area can be prevented from being tampered with in the future through a one-time lock mechanism, and are commonly used security elements in scenarios such as IoT nodes, anti-counterfeiting, and anti-cloning.

Precautions

  • After performing the lock operation, the area will be unable to be unlocked. Please do not perform batch operations before confirming the parameters
  • Currently, only some products are equipped with ATSHA204A encryption chips, please pay attention to the product parameters
  • Microchip provides official library files, if you need to operate accordingly, you can refer to the official cryptoauthlib demo to implement

Working with Raspberry Pi

Environment Setup

  • Install dependencies + compile C library (this is the official Microchip library file) (Click here to download if cloning fails, and then copy the downloaded file to the system you are using)
#sudo apt-get update
sudo apt-get install -y git build-essential cmake libssl-dev
git clone https://github.com/MicrochipTech/cryptoauthlib.git
cd cryptoauthlib
mkdir build && cd build
cmake -DATCA_HAL_I2C=ON ..    # Linux I2C HAL is enabled by default
make
sudo make install
sudo ldconfig
cd ../../


Usage Operations

  • The main functions of the product are as follows, and the related explanations are based on the following content
    • Initialize / Shut down
    • Read chip information/serial number
    • Read random number
    • Nonce (update TempKey)
    • Calculate MAC
    • Query/lock the Config/Data area
    • Read/write Config area
    • Read/write Data area slot
  • Note that the Python of the official library file is only a very thin ctypes package, and the actual work is still done by the C version of libcryptoauth.so. Moreover, the ctypes package lacks many functions, that is, many functions cannot be called. Therefore, the Python demo used in this example also has a layer of C library wrapping at the bottom.

Initialize / Shut Down

  • After installing the official library files, perform parameter initialization
ATCA_STATUS atsha204a_init(void)
{
    if (g_initialized)
        return ATCA_SUCCESS;                               // Initialized, returns directly after success

    ATCA_STATUS status = atcab_init(&g_atsha_cfg);         // Call the init of cryptoauthlib
    if (status == ATCA_SUCCESS)
        g_initialized = true;                              // Marked as initialized

    return status;
}

Read Chip Information / Serial Number

ATCA_STATUS atsha204a_get_info(uint8_t info[4])
{
    if (!info)
        return ATCA_BAD_PARAM;                             // Null pointer, parameter error

    ATCA_STATUS status = atsha204a_init();                 // Make sure it is initialized
    if (status != ATCA_SUCCESS)
        return status;

    return atcab_info(info);                               // Invoke the underlying info command
}

ATCA_STATUS atsha204a_get_serial(uint8_t sn[9])
{
    if (!sn)
        return ATCA_BAD_PARAM;                             // Null pointer, parameter error

    ATCA_STATUS status = atsha204a_init();                 // Make sure it is initialized
    if (status != ATCA_SUCCESS)
        return status;

    return atcab_read_serial_number(sn);                   // Invoke the underlying Serial command
}

Other Features

  • Relevant functions have been implemented through each function in the example, please refer to the relevant demo for detailed analysis
  • C demo

ATSHA204A-WIKI-1.jpg

  • Python demo (The underlying layer also uses C files, and the basic functions have been encapsulated.)

ATSHA204A-WIKI-2.jpg

  • After performing the lock operation, the area will be unable to be unlocked. Please do not perform batch operations before confirming the parameters
  • Note that the correlation cannot be seen in the above unlocked area, and a series of parameters such as the random number read cannot be seen, the data can only be seen normally after the area is locked
  • If the area is configured as a "normal storage slot" after the area is locked, read and write verification can be performed, please note that the area cannot be unlocked after the area is locked!

ATSHA204A-WIKI-3.jpg

  • Here, the lock area program in the Python example has been modified (see the comments at the bottom, note that it cannot be unlocked after being locked!)

ATSHA204A-WIKI-4.jpg

Explanation of Config Area and Data Area

Config Area (Configuration Zone)

The config area stores: the configuration and permissions of the chip, such as:

  • Can each Data slot be read? Can it be written? Should it be encrypted when writing?
  • Is I2C or a single-wire interface used? What is the I2C address?
  • Lock status, some global options (such as whether certain commands are allowed).
  • A bit like "System Settings / BIOS".

Features:

  • Fixed size (128 bytes), layout is fixed in the datasheet: SN and Rev at the beginning, followed by SlotConfig/KeyConfig, etc.
  • Usually written only once during the factory configuration phase:
  • Design the strategy for each slot; write it into the Config area; after confirming there are no issues, execute once LockConfig → Permanently lock it, so it can no longer be changed in the future.
  • Once the Config area is locked: the "permission rules" in Config are fixed; subsequent access behaviors in the Data area will strictly follow these rules.

So: The Config area is more like a "rule manual + permission table".

{
    uint8_t slot = 15;                              // Specify slot 15
    size_t offset = 20u + (size_t)slot * 2u;        // Search for offset bytes
    // TODO: Change the following two bytes to the actual calculated SlotConfig[15] value, currently set to "Normal storage slot"
    cfg[offset + 0] = 0x00;           // Low bytes (LSB, cfg[offset + 0])    
        // bit 0–3:ReadKey = 0      Specify the "Key number used when reading this slot" (0–15)             
        // bit 4:  CheckOnly = 0      0: Normal slot, can participate in read/write/MAC operations           1 = Only used for CheckMac, normal read/write is not allowed" 
        // bit 5: SingleUse = 0      0: Can be used multiple times (normal slot)                             1 = "Disposable (with counter), void after use" 
        // bit 6: EncryptRead = 0    0: Read in plain text, when reading this slot, the returned data is the original bytes stored in the slot       1 = "Reading this slot must be encrypted (cannot be read in plain text)." 
        // bit 7: IsSecret = 0      0: Non-confidential slot, the chip will not force the use of "key security policy" for this slot      1 = "This slot is treated as a key / confidential data" 
    cfg[offset + 1] = 0x00;            // High bytes (MSB, cfg[offset + 1])    
        // bit 0~3: WriteKey = 0       Points to a "write-protected key slot", and if WriteConfig requires "encrypted writes", the chip participates in the calculation with the key slot specified by the WriteKey (e.g. MAC/decrypt data)
        // bit 4–7: WriteConfig = 0   Set to a certain "encrypted write mode", specifically according to the manual, if WriteConfig is a plaintext mode such as Always / Never, the WriteKey can be kept at 0 and not participated. 
}

Data Area (Data Zone)

The Data area is where the real "valuable things" are stored, such as:

  • Symmetric key (AES/HMAC key);
  • Serial number extension, user ID;
  • Small block configuration data, counters, flags, etc.

Structure:

  • Divided into multiple slots, each usually 32 bytes or multiples;
  • The "behavior and permissions" of each slot are determined by the SlotConfig/KeyConfig in the Config area:
  • Some slots allow plaintext reading/writing;
  • Some slots only allow indirect access through encrypted commands (e.g., they can only be verified using MAC/CheckMac, not directly read out the keys);
  • Some slots serve as counters and limit the number of times they can be used.
  • As long as LockConfig is still 0x55 (Config not locked), all read/write operations to Data/OTP are prohibited.
  • As long as LockData remains unlocked, the read/write success indicator for Data/OTP is invalid and cannot be used as a reference.

Area Locking

The Data area also has an overall lock position: LockData; The usual process is:

  • Note: Do not lock the area until you are familiar with the relevant settings. Once locked, it cannot be unlocked!!!
  • Config area is written and locked;
  • Write keys and parameters to each slot according to the Config rules;
  • After confirming that all are correct → execute LockData → the entire Data area permissions will take effect and cannot be changed.

So: Data Zone = the repository where "secret" and application data are actually stored, Config Zone = the rules that determine how each "door" of these repositories is locked and who can enter how.

Resources

Datasheets

Demo

FAQ

 Answer:

Please reduce the I2C communication rate.