Ja, vor allem weil die Konzepte der Hersteller sich auch noch stärker unterscheiden, als man anfangs denkt.
Ich wollte damit nur sagen, dass ich als Neuling im Thema damals der Meinung war, die Bitbox verwende das Secure Element genauso wie der Ledger. Über solche Details wurde bisher eben wenig diskutiert. Man musste sich also selbst auf der Herstellerseite informieren. Deshalb der Vorschlag an Roman.
Aber trotzdem kurz zu deiner Frage:
Ich kenne mich mit Secure Elements nicht aus. Allerdings ist der Grundgedanke nach meinem Verständnis der, das Betriebssystem und die Schnittstellen soweit zu vereinfachen und abzuspecken, dass weniger Spielraum (Komplexität) für software-seitige Angriffe bleibt. Hinzu kommt ein Hardwaredesign, was physische Angriffe verhindern soll.
Es wird also natürlich schwerer sein, ein Secure Element „auszulesen“, als einen normalen Microcontroller. „Auslesen“ hier im Sinne des Restrisikos für einen erfolgreichen, software-seitigen oder physischen Angriff.
Allerdings bringt diese Feststellung alleine nicht viel beim Vergleich von HW-Wallets. Wie du selbst schreibst, ist die Seedphrase bei der Bitbox verschlüsselt auf dem Microcontroller gespeichert. Das ist gut auf der Shiftcrypto Website und auch hier von Stadicus beschrieben.
Aus meiner Sicht kann man das Problem des closed-source Secure Elements allerdings prinzipiell nicht komplett lösen. Beispiel Bitbox:
Das Secure Element wird eingesetzt, um resistent ggü. physischen Eingriffen zu sein (siehe verlinkter Beitrag). Um aber dem closed-source Code des Herstellers nicht vertrauen zu müssen, kann das Secure Element alleine die Seedphrase nicht entschlüsseln. Hört sich erst einmal gut an.
Allerdings muss ich dem Hersteller immer noch vertrauen. Wo ist der Unterschied, ob der Hersteller einen betrügerischen oder fehlerhaften Code implementiert, oder ob er einen betrügerischen oder mangelhaften Schutz vor physischen Zugriffen designed?
Zumindest hat man durch das Bitbox-Design das rein software-seitige Problem mit dem closed-source Code gelöst. Das verbleibende HW-Risiko ist wahrscheinlich geringer.
Um das Vertrauensproblem aber komplett zu lösen, müsste eben auch noch das HW- und SW-Design des Secure Elements komplett open-source sein. Deshalb sind die von @Cricktor verlinkten entsprechenden Pläne von Trezor interessant.