Merge branch 'main' of https://github.com/firmwaremodules/stm32-secure-patching-bootloader

Author: firmwareguru

Docs/README.md

@@ -239,8 +239,8 @@ Also note: the firmware image header contains a 4-byte field for version and the
 
 * The bootloader system is designed so that your products and firmware update files can be distributed into uncontrolled environments.  This means firmware confidentiality is ensured through AES encryption, and firmware and device integrity are ensured through ECDSA (digital signatures).  The AES encryption and the ECDSA public verification keys are stored in your device's internal flash.  The AES encryption and ECDSA private signing key are typically stored in your firmware development repository (e.g. on GitHub, your developer's and build PCs).  
 
-* Those that would attempt to undermine your products and solutions know that these keys exist.  Thus, protection of these keys is paramount.  You must create a root of trust on each of the devices you deploy by way of enabling RDP Level 2 through the stm32-secure-patching-bootloader production build (you get this build when you register the bootloader at firmwaremodules.com).  This build will automatically check and enable RDP Level 2 on each boot to help mitigate potential RDP regression attack vectors (yes these do exist).  Note that when RDP Level 2 is enabled, you permanently forfeit the ability to connect a debugger to your devices (a good thing when security is concerned). 
+* Those that would attempt to undermine your products and solutions know that these keys exist.  Thus, protection of these keys is paramount.  You must create a root of trust on each of the devices you deploy by way of enabling RDP Level 2 through the stm32-secure-patching-bootloader production build (you can get this build upon request when you register the bootloader at firmwaremodules.com).  This build will automatically check and enable RDP Level 2 on each boot to help mitigate potential RDP regression attack vectors (yes these do exist).  Note that when RDP Level 2 is enabled, you permanently forfeit the ability to connect a debugger to your devices (a good thing when security is concerned, but not good if you're still in development). 
 
 * The bootloader system is not designed to protect your device and secrets from your own firmware application.  If you don't trust your application or the way it works (e.g. you think it might offer a way for an attacker to read out contents of memory) then this bootloader system is not for you, or at least you must be aware that internal protections such as proprietary readout protection (PCROP) or firewalls are not implemented.  These are by no means foolproof even when enabled.  Don't offer a command-line interface that has memory peek and poke commands. 
 
-* Finally, you should assume that if an attacker has physical access to your device and is determined enough (time and resources) then your secrets will eventually be extracted.  You need to weigh the expense and effort someone (or some group) would go to obtain your firmware update AES encryption key and public signature verification key, and the 'payoff' that may be associated with that effort.   
+* Finally, you should assume that if an attacker has physical access to your device and is determined enough (time and resources) then your secrets will eventually be extracted no matter what you do.  You need to weigh the expense and effort someone (or some group) would go to obtain your firmware update AES encryption key and public signature verification key, and the 'payoff' that may be associated with that effort.   

README.md

@@ -1,6 +1,6 @@
 ## STM32 Secure Patching Bootloader
 
-*Don't forget to check out our [v1.4 preview](https://github.com/firmwaremodules/stm32-secure-patching-bootloader/tree/v1.4-preview) branch with support for awesome new boards like the G0 and G4 series*
+*Don't forget to check out our [v1.4 preview](https://github.com/firmwaremodules/stm32-secure-patching-bootloader/tree/v1.4-preview) branch with support for awesome new boards like the G0 and G4 series and the Nucleo-WL55*
 
 A Secure Patching Bootloader and Firmware Update System for all **STM32** MCUs.
 
@@ -25,11 +25,12 @@ This secure patching bootloader and firmware update system is Apache and MIT lic
 The stm32-secure-patching-bootloader reserves between **40 - 80 KB** at the beginning of internal flash, depending on MCU and feature selected (support for USB flash loader, external flash / multisegment add to size).
 The bootloader also reserves about **5 KB** at the start of SRAM for the secure patching engine's stack and state, fully indepdenent of the application.  This allows the application to perform in-application firmware updates and make other runtime requests of the bootloader (get firmware version, etc).
 
+Check out the **FAQ** [here](https://github.com/firmwaremodules/stm32-secure-patching-bootloader/wiki#faq) in the wiki.
+
 ### Quick Start Guide
 
 Refer to details in [Product Documentation](Docs/README.md).
 
-
 ### Supported Boards
 
 This list will grow over time as we work to support key STM32 NUCLEO, DISCO, EVAL and 3rd-party boards.  Note that we group -DISCO, -Discovery and -DK  as just `DISCO`.