为什么除了验证密码文本的完整性之外，还要验证明文的完整性？

Question

阅读iOS安全指南的S对iMessage加密协议的描述，我想弄清楚为什么它们包含了一种验证明文完整性和验证最终密码文本完整性的机制(重点是后加的)。

对于每个接收设备，发送设备生成一个随机的88位值，并将其用作HMAC- the 256密钥，以构造从发送方和接收方公钥和明文派生的40位值。88位和40位值的级联产生了128位密钥，在CTR模式下使用AES加密消息。接收端使用该40位值来验证解密明文的完整性。使用RSA-OAEP加密每个消息的AES密钥到接收设备的公钥.加密消息文本和加密消息密钥的组合然后使用SHA-1进行散列，哈希使用发送设备的私有签名密钥与ECDSA签名。

这个附加的签名组件会增加消息的真实性吗？

Answer 1

这个附加的签名组件会增加消息的真实性吗？

实际上我觉得你把它倒过来了。ECDSA的签名首先在那里。结果证明这还不够。这是“火山之唇上的舞蹈”(PDF格式)论文内容的一部分。

这样的想法是，像Apple这样的攻击者只需去掉签名，用一个“可信的签名”(因为他们提供公钥目录服务)代替它，在那里他们实际上控制签名密钥。在认证失败后，本文描述了一种向接收方发送恶意密文的方法，以使接收者能够慢慢地学习消息。

您在这里看到的“修复”是，它们现在已经成为AES-CTR密钥的一部分，这取决于发送方和接收方的公钥。当然，当攻击者剥离签名并生成新签名时，情况就不同了，然后收件人应该注意到完整性检查失败。

还请注意，解决此问题的真正明智的方法是使用签名-然后加密与经过验证的加密，而不是签署AES-CTR密文.

尽管人们不得不承认，这个“修复”在某种程度上解决了问题，假设他们真的不能改变以前的任何消息格式，因为这只是一点(无法检测到)结构变成了以前完全随机的AES密钥。