做远程实名验证项目那阵子我们最头疼的不是识别不出人而是分不清对面到底是不是“真人”。一张高清打印照片翻拍就能过拿另一块屏幕播放事先录好的点头视频也能过甚至有人直接把目标人物的照片打印出来弯折一下贴在脸前照样能骗过早期规则。传统的眨眼、张嘴、左右转头这类指令式活体检测在“预先录制的视频回放”面前几乎不堪一击。后来我们换了一条思路既然用户手里拿的是一台手机手机屏幕本身就是一块可以动态改变颜色和亮度的光源那为什么不把验证过程变成“随机打光”呢这就是我想聊的炫彩活体检测技术——把手机屏幕转化为动态光源将每一次验证请求变成一个不可预测的光学挑战把高安全性人脸验证从“让用户动一动”升级成“让光线和脸互相证明”。这个方案的核心逻辑很简单每次请求前后端生成一段只有本次会话知道的光照图案序列手机屏幕按这个图案跑摄像头同步录制面部对光影的响应。活体判断不再依赖行为动作而是看脸上的光影变化是否跟屏幕图案形成物理上可解释的对应关系。静态照片没有足够的三维结构视频重放又无法预知挑战图案低成本攻击手段就都被拦在门外了。这篇文章我会把原理、方案选型、工程实现和调参排障一块儿讲清楚适合正在做人脸验证、风控鉴权或者终端多模态感知的团队参考。1. 把屏幕变成探照灯之前先聊聊传统活体检测在防什么1.1 三类常见攻击路径成本和威胁等级完全不一样做风控的人心里都有一本账不是所有攻击都值得用昂贵方案去防得先搞清楚对手手里有什么牌。第一类是照片攻击。这是门槛最低的把目标人物的高清正脸照打印出来或者直接拿另一台手机打开一张照片怼在摄像头前。成本几乎为零但也是最好防的一类因为平面照片没有深度、没有微小运动甚至边缘都可能穿帮。第二类是视频重放攻击。攻击者提前录制一段目标人物做指定动作的视频然后在验证时用另一块屏幕播放。这种攻击的威胁等级直接跳了好几档因为视频里的人是会动的会眨眼、会微笑、会摇头如果验证系统还停留在“检测动作是否出现”的层面几乎防不住。第三类是头模或者面具攻击。通过3D打印、硅胶面具物理复刻目标的脸部轮廓成本高、制作周期长一般出现在高价值账户的定向攻击场景。这类攻击对纯2D算法最有杀伤力但对有深度信息采集的设备来说反而容易识别——毕竟面具材质的反射特性和真人皮肤差异很大。1.2 指令式活体的固有短板一切可预知的动作都可以被脚本化传统指令式活体的思路是“让用户做一个动作”比如眨眨眼、张张嘴、左右转头。这套方案早期还行但对抗升级后问题就暴露了动作集合是公开的而且极其有限。攻击者只要提前录制一段目标人物完成所有标准动作的视频验证时按需播放就行了。有人会说那我把动作指令随机化比如随机要求“先向左转头再眨两次眼”这样攻击者不就没法提前录制了吗理论上没错但实际效果有限。因为随机动作的“随机空间”很小翻来覆去还是那几个动作的组合攻击者可以分别录制各个动作的片段然后实时拼接。拼接画面虽然会有跳帧但很多低成本算法根本不会去细查帧间连续性。更深一层的问题是指令式活体只验证了“有没有做动作”没有验证“这个动作是否发生在真实的物理环境中”。攻击者播放视频时视频画面里确实有人在做动作从2D像素层面看动作是真实存在的只是它的物理来源不是现实世界。要打破这一点必须引入一个攻击者无法伪造的物理变量。1.3 为什么“随机光学挑战”的攻防位置更合理手机就在用户手里屏幕光的可控性极强这是任何攻击者都绕不开的物理条件。服务器可以在每一次请求中生成独一无二的图案手机屏幕是唯一的渲染设备摄像头是唯一的观察设备。屏幕光打在目标脸上等于让攻击者面对一个不断变化的物理环境。攻击者如果要伪造光影响应就得在回放时实时知道挑战图案并且让预录视频里的人物脸上出现和当前挑战一致的动态光影。这几乎做不到。他们能做的只有两种要么用一张静态照片去“扛”动态光要么用一个实时运算的程序去模拟光影——前者会暴露空间一致性的破绽后者对算力、渲染精度和时延的要求高到不划算。这就是炫彩活体检测的逻辑起点不跟攻击者比拼动作指令的复杂度而是直接把物理光源变成验证因子。2. 炫彩活体检测的核心原理随机光学挑战与响应一致性校验2.1 把人脸理解成一块“有深度的反射屏”要理解这套方案先得放下“人脸是一张图片”的惯性思维。真实人脸是一块三维的、多层介质的反射体皮肤含有黑色素、血红蛋白、角质层对不同波长的光反射率不同头发是高吸收低反射区域眼球则是一个高光点。当手机屏幕显示一块红色高亮区域时真实人脸靠近屏幕的一侧会被均匀地染上红调皮肤上的血色感会变强。当屏幕切到绿色高亮时肤色又会往绿调偏移。与此同时因为面部是三维的屏幕光从左侧扫到右侧时脸上的阴影方向和明暗分布会跟着改变——鼻梁两侧、眼眶下方、颧骨下方都会出现有先后顺序的微阴影变化。而打印照片是平面无论外部光源怎么移动照片上的明暗关系都纹丝不动。打个最朴素的比方用手电筒从左边照一颗球球的左半亮右半暗手电筒换到右边明暗关系刚好反转。如果给对面看的是一张球体照片那么不管手电筒怎么移动照片上的光影永远是固定的。炫彩活体检测做的事情就是把手电筒换成手机屏幕然后观察“球”的明暗是否真的跟着光源动了。2.2 一次典型的验证流程拆解标准流程大概是这样用户在App内发起验证请求服务端生成挑战图案序列核心参数包括随机种子、会话ID、时间戳、图案类型、光带宽度、移动速度、循环次数。客户端解析挑战参数用全屏纹理Shader实时渲染图案并同步开启前置摄像头录制。摄像头录制2到3秒视频每一帧都记录精确的时间戳和屏幕图案的理论位置对齐。对视频帧做人脸关键点定位提取面部区域计算亮度、色温、高光分布等统计特征。把特征序列和理论图案序列做时序相关性分析同时校验空间变化方向是否合理。综合多路特征得到活体评分输出通过或拒绝。2到3秒的时长是有讲究的。太短了光带只能扫过一两轮用于统计的时间序列样本不够误判率会上升太长了用户体验明显变差用户可能在中途移动手机或转头引入额外干扰。单次验证控制在2.5秒左右既能覆盖3到4轮完整扫描又不会让用户觉得繁琐。2.3 判定时要回答的三类问题图案、空间、时间算法不直接回答“是不是真人”而是回答三个更具体的问题图案一致性面部区域的亮度/色相变化是否跟屏幕当前显示的颜色匹配屏幕亮红时脸部应该偏红屏幕亮绿时应该偏绿并且这种颜色跟随关系要在几十毫秒内发生。如果屏幕上已经切换到绿色脸部还在持续泛红说明信号链路有问题。空间一致性光带从屏幕左侧移动到右侧时面部左右两侧的明暗变化是否有先后顺序因为屏幕和面部之间有物理距离屏幕左侧发光时左脸会被照亮得更明显光带移到右侧时右脸才亮起来。二维照片没有这个深度关系整张脸会同时被环境光影响或者产生无法解释的同步变化。时间一致性多个扫描周期的节奏是否稳定是否存在剪辑、跳帧、合成痕迹真实摄像头录制的光影变化是连续平滑的而攻击者若用脚本控制渲染程序模拟会产生微妙的时间抖动或帧间跳跃。三类一致性综合起来比任何单一指标都难欺骗。3. 工程实现挑战生成、屏幕渲染、采集与判定编排3.1 服务端负责生成挑战客户端不做自由发挥有个关键设计原则挑战参数绝不能由客户端自行生成。客户端跑在攻击者手里任何“本地随机”都可以被逆向、被Hook、被固定种子绕过。正确做法是服务端生成一段完整的图案时间表下发后客户端只负责当“播放器”。一种可行的实现是类似TOTP的时间同步机制。服务端维护一个随时间变化的随机种子结合会话ID和一次性使用标记签发挑战。挑战的内容可以很简单一串归一化坐标和颜色值的列表例如“第200毫秒光带中心位于x0.3颜色为纯红第350毫秒光带中心位于x0.55颜色为纯绿”。客户端按时间顺序渲染即可不需要理解图案含义。挑战还必须绑定“一次一密”和“短时有效”。同一个挑战图案被使用过一次就立即作废有效期控制在几十秒内防止攻击者拿泄露的挑战去二次构造。服务端下发时还可以附带一个签名客户端渲染的同时回传签名校验结果防篡改。3.2 渲染层与摄像头采集的同步是工程落地的头号难点这里说的不是“能不能显示”而是“显示和采集能不能在时间轴上严格对齐”。我们一开始走了不少弯路最初用自增计数器去做帧对齐结果不同机型的帧率差异直接把时间线打乱了。后来统一改用系统级时钟戳CLOCK_MONOTONIC渲染每条挑战事件时记录当时的时间戳摄像头回传的每一帧也带同一时基的时间戳两边才能对齐。另一个容易被忽略的点是摄像头自动白平衡和自动曝光必须锁定。大多数手机相机会主动“修正”画面色彩屏幕从红变绿时相机会为了让画面“看起来正常”而自动调整白平衡结果面部色偏几乎被抹平特征完全消失。必须通过Camera2 API把AE和AWB切到手动模式锁定曝光时间和ISO才能采集到真实的色彩响应信号。实操中还有一个小技巧挑战图案用GPU着色器渲染直接在Surface上完成不要经过Bitmap中转。否则图案渲染速度跟不上视频帧率时间戳全是错的后续所有分析都白做。内存中每多一次拷贝就可能多出几十毫秒不可控延迟。3.3 回传数据与判定模块的分工前端回传的数据不应该是整段压缩视频最好是关键帧序列加传感器数据。视频压缩会严重破坏色彩精度尤其在高频颜色交替变化的区域压缩伪影会被误判成“活体特征”。建议回传未压缩或轻压缩的关键帧配合陀螺仪和加速度计数据用来排除极端姿态和屏幕甩动。服务端判定模块一般分成四个阶段基础质量检测人脸清晰度、遮挡比例、画面亮度是否在合理区间。这一步先挡住低质量请求。物理一致性检测计算面部区域亮度/色相时间序列和理论图案之间的相关性判定图案跟随是否成立。深度线索检测分析光带扫描过程中左右脸的明暗变化顺序验证三维结构。附加检测检查摩尔纹、屏幕反射、画面边界伪影等攻击痕迹。每个阶段都可以独立调节阈值方便针对不同风控场景做弹性配置。低风险场景可以只跑前两个阶段高风险场景四个阶段全开。4. 攻击路径与对抗思考为什么预录视频和实时合成都不好使4.1 预录视频的第一个死穴无法预知当前挑战攻击者想在验证前准备好一段能通过的视频前提是知道本次验证的屏幕图案是什么。但挑战是由服务端动态生成的绑定会话ID和时间戳有效期只有几十秒。攻击者既不可能提前知道图案也不可能在拿到图案后再找回目标人物重新录制。即使攻击者非常激进尝试用“盲猜”的方式录制多段视频每一段都模拟不同的光带扫描模式随机碰撞命中的概率也低到可以忽略。图案序列的随机空间足够大服务端还可以在同一会话内轮换两次甚至三次不同图案进一步压缩碰撞窗口。4.2 实时合成为什么还是不行不是做不到是不划算更狡猾的攻击者会尝试实时伪造光影在摄像头前放一张目标人物的照片然后用另一块屏幕在照片上方来回移动模拟光带扫过或者用实时滤镜给视频流叠加动态光影。这类攻击存在理论可行性但实际会受到多重制约。第一平面照片不具备三维反射特性。屏幕光从左往右扫过时真实人脸的鼻梁、眼窝、颧骨会形成连续的阴影迁移而照片表面的光影过渡是均匀的没有深度边缘和遮挡关系很容易被空间一致性校验识破。第二RGB三通道的相对变化很难同时伪造。屏幕上切换红绿蓝三色光时真实皮肤对三种波长的反射比是固定的攻击者要在一个实时合成管线里精准模拟这种反射比需要知道当前人脸的材质参数还要保证视频编码不丢色。编码一压缩色彩精度一损失信号就“糊”了。第三任何实时处理都会引入时延。攻击者拿一块屏幕在镜头前移动时屏幕上的光带位置和摄像头画面中的光带位置之间存在物理延迟这种延迟会体现在帧间抖动上。只要判定模块计算图案到达面部的时间是否符合物理距离和光速就能发现异常。4.3 多帧级联判定把单次攻击变成一场必败的连续博弈我们最终落地时把判定做成了多轮挑战的级联机制。第一轮先跑一个快速测试如果通过就进入第二轮新一轮图案依赖第一轮的结果动态生成。这样攻击者即使攻破第一轮也无法根据第一轮结果调整第二轮因为第二轮的图案在服务端决策后才下发客户端拿到图案到开始渲染之间只有极短的响应窗口。连续两轮都伪造成功的概率已经不是攻击成本的常数倍而是指数级上升。5. 实测中的调参与翻车记录从误拒绝、暗光噪点到屏幕亮度不足5.1 光带宽度、移动速度与刷新频率的交叉实验挑战图案不是越复杂越好。我们最初设计了很多炫酷的图案比如多色光斑游走、对角线扫动、频闪彩虹但实测下来有些方案识别率高但用户受不了有些方案用户无感但攻击者也很容易模拟。最有效的其实是简单的单色光带匀速扫动。关键参数有三个光带宽度、移动速度、刷新频率。光带宽度用屏幕宽度的百分比来衡量。太宽比如超过70%整张脸几乎被均匀照亮扫描效应不明显空间一致性校验就失去了意义太窄比如低于20%光带可能只覆盖半张脸特征区域不足。我们最终选定30%到50%宽度这是一个在“观察得到扫描”和“特征足够多”之间的平衡点。移动速度上每秒完成1到1.5次全屏扫描比较合适。太快了摄像头的帧率跟不上一帧内图案已经移动了一大段距离时序对齐出现困难太慢了用户要等更久才能完成多轮扫描体验变差。我们按1.2次每秒作为默认值。刷新频率需要注意一个坑如果挑战图案使用正弦波亮度沿屏幕滚动空间频率和移动速度必须避开摄像头采样频率的整数倍否则会产生莫尔条纹严重影响亮度时序信号的提取。我们通过引入固定相位偏移来避免这个问题。5.2 暗光、弱光、频闪环境下的采集质量其实没想象中可怕暗光环境反而更适合这套方案因为屏幕光成了主要光源画面中的信噪比更高响应特征更清晰。真正的麻烦来自两类问题一是省电模式和自动亮度限制。很多手机在遇到大面积高亮图案时会主动降低屏幕亮度导致挑战图案的实际输出和理论值相差很远。解决方式是在验证流程开始时请求用户关闭自动亮度并把屏幕亮度设置为固定最大值同时检测屏幕亮度传感器的实际读数。二是室内高频荧光灯带来的频闪干扰。一些环境光源以100Hz到120Hz的频率波动视频帧率如果和它不同步画面亮度就会出现周期性伪影。我们不得不在算法里加入环境光频率估计和滤波模块把环境光的亮度分量从响应序列中分离出去。经验是先对环境光建模再估计屏幕光的响应两个步骤分开做比直接算“总码率”要稳定得多。5.3 三个印象深刻的失败案例案例A偏光太阳镜把屏幕光“吞”了。一位测试用户戴着偏光墨镜屏幕偏振光被镜片过滤脸部亮度时序几乎完全没有变化算法直接判成无响应。后续我们在引导页增加了“请摘掉墨镜/偏光镜”的提示同时在渲染图案中增加了一路无偏振的大面积亮度脉冲这样即使镜片滤掉了方向性光亮度脉冲仍然可以触发响应。案例B某款OLED屏幕的色彩响应严重非线性。一款中端机型在低亮度区域的Gamma曲线和相机感知曲线叠加后红绿蓝三色的响应比值完全偏移算法判定连续失败。排查后确认不是算法问题而是屏幕本身的色彩管理机制在低灰阶区间做了大幅裁剪。解决方案是要求屏幕亮度不低于最大值的80%同时在服务端增加针对特定机型配置的预校准参数。案例C帧率调整导致挑战时间表失效。一次线上灰度测试中我们升级了采集模块把预览帧率从60fps降到了30fps但挑战时间表仍然按60fps的时间粒度下发。结果每帧之间图案已经跳变多次算法无法建立准确对应。修复方式是把挑战事件的时间分辨率改成跟随设备帧率动态调整而不是固定一个时间表。6. 给想复现这套方案的同学的几则工程建议6.1 优先保证摄像头能输出带时间戳的原始帧而不是压缩后的预览流这是整个工程链路里最容易被低估的一环。很多开发者在做原型时直接读取系统预览回调的Image对象拿到的帧已经经过自动白平衡、自动曝光和压缩编码的处理色彩信息损失严重。建议从第一天就接入带手动参数的摄像头输出接口输出未压缩的YUV或RAW帧配合系统时钟戳对齐。宁可在后续降低帧率也不能丢掉色彩精度。6.2 挑战图案设计要同时兼顾“可判别性”和“感知舒适度”不是光效越炫越安全。频闪频率过高会引发光敏性不适甚至可能触犯无障碍设计规范。我们最终把亮度变化周期控制在500毫秒以上整体闪烁频率低于2Hz。颜色上使用纯红、纯绿、纯蓝这类极限色值比中间色更容易分离通道因为肤色对RGB三个通道的响应差异更明显。但用纯色时要注意屏幕自带的色彩增强模式有些手机会自动提高饱和度导致实际输出和理论值出现偏差。6.3 从活体检测走向“屏幕光感知”的扩展思路屏幕作为动态光源的价值不止于活体检测。它可以延伸为一种通用的“可信环境光编码”支付确认时屏幕播放特定光码摄像头同时验证人脸和光码既能防截屏又能防录制远程办公场景中用屏幕光感知确认用户面前没有第二块屏幕在重放甚至可以让屏幕光的频率和手机陀螺仪联动构建一个“只有这台设备当前状态才能生成”的物理签名。我落地这套方案最深的感觉是活体检测的本质不是让用户做动作而是让验证系统掌握一个对手无法提前拿到的物理参数。手机屏幕恰好就是这样一种低成本、可编程、又用户必然持有的物理参数。如果你们也在做类似产品我建议先把随机种子牢牢放在服务端再把响应一致性做成可解释的时序匹配最后用真实攻击样本库去验证效果。祝各位在攻防路上少踩几个坑。
