rho*_*lke 6 security encryption cryptography aes erlang-otp
我正在尝试为服务器和客户端提供一种方法,以便能够为每个请求生成唯一的IV,这对于每个客户端都是不同的,但是确定性的.我的意思是确定性是服务器可以计算未来任何请求的IV,只知道起始序列.
我需要此功能的原因是我使用AES加密来实现一次性密码(OTP)方案.当客户端登录到服务器时,它会获得一个种子.通过加密该种子生成第一个OTP.对于每个后续请求,客户端使用服务器和客户端之间的共享AES密钥加密最后一个OTP.因此,即使攻击者在没有共享密钥的情况下嗅探最后一个OTP,他们也无法获得下一个OTP.OTP在CBC模式下使用AES加密.如果服务器和客户端不同步,则会出现问题.我计划处理这个的方式是在服务器端生成一些未来的OTP,看看它们是否与客户端相匹配.但是,如果没有确定性地计算每次加密迭代的IV的方法,这是不可能的.
在我进入我提出的解决方案之前,让我表达我对AES,IV,CBC和ECB的理解.这样,如果我对我的基本原则有任何误解,可以指出并纠正.
我知道ECB将为使用相同密钥加密的相同明文块产生相同的输出.因此,它不应该用于多个数据块,因为可以通过统计分析数据来辨别有关明文的信息.基于此,似乎如果你可以保证你的数据总是小于16字节(128位),它将消除统计攻击的问题.此外,如果您还可以保证从未使用相同的密钥加密相同的明文,您将永远无法获得相同的输出.因此,在我看来,假设您的系统始终符合这些非常严格的标准,使用ECB是安全的.
我知道CBC旨在消除这两个问题.通过链接块,它消除了ECB的多块统计攻击.从不对同一个AES密钥使用相同的IV,可以消除使用相同密钥对同一输出加密相同明文的问题.
如果每个客户端获得生成的AES密钥,那么当多个用户具有相同密钥的可能性很小时,机会非常小.因此,可以安全地假设没有两个客户端将使用相同的AES密钥.
我建议的解决方案是为每个客户端提供唯一的AES密钥.生成密钥时,计数器将初始化为随机数.每次必须加密某些东西时,计数器将增加1.此数字将填充到块中,然后在ECB模式下使用AES加密.这个输出将是我使用CBC加密数据的IV.
如果服务器与客户端的计数器不同步,因为它具有相同的密钥而ECB不需要IV,它可以继续生成IV,直到找到允许数据被解密的IV.
我的想法是这个IV是安全的统计攻击,因为它等于AES的块大小.此外,每次用户都会有所不同,因为每个用户都有一个唯一的密钥,计数器总是递增.显然,必须安全地传输AES密钥(现在客户端正在使用服务器的公共RSA密钥加密生成的密钥).
我对所提出的解决方案中描述的技术的基本理解是否正确？我提议的解决方案有什么明显的错误吗？是否存在使用相同密钥以建议方式生成IV以及使用CBC加密的安全漏洞？
我意识到最后一个问题可能很难/不可能回答,因为密码学真的很难,但任何见解都会受到赞赏.
提前致谢.
正如评论中所述，我会不惜一切代价避免发明协议，而是尝试实现标准化协议。某些 OTP 协议要求客户端在登录服务器时使用第二个带外设备来接收 OTP，银行的常见情况是，在您向服务器应用程序发出登录请求时，服务器会将 OTP 发送到你的手机。客户端和服务器的 OTP 生成器通常是时间同步或反同步的，如果我理解正确的话，您计划使用后一种解决方案。我在您的描述中没有找到您打算如何在单独的设备上管理客户的柜台？
无论如何，我建议使用已经“现场测试”的标准化程序，而不是推出我自己的方案。HOTP可能就是您正在寻找的 - 尽管它使用密钥 HMAC 解决方案而不是对称加密，但这应该会让事情变得更容易，因为您不必再担心 IV。
无论如何，您应该尽早计划如何与客户建立对称密钥。如果您无法通过安全通道处理此问题（例如亲自分发密钥），这将成为整个系统的安全问题。