STM32F103驱动ATSHA204A硬件加密芯片实战：I2C与SWI接口详解-编程实验室

简介：本资源面向嵌入式安全开发工程师及STM32初学者，提供ATSHA204A加密芯片的完整软硬件集成方案，解决物联网设备身份认证、密钥存储与挑战响应式鉴权等核心安全需求。压缩包共1020个文件，总计10.84MB，涵盖95个头文件（h）、81个C源码（c）及大量编译中间文件（o/d/crf），其中主程序清晰演示I²C与单线SWI双接口初始化、序列号读取、密钥配置、随机数生成及SHA-256挑战响应计算全流程；同时包含ATSHA204A官方PDF数据手册、原理图与PCB参考设计，以及基于STM32F103的Keil工程（含uvprojx、axf、map等）。已有1328人下载学习，内容结构完整、即拿即用，特别适合快速验证加密芯片功能、理解安全协处理器驱动逻辑及构建可信启动基础模块。

1. 项目背景与ATSHA204A芯片初探

最近在做一个需要硬件加密功能的小项目，选型时盯上了Microchip（原Atmel）的ATSHA204A这颗芯片。这玩意儿在物联网设备、消费电子里用得挺多，主要就是干一件事：给设备一个唯一的、不可克隆的“身份证”，同时还能做点简单的数据加解密和验证。说白了，就是防止你的硬件被山寨，或者固件被随便刷。网上资料说它好用的不少，但真到自己动手把芯片焊到板子上，然后写代码去驱动它，才发现坑是一个接一个。官方给的数据手册全是英文，虽然严谨但读起来费劲；参考设计电路看着简单，实际布线时对电源和信号完整性的要求一点不低；最头疼的是软件，I2C和单线接口（SWI）两种模式，时序要求严格，稍有不慎就通信失败。

我这次用的主控是STM32F103C8T6，也就是大家常说的“蓝屏”最小系统板，性价比高，资源也够用。项目目标很明确：在STM32F103上，分别通过I2C和SWI接口，成功驱动ATSHA204A芯片，完成最基本的读序列号、生成随机数、计算SHA-256摘要以及验证MAC（消息认证码）这些操作。我把整个摸索过程，从硬件连接到软件调试，再到最后跑通的DEMO程序，都整理了出来。如果你也在用这颗加密芯片，或者对STM32的硬件加密外设驱动感兴趣，这篇内容应该能帮你省下不少查资料和调试的时间。

2. ATSHA204A核心功能与硬件设计要点

ATSHA204A本质上是一个基于硬件的加密认证协处理器，内部集成了SHA-256算法引擎、一个512位的EEPROM（用于存储密钥、证书等敏感数据）、一个高质量的随机数发生器（RNG）以及一个唯一的72位序列号。它的主要应用场景包括：防止固件克隆、确保配件（如电池、墨盒）为正品、建立设备间的安全通信链路等。

2.1 芯片关键特性与工作模式解析

首先得搞清楚这颗芯片怎么用。它支持两种通信接口：I2C和单线接口（Single-Wire Interface， SWI）。I2C模式大家都很熟悉，两根线（SDA， SCL），地址是固定的0xC0（写）和0xC1（读），注意这是7位地址左移一位后的8位地址表示。I2C速度最高支持1MHz，对于STM32F103来说完全够用。

SWI模式就比较特殊了，它只用一根线进行双向通信。这根线平时由上拉电阻拉到高电平，通信时由主机（单片机）控制输出高低电平来实现。它的协议是类似单总线的，但时序和命令结构是Atmel自定义的。SWI模式的优点是可以节省一个IO口，并且在布线非常紧张或者需要电气隔离的场景下有点用。但缺点也很明显，时序更敏感，软件驱动实现起来比I2C要复杂一些，调试也更麻烦。

芯片的工作电压范围是2.0V到5.5V，很宽。但这里有个细节：芯片的IO电平是与VCC绑定的。也就是说，如果你的单片机是3.3V系统，那么ATSHA204A的VCC也必须供3.3V，这样才能保证通信电平匹配。如果你给它供5V，而单片机是3.3V，虽然芯片可能不会坏（因为IO口耐压可能够），但直接连接会有电平不匹配的风险，严重时会损坏单片机IO口。稳妥的做法是双方电压一致，或者使用电平转换电路。

2.2 硬件电路设计参考与避坑指南

官方数据手册里提供的参考设计原理图其实已经非常清晰了。我这里结合自己踩过的坑，强调几个关键点：

电源与去耦：这是所有数字芯片稳定工作的基础，对加密芯片尤其重要。ATSHA204A的VCC和GND引脚必须就近放置一个0.1uF的陶瓷电容进行高频去耦。如果电源线比较长，还需要在电源入口处加一个10uF左右的钽电容或电解电容进行低频滤波。电源的干净与否，直接影响到内部随机数发生器的质量以及通信的稳定性。我曾经因为省事没加0.1uF电容，结果芯片偶尔会无响应，加上之后就再没出现过。
I2C接口电路：标准的I2C线路，SCL和SDA都需要上拉电阻。阻值的选择取决于总线电容和通信速度。对于常见的100kHz或400kHz速率，以及板上距离不远的连接，4.7kΩ到10kΩ的上拉电阻是通用选择。我用的是4.7kΩ，通信很稳定。特别注意：ATSHA204A的I2C引脚是开漏输出，所以这个上拉电阻是必须的，单片机端的I2C引脚也需要配置为开漏模式。
SWI接口电路：SWI引脚同样需要上拉电阻，典型值也是4.7kΩ到10kΩ。由于是单线双向，单片机的这个IO口必须配置为开漏模式，并且具备在输入和输出模式间快速切换的能力。在软件驱动里，控制IO口输出低电平来发送“0”，而发送“1”或接收时，则需要将IO口设置为高阻输入（或开漏输出高电平），依靠上拉电阻将总线拉高。
GPIO连接（可选）：ATSHA204A有一个GPIO引脚，可以配置为输入或输出，用于简单的状态指示或与主机的交互。比如，可以配置成在特定命令执行完成后产生一个中断信号给单片机。如果不用，这个引脚悬空即可。
PCB布局：尽量让ATSHA204A靠近单片机，缩短走线长度。电源和地线要粗。I2C或SWI信号线最好走在一起，避免与其他高速或噪声大的信号线（如电机驱动线、开关电源线）平行走线，以减少干扰。

注意：ATSHA204A的GND引脚必须与系统的数字地可靠连接。整个系统的接地要良好，否则可能引入难以排查的通信错误。

3. STM32F103的I2C驱动ATSHA204A实战

我首先实现的是I2C接口驱动，因为STM32的硬件I2C外设用起来相对直观。我使用的是STM32标准外设库（StdPeriph_Lib），当然用HAL库或者LL库原理也一样。

3.1 STM32 I2C外设初始化与配置陷阱

初始化代码看起来简单，但有几个参数配置不对就会导致整个通信失败。

// I2C 初始化结构体 I2C_InitTypeDef I2C_InitStructure; GPIO_InitTypeDef GPIO_InitStructure; // 1. 开启时钟 RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE); // 假设用PB6, PB7 RCC_APB1PeriphClockCmd(RCC_APB1Periph_I2C1, ENABLE); // 2. 配置GPIO为复用开漏模式 GPIO_InitStructure.GPIO_Pin = GPIO_Pin_6 | GPIO_Pin_7; // SCL, SDA GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_OD; // 复用开漏 GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOB, &GPIO_InitStructure); // 3. 配置I2C I2C_InitStructure.I2C_Mode = I2C_Mode_I2C; I2C_InitStructure.I2C_DutyCycle = I2C_DutyCycle_2; // 标准模式用2， 快模式用16/9 I2C_InitStructure.I2C_OwnAddress1 = 0x00; // 单片机作为从机地址，主模式可设为任意值 I2C_InitStructure.I2C_Ack = I2C_Ack_Enable; I2C_InitStructure.I2C_AcknowledgedAddress = I2C_AcknowledgedAddress_7bit; I2C_InitStructure.I2C_ClockSpeed = 400000; // 400kHz I2C_Init(I2C1, &I2C_InitStructure); I2C_Cmd(I2C1, ENABLE);

关键点与避坑：

GPIO模式：必须设置为GPIO_Mode_AF_OD（复用开漏），而不是推挽输出。开漏输出才能实现“线与”功能，配合上拉电阻形成正确的高电平。
时钟速度：ATSHA204A支持最高1MHz，但STM32F103在72MHz系统时钟下，I2C的时钟频率设置需要计算。设置成400kHz（快速模式）是比较稳妥且高效的选择。设置完后，最好用逻辑分析仪抓一下波形，看实际SCL频率是否匹配。
应答：I2C_Ack_Enable必须开启。虽然我们是主机，但STM32的I2C外设在接收数据时，需要硬件自动发出ACK信号。
自身地址：在纯主机模式下，这个地址用不上，但必须设置一个非冲突的值，不能是0x00或0xFF。

3.2 ATSHA204A I2C通信协议与命令封装

ATSHA204A的通信不是简单的读写寄存器，它有一套基于命令包（Command Packet）和响应包（Response Packet）的协议。每个操作，比如读序列号，都需要主机构建一个符合格式的命令包发送给芯片，然后等待并读取芯片返回的响应包。

一个命令包的基本结构是：

Word Address：固定为0x03，表示这是一个命令。
Count：整个数据包（包括Word Address、Count本身和后续所有数据）的字节总数。
Command Opcode：操作码，比如读序列号是0x30。
Param1， Param2：命令参数。
Data：可选的数据域。
CRC：对整个包（从Count开始到Data结束）计算的CRC16校验码。

响应包的结构类似，以Count字节开始，包含状态码、返回数据和CRC。

我写了一个通用的发送命令函数atsha204a_send_command和一个读取响应函数atsha204a_receive_response。这里以读取72位唯一序列号（Opcode: 0x30）为例，展示核心流程：

uint8_t atsha204a_read_serial_number(uint8_t *serial_out) { uint8_t command_packet[ATSHA204A_CMD_SIZE_MIN]; uint8_t response[ATSHA204A_RSP_SIZE_32]; // 读序列号响应包较长 // 1. 构建命令包 command_packet[0] = ATSHA204A_WORD_ADDR; // 0x03 command_packet[1] = ATSHA204A_CMD_SIZE_MIN; // 包长度 command_packet[2] = ATSHA204A_OPCODE_READ; // 0x30 command_packet[3] = 0x00; // Param1: 读哪个区域？这里读“Config”区域的特定位置 command_packet[4] = 0x00; // Param2: 具体位置偏移 // 计算CRC并填充到command_packet[5]和[6] atsha204a_calculate_crc(ATSHA204A_CMD_SIZE_MIN - 2, &command_packet[1], &command_packet[5]); // 2. 唤醒芯片（如果处于睡眠模式） atsha204a_wakeup(); // 3. 发送命令包 if (i2c_write_bytes(ATSHA204A_I2C_ADDR_WRITE, command_packet, ATSHA204A_CMD_SIZE_MIN) != SUCCESS) { return STATUS_FAIL; } // 4. 等待命令执行完成。读序列号需要时间，数据手册规定最大延迟。 delay_ms(ATSHA204A_EXEC_TIME_READ); // 典型值几毫秒 // 5. 读取响应包 if (i2c_read_bytes(ATSHA204A_I2C_ADDR_READ, response, ATSHA204A_RSP_SIZE_32) != SUCCESS) { return STATUS_FAIL; } // 6. 验证响应包的CRC if (!atsha204a_check_crc(response, ATSHA204A_RSP_SIZE_32)) { return STATUS_CRC_ERROR; } // 7. 检查状态码（响应包的第1个字节，即Count之后） if (response[1] != ATSHA204A_STATUS_SUCCESS) { return response[1]; // 返回错误状态码 } // 8. 提取序列号数据（从响应包第2字节开始） memcpy(serial_out, &response[2], ATSHA204A_SERIAL_NUM_SIZE); // 通常是9字节 return STATUS_SUCCESS; }

调试这个过程中的核心教训：

唤醒序列：ATSHA204A有个低功耗睡眠模式。如果通信不上，第一步不是怀疑代码，而是先发送一个特定的“唤醒”信号：在SCL为高时，将SDA拉低至少60us，然后释放。这个操作需要直接用GPIO模拟实现，因为硬件I2C无法产生这种不符合I2C起始条件的信号。我的做法是，在初始化I2C前，先把SDA和SCL的GPIO配置成推挽输出，手动产生这个时序，然后再切换回I2C复用模式。
时序延迟：每个命令执行都需要时间，delay_ms的等待是必须的。时间不够就读不到数据，会返回“命令未完成”的错误。具体延迟时间查数据手册，不同命令不一样。
CRC校验：一定要做！这是确保数据完整性的关键。我一开始图省事没校验，偶尔读到错误的数据，排查了很久。CRC算法是标准的CRC-16，多项式是0x8005，初始值是0x0000。网上有现成的代码，但要注意计算范围（从Count字节开始，到Data结束）。
I2C超时处理：STM32的硬件I2C在总线被意外拉低（比如设备未响应）时可能会挂死。务必在发送和接收函数里加入超时机制，超时后重新初始化I2C外设。

4. 单线接口（SWI）驱动实现与深度调试

SWI驱动是本次项目的一个难点，因为需要软件模拟精确的时序。SWI协议是基于时间槽的，主机通过控制信号线低电平的持续时间来发送“0”或“1”，以及特殊的唤醒脉冲、起始条件。

4.1 SWI协议时序的软件模拟关键点

SWI通信的基本单位是“位”。发送一位的时序如下：

发送‘0’：主机将总线拉低约60us，然后释放（设置为输入），等待约5us的“采样延迟”后，再开始下一位。
发送‘1’：主机将总线拉低约2us，然后释放，同样等待采样延迟。

一个字节的发送是LSB（最低位）在先。每个命令或数据包之前，需要先发送一个“起始条件”：一个持续约80us的低电平脉冲。之后是7位命令码（注意，不是I2C的地址，SWI没有地址概念，因为总线上通常只挂一个设备）和1位读写方向位。

接收数据时，主机先拉低2us发出“读时隙”起始信号，然后释放总线并迅速切换到输入模式，在延迟一段时间后（比如20us）去读取总线电平。高电平为‘1’，低电平为‘0’。

实现这样的时序，对延时函数的精度要求很高。在STM32F103上，不能使用简单的for循环延时，因为编译器优化和中断会影响精度。必须使用系统滴答定时器（SysTick）或者通用定时器（TIM）来产生微秒级延时。

// 使用SysTick实现微秒延时（系统时钟72MHz） void delay_us(uint32_t us) { uint32_t ticks = us * (SystemCoreClock / 1000000); uint32_t start_tick = SysTick->VAL; while ((start_tick - SysTick->VAL) < ticks) { // 等待 } } // 发送一个SWI字节 void swi_send_byte(uint8_t data) { uint8_t i; for (i = 0; i < 8; i++) { if (data & 0x01) { // 先发送LSB swi_write_slot(1); // 发送‘1’时隙 } else { swi_write_slot(0); // 发送‘0’时隙 } data >>= 1; delay_us(SWI_T_SAMPLE); // 位间采样延迟 } } // 发送一个位时隙 void swi_write_slot(uint8_t bit_value) { SWI_GPIO_PORT->BSRR = SWI_PIN; // 拉低总线 if (bit_value) { delay_us(SWI_T_ONE_LOW); // ‘1’的低电平时间，约2us } else { delay_us(SWI_T_ZERO_LOW); // ‘0’的低电平时间，约60us } SWI_GPIO_PORT->BRR = SWI_PIN; // 释放总线（设置为输出高？这里有问题！） }

上面代码有个严重问题：swi_write_slot函数在释放总线时，只是将GPIO输出低电平寄存器清零，如果GPIO之前配置为推挽输出，这会让总线输出低电平，而不是释放！正确的做法是，在需要释放总线（即让总线由上拉电阻拉高）时，必须将GPIO配置为输入模式（或开漏输出且输出高电平）。因此，驱动函数需要在输出和输入模式间频繁切换。

4.2 SWI驱动中的IO模式切换与优化

修正后的思路是：

总线输出低电平：将GPIO配置为推挽输出，并输出低。
总线释放（高阻）：将GPIO配置为浮空输入（或上拉输入），或者配置为开漏输出并输出高。我选择配置为浮空输入，因为外部有上拉电阻。这样切换速度要快，因为时序要求严格。直接操作寄存器比调用库函数快。

// 宏定义，快速设置IO方向 #define SWI_SET_OUTPUT() do { \ GPIOB->CRL &= ~(0xF << (4*0)); /* 清除PB0原有配置 */ \ GPIOB->CRL |= (0x3 << (4*0)); /* 推挽输出，50MHz */ \ } while(0) #define SWI_SET_INPUT() do { \ GPIOB->CRL &= ~(0xF << (4*0)); \ GPIOB->CRL |= (0x4 << (4*0)); /* 浮空输入 */ \ } while(0) #define SWI_WRITE_LOW() (GPIOB->BRR = GPIO_Pin_0) #define SWI_WRITE_HIGH() (GPIOB->BSRR = GPIO_Pin_0) // 注意：在输入模式下这个操作无效 #define SWI_READ() ((GPIOB->IDR & GPIO_Pin_0) != 0) void swi_write_slot_corrected(uint8_t bit_value) { SWI_SET_OUTPUT(); SWI_WRITE_LOW(); // 拉低总线开始一个时隙 if (bit_value) { delay_us(SWI_T_ONE_LOW); } else { delay_us(SWI_T_ZERO_LOW); } SWI_SET_INPUT(); // 关键！释放总线，切换到输入模式 // 不需要再软件拉高，上拉电阻会完成这个工作 // 保持一段高电平时间（根据协议要求） delay_us(SWI_T_HIGH); }

接收位时隙的函数也需要类似的模式切换。调试SWI驱动时，逻辑分析仪是必不可少的。你需要清晰地看到每一个低电平脉冲的宽度、位与位之间的间隔、以及主机释放总线后总线被上拉电阻拉高的过程。任何时序的偏差都可能导致ATSHA204A无法正确解析命令。

5. DEMO软件例程功能详解与使用指南

我提供的DEMO工程基于Keil MDK开发，使用了STM32标准外设库。工程结构清晰，主要分为以下几个部分：

main.c：主程序，演示了芯片初始化、读序列号、生成随机数、计算MAC等基本流程。
atsha204a_i2c.c/.h：I2C接口的底层驱动和命令封装。
atsha204a_swi.c/.h：SWI接口的底层驱动和命令封装。
atsha204a_crc.c/.h：CRC16校验计算函数。
delay.c/.h：高精度延时函数（基于SysTick）。
i2c_soft.c/.h（可选）：如果你不想用硬件I2C，我还提供了一个经过验证的软件模拟I2C驱动。

5.1 主程序流程与功能演示

主程序首先初始化系统时钟、延时函数和串口（用于打印调试信息）。然后，根据一个宏定义USE_SWI来选择使用I2C还是SWI接口与ATSHA204A通信。

int main(void) { uint8_t serial_num[9]; uint8_t random_num[32]; uint8_t response[32]; uint8_t status; // 硬件初始化 SystemInit(); Delay_Init(); USART1_Init(115200); printf("ATSHA204A Demo Start...\r\n"); #if USE_SWI printf("Using SWI Interface.\r\n"); swi_init(); // 初始化SWI GPIO #else printf("Using I2C Interface.\r\n"); i2c_hardware_init(); // 初始化硬件I2C #endif // 1. 唤醒芯片 atsha204a_wakeup(); printf("Device Waked Up.\r\n"); // 2. 读取并打印72位唯一序列号 status = atsha204a_read_serial_number(serial_num); if (status == STATUS_SUCCESS) { printf("Serial Number: "); for (int i = 0; i < 9; i++) { printf("%02X ", serial_num[i]); } printf("\r\n"); } else { printf("Read Serial Failed: 0x%02X\r\n", status); } // 3. 生成一个32字节的随机数 status = atsha204a_random(random_num); if (status == STATUS_SUCCESS) { printf("Random Number: "); for (int i = 0; i < 32; i++) { printf("%02X ", random_num[i]); } printf("\r\n"); } // 4. 计算MAC (Message Authentication Code) 示例 // 这里需要预先在芯片的某个Slot里写入一个密钥。假设密钥在Slot 0。 uint8_t challenge[32] = { ... }; // 一个挑战数据 status = atsha204a_mac(challenge, 0 /* Slot ID */, response); if (status == STATUS_SUCCESS) { printf("MAC Result: "); for (int i = 0; i < 32; i++) { printf("%02X ", response[i]); } printf("\r\n"); } while (1) { // 主循环 } }

5.2 工程配置与移植注意事项

宏定义切换：在atsha204a_config.h文件中，可以方便地切换USE_SWI宏来选择通信接口。同时，I2C的引脚定义、SWI的引脚定义、时序参数（微秒数）都在这里配置。
时钟配置：DEMO默认使用72MHz系统时钟。如果你的晶振频率不同，需要修改system_stm32f10x.c中的相关配置，并调整delay_us函数中的延时系数。
引脚冲突：检查i2c_hardware_init和swi_init中使用的GPIO引脚（如PB6， PB7， PB0）是否与你的板子上的其他外设（如USB、晶振）冲突。
上拉电阻：再次强调，无论是I2C还是SWI，硬件上必须连接正确的上拉电阻（4.7kΩ-10kΩ）到3.3V。
电源：确保ATSHA204A的VCC引脚连接的是稳定的3.3V（与STM32同源最好）。

如果一切连接正确，编译下载程序后，打开串口助手（波特率115200），你应该能看到芯片的序列号和一串随机数被打印出来。这是验证硬件连接和底层驱动是否成功的最直接标志。

6. 常见问题排查与进阶使用思考

即使按照参考设计连接，代码也似乎正确，仍然可能遇到问题。下面是我在调试过程中遇到的一些典型问题及解决方法。

6.1 通信失败问题排查清单

当调用atsha204a_read_serial_number等函数返回失败时，可以按照以下步骤排查：

电源和地线：用万用表测量ATSHA204A的VCC和GND引脚电压是否为稳定的3.3V？纹波是否过大？地线连接是否可靠？
上拉电阻：I2C的SDA、SCL或SWI数据线是否接了上拉电阻？阻值是否合适？可以用万用表测量总线空闲时的电压，应该是接近3.3V的高电平。
唤醒序列：对于I2C模式，在首次通信前是否执行了正确的唤醒序列？可以用逻辑分析仪抓取SDA和SCL的波形，看起始条件前是否有一个持续60us以上的低电平脉冲（SDA低，SCL高）。
时序问题：
- I2C：用逻辑分析仪检查I2C的起始信号、地址、数据、ACK和停止信号是否都符合规范。STM32的I2C时钟频率设置是否正确？
- SWI：用逻辑分析仪检查每一位的“低电平时间”和“高电平时间”是否严格符合数据手册要求（误差最好在±10%以内）。特别注意主机释放总线后，总线电压是否被顺利上拉到高电平。
CRC错误：如果返回状态是CRC错误，说明数据在传输过程中出错了。检查硬件连接是否松动，电源噪声是否太大。也可以尝试降低I2C的通信速率（比如从400kHz降到100kHz）看是否改善。
芯片是否损坏：尝试更换一颗新的ATSHA204A芯片。静电或电源浪涌可能导致芯片损坏。
软件延时：命令执行后的delay_ms是否足够长？可以尝试将延时时间加倍测试。

6.2 从Demo到产品：密钥管理与安全考量

这个DEMO程序只是为了验证通信和基本功能。在实际产品中使用ATSHA204A进行安全认证时，有几个更重要的层面需要考虑：

密钥的烧录与存储：ATSHA204A的EEPROM中有一个专门的Config区和一个Data区（包含多个Slot）。你需要规划好哪个Slot存放用于MAC计算的密钥，哪个Slot存放其他数据。最重要的密钥必须在绝对安全的环境下烧录，通常是在芯片贴片前，由生产厂家使用Microchip提供的专用工具和加密机进行。一旦烧录并锁定了相关区域，密钥就永远无法被读取出来，只能用于内部计算。
配置区的锁定：芯片出厂时Config区是可写的。在你完成所有配置（如设置Slot的权限、是否加密读写等）后，必须发送“Lock Config Zone”命令将其永久锁定。锁定后，大部分配置将无法更改。
数据区的锁定：Data区（存放密钥的Slot）也可以单独锁定。锁定后，密钥就无法再被修改或读取（根据权限设置）。
认证流程设计：简单的认证可以是“挑战-响应”模式。服务器（或主设备）生成一个随机数（挑战）发送给客户端（带ATSHA204A的设备），客户端用芯片内部密钥对这个挑战计算MAC，并将结果（响应）发回服务器。服务器用同样的密钥进行计算并比对。关键点在于，真正的密钥从未在通信线上出现，且每次挑战不同，响应也不同，能有效防止重放攻击。
代码安全：单片机中调用ATSHA204A的代码本身也可能成为攻击点。虽然密钥在加密芯片里很安全，但如果攻击者能够篡改单片机的程序，让它总是返回“认证成功”，那么安全机制就形同虚设。因此，需要考虑对单片机的固件进行加密或签名校验。

最后，ATSHA204A只是一个组件，真正的系统安全是一个体系，需要结合安全的通信协议（如TLS）、安全的启动流程、安全的固件更新机制等共同构建。这个DEMO可以作为你探索硬件加密世界的第一块敲门砖，理解了它的基本运作方式后，你就能更好地去设计和完善整个产品的安全架构了。

本文还有配套的精品资源，点击获取