Clarify security notes section

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.