使用OTP数组是一个坏主意吗？

您所描述的是任何预共享密钥（PSK）系统的限制。当在N个节点之间具有预共享密钥时，要破解这些节点之间的通信，您所要做的就是中断其中一个节点（如果预共享密钥也如上文所暗示的那样用于通信）。忘记有一个被黑客攻击的节点解密/欺骗消息。对你捕获的节点进行处理，并直接获取密钥。如果有人在所有设备上使用相同的PSK，那么你就一次破解了所有的东西，因此PSK有局限性。您需要创建一个捕获它们密钥的系统破坏其有用性。例如，在物理设备通过PSK与服务器通信，并且每个物理设备与服务器具有不同的PSK对的情况下（它们都是唯一的），那么破解一个设备不是非常有用的。您可以对接收到的消息进行解密，并且可以像您所暗示的那样对您自己的消息进行加密，但是由于您已经销毁了实际使用它们的物理设备的固件，因此您将无法在应用程序中使用它们。由于每个设备都具有唯一的PSK，所以不能应用该信息来攻击第二设备。因此，如果传输到某个人所拥有的物理节点的数据的机密性对于维护很重要，甚至在设备被破坏之后，那么OTP密钥可能不是一个好主意。您希望使用RAM密钥。在这种情况下，您可能还想考虑使用PSK之外的其他设备……如果数据的机密性在设备销毁之后并不重要，只要数据不能应用于其他类似的设备，那么OTP中每个设备唯一的PSK应该非常完美。这里的假设是，不应该存在攻击者可以摧毁然后进行欺骗的设备，这些设备将为他们提供有用。因此，如果他们有可以通过服务器（比如说通过智能手机）控制的IoT灯，那么破坏光来欺骗光是没有用的，因为他们在过程中失去了光的功能（更不用说你必须已经拥有物理访问权）。然后，他们不能通过发送来自服务器的数据来使用这些信息来控制其他远程光。这是因为另一种光具有不同的、未知的PSK。攻击者无法访问服务器，因此他们不能攻击该端并试图欺骗数据到光来控制该光。在这个例子中，数据的机密性在传输之后是没有价值的。所以我发现你发了一个“光”命令或者“关灯”命令…事后了解并不十分有用。如果某人能够访问两个设备，并且能够销毁并欺骗被销毁的设备是有益的，那么OTP中的密钥将是一个问题。那么使用OTP密钥阵列是不是一个坏主意？是的，不。这要看你的情况。这在某些情况下是完全合理的，在另一些情况下是一个非常糟糕的想法。



      以下为原文

    What you describe is a limitation of any pre-shared key (PSK) system.  When have a pre-shared key between N nodes, all you have to do to crack the communication between those nodes is break one of the nodes (if the pre-shared key is also used for communication as implied above).  Forget having one hacked node decrypt/spoof the messages.  De-process the node you captured and take the keys directly.  If someone uses the same PSK on all devices, then you've cracked everything all at once.

And thus PSK has limitations.  You need to create a system where capturing they key destroys its usefulness.  For example, in the situation where a physical device is talking to a server through a PSK and each physical device has a different PSK pair with the server (they are all unique), then cracking one device any not be very useful.  You can decrypt messages received and you can encrypt your own messages like you implied, but you will not be able to use them in application since you have destroyed the firmware of the physical device that actually uses them.  Since each device has a unique PSK, you will not be able to apply that information to attack a second device.  
 
So if the confidentiality of the data transmitted to the physical node that someone possesses is important to maintain, even after the destruction of the device, then an OTP key probably isn't a good idea.  You'd want to use a RAM key.  You'd probably also want to consider using something other than PSK in that case as well...
 
If the confidentiality of the data doesn't matter past the destruction of the device as long as that data can't be applied to other similar devices, then a unique PSK per device in OTP should be perfectly fine.  The assumption here is that there shouldn't be a device that the attacker can destroy and then spoof that would provide useful to them.  So if they have a IoT light that can be controlled via a server (through a smartphone let's say), then it is no use to them to destroy the light to be able to spoof the light since they lost the functionality of the light in the process (not to mention you have to already have physical access).  They can't then use that information to control some other remote light by sending data spoofed from the server.  This is because the other light has a different, unknown PSK.  The attacker doesn't have access to the server so they can't attack that end and try to then spoof the data to the light to control that light.  In this example the confidentiality of the data isn't valuable after the transmission.  So I found out that you sent a "light-on" command or a "light-off" command... not very useful to know after the fact.
 
If you have a situation where the person has access to both devices and there is benefit to being able to destroy and then spoof the destroyed device, then the key in OTP would be a problem.
 
So is using an OTP key array a bad idea?  Yes and no.  It depends on your situation.  It is perfectly reasonable for some situations and a really bad idea in others.  

谢谢，这对我来说是一个很好的解释。从PIC24F的角度来看，我想一种可能的“最佳实践”将包括在最高设置时使用CodeGuard，将密钥存储在闪存中，将闪存直接传输到CRYKEY寄存器，保存哪个设备具有w的纸质列表关键…还有什么？格拉斯达夫



      以下为原文

    Thanks, that was a good explanation for me.

From the PIC24F point of view I suppose a possible 'best practice' would include
using CodeGuard at its highest setting,
storing the key in flash memory,
transferring the flash memory direct to the CRYKEY register,
keeping a paper list of which device has which key...
 
And what else?
 
cheers
Dave