请问如何才能安全地存储加密密钥？

这取决于你所说的“安全存储”。你需要多少保护？代码保护(CP)可以防止外部调试器/程序员读取部件，但不阻止内部代码访问它们。系统总线具有可以设置为阻止对某些启动器的访问的权限机制。这可以防止代码不必要地读取密钥，但是需要一些代码工作才能使其有效。另一个选项是管理程序，因为MZ EF部分确实具有虚拟化的能力。PRPL基金会创建了一个运行在MZ-EF部分的管理程序。您可以在HTTPS://GITHUBCOM/PRPLFASTATION/PRPL-HyvVisor中找到代码。



      以下为原文

    It depends on what you mean by "securely store". How much protection do you need?
 
Code Protect (CP) can prevent the part from being read by an external debugger/programmer, but doesn't prevent the internal code from accessing them.
 
The system bus has permission mechanisms that can be set up to block access to certain initiators. This can prevent code from reading the keys unnecessarily, but will require some code work to make it effective.
 
Another option is a hypervisor, as the MZ EF part does have the ability to virtualize. The Prpl foundation has created a hypervisor that runs on the MZ EF part. You can find the code at https://github.com/prplfoundation/prpl-hypervisor.
 

我不确定细节，因为它不是一个典型的嵌入式系统。但它是MIPS32（更具体地说，是M5150核）的一个特性。所有MIPS32核都需要一个内存管理单元来将虚拟内存映射到物理内存。在PIC32设备上，当您想到启动序列时，就会看到这一点。所有PIC32设备都在0xBFC0000万开始执行代码。这称为KSEG1，并且访问未缓存的内存，这意味着没有东西放入缓存中，无论是MZ上的L1缓存，还是MX上的picocache。在启动序列完成之后，处理器通常跳到缓存的KSEG0内存，以便获得可能的最佳执行速度。在MX设备上，有一个称为KUSEG的模式，它限制了正在执行的代码的内存映射。它应该防止访问SFRS，这将是防止访问密钥的关键。任何对硬件和密钥的访问都应该由内核处理。MZ设备具有相似的模式，但是MX使用固定映射（FMT），MZ设备有一个真正的TLB MMU，这意味着它可以进行配置。在PrP管理程序上会很好。另一种可能性是类似于LITEBSD的，它是运行在PIC32 MZ上的4.4BSD版本。这甚至可能允许将密钥存储在文件系统中，并且基于用户ID阻止对密钥的访问。



      以下为原文

    I'm not sure about the specifics, because it is not something typically done in an embedded system. But it is a feature of the MIPS32 (and, more specifically, the M5150 core).
 
All MIPS32 cores require a memory management unit in order to map virtual memory to physical memory. On PIC32 devices, this is seen when you think about, say, the startup sequence. All PIC32 devices start executing code at 0xBFC0_0000. This is called KSEG1, and accesses memory uncached, meaning that nothing is put into a cache, either the L1 cache on MZ, or the picocache on MX. After the startup sequence is complete, then the processor will typically jump to cached, KSEG0 memory in order to get the best execution speed possible.
 
On MX devices, there is a mode called KUSEG, which limits the memory map of the code being executed. It should prevent access to the SFRs, which would be key to preventing access to the keys. Any access to the hardware and keys should be handled by the kernel.
 
The MZ devices have a similar mode, but where the MX uses Fixed Mapping (FMT), the MZ devices have a true TLB MMU, which means it can be configured.
 
Again, I'm not very familiar with the deep internals of this, which is why looking at prplHypervisor would be good. Another possibility is something like LiteBSD, which is a 4.4BSD version running on PIC32MZ. This might even allow storing the keys in a file system, and blocking the access to the keys based on a user ID.

非常感谢你精心的回答！嗯，这对我的时间框架来说太复杂了，但是这很有趣，我稍后再看。同时，我需要找到一个更快更容易的解决方案：也许你已经提到的许可机制：



      以下为原文

    Thank you very much for the elaborate answer!
Well, this is way too complicated for my given time frame, but it's definitely interesting and I'll look into it later. Meanwhile, I'll need to find a quicker and easier solution grin:  perhaps the permission mechanisms you have mentioned :)
 

克罗斯兰，目前的体系结构是接收加密消息，使用密钥对其进行解密，并执行加密命令。可以使用适当的命令更改密钥，因此必须将其存储在内部闪存中，可以在其中重写。直接读出闪光灯2。使用BooLoad 3读取程序中的Flash。替换密码或代码，允许访问和后门。4。任何不需要军用级设备的化学/电子方式获得密码，这能不能使用我的微芯片已经提供的工具和手段完成，或者我需要添加HW防御来防止任何类型的篡改？或者考虑其他提供这些防御的产品？任何建议都将非常感谢：



      以下为原文

    Crosland,
the architecture of the system is, currently, receiving encrypted messages, decrypting them using a key, and executing the encrypted commands. the key may be changed using the appropriate command, so it must be stored in the internal flash, where it can be rewritten.
 
what I want to protect against (attack vectors, as you described it), is:
1. reading out the flash directly
2. reading out the flash programatically, using a bootloader
3. replacing the password, or code, to allow access and backdoors.
4. any chemical / electronic way to get the password that does not require military grade equipment
 
can this be done using tools and means already provided my Microchip, or I'll need to add HW defenses against any type of tampering?
Or maybe consider other products that provide these defenses?
 
Any advice will be much appreciated :)