C ^ E —压缩⊕加密

根据您的威胁模型，结合使用压缩和加密会引入安全问题。如果要在加密之前先压缩数据，则应确保不会通过压缩率侧通道泄漏信息。如果不确定是否通过压缩泄漏信息，请不要在加密纯文本数据之前对其进行压缩。

作为S3对象存储，Minio为您提供了一个S3兼容的API，用于存储数据。但是，此外，我们尝试提供企业级数据存储系统/解决方案所期望的功能，例如安全数据加密和数据压缩。但是，有时，如果您组合使用功能，则可能会以意想不到的方式发生严重错误。在本文中，我将描述何时以及为何不将压缩和加密结合在一起是一个好主意，在这种情况下，它仍然可以使用，以及为什么我们决定不压缩加密数据。

首先，我们必须定义威胁模型的外观以及对加密的期望。我们的基本模型如下所示：

此处，客户端通过TLS / HTTPS连接通过SSE-C S3 API将对象上载/下载到minio服务器。服务器采用客户端提供的密钥和对象，并将加密的对象存储在其存储后端。现在，攻击者进入了舞台。目前，我们假设攻击者可以观察到客户端与服务器之间以及服务器与存储后端（如果有）之间的网络流量，并且可以完全访问存储后端的对象数据。我们将此攻击者称为被动攻击者，因为她不与客户端交互或影响从客户端发送到服务器的任何数据。但是，攻击者无法访问客户端或服务器的内部内存，并且不知道纯文本对象或SSE-C客户端密钥。

现在，我们指定对加密的期望。首先，只要您不知道加密密钥，您就不应该从加密对象中学到任何东西，除了它的大小和用于加密它的算法。特别是，这意味着加密对象不会泄漏有关其明文的任何信息。其次，我们期望通过适当的加密方案，攻击者无法解密加密的对象，而无需在解密过程中检测到该对象。我们通过使用现代的认证加密方案来实现这一目标。

在定义了关于整个系统的假设之后，我将展示两种不同类型的攻击，这些攻击使用通过压缩比边通道泄漏的信息。两种攻击都使攻击者可以了解有关加密对象的一些信息，如果不进行压缩就无法学习，并且违反了我们的安全性假设。

检测不相等但大小相等的对象

第一次攻击使用压缩来区分两个相同大小的对象是否包含相同的明文数据。因此，我们假设服务器使用确定性压缩算法压缩所有对象。这意味着在给定相同的输入数据的情况下，压缩会再次产生相同的压缩输出-我所知道的所有压缩算法都是这种情况。

现在，假设客户端将两个对象上载到服务器。两个对象的大小相同-例如5 MB。观察网络流量的攻击者由于TLS而无法了解两个对象的内容，但她可以通过分析流量来近似甚至确定（纯文本）对象大小。然后，服务器对对象进行压缩和加密，并将压缩和加密的数据存储在存储后端。现在有两种可能的情况：

1. 压缩和加密的对象都具有相同的大小。这意味着它们的明文数据相等，或者两个不同的明文对象的压缩产生了相同大小的压缩数据。因此，我们无法对这些对象发表任何声明-攻击者不知道它们是相等还是不同。

2. 压缩和加密对象的大小不同。然后，攻击者立即知道两个对象的明文不同。如果它们相等，则压缩算法会将它们压缩为相同大小的数据-因为我们知道对象的明文大小相等并且压缩是确定性的。因此，由于矛盾，对象的明文必须不同。

但这已经破坏了我们的安全性。攻击者能够了解（某些）加密对象（无论它们是否包含相同的纯文本），而不会破坏加密方案。因此，攻击者使用了一条附加信息：对象的原始大小和压缩大小之间的差。这是通过使用压缩创建的压缩比率侧通道泄漏的信息。

因此，我们已经可以看到加密之前的压缩削弱了模型的安全性。但是，可能有人认为这种攻击对实际情况几乎没有影响。在大多数情况下，区分某些加密对象是否相等不会对吗？

好吧，到目前为止，我们仅考虑了被动攻击者，该攻击者仅观察网络流量并且不与S3客户端或minio服务器进行交互。但是，通过稍微更改设置，我们可以引入可以进行更强大攻击的主动攻击者。

在此设置中，S3客户端向用户（包括可能是恶意用户的攻击者）提供服务。客户端从用户那里获取一些输入，将用户的数据与客户端（不是用户）仅知道的一些数据进行合并，并将合并后的数据作为压缩和加密的对象存储在服务器上。因此，我们更改了模型，以使攻击者可以通过与S3客户端进行交互来控制对象的明文的某些部分。当然，这只是一个最小的例子。该演示设置可能有多种变体，它们更紧密地反映了实际的用例。此处重要的一点是，攻击者除了具有监视功能之外，还可以影响压缩和加密对象的某些部分。

全部/部分明文恢复

第二次攻击演示了活动的攻击者如何通过利用压缩率侧通道来恢复加密对象的某些甚至整个明文。因此，攻击者的目标是学习一些尚未由其控制的明文对象部分的信息。

为简单起见，我们假设用户以及我们的攻击者可以向S3客户端上载任意数量的数据，S3客户端将该数据附加到其自己的64字节长字符串中，并将合并的数据作为对象上载到服务器。此外，我们假设客户端的数据由相同的字节组成，例如64次0xA0。但是，我们的攻击者事先没有有关客户端数据的信息。因此，如果服务器压缩（例如使用snappy算法）然后加密对象，则攻击者可以发起以下攻击来恢复整个64字节长的客户端字符串：

1. 攻击者将无/空数据上载到S3客户端。这将导致客户端创建仅包含客户端数据的压缩和加密对象。在我们的示例中，客户端通过64 x 0xA0安全的TLS连接将对象有效负载发送到服务器。然后，服务器使用snappy将数据压缩为6个字节长的压缩明文，并在将其写入存储后端之前对此6个字节进行加密。

2. Through network traffic analysis the attacker learned that the object’s plaintext is 64 bytes long — even though she has no clue about its content because of TLS. Further, she can recover from looking at the encrypted object that the ciphertext is 6 bytes long. Now the attacker does some experiments with snappy and concludes that if snappy can compresses a 64-bytes string to 6 bytes than the 64-bytes string must contain 64-times the same byte. So the compression already revealed that the client data contains 64-times the same byte. However, our attacker does not know which one.

3. 现在，攻击者再次使用S3客户端服务，并上传1字节长的数据-例如0x00。客户端再次将此数据附加到自己的数据，然后让服务器创建另一个压缩和加密的对象。攻击者将观察到对象有效载荷现在为65个字节长，后端的对象包含7个加密字节。现在，她可以得出结论，snappy无法将其附加字节（0x00）压缩到客户端数据中-否则，该对象将仅包含6个加密字节。她基本上在增加字节的同时重复此步骤3.（接下来她使用0x01，然后0x02，…），直到她在后端看到一个包含6个加密字节的对象。一旦她观察到这样的对象，便知道snappy能够将其字节压缩到客户端的数据中，并且随后她的字节等于客户端的64字节字符串中的所有字节。

这样，攻击者就可以恢复对象的全部内容，而不会破坏加密方案，而仅使用通过压缩比侧通道泄漏的信息即可。当然，这种攻击只能起到很好的作用，因为我做了一些简化的假设，例如客户端的数据仅包含相同的字节，尤其是0xA0。不过，这种攻击在很多实际情况下也可以起作用，但是我们的攻击者可能不得不做更多尝试，使用更复杂的方法，并且可能仅恢复部分明文。例如，针对TLS的CRIME攻击是此攻击的高级版本，如果启用了TLS压缩，则可用于窃取HTTPS cookie。

我们可以解决这个问题吗？

为了完全消除这种攻击，我们必须禁用对加密内容的压缩。更准确地说，我们在加密明文数据之前一定不要压缩它。加密后压缩数据将是安全的，但效果不是很好。安全的加密方案产生的密文与真正的随机位串是无法区分的，因此压缩不能使用数据的任何冗余来对其进行压缩。因此，没有压缩算法应该能够显着压缩安全加密方案的输出。

那么压缩+加密是否完全中断了？

好吧，这取决于您的威胁模型。对于被动的对手，如果不是小型服务器，但S3客户端将压缩对象数据就足够了。这样，被动攻击者就无法通过网络分析来观察原始明文的大小，并且无法利用压缩比副通道的任何优势-因为没有任何优势。因此，必须确保压缩率（原始数据大小和压缩数据大小之差）不会泄露给攻击者。

对于活跃的攻击者，情况要复杂一些。由于她可以在压缩和加密数据之前对数据进行某种控制，因此即使她无法观察到原始明文的大小，她仍然可以学习有关剩余明文的信息。例如，她总是可以观察到她的输入如何影响整体压缩数据。通过改变由她控制的数据部分，她也许能够提取有关未知部分的一些信息。因此，不可能完全防止主动对手模型中的压缩比攻击。但是，它们可能不足以给攻击者带来明显的优势，但这需要对特定情况进行一些分析。

Minio将如何处理压缩和加密

Minio我们竭尽全力为您提供使用擦除编码的数据可用性/完整性以及使用经过身份验证的加密的机密性和真实性的强大安全保证。因此，我们不会压缩任何应在minio服务器上加密的数据。压缩加密数据根本没有意义，而压缩纯文本数据将损害您的安全性。因此，如果要压缩加密的对象，则必须先在S3客户端上进行加密，然后再将其上传到服务器。

我们希望这篇文章不仅对我们的用户有用，而且还可以帮助其他团队和项目找到适合他们情况的正确方法。当然，我们总是欢迎您提供反馈或问题！