I have talked to Tropic Square and I had a really poor impression. They are pretty inexperienced in the SE world from my talks with them, and custom firmware was barely a priority for them (which I asked about)
My current work about open SE platforms is with one of the big 3 SE companies, which has been pretty supportive. (I’ll let you guess which, there’s only one company that would barely consider it.)
I haven't interacted with Tropic Square in any capacity nor do I think it has been an idea to use in a GrapheneOS device simply because there's no largely available 'product' and there would be a lot of developer work. I don't know about other team members interactions.
ATM our expectation is Qualcomm is going to add MTE to Snapdragon this year and OEMs willing to provide timely patches would mean a lot more devices would be meeting our standards in 2026. We're in contact with an OEM to make a GrapheneOS variant of a phone with a next generation Snapdragon flagship that can hopefully come in the coming years.
Snapdragon flagships have a basic secure element, but it wouldn't be as secure as the Titan M2, but it is sufficient at a baseline. This is the most likely alternative for the next non-Pixel GrapheneOS device. Snapdragon does other things better outside of secure element though.
Yeah, implementing a new platform is a lot of work. Nice to see non-Pixel devices are coming, at least.
What specific security features are being looked for in a secure element?
The big ones are:
- StrongBox keystore support with hardware key attestation support (used in Auditor) with attest key support, which then would be used for key pinning
- Weaver key derivation throttling (hardware-enforced Android credential brute forcing countermeasure)
- Insider attack resistance (Owner user must authenticate before the SE can be firmware updated)
Samsung closely meet requirements but because they kill the secure element features with an eFuse when installing another OS, it is useless to us.
I looked at the Tropic Square datasheet and it would not be able to offer the StrongBox keystore protection level, throttling, or support for insider attack protection. So basically not usable for this purpose.
It would be possible to do it with what I’m working on, along with some custom eSE applet-like functionality (sandboxed).
Considering it is a Trezor offshoot, no surprise. I would imagine their goal is to use it for their HWWs firstly. It's why they started it.
The chip also is too expensive for what it does. They had some preliminary pricing but that is it.
I feel like it is a huge wasted opportunity, but oh well.
Was just writing my reply when you sent yours.
With this, there would have to be a closed and immutable boot code of the secure element, otherwise the rest could be mostly open, allowing stronger firmware verification.
Insider attack protection would be implemented as system-controlled flag that decides whether data transfer is allowed across applet upgrades. This could require the owner to authenticate, so it would fulfill that requirement.
Requiring the KeyStore applet be signed by a trusted party + issuing an attestation certificate to it would also tick that box.
