22、生物识别数据合规：指纹、面部、声纹数据定义、本地处理要求、不可逆加密存储方案
好，咱们今天聊一个很敏感、也很实在的话题——生物识别数据合规。
说实话，我最早接触这块是在一个金融App的项目里。当时产品经理一拍脑袋说「加个刷脸登录吧」，我第一反应是「技术上不难啊」。但等我真正去翻GDPR和《个人信息保护法》的时候，才发现——嗯，这事没那么简单。
你想想看，指纹、人脸、声纹，这些东西跟密码不一样。密码忘了可以重置，但你的脸丢了，能重置吗？不能。所以法律对这类数据的保护要求，是最高级别的。
一、什么是生物识别数据？
先明确一下定义。根据GDPR第4条，生物识别数据是指：
- 通过特定技术处理得到的、与自然人的身体、生理或行为特征相关的个人数据
- 能够唯一识别该自然人
- 典型例子：指纹、面部图像、虹膜、声纹、掌纹、DNA等
我个人习惯把生物识别数据分成两类：
| 类别 | 示例 | 特点 |
|---|---|---|
| 生理特征 | 指纹、人脸、虹膜 | 相对稳定，不易变化 |
| 行为特征 | 声纹、步态、击键习惯 | 可能受情绪、环境影响 |
我在项目中遇到过最头疼的，其实是声纹。因为用户感冒了声音就变了，识别率下降，用户投诉说「你们App是不是坏了」——但合规上，声纹依然属于敏感生物识别数据，处理要求一点不能降。
二、本地处理要求：为什么必须「本地化」？
说白了，生物识别数据最核心的合规原则就是——能本地处理，绝不传云端。
为什么？
- 一旦上传到服务器，数据就脱离了用户的控制范围
- 服务器一旦被攻破，生物特征就彻底泄露了
- GDPR和《个人信息保护法》都要求对敏感个人信息采取「更严格的保护措施」
我自己的经验是，Android平台上实现本地处理，主要靠这几个东西：
- Android Biometric API：官方提供的生物识别认证接口，数据不出设备
- Android Keystore System：密钥存储在硬件安全模块（TEE/SE）中
- BiometricPrompt：统一的人机交互界面，避免开发者自己采集原始生物特征
核心原则：你的App永远不应该直接访问原始指纹图像或人脸照片。你只能通过系统API得到一个「认证成功/失败」的布尔值。
举个例子，如果你用Camera API自己拍用户的脸，然后上传到服务器做比对——嗯，这基本就踩了红线了。我曾经审计过一个第三方SDK，它就是这么干的，我直接写了「不合规，禁止集成」的结论。
三、不可逆加密存储方案
好，那如果某些场景下确实需要存储生物特征模板（比如设备本地存储），怎么存才合规？
答案是：不可逆加密。
什么叫不可逆？就是你存了之后，自己也没办法还原出原始的人脸照片或指纹图像。常见的做法是：
- 使用哈希算法（如SHA-256）对特征向量做摘要
- 加盐（Salt）防止彩虹表攻击
- 密钥由TEE（可信执行环境）管理，App拿不到
下面是一个典型的本地存储流程：
// 伪代码示例：不可逆存储生物特征模板
1. 系统API返回特征向量（byte[]）
2. 生成随机盐值（16字节以上）
3. 使用PBKDF2或Argon2进行慢哈希
4. 存储：盐值 + 哈希结果
5. 比对时：用同样的盐值重新哈希，比对结果避坑指南：我曾经见过一个团队直接用MD5加密指纹模板——这基本等于没加密。MD5是设计用来做校验和的，不是用来保护敏感数据的。记住，生物特征泄露了，用户一辈子都换不了。
四、知识体系结构图
下面这张图是我梳理的生物识别数据合规核心逻辑，你可以对照着看：
五、合规检查清单
最后，我整理了一份自查清单，你在做生物识别功能时逐条核对就行：
- 是否明确告知用户？ —— 单独弹窗，不能藏在隐私政策里
- 是否取得单独同意？ —— 不能一揽子同意，必须单独勾选
- 是否本地处理？ —— 原始数据不出设备
- 是否不可逆存储？ —— 哈希加盐，密钥由TEE管理
- 是否有删除机制？ —— 用户撤回同意后，必须能彻底删除
- 是否有备用方案？ —— 不能强制使用生物识别，必须提供密码/PIN作为替代
特别注意：Android 10及以上版本，系统对生物识别数据的保护已经做得比较完善了。但如果你要兼容低版本，或者使用第三方SDK，一定要仔细审计——我见过太多「本地处理」的SDK，实际上偷偷把特征值传到了自己的服务器上。
嗯，关于生物识别数据合规，核心就是这几点。说白了，技术上不难，难的是你有没有这个意识。每次产品经理说「加个刷脸吧」，我都会反问一句：「你准备好合规文档了吗？」
公众号:蓝海资料掘金营，微信deep3321