LockPic：隐私保护的照片共享

原创于 2025-10-25 09:26:03 发布 · 977 阅读

10 ·

CC 4.0 BY-SA版权

文章标签：

#隐私保护 #照片共享 #可逆加密 #密钥管理 #JPEG加密

LockPic：社交网络中的隐私保护照片共享

1 引言

如今，社交网络蓬勃发展，随之而来的是个人照片的公开分享。从隐私的角度来看，一旦用户发布照片，他或她就失去了对该照片的全部控制权。即使之后从服务器上删除了该内容，已经保存该内容的其他用户仍可无限次重新分享，甚至违背原始所有者的意愿。当照片涉及其他人（这些人可能不希望内容被分享，甚至可能 unaware）或当主题受到法律限制时（例如大多数国家对儿童的情况），情况会更加严重；或者当某些人物具有一定知名度时，问题也会加剧。

传统的保护机制在这种场景下并不适用。与其保护整张图片，不如仅保护或隐藏其中的关键部分。这样既能允许社交网络中的其他成员预览图片，又不会损害图片中用户的隐私。通常情况下，人脸是需要保护的目标，但其他元素也可能需要隐藏，例如车牌。可逆隐藏的优势在于，授权用户能够恢复完整的图片，而非授权用户只能获得公开部分。

在提出解决方案时，我们需要考虑三个参数：
– 可用性。隐藏技术应尽可能不引人注目，并且足够轻量级，以便在移动平台上顺畅运行。
– 互操作性。应易于将隐藏过程集成到照片共享工作流程中。
– 安全性。在不知道用于隐藏关键部分的密钥材料的情况下，应难以恢复原始图片。

我们方案的核心是一个基于OpenSSL和开源JPEG编解码器的C语言库，该库在JPEG图片的编码过程中集成了密码学强加密（AES）。LockPic应用1基于此C语言库构建，能够加密图片中的敏感部分，并在之后对其进行解密。我们还实现了一个配套密钥服务器，用于传递保护图片所使用的加密密钥。

2 相关工作

文献中提出了许多针对图片和视频的部分或选择性加密方案[8]。如果我们聚焦于静态图片，其中大多数方案依赖于使用JPEG2000格式[3]，该格式为部分加密提供了更好的基础，但存在一个主要缺点：当前的社交网络和网页浏览器大多不支持JPEG2000格式。在本节中，我们重点关注基于JPEG[5]的解决方案。

在下一段中，我们将简要概述JPEG图像的编码方式，以便解释如何集成加密机制。图像包含1到3个通道：一个亮度通道和最多两个色度通道。每个通道被分解为称为MCU（最小编码单元）的方形块，并分别对每个MCU进行编码。

每个MCU经历离散余弦变换，并保留对应于最低频率的64个系数（即人眼最容易分辨的部分）。这些值会被四舍五入，以使它们之间的零尽可能多；这一称为量化的步骤会引入损失。最后，使用霍夫曼编码对该序列的64个数字进行无损压缩。这明确指出了执行加密过程的最佳位置：因为在量化后得到的64个系数在此之后不会再遭受进一步损失。

在[2]中，作者提出了一种可用于隐私保护视频监控的方法。随后在[7]中，他们调整了该方法以支持JPEG并提供了一个原型iOS应用Proshare。他们的解决方案基于翻转编码图像中系数的符号，即使用任何密码学上安全的伪随机数生成器，将系数的符号更改为1，或保持为0。尽管该方案在一般情况下表现良好，但其在高分辨率图像上的应用受到限制，因为除了使用一次性密码本加密直流分量的超高安全级别外，所有提议的加密级别下的扰乱效果均变得不太明显。遗憾的是，目前尚无足够信息说明在超高安全级别下用于符号翻转和一次性密码本加密的PRNG类型，因此无法评估该方案的实际安全性。另一个重要方面是，在撰写本文时，客户端应用中的扰乱与解扰以及自动密钥分发在原型中尚未得到支持。还有一些其他方法[6,11]也基于对JPEG系数进行伪随机移位来设计其加密算法，试图保留足够的信息使整个图像保持“同质”，同时尽量减少识别出被扰乱区域的可能性。

基于某些随机模式翻转/移动JPEG系数符号的方案的主要安全性风险在于，攻击者可以通过观察打乱区域中邻近像素的图像特征，在第一阶段从边缘向中心迭代，利用暴力破解攻击重建该模式。此外，其视觉输出相当显眼，如图1a所示。

为了减轻视觉影响，我们可以采用 [11]中描述的思想：始终保留最重要系数（DC），并对剩余的63个系数进行伪随机移位。这种修改的效果使输出在视觉上可以接受，如图1b所示。然而，这不仅从理论上降低了算法的安全性（暴露了更多信息），在实践中也是如此。仅加密交流系数的符号已被证明对视频内容不安全 [4]。包含颜色信息的DC系数保持不变，这意味着任何加密后的 MCU中的平均颜色与加密前相同。对于足够大的图像而言，MCU基本上表现为一个像素；因此正如我们之前提到的，即使信息被修改，肉眼也难以察觉加密的存在。如图1c所示。除了 [7] 中的超高加密级别外，所有加密级别都会受到大致相同的影响。

这些提议的一个关键方面在于，经过扰乱的图像包含了在给定加密密钥的情况下恢复原始图像所需的全部信息。从实际角度来看，这似乎是一个良好的起点，因为加密和解密算法非常简单且高效。在[9]中，作者提出了一种将恢复图像所需的某些加密信息存储在云中的解决方案。他们的方案基于一个代理，该代理拦截从社交网络下载的所有图像，并实时对其进行解密，提供一种透明解密服务。尽管作者声称他们的方案仅在云中增加了最小的照片存储开销，但确实引入了一个新的依赖。此外，该透明代理是无害的在HTTP连接中使用时没有问题，但在社交网络当前标准的HTTPS中使用时，可能会引发一些安全性和信任问题。

在 [10]中，他们采取了不同的方法，不是加密图像的某些部分，而是使用 JPEG 文件作为加密图像的容器。他们的重点是保持容器 JPEG 在常见社交网络中的可恢复性，即抵抗 JPEG 重新压缩。该方案基于 JavaScript，提供浏览器端解密图像，无需任何服务器来存储加密的图像部分，但无法仅保护图像的部分内容，他们的提议是全有或全无的加密。由于容器 JPEG 并不能代表所分享的图片，该方案在某种程度上等同于仅仅分享受保护图片的链接。

另一个在大多数方案中通常被忽视的问题是应用程序的可用性。一些应用假定图片中存在一个需要保护的指定区域，但并未说明如何定义坐标以及如何激活保护机制。在[1]中，作者提出使用可穿戴标签（二维码）来激活保护机制。在他们的方法中，当拍照时，佩戴Privacy. Tag（即打印的二维码）的用户会被识别，并根据其偏好自动保护其人脸。

3 充加密/解密模块

我们的方案基于一个C语言库，该库在进行JPEG编码/解码的同时执行加密/解密。该核心C语言库需要对称密钥来对JPEG图片进行编码和解码。

我们对加密/解密过程规划了以下要求：必须是可逆的；加密后的输出必须仍然是标准格式下的有效图像；且该过程应是密码学上安全的。我们的目标是对图像中任何被加密的区域进行彻底失真，使其无法辨认，同时保持其余部分基本不变。加密/解密过程应为轻量级的，并生成大小可控的加密文件。此外，理想情况下，加密图像中的混淆区域相对于图像其余部分在视觉上应不显突兀；即图像的颜色和大致轮廓应与原始图像相似。这一要求在某种程度上与期望的失真效果相冲突。失真程度越高，输出的失真程度就越高。我们试图在失真水平上找到一个折衷方案，优先考虑安全性而非美观我性们。最初的方法是使用基于需模糊区域中像素安全置换的加密机制；但这意味着依赖BMP格式，这带来了多个问题——主要是速度和输出大小。在图2a中可以看出，像素随机化保留了原始图片的颜色，但未保留底层人脸的形状。

这可以通过将感兴趣区域分解为小块，并仅在小块内应用伪随机化来部分解决。在图2b中可以看出，这种情况下加密的侵入性较小。如前所述，在位图级别操作的主要问题是图像的大小。如果我们随后将生成的图像转换为压缩格式，则会出现色彩失真问题（见图2c），而这一问题难以轻易解决。在评估了各种优缺点后，我们采取了一种完全不同的加密方法，不再将图像视为像素矩阵，而是直接针对JPEG编码图像，并将加密过程集成到JPEG编解码器内部。

示意图0

示意图1

在我们的方案中，每个MCU（最小编码单元）内所有非零系数的序列使用标准对称密码进行加密，具体而言，我们采用OFB模式的AES，从而生成一组新的系数。需要注意的是，该方案完全不保留原始颜色分布。然而，无论图像大小如何，加密区域都将保持完全模糊化。在附录B中提供了加密输出示例。

我们决定仅对非零系数进行加密，以保持压缩算法的有效性。霍夫曼编码利用了连续的零出现的规律，但如果对所有系数都进行加密，则这些模式将被破坏。实际上，如果对所有系数都进行加密，生成的JPEG图像即使比对应的 BMP图像小，仍然过大而不便于管理。我们承认这会削弱方案的安全性（与同时加密零系数的方案相比），因为我们公开暴露了哪些系数为零、哪些不为零。然而，这一信息对于重建图像而言远远不足，而作为交换，它使得加密后的图像大小与常规JPEG文件相当。

该方案满足了我们最初为加密过程设计的大部分要求：它确实是可逆的，完全混淆了被加密的区域，且不会影响图像中的任何其他区域。加密文件的大小几乎与原始文件相同，且加密/解密过程快速且轻量级。但我们的方案也存在一些不足之处。首先，会造成一定程度的质量损失（由于转换为JPEG格式导致，而JPEG压缩总是有损的，因此无法避免）。其次，图像中的加密区域非常显眼。还应注意，此实现方式不支持对图像进行进一步压缩。

某些社交网络为了优化存储和网络带宽会对图片进行重新压缩，这可能迫使我们使用一些外部服务来存储受保护的图片（例如 Flickr、ImageShack、Dropbox 等），仅分享图片的链接而非图片本身。这样一来，社交网络只会存储图片的预览图，而原始图片则始终可以从外部服务中获取。然而，也存在一些不进行图片重新压缩并保留原始元数据的社交网络（例如 Google+），在这种情况下我们无需使用外部服务。

4 LockPicElements 和安全性模型

我们假设用户将照片存储在自己选择的服务中。这可以是社交网络或照片共享服务，但用户也可以通过电子邮件或其他方式共享照片。我们假设该服务器不会修改照片，但可能有兴趣了解受保护的内容。

每当需要对图片进行加密或解密时，LockPic应用都会通过安全通道向密钥服务器查询。密钥服务器对图片内容一无所知，仅知道部分元数据和加密密钥。这样，图片及其用于加密/解密的密钥被存储在不同的信任域中。

密钥服务器和照片共享服务被视为诚实但好奇的服务器。我们假设它们不会共谋来破坏用户隐私。密钥服务器仅会向授权用户提供密钥，并将根据指令为图片生成密钥和ID。照片共享服务被信任不会篡改图片，但对于谁被授予访问加密图片的权限没有额外要求。其他用户可以使用标准API与这两个服务进行交互，且不应被信任。用户之间可能相互串通，并可以访问存储在照片共享服务中的所有图片，但只能根据密钥服务器中授予的访问权限获取密钥。

加密工作流程（图3a）包含四个步骤。通常在用户使用LockPic应用拍摄照片时开始，但用户也可以选择已存储在手机中的照片。应用随后会向用户显示该照片，并提示他们选择需要保护的区域以及哪些用户能够访问这些区域。

然后，应用通过安全通道向密钥服务器查询，以获取每个感兴趣区域的加密密钥。应用会发送照片的名称和尺寸，以及每个需要与被授权访问这些区域框的用户列表一起加密。密钥服务器为该图片生成一个随机ID，并将受保护区域框的信息存储在数据库中。然后，服务器返回该ID以及对应于每个请求区域框的加密密钥列表，每个区域框一个密钥。我们在附录 A中详细说明密钥生成的细节。

应用程序将加密密钥、坐标和ID传递给修改后的JPEG编码库，该库会使用相应的密钥对区域框进行加密，并将ID包含在图像的系统中。为了允许其他用户查询解密密钥，ID必须存在于图像的元数据中。最后，应用程序显示加密后的图像，并为用户提供一些分享选项。

示意图2

如图3b所示，解密工作流程包含三个主要步骤，并在用户每次接收到加密图片时触发。首先，LockPic应用加载该图片，并从元数据中提取图片ID。其次，应用将用户身份认证信息发送至密钥服务器，并提交图片ID以获取其有权访问的区域框的密钥。密钥服务器根据图片ID从数据库中获取该图片包含的区域框列表，并逐一检查用户是否已被授予访问权限。然后，密钥服务器向应用返回用户被授权访问的区域框列表及其对应的解密密钥。最后，应用将这些区域框列表和解密密钥传递给修改后的JPEG解码库。

图片所有者可以随时修改访问权限。用户可以从密钥服务器请求获取为其生成的图片ID列表，以及加密区域框的坐标和当前被授予访问权限的用户。他们可以向现有区域框中添加新用户或删除现有用户，但无法创建新的区域框。

根据当前API，当用户需要修改或删除现有区域框，或创建新区域框时，应用程序需要请求一个新的图片ID。

密钥服务器根据图片ID和用户ID向用户提供加密/解密密钥，因此第一步是能够针对密钥服务器对用户进行身份验证。我们使用谷歌账户进行身份验证，以充分利用谷歌生态系统。通过这种方式，用户的认证由安卓操作系统和 Google应用引擎透明地管理，我们在其中部署了密钥服务器的实例。

5 结论和未来工作

LockPic应用已实现为一个原型，用于展示Clibrary在JPEG图像的加密/解密与编码/解码同时进行方面的功能。我们已发布该应用和密钥服务器的源代码，以证明我们方法的可行性，并帮助他人在此基础上开展工作。

关于未来工作，我们希望探索其他架构、认证流程和密钥分发方法，这些方法可以在不需要在线密钥服务器的情况下运行，并将我们的功能集成到消息应用程序中（例如Telegram）。我们可以采用一种混合方法，其中用于加密每个区域的对称密钥使用预期接收者的公钥进行加密。该场景中的挑战将是优化用于编码加密密钥的元数据大小。我们还希望扩大本研究的应用范围——将加密模块作为独立的C语言库发布，并将应用程序发布到其他操作系统上。另一个在本文中尚未解决的重要问题是如何跟踪谁在访问您的图片。我们认为，我们的方法可以轻松地进行调整，通过解密密钥的发放情况来提供更清晰的图片访问记录。然而，这将需要对客户端和服务器端都进行修改。

加密/解密密钥管理

除了提供适当的安全性和高效的实现外，一个重要的挑战是妥善管理系统中使用的所有加密密钥。我们提出了一种集中式方法，将所有密钥存储在受信任的密钥服务器中。

服务器必须能够唯一识别图像，以便为每张图片及其各个区域生成唯一的密钥。正如我们所提到，密钥服务器会为每个受保护的图片随机生成一个唯一标识符，并在加密时将其发送回LockPic应用。该唯一标识符将包含在加密图片的元数据中。另一种方法是使用图片的哈希值作为ID。但使用哈希作为 ID的问题在于，哈希运算必须在移动应用中进行，这可能是一项开销较大的操作，具体取决于图片的大小，并且在发生哈希碰撞的情况下可能带来安全问题。

更重要的是，密钥服务器将能够分析某些使用模式，因为它可以识别出两个不同用户是否加密了同一张图片。

如前所述，密钥生成过程在服务器端执行。我们最初的方法是为每个受保护的区域生成一个独立的密钥每张图像都会如此。然而，这带来了一些问题，因为随机数可能需要快速生成，随机数生成器（RNG）可能会成为瓶颈。同时，密钥存储的大小也难以估计，因为它会随着受保护区域数量的增加而成比例增长。由于必须为不同区域使用不同的密钥，才能实现对区域的细粒度访问控制，因此我们采用了以下方法。

对于每个用户 U，在首次访问时会随机生成一个主密钥 MSU。对于每个需要加密的区域，将该主密钥与图片标识符 ID 以及该区域的坐标 r={x0, y0, x1, y1} 进行拼接；随后对该比特字符串应用安全哈希函数，其输出即作为该区域的加密密钥，即
keyU,ID,r= hash(MSU ‖ ID ‖ x0 ‖ y0 ‖ x1 ‖ y1)
这种设计的主要优势在于每个用户仅使用一次随机数生成器（RNG），并且密钥服务器管理的密钥数量与用户数量成线性关系，因此与图片数量或加密区域框的数量无关。

B LockPic应用

LockPic应用采用非常简单的用户界面，提供三种不同选择：加密、解密和我的图片。第一种选择会触发加密机制，系统会提示用户从图库中选择一张图片，并要求选择需要保护的区域。受保护区域（图4a）的选择可以手动完成，即在目标区域上放置一个区域框，并通过拖动右下角来调整其大小。另一种选择是依赖Android人脸识别API，以在检测到的人脸上自动生成区域框。无论哪种方式，都可以通过单指操作轻松重新排列和调整区域框的大小。

示意图3