对于我的系统来说，这是一个可接受的ARC4加密实现吗？

Question

我正在构建一个开源的硬件系统，它将被用来控制互联网上的事物。该系统由基站和模块组成，采用2.4GHz无线通信进行数据交换。

现在，我已经到了需要保护发射的射频数据不被重新传输和解密的地步。我也需要保护系统，这样没有人可以伪装成基站和发送射频包到某个模块，例如打开我的灯或打开门。

关于需要保护的数据的详细信息：

1. 消息总是27字节长(这可以减少到20字节，为适当的MAC留下空间)
2. 消息的格式(协议)为公众所知
3. 消息内容有时是公开的，因为它通常是一个简单的命令，比如"1“表示”打开“命令，"0”表示“关闭”命令。其他未来模块可能包含应该对潜在窃听者保密的数据。
4. 消息很少发送，没有固定的RF活动。

由于该项目是在内存有限的微控制器上实现的(整个程序的内存约为4kB )和程序的闪存(通常为32 4kB)，所以对于最先进的加密算法和MAC哈希生成功能来说，没有太多的空间。在每个包中传输的数据也有一个限制，仅为29个字节。数据不应该被分割成多个数据包并在接收端重新组装，所以我们需要处理的只有29个字节。

以下是我当前实现的规范：

1. 使用ARC4加密消息
2. ARC4的键是27+1字节长
3. 键用于最多256次传输或30分钟的射频无活动(以第一次为准)。在模块内部生成新密钥后，将其加密并发送到基站，以便解密进一步的数据
4. 密钥(27字节)附加1字节(同步)，在每次加密解决重传漏洞后增加。滚出后，这个字节再次从0开始(0-255)。最后，这使得ARC4的密钥为28字节，并且每个传输都不同。

加密过程

27字节未加密的数据消息首先用同步字节(最终ARC4密钥的最后一个字节)填充，然后用CRC-8校验和填充，在前面的28个字节上计算。这些得到的29个字节使用当前的ARC4密钥(27个字节和同步计数器(1个字节)进行加密)。

CRC-8校验和与同步字节相结合用作解密侧的MAC。该分组是使用当前KEY+SYNC解密的，如果解密包中的同步字节与解密过程中预期和使用的同步字节相同，并且如果CRC-8是在整个解密包上计算的，则所有这些都是好的。

问题

1. 我认为这并不是一个非常聪明的实施MAC的方法。还有什么东西我可以在这里实现，占用我的未加密数据空间最多9字节？我可以将应用程序数据空间从27字节减少到20字节，从而为改进的MAC提供空间。
2. 这个系统的当前实现有多安全，因为我担心有人可能会注入他们自己的RF数据包，这些包将被Modules解密并匹配SYNC & CRC-8。有什么办法来分析这个吗？

我希望我在这篇文章中没有给出太多无关的信息，这是我第一次实现某种加密，也是我在SE上的第一篇文章。

更新

我已经决定放弃这个设计，因为它是不安全的。感谢波乔提出的替代方案。我在AVR411文档中找到了CMAC实现，它也针对我目前使用的相同的硬件。只要在谷歌上搜索AVR411，你就可以找到这个文档。

Answer 1

这个协议有很多问题。

首先，生成RC4密钥(将秘密密钥与公共名称连接起来)的方式是以软弱而闻名。节省您的一件事是，您只在生成一个新的密钥之前执行256次；但是，众所周知，如果您使用一个秘密密钥执行了2000次，则泄漏该密钥的可能性很小。在我看来，这已经够吓人的了；我会重新考虑这一点。

现在，关于你的实际问题：

我认为这不是一个实现MAC的非常明智的方法。

这是温和的，这是一个非常糟糕的方式实现它。问题是CRC-8是完全线性的；截取数据包的人可以在密文中翻转位，然后预测CRC-8中的哪些位，他需要翻转才能进行补偿；解密后的明文将精确地翻转这些位。唯一可以拯救您的是，您将拒绝同一消息两次；一个创造性的攻击者可以绕过这一点，导致接收真实的消息失败。

看起来，您的主要限制是内存(对于程序和数据)，而不是执行速度。如果是这样的话，我建议您看一下小型的AES实现，比如在这个堆栈交换中提到的。它们似乎很符合您的预算，并且可以作为一个真正安全的协议的基础。