先说结论：这起案子里，攻击者没有攻破任何人脸比对算法。他们攻破的是采集链路。
杭州市中级人民法院今年公布的一起案件，9月4日当庭一审宣判：两名被告用网络收集的他人照片，通过AI生成点头、摇头、眨眼等动态视频，再篡改相机数据，突破某购物平台的人脸核验，非法登录近30个账号，盗取收货地址、购物车等信息并转卖，同时有偿提供虚假实名认证，非法牟利5857元。判决为公开道歉加5857元公益损害赔偿金。
对做客户端和风控的同行来说，这个案子的价值不在“AI换脸”这四个字，而在它把一条完整的攻击链摆到了台面上。下面按攻击面拆，再按防御层给方案。
一、攻击链拆解：四个环节，每一环都不需要多高深的技术
环节1 素材获取。手机号、头像照片、身份信息。社交平台公开头像、历史泄露数据、钓鱼获取，成本极低。单张清晰正脸照就够，不需要多角度。
环节2 人脸重建与动作驱动。通过深度学习算法识别人脸要素（关键点、纹理、姿态），训练建模，生成模拟真人的动态视频。案涉技术可以生成向左看、向右看、张张嘴、眨眨眼等核验环节的常用指定动作。
这一环的技术门槛这两年塌得很快：单图驱动的 talking-head 类模型 + 关键点重演（reenactment），已经能做到实时或近实时出片；商用开源工具都能拿到。
环节3 采集端替换（虚拟相机）。在手机中植入虚拟相机应用替换本地相机。平台调起摄像头时，Camera 预览回调拿到的不是 sensor 数据，而是合成视频的帧。Android 侧常见做法是 hook Camera1 的 preview callback / Camera2 的 Surface 输出，或借助 Xposed/Frida 一类框架、双开与虚拟化容器；iOS 侧对应 hook AVCaptureSession 的输出。
环节4 认证态伪造。把合成视频接到虚拟相机上，按平台要求的动作序列播放，活体检测通过，人脸比对自然通过——因为比对的那张脸，本来就是受害者的脸。
这条链的要害在环节3。前两环解决“有脸”，第四环是结果，只有第三环是把假数据喂进真系统的那个接口。所以防御的重心也在这里。
二、为什么动作挑战会失效：一个概念上的错位
动作挑战（challenge-response）的设计前提是：只有活人能按指令做出不可预演的动作。
这个前提在静态照片攻击时代成立。但它有两个隐含假设：一是动作空间足够大、不可枚举；二是攻击者无法实时响应随机指令。
现实里：动作空间是被产品经理固定在界面提示里的（眨眼、张嘴、摇头、左转右转），等于把答案提前公开了；而合成视频是预生成的，根本不需要实时响应——攻击者只要按平台提示的动作顺序准备一段视频即可。
所以动作挑战本质上是一种“行为证明”，不是“身份证明”，更不是“活体证明”。它证明的是“镜头前有个东西按指令动了”，而不是“这个动作来自一个具有生理特征的人”。
再叠加虚拟相机，连“图像来自真实光学系统”这个最后的物理锚点也没了。传统方案在这两层上同时失守，通过率自然高。
三、五层防御设计（从采集端到决策端）
L1 采集端可信：先确认“帧从哪来”。
这一层目标不是识别假脸，是识别假设备/假管线。可做的事：校验 Camera 调用链是否被 hook（检测常见 hook 框架痕迹、检查进程加载的可疑 so/framework）；读取 CameraCharacteristics 做合理性检查——真实模组的 LENS_FACING、SENSOR_INFO_PHYSICAL_SIZE、焦距范围、支持的 AE/AF 模式是一组互相约束的值，虚拟相机常返回默认值或自相矛盾的组合；检测虚拟摄像头/多开容器特征（包名可改，但 SELinux 上下文、设备节点、MediaProjection 使用痕迹难完全抹掉）。
更硬的做法是设备证明：Android 用 KeyStore 的硬件支持密钥做 attestation，iOS 用 App Attest / DeviceCheck。把“这台设备是不是真实未篡改设备”变成可验证的密码学断言，比特征匹配稳得多。
L2 注入检测：确认“帧是不是被外部灌进来的”。
视频流注入的痕迹往往在时序上。可交叉的信号包括：帧时间戳与系统单调时钟的一致性、帧间隔抖动分布（真实 sensor 有固定曝光节奏和丢帧模式，注入流通常过于规整）；帧与 IMU 的相关性——手持设备拍脸时，画面位移与加速度计/陀螺仪读数存在物理相关性，合成视频与设备运动无关，这个相关性会塌；屏幕重放还会带摩尔纹、镜面反射、色域/白点偏差、压缩伪影分布异常。
L3 生理信号：确认“这张脸是不是活的”。
rPPG（远程光电容积脉搏波）从面部肤色随血流的周期性变化里提心率，真人一般在 0.7-4Hz 有稳定峰；合成视频没有真实的血流信号。再叠加微表情、瞳孔对光反射、眼动扫视模式。硬件允许的话，3D 结构光/ToF 给深度，红外给材质反射特性——这两类信号目前最难伪造，因为需要物理对抗。
L4 决策层：不要用一个信号做决定。
把所有信号汇成一个风险评分，按场景设阈值。高风险动作（改绑手机、改密码、大额支付、首次设备登录）必须触发独立于人脸的第二因子——短信、邮箱、已信任设备、人工复核。这就是《人脸识别技术应用安全管理办法》第十条讲的“不得作为唯一验证方式”在工程上的落地形态。
L5 运营层：把对抗变成常态。
用高逼真度 AI 攻击样本做红队测试；建立攻击样本库并持续更新；灰度发布新模型并监控通过率异常（通过率突然上升往往意味着防线被绕过）；把“核验方式有效性”纳入版本发布检查项——系统上线时通过测试，不代表可以长期沿用。
四、合规侧怎么把这套东西写成材料
技术做完了，材料不齐，一样过不了检查。《人脸识别技术应用安全管理办法》第九条要求事前开展个人信息保护影响评估，四项内容可以一一映射到工程文档上：
第一项，处理目的、方式是否合法正当必要。对应：为什么要用人脸、有没有更小影响的方式、采集点位数与覆盖人群、是否满足第十条的非人脸替代通道。
第二项，对个人权益的影响及降险措施是否有效。对应：本方案的 L1-L4 各层措施清单，以及每一层的有效性证据（测试报告、红队结论），不是“我们做了加密”这种表述。
第三项，发生泄露、篡改、丢失、毁损或者被非法获取、出售、使用的风险及可能造成的危害。对应：威胁建模。这次的案件就是现成的风险场景，写“不存在此类风险”的评估报告，等于自己给自己挖坑。
第四项，保护措施是否合法有效并与风险程度相适应。对应：风险等级与措施强度的对应表，以及残余风险说明。
报告和处理情况记录至少保存3年；目的方式变化或发生重大安全事件，要重新评估。这一条对应到工程上，就是评估不能是一次性文档，要绑定版本和变更流程。
日志该留什么，建议覆盖这条链：认证请求（时间、场景、账号、设备指纹）、活体检测结果与各子信号置信度、决策结果与命中规则、是否触发第二因子、人工复核记录。这份日志同时服务三件事：安全事件溯源、第五十七条的泄露通知、以及第五十四条合规审计的取证。
审计怎么验，也基本是围绕这些材料：评估报告是否覆盖全部人脸场景、是否在变更后重做、日志是否完整可关联、措施是否有有效性证据。TC260-PG-20255A 的审计要点里，“是否依法开展个人信息保护影响评估”是必查项，进场第一批调的就是这份报告。
规模上还有两条硬线：人脸信息存储数量达到10万人之日起30个工作日内，向所在地省级以上网信部门备案，备案材料第五项就是影响评估报告；个人信息保护合规审计按规模分档，超过1000万人每两年至少一次，超过100万不超过1000万人每三年或四年至少一次，不超过100万人宜每五年至少一次。
五、一份可执行的自查清单
采集端——虚拟相机检测有没有上线；Camera 参数合理性校验有没有做；设备证明（KeyStore attestation / App Attest）有没有接。
链路——帧时间戳与系统时钟一致性校验有没有；帧与 IMU 相关性分析有没有；屏幕重放检测有没有。
活体——是否只依赖动作挑战；有没有生理信号维度；有没有深度或红外通道。
决策——高风险动作是否强制第二因子；风险评分是否多信号融合；阈值是否按场景区分。
运营——红队测试频率是多少；攻击样本库谁维护；通过率异常有没有告警。
合规——影响评估报告是否覆盖全部场景；变更后是否重做；是否满三年仍在有效期思路内；存储量是否触及10万人备案线；日志能否支撑审计取证。
架构——人脸信息是否按要求尽量本地存储、不通过互联网对外传输；传输与存储是否加密；权限是否最小化并可审计；系统是否落实了入侵检测和防御措施（第十四条明确列了这一项）。
六、最后一点判断
这起案子判赔5857元，金额不大。但它确认了一个技术事实：以传统活体检测为核心的人脸识别系统，已经挡不住一段合成视频加一个虚拟相机。
对工程团队来说，这意味着安全模型要更新——不能再用“图像来自摄像头”作为信任根，得往上找更硬的锚：设备证明、生理信号、多信号交叉、独立第二因子。
对合规团队来说，这意味着影响评估里的那句“风险可控”，必须有证据支撑。评估报告写得再漂亮，也挡不住一段视频；能挡住视频的，是采集端的那几行校验。
北京品阁科技有限公司——数据安全合规评估服务商
主营业务：个人信息保护影响评估、个人信息保护合规审计、人脸识别技术应用备案、数据出境安全评估
服务范围：全国（重点：北京、上海、江苏、福建、广东、湖南、陕西）
文中防御分层与自查清单如需按贵司系统架构细化，可在评论区说明业务形态与用户规模。
