使用共享秘密建立加密密钥
我需要在一个由8位微控制器组成的网络上建立一些安全措施。非常有限的RAM，CPU和数据包大小。
我已经锁定了一个基于秘密的共享计划。设置共享秘密超出了范围。加密是AES128。
为了安全地在两个节点(A和B )之间创建和共享加密密钥，我编写了以下内容：
A creates an encryption key Ks = H(Ns, R0)
A sends R0 to B
B calculates key K's = H(Ns, R0)K和Ks是相同的当且仅当B有Ns
Where H = Hash(R0|Ns|R0), or Hash(R0|Ns|H(Ns)) or maybe HMAC (still undecided)
R0 = random number
Ns = Shared network secret.
Ns is 16 byte. R0 is 4 byte. Both come directly from a RNG.主要目标是:防篡改，前向保密。
暂时不关心对侧通道的抵抗或重放攻击。
R0 (因此也是Ks)将定期更新，也许每100~10K独立分组传输一次。
这个计划可以吗？Ns或R0的尺寸需要增加吗？最重要的是，这个计划是否能够保证Ns的安全，以及持续多长时间？
===============编辑：
前向保密：
我想要确保，只要网络秘密是安全的，如果未来的会话密钥(Ks)被泄露，过去的会话密钥和数据也不应该被泄露。另外，重新协商会话密钥应该重新建立安全性。
这可能不是向前保密的确切定义，但这就是我的意思。我没有会话，但是我会定期地将密钥过期，或者过了一段时间，或者一些数据包被跨越等等，然后称之为会话。
===============
条例H()
基于答案，我在H()的函数列表中添加了AES(k=Ns，d=R0)。将根据时间/时钟要求作出决定。
===============
现在，根据答案，我推断H()的所有当前选项都将创建足够好的密钥来保护加密数据和网络秘密Ns。
如果您正在阅读这篇文章，并认为其中任何一个可能是不安全的，请留下评论或答复。谢谢。
回答 2
Cryptography用户
发布于 2015-06-25 20:16:19
所以，它们都有一个16字节的共享秘密，您想要创建一个共享的16字节(=128位)的AES key...am i吗？为什么不把秘密当作钥匙呢？
只要把它插入CBC或CTR或GCM或其他什么东西，你就会很好。
如果您要运行大量消息，那么您所描述的使用HMAC的方案将是完全可以接受的。据我所知，如果不攻击HMAC或AES，它是无法被打破的。
当然，这是假定网络秘密只为Alice和Bob所知，这取决于微控制器如何设置与网络共享的密钥。
Cryptography用户
发布于 2015-06-25 20:39:51
首先，不要翻动你自己的密码。
第二，您不需要协商每个传输的会话密钥。只要网络秘密是安全的，所有使用这个秘密的连接都是安全的。
然而，你提到了向前保密。你不能用预共享的钥匙得到这个。如果钥匙被拧了，每一个连接(现在和将来)都可以被打破，前提是握手被记录下来。
关于您对Ns的关注，即它可能被从协议中提取或以其他方式被破坏，您是相当安全的，因为散列函数使得反向查找Ns变得不可能。然而，在大约50年(或者更短的时间内)，许多组织都有可能用暴力强制128位键。因此，如果您的设备将部署超过40年，请确保升级到更强大的设备(并确保Ns不能从设备反向工程！)
使用HMAC作为H的最佳选择，因为您希望使用R0的“身份验证标记”，使用共享密钥作为会话密钥。应该选择更大的R0，因为现在它没有真正的值，因为32位的值并不是那么不可预测，我建议选择12-16字节范围(96-128位)的东西。
对我来说，密钥设置阶段看起来已经足够好了，尽管我从来不相信任何协议的安全性还没有被证明。您可以保留它的原样，或者您可以用R1添加来自B的响应，并使用两者的异或，这只有在您认为一个设备可能被破坏时才有用，并且它将帮助任何攻击者以某种方式“预测”某个密钥。每更新一次10-100 k的消息看起来不错(假设设备将在可预见的时间内交换此数量的数据，比如一周或更短的时间)。
使用TLS-PSK是一种选择，因为它适用于“不要使用您自己的密码”，因此您可能需要像TLS_PSK_使用_AES_256_GCM_SHA384一样使用AEAD方案(即GCM)。作为您的共享密钥，您可以插入您的Ns或您的派生会话密钥，它们很可能是相当安全的。
https://crypto.stackexchange.com/questions/26534
复制相似问题
腾讯云开发者
