是否能通过OTA远程更新应用程序

BWP和PWP位控制闪存中的那些页是否可以在运行时被擦除和重新编程。启用它们意味着它们不能被擦除或重新编程。理想情况下，您将只启用那些涉及OTA Bootloader的页面。这样，在理论上，引导加载程序不能意外地删除它自己。但是它仍然可以删除主应用程序并重新编程一个新的应用程序。当你说“安全系数”时，你具体指的是什么？你想保护什么？



      以下为原文

    The BWP and PWP bits control whether those pages in Flash can be erased and reprogrammed at runtime. Enabling them means that they can't be erased or reprogrammed.
 
Ideally, you'll enable those bits only for the pages that involve your OTA bootloader. That way, the bootloader can't, in theory, accidentally erase itself. But it can still erase the main application and reprogram a new one.
 
When you say "security quotient", what are you referring to, specifically? What are you wanting to protect?

具体地说，我需要避免欺骗。因此，如果我的Bootloader是写保护的，那么黑客不能用自己的Bootloader替换它，并用自己的工具获取我的应用程序代码。此外，通过写保护我的Bootloader，它可以避免欺骗的可能性；否则我需要对Bootloader和应用程序进行相同的加密。目前，我们通过启用CP配置位来读取保护我们的软件。但是，我的代码仍然可以使用Bootloader读取，并且工具还可以与我的Bootloader通信，因为它没有被加密。



      以下为原文

   
To be specific,
I need to avoid spoofing. So If my bootloader is write protected, then the hacker cannot replace it with their own bootloader and fetch my application code using their own tool. Further will by write protecting my bootloader could it avoid the possibility of spoofing; else would i need to encrypt the bootloader and application for the same. Currently we have read protected our software by enabling CP configuration bit. But still my code can be read using bootloader and tools can communicate to my bootloader since it has not been encrypted

具体地说，我需要避免欺骗。因此，如果我的Bootloader是写保护的，那么黑客不能用自己的Bootloader替换它，并用自己的工具获取我的应用程序代码。此外，通过写保护我的Bootloader，它可以避免欺骗的可能性；否则我需要对Bootloader和应用程序进行相同的加密。目前，我们通过启用CP配置位来读取保护我们的软件。但是，我的代码仍然可以使用Bootloader读取，并且工具还可以与我的Bootloader通信，因为它没有被加密。



      以下为原文

    To be specific,
I need to avoid spoofing. So If my bootloader is write protected, then the hacker cannot replace it with their own bootloader and fetch my application code using their own tool. Further will by write protecting my bootloader could it avoid the possibility of spoofing; else would i need to encrypt the bootloader and application for the same. Currently we have read protected our software by enabling CP configuration bit. But still my code can be read using bootloader and tools can communicate to my bootloader since it has not been encrypted

如果启用了BWP，则它应该保护引导加载程序不被擦除，因为它需要在该点进行全芯片擦除来替换它。这将需要一个外部程序员，擦除闪存将击败取代Bootloader的目的。它可能是加密程序闪存，并只是从RAM运行，但会有一个速度惩罚，你可能耗尽的RAM真的很快。CP不保护闪光灯。从内部读取（否则，它将如何运行），因此引导加载程序不允许来自任何源的外部代码变得至关重要。你如何处理这个问题取决于你的攻击向量。例如，引导加载程序如何知道它正在与授权的源进行对话？数据流是用公钥/私钥对加密的，所以即使它们能够访问Bootloader代码，它们也不知道用于加密数据的私钥吗？Bootloader是否保持某种方式知道应用程序自从上次更新（哈希、校验和、CRC等）以来没有被篡改？SysKy值是否存储在引导加载程序中，或者通信应用程序必须提供它们（加密），以防止应用程序的重写吗？物理访问处理器有多难？正如你所看到的，在保护你的产品时要考虑很多问题，而我上面所说的只是表面上的。在强大的安全性、安全性的成本以及你的客户愿意为你的产品支付多少费用之间总会有一个折衷。



      以下为原文

    If the BWP is enabled, it should protect the bootloader from being erased, as it requires a full chip erase at that point to replace it. That would require an external programmer, and erasing the flash would defeat the purpose of replacing the bootloader.
 
It might be possible to encrypt the program flash, and just run from RAM, but there would be a speed penalty, and you might run out of RAM really fast.
 
CP does not protect the flash from being read internally (else, how would it run), so it becomes critical that the bootloader doesn't allow external code from any source. How you approach that problem depends on your attack vectors. For example, how does the bootloader know it is talking to an authorized source? Is the data stream encrypted with a public/private key pair, so even if they had access to the bootloader code, they don't know the private key used to encrypt the data? Does the bootloader maintain some way of knowing the application hasn't been tampered with since the last time it updated (hash, checksum, CRC, etc.)? Are the SYSKEY values stored in the bootloader, or does the communicating app have to provide them (encrypted), in order to prevent overwrite of the application? How hard is it to physically access the processor?
 
As you can see, there are a lot of considerations to take when securing your product, and what I asked above only scratches the surface. There is always going to be a tradeoff between strong security, the cost of that security, and how much your customers are willing to pay for your product.