聊聊照片类数据中的显水印和隐水印

前言

最近数据安全和个人隐私保护重新回到大家关注的视野，这是好事。作为数据治理的部门而言，这里实际上我们需要关注的应该有两点：

1. 数据授权的合规性：也就是要确保数据的最小颗粒度授权，预防数据泄露的风险。特别是涉及个人信息的数据应该在取得用户同意的前提下授权获取。这是降低数据泄露风险，亦是确保数据服务合规的最理想方案，在技术上我们通常以 OAuth2 授权码结合 API 网关的方式实现，这个我们留到下一篇文章展开细讲。

2. 数据内容的可追溯性：也就是万一发生数据泄露，应该可以追溯到数据泄露的来源，从而快速定位止损，并确定责任人。然而数据内容的溯源并不容易，因为在数据传递的过程中很难去给他额外的添加一个标记且不改变数据本身的含义。

溯源与可信

数据的溯源和可信实际上是两件事情，数据的可信，或者说数据的不可篡改性，通常会通过签名来实现。举个例子：

假定我们需要传递一条数据 data，我们可以对他进行一个签名，附带一个 sign 的字段，这个签名可以使用私钥来生成。而数据的接收方可以通过对应的公钥，针对数据 data 和 sign 进行验签，从而确保数据的未经篡改和可信，这也是现在 CA 证书体系的基石之一。

然而签名并不能帮助溯源，回头刚才的例子，data 和 sign 是分离的两个字段，我们在验证其可信性的时候，当然要求他们必须同时出现。然而既然产生了数据泄露， 那泄露的必然只有 data ，签名对此并不能提供什么帮助，溯源时所需要的方案是——水印。

水印

水印的本质，是要在数据里面混入一些标记，他既不能影响数据的正常含义，又不能被轻易的从数据中剥离（就像那个签名的 sign 一样，如果可以被轻易丢掉那就没有意义了）。

针对数据库以及通用数据的水印技术，目前尚不太成熟，尚处于理论研究的阶段，然而图像领域的水印已经非常成熟，因此针对照片这一特定的敏感数据，可以采取非常有效的水印方案进行溯源。对于照片类数据的水印方案，大概可以有显式水印和隐式水印两种。

显式水印

顾名思义，就是水印直接打在照片上，比如这就是一个显式的水印：

通过调整水印的角度和水印的覆盖范围，将极大的增加去除水印的成本，从而保护照片数据的溯源提供支持，这也是我们大部分场景下图片类数据的水印标准方案。

当然我们可以通过调整水印的颜色，透明度等来降低水印的存在感，提升肉眼观察时的体验，例如这样子依然保留了水印，然而水印已经非常不明显，特别在小图的场景下几乎无法分辨。

回到对照片类数据的保护，显示的水印特别适合在需要向用户展示照片，但并不给用户提供照片下载的场景，也就是这个照片的使用场景是专一化的。例如人脸识别时，终端设备上的匹配显示这种场景，一个显式的水印可以确保我们照片数据在传递给人脸识别设备供应商时，安全可溯源，几乎很难消除水印信息，同时适当的透明度处理，也可以做到对用户几乎无感。

隐式水印

也叫盲水印或者隐写术，是指将水印信息隐藏在图像数据内部，肉眼观察无法感知的水印实现方式。在溯源时，需要通过特定的算法来从图片中重新提取水印信息。

一种最简单的实现方案是 LSB （最低有效位）替换。通常图片内的像素通过 RGB 三原色组成，每个颜色占用 8 位，这样总共有 2^24 种取值范围，对于比较细微的颜色变化（也就是颜色分量的最低位），肉眼无法分辨这里的变化，因此可以把水印编码在每个像素颜色分量的最低位上（Least Significant Bit），就能实现肉眼无感的隐式水印嵌入。下面这张图我就通过 LSB 嵌入了水印，显然肉眼无法分辨出任何区别。

当需要提取水印的时候，就需要将加密过程反过来，从像素的最低位去提取信息，并将其重新组合为水印数据。Releases · DimitarPetrov/stegify (github.com) 这个项目提供了一个 LSB 水印的编码/解码工具，直接下载他的二进制 release，然后通过以下命令就可以简单快速的测试 LSB 水印

stegify encode --carrier <file-name> --data <file-name> --result <file-name>stegify decode --carrier <file-name> --result <file-name>

通过工具编码生成的图片，再去解码应该是可以解出来的，但是如果你尝试对我上面这张图片做 LSB 水印的解码，大概率应该是解不出的。原因很简单，图片上传到 infoq 后重新经过了编码，他的 RGB 像素信息已经发生了变化，这导致水印信息被损坏了。实际上 LSB 的隐水印方案很容易受到一些常见的图像处理操作的影响，如压缩、滤波、裁剪、旋转、缩放等，这些操作都会改变或破坏图像的最低位，导致水印信息的丢失或损坏。

除了 LSB 以外，还有一些其他的隐式水印方案，例如快速傅里叶变换(FTT)、离散小波变换 (DWT)等，实现原理上大抵都是先将图片进行频域变化，然后在频域图像种找一个合适的位置，比如低频等区域等，嵌入水印后，再逆向变换恢复原图。相比 LSB 而言，频域变换的水印方案抗攻击能力更强一些，然而如果图像的编码本身有较大变化，或者经过一些压缩处理等，则水印的提取依然可能难以解析。无论采取哪种方案，隐式水印的解析都尽量需要获得原图，才能比较好的保障解析的成功率。

因此，回到对照片类数据的保护，如果我们面临的场景中，用户可能会下载照片本身，并且需要将照片另外用作他途——例如用户个人门户内的照片头像等，此时显式的水印会影响照片本身的用途，不再适合作为水印方案，而隐式的水印是更好的选择。

尽管此时用户二次处理过的照片，很可能难以解析水印信息，然而这并不是我们溯源的场景，我们需要提防的是应用系统的供应商，或者应用系统本身的安全问题导致照片的原始数据批量泄露，此时通过流出的泄露数据（通常是原始照片），我们能够快速确定数据的来源，从而迅速定位产生数据泄露的应用系统，修复问题及时止损，并明确责任。

结束语

两种水印模式，实际上也是我们数据平台在提供照片服务接口时所采用的数据溯源方案。我们会将应用的 AppID 添加到照片的水印中，根据应用的实际场景确定显式水印或者隐式水印模式，确保通过数据平台提供的照片数据 100%经过水印保护，如果出现问题能够提供溯源支持。

但愿溯源的能力永远不要用上。

以上