For Bitcoin, I'd be nervous to keep keys that hold larger amounts on a device with WIFI capabilities. On the other hand, for keys holding smaller amounts for everyday use, this seems very appropriate ...
Thanks, this lines up with how we're thinking, and the identity/signing-key split you've built into Inkan is the same seam we're designing along.
Bitcoin: the real Wi-Fi concern is a remote RCE, so we bracket every transaction with a secure-boot cycle before and after to force a fresh state, and airgapped QR-only mode removes the Wi-Fi RCE surface entirely. Even without airgap, the seed is never plaintext at rest: it's SE-protected and only unwrapped for milliseconds during signing. We originally wanted to offer the QR-or-local-network choice, but we're now leaning toward removing the non-airgapped path entirely and dropping local HTTP with it. Some users won't grasp the risk, and defaults matter more than options when the downside is losing funds. Airgapped QR is still quick for everyday amounts.
Nostr: the identity key is harder because it has to be live to sign on demand, and you can't airgap an interactive signer. So we isolate it on a dedicated second MCU with a tiny attack surface: its only input is a 32-byte hash, it never parses anything, and the nonce is generated in-chip. The scoped claim: no known remote software path can extract the key, because it never enters the network-facing processor. We keep fuzzing our parsers, but that's a different risk, stopping a malicious message from getting the device to sign something it shouldn't, not key extraction. Even then the key stays put and the worst case is a signature you didn't intend, which is recoverable. And the fully airgapped path is always there.
Physical is different. With physical possession of an unlocked device and the right tooling, someone could force a signing event and capture the key in plaintext as the signer uses it. But that means they're already holding your unlocked device, where most security models are in trouble anyway. That's the window our motion lock is built for: it locks the moment the device is moved or handled unexpectedly. It's working well in-house and going to beta before we make firm claims. It doesn't make the theory of physical extraction impossible, nothing does, but it closes the unlocked-and-unattended window this attack depends on.
On whether Inkan's delegation and revocation signing could run on this hardware: yes, and it's arguably a better fit than our own Nostr path. Ethereum delegation transactions are ECDSA over secp256k1, the SE051's native on-chip operation, so the key stays resident in the secure element and never becomes plaintext at all, the exact property we can't fully get for Nostr Schnorr but get for free on your Ethereum case. One caveat: your delegation format presumably wraps the signature in some typed-data encoding (EIP-712 or similar). The primitive is still SE-native ECDSA either way, since encoding and hashing happen host-side before the hash reaches the signer, but I wouldn't claim to know your exact format without looking at it.
To be upfront, our brand is Bitcoin-only, a deliberate identity choice rather than a hardware limit. But the platform isn't closed, and your delegation case is exactly the kind of thing we'd be glad to see run on it. The SE051 exposes ECDSA (secp256k1), ECDH, AES, and EC point ops, so there's real headroom. Modifying the firmware yourself is a direction we'd welcome, though it would be on dev units rather than production hardware, production ships with Secure Boot locked, so for this we'd provide units with Secure Boot unlocked and an attestation key that marks them as dev-only, so a modified unit can never present itself as a trusted production device. An auditable path where you implement your own delegation format and verify the whole chain fits what you've built better than a black box.
We are in continuous development, and we won't go to market until it's been in other hands and independently reviewed. We'd rather have our claims tested by people trying to break them than make firm public statements ahead of it. If you'd want to be a part of that, we'd value your eyes in particular.
Bitcoin: the real Wi-Fi concern is a remote RCE, so we bracket every transaction with a secure-boot cycle before and after to force a fresh state, and airgapped QR-only mode removes the Wi-Fi RCE surface entirely. Even without airgap, the seed is never plaintext at rest: it's SE-protected and only unwrapped for milliseconds during signing. We originally wanted to offer the QR-or-local-network choice, but we're now leaning toward removing the non-airgapped path entirely and dropping local HTTP with it. Some users won't grasp the risk, and defaults matter more than options when the downside is losing funds. Airgapped QR is still quick for everyday amounts.
Nostr: the identity key is harder because it has to be live to sign on demand, and you can't airgap an interactive signer. So we isolate it on a dedicated second MCU with a tiny attack surface: its only input is a 32-byte hash, it never parses anything, and the nonce is generated in-chip. The scoped claim: no known remote software path can extract the key, because it never enters the network-facing processor. We keep fuzzing our parsers, but that's a different risk, stopping a malicious message from getting the device to sign something it shouldn't, not key extraction. Even then the key stays put and the worst case is a signature you didn't intend, which is recoverable. And the fully airgapped path is always there.
Physical is different. With physical possession of an unlocked device and the right tooling, someone could force a signing event and capture the key in plaintext as the signer uses it. But that means they're already holding your unlocked device, where most security models are in trouble anyway. That's the window our motion lock is built for: it locks the moment the device is moved or handled unexpectedly. It's working well in-house and going to beta before we make firm claims. It doesn't make the theory of physical extraction impossible, nothing does, but it closes the unlocked-and-unattended window this attack depends on.
On whether Inkan's delegation and revocation signing could run on this hardware: yes, and it's arguably a better fit than our own Nostr path. Ethereum delegation transactions are ECDSA over secp256k1, the SE051's native on-chip operation, so the key stays resident in the secure element and never becomes plaintext at all, the exact property we can't fully get for Nostr Schnorr but get for free on your Ethereum case. One caveat: your delegation format presumably wraps the signature in some typed-data encoding (EIP-712 or similar). The primitive is still SE-native ECDSA either way, since encoding and hashing happen host-side before the hash reaches the signer, but I wouldn't claim to know your exact format without looking at it.
To be upfront, our brand is Bitcoin-only, a deliberate identity choice rather than a hardware limit. But the platform isn't closed, and your delegation case is exactly the kind of thing we'd be glad to see run on it. The SE051 exposes ECDSA (secp256k1), ECDH, AES, and EC point ops, so there's real headroom. Modifying the firmware yourself is a direction we'd welcome, though it would be on dev units rather than production hardware, production ships with Secure Boot locked, so for this we'd provide units with Secure Boot unlocked and an attestation key that marks them as dev-only, so a modified unit can never present itself as a trusted production device. An auditable path where you implement your own delegation format and verify the whole chain fits what you've built better than a black box.
We are in continuous development, and we won't go to market until it's been in other hands and independently reviewed. We'd rather have our claims tested by people trying to break them than make firm public statements ahead of it. If you'd want to be a part of that, we'd value your eyes in particular.
2
