软件：采用GNU Radio + Python
技术背景： 本技术主要遵从ISO/IEC 14443 标准，里面定义了物理层特性，调制和编码特性等。在这里我们主要聚焦Type A的通信， 这种通信载波频率fc=13.56MHz. 读卡设备与卡进行通信采用的是调制深度为100% ASK调制方式。信道编码方式采用修改版的米勒编码。 从读卡器到卡之间采用了负载调整方式，采用子载波频率fs= fc/16 = 847.5kHz, 曼彻斯特编码以106kb/s的速率发送数据。
读卡器向卡发送数据： 读卡器发送数据时由于采用100% ASK调制方式，所以当传输数字0时，就不发送任何信号。然后采用修改版的米勒编码来保证不存在超过3us的静默期（不传递信号期间）。并且每个Bit表示为长度为tb = 128/fc = 9.44us的信号。 例子如下图所示：（1）bit 1被编码为tb/2 = 4.72us的有信号期， 后面跟3us的无信号静默期，然后后面再跟一个tb/2-3 = 1.72us的有信号期。（2）如果是Bit 0后面还有一个bit 0， 也就是两个连续0，则编码为3us的无信号静默期，后面紧跟tb-3 =6.44us的有信号期。如下图连续两个0的表示。（3）如果是编码bit 1,0 则编码为tb=9.44us的有信号期。信息传输的起始位和结束位都要插入bit 0.
image.png (13.94 KB, 下载次数: 1)
下载附件
2025-3-24 12:48 上传
读卡器端实际采集到波形大致如下式样：
image.png (169.21 KB, 下载次数: 1)
下载附件
2025-3-24 12:48 上传
卡向读卡器发送数据：
对于卡而言采用的是读卡器电磁波的能量来工作的，故而电力相对是有限的。所以卡是通过修改字节的负载值来引起读卡器产生电压下降来传递信息的，也称为负载调制。对于负载进行开关来产生相关的子载波传输数据，子载波的频率fs = fc/16 = 847.5kHz.传输的bit采用曼彻斯特编码方式. bit时长占用 tb=9.44us,也就是约等于子载波周期的8倍。 如下图所示:(1) Bit1 表示为将第一个一半的Bit时间tb/2=4.72us进行负载调制，如下图所示可以看到负载调制后的波形一半幅度大一半幅度小。(2) Bit0 表示为将第2个一半的Bit时间tb/2=4.72us进行负载调制.(3) 逻辑1代表开始传输，负载调制波形无波形输出时代表停止传输。
image.png (55.33 KB, 下载次数: 1)
下载附件
2025-3-24 12:49 上传
协议简述：
ISO/IEC 14443A 给出了通用性的规范。如下几点需要注意:(1) bit传输时是从LSB到MSB排列，并且跟上一个奇校验位. 也就是说如果传输数据中的是偶数个的bit 1，后面要紧跟一个bit1. 如果是传输的数据中有奇数个bit1，则最后要紧跟一个Bit 0 . 例如 0x3F 就被编码为1111 1100 1.(2) 读卡器设备在处于等待读卡时会重复发送REQ(0x26)或者WUPA(0x52)指令， 其中REQA或者WUPA中的A代表是Type A的协议。 两个命令的不同之处是WUPA指令是可以唤醒之前被发送HALT指令的卡的。与其他指令不同这两个指令都采用了短帧，有用信息只有7个bit，而且与其他指令不同的是，这两个指令不包含前面所述的奇校验位. 例如REQ(0x26) 指令，编码为 0110 010,首位各自添加1个0作为起始位和停止位。最终数据为 0 0110 010 0。(3) 对于较长的指令，为了探测错误，引入了CRC校验。CRC校验计算时是排除了起始位和终止位的，采用的多项式是
image.png (17.67 KB, 下载次数: 1)
下载附件
2025-3-24 12:49 上传
CRC占用2个字节。 比如HALT（0x50 0x00），计算的CRC字节是 0x57 0xCD。
Tag A 的技术规范 如下表所示：此tag有7byte的UID SN[0-6], 包括 2 check bytes BCC[0-1]. SN0是厂商ID (0x04是NXP), check byte按照如下两个公式定义:
image.png (86.88 KB, 下载次数: 1)
下载附件
2025-3-24 12:50 上传
image.png (89.39 KB, 下载次数: 1)
下载附件
2025-3-24 12:50 上传
Lock bytes 能用于将特定的page变成read only模式。 OTP(One Time Pad) byte 可以被设置为1，但是一旦设置为1之后就不能再设置为0 了。
image.png (44.57 KB, 下载次数: 1)
下载附件
2025-3-24 12:50 上传
下表给出了此tagA可用的命令格式。 READ和WRITE命令可以操作的地址范围0x00~0x0F 并且包含CRC字节 C[0-1]。D[0-15]代表数据data字节.
image.png (110.37 KB, 下载次数: 0)
下载附件
2025-3-24 12:50 上传
对应的FSM状态迁移图如下所示:
image.png (51.7 KB, 下载次数: 0)
下载附件
2025-3-24 12:51 上传
TagB 加密技术解析：
tagB采用了一种称为 CRYPTO1的加密技术。这是一种3步加密协议。 每一个sector有6字节的Key A和6个字节的Key B， 出厂设置为[0xFF 0xFF 0xFF 0xFF 0xFF 0xFF ]，随后可以被用户更改。每次鉴权开始时读卡器会从两个key中选择一个，并且只允许访问特定的sector.每个sector 有4个block, 每个block有16个字节。每个sector还包含一个trailer,这个trailer包含了2个key和一些访问权限控制Bit来控制有怎样的访问那4个sector. 读卡器首先向卡表明要采用哪个key和想使用哪些地址。 如下图所示，3步方案包含了一个4 byte的challenge从卡到读卡器，然后8 byte Challenge Response从读卡器发送到卡（Token AB）. 再从卡发送4字节的token BA 给读卡器。
image.png (45.92 KB, 下载次数: 0)
下载附件
2025-3-24 12:52 上传
从Token RB 开始，后面的通信数据都是加密的。哪怕是后面的Token AB和 Token BA都是加密的。这样就会导致一个总所周知的缺陷称为nested Authentication (嵌套认证).在详细解释加密算法之前，先简单总结一下这个CRYPTO1加密方法。这个加密方法是一个流式加密，其中包含了一个48 bit的LFSR 和一个非线性滤波函数。这个加密结合了卡的UID和利用一个16-bit的LFSR生成的random nonce RB。 然而，两次challenge response 只是依赖于卡的nonce (不依赖读卡器的nonce 或者UID), 并且两次都采用相同的16-bit LFSR来生成nonce.另外一点，奇校验位也是加密的（这和ISO 14443协议是不兼容的）, 而且用于加密奇校验位的密钥流也用于加密原始的明文数据。这个缺陷结合nested authentication （可能会导致token RB也被加密）就导致泄露出的数据可以用于反向猜测和推测出nonce的，从而反向破解密钥。下面详细介绍此加密技术：如下图所示，这个卡只用一次ANTICOLLISION 和SELECT命令，但是可以包含多次的3步鉴权机制.
image.png (49.9 KB, 下载次数: 0)
下载附件
2025-3-24 12:52 上传
如下表所示，此卡没有UID，而是在block 0采用了4个byte的NUID。每个sector都有一个叫做trailer的区域，包含了2个key和access Bits.
image.png (44.51 KB, 下载次数: 0)
下载附件
2025-3-24 12:53 上传
而access Bits 的结构如下表所示:其中CXy是第X个access bit, 对应与第y个block.
image.png (48.82 KB, 下载次数: 0)
下载附件
2025-3-24 12:53 上传
这些access bit 可以根据当前的block是不是trailer block而含义不同。如下表所示:
image.png (100.67 KB, 下载次数: 0)
下载附件
2025-3-24 12:53 上传
而NID[0-3]表示了NUID，并且
image.png (30.96 KB, 下载次数: 0)
下载附件
2025-3-24 12:54 上传
可用地址范围0x00~0x3F。 C[0-1]表示CRC, D[0-15]为data 字节。下表给出了此卡支持的命令
image.png (143.68 KB, 下载次数: 0)
下载附件
2025-3-24 12:54 上传
CRYPTO1 算法分析:
定义明文nonce RB表示为nT,token AB 表示为{nR},{aR}, token BA 表示为{aT}.将 k表示为密钥Key, u代表卡的NUID，对于任意x, xi代表第i个bit. 此加密算法采用48 bit的LFSR， 初始值为key(长度也是48）. 将 alpha(i)=ai,ai+1,....ai+47，代表了时间i对应的LFSR的内部状态，然后我们得到如下算法公式:
image.png (62.49 KB, 下载次数: 0)
下载附件
2025-3-24 12:54 上传
L是LFSR的反馈函数:
image.png (67.79 KB, 下载次数: 0)
下载附件
2025-3-24 12:55 上传
输出被一个滤波函数进行加密，滤波函数定义如下:
image.png (56.88 KB, 下载次数: 0)
下载附件
2025-3-24 12:55 上传
image.png (27.58 KB, 下载次数: 0)
下载附件
2025-3-24 12:55 上传
这两个函数的结构总结如下图： 密钥流中bi被定义为bi = f(ai ...a47+i), 加密第i个常规bit(去除了start, end ,parity bits) 被定义为与bi的异或操作。
image.png (116.54 KB, 下载次数: 0)
下载附件
2025-3-24 12:56 上传
image.png (58.16 KB, 下载次数: 0)
下载附件
2025-3-24 12:56 上传
需要注意的是前32个bit并没有在首次鉴权时使用，但是在后续的鉴权步骤中都采用了这些Bit.当卡的nonce被加密时，
image.png (45.55 KB, 下载次数: 0)
下载附件
2025-3-24 12:56 上传
image.png (29.94 KB, 下载次数: 0)
下载附件
2025-3-24 12:56 上传
实际验证：采用USRB N210 加LFTX, LFRX，在 13.56 MHz 上进行嗅探或者模拟伪造读卡过程。采用推荐的电路图制作建议的线圈接收/发射天线。
image.png (249.33 KB, 下载次数: 0)
下载附件
2025-3-24 12:57 上传
如下图所示:比如一个示例采集波形和对应的Bit含义，红色代表了起始位和终止位。
image.png (100.44 KB, 下载次数: 0)
下载附件
2025-3-24 12:57 上传
将录制到的数据存为wav格式的解调数据，采用分析软件进行分析，比如如下所示可以看到相互交互的数据可以被正确的识别出来，也就是采用SDR可以正常嗅探整个通信过程。 如下是tagA的，没有加密和鉴权过程。
image.png (55.02 KB, 下载次数: 0)
下载附件
2025-3-24 12:58 上传
如下是tagB的，有鉴权过程，然后后面的通信都是加密的。
image.png (59.96 KB, 下载次数: 0)
下载附件
2025-3-24 12:58 上传
总结一下，两个卡对应的实例日志如下： 卡tag A (无加密时）的示例日志：
[table][tr][td]方向
