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?

Reply to this note

Please Login to reply.

Discussion

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.