CipherCloud如何进行同态加密？

#1 楼

我找不到任何指向同态加密的证据。我可以找到的是确定性加密和格式保留加密的不同组合。

这篇文章是基于CipherCloud网站上CipherCloud云安全学习中心-精选内容上发布的材料。 CipherCloud指出，实际产品具有附加的加密功能，这些功能可提供更强的安全性，并且不会受到所列漏洞的影响（请参见CipherCloud响应部分）。

材料1：白皮书“安全最佳实践”中的屏幕截图您的
Salesforce，Force.com和Chatter中的客户数据在第10页：

[由于DMCA请求而被删除的图像]

描述：此屏幕快照在三列中描述了联系人详细信息（姓名，地址，电话等）。


第一列显示了确定应如何加密不同字段的策略。对于大多数字段，这是“ AES加密加密”，对于某些字段，例如电话号码，它是一种特殊的加密形式，例如“电话号码加密”。
第二列显示明文（“经授权用户看到“）
第三列密文（“未经授权的用户所见”）

分析：当字段由几个部分组成（例如firstname和lastname）时，他们将其拆分为这些部分，分别加密它们。

某些重要字段（例如“年收入”）根本没有加密，可能是因为它们需要在计算中使用它。

加密用于名称和地址的单词的长度和空格的位置都保留下来。单词之间有特殊的标记，似乎标记了加密的部分和单独的标记。

保留长度强烈暗示确定性加密，支持搜索也是如此。从理论上讲，可以对不同的记录使用差值随机数，但我认为这不太可能，因为在这种情况下很难保留搜索索引。

材料2：功能列表来自同一份白皮书（第11页）：


加密选项：AES-256，功能保留加密，长度限制加密等。能力
选择逐场分析


分析：在材料1中已经观察到相同长度的加密。大概是保留了函数的搜索和排序。可能可以在每个字段中选择要保留的功能。资料3将演示一种加密形式，该形式可以搜索，但似乎无法保留顺序。

材料3：CipherCloud Connect AnyApp演示视频大约在2:30和3:00：

[由于DMCA请求而省略了屏幕截图]

描述：这显示了一个典型的留言板，它是yammer Web应用程序的一部分。有两个打开的窗口显示相同的线程。一个显示加密的消息（如yammer.com服务器所见），另一个显示通过CipherCloud访问时的纯文本格式。邮件正文是加密的，用户名和发布时间未加密。加密的消息混合了亚洲字符和ASCII字符。

分析：

明文单词和密文标记之间有明确的对应关系。每个令牌以zqx1开头，以0j1xqz结尾，并对应一个单词。标点符号根本没有加密。

在纯文本中多次出现的单词（例如meet，to，want）在密文中显示为相同的令牌。

单词new和will甚至更有趣。它们以小写和大写形式出现。 New的加密形式可能看起来像zqx1賓翡祀徠鈞祁記勤机琦芸稶70j1xqz 1，new的加密形式看起来像zqx1賓翡祀徠鈞祁記勤机[linebreak]20j1xqz2。

所以我假设令牌的第一部分以不区分大小写的形式对单词进行编码，第二部分提供外壳信息。席德在他的帖子中也发表了同样的看法。这种加密形式允许他们在视频中演示的不区分大小写的搜索，其中搜索apac会出现一条包含APAC的消息，因为单词的开头是相同的，无论大小写如何。这肯定看起来像小写单词和令牌的第一部分之间的1：1映射。

令牌的第一部分似乎具有9个亚洲字符的恒定大小。给定大量这样的字符，足以编码128位或一个AES块。因此，一种可能的实现方式是在ECB或CBC模式下使用具有恒定IV加密单个块的AES。但是，此段纯属推测，无法从我们所做的有限观察中得到证明。

这种方案的固有缺点是它不提供语义安全性。如果在不同位置对同一单词进行加密，则攻击者可以看到在两个位置都使用了相同单词。如果他能找出其中一个，他也会自动知道另一个。

攻击者还可以对令牌使用某种单词级频率分析。一旦部分密文已被恢复，已知单词将用作进一步猜测的上下文。一旦超过某个知识阈值，这应该可以恢复大多数单词。因此，本质上是防止攻击者学习任何（密文，明文）对，即使对于无害的消息也是如此。引用公共材料或存储草稿，这些草稿随后将要发布也很危险。

类似的不确定性方案

以上方案本质上是词级替换密码。古典替代密码通常使用单个字母（或少量固定数量的字母）作为替代单位。诸如AES之类的现代分组密码通常允许使用整个单词作为替换单位，这在没有计算机的情况下是很难做到的。

那些早期替换密码与上述方案具有类似的弱点（1：1映射）字母，确定性加密和频率分析之间）。当然，对于短/字母单元，这些弱点比长/字单元更明显。

用于减少这些弱点影响的一种技术是对每个纯文本单元进行多种可能的替换，并随机选择一个在加密过程中。此技术称为同音替换。显然，该技术也可以应用于单词级替换密码。

当单词有可能的密文时，仍然可以通过对加密数据触发n个单独的搜索并将结果合并来进行搜索。这会将1：1映射以上转换为1：n映射，使加密变得不确定，并且根据所选的概率分布，频率分析的效果也可能不太好。当然，这样的组合搜索将向服务器泄漏一些信息，关于该信息哪些密文单元可能对应于相同的明文单元。

没有证据表明CipherCloud使用同音词替换密码。我之所以仅提及此方案，是因为它是对上述方案的最简单的更改，并且与DMCA通知中的声明并不矛盾。由于“正在申请专利的机制”，Ciphercloud声称不会遭受上述弱点的困扰。我当然希望他们的机制比单纯转换为谐音词替换密码更好。

CipherCloud在DMCA中的声明通知：

与该分析相对应的是DMCA通知中提出的一些主张：


这样的虚假，误导和诽谤性陈述包括以下示例：

（2 ）“如果在不同的地方对相同的字符串进行加密，则攻击者可以看到在两个地方都使用了相同的字符串。” [此帖子的旧版本声明]
*同样，CipherCloud的产品也不是确定性的。

（4）“如CodesInChaos在先前的回答中所建议，这使解决方案极易受到以下攻击频率分析攻击。” [摘自AdrenaLion的帖子]
*所引用的方案不代表CipherCloud功能。实际上，CipherCloud具有可克服频率分析攻击的正在申请专利的机制。

（7）“基本上，它们最终以小写单词的1：1映射结束。” [Sid的帖子，指的是此帖子中讨论的留言板]
＊该声明显然是错误的。 Sid暗示从公共演示中看到的是CiperCloud的产品。 [我的重点] CipherCloud不包含1：1映射。


（DMCA通知中包含10个示例语句，我选择了与该帖子最相关的那些语句。我插入了引用链接的注释链接）对原始帖子的声明）

结论

观察到的加密具有明显的弱点，其中大多数弱点是一种方案固有的功能，该方案希望在使原始应用程序执行操作的同时对数据进行加密例如在不更改该应用程序的情况下对加密数据进行搜索和排序。可能有一些高级技术（同态加密等）可以避免这些弱点，但至少视频中演示的软件没有使用它们。

我认为将DMCA通知中的声明与观察到的加密属性进行协调的唯一方法是，实际的CipherCloud产品与促销材料中显示的产品显着不同（并且更好）。

不想根据他们发布的有关其产品的信息进行判断，也许他们应该更新其材料以使其更接近实际产品。

CipherCloud响应

CipherCloud在他们的博客上发布回复：回应关于CipherCloud加密技术的神话对CipherCloud是否使用同态加密的问题有了一些澄清。答案是不。由于性能和功能不足，同态加密还远未准备好实际使用。

董事会线程中引用的CipherCloud产品演示着重于向使用云应用程序的组织强调我们为云信息保护提供的反向代理概念。禁用了一些可用的基本安全功能（例如，全域加密，通过IV进行随机化等），因为在我们的专利仍在申请中时，我们不愿意在Internet上共享此类IP。



1实际的亚洲字符与我的帖子中的字符不同，但一般形式相同。2换行符是浏览器显示文本的人工产物。它可能隐藏了一些字符。

#2 楼

我认为他们根本没有实现同态加密。他们刚刚实施了常规的AES加密（他们的AES拥有FIPS 197证书），但是这种方式似乎非常不安全。他们为什么选择这样做？因为他们别无选择。我的意思是：

具有轻量级架构（不需要数据库，存储需求小）的云加密提供商（如CipherCloud）面临的挑战是，他们需要后端SaaS应用程序（Salesforce，GMail）等），以便可以对数据执行所有搜索和报告功能，就好像它们是纯文本格式一样。为了使之成为可能，您必须确保相同的字符串每次都以相同的方式进行加密。正如CodesInChaos在先前的回答中所建议的那样，这使得该解决方案极易受到频率分析攻击的攻击。

但是SaaS加密实现存在一个更大的问题。搜索精确匹配是一个容易解决的问题-只需将匹配的加密值发送到SaaS应用程序即可。但这不是您需要支持的唯一搜索类型。如果用户搜索以John开头的所有名称，会发生什么情况？ （例如“ John *”）（至少）有两个选项：第一个选项是在加密设备中存储到以John *开头的每个字符串的每个实例的映射，然后为每个字符串发送加密文本的所有实例。将与John *匹配的字符串映射到SaaS应用程序，以便它可以执行搜索。如果有很多以“ John *”开头的字符串，这将成为问题-您必须将所有匹配的字符串发送到SaaS应用程序才能进行搜索。但是想象一下搜索John * + Jon * + Jame * + Smith *。您可能很容易用完查询参数。运行报告时甚至更糟。

您还必须在加密设备上具有映射基础结构（数据库将是企业级的方法）才能完成此工作，但是CipherCloud似乎不需要数据库，因此在这种情况下不太可能使用此方法。而且，CipherCloud似乎没有使用这种方法，就像从其公开文件中看到的那样。

但是他们可能实现了更糟糕的方法，因为解决搜索“ John *”的第二种方法是他们似乎确实做了。此方法在密文中保留字符串顺序，例如John成为XXyzzz，Johnathan是XXyzzzAAddBBaaBB，Johnson是XXyzzzDdffsss（这不是他们的算法，仅表示净效果。）这样，搜索John *意味着我只拥有发送“ XXyzzz *”到SaaS应用程序以正确执行搜索。但是这种方法大大削弱了数据的安全性。这是因为一旦我推断出John是XXyzzz，每当我看到以这些字符开头的字符串时，我就知道它是某种形式的名称“ John *”，并且我真的可以开始攻击数据了。 CipherCloud声称使用AES，这应该不会出现此问题，那么他们如何使用AES保留此字符串顺序？好吧，第一件事不是使用填充，也不是在所有地方都使用相同的填充。 kes！第二件事是对所有字符串使用相同的IV（初始化向量，也称为随机数）。又！没有填充和IV分集，AES成为XOR的美化版本。谁敢打赌他们的数据安全呢？ （这可能解释了为什么他们没有FIPS 140-2验证，甚至没有获得该验证的原因，这与正确执行已批准算法有关。）

CipherCloud解决方案的最新演示似乎在密文中使用了多字节字符，这使模式很难用肉眼看到（好的，过去用来解析西方字符集的眼睛），但是对于计算机来说，破解起来就不难了。

我不确定他们是否还在那里，但是过去在Vimeo和Youtube上有一些很好的有关他们的解决方案的视频，因此您可以看看这些并亲自了解我在谈论。我相信您也可以从他们的网站下载白皮书。我将它留给其他人来真正地挖掘可用数据并弄清楚他们的工作方式，但是值得任何调查人员提及的是，CipherCloud似乎也保留了明文形式的某些标点符号。 （我看到一个实例“ I”被加密，并且保留了撇号！）

一如既往，但是对于安全产品，Caveat Emptor则加倍！如果您正在使用CipherCloud或任何SaaS加密解决方案，则最好提出很多具体问题，并确保答案清晰明确。

#3 楼

我已经有一段时间没有发布消息了，事实上，与我的Stack Exchange帐户绑定的电子邮件不再存在，我忘记了StackEx密码，不得不创建一个新帐户。 （我将由读者决定这是否是真实的我。）

但是我确实只想在这里跟进，因为在我的上一篇文章和其他人的后续帖子。自从我写了以上文章以来，我一直在想自己如何从安全的角度来看，这种可搜索的加密实际上如何工作而又不会令人难以置信的弱。碰巧的是，我在本周参加Ciphercloud的RSA Security 2013大会上。在两次会议之间，我有时间参观他们的展位以了解更多信息。

他们确实声称做过“军事级加密”，而且看来他们可以使用第三方FIPS 140-2加密模块。但是，在演示中，我得到了他们在SalesForce设置中加密数据的演示，该加密肯定不是在使用FIPS 140-2或其他方法。实际上，我可以在他们的大型演示屏幕上看到我期望使用其加密算法看到的确切问题，以及使我摇头的一些事情。

例如，事实证明它们确实在密文中保留了明文模式。如果到处都以相同的方式（例如“ XXyyZ123”）进行加密，则搜索“ John”很容易。但是它们似乎也可以单独加密字符串中的每个单词，例如您在“帐户名称”字段中看到的那样。我知道这一点是因为他们展示了明文和加密帐户的并排比较示例。名称中有两个带有“ United Oil＆Gas”的帐户。两个加密的名称都相同。这意味着他们使用相同的密钥，现时（IV）和帐户名称填充。由于加密的全部目的是促进密文中的随机性，因此这是一个非常弱的非随机实现。您会将数据委托给XOR吗？我肯定不会。

但这是令我头疼的部分，主要是因为几乎需要零加密破解技能才能确定数据的真实价值：它们似乎有问题，由于某些原因，我无法完全理解字符串中的标点符号。在他们向我展示的示例中，“ United Oil＆Gas”被加密为诸如“ fgt ^ e3s3 SD72d＆3edf”之类的文件（注意：它们也具有包装其加密字符串的前缀和后缀，但是由于它们出现了，所以我没有包括它们）保持一致，并且可以在那里将字符串标识为已加密，但是不会保护数据。）

因此，如果您要寻找一个名为“ United Oil＆Gas”的客户，您可以采用一种非常简单的方法来缩小可能的记录范围-只需搜索“＆”字符，然后将结果缩小到它出现在第二个和第三个词之间。然后，在该列表中，查看名称中的单词长度，第二和第三短字符串是最好的选择。这部分是因为在“伤亡与生命联合”中，“伤亡”一词的密文要比“石油”一词更长。 （请记住，它们使用相同的填充使所有内容都可搜索。）最重要的是，加密并没有真正保护此处的数据。成本无济于事。

但是情况变得更糟：一旦您知道“ United”，“ Oil”和“ Gas”中的每个词都有密文，您就可以搜索以下内容的匹配项：这些密文模式，您将知道其中包含这些单词的所有帐户名称（也许还有其他所有字段），以及这些字段在这些字段中存储的多单词字符串中的位置。

但是，情况可能更糟：您甚至可以基于已经衍生的单词来衍生新单词。这是因为对于这三个明文单词，您现在知道以这些字符串开头的任何单词的密文模式。 （完整披露：这是我在猜测的地方，因为向我演示的那个家伙无法告诉我他们使用的AES模式。我假设它们使用的是CBC之类的东西，并且它们仍以16位块进行处理-每次使用两个字符。）使用CBC，相同的键，随机数和填充将保留单词开头的字符串模式。因此，“ United”，“ Un”将共享两个共同的字符模式以开始其密文，而“ United”和“ Unit”将共享前四个字符模式。因此，如果派生“ United”，则可以找到任何以“ Unit”，“ Un”等开头的单词。

使用我在RSA的Ciphercloud展位上看到的示例，您可以使用该模式保存来查找带有“ United”，“ Oil”或“ Gas”一词的任何其他帐户，以及以该词开头的任何单词字符串，例如“ United”，“ Oil”或“ Gas”。

现在，我知道这是一个演示，展示它的那个人可能是一个没有安全概念的营销人。但这是2013年的RSA Security展会。像我这样的人会看到您，这些人对加密知识了解一两点，并在次充好东西上戳破了漏洞。我还要说，在他们的辩护中，这些表演由其市场部门协调，并且可能没有最新的演示材料。因此，也许他们可以展示出对我或任何安全专家都满意的产品的更好（更新）实施。

但是事实仍然是他们没有。在美国最大，最有影响力的安全展会之一上，即使不是世界范围内，您也不应为示威作准备，而这很容易被击败。

#4 楼

他们没有使用任何外来加密。实际上，基于数据，在将纯文本数据的大小写降低后，它似乎只是1：1映射（标记化）。我对其他人一无所知，但对我来说，当我观看演示视频时，这种模式就显得突出了。要亲自观看，请查看他们的公开演示视频。点击高清，全屏播放到2:19。您会发现相同的明文单词都具有相同的密文（例如：“ to”）。如果明文仅在大小写上有所不同（例如：“ New”和“ new”），则密文的唯一区别是在末尾，其中大小写不同似乎已编码。

基本上该方案以小写单词的1：1映射结尾，并在末尾进行大小写编码。因此，它们是否绕着银河系，吸收恒星的所有能量，执行AES256或只是旋转位都没关系。在一天结束时，只有小写单词级别的1：1！因此，您可以将整个“加密”对话运行到统计分析器中，并根据常规英语单词的频率发现1：1映射。如果添加存在单词级别模式的逻辑（“ The the”非常罕见而“ extra extra”），即Markov链建模-那么您需要更少的“加密数据”副本即可剥离安全性。

请注意，此映射对于他们在营销文档中描述的搜索和排序功能至关重要。为什么？因为根据定义，搜索依赖于搜索词（“ john”）和搜索空间（“ ann”，“ beth”，“ john”和“ zoe”）之间的固定关系。如果无法将“搜索约翰”映射到“搜索空间约翰”，则因为找不到自己的搜索命中而找不到它。

我个人更喜欢这样的令牌化方案进行传统加密，因为


对我而言，1：1映射没有安全性。忘记映射只是能够直观地看到数据中的模式（无论是肉眼还是通过程序），都会泄漏信息内容，因此是安全漏洞。否则将不允许=>引入新的公司安全漏洞
如果购买网关盒/维护的额外开销伴随着此类安全漏洞，那么这将浪费组织的金钱和时间
供应商锁定-除非他们提供了迁移工具，它们的设备/网关是唯一知道这些1：1映射的工具，因此您的官方升级和数据提取路径将需要您自己执行频率分析（即黑客入侵）。

更新：


作为对DMCA通知的回应，StackExchange临时取出了该答案（以及整个主题的其他地方）中使用的图像。因此，我将答案改写为在没有该图像/链接的情况下仍然有意义。
所有信息均基于可公开获得的数据，并在美国版权法的指导原则之内使用。这包括但不限于版权法-美国法典第17标题第107至119条。这还包括但不限于合理使用原则。
虽然很明显，但以上信息完全基于我的安全知识，安全科学的最新水平以及对质疑自己。它们不反映我的妻子，孩子，朋友，雇主，公司，任何东西或任何其他人甚至本人的信念，除了具有安全知识的个人的信念以外，出于纯粹的技术讨论目的一个技术问题。除了自己的个人能力和个人的技术能力，我在这里不代表任何其他方。

#5 楼

我还观看了该视频（感谢Sid提供的链接），观看该视频后，它揭示了Ciphercloud似乎用于保留搜索的其他方法。似乎没有任何形式的同态加密实现。

输入John的响应并加密后，我抓拍了一个屏幕的副本，并在下面附加了一张图片（为粗体突出显示表示歉意） ）。在约翰的帖子中先看“见面”一词，然后在索菲的第一篇帖子中看“见面”。字符串“ meet”的密文模式在两者中是相同的，如果要通过对用户输入“ meet”的输入进行加密并将密文发送到云以实际执行搜索来执行搜索，则这是必需的。

我还没有时间充分探讨这一点，但是请注意，在“聚会”中，连字符以密文形式清晰保留。我怀疑这是因为需要启用对“ up”一词的搜索，这基本上需要将IV设置回其静态值之一，例如“ meet”被加密时使用的静态值，或者也许是那个（假设还有用于加密“ up”的其他实例的任何其他IV。这是确保后缀“ up”将匹配“ up”的单数实例的唯一方法。

我没有突出显示它，但是您还可以看到诸如问号之类的标点符号被保留了下来。同样，如果要对“ meet”执行精确匹配搜索，则需要去除多余的字符，因为“ meet？”的密文是？会与“会议”不同，因此搜索不会返回人类期望的结果。

[由于DMCA请求而删除了图片]

但是，从安全角度讲，这里的含义是，如果我能够清楚地看到标点符号（例如连字符），并且密文中的模式保留非常关键，以至于我必须剥离（然后揭示！）尾随的标点符号，那么攻击者就可以了提供了打破加密的先机。如果您不提高密文的随机性，那么就不加密。 Ciphercloud似乎在做的事情不是随机的，因此不是真正的加密，当然也不是同态加密。

因此，原始问题的答案是Ciphercloud没有在做同态加密。 />

#6 楼

我不知道CipherCloud是如何工作的。但是，一个相关的问题是：如何以一种可以实现这些目标的方式来加密数据库中的数据？为了实现该目标，目前已知的最佳加密技术是什么？

碰巧出现了这个问题。看一下CryptDB，这是由MIT研究人员构建的系统，用于加密数据库中的所有数据，同时仍然允许您的应用程序操作数据。在他们的系统中，应用程序可以对加密的数据执行SQL查询（即使已加密！），并对数据进行一些有限的计算。

CryptDB使用了由开发的技术组合密码学家在过去的一两年中，实现了这些目标。他们表明结果是可行的，具有良好的性能，并且能够与现有系统（如phpBB）一起使用。这是一个出色的系统，并且是该领域的重大进步。请阅读他们的研究论文，以获取有关其工作方式的更多信息：



CryptDB：使用加密查询处理保护机密性。 Raluca Ada Popa，Catherine M.S. Redfield，Nickolai Zeldovich和Hari Balakrishnan。 SOSP2011。

总而言之，CryptDB中的技术是Ciphercloud应该做的。我不知道Ciphercloud是否实际上正在这样做（您必须问Ciphercloud这样），但是CryptDB代表了该领域目前的最新状况。

#7 楼

CipherCloud的网站在2013年9月21日之前明确声明CipherCloud不使用同态加密。
这也表明CipherCloud在任何客户部署中均不实现1：1映射或ECB模式。其他声明还承认CipherCloud的早期演示是这样做的，它引用了说明功能，尚未实现的功能以及避免公开尚未获得专利的技术的必要性的意愿。
我还看到了CipherCloud现在，对于其法律小组提出的DMCA移除通知的某些令人寒意的效果，我们表示“完全道歉”。
我渴望看到比“云信息保护公认标准”更精确的功能描述；尤其是对于数据库应用程序前面的（反向）代理设置，对没有1：1映射的加密术语的可搜索性有什么限制（如果有的话）。
Ciphercloud的常见问题解答将于10月17日发布， 2013表示它进行了逐字加密以支持搜索：


CipherCloud如何仍可搜索加密数据>

CipherCloud对粒度级别进行了精细控制特定信息的加密和搜索能力。可以使用行业标准AES 256位加密在每个字段或每个单词的基础上对数据进行加密。

#8 楼

与此相关的是，IBM拥有一种同态加密方案的专利：美国专利＃8,565,435，“高效实现完全同态加密”。

考虑到IBM在同一个领域竞争，我敢打赌IBM并未将该技术许可给竞争对手。

这并不意味着CipherCloud没有发明自己的同态加密方案。但是我怀疑从IBM获得CipherCloud许可的机会要比发明CierCloud发明HME或SWHE方案的机会更大。 （但谁知道，也许CipherCloud的研发可以与IBM Research匹敌）。