中科院补发100多万张弱证书

结果发现,该软件是一组用于生成公钥证书的CA有缺陷的:他们创建的随机序列号只有63位,而不是所需的64位。对外行来说这似乎不是什么大问题,但这一位的变化意味着序列号只有所需熵的一半。这真的不是安全问题;序列号用于防止涉及弱散列函数的攻击,我们不再允许这些弱散列函数。不过,中科院重新颁发证书是件好事。标准的要点是要遵守。

发表于3月18日,2019年上午6:23•26条评论

评论

安德烈·德阿莫里姆3月18日,2019年7:31 AM

在我看来,软件开发周期;

1.规格(软件的作用)
2.第二步。模式识别(数学)
三。算法(规则集)
第四章。代码(描述性语言)

然后检查代码是否符合规范。

关于CA和“1M”,BTC以“20M”开头

;-)

塔塔3月18日,2019年上午9:14

跟随链接,请我觉得这个bug实际上与底层规范有关:

序列号必须是CA分配给每个证书的正整数。对于由给定CA颁发的每个证书,它必须是唯一的(即,颁发者名称和序列号标识唯一的证书)。cas必须强制serialNumber为非负整数。

为什么规范没有说明sn必须是一个无符号的64位数字?或者为什么2的补码表示在这个上下文中应该有意义?

这个问题昨天没有被发现。查到上面的字符串,从2014年起我遇到了一条短线,标题是为什么RFC5280要求CA不颁发序列号为负数的证书?你看!

在90年代克里夫·莫勒尔编写了一份TMW技术说明,描述了Matlab 5中使用的统一RNG。我记得在接受这个RNG所要求的周期性方面有问题,作为IIRC,它似乎与浮点状态向量位的尾数宽度之和有关。然而,由于矢量采用IEEE-754双精度浮点表示法,使用隐含的-1前导位,情况更加复杂。但我假设这个RNG不是为加密而设计的。对于模拟,非均匀分布的利益更大,例如。,正态分布Marsaglia的Ziggurat算法.

浮士德3月18日,2019上午9:18

“63位,而不是所需的64位。对外行来说这似乎不是什么大问题,但这一位的变化意味着序列号只有所需熵的一半。”

不,序列号的熵是63位而不是64位。这不是熵的一半。熵是对可能状态数的对数度量,不是实际的可能状态数。

但这是真的,将位减少一,将序列号的潜在值减少一半,但熵是势能值的对数基数2,所以它减少了1。

苏格兰3月18日,2019年上午9:42

这是一个学究式的语法问题,但不是“随机序列号”自相矛盾?“序列号”应该,根据它的定义,是连续的,传统用法,也是独一无二的。术语“随机”禁止可预测性,因此序列号的顺序性和独特性都是如此。写得不好的文件已经足够糟糕了,但是写得不好的规范是噩梦的主题。

迈克科尔斯3月18日,2019上午11:25

5280确实说:“注意:不合格的CA可以颁发序列号为负数或零的证书。证书用户应该准备好优雅地处理这些证书。”

迈克科尔斯3月18日,2019上午11:28

另外:“鉴于上述唯一性要求,序列号可以包含长整数。证书用户必须能够处理最多20个八位字节的序列号值。符合条件的CA不能使用超过20个八位字节的序列号值。”所以64位没有什么魔力。

弧光3月18日,2019年下午4:16

我对中情局的宽容少了一点。这是那种“你有一份工作”字面意思是他们用一堆钱来发行一组随机数字和有符号文本文件的区域。我觉得我们应该期待他们比其他主要业务是其他业务的公司更尽职调查,比如写软件。

迈克科尔斯3月18日,2019年下午4:28

不符合条件的CA数量令人难以置信。我认为问题是由名称证书*权威*引起的。他们认为他们是证书格式的权威。一家大型中国CA坚持使用BER格式而不是DER。我熟悉的一个德国CA说,可以用不在颁发路径上的证书签署一个CRL。有人告诉我没关系,因为他们收到德国政府的一封信,告诉他们没关系。当然,我们总是处理“整数”在序列号的情况下为无符号。回到最初关于弱证书的抱怨——序列号只需要是唯一的。他们在证书实力方面没有发挥作用。查看hash函数和rsa模的强度。我在野外见过MD5/RSA512。

迈克科尔斯3月18日,2019年下午5:11

我看过CA/BROWSER论坛文档,并且(imho)对(至少)64位CSPRNG的要求是愚蠢的。不发行连续序列号的一个原因是为了防止竞争对手知道你发行了多少证书。但是现在您需要保存一个数据库,其中包含您已经发布的所有序列号,以确保它们是唯一的(5280的要求没有改变)。这些标准没有成人监督吗?

伍迪3月18日,2019年下午5:13

我所知道的最大的CRL(没有做任何特定的搜索)大约有50万个条目。是不是每个crl一百万个,还是100万个覆盖所有的crl?

1&1~=umm3月18日,2019年下午5:40

@苏格兰人:

“序列号”应该,根据它的定义,是连续的,传统用法,也是独一无二的”

虽然你的第二个前提是正确的,第一个不是,即使按惯例也不行(想想钞票)。

总的来说,它的发生是因为它更简单,因此使它们按顺序排列的成本更低。

如果你看一看物理上不可协调的函数(puf),它们被假定为随机的,并且具有如此大的规模/复杂性,以至于基于第一个假设,它们不唯一的概率低于某个阈值,从而使冲突极不可能发生。

戴夫3月18日,2019年8:31下午

比这更复杂,但是你需要读一段非常长的、无意识的、涵盖这一点的废话。序列号不弱,强大,或者别的什么。64位的数字从稀薄的空气中被拉出。没有任何加密参数可以支持它,这只是一个任意的价值,有人发明了。问题是,cab论坛的基线要求表明您必须使用64位,通过对要求的一些解释,一些CA可能没有做到这一点——措辞极其含糊,对许多人开放,许多不同的解释。

因此,问题是,一些CA没有充分证明符合驾驶室基线要求中的任意和含糊不清的要求,不是说有什么安全问题。

1&1~=umm3月19日,2019年上午6:29

@布鲁斯施耐尔:

“这真的不是安全问题;序列号用于防止涉及弱散列函数的攻击。”

你是说曾经被视为,只是一个规范中的“有用的附加字段”,后来被增选/提升为有效地使用“加密nonce”,以改善主要标准中的安全缺陷?

从本质上讲,这是一个避免向后兼容和其他遗留问题的机会,这些问题将由重新发布现有标准引起。这反过来又可以说是由于缺乏远见或知识而产生的。

如果是这样的话,有必要指出这就是事实,以同样的方式,最初的wifi规范使用了研究人员称之为arc4的技术,该技术用于快速破坏的“有线平等隐私”(wep)。又是由于缺乏知识。

如果“一般开发人员”没有被告知规范有问题,并且序列号的使用被提升为“安全功能”,那么这应该只是一个非常短期的临时修复,那么我们就不会看到它像以前那样严重地出错了。这实际上是很重要的,因为“信息被截留”,因此他们在他们的知识和理解范围内做了他们认为务实的事情。

如果没有正确地向他们提供THW信息,我们怎么能期望通用开发人员不只是做出正确的更改,但同时也培养了关于安全的“第六感”知识,从而谨慎对待事物?

这反过来又会使程序员更有可能开发他们的安全相关知识,避免在当时犯错误,而且在未来,类似的情况几乎肯定会再次发生。

在他们的“活到老学到老”中,把它看成是建设性的。在他们一生的学习和发展中快乐。

@戴夫:

“序列号不弱,强大,或者别的什么。64位的数字是从稀薄的空气中提取出来的。”

不,它不是从稀薄的空气中拔出来的,这很可能是基于历史知识和问题的折衷方案,部分原因在于计算机上整数数学的实现可以追溯到20世纪50年代,如果不是更进一步的话。

早在大多数现代编程语言被想到之前,计算机是非常昂贵的,每一位总线宽度数千美元,相关的算术逻辑函数(而非逻辑函数)。

更糟的是,历史上的算术逻辑运算器,因此总线宽度几乎没有或没有“总线宽度”或大小乘数的共性。许多早期系统使用“3位八位字节”的倍数,而其他后期系统使用“4位半字节”,有些人在方便的地方同时使用。其原因是将二进制整数转换回易于处理的十进制近似值,一些早期的CPU实际上有加减指令来专门处理“二进制编码十进制”(BCD)数字表示。您仍然可以看到3/4位划分到今天的传统,不仅仅是在硬件上,如早期的微芯片芯片芯片处理器(12位)和各种IBM以及类似的“大铁”系统(24位和36位)。但在*nix操作系统的许可位中,它的历史至少可以追溯到与“通用综合操作系统”(GECOS)操作系统的古老属性兼容。它来自于通用电气的计算机部门,早在1960年代早期就制造了“大铁”主机,被军方及其支持研究机构使用,包括一些大学,他们是“天才或补贴”GECOS系统,作为“占领市场”营销计划的一部分。

但引起重大问题的还有“有符号整数”数学。有些计算机使用“一的补码”数学,其问题是“两个零”和“两个补码”,其问题是负整数和正整数的“不平衡数范围”,这会给那些编写“扩展数学函数”的人带来很多麻烦。有符号整数这两种类型都有隐式的最高有效符号位,这会导致另一个问题,即“数字范围”实际上比无符号整数将数字范围减半。无符号整数是所有的基本计算硬件实际工作,即使在数学协处理器。负数的概念在大多数ALU和地址总线计算中并不隐含,因此IAX86的“差曼MMU”分段存在问题。

历史上,“有符号”是一个“事后固定”的概念,它不仅使程序设计人员的生活变得简单,而且使程序流程更为“分支”。

因此,“c”在1960年代末由“b”和algol发展而来,必须有效地支持两个总线宽度乘数才能“发挥作用”。这导致了一个“整数数学”问题,我们今天仍然看到它的遗留问题,因为后来的语言通常是用C语言写的。简单地说,整数在“c”中处理得很糟糕,因为采用了“最小公分母”方法。如果你想做你自己的“大整数”,以前是在8/12/16位CPU架构上做32和64位整数的数学运算,你必须编写复杂的代码,因为没有访问“CPU标志”的权限,很容易地使用“溢出和下溢”进行加减/比较。这就导致了乘法和除法的其他问题(不要问浮点,这是另一个附加的程序员的便利,可以增加更多的问题)。

所以“64位无符号”不是“凭空拔出来的”这至少是在“语言可用”的程序员便利性和试图解决标准中的安全问题之间的折衷。所有这些都不必重新发布基础标准,因为基础标准会引起各种向后兼容问题,或者试图发布代码补丁的遗留问题。但主要是在不需要让程序员走出正常工作区或更糟的情况下,打开新一批安全漏洞的情况下,所以创造了更多的补丁等。

戴夫3月19日,2019上午8:51

@1&1~=umm:阅读我引用的讨论主题。有人查阅了所有与此相关的研究论文,却找不到任何有价值的证据。它实际上是为出租车论坛文件做的。

浮士德3月19日,2019上午10:23

布鲁斯:“63位,而不是所需的64位。对外行来说这似乎不是什么大问题,但这一位的变化意味着序列号只有所需熵的一半。”

浮士德:不,序列号的熵是63位而不是64位。这不是熵的一半。熵是对可能状态数的对数度量,不是实际的可能状态数。

时间过去了。没有人反驳我的逻辑。但布鲁斯还是没有纠正。

我把这个博客看作是我们所说的很多东西的试验场。这种情况让我想起了公共政策技术专家的讨论。因为布鲁斯是一个公共技术专家,我认为他刚刚犯了一个严重的错误,用他的陈述来评估熵会误导任何人。别对布鲁斯大发脾气。我认为这表明了专家技术专家的整个概念存在缺陷。

在我的陈述中仍然有可能我是错的,但这似乎不太可能。我是不是很烦人,没人会费心纠正我?我希望不会。我是极少数乐于承认错误的人之一。

假设我是正确的,我认为这些是错误和缺乏反应的交流:

1.成为一名公共专家对成为一名技术专家是有害的。如果你不是每天都在技术的战壕中,你的知识很快就会过时。布鲁斯在90年代写了重要的密码。在某种程度上,他清楚地知道熵是什么。但既然他是一名专家和公众人物,他似乎无法立即获得这些信息,因为他不再关注技术,而是社会问题。

2.第二步。作为专家,人们可能不愿承认自己错了,因为它损害了一个品牌。或者有人可能低估了错误。“对数烟雾算法!你知道我的意思!”.但是,那些来找你寻求专业知识的人可能无法确定什么是真正的,什么是“足够近,可以推到地毯下”。

三。我是一个普通人,我认为专家们更愿意表现得像专家,而不是真正正确。如果专家不真诚地关心他们陈述的正确性,专家就是政治家的另一种风格。

第四章。如果公共利益专家要成为真正有用的东西,至少专家必须谨慎对待事实,快速自我修正,并且愿意传达不支持其政策立场的信息,就像传达不支持其政策立场的信息一样。否则,这只是更多的后真理的B。

再一次,我尊重布鲁斯。我认为我所说的一切都适用于这个时代的所有专家。布鲁斯只是提供了一个强有力的具体例子,说明为什么我对“专家”这个概念不满意。无论它与“执行者”有何不同。

迈克科尔斯3月19日,2019上午10:48

@1&1~=umm:证书中的序列号不参与证书的加密安全。它只是一个用于识别特定证书的数字,以及消除具有相同颁发者名称的证书的歧义,以识别CRL中的特定证书。我必须同意@dave的说法,bab中的序列号要求是基于无知。

浮士德3月19日,2019年12:13下午

@对于所有认为63对64位的问题是一个小问题的人来说

我认为最重要的问题是不符合规范。如果人们不遵守规范,因为他们看不到需求,这就树立了一个坏的先例。没有看到需求远不是安全证据。最终,有人不会看到需要的东西。一些真正重要的东西。

天气3月19日,2019年下午2:23

从1比特到2比特不多,但从64比特到63比特,也许你应该读两本,它们看起来是线性的,但问题出在a=a上,下一个a=a是1.67倍加上这个。T
你可以调一台硬盘,但100年过去了。

1&1~=umm3月20日,2019年1:09 AM

@戴夫:

“阅读我引用的讨论主题。”

很抱歉听起来很挑剔,但你提到了一个线索,但实际上并没有“引用”它,你没有提供唯一的方法来搜索它…

但为了回到这个问题之前已经讨论过了,人们仍然不摸索这个问题。所以,

a)第7.1节中的CA基线要求指出,输出“必须是至少64位的随机性”。

b)在RFC 5280中,他们只半个有用地表示顶部必须为零,当整数位于更大的字段中时,这实际上是不明确的。

尽管如此,EJBCA还是完全无法理解,上面的A&B正确并且默认使用63位+零-这保证了不符合要求的证书。但重要的是,尽管大家都知道,尽管彼得·古特曼(PeterGutman)等其他人曾多次指出这一点,但没有人愿意采取行动。直到“黑暗物质”大灰狼出现。所有人都知道,他们应该憎恨,因为他们是“坏人”,所以轻视和抛弃…所以当某个知名机构开门说“嗨,欢迎坐在桌子旁,人们开始吵吵闹闹,寻找“抛弃”的理由。所以自封的“好人”需要一个借口,可以预见,他们的“大脑处于中立”状态,把罐子的盖子拿下来,低下头,看到各种虫子在白昼的阳光下蠕动出来……机会。

从而说明了基于规则的生态系统的问题,如果按设计,唯一的规则是可定义的和可测试的。因为没有人能编纂“不要作恶”,他们就不能为它制定一个有歧视性和可测试性的规则…

但是回顾一下,我注意到A&B之间的问题在规范发布之前就已经被发现并讨论过了,没有人认为这会是一个真正的问题,所以从另一个角度看。

那么EJBCA应该做什么呢?

好吧,乍一看还不完全清楚,因为大多数没有经验的工程师都是以设计通信协议为生的。规则A规定,任何有效整数的64位必须来自二进制集合,其中每个位可以是零或一。因此,这些64位都不能是符号位。规则B说任何整数的最高位都必须是零,这虽然正确,但只是问题的一半。由于未定义整数的大小,但它所在字段的大小必须至少为x字节,这比64位要大得多。

因此,在一个不确定但足够大的字段中找到一个整数的大小的问题就开始起作用了。从通信理论来看,最简单的方法就是有一个已知的引入标记。通常,由于噪声和同步问题,它将是一个像0111110这样的多位模式,这是一个唯一的只能用于此目的的带内标记(请参阅HDLC通信协议*了解至少回到20世纪70年代的完整解释)。如何在一个可靠的数据字段的情况下,你可以做事情的方式艾伦图灵在他的磁带。你只需从左边开始一点一点往下走,直到你遇到一个标记,我称之为“开始位”,它标志着整数的开始。在这种情况下,这将是一个“一”,因为字段中的所有预处理位都是约定的零。也,按照惯例,有符号整数以符号位开始,正数为零,负数为一,简单性和通信安全性表明,起始位也不能用作数据位,因此下一位必须按规则B为零。所以你的切入点是,在64位的熵前面的“..010”和引入的前导零可以是零或更多,根据约定为零。

所以整数字段的实际最小大小是66位,但在较大的字段大小中,它的前面是66位,所有前导位都是零。

但现代计算机通常至少有,基于8位的倍数的数据宽度。所以如果ejbca能帮上忙的话,

1个,八个字节的随机位,前面有一个固定的起始字节0x02,在字段中右对齐,所有字节的预处理都是0x00。

2个,字段右对齐9个字节,第一个字节,其中两个最高有效位是“10”,后面是六个随机位,后面是八个随机位的八个字节。

不会有问题的。但是,隐藏的事实是,尽管隐含的ASN.1是模糊的,而且ASN.1也是定义通信数据对象结构的标准。此外,专业工程师和密码学家的谨慎,正如彼得·古特曼在2013年1月所说,

“有一秒钟,但是:历史上许多编码器都把整数的签名弄错了,这意味着(a)如果你得到一个负数(至少在加密领域,这是我最熟悉的)它始终是一个编码错误,而不是有意使用负值,(b)由于广泛使用了不正确的编码器,许多解码器将所有整数值视为无符号。所以虽然理论上你可以用负值,这在实践中不是个好主意。”

http://lists.asn1.org/pipermail/asn1/2013-1月/000959.html

*为了了解HDLC和它的奥拉金斯,请看,https://en.m.wikipedia.org/wiki/high-level_data_link_control(高级数据链接控制)

詹妮D3月20日,2019年2:36 AM

这里有一件事始终是错误的:这不是软件问题,这是配置问题。

默认配置,从2001年开始,有64位序列号。但EJBCA软件自2014年4月以来支持更长的序列号-请参阅EJBCA开源版本6.1.1的发行说明.但一般来说,升级EJBCA不会覆盖您的配置——也不应该覆盖它。

cabforum在2017年提出了64位熵的要求。

ejbca在2019年2月更改了默认配置,即就在这件事发生之前。但是,再一次,更改新安装的默认配置不会覆盖任何当前使用的配置。

在任何时候,当CA声称要遵循的要求发生任何变化时,管理员有责任检查他们的配置并进行任何必要的更改。如果他们不这样做,错误不在软件中。

默认配置是否应提前更改?你当然可以证明这一点。但在我看来,这里的主要问题是CA管理员没有在需求更改时验证其CA的运行配置是否正确。

1&1~=umm3月20日,2019年7:09 AM

@浮士德:

“对于所有认为63位与64位问题是一个小问题的人来说”

你想再跑一次吗?

因为我真的认为它没有说出你写它时的想法。

如果64位不是63,那么它是否重要,这取决于你如何看待它。

每增加一位都会使暴力搜索时间加倍,我想我们都可以同意,即使我们知道除了蛮力还有其他的方法。

这就把我们带到了“安全裕度”的问题上,你如何在任何时间点决定在那个时间点什么是足够的,并且从那个时间点开始保持足够的时间,比如说一个世纪之后。

简单的答案是你不能,过去也不可能。历史告诉我们两件相关的事情,首先,人类自身的发展非常缓慢,但是,许多工具的开发正在以一种不可预测但不断增长的速度进行。许多相当于力倍增器。

然而,物理定律告诉我们,实际上有一堵砖墙,我们正朝着这个不断增长的速度前进。理论上,这堵墙是没有办法绕过的,但人总的来说是有创造力的,所以是不可预测的。至于计算机逻辑,我们已经到了这样的地步:我们的电子产品的原始性能在连续处理的砖墙的百分之几以内。所以任何突破都会产生最小的影响。然而,我们也知道顺序处理并不是镇上唯一的游戏。也就是说,在很多情况下,我们都可以并行处理,恰好打破弱散列是其中之一。物理学的基本规则同样适用,因为在原材料方面我们只能做这么多。

但我们发现,还有一些物理定律确实很奇怪,超出了我们从宏观世界的比较经验中可以有效理解的范围。因此在任何时候量子计算都会出现,或许不是,这是一种不可知的东西,目前看来一般都是遥不可及的。假设发生这种情况,人们将从实践中了解它,并且在这个过程中能够看到新的方法和未来的潜在挑战。关键是,我们不仅不知道他们会是什么,或者他们是否值得剥削,我们也绝对不知道他们什么时候会发生。

因此,我们唯一能说的是,安全边际只是基于直觉的猜测,这些都不是真正可以量化的。

所以这可能是最好的,与规格最小值相比,“鸡蛋太多,布丁太多”,为了让安全边际更加安全。还是?因为如果你回头看《密码战争一号》的剪报,它的安全边际超过它的指定位大小实际上是非常小的一个比特的事情。

因此,在clipper的情况下,只有一到两位的丢失会抹去它的安全边际。即使没有已知的安全缺陷,我怀疑很多人会认为它是安全的。至于其他国家安全局的密码,他们试图让公众接受它,似乎没有人想要它,并积极反对它。

哦,当然,我们发现国家安全局已经找到了用弱哈希伪造公钥证书的方法,当时我们不知道怎么做,我们可能永远不知道他们是怎么做到的。但是开放的社区知道这是可能的,然后很快就找到了自己的方法,如果他们不知道这是现实世界的可能,他们可能已经很久没有这样做了。

但希望现在已经有了足够的“噪音”来让信息在开发人员的头脑中传播并成为知识,希望历史不会以同样的方式重演,因为安全需要不断向前发展,而不是像某些情况下那样旋转或向后滑动,在这些情况下,已知的知识似乎在短短几十年内就被遗忘了。

迈克科尔斯3月20日,2019上午10:30

@1&1~=umm:

“对于所有认为63位与64位问题是一个小问题的人来说”

在这种情况下,它是一个尼特,因为序列号在证书的加密安全性中不起作用。它只是证书签名中散列的项目之一。

我认为最不具破坏性的做法是发行所有序列号较长的新证书,到期时更换其他部件。

1&1~=umm3月21日,2019上午10:14

@市场:

“序列号不参与证书的加密安全。”

有趣的是,然而,也有人认为,这使得用弱散列的crtifite的伪造变得不那么容易…这不是影响密码安全的因素吗?

谁相信这是个问题…

深圳3月22日,2019年12:41下午

对外行来说这似乎不是什么大问题,但这一位的变化意味着序列号只有所需熵的一半。

应该是,技术上,一半的“事件空间”。

仍被认为是63/64“必需的”熵,因为熵是一个对数度量,但我不太相信,或者。绅士和政界人士有时对数学表现得非常愚蠢,但在某种程度上,“变得聪明”是无法纠正的。和他们在一起。

克里斯·贝克4月18日,2019年1:51 AM

摩尔定律是指每18个月一次的有效强度。因此,每隔18个月,就会看到所有现有密钥的虚拟1位比特率。

发表评论

允许的HTML:

乔·麦金尼斯的布鲁斯·施耐尔侧边栏照片。