Things Behind Apple's CSAM Detection

TL;DR

• NeuralHash is a MobileNetv3 whose last layer is replaced by Fully-connected.
• NeuralHash convert the outputs of MobileNetv3 to hashes by Random Projection.
• Transfer Protocol used "a two-layer encryption": Images are encrypted with a shared random key \(k_1\). \(k_1\) is splitted into \(t\) parts \(p_1, \dots, p_t\) by Sharmir's Secret Sharing. Each \(p_i\) is attatched to a matched image and further encrypted by using the hash of corresponding image as the key.
• This protocol looks good, but NeuralHash may cause false positive.

Introduction

苹果出人意料的宣布了一个保护儿童，以及限制涉及儿童色情信息传播的举措——Child Safety。苹果将会对用户的信息、图片、Siri以及搜索服务进行审查，找出其中可能的CSAM（Child Sexual Abuse Material）信息并与执法机关分享。显然苹果预料到了用户的不满，他们不但给出了一份面向普通用户的解说文档，还详细解释了这个上传信息的Protocol是如何工作的，甚至还有一些苹果之外人员对这个Protocol的验证。但这些显然不能平息用户的疑虑，对于这种行为是否真的安全，是否存在信息泄露，以及是否能够按照苹果设想的内容去工作，大多数用户都持怀疑的态度。在这篇文章里，我们将通过苹果给出的文档，来看一看这个功能背后是如何实现的。

General Architecture

虽然苹果在他们的CSAM Detection Technical Summary的P.4里给出了一个Overview，但它是有些晦涩难懂——里面充满了苹果自己的用词，以及反复冗长的说教式说明。因此我决定给出一个自己的版本：

整个流程可以分为三个部分：

1. NCMEC以及其他的儿童保护组织会向苹果提供图像数据库，苹果会用他们的NeuralHash根据图像特征计算Hash，最终得到一个大的Hash Table。

   注意，这里的Hash并不是普通意义上的通过Binary计算得出的Hash，而是来自于图像特征——因此即使有人修改了图片里的几个Bit，或者加上少量的马赛克也不会影响计算结果。

2. 上述的Hash Table会储存在用户的设备上。之后，用户的设备会扫描储存的照片，同时使用跟服务器同样的NeuralHash来计算Hash。这个Hash跟之前的Hash Table进行比对，相同的图片会进行加密之后上传到苹果的服务器。

3. 苹果对上传的图片进行处理，这个处理分为两个部分：

   1. 计算有多少图片跟数据库配对。
   2. 如果配对的图片大于一定数量，则对配对的图片进行解密，同时交给工作人员处理。如果没有达到这个数量，则不进行解密。

   一个普遍的担心是，就算苹果不解密数据，如果有人因为算法的问题错误配对了，那么苹果会不会把他告知给相关的团体？为了避免这个问题，苹果对配对数量加入了随机性——苹果自己也不知道具体有多少张配对了。因此只要数量不大于规定的值，苹果很难获得准确的信息。

下面，让我们分别看一看这三个部分。

NeuralHash

虽然在开头我们提到，苹果为了平息用户的疑虑公开了很多技术细节，但这些内容都是针对如何向服务器分享数据的Protocol，对于识别图片的"NeuralHash"，苹果却讳莫如深，只有在Technical Summary里提到了寥寥数笔：

NeuralHash is a perceptual hashing function that maps images to numbers. Perceptual hashing bases this number on features of the image instead of the precise values of pixels in the image. The system computes these hashes by using an embedding network to produce image descriptors and then converting those descriptors to integers using a Hyperplane LSH (Locality Sensitivity Hashing) process. This process ensures that different images produce different hashes.

这些内容并没有提供任何有用的信息——比如如何避免神经网络的误判，如何保证Hash对于Dataset能够具有最大的区分度。

不过，有人发现这个模型早在iOS14.3就已经存在了，不但如此还能够实际的执行这个模型，通过目前的模型，可以看到目前的NeuralHash是这样的：

1. 首先图片会变换成360x360的RGB格式
2. 变换过的图片通过MobileNetV3¹学习特征量，由于这里不是分类问题，所以最后一层并不是Softmax，而是一个Fully-connected。最终会变换成一个128维的输出。

3. 通过一个预先给定的Seed Matrix \(S\)，进行线性Projection \(v = SX\)，变换成96维的向量之后进行二值化。将所有的bit整合起来就成了最终结果。所以最终一个图片会被变换成\(\frac{96}{8}=12\) bytes长的Hash。

   这个Seed Matrix是如何计算的并没有任何说明，但考虑到这个简单的形式，看起来很像是SimHash（Random Projection）²，也就是\(S\)是一个随机生成的矩阵，我们把元数据映射到随机的轴上得到Hash。为了验证这个想法，我们把Seed的每个Weight统计一下：

   

   横轴是Weight的大小，纵轴是每个区间里包含的Weight的数量，可以看到Weight是很漂亮的高斯分布，因此可以认为这个算法来自于Fast LSH³。

总结起来，这个Hash可以写成下面的形式：

\(Hash(x) = [S\times MobileNetv3(x)], where S \sim N(0,\sigma) \in R^{96 \times 128}\)

实际上，尝试CNN + Locality Sensitive Hashing的论文并不是新鲜的东西，类似的论文比如ICCV’17的这一篇论文⁶，它的结构是这样的：

Reddit上对于NeuralHash模型的初步测试也显示出这个模型对于缩放，压缩有一定的鲁棒性，但并不能对应旋转和剪切，这跟CNN的特征是一致的。

但考虑到目前发现的模型只是一个古老的版本，Apple完全可以引入Attention⁴来应对图片剪切，以及引入Capsule Network⁵来应对旋转，纵使手机芯片并不能完整的这些算法，我也不认为最终出现在成品里的算法会像现在这么脆弱。如果你打算把图片都旋转45°的话那还是放弃为好。

总体来说，这个NeuralHash依然是一个普通的Neural Network，LSH算法也没有做特别的优化，它们都并不能保证Hashing一定是对的，不过对于这种只需要对比已知内容的工作，通过过学习来抑制False Positive似乎也不是一个坏主意。并且，苹果还留出了犯错的空间——要有多枚图片同时配对之后才会交给人工处理。

Communication Protocol

在计算完所有图片之后，下一步就是交给用户设备去比对了，而苹果在这个比对过程中尽可能的保证不获取范围之外的信息。对于这个Protocol苹果还给出了一份36页的说明文档（或者说论文），可以看出相比于NeuralHash，他们对这个Protocol更有信心。当然了，这个Protocol也确实没有问题。让我们忽略各种细节，粗枝大叶的看上去这个Protocol是这样的：

1. 首先，在本地配对的图片会用一个随机生成的Key1来加密，与此同时，设备还会生成一些"假的数据"，这些数据在加密后看起来就像是跟真的配对了一样。这样最终传到服务器上之后能够保证苹果无法准确的知道用户手上有多少有问题的图片。

2. 之后，这个用来加密的Key1会被分割成\(t\)个Partial Key，通过这\(t\)个Partial Key服务器可以反推出Key1。每一副真正配对的图片都会带有一个Partial Key，因此，如果真正配对的图片少于\(t\)个，服务器就无法得到全部的Partial Key也就没法得到Key1。这样就保证了图片数据是安全的。

   实际上，在看到苹果官网对这一部分的描述时，我就立马联想到了Shamir's Secret Sharing⁷，论文里也确实用了这个方法。Shamir Secret Share的思想非常简单：

   我们知道加密用的Key通常是一个巨大的数字，假设是\(k\), 如果想把它分割成\(t\)个部分，就随机选取\(t\)个数字\(c_1,\dots,c_t\)，这样我们可以构建一个多项式：

   \(F(x) = k + c_1 x + c_2 x^2 + \dots + c_t x^t\)

   我们知道，一个\(t\)阶多项式需要\(t\)组解联立才能求出系数，因此，我们取下面一组数字对作为新的Key：

   \((1, F(1)), (2, F(2)), \dots, (t, F(t)), \dots\)

   只有服务器知道至少\(t\)组解，才能求出系数，这就做到了安全的把Key分割成多个部分。实际上，这种方法在Google的Federated Learning加密里面也有应用⁸。

3. 之后，对于每个加密过的图像，都有一个附带的Partial Key。根据这个图像所配对的NeuralHash，设备会计算一个Key2，对这个Partial Key进行一次加密。而这个Key2并不会传给服务器——服务器通过自己手里的NeuralHash来计算这个Key2从而进行解密。这样就保证了服务器无法解密Hash Table之外的内容。值得一提的是，苹果采用了一种很有趣的办法来确认数据是否存在于数据库里，如果你对具体算法感兴趣，可以阅读他们的论文。

这就是苹果所说的2次加密的整体流程，对于有问题图片的用户，随机加入的假数据一定程度上模糊了图片的数量，而为了保证图片不被随意看到，苹果采用了Shamir Secret Sharing保证解密时的最小数据数量，而为了保证"清白的"用户，Shamir Secret Sharing得到的Key也只能对于配对的数据才能解密，考虑到网络问题，就算解密了工作人员也只能得到低分辨率的图片。这个Protocol至少看上去是没什么问题的，或者说——NeuralHash看起来更可疑一些。

Random Thoughts

• 显然从NeuralHash的结果里无法还原图片，但这并不的代表无法还原"低画质"的图片，用户的手里有NeuralHash的神经网络，也有LSH的矩阵，那么把NeuralHash作为一个discriminator，自己实现一个generator的话，自然可以近似的还原图像。好在苹果已经考虑到了这一点，传送到用户手里的数据库经过了一些变换，用户不知道变换的细节，因此这些Hash无法拿来作为GAN的判定器。

• NeuralHash的False Positive和False Negative都是个让人担心的问题。神经网络不确定性很多来自于分类层，针对分类的攻击并只需要让几个Feature变得足够强大，就能够压倒别的Feature从而让分类器出现误判。苹果通过Hash比对一定程度上抑制了这个问题，Hash来自于所有Feature的线性组合，而这些Feature没有Weight，都被量化成了0和1，这就意味着一两个突出的Feature并不会影响最终结果，除非有人能够构建出所有的Feature都一致的图像。

  反过来说，过于严格的判定显然会导致False Negative。因此比对Hash可以放宽到一定的汉明距离，即有\(k\)以上的Feature一致则判定为符合。而汉明距离设定为多少，需要对iCloud上的图片进行实际统计才能得出结果吧。

Conclusion

到这里，我们对苹果的这个CSAM Detection已经有了大致的理解，实际上，技术并不能保证运用中的问题——比如，NeuralHash会不会对亚洲人存在歧视？苹果的客户端没有按照要求把Key分割成\(t\)个呢？或者未来受到压力苹果把iCloud的内容直接交给工作人员审核呢？又或者，这个技术在不知不觉中变成了检测政治内容的工具呢？苹果保证了被监测的人员不会收到任何反馈——那么用户又怎么保证这个数据库只会用来识别CSAM呢？

不过考虑到这篇博客的目的并非批判或者维护苹果的决策，这些问题还是交给秋季发布会之后用户的反应去回答吧。