Devs of Nostr:
What would you do with a secure element that is easy to write software for, required no NDAs and had an open source development toolchain?
(Please renote for visibility) #asknostr
Discussion
nostr:nprofile1qqsxhugzf33nvzfmvvkm9k3pkedyf37c9qcy2na56atrfw3grctpeyqpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszrnhwden5te0dehhxtnvdakz7qgswaehxw309ahx7um5wghx6mmd9u7khfl7
Sigit is one solution!
GM Swap or ASS swaps
you mean something like https://www.nitrokey.com/products/nitrokeys ?
Kind of.
Except you could write your own software as well.
And integrate it into other systems, not just USB.
You could write your own software for it. You just need one with unlocked bootloader
Have merchants use it for attested check-ins to places.
Access control too.
nothing
Build the universal key store, with adaptors for every kind of key one could want. Even better, a BIP-39 standard to generate all of those keys.
Then I won’t need yubikeys anymore, or a ColdCard, or anything else. One (key) ring to rule them all.
> One (key) ring to rule them all.
You still need the index number if it's BIP39 derived addresses. You need to have backups for the master seed and all its derived indexes, with proper references to the derived keys' functions.
This
Seedsigner with persistent key storage.
I am no Dev. I can’t do anything :/. I do see a future in sovereign devices. Like wearable such as watches. It could be a part of it I dunno
👀
Secure element applet for secp256k1 and Schnorr combined with extension to Android OS Keystore API so a wallet app in GrapheneOS would protect keys through a secure element.
It wouldn't replace a HWW at all though, as there's no additional display for transaction confirmations and other useful information. It would just allow more secure hot wallet apps.
Currently all the SEs on the market could easily even do BIP-340/Taproot. It’s just not available to the end user.
Many things like that. You can have accelerated ChaCha20, support for Ed25519 properly, and so on…
While fully open source & high-security SEs seem to be near-impossible in the short term, it would be possible to have SEs with open and NDA-free toolchains.
For the later future Tropic Square could be interesting for what you want. Although, all the AOSP APIs would need to be developed for it in our use case (such as Weaver throttling, insider attack resistance setting and the Keystore) to have a smartphone that uses it.
More likely we'd have a new device from an OEM before the possibility of that.
The Pixels' RISC-V Titan M2 secure element is mostly derived from OpenTitan. Google committed to open sourcing the Pixel specific changes they made to OpenTitan a long time ago but it still hasn't appeared yet...
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.
Discussed it in the past but it would be more realistic to have a phone that just has a separate HWW like a Trezor attached at the back of it with some kind of hardware switch to power it on and connect it to the host device.
It already works fine as a separate device, so it likely wouldn't sell because of it being a gimmick. Also wouldn't fit some threat models because it's being used out in the open. Personally id still get one for the novelty.