我想审核如何使用以下给定的问题数据真正执行加密算法的实现:


加密机制是可逆的(这不是签名),
该算法假装为AES,但可能正确执行或不正确执行,或更糟糕的是,
密钥未知(在我感兴趣的情况下,我想检查所有文件已被正确加密,但我可以使用专门设计的加密算法),
我无法访问源代码。

至少我希望能够检测到该文件未加密。
接下来,我希望能够检测到RNG是在很小的范围内运行还是不是随机运行。

在第一种方法中,我认为分析加密文件的随机性:平均值+标准偏差(使用ent之类的工具)。
但是我立即想到了具有完美平均值的人工文件
和标准偏差是完全规则的,而不是任何加密的结果。
然后我的第一种方法是错误的。

我进行审核的环境是Unix。
(我无法使用无法阅读,编译和检查自己的工具或算法。 )


实际案例:


我想检查我的iPhone是否正确加密,以及从一个常量派生的AES密钥是什么? ,我的密码,一个硬件uniq标识符。
我想对所有要求我对他的专业iPhone进行相同验证的工作人员进行相同的iPhone验证。这是一项针对用户的服务,旨在为他们提供对他们认为已加密并且必须加密的内容的信任。


评论

如果要审核的是真实事物,则数据必须是真实的。因此,它必须具有您可能需要的一些随机特性。还是没有它们。还是只加密一个时间垫/ TRNG输出?

注意,根据定义,“加密”是可逆的。否则,它称为“散列”或“签名”。

您可以访问执行此操作的二进制文件吗?这使得可行,但要花很长时间才能找出真正发生的事情

如果您可以这样做,那将是一个巨大的安全漏洞。说您知道消息是“是的,在黎明时发动攻击!”或“不,请勿攻击!”。如果您提出的测试存在,它将以一个纯文本通过,而以另一个纯文本通过。但是您不会知道攻击者不知道的任何内容,并且可以解密数据!

通常来说,错误的实现方式可以成功进行攻击。因此,一般而言,审核包括执行已知攻击并查看它们是否成功。 (当然,如果算法未知,则必须对所有可能的算法都这样做。)

#1 楼

如果您至少在某些示例用途中无法访问该密钥,则无法确定。例如,如果您无权访问密钥,则不可能将AES-128与AES-256区分开。这对于任何加密方法都是如此:在不知道密钥的情况下,您无法将密文与相同长度的随机数据区分开。通常,您无法通过某些管理界面访问这些密钥。

您可以进行统计测试,但这只能告诉您加密没有被完全破坏或跳过。

如果您的供应商不完全不诚实,并且声称使用了AES,则可能使用了AES。与不使用AES相比,更常见的问题是使用AES错误。在这里,您也不能确定它们是否正确,但是至少可以检查一些常见问题。

检查密文的长度如何随明文的长度而变化。密文应包括一个初始化向量和一个身份验证标签,通常每一个都增加16个字节。如果密文不比明文大32个字节,则可能是错误的,但是在某些情况下可以这样做(例如,对于磁盘加密,其中扇区号用于构建唯一的IV,并且不需要进行身份验证)。 />
在不同条件下传递相同的输入,并确保生成的密文完全不同。如果可以安排使用同一密钥对多条消息进行加密,请确保相同的消息导致完全不同的密文。这可以验证是否生成了初始化向量,如果初始化不正确,则至少是愚蠢的。

如果您有办法提交修改后的密文,请执行此操作,并检查它们是否被拒绝,并出现通用的“无效密文”错误,而不是由于内容无效而导致的特定错误。这可以验证是否使用了经过身份验证的加密。在没有威胁的情况下,有些威胁模型是可以的,但是您需要非常小心。 (与使用非加密随机生成器生成密钥,然后将密钥的副本写入不受保护的位置相反。)您只能通过查看系统的行为来进行审计。

评论


$ \ begingroup $
最后检查时,我使用了canari方法:一个巨大的密钥(128 U字符串),并且在没有太多空闲空间的系统上进行加密过程期间和之后,我运行了grep canari / dev / kmem。您对这种方法的批评分析是什么? (也许足够有趣,可以提出另一个问题?)。
$ \ endgroup $
– dan
19年8月5日在23:53



$ \ begingroup $
如果您知道如何检测电子密码本,则可以大大改善。
$ \ endgroup $
–约书亚
19年8月6日在1:02

$ \ begingroup $
@dan我不明白您所说的“一把巨大的钥匙(一串128 U)”是什么意思。 AES密钥为32个字节,您说您无权访问该密钥。
$ \ endgroup $
–吉尔斯'所以-不再是邪恶的'
19年8月6日在8:32

$ \ begingroup $
@dan您在其中输入密钥的GUI?真的很奇怪人类永远都不会看到密钥。密码与密钥完全不同。
$ \ endgroup $
–吉尔斯'所以-不再是邪恶的'
19年8月6日在9:18

$ \ begingroup $
@leftaroundabout确实,这是与随机性的不可区分性,它比密文不可区分性强。我正在简化。实际上,在随机数/ IV中,对称密码确实表现出与随机噪声的区别。这是因为,如果不包括IV和认证标签的密文与明文具有相同的大小,则不会有噪声不能成为密文。
$ \ endgroup $
–吉尔斯'所以-不再是邪恶的'
19年8月7日在13:26

#2 楼

除非文件具有表明已加密的明文标题,否则无法将密文与统一随机数据区分开。您可以试探性地猜测一个文件,如果它绝对没有结构并且看起来完全是随机的,则将被加密,但是您不能确定地证明它。

任何可以区分输出与随机的密码都将被视为损坏。

评论


$ \ begingroup $
我不能相信纯文本标题(作为魔术数字),因为它可能被伪造。
$ \ endgroup $
– dan
19年8月5日在15:55

$ \ begingroup $
好吧,gpg --encrypt和gpg --sign甚至gpg --store的标头之间没有什么区别,它们都是带有非常相似的标头和相同ASCII装甲的OpenPGP消息–您不容易分辨通过查看哪个被加密而哪个未被加密。 (提示:后两个不是。)
$ \ endgroup $
–user1686
19年8月6日在6:07



#3 楼

除了其他答案已说明的内容外,使用AES-256(不选择块模式)的“适当”加密仍然可以允许后门,例如通过恶意选择IV /随机数。菲尔·罗加威(Phil Rogaway)和其他人在他们的论文“针对大规模监视的对称加密的安全性”(此处提供摘要)中对此进行了更详细的讨论。

#4 楼

这个问题很容易回答:

实现不正确,您绝对不应该使用它。对这个黑匣子的任何其他态度都是无可厚非的。

您的立场应该是:“我必须能够看到源代码,审核源代码,并将源代码自己构建为二进制文件”。缺少任何事情对您而言都是不负责任的。不要接受其他答案中提出的不安全的半措施。

您不需要要求访问用于加密的密钥,但是您绝对必须能够验证算法是否正确。是正确的,而仅通过观察其输入和输出就无法正确完成。这甚至不仅仅局限于加密-任何程序都可以具有后门输入,该输入会执行某些令人讨厌的操作,并且根本无法通过外部实验来发现它-但对于密码基元而言,它给您带来的后果要比其他非关键软件高得多。

评论


$ \ begingroup $
我不确定OP是否要使用加密程序;我了解他想审核(可能代表他人)。疯狂的猜测将包括教育或专业任务,其中实际用户无权访问源或假装无权(在教育的情况下)。
$ \ endgroup $
–彼得-恢复莫妮卡
19年8月7日在11:51

$ \ begingroup $
@ PeterA.Schneider我不确定我的答案是否会发生重大变化;唯一负责任的审核结果应为“请勿使用此内容”,无论是代表您自己还是他人的。
$ \ endgroup $
–丹尼尔·瓦格纳(Daniel Wagner)
19年8月7日在13:54

#5 楼

如果您想知道iPhone的加密功能,那么这项工作可能已经为您完成。许多Apple / iPhone产品都已通过正式的FIPS 140-2认证,该认证对您所关心的事情进行了广泛的测试。如果要查看有关哪些产品已通过哪种算法/密钥大小认证的详细信息,请访问NIST的CMVP网站并搜索供应商“ Apple”。苹果公司还在其网站上提供了有关其在各种产品上已完成的安全认证的详细信息。

FIPS 140-2本身专注于加密模块,例如算法实现或密钥管理实践。这足以表明随机数生成器具有足够的随机性,或者他们声称的AES确实是真正的AES。 ,文件系统是否确实对该特定文件进行了加密)。在移动设备上,您自己进行测试将很困难,因为您无法(例如)将硬盘驱动器移植到其他系统上,以读取原始数据并检查纯文本。 Apple的认证页面列出了一些我不太熟悉的其他认证。我建议您查看那些认证计划,看看其中是否涵盖您想要进行的各种测试。毕竟,像Apple这样的公司会花费大量时间和金钱来进行这些认证流程,因此您不必自己进行此类测试。

评论


$ \ begingroup $
👌🏻:谢谢,但是我需要我直接负责的回答(对于我的同事)。我应该能够将其复制为任何科学分析。
$ \ endgroup $
– dan
19年8月8日在11:28

$ \ begingroup $
+:不,这不是我特别热衷于iPhone的加密实现。Veracrypt是我要尽可能证明没有不良作法的另一种产品。
$ \ endgroup $
– dan
19年8月8日在11:35

#6 楼

许多答案指出,您无法做的事情。如果没有密钥X和加密内容的签名,就不可能用密钥X加密某些东西。如果可能,则加密算法将是错误的算法。 AES不适合该法案。

但是,如果您确实处于困境中,则管理层告诉您必须这样做,尽管有证据表明您无法做到,但是有解决方案。分解并反向工程该加密实现,并亲眼确认该特定位组作为Unix可执行文件执行时,已正确加密了数据。这是一项艰巨的任务,但比证明无法证明的事情无限可行。

除此以外,您可能要尝试的步骤之一就是开发威胁模型。例如,如果您可以假设所有文件都以与测试文件相同的方式进行加密,那么您至少可以通过检查加密某些已知明文的结果来做出一些声明。

#7 楼

您是否已为所有这些文件的纯文本版本提供了参考集?可以通过系统从1 kb到1 GB的大小不一的10,000个文件的代表性集合。可以进行测量。 ,您可以尝试使用此密码进行加密,尽管它是新制作的新密钥。看看是否可以将文件大小与可能匹配的4KB或64 KB块等关联起来。 ?还是该密钥存在于您无法企及的地方?如果是这样,您可以根据需要安排打样。

准确知道运行至CPU周期所需的时间非常有用。也许您可以在virtualbox中模拟处理过程并以慢动作运行它,以了解正在发生的浮点运算量。也许尝试在CPU缓存和内存控制器等上发起侧通道攻击。

它可能在具有唯一引导参数的AES硬件上运行。例如,要重新哈希的循环数;或一些初始质数的值等。之后,它在AES硬件上运行。如果您迷失在正确的按键上,这种技术肯定会使它更加困难,因为它实际上可能无法及时发现等。

我认为一般来说,您寻求ZK证明-零知识证明。那是一些很酷的数学。允许人们验证数学运算,但不知道实际情况。