ATECC608B EEPROM访问策略详解：安全存储与加密访问实战

1. 项目概述：为什么ATECC608B的EEPROM访问是安全设计的核心

如果你正在设计一个需要硬件级安全认证、密钥存储或防篡改功能的产品，比如智能门锁、支付终端、物联网网关，那么你大概率绕不开Microchip的ATECC608B这颗芯片。它常被称作“加密协处理器”或“安全元件”，但很多工程师第一次接触时，最头疼的往往不是那些复杂的加密指令，而是最基础的：数据怎么存进去，又怎么安全地读出来？

这恰恰是ATECC608B设计的精妙之处。它的内部EEPROM（电可擦可编程只读存储器）远非一个简单的存储阵列。你不能像操作普通24C02那样，给个I2C地址和偏移量就随意读写。它的每一个存储区（Slot）都有独立的、可配置的访问策略，这些策略与芯片的加密引擎、状态机深度绑定，共同构成了一个坚不可摧的安全边界。理解这些策略，是正确使用ATECC608B的基石，否则你可能会遇到“权限不足”、“命令失败”等令人困惑的错误，甚至可能因配置不当而永久锁死芯片。

简单来说，ATECC608B的EEPROM存储区与数据访问策略，定义了“谁”（哪种命令或状态）“在什么条件下”（是否需要加密、认证）“能对哪块数据”（哪个Slot）“做什么操作”（读、写、加密写、递增等）。这就像给保险箱里的每个格子都配了不同的锁和开门规则。本文将深入拆解这套规则体系，结合我实际在多个物联网安全项目中的踩坑经验，手把手带你弄懂配置逻辑、避开常见陷阱，并解释其背后的安全设计哲学。

2. ATECC608B EEPROM存储区结构全景解析

ATECC608B的EEPROM总容量为10KB，但这10KB被严格划分为多个功能区域，每个区域都有其固定用途。你不能把它当作一个连续的、扁平的地址空间来理解。下图是其核心存储结构的逻辑视图：

这里需要重点理解两个关键概念：Zone（区）和Slot（槽）。

配置区是芯片的“大脑”。在芯片出厂后、投入使用前，你必须根据应用需求，精心编写配置数据并写入该区，然后执行Lock Config Zone命令将其永久锁定。锁定后，绝大部分配置内容（包括所有Slot的访问策略）将无法再更改。这意味着，你的安全策略必须在设计阶段就考虑周全。配置区中定义了每个Slot的“元数据”，比如它的大小、类型（是私钥、对称密钥还是普通数据），以及最重要的——SlotConfig和KeyConfig这两个决定访问策略的寄存器值。

数据区是存储用户数据的“仓库”，它被划分为最多16个Slot（编号0-15）。每个Slot可以独立配置大小（0、32、64、128、256、416字节不等），但总容量不能超过10KB减去配置区和OTP区后的剩余空间。Slot是访问控制的基本单元。当你通过Read或Write命令操作时，对象就是某个Slot。

OTP区比较特殊，它的每一位通常只能从1编程为0（或根据模式设置）。它适合存放那些一旦设定就不希望被更改的信息，比如产品的最终序列号。其访问策略相对固定，但也可以通过配置进行一定限制。

很多初学者容易混淆的是地址。请注意，配置区、数据区和OTP区在逻辑上是独立的，它们有各自独立的地址空间，通常都是从0x0000开始。你在发送读写命令时，需要指定操作的是哪个Zone，以及在该Zone内的偏移地址。例如，读配置区的序列号，和读数据区Slot0的第一个字节，使用的命令和地址编码方式是不同的，芯片内部的状态机会根据Zone参数进行路由。

3. 访问策略的神经中枢：SlotConfig与KeyConfig详解

访问策略并非凭空产生，它由配置区中两个关键的128位（16字节）寄存器阵列定义：SlotConfig和KeyConfig。每个Slot都对应这两个阵列中的一个条目（各2字节）。正是这4个字节（32位）的数据，像DNA一样编码了该Slot的完整“性格”和“门禁规则”。

3.1 SlotConfig：定义基础访问权限

SlotConfig寄存器（每个Slot占用2字节）主要控制该Slot本身数据的读写权限。它的每一个比特位都有明确含义。我们以一个典型的用于存储非对称私钥的Slot配置为例（假设为Slot 0）来拆解：

假设SlotConfig[0]的值被设置为0x83A0。我们将其分解为二进制（16位）来分析：

• Bit 15:8 (高字节 0x83):

  • Bit 15:12 (0x8): 这4位通常与WriteKey相关（在某些上下文中），但更关键的是它们与KeyConfig联动。我们稍后结合看。
  • Bit 11:8 (0x3): 这4位是ReadKey字段。0x3是一个特殊值，它表示“永远允许读取”。注意，对于私钥Slot，这通常不是读取原始私钥数据，而是允许使用该私钥进行签名或生成共享密钥等操作。如果这里设置为一个Slot编号（如0x0），则表示需要该Slot对应的密钥进行认证后才能读。

• Bit 7:0 (低字节 0xA0):

  • Bit 7:4 (0xA): 这4位是WriteConfig字段。0xA也是一个典型值，它定义了写入此Slot的条件。0xA通常表示“需要Encrypt（加密写入）”。这意味着，向这个Slot写数据不能使用普通的Write命令，而必须使用GenDig（生成摘要）、Nonce（生成随机数）和Write命令组合的加密写入流程，且写入的数据是经过会话密钥加密的。这是保护密钥不被旁路探测的关键机制。
  • Bit 3:0 (0x0): 这4位是IsSecret和WriteKey等标志的组合。0x0通常表示这是一个私钥Slot (IsSecret=1)，并且其WriteKey可能指向自身或一个特殊值，意味着写入权限与加密绑定，而不是另一个密钥。

从上面的分析可以看出，对于私钥Slot，典型的配置是：禁止明文读取、必须加密写入。ReadKey=0x3看似开放了读权限，但实际上芯片硬件会拦截直接的明文读取请求，这个“读权限”实际转化为“允许使用该密钥进行密码学运算的权限”。

3.2 KeyConfig：定义密钥类型与使用方式

KeyConfig寄存器（同样每个Slot2字节）进一步定义了该Slot中数据的“类型”和“用途”。继续以Slot 0为例，假设KeyConfig[0] = 0x0033。

• Bit 15:8 (0x00): 这部分包含ReqAuth（是否需要授权）、ReqRandom（是否需要在命令中提供随机数）等扩展标志。0x00表示不需要额外授权。
• Bit 7:0 (0x33): 这是核心定义位。
  • Bit 7:4 (0x3):KeyType字段。0x3代表这是P256 NIST ECC私钥。如果是0x4，则可能是AES-128对称密钥。不同的KeyType决定了该Slot数据如何被加密引擎解释。
  • Bit 3:0 (0x3):Lockable(可锁定) 和SlotType等。0x3的常见解释是该Slot是私钥，且其GenKey（生成密钥）命令的行为是生成密钥对并将公钥输出，私钥永远不可见地存储在Slot内。

SlotConfig和KeyConfig的联动是理解策略的关键。例如：

• SlotConfig.WriteConfig = Encrypt要求写入必须加密。
• KeyConfig.KeyType = P256 Private定义了加密时应使用哪种算法（ECDH）来派生会话密钥。
• SlotConfig.ReadKey = Always或SlotX决定了谁能“使用”这个密钥。

一个致命的常见错误是：工程师在配置时，希望某个Slot存储一个以后可以明文读取的证书（比如X.509设备证书），却错误地将KeyType配置成了Private Key。结果就是，你永远无法用Read命令取出这个证书！因为芯片硬件禁止明文读取Private Key类型的Slot，无论ReadKey如何设置。正确的做法是，将这类数据的KeyType设置为Data（数据类型），然后根据需要配置ReadKey和WriteConfig。

4. 核心数据访问命令实战与流程拆解

理解了静态配置，我们来看动态的执行过程。ATECC608B的所有交互都通过命令-响应的模式进行。访问EEPROM数据，主要涉及以下几个命令：Read,Write,GenDig,Nonce,UpdateExtra。其中，普通访问和加密访问的流程天差地别。

4.1 明文读取流程（以读取配置区或普通Data Slot为例）

这是最简单的流程，适用于ReadKey设置为Always（0x3）且KeyType非Private Key的Slot。

1. 构造Read命令：命令包中需要指定Zone（配置区/数据区/OTP区）、地址（Slot编号和偏移量）、长度。
2. 发送并执行：通过I2C将命令包发送给608B。
3. 获取响应：芯片执行后，会通过I2C返回指定长度的数据。

代码示例（伪代码风格）：

// 假设读取数据区 Slot 8 的前32字节数据（Slot8被配置为Data类型，ReadKey=Always） uint8_t read_cmd[] = { 0x03, // Read命令码 0x00, // Zone: 数据区，明文读取 0x00, 0x08, // Slot 8 的地址偏移（具体编码方式需参考数据手册） 0x00 // 长度（实际编码可能不同，这里示意） }; i2c_send(ATECC_ADDR, read_cmd, sizeof(read_cmd)); delay_ms(2); // 等待命令执行 i2c_receive(ATECC_ADDR, read_buffer, 32); // 读取32字节响应数据

注意：地址参数的具体编码需要仔细查阅数据手册。对于数据区，它通常是(SlotNum << 3)或类似的格式加上偏移量。这是第一个容易出错的点，地址算错会导致读取到错误数据或命令失败。

4.2 加密写入流程详解（以写入一个私钥或敏感数据到Slot为例）

这是ATECC608B安全性的核心体现。当WriteConfig设置为Encrypt时，必须遵循此流程。其核心思想是：写入的数据必须在主机（单片机）端使用一个临时的会话密钥加密，而608B内部可以利用共享秘密（另一个密钥）推导出相同的会话密钥进行解密。这个过程确保了即使I2C总线被监听，攻击者也只能看到密文。

详细步骤与原理：

1. Nonce（生成随机数）命令：

   • 目的：生成一个临时的会话随机数，用于后续的密钥派生，确保每次加密写入的会话密钥都不同（即使写入相同数据），防止重放攻击。
   • 操作：主机发送一个随机数R（通常来自单片机真随机数发生器）给608B。608B将其与内部的一个随机数混合，生成一个临时的Nonce值存储在它的易失性寄存器中。这个值后续用于GenDig。

2. GenDig（生成摘要）命令：

   • 目的：根据Nonce、目标Slot的密钥、以及可能的其他输入，通过SHA-256哈希运算，派生出一个会话密钥（Session Key）。这个密钥永远不会在总线上出现，只在608B内部和主机端（通过软件计算）分别生成。
   • 关键配置：执行GenDig命令时需要指定一个KeyID。这个KeyID就是用于派生会话密钥的“源密钥”所在的Slot编号。例如，你想加密写入Slot 0，你可能会使用Slot 15（一个预先共享的对称密钥）作为KeyID来执行GenDig。SlotConfig中的WriteKey字段有时就指向这个KeyID。
   • 主机端计算：主机必须同步进行完全相同的SHA-256计算。它需要知道源密钥（Slot 15的密钥值）、发送的Nonce随机数、以及608B的序列号等参数，才能计算出相同的会话密钥。这就要求源密钥必须同时被主机和608B所知，通常是在个人化阶段预先注入的。

3. Write（写入）命令：

   • 目的：执行实际的加密写入操作。
   • 操作：主机使用上一步生成的会话密钥，通过AES-128-CTR等模式加密待写入的明文数据，得到密文。然后将Write命令（包含Zone、地址等信息）和密文发送给608B。
   • 芯片端验证：608B收到密文后，在内部使用自己派生出的相同会话密钥进行解密，得到明文，然后将其写入指定的EEPROM Slot中。同时，它还会计算密文的MAC（消息认证码）进行完整性校验。

整个加密写入流程的要点：

• 源密钥（KeyID）的选择至关重要。它必须是一个主机和608B共享的密钥。通常，会预留一个Slot（如Slot 15）专门用于存储这个“传输密钥”。
• Nonce的随机性保证了前向安全。即使某次通信被破解，也无法推导出之前或之后的会话密钥。
• 主机端需要实现相应的加密算法（如SHA-256, AES-CTR）。Microchip提供了加密库（CryptoAuthLib）来帮助完成这些复杂计算。
• 顺序必须严格遵循：Nonce->GenDig->Write。任何步骤失败或顺序错误都会导致写入失败。

5. 高级策略与混合访问模式剖析

除了简单的“明文读”和“加密写”，ATECC608B支持更精细的、基于密码学认证的访问控制，这构成了其“权限分离”的安全模型。

5.1 基于MAC的认证读取

某些场景下，你可能希望Slot数据可以被读取，但前提是读取者必须证明自己“知道”某个密钥。这可以通过将Slot的ReadKey设置为另一个Slot的编号（例如Slot 10）来实现。

1. 配置：Slot 5（数据Slot）的ReadKey = 0x0A（指向Slot 10）。Slot 10中存储着一个对称密钥K_Auth。
2. 读取流程：
   • 主机首先执行Nonce和GenDig命令，使用Slot 10的密钥K_Auth来生成一个会话密钥和MAC。
   • 然后发送Read命令，但这次需要携带一个MAC（消息认证码）。
   • 608B验证MAC有效后，才允许数据被读出。攻击者不知道K_Auth，就无法生成有效的MAC，从而无法读取Slot 5的数据。

这种模式非常适合设备制造商向现场设备读取日志或特定配置，但需要提供认证密钥的场景。

5.2 使用私钥进行签名式外部认证

这是更高级的认证方式，常用于服务器验证设备真伪。它不直接读取Slot，而是验证设备是否拥有某个私钥。

1. 配置：设备端ATECC608B的Slot 0存储着设备私钥PrivDev。对应的公钥PubDev已提前在服务器注册。
2. 认证流程（挑战-响应）：
   • 服务器生成一个随机挑战Challenge（例如20字节随机数），发送给设备。
   • 设备单片机控制608B，使用Slot 0的私钥对Challenge进行签名（Sign命令），得到签名Signature。
   • 设备将Signature返回给服务器。
   • 服务器使用注册的PubDev验证Signature。验证通过，则证明设备确实拥有对应的私钥，身份可信。

在这个过程中，私钥PrivDev始终没有离开608B芯片。访问策略（SlotConfig/KeyConfig）确保了Sign命令可以被成功执行（例如，ReadKey被设置为允许签名）。

5.3 权限继承与组合

一个Slot的访问权限可能由多个策略共同决定。例如：

• 写入：可能需要加密（WriteConfig=Encrypt），并且加密所用的源密钥（WriteKey指向的Slot）本身也有读取限制。
• 读取/使用：可能需要MAC认证（ReadKey指向一个认证密钥Slot），而这个认证密钥的读取可能又需要其他条件。

这种嵌套的权限模型提供了极大的灵活性，可以构建出非常复杂的安全协议。例如，你可以设计一个系统，其中根密钥（Slot 15）永远不可读，但用于派生加密写入其他Slot的会话密钥；应用密钥（Slot 0-7）可以用于签名和加密；而用户数据（Slot 8-10）在认证后可以明文读取。

6. 实战配置案例、踩坑记录与调试技巧

理论之后，我们来点实际的。假设我们要为一个物联网设备配置ATECC608B，需求如下：

1. Slot 0: 存储设备唯一的ECC私钥，用于TLS客户端认证或签名。必须加密注入，且永远不能明文读出。
2. Slot 1: 存储对应的设备证书（X.509格式）。需要能明文读取，以便在TLS握手时发送给服务器。
3. Slot 15: 存储一个传输对称密钥K_TRANS，用于在个人化阶段加密注入其他密钥。该密钥也需要加密注入，且之后最好锁定为不可读（但可用于GenDig）。

配置步骤与坑点：

第一步：规划与计算配置数据。这是最易出错的一步。你需要手动或使用Microchip的配置工具（如atecc608_config_tool.py）生成一个128字节的配置数据块。你需要为Slot 0, Slot 1, Slot 15分别设置SlotConfig和KeyConfig。

• 对于Slot 0 (私钥):
  • KeyConfig:KeyType = P256 NIST ECC Private Key (0x03),Lockable = True。
  • SlotConfig:ReadKey = Always (0x3)（允许签名操作），WriteConfig = Encrypt (0xA)，WriteKey = 0xF（指向Slot 15，即用K_TRANS加密写入）。
• 对于Slot 1 (证书):
  • KeyConfig:KeyType = Data (0x0)。千万不能设成Private Key！
  • SlotConfig:ReadKey = Always (0x3),WriteConfig = Encrypt (0xA)（证书也建议加密写入防篡改），WriteKey = 0xF。
• 对于Slot 15 (传输密钥):
  • KeyConfig:KeyType = AES-128 Key (0x04)。
  • SlotConfig:ReadKey = Never (0x0)或一个你不知道的密钥ID（写入后使其不可读），WriteConfig = Encrypt (0xA)，WriteKey = 0xF（自举：第一次写入时，可能需要使用芯片的固定密钥或一个临时密钥）。

第二步：写入并锁定配置区。

1. 使用Write命令，将计算好的128字节配置数据写入配置区（Zone=0）。
2. 执行Lock Config Zone命令。这是一个不可逆操作！执行前务必校验配置数据100%正确。我曾在早期项目中使用脚本生成配置，但因字节序问题导致一个字段错误，锁定后整个芯片批次报废，损失惨重。务必在锁定前，执行一次Read命令，将读出的配置数据与源文件逐字节比对。

第三步：个人化（注入密钥和证书）。

1. 注入Slot 15 (K_TRANS)：这通常是最棘手的一步。在配置锁定后，你可能需要使用芯片的GenKey命令生成一个临时密钥对，或者利用出厂预置的Transport Key（如果存在）来加密注入K_TRANS。具体流程需参考Microchip的个性化指南，步骤繁琐但必须严格执行。
2. 注入Slot 0 (私钥)：现在可以用K_TRANS了。遵循Nonce->GenDig(KeyID=15) ->Write(加密)的流程，将私钥密文写入Slot 0。私钥明文千万不能存在于量产工具之外的不安全环境中，理想情况是在安全服务器内生成并直接加密后下发。
3. 注入Slot 1 (证书)：同样使用K_TRANS加密写入。因为其KeyType=Data，之后可以用明文Read命令读出。

第四步：锁定数据区。在所有必要Slot写入完成后，执行Lock Data Zone命令。这会锁定各Slot的SlotConfig.KeyConfig中关于“是否锁定”的位，并固定OTP区模式。锁定后，某些属性将无法更改。

常见坑点与调试技巧：

• 命令执行失败（返回错误码0x01 - 校验和错误）：这是最常见错误。首先检查I2C通信的时序和ACK。其次，确保命令包、参数、CRC16的计算完全正确。Microchip库中的atcab_系列函数会自动计算CRC，但如果自己实现协议，CRC计算是重灾区。
• Write命令返回“权限错误”：立即检查目标Slot的WriteConfig和WriteKey。你是否使用了正确的加密流程？GenDig的KeyID参数是否指向了正确的源密钥Slot？主机端计算的会话密钥是否与芯片内部一致？可以通过对比调试日志，检查Nonce输入和GenDig的输入参数是否完全一致。
• Read命令返回全0或错误数据：确认Zone和地址参数。对于数据区，地址是(slot_num << 3) | offset（具体看手册）。确认该Slot的ReadKey是否允许当前操作。如果是Private Key类型，直接Read永远返回0或错误。
• 使用逻辑分析仪抓取I2C波形：这是最强大的调试手段。将608B的通信波形抓下来，与数据手册中的命令格式逐字节对比，可以快速定位参数错误。同时，可以验证Nonce随机数是否每次不同，防止随机数源失效导致的安全风险。
• 充分利用芯片的Info命令：Info命令可以读取芯片的状态、锁定位信息。在调试时，先读一下配置区和数据区的锁状态，确认芯片处于你预期的生命周期阶段（未锁定、已锁定等）。

7. 安全设计哲学与最佳实践总结

回顾ATECC608B的EEPROM访问策略，其核心安全设计哲学可以概括为“默认拒绝，显式允许，权限最小化”。

• 默认拒绝：所有Slot在未经配置前，都是高度锁定的。你不能随意读写。
• 显式允许：你必须通过精心配置SlotConfig和KeyConfig，明确指定每个Slot在何种条件下、能被何种操作访问。
• 权限最小化：一个Slot只应拥有完成其功能所必需的最小权限。能加密写的绝不明文写；能通过认证读取的绝不开放明文读；不用的Slot全部禁用。

基于此，总结几条铁律般的实践：

1. 设计先行，反复验证：在动手写代码前，用表格或工具规划好每个Slot的用途、类型、访问策略。让同事或专家进行评审。
2. 隔离密钥，分权而治：使用不同的Slot存储不同用途的密钥（传输密钥、认证密钥、签名密钥）。避免一个密钥被用于多个不相关的场景。
3. 加密一切可能被攻击的通道：即使数据本身不敏感，加密写入也能防止攻击者通过篡改数据（如证书中的有效期）来破坏系统。
4. 锁定后测试：在锁定配置区和数据区后，立即执行一套完整的测试用例，验证所有设计好的访问路径（签名、加密写、认证读）都工作正常，而非法访问都被拒绝。
5. 管理好你的“根”：Slot 15（或其他作为传输密钥的Slot）是你的信任根。确保其注入过程绝对安全，并在注入后尽可能将其配置为不可读，仅用于派生会话密钥。

ATECC608B是一个强大的安全工具，但它的力量来自于复杂的配置。EEPROM存储区与访问策略是驾驭这股力量的第一道关卡。理解它，意味着你不仅是在配置一个存储器，而是在为你的产品构建一道坚固的硬件安全基石。