mcu non sécurisé oui et non, le coeur du truc est quand même dans un ST31... c'est secure. mais seulement lui... le reste du système est une semi passoire, alors qu'il est par conception dans l'environnement sécurisé du système. du coup, c'est mort.

le chiffrement de la comm ne change rien puisque le canal sécurisé aboutit dans un cpu non secure, donc la clé est trouvable.

A la réflexion, l'envoi du code mcu au SE pour vérification n'est pas si con, puisque t'envoies justement pas le hash mais le code, et il faut l'envoyer complètement... donc avoir soit un cpu plus gros, soit le transmettre depuis un canal externe, et ca peut justement être détecté par timing (c'est une des contremesures implémentées)
il y a des techniques pour rendre le code non compressible, genre remplir les zones non utilisées par du random, et inclure toute la mémoire dans la vérif, pas juste le firmware utile.
une autre contre mesure implémentée (lisez le rapport original, pas le bullshit media autour) consiste a eviter d'avoir de la duplication de routines entre l'OS et le bootloader... technique qui a permis de faker la vérification du code non secure, en envoyant des bouts de code du bootloader, et en patchant les endroits correspondants dans le firmware.

lire la mem du stm32 par jtag depuis le cpu secure n'est pas possible: celui ci n'a a sa disposition qu'une simple UART. rien d'autre. c'est justement ce qui les a forcés a utiliser un cpu proxy non secure pour gérer bouton et écran... et que ca pète tout le modèle. les pcb n'ont même pas d'anti tampering sur le cpu insecure.

edit: bon l'article est précis et complet... mais ne fait que repomper le rapport!