No, the STM32 has no internal root of trust; there is no mask ROM that verifies a first stage loader in flash is correct before executing. The main security feature on STM’s is that flash is on-die, so hard (not impossible) to disturb as long as all the security features are enabled such as RDP2.
It is possible to glitch RDP2 devices into RDP1 (see https://chip.fail ) which doesn’t give code readout but does enable JTAG and allow RAM contents at the time of reset to be read; the gitch just needs to flip a single bit in the flash config register to do this. Whilst in theory you could glitch it into RDP0 with the same trick, you need to flip multiple bits just the right way… exponentially harder.
In RDP2 mode, the system ROM DFU mode is disabled as is JTAG/SWD. However, code running on the device can still jump to the system ROM DFU code and hence enable it, but this sounds like particle behavior not inherent to the STM32.
Note that there is generally no way back from RDP2, which means if a device ever got to a point where it required particle doctor when in RDP2, it’d be a brick and unrecoverable. When you use RDP2 you need to be really, really sure that you’re never ever going to need DFU or JTAG ever again.
I don’t believe particle images are signed, though they are sent over the encrypted channel. On electric imp devices, OS upgrades are both AES encrypted and RSA signed, with the private key being stored in a FIPS140-2 HSM that requires multifactor physical authentication to perform a signing. Some imp devices like the imp005 do validate encrypted boot images using mask ROM code, but STM32-based ones are using RDP2 and a bootloader to validate OTA upgrades as they are applied because there aren’t any other ways to do it.
Security is hard!