很多%的加密方式_密码软件可能会失败的很多很多方式-CSDN博客

很多%的加密方式

by Nabeel Yoosuf

由Nabeel Yoosuf

密码软件可能会失败的很多很多方式 (The many, many ways that cryptographic software can fail)

When cryptographic software fails, what’s to blame?

当加密软件出现故障时，应该负责什么？

Algorithms?

算法？

Cryptography libraries?

密码学图书馆？

Apps incorrectly using those libraries?

应用程序错误地使用了那些库？

Or is it something else entirely?

还是完全其他？

We rely on cryptographic algorithms and protocols every day for secure communication over the Internet. We’re able to access our bank accounts online because cryptography protects us. We’re able to send private messages to our friends because cryptography protects us. We’re able to buy and sell things using credit cards and Bitcoin because cryptography protects us.

我们每天都依赖加密算法和协议来确保Internet上的安全通信。我们可以在线访问我们的银行帐户，因为密码保护了我们。我们能够向我们的朋友发送私人消息，因为加密技术可以保护我们。我们可以使用信用卡和比特币买卖东西，因为密码学可以保护我们。

Let me give you a concrete example of this. When you check your email through your favorite browser, the connection between your browser and the email server is secured using the TLS (transport level security) protocol, so that no one can eavesdrop on your emails or modify them in transit without your knowledge.

让我给你一个具体的例子。通过最喜欢的浏览器检查电子邮件时，浏览器和电子邮件服务器之间的连接使用TLS(传输级安全性)协议来保护，因此没有人可以在您不知情的情况下窃听或修改传输中的电子邮件。

In short, without cryptography, the Internet we know today could not be possible. Law and order on the internet depends on cryptography.

简而言之，如果没有密码技术，今天我们知道的互联网是不可能的。互联网上的治安取决于加密技术。

But this tool that we all rely upon so heavily is also quite brittle. Our cryptographic software often lets us down. Sometime it really lets us down.

但是我们大家都非常依赖的这个工具也很脆弱。我们的加密软件经常使我们失望。有时候它真的让我们失望。

Have you ever wondered why the cryptographic software — including implementations of the TLS protocol — fail over and over again?

您是否曾经想过，为什么加密软件 (包括TLS协议的实现) 会反复失败？

According Veracode’s state of security reports, our cryptographic software is just as vulnerabilities as it was two years ago.

根据Veracode的安全状态报告，我们的加密软件与两年前一样，都存在漏洞。

Are these failing because of weaknesses in the underlying cryptographic algorithms?

这些失败是由于底层密码算法的弱点导致的吗？

Well, several past attacks (Apple iOS TLS, WD self encrypting drives, Heartbleed, WhatsApp messages, Juniper’s ScreenOS, DROWN, Android N-encryption and so on) show us that our cryptographic software is less likely to be broken due to the weaknesses in the underlying cryptographic algorithms. In other words, cryptanalysis is one of the less likely threats to our cryptographic software.

好吧，过去的几次攻击( Apple iOS TLS ， WD自加密驱动器， Heartbleed ， WhatsApp消息， Juniper的ScreenOS ， DROWN ， Android N加密等)表明，由于以下方面的弱点，我们的加密软件不太可能被破坏基本的加密算法。换句话说，密码分析是对我们的密码软件不太可能的威胁之一。

Have you ever heard an attacker breaking a 256-bit AES encryption algorithm to recover the secret hidden within it? None that I know of. (Of course, if you use a vulnerable obsolete cryptographic protocol like DES or RC4, cryptanalysis might help break the software). So if the culprit isn’t cryptanalysis, then what is it?

您是否听说过攻击者破解256位AES加密算法以恢复隐藏在其中的秘密？我不知道。 (当然，如果使用易受攻击的过时的加密协议(例如DES或RC4) ，则加密分析可能会帮助破坏软件)。因此，如果罪魁祸首不是密码分析，那又是什么？

Well, it’s everything but cryptanalysis. In other words, cryptanalysis is not the weakest link of cryptographic software. Bad actors use numerous other weak links to break cryptographic software.

好吧，除了密码分析之外，这就是一切。换句话说，密码分析不是密码软件的最薄弱环节。不良行为者会使用许多其他薄弱环节来破坏加密软件。

失败原因1：加密库中的错误 (Cause of failure #1: bugs in crypto libraries)

One popular example is the Heartbleed bug.

一个流行的例子是Heartbleed错误。

What’s the matter with Heartbleed? This bug (CVE-2014–0160) was introduced due to an incorrect implementation of the TLS heartbeat extension in the widely-used OpenSSL (read 66% of the internet), which is used to support TLS in web servers. What does this extension do? As the the name suggests, it’s a keep-alive feature where one end of the connection sends a payload of arbitrary data and the other end is supposed to send the exact copy of the data to prove that all is fine and well.

Heartbleed怎么了？引入此错误( CVE-2014-0160 )的原因是，在广泛使用的OpenSSL(用于读取Internet的66％)中错误地实现了TLS心跳扩展，该SSL用于在Web服务器中支持TLS。此扩展程序有什么作用？顾名思义，这是一个保持活动的功能，其中连接的一端发送任意数据的有效负载，而另一端则发送数据的精确副本以证明一切都很好。

The bug turned out to be an age-old mistake of not bound checking before memcpy() that uses non-sanitized data. The vulnerable OpenSSL implementation does not validate the payload length against the actual payload. An attacker could lie about the length and get the victim to send more bytes from its memory, as shown in the following diagram.

原来，该错误是一个古老的错误，即在使用未经消毒的数据的memcpy()之前不进行绑定检查。易受攻击的OpenSSL实现无法根据实际负载验证负载长度。攻击者可能会撒谎，然后让受害者从其内存中发送更多字节，如下图所示。

This in turn allowed the attacker to obtain session keys and other secret information (like your username and password) from any websites currently in your browser’s memory.

反过来，这又使攻击者可以从浏览器内存中当前存在的任何网站中获取会话密钥和其他机密信息(如用户名和密码)。

Let me show you the code. The patch is essentially a bound check added to the patched version 1.0.1g as shown below.

让我向您展示代码。补丁实质上是添加到补丁版本1.0.1g中的绑定检查，如下所示。

====== Vulnerable code =======/* Enter response type, length and copy payload */*bp++ = TLS1_HB_RESPONSE;s2n(payload, bp);memcpy(bp, pl, payload);

====== Patched code =========hbtype = *p++;n2s(p, payload);if (1 + 2 + payload + 16 > s->s3->rrec.length)  return 0; /* silently discard per RFC 6520 sec. 4 */pl = p;

Lesson learned: Always bound check your strings before using them. Sanitization is vital for stopping bad inputs from getting into your system.

经验教训：在使用字符串之前，一定要检查字符串。清理对于阻止不良输入进入系统至关重要。

失败原因2：操作系统和应用程序 (Cause of failure #2: operating systems and apps)

You probably remember Apple’s “goto” bug (CVE-2014–1266) in its SSL/TLS implementation, disclosed in February 2014.

您可能还记得苹果在2014年2月披露的SSL / TLS实施中的“ goto”漏洞 ( CVE-2014–1266 )。

Apple’s code with the “goto” bug:

苹果的代码带有“ goto”错误：

1 static OSStatus2 SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa,                                  SSLBuffer signedParams,3                       uint8_t *signature, UInt16 signatureLen)4 {5   OSStatus err;6 …78   if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)9     goto fail;10  if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)11    goto fail;12    goto fail;13  if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)14    goto fail;15  …1617 fail:18   SSLFreeBuffer(&signedHashes);19   SSLFreeBuffer(&hashCtx);20   return err;21 }

So, what’s the issue here? The extra goto statement on line 12 bypasses all certificate checks for SSL/TLS connections in iOS and Mac devices. This makes lines 13 to 16 effectively dead code. This simple implementation mistake accepts any invalid certificate, making the connection susceptible to Man in the Middle attacks.

那么，这是什么问题？第12行上的额外goto语句绕过了iOS和Mac设备中所有SSL / TLS连接的证书检查。这使第13至16行有效地变为死代码。这个简单的实现错误会接受任何无效的证书，从而使连接容易受到中间人攻击。

I was curious to find out whether the implementation bugs in crypto software are more due to bugs in the crypto libraries themselves than in the way apps use them. Well researchers from MIT analyzed 269 cryptographic bugs reported in the Common Vulnerabilities and Exposures database between January 2011 and May 2014. They found that only 17% of bugs are caused by the crypto libraries themselves. The remaining 83% are due to misuse of crypto libs by app developers.

我很好奇地发现，加密软件中的实现错误是否更多是由于加密库本身的错误所致，而不是由于应用程序使用它们的方式所致。麻省理工学院的研究人员分析了2011年1月至2014年5月之间在“常见漏洞和披露”数据库中报告的269个加密错误。他们发现，只有17％的错误是由加密库本身引起的。其余的83％是由于应用程序开发人员滥用了加密库。

But just because the majority of bugs are due to misuse of crypto libraries in apps doesn’t mean that we can just blame app developers and get on with our day.

但是，仅仅因为大多数错误是由于在应用程序中滥用了加密库所致，并不意味着我们可以责备应用程序开发人员并继续前进。

There could be many reasons behind the above statistics on the crypto misuse. The crypto libraries themselves may not be providing safe default options, may not have adequate documentation or may be difficult to use. Further, many developers may not have a formal understanding of applying cryptography in their software, even though they are experts at software development itself. These all could result in the misuse of crypto libs.

上述关于密码滥用的统计数据背后可能有很多原因。密码库本身可能未提供安全的默认选项，可能没有足够的文档或可能难以使用。此外，即使他们是软件开发本身的专家，许多开发人员可能对在其软件中应用密码学也没有一个正式的了解。所有这些都可能导致滥用加密库。

Lesson learned: always use tools to analyze your code. A dead code analysis tool should have caught this specific case.

经验教训：始终使用工具来分析您的代码。无效代码分析工具应已捕获此特定情况。

失败原因三：设计不良 (Cause of failure #3: bad design)

In 2015, researchers uncovered a series of issues in WD self-encrypting drives. There were serious design flaws in their use of cryptographic algorithms. I wrote about this in a previous post. Let me show a couple of flaws here.

在2015年，研究人员发现了WD自加密驱动器中的一系列问题。在使用加密算法时存在严重的设计缺陷。我在以前的文章中写过这个。让我在这里展示一些缺陷。

Following the best practices, WD did use two levels of keys to encrypt documents stored in the drive — master KEK (Key Encryption Key) and per file DEK (Data Encryption Key). Further, they did use a key derivation function to derive KEKs from the password.

按照最佳实践，WD确实使用了两个级别的密钥来加密存储在驱动器中的文档：主KEK(密钥加密密钥)和每个文件DEK(数据加密密钥)。此外，他们确实使用密钥派生功能从密码派生KEK。

But the way they designed the key derivation function itself was totally insecure. They used a fixed salt and a fixed number of iterations. Thus, it was susceptible to pre-computed hash table-based attacks. Attackers could recover keys much faster than a pure brute force attack would have been able to.

但是他们设计密钥派生函数本身的方式是完全不安全的。他们使用了固定的盐和固定的迭代次数。因此，它容易受到预先计算的基于哈希表的攻击。攻击者可以比单纯的蛮力攻击更快地恢复密钥。

And if this vulnerability weren’t enough, WD used a dismal random number generator to generate KEKs. It was not only predictable — it also didn’t have enough complexity (only 40 bits).

如果此漏洞还不够，WD会使用令人沮丧的随机数生成器来生成KEK。它不仅可以预测-还没有足够的复杂性(仅40位)。

Cryptographic protocols critically rely on cryptographically secure pseudorandom number generators. If these aren’t secure enough, any cryptographic algorithm or protocol using these random numbers will be quite easy to break.

密码协议至关重要地依赖于密码安全的伪随机数生成器。如果这些不够安全，那么使用这些随机数的任何加密算法或协议都将很容易破解。

Lesson learned: Have a good understanding of cryptographic constructs and know their limitations. Follow industry best practices for key derivation.

获得的经验：充分了解密码构造并了解其局限性。遵循行业最佳实践进行密钥推导。

失败原因4：配置错误或默认配置不安全 (Cause of failure #4: misconfigurations or insecure default configurations)

DROWN attack of breaking TLS connections via SSLv2 is a good example of this. You may be using fairly secure TLS connection to communicate with a web server, but if the web server still supports (which it shouldn’t) old SSLv2, an attacker can exploit it to break the security provided by TLS and get at your keys and other sensitive information.

通过SSLv2破坏TLS连接的DROWN攻击就是一个很好的例子。您可能正在使用相当安全的TLS连接来与Web服务器进行通信，但是如果Web服务器仍然(不应该)支持旧的SSLv2，则攻击者可以利用它来破坏TLS提供的安全性并获取您的密钥和其他敏感信息。

SSLv2 has long considered to be broken, and none of the clients today use it for secure connections. But researchers have found that out of 36 million HTTPS servers they probed, 6 million (about 17%) still supported SSLv2.

长期以来，SSLv2一直被认为已被破坏，如今，没有任何客户端将其用于安全连接。但是研究人员发现，在他们调查的3600万HTTPS服务器中，有600万(约17％)仍支持SSLv2。

The above research also uncovers another common lazy practice of using the same key pair in different servers of an organization. It shows how even when one server supports only TLS, if there are other servers supporting SSLv2 with a shared certificate, the server that only supports TLS is vulnerable as well.

上述研究还发现了在组织的不同服务器中使用相同密钥对的另一种常见的懒惰做法。它显示了即使一台服务器仅支持TLS，如果还有其他服务器支持带有共享证书的SSLv2，那么仅支持TLS的服务器也容易受到攻击。

Lesson learned: a system is only as secure as its weakest link. Try to protect all of your systems at least reasonably well.

经验教训：系统的安全性仅取决于其最薄弱的环节。尝试至少合理地保护所有系统。

加密软件还有很多其他方式可能会失败 (There are lots of other ways cryptographic software can fail)

Can you think of some additional ways?

您能想到其他方法吗？

It fails due to users. How? Think about social engineering attacks. RSA SecureID breach is said to originate from phishing emails exploiting users and a zero day vulnerability.

由于用户而失败。怎么样？考虑一下社会工程攻击。据说RSA SecureID违规源于利用用户的网络钓鱼电子邮件和零日漏洞。

It fails due to unrealistic threat models (Breaking web applications built on top of encrypted data).

由于不切实际的威胁模型( 破坏基于加密数据构建的Web应用程序)，它失败。

It fails due to hardware (Breaking hardware enforced technologies such as TPM with hypervisors).

由于硬件而失败( 破坏了硬件强制实施的技术，例如带有管理程序的TPM )。

It fails due to side channels (Timing attacks on RSA, DH and DSS algorithms).

它由于侧信道而失败( 对RSA，DH和DSS算法的定时攻击 )。

As you can see, cryptographic software can fail due to many reasons. Are we really doomed to never get cryptographic software right? Or can we at least can reduce the number of such failures? Why can’t we learn from the past and avoid the same mistakes happening again and again? What tools will help us spot most of these issues?

如您所见，加密软件可能由于多种原因而失败。我们真的注定永远不会正确使用加密软件吗？还是至少可以减少此类故障的数量？为什么我们不能从过去中吸取教训，避免一次又一次地犯同样的错误？哪些工具可以帮助我们发现大多数这些问题？

Our situation actually isn’t all that bleak. There are ways to prevent most of the failures discussed above. In a follow up post, I’ll explore the topic of how we can make cryptographic software fail less often.

实际上，我们的处境并不是那么凄凉。有一些方法可以防止上面讨论的大多数故障。在后续文章中，我将探讨如何使密码软件发生故障的频率降低的主题。

Thanks for reading. If you found this article useful, please click the ? below so that others can see this on Medium.

谢谢阅读。如果您发现本文有用，请单击“？”。以便其他人可以在Medium上看到。