Secure Enclave support for secp256k1

--- robots: noindex, nofollow --- # Secure Enclave support for secp256k1 ###### tags: `article / in process` ## Background Hardware-based security for cryptocurrencies has been quite complicated for a while. Despite the security claims of various HSM (Hardware Security Module) offerings from different companies, and despite "certification" of these silicon solutions in standards such as FIPS 140 and FIDO, none of them are as secure as promised for cryptocurrencies due to a lack of support for the `secp256k1` curve used by those digital currencies. Instead, these "legacy" Secure Enclaves were designed for the banking community, and thus only support legacy NIST, ISO, and IETF algorithms such as RSA, curves such as `secp256r1` (used by NIST ECDSA and believed to be designed by the NSA), and more recently IETF's 25519 (which is a good NUMS "Nothing Up My Sleeves" curve, but has complications with HD-keys and doesn't safely support Schnorr aggregation for multisig). One of the more common solutions for this problem in Bitcoin and other cryptocurrencies is to use an SE (Secure Enclave) chip to secure a less-secure MCU (Micro Controller Unit) chip, making the combination of both a form of simple TEE (Trusted Exuction Environment) that can execute code signed by the manufacturer and verified by the SE. An example of this is the architecture used by Ledger[[1](https://developers.ledger.com/docs/nano-app/bolos-hardware-architecture/)] where the MCU has a script interpreter for micro-python, which is what is used to actually conduct`secp256k1` operations. This combination does have the advantage of flexibility: as new algorithms, new blockchains, or new security apps emerge, they can be implemented in the scripting languing. However, this makes the `secp256k` keys in the MCU very vulnerable to a variety of attacks that SE designs would be less vulnerable to. In addition, the current generation of SEs that requires this sort of design for cryptocurrency use has their designs under NDA, which makes inspection of and verification of their implementations very difficult. A new generation of SE is needed that supports modern-day elliptic-curve cryptography natively. ## The Opportunity [CrossBar Inc](https://crossbar-inc.com), a silicon chip design company, has joined with Blockchain Commons to work with the cryptocurrency community to define the requirements for a new silicon chip (for delivery in the 2023 timeframe) that is optimized for cryptocurrency. The current plan is a two-chip design, with a more powerful SE that natively supports a side-channel attack resistant `secp256k1` as well an MCU more powerful than current cryptocurrency MCUs, all integrated into a single tamper-resistant and supply-chain verifying system (as well as offering many other features). The chip will be designed using open development practices (with code open sourced as much as is possible), allowing for inspection and verification. ## Seeking Feedback from Hardware Designers & Cryptographers Taking proven silicon designs for `secp256r1` used by NIST ECDSA, and adapting them for `secp256k1`, with equivalent security and side-channel resistance, should be relatively easy. However, there is a real opportunity for the community to request additional features in the SE that could add real value to the community by offering further security. These additional features might include: * Support for not just `secp256k1` ECDSA signing, but also Bitcoin's BIP-340 Schnorr signatures, ECDH, ECIES, etc. * Support in the SE for generating BIP-32 key derivations from the seed directly, so hierachical keys can be used for signing without private keys leaving the SE. * Support for more advanced functionality through the exposure or addition of various elliptic curve operations such as: * Constant-time conditional point addition * Scalar-point multiplication * Fast exponentiation * Hardcoded linear combinations of 256-bit values modulo specific primes * Direct support for more forms of deterministic nonces. * Support for [anti-exfiltration via nonces](https://medium.com/blockstream/anti-exfil-stopping-key-exfiltration-589f02facc2e), for instance to prevent leaking of key material in signatures. * Support for encrypted, SSS, or VSS restoration native to the SE to allow for safer recovery of seed or key material. * Additional PUFs (Physically Unclonable Functions) available for different purposes. * Monotonic (one-way) counters. * Encryption improvements, such as: * Primitives to accelerate Chacha20/Poly1305 or Google's Adiantum disk encryption. * More Hashes such as: * Blake * SHA-3 * More curves such as: * 25519 * Ristretto255 * BLS-12-381 * Wild-cards such as: * Signed Poisson Random Time (for PoET (Proof of Elapsed Time)) * Support for mirror curve of `secp256k1` for curve bulletproofs [link](https://github.com/BlockchainCommons/Community/issues/71#issuecomment-410482607) or [HALO](http://www.doc.ic.ac.uk/~ids/dotdot/crypto_papers_etc_worth_reading/coin_mixing/Halo_iacr_2019_1021.pdf). Related, CrossBar has a new silicon technology called [ReRAM](https://www.crossbar-inc.com/technology/reram-overview/), which allows for a more secure persistent memory to be directly integrated with CMOS logic. CrossBar can't do all of this in the next generation chip (2023), especially as it is not clear which can be easily and securely done in silicon — or even if the SE is the best place to do many of these functions. However, feedback from the community can help them to choose priorities and will also inform longer-term chip designs. ## Questions for Wallet Community * CrossBar is considering not allowing the seed or the derived BIP32 `secp256k1` private keys to leave the SE, only public keys. Do you have requirements for private keys to be derived from the seed and made available to MCU? Related, might a white-list of derivations be helpful? * @kanzure: I would like a system where you can specify whether the private key can ever be exported. And then the chip should sign a statement saying how the key was configured when it was created. For example, the chip could attest to the fact that the key was created in the way that the private key can never be exported. Or it could attest to the alternative of course. * @ChristopherA: maybe some attestations/proofs leveraging cryptographic tricks like the anti-exfilration to verify that the key was created with randomness contributed by MCU (or the user) * What are your needs for persistent storage? How much? * Do you have use cases for shared ReRAM between MCU and SE by logical access control (vs. physical separation of ReRAM dedicated to each)? Concerns? * Are there some specific things the SE can do to assure supply chain, both software and hardware, that are possible with new functionality? ## Questions for CrossBar * @ChristopherA: How much ReRAM do you anticipate having available on the SE vs MCU? * @devrandom: more details about SE program memory: * is it part of the ReRAM? * how large? * is there a way to get an attestation of the program memory contents? * @devrandom: will developers be able to develop without signing any agreement (e.g. NDA)? * @devrandom: can developers use Rust? * @ChristopherA In MCU I presume? Any particular suggests on issues on how to best implement Rust in an ARM-derived MCU? @devrandom: is the SE also ARM? for Lightning, most of the complexity has to be in the SE. * @devrandom: will developers be able to program off-the-shelf parts and ship them to end-users, or will the parts have to be factory programmed? * @jwilkins: support seedxor? (https://seedxor.com/) * @ChristopherA Interesting. Should be compared against alternatives like VSS or VSS using partial values from FROST. ## About Blockchain Commons Blockchain Commons is a not-for-profit company whose goal is to create open, interoperable, secure, and compassionate digital infrastructure. It works to bring together the digital-assets community to jointly decide a way forward. Much of this has been done through the [Airgapped Wallet Community](https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions), which has discussed interoperable specifications, complex use cases, recovery standards and much more. Blockchain Commons' work interfacing between CrossBar and the wallet community is another example of how it's helping the community advance. Many community members are also [sponsors](https://github.com/sponsors/BlockchainCommons), to ensure the continuation of the Commons.