如何改良粤康码检查机制

粤康码检查机制的猜想和探讨

📎 为什么会关注到粤康码的设计问题？

晚上回家时在电梯上看到有人在 P 粤康码，不免觉得恐怖，如果有病毒携带者使用假码出入公共场所，关卡形如虚设，很容易造成疫情四处开花的局面。

现在粤康码的检查机制建立在群众利益一致的前提下，在流程上牺牲了一定的可靠性，以在安全和体验间达成某种平衡。 但最近福田区持续出现新的病例，说明有可能已经出现了为满足个人利益而欺骗程序的情况，破坏了这种平衡。

对于检查机制而言，如果希望得到更高的可靠性，可以如何优化呢？

📎 检查机制

📎 肉眼比对颜色法

现在人们是如何检查粤康码的？

我日常在进入小区、办公楼、商区、城中村时会被要求检查粤康码和测量体温。

检测员通常是物业保安或志愿者；进入以上场所时，由群众主动出示粤康码，由检测员肉眼检查码色并决定是否放行。其中码色根据风险程度分为绿、黄、红三种；在风险较高的区域还会要求出示核酸检测记录，分为四个等级 —— 24 小时、48 小时、72 小时或更长，核酸检测记录也采用了不同的颜色展示。

这种机制的优点是效率高，在群众可信度高的前提下，即节约了时间，也达成了筛查保护效果。 但本质上这是一种离线的校验形态，没有服务端参与最终的信息检查；单纯就流程设计而言，客户端是不可信任的，流程不应直接信任客户端提供的信息。

如果有意欺骗，通过一张过期或修改过的截图便能轻松绕开检查机制。 所以也很容易发现，现在的粤康码相比早期多了一个持续流动的背景动画效果；可以推测是针对这类低门槛欺骗的防御手段。

但这种防御无法杜绝其它类型的欺骗攻击，例如伪造假客户端等。 因此可以说这个机制是 建议在充分信任群众的前提下，在安全和体验间选择的一种平衡。

📎 联网验签法

粤康码的具体表现是一张二维码，从这一点可以看出，其实肉眼比对颜色法并非其最早的设计形态。扫描该二维码可以得到文本值:

{
  "label": "***",
  "cid": "440***************",
  "cidtype": "1000",
  "name": "***",
  "phone": "***********",
  "encode": "ub...6L1f",
  "c": "G",
  "t": 1646120011,
  "v": 2,
  "s": "wE3...=="
}

其中 encode 和 s 字段为 Base64 编码值，t 为时间戳，其余为个人信息。 从 Base64 编码值推测，encode 或 s 是数据签名，即为用于验签的字段。

验签也是最容易被想到的、能够实现安全合规的一种流程。

例如以下这样的联网验签法，能够杜绝客户端伪造信息的问题。

但回到现实中，还必须得考虑到 群众数量多、场所网络环境复杂 的实际情况。 一旦检测员设备联网出现问题，很容易导致现场检测堵塞，产生大面积事故。

因此这种联网验签法更适合用于安全级别高的场所，允许损失一定的用户体验，换取足够高的信息可信度。

📎 离线非对称解密法

有没有什么办法能够解决弱网问题呢？

如果检测员设备也拥有验签的能力，便能做到不依赖网络，验证客户端信息。 其次，下放给检测员的设备只应拥有 验签 的能力，不应拥有 生成签名 的能力。 否则一旦设备泄漏，整个机制就不再可靠。

这便是典型的 非对称加解密 能力。

在这个场景里，可以将私钥颁发给服务端，将公钥颁发给各个检测员设备。

云端在生成码值时使用 私钥加密；检测员通过「检查程序」扫描客户端二维码，检测程序使用 公钥解密，根据解密得到的时间戳判定信息是否在有效期内，再根据放行规则比对个人信息 (风险高低、核酸检测时间等)，最终给出决策结果。

这个机制可以 使检测员设备完成离线闭环，不依赖实时的网络环境，提供足够高的信息可信度。

如果要实际落地，进一步还应做到以下两点：

• 检测员设备的时钟应尽量接近云端时钟。因此设备不能完全无网，应有能力定期同步时钟 (例如每天一次)。
• 为避免因私钥泄漏事故导致机制失效，检测员设备还应支持手动或定期联网同步公钥，完成风险兜底。

除了粤康码，离线非对称解密法也适用于一些 IoT 场景。IoT 场景存在有着共性的 复杂网络环境问题，这种检查机制也与 TOTP 有相似之处 —— 都依赖系统时钟。

📎 总结

从体验和可信度两个维度，可以将三种方案分布：

加上条件做横向对比：

根据实际情况平衡安全和体验。在低风险阶段，使用现行的肉眼比对颜色法能够得到最好的体验；在中高风险阶段，则可以考虑使用离线非对称解密法确保信息安全。

📎 参考资料

• “粤康码”使用常见问题答疑（粤康码使用指引第五版）
• TOTP