security - 对CBC和ECB使用相同的AES key

Question

概述

我正在尝试为服务器和客户端提供一种方法，使其能够为每个请求生成唯一的IV，这对于每个客户端而言都是不同的，但是具有确定性。我所说的确定性是，服务器将来仅知道启动顺序就可以为任何请求计算IV。

我需要此功能的原因是，我正在使用AES加密来实现一次性密码(OTP)方案。当客户端登录到服务器时，将获得一个种子。通过对该种子进行加密来生成第一个OTP。对于每个后续请求，客户端使用服务器和客户端之间的共享AES key 对最后一个OTP进行加密。因此，即使攻击者在没有共享 key 的情况下嗅探了最后一个OTP，他们也将无法获得下一个OTP。在CBC模式下，使用AES对OTP进行了加密。如果服务器和客户端不同步，就会出现问题。我计划解决此问题的方法是在服务器端生成一些OTP，以查看将来是否与客户的OTP相匹配。但是，如果没有确定性地为每次加密迭代计算IV的方法，这是不可能的。

在我提出建议的解决方案之前，让我表达我对AES，IV，CBC和ECB的理解。这样，如果我对基本原理有任何误解，可以指出并纠正它们。

理论

欧洲央行

我知道ECB会对使用相同 key 加密的相同明文块产生相同的输出。因此，不应将其用于多个数据块，因为可以通过对数据进行统计分析来识别有关明文的信息。基于此，如果您可以保证数据始终小于16字节(128位)，则可以消除统计攻击的问题。另外，如果您还可以保证永远不会使用相同的 key 对相同的明文进行加密，那么您将永远不会获得相同的输出。因此，在我看来，假设您的系统将始终满足这些非常严格的条件，那么使用ECB是安全的。

CBC和IV

我知道CBC旨在消除这两个问题。通过链接块，它消除了ECB的多块统计攻击。通过从不对相同的AES key 使用相同的IV，可以避免使用相同的 key 对相同的输出加密相同的纯文本的问题。

关键唯一性

如果每个客户端都获得了一个生成的AES key ，则虽然有多个用户具有相同 key 的可能性很小，但机会非常小。因此，可以安全地假设没有两个客户端将使用相同的AES key 。

拟议的解决方案

我建议的解决方案是为每个客户端提供唯一的AES key 。生成 key 后，计数器将初始化为随机数。每次必须对某些内容进行加密时，计数器将增加一。该数字将被填充到一个块中，然后在ECB模式下使用AES进行加密。其输出将是我的IV，用于使用CBC加密数据。

如果服务器由于具有相同的 key 而与客户端的计数器不同步，并且ECB不需要IV，则它可以继续生成IV，直到找到允许解密的数据为止。

我的想法是，此IV不受统计攻击，因为它等于AES的块大小。另外，对于每个用户而言，每次都将有所不同，因为每个用户将具有唯一的 key ，并且计数器将始终递增。显然，必须安全地传输AES key (现在，客户端正在使用服务器的公共(public)RSA key 对生成的 key 进行加密)。

我的问题

我对所提出的解决方案中描述的技术的基本理解正确吗？我提出的解决方案显然有什么问题吗？使用相同的 key 以建议的方式生成IV以及使用CBC进行加密是否存在安全性缺陷？

我意识到最后一个问题可能很难/不可能回答，因为加密技术确实很困难，但是任何见识都会受到赞赏。

提前致谢。

Answer 1

如评论中所述，我将避免不惜一切代价发明一个协议(protocol)，而是尝试实现一个标准化的协议(protocol)。某些OTP协议(protocol)要求客户端在登录服务器时使用第二个带外设备来接收OTP，银行常见的情况是，在您向服务器应用程序登录请求后，服务器将向您发送OTP到您的手机。如果我理解正确，那么您打算使用后一种解决方案，那么客户机和服务器的OTP生成器通常是时间同步的或逆同步的。在您的描述中，我没有发现您打算如何在单独的设备上管理客户的柜台？

无论如何，我建议使用经过“现场测试”的标准化程序，而不要采用自己的方案。 HOTP可能就是您想要的-尽管它使用键控HMAC解决方案而不是对称加密，但这将使事情变得容易，因为您不必再​​担心IV。

无论如何，您都应该尽早计划如何与客户建立对称 key 。如果您不能通过安全 channel 来处理此问题(例如亲自分发 key )，那么这将成为整个系统安全的问题。