当前位置：首页 > news >正文

MIFARE Ultralight AES安全芯片：低成本应用的AES-128与CMAC实战指南

news 2026/6/8 13:43:09

1. 项目概述与核心价值

如果你正在设计一个基于NFC的票务、门禁或者物流追踪系统，并且对成本敏感，但又不能完全牺牲安全性，那么MIFARE Ultralight AES这颗芯片很可能已经进入了你的备选清单。它不像它的“大哥”MIFARE DESFire那样拥有复杂的文件系统和极高的安全等级认证，但它在一个非常巧妙的平衡点上：在保持MIFARE Ultralight系列低成本、小尺寸、低功耗特性的同时，首次引入了基于AES-128的对称加密引擎和CMAC消息认证码机制。

这意味着什么？简单来说，过去的Ultralight芯片，其安全主要依赖于“锁字节”这种一次性可编程（OTP）的物理写保护，以及相对简单的通信协议。数据在传输过程中是明文的，容易被侦听和篡改。而MIFARE Ultralight AES的出现，填补了低成本应用中对通信过程安全和动态数据保护的需求空白。它允许你对存储器的特定区域进行读写权限控制，只有通过AES密钥认证后才能访问；它支持带安全认证的计数器，防止票务次数被恶意回滚；它甚至能对传输的每一条指令进行完整性校验（CMAC），确保命令没有被中途篡改。

我经手过不少从传统逻辑加密卡（如MIFARE Classic）或基础型Ultralight卡升级到带认证功能芯片的项目，最大的感触就是：安全特性的引入，绝不能是简单的功能堆砌，而是需要对芯片的安全模型有透彻的理解，并将其无缝地融入到你的系统工作流中。否则，轻则功能无法实现，重则留下严重的安全隐患。本文就将结合官方文档（如AN13452）和实际调试经验，为你拆解MIFARE Ultralight AES的核心安全特性、最佳实践配置以及那些数据手册里不会明说，但实际开发中一定会遇到的“坑”。

2. 芯片安全架构与核心功能解析

要玩转MIFARE Ultralight AES，不能只把它当成一个带加密功能的存储器。你需要理解它是一台具有特定状态机和安全策略的微型计算机。它的所有行为，都围绕着几个核心的安全状态和配置位展开。

2.1 内存组织与访问控制基石

MIFARE Ultralight AES的内存以页（Page）为单位组织，每页4字节。对于最常见的144字节用户内存版本，其布局是理解一切功能的基础。

用户内存与配置区：前40页（00h-27h）是用户可用的数据区，其中包含序列号（UID）、厂商数据、锁字节和OTP区。从28h开始，是锁字节2/3/4、配置页以及至关重要的两个AES-128密钥存储区。这个布局设计意味着，密钥本身也是存储在EEPROM中的，可以通过普通的WRITE命令写入。这带来了极大的灵活性，但也引入了第一个关键安全考量：密钥注入过程必须在安全环境中进行，因为芯片本身不支持加密形式注入密钥，密钥在个人化阶段是以明文形式写入的。

锁字节机制：这是芯片的硬件写保护机制。页02h的锁字节0和1，以及用户内存后的锁字节2/3/4，共同控制着从OTP区到用户内存区的写保护。每个锁位（Lx）对应一页，将其置1后，该页将变为只读。更重要的是块锁位（BLx）。一旦某个内存区域的块锁位被置1，该区域对应的锁位配置就被永久冻结，无法再更改。例如，锁字节0中的BL_OTP位锁定了OTP区的锁定位配置。

实操心得：锁字节配置策略很多开发者在个人化完成后，会记得去锁用户数据页，但常常忽略锁配置页和密钥锁定位。这是一个潜在风险点。官方强烈建议，在个人化配置固化后，立即设置LOCK_USR_CFG位来锁定配置页，防止攻击者通过篡改配置（如降低AUTH0值来扩大开放区域）来绕过保护。同时，如果应用场景允许，应在写入密钥后，立即设置LOCK_AES_KEY0和LOCK_AES_KEY1位，并最终设置BLOCK_LOCK_KEY位来冻结这些密钥锁定位。记住，这些锁位都是OTP的，设错了就没有回头路，所以务必在测试卡上反复验证流程后再对正式卡操作。

2.2 双密钥体系与芯片状态切换

芯片内置两个独立的AES-128密钥：Key0 (DataProtKey)和Key1 (UIDRetrKey)。这不是简单的备份，而是对应着芯片完全不同的两个安全状态。

Key0 (数据保护密钥)：这是主密钥。认证成功后，芯片进入AUTHENTICATED状态。在此状态下，可以访问受AUTH0和PROT配置所保护的内存区域，以及受保护的计数器2。
Key1 (UID检索密钥)：这是一个专用密钥。认证成功后，芯片进入TRACEABLE状态。这个状态的核心目的，是在启用了“随机ID（Random ID）”功能时，用于安全地检索出芯片的真实UID和NXP原厂签名。

为什么需要两个密钥？这体现了职责分离的安全思想。想象一个公共交通场景：Key0用于日常检票（验证票的有效性并扣款），它应该是分散化的（即每张卡的Key0由主密钥和卡UID计算得出，各不相同），这样即使破解一张卡，也无法威胁其他卡。而Key1用于在需要追溯票卡来源（如防伪稽查）时，获取卡的真实身份。Key1应该是非分散化的、统一的，并由更高级别的管理机构保管。如果Key1也被分散化了，而卡又处于Random ID模式，你将没有任何手段能恢复出它的真实UID，这张卡就彻底“匿名”了。

2.3 核心安全配置详解：AUTH0, PROT 与 AUTH_LIM

这三个配置共同定义了内存访问的安全策略。

AUTH0 (认证起始页)：这是一个7位的值（00h-7Fh）。它定义了从哪一页开始，访问需要受到认证保护。例如，AUTH0 = 12h，意味着从页18（十进制）开始的所有页面，其访问将受到限制。
PROT (保护模式)：此位决定是仅写保护，还是读写都保护。
- PROT = 0：写保护，读自由。页地址 >= AUTH0 的区域，写入需要认证，但读取不需要。这适用于存储公开信息但需要防篡改的场景，如产品生产信息。
- PROT = 1：读写均需认证。页地址 >= AUTH0 的区域，无论是读还是写，都必须先通过Key0认证。这适用于存储敏感数据的场景，如电子钱包余额、个人标识符。

配置示例与风险：假设你设置AUTH0=04h,PROT=1。那么页00h-03h（UID、锁字节、OTP）是全局可读的，而从页04h开始的所有用户数据，读写均需认证。这里有一个极易忽略的陷阱：AUTH0的最大值可设为7Fh，这远大于实际内存页地址（如27h）。如果你错误地将AUTH0设为一个大于实际最后页地址的值（例如AUTH0=40h），那么PROT=1的规则将永远不会被触发，因为没有任何页的地址“大于等于40h”，导致整个内存处于无保护状态。务必在配置后，用未认证的读命令尝试访问受保护区域，以验证配置是否生效。

AUTH_LIM (认证失败计数器)：这是一个至关重要的防暴力破解机制。它限制连续失败的认证尝试次数。一旦失败次数达到设定值（如100次），即使后续输入正确的密钥，认证也会永远失败。这直接对抗针对密钥的旁道攻击和暴力枚举。强烈建议在生产环境中启用此功能，并将阈值设置为一个合理的较低值（如64次）。每次成功的认证会将失败计数器减少16（10h），这为合法操作中的偶尔失误留出了余地。

3. AES-128认证流程与CMAC安全消息传递实战

理论配置完毕，接下来就是让芯片“活”起来的关键：认证与安全通信。这是整个安全链条中最核心的交互部分。

3.1 AES认证流程逐步拆解

认证是一个两步挑战-响应过程。我们以Key0认证为例，假设密钥是全零的默认密钥（仅用于示例，生产环境绝不可用）。

步骤1: 发起认证 (Authenticate Part 1)读写器发送命令1A 00（认证，使用Key0）。芯片会生成一个16字节的随机数RndB，用Key0加密后，连同状态码AFh一起返回给读写器。

你收到：AF 37 41 42 DA FB 0A B9 71 83 D8 46 EB 7E D3 79 E0
其中AF是状态，后面16字节是Enc(Key0, RndB)。

步骤2: 解密并准备响应 (Authenticate Part 2)

解密RndB：你用Key0解密收到的16字节，得到明文RndB。例如解密后得到RndB = 0D 2B BA 17 01 10 98 E9 86 4C 8A A5 19 2A F7 96。
生成RndA：读写器自己生成一个16字节的随机数RndA。例如RndA = 42 BD F7 E0 8E 11 0F 14 B6 D3 32 3D 14 F1 C2 B9。
构造RndB‘：将RndB循环左移一个字节。RndB' = 2B BA 17 01 10 98 E9 86 4C 8A A5 19 2A F7 96 0D。
加密挑战数据：将RndA和RndB‘拼接起来（共32字节），用Key0加密。得到Enc(Key0, RndA || RndB')。
发送第二部分：将加密后的数据附加在AFh后发送给芯片。命令为AF [32字节加密数据]。

步骤3: 验证与状态切换芯片用Key0解密你发送的数据，得到RndA和RndB‘。它会验证你发送的RndB‘是否等于它持有的RndB左移后的结果。同时，芯片会将自己的RndA也左移一个字节得到RndA‘，并用Key0加密后返回给你（状态码00h表示成功）。

你收到：00 A1 76 73 DC C2 0D 27 EE 80 58 4A CC FC 39 E0 A3
你用Key0解密后16字节，得到RndA' = BD F7 E0 8E 11 0F 14 B6 D3 32 3D 14 F1 C2 B9 42。
验证：检查RndA'是否等于你生成的RndA循环左移一个字节的结果。如果是，则认证成功，芯片进入AUTHENTICATED状态。

踩坑记录：随机数生成与会话密钥推导很多自研读卡器程序在认证失败时，问题往往出在随机数生成或会话密钥计算上。务必确保：
随机数质量：RndA必须是密码学安全的真随机数，不能使用简单的伪随机序列或固定值。许多MCU的硬件随机数发生器（RNG）在上电初期熵不足，需要等待或混合其他熵源。
字节顺序：在计算会话向量（SV）用于生成CMAC会话密钥时，文档中提到的RndA[15..14]等表示法是指字节数组的切片，且遵循小端序（LSB first）约定。计算错误将导致后续所有CMAC校验失败。建议将官方示例中的每一步数据都打印出来，与自己的计算结果逐字节比对。

3.2 CMAC安全消息传递：为通信加上“防伪码”

认证建立了安全通道，但之后的读写操作呢？如果没有完整性保护，攻击者仍然可以截获、篡改或重放指令。CMAC就是为了解决这个问题。

原理：认证成功后，芯片和读写器会基于刚才交换的随机数（RndA, RndB）推导出一个临时的会话密钥（Session Key）。此后，双方用这个会话密钥为每一条指令和响应计算一个“消息认证码”（CMAC），附在数据后面。接收方用同样的密钥和算法计算CMAC，如果匹配，说明消息完整且来自合法的通信方，有效防止了篡改和重放。

启用：通过设置配置页中的SEC_MSG_EN位来启用CMAC安全消息模式。一旦启用，芯片将只接受附带有效CMAC的命令（除AUTHENTICATE本身）。

核心机制：

命令计数器（CmdCtr）：一个2字节的计数器，认证成功后从0000h开始。每成功处理一条命令（及响应）后递增。它被纳入每条命令和响应的CMAC计算中，是防重放攻击的关键。即使攻击者截获了一条有效的带CMAC的命令，因为计数器值已经变化，重放该命令会被识别为无效。
CMAC计算范围：对于命令，CMAC计算数据包括CmdCtr || Command Code || Arguments；对于响应，则是CmdCtr || Response Data。CRC校验字节不参与CMAC计算，但发送时仍需附加在CMAC之后。
截断（Truncation）：MIFARE Ultralight AES采用一种特殊的“MFP截断法”，不是取CMAC值的前8字节，而是取所有偶数位置的字节（从0开始计数）。例如，一个16字节的CMACC0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF，截断后为C0 C2 C4 C6 C8 CA CC CE。

实战示例：带CMAC的读操作假设会话密钥已生成，命令计数器为0002h。

构造输入数据：要发送读页04h的命令，命令码是30h，参数是04h。输入数据为：0200 30 04（CmdCtr LSB在前，然后是命令和参数）。
计算CMAC：使用会话密钥对上述输入数据计算完整的16字节CMAC。
截断CMAC：使用MFP截断法得到8字节的CMACT。
发送命令：发送30 04 [8字节CMACT]。
验证响应：芯片返回数据后，会附带8字节的CMACT。你需要用新的命令计数器值（此时应为0003h）和收到的数据，重新计算并截断CMAC，与收到的CMACT比对。

注意事项：CMAC模式下的“静默”响应在普通模式下，写入成功通常返回一个0A（ACK）。在CMAC安全消息模式下，对于某些预期只返回ACK的命令（如成功的WRITE），芯片的响应会变为仅返回该命令对应的CMACT，而不再有0A状态码。你的读卡器程序必须适应这种变化，将接收到的8字节数据直接视为CMACT进行验证，而不是将其解析为状态码+数据。

4. 安全计数器与OTP的防撕毁应用实践

对于票务、次卡等应用，一个可靠且防篡改的计数器是核心。MIFARE Ultralight AES提供了3个24位单向计数器，其中计数器2（CNT2）可以通过AES认证进行保护。

4.1 受保护计数器的使用流程

使用受AES保护的计数器2是最佳实践。流程如下：

启用保护：在配置页中，将CNT_INC_EN和CNT_RD_EN位设为0。这意味着对计数器2的“读”和“增”操作都需要先通过Key0认证。
认证：执行前述的AES认证流程，使芯片进入AUTHENTICATED状态。
读当前值：发送READ_CNT命令读取计数器2的当前值。建议在安全消息模式下进行，以验证响应完整性。
递增：发送INCR_CNT命令，指定递增的值（1-FFFFFFh）。值为0是合法的，但实际不会增加。
处理响应：
- 成功：芯片返回操作成功的响应（在安全消息模式下是CMACT）。
- NAK5或NAK7：这通常意味着发生了撕毁事件。在递增操作完成前，卡片离开了读写器场区。此时计数器的值可能处于不确定状态（可能已增，可能未增）。标准处理流程是回到步骤3，重新读取并尝试递增。
- NAK6：计数器已损坏或不可用。对于票务应用，这意味着此票卡应被永久禁用（例如，通过设置OTP中的某个位或写入特定标志到受保护内存）。
验证（可选但推荐）：在非安全消息模式下，强烈建议在递增操作后再次读取计数器，确认值已正确更新。在安全消息模式下，如果收到了有效的CMACT响应，则可以省去此验证步骤，因为CMAC已经保证了命令被完整执行。

4.2 将OTP区域用作简易计数器

除了专用计数器，页03h的32位OTP区域也可被巧妙地用作计数器。所有位出厂为0，只能一次性烧写为1。你可以将其视为一个最多32次的递减计数器。

推荐实现方法（防误操作）：不是从全0开始写1，而是从某个特定值开始。例如，如果你需要提供4次服务，可以在个人化时将OTP页初始化为0x0F FF FF FF（二进制：00001111...）。每次使用，将最高位的某个0烧写成1。第一次使用后变为0x1F FF FF FF，第二次0x3F FF FF FF，第三次0x7F FF FF FF，第四次0xFF FF FF FF。这样，通过检查从最高位开始连续1的个数，就能知道剩余次数。这种方法比从低位开始写更可靠，因为高位比特在物理布局上可能更稳定，且逻辑判断简单。

关键优势：OTP操作本身是防撕毁的。即使在烧写过程中发生撕毁，该比特要么保持原值（0），要么变为目标值（1），绝不会处于中间状态。这保证了计数器状态的确定性。

4.3 防欺诈的计数器初始化策略

即使有了AES保护，对于计数器1和3（如果不使用），或者在某些极端假设下，仍需考虑防数据篡改。这里提供两个系统级思路：

内存存储MAC：在用户内存中，除了存储计数器值，再存储一个基于“计数器值 || UID || 其他固定数据”计算出的MAC（消息认证码）。这个MAC在后台系统用安全密钥生成，写入卡片。每次读卡时，终端或后台重新计算MAC并与存储的比对，不一致则说明数据被篡改。这相当于在卡片层面增加了一层软件校验。
后端关联校验：在后台数据库中，记录每张卡（UID）的最后一次合法计数器值。当终端读到一张卡时，不仅校验卡片内的逻辑（如CMAC），还将（UID，当前计数器值）上报后台。后台检查该计数器值是否合理（例如，是否大于上次记录的值，增长幅度是否在合理时间窗口内）。发现异常则拉黑该UID。这是一种基于行为分析的防御。

5. 芯片真伪鉴别与数字签名管理

在对抗克隆卡和假冒芯片的斗争中，MIFARE Ultralight AES提供了基于椭圆曲线数字签名（ECDSA）的原厂鉴别功能。

5.1 NXP原厂签名及其验证

每颗芯片在出厂时，都使用NXP的私钥，对其自身的UID计算了一个48字节的ECDSA签名，并存储在芯片的签名区域。你可以通过READ_SIG命令读取它。

验证流程：

从芯片读取UID和48字节签名。
使用NXP公开的ECC公钥（基于secp192r1曲线）和标准ECDSA验证算法，对“UID”和“签名”进行验证。
如果验证通过，则证明该芯片是由NXP生产的正品。

重要限制：这个机制主要用于批量真伪鉴别，防止大量非NXP生产的兼容芯片流入你的系统。它不能防止针对单张卡的克隆。因为攻击者可以从一张正品卡上完整地复制UID和签名，然后烧录到克隆芯片中。因此，原厂签名验证必须与UID重复检测机制结合使用。后台系统应记录每次交易使用的UID，如果发现同一个UID在不可能的时间或地点同时出现，则很可能遭遇了克隆卡。

5.2 自定义签名与锁定

芯片允许你用自定义签名覆盖NXP的原厂签名。这通过WRITE_SIG命令实现，需要逐页（共12页）写入48字节的新签名数据。签名区域有三种状态，由LOCK_SIG命令控制：

解锁态：可以写入新签名。
锁定态：不能写入，但可以通过LOCK_SIG命令解锁。
永久锁定态：永远不能写入，也无法解锁。

应用场景：你可以在个人化阶段，使用自己系统的一对ECC密钥，为每张卡生成一个基于其UID的系统专属签名，并覆盖掉原厂签名。这样，你的读写器在验卡时，就用你自己系统的公钥来验证这个签名。这不仅能验证芯片真伪，还能验证这张卡是否是“你系统发行的”合法卡片，实现了双重鉴别。

操作警告：签名锁定流程修改签名是一个高风险操作。务必遵循以下顺序：
LOCK_SIG 00h：确保签名区处于解锁状态。
循环执行WRITE_SIG，写入12页新签名数据。
立即执行LOCK_SIG 02h：将签名区永久锁定。千万不要在写入后停留在锁定态（LOCK_SIG 01h）。因为锁定态是可逆的，如果攻击者获取了你的LOCK_SIG 00h命令，他可以解锁签名区并篡改你的系统签名。永久锁定是唯一安全的选择。同样，在启用CMAC安全消息后，WRITE_SIG和LOCK_SIG命令也必须附带有效的CMAC。