Secure Enclave Keys

[ptrwtts]

In your blog post, you mention this:

A KeyManager that leverages the Secure Enclave in iOS devices to derive Ethereum’s private key.

Is this true? I was under the impression that the Secure Enclave used secp256r1 to generate signatures, whereas Ethereum used secp256k1 (r vs k). Therefore, the only way to use a Secure Enclave generated key would be with a smart contract wallet, that did it's own verification of signed messages. Is this correct, or do you have some way to generate Ethereum compatible keys in the Enclave (cool if so!)?

[SirensOfTitan]

Hey Peter! You're right, and I think it's doubtful we'll see anything other than the r1 curve being supported the SE.

What we're doing today is essentially: we generate a k1 private key and an r1 private key, then we encrypt the k1 private key using a symmetric encryption strategy and we store that k1 key inside the Apple keychain. This means we need the decrypted key inside main computer memory when we sign transactions, but only momentarily before we can throw it away. I'm about to clean up our key generation process, and want to be a little cleaner so at the very least we explicitly autorelease the decrypted key in memory so it's only there for the very small moment we need it to compute signatures (eliminating typical attacks like memory dumps, although these are already much more difficult to execute on non-jailbroken iOS than other platforms).

I looked into the smart contract solution, but without support for the r1 as a pre-computed curve, it would be incredibly expensive to do any manual validation inside a smart contract (AFAIK), and of course this opens us up to a lot of bugs by writing our own mechanisms for doing this, so the benefit honestly is questionably worth it even if we did have a pre-computed curve.

Support of the NIST 256r1 curve would be wonderful in some capacity, but there's just still so much resistance because a lot of people think it has a backdoor (I haven't looked recently, but there's some discussion in ethereum/EIPs#28). It's unfortunate, as while the backdoor hypothesis is only rumors and whispers, the security benefits for almost any typical user would skyrocket for support of this curve. If I were an idealist, I would love to see the community (both hardware and software) rally behind curves like Curve25519 as it's safe, super fast, and has really awesome implementations.

If you have any ideas, please say!, we just want a secure, easy to use library for building good crypto apps on mobile.

[ptrwtts]

Thanks for detailed response! I couldn't recall if the changes in Byzantine made this more efficient, but sounds like it didn't. Hopefully it will be doable with account abstraction, once sharding happens, or perhaps through eWASM.

What you're doing sounds like a nice additional precaution, although as you mention, probably won't have a huge impact on a largely secure platform like iOS. Are you planning an Android library too? I could see it adding a lot of value there.

[SirensOfTitan]

Are you planning an Android library too? I could see it adding a lot of value there.

I'm a big believer in ensuring an OSS library has a tangible project attached so that we're making decisions based on real world use (as people, even developers, are really bad at predicting 😛 ). I would love to start an Android based library, but it'll have to wait until we start ground on an Android wallet. I can obviously ping back here if and when we start on an Android analogue, but it'll definitely be after 1.0 of EtherKit.

[SirensOfTitan]

Also @ptrwtts : trunk (/ 0.2.0-beta1) has a much more declarative, readable approach for handling keys. You should have a much easier time seeing how we do things now.

Closing this out for now as no action can be taken.