3. 静态数据认证（SDA）：SDA原理、SDA流程、SDA的局限性、SDA在脱机交易中的角色

好，我们开始聊静态数据认证。SDA，全称 Static Data Authentication。

说白了，它是EMV脱机交易里最基础、也是最古老的一种卡片认证方式。我最早接触EMV规范时，第一个啃的就是SDA。当时觉得这东西挺简单，后来踩了坑才发现，简单的东西往往藏着最深的坑。

3.1 SDA原理：到底在认证什么？

SDA的核心思想，就是验证卡片上的关键数据有没有被篡改。注意，它只验证数据是否完整，不验证卡片是不是真的——这是它最大的特点，也是最大的局限。

具体怎么做的呢？

发卡行在个人化卡片时，会挑一批关键数据，比如卡号、有效期、发卡行公钥证书、CA公钥索引等等。然后用发卡行的私钥对这些数据算一个签名。这个签名就存在卡片里。

交易时，终端把卡片里的数据和签名一起读出来。终端用CA公钥去验这个签名。签名能对上，说明数据没被人动过手脚。

嗯，这里要注意：SDA验证的是“数据没变”，而不是“卡片是真的”。

我见过不少刚入行的朋友把这两件事搞混。你想想看，如果一张卡被克隆了，克隆卡里存的数据和原卡一模一样，那SDA照样能通过。因为它只认数据，不认卡。

3.2 SDA流程：一步一步来

SDA的流程其实不复杂。我习惯把它拆成三步：

1. 终端发命令读数据：终端通过GET DATA或READ RECORD命令，把卡片里的签名数据和相关记录读出来。
2. 终端重建认证数据：终端把读到的数据按规范拼起来，形成一个待验证的数据块。
3. 终端验签：终端用CA公钥去验这个数据块的签名。验签通过，SDA成功；验签失败，交易直接拒绝。

流程看起来简单，但实际项目中容易出问题的地方不少。

我举个例子。有一次我在做终端测试，发现某张卡总是SDA失败。查了半天，原来是终端在读数据时，漏读了一个记录。那个记录里存的是发卡行公钥证书的一部分。少了它，签名自然验不过。

所以，我个人习惯在实现SDA时，先列一个清单，把需要读的数据项一个一个写清楚。然后对照规范，确保每项都读到了。

3.3 SDA的局限性：为什么它不够用？

SDA的局限性，说白了就一句话：它只能防数据篡改，防不了卡克隆。

为什么会这样？

因为SDA验证的数据是静态的。卡片每次交易返回的数据都一样。攻击者只要拿到一张卡的全部数据，就能复制出一张一模一样的卡。克隆卡做SDA时，终端验签照样能过。

我整理了一下SDA的主要局限：

局限	说明
无法防克隆	签名数据是静态的，克隆卡可以完全复制
无法防重放	每次交易数据相同，攻击者可截获并重放
无卡活体验证	无法确认卡片是否真实存在，只能验证数据
依赖CA公钥安全	如果CA私钥泄露，整个体系就崩了

嗯，这里要特别说一下CA公钥的问题。SDA的安全性完全建立在CA私钥不泄露的前提下。一旦CA私钥泄露，攻击者就能伪造任意卡片的签名。这在现实中发生过，虽然不多，但一旦发生就是灾难性的。

3.4 SDA在脱机交易中的角色：它还有存在的必要吗？

你可能会问，SDA这么弱，为什么还要学它？

答案是：SDA虽然弱，但它便宜、简单、兼容性好。

在EMV的早期阶段，很多卡片芯片性能很差，跑不动复杂的非对称加密运算。SDA只需要终端做验签，卡片只负责存数据，对卡片性能要求极低。所以SDA在低端卡、老卡上仍然广泛存在。

另外，SDA是EMV脱机交易认证体系的基础。你理解了SDA，再学DDA和CDA就轻松多了。因为DDA和CDA都是在SDA的基础上加了动态元素。

我个人的看法是：SDA就像EMV认证体系里的“入门课”。它不完美，但你必须懂它。不懂SDA，你很难理解为什么后来要搞DDA，为什么又要搞CDA。

下面这张图展示了SDA在脱机交易认证体系中的位置：

从这张图可以看得很清楚：SDA是认证体系的起点。它虽然简单，但为后续更安全的认证方式打下了基础。

在实际项目中，我建议你根据卡片能力和安全需求来选择认证方式。如果卡片性能允许，优先用CDA。如果卡片太老，只能用SDA，那就要在交易限额、风控策略上做补偿。

好了，SDA的内容就聊到这里。记住它的核心：静态、简单、有局限。下一节我们聊DDA，那才是真正能防克隆的东西。